Setting Colibri imx6ULL 512 SLC NAND - LCD screen to 320x240

Technical Support
, , , ,
1

I am currently looking at using the Colibri iMX6ULL 512MB with embedded Linux via Yocto.
I had been using the 5.7.0 Reference Multimedia build from TEZI.
This has worked fine and i am able to change the screen resolution using vidags to set up the 320x240 LCD panel we have.
I have also achieved the same results building the image via Yocto.
My problem started when i needed to add .NET 5.0 to the project.
An issue with .NET 5 that caused software issues that appear to have been fixed in .net 6, but i could not get Yocto to add a .net 6 with BSP5.
The solution was to move to BSP6 (kirkstone) build, which allow me to add .NET 6

My problem is i can no longer set the vidargs to 320x240 with the latest 6.2.0 Reference Multimedia image. As i am also using the 512MB SLC NAND, i have no option to use the device tree :frowning:

How do i go about changing the display settings?

2

Hi @ObiTwo ,

Thanks for reaching out to Toradex.

Glad to hear that!

You actually do have the option to use the device tree. What you do not have with the Colibri iMX6ULL NAND is the device tree overlays.
So what you could do is set the resolution of your display in a custom device tree file that should include the device tree file imx6ull-colibri-eval-v3.dtsi and add the panel-timings plus resolution in there.

Alternatively, you could directly edit the above-mentioned file and add the respective timings directly inside the &panel node.

This is the overview of what I would try.

Best Regards
Kevin

3

Hi @kevin.tx,
Thanks for the info.
As I am still on a steep Yocto learning curve, I am going to have to ask some noob questions.

Within the project i cannot find any .dtsi files.
I can get these from github, but looking at various articles, they refer to a /boot/dts folder which i also cannot find within the yocto project folders.

The closest thing i have found so far is the .patch files within the layers/…/linux-toradex-mainline-git folder which would provide a route to adding the &panel node changes required with a new patch file.
Is this valid route?

4

Hi @ObiTwo !

This is something that when we start learning Yocto, we need to pass through it :stuck_out_tongue:

The Yocto Project/Open Embedded only brings us the meta data (layers, which contain recipes, configurations, scripts, patches - maybe - etc). In here we will not find the actual data, in other words, the actual code that we need to compile.

From the recipes, we are able to find out from where the source code (to be compiled) is downloaded.

Maybe you would like to check these two videos about Yocto usage:

Although they are pretty old, I think they will be helpful.

And keep asking the questions you need. We are here to help :wink:

Best regards,

5

Hi @henrique.tx ,
I have watched the videos and they are informative, but skip over one vital operation.
This being the creation of the .patch file to update the dtsi file.
He creates the file the just pastes in a ready to go file.

I have since found out how to create the patch file by modifying the dtsi and using a few git commands.
Once rebuilt, the dtb files provided had increased in size which looked promising.
A quick HexEdit showed the addition of a 320x240 entry. Not absolute proof, but again, promising.

Applied the new image to my imx6ULL, but sadly it still defaults to 640x480 :frowning_face:
i tried applying the setenv vidargs video=‘mxsfb:320x240M-16@60’
and clearing them down to see if either worked bu i am still stuck at 640x480.

below is the settings used based on the example given in framebuffer boot configuration for the imx6ull.

&lcdif {
        display = <&display0>;
        status = "okay";

        display0: lcd-display {
            bits-per-pixel = <16>;
            bus-width = <18>;

            display-timings {
                native-mode = <&timing_vga>;

                /* Standard VGA timing */
                timing_vga: 640x480 {
                    clock-frequency = <6550000>;
                    hactive = <320>;
                    vactive = <240>;
                    hback-porch = <44>;
                    hfront-porch = <2>;
                    vback-porch = <11>;
                    vfront-porch = <18>;
                    hsync-len = <10>;
                    vsync-len = <10>;

                    de-active = <1>;
                    hsync-active = <0>;
                    vsync-active = <0>;
                    pixelclk-active = <0>;
                };
            };
        };
    };
6

A shot in the dark, but maybe try changing:

            timing_vga: 640x480

to

            timing_vga: 320x240
7

DOH!! Can’t believe i missed that :smiley:
Will try that asap.
Thanks.

8

Turns out I had set this correctly. Must have copied and old file for posting.
I check the dtsi file and it is set to
timing_vga: 320x240
So I am still at a loss as to why its not working on my LCD panel.

9

At what point(s) during boot are you using/looking at the lcd panel and seeing the wrong resolution? During uboot, kernel boot, or some sort of display application takeover after that? I only ask because each might try to muck with things during startup.

