RevC USB Host port randomly disconnects
217 views
Skip to first unread message
eelcor
Apr 20, 2009, 4:32:49 AM4/20/09
to Beagle Board
Hi,
I've been playing around with Sakoman's precompiled kernel and rootfs
and it all works fine. However, when I try to copy a lot of data from
a usb key or through the network, the beagleboard randomly disconnects
the USB. I haven't been able to copy a single file on the Beagleboard
(I tried some 16MB mp4 files and some larger files) but it doesn't
work at all.
I power the beagleboard using the iPod charger and tried several
(higher specced) psu's as well. I've tried to connect different hub's
as well, with no luck either.
Somebody said that it could be a bug in the kernel (2.6.29-omap1) and
that there might be a workaround. Can somebody help me with this
problem?
Kind regards,
Eelco
I've been playing around with Sakoman's precompiled kernel and rootfs
and it all works fine. However, when I try to copy a lot of data from
a usb key or through the network, the beagleboard randomly disconnects
the USB. I haven't been able to copy a single file on the Beagleboard
(I tried some 16MB mp4 files and some larger files) but it doesn't
work at all.
I power the beagleboard using the iPod charger and tried several
(higher specced) psu's as well. I've tried to connect different hub's
as well, with no luck either.
Somebody said that it could be a bug in the kernel (2.6.29-omap1) and
that there might be a workaround. Can somebody help me with this
problem?
Kind regards,
Eelco
Koen Kooi
Apr 20, 2009, 4:34:32 AM4/20/09
to beagl...@googlegroups.com
Op 20 apr 2009, om 10:32 heeft eelcor het volgende geschreven:
>
> Hi,
>
> I've been playing around with Sakoman's precompiled kernel and rootfs
> and it all works fine.
What about the angstrom rootfs and kernels? I have no problems with
big USB transfers there. The 2.6.29 OE builds is working quite well,
but it heavily patches usb.
regards,
Koen
eelcor
Apr 20, 2009, 4:42:19 AM4/20/09
to Beagle Board
Let me see if I can copy large files within the SD. Yup, that works
ok...so it is something with the USB port.
Any clues?
regards,
Eelco
> PGP.sig
> < 1 KWeergevenDownloaden
ok...so it is something with the USB port.
Any clues?
regards,
Eelco
> < 1 KWeergevenDownloaden
Frans Meulenbroeks
Apr 20, 2009, 7:55:49 AM4/20/09
to Beagle Board
What hw rev do you have? What port do you use?
I had the same problems with the OTG port with 2.6.28.
As far as I know there is no fix yet.
With the EHCI port on C2 hw I haven't seen the problem yet.
Frans
I had the same problems with the OTG port with 2.6.28.
As far as I know there is no fix yet.
With the EHCI port on C2 hw I haven't seen the problem yet.
Frans
Steve Sakoman
Apr 20, 2009, 10:47:34 AM4/20/09
to beagl...@googlegroups.com
On Mon, Apr 20, 2009 at 1:32 AM, eelcor <eelco...@gmail.com> wrote:
>
> Hi,
>
> I've been playing around with Sakoman's precompiled kernel and rootfs
> and it all works fine. However, when I try to copy a lot of data from
> a usb key or through the network, the beagleboard randomly disconnects
> the USB. I haven't been able to copy a single file on the Beagleboard
> (I tried some 16MB mp4 files and some larger files) but it doesn't
> work at all.
I don't see this on my rev C Beagleboard or on my Overo when
>
> Hi,
>
> I've been playing around with Sakoman's precompiled kernel and rootfs
> and it all works fine. However, when I try to copy a lot of data from
> a usb key or through the network, the beagleboard randomly disconnects
> the USB. I haven't been able to copy a single file on the Beagleboard
> (I tried some 16MB mp4 files and some larger files) but it doesn't
> work at all.
transferring a 64MB mp4 file:
root@beagleboard:~# cp /bbb.mp4 /media/sda1/test/
root@beagleboard:~# ls -l /media/sda1/test/
total 63144
-rwxr-xr-x 1 root root 64657027 Apr 19 22:10 bbb.mp4
root@overo:~# cp /bbb.mp4 /media/sda1/test/
root@overo:~# ls -l /media/sda1/test/
total 63144
-rwxr-xr-x 1 root root 64657027 Apr 20 07:38 bbb.mp4
Can you give us a little more info on which of my builds you are using
and what type of USB data storage device you are using?
I did my test using my most recent build, the EHCI port, a Cyberpower
powered hub and a Lexar 4GB flash drive.
Steve
Steve Sakoman
Apr 20, 2009, 10:56:43 AM4/20/09
to beagl...@googlegroups.com
On Mon, Apr 20, 2009 at 1:34 AM, Koen Kooi <ko...@beagleboard.org> wrote:
> The 2.6.29 OE builds is working quite well, but it heavily
> patches usb.
From the thread title it appears he is using ehci, so I don't think
that the musb patches matter in this case :-)
I too see no issues with large file transfers, so something else is
going on here.
Steve
John Beetem
Apr 20, 2009, 11:48:34 AM4/20/09
to Beagle Board
Eelco:
Your symptoms sound very much like insufficent USB power to your
device. I had similar problems with my B4 until I hooked up an
external power supply to my hub.
Have you tried using a self-powered USB hub, i.e., one with an
external power supply? According to the Rev C2.2 BeagleBoard system
reference manual (http://beagleboard.org/static/BBSRM_latest.pdf) the
Host-only port should be able to deliver 500 mA. However, I think
this is only if you have a 5V regulated supply connected through the
power jack. According to section 7.2 of the system reference manual,
"if the board is powered from the OTG connector, then the power from
this port [i.e., host-only USB] is extremely limited and will not be
able to provide sufficient power to run most USB devices".
Hope this helps,
John
Your symptoms sound very much like insufficent USB power to your
device. I had similar problems with my B4 until I hooked up an
external power supply to my hub.
Have you tried using a self-powered USB hub, i.e., one with an
external power supply? According to the Rev C2.2 BeagleBoard system
reference manual (http://beagleboard.org/static/BBSRM_latest.pdf) the
Host-only port should be able to deliver 500 mA. However, I think
this is only if you have a 5V regulated supply connected through the
power jack. According to section 7.2 of the system reference manual,
"if the board is powered from the OTG connector, then the power from
this port [i.e., host-only USB] is extremely limited and will not be
able to provide sufficient power to run most USB devices".
Hope this helps,
John
eelcor
Apr 20, 2009, 1:33:40 PM4/20/09
to Beagle Board
Thank you all for your replies. I was also thinking about an
insufficient powersupply. However, I use an iPod charger as power
supply and not a powered hub. I read something in the irc logs
regarding someone who had the same problems. I will try and see
whether I am able to increase the power using a DC adapter. How about
the MUSB patches? How do I apply these?
Kind regards, Eelco
insufficient powersupply. However, I use an iPod charger as power
supply and not a powered hub. I read something in the irc logs
regarding someone who had the same problems. I will try and see
whether I am able to increase the power using a DC adapter. How about
the MUSB patches? How do I apply these?
Kind regards, Eelco
eelcor
Apr 20, 2009, 2:07:09 PM4/20/09
to Beagle Board
did Steve also use these patches in his kernel builds? I'm currently
using 2.6.29-omap1 as kernel version. I will look into the power
issue. I hope I will get the DC in to work, as I have done something
really stupid and plugged 5v the wrong way in. There hasn't been any
smoke and the board still works on the OTG power. It should however be
explained more explicit in de SRM (they do mention a lot about exactly
5 volts, but nothing about the pinout).
So I hope to supply the board with more amps to get sufficient power.
Can the power to OTG port be more when you use a separate USB power
supply?
Kind regards, Eelco
> PGP.sig
> < 1 KWeergevenDownloaden
using 2.6.29-omap1 as kernel version. I will look into the power
issue. I hope I will get the DC in to work, as I have done something
really stupid and plugged 5v the wrong way in. There hasn't been any
smoke and the board still works on the OTG power. It should however be
explained more explicit in de SRM (they do mention a lot about exactly
5 volts, but nothing about the pinout).
So I hope to supply the board with more amps to get sufficient power.
Can the power to OTG port be more when you use a separate USB power
supply?
Kind regards, Eelco
> < 1 KWeergevenDownloaden
Gerald Coley
Apr 20, 2009, 2:24:18 PM4/20/09
to beagl...@googlegroups.com
The pinout is clearly defined in section 9.1 of the System Reference Manual. There is even a big picture.
Gerald
eelcor
Apr 20, 2009, 2:35:24 PM4/20/09
to Beagle Board
Thank you, I have been stuck on page 24 and 16 I think. Both mention
the power connector, but do not supply the correct schematics...
Thankfully the power port hasn't been broken. I still have a fine
board, now trying to see whether I am able to do my transfers.
kind regards, Eelco
> > > < 1 KWeergevenDownloaden- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -
the power connector, but do not supply the correct schematics...
Thankfully the power port hasn't been broken. I still have a fine
board, now trying to see whether I am able to do my transfers.
kind regards, Eelco
>
> - Tekst uit oorspronkelijk bericht weergeven -
eelcor
Apr 20, 2009, 2:42:30 PM4/20/09
to Beagle Board
Okay,
I've connected the beagleboard to a 5V 2A max power supply using the
DC in connector. I've tried to copy stuff, but it still gets stuck
after copying approx 10-15MB. It completely disables the USB EHCI
port. I use a powered logitech USB hub. The board does not crash, only
the USB gets disconnected and only a reset solves the problem.
Kind regards, Eelco
I've connected the beagleboard to a 5V 2A max power supply using the
DC in connector. I've tried to copy stuff, but it still gets stuck
after copying approx 10-15MB. It completely disables the USB EHCI
port. I use a powered logitech USB hub. The board does not crash, only
the USB gets disconnected and only a reset solves the problem.
Kind regards, Eelco
eelcor
Apr 20, 2009, 2:50:43 PM4/20/09
to Beagle Board
Hi,
Just captured the post-mortem on the serial console, during the USB
disconnect. Somehow it is not able to regain control.
Kind regards, Eelco
>>> capture of the serial console
hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 2-2: USB disconnect, address 2
usb 2-2.1: USB disconnect, address 3
hub 2-2:1.0: cannot reset port 1 (err = -71)
hub 2-2:1.0: cannot reset port 1 (err = -19)
hub 2-2:1.0: cannot disable port 1 (err = -19)
hub 2-2:1.0: cannot disable port 1 (err = -19)
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 313311
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 313551
FAT: FAT read failed (blocknr 4018)
FAT: FAT read failed (blocknr 4018)
usb 2-2.2: USB disconnect, address 4
Just captured the post-mortem on the serial console, during the USB
disconnect. Somehow it is not able to regain control.
Kind regards, Eelco
>>> capture of the serial console
hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 2-2: USB disconnect, address 2
usb 2-2.1: USB disconnect, address 3
hub 2-2:1.0: cannot reset port 1 (err = -71)
hub 2-2:1.0: cannot reset port 1 (err = -19)
hub 2-2:1.0: cannot disable port 1 (err = -19)
hub 2-2:1.0: cannot disable port 1 (err = -19)
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 313311
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 313551
FAT: FAT read failed (blocknr 4018)
FAT: FAT read failed (blocknr 4018)
usb 2-2.2: USB disconnect, address 4
eelcor
Apr 20, 2009, 2:53:31 PM4/20/09
to Beagle Board
And the kernel version reported by the board during startup is:
Angstrom/2.6.29-rcfinal+r2+git90
It is a precompiled binary by Steve.
Kind regards, Eelco
Angstrom/2.6.29-rcfinal+r2+git90
It is a precompiled binary by Steve.
Kind regards, Eelco
John Beetem
Apr 20, 2009, 3:46:02 PM4/20/09
to Beagle Board
Eelco,
Another thing to check is all the USB cables between Beagle and your
device(s). 480 Mb/s high-speed USB requires high quality cables,
preferably very short. The USB hardware and software should be able
to recover seamlessly from an occasional data error, but the software
may not be completely robust at this time.
Now that you have +5V regulated power for the BeagleBoard power jack
and a powered hub, you might also try using the OTG port to talk to
your hub. It supports all three USB 2.0 speeds. See the BeagleBoard
wiki and FAQ for common problems.
Hope this helps,
John
Another thing to check is all the USB cables between Beagle and your
device(s). 480 Mb/s high-speed USB requires high quality cables,
preferably very short. The USB hardware and software should be able
to recover seamlessly from an occasional data error, but the software
may not be completely robust at this time.
Now that you have +5V regulated power for the BeagleBoard power jack
and a powered hub, you might also try using the OTG port to talk to
your hub. It supports all three USB 2.0 speeds. See the BeagleBoard
wiki and FAQ for common problems.
Hope this helps,
John
eelcor
Apr 20, 2009, 4:39:28 PM4/20/09
to Beagle Board
I have a feeling that you're right, although I use high quality cables
it is worth a try. Can you see anything based on the output I mailed
earlier? I am also trying to compile a new kernel, to see whether that
has some success.
Thank you very much!
Eelco
it is worth a try. Can you see anything based on the output I mailed
earlier? I am also trying to compile a new kernel, to see whether that
has some success.
Thank you very much!
Eelco
eelcor
Apr 20, 2009, 5:28:42 PM4/20/09
to Beagle Board
Hmmm it even gets stranger. When I run Chameleon man for a longer
period (more than 1 minute) USB also shuts down...very strange... I
think it must be some kind of software problem...
> > John- Tekst uit oorspronkelijk bericht niet weergeven -
period (more than 1 minute) USB also shuts down...very strange... I
think it must be some kind of software problem...
Steve Sakoman
Apr 20, 2009, 11:04:02 PM4/20/09
to beagl...@googlegroups.com
On Mon, Apr 20, 2009 at 2:28 PM, eelcor <eelco...@gmail.com> wrote:
>
> Hmmm it even gets stranger. When I run Chameleon man for a longer
> period (more than 1 minute) USB also shuts down...very strange... I
> think it must be some kind of software problem...
I don't think it is a sw issue. As I mentioned earlier today, I do
>
> Hmmm it even gets stranger. When I run Chameleon man for a longer
> period (more than 1 minute) USB also shuts down...very strange... I
> think it must be some kind of software problem...
not see the issues you describe when using those images on my rev C
beagle or my overo. I just ran ChameleonMan for an hour and
experienced no loss of USB.
You definitely seem to have an problem, but I don't think it is a
fundamental sw issue. I suspect something in your hardware setup.
Steve
eelcor
Apr 21, 2009, 1:46:35 AM4/21/09
to Beagle Board
Steve,
Installing the rootfs, u-boot and uImage should be enough? You also
put a modules.tgz file on the site. Do I need to do something with
this file as well? I don't see any moduls errors during startup.
regards, Eelco
On Apr 21, 5:04 am, Steve Sakoman <sako...@gmail.com> wrote:
> >> - Tekst uit oorspronkelijk bericht weergeven -- Hide quoted text -
>
> - Show quoted text -
Installing the rootfs, u-boot and uImage should be enough? You also
put a modules.tgz file on the site. Do I need to do something with
this file as well? I don't see any moduls errors during startup.
regards, Eelco
On Apr 21, 5:04 am, Steve Sakoman <sako...@gmail.com> wrote:
>
> - Show quoted text -
eelcor
Apr 21, 2009, 3:23:49 AM4/21/09
to Beagle Board
Okay, I'm completely flabbergasted.
I tried pretty much everything, ranging from using different power
supplies both on the OTG port and the DC in port. I reinstalled the
binaries from Steve and I used three different USB2.0 hubs. I have
still a disconnecting USB port. I am not able to reset the USB port, a
complete reboot is needed.
What can be wrong? Do I have a malfunctioning beagleboard? I read
someone on the IRC channel having the same problems.
Kind regards,
Eelco
> > - Show quoted text -- Tekst uit oorspronkelijk bericht niet weergeven -
I tried pretty much everything, ranging from using different power
supplies both on the OTG port and the DC in port. I reinstalled the
binaries from Steve and I used three different USB2.0 hubs. I have
still a disconnecting USB port. I am not able to reset the USB port, a
complete reboot is needed.
What can be wrong? Do I have a malfunctioning beagleboard? I read
someone on the IRC channel having the same problems.
Kind regards,
Eelco
Søren Steen Christensen
Apr 21, 2009, 3:45:02 AM4/21/09
to beagl...@googlegroups.com
Hi Eelco,
I can't remember if you already wrote, but have you tried another memory
stick? Which one are you using?
How is your setup? A standard ~1.8m cable from BB to HUB and then the memory
stick connected directly to the HUB? Just trying to bring all details on the
table in order to search for minor differences in our setups :-)
Best regards
Søren
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.12.0/2068 - Release Date:
> 04/19/09 20:04:00
I can't remember if you already wrote, but have you tried another memory
stick? Which one are you using?
How is your setup? A standard ~1.8m cable from BB to HUB and then the memory
stick connected directly to the HUB? Just trying to bring all details on the
table in order to search for minor differences in our setups :-)
Best regards
Søren
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.12.0/2068 - Release Date:
> 04/19/09 20:04:00
eelcor
Apr 21, 2009, 4:00:07 AM4/21/09
to Beagle Board
I have an even shorter cable between the board and the hub. I've
connected the memorystick directly to the hub. I've tried 3 different
memory sticks and an USB ethernet adaptor (which also shuts down when
to much data passes), all exhibit the same problem. I tried to connect
both OTG and DC in power supplies (separately and both at the same
time). Strangely it not only crashes on a lot of data, it also crashes
when I run the chameleon man demo, the USB hub lights go out after
approx 1 minut of running time.
It more and more starts to look like a hardware failure. I've included
the messages that are generated during the USB crash. As you can see
the hub is pretty much useless afterwards, a power cycle of the hub or
disconnect/connect does not do the trick, I have to restart. The
serial console however still works and I do get an image (the running
man keeps on running).
Kind regards, Eelco
>>> output on serial console, the cables are good quality and should not be the limiting factor
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: hub_port_status failed (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: hub_port_status failed (err = -71)
hub 2-2:1.0: hub_port_status failed (err = -71)
sd 0:0:0:0: [sda] READ CAPACITY failed
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] READ CAPACITY failed
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] READ CAPACITY failed
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
usb 2-2.3: USB disconnect, address 3
usb 2-2.4: USB disconnect, address 4
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
hub 2-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
hub 2-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
hub 2-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
hub 2-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
hub 2-2:1.0: hub_port_status failed (err = -19)
hub 2-2:1.0: hub_port_status failed (err = -19)
hub 2-2:1.0: hub_port_status failed (err = -19)
hub 2-2:1.0: hub_port_status failed (err = -19)
hub 2-2:1.0: activate --> -19
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
On 21 apr, 09:45, Søren Steen Christensen
> > 04/19/09 20:04:00- Tekst uit oorspronkelijk bericht niet weergeven -
connected the memorystick directly to the hub. I've tried 3 different
memory sticks and an USB ethernet adaptor (which also shuts down when
to much data passes), all exhibit the same problem. I tried to connect
both OTG and DC in power supplies (separately and both at the same
time). Strangely it not only crashes on a lot of data, it also crashes
when I run the chameleon man demo, the USB hub lights go out after
approx 1 minut of running time.
It more and more starts to look like a hardware failure. I've included
the messages that are generated during the USB crash. As you can see
the hub is pretty much useless afterwards, a power cycle of the hub or
disconnect/connect does not do the trick, I have to restart. The
serial console however still works and I do get an image (the running
man keeps on running).
Kind regards, Eelco
>>> output on serial console, the cables are good quality and should not be the limiting factor
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: cannot reset port 4 (err = -71)
hub 2-2:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: cannot disable port 4 (err = -71)
hub 2-2:1.0: hub_port_status failed (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: cannot reset port 3 (err = -71)
hub 2-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: cannot disable port 3 (err = -71)
hub 2-2:1.0: hub_port_status failed (err = -71)
hub 2-2:1.0: hub_port_status failed (err = -71)
sd 0:0:0:0: [sda] READ CAPACITY failed
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
sd 0:0:0:0: [sda] Sense not available.
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] READ CAPACITY failed
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
sd 0:0:0:0: [sda] Sense not available.
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] READ CAPACITY failed
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
sd 0:0:0:0: [sda] Sense not available.
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
usb 2-2.3: USB disconnect, address 3
usb 2-2.4: USB disconnect, address 4
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
hub 2-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
hub 2-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
hub 2-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
hub 2-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
hub 2-2:1.0: hub_port_status failed (err = -19)
hub 2-2:1.0: hub_port_status failed (err = -19)
hub 2-2:1.0: hub_port_status failed (err = -19)
hub 2-2:1.0: hub_port_status failed (err = -19)
hub 2-2:1.0: activate --> -19
ehci-omap ehci-omap.0: port 2 reset error -110
hub 2-0:1.0: hub_port_status failed (err = -32)
On 21 apr, 09:45, Søren Steen Christensen
eelcor
Apr 21, 2009, 4:05:41 AM4/21/09
to Beagle Board
It also happens without the memory stick. The USB port just shuts down
after running the Chameleon man for more than one minute.
regards, Eelco
> ...
>
> meer lezen »- Tekst uit oorspronkelijk bericht niet weergeven -
after running the Chameleon man for more than one minute.
regards, Eelco
>
> meer lezen »- Tekst uit oorspronkelijk bericht niet weergeven -
Søren Steen Christensen
Apr 21, 2009, 4:12:37 AM4/21/09
to beagl...@googlegroups.com
Hmm - Sounds like a HW failure - Do you have any measurement equipment? Can
you monitor the Host_Vbus signal on a scope while the error is occurring?
You can measure it at the capacitor C101 just next to the USB connector (the
end toward the inside of the board)...
In case not, I think you should try to go for a RMA...
you monitor the Host_Vbus signal on a scope while the error is occurring?
You can measure it at the capacitor C101 just next to the USB connector (the
end toward the inside of the board)...
In case not, I think you should try to go for a RMA...
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.12.0/2068 - Release Date:
> 04/20/09 17:56:00
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.12.0/2068 - Release Date:
eelcor
Apr 21, 2009, 4:23:38 AM4/21/09
to Beagle Board
I think I will go for an RMA. I do have some measurement equipment but
not the stuff to repair the board. Søren, you also live in Europe? How
do I do an RMA from the Netherlands?
Thank you very much for all your advice. I will have to get used to a
couple of weeks living without the board...my wife won't mind ;-)
kind regards, Eelco
On 21 apr, 10:12, Søren Steen Christensen
not the stuff to repair the board. Søren, you also live in Europe? How
do I do an RMA from the Netherlands?
Thank you very much for all your advice. I will have to get used to a
couple of weeks living without the board...my wife won't mind ;-)
kind regards, Eelco
On 21 apr, 10:12, Søren Steen Christensen
<sorenschristen...@stofanet.dk> wrote:
> Hmm - Sounds like a HW failure - Do you have any measurement equipment? Can
> you monitor the Host_Vbus signal on a scope while the error is occurring?
> You can measure it at the capacitor C101 just next to the USB connector (the
> end toward the inside of the board)...
>
> In case not, I think you should try to go for a RMA...
>
> Best regards
>
>
>
>
> Hmm - Sounds like a HW failure - Do you have any measurement equipment? Can
> you monitor the Host_Vbus signal on a scope while the error is occurring?
> You can measure it at the capacitor C101 just next to the USB connector (the
> end toward the inside of the board)...
>
> In case not, I think you should try to go for a RMA...
>
> Best regards
>
>
>
>
Søren Steen Christensen
Apr 21, 2009, 4:43:59 AM4/21/09
to beagl...@googlegroups.com
Hi Eelco,
Yes - I'm Danish and live in Denmark (for the time being). I have the
previous nearly 3 years been working as a contractor for TI, but
unfortunately TI recently decided to shutdown their Aalborg-department. I'm
therefore currently looking for new opportunities so I might move in case I
find anything interesting elsewhere in the World :-) In case anybody will
take their time to check my LinkedIn profile it can be found at:
http://www.linkedin.com/in/sorenschristensen - This would be highly
appreciated :-)
I haven't tried the RMA procedure myself, but you can find more info at:
http://beagleboard.org/support/rma
In case of further questions, please ask Gerald - I'm sure he can answer :-)
Best regards - Good luck
Yes - I'm Danish and live in Denmark (for the time being). I have the
previous nearly 3 years been working as a contractor for TI, but
unfortunately TI recently decided to shutdown their Aalborg-department. I'm
therefore currently looking for new opportunities so I might move in case I
find anything interesting elsewhere in the World :-) In case anybody will
take their time to check my LinkedIn profile it can be found at:
http://www.linkedin.com/in/sorenschristensen - This would be highly
appreciated :-)
I haven't tried the RMA procedure myself, but you can find more info at:
http://beagleboard.org/support/rma
In case of further questions, please ask Gerald - I'm sure he can answer :-)
Best regards - Good luck
Søren
> -----Original Message-----
> From: beagl...@googlegroups.com
> [mailto:beagl...@googlegroups.com] On Behalf Of eelcor
> Sent: Tuesday, April 21, 2009 10:24 AM
> To: Beagle Board
> Subject: [beagleboard] Re: RevC USB Host port randomly disconnects
>
>
> -----Original Message-----
> From: beagl...@googlegroups.com
> [mailto:beagl...@googlegroups.com] On Behalf Of eelcor
> Sent: Tuesday, April 21, 2009 10:24 AM
> To: Beagle Board
> Subject: [beagleboard] Re: RevC USB Host port randomly disconnects
>
>
Frans Meulenbroeks
Apr 21, 2009, 5:46:18 AM4/21/09
to Beagle Board
The only other thing left I can suggest is trying a different kernel
(e.g. an image from http://amethyst.openembedded.net/~koen/narcissus/
)
Fm
(e.g. an image from http://amethyst.openembedded.net/~koen/narcissus/
)
Fm
Gerald Coley
Apr 21, 2009, 7:51:00 AM4/21/09
to beagl...@googlegroups.com
I suggest you follow the process in the System Reference Manual to verify that the HW is OK. If it fails, then request the RMA.
Gerald
Steve Sakoman
Apr 21, 2009, 10:31:39 AM4/21/09
to beagl...@googlegroups.com
On Mon, Apr 20, 2009 at 10:46 PM, eelcor <eelco...@gmail.com> wrote:
>
> Steve,
>
> Installing the rootfs, u-boot and uImage should be enough? You also
> put a modules.tgz file on the site. Do I need to do something with
> this file as well? I don't see any moduls errors during startup.
I typically run with the complete set of MLO, u-boot.bin, uImage, and rootfs.
>
> Steve,
>
> Installing the rootfs, u-boot and uImage should be enough? You also
> put a modules.tgz file on the site. Do I need to do something with
> this file as well? I don't see any moduls errors during startup.
Additionally, when using a new set of images I typically wipe my
u-boot environment (for beagle: nand erase 260000 20000) so that I am
running with the latest u-boot default environment and not some older
and potentially incompatible environment (mainly an issue when dss2
boot args change).
My testing has been with this set:
http://www.sakoman.com/feeds/omap3/glibc/images/beagleboard/200904161145/
I've tried hard to recreate your issue both on my Beagle and on
multiple Overo setups, but I just don't see anything like your issue.
On Beagle, poor ChameleonMan has been running past that brick wall for
12 hours now and USB still works just fine :-)
Steve
eelcor
Apr 21, 2009, 5:45:28 PM4/21/09
to Beagle Board
Thank you for all replies, hints and tips. I am going to try another
kernel as frans sugggested and do a nand erase and finally try the HW
tests as Gerald suggested. I really hope it will solve the problems,
as I am not looking forward to send my precious beagleboard back (way
too much fun!). Steve, I really appreciate that you have been
excercising the Chameleon man!
I will post my results as soon as possible, although I am prepared for
the worst...
Kind regards, Eelco
On 21 apr, 16:31, Steve Sakoman <sako...@gmail.com> wrote:
> >> - Show quoted text -- Tekst uit oorspronkelijk bericht niet weergeven -
kernel as frans sugggested and do a nand erase and finally try the HW
tests as Gerald suggested. I really hope it will solve the problems,
as I am not looking forward to send my precious beagleboard back (way
too much fun!). Steve, I really appreciate that you have been
excercising the Chameleon man!
I will post my results as soon as possible, although I am prepared for
the worst...
Kind regards, Eelco
On 21 apr, 16:31, Steve Sakoman <sako...@gmail.com> wrote:
> On Mon, Apr 20, 2009 at 10:46 PM, eelcor <eelco.r...@gmail.com> wrote:
>
> > Steve,
>
> > Installing the rootfs, u-boot and uImage should be enough? You also
> > put a modules.tgz file on the site. Do I need to do something with
> > this file as well? I don't see any moduls errors during startup.
>
> I typically run with the complete set of MLO, u-boot.bin, uImage, and rootfs.
>
> Additionally, when using a new set of images I typically wipe my
> u-boot environment (for beagle: nand erase 260000 20000) so that I am
> running with the latest u-boot default environment and not some older
> and potentially incompatible environment (mainly an issue when dss2
> boot args change).
>
> My testing has been with this set:
>
> http://www.sakoman.com/feeds/omap3/glibc/images/beagleboard/200904161...
>
> > Steve,
>
> > Installing the rootfs, u-boot and uImage should be enough? You also
> > put a modules.tgz file on the site. Do I need to do something with
> > this file as well? I don't see any moduls errors during startup.
>
> I typically run with the complete set of MLO, u-boot.bin, uImage, and rootfs.
>
> Additionally, when using a new set of images I typically wipe my
> u-boot environment (for beagle: nand erase 260000 20000) so that I am
> running with the latest u-boot default environment and not some older
> and potentially incompatible environment (mainly an issue when dss2
> boot args change).
>
> My testing has been with this set:
>
thierry
Apr 22, 2009, 5:18:32 PM4/22/09
to Beagle Board
Hi,
I have exactly the same problem as Eelco : on a Beagleboard C2 with
2.6.28 kernel (Angstrom compiled using OE) and a USB / WIFI adapter
(LINKSYS WUSB54GC) connected to the USB HOST thru a self powered USB
HUB, a transfer from a PC using 'scp' suddendly break. However, when
sending data with 'curl' from the Beagleboard it works properly. I
have exactly the same problem when connecting directly the USB WIFI
adapter to the USB HOST (thanks a short cable male/female ~ 50 cm
long). I did not test the USB OTG yet.
Notice that exactly the same USB WIFI adapter, same USB HUB worked
with the Beagleboard B7 with a different cable connected to the USB
OTG (mini USB), running 2.6.26 kernel.
I'm ready to participate to that discussion in order to locate the
probleme : SW? HW? other?
Best regards to all.
I have exactly the same problem as Eelco : on a Beagleboard C2 with
2.6.28 kernel (Angstrom compiled using OE) and a USB / WIFI adapter
(LINKSYS WUSB54GC) connected to the USB HOST thru a self powered USB
HUB, a transfer from a PC using 'scp' suddendly break. However, when
sending data with 'curl' from the Beagleboard it works properly. I
have exactly the same problem when connecting directly the USB WIFI
adapter to the USB HOST (thanks a short cable male/female ~ 50 cm
long). I did not test the USB OTG yet.
Notice that exactly the same USB WIFI adapter, same USB HUB worked
with the Beagleboard B7 with a different cable connected to the USB
OTG (mini USB), running 2.6.26 kernel.
I'm ready to participate to that discussion in order to locate the
probleme : SW? HW? other?
Best regards to all.
thierry
Apr 23, 2009, 3:27:40 AM4/23/09
to Beagle Board
Hello everyone,
This morning, I downloaded what mentionned by Steve at
http://www.sakoman.com/feeds/omap3/glibc/images/beagleboard/200904161145/
My test is based on a USB/WIFI adapter, connected to a powered USB
HUB, sending with 'scp' a 'big' file (~40MB) from a PC to the
Beagleboard.
1) Still have the problem on USB HOST
2) Do not have the problem on USG OTG
Thus I ask myself the following questions :
1) Does it mean that from kernel point of view it is not a SW issue ?
2) Does it mean the USB HOST has some kind of HW issue (notice that
sending data using 'curl' from the Beagleboard to a PC works
properly) ?
3) The other main difference is the cable (one is mini USB, the other
not) ; I'm going to test all the available cable I have
4) I'm going back to 2.6.28 to check USB OTG (I only noticed my test
failed onto USB HOST).
Thanks to all.
This morning, I downloaded what mentionned by Steve at
http://www.sakoman.com/feeds/omap3/glibc/images/beagleboard/200904161145/
My test is based on a USB/WIFI adapter, connected to a powered USB
HUB, sending with 'scp' a 'big' file (~40MB) from a PC to the
Beagleboard.
1) Still have the problem on USB HOST
2) Do not have the problem on USG OTG
Thus I ask myself the following questions :
1) Does it mean that from kernel point of view it is not a SW issue ?
2) Does it mean the USB HOST has some kind of HW issue (notice that
sending data using 'curl' from the Beagleboard to a PC works
properly) ?
3) The other main difference is the cable (one is mini USB, the other
not) ; I'm going to test all the available cable I have
4) I'm going back to 2.6.28 to check USB OTG (I only noticed my test
failed onto USB HOST).
Thanks to all.
David Hagood
Apr 23, 2009, 9:48:48 AM4/23/09
to Beagle Board
I am seeing these disconnects as well. I have the Beagleboard powered
by a 5V 2A switching power supply, and the host USB port is driving a
self-powered USB 2.0 high-speed hub (in other words, the Beagleboard
is NOT powering the hub nor anything downstream of the hub).
When this disconnect happens, it is persistent until the board is
rebooted. The hub can be plugged into the OTG port and the devices
detected, but plugging it into the host port does nothing.
by a 5V 2A switching power supply, and the host USB port is driving a
self-powered USB 2.0 high-speed hub (in other words, the Beagleboard
is NOT powering the hub nor anything downstream of the hub).
When this disconnect happens, it is persistent until the board is
rebooted. The hub can be plugged into the OTG port and the devices
detected, but plugging it into the host port does nothing.
emeb
Apr 23, 2009, 1:57:28 PM4/23/09
to Beagle Board
I found it randomly disconnecting devices on the host port. I also saw
that the system needed to be rebooted to recognize anything on the
host port. I've had disconnects on an external DVD hooked directly to
the port, as well as a keyboard / mouse hooked up through a powered
USB2.0 hub.
Eric
eelcor
Apr 24, 2009, 9:40:55 AM4/24/09
to Beagle Board
Ah,
So I am not the only one. Can anyone verify that this problem also
appears during the chameleon man demo (probably there are more
programs that will cause this issue). It happens when running for
approx. more than a minute and moving the mouse (after a while of
moving the mouse, you will see that the hub is losing the connection.
I thought I saw someone mentioning this problem on one of the IRC
sessions...
As Frans and Steve told me they didn't have the problem with their
beagleboards, could it be something with certain tolerances on
components? (resistors, capacitors)
I am on the virge of sending the board back... But if there is no
guarantee that a new board will work than that is no option...
Kind regards,
Eelco
So I am not the only one. Can anyone verify that this problem also
appears during the chameleon man demo (probably there are more
programs that will cause this issue). It happens when running for
approx. more than a minute and moving the mouse (after a while of
moving the mouse, you will see that the hub is losing the connection.
I thought I saw someone mentioning this problem on one of the IRC
sessions...
As Frans and Steve told me they didn't have the problem with their
beagleboards, could it be something with certain tolerances on
components? (resistors, capacitors)
I am on the virge of sending the board back... But if there is no
guarantee that a new board will work than that is no option...
Kind regards,
Eelco
eelcor
Apr 24, 2009, 10:06:05 AM4/24/09
to Beagle Board
The RevC validation tests are not sufficient to detect this problem as
it seems only to occur when the board (USB, processor) is stressed by
bulk data through the port. I haven´t been able to test the OTG port,
as mini A to mini A cables are hard if not impossible to find. Frans,
have you seen any of these cables in the Netherlands?
regards, Eelco
> > Eric- Tekst uit oorspronkelijk bericht niet weergeven -
it seems only to occur when the board (USB, processor) is stressed by
bulk data through the port. I haven´t been able to test the OTG port,
as mini A to mini A cables are hard if not impossible to find. Frans,
have you seen any of these cables in the Netherlands?
regards, Eelco
Guylhem Aznar
Apr 24, 2009, 11:08:13 AM4/24/09
to beagl...@googlegroups.com
Hello
I have such a mini A/A cable and a rev C. I can test if you tell me
how you can successfully cause the stress which results in a
disconnect.
Guylhem
eelcor
Apr 24, 2009, 11:20:35 AM4/24/09
to Beagle Board
Well to crash the USB port I didn't need to use the OTG port. I've
tried a simple USB thumbdrive connected to a powered hub connected to
the Host port. I tried to copy a file of 60 or 300 MB from the
thumbdrive to my home directory on the flash disk and it stalls after
approx 10-30 megabytes. After that, the whole USB hub doesn't work
anymore and the board needs to be rebooted. Another test does not need
the thumbdrive, only a powered hub connected to the USB host port (not
OTG) and a keyboard/mouse connected to this hub. Move the mouse
pointer during the chameleon man demo (you will see that it has an
impact on the speed of the demo), after a while (a minute or so), the
hub loses connection and can only be activated after rebooting the
beagleboard.
regards, Eelco
tried a simple USB thumbdrive connected to a powered hub connected to
the Host port. I tried to copy a file of 60 or 300 MB from the
thumbdrive to my home directory on the flash disk and it stalls after
approx 10-30 megabytes. After that, the whole USB hub doesn't work
anymore and the board needs to be rebooted. Another test does not need
the thumbdrive, only a powered hub connected to the USB host port (not
OTG) and a keyboard/mouse connected to this hub. Move the mouse
pointer during the chameleon man demo (you will see that it has an
impact on the speed of the demo), after a while (a minute or so), the
hub loses connection and can only be activated after rebooting the
beagleboard.
regards, Eelco
John Beetem
Apr 24, 2009, 12:41:07 PM4/24/09
to Beagle Board
Eelco:
If you want to force the OTG port into host mode and only have a Mini-
B cable, you can short OTG connector pins 4 and 5 together with a
probe or a pin while you're booting Linux. Once the boot is complete,
you can remove the short. There is a photo of which pins to short at:
http://elinux.org/BeagleBoard#OTG
Hope this helps,
John
If you want to force the OTG port into host mode and only have a Mini-
B cable, you can short OTG connector pins 4 and 5 together with a
probe or a pin while you're booting Linux. Once the boot is complete,
you can remove the short. There is a photo of which pins to short at:
http://elinux.org/BeagleBoard#OTG
Hope this helps,
John
Gerald Coley
Apr 24, 2009, 2:23:23 PM4/24/09
to beagl...@googlegroups.com
Rev C2 has a shorting pist on it that you can solder a wire or blob some solder across it an accomplish the same thing.
Gerald
John Beetem
Apr 24, 2009, 7:23:13 PM4/24/09
to Beagle Board
Gerald,
Thank you for adding the shorting point J6 to Rev C2. I found J6 in
the BeagleBoard System Reference Manual C2.2 text and schematics, but
for some reason I can't find it in the Rev C2 photo or silkscreens. I
don't have a Rev C board myself. Can someone tell me where J6 is on
the Rev C2 board for future reference?
Thanks,
John
Thank you for adding the shorting point J6 to Rev C2. I found J6 in
the BeagleBoard System Reference Manual C2.2 text and schematics, but
for some reason I can't find it in the Rev C2 photo or silkscreens. I
don't have a Rev C board myself. Can someone tell me where J6 is on
the Rev C2 board for future reference?
Thanks,
John
Gerald Coley
Apr 24, 2009, 9:17:20 PM4/24/09
to beagl...@googlegroups.com
It is between J2 and the OTG connector on the back side of the board. All of the Gerbers and Allegro files are now on the website.
Gerald
Gerald Coley
Apr 24, 2009, 9:19:13 PM4/24/09
to beagl...@googlegroups.com
And, you can also find in in Figure 20 of the System Reference Manual. It is in the upper left hand corner of the picture.
Gerald
On Fri, Apr 24, 2009 at 6:23 PM, John Beetem <johnb...@yahoo.com> wrote:
chung
Apr 25, 2009, 2:17:29 AM4/25/09
to Beagle Board
Same here with RevC2 and Sakoman 20090416 build. The hub is self-
powered and attached with keyboard, mouse, ethernet and 8g flash
stick. The disconnections occur randomly. No problem if the hub is
connected to OTG port with 2.6.28 kernel(from rcn-ee.com and ubuntu
9.04, it seems you don't need to short JP6 to ground to enable OTG
host mode in kernel 2.6.28)
Chung
powered and attached with keyboard, mouse, ethernet and 8g flash
stick. The disconnections occur randomly. No problem if the hub is
connected to OTG port with 2.6.28 kernel(from rcn-ee.com and ubuntu
9.04, it seems you don't need to short JP6 to ground to enable OTG
host mode in kernel 2.6.28)
Chung
eelcor
Apr 25, 2009, 8:27:41 AM4/25/09
to Beagle Board
Søren,
I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
4.82-4.83 volts, sometimes it dips a little bit during the chameleon
man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
increases to 4.87. During the voltage dip the framerate of the
chameleon man demo drops as well (this also happens when moving the
mouse). Any ideas?
Kind regards, Eelco
> > Eric- Tekst uit oorspronkelijk bericht niet weergeven -
I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
4.82-4.83 volts, sometimes it dips a little bit during the chameleon
man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
increases to 4.87. During the voltage dip the framerate of the
chameleon man demo drops as well (this also happens when moving the
mouse). Any ideas?
Kind regards, Eelco
Søren Steen Christensen
Apr 25, 2009, 8:43:45 AM4/25/09
to beagl...@googlegroups.com
> I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
> 4.82-4.83 volts, sometimes it dips a little bit during the chameleon
> man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
> increases to 4.87. During the voltage dip the framerate of the
> chameleon man demo drops as well (this also happens when moving the
> mouse). Any ideas?
Hi Eelco,> 4.82-4.83 volts, sometimes it dips a little bit during the chameleon
> man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
> increases to 4.87. During the voltage dip the framerate of the
> chameleon man demo drops as well (this also happens when moving the
> mouse). Any ideas?
DMM = Digital Multi Meter?
Voltage drops of 0.02V wouldn't concern me. The voltage of 4.82V is a bit
low, but as well not scaring. I guess, that the reason why the voltage
increase after the error is, that the hub stops drawing current => Voltage
increases to unloaded level ~4.9V (ideal 5V)...
In case DMM is a Digital Multi Meter I'm afraid, you can't catch/see what
I'm searching for, since they normally contains some kind of low-pass filter
and thereby won't show spikes where the voltage might i.e. drop or rise
drastically (several volts) due to some kind of yet unknown reason... Can
you gain access to an oscilloscope?
As stated previously I have no arguments, that this should actually be the
case, but would just like to rule out this possibility completely since it
seems to be some kind of HW related issue since not everybody is
experiencing this problem... :-)
I myself unfortunately don't have a Rev C board for testing/measuring
myself...
Steve Sakoman
Apr 25, 2009, 8:54:22 AM4/25/09
to beagl...@googlegroups.com
On Sat, Apr 25, 2009 at 5:27 AM, eelcor <eelco...@gmail.com> wrote:
>
> Søren,
>
> I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
> 4.82-4.83 volts, sometimes it dips a little bit during the chameleon
> man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
> increases to 4.87. During the voltage dip the framerate of the
> chameleon man demo drops as well (this also happens when moving the
> mouse). Any ideas?
You might want to flip your multimeter to AC mode and see what the AC
>
> Søren,
>
> I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
> 4.82-4.83 volts, sometimes it dips a little bit during the chameleon
> man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
> increases to 4.87. During the voltage dip the framerate of the
> chameleon man demo drops as well (this also happens when moving the
> mouse). Any ideas?
component of the signal is. If it is more than a few tenths on a volt
this may be your issue. I have seen that many inexpensive hubs have
little/no filtering of V_BUS. I'm not sure what the output cap is on
rev C Beagles, but perhaps it is a tad small.
If the AC component is reasonable, perhaps you could try the kernel
from my latest build:
http://www.sakoman.com/feeds/omap3/glibc/images/beagleboard/200904242040/
I enabled the following config option:
config USB_EHCI_TT_NEWSCHED
bool "Improved Transaction Translator scheduling (EXPERIMENTAL)"
depends on USB_EHCI_HCD && EXPERIMENTAL
---help---
This changes the periodic scheduling code to fill more of the low
and full speed bandwidth available from the Transaction Translator
(TT) in USB 2.0 hubs. Without this, only one transfer will be
issued in each microframe, significantly reducing the number of
periodic low/fullspeed transfers possible.
If you have multiple periodic low/fullspeed devices connected to a
highspeed USB hub which is connected to a highspeed USB Host
Controller, and some of those devices will not work correctly
(possibly due to "ENOSPC" or "-28" errors), say Y.
It has no negative effects in my testing, and I kind of doubt it will
fix your issue, but it is worth a try.
Steve
eelcor
Apr 25, 2009, 8:59:27 AM4/25/09
to Beagle Board
Let's see if I can find something using my oscilloscope. I have been
using a digital multimeter to see if the state changes, now I will
look for some spikes. Other suggestions for measurement points?
Regards, Eelco
On Apr 25, 2:43 pm, Søren Steen Christensen
using a digital multimeter to see if the state changes, now I will
look for some spikes. Other suggestions for measurement points?
Regards, Eelco
On Apr 25, 2:43 pm, Søren Steen Christensen
eelcor
Apr 25, 2009, 9:42:47 AM4/25/09
to Beagle Board
Okay, I tried to see whether V_bus changes during the lockup of the
hub. I see some ripples on the oscilloscope during using my mouse
(these are minimal, approx. 0.01 volts) and there is no clear evidence
when the port locks up. V_bus doesn't show any signs of spikes or
sudden lows. Somehow it feels like some kind of timing issue...
> > Søren- Tekst uit oorspronkelijk bericht niet weergeven -
hub. I see some ripples on the oscilloscope during using my mouse
(these are minimal, approx. 0.01 volts) and there is no clear evidence
when the port locks up. V_bus doesn't show any signs of spikes or
sudden lows. Somehow it feels like some kind of timing issue...
Steve Sakoman
Apr 25, 2009, 9:27:50 AM4/25/09
to beagl...@googlegroups.com
On Sat, Apr 25, 2009 at 5:54 AM, Steve Sakoman <sak...@gmail.com> wrote:
> On Sat, Apr 25, 2009 at 5:27 AM, eelcor <eelco...@gmail.com> wrote:
>>
>> Søren,
>>
>> I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
>> 4.82-4.83 volts, sometimes it dips a little bit during the chameleon
>> man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
>> increases to 4.87. During the voltage dip the framerate of the
>> chameleon man demo drops as well (this also happens when moving the
>> mouse). Any ideas?
>
> You might want to flip your multimeter to AC mode and see what the AC
> component of the signal is. If it is more than a few tenths on a volt
> this may be your issue. I have seen that many inexpensive hubs have
> little/no filtering of V_BUS. I'm not sure what the output cap is on
> rev C Beagles, but perhaps it is a tad small.
> On Sat, Apr 25, 2009 at 5:27 AM, eelcor <eelco...@gmail.com> wrote:
>>
>> Søren,
>>
>> I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
>> 4.82-4.83 volts, sometimes it dips a little bit during the chameleon
>> man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
>> increases to 4.87. During the voltage dip the framerate of the
>> chameleon man demo drops as well (this also happens when moving the
>> mouse). Any ideas?
>
> You might want to flip your multimeter to AC mode and see what the AC
> component of the signal is. If it is more than a few tenths on a volt
> this may be your issue. I have seen that many inexpensive hubs have
> little/no filtering of V_BUS. I'm not sure what the output cap is on
> rev C Beagles, but perhaps it is a tad small.
Looking at the Rev C schematics, I see that the V_BUS cap is 100uf,
which should be just fine.
It will still be interesting to see what you find using a scope.
Perhaps the issue is the power source for your Beagle.
Steve
eelcor
Apr 25, 2009, 11:08:31 AM4/25/09
to Beagle Board
For the power source, I have used many different options, ranging from
powering the OTG port to 3 different power bricks and a combination of
both USB and OTG. Somehow I'm starting to think that it's not a
voltage issue but some kind of timing issue. The scope showed some
moderate ripples (unfortunately not possible to take relevant
pictures), but these stayed in the reasonable range. Your suggestion
for the power supply sounds plausible although I really don't know
which powersupply I should use now.
I am going to try Steve's new build. Are there any changes?
Regards, Eelco
On 25 apr, 15:27, Steve Sakoman <sako...@gmail.com> wrote:
> On Sat, Apr 25, 2009 at 5:54 AM, Steve Sakoman <sako...@gmail.com> wrote:
powering the OTG port to 3 different power bricks and a combination of
both USB and OTG. Somehow I'm starting to think that it's not a
voltage issue but some kind of timing issue. The scope showed some
moderate ripples (unfortunately not possible to take relevant
pictures), but these stayed in the reasonable range. Your suggestion
for the power supply sounds plausible although I really don't know
which powersupply I should use now.
I am going to try Steve's new build. Are there any changes?
Regards, Eelco
On 25 apr, 15:27, Steve Sakoman <sako...@gmail.com> wrote:
> On Sat, Apr 25, 2009 at 5:54 AM, Steve Sakoman <sako...@gmail.com> wrote:
> > On Sat, Apr 25, 2009 at 5:27 AM, eelcor <eelco.r...@gmail.com> wrote:
>
> >> Søren,
>
> >> I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
> >> 4.82-4.83 volts, sometimes it dips a little bit during the chameleon
> >> man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
> >> increases to 4.87. During the voltage dip the framerate of the
> >> chameleon man demo drops as well (this also happens when moving the
> >> mouse). Any ideas?
>
> > You might want to flip your multimeter to AC mode and see what the AC
> > component of the signal is. If it is more than a few tenths on a volt
> > this may be your issue. I have seen that many inexpensive hubs have
> > little/no filtering of V_BUS. I'm not sure what the output cap is on
> > rev C Beagles, but perhaps it is a tad small.
>
> Looking at the Rev C schematics, I see that the V_BUS cap is 100uf,
> which should be just fine.
>
> It will still be interesting to see what you find using a scope.
> Perhaps the issue is the power source for your Beagle.
>
> Steve- Tekst uit oorspronkelijk bericht niet weergeven -
>
> >> Søren,
>
> >> I have picked up a DMM and measured V_BUS. The V_BUS voltage is around
> >> 4.82-4.83 volts, sometimes it dips a little bit during the chameleon
> >> man demo (approx 0.02 volts) and when the hub disconnects, V_BUS
> >> increases to 4.87. During the voltage dip the framerate of the
> >> chameleon man demo drops as well (this also happens when moving the
> >> mouse). Any ideas?
>
> > You might want to flip your multimeter to AC mode and see what the AC
> > component of the signal is. If it is more than a few tenths on a volt
> > this may be your issue. I have seen that many inexpensive hubs have
> > little/no filtering of V_BUS. I'm not sure what the output cap is on
> > rev C Beagles, but perhaps it is a tad small.
>
> Looking at the Rev C schematics, I see that the V_BUS cap is 100uf,
> which should be just fine.
>
> It will still be interesting to see what you find using a scope.
> Perhaps the issue is the power source for your Beagle.
>
John Beetem
Apr 25, 2009, 12:49:17 PM4/25/09
to Beagle Board
Gerald: thank you for directing me to J6.
All: I would be very surprised if the problem is V_bus. You can
certainly get glitches on that when hot-swapping a cheap hub or a
plugging a device into a cheap hub, but I would not suspect any
voltage problems once a device is up and running.
Since multiple Beaglers have seen the same problem, I would suspect a
subtle race condition in the Host USB driver. Any time you have
interrupt-driven software you have to be very careful with all shared
variables. This is particularly nasty with a RISC processor where
incrementing a variable that's in memory is usually not an atomic
operation: it's a LOAD + register ADD + STORE. If an interrupt occurs
between the LOAD and STORE and the interrupt service routine modifies
the same variable, you end up with an inconsistent result. This is
incredibly hard to reproduce since the chance of observing it in
normal operation is tiny. However, if you exercise the driver with a
long transfer, your chance of observing the hazard becomes
significant. (I once had an problem like this in an embedded system
that was only observable after several hours and only if the product
was in a high-temp environment.)
The easiest solution to incrementing a shared variable is to suspend
interrupts while incrementing it. It is only one simple example of
the many possible shared variable hazards that can occur.
Anyone know how much of the code is shared between the OTG and Host
Port drivers?
All: I would be very surprised if the problem is V_bus. You can
certainly get glitches on that when hot-swapping a cheap hub or a
plugging a device into a cheap hub, but I would not suspect any
voltage problems once a device is up and running.
Since multiple Beaglers have seen the same problem, I would suspect a
subtle race condition in the Host USB driver. Any time you have
interrupt-driven software you have to be very careful with all shared
variables. This is particularly nasty with a RISC processor where
incrementing a variable that's in memory is usually not an atomic
operation: it's a LOAD + register ADD + STORE. If an interrupt occurs
between the LOAD and STORE and the interrupt service routine modifies
the same variable, you end up with an inconsistent result. This is
incredibly hard to reproduce since the chance of observing it in
normal operation is tiny. However, if you exercise the driver with a
long transfer, your chance of observing the hazard becomes
significant. (I once had an problem like this in an embedded system
that was only observable after several hours and only if the product
was in a high-temp environment.)
The easiest solution to incrementing a shared variable is to suspend
interrupts while incrementing it. It is only one simple example of
the many possible shared variable hazards that can occur.
Anyone know how much of the code is shared between the OTG and Host
Port drivers?
Søren Steen Christensen
Apr 25, 2009, 1:25:28 PM4/25/09
to beagl...@googlegroups.com
> All: I would be very surprised if the problem is V_bus. You can
> certainly get glitches on that when hot-swapping a cheap hub or a
> plugging a device into a cheap hub, but I would not suspect any
> voltage problems once a device is up and running.
> certainly get glitches on that when hot-swapping a cheap hub or a
> plugging a device into a cheap hub, but I would not suspect any
> voltage problems once a device is up and running.
Agree there shouldn't be any glitches when the system is up running. We
however didn't knew this was the case for sure for the failing boards- There
might had been some kind of strange HW problem. But thanks to Eelcor
measurements today we can now totally rule out this possibility... :-)
> Since multiple Beaglers have seen the same problem, I would suspect a
> subtle race condition in the Host USB driver. Any time you have
> interrupt-driven software you have to be very careful with all shared
> variables. This is particularly nasty with a RISC processor where
> incrementing a variable that's in memory is usually not an atomic
> operation: it's a LOAD + register ADD + STORE. If an interrupt occurs
> between the LOAD and STORE and the interrupt service routine modifies
> the same variable, you end up with an inconsistent result. This is
> incredibly hard to reproduce since the chance of observing it in
> normal operation is tiny. However, if you exercise the driver with a
> long transfer, your chance of observing the hazard becomes
> significant.
Hi John,
I agree that ISR's and shared variables can cause trouble :-). I although
don't expect this to be the main reason in this case. Main reason for this
is, that Eelcor can provoke the error every time within few minutes (1 or 2
minutes - Right?), while Steve have tried for several hours with no luck at
all. I my world this points in the direction of a somehow HW related
problem...
In order to be 100% sure if it's a pure SW problem or not, I would suggest
Eelcor to write a 100% step by step description of what to do in order to
provoke the error. Including full path to images, MMC card type/size, USB
hub name, U-boot and x-loader version, etc... We need to 100% dummy step by
step guide to be 100% sure, that everybody is testing the *exact* same use
case...
Then other people can redo the exact same steps and see if they can provoke
the problem. In this case, I agree it's most likely a pure SW error. In case
they still can't provoke it, I suspect some kind of HW dependency to be
involved as well...
Best regards
Søren
eelcor
Apr 25, 2009, 2:07:49 PM4/25/09
to Beagle Board
Sounds like a plan.
Let's see:
First of all I installed Steve's latest build (24 april 09) on a 8 GB
Sandisk Extreme II SD card. I use the desktop image. After installing
I wait for the distro to be configured (first boot) and I choose the
minimalist theme (just for the record, the error occurs regardless of
themes). I use the version of u-boot supplied with the build and after
erasing the environment variables I supply omapfb.mode=dvi:
1280x768-16@60 (just for the record, other resolutions also give
problems). The rest is kept clean without modifications.
I have a logitech pocket USB hub powered by a 2A power supply.
The beagleboard is powered using an iPod charger (1A supply) using the
OTG port.
The hub is attached to the beagleboard using a good quality cable and
it's attached to the EHCI port (host port).
I have a serial cable attached to the board (just for the record, the
error occurs also without the serial port)
I've attached a logitech wireless keyboard and mouse to the hub.
After setting up everything according to the above, there are two ways
to provoke the error:
1. Running the Chameleon man demo and moving the mouse during the demo
- After approx 1-2 minutes the lights from the hub go out and the
serial console shows multiple errors with the USB hub (see one of my
earlier posts). I've also run the Chameleon man without moving the
mouse and it still happens (it only takes longer). After the hub is
disconnected the demo keeps on running, but I am not able to use the
keyboard or the mouse anymore (need to reboot).
2. Copying a large file (350MB divx file) from a USB key attached to
the powered hub. I have several fat32 formatted 4-8GB thumbdrives and
tried them all. After copying approx 30-60 MB the hub disconnects and
I can no longer use the keyboard and mouse. The hub is reconnected
after a reboot.
One important thing is that the beagleboard only loses connection to
the hub and the usb devices, but otherwise remains fully functional
(there is no system crash at all and the serial console still works).
I haven't been able to try the OTG port.
I hope this is detailed enough and it would be great to see others try
this as well.
Kind regards, Eelco
On 25 apr, 19:25, Søren Steen Christensen
Let's see:
First of all I installed Steve's latest build (24 april 09) on a 8 GB
Sandisk Extreme II SD card. I use the desktop image. After installing
I wait for the distro to be configured (first boot) and I choose the
minimalist theme (just for the record, the error occurs regardless of
themes). I use the version of u-boot supplied with the build and after
erasing the environment variables I supply omapfb.mode=dvi:
1280x768-16@60 (just for the record, other resolutions also give
problems). The rest is kept clean without modifications.
I have a logitech pocket USB hub powered by a 2A power supply.
The beagleboard is powered using an iPod charger (1A supply) using the
OTG port.
The hub is attached to the beagleboard using a good quality cable and
it's attached to the EHCI port (host port).
I have a serial cable attached to the board (just for the record, the
error occurs also without the serial port)
I've attached a logitech wireless keyboard and mouse to the hub.
After setting up everything according to the above, there are two ways
to provoke the error:
1. Running the Chameleon man demo and moving the mouse during the demo
- After approx 1-2 minutes the lights from the hub go out and the
serial console shows multiple errors with the USB hub (see one of my
earlier posts). I've also run the Chameleon man without moving the
mouse and it still happens (it only takes longer). After the hub is
disconnected the demo keeps on running, but I am not able to use the
keyboard or the mouse anymore (need to reboot).
2. Copying a large file (350MB divx file) from a USB key attached to
the powered hub. I have several fat32 formatted 4-8GB thumbdrives and
tried them all. After copying approx 30-60 MB the hub disconnects and
I can no longer use the keyboard and mouse. The hub is reconnected
after a reboot.
One important thing is that the beagleboard only loses connection to
the hub and the usb devices, but otherwise remains fully functional
(there is no system crash at all and the serial console still works).
I haven't been able to try the OTG port.
I hope this is detailed enough and it would be great to see others try
this as well.
Kind regards, Eelco
On 25 apr, 19:25, Søren Steen Christensen
eelcor
Apr 25, 2009, 2:10:00 PM4/25/09
to Beagle Board
My X-loader is version 1.4.2 (19th of february)
regards, Eelco
On 25 apr, 19:25, Søren Steen Christensen
regards, Eelco
On 25 apr, 19:25, Søren Steen Christensen
Steve Sakoman
Apr 25, 2009, 3:13:58 PM4/25/09
to beagl...@googlegroups.com
On Sat, Apr 25, 2009 at 11:07 AM, eelcor <eelco...@gmail.com> wrote:
>
> Sounds like a plan.
>
> Let's see:
>
> First of all I installed Steve's latest build (24 april 09) on a 8 GB
> Sandisk Extreme II SD card. I use the desktop image. After installing
> I wait for the distro to be configured (first boot) and I choose the
> minimalist theme (just for the record, the error occurs regardless of
> themes). I use the version of u-boot supplied with the build and after
> erasing the environment variables I supply omapfb.mode=dvi:
> 1280x768-16@60 (just for the record, other resolutions also give
> problems). The rest is kept clean without modifications.
>
> I have a logitech pocket USB hub powered by a 2A power supply.
> The beagleboard is powered using an iPod charger (1A supply) using the
> OTG port.
I'm powering my Beagle through the barrel connector with a 3A 5V
>
> Sounds like a plan.
>
> Let's see:
>
> First of all I installed Steve's latest build (24 april 09) on a 8 GB
> Sandisk Extreme II SD card. I use the desktop image. After installing
> I wait for the distro to be configured (first boot) and I choose the
> minimalist theme (just for the record, the error occurs regardless of
> themes). I use the version of u-boot supplied with the build and after
> erasing the environment variables I supply omapfb.mode=dvi:
> 1280x768-16@60 (just for the record, other resolutions also give
> problems). The rest is kept clean without modifications.
>
> I have a logitech pocket USB hub powered by a 2A power supply.
> The beagleboard is powered using an iPod charger (1A supply) using the
> OTG port.
supply and V_BUS is a solid 5.04V. It does not seem to vary with
activity.
Steve
Søren Steen Christensen
Apr 25, 2009, 4:49:09 PM4/25/09
to beagl...@googlegroups.com
> Sakoman wrote:
> I'm powering my Beagle through the barrel connector with a 3A 5V supply
and
> V_BUS is a solid 5.04V. It does not seem to vary with activity.
> I'm powering my Beagle through the barrel connector with a 3A 5V supply
and
> V_BUS is a solid 5.04V. It does not seem to vary with activity.
Just realized, that the V_BUS is basically directly connected (through a
switch) to the DC_5V net. =>
The difference from 4.9 to 5.04V can most likely be tracked all the way back
to the power supply supplying the board...
> Eelcor wrote:
> Other suggestions for measurement points?
One far guess for another measuring point is: RBIAS on R52.
As far as I can read it's supposed to be 0.8V during normal operation.
A other idea could be to try to check the VBAT and VIO_1V8 near to the balls
C1 and B3 of the USB transceiver (USB3322). Alternatively - Try to increase
C104 and C106 to 10uF each...
chung
Apr 25, 2009, 9:38:08 PM4/25/09
to Beagle Board
I have tried different combination of accessories connected to BB to
see how they trigger the disconnection problem. The below is the list
of accessories I used to test BB.
A - 4 ports hub self-powered (2A PS) (unknow brand,US$5 value)
B - 7 Ports hub self-powered (2A PS) (unknow brand,US$5 value)
C - Sony optical mouse
D - Philips wireless optical mouse
E - Logitech Netplay keyboard
F - Rapoo wireless keyboard/mouse
G - Sandisk Cruzer Micro 8G flash stick
H - USB ethernet adapter (unkow brand,US$5 value)
I - TP-Link TL-WN321G WIFI adapter
So far, the only stable combination is A+F+G+I, will try other
combinations
chung
see how they trigger the disconnection problem. The below is the list
of accessories I used to test BB.
A - 4 ports hub self-powered (2A PS) (unknow brand,US$5 value)
B - 7 Ports hub self-powered (2A PS) (unknow brand,US$5 value)
C - Sony optical mouse
D - Philips wireless optical mouse
E - Logitech Netplay keyboard
F - Rapoo wireless keyboard/mouse
G - Sandisk Cruzer Micro 8G flash stick
H - USB ethernet adapter (unkow brand,US$5 value)
I - TP-Link TL-WN321G WIFI adapter
So far, the only stable combination is A+F+G+I, will try other
combinations
chung
eelcor
Apr 26, 2009, 5:55:30 AM4/26/09
to Beagle Board
I've tried the approach of Chung and replaced one item I did'n replace
earlier, namely the keyboard and mouse. It seems to have improved the
stability dramatically. I have changed the el-cheapo logitech combo
with a more sophisticated Microsoft set. The chameleon man seems to be
running a bit longer. I have to test it more extensively to see
whether this solves something.
I still have the problem copying things from a USB stick to the MMC
card, it seems to be depending on the brand and kind of stick. Some
sticks immediately give errors, while others give some time...
I am going to try more...
Regards, Eelco
earlier, namely the keyboard and mouse. It seems to have improved the
stability dramatically. I have changed the el-cheapo logitech combo
with a more sophisticated Microsoft set. The chameleon man seems to be
running a bit longer. I have to test it more extensively to see
whether this solves something.
I still have the problem copying things from a USB stick to the MMC
card, it seems to be depending on the brand and kind of stick. Some
sticks immediately give errors, while others give some time...
I am going to try more...
Regards, Eelco
eelcor
Apr 26, 2009, 6:00:03 AM4/26/09
to Beagle Board
Well my earlier post was wishful thinking... Still having the same
problems...
> > - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk bericht niet weergeven -
problems...
Frans Meulenbroeks
Apr 26, 2009, 6:17:52 AM4/26/09
to beagl...@googlegroups.com
2009/4/26 eelcor <eelco...@gmail.com>:
>
> I've tried the approach of Chung and replaced one item I did'n replace
> earlier, namely the keyboard and mouse. It seems to have improved the
> stability dramatically. I have changed the el-cheapo logitech combo
> with a more sophisticated Microsoft set. The chameleon man seems to be
> running a bit longer. I have to test it more extensively to see
> whether this solves something.
>
>
> I've tried the approach of Chung and replaced one item I did'n replace
> earlier, namely the keyboard and mouse. It seems to have improved the
> stability dramatically. I have changed the el-cheapo logitech combo
> with a more sophisticated Microsoft set. The chameleon man seems to be
> running a bit longer. I have to test it more extensively to see
> whether this solves something.
>
Try to disconnect kbd and mouse and see if that helps. (if you have
serial, you can use serial to connect, if not start an ssh session to
your beagle).
For me mouse is working but kbd is not (although once I managed to get
it working, but could not reproduce that).
I think this is a driver issue somewhere.
usb on beagle still has some issues (see an earlier post from me).
FM
chung
Apr 26, 2009, 6:25:29 AM4/26/09
to Beagle Board
At least in my case, the Rapoo wireless keyboard/mouse + TL WIFI
adapter give me a stable setup to run 3D demo, video playback and web
browsing. It seems the fewer loading to the hub, the more stable.
Chung
adapter give me a stable setup to run 3D demo, video playback and web
browsing. It seems the fewer loading to the hub, the more stable.
Chung
Frans Meulenbroeks
Apr 26, 2009, 7:35:34 AM4/26/09
to beagl...@googlegroups.com
2009/4/26 chung <chun...@netvigator.com>:
>
> At least in my case, the Rapoo wireless keyboard/mouse + TL WIFI
> adapter give me a stable setup to run 3D demo, video playback and web
> browsing. It seems the fewer loading to the hub, the more stable.
>
> Chung
>
> At least in my case, the Rapoo wireless keyboard/mouse + TL WIFI
> adapter give me a stable setup to run 3D demo, video playback and web
> browsing. It seems the fewer loading to the hub, the more stable.
>
> Chung
This could indicate that the quality of the power supply of the hub is
an important factor.
A thing to try is to cascade two powered hubs and use the 2nd one.
Assumption for this test is that the first hub will dampen power
transients that one way or another occur on the input of the 2nd hub.
FM.
chung
Apr 26, 2009, 11:15:51 AM4/26/09
to Beagle Board
I have tried your suggestion that connected a second self-powered hub
to the primary hub, the disconnection still occur. The strange thing
is that some combination of accessories didn't work when connected to
host port (Sakoman kernel and rootfs) but work well with OTG port(have
to use kernel 2.6.28 from www.rcn-ee.com and ubuntu 9.04 rootfs)
Chung
On Apr 26, 7:35 pm, Frans Meulenbroeks <fransmeulenbro...@gmail.com>
wrote:
> 2009/4/26 chung <chung...@netvigator.com>:
to the primary hub, the disconnection still occur. The strange thing
is that some combination of accessories didn't work when connected to
host port (Sakoman kernel and rootfs) but work well with OTG port(have
to use kernel 2.6.28 from www.rcn-ee.com and ubuntu 9.04 rootfs)
Chung
On Apr 26, 7:35 pm, Frans Meulenbroeks <fransmeulenbro...@gmail.com>
wrote:
> 2009/4/26 chung <chung...@netvigator.com>:
eelcor
Apr 26, 2009, 3:32:55 PM4/26/09
to Beagle Board
Hmmm, I'm really confused at this moment. Should I RMA the board or
not?
Regards, Eelco
On 26 apr, 17:15, chung <chung...@netvigator.com> wrote:
> I have tried your suggestion that connected a second self-powered hub
> to the primary hub, the disconnection still occur. The strange thing
> is that some combination of accessories didn't work when connected to
> host port (Sakoman kernel and rootfs) but work well with OTG port(have
> to use kernel 2.6.28 fromwww.rcn-ee.comand ubuntu 9.04 rootfs)
not?
Regards, Eelco
On 26 apr, 17:15, chung <chung...@netvigator.com> wrote:
> I have tried your suggestion that connected a second self-powered hub
> to the primary hub, the disconnection still occur. The strange thing
> is that some combination of accessories didn't work when connected to
> host port (Sakoman kernel and rootfs) but work well with OTG port(have
>
> Chung
>
> On Apr 26, 7:35 pm, Frans Meulenbroeks <fransmeulenbro...@gmail.com>
> wrote:
>
>
>
> > 2009/4/26 chung <chung...@netvigator.com>:
>
> > > At least in my case, the Rapoo wireless keyboard/mouse + TL WIFI
> > > adapter give me a stable setup to run 3D demo, video playback and web
> > > browsing. It seems the fewer loading to the hub, the more stable.
>
> > > Chung
>
> > This could indicate that the quality of the power supply of the hub is
> > an important factor.
> > A thing to try is to cascade two powered hubs and use the 2nd one.
> > Assumption for this test is that the first hub will dampen power
> > transients that one way or another occur on the input of the 2nd hub.
>
> > FM.- Tekst uit oorspronkelijk bericht niet weergeven -
> Chung
>
> On Apr 26, 7:35 pm, Frans Meulenbroeks <fransmeulenbro...@gmail.com>
> wrote:
>
>
>
> > 2009/4/26 chung <chung...@netvigator.com>:
>
> > > At least in my case, the Rapoo wireless keyboard/mouse + TL WIFI
> > > adapter give me a stable setup to run 3D demo, video playback and web
> > > browsing. It seems the fewer loading to the hub, the more stable.
>
> > > Chung
>
> > This could indicate that the quality of the power supply of the hub is
> > an important factor.
> > A thing to try is to cascade two powered hubs and use the 2nd one.
> > Assumption for this test is that the first hub will dampen power
> > transients that one way or another occur on the input of the 2nd hub.
>
thierry
Apr 26, 2009, 4:52:26 PM4/26/09
to Beagle Board
Hello,
A "hardware" friend of mine suspects the CLKOUT signal of USB
controler (USB3322 - U7) who should be connected to the OMAP, because
it explains me that "it's USB controler to provide clock for command
bus, not the opposite".
Best regards to all guys, hardware expert enough to check that.
On Apr 26, 9:32 pm, eelcor <eelco.r...@gmail.com> wrote:
> Hmmm, I'm really confused at this moment. Should I RMA the board or
> not?
>
> Regards, Eelco
>
> On 26 apr, 17:15, chung <chung...@netvigator.com> wrote:
>
> > I have tried your suggestion that connected a second self-powered hub
> > to the primary hub, the disconnection still occur. The strange thing
> > is that some combination of accessories didn't work when connected to
> > host port (Sakoman kernel and rootfs) but work well with OTG port(have
> > to use kernel 2.6.28 fromwww.rcn-ee.comandubuntu 9.04 rootfs)
A "hardware" friend of mine suspects the CLKOUT signal of USB
controler (USB3322 - U7) who should be connected to the OMAP, because
it explains me that "it's USB controler to provide clock for command
bus, not the opposite".
Best regards to all guys, hardware expert enough to check that.
On Apr 26, 9:32 pm, eelcor <eelco.r...@gmail.com> wrote:
> Hmmm, I'm really confused at this moment. Should I RMA the board or
> not?
>
> Regards, Eelco
>
> On 26 apr, 17:15, chung <chung...@netvigator.com> wrote:
>
> > I have tried your suggestion that connected a second self-powered hub
> > to the primary hub, the disconnection still occur. The strange thing
> > is that some combination of accessories didn't work when connected to
> > host port (Sakoman kernel and rootfs) but work well with OTG port(have
Gerald Coley
Apr 26, 2009, 5:03:32 PM4/26/09
to beagl...@googlegroups.com
The OMAP3530 can only provide the clock on the EHCI ports to the external PHY. It cannot receive the clock from the PHY. The interface on the EHCI port is different than the OTG port. Feel free to read the OMAP3530 Technical Reference Manual for more details.
Gerald
John Beetem
Apr 27, 2009, 11:53:15 AM4/27/09
to Beagle Board
eelcor:
Have you tried making your flash drive the only device on the Host
USB, i.e., moving the low-speed devices to the OTG port?
Mixing high-speed and full/low-speed devices on the same USB requires
tricky USB 2.0 protocols with split transactions. Given the symptoms
reported by everyone above it's possible that some slow USB devices
can break high-speed split transactions whereas others don't (or do so
with a much lower probability), perhaps due to a timeout somewhere. I
don't know whether split transactions are implemented in the device
driver or in the USB controller hardware.
Just food for thought from someone who only knows enough about USB
internals to be dangerous. For more information, see Chapter 8 of the
USB 2.0 specification.
John
Have you tried making your flash drive the only device on the Host
USB, i.e., moving the low-speed devices to the OTG port?
Mixing high-speed and full/low-speed devices on the same USB requires
tricky USB 2.0 protocols with split transactions. Given the symptoms
reported by everyone above it's possible that some slow USB devices
can break high-speed split transactions whereas others don't (or do so
with a much lower probability), perhaps due to a timeout somewhere. I
don't know whether split transactions are implemented in the device
driver or in the USB controller hardware.
Just food for thought from someone who only knows enough about USB
internals to be dangerous. For more information, see Chapter 8 of the
USB 2.0 specification.
John
eelcor
Apr 27, 2009, 3:08:51 PM4/27/09
to Beagle Board
John,
I hoped that it was the case with the USB key and so I hopefully
directly connected the key to the beagleboard without a powered hub.
It took a while, while I was copying a 350MB file, but it didn't work.
These were the errors I received:
hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 2-2: USB disconnect, address 2
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 1666640
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 1666880
After that I got a FAT error all the way... I'm starting to get
desperate...
Regards, Eelco
I hoped that it was the case with the USB key and so I hopefully
directly connected the key to the beagleboard without a powered hub.
It took a while, while I was copying a 350MB file, but it didn't work.
These were the errors I received:
hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 2-2: USB disconnect, address 2
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 1666640
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 1666880
After that I got a FAT error all the way... I'm starting to get
desperate...
Regards, Eelco
Gerald Coley
Apr 27, 2009, 3:11:52 PM4/27/09
to beagl...@googlegroups.com
I would go ahead and request an RMA on the board.
Gerald
Reply all
Reply to author
Forward
0 new messages