Please explain.
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.
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.
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...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
1st Old Man: Gee, its windy today.
2nd Old Man: No it's not... it's Thursday.
3rd Old Man: Yeh, me too. Let's go for a beer.
From: Li Yang-r58472 <hidden> Date: 2006-08-03 11:38:58
-----Original Message-----
From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of
Wolfgang Denk
Sent: Thursday, August 03, 2006 6:33 AM
To: McClintock Matthew-R56630
Cc: linuxppc-dev
Subject: Re: [RFC] New target 'cuImage' - compatibility uImage
=20
In message <1154552346.5550.51.camel@localhost> you wrote:
=20
Please explain.
=20
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.
=20
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 don't know if my understanding is exactly what Matt means. But the
compressed uImage seems to be (u-boot header + compress(wrapper + FDT +
kernel image)), instead of original (u-boot header + compress(kernel
image)). A better naming probably is needed to prevent misleading.
=20
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...
=20
Best regards,
=20
Wolfgang Denk
From: Matthew McClintock <hidden> Date: 2006-08-03 15:29:05
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.
Yes
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
wasteful)
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)
-Matthew
On 8/3/06, Matthew McClintock [off-list ref] wrote:
On Thu, 2006-08-03 at 00:33 +0200, Wolfgang Denk wrote:
quoted
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.
Yes
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.
quoted
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
wasteful)
quoted
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)
-Matthew
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Matthew McClintock <hidden> Date: 2006-08-03 16:02:14
On Thu, 2006-08-03 at 23:56 +0800, Li Yang wrote:
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.
This is an option. But, I do not see a reason why you would not still
opt to compress everything. Especially since it is already working.
Comments anyone?
-Matthew
On 8/4/06, Matthew McClintock [off-list ref] wrote:
On Thu, 2006-08-03 at 23:56 +0800, Li Yang wrote:
quoted
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.
This is an option. But, I do not see a reason why you would not still
opt to compress everything. Especially since it is already working.
Comments anyone?
Though it will need more space, the increase won't be too much as
wrapper and FDT should be very small. The benefit is that kernel can
be extract directly to it's destination(address 0), rather than
extract to another place and then move it there. A classical
time/space tradeoff.
From: Matthew McClintock <hidden> Date: 2006-08-03 16:24:06
On Fri, 2006-08-04 at 00:17 +0800, Li Yang wrote:
Though it will need more space, the increase won't be too much as
wrapper and FDT should be very small. The benefit is that kernel can
be extract directly to it's destination(address 0), rather than
extract to another place and then move it there. A classical
time/space tradeoff.
I'm not sure that is correct. Let me walk through the steps to verify.
1) Load cuImage at a load address
2) Extract zImage at an address and begin execution
3) Copy kernel to load address and fixup DTB, etc.
4) Start kernel execution
versus...
1) Load cuImage at a load address
2) Copy zImage to an address and begin execution
3) Extract kernel to load address and fixup DTB, etc.
4) Start kernel execution
There will always be that extra copy in there vs. just running the
zImage itself. This is to maintain compatibility with older u-boots,
which is the main point of this target.
Am I missing something here?
-Matthew
On 8/4/06, Matthew McClintock [off-list ref] wrote:
On Fri, 2006-08-04 at 00:17 +0800, Li Yang wrote:
quoted
Though it will need more space, the increase won't be too much as
wrapper and FDT should be very small. The benefit is that kernel can
be extract directly to it's destination(address 0), rather than
extract to another place and then move it there. A classical
time/space tradeoff.
I'm not sure that is correct. Let me walk through the steps to verify.
1) Load cuImage at a load address
2) Extract zImage at an address and begin execution
3) Copy kernel to load address and fixup DTB, etc.
4) Start kernel execution
versus...
1) Load cuImage at a load address
2) Copy zImage to an address and begin execution
Don't know if it's possible to by-pass this by setting in u-boot
header. If not, please ignore my suggestion.
- Leo
3) Extract kernel to load address and fixup DTB, etc.
4) Start kernel execution
There will always be that extra copy in there vs. just running the
zImage itself. This is to maintain compatibility with older u-boots,
which is the main point of this target.
Am I missing something here?
-Matthew
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Mark A. Greer <hidden> Date: 2006-08-03 19:37:49
On Thu, Aug 03, 2006 at 11:02:14AM -0500, Matthew McClintock wrote:
On Thu, 2006-08-03 at 23:56 +0800, Li Yang wrote:
quoted
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.
This is an option. But, I do not see a reason why you would not still
opt to compress everything. Especially since it is already working.
Comments anyone?
Yes...sort of. I believe that one of the goals is to be able to tack
an fdt onto a zImage/uImage/whatever long after that image has been
built. That would be simpler if the fdt wasn't compressed.
A proper tool can handle this, of course, but it would be simpler and
not a huge waste of space to keep the fdt uncompressed.
But, as long as we have tools to view and modify the fdt that in the
clump of bits, I don't really care that much.
Mark