Active Topics
-
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 12 hrs, 32 mins ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 1 day, 9 hrs ago - more...
| The Following 3 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
2010-05-08
, 15:47
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#802
|
i2cset and other are here.
| The Following 5 Users Say Thank You to egoshin For This Useful Post: | ||
|
|
2010-05-08
, 15:59
|
|
Posts: 82 |
Thanked: 214 times |
Joined on Jan 2010
@ Cape town
|
#803
|
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?
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?
| The Following 3 Users Say Thank You to cb22 For This Useful Post: | ||
|
|
2010-05-08
, 16:35
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#804
|
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).
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).
| The Following 3 Users Say Thank You to egoshin For This Useful Post: | ||
 |
|
2010-05-08
, 19:32
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#805
|
Originally Posted by egoshin
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.
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).
| The Following 4 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2010-05-08
, 22:07
|
|
Posts: 306 |
Thanked: 566 times |
Joined on Jan 2010
@ Romania
|
#806
|
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
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
Last edited by blue_led; 2010-05-08 at 22:23.
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
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
Last edited by blue_led; 2010-05-08 at 22:23.
| The Following 3 Users Say Thank You to blue_led For This Useful Post: | ||
 |
|
2010-05-09
, 00:40
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#807
|
Originally Posted by joerg_rw
Exactly. And btw, yet another reason for not touching the twl3040 at all =) .
Well, in this thread there's not really anything that messes with TWL4030, except special patched kernels ;-).
| The Following User Says Thank You to javispedro For This Useful Post: | ||
|
|
2010-05-09
, 06:24
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#808
|
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.
Last edited by egoshin; 2010-05-09 at 07:56.
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.
Last edited by egoshin; 2010-05-09 at 07:56.
| The Following 46 Users Say Thank You to egoshin For This Useful Post: | ||
ajax1, anaskr, andree, attila77, b-man, Bec, bunanson, cb22, clasificado, daperl, Dollyknot, EugeneS, frals, freemangordon, fw190, GameboyRMH, gunni, Hmoobwarrior, javispedro, jkq, joerg_rw, lemmyslender, maguitodelrock, Marshall Banana, maxximuscool, mikec, MohammadAG, morusaka, MrGrim, mveplus, mwrf, OVK, Patola, pH5, qole, S0urcerr0r, shapeshifter, sjgadsby, skorbut, SpeedEvil, stlpaul, Stskeeps, thecursedfly, tomaszf, v13 | ||
|
|
2010-05-09
, 09:19
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#809
|
Originally Posted by egoshin
Egoshin,
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.
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.
I like to ask you for a few favours:
- 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. - 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)
- 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!
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
Last edited by joerg_rw; 2010-05-09 at 15:29.
| The Following 17 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2010-05-09
, 18:15
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#810
|
Originally Posted by joerg_rw
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)
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.
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)
[*]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 &'
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
| The Following 7 Users Say Thank You to egoshin For This Useful Post: | ||
 |
| Tags |
| awesomeness in the works, boulevard of broken deals, host, i am the dealbreaker, inspector gadget lies, mobidapter is a scam, nokia fanbois, otg, over 9000, usb, usbcontrol |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 18:37.
I'll create a .tgz once I have a nice scriptie, to contain the binaries
Last edited by joerg_rw; 2010-05-08 at 14:55.