Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Ron Minnich]

let's make these values rich in bits, in particular, starting off with
abcd_NONE  = 0 means you can't tell zero'd memory from a tag.

This pattern repeats with every new such project I see. Use those bits, and
set them with values unlikely to occur in practice.

Use them all, they are there anyway. And it's best if they're not
sequential values.

On Thu, Jun 17, 2021 at 4:45 PM  wrote:

> My take: Don’t force device tree on platforms. Lets not make decisions
> about whether SDRAM is sufficient to expose device tree, that is assuming
> size may be the only problem with device tree. Some platforms don’t want to
> use device tree just like some platforms don’t want to use UUID’s(which
> b.t.w does not necessarily mean private use as was explained during the
> TF-A forums).
>
> I support ARM’s proposal that partitions the problem based on market
> segments and allows different platforms to choose what is right for them,
> that includes the ability to use UUID if a platform so chooses AND across
> boundaries. I wouldn’t vote for the proposal below about using bloblist for
> simple things and device tree for other complex things based on SRAM/SDRAM
> etc. that complicates things further. What if you need to pass information
> from the bloblist to later boot stages? Do we take data from bloblist and
> patch it into a device tree?
>
>
>
> I also think it is incorrect to partition platforms into what u-boot/linux
> boot/embdedded systems do and what “UEFI/private code” does. UEFI is a huge
> part of the ARM eco-system and is being used fairly extensively and
> supported across different markets and is not private code.
>
>
>
> Thanks
>
> -Raghu
>
>
>
> *From:* TF-A  *On Behalf Of *François
> Ozog via TF-A
> *Sent:* Thursday, June 17, 2021 12:57 PM
> *To:* Simon Glass 
> *Cc:* Ed Stuber ; Boot Architecture Mailman
> List ; Harb Abdulhamid OS <
> abdulha...@os.amperecomputing.com>; U-Boot Mailing List <
> u-b...@lists.denx.de>; Arjun Khare ;
> t...@lists.trustedfirmware.org; Paul Isaac's ;
> Ron Minnich ; Moe Ammar 
> *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for
> information passing between boot stages
>
>
>
>
>
>
>
> Le jeu. 17 juin 2021 à 21:38, Simon Glass  a écrit :
>
> Hi,
>
>
>
> On Fri, 11 Jun 2021 at 05:52, François Ozog 
> wrote:
>
>
>
>
>
> On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 
> 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
>
> They always have a tag, but one of the tags can be BLOBLISTT_UUID
> indicating it is for private use. But we should not allow this for passing
> across a boundary, so that no software needs to deal with UUID unless it is
> UEFI / private code. So, basically what Francios says below.
>
>
>-
>- 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* 
> 
>  {
>
>   *u32* 
>  
> *tag* 
> ;
>
>   *u32* 
>  
> *hdr_size* 
> ;
>
>   *u32* 
>  
> size;
>
>   *u32* 
>  
> *spare* 
> ;
>
> };
>
> enum *bloblist_tag_t* 
> 
>  {
>
>*BLOBLISTT_NONE* 
> 
>  = 0,
>
>
>
>*/* Vendor-specific tags are permitted here */*
>
>*BLOBLISTT_EC_HOSTEVENT* 
> 

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Simon Glass]

Hi Raghu,

The thing is, devicetree is already used widely on ARM and it is hard to
see a good alternative. Using a C struct to describe something complicated
is a pain. Take a look at the x86 setup.bin stuff, or the binary block that
PowerPC used to pass to linux. Even the 'atag' tagged structure that ARM
used before devicetree provides an example of the limitations of this
approach. Look also at the huge tables of data passed to Intel's binary
blobs (which are just chunks of UEFI, by the way) and passed back to the
firmware framework, sometimes hundreds of fields across a dozen or more
HOBs. C structs are good for simple things, particularly if they are not
going to need to expand a lot, but devicetree provides more flexible data
types and sizes, schema, human readability, expansion, tooling,
future-proofing, etc. I really feel that this is self-evident, but I'm
happy to go into more detail about why.

If some projects don't want to use devicetree for complex structures,
that's OK. They can do their own thing and avoid talking across boundaries
to other projects. When they have a need to pass complex info in a standard
way to other projects once SDRAM is up, they can see whether adopting
devicetree is worth it.

As I mentioned, "Blobs that were created pre-SDRAM can continue to be
passed on". The proposal is just that we should not *create* new data in a
blob once SDRAM is running. So we don't need to "take data from a bloblist
and patch it in a devicetree".

There seems to be no benefit or need for a UUID where open collaboration is
desired; in fact it appears to be designed for the opposite. The 'killer'
argument provided for UUID is it allows people to allocate them in
isolation without any reference to another project, which is exactly the
opposite of open collaboration... So long as UUID is not *required* in any
of the structures passed through the open firmware components, it seems OK
to have it as an option. But it should not be *required* by ATF, etc.
Specifically, U-Boot should be able to parse and generate bloblists without
any UUID code. Further to that, it wouldn't
make sense to use UUID to pass info from ATF to UEFI just because it is
UEFI. Why not just use a tag? We have to allocate it anyway...

