Initializing MAC address at run-time

Uwe Kleine-König u.kleine-koenig at pengutronix.de
Wed Jan 18 10:54:35 PST 2017


Hello,

On Wed, Jan 18, 2017 at 03:03:57PM +0100, Mason wrote:
> When my system boots up, eth0 is given a seemingly random MAC address.
> 
> [    0.950734] nb8800 26000.ethernet eth0: MAC address ba:de:d6:38:b8:38
> [    0.957334] nb8800 26000.ethernet eth0: MAC address 6e:f1:48:de:d6:c4
> 
> 
> The DT node for eth0 is:
> 
> 	eth0: ethernet at 26000 {
> 		compatible = "sigma,smp8734-ethernet";
> 		reg = <0x26000 0x800>;
> 		interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
> 		clocks = <&clkgen SYS_CLK>;
> 	};
> 
> Documentation/devicetree/bindings/net/ethernet.txt mentions
> - local-mac-address: array of 6 bytes, specifies the MAC address that was
>   assigned to the network device;
> 
> And indeed, if I define this property, eth0 ends up with the MAC address
> I specify in the device tree. But of course, I don't want all my boards
> to share the same MAC address. Every interface has a unique MAC address.
> 
> In fact, the boot loader (not Uboot, a custom non-DT boot loader) stores
> the MAC address somewhere in MMIO space, in some weird custom format.

Where does your machine get the dtb from? You write it to the boot
medium at a certain point of time I assume. So AFAICT you have the
following options (in no particular order):

 a) Describe in the dtb how to find out how the MAC address is stored
    (already pointed out Mark and Robin)
 b) Make your bootloader dt aware and let it provide the
    local-mac-address property.
 c) Adapt the dtb before it is written to the boot medium.
 d) Let the bootloader configure the device and teach the driver to pick
    up the mac from the device's address space.
 e) Accept that the mac address is random during development, and make
    Userspace configure the MAC address, which is early enough for
    production use.

Not sure d) is considered ok today, but some drivers have this feature.
I'd say b) is the best choice.

> I need to do something similar with the NAND partitions. The boot loader
> stores the partition offsets somewhere, and I need to pass this info
> to the NAND framework, so I assumed that inserting the corresponding
> properties at run-time was the correct way to do it.

The list of options here is similar to the list above. d) doesn't work,
but instead you can pass the partitioning on the kernel commandline.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |



More information about the linux-arm-kernel mailing list