[TF-A] Re: [RFC] Proposed location to host the firmware handoff specification.

Stuart Yoder stuart.yoder at arm.com
Tue Dec 6 23:54:39 CET 2022



On 12/5/22 10:18 PM, Julius Werner via TF-A wrote:
> It seems like some of us still have very different opinions about how
> this handoff structure should and shouldn't be used, which I really
> think need to be worked out and then codified in the spec before we
> can call the document final, because otherwise no firmware project can
> trust that it is safe to adopt this. My understanding was that this is
> supposed to be a universal handoff structure that's free to be used by
> any open source firmware project for any of its internal purposes at
> any stage of the boot flow as a standalone solution that doesn't force
> them to pull in dependencies to any other format. If that is the case
> then I think the spec should reflect this very clearly and should
> particularly not contain any language about deferring certain types of
> data to other handoff structures wrapped in the TL. It needs to be
> clear that projects will be allowed to freely register tags for their
> needs without the risk of suddenly getting told by the maintainers
> that they need to use an FDT for this or that instead.

I can see 3 types of use cases:

1.  A tag that is intended to be used for information passed between
     different firmware projects.  Such as from TF-A to EDK2 and u-boot.

2.  A tag for _internal_ use within a firmware project.  Here a
     firmware project should be free to do whatever they want, but they
     still will likely want to use tag IDs that will not conflict with
     other uses.  I don't see the value of cluttering the firmware
     handoff spec with layouts internal to specific firmware projects.

3.  A tag for experimental or other uses where standardization is
     not wanted.

We have plenty of bits, so why not define 3 ranges:

0x0 -- 0xf_ffff	  Standard tag id range. Any tag id in this range must 
first be allocated in this specification before being used. The 
allocation of the tag id requires the entry layout to be defined as well.

0x10_0000 -- 0x10_ffff	Vendor tag id range. Any tag id in this range 
must first be allocated in this specification before being used.  A 
vendor or project requests a range of tag IDs. The layout of entries in 
this range is not standardized.

0x11_0000 -- 0x11_ffff	Non-standard range. A platform firmware 
integrator can create entries in this range without coordination with 
the firmware handoff specification. Different platforms are allowed to 
have tag ids in this range with distinct data formats. Entries in this 
range are not standardized.

0x12_0000 -- 0xffff_ffff	Reserved


Thanks,
Stuart


More information about the U-Boot mailing list