N900 will not allow USB OTG! - Page 73 - maemo.org

joerg_rw | # 721 | 2010-05-03, 21:58 | Report

Originally Posted by blue_led View Post

if the vbus are not proper decoupling datalines transitions may have jitter out of specs.
this phenomen is visible on cheap computerboard with integrated graphics, horizontal sync signal may have jitter because insufficient decoupling and filtration of graphic "card" power

Well if we get hostmode working, and even manage to supply VBUS (which was considered absolutely impossible when this lengthy thread started, then I'll happily take whatever jitter, especially on horizontal sync.
Though the jitter will come from higher frequency ripple which is easily filtered by something like a low ESR 10uF inside N900, rather than a crappy 120uF retrofitted on the outside to a semi-broken cable that has a incontinuity in wave impedance where you added the capacitor.

TBH that spec from USB.org is kinda crap, as a 120uF doesn't say anything about the source impedance of the VBUS feed without such a monster C. In fact a ultrafast hard regulator for VBUS may do a vastly better job on suppressing ripple and glitches than a 10.000uF with a relatively high ESR.

I think we shouldn't get defocused from the real problems by such geeky niche concerns. Believe me, hostmode will be fine and everybody happy, even without big C

cheers
jOERG

The Following 2 Users Say Thank You to joerg_rw For This Useful Post:
MohammadAG, Venemo

Venemo | # 722 | 2010-05-03, 22:20 | Report

Hey guys, I'm really happy to see some progress here!

My thoughts:
Would it be possible to power the USB peripherials with an external power source?
For example, with a special USB cable. (Like the ones they used with the 770?)

That way, the N900 would only need to do the communication, and the battery would be thankful also.

(Just my 2 cents)

joerg_rw | # 723 | 2010-05-03, 22:44 | Report

Originally Posted by Venemo View Post

Hey guys, I'm really happy to see some progress here!

My thoughts:
Would it be possible to power the USB peripherials with an external power source?
For example, with a special USB cable. (Like the ones they used with the 770?)

That way, the N900 would only need to do the communication, and the battery would be thankful also.

(Just my 2 cents)

Yes, it's possible. That's what the term 'externally powered hostmode" in previous posts refers to. You can even charge the N900 while it's in hostmode.
Or you decide to crank up the bq24150 internal power source and drain the battery of N900 to momentarily read out a USB memstick abroad, or provide power to a USB keyboard while on the train. This wouldn't eat unbearable amounts of power

cheers
jOERG

The Following 4 Users Say Thank You to joerg_rw For This Useful Post:
imperiallight, MohammadAG, thecursedfly, Venemo

egoshin | # 724 | 2010-05-04, 07:31 | Report

I tested VBUS handling by TWL4030 and ISP1707 and got some conclusions.

1. The real USB control is done by combination of ISP1707 + CPU USB (musb) interface communicating via ULPI bus. It is partly transparent - session start/end is detected by 1707 and sent to CPU hardware. TWL4030 actually is used as for misc purpose (it has no ULPI and can't do an efficient data transfer but handles a lot of another functions like KBD, sound etc). The VBUS is going to it only for BME server convenience (at least it reads VBUS directly from twl4030-usb driver).

2. Combination 1707+ARM CPU USB doesn't handle HOST mode because 1707 chip doesn't recognize HOST mode (ID pin is not grounded). I don't know yet - can it be changed by properly setup of DM_PULLUP in 1707, it needs some testing

3. However, ARM CPU USB has a possibility to FORCE HOST mode in spite of 1707 signaling. ARM CPU USB core enters in HOST mode. Needs testing.

4. I didn't look into BME server issue but it seems that disconnect BME server from VBUS high in HOST mode is pretty simple because it uses a separate VBUS signal from TWL4030. However, I observed a drop in VBUS voltage which I believe is a result of transferring the whole system into "charge" mode. I base on Joerg's experiments that suspending BME server prolongs VBUS high, so - it is not a result of CHRG_DET signal from ISP1707 to BQ24150 but manual BME server intervention.

The Following 4 Users Say Thank You to egoshin For This Useful Post:
blue_led, joerg_rw, S0urcerr0r, Venemo

Venemo | # 725 | 2010-05-04, 10:37 | Report

Originally Posted by joerg_rw View Post

Yes, it's possible. That's what the term 'externally powered hostmode" in previous posts refers to. You can even charge the N900 while it's in hostmode.
Or you decide to crank up the bq24150 internal power source and drain the battery of N900 to momentarily read out a USB memstick abroad, or provide power to a USB keyboard while on the train. This wouldn't eat unbearable amounts of power

cheers
jOERG

Huh, really? This is the best news I heard about the N900 in months!

Could you be so kind as to tell me how to do it? (Or at least point me to a post which tells?)

BTW, what is bq24150?

MohammadAG | # 726 | 2010-05-04, 12:10 | Report

Originally Posted by Venemo View Post

Could you be so kind as to tell me how to do it? (Or at least point me to a post which tells?)

BTW, what is bq24150?

Too early for him to give out instructions, first someone has to fix the driver as he said.

From this thread alone you should know it handles battery management and mode switches.

The Following User Says Thank You to MohammadAG For This Useful Post:
joerg_rw

Venemo | # 727 | 2010-05-04, 13:25 | Report

Originally Posted by MohammadAG View Post

Too early for him to give out instructions, first someone has to fix the driver as he said.

Oh, so the news that it doesn't support it by hardware, were false?
Nice to know.
Is the driver in question open source?
Is there another one which could be ported instead?
What's the glitch with the current one?

Finally, isn't there anyone in the "compiling custom kernels" thread who could help out with this?

After all, they've got USB over IP support, and other nice stuff.

Originally Posted by MohammadAG View Post

From this thread alone you should know it handles battery management and mode switches.

Thx for explaining.
(I tried to keep up, I followed the first 50 or so pages of this thread, but after it became pointless moaning, I didn't. It is good to see some real progress.

)

blue_led | # 728 | 2010-05-04, 14:06 | Report

Originally Posted by egoshin View Post

I tested VBUS handling by TWL4030 and ISP1707 and got some conclusions.

1. The real USB control is done by combination of ISP1707 + CPU USB (musb) interface communicating via ULPI bus. It is partly transparent - session start/end is detected by 1707 and sent to CPU hardware. TWL4030 actually is used as for misc purpose (it has no ULPI and can't do an efficient data transfer but handles a lot of another functions like KBD, sound etc). The VBUS is going to it only for BME server convenience (at least it reads VBUS directly from twl4030-usb driver).

2. Combination 1707+ARM CPU USB doesn't handle HOST mode because 1707 chip doesn't recognize HOST mode (ID pin is not grounded). I don't know yet - can it be changed by properly setup of DM_PULLUP in 1707, it needs some testing

3. However, ARM CPU USB has a possibility to FORCE HOST mode in spite of 1707 signaling. ARM CPU USB core enters in HOST mode. Needs testing.

4. I didn't look into BME server issue but it seems that disconnect BME server from VBUS high in HOST mode is pretty simple because it uses a separate VBUS signal from TWL4030. However, I observed a drop in VBUS voltage which I believe is a result of transferring the whole system into "charge" mode. I base on Joerg's experiments that suspending BME server prolongs VBUS high, so - it is not a result of CHRG_DET signal from ISP1707 to BQ24150 but manual BME server intervention.

1) this is according schematics !! D4280 ulpi bus go straight to omap processor.no need for software tests
2) ID pin is not connected to micro usb receptacle . very old news
3) id pin sense is part of OTG protocol, signaling, et c. according brief datasheet isp can be pure host and Nucleus core can switch to this mode without ID sense. ID pin have nothing in common with ulpi bus.
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
4)I suppose the real issue which was not implemented host mode is lack support for bq24150-32sec watchdog timer in the Mentor Nucleus core
also lack of Attach Detection Protocol in isp 1707 make difficult to make a decision about vbus keep alive.
a ghetto style approach ... ignoring ADP, vbus comparators, interrupts, ....
ULPI bus is standardized and i think any transceiver can act on this bus . we only need to find Nucleus host G-point.

