Le ven. 9 juil. 2021 à 03:09, Julius Werner jwerner@chromium.org a écrit :

...

Of course every project would like not to change...

For TF-A I wonder whether it will/should in fact use devicetree if there

is a lot of complex data? TBD, I suppose.

Okay, sorry, now I'm a bit confused -- I thought the discussion in this thread was about which parameter hand-off mechanism to use *for TF-A*? Or did it shift to discuss other projects in the meantime (I didn't always follow it closely)? I think it started with the UEFI guys wanting to implement a HOB format to interface with TF-A, and I think we now concluded that they're okay with using a simple parameter list instead (and wrapping their custom HOBs into a parameter blob that contains their UUID and everything else in the data part).

So for TF-A, if the decision is that we want a parameter list, I think it makes sense to keep using the format that has already been there and in use for several years, and define new tags for the UEFI HOB use case in that. I don't really see a reason to switch TF-A and all other projects currently interfacing with it that way (e.g. coreboot) to something only used by U-Boot right now, if they're practically identical in concept.

Looking at bl_au_params: used by 3 SoCs to deal with gpio and serial. Migration may not be that a big effort (handful lines of code?). The key thing is that the biggest consumer of them are BL33 and a little bit by some OS drivers (OS itself shall not be a consumer). U-Boot has an established mechanism which is used in particular on all chrome books in both x86 and Arm environments. I have the impression that U-Boot is the typical BL33 so I would import the mechanism into TFA, not the other way round. EDK2 has typically its own code for TFA matters and may just import BL31, so it does not appear a priority in that decision. But I may be wrong…

--

François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

Please find my replies

To Julius's question: Just to clarify: are you using "bloblist" as a general term for the concept of a simple linked list of tagged data blobs, or to refer specifically to the U-Boot implementation with that name? The existing TF-A implementation (bl_aux_params) is basically identical in concept to the U-Boot bloblist, but not binary compatible. Are we talking about just keeping that, or throwing it away in order to reimplement the exact structure U-Boot is using? (I would prefer to keep the bl_aux_params as they are to avoid disrupting existing uses, of course. Making backwards-incompatible changes to an interface that passes across multiple repos and firmware components is always a big pain.) - "bloblist" is a general term for concept of linked list and it's not exactly U-boot implementation. The proposed solution will cause some degree of changes in all the participating projects. For backward compatibility issue, we have already though about it and proposed to have build configs which will be enabled by platform integrators.

To Daniel's question: In short are you confident adopting a mantra of "it doesn't exist unless it's upstreamed" is sufficient? - "If it is not upstreamed we don't know if it exists or not?", Since we can't know/control what all are hidden in closed sources, so we are only concentrating on open sources.

Finally, We are trying to solve a problem(in a standard way) which is already solved in different projects differently. To have a common solution acceptable to all, changes in participating projects are inevitable. Once we get agreement in principle, we should be ready to have some changes in the codebase. The TF-A project is willing to put effort to put something out there that will enable other projects, but we need some degree of assurances that proposed changes will be accepted in other projects also.

Thanks Manish ________________________________ From: Daniel Thompson daniel.thompson@linaro.org Sent: 09 July 2021 11:07 To: François Ozog francois.ozog@linaro.org Cc: Julius Werner jwerner@chromium.org; Ed Stuber edstuber@amperecomputing.com; Boot Architecture Mailman List boot-architecture@lists.linaro.org; undefined loic.pallardy@st.com; Harb Abdulhamid OS abdulhamid@os.amperecomputing.com; Simon Glass sjg@chromium.org; Arjun Khare akhare@amperecomputing.com; U-Boot Mailing List u-boot@lists.denx.de; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org; Paul Isaac's paul.isaacs@linaro.org; Ron Minnich rminnich@google.com; Moe Ammar moe@amperecomputing.com; Manish Pandey2 Manish.Pandey2@arm.com Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

On Fri, Jul 09, 2021 at 09:05:09AM +0200, François Ozog wrote:

Le ven. 9 juil. 2021 à 03:09, Julius Werner jwerner@chromium.org a écrit :

...

...

Of course every project would like not to change...

For TF-A I wonder whether it will/should in fact use devicetree if there

is a lot of complex data? TBD, I suppose.

Okay, sorry, now I'm a bit confused -- I thought the discussion in this thread was about which parameter hand-off mechanism to use *for TF-A*? Or did it shift to discuss other projects in the meantime (I didn't always follow it closely)? I think it started with the UEFI guys wanting to implement a HOB format to interface with TF-A, and I think we now concluded that they're okay with using a simple parameter list instead (and wrapping their custom HOBs into a parameter blob that contains their UUID and everything else in the data part).

