Hi Hannes, On Tue, Sep 6, 2016 at 3:23 PM, Hannes Schmelzer <hannes.schmel...@br-automation.com> wrote: > Bin Meng <bmeng...@gmail.com> schrieb am 06.09.2016 09:07:39: > > [...] >> >> >> >> Why is this needed? The MAC address is supposed to be programmed in >> >> the driver's probe routine. >> > >> > For example on my custom ZYNQ board. >> > The Ethernetcontroller within the ZYNQ has no ROM to store his own >> > MAC-Address, further no MAC is stored within environment. >> > So Ethernet gets probed with a "random MAC-Address" if configured. >> > >> > Later somebody (like me) oder something (my bootscript) runs "setenv >> > ethaddr ...." on the console. >> > Result is (was before this patch), that all networking infrastructre > is >> > running this new mac, but hardware is running the old (random) one and >> > networking is simple not functional. >> > >> >> This indicates that your ethernet driver does not program the latest >> MAC address everyone when it gets probed. The driver should be fixed. > > The driver doesn't get probed again if mac-address is changed using > "setenv ethaddr", > so it has no chance to program anything. >
Yes, driver is not probed when "setenv ethaddr", but next time when you type any ethernet related command (like tftpboot), the driver will be probed. > For program i understand, in this case with zynq, overtaking mac-address > into his registers. > There is per default no ROM to store some mac. > I have feeling that for some ethernet controllers, simply calling eth_write_hwaddr() may not change its MAC address correctly. It may need some special programming sequence like firstly turn off, reset, then program the MAC. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot