g2d_open failed - imxvideoconvert_g2d

Technical Support
1

Im using the Verdin IMX8MPlus SoM in combination with the Dahlia Carrier Board.

When running gst-inspect-1.0 imxvideoconvert_g2d (in a docker container, see Additional Notes below), I get the following error: “g2d_open: fail with status -7”

0:00:00.087035750    16   0x559671c630 LOG          imxvideoconvert gstimxvideoconvert.c:1979:gst_imx_video_convert_register: Registering g2d video converter
g2d_open: fail with status -7
0:00:00.088508875    16   0x559671c630 ERROR        imxvideoconvert gstimxvideoconvert.c:1940:gst_imx_video_convert_init: Open video process device failed.

I am using a custom image build, I built with the Torizon Core Builder v3.13.0 (Linux Kernel: toradex_6.6-2.2.x-imx, Torizon OS image: 7.3.0+build.18) that includes a device tree overlay for the Framos IMX678-driver (following instructions from First Steps with Framos FSM:GO CSI Optical Sensor Modules(Torizon) | Toradex Developer Center ):

input:
	easy-installer:
		local: torizon-docker-verdin-imx8mp-Tezi_7.3.0+build.18.tar

customization:
	device-tree:
		include-dirs:
			- linux/include
			- device-trees/overlays
		custom: linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-dahlia.dts
		overlays:
			add:
				- device-trees/overlays/verdin-imx8mp_imx678_overlay.dts
				- device-trees/overlays/verdin-imx8mp_hdmi_overlay.dts
kernel:
	modules:
		- source-dir: imx678-driver/
		  autoload: false

output:
     easy-installer:
	     local: custom-torizon-docker-verdin-imx8mp
	     name: Torizon OS - Framos Camera

When using the following BSP image (BSP 7, Downstream Linux Reference Multimedia, Verdin iMX8M Plus - 7.4.0+build.10): https://tezi.toradex.com/artifactory/tdxref-oe-prod-frankfurt/scarthgap-7.x.y/release/10/verdin-imx8mp/tdx-xwayland/tdx-reference-multimedia-image/oedeploy/Verdin-iMX8MP_Reference-Multimedia-Image-Tezi_7.4.0+build.10.tar The imxvideoconvert_g2d command is working normally.

Am I missing of installing/configuring something in my custom image?

Additional Notes:

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

G2D Hardware Acceleration Issue on Custom Torizon OS Image

The error “g2d_open: fail with status -7” indicates that the G2D (Graphics 2D) hardware acceleration driver cannot access the hardware properly in your custom Torizon OS image.

Root Cause Analysis

The issue stems from differences between your custom Torizon OS 7.3.0 image and the BSP Reference Multimedia image. The G2D driver requires specific kernel configurations and device tree settings that may not be present in your customized build.

Solution Steps

1. Verify Your Configuration File Structure

Your tcbuild.yaml configuration looks correct for basic device tree customization(1). However, ensure your project structure matches the expected format:

.
├── linux
├── device-trees
│   └── overlays
│       └── verdin-imx8mp_imx678_overlay.dts
│       └── verdin-imx8mp_hdmi_overlay.dts
├── tcbuild.yaml
└── torizon-docker-verdin-imx8mp-Tezi_7.3.0+build.18.tar

2. Use the Correct Base Device Tree

Your configuration uses imx8mp-verdin-nonwifi-dahlia.dts(1). For the Dahlia Carrier Board with Verdin iMX8M Plus, ensure this device tree includes the necessary GPU and VPU configurations(2).

3. Add Required Include Directories

Update your tcbuild.yaml to include all necessary header directories(3):

customization:
  device-tree:
    include-dirs:
      - linux/include
      - device-trees/overlays
    custom: linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-dahlia.dts
    overlays:
      add:
        - device-trees/overlays/verdin-imx8mp_imx678_overlay.dts
        - device-trees/overlays/verdin-imx8mp_hdmi_overlay.dts

4. Verify Kernel Module Loading

Since your Framos camera driver has autoload: false, ensure that all required multimedia drivers are properly loaded. The G2D functionality depends on specific kernel modules being available.

Hardware Verification

Your verification that the following devices show “okay” status is correct:

  • gpu2d@38008000
  • gpu3d@38000000
  • vipsi@38500000
  • vpu_g1@38300000
  • vpu_g2@38310000
  • vpu_v4l2

However, the G2D driver also requires proper memory allocation and device permissions.

Recommended Approach

  1. Build a minimal test image without the Framos overlay first to isolate the G2D issue
  2. Compare device tree differences between your custom image and the working BSP Reference Multimedia image
  3. Verify container permissions - ensure your Docker container has access to the required device nodes (/dev/galcore, /dev/mxc_hantro)

The key difference is likely that the BSP Reference Multimedia image includes additional kernel configurations and device tree settings specifically for multimedia acceleration that aren’t present in the base Torizon OS image you’re customizing.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hi @random,

This was tested on earlier versions of Torizon 7 and BSP 7 (specifically 7.0.0 and 7.1.0).
Have you, by any chance, tried testing with these versions?

I’d also suggest testing with the latest Torizon 6 release to help narrow down the issue.
With these tests, we can identify when the problem started and get closer to finding a solution.

Best regards.

4

Hi @lucas_az.tx ,

I tested again with different Torizon builds (without modifying them this time, so no custom build and no Framos driver).

On Torizon OS 6 builds 6.8.3 and 6.5.0 the imxvideoconvert_g2d is working. When running gst-inspect it shows:
No g2d kernel cache file /tmp/g2d_opencl_kernel.bin
Building g2d kernel … buildBinarySize = 58435“
I can also use the element in my gstreamer pipeline with the testvideo source.

On Torizon OS 7 however : 7.3.0 and 7.0.0 it is not working anymore, I get the “g2d_open: fail with status -7“ error.

Regards

5

Hi @random!

You mentioned earlier that you used the torizon-samples/vpu/generic/vpuGeneric docker-compose file to run the GStreamer commands. Could you share why you chose this specific docker-compose setup?

For the next steps, I recommend testing the version that was working properly (Torizon 6.8.3) and applying your customization and the Framos drivers.

If everything works as expected, I would suggest staying on that version, since it is already stable and ready to use. Fixing issues or bugs in Torizon 7 might take some time and could delay your project.

Best regards.

6

The torizon-samples/vpu/generic/vpuGeneric docker container was just for testing, to make sure our custom docker container is not the issue.

I switched to Torizon OS 6 now and now everything is working as expected (including our custom docker container setup). We will stay on Torizon OS 6 then until OS 7 is fixed.

Thanks!

1 Like