All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Strobach <lalochcz@gmail.com>
To: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: Add support for BCM20702A0 [0489:e031]
Date: Sat, 14 Jan 2012 14:27:15 +0100	[thread overview]
Message-ID: <1686528.W7zB9hRLAY@uriel> (raw)
In-Reply-To: <1326278147.6454.225.camel@aeonflux>

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


  parent reply	other threads:[~2012-01-14 13:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-09 11:09 [PATCH] Bluetooth: Add support for BCM20702A0 [0489:e031] Thilo Cestonaro
2012-01-09 19:39 ` Marcel Holtmann
2012-01-10  7:12   ` Harvey
2012-01-10  8:11     ` Marcel Holtmann
2012-01-10 12:55       ` Harvey
2012-01-10 16:51         ` Marcel Holtmann
2012-01-11  8:15           ` Harvey
2012-01-11 10:35             ` Marcel Holtmann
2012-01-11 10:49               ` Harvey
2012-01-11 10:56                 ` Marcel Holtmann
2012-01-11 11:12                   ` Harvey
2012-01-14 13:27               ` David Strobach [this message]
2012-01-15 10:58                 ` Johan Hedberg
2012-01-15 11:21                   ` David Strobach
2012-01-11  7:43   ` Thilo Cestonaro
2012-01-11 10:34     ` Marcel Holtmann
  -- strict thread matches above, loose matches on Subject: below --
2012-08-27 19:56 thilo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1686528.W7zB9hRLAY@uriel \
    --to=lalochcz@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.