public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay
Date: Tue, 18 Dec 2007 09:16:44 +0100	[thread overview]
Message-ID: <20071218081644.BE34C248AC@gemini.denx.de> (raw)
In-Reply-To: Your message of "Tue, 18 Dec 2007 06:20:44 +0100." <200712180620.44690.sr@denx.de>

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.

  reply	other threads:[~2007-12-18  8:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-17 19:03 [U-Boot-Users] MPC5121 (and MPC5200) ethernet initialization delay Chris Morgan
2007-12-17 23:21 ` gvb.uboot
2007-12-18  1:37   ` Chris Morgan
2007-12-18  3:17     ` gvb.uboot
2007-12-18  5:20     ` Stefan Roese
2007-12-18  8:16       ` Wolfgang Denk [this message]
2007-12-18  9:03         ` Stefan Roese
2007-12-18 17:38           ` Chris Morgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071218081644.BE34C248AC@gemini.denx.de \
    --to=wd@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox