boot-architecture

boot-architecture@lists.linaro.org

1 participants
684 discussions

by François Ozog

Hi, As per the results of the poll (https://docs.google.com/spreadsheets/d/1WdsXgUoS3naL_-5eap1e_Sd9t0PM60s0Ljs…), there will be two calls per month: - 2nd wednesday 2pm UTC - 4th wednesday 2pm UTC 2pm UTC currently corresponds to 7am PST / 4pm CET. Call to be added to your agendas if you did not received it by mail: Device Tree Evolution forum calls. - 2nd Wednesday of the month prime focus: system device tree and RTOS tools. - 4th Wednesday of the month prime focus: device tree life cycle, overlays, authentication and unified repository Those calls are public. Participants are advised they should not introduce topics that relate to confidential matters. https://zoom.us/j/97895025968?pwd=N0JWWFBqY0Npdi9RY2JIOFc1ZzI0UT09 join by phone: https://zoom.us/u/asu8Yfroy meeting ID: 978 9502 5968 Password: 270935 Cordially, François-Frédéric Ozog, Linaro

6 years

[PATCH v2 1/2] Update spec to address UEFI 2.8 Errata A

by 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. However, real world impact is minimal. U-Boot has already converted to the new method, and Linux only ever implemented the EFI_RT_PROPERTIES_TABLE method. Cc: Andrei Warkentin <awarkentin(a)vmware.com> Cc: Francois Ozog <francois.ozog(a)linaro.org> Cc: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter2-uefi.rst | 7 ++++--- source/references.rst | 6 +++--- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 82b1a42..c42691b 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -9,7 +9,7 @@ platforms. UEFI Version ============ -This document uses version 2.8 of the UEFI specification [UEFI]_. +This document uses version 2.8 Errata A of the UEFI specification [UEFI]_. UEFI Compliance =============== @@ -111,7 +111,7 @@ during both boot services and runtime services. However, it isn't always practical for all EFI_RUNTIME_SERVICES functions to be callable during runtime services due to hardware limitations. If any EFI_RUNTIME_SERVICES functions are only available during boot services -then firmware shall provide the global `RuntimeServicesSupported` variable to +then firmware shall provide the `EFI_RT_PROPERTIES_TABLE` to indicate which functions are available during runtime services. Functions that are not available during runtime services shall return EFI_UNSUPPORTED. @@ -202,7 +202,8 @@ If a platform does not implement modifying non-volatile variables with SetVariable() after ExitBootServices(), then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(), and must advertise that SetVariable() isn't available during runtime services -via the `RuntimeServicesSupported` variable as defined in [UEFI]_ § 8.1. +via the `RuntimeServicesSupported` value in the `EFI_RT_PROPERTIES_TABLE` +as defined in [UEFI]_ § 4.6. EFI applications can read `RuntimeServicesSupported` to determine if calls to SetVariable() need to be performed before calling ExitBootServices(). diff --git a/source/references.rst b/source/references.rst index d901bb1..1eb0509 100644 --- a/source/references.rst +++ b/source/references.rst @@ -20,6 +20,6 @@ <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ 8 March 2016, `Arm Limited <http://arm.com>`_ -.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 - <http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf>`_, - March 2019, `UEFI Forum <http://www.uefi.org>`_ +.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A + <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_, + February 2020, `UEFI Forum <http://www.uefi.org>`_ -- 2.20.1

6 years

[PATCH] Update spec to address UEFI 2.8 Errata A

by 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. U-Boot implements the variable method which will need to be changed to a table. It is unclear if any OSes depend heavily on it being implemented. Cc: Andrei Warkentin <awarkentin(a)vmware.com> Cc: Francois Ozog <francois.ozog(a)linaro.org> Cc: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter2-uefi.rst | 7 ++++--- source/references.rst | 6 +++--- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index fe03ae3..b622abe 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -9,7 +9,7 @@ platforms. UEFI Version ============ -This document uses version 2.8 of the UEFI specification [UEFI]_. +This document uses version 2.8 Errata A of the UEFI specification [UEFI]_. UEFI Compliance =============== @@ -111,7 +111,7 @@ during both boot services and runtime services. However, it isn't always practical for all EFI_RUNTIME_SERVICES functions to be callable during runtime services due to hardware limitations. If any EFI_RUNTIME_SERVICES functions are only available during boot services -then firmware shall provide the global `RuntimeServicesSupported` variable to +then firmware shall provide the `EFI_RT_PROPERTIES_TABLE` to indicate which functions are available during runtime services. Functions that are not available during runtime services shall return EFI_UNSUPPORTED. @@ -202,7 +202,8 @@ If a platform does not implement modifying non-volatile variables with SetVariable() after ExitBootServices(), then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(), and must advertise that SetVariable() isn't available during runtime services -via the `RuntimeServicesSupported` variable as defined in [UEFI]_ § 8.1. +via the `RuntimeServicesSupported` value in the `EFI_RT_PROPERTIES_TABLE` +as defined in [UEFI]_ § 4.6. EFI applications can read `RuntimeServicesSupported` to determine if calls to SetVariable() need to be performed before calling ExitBootServices(). diff --git a/source/references.rst b/source/references.rst index d901bb1..1eb0509 100644 --- a/source/references.rst +++ b/source/references.rst @@ -20,6 +20,6 @@ <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ 8 March 2016, `Arm Limited <http://arm.com>`_ -.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 - <http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf>`_, - March 2019, `UEFI Forum <http://www.uefi.org>`_ +.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A + <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_, + February 2020, `UEFI Forum <http://www.uefi.org>`_ -- 2.20.1

6 years

[PATCH] trivial: Fix typo in chater 3 title

by Grant Likely

Fixes: #42 Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter3-secureworld.rst | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/source/chapter3-secureworld.rst b/source/chapter3-secureworld.rst index 4e9fa61..9c51bca 100644 --- a/source/chapter3-secureworld.rst +++ b/source/chapter3-secureworld.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -****************************** -Priviledged or Secure Firmware -****************************** +***************************** +Privileged or Secure Firmware +***************************** AArch32 Multiprocessor Startup Protocol ======================================= -- 2.20.1

6 years

DTE call meeting notes

by François Ozog

Hi, Thank you for your participation in yesterday's call. Here are meeting notes that you can update <https://docs.google.com/document/d/13TwImAK9bta5_qY2PAFplO6pypd0hpNQNkpkI_W…>as you see fit (I think the permissions associated with this new link are correct). Survey was answered by 12 participants while there were 27 people on the call. I would be more comfortable to select a time with more responses. Cordially, François-Frédéric -- François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

6 years

DTE discussion agenda

by François Ozog

Hi, Here is the agenda for today's call <http://meet.google.com/oua-wrbf-ppi>: - DTE activities for the next cycle and overall organization - Regular meeting setup (survey <https://www.surveymonkey.com/r/F72TLPF>) - System Device Tree status and roadmap (JIRA?) this topic depends on presence of SDT stakeholders - Device Tree specification: its role in the future and short term - Device Tree lifecycle (what happens to a DT from TFA to OS): a presentation and a discussion Cheers FF

6 years

DTE weekly

by François Ozog

Hi, I am taking over Steve to drive Device Tree Evolution project except the System Device Tree which will continue to evolve under the leadership of Nathalie and Stefano. To discuss: - lifecycle (how TFA, OP-TEE, U-Boot and Operating Systems deal with DT and pass information between them) - overlays - unified repo - summary of System DT activities I'd like to set up a weekly call starting next week. Please state the best timeslot in this poll: https://www.doodle.com/poll/k57zhwa4q9caivgy (the poll proposes the timeslot to be repeated). By next week, Joakim, Ilias and myself will have prepared some content to launch/continue debate. Cordially, François-Frédéric -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

6 years

Invitation: DTE discussion @ Mon 4 May 2020 18:00 - 19:00 (CEST) (boot-architecture@lists.linaro.org)

by François Ozog

You have been invited to the following event. Title: DTE discussion This is a one off meeting unless we find a sustainable timeslot for India participants. When: Mon 4 May 2020 18:00 – 19:00 Central European Time - Paris Joining info: Join with Google Meet https://meet.google.com/oua-wrbf-ppi Join by phone +33 1 87 40 48 87 (PIN: 588964477) More phone numbers: https://tel.meet/oua-wrbf-ppi?pin=4737911870439&hs=0 Calendar: boot-architecture(a)lists.linaro.org Who: * François Ozog- organiser * boot-architecture(a)lists.linaro.org * team-ledge * dte-all Event details: https://www.google.com/calendar/event?action=VIEW&eid=NzRkanQyMXZtOWwzc2xic… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account boot-architecture(a)lists.linaro.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years

Re: DTE-8 DeviceTree lifecycle: the basics

by François Ozog

+boot architecture Le sam. 25 avr. 2020 à 19:26, François Ozog <francois.ozog(a)linaro.org> a écrit : > Hi > > I would like to start the discussion on DTE-8 as LEDGE is going to need > results soon. I'd like to keep it high level, general principles, not too > precise on implementation details. Let's take overlays and other > complications out of the discussion until we share a vision for the basics. > > When we have concluded this discussion cycle we will need to address: > - DTE-8 DeviceTree lifecycle: BL32 (BL32 may mask some devices until > given credentials...) > - DTE-8 DeviceTree lifecycle: overlays > - DTE-8 DeviceTree lifecycle: tooling > - DTE-8 DeviceTree lifecycle: chain of trust > > Is the following correct? > Is it complete on the target reduced scope? > Is the discussion series/roadmap complete, is the order right ? > > Cordially, > > François-Frédéric > > > I - Definitions > > Let's consider there are four trees used by the following entities: > - TFA which spans BL1, BL2, BL31 has a tree <TFA> which originates from > tfa.dtb > - BL32 (let's assume OP-TEE) has a tree <BL32> which originates from > bl32.dtb > - BL33 (let's assume U-Boot) has a tree <BL33> which originates from > bl33.dtb > - THING, the "thing" that is booted by BL33, has a tree <THING> which > originates from thing.dtb and manipulations from BL33. > > The THING can be a Linux kernel, a bsd kernel, grub, shim<arch>.efi, > efibootguard.efi, Xen, Hafnium or many other possibilities. > BL33 is assumed to be U-Boot but it can be EDK2, Linux Kernel, Hafnium, > Xen or other thing. > > A tree is not dtb. A tree is the result of loading a DTB with or without > manipulations. > > II - Build time assumptions > > It is assumed that TFA, BL32 and BL33 are board specific while THINGS is > board agnostic. > > As a result of this architectural decision: > - tfa.dtb, bl32.dtb and bl33.dtb can be built by the build process of the > respective entity TFA, BL32, BL33. > - thing.dtb is purely describing hardware and has no "chosen" nodes for > instance, it may contain architectural/platform/board specific > "reserved-memory". In other words, nothing that can tie it to a particular > "thing". > > All DTBs shall be derived from a single source repository. > > The bindings of a single piece of hardware, may differ depending on the > entity that needs it (there are many ways to implement that aspect, let's > not talk about implementation yet). > For instance, a display panel for BL33 can be represented as a single > small node while the same display panel can be controlled out of several > large nodes by a downstream Operating System. > > III - Lifecycle > > Out of all possible transitions, let's consider BL31->BL33 and > BL33->THING. Transitions are opportunities to pass DT information from one > entity to the other that complements the static *.dtb . For instance, > passing PSCI interface information, memory reservations, PCI IO ranges... > > III.1 BL31->BL33 > > III.1.1 nature of manipulations > typically, PSCI interface may be injected as well some memory > reservations. > > III.1.2 manipulation operational considerations > There are three possibilities for passing this information: > - BL31 manipulates the BL33 tree to add/change nodes > - BL33 asks BL31 to add/change nodes > - BL31 passes an interim tree that BL33 will merge into his. > > Current wisdom is BL31 manipulates the BL33 tree. > > III.2 BL33->THING > > III.2.1 nature of manipulations > * operational > - board information (part numbers, serial numbers...) > - memory layout (beyond the typical 4G) > - IO specifics (PCIe...) > - reserved areas for runtime services (UEFI for instance) > - os.dtb > * THING dependent elements > - chosen for "command line" or other aspects > > III.2.2 manipulation operational considerations > In the case of UEFI interface, os.dtb passed as DT artifact or a UEFI > table shall be referring to the same tree (a single tree in memory, two > access methods). > > BL33 will operate all necessary manipulations on os.dtb before passing it > to the THING. The THING (grub, efiapp, kernel) can further operate > manipulations, it is outside scope of the discussion. > > > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > francois.ozog(a)linaro.org | Skype: ffozog > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

