maemo.org - Talk
Page 89 of 110 « First 798788 89 909199 Last »
Show 40 post(s) from this thread on one page

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Nokia N900 (https://talk.maemo.org/forumdisplay.php?f=44)
-   -   N900 will not allow USB OTG! (https://talk.maemo.org/showthread.php?t=31921)

titan 2010-05-17 20:17
Re: N900 will not allow USB OTG!
 
yes, I did see the log message. maybe my USB A F/F adapter is broken? or my USB hub??
here's the script I used:
Code:
#!/bin/sh
echo 5 > /sys/module/musb_hdrc/parameters/debug
echo host >/sys/devices/platform/musb_hdrc/mode
sleep 1
echo H >/proc/driver/musb_hdrc
cat /sys/devices/platform/musb_hdrc/mode
Quote:
Originally Posted by egoshin (Post 662812)
Interesting. Sometime I can't do it too but I blamed it to some leftovers and repeat it after removing battery.
BTW, did you see in log a message "twl4030_set_host() after 4030 OTG_CTRL=0x26"?

egoshin 2010-05-18 05:20
Re: N900 will not allow USB OTG!
 
Quote:
Originally Posted by titan (Post 663024)
yes, I did see the log message. maybe my USB A F/F adapter is broken? or my USB hub??
here's the script I used:
Code:
#!/bin/sh
echo 5 > /sys/module/musb_hdrc/parameters/debug
echo host >/sys/devices/platform/musb_hdrc/mode
sleep 1
echo H >/proc/driver/musb_hdrc
cat /sys/devices/platform/musb_hdrc/mode
Can you show the log? There are some conditions which should be set and I suspect - there is a difference in hubs too.

blue_led 2010-05-18 21:50
Re: N900 will not allow USB OTG!
 
i found why otg state machine skip some states

from http://mxr.maemo.org/fremantle/sourc...usb/omap2430.c

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
159 * connect. They can trigger transient overcurrent conditions
160 * that must be ignored.
161 */
162
163 devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
164
165 if (is_on) {
166 musb->is_active = 1;
167 musb->xceiv->default_a = 1;
168 musb->xceiv->state = OTG_STATE_A_WAIT_VRISE;
169 devctl |= MUSB_DEVCTL_SESSION;
170
171 MUSB_HST_MODE(musb);
172 } else {
173 musb->is_active = 0;
174
175 /* NOTE: we're skipping A_WAIT_VFALL -> A_IDLE and
176 * jumping right to B_IDLE...
177 */
178
179 musb->xceiv->default_a = 0;
180 musb->xceiv->state = OTG_STATE_B_IDLE;
181 devctl &= ~MUSB_DEVCTL_SESSION;
182
183 MUSB_DEV_MODE(musb);
184 }
185 musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
186
187 DBG(1, "VBUS %s, devctl %02x "
188 /* otg %3x conf %08x prcm %08x */ "\n",
189 otg_state_string(musb),
190 musb_readb(musb->mregs, MUSB_DEVCTL));
191 }

i run around this code and from http://mxr.maemo.org/fremantle/sourc...usb/tusb6010.c

1141 if (is_host_enabled(musb))
1142 musb->board_set_vbus = tusb_source_power;
1143 if (is_peripheral_enabled(musb))
1144 xceiv.set_power = tusb_draw_power;

workaround : can we put some #ifdef ...board_rx-51 ... code for charge vbus from bq24150 ?

omap_set_vbus need more attention
line 167 : wait to rise vbus over 4.4 V and after that at line 171 we have host enabled

220 #define MUSB_HST_MODE(_musb)\
221 { (_musb)->is_host = true; }

i think this host mode can be sustained by vbus above 4.4v or by session valid as i found here http://talk.maemo.org/showpost.php?p...&postcount=783

latest specifications allow peripherals detection in absence of vbus . this must be checked on isp1707 case

joerg_rw 2010-05-18 23:38
Re: N900 will not allow USB OTG!
 
Quote:
Originally Posted by blue_led (Post 664922)
i found why otg state machine skip some states
...
...
Well, nice finding, but WE DO NOT WANT OTG!!!!
WE NEED PLAIN HOSTMODE

[edit]
As javispedro made clear to me, this is a little ambiguous. So let me elaborate...
Code:
musb->xceiv->state = OTG_STATE_A_WAIT_VRISE;
is about OTG state machine (evident by the name if nothing else).
We need to avoid OTG state machine, we want
Code:
echo host >mode
to work correctly.
Correctly here means:
  • configure PHY to host setup = 2 pulldown R instead of 1 pullup for device mode
  • disable VBUS interrupt triggering weird state changes in OTG state machine (either by switching off the interrupt in TWL4030, or by setting the driver to a mode where it ignores this interrupt)
  • enable PHY originated "IRQ" (this in fact is a ULPI state message I guess) for detecting attachment of peripheral devices, I.E. sense when one of the D-lines is pulled high by the peripheral's pullup R from VBUS to D(+/-)
  • on detection of peripheral attachment, start whatever a plain vanilla host does (ENUM etc)
Nota bene this list does NOT include enabling VBUS boost to supply 5V to USB, as we want to handle that independently from logical hostmode (refer to http://wiki.openmoko.org/wiki/USB_ho...USB_host_modes). We might want to operate hostmode without burning battery for VBUS boost, by using an externally powered hub. We even might want to charge N900 while in logical hostmode (a very common usecase)

blue_led 2010-05-19 00:43
Re: N900 will not allow USB OTG!
 
but lines 1141-1142 from tusb6010 don't ring a bell ?

joerg_rw 2010-05-19 00:56
Re: N900 will not allow USB OTG!
 
Quote:
Originally Posted by blue_led (Post 665076)
but lines 1141-1142 from tusb6010 don't ring a bell ?
Yes, they tell me tusb6010 driver is not considering we might want logical host mode WITHOUT powering the peripheral device (maybe the device this driver was written for doesn't make sense with non-powered hostmode, e.g when it's a device with decent power supply, not a battery and charging over USB). We don't want to make same mistake, and plain vanilla hostmode DOES NOT NEED VBUS to work, it should rather be totally agnostic about VBUS state, so the line
Code:
musb->xceiv->state = OTG_STATE_A_WAIT_VRISE;
clearly indicates there's something fishy with the way we try to achieve hostmode on N900 by now.
Rationale: a plain vanilla USB host has a "always on" 5V VBUS supply (sometimes literally, just hooked up to system's main 5V rail), and there is no such thing like handling VBUS for a simple host, that's all OTG which we want to avoid after all.

flailingmonkey 2010-05-19 01:06
Re: N900 will not allow USB OTG!
 
I understand that OTG is not our end goal, but hasn't the progress so far in putting the N900 into a host role and communicating with USB devices been by using what was left in the kernel or drivers for the purposes of OTG?

It seems that there are a few approaches being taken towards connecting the N900 to USB devices (as devices), so perhaps the relevent wiki page http://wiki.maemo.org/N900_Hardware_USB_Host needs to be updated? There is a lot of information that repeatedly get clarification, which might be easier to organize in a single page rather than reading through every post.

egoshin 2010-05-19 06:16
Re: N900 will not allow USB OTG!
 
Friends,

We need first to set USB H/W in host mode without Host Negotiation Protocol invocation. I tried (briefly) FORCE_HOST mode but 1707 doesn't recognize a device connect. It is needed to eliminate initial PC connection from picture. It may be:

a) incorrect pulldown - and I am reading USB protocols to find which should be used and how. 1707 or other side may not able to read correctly with incorrect pulldowns.

b) a hub is not required to support any connection-style USB protocol (i used HUB to get USB stick mounted) - it should be in constant connect mode and send a periodic updates.

I plan to repeat a FORCE_HOST mode test with external Hard Disk which may support a "connection" protocol. But I also browse through my electronic equipment which has microusb - it SHOULD support "connect" message.

EDIT: if ARM USB gets "connect" message (actually - "session started") then musb driver works - my experiment proves that!

Also I try to figure out - is "connection" signaling is needed to switch USB in a real host mode or is not - the problem is that then I used FORCE_HOST mode then the slave device doesn't react on any write or read transfer - looked like other side is dead.

Finally, a driver doesn't support ADP at all but I think with manual host mode setup it should be not an issue for us.

egoshin 2010-05-19 06:36
Re: N900 will not allow USB OTG!
 
Quote:
Originally Posted by joerg_rw (Post 665017)
[*]configure PHY to host setup = 2 pulldown R instead of 1 pullup for device mode
I will double check but it seems that 1707 has both pulldown R. You can find my message a couple of days ago then I was surprised by this difference with 1704 description. Looks like driver was prepared to work in host mode (?)

Quote:
[*]disable VBUS interrupt triggering weird state changes in OTG state machine (either by switching off the interrupt in TWL4030, or by setting the driver to a mode where it ignores this interrupt)
VBUS interrupt from TWL4030 has nothing with musb driver in N900 - it passes it. driver works only with musb interrupts and twl4030 interrupt just triggers change in some /sys file and message to ke-recv.

Quote:
[*]enable PHY originated "IRQ" (this in fact is a ULPI state message I guess) for detecting attachment of peripheral devices, I.E. sense when one of the D-lines is pulled high by the peripheral's pullup R from VBUS to D(+/-)
That is ADP, I suspect. It is not needed now as long as musb driver is forced in HOST mode - we expect do USB host fast today. Later - yes, to save energy, but it is a next stage, I believe.

EDIT: from USB docs it seems that ADP is needed only as a signal to switch VBUS on. And other docs says that ADP flip-flop and recogntion are manual - and it is a reason why it is absent from musb (nobody wrote it :))

