Dear "Moffett, Kyle D",
In message 58A08F2D-4743-4634-A909-466EB853570B@boeing.com you wrote:
Yes, it should. The rule is that then environment settings always have precedence, and if they are missing or contain different data than other sources for this information, a waning shall be printed.
That is a problem for devices which are typically add-in PCI cards. In that case U-Boot can't be expected to have knowledge of what the MAC addresses should be, and it should just use the ROM attached to the card instead.
The user can be expected to read the boot messages and adjust the environment if he wants to use the card's settinge. In any case, the user shall have the authority to overwrite the card's settings by defining any settings in the environment he wants.
In our use case the e1000 chips are on a separate board attached via CompactPCI. U-Boot should not spontaneously start throwing errors just because the board was stuck into a different slot or replaced due to hardware failure.
U-Boot does not throw errors if you have appropriate settings in the environment. The worst to happen is a warning thatt he MAC settings in U-Boot and on the card don't match.
However, in the case that the board itself has a valid external MAC address and U-Boot does not even have an environment variable, it should not cause extra messages. Think about hot-pluggable USB net adapters where the detection order is nondeterministic.
Yes, it should, because a mandatory environment variable is not set correctly.
The "e1000" driver has always done that. I can submit a separate patch to fix that if you would like.
Thats would be welcome, thanks.
Ok, I will respin the patch so that errors show up like this:
Net: eth0, eth1, ERROR: Could not set MAC address: 00:50:93:81:ff:8a eth2
Is that OK?
Yes, thanks.
Best regards,
Wolfgang Denk