hciuart holding off start of bluetoothd
maxnet opened this issue · comments
Newer (upstream) kernels have the ability to manage the uart connection and load firmware themselves, without a need for the hciattach daemon.
However when using such kernel with Raspbian it currently takes a minute or two before bluetooth works.
This is because your hciuart service is waiting a long time for dev-serial1 to appear (which never will, as device is claimed by kernel), before eventually timing out.
Since you have Before=bluetooth.service that prevents startup of bluetoothd during that time.
It would be nice if hciuart didn't hold off starting up bluetoothd.
Isn't it capable of dealing with hci devices appearing later?
I'd hope so, but then I'm not sure whether the bthelper service will still work. I can add it to the todo list, but doubt I will get to it in the near future. I'd take a PR if it has been tested though.
I'd hope so, but then I'm not sure whether the bthelper service will still work.
Not sure if I understand that script.
If the device is guaranteed to be available by systemd ordering, why does it busy loops up to 30 times (without delay?) looking if the device appears in hciconfig?
Can't this be done cleaner by udev rule only invoked when a hci device with the right MAC address shows up?
If the device is guaranteed to be available by systemd ordering, why does it busy loops up to 30 times (without delay?) looking if the device appears in hciconfig?
Not going to pretend I know, but the author generally has reasons for doing things the way he does.
Can't this be done cleaner by udev rule only invoked when a hci device with the right MAC address shows up?
I didn't have much luck with that. If I recall correctly, when the hci device becomes available, hcitool fails. It only starts working a little later.
This may actually go together with your original question. Perhaps bluetooth.service needs to be loaded for hcitool to work and replacing the Before= line with an After= would solve both issues. Can't go down the rabbit hole of looking into it properly right now though.
I didn't have much luck with that. If I recall correctly, when the hci device becomes available, hcitool fails.
It only starts working a little later.
Probably because hcitool dev is similar in behavior to ifconfig without the -a, it only shows devices that are up.
pi@raspberrypi:~ $ hciconfig
hci0: Type: Primary Bus: UART
BD Address: 43:45:C0:00:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1
DOWN
RX bytes:2982 acl:0 sco:0 events:324 errors:0
TX bytes:55836 acl:0 sco:0 commands:324 errors:0
pi@raspberrypi:~ $ hcitool dev
Devices:
pi@raspberrypi:~ $ sudo hciconfig hci0 up
pi@raspberrypi:~ $ hcitool dev
Devices:
hci0 43:45:C0:00:1F:AC
bluetoothd does bring all devices up, so that can indeed be why it starts working.
But it is naturally also possible to bring device up in udev script.
May have a go later at that.
Problem is I currently only have bluetooth HID input devices to play with laying around, and not something that needs your special commands.
I have devices I can test against if you send a PR.
Hmm, just found out the upstream kernel implementation isn't that useful at this time.
Doesn't offer a straightforward way to patch up the MAC address.
And the bluetooth firmware still doesn't seem to get the address from OTP.
Make it not fit for purpose if you have more than one Pi 3 in the room.
Do will add a PR to fix the startup issue.
But don't feel any rush to test it.
Do note that hciattach/hcitool/hciconfig are all depreceated and no longer there in newer bluez versions.
So you may want to look into switching to a different construct before the next major Debian version.