Peter Tyser wrote:
On Wed, 2009-02-04 at 17:07 -0600, Andy Fleming wrote:
On Wed, Feb 4, 2009 at 3:26 PM, Wolfgang Denk wd@denx.de wrote:
Dear Andy Fleming,
In message 2acbd3e40902041320l3bce93c1p989c4c33ca8e7ae@mail.gmail.com you wrote:
Hmmm....I made that change for a reason. Waiting for autonegotiation to finish on a tsec with no link was quite tiresome. If you've hooked up the 4th tsec, and try to boot, you end up waiting for *three* tsecs to timeout. If dhcp fails because the link isn't up you can always try again, or add a delay before dhcp starts so that the link is up.
Why that? Don't you always enable only the interface you are trying to use?
The problem is that you don't always know which interface you have hooked up. So u-boot tries the one set in ethact, and then the next, etc. With the old method, the penalty for being wrong was quite high. I hadn't run into an issue with the link not being up. Why don't we look up the spec, and find out the maximum time we'd have to wait for that to happen. That way we get the best of both worlds. My sense is that the link comes up fast, but autonegotiation potentially takes a while.
2 seconds minimum, it is written in the autonegotiation spec. If you add the spec-required minimum times for each step of the dance, it is 2 seconds. It could take longer, but I've never seen anything but 2 seconds.
My understanding was that link was was never achieved until autonegotiation was finished. How could link be up before autonegotiation was complete?
With the original code I always saw 1 of 2 situations with a variety of Broadcom PHYs:
- Autonegotiation completed and link was detected
- Autonegotiation was in process and link was not detected
I never saw the case that the code referenced: 3. Autonegotiation was in process and link was detected
Do others see #3?
Thanks, Peter
I never tried #3 personally, but my understanding of the link and autonegotiation dance is that #3 is not possible.
You may see what appears to be #3 *if* your PHY is strapped to start autonegotiation on application of power (typically true) and *if* you don't do a software reset on the PHY as part of your power up sequence (see also my previous email on this thread). This really isn't #3, it is... 4. Strap the PHY to autonegotiate on application of power and use the results from that rather than resetting the PHY and re-starting auto-negotiation in software.
Best regards, gvb