Linux DietPi 5.15.89-sunxi64 #22.11.4 SMP Mon Jan 23 22:02:54 UTC 2023 aarch64 GNU/Linux
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=14
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
This a pine64,a64 cpu.2GB with factory wifi/bt plug on board
There is no /dev/ttyS1 so the command
rtk_hciattach -n -s 115200 /dev/ttyS1 rtk_h5 does not work
Nothing shows in rfkill, hcitool
dmesg |grep tty
----part-----
1.860477] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 42, base_baud = 1500000) is a 16550A
[ 1.860622] serial serial0: tty port ttyS1 registered
[ 5.476713] systemd[1]: Created slice system-getty.slice.
[ 5.511740] systemd[1]: Created slice system-serial\x2dgetty.slice.
No /dev/serial* either
how to get ttyS1 back?
trying with ttyS0 also fails
—more—
pulling apart dtb, it is clear why ttyS1, there is a bluetooth section (comapatible with=)
and not for serial 0
Maybe something in boot.scr that redirects ttyS1?
I certainly can not find where the device node that it is redirected to
Just to be clear, /dev/ttyS1 does not exist
-----and yet more----
I think (maybe) the problem of missing //dev/ttyS1 is from boot.scr/boot.cmd
setenv consoleargs “console=tty1”
I don’t think changing (and recompile) to =“” would work, no way to login
maybe console=tty0 would be OK ???
OR i could change dtb, move the bluetooth section to serial0
BTW if you try GitHub - lwfinger/rtl8723bs_bt: Bluetooth Code for RTL8723bs
for it to “work” start_bt.sh , line 9 has to have at end | cut -b 17-22`
and then it sort of works, BUT it returns /dev/ttyS0 to plug intp the rtk_hciattach line
AND without an altered dtb, this will not work (since the bluetooth section is /dev/ttyS1)
The question then is which is best solution, vis a vis updates,
alter boot.scr or alter dtb ???
Try to add uart1 to the end (in case separated with a space) of the overlays= line in /boot/dietpiEnv.txt. This enables the /dev/ttyS1 device. But not sure whether it can be used via HCI-UART the same way as with vendor kernel. I guess you got the information from PINE64 wiki? This does not necessarily apply to our mainline kernel.
You did enable Bluetooth in dietpi-config advanced options, right?
We can also check for a device tree node:
find /proc/device-tree/ -name status -exec echo -ne '\n{}: ' \; -exec cat {} \;
Thanks
Yes bluetooth turned on
changing (in dietpiEnv.txt) overlays= to overlays=uart1 made no difference,
still no /dev/ttyS1
the first line of the find (of many lines)
/proc/device-tree/soc/serial@1c28400/status: okay
1c28400 is serial 1
Not sure what you mean “(in case separated with a space) "
-----more----
I may be wrong, for every kernel compile, also a dtb is made
it is 'loosely” coupled to that specific kernel, ie you can move dtb to close kernels
(and tightly coupled to specific hardware)
anyway, at the end of the serial 1 section in the dtb (decompiled to dts)
bluetooth {
compatible = “realtek,rtl8723bs-bt”;
reset-gpios = <0x38 0x00 0x04 0x01>;
device-wake-gpios = <0x38 0x00 0x05 0x00>;
host-wake-gpios = <0x38 0x00 0x06 0x00>;
firmware-postfix = “pine64”;
I have a PineA64Plus, but seeing as it shares the same DTS this should also apply. My main issue was not getting bluetooth to work, but getting it to work after reboots. I found that making this simple adjustment removed the need of using a bluetooth helper script and had bluetooth working on cold boot and reboot.
Taken from the Armbian patch:
+ bluetooth {
+ compatible = "realtek,rtl8723bs-bt";
+ reset-gpios = <&r_pio 0 4 GPIO_ACTIVE_LOW>; /* PL4 */
+ device-wake-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
+ host-wake-gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+ firmware-postfix = "pine64";
+ };
};
Adjustment:
+ bluetooth {
+ compatible = "realtek,rtl8723bs-bt";
+ enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+ reset-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+ device-wake-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
+ host-wake-gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+ };
};
This being the magic: enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
Of course all the proper firmware needs to be in place and like I said I have only tested this on the Plus.
patrick@pinea64plus:~$ bluetoothctl
Agent registered
[CHG] Controller 34:C3:D2:BF:C8:4A Pairable: yes
[bluetooth]# show
Controller 34:C3:D2:BF:C8:4A (public)
Name: pinea64plus
Alias: pinea64plus
Class: 0x00000000
Powered: yes
Discoverable: no
DiscoverableTimeout: 0x000000b4
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d0537
Discovering: no
Roles: central
Roles: peripheral
Advertising Features:
ActiveInstances: 0x00 (0)
SupportedInstances: 0x05 (5)
SupportedIncludes: tx-power
SupportedIncludes: appearance
SupportedIncludes: local-name
[bluetooth]# scan on
Discovery started
[CHG] Controller 34:C3:D2:BF:C8:4A Discovering: yes
[NEW] Device 00:1A:7D:DA:71:13 musicbox
[bluetooth]# exit
Does this break any other interface which might be used on those GPIOs, e.g. the serial console on ttyS1?
@wdt
Also after reboot, with overlays=uart1 (yes that is correct), /dev/ttyS1 was not present? This would mean the overlay is broken.
Probably the related GPIOs generally need to be enabled, e.g. since after a change in mainline kernel, so that the same enable-gpios attribute needs to be added to the UART1 overlay as well, or simply to the base device tree?
Thats a good question. Not sure as its not actually there:
ls /dev/ttyS*
/dev/ttyS0 /dev/ttyS3 /dev/ttyS5 /dev/ttyS7
/dev/ttyS2 /dev/ttyS4 /dev/ttyS
Never was.
It makes sense that it is not present OOTB (with Armbian kernel), otherwise the dtoverlay wouldn’t make any sense. But of should be present with overlays=uart1, according to description of this overlay.
But strange that ttyS2 and ttyS3 are present, since those have overlays as well, if I remember right:
ls -l /boot/dtb/allwinner/overlay/sun50i-a64*
ls -l /boot/dtb/allwinner/overlay/sun50i-a64-ua*
-rw-r–r-- 1 root root 506 Jan 23 17:02 /boot/dtb/allwinner/overlay/sun50i-a64-uart1.dtbo
-rw-r–r-- 1 root root 963 Jan 23 17:02 /boot/dtb/allwinner/overlay/sun50i-a64-uart2.dtbo
-rw-r–r-- 1 root root 804 Jan 23 17:02 /boot/dtb/allwinner/overlay/sun50i-a64-uart3.dtbo
-rw-r–r-- 1 root root 963 Jan 23 17:02 /boot/dtb/allwinner/overlay/sun50i-a64-uart4.dtbo
ls /dev/ttyS*
/dev/ttyS0 /dev/ttyS2 /dev/ttyS3 /dev/ttyS4 /dev/ttyS5
I see from looking at connector pin-outs that bluetooth is fixed to uart1
—more–=-
there is a typo in uart1.dtbo, the serial address is wrong, should be 1c28400,
is wrong @1c28800
And…that didn’t help, still no ttyS1
Wow, very much confusion… In a fit of tidiness I moved all but …a64-pine64.dtb to a temp dir
AND THEN it didn’t boot !!! I had to move …a64-pine64-plus.dtb back
So something is set up wrong in boot.scr or dietpiEnv
still no ttyS1, still no bluetooth… I did add the changes to dtb from pyavitz,
thought I had done it wrong for a bit until I figured it out
And late last night a kernel update arrived, everything ‘just works’
right from the get go, sorry to waste your time, thanks for the effort