HOBS are "bad'.
several reasons.
1. They depend on the nature of the C compiler and require use of a keyword
("packed") known to be an issue.
(i.e. there are alignment and padding requirements that not all
compilers handle the same way for all versions)
In fact, interestingly, a recent OpenTitan document describing best
practices for binary structs calls out bad practices that
are used in today's HOBs [they did not know this but I noticed it].
2. We've seen cases where the components of a HOB change with compiler flags
3. The degree to which they are open is not clear. It used to be that even
the name "HOB" was NDA.
For a long time the components were NDA.
At this moment it's not clear how much is open.
4. they are not self-describing; you need to have exact knowledge of their
binary structure to unpack them.
I'd like to move forward from HOBs to a true self-describing,
endian-independent, alignment-independent format.
There are lots of these, and many of them are designed in a way that makes
decoded fast and reliable.
ron
On Thu, Apr 15, 2021 at 9:28 AM Ryan O'Leary via groups.io <ryanoleary=
google....@groups.io> wrote:
> I can add this topic "Sustainable Firmware" to today's OSF call agenda if
> anyone is interested in discussions.
>
> For instructions on joining the call (it's in 30 mins, but repeats every
> second week): https://www.opencompute.org/projects/open-system-firmware
>
> Thanks,
> Ryan
>
> On Thu, Apr 15, 2021 at 8:22 AM ron minnich <rminn...@gmail.com> wrote:
>
>> Loic, it is wonderful to have you here. I think in the OCP OSF call today
>> (to which you are now invited, if you want; let me know -- same applies to
>> everyone here who's interested in open compute platform open *system*
>> firmware standard)
>>
>> Documenting ABIs is problematical, since not all OSF systems will be
>> following an existing ABI. That is a box best not opened. Most of the OSF
>> participants use both UEFI and LinuxBoot, and it's hard to imagine two more
>> incompatible systems.
>>
>> PIcking the size of flash is a hard one too, and it varies a lot
>> depending on the system, so we felt it best not to bring that in. Intel,
>> AMD, Power, ARM -- all have widely varying and incompatible issues.
>>
>> I wonder if I can interest you (and others) in a workshop I'm trying to
>> put together for linuxcon dublin end of september.
>>
>> LinuxBoot requires a solid kexec, and kexec is not quite there yet. Our
>> goal is to improve the situation with kexec. An ancillary goal is to get
>> the various distros to ship images that are "kexec friendly". We did talk
>> to Mark about all this a few years ago but it was a bit too early. I think
>> what with systemd starting to look at kexec, now it's time.
>>
>> I'd like to get canonical, red hat, and whoever else is interested in a
>> room and hammer out what we need to do to make kexec solid. As of now it's
>> too flaky.
>>
>> interested? Linux Conf sounds more and more like it will happen, and it
>> would be good to get people in the room and figure out kexec -- its current
>> capabilities, how its being used (e.g. Google has deployed LinuxBoot with
>> kexec at scale), its limits, and how to make distros "kexec friendly"
>>
>>
>>
>>
>>
>> On Thu, Apr 15, 2021 at 1:19 AM Loïc Minier <loic.min...@canonical.com>
>> wrote:
>>
>>> Hi Ron,
>>>
>>> Apologies; I clearly hadn't read enough. I just recently joined the
>>> OCP-OSF project's mailing-list as I wasn't aware of the effort before, and
>>> had only read the welcome web page. I've now read through the Governance,
>>> Charter and Transition schedule docs, and also saw the Pilot's draft
>>> Checklist gdoc and spreadsheet – I can see this overlaps with existing
>>> sections and topics. (Are there other consolidated docs or efforts you'd
>>> encourage new contributors to checkout?)
>>>
>>> I did see the idea of keys in the Ownership section of the Checklist
>>> doc. Is there a good place to document supported ABIs (I understand the
>>> spirit is not to mandate particular interfaces, but it would still make
>>> sense to document them)?
>>>
>>> There are some questions around existing artifacts, would that be the
>>> right place to document maximum capacity (eg size of flash)?
>>>
>>> Thanks,
>>> - Loïc
>>>
>>> On Thu, 15 Apr 2021 at 07:59, ron minnich <rminn...@gmail.com> wrote:
>>>
>>>> I do wonder if you have read the OSF doc. That was a lot of work over a
>>>> near 3 year period, and your doc looks like the very early drafts of that
>>>> doc. I think it would pay to take a look.
>>>>
>>>> On Wed, Apr 14, 2021 at 10:52 PM Loïc Minier <loic.min...@canonical.com>
>>>> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> Sorry for the late reply, here's a draft the concepts from this thread
>>>>> and link them to sustainability levels:
>>>>>
>>>>> https://docs.google.com/document/d/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCEW7Y/edit?usp=sharing
>>>>> (doc open for comments / suggestions from anyone, ping me if you need
>>>>> write access)
>>>>>
>>>>> Best,
>>>>> - Loïc Minier
>>>>>
>>>>> On Fri, 9 Apr 2021 at 13:45, François Ozog <francois.o...@linaro.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt <xypron.g...@gmx.de>
>>>>>> wrote:
>>>>>>
>>>>>>> On 09.04.21 08:59, François Ozog wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <
>>>>>>> xypron.g...@gmx.de
>>>>>>> > <mailto:xypron.g...@gmx.de>> wrote:
>>>>>>> >
>>>>>>> > On 4/8/21 10:46 AM, François Ozog wrote:
>>>>>>> > > On Thu, 8 Apr 2021 at 10:30, Loïc Minier
>>>>>>> > <loic.min...@canonical.com <mailto:loic.min...@canonical.com>>
>>>>>>> wrote:
>>>>>>> > >
>>>>>>> > >> Hi François-Frédéric,
>>>>>>> > >>
>>>>>>> > >> Like you, I'm particularly keen to connect the dots between
>>>>>>> > environmental
>>>>>>> > >> sustainability and open source software.
>>>>>>> > >>
>>>>>>> > >> I love your levels, basically recognizing that if the
>>>>>>> firmware is not
>>>>>>> > >> updatable or maintained anymore, or if it can't fulfill its
>>>>>>> > function by
>>>>>>> > >> running TAs, the whole system might be rendered obsolete.
>>>>>>> > >>
>>>>>>> > >> There are two other interesting dimensions I would propose
>>>>>>> to
>>>>>>> > consider:
>>>>>>> > >> - resource requirements of the firmware and payloads such
>>>>>>> as TAs
>>>>>>> > – the
>>>>>>> > >> firmware/system is rendered obsolete because resources
>>>>>>> available
>>>>>>> > for the
>>>>>>> > >> firmware are insufficient, e.g. TAs or binaries grow in
>>>>>>> size or
>>>>>>> > number or
>>>>>>> > >> runtime requirements to the point that the device can't
>>>>>>> function
>>>>>>> > >>
>>>>>>> > > I missed that one even though we have a call on this topic
>>>>>>> today
>>>>>>> > (see on
>>>>>>> > > trusted-substrate.org <http://trusted-substrate.org>) on
>>>>>>> how to
>>>>>>> > make TA lifecycle much easier, starting
>>>>>>> > > with Secure DRAM size selection by product maker. There is
>>>>>>> also an
>>>>>>> > > ownership transfer discussion that I had with an industrial
>>>>>>> player
>>>>>>> > that
>>>>>>> > > would allow formalization of who can change what
>>>>>>> "downstream" (here
>>>>>>> > > downstream is relative to software chain that starts with
>>>>>>> firmware
>>>>>>> > and ends
>>>>>>> > > with applications)
>>>>>>> > >
>>>>>>> > >> - architectural requirements – the firmware or its payloads
>>>>>>> start
>>>>>>> > >> requiring recent hardware features or a newer API; this is
>>>>>>> likely
>>>>>>> > going to
>>>>>>> > >> bring some tradeoffs in security as the bar keeps getting
>>>>>>> higher;
>>>>>>> > this
>>>>>>> > >> could connect to your level 2
>>>>>>> > >>
>>>>>>> > >> Good point. That said, this should not imply an ACPI HAL
>>>>>>> like
>>>>>>> > effort by
>>>>>>> > > the firmware. In addition, I remember the Panasonic CTO
>>>>>>> calling
>>>>>>> > for using
>>>>>>> > > virtio as a HAL even on non-virtualized environments. Would
>>>>>>> this
>>>>>>> > be part of
>>>>>>> > > the picture?
>>>>>>> > >
>>>>>>> > >> I'd love to help draft language or with recommendations
>>>>>>> around this!
>>>>>>> > >>
>>>>>>> > >> That would be great: what about you share a Google doc and
>>>>>>> we
>>>>>>> > discuss it
>>>>>>> > > here?
>>>>>>> > >
>>>>>>> > >> Best,
>>>>>>> > >> - Loïc Minier
>>>>>>> > >>
>>>>>>> > >> On Thu, 8 Apr 2021 at 10:12, François Ozog
>>>>>>> > <francois.o...@linaro.org <mailto:francois.o...@linaro.org>>
>>>>>>> > >> wrote:
>>>>>>> > >>
>>>>>>> > >>> Hi
>>>>>>> > >>>
>>>>>>> > >>> even though I am not an "ecology activist", sustainability
>>>>>>> is a
>>>>>>> > topic dear
>>>>>>> > >>> to me. And it can translate into firmware world... So I am
>>>>>>> > targeting this
>>>>>>> > >>> message to the audience of the two firmware communities I
>>>>>>> know
>>>>>>> > and hope it
>>>>>>> > >>> is okay to do so.
>>>>>>> > >>>
>>>>>>> > >>> March 2021 was a big date for Open Source Firmware
>>>>>>> > >>> <https://www.opencompute.org/projects/open-system-firmware
>>>>>>> > <https://www.opencompute.org/projects/open-system-firmware>>:
>>>>>>> that
>>>>>>> > was the
>>>>>>> > >>> deadline to get
>>>>>>> > >>>
>>>>>>> > >>> "
>>>>>>> > >>> Owners must be able to change firmware and share it --
>>>>>>> including any
>>>>>>> > >>> binary
>>>>>>> > >>> components -- with other owners. Starting in March, 2021,
>>>>>>> OCP
>>>>>>> > badging for
>>>>>>> > >>> servers will require that systems support OSF.
>>>>>>> > >>> "
>>>>>>> > >>>
>>>>>>> > >>> That's a big step towards sustainability in the OCP world.
>>>>>>> > >>>
>>>>>>> > >>> More generally, we should have the capacity to
>>>>>>> characterize firmware
>>>>>>> > >>> sustainability for post official firmware End Of Life.
>>>>>>> > >>>
>>>>>>> > >>> What about the following :
>>>>>>> > >>>
>>>>>>> > >>> level 0: system cannot evolve or be updated.
>>>>>>> > >>>
>>>>>>> > >>> level 1: the system can be updated to a bootable minimal
>>>>>>> > functionality
>>>>>>> > >>> with
>>>>>>> > >>> open community effort.It may lack some features. For
>>>>>>> instance,
>>>>>>> > you can
>>>>>>> > >>> still look at your TV but lose Netflix 4K because the
>>>>>>> owners (in OCP
>>>>>>> > >>> sense)
>>>>>>> > >>> cannot get a signed Netflix TA (either updated or not).
>>>>>>> > >>>
>>>>>>> > >>> level 2: the TAs and other binaries can be made available
>>>>>>> > (signed) to the
>>>>>>> > >>> ones maintaining open source firmware projects (TF-A,
>>>>>>> OP-TEE,
>>>>>>> > U-Boot...).
>>>>>>> > >>> For instance, owners (in the OCP sense) can get the updated
>>>>>>> > Netflix TA
>>>>>>> > >>> binary (updated or not) and sign it for inclusion.
>>>>>>> >
>>>>>>> > Getting a binary now does not mean that you will get a new
>>>>>>> compatible
>>>>>>> > binary in two years after a grave security bug has been
>>>>>>> discovered in
>>>>>>> > the WiFi firmware or Netflix uses a new encoding scheme.
>>>>>>> >
>>>>>>> > So isn't level 2 still on the path to obsolescence?
>>>>>>> >
>>>>>>> > I think I had the unconscious idea to have the equivalent of Google
>>>>>>> > Project Trebble
>>>>>>> > <
>>>>>>> https://www.computerworld.com/article/3306443/what-is-project-treble-android-upgrade-fix-explained.html
>>>>>>> >:
>>>>>>> > the binary blobs are part of an ABI framework so that the project
>>>>>>> can
>>>>>>> > evolve but still get access to old "stuff".
>>>>>>>
>>>>>>> This project is about supporting SoCs for four years and after that
>>>>>>> comes obsolescence.
>>>>>>>
>>>>>>> If you are buying a mid-range phone without the newest SoC, it boils
>>>>>>> down to the two years obsolescence of Android One phones which is a
>>>>>>> shame.
>>>>>>>
>>>>>>> > There is nothing such as a free meal: blobs are inevitable and we
>>>>>>> don't
>>>>>>> > want proliferation of ABI that could slow innovation.
>>>>>>> > In other words, can we think of a Trebble for firmware that would
>>>>>>> allow
>>>>>>> > evolution of the core open source projects and still be able to
>>>>>>> use old
>>>>>>> > blobs?
>>>>>>> > Making a mind experiment with DRAM initialization binary and a
>>>>>>> TF-A API
>>>>>>> > change (which happened last year I think on my platform of
>>>>>>> interest),
>>>>>>> > that change could have been made in such a way to maintain
>>>>>>> compatibility
>>>>>>> > with the old API.
>>>>>>> > Is it something thinkable in the U-Boot context ?
>>>>>>>
>>>>>>> Looking through the U-Boot code I found the "NXP PFE Ethernet driver"
>>>>>>> for LS1012A boards that uses a firmware blob. Of course using such a
>>>>>>> blob does not stop us from developing the rest of U-Boot. Yet
>>>>>>> obsolescence for LS1018A boards will be dictated by the availability
>>>>>>> of
>>>>>>> updates for NXP's blob and license conditions.
>>>>>>>
>>>>>>> In a Trebble for Android world: there is an immutable ABI for
>>>>>> ethernet driver (the most complex to accept has been on the GPU side). So
>>>>>> you can update the entire system and still use an old blob.
>>>>>> In a Trebble ofr U-Boot, we would define a similar immutable ABI for
>>>>>> ethernet.
>>>>>> Should NXP have compatible licensing conditions, some systems could
>>>>>> be sustainability "level 2".
>>>>>> (The goal is not to have all products be level 2 or 3, the goal is to
>>>>>> understand what is possible with a particular product, and may be make a
>>>>>> buying decision)
>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Heinrich
>>>>>>> >
>>>>>>> > >>>
>>>>>>> > >>> level 3: all firmware components are open source and can
>>>>>>> thus be
>>>>>>> > community
>>>>>>> > >>> maintained.
>>>>>>> > >>>
>>>>>>> > >>> I think :
>>>>>>> > >>> Level 2 is the right balance between business value and
>>>>>>> > "ecological" goal
>>>>>>> > >>> of sustainability.
>>>>>>> > >>> Level 3 is not mandatory and not the ultimate goal.
>>>>>>> > >>>
>>>>>>> > >>> Is this a good way to characterize sustainability?
>>>>>>> > >>> How to make at least level 2 happen ?
>>>>>>> > >>>
>>>>>>> > >>> Cheers
>>>>>>> > >>>
>>>>>>> > >>> FF
>>>>>>> > >>> --
>>>>>>> > >>> François-Frédéric Ozog | *Director Linaro Edge & Fog
>>>>>>> Computing
>>>>>>> > Group*
>>>>>>> > >>> T: +33.67221.6485
>>>>>>> > >>> francois.o...@linaro.org <mailto:francois.o...@linaro.org>
>>>>>>> |
>>>>>>> > Skype: ffozog
>>>>>>> > >>> _______________________________________________
>>>>>>> > >>> boot-architecture mailing list
>>>>>>> > >>> boot-architecture@lists.linaro.org
>>>>>>> > <mailto:boot-architecture@lists.linaro.org>
>>>>>>> > >>>
>>>>>>> https://lists.linaro.org/mailman/listinfo/boot-architecture
>>>>>>> > <https://lists.linaro.org/mailman/listinfo/boot-architecture>
>>>>>>> > >>>
>>>>>>> > >>
>>>>>>> > >>
>>>>>>> > >> --
>>>>>>> > >> Loïc Minier
>>>>>>> > >>
>>>>>>> > >
>>>>>>> > >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > --
>>>>>>> >
>>>>>>> > François-Frédéric Ozog | /Director Linaro Edge & Fog Computing
>>>>>>> Group/
>>>>>>> > T: +33.67221.6485
>>>>>>> > francois.o...@linaro.org <mailto:francois.o...@linaro.org
>>>>>>> > | Skype: ffozog
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
>>>>>> T: +33.67221.6485
>>>>>> francois.o...@linaro.org | Skype: ffozog
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Loïc Minier
>>>>>
>>>>>
>>>
>>> --
>>> Loïc Minier
>>>
>>> _._,_._,_
> ------------------------------
> Groups.io Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#139) <https://OCP-All.groups.io/g/OCP-OSF/message/139>
> | Reply To Group
> <ocp-...@ocp-all.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence>
> | Reply To Sender
> <ryanole...@google.com?subject=Private:%20Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence>
> | Mute This Topic <https://groups.io/mt/81937262/1492462> | New Topic
> <https://OCP-All.groups.io/g/OCP-OSF/post>
> Your Subscription <https://OCP-All.groups.io/g/OCP-OSF/editsub/1492462> |
> Contact
> Group Owner <ocp-osf+ow...@ocp-all.groups.io> | Unsubscribe
> <https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy>
> [rminn...@gmail.com]
> _._,_._,_
>
>
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
