Actions
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

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

Parents
  • 0

    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

Reply
  • 0

    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

Children
No Data