VOXL2 kernel rebuild: GPIO sysfs does not work
-
Hi, I need to add a new USB device to usb core driver: hub.c
I can modify it and rebuild a new kernel successfully, but after flashing it I cannot use gpio sysfs anymore.
The interface is present, but when attempting to write on /sys/class/gpio/export file it returns me with this error:voxl2:/$ echo 131 > /sys/class/gpio/export bash: echo: write error: Invalid argument
Kernel version is:
voxl2:/$ uname -a Linux m0054 4.19.125 #1 SMP PREEMPT Fri Apr 12 14:07:33 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux
I am building from kernel GIT repo on branch qrb5165-ubun1.0-14.1a
Also command voxl-gpio read/write returns error
voxl2:/$ voxl-gpio read 131 ERROR: Invalid GPIO direction for pin 131: got 0 ERROR: Failed to open path /sys/class/gpio/gpio1231/value ERROR reading from pin number : 131 (got -1, expected 0 or 1
According to documentation it should work
https://docs.modalai.com/voxl-gpio-io/#manipulating-gpio-using-linux-commandsThanks in advance
Enrico -
Hi @enrico-bandera-0 ,
We've done some work in this area in both the user space application and kernel/rootfs, can you let me know what version you are on?
From our downloads, thisi s the latest:
VOXL2 SDK 1.1.3 voxl2_SDK_1.1.3.tar.gz 2/26/2024, 9:28:46 AM
The voxl-gpio-mod out of tree kernel module is handling initialization, can you grep status?
dmesg | grep voxl-gpio-modThanks,
Travis -
Hi @modaltb ,
thank for your reply.
I have installed the latest SDK, 1.1.3 same you mentioned.
Then rebuild the kernel and flashed.
The output of dmesg |grep voxl is following:[ 24.177791] voxl_fsync_mod: disagrees about version of symbol module_layout [ 24.185953] voxl_gpio_mod: disagrees about version of symbol module_layout [ 24.194024] voxl_platform_mod: disagrees about version of symbol module_layout [ 32.003105] voxl_gpio_mod: disagrees about version of symbol module_layout [ 32.004019] voxl_fsync_mod: disagrees about version of symbol module_layout [ 32.016895] voxl_platform_mod: disagrees about version of symbol module_layout
Original kernel replies with following output:
[ 2.383515] voxl_fsync_mod_init [ 2.383703] voxl_fsync_probe [ 2.383801] voxl_fsync_probe : OK [ 2.384617] voxl-gpio init [ 2.385049] voxl_gpio_probe [ 2.385143] voxl-gpio: gpio0 - output, high [ 2.385163] voxl-gpio: gpio1 - output, high [ 2.385187] voxl-gpio: gpio53 - output, high [ 2.385209] voxl-gpio: gpio56 - output, high [ 2.385231] voxl-gpio: gpio57 - output, high [ 2.385251] voxl-gpio: gpio85 - output, high [ 2.385269] voxl-gpio: gpio86 - output, high [ 2.385291] voxl-gpio: gpio87 - output, high [ 2.385309] voxl-gpio: gpio88 - output, high [ 2.385327] voxl-gpio: gpio89 - output, high [ 2.385345] voxl-gpio: gpio124 - output, high [ 2.385364] voxl-gpio: gpio152 - output, high [ 2.385382] voxl-gpio: gpio157 - output, high [ 2.385403] voxl-gpio: gpio159 - output, high [ 2.385423] voxl-gpio: gpio36 - output, low [ 2.385442] voxl-gpio: gpio37 - output, low [ 2.385463] voxl-gpio: gpio46 - output, low [ 2.385483] voxl-gpio: gpio54 - output, low [ 2.385503] voxl-gpio: gpio55 - output, low [ 2.385522] voxl-gpio: gpio67 - output, low [ 2.385549] voxl-gpio: gpio82 - output, low [ 2.385564] voxl-gpio: gpio83 - output, low [ 2.385581] voxl-gpio: gpio84 - output, low [ 2.385603] voxl-gpio: gpio131 - output, low [ 2.385623] voxl-gpio: gpio153 - output, low [ 2.385643] voxl-gpio: gpio154 - output, low [ 2.385663] voxl-gpio: gpio155 - output, low [ 2.385686] voxl-gpio: gpio48 - input [ 2.385705] voxl-gpio: gpio49 - input [ 2.385728] voxl-gpio: gpio50 - input [ 2.385744] voxl-gpio: gpio51 - input [ 2.385763] voxl-gpio: gpio52 - input [ 2.385765] voxl-gpio probe complete [ 2.386275] voxl-platform init [ 2.386369] voxl_platform_probe [ 2.386416] voxl-platform: Machine: - ID - 1 [ 2.386418] voxl-platform: Variant: - ID - 0 [ 2.386419] voxl-platform probe complete
-
I think it's because the kernel is built as a 'debug' kernel, whereas the KO is not, in this case. To build the perf kernel, see usage here:
https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel-build-docker/-/blob/qrb5165-ubun1.0-14.1a/bin/qrb5165-build.sh?reef_type=heads#L136Alternatively, you can rebuild voxl-gpio-mod with debug flags, namely replace:
bitbake qti-ubuntu-robotics-image -fc do_make_bootimg
with
bitbake voxl-gpio-mod
When the build is finished,
find / -name voxl-gpio-mod.ko
to locate and you can replace the one on target.--- another approach for me --- is likely to see how to build these modules IN TREE to avoid this.... I will begin to research this.
-
@modaltb ok, thanks, actually building in perf mode solved the gpio issue.
We need to detect usb HUB TI TUSB8041.
This is enabled by GPIO131, and now the kernel enumerates itBus 002 Device 002: ID 0451:8140 Texas Instruments, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
But no devices were linked to it.
dmesg output reported following messages:
[ 28.656134] usb 1-1: new low-speed USB device number 2 using xhci-hcd [ 28.776276] usb 1-1: device descriptor read/64, error -71 [ 29.000256] usb 1-1: device descriptor read/64, error -71 [ 29.224480] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd [ 29.241526] usb 2-1: New USB device found, idVendor=0451, idProduct=8140, bcdDevice= 2.00 [ 29.241541] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 29.360270] usb 1-1: new low-speed USB device number 3 using xhci-hcd [ 29.450776] hub 2-1:1.0: USB hub found [ 29.451044] hub 2-1:1.0: 4 ports detected [ 29.480718] usb 1-1: device descriptor read/64, error -71 [ 29.704270] usb 1-1: device descriptor read/64, error -71 [ 29.808495] usb usb1-port1: attempt power cycle [ 30.440376] usb 1-1: new low-speed USB device number 4 using xhci-hcd [ 30.440852] usb 1-1: Device not responding to setup address. [ 30.644893] usb 1-1: Device not responding to setup address. [ 30.848259] usb 1-1: device not accepting address 4, error -71 [ 30.968127] usb 1-1: new low-speed USB device number 5 using xhci-hcd [ 30.968591] usb 1-1: Device not responding to setup address. [ 31.172610] usb 1-1: Device not responding to setup address. [ 31.376137] usb 1-1: device not accepting address 5, error -71 [ 31.376368] usb usb1-port1: unable to enumerate USB device [ 33.761006] vdd_tof: disabling [ 33.761012] vdd_hap_boost: disabling
How can we correctly detect?
Thanks for your help.
Enrico -
Does this device (TUSB8041) enumerate normally in the 'stock' kernel/rootfs? E.g. if you have our production SDK release loaded does it show up?
Thanks,
Travis -
@modaltb
no, it behaves the same and returns the identical error message on dmesg. -
OK got it. You alluded to this, modifying something like hub.c
(Generally if it's not showing up, we need to find some flags to add. For example, we added some USB modems like this:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/patches/005-telit-option.patch
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/patches/004-quectel-usb-wwan.patch
)We'll likely need to find similar for TUSB8041 and then try to add if it's not showing up by default.
Are you plugging this TUSB8041 hub into a USB port or using custom hardware?
Have you located anything from TI that tells us what flags to enable? That's where I'd go next, see if vendor has clues and then we can try it out.
-