Specify how FDT is to be passed from UEFI

[andreiw]

UEFI spec doesn't know anything about the configuration table GUID for FDT.

See https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf#page=172

...because of that, this spec should cover the GUID used to pass FDT (e.g. gFdtTableGuid = { 0xb1b621d5, 0xf19c, 0x41a5, { 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0 } }), as well as requirements on memory - should this BS Data or RT Data? Should the memory type be ACPI NVS or it doesn't matter?

A

[fozog]

Hi

Very good point !

That said, EBBR is actually a set of requirements and not a specification. Device Tree specification shall define the elements you mention.

Le 30 avr. 2020 à 21:54, Andrei Warkentin notifications@github.com a écrit :

 UEFI spec doesn't know anything about the configuration table GUID for FDT.

See https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf#page=172

...because of that, this spec should cover the GUID used to pass FDT (e.g. gFdtTableGuid = { 0xb1b621d5, 0xf19c, 0x41a5, { 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0 } }), as well as requirements on memory - should this BS Data or RT Data? Should the memory type be ACPI NVS or it doesn't matter?

Probably EfiRuntimeServicesData. In the DT spec it may be good to refer to aarch64 alignment and other aspect of section 2.3.6 of uefi spec.

A

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[andreiw]

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.

[andreiw]

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

[fozog]

Le 1 mai 2020 à 02:55, Andrei Warkentin notifications@github.com 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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[andreiw]

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

[fozog]

Le 1 mai 2020 à 10:29, Andrei Warkentin notifications@github.com 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.

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?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[robherring]

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.

[robherring]

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.

[andreiw]

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.

[ardbiesheuvel]

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?

[fozog]

On 01.05.2020 16:47, Rob Herring wrote:

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. DT is today merely a language spec with a few bindings. The lack of standardization of the bindings, lifecycle and overall usage guidance led to keep fragmentation. ACPI, standardizes the GUID for UEFI while it is not a GUID driven standard too.

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. That's if you want to keep the spec at the lanugage level. AWS, Microsoft and Google are now recognizing that having MQTT as the common language is not helping their business as they have different "bindings" for the same things. Microsoft said this creates "necessary friction" that needs to be addressed. DT is going through the same path and this is a good time to re-assess why DT was created and it should be. If usage is totally free and not coordinated, DT does not address fragmentation and in that regards fails to reach the initial onjective.

-- You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[andreiw]

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

[fozog]

On 01.05.2020 17:35, Ard Biesheuvel wrote:

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

What is your recommendation for the memory type?

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

-- You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ardbiesheuvel]

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.

[fozog]

On 01.05.2020 18:00, Andrei Warkentin wrote:

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.

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? Not the simplest learning path for a developer... And over time, you may need a whole bunch of additional specs to address the diversity of contexts in which two constructs can interact.

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.

A

-- You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[fozog]

On 01.05.2020 18:16, Ard Biesheuvel wrote:

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.

Thanks.

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.

Nothing I think. But this the tip of an iceberg about DT specification. Addressing this simple point allows to raise the right questions and gradually address what's below the surface and that I could qualify the specification debt.

You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[xypron]

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.

[xypron]

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.

[andreiw]

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.

[xypron2]

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?

[fozog]

On 01.05.2020 19:51, Heinrich Schuchardt wrote:

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. That was my first impression. That said UEFI also states section 2.6.4: "By way of examples, at the time of writing the UEFI Forum is aware of a number of extension publications that are compatible with and designed for use with this specification." "Other extension documents may exist outside the view of the UEFI Forum or may have been created since the last revision of this document." TCG is actually defining a number of extensions and some are identified by GUIDs, not present in the UEFI Spec. Section 4.6 of UEFI says: "The following list shows the GUIDs for tables defined in some of the industry standards. These industry standards define tables accessed as UEFI Configuration Tables on UEFI-based systems. This list is not exhaustive and does not show GUIDS for all possible UEFI Configuration tables." Bottom line, UEFI is happy with companion specifications that define objects to be used in UEFI. I favor that option as it is in line with the idea of avoiding release cycles dependencies. That said, I am also in favor of the selected specification for the DT GUID listed in the other specs of section 2.6.4.

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. Agreed. And even if it was not de facto tied to Arm, EBBR only defines one profile of usage of UEFI. Nothing precludes SBBR to include DT. Nothing precludes creation of other UEFI profiles in Arm or not. all those additional specs should handle DT and UEFI the same way. With all the above, normalizing DT usage in the context of UEFI just make sense to be specified in DT spec and not in a third one. As Andrei raised that very good point, I would think he is the one entitled to send an RFC to the DT mailing list. 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.

-- You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[andreiw]

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?

[andreiw]

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.

[andreiw]

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]

On 02.05.2020 18:05, Andrei Warkentin wrote:

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? Personal opinion.

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[fozog]

On 02.05.2020 18:43, Andrei Warkentin wrote:

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. Goo point. And I join Heinrich comment earlier: if EBBR is the only spec where it can be accepted then let it be. But at least I'll give a try to make things logical.

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[fozog]

On 02.05.2020 18:46, Andrei Warkentin wrote:

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. Got your point. I'll make sure it is followed up.

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[apalos]

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

[glikely]

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

[glikely]

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