element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      • Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Avnet Boards Forums
  • Products
  • Dev Tools
  • Avnet & Tria Boards Community
  • Avnet Boards Forums
  • More
  • Cancel
Avnet Boards Forums
Avnet Boards General Passing MAC address to kernel via Device Tree Blob
  • Forum
  • Documents
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Avnet Boards Forums to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Not Answered
  • Replies 7 replies
  • Subscribers 353 subscribers
  • Views 8983 views
  • Users 0 members are here
Related

Passing MAC address to kernel via Device Tree Blob

Former Member
Former Member over 12 years ago

Good morning everyone,

in our lab, we have several ZedBoards of which some obtain an IP address from a DHCP server based on their MAC address and some of them use a fixed IP address (no DHCP).

Based on my experience with other embedded Linux boards, the straight forward solution to achieve this would be to generate an individual device tree source (DTS) file for each board containing
- the specific MAC address and
- the specific boot arguments for the kernel to either turn on DHCP or to assign a specific fixed IP address.

According to the Embedded Linux Hands-on Tutorial and the Embedded Linux Development Guide, it is recommended to set the MAC address of the ethernet port of the ZedBoard via U-Boot (zynq_zed.h). However, it is also mentioned that the MAC address can be set via DTS file. To do so, the MAC address assignment in the U-Boot configuration needs to be deleted.

Now to my problem:
If I now boot the ZedBoard with such a configuration, the MAC address of the system differs from the address specified in the DTS file. More precisely, the first 4 Bytes are equal to the specified address but the last 2 Bytes are always zero.
Example:
AA:BB:CC:DD:11:FF -> AA:BB:CC:DD:00:00

If the MAC address is set via U-Boot, everything is fine. Except that I then need to generate both a specific BOOT.BIN (containing the U-Boot) and a DTS file for each board.

I think that there is an error in how the MAC address is passed from the DTS to the driver (xemacps). Does anyone of you have an idea how to fix that?

Best regards,

Pirmin

  • Sign in to reply
  • Cancel
Parents
  • zedhed
    0 zedhed over 10 years ago

    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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • paulclaessen
    0 paulclaessen over 10 years ago in reply to zedhed

    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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Reply
  • paulclaessen
    0 paulclaessen over 10 years ago in reply to zedhed

    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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube