Issue #538 has been updated by Nico Huber.
Patrick Rudolph wrote in #note-4:
UEFI firmware patches the VBT, while coreboot does not. Maybe a wrong version was checked in causing this issue?
This could indeed be part of the problem: ``` $ intel_vbt_decode --file=src/mainboard/lenovo/x230/variants/x230/data.vbt | grep -1 LFP\ 1 Child device info: Device handle: 0x0008 (LFP 1 (eDP)) Device type: 0x1022 (LFP) $ intel_vbt_decode --file=src/mainboard/lenovo/x230/variants/x230/data.vbt | grep -A16 LVDS\ panel BDB block 42 (1264 bytes) - LVDS panel data block: Panel 2 * 1024x768 clock 65000000 info: LVDS: 0x00000300 PP_ON_DELAYS: 0x009609c4 PP_OFF_DELAYS: 0x012c07d0 PP_DIVISOR: 0x00270f06 PFIT: 0x00414000 timings: 1024 1048 1184 1344 768 771 777 806 65000.00 (good) PnP ID: Mfg name: MS_ (0x7f36) Product code: 3 Serial: 3 Mfg week: 0 Mfg year: 2002 Panel name: LFP_PanelName ``` It says the panel is connected over eDP. This might make it harder for Linux to find the EDID. And there's a 1024x768 set. Overall this VBT looks more like Intel's template than what Lenovo intended.
It can't explain the whole problem, though, because nobody with the stock panel seems to have this issue and the VBT file has been around for 6 years already.
A good step to gather more information may be to return to the vendor BIOS and confirm that Linux can directly read the EDID from hardware (if you haven't yet), and to fetch the active VBT. For the former I would use `i2cdump`, e.g.: ``` $ # to find the i2c bus number $ grep panel /sys/class/i2c-adapter/i2c-?/name /sys/class/i2c-adapter/i2c-2/name:i915 gmbus panel $ # so on my system it's i2c-*2* $ sudo modprobe i2c-dev $ sudo i2cdump -y 2 0x50 # 2 is the bus, 0x50 the EDID address No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX ... ``` The VBT can be fetched from `debugfs`: ``` $ # optionally, might have to mount debugfs if it isn't already: $ sudo mount -t debugfs debugfs /sys/kernel/debug $ sudo cp /sys/kernel/debug/dri/0/i915_vbt /somewhere/safe/ ```
---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1837
* Author: Brian L * Status: New * Priority: High * Target version: none * Start date: 2024-05-14 * Affected hardware: Lenovo x230 ---------------------------------------- Environment: - Lenovo x230 - Stock screen replaced with Pixel Qi (not sure if relevant) (plug & play LVDS) - Coreboot using Heads (coreboot + linuxboot) - Official lenovo docking station connected to external monitor via DisplayPort
Bug Trigger: Using Heads/coreboot fine for years with my Pixel Qi screen modded x230. I then bought a Lenovo docking station. Booted up, everything worked fine. Disconnected from dock, booted up, and there was no bios screen. Screen did not turn on until taken over by Linux Kernel. Once in userspace, wayland could no longer identify the monitor as a Pixel Qi or its proper resolution. EDID is blank. Booting with docking station allows bios to show on external display.
Restarting did *not* fix the issue, reflashing heads did *not* fix the issue, flashing skulls (coreboot + seabios) did *not* fix the issue.
Flashing stock bios *did fix* the issue. I can now see BIOS screen and get proper EDID in userspace whether on the dock or not. *However* reflashing coreboot again, even coming from stock bios working state, and I immediately now no longer get a BIOS screen or EDID, even without ever introducing the dock again. Essentially now bricked with anything but stock bios.