Joerg,

If you describe a sequence then it is possible to encode it. Right now 170x support is just some add-on to twl4030 driver and it doesn't work with OTG_CTRL beyond initial setup and power saving/restore. It even doesn't control 1704 VBUS charge/discharge, so I have concern that just cable patch could work - VBUS signalling is required to establish a HOST presence.

(EDIT: actually driver extensively manupulates USB port of TWL4030 and 170x control is just supplementary)

ID pin is not needed to establish HOST mode without microA USB cable - it looks it is just a way to inform driver about cable insertion. But again - that stuff is missed in driver.

I need some time to read a session setup procedure description.

OK, I set DRVVBUS of TWL4030 inside driver via 'host' word into 'mode' file of musb_hdrc. I can't detect VBUS voltage - socked has no V on any pin.

However, at one time during kernel boot it gave me note "charging" with disconnected USB.

I will continue tomorrow.

EDIT: question: in command "./i2cset -y -m 0x07 2 0x6b 0x01 0x05" what is a device 0x6b? My N900 hasn't this...

keep it up guys! i'll be waiting patiently in the crowed supporting you guys

Me too!! Thanks guys!

hehhehehe count me in too .. we r not among u heros but surely support u .. thumbs up

Please start reading my posts at http://talk.maemo.org/showthread.php...165#post583165.
We are missing some capacitor to put TWL4030 GAIA boostmode to work, but N1140 bq24150 USB Bat Charger chip is perfectly suited for that. The i2cset cmd you're asking about does exactly that: enable boost mode (aka supply VBUS) in bq24150

Nota bene VBUS supply is our least problem. First we need a proper driver 'talking' hostmode, like OHCI or whatever. Second we need to switch the 1707 PHY chip (for the 2k2 pullup vs 15k pulldown R) and the musb UART in SoC (for clock master?) to hostmode. According to http://www-s.ti.com/sc/techlit/SPRUF98 p3162f, and http://focus.ti.com/lit/ug/spruf98d/spruf98d.pdf, there are several possible ways to implement that, last resort test mode (which you quoted for 1303)
Once this is accomplished we have a proper host working flawlessly with e.g powered hubs.

THEN we may look into the VBUS supply issue, and consider how we stop bme from throwing sticks at our legs

cheers
jOERG

[edit] beagleboard seems to use musb for hostmode successfully. Though they got another PHY chip (they use TWL4030 aiui), the handling of the forced hostmode should be similar wrt musb

Joerg_rw,

1) If you look into SPRUF98F/D, p3162, you can note that paragraph 23.1.5.4.2 has the same text as 23.1.5.4.3 - absolutely the same procedures. But 23.1.5.4.3 is "High-Speed USB Controller in Peripheral Mode". And paragraph 23.1.5.4.4 "High-Speed USB Controller in Host/Peripheral Mode" virtually has the same programming sequence. So, that stuff IS programmed in driver - it is generic ARM CPU and has nothing with USB chip. That's good.

2) The stuff which works as USB host is in musb driver. However, looking into it (and TWL4030) I see an extensive check of VBUS level, even in peripheral mode. So, I strongly suspect that w/out VBUS signal a peripheral device like USB stick may not respond to any connection attempt. So, for debuging the VBUS may be needed.

3) There is some play with DM/DP (D-/D+) lines and for a moment I am not sure - is it only needed during some extra microUSB protocols and we can skip it for now or it is a part of initial HOST-Bdevice setup (I am still not very familiar with USB basics).

BTW, can you point me to some spec of BQ24150?

http://talk.maemo.org/showthread.php...950#post588950
http://www.ti.com/lit/gpn/bq24150

Sure any usual peripheral device will check for VBUS usually, as quite obviously e.g. a USB-memstick can't work without VBUS for power supply.
Anyway this does NOT apply e.g. for externally powered USB-hubs, and also for quite a number of external HDD which also regularly need their own power wallwart and thus are not relying on VBUS.
As mentioned before we face problems with BME interfering bq24150 and resetting it immediately when I issue that i2cset cmd to start boost mode. When we -SIGSTOP BME, then the system watchdog will reboot N900 after some 60 sec. When we kill -9 BME or otherwise terminate it, we don't do any better. When we simply replace BME executable by a dummy then we get a bootloop ->reflashing needed.
So my strong suggestion is to focus on logical hostmode for now, and tackle the boostmode/VBUS bit later when we know our host is working on a logical level.

cheers
jOERG

I suppose the easiest way around that would be