OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Usb Power Issues
louigi600
post May 1 2008, 02:35 AM
Post #1





Group: Members
Posts: 474
Joined: 21-May 06
Member No.: 9,928



Although I've made hardware changes to my C1k (to be able to power upto 500mA to the usb port and I've terted it with pdaxrom to be effective) debian is refusing to power up wireless device dew to excessive power consumtion (probabbly calculated on USB OTG power sepecifications).

Anyone know how to correct the behaviour fo my 500mA capable hardware ?

Foud this workaroud:
http://www.oesf.org/forum/index.php?showto...&hl=pegasus
which is not that straightforwars to apply:
I mean lsusb shows bus address to be 1 and not 1-2.
Althought dmesg shows some messages about 1-2 ... I find it difficult to correlete what lsusb shows and the content of the /sys/bus/usb subtree.
lsusb shows bus 1 and device 8 ... I guess that bus1:1 becomes 1-1 and 1:8 becomes 1-2 a bit like scsi devices ?
anyway with some doubts whether it's the right thing to di I dot the zd1211 to power up correctly.

Anyway I would still prefer instrucnting that my hardware supports normal USB 500mA specification.
Go to the top of the page
 
+Quote Post
pelrun
post May 15 2008, 12:45 AM
Post #2





Group: Members
Posts: 369
Joined: 6-September 04
From: Brisbane, Australia
Member No.: 4,488



I agree that the bConfigurationValue trick isn't really appropriate for more than initial debugging. There are a couple of other options:

1) Recompile the kernel with the new current limit, or
2) Add udev rules for each device that exceeds the kernel power limit.

The kernel limit is set in spitz.c, and by default is at 150mA. Fixing this is the best all-round option, except that compiling a Z kernel is a pain.

The udev option is the proper way of applying the bConfigurationValue trick, and only has to be done once for each device. You want to make a new file called 99-usbpower.rules or similar in /etc/udev/rules.d, containing rules like this (note the =='s and ='s):

CODE
SUBSYSTEM=="usb", ATTR{idVendor}=="vendorid", ATTR{idProduct}=="productid", ATTR{bConfigurationValue}=1

Then do a "udevcontrol reload_rules". The rule will forcibly select device configuration 1 whenever the usb device with the specified vendor and product id is inserted.

I've been using the udev option for my Huawei 3G modem. It's too bad I didn't use a small enough resistor when doing the usb power mod, because I still can't get enough current - it's enough to initialise the device now, but not enough to turn the transmitter on! I'm going to have to pull my Z apart again *shudder*
Go to the top of the page
 
+Quote Post
radiochickenwax
post Jul 13 2008, 09:56 PM
Post #3





Group: Members
Posts: 158
Joined: 21-November 04
Member No.: 5,548



QUOTE(pelrun @ May 15 2008, 08:45 AM) *
The kernel limit is set in spitz.c, and by default is at 150mA. Fixing this is the best all-round option, except that compiling a Z kernel is a pain.


I'm guessing this is line 466? What's a reasonable number to put here? I'm thinking 500mA is too much... gonna go with 250 for now

*edit* rebuilt kernel with this change, but waiting for native compile of FFMPEG to finish (or fail) before I reflash



QUOTE(pelrun @ May 15 2008, 08:45 AM) *
too bad I didn't use a small enough resistor when doing the usb power mod, because I still can't get enough current - it's enough to initialise the device now, but not enough to turn the transmitter on! I'm going to have to pull my Z apart again *shudder*


Do you have any documentation (online) about your usb mod?
Go to the top of the page
 
+Quote Post
pelrun
post Jul 14 2008, 10:41 PM
Post #4





Group: Members
Posts: 369
Joined: 6-September 04
From: Brisbane, Australia
Member No.: 4,488



There's no point in changing the kernel if you haven't done the power mod; the hardware will forcibly power off any USB device which tries to draw more than that. If a usb device is requesting more current than it actually draws then it's better to override it using a udev rule.

The power mod involves changing the resistor which sets the overcurrent protection limit (currently at 150mA) - the info is buried somewhere in albertr's internal bluetooth/wifi mod thread.
Go to the top of the page
 
+Quote Post
radiochickenwax
post Jul 15 2008, 12:41 AM
Post #5





Group: Members
Posts: 158
Joined: 21-November 04
Member No.: 5,548



QUOTE(pelrun @ Jul 15 2008, 06:41 AM) *
There's no point in changing the kernel if you haven't done the power mod;


(haven't done power mod)
whoops.. oh well, I'm on a rebuild kick without a roadmap, and this is what happens.

QUOTE(pelrun @ Jul 15 2008, 06:41 AM) *
The power mod involves changing the resistor which sets the overcurrent protection limit (currently at 150mA) - the info is buried somewhere in albertr's internal bluetooth/wifi mod thread.


http://www.oesf.org/forum/index.php?showto...3562&st=360

Wow! (Can't believe I missed so much of this)
That's a pretty long thread. (365 posts) You didn't do the CF/usb mod I take it, just the OTG mod?
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th September 2014 - 10:00 PM