without 'setenv serverip<something>' it will load from 0.0.0.0, which
does work, but upsets uboot greatly!
well even if that indeed solves your problem I think there is an other
problem as even with a correct IP configuration I meet the same timeout
problem when connected to a Gb switch
Did you confirm earlier that you got this working with a particular switch?
So are you saying that there is a problem on the Networking side? I
don't see how because its USB that timesout on a "receive" request. I
don't think this is the correct behavior of LAN9514, as it surely sets
one of the status registers when something goes wrong.
I checked all the MII registers and I don't see any problem there so I believe this is not a problem on the networking side at least on the PHY side because I didn't checked the MAC registers.
The only fact I can tell is that here on a 1Gb switch, USB timeouts are always present (even ping doesn't work) and on a 100/10 switch, USB timeouts are quite rare (and only appear during tftp transfers).
As I have other things to bring up and that the 9514 is just a debug tool in this project, I'm now on a 10/100 switch and I'm not investigating more on this issue.
At least we've got a bug which can be reproduced regardless of what's
between the beagle and the PC.
I tried also to stress test the beagle from user space, but it's stable
there - no complaints from the kernel with tftp -g -r uImage
192.168.5.5; ls -la
If you want me to test a patch just let me know;)
Regards,
Robert
..."As far as I know we never had an undetected error." - Anonymous
With this, the EHCI seems to "recover" from a timeout. This is particularly
observable if you were to ping the wrong IP Address and then ping the correct
one or if there was a temporary failure during tftp sessions.
All it takes is one timeout to disable it. If you have a noisy network (lot
of traffic), even if the traffic is not for the board, the timeouts don't occur.
---
Robert, Could you see if this patch solves the issue you're seeing without
increasing the timeout?
The tftp session retrieves the uImage with your patch and a timeout of 5000:
OMAP3 beagleboard.org # tftp 0x82000000 beagle-xm-rev-c/uImage
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.5.5; our IP address is 192.168.5.3
Filename 'beagle-xm-rev-c/uImage'.
Load address: 0x82000000
Loading: #################################################################
############################################################EHCI timed
out on TD - token=0x88008d80
T EHCI timed out on TD - token=0x88008d80
T EHCI timed out on TD - token=0x88008d80
T #####
###################################EHCI timed out on TD - token=0x88008d80
T EHCI timed out on TD - token=0x88008d80
T EHCI timed out on TD - token=0x88008d80
T #EHCI timed out on TD - token=0x88008d80
T ##############
done
Bytes transferred = 2632196 (282a04 hex)
OMAP3 beagleboard.org #
Regards,
Robert...fortune says today:There is no TRUTH. There is no REALITY.
There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS I'm very
probably wrong.
With this, the EHCI seems to "recover" from a timeout. This is particularly
observable if you were to ping the wrong IP Address and then ping the correct
one or if there was a temporary failure during tftp sessions.
All it takes is one timeout to disable it. If you have a noisy network (lot
of traffic), even if the traffic is not for the board, the timeouts don't occur.
Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com>
---
Robert, Could you see if this patch solves the issue you're seeing without
increasing the timeout?
Simon, Could this be a fix for a similar issue you were seeing with asix?
Yes this is better (ASIX can recover from a timeout), but I am
concerned that it carries on without reporting an error. Is that
right?
Should we disable async schedule and then return an error?
With respect to using a bulk USB stick (some of which take 3s or more
to respond to a submit) this doesn't make any difference for me. It
seems to take a long time to respond the first time, so the 5s timeout
seems prudent.
Since this sorts out the network side we can probably skip that patch.
