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

joerg_rw | # 741 | 2010-05-05, 09:52 | Report

Originally Posted by javispedro View Post

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

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)

cb22 | # 742 | 2010-05-05, 14:21 | Report

Originally Posted by joerg_rw View Post

Javispedro, what do you mean by "does nothing"?
Have you tested with negative results?

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)

The Following 2 Users Say Thank You to cb22 For This Useful Post:
javispedro, joerg_rw

blue_led | # 743 | 2010-05-05, 14:53 | Report

Originally Posted by joerg_rw View Post

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)

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}

Last edited by blue_led; 2010-05-05 at 15:51.

The Following User Says Thank You to blue_led For This Useful Post:
S0urcerr0r

joerg_rw | # 744 | 2010-05-05, 16:08 | Report

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

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

egoshin | # 745 | 2010-05-05, 16:27 | Report

Originally Posted by cb22 View Post

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)

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

The Following User Says Thank You to egoshin For This Useful Post:
S0urcerr0r

egoshin | # 746 | 2010-05-05, 16:29 | Report

Originally Posted by joerg_rw View Post

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

Can you detail a little more here?

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

The Following User Says Thank You to egoshin For This Useful Post:
S0urcerr0r

joerg_rw | # 747 | 2010-05-05, 16:36 | Report

Originally Posted by egoshin View Post

Can you detail a little more here?

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

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

Originally Posted by

To recap, the direction of power can be controlled:
Set to 0 (default), no power is provided at the USB port, charging is enabled, and host 15K pulldowns are removed from D+ and D-:
echo 0 > /sys/devices/platform/neo1973-pm-host.0/hostmode
Set to 1, provides up to 500mA USB power at the USB port (FreeRunner only), disables charging from USB, and applies 15K pulldowns to USB D+ and D-:
echo 1 > /sys/devices/platform/neo1973-pm-host.0/hostmode

Last edited by joerg_rw; 2010-05-05 at 16:44.

The Following 2 Users Say Thank You to joerg_rw For This Useful Post:
egoshin, javispedro

daperl | # 748 | 2010-05-05, 17:14 | Report

Originally Posted by joerg_rw View Post

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!

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.

Last edited by daperl; 2010-05-05 at 17:44. Reason: number jumble

The Following 6 Users Say Thank You to daperl For This Useful Post:
cb22, jkq, joerg_rw, MohammadAG, sjgadsby, Venemo

joerg_rw | # 749 | 2010-05-05, 17:25 | Report

daperl, I'm really sorry the 20 times I hit the thanks button didn't show up.

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

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

joerg_rw | # 750 | 2010-05-05, 17:37 | Report

Originally Posted by daperl View Post

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 OMAP4330 with a TWL5030 [Beagleboard?]).

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