Solved Intel UHD Graphics 630 on FreeBSD 14.0-RELEASE

jambock.84

jambock.84

DISCLAIMER:
Along this thread I cannot know at large if what particularly happened to me could be in fact general, nor could I state that the workaround would be the best practice or the right thing to do in a similar case. Thus, what I'm trying to share here is to be taken as a mere contribution which may or may not work under other circumstances or scenarios and I shall not be held responsible for anything that could go wrong, that is, if you try what I've successfully did, in part or in its entirety, do at your own risk. Thank you.
Click to expand...

Introduction
My starting point is: Installing FreeBSD 14.0-RELEASE on Dell Vostro (GPT+ZFS on SSD). Next I set to get X11 running on it as well so I perform the usual pkg install xorg and add user to the video group. But before launching X for the very first time it's probably undoubtedly reasonable to install the graphical video drivers and firmware for getting the best experience. When the graphics cards is from some NVidia flavor chances are that the processes will be smoother and nearly optimum. Unfortunately, by comparison, for reasons that I believe don't matter to debate, on the Intel side in relation to Unix things seems to be yet in a relatively early stage, although some remarkable (IMHO) progress has been made in the last couple of years. The problem I've got was to make use of an Intel UHD Graphics 630 which is capable of providing a 1920x1080 resolution at 60Hz.

Setup
After struggling for some time browsing documentation and forums on the Internet I've finally come to know that I would need DRM kernel-mode drivers as well as some firmware (or blobs) from the manufacturer. Fortunately, AFAIK, since FreeBSD 13.0-RELEASE things are becoming easier. For instance, on FreeBSD 14.0-RELEASE, looking at the results of pkg search drm and pkg search firmware-intel I can see packages such as:
  • drm-515-kmod
  • drm_info
  • gpu-firmware-intel-kmod-...
I believe that no doubt a system package is more convenient than a manually built artifact from the ports collection, even though this last one could be "more" optimal if all the possibly tricky (IMHO) details for building it goes well. Moving on, I now have to find out which is the codename of my GPU and that's when drm_info seems to be handy for the first time.
# drm_info |grep Device ... Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630]

But then difficulty strikes in again because the firmware files are named after two keywords (the first one related to an Intel codename and the second related to its "functionality") which are hard-to-find and hard-to-select the ones that are required for a particular system. In addition, the "lazy" strategy of installing everything in the hope the right one will be automatically selected and used may lead to hang during the boot phase when kernel modules are loaded if an incompatible module somehow happens to be loaded. So I'm aiming to install just the "presumably" right kernel modules and graphics firmware.

IMHO the "best" point to start getting the essential practical concepts and basic understanding towards selecting what's right for a particular installation is:
  1. Find out if dmesg reveals some load failure about DRM by inspecting the output of dmesg |grep drm |grep load which in my particular case revealed the unforeseen need of the i915/kbl_dmc_ver1_04.bin file.
  2. With the hint from the previous step I could narrow down the search for the missing file(s) within the available gpu-firmware-intel-kmod-... packages by guessing that kbl would be an acronym for KabyLake. Without the hint I would probably not deduce that my CoffeeLake is somehow related to KabyLake! If the hint was of no help unfortunately I would be required to perform the uncomfortable repetitive task of installing-viewing-uninstalling each candidate package out of a total of at most 11 by the time of this writing:
    # pkg search gpu-firmware-intel
    gpu-firmware-intel-kmod-alderlake-20230210_1 Firmware modules for alderlake Intel GPUs
    gpu-firmware-intel-kmod-broxton-20230210_1 Firmware modules for broxton Intel GPUs
    gpu-firmware-intel-kmod-cannonlake-20230210_1 Firmware modules for cannonlake Intel GPUs
    gpu-firmware-intel-kmod-dg1-20230210_1 Firmware modules for dg1 Intel GPUs
    gpu-firmware-intel-kmod-elkhartlake-20230210_1 Firmware modules for elkhartlake Intel GPUs
    gpu-firmware-intel-kmod-geminilake-20230210_1 Firmware modules for geminilake Intel GPUs
    gpu-firmware-intel-kmod-icelake-20230210_1 Firmware modules for icelake Intel GPUs
    gpu-firmware-intel-kmod-kabylake-20230210_1 Firmware modules for kabylake Intel GPUs
    gpu-firmware-intel-kmod-rocketlake-20230210_1 Firmware modules for rocketlake Intel GPUs
    gpu-firmware-intel-kmod-skylake-20230210_1 Firmware modules for skylake Intel GPUs
    gpu-firmware-intel-kmod-tigerlake-20230210_1 Firmware modules for tigerlake Intel GPUs
