From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ladislav Michl Date: Thu, 26 Aug 2004 21:17:30 +0200 Subject: [U-Boot-Users] MAC address question... In-Reply-To: <6.1.1.1.0.20040826093807.01de9258@wheresmymailserver.com> References: <6.1.1.1.0.20040826093807.01de9258@wheresmymailserver.com> Message-ID: <20040826191729.GA2475@umax645sx> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Aug 26, 2004 at 10:25:50AM -0700, Robin Getz wrote: [snip] > I have had a few beta users who had to change the MAC address, (to get DHCP > working on their networks), but then started calling for help when they get > these warning messages. I normally tell them to RTFM - but I was thinking > that a better solution might be necessary. Huh? In that case I would expect that they simply tell DHCP server about new MAC address. > The "solution" was add some functionality somewhere, to change the MAC > address in the SROM. I thought U-boot might be the best bet - because that > is where MAC addresses should be managed - in the boot loader. I know that > this should be programmed during manufacturing (and it is), but there is no > way to re-program the SROM MAC. (unless I am missing something?) > > >Defining memory locations of the processor as flash? ?? ??? > > > >What exactly are you talking about???? > > Today on my board, I have 4 Meg of Flash - If I define things as 4Meg + 6 > bytes, in the board/specific/flash.c in write_buff() - I can trap these +6 > bytes, and actually program the MAC in the SROM. This is bad form because I > know I should not be accessing a device outside the /driver/smc9111.c file. Set MAC function should definitely live in driver/smc9111.c, how to call it is different story and I would expect that this function will be called on setenv ethaddr command. See my earlier post. Regards, ladis