Bin Meng bmeng.cn@gmail.com schrieb am 06.09.2016 09:28:13:
Von: Bin Meng bmeng.cn@gmail.com An: Hannes Schmelzer Hannes.Schmelzer@br-automation.com, Kopie: Joe Hershberger joe.hershberger@gmail.com, Joe Hershberger joe.hershberger@ni.com, Hannes Schmelzer oe5hpm@oevsv.at, u-boot <u- boot@lists.denx.de>, U-Boot u-boot-bounces@lists.denx.de Datum: 06.09.2016 09:28 Betreff: Re: Re: Re: [U-Boot] [PATCH] net: write enetaddr down to
hardware on
env_callback
Hi Hannes,
On Tue, Sep 6, 2016 at 3:23 PM, Hannes Schmelzer Hannes.Schmelzer@br-automation.com wrote:
Bin Meng bmeng.cn@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.
No. The ethernet driver isn't probed everytime a network transaction is coming. What i can see, the probe is done one time.
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.
That might be possible. Maybe this is the reason why not all drivers provide this function.
Regards, Bin