[U-Boot-Users] MAC address question...

[U-Boot-Users] MAC address question...

[Getz, Robin]

I have a board with a SMC91111 on it, with an EEPROM connected to it, to 
store the MAC address. This allows users of the board to re-flash the main 
flash with U-boot as many times as they want without worrying about 
managing the MAC address in the main flash.

However, changing the EEPROM MAC address is troublesome, because the 
/drivers/smc91111.c doesn't seem to support programming the attached 
EEPROM. (you can get_rom_mac, but not set_rom_mac).

Before I started adding things, does anyone else have the same issue?

What I was thinking of doing was defining some reserved memory locations of 
the processor as FLASH, and handle this in /board/specific/flash.c - a 
flash write to 6 memory locations will actually set the MAC address in the 
EEPROM attached to the LAN91111.

This solution is OK - it only effects my board, the downside is that if 
this is a problem other face, it doesn't help anyone else.

Thoughts?

Thanks
-Robin

[U-Boot-Users] MAC address question...

[Ladislav Michl]

On Thu, Aug 26, 2004 at 01:30:19AM -0700, Getz, Robin wrote:
> What I was thinking of doing was defining some reserved memory locations of 
> the processor as FLASH, and handle this in /board/specific/flash.c - a 
> flash write to 6 memory locations will actually set the MAC address in the 
> EEPROM attached to the LAN91111.

Patche bellow adds new command - sea - Store Ethernet Address :-)
sea 11:22:33:44:55:66
Address is writen into EEPROM connected to LAN91C111 chip (there are
some not necessary changes - result of some testing)

Best regards,
	ladis

Index: common/cmd_net.c
===================================================================
RCS file: /cvsroot/u-boot/u-boot/common/cmd_net.c,v
retrieving revision 1.13
diff -u -r1.13 cmd_net.c
--- common/cmd_net.c	9 Jun 2004 12:42:26 -0000	1.13
+++ common/cmd_net.c	26 Aug 2004 09:11:20 -0000
@@ -279,4 +279,30 @@
 );
 #endif	/* CFG_CMD_CDP */
 
+extern int set_rom_mac (char *v_rom_mac);
+	
+int do_sea (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+	int i;
+	char *s, *e, eaddr[6];
+
+	if (argc != 2) {
+		printf ("Usage:\n%s\n", cmdtp->usage);
+		return 1;
+	}
+	s = argv[1];
+	/* turn string into mac value */
+	for (i = 0; i < 6; ++i) {
+		eaddr[i] = simple_strtoul(s, &e, 16);
+		s = (*e) ? e+1 : e;
+	}
+
+	return set_rom_mac(eaddr);
+}
+
+U_BOOT_CMD(
+	sea,	2,	1,	do_sea,
+	"sea\t- Store Ethernet Address\n",
+);
+
 #endif	/* CFG_CMD_NET */
