All,
Here are my notes from today. Please correct anything I got wrong.
Attendees: Bruce Ashfield Frank Rowand Simon Glass Etienne Carriere Heinrich Schuchardt Ilias Apalodimas Joakim Bech Loic Pallardy Mark Brown Mathieu Poirier Rob Herring Ruchika Gupta Vincent Guittot Vincent Stehle
CC: Stefano Stabellini Kumar Gala
Discussion:
Today we did a brainstorming session on goals/requirements for a new DTB format.
Remember this is a laundry list of requirements / concerns. Not all will necessarily be included in the new format but all will be considered.
It is not a discussion of the format changes to achieve these goals.
Frank Rowand will be collecting past discussions related to this and expects this to be ready for the meeting on March 22.
* FR: Reduce Size * FR: Overlay support in "symbol table" not looking like HW description * FR: Ability to express "delete node" and "delete property" ** many: do we really need delete node, every node should have status ** RH: not everyone today looks for status != ok ** general agreement that they should ** RH: perhaps we should make it more automatic somehow * SG: New format should be little endian ** most current active / popular CPU arch are LE these days * SG: Ability to refer to data blob by reference instead of inline ** blob would still be in DTB file/image but not inline as a property blob * RH: Include type info ** Know what is a u64 vs u32 vs phandle ** replicate what we have in schema with bit fields etc ** enums?? structs?? * SG: Provision for comments * RH: In general want more less conversion DTS -> DTB -> DTS ** WAM: Is it OK to rely on schema? ** SG: Ideally not, would prefer self describing format * HS: Want to be able to validate DTB (against schema) ** WAM: Isnt this the same as type info? ** RH: That is a lot of it but there is more * WAM: We want a new section for meta data ** WAM: signatures as discussed on this call ** FR: Source file info / version markers ** HS/WAM: taint flag if the DTC compile or validate is not clean * SG: IN yaml we can import a node, ** would be good to have this in DTS as well ** FR: It is valid to bring in DTS requirements as some of this will effect anyway * WAM: Segmeneted DTB or DTB set ** instead of applying overlays leave base and overlay intact ** deliver to OS as a set with assembly order. ** [We can call it IKEA mode :) ] ** allows signatures to reamin valid, can be passed on ** makes it clear what fixups were performed by the firmware * SG: a previous node "pointer" ** going backwards is very slow in FDT * WAM: Huawei is asking for B-Tree to speed up search in FDT ** FR/RH: probably too far but we will consider * RH: DTB format could be unflattened ** SG: could be too big ** SG: we may really need more than one format to balance speed vs size ** [WAM: learns that libfdt does not unflatten. U-boot copies Linux code for this.] ** RH: we could have a libdt that would be lib for live trees * SG: for speed it would be nice to have a directory for quick access ** WAM: improved alias? SG: Yes if they were phandles perhaps * WAM: Can we revist size, that is pretty broad ** Eliminate as many strings as possible ** FR: Compiler does "tail recursion" on strings already ** WAM: strings in properties are not in symbold table today ** SG: Yes I studied that and elimination of that did not help a lot. ** SG: Today everything is 32 bit *** I looked at reducing and could save 20% *** But it is not as regular *** WAM: is it aligned today? *** RH: Yes, 64 bit aligned but not very clear in spec ** HS: Just gzip the DTB if you just want to reduce storage size ** WAM: Published ATOM based DTB doc a few years ago. *** Try to move most strings to 32 bit ATOM constants (not offsets) *** Optionally include ATOM table to include the strings
Devicetree Atom Table Format: https://docs.google.com/document/d/19XbxN-zX-GYwOXdF78lGnp0j7UNx1MT3wzyCjait...
Frank reminds us that we want to collect all the stake holders: * Linux * DTC * U-Boot * BSDs ** One has its own DTC * RTOS ** Zephyr (mostly DTS) *** Have their own DTS parser, DOM lib, and code gen *** Want to make it more generic ** Vxworks (does use runtime DT of some sort)
All agree: Old DTB format will need to be supported for a good while after new DTB format is defined.
Thanks, Bill