Thus, my final installation step was performing a pkg install gpu-firmware-intel-kabylake which installed the required file on /boot/modules and solved the issue. :cool:

# dmesg |grep drm​
drmn0: <drmn> on vgapci0​
vgapci0: child drmn0 requested pci_enable_io​
vgapci0: child drmn0 requested pci_enable_io​
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). :-/​
[drm] Got stolen memory base 0xbb800000, size 0x2000000​
lkpi_iic0: <LinuxKPI I2C> on drmn0​
lkpi_iic1: <LinuxKPI I2C> on drmn0​
lkpi_iic2: <LinuxKPI I2C> on drmn0​
lkpi_iic3: <LinuxKPI I2C> on drmn0​
drmn0: [drm] [ENCODER:102:DDI E/PHY E] is disabled/in DSI mode with an ungated DDI clock, gate it :-/​
drmn0: successfully loaded firmware image 'i915/kbl_dmc_ver1_04.bin'​
drmn0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)​
lkpi_iic4: <LinuxKPI I2C> on drm2​
[drm] Initialized i915 1.6.0 20201103 for drmn0 on minor 0​
name=drmn0 flags=0x0 stride=7680 bpp=32​

And without performing any single X11 manual configuration/tweak (so far) I've got the TWM default out-of-the-box config with XTerm displaying crisp text at a 1920x1080@60 resolution and quite good speed for my "graphical console" workings even though my display is capable of achieving 120Hz:

# xrandr​
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384​
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm​
1920x1080 60.00*+120.00 100.00 119.88 119.98 99.93 74.99 50.00 59.94​
1280x1024 119.96 75.02 60.02​
1440x900 119.85​
1152x864 75.00​
1280x720 60.00 50.00 59.94​
1024x768 119.99 75.03 60.00​
800x600 119.97 75.00 60.32​
720x576 50.00​
720x480 60.00 59.94​
640x480 75.00 60.00 59.94​
720x400 70.08​
DP-1 disconnected (normal left inverted right x axis y axis)​

PS
For the correct Intel keywords I would give up searching the Internet and just rely on the diagnostic output from dmesg for getting hints on what is presumably missing/desired. For the "functionality" keywords, considering that the lowercase "u" in GuC and HuC would in fact :eek: represent the Greek letter "µ" for micro, some search on the Internet seems to reasonably indicate that:
  • DMC means Display Micro Controller.
    In this context it provides for low power idle-states.
  • GuC means Graphics Micro Controller.
    In this context it provides for workload scheduling and parallel engines.
  • HuC means HEVC/H.265 Micro Controller.
    In this context it provides CPU offloading (hardware acceleration) for media functions.
Finally, I've got to know that there's an URL for downloading such firmware (BLOBs) but unfortunately they are not directly usable on FreeBSD, that is, one cannot simply download and put them on /boot/modules after all they are not loadable kernel modules but just ordinary BLOBs (I once have seen a FreeBSD diagnostic message saying "go get it" but that's crazy ? as it won't work as-is).
 
I've checked if by placing tmpfs_load="YES" in loader.conf would make the following diagnostic message go away, but it didn't.
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). :-/
Click to expand...

In fact, I've added tmpfs to my /etc/rc.conf kld_list but I've got to know it was already loaded or integrated into the kernel, so then I've noticed that it may not be just about tmpfs being there, but about a private mount ? of a tmpfs.

On the Internet I've found the following WRT Linux kernels 2.6.15 and above:
The shared subtrees operations.
Since Linux 2.6.15 it is possible to mark a mount and its submounts as shared, private, slave or unbindable.
A shared mount provides ability to create mirrors of that mount such that mounts and umounts within any of the mirrors propagate to the other mirror.
A slave mount receives propagation from its master, but any not vice-versa.
A private mount carries no propagation abilities.
A unbindable mount is a private mount which cannot cloned through a bind operation.
...
mount --make-shared mountpoint
mount --make-slave mountpoint
mount --make-private mountpoint
mount --make-unbindable mountpoint
Click to expand...

Thus, the issue seems to be related to mount() and not tmpfs() after all and it seems FreeBSD has no such or equivalent feature.

Perhaps the diagnostic message could have been suppressed while porting the implementation or at least the "hugepage support" should not be prevented by this "namespace feature" if the FreeBSD "hugepages support" implementation were "compatible".

From a quick reading the missing feature seems to be about "isolation of mountings through namespaces" and it's not yet clear to me the practical benefits it provides.
 
