Hi Jerry,
Thanks for your comments, see my replies below.
Jerry Van Baren wrote: [...]
- '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