Hi Laurie

I created a github issue about this https://github.com/UniversalScalableFirmware/documentation/issues/37 almost 11 months ago with no reply.
I also don't see any discussions about FSP-I in particular in that community but I posted my github issue again on that mailing list.

Arthur

On Fri, Sep 30, 2022 at 6:45 PM Jarlstrom, Laurie <laurie.jarlstrom@intel.com> wrote:

Hi,

I would like to invite you to the Universal Scalable Firmware (USF) Community where Intel® FSP is an ingredient to a full system firmware solution and incorporates multiple bootloaders including coreboot.

There have been discussions on the updates to Intel® FSP within this community

https://universalscalablefirmware.groups.io/g/discussion

 

What is USF?  Links to  USF training videos: https://www.youtube.com/playlist?list=PLehYIRQs6PR5N73cbW8CPvU_stDTAG_j5

 

Thanks,

Laurie

 

Laurie.jarlstrom@intel.com,

System Firmware Products

Firmware Ecosystem & Business Dev.

(503) 880 5648 Mobile

 

From: ron minnich <rminnich@gmail.com>
Sent: Friday, September 30, 2022 9:00 AM
To: Nico Huber <nico.h@gmx.de>
Cc: Arthur Heymans <arthur@aheymans.xyz>; coreboot <coreboot@coreboot.org>
Subject: [coreboot] Re: FSP 2.4: runtime blobs!

 

 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 <nico.h@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-leave@coreboot.org