[U-Boot] DM9000 : MAC Address mismatch with Linux kernel

[U-Boot] DM9000 : MAC Address mismatch with Linux kernel

[stefano babic]

Hi all,

I have seen a wrong behaviour about Mac Address handling when the DM9000
controller is connected to an external serial eeprom. The eeprom
contains the Mac Address and the configuration data for the controller.

If the ethaddr variable is set, u-boot uses this variable and sets with
this value the ethernet controller. Only if the ethaddr is not set, the
Mac Address is read from Eeprom.

However, the driver in the linux kernel uses a different approach : it
takes the Mac address first from the eeprom, if it is valid.

This generates a strange phenomen:

1. The target works in u-boot with a mac address, and with this address
for example loads the kernel from network.

2. When the kernel boots, the system takes a different mac address,
because the mac address passed by u-boot is not used.

This behavior is wrong, at least we have wrong values in the arp cache
for some systems on the lan.
I understand that this happens until the arp cache is renewed, however
it can produce failures in the network.

IMHO we should synchronize the two values, writing down the Eeprom in
the case the ethaddr is set. I think this is congruent with all other
boards in u-boot (ethaddr has the highest priority).
In this way, the kernel will use the same Mac address as u-boot.

However, I do not know if this behavior is always acceptable (for
example, if the mac address is written in the factory and the component
has a label reporting the mac address) and it is not so easy to find in
u-boot which boards with the DM9000 controller have a serial eeprom
attached to it.

Any opinion about it ?

Regards,

Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] DM9000 : MAC Address mismatch with Linux kernel

[Wolfgang Denk]

Dear Stefano,

In message <4A2F7183.2000407@denx.de> you wrote:
> 
> This generates a strange phenomen:
> 
> 1. The target works in u-boot with a mac address, and with this address
> for example loads the kernel from network.
> 
> 2. When the kernel boots, the system takes a different mac address,
> because the mac address passed by u-boot is not used.

I understand this is on an ARM system - but  there  U-Boot  does  not
pass any MAC address information to the kernel - at least there is no
standard  way  for  doing  this.  So  either  you  don't pass any MAC
information to Linux, and Linux does the best  effort,  or  you  have
defined  your  own method (like using an "ethadd=" boot argument like
some others do), but you failed to adapt the driver to  pick  up  the
information from there.

In both cases you have no real reason to complain :-)

[But I understand that you are dissatisfied with the current
behaviour.]

> IMHO we should synchronize the two values, writing down the Eeprom in
> the case the ethaddr is set. I think this is congruent with all other

See my posting from yesterday - 
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/54542/focus=61202

I agree that if we have two different  values,  there  should  be  at
least a warning printed by U-Boot.

> boards in u-boot (ethaddr has the highest priority).

I also agree that the "ethaddr" setting should have higher priority.

I am not so sure however if we should automatically change the MAC
address in the EEPROM of the network adapter - I don't think this is a
really good idea.

> However, I do not know if this behavior is always acceptable (for
> example, if the mac address is written in the factory and the component
> has a label reporting the mac address) and it is not so easy to find in
> u-boot which boards with the DM9000 controller have a serial eeprom
> attached to it.
> 
> Any opinion about it ?

My vote is to re-add the warning message that got dropped in the above
mentioned series of patches, and provide means to the user to manually
sync the addresses - one way or the other, dependent on user's
discretion.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Is a computer language with goto's totally Wirth-less?