Add overlays to TorizonCore

Hi,

We have managed to build and enable overlays according to:
https://www.toradex.com/community/questions/56286/touch-functionality-on-torizon.html

However, we would like to add these overlays to our TorizonCore image and enable them in our build. How can we do that in Yocto? We have parallel builds in both Zeus and Dunfell but we are primarily working in Zeus.

Greetings @Jacmo,

If you don’t mind may I ask why you would like to use overlays if you’re already building this all in Yocto? What I’m trying to say is, if you already went through the effort of setting up a Yocto build, why not just implement these changes via kernel patches in meta-layers rather than an overlay?

Overlays are a handy tool that let’s you basically “hotfix” the system’s device tree without needing to recompile the image/system as a whole. But if you’re already gonna be building Torizon via Yocto then you might as well patch the device tree at Yocto build time in order to perform these changes.

Best Regards,
Jeremias

If I understand this correctly, could we take the content from the overlay and make a git patch to apply it to the imx8qxp-colibri-eval-v3.dtsi is that all we need to do?

Well not directly let me clarify, here’s what you’d need to do:

  1. Clone the kernel that matches what’s running on your system, you can check your yocto build for the right kernel source/branch or you can also check the tables here: https://developer.toradex.com/knowledge-base/build-u-boot-and-linux-kernel-from-source-code
  2. Find the device tree node that matches what the overlay is changing. In this case you’d look for the panel-dpi node in the i.MX8QXP device tree sources.
  3. Once you locate the source in the kernel look at the overlay and make these changes.
  4. Create a patch file with git.
  5. Integrate this patch file into Yocto via the kernel recipe. Yocto automatically applies patch files in layers against the source at build time.

As an example/reference you can see where we’ve applied similar device tree patches in our meta-layers here: https://github.com/toradex/meta-toradex-torizon/blob/zeus/recipes-kernel/linux/linux-toradex-mainline/0001-Revert-ARM-dts-imx7-colibri-aster-enable-Atmel-multi.patch

Best Regards,
Jeremias

We have changed the file fsl-imx8qxp-colibri.dtsi. The display resolution now works as intended but we could not get the touch controller to work so we need some help with that. Could you take a look at our changes and see if there is anything we have missed?

Here is a diff from our dtsi file:

