>> 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 ?

If you can align things on 1MB boundaries both physically and
virtually you can use a L1 pagetable entry for the whole section.

For the SA-11x0 port, I have put all the static maps into 0xFExxxxxx,
which gives me 208MB of kernel VM space.

I potentially need this much kernel VM space as I have modified the md
driver hooks to work with on board flash memory.

Robert