Bug #620
open
X230(t) does not work since commit 97dbfd3098ae12ef3f51e5f95cd6d66c25214205 was merged
Added by Hustler One 8 days ago.
Updated 7 days ago.
Category:
coreboot common code
Description
Releases 25.09, 25.12 are affected. 25.06 works.
The commit 97dbfd3098ae12ef3f51e5f95cd6d66c25214205 prevents the x230t from going past the postcar stage, hence it being inoperable since it won't load into the main payload.
I have attempted to debug using flashconsole but the trail runs cold after postcar.
Credit to iam_tj for finding the commit.
Also, Libreboot is somehow unaffected by this. I don't know if lbmk undoes this commit or not at this time.
The referenced commit seems to work fine on google/link (IVB) and lenovo/X220 (SNB).
Any ideas why there's a different behaviour?
Are microcode updates properly loaded?
Does it work with unstripped Intel ME?
Tj here (identified the problem commit). I've been working with hustlerone in #coreboot:matrix.org for a few days on this and other issues.
Rudolf: your comment in commit 97dbfd309 "TODO: Test on platforms that have FSRM (Ivy Bridge and newer)." cued me in as this possibly being the cause of the Lenovo X230 regression.
I'm currently writing a patch for hustlerone to figure out the cause that conditionally reverts parts of the commit. The most obvious changes are:
- MTRR
- splitting of cache fill/clear
- possibly the rep stosl using ERSM in Ivy Bridge influenced by the 64-byte stride for the modification loop
The original X230 firmware uses the same assembly code as introduced by 97dbfd3098ae12ef3f51e5f95cd6d66c25214205.
It's possible that it uncovered a different issue, since it now boots much faster. With cleaned ME it also skips some
spots where it would usually slow down the boot.
Figuring out where it actually hangs might shed some light on the real problem.
Also available in: Atom
PDF