Bluetooth: Add support for BCM20702A0 [0489:e031]

PATCH In review Thilo Cestonaro 5 participants 16 messages Jan 9, 2012 – Jan 15, 2012 Bluetooth drivers

lore

Share & tools

lore

Thilo Cestonaro

author

2012-01-09 11:09 UTC #0 lore raw

PATCH 1/1 Bluetooth: Add support for BCM20702A0 [0489:e031]

Add another vendor specific ID for BCM20702A0.

output of usb-devices:

T:  Bus=02 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e031 Rev=01.12
S:  Manufacturer=Broadcom Corp
S:  Product=BCM20702A0
S:  SerialNumber=EC55F9EADE09
C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
---
 drivers/bluetooth/btusb.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

drivers/bluetooth/btusb.c +1 -0

index 55ac349..07622141a 100644
@@ -101,6 +101,7 @@ static struct usb_device_id btusb_table[] = {
     { USB_DEVICE(0x0c10, 0x0000) },
 
     /* Broadcom BCM20702A0 */
+    { USB_DEVICE(0x0489, 0xe031) },
     { USB_DEVICE(0x0a5c, 0x21e3) },
     { USB_DEVICE(0x413c, 0x8197) },

Signature · 1 line

1.7.5.4

Marcel Holtmann

maintainer

2012-01-09 19:39 UTC #1 lore raw

Hi Thilo,

Quoted 12 lines

output of usb-devices:

T:  Bus=02 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e031 Rev=01.12
S:  Manufacturer=Broadcom Corp
S:  Product=BCM20702A0
S:  SerialNumber=EC55F9EADE09
C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

you need to signed-of-by your patches.

Quoted 9 lines

---
  drivers/bluetooth/btusb.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

drivers/bluetooth/btusb.c +0 -0

index 55ac349..07622141a 100644

drivers/bluetooth/btusb.c static struct usb_device_id btusb_table[] = { · line 106

Quoted 6 lines

drivers/bluetooth/btusb.c +1 -0

@@ -101,6 +101,7 @@ static struct usb_device_id btusb_table[] = {
      { USB_DEVICE(0x0c10, 0x0000) },
 
      /* Broadcom BCM20702A0 */
+    { USB_DEVICE(0x0489, 0xe031) },
      { USB_DEVICE(0x0a5c, 0x21e3) },
      { USB_DEVICE(0x413c, 0x8197) },

And please follow the coding style. This needs to be a tab here.

Regards

Marcel

Harvey

2012-01-10 07:12 UTC #2 lore raw

Hi all,

Quoted 10 lines

   drivers/bluetooth/btusb.c |    1 +
   1 files changed, 1 insertions(+), 0 deletions(-)

drivers/bluetooth/btusb.c +0 -0

index 55ac349..07622141a 100644
@@ -101,6 +101,7 @@ static struct usb_device_id btusb_table[] = {
       { USB_DEVICE(0x0c10, 0x0000) },

Quoted 4 lines

drivers/bluetooth/btusb.c static struct usb_device_id btusb_table[] = { · line 106
Quoted 4 lines
drivers/bluetooth/btusb.c +1 -0
       /* Broadcom BCM20702A0 */
+    { USB_DEVICE(0x0489, 0xe031) },
       { USB_DEVICE(0x0a5c, 0x21e3) },
       { USB_DEVICE(0x413c, 0x8197) },

I fear this alone won't be enough. We are discussing this topic here:
https://bbs.archlinux.org/viewtopic.php?pid=1038521#p1038521

Short summary:
The adapter seems to work in first but the log files say:
'localhost bluetoothd[1718]: Inquiry Failed with status 0x12' while scanning.

From a short look in the Windows inf. file:
Fujitsu is listed there in a separate section called RAMUSBE031. There is also this "BCM20702A0_001.001.024.0023.0055.hex" file copied along with the driver, which is then referenced in the registry as "RAMPatchFileName". There is a long list of other 20702 adapters divided in those that need a 'RAM patch' or not. Maybe you could complete your list of compatible devices bases on this.

I own one of these Fujitsu laptops (E751 0x0489:0xe031) with the need for the hex file. If you want me to I can do more testing with to your guidance.

Thanks for your attention
Harvey

Marcel Holtmann

maintainer

2012-01-10 08:11 UTC #3 lore raw

Hi Harvey,

Quoted 23 lines

Quoted 10 lines
Quoted 10 lines
   drivers/bluetooth/btusb.c |    1 +
   1 files changed, 1 insertions(+), 0 deletions(-)
drivers/bluetooth/btusb.c +0 -0
index 55ac349..07622141a 100644
@@ -101,6 +101,7 @@ static struct usb_device_id btusb_table[] = {
       { USB_DEVICE(0x0c10, 0x0000) },
 
Quoted 4 lines
drivers/bluetooth/btusb.c static struct usb_device_id btusb_table[] = { · line 106
Quoted 4 lines
drivers/bluetooth/btusb.c +1 -0
       /* Broadcom BCM20702A0 */
+    { USB_DEVICE(0x0489, 0xe031) },
       { USB_DEVICE(0x0a5c, 0x21e3) },
       { USB_DEVICE(0x413c, 0x8197) },
I fear this alone won't be enough. We are discussing this topic here:
https://bbs.archlinux.org/viewtopic.php?pid=1038521#p1038521
Short summary:
The adapter seems to work in first but the log files say:
'localhost bluetoothd[1718]: Inquiry Failed with status 0x12' while scanning.

Quoted 7 lines

From a short look in the Windows inf. file:
Fujitsu is listed there in a separate section called RAMUSBE031. There is also this "BCM20702A0_001.001.024.0023.0055.hex" file copied along with the driver, which is then referenced in the registry as "RAMPatchFileName". There is a long list of other 20702 adapters divided in those that need a 'RAM patch' or not. Maybe you could complete your list of compatible devices bases on this.

this most likely means that your device is a ROM chip that needs some patching (kinda firmware download) to fix some bugs in the ROM mask.

Have a USB sniffer handy and figure out on how they upload this file into the chip. Most likely they are some HCI vendor commands.

Regards

Marcel

Harvey

2012-01-10 12:55 UTC #4 lore raw

HI Marcel,

Quoted 8 lines

Quoted 7 lines
From a short look in the Windows inf. file:
Fujitsu is listed there in a separate section called RAMUSBE031. There is also this "BCM20702A0_001.001.024.0023.0055.hex" file copied along with the driver, which is then referenced in the registry as "RAMPatchFileName". There is a long list of other 20702 adapters divided in those that need a 'RAM patch' or not. Maybe you could complete your list of compatible devices bases on this.

Quoted 5 lines

this most likely means that your device is a ROM chip that needs some patching (kinda firmware download) to fix some bugs in the ROM mask.
Have a USB sniffer handy and figure out on how they upload this file into the chip. Most likely they are some HCI vendor commands.

Can you suggest one which is especially helpful for this task? I will try this in a virtualbox xp machine if possible. BTW, I'm not really a crack but will try to do my best to help here if you want me to.

Harvey

Marcel Holtmann

maintainer

2012-01-10 16:51 UTC #5 lore raw

Hi Harvey,

Quoted 11 lines

Quoted 11 lines
Quoted 7 lines
From a short look in the Windows inf. file:
Fujitsu is listed there in a separate section called RAMUSBE031. There is also this "BCM20702A0_001.001.024.0023.0055.hex" file copied along with the driver, which is then referenced in the registry as "RAMPatchFileName". There is a long list of other 20702 adapters divided in those that need a 'RAM patch' or not. Maybe you could complete your list of compatible devices bases on this.
this most likely means that your device is a ROM chip that needs some patching (kinda firmware download) to fix some bugs in the ROM mask.

Quoted 6 lines

Quoted 2 lines
Have a USB sniffer handy and figure out on how they upload this file into the chip. Most likely they are some HCI vendor commands.
Can you suggest one which is especially helpful for this task? I will try this in a virtualbox xp machine if possible. BTW, I'm not really a crack but will try to do my best to help here if you want me to.

virtualbox and then running either usbmon or Wireshark on your Linux system should work just fine.

Regards

Marcel

Harvey

2012-01-11 08:15 UTC #6 lore raw

Hi Marcel,

Quoted 2 lines

virtualbox and then running either usbmon or Wireshark on your Linux system should work just fine.

O.K., here's what I found: running windows in virtualbox first then shutting it down again: the adapter works in linux too until the next reboot (still have to load the module and echo the ID to new_ID because of the adapter not reconigzed by the actual bt module) Doing a capture with wireshark on usb port 2 gives me the capture file attached.

Harvey

Marcel Holtmann

maintainer

2012-01-11 10:35 UTC #7 lore raw

Hi Harvey,

Quoted 9 lines

Quoted 2 lines
virtualbox and then running either usbmon or Wireshark on your Linux system should work just fine.
O.K., here's what I found: running windows in virtualbox first then shutting it down again: the adapter works in linux too until the next reboot (still have to load the module and echo the ID to new_ID because of the adapter not reconigzed by the actual bt module)
Doing a capture with wireshark on usb port 2 gives me the capture file attached.

so there is clearly some binary download in the capture file. It will most likely match the files that a referenced in the .inf file. However I am not reverse engineering this stuff for anybody. Someone else has to do that job.

Regards

Marcel

Harvey

2012-01-11 10:49 UTC #8 lore raw

Marcel,

Quoted 4 lines

so there is clearly some binary download in the capture file. It will most likely match the files that a referenced in the .inf file. However I am not reverse engineering this stuff for anybody. Someone else has to do that job.

So we're at an end here? I simply can't do it, you won't do it - game over?

BTW, I get your answers twice, once on the list, once as PM. Is this intended?

Harvey

Marcel Holtmann

maintainer

2012-01-11 10:56 UTC #9 lore raw

Hi Harvey,

Quoted 6 lines

Quoted 4 lines
so there is clearly some binary download in the capture file. It will most likely match the files that a referenced in the .inf file. However I am not reverse engineering this stuff for anybody. Someone else has to do that job.
So we're at an end here? I simply can't do it, you won't do it - game over?

most likely. Unless you find someone that does the reverse engineering for you. I bet it is pretty trivial, but I have no bandwidth for this.

Quoted 2 lines

BTW, I get your answers twice, once on the list, once as PM. Is this intended?

You are setting the Reply-to: field. And complain to GMX if they do not manage to do duplicate filtering correctly.

Regards

Marcel

Harvey

2012-01-11 11:12 UTC #10 lore raw

Hi Marcel,

Quoted 9 lines

Quoted 6 lines
Quoted 4 lines
so there is clearly some binary download in the capture file. It will most likely match the files that a referenced in the .inf file. However I am not reverse engineering this stuff for anybody. Someone else has to do that job.
So we're at an end here? I simply can't do it, you won't do it - game over?
most likely. Unless you find someone that does the reverse engineering for you. I bet it is pretty trivial, but I have no bandwidth for this.

Although this is disappointing for me, I understand completely. This is not your job. Broadcom or Fujitsu are coming to my mind :P

Quoted 5 lines

Quoted 2 lines
BTW, I get your answers twice, once on the list, once as PM. Is this intended?
You are setting the Reply-to: field. And complain to GMX if they do not manage to do duplicate filtering correctly.

Ah, I see. But I don't see how to convince thunderbird not to do this. And GMX... :/ So I will just delete the doubles ;)

Heads up
Harvey

David Strobach

2012-01-14 13:27 UTC #11 lore raw

In reply to Marcel Holtmann

Hello,

Quoted 10 lines

Quoted 9 lines
Quoted 2 lines
virtualbox and then running either usbmon or Wireshark on your Linux system should work just fine.
O.K., here's what I found: running windows in virtualbox first then shutting it down again: the adapter works in linux too until the next reboot (still have to load the module and echo the ID to new_ID because of the adapter not reconigzed by the actual bt module)
Doing a capture with wireshark on usb port 2 gives me the capture file attached.

Quoted 4 lines

so there is clearly some binary download in the capture file. It will most likely match the files that a referenced in the .inf file. However I am not reverse engineering this stuff for anybody. Someone else has to do that job.

based on the trace and the .hex files I extracted from the Windows driver package I wrote a simple python rampatch downloader script. I also started writing a downloader kernel module. I have two questions though.

Is there a need for a driver module at all?
The script seems to work well, so I think it would be sufficient to write a statically linked libusb based binary downloader and distribute it along with the rampatch files and an udev rule file.

If the module is needed for whatever reason, is there a way to implement it using btusb HCI interface functions?
The rampatch download process is basically a series of HCI commans sent to control or bulk out endpoint. I could of course implement the payload packaging myself, but I feel somehow, that a cleaner solution would be to use some common subsystem mechanism.

Regards

David

Johan Hedberg

2012-01-15 10:58 UTC #12 lore raw

Hi,

Quoted 24 lines · David Strobach

Quoted 10 lines
Quoted 9 lines
Quoted 2 lines
virtualbox and then running either usbmon or Wireshark on your Linux system should work just fine.
O.K., here's what I found: running windows in virtualbox first then shutting it down again: the adapter works in linux too until the next reboot (still have to load the module and echo the ID to new_ID because of the adapter not reconigzed by the actual bt module)
Doing a capture with wireshark on usb port 2 gives me the capture file attached.
Quoted 4 lines
so there is clearly some binary download in the capture file. It will most likely match the files that a referenced in the .inf file. However I am not reverse engineering this stuff for anybody. Someone else has to do that job.
based on the trace and the .hex files I extracted from the Windows driver package I wrote a simple python rampatch downloader script. I also started writing a downloader kernel module. I have two questions though.
Is there a need for a driver module at all?
The script seems to work well, so I think it would be sufficient to write a statically linked libusb based binary downloader and distribute it along with the rampatch files and an udev rule file.

Quoted 6 lines

If the module is needed for whatever reason, is there a way to implement it using btusb HCI interface functions?
The rampatch download process is basically a series of HCI commans sent to control or bulk out endpoint. I could of course implement the payload packaging myself, but I feel somehow, that a cleaner solution would be to use some common subsystem mechanism.

How is this all related to the Broadcom firmware uploader that was sent to this list back in November, or is that for some separate piece of hardware:
http://www.spinics.net/lists/linux-bluetooth/msg17785.html

Johan

David Strobach

2012-01-15 11:21 UTC #13 lore raw

Quoted 32 lines · Johan Hedberg

Quoted 24 lines · David Strobach
Quoted 10 lines
Quoted 9 lines
Quoted 2 lines
virtualbox and then running either usbmon or Wireshark on your Linux system should work just fine.
O.K., here's what I found: running windows in virtualbox first then shutting it down again: the adapter works in linux too until the next reboot (still have to load the module and echo the ID to new_ID because of the adapter not reconigzed by the actual bt module)
Doing a capture with wireshark on usb port 2 gives me the capture file attached.
Quoted 4 lines
so there is clearly some binary download in the capture file. It will most likely match the files that a referenced in the .inf file. However I am not reverse engineering this stuff for anybody. Someone else has to do that job.
based on the trace and the .hex files I extracted from the Windows driver package I wrote a simple python rampatch downloader script. I also started writing a downloader kernel module. I have two questions though.
Is there a need for a driver module at all?
The script seems to work well, so I think it would be sufficient to write a statically linked libusb based binary downloader and distribute it along with the rampatch files and an udev rule file.
Quoted 6 lines
If the module is needed for whatever reason, is there a way to implement it using btusb HCI interface functions?
The rampatch download process is basically a series of HCI commans sent to control or bulk out endpoint. I could of course implement the payload packaging myself, but I feel somehow, that a cleaner solution would be to use some common subsystem mechanism.

Quoted 4 lines

How is this all related to the Broadcom firmware uploader that was sent to this list back in November, or is that for some separate piece of hardware:
http://www.spinics.net/lists/linux-bluetooth/msg17785.html

That seems to be for old BCM2045 Blutonium adapters.

Thilo Cestonaro

author

2012-01-11 07:43 UTC #14 lore raw

In reply to Marcel Holtmann

Hey Marcel,

I attached my patch as my mail client converts the tabs into spaces :(.

Thx for your quick review.

Regards,
Thilo

Marcel Holtmann

maintainer

2012-01-11 10:34 UTC #15 lore raw

Hi Thilo,

Quoted 1 line

I attached my patch as my mail client converts the tabs into spaces :(.

the simple answer is to get your mail client fixed.

However since the firmware patching stuff is still unclear, this patch is a bit premature until that got figured out.

Regards

Marcel