Hi,

I promised to send my summary of Trusted Substrate architecture council call on HOBs, here it is:

Topics where there seem to be consensus

Scope include diverse firmware flows (U-Boot/SPL, TFA, CoreBoot…) on difference 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 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) 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.

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 or flatten device tree fragments/overlays.

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.

Cheers

On Mon, 12 Apr 2021 at 16:49, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> From: Simon Glass <sjg@chromium.org>
> Date: Fri, 9 Apr 2021 06:19:08 +1200
>
> Here are a few thoughts on UUIDs.
> Why a UUID/GUID is probably not the answer
>
> sjg, 30-Mar-21
> Code is for humans
>
> Code should be readable, so far as possible.
>
> This is not readable:
>
> #define FSP_HOB_RESOURCE_OWNER_SMM_PEI_SMRAM_GUID \
>
> EFI_GUID(0x6dadf1d1, 0xd4cc, 0x4910, \
>
> 0xbb, 0x6e, 0x82, 0xb1, 0xfd, 0x80, 0xff, 0x3d)
>
> This is readable:
>
> enum {
>
> BLOBLISTT_SPL_HANDOFF = 123,
>
> };
> UUID is more like a hash than a sequence number

No kidding. Try figuring out what an ACPI ASL methods like _DSM and
_OSC are supposed to do when trying to figure out what the code is
supposed to do.

They're terrible to grep for in source code since there is no uniform
way to format them in the code.

And then there is the issue of byte order of course.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture