Re: N900 will not allow USB OTG!
 

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

Re: N900 will not allow USB OTG!
 

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)

Re: N900 will not allow USB OTG!
 

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

Re: N900 will not allow USB OTG!
 

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.

Re: N900 will not allow USB OTG!
 

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?

Re: N900 will not allow USB OTG!
 

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.

Re: N900 will not allow USB OTG!
 

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. :) )

Re: N900 will not allow USB OTG!
 

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

Re: N900 will not allow USB OTG!
 

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

Re: N900 will not allow USB OTG!
 

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)

Re: N900 will not allow USB OTG!
 

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

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

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

Re: N900 will not allow USB OTG!
 

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.

Re: N900 will not allow USB OTG!
 

@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.

Re: N900 will not allow USB OTG!
 

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

Re: N900 will not allow USB OTG!
 

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

/jOERG

Re: N900 will not allow USB OTG!
 

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

Re: N900 will not allow USB OTG!
 

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 ! :D
so now we have additional datasheet to read seating on toilet.

Re: N900 will not allow USB OTG!
 

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.

Re: N900 will not allow USB OTG!
 

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.

Re: N900 will not allow USB OTG!
 

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.]]

Re: N900 will not allow USB OTG!
 

Javispedro, what do you mean by "does nothing"?
Have you tested with negative results?
AIUI the PHY chip has a parallel->serial converter for sending data, a serial->parallel converter for receiving data (both for all I understand are completely unchanged function for both host and device mode!), and the only thing to switch to enter "host mode" are the pull-up resp pull-down resistor.
Even that doesn't completely stop host mode if not accomplished, as I could witness by using OM GTA02 Freerunner in externally powered host mode successfully (on GTA02 switching off the VBUS booster also switches the pulldowns/pullup)

Re: N900 will not allow USB OTG!
 

Awhile ago in this thread (page 55), it was suggested by andree to add some lines of code which would set USB_TEST_FORCE_HOST
(http://talk.maemo.org/showpost.php?p...&postcount=541)

I compiled a custom kernel, and verified the code was indeed being called, but it appeared to have no effect whatsoever, no dmesg output (well, besides a printk I added) and charging / USB with a computer still working as usual.
(http://talk.maemo.org/showpost.php?p...&postcount=542)

Re: N900 will not allow USB OTG!
 

i don't think so ! you have 99.(9) % chances to be wrong.

1.5 K pull up resistor is required for peripheral mode. this resistor inform a host " hello i am here " when a device is inserted into a hub port. this resistor may be disconnect when data is transmitted but is not mandatory.

15k are required for host mode bring D+ & D- at low level, this mode is called SE0 and indicates a reset or disconnected connection.
these resistors may stay always connected as data lines impedance is 90 Ω and resistors don't matter lead to 88.9 Ω total impedance on host. in fact many cheap usb hubs have soldered the resistors on board.
data bus can happily do his job with resistors in place.

i think those resistors are activated by driver or by usb core transparently and from standardization POV PHY registers must be located at same address across all manufacturers. this fact i searched last night and i found faircild transceiver to be pin to pin identical with isp1707.
we must search all founded datasheets for registers addresses

i think i found how to gain host direction mode.
the phy unconditionally gains ownership of the data bus by asserting dir . if ID pin is used and if this pin is grounded the phy start as "host" . don't forget phy is bidirectional from data POV and dir is OUTPUT from phy. so how to change direction ?
simple: there is a mechanism called "turn around" which can reverse direction of the transceiver. a turnaround cycle is required
whenever the bus changes direction.
because receptacle ID pin is not wired to isp1707 all we need is a primordially turnaround cycle in host mode and leave after that the driver to do his usual jobs. it is clear why we can't find any instruction to force host mode ? "forcing_host" is a simple turnaround cycle and a jump/ go_to in the a_mode code
now somebody must write the code.

void extremely_beautiful_simple_stupid_ solution {void}

Re: N900 will not allow USB OTG!
 

Please pretty please can we stop talking about ID pin every second sentence. It is used for OTG only, and we don't need it, don't want it, can't use it, and don't care!

otherwise I don't see the point where I'm supposedly "99.9%" wrong. I used Openmoko GTA02 with a USB keyboard, while those pulldown resistors were disabled, and the pullup ususally signaling the GTA02 is a device was enabled. It worked. Period
:confused:

Re: N900 will not allow USB OTG!
 

It is not enough - ISP1707 should be switched too.

And some driver internals, it doesn't switch yet to host-mode-only state machine.

BTW, writing 'H' to /proc/devices/musb_hdrc just enforces Host Negotiation Protocol on connection from N900 to PC. Doesn't help working with USB memory stick...

Re: N900 will not allow USB OTG!
 

Can you detail a little more here?

Which resisters and which line pullup/down and what was a sequence?

Re: N900 will not allow USB OTG!
 

Please refer to
http://wiki.openmoko.org/wiki/USB_ho...USB_host_modes
and
http://wiki.openmoko.org/wiki/Specia...aka_Y-Cable.29
and
http://people.openmoko.org/joerg/sch...public_RC0.pdf

Re: N900 will not allow USB OTG!
 

I agree with you, but I'm gonna mention it one more time to help with your crusade of "let's forget about the ID pin." Wasn't the ID pin first introduced only for OTG (and maybe for charging?), and thus that's why micro connectors have a fifth pin? The conversation should narrowly be about forced host mode. You know, like the non-micro-A n800 has.

That said, I still think a working Beagleboard uB<->uB n810 configuration has much information to give. I perused the Fremantle kernel changelog yesterday, and glanced through some of the USB related code. At a naive level, there's very interesting things in there, and some stuff that seems specific to making USB appliance/charging compliance at whatever cost. Also, from reading that stuff, I get the impression that even with chip changes and reroutes, that, besides the jack, Nokia made software-only changes to disable OTG and host mode (initially using just the TWL4030, and rerouted USB stuff to isp1707 later? [look at usb_emergency_stop() comments] Actually, initially using a OMAP3430 with a TWL5030 [Beagleboard?]).

So, again, if someone get's the Beagleboard <-> n810 configuration working, the next step would be to put the n900 USB kernel/driver code in a Beagleboard. After someone gets it to compile with whatever kernel version it's using, my theory is that it won't work. And I'm saying it won't work because of specific Nokia changes, and not because of anything else. Thus, if that's close to true, someone could slowly (or quickly!) morph the Fremantle USB kernel/driver code until the Beagleboard starts working. That code could be the gold that used to be feldspar.

Re: N900 will not allow USB OTG!
 

daperl, I'm really sorry the 20 times I hit the thanks button didn't show up. :D
Thanks a zillion and please keep pushing us into the right direction.
Ah, do I need to mention a 1000% agree with every word you said?

cheers
jOERG

Re: N900 will not allow USB OTG!
 

Yes, afaik Nokia had to switch to 1707 just because early versions of the TWL4030 had no charger detection.

Re: N900 will not allow USB OTG!
 

That's why I am asking if we know of any forced host mode setting that works on a Beagle Board, considering they're using mostly the same driver.

EDIT: <removed stupid assertion until more info>.

I gather that mode switching is also broken on the Beagleboard: http://www.beagleboard.org/irclogs/i...2-17#T14:58:33

Re: N900 will not allow USB OTG!
 

A pity.
Has anyone actually tried?

I mean, if it is not working, what's the point in having it in the repository?

Yeah, it's a good habbit of theirs. (also for FM transmitters, and other stuff)

But still, it is hard to believe that Quim actually lied that the limitation comes from a hardware level.

Perhaps they said that because they didn't want us to bother and try it anyway?

Re: N900 will not allow USB OTG!
 

Quim and Igor told the absolute truth. OTG is not possible on a device with micro-B receptacle. Igor even explained why they had to do that.

Please also read the previous post of mine, with the blue and greenblue text. I elaborate on that topic a little more there

/j

Re: N900 will not allow USB OTG!
 

I read all your posts from the last 10 or so pages. Brilliant work. I'm not talking about OTG.
On the link, they say exactly the following:
This is what I meant.

Re: N900 will not allow USB OTG!
 

hmm, to me it seems a) Quite a Number of people mix OTG and hostmode and aren't really aware of the elementary difference, and b) most have to rely on what they're told and just try to cite as good as they can, sometimes failing as they are no Electronics Engineers.

I wouldn't blame anybody for that.

/j

Re: N900 will not allow USB OTG!
 

It is from their's honest point of view. The real truth can be tested.

Re: N900 will not allow USB OTG!
 

After booting N900, cat /proc/interrupts | grep usb:
Plug into powered hub, as a gadget:
Plug into self-powered hub, as a host: no new interrupts.

Even though you can hack around musb until you really convince it that it should be in host mode
I get no debug output from it when plugged into a selfpowered hub via female-female adaptor, and seemingly no interrupts.

Also, I tried to build non-otg, only host mode kernel, but fails to boot (wild guess: tries to insert gadget modules during early start).

Re: N900 will not allow USB OTG!
 

82 means - your USB is still in B-mode, with A-session requested but not confirmed from other side. No VBUS at all.

Re: N900 will not allow USB OTG!
 

I see, so that is the DEVCTL MUSB register.


From what I gather, the ISP1707 is actually only configured specifically in one single function: http://mxr.maemo.org/fremantle/sourc...omap2430.c#400 . The twl3040 stuff is just sitting there wasting cycles, as it accesses the twl3040 registers via i2c instead of ulpi (thus configuring the 3040 and not the isp1707). (Curiously enough it's also wasting a bit of power according to 1704a datasheet as the way it is setup it is uselessly sampling the ID line).

Today I was trying a stupid approach of just lying in the linkstate about the ID pin state, and patching the force host mode function with certain 1707 specifics, like disabling the dm & dp pulldown resistors. Most of the time though, at the a_idle state, the PHY seems to be shut down: I just get timeouts trying to write via ulpi to registers, UNLESS the cable is connected or unless I have just recently reset it.

The charger sysfs node also queries the 1707, and also suffers from timeouts when no connection.

My second wild guess of the day thus is that there can't be any power saving mode when waiting for a device in host mode -- the driver should configure the 1707 properly then waste power by repeatedly trying to start a session until it succeeds. I think this is what the N8x0 does while in the a_wait_bcon state (but I really have no idea).

Re: N900 will not allow USB OTG!
 

Javier,

The cable/hw patchwork is not enough, some additonal activity in driver is needed. I am working on it.

There are two un-answered issues now for me -

- configuration of 1707 DM/DP pulldown registers is done in reverse with document. What is it - document error or software bug which does still not produce a problem? I don't know but try to find, it actually changes the resitor values only.

- Is VBUS voltage needed for 1707 to support ARM CPU USB in HOST mode? I am not familiar with USB protocol details yet to answer it fast.