[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.
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
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 */
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
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
-----Messaggio originale----- Da: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]Per conto di Getz, Robin Inviato: giovedi, 26. agosto 2004 10:30 A: U-Boot-Users@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
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
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
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
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
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
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
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.
- 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?
- 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
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
participants (4)
-
Getz, Robin -
Ladislav Michl -
Paolo Broggini -
Wolfgang Denk