For the wayback machine, the design of HOB’s dates back to early 2000’s.

 

 

The HOB defin was part of the Intel Framework specs & it was made public in 2003 through a click-through, as folks noted.  HOBs became part of the UEFI Forum Platform Initialization (PI) spec in 2006.  Essentially PI 1.0 absorbed most of the Framework 0.9x specs (sans datahub, CSM).

from https://link.springer.com/book/10.1007/978-1-4842-0070-4

 

IMHO the biggest bug on the present Type Length Value (TLV)-based HOB design entails the “L” of the TLV, namely the 16-bit length limitation on the size of a specific HOB.  Servers often bump into this limitation today given the amount of state discovered in these early initialization flows.  The use of GUID’s w/o strings is also a usability challenge, I’d agree, that any new design can address.

 

Going forward

The more recent proposed use of HOB's for the generic payload interface https://github.com/universalpayload/documentation launching was more for convenience since it's a simple TLV encoded mechanism and there are parsing libraries already in the wild. But the use of HOB’s versus DT versus  …. for the inargs of the payload is definitely open for discussion/change in the design.  The earlier thread suggestions of CBOR/8949 https://www.rfc-editor.org/rfc/rfc8949.html  from Francois/Nate is interesting. We can update the already open issue on this topic https://github.com/universalpayload/documentation/issues/9  with some of these thoughts and build upon the sentiments Ron shared earlier on the topic.

 

And regarding the payload specification https://universalpayload.github.io/documentation/ mentioned above, I’m happy to present on this design effort in an upcoming OSF meeting, including how payloads may relate to the OSF workstream.  The payload design is intended to be an open process with a code-first workflow that doesn’t tie itself to any specific bootloader design, as demonstrated by the different bootloaders and payloads ported at https://github.com/universalpayload.  Although there isn’t a U-Boot example ported (I thought I heard mention of U-boot in this thread or meeting?), addressing the needs of U-boot and other *boot solutions (e.g., oreboot) is definitely part of the design scope intent, too.

 

Thanks,

 

Vincent

 

 

-----Original Message-----
From: OCP-OSF@OCP-All.groups.io <OCP-OSF@OCP-All.groups.io> On Behalf Of ron minnich
Sent: Thursday, April 15, 2021 3:14 PM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Cc: OCP-OSF@OCP-All.groups.io; Boot Architecture Mailman List <boot-architecture@lists.linaro.org>; Leif Lindholm <leif@nuviainc.com>
Subject: Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

 

actually isn't device tree a 1980s design :-)

 

anyway, as long as we can hit the things I care so much about,

 

self describing

alignment independent

endian independent

names not magic numbers (I mean, you want to put a UUID in there too, fine, but I doubt a human-readable string will kill us on space)

 

it can be anything you all think best.

 

On Thu, Apr 15, 2021 at 2:49 PM Desimone, Nathaniel L <nathaniel.l.desimone@intel.com> wrote:

> 

> On Thu, Apr 15, 2021 at 1:29 -0700, ron minnich wrote:

> 

> >I'd rather not take HOB as a given without considering alternatives.

> >It's a very 1990s design.

> 

> Device tree is also a very early 90s design for that matter. If we are talking about clean slate design, how about something actually new and modern like RFC 8949?

> 

> From a practical standpoint I don't see HOBs going away very soon but I'm open to possibility thinking on a long term basis.

> 

>

> 

> 

 

 

 

 

_._,_._,_

---

Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#149) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [francois.ozog@linaro.org]

_._,_._,_