Re: N900 will not allow USB OTG!
 

OK, good news:

1. I was able to set hardware in HOST mode with VBUS on. I don't remember for a moment - was it via TWL4030 VBUS boost or via "i2cset" usage (it is night in CA). However, looking into log I think - VBUS setup was a result of boost in TWL4030.
ARM CPU USB started work as HOST, recognized the new device attachment (I used USB memory stick) and tried to communicate.

2. musb driver was able to work in HOST mode which was triggered by CONNECT interrupt and tried to assign HUB, enumerate device and so on.

Not very good news (yet :))

3. session init with USB stick failed and I don't know yet - is it because of I/O error, USB stick underpowered or some protocol violation.

EDIT: - protocol error, msg type doesn't correspond to expected.

Note: I didn't switch ARM CPU USB to FORCE_HOST mode - just played with VBUS supply and tried use 'host' and 'H' commands.

Note2: don't believe file /sys/devices/platform/musb_hdrc/vbus - it says 'Vbus=off" permanently (programming error).

Note3: VBUS on discharge battery - 45min and 1/4 battery gone. But screen was constantly ON and intensive work in X-Term too.

Re: N900 will not allow USB OTG!
 

It was my understanding that the twl4030 capacitor for boost mode was not there (in the schematic at least).

If this is the case, then VBUS is going to be very low - under 3V?
This might cause some semblance of activity on the port - but will not actually work.

External supply would be an easy way to test it. Or of course a voltmeter to verify.

Re: N900 will not allow USB OTG!
 

Mine too, in fact, a post earlier by joerg seems to state exactly that:

Re: N900 will not allow USB OTG!
 

I didn't attach multimeter - my has too thick probes.
But VBUS voltage is confirmed by reading both - TWL4030 and 1704 registers:

A. File /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus shows 1. The same value is in this file during attachment of PC USB host port or charger. It is from STS_HW_CONDITIONS of TWL4030.

B. ARM CPU USB module, DevCtl shows 0xd5 which means "VBUS above AValid, below VBusValid" or in my mind: 0.8v-1.4v < VBUS < 4.4v-4.6v. So, it should be enough, at least from 1707 point of view.

USB stick tried to establisjh attention via pullup/pulldown play with D+/D- in my understanding (but I don't know USB line protocol details). ARM CPU USB triggered interrupts about session start and under "full speed" protocol and indicated my "host session valid". And that happened only after a physical attachment of USB stick.

However, morning analysis shows that ARM CPU USB controller stayed as B-device (high order bit in DevCtl=0xd5). That probably means that N900 tries to swap roles with other side (became 'host') via HNP but USB stick doesn't understand it. (I used 'echo H >/proc/drivers/musb_hdrc')

Or it may be a physical error - morning analysis shows that N900 can't read anything from USB stick. It transmits but read stops due to timeout. (BTW, do we need to swap D-/D+ if N900 is a host?)

Equally, it is possible that some 1704 configuration must be changed. I found the same pullup/pulldown resistor table in TWL4030 description and driver setup it's properly for TWL4030 but in incorrect way for 1704 during regular USB run as a B-device disk.

And finally, you may be right - VBUS voltage is not enough to power USB stick. I will try with external hard disk next day.

Re: N900 will not allow USB OTG!
 

Yes, I was borking the driver.

Where are you seeing that? All I can see is that after Power on Reset http://mxr.maemo.org/fremantle/sourc...omap2430.c#420 id pin sampling and both dp & dp pulldowns are enabled (seemingly to enter OTG mode?).

When vbus is detected by twl3040 twl3040-usb fires a sysfs-node changed event (linkstat) which I believe bme is listening to, which then proceeds to read the charger sysfs node thus causing musb_verify_charger to run thus causing DP & DM pull downs to be disabled and strong pull up on DP to be enabled (thus entering gadget/peripheral mode).

Note that configuring twl3040 via i2c as the twl3040-usb driver does is for all practical purposes as I understand a NOP (save for reading/writing registers related to pins it has connected, like vbus or id). Only valid configuration of isp1707 is via ULPI.

No; for example self powered hubs should work without VBUS on host. Since there are quite a few cons to having the vbus pump enabled (bme will have to be lied at, possibly high battery consumption, ...) I suggest we center on enabling host mode _without_ vbus. It should be possible.

Re: N900 will not allow USB OTG!
 

Table 14.
Operating states and their corresponding resistor settings
(only DP_PULLDOWN and DM_PULLDOWN are shown here):
...
Host high-speed ... 1b 1b
...
Peripheral high-speed ... 0b 0b
...
OTG device peripheral high-speed ... 0b 1b

You say you see both are enabled. Me too. But device is not in Host mode, right? At least TWL4030 has both zeroes until switch to host mode.


I put a couple of debug prints in musb_verify_charger(). Never seen once. Will try to see it with a regular charger.

To make TWL4030 configuration working I did some tricks - power registers are protected and you can't change some TWL4030 USB registers while it is sleeping.


Good!
I will think and continue Saturday.

Re: N900 will not allow USB OTG!
 

from datasheet of 1704
"8.7.2.1 VBUS valid comparator
This comparator is used by hosts and A-devices to determine whether the voltage on
VBUS is at a valid level for operation. The ISP1704A minimum threshold for the VBUS valid
comparator is 4.4 V. Any voltage on VBUS below this threshold is considered invalid.
During power-up, it is expected that the comparator output will be ignored.'"

if otg controller expect a valid vbus on isp1704 vbus probe pin maybe this is the reason for timeouts

do a voltage check with a voltmeter . if vbus is below 3.3V this voltage come from isp1707 internals.
............
OTG controller ALWAYS start a FS session even if a HS device is attached .
................
check also usb documentation especially appendix C you will find some C code at de end of document

@javispedro
NO . this setting is for swapping receptacle on the other side of the printed board to avoid datalines cross over and traces be routed on one single board layer.


this post will be edited later with additional informations

Re: N900 will not allow USB OTG!
 

You guys should see some interesting output when plugged into that DC <-> uB adapter dongle. My n900 "sounds" likes it trying to talk to that thing constantly. Maybe it's time to get an extra one of those and crack it open.

Re: N900 will not allow USB OTG!
 

Hm-m... But it definitely transmits... Or it may be a comparator for validity check to supply a valid VBUS from 1707?

I don't think so - until I programmed TWL4030 I didn't see any VBUS voltage above VSESSVALID (0.8v - 1.4v) or in ARM CPU USB description - "Above session end, below AValid".

EDIT: "Above AValid, below VBusValid" - sorry for confusion, still sleepy.

Re: N900 will not allow USB OTG!
 

i think all tests must be done respecting this minimals :
--without bme running
--charger detection disabled inside 1707
-- 5V applied from external source to 1707
this make valid vbus for A state machine

a hacked cable is needed :)

Re: N900 will not allow USB OTG!
 

Sorry, but I can't seem to stop sticking my naive nose into this.

Isn't the n800 considered a "dumb" USB device? By "dumb," I mean that the hardware and the software (pre n810 kernel?) of an n800 knows nothing about USB OTG or USB charging.

If the above is true, and USB hardware and software is supposed to be backwards compatibile, I find it hard to believe that the USB chips are gonna try and be too smart. What I mean is, isn't it likely that the isp1707 and/or the TWL4030 are suppose to work in a scenario with two "dumb" USB devices?

Again, if the above is true, the hardware shouldn't care about what role the device it's in is playing. My n800's battery can power a USB music card and a pair of usb speakers at the same time!

So, once again, I think it's all about the software. Except this time, let's forget about the Beagleboard, let's make it all about the n800 and why it works. I realize there are crazy changes between 2.6.21 and 2.6.28, but the USB spec for "dumb" devices hasn't changed at all.

So, I agree with blue_led, let's turn of charger detection and roll back the n900 to the "dumb" USB device that it is. But looking too closely at the Fremantle USB kernel/driver code is muddying the waters, in my opinion. Quite frankly, that might be the last code you want to look at. Or at least do a diff with the 2.6.28 or the 2.6.27 baselines.

Re: N900 will not allow USB OTG!
 

But save for maybe id or vbus monitoring (not pumping since we can't use it) there's no other use for twl3040 in our current use case. Basically, twl3040 should be out of the picture, and we'd need only accesses either SoC registers (via mapped i/o) or isp1707 registers (via ulpi, either using Nokia's musb_ulpi accesor functions or manually writing the SoC registers).

Also more importantly and along the lines of what you noticed is that you cannot get to the isp1707 while it is in standby (/lowpower protocol) or entirely shut down. And the twl3040-usb driver uses the vbus change interrupt to decide whether to power the phy on or off (and this does affect the real isp1707 I believe) -- to write or read a single register out of it you need to either have vbus or manually give power and reset the 1707. The latter is what I did to be able to write to the OTG_CTRL registers when setting H via procfs.

Re: N900 will not allow USB OTG!
 

I am already using my N810 for comparisons :) Of course a way more similar configuration is the Beagleboard -- and the reason execution traces of its driver would be much interesting.

Re: N900 will not allow USB OTG!
 

4030 vbus sysnode flipped to 1 really easily when I was experimenting with charging (for minutes on just remaining voltage in small capacitors while battery charger is trying to charge from it). I wouldn't trust it as a measure that useful vbus is present.

Re: N900 will not allow USB OTG!
 

On the current flowchart I've been making in my head of what the driver is doing (usual disclaimer: might be wrong) it uses the twl3040 vbus sense to notify bme which then runs isp1707 manual charger detection. So for anything serious it does a second check; but seemingly uses vbus sense alone for powering on/off the PHY.

Re: N900 will not allow USB OTG!
 

@javispedro
behavior you described have sense for detecting high power charger.
when vbus is detected, then by enabling D+ pull up resistor (& disabling precious 15 K resistors) this apply voltage on D+ line and if the voltage is returned on D- line mean high power charger which have D+ and D- shorted by standard
enabling D+ resistor is not made for peripheral mode in this case.

bme interferences are very annoying

Re: N900 will not allow USB OTG!
 

OK, I just looked into ways to switch USB subsystem to HOST mode. And I tried to powerup USB stick a little. Looks successful, because N900 USB subsystem feels USB stick attachment.

The real decision about TWL4030 VBUS can be done with multimeter (poisoned to by another USB-USB connector and disassemble it to measure).

Actually, I spoke about TWL4030. It has a protection scheme in addition to poweroff/standby difficulties of accessing registers. Not yet sure - does it cover VBUS control...

Re: N900 will not allow USB OTG!
 

please be very clear about what we are talking about
VBUS *DETECTION* can be done inside TWL4030, ISP1707, and bq24150
VBUS *POWERSUPPLY* can be done by bq24150 ONLY

So no use in "The real decision about TWL4030 VBUS can be done with multimeter", as TWL4030 is missing a capacitor and thus can NOT provide VBUS power

Also refer to previous post of mine regarding i2cset - you can power VBUS for up to 32sec, if you -sigstop BME prior to twiddling with bq24150 (even longer if you issue a watchdog timer clear cmd to bq24150 every 30sec at latest). After some 60sec the system watchdog will reboot your device due to bme stopped, unless you -sigcont it prior to that. But 30sec should be more than enough to make decent tests on whether usb hostmode is working (unless of course when MUSB_HDRC or whatever kernel driver for USB is depending on BME, of course)

/j

Re: N900 will not allow USB OTG!
 

and if we find what bme discuss with system watchdog a simple timer routine can tickle both bq24150 and system watchdog every 30s to leave us alone with our tests.

Re: N900 will not allow USB OTG!
 

Cool, then a few more thoughts and I'll get out of the way.

What about a binary search type algorithm to try and morph the n8x0 USB kernel/driver code towards the Fremantle code until it breaks usbcontrol and host mode on your n810.

How about those Android kernels that people were porting to the n8x0? I seem to remember those being anywhere from 2.6.29 - 2.6.31. Doesn't plenty of USB stuff work out-of-the-box with those kernels? If so, getting host mode working with your n810 shouldn't be monumental. That code would probably be easier to put into a Fremantle kernel and driver than 2.6.21 code.

Aren't the MeeGo guys already running a 2.6.33 kernel with USB networking. Maybe that USB code has yet to be gifted all the n900 OTG/host disabling stuff. A quick MeeGo compile of usbcontrol and who knows.

Lastly, if a contrast with the n900 would be helpful (or even possible), and if you don't already have it, stskeeps posted some code and notes about BME for the n8x0. It's probably over at the Mer Wiki if needed. Worst case, I could dig it out of my basement if I have to.

Re: N900 will not allow USB OTG!
 

Fr 7. Mai 2010] [21:28:13] <javispedro> btw in case you're interesting when looking through the kernel, the n8x0 host stuff is in the n900 kernel. instead of omap2430.c they use http://mxr.maemo.org/fremantle/sourc...usb/tusb6010.c
[Fr 7. Mai 2010] [21:57:05] <DocScrutinizer> 597 * REVISIT: It would be possible to add support for changing between host
[Fr 7. Mai 2010] [21:57:05] <DocScrutinizer> 598 * and peripheral modes in non-OTG configurations by reconfiguring hardware
[Fr 7. Mai 2010] [21:57:05] <DocScrutinizer> 599 * and then setting musb->board_mode. For now, only support OTG mode.
[Fr 7. Mai 2010] [21:57:29] <DocScrutinizer> from http://mxr.maemo.org/fremantle/sourc...usb/tusb6010.c

Re: N900 will not allow USB OTG!
 

Are you sure BME does something with watchdogs? There are two watchdogs known to the kernel (OMAP and TWL), and both are handled by DSME.

Re: N900 will not allow USB OTG!
 

found on ulpi erata

Depending on the application, the link should enable or disable the appropriate Vbus interrupts. Example
settings for typical applications are given in Table
Application VbusValid(*) SessValid SessEnd
Standard Host Yes No No
Standard Peripheral No Yes No
OTG A-Device Yes Yes No
OTG B-Device No Yes Yes
Table – Vbus indicators in the RXCMD required for typical applications
* The VbusValid indicator in the RXCMD comes from either the internal VbusValid comparator, or the external Vbus
indicator

and for shure 1707 pin layout seem to be a standard
another chip found ( without charger detection )
http://www.st.com/stonline/products/.../stulpi01a.pdf

tusb6010.c
957 if (!(musb_readl(tbase, TUSB_DEV_OTG_STAT)
958 & TUSB_DEV_OTG_STAT_ID_STATUS))
959 musb_writel(tbase, TUSB_INT_SRC_SET,
960 TUSB_INT_SRC_ID_STATUS_CHNG);

funny but not for n900

Re: N900 will not allow USB OTG!
 

Confirmed:

connecting charger causes VBUS signal, some application (BME?) reads /sys/devices/platform/musb_hdrc/charger --> calls musb_charger_detect() and if a charger is a high-performance charger (not PC) then VDAT signal enforces a call to musb_verify_charger().

The last function clears DP/DM PULLDOWN and sets only DM_PULLDOWN.

But this happens only for high performance charger.

Re: N900 will not allow USB OTG!
 

I wonder why it sets any pulldown at all, actually I'd think even chrg_det won't work with both pulldowns set, it rather should use a pullup on one dataline, and a (much larger) pulldown plus voltage comparator on the other dataline for detection of D+/- short.
Then when a high power charger is detected, any D+/- meddling is highly senseless, as you'll notice unplugging of the charger anyway, by VBUS drop (if you simply switch off the charger, no side effects will arise from that either, as next return of VBUS - when you plug the wallwart to the wall again - will trigger another D+/- short detection cycle).

My 2 cent
/j

[edit]
Nokia-N900-02-8:~# cat /sys/devices/platform/musb_hdrc/charger /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus
1) nothing attached
0 0
2) blank cable, D+/- short
0 0
3) VBUS (from hub downstream)
0 1
4) VBUS plus D+/- short
1 1
5) like 3) but after 4)
1 1

we see
a) /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus is 5V VBUS detection, probably from twl4030
b) /sys/devices/platform/musb_hdrc/charger is D+/- short detect, aka charger_detect, probably from 1707
c) charger_detect only works (or is triggered) when VBUS is applied
d) charger_detect is 'stricky', se 3) vs 5) above. I.E. it is reset to 0 only when vbus is removed (I have not checked to keep D+/- short while removing VBUS, but I'd expect the standard charger when unplugged from mains does exactly that, and it results in 0 0 )




bme_RX-51 open files:
I wonder what /dev/twl4030-adc might do...

Re: N900 will not allow USB OTG!
 

OK, last result about VBUS -

I repeated the test (boost VBUS with DRVVBUS of OTG_CTRL register of TWL4030 chip) with naked cable and multimeter:

N900 --- cable --- USB memory stick

and measured voltages.

Between black and red cable - 3.5V
Between red and another cable - 2.5V

Another combinations gave me around 0 or 1.5V

EDIT: this time a can't get a repeated session setup. Only "cable problem" or so message. However, it was in HOST mode - it tries to enumerate usb1-0.

Re: N900 will not allow USB OTG!
 

well, TWL4030 boost mode does not work, I told you before. Maybe now you believe me. Also take care, we do not know what happens to TWL4030 when enabling the boostmode and no capacitor is on the chargepump. It might break.

Re: N900 will not allow USB OTG!
 

3.5V - it is from my experiment, see my previous post.

Sure - 1707, it is from code.

It is a pure wish of BME and we are not sure then it reads file '.../charger'

charger_detect is called by reading file /sys/devices/platform/musb_hdrc/charger and it seems that BME reads it after it gets signal about VBUS UP.

Re: N900 will not allow USB OTG!
 

Sorry, Joerg, I believe multimeter. It is possible to create multiple explanations but fact is - 3.5V between red and black cable, after I set DRVVBUS in DEVCTL of TWL4030.

Re: N900 will not allow USB OTG!
 

Aha, so why don't you believe your multimeter then wrt to 3.5V being a definitely broken non-functional state for the TWL4030 chargepump, and also completely useless for any attached USB device?
We need five Volt, not 3.5. Of course a chargepump without charge-pumping capacitor can forward the battery voltage (well maybe), this only shows clearly the capacitor on TWL4030 actually is missing

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.