From mboxrd@z Thu Jan 1 00:00:00 1970 From: Txema Lopez Date: Wed, 28 Feb 2007 16:40:15 +0100 Subject: [U-Boot-Users] RFC: extended image formats In-Reply-To: <45E588D0.5000305@smiths-aerospace.com> References: <20070227222912.902CB352B86@atlas.denx.de> <45E588D0.5000305@smiths-aerospace.com> Message-ID: <45E5A25F.6020307@aotek.es> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Jerry Van Baren wrote: >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 > > What about an image tail?. The last 2 longs of the name could be changed by: u32 tail_magic_number; /* A magic number to detect an image with a tail */ u32 tail_offset; /* Offset to the tail from the image header */ The tail structure will add the new information for the next versions of U-Boot. -------------- next part -------------- A non-text attachment was scrubbed... Name: tlopez.vcf Type: text/x-vcard Size: 324 bytes Desc: not available Url : http://lists.denx.de/pipermail/u-boot/attachments/20070228/058394bc/attachment.vcf