Hi Stefano,
Heiko Schocher wrote:
Hi Heiko,
Signed-off-by: Heiko Schocher hs@denx.de
drivers/net/fec_mxc.c | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 5af9cdb..b5245ec 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -749,11 +749,18 @@ static int fec_probe(bd_t *bd)
eth_register(edev);
- if (fec_get_hwaddr(edev, ethaddr) == 0) {
printf("got MAC address from EEPROM: %pM\n", ethaddr);memcpy(edev->enetaddr, ethaddr, 6);fec_set_hwaddr(edev);
if (!eth_getenv_enetaddr("ethaddr", ethaddr)) {
/* "ethaddr" is not set in the environment */if (fec_get_hwaddr(edev, ethaddr) == 0) {printf("got MAC address from EEPROM: %pM\n", ethaddr);eth_setenv_enetaddr("ethaddr", ethaddr);} else {printf ("no MAC found\n");return -1;}}
memcpy(edev->enetaddr, ethaddr, 6);
fec_set_hwaddr(edev);
return 0;
}
As I understood Ben's comment on my last patch, the driver must not touch any environment variable, that is it must not call any getenv/setenv function.
See http://www.mail-archive.com/u-boot@lists.denx.de/msg28329.html
Hm, maybe this needs to be discussed again.
What Heiko _really_ fixes is that the board has a problem with linux when no network transfer was done in U-Boot. Looking at the code, this is quite obvious as this special driver does not program any mac address into the controller when no EEPROM mac is found.
No one could argue that Linux should initialize that, but given our failed attempts to fix such things in the ARM linux tree, I looked for another solution.
Looking into our network code again I found doc/README.drivers.eth. It is explicitely allowed in this document to program a mac address into the controller. Now on the other hand if we have "ethaddr" override any other settings, I fail to see how we should do this without using a getenv call.
So maybe Ben _will_ allow this construct after all.
Cheers Detlev