Extending U-Boot image format requirements
------------------------------------------

1. Preserve old image format, cleanup and re-factor old image handling code

  (a) Cleanup shall cover:
	- related U-boot commands: bootm, imls, iminfo,
	  imxtract, doc, fdcboot, fpga, ide, nboot, scsiboot, usbboot

	- platform specific code that is referencing old image format

	- cpu specific code (lib_i386, lib_mips, etc.)

	- U-boot tools, etc.

  (b) After cleanup and refactoring it shall be possible to continue to use
      the old images (and the old image format) where needed

2. Develop a 'new image' format

  (a) 'New image' format shall be based on a Flat Device Tree (FDT) structure

  (b) Specific bindings shall be defined to implement 'new image' structure

  (c) Code implementation shall be based on libfdt library

  (d) Device Tree Compiler (DTC) shall be used to produce 'new image' blobs


3. 'New image' format must support the following features:

  (a) 'container' blob

	- the 'new image' aka the 'container' must be a proper FDT blob file
	  produced from Device Tree Source file (DTS) with the use of Device
	  Tree Compiler (DTC)

	- 'container' format shall provide support for multiple 'component'
	  images (sub-images)

	- 'container' image blob shall include 'component' images'
	  data, which means direct data embedding  - as opposed to
	  having only references

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

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

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

  (a) typical use case:

	- collect set of N 'component' data files, such data files being for
	  example Linux kernel image, Ramdisk image, FDT blob, arbitrary
	  binary image, script file, FPGA image, etc.
	
	- create corresponding .dts file describing 'container' contents
	  and structure

	- use mkimage tool to create new 'container' image from a set of
	  given data files

  (b) possibly useful (and user friendly) operations:

	- add new 'component' of a given type to existing 'container' blob
	- delete existing 'component' from 'container' blob
	- display 'component' list
	- set 'component' properties (label, type, entry point, etc.)

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

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

  (b) platform specific code that is referencing old image format will not be
      extended to include 'new image' format - adding such support will be
      up to platform maintainers

  (c) support for 'new image' format shall be added to cpu specific code
      (lib_i386, lib_mips, etc.)

  (d) support for 'new image' format shall added to U-boot tools, etc.