Active Topics

 


Closed Thread
Thread Tools
Posts: 946 | Thanked: 1,650 times | Joined on Oct 2009 @ Germany
#881
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
Originally Posted by egoshin View Post
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"?
 
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#882
Originally Posted by titan View Post
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.
 

The Following User Says Thank You to egoshin For This Useful Post:
Posts: 306 | Thanked: 566 times | Joined on Jan 2010 @ Romania
#883
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

Last edited by blue_led; 2010-05-18 at 22:36.
 

The Following 5 Users Say Thank You to blue_led For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#884
Originally Posted by blue_led View Post
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)
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N

Last edited by joerg_rw; 2010-05-19 at 00:28.
 

The Following 4 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 306 | Thanked: 566 times | Joined on Jan 2010 @ Romania
#885
but lines 1141-1142 from tusb6010 don't ring a bell ?
 
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#886
Originally Posted by blue_led View Post
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.
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N

Last edited by joerg_rw; 2010-05-19 at 01:24.
 

The Following User Says Thank You to joerg_rw For This Useful Post:
Posts: 60 | Thanked: 144 times | Joined on Jan 2010 @ Philadelphia
#887
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.
 

The Following User Says Thank You to flailingmonkey For This Useful Post:
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#888
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.

Last edited by egoshin; 2010-05-19 at 06:19.
 

The Following 2 Users Say Thank You to egoshin For This Useful Post:
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#889
Originally Posted by joerg_rw View Post
[*]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 (?)

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

[*]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 )

[*]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).

Last edited by egoshin; 2010-05-19 at 06:44.
 

The Following 2 Users Say Thank You to egoshin For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#890
Originally Posted by egoshin View Post
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

Originally Posted by egoshin View Post
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

Originally Posted by egoshin View Post
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..."
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
 

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

Tags
awesomeness in the works, boulevard of broken deals, host, i am the dealbreaker, inspector gadget lies, mobidapter is a scam, nokia fanbois, otg, over 9000, usb, usbcontrol


 
Forum Jump


All times are GMT. The time now is 15:46.