Passing MAC address to kernel via Device Tree Blob

Hi Pirmin,

Sorry for bringing up an old thread, but this one took me a while to find an answer for and I just happened to come back across this thread while looking for another one. I wanted to post this information for the rest of the community in case anyone stumbled across this thread again.

In short, a modern U-Boot overwrites the local-mac-address = [00 0a 35 00 00 00]; property of your device tree after it gets loaded into memory. The value that it is overwritten with comes from the U-Boot ethaddr=00:0a:35:00:01:22 environment variable.

This is also confirmed in this forum post here:

http://forums.xilinx.com/t5/Embedded-Linux/Perm-changing-the-MAC-address/td-p/61463

Now for the long version and how to prove that this happens:

All of this can be observed if you boot a more recent OSL release like the 2014.4 found on this page:

http://www.wiki.xilinx.com/Zynq+2014.4+Release

Download the Xilinx 2014.4 Linux release and copy the zedboard files to an sd card, boot ZedBoard to U-Boot prompt, run the following command:

zynq-uboot> printenv ethaddr ethaddr=00:0a:35:00:01:22 

Take a peek inside of the devicetree.dts file, and see the following:

local-mac-address = [00 0a 35 00 00 00]; 

Boot ZedBoard all the way into Linux and then run ifconfig command:

# ifconfig eth0

…

Hwaddr 00:0a:35:00:01:22

…

So this demonstrates, in this case, that U-Boot uses its own environment variable to override the devicetree setting.

Now for the extra long version:

You can prove that this happens by going into U-Boot source code and adding some additional print statements to see what is going on.

To test this out, I made some additional prints to u-boot source code and rebuilt:

In u-boot-xlnx/common/fdt_support.c: fdt_fixup_ethernet() added a few lines around here:

// Debug stuff to demonstrate whether device tree is touched or not.

printf("\n");

printf("DEBUG: common/fdt_support.c:fdt_fixup_ethernet()\n");

printf("DEBUG: Modifying the device tree that is loaded into memory\n");

printf("\n");



sprintf(mac, "eth%daddr", ++i);

Fired this up on my ZedBoard and sure enough, here is what I see in the terminal:

## Flattened Device Tree blob at 02000000

   Booting using the fdt blob at 0x2000000

   Loading Kernel Image ... OK

   Loading Ramdisk to 1e793000, end 1ed23d29 ... OK

   Loading Device Tree to 1e78d000, end 1e7923de ... OK



DEBUG: common/fdt_support.c:fdt_fixup_ethernet()

DEBUG: Modifying the device tree that is loaded into memory

DEBUG: About to fix up mac address in device tree node: /amba/ethernet@e000b000

DEBUG: Device tree node modified to MAC address 00 0A 35 00 01 22


Starting kernel ...

Hopefully this clears up where the MAC address comes from.

Regards,

-Kevin

Hi Pirmin,

I have some additional information that I would like to share on this topic that I just recently found.

Not only is U-Boot able to overwrite the  local-mac-address property, but if you store additional ethaddr variables in the U-Boot environment and add aliases to your devicetree for your ethernet interfaces, U-Boot can pass those MAC addresses via the devicetree into Linux.

