Subject: Re: Changing kernel base address (was: Re: Heads up: shared arm include files)
To: Chris Gilbert <chris@buzzbee.freeserve.co.uk>
From: Mike Pumford <mpumford@black-star.demon.co.uk>
List: port-arm32
Date: 01/14/2001 20:57:02
> On Sunday 14 January 2001  5:52 pm, Robert Swindells wrote:
> > >> Since a.out files don't contain the address to load things at, the
> > >> bootloader has to have wired-in knowledge of where the kernel goes. 
> > >> ELF, of course, doesn't suffer from this.
> > >
> > >ELF would solve many problems but it's not exactly trivial to change too.
> > >
> > >> It's also worth noting that libkvm currently has the value of
> > >> VM_MAXUSER_ADDRESS compiled into it, so changing it may cause
> > >> compatibility issues there.
> > >
> > >Yes but the m68k code has to deal with this being variable so maybe it
> > >is possible to do the same on arm32 to get people over the
> > >compatibility problems without causing too much pain. If this can be
> > >done it removes at least one obstacle to the relocation.
> >
> > I would take a look at whether the static maps can be made to take up
> > less space. At first glance, IOMD_BASE is on a 16MB boundary when it
> > only needs to be aligned to 1MB. There may be some of the VIDC
> > registers that can be brought closer together in the VM map too.
> > How much video memory do you need anyway ?
> 
> Certainly the mappings of chips could be moved, the VIDC, IOMD and COMBO only 
> need 1MB I believe.  So they could be pushed up. 
> 
> > If you can align things on 1MB boundaries both physically and
> > virtually you can use a L1 pagetable entry for the whole section.
> 
> Yep, currently they are mapped in with sections.  Looking at the machdep on 
> the riscpc there's nothing above 0xf8000000.  Not sure on the shark, cats 
> etc.  Perhaps we should consider moving them upwards on all arm32 boxen.
> 
Well we can move things on RiscPC first and then do the SHARK and CATS 
afterwards. Everything is already setup to allow for different mappings on 
each machine. Before doing this we need a complete map of the memory as it is 
layed out now along with extents for each of the current sections. Then we 
need to figure out how the current mappings work so that they can be moved.
Time to figure out what the hell is going on in initarm().

Mike