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