Issue #538 has been updated by Patrick Rudolph. Looking at the schematics there's no way the LVDS can be disconnected. However it might be possible that the display isn't powered, though it's unclear why coreboot would cause this effect. ---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1828 * 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

Issue #538 has been updated by Brian L. Patrick Rudolph wrote in #note-1:

Looking at the schematics there's no way the LVDS can be disconnected. However it might be possible that the display isn't powered, though it's unclear why coreboot would cause this effect.

Circling back to this, the issue is fixed when using the vendor blob for video bios. So i guess this is a libgfxinit issue then? I've tested Skulls prebuilt images with no vendor blob and have the issue on 1.0.8 and 1.1.0. I am not sure if this ever worked properly for libgfxinit or not. Googling shows many users using x230 on dock and not reporting issues, so its unclear if it worked at some point, or if they were all using video blobs, or if me having a non-standard screen panel made the issue more easily debugable (maybe stock panels fallback to proper resolution where as my panel had a clearly different one, as noted in my post above). ---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1833 * 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

Issue #538 has been updated by Patrick Rudolph. Probably related issue: https://ticket.coreboot.org/issues/278 ---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1836 * 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

Issue #538 has been updated by Brian L. Nico Huber wrote in #note-6:

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/ ```

Thanks Patrick and Nico. Please let me provide the additional information. - No UEFI is used on this system. It has always been some coreboot flavor (seabios or linuxboot) booting into grub or kexec'ing linux, respectively. - I have already verified that going back to vendor bios allows the screen to work at boot and the EDID to be visible in linux, then returning to coreboot libgfxinit the screen will stop working at boot and no EDID is available - There is no misconfiguration on my end, the problem appeared without making any changes to my bios, it occured after using a thinkpad dock for the first time and it has never behaved properly since, despite not using the dock anymore and having done dozens of full 12mb flashes since then - The data.vbt i've been using is the one provided by skulls and heads, respectively and it has the same checksum. - Whether I boot with vga blob (working) or with libgfxinit (not working), cbmem log shows `GMA: Found valid VBT in CBFS` The following coreboot flavors are properly **working** AFAICT: - Skulls 1.08 - (VGA Blob + SeaBios) - Based on Coreboot commit aa1efece74 - Skulls 1.10 - (VGA Blob + SeaBios) - Based on Coreboot commit 04d6eb1eae The following coreboot flavors are **not working**: - Skulls 1.08 - (libgfxinit + SeaBios) - Based on Coreboot commit aa1efece74 - Skulls 1.10 - (libgfxinit + SeaBios) - Based on Coreboot commit 04d6eb1eae **Another** potentially helpful clue, **however** I am a bit cautious it may be a red herring: Heads (coreboot w/ Linuxboot payload) does **not** work using VGA blob. I say this is a red herring because I don't know if it is actually supposed to work. Heads uses libgfxinit by default, and I see no one discussing using VGA blobs instead. However there are some (T530/W530, I think) supported laptops with dGPUs which do have configs using VGA blobs, so I would assume that x230 built-in graphics vga blob would also work, as long as the correct menuconfig changes were made (which I'm 99% confident I did, as I've done it for vanilla coreboot plenty of times and I have a pretty good understanding of how everything works, but of course I am human and also not any type of coreboot expert, so there is a small chance it is misconfig). I really don't think I can voluntarily go back to vendor bios again to debug, as I am starting to be afraid of the health of the eeprom pins and the smd components near them, and so I'd prefer to only have to external flash in emergency situations. Is there a config change i can make to the VBT to test? I do have the program that the "x230 Full HD Mod" users were using and I am somewhat familiar with using it to make changes. - ---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1838 * 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

Issue #538 has been updated by Brian L. Nico Huber wrote in #note-6:

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 ... ```

As mentioned before, there are no issues getting edid once vendor bios is flashed, so I didn't provide the above info to you. However, I am not sure if this is interesting. The following output is from a booted session where internal panel was not working correctly: ``` [root@x230 card0-LVDS-1]# pwd /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1 [root@x230 card0-LVDS-1]# ls connector_id device edid firmware_node power subsystem waiting_for_supplier ddc dpms enabled modes status uevent [root@x230 card0-LVDS-1]# cat edid [root@x230 card0-LVDS-1]# i2cdump -y 3 0x50 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: 00 ff ff ff ff ff ff 00 42 29 08 10 00 00 00 00 ........B)??.... 10: 29 13 01 03 80 16 0c 78 0a a3 95 8c 57 53 8c 28 )??????x????WS?( 20: 29 50 57 00 00 00 01 01 01 01 01 01 01 01 01 01 )PW...?????????? 30: 01 01 01 01 01 01 2d 11 00 a0 40 58 13 20 30 20 ??????-?.?@X? 0 40: 3a 00 de 7d 00 00 00 18 74 0b 00 a0 40 58 13 20 :.?}...?t?.?@X? 50: 30 20 3a 00 de 7d 00 00 00 18 97 08 00 a0 40 58 0 :.?}...???.?@X 60: 13 20 30 20 3a 00 de 7d 00 00 00 18 00 00 00 fe ? 0 :.?}...?...? 70: 00 50 51 33 51 69 2d 30 31 0a 20 20 20 20 00 e5 .PQ3Qi-01? .? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff 54 31 31 32 33 30 34 31 4e 53 31 30 ff ff ..T1123041NS10.. c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ ``` ---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1840 * 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

Issue #538 has been updated by Nico Huber. Brian L wrote in #note-10:

Yup, so I'm like 99% sure now. Coreboot does not initialize my internal display whether using libgfxinit or vga blob. However, if SeaBios runs the vgablob, then it does work

Sooooo... i just found out that if I change the VGA_BIOS_ID from "8086,0166" (the default that coreboot uses for pretty much all lenovo laptops for years now and has always worked fine for me) to "8086,0106"... coreboot properly loads the option rom, i get a bios screen, and i get an edid now!!!! what the heck??

There are plenty of things that can go wrong with configurations with VBIOS blobs. The `VGA_BIOS_ID` thing is just one of them. `VGA_BIOS_ID` decides how the VBIOS file in CBFS is called. This is important when coreboot/SeaBIOS try to find a matching file for the hardware ID that is encountered at runtime. Because the VBIOS blob supports multiple IDs, 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). SeaBIOS has its own mapping mechanism but that's barely ever configured, so people tend to enter the exact ID for `VGA_BIOS_ID`. It's hard to tell without seeing the whole `.config`, but assuming you haven't also switched the payload, 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. 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 ``` 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 ``` The other thing would be to check where exactly libgfxinit fails. You can build with `CONFIG_DEBUG_ADA_CODE=y` to get traces of it, then `cbmem -c` should give a lot more information. ---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1842 * 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

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, 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 ```

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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

Issue #538 has been updated by Brian L. Priority changed from High to Normal Libgfxinit issue has been resolved. It was caused by a damaged LVDS cable, which was most likely jostled loose by the violent eject button mechanism on the Lenovo dock. Very interesting symptoms it ended up producing! VGA bios blob issue identified regression caused by commit 42f0396a1028. This issue can be closed (I don't seem to have the option to mark as closed). Thanks for your help! ---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538#change-1850 * Author: Brian L * Status: New * Priority: Normal * 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. ---Files-------------------------------- cbmem.log (62.6 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account