Project

General

Profile

Actions
Copy link

Bug #620

open

X230(t) does not work since commit 97dbfd3098ae12ef3f51e5f95cd6d66c25214205 was merged

Added by Hustler One 7 days ago. Updated 6 days ago.

Status:
New
Priority:
High
Assignee:
-
Category:
coreboot common code
Target version:
main
Start date:
12/31/2025
Due date:
% Done:

0%

Estimated time:
Affected versions:
main
Needs backport to:
Affected hardware:
x230t
Affected OS:

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.

Related links

https://www.reddit.com/r/coreboot/comments/1pu5vlp/x230t_does_not_get_past_postcar/
https://www.reddit.com/r/coreboot/comments/1pyzcvf/no_video_output_with_updated_coreboot_x230_4132512/

Actions
Copy link
 #1

Updated by Patrick Rudolph 7 days ago

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?

Actions
Copy link
 #2

Updated by Teej Tj 6 days ago

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:

  1. MTRR
  2. splitting of cache fill/clear
  3. possibly the rep stosl using ERSM in Ivy Bridge influenced by the 64-byte stride for the modification loop
Actions
Copy link
 #3

Updated by Patrick Rudolph 6 days ago

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.

Actions
Copy link

Also available in: Atom PDF