mantabernd Posted July 24, 2017 Posted July 24, 2017 Hi, I'm trying to use bluetooth with the Mainline 4.11.9-sun8i armbian kernel (I also tried 4.11.7-sun8i). I activated ttyS3 (uart3) in armbianEnv.txt: verbosity=1 logo=disabled console=serial overlay_prefix=sun8i-h3 rootdev=UUID=59c35982-ddad-4bf0-8b72-a8974bfe88a6 rootfstype=ext4 overlays=uart3 spi-spidev param_uart3_rtscts=1 param_spidev_spi_bus=0 Unfortunately hciconfig -a does not find any device. I already tried to set the baudrate but no chance to get bluetooth alive: service bluetooth stop rfkill unblock all echo "0" > /sys/class/rfkill/rfkill0/state echo "1" > /sys/class/rfkill/rfkill0/state echo " " > /dev/ttyS3 hciattach /dev/ttyS3 bcm43xx 1500000 flow hciconfig hci0 up brings: bcm43xx_init Initialization timed out. Can't get device info: No such device root@nanopiair:~# Any idea whats going wrong here? Regards Bernhard
martinayotte Posted July 24, 2017 Posted July 24, 2017 You didn't mention which board you are using ... This is important, since some boards, such OPiWin or OPiZeroPlus, are using UART1 nor UART3. Also, the AP6212 has BT-WAKE-AP and AP-WAKE-BT pins that maybe need to be added in DT.
mantabernd Posted July 24, 2017 Author Posted July 24, 2017 I'm using Nano Pi Neo Air. AP6212a is located on ttyS3. It's working under 3.4 kernel. BT-WAKE-AP and AP-WAKE-BT is a good hint. Thank you for this! Can you tell me how I activate these pins in DT? I guess you are talking about Pins PA7 and PA8? Thanks for your help.
mantabernd Posted July 24, 2017 Author Posted July 24, 2017 I guess I need to create my own overlay, or? I found this .dts file for uart3 on Allwinner H3: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/aliases"; __overlay__ { serial3 = "/soc/serial@01c28c00"; }; }; fragment@1 { target = <&uart3>; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <&uart3_pins>; status = "okay"; }; }; }; How to insert the custom GPIOs here?
martinayotte Posted July 24, 2017 Posted July 24, 2017 That is a good question ! I've never played with Bluetooth ... Maybe we need to compare what has been done in the Legacy FEX for those GPIOA7 and GPIOA8, probably some interrupts defines.
mantabernd Posted July 25, 2017 Author Posted July 25, 2017 Maybe it's already enough to set GPIOA7 and GPIOA8 to a high level... Unfortunately I can't find any information how to set them as a output with pullup. Do you have any idea how to change the .dts file from my prev post?
mantabernd Posted July 25, 2017 Author Posted July 25, 2017 I found a patch regarding this: https://github.com/armbian/build/blob/01a34e94e2f618f805ead41679695fb09490add0/patch/kernel/sun8i-dev/nanopi-neo-air-wireless-and-dvfs.patch Can you please tell me how to install this patch?
Igor Posted July 25, 2017 Posted July 25, 2017 9 minutes ago, mantabernd said: Can you please tell me how to install this patch? That patch is deprecated, not "installable" and that's why it was removed. You need to implement that code to recent kernel source. Not straightforward process. We have plan to wait for 4.12 and than patches will be adjusted in greater degree. And when we will find time.
martinayotte Posted July 25, 2017 Posted July 25, 2017 Anyway, this patch doesn't seems to take care of BT-WAKE-AP and AP-WAKE-BT.
esc Posted January 2, 2018 Posted January 2, 2018 (edited) 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. Edited January 2, 2018 by esc
Larry Bank Posted January 2, 2018 Posted January 2, 2018 3 hours ago, esc said: 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. I just tried this on my Orange Pi Zero Plus 2 (H5) and get the following error when running hciattach: Can't get port settings: Input/output error Can't initialize device: Input/output error Any ideas? Are you using this on the H3 or the H5 version of the OPZ+2?
esc Posted January 2, 2018 Posted January 2, 2018 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.
Larry Bank Posted January 2, 2018 Posted January 2, 2018 1 hour ago, esc said: 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. I activated uart1 and now I get the error "bcm43xx_init Initialization timed out."
esc Posted January 2, 2018 Posted January 2, 2018 44 minutes ago, Larry Bank said: I activated uart1 and now I get the error "bcm43xx_init Initialization timed out." 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/
Larry Bank Posted January 2, 2018 Posted January 2, 2018 Here's the text file output from dtc: https://www.dropbox.com/s/30sdoj02tit2snc/dt.txt?dl=0
esc Posted January 2, 2018 Posted January 2, 2018 10 hours ago, Larry Bank said: Here's the text file output from dtc: https://www.dropbox.com/s/30sdoj02tit2snc/dt.txt?dl=0 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>;
thc013 Posted May 5, 2018 Posted May 5, 2018 On 1/2/2018 at 11:31 PM, Larry Bank said: I activated uart1 and now I get the error "bcm43xx_init Initialization timed out." also add param_uart1_rtscts=1 and it also works with the script to eneable bt and if you add the script to /etc/init.d/ap6212-bluetooth it will work out of the box # Start patching rfkill unblock all echo "0" > /sys/class/rfkill/rfkill0/state echo "1" > /sys/class/rfkill/rfkill0/state echo " " > /dev/$PORT 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 hciattach /dev/$PORT bcm43xx 115200 flow bdaddr $MAC_OPTIONS hciconfig hci0 up
Henrik Larsson Posted July 1, 2018 Posted July 1, 2018 I had the same problem with NanoPi Neo Air and bluetooth as mantabernd hciconfig -a didn't show any device and hciattach timed out: hciattach /dev/ttyS3 bcm43xx 115200 flow bdaddr 43:29:B1:55:01:01 bcm43xx_init Initialization timed out. The other replies here by Larry Bank and thc013 helped me solve it. uname -a Linux nanopiair 4.14.52-sunxi #581 SMP Fri Jun 29 10:05:07 UTC 2018 armv7l armv7l armv7l GNU/Linux I first used armbian-config to install BT support. Then I edited the /boot/armbianEnv.txt to add uart3 overlay and param_uart3_rtscts=1 to enable rts and cts. Since I was unsure if it was supposed to be uart1 or uart3 I looked at the schematic here and saw it was connected tu uart3: http://wiki.friendlyarm.com/wiki/images/9/98/NanoPi-NEO-Air-1608-Schematic.pdf My armbianEnv.txt: verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 param_uart3_rtscts=1 overlays=uart3 usbhost1 usbhost2 rootdev=UUID=91977eb8-39b7-4db4-ac8b-2eb075f6eef2 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Then I edited /etc/default/ap6212 to change from ttyS1 to ttyS3: # # Default it is called to be uncertain wich MAC address the chipset has. # Therefore it is recommendable to set the MAC address manually. # This can be done by setting the variable MAC_ADDR with a chosen value. # If this variable is empty or not set the default 11:22:33:44:55:66 will be chosen. MAC_ADDR=43:29:B1:55:01:01 # PORT=ttyS3 After a restart I run these commands: # rfkill unblock all # echo "0" > /sys/class/rfkill/rfkill0/state # echo "1" > /sys/class/rfkill/rfkill0/state # echo " " > /dev/ttyS3 # 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 # hciattach /dev/ttyS3 bcm43xx 115200 flow bdaddr 43:29:B1:55:01:01 # hciconfig hci0 up From the schematic I found that BT_RST_N is connected to GPIOG13. I didn't find any documentation (anyone know where it is?) saying which gpio number GPIOG13 maps to but I found that GPIOG11 maps to 203 ( http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air ). After running above commands hciconfig -a returns this: # hciconfig -a hci0: Type: Primary Bus: UART BD Address: 43:29:B1:55:01:01 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:983 acl:0 sco:0 events:46 errors:0 TX bytes:2719 acl:0 sco:0 commands:46 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'nanopiair' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x6a LMP Version: 4.0 (0x6) Subversion: 0x2209 Manufacturer: Broadcom Corporation (15) The last step will be to add the script to /etc/init.d/ap6212-bluetooth (same as above but with the variables for port and mac_option) : rfkill unblock all echo "0" > /sys/class/rfkill/rfkill0/state echo "1" > /sys/class/rfkill/rfkill0/state echo " " > /dev/$PORT 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 hciattach /dev/$PORT bcm43xx 115200 flow bdaddr $MAC_OPTIONS hciconfig hci0 up 1
martinayotte Posted July 2, 2018 Posted July 2, 2018 Most patches done for BRCM doesn't include Bluetooth DT nodes, only WiFi nodes. If you wish to participate to such development, learn about devices-tree, check existing DTS, and start adding BT nodes for AP6212.
Henrik Larsson Posted July 2, 2018 Posted July 2, 2018 I have tested Bluetooth Low Energy using bleno to implement a BLE peripherals ( https://github.com/noble/bleno ) and it appears to work! I have a requirement to have a unique bluetooth mac address for each board. And one that stays the same over reboots and flashes of new images. I tested running this: # hciattach /dev/ttyS3 bcm43xx 115200 flow omitting the bdaddr $MAC_OPTIONS part. This still works and it sets a BT mac address. It set the same BT mac address after rebooting. And when trying on my second NanoPi Neo Air it was set to another BT mac address. My guess is that it uses a unique BT mac address of the ap6212 chip. Does that sound right? But why do armbian set a fixed BT mac address? A clue can be found in /etc/default/ap6212: # Default it is called to be uncertain wich MAC address the chipset has. # Therefore it is recommendable to set the MAC address manually. # This can be done by setting the variable MAC_ADDR with a chosen value. # If this variable is empty or not set the default 11:22:33:44:55:66 will be chosen. But I don't understand this comment. Does anyone else?
arox Posted July 3, 2018 Posted July 3, 2018 11 hours ago, Henrik Larsson said: I have tested Bluetooth Low Energy using bleno to implement a BLE peripherals ( https://github.com/noble/bleno ) and it appears to work! I have a requirement to have a unique bluetooth mac address for each board. And one that stays the same over reboots and flashes of new images. I tested running this: # hciattach /dev/ttyS3 bcm43xx 115200 flow omitting the bdaddr $MAC_OPTIONS part. This still works and it sets a BT mac address. It set the same BT mac address after rebooting. And when trying on my second NanoPi Neo Air it was set to another BT mac address. My guess is that it uses a unique BT mac address of the ap6212 chip. Does that sound right? But why do armbian set a fixed BT mac address? A clue can be found in /etc/default/ap6212: # Default it is called to be uncertain wich MAC address the chipset has. # Therefore it is recommendable to set the MAC address manually. # This can be done by setting the variable MAC_ADDR with a chosen value. # If this variable is empty or not set the default 11:22:33:44:55:66 will be chosen. But I don't understand this comment. Does anyone else? I suppose that some manufacturer spare money by not registring an address. Nanopi air should anyway have one. For my part, what I donnot understand is the 115200 in hciattach command : AP62XX is a serial module, and all BT traffic is routed in HCI over serial communication link. So how could someone reach 3 Mb/s of data rate over a 115200 b/s line ?!?. I always change this for 1500000. Otherwise an a2dp link drop packets for example. Another funny thing is the usage of 11:xx...etc or 43:xx...etc addresses. By default the system load a BNEP module, but dont try to configure a NAP acces point with that : it will try to use the address as an ethernet address in BNEP emulation - and fail with bad reporting because an address with an even first byte is illegal for Ethernet. I use a Nanopi neo 4.14.14 kernel with btusb dongle to create ppp/rfcomm links. I previously used a Nanopi air or a BPIM2+ 3.4.17 kernel for BNEP links. With nanopis or bpi I crash the kernel every other day. So did you achieve some stability with that ? Anyway, with BR/EDR mode and bluez, I need to reset the controller periodicaly because it became anable to create basic link (ACL) after some time when forming multiple piconet. So I also experiment with BLE. I tested Bluepy - wich can handle "central" (but not peripheral) role in python. But I doubt to achieve stability and low latency in connected mode. So I am now developping my own trivial mesh protocol by advertising/scanning transmission with gatt/paypal in golang on RPI (and chip with some tweak in scan report demux) ... I didnt try bleno/noble. It seems to shunt BLUEZ insane routing through dbus/xml unstable/undocumented messaging API (as do also gatt/paypal) and handle itself the HCI interface. I am not sure about the difference in socket interface in both implementation ? I am not sure of the role of 4343A0.hcd or so files downloaded by hciattach. If this is the firmware for BT controller, there certainly is a lot of bugs in this and we need more robust version ? 1
Henrik Larsson Posted July 4, 2018 Posted July 4, 2018 Thanks for your reply, some good points there! The extent of my Bleno/ BLE testing was to start it up, see that I could connect and list the characteristics. So I have no idea if it is stable or not. The bluetooth default address might not be registered but as long as it is 'reasonably' unique it is probably good enough for me.
triglm Posted August 14, 2018 Posted August 14, 2018 I'm trying to get Bluetooth BLE to work on the NanoPi Neo Air. I've got it working on my Raspberry PI 3 under Raspbian Stretch, but I haven't had any luck getting to work on the NanoPi NEO. I'm using Armbian Stretch # uname -a Linux nanopiair 4.14.18-sunxi #24 SMP Fri Feb 9 16:24:32 CET 2018 armv7l GNU/Linux But when I run... hciconfig -a returns nothing and so does hcitool dev I tried @Henrik Larsson commands listed above, but when I do... #hciattach /dev/ttyS3 bcm43xx 115200 flow bdaddr 43:29:B1:55:01:01 bcm43xx_init Initialization timed out. The Initialization times out. I noticed there is a similar set of commands already in /etc/init.d/ap6212-bluetooth Does anyone have Bluetooth working with Armbian Stretch on the Nanopi Air? Should I try another distro? another Kernel?
Larry Fox Posted September 25, 2018 Posted September 25, 2018 I tried the process as well to enable ttyS3 and although ttyS3 is there, the commands listed above do not work. I get the same message in the hciattach, bcm43xx_init Initialization timed out. Fundamentally all I would like to do is get hci_uart fired up. In a standard build for the NEO Air LTS Linux BE-BLUE 4.14.0 #2 SMP Wed Dec 13 15:15:38 CST 2017 armv7l armv7l armv7l GNU/Linux [ 19.331372] Bluetooth: Core ver 2.22 [ 19.331541] NET: Registered protocol family 31 [ 19.331550] Bluetooth: HCI device and connection manager initialized [ 19.331587] Bluetooth: HCI socket layer initialized [ 19.331606] Bluetooth: L2CAP socket layer initialized [ 19.331665] Bluetooth: SCO socket layer initialized [ 19.350794] Bluetooth: HCI UART driver ver 2.3 [ 19.350814] Bluetooth: HCI UART protocol H4 registered [ 19.350819] Bluetooth: HCI UART protocol BCSP registered [ 19.351002] Bluetooth: HCI UART protocol LL registered [ 19.351009] Bluetooth: HCI UART protocol ATH3K registered [ 19.351014] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 19.351252] Bluetooth: HCI UART protocol Intel registered [ 19.351480] Bluetooth: HCI UART protocol Broadcom registered [ 19.351488] Bluetooth: HCI UART protocol QCA registered [ 19.351492] Bluetooth: HCI UART protocol AG6XX registered [ 19.351496] Bluetooth: HCI UART protocol Marvell registered [ 43.777037] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 43.777055] Bluetooth: BNEP filters: protocol multicast [ 43.777093] Bluetooth: BNEP socket layer initialized [ 44.597084] Bluetooth: RFCOMM TTY layer initialized [ 44.597132] Bluetooth: RFCOMM socket layer initialized [ 44.597178] Bluetooth: RFCOMM ver 1.11 In the latest armbian (Debian stretch) I see below. Clearly HCI UART is not being loaded Linux nanopiair 4.14.65-sunxi #1 SMP Mon Aug 20 08:45:20 CEST 2018 armv7l GNU/Linux [ 14.579509] Bluetooth: Core ver 2.22 [ 14.579673] NET: Registered protocol family 31 [ 14.579682] Bluetooth: HCI device and connection manager initialized [ 14.579803] Bluetooth: HCI socket layer initialized [ 14.579828] Bluetooth: L2CAP socket layer initialized [ 14.579873] Bluetooth: SCO socket layer initialized
Henrik Larsson Posted November 26, 2018 Posted November 26, 2018 @Larry Fox@triglm I started over with a Debian image and also got the initialization timeout error... By running the hciattach command a second time it kind of initialized, it gave an error message about not finding the firmware but still initialized. However I googled around a bit and found this: http://www.blog.willandnora.com/2017/08/11/bluez-5-46-hciuart-configuration-changes/ and this patch https://github.com/OpenELEC/OpenELEC.tv/blob/6b9e7aaba7b3f1e7b69c8deb1558ef652dd5b82d/packages/network/bluez/patches/bluez-07-broadcom-dont-set-speed-before-loading.patch So I decided to try to patch and recompile bluez by following https://raphaelhertzog.com/2010/12/15/howto-to-rebuild-debian-packages/ This seems to fix the firmware loading issue!
Larry Fox Posted November 28, 2018 Posted November 28, 2018 On 11/26/2018 at 3:14 PM, Henrik Larsson said: @Larry Fox@triglm I started over with a Debian image and also got the initialization timeout error... By running the hciattach command a second time it kind of initialized, it gave an error message about not finding the firmware but still initialized. However I googled around a bit and found this: http://www.blog.willandnora.com/2017/08/11/bluez-5-46-hciuart-configuration-changes/ and this patch https://github.com/OpenELEC/OpenELEC.tv/blob/6b9e7aaba7b3f1e7b69c8deb1558ef652dd5b82d/packages/network/bluez/patches/bluez-07-broadcom-dont-set-speed-before-loading.patch So I decided to try to patch and recompile bluez by following https://raphaelhertzog.com/2010/12/15/howto-to-rebuild-debian-packages/ This seems to fix the firmware loading issue! I have completed quite the diagnosis of this problem and I am still not seeing a result that gets me to a working BT Uart. Here are a few things that I have determined with my current linux build: ARMBIAN 5.65 stable Debian GNU/Linux 9 (stretch) 4.14.78-sunxi modified armbianEnv.txt to include uart3 (used on the nano pi neo air for BT) and param_uart3_rtscts=1 modified /etc/default/ap6212, changed port to PORT=ttyS3 added hci_uart to modules Updated Bluez to latest Installed hciattach patch, still getting "Initialization timed out." Still have an error loading the firmware as noted in ""systemctl status ap6212-bluetooth.service" Nov 28 15:13:19 nanopiair ap6212-bluetooth[2179]: Initialization timed out. Nov 28 15:13:19 nanopiair ap6212-bluetooth[2179]: bcm43xx_init Nov 28 15:13:19 nanopiair ap6212-bluetooth[2179]: Can't get device info: No such Nov 28 15:13:19 nanopiair systemd[1]: ap6212-bluetooth.service: Control process Nov 28 15:13:19 nanopiair systemd[1]: Failed to start LSB: Patch firmware for ap -- Subject: Unit ap6212-bluetooth.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit ap6212-bluetooth.service has failed. -- -- The result is failed. Nov 28 15:13:19 nanopiair systemd[1]: ap6212-bluetooth.service: Unit entered fai Nov 28 15:13:19 nanopiair systemd[1]: ap6212-bluetooth.service: Failed with resu Some obvious items worthy of note. I can remove the SD card with this build of linux and replace it with the Friendlyarm build and BT works like a champ. As such the hardware is functional. I also notice that PG13 is currently low on the Armbian build whereas it is high on the Friendlyarm build. I have not probed into this more but this I/O does control BT Reset to the ap6212. I get the feeling that the gatekeeper to success is simply being able to talk to /dev/ttyS3 to move info back and forth to the ap6212. Regards, Larry
esc Posted November 28, 2018 Posted November 28, 2018 1 hour ago, Larry Fox said: I also notice that PG13 is currently low on the Armbian build whereas it is high on the Friendlyarm build. I have not probed into this more but this I/O does control BT Reset to the ap6212. @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
Larry Fox Posted November 28, 2018 Posted November 28, 2018 Well one step further and a small change has occurred, I see the baud rate change message on the first try. bcm43xx_init Failed to read local name, command failure Can't initialize device: Success or bcm43xx_init Patch not found, continue anyway Set Controller UART speed to 1500000 bit/s Initialization timed out. copied the patch to /etc/firmware and now get bcm43xx_init Failed to write reset command Can't initialize device: Success realized I needed a reboot and now get bcm43xx_init Patch not found, continue anyway Set Controller UART speed to 1500000 bit/s Device setup complete hciconfig hci0 hci0: Type: Primary Bus: UART BD Address: AA:AA:AA:AA:AA:AA ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:766 acl:0 sco:0 events:48 errors:0 TX bytes:2737 acl:0 sco:0 commands:48 errors:0 the BD address is bogus and will need to do some work to get the right profiles/class, etc registered. Now to make this something more manageable Larry
esc Posted November 28, 2018 Posted November 28, 2018 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 Posted November 28, 2018 Posted November 28, 2018 52 minutes ago, esc said: Maybe wrong firmware is being used? Did you get bcm43430a1.hcd? I'd try grabbing bcm*.hcd files from /etc/firmware of Friendlyarm. Confirmed the same files are on a friendlyarm board as on my board now. I have seen mention of defining an env variable FIRMWARE_DIR. Doesn't seem to have any affect that I can tell. Note also tried to add a bdaddr to the hciattach command, no luck there. FYI the script sometimes fails the first time around but seems to be pretty solid on try two. Now to get all of this mess into a startup scenario where I can cold boot and have everything configured properly. Thanks for all your help! Still more than willing to try any suggestions. Larry
Recommended Posts