boot-architecture September 2020

boot-architecture@lists.linaro.org

14 participants
16 discussions

[PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property

by Heinrich Schuchardt

Closes: #52 The no-map property of the /reserved-memory DT node is used by Linux to signal that a memory region shall not be mapped and that speculative access shall not be permitted. The memory map returned by GetMemoryMap() does not have a flag corresponding to no-map. So the closest thing we can do is not to include no-map reserved memory into the map returned by GetMemoryMap(). Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- source/chapter2-uefi.rst | 4 ++++ source/references.rst | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 2add2de..1e57164 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -74,6 +74,10 @@ that virtual addresses must equal physical addresses. The default RAM allocated attribute must be EFI_MEMORY_WB. +Reserved memory with property no-map [RESMEM]_ in the /reserved-memory +device-tree node shall not be included in the memory map returned by +GetMemoryMap(). + Configuration Tables -------------------- diff --git a/source/references.rst b/source/references.rst index 1eb0509..2434137 100644 --- a/source/references.rst +++ b/source/references.rst @@ -16,6 +16,10 @@ <https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_ 30 January 2015, `Arm Limited <http://arm.com>`_ +.. [RESMEM] `Reserved memory regions + <https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memor…>`_, + 21 July 2020, Linux kernel + .. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ 8 March 2016, `Arm Limited <http://arm.com>`_ -- 2.28.0

3 years, 7 months

[EBBR RFC] Remove the exclusive-or language around DT or ACPI

by Grant Likely

Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions. However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not. Thoughts? Can the exclusive or be relaxed here? Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table. -Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables: - an Advanced Configuration and Power Interface [ACPI]_ table, or - a Devicetree [DTSPEC]_ system description -EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader. - Devicetree ^^^^^^^^^^ -- 2.20.1

3 years, 8 months

Re: [System-dt] Notes (brief) from System DT call: OpenAMP bindings

by Stefano Stabellini

On Tue, 1 Sep 2020, François Ozog via System-dt wrote: > On Tue, 1 Sep 2020 at 14:49, Tomas Evensen <tomase(a)xilinx.com> wrote: > Here are some brief notes from the meeting. > > If nothing else as a showcase on how much we miss Nathalie when she is on vacation 😉 > > Krzysztof Kepa – GE > Mathieu Poirier – Linaro > Etsam Anjum – Mentor > Anrnoud Pouliquen – ST > Loic Pallardy - ST > Suman Anna - TI > Dan Milea – Wind River > Mark Dapoz – Wind River > Tomas Evensen – Xilinx > Stefano Stabellini – Xilinx > Bruce Ashfield – Xilinx > Ed Mooring – Xilinx > Ben Levinsky - Xilinx > > Stefano went through slides. > Overall idea: > > 1. Specify remoteproc channels with minimal information in System-DT in a way that is as common as possible for all vendors. > In particular, we are avoiding to have to specify the same memory regions in more than one place. A resource group is specially > marked to contain most information. > 2. Use Lopper to create the vendor specific remoteproc specification > Generating reserved-memory, etc. information that has duplicate information. > For the time being, no plans to unify the vendor specific information that goes into the traditional device tree for Linux > 3. Later (or in parallel), but without making it a gating item, start discussions on what we can do to unify the vendor > specific information in the traditional DT > > Discussion about how TI and ST might generate their specific information from this specification. > > Stefano to send out examples and slides. > Ben: Xilinx backend to Lopper is upstreamed and available as an example. Might change as upstreaming continues. > > Question: > * How do we configure VirtIO? > > Could you describe more the VirtIO question so that relationship with Linaro project Stratos is assessed? I think this point refers to various vdev<x> buffers described under /reserved-memory which are linked from RemoteProc. From the Xilinx bindings: reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed40000 0x4000>; }; rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed44000 0x4000>; }; rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed48000 0x100000>; }; rproc_0_reserved: rproc@3ed000000 { compatible = "xilinx,openamp-ipc-1.0"; no-map; reg = <0x3ed00000 0x40000>; }; };

3 years, 8 months

