NXP S32Z270DC2_R52 platform uses same MAC for every build

[benmordaunt]

The NXP S32Z270DC2_R52 platform uses the same MAC address for every build (specifically for the enetc_psi0 interface:

zephyr/boards/arm/s32z270dc2_r52/s32z270dc2_r52.dtsi

Line 108 in b423314

local-mac-address = [00 00 00 01 02 00];

instead of deriving it from EEPROM or similar.

As a result, attempting to network several of these boards together will fail at ARP resolution (layer 2). Is there not a unique partial MAC stored somewhere on this board/PHY?

Thanks,

Ben

[manuargue]

hi @benmordaunt. You can change the local-mac-address from your application DT overlay, or choose one of https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/ethernet/ethernet-controller.yaml#L9-L24

[benjaminmordaunt]

@manuargue Sure, that is what I am currently doing. However neither approach is particularly robust. local-mac-address has me guessing unique addresses, and random-mac-address gives the surprising behaviour of having a new MAC on each boot, which can cause issues with ARP caches.

Most embedded systems have an EEPROM somewhere with a factory-programmed partial (24-bit) MAC address which can be read. Is that not the case here?

I'm not sure it should be necessary to provide a DT overlay just to have unique MAC addresses...

[manuargue]

I understand the use-case. Not many Ethernet drivers in Zephyr do that out-of-the-box, only the Atmel SAM GMAC https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/ethernet/eth_sam_gmac.c#L1799-L1820

There's an on-board EEPROM that can be used for this purpose, but is not of my knowledge that it has a factory pre-programmed partial MAC address on it. I will consult with the hw design team and come back to you on this.

In the meantime, I'll mark this as a feature request instead of a bug.

[manuargue]

Hi @benjaminmordaunt. The on-board EEPROM does not contain factory-programmed MAC addresses and is there with the intention to support RCON boot, not for parameters storage. Although, this does not prevent the user to use the EEPROM for something else if RCON boot is not used, but the user would need to program it before booting Zephyr, provided there's a mechanism implemented in the Ethernet driver to pull the MAC address from a configurable memory address (actually more than one addresses since the NETC exposes multiple SI's plus the Switch ports). An alternative storage would be the fuse space.

I will keep this issue open while internally at NXP analyze if it's feasible and valuable to implement this use-case for Zephyr.
If you have further questions related to the hardware support, please reach out NXP through https://community.nxp.com/ or through your NXP communication channels.

[Dat-NguyenDuy]

Hello @benjaminmordaunt, sorry for a delay in response. As discussed last year, since the board does not contain unique factory-programmed MAC addresses, user would need program to store the MAC addresses into hardware before booting Zephyr.

Is you still interested this approach as a solution for the feature request? Thanks.

[manuargue]

closing as this ad-hoc feature request have been logged almost a year ago and currently there's no response from the author. If needed, it can be re-opened.