RPi-Distro / pi-bluetooth

Loads BCM43430A1 firmware on boot
42 stars 34 forks source link

Add a btserial command and move serial device rules #28

Closed waveform80 closed 2 years ago

waveform80 commented 2 years ago

I'm not sure if this will be of interest, but just in case:

In RaspiOS, the udev rules for configuring the /dev/serialN devices exist in /etc/udev/rules.d/99-com.rules and involve a few chunks of shell-script for determining which UART to point the serialN alias(es) at.

With the version of udev in Bullseye (and coincidentally, Ubuntu Hirsute onwards), udev complains about the $ALIASES substitution in this rule. In Bullseye, this was fixed by escaping it to $$ALIASES, but I thought it might be a little cleaner to spin this logic out into its own script, and stuff all the rules and logic in the pi-bluetooth package (this is what I'm doing in the Ubuntu version of the package).

Incidentally, if you do decide to merge this, you would need to remove the corresponding chunk in RPi-Distro/raspberrypi-sys-mods.

Closes #27 (which should probably be closed anyway as RaspiOS Bullseye already fixed this)

pelwell commented 2 years ago

I like the clean-up, but although the symlinks were originally prompted by Bluetooth, and still used by Bluetooth, they should still exist if Bluetooth is disabled or completely absent.

waveform80 commented 2 years ago

Ah, hence the rules' existence in raspberrypi-sys-mods, as opposed to pi-bluetooth (though the latter is installed by default in both RaspiOS and Ubuntu, it could be subsequently purged, which would then effectively remove the aliases). And of course, the boot firmware mirrors these aliases in its treatment of re-writing console=serial0 to, say, console=ttyAMA0, hence they're a "system level thing".

Hmmm ... I need to have a think about the "right" way to handle this (in Ubuntu I'd already incorporated those rules into our pi-bluetooth package as our equivalent of sys-mods wasn't universally installed across all images until recently for ... reasons). At the very least, the btserial script should probably be named something else to make it evident it's not Bluetooth specific. I'll close this for now and have a play with some alternatives -- thanks for the reply!