2381692_en-US

[#1]

MCXN547 - Best approach to load Ethernet MAC address from IFR (CMPA) at runtime?

Hello,

We are developing a product based on the MCXN547 with Zephyr RTOS 4.3.0. As part of our factory provisioning process, we program a unique EUI64 per unit into the CMPA region of the IFR (at address `0x01004190`), using the MCUXpresso Secure Provisioning Tool. From this EUI64 we derive the 6-byte Ethernet MAC address.

We would like the Ethernet driver to automatically use this MAC address at boot, instead of a static `local-mac-address` in the devicetree.

We have verified that the CMPA region at `0x01004190` is directly readable at runtime via memory-mapped access (`devmem` confirmed this).

Our question: What is the recommended approach to have the `nxp,enet-qos-mac` driver (used by the MCXN547) read the MAC address from a custom location in the IFR/CMPA at startup?

We are aware that the classic `nxp,enet-mac` driver supports `nvmem-cells` for this purpose, but we are not sure if this is also supported or achievable with the `nxp,enet-qos-mac` driver, and what the correct devicetree configuration would be for the MCXN547.

Any guidance or example from NXP or the community would be greatly appreciated.

Environment:
- MCU: MCXN547
- Zephyr: 4.3.0 (NXP fork nxp-v4.3.0)
- Driver: `drivers/ethernet/eth_nxp_enet_qos/eth_nxp_enet_qos_mac.c`
- IDE: VS Code + MCUXpresso extension
- Provisioning: MCUXpresso Secure Provisioning Tool

MCXNRe: MCXN547 - Best approach to load Ethernet MAC address from IFR (CMPA) at runtime?

If you're willing to try an alternative route, you can try Mongoose with its built-in TCP/IP stack. Mongoose allows you to redefine MG_SET_MAC_ADDRESS to your custom function.

To try,
1. Disable Zephyr TCP/IP in your project conf
2. Create mongoose/ directory, and copy mongoose.c and mongoose.h from https://github.com/cesanta/mongoose
3. Create mongoose_config.h with this:

#pragma once

// See https://mongoose.ws/documentation/#build-options
#define MG_ARCH MG_ARCH_ARMGCC
#define MG_OTA MG_OTA_MCXN

#define MG_ENABLE_TCPIP 1
#define MG_ENABLE_DRIVER_MCXN 1
#define MG_ENABLE_CUSTOM_MILLIS 1

// extern void my_function(unsigned char *mac);
// #define MG_SET_MAC_ADDRESS(mac) my_function(mac)

4. Implement "uint64_t mg_millis(void)" to return number of milliseconds since boot.

Make a Zephyr task that runs mongoose, give it 8kb stack:

struct mg_mgr mgr;
mg_mgr_init(&mgr);
for (;;) mg_mgr_poll(&mgr, 1);

And that should be it.  Redirect printf to UART to see debug logs. Also, Mongoose gives you CRA-ready OTA built-in, https://mongoose.ws/ota/

There is a pre-built test project for a slightly different MCU, https://github.com/cesanta/mongoose/tree/master/tutorials/nxp/frdm-mcxn947-make-baremetal-builtin - close mongoose repo and type "make" in that directory to build, that needs make and ARM GCC installed.

Re: MCXN547 - Best approach to load Ethernet MAC address from IFR (CMPA) at runtime?

Hi @Jorini 

Thank you for the post!

You could follow the Zephyr documentation using the option to change the MAC address at runtime: MAC Address Configuration — Zephyr Project Documentation

Please let me know if this information helps! 

Re: MCXN547 - Best approach to load Ethernet MAC address from IFR (CMPA) at runtime?

Thank you both for the suggestions!

Regarding the mac_config.html approach: we looked into it and agree it is the "clean" Zephyr way to do this. However, it requires modifying eth_nxp_enet_qos_mac.c to call net_eth_mac_load(), adding nvmem-cells support to the nxp,enet-qos-mac binding, and having an nvmem provider for the CMPA/IFR region — none of which exist in Zephyr 4.3 for the MCXN547. So while it is the right long-term direction, it is not directly applicable today.

Regarding Mongoose: it is an interesting option for new projects starting from scratch, but in our case it would mean replacing the entire Zephyr network stack and rewriting all our networking code (DHCP, TLS, HTTP, OTA, socket-based cloud communication). The cost is not justified given that we already have a working solution.

What we ended up doing — and it works correctly in production — is using two SYS_INIT hooks in our application code, with no changes to the driver:

1. POST_KERNEL priority 83: overwrite the ENET QOS hardware registers (MAC_ADDRESS0_HIGH/LOW at 0x40100300/304) right after the driver initializes at priority 82. This ensures the MAC chip filters frames with the correct address.

2. APPLICATION priority 1: update the Zephyr software network interface table (net_if link_addr). Without this second step, Zephyr's IP stack silently discards all incoming frames because the SW MAC does not match the HW MAC.

Thanks you