On Fri, 18 Jan 2013 10:14:39 +0100 Holger Brunck <[email protected]> wrote:
> On 01/18/2013 01:44 AM, Kim Phillips wrote: > > On Thu, 17 Jan 2013 13:47:51 +0100 > > Holger Brunck <[email protected]> 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"); > >> + } else > >> + puts("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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