Once the kernel boots, can you examine/change the resolution using xrandr or something like that?

It would also be great if you could list the active device tree after startup from the kernel command line with something like “dtc -I fs /proc/device-tree” (if you have the device-tree-compiler package in your mix). If you don’t have that package available, you can look around that directory for display stuff and try to interpret if you have the correct device tree entries available.

And if you didn’t copy the actual real device tree piece above, post it here so we’re looking at exactly what is in your device tree.

10

Hi DaveM,
I have the imx6ULL running on an iris carrier.
This is connected to an LCD panel and a monitor via a DVI->vga connection.
Once powered on the boot sequence is visible at 640x480 on the monitor but the LCD just shows a 3rd of the screen white.
Sadly, the toradex multimedia reference image does not contain xrandr or dtc.
Examination of the /proc/device-tree did not reveal anything relating to a 320x240 setting.

I can look at the dtb files contained within the Toradex Installer file set I use to install the image.
using dtc, i can see the settings that were added to the dsti file.
The following is the settings added to the dsti file.
&lcdif {
display = <&display0>;
status = “okay”;

    display0: lcd-display {
        bits-per-pixel = <16>;
        bus-width = <18>;

        display-timings {
            native-mode = <&timing_vga>;

            /* Standard VGA timing */
            timing_vga: 320x240 {
                clock-frequency = <6550000>;
                hactive = <320>;
                vactive = <240>;
                hback-porch = <44>;
                hfront-porch = <2>;
                vback-porch = <11>;
                vfront-porch = <18>;
                hsync-len = <10>;
                vsync-len = <10>;

                de-active = <1>;
                hsync-active = <0>;
                vsync-active = <0>;
                pixelclk-active = <0>;
            };
        };
    };
};

And below is a section from the output of dtc -I dtb imx6ull-colibri-eval-v3.dtb:

		lcdif@21c8000 {
			compatible = "fsl,imx6ul-lcdif\0fsl,imx6sx-lcdif";
			reg = <0x21c8000 0x4000>;
			interrupts = <0x00 0x05 0x04>;
			clocks = <0x01 0xa2 0x01 0xa1 0x01 0x00>;
			clock-names = "pix\0axi\0disp_axi";
			status = "okay";
			pinctrl-names = "default";
			pinctrl-0 = <0x46 0x47>;
			display = <0x48>;
			phandle = <0x96>;

			port {

				endpoint {
					remote-endpoint = <0x49>;
					phandle = <0x55>;
				};
			};

			lcd-display {
				bits-per-pixel = <0x10>;
				bus-width = <0x12>;
				phandle = <0x48>;

				display-timings {
					native-mode = <0x4a>;

					320x240 {
						clock-frequency = <0x63f1f0>;
						hactive = <0x140>;
						vactive = <0xf0>;
						hback-porch = <0x2c>;
						hfront-porch = <0x02>;
						vback-porch = <0x0b>;
						vfront-porch = <0x12>;
						hsync-len = <0x0a>;
						vsync-len = <0x0a>;
						de-active = <0x01>;
						hsync-active = <0x00>;
						vsync-active = <0x00>;
						pixelclk-active = <0x00>;
						phandle = <0x4a>;
					};
				};
			};
		};

It would appear the device tree has the settings required, but i cant see any evidence of this in the /proc/device-tree folder.

I have attached the dtc output if that helps.
imx6ull-colibri-eval-v3-dtb.txt (55.5 KB)

11

So, if we go back to 5.7 with the “it worked before”, what changes did you make to that distribution in order for things to work with your panel? Is everything else the same (hardware connections?)

I guess the piece above of having both an lcd panel and a vga connection seems interesting also. If you unplug the vga or disable it some way on the carrier board does anything change?

Unfortunately “upgrading” always brings along a bunch of baggage. I hate upgrading. When things are stable, things are stable. Introducing variables into equations is a PIA.

12

Hi DaveM,
Back to 5.7. Works perfectly.
It does require configuration with:
setenv vidargs video=‘mxsfb:800x480M-16@60’

By default i have both VGA and LCD plugged in, as the installer defaults to 640x480.

I have made no changes to the build or hardware.
Just the default graphical image provided Toradex.
I would like the 6.0 version to work, but its less of a priority now.
I will have a look at the dtb generated by the 5.7 build and see if i can find the difference that allows it to work at 320x240.

1 Like
13

Sounds good…all of the vidargs/video/drm stuff probably has new requirements in the 6.x series. Folks don’t usually care about our little embedded lcd panels so testing is probably a bit sparse. Sticking with 5.7 is the way to go (for now).