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

[Christoph Niedermaier <cniedermaier@dh-electronics.com>]

From: Marek Vasut <marex@nabladev.com>
Sent: Monday, March 23, 2026 3:59 PM
> On 3/23/26 11:07 AM, Christoph Niedermaier wrote:
> 
> [...]
> 
>>> The priority is this:
>>> - ENV -- because user can override the content, and user override is
>>> highest prio
>>> - Device not enabled in DT, do nothing
>>> - Fuses, (newly first fuse block 1 , then) fuse block 0 -- because
>>> in-SoC fuses always have to take precedence over the external EEPROM
>>> - EEPROM, first block 1, then block 0 -- because this is what is usually
>>> programmed out of factory, anything higher priority is up to the user
>>
>> The SoM is delivered with both MAC addresses coming from DH electronics provided
>> by EEPROMs. If a customer wants his own MAC, they can fuse the MAC address to
>> override it permanently, but referring to your suggestion if the customer only
>> fuse one MAC address the behavior depends on which MAC address is fused.
>>
>> Fuse only the first MAC address:
>> - 1. Ethernet: MAC is taken from FUSE 0
>> - 2. Ethernet: MAC is taken from FUSE 0 + incremented by one
>>
>> Fuse only the second MAC address:
>> - 1. Ethernet: MAC is taken from EEPROM
>> - 2. Ethernet: MAC is taken from FUSE 1
>>
>> The problem is that we have a customer with SoMs where only the first MAC address
>> was sequentially fused from a MAC address pool. That means the second MAC address
>> of the SoM is the same MAC address as the MAC address from the next SoM's first
>> MAC address. This patch prevents this by setting the MAC addresses independently
>> of one another. Then for the second MAC address the DH electronics MAC from the
>> EEPROM is used. In this patch the fallback where the first MAC address incremented
>> by one is used should not occur on the customer side, as the SoMs are shipped with
>> MAC addresses in the EEPROMs. If this does occur, however due to an EEPROM read
>> error or whatever this patch could be improved by a warning message.
> I don't understand this last sentence, can you please rephrase ? Keep in
> mind, not all MX8MP DHCOM were populated with both EEPROMs, the rev.100
> only had one EEPROM on them.

On the rev.100 the amount of populated EEPROM depends on the number of Ethernet
interfaces. One Ethernet interface means on EEPROM is populated and on a SoM
with two Ethernet interfaces two EEPROM are populated. The SoMs with two Ethernet
interfaces, in which only one EEPROM was populated, were prototype configurations.
This is no longer the case in the production series. This fallback can therefore
be removed.
In the last sentence I mean if the EEPROM can't provide a MAC address it is an
indication that something goes wrong and if the MAC address from the first MAC
fuse incremented by one is used a message could be displayed to inform about
that.

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

If I remove the eeprom0+1, because it was for prototype configurations,
my preferred order would be:

fuse1
eeprom1
fuse0+1


Regards
Christoph