Re: N900 will not allow USB OTG!
 

oopsie. Mine I ripped out from shadowJK's bq27200 readout hack

I'll create a .tgz once I have a nice scriptie, to contain the binaries

Re: N900 will not allow USB OTG!
 

i2cset and other are here.

Re: N900 will not allow USB OTG!
 

Just thought I'd add a photo or two to the thread...
Note to everyone who hasn't been following: USB host mode is in no way working, all that's happening here is that the N900 is powering a mouse... The data pins aren't even connected.

USB toothbrush anyone?

http://imgur.com/ZVwwR.jpg

http://imgur.com/M9FZP.jpg

Re: N900 will not allow USB OTG!
 

WARNING! WARNING!

Please don't experiment with stuff which you can find in this thread until you know how to handle the unexpected situations.


Explanation: I just found that N900 TWL4030 may keep settings while N900 is switched OFF. It is pretty obvious (if I think i little) - this chip is powered by battery. I was not able to reboot a kernel which booted yesterday - until I removed battery for 30secs.


Moreover, after that N900 software asked me about date, time, zone something else after that (but it is stll gave me a right advice of these values).

Re: N900 will not allow USB OTG!
 

Well, in this thread there's not really anything that messes with TWL4030, except special patched kernels ;-). Anyway a general warning won't hurt about all the stuff discussed here being even pre-alpha and not of any use or intended for end users. This are bleeding edge results of tests, addressed to developers who like to contribute and have a thorough understanding of what they're doing.

Re: N900 will not allow USB OTG!
 

usb devices are sensitive on vbus timings
i found
This ECN ensures that all USB peripherals have a detectable change in capacitance on VBus when they
are attached. This ensures that OTG devices and Embedded Hosts can detect attachment of peripherals
in the absence of VBus.
and :D
Specification Changes
The last sentence in Section 7.2.4.2 to be modified from:
“A minimum of 1.0uF is recommended for bypass across Vbus.”
To the following text:
“A USB device is required to expose a capacitance on the VBUS pin of its connector of CRPB. This
capacitance shall be greater than CRPB min for voltages on the VBUS pin from 0V to 5.25V,
regardless of whether the USB device is powered or unpowered.”


from early ( final, not pached with otg stuff , but valid ) usb standard
No device shall supply (source) current on VBUS at its upstream facing port at any time. From VBUS on its
upstream facing port, a device may only draw (sink) current. They may not provide power (my note: from 3,3v internal source ) to the pull-up resistor
on D+/D- unless VBUS is present

vbus is needed for that so let put 5v on vbus * to make peripherals happy

* joerg broke a annoying barrier between host and n900 when he finded how to enable boost mode on 24150

Re: N900 will not allow USB OTG!
 

Exactly. And btw, yet another reason for not touching the twl3040 at all =) .

Re: N900 will not allow USB OTG!
 

OK, some success (at least I think so).

I used a wall-powered hub with USB memory stick and external USB hard drive. I applied 3.5V from TWL4030 to VBUS and set Host mode of operations in ARM CPU USB.

The result - in both cases a lot of communications (TX interrupts but no RX - ?) and finally the message -

Nokia-N900-42-11 kernel: [...] usb 1-1: device v04b4 p6560 is not supported <---- this is for USB Hub with USB memory stick

Nokia-N900-42-11 kernel: [...] usb 1-1: device v0bc2 p3000 is not supported <---- this is for USB hard disk.

EDIT: verified via SuSE notebook - Hard Disk is 0bc2:3000 Seagate RSS LLC, and HUB - 04b4:6560 Cypress Semiconductor Corp. CY7C65640 USB-2.0 "TetraHub"

Taking into account the different Vendor (v*) and Product (p*) values and the very remarkable Product value for HDisk - p3000, I assume that it is values read from devices.


I looked briefly in code - yes, there is no support for that kind of devices. But it should be supported via device class - hub at least for sure. So, some software debug print is needed to find out the whole info from device... tomorrow.

Re: N900 does now allow USB hostmode!
 

Egoshin,
That's great news for sure. That's working hostmode (to the definition of host talking to peripherals and reading replies), no matter if the devices are recognized / supported or not. Everything beyond is just a question of proper drivers, and hardware side is definitely confirmed to work for hostmode now. :):):D:cool:

I like to ask you for a few favours:

1. 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.
2. 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)
3. 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 &'

   ---

   )

Congrats! :D
cheers
jOERG




[edit]
completely(?) unrelated, here some lines in http://mxr.maemo.org/fremantle/sourc...rx51_defconfig I found interesting or suspicious:
1436 # CONFIG_USB_MUSB_HOST is not set
1487 # CONFIG_USB_SERIAL is not set
1510 CONFIG_USB_TEST=m
1513 CONFIG_USB_GADGET=m
1514 # CONFIG_USB_GADGET_DEBUG is not set
1517 CONFIG_USB_GADGET_VBUS_DRAW=2
1523 # CONFIG_USB_GADGET_OMAP is not set
1540 # CONFIG_USB_G_SERIAL is not set
1544 CONFIG_USB_G_NOKIA=m

1551 # CONFIG_USB_GPIO_VBUS is not set
1553 CONFIG_TWL4030_USB=y

Re: N900 does now allow USB hostmode!
 

It is not yet something real to publish - the result was obtained mostly by voodoo dancing around - cabling switching forth and back and manupulating some controls. And that procedure is not even stable yet - I mean, sometime it is very difficult to set N900 in proper mode (for a moment I want to explore the full battery charge - it seems that I can reach my results much more easy if battery is half-charged. But don't assume that it is truth yet - it is inconclusive yet)

My primary goal up to yesterday was to find a breakthrough and main direction for subsequent work. Actually, it was a reason why I worked with TWL4030 but not BQXXXXX chip - I am not familiar with BQXXXXX chip and hesitated to play around with it and BME (BME is a near black box and I try to remove it from research).


However, the diff for main two lines is here (I skip many another lines which seems to do not work, are debug tools etc):


egoshin:musb> diff ../otg/twl4030-usb.c ../otg/twl4030-usb.c-orig
624d623
< printk(KERN_WARNING "twl4030_usb_irq: status=0x%0x\n",status);
673,675d671
< printk(KERN_WARNING "twl4030_set_peripheral() 4030 OTG_CTRL=0x%0x\n",twl4030_usb_read(twl,TWL4030_OTG _CTRL));
< twl4030_usb_clear_bits(twl,TWL4030_OTG_CTRL,TWL403 0_OTG_CTRL_DRVVBUS);
< printk(KERN_WARNING "twl4030_set_peripheral() after 4030 OTG_CTRL=0x%0x\n",twl4030_usb_read(twl,TWL4030_OTG _CTRL));
691,693d686
< printk(KERN_WARNING "twl4030_set_host() 4030 OTG_CTRL=0x%0x\n",twl4030_usb_read(twl,TWL4030_OTG _CTRL));
< twl4030_usb_set_bits(twl,TWL4030_OTG_CTRL,TWL4030_ OTG_CTRL_DRVVBUS);
< printk(KERN_WARNING "twl4030_set_host() after 4030 OTG_CTRL=0x%0x\n",twl4030_usb_read(twl,TWL4030_OTG _CTRL));

This stuff is triggered by writing 'host' to /sys/devices/platform/musb_hdrc/mode but it doesn't work in most of times because TWL4030 registers are blocked. It is needed some activity on USB to unlock it. The similar but different things are for writing a letter 'H' to /proc/drivers/musb_hdrc. I do my voodoo stuff basing on my code knowledge ... it is not that can be easily shared for a moment.


Sure, I will do it today at night or tomorrow morning. Good idea!

Yes, I will test it too. I only need to get a stable procedure, for a moment it repeats in 80% at night but mostly fails in the morning ;)

All of them are set properly. I already did some research about it. GADGET stuff is only for PERIPHERAL mode and a suspicious CONFIG_USB_MUSB_HOST/CONFIG_USB_GPIO_VBUS work with another boards. However, that stuff can be great for programming input.