Quote:
[*]on detection of peripheral attachment, start whatever a plain vanilla host does (ENUM etc)
For a moment, musb driver waits "session start" interrupt to continue and "hostmode" + "session" bits in DEVCTL + VBUS in DEVCTL. If it gets all three - we have a right whole protocol stack on top of musb (usb read/write, enumeration, usb-2-SCSI conversion etc).

joerg_rw 2010-05-19 06:52
Re: N900 will not allow USB OTG!
 
Quote:
Originally Posted by egoshin (Post 665375)
Friends,

We need first to set USB H/W in host mode without Host Negotiation Protocol invocation.
I tried (briefly) FORCE_HOST mode but 1707 doesn't recognize a device connect. It is needed to eliminate initial PC connection from picture. It may be:

a) incorrect pulldown - and I am reading USB protocols to find which should be used and how. 1707 or other side may not able to read correctly with incorrect pulldowns.

b) a hub is not required to support any connection-style USB protocol (i used HUB to get USB stick mounted) - it should be in constant connect mode and send a periodic updates.
well, that's exactly what I said 2 posts above

Quote:
Originally Posted by egoshin (Post 665375)
I plan to repeat a FORCE_HOST mode test with external Hard Disk which may support a "connection" protocol. But I also browse through my electronic equipment which has microusb - it SHOULD support "connect" message.

EDIT: if ARM USB gets "connect" message (actually - "session started") then musb driver works - my experiment proves that!
yes. OTG is a full host protocol driver (plus device protocol driver) plus some state machine wrapper

Quote:
Originally Posted by egoshin (Post 665375)
Also I try to figure out - is "connection" signaling is needed to switch USB in a real host mode or is not - the problem is that then I used FORCE_HOST mode then the slave device doesn't react on any write or read transfer - looked like other side is dead.

Finally, a driver doesn't support ADP at all but I think with manual host mode setup it should be not an issue for us.
Connection signaling is needed to start negotiation/ENUM of the host. Connection is defined as pullup of one of the D-lines, and that depends on correct pulldown Rs on host and pullup R on device.
For lockup please refer to
musb_core.c line 2496 "/* resets the controller..."


All times are GMT. The time now is 18:21.
Page 89 of 110 « First 798788 89 909199 Last »
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8