From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Wed, 28 Feb 2007 08:51:12 -0500 Subject: [U-Boot-Users] RFC: extended image formats In-Reply-To: <20070227222912.902CB352B86@atlas.denx.de> References: <20070227222912.902CB352B86@atlas.denx.de> Message-ID: <45E588D0.5000305@smiths-aerospace.com> 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: > Hello, > > I'm trying to figure out what could be done to add (at least in some > cases) more information to U-Boot images. > > In this case, the existing CRC32 checksum is not sufficient; > therequirement is to use some stronger hashes (md5 or sha1) to verify > the correctness of the kernel and file system images. > > A similar thing happened not so long ago when we discussed how to add > the OFT blob. > > Here some thoughts: > > * The original 64 byte header is tabu and cannot be changed to provide > compatibility to existing versions. > > * A quick & dirty hack could use a multi-file image to add - for > example - the SHA1 checksum as separate image in addition to the > kernel (and eventually file system) image(s). > > Add an OFT blob, and the confusion is perfect. > > Seems we need a more structured approach. > > I would like to use this opportunity to collect ideas and suggestions > for a more generalized solution that is flexible and extensible > enough to handle not only the current , but also future requirements. > At least some of them ;-) > > All input welcome... > > Best regards, > > Wolfgang Denk Two possibilities come to mind for using (abusing) the original 64 byte header: 1) If we put an ASCII-hex hash _as_ the name, we could support a 16 byte (128 bit) hash. The name would no longer be pronounceable :-P, but it _would_ be unique. An MD5 hash is typically a 32-character hexadecimal number. [Ref: ] 2) The name is 32 bytes. If we trimmed the maximum name length to 28 bytes, we could use the last 4 bytes as a pointer to a hash. Bleah, not much/any better than the multi-file approach. gvb