Last edited:
I'd say that following diagnostic message is at a minimum obscure as is IMO it lacks a good punctuation.
For instance, I have no idea of what is being affected and the overall severity; the presence of "/" could lead to different interpretations and course of actions:
drmn0: [drm] [ENCODER:102:DDI E/PHY E] is disabled/in DSI mode with an ungated DDI clock, gate it :-/
Click to expand...
  • Is something (?) disabled that should be enabled?
  • Am I in DSI mode with an ungated DDI clock?
  • Must I unconditionally "gate" it at all times?
  • What would be the impacts or trade-offs?
The way it's currently stated, it seems a dead-end. ?
 
Last edited:
Hi Jambock.84!

I'm using a FreeBSD 15-current.

I have a Lenovo IdeaPad With Coffee Lake with Intel UHD Graphics 630. But My system has dual GPU (intel and NVIDIA).
I can't use HDMI output.
I can set up Internal Display using intel graphics or External (HDMI) with NVIDIA.
My system missing the same file (firmware), but when I install this, It not really install on correct place.
Do you know where the correct place to put this?

sh: 
# pciconf -lBV | grep vga
vgapci1@pci0:0:2:0:     class=0x030000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x3e9b subvendor=0x17aa subdevice=0x3a2e
vgapci0@pci0:1:0:0:     class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1f91 subvendor=0x17aa subdevice=0x3a2e

# find / -name "kbl_dmc*" -type f
/usr/ports/graphics/gpu-firmware-intel-kmod/work-skylake/drm-kmod-firmware-20230625_4/i915kmsfw-files/kbl_dmc_ver1_04.bin

My question is:
Is possible to use HDMI output using only intel?

sh: 
Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: LENOVO
        Product Name: 81TR
        Version: LENOVO IDEAPAD L340 15IRH
        Serial Number: 
        UUID: f8bc804f-a8b4-5d56-80c9-
        Wake-up Type: Power Switch
        SKU Number: LENOVO_MT_81TR_BU_idea_FM_IDEAPAD L340-15IRH
        Family: IDEAPAD L340-15IRH

TIA,
Nilton Jose Rizzo
 
Nilton Jose Rizzo said:
Is possible to use HDMI output using only intel?
Click to expand...
I have Intel UHD 630 ( drm-kmod as-is), and on FreeBSD 14.1 HDMI audio seems to work fine:

mixer -a
Code: 
pcm0:mixer: <Realtek ALC256 (Analog 2.0+HP)> on hdaa0 (play) (default)
    vol       = 0.80:0.80     pbk
    pcm       = 1.00:1.00     pbk
    ogain     = 1.00:1.00     pbk
pcm1:mixer: <Intel Kaby Lake (HDMI/DP 8ch)> on hdaa1 (play)
    vol       = 0.85:0.85     pbk
    pcm       = 1.00:1.00     pbk

mixer -d 1
Code: 
default_unit: 0 -> 1
pcm1:mixer: <Intel Kaby Lake (HDMI/DP 8ch)> on hdaa1 (play) (default)
    vol       = 0.85:0.85     pbk
    pcm       = 1.00:1.00     pbk

With 3.5mm headphones connected to my HDMI screen, audio plays.

There's a note about IOMMU potentially preventing HDMI on Haswell on Linux; I have CPU virt disabled on FreeBSD currently.

It also sounds like your HDMI port is hard-wired to the NVIDIA GPU (usually the case if the computer advertised G-SYNC or VR-ready), and you'll likely need to mess with NVIDIA-related drivers for that.
 
jambock.84 said:
I'd say that following diagnostic message is at a minimum obscure as is IMO it lacks a good punctuation.
For instance, I have no idea of what is being affected and the overall severity; the presence of "/" could lead to different interpretations and course of actions:

  • Is something (?) disabled that should be enabled?
  • Am I in DSI mode with an ungated DDI clock?
  • Must I unconditionally "gate" it at all times?
  • What would be the impacts or trade-offs?
The way it's currently stated, it seems a dead-end. ?
Click to expand...

I've seen that on Linux for months (if not a year) but never saw a situation where it was a problem, nor would I know where to begin messing with that :p (it sounds like a burned-in firmware ordeal from Dell/motherboard/display IC; didn't see any obvious sysctl to alter it)

It sounds like ENCODER:102:DDI is pointing to a specific port/display. It also sounds like this is specific to the i915 driver developed for Linux and would be ideal to have fixed upstream: https://gitlab.freedesktop.org/drm/i915/kernel
 
You must log in or register to reply here.
Back
Top