Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: Juanito on August 12, 2026, 08:46:48 AM
-
Testing the onboard bluetooth device on an RPi5.
If I use the first of the scripts below, bluetooth starts successfully (the script doesn't return the cursor) and I can use blueman to search for/pair bluetooth headphones and play music through them from the RPi5 using xmms-pulse/pavucontrol.
If I add the second of the scripts below to the end of the first script, bluetooth starts successfully, but blueman will not start with the error that it cannot find the gir files from networkmanager - an extension that does not exist on piCore64.
I'm somewhat baffled by this - what is it about the second script that makes blueman look for networkmanager?
#!/bin/sh
sudo /usr/local/etc/init.d/bluez start
sudo modprobe hci_uart
while [ ! -r /dev/serial1 ]; do
sleep 0.5
done
HCIATTACH=/usr/local/bin/hciattach
if grep -q "Pi 4" /proc/device-tree/model; then
BDADDR=
else
SERIAL=`cat /proc/device-tree/serial-number | cut -c9-`
B1=`echo $SERIAL | cut -c3-4`
B2=`echo $SERIAL | cut -c5-6`
B3=`echo $SERIAL | cut -c7-8`
BDADDR=`printf b8:27:eb:%02x:%02x:%02x $((0x$B1 ^ 0xaa)) $((0x$B2 ^ 0xaa)) $((0x$B3 ^ 0xaa))`
fi
uart0="`cat /proc/device-tree/aliases/uart0`"
serial1="`cat /proc/device-tree/aliases/serial1`"
if [ "$uart0" = "$serial1" ] ; then
uart0_pins="`wc -c /proc/device-tree/soc/gpio@7e200000/uart0_pins/brcm\,pins | cut -f 1 -d ' '`"
if [ "$uart0_pins" = "16" ] ; then
sudo $HCIATTACH /dev/serial1 bcm43xx 3000000 flow - $BDADDR
else
sudo $HCIATTACH /dev/serial1 bcm43xx 921600 noflow - $BDADDR
fi
else
sudo $HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR
fi
rpi_bthelper() {
# For on-board BT, route SCO packets to the HCI interface (enables HFP/HSP)
# Sound quality is horrible.....just puting this here for info
#echo "Usage: $0 <bluetooth hci device>"
dev="hci0"
# Need to bring hci up before looking at MAC as it can be all zeros during init
/usr/local/bin/hciconfig "$dev" up
if ! /usr/local/bin/hciconfig $dev | grep -q "Bus: UART"; then
echo Not a UART-attached BT Modem
return
fi
if ( /usr/local/bin/hcitool -i $dev dev | grep -q -E '\s43:4[35]:|AA:AA:AA:AA:AA:AA' ); then
SERIAL=`cat /proc/device-tree/serial-number | cut -c9-`
B1=`echo $SERIAL | cut -c3-4`
B2=`echo $SERIAL | cut -c5-6`
B3=`echo $SERIAL | cut -c7-8`
BDADDR=`printf '0x%02x 0x%02x 0x%02x 0xeb 0x27 0xb8' $((0x$B3 ^ 0xaa)) $((0x$B2 ^ 0xaa)) $((0x$B1 ^ 0xaa))`
/usr/local/bin/hcitool -i $dev cmd 0x3f 0x001 $BDADDR
/usr/local/bin/hciconfig $dev reset
else
echo Raspberry Pi BDADDR already set
fi
}
-
Hi Juanito
... it cannot find the gir files from networkmanager - an extension that does not exist on piCore64. ...
But it does exist in the armhf repo:
Title: networkmanager.tcz
Description: network manager
Version: 1.22.10
Author: see list of sites below
Original-site: see list of sites below
Copying-policy: see list of sites below
Size: 2.7MB
Extension_by: juanito
Tags: network wired wireless wifi 3g bluetooth wwan
Comments: set of co-operative tools that make networking simple and straightforward.
Whether wifi, wired, 3g, or bluetooth, networkmanager allows you to quickly move from one network to another
----------
This extension contains:
NetworkManager-1.22.10 - GPLv2 - https://ftp.gnome.org/pub/GNOME/sources/NetworkManager/1.22/NetworkManager-1.22.10.tar.xz
----------
Change-log: 2018/02/05 first version
Current: 2020/05/21 updated 1.4.6 -> 1.22.10Found here:
http://tinycorelinux.net/17.x/armhf/tcz/networkmanager.tcz.info
networkmanager-gir.tcz is there as well.
... I'm somewhat baffled by this - what is it about the second script that makes blueman look for networkmanager? ...
The only commands there are hciconfig and hcitool, and I can't find
why they might want networkmanager.
echo Raspberry Pi BDADDR already set
Unrelated, but did you mean to echo the variable name (BDADDR) or its contents ($BDADDR)?
-
The only commands there are hciconfig and hcitool, and I can't find why they might want networkmanager.
It's not so much that the hciconfig and/or hcitool commands need networkmanager, but rather that they cause blueman to need networkmanager.
I can get around this by using dconf-editor to add the following to blueman plugin-list:
['!NMPANSupport', '!NMDUNSupport']
..but that's not really solving the problem.
-
Hi Juanito
Maybe something in the build process pulled it in.
Possibly a pkgconfig error?
-
Maybe, but that doesn't happen when I only use the first part of the bluetooth start script.
Also since blueman uses networkmanager via gir, it doesn’t look for it at build time.
..but thanks for the suggestions :)
-
Hi guys!
As usual I have a question. If I am about to start from scratch with bittorrent what are the packages needed? When I try to setup bluetooth something crashes in the moment i hear that it should be connection. Some kind of digital crash between two different commands is what I am wondering about. So the NEEDED packages ONBOOT that would be perfect to know.
Kind Greetings,
meo
-
Hi Juanito
... Also since blueman uses networkmanager via gir, it doesn’t look for it at build time. ...
My mistake. I thought this was a bluez issue since I manged to miss all of
the blueman references when previously reading this thread.
I rephrased my query to Google and got this response:
Running deprecated tools like hciconfig or hcitool does not literally force
NetworkManager into your system. Instead, using these legacy BlueZ commands triggers
state changes or dial-up/PAN network profile hooks in blueman that assume a network
stack manager is present to handle network-via-bluetooth interfaces.
Why This Interaction Happens
Legacy vs. Modern Stack: hciconfig and hcitool were deprecated by BlueZ in
favor of bluetoothctl and btmgmt. They interact with the kernel interface differently
than modern D-Bus API calls.
Network Profile Triggers: When legacy commands modify or query adapter states,
blueman attempts to sync device network NAP (Network Access Point) or PAN
(Personal Area Network) services.
Dependency Assumptions: blueman has built-in features for network dial-up and
network tethering over Bluetooth, causing lightweight or minimalist environments (like
Tiny Core Linux or custom setups) to throw missing dependency warnings for
NetworkManager when these paths are activated.
How to Fix or Avoid It
Switch to bluetoothctl: Stop using hciconfig and hcitool. Use bluetoothctl
for modern device management and connection states.
Check blueman Network Plugins: Open blueman-manager, go to Preferences ->
Plugins, and disable network-related plugins (like Network or NAP/PAN support) if you
do not route internet over Bluetooth.
Use btmgmt: For low-level kernel interface adjustments previously done via
hciconfig, use btmgmt instead.
Don't know how useful this is.
-
The second script does this.
# For on-board BT, route SCO packets to the HCI interface (enables HFP/HSP)
I would imagine those extra bluetooth profiles are what pulls in the extra requirements
-
Don't know how useful this is.
It's definitely interesting...
@Paul_123 - I take it that the Raspberry OS is not (yet) using bluetoothctl/btmgmt instead of hciconfig/hcitool to initialise the onboard bluetooth interface?
As mentioned, I could try to disable the networkmanager plugins in blueman by default, but I seem to remember that having done so, blueman still didn't work as expected.
I could also build a networkmanger extension, but for things to work properly a user would have to bring the network up with networkmanager rather than udpcpc.
As an aside, it might be a good idea to include the bluetooth initialisation script with the bluez extension, but not call it with the startup script?
-
In fact if I disable networkmanager in blueman prior to starting bluetooth with the full script things appear to work :)