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

[Jason]

Nicolas,

On Mon, Nov 07, 2011 at 10:51:33PM -0500, Nicolas Pitre wrote:
> 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.

exactly, see my comments below.

> > 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.

It sounds like you are intending for distributions to provide uImages.
Why can't they provide a generic zImage, and a post-install hook runs
mkimage to add the board specific uImage header?  Similar to update-grub
on x86{_64}.  This seems _more_ flexible to me, and fitting with
standard conventions distributions are accustomed to.

eg, after a kernel upgrade on a debian system, since I had 'apt-get
install u-boot' there is a post-kernel install hook that would run a
distro provided 'update-uboot' script.  This script would read a board
specific config file (or, the u-boot environment), add the u-boot header
to the kernel, and possibly modify the u-boot environment to now load
uImage-3.1-34.  The file shipped with the kernel image package was a
generic zImage which will now work on the board.

Or, maybe I'm missing something...  I always thought 'make uImage' was
a convenience for developers.

hth,

Jason.