[Droid Eris Android Development] bftb0:
Hi tereg,

In a boot sequence that you describe (fastboot -> hboot -> recovery) where the recovery boot has adbd running (either because you won the Incredible/Slide "race #1", or because the custom recovery has adbd running all the time) you will see exactly the transitions you reported.

fastboot: 0bb4:0fff address N
hboot: (usb is "dead" for all purposes)
recovery: 0bb4:0ff9 address N+1 followed by
0bb4:0c98 address N+2

( You'll find some additional info in this post )

So, the PC operating the USB root hub will pick a driver to use based not only on the Vendor:Product identifiers that the device reports, but also the "endpoints" within the device. Having an "address" assigned to a device by low-level USB negotiations allows you to have multiple identical devices connected to a USB hub without any problems,

What seems to happen during the recovery boot (by examining USB packet traces and kernel boot logs from the phone), is that the Android kernel brings up by default the 0bb4:0ff9 device, which supports only a single endpoint - Mass Storage. This happens pretty early: about 3-4 seconds into the kernel booting sequence. (Have a look in that pastebin I sent you).

Despite that the endpoint is there, there is no "disk" available to the PC - the SCSI-over-USB traffic that will take place between the phone and the PC after that time will indicate an "offline LUN". This corresponds to the observation that folks sometimes have with a regular phone OS boot that a "disk drive" will appear in Windows Explorer, but there is "nothing there when I click on it".

After the recovery kernel is almost fully operational, it launches "init", which starts all the services, including the sometimes-stays-alive adbd. When adbd comes alive, either in the regular OS boot or the recovery boot, it shuts down the 0bb4:0ff9 "device", and brings up the ADB Composite interface at 0bb4:0c98. This seems to happen around 8-10 seconds into the boot process - right about the same time as the /!\ splash screen shows up on the phone. This process causes a new USB address to be negotiated, and that's what you are seeing in your linux kernel logs.

This interface is "composite" because it has two endpoints (take a look with lsusb -v): the ADB endpoint, and also a Mass storage endpoint.

The bottom line is that when the ADB composite interface shows up as a result of a hiccup/race in the recovery boot, it does so in exactly the same sequence of events that would happen if you were booting up the main OS (with USB debugging enabled by default).

Note that we've had a report of a successful rooting where the person never ran the "loop" - my belief is that if adbd comes alive and survives the race on the phone, it will stay up permanently for that boot. But, that doesn't mean there is no traffic between the phone and the PC - the Mass Storage driver on the PC is constantly checking to see if a drive has changed it's status at the Mass Storage endpoint - and since there is a Mass Storage endpoint in both the "device" with identity 0bb4:0ff9 and the "device" with identity 0bb4:0c98, the PC is actually talking with the phone practically all the time after the initial interface bring-up at around 3 seconds, whether or not adbd comes up on the phone.

If you want to look at it a little more carefully, I can either post up or PM you step-by-step instructions on how to build a version of Wireshark (linux) so you can sniff every packet on the USB bus. It's not too bad - maybe 5 or 10 minutes of work.

The thing is, I'm not sure how much "there" is there. The phone needs to interoperate with PCs by conforming to the USB specification, and if you observe the USB bus with the phone in the normal OS when you are turning USB debugging on or off (or turning HTC sync on or off), you will see exactly the same activity taking place that you see in your recovery boot when you "win". You might become an expert in how USB works, but I don't know if it will gain you any advantage in improving the win % of the Incredible/Slide rooting method.

bftb0