On Wednesday 26 April 2006 11:06 am, Wolfgang Denk wrote:

In message 200604261010.06536.ngustavson@emacinc.com you wrote:

...

We want to create a utiltiy to reflash a u-boot package created with mkimage through the MTD layer of uClinux.

First off, is there already have a GNUtool to do this?

No. Normally you don't use mkimage for U-Boot images.

? I did not know that. What's the recommended way?

thx, NZG

We always use just the binary image, u-boot.bin

O, not that, I'm referring to compressed uClinux packages that are created by the mkimage utility for loading with u-boot.

NZG

Best regards,

Wolfgang Denk

So what is your problem - you have the image, and want to write it to flash. Why would you need any additional tools for that?

Because I want to write it through the uClinux MTD layer, which has nothing to do with u-boot, other than the fact that the flashing utility needs to calculate a checksum and verify it against the package, which is the "ubootian" format created by mkimage.

This is really a question for both the uClinux and u-boot communities. If a section of what I'm asking does not apply to your work then please ignore it.

thank you, NZG.

Wolfgang Denk wrote:

In message 200604261502.02751.ngustavson@emacinc.com you wrote:

...

...

So what is your problem - you have the image, and want to write it to flash. Why would you need any additional tools for that?

Because I want to write it through the uClinux MTD layer, which has nothing to do with u-boot, other than the fact that the flashing utility needs to calculate a checksum and verify it against the package, which is the "ubootian" format created by mkimage.

Maybe you explain in more detail what you intend to do. I don't see why "the flashing utility needs to calculate a checksum" - the uImage file already has two checksums, so no new calculation should be needed.

We had the similar need to do this. In our software update program (which gets executed via a custom CLI/Web layer etc.) we validate the kernel+initrd in uimage format before storing in the flash. If validation fails (not a uimage file or corrupt uimage) flash is not updated and user is notified.

We do this by calculating the crc of the header comparing with stored header crc and if that checks calculating the data payload crc and comparing it with the stored payload crc in the image header. libz provides the necessary crc32() functionality in Linux.

If you use the MTD layer as a blockdevice, you will probably have a file system there; then you can just use "cp" as "flashing utility" and "mkimage -l" to verify the checksums after writing.

If you are not building images on the target mkimage is an overkill to validate the image. As a matter of fact, we do not build a cross version of this utility.

Please also consider that their is not enough space in the writable file system so image is kept in ram by the update application until update is completed. So, dependency on external utilities is not necessary or not required.

Wolfgang, now my question is "image.h" file needed by the update application and this file is GPL. Would you consider dual licensing this file only so it could be included in such a proprietary closed-source program?

Best regards, Tolunay

Wolfgang Denk wrote:

...

Wolfgang, now my question is "image.h" file needed by the update application and this file is GPL. Would you consider dual licensing this file only so it could be included in such a proprietary closed-source program?

No. But please read the file header again, more carefully.

Older copy of image.h that was used for our custom application did not have the remark below:

* NOTE: This header file defines an interface to U-Boot. Including * this (unmodified) header file in another file is considered normal * use of U-Boot, and does *not* fall under the heading of "derived * work".

Maybe you explain in more detail what you intend to do.

The target board is our SoM-5282M, http://www.emacinc.com/som/som5282em.htm which comes with U-Boot and uClinux installed on it. U-Boot has tftp capability and can access all the flash, and is fully capable of swapping out the OS image already. The uClinux build has MTD installed and can see all the external flash of the device, which is where the OS image is located. We want to add a feature to allow the module to reflash it's OS from the command line of uClinux through the MTD layer. Ideally, we would like to write the image through the MTD layer and then verify it by reading it back and making sure the image checksum matches a calculated one.

I don't see why "the flashing utility needs to calculate a checksum" - the uImage file already has two checksums, so no new calculation should be needed.

For verification during the writing process.

