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: 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.
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
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 - 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
I'd love to help draft language or with recommendations around this!
Best, - Loïc Minier
On Thu, 8 Apr 2021 at 10:12, François Ozog francois.ozog@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: 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.
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Thu, 8 Apr 2021 at 10:30, Loïc Minier loic.minier@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) 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.ozog@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: 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.
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Loïc Minier
On 4/8/21 10:46 AM, François Ozog wrote:
On Thu, 8 Apr 2021 at 10:30, Loïc Minier loic.minier@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) 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.ozog@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: 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?
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Loïc Minier
You can see how quickly this gets complicated. It is why we tried to keep the OSF requirements as simple as possible.
The requirements, in their most basic form, allow owners of systems to modify firmware, install it, and share it. Open source is not required.
But for customers to install firmware is very hard in the x86 world nowadays. It's impossible on dell and HPE and many other systems, to name a few. If you modify one bit -- literally one bit -- most modern servers will fail to boot.
So going back to your levels:
level 0: system cannot evolve or be updated.
Level 0 is where we are today.
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).
This is not really appropriate for OCP, and nobody owning a server will want OSF if it means capability is lost. I don't think this is useful for OCP.
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.
This doesn't really fit the x86 world either.
level 3: all firmware components are open source and can thus be community maintained.
The only system on which this works completely today is IBM Power.
Getting back to Open System Firmware:
So, to reiterate, Open System Firmware (NOT open source -- open system) is very simple.
Owners have to be able to modify, install, and share their modified firmware.
Modification and installation require that the vendors sell hardware that allows it. Many x86 vendors can't do this today.
Sharing is purely a matter for lawyers, and should be possible.
On Thu, Apr 8, 2021 at 10:38 AM Heinrich Schuchardt xypron.glpk@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.minier@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) 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.ozog@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: 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?
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Loïc Minier
-=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#129): https://OCP-All.groups.io/g/OCP-OSF/message/129 Mute This Topic: https://groups.io/mt/81937262/1492462 Group Owner: OCP-OSF+owner@OCP-All.groups.io Unsubscribe: https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy [rminnich@gmail.com] -=-=-=-=-=-=-=-=-=-=-=-
On Thu, 8 Apr 2021 at 19:53, ron minnich rminnich@gmail.com wrote:
You can see how quickly this gets complicated. It is why we tried to keep the OSF requirements as simple as possible.
The requirements, in their most basic form, allow owners of systems to modify firmware, install it, and share it. Open source is not required.
But for customers to install firmware is very hard in the x86 world nowadays. It's impossible on dell and HPE and many other systems, to name a few. If you modify one bit -- literally one bit -- most modern servers will fail to boot.
So going back to your levels:
level 0: system cannot evolve or be updated.
Level 0 is where we are today.
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).
This is not really appropriate for OCP, and nobody owning a server will want OSF if it means capability is lost. I don't think this is useful for OCP.
Indeed, here I am just trying to identify what can be the cases
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.
This doesn't really fit the x86 world either.
Not sure why. Could you elaborate? Here the main system firmware is open
source, access to binary elements is facilitated by the providers themselves. So it achieves the sustainability goal.
level 3: all firmware components are open source and can thus be community maintained.
The only system on which this works completely today is IBM Power.
Getting back to Open System Firmware:
So, to reiterate, Open System Firmware (NOT open source -- open system) is very simple.
How can I miss that one!!!
Owners have to be able to modify, install, and share their modified firmware.
Modification and installation require that the vendors sell hardware that allows it. Many x86 vendors can't do this today.
Sharing is purely a matter for lawyers, and should be possible.
On Thu, Apr 8, 2021 at 10:38 AM Heinrich Schuchardt xypron.glpk@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.minier@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) 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.ozog@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: 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?
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Loïc Minier
-=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#129):
https://OCP-All.groups.io/g/OCP-OSF/message/129
Mute This Topic: https://groups.io/mt/81937262/1492462 Group Owner: OCP-OSF+owner@OCP-All.groups.io Unsubscribe:
https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy [rminnich@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-
On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt xypron.glpk@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.minier@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) 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.ozog@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: 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". 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 ?
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.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Loïc Minier
On 09.04.21 08:59, François Ozog wrote:
On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@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.minier@canonical.com <mailto:loic.minier@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.ozog@linaro.org <mailto:francois.ozog@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.
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.ozog@linaro.org <mailto:francois.ozog@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.ozog@linaro.org mailto:francois.ozog@linaro.org | Skype: ffozog
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09.04.21 08:59, François Ozog wrote:
On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@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.minier@canonical.com <mailto:loic.minier@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 isnot
>> 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 aroundthis!
>> >> 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.ozog@linaro.org <mailto:francois.ozog@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 -- includingany
>>> 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 characterizefirmware
>>> 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 (inOCP
>>> 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...
: 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.ozog@linaro.org <mailto:francois.ozog@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.ozog@linaro.org <mailto:francois.ozog@linaro.org | Skype: ffozog
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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE... (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.ozog@linaro.org wrote:
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09.04.21 08:59, François Ozog wrote:
On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@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.minier@canonical.com <mailto:loic.minier@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 firmwareis 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 aroundthis!
>> >> 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.ozog@linaro.org <mailto:francois.ozog@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 characterizefirmware
>>> 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 newcompatible
binary in two years after a grave security bug has been discoveredin
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...
: 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.ozog@linaro.org <mailto:francois.ozog@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.ozog@linaro.org <mailto:francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE... (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.ozog@linaro.org wrote:
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09.04.21 08:59, François Ozog wrote:
On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@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.minier@canonical.com <mailto:loic.minier@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 firmwareis 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 alsoan
> ownership transfer discussion that I had with an industrialplayer
that > would allow formalization of who can change what "downstream"(here
> downstream is relative to software chain that starts withfirmware
and ends > with applications) > >> - architectural requirements – the firmware or its payloadsstart
>> requiring recent hardware features or a newer API; this islikely
going to >> bring some tradeoffs in security as the bar keeps gettinghigher;
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 aroundthis!
>> >> 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.ozog@linaro.org <mailto:francois.ozog@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 characterizefirmware
>>> 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 newcompatible
binary in two years after a grave security bug has been discoveredin
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...
: 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 thusbe
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.ozog@linaro.org <mailto:francois.ozog@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.ozog@linaro.org <mailto:francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- Loïc Minier _._,_._,_
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#135) https://OCP-All.groups.io/g/OCP-OSF/message/135 | Reply To Group <OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Reply To Sender <loic.minier@canonical.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+owner@OCP-All.groups.io | Unsubscribe https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy [rminnich@gmail.com] _._,_._,_
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 rminnich@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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE... (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.ozog@linaro.org wrote:
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09.04.21 08:59, François Ozog wrote:
On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@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.minier@canonical.com <mailto:loic.minier@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 firmwareis 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 asTAs
– the >> firmware/system is rendered obsolete because resourcesavailable
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'tfunction
>> > 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 alsoan
> ownership transfer discussion that I had with an industrialplayer
that > would allow formalization of who can change what "downstream"(here
> downstream is relative to software chain that starts withfirmware
and ends > with applications) > >> - architectural requirements – the firmware or its payloadsstart
>> requiring recent hardware features or a newer API; this islikely
going to >> bring some tradeoffs in security as the bar keeps gettinghigher;
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 aroundthis!
>> >> 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.ozog@linaro.org <mailto:francois.ozog@linaro.org>> >> wrote: >> >>> Hi >>> >>> even though I am not an "ecology activist", sustainability isa
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 characterizefirmware
>>> 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 newcompatible
binary in two years after a grave security bug has beendiscovered 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...
: 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 thusbe
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.ozog@linaro.org <mailto:francois.ozog@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.ozog@linaro.org <mailto:francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- Loïc Minier
_._,_._,_
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#136) https://OCP-All.groups.io/g/OCP-OSF/message/136 | Reply To Group <OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Reply To Sender <rminnich@gmail.com?subject=Private:%20Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Mute This Topic https://groups.io/mt/81937262/6035047 | New Topic https://OCP-All.groups.io/g/OCP-OSF/post Your Subscription https://OCP-All.groups.io/g/OCP-OSF/editsub/6035047 | Contact Group Owner OCP-OSF+owner@OCP-All.groups.io | Unsubscribe https://OCP-All.groups.io/g/OCP-OSF/leave/10185920/6035047/1270533012/xyzzy [loic.minier@canonical.com] _._,_._,_
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.minier@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 rminnich@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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE... (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.ozog@linaro.org wrote:
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09.04.21 08:59, François Ozog wrote:
On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@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.minier@canonical.com <mailto:loic.minier@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 thefirmware 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 asTAs
– the >> firmware/system is rendered obsolete because resourcesavailable
for the >> firmware are insufficient, e.g. TAs or binaries grow in sizeor
number or >> runtime requirements to the point that the device can'tfunction
>> > I missed that one even though we have a call on this topictoday
(see on > trusted-substrate.org <http://trusted-substrate.org>) on howto
make TA lifecycle much easier, starting > with Secure DRAM size selection by product maker. There isalso an
> ownership transfer discussion that I had with an industrialplayer
that > would allow formalization of who can change what "downstream"(here
> downstream is relative to software chain that starts withfirmware
and ends > with applications) > >> - architectural requirements – the firmware or its payloadsstart
>> requiring recent hardware features or a newer API; this islikely
going to >> bring some tradeoffs in security as the bar keeps gettinghigher;
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. Wouldthis
be part of > the picture? > >> I'd love to help draft language or with recommendationsaround 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.ozog@linaro.org <mailto:francois.ozog@linaro.org>> >> wrote: >> >>> Hi >>> >>> even though I am not an "ecology activist", sustainabilityis 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 Iknow
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 characterizefirmware
>>> 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. Forinstance,
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 newcompatible
binary in two years after a grave security bug has beendiscovered 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...
: 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 canthus 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 & FogComputing
Group* >>> T: +33.67221.6485 >>> francois.ozog@linaro.org <mailto:francois.ozog@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.ozog@linaro.org <mailto:francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- Loïc Minier
-- Loïc Minier _._,_._,_
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#137) https://OCP-All.groups.io/g/OCP-OSF/message/137 | Reply To Group <OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Reply To Sender <loic.minier@canonical.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+owner@OCP-All.groups.io | Unsubscribe https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy [rminnich@gmail.com] _._,_._,_
On Thu, 15 Apr 2021 at 17:21, ron minnich rminnich@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)
(ahhhh I feel bad ;-)
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.
Ampere is proposing we standardize HOBs (DRAM information...) when
launching U-Boot. I am advocating to use this for any non-secure firmware, be it EDK2, U-Boot or LinuxBoot. Adopting EDK2 HOBs or similar (see Platform Initialization chapter 5) would greatly simplify things and further reduce non value bringing platform specific code. It is also helping making the TrustZone a much simpler place to organize. And it is also architecture agnostic.
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.
Please count me in.
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.
I'll pass the word...
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.minier@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 rminnich@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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE...
(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.ozog@linaro.org wrote:
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09.04.21 08:59, François Ozog wrote: > > > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <
xypron.glpk@gmx.de
> mailto:xypron.glpk@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.minier@canonical.com mailto:loic.minier@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.ozog@linaro.org mailto:francois.ozog@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...
>: > 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.ozog@linaro.org mailto:francois.ozog@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.ozog@linaro.org mailto:francois.ozog@linaro.org | Skype: ffozog > >
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- Loïc Minier
-- Loïc Minier _._,_._,_
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#137) <
https://OCP-All.groups.io/g/OCP-OSF/message/137%3E
| Reply To Group <
OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence
| Reply To Sender <
loic.minier@canonical.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+owner@OCP-All.groups.io | Unsubscribe <
https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy%3E
[rminnich@gmail.com] _._,_._,_
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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 rminnich@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.minier@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 rminnich@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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE... (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.ozog@linaro.org wrote:
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09.04.21 08:59, François Ozog wrote: > > > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt < xypron.glpk@gmx.de > mailto:xypron.glpk@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.minier@canonical.com mailto:loic.minier@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.ozog@linaro.org mailto:francois.ozog@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... >: > 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.ozog@linaro.org mailto:francois.ozog@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.ozog@linaro.org mailto:francois.ozog@linaro.org | Skype: ffozog > >
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- Loïc Minier
-- Loïc Minier
_._,_._,_
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#138) https://OCP-All.groups.io/g/OCP-OSF/message/138 | Reply To Group <OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Reply To Sender <rminnich@gmail.com?subject=Private:%20Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Mute This Topic https://groups.io/mt/81937262/1746712 | New Topic https://OCP-All.groups.io/g/OCP-OSF/post Your Subscription https://OCP-All.groups.io/g/OCP-OSF/editsub/1746712 | Contact Group Owner OCP-OSF+owner@OCP-All.groups.io | Unsubscribe https://OCP-All.groups.io/g/OCP-OSF/leave/3823437/1746712/1584468655/xyzzy [ryanoleary@google.com] _._,_._,_
I won't be able to make the time in 15mn (I misread the Gcalendar's TZ and thought it was at 1pm my time) , but I'd love to be invited to future meetings; this 7pm CEST time might be problematic for me some weeks where I have other commitments, but I'll do my best to attend :-)
On Thu, 15 Apr 2021 at 18:28, Ryan O'Leary via groups.io <ryanoleary= google.com@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 rminnich@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.minier@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 rminnich@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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE... (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.ozog@linaro.org wrote:
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
> On 09.04.21 08:59, François Ozog wrote: > > > > > > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt < > xypron.glpk@gmx.de > > mailto:xypron.glpk@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.minier@canonical.com mailto:loic.minier@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.ozog@linaro.org mailto:francois.ozog@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... > >: > > 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.ozog@linaro.org mailto:francois.ozog@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.ozog@linaro.org mailto:francois.ozog@linaro.org > | Skype: ffozog > > > > > >
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@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-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Reply To Sender <ryanoleary@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/6035047 | New Topic https://OCP-All.groups.io/g/OCP-OSF/post Your Subscription https://OCP-All.groups.io/g/OCP-OSF/editsub/6035047 | Contact Group Owner OCP-OSF+owner@OCP-All.groups.io | Unsubscribe https://OCP-All.groups.io/g/OCP-OSF/leave/10185920/6035047/1270533012/xyzzy [loic.minier@canonical.com] _._,_._,_
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.com@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 rminnich@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.minier@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 rminnich@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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE... (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.ozog@linaro.org wrote:
On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
> On 09.04.21 08:59, François Ozog wrote: > > > > > > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt < > xypron.glpk@gmx.de > > mailto:xypron.glpk@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.minier@canonical.com mailto:loic.minier@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.ozog@linaro.org mailto:francois.ozog@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... > >: > > 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.ozog@linaro.org mailto:francois.ozog@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.ozog@linaro.org mailto:francois.ozog@linaro.org > | Skype: ffozog > > > > > >
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@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-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Reply To Sender <ryanoleary@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+owner@OCP-All.groups.io | Unsubscribe https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy [rminnich@gmail.com] _._,_._,_
On Thu, 15 Apr 2021 at 19:42, ron minnich rminnich@gmail.com wrote:
HOBS are "bad'.
several reasons.
- 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].
I have tried to find it but could only found this: https://docs.opentitan.org/doc/ug/rust_for_c/ "packed" at least works otherwise no network protocol would be operating as expected. I agree that portable "packed" is hard because of alignment aspects on some architectures.
- 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.
Partly open: it allows extensions. If we define HOBs (the function of, not the PI ones) I'll make sure to include "if you add extensions, then their specification must be made public".
- 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.
Well, some HOBs can be like that because when you are configuring the DRAM
controllers and the like, each byte on data and instructions count. So those can't be anything but compact binary objects. As we grow up in the layers, HOBs may evolve. Natural candidate for embedded world is Device Tree. But why not CBOR or things like that.
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.com@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 rminnich@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.minier@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 rminnich@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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE...
(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.ozog@linaro.org
wrote:
> > > On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt <
xypron.glpk@gmx.de>
> wrote: > >> On 09.04.21 08:59, François Ozog wrote: >> > >> > >> > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt < >> xypron.glpk@gmx.de >> > mailto:xypron.glpk@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.minier@canonical.com <mailto:loic.minier@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.ozog@linaro.org mailto:francois.ozog@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
>> > Project Trebble >> > < >>
https://www.computerworld.com/article/3306443/what-is-project-treble-android...
>> >: >> > 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.ozog@linaro.org <mailto:
francois.ozog@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.ozog@linaro.org mailto:francois.ozog@linaro.org > > | Skype: ffozog >> > >> > >> >> > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing
Group*
> T: +33.67221.6485 > francois.ozog@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%3E
| Reply To Group <
OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence
| Reply To Sender <
ryanoleary@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+owner@OCP-All.groups.io | Unsubscribe <
https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy%3E
[rminnich@gmail.com] _._,_._,_
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Thu, Apr 15, 2021 at 11:25 AM François Ozog francois.ozog@linaro.org wrote:
"packed" at least works otherwise no network protocol would be operating as expected.
that is a very common misconception. C code for networks existed for decades before packed existed.
packed does not exist in plan 9 compilers to this day and they work fine without it.
The use of packed almost always indicated non-portable assumptions or just plain bad design. Let's stop doing that.
Well, some HOBs can be like that because when you are configuring the DRAM
controllers and the like, each byte on data and instructions count. So those can't be anything but compact binary objects. As we grow up in the layers, HOBs may evolve. Natural candidate for embedded world is Device Tree. But why not CBOR or things like that.
I think device tree would be fine. And defining a marshaling rule from device tree to compact structs for DRAM controllers is a solved problem.
Device tree is a FAR better choice than HOBs. HOBs were a mistake from the time they were created.
On Thu, Apr 15, 2021 at 10:41:28 -0700, ron minnich wrote:
HOBS are "bad'.
several reasons.
- 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)
/work/git/linux$ git grep packed | wc -l 15305
So I guess LinuxBoot is out too ;)
In fact, interestingly, a recent OpenTitan document describing bestpractices for binary structs calls out bad practices that are used in today's HOBs [they did not know this but I noticed it].
- We've seen cases where the components of a HOB change with
compiler flags
- The degree to which they are open is not clear.
It used to be that even the name "HOB" was NDA.
It is mentioned in version 1.2B of the PI specification, released 2010.
www.uefi.org/sites/default/files/resources/PI_Spec_1.2_B.zip
This is the oldest one downloadable from https://uefi.org/specifications
For a long time the components were NDA.
I don't recall that far back.
The specifications used to be hidden behind a click-through license. I think it was 2013 that we managed to get that removed.
At this moment it's not clear how much is open.
- 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.
If you want to argue for alternatives on technical or licensing merits, you are more than welcome to do so.
/ Leif
ron
On Thu, Apr 15, 2021 at 9:28 AM Ryan O'Leary via groups.io <ryanoleary= google.com@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 rminnich@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.minier@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 rminnich@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.minier@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/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCE... (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.ozog@linaro.org wrote:
> > > On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de > wrote: > >> On 09.04.21 08:59, François Ozog wrote: >> > >> > >> > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt < >> xypron.glpk@gmx.de >> > mailto:xypron.glpk@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.minier@canonical.com mailto:loic.minier@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.ozog@linaro.org mailto:francois.ozog@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... >> >: >> > 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.ozog@linaro.org mailto:francois.ozog@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.ozog@linaro.org mailto:francois.ozog@linaro.org > > | Skype: ffozog >> > >> > >> >> > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > francois.ozog@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-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> | Reply To Sender <ryanoleary@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+owner@OCP-All.groups.io | Unsubscribe https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy [rminnich@gmail.com] _._,_._,_
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Thu, Apr 15, 2021 at 12:43 PM Leif Lindholm leif@nuviainc.com wrote:
It is mentioned in version 1.2B of the PI specification, released 2010.
yep, and when I visited google in 2003, somebody mentioned the name HOB to me and then said "oops, don't repeat that name". So for half of its life, the name "HOB" was NDA.
The specifications used to be hidden behind a click-through license. I think it was 2013 that we managed to get that removed.
so 15 years in, we got past that limit. By then it was far too late. The design was locked down by that point, with all its mistakes wired in.
It's 23 years now, and for something we hope to use for the next 23 years, we can do better.
Even device tree would be far better.
I'd rather not take HOB as a given without considering alternatives. It's a very 1990s design.
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 (#146): https://OCP-All.groups.io/g/OCP-OSF/message/146 Mute This Topic: https://groups.io/mt/81937262/1767664 Group Owner: OCP-OSF+owner@OCP-All.groups.io Unsubscribe: https://OCP-All.groups.io/g/OCP-OSF/leave/6627687/1767664/1274031919/xyzzy [nathaniel.l.desimone@intel.com] -=-=-=-=-=-=-=-=-=-=-=-
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 (#146): https://OCP-All.groups.io/g/OCP-OSF/message/146 Mute This Topic: https://groups.io/mt/81937262/1767664 Group Owner: OCP-OSF+owner@OCP-All.groups.io Unsubscribe: https://OCP-All.groups.io/g/OCP-OSF/leave/6627687/1767664/1274031919/xyzzy [nathaniel.l.desimone@intel.com] -=-=-=-=-=-=-=-=-=-=-=-
boot-architecture@lists.linaro.org
-
Desimone, Nathaniel L -
François Ozog -
Heinrich Schuchardt -
Leif Lindholm -
Loïc Minier -
ron minnich -
Ryan O'Leary