6 years

[RFC] Systemd-boot and EBBR

by François Ozog

Hi, I instrumented boot on my Ubuntu 18.04 server right after systemd startup and caught an access to: /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f This led to: https://systemd.io/DISCOVERABLE_PARTITIONS/ And then: https://systemd.io/BOOT_LOADER_INTERFACE/ https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ My server is configured with Grub to boot (grub and kernel on a HD, root FS of NVME as grub do not have nvme driver for my card) but the udev is still checking those systemd-boot variables. >From a boot loader perspective, we have the following EFI applications: - Grub2 - EFIBootGuard (used by CIP) - Systemd-boot (used by ?) Regardless of the loader, I assume we need to ensure whatever option is selected by solution builders, they can implement it with our U-Boot reference implementation of UEFI. The Systemd boot-bless seems of high interest for rolling back UEFI update capsules of firmware... I'd be happy to get some feed back on : - the systemd-boot technology - whether we need to implement the above specs in our UEFI implementation - whether this has an influence on EBBR Cheers FF PS: other references https://manpages.debian.org/testing/systemd/systemd-boot.7.en.html https://manpages.debian.org/testing/systemd/systemd-bless-boot.service.8.en… http://man7.org/linux/man-pages/man1/bootctl.1.html -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

6 years, 1 month

← Newer
1
...
31
32
33
34
35
36
37
...
69
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture