Project

General

Profile

Actions

Bug #647

open
CS

ec/lenovo/h8: ThinkLight is always-on with specific `backlight` CMOS options on ThinkPad X230

Bug #647: ec/lenovo/h8: ThinkLight is always-on with specific `backlight` CMOS options on ThinkPad X230

Added by Christian Schrötter about 24 hours ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
Start date:
05/25/2026
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Lenovo ThinkPad X230
Affected OS:

Description

The ThinkPad X230 supports the following values for the option "Keyboard Illumination Device" (Config » Keyboard/Mouse) in the stock BIOS. These states are represented in EC RAM register 0x01 via bits 2-3:

  • Both: 0x00
  • Keyboard Backlight Only: 0x04 (bit 2 set)
  • ThinkLight Only : 0x08 (bit 3 set)

coreboot implements this setting via the backlight CMOS option. Additionally, there's a 4th (undocumented?) value in coreboot, which is apparently supported by some ThinkPads:

  • None : 0x0c (bit 2 and 3 set)

I've successfully tested backlight=Keyboard and backlight=None on a T440p with coreboot, without any issues.

Bug description

However, X230's behaviour under coreboot is broken for specific settings:

  • backlight=Both and backlight=Thinklight only: Works as expected.
  • backlight=None or backlight=Keyboard only: ThinkLight is always-on!

In this "always-on" state, there's no way to turn off ThinkLight. Even pressing Fn+Space is completely ignored by the EC.

Debugging Attempts & Observations

  • I suspected a race condition during EC initialization and tried to forcefully disable the ThinkLight during h8_enable() before config1 gets written.
  • It appears that setting bit 2 in 0x01 doesn't just disable the feature, but rather locks out the EC entirely from controlling the physical GPIO pin, leaving it floating/high.
  • The catch (timing): There is one exception! The ThinkLight correctly switches off during the very first cold boot right after flashing the BIOS region; when the MRC cache is invalid. The lengthy RAM training delay somehow prevents the issue. This strongly points towards a timing or race condition issue during the EC's own initialization phase versus coreboot sending the commands.

Currently, I'm out of ideas on how to properly debug or fix this EC quirk. Any hints from a coreboot veteran would be highly appreciated. :-)

No data to display

Actions

Also available in: PDF Atom