[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser]

Previously, waiting for auto-negotiation would only occur if a valid
link had been detected.  Problems arose when attempting to use a
tsec immediately after bootup but before link was achieved, eg:
=> dhcp
Auto-neg error, defaulting to 10BT/HD
eTSEC1: No link.
Auto-neg error, defaulting to 10BT/HD
eTSEC2: No link.
=>

With this patch applied the same operation as above resulted in:
=> dhcp
Waiting for PHY auto negotiation to complete. done
Enet starting in 1000BT/FD
Speed: 1000, full duplex

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---

 drivers/net/tsec.c |   19 +++++++++----------
 1 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index dc90f23..2e30fe9 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -352,8 +352,8 @@ uint mii_cr_init(uint mii_reg, struct tsec_private * priv)
 		return MIIM_CR_INIT;
 }
 
-/* Parse the status register for link, and then do
- * auto-negotiation
+/*
+ * Wait for auto-negotiation to complete, then determine link
  */
 uint mii_parse_sr(uint mii_reg, struct tsec_private * priv)
 {
@@ -362,8 +362,7 @@ uint mii_parse_sr(uint mii_reg, struct tsec_private * priv)
 	 * (ie - we're capable and it's not done)
 	 */
 	mii_reg = read_phy_reg(priv, MIIM_STATUS);
-	if ((mii_reg & MIIM_STATUS_LINK) && (mii_reg & PHY_BMSR_AUTN_ABLE)
-	    && !(mii_reg & PHY_BMSR_AUTN_COMP)) {
+	if ((mii_reg & PHY_BMSR_AUTN_ABLE) && !(mii_reg & PHY_BMSR_AUTN_COMP)) {
 		int i = 0;
 
 		puts("Waiting for PHY auto negotiation to complete");
@@ -384,15 +383,15 @@ uint mii_parse_sr(uint mii_reg, struct tsec_private * priv)
 			mii_reg = read_phy_reg(priv, MIIM_STATUS);
 		}
 		puts(" done\n");
-		priv->link = 1;
+
+		/* Link status bit is latched low, read it again */
+		mii_reg = read_phy_reg(priv, MIIM_STATUS);
+
 		udelay(500000);	/* another 500 ms (results in faster booting) */
-	} else {
-		if (mii_reg & MIIM_STATUS_LINK)
-			priv->link = 1;
-		else
-			priv->link = 0;
 	}
 
+	priv->link = mii_reg & MIIM_STATUS_LINK ? 1 : 0;
+
 	return 0;
 }
 
-- 
1.6.0.2.GIT

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Andy Fleming]

On Wed, Feb 4, 2009 at 3:14 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> Previously, waiting for auto-negotiation would only occur if a valid
> link had been detected.  Problems arose when attempting to use a
> tsec immediately after bootup but before link was achieved, eg:
> => dhcp
> Auto-neg error, defaulting to 10BT/HD
> eTSEC1: No link.
> Auto-neg error, defaulting to 10BT/HD
> eTSEC2: No link.
> =>

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.

I'm open to other suggestions, but I really don't want to go back to
the old behavior.

Andy

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Wolfgang Denk]

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?

That would be a bug that needs to be fixed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Unix: Some say the learning curve is steep,  but  you  only  have  to
climb it once.                                      - Karl Lehenbauer

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser]

On Wed, 2009-02-04 at 22:26 +0100, Wolfgang Denk 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?
> 
> That would be a bug that needs to be fixed.

It seems like the workaround for the "4 tsec autonegotiation delay" you
mention is to set a sane "ethact" value when you know which port you are
going to be using.  However, there is no good workaround for waiting for
link other than adding an arbitrary delay to the boot process which is
pretty hokey, thus the patch.

Best,
Peter

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Scott Wood]

Andy Fleming 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.
> 
> I'm open to other suggestions, but I really don't want to go back to
> the old behavior.

Is there any way that you could do the auto-negotiation in parallel?

Better yet if you could send bootp/dhcp requests to each one as it comes 
up, and abort the process upon the first valid bootp/dhcp reply.

-Scott

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Wolfgang Denk]

Dear Scott Wood,

In message <498A0D5C.5060901@freescale.com> you wrote:
> Andy Fleming 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.
> > 
> > I'm open to other suggestions, but I really don't want to go back to
> > the old behavior.
> 
> Is there any way that you could do the auto-negotiation in parallel?

You definitely do not want to do that.

Requirement is NOT to initialize network interfaces unless used by
U-Boot.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Objects in mirror are closer than they appear.

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Scott Wood]

Wolfgang Denk wrote:
> Dear Scott Wood,
> 
> In message <498A0D5C.5060901@freescale.com> you wrote:
>> Andy Fleming 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.
>>>
>>> I'm open to other suggestions, but I really don't want to go back to
>>> the old behavior.
>> Is there any way that you could do the auto-negotiation in parallel?
> 
> You definitely do not want to do that.
> 
> Requirement is NOT to initialize network interfaces unless used by
> U-Boot.

This would be in a case where the user *asks* for all the network 
interfaces to be used.  How is it different than the current behavior of 
rotating on a timeout?

-Scott

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Wolfgang Denk]

Dear Scott Wood,

In message <498A100E.4080807@freescale.com> you wrote:
>
> > Requirement is NOT to initialize network interfaces unless used by
> > U-Boot.
> 
> This would be in a case where the user *asks* for all the network 

This is impossible. U-Boot will always use only exactly one interfce
at a time. And before you initialize the next interface it is
required to shut down the previous one.

> interfaces to be used.  How is it different than the current behavior of 
> rotating on a timeout?

In that only one interface (maximum) is active all at any time.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The trouble with our times is that the future is not what it used  to
be.                                                     - Paul Valery

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Andy Fleming]

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.

Andy

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser]

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.

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

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Scott Wood,
> 
> In message <498A0D5C.5060901@freescale.com> you wrote:
>> Andy Fleming 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.
>>>
>>> I'm open to other suggestions, but I really don't want to go back to
>>> the old behavior.
>> Is there any way that you could do the auto-negotiation in parallel?

Excellent suggestion!

Related suggestion: if we knew that the PHY was strapped to start 
autonegotiation on power up (it is a board-specific option, typically 
true), we could enhance the code to use those autonegotiation results 
rather than hitting the PHY with the reset hammer and restarting 
autonegotiation.  This would have an added advantage of "reducing" 
network start up time by 2 seconds (assuming normal power up time is 
more than 2 seconds) by overlapping the software initialization and PHY 
autonegotiation.

> You definitely do not want to do that.
> 
> Requirement is NOT to initialize network interfaces unless used by
> U-Boot.

Autonegotiation is *not necessarily* a violation of this principle.  The 
autonegotiation is in the PHY and is (should be) logically completely 
separate from initializing the network interface (MAC).

Just because the PHY is ready to run should have no impact on u-boot or 
linux start up.  Case in point: most PHYs actually start their 
autonegotiation when power is applied (it typically is a strapping option).

Caveats:
* I have not looked at the code, but the PHY initialization is probably 
coupled in s/w with the MAC (ethernet chip) initialization.  This would 
have to be changed to decouple the two.

* Typically, PHYs have an interrupt output line.  I'm assuming here that 
the interrupt is disabled.  If the interrupt is *enabled,* it *would* 
violate u-boot's ground rule about not leaving hardware grenades laying 
around.  The interrupt can be disabled in the PHY itself or at the CPU 
end of the interrupt line.
   1) It would be very unusual to have the interrupt enabled in u-boot.
        I would be surprised if any PHY initialization enables the
        interrupt (it is a control bit in a register in the PHY,
        I forgot if it is a standard register or PHY-specific).
   2) If a PHY interrupt causes a problem in linux, it is a driver bug
        IMHO because it would mean the linux driver enabled the interrupt
        before initializing the handler.  This would be a race condition
        bug regardless of what u-boot does with the PHY and I trust none
        of these are present in linux.  ;-/

> Best regards,
> 
> Wolfgang Denk

