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

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?

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

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.

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

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

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

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

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

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.