Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 3 days, 21 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 4 days, 17 hrs ago - more...
| The Following 2 Users Say Thank You to egoshin For This Useful Post: | ||
 |
|
2010-05-08
, 04:40
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#792
|
I think that 3.5V are the minimum voltage to allow system bootup. But it's quite outside of normal USB specs afaik. Also the TWL4030 without capacitor will probably not perform up to anything near the 200mA which bq24150 can deliver at a proper 5.0Volt to VBUS supply.
Nevertheless your results for ENUM etc are really exciting, could you try and use a selfpowered USB hub for your tests? I'd expect it should reply properly to any data sent from N900, even when the VBUS from N900 is as low as 3.5V
Nevertheless your results for ENUM etc are really exciting, could you try and use a selfpowered USB hub for your tests? I'd expect it should reply properly to any data sent from N900, even when the VBUS from N900 is as low as 3.5V
| The Following 2 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2010-05-08
, 04:50
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#793
|
Originally Posted by egoshin
you miss the point, sorry I was a little fuzzy. When I say 'charger_detect' I mean the content of /sys/devices/platform/musb_hdrc/charger. Repeated reading didn't change the fact it was stuck at '1' while I had removed the D+/- short. It stays at '1' until you remove VBUS voltage
It is a pure wish of BME and we are not sure then it reads file '.../charger'
charger_detect is called by reading file /sys/devices/platform/musb_hdrc/charger and it seems that BME reads it after it gets signal about VBUS UP.
| The Following 2 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2010-05-08
, 05:11
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#794
|
Originally Posted by joerg_rw
What do you think - Is a self powered disk suitable for this?
Nevertheless your results for ENUM etc are really exciting, could you try and use a selfpowered USB hub for your tests? I'd expect it should reply properly to any data sent from N900, even when the VBUS from N900 is as low as 3.5V
Or, alternatively - is any selfpowered USB hub sutable (I need to buy one)?
| The Following User Says Thank You to egoshin For This Useful Post: | ||
|
|
2010-05-08
, 05:54
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#795
|
Originally Posted by egoshin
Disk -> probably, though you should check (isolate or cut the V+ VBUS wire (red)) and connect to any normal working host.
What do you think - Is a self powered disk suitable for this?
Or, alternatively - is any selfpowered USB hub sutable (I need to buy one)?
selfpowered hub, quite sure will work. Most don't care about upstream VBUS aiui. Speedevil should know better details.
On a different topic: To me it seems like we are using the http://mxr.maemo.org/fremantle/sourc...usb/omap2430.c for N900?
In there are a number of *very* interesting details, e.g
209 #ifdef CONFIG_USB_MUSB_HDRC_HCD
210 case MUSB_HOST:
are our kernels compiled with CONFIG_USB_MUSB_HDRC_HCD ?
and
155 static void omap_set_vbus(struct musb *musb, int is_on)
156 {
157 u8 devctl;
158 /* HDRC controls CPEN, but beware current surges during device
This clearly refers to CPEN ChargePumpENable of any PHY chip. Won't work, as we need to talk to bme instead
even
151 static void omap_vbus_power(struct musb *musb, int is_on, int sleeping)
152 {
153 }
AIUI here we need to kick on bq24150 boostmode, by whatever means
272 if (is_host_enabled(musb))
273 musb->board_set_vbus = omap_set_vbus;
also interesting the lines
418 /* Recover OTG control */
419 r = musb_ulpi_readb(musb->mregs, ISP1704_OTG_CTRL);
...426
containing ISP1704 references. See e.g. http://mxr.maemo.org/fremantle/ident?i=ISP1704_OTG_CTRL
Last edited by joerg_rw; 2010-05-08 at 06:30.
| The Following 3 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2010-05-08
, 06:51
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#796
|
Originally Posted by joerg_rw
OK.
Disk -> probably, though you should check (isolate or cut the V+ VBUS wire (red)) and connect to any normal working host.
selfpowered hub, quite sure will work. Most don't care about upstream VBUS aiui. Speedevil should know better details.
On a different topic: To me it seems like we are using the http://mxr.maemo.org/fremantle/sourc...usb/omap2430.c for N900?
In there are a number of *very* interesting details, e.g
209 #ifdef CONFIG_USB_MUSB_HDRC_HCD
210 case MUSB_HOST:
are our kernels compiled with CONFIG_USB_MUSB_HDRC_HCD ?
and
155 static void omap_set_vbus(struct musb *musb, int is_on)
156 {
157 u8 devctl;
158 /* HDRC controls CPEN, but beware current surges during device
This clearly refers to CPEN ChargePumpENable of any PHY chip. Won't work, as we need to talk to bme instead
EDIT: DP/DM/ID but not VBUS.
Moreover, the special control of VBUS charge pump setup or VBUS PULLUP/PULLDOWN are absent in OTG driver, even for TWL4030. It only monitors a VBUS level.
EDIT2: driver of ISP1301 does VBUS setup but it is not even compiled.
even
151 static void omap_vbus_power(struct musb *musb, int is_on, int sleeping)
152 {
153 }
...
272 if (is_host_enabled(musb))
273 musb->board_set_vbus = omap_set_vbus;
the function itself is empty/nullfunct (152,153)
However, thank you for clue.
also interesting the lines
418 /* Recover OTG control */
419 r = musb_ulpi_readb(musb->mregs, ISP1704_OTG_CTRL);
...426
containing ISP1704 references. See e.g. http://mxr.maemo.org/fremantle/ident?i=ISP1704_OTG_CTRL
And this place puzzles me a lot - the next line is
r |= ISP1704_OTG_CTRL_IDPULLUP | ISP1704_OTG_CTRL_DP_PULLDOWN;
In this line ISP1704_OTG_CTRL_IDPULLUP setup means the restore of ID ground monitoring --> restore OTG. But OTG should have ISP1704_OTG_CTRL_DP_PULLDOWN bit as ZERO in accordance with Table 14,
Operating states and their corresponding resistor settings of 1704 description.
Last edited by egoshin; 2010-05-08 at 07:05.
| The Following 2 Users Say Thank You to egoshin For This Useful Post: | ||
 |
|
2010-05-08
, 10:03
|
|
Posts: 70 |
Thanked: 410 times |
Joined on Sep 2009
@ Fife, Scotland.
|
#797
|
3.5V is a 'odd' state of the USB bus - there is no guarantee that stuff will work - even if the power supply stays at 3.5V under load.
If it did - then there is a chance that some USB devices may work - but most will not. The USB voltage is 4.5 (IIRC) minimum.
There are a couple of issues with regards to using USB devices or hubs from an unpowered host.
The most obvious is there is no power - selfpowered stuff will not work.
Second is that even powered devices sometimes look at usb to see if there is a host there that they should negotiate with.
One printer and one hub I have will not talk to an unpowered host (lexmark printer, and Belkin Tetrahub).
(unpowered may or may not behave as 3.5V does).
99% of cheap external powered hubs will not care.
There is a very simple way to test this.
Get a standard USB cable.
Chop it open.
Cut the red wire. (being careful not to short it, or it will explode! (or not - however - insulating the cut ends is a good plan))
Try plugging stuff into a normal host.
(try with a few cables you don't care about first, if you're unsure.)
If it did - then there is a chance that some USB devices may work - but most will not. The USB voltage is 4.5 (IIRC) minimum.
There are a couple of issues with regards to using USB devices or hubs from an unpowered host.
The most obvious is there is no power - selfpowered stuff will not work.
Second is that even powered devices sometimes look at usb to see if there is a host there that they should negotiate with.
One printer and one hub I have will not talk to an unpowered host (lexmark printer, and Belkin Tetrahub).
(unpowered may or may not behave as 3.5V does).
99% of cheap external powered hubs will not care.
There is a very simple way to test this.
Get a standard USB cable.
Chop it open.
Cut the red wire. (being careful not to short it, or it will explode! (or not - however - insulating the cut ends is a good plan))
Try plugging stuff into a normal host.
(try with a few cables you don't care about first, if you're unsure.)
| The Following 6 Users Say Thank You to SpeedEvil For This Useful Post: | ||
|
|
2010-05-08
, 14:11
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#798
|
"infinite" VBUS
(explanation for those entering this endless thread here: the cmdline pasted below will provide a continuous 5V@200mA to the USB receptacle of your N900, thus meeting one of the prerequisites to connect USB devices like mice, compass, kbd... you name it):
If nothhing else, at least enjoy your USB-mugwarmer powered from N900 now :-P
cheers
jOERG
(hitting 'Thanks' highly appreciated )
[edit] 'start bme' is your friend ;-)
[edit2] if you're not in a hurry - a decent scriptie will follow in a short while
[disclaimer] messing around with i2cset is potentially hazardous to your device. The above commandline is considered safe (though without any warranty implied or fart, as usual) - but please watch out for typos, and do NOT experiment with i2cset parameters as long as you don't know exactly what you're doing.
Result (intermediate): http://talk.maemo.org/showthread.php...247#post650247
Last edited by joerg_rw; 2010-05-11 at 03:19. Reason: disclaimer
(explanation for those entering this endless thread here: the cmdline pasted below will provide a continuous 5V@200mA to the USB receptacle of your N900, thus meeting one of the prerequisites to connect USB devices like mice, compass, kbd... you name it):
Code:
Nokia-N900-02-8:/home/user/i2c# stop bme; sleep 3; ./i2cset -y -m 0x07 2 0x6b 0x01 0x05; while true; do sleep 28; ./i2cset -y -m 0x80 2 0x6b 0x00 0x80; done
cheers
jOERG
(hitting 'Thanks' highly appreciated
)[edit] 'start bme' is your friend ;-)
[edit2] if you're not in a hurry - a decent scriptie will follow in a short while
[disclaimer] messing around with i2cset is potentially hazardous to your device. The above commandline is considered safe (though without any warranty implied or fart, as usual) - but please watch out for typos, and do NOT experiment with i2cset parameters as long as you don't know exactly what you're doing.
Result (intermediate): http://talk.maemo.org/showthread.php...247#post650247
Last edited by joerg_rw; 2010-05-11 at 03:19. Reason: disclaimer
| The Following 31 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2010-05-08
, 14:34
|
|
Posts: 82 |
Thanked: 214 times |
Joined on Jan 2010
@ Cape town
|
#799
|
Joerg,
What version of i2cset are you using? The version I have doesn't seem to know anything about the -m flag... It's the one from i2ctools in Debian.
What version of i2cset are you using? The version I have doesn't seem to know anything about the -m flag... It's the one from i2ctools in Debian.
| The Following User Says Thank You to cb22 For This Useful Post: | ||
 |
|
2010-05-08
, 14:45
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#800
|
Originally Posted by SpeedEvil
Anecdotal note: I think that the N900 itself its one gadget that will refuse to negotiate with a host without vbus.
There is a very simple way to test this.
Get a standard USB cable.
Chop it open.
Cut the red wire. (being careful not to short it, or it will explode! (or not - however - insulating the cut ends is a good plan))
Try plugging stuff into a normal host.
| The Following 3 Users Say Thank You to javispedro 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
»
| Thread Tools | |
|
All times are GMT. The time now is 22:29.
Are you sure that host w/out high-performance charge capability requires VBUS=5V? The reason for my question is simple - the ARM CPU USB DEVCTL has a couple of voltage levels and so called "AValid" or A-state Valid is right about 3.5V.