That draft is the DEN0135 document [2]. I realise that I haven’t made it sufficiently explicit in this thread that the DEN0135 document [2] is still at draft quality (see ALP maturity called out in the title page and footers). Please do not consider this a finished document 😊. We’ve been iterating on this pdf as we gather feedback from the open-source communities. It's becoming clear that we need to move this debate to a more suitable forum. That’s why we’re proposing, in this thread, to move the document to trustedfirmware.org.
Understood. FWIW, I totally support hosting this on TF.org, I think that makes sense considering that it has good co-development infrastructure that is open to everyone (e.g. Gerrit) already set up and that it's easy to administer for you guys who are currently organizing this. I don't really see Simon's concern regarding "captive to one project" -- this whole spec is an attempt to cooperate better, not work against each other, so there shouldn't need to be fights about who "owns" it (just pick a place with good infrastructure and let everyone access it there). If perhaps the real concern is rather related to who controls future spec updates, tag assignments, etc. then I think we should address those directly and define clear processes that we can all feel comfortable with, rather than implying that the final word on these is left to whoever controls the hosting platform.
The requirement originated in feedback from the u-boot community, please see [3]. The argument for 16-byte alignment is that some data-structures have to be 16-byte aligned. We ought to meet that requirement if we ever want to carry those structures.
I still really think that this is wasting space to the point where it defeats the purpose of this being a "lightweight" data handoff structure. Consider that all of the bl_aux_params tags in TF-A (which I described as one of the existing mechanisms for this kind of thing in last year's thread) are 8 bytes or less, which means that for these use cases the transfer list would have over 3 times as much overhead as actual data. There seems to be some disconnect here since the stated idea for this is to be a lightweight handoff mechanism to pass individual pieces of information directly, yet all the initially proposed tags are just for wrapping large existing hand off blobs that bundle lot of information in their own structures (giving it a very xkcd.com/927-like feel), and the spec design seems to be tuned toward the latter use cases.
If individual tags have special alignment requirements, they could just deal with that internally (by including another offset field in the "data" part) without dragging every other tag in the structure down with them. Alternatively, if you really want to keep this I think an acceptable compromise could be to keep the 16-byte entry alignment but reduce the transfer entry header size to 8 bytes, and then allow tags that don't require 16 byte data alignment to immediately use the following 8 bytes for data. That way, entries with 8 bytes or less of data could fit both header and data into a single 16 byte block which drastically cuts down on overhead for small data.
- The table entry header seems unnecessarily large. What's the point of
including a "header length" field when that field will always contain a 16?
The "header length" enables the table entry header to be extended if we ever need that in the future. Changes to the TE header are backwards compatible. A consumer obtains the address of the data by adding the "header length" to the entry's base address.
I really don't see this as likely enough to be worth paying that big upfront cost of making the whole structure so much less efficient to start with. I think 8 bytes are already the most you'd reasonably want to pay for header overhead, I find it highly improbable that we'd want to introduce more fields later to make that even bigger. If there's desire for optional large annotations (e.g. per-entry cryptographic hashes) in the future, I'd rather suggest implementing that as "companion entries" with special tags that are written right behind the entry they refer to, rather than try squeezing it all into a single header structure. If you want to leave some room for simple bit flags, I would suggest masking out the high byte of the data length field instead (i.e. splitting it into 3 and 1) -- it doesn't seem like anyone would want to pass a data item larger than 32 MB in a firmware information structure anyway.
The TL header version is incremented when we do a new release of the document. At a new document release, we can introduce one or more new standard tags and also append fields to the TL header.
FWIW I would suggest decoupling the data structure version from the document version and only increasing the data structure version when the actual structure changes in a meaningful way. Documents may be amended to improve clarity or add more detailed explanations that don't always require parsers to actually act differently, so increasing version numbers in the code for those cases would seem to just unnecessarily confuse things.
- I don't think a strict definition of entry type ranges is a good idea,
particularly if "standard" and "OEM" are the only two options.
As mentioned above, the standard tag range ought to have a low-barrier for new tags to be requested. The OEM range allows FW integrators to carry platform-specific entries that may not be generalizable.
Okay. This definitely needs to be specified in more detail and give more guidance about where tags should be allocated for what case, because my first impression from reading the doc was apparently quite different than yours. I think the spec should strongly encourage allocating a global tag whenever there might be the slightest possibility that other platforms might want to use it later. For example, maybe we can define the guideline that anything referred to by any code checked into the upstream of any open source project (U-Boot, TF-A, whatever) should always be a global tag. I guess a small range of OEM tags makes sense for closed source downstream code that isn't shared with anyone, but that should be the only use case for that (so that open source projects can always freely collaborate and adopt each others' standards without the risk of tag clashes).
The feedback we received so far is: data should be included in the TL as that simplifies procedures, such as relocating the data, without having to worry about stale pointers.
I generally agree with that sentiment, but I also don't see including a whole FDT or ACPI table in this structure as a normal case -- that's more of a pathological edge case necessary to interface with environments that use these other hand-off structures (because all these are really just different ways to do the same thing, and there's no real benefit from wrapping one in the other... it's just an unfortunate necessity due to different boot stages expecting different things). I really expect these to be mostly independent (and come with their own placement requirements, which is a problem for direct inclusion), I would expect at least some platforms to need the flexibility of keeping them separate and therefore think it would be better to standardize on that. But if other platforms really think it's important to have these inline in the transfer list for their use case, you could offer separate tags for both.