New target 'cuImage' - compatibility uImage

And the new cuImage will look like this:

-------------------------------------

(quoted diff) +0 -5

-	compressed uImage	  - -
- ------------------------------- - -
- - 	_start			- - -
- -	boot wrapper code	- - -
- - ----------------------------- - -

-----Original Message-----
From: [email protected] [mailto:[email protected]] On =

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

Quoted 9 lines · In message <1154552346.5550.51.camel@localhost> you wrote:

And the new cuImage will look like this:

-------------------------------------

(quoted diff) +0 -5

-	compressed uImage	  - -
- ------------------------------- - -
- - 	_start			- - -
- -	boot wrapper code	- - -
- - ----------------------------- - -

Review

Quoted 10 lines

(quoted diff) +0 -10

- - -	device tree	      	- - -
- - ----------------------------- - -
- - ----------------------------- - -
- - - 			      	- - -
- - - 	UNcompressed	      	- - -
- - - 	kernel image	      	- - -
- - -			      	- - -
- - ----------------------------- - -
- --------------------------------- -
-------------------------------------

=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.

=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

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...

Quoted 4 lines · Wolfgang Denk

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

Quoted 5 lines

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 5 lines

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
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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 6 lines · Li Yang

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

Quoted 3 lines

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

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.

Quoted 7 lines · Li Yang

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

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

Both approaches seem broken to me.

You should make sure that your bootstrap code comes *after* the kernel image, so you can load the whole blob at address 0x0000 (mkimage option "-a 0") while starting it at the bootstrap entry point (mkimage option "-e <your_address>").

This way U-Boot will load (and if necessary uncompress) the kernel image plus your attached bootstrap code to it's normal start address. Then it starts your bootstrap code which can fixup DTB and then just start the kernel.

Please avoid any aditional memory copy. It's not necessary.

However, currently the zImage has an elfheader which will come before

Quoted 5 lines

This way U-Boot will load (and if necessary uncompress) the kernel image plus your attached bootstrap code to it's normal start address. Then it starts your bootstrap code which can fixup DTB and then just start the kernel.

We do not need to worry about this with cuImage because the kernel section will not be compressed. If compression is desired it will be done at the U-Boot level (were U-Boot would do the uncompressing).

Quoted 2 lines · In message <1154636438.5094.45.camel@localhost> you wrote:

However, currently the zImage has an elfheader which will come before

May it have whatever it wants. It's irrelevant.

WE DO NOT USE zImage FILES FOR U-BOOT.

Quoted 7 lines

Quoted 6 lines

This way U-Boot will load (and if necessary uncompress) the kernel image plus your attached bootstrap code to it's normal start address. Then it starts your bootstrap code which can fixup DTB and then just start the kernel.

Quoted 3 lines

We do not need to worry about this with cuImage because the kernel section will not be compressed. If compression is desired it will be done at the U-Boot level (were U-Boot would do the uncompressing).

Yes, we do need to care about this. A useless copy of the uncompressed kernel image is just a waste of boot time. Not to mention that you have to copy your bootstrapo loader out of the way before it gets overwritten.

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.

Quoted 6 lines · Li Yang

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

Quoted 3 lines

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?

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.

Quoted 4 lines

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

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)

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)

Quoted 1 line

So to clarify. The current method has a zImage with a compressed

kernel

No, it does not. We do not use zImage (which includes bootstrap wrapper code). U-Boot uses a plain stripped and compressed kernel image, i. e. something like this:

objcopy -O binary vmlinux vmlinux.bin
gzip -f -9 <vmlinux.bin >vmlinux.gz
mkimage ... -C gzip -d vmlinux.gz uImage

I'm referring to the zImage target as what the current method does. My

The zImage can have a compressed kernel section or an uncompressed

As a side note, the final cuImage (which is a U-Boot image) can be either compressed or uncompressed. That is irrelevant. The major point is the kernel section within the cuImage is not compressed, and the final cuImage is in fact a U-Boot image which can be started with the 'bootm' command from within U-Boot.

Quoted 1 line

I'm referring to the zImage target as what the current method does.

My

This is highly confusing. zImage is a special make target, which has NOTHING to do with U-Boot. Please don't use this name in the U-Boot context unleass you really mean it.

Quoted 1 line

The zImage can have a compressed kernel section or an uncompressed

I stop parsing here. zImage has *nothing* to do with this topic.

On Wed, Aug 02, 2006 at 03:59:06PM -0500, Matthew McClintock wrote:

[snip]

arch/powerpc/Makefile # Default to zImage, override when neede · line 144

Quoted 9 lines

arch/powerpc/Makefile +1 -0

index 01667d1..eefbe16 100644
@@ -141,12 +141,13 @@ # Default to zImage, override when neede
 defaultimage-y			:= zImage
 defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
 defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
+defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage

This means we never default to a regular 'uImage', and should either modify the existing line, or a DEFAULT_CUIMAGE. No preference/etc, just noting.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On =

Matthew McClintock
Sent: Thursday, August 03, 2006 4:59 AM
To: linuxppc-dev
Subject: [RFC] New target 'cuImage' - compatibility uImage =20
Hi all,
=20
The following is a patch which creates a new target called 'cuImage'.

is designed to correctly package the kernel along with the 'arch/powerpc/boot' wrapper code into a uImage to be loaded and

by U-Boot.
=20
The purpose of this target is to allow boards with older versions of U-Boot to utilize the 'bootm' command within U-Boot to run new powerpc kernels. The bootwrapper will begin execution and can correctly setup

flat device tree based on values passed in the bd_t structure,

old versions of U-Boot are not capable of.
=20
One might ask why not just use the 'bootelf' command in u-boot. Well, not all boards have that option compiled in, and some other boards

not even have access to the console. Also, the bd_t structure is not passed from U-Boot when using the bootelf command so we would have no method to correctly fill in values in the device tree. This would theoretically allow an old board to start a new kernel without access

the console if required.
=20
Currently the zImage looks like this:
=20
---------------------------------

(quoted diff) +0 -12

- 	_start			-
-	boot wrapper code	-
- ----------------------------- -
- -	device tree	      - -
- ----------------------------- -
- ----------------------------- -
- - 			      - -
- - 	compressed	      - -
- - 	kernel image	      - -
- -			      - -
- ----------------------------- -
---------------------------------

=20
And the new cuImage will look like this:
=20
-------------------------------------

(quoted diff) +0 -15

-	compressed uImage	  - -
- ------------------------------- - -
- - 	_start			- - -
- -	boot wrapper code	- - -
- - ----------------------------- - -
- - -	device tree	      	- - -
- - ----------------------------- - -
- - ----------------------------- - -
- - - 			      	- - -
- - - 	UNcompressed	      	- - -
- - - 	kernel image	      	- - -
- - -			      	- - -
- - ----------------------------- - -
- --------------------------------- -
-------------------------------------

=20
-Matthew
=20

If my understanding to Matt's idea is correct, it will be a good way, IMHO. How about use the naming of uwImage(U-boot Wrapped Image) or utImage(u-boot device-Tree Image).