[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