Hello,
I have been working at getting a custom device tree up and running to allow the Colibri iMX7S module to run a custom display plugged into the toradex evaluation board. I have custom values for the LCD settings, and I believe I have set them correctly. In my early development, I have taken the existing imx7-colibri-eval-v3.dtsi and put my own parameters into every single display-timing option stored there. after compilation, I ran an fdtdump on the compiled imx7s-colibri-eval-v3.dtb file, and I have attached the relevant section at the end of this question. It appears as though the dtb file has the correct timings in it, however when I boot up the board, I see the display I started with still works, and the display I am attempting to use will not start up. because the old display works, it makes me think that the settings I have changed are not actually changing anything. software is being loaded to the board through a customized easy-installer package, if needed, I can attach that as well, but its just the boot2qt package with a redirected image.json, new dtb files, a new zimage, and a modified uenv.txt.
Any help would be appreciated,
Nate Hinshaw
lcdif@30730000 {
compatible = "fsl,imx7d-lcdif", "fsl,imx28-lcdif";
reg = <0x30730000 0x00010000>;
interrupts = <0x00000000 0x00000005 0x00000004>;
clocks = <0x00000001 0x0000007a 0x00000001 0x00000199 0x00000001 0x00000199>;
clock-names = "pix", "axi", "disp_axi";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <0x0000002b 0x0000002c>;
display = <0x0000002d>;
lcd-display {
bits-per-pixel = <0x00000020>;
bus-width = <0x00000012>;
linux,phandle = <0x0000002d>;
phandle = <0x0000002d>;
display-timings {
native-mode = <0x0000002e>;
640x480 {
clock-frequency = <0x018b0879>;
hactive = <0x000001e0>;
vactive = <0x00000280>;
hback-porch = <0x00000005>;
hfront-porch = <0x00000005>;
vback-porch = <0x00000002>;
vfront-porch = <0x00000002>;
hsync-len = <0x00000005>;
vsync-len = <0x00000002>;
de-active = <0x00000001>;
hsync-active = <0x00000000>;
vsync-active = <0x00000000>;
pixelclk-active = <0x00000001>;
linux,phandle = <0x0000002e>;
phandle = <0x0000002e>;
};
800x480 {
clock-frequency = <0x018b0879>;
hactive = <0x000001e0>;
vactive = <0x00000280>;
hback-porch = <0x00000005>;
hfront-porch = <0x00000005>;
vback-porch = <0x00000002>;
vfront-porch = <0x00000002>;
hsync-len = <0x00000005>;
vsync-len = <0x00000002>;
de-active = <0x00000001>;
hsync-active = <0x00000000>;
vsync-active = <0x00000000>;
pixelclk-active = <0x00000001>;
};
800x480pixclkact {
clock-frequency = <0x018b0879>;
hactive = <0x000001e0>;
vactive = <0x00000280>;
hback-porch = <0x00000005>;
hfront-porch = <0x00000005>;
vback-porch = <0x00000002>;
vfront-porch = <0x00000002>;
hsync-len = <0x00000005>;
vsync-len = <0x00000002>;
de-active = <0x00000001>;
hsync-active = <0x00000000>;
vsync-active = <0x00000000>;
pixelclk-active = <0x00000001>;
};
800x600 {
clock-frequency = <0x018b0879>;
hactive = <0x000001e0>;
vactive = <0x00000280>;
hback-porch = <0x00000005>;
hfront-porch = <0x00000005>;
vback-porch = <0x00000002>;
vfront-porch = <0x00000002>;
hsync-len = <0x00000005>;
vsync-len = <0x00000002>;
de-active = <0x00000001>;
hsync-active = <0x00000000>;
vsync-active = <0x00000000>;
pixelclk-active = <0x00000001>;
};
1024x600 {
clock-frequency = <0x018b0879>;
hactive = <0x000001e0>;
vactive = <0x00000280>;
hback-porch = <0x00000005>;
hfront-porch = <0x00000005>;
vback-porch = <0x00000002>;
vfront-porch = <0x00000002>;
hsync-len = <0x00000005>;
vsync-len = <0x00000002>;
de-active = <0x00000001>;
hsync-active = <0x00000000>;
vsync-active = <0x00000000>;
pixelclk-active = <0x00000001>;
};
1024x768 {
clock-frequency = <0x018b0879>;
hactive = <0x000001e0>;
vactive = <0x00000280>;
hback-porch = <0x00000005>;
hfront-porch = <0x00000005>;
vback-porch = <0x00000002>;
vfront-porch = <0x00000002>;
hsync-len = <0x00000005>;
vsync-len = <0x00000002>;
de-active = <0x00000001>;
hsync-active = <0x00000000>;
vsync-active = <0x00000000>;
pixelclk-active = <0x00000001>;
};
};
};
};
What exact hardware (carrier board and display) and software versions of things are you talking about?
I am using the Colibri Evaluation Board, Colibri Evaluation Board | Toradex Developer Center,
the display we were originally using with it was
the Resistive Touch Display 7" Parallel, Resistive Touch Display 7" Parallel | Toradex Developer Center
the new display I am trying to run is an off the shelf transflective 480x640 3.5 inch display. I was given options for my device tree settings as :
display: display {
bits-per-pixel = <32>;
bus-width = <18>;
display-timings {
native-mode = <&timing0>;
timing0: timing0 {
clock-frequency = <25888889>;
hactive = <480>;
vactive = <640>;
hback-porch = <5>;
hfront-porch = <5>;
vback-porch = <2>;
vfront-porch = <2>;
hsync-len = <5>;
vsync-len = <2>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <1>;
};
};
};
I then went ahead and set all of the potential resolutions to that setting. I am not expecting that to actually drive the display I am attempting to use, however I would expect that the 7 inch resistive touch display would stop working, as I have changed the frequency that the display should be expecting. the display; however, has continued working, despite my best efforts.
The versions of the things I am talking about, Zimage, Dtb, etc… are whatever the latest were I could pull and build following
running git clone -b toradex_4.9-2.3.x-imx git://git.toradex.com/linux-toradex.git
and then going through the series of build steps to get both pieces built. the only piece modified in the device tree was IMx7-colibri-eval-v3.dtsi, where I changed the displaytimings in every column to my intended values. again intending not necessarily to make my display work, but to make the existing display stop working, as a verification that my changes are having an effect on the system.
Thanks,
Nate Hinshaw
Hi @Nhinshaw
the display we were originally using with it was
the display is an display we purchased the Resistive Touch Display 7" Parallel
Did you manage to make this display to work?
the new display I am trying to run is an off the shelf transflective 480x640 3.5 inch display
Could you share a datasheet of this display?
I then went ahead and set all of the potential resolutions to that setting. I am not expecting that to actually drive the display I am attempting to use, however I would expect that the 7 inch resistive touch display would stop working, as I have changed the frequency that the display should be expecting. the display; however, has continued working, despite my best efforts.
What is your purpose? Why are you doing this?
The versions of the things I am talking about, Zimage, Dtb, etc… are whatever the latest were I could pull and build following
For the first test, the best is use a regular Bsp and change the resolution of screen as it is described here.
Could you provide the complete dmesg log in a file and the output of fbset and xrandr?
Please share also your Software Information ( uname -a )?
Thanks and best regards,
Jaski
Hello Jaski,
The Resistive Touch 7" does work. I am attempting to make it stop working to verify that the changes I am making are having some effect on the system.
The display I am attempting to use is this
https://www.mouser.com/datasheet/2/271/Microtips_Technology-8-1-2017-MTD0350SZG_SPEC1-1181533.pdf
I got the settings for frequency, etc, from this display
and this git repo,
https://github.com/crystalfontz/cfa_10036_kernel/commit/e7c878e59b0c0f49295e2b4ee07ead507e0d3d43
I do apologize for my lack of experience on this, this is my first foray into embedded linux, so its possible I am doing something simple incorrectly.
What is your purpose? Why are you doing this?
I am attempting to make sure that the changes I am making to the device tree are indeed changing the system. if it makes the original display stop working, that is a good indicator that at least I’m messing with the correct spot.
root@b2qt-colibri-imx7:~# fbset
mode "480x640-60"
# D: 24.250 MHz, H: 39.885 kHz, V: 59.977 Hz
geometry 480 640 480 640 16
timings 41237 64 16 12 3 48 10
accel false
rgba 5/11,6/5,5/0,0/0
endmode
root@b2qt-colibri-imx7:~# xrandr
-sh: xrandr: command not found
root@b2qt-colibri-imx7:~# uname -a
Linux b2qt-colibri-imx7 4.9.166-dirty #2 SMP Thu Apr 11 13:19:44 PDT 2019 armv7l armv7l armv7l GNU/Linux
root@b2qt-colibri-imx7:~#
without xrandr, I am unsure how to set the display settings, technically there is the display uboot env variable, but that doesn’t seem to have some of the settings being used in the device tree.
Thanks,
Nate Hinshaw
Hi @Nhinshaw
I don’t see how the Mouser Display is related to the CrystalFontz Display. I would recommend you to install the regular Lxde Bsp Image on the module and set up the resolution of your display in U-Boot as explained here. Once this is working, then you can look further in the b2QT Image.
Hello @jaski.tx
I started working toward that, I am now booting to the LXDE image, the issue I’m still getting is that no matter what I set in the timing as far as clock frequency, hactive, hback-porch, etc, the actual device does not seem to change those values. my device tree looks like
&lcdif {
display = <&display>;
status = "okay";
display: display {
bits-per-pixel = <32>;
bus-width = <18>;
display-timings {
native-mode = <&timing0>;
timing0: timing0 {
clock-frequency = <25888889>;
hactive = <480>;
vactive = <640>;
hback-porch = <5>;
hfront-porch = <5>;
vback-porch = <2>;
vfront-porch = <2>;
hsync-len = <5>;
vsync-len = <2>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <1>;
};
};
};
};
but I have tried changing clock-frequency to “1” and the old display still works. either the system is not honoring the frequency I am requesting, or the toradex display has a very high operating range. Perhaps I am doing something wrong.
Thanks for the help,
Nate Hinshaw
Did you clear the U-Boot variable vidargs? If not, then it is normal that the old display is still working, since the configuration of the framebuffer is done by the U-boot parameter as explained here. If you absolutely want to use the device tree parameters, then you need to clear the vidargs variable.
Hello Jaski,
That does appear to at least verify that my device tree changes are working. I am now suspicious of the wiring I physically did for the display I am attempting to drive, so I have sent out for a PCB to replace my jumper wires in case that is the issue. I will get back to this thread in about a week with my findings once that board comes in.
Thank you for your help,
Nate Hinshaw
Thanks for your Input. You can post a copy of your schematic here. Please let us know about your findings.
Hello @jaski.tx,
I have received my new prototype board, and my device tree is now affecting the display correctly. This would lead me to believe the initial wiring was an issue.
The new issue I am running into is that LCD_DAT_23 (Red7) Pin 146 and LCD_DAT_22, (Red6) Pin 144 on the IMx7, seems to be constantly ran to 3.3V. this is red-washing the entire display output. i measured on the colibri evaluation board without my display hooked up, the pin is still 3.3V. this may be escaping the scope of the initial question, but is there a peripheral I am missing that could be running that pin high? Attached is my new device tree, I have changed displays, the new display is working other than the red coming in too strong.
Thanks for the help,
Nate Hinshaw
&lcdif {
display = <&display0>;
status = "okay";
display0: lcd-display {
bits-per-pixel = <32>;
bus-width = <24>;
display-timings
{
native-mode = <&timing_vga>;
timing_vga: 320x240
{
clock-frequency = <6000000>;
hactive = <320>;
vactive = <240>;
hback-porch = <43>;
hfront-porch = <8>;
vback-porch = <12>;
vfront-porch = <8>;
hsync-len = <4>;
vsync-len = <4>;
de-active = <0>;
hsync-active = <0>;
vsync-active = <0>;
pixelclk-active = <1>;
};
};
};
};
The display I am driving is Attached
The jumper board I am using for the display is Attached
J2-J5 have jumpers installed, except for the LED backlight and SPI. RST_PULL and LCD_BIAS are pulled high with 10k.
Also of note, the image is the Toradex Embedded Linux Qt4 Demo With X11 built using openembedded. the rest of the device tree is built from
Build U-Boot and Linux Kernel from Source Code | Toradex Developer Center, the lcdif is the only section changed.
As an answer to the last question I asked, I removed
&pinctrl_gpio3 from
&iomuxc {
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_gpio1 &pinctrl_gpio2 &pinctrl_gpio3 &pinctrl_gpio4
&pinctrl_gpio5 &pinctrl_gpio6 &pinctrl_gpio7>;
and added
&pinctrl_lcdif_dat_24 to
&lcdif {
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_lcdif_dat
&pinctrl_lcdif_ctrl>;
};
now my colors are working correctly.
Thank you for the help in remedying my problems.
Nate Hinshaw
Perfect that it works. Thanks for the feedback.