diff --git a/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi b/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi
index 8c755fae4f22..79d051804591 100644
--- a/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi
@@ -44,17 +44,20 @@
                data-mapping = "bgr666";
 
                panel-timing {
-                       /* Default VESA VGA display timings */
-                       clock-frequency = <25175000>;
-                       hactive = <640>;
-                       hback-porch = <48>;
-                       hfront-porch = <16>;
-                       hsync-len = <96>;
+                       clock-frequency = <33260000>;
+                       hactive = <800>;
                        vactive = <480>;
-                       vback-porch = <31>;
-                       vfront-porch = <11>;
-                       vsync-len = <2>;
-                       pixelclk-active = <0>;
+                       hback-porch = <88>;
+                       hfront-porch = <40>;
+                       vback-porch = <32>;
+                       vfront-porch = <13>;
+                       hsync-len = <48>;
+                       vsync-len = <3>;
+
+                       de-active = <1>;
+                       hsync-active = <0>;
+                       vsync-active = <0>;
+                       pixelclk-active = <1>;
                };
 
                port {
@@ -307,12 +310,6 @@
 
 /* Colibri I2C */
 &i2c1 {
-       #address-cells = <1>;
-       #size-cells = <0>;
-       clock-frequency = <100000>;
-       pinctrl-names = "default";
-       pinctrl-0 = <&pinctrl_i2c1>;
-
        /* Atmel maxtouch controller */
:
                data-mapping = "bgr666";
 
                panel-timing {
-                       /* Default VESA VGA display timings */
-                       clock-frequency = <25175000>;
-                       hactive = <640>;
-                       hback-porch = <48>;
-                       hfront-porch = <16>;
-                       hsync-len = <96>;
+                       clock-frequency = <33260000>;
+                       hactive = <800>;
                        vactive = <480>;
-                       vback-porch = <31>;
-                       vfront-porch = <11>;
-                       vsync-len = <2>;
-                       pixelclk-active = <0>;
+                       hback-porch = <88>;
+                       hfront-porch = <40>;
+                       vback-porch = <32>;
+                       vfront-porch = <13>;
+                       hsync-len = <48>;
+                       vsync-len = <3>;
+
+                       de-active = <1>;
+                       hsync-active = <0>;
+                       vsync-active = <0>;
+                       pixelclk-active = <1>;
                };
 
                port {
@@ -307,12 +310,6 @@
 
 /* Colibri I2C */
 &i2c1 {
-       #address-cells = <1>;
-       #size-cells = <0>;
-       clock-frequency = <100000>;
-       pinctrl-names = "default";
-       pinctrl-0 = <&pinctrl_i2c1>;
-
        /* Atmel maxtouch controller */
        atmel_mxt_ts: atmel_mxt_ts@4a {
                compatible = "atmel,maxtouch";
@@ -320,10 +317,10 @@
                pinctrl-0 = <&pinctrl_mxt_ts>;
                reg = <0x4a>;
                interrupt-parent = <&gpio3>;
-               interrupts = <20 IRQ_TYPE_EDGE_FALLING>;        /* SODIMM 107 */
-               reset-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;     /* SODIMM 106 */
-                status = "disabled";
-        };
+               interrupts = <20 IRQ_TYPE_EDGE_FALLING>;        /* SODIMM 107 */
+               reset-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;     /* SODIMM 106 */
+               status = "okay";
+       };
 };
 
 &iomuxc {
@@ -809,11 +806,11 @@
                };
 
                pinctrl_mxt_ts: mxt-ts {
-                       fsl,pins = <
-                               SC_P_QSPI0B_DATA2_LSIO_GPIO3_IO20               0x20            /* SODIMM 107 */
-                               SC_P_QSPI0B_SS1_B_LSIO_GPIO3_IO24               0x20            /* SODIMM 106 */
-                       >;
-               };
+                       fsl,pins = <
+                                SC_P_QSPI0B_DATA2_LSIO_GPIO3_IO20               0x20            /* SODIMM 107 */
+                               SC_P_QSPI0B_SS1_B_LSIO_GPIO3_IO24               0x20            /* SODIMM 106 */
+                       >;
+                };
        };
 };

Let’s see if I understand this diff correctly then did you remove these lines from the i2c1 node?

  •   #address-cells = <1>;
    
  •   #size-cells = <0>;
    
  •   clock-frequency = <100000>;
    
  •   pinctrl-names = "default";
    
  •   pinctrl-0 = <&pinctrl_i2c1>;
    

If so then you shouldn’t remove this. To clarify a device tree overlay only adds/overwrites properties it never removes properties that were already there in the base device tree source. So just because the device tree overlay doesn’t reference it doesn’t mean you need to remove it.

Also for the pinctrl_mxt_ts node please make sure you add it under the colibri-imx8qxp node which is under the iomuxc node.

Best Regards,
Jeremias

Okay, we readded the lines you mentioned but it didn’t help. So here are our changes. Is there anything else we have to do?

/* Colibri I2C */
 &i2c1 {
+       
        #address-cells = <1>;
-       #size-cells = <0>;
-       clock-frequency = <100000>;
-       pinctrl-names = "default";
-       pinctrl-0 = <&pinctrl_i2c1>;
+        #size-cells = <0>;
+        clock-frequency = <100000>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&pinctrl_i2c1>;
 
        /* Atmel maxtouch controller */
        atmel_mxt_ts: atmel_mxt_ts@4a {
@@ -320,10 +324,10 @@
                pinctrl-0 = <&pinctrl_mxt_ts>;
                reg = <0x4a>;
                interrupt-parent = <&gpio3>;
-               interrupts = <20 IRQ_TYPE_EDGE_FALLING>;        /* SODIMM 107 */
-               reset-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;     /* SODIMM 106 */
-                status = "disabled";
-        };
+               interrupts = <20 IRQ_TYPE_EDGE_FALLING>;        /* SODIMM 107 */
+               reset-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;     /* SODIMM 106 */
+               status = "okay";
+       };
 };
 
 &iomuxc {
@@ -809,11 +813,11 @@
                };
 
                pinctrl_mxt_ts: mxt-ts {
-                       fsl,pins = <
-                               SC_P_QSPI0B_DATA2_LSIO_GPIO3_IO20               0x20            /* SODIMM 107 */
-                               SC_P_QSPI0B_SS1_B_LSIO_GPIO3_IO24               0x20            /* SODIMM 106 */
-                       >;
-               };
+                       fsl,pins = <
+                                SC_P_QSPI0B_DATA2_LSIO_GPIO3_IO20               0x20            /* SODIMM 107 */
+                               SC_P_QSPI0B_SS1_B_LSIO_GPIO3_IO24               0x20            /* SODIMM 106 */
+                       >;
+                };
        };

