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(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 55ac349..07622141a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -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) },
--
1.7.5.4
On Sun, Jan 15, 2012 at 11:58, Johan Hedberg <[email protected]> wrote:
> On Sat, Jan 14, 2012, David Strobach wrote:
>> > > > 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.
>>
>> 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.
>
> 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.
Hi,
On Sat, Jan 14, 2012, David Strobach wrote:
> > > > 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.
>
> 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.
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
Hello,
> > > 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.
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
Hi Marcel,
>>> 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
>> 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
Hi Harvey,
> > 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.
> 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
Marcel,
> 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
Hi Harvey,
> > 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
Hi Thilo,
> 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
Hi Marcel,
> 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
Hey Marcel,
I attached my patch as my mail client converts the tabs into spaces :(.
Thx for your quick review.
Regards,
Thilo
Hi Harvey,
> >> 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.
>
> 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
HI Marcel,
>> 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.
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
Hi Harvey,
> >> drivers/bluetooth/btusb.c | 1 +
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> >> index 55ac349..07622141a 100644
> >> --- a/drivers/bluetooth/btusb.c
> >> +++ b/drivers/bluetooth/btusb.c
> >> @@ -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) },
>
> 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.
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
Hi all,
>> drivers/bluetooth/btusb.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index 55ac349..07622141a 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -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) },
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
Hi Thilo,
> 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.
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 55ac349..07622141a 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -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
Hey,
> 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?
> If the module is needed for whatever reason, is there a way to
> implement it
> using btusb HCI interface functions?
Could someone please answers David's questions? As this would be very
interessting for me too.
@David: Could you possible share anything about the udev stuff or
kernel module you implemented?
Your python script is working fine here ;).
Regards
Thilo