From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marian Balakowicz <m8@semihalf.com>
Date: Thu, 13 Dec 2007 23:41:44 +0100
Subject: [U-Boot-Users] RFC: New U-boot image format
In-Reply-To: <475EE3AE.6060102@ge.com>
References: <475EB857.4080104@semihalf.com> <475EE3AE.6060102@ge.com>
Message-ID: <4761B528.3080601@semihalf.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de


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