I have been able to get the device to report the same power and devctl registers as the n810 and n800. What happens is that as an A device the musb detects an HNR attempt which times out and then the device switches "back" to host mode. I didn't expect this. It happens after a somewhat reasonable sequence of actions though.

With a POS hub I got what looked like a connection. There was an urb which looked like it had some kind of updates. When I connected a keyboard that didn't work. There was a warning from musb_host:128 about not being able to flush a host fifo so I assume that's related. This is with a power injecting cable and a heavily hacked kernel, off spec connectors etc. I probably haven't hacked things correctly, just got it so that it "looked" right. Patch is attached. I do *not* recommend flashing this kernel, instead follow the instructions for loading and booting the kernel from the wiki page w/out flashing.

I can't get the switch to host mode (bit 2 of devctl set) to happen reliably. On the other hand I have seen the usb on the n800 get screwed up such that a reboot was required, so maybe that's not a notable difference. If it is abnormal I think this is related to setting the phy resistors manually. That often times out. I suspect it could be because of some concurrent access and it gets screwed up. Perhaps the resistors don't need to be set manually, or at least don't need to be set manually where I'm doing it currently.

I'm less concerned about the unreliable connection and more concerned about the failure of this fifo to flush. I think this might be at the limit of what I can do unless there are patches out there to fix that issue.

FYI the state being set to a_idle when grounding the id pin doesn't effectively do anything. The id pin is picked up by the twl4030 and that module sets the state to a_idle if the id pin is what generates the interrupt. 'find /sys -name linkstat' to find the file which tells you the interrupt source. However this doesn't seem to be connected to the actual phy, the isp1704. If the id pin was connected there then I think bit 5 of the interrupt status register for the isp1704 should have been set to 0 when the id pin is grounded. It isn't as far as I can tell.