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

[Simon Glass]

Hi Nicolas,

On Mon, Nov 7, 2011 at 7:51 PM, Nicolas Pitre <nico at fluxnic.net> 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.
>
>> 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.

Actually I was talking about the case where U-Boot does the
decompression. You have said it is supported above. I don't suggest
that it be the only option, only that it be an option. Perhaps only
U-Boot will use it, but that is fine. U-Boot is a popular boot loader.

If the boot loader puts the pieces in the right place, decompressed
and ready to go, we could presumably avoid this code in the kernel:

 1096  4860 27129 arch/arm/boot/compressed/head.S
   13    53   304 arch/arm/boot/compressed/big-endian.S
   50   153  1267 arch/arm/boot/compressed/decompress.c
 1096  4860 27129 arch/arm/boot/compressed/head.S
   47   214  1238 arch/arm/boot/compressed/head-sa1100.S
  139   650  3537 arch/arm/boot/compressed/head-shark.S
  150   619  3564 arch/arm/boot/compressed/head-sharpsl.S
   53   263  1685 arch/arm/boot/compressed/head-shmobile.S
   41   179   992 arch/arm/boot/compressed/head-xscale.S
  134   571  2868 arch/arm/boot/compressed/ll_char_wr.S
  124   324  3011 arch/arm/boot/compressed/Makefile
  208   589  3812 arch/arm/boot/compressed/misc.c
  260   604  5289 arch/arm/boot/compressed/ofw-shark.c
    6    10   145 arch/arm/boot/compressed/piggy.gzip.S
    6    10   145 arch/arm/boot/compressed/piggy.lzma.S
    6    10   144 arch/arm/boot/compressed/piggy.lzo.S
   70   226  1481 arch/arm/boot/compressed/vmlinux.lds.in
 2403  9335 56611 total

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

Yes, although one way for the boot loader to do that is to use mkimage
to create a FIT image with the kernel and the DTB file. Can the kernel
better facilitate that?

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

Quite agree with the latest patch - I tested it.

That gives the kernel what it wants. How can we give U-Boot what it
wants, which is apparently the ability to decompress the kernel itself
and arrange everything in memory at the right place? Wolfgang
complains that patches to do this have been repeatedly rejected in the
kernel. If this is the FIT image, how about adding a 'fitImage' make
target?

These are the targets I can see in the kernel:

Architecture specific targets (arm):
* zImage        - Compressed kernel image (arch/arm/boot/zImage)
  Image         - Uncompressed kernel image (arch/arm/boot/Image)
* xipImage      - XIP kernel image, if configured (arch/arm/boot/xipImage)
  uImage        - U-Boot wrapped zImage
  bootpImage    - Combined zImage and initial RAM disk
                  (supply initrd image via make variable INITRD=<path>)
  dtbs          - Build device tree blobs for enabled boards
  install       - Install uncompressed kernel
  zinstall      - Install compressed kernel
                  Install using (your) ~/bin/installkernel or
                  (distribution) /sbin/installkernel or
                  install to $(INSTALL_PATH) and run lilo

There doesn't seem to be a FIT image, but yet this is the 'modern'
image format in U-Boot. It seems odd that uImage says 'U-Boot wrapped
zImage' which suggests that it cannot support U-Boot decompressing the
image.

There seems to be a discussion about it here:

http://permalink.gmane.org/gmane.linux.kbuild.devel/4345

Regards,
Simon

>
>
> Nicolas
>