Re: N900 will not allow USB OTG!
 

Joerg,

Are you sure that host w/out high-performance charge capability requires VBUS=5V? The reason for my question is simple - the ARM CPU USB DEVCTL has a couple of voltage levels and so called "AValid" or A-state Valid is right about 3.5V.

Re: N900 will not allow USB OTG!
 

I think that 3.5V are the minimum voltage to allow system bootup. But it's quite outside of normal USB specs afaik. Also the TWL4030 without capacitor will probably not perform up to anything near the 200mA which bq24150 can deliver at a proper 5.0Volt to VBUS supply.
Nevertheless your results for ENUM etc are really exciting, could you try and use a selfpowered USB hub for your tests? I'd expect it should reply properly to any data sent from N900, even when the VBUS from N900 is as low as 3.5V

Re: N900 will not allow USB OTG!
 

you miss the point, sorry I was a little fuzzy. When I say 'charger_detect' I mean the content of /sys/devices/platform/musb_hdrc/charger. Repeated reading didn't change the fact it was stuck at '1' while I had removed the D+/- short. It stays at '1' until you remove VBUS voltage

Re: N900 will not allow USB OTG!
 

What do you think - Is a self powered disk suitable for this?

Or, alternatively - is any selfpowered USB hub sutable (I need to buy one)?

Re: N900 will not allow USB OTG!
 

Disk -> probably, though you should check (isolate or cut the V+ VBUS wire (red)) and connect to any normal working host.
selfpowered hub, quite sure will work. Most don't care about upstream VBUS aiui. Speedevil should know better details.


On a different topic: To me it seems like we are using the http://mxr.maemo.org/fremantle/sourc...usb/omap2430.c for N900?
In there are a number of *very* interesting details, e.g
209 #ifdef CONFIG_USB_MUSB_HDRC_HCD
210 case MUSB_HOST:
are our kernels compiled with CONFIG_USB_MUSB_HDRC_HCD ?

and
155 static void omap_set_vbus(struct musb *musb, int is_on)
156 {
157 u8 devctl;
158 /* HDRC controls CPEN, but beware current surges during device
This clearly refers to CPEN ChargePumpENable of any PHY chip. Won't work, as we need to talk to bme instead

even
151 static void omap_vbus_power(struct musb *musb, int is_on, int sleeping)
152 {
153 }
AIUI here we need to kick on bq24150 boostmode, by whatever means


272 if (is_host_enabled(musb))
273 musb->board_set_vbus = omap_set_vbus;

also interesting the lines
418 /* Recover OTG control */
419 r = musb_ulpi_readb(musb->mregs, ISP1704_OTG_CTRL);
...426
containing ISP1704 references. See e.g. http://mxr.maemo.org/fremantle/ident?i=ISP1704_OTG_CTRL

Re: N900 will not allow USB OTG!
 

OK.


Yes.

Yes.

omap2430 doesn't control OTG_CTRL VBUS. It only manipulates PULLDOWN/PULLUP resistors.

EDIT: DP/DM/ID but not VBUS.

Moreover, the special control of VBUS charge pump setup or VBUS PULLUP/PULLDOWN are absent in OTG driver, even for TWL4030. It only monitors a VBUS level.

EDIT2: driver of ISP1301 does VBUS setup but it is not even compiled.


I will look into this place as a good candidate for BQ24150 boostmode. But I can't say it now because it requires looking around a lot.

However, thank you for clue.

I already put a debug print in that place :)
And this place puzzles me a lot - the next line is

r |= ISP1704_OTG_CTRL_IDPULLUP | ISP1704_OTG_CTRL_DP_PULLDOWN;

In this line ISP1704_OTG_CTRL_IDPULLUP setup means the restore of ID ground monitoring --> restore OTG. But OTG should have ISP1704_OTG_CTRL_DP_PULLDOWN bit as ZERO in accordance with Table 14,
Operating states and their corresponding resistor settings of 1704 description.

Re: N900 will not allow USB OTG!
 

3.5V is a 'odd' state of the USB bus - there is no guarantee that stuff will work - even if the power supply stays at 3.5V under load.

If it did - then there is a chance that some USB devices may work - but most will not. The USB voltage is 4.5 (IIRC) minimum.

There are a couple of issues with regards to using USB devices or hubs from an unpowered host.
The most obvious is there is no power - selfpowered stuff will not work.
Second is that even powered devices sometimes look at usb to see if there is a host there that they should negotiate with.

One printer and one hub I have will not talk to an unpowered host (lexmark printer, and Belkin Tetrahub).

(unpowered may or may not behave as 3.5V does).

99% of cheap external powered hubs will not care.
There is a very simple way to test this.
Get a standard USB cable.
Chop it open.
Cut the red wire. (being careful not to short it, or it will explode! (or not - however - insulating the cut ends is a good plan))
Try plugging stuff into a normal host.

(try with a few cables you don't care about first, if you're unsure.)

Re: N900 will now allow USB 5V VBUS!
 

"infinite" VBUS
(explanation for those entering this endless thread here: the cmdline pasted below will provide a continuous 5V@200mA to the USB receptacle of your N900, thus meeting one of the prerequisites to connect USB devices like mice, compass, kbd... you name it):

If nothhing else, at least enjoy your USB-mugwarmer powered from N900 now :-P

cheers
jOERG

(hitting 'Thanks' highly appreciated :) )
[edit] 'start bme' is your friend ;-)
[edit2] if you're not in a hurry - a decent scriptie will follow in a short while

[disclaimer] messing around with i2cset is potentially hazardous to your device. The above commandline is considered safe (though without any warranty implied or fart, as usual) - but please watch out for typos, and do NOT experiment with i2cset parameters as long as you don't know exactly what you're doing.


Result (intermediate): http://talk.maemo.org/showthread.php...247#post650247

Re: N900 will not allow USB OTG!
 

Joerg,
What version of i2cset are you using? The version I have doesn't seem to know anything about the -m flag... It's the one from i2ctools in Debian.

Re: N900 will not allow USB OTG!
 

Anecdotal note: I think that the N900 itself its one gadget that will refuse to negotiate with a host without vbus.