[U-Boot-Users] bootloader MAC

[NZG <ngustavson@emacinc.com>]

> So what? Is there any reason why the Linux ethernet driver could ?not
> perform the same actions that U-Boot can perform?
Yes, the board won't necessarily be booting a version Linux we specify, or 
Linux at all for that matter.  As an OEM we can't modify every OS in the 
world to check these things, but we can ensure that the MAC address is 
correctly installed in the bootloader when we ship it out. If we do not put 
the MAC address in, there are Linux versions out there(all of them to my 
knowledge) that won't do it either. Somebody has to take responsibility for 
it.

> It does not matter where the Linux driver is grabbing the MAC address
> from - from a EEPROM,  or  from  the  U-Boto  environment,  from  the
> bd_info  struct  or  from some OF tree - fact is, that it's the Linux
> driver's responsibility to program the MAC.
It's a common practice among ethernet controllers, such as the Realtek 8139 
and the Intel 82559 to have the MAC address automatically load from the 
EEPROM upon reset with no intervention from any sort of driver. There isn't 
really anything incorrect about expecting the MAC to be valid upon loading 
the OS,It's typical of the industry.  I agree you will have a more robust OS 
if your driver's do not assume things to be initialized, but I would not go 
so far as to call it the OS's "responsibility". Even if it is, it's not 
typically being furfilled, so how about some redundancy?

Did your copy of Windows come with a MAC address? Did you buy one for you 
Linux distro? Of course not, it came with the hardware. It isn't set 
specifically by the BIOS but it's part of the core package, it has nothing to 
do with the OS. 
By putting it in the bootloader I'm attempting to maintain this typical 
arrangement by delivering a piece of hardware that can use any OS, but comes 
with a working bootloader and a pre-installed MAC. 

> Right. And one important area where this plays a role in real life is
> when you have to optimize power consumption on your system (like when
> runningfrom batteries), and you power on the ethernet port only ?when
> you ?want ?to use it. Now don't tell me that you want to reaboot your
> system in such a situation.
In the systems mentioned above, it's automatically loaded from the EEPROM 
without intervention from a driver. In the case of the MCF5282, the MAC 
address is stored in the FEC which is a part of the processor and cannot be 
effectively powered down without powering down the processor. The PHY can be, 
but this won't unset the MAC.  This solution may or may not be as effective 
for the ARM. I'd have to do more research to know, but it is certainly 
effective for the Coldfire.

> You are wrong. It is teh responsibility of the Linux driver to adjust
> the settings it needs for correct operation.
Please offer some justification, or at least evidence of collective agreement 
for your opinions.
To requote your own email:
It is wrong always, everywhere and for everyone to ?believe ?anything
upon ?insufficient ?evidence. ?- W. K. Clifford, British philosopher,

NZG