On 3/27/26 11:02 PM, Christoph Niedermaier wrote:
From: Marek Vasut <[email protected]>
Sent: Monday, March 23, 2026 6:21 PM
On 3/23/26 5:49 PM, Christoph Niedermaier wrote:
[...]
As for the rest, it really boils down to the ordering of fallbacks, it
is either:
A)
fuse1
eeprom1
fuse0+1
eeprom0+1
or
B)
fuse1
fuse0+1
eeprom1
eeprom0+1
The following ordering, which is the ordering introduced by this patch,
is confusing:
fuse1
eeprom1
eeprom0+1
fuse0+1
So please pick either A) or B) above. I do not see any particular
advantage of either of the other, except maybe B) improves boot time in
case both fuse blocks are blown, because it avoids the EEPROM I2C access.
The prevention of I2C access is only a one time effect, because then the
MAC addresses will provided by the environment.
Which increases the system boot time, which is undesired.
If a customer sequentially fuse only the first MAC address from a MAC address
pool. Then the second MAC address of the SoM is the same MAC address as the MAC
address from the next SoM's first MAC address. That is very bad. With the A)
it can be avoided, because the second MAC address then is taken from the EEPROM.
This edge case can be fixed on first boot in a boot script. Read out the
fuse using "setexpr var *addr", detect whether the fuse is empty using
"if test ...", and if it empty, then populate its content with EEPROM
content. This saves you one extra I2C operation on every boot afterward.
If I had to choose between reducing the boot time once and preventing potential
duplicate MAC addresses, I would say that preventing potential duplicate MAC
addresses is the better option. Furthermore, the issue of duplicate MAC
addresses
in the system is not a hypothetical scenario, it has already occurred in
practice.
If I remove the eeprom0+1, because it was for prototype configurations,
my preferred order would be:
fuse1
eeprom1
fuse0+1
eeprom0 can not be removed, that breaks backward compatibility. And the
ordering of fuse-eeprom-fuse is confusing and has the boot time increase
downside of A).
For which SoM should backward compatibility be maintained here. There is
no SoM at the customer's site where it is required. For rev.200 the EEPROM
ID page is used, for rev.100 only some internal SoM prototypes with two
Ethernet interfaces had only the first EEPROM populated. It's not worth
keeping that code.
So yes, eeprom0 can not be removed, because it also contains the WLP.
I would say B) is the way to go, it should also cover your requirements,
keeps the boot time low if both fuse banks are fused (which can be fixed
even on existing hardware, simply read out eeprom content and fuse it
into fuse bank 1), and it retains the priority ordering (env, fuse,
eeprom) without mixing it up.
The case that only the first MAC address is fused and not the second one is
a special case, but if this happens, with the order A) above you can prevent
duplicate MAC addresses from appearing in the system. In addition, if you want
to fix it, it's dangerous to fuse the second MAC address at the customer's
location, because if something goes wrong during the fusing, the device must
be replaced on-site. This can also be avoided with order A).
If this is a special case, then please convert it into a common case, so
the generic code upstream can be kept that, generic.
If this special case can not be converted to common case, then add local
patch to handle that specific device.