So for TF-A, if the decision is that we want a parameter list, I think it makes sense to keep using the format that has already been there and in use for several years, and define new tags for the UEFI HOB use case in that. I don't really see a reason to switch TF-A and all other projects currently interfacing with it that way (e.g. coreboot) to something only used by U-Boot right now, if they're practically identical in concept.

Looking at bl_au_params: used by 3 SoCs to deal with gpio and serial.

I presume this analysis only covers those SoCs where someone (vendor, customer, community) has upstreamed their TF-A implementation?

It is only relatively recently[1] that the TF-A CLA requirements that inhibited upstreaming were relaxed. Additionally the current silicon supply crunch is forcing board designers to second (third and forth) source critical components which can drive usage of firmware parameter passing.

In short are you confident adopting a mantra of "it doesn't exist unless it's upstreamed" is sufficient?

Daniel.

[1] Perhaps not that recent if measured in years... but certainly recent relative to firmware life cycles!

Migration may not be that a big effort (handful lines of code?). The key thing is that the biggest consumer of them are BL33 and a little bit by some OS drivers (OS itself shall not be a consumer). U-Boot has an established mechanism which is used in particular on all chrome books in both x86 and Arm environments. I have the impression that U-Boot is the typical BL33 so I would import the mechanism into TFA, not the other way round. EDK2 has typically its own code for TFA matters and may just import BL31, so it does not appear a priority in that decision. But I may be wrong…

...

--

François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture

On Sat, 10 Jul 2021 at 01:07, Julius Werner jwerner@chromium.org wrote:

...

• "bloblist" is a general term for concept of linked list and it's not

exactly U-boot implementation. The proposed solution will cause some degree of changes in all the participating projects. For backward compatibility issue, we have already though about it and proposed to have build configs which will be enabled by platform integrators.

Okay, let's gather the requirements and then decide how the existing system needs to be expanded to meet them. Please keep me in the loop on those discussions.

...

...

U-Boot has an established mechanism which is used in particular on all

chrome

...

...

books in both x86 and Arm environments. I have the impression that U-Boot is the typical BL33 so I would import the mechanism into TFA, not the other way round.

There has been no Chromebook (x86 or Arm) shipping with U-Boot since 2013 (before TF-A existed). In fact, Chromebooks are all running coreboot today and using the bl_aux_params mechanism (it's 3 SoC vendors, more than 3 SoCs, but the parameter code is shared at the vendor level), and one of my concerns here is trying to limit disruption to those existing setups. I don't have enough data to say what the "typical" boot flow among all TF-A devices in existence is, but at least for the millions of Chromebooks out there it is coreboot

• TF-A, not U-Boot.

My bad! I candidly inferred from Chromebook reference in U-Boot and Simon's VBE proposal that U-Boot was used.

• fuller implementation with more features

Is that a good thing? Didn't we just have a long discussion eschewing a heavy-handed, bulky hand-off block design in favor of more simple and flexible structures? I think simplicity is key for this and the bl_aux_params are trying to be about as simple as they can possibly get. Particularly in a situation like this where many different projects will need to implement this independently, any extra clutter (like versioning, an apparently unused(?) flags field, checksumming) adds unnecessary extra friction that's best to avoid. (You can *do* all these things like adding an extra checksum over the whole thing with bl_aux_params by just defining an extra tag for it, of course, but none of them are required for platforms for which they don't make sense.)

• has comments / more documentation

Is there anything in particular you feel is missing from the bl_aux_params comments?

• easily supports everything in one block instead of a linked list (easier to allocate)

I don't understand how this is easier, in fact I see it as a big drawback. The bl_aux_params design allows structures to be allocated wherever -- in the easiest case you can just define them as global variables in the earlier stage (in the respective files that deal with each tag) and then chain those together. You *can* of course also allocate them in a contiguous block from a special memory area, and if you're planning to pass this across more than one stage boundary that's probably the better choice. But not all platforms have that requirement, and this design allows them the flexibility to choose. The coreboot platforms only care about the BL2->BL31 transition, so why should they switch to a design that forces us to set up an extra contiguous-block allocator for no good reason?

• avoids 64-bit tags/size which seem quite unnecessary

Well, earlier there were some concerns about possible tag collisions, so I think the extra space doesn't hurt to alleviate those fears. Having 64 bits allows us to split the tag space into many separate ranges that can then be allocated from independently -- for example, we could just say that the top 2^63 tags are available for private vendor tags generated as random numbers (like a GUID). (Your bloblist seems to waste space on things like a "spare" field instead, so in the end both implementations still come out to the same overhead per tag, and bloblist has additional overhead for the header at the front.)

• ability to link to another bloblist (do we really need this?)

FWIW you can do this by default with bl_aux_params because they're not required to be contiguous.