Hi,
so with a 4.15 kernel, the Bluetooth chip on the RPi3 is fully supported via DT and serdev. The only problem still present is that when you rmmod hci_uart and then modprobe hci_uart again it will be stuck.
= New Index: 00:00:00:00:00:00 (Primary,UART,hci0)
= Open Index: 00:00:00:00:00:00
= Index Info: 00:00:00:00:00:00 (Broadcom Corporation)
< HCI Command: Broadcom Update UART Baud Rate (0x3f|0x0018) plen 6
Encoded baud rate: Not used (0x0000)
Explicit baud rate: 2000000 Mbps
< HCI Command: Reset (0x03|0x0003) plen 0
= Close Index: 00:00:00:00:00:00
= Delete Index: 00:00:00:00:00:00
Seems like something with the initial baud rate is wrong. When booting the hardware it is suppose to be set to 115200 Mbps, but it seems to be never reset after unloading the module. It stays at 2000000 Mbps. So when sending the Update UART Baud Rate initial command, it gets send at 115200 Mbps, but in reality the Bluetooth chip is still at 2000000 Mbps. So do we have to pull some reset GPIO to get this back into the original setting? Maybe this is just because the GPIOs are not yet exposed on the RPi3 as of now.
Is there any update to get the GPIO expander work upstream?
One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
Regards
Marcel
Hi Stefan,
>>>>>>> After enabling bluetooth scanning i will see these error messages periodically:
>>>>>>>
>>>>>>> [ 815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>> [ 831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>> [ 847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>> [ 863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>> [ 879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>> I really need to hook up the error messages into the btmon output since then we can trace where these are coming from. Anyway, can you btmon -w trace.log from before loading the module and this error showing up.
>>>>> I attached the log. According to dmesg this error happend only once during the trace.
>>>> I will add bt_dev_err tracing to be include in btmon and that way we can figure out where that error happens. Or do you have a trace.log and dmesg -T where we can correlate it based on time.
>>> Please look at this attachment and the following output (issue appears every 16 seconds after enabling scanning even if i use a baudrate of 115200):
>>>
>>> 2018-02-23T14:12:52,454443+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:13:08,454601+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:13:24,453167+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:13:40,453414+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:13:56,453859+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:14:12,453864+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:14:28,453966+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:14:44,455381+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:15:00,452972+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:15:16,453733+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:15:32,453318+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:15:48,453495+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:16:04,452430+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:16:20,452531+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:16:36,452813+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 2018-02-23T14:16:52,453043+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>
>>> I also noticed a different issue (only tested 4.15 yet), sometimes if i try to unload "modprobe -r hci_uart" the command blocks forever. There is no crash just the command hangs.
>> so it seems that this matched up to the set scan enable command.
> Hm, i only enabled the scanning once. Does bluetoothctl send this command periodically every 16 seconds?
yes, it does interleaved scanning on LE and then BR/EDR. Hence the switch from LE Set Scan Enable to Inquiry etc.
>> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #415 [hci0] 2018-02-23 14:12:52.478963
>> Scanning: Disabled (0x00)
>> Filter duplicates: Disabled (0x00)
>>> HCI Event: Command Complete (0x0e) plen 4 #416 [hci0] 2018-02-23 14:12:52.483769
>> LE Set Scan Enable (0x08|0x000c) ncmd 1
>> Status: Success (0x00)
>>
>> Does this happen with all baud rates or just with 115200?
>
> I've seen this at 115200 and 2000000 baud.
This could be well our issue. I need to check if I can reproduce it.
I assume you use bluetoothctl for enabling scanning. Wonder what happens if you do it only on LE. So “menu scan” and then “transport le”. I think it is really just the switch from LE to BR/EDR where this happens.
Regards
Marcel
Hi Marcel,
Am 26.02.2018 um 09:13 schrieb Marcel Holtmann:
> Hi Stefan,
>
>>>>>> After enabling bluetooth scanning i will see these error messages periodically:
>>>>>>
>>>>>> [ 815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>> [ 831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>> [ 847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>> [ 863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>> [ 879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>> I really need to hook up the error messages into the btmon output since then we can trace where these are coming from. Anyway, can you btmon -w trace.log from before loading the module and this error showing up.
>>>> I attached the log. According to dmesg this error happend only once during the trace.
>>> I will add bt_dev_err tracing to be include in btmon and that way we can figure out where that error happens. Or do you have a trace.log and dmesg -T where we can correlate it based on time.
>> Please look at this attachment and the following output (issue appears every 16 seconds after enabling scanning even if i use a baudrate of 115200):
>>
>> 2018-02-23T14:12:52,454443+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:13:08,454601+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:13:24,453167+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:13:40,453414+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:13:56,453859+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:14:12,453864+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:14:28,453966+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:14:44,455381+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:15:00,452972+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:15:16,453733+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:15:32,453318+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:15:48,453495+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:16:04,452430+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:16:20,452531+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:16:36,452813+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>> 2018-02-23T14:16:52,453043+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>>
>> I also noticed a different issue (only tested 4.15 yet), sometimes if i try to unload "modprobe -r hci_uart" the command blocks forever. There is no crash just the command hangs.
> so it seems that this matched up to the set scan enable command.
Hm, i only enabled the scanning once. Does bluetoothctl send this
command periodically every 16 seconds?
>
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #415 [hci0] 2018-02-23 14:12:52.478963
> Scanning: Disabled (0x00)
> Filter duplicates: Disabled (0x00)
>> HCI Event: Command Complete (0x0e) plen 4 #416 [hci0] 2018-02-23 14:12:52.483769
> LE Set Scan Enable (0x08|0x000c) ncmd 1
> Status: Success (0x00)
>
> Does this happen with all baud rates or just with 115200?
I've seen this at 115200 and 2000000 baud.
Stefan
Hi Stefan,
>>>>> After enabling bluetooth scanning i will see these error messages periodically:
>>>>>
>>>>> [ 815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>> [ 831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>> [ 847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>> [ 863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>> [ 879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>
>>>> I really need to hook up the error messages into the btmon output since then we can trace where these are coming from. Anyway, can you btmon -w trace.log from before loading the module and this error showing up.
>>>
>>> I attached the log. According to dmesg this error happend only once during the trace.
>>
>> I will add bt_dev_err tracing to be include in btmon and that way we can figure out where that error happens. Or do you have a trace.log and dmesg -T where we can correlate it based on time.
>
> Please look at this attachment and the following output (issue appears every 16 seconds after enabling scanning even if i use a baudrate of 115200):
>
> 2018-02-23T14:12:52,454443+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:13:08,454601+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:13:24,453167+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:13:40,453414+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:13:56,453859+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:14:12,453864+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:14:28,453966+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:14:44,455381+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:15:00,452972+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:15:16,453733+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:15:32,453318+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:15:48,453495+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:16:04,452430+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:16:20,452531+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:16:36,452813+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
> 2018-02-23T14:16:52,453043+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
>
> I also noticed a different issue (only tested 4.15 yet), sometimes if i try to unload "modprobe -r hci_uart" the command blocks forever. There is no crash just the command hangs.
so it seems that this matched up to the set scan enable command.
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #415 [hci0] 2018-02-23 14:12:52.478963
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #416 [hci0] 2018-02-23 14:12:52.483769
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
Does this happen with all baud rates or just with 115200?
What could be the case is that the start of inquiry is too fast and the processing internally goes bonkers.
< HCI Command: Inquiry (0x01|0x0001) plen 5 #417 [hci0] 2018-02-23 14:12:52.484027
Access code: 0x9e8b33 (General Inquiry)
Length: 5.12s (0x04)
Num responses: 0
> HCI Event: Command Status (0x0f) plen 4 #418 [hci0] 2018-02-23 14:12:52.486440
Inquiry (0x01|0x0001) ncmd 1
Status: Success (0x00)
The inquiry command is actually answered with a command status.
Johan, any ideas?
>>>>> Btw: Linus Wallej applied the GPIO expander driver
>>>>
>>>> That is awesome. Do you see any difference now if you hook up the GPIO in DT. Mind you to change the resources part to allow using only the shutdown GPIO and not having the device-wakeup GPIO.
>>>
>>> The RPi Zero W doesn't have a GPIO expander and the RPi 3 also uses the BT_ON line (via GPIO expander). So i don't expect any difference between them.
>>
>> So on the Zero W the BT_ON GPIO is exposed without the expander? And the 3 needs the expander? Is that how they are designed?
>
> Yes. Yes. I only have the firmware devicetree file [1] as reference.
>
> Btw there is another difference between Zero W and 3. The Zero W could uses the hardware flow-control pins, the 3 not.
>
> How does the Broadcom BT driver know about the flow control?
> Is it sufficient to add "uart-has-rtscts"?
>
> [1] - https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts#L1536
I have no answer for this, but using flow control is required for H:4 operation as far as I remember.
Regards
Marcel
Hi Marcel,
> Marcel Holtmann <[email protected]> hat am 22. Februar 2018 um 19:50 geschrieben:
>
>
> Hi Stefan,
>
> >>>
> >>> After enabling bluetooth scanning i will see these error messages periodically:
> >>>
> >>> [ 815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
> >>> [ 831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
> >>> [ 847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
> >>> [ 863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
> >>> [ 879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)
> >>
> >> I really need to hook up the error messages into the btmon output since then we can trace where these are coming from. Anyway, can you btmon -w trace.log from before loading the module and this error showing up.
> >
> > I attached the log. According to dmesg this error happend only once during the trace.
>
> I will add bt_dev_err tracing to be include in btmon and that way we can figure out where that error happens. Or do you have a trace.log and dmesg -T where we can correlate it based on time.
Please look at this attachment and the following output (issue appears every 16 seconds after enabling scanning even if i use a baudrate of 115200):
2018-02-23T14:12:52,454443+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:13:08,454601+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:13:24,453167+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:13:40,453414+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:13:56,453859+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:14:12,453864+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:14:28,453966+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:14:44,455381+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:15:00,452972+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:15:16,453733+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:15:32,453318+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:15:48,453495+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:16:04,452430+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:16:20,452531+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:16:36,452813+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
2018-02-23T14:16:52,453043+0100 Bluetooth: hci0: last event is not cmd complete (0x0f)
I also noticed a different issue (only tested 4.15 yet), sometimes if i try to unload "modprobe -r hci_uart" the command blocks forever. There is no crash just the command hangs.
>
> >>> Btw: Linus Wallej applied the GPIO expander driver
> >>
> >> That is awesome. Do you see any difference now if you hook up the GPIO in DT. Mind you to change the resources part to allow using only the shutdown GPIO and not having the device-wakeup GPIO.
> >
> > The RPi Zero W doesn't have a GPIO expander and the RPi 3 also uses the BT_ON line (via GPIO expander). So i don't expect any difference between them.
>
> So on the Zero W the BT_ON GPIO is exposed without the expander? And the 3 needs the expander? Is that how they are designed?
Yes. Yes. I only have the firmware devicetree file [1] as reference.
Btw there is another difference between Zero W and 3. The Zero W could uses the hardware flow-control pins, the 3 not.
How does the Broadcom BT driver know about the flow control?
Is it sufficient to add "uart-has-rtscts"?
[1] - https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts#L1536
> I have Zero W here, but no toolchain available for it.
How about using the Linaro ARMHF toolchain?
Stefan
>
> >> Also let me guess, 4.15 is fine, but 4.16-rc1 or later fails because of the Apple changes.
> >
> > Didn't tried it yet.
>
> If you have a chance, please do. I think it needs a patch for 4.16-rc1 to make it work again. Otherwise I am happy that we finally can get the RPi working without btattach. Next step is to also read out and set the PCM configuration.
>
> Regards
>
> Marcel
>
Hi Stefan,
>>>>>>>>>>>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
>>>>>>>>>>> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
>>>>>>>>>>
>>>>>>>>>> We may also reset to initialization speed on module unload.
>>>>>>>>>> This will allow multiple tests on the hardware, even if it does not have GPIOs exposed.
>>>>>>>>>
>>>>>>>>> I prefer this solution instead of coding workarounds within the devicetree.
>>>>>>>>
>>>>>>>> DT is actually for encoding workarounds for the hardware. If the GPIOs are not exposed, we are actually limited. However I am going to do that in the hci_bcm.c driver itself since it is a more wider problem. If the GPIO resources are not available, the device will actually not function. This is actually a valid assumption for all hardwired Bluetooth chips. They all have some GPIO or power control option. The only reason to not have GPIOs would be external development boards. So the RPi with the not exposed GPIOs is kinda broken hardware right now. That we got this far supporting Bluetooth on it has to be considered pure luck :)
>>>>>>>
>>>>>>> only to make sure that we talking about the same, please take a look at my attempt for the RPi Zero W [1].
>>>>>>>
>>>>>>> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn't test the reload case yet.
>>>>>>>
>>>>>>> So after the implementation of the RPI firmware expander driver, we still need this baudrate limitiation?
>>>>>>>
>>>>>>> Btw Baruch said that he will send a new version of his patch series soon.
>>>>>>>
>>>>>>> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69f2e32d35827635b95cf966
>>>>>>
>>>>>> before you include "shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;” we might need to figure out on how the BT_ON GPIO is working and what it is suppose to be doing. But otherwise the patch fro the Zero W looks right to me.
>>>>>>
>>>>>> Also keep in mind that the current 4.16-rc2 kernel will require the shutdown-gpios and device-wakeup-gpios both to be available. We have not yet tested this when only shutdown-gpios is available. You might need to modify bcm_get_resources and bcm_gpio_set_power to test this out.
>>>>>
>>>>> i think this contradicts to the binding documentation, which defines both as optional.
>>>>
>>>> the 4.15 kernel might be fine actually while the support for Apple hardware with Broadcom UART devices might have accidentally required this now. Maybe you just want to hack your kernel and see how it goes when just having the shutdown-gpios available.
>>>>
>>>> I am super curious if the firmware resets and falls back to the ROM state or if something is actually kept.
>>>
>>> since i don't have any schematics about the BT part, i simply retested my patches against 4.15 on RPi Zero W.
>>>
>>> modprobe -r hci_uart
>>> modprobe hci_uart
>>>
>>> works without any issues:
>>>
>>> [ 233.486208] Bluetooth: HCI UART driver ver 2.3
>>> [ 233.486258] Bluetooth: HCI UART protocol H4 registered
>>> [ 233.487189] hci_uart_bcm serial0-0: BCM irq: -22
>>> [ 233.488382] Bluetooth: HCI UART protocol Broadcom registered
>>> [ 233.641217] Bluetooth: hci0: BCM: chip id 94
>>> [ 233.642081] Bluetooth: hci0: BCM: features 0x2e
>>> [ 233.644283] Bluetooth: hci0: BCM43430A1
>>> [ 233.644321] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>> [ 234.360569] Bluetooth: hci0: BCM (001.002.009) build 0325
>>>
>>> After enabling bluetooth scanning i will see these error messages periodically:
>>>
>>> [ 815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> [ 831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> [ 847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> [ 863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> [ 879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>
>> I really need to hook up the error messages into the btmon output since then we can trace where these are coming from. Anyway, can you btmon -w trace.log from before loading the module and this error showing up.
>
> I attached the log. According to dmesg this error happend only once during the trace.
I will add bt_dev_err tracing to be include in btmon and that way we can figure out where that error happens. Or do you have a trace.log and dmesg -T where we can correlate it based on time.
>>> Btw: Linus Wallej applied the GPIO expander driver
>>
>> That is awesome. Do you see any difference now if you hook up the GPIO in DT. Mind you to change the resources part to allow using only the shutdown GPIO and not having the device-wakeup GPIO.
>
> The RPi Zero W doesn't have a GPIO expander and the RPi 3 also uses the BT_ON line (via GPIO expander). So i don't expect any difference between them.
So on the Zero W the BT_ON GPIO is exposed without the expander? And the 3 needs the expander? Is that how they are designed? I have Zero W here, but no toolchain available for it.
>> Also let me guess, 4.15 is fine, but 4.16-rc1 or later fails because of the Apple changes.
>
> Didn't tried it yet.
If you have a chance, please do. I think it needs a patch for 4.16-rc1 to make it work again. Otherwise I am happy that we finally can get the RPi working without btattach. Next step is to also read out and set the PCM configuration.
Regards
Marcel
Hi Marcel,
> Marcel Holtmann <[email protected]> hat am 22. Februar 2018 um 16:43 geschrieben:
>
>
> Hi Stefan,
>
> >>>>>>>>>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
> >>>>>>>>> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
> >>>>>>>>
> >>>>>>>> We may also reset to initialization speed on module unload.
> >>>>>>>> This will allow multiple tests on the hardware, even if it does not have GPIOs exposed.
> >>>>>>>
> >>>>>>> I prefer this solution instead of coding workarounds within the devicetree.
> >>>>>>
> >>>>>> DT is actually for encoding workarounds for the hardware. If the GPIOs are not exposed, we are actually limited. However I am going to do that in the hci_bcm.c driver itself since it is a more wider problem. If the GPIO resources are not available, the device will actually not function. This is actually a valid assumption for all hardwired Bluetooth chips. They all have some GPIO or power control option. The only reason to not have GPIOs would be external development boards. So the RPi with the not exposed GPIOs is kinda broken hardware right now. That we got this far supporting Bluetooth on it has to be considered pure luck :)
> >>>>>
> >>>>> only to make sure that we talking about the same, please take a look at my attempt for the RPi Zero W [1].
> >>>>>
> >>>>> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn't test the reload case yet.
> >>>>>
> >>>>> So after the implementation of the RPI firmware expander driver, we still need this baudrate limitiation?
> >>>>>
> >>>>> Btw Baruch said that he will send a new version of his patch series soon.
> >>>>>
> >>>>> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69f2e32d35827635b95cf966
> >>>>
> >>>> before you include "shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;” we might need to figure out on how the BT_ON GPIO is working and what it is suppose to be doing. But otherwise the patch fro the Zero W looks right to me.
> >>>>
> >>>> Also keep in mind that the current 4.16-rc2 kernel will require the shutdown-gpios and device-wakeup-gpios both to be available. We have not yet tested this when only shutdown-gpios is available. You might need to modify bcm_get_resources and bcm_gpio_set_power to test this out.
> >>>
> >>> i think this contradicts to the binding documentation, which defines both as optional.
> >>
> >> the 4.15 kernel might be fine actually while the support for Apple hardware with Broadcom UART devices might have accidentally required this now. Maybe you just want to hack your kernel and see how it goes when just having the shutdown-gpios available.
> >>
> >> I am super curious if the firmware resets and falls back to the ROM state or if something is actually kept.
> >
> > since i don't have any schematics about the BT part, i simply retested my patches against 4.15 on RPi Zero W.
> >
> > modprobe -r hci_uart
> > modprobe hci_uart
> >
> > works without any issues:
> >
> > [ 233.486208] Bluetooth: HCI UART driver ver 2.3
> > [ 233.486258] Bluetooth: HCI UART protocol H4 registered
> > [ 233.487189] hci_uart_bcm serial0-0: BCM irq: -22
> > [ 233.488382] Bluetooth: HCI UART protocol Broadcom registered
> > [ 233.641217] Bluetooth: hci0: BCM: chip id 94
> > [ 233.642081] Bluetooth: hci0: BCM: features 0x2e
> > [ 233.644283] Bluetooth: hci0: BCM43430A1
> > [ 233.644321] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> > [ 234.360569] Bluetooth: hci0: BCM (001.002.009) build 0325
> >
> > After enabling bluetooth scanning i will see these error messages periodically:
> >
> > [ 815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
> > [ 831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
> > [ 847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
> > [ 863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
> > [ 879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)
>
> I really need to hook up the error messages into the btmon output since then we can trace where these are coming from. Anyway, can you btmon -w trace.log from before loading the module and this error showing up.
I attached the log. According to dmesg this error happend only once during the trace.
>
> > Btw: Linus Wallej applied the GPIO expander driver
>
> That is awesome. Do you see any difference now if you hook up the GPIO in DT. Mind you to change the resources part to allow using only the shutdown GPIO and not having the device-wakeup GPIO.
The RPi Zero W doesn't have a GPIO expander and the RPi 3 also uses the BT_ON line (via GPIO expander). So i don't expect any difference between them.
>
> Also let me guess, 4.15 is fine, but 4.16-rc1 or later fails because of the Apple changes.
Didn't tried it yet.
Regards
Stefan
>
> Regards
>
> Marcel
>
Hi Stefan,
>>>>>>>>>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
>>>>>>>>> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
>>>>>>>>
>>>>>>>> We may also reset to initialization speed on module unload.
>>>>>>>> This will allow multiple tests on the hardware, even if it does not have GPIOs exposed.
>>>>>>>
>>>>>>> I prefer this solution instead of coding workarounds within the devicetree.
>>>>>>
>>>>>> DT is actually for encoding workarounds for the hardware. If the GPIOs are not exposed, we are actually limited. However I am going to do that in the hci_bcm.c driver itself since it is a more wider problem. If the GPIO resources are not available, the device will actually not function. This is actually a valid assumption for all hardwired Bluetooth chips. They all have some GPIO or power control option. The only reason to not have GPIOs would be external development boards. So the RPi with the not exposed GPIOs is kinda broken hardware right now. That we got this far supporting Bluetooth on it has to be considered pure luck :)
>>>>>
>>>>> only to make sure that we talking about the same, please take a look at my attempt for the RPi Zero W [1].
>>>>>
>>>>> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn't test the reload case yet.
>>>>>
>>>>> So after the implementation of the RPI firmware expander driver, we still need this baudrate limitiation?
>>>>>
>>>>> Btw Baruch said that he will send a new version of his patch series soon.
>>>>>
>>>>> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69f2e32d35827635b95cf966
>>>>
>>>> before you include "shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;” we might need to figure out on how the BT_ON GPIO is working and what it is suppose to be doing. But otherwise the patch fro the Zero W looks right to me.
>>>>
>>>> Also keep in mind that the current 4.16-rc2 kernel will require the shutdown-gpios and device-wakeup-gpios both to be available. We have not yet tested this when only shutdown-gpios is available. You might need to modify bcm_get_resources and bcm_gpio_set_power to test this out.
>>>
>>> i think this contradicts to the binding documentation, which defines both as optional.
>>
>> the 4.15 kernel might be fine actually while the support for Apple hardware with Broadcom UART devices might have accidentally required this now. Maybe you just want to hack your kernel and see how it goes when just having the shutdown-gpios available.
>>
>> I am super curious if the firmware resets and falls back to the ROM state or if something is actually kept.
>
> since i don't have any schematics about the BT part, i simply retested my patches against 4.15 on RPi Zero W.
>
> modprobe -r hci_uart
> modprobe hci_uart
>
> works without any issues:
>
> [ 233.486208] Bluetooth: HCI UART driver ver 2.3
> [ 233.486258] Bluetooth: HCI UART protocol H4 registered
> [ 233.487189] hci_uart_bcm serial0-0: BCM irq: -22
> [ 233.488382] Bluetooth: HCI UART protocol Broadcom registered
> [ 233.641217] Bluetooth: hci0: BCM: chip id 94
> [ 233.642081] Bluetooth: hci0: BCM: features 0x2e
> [ 233.644283] Bluetooth: hci0: BCM43430A1
> [ 233.644321] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> [ 234.360569] Bluetooth: hci0: BCM (001.002.009) build 0325
>
> After enabling bluetooth scanning i will see these error messages periodically:
>
> [ 815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
> [ 831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
> [ 847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
> [ 863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
> [ 879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)
I really need to hook up the error messages into the btmon output since then we can trace where these are coming from. Anyway, can you btmon -w trace.log from before loading the module and this error showing up.
> Btw: Linus Wallej applied the GPIO expander driver
That is awesome. Do you see any difference now if you hook up the GPIO in DT. Mind you to change the resources part to allow using only the shutdown GPIO and not having the device-wakeup GPIO.
Also let me guess, 4.15 is fine, but 4.16-rc1 or later fails because of the Apple changes.
Regards
Marcel
Hi Marcel,
> Marcel Holtmann <[email protected]> hat am 19. Februar 2018 um 19:58 ge=
schrieben:
>=20
>=20
> Hi Stefan,
>=20
> >>>>>>>>> One option is of course to keep the max-speed in the DT at 1152=
00 Mbps. It would work, but seriously slow down the transport. Maybe this s=
hould be done until we get access to the GPIOs.
> >>>>>>> So I am convinced when we run on hardware that has no GPIO resour=
ces exposed (as it is with RPi right now), we should limit the operational =
speed to the initialization speed. And then my problem actually goes away. =
It also forces people to get the GPIOs exposed or they have to stick with a=
slower HCI transport.
> >>>>>>=20
> >>>>>> We may also reset to initialization speed on module unload.
> >>>>>> This will allow multiple tests on the hardware, even if it does no=
t have GPIOs exposed.
> >>>>>=20
> >>>>> I prefer this solution instead of coding workarounds within the dev=
icetree.
> >>>>=20
> >>>> DT is actually for encoding workarounds for the hardware. If the GPI=
Os are not exposed, we are actually limited. However I am going to do that =
in the hci_bcm.c driver itself since it is a more wider problem. If the GPI=
O resources are not available, the device will actually not function. This =
is actually a valid assumption for all hardwired Bluetooth chips. They all =
have some GPIO or power control option. The only reason to not have GPIOs w=
ould be external development boards. So the RPi with the not exposed GPIOs =
is kinda broken hardware right now. That we got this far supporting Bluetoo=
th on it has to be considered pure luck :)
> >>>=20
> >>> only to make sure that we talking about the same, please take a look =
at my attempt for the RPi Zero W [1].
> >>>=20
> >>> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i di=
dn't test the reload case yet.
> >>>=20
> >>> So after the implementation of the RPI firmware expander driver, we s=
till need this baudrate limitiation?
> >>>=20
> >>> Btw Baruch said that he will send a new version of his patch series s=
oon.
> >>>=20
> >>> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a=
69f2e32d35827635b95cf966
> >>=20
> >> before you include "shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>;=E2=
=80=9D we might need to figure out on how the BT_ON GPIO is working and wha=
t it is suppose to be doing. But otherwise the patch fro the Zero W looks r=
ight to me.
> >>=20
> >> Also keep in mind that the current 4.16-rc2 kernel will require the sh=
utdown-gpios and device-wakeup-gpios both to be available. We have not yet =
tested this when only shutdown-gpios is available. You might need to modify=
bcm_get_resources and bcm_gpio_set_power to test this out.
> >=20
> > i think this contradicts to the binding documentation, which defines bo=
th as optional.
>=20
> the 4.15 kernel might be fine actually while the support for Apple hardwa=
re with Broadcom UART devices might have accidentally required this now. Ma=
ybe you just want to hack your kernel and see how it goes when just having =
the shutdown-gpios available.
>=20
> I am super curious if the firmware resets and falls back to the ROM state=
or if something is actually kept.
since i don't have any schematics about the BT part, i simply retested my p=
atches against 4.15 on RPi Zero W.
modprobe -r hci_uart
modprobe hci_uart
works without any issues:
[ 233.486208] Bluetooth: HCI UART driver ver 2.3
[ 233.486258] Bluetooth: HCI UART protocol H4 registered
[ 233.487189] hci_uart_bcm serial0-0: BCM irq: -22
[ 233.488382] Bluetooth: HCI UART protocol Broadcom registered
[ 233.641217] Bluetooth: hci0: BCM: chip id 94
[ 233.642081] Bluetooth: hci0: BCM: features 0x2e
[ 233.644283] Bluetooth: hci0: BCM43430A1
[ 233.644321] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
[ 234.360569] Bluetooth: hci0: BCM (001.002.009) build 0325
After enabling bluetooth scanning i will see these error messages periodica=
lly:
[ 815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
[ 831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
[ 847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
[ 863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
[ 879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)
Btw: Linus Wallej applied the GPIO expander driver
Stefan
>=20
> Regards
>=20
> Marcel
>
Hi Stefan,
>>>>>>>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
>>>>>>> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
>>>>>>
>>>>>> We may also reset to initialization speed on module unload.
>>>>>> This will allow multiple tests on the hardware, even if it does not have GPIOs exposed.
>>>>>
>>>>> I prefer this solution instead of coding workarounds within the devicetree.
>>>>
>>>> DT is actually for encoding workarounds for the hardware. If the GPIOs are not exposed, we are actually limited. However I am going to do that in the hci_bcm.c driver itself since it is a more wider problem. If the GPIO resources are not available, the device will actually not function. This is actually a valid assumption for all hardwired Bluetooth chips. They all have some GPIO or power control option. The only reason to not have GPIOs would be external development boards. So the RPi with the not exposed GPIOs is kinda broken hardware right now. That we got this far supporting Bluetooth on it has to be considered pure luck :)
>>>
>>> only to make sure that we talking about the same, please take a look at my attempt for the RPi Zero W [1].
>>>
>>> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn't test the reload case yet.
>>>
>>> So after the implementation of the RPI firmware expander driver, we still need this baudrate limitiation?
>>>
>>> Btw Baruch said that he will send a new version of his patch series soon.
>>>
>>> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69f2e32d35827635b95cf966
>>
>> before you include "shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;” we might need to figure out on how the BT_ON GPIO is working and what it is suppose to be doing. But otherwise the patch fro the Zero W looks right to me.
>>
>> Also keep in mind that the current 4.16-rc2 kernel will require the shutdown-gpios and device-wakeup-gpios both to be available. We have not yet tested this when only shutdown-gpios is available. You might need to modify bcm_get_resources and bcm_gpio_set_power to test this out.
>
> i think this contradicts to the binding documentation, which defines both as optional.
the 4.15 kernel might be fine actually while the support for Apple hardware with Broadcom UART devices might have accidentally required this now. Maybe you just want to hack your kernel and see how it goes when just having the shutdown-gpios available.
I am super curious if the firmware resets and falls back to the ROM state or if something is actually kept.
Regards
Marcel
Hi Marcel,
> Marcel Holtmann <[email protected]> hat am 19. Februar 2018 um 19:38 ge=
schrieben:
>=20
>=20
> Hi Stefan,
>=20
> >>>>>>> One option is of course to keep the max-speed in the DT at 115200=
Mbps. It would work, but seriously slow down the transport. Maybe this sho=
uld be done until we get access to the GPIOs.
> >>>>> So I am convinced when we run on hardware that has no GPIO resource=
s exposed (as it is with RPi right now), we should limit the operational sp=
eed to the initialization speed. And then my problem actually goes away. It=
also forces people to get the GPIOs exposed or they have to stick with a s=
lower HCI transport.
> >>>>=20
> >>>> We may also reset to initialization speed on module unload.
> >>>> This will allow multiple tests on the hardware, even if it does not =
have GPIOs exposed.
> >>>=20
> >>> I prefer this solution instead of coding workarounds within the devic=
etree.
> >>=20
> >> DT is actually for encoding workarounds for the hardware. If the GPIOs=
are not exposed, we are actually limited. However I am going to do that in=
the hci_bcm.c driver itself since it is a more wider problem. If the GPIO =
resources are not available, the device will actually not function. This is=
actually a valid assumption for all hardwired Bluetooth chips. They all ha=
ve some GPIO or power control option. The only reason to not have GPIOs wou=
ld be external development boards. So the RPi with the not exposed GPIOs is=
kinda broken hardware right now. That we got this far supporting Bluetooth=
on it has to be considered pure luck :)
> >=20
> > only to make sure that we talking about the same, please take a look at=
my attempt for the RPi Zero W [1].
> >=20
> > Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn=
't test the reload case yet.
> >=20
> > So after the implementation of the RPI firmware expander driver, we sti=
ll need this baudrate limitiation?
> >=20
> > Btw Baruch said that he will send a new version of his patch series soo=
n.
> >=20
> > [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69=
f2e32d35827635b95cf966
>=20
> before you include "shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>;=E2=80=
=9D we might need to figure out on how the BT_ON GPIO is working and what i=
t is suppose to be doing. But otherwise the patch fro the Zero W looks righ=
t to me.
>=20
> Also keep in mind that the current 4.16-rc2 kernel will require the shutd=
own-gpios and device-wakeup-gpios both to be available. We have not yet tes=
ted this when only shutdown-gpios is available. You might need to modify bc=
m_get_resources and bcm_gpio_set_power to test this out.
i think this contradicts to the binding documentation, which defines both a=
s optional.
Stefan
>=20
> Regards
>=20
> Marcel
>
Hi Stefan,
>>>>>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
>>>>> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
>>>>
>>>> We may also reset to initialization speed on module unload.
>>>> This will allow multiple tests on the hardware, even if it does not have GPIOs exposed.
>>>
>>> I prefer this solution instead of coding workarounds within the devicetree.
>>
>> DT is actually for encoding workarounds for the hardware. If the GPIOs are not exposed, we are actually limited. However I am going to do that in the hci_bcm.c driver itself since it is a more wider problem. If the GPIO resources are not available, the device will actually not function. This is actually a valid assumption for all hardwired Bluetooth chips. They all have some GPIO or power control option. The only reason to not have GPIOs would be external development boards. So the RPi with the not exposed GPIOs is kinda broken hardware right now. That we got this far supporting Bluetooth on it has to be considered pure luck :)
>
> only to make sure that we talking about the same, please take a look at my attempt for the RPi Zero W [1].
>
> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn't test the reload case yet.
>
> So after the implementation of the RPI firmware expander driver, we still need this baudrate limitiation?
>
> Btw Baruch said that he will send a new version of his patch series soon.
>
> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69f2e32d35827635b95cf966
before you include "shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;” we might need to figure out on how the BT_ON GPIO is working and what it is suppose to be doing. But otherwise the patch fro the Zero W looks right to me.
Also keep in mind that the current 4.16-rc2 kernel will require the shutdown-gpios and device-wakeup-gpios both to be available. We have not yet tested this when only shutdown-gpios is available. You might need to modify bcm_get_resources and bcm_gpio_set_power to test this out.
Regards
Marcel
Hi Marcel,
> Marcel Holtmann <[email protected]> hat am 19. Februar 2018 um 14:16 geschrieben:
>
>
> Hi Stefan,
>
> >>>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
> >>> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
> >>
> >> We may also reset to initialization speed on module unload.
> >> This will allow multiple tests on the hardware, even if it does not have GPIOs exposed.
> >
> > I prefer this solution instead of coding workarounds within the devicetree.
>
> DT is actually for encoding workarounds for the hardware. If the GPIOs are not exposed, we are actually limited. However I am going to do that in the hci_bcm.c driver itself since it is a more wider problem. If the GPIO resources are not available, the device will actually not function. This is actually a valid assumption for all hardwired Bluetooth chips. They all have some GPIO or power control option. The only reason to not have GPIOs would be external development boards. So the RPi with the not exposed GPIOs is kinda broken hardware right now. That we got this far supporting Bluetooth on it has to be considered pure luck :)
only to make sure that we talking about the same, please take a look at my attempt for the RPi Zero W [1].
Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn't test the reload case yet.
So after the implementation of the RPI firmware expander driver, we still need this baudrate limitiation?
Btw Baruch said that he will send a new version of his patch series soon.
[1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69f2e32d35827635b95cf966
>
> Regards
>
> Marcel
>
Hi Stefan,
>>>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
>>> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
>>
>> We may also reset to initialization speed on module unload.
>> This will allow multiple tests on the hardware, even if it does not have GPIOs exposed.
>
> I prefer this solution instead of coding workarounds within the devicetree.
DT is actually for encoding workarounds for the hardware. If the GPIOs are not exposed, we are actually limited. However I am going to do that in the hci_bcm.c driver itself since it is a more wider problem. If the GPIO resources are not available, the device will actually not function. This is actually a valid assumption for all hardwired Bluetooth chips. They all have some GPIO or power control option. The only reason to not have GPIOs would be external development boards. So the RPi with the not exposed GPIOs is kinda broken hardware right now. That we got this far supporting Bluetooth on it has to be considered pure luck :)
Regards
Marcel
Hi Fred,
>>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
>> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
>
> We may also reset to initialization speed on module unload.
> This will allow multiple tests on the hardware, even if it does not have GPIOs exposed.
you would have to do that on hci_unregister_dev and that is also tricky. If the device is down, we need to spin the transport back up and actually support HCI transaction like within hdev->setup(). It also means that we would have to take care of a lot of struct device lifetime rules etc since this might actually take some time. And if it still fails, the device is still borked.
So I had thought about this briefly and looked into adding infrastructure into Bluetooth core for a hdev->cleanup() function, but just adding it for a hardware that actually has a GPIO, but doesn’t expose it right now seems really like a lot of code for nothing. This means limiting it to 115200 baud initially until someone comes along and gets the GPIO integrated seems more encouraging than hacking around it. And this would be hacking around it.
Regards
Marcel
Am 19.02.2018 um 11:10 schrieb Frédéric Danis:
> Hi Marcel,
>
> Le 18/02/2018 à 20:07, Marcel Holtmann a écrit :
>>
>>>> One option is of course to keep the max-speed in the DT at 115200
>>>> Mbps. It would work, but seriously slow down the transport. Maybe
>>>> this should be done until we get access to the GPIOs.
>> So I am convinced when we run on hardware that has no GPIO resources
>> exposed (as it is with RPi right now), we should limit the
>> operational speed to the initialization speed. And then my problem
>> actually goes away. It also forces people to get the GPIOs exposed or
>> they have to stick with a slower HCI transport.
>
> We may also reset to initialization speed on module unload.
> This will allow multiple tests on the hardware, even if it does not
> have GPIOs exposed.
I prefer this solution instead of coding workarounds within the devicetree.
Thanks
Stefan
>
> Regards,
>
> Fred
>
Hi Marcel,
Le 18/02/2018 à 20:07, Marcel Holtmann a écrit :
>
>>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
> So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
We may also reset to initialization speed on module unload.
This will allow multiple tests on the hardware, even if it does not have
GPIOs exposed.
Regards,
Fred
--
Frédéric Danis Embedded Linux Consultant
[email protected]
Hi Stefan,
>> so with a 4.15 kernel, the Bluetooth chip on the RPi3 is fully supported via DT and serdev. The only problem still present is that when you rmmod hci_uart and then modprobe hci_uart again it will be stuck.
>>
>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0)
>> = Open Index: 00:00:00:00:00:00
>> = Index Info: 00:00:00:00:00:00 (Broadcom Corporation)
>> < HCI Command: Broadcom Update UART Baud Rate (0x3f|0x0018) plen 6
>> Encoded baud rate: Not used (0x0000)
>> Explicit baud rate: 2000000 Mbps
>> < HCI Command: Reset (0x03|0x0003) plen 0
>> = Close Index: 00:00:00:00:00:00
>> = Delete Index: 00:00:00:00:00:00
>>
>> Seems like something with the initial baud rate is wrong. When booting the hardware it is suppose to be set to 115200 Mbps, but it seems to be never reset after unloading the module. It stays at 2000000 Mbps. So when sending the Update UART Baud Rate initial command, it gets send at 115200 Mbps, but in reality the Bluetooth chip is still at 2000000 Mbps. So do we have to pull some reset GPIO to get this back into the original setting? Maybe this is just because the GPIOs are not yet exposed on the RPi3 as of now.
>
> The datasheet says the default baudrate is at 115.200 Kbaud, but it also support automatic baudrate detection. So a reset via GPIO should enforce this baudrate.
the only thing I wonder is if the BT_ON GPIO will full hard reset the device so that it needs the firmware again or just soft reset it. But unless we have that GPIO exposed, it is hard to tell.
>> Is there any update to get the GPIO expander work upstream?
>
> The latest version of the GPIO expander patch series is here [1]. Unfortunately not merged yet.
Is there any feedback on it. Looks super straight forward to me.
> I plan to provide bluetooth support for RPi Zero W. Is there anything missing from driver side?
I think just the DT part fo the RPi Zero W should be missing. However it seems when adding Apple support, we broke the RPi support. I have a patch for it that will make it work again. Not having the “shutdown” and “device-wakeup” GPIOs makes it fail the resource setup. So when you test the DT changes, test them with a 4.15 kernel and not 4.16-rc1.
>> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
So I am convinced when we run on hardware that has no GPIO resources exposed (as it is with RPi right now), we should limit the operational speed to the initialization speed. And then my problem actually goes away. It also forces people to get the GPIOs exposed or they have to stick with a slower HCI transport.
Regards
Marcel
> Stefan Wahren <[email protected]> hat am 18. Februar 2018 um 14:54 geschrieben:
>
>
> Hi Marcel,
>
> > Marcel Holtmann <[email protected]> hat am 17. Februar 2018 um 22:09 geschrieben:
>
> >
> > Is there any update to get the GPIO expander work upstream?
>
> The latest version of the GPIO expander patch series is here [1]. Unfortunately not merged yet.
>
> I plan to provide bluetooth support for RPi Zero W. Is there anything missing from driver side?
>
> Stefan
>
> [1] - http://lists.infradead.org/pipermail/linux-rpi-kernel/2018-January/007397.html
>
Sorry, this was a wrong link.
https://marc.info/?l=linux-arm-kernel&m=151802865717414&w=2
Hi Marcel,
> Marcel Holtmann <[email protected]> hat am 17. Februar 2018 um 22:09 geschrieben:
>
>
> Hi,
>
> so with a 4.15 kernel, the Bluetooth chip on the RPi3 is fully supported via DT and serdev. The only problem still present is that when you rmmod hci_uart and then modprobe hci_uart again it will be stuck.
>
> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0)
> = Open Index: 00:00:00:00:00:00
> = Index Info: 00:00:00:00:00:00 (Broadcom Corporation)
> < HCI Command: Broadcom Update UART Baud Rate (0x3f|0x0018) plen 6
> Encoded baud rate: Not used (0x0000)
> Explicit baud rate: 2000000 Mbps
> < HCI Command: Reset (0x03|0x0003) plen 0
> = Close Index: 00:00:00:00:00:00
> = Delete Index: 00:00:00:00:00:00
>
> Seems like something with the initial baud rate is wrong. When booting the hardware it is suppose to be set to 115200 Mbps, but it seems to be never reset after unloading the module. It stays at 2000000 Mbps. So when sending the Update UART Baud Rate initial command, it gets send at 115200 Mbps, but in reality the Bluetooth chip is still at 2000000 Mbps. So do we have to pull some reset GPIO to get this back into the original setting? Maybe this is just because the GPIOs are not yet exposed on the RPi3 as of now.
The datasheet says the default baudrate is at 115.200 Kbaud, but it also support automatic baudrate detection. So a reset via GPIO should enforce this baudrate.
>
> Is there any update to get the GPIO expander work upstream?
The latest version of the GPIO expander patch series is here [1]. Unfortunately not merged yet.
I plan to provide bluetooth support for RPi Zero W. Is there anything missing from driver side?
Stefan
[1] - http://lists.infradead.org/pipermail/linux-rpi-kernel/2018-January/007397.html
>
> One option is of course to keep the max-speed in the DT at 115200 Mbps. It would work, but seriously slow down the transport. Maybe this should be done until we get access to the GPIOs.
>
> Regards
>
> Marcel
>