Mouse <[email protected]> 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 - [email protected]
