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

Active Topics

Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 20 hrs, 57 mins ago
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 22 hrs, 11 mins ago
Maemo repository (3)
to Community by torsen - 1 day, 13 hrs ago
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 2 days, 11 hrs ago
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 3 days, 17 hrs ago
more...

Page 83 of 110

Thread Tools

egoshin	2010-05-11 , 06:23
Posts: 992 \| Thanked: 995 times \| Joined on Dec 2009 @ California	#821

@joerg:

I finally found a time and did tests. Without BME it doesn't work. But it seems that some application also listen VBUS signal because even with stopped BME a dbus server issues a note about vbus change (seen in syslog).

Moreover, if I stop BME and set VBUS then after 3-5secs the N900 LED indicator goes to constant yellow and "battery filling icon" occurs in screen.

Originally Posted by joerg_rw

[*]Could you repeat the tests as done above, but prior to that you run a 'stop bme', so we find out if annoying bme_RX-51 has its fingers in there in any way. (I could imagine detection of VBUS in/for musb_hdrc somewhat fails without bme)

It doesn't work - I lost the way to wakeup USB hardware and I can't transfer it to hostmode. The request to transfer to hostmode stays but nothing happens. I believe that BME works with USB wakeups but I still doesn't know how. The kernel code has some way to do it, of course, but I had no time to research it.

Originally Posted by joerg_rw

[*]And finally, maybe you can replace the TWL4030 VBUS boostmode call by a call to bq24150 (or a system() call [man 3 system] to invoke my above posted cmdline like
Code:
 /bin/sh -c '/sbin/stop bme && sleep 3 && /usr/local/i2cset -y -m 0x07 2 0x6b 0x01 0x05 && while sleep 28; do /usr/local/i2cset -y -m 0x80 2 0x6b 0x00 0x80; done &'
)

It doesn't work at all. As I said, the "charge" process starts but no reaction from external hard disk or USB stick. USB hardware is not switched to hostmode.

Originally Posted by joerg_rw

[*]Please publish the diffs of the patches you made to the kernel, and the exact procedure (echo x >y?) to make that happen.
AIUI it's only a few files like musb_core.c or similar, so you could as well publish the complete file(s) as an attachment to your answer.

I sorted out all diffs and now I am sure that I have only two lines of code (see before in this thread) which switches TWL4030 to VBUS ON then I issues "host" command and which are relevant to this experiments.

The exact sequence is:

1. Boot the modified kernel and wait until system set up.
2. connect USB to PC, answer on question as "PC suite mode" (not mass storage).
3. echo host >/sys/devices/platform/musb_hdrc/mode -- this command requests host operations in MUSB driver and it also switches VBUS on in TWL4030 because of my fixes.
4. echo H >/proc/drivers/musb_hdrc -- it activates a request for switching to hostmode in USB hardware
5. reconnect USB to self-powered external disk (in 5 secs). In this moment USB hardware is switched to suspend mode and hostmode is activated. After cable is attached a debug shows that signal about "new device is connected"/"session started" comes in and MUSB driver starts host-mode state machine and tries to enumerate a new device.

At this moment syslog begins display "non supported" messages. I have also some debug print switched on and it shows me that there is "end-of-TX" interrupts.

If it doesn't happen then - repeat the procedure. The check shows that in this case the request to hostmode is lost. I believe some daemon action causes it (DMCE ?).

Now I switch to looking into kernel code "why it doesn't recognize a HUB?"

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

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

egoshin	2010-05-11 , 08:15
Posts: 992 \| Thanked: 995 times \| Joined on Dec 2009 @ California	#822

Last progress:

I edited a HUB table to support protocol version 2 (my hub has this protocol version !) and kernel now recognizes it, enumerates it and command 'lsusb' shows it ! (All of it - for self-powered hub, of course).

But next stop is - "ignoring external hub". It needs some analysis - why it is chosen to ignore... Besides of that there is a lot of debug output which requires some analysis too.

EDIT: It looks like I discovered the reason of unstable results - my USB female-2-female connector has preference which side to connect to N900 (!?)

Last edited by egoshin; 2010-05-11 at 08:30.

The Following 8 Users Say Thank You to egoshin For This Useful Post:
blue_led, cproc, daperl, joerg_rw, Marshall Banana, Netweaver, qole, S0urcerr0r

	javispedro	2010-05-11 , 08:54
	Posts: 2,355 \| Thanked: 5,249 times \| Joined on Jan 2009 @ Barcelona	#823

Originally Posted by egoshin

But next stop is - "ignoring external hub". It needs some analysis - why it is chosen to ignore... Besides of that there is a lot of debug output which requires some analysis too.

Have you seen my previous post about hubs blacklisted config option?

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

blue_led	2010-05-11 , 09:06
Posts: 306 \| Thanked: 566 times \| Joined on Jan 2010 @ Romania	#824

Originally Posted by egoshin

@joerg:

I finally found a time and did tests. Without BME it doesn't work. But it seems that some application also listen VBUS signal because even with stopped BME a dbus server issues a note about vbus change (seen in syslog).

Moreover, if I stop BME and set VBUS then after 3-5secs the N900 LED indicator goes to constant yellow and "battery filling icon" occurs in screen.I

this is a "32 minute mode" of bq24150 and charge battery without software control . orange-yellow led signaling is pure hardware based. after finish 32 min timer battery charge will stop.
battery icon prove there is another piece of software who read battery charging current through current sense resistor R1130 ( Gazoo chip )

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

blue_led	2010-05-11 , 09:09
Posts: 306 \| Thanked: 566 times \| Joined on Jan 2010 @ Romania	#825

Originally Posted by egoshin

But next stop is - "ignoring external hub". It needs some analysis - why it is chosen to ignore... Besides of that there is a lot of debug output which requires some analysis too.

i think because otg is supposed to work between self powered devices directly connected

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

	javispedro	2010-05-11 , 09:40
	Posts: 2,355 \| Thanked: 5,249 times \| Joined on Jan 2009 @ Barcelona	#826

Originally Posted by javispedro

CONFIG_USB_OTG_WHITELIST=y
CONFIG_USB_OTG_BLACKLIST_HUB=y

So why not disable them both?

The latter one is the cause of the ignoring external hub one.

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

blue_led	2010-05-11 , 16:13
Posts: 306 \| Thanked: 566 times \| Joined on Jan 2010 @ Romania	#827

Originally Posted by egoshin

EDIT: It looks like I discovered the reason of unstable results - my USB female-2-female connector has preference which side to connect to N900 (!?)

isn't this behavior otg selection mode ? a-end vs. b-end ?
check on happy ( cable ) end if there is a low resistance ( close to 0 ) between pin 4 and 5 . you don't cross otg border even n900 is acting as a host.
anyway, congrats !

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

egoshin	2010-05-11 , 17:26
Posts: 992 \| Thanked: 995 times \| Joined on Dec 2009 @ California	#828

Originally Posted by blue_led

isn't this behavior otg selection mode ? a-end vs. b-end ?
check on happy ( cable ) end if there is a low resistance ( close to 0 ) between pin 4 and 5 . you don't cross otg border even n900 is acting as a host.

It is a 4-pin-to-4-pin connector of regular USB. No ID pin at all and I connect to it via Nokia USB cable.

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

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

Originally Posted by blue_led

isn't this behavior otg selection mode ? a-end vs. b-end ?
check on happy ( cable ) end if there is a low resistance ( close to 0 ) between pin 4 and 5 . you don't cross otg border even n900 is acting as a host.
anyway, congrats !

Yes, exactly - the ID pin is just to distinguish A-end from B-end of a OTG cable. The A-end is supposed to take the host role in a OTG setup *initially*, though two OTG devices can swap roles any time. That's why we don't care about ID pin (or at least we should make sure kernel doesn't care). ID pin is about OTG, and we don't want OTG, we want plain vanilla hostmode.

BTW depending on adapter type, there's most likely no 5th pin aka ID pin on the F-F adapter of egoshin. Standard size USB has only 4 pins. So it's quite obscure how such an adapter could show any asymmetry. (If it were a 5pole micro-F-F adapter then it would be useless anyway, as you could use such adapter with a OTG cable only, and it would not add any adapting function to the setup. Also even on OTG cables the 5th pin usually isn't connected to the cable and seen on the other end, means virtually *all* USB cables are 4-wire only)

We really need to check why 'echo host >mode' seems to have no effect - evidence for the missing effect is the usage of the whitelist.
Probably there are parts missing in the source, for handling plain vanilla hostmode. My suggestion would be to see how it's done in diablo for N810, and then copy&adapt the missing parts for the new hardware of N900 (i.e. 1707 PHY, twl4030 VBUS *detect*, bq24150 VBUS *supply*). I'd be happy to help on such effort, from the hardware side

The Following 4 Users Say Thank You to joerg_rw For This Useful Post:
blue_led, Marshall Banana, MohammadAG, S0urcerr0r

blue_led	2010-05-11 , 19:26
Posts: 306 \| Thanked: 566 times \| Joined on Jan 2010 @ Romania	#830

Originally Posted by joerg_rw

So it's quite obscure how such an adapter could show any asymmetry.

the only one i found is different length of pins inside receptacle ( tolerances or overheat & melted plastic of receptacle body during manufacturing process of adapter )
different connection is made first : ground , vbus and datalines and sometimes something go wrong

Last edited by blue_led; 2010-05-11 at 19:35.