Hi, Do we have slides and video from last week's discussion?
Thanks, Okash On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A <t...@lists.trustedfirmware.org> wrote: > > 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 » >> >> >> >> 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/ >> >> >> >> Trusted Firmware is inviting you to a scheduled Zoom meeting. >> >> >> >> Join Zoom Meeting >> >> https://zoom.us/j/9159704974 >> >> >> >> Meeting ID: 915 970 4974 >> >> >> >> One tap mobile >> >> +16465588656,,9159704974# US (New York) >> >> +16699009128,,9159704974# US (San Jose) >> >> >> >> Dial by your location >> >> +1 646 558 8656 US (New York) >> >> +1 669 900 9128 US (San Jose) >> >> 877 853 5247 US Toll-free >> >> 888 788 0099 US Toll-free >> >> Meeting ID: 915 970 4974 >> >> Find your local number: https://zoom.us/u/ad27hc6t7h >> >> >> >> ________________________________ >> >> 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 – 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: >> >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and >> *possibly* one or more BL32 instances >> “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 - 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 +Paul Isaac's >> >> >> >> 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 zoom call 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, 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) 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 >> >> > > -- > TF-A mailing list > t...@lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a
