eth_nxp_enet : get mac address from eeprom

[mspeder]

Is your enhancement proposal related to a problem? Please describe.
When used in production environment all devices must have different "real" mac addresses.
Using a random (or derived from device id) mac address is not acceptable nor is using a common fixed mac supplied by the device tree thru local_mac_address property. It is very common to use an eeprom to provide the mac address.

Describe the solution you'd like
We need a way to provide mac address using an eeprom with eth_nxp_enet, like we already have on other ethernet drivers like eth_sam_gmac.

Similar to the eth_sam_gmac, configuration would be controlled by new optional device tree properties : ETH_NXP_ENET_MAC_I2C_EEPROM,
ETH_NXP_ENET_MAC_I2C_ADDRESS.

Thanks in advance for your feedback.
If that's ok I can submit a PR.

[yuecelm]

did you tried nxp,fused-mac? there is also the option to use nxp,unique-mac in order to get a static mac address:

&enet_mac {
        /delete-property/ zephyr,random-mac-address;
        //nxp,fused-mac; // not working, seems not be available on mimxrt1050_evk board
        nxp,unique-mac;
};

further docs: https://docs.zephyrproject.org/latest/build/dts/api/bindings/ethernet/nxp,enet-mac.html

[yuecelm]

maybe you also need to cherry pick this commit: 931628a

[mspeder]

@yuecelm thanks for the feedback.
I agree fused mac would have been a good solution, but unfortunately not existing on my MK64 SoC, where there is no such concept of fuses.
"unique-mac" is the solution I was referring to when I mentioned "derived from device id". Unfortunately this generates a fake mac using the device id. As mentioned in the doc, while this can be useful for testing or demos, this is not a valid option for production where we need "real" addresses.

[henrikbrixandersen]

Instead of adding Kconfig options for this, I'd like to see Ethernet drivers move towards the devicetree solution outlined here: #74835 (comment)

[mspeder]

@henrikbrixandersen thanks for the feedback. I totally agree that a pure device tree solution would be more elegant.

I see two options in the thread you mentioned.
1/ the simple mac-eeprom = <&eeprom 0x00> mentioned by @pdgendt
2/ the more complex with with nvmem-cells

I didn't find any usage of this nvmem-cells approach elsewhere in zephyr. Does it make any assumption on the kind of underlying storage ? Not sure to understand how do I know which api to call to access this (as opposed to the already existing and explicit eeprom api implied by the first syntax) ?

Since this need is going to be replicated in multiple eth drivers, it looks like some standardisation would be beneficial. As I am new to the zephyr community, I am not sure how do we reach some kind of common approach ?

Also adding @decsny to this discussion, since he made most of the recent contributions to this part of the eth_nxp_driver.

[decsny]

"unique-mac" is the solution I was referring to when I mentioned "derived from device id". Unfortunately this generates a fake mac using the device id. As mentioned in the doc, while this can be useful for testing or demos, this is not a valid option for production where we need "real" addresses.

I am glad to know the doc of that property was useful

[ofirshe]

@mspeder Are you planning to support this? We have a custom board with the RT1061 microcontroller, along with an external EEPROM, and I need to load the MAC address from it on boot time.

[decsny]

@mspeder , @ofirshe , is there a reason you can't just use the eeprom API to read the mac address and then use the ethernet API to set the MAC address? why would this be supported in the ethernet driver or really anywhere in the network stack? it is an application/system design choice

[mspeder]

@decsny This is certainly possible since it's the workaround I ended up using. However, as a side effect, you have to disable network stack auto-init; otherwise, early packets with a bogus MAC may slip through. Essentially, the driver first initializes the hardware with an incorrect address, then you manually change it, and finally, you need to initialize the network stack yourself.

This isn't a very clean approach, in my opinion. It feels like the NXP-ENET driver is currently stuck in between. It's cluttered with unnecessary options (who seriously uses a random MAC in real-world applications nowadays?) while lacking a quite common way of doing things that some other Zephyr Ethernet drivers already provide.

[ofirshe]

I agree with @mspeder.
Since the MAC address is initialized first in the driver, your approach does not guarantee that packets with a wrong MAC address won’t be transmitted. We have many custom boards with EEPROM, and we need the ability to dynamically load the MAC address from them at boot. Currently, the driver does not provide an option for this.
@mspeder Are you planning to submit a PR for this?