[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link
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; }
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
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
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
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
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
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
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
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).
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
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
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
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
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
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
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
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
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
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.
- 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).
- 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
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
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...
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
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
participants (6)
-
Andy Fleming -
Ben Warren -
Jerry Van Baren -
Peter Tyser -
Scott Wood -
Wolfgang Denk