On Wed, 27 Mar 2013, Jon Masters wrote:
Prior to Brendan sending that mail last night, we had an internal RH
meeting wherein this topic came up (and precipitated the email). I
explained already in that and will repeat here that the ARM kernel is
already relocatable. It has only two major requirements right now:
0). That it be loaded into actual RAM somewhere. Most boards direct map
physical RAM at 0. Some do it at 2GB or higher. Others have aliasing
where you see physical RAM in two ranges and other weirdness. The reason
we have these different load addresses today is that the hardware
platforms are not all consistent around physical map.
1). That it be loaded at sufficient alignment (low-order bits 0x8000 due
to the exception vectors). Maybe that one even can/could/is handled by
the uncompressor. I dunno if that limitation is relaxed somewhere.
The decompressor code takes care of that already. If you compile your
kernel with CONFIG_AUTO_ZRELADDR=y then all you need is to load the
zImage within the first 128MB of physical RAM.
I mentioned already that I favor ignoring the uImage header and just
loading the kernel where we know it needs to be.
But U-Boot will fight against you nevertheless. Irrespective of where
in RAM you ask it to load a uImage, it will still relocate it according
to the address provided in its header before executing the kernel.
I agree that the easiest way to do that is to drop uImage loading and
do zImage.
Nicolas