Ditto,
gvb

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Jerry Van Baren]

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:
> 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

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Ben Warren]

Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>   
>> Dear Scott Wood,
>>
>> In message <498A0D5C.5060901@freescale.com> you wrote:
>>     
>>> Andy Fleming 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.
>>>>
>>>> I'm open to other suggestions, but I really don't want to go back to
>>>> the old behavior.
>>>>         
>>> Is there any way that you could do the auto-negotiation in parallel?
>>>       
>
> Excellent suggestion!
>
> Related suggestion: if we knew that the PHY was strapped to start 
> autonegotiation on power up (it is a board-specific option, typically 
> true), we could enhance the code to use those autonegotiation results 
> rather than hitting the PHY with the reset hammer and restarting 
> autonegotiation.  This would have an added advantage of "reducing" 
> network start up time by 2 seconds (assuming normal power up time is 
> more than 2 seconds) by overlapping the software initialization and PHY 
> autonegotiation.
>
>   
I think this is a good idea.  Serial autonegotiation is really such a 
time killer and has little to do with software, why not at least do a 
best effort attempt at letting all PHYs (or as many as the board 
developer feels like) autonegotiate as early in the process as possible?
>> You definitely do not want to do that.
>>
>> Requirement is NOT to initialize network interfaces unless used by
>> U-Boot.
>>     
>
> Autonegotiation is *not necessarily* a violation of this principle.  The 
> autonegotiation is in the PHY and is (should be) logically completely 
> separate from initializing the network interface (MAC).
>
> Just because the PHY is ready to run should have no impact on u-boot or 
> linux start up.  Case in point: most PHYs actually start their 
> autonegotiation when power is applied (it typically is a strapping option).
>
> Caveats:
> * I have not looked at the code, but the PHY initialization is probably 
> coupled in s/w with the MAC (ethernet chip) initialization.  This would 
> have to be changed to decouple the two.
>   
Currently, it depends greatly on the interface since each does its own 
thing.   I have some PHY-related development ongoing (phylib branch of 
the net tree) that leverages heavily from the Linux PHY drivers and some 
existing U-boot drivers that will let the user specify all sorts of 
things in board code.  I'd hoped to get it into the current release but 
that date's creeping up and  I'm low on time.  I hope to start RFCing it 
soon so in the following release we can migrate as many ethernet drivers 
as possible.  Anyway, with it we should be able to at least start AN via 
software in parallel, if desired of course.
> * Typically, PHYs have an interrupt output line.  I'm assuming here that 
> the interrupt is disabled.  If the interrupt is *enabled,* it *would* 
> violate u-boot's ground rule about not leaving hardware grenades laying 
> around.  The interrupt can be disabled in the PHY itself or at the CPU 
> end of the interrupt line.
>    1) It would be very unusual to have the interrupt enabled in u-boot.
>         I would be surprised if any PHY initialization enables the
>         interrupt (it is a control bit in a register in the PHY,
>         I forgot if it is a standard register or PHY-specific).
>    2) If a PHY interrupt causes a problem in linux, it is a driver bug
>         IMHO because it would mean the linux driver enabled the interrupt
>         before initializing the handler.  This would be a race condition
>         bug regardless of what u-boot does with the PHY and I trust none
>         of these are present in linux.  ;-/
>
>   
>> Best regards,
>>
>> Wolfgang Denk
>>     
>
> Ditto,
> gvb
>
> _________
Good discussion.

cheers,
Ben

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Andy Fleming]

On Fri, Feb 6, 2009 at 7:32 AM, Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
> Peter Tyser wrote:
>>

>>> 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.

Could you point me at where in the spec it says this?  I've been
digging around in it, and found nothing concrete so far.


>
>> My understanding was that link was was never achieved until
>> autonegotiation was finished.  How could link be up before
>> autonegotiation was complete?


Actually, as best I can tell, the link status is not well-defined.
The PHY designers are allowed to decide for themselves when the link
is considered "up".  The link state machine goes through several
states, and before auto-negotiation completes, the link can be in a
"READY" state.

Anyway, I'm fairly convinced that we can't assume the link will come
up, first, but I'd like to review the part of the spec where it says 2
seconds, and then I suggest Peter modify his patch to change the
timeout to 2 seconds.  I'm also trying to figure out why I remember
the timeout being 30 seconds, when it is clearly setup to be 5...

> 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.

I'd be fine with that, it's similar to a change we made in Linux,
where we don't reset a PHY that appears to be configured.

It seems to me that, as the timeout for receiving link negotiation
bursts from the link partner is 150ms, that after 150ms, the PHY would
be able to report the link as definitively down, somehow...

Anyway, I'm fine with a 2 second timeout, as long as I've confirmed it
in the spec.

