[PATCH] rockchip: board: assign up to 3 static Ethernet MAC addresses

[Quentin Schulz]

Hi Micha,

Please keep the ML in Cc.

On 6/18/25 3:05 AM, MichaIng wrote:
> Hi Quentin,
> 
>  > I didn't mean to suggest to have this as part of the boot script. Board
>  > file (for me) is any file in the board/ directory which applies to a
>  > board. See board/theobroma-systems/ringneck_px30 for example.
>  >
>  > There you could replace misc_init_r entirely, or define your own
>  > rockchip_early_misc_init_r (like I do in board/theobroma-systems/
>  > ringneck_px30/ringneck-px30.c for example) or add a
>  > rockchip_late_misc_init_r callback after the ethernet addresses if you
>  > want?
>  >
>  > That's what I was suggesting essentially.
> 
> Ah I see. Since it affects 3 different Rockchip boards relevant for me/ 
> us, potentially more, doing it for all Rockchip boards seems reasonable, 

We currently have 137 defconfigs for Rockchip boards (git grep -l 
ARCH_ROCKCHIP configs/ | wc -l), so not sure 3 is a reasonable threshold :)

> at least less code in one place. I will probably start to work on the 
> Orange Pi R2S soon, a RISC-V board with 4 Ethernet adapters, which will 
> most likely have random MAC addresses as well. So actually I would vote 
> for a more generic solution which works the same way on all hardware. I 

I am not too fond of how we handle the random MAC addresses in Rockchip 
either, we should be able to make this more generic indeed.

Now I see a possible issue in that. I believe the random MAC addresses 
are constant across reboots for a given board since it's based on the 
CPU ID. I am assuming we should be keeping this stable if we make the 
thing more generic. Sunxi seems to be setting the first byte of the MAC 
address depending on the ethernet controller index. Rockchip seems to be 
XOR'ing the last bit of the last byte (and you were looking into 
extending this to the 2LSB of the last byte for up to 4 addresses). So 
we already have different expectations of how the random MAC addresses 
need to be computed.

We could have a generic implementation that is overridable for 
boards/vendors or architectures (e.g. via weak symbols for example).

> see the argument to not bloat the environment with often unused 
> variables, so makes sense to generate those MAC addresses on demand only.
> 
> As you mention misc_init_r, I see sunxi boards override/use it to do it 
> more that way: check for aliases ethernet0-4 in a loop, and generate an 
> eth*addr variable only if the alias exist, and the variable does not: 
> https://eur02.safelinks.protection.outlook.com/? 
> url=https%3A%2F%2Fgithub.com%2Fu-boot%2Fu- 
> boot%2Fblob%2Fmaster%2Fboard%2Fsunxi%2Fboard.c%23L776- 
> L795&data=05%7C02%7Cquentin.schulz%40cherry.de%7C464204d1dfa844099a4208ddae0443dc%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638858055555459309%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FD%2Fr88eFxZY%2Bf%2FMafL6AftJVswiA4uVClC1Hqn3xM1M%3D&reserved=0
> But since it generates variables, I assume it is called before boot 
> scripts and hence is based on the ethernet* aliases defined in U-Boot's 
> device tree, rather than the kernel device tree, right? I mean I aim to 

Yes. Remember that some boards do use U-Boot DTB as kernel DTB as well, 
so it's not that easy of a shortcut for everything supported by U-Boot.

> send Linux patches to add those to respective device trees as well, if/ 
> once this U-Boot patch gets merged, and those might be synced back into 
> U-Boot device trees. But since this is all done on/for the kernel device 
> tree, I would prefer it to depend on kernel dtb aliases only.
> 

Not sure to understand what you want to do here or what's the issue sorry.

You need also eth*addr for use in U-Boot (if you do PXE, TFTP, ping, 
whatever involving networking) so it makes sense to have them in U-Boot 
DT as well.

You can anticipate ethernet aliases being in DT of future Linux kernel 
releases by adding a temporary -u-boot.dtsi with a few properties in 
/chosen/aliases matching the ones in the Linux kernel. Once synced you 
can remove them. Note that obviously unless your system uses the exact 
same binary for U-Boot DTB and kernel DTB, you cannot guarantee that the 
aliases will point to the same controllers for example, so ethernet2 in 
U-Boot may point to ethernet1 in kernel for example, in which case MAC 
addresses may all get swapped between U-Boot and kernel. This is 
theoretically possible, not sure how likely it is to happen though.

> Wouldn't it be possible to generate and generate and apply the MAC 
> addresses [here](https://eur02.safelinks.protection.outlook.com/? 
> url=https%3A%2F%2Fgithub.com%2Fu-boot%2Fu- 
> boot%2Fblob%2Fmaster%2Fboot%2Ffdt_support.c%23L645- 
> L664&data=05%7C02%7Cquentin.schulz%40cherry.de%7C464204d1dfa844099a4208ddae0443dc%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638858055555480725%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zes5ZQmR4du9dygIIf6HLT2cVO5yWR2b5dwbaLzpWDA%3D&reserved=0), hence for all actually existing aliases, and only as fallback if the respective eth*addr variable is not set?
> If the method for obtaining the first ethaddr differs between boards, it 
> could still rely on an existing ethaddr variable, to derive different 
> MAC addresses for each ethernet* alias index in a consistent way.
> 

I guess. I would rather have a fallback whenever env_get(mac) doesn't 
return successfully, in which case you can attempt to generate one 
randomly based on some callback. This would cover the case when you have 
a kernel DT with etherent aliases not present in U-Boot DT, this is 
reasonable for boards with adapters covered by Device Tree Overlays for 
example, which don't need to necessarily be applied on U-Boot DTB.

Cheers,
Quentin