On Fri, 18 Jan 2013 10:14:39 +0100 Holger Brunck holger.brunck@keymile.com wrote:
On 01/18/2013 01:44 AM, Kim Phillips wrote:
On Thu, 17 Jan 2013 13:47:51 +0100 Holger Brunck holger.brunck@keymile.com wrote:
- if (piggy_present()) {
uchar enetaddr[6];if (eth_getenv_enetaddr("ethaddr", enetaddr)) {/* increment last 3 bytes */u32 val = (enetaddr[3] << 16) + (enetaddr[4] << 8)+ enetaddr[5];val++;enetaddr[3] = (val >> 16) & 0xFF;enetaddr[4] = (val >> 8) & 0xFF;enetaddr[5] = (val >> 0) & 0xFF;if (!eth_setenv_enetaddr("eth1addr", enetaddr)) {setenv("ethact", "UEC2");setenv("netdev", "eth1");puts("using PIGGY for network boot\n");} elseputs("using frontport for network boot\n");}- } else
puts("using frontport for network boot\n");+#endif
AFAIK, assigning the switch MAC address to the front port's MAC address plus one isn't acceptable practice for u-boot board code. Get eth1addr in the same manner ethaddr is obtained/assigned.
Because you may get a MAC adress which is already given to someone else? In our case this can't happen. We reserve for one instance of this board exactly two MAC adresses. The first one is read out at startup from the inventory in keymile/common/ivm.c. The second one is calculated like above. But it is a unique MAC adress, because exactly this MAC adress is reserved for this board.
it can happen if if setting ethaddr from eeprom somehow fails, and/or the user manually modifies ethaddr in the environment.
But maybe we should move the code to the location where we set ethaddr,
yes, indeed
even if the calculation would be the same?
ideally ethaddr and eth1addr would be stored as separate entities in the eeprom.
Kim