And then I suspect we'll have to change it again when we find someone
who has a PHY that didn't conform to the spec...

Andy

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Jerry Van Baren]

Andy Fleming wrote:
> On Fri, Feb 6, 2009 at 7:32 AM, Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
>> Peter Tyser wrote:
> 
>>>> 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.
> 
> Could you point me at where in the spec it says this?  I've been
> digging around in it, and found nothing concrete so far.

I've been sweating bullets just *knowing* someone was going to call me 
on this.  Oh man, I am ***SO*** lucky... I had to dig back to October 
2002 to find it, but find it I did.  :-) :-) :-)

My experience is that "The second case assumes that the far end link 
partner fully supports Auto-Negotiation:" / "Min spec" time is what 
occurs.  I've never seen a PHY take anything other than bang-on 2 
seconds (OK, 2.054 seconds).

IIRC, the "min spec" time is the minimum time a PHY is allowed to take 
for autonegotiation.  The "max spec" time is the maximum time the PHY is 
allowed to take for autonegotiation.  The PHY *has* everything it needs 
to know by the "min spec" time, which is why all PHYs (that I've ever 
used) take exactly 2 seconds for autonegotiation.

If you wanted to be safer than my semi-empirical 2 second number, 2.8 
(round up to 3?) seconds is probably a good choice.

Note that the first case mentioned below is oddball in that the far end 
doesn't support autonegotiation.  In real life, you are probably screwed 
in this case regardless of the time it takes for autonegotiation to fail.

I recall verifying the DP83840 calculations against chapter 28 of the 
IEEE 802.3u and I *clearly* recall not wanting to go back there ever 
again.  If you doubt the numbers, *you* can go there.  ;-)

Enjoy,
gvb

------------------------------------------------------------------
Worst case auto-negotiate times per IEEE.
------------------------------------------------------------------

Quote from National Instrument's DP83840A Datasheet:
==================================================================
3.9.6 Auto-Negotiation Complete Time

This section describes the amount of time required to complete an
Auto-Negotiation cycle for the 840A. These times are defined for two cases.

The first case assumes that the far end link partner does not support
Auto-Negotiation and is either a fixed 10M or 100M implementation.

Timer			Min spec	Max spec	DP83840A
-----			--------	--------	--------
Break link		1200ms		1500ms		1300ms
Autoneg wait		 500ms		1000ms		 750ms
Link fail inhibit	 750ms		1000ms		 800ms
------------------------------------------------------------------
Total			1700-2450ms	2500-3500ms	2050-2850ms


The second case assumes that the far end link partner fully
supports Auto-Negotiation:

Timer			Min spec	Max spec	DP83840A
-----			--------	--------	--------
Break link		1200ms		1500ms		1300ms
FLP bursts		 104ms		 312ms		 200ms
Link fail inhibit	 750ms		1000ms		 800ms
------------------------------------------------------------------
Total			1304-2054ms	1812-2812ms	1500-2300ms

Refer to chapter 28 of the IEEE 802.3u standard for a full description 
of  the individual timers related to Auto-Negotiation.
==========================================================================

Notes:
* The minimum time in the "Total" lines is if "Link fail inhibit" is not
necessary.  The maximum is the sum of all three times in the column.

* Assuming "Link fail inhibit" doesn't occur, the "Break link" dominates
the time required.

* Our experience is that the PHYs can be configured to start 
auto-negotiating on application of power.  This allows the 
auto-negotiation to occur in parallel with the processor start up code. 
  This is helpful, but 2 seconds is still a long time.

* The FLP pulse width is 100nSec (10MHz fundamental frequency, probably
square edges).

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Andy Fleming]

