From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Tue, 13 Mar 2012 15:46:41 +1100 Subject: [U-Boot] [PATCH V3] BOOT: Add "bootz" command to boot Linux zImage In-Reply-To: <20120313043053.22918202BE6@gemini.denx.de> References: <1331588061-21546-1-git-send-email-marex@denx.de> <201203122308.54249.marex@denx.de> <20120312224255.5FD0F202F14@gemini.denx.de> <201203130113.19092.marex@denx.de> <20120313043053.22918202BE6@gemini.denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, On Tue, Mar 13, 2012 at 3:30 PM, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message 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