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