As to market segments, again, why? If we have a simple but sufficient
solution, why not use that everywhere?

I am not sure how to respond to the part about UEFI not being private code;
perhaps we just have different meanings of the word. Where is the project
with all the boards supported by UEFI? U-Boot supports about 1300 with all
sorts of vendors collaborating on advancing open firmware, over two
decades. In any case that seems like a different topic. We don't need to
discuss the merits of the different development models to come to an
agreement on how to pass info between components, open or not.

Regards,
SImon

On Thu, 17 Jun 2021 at 17:45,  wrote:

> My take: Don’t force device tree on platforms. Lets not make decisions
> about whether SDRAM is sufficient to expose device tree, that is assuming
> size may be the only problem with device tree. Some platforms don’t want to
> use device tree just like some platforms don’t want to use UUID’s(which
> b.t.w does not necessarily mean private use as was explained during the
> TF-A forums).
>
> I support ARM’s proposal that partitions the problem based on market
> segments and allows different platforms to choose what is right for them,
> that includes the ability to use UUID if a platform so chooses AND across
> boundaries. I wouldn’t vote for the proposal below about using bloblist for
> simple things and device tree for other complex things based on SRAM/SDRAM
> etc. that complicates things further. What if you need to pass information
> from the bloblist to later boot stages? Do we take data from bloblist and
> patch it into a device tree?
>
>
>
> I also think it is incorrect to partition platforms into what u-boot/linux
> boot/embdedded systems do and what “UEFI/private code” does. UEFI is a huge
> part of the ARM eco-system and is being used fairly extensively and
> supported across different markets and is not private code.
>
>
>
> Thanks
>
> -Raghu
>
>
>
> *From:* TF-A  *On Behalf Of *François
> Ozog via TF-A
> *Sent:* Thursday, June 17, 2021 12:57 PM
> *To:* Simon Glass 
> *Cc:* Ed Stuber ; Boot Architecture Mailman
> List ; Harb Abdulhamid OS <
> abdulha...@os.amperecomputing.com>; U-Boot Mailing List <
> u-b...@lists.denx.de>; Arjun Khare ;
> t...@lists.trustedfirmware.org; Paul Isaac's ;
> Ron Minnich ; Moe Ammar 
> *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for
> information passing between boot stages
>
>
>
>
>
>
>
> Le jeu. 17 juin 2021 à 21:38, Simon Glass  a écrit :
>
> Hi,
>
>
>
> On Fri, 11 Jun 2021 at 05:52, François Ozog 
> wrote:
>
>
>
>
>
> On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 
> wrote:
>
> Hi Everyone,
>
>
>
> I have tried to conclude the discussions we had in two of the TF-A tech
> forum 

RE: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[raghu.ncstate]

My take: Don’t force device tree on platforms. Lets not make decisions about 
whether SDRAM is sufficient to expose device tree, that is assuming size may be 
the only problem with device tree. Some platforms don’t want to use device tree 
just like some platforms don’t want to use UUID’s(which b.t.w does not 
necessarily mean private use as was explained during the TF-A forums).

I support ARM’s proposal that partitions the problem based on market segments 
and allows different platforms to choose what is right for them, that includes 
the ability to use UUID if a platform so chooses AND across boundaries. I 
wouldn’t vote for the proposal below about using bloblist for simple things and 
device tree for other complex things based on SRAM/SDRAM etc. that complicates 
things further. What if you need to pass information from the bloblist to later 
boot stages? Do we take data from bloblist and patch it into a device tree?

 

I also think it is incorrect to partition platforms into what u-boot/linux 
boot/embdedded systems do and what “UEFI/private code” does. UEFI is a huge 
part of the ARM eco-system and is being used fairly extensively and supported 
across different markets and is not private code.

 

Thanks

-Raghu

 

From: TF-A  On Behalf Of François Ozog 
via TF-A
Sent: Thursday, June 17, 2021 12:57 PM
To: Simon Glass 
Cc: Ed Stuber ; Boot Architecture Mailman List 
; Harb Abdulhamid OS 
; U-Boot Mailing List 
; Arjun Khare ; 
t...@lists.trustedfirmware.org; Paul Isaac's ; Ron 
Minnich ; Moe Ammar 
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for 
information passing between boot stages

 

 

 

Le jeu. 17 juin 2021 à 21:38, Simon Glass mailto:s...@chromium.org> > a écrit :

Hi,

 

On Fri, 11 Jun 2021 at 05:52, François Ozog mailto:francois.o...@linaro.org> > wrote:

 

 

On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 mailto: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

They always have a tag, but one of the tags can be BLOBLISTT_UUID indicating it 
is for private use. But we should not allow this for passing across a boundary, 
so that no software needs to deal with UUID unless it is UEFI / private code. 
So, basically what Francios says below.