Index: drivers/smc91111.c
===================================================================
RCS file: /cvsroot/u-boot/u-boot/drivers/smc91111.c,v
retrieving revision 1.17
diff -u -r1.17 smc91111.c
--- drivers/smc91111.c	9 Jul 2004 22:51:02 -0000	1.17
+++ drivers/smc91111.c	26 Aug 2004 09:11:26 -0000
@@ -432,15 +432,9 @@
 {
 	PRINTK2 ("%s: smc_reset\n", SMC_DEV_NAME);
 
-	/* This resets the registers mostly to defaults, but doesn't
-	   affect EEPROM.  That seems unnecessary */
-	SMC_SELECT_BANK (0);
-	SMC_outw (RCR_SOFTRST, RCR_REG);
-
 	/* Setup the Configuration Register */
 	/* This is necessary because the CONFIG_REG is not affected */
 	/* by a soft reset */
-
 	SMC_SELECT_BANK (1);
 #if defined(CONFIG_SMC91111_EXT_PHY)
 	SMC_outw (CONFIG_DEFAULT | CONFIG_EXT_PHY, CONFIG_REG);
@@ -448,6 +442,10 @@
 	SMC_outw (CONFIG_DEFAULT, CONFIG_REG);
 #endif
 
+	/* This resets the registers mostly to defaults, but doesn't
+	   affect EEPROM.  That seems unnecessary */
+	SMC_SELECT_BANK (0);
+	SMC_outw (RCR_SOFTRST, RCR_REG);
 
 	/* Release from possible power-down state */
 	/* Configuration register is not affected by Soft Reset */
@@ -1548,13 +1546,55 @@
 	int valid_mac = 0;
 
 	SMC_SELECT_BANK (1);
+	SMC_outw ((SMC_inw (CTL_REG) | CTL_RELOAD) & (~CTL_EEPROM_SELECT), CTL_REG);
+	i = 10;
+	while (SMC_inw (CTL_REG) & CTL_RELOAD) {
+		if (!--i) {
+			printf ("Failed reload MAC addr\n");
+			return 0;
+		}
+		udelay(100);
+	}
+
 	for (i=0; i<6; i++)
 	{
 		v_rom_mac[i] = SMC_inb ((ADDR0_REG + i));
 		valid_mac |= v_rom_mac[i];
 	}
 
+	PRINTK2("SMC eeprom read::\n" );
+	PRINTK2(" MAC:%02X:%02X:%02X:%02X:%02X:%02X\n",
+		v_rom_mac[0], v_rom_mac[1],
+		v_rom_mac[2], v_rom_mac[3],
+		v_rom_mac[4], v_rom_mac[5]) ;
+
+	PRINTK2(" Base: %04x\n", SMC_inw (BASE_REG) );
+	PRINTK2(" Gp: %04x\n", SMC_inw (GP_REG) );
+
 	return (valid_mac ? 1 : 0);
 #endif
 }
+
+int set_rom_mac (char *v_rom_mac)
+{
+	int i, timeout;
+
+	printf ("\nStoring MAC address.\n");
+
+	for (i = 0; i < 3; i++) {
+		SMC_SELECT_BANK (2);
+		SMC_outw ( 0x20 + i, PTR_REG );
+		SMC_SELECT_BANK (1);
+		SMC_outw ( *(((u16 *)v_rom_mac)+i), GP_REG );
+		SMC_outw (SMC_inw (CTL_REG) | CTL_STORE | CTL_EEPROM_SELECT, CTL_REG);
+		timeout = 100;
+		while (SMC_inw (CTL_REG) & CTL_STORE && --timeout)
+			udelay(100);
+		if (timeout == 0) {
+			printf ("Failed to store MAC address\n");
+			break;
+		}
+	}
+}
+
 #endif /* CONFIG_DRIVER_SMC91111 */
Index: drivers/smc91111.h
===================================================================
RCS file: /cvsroot/u-boot/u-boot/drivers/smc91111.h,v
retrieving revision 1.10
diff -u -r1.10 smc91111.h
--- drivers/smc91111.h	9 Jun 2004 15:37:24 -0000	1.10
+++ drivers/smc91111.h	26 Aug 2004 09:11:28 -0000
@@ -374,7 +374,7 @@
 #define CONFIG_EPH_POWER_EN 0x8000 /* When 0 EPH is placed into low power mode. */
 
 /* Default is powered-up, Internal Phy, Wait States, and pin nCNTRL=low */
-#define CONFIG_DEFAULT	(CONFIG_EPH_POWER_EN)
+#define CONFIG_DEFAULT	(CONFIG_EPH_POWER_EN | CONFIG_NO_WAIT)
 
 
 /* Base Address Register */

R: [U-Boot-Users] MAC address question...

[Paolo Broggini]

> -----Messaggio originale-----
> Da: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]Per conto di Getz,
> Robin
> Inviato: giovedi, 26. agosto 2004 10:30
> A: U-Boot-Users at lists.sourceforge.net
> Oggetto: [U-Boot-Users] MAC address question...
>
>
> I have a board with a SMC91111 on it, with an EEPROM connected to it, to
> store the MAC address. This allows users of the board to re-flash
> the main
> flash with U-boot as many times as they want without worrying about
> managing the MAC address in the main flash.

You can use 'ethaddr' env. variable. By keeping the environment variables in
a
separate flash sector you can re-flash the U-Boot sectors without worries.
That's actually what I do on our board, which doesn't have an EEPROM
connected to
the LAN91C111.

>
> However, changing the EEPROM MAC address is troublesome, because the
> /drivers/smc91111.c doesn't seem to support programming the attached
> EEPROM. (you can get_rom_mac, but not set_rom_mac).
>
> Before I started adding things, does anyone else have the same issue?
>
> What I was thinking of doing was defining some reserved memory
> locations of
> the processor as FLASH, and handle this in /board/specific/flash.c - a
> flash write to 6 memory locations will actually set the MAC
> address in the
> EEPROM attached to the LAN91111.

...wouldn't be better to implement a set_rom_mac() ?

>
> This solution is OK - it only effects my board, the downside is that if
> this is a problem other face, it doesn't help anyone else.
>
> Thoughts?
>
> Thanks
> -Robin
>
>
Regards,
-Paolo Broggini

>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>

[U-Boot-Users] MAC address question...

[Wolfgang Denk]

In message <6.1.1.1.0.20040826005414.01dd2158@wheresmymailserver.com> you wrote:
>
> However, changing the EEPROM MAC address is troublesome, because the 
> /drivers/smc91111.c doesn't seem to support programming the attached 
> EEPROM. (you can get_rom_mac, but not set_rom_mac).
> 
> Before I started adding things, does anyone else have the same issue?

Where exactly is the provlem? This case should be covered by  U-Boot.
See  the  paragraphs  starting  with "If the network interface stores
some valid MAC address..." in section "Note  for  Redundant  Ethernet
Interfaces" in the README.

> What I was thinking of doing was defining some reserved memory locations of 
> the processor as FLASH, and handle this in /board/specific/flash.c - a 

Defining memory locations of the processor as flash? ?? ???

What exactly are you talking about????

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to  the
purpose of sitting around all day and eating big heavy meals.
                                 - Terry Pratchett, _Moving Pictures_

[U-Boot-Users] MAC address question...

[Wolfgang Denk]

In message <20040826091736.GA2530@umax645sx> you wrote:
>
> Patche bellow adds new command - sea - Store Ethernet Address :-)
> sea 11:22:33:44:55:66
> Address is writen into EEPROM connected to LAN91C111 chip (there are
> some not necessary changes - result of some testing)

I reject this patch. No such command is  needed.  This  situation  is
covered  by  the  "setenv  ethaddr"  command.  If  you think you must
initialize the EEPROM content in case it does not contain a valid MAC
address such code should be automatically executed then.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Real programmers can write assembly code in any language.   :-)
                      - Larry Wall in  <8571@jpl-devvax.JPL.NASA.GOV>

R: [U-Boot-Users] MAC address question...

[Wolfgang Denk]

In message <NDBBJGGCBKABIDHFAMBIOEOACDAA.pbroggini@softool.ch> you wrote:
> 
> You can use 'ethaddr' env. variable. By keeping the environment variables in a
> separate flash sector you can re-flash the U-Boot sectors without worries.
> That's actually what I do on our board, which doesn't have an EEPROM
> connected to
> the LAN91C111.

Even with an embedded flash sector you can  re-flash  U-Boot  without
problems by just adding a "saveenv" after writing the image.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Madness takes its toll. Please have exact change.

[U-Boot-Users] MAC address question...

[Ladislav Michl]

On Thu, Aug 26, 2004 at 05:05:34PM +0200, Wolfgang Denk wrote:
> I reject this patch. No such command is  needed.  This  situation  is
> covered  by  the  "setenv  ethaddr"  command.  If  you think you must
> initialize the EEPROM content in case it does not contain a valid MAC
> address such code should be automatically executed then.

Wolfgang, this patch wasn't of course sent for inclusion. It's only
meant example how to store mac address to eeprom. We are using it for
testing and debugging purposes only.

regards,
	ladis

[U-Boot-Users] MAC address question...

[Ladislav Michl]

On Thu, Aug 26, 2004 at 05:03:20PM +0200, Wolfgang Denk wrote:
> In message <6.1.1.1.0.20040826005414.01dd2158@wheresmymailserver.com> you wrote:
> >
> > However, changing the EEPROM MAC address is troublesome, because the 
> > /drivers/smc91111.c doesn't seem to support programming the attached 
> > EEPROM. (you can get_rom_mac, but not set_rom_mac).
> > 
> > Before I started adding things, does anyone else have the same issue?
> 
> Where exactly is the provlem? This case should be covered by  U-Boot.
> See  the  paragraphs  starting  with "If the network interface stores
> some valid MAC address..." in section "Note  for  Redundant  Ethernet
> Interfaces" in the README.

I have question regarding this section. If interface is able to
store mac address in its own eeprom then _no_ definition in enviroment
should _ever_ exist. What does point "o" 4th mean? Do you really want to
allow U-Boot and (for example) Linux to boot with different mac address?
Why?

	ladis

[U-Boot-Users] MAC address question...

[Wolfgang Denk]

In message <20040826161304.GB2506@umax645sx> you wrote:
>
> I have question regarding this section. If interface is able to
> store mac address in its own eeprom then _no_ definition in enviroment
> should _ever_ exist. What does point "o" 4th mean? Do you really want to

No. For U-Boot the reference is always the  value  of  the  "ethaddr"
envrionment variable.

> allow U-Boot and (for example) Linux to boot with different mac address?
> Why?

Normally no user is supposed to touch  or  modify  the  MAC  address.
That's why it's value in the default configuration is read-only after
being  set.  It  gets set once during production (or automagically at
first boot) and then never changes.

Now _if_ you configure U-Boot to allow overwriting the setting,  then
you  are  supposed  to know what you are doing, and we will not limit
you. You may have a special purpose of doing  exactly  this.  If  you
don't like this, then don't do it.

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
      Bugs are by far the largest and  most successful class of
      entity, with nearly a million known species. In this res-
      pect they outnumber all the other  known  creatures about
      four to one.  -- Professor Snope's Encyclopedia of Animal

[U-Boot-Users] MAC address question...

[Ladislav Michl]

On Thu, Aug 26, 2004 at 06:44:10PM +0200, Wolfgang Denk wrote:
> No. For U-Boot the reference is always the  value  of  the  "ethaddr"
> envrionment variable.

Ah, I probably didn't explain it too well :( "ethaddr" envrionment
variable still exist, but it's not stored together with other variables,
but in smc's eeprom itself (so it's not stored in two different places)

That feature is configurable (eeprom is optional and smc can be told not
to use it). Are you interested in patch?

> > allow U-Boot and (for example) Linux to boot with different mac address?
> > Why?
> 
> Normally no user is supposed to touch  or  modify  the  MAC  address.
> That's why it's value in the default configuration is read-only after
> being  set.  It  gets set once during production (or automagically at
> first boot) and then never changes.

My point is exactly the same. After board is manufactured, it is put
into automatic tester which writes mac address (basicaly it is computer
hooked to serial line and some other signals for diagnostic) by issuing
setenv ethaddr command. This command stores mac address directly into
eeprom, not into the same space as other variables are stored (NOR
flash)

> Now _if_ you configure U-Boot to allow overwriting the setting,  then
> you  are  supposed  to know what you are doing, and we will not limit
> you. You may have a special purpose of doing  exactly  this.  If  you
> don't like this, then don't do it.

Once set, overwriting mac address is allowed, but it is password protected.
That way unexperienced user is not able to change it, but service
technician is.

> "UNIX was not designed to stop you from doing stupid things,  because
> that would also stop you from doing clever things."       - Doug Gwyn

:)

Regards,
	ladis

[U-Boot-Users] MAC address question...

[Robin Getz]

Sorry - maybe I need to explain myself a little better.

The board that I am designing is a hardware/software prototyping validation 
board for various open source projects. It includes processor (Blackfin), 
Ethernet (SMC91111), Flash (4Meg) and SDRAM (128Meg), and expansion 
connectors for ADC, DAC, Audio Codecs, video encoder/decoders, ISM radios, etc.

Since this will eventually sold at Digikey & Farnell, it will be used by a 
variety of people at different skill levels (from pros to beginners), I 
want to ensure that if someone erases the entire Flash, it will still have 
a valid MAC address. Therefore, it will ship to people with valid MAC 
addresses (purchased from the IEEE) in the EEPROM connected to the 
SMC91111, and no environment variable (ethaddr) set.

If someone wants to change the MAC address, they add the environment 
variable (ethaddr), and this will be used. (but it will print warning 
messages that the MACs do not match).

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.

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.

The other option I had was make a similar patch to what Ladis did (thanks 
by the way) - but I expected Wolfgang to have a similar reaction to what he 
did.

I would like to come up with an acceptable solution, but maybe I am just 
worrying about something that I should not be - and just document things 
better.

As always - opinions or thoughts appreciated.

-Robin  

[U-Boot-Users] MAC address question...

[Ladislav Michl]

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

[U-Boot-Users] MAC address question...

[Wolfgang Denk]

In message <20040826171027.GA2759@umax645sx> you wrote:
>
> > No. For U-Boot the reference is always the  value  of  the  "ethaddr"
> > envrionment variable.
> 
> Ah, I probably didn't explain it too well :( "ethaddr" envrionment
> variable still exist, but it's not stored together with other variables,
> but in smc's eeprom itself (so it's not stored in two different places)

This is not acceptable.  The  environment  is  defined  as  a  single
contiguous  area  in memory (RAM while U-Boot is running). I will not
accept exceptions from that rule.

> That feature is configurable (eeprom is optional and smc can be told not
> to use it). Are you interested in patch?

No, see above.

Again: there is no need for such a behaviour. If there is a valid MAC
address somewhere else, you can simply  omit  the  "ethaddr"  in  the
initialization  of  the  environment,  and  you  may even add code to
automatically bootstrap the definition from  this  external  storage.
But that's all.

> My point is exactly the same. After board is manufactured, it is put
> into automatic tester which writes mac address (basicaly it is computer
> hooked to serial line and some other signals for diagnostic) by issuing
> setenv ethaddr command. This command stores mac address directly into
> eeprom, not into the same space as other variables are stored (NOR
> flash)

No. Make your teste write it directly to the EEPROM if you like  (but
not  though  the "setenv" command, as this will always write to _one_
device only).

> Once set, overwriting mac address is allowed, but it is password protected.
> That way unexperienced user is not able to change it, but service
> technician is.

Such password protection  is  overkill.  Shall  I  show  you  how  an
unexperienced user is able to overwrite the whole environment even if
you  password protect it? You just need to read the documentation and
add 2 and 2 together.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
In any group of employed individuals the only naturally  early  riser
is  _always_  the office manager, who will _always_ leave reproachful
little notes ... on the desks of their subordinates.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot-Users] MAC address question...

[Wolfgang Denk]

In message <6.1.1.1.0.20040826093807.01de9258@wheresmymailserver.com> you wrote:
> 
> Since this will eventually sold at Digikey & Farnell, it will be used by a 
> variety of people at different skill levels (from pros to beginners), I 
> want to ensure that if someone erases the entire Flash, it will still have 
> a valid MAC address. Therefore, it will ship to people with valid MAC 
> addresses (purchased from the IEEE) in the EEPROM connected to the 
> SMC91111, and no environment variable (ethaddr) set.

OK. This is fine.

> If someone wants to change the MAC address, they add the environment 
> variable (ethaddr), and this will be used. (but it will print warning 
> messages that the MACs do not match).

OK again. All this is exactly what the README says.

> 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 

Why do you need to change a MAC address  to  get  DHCP  working???  I
never  heard  such  a  thing before - of course I assume that you are
distributing your boxes with valid MAC addresses only!?

> 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?)

Such functionality has been added  before,  but  not  as  (statically
linked)  part  of  U-Boot.  Please  see  examples/82559_eeprom.c  and
examples/eepro100_eeprom.c for examples.

> 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.

I will not allow such dirty hacks in the public U-Boot source tree.

> The other option I had was make a similar patch to what Ladis did (thanks 
> by the way) - but I expected Wolfgang to have a similar reaction to what he 
> did.

:-)


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Karl's version of Parkinson's Law: Work expands to  exceed  the  time
alloted it.

[U-Boot-Users] MAC address question...

[Robin Getz]

At Thursday, August 26, 2004 12:38 PM Wolfgang Denk wrote:
[snip]
> > I have had a few beta users who had to change the MAC address, (to get
> > DHCP working on their networks)
>
>Why do you need to change a MAC address  to  get  DHCP  working???  I 
>never  heard  such  a  thing before - of course I assume that you are 
>distributing your boxes with valid MAC addresses only!?

The MAC addresses that I ship are valid MAC addresses - it was that their 
DHCP server, only gave IP addresses to "valid" machines on their network 
(valid = machines that the net admin knew about and wanted on the network). 
Since they were hacking on this they did the best thing they could - they 
unplugged the Windows machine, and stole it's MAC address, so their DHCP 
server would give them an IP number that their routers liked.

>Such functionality has been added  before,  but  not  as  (statically
>linked)  part  of  U-Boot.  Please  see  examples/82559_eeprom.c  and 
>examples/eepro100_eeprom.c for examples.

OK - I guess that is what I was looking for. If I made a smc91111_eeprom.c, 
would you accept that back into the examples, and if someone wanted to 
change it, they could do it from there?

I guess I really didn't look in the examples dir. In the README, it says 
there are two simple examples - it didn't mention that there were complex 
ones to :)

>I will not allow such dirty hacks in the public U-Boot source tree.

This is the reason I asked before I started coding -
My five favorite words "architect, design, implement, test, ship".

Thanks for the pointers - I will see what I can get from the examples dir.

-Robin 

[U-Boot-Users] MAC address question...

[Ladislav Michl]

On Thu, Aug 26, 2004 at 09:22:24PM +0200, Wolfgang Denk wrote:
[snip]
> No. Make your teste write it directly to the EEPROM if you like  (but
> not  though  the "setenv" command, as this will always write to _one_
> device only).

I'm getting clueless now. You don't like new command approach and you
also don't like setenv ethaddr approach. I think there are people, who
are solving similar problem. If there is no way to add this feature
into official U-Boot, just say it directly and I'm fine with keeping
patches localy.

> > Once set, overwriting mac address is allowed, but it is password
> > protected. That way unexperienced user is not able to change it, but
> > service technician is.
> 
> Such password protection  is  overkill.  Shall  I  show  you  how  an
> unexperienced user is able to overwrite the whole environment even if
> you  password protect it? You just need to read the documentation and
> add 2 and 2 together.

1) MAC adress lives in EEPROM connected to SMC ethernet chip. This
   address comes from purchased range.
2) User is able to change it in enviroment, but is unable to save it
   together with other enviroment variables and he is also unable to
   store it into serial EEPROM. Think about MAC as a board id.

It is posible that board dies (it is hit by flash, etc). In that case
servician comes to replace it and stores the MAC used by dead board to
new one, not breaking customers setup and to save MAC addresses from
purchased range.

Regards,
	ladis

[U-Boot-Users] MAC address question...

[Wolfgang Denk]

In message <6.1.1.1.0.20040826130504.01de0b38@wheresmymailserver.com> you wrote:
> 
> The MAC addresses that I ship are valid MAC addresses - it was that their 
> DHCP server, only gave IP addresses to "valid" machines on their network 
> (valid = machines that the net admin knew about and wanted on the network). 
> Since they were hacking on this they did the best thing they could - they 
> unplugged the Windows machine, and stole it's MAC address, so their DHCP 
> server would give them an IP number that their routers liked.

Well, such behaviour makes no sense and should not be fixed in software.

> OK - I guess that is what I was looking for. If I made a smc91111_eeprom.c, 
> would you accept that back into the examples, and if someone wanted to 
> change it, they could do it from there?

Sure.

> My five favorite words "architect, design, implement, test, ship".

:-)


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Infidels in all ages have battled for the rights of man, and have at
all times been the fearless advocates of liberty and justice."
- Robert Green Ingersoll

[U-Boot-Users] MAC address question...

[Wolfgang Denk]

Dear Ladislav,

in message <20040826205439.GA2670@umax645sx> you wrote:
> 
> I'm getting clueless now. You don't like new command approach and you
> also don't like setenv ethaddr approach. I think there are people, who
> are solving similar problem. If there is no way to add this feature
> into official U-Boot, just say it directly and I'm fine with keeping
> patches localy.

I'm not against this feature, I just see no sense  in  adding  a  new
command.  Either you can script this using existing "i2c" or "eeprom"
or "mm" commands, or you can use a separate standalone application as
done for the 82559 and eepro100 cards.

> 1) MAC adress lives in EEPROM connected to SMC ethernet chip. This
>    address comes from purchased range.

OK, then there is no need to change it, right?

> 2) User is able to change it in enviroment, but is unable to save it
>    together with other enviroment variables and he is also unable to
>    store it into serial EEPROM. Think about MAC as a board id.

If I was to configure such a system, the user is NOT able  to  change
the MAC address.

If you allow to overwrite the "ethaddr" variable this of course  gets
saved together with the other enviroment variables.

If you want to allow the user to  modify  the  hardware  ID  (in  the
SROM), then provide a separate tool for it.

And yes, I do think about the MAC as  a  board  ID.  This  is  why  I
recommend to make it NOT changable by the user.

> It is posible that board dies (it is hit by flash, etc). In that case
> servician comes to replace it and stores the MAC used by dead board to
> new one, not breaking customers setup and to save MAC addresses from
> purchased range.

This is NEW board, so it has a new board ID - obviously. Sorry, but I
feel this is a constructed example, and not a real problem.  You  can
be  lucky that U-Boot provides the flexibility to do such things, but
this is not a free ticket for misuing it. Just assume the  bootloader
does  not  allow  changing the MAC address. This is actually the case
with _most_ boot loaders.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Never worry about theory as long as  the  machinery  does  what  it's
supposed to do.                                      - R. A. Heinlein

[U-Boot-Users] MAC address question...

[Ladislav Michl]

On Thu, Aug 26, 2004 at 11:58:51PM +0200, Wolfgang Denk wrote:
> I'm not against this feature, I just see no sense  in  adding  a  new
> command.  Either you can script this using existing "i2c" or "eeprom"
> or "mm" commands, or you can use a separate standalone application as
> done for the 82559 and eepro100 cards.

Thanks for hints, it seems this the way to follow.

> This is NEW board, so it has a new board ID - obviously. Sorry, but I
> feel this is a constructed example, and not a real problem.  You  can

Board numbers, customers, locations, etc. are stored in database. That
way it is always known what's going on and the only requirement is to
not allow two same MAC addresses at time. As a customer who doesn't care
about implementation details I would assume that new/repaired device
will behave exactly as before. Of course I'd vote for unique MAC too,
but I'm not the one who decides...

> be  lucky that U-Boot provides the flexibility to do such things, but

Sure, that's why I like open source projects :)

> this is not a free ticket for misuing it. Just assume the  bootloader
> does  not  allow  changing the MAC address. This is actually the case
> with _most_ boot loaders.

Even _most_ firmware has a undocumented way how to change MAC address
(it's note only, your point is certainly right :))

Best regards (and thanks),
	ladis