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

Nicolas Pitre
2011-11-08T03:51:33Z

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.

> 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