Hi Harb, Thanks for the idea. I am still not completely sure what benefit UUID provides to an open project. I'd like to propose something different, more in the spirit of open collaboration. I also worry that the word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. enabling/preferring closed-source firmware and the continued decline of open-source projects. It really should not be.
So I suggest: Use simple integer IDs and reserve some area for 'private' use. If you want to collaborate across projects outside your company, you either need to allocate a 'public' ID or agree privately between the parties which private ID to use. This means that the default and easiest option is for collaboration and a public ID, with private ones (whose purpose may be secret) reserved just for private use. Regards, Simon On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS < abdulha...@os.amperecomputing.com> wrote: > Hey Folks, > > We wanted to put out a middle-ground proposal to help guide the discussion > on the call tomorrow. > > > > A proposal that we have been discussing offline involves reserving a > single tag ID for the purpose of construction UEFI PI HOB List structure, > and that tag would be used to identify a HOB-specific structure that does > leverage UUID based identifier. This will eliminate the burden of having > to support UUID as the tag, and this enables projects that require UUID > based identifiers for the broad range of HOB structures that need to be > produced during the booting of the platform. Once we have a tag for a HOB > list, this will enable various HOB producers that can add/extend the HOB > list in TF-A code (or even pre-TF-A code), with a HOB consumer for that > UUID/GUID on the other side (i.e. whatever the BL33 image is booting on > that platform). > > > > Essentially, the idea is if someone would like to support HOB structures > in a standard way using TF-A, they would wrap it up in a BL_AUX_PARAM/BLOB > structure (whatever the group decides) and the way we identify the > structure as a HOB list is with this new reserved tag. > > > > Hopefully that makes sense and less contentious. Look forward to discuss > this further on the call. > > > > Thanks, > > --Harb > > > > *From:* Manish Pandey2 <manish.pand...@arm.com> > *Sent:* Friday, April 30, 2021 8:14 AM > *To:* François Ozog <francois.o...@linaro.org> > *Cc:* Simon Glass <s...@chromium.org>; Julius Werner <jwer...@chromium.org>; > Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot Architecture > Mailman List <boot-architect...@lists.linaro.org>; > t...@lists.trustedfirmware.org; U-Boot Mailing List <u-boot@lists.denx.de>; > Paul Isaac's <paul.isa...@linaro.org>; Ron Minnich <rminn...@google.com> > *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > Hi All, > > > > *Please find invite for next TF-A Tech Forum session to continue our > discussions on HOB implementation, feel free to forward it to others.* > > > > The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 > (BST). > > > > Agenda: > > - Discussion Session: Static and Dynamic Information Handling in TF-A > > > - Lead by Manish Pandey and Madhukar Pappireddy > > · There is ongoing mailing lists discussion[1] related with > adopting a mechanism to pass information through boot stages. > > The requirement is two-fold: > > 1. Passing static information(config files) > > 2. Passing dynamic information (Hob list) > > In the upcoming TF-A tech forum, we can start with a discussion on dynamic > information passing and if time permits, we can cover static information > passing. The purpose of the call is to have an open discussion and continue > the discussion from the trusted-substrate call[2] done earlier. We would > like to understand the various requirements and possible ways to implement > it in TF-A in a generalized way so that it can work with other Firmware > projects. > > > > The two specific item which we would like to discuss are: > > 1. HOB format: TF-A/u-boot both has an existing bloblist > implementation, which uses tag values. Question, can this be enhanced to > use hybrid values(Tag and UUID) both? > > 2. Standardization on Physical register use to pass base of HoB data > structure. > > References: > > [1] > https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html > > [2] > https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQnHTqzgA5Wav0qOO8n7SAM0yj-Hg.mLyFkVJNB1vDKqw_ > Passcode: IPn+5q% > > > > Thanks > > > > Joanna > > > *You have been invited to the following event.* TF-A Tech Forum > > When > > Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time > > Calendar > > t...@lists.trustedfirmware.org > > Who > > • > > Bill Fletcher- creator > > • > > t...@lists.trustedfirmware.org > > *more details » > <https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrMTkxNHJ0MWdqZDIgdGYtYUBsaXN0cy50cnVzdGVkZmlybXdhcmUub3Jn&tok=NjMjbGluYXJvLm9yZ19oYXZqdjJmaWdyaDVlZ2FpdXJiMjI5cGQ4Y0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29tMDVmNzVlNmQ2YzJjMzcwMTRmMmUyZDBkNzYzNmNiODIwMGU5NDI5Nw&ctz=Europe%2FLondon&hl=en_GB&es=0>* > > > > We run an open technical forum call for anyone to participate and it is > not restricted to Trusted Firmware project members. It will operate under > the guidance of the TF TSC. > > > > Feel free to forward this invite to colleagues. Invites are via the TF-A > mailing list and also published on the Trusted Firmware website. Details > are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ > <https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetings%2Ftf-a-technical-forum%2F&sa=D&ust=1592587253515000&usg=AOvVaw0RDjjhVrGvCfZnSVkoArNN> > > > > Trusted Firmware is inviting you to a scheduled Zoom meeting. > > > > Join Zoom Meeting > > https://zoom.us/j/9159704974 > <https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&ust=1592587253515000&usg=AOvVaw0Wqwu3aHeTRWoaF_9AQwgq> > > > > Meeting ID: 915 970 4974 <(915)%20970-4974> > > > > One tap mobile > > +16465588656 <(646)%20558-8656>,,9159704974 <(915)%20970-4974># US (New > York) > > +16699009128 <(669)%20900-9128>,,9159704974 <(915)%20970-4974># US (San > Jose) > > > > Dial by your location > > +1 646 558 8656 <(646)%20558-8656> US (New York) > > +1 669 900 9128 <(669)%20900-9128> US (San Jose) > > 877 853 5247 <(877)%20853-5247> US Toll-free > > 888 788 0099 <(888)%20788-0099> US Toll-free > > Meeting ID: 915 970 4974 <(915)%20970-4974> > > Find your local number: https://zoom.us/u/ad27hc6t7h > <https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&ust=1592587253515000&usg=AOvVaw0oU7jjBlz1P9VncfgjPkAL> > > > > ------------------------------ > > *From:* François Ozog <francois.o...@linaro.org> > *Sent:* 08 April 2021 16:50 > *To:* Manish Pandey2 <manish.pand...@arm.com> > *Cc:* Simon Glass <s...@chromium.org>; Julius Werner <jwer...@chromium.org>; > Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot Architecture > Mailman List <boot-architect...@lists.linaro.org>; > t...@lists.trustedfirmware.org <t...@lists.trustedfirmware.org>; U-Boot > Mailing List <u-boot@lists.denx.de>; Paul Isaac's <paul.isa...@linaro.org>; > Ron Minnich <rminn...@google.com> > *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > Hi > > > > here is the meeting recording: > > > https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQnHTqzgA5Wav0qOO8n7SAM0yj-Hg.mLyFkVJNB1vDKqw_ > Passcode: IPn+5q%z > > > > I am really sorry about the confusion related to the meeting time. I have > now understood: the Collaborate portal uses a specific calendar which is > tied to US/Chicago timezone while the actual Google Calendar is tied to > Central Europe timezone. I am going to drop the Collaborate portal and use > a shared Google calendar (it should be visible on the > trusted-substrate.org page). > > > > I'll try to summarize what I learnt and highlight my view on what can be > next steps in a future mail. > > > > Cheers > > > > FF > > > > On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A < > t...@lists.trustedfirmware.org> wrote: > > Hi, > > > > From TF-A project point of view, we prefer to use existing mechanism to > pass parameters across boot stages using linked list of tagged elements (as > suggested by Julius). It has support for both generic and SiP-specific > tags. Having said that, it does not stop partners to introduce new > mechanisms suitable for their usecase in platform port initially and later > move to generic code if its suitable for other platforms. > > > > To start with, Ampere can introduce a platform specific implementation of > memory tag(speed/NUMA topology etc) which can be evaluated and discussed > for generalization in future. The tag will be populated in BL2 stage and > can be forwarded to further stages(and to BL33) by passing the head of list > pointer in one of the registers. Initially any register can be used but > going forward a standardization will be needed. > > > > The U-boot bloblist mentioned by Simon is conceptually similar to what > TF-A is using, if there is consensus of using bloblist/taglist then TF-A > tag list may be enhanced to take best of both the implementations. > > > > One of the potential problems of having structure used in different > projects is maintainability, this can be avoided by having a single copy of > these structures in TF-A (kept inside "include/export" which intended to be > used by other projects.) > > > > Regarding usage of either UUID or tag, I echo the sentiments of Simon and > Julius to keep it simple and use tag values. > > > > Looking forward to having further discussions on zoom call today. > > > > Thanks > > Manish P > > > ------------------------------ > > *From:* TF-A <tf-a-boun...@lists.trustedfirmware.org> on behalf of Julius > Werner via TF-A <t...@lists.trustedfirmware.org> > *Sent:* 25 March 2021 02:43 > *To:* Simon Glass <s...@chromium.org> > *Cc:* Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot > Architecture Mailman List <boot-architect...@lists.linaro.org>; > t...@lists.trustedfirmware.org <t...@lists.trustedfirmware.org>; U-Boot > Mailing List <u-boot@lists.denx.de>; Paul Isaac's <paul.isa...@linaro.org>; > Ron Minnich <rminn...@google.com> > *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > Just want to point out that TF-A currently already supports a (very > simple) mechanism like this: > > > > > https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/include/export/lib/bl_aux_params/bl_aux_params_exp.h > > > https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/lib/bl_aux_params/bl_aux_params.c > > > https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/plat/rockchip/common/params_setup.c > > > > It's just a linked list of tagged elements. The tag space is split into > TF-A-wide generic tags and SiP-specific tags (with plenty of room to spare > if more areas need to be defined -- a 64-bit tag can fit a lot). This is > currently being used by some platforms that run coreboot in place of > BL1/BL2, to pass information from coreboot (BL2) to BL31. > > > > I would echo Simon's sentiment of keeping this as simple as possible and > avoiding complicated and bloated data structures with UUIDs. You usually > want to parse something like this as early as possible in the passed-to > firmware stage, particularly if the structure encodes information about the > debug console (like it does for the platforms I mentioned above). For > example, in BL31 this basically means doing it right after moving from > assembly to C in bl31_early_platform_setup2() to get the console up before > running anything else. At that point in the BL31 initialization, the MMU > and caches are disabled, so data accesses are pretty expensive and you > don't want to spend a lot of parsing effort or calculate complicated > checksums or the like. You just want something extremely simple where you > ideally have to touch every data word only once. > > > > On Wed, Mar 24, 2021 at 5:06 PM Simon Glass via TF-A < > t...@lists.trustedfirmware.org> wrote: > > Hi Harb, > > > > On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS < > abdulha...@os.amperecomputing.com> wrote: > > Hello Folks, > > Appreciate the feedback and replies on this. Glad to see that there is > interest in this topic. 😊 > > > > I try to address the comments/feedback from Francois and Simon below…. > > > > @François Ozog <francois.o...@linaro.org> – happy to discuss this on a > zoom call. I will make that time slot work, and will be available to > attend April 8, 4pm CT. > > > > Note that I’m using the term “HOB” here more generically, as there are > typically vendor specific structures beyond the resource descriptor HOB, > which provides only a small subset of the information that needs to be > passed between the boot phases. > > > > The whole point here is to provide mechanism to develop firmware that we > can build ARM Server SoC’s that support **any** BL33 payload (e.g. EDK2, > AptioV, CoreBoot, and maybe even directly boot strapping LinuxBoot at some > point). In other-words, we are trying to come up with a TF-A that would > be completely agnostic to the implementation of BL33 (i.e. BL33 is built > completely independently by a separate entity – e.g. an ODM/OEM). > > > > Keep in mind, in the server/datacenter market segment we are not building > vertically integrated systems with a single entity compiling > firmware/software stacks like most folks in TF-A have become use to. There > are two categories of higher level firmware code blobs in the > server/datacenter model: > > 1. “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, > BL31, and **possibly** one or more BL32 instances > 2. “Platform” or “board” firmware – in TF-A this may map to BL33 and * > *possibly** one or more BL32 instances. > > > > Even the platform firmware stack could be further fragmented by having > multiple entities involved in delivering the entire firmware stack: IBVs, > ODMs, OEMs, CSPs, and possibly even device vendor code. > > > > To support a broad range of platform designs with a broad range of memory > devices, we need a crisp and clear contract between the SoC firmware that > initializes memory (e.g. BL2) and how that platform boot firmware (e.g. > BL33) gathers information about what memory that was initialized, at what > speeds, NUMA topology, and many other relevant information that needs to be > known and comprehended by the platform firmware and eventually by the > platform software. > > > > I understand the versatility of DT, but I see two major problems with DT: > > - DT requires more complicated parsing to get properties, and even > more complex to dynamically set properties – this HOB structures may need > to be generated in boot phases where DDR is not available, and therefore we > will be extremely memory constrained. > - DT is probably overkill for this purpose – We really just want a > list of pointers to simple C structures that code cast (e.g. JEDEC SPD data > blob) > > > > I think that we should not mix the efforts around DT/ACPI specs with what > we are doing here, because those specs and concepts were developed for a > completely different purpose (i.e. abstractions needed for OS / RTOS > software, and not necessarily suitable for firmware-to-firmware hand-offs). > > > > Frankly, I would personally push back pretty hard on defining SMC’s for > something that should be one way information passing. Every SMC we add is > another attack vector to the secure world and an increased burden on the > folks that have to do security auditing and threat analysis. I see no > benefit in exposing these boot/HOB/BOB structures at run-time via SMC > calls. > > > > Please do let me know if you disagree and why. Look forward to discussing > on this thread or on the call. > > > > @Simon Glass <s...@chromium.org> - Thanks for the pointer to bloblist. > I briefly reviewed and it seems like a good baseline for what we may be > looking for. > > > > That being said, I would say that there is some benefit in having some > kind of unique identifiers (e.g. UUID or some unique signature) so that we > can tie standardized data structures (based on some future TBD specs) to a > particular ID. For example, if the TPM driver in BL33 is looking for the > TPM structure in the HOB/BOB list, and may not care about the other data > blobs. The driver needs a way to identify and locate the blob it cares > about. > > > > The tag is intended to serve that purpose, although perhaps it should > switch from an auto-allocating enum to one with explicit values for each > entry and a range for 'local' use. > > > > I guess we can achieve this with the tag, but the problem with tag when > you have eco-system with a lot of parties doing parallel development, you > can end up with tag collisions and folks fighting about who has rights to > what tag values. We would need some official process for folks to register > tags for whatever new structures we define, or maybe some tag range for > vendor specific structures. This comes with a lot of pain and > bureaucracy. On the other hand, UUID has been a proven way to make it easy > to just define your own blobs with **either** standard or vendor specific > structures without worry of ID collisions between vendors. > > > > True. I think the pain is overstated, though. In this case I think we > actually want something that can be shared between projects and orgs, so > some amount of coordination could be considered a benefit. It could just be > a github pull request. I find the UUID unfriendly and not just to code size > and eyesight! Trying to discover what GUIDs mean or are valid is quite > tricky. E.g. see this code: > > > > #define FSP_HOB_RESOURCE_OWNER_TSEG_GUID \ > EFI_GUID(0xd038747c, 0xd00c, 0x4980, \ > 0xb3, 0x19, 0x49, 0x01, 0x99, 0xa4, 0x7d, 0x55) > > (etc.) > > > > static struct guid_name { > efi_guid_t guid; > const char *name; > } guid_name[] = { > { FSP_HOB_RESOURCE_OWNER_TSEG_GUID, "TSEG" }, > { FSP_HOB_RESOURCE_OWNER_FSP_GUID, "FSP" }, > { FSP_HOB_RESOURCE_OWNER_SMM_PEI_SMRAM_GUID, "SMM PEI SMRAM" }, > { FSP_NON_VOLATILE_STORAGE_HOB_GUID, "NVS" }, > { FSP_VARIABLE_NV_DATA_HOB_GUID, "Variable NVS" }, > { FSP_GRAPHICS_INFO_HOB_GUID, "Graphics info" }, > { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID1, "PCD database ea" }, > { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID2, "PCD database 9b" }, > > (never figured out what those two are) > > > { FSP_HOB_RESOURCE_OWNER_PEIM_DXE_GUID, "PEIM Init DXE" }, > { FSP_HOB_RESOURCE_OWNER_ALLOC_STACK_GUID, "Alloc stack" }, > { FSP_HOB_RESOURCE_OWNER_SMBIOS_MEMORY_GUID, "SMBIOS memory" }, > { {}, "zero-guid" }, > {} > }; > > static const char *guid_to_name(const efi_guid_t *guid) > { > struct guid_name *entry; > > for (entry = guid_name; entry->name; entry++) { > if (!guidcmp(guid, &entry->guid)) > return entry->name; > } > > return NULL; > } > > > > Believe it or not it took a fair bit of effort to find just that small > list, with nearly every one in a separate doc, from memory. > > > > > > We can probably debate whether there is any value in GUID/UUID or not > during the call… but again, boblist seems like a reasonable starting point > as an alternative to HOB. > > > > Indeed. There is certainly value in both approaches. > > > > Regards, > > Simon > > > > > > Thanks, > > --Harb > > > > *From:* François Ozog <francois.o...@linaro.org> > *Sent:* Tuesday, March 23, 2021 10:00 AM > *To:* François Ozog <francois.o...@linaro.org>; Ron Minnich < > rminn...@google.com>; Paul Isaac's <paul.isa...@linaro.org> > *Cc:* Simon Glass <s...@chromium.org>; Harb Abdulhamid OS < > abdulha...@os.amperecomputing.com>; Boot Architecture Mailman List < > boot-architect...@lists.linaro.org>; t...@lists.trustedfirmware.org > *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > +Ron Minnich <rminn...@google.com> +Paul Isaac's <paul.isa...@linaro.org> > > > > Adding Ron and Paul because I think this interface should be also > benefiting LinuxBoot efforts. > > > > On Tue, 23 Mar 2021 at 11:17, François Ozog via TF-A < > t...@lists.trustedfirmware.org> wrote: > > Hi, > > > > I propose we cover the topic at the next Trusted Substrate > <https://collaborate.linaro.org/display/TS/Trusted+Substrate+Home> zoom > call <https://linaro-org.zoom.us/j/94563644892> on April 8th 4pm CET. > > > > The agenda: > > ABI between non-secure firmware and the rest of firmware (EL3, S-EL1, > S-EL2, SCP) to adapt hardware description to some runtime conditions. > > runtime conditions here relates to DRAM size and topology detection, > secure DRAM memory carvings, PSCI and SCMI interface publishing. > > > > For additional background on existing metadata: UEFI Platform > Initialization Specification Version 1.7 > <https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf> > , 5.5 Resource Descriptor HOB > > Out of the ResourceType we care about is EFI_RESOURCE_SYSTEM_MEMORY. > > This HOB lacks memory NUMA attachment or something that could be related > to fill SRAT table for ACPI or relevant DT proximity domains. > > HOB is not consistent accros platforms: some platforms (Arm) lists memory > from the booting NUMA node, other platforms (x86) lists all memory from all > NUMA nodes. (At least this is the case on the two platforms I tested). > > > > There are two proposals to use memory structures from SPL/BLx up to the > handover function (as defined in the Device Tree technical report > <https://docs.google.com/document/d/1CLkhLRaz_zcCq44DLGmPZQFPbYHOC6nzPowaL0XmRk0/edit?usp=sharing>) > which can be U-boot (BL33 or just U-Boot in case of SPL/U-Boot scheme) or > EDK2. > > I would propose we also discuss possibility of FF-A interface to actually > query information or request actions to be done (this is a model actually > used in some SoCs with proprietary SMC calls). > > > > Requirements (to be validated): > > - ACPI and DT hardware descriptions. > > - agnostic to boot framework (SPL/U-Boot, TF-A/U-Boot, TF-A/EDK2) > > - agnostic to boot framework (SPL/U-Boot, TF-A/U-Boot, TF-A/EDK2, > TF-A/LinuxBoot) > > - at least allows complete DRAM description and "persistent" usage > (reserved areas for secure world or other usages) > > - support secure world device assignment > > > > Cheers > > > > FF > > > > > > On Mon, 22 Mar 2021 at 19:56, Simon Glass <s...@chromium.org> wrote: > > Hi, > > Can I suggest using bloblist for this instead? It is lightweight, > easier to parse, doesn't have GUIDs and is already used within U-Boot > for passing info between SPL/U-Boot, etc. > > Docs here: > https://github.com/u-boot/u-boot/blob/master/doc/README.bloblist > Header file describes the format: > https://github.com/u-boot/u-boot/blob/master/include/bloblist.h > > Full set of unit tests: > https://github.com/u-boot/u-boot/blob/master/test/bloblist.c > > Regards, > Simon > > On Mon, 22 Mar 2021 at 23:58, François Ozog <francois.o...@linaro.org> > wrote: > > > > +Boot Architecture Mailman List <boot-architect...@lists.linaro.org> > > > > standardization is very much welcomed here and need to accommodate a very > > diverse set of situations. > > For example, TEE OS may need to pass memory reservations to BL33 or > > "capture" a device for the secure world. > > > > I have observed a number of architectures: > > 1) pass information from BLx to BLy in the form of a specific object > > 2) BLx called by BLy by a platform specific SMC to get information > > 3) BLx called by BLy by a platform specific SMC to perform Device Tree > > fixups > > > > I also imagined a standardized "broadcast" FF-A call so that any firmware > > element can either provide information or "do something". > > > > My understanding of your proposal is about standardizing on architecture > 1) > > with the HOB format. > > > > The advantage of the HOB is simplicity but it may be difficult to > implement > > schemes such as pruning a DT because device assignment in the secure > world. > > > > In any case, it looks feasible to have TF-A and OP-TEE complement the > list > > of HOBs to pass information downstream (the bootflow). > > > > It would be good to start with building the comprehensive list of > > information that need to be conveyed between firmware elements: > > > > information. | authoritative entity | reporting entity | information > > exchanged: > > dram | TFA | TFA | > > <format to be detailed, NUMA topology to build the SRAT table or DT > > equivalent?> > > PSCI | SCP | TFA? | > > SCMI | SCP or TEE-OS | TFA? TEE-OS?| > > secure SRAM | TFA. | TFA. | > > secure DRAM | TFA? TEE-OS? | TFA? TEE-OS? | > > other? | | > > | > > > > Cheers > > > > FF > > > > > > On Mon, 22 Mar 2021 at 09:34, Harb Abdulhamid OS via TF-A < > > t...@lists.trustedfirmware.org> wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > > > TF-A mailing list > > > t...@lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > > > > -- > > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > > francois.o...@linaro.org | Skype: ffozog > > _______________________________________________ > > boot-architecture mailing list > > boot-architect...@lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/boot-architecture > > > > > -- > > *François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > -- > TF-A mailing list > t...@lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > -- > > *François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > -- > TF-A mailing list > t...@lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- > TF-A mailing list > t...@lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > -- > > *François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > >
