coreboot

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.

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.

To be clear, the display certainly is powered once the OS kernel starts. I get a gui on the screen, but its detected as 1024x768 instead of 1024x600, so application windows go off the bottom of the screen. There is no EDID and the model is "Unknown" instead of "Pixel Qi" from swaymsg get_outputs. This all gets fixed by flashing stock bios and retriggers flashing any coreboot flavor, all without involving the dock, even though it was triggered by the dock originally. I would expect even if coreboot somehow causes the display to be unpowered, it should still be hotpluggable in linux to detect it properly correct? Or maybe I can manually trigger a rescan to debug? I'm not sure how though

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

Since it works when using the VBIOS the hardware isn't broken and it's likely a software bug or miss-configuration.
Maybe a regression in libgfxinit or coreboot? No VBT included? Wrong VBT included?
UEFI firmware patches the VBT, while coreboot does not. Maybe a wrong version was checked in causing this issue?
The only difference from OS point of view might be the VBT being used when running on VBIOS (it's part of the VBIOS).

Probably related issue: https://ticket.coreboot.org/issues/278

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.

You know, taking a step back and looking at this, I am not even sure the payload or the OS even needs to be involved in the discussion because: shouldn't coreboot alone be able to show a bootsplash image? If I enable that, and it isn't happening anymore like it used to, that would indicate the issue is at that point in the bootchain.

I do think it is interesting that vga blob (+ seabios maybe also required) are able to overcome this, but the fault is definitely lying at the start of the coreboot process right?

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

I am not sure what all of the output means, but I can tell you the "PQ3Qi-01" is correct

A longshot, but Section 6.1.8 of this can't explain anything, can it?

And another thing that I don't know if it is useful: when im booted using a working configuration, /sys/devices/pci0000:00/0000:00:02.0/drm/card1 is the device that gets populated, and i can read the edid under there... when im booted using a nonworking configuration /sys/devices/pci0000:00/0000:00:02.0/drm/card0 is the device that gets populated and as mentioned earlier, the edid is blank

Brian L wrote in #note-8:

You know, taking a step back and looking at this, I am not even sure the payload or the OS even needs to be involved in the discussion because: shouldn't coreboot alone be able to show a bootsplash image? If I enable that, and it isn't happening anymore like it used to, that would indicate the issue is at that point in the bootchain.

I do think it is interesting that vga blob (+ seabios maybe also required) are able to overcome this, but the fault is definitely lying at the start of the coreboot process right?

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??

so i guess the issue had something to do with the card0 vs card1 thing and the 0106 vs 0166 thing... I have no idea what that stuff means or why Im the only person with an x230/lenovo laptop who has ever seemed to have the laptop "switch" between those 2 cards permanently because of using a dock, but thats what it was i guess

and just to make it more confusing when it was finally seeming to be clear, i noticed that the vgabios.rom that has been used for years for the x230 by coreboot and its derivatives.... when you run file on it, you get:

vgabios.bin: BIOS (ia32) ROM Ext. IBM comp. Video "IBM VGA Compatible BIOS. \003n" (128*512) jmp 0xea78; at 0x40 PCI Intel device=0x0106 PRIOR, ProgIF=3, at 0x1c VPD, revision 3, code revision 0x3, last ROM, 3rd reserved 0x8000

showing that it has always been device=0x0106, so i don't know why this is just an issue now

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.

One very important thing: Do you remember the exact coreboot version / config that you used when it broke?

Many of my ealier thoughts were based on the assumption that it was stock HEADS and that libgfxinit worked before with your panel. But maybe it didn't?

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

Nico Huber wrote in #note-12:

One very important thing: Do you remember the exact coreboot version / config that you used when it broke?

Many of my ealier thoughts were based on the assumption that it was stock HEADS and that libgfxinit worked before with your panel. But maybe it didn't?

Libfgxinit worked fine for years with multiple flavors and payloads. It was only after using a dock that it suddenly broke. I dont recall the exact coreboot revision that i used when it broke, unfortunately, but it was Heads with a stock Head's coreboot config. (only customizations were unrelated to graphics, and it was in the payload linuxboot side of the configuration)

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.

Brian L wrote in #note-16:

If you want to get libgfxinit working again, a log would really be the next best step.

See attached full ADA debug log, thanks

Thanks. Not what I expected. Gave me some ideas, though, even if it feels a bit desparate: There's a timeout waiting for the GMBUS (I2C) controller when trying to read an EDID over the DP connector. Not directly a problem, but this controller is known to sometimes act rather erratic, and maybe, maybe it causes problems even for other connectors probed later.

[0.053716] HW.GFX.GMA.Registers.Wait:  0x00000800 <- 0x00000800 & 0x000c5108:PCH_GMBUS2
[0.553718] HW.GFX.GMA.Registers.Wait: Timed Out!

This happens after we request power to the panel and delays for incredibly long 500ms. That makes a timing issue unlikely. Two things I'd try:

1. Place the LVDS first in src/mainboard/lenovo/x230/variants/x230/gma-mainboard.ads (if that helps, try the old order with HDMI1 removed).

2. Add another desparate delay to the Wait_On() procedure nevertheless:

   diff --git a/common/hw-gfx-gma-panel.adb b/common/hw-gfx-gma-panel.adb
   index 532bf674b41d..c546b81dc820 100644
   --- a/common/hw-gfx-gma-panel.adb
   +++ b/common/hw-gfx-gma-panel.adb
   @@ -384,6 +384,8 @@ is
         TOut_MS  => 300);
   
      Registers.Unset_Mask (PP (Panel).CONTROL, PCH_PP_CONTROL_VDD_OVERRIDE);
   +
   +      Time.M_Delay (500);
   end Wait_On;
   
   procedure Off (Panel : Panel_Control)
   

Nico Huber wrote in #note-17:

Brian L wrote in #note-16:

If you want to get libgfxinit working again, a log would really be the next best step.

See attached full ADA debug log, thanks

Thanks. Not what I expected. Gave me some ideas, though, even if it feels a bit desparate: There's a timeout waiting for the GMBUS (I2C) controller when trying to read an EDID over the DP connector. Not directly a problem, but this controller is known to sometimes act rather erratic, and maybe, maybe it causes problems even for other connectors probed later.

[0.053716] HW.GFX.GMA.Registers.Wait:  0x00000800 <- 0x00000800 & 0x000c5108:PCH_GMBUS2
[0.553718] HW.GFX.GMA.Registers.Wait: Timed Out!

This happens after we request power to the panel and delays for incredibly long 500ms. That makes a timing issue unlikely. Two things I'd try:

1. Place the LVDS first in src/mainboard/lenovo/x230/variants/x230/gma-mainboard.ads (if that helps, try the old order with HDMI1 removed).

2. Add another desparate delay to the Wait_On() procedure nevertheless:

   diff --git a/common/hw-gfx-gma-panel.adb b/common/hw-gfx-gma-panel.adb
   index 532bf674b41d..c546b81dc820 100644
   --- a/common/hw-gfx-gma-panel.adb
   +++ b/common/hw-gfx-gma-panel.adb
   @@ -384,6 +384,8 @@ is
         TOut_MS  => 300);
   
      Registers.Unset_Mask (PP (Panel).CONTROL, PCH_PP_CONTROL_VDD_OVERRIDE);
   +
   +      Time.M_Delay (500);
   end Wait_On;
   
   procedure Off (Panel : Panel_Control)
   

Attempting to investigate hardware issue -- removing the bezel of my display assembly was enough to cause the screen to go completely offline. At this time I am investigating hardware failure as the most likely root cause. Providing this update so no one wastes time on this until I have a chance to rule that out or not