I'm confused by your statement. EBBR is a spec much like SBBR is a spec - it specifies behavior that EBBR OSes expect from firmware. A spec is a list of requirements. What does an EBBR OS require from firmware to properly consume DT when booting via UEFI? That is still the question.

I don't see anything here: https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3

So if the UEFI spec doesn't have it, and the Devicetree spec doesn't have it, EBBR must have it, because it's integrating the two together.

The UEFI spec, as I mentioned again, does not cover device tree or any other vendor-specific configuration tables. That belongs in EBBR.

Please point me to the specification that mandates the GUID for passing DT from UEFI to OS.

Le 1 mai 2020 à 02:55, Andrei Warkentin @.***> a écrit :  I'm confused by your statement. EBBR is a spec much like SBBR is a spec - it specifies behavior that EBBR OSes expect from firmware. A spec is a list of requirements. What does an EBBR OS require from firmware to properly consume DT when booting via UEFI? That is still the question. I don't see anything here: https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 So if the UEFI spec doesn't have it, and the Devicetree spec doesn't have it, EBBR must have it, because it's integrating the two together.
DT is an architecture independent construct specification. There are no reason to specify DT overall behavior outside DT. The RiscV May define another EBBR like spec yet I would very much like they use the same GUID.

The intention was that RiscV or any other architecture would be supported within EBBR. The issue so far has been getting any participation from RiscV folks.

Le 1 mai 2020 à 10:29, Andrei Warkentin @.***> a écrit :  Please point me to the specification that mandates the GUID for passing DT from UEFI to OS.
There’s no paragraph currently that’s why you are making a very good point. I just say that EBBR is not the right place to solve it. I think a proposal to devicetree-spec@vger.kernel.org makes sense.

DT has no clue what a GUID is. That's largely a UEFI construct. The DT spec is not the right place.

I believe other topics are missing in DT specification: authentication, overlays, lifecycle (interactions with Trusted Firmware and OP-TEE at least)... have you identified other missing certification elements?

IMO, those only belong in the DT spec to the extent they impact the DT contents or FDT file format.

Folks, I'm not asking for the DT spec to know anything about the GUID. That's not my request. I'm just pointing out that this "integration" belongs in the EBBR spec, as neither UEFI spec nor the DT spec covers this.

So far, it appears the GUID used is an EmbeddedPkg Tiano implementation detail. It's not on paper anywhere. Same goes for my other question - memory type requirements for backing pages? Is this boot services data (e.g. not preserved) or runtime services data (preserved)? Or us EfiACPIReclaimMemory supposed to be used? These things belong in a spec - the EBBR spec.

Aside: EfiRuntimeServicesData should only be used for data that the firmware implementation itself needs to access at runtime.

As for the GUID: this is a contract between the OS and the UEFI firmware., but that does not mean it belongs in the UEFI spec. For instance, TPM related config table GUIDs are in the TCG spec, and SMBIOS related ones are in the DMTF spec.

However, the DT GUID is already well established, and GUIDs are constructed the way they are to avoid collisions, so I wonder which problem we are actually solving here?

Hi Ard,

We're solving a documentation problem in the EBBR - EBBR should document and mandate the stablished practice. This is not a DT or UEFI problem.

Imagine you have have /never/ worked on UEFI, Arm or Devicetree... could a reasonably competent person pick up the EBBR and have the full set of OS requirements to implement an EBBR-compliant firmware implementation today? Without looking at other EBBR implementations or OS code? I would say - not today?

A

On 01.05.2020 17:35, Ard Biesheuvel wrote:
...
What is your recommendation for the memory type?

ACPI reclaim is the most appropriate - it is ordinary memory that the OS can use whichever way it wants if it is no longer interested in the contents passed by the firmware.

The GUID itself is de-facto but Andrei has a point that no spec has it defined (such as TCG, or DMTF). The question is what spec is the right home? EBBR is a spec for a specific market. It is certainly inevitable that other requirements will appear that will drive DT usage (complementing EBBR, SBBR collection in Arm or for other architectures). So DT seem the natural place for that specification following ACPI, TCG and DMTF examples.

I understand that there is no spec that defines it today. I just don't see what will go wrong if it stays that way.

As for the GUID: this is a contract between the OS and the UEFI firmware., but that does not mean it belongs in the UEFI spec. For instance, TPM related config table GUIDs are in the TCG spec, and SMBIOS related ones are in the DMTF spec.

You could the say the same for the ACPI tables. They are also a contract between OS. But the UEFI spec defines the GUIDs for ACPI tables.

As ACPI and DT are to a high degree two alternative formats for describing the same thing, why should they be treated differently? So I think that the UEFI spec would be the most appropriate place for the device tree table GUID.

But I would not mind if the GUID would be placed into another spec, e.g. the device tree spec. The EBBR is de facto an ARM only project. This may not be the best place but it is better then no spec at all and putting it here would not stop the UEFI spec from picking it up.

ACPI reclaim is the most appropriate - it is ordinary memory that the OS can use whichever way it wants if it is no longer interested in the contents passed by the firmware.

The UEFI spec says: "ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS."

I would suggest to treat the device tree configuration table equally and to put this into the EBBR spec.

As ACPI and DT are to a high degree two alternative formats for describing the same thing, why should they be treated differently? So I think that the UEFI spec would be the most appropriate place for the device tree table GUID.

That's a fair assessment to make, but then someone needs to take this up and file a Mantis item in the ASWG, to both get the requirements and the GUID documented. TBH that someone should be an EBBR stakeholder.

That's a fair assessment to make, but then someone needs to take this up and file a Mantis item in the ASWG, to both get the requirements and the GUID documented. TBH that someone should be an EBBR stakeholder.

Is anybody in the thread member of the ACPI Specification Working Group?

Just so I’m crystal clear here, @fozog are you channeling your own opinion here or is this an official “EBBR steering committee” (if there is one) communication?

So your logic is that when you have two constructs that are defined by two specs you need a third spec to define how the first two constructs interact?

Yes. Because that’s literally the purpose behind EBBR? To specify how UEFI-compatible firmware, capable of booting DT-oriented OSes, should operate? There’s no one else in town who - today - who might care about bridging DT and UEFI together... it’s an Arm spec that relies today on an Arm-developed implementation. Who else in your opinion should be driving this?

Again - between the EBBR, UEFI and DT specs there isn’t complete knowledge on how to write an EBBR implementation.

The ServerReady SBBR spec (also an Arm spec, albeit one that focuses in ACPI) isn’t run this way. They take ownership, regardless of whether that means amending their own specs or working to amend related specs.

Consider that your effort to change the DT or UEFI specs might take significant time or suffer pushback (i.e. they have an equal opportunity to tell you to go away). That means the language has to live somewhere in the interim, considering that we’ve agreed this is a gap. Otherwise what you have here is not a spec, but a loose and incomplete collection of notes.

As Andrei raised that very good point, I would think he is the one entitled to send an RFC to the DT mailing list.
…

Thanks, but no thanks. I’ve done my duty to report an issue with your spec. I’ve no intention of picking up ownership/maintainership of EBBR or to represent EBBR interests in other forums - that’s the function of the EBBR community itself.

@fozog joining late, but I agree with Heinrich on this.
Since ACPI is part of the UEFI spec, the first thing that makes sense is adding similar wording for DT.

Wow. This got to be a long thread. I have no problem specifying the DT GUID in the EBBR spec.

Added a proposed fix to my private branch, and sent it to the boot-architecture mailing list. Can be discussed there.