This is an interesting thread I can't wait to see someone actually hack the USB OTG to work

" The devil is not so black as he is painted "


blue_led, thanks for your continued work on this. If you want a set of N900 stands from my store, let me know, I'll mail them to you. If you want something small laser - cut, let me know, and I'll cut it and include that, too.

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.

Doing my experiments ....
Until now i put n900 in a stable state of powering the vbus few seconds.
according standard there is a time frame for connection 4.9 s . In this state ( a_vbus_vld ) n900 drive the vbus to 2.7 V ( 0.8< vbus_otg < 4.0 V ) and driver expect a_wait_bcon event. I could not imagine why bcon don't happen, leading switching the bus to reset state, instead i got unhandled disconnect interrupt
I found some limitations of devices offending last usb 20 standard and a lot of variants of usb 20 standard itself and a lot of obscure notes regarding functional implementations.
I think to write some code in a PIC microcontroller to inject a fake B_device connection signal into N900 but it is a little bit hard to switch to a real usb device hub or memstick fooling them they are already connected.

Yeah dude this gonna be amazing!! I want it on my n900

I'm confused, are you trying to really drive vbus? AFAIK the isp1704 doesn't have an integrated charge pump - bit 5 of the otg ctrl register is reaerved and that bit is drive vbus for the isp1301. I suppose I haven't tried setting bit 6 which is enabling an external charge pump but this is outside my comfort zone.

Also - what interrupts are you getting? On the n800 it's a connect interrupt which goes from wait_bcon to host. Forcing host I get a session req. interrupt which I am pretending is a connect int. - not sure if that actually works.

I don't drive vbus( this is an offending standard situation ) . 2.7 volts came from n900 itself and this is a very weak voltage source .
when an A device make a connection to an B device the A device must drive vbus so N900 can drive vbus somehow and that is a good piece of news. 2.7 V can be easily obtained from 3.3 V inside of isp1707 without charge pump.
An external power source can sense the 2.7v on vbus and drive with 5V hubs, sticks, et c.

i got int 941 when doing **** things on datalines

I tried reading as much of this as I could but I wasn't sure what would happen in my scenario. I own the following HDD:

http://www.hypershop.com/HyperDrive-COLORSPACE-s/23.htm

This drive has an internal battery to drive operation because of the screen and etc. There is a connector to take power from a battery or wall jack if you want extra juice to recharge while in use.

My question is I know the N900 doesn't supply power in its USB connection, so since this drive doesn't need power from the USB, can I get it to work with the N900?

I am a photographer that works on the road. With this I could send files from anywhere in the world that has cell coverage without the need for bringing a laptop. This would be HUGE. Any suggestions? Thanks.

geohsia, to my knowledge nothing works yet. I will post if I have any updates. If someone could review updates to musb and otg that might help.

As far as the recently leaked schematics are correct, VBUS is hooked up to GAIA TWL4030 PMU chargepump to deliver a correct 5V supply - rather than to the PHY chip.

Alas I've not found any matching node in sysfs to enable the GAIA vbus chargepump. Access to the related register via I2C should be possible nebertheless

jOERG