Issue #670 has been reported by Johannes Sjölund. ---------------------------------------- Bug #670: Lenovo M720q: Incorrect DDI B mapping in VBT prevents DisplayPort detection https://ticket.coreboot.org/issues/670
* 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) -- 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]
