[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link
Jerry Van Baren
gerald.vanbaren at ge.com
Fri Feb 6 14:32:14 CET 2009
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 at denx.de> wrote:
>>> Dear Andy Fleming,
>>>
>>> In message <2acbd3e40902041320l3bce93c1p989c4c33ca8e7ae at 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:
> 1. Autonegotiation completed and link was detected
> 2. 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
More information about the U-Boot
mailing list