Subject: Re: Changing kernel base address (was: Re: Heads up: shared arm include files)
To: None <port-arm32@netbsd.org>
From: Chris Gilbert <chris@buzzbee.freeserve.co.uk>
List: port-arm32
Date: 01/15/2001 21:09:33
Hi Reinoud,

On Monday 15 January 2001 10:50 am, Reinoud Zandijk wrote:
> Hi Ben, Mike, Chris and all :)
>
> Just saw this thread and had to reply on it allthough i must admit i've
> been a bit too quiet on it ... :

That reminds me, your boot loader doesn't work on my kinetic system.  comes 
up with an error at line 6770 (not had time to figure it out I lack a decent 
basic editor on my acorn (I've ZAP around here somewhere, but need to get it 
onto the Risc os side))

> On Sat, 13 Jan 2001, Ben Harris wrote:
> > > I noticed that. I had a quick look at the bootloader and that would
> > > need some hacking if the kernel was rebased as it assumes that the
> > > kernel starts at 0xf0000000. I cannot speak for the new bootloader
> > > written by Reinoud Zandijk but it may need similar tweakings.
>
> Yep, just some simple tweakings... I must admit that my first try was to
> get a good working system without optimising the memory map at first. I'll
> do the modifications on my new bootloader as soon as possible to try to
> squeeze some extra memory out of it.

It's more the amount of memory the Kernel VM has access to.

> As far as i know, the fixed address was put there for the Shark/EBSA
> family. Just hadn't considered yet a change for the RiscPC. It has to be
> tested on these machines too ...
>
> The problem i've seen mentioned in this thread is that some ubc chunks
> can't be mapped due to their size ? Is that confirmed that it is really
> the size ? Where do these critters get mapped anyway ... above the kernel
> ?

Yes it's the size of the kernel VM space (it's not big enough to map in the 
UBC chunk along with everything else)

> For the RiscPC I can't see any reason why the address can't be lowered
> .... say to 0xe0000000 .... Nothing there in the memory map anyway... and
> the VIDC/MEMC/IOC can be reduced indeed... Will look at that too .

I think in the short term shifting the VIDC/IOMD upwards would help as we can 
then just grow the kernel VM space, without requiring bootloader changes.

> Its good to see that the SA1x00 port is making progress :) ...

Indeed

> Will roll out a new version of the updated bootloader soon ... I've also
> got some clues as to why the debug-images were crashing ...

Excellent :)

Anyway they'll be more eyes on the current source now, sup has just updated 
to use current.

Cheers,
Chris