[U-Boot-Users] Accessing mkimage checksum

[U-Boot-Users] Accessing mkimage checksum

[NZG]

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?

If not, what is the offset of the checksum in a package made by mkimage?

thx,
NZG

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

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.

> If not, what is the offset of the checksum in a package made by mkimage?

Please see include/image.h

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is easier to change the specification to fit the program than vice
versa.

[U-Boot-Users] Accessing mkimage checksum

[NZG]

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

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

In message <200604261111.36438.ngustavson@emacinc.com> you wrote:
>
> What's the recommended way?

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

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
365 Days of drinking Lo-Cal beer.                       = 1 Lite-year

[U-Boot-Users] Accessing mkimage checksum

[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

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

In message <200604261420.49711.ngustavson@emacinc.com> you wrote:
> > 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.

Then please write that you are talking about Linux images next time.

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?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)

[U-Boot-Users] Accessing mkimage checksum

[NZG]

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

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

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.

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.

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

> If a section of what I'm asking does not apply to your work then please ignore 
> it. 

You post her, I reply here.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If there was anything that depressed him more than his own  cynicism,
it was that quite often it still wasn't as cynical as real life.
                                 - Terry Pratchett, _Guards! Guards!_

[U-Boot-Users] Accessing mkimage checksum

[Tolunay Orkun]

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

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

In message <444FE313.2090609@orkun.us> you wrote:
>
> 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 

Yes, of course. Thisi s a perfectly valid request. But you don't need
no special tools for this. A simple "mkimage -l" will do this.

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

You just reinvented another wheel.

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

So how big is "mkimage" on your system? For PowerPC I get:

	-> ls -lh mkimage
	-rwxr-xr-x  1 wd users 18K Apr 27 00:26 mkimage

18 kB... How big is your custom application, and how much memory  did
you save?

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

If you can keep it in RAM, you could use a tmpfs and operate on files
as well. You probably could have used other standard  tools  then  as
well.

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

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Heavier than air flying machines are impossible.
                    -- Lord Kelvin, President, Royal Society, c. 1895

[U-Boot-Users] Accessing mkimage checksum

[Tolunay Orkun]

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

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

In message <4450051C.5070309@orkun.us> you wrote:
>
> Older copy of image.h that was used for our custom application did not 
> have the remark below:

Then you must update U-Boot ...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Everybody is talking about the  weather  but  nobody  does  anything
about it."                                               - Mark Twain

[U-Boot-Users] Accessing mkimage checksum

[NZG]

> 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 

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

In message <200604270900.14579.ngustavson@emacinc.com> you wrote:
>
> The target board is our SoM-5282M, 
> http://www.emacinc.com/som/som5282em.htm

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

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

You don't want to verify this  "during  the  writing  process".  This
makes  no  sense. You probably want to verify it *before* erasing the
image in flash (so that you keep the old image if the downloaded  one
was  corrupt),  and *after* writing has completed (so you can be sure
that the flash content is ok).

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

"mkimage" is trivial to use. It just requires the "-l" option  and  a
file name argument.

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

I just told you: this *has* been solved. "mkimage" perfectly does the
job. No new code is needed.

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

This is standard Linux stuff and not uClinux specific.

> by mkimage, and it would be nice to know I'm not reinventing the wheel.

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

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human mind treats a new idea the way the body  treats  a  strange
protein - it rejects it.                                 - P. Medawar

[U-Boot-Users] Accessing mkimage checksum

[NZG]

> 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

[U-Boot-Users] Accessing mkimage checksum

[Sam Song]

NZG <ngustavson@emacinc.com> wrote:
> 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.

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

# tools/mkimage -l /tftpboot/uImage
Image Name:   Linux-2.4.23
Created:      Tue Dec 20 16:58:58 2005
Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
Data Size:    1442558 Bytes = 1408.75 kB = 1.38 MB
Load Address: 0x00000000
Entry Point:  0x00000000
#

Thanks in advance,

Sam


	

	
		
___________________________________________________________ 
??1G??????????? 
http://cn.mail.yahoo.com/

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Life and death are seldom logical."
"But attaining a desired goal always is."
	-- McCoy and Spock, "The Galileo Seven", stardate 2821.7

[U-Boot-Users] Accessing mkimage checksum

[Sam Song]

Wolfgang Denk <wd@denx.de> 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 
verfication. Besides,a stuff like U-Boot/Kernel/
Rootfs combination cannot be checked by mkimage -l. 

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:-)

Thanks,

Sam


	

	
		
___________________________________________________________ 
??1G??????????? 
http://cn.mail.yahoo.com/

[U-Boot-Users] Accessing mkimage checksum

[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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Drun'? 'm not drun'! You woudn' dare call m' drun' if I was sober!
                                     - Terry Pratchett, _Men at Arms_

[U-Boot-Users] Accessing mkimage checksum

[Wolfgang Denk]

In message <20060428080933.11288.qmail@web15903.mail.cnb.yahoo.com> you wrote:
> 
> Ummm, the rule is that you should provide the
> crc32 checksum first to check before sending
> it out. Some unexpection would happen to the 
> file via email or transferring process. This
> is also true for md5sum file for download
> cases:-)

I don't think that crc32 is a good  choice  for  such  purposes.  But
YMMV.

I think we should stop this discussion now. It is off topic anyway.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perl itself is  usually  pretty  good  about  telling  you  what  you
shouldn't do. :-)     - Larry Wall in <11091@jpl-devvax.JPL.NASA.GOV>

[U-Boot-Users] Accessing mkimage checksum

[Tolunay Orkun]

Sam Song wrote:
> NZG <ngustavson@emacinc.com> wrote:
>> 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.
> 
> I also haven't seen mkimage -l displaying checksum
> info. Is mkimage I used out of date?
> 
> # tools/mkimage -l /tftpboot/uImage
> Image Name:   Linux-2.4.23
> Created:      Tue Dec 20 16:58:58 2005
> Image Type:   PowerPC Linux Kernel Image (gzip
> compressed)
> Data Size:    1442558 Bytes = 1408.75 kB = 1.38 MB
> Load Address: 0x00000000
> Entry Point:  0x00000000
> #
> 
> Thanks in advance,
> 
> Sam
> 

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.

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.

Best regards,
Tolunay

[U-Boot-Users] Accessing mkimage checksum

[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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's not an optical illusion, it just looks like one.   -- Phil White

[U-Boot-Users] Accessing mkimage checksum

[Sam Song]

Wolfgang Denk <wd@denx.de> wrote:
> Argh... Thanks for using past tense. Yes, it is
> fixed *now*.

Oops... So quick the fix was. Great!

Sam


		
___________________________________________________________
 
?????????????