I have tried to load the driver using the modprobe instruction as explained here, but I can’t seem to get it to do anything.
I have opened the touchscreen location and tried the modprobe fusion_F0710A command but I get no response. It just skips to next line with a prompt - no error or anything. I’m guessing that I should expect a response like the one that is shown in the instructions (see below).
[ 104.658457] fusion_F0710A 0-0010: Touchscreen registered with bus id (0) with slave address 0x10
[ 104.689688] fusion_F0710A 0-0010: version product 70Z7(1)
[ 104.695219] fusion_F0710A 0-0010: version id 1.4(1)
[ 104.700991] fusion_F0710A 0-0010: version series (1110191)
[ 104.712672] input: fusion_F0710A as /devices/virtual/input/input0
I can browse to the /lib/modules/uname -r/kernel/drivers/input/touchscreen/ location and see that the fusion_F0710A.ko file exists.
My guess is that you mixed up something with the HW connection to the touch controller, (TOUCH_I2C_SCL_3.3V), TOUCH_I2C_SDA_3.3V, TOUCH_INT_3.3V, TOUCH_RESET_3.3V)
When doing the modprobe I would at least expect some output in the kernel log.
E.g. on a system with correctly connected touch screen I expect that dmesg has something like the following at the end after the module got inserted:
root@colibri-imx6:~# dmesg
...
[ 1076.558936] fusion_F0710A 2-0010: Touchscreen registered with bus id (2) with slave address 0x10
[ 1076.560735] fusion_F0710A 2-0010: version product 10Z8(0)
[ 1076.560767] fusion_F0710A 2-0010: version id 1.4(1)
[ 1076.560786] fusion_F0710A 2-0010: version series (1106011)
[ 1076.572691] input: fusion_F0710A as /devices/virtual/input/input5
And that what I expect if no touch screen is connected:
root@colibri-imx6:~# dmesg
...
[ 313.005468] fusion_F0710A 2-0010: Touchscreen registered with bus id (2) with slave address 0x10
[ 313.005730] fusion_F0710A 2-0010: query failed: -5
[ 313.007347] fusion_F0710A: probe of 2-0010 failed with error -5
You could also check with the I2C tools if you can see the touch controller:
root@colibri-imx6:~# rmmod fusion_F0710A
root@colibri-imx6:~# i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@colibri-imx6:~# i2cdump -r 0-0x10 2 0x10
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2, address 0x10, mode byte
Probe range limited to 0x00-0x10.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 01 00 80 04 b6 01 10 00 00 00 00 00 00 00 16 0a ?.?????.......??
10: 00
If the above looks good I2C is connected correctly and likely the reset line also.
So you could reinsert the kernel module and check for interrupts:
No luck though. After verifying the HW touch connections, I tried modprobe fusion_F0710A and still get no response.
I also don’t see any reference to fusion_F0710A in the dmesg output. As expected, cat /proc/interrupts | grep fusion also doesn’t return a response.
I should have mentioned this earlier, but forgot. I am using image version 2.6, not 2.7. I didn’t use 2.7 because I came across a problem when trying to extract files. I will try 2.7 again later today and let you know how things go with it.
modprobe: FATAL: Module fustion_F0710A not found in directory /lib/modules/4.1.35-dirty
Why the -dirty here? Does that mean you are not using our demo image but rather compiled something on your own? If so I suspect you may have missed one or the other step about properly deploying them kernel modules as well.
cd
git clone -b 2016.11-toradex git://git.toradex.com/u-boot-toradex.git
cd u-boot-toradex
make colibri_imx6_defconfig
make -j3 2>&1 | tee build.log
cp ~/u-boot-toradex-2016/SPL /media/chemtrac/UPDATE/colibri_imx6/
cp ~/u-boot-toradex-2016/u-boot.img /media/chemtrac/UPDATE/colibri_imx6/u-boot.imx-spl
Kernel Source
git clone -b toradex_4.1-2.0.x-imx git://git.toradex.com/linux-toradex.git
cd linux-toradex
make colibri_imx6_defconfig
make -j3 uImage LOADADDR=10008000 2>&1 | tee build.log
make imx6dl-colibri-eval-v3.dtb
make -j3 modules
Kernel Update
cd
cp ~/linux-toradex/arch/arm/boot/uImage /media/chemtrac/UPDATE/colibri_imx6
cp ~/linux-toradex/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dtb /media/chemtrac/UPDATE/colibri_imx6
From U-Boot
setenv fdt_file imx6dl-colibri-eval-v3.dtb
saveenv
run setupdate
run update_kernel
run update_fdt
run update
From U-Boot (after flashing)
setenv vidargs ‘video=mxcfb0:dev=lcd,FusionF07A’
savee
print
reset
The above steps will show the display at the proper resolution on the capacitive display. I just can’t use the touch features.
BTW, I’m not sure if I needed to do anything with Kernel Module Deployment referenced here.
Here is how I have the display wired from the adapter board to the Colibri Eval Board.
Adapter: X4/2 to Eval: X9/43
Adapter: X4/3 to Eval: JP24/3
Adapter: X4/4 to Eval: X9/49
Adapter: X4/6 to Eval: X9/48
Adapter: X4/7 to Eval: X9/47
Adapter: X4/8 to Eval: X10/27
Adapter: X4/9 to Eval: X10/28
Adapter: X4/10 to Eval: X10/50
Last thing. Would it be possible to send me a device tree file that shows exactly how it should be configured for a capacitive display with Colibri iMX6DL using a Colbri Eval Board?
Do you have any additional thoughts as why I can’t get the touch to work? If you look above you can see which commands I used to configure the device tree.
Kernel and Kernel Modules have a version which must exactly match.
uname -r shows that version.
By changing the kernel sources (e.g. the device-tree source files) you changed that version (the additional ‘-dirty’). By compiling and deploying only the kernel but not the modules the version between kernel and modules do not match anymore.
So you could:
Since you only changed device-tree files you could go back to your initial kernel binary and try again.
You could build additionally the modules and deploy them along with the new kernel.
You could also cheat and copy the kernel modules to a different path. For cases were you did not really change much that often works. However I do not advise doing so for production code.
depmod
... could not open directory <missing dir> ...
cp -pPr <existing module dir> <missing dir>
depmod
e.g.
depmod
... could not open directory /lib/modules/4.1.35-dirty ...
cp -pPr 4.1.35-v2.7b1+gc117783 /lib/modules/4.1.35-dirty
depmod
I was able to get it to work but sometimes it doesn’t.
I’m wondering if you can tell me exactly where I need to go back to in the Build U-Boot and Linux Kernel from Source Code page after I update the kernel module? Or, which instruction should I start with after I run the sudo -E make INSTALL_MOD_PATH=../Colibri_iMX6_LinuxImageV2.7/rootfs/ modules_install command?
You install the kernel modules to some arbitrary path with sudo -E make INSTALL_MOD_PATH=../Colibri_iMX6_LinuxImageV2.7/rootfs/ modules_install
As already said, if you’re only goal is to get our image working with the Fusion 7" touchscreen you do not need to recompile the kernel and the kernel modules. You only need to change/compile/deploy the device-tree.
Having said that here is my 2 cents on building and deploying the kernel in different phases in your development:
If you are in development mode with your one and only Colibri module:
build kernel/device-tree/modules
deploy kernel/device-tree/modules to the already flashed module
scp arch/arm/boot/uImage root@192.168.10.2:/media/mmcblk0p1/
scp arch/arm/boot/dts/ root@192.168.10.2:/media/mmcblk0p1/
sudo -E make INSTALL_MOD_PATH=/ modules_install
cd ; tar cjvf kernel-modules.tar.bz2 lib/modules/*
scp kernel-modules.tar.bz2 root@192.168.10.2:
On module
cd /; tar xjvf /home/root/kernel-modules.tar.bz2
depmod
reboot
If you are in ‘test a few Colibri modules’ mode:
build kernel/modules/device-tree
deploy kernel/device-tree/modules into an unpacked image
sudo cp arch/arm/boot/uImage …/Colibri_iMX6_LinuxImageV2.7/colibri-imx6_bin
sudo cp arch/arm/boot/dts/ …/Colibri_iMX6_LinuxImageV2.7/colibri-imx6_bin
sudo -E make INSTALL_MOD_PATH=…/Colibri_iMX6_LinuxImageV2.7/rootfs/ modules_install
recreate the update media and use this to flash your Colibri
If you’re in ‘prepare for production’ mode
integrate your changes into the openembedded kernel recipe
