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

Active Topics

Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 4 days, 1 hr ago
Handbook (2)
to Maemo 7 / Leste by teroyk - 5 days, 1 hr ago
more...

Page 97 of 110

Thread Tools

	javispedro	2010-05-28 , 08:47
	Posts: 2,355 \| Thanked: 5,249 times \| Joined on Jan 2009 @ Barcelona	#961

Originally Posted by blue_led

so limitaton on real n900 device with not id pin hardwired : any a-state machine can not start, and bme with charger check procedure prevent bus to enter suspend state and my final conclusions are
as nokia deliver n900 ( with glorious bme ) can't perform otg as everybody know that
the only host hope for us is b_host and i am confident it can be reached without a pc

To check this was one of the reasons I had started testing with the N810. All of the previous devices (including non id pin in connector ones) use a_host state.

The Following 3 Users Say Thank You to javispedro For This Useful Post:
blue_led, MohammadAG, S0urcerr0r

	joerg_rw	2010-05-28 , 10:32
	Posts: 2,222 \| Thanked: 12,651 times \| Joined on Mar 2010 @ SOL 3	#962

Originally Posted by flailingmonkey

I have started to wonder if Nokia is actually not allowed to assist in these efforts to determine how to manually turn the USB controller to hostmode, due to USB Consortium crap, or if its just due to the bme system being closed-source. Does the partial OTG software implementation in the drivers provide any actual benefits beyond pure peripheral mode? Or is it there because they started work on OTG and realized they couldn't finish it, and reworked that code instead of removing all the OTG-ness.

I have been wondering about literally hacking the bme. basically, the program would not change, and maybe with the magic of LD_PRELOAD and some tracing, we'd fake out the syscalls/library calls it would make (akin to how rootkits hide themselves).

AIUI they simply swapped the USB receptacle (and added a 1k VBUS R to PHY 1707) to get by the OTG cert. The driver isn't exactly from Nokia, but is more like a generic linux driver pushed by maybe mentorgraphics originally.
The whole bme stuff doesn't interfere right now, as we don't want OTG so we don't need the USB driver controlled VBUS ringing (needed for HNP & SRP), and I so far fail to see evidence a "stop bme" neutered bme would conflict with pure hostmode.

__________________
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 2 Users Say Thank You to joerg_rw For This Useful Post:
blue_led, S0urcerr0r

	joerg_rw	2010-05-28 , 11:28
	Posts: 2,222 \| Thanked: 12,651 times \| Joined on Mar 2010 @ SOL 3	#963

Originally Posted by javispedro

To check this was one of the reasons I had started testing with the N810. All of the previous devices (including non id pin in connector ones) use a_host state.

Yes, but aiui this was accomplished by "echo host >mode" triggering a fake ID_GND signal from "PHY" layer to the above machinery, which our 1707 alas is incapable to do.

