Hi folks, During last review meeting Matt and I started talking about "re-factoring" CFR to reduce burden on maintainers and bring coreboot closer to proprietary solutions (i.e AMI).
Currently CFR is done on board-level, which depends on board maintainers to implement it. This requires additional work, many of us simply don't want to spend additional time on it. I would like to suggest implementing tree-wide CFR in following stages: 1. Starting with hooks to FSP pointers on x86_64 platforms (Skylake+ in Intel's case, Zen+ in AMD's case) as that's the simplest to implement as a POC. 2. Adding CFR in general for older pre-FSP platforms (Sandy Bridge, Haswell etc.), as well as modern AMD x86_64 platforms using OpenSIL. 3. Adding CFR to Embedded Controllers and other devices that end-users might want to configure (privacy switches like camera GPIOs/DMICs, keyboard backlight on boot etc). 4. Extending CFR support to non-x86 platforms. I only worked on x86, x86_64, ARMv6, ARMv7 and ARM64 during my career so far (at least on the low-level, I did work with POWER7 and POWER8 and AIX on system-level during my time at IBM), so this would require cooperation from maintainers familiar with other architectures such as RISC-V or POWER). 5. Figuring out how we can safely modify configuration values from Linux (possibly writing a driver and talking to sysfs?) and write an utility to make configuration payload-independent (not sure if it's a good idea in the first place though). Long story short, idea is to have SoC-specific configuration options gated with something like "HAVE_PANTHERLAKE_CFR", which can either be selected in nconfig at build time or included by default if such option would be added to mainboard's Kconfig. Board maintainers could then extend CFR options with their own additional options or change default behavior by writing a cfr.c like they can currently. I'm also currently working on "safeguard" which would be needed for exposing options such as enabling XMP or overclocking. From talking to people at conferences like CCC or FOSDEM I see an interest in coreboot, but many people opt to not install it (even if their board is supported) because they would lose performance benefits. XMP itself works perfectly fine if configured manually. I have two systems with coreboot (one DDR4-3200, one DDR5-5600) with XMP enabled by passing SpdProfileSelected pointer to FSP-M in romstage. However, if memory training would fail for any reason I would be stuck with unbootable system (until I would connect the flasher and overwrite SMMSTORE). That's why another part of this suggestion is to add a boot counter that checks if system had reached the payload stage and wipe CFR options (set by user) if it failed to do so three times in a row. Please let me know what you think, - Alicja _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
