Issue #538 has been updated by Brian L.
Nico Huber wrote in #note-11:
coreboot first tries to find an exact match, and if that doesn't work, falls back to "8086,0106" (that's hardcoded in C code for Sandy and Ivy Bridge iGPUs).
Coreboot is not running my option ROM unless I change my VGA_BIOS_ID away from the coreboot default "8086,0166" to a "trick" value of "8086,0106". I am not sure where the confusion is here, but this is not correct behavior. It can easily be tested if you use default coreboot options for x230, using a linuxboot payload, and enabling vga rom run. Coreboot will not run the option rom, you wont get a screen, and you'll get a log saying "Could not find pci8086,0106.rom". And that is because coreboot renames it to "pci8086,0166.rom"
you are in a classic coreboot and SeaBIOS competing to run the VBIOS situation: SeaBIOS always tries to run it. If you run it in coreboot first, it runs twice which often doesn't work even if the first run succeeded. Generally, never use `VGA_ROM_RUN` with a SeaBIOS payload. If this is what you tried, the "8086,0106" would work because then SeaBIOS couldn't find the file anymore and the VBIOS only runs once.
This is not correct, if you've read the above, SeaBios is the only way that the option rom does work. I am not sure what the confusion is here. I've restated multiple times the environments I've tested and what works and doesnt work, and every time I have said SeaBios+vga blob is the only thing that works. (although now I can get vga blob to work with any payload if I trick coreboot to run the blob by changing the VGA_BIOS_ID to 0106 which is incorrect for the x230)
The card0/1 thing might just be the boot framebuffer showing up as `card0`. You can check where it points to:
$ ls -l /sys/class/drm/card0
``` ls -l /sys/class/drm/card0 lrwxrwxrwx 1 root root 0 May 19 13:17 /sys/class/drm/card0 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0 ```
Nothing of this explains the docking issue and why libgfxinit and Linux fail to initialize graphics even though the EDID can be read later (your i2cdump shows that the EDID is perfectly fine). If you want to investigate this further, two ideas: Check if the EDID can still be read with `i2cdump` when the panel is *off*, e.g. with the lid *closed*. Normally, it should work, but your panel might be unusually wired, or something could just have broken physically.
# i2cdump -y 3 0x50 # sleep 10; i2cdump -y 3 0x50 # close lid, open again in 15s, compare
``` vbetool dpms off && sleep 1 && i2cdump -y 3 0x50 && sleep 1 && vbetool dpms on 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 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX c0: XX XX XX XX XX XX XX XX XX XX XX XX ff XX XX XX XXXXXXXXXXXX.XXX d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX ```
---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1844
* 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.