This sounds like a useful abstraction to me. I can see it being useful
when we need to pass TPM logs from one stage to another, or to pass on
firmware update status. Things that /could/ be stuffed into a single
devicetree, but it is awkward to rewrite the devicetree for every piece
of dynamic data that gets generated and passed on. It would also be
helpful if a common approach can be used regardless of the normal-world
firmware (i.e., EDK2, U-Boot, or something else).
g.
Hello Folks,
I'm emailing to start an open discussion about the adoption of a concept
known as "hand-off blocks" or HOB to become a part of the TF-A Firmware
Framework Architecture (FFA).� This is something that is a pretty major
pain point when it comes to the adoption of TF-A in ARM Server SoC�s
designed to enable a broad range of highly configurable datacenter
platforms.
What is a HOB (Background)?
UEFI PI spec describes a particular definition for how HOB may be used
for transitioning between the PEI and DXE boot phases, which is a good
reference point for this discussion, but not necessarily the exact
solution appropriate for TF-A.
A HOB is simply a dynamically generated data structure passed in between
two boot phases.� This is information that was obtained through
discovery and needs to be passed forward to the next boot phase *once*,
with no API needed to call back (e.g. no call back into previous
firmware phase is needed to fetch this information at run-time - it is
simply passed one time during boot).
There may be one or more HOBs passed in between boot phases.� If there
are more than one HOB that needs to be passed, this can be in a form of
a "HOB table", which (for example) could be a UUID indexed array of
pointers to HOB structures, used to locate a HOB of interest (based on
UUID).� In such cases, instead of passing a single HOB, the boot phases
may rely on passing the pointer to the HOB table.
This has been extremely useful concept to employ on highly configurable
systems that must rely on flexible discovery mechanisms to initialize
and boot the system.� This is especially helpful when you have multiple
Why do we need HOBs in TF-A?:
It is desirable that EL3 firmware (e.g. TF-A) built for ARM Server SoC
in a way that is SoC specific *but* platform agnostic.� This means that
a single ARM SoC that a SiP may deliver to customers may provide a
single TF-A binary (e.g. BL1, BL2, BL31) that could be used to support a
broad range of platform designs and configurations in order to boot a
platform specific firmware (e.g. BL33 and possibly even BL32 code).� In
order to achieve this, the platform configuration must be *discovered*
instead of statically compiled as it is today in TF-A via device tree
based enumeration.� The mechanisms of discovery may differ broadly
depending on the relevant industry standard, or in some cases may have
rely on SiP specific discovery flows.
For example:� On server systems that support a broad range DIMM memory
population/topologies, all the necessary information required to boot is
fully discovered via standard JEDEC Serial Presence Detect (SPD) over an
I2C bus.� Leveraging the SPD bus, may platform variants could be
supported with a single TF-A binary.� Not only is this information
required to initialize memory in early boot phases (e.g. BL2), the
subsequent boot phases will also need this SPD info to construct a
system physical address map and properly initialize the MMU based on the
memory present, and where the memory may be present.� Subsequent boot
phases (e.g. BL33 / UEFI) may need to generate standard firmware tables
to the operating systems, such as SMBIOS tables describing DIMM topology
and various ACPI tables (e.g. SLIT, SRAT, even NFIT if NVDIMM's are
present).
In short, it all starts with a standardized or vendor specific discovery
flow in an early boot stage (e.g. BL1/BL2), followed by the passing of
information to the next boot stages (e.g. BL31/BL32/BL33).
Today, every HOB may be a vendor specific structure, but in the future
there may be benefit of defining standard HOBs.� This may be useful for
memory discovery, passing the system physical address map, enabling TPM
measured boot, and potentially many other common HOB use-cases.
It would be extremely beneficial to the datacenter market segment if the
TF-A community would adopt this concept of information passing between
all boot phases as opposed to rely solely on device tree enumeration.
This is not intended to replace device tree, rather intended as an
alternative way to describe the info that must be discovered and
dynamically generated.
Conclusion:
We are proposing that the TF-A community begin pursuing the adoption of
HOBs as a mechanism used for information exchange between each boot
stage (e.g. BL1->BL2, BL2->BL31, BL31->BL32, and BL31->BL33)? Longer
term we want to explore standardizing some HOB structures for the BL33
phase (e.g. UEFI HOB structures), but initially would like to agree on
this being a useful mechanism used to pass information between each boot
stage.
Thanks,
--Harb
Grant Likely