Thread: N900 will not allow USB OTG!
View Single Post
egoshin is offline egoshin
2010-05-09 , 18:15
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#810
Originally Posted by joerg_rw View Post
I like to ask you for a few favours: [LIST=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.
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.


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)
Sure, I will do it today at night or tomorrow morning. Good idea!

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

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

The Following 7 Users Say Thank You to egoshin For This Useful Post: