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

[Chris Morgan]

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.

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