From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tolunay Orkun Date: Wed, 26 Apr 2006 16:16:03 -0500 Subject: [U-Boot-Users] Accessing mkimage checksum In-Reply-To: <20060426201415.427F9353AC4@atlas.denx.de> References: <20060426201415.427F9353AC4@atlas.denx.de> Message-ID: <444FE313.2090609@orkun.us> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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