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

[Marek Vasut]

On 3/27/26 11:02 PM, Christoph Niedermaier wrote:
> 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.

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.