*
*   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 {
   
 
u32  
 
tag;
   
 
u32  

 hdr_size;
   
 
u32 size;
   
 
u32  
 
spare;
};
enum  

 bloblist_tag_t {


 BLOBLISTT_NONE = 0,
 
   /* Vendor-specific tags are permitted here */


 BLOBLISTT_EC_HOSTEVENT,   /* Chromium OS EC host-event mask */

 

We can give these each a value (=1, =2) so it is clear. 



 BLOBLISTT_SPL_HANDOFF,/* Hand-off info from SPL */


 BLOBLISTT_VBOOT_CTX,  /* Chromium OS verified boot context */

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[François Ozog]

Le jeu. 17 juin 2021 à 21:38, Simon Glass  a écrit :

> Hi,
>
> On Fri, 11 Jun 2021 at 05:52, François Ozog 
> wrote:
>
>>
>>
>> On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 
>> 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
>>>
>>> They always have a tag, but one of the tags can be BLOBLISTT_UUID
> indicating it is for private use. But we should not allow this for passing
> across a boundary, so that no software needs to deal with UUID unless it is
> UEFI / private code. So, basically what Francios says below.
>
>>
>>>-
>>>- 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 
>> 
>>  {
>>  u32 
>>  
>> tag 
>> ;
>>  u32 
>>  
>> hdr_size 
>> ;
>>  u32 
>>  
>> size;
>>  u32 
>>  
>> spare 
>> ;};
>>
>> enum bloblist_tag_t 
>> 
>>  {
>>  BLOBLISTT_NONE 
>> 
>>  = 0,
>>
>>  /* Vendor-specific tags are permitted here */
>>  BLOBLISTT_EC_HOSTEVENT 
>> ,
>>  /* Chromium OS EC host-event mask */
>>
>>
> We can give these each a value (=1, =2) so it is clear.
>
>>  BLOBLISTT_SPL_HANDOFF 
>> ,
>>/* Hand-off info from SPL */
>>  BLOBLISTT_VBOOT_CTX 
>> ,
>>/* Chromium OS verified boot context */
>>  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 
>> ,
>>  BLOBLISTT_INTEL_VBT 
>> ,
>>/* Intel Video-BIOS table */
>>  BLOBLISTT_TPM2_TCG_LOG 
>> ,
>>  /* TPM v2 log space */
>>  BLOBLISTT_TCPA_LOG 
>> ,
>>  /* TPM log space */
>>  BLOBLISTT_ACPI_TABLES 
>> ,
>>/* ACPI tables for x86 */
>>  BLOBLISTT_SMBIOS_TABLES 
>> ,
>>/* SMBIOS tables for x86 */
>>
>> How about:
>
> BLOBLISTT_LOCAL = 0xf000u   /* values in this space are for local use
> during development */
>
>>  BLOBLISTT_COUNT 
>> };
>>
>> I would add a BLOBLISTT_UUID for all proprietary things that people want
>> 

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Simon Glass]

Hi,

On Fri, 11 Jun 2021 at 05:52, François Ozog 
wrote:

>
>
> On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 
> 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
>>
>> They always have a tag, but one of the tags can be BLOBLISTT_UUID
indicating it is for private use. But we should not allow this for passing
across a boundary, so that no software needs to deal with UUID unless it is
UEFI / private code. So, basically what Francios says below.

>
>>-
>>- 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 
> 
>  {
>   u32 
>  
> tag 
> ;
>   u32 
>  
> hdr_size 
> ;
>   u32 
>  
> size;
>   u32 
>  
> spare 
> ;};
>
> enum bloblist_tag_t 
> 
>  {
>   BLOBLISTT_NONE 
> 
>  = 0,
>
>   /* Vendor-specific tags are permitted here */
>   BLOBLISTT_EC_HOSTEVENT 
> ,
>  /* Chromium OS EC host-event mask */
>
>
We can give these each a value (=1, =2) so it is clear.

>   BLOBLISTT_SPL_HANDOFF 
> ,
>/* Hand-off info from SPL */
>   BLOBLISTT_VBOOT_CTX 
> ,
>/* Chromium OS verified boot context */
>   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 
> ,
>   BLOBLISTT_INTEL_VBT 
> ,
>/* Intel Video-BIOS table */
>   BLOBLISTT_TPM2_TCG_LOG 
> ,
>  /* TPM v2 log space */
>   BLOBLISTT_TCPA_LOG 
> ,
>  /* TPM log space */
>   BLOBLISTT_ACPI_TABLES 
> ,
>/* ACPI tables for x86 */
>   BLOBLISTT_SMBIOS_TABLES 
> ,
>/* SMBIOS tables for x86 */
>
> How about:

BLOBLISTT_LOCAL = 0xf000u   /* values in this space are for local use
during development */

>   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