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

[Christoph Niedermaier]

From: Marek Vasut <marex at nabladev.com>
Sent: Saturday, March 28, 2026 12:12 AM
> 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.

With the right order all typical scenarios can be covered and also the
"edge case" is avoided.

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

Will do this in V2.

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

I'll try to implement that in V2.


Regards
Christoph