[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 at 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