[RFC] New target 'cuImage' - compatibility uImage
LeoLi at freescale.com
Fri Aug 4 01:56:52 EST 2006
On 8/3/06, Matthew McClintock <msm at freescale.com> wrote:
> On Thu, 2006-08-03 at 00:33 +0200, Wolfgang Denk wrote:
> > In my understanding, an "uImage" file is a image consisting of an
> > U-Boot header (64 bytes) followed by an (compressed or uncompressed)
> > Linux kernel image.
If U-boot supports uncompressed kernel image in uImage, I think it
will be better to use this scheme:
u-boot header + wrapper + FDT + compressed kernel image
As kernel image will be uncompressed to its loading address directly.
While in your proposal, it needs to be moved one more time.
> > So what do you mean by "compressed uImage"? If you take an "uImage"
> > file according to above definition and compress it, it will not be
> > recognized by U-Boot.
> I mean that the data contained within the uImage is compressed. In this
> case where the uImage data is compressed I choose to skip compressing
> the kernel section in the zImage (because have it compressed twice was
> > And why do you need a second, "UNcompressed kernel image" in your
> > setup? I must be missing something, because including *two* kernel
> > images makes no sense to me, and I don't understand why you would
> > want to insist of an "UNcompressed" image...
> So to clarify. The current method has a zImage with a compressed kernel
> section where the actual kernel lives. The zImage uncompressed this code
> to the kernel load address. The 'cuImage' would be packaged in a uImage
> with the entire zImage compressed, except in this case the kernel
> section would not be compressed (to avoid have a compressed image within
> a compressed image)
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
More information about the Linuxppc-dev