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