Shortcut to patch device tree within Toradex build system?

I am new to building linux for embedded systems.

I have an LCD module with an ST1633i touch panel controller attached to a Viola carrier board and a Colibri iMX6 SoM. I have built the angstrom-qt5-x11-image recipe, and I have loaded the image onto the target device. I have a Qt5 application that runs on the target.

I have everything working except for the touch panel.

One step in the procedure at says to uncomment a line in a device tree file:

#define PCAP

A hack way to do it might be to edit the .dts file in the build/tmp-glibc/work-shared/... tree, and then rebuild. But, I don’t know bitbake well enough to know what command will build the image using the changed source file. The default command doesn’t do it.

Instructions in this video (Webinar On-Demand: Part 2 (Advanced) - Building Embedded Linux Images with the Yocto Project - YouTube) would have me define multiple new layers and new recipes and a new machine type and I forget what else. But, the video is out-of-date with respect to the latest build system, and I haven’t learned enough bitbake to apply the instructions to the new system.

I’m trying to learn how bitbake and the build system work, but I’ve got a hard deadline, and I’m running out of time.

Isn’t there some easy way to patch arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts and then re-build?


While one could go your approach of stopping in the middle of building the kernel with bitbake, make changes to the configuration / sources and then continue building an image, this is not what we recommend.

Your changes may be overwritten if bitbake thinks it need to unpack the kernel again or your changes might never be compiled into the kernel because bitbake does not know that anything changed.

When working with the kernel we recommend developing the kernel outside of Openembedded. Once you know what must be changed create patches and apply these to the kernel recipe.

Note that the #define PCAP you reference is meant for the Fusion 7" and 10" panels with capacitive touch that we have in the webshop. For the touch controller on these panels the kernel already has the required drivers compiled in and the #define changes some pinmuxing and I2C device configuration.

You will need to find what linux kernel option you need to enable for your touch controller (assuming there is one in the kernel). Then you will need to adapt the device-tree depending on the specific requirements of that driver and your HW connection to the touch controller .

Possibly this community entry could be helpful.


Max, I’m still hoping for an answer to my question.

Regardless of whether your driver will work with the display, or whether I need to use the driver provided by the display’s manufacturer, I still would like to know how I can #define the PCAP symbol in arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts, within the framwork of BitBake.

In my latest attempt, I created a new layer that added a file:


That seemed promising except that when the build system attempted to apply my patch, the imx6dl-colibri-eval-v3.dts file did not exist anywhere within the working tree. Maybe I appended the wrong recipe, but if so, then how do I know which recipe is the correct one to extend? Or, if not, then what’s the right way to solve my problem?

You suggested that I build the kernel outside of BitBake, but I don’t just need a kernel, I need a whole device image with a sysroot and all. BitBake seems a convenient, automated way to create that, if only I could persuade it to change the one line in the device tree.


You would first need to find what recipe builds the kernel for your machine which would be in the meta-toradex-nxp/conf/machine/.conf file for your machine. (if in the meta data version you use that file does not exist it will fall back to meta-fsl-arm/conf/machine/.conf.

Search for PREFERRED_PROVIDER_virtual/kernel ?= "linux-toradex"

So linux-toradex_%.bbappend should really append to that recipe.

Then, if you create a new layer you have to add it the layers which get actually parsed, e.g. edit build/conf/bblayers.conf and add your layer.

Then I would check if your bbappend does really change something, e.g. run bitbake virtual/kernel -e > kernel.txt. Assuming that you add to SRC_URI in your bbappend you could search for SRC_URI in the resulting kernel.txt and check if your addition has been picked up.