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

Robin Getz rgetz at blackfin.uclinux.org
Thu Aug 26 19:25:50 CEST 2004


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  





More information about the U-Boot mailing list