Issue #670 has been updated by Matt DeVillier. File candidate_dp_b_hdmi_c_padded.vbt added File candidate_dp_b_hdmi_c_padded_228.vbt added
Thanks for the detailed report and for validating the EFP1 change. **VBT source** The in-tree `data.vbt` matches one of the 19 (!!) VBTs from Lenovo’s M1UKT79A image (`m1ujy79usa.exe` / `imageM1U.ROM`) byte-for-byte. coreboot only includes one of them — EFP1 as DVI-D on HDMI-B with no AUX — which is the wrong one for your M720q. Another Lenovo SKU in the same image has EFP1 as DisplayPort/HDMI/DVI on DP-B + AUX-B and EFP2 as DVI-D on HDMI-C, which matches your HPD findings. **BDB vs CFL FSP** The Lenovo/in-tree VBTs are BDB 212. The Coffee Lake FSP sample VBT is BDB 228. That gap is not automatically fatal, but these tables are older than what the FSP package ships as a reference. They also keep fixed boot mode 1024x768 and a phantom LFP1 entry, which fits FSP GOP reporting a 1024x768 framebuffer while leaving both outputs black. **Path forward** I'm attaching 2 diff VBTs here: 1) a DP-B + HDMI-C one extracted from the lenovo firmware, with LFP1 and the fixed boot mode removed 2) same as the above, but migrated to the 228 BDB that the CFL FSP likely wants. Please test both and LMK how they work for you with both Linux and FSP GOP on both outputs if possible ---------------------------------------- Bug #670: Lenovo M720q: Incorrect DDI B mapping in VBT prevents DisplayPort detection https://ticket.coreboot.org/issues/670#change-2449 * Author: Johannes Sjölund * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2026-10-27 ---------------------------------------- ## Hardware and software - **System:** Lenovo ThinkCentre M720q Tiny - **CPU:** Intel Core i5-8400T - **GPU:** Intel UHD Graphics 630 (`8086:3e92`) - **Motherboard PCB identifier:** `IQ3X0IL` - **PCB revision:** `1.0` - **Identification method:** Physical inspection of the motherboard silkscreen - **Physical display outputs tested:** DisplayPort and HDMI - **Coreboot:** 26.09 - **Payload:** MrChromebox EDK II - **OS:** Arch Linux, using the `i915` DRM driver - **VBT:** `src/mainboard/lenovo/m720q_m920q/data.vbt` The PCB identifier and revision were confirmed directly from the motherboard rather than SMBIOS, since the original DMI information is no longer available after replacing the Lenovo firmware with Coreboot. ## Problem The VBT included with the M720q/M920q mainboard describes EFP1 (device handle `0x0004`) as a DVI/HDMI output on DDI B. However, on my M720q, the physical DisplayPort connector is connected to DDI B. This was confirmed by monitoring hotplug events in Linux: - Connecting/disconnecting the physical DisplayPort cable triggers HPD events on DDI B. - With the original VBT, `i915` treats DDI B as HDMI, creates an HDMI connector, and attempts DDC/GMBUS communication. - The connected DisplayPort monitor is not detected correctly. ## VBT correction I modified the EFP1 child-device entry in BDB block 2 (General Definitions): | Field | Original | Modified | |---|---|---| | Device handle | `0x0004` (EFP1) | Unchanged | | Device type | `0x60d2` (DVI-D) | `0x68c6` (DisplayPort) | | DVO port | `0x01` (HDMI-B) | `0x07` (DP-B) | | AUX channel | `0x00` | `0x10` (AUX-B) | The VBT checksum was recalculated. The VBT size and all other child-device entries were preserved. The resulting VBT was validated using `intel_vbt_decode`. ## Verification I first tested the modified VBT without reflashing Coreboot, using the Linux `i915.vbt_firmware` module parameter. The modified VBT was loaded successfully and verified against the kernel's `i915_vbt` debugfs data. With this change: - Linux creates `DP-1` on DDI B. - AUX-B communication works and DPCD reads succeed. - DisplayPort link training succeeds. - The monitor is detected and can display an image. I then included the modified `data.vbt` in Coreboot, rebuilt and flashed the BIOS region. ### Results with libgfxinit and corrected VBT - **EDK II over DisplayPort:** Working. - **EDK II over HDMI:** Working. - **Linux over HDMI:** Working without intervention. - **Linux over DisplayPort at 1280×720:** Working without intervention. - **Linux over DisplayPort at 3840×2160:** The initial modeset can result in a black screen. A subsequent KMS modeset to 3840×2160 at 59.94 Hz restores the image. ### Results with FSP GOP and corrected VBT - Linux detects both physical outputs correctly. - Both outputs can display an image after a hotplug event or an additional modeset. - No visible EDK II output was obtained. ## Separate high-resolution modeset issue On a Samsung Odyssey G95NC running in Picture-in-Picture mode, the initial Linux modeset at 3840×2160 may leave the DisplayPort output black. The DRM logs show successful DisplayPort link training followed by a CPU pipe A FIFO underrun. A manual modeset using: ```bash modetest -M i915 -s 111:3840x2160-59.94 ``` restores the image, while the 60 Hz mode tested did not. The monitor advertises multiple 3840×2160 modes with different timing parameters. This may be a separate monitor/EDID/i915 compatibility issue and does not appear necessary to reproduce the VBT port-mapping problem. ## Questions 1. Is the supplied VBT expected to describe all M720q/M920q hardware variants? 2. Could the existing EFP1 configuration be incorrect for the M720q's physical DisplayPort wiring? 3. Would a corrected VBT, a board-specific override, or a documentation update be the preferred solution? I can provide the original and modified VBT decode output, exact byte-level changes, Coreboot configuration, CBMEM logs and Linux DRM debug logs. I have not verified this correction on other M720q/M920q hardware variants. ---Files-------------------------------- M720q.jpg (707 KB) candidate_dp_b_hdmi_c_padded.vbt (4.5 KB) candidate_dp_b_hdmi_c_padded_228.vbt (4.5 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 _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
