Hi,
I've been attempting to get bluetooth working on a broadcom 43430 chip,
on 4.12-rc6.
I've got it to work, at least somewhat.
I'm using:
# brcm_patchram_plus --patchram /lib/firmware/bcm/bcm43430a1.hcd
--no2bytes --tosleep 1000 --bd_addr <my_addr> /dev/ttymxc1
# hciattach /dev/ttymxc1 any
As I understand it, brcm_patchram_plus just loads firmware into the
chip, and hciattach is just hooking the hci-uart driver to the serial
port as a line discipline?
Is this the correct approach? is there a better way to get the firmware
loaded?
I've also read that btattach should be used instead of hciattach? is
this the case?
-Ian
On 27/06/17 17:09, Loic Poulain wrote:
> Hi Ian,
> +++ b/drivers/bluetooth/btbcm.c
> @@ -274,7 +274,7 @@ static struct sk_buff *btbcm_read_usb_product(struct
> hci_dev *hdev)
> { 0x410e, "BCM43341B0" }, /* 002.001.014 */
> { 0x4406, "BCM4324B3" }, /* 002.004.006 */
> { 0x610c, "BCM4354" }, /* 003.001.012 */
> + { 0xXXXX, "BCM43430A1" }, /* 001.002.009 */
> { }
> };
>
> Can you replace with the correct subver and submit a patch ?
Will do. I'll have a look at getting any DT fluff done too, if its not
already.
>> PS. Are my emails coming out OK now? I think it's fixed :)
>
> It looks good.
Awesome, ta!
-Ian
Hi Ian,
>> Would you be able to apply the following change to your
>> kernel/module and retry ?
>>
>> diff --git a/drivers/bluetooth/hci_bcm.c
>> b/drivers/bluetooth/hci_bcm.c index f87bfdf..b6e94ab 100644 ---
>> a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@
>> -423,7 +423,7 @@ static int bcm_setup(struct hci_uart *hu) if (!err)
>> err = bcm_setup_sleep(hu);
>>
>> - return err; + return 0; }
>
> I suspected as much, something on those lines - yes, your patch makes it
> work.
Great!
> Any idea on the below point?
>
>>> I'll prod this a bit tomorrow - in the meantime, is there a known
>>> current/good firmware for this chip? (43430a)
> Mine seems to function, md5sum:
>
> 00b4a75a3bc247f96eb07f12b28dd061 /lib/firmware/brcm/BCM.hcd
Don't know, this is a question for Broadcom.
>
> ls -l /lib/firmware/brcm/BCM.hcd
> -rwxr-xr-x 1 root root 14265 Jun 26 18:23 /lib/firmware/brcm/BCM.hcd
I also suggest to add the subversion in the bcm_uart_subver_table so
that it loads BCM43430A1.hcd instead of the generic BCM.hcd.
+++ b/drivers/bluetooth/btbcm.c
@@ -274,7 +274,7 @@ static struct sk_buff *btbcm_read_usb_product(struct
hci_dev *hdev)
{ 0x410e, "BCM43341B0" }, /* 002.001.014 */
{ 0x4406, "BCM4324B3" }, /* 002.004.006 */
{ 0x610c, "BCM4354" }, /* 003.001.012 */
+ { 0xXXXX, "BCM43430A1" }, /* 001.002.009 */
{ }
};
Can you replace with the correct subver and submit a patch ?
> PS. Are my emails coming out OK now? I think it's fixed :)
It looks good.
Regards,
Loic
On 27/06/17 09:30, Loic Poulain wrote:
> Hi Ian,
Hi!
> Would you be able to apply the following change to your
> kernel/module and retry ?
>
> diff --git a/drivers/bluetooth/hci_bcm.c
> b/drivers/bluetooth/hci_bcm.c index f87bfdf..b6e94ab 100644 ---
> a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@
> -423,7 +423,7 @@ static int bcm_setup(struct hci_uart *hu) if (!err)
> err = bcm_setup_sleep(hu);
>
> - return err; + return 0; }
I suspected as much, something on those lines - yes, your patch makes it
work.
hciconfig
hci0: Type: Primary Bus: UART
BD Address: 43:43:A1:12:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING PSCAN ISCAN
RX bytes:8823 acl:150 sco:0 events:333 errors:0
TX bytes:26178 acl:150 sco:0 commands:173 errors:0
Its considerably more reliable at scanning thus far, too.
Any idea on the below point?
>> I'll prod this a bit tomorrow - in the meantime, is there a known
>> current/good firmware for this chip? (43430a)
Mine seems to function, md5sum:
00b4a75a3bc247f96eb07f12b28dd061 /lib/firmware/brcm/BCM.hcd
ls -l /lib/firmware/brcm/BCM.hcd
-rwxr-xr-x 1 root root 14265 Jun 26 18:23 /lib/firmware/brcm/BCM.hcd
PS. Are my emails coming out OK now? I think it's fixed :)
-Ian
Hi Ian,
> OK, so it looks like it is capable of loading the firmware - thats a big
> step. sadly,
>
> hciconfig hci0 up
>
> results in:
>
> Bluetooth: hci0: BCM: chip id 94
> Bluetooth: hci0: BCM (001.002.009) build 0022
> Bluetooth: hci0: BCM (001.002.009) build 0022
> Can't init device hci0: No such device (19)
Good, Looking at the hci_bcm/btbcm driver, seems that you go through the
the bcm_setup procedure
and successfully load the firmware, you rename it BCM.hcd, right ?
However I think the bcm_setup failed because of:
err = bcm_request_irq(bcm);
if (!err)
err = bcm_setup_sleep(hu);
return err;
bcm_request_irq fails since there is no platform device attached to this
uart/tty (no acpi nor DT entry).
So the driver is unable to retrieve resources like gpios/irq,
bcm_request_irq returns -ENODEV.
This should NOT be a problem, since the driver supports this case
(without power control).
However, the bcm_setup procedure returns the err value set by
bcm_request_irq.
Would you be able to apply the following change to your kernel/module
and retry ?
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index f87bfdf..b6e94ab 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -423,7 +423,7 @@ static int bcm_setup(struct hci_uart *hu)
if (!err)
err = bcm_setup_sleep(hu);
- return err;
+ return 0;
}
Regards,
Loic
> however, I can use the old hciattach method to attach to the uart and it
> works - thus the firmware is running.
>
> I'll prod this a bit tomorrow - in the meantime, is there a known
> current/good firmware for this chip? (43430a)
>
> Thanks,
>
> -Ian
On 26/06/17 09:33, Loic Poulain wrote:
> From user-space, you only have to attach your tty with the bcm line
> discipline. btattach is the preferred way. $ btattach -B /dev/ttyX -P
> bcm
>
> What is your platform, do you have ACPI or Device-tree support ? any
> entry corresponding to your bcm controller ?
OK, so it looks like it is capable of loading the firmware - thats a big
step. sadly,
hciconfig hci0 up
results in:
Bluetooth: hci0: BCM: chip id 94
Bluetooth: hci0: BCM (001.002.009) build 0022
Bluetooth: hci0: BCM (001.002.009) build 0022
Can't init device hci0: No such device (19)
however, I can use the old hciattach method to attach to the uart and it
works - thus the firmware is running.
I'll prod this a bit tomorrow - in the meantime, is there a known
current/good firmware for this chip? (43430a)
Thanks,
-Ian
Apologies for the mangled email - I've taken T-bird out the back
and shot it. :-)
-Ian
On 26/06/17 09:33, Loic Poulain wrote:
> Hi Ian, > >> >> # brcm_patchram_plus --patchram
/lib/firmware/bcm/bcm43430a1.hcd >> --no2bytes --tosleep 1000 --bd_addr
<my_addr> /dev/ttymxc1 >> >> >> # hciattach /dev/ttymxc1 any >> >> >> As
I understand it, brcm_patchram_plus just loads firmware into >> the
chip, and hciattach is just hooking the hci-uart driver to the >> serial
port as a line discipline? >> >> Is this the correct approach? is there
a better way to get the >> firmware loaded? >> > > Actually, yes,
bcm43xx is now "in-kernel" supported (firmware > loading, gpio
switching, low power mode...). From user-space, you > only have to
attach your tty with the bcm line discipline. btattach > is the
preferred way. $ btattach -B /dev/ttyX -P bcm > > What is your platform,
do you have ACPI or Device-tree support ? any > entry corresponding to
your bcm controller ?
Oh, thats bloody fantastic - I did look, but must have missed it somehow.
The platform is i.MX6ul, so its device-tree based.
Thanks very much, thats a big help!
I guess I'm going to have to actually figure out how to build the bluez
userspace now, I managed to get stuck on the glib dependency, for some
reason... (my current userspace doesnt have btattach)
-Ian
Hi Ian,
>
> # brcm_patchram_plus --patchram /lib/firmware/bcm/bcm43430a1.hcd
> --no2bytes --tosleep 1000 --bd_addr <my_addr> /dev/ttymxc1
>
>
> # hciattach /dev/ttymxc1 any
>
>
> As I understand it, brcm_patchram_plus just loads firmware into the
> chip, and hciattach is just hooking the hci-uart driver to the serial
> port as a line discipline?
>
> Is this the correct approach? is there a better way to get the
> firmware loaded?
>
Actually, yes, bcm43xx is now "in-kernel" supported (firmware loading,
gpio switching, low power mode...).
From user-space, you only have to attach your tty with the bcm line
discipline.
btattach is the preferred way.
$ btattach -B /dev/ttyX -P bcm
What is your platform, do you have ACPI or Device-tree support ? any
entry corresponding to your bcm controller ?
Regards,
Loic
Replying to myself here...
It seems to me that my system would be considered to have a "soft"
rfkill line, in that the state can be changed from userspace (effectively
turning the hardware on and off).
One approach would be to implement rfkill code that picks up the gpio
state change, and notifies userspace - at which point userspace can
push the firmware up to the device, and call hciattach to re-attach the
interface to the UART.
Is that "correct usage" ?
It seems to me that we only *really* want to power up the bluetooth
device if someone attempts to hciattach it to a UART, so perhaps a better
solution would be to modify the hci_uart code such that it will enable the
GPIO when it is attached, and push the firmware for itself.
I favour the latter approach, as it should work perfectly across sus/res and
wont leave the BT device powered if its not attached to a UART.
Thoughts?
-Ian
On 25/06/17 17:26, Ian Molton wrote:
> Hi, > > > I've been attempting to get bluetooth working on a broadcom
43430 > chip, on 4.12-rc6. > > I've got it to work, at least somewhat. >
> I'm using: > > # brcm_patchram_plus --patchram
/lib/firmware/bcm/bcm43430a1.hcd > --no2bytes --tosleep 1000 --bd_addr
<my_addr> /dev/ttymxc1 > > > # hciattach /dev/ttymxc1 any > > > As I
understand it, brcm_patchram_plus just loads firmware into the > chip,
and hciattach is just hooking the hci-uart driver to the serial > port
as a line discipline? > > Is this the correct approach? is there a
better way to get the > firmware loaded? > > I've also read that
btattach should be used instead of hciattach? is > this the case? > > >
> -Ian -- To unsubscribe from this list: send the line "unsubscribe >
linux-bluetooth" in the body of a message to > [email protected]
More majordomo info at > http://vger.kernel.org/majordomo-info.html