RE: [U-Boot-Users] MAC address question...
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
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
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
participants (3)
-
Ladislav Michl -
Robin Getz -
Wolfgang Denk