Getting the Broadcom BCM2035B to play ball
Well, I’ve tinkered today with the headset and this Bluetooth dongle, and got a little further. Still can’t actually connect to anything, but I am seeing devices pop up in Konqueror under the bluetooth:/ kioslave and hcitool scan actually reports some devices.wander ~ # hcitool scan –flush
Scanning …
20:07:35:xx:xx:xx KF-700
00:1E:E1:xx:xx:xx SGH-A412
I have no idea what the SGH device is … someone’s mobile phone apparently (this dongle has a 100m range). The other device, is my headset. However, hitting the MFB (Mobile Find) button on the headset, does not yield a pin entry request in KDEBluetooth. I’m no closer to actually being able to use this as a means of wireless VoIP.
To reiterate what I have tried:
- Upgraded to latest vanilla kernel: 2.6.25-rc6
- Running latest BlueZ tools in portage: bluez-firmware-1.2 bluez-bluefw-1.0 bluez-libs-3.28 bluez-utils-3.28 bluez-hciemu-1.2
- Using hciconfig to bring the device down, back up, and reset it, enabling various modes (e.g. page scan, inquiry scan, page+inquiry scan)
The following is seen in dmesg when the dongle is plugged in (proceeding text snipped):
[ 2560.963622] usb 5-1: new full speed USB device using ohci_hcd and address 3
[ 2561.133938] usb 5-1: configuration #1 chosen from 1 choice
[ 2561.151391] usb 5-1: New USB device found, idVendor=0a5c, idProduct=2035
[ 2561.151403] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2561.151409] usb 5-1: Product: BCM2035B
[ 2561.151414] usb 5-1: Manufacturer: Broadcom Corp
And hciconfig shows:
wander ~ # hciconfig
hci0: Type: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 377:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:982 acl:0 sco:0 events:28 errors:0
TX bytes:610 acl:0 sco:0 commands:28 errors:0
I’m guessing the address is the problem. And this issue seems to rest with the kernel driver itself, hci-usb. I’ve tried forcing bcm203x to take custody of the device, this doesn’t work at all — the device doesn’t even initialise. So clearly hci-usb is responsible for setting things up — but it isn’t. In sysfs:
wander ~ # cat /sys/bus/bluetooth/devices/hci0/address
00:00:00:00:00:00
Allegedly, the BCM2033 works rather well with Linux, and I see no reason why the BCM2035 shouldn’t, when the code is clearly present. I’d say there’s some edge case that isn’t handled. I’ll ask a little later on the BlueZ mailing lists and see what I can come up with … but I’m posting this here for others’ reference. Later down the track I plan to repeat this exercise on the Lemote boxes (and maybe my O2 as well, if I get a USB card for it) — presently though, I’m doing this on my laptop (which is x86-based).
Again, if anyone has an idea what’s going wrong… I’m all ears. 
May 6th, 2008 at 4:05 am
Same problem with the BCM2035B Bluetooth dongle. Haven’t found a solution yet.
Here’s what I had done…
http://www.debiantutorials.org/talkitup/index.php?topic=1662.0
Couldn’t get it to work on Debian Etch, kernel 2.6.18-6-686.
Hasn’t worked on Windows XP either (with the WIDCOMM driver which came on CD).
May 6th, 2008 at 4:06 am
Something I came across when I was trying to get it to work. Not the same device, but the same issue… no address assigned to the device.
http://linuxgazette.net/109/oregan3.html
May 6th, 2008 at 8:09 am
I managed to get mine working under Windows 2000… although support for headsets is utter crap there. Interestingly, the Bluetooth address under the Widcomm stack showed all zeros there too.
So this may not necessarily be the problem, either the device isn’t revealing its address to the OS, or Broadcom made a whoopsie producing these devices.
I shall certainly have a look at those links… for now I’ve just palmed the device off to my father so he can sync his new phone to his Windows 2000-based desktop. I can borrow it to try and fix problems under Linux though.
May 23rd, 2008 at 12:22 pm
I also have this dongle, and I’ve managed to solve the problem. It seems that some chinese company decided not to pay for a bdaddress range, so our dongles have the address zeroed.
You have to download bluez source code from http://www.bluez.org/download.html. You have to compile the libs first, and then compile a tool called ‘bdaddr’ inside bluez-utils. This will allow you to set a new address manually. (you have to reset the device after running bdaddr)
The problem with this is that the bdaddres isn’t retained when you unplug the dongle. I’ve tried to flash a new firmware, expecting that way to fix a new address, but it seems this model cannot be flashed, or bluez doesn’t know how.
If you guys dare to open the dongle, maybe with the chip codes we can know if it is possible to flash it.
Good luck.