[PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

From: Marek Vasut <marex at nabladev.com>
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.
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.

> 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).


Regards
Christoph