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

[Jerry Van Baren]

Marian Balakowicz wrote:
> Hello,
> 
> New format for U-boot images has been on the list few times already.
> There were different ideas and features discussed but no final
> conclusion has been made.
> 
> I've put together a set requirements that aims to assist further
> discussion. They are quite generic at this point of time and do not
> cover all details, use cases, features.
> 
> So far they got briefly review by Wolfgang but I hope to hear more
> comments, suggestions, criticism, opinions, etc.
> 
> All feedback is welcome.
> 
> Thanks,
> Marian

Very interesting!  Thanks for putting in the time and thought.

> Extending U-Boot image format requirements
> ------------------------------------------
> 
> 1. Preserve old image format, cleanup and re-factor old image handling code

[snip]

> 2. Develop a 'new image' format
> 
>   (a) 'New image' format shall be based on a Flat Device Tree (FDT) structure

Trivia: Flattened (not flat) Device Tree.

[snip]

> 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?

>   (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.)

> 			- data compression type property (compressions 
> 			  currently supported by U-boot)
> 			- data size property
> 			- timestamps property
> 
> 			- properties corresponding to remaining header
> 			  fields from the old image format:
> 
> 				os type, cpu architecture properties
> 				data load address
> 				entry points for executable images
> 
> 	  Note: the above list is considered *draft* and open to discussion

Which properties are new inventions?  Data compression, timestamps, OS 
Type, CPU arch, data load address, and entry point?  Not a bad thing, 
just trying to understand how much we are extending.

> 	- properties/bindings, their format and definition and the way they
> 	  are accessed and processed in U-boot shall allow for easy and
> 	  flexible extensions; that is, adding new 'component' type,
> 	  new compression type, etc. shall be possible in a clean and
> 	  compact way.
> 
> 	- 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?). (Do we need a [Dd]ocumentation 
subdirectory?)

> 4. Extend mkimage tool to support new image handling operations:

[ack-snip]

> 5. Add 'new image' handling to U-Boot
> 
>   (a) support for 'new image' shall be added to related U-boot commands: bootm,
>       imls, iminfo, imxtract, doc, fdcboot, fpga, ide, nboot, scsiboot, usbboot

I presume...
imls     == image list (overlaps with "fdt l /", no?)
iminfo   == image info?  What does it do more than imls?
imxtract == image extract?
    * Does what?
    * Somebody buy that man a vowl ;-)

It is probably an urban legend, but I recall somebody once asked Brian 
Kernighan (Dennis Ritchie?) what his greatest regret in creating the C 
language was, and he replied "Leaving the 'e' off create."

> 	- command syntax (especially 'bootm') will need to be extended to
> 	include 'new image' format related uses cases

Should we create a new command rather than trying to create yet another 
bootm extension (YABE), or is that too disruptive?  If not, bootfdt?

[ack-snip]

Thanks again,
gvb