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