Verdin imx8mp mipi_dsi display weston failure / no image


I am using a Verdin imx8mp on a custom carrier board and trying to get the display working. Currently I cannot see anything on the display and weston fails to launch. I managed to get the backlight working by customizing my devictree .dtsi like in this thread Imx8mm: mipi-dsi display with 1920x1200 .

The panel I’m using is Ortustech COM43H4N10ULC , for which I have a driver and which is working properly on a Colibri imx8qxp custom carrier board. The BSP version used is 6.3.0 Kirkstone.

Here is a device tree snippet

/* MIPI-DSI */
&lcdif1 {
    status = "okay";

&ldb {
	status = "okay";

&ldb_phy {
	status = "okay";

&backlight {
    brightness-levels = <0 255>;
    num-interpolated-steps = <255>;
    default-brightness-level = <127>;
    power-supply = <&reg_3p3v>;
    pwms = <&pwm3 0 5000000 1>;
    enable-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
    status = "okay";

&mipi_dsi {
    #address-cells = <1>;
    #size-cells = <0>;
    status = "okay";

	panel@0 {
        #address-cells = <1>;
        #size-cells = <0>;		
        compatible = "ortustech,com43h4n10ulc";
        reg = <0>;
        power-supply = <&reg_3p3v>;	
		backlight = <&backlight>;

		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_gpio_10_dsi>;
		enable-gpios = <&gpio3 3 GPIO_ACTIVE_HIGH>;	// Verdin GPIO_10_DSI (SODIMM 21)

		status = "okay";	

		port@0 {
			reg = <0>;
        	panel1_in: endpoint {
				remote-endpoint = <&mipi_dsi_panel1_out>;

	port@1 {
		reg = <1>;
		mipi_dsi_panel1_out: endpoint {
			remote-endpoint = <&panel1_in>;

On bootup I can see this error

imx_sec_dsim_drv 32e60000.mipi_dsi: [drm] *ERROR* modalias failure on /soc@0/bus@32c00000/mipi_dsi@32e60000/port@1

And the weston log looks like this

[22:44:13.298] weston 10.0.1
               Bug reports to:
               Build: lf-5.15.52-2.1.0+
[22:44:13.299] Command line: /usr/bin/weston --log=/tmp/weston.log
[22:44:13.299] OS: Linux, 5.15.77-6.3.0-devel+git.ddc6ca4d76ea, #1 SMP PREEMPT Thu Jun 29 10:14:22 UTC 2023, aarch64
[22:44:13.299] Flight recorder: enabled
[22:44:13.300] Using config file '/etc/xdg/weston/weston.ini'
[22:44:13.300] Output repaint window is 7 ms maximum.
[22:44:13.301] Loading module '/usr/lib/libweston-10/'
[22:44:13.318] initializing drm backend
[22:44:13.318] Trying logind launcher...
[22:44:13.336] logind: session control granted
[22:44:13.344] using /dev/dri/card0
[22:44:13.344] DRM: supports atomic modesetting
[22:44:13.344] DRM: does not support GBM modifiers
[22:44:13.344] DRM: supports picture aspect ratio
[22:44:13.346] Loading module '/usr/lib/libweston-10/'
[22:44:13.369] EGL client extensions: EGL_EXT_client_extensions
               EGL_EXT_platform_base EGL_KHR_platform_wayland
               EGL_EXT_platform_wayland EGL_EXT_device_query
               EGL_EXT_device_drm EGL_EXT_device_drm_render_node
---- stops here ----

Could there possibly be something wrong in my custom device tree ?

Best regards and thanks,

Hi @Amik7 ,

The panel I’m using is Ortustech COM43H4N10ULC , for which I have a driver and which is working properly on a Colibri imx8qxp custom carrier board. The BSP version used is 6.3.0 Kirkstone.

Is the device tree used for the Colibri iMX8X similar to what you used for the Verdin iMX8M Mini?

Where exactly did you get the driver for your display? In the Downstream kernel used on BSP 6 I can’t find any references to its compatible field in the kernel devicetree documentation, only for other displays of the same manufacturer:

[linux/Documentation/devicetree/bindings]$ git status
On branch toradex_5.15-2.2.x-imx
Your branch is up to date with 'origin/toradex_5.15-2.2.x-imx'.

nothing to commit, working tree clean

[linux/Documentation/devicetree/bindings]$ grep -R ortustech,com43h4n10ulc
[linux/Documentation/devicetree/bindings]$ grep -R ortustech
display/panel/panel-simple.yaml:      - ortustech,com37h3m05dtc
display/panel/panel-simple.yaml:      - ortustech,com37h3m99dtc
display/panel/panel-simple.yaml:      - ortustech,com43h4m85ulc
vendor-prefixes.yaml:  "^ortustech,.*":

Maybe that’s related to your issue?

Best regards,
Lucas Akira

Hi @lucas_a.tx ,

Thanks for the response.

I would say that the DTs are similar only to some extent, as they are quite different in general already. I have used as a basis for my custom DT.

The driver is self written and based on Raydium rm67191 driver. Also, it is enabled in kernel config and loaded at the boot. I tried patching these files accordingly like you suggested, and actually Weston starts but there is still no image.


On dmesg | grep dsi and dmesg | grep drm I can see the following lines

[ 0.322384] platform 32e80000.lcd-controller: Fixing up cyclic dependency with 32e60000.mipi_dsi
[ 1.516622] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops)
[ 1.524885] imx_sec_dsim_drv 32e60000.mipi_dsi: version number is 0x1060200
[ 1.532220] imx-drm display-subsystem: bound 32e60000.mipi_dsi (ops imx_sec_dsim_ops)
[ 1.540967] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0
[ 1.744647] imx-drm display-subsystem: [drm] fb0: imx-drmdrmfb frame buffer device
[ 5.009643] systemd[1]: Starting Load Kernel Module drm…
[ 5.251182] [drm] Initialized vivante 1.0.0 20170808 for 40000000.mix_gpu_ml on minor 1
[ 8.674015] imx_sec_dsim_drv 32e60000.mipi_dsi: wait rx done time out
[ 8.962074] imx_sec_dsim_drv 32e60000.mipi_dsi: wait payload tx done time out

with the time out messages at the bottom. Maybe the issue is there somehow ?

Best regards,

Hi @Amik7 ,

The driver is self written and based on Raydium rm67191 driver.

Given that you wrote the driver, it’s hard for us to tell exactly about the device tree bindings for it, as this depends on how your driver interprets it. If you based it on the Raydium rm67191 driver then its DT binding documentation in the kernel is probably the best resource you can look to make sure the bindings are correct.

Best regards,
Lucas Akira

Hi @lucas_a.tx ,

Apologies for not answering, I’ve been off for a while.

Here is the driver file, panel-simple.c patch and panel definitions (as a collective .txt file for the purpose of this post). As for now, the com43h4n10ulc driver wont load, only imx_sec_dsim (dmesg | grep -i ortus returns nothing). If I comment out panel_desc_dsi com43h4n10ulc etc then the ortustech driver will load, although then also these imx_sec_dsim timeout errors pop up along with com43h4n10ulc backlight enable/disable failure messages (dmesg | grep -i ortus will return succeeded in all the other each steps). Regardless of what’s in panel-simple.c, only backlight is working but still no image even with Weston running.

Best regards,

panel-definitions-yamls.txt (3.1 KB)

panel-simple.c (2.3 KB)

panel-ortustech-com43h4n10ulc.c (13.4 KB)

Hi @Amik7 !

The development of drivers is usually out of the scope of Toradex Support.

If you need help to enable the hardware you need, we can refer you to some of our partners who have expertise on this topic.

Best regards,

Hi @henrique.tx @lucas_a.tx ,

I got the issue solved. After all it turned out to be a reset related hardware issue :upside_down_face:

Thanks for the help and quick responses anyways :slight_smile:


Hi @Amik7 !

Happy to know that you found the issue :slight_smile:

Glad to help :smiley:

And thanks for the feedback! I marked your message as the solution.

Have a nice day!