On Fri, Feb 6, 2009 at 1:30 PM, Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
> Andy Fleming wrote:
>>
>> On Fri, Feb 6, 2009 at 7:32 AM, Jerry Van Baren <gerald.vanbaren@ge.com>
>> wrote:
>>>
>>> Peter Tyser wrote:
>>
>>>>> 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.
>>
>> Could you point me at where in the spec it says this?  I've been
>> digging around in it, and found nothing concrete so far.
>
> I've been sweating bullets just *knowing* someone was going to call me on
> this.  Oh man, I am ***SO*** lucky... I had to dig back to October 2002 to
> find it, but find it I did.  :-) :-) :-)
>
> My experience is that "The second case assumes that the far end link partner
> fully supports Auto-Negotiation:" / "Min spec" time is what occurs.  I've
> never seen a PHY take anything other than bang-on 2 seconds (OK, 2.054
> seconds).
>
> IIRC, the "min spec" time is the minimum time a PHY is allowed to take for
> autonegotiation.  The "max spec" time is the maximum time the PHY is allowed
> to take for autonegotiation.  The PHY *has* everything it needs to know by
> the "min spec" time, which is why all PHYs (that I've ever used) take
> exactly 2 seconds for autonegotiation.
>
> If you wanted to be safer than my semi-empirical 2 second number, 2.8 (round
> up to 3?) seconds is probably a good choice.


Based on my reading of the below, "safe" is 3.5 seconds.

>
> Note that the first case mentioned below is oddball in that the far end
> doesn't support autonegotiation.  In real life, you are probably screwed in
> this case regardless of the time it takes for autonegotiation to fail.

  If the link partner doesn't support autonegotiation, many PHYs
support "Parallel detection" which allows the PHY to essentially
notice by the link response what speeds seem to be supported.  And,
really, my issue is not with autonegotiation failing, but failing due
to no link actually being present.  If the link isn't there, it's
annoying to wait and wait and wait.

>
> I recall verifying the DP83840 calculations against chapter 28 of the IEEE
> 802.3u and I *clearly* recall not wanting to go back there ever again.  If
> you doubt the numbers, *you* can go there.  ;-)

I'll trust your math.  My curiosity has to do with whether the link
status will be reported as up once the break link time has elapsed.
But 3.5 is still better than what at some point was a much longer
timeout.

Andy

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Jerry Van Baren]

Andy Fleming wrote:
> On Fri, Feb 6, 2009 at 1:30 PM, Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
>> Andy Fleming wrote:
>>> On Fri, Feb 6, 2009 at 7:32 AM, Jerry Van Baren <gerald.vanbaren@ge.com>
>>> wrote:
>>>> Peter Tyser wrote:

[snip]

>> My experience is that "The second case assumes that the far end link partner
>> fully supports Auto-Negotiation:" / "Min spec" time is what occurs.  I've
>> never seen a PHY take anything other than bang-on 2 seconds (OK, 2.054
>> seconds).
>>
>> IIRC, the "min spec" time is the minimum time a PHY is allowed to take for
>> autonegotiation.  The "max spec" time is the maximum time the PHY is allowed
>> to take for autonegotiation.  The PHY *has* everything it needs to know by
>> the "min spec" time, which is why all PHYs (that I've ever used) take
>> exactly 2 seconds for autonegotiation.
>>
>> If you wanted to be safer than my semi-empirical 2 second number, 2.8 (round
>> up to 3?) seconds is probably a good choice.
> 
> Based on my reading of the below, "safe" is 3.5 seconds.
> 
>> Note that the first case mentioned below is oddball in that the far end
>> doesn't support autonegotiation.  In real life, you are probably screwed in
>> this case regardless of the time it takes for autonegotiation to fail.
> 
>   If the link partner doesn't support autonegotiation, many PHYs

s/many/all/

> support "Parallel detection" which allows the PHY to essentially
> notice by the link response what speeds seem to be supported.  And,

(speed, but not duplex)

> really, my issue is not with autonegotiation failing, but failing due
> to no link actually being present.  If the link isn't there, it's
> annoying to wait and wait and wait.

I understand "parallel detection".  The problem is that the percentage 
of times that it results in a properly configured link is (in my 
experience) very very low.  Not because "parallel detection" doesn't 
work, but because the humans configuring the fixed side don't understand 
parallel detection and set it up for full duplex.

Ignoring the configuration where both ends are (presumably correctly) 
manually configured, you end up with five cases, two of them 
misconfigured and WRONG:
1) Autonegotiation <-> autonegotiation - reliable.
2) 10bT half duplex <-> autonegotiation - reliable.
3) 100bT half duplex <-> autonegotiation - reliable.
4) 10bT *FULL* duplex <-> autonegotiation - *UNreliable*.
5) 100bT *FULL* duplex <-> autonegotiation - *UNreliable*.

The problem that I've observed is that the *humans* (the weak links) 
that do the manual configuration don't understand that "parallel 
detection" *must be* half duplex by definition in the spec (it is hard 
to define a reliable algorithm to detect full duplex capability so the 
spec writers punted).  As a result, the human invariably picks "full 
duplex" because everybody knows full duplex is better... and end up as 
case (4) or (5).  They inadvertently end up with a slower unreliable 
link (lots of "collisions" resulting in runt packets) rather than the 
faster better link they thought they were picking (d'oh!).  The really 
bad thing is that the network works fine in testing on an isolated LAN 
with no traffic and absolutely craps its pants when it hits the real world.

That is my reasoning behind my statement that we can generally ignore 
the autonegotiation <-> fixed configuration case because the odds of it 
working properly are poor anyway.

Having said all that, I don't have any problem with using 3.5 seconds as 
the safe timeout value.  it isn't worth timing out too soon just to 
shave 0.5 or even 1.0 seconds off the negotiation timeout time.

>> I recall verifying the DP83840 calculations against chapter 28 of the IEEE
>> 802.3u and I *clearly* recall not wanting to go back there ever again.  If
>> you doubt the numbers, *you* can go there.  ;-)
> 
> I'll trust your math.  My curiosity has to do with whether the link
> status will be reported as up once the break link time has elapsed.
> But 3.5 is still better than what at some point was a much longer
> timeout.
> 
> Andy

Best regards,
gvb

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Scott Wood]

On Tue, Feb 10, 2009 at 08:59:11AM -0500, Jerry Van Baren wrote:
> That is my reasoning behind my statement that we can generally ignore 
> the autonegotiation <-> fixed configuration case because the odds of it 
> working properly are poor anyway.

I'm not fond of giving up any ability to support a configuration just
because some people get it wrong (including configurations where the
human *can't* screw it up because the fixed end is some old hub or NIC
that doesn't support anything other than 10Mbit, half-duplex), especially
when the benefit of not supporting it is so low.

> Having said all that, I don't have any problem with using 3.5 seconds as 
> the safe timeout value.  it isn't worth timing out too soon just to 
> shave 0.5 or even 1.0 seconds off the negotiation timeout time.

OK, good. :-)

-Scott

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser]

Sorry for the delayed response,

On Tue, 2009-02-10 at 11:31 -0600, Scott Wood wrote:
> On Tue, Feb 10, 2009 at 08:59:11AM -0500, Jerry Van Baren wrote:
> > That is my reasoning behind my statement that we can generally ignore 
> > the autonegotiation <-> fixed configuration case because the odds of it 
> > working properly are poor anyway.
> 
> I'm not fond of giving up any ability to support a configuration just
> because some people get it wrong (including configurations where the
> human *can't* screw it up because the fixed end is some old hub or NIC
> that doesn't support anything other than 10Mbit, half-duplex), especially
> when the benefit of not supporting it is so low.
> 
> > Having said all that, I don't have any problem with using 3.5 seconds as 
> > the safe timeout value.  it isn't worth timing out too soon just to 
> > shave 0.5 or even 1.0 seconds off the negotiation timeout time.
> 
> OK, good. :-)

I agree, I'd prefer to err on the conservative side too.  The spec Jerry
mentioned was for a 100M PHY.  I'm guessing it could take longer for a
1000M PHY...  I've looked around a fair bit and couldn't find anything
concrete either.  I see a few references to a 4.5 second autonegotiation
timeout in the Linux kernel (e1000 and e1000e drivers), but of course no
mention of where those numbers came from.  I see timeout values of 4 and
5 seconds in U-Boot also.

What if I keep this patch as is, then submit an additional patch which
would replace all PHY_AUTONEGOTIATE_TIMEOUT references with
CONFIG_SYS_PHY_AUTONEG_TIMEOUT.  A conservative default value of 4.5
seconds would be assigned to CONFIG_SYS_AUTONEG_TIMEOUT in net.h, but
this could be overridden by board config files if wanted/needed?

Thanks,
Peter

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser]

On Wed, 2009-02-04 at 15:14 -0600, Peter Tyser wrote:
> Previously, waiting for auto-negotiation would only occur if a valid
> link had been detected.  Problems arose when attempting to use a
> tsec immediately after bootup but before link was achieved, eg:
> => dhcp
> Auto-neg error, defaulting to 10BT/HD
> eTSEC1: No link.
> Auto-neg error, defaulting to 10BT/HD
> eTSEC2: No link.
> =>
> 
> With this patch applied the same operation as above resulted in:
> => dhcp
> Waiting for PHY auto negotiation to complete. done
> Enet starting in 1000BT/FD
> Speed: 1000, full duplex
> 
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

This patch originally spawned a lot of discussion but nothing came of
it.  Could we get it applied?  If not, what do I need to do to get a
similar change in?

Right now if you have autoboot enabled that uses network operation, you
have to add an arbitrary delay to the boot process to give
autonegotiation time to complete, which is annoying.  The negotiation
time varies depending on switch too, so the delay can never be exact.

Thanks,
Peter

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser]

On Sun, 2009-07-19 at 15:14 -0500, Peter Tyser wrote:
> On Wed, 2009-02-04 at 15:14 -0600, Peter Tyser wrote:
> > Previously, waiting for auto-negotiation would only occur if a valid
> > link had been detected.  Problems arose when attempting to use a
> > tsec immediately after bootup but before link was achieved, eg:
> > => dhcp
> > Auto-neg error, defaulting to 10BT/HD
> > eTSEC1: No link.
> > Auto-neg error, defaulting to 10BT/HD
> > eTSEC2: No link.
> > =>
> > 
> > With this patch applied the same operation as above resulted in:
> > => dhcp
> > Waiting for PHY auto negotiation to complete. done
> > Enet starting in 1000BT/FD
> > Speed: 1000, full duplex
> > 
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> 
> This patch originally spawned a lot of discussion but nothing came of
> it.  Could we get it applied?  If not, what do I need to do to get a
> similar change in?
> 
> Right now if you have autoboot enabled that uses network operation, you
> have to add an arbitrary delay to the boot process to give
> autonegotiation time to complete, which is annoying.  The negotiation
> time varies depending on switch too, so the delay can never be exact.

Ping...

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser]

On Tue, 2009-08-04 at 17:50 -0500, Peter Tyser wrote:
> On Sun, 2009-07-19 at 15:14 -0500, Peter Tyser wrote:
> > On Wed, 2009-02-04 at 15:14 -0600, Peter Tyser wrote:
> > > Previously, waiting for auto-negotiation would only occur if a valid
> > > link had been detected.  Problems arose when attempting to use a
> > > tsec immediately after bootup but before link was achieved, eg:
> > > => dhcp
> > > Auto-neg error, defaulting to 10BT/HD
> > > eTSEC1: No link.
> > > Auto-neg error, defaulting to 10BT/HD
> > > eTSEC2: No link.
> > > =>
> > > 
> > > With this patch applied the same operation as above resulted in:
> > > => dhcp
> > > Waiting for PHY auto negotiation to complete. done
> > > Enet starting in 1000BT/FD
> > > Speed: 1000, full duplex
> > > 
> > > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > 
> > This patch originally spawned a lot of discussion but nothing came of
> > it.  Could we get it applied?  If not, what do I need to do to get a
> > similar change in?
> > 
> > Right now if you have autoboot enabled that uses network operation, you
> > have to add an arbitrary delay to the boot process to give
> > autonegotiation time to complete, which is annoying.  The negotiation
> > time varies depending on switch too, so the delay can never be exact.
> 
> Ping...

Hi Ben,
This is the 3rd or 4th time this type of patch has been brought up with
no major objections that I'm aware of.  Can we apply it?  Or if someone
has an objection, can they let me know?

Thanks,
Peter

[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Ben Warren]

Peter Tyser wrote:
> Previously, waiting for auto-negotiation would only occur if a valid
> link had been detected.  Problems arose when attempting to use a
> tsec immediately after bootup but before link was achieved, eg:
> => dhcp
> Auto-neg error, defaulting to 10BT/HD
> eTSEC1: No link.
> Auto-neg error, defaulting to 10BT/HD
> eTSEC2: No link.
> =>
>
> With this patch applied the same operation as above resulted in:
> => dhcp
> Waiting for PHY auto negotiation to complete. done
> Enet starting in 1000BT/FD
> Speed: 1000, full duplex
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
>   
Applied to net repo.

thanks,
Ben