Here is how I have my DTS setup on PicoZed FMC Carrier using a 7020 SOM:

    aliases {
        ethernet0 = "/amba/ethernet@e000b000";
        ethernet1 = "/amba/ethernet@e000c000";
        serial0 = "/amba/serial@e0001000";
        spi0 = "/amba/spi@e000d000";
    };

        ethernet@e000b000 {
            compatible = "xlnx,ps7-ethernet-1.00.a";
            reg = <0xe000b000 0x1000>;
            status = "okay";
            interrupts = <0x0 0x16 0x4>;
            clocks = <0x1 0xd 0x1 0x1e>;
            clock-names = "ref_clk", "aper_clk";
            local-mac-address = [00 0a 35 00 00 01];
            xlnx,has-mdio = <0x1>;
            #address-cells = <0x1>;
            #size-cells = <0x0>;
            phy-mode = "rgmii-id";
            phy-handle = <&phy0>;

            ps7_ethernet_0_mdio: mdio {
                #address-cells = <0x1>;
                #size-cells = <0x0>;

                phy0: phy@0 {
                    compatible = "marvell,88e1510";
                    device_type = "ethernet-phy";
                    marvel,reg-init = <3 16 0xff00 0x1e 3 17 0xfff0 0x00>;
                    reg = <0x0>;
                };
            };
        };

        ethernet@e000c000 {
            compatible = "xlnx,ps7-ethernet-1.00.a";
            reg = <0xe000c000 0x1000>;
            status = "okay";
            interrupts = <0x0 0x2d 0x4>;
            clocks = <0x1 0xe 0x1 0x1f>;
            clock-names = "ref_clk", "aper_clk";
            local-mac-address = [00 0a 35 00 00 02];
            xlnx,has-mdio = <0x1>;
            #address-cells = <0x1>;
            #size-cells = <0x0>;
            phy-mode = "rgmii-id";
            phy-handle = <&phy1>;
            gmii2rgmii-phy-handle = <&gmii_to_rgmii_0>;
        
            ps7_ethernet_1_mdio: mdio {
                #address-cells = <1>;
                #size-cells = <0>;
                phy1: phy@1 {
                    compatible = "marvell,88e1510";
                    device_type = "ethernet-phy";
                    marvel,reg-init = <3 16 0xff00 0x1e 3 17 0xfff0 0x00>;
                    reg = <0x1>;
                };

                gmii_to_rgmii_0: phy@8 {
                    device_type = "ethernet-phy";
                    reg = <0x8>;
                };
            };
        };

If I set my MAC addresses at the U-Boot command prompt and save to non-volatile memory like this:

zynq-uboot> setenv ethaddr 00:0a:35:00:01:24

zynq-uboot> setenv eth1addr 00:0a:35:00:01:25

zynq-uboot> saveenv

Even after doing all of that I ran into some problems using the xilinx-v2014.4 release tag Linux kernel because only ethaddr was getting passed to my eth0 interface due to a problem in the xilinx_xemacps.c driver code.  It turns out the other MAC adddress stored in eth1addr was getting corrupted somewhere along the way and eth1 was getting set to a random MAC address by the kernel.  After doing some more research, it turns out that there were some commits made to the kernel to correct this behavior with 467c0558bff78cdf3daa67a73a3bd16b60d0d930 and a9a47cf8a7a51dfb307bec7fd2ef236a97d5bf8c so if you use a later release tag, that should solve the problem.

I ended up using the zynq-soc-for-3.20 release tag so now my two Ethernet interfaces come up with the expected MAC addresses assigned.

root@zynq:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0A:35:00:01:24
          inet addr:192.168.2.10  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:54 Base address:0xb000

eth1      Link encap:Ethernet  HWaddr 00:0A:35:00:01:25
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:58 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5044 (4.9 KiB)  TX bytes:0 (0.0 B)
          Interrupt:77 Base address:0xc000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@zynq:~#

Regards,

-Kevin

Kevin,

Based on your observations above it sounds like one can set a device's MAC address by changing the ethaddr environment variable in uBoot.

I tried this on a Zed board running Ubuntu.

However, when I do that, the eth0 device is not created by the kernel.
Here's what I did:

- In uBoot:
  env print ethaddr -> 00:0a:35:00:01:22
  setenv ethaddr 00:0a:35:00:01:23
  saveenv

- I then reset the system, and when it enters uBoot again, I do another 'env print ethaddr' to make sure it stuck. (It did!).
- Then I boot the system
- The kernel does NOT generate an eth0 device, just the 'lo' loopback one.

- When I put the address back to it's original value (last byte 22), save, reset, check, reboot, ... everything is fine and eth0 is there.

Any idea what prevents me from getting an Ethernet interface when I change the Ethernet address in uBoot's environment settings?

Note: when you change the Ethernet address as shown above, you shouldn't do a 'boot' cmd after 'saveenv', because then it will still use the old Ethernet address it read from NV memory. You have to reset the whole system, so that it starts uBoot again.


