Issue #506 has been reported by Matt DeVillier.
---------------------------------------- Bug #506: Apollolake/Geminilake boards fail to boot OS when CPU microcode included "from tree" https://ticket.coreboot.org/issues/506
* Author: Matt DeVillier * Status: New * Priority: Normal * Target version: none * Start date: 2023-08-30 * Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: all boards using Intel Apollolake/Geminilake SoCs * Affected OS: All ---------------------------------------- Apollolake/Geminilake (APL/GLK) based devices are unique in that they have a special firmware region called IFWI, which contains the coreboot bootbock and CPU microcode, among other things. As part of building an image for an APL/GLK-based device, an existing IFWI binary must be supplied in order to be modified with coreboot's bootblock. The CPU microcode however is not updated, as the region size is fixed, and current tooling (util/cbfstool/ifwitool) does not have the ability to resize it.
When the default coreboot Kconfig option `CPU_MICROCODE_CBFS_DEFAULT_BINS` for CPU microcode is selected, coreboot will include a microcode update in CBFS which is (much) newer than that in the IFWI, and apply it in ramstage. This causes any OS to fail to boot: Linux hangs, and Windows BSODs with an `UNSUPPORTED CPU` error. The only workaround is to include an external CPU microcode binary which matches the one in IFWI (ie, use both the IFWI and microcode extracted from the original vendor firmware image). Not including any microcode update has not been tested, and may also be an option.
There have been a few patches submitted to work around this (CB:65680, CB:64863), but the former requires external, non-public tooling, and the latter fails if the new microcode update is larger than the existing IFWI region.
Possible areas to investigate are adding resizing capability to ifwitool, and constructing an IFWI from scratch (vs copying/modifying the existing one)