I do wonder if you have read the OSF doc. That was a lot of work over a near 3 year period, and your doc looks like the very early drafts of that doc. I think it would pay to take a look.
On Wed, Apr 14, 2021 at 10:52 PM Loïc Minier <loic.min...@canonical.com> wrote: > Hi! > > Sorry for the late reply, here's a draft the concepts from this thread and > link them to sustainability levels: > > https://docs.google.com/document/d/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCEW7Y/edit?usp=sharing > (doc open for comments / suggestions from anyone, ping me if you need > write access) > > Best, > - Loïc Minier > > On Fri, 9 Apr 2021 at 13:45, François Ozog <francois.o...@linaro.org> > wrote: > >> >> >> On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt <xypron.g...@gmx.de> >> wrote: >> >>> On 09.04.21 08:59, François Ozog wrote: >>> > >>> > >>> > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.g...@gmx.de >>> > <mailto:xypron.g...@gmx.de>> wrote: >>> > >>> > On 4/8/21 10:46 AM, François Ozog wrote: >>> > > On Thu, 8 Apr 2021 at 10:30, Loïc Minier >>> > <loic.min...@canonical.com <mailto:loic.min...@canonical.com>> >>> wrote: >>> > > >>> > >> Hi François-Frédéric, >>> > >> >>> > >> Like you, I'm particularly keen to connect the dots between >>> > environmental >>> > >> sustainability and open source software. >>> > >> >>> > >> I love your levels, basically recognizing that if the firmware >>> is not >>> > >> updatable or maintained anymore, or if it can't fulfill its >>> > function by >>> > >> running TAs, the whole system might be rendered obsolete. >>> > >> >>> > >> There are two other interesting dimensions I would propose to >>> > consider: >>> > >> - resource requirements of the firmware and payloads such as TAs >>> > – the >>> > >> firmware/system is rendered obsolete because resources available >>> > for the >>> > >> firmware are insufficient, e.g. TAs or binaries grow in size or >>> > number or >>> > >> runtime requirements to the point that the device can't function >>> > >> >>> > > I missed that one even though we have a call on this topic today >>> > (see on >>> > > trusted-substrate.org <http://trusted-substrate.org>) on how to >>> > make TA lifecycle much easier, starting >>> > > with Secure DRAM size selection by product maker. There is also >>> an >>> > > ownership transfer discussion that I had with an industrial >>> player >>> > that >>> > > would allow formalization of who can change what "downstream" >>> (here >>> > > downstream is relative to software chain that starts with >>> firmware >>> > and ends >>> > > with applications) >>> > > >>> > >> - architectural requirements – the firmware or its payloads >>> start >>> > >> requiring recent hardware features or a newer API; this is >>> likely >>> > going to >>> > >> bring some tradeoffs in security as the bar keeps getting >>> higher; >>> > this >>> > >> could connect to your level 2 >>> > >> >>> > >> Good point. That said, this should not imply an ACPI HAL like >>> > effort by >>> > > the firmware. In addition, I remember the Panasonic CTO calling >>> > for using >>> > > virtio as a HAL even on non-virtualized environments. Would this >>> > be part of >>> > > the picture? >>> > > >>> > >> I'd love to help draft language or with recommendations around >>> this! >>> > >> >>> > >> That would be great: what about you share a Google doc and we >>> > discuss it >>> > > here? >>> > > >>> > >> Best, >>> > >> - Loïc Minier >>> > >> >>> > >> On Thu, 8 Apr 2021 at 10:12, François Ozog >>> > <francois.o...@linaro.org <mailto:francois.o...@linaro.org>> >>> > >> wrote: >>> > >> >>> > >>> Hi >>> > >>> >>> > >>> even though I am not an "ecology activist", sustainability is a >>> > topic dear >>> > >>> to me. And it can translate into firmware world... So I am >>> > targeting this >>> > >>> message to the audience of the two firmware communities I know >>> > and hope it >>> > >>> is okay to do so. >>> > >>> >>> > >>> March 2021 was a big date for Open Source Firmware >>> > >>> <https://www.opencompute.org/projects/open-system-firmware >>> > <https://www.opencompute.org/projects/open-system-firmware>>: that >>> > was the >>> > >>> deadline to get >>> > >>> >>> > >>> " >>> > >>> Owners must be able to change firmware and share it -- >>> including any >>> > >>> binary >>> > >>> components -- with other owners. Starting in March, 2021, OCP >>> > badging for >>> > >>> servers will require that systems support OSF. >>> > >>> " >>> > >>> >>> > >>> That's a big step towards sustainability in the OCP world. >>> > >>> >>> > >>> More generally, we should have the capacity to characterize >>> firmware >>> > >>> sustainability for post official firmware End Of Life. >>> > >>> >>> > >>> What about the following : >>> > >>> >>> > >>> level 0: system cannot evolve or be updated. >>> > >>> >>> > >>> level 1: the system can be updated to a bootable minimal >>> > functionality >>> > >>> with >>> > >>> open community effort.It may lack some features. For instance, >>> > you can >>> > >>> still look at your TV but lose Netflix 4K because the owners >>> (in OCP >>> > >>> sense) >>> > >>> cannot get a signed Netflix TA (either updated or not). >>> > >>> >>> > >>> level 2: the TAs and other binaries can be made available >>> > (signed) to the >>> > >>> ones maintaining open source firmware projects (TF-A, OP-TEE, >>> > U-Boot...). >>> > >>> For instance, owners (in the OCP sense) can get the updated >>> > Netflix TA >>> > >>> binary (updated or not) and sign it for inclusion. >>> > >>> > Getting a binary now does not mean that you will get a new >>> compatible >>> > binary in two years after a grave security bug has been discovered >>> in >>> > the WiFi firmware or Netflix uses a new encoding scheme. >>> > >>> > So isn't level 2 still on the path to obsolescence? >>> > >>> > I think I had the unconscious idea to have the equivalent of Google >>> > Project Trebble >>> > < >>> https://www.computerworld.com/article/3306443/what-is-project-treble-android-upgrade-fix-explained.html >>> >: >>> > the binary blobs are part of an ABI framework so that the project can >>> > evolve but still get access to old "stuff". >>> >>> This project is about supporting SoCs for four years and after that >>> comes obsolescence. >>> >>> If you are buying a mid-range phone without the newest SoC, it boils >>> down to the two years obsolescence of Android One phones which is a >>> shame. >>> >>> > There is nothing such as a free meal: blobs are inevitable and we don't >>> > want proliferation of ABI that could slow innovation. >>> > In other words, can we think of a Trebble for firmware that would allow >>> > evolution of the core open source projects and still be able to use old >>> > blobs? >>> > Making a mind experiment with DRAM initialization binary and a TF-A API >>> > change (which happened last year I think on my platform of interest), >>> > that change could have been made in such a way to maintain >>> compatibility >>> > with the old API. >>> > Is it something thinkable in the U-Boot context ? >>> >>> Looking through the U-Boot code I found the "NXP PFE Ethernet driver" >>> for LS1012A boards that uses a firmware blob. Of course using such a >>> blob does not stop us from developing the rest of U-Boot. Yet >>> obsolescence for LS1018A boards will be dictated by the availability of >>> updates for NXP's blob and license conditions. >>> >>> In a Trebble for Android world: there is an immutable ABI for ethernet >> driver (the most complex to accept has been on the GPU side). So you can >> update the entire system and still use an old blob. >> In a Trebble ofr U-Boot, we would define a similar immutable ABI for >> ethernet. >> Should NXP have compatible licensing conditions, some systems could be >> sustainability "level 2". >> (The goal is not to have all products be level 2 or 3, the goal is to >> understand what is possible with a particular product, and may be make a >> buying decision) >> >>> Best regards >>> >>> Heinrich >>> > >>> > >>> >>> > >>> level 3: all firmware components are open source and can thus >>> be >>> > community >>> > >>> maintained. >>> > >>> >>> > >>> I think : >>> > >>> Level 2 is the right balance between business value and >>> > "ecological" goal >>> > >>> of sustainability. >>> > >>> Level 3 is not mandatory and not the ultimate goal. >>> > >>> >>> > >>> Is this a good way to characterize sustainability? >>> > >>> How to make at least level 2 happen ? >>> > >>> >>> > >>> Cheers >>> > >>> >>> > >>> FF >>> > >>> -- >>> > >>> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing >>> > Group* >>> > >>> T: +33.67221.6485 >>> > >>> francois.o...@linaro.org <mailto:francois.o...@linaro.org> | >>> > Skype: ffozog >>> > >>> _______________________________________________ >>> > >>> boot-architecture mailing list >>> > >>> boot-architecture@lists.linaro.org >>> > <mailto:boot-architecture@lists.linaro.org> >>> > >>> https://lists.linaro.org/mailman/listinfo/boot-architecture >>> > <https://lists.linaro.org/mailman/listinfo/boot-architecture> >>> > >>> >>> > >> >>> > >> >>> > >> -- >>> > >> Loïc Minier >>> > >> >>> > > >>> > > >>> > >>> > >>> > >>> > -- >>> > >>> > François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ >>> > T: +33.67221.6485 >>> > francois.o...@linaro.org <mailto:francois.o...@linaro.org >>> > | Skype: ffozog >>> > >>> > >>> >>> >> >> -- >> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* >> T: +33.67221.6485 >> francois.o...@linaro.org | Skype: ffozog >> >> > > -- > Loïc Minier > _._,_._,_ > ------------------------------ > 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-...@ocp-all.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> > | Reply To Sender > <loic.min...@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+ow...@ocp-all.groups.io> | Unsubscribe > <https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy> > [rminn...@gmail.com] > _._,_._,_ > > _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
