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
