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
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
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
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
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
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
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
+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
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.htmlhttps://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