From: Marek Vasut <[email protected]> Sent: Saturday, March 28, 2026 12:12 AM > On 3/27/26 11:02 PM, Christoph Niedermaier wrote: >> From: Marek Vasut <[email protected]> >> 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
