public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tolunay Orkun <listmember@orkun.us>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Accessing mkimage checksum
Date: Wed, 26 Apr 2006 16:16:03 -0500	[thread overview]
Message-ID: <444FE313.2090609@orkun.us> (raw)
In-Reply-To: <20060426201415.427F9353AC4@atlas.denx.de>

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

  reply	other threads:[~2006-04-26 21:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-26 15:10 [U-Boot-Users] Accessing mkimage checksum NZG
2006-04-26 16:06 ` Wolfgang Denk
2006-04-26 16:11   ` NZG
2006-04-26 19:11     ` Wolfgang Denk
2006-04-26 19:20       ` NZG
2006-04-26 19:26         ` Wolfgang Denk
2006-04-26 20:02           ` NZG
2006-04-26 20:14             ` Wolfgang Denk
2006-04-26 21:16               ` Tolunay Orkun [this message]
2006-04-26 22:33                 ` Wolfgang Denk
2006-04-26 23:41                   ` Tolunay Orkun
2006-04-27  7:26                     ` Wolfgang Denk
2006-04-27 14:00               ` NZG
2006-04-27 14:58                 ` Wolfgang Denk
2006-04-27 15:48                   ` NZG
2006-04-28  3:45                     ` Sam Song
2006-04-28  6:45                       ` Wolfgang Denk
2006-04-28  7:07                         ` Sam Song
2006-04-28  7:38                           ` Wolfgang Denk
2006-04-28 15:53                       ` Tolunay Orkun
2006-04-28 19:23                         ` Wolfgang Denk
2006-04-29  1:22                           ` Sam Song
     [not found] <20060428080933.11288.qmail@web15903.mail.cnb.yahoo.com>
2006-04-28  9:54 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=444FE313.2090609@orkun.us \
    --to=listmember@orkun.us \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox