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

Graeme Russ graeme.russ at gmail.com
Tue Mar 13 05:46:41 CET 2012

Hi Wolfgang,

On Tue, Mar 13, 2012 at 3:30 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme Russ,
> In message <CALButCLDyKZnsZqGXhxcu-UEv9nySg77f1XwaUvmgb9gc7BPNQ at mail.gmail.com> you wrote:
>> While we are on the subject - Do either of you think support for the x86
>> zimage/bzImage format should end up here in common code? Not that the x86
> The common coe should be architecture-neutral.  It might cann
> architecture-specific routines, which may (or may not) get added
> later, depending if somebody cares about adding such support.
>> (b)zImage header is unique (see arch/x86/include/asm/bootparam.h) and
>> decompressing vmlinux out of an x86 (b)zImage is non-trivial given the
>> header and decompression stub
> I have to admit that I never understood the fuzz about being able to
> boot zImages.  I see more disadvanatges than advantages for this, but

Ah grasshopper - remember from whence Linux evolved ;)

Bootable zImage for x86 came from the desire to write the image to a
floppy (using dd) and have it boot. This was way before GRUB and LILO

I remember the days of the kernel on one floppy and the root fs on a
second floppy and you would be prompted to change disks :)

And then the kernel grew too big, so it got compressed and to still
allow booting from a floppy, the decompression stub was added to the
kernel image

And then came loadlin so you could boot linux from DOS (or Winodws)
and the header was used to tell loadlin where to load the kernel in
memory - but the decompression routine was already in the zImage and
DOS ran in real-mode so there was no need to change how it booted

And then the kernel grew some more and the limitations of the zImage
format were reached - bzImage (Big zImage) format was born, but the
header and decompression stub pretty much remained intact so existing
bootloaders did need to jump through hoops to handle the change

And in the mix is loadable modules and initial ram disks et al.

And then someone decided it would be a pretty neat idea to shove linux
into a tiny little box running an ARM processor :P

> some ARM people go frenzy when this topic pops up - see recent
> discussions about removal of uImage support on the AKML.
> Frankly: I see no benefit in adding x86 support.

Ouch! - Do you mean in common code or in general?

> I see no benefit in adding ARM support either, but YMMV...

Hmm, methinks the Android guys might have a bone to pick with that
statement ;)



More information about the U-Boot mailing list