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