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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
