The MAC address of every ethernet interface should normally be globally unique, and it technically has to be unique within its ethernet broadcast domain. To achieve this, the manufacturer usually allocates a block of MAC addresses from a centrally-administered pool (for which a fee has to be paid) and preconfigures one of these addresses on each item sold.

In the case of development boards, sometimes the manufacturer wants to avoid paying these fees and therefore provides no globally unique addresses. In these cases the users themselves have to define MAC addresses for their systems. When no MAC address is defined for an ethernet interface, some network drivers generate a random MAC address that can change on every boot, and if this happens, network access would be possible even when the user has not manually set an address, but e.g. assigning semi-static IP addresses by DHCP based on the MAC address of the requesting client would obviously not work reliably.

To avoid conflicts with existing officially-assigned MAC addresses, there is an address pool which is reserved for so-called “locally administered” addresses. It is defined by the value of two specific bits in the first byte of the address (the article “MAC address” in the English language Wikipedia gives a good explanation). In practice this means that e.g. any address starting with hexadecimal ca (such as ca:ff:ee:12:34:56) can be used as a locally administered address.

On systems using U-Boot as system firmware, the ethernet MAC address is placed in the “ethaddr” environment variable. It can be checked at the U-Boot command prompt with the command “printenv ethaddr” and can be set with the command “setenv ethaddr ca:ff:ee:12:34:56”. After setting the value, the command “saveenv” makes the assignment permanent.

On some systems with older U-Boot versions there can be problems with properly relocating the Linux kernel, the initial ramdisk and the device-tree blob in memory during the boot process. In this case, U-Boot shows the message “Starting kernel ...”, but the system freezes afterwards without further output. These issues have been solved with newer U-Boot versions from v2014.07 onwards.

If the system has originally used a U-Boot version older than v2014.07 and has been upgraded to a newer version later, the problem might still occur even after upgrading U-Boot. Upgrading U-Boot usually does not modify the existing U-Boot environment variables and the fix requires an additional environment variable (bootm_size) to be set, which U-Boot does automatically only on fresh installations without existing environment data. It is possible to manually set bootm_size to the new U-Boot's default value by running the command “env default bootm_size; saveenv” at the U-Boot prompt.

Another possibility to circumvent relocation-related problems is to run the command “setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv” at the U-Boot prompt to completely disable the relocation of the initial ramdisk and the device-tree blob.