Verdin imx8m Plus WB 2GB etnaviv failed to start

Hello,

I failed running gpu part of etnaviv graphics driver on our (dahlia based) custom board running with the WB variant with 2 GB.
The same board used together with the non-WB 4 GB Variant starts that graphics driver without any problems.

I’ve even tried the original dahlia device tree, with the same results:

etnaviv is loaded and creates /dev/dri/card0 + /dev/dri/card1 where card1 is the connection our display is attached to.
Framebuffer is working nicely, we get weston running with software rendering.
But /dev/dri/renderD128 does not come up.

Bootlog contain some entries we do not see when boot the non-wifi modul:

Repeated many times
[ 5.174012] imx-pgc imx-pgc-domain.4: failed to command PGC

And finally
[ 18.409973] platform 38500000.npu: deferred probe pending: (reason unknown)


dmesg.log (41.2 KB)


# tdx-info   

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.12.35-0 #1 SMP PREEMPT Fri Jun 27 10:11:46 UTC 2025
Kernel command line:      root=/dev/mmcblk2p1 console=ttymxc2 console=tty1  rauc.slot=A
Distro name:              NAME="ARIS distro for ticket vending machines"
Distro version:           VERSION_ID=5.0.6
Distro variant:           -
Hostname:                 DEMO-630
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on demo_base
Toradex version:          0064 V1.1A
Serial number:            15675216
Processor arch:           aarch64
------------------------------------------------------------

let me know if i should provide you with more Information.

Any help is appreciated, thanks in advance

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


Hello,

Thank you for your detailed description and log snippet. I understand you’re experiencing issues with the etnaviv graphics driver on your Verdin iMX8M Plus WB (Wi-Fi/Bluetooth) 2GB variant, where /dev/dri/renderD128 does not appear, although framebuffer and basic Weston with software rendering does work. Meanwhile, the non-WB 4GB variant works as expected.

Let’s go through a checklist and some troubleshooting steps:


1. Hardware Differences (WB vs. non-WB)

The WB variant primarily differs by the addition of the Wi-Fi/Bluetooth module (AW-CM276NF) (Verdin iMX8M Plus module variants). Typically, the base GPU/NPU resources should be available on both, but sometimes pin multiplexing or shared resources or power domain init can introduce subtle changes.


2. PGC Power Domain Failures

The repeated log:

[    5.174012] imx-pgc imx-pgc-domain.4: failed to command PGC

suggests a problem with the power gating controller (PGC) for a particular domain, possibly the GPU or a related subsystem.


3. Device Tree Consistency

You’ve tried with the original Dahlia device tree, which is good. Please ensure you are using the Device Tree Binary (.dtb) matching specifically your WB SOM variant. Sometimes, differences in pinmux or power domains for the WB variant may require a .dtb generated by specifying the correct part number.


4. Kernel/DTS Configuration

Ensure the GPU node is not disabled in your device tree and that it correctly matches your SOM variant. Look for status = "okay"; under the GPU nodes.


5. Firmware and U-Boot

The NPU probe defer (platform 38500000.npu: deferred probe pending) might be unrelated, but check that you’re using the reference firmware/U-Boot built for your WB module. Rare differences in non-volatile configuration or device tree overlays are possible.


6. Memory Differences

You have 2GB on the WB, 4GB on the non-WB variant. While this shouldn’t directly affect GPU/etnaviv initialization, some deeper issues could arise if reserved memory in the device tree is tuned for a 4GB SOM and then used with a 2GB module. Make sure any reserved memory regions (such as cma, gpu_reserved, or similar) in your .dts don’t exceed what is actually available.


7. Driver Probes and Kernel Logs

Check for etnaviv (or drm) specific errors earlier in your dmesg (search for “etnaviv”, “gpu”, “drm”, etc.). Sometimes the actual error message is earlier than the first failing log you posted.


8. Reference Images

If possible, try using a Toradex Reference Multimedia Image temporarily to check if the GPU brings up /dev/dri/renderD128 using the default Yocto/Torizon images. This can help determine if the issue is device tree, driver, or distribution specific.


9. Software Version

You mention a custom distro based on kernel 6.12.35-0. Toradex typically uses LTS kernel mainline backports and verified branches. Consider trying with the recommended kernel versions to rule out any kernel driver regression or compatibility issue.


10. Display Connection

Since /dev/dri/card1 is created and your display works, the display controller is likely OK. The absence of /dev/dri/renderD128 strongly suggests the GPU node did not finish initialization.


Suggested Initial Actions

  • Double-check .dtb and overlays: make sure they match WB + Dahlia + your panel configuration.
  • Search dmesg for “gpu”, “etnaviv”, “drm”, and post those lines here.
  • If you have a serial console, enable maximum kernel debug for the etnaviv driver to get additional logs about why initialization failed.
  • Compare the reserved memory regions in the device tree between both SOM variants.
  • Try the reference images from Toradex as a baseline test if possible.

If you can post the output of:

grep -iE "etnaviv|galcore|gpu|drm" dmesg.log

and/or your device tree GPU section, I can assist you further.

Let me know if you need step-by-step help with any of the above or have more logs to share!

Best regards,
Toradex AI Assistant.


References:

$ grep -iE "etnaviv|galcore|gpu|drm" dmesg.log
[    3.601099] systemd[1]: Starting Load Kernel Module drm...
[    5.317512] [drm] Initialized imx-lcdif 1.0.0 for 32fc6000.display-controller on minor 0
[    5.326147] imx-lcdif 32fc6000.display-controller: [drm] Cannot find any crtc or sizes
[    5.859874] samsung-dsim 32e60000.dsi: [drm:samsung_dsim_host_attach [samsung_dsim]] Attached sn65dsi83 device (lanes:4 bpp:24 mode-flags:0x2e3)
[    5.881248] [drm] Initialized imx-lcdif 1.0.0 for 32e80000.display-controller on minor 1
[    6.035963] imx-lcdif 32e80000.display-controller: [drm] fb0: imx-lcdifdrmfb frame buffer device
[rdoerner@fee-pc-rdoe ~]$

Some more info:

  • We use linux-toradex-upstream from yocto scarthgap branches

Some news on this topic.

The problem disappered if we use a

“Verdin iMX8M Plus Quad 4GB WB IT”

instead of a “Verdin iMX8M Plus Quad 2GB WB IT”

We assumed these are identical modules, beneath the ram size.

Hello @reinhard,

Thanks for the detailed report. I quickly checked here on my side on a Verdin iMX8MP Q 2GB WB IT module with a Scarthgap upstream multimedia image with kernel version 6.12.41. In this setup I am unable to reproduce the issue that you are experiencing:

root@verdin-imx8mp-15506608:~# tdx-info 

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.12.41-7.4.0-devel #1 SMP PREEMPT Fri Aug  1 08:48:47 UTC 2025
Kernel command line:      root=PARTUUID=53b61507-02 ro rootwait console=tty1 console=ttymxc2,115200
Distro name:              NAME="TDX Wayland with XWayland Upstream"
Distro version:           VERSION_ID=7.4.0-devel-20250801-build.402
Distro variant:           -
Hostname:                 verdin-imx8mp-15506608
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0064 V1.1B
Serial number:            15506608
Processor arch:           aarch64
------------------------------------------------------------


root@verdin-imx8mp-15506608:~# ls /dev/dri/
by-path  card0  card1  card2  renderD128

This module is of version V1.1B. I do not have V1.1A with me at the moment. Could you please also test on the reference multimedia image from Toradex? This would help us rule out any possibility of a hardware issue.

Hi @rudhi.tx, hi @reinhard

I compiled the reference image for our carrier and the problem stays. Here are the infos:

root@verdin-imx8mp-15229969:~# tdx-info

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.12.31-7.3.0-devel #1 SMP PREEMPT Thu May 29 09:03:27 UTC 2025
Kernel command line:      root=PARTUUID=076c4a2a-02 ro rootwait console=tty1 console=ttymxc2,115200
Distro name:              NAME="TDX Wayland with XWayland"
Distro version:           VERSION_ID=7.3.0-devel-20250623073622-build.0
Distro variant:           -
Hostname:                 verdin-imx8mp-15229969
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on kt0345_base
Toradex version:          0064 V1.1A
Serial number:            15675195
Processor arch:           aarch64
------------------------------------------------------------

It turns out, the 0064 V1.1A uses the MIMX8ML6CVNKZAB without NPU, the other modules use the MIMX8ML8CVNKZAB with NPU. Disabling the NPU in the DT does the trick.

BR, Stephan

Hi @steff,

It is good that you got this working. I’m afraid this issue is related to your custom device tree. The reason I think so is, the 0064 V1.1B module that I have also features MIMX8ML6CVNKZAB without NPU. I could get the etnaviv driver started on it with our default device tree on a Dahlia carrier board.