coreboot

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

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:

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.