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

Jason
2011-11-08T14:52:52Z

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