On Wed, 27 Mar 2013, Jon Masters wrote: > On 03/27/2013 11:26 AM, Nicolas Pitre wrote: > > 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. > > Good to know. Then we're not specifically stuck with any special > alignment requirements as long as we load within the branch limit.
It is not a branch limit. The zImage decompressor simply masks the pc register with 0xf8000000 to determine the start of RAM, hence the 128MB restriction. That mask was selected to cover all the possible RAM start addresses encountered so far, and we believe that no one is going to produce a system with a smaller alignment for RAM. Bootloaders can branch into the kernel at any address since they use absolute branches for that. Nicolas _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
