boot-architecture August 2020

boot-architecture@lists.linaro.org

16 participants
14 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

4 years, 12 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

5 years

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.

5 years

[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

5 years

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

by Stefano Stabellini

On Mon, 31 Aug 2020, Bjorn Andersson via System-dt wrote: > On Mon 31 Aug 16:04 UTC 2020, Tomas Evensen via System-dt 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 > > Can anyone point me to some examples of vendor specific information > referred to here? Some of the other attendees might have better examples than this. The ones I was mentioning this morning are the "mboxes" and "mbox-names" properties you can see in the "output.txt" example. Also the memory regions listed under the "memory-region" property and under "reserved-memory".

5 years

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

by Stefano Stabellini

On Mon, 31 Aug 2020, Tomas Evensen via System-dt wrote: > Stefano to send out examples and slides I am attaching the slides and examples, where: - input.txt is the system device tree snippet, input to lopper - output.txt is the traditional device tree snipper, output from lopper

5 years

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

by Bjorn Andersson

On Mon 31 Aug 16:04 UTC 2020, Tomas Evensen via System-dt 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 Can anyone point me to some examples of vendor specific information referred to here? Regards, Bjorn > > 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. > -- > System-dt mailing list > System-dt(a)lists.openampproject.org > https://lists.openampproject.org/mailman/listinfo/system-dt

5 years

DTE call this Wednesday

by François Ozog

Hi, This Wednesday agenda is: - Presentation of RiscV DT by Atish Patra - Proposal of DT authentication/identification/format PoC by Joakim/FF Cordially, FF

5 years

Restarting EBBR biweekly meetings

by Grant Likely

It has been a long time since there has been a regular EBBR review meeting, and with the amount of activity that has happened in the last year I think it is time to start meeting again. I'd like to start talking about content for EBBR v1.0+. A biweekly cadence seems about right to me, but we can discuss when we start meetings again. Would Monday, 31 Aug at 16:00BST, 08:00PST work? Email me privately if you want me to send you a calendar invite. Discussion topics: - EBBR testing progress - EBBR Scope -- doing a better job to describe the purpose of EBBR - Tightening requirements as U-Boot implementation matures (make fewer things optional) - Security requirements - Secure boot and secure capsule update - issue review - Signing requirements on dtbs and variables Send me an email if you want to add to the agenda, or add an issue to the github page: https://github.com/arm-software/ebbr/issues g. ---- Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Password: 490324 One tap mobile +14086380968,,92081365511#,,#,490324# US (San Jose) +16465189805,,92081365511#,,#,490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Password: 490324 Find your local number: https://armltd.zoom.us/u/adYiWaDyys IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years

Trusting DT

by François Ozog

Hi, I just updated the technical report <https://docs.google.com/document/d/1CLkhLRaz_zcCq44DLGmPZQFPbYHOC6nzPowaL0X…> with a section on "Trusting DT" that is the result of my analysis of the discussion we had (not what I presented). Please comment, correct, update... Cordially, FF -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture August 2020