On Thu, 15 Apr 2021 at 17:21, 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) > > (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.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 (#137) < > https://OCP-All.groups.io/g/OCP-OSF/message/137> > > | 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 > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
