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

[Marek Vasut]

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.

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.