I’m stuck on trying to regain control of a gpio pin which had previously been taken by a driver at boot time.
This is on a beaglebone black with a 4D display cape. The problematic driver is for the touch panel, and the pin is pin p9.26, which is the touch interrupt pin. I want to use this instead for CAN.
I have disabled the driver using unbind, but then trying to reassign the pin with config-pin, the error is:
ERROR: open() for /sys/devices/platform/ocp/ocp:P9_26_pinmux/state failed, No such file or directory
I dont want to use this driver at all. My userspace driver is working fine without using the interrupt so I’ll just cut the trace on the cape leading to that pin. If I want to use the interrupt at a future time, I can simply reroute it to a different pin.
Possible solutions:
Permanently prevent the driver from loading at boot (edt_ft5x06).
Edit the dtb to disable the touch configuration. (BB-BONE-4D5C-01-00A1.dtbo)
Do something to bring the pin back under the control of the config-pin command.
The only google results I found for disabling a module at boot time are for desktops and don’t seem applicable to the BBB.
Recompiling a .dts to a .dtbo seems to have changed recently an I havn’t found instructions that work for the new way. dtc seems to barf on the #include directive. I did find one article that seemed to suggest that I would need to basicly build a custom kernel, which doesnt seem quite right.
Can anyone offer advice on a best approach, or how to achieve this?
It’s been a while since I did anything with a BBB, but things to check.
It is probably that a DTS overlay is being loaded by uboot for the touchscreen driver. If so you can start by removing this. If you have the serial console connected you should see if this is the case.
If you want to use the pin for CAN you will probably need to set up the pin muxing and will need to make a DTS overlay, or modify the root DTS.
You don’t need to compile a custom kernel for this, but you will probably need the kernel source, hence the failure on the #include. You can just compile the DTS files by doing a ‘make dtbs’ after adding your custom file to the Makefile. You don’t need to compile the kernel.
Mostly because the overlays are an undocumented, poorly debuggable, impenetrable mess of files with weird syntax.
Overlays are the automake of the embedded Linux ARM world. Everybody copies a “working” script, changes a few bits, types a few magic commands, and prays to their favorite deity in the hopes that the result will do something useful because they can’t possibly figure it out if it doesn’t.
Big Thank you to Benedict and Robert for pointing me in the right direction. For future reference, here are the steps I took to make this work.
git clone https://github.com/beagleboard/linux.git
cd linux
git checkout 5.10
make omap2plus_defconfig
copy edited .dts into arch/arm/boot/dts/overlays/
make dtbs
copy resulting .dtbo into /lib/firmware/
However there were many hickups and roadblocks along the way. Here are just some:
The git archive is 4Gb - make sure there is room on the SD card.
Downloading the archive choked on the BBB part way through while cross compiling on Ubuntu failed, so I downloaded it on Ubuntu then copied it across to the BBB.
The .dts didn’t exist in the archive, so I copied it from the distribution then updated the Makefile.
One of the headers wasn’t found in the include path, but it did exist elsewhere in the archive, so I just copied it into the expected location.
(Pretty much just as Buzmeg described it … Huge relief when it did finaly work.)
Edit: seems most of the above is unnecessary - see reply below. I could simply have typed make in /opt/source/bb.org-overlays …
As a side note; I had hoped that this might prevent the loading of the ft5x06 driver, as well as preventing the capture of the pin at boot, however the driver does still appear to be loading. I dont appear to need to issue the unbind command to the driver any more, but I think it’s probably dumb not to.