Jump to content

No bluetooth with AP6212a under 4.11 Mainline


mantabernd

Recommended Posts

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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

 

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by esc
Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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."

 

Link to comment
Share on other sites

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/

Link to comment
Share on other sites

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>;

Link to comment
Share on other sites

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

 

 

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

@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!

 

Link to comment
Share on other sites

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

 

 

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines