Re: Conceptual USB doc?

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

[snip]

> I did find a _little_ doc on the protocol fastboot speaks over USB, but
> it assumes knowledge of concepts I don't have, saying things like
>
> 	Basic Requirements</h2><ul><li><p>USB</p><ul><li>Two bulk
> 	endpoints (in, out) are required</li><li>Max packet size must
> 	be 64 bytes for full-speed, 512 bytes for high-speed and 1024
> 	bytes for Super Speed USB.</li><li>The protocol is entirely
> 	host-driven and synchronous [...].
>
> Setting up "two bulk endpoints", even with the help of something like
> libusb atop ugen, requires knowing enough about what that means to find
> and make the appropriate calls.  (If I can even find a libusb that
> works on the host I want to use; there is usually some level of
> bludgeoning required to make others' software work on my machines.)

[snip]

So..  what you have there is the physical description of the USB
endpoints that are being used.  That is a start, but mostly just the
flea on the tick on the dog.  You will need the dog.

If you want to see kernel code that works at this level, you can look at
src/sys/dev/usb/if_rum.c in a recentish NetBSD source tree around line
349 or so in the attach function.  The if_rum device uses bulk endpoints
to send and receive network traffic.

What you are going to ultimately need is what is sent over those end
points.  This is the logical layer description and can almost be nearly
anything.  Not quite anything, but the field is very wide.

As an example...  the MCP2221A and MCP2210 are multi-io chips that speak
USB to something or other protocol (I2C, SPI, GPIO).  They utilize the
HID (Human Interface Device) spec which is somewhat like an interrupt.
How you use it is you sent up a 64 byte packet request, send it and then
asynchronously wait for a response which is also 64 byte.  Mostly what
is in the request and response packets are chip set specific.  What made
it possible to write device drivers for those chips is that this
protocol conversation was pretty well detailed in chip datasheets.  The
HID spec is used to talk to mice and keyboard and that higher level
conversation is nicely documented in the USB docs, the MCP chips made up
their own conversation and thankfully documented it.

Lacking any sort of chip or device data sheet, what you will likely have
to do is capture the protocol between a working system that can speak to
it and the device itself.  A way this is done is with Wireshark using
its ability to capture from a USB network stack in the same way as it
can from other networking worlds.  Once you have the USB packets you can
use the digesters that Wireshark has to decompose what the logical
protocol conversation into something that you can work with in libusb.

Now, you mentioned Android.  It is not at all a suprise that a phone
would be running that and it may be possible to learn how to speak to
the device by looking at the Android SDK which provides a fastboot
command and the like that knows how to talk to devices.  Back when I
flashed my Android based phone with LinageOS (open source Android fork)
to get an updated version of the base Android OS on the phone I used
fastboot a lot (in my case, binary blobs from the original Android OS
version were merged into a new Android version using shim code to create
a new base Android OS that could talk to the chipsets that were present
on the phone.  This was needed as the black box that actually did call
management and the like was completely closed source.  There are some
very clever people that worked on getting new base Android on very old
phones).  I don't remember if pkgsrc has the Android tools in it, but it
may be possible.  I used use them from MS-WINDOWs.






-- 
Brad Spencer - brad%anduin.eldar.org@localhost