From: Lono on
My boss wants me to write a driver to download USB driver directly into a
mobile device. After the USB driver is downloaded into the mobile device, I
need to download the rest of system image via the same USB cable. Therefore,
I cannot use standard USB driver( like WinUSB) to achieve it because there is
no USB driver in the device at the first place.
I think I need a simple protocol to communicate between PC and the
mobile device. The simple protocol should be simple enough to be stored in
the ROM of the device. The main issue is that I don't know how to bypass the
whole USB protocol stack and transmit raw data to the device direclty. Is it
possible with the Microsoft driver framework?
From: chris.aseltine on
On Apr 14, 10:36 am, Lono <L...(a)discussions.microsoft.com> wrote:

> My boss wants me to [...]

Uh oh.

> I think I need a simple protocol to communicate between PC and the
> mobile device. The simple protocol should be simple enough to be stored in
> the ROM of the device. The main issue is that I don't know how to bypass the
> whole USB protocol stack and transmit raw data to the device direclty. Is it
> possible with the Microsoft driver framework?

No, absolutely not. What you're describing is impossible. Moreover,
I think you've totally misunderstood the purpose of the USB driver in
the first place -- why would you download it (the host driver) to your
device at all?

Now, the overall thing that (I think) you're trying to achieve is very
common (that is, having some sort of bootloader/stub code on your
device, and then uploading its entire executable code image when you
plug it in).

However, this doesn't require you messing around with the stack on the
PC. You can write a small USB driver (in KMDF) that will communicate
with both your bootloader/ROM code and the device itself.

It sounds like your "boss" doesn't want to preinstall a PC driver
before connecting the device and flashing it. If that's the case, you
could possibly have your bootloader/ROM code enumerate as a generic
HID device, and you could write out your firmware by reading/writing
HID reports to it, but that's a nasty hack.
From: Lono on
There are two motivations. First, implementation of USB protocol in
mobile devices takes a lot of ROM size. If we can implement some simplier
protocol, it could save us some code space.
Second, we want to use same ROM code for both USB or RS232 connection.
If we could transfer USB raw data( No token packets, no checksum, ...), it's
possible to make the connection type transparent to mobile devices.
My boss heard it that some other companies already did that, so he
wants it too :(

"chris.aseltine(a)gmail.com" wrote:

> On Apr 14, 10:36 am, Lono <L...(a)discussions.microsoft.com> wrote:
>
> > My boss wants me to [...]
>
> Uh oh.
>
> > I think I need a simple protocol to communicate between PC and the
> > mobile device. The simple protocol should be simple enough to be stored in
> > the ROM of the device. The main issue is that I don't know how to bypass the
> > whole USB protocol stack and transmit raw data to the device direclty. Is it
> > possible with the Microsoft driver framework?
>
> No, absolutely not. What you're describing is impossible. Moreover,
> I think you've totally misunderstood the purpose of the USB driver in
> the first place -- why would you download it (the host driver) to your
> device at all?
>
> Now, the overall thing that (I think) you're trying to achieve is very
> common (that is, having some sort of bootloader/stub code on your
> device, and then uploading its entire executable code image when you
> plug it in).
>
> However, this doesn't require you messing around with the stack on the
> PC. You can write a small USB driver (in KMDF) that will communicate
> with both your bootloader/ROM code and the device itself.
>
> It sounds like your "boss" doesn't want to preinstall a PC driver
> before connecting the device and flashing it. If that's the case, you
> could possibly have your bootloader/ROM code enumerate as a generic
> HID device, and you could write out your firmware by reading/writing
> HID reports to it, but that's a nasty hack.
>
From: chris.aseltine on
On Apr 14, 8:29 pm, Lono <L...(a)discussions.microsoft.com> wrote:

> Second, we want to use same ROM code for both USB or RS232 connection.
> If we could transfer USB raw data( No token packets, no checksum, ...), it's
> possible to make the connection type transparent to mobile devices.

I wish you could see my face right now.

> My boss heard it that some other companies already did that, so he
> wants it too :(

I have a bridge for sale, is he interested?
From: Pavel A. on
<chris.aseltine(a)gmail.com> wrote in message
news:160a9aa4-d964-4cf8-a51b-f601f205a200(a)a70g2000hsh.googlegroups.com...
> On Apr 14, 8:29 pm, Lono <L...(a)discussions.microsoft.com> wrote:
>
>> Second, we want to use same ROM code for both USB or RS232
>> connection.
>> If we could transfer USB raw data( No token packets, no checksum, ...),
>> it's
>> possible to make the connection type transparent to mobile devices.
>
> I wish you could see my face right now.
>
>> My boss heard it that some other companies already did that, so he
>> wants it too :(
>
> I have a bridge for sale, is he interested?

Well, EHCI has a kind of simplified interface for the debug port (what is
used by windbg in Vista), but still this isn't raw,
and not accessible from Windows.
If they need to download the firmware only once during manufacturing, they
could make a special adapter
and connect it (say) to RS232...

--PA