[PATCH] Clean up ARM compressed loader
Nicolas Pitre
nico at fluxnic.net
Wed Feb 24 23:06:55 EST 2010
On Thu, 25 Feb 2010, Hector Martin wrote:
> Russell King - ARM Linux wrote:
> > On Wed, Feb 24, 2010 at 06:34:49PM -0500, Nicolas Pitre wrote:
> >> What about simply not compiling the decompressor with -fPIC when using
> >> ZBOOT_ROM=y? That would certainly solve the problem with the only
> >> restriction that such kernel images won't be bootable from RAM which is
> >> probably an acceptable compromize.
> >
> > Unfortunately, that doesn't solve the stack-bashing with ZBOOT_ROM=n.
>
> Yes it does, that's exactly what my first version of the patch did. Once
> you get rid of the partial relocation used for ROM builds (with split
> text/bss) you don't need -Dstatic=, and once you get rid of that you
> solve the stack-bashing. The ROM build becomes a bog standard
> non-relocatable ROM image (with the usual LMA/VMA linker script stuff to
> copy initialized data to RAM), and the RAM build becomes a bog standard
> relocatable image (a single contiguous blob including
> text/rodata/data/bss) that doesn't suffer from any issues when you move
> it around.
OK... Well, just to put things in perspective: the CONFIG_ZBOOT_ROM
was invented by myself almost 12 years ago. No split LMA/VMA was needed
because the code didn't use any writable global variable. The idea is
to have the boot loader branch directly to the decompressor stored in
flash (those were the days when NOR flash was more popular than NAND)
and then the decompressor simply get the deflated data directly from ROM
and stores the inflated kernel directly in RAM at its final address. No
copy what so ever was involved, and with the CPU I and D caches enabled
and burst mode properly configured in the flash you get the fastest boot
possible. At least until I added support to do eXecute-In-Place from
flash with the kernel that is (yes, I'm guilty for that as well). So
that has to continue working otherwise it is a regression.
Then, Russell added the ability for the decompressor to be PIC. And he
even managed for a ZBOOT_ROM kernel to just work if you decided to load
it in RAM and execute it from there. But for that to work the -Dstatic
hack was needed. Admitedly, this hack and the ability to run a
ZBOOT_ROM kernel from anywhere in RAM is nice but not strictly needed.
But no one could argue that this didn't work. Claiming that this is an
abuse of the compiler is beside the point: it has worked for years and
now _you_ are the one who wants to change the rules, not the GCC people.
Now I apparently missed something in the thread... What is this stack
bashing about? Admitedly I didn't look at any of the patches (yet).
Nicolas
More information about the linux-arm-kernel
mailing list