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.
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.
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 .
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.
