[U-Boot-Users] RFC: New U-boot image format

Marian Balakowicz
2007-12-13T22:41:44Z

Hi Jerry,

Thanks for your comments, see my replies below.

Jerry Van Baren wrote:
[...]
>> 3. 'New image' format must support the following features:
>
> [snip]
>
>> - 'container' image blob shall include 'component' images'
>> data, which means direct data embedding - as opposed to
>> having only references
>
> Q for Jon L: This would require an extension to the dtc to "include" a
> raw file into the blob? I'm presuming that we don't want to take a
> binary (ELF) file, turn it into ASCII bytes, include it into a dts, and
> then use dtc to compile it back into binary.
>
> Am I missing something that is already available? Do you see any
> problems with extending dtc to support this?

AFAIK dtc currently has no support for data includes. I've seen such
feature on a dtc wish list though, so adding it should not be troublesome.

>> (b) 'container' source file (.dts)
>>
>> - the following bindings and properties shall be defined for a device
>> tree source file (.dts) that is corresponding to a 'container'
>> image blob:
>>
>> - root node of the DTS shall represent a 'container' node
>> - 'container' node shall support:
>> - label property
>> - timestamp property
>> - 'container' node shall support multiple 'component' subnodes
>>
>> - 'component' subnode shall support:
>> - label property
>> - type property
>> - hash properties (crc32, md5, sha1, etc.)
>
> Would hash be two entries (type and value), or would it be just the type
> and use conventions for where the value is stored (i.e. last /n/ bytes
> of the image)? I would vote for (type and value) if this were a democracy.
>
> Are image hashes to validate what is stored in the blob (compressed) or
> to validate what is in memory after decompressing? (Ability to support
> both options would be very good IMHO.)

Agree, entries are much more flexible, e.g. we can easily add third
entry which will distinguish compressed/uncompressed data hashes.

>>
>> - detailed image bindings description shall be provided as a separate
>> document (e.g. wiki web page)
>
> I vote for capturing it git as a text document equivalent to
> booting_without_of.txt (fdt_images.txt?).

I mentioned wiki as it's easier to update and work with, but I am fine
with the git txt as well.

> (Do we need a [Dd]ocumentation subdirectory?)

Not sure, there is a doc directory which contains board README files.
And there is a (quite large) README file that documents a lot of U-boot
internals. I guess we may want to hear Wolfgang's opinion?

Cheers,
Marian