We have managed to build and enable overlays according to:
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.
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.
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?
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.
Once you locate the source in the kernel look at the overlay and make these changes.
Create a patch file with git.
Integrate this patch file into Yocto via the kernel recipe. Yocto automatically applies patch files in layers against the source at build time.
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?
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.
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?
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
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.
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):