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
