From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Mack Date: Mon, 27 Apr 2009 16:44:16 +0200 Subject: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected In-Reply-To: <200904262314.12901.vapier@gentoo.org> References: <1239189819-26805-1-git-send-email-daniel@caiaq.de> <200904082357.38602.vapier@gentoo.org> <20090421111310.GA32352@buzzloop.caiaq.de> <200904262314.12901.vapier@gentoo.org> Message-ID: <20090427144416.GE10969@buzzloop.caiaq.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sun, Apr 26, 2009 at 11:14:06PM -0400, Mike Frysinger wrote: > On Tuesday 21 April 2009 07:13:10 Daniel Mack wrote: > > On Wed, Apr 08, 2009 at 11:57:37PM -0400, Mike Frysinger wrote: > > > > Not if the MAC is stored in the volatile smc911x registers. Issuing a > > > > soft reset flushes these values - if U-Boot does that, the OS has no > > > > change getting them. > > > > > > then either your u-boot or your OS is misconfigured and you need to fix > > > that. as clearly stated in docs/README.enetaddr, the environment is the > > > place where mac addresses live when there is no dedicated storage (like > > > an eeprom). > > > > > > ignoring that, the mac address doesnt magically get programmed. if no > > > network operation was initiated, then the part wouldnt have been > > > programmed anyways, so you're still left with an OS that cant get itself > > > functional. > > > > Ok, true. Thanks for pointing this out. > > usually what i suggest to people are things like: > - pass $(ethaddr) via kernel command line and parse /proc/cmdline > - use the u-boot tools to read the u-boot env directly > - set the hw address with `ifconfig` or similar tool ... which doesn't help much when it's about booting from NFS root. The particular problem here is that the MAC changes from what it's set to in U-Boot during the TFTP transaction and the randomly chosen one in Linux (which takes place because after the reset, the MAC is all 0xff). And that in turn confuses the ARP caches on other hosts. My patch solves that issue for that very case; that's why it's still in my local tree. Daniel