I studied 2 versions of SPRUF98 for OTG-USB, and found there are actually 3 'correct' ways to put the musb core to hostmode:
* ID pin grounded causing the corresponding flag bit in RXCMD from PHY being asserted, which results in A role for the device and puts musb core into hostmode (for obvious reasons this seems not possible on N900)
* HNP to walk the musb core thru the state transitions involved with host role change (the thing egoshin somewhat accidentally exploited by keeping VBUS alive so session end wasn't detected when swapping the cable, and which might be possible to do by blue_led suggested method, without need of a kickstart PC)
* FORCE_HOSTMODE bit, which - according to
SPRUF98D - October 2009,
"§23.1.4.11 Register to Enable the USB 2.0 Test Modes (TESTMODE)" does:

bit 7 FORCE_HOST:
Set this bit to forcibly put the USB controller into Host mode when SESSION bit is set,
regardless of whether it is connected to any peripheral. The controller remains in Host mode
until the Session bit is cleared, even if a device is disconnected. And if the FORCE_HOST but
remains set, it will re-enter Host mode next time the SESSION bit is set. The operating speed is
determined using the FORCE_HS and FORCE_FS bits.

alas it seems there will be no automatic speed negotiation, no session-end detection and no HOSTDISCON IRQ generated, so the software statemachine found mainly inside function
559 static irqreturn_t musb_stage0_irq()
in musb_core.c which is driven entirely by IRQ triggered by the musb core harware, won't play nice.
Nevertheless we can probably, even definitely, by some patches force the software statemachine into the correct state when sensing a "echo host >mode" is done. Same time we would config the musb core and PHY correctly (set FORCE_HOST bit, enable the DM_PD and DP_PD resistors in PHY for physical hostmode config, etc), and then poll HOSTDISCON from DevCtl register, to detect attachment/removal of a peripheral and his pullup R. We will need a patch in USB protocol driver (I'm wildly guessing here) to do this poll and start chatting with peripheral when due.

description of the FORCE_HOST operation mode

23.1.3.4.6 FORCE_HOST
The Force Host test mode enables the user to instruct the core to operate in Host mode, regardless of
whether it is actually connected to any peripheral i.e. the state of the CID input and the LINESTATE and
HOSTDISCON signals are ignored. (While in this mode, the state of the HOSTDISCON signal can be read
from bit 7 of the DevCtl register.)
This mode, which is selected by setting bit 7 within the Testmode register, allows implementation of the
USB TEST_FORCE_ENABLE (7.1.20). It can also be used for debugging PHY problems in hardware.
While the FORCE_HOST bit remains set, the core will enter Host mode when the Session bit is set and
remain in Host mode until the Session bit is cleared even if a connected device is disconnected during the
session. The operating speed while in this mode is determined for the setting of the FORCE_HS and
FORCE_FS bits of the Testmode register in Section 23.1.4.11.

description of IRQ we will not see in FORCE_HOST mode

HOSTDISCONNECT_RISE
Generate an interrupt event notification when
Hostdisconnect changes from low to high. Applicable only in
host mode (DpPulldown and DmPulldown both set to 1b).

please hit 'thanks' if you feel this is a useful post

The Following 16 Users Say Thank You to joerg_rw For This Useful Post:
Big Phat Jan, blue_led, Chrome, egoshin, frals, fw190, hcm, javispedro, jkq, joshv06, MohammadAG, S0urcerr0r, SpeedEvil, titan, trx, zod

titan	2010-05-28 , 13:54
Posts: 946 \| Thanked: 1,650 times \| Joined on Oct 2009 @ Germany	#964

do you think it would be possible to disable FORCE_HOSTMODE at CONNECT IRQ and enable it again at DISCONNECT IRQ?
or the other way around: temporarily enable FORCE_HOSTMODE upon CONNECT
set devctl, and disable it again?

Originally Posted by joerg_rw

Nevertheless we can probably, even definitely, by some patches force the software statemachine into the correct state when sensing a "echo host >mode" is done. Same time we would config the musb core and PHY correctly (set FORCE_HOST bit, enable the DM_PD and DP_PD resistors in PHY for physical hostmode config, etc), and then poll HOSTDISCON from DevCtl register, to detect attachment/removal of a peripheral and his pullup R. We will need a patch in USB protocol driver (I'm wildly guessing here) to do this poll and start chatting with peripheral when due.

The Following 2 Users Say Thank You to titan For This Useful Post:
joerg_rw, S0urcerr0r

	joerg_rw	2010-05-28 , 15:18
	Posts: 2,222 \| Thanked: 12,651 times \| Joined on Mar 2010 @ SOL 3	#965

Originally Posted by titan

do you think it would be possible to disable FORCE_HOSTMODE at CONNECT IRQ and enable it again at DISCONNECT IRQ?
or the other way around: temporarily enable FORCE_HOSTMODE upon CONNECT
set devctl, and disable it again?

host has 2 pulldown R (15k)
peripheral has 1 pullup R 1k5 (depending on low speed / full speed either on DP or DM line)
host detects attachment of peripheral when one of the D lines is pulled up (= HOSTDISCON)

So, to detect attachment of a peripheral, the host MUST have both pulldown R enabled (this is obviously the default idle state of N900)
Also host MUST (for the normal procedure) provide 5V VBUS, otherwise the peripheral (unpowered) has no means to pullup any D line

N900 switches from default idle PHY config (which is similar to host config, 2 pulldown, see above) to peripheral PHY config (= 1 pullup, no pulldowns), on sensing VBUS. Musb_hdrc driver, musb core, and PHY all do not know about bq24150, so enabling boost mode aka 5V supply mode will make the N900 think it has been attached to a host -> change to peripheral mode -> we lost the game.

We need to explicitly switch to hostmode by doing 'echo host >mode', as without that we don't have a means to detect attachment of a peripheral correctly.

So on issuing 'echo host >mode':
*)
We need to FORCE_HOST, make sure the pulldowns stay enabled, do other mandatory configs wrt for example powersaving mode - refer to SPRUF98, and start VBUS supply boost if that is what we want (quite usually it is. Except for externally powered host mode, i.e. host mode while charging, using a Y-cable)
Then we set SESSION bit [edited after first tests]
Then we can poll for HOSTDISCON flag changing state, which signals us one of the D lines was pulled up.
I have to speculate a little what's correct sequence from then, probably
we check whether D+ or D- was pulled up (we can read out from PHY's debug register iirc), and set LowSpeed / FullSpeed accordingly

The operating speed while in this mode is determined for the setting of the FORCE_HS and
FORCE_FS bits of the Testmode register in Section 23.1.4.11.

Now we are ready to pass control to the logical driver talking to the connected peripheral, i.e. start ENUM, aka force software statemachine into hostmode
Whenever the logical aka protocol driver detects a disconnect of peripheral, either by timeout, or by HOSTDISCON changing state, it needs to reset SESSION, and we go back to *)

When we do a 'echo OTG >mode', the driver needs to stop logic protocol subdriver if there's still a session established, then disable VBUS boost if it was enabled, reset musb core and PHY, and restart the software state machine.

Please take the above with a grain of salt, it was written down quickly from memory, without checking back with the datasheets/specs etc, to give you a quick start in the right general direction. I may edit this post if I find inaccuracies on a later more close check, so reread occasionally please.

Last edited by joerg_rw; 2010-06-03 at 12:44.

The Following 7 Users Say Thank You to joerg_rw For This Useful Post:
blue_led, hcm, javispedro, MohammadAG, S0urcerr0r, titan, trx

sarahn	2010-05-28 , 15:56
Posts: 243 \| Thanked: 172 times \| Joined on Sep 2007 @ silicon valley	#966

Originally Posted by joerg_rw

So on issuing 'echo host >mode':
*)
We need to FORCE_HOST, make sure the pulldowns stay enabled, do other mandatory configs wrt for example powersaving mode - refer to SPRUF98, and start VBUS supply boost if that is what we want (quite usually it is. Except for externally powered host mode, i.e. host mode while charging, using a Y-cable)
Then we can poll for HOSTDISCON flag changing state, which signals us one of the D lines was pulled up.
I have to speculate a little what's correct sequence from then, probably
we check whether D+ or D- was pulled up (we can read out from PHY's debug register iirc), and set LowSpeed / FullSpeed accordingly
Then we set SESSION bit
Now we are ready to pass control to the logical driver talking to the connected peripheral, i.e. start ENUM, aka force software statemachine into hostmode
Whenever the logical aka protocol driver detects a disconnect of peripheral, either by timeout, or by HOSTDISCON changing state, it needs to reset SESSION, and we go back to *).

An excerpt from my kernel patches, which I posted:

Code:

		if (testmode & MUSB_TEST_FORCE_HOST) {
			u8 r,reg;
      void __iomem *mbase = musb->mregs;

			musb_force_term(musb->mregs,MUSB_TERM_HOST_HIGHSPEED);

			r = musb_ulpi_readb(mbase, ISP1704_DEBUG);
			DBG(1,"Linestate %x\n",r);
			switch(r) {
			case 2:
				musb->port1_status |= USB_PORT_STAT_LOW_SPEED;
				reg = musb_readb(mbase, MUSB_TESTMODE);
				reg &= ~MUSB_TEST_FORCE_FS;
				reg &= ~MUSB_TEST_FORCE_HS;
				musb_writeb(mbase, MUSB_TESTMODE, reg);

				reg = musb_readb(mbase, MUSB_POWER);
				reg &= ~MUSB_POWER_HSENAB;
				musb_writeb(mbase, MUSB_POWER, reg);

				musb_force_term(musb->mregs,MUSB_TERM_HOST_LOWSPEED);
				break;
			case 1:
				/*High or full speed*/
				reg = musb_readb(mbase, MUSB_TESTMODE);
				if(reg &  MUSB_TEST_FORCE_HS) {
					/*High speed*/
					reg &= ~MUSB_TEST_FORCE_FS;
					musb_writeb(mbase, MUSB_TESTMODE, reg);

					reg = musb_readb(mbase, MUSB_POWER);
					reg |= MUSB_POWER_HSENAB;
					musb_writeb(mbase, MUSB_POWER, reg);
				} else {
					/*Full speed*/
					reg |= MUSB_TEST_FORCE_FS;
					musb_writeb(mbase, MUSB_TESTMODE, reg);

					reg = musb_readb(mbase, MUSB_POWER);
					reg &= ~MUSB_POWER_HSENAB;
					musb_writeb(mbase, MUSB_POWER, reg);
				}

				musb_force_term(mbase,MUSB_TERM_HOST_FULLSPEED);

				break;
			case 0:
			case 3:
				/*invalid*/
				WARNING("Invalid line state of %d\n",r);
				break;
				
			}
		} else {

			/* high vs full speed is just a guess until after reset */
			if (devctl & MUSB_DEVCTL_LSDEV)
				musb->port1_status |= USB_PORT_STAT_LOW_SPEED;
		}

sarahn	2010-05-28 , 16:05
Posts: 243 \| Thanked: 172 times \| Joined on Sep 2007 @ silicon valley	#967

Also, once this is ready, to my knowledge there is no reason you couldn't kick all of this off via the id pin interrupt from the twl4030 and stop it when the cable is disconnected.

	joerg_rw	2010-05-28 , 16:27
	Posts: 2,222 \| Thanked: 12,651 times \| Joined on Mar 2010 @ SOL 3	#968

Originally Posted by sarahn

An excerpt from my kernel patches, which I posted:

I gather you do this speed setting (which is btw exactly what I had in mind) on
801 if (int_usb & MUSB_INTR_CONNECT) {...

The problem I see is we never enter the whole
559 static irqreturn_t musb_stage0_irq()
function, once we've set FORCE_HOST correctly, as it will disable the IRQ generation from musb core.
So we can either postpone FORCE_HOST & setting SESSION until the core threw an IRQ for MUSB_INTR_CONNECT, and do it then same time as the speed settings you have there.
My concern is we need VBUS (usually) for a CONNECT to happen (btw MUSB_INTR_CONNECT is the same like the HOSTDISCON IRQ?). This may cause the core to enter peripheral state on PHY 1707 sensing VBUS, if we don't set FORCE_HOST prior to supplying VBUS

Or we do a soft-IRQ/simulated IRQ by calling the routine directly. I don't know if that will work though, as for all I understand it's a IRQ callback function which might be a little icky to call directly.

cheers
jOERG

[edit]
There is no IRQ from TWL4030 ID pin, for two reasons:
1) we don't use twl4030 at all for USB, so the ID pin IRQ needs to be handled somewhere else and passed in to the USB driver stuff
2) it's unclear if the ID pin really is connected from TWL4030:R11 to the USB receptacle, and it's pretty hard to virtually impossible to find a micro-B plug with ID pin grounded

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

The Following 2 Users Say Thank You to joerg_rw For This Useful Post:
S0urcerr0r, trx

blue_led	2010-05-28 , 19:54
Posts: 306 \| Thanked: 566 times \| Joined on Jan 2010 @ Romania	#969

the id pin of usb receptacle is very connected to twl chip
i use a modified uB to A adapted during my tests
you can see orange a jumper and i can replace it with resistors
twl chip have inside comparator sensing 0, 100k 200k 400k resistor between id pin and ground ( old ? charger specs ?! )

tear id to ground switch to a_idle as expected

Attached Images

Last edited by blue_led; 2010-05-28 at 20:13.

The Following 5 Users Say Thank You to blue_led For This Useful Post:
flailingmonkey, Fumanchu, fw190, joerg_rw, S0urcerr0r

sarahn	2010-05-28 , 20:33
Posts: 243 \| Thanked: 172 times \| Joined on Sep 2007 @ silicon valley	#970

Yup, we've known about the id pin causing an interrupt and by default switching to a_idle and also setting some sysfs file to read id (I forget which) instead of vbus. That only changes that particular state.
When vcc is applied logically you should go to a_wait_bcon, that may not be useful though.

At some point I got an SRP when I started a session under forced host mode. I do not recall the exact sequence to get there.

IIRC you'll find within that state machine for irq 0 people already fake out some interrupts.

I have always booted with the usb cable attached and in the latest kernel I think I saw some fixes related to that, so I'm hopeful those patches will help.

In context save and restore the resistors are set back to peripheral, and somewhere in either plat-omap or mach-omap2 the phy can be put into low power mode(?) also resetting back to peripheral for automatic charger detection. Need to fix that, those changes are on my implemented but untested list as I am getting a kernel panic atm during boot.

If this doesn't work I'm going to patch 2.6.29 with beagleboard musb patches and see what the differences are to the maemo 2.6.28, though I am told musb is flaky on the beagleboard too. I think there is a patch to fix not being able to leave suspend under host mode if it happens, and that was a state I saw. I was also trying to prevent suspend outright