Hi Wolfgang,
On Tue, Mar 13, 2012 at 3:30 PM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message CALButCLDyKZnsZqGXhxcu-UEv9nySg77f1XwaUvmgb9gc7BPNQ@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 ;)
Regards,
Graeme