Has anyone tried this?
Any specific adapter recommended?
Since there is no UHCI support compiled in the kernel (and nobody got it working yet), you only could succeed with an USB Highspeed
(480 MBit/s - which then uses EHCI) adapter. I'm not sure if any slower USB fullspeed (12MBit/s) devices are around, which would not
work at all (because they need UHCI).
For example a FTDI FT245B based adapter should work, if you get the kernel module
compiled and loaded without errors (it's under Device drivers -> USB support -> USB serial converters support -> USB FTDI single port ….)
Yes it's under serial even if it's a 8-bit port parallel converter.
[edit]
Oh, an other idea would be to connect to the internal I2C bus of the MBWE (disadvantage: you would have to open it - but
owners of soldering irons won't care, would they ?) which can be easily found on the RTC chip M41T0 (also look at http://mockmoon-cybernetics.ch/computer/wdh1nc10000/ for photos of the mainboard. The RTC chip has been marked :-) )
I believe the I2C bus is 3.3V though…
Blip
Thank you very much.
I ordered this one http://www.delock.com/produkte/gruppen/USB+Adapter/Delock_USB_11_parallel_adapter_61330.html
and I am going to try today.
I'm not sure which chip set is in it but I hope I get it working.
I was hoping that there would be built in support for the parallel port in linux.
How would I go about compiling the kernel module? Could there be something ready in optware? e.g. "libieee1284 - 0.2.11-1 - libieee1284 is a cross-platform library for parallel port access"
If I go with your second idea (soldering), would I still need to go through drivers and stuff?
Hi,
I'm sorry to say that the device you ordered most likely won't work, since the website states
that it is an USB 1.1 device - which needs UHCI support.
I dont know the details of libieee1284, but ieee1284 only defines bidirectional communication with parallel port devices.
It's well possible that it relies itself on device drivers, but I dont know.
Optware has lots of additional software ready, but there are no kernel modules as far as I know. If its only for the
FTDI kernel module, you can find it compiled on my MyBook page mentioned above. I only tried it with serial converters,
but the drivers documentation says that it can handle FT245 (parallel …) as well.
Blip
bleep!
Ok this is where i'm at:
I plug it in and I get:
MyBookWorld user.notice [6844]: … no modules for USB product fe6/811e/101
What do you mean by "If its only for the
FTDI kernel module, you can find it compiled on my MyBook page mentioned above."
This page? http://zeroone.homeunix.net/~blip/comp/mbwe/
It does not seem to contain information about ftdi.
Is there anything I can try?
I there a way to send and receive raw data to the usb device? I only need to read some raw data from the parallel port.
Also in optware I find these:
libftdi - 0.7-2 - Library to access the FTDI (usb2serial) chip in userspace via libusb
Is this any good?
Thanks again
Ok,
I found your ftdi_1.0.0_arm.ipk and I installed it. Is there anything I can try now?
I still get the no modules for USB product fe6/811e/101 message although the modules are loaded.
Is there a way I can force the module to load the drivers for the device? e.g. to manually add "USB product fe6/811e/101 " in the module.
If you don't mind spending a little of your time, I could also send you an ip to connect through telnet.
I also tried another cable : USB Prolific Technology Inc. IEEE-1284 Controller
but I still get the following in the log.
03/10 22:37:13 MyBookWorld user.notice [26188]: … no modules for USB product 67b/2305/202
03/10 22:37:13 MyBookWorld user.notice [26173]: … no modules for USB Prolific Technology Inc. IEEE-1284 Controller
I waste some time with compiling UHCI kernel modules:
http://mybookworld.wikidot.com/forum/t-207396/
… and give up.
I think, we need a self-compiled kernel with UHCI support.
But with the terrible upgrade procedure of White Book (no flash rom with sftp upgrade over lan) nobody want to disassamble the hard drive many times for testing buggy kernels.
Now I reanimated my good old NSLU2 with great UHCI support => additional 30 kWh/year :-(
I think about get the 5V/500mA Power for NSLU2 direct from the USB Port of Whitebook and avoid the second power supply plug of NSLU2.
thank you thomas.
from what you and bleep are saying, I believe it's best if I give up. I am just starting to learn linux, and I am lost in all this compiling, modules and gcc stuff.
Thanks for your input anyway.
@tomas:
I do not give up yet. I've ordered MAX3232CPE level converters so I'll have a serial console soon. Then I'll try again. Since our last mail, I've bricked the MBWE two more times so I've decided that I really need a serial console now.
I think I found something out about the assembly of the raid devices. As you said, I cant be
done in the initial ramdisk, because there is no initial ramdisk. But I've read something that
the kernel indeed can assemble raid devices itself - to this might be the way WD is doing it.
@andrew:
Thank you for your trust in offering me a login on your MBWE, butI really have almost no
spare time even for my own projects, so this is no option, sorry.
At least I found something out about your prolific adapter. On the site [http://www.qbik.ch]
it is listed as supported for the usblp device driver, but write only (no reading).
(Hint: on the site, search for the product id which is 2305).
On would have to get the datasheet of this converter chip to make sure it can do EHCI
and does not need UHCI (which we dont have on the MBWE).
But what I allready have guessed and you have confirmed now: You are a Linux beginner.
This is a really difficult project to start with. Did you allready succeed in accessing your home
automation project with a normal Linux PC? This is where you should start with. Once you
know how to access devices in general in Linux, you can continue to get it running on the
MBWE (in the meantime I might have got UHCI running, but to be honest I hardly believe in this myself anymore).
On the other hand, once we had UHCI running, the IO-Warrior chips from [http://www.codemercs.de] could be a cool thing for your project.
Bleep
Thanks bleep,
although I am a beginner in linux, I'm quite familiar with programming languages so I am confident I will manage to make a linux program for my home automation project. All I need is OS hardware support. (I've already coded this project for a windows PC, but I want it assigned to the WD since it's always running.)
BTW, thanks for the link. I'm going to research that site, although I mostly need the port for reading :-(
BLEEP!!!!!!!!!!!!!!!
I've made progress because of your hints!
I installed usblp
then I run "mount -t usbfs none /proc/bus/usb" and now lsusb reports the following:
Bus 001 Device 002: ID 067b:2305 Prolific Technology, Inc. PL2305 Parallel Port
Bus 001 Device 001: ID 0000:0000
Now I can do the following:
echo sometext>/dev/lp0
and I believe it does send the data.
Now if I run cat /dev/lp0 will it return data? I must check
Thanks again, you and tomas have helped very much
:EDIT
A bit more information from /proc/bus/usb/devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24.4 ehci_hcd
S: Product=OXNAS EHCI Host Controller
S: SerialNumber=usb
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=067b ProdID=2305 Rev= 2.02
S: Manufacturer=Prolific Technology Inc.
S: Product=IEEE-1284 Controller
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=07(print) Sub=01 Prot=01 Driver=usblp
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 0 Alt= 1 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=usblp
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 0 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=usblp
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=03(Int.) MxPS= 4 Ivl=1ms
so bleep the difficult part is over?
Now I just need to figure out how to read raw data from /dev/usb/lp0
Could someone that has the toolchain setup please compile this for me?
http://sourceforge.net/projects/parashell/files/parashell/2.2/parashell-2.2.zip/download
It is a simple application to read and write to the parallel port
Thanks
Wow, you have a running usblp kernel modul? From which feed you get the kernel-module-usblp*.ipk ?
I think, that your Spd=12 and Ver= 1.00 is a sign for UHCI/OHCI !!
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12
D: Ver= 1.00see http://www.linux-usb.org/USB-guide/c607.html#AEN609
"Ver indicates which USB specification version the device claims to meet"
wonder…
If you have a good old usb mouse (e.g. logitech) please plug in Mybook and give me your output of
cat /proc/bus/usb/devices
and
lsmod
thanks
tomas,
I only have a usb Microsoft optical basic. Do you want me to try?
I got usblp from this site http://members.aon.at/berwinter/mbwe/mbwe_en.html
BTW, do you know what the easiest way is to read and write bytes at /dev/usb/lp0????
yes, use any OHCI mouse and send your /proc/bus/usb/devices
> do you know what the easiest way is to read and write bytes at /dev/usb/lp0
you wrote
> echo sometext>/dev/lp0
> and I believe it does send the data.
Does'nt it work??
@bleep
andrew_sh found another german speaking kernel module freak for white books:
http://members.aon.at/berwinter/mbwe/mbwe_de.html
very interesting…
Here you go:
~ # cat /proc/bus/usb/devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24.4 ehci_hcd
S: Product=OXNAS EHCI Host Controller
S: SerialNumber=usb
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
~ # lsmod
Module Size Used by Tainted: P
nfsd 101460 0
exportfs 3840 1 nfsd
lockd 66008 1 nfsd
nfs_acl 3232 1 nfsd
sunrpc 175292 5 nfsd,lockd,nfs_acl
wixevent 5800 0
rtc_ds1307 5024 0
rtc_core 14840 1 rtc_ds1307
i2c_oxnas_bitbash 2400 0
i2c_algo_bit 5828 1 i2c_oxnas_bitbash
i2c_core 19216 3 rtc_ds1307,i2c_oxnas_bitbash,i2c_algo_bit
usblp 12064 0
ftdi_sio 33864 0
usbserial 27368 1 ftdi_sio
ufsd 445668 0
vfat 10240 0
nls_iso8859_1 3904 0
nls_cp437 5568 0
ehci_hcd 28972 0
usb_storage 35936 0
usbcore 120212 6 usblp,ftdi_sio,usbserial,ehci_hcd,usb_storage
user_recovery_button 3160 0
power_button 3388 0
thermAndFan 7140 0
gmac 26352 0
mii 6144 1 gmac
oxnas_wd810_leds 7496 0
whith echo sometext>/dev/lp0 i'm able to send a string. I would like to be able to read a single byte from /dev/usb/lp0.
Thanks
@tomas:
Looks like the mouse does not work. I would have been very surprised if it had.
I dont know why the PL2305 works - its still not clear to me whether it does 480mbit/s or 12mbit/s.
The prolific homepage reads as if it would support HighSpeed - but the /proc/bus/usb/devices
really look like 12mbit/s. I am confused.
@andrew:
Yes, it is a big step forward if the Prolific Converter is recognised by the usblp driver.
However, /dev/lp was not made to read the data lines from the port, only
to write to them. Reading is only possible for the centronics control lines (BUSY, PAPEROUT
and another one I can't remember just right now). We need /dev/parport for such things, but
it seems that there is no driver at all that supports mapping parallel ports via USB to /dev/parport.
The FTDI driver I mentioned maps it to /dev/ttyUSB0 but also seems to support reading.
I wanted to crosscompile the parashell for you, but then realised that it won't work.
The Linux version also does not support reading, and I almost vomitted when I saw that it uses
outb() calls to the io-address 0x378 to access the port. This is how you accessed hardware in old
the medieval (i.e. MSDOS.). It is not portable at all and will in no case work with USB converters!
How many bits do you have to read at once? Do you really need 8bits? How fast do you have to
read them (if its more than 100 bytes/sec or the timing is relevant, then forget about usb converters). It would help me to give tipps if I knew what you want to read ;-)
How are your electronic skills?
Blip
Blip,
Thanks for your effort. I also did some research and realized that the script I gave you would not work. The project goes like this;
I want to hook the parallel port inputs to my security system, so the mbwe would send me push notifications on my iphone.
I had already achieved this on a windows pc, and had all information about the zones etc. I realize that if I use the status lines, I wont be able to have all this information, but it would still be great even if I had only 2 inputs. One for the alarm going off, and one to tell me when the alarm is armed/disarmed. So at least timing is not an issue, even one reading per second would be excellent.
My electronic skills are good (I could make a simple board), although I would like to keep it simple and tidy.
Ok, then I'm excited how the program works I sent you via PM.
I thought if you really need 8 input bits and timing does not matter, one also could use something like a 74151 multiplexer. But if 2 bits were ok, I am confident that we get this working by reading the status lines.
Blip
bleep,
i've just got to it. Thanks for the utility you sent me. Looking through your source code I believe it won't work because it is using /dev/lp0, but in my case usblp has installed it as /dev/usb/lp0. I'm still going to try it and I am also setting up a linux vm so I can recompile your script.
I'll inform you when I get somewhere
Thanks again
Ah, sorry, I just assumed it would be /dev/lp0. Would be even better if one could gibe this with the command line.
Meanwhile, you could make a symlink with "ln -s /dev/usb/lp0 /dev/lp0" (thats quicker than setting up a vm ;-)
bleep,
it might have worked!
I got the following output
BUSY = HI
POUT = HI
ERR = HI
SEL = HI
and if I unplug the adapter I get
Error: can not open /dev/lp0
and when I plugged it in again I get
BUSY = HI
POUT = HI
ERR = LO
SEL = HI
with a 6sec pause
I'm going to try to ground some now!
EDIT:
It seems that ERR always goes LO after a while.
I'm trying to change the value of the pins but unfortunately they wont change. Maybe it uses some kind of internal handshaking before it can read the status pins :-(
I'm still trying
EDIT:
after I run the script or send data to the port with echo, after about 10sec ERR goes to LO.
After a reboot it goes back to HI.
Something else i've noticed is that when ERR = HI the script processes immediately, but when ERR turns to LO the script takes about 6sec to process.
Also, when ERR goes to LO I cannot echo anymore to the port (it just hangs there).
@bleep
a little bit offtopic
Peter Lemenkov actual working for updates of 2.6 kernel for our WhiteBook (OxSemi 810)
http://github.com/lemenkov/linux-2.6-oxnas/downloads
unfortunately there is a "Access Denied" to linux-2.6.24.4-oxnas810-WD-MyBookWorld-v1.00.16-GPL.patch … see my comment at the bottom
I found out that the WD 1.00.16 SDK contains a patch in kernel module ehci-hcd.c
#ifdef CONFIG_ARCH_OXNAS
#include "ehci-oxnas.c"
#define PLATFORM_DRIVER ehci_hcd_oxnas_driver
#else // CONFIG_ARCH_OXNAS
#ifdef CONFIG_PCI
#include "ehci-pci.c"
#define PCI_DRIVER ehci_pci_driver
#endif // CONFIG_PCIthis redirect the kernel probe from ehci-pci.c
static struct pci_driver ehci_pci_driver = {
.probe = usb_hcd_pci_probe,
.remove = usb_hcd_pci_remove,to function to ehci-oxnas.c:
static struct platform_driver ehci_hcd_oxnas_driver = {
.probe = ehci_hcd_oxnas_drv_probe,
.remove = ehci_hcd_oxnas_drv_remove,
};the functions ehci_hcd_oxnas_drv_probe and ehci_hcd_oxnas_drv_remove are defined in ehci-oxnas.c and if you insmod the ehci-hcd.kothe kernel knows the functions.
but here is the source of unpatched uhci-hcd.c:
static struct pci_driver uhci_pci_driver = {
...
.probe = usb_hcd_pci_probe,
.remove = usb_hcd_pci_remove,the function usb_hcd_pci_probe and usb_hcd_pci_remove are undefined and this generates the kernel error messages
~ # dmesg | tail
uhci_hcd: Unknown symbol usb_hcd_pci_probe
uhci_hcd: Unknown symbol usb_hcd_pci_removewe need a OXNAS patch for UHCI…
There is not a problem, that usblp.ko works with low speed USB. This kernel driver usblp.ko handels all USB access himself. Not access over uhci/ehci.
PS: Lemenkov also published code for Stage2 bootloader of WD MyBook
http://wiki.github.com/lemenkov/u-boot-oxnas/
and Stage1 bootloader
http://github.com/lemenkov/wd-mybook-bootloader
Why the semiconductor of OXE810 prevent users for downloadind datasheets / docs?
http://www.plxtech.com/products/consumer/oxe810se
In the general datasheet I found:
"1xUSB2.0 for added storage drives, 2xUSB1.1 for print server functionality"
Is the USB1.1 Port another pin?
I sort of have some success.
I can read the status lines but only once. After that I get ERR=LO and no more inputs are read. It seems that when you send data to the output, it causes ERR to go to LO
EDIT:
I MADE IT AT LAST
with your help of course
I had to modify the script so it runs in a loop. Otherwise when it closes the file and reopens it, the problem begins.
@andrew:
I'm glad you made it. But still, it's strange that it works only on the first open().
Maybe this has something to to with resetting the device?
Try to leave away the line "ioctl(fd, LPRESET);" and check if the behavior remains.
Doing the thing in a loop is indeed what you wanted, but lets make sure the code really work
(we dont want undetected burglars, do we ? ;-)
If you use the loop inside the C Programm, then of course you need to do you push mail with a call to
system() or similar.
@tomas:
Let me guess… you also could not find uhci-oxnas.c anywhere ?
The stuff of this Peter Lemenkov sound very interesting. Let's hope he releases information on
kernel updates one day. I'll have my serial console ready then ;-)
Blip
Bleep
I have already tried to comment out the ioctl(fd, LPRESET); which changed some readings, but still the readings wouldn't change (and you had a 6sec delay). I left your script intact and just added a while{} loop and works great. If I have your permission I can post the modified script. I'm not sure what you mean by "If you use the loop inside the C Programm, then of course you need to do you push mail with a call to system() or similar." I'm going to use apple's push notifications, not push mail.
Now I'm going to start programming!!!
EDIT:
a yes, now I get what you mean by the system() call. Yes I'm going to call a bash script i've already made that sends a text to the iphone's screen.
Hallo andrew_sh,
Can it be possible that PL2305 also without the usblp device driver is recognized by usb bus?
~ # cat /proc/bus/usb/devices
I: ........ Driver=noneThis is a really important question!
I saw that your usbcore connected with five kernel modules (usblp, ftdi_sio, usbserial, ehci_hcd, usb_storage)
The original WD White Book installation binds only two kernel modules (** ehci_hcd, usb_storage**)
You can check in four steps whether the PL2305 is invisible without usblp:
(1) disconnect the Prolific 2305 adapter
(2) now unbind all extra kernel modules
- rmmod usblp
- rmmod ftdi_sio
- rmmod usbserial
(3) after this connect the Prolific 2305 adapter to the usb port
(4) post us the output of this three commands
- cat /proc/bus/usb/devices
- lsmod
- dmesg | tail
Thank you for help!
Don't forget to restart the kernel modules…
Edit: If the PL2305 again runs fine please post the output of : dmesg | grep -i USB
Ok, I removed the modules, replug usb and I get:
~ # cat /proc/bus/usb/devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24.4 ehci_hcd
S: Product=OXNAS EHCI Host Controller
S: SerialNumber=usb
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=067b ProdID=2305 Rev= 2.02
S: Manufacturer=Prolific Technology Inc.
S: Product=IEEE-1284 Controller
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=07(print) Sub=01 Prot=01 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 0 Alt= 1 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 0 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=03(Int.) MxPS= 4 Ivl=1ms
~ # lsmod
Module Size Used by Tainted: P
nfsd 101460 0
exportfs 3840 1 nfsd
lockd 66008 1 nfsd
nfs_acl 3232 1 nfsd
sunrpc 175292 5 nfsd,lockd,nfs_acl
wixevent 5800 0
rtc_ds1307 5024 0
rtc_core 14840 1 rtc_ds1307
i2c_oxnas_bitbash 2400 0
i2c_algo_bit 5828 1 i2c_oxnas_bitbash
i2c_core 19216 3 rtc_ds1307,i2c_oxnas_bitbash,i2c_algo_bit
ufsd 445668 0
vfat 10240 0
nls_iso8859_1 3904 0
nls_cp437 5568 0
ehci_hcd 28972 0
usb_storage 35936 0
usbcore 120212 3 ehci_hcd,usb_storage
user_recovery_button 3160 0
power_button 3388 0
thermAndFan 7140 0
gmac 26352 0
mii 6144 1 gmac
oxnas_wd810_leds 7496 0
~ # dmesg | tail
usblp0:failed reading printer status (-71)
usblp0:failed reading printer status (-19)
usblp0:failed reading printer status (-19)
usblp0: removed
usbcore: deregistering interface driver usblp
usb 1-1: new full speed USB device using oxnas-ehci and address 3
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: USB disconnect, address 3
usb 1-1: new full speed USB device using oxnas-ehci and address 4
usb 1-1: configuration #1 chosen from 1 choice
~ #
(I replugged it twice)
and the usb does not work now without usblp. I get
~ # echo sdfds>/dev/usb/lp0
-sh: cannot create /dev/usb/lp0: No such device
Hope this helps you. Tell me what else you need
thanks for this good work
I see, that the Prolific 2305 registered in usb bus without extra kernel driver.
The 2305 makes a handshake over high speed EHCI:
usb 1-1: new full speed USB device using oxnas-ehci and address 4Your luck but this is a great difference to our non-working UHCI USB devices ;-)
Hi Andrew,
when looking again at the C-source code I've sent you, I discovered a small but important bug.
The compare with the masked value to find out which Pin is Low or High is done wrong (compared agains either
0 or 1 instead of comparing against the mask value). Look again here for the corrected version:
parport.html
Also note that now I'm inverting the BUSY signal. All this occured to me when I compared the code to some
code I wrote later to access the parport via /dev/parport0 (which we cant use here).
@tomas:
Ok now we know that the device is also listed in /proc/bus/usb/devices even though not claimed by and driver.
Does this mean your plan of writing an own driver for the AVR project is rather going to work or rather not ?
Blip
@bleep, tomas
I have to say that the device was not immediately listed in /proc/bus/usb/devices
I had to run mount -t usbfs none /proc/bus/usb
@bleep
Thnanks bleep, i'll have a look, but your code works fine - i've been using it 2 days already (at least the POUT and SEL inputs)!!!!!
Also, do you know if there is an event for when the data changes? I use a pause in each cycle in the script for 0.2sec but still the cpu goes up to 15-20%
some words to our usb problem:
The whitebook don't use a pci bus to access to the usb devices because the usb ports are internal ports of chip OxSemi 810).
I wrote above about the oxnas hack for accessing to the usb ports:
Oxsemi exchanged the Linux Kernel 2.6.24 PCI device driver (ehci-pci.c) for the own ehci-oxnas.c. This proprietary driver don't access the usb ports over pci bus. The programming of usb registers take place with internal registers of OXE800DSE
// Force the high speed clock to be generated all the time, via serial
// programming of the USB HS PHY
writel((2UL << SYS_CTRL_USBHSPHY_TEST_ADD) |
(0xe0UL << SYS_CTRL_USBHSPHY_TEST_DIN), SYS_CTRL_USBHSPHY_CTRL);you find the corresponding OXE810SE registers here
/include/asm-arm/arch-oxnas/hardware.h
/* System Control registers */
#define SYS_CTRL_USBHSPHY_CTRL (SYS_CONTROL_BASE + 0x84)in dmesg you see the result of initialization process of usbcore:
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
now let's see to the USB Device Filesystem
~ # cat /proc/bus/usb/devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24.4 ehci_hcd
S: Product=OXNAS EHCI Host Controller
S: SerialNumber=usb
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256mssee Linux Kernel Documentation http://www.mjmwired.net/kernel/Documentation/usb/proc_usb_info.txt
or a good german description: http://www.fibel.org/linux/lfo-0.6.0/node451.html
What's the meaning of this?
We can't write a user space driver for UHCI. We need a hardware driver for OXNAS-UHCI. This hardware driver links the UHCI device in /proc/bus/usb/devices and tags the device with "Driver=(none)".
Now we can speak with our UHCI device with a generic driver like libusb our use a customised driver (like usblp).
I found out that Iomega Home Media Network Hard Drive use the same processor OXE800DSE: http://www.wepcracking.com/content/view/30720/75/
But if I look in the dmesg I see the identical message like our WhiteBook
http://iomega.nas-central.org/wiki/Home_Media_Stock_Configuration
10 Dec 2004 USB 2.0 'Enhanced' Host Controller (EHCI) Driver@e7000000 Device ID register 42fa05
oxnas-ehci oxnas-ehci.0: OXNAS EHCI Host Controller
oxnas-ehci oxnas-ehci.0: new USB bus registered, assigned bus number 1
oxnas-ehci oxnas-ehci.0: irq 7, io mem 0x00000000
oxnas-ehci oxnas-ehci.0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detectedWhat this: 3 ports detected ??
The Semiconductor writes:: http://www.plxtech.com/products/consumer/oxe810se
"USB Multi-Port Host Controller
The USB can be used to connect to external USB HDDs via the high-speed 480-Mbps port A, or to other peripherals, such as printers or USB memory via the full-speed 12-Mbps ports B and C as well as port A."
I think, that the oxe810se give us UHCI only over second and third usb ports. But this ports are not wired in Mybook and Iomega Home Media Network.
There is no reason for the One_USB_Port_SDK to give us a UHCI driver.
PS: I'm not a expert to explain how Profilec 12Mps woks over EHCI. Crucial is the kernel output
"usb 1-1: new full speed USB device using oxnas-ehci"
It seems likely that EHCI can work with low/full-speed fine:
linux kernel doc says
http://www.mjmwired.net/kernel/Documentation/usb/ehci.txt
4 USB 2.0-capable host controller hardware. The USB 2.0 standard is
5 compatible with the USB 1.1 standard. It defines three transfer speeds:
6
7 - "High Speed" 480 Mbit/sec (60 MByte/sec)
8 - "Full Speed" 12 Mbit/sec (1.5 MByte/sec)
9 - "Low Speed" 1.5 Mbit/sec
10
11 USB 1.1 only addressed full speed and low speed. High speed devices
12 can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds.
13
14 USB 1.1 devices may also be used on USB 2.0 systems. When plugged
15 into an EHCI controller, they are given to a USB 1.1 "companion"
16 controller, which is a OHCI or UHCI controller as normally used with
17 such devices. When USB 1.1 devices plug into USB 2.0 hubs, they
18 interact with the EHCI controller through a "Transaction Translator"
19 (TT) in the hub, which turns low or full speed transactions into
20 high speed "split transactions" that don't waste transfer bandwidth.If you google for EHCI and UHCI you often find hints for using (simple) low speed devices with deactivating ehci devices driver and using (good old) uhci kernel drivers. Eventually is the oxsemi ehci implementation of low speed devices buggy.
some infos about the prolific PL-2303 USB to Serial Bridge Controller:
it's use 12Mbs Full Speed USB and this works fine with our OXNAS EHCI Host Controller :-)
~ # cat /proc/bus/usb/devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24.4 ehci_hcd
S: Product=OXNAS EHCI Host Controller
S: SerialNumber=usb
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=067b ProdID=2303 Rev= 3.00
S: Manufacturer=Prolific Technology Inc.
S: Product=USB-Serial Controller
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 10 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0msyou run this on another linux machine?
no it's a screenshot :-) from our whitebook
The Profilec 2303 (serial) and 2305 (parallel) are Full-Speed-USB adapter from the same family.
I'm sure all the time that the serial adapter 2303 also works. Now I have a PL-2303 cable.
Now I'm also sure anybody "Low Speed" adapter don't. The oxnas-ehci kernel driver speaks 480 Mbit/sec "High Speed" and 12 Mbit/sec "Full Speed".
You tested unsuccessful a USB Mouse -> the mouse is a low speed device!
There is a good microsoft tool to print out all usb values under windows:
Microsoft USBView - USB Connection Viewer
http://www.ftdichip.com/Resources/Utilities.htm
here a sample from a Logitech mouse under windows
Device Descriptor:
bcdUSB: 0x0200
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x08 (8)
idVendor: 0x046D (Logitech Inc.)
idProduct: 0xC03E
bcdDevice: 0x2000
iManufacturer: 0x01
iProduct: 0x02
iSerialNumber: 0x00
bNumConfigurations: 0x01
ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed: Low
Device Address: 0x01
Open Pipes: 1
Endpoint Descriptor:
bEndpointAddress: 0x81 IN
Transfer Type: Interrupt
wMaxPacketSize: 0x0004 (4)
bInterval: 0x0AHm, interesting, so this has nothing to do with UHCI and EHCI, but only with speed - only low
speed devices dont work? Well it explains why the IO-Warrior wont work, because they are
also Lowspeed.
Should have tried this before…. (connecting my collection of usb-devices)…
USB V1.1 (!) Hub - works (with 12MBits/s of course)
0557:2008 (Serial -> USB converter) - detected, speed=12MBit/s, no driver
0403:6001 (Serial -> USB converter) - detected, speed=12MBit/s, no driver
050f:0180 (IRDA adapter) - detected, speed=12MBit/s, no driver
Aha! So I had the bad luck that the first (and only) device I tried was a LowSpeed device and
I concluded that UHCI does not work!
@Andrew:
Thanks for your entry in the guestbook!
@tomas123:
On saturday, the MAX232 arrived :-) The soldering iron needs to get heated ;-)
Blip
Wikipedia wrotes: "While high-speed hubs support all device speeds, low and full-speed traffic is combined and segregated from high-speed traffic through a transaction translator. Each transaction translator segregates lower speed traffic into its own pool, essentially creating a virtual full-speed bus. "
It's possible to use a low speed device connected with an external usb hub?
The hub translates low speed to high speed!!
Unfortunately I have not a USB 2.0 hub for testing.
Please check your USB 1.1 hub with IO-Warrior or a mouse.
> speed=12MBit/s, no driver
This is not a problem. The missing driver don't need oxnas hardware support. You can use libusb to speek with the device. Some special drivers are in optware feed for other NAS (NSLU2).
see http://ipkg.nslu2-linux.org/feeds/unslung/modules/cross/unstable/
We need adaptations for WhiteBook.
For usb-serial devices you need first a general bridge…
"ipkg install kernel-module-usbserial" -> usbserial.o
…and the corresponding device driver:
your device id: 0557-2008
Prolific PL-2303 Driver: pl2303.o
some optware feeds support a "ipkg install kernel-module-pl2303"
see: http://www.nslu2-linux.org/wiki/Peripherals/USB2Serial
I think it's a minor change adapting the source to WhiteBook.
your device: 0403-6001
a FTI232 8-bit FIFO
there is also a kernel driver in other feeds "ipkg install kernel-module-ftdi-sio": ftdi_sio.o
Tomas,
I know how I could get the USB-to-serial converters to work (I even compiled the ftdi_sio and added it to
the downloads offered on my page), I just have no use for it! Thanks anyway for explaining, maybe someone
else finds it useful.
I've asked the question whether one could use a LowSpeed device via the transaction translater (a HUB) myself
just yesterday. I tried what you also proposed to do: Connect the IO-Warrior via an HUB. With my USB 1.1 HUB,
it does not work. Should try with an USB 2.0 HUB, but I have none lying around just now.
Is the AVR device you plan to build LowSpeed or FullSpeed ?
Blip
P.S. - We should rename this thread something like "MBWE - USB kernel module hacking for experts" ;-)
some bad news to Prolific PL-2303 USB/serial Driver:
I compiled usbserial.ko and pl2303.ko with nativ kernel sources.
see kernel compile tutorial / variant 2/ make menuconfig : http://mybookworld.wikidot.com/compiling-white-light-modules-from-source
…but there some bugs:
let's begin:
# mknod /dev/ttyUSB0 c 188 0
# mknod /dev/ttyUSB1 c 188 1
# chmod 666 /dev/ttyUSB*
# insmod usbserial.ko
# insmod pl2303.ko debug=1
# dmesg | tail
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
usb 1-1: new full speed USB device using oxnas-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
pl2303 1-1:1.0: pl2303 converter detected
drivers/usb/serial/pl2303.c: device type: 2
usb 1-1: pl2303 converter now attached to ttyUSB0
# mount -t usbfs none /proc/bus/usb
# cat /proc/bus/usb/devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24.4 ehci_hcd
S: Product=OXNAS EHCI Host Controller
S: SerialNumber=usb
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=067b ProdID=2303 Rev= 3.00
S: Manufacturer=Prolific Technology Inc.
S: Product=USB-Serial Controller
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=pl2303
E: Ad=81(I) Atr=03(Int.) MxPS= 10 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0msThat look fine.
I'm using parameter "debug=1" for verbose mode of kernel driver (kernel message protocol)
We need "mknod /dev/ttyUSB0 …" and chmod only first time. It's resident after reboot.
Now we send a message
# echo -n "Hello" > /dev/ttyUSB0
# dmesg
drivers/usb/serial/pl2303.c: pl2303_open - port 0
drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 2
drivers/usb/serial/pl2303.c: 0x40:0x1:0x404:0x0 0
drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 2
drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8383:0x0 1 - 0
drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 2
drivers/usb/serial/pl2303.c: 0x40:0x1:0x404:0x1 0
drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 2
drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8383:0x0 1 - 0
drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x1 0
drivers/usb/serial/pl2303.c: 0x40:0x1:0x1:0x0 0
drivers/usb/serial/pl2303.c: 0x40:0x1:0x2:0x44 0
drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0 0
drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0 0
drivers/usb/serial/pl2303.c: pl2303_set_termios - port 0
drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 0
drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8
drivers/usb/serial/pl2303.c: pl2303_set_termios - baud = 9600
drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1
drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none
drivers/usb/serial/pl2303.c: 0x21:0x20:0:0 7
drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0
drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8
drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0 0
drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb
drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb
drivers/usb/serial/pl2303.c: pl2303_read_int_callback (0)
pl2303 ttyUSB0: pl2303_read_int_callback - length = 10, data = a1 20 00 00 00 00 02 00 00 02
drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401
drivers/usb/serial/pl2303.c: pl2303_write_room - port 0
drivers/usb/serial/pl2303.c: pl2303_write_room - returns 1023
drivers/usb/serial/pl2303.c: pl2303_write - port 0, 5 bytes
drivers/usb/serial/pl2303.c: pl2303_send - port 0
pl2303 ttyUSB0: pl2303_send - length = 5, data = 48 65 6c 6c 6f
drivers/usb/serial/pl2303.c: pl2303_write_bulk_callback - port 0
drivers/usb/serial/pl2303.c: pl2303_send - port 0
drivers/usb/serial/pl2303.c: pl2303_close - port 0
drivers/usb/serial/pl2303.c: pl2303_close - shutting down urbs
drivers/usb/serial/pl2303.c: pl2303_read_bulk_callback - port 0
drivers/usb/serial/pl2303.c: pl2303_read_bulk_callback - urb status = -2
drivers/usb/serial/pl2303.c: pl2303_read_bulk_callback - port is closed, exiting.
drivers/usb/serial/pl2303.c: pl2303_read_int_callback (0)
drivers/usb/serial/pl2303.c: pl2303_read_int_callback - urb shutting down with status: -2
drivers/usb/serial/pl2303.c: set_control_lines - value = 0, retval = -110No error, all looks fine - but the serial port is quiet.
I check it with an oscilloscope. Nothing.
I wrote same bytes to our whitebook. Also unsuccessful.
If I disconnect and then reconnect the Prolific PL-2303 the driver don't grab the ttyUSB0
# dmesg
usb 1-1: new full speed USB device using oxnas-ehci and address 12
# echo -n "Hello" > /dev/ttyUSB0
-sh: cannot create /dev/ttyUSB0: No such devicethis is a good point to restart the whitebook
Edit: Afterwards I noticed that Rx works fine. Only Tx is buggy. See next message.
PS: The software-USB with AVR is LowSpeed.
http://www.obdev.at/products/vusb/index-de.html
I found another Prolific PL-2303 USB/serial Driver in my spare box:
idVendor: 0x0557 (ATEN International Co. Ltd.)
idProduct: 0x2008
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0557 ProdID=2008 Rev= 0.01
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=pl2303
E: Ad=81(I) Atr=03(Int.) MxPS= 10 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms@bleep : It's the same id like your adapter.
Here is a picture: http://www.partsdata.de/descr_artikel/U/USB-0555/USBtoSERIAL_BIG.jpg
This adapter works a little bit.
I can rockstable send messages with 9600 Baud to the WhiteBook
Simple type for reading messages from PC:
# cat /dev/ttyUSB0But if I send a message from whitebook to my PC the oxnas kernel driver ehci_hcd.ko dies after 2 or 3 packets.
I only must restart ehci-hcd.ko for the next message.
Lets look:
//for debug only we kill the unnecessary module
# rmmod usb_storage
//now start pl2303 driver
# insmod usbserial.ko
# insmod pl2303.ko
// here we plug in the pl2303
# echo -n "Hello" > /dev/ttyUSB0
# echo -n "Hello" > /dev/ttyUSB0
// this hellos I successful received on my PC but now the kernel driver dies and I must restart the driver
// it's not necessary to unplug the pl2303 !!
# rmmod ehci_hcd
# insmod /lib/modules/2.6.24.4/kernel/drivers/usb/host/ehci-hcd.ko
// now we can send the next message
# echo -n "Hello" > /dev/ttyUSB0
# echo -n "Hello" > /dev/ttyUSB0
//...until ehci_hcd.ko dies
# rmmod ehci_hcd
# insmod /lib/modules/2.6.24.4/kernel/drivers/usb/host/ehci-hcd.ko
# echo -n "Hello" > /dev/ttyUSB0
# echo -n "Hello" > /dev/ttyUSB0
//and so on....this is dirty
Don't forget:
This hack for Tx don't work with the other PL-2303 Vendor=067b ProdID=2303.
I found a difference:
Vendor=067b ProdID=2303 => PL-2303X (bMaxPacketSize0 MxPS is 64)
Vendor=0557 ProdID=2008 => PL-2303 (bMaxPacketSize0 MxPS is 8)
The PL-2303X can be distinguished from a PL-2303 by checking bMaxPacketSize0 for the device using.
If bMaxPacketSize0 is 64, you probably have a PL-2303X.
The kernel driver pl2303.c is for both chips:
enum pl2303_type {
type_0, /* don't know the difference between type 0 and */
type_1, /* type 1, until someone from prolific tells us... */
HX, /* HX version of the pl2303 chip */
};
static int pl2303_startup(struct usb_serial *serial)
{
... if (serial->dev->descriptor.bMaxPacketSize0 == 0x40)
type = HX;some news:
I connected a USB 2.0 Hub to WhiteBook.
With this hub a Logitech Low Speed Mouse is visible (Spd=1.5)!!
~ # cat /proc/bus/usb/devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 1, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.24.4 ehci_hcd
S: Product=OXNAS EHCI Host Controller
S: SerialNumber=usb
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 4
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05e3 ProdID=0605 Rev= 6.0b
S: Product=USB2.0 Hub
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
T: Bus=01 Lev=02 Prnt=03 Port=03 Cnt=01 Dev#= 4 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=046d ProdID=c03e Rev=20.00
S: Manufacturer=Logitech
S: Product=USB-PS/2 Optical Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=10msThe USB hub with ID 05e3:0605 is a Genesys Logic USB 2.0 Hub with GL850 chip.
google search: GL850 datasheet
Also both USB/serial adapters (with PL-2303 and PL-2303X chip) works great in both directions over this hub!
We beat the OXNAS EHCI bug!
Hi Tomas,
I can confirm this behavior also with an other HUB and with other LowSpeed devices:
T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=07c0 ProdID=1501 Rev=10.21
S: Manufacturer=Code Mercenaries
S: Product=IO-Warrior24
S: SerialNumber=00000000
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=iowarrior
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=iowarrior
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
The HUB used has VID 0409 and PID 005a, it contains a NEC uPD720114 USB 2.0 4 Port HUB chip.
I think we can conclude that operating any LowSpeed USB device is possible with any USB 2.0 HUB
(except those with a buggy Transaction Translator).
Anyone who wants to connect homebrew electronics to the MBWE could use the IOWarrior this way.
Of course, projects with firmware driven USB support (which is LowSpeed most times too) works too
when using an USB 2.0 HUB.
Blip
Please send me a mail if you succesfull compiled source code for iowarrior.
I have some trouble with cross compiling my own source code (need a make file).
Also I can't compile a native gcc with our nslu2 svn (svn use the ready compiled gnu-csl-arm-2005Q1B-arm-none-linux-gnueabi-i686-pc-linux-gnu from codesourcery.com)
-> I get same minor errors while compiling gcc ;-)
see variant 3 in http://mybookworld.wikidot.com/compiling-white-light-modules-from-source














