Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Grant Likely
On 05/05/2020 17:39, Heinrich Schuchardt wrote: On 05.05.20 11:10, Grant Likely wrote: On 04/05/2020 19:30, Heinrich Schuchardt wrote: On 5/4/20 7:20 PM, Grant Likely wrote: None of the relevent specs (EFI, DT, EBBR) specify the GUID for passing a DTB. Add it to the EBBR document so it is

Re: EBBR v1.0.1 release in the near future

2020-05-05 Thread Heinrich Schuchardt
On 05.05.20 17:44, Grant Likely wrote: > Hi all, > > I'm considering doing a quick point-release for EBBR to address the > change to RuntimeServicesSupported in UEFI 2.8 Errata A. From 2.8final > to 2.8_A, RuntimeServicesSupported changed from being a variable to data > in a system table entry. U-B

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Heinrich Schuchardt
On 05.05.20 11:10, Grant Likely wrote: > > > On 04/05/2020 19:30, Heinrich Schuchardt wrote: >> On 5/4/20 7:20 PM, Grant Likely wrote: >>> None of the relevent specs (EFI, DT, EBBR) specify the GUID for passing >>> a DTB. Add it to the EBBR document so it is documented somewhere >>> relevant. >>> >

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread François Ozog
On Tue, 5 May 2020 at 17:48, Heinrich Schuchardt wrote: > On 05.05.20 15:51, Grant Likely wrote: > > > > > > On 05/05/2020 08:30, Andrei Warkentin wrote: > >> *From:* Ard Biesheuvel > >> > >>> > Not a strong position, but you may also want to put the foot down on > >>> > *when* the exposed Devic

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Ard Biesheuvel
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt wrote: > ... > > As long as device-trees loaded by an EFI application like GRUB do not > fully describe boards and miss on copying memory reservations, > boot-hartid and everything else needed for successful booting the > requirement not to fix-up d

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Heinrich Schuchardt
On 05.05.20 15:51, Grant Likely wrote: > > > On 05/05/2020 08:30, Andrei Warkentin wrote: >> *From:* Ard Biesheuvel >> >>> > Not a strong position, but you may also want to put the foot down on >>> > *when* the exposed Devicetree blob must be consistent (consistent with >>> > some firmware setting

EBBR v1.0.1 release in the near future

2020-05-05 Thread Grant Likely
Hi all, I'm considering doing a quick point-release for EBBR to address the change to RuntimeServicesSupported in UEFI 2.8 Errata A. From 2.8final to 2.8_A, RuntimeServicesSupported changed from being a variable to data in a system table entry. U-Boot and Linux have been updated to the UEFI metho

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Grant Likely
On 05/05/2020 08:30, Andrei Warkentin wrote: *From:* Ard Biesheuvel > Not a strong position, but you may also want to put the foot down on > *when* the exposed Devicetree blob must be consistent (consistent with > some firmware setting changes). Perhaps thats at ReadyToBoot or > ExitBootServ

Re: [PATCH] Update spec to address UEFI 2.8 Errata A

2020-05-05 Thread Grant Likely
On 05/05/2020 12:54, Ard Biesheuvel wrote: On Tue, 5 May 2020 at 13:49, Grant Likely wrote: UEFI 2.8 Errata A changed RuntimeServiceSupported value to be passed via an EFI_RT_PROPERTIES_TABLE instead of via a runtime variable. This is a breaking change and we should do a new EBBR release in

Re: [PATCH] Update spec to address UEFI 2.8 Errata A

2020-05-05 Thread Ard Biesheuvel
On Tue, 5 May 2020 at 13:49, Grant Likely wrote: > > UEFI 2.8 Errata A changed RuntimeServiceSupported value to be passed via > an EFI_RT_PROPERTIES_TABLE instead of via a runtime variable. > > This is a breaking change and we should do a new EBBR release in short > order to keep EBBR up to date w

[PATCH] Update spec to address UEFI 2.8 Errata A

2020-05-05 Thread Grant Likely
UEFI 2.8 Errata A changed RuntimeServiceSupported value to be passed via an EFI_RT_PROPERTIES_TABLE instead of via a runtime variable. This is a breaking change and we should do a new EBBR release in short order to keep EBBR up to date with what is in UEFI. Unsure what the overall impact will be.

Re: [PATCH] Fix all UEFI references to be the same version

2020-05-05 Thread Grant Likely
On 04/05/2020 18:55, Ard Biesheuvel wrote: On Mon, 4 May 2020 at 19:43, Grant Likely wrote: Reference UEFI v2.8 throughout. v2.8 is the first version that defines the RuntimeServicesSupported variable. Fixes: #40 Signed-off-by: Grant Likely This should refer to UEFI 2.8 errata A directly,

DTE call meeting notes

2020-05-05 Thread François Ozog
Hi, Thank you for your participation in yesterday's call. Here are meeting notes that you can update as you see fit (I think the permissions associated with this new link are correct). Survey was an

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Andrei Warkentin
From: Ard Biesheuvel > > Not a strong position, but you may also want to put the foot down on > > *when* the exposed Devicetree blob must be consistent (consistent with > > some firmware setting changes). Perhaps thats at ReadyToBoot or > > ExitBootServices. > ReadyToBoot is a PI concept, not a

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Andrei Warkentin
Typo: (IIRC ACPI has the same problem [with consistency], but you have the luxury of NOT having to worry about that [in the context of EBBR]). From: Andrei Warkentin Sent: Monday, May 4, 2020 1:34 PM To: Grant Likely ; boot-architecture@lists.linaro.org Cc: Fran

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Ard Biesheuvel
On 5/4/20 8:34 PM, Andrei Warkentin wrote: Hi Grant, Please also factor in requirements for how memory containing DT must be described in the memory map (Ard mentioned using EfiACPIReclaimMemory). Maybe something like: * Devicetree loaded at boot time must be contained in memory of type

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Andrei Warkentin
Hi Grant, Please also factor in requirements for how memory containing DT must be described in the memory map (Ard mentioned using EfiACPIReclaimMemory). Maybe something like: * Devicetree loaded at boot time must be contained in memory of type EfiACPIReclaimMemory. Not a strong position

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Grant Likely
On 04/05/2020 19:30, Heinrich Schuchardt wrote: On 5/4/20 7:20 PM, Grant Likely wrote: None of the relevent specs (EFI, DT, EBBR) specify the GUID for passing a DTB. Add it to the EBBR document so it is documented somewhere relevant. Fixes: #45 Cc: Andrei Warkentin Cc: Francois Ozog Signed-

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread Ard Biesheuvel
On Tue, 5 May 2020 at 10:38, François Ozog wrote: > > On Tue, 5 May 2020 at 09:16, Ard Biesheuvel wrote: > > > On 5/4/20 8:34 PM, Andrei Warkentin wrote: > > > Hi Grant, > > > > > > Please also factor in requirements for how memory containing DT must be > > > described in the memory map (Ard ment

Re: [EBBR PATCH] Add EFI GUID for device tree blob

2020-05-05 Thread François Ozog
On Tue, 5 May 2020 at 09:16, Ard Biesheuvel wrote: > On 5/4/20 8:34 PM, Andrei Warkentin wrote: > > Hi Grant, > > > > Please also factor in requirements for how memory containing DT must be > > described in the memory map (Ard mentioned using EfiACPIReclaimMemory). > > > > Maybe something like: >