From: Txema Lopez <tlopez@aotek.es>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] RFC: extended image formats
Date: Wed, 28 Feb 2007 16:40:15 +0100 [thread overview]
Message-ID: <45E5A25F.6020307@aotek.es> (raw)
In-Reply-To: <45E588D0.5000305@smiths-aerospace.com>
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: <http://en.wikipedia.org/wiki/MD5>]
>
>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
next prev parent reply other threads:[~2007-02-28 15:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-27 22:29 [U-Boot-Users] RFC: extended image formats Wolfgang Denk
2007-02-28 13:51 ` Jerry Van Baren
2007-02-28 15:40 ` Txema Lopez [this message]
2007-02-28 14:21 ` Josh Boyer
2007-02-28 14:58 ` Jerry Van Baren
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=45E5A25F.6020307@aotek.es \
--to=tlopez@aotek.es \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.