Bluetooth Unavailable on Raspberry Pi 4B running Manjaro

I have been running Manjaro for about a year now on the Pi 4B and tbh it’s been really stable and extremely usable until when I decided to do a system upgrade yesterday when Bluetooth suddenly stopped working. I have read through these two threads and noted that there’s been a Bluetooth firmware update not long before:

  • manjaro-arm-update-failed-brcm-patchram-plus-and-pi-bluetooth-conflicting/42902
  • brcm-patchram-plus-conflict-with-pi-bluetooth/37935
    (for some reason the forum doesn’t allow me to attach links but just add forum[dot]manjaro[dot]org/t/)

Anyways, so I went ahead and tried to troubleshoot what might be wrong.

  • bluetoothctl shows no controller available
  • rfkill doesn’t see bluetooth either (it used to have an entry for hci0 before the upgrade)
  • restarting bluetooth.service successfully launches it, but the hardware is still inaccessible (displaying the same symptom as if bluetooth wasn’t attached at all)
  • bluetooth.service and attach-bluetooth.service both enabled

With the above to no avail, I decided to look into attach-bluetooth.service and I noticed all it does is to call brcm_patchram_plus at the boot stage to load the bluetooth firmware so I suspect there’s something wrong in this chain. Indeed, if I do top I can see that process right at the top occupying almost 100% of a cpu core which probably isn’t the expected behavior:
294 root 20 0 1816 496 428 R 99.7 0.0 47:20.73 brcm_patchram_p

In another thread this happened to someone who disabled bluetooth in dtoverlay so I suspected it could be a result of my somewhat heavily modified boot config (leds off by default, gpio enabled, zeroed loglevel). But when I restored everything to stock (removed my custom config and completely reinstalled linux-rpi4, linux-rpi4-headers) the exact same issue persists. Notice that at this point my setup is already when everything’s been switched over to brcm_patchram_plus and I verified this through pacman -Qe (no presence of pi-bluetooth).

uname says I’m currently rocking the latest kernel: Linux pi 5.10.17-1-MANJARO-ARM

As a last resort I tried to switch to the stable branch via pacman-mirrors but it appears there’s no change to my packages (I don’t think I’ve ever switched to unstable/testing before so I should be on stable all along?).

Thanks in advance guys. Any suggestions would be greatly appreciated! :sob:

Okay I’ve just seen this thread and it seems that I’m having a really similar issue.

@Darksky Any insights? The Manjaro version I’m using is updated from the 20.04 image last year, in the process I only installed code and libwidevine from AUR which both reside in userland and shouldn’t affect anything. Apart from that I’ve been updating through stock mirrors all the time and I’m really confused as to what could be causing this. :sob:

Update: switch to the mainland kernel but the issue persists.

Here’s the output from top right after boot:

top - 10:09:24 up 2 min,  1 user,  load average: 1.89, 1.70, 0.74

Tasks: 120 total, 2 running, 117 sleeping, 0 stopped, 1 zombie
%Cpu(s): 10.3 us, 16.0 sy, 0.0 ni, 73.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3806.1 total, 3585.7 free, 79.0 used, 141.4 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3676.5 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                                                                 
308 root      20   0    1816    484    416 R 100.0   0.0   2:40.59 brcm_patchram_p       

Manually executing /usr/bin/brcm_patchram_plus --patchram /usr/lib/firmware/updates/brcm/BCM4345C0.hcd --baudrate 3000000 --enable_hci --use_baudrate_for_download --no2bytes --tosleep=1000000 /dev/ttyAMA0 leads to a complete freeze unless I Ctrl+C out of it.

uname now reports this: Linux pi 5.11.0-3-MANJARO-ARM

Also, thought it might be worthwhile to mention, here’s the output of
sudo pacman -Qe | grep linux

linux-rpi4-mainline 5.11.0-3
linux-rpi4-mainline-headers 5.11.0-3

Now I’m trying to update yay to get pi-bluetooth from AUR and see if that changes anything.

Okay the 100% CPU problem was solved as expected but it didn’t improve anything.

Apparently the firmware folder back then was /etc/firmware but somehow the actual firmware file gets removed by another existing package in the current release so I had to switch back to brcm_patchram_plus and nothing’s changed.

Grrrrrr after a whole day scratching my head I finally found the culprit. Thanks @Darksky for your comment on another thread that eventually points me to the correct direction.

It wasn’t pi-firmware or pi-bluetooth. As it turns out there was a change in the bootloader (/boot/config.txt & /boot/cmdline.txt) and somehow the file didn’t get updated because of my custom dual boot setup with Raspbian (basically there are three partitions on my SD card and I made it so that it automatically tars the current /boot and backs it up when I need to switch OS in the next boot). Reinstalling linux-rpi4 didn’t change anything because it never touches that offending line in /boot/cmdline.txt and I was too stupid to realize it was the package raspberrypi-bootloader that corrects it.

Anyhow, appreciate that comment in the other thread @Darksky!

Should have made it a PSA tho considering there’s a fair amount of people that modify /boot/cmdline.txt for various reasons lol. This feaked me out because originally I set it up so that it automatically creates a bt-pan network that only authenticates with my devices allowing headless remote control whilst Wi-Fi is enabled and when bluetooth died I lost my only way to control it aside from manually attaching it to a keyboard/ethernet cable haha

The older kernels would overwrite /boot/cmdline.txt / config.txt. Since a overwhelming number of people make custom changes in the files and had to reset them after each kernel upgrade they requested that their files did not get overwritten. So these files do not get installed with the kernel package it’s self any more but the post_install() / post_upgrade() functions in the .INSTALL checks if they exist and only creates the files if they do not.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.