The MAC address is not set during the boot process -> MAC address is 00:00:00:00:00:00 with the following exception:
If in UBOOT is a dummy file loaded with the tftpboot command then the correct MAC address during booting is set.
A work around that works is the following:
1) In the boot arguments in UBOOT a parameter must be added, for example 'mac_address' with the value 'ethaddr' ( MAC address set by F&S):
"setenv bootargs console=ttyASC2,38400 ... mac_adress=$(ethaddr)"
2) After the boot process the parameter mac_address with its value can be found in '/proc/cmdline'
3) The value of the MAC address can be extracted with 'sed' and regular expressions.
4) The extracted MAC address then can be set under Linux as follows:
"ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx" ( the xx are the placeholders for the MAC address )
I have the following find under FAQ in the UBOOT project, "14.3.11. Ethernet does not work in Linux"
" Question:
Ethernet does not work on my board. But everything is fine when I use the ethernet interface in U-Boot (for example by performing a TFTP download). This is a bug in U-Boot, right?
Answer:
No. It's a bug in the Linux ethernet driver.
In some cases the Linux driver fails to set the MAC address. That's a buggy driver then - Linux ethernet drivers are supposed to read the MAC address at startup. On ->open, they are supposed to reprogram the MAC address back into the chip (but not the EEPROM, if any) whether or not the address has been changed.
In general, a Linux driver shall not make any assumptions about any initialization being done (or not done) by a boot loader; instead, that driver is responsible for performing all of the necessary initialization itself.
And U-Boot shall not touch any hardware it does not access itself. If you don't use the ethernet interface in U-Boot, it won't be initialized by U-Boot.
A pretty extensive discussion of this issue can be found in the thread ATAG for MAC address on the ARM Linux mailing list. archive 1 archive 2
Some current methods for handling the MAC address programming:
* use custom ATAGs (ARM systems)
* use a Flattened Device Tree (if your arch/port supports it)
* parse the U-Boot environment directly
* pass it via the command line
If your device driver does not support one of these sources directly, then do it yourself:
* add an init board hook
* program it from user space (`ifconfig hw ...`)
* for people who need to do NFS root or similar, then use initramfs -- this is what it was designed for ! "
Is there already a patch to solve this problem ?