It’s getting a little hard to tell what exactly your device tree looks like just off the diffs. Could you please share a copy of the device tree source file(s) you’ve changed so I can review?

Right now just looking at the diffs the only thing I can notice is that it seems you don’t have pinctrl-names = "default"; line included under the atmel_mxt_ts like in the original overlay. Other than that do you get any logs/messages in dmesg when you boot the system with this device tree? Anything in there related to the touch driver/atmel?

Best Regards,
Jeremias

Okay, I´ll attach our device tree files that we have modified.

Here are the outputs from dmesg related to touch that we found:

colibri-imx8x-v10b-06614388:~$ dmesg | grep i2c
[    0.038422] dma_lpi2c0 : no governor for states
[    0.038428] dma_lpi2c1 : no governor for states
[    0.038435] dma_lpi2c2 : no governor for states
[    0.038441] dma_lpi2c3 : no governor for states
[    0.038728] cm40_i2c : no governor for states
[    0.038797] mipi0_dsi_i2c0 : no governor for states
[    0.038803] mipi0_dsi_i2c1 : no governor for states
[    0.038846] mipi1_dsi_i2c0 : no governor for states
[    0.038853] mipi1_dsi_i2c1 : no governor for states
[    0.038892] mipi_csi0_i2c0 : no governor for states
[    0.038913] parallel_csi_i2c : no governor for states
[    0.411823] i2c i2c-16: LPI2C adapter registered
[    0.413741] i2c i2c-17: LPI2C adapter registered
[    0.415132] i2c i2c-18: LPI2C adapter registered
[    1.515676] i2c /dev entries driver

fsl-imx8qxp-colibri.dtsi

fsl-imx8qxp-colibri-eval-v3.dtsi

Actually quick question now that I’m looking at your device tree vs the source device tree. You’re on 4.0 Torizon and therefore the 4.14 kernel correct? I ask because when I look at our 4.14 source the i2c1 subnode for touch is already there it’s just disabled: http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi?h=toradex_4.14-2.0.x-imx#n309

So why did it look like you had to add these in your diffs? The only change needed would be to enable this atmel node.

That being said your device trees don’t look wrong. Perhaps then the reason is that the Atmel driver is included in our Linux kernel as a module. Maybe it’s just not loaded, you can try modeprobe atmel_mxt_ts to load it, in that case.

Best Regards,
Jeremias

The module was not loaded automatically. We tried to load the atmel_mxt_ts module via modprobe and we have also included it in /etc/modules-load.d to make sure that it started at boot. We have checked that the module is loaded but the touch functionality still doesn’t work.

Alright I made the patch myself on my own setup. It seems the pins used for the I2C touch are being used by another interface causing a conflict and for the driver to fail initialization.

The following patch successfully brought up touch on my 4.0 Torizon setup (this patch only includes the touch changes and not resolution/display changes):

diff --git a/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi b/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi
index 8c755fae4f22..a57eabd8c5b5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi
@@ -322,14 +322,14 @@
                interrupt-parent = <&gpio3>;
                interrupts = <20 IRQ_TYPE_EDGE_FALLING>;        /* SODIMM 107 */
                reset-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;     /* SODIMM 106 */
-                status = "disabled";
+                status = "okay";
         };
 };
 
 &iomuxc {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_hog0>, <&pinctrl_hog1>, <&pinctrl_hog2>,
-                       <&pinctrl_ext_io0>, <&pinctrl_mxt_ts>;
+                       <&pinctrl_ext_io0>;
 
        colibri-imx8qxp {
                /* On-module touch pen-down interrupt */

As a side note if you see the following or similar errors on boot:

[    8.735234] atmel_mxt_ts 17-004a: __mxt_read_reg: i2c transfer failed (-110)
[    8.747689] atmel_mxt_ts 17-004a: Failed to read 67 messages (-110)

Go and try touch first. Sometimes these errors don’t actually mean touch isn’t working like in my case.

Best Regards,
Jeremias