>> I built kernel, modules and dtb from a bluetooth-next tree (4.12 and 4.13-rc3).
>> Using 32-bit multi_v7_defconfig + some additional confs to enable miniuart (BCM2835AUX...) for console.
>> I push this on a raspbian image.
>>
>> my boot/config.txt is very simple (no overlay):
>>
>> kernel=zImage
>> device_tree=bcm2837-rpi-3-b.dtb
>> # hack for miniuart serial clock
>> core_freq=250
>> dtparam=audio=on
>
> so the Fedora 26 kernel that is based on 4.12 is missing uart0 configuration in DT. Adding it to bcm2837-rpi-3-b.dts will allow for btattach to actually work.
I'm the Fedora maintainer for the Raspberry Pi (and a lot of ARM on
Fedora in general).
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_gpio32 &gpclk2_gpio43>;
> status = "okay”;
> };
>
> It kinda works, but not all of it. This command confuses me.
With the upstream kernel, some DT bits headed upstream (ie the Fedora
kernel) plus these patches I get to the "kinda works" too in that it
sees a BT adapter but doesn't give it a mac address.
> < HCI Command: Broadcom Write UART Clock Setting (0x3f|0x0045) plen 1
> 01 .
>> HCI Event: Command Complete (0x0e) plen 4
> Broadcom Write UART Clock Setting (0x3f|0x0045) ncmd 1
> Status: Unknown HCI Command (0x01)
>
> And I am seeing fun stuff like failed frame assembly.
>
> [ 888.687594] Bluetooth: hci0: BCM: chip id 94
> [ 888.687821] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0182
> [ 892.059023] Bluetooth: hci0: Frame reassembly failed (-84)
> [ 892.316936] Bluetooth: hci0: BCM: failed to write clock (-56)
> [ 892.429478] Bluetooth: hci0: BCM (001.002.009) build 0182
>
> Actually not providing the firmware makes the controller work. It however is stuck ad AA:AA:.. default address. Providing the firmware turns the address active. However then it never completes.
I've tried on and off to get the BT working, there seems to lots of
options and bits needed including some patches to the bluez [1] stuff
but between not quite upstream kernel bits and numerous distros all
doing it slightly differently I've never got it to work well.
The yocto [1] bits seem fairly representative of some the patches
flying around "to get it working" although I'm not sure how many of
these are actually required and how many are superfluous with this
patch set. There seems to be a firmware required that's not
distributed with linux-firmware which would also be nice to resolve.
Peter
[1] https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-connectivity/bluez5/bluez5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