@joerg_rw : my last statement about vbus capacitor:
inside n900 there is a small 1uF capacitor . this small value is required according usb otg standard for SNP & HNP . these protocols are basically hardware done by voltage on vbus between self powered devices . i think this value is quite small when power is applied to a peripheral device .
inside N810 there is a 10 uF capacitor which can sustain ( with help of a 3 MHz high freq switching source ) power to a memorystick
i don't say 120 value is a must but pay a little attention to the vbus quality specially in testing periods. all hubs have inside this cap.
i seen in usb specs, but i don't remember where, a more exotic value of 96 uF
i hope we don't get stuck in rise and fall vbus timings

Last edited by blue_led; 2010-05-04 at 14:17.

The Following 2 Users Say Thank You to blue_led For This Useful Post:
joerg_rw, S0urcerr0r

javispedro | # 729 | 2010-05-04, 14:11 | Report

Originally Posted by egoshin View Post

3. However, ARM CPU USB has a possibility to FORCE HOST mode in spite of 1707 signaling. ARM CPU USB core enters in HOST mode. Needs testing.

musb/debug initiated forced host mode does nothing -- if someone has a Beagleboard could they check if it's supposed to work there?

The Following 4 Users Say Thank You to javispedro For This Useful Post:
daperl, joerg_rw, qole, S0urcerr0r

MohammadAG | # 730 | 2010-05-04, 14:17 | Report

Originally Posted by Venemo View Post

Oh, so the news that it doesn't support it by hardware, were false?
Nice to know.
Is the driver in question open source?
Is there another one which could be ported instead?
What's the glitch with the current one?

Finally, isn't there anyone in the "compiling custom kernels" thread who could help out with this?

After all, they've got USB over IP support, and other nice stuff.

Thx for explaining.
(I tried to keep up, I followed the first 50 or so pages of this thread, but after it became pointless moaning, I didn't. It is good to see some real progress.

)

OTG is impossible, host mode isn't.
Read 4 pages back you'll find most of your questions answered

(start from http://talk.maemo.org/showpost.php?p...&postcount=683 if you want)

The Following 3 Users Say Thank You to MohammadAG For This Useful Post:
choubbi, joerg_rw, pelago