Storage of public key certificates for capsule authentication

by Sughosh Ganu

hi, I am currently working on adding support for the capsule authentication in the SetImage function of the efi firmware management protocol in u-boot. This work is part of adding functionality in u-boot for firmware updates using the uefi capsule format. The capsule authentication is done using a public key stored as a pkcs7 certificate. The uefi specification does not have any mention of how this certificate needs to be stored. This is unlike the case of the certificates used for image authentication when UEFI secure boot feature is enabled, where the certificates and hash values are stored as part of the authenticated variables like KEK, db, dbx. Can we use an authenticated variable like KEK to store the certificate used for authentication of the capsule payload. Would it make sense to have this mentioned in EBBR, or even the UEFI specification. Please let me know your thoughts. Thanks. -sughosh

3 years, 8 months

Notes (brief) from System DT call: OpenAMP bindings

by Tomas Evensen

Here are some brief notes from the meeting. If nothing else as a showcase on how much we miss Nathalie when she is on vacation 😉 Krzysztof Kepa – GE Mathieu Poirier – Linaro Etsam Anjum – Mentor Anrnoud Pouliquen – ST Loic Pallardy - ST Suman Anna - TI Dan Milea – Wind River Mark Dapoz – Wind River Tomas Evensen – Xilinx Stefano Stabellini – Xilinx Bruce Ashfield – Xilinx Ed Mooring – Xilinx Ben Levinsky - Xilinx Stefano went through slides. Overall idea: 1. Specify remoteproc channels with minimal information in System-DT in a way that is as common as possible for all vendors. In particular, we are avoiding to have to specify the same memory regions in more than one place. A resource group is specially marked to contain most information. 2. Use Lopper to create the vendor specific remoteproc specification Generating reserved-memory, etc. information that has duplicate information. For the time being, no plans to unify the vendor specific information that goes into the traditional device tree for Linux 3. Later (or in parallel), but without making it a gating item, start discussions on what we can do to unify the vendor specific information in the traditional DT Discussion about how TI and ST might generate their specific information from this specification. Stefano to send out examples and slides. Ben: Xilinx backend to Lopper is upstreamed and available as an example. Might change as upstreaming continues. Question: * How do we configure VirtIO? From: nathalie(a)xilinx.com When: 8:00 AM - 9:00 AM August 31, 2020 Subject: [System-dt] System DT call: OpenAMP bindings Location: webex CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. Hi all, The OpenAMP-remoteproc working group is looking forward to discuss OpenAMP bindings with the System DT working group & all others interested in System DT. Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source & Community Meeting number (access code): 145 853 2028 Meeting password: NgTwf4r8R$3 Monday, August 31, 2020 8:00 am | (UTC-07:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=mcd4ad9bca009dfef38671c26d5a1d301> Canada toll free 1-844-426-4405 France toll free 0800-912-485 India toll free 000-800-040-1016 Sweden toll free 020-033-6721 UK toll free 08000315372 United States Toll Free 1-844-621-3956 Global call-in numbers<https://xilinx.webex.com/xilinx/globalcallin.php?MTID=m370fae0984a8792a3592…> | Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

3 years, 8 months

[PATCH] EBBR: ResetSystem has return type void

by Heinrich Schuchardt

Closes: #50 ResetSystem() has return type void. So it cannot return EFI_UNSUPPORTED. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- source/chapter2-uefi.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 2add2de..74ef70e 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -209,9 +209,10 @@ ResetSystem() is required to be implemented in boot services, but it is optional for runtime services. During runtime services, the operating system should first attempt to use ResetSystem() to reset the system. -If firmware doesn't support ResetSystem() during runtime services, -then the call will immediately return EFI_UNSUPPORTED, and the OS should -fall back to an architecture or platform specific reset mechanism. + +If firmware doesn't support ResetSystem() during runtime services, then the call +will immediately return, and the OS should fall back to an architecture or +platform specific reset mechanism. On AArch64 platforms implementing [PSCI]_, if ResetSystem() is not implemented then the Operating System should fall -- 2.28.0

3 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture September 2020