[RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Mark A. Greer]

On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> > David Gibson wrote:
> > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:

> > Looking deeper at this I've found that currently u-boot thinks that 
> > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ 
> > defined as (8 << 20)), although all physical memory is identity mapped. 
> > That's why it puts command line and board info structure as high as 
> > possible within the first 8MB. This worked fine with uImage, since 
> > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher 
> > (we need space at the start of the memory to eventually put vmlinux 
> > image there). So, if unpacked kernel image crosses 8MB boundary, it gets 
> > damaged by u-boot when it prepares cmd_line and bdinfo. The possible 
> > workaround for that is to always link zImage at >=8MB base or to have 
> > 4MB granularity like this:
> > 
> > +  . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
> > 
> > Reserve at least 64K for u-boot cmd_line and bdinfo.
> 
> Ah.  Right.  That makes things a bit tricky.  Even this 4MB
> granularity may not be enough (say, if the vmlinux is < 4MB, but the
> zImage has a really big initrd and is > 4MB).
> 
> Except... it shouldn't really be the link address that matters.  The
> zImage is relocatable, so it should only be the load address specified
> in the uImage header which matters.  I think that's currently derived
> from the link address, but it doesn't have to be.

Having the link address jump around depending on the size of the kernel
or zImage is wrong IMHO.  It just screams "weird can't boot issues."
We need a way to specify exactly where we want the zImage linked no
matter what the kernel or zImage size.

Also, being able to control the link address (that is, the download
address with some firmwares) is not a u-boot specific issue and we
shouldn't make a u-boot specific solution.

The more general problem is that some firmwares examine the ELF header
and download the zImage to address it was linked at.  Some firmwares let
you override this but some don't and those are the problem ones.

We talked about this a bit back in February,
http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html

In that thread Geoff Levand suggested a config option and running it
thru a preprocessor.  David Gibson suggested making a replaceable linker
script.  I suggested passing the value of a config option to the wrapper
script which would use objcopy/whatever to change the section addresses
in the image (maybe this is what Geoff had in mind, I'm not sure).

I still like my idea best.  I haven't coded yet it so I don't have a patch
but this is what I mean:

1) add a config option (default 4MB) for the link address
2) add a parameter to the wrapper script thru which we pass the value in
   the config option
3) the wrapper script changes the VMA/LMA to the address specified
   (objcopy --change-addresses=<some math to get correct incr> ?).

I'll code it up in the next day or two unless someone doesn't like the idea.

Mark