netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brent Cook <bcook@bpointsys.com>
To: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: netdev@vger.kernel.org, tbm@cyrius.com, yt_lee@thecus.com
Subject: Re: e1000: operation without eeprom?
Date: Mon, 28 Aug 2006 09:20:08 -0500	[thread overview]
Message-ID: <200608280920.08647.bcook@bpointsys.com> (raw)
In-Reply-To: <20060828005019.GA31786@xi.wantstofly.org>

On Sunday 27 August 2006 19:50, Lennert Buytenhek wrote:
> Hi,
>
> There are a couple of ARM boards out there with on-board e1000s but
> without any kind of eeprom.  The boot loader and kernel board support
> code have all the info necessary to configure the e1000, but the e1000
> driver bombs out because there isn't an eeprom connected -- how are
> we supposed to deal with this situation?
>

u-boot, which uses modified versions of the linux e1000 drivers, handles this 
special cases with a bunch of platform-specific #ifdefs

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;h=927acbb26737a20e02962f67047e192545a870a1;hb=16850919ff8666f20d047cb83b4ee77581336515;f=drivers/e1000.c

I fear that working in general across the e1000 product line without an eeprom 
might not work so well. We've had 82545's work OK without and eeprom, but the 
82572 did not work so well. Some chips appear to work OK with pure software 
config, whereas others might need some special setup parameters that would 
work best at chip power-up via the eeprom.

As a general solution (with fewer ifdefs than the u-boot solution), it might 
be nice to have a read_eeprom_virtual(..) method in the driver where one 
could supply a binary blob to the driver instead of having a real eeprom. All 
of the driver code that relies on the eeprom could work like normal. I've 
been toying with this under u-boot for a custom ARM board without an eeprom 
too, though it does have the side-effect of bloating the u-boot driver a bit 
with the fake eeprom data that's really useless after boot (it's mostly 
0xFFFFFFFF's though, so you could totally optimize it.)

 - Brent

      reply	other threads:[~2006-08-28 14:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-28  0:50 e1000: operation without eeprom? Lennert Buytenhek
2006-08-28 14:20 ` Brent Cook [this message]

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=200608280920.08647.bcook@bpointsys.com \
    --to=bcook@bpointsys.com \
    --cc=buytenh@wantstofly.org \
    --cc=netdev@vger.kernel.org \
    --cc=tbm@cyrius.com \
    --cc=yt_lee@thecus.com \
    /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;
as well as URLs for NNTP newsgroup(s).