Project

General

Profile

Actions

Bug #506

open

Apollolake/Geminilake boards fail to boot OS when CPU microcode included "from tree"

Added by Matt DeVillier about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
08/30/2023
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
all boards using Intel Apollolake/Geminilake SoCs
Affected OS:
All

Description

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)

No data to display

Actions

Also available in: Atom PDF