[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[Chris Morgan]

Here at Bose we've measured a significant delay in the time it takes
to initialize ethernet on the MPC5121, a delay of ~2 seconds. I've
seen the same delay on the MPC5200 with u-boot 1.1.3. Currently we are
using the mpc5121 ads version of u-boot from Freescale, based on
1.2.0.

Is there a known requirement in the ethernet hardware or protocol that
requires this 2 second delay? Auto detection of speed or something?

Because we haven't been using ethernet to boot, only to program flash,
we've been able to eliminate the delay by moving the ethernet init
until after the user has pressed enter and broken into the shell. This
would naturally break bootcmds that used ethernet, like nfs or tftp
booting. If the delay is fixed due to hardware I'm wondering if it
would be acceptable to make the ethernet initialization occur on
demand when other code wanted to access the ethernet device?

Chris

[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[gvb.uboot]

Chris Morgan wrote:
> Here at Bose we've measured a significant delay in the time it takes
> to initialize ethernet on the MPC5121, a delay of ~2 seconds. I've
> seen the same delay on the MPC5200 with u-boot 1.1.3. Currently we are
> using the mpc5121 ads version of u-boot from Freescale, based on
> 1.2.0.
> 
> Is there a known requirement in the ethernet hardware or protocol that
> requires this 2 second delay? Auto detection of speed or something?
> 
> Because we haven't been using ethernet to boot, only to program flash,
> we've been able to eliminate the delay by moving the ethernet init
> until after the user has pressed enter and broken into the shell. This
> would naturally break bootcmds that used ethernet, like nfs or tftp
> booting. If the delay is fixed due to hardware I'm wondering if it
> would be acceptable to make the ethernet initialization occur on
> demand when other code wanted to access the ethernet device?
> 
> Chris

A 2 second delay sounds exactly like the PHY autonegotiating the link 
speed (if you add up the numbers in the 100bT standard, it is 2 seconds).

One of Wolfgang's mantras is that hardware must not be initialized 
before and unless it is used.  There is some gray area here... you do 
use the ethernet, just not all the time.

I can guess (with pretty good assurance) about the cause of the delay, 
but I'm not aware of any really good options to eliminate the delay. 
Sorry.  Hardwiring the speed is very ugly.  If you start the 
autonegotiation on power up (typically the PHY can be configured to do 
this via hardware strapping) and *don't* restart it when the ethernet is 
initialized, it can hide the delay.  Or your solution may be the best 
(for you).

HTH,
gvb

[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[Chris Morgan]

On Dec 17, 2007 6:21 PM, gvb.uboot <gvb.uboot@gmail.com> wrote:
>
> Chris Morgan wrote:
> > Here at Bose we've measured a significant delay in the time it takes
> > to initialize ethernet on the MPC5121, a delay of ~2 seconds. I've
> > seen the same delay on the MPC5200 with u-boot 1.1.3. Currently we are
> > using the mpc5121 ads version of u-boot from Freescale, based on
> > 1.2.0.
> >
> > Is there a known requirement in the ethernet hardware or protocol that
> > requires this 2 second delay? Auto detection of speed or something?
> >
> > Because we haven't been using ethernet to boot, only to program flash,
> > we've been able to eliminate the delay by moving the ethernet init
> > until after the user has pressed enter and broken into the shell. This
> > would naturally break bootcmds that used ethernet, like nfs or tftp
> > booting. If the delay is fixed due to hardware I'm wondering if it
> > would be acceptable to make the ethernet initialization occur on
> > demand when other code wanted to access the ethernet device?
> >
> > Chris
>
> A 2 second delay sounds exactly like the PHY autonegotiating the link
> speed (if you add up the numbers in the 100bT standard, it is 2 seconds).
>
> One of Wolfgang's mantras is that hardware must not be initialized
> before and unless it is used.  There is some gray area here... you do
> use the ethernet, just not all the time.
>
> I can guess (with pretty good assurance) about the cause of the delay,
> but I'm not aware of any really good options to eliminate the delay.
> Sorry.  Hardwiring the speed is very ugly.  If you start the
> autonegotiation on power up (typically the PHY can be configured to do
> this via hardware strapping) and *don't* restart it when the ethernet is
> initialized, it can hide the delay.  Or your solution may be the best
> (for you).
>
> HTH,
> gvb
>

Hi Jerry.

One of the hardware guys speculated about the autonegotation being the
cause of the delay so I guess it has at least a few votes now. I'm
hoping for a Freescale person on this list to verify the cause of the
issue as something we can't just change a few registers and fix.

If Wolfgang is ok with not initializing the hardware before use then
doesn't that fit with holding off the ethernet initialization until
there is a function call in the code that requires accessing ethernet?
We aren't using any boot commands that use networking so while we have
ethernet enabled in our board configuration for debug and flashing it
isn't necessary in most boot situations. If initialization on demand
of the ethernet device was acceptable we could probably have someone
work on a patch to do so. Just want to get approval that the idea is
sane and acceptable for inclusion in u-boot, if properly implemented.

Chris

[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[gvb.uboot]

Chris Morgan wrote:
> On Dec 17, 2007 6:21 PM, gvb.uboot <gvb.uboot@gmail.com> wrote:
>> Chris Morgan wrote:
>>> Here at Bose we've measured a significant delay in the time it takes
>>> to initialize ethernet on the MPC5121, a delay of ~2 seconds. I've
>>> seen the same delay on the MPC5200 with u-boot 1.1.3. Currently we are
>>> using the mpc5121 ads version of u-boot from Freescale, based on
>>> 1.2.0.
>>>
>>> Is there a known requirement in the ethernet hardware or protocol that
>>> requires this 2 second delay? Auto detection of speed or something?
>>>
>>> Because we haven't been using ethernet to boot, only to program flash,
>>> we've been able to eliminate the delay by moving the ethernet init
>>> until after the user has pressed enter and broken into the shell. This
>>> would naturally break bootcmds that used ethernet, like nfs or tftp
>>> booting. If the delay is fixed due to hardware I'm wondering if it
>>> would be acceptable to make the ethernet initialization occur on
>>> demand when other code wanted to access the ethernet device?
>>>
>>> Chris
>> A 2 second delay sounds exactly like the PHY autonegotiating the link
>> speed (if you add up the numbers in the 100bT standard, it is 2 seconds).
>>
>> One of Wolfgang's mantras is that hardware must not be initialized
>> before and unless it is used.  There is some gray area here... you do
>> use the ethernet, just not all the time.
>>
>> I can guess (with pretty good assurance) about the cause of the delay,
>> but I'm not aware of any really good options to eliminate the delay.
>> Sorry.  Hardwiring the speed is very ugly.  If you start the
>> autonegotiation on power up (typically the PHY can be configured to do
>> this via hardware strapping) and *don't* restart it when the ethernet is
>> initialized, it can hide the delay.  Or your solution may be the best
>> (for you).
>>
>> HTH,
>> gvb
>>
> 
> Hi Jerry.
> 
> One of the hardware guys speculated about the autonegotation being the
> cause of the delay so I guess it has at least a few votes now. I'm
> hoping for a Freescale person on this list to verify the cause of the
> issue as something we can't just change a few registers and fix.

Well, for a crude confirmation, you can watch the link status LEDs on 
your switch (and board, if your board has them).  My prediction is that 
the link LED probably will go on (hardware started autonegotiation 
complete - might not happen), go off for two seconds (software reset the 
PHY, restarting the autonegotiation), and then come back on again.  The 
second "on" will coincide with your delay ending.

[snip]

gvb

[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[Stefan Roese]

On Tuesday 18 December 2007, Chris Morgan wrote:
> One of the hardware guys speculated about the autonegotation being the
> cause of the delay so I guess it has at least a few votes now. I'm
> hoping for a Freescale person on this list to verify the cause of the
> issue as something we can't just change a few registers and fix.
>
> If Wolfgang is ok with not initializing the hardware before use then
> doesn't that fit with holding off the ethernet initialization until
> there is a function call in the code that requires accessing ethernet?
> We aren't using any boot commands that use networking so while we have
> ethernet enabled in our board configuration for debug and flashing it
> isn't necessary in most boot situations. If initialization on demand
> of the ethernet device was acceptable we could probably have someone
> work on a patch to do so. Just want to get approval that the idea is
> sane and acceptable for inclusion in u-boot, if properly implemented.

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?

This is not what should happen. The targets I know best (PPC4xx) initiate the 
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.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[Wolfgang Denk]

In message <200712180620.44690.sr@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
things differently.

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

And optimizing boot time is a  perfectly  valid  requirement  (and  a
frequent  one,  too),  and  sometimes it may require a different init
sequence.

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.

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
As of 1992, they're called European Economic Community fries.

[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[Stefan Roese]

On Tuesday 18 December 2007, Wolfgang Denk wrote:
> > 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
> things differently.
>
> 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.

Right. I know of such ports too and don't see any problems here since no delay 
is imposed.

> But there are other implementations which wait for 
> autonegotiation to complete.

I don't see a reason why a board should wait for autonegotionation to 
complete, when the interface is not used. This should be fixed.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay

[Chris Morgan]

On Dec 18, 2007 4:03 AM, Stefan Roese <sr@denx.de> wrote:
> On Tuesday 18 December 2007, Wolfgang Denk wrote:
> > > 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
> > things differently.
> >
> > 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.
>
> Right. I know of such ports too and don't see any problems here since no delay
> is imposed.
>
> > But there are other implementations which wait for
> > autonegotiation to complete.
>
> I don't see a reason why a board should wait for autonegotionation to
> complete, when the interface is not used. This should be fixed.
>

I appreciate the responses to this email thread. Knowing more about
what is a suitable solution to the problem reduces the chance that any
proposed solution will have to be fundamentally reworked before being
accepted back into the u-boot tree.

On our end we still need to confirm with someone at Freescale that the
delay is a hardware constraint. I can work that through our support
contacts and if they aren't going to address the issue in u-boot I'm
going to see about having the work to fix this for the 512x(and likely
5200) platforms put on our internal development schedule.

Gerry, I'm copying you to get you in on the discussion. Relative to
our overall board boot time a significant amount of time is spent
waiting for the ethernet initialization so its something we want to
address and to do so in a clean fashion. Any help you guys might be
able to provide would be helpful.

Chris