Hi Quentin,
thanks for the review!
> You could set the eth2addr in your board file if you wanted instead of
> setting it for everybody.
We provide OS images for everyone, and our users complained about the
changing MAC addresses. I agree with them that generally the exception
is that MAC addresses are static by default, and randomising them being
an optional privacy feature when connecting to untrusted networks, like
a WiFi hotspot with a mobile phone. Setting eth2addr in boot
script/environment would require a random MAC address generation our end
on first boot or so on each system, to rule out collisions. Since U-Boot
has the feature implemented already, it just makes sense to make use of
it and extend it for the affected Rockchip builds, also to have the
somewhat nicely aligned with the last digit deferring only. So we
currently patch our sources.
> What's the number when we'll decide this is too many? I have a board
> with 5 Ethernet ports for example :)
Good question. In Germany we say "Aller guten Dinge sind drei" (All good
things come in threes). Jokes aside: not sure whether there are Rockchip
SoC boards which provide more Ethernet NICs, but I have 3 with 3 ones
(in one case provided by an official expansion board), all RK3588 with
two onboard PCIe adapters. There is another PCIe bus, but commonly used
for an M.2 socket, not sure whether it could theoretically provide a 4th
Ethernet adapter. I don't know the background about why the Ethernet
driver/firmware is not able to read/assign the hardware MAC, or why
there is no hardware MAC, as I understand that this is an IEEE
requirement. So what U-Boot does seems a workaround, and I agree that,
if there is no generic approach, it has limits.
> I don't know how far we want to go to avoid defining unused ethXaddr
> variables in the environment? We could use of_alias_get_highest_id for
> example and generate enough environment variables based on that info?
This sounds reasonable. But are ethXaddr variables not generated before
boot scripts are called, when the number of alias IDs cannot be known
yet, and MAC addresses assigned afterwards, when the OS device tree was
loaded? When generating the variables afterwards, all good, but then
existing values assigned by boot script/env should not be overwritten,
of course. Then a generic approach would be possible, incrementing the
bit mask by one each loop, to assign up to a quite large number of MAC
addresses to ethernet aliases.
Best regards,
Micha (aka MichaIng)
DietPi project lead
