Okay, now I see the difference.
But I want only the host mode, and don't care if it is OTG.

Count me in for testing if there is anything!
For making myself ready, I'll buy a microUSB male to USB female cable.

BTW, I read all posts since the one you linked. Really interesting stuff. (But I don't have a degree in electronic engineering, yet.)

half true !
initial settings of n900 as a A-device is impossible but nothing prevent n900 become b_host with help of HNP and "all mode" driver.
with actual peripheral only driver your statement, sadly, is true
if n900 get all mode driver i swear I will resolder my isp1707 with id pin wired to the receptacle ID pin and also i'll change it to microAB.

@blue_led:
you missed a point - ARM CPU OTG USB module handles all stuff about sessions including taking decisions about B-session or A-session protocol. And that includes ADP-like detection what B-device is connected to A-host and session should be started.

Now:

>from datasheet :
>'If the micro-A end of the cable is plugged in, the ISP1704A will report that ID_GND is
>logic 0. The USB link must be in the A-device state."
>this statement say if id pin is ground the usb logic, which is inside omap processor, must switch itself to A device state

I would be happy if logic of selection A or B state is located in ARM CPU OTG USB hardware - it looks like it is possible to switch it to HOST mode. But I see from 1704 specs that it should be a properly configured for HOST high-speed transaction and that piece of code is absent. I only hope that this setup would switch 1704 to HOST mode. I don't see any another ways to explicitly reconfigure 1704 in HOST mode besides a Table 14, "Operating states and their corresponding resistor settings" specifies a different setup for HOST, Peripheral and OTG modes. 1704 also doesn't discriminate between B and A types of session.

"also lack of Attach Detection Protocol in isp 1707 make difficult to make a decision about vbus keep alive"

I don't think that it is needed. The B-device attachment ahould be supported in 1707 for sure (it has HOST mode), but it is based on D+/D- lines capacity change.

EDIT: use SPRUF98D instead of SPRUF98F - the last one is much useless for programming. For some reason TI deleted from SPRUF98F the most USB OTG registers description.

There's an app in Extras-Devel called "usbcontrol". Is it of any use?

Alas not, it's heritage from N810 and largely useless on N900, I.E. doesn't work
Nevertheless thanks for pointing at it

/jOERG

Ok guys we re watching your effort to get host mode on N900, keep going

as ulpi is standardized i expect any transceiver to work even at usb resistors level but it is a huge surprise to find Fairchild FUSB2500 http://www.fairchildsemi.com/ds/FU/FUSB2500.pdf pin to pin compatible with isp 1707. F1 pin is also documented !
so now we have additional datasheet to read seating on toilet.

Yes, my opinion is with all the unknown variables, one should work backwards. I'm assuming that, besides the jack, the USB hardware differences between a particular Beagleboard rev and the n900 are negligible. So, get a Beagleboard working with the forced host mode method by using a non-conforming cable setup with a micro-B plug in the Beagelboard, and a micro-B plug in an n810. There should be a wealth of debug from both devices if the Beagelboard can successfully mount and transfer files from an n810 drive.

After that is working, then force the Beagleboard's ID pin (?) to ground (?) or clip it and see if host mode can still be forced by trying all software changes at your disposal. If not, it's likely that there isn't a software-only solution for the n900. If so, now try the Beagleboard USB kernel/driver/OS pieces on an n900. Both the n900 and the n810 should be spitting out enough debug at this point, that a final answer should come quickly.

Unfortunately that is not the case, as the similitudes end as soon as you get to the ulpi layer: the beagle board's cpu is connected to the twl3040, while the N900's is connected to a isp1707a USB PHY.

great!
Let me quote and comment on arbitrary details in the datasheet which I find worth to take notice of:

Name: ID pin: D3 type:I Identification (ID) pin of the micro-USB cable. TTL, If not used, connect to the VCC3V3 pin. [[complies with N900]]

Name: PSW pin: D4 type:O Controls an external, active HIGH, VBUS power switch/charge pump and/or an SMPS charger IC. [[Not used in N900, we need to control VBUS power *supply* inside bq24150, probably via a patched/replaced bme]]

Name: VBUS pin: F4 type:AI/O Should be connected to the VBUS pin of the USB cable. Leave open circuit if not used. An internal 90KΩ ±11% pull-down resistor is present on this pin. [[On N900 this pin is connected to VBUS rail via a 1k, so all the probing/charging/whatever should work as supposed]]

Description: [[excerpt]]
The FUSB2500 is optimized to connect the USB2.0 host, peripheral, or OTG-controller to the USB connector via the ULPI link. [[There's nothing whatsoever mentioned regarding special requirements in circuitry and/or interfacing, to implement hostmode. Means this chip can do hostmode out of the box with the standard application circuit. ID pin is not needed to switch to hostmode (as elaborated in this thread several times now). ]]
[[description excerpt continued]]
The FUSB2500 also includes a charger-detection
functional block that enables automatic detection for
charging USB2.0 host ports or dedicated chargers. [[This is the reason why Nokia swapped the TWL4030 for this PHY chip. Though both the TWL4030 and the 1707 are fully ULPI conform and thus probably highly compatible from a kernel driver POV, yet the early TWL4030 variants missed the charger detection function. So Nokia, to implement the annoying mandatory charging over USB, had to bin the PHY block inside TWL4030 and use 1707 instead.
Then, as quite clearly stated here, Nokia wasn't able to finish the whole complex driver zoo for OTG, charging, etc pp just in time and so had issues with usb.org cert authorities to the point where they either
a) could ship a device with option to implement full OTG later, but lacking USB certification, which would create all sorts of secondary problems (Microsoft not signing the driver, China and EU feeling pissed by Nokia not adhering to their rules for mobile devices&chargers, dunno what else), or
b) replace the micro-AB receptacle by a micro-B type, and thus circumvent all the OTG trouble, as B type per definitionem does NOT support OTG (and the ID pin is all about OTG and detecting A-plugs, and nothing else, btw) - get cert from usb.org easily, and ship several months earlier.]]