On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 <manish.pand...@arm.com> wrote:
> Hi Everyone, > > I have tried to conclude the discussions we had in two of the TF-A tech > forum sessions and on mailing list. > > The problem we are trying to solve is already solved in different projects > in different ways, the purpose of these discussions was to come up with a > standard way which can be adopted widely. > Considering that many Firmware projects are not DT aware its better to > avoid its usage and use simple C structures for wider acceptance. Based on > the discussions following design came up as most acceptable solution > > - Use list of pre-defined C data structures(blobs) to pass > information, let's call it bloblist > - Only bootloaders stages will participate > - Blobs will be identified by either tags or UUIDs > - Pass pointer to the bloblist head through x0 > - Existing usage of x0 will be translated into a blob > > After all discussions, I now support Simon proposal to use existing bloblist: it does the job, is already upstream in key projects (core boot, U-Boot), is supported on x86 and Arm. I would think of a few additions on the bloblist_rec: struct bloblist_rec <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/bloblist_rec> { u32 <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/u32> tag <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/tag>; u32 <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/u32> hdr_size <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/hdr_size>; u32 <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/u32> size; u32 <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/u32> spare <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/spare>;}; enum bloblist_tag_t <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/bloblist_tag_t> { BLOBLISTT_NONE <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_NONE> = 0, /* Vendor-specific tags are permitted here */ BLOBLISTT_EC_HOSTEVENT <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_EC_HOSTEVENT>, /* Chromium OS EC host-event mask */ BLOBLISTT_SPL_HANDOFF <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_SPL_HANDOFF>, /* Hand-off info from SPL */ BLOBLISTT_VBOOT_CTX <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_VBOOT_CTX>, /* Chromium OS verified boot context */ BLOBLISTT_VBOOT_HANDOFF <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_VBOOT_HANDOFF>, /* Chromium OS internal handoff info */ /* * Advanced Configuration and Power Interface Global Non-Volatile * Sleeping table. This forms part of the ACPI tables passed to Linux. */ BLOBLISTT_ACPI_GNVS <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_ACPI_GNVS>, BLOBLISTT_INTEL_VBT <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_INTEL_VBT>, /* Intel Video-BIOS table */ BLOBLISTT_TPM2_TCG_LOG <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_TPM2_TCG_LOG>, /* TPM v2 log space */ BLOBLISTT_TCPA_LOG <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_TCPA_LOG>, /* TPM log space */ BLOBLISTT_ACPI_TABLES <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_ACPI_TABLES>, /* ACPI tables for x86 */ BLOBLISTT_SMBIOS_TABLES <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_SMBIOS_TABLES>, /* SMBIOS tables for x86 */ BLOBLISTT_COUNT <https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_COUNT>}; I would add a BLOBLISTT_UUID for all proprietary things that people want to add. Using private space in a 64 bit field does not make the thing open. So by using this tag, we know exactly the nature of the blob. Negotiating for adding a new tag is a good open governance process. We may have to deal with super small SRAM (256KB) and thus we can assume the bloblist will be a single region of blobs. So I would add a BLOBLISTT_CONTINUATION which would be a pointer from the SRAM bloblist to a DRAM backed bloblist. Other tags to consider: PSCI interface details, DRAM information, SCMI stuff, Secure SRAM and DRAM information... > - Going forward we would provide core changes to demonstrate this > design on various TF-A boundries, BL1<->BL2, BL2<->BL31 and > BL31<->BL33(only BL31 part) > > > Please share your thoughts if you disagree to the proposed solution. > > Also, refer to attached slide deck which was presented during last tech > forum session on 3rd june, it also captures the points discussed during > meeting and next steps for implementing it in TF-A. > > Thanks > Manish Pandey > ------------------------------ > *From:* Joanna Farley <joanna.far...@arm.com> > *Sent:* 02 June 2021 16:26 > *To:* Madhukar Pappireddy <madhukar.pappire...@arm.com>; Okash Khawaja < > okash.khaw...@gmail.com>; Simon Glass <s...@chromium.org> > *Cc:* Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot > Architecture Mailman List <boot-architect...@lists.linaro.org>; Ed Stuber > <edstu...@amperecomputing.com>; Arjun Khare <akh...@amperecomputing.com>; > U-Boot Mailing List <u-boot@lists.denx.de>; Paul Isaac's < > paul.isa...@linaro.org>; Ron Minnich <rminn...@google.com>; Moe Ammar < > m...@amperecomputing.com>; t...@lists.trustedfirmware.org < > t...@lists.trustedfirmware.org>; Manish Pandey2 <manish.pand...@arm.com> > *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > + TF-A list that got dropped (again)! > > > > Joanna > > > > *From: *Joanna Farley <joanna.far...@arm.com> > *Date: *Wednesday, 2 June 2021 at 15:29 > *To: *Madhukar Pappireddy <madhukar.pappire...@arm.com>, Okash Khawaja < > okash.khaw...@gmail.com>, Simon Glass <s...@chromium.org> > *Cc: *Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>, Boot > Architecture Mailman List <boot-architect...@lists.linaro.org>, Ed Stuber > <edstu...@amperecomputing.com>, Arjun Khare <akh...@amperecomputing.com>, > U-Boot Mailing List <u-boot@lists.denx.de>, Paul Isaac's < > paul.isa...@linaro.org>, Ron Minnich <rminn...@google.com>, Moe Ammar < > m...@amperecomputing.com> > *Subject: *Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > Hi Everyone, > > > > The Manish Pandy and Madhukar Pappireddy of the TF-A team are planning to > host another TF-A Tech Forum this Thursday to continue the live discussion. > > > > Here is their agenda: > > On tech forum this week, we would like to continue discussions on HOB list > design. > > The topics which we would like to cover is > > 1. Evaluate different proposals of passing information through boot phases. > > 2. If we don't get an agreement on one solution fit for all then we would > try to get consensus for Infra segment platform(to solve original problem > mentioned by Harb) > > 3. Try to get an agreement on size of tags and how "hybrid and tag only" > HOB list can co-exist together? > > > > Details of the call are: > > > > ====================== > > > > 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 > > > > 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 > > > > > > ================ > > > > Joanna > > > > > > > > > > > > > > > > On 19/05/2021, 03:50, "Madhukar Pappireddy" <madhukar.pappire...@arm.com> > wrote: > > > > Attached slides presented by Manish in the TF-A tech forum. > > > > > > -----Original Message----- > > From: TF-A <tf-a-boun...@lists.trustedfirmware.org> On Behalf Of > Madhukar Pappireddy via TF-A > > Sent: Tuesday, May 18, 2021 8:59 PM > > To: Joanna Farley <joanna.far...@arm.com>; Okash Khawaja < > okash.khaw...@gmail.com>; Simon Glass <s...@chromium.org> > > Cc: Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot > Architecture Mailman List <boot-architect...@lists.linaro.org>; Ed Stuber > <edstu...@amperecomputing.com>; Arjun Khare <akh...@amperecomputing.com>; > U-Boot Mailing List <u-boot@lists.denx.de>; t...@lists.trustedfirmware.org; > Paul Isaac's <paul.isa...@linaro.org>; Ron Minnich <rminn...@google.com>; > Moe Ammar <m...@amperecomputing.com> > > Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > Hi, > > > > I tried to summarize the discussions in the previous TF-A tech forum > regarding the proposal to adopt Hand-off Blocks (HOBs) for passing > information along the boot chain. I am certain I could not capture all > suggestions/concerns brought up during the call. I apologize if I missed > and/or misinterpreted any comments and would appreciate it if everyone > could share their thoughts in response to this email thread. > > > > The idea is to share information to other boot phases: > > > Dynamic information: Created during runtime. Shared in the form of a > chain of blobs(built as a linked list of C structure objects i.e., HOB > list). > > > Static information: Known at compile time. Historically, shared > through the use of Device Tree/ACPI tables > > > > Both the above requirements are common in many ecosystems and need to > co-exist. > > > > There are broadly 3 problems to solve: > > 1. Format of HOB structures: It looks like the consensus is that we > could use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist in > u-boot). > > 2. Identification of HOB list entries: There is a debate about whether > tags would suffice or if the HOB list producer and consumer would depend on > UUID/GUIDs for identifying a specific HOB structure. Another suggestion was > to use a hybrid approach. Reserve a single tag ID for > identifying/constructing a HOB structure that further leverages UUID based > identifier. This way, the generic HOB list doesn't need to support UUIDs > and can work with tags. > > 3. The design contract for the static interface between two boot > phases: The problem at hand is whether to pass a pointer to a HOB list or a > device tree blob through the general-purpose registers for configuration > hand-off between two boot phases. Some proposals that came up: > > > Proposal 1: Always pass a pointer to the device tree blob > through the GP register and capture the pointer to the HOB list as a > property of a node that is uniquely identifiable by the downstream boot > phase. This needs to define a device tree binding such that producer and > consumer agree on the information passed. > > > Proposal 2: Pass a pointer to a generic container through > the GP register that can be interpreted appropriately by both boot > loaders(i.e., producer and consumer of the boot info). This container can > either be a dtb or a HOB list which can be simply inferred by checking for > a magic header that indicates if the buffer appears to be a flattened > device tree. > > > One another concern that was brought up offline is to make > sure we don't break current design contracts between various boot loader > phases in TF-A. Many of the general-purpose registers have a designated > purpose such as to share configurations between BL images( such as firmware > config dtb, SoC config dtb, Non trusted firmware config dtb, memory layout, > entry point info, etc.). > > > > If I am not mistaken, a single design may not fit the needs of every > segment(client, Infra, embedded) and the forum is open to solutions > tailored for individual segments. Joanna will be sending a follow up email > with more information about future TF-A tech forums that serves as a > platform for further discussions. > > > > Thanks, > > Madhukar > > > > -----Original Message----- > > From: TF-A <tf-a-boun...@lists.trustedfirmware.org> On Behalf Of > Joanna Farley via TF-A > > Sent: Sunday, May 16, 2021 5:19 AM > > To: Okash Khawaja <okash.khaw...@gmail.com>; 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; Ed Stuber <edstu...@amperecomputing.com>; > Arjun Khare <akh...@amperecomputing.com>; U-Boot Mailing List < > u-boot@lists.denx.de>; Paul Isaac's <paul.isa...@linaro.org>; Ron Minnich > <rminn...@google.com>; Moe Ammar <m...@amperecomputing.com> > > Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > Apologies I failed with the recording. Manish/Madhu will reply early > next week with the slides and some notes to help with a follow up session > which we hope to hold this Thursday. Invite and agenda will also be sent > out early next week. > > > > Thanks > > > > Joanna > > > > On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" < > tf-a-boun...@lists.trustedfirmware.org on behalf of > t...@lists.trustedfirmware.org> wrote: > > > > 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 > > -- > > 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 > > -- > > 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
