Hi Quentin,
> Please keep the ML in Cc.
Was too late for me yesterday :).
> We currently have 137 defconfigs for Rockchip boards (git grep -l
> ARCH_ROCKCHIP configs/ | wc -l), so not sure 3 is a reasonable
threshold :)
I mean just for us/me, coding efforts and maintaining a patch, it is
easier to do it right there, where it is done right now for ethaddr and
eth1addr already for all Rockchip boards, instead of creating overrides
for 3 particular boards. I hope an additional eth2addr is fine for now,
until we found a better/more generic solution.
> 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).
Yes, whatever we do, it should be a non-breaking addition, at last for
now, just generating those MAC addresses for existing ethernet* aliases,
which have no related variable assigned yet. And seeing the different
approaches on getting the first/initial ethaddr to derive further ones
from, I think a new generic method needs to work on top of an existing
ethaddr variable, generated in current board-specific way, or defined in
boot env/script.
I also wondered about sunxi adjusting the first byte. Since the first
block contains also unicast/multicast bit etc, I would always prefer
varying addresses from the back, so the same method can theoretically be
continued for a lot more MAC addresses, before running into bits we must
not change. We can assign already 16 MAC addresses with the last xdigit
only, when incrementing the bitwise mask by 1 each iteration, and apply
it on the original ethaddr each time? And as far as I can think about
it, incrementing it further to span the second last xdigit, hence the
whole last MAC address block, would work just the same way, able to
handle ethernet0 - ethernet255, theoretically.
> 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.
U-Boot assigns those variables to ethernet aliases on its own device
tree as well? Would be reasonable, but for me this is minor. At least I
did not hear from a case where someone was complaining about a random
MAC address for network boot.
What I aim for is U-Boot assigning static MAC addresses to ethernet
aliases defined in/for the kernel device tree, better in a more generic
than specific way, so it does not need to be changed again each time a
new SBC (with new SoC) with multiple onboard Ethernet adapters arrives.
Adding the aliases to the kernel device tree is then a different topic,
not related to U-Boot, which I however aim to achieve upstream as well.
If U-Boot syncs these back, it allows static MAC addresses for related
adapters in U-Boot phase as well, of course.
> 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.
That could happpen already now with the often at least 2 aliases
defined. I wonder whether it can cause issues with PXE boot etc. In the
cases I know, a dedicated dtb is shipped as well, and I am not even sure
whether the network connection remains the same between U-Boot phase and
kernel phase? In any case, as long as any new generic MAC assignment
does not overwrite existing eth*addr variables, and does not generate
new/different MAC addresses for ethernet* aliases which have a related
eth*addr variable, it should not be able to break anything, but only
turns all those MAC addresses to static, which are otherwise random.
Best regards,
Micha (aka MichaIng)
DietPi project lead
Am 18.06.2025 um 11:49 schrieb 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
