IMX8X Device Tree Overlay for Capacitive Touch Screen Display (5.7")

Greetings Support,
Thank you in advance for your help.
I currently have a Hantronix capacitive touch display (640x480 RGB) that works with my T30 SoM. I just installed the Qt eval image on the IMX8X and attempted to plug it into said display but the display did not work. When using the VGA port to my desktop monitor, it works fine. I originally thought this was a driver issue, but am now considering Device Tree Overlay or Rebuilding the image, however tech support thinks I should. Thanks again!

-Nick

Please refer to these materials:

Alex,
I was able to run the revcovery-windows.bat and revert from Qt boot to a Linux Reference Image. I have adjusted my overlays.txt file to be the following:

fdt_overlays=colibri-imx8x_parallel-rgb_overlay.dtbo colibri-imx8x_ad7879_overlay.dtbo colibri-imx8x_vga-640x480_overlay.dtbo

However, upon using the vi editor within the system I am seeing the default values. That is when typing vi /boot/overlays.txt, I am seeing:

fdt_overlays=colibri-imx8x_parellel-rgb_overlay-dtbo colibri-imx8x_ad7879_overlay.dtbo display-vga_overlay.dtbo

I have tried to edit this using the vi and cat commands, but have not been successful.
Please advise. I am still seeing a white screen on my 5.7" capacitive touch display, which makes me think I am getting no signal. Please advise.

Could you please describe how did you adjusted your overlays.txt file on the firs step?
and which exactly reference image you’ve flashed?

I have flashed the colibri-imx8x_reference Minimal-Image 5.7.5+build 27.

I changed the overlays.txt file using notepad on my host computer, then replaced it in the /boot folder of the development board using WinSCP to be the following:
fdt_overlays=colibri-imx8x_parallel-rgb_overlay.dtbo colibri-imx8x_ad7879_overlay.dtbo display-edt5.7_overlay.dtbo

I am trying to follow the article that you previously linked and am stuck at this part:

  1. Write a Device Tree Overlay (.dts) file.
  2. Compile the .dts file to generate a .dtbo file.
  3. Enable the overlay (using the .dtbo file)

I am unsure just how to perform any of these steps. I have tried to adjust the overlays.txt file to include many different permuatations of the already existent .dtbo files.
Please advise.

Thank you kindly,
Nick

EDIT: Previously had issues with display, determined to be connection issue.

Are you referring to the console on a VGA display or a UART console? How were you able to use the vi editor without access to a console?

You won’t see any image on your 5.7" display until you configure the correct overlay, with resolution and timings that match your display’s parameters.

The colibri-imx8x_parallel-rgb_overlay.dtbo is designed to enable the parallel RGB interface but does not include the required timings. The colibri-imx8x_ad7879_overlay.dtbo is intended for enabling the resistive touch controller; it’s not suitable for capacitive touch displays and does not alter display output settings. Meanwhile, the colibri-imx8x_vga-640x480_overlay.dtbo provides timings and resolution for VGA (640x480), but I doubt it fully matches the parameters needed for your 5.7" capacitive touch display.

Consider using the colibri-imx8x_panel-cap-touch-7inch_overlay.dts as a starting point. You’ll need to modify the resolution and timings (found in display-lt161010_overlay.dtsi), compile it as described here, then enable it as listed here .

Alex,
I am hoping to follow the instructions here but am currently unable to find a version of the files that he references in his post. Namely, I need to include the “colibri-imx8x_panel-cap-touch-7inch_overlay.dtbo”. As you can see in the following photo, I seem to have the other requisite files:

I see that you sent a link to the root/overlays/colibri-imx8x_panel-cap-touch-7inch_overlay.dts file, but I do not know how to turn this into a .dtbo file. Please advise. Thanks for your patience.
Best,
Nick B.

You need to compile it as described here.

1 Like

Okay, I have changed the overlays.txt and typed sync and just rebooted by typing reboot into the console but now the unit does not come back online, even with a power cycle. Please advise.

P.S. You are so patient and kind. Thank you…

When you mention the ‘unit does not come back online,’ are you indicating that the display shows no output, or that the unit does not produce any output on a debug UART?

Alex,
Sorry for the late response, I have been busy trying something from another post. One post mentioned that I should use an Upstream version like the Toradex Embedded Linux Reference Multimedia Image Version 5.7.5 + build.27. After trying to use this, it became apparent that I would not be able to run the sync and the reboot commands after updating the overlays.txt file, since there was no console to run it with. However, I am now on back on the Toradex Embedded Linux Reference Minimal ImageVersion 5.7.5 + build.27 version.

Relevant Changes:
overlays.txt Updated: fdt_overlays=colibri-imx8x_panel-cap-touch-7inch_overlay.dtbo
File /boot/overlays/ Updated: Now has the appropriate .dtbo folder. Did not have colibri-imx8x_panel-cap-touch-7inch_overlay.dtbo previously
Command Line Input: root@colibri-imx8x-14791658: ~# sync
root@colibri-imx8x-14791658: ~# reboot

After performing these steps I plugged my IMX8X SoM into my unit to test the 5.7" capacitive touch display. Unfortunately, I am still seeing the white screen. I do not see any .dtsi files in the /boot/overlays folder, so I will now attempt to create one from scratch with the title: display-lt161010_overlay.dtsi and I will attempt to modify the resolution and timing in this file as you mentioned previously.

Warmest Regards,
Nickolas B.

I’m still confused - when you mention “no console,” what exactly are you referring to? Every image pre-built by Toradex includes a serial debug console. If your carrier board is connected to the local network, you can also utilize SSH for console access

Device tree files with dts or dtsi extensions are source files and you need to build a Device Tree BLOB or overlay before you can use it. Please refer to this link.
Please also familiarize yourself with the general information about the Device Tree.

Alex,
By “no console” I simply mean that I was unsure how to use the serial debug when it doesn’t automatically appear on the display which is plugged into the VGA port of the evaluation kit. I was not aware that there was SSH console access, however I am mostly interested in looking at the serial debug output via my host computer so that I can interrupt the console on boot and be able to process commands when there is a GUI.

I have read the Device Tree Documentation Overview. Thank you for that, it has helped me to understand what I am doing. I am now moving on to the following article:

I apologize for being such a noob at this, it is my first time dealing with Linux, Kernel, or Device Trees.
Your patience and kindness has done wonder in getting me this far.

Highest Regards,
Nick B.

The serial debug console operates independently of any display connected to the system. It utilizes UART communication and does not depend on the video subsystem.

Alex,
Thank you for that. I will be sure to configure the UART access.
I am unsure if I am downstream or upstream, and which git to access for step 1 of the “First Steps with Device Trees” article that I linked above. The article states:
" 1. Choose the base device tree that matches the hardware platform. Toradex provides a set of base device trees for its hardware platforms that can be found in:

I am not sure which to access. Please advise.

Best,
Nick B

The choice between using an upstream or downstream kernel should align with your specific needs. A downstream kernel is tailored based on the Linux version provided by NXP and offers enhanced support for NXP System-on-Chip (SoC) peripherals. However, it may lack the most recent features available in the broader Linux kernel community. On the other hand, if your application requires the latest enhancements and features introduced by the community, an upstream-based kernel is the preferable option. In cases where compatibility with NXP SoC peripherals is a priority and the latest kernel features are not essential, I recommend opting for a downstream approach.