Hi
Open System Firmware and Trusted Firmware communities have common interests in driving *some* firmware discussions because upstream projects like EDK2, U-Boot and Linux boot greatly benefit from common approaches regardless of processor architecture and early firmware components.
The discussion on passing metadata between early firmware components and from early firmware to EDK2/U-Boot/LinuxBoot is typically such a topic.
EDK2 is the only project that has defined metadata in the form of Platform Initialization HOBs (chapter 5 of PI spec). U-Boot and LinuxBoot have platform specific techniques to consume that metadata. Let's make sure that at least there is common solution for those two and hope that the result is enticing enough that EDK2 decide to leverage the result one way or the other.
Here is a patched repost of the state of discussion after last Trusted Substrate call:
Topics where there seem to be consensus
- Scope include diverse firmware flows (U-Boot/SPL, TFA, CoreBoot…) on different architectures (Arm, RiscV) - Definitions: The Hand Over Function is the firmware component that hands off to the booted payload = {OS/Hypervisor/Grub/Shim}. - Hand Over Function can be EDK2, U-Boot or LinuxBoot. - The HOF, through ACPI or DT is responsible to describe what shall be controlled and partly how (some parameters) - *There is information that can only be discovered at runtime by diverse early firmware components and needs to be conveyed through the HOF to the booted payload.*
- The proposal is to convey that dynamic information in the form of HandOverBlocks (HOBs - generic idea, not the EDK2 construct) whose format is yet to be defined and built as a linked list of objects. The other proposal to use call backs (mmc calls or equivalent) from HOF to firmware is rejected. In Arm architecture, that choice does not preclude some firmware components to use SCMI calls into SCP to obtain authoritative information.
- The firmware components shall not care about what is the actual HOF: the format is standard regardless if HOF is EDK2, U-Boot or LinuxBoot. In TF-A words, the HOBs become part of the input ABI for BL33. In the best world, it should be possible for the platform "buyer" to choose the HOF.
Characteristics to consider about HOBs:
- HOBs can be built by very early components and must fit into highly constrained SRAM - A HOB may be passed between different firmware components, secure and non-secure. - A HOB can be built by secure and non-secure firmware components - An information can have a single format: no alternative representation is allowed. In other words if the information is passed as a data structure it cannot be represented by a DT fragment by another implementation and conversely.
Topics that need more discussion
- HOBs need a way to be identified: UUID, ID, hybrid (like Platform Initialization).
*My views: the hybrid allows constraints firmware components to be using simple IDs and richer components may want leverage UUIDs (same as Platform Initialization).*
- HOB format: binary information; just static structure, flatten device tree fragments/overlays or even CBOR.
*My views: again hybrid approach seem very efficient. Static structures for memory information, DT fragment for device assignment (for non-secure partitions or for secure world / secure partitions). Typically I would imagine a UUID HOB with a DT fragment seems just good. This is actually implemented like that with Platform Initialization:*
*HOBs are identified by a simple ID, out of IDs are EFI_HOB_RESOURCE_DESCRIPTOR for DRAM description and EFI_HOB_GUID_TYPE that contains something identified by a GUID. There is a GUID used in the context of EDK2 to actually contain a DT fragment today.*
*As an open specification that allows extension, there shall be a mandate to publish an open specification of any extension.*
On Fri, 16 Apr 2021 at 07:51, François Ozog via TF-A < tf-a@lists.trustedfirmware.org> wrote:
+tf.org as the discussion evolved to a topic discussed there.
Le ven. 16 avr. 2021 à 01:25, Zimmer, Vincent vincent.zimmer@intel.com a écrit :
For the wayback machine, the design of HOB’s dates back to early 2000’s.
The HOB defin was part of the Intel Framework specs & it was made public in 2003 through a click-through, as folks noted. HOBs became part of the UEFI Forum Platform Initialization (PI) spec in 2006. Essentially PI 1.0 absorbed most of the Framework 0.9x specs (sans datahub, CSM).
from https://link.springer.com/book/10.1007/978-1-4842-0070-4
IMHO the biggest bug on the present Type Length Value (TLV)-based HOB design entails the “L” of the TLV, namely the 16-bit length limitation on the size of a specific HOB. Servers often bump into this limitation today given the amount of state discovered in these early initialization flows. The use of GUID’s w/o strings is also a usability challenge, I’d agree, that any new design can address.
Going forward
The more recent proposed use of HOB's for the generic payload interface https://github.com/universalpayload/documentation launching was more for convenience since it's a simple TLV encoded mechanism and there are parsing libraries already in the wild. But the use of HOB’s versus DT versus …. for the inargs of the payload is definitely open for discussion/change in the design. The earlier thread suggestions of CBOR/8949 https://www.rfc-editor.org/rfc/rfc8949.html from Francois/Nate is interesting. We can update the already open issue on this topic https://github.com/universalpayload/documentation/issues/9 with some of these thoughts and build upon the sentiments Ron shared earlier on the topic.
And regarding the payload specification https://universalpayload.github.io/documentation/ mentioned above, I’m happy to present on this design effort in an upcoming OSF meeting, including how payloads may relate to the OSF workstream. The payload design is intended to be an open process with a code-first workflow that doesn’t tie itself to any specific bootloader design, as demonstrated by the different bootloaders and payloads ported at https://github.com/universalpayload. Although there isn’t a U-Boot example ported (I thought I heard mention of U-boot in this thread or meeting?), addressing the needs of U-boot and other *boot solutions (e.g., oreboot) is definitely part of the design scope intent, too.
Thanks,
Vincent
-----Original Message----- From: OCP-OSF@OCP-All.groups.io OCP-OSF@OCP-All.groups.io On Behalf Of ron minnich Sent: Thursday, April 15, 2021 3:14 PM To: Desimone, Nathaniel L nathaniel.l.desimone@intel.com Cc: OCP-OSF@OCP-All.groups.io; Boot Architecture Mailman List < boot-architecture@lists.linaro.org>; Leif Lindholm leif@nuviainc.com Subject: Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence
actually isn't device tree a 1980s design :-)
anyway, as long as we can hit the things I care so much about,
self describing
alignment independent
endian independent
names not magic numbers (I mean, you want to put a UUID in there too, fine, but I doubt a human-readable string will kill us on space)
it can be anything you all think best.
On Thu, Apr 15, 2021 at 2:49 PM Desimone, Nathaniel L < nathaniel.l.desimone@intel.com> wrote:
On Thu, Apr 15, 2021 at 1:29 -0700, ron minnich wrote:
I'd rather not take HOB as a given without considering alternatives.
It's a very 1990s design.
Device tree is also a very early 90s design for that matter. If we are
talking about clean slate design, how about something actually new and modern like RFC 8949?
From a practical standpoint I don't see HOBs going away very soon but
I'm open to possibility thinking on a long term basis.
_._,_._,_
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#149) https://OCP-All.groups.io/g/OCP-OSF/message/149 | Reply To Group <OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Reply To Sender <vincent.zimmer@intel.com?subject=Private:%20Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Mute This Topic https://groups.io/mt/81937262/675475 | New Topic https://OCP-All.groups.io/g/OCP-OSF/post Your Subscription https://OCP-All.groups.io/g/OCP-OSF/editsub/675475 | Contact Group Owner OCP-OSF+owner@OCP-All.groups.io | Unsubscribe https://OCP-All.groups.io/g/OCP-OSF/leave/10214763/675475/1625423992/xyzzy [francois.ozog@linaro.org] _._,_._,_
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
tf-a@lists.trustedfirmware.org
-
François Ozog