If you use the MTD layer as a blockdevice, you will probably have a file system there; then you can just use "cp" as "flashing utility" and "mkimage -l" to verify the checksums after writing.

If you use a character device, you can just use "cp" as "flashing utility" and "mkimage -l" to verify the checksums after writing; probably an additional step will be nedded to reead back the MTD character device in a file, making sure only the original amount of data is read back; a tiny shell script based on "ls" and "cut" and "dd" will do).

I have no idea what you could need special tools for.

It needs to be an easy to use utility (This utility could be a shell script) because we are not the ones using it, it's for the end customer, and further down the line, it's for the technicians in the field. A uClinux daemon that provided a port to do this would be even better.

I realize it's not that complicated an issue, and I could probably figure it out in an hour or two. But somebody's probably already done this, why not just ask?

...

This is really a question for both the uClinux and u-boot communities.

Actually this has nothing to do with uClinux, and very little with U-Boot.

It requires a small amount of knowlege of raw access to MTD, the format used by mkimage, and it would be nice to know I'm not reinventing the wheel. Therefore the original question was posted to the uClinux list (for MTD help) The U-Boot list (for information about the mkimage format) , and to Wildrice (general search for pre-generated scripts and utilities) I received several helpful responses. Thank you to everyone who has contributed.

NZG

And there never was an apple, in Adam's opinion, that wasn't worth the trouble you got into for eating it. -Neil Gaiman

Maybe before asking for free help here you should feed your patches back into the public tree.

My work was based on Zachary P. Landau's, which was rejected from the main tree because of the way it modified the core flash code. I fed all my work back to him and try to help with any 5282 stuff I can on the list. I'm not asking for anything that I don't give out myself on the Coldfire/U-Boot lists.

...

It requires a small amount of knowlege of raw access to MTD, the format used

This is standard Linux stuff and not uClinux specific.

Technically true, but I don't know of any lists that would be more likely to know the answer.

You don't need to know the mkimage format, as the mkimage tool is perfectly capable of reading and checking such images.

Sounds good, it just isn't obvious to me since mkimage -l was verifying the checksum, since it doesn't display an checksum information. Now that you've said it, I see it in the README.

thx, NZG

In message 20060428034515.7523.qmail@web15904.mail.cnb.yahoo.com you wrote:

I also haven't seen mkimage -l displaying checksum info. Is mkimage I used out of date?

mkimage does not display the checksum, but it checks it, and you get error messages and appropriate exit code in case of error.

Best regards,

Wolfgang Denk

In message 20060428070721.31282.qmail@web15909.mail.cnb.yahoo.com you wrote:

...

mkimage does not display the checksum, but it checks it, and you get error messages and appropriate exit code in case of error.

That's not enough in some cases. Factory engineers need CRC32 checksum of a ROM image for programming

Both of the checksums stored with the U-Boot image are internal checksums, which are computed over certain areas in the image. None of these checksums is goot for use with a programmer.

On the other hand, all programmers I know are capable of computing the checksum themself.

verfication. Besides,a stuff like U-Boot/Kernel/ Rootfs combination cannot be checked by mkimage -l.

Obviously not. But nobody ever clamined that.

So seems an utility which can check the image's CRC32 checksum is better. I used to download the stuff to RAM in u-boot and got the result with crc32 command:-)

You have different purposes, so other tools are more appropriate for you. But these tools also exist, i. e. there is no need to write any new code.

Best regards,

Wolfgang Denk

In message 44523A5D.1040201@orkun.us you wrote:

It does not print crc. Inspecting code quickly, it only displays crc **Warning** if there is mismatch but proceeds after that as if nothing has happened. So, it was not suitable for the task anyhow.

Argh... Thanks for using past tense. Yes, it is fixed *now*.

I think -v option can be added to verify the integrity of archive and return 0 [OK] or an shell error code so it could be used in a shell script properly.

No. Image verification is already done, just the error handling was missing. Fixed now.

Best regards,

Wolfgang Denk