Dear community,
I am trying to use the brcm_patchram_plus program to initialise
broadcom bcm4354A2 on my target with 3.10 Linux kernel. Currently the
hci0 can be found UP, however, it doesn't seem to function properly.
For example, the scan command timed out:
/ # hcitool scan
Scanning ...
Inquiry failed: Connection timed out
/ #
The hcidump says that there was NO relevant HCI Event packet received
as its response:
< HCI Command: Inquiry (0x01|0x0001) plen 5
lap 0x9e8b33 len 8 num 0
Relevant syslog reads:
Apr 5 05:44:53 armv8-generic-okl4 kernel: [ 588.521355] Bluetooth:
Frame Reassembly Failed: 84
Apr 5 05:44:57 armv8-generic-okl4 kernel: [ 592.516397] Bluetooth:
hci0 command 0x0401 tx timeout
The "84" error code was printed by my changes in
hci_recv_stream_fragment(). hci_reassembly() thought the passed in
type parameter was invalid:
if ((type < HCI_ACLDATA_PKT || type > HCI_EVENT_PKT) ||
index >= NUM_REASSEMBLY)
return -EILSEQ;
So, once adding more debug logs, I found when such situation happens,
the data received by low level tty driver contained an extra "0x00"
byte:
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078113] Bluetooth:
skb is null, pkt_type from data[0]: 0
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078212] Bluetooth:
Illegal byte sequence - type: 0, index: 0
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078248] Bluetooth:
Frame Reassembly Failed: 84. Received 11 bytes of data:
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078280] Bluetooth: 00
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078302] Bluetooth: 04
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078306] Bluetooth: 0e
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078310] Bluetooth: 07
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078315] Bluetooth: 01
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078319] Bluetooth: 23
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078323] Bluetooth: 0c
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078337] Bluetooth: 00
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078341] Bluetooth: 00
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078345] Bluetooth: 01
Apr 5 08:21:10 armv8-generic-okl4 kernel: [ 221.078349] Bluetooth: 40
Apr 5 08:21:12 armv8-generic-okl4 kernel: [ 223.071566] Bluetooth:
hci0 command 0x0c23 tx timeout
The normal response to the 0x0c23 (Read class of device) command should be:
04 0e 07 01 23 0c 00 00 01 40, that is, class == 0x400100. However,
this extra, preceding 0x00 byte would make hci_reassembly() regard the
packet type illegal. I guess the packet was simply dropped and
therefore hcidump received no responses at all.
It's very strange. During the execution of brcm_patchram_plus program
the HCI commands sent by it won't trigger such situation at all. Once
hci0 was brought up, I would run into it quickly. Moreover, if I
skipped over data[0] when it was 0x00, the HCI Event packet in the
data buffer could be handled properly since the rest of content in the
data buffer are sane.
So any insight on the root cause of this phenomenon? and how I should
initialise the bcm4354A2 correctly? Currently I am using below
parameters:
./brcm_patchram_plus -d --patchram /system/etc/firmware/BCM43xx.hcd
--no2bytes --baudrate 4000000 --use_baudrate_for_download --enable_hci
--bd_addr 40:40:a7:a6:a5:c1 --tosleep=100 /dev/ttyHS0 &
Where the BCM43xx.hcd file is obtained by AOSP and the --tosleep delay
in ms was arranged between the launch ram command and the hci reset
command (as inspired by relevant code in broadcom's libbt
implementation for bluedroid)
Moreover, once I skipped over data[0] when it was 0x00, the Scan
operation still failed:
Apr 5 13:01:07 armv8-generic-okl4 bluetoothd[3863]: hci0: Start
Discovery (0x0023) failed: Not Supported (0x0c)
The bluetooth spec reads that 0x0c error code means "Command
Disallowed" - the hardware was in a state unable to execute the
command. Again, I doubt I have enabled the bcm4354A2 properly.
Many thanks for any comments!
Cheers,
Harry
Hello Loic,
I've got feedback from vendor, turns out the hcd file I have been
testing is as a matter of fact, the latest one available from their
github:
https://github.com/sonyxperiadev/device-sony-karin_windy/blob/master/rootdir/system/etc/BCM4356.hcd
So the hcd file should be fine. Given that I have managed to use
brcm_patchram_plus program to achieve the same results as bluedroid to
initialise the BCM4354A2 hardware and I have even used "hcitool cmd"
to send extra dozens of HCI commands sent by bluedroid (as recorded in
btsnoop_hci.log file) right after initialisation, the culprit might
locate in kernel space. So I compared and contrasted bluetooth kernel
stack in my 3.10 kernel tree and the one used by vendor
(git://github.com/sonyxperiadev/kernel) , turns out there indeed has
one file different - msm_serial_hs.c, the high speed uart driver!
commit 67f8f9d4579db3cd7e852ec42801f2748b18d1d2
Author: Humberto Borba <[email protected]>
Date: Thu Apr 21 00:03:06 2016 -0300
drivers: msm_serial_hs: Fix unbalanced IRQ for msm8974
This path fixes unbalanced IRQ for msm8974 platforms,
also it fixes bluesleep wakelocks and it saves the battery life.
Welcome back deep sleep state.
This issue happened after driver update (for msm8994 platform) on:
https://github.com/sonyxperiadev/kernel/commit/529ec81e42194fee05bfd18bffc2c95ba796887d
Signed-off-by: Humberto Borba <[email protected]>
Well, after I patched above commit, my situation was greatly improved:
1. The HCI inquiry command will receive relevant command status,
inquiry result and inquiry complete events successfully. Previously
the Inquiry result event won't be received until the HCI inquiry
cancel command is sent.
2. The brcm_patchram_plus program won't have to re-send HCI reset
command any more. Previously the 4-second alarm will be triggered
twice to send the HCI reset command 3 times in total.
3. The HCI write simple pairing mode command will receive its command
complete event immediately. Previously using hcitool to send such
command will block and I would have to send another HCI command to
receive relevant command complete status for it (along with that of
the second command)
All above facts made me wondering that HCI events could be stuck by
uart driver and not relayed upwards to bluetooth kernel stack until a
new event is received.
Last but not least, even after applied this commit, there are still
0x00 leading bytes issue (although they could be worked around by my
patch to skip them over), and sometimes I still could run into
hci_reassembly() error:
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544467] Bluetooth:
Packet too short! Ignored. Count: 1 :
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544500] Bluetooth: 04
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544612] Bluetooth:
Frame Reassembly Failed: 84
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544626] Bluetooth:
Received 6 bytes of data:
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544645] Bluetooth: 0e
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544656] Bluetooth: 04
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544665] Bluetooth: 01
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544672] Bluetooth: 08
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544676] Bluetooth: 20
Apr 12 13:20:58 armv8-generic-okl4 kernel: [21928.544680] Bluetooth: 00
As we can see, the h4_recv() callback has been incorrectly invoked
twice by the low level tty driver for only one hci event packet: once
for the first "04" byte and another for the rest of the "04 0e 04 01
08 20 00" packet, which otherwise would have been passed on to hcitool
in usrspace through the HCI socket.
Anyway, I will continue chase this issue up to relevant developer
Humberto Borba :-D
Many thanks again for all your help and guidance throughout this whole week!
Harry
On Thu, Jun 16, 2016 at 7:07 PM, Loic Poulain <[email protected]> wrote:
> Hi Harry,
>
>> I have to say you are shrewd in this respect, if I use baud rate of
>> 115.2K, then the leading "garbage" bytes would no longer be 0x00 as
>> with baud rate of 3M or 4M, e.g.:
>>
>> Above logs are printed when hci_reassembly() returns -84 error code,
>> as we can see, the leading bytes becomes f8 or fc, sometimes even an
>> array of "18 90 90 15 f8". By contrast, if baudrate of 3M/4M is used,
>> the leading bytes seem always be 0x00. So it seems apparent that the
>> leading garbage bytes are related with the baudrate used.
>
>
> Look like some unsync serial bytes.
> This seems definitely related to your firmware.
>
>> Moreover, with baudrate of 4M, I tried avoid downloading BCM43xx.hcd
>> file at all, to my surprise, the hci0 can still be enabled well.
>> "hciconfig -a" reads that the HCI revision has changed from 0x2108
>> (with *.hcd downloaded) to 0x2000 (without *.hcd at all):
>> HCI Version: (0x7) Revision: 0x2000
>> HCI Version: (0x7) Revision: 0x2108
>>
>> with all the other features/link policy/packet types identical. Out of
>> curiosity, what difference could HCI revision make for hardware
>> capability?
>
>
> HCI revision is implementation dependent, vendor can change revision with
> new firmwares (including fixes, capabilities...).
>
>>
>> Further more, when a *.hcd file is downloaded if I use "hcitool cmd"
>> to send the HCI Inquiry command, I can receive the corresponding HCI
>> Inquiry Result event when I send out the HCI Inquiry Cancel commands.
>> However, when the *.hcd file is not used, I received no HCI Inquiry
>> Result event at all. So I guess the firmware patchfile *.hcd is still
>> desirable to configure hardware properly.
>
>
> Indeed, embedded firmware can be buggy, you need the right hcd.
>
> Regards,
> Loic
Hi Harry,
> I have to say you are shrewd in this respect, if I use baud rate of
> 115.2K, then the leading "garbage" bytes would no longer be 0x00 as
> with baud rate of 3M or 4M, e.g.:
>
> Above logs are printed when hci_reassembly() returns -84 error code,
> as we can see, the leading bytes becomes f8 or fc, sometimes even an
> array of "18 90 90 15 f8". By contrast, if baudrate of 3M/4M is used,
> the leading bytes seem always be 0x00. So it seems apparent that the
> leading garbage bytes are related with the baudrate used.
Look like some unsync serial bytes.
This seems definitely related to your firmware.
> Moreover, with baudrate of 4M, I tried avoid downloading BCM43xx.hcd
> file at all, to my surprise, the hci0 can still be enabled well.
> "hciconfig -a" reads that the HCI revision has changed from 0x2108
> (with *.hcd downloaded) to 0x2000 (without *.hcd at all):
> HCI Version: (0x7) Revision: 0x2000
> HCI Version: (0x7) Revision: 0x2108
>
> with all the other features/link policy/packet types identical. Out of
> curiosity, what difference could HCI revision make for hardware
> capability?
HCI revision is implementation dependent, vendor can change revision
with new firmwares (including fixes, capabilities...).
>
> Further more, when a *.hcd file is downloaded if I use "hcitool cmd"
> to send the HCI Inquiry command, I can receive the corresponding HCI
> Inquiry Result event when I send out the HCI Inquiry Cancel commands.
> However, when the *.hcd file is not used, I received no HCI Inquiry
> Result event at all. So I guess the firmware patchfile *.hcd is still
> desirable to configure hardware properly.
Indeed, embedded firmware can be buggy, you need the right hcd.
Regards,
Loic
Hi Loic,
Many thanks for your tips!
I have sent emails to double check whether the vendor may have any
updated *.hcd for the BCM4354A2 hardware.
I have to say you are shrewd in this respect, if I use baud rate of
115.2K, then the leading "garbage" bytes would no longer be 0x00 as
with baud rate of 3M or 4M, e.g.:
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664791] Bluetooth:
Frame Reassembly Failed: 84
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664863] Bluetooth:
Received 12 bytes of data:
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664892] Bluetooth: 18
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664908] Bluetooth: 90
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664923] Bluetooth: 90
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664939] Bluetooth: 15
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664952] Bluetooth: f8
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664967] Bluetooth: 04
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.664982] Bluetooth: 0e
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.665000] Bluetooth: 04
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.665015] Bluetooth: 01
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.665028] Bluetooth: 6d
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.665042] Bluetooth: 0c
Apr 10 05:49:00 armv8-generic-okl4 kernel: [ 4434.665057] Bluetooth: 00
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.656159] Bluetooth:
hci0 command 0x0c6d tx timeout
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664625] Bluetooth:
Frame Reassembly Failed: 84
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664690] Bluetooth:
Received 8 bytes of data:
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664717] Bluetooth: fc
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664732] Bluetooth: 04
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664747] Bluetooth: 0e
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664760] Bluetooth: 04
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664774] Bluetooth: 01
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664788] Bluetooth: 1a
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664802] Bluetooth: 0c
Apr 10 05:49:02 armv8-generic-okl4 kernel: [ 4436.664824] Bluetooth: 00
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.656160] Bluetooth:
hci0 command 0x0c1a tx timeout
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664776] Bluetooth:
Frame Reassembly Failed: 84
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664838] Bluetooth:
Received 8 bytes of data:
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664861] Bluetooth: f8
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664876] Bluetooth: 04
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664895] Bluetooth: 0e
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664910] Bluetooth: 04
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664924] Bluetooth: 01
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664938] Bluetooth: 24
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664952] Bluetooth: 0c
Apr 10 05:49:04 armv8-generic-okl4 kernel: [ 4438.664967] Bluetooth: 00
Apr 10 05:49:06 armv8-generic-okl4 kernel: [ 4440.656159] Bluetooth:
hci0 command 0x0c24 tx timeout
Apr 10 05:49:06 armv8-generic-okl4 kernel: [ 4440.663119] Bluetooth:
Packet too short! Ignored. Count: 1 :
Apr 10 05:49:06 armv8-generic-okl4 kernel: [ 4440.663183] Bluetooth: f8
Above logs are printed when hci_reassembly() returns -84 error code,
as we can see, the leading bytes becomes f8 or fc, sometimes even an
array of "18 90 90 15 f8". By contrast, if baudrate of 3M/4M is used,
the leading bytes seem always be 0x00. So it seems apparent that the
leading garbage bytes are related with the baudrate used.
Moreover, with baudrate of 4M, I tried avoid downloading BCM43xx.hcd
file at all, to my surprise, the hci0 can still be enabled well.
"hciconfig -a" reads that the HCI revision has changed from 0x2108
(with *.hcd downloaded) to 0x2000 (without *.hcd at all):
HCI Version: (0x7) Revision: 0x2000
HCI Version: (0x7) Revision: 0x2108
with all the other features/link policy/packet types identical. Out of
curiosity, what difference could HCI revision make for hardware
capability?
Further more, when a *.hcd file is downloaded if I use "hcitool cmd"
to send the HCI Inquiry command, I can receive the corresponding HCI
Inquiry Result event when I send out the HCI Inquiry Cancel commands.
However, when the *.hcd file is not used, I received no HCI Inquiry
Result event at all. So I guess the firmware patchfile *.hcd is still
desirable to configure hardware properly.
Thanks again!
Harry
On Tue, Jun 14, 2016 at 8:01 PM, lpoulain <[email protected]> wrote:
> Hi Harry,
>
>> However, I still found logs that an extra 0x00 byte was skipped over
>> (by my workaround patch) for some HCI_Event packet (otherwise lots of
>> HCI commands would time out because this extra 0x00 byte would fail
>> hci_reassembly()) and start discovery also failed by 0x0C error code
>> (command disallowed).
>
>
> You should ask to the vendor about this issue.
> Maybe:
> - The firmware is buggy or the wrong one.
> - This extra byte is a vendor specific one (for low power mgmt, sw flow
> control...)
>
> What is the behavior if you don't download the hcd ? (using the embedded fw)
> Just in case, you can also try to reduce the operational baudrate (115200).
>
> Regards,
> Loic
Hi Harry,
> However, I still found logs that an extra 0x00 byte was skipped over
> (by my workaround patch) for some HCI_Event packet (otherwise lots of
> HCI commands would time out because this extra 0x00 byte would fail
> hci_reassembly()) and start discovery also failed by 0x0C error code
> (command disallowed).
You should ask to the vendor about this issue.
Maybe:
- The firmware is buggy or the wrong one.
- This extra byte is a vendor specific one (for low power mgmt, sw flow
control...)
What is the behavior if you don't download the hcd ? (using the embedded fw)
Just in case, you can also try to reduce the operational baudrate (115200).
Regards,
Loic
Hi Loic,
Many thanks for your suggestion!
I hadn't used hciattach on BCM4354A2 hardware before, so I tried it
out today and found that it couldn't yield better result than
brcm_patchram_plus program. As a matter of fact, after the firmware
patchfile is downloaded the HCI_Reset command needs very likely to be
re-sent again otherwise it simply blocks on reading relevant HCI_Event
packet until times out in the default 10 seconds. Once I resent this
command by capturing the SIGALRM in 4 seconds, the hci0 can be
enabled.
However, I still found logs that an extra 0x00 byte was skipped over
(by my workaround patch) for some HCI_Event packet (otherwise lots of
HCI commands would time out because this extra 0x00 byte would fail
hci_reassembly()) and start discovery also failed by 0x0C error code
(command disallowed).
I am using hciattach bcm43xx in the way of:
{ "bcm43xx", 0x0000, 0x0000, HCI_UART_H4, 115200, 4000000,
FLOW_CTL, DISABLE_PM, "40:40:a7:a6:a5:c1", bcm43xx, NULL },
/ # ./hciattach -n /dev/ttyHS0 bcm43xx
bcm43xx_init
Set Controller clock (1)
Set Controller UART speed to 4000000 bit/s
Flashed firmware /etc/firmware/BCM4354A2.hcd
Not received hci event for reset command, reset again (printed by
SIGALRM handler to send hci reset command in 4 sec)
Set BDADDR UART: 40:40:a7:a6:a5:c1
Set Controller clock (1)
Set Controller UART speed to 4000000 bit/s
Device setup complete
Cheers,
Harry
On Fri, Jun 10, 2016 at 6:04 PM, lpoulain <[email protected]> wrote:
> Hi Harry,
>
>> Dear community,
>> r
>> I am trying to use the brcm_patchram_plus program to initialise
>> broadcom bcm4354A2 on my target with 3.10 Linux kernel. Currently the
>> hci0 can be found UP, however, it doesn't seem to function properly.
>
>
> Did you try to init the chip with hciattach (bcm43xx) ?
> If yes, do you reproduce the same issue ?
>
> Regards,
> Loic
Hi Harry,
> Dear community,
> r
> I am trying to use the brcm_patchram_plus program to initialise
> broadcom bcm4354A2 on my target with 3.10 Linux kernel. Currently the
> hci0 can be found UP, however, it doesn't seem to function properly.
Did you try to init the chip with hciattach (bcm43xx) ?
If yes, do you reproduce the same issue ?
Regards,
Loic