Hi Rob,
On Tue, 5 Jul 2022 at 11:27, Rob Herring robh@kernel.org wrote:
On Tue, Jul 5, 2022 at 10:37 AM Simon Glass sjg@chromium.org wrote:
Hi Rob,
On Tue, 5 Jul 2022 at 09:24, Rob Herring robh@kernel.org wrote:
On Thu, Jun 30, 2022 at 3:24 AM Simon Glass sjg@chromium.org wrote:
Hi Jose,
I don't think this is correct. TF-A is a project that aims to replace U-Boot SPL (and perhaps other components) with more closed firmware, e.g. the permissive license.
This spec needs to be in a neutral place, not captive of one project.
Given its close relationship to device tree, I suggest github.com/devicetree-org
The only relationship to DT I see is DT is a payload as is ACPI. So I don't think dt.org is the right place.
Actually I was about to email you about this. Here's how I see it.
DT is a base structure to allow self-describing data to be stored. This is in contrast with ACPI where there is just a header, but it is not possible to read the data without specific parsing code for the particular table types. Let's ignore ACPI for this discussion.
Unfortunately DT has an overhead and is too expensive for early firmware use. It takes 3-4KB of code for libfdt as well as extra code and data to read properties, etc.
Transfer List aims to bridge the gap, allowing simple C structures to be put into a tagged data structure. The intention is that anything more complex than that would use DT.
So there is at least some relationship: simple stuff = Transfer list, complex stuff = DT.
That's a stretch IMO. Perhaps if this was a new output (DTB) format for easier parsing, I'd agree. It's related to DT only as much as any other data passed between 2 boot components (remember ATAGS?).
Yes it is a stretch. I'm just making the case.
The Transfer List spec specifies the data format for each entry type (the analog to the schema). The DT provides the format and schema for more complicated stuff.
We could perhaps put it in an entirely separate repo, but to me there is a relationship with DT.
It seems to me that TF is the main driver and user of this, so I don't see the issue with them hosting it at least to start as long as there's not barriers to contributions. It's just a namespace like devicetree-org. Personally, I'd be more concerned on what the source format is (I assume the plan is not to commit PDFs) and what the output generation is. GH has a lot of nice features to support that which we've used for the DT spec and EBBR.
Yes the DT spec works well and I hope the same thing can be used.
I'm not saying no to devicetree-org either. If the consensus is to put it there, I really don't care so much as it takes less time to create a new repo there than to write this email.
I do hope that this can become a standard beyond ARM, e.g. with Intel and another i can think of. Intel is essentially trying to create a different thing independently, although has apparently adjusted to use device tree due to its self-describing properties. I suspect that having this spec in an ARM site would be a barrier to that.
I am OK with ARM TF being the means to get this into the open, but not with it being the final destination.
If we cannot agree on anything better, I am happy with creating a new project on github. We'll need to pick someone to own it and make final calls when there is disagreement.
Regards, Simon