[PATCH] Clean up ARM compressed loader
Nicolas Pitre
nico at fluxnic.net
Wed Feb 24 18:34:49 EST 2010
On Wed, 24 Feb 2010, Russell King - ARM Linux wrote:
> On Wed, Feb 24, 2010 at 03:23:37AM +0100, Hector Martin wrote:
> > Instead, clean up the stub loader and unify it. The loader is now
> > exactly the same regardless of whether you've enabled CONFIG_ZBOOT_ROM
> > or not, and runs from RAM in PIC mode. CONFIG_ZBOOT_ROM simply enables
> > an extra section of stub code that lets the zImage boot from ROM by
> > copying itself to RAM first.
>
> Unacceptable.
>
> The point of putting the decompressor in ROM is to save the time spent
> copying it to RAM first. Boot loaders are already perfectly capable
> of copying the image into RAM and calling it there.
>
> Getting the decompressor to do that step first just moves the copy from
> the boot loader into the decompressor. It doesn't eliminate it, which
> is what ROM-based decompression is all about.
>
> Basically, this patch makes the feature entirely pointless.
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.
The idea with ZBOOT_ROM is also to have an empty .data section so there
is no data segment to copy. This is achieved by not having any writable
global variable nor static local variables (unless they're marked const
of course). We probably should add an assert statement in the linker
script to ensure this is the case.
Nicolas
More information about the linux-arm-kernel
mailing list