[U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address

[Nicolas Pitre]

On Mon, 7 Nov 2011, Simon Glass wrote:

> On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> 
> > On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> >
> >> Dear Nicolas Pitre,
> >>
> >> > We don't want any hardcoded architecture specific address anymore.
> >> > This is being removed from the kernel as we speak.  If I cannot use a
> >>
> >> Also for raw images?
> >
> > No.  The requirements on raw images are unchanged.  you can use them if
> > you wish, but generic ARM distributions can't use that if they want to
> > target more than one SOC.  Therefore raw images are not interesting by
> > the use case at hand.
> 
> I will leave you to your discussion, but want to pick up on this point.
> 
> Can I assume that we have (or can have) a 'make uImage' target or
> similar in the kernel which can pack together:
> 
> - a compressed kernel (not zImage, I mean something that U-Boot can
> decompress), with a rel_offset of 32KB

Yes.

> - a DTB

No.

> - a ramdisk

No.  However you can provide a set of files which can be included in an 
initramfs image linked directly into the kernel.  But distributors never 
use that facility as they prefer a customized ramdisk created during 
kernel installation.

> and that with Stephen's patch (committed to U-Boot) today, we can, in
> U-Boot, with a script, load this uImage to somewhere and have U-Boot
> decompress the kernel and set the bits out nicely in RAM, no matter
> where that RAM is? The kernel will start at 32KB, and the other bits
> will be somewhere above that. Then U-Boot can enter the kernel at 32KB
> and all will be well, yes?
> 
> Because it seems to me that this approach would work just as well as
> the zImage approach (it is perhaps more 'pure' from a boot loader
> point of view), and that the code in the kernel zImage header that
> figures out where SDRAM is and decompresses the kernel to 32KB could
> just as well be in U-Boot.

Firstly, there is not just u-Boot out there.  And since the layout 
optimization for Linux when decompressing is by definition Linux 
specific, this better live in zImage than be duplicated in every 
bootloaders.

Secondly, we don't want to pack a DTB with the kernel.  For the same 
reasons as for the load address, we want a distributable kernel binary 
which contains no assumption about any specific board or machine.  The 
kernel should be generic and be provided a machine specific DTB by the 
boot loader.

> Then both groups get what they want.

No.  For both groups to get what they want, Stephen's latest patches 
should be merged.  All they do is to allow for -1 as a load address in 
uImage to mean "never relocate but just use whatever address where 
uImage has been loaded."  This cannot be simpler than that.


Nicolas