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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
