esc

I know it doesn't matter for your case since you've managed to get it up and running; but,"bdaddr" isn't a keyword, actual address should be the only non-option argument of the command: /usr/bin/hciattach /dev/ttyS3 bcm43xx 1500000 - 43:29:B1:55:01:01 What modified hciattach are you running? Is it with firmware patch uploading fix?

I've just checked my orangepi board and can confirm that it receives same AA:AA:AA:AA:AA:AA without manual assignment. Are you saying manual assignment is not working?

Did you get bcm43430a1.hcd? I'd try grabbing bcm*.hcd files from /etc/firmware of Friendlyarm. Looks like bcm driver was able read chip variant from the IC but could not find matching firmware in /etc/firmware.

@Larry Fox, you're certainly right about PG13 pin. Having BT-RST-N low prevents a BT module from communicating. Try running script below while having ttyS3 activated: #!/bin/sh devmem2 0x1f00060 b 1 echo 205 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio205/direction echo 0 > /sys/class/gpio/gpio205/value echo 1 > /sys/class/gpio/gpio205/value sleep 0.1 /usr/bin/hciattach /dev/ttyS3 bcm43xx 1500000

Thanks! Looks like serial1 is lacking a reference to the flow control pins. Don't know if it's like that in board's dtb or overlay breaks this. I'd try to update the dtb file by changing the following line from: pinctrl-0 = <0x50>; to: pinctrl-0 = <0x50 0x51>;

Hm, I didn't have to touch uart1 with H3 as it was already active in dtb used, wonder if something else is off there... Could you grab your device tree with dtc -I fs /sys/firmware/devicetree/base/

You can ask dtc to scan the tree and produce textual representation of the state. dtc -I fs /sys/firmware/devicetree/base/ If the output from above command includes the change you intended then it must be something else that prevents it from working.

Ah, forgot to mention that I have an H3. Looks like your UART1 is not active. First, I'd suggest to try adding overlay=uart1 to /boot/armbianEnv.txt and rebooting. Then make sure dmesg output contains lines about ttyS1. If this doesn't work then maybe H5 board version's port/pin allocation may differ from H3, i don't know. Let's see if this works first.

Not sure if this is relevant to the board in question but I was recently playing with Orange Pi Zero Plus 2. I could get BT running by manually setting BT_RST_N pin HIGH and enabling 32KHz clock from RTC module. Though I never had to touch 'wake' signals, they may just happened to be in correct state for some reason. AP6212 datasheet is not very verbose regarding the purpose of these signals. For now I just have a dumb script to bring BT up and need to figure out a way to properly integrate these changes into the device tree (probably in a form of rfkill-section but I don't have experience with DTS). #!/bin/sh devmem2 0x1f00060 b 1 echo 10 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio10/direction echo 0 > /sys/class/gpio/gpio10/value echo 1 > /sys/class/gpio/gpio10/value sleep 0.1 /usr/bin/hciattach /dev/ttyS1 bcm43xx 1500000 Also my board came with AP6212A so I'm using bcm43430a1.hcd(md5:b95ee9032a723daa25ab9608a515e984) firmware.