Issue #538 has been updated by Nico Huber.
Brian L wrote in #note-13:
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)
Well, these are two things, saying that only SeaBIOS can do it and saying coreboot can do it with the `0106`. When you first reported the latter, you did not tell us what payload you were using. If we knew the config of each of your builds (you can upload them here), we could help you better. But that's ok for now.
Anyway, that the `0166` isn't working anymore is a regression that I could confirm now in the source code. Thanks for helping to catch that. Reverting "42f0396a1028 (device/pci_rom: rework PCI ID remapping in pci_rom_probe)" should fix it, I guess.
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
Is this the working case? Do both card0 and card1 point to the same PCI device? It's not important I guess. Only interesting if you want to figure out what the second card is about.
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, comparevbetool 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
Thanks, well, that gets us closer I guess. If power sequencing is involved, it could be a timing issue (even though I expect an EDID EEPROM to be ready right away). The one `ff` byte might mean that the EEPROM actually was able to reply for this single byte. Btw. did you give the physical connections a look? After all it might also be coincidence, e.g. if something got loose during the docking.
If you want to get libgfxinit working again, a log would really be the next best step.
---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1846
* 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.