Setting custom timings for Non-VESA monitor not working

I have been trying to set up the timings for a 1280x800 monitor with Non-VESA timings but am unable to get the timings to apply on creating the .dtbo file and applying it to the overlays.txt. In out bitbake layer, we have one .dts source file that sets up basic panel and LCD properties, and in another .dts file (1280x800_overlays.dts) we use to generate a .dtbo file and set that in the overlays.txt. I am able to set mode_str=“whateverxresolutionM@60” in mxcfb1 for our other monitors to generate an overlays file that works on our other monitors but since this particular monitor we are messing with does not use VESA timings I need to specify which timings we need.

This is where the problem we are having comes in: I cannot seem to write the display timings anywhere in the overlays .dts file and have the properties apply on reboot. fbset says the monitor settings reflect what is present in imx6qdl-colibri.dtsi which gives me the idea that the display timings are either being overwritten or not applied at all, and obviously as a result the monitor does not display correctly. The version of Yocto we are using is dunfell and the version of board we are using is imx6qdl. Our monitor’s timings is as follows:

/*display-timings {                                                 
    	timing {                                                  
            clock-frequency = <72400000>;                     
            hactive = <1280>;                                 
            vactive = <800>;                                  
            hfront-porch = <70>;                               
            hback-porch = <80>;                                
            hsync-len = <10>;                                
            vback-porch = <20>;                                
            vfront-porch = <10>;                               
            vsync-len = <8>;
	    hsync-active = <0>;
	    vsync-active = <0>;
	    de-active = <0>;
	    pixelclk-active = <0>;
	};
};*/

Our “main” .dts contains the relevant information:

lcd_display: display@di0 {
		compatible = "fsl,imx-parallel-display";
		#address-cells = <1>;
		#size-cells = <0>;
		interface_pix_fmt = "rgb24";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_ipu1_lcdif>;
		status = "okay";

		port@0 {
			reg = <0>;

			lcd_display_in: endpoint {
				remote-endpoint = <&ipu1_di0_disp0>;
			};
		};

		port@1 {
			reg = <1>;

			lcd_display_out: endpoint {
				remote-endpoint = <&lcd_panel_in>;
			};
		};
	};


&lcd {
//	status = "okay";
	default_ifmt = "RGB24";

};



&mxcfb2 {
	status = "disabled";
};

&pinctrl_ipu1_lcdif {
         fsl,pins = <
            MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK   0xa1
            MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15      0xa1
            MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02    0xa1
            MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03    0xa1
            MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00  0xa1
            MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01  0xa1
            MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02  0xa1
            MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03  0xa1
            MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04  0xa1
            MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05  0xa1
            MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06  0xa1
            MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07  0xa1
            MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08  0xa1
            MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09  0xa1
            MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0xa1
            MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0xa1
            MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0xa1
            MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0xa1
            MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0xa1
            MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0xa1
            MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0xa1
            MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0xa1
            MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0xa1
            MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0xa1
            MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0xa1
            MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0xa1
            MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0xa1
            MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0xa1
         >;
};

(irrelevant components removed)

Our overlays .dts file is as follows:

// Enable the LCD interface and turn on the VGA DAC on the Colibri iMX6DL

/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,colibri_imx6dl";
};

&backlight {
	status = "okay";
};

&lcd {
	status = "okay";
};

&lcd_display {
	status = "okay";
	
};

&mxcfb1 {
	interface_pix_fmt = "RGB24";
	default_bpp = <32>;
	/delete-property/640x480M@60;
	/delete-property/mode_str;
	status = "okay";

        display-timings {                                                 
    	        timing {                                                  
        	        clock-frequency = <72400000>;                     
                        hactive = <1280>;                                 
                        vactive = <800>;                                  
                        hfront-porch = <70>;                               
                        hback-porch = <80>;                                
                        hsync-len = <10>;                                
                        vback-porch = <20>;                                
                        vfront-porch = <10>;                               
                        vsync-len = <8>;
			hsync-active = <0>;
			vsync-active = <0>;
			de-active = <0>;
			pixelclk-active = <0>;
		};
        };
};

 &pwm3 {
	status = "okay";
};

I have tried to place the display timings in the mxcfb1, lcd_display, and lcd objects with no change to fbset’s output. Let me know if I need to provide anymore information. I am fairly inexperienced with specifying timings in the device tree.

Hi @smcgAdditech,

Could you please share with us the datasheet of the display you are using? In this way, I can help you with the right timing for your model.

The display-timings node should not be inside the mxcfb1. Take the following example

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
 * Copyright 2020-2021 Toradex
 */

// VGA display with a resolution of 640x480 pixel. VGA Signal 640x480@60Hz Industry standard timing

/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,apalis_imx6q",
		     "toradex,apalis-imx8x",
		     "toradex,colibri_imx6dl",
		     "toradex,colibri-imx6ull",
		     "toradex,colibri-imx7d",
		     "toradex,colibri-imx7d-emmc",
		     "toradex,colibri-imx7s",
		     "toradex,colibri-imx8x";
};

&{/panel-dpi} {
	status = "okay";
	/* for 0.3mm pixels */
	width-mm = <192>;
	height-mm = <144>;

	panel-timing {
		clock-frequency = <25175000>;
		hactive = <640>;
		vactive = <480>;
		hsync-len = <96>;
		hfront-porch = <16>;
		hback-porch = <48>;
		vsync-len = <2>;
		vfront-porch = <10>;
		vback-porch = <33>;
	};
};

from display-vga_overlay.dts overlay. Please, try to set the timings like the file above to check if it works or not and share with us the datasheet so we can support you better.

Best Regards,
Hiago.

Hello, thank you for the reply. The model of monitor is a 1280x800 Ampire AM-1280800W2TZQW-01H. The timings were given to me via a representative of the company on email. They are as provided below:

/*display-timings {                                                 
    	timing {                                                  
            clock-frequency = <72400000>;                     
            hactive = <1280>;                                 
            vactive = <800>;                                  
            hfront-porch = <70>;                               
            hback-porch = <80>;                                
            hsync-len = <10>;                                
            vback-porch = <20>;                                
            vfront-porch = <10>;                               
            vsync-len = <8>;
	    hsync-active = <0>;
	    vsync-active = <0>;
	    de-active = <0>;
	    pixelclk-active = <0>;
	};
};*/

I will see if adding the panel into the monitor .dts file fixes the problem and reply back.

Hi @smcgAdditech,

Perfect, please try as I showed you in my last reply, and then let me know if that helped.

Best Regards,
Hiago.

It seems that adding that specific declaration for the panel and changing the timings to match my monitor did not work and resulted in some kind of kernel panic, as all lights on board and our mini-OLED screen no longer turn on. I cannot get ssh access back into our board. Only way to regain access is by reflashing the OS back on it and clearing the overlays.txt.

I currently added this to the 1280x800_overlays.dts file which is what caused the system to cease responding on reboot:

&{/panel-dpi} {
	status = "okay";
	/* for 0.3mm pixels */
	width-mm = <192>;
	height-mm = <144>;

	panel-timing {
        clock-frequency = <72400000>;                     
        hactive = <1280>;                                 
        vactive = <800>;                                  
        hfront-porch = <70>;                               
        hback-porch = <80>;                                
        hsync-len = <10>;                                
        vback-porch = <20>;                                
        vfront-porch = <10>;                               
        vsync-len = <8>;
		hsync-active = <0>;
		vsync-active = <0>;
		de-active = <0>;
		pixelclk-active = <0>;
	};
};

I do not know if I must change width-mm or height-mm for my specific monitor as I never received any specific properties of that in the datasheet, but I would assume I would receive SOME KIND of output, whether garbled or not.
Also, I should specify I changed &{/panel-dpi} { to &panel { as well and tested that also, in that case I did not receive any panic but the timings defaulted back to 640x480m60 which is specified in imx6qdl-colibri.dtsi.

Hi @smcgAdditech,

Please, try the above overlay:


/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,colibri_imx6dl";
};

&{/panel-dpi} {
	status = "okay";

	panel-timing {
        clock-frequency = <72400000>;                     
        hactive = <1280>;                                 
        vactive = <800>;                                  
        hfront-porch = <70>;                               
        hback-porch = <80>;                                
        hsync-len = <10>;                                
        vback-porch = <20>;                                
        vfront-porch = <10>;                               
        vsync-len = <8>;
	    hsync-active = <0>;
	    vsync-active = <0>;
	    de-active = <0>;
	    pixelclk-active = <0>;
	 };
};

You can download the overlay compiled here: Download - Toradex File Sharing Platform.
Please use this overlay with the default device tree from Toradex (select the right carrier board), so we can check if something is going on if you’re device tree or if it’s a problem in the Toradex device tree. If it crashes, can you send me your dmesg log, please?

Best Regards,
Hiago.

Thank you for the suggestion. I attempted to use the compiled device tree object and it panicked again. I am not sure how I would be able to retrieve logs off the device if I cannot even ssh into it when it powers on. I’m going to install one of the default linux images on the board and try the dtbo file on it to see if maybe I have a mistake or conflict in my device tree.

Hi @smcgAdditech,

Can you please try this overlay that I’ve sent you with the Toradex device tree? So then we can narrow down the problem and check if it’s a problem with the overlay or with your specific device tree.

If the overlay is panicking your kernel, you can disable it in uboot terminal by running

> setenv skip_fdt_overlays 1
> boot

This will boot your image without the device tree overlay. Then you can get the dmesg log.

Best Regards,
Hiago

It seems to just hang indefinitely at

ERROR: Did not find a cmdline Flattened Device Tree

Starting kernel ...

My entire output via the UART port is as follows after boot:

Colibri iMX6 # boot             
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
4807 bytes read in 22 ms (212.9 KiB/s)
## Executing script at 17000000
Loading DeviceTree: imx6dl-colibri-MASrevC.dtb
75891 bytes read in 19 ms (3.8 MiB/s)
46 bytes read in 10 ms (3.9 KiB/s)
Applying Overlay: colibri-imx6_custom_display.dtbo
608 bytes read in 37 ms (15.6 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
6822528 bytes read in 248 ms (26.2 MiB/s)
Bootargs: enable_wait_mode=off galcore.contiguousSize=50331648 root=PARTUUID=664643aa-02 ro rootwait fec_mac=XX:XX:XX:XX:XX:XX consoleblank=0 no_console_suspend=1 console=tty1 console=ttymxc0,115200n8 fbmem=8M
ERROR: Did not find a cmdline Flattened Device Tree

Starting kernel ...

So it seems the environment variable is not being set correctly.

Hi @smcgAdditech,

I can see you’re loading your own customer device tree here. It’s probably breaking something and then Linux can’t boot. If you test if the default Toradex Device tree, like imx6dl-colibri-eval-v3.dts, it will probably work. Can you test that? What are you changing in your device that could be possibly causing this issue?

Best Regards,
Hiago.

Changes done in the custom tree are explained in the original question, just basic gpio pinout configuration and “template” declarations that are then reused in the .dtbo files.

I was successful in setting the Tree to the imx6dl-colibri-eval-v3.dtb object, but even after scp’ing the custom .dtbo sent to me into the /boot/overlays directory and setting it to the overlay, I still receive this error in uboot:

CPU:   Freescale i.MX6DL rev1.4 996 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 49C
Reset cause: POR
DRAM:  512 MiB
PMIC:  device id: 0x10, revision id: 0x21, programmed
MMC:   FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Model: Toradex Colibri iMX6 DualLite 512MB V1.1A, Serial# 10770038
Net:   eth0: ethernet@2188000
Hit any key to stop autoboot:  0 
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
4807 bytes read in 23 ms (204.1 KiB/s)
## Executing script at 17000000
Loading DeviceTree: imx6dl-colibri-eval-v3.dtb
72921 bytes read in 24 ms (2.9 MiB/s)
46 bytes read in 10 ms (3.9 KiB/s)
Applying Overlay: colibri-imx6_custom_display.dtbo
608 bytes read in 36 ms (15.6 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
6822528 bytes read in 247 ms (26.3 MiB/s)
Bootargs: enable_wait_mode=off galcore.contiguousSize=50331648 root=PARTUUID=daeeae2a-02 ro rootwait fec_mac=XX:XX:XX:XX:XX:XX consoleblank=0 no_console_suspend=1 console=tty1 console=ttymxc0,115200n8 fbmem=8M
ERROR: Did not find a cmdline Flattened Device Tree

Starting kernel ...

Without the overlays.dtbo declared, by device boots normally but just has no video output. The new .dtbo file is in fact in the /boot/overlays/ directory as I checked and saw it in there after scp.

Sorry to revive an old post, but have you happened to get a general idea of what is going wrong with my device tree boot process? And is there any information you might need that I haven’t brought up that you could use to help you figure out what might be going wrong here?

Hi @smcgAdditech,

Sorry for the delay. I couldn’t detect what is wrong with your device tree. Can you share the dts and the overlay code that you are using? Also, can you explain to me how are you compiling everything?

Best regards,
Hiago.

Hello,
Thank you for the reply. The DTS file is “semi-proprietary” so unfortunately I cannot post it directly here, but I asked my supervisor and he has allowed me to direct message you with the entire DTS file.
As for the overlay code, I will post the entire thing here:


// Enable the LCD interface and turn on the VGA DAC on the Colibri iMX6DL

/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,colibri_imx6dl";
};

&backlight {
	status = "okay";
};

&lcd {
	status = "okay";
	
	display-timings {  
	native-mode = <&t_lcd>
    	t_lcd: t_lcd_default {                                                  
        	clock-frequency = <72400000>;                     
            hactive = <1280>;                                 
            vactive = <800>;                                  
            hfront-porch = <72>;                               
            hback-porch = <200>;                                
            hsync-len = <128>;                                
            vback-porch = <3>;                                
            vfront-porch = <22>;                               
            vsync-len = <6>;                                 
		};
	};
	
};

&lcd_display {
	status = "okay";
	
};

&mxcfb1 {
	interface_pix_fmt = "RGB24";
	default_bpp = <32>;
	/delete-property/mode_str;
	status = "okay";
};


&pwm3 {
	status = "okay";
};


I am assuming I probably have things in the wrong spot, as it’s been a while since I’ve looked at it directly, but this is basically the code I’ve been having problems with.

As for compiling, all I am doing so far is just the regular

cpp -nostdinc -I ${SOURCE}/arch/arm/boot/dts/ -I ${S}/include/ -undef -x assembler-with-cpp ./mine.dts ./mine.dts.processed
 /usr/bin/dtc -f -@ -Hepapr -I dts -O dtb -i ${SOURCE}/arch/arm/boot/dts/ -o ./mine.dtbo ./mine.dts.processed

The .dtb file works completely fine with all my other unrelated stuff, it just seems that the moment I try to add this “non-VESA” dts file (all other ones that I’ve used mode_str with work fine) I start getting panics.

On a related note about private messaging you, on this particular forum how would I go about sending you a private message? I have never sent a PM before on this forum and I want to make sure I don’t accidentally post the file on a public “wall” of yours.

Hi @smcgAdditech,

I sent you a private message. Please, check your inbox. We can continue this thread there privately.

Best Regards,
Hiago.