note that I am having this exact same problem in the RISC-V community: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/102
People just like their SMM. It's hard to kill. I fear that you're not going to get much luck with Intel, which is why I try to work with non-Intel CPUs as much as I can nowadays. On Fri, Sep 30, 2022 at 5:58 AM Nico Huber <nic...@gmx.de> wrote: > Hi Arthur, coreboot fellows, > > On 30.09.22 13:53, Arthur Heymans wrote: > > What are your thoughts? > > printing, bonfire... > > > Do we take a stance against FSP-I integration in coreboot? > > I think we already do. From coreboot.org: > > "coreboot is an extended firmware platform that delivers a lightning > fast and secure boot experience on modern computers and embedded > systems. As an Open Source project it provides auditability and > maximum control over technology." > > FSP-I means exactly the opposite of most of the above points. It's > inherently incompatible. > > IMO, unless we discuss if we want to change how we define coreboot > first, there can't be a discussion about integrating FSP-I nor any > action in that direction. > > > Are there precedents where blobs runtimes are installed on the main CPU, > > that I don't know of which could justify FSP-I? > > There's something for the main CPU but definitely not the same: I was > told AMD's binary pi can provide runtime ACPI code. But running ACPI is > an opt-in for the OS, whilst FSP-I wouldn't even allow an opt-out, I > guess. > > > > > P.S. It's quite sad to see this happen after an open letter 361 people > > signed for a more open FSP. > > > https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fsp-59d7a0c6 > > Sad, but not unexpected. I believe this is part of a more than a > decade old strategy. It seems to me Intel never really supported > open-source OS drivers for their server platforms. They just hid > everything in SMM with a nice open-source facade for Linux. We > turned a blind eye to that. Now it seems that the ecosystem around > Intel servers is rather unprepared for open source. Even if they'd > open up their SMM code, it would just be wrong to keep the code in > SMM, IMO. Proper OS drivers should be written instead. > > Nico > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org >
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
