well, once you make the n900's usb controller to think he is the host (by using the force_host option, if it works on omap3430/twl4030), you only need to use a special cable (and probably inject cutom power source too)...

it's all only about setting up of the host-client session on data bus (which should be very much only a software problem - I've read somewhere, that for a long time now, most (even the simplest) embedded client usb controllers support at least a primitive host mode)...)

the only obsticle I can see is that either the hardware is horifically badly designed (like it can't be a host, because of some electrical out-of-usb-spec issues when connecting other device.. i think there were some problems with host mode on otg port of BeagleBoard too (with older revisions), so it could be something similar) - or omap3430 doesn't implement the force_host (correctly)...

please, Siggen, post the answer(s) here again, if you get some...

I'm curious: what is left to try now that even setting test mode in a patched kernel has failed?

for starters we don't know if the testmode had any effect on the chipset operations at all... we don't know whether the kernel module works correctly (i.e. whether it detects host mode and initiates required comm protocols - there are tons of stuff one has to do even before a client session,so it's possible we left out something) etc. - someone with usb-debugging skills (at sw and hw level) has to look into this to give a final verdict.. for me, the official "n900 doesn't support otg on hw level" statement is too vague...

FWIW, I think the patches against 2.6.28 could be applied to a different kernel with theoretically no loss in functionality, but the other way around may be easier.

My speculation - msusb not provide direct connection
to USB connector. All USB communication going
through ISP1707 ULPI interface.
If this true, you can configure USB host, peripheral or OTG
mode. Also ISP1707 have internal resistors for DP, DM and ID pins.
You can found data sheet for ISP1704A (same as ISP1707,
but without CHRG_DET_POL feature)

The twl4030 has nothing to do with USB.
The chip doing USB is the http://wiki.maemo.org/N900_Hardware_isp1707 - it is unclear if the statement in that page about rework is accurate - though it was allegedly made by someone who had schematics - the datasheets of similar chips do not seem to support it.

It seems likely that the statement 'you need to rework to get USB host' seems to only be true for devices with unchangable kernels that cannot be told to ignore the setting.

lovely...

well, twl4030 is still used for usb - only now we know, that the PHY is isp1707... As EugeneS said, and as it is written in ULPI specification - it should be possible to do some stuff with the pulldown resistors of PHY, I've even found interesting code in drivers/usb/musb/musb_core.c:

functions musb_verify_charger / musb_ulpi_readb / musb_ulpi_writeb

and definitions like

ISP1704_OTG_CTRL_DP_PULLDOWN / ISP1704_OTG_CTRL_DM_PULLDOWN

which means, we can control the PHY to some extent - and maybe also force it into host mode...

(erm, to be precise - the PHY probably doesn't know too much about host/peripheral modes, when it comes to logic.. it probably only cares about electronics stuff (like power pump (which however might be not present in n900) for host mode, those pulldown resistors, maybe initial speed/OTG negotiation) - so additional work still might need to be done inside the MUSB code, to make it all work together properly...)

I'll have to read the usb/ulpi specification more carefuly - if anyone with greater knowledge is interested - please, don't hasitate to join the discussion :-)

this seems to continue being fun...

Hmm - I may have been confused and the twl4030 drives the phy - I thought it had it integrated.

It's almost certain the resistors are integrated into the devices.
In all comparable devices I've seen - lookes at maybe 5 datasheets - they are.
Hence they can't be left out.

ISP1707 have all ULPI registers in range 0x0 - 0x1B,
plus PWR_CTRL registers 0x3D - 0x3F.
Most interesting - OTG_CTRL 0xA - 0xC and
Function Control 0x4 - 0x6.

Hi,

I don't know if this has already be mentioned somewhere, if so just ignore this post:

If you want to claim support for OTG you have to source power from the connector. Period. If you don't then even if the controller would be able to do OTG, it's not compliant.

The N900 doesn't seem to do this (just like the n800 doesn't) and that is the hardware limitation.

Circumventing the hardware limitation by sourcing externally, it might be possible to do OTG though.

just my 2 cents and I'd really like this to work because then I could connect my model plane charger and record charge curves from it. Now I do this with an old subnote which barely runs XP

Axdan