[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay
wd at denx.de
Tue Dec 18 09:16:44 CET 2007
In message <200712180620.44690.sr at denx.de> you wrote:
> Let me check if I understand this correctly. Your U-Boot has a delay of
> approx. 2 seconds upon booting (most likely waiting for autonegotiation to
> complete), even when you don't use ethernet in U-Boot at all?
Yes. Depending on CPU and board there may be several such delays.
> This is not what should happen. The targets I know best (PPC4xx) initiate the
You are right, it shouldnot happen.
> autonegotiation only when the ethernet interface is used. Upon TFTP download
> or something like this. So there should be no delay at all in U-Boot related
> to this ethernet initialization when you don't use ethernet.
Right, that's how it should be in an ideal world.
However, things are not that simple.
First, the perception that this is how things should work has not been
there forever. It has riped over time, and older boards / ports do
Second, there are some CPUs / boards where "initializing" the ether-
net just requires to whack a PY reset or simply take the PHT out of
reset etc. Autonegotiation then takes place while U-Boot is doing
other things, and by the time you want to use the Ethernet for a TFTP
download or so it will be available with no or at least with greatly
reduced delay. But there are other implementations which wait for
autonegotiation to complete.
There are similar problems in other areas - for example, many boards
suffer from delays due to IDE intialization even if you don't use it.
Again the MPC5200 is a bad example for such behaviour - especially on
some boards which are missing a pull-down resistor at IDE5V_DD7; on
such boards you will suffer from a 2 minutes timeout (IIRC this is
the value defined by the ATA spec) if no IDE device is connected.
So yes, devices *should* only be initialized when really used, but the
current implementation is differently, at least on some processors or
And optimizing boot time is a perfectly valid requirement (and a
frequent one, too), and sometimes it may require a different init
We should be able to provide both - the "clean" approach for "stan-
dard" systems and the optimized one for systems requiting it.
This is yet another are where code cleanup is needed.
Volunteers and patches welcome.
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
As of 1992, they're called European Economic Community fries.
More information about the U-Boot