[U-Boot] [PATCH V3] BOOT: Add "bootz" command to boot Linux zImage

[Graeme Russ]

Hi Marek,

On Tue, Mar 13, 2012 at 3:50 PM, Marek Vasut <marex at denx.de> wrote:
> Dear Wolfgang Denk,
>
>> Dear Marek Vasut,
>>
>> In message <201203130113.19092.marex at denx.de> you wrote:
>> > > + zi = (struct zimage_header *)images->ep;
>> > > +
>> > > + if (zi->zi_magic != LINUX_ARM_ZIMAGE_MAGIC) {
>> >
>> > This gave me an idea ... this might be how to check for zImage inside
>> > bootm and be done with it. Simply squash those two together.
>>
>> Hm... but this must not be the only test, then, or you will run the
>> risk of false positives...
>
> Certainly.
>
>>
>> > > Do we have to care about endianess here?
>> >
>> > We should make bootz arm-specific until more people (with different
>> > arches) step up and verify it works for them.
>>
>> NAK.  Please implement in an architecture independent way right from
>> the beginning.
>
> Can someone tell if the the zImage format differs per-arch or is it the same?
> Graeme, what is it about that x86 stuff?

Do you really want to know? How long have you got ;)

There are three options:
 1 Keep the kernel packaged up in the bzImage
 2 Extract the 'header' externally to U-Boot and put it, the corresponding
   vmlinux (compressed) and an initrd (compressed) in a uImage
 3 Extract the 'header' and vmlinux from a bzImage within U-Boot

Option 1 means I have to keep the crappy 16-bit Real Mode BIOS stub in
U-Boot which is a PITA. It also means more memory copy operations to get
the kernel up and running - I've spoken to Gabe Black who did the coreboot
patches for U-Boot and he is fine with us dropping this (his patches added
code to bypass it anyway)

Option 2 is messy

Option 3 is nice - If you have enough onboard NAND flash, you can but the
bzImage there and decompress it straight to its 'in RAM' resting place.
Boot times are brutal!

I may be wrong, but I zImages are generally a header followed by a
compressed vmlinux (x86 has a built-in decompression stub). So if the
U-Boot zImage code called an arch-specific function that passed in the
location of the (b)zImage and reference variables for the:

 - Location of the compressed vmlinux
 - Compression algorith used to compress vmlinux (although U-Boot could
   figure this out from the first few bytes)
 - Length of the compressed data
 - Length of the decompressed data (if known)

And a functions to process the header, command line, initrd etc I think
we would have an arch-neutral way forward

Regards,

Graeme