Multiple errors after update to 5.10.140-ti-r52

After I upgrade to this kernel I started getting failures related to the universal cape, which I haven’t enabled in uBoot.env. Here are a few of the errors I’m seeing:

gpio-of-helper ocp:cape-universal: Failed to get gpio property of ‘P8_03’
gpio-of-helper ocp:cape-universal: Failed to create gpio entry
gpio-of-helper ocp:cape-universal: Allocated GPIO id=0 name=‘P8_03’

WiFi and Bluetooth also fails, and I’m getting these errors:

[ 61.674997] Bluetooth: hci0: Reading TI version information failed (-110)
[ 61.682009] Bluetooth: hci0: download firmware failed, retrying…
[ 63.723018] Bluetooth: hci0: command 0x1001 tx timeout

This was the update that created the problem (I’m running on BBGW, v1.0)

apt upgrade

Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Calculating upgrade… Done
The following NEW packages will be installed:
libpruio-modules-5.10.140-ti-r52 linux-image-5.10.140-ti-r52
qcacld-2.0-modules-5.10.140-ti-r52 rtl8723bu-modules-5.10.140-ti-r52
rtl8723du-modules-5.10.140-ti-r52 rtl8821cu-modules-5.10.140-ti-r52
The following packages will be upgraded:

Has anyone else had this problem? When I roll back to 5.10.131-ti-r50, everything works fine.


I am assuming here that you were building your own kernel from the linux github link online? Personally, I have not had this issue but I am still new to building.

So, I would not know what Bluetooth actually is used to achieve or even how to install it via the kernel.

But…one thing I did notice is that they have rolling updates/upgrades on kernels if things go smoothly w/in their organization.

I am going to help this fellow w/ LCD touchscreen. Then, I can test this instance. I have a BBGW over here I can test.

Oh! @ridgelift , there were some updates to particular images and kernels. This may be what I am witnessing. /dev/bone/* is where the “symlinked” items are located now. W/out Cape_Universal installed or being used, then those installs and symlinks are not available as they would.


P.S. The P8.03 is a header pin that handles the M3 wakeup MCU if I am not mistaken.

Anyway, I am sure corrections will be made in the light from my current post. One thing I noticed is that on the BBGW, I had some .service files that needed to be repeatedly restarted to have them accessible for use in the FS. If this does not help, I understand. If it sheds some understanding, good. I will keep trying.