Kind regards,

~ Paul Claessen

Hi Paul,

I cannot say that I have ever tried this under Ubuntu and I am not sure what would cause eth0 to not come up after changing ethaddr under U-Boot.

Have you checked your device tree to see if there is a 00:0a:35:00:01:22 entry for your Ethernet interface in there?

Thanks for the note about the stale Ethernet address being used until the system is rebooted, I did not catch that during my experiment.

Regards,

-Kevin

Kevin,

Thanks for your response.

No, I haven't checked my device tree (I'm getting my BOOT.bin blob from someone else, and I would have to check with this person), but as you yourself proved at the beginning of this thread, the uBoot ethaddress environment variable overwrites what's in the device tree.

(Note, btw, that uBoot now DOES let you change the ethaddress variable as described in my previous message: a lot of articles I found claim that once it's set, uBoot won't allow you to change it anymore .. that appears to no longer be the case .. thankfully)

(Note2: this also raises the question: if the env variable overwrites the device tree's MAC address, where (and by whom) is this uBooot env variable set initially?)

Btw, I also tried simply setting the mac address with ifconfig: to my surprise, this actually worked:
ifconfig eth0 down
ifconfgi eth0 hw ether <mac address>
ifconfig eth0 up

UNfortunately, the interface doesn't work anymore after that, I get the error (on a simple ping):
connect: Network is unreachable

I would expect maybe some problems at the receiving end (the gateway for instance), because it still has the old MAC address for our IP address in its arp table, but that should be resolved in a few minutes), but the above error clearly indicates something got messed up at the sending side (us!).

ANYWAY ... I have read other posts about this, following some of the links you have provided, but the main basic question remains:

In a production environment, using Zynq 7000 based systems like the Zed board, what is the most efficient way to get every device its own unique MAC address?
Setting a MAC address as a uBoot env variable is an acceptable solution.
Clearly, generating a unique device tree and thus building a new BOOT.bin blob for every single device is not. ;-)

It's actually a real problem now, since we have two Zedboard that are being worked with, and they both have the same MAC address, which causes issues.

~ Paul Claessen

Okay, I figured out how to give a Zed board that is running Linaro Ubuntu a unique MAC address.

As mentioned in a previous post above, the way one would expect this to work is by setting the ethaddr environment variable in uBoot. (This actually works for Petalinux).
The problem I had when I did that, was that Linux wouldn't create my eth0 interface.
What I just found out was that it actually DID create an eth4 interface. Of course I didn't have an interface file for it, so it wasn't usable. But after I used ipconfig to give it the right info (IP address, gateway, etc), it worked just fine.

So then I started to wonder where this eth4 came from.
Turns out it is created by the udev system.
By looking at the rules file that creates the interfaces ( /etc/udev/rules.d/70-persistent-net.rules) I noticed that it tries to create, indeed, 5 interfaces, one for each MAC address I ever tried in all my testing. So, had I changed the ethaddr Uboot variable yet again, it would have added a sixth (eth5) interface for it (which would never be configured right, since I did't expect an eth5).
As it turns out this rules file /etc/udev/rules.d/70-persistent-net.rules is itself created dynamically at boot time by a udev script called /lib/udev/write_net_rules.
THAT is the file that keeps adding interfaces to the rules file if it gets a MAC address passed that it hasn't used before.
One way of fixing this it to alter that script to not add new interfaces, but a much simpler solution is to simply delete the rules file!

So here is the entire procedure:

1. Boot into Linux
2. Run:
   rm /etc/udev/rules.d/70-persistent-net.rules
   sync
   boot
3. Stop uBoot from booting, so you get into the uBoot command line (if you accidently boot into Linux again, remove the rules file again!)
4. Run:
   setenv ethaddr xx:xx:xx:xx:xx:xx
   saveenv
   reset   (NOT 'boot'!)
5. Let it boot into Linux .. now you have an eth0 with the new MAC address

Hope this is helpful to someone .. (the critical step is to remove the rules file! You only have to do all this once for each board/device)


~ Paul

'ipconfig'  = 'ifconfig'