We are currently preparing for the mass production (MP) of a custom carrier board based on the NVIDIA Jetson platform. To support complex hybrid networking applications, our design integrates multiple network interfaces:
Marvell AQR113C (10GbE)
TI DP83867 (1GbE)
Realtek RTL8126 (5GbE, via PCIe)
Regarding the management and provisioning of MAC addresses during the production stage, we would like to clarify the following technical details:
MAC Address Storage Architecture
We are evaluating the most reliable method for persistent MAC address storage. In NVIDIA’s standard reference design:
SOM EEPROM: Does the built-in EEPROM on the SOM reserve space for customers to define additional MAC addresses to support multi-NIC configurations?
Carrier Board EEPROM: If we need to store MAC addresses for these specific PHYs/NICs on the carrier board, does NVIDIA recommend a dedicated EEPROM design? Furthermore, if the carrier board EEPROM is removed, what are the recommended alternative access mechanisms at the firmware level (UEFI/Kernel)?
Official Procedures and Documentation
Does NVIDIA provide a Standard Operating Procedure (SOP) for MAC address provisioning in a production environment? Specifically:
Software Access Mechanism: Is it preferred to read the MAC address from the EEPROM via the Bootloader and pass it to the Kernel command line, or should it be injected dynamically using the local-mac-address property in the Device Tree (DTS)?
Special Partitioning: Does NVIDIA support storing MAC addresses in a specific eMMC partition (e.g., customer_data) to be read and assigned during the boot sequence?
Reference Materials: Please provide any official Application Notes or technical documentation regarding EEPROM layout or MAC burning tools.
Management Logic for Multiple Network Interfaces
Given that our design runs 10G, 5G, and 1G interfaces simultaneously—each with different driver architectures and use cases:
Within the BSP (Board Support Package), what is the best practice for assigning and binding multiple MAC addresses to ensure there are no address conflicts or interface identification errors during mass production?
We look forward to your professional guidance on these matters.
We are currently scaling our development across the entire NVIDIA Jetson family and preparing for Initial Mass Production (Risk Production). Our carrier board designs are primarily based on NVIDIA reference architectures with minor modifications and re-configurations.
As we finalize our production pipeline, I would like to discuss the Hardware MAC Address programming for different Ethernet PHYs/Controllers across our lineup:
Jetson Thor (T5000): Utilizing Realtek RTL8126.
Jetson Orin: Utilizing Marvell AQR113C and TI DP83867.
We are maintaining a unified source code tree for the Orin, NX,AGX, and Nano series.
Our Core Question:
Based on current industry standards and NVIDIA’s reference designs, how are the MAC addresses typically programmed during the manufacturing process? Specifically, do existing development boards or reference designs utilize a dedicated EEPROM, eFuse, or a specific vendor tool for MAC address burning at the factory level?
We want to ensure our production methodology aligns with NVIDIA’s best practices to mitigate any risks during the first batch of mass production.
I don’t know if you are familiar with the interface level things.
If the PHY is running on our EQOS or MGBE interface which runs with nvethernet driver, then the MAC address basically is from the CVM EEPROM.
If the NIC is a PCIe card, then most likely the MAC address is read from the efuse memory of the PHY.
Back to your platforms
Jetson Thor (T5000): Utilizing Realtek RTL8126.
→ This is a PCIe card so mac addr is from the efuse.
Jetson Orin: Utilizing Marvell AQR113C and TI DP83867.
→ One of the MAC address will be from the CVM EERPOM. The rest one is undefined.
also uncertain if you already bring up “TI DP83867” because we saw many users failing to bring up this one.
If you already bring this up, then maybe sharing your software configuration could help others. Thanks.
Thank you for your assistance and detailed reply. Regarding the hardware configuration and MAC address management of the CVM EEPROM, I would like to align on a few technical details:
EEPROM Allocation Confirmation: According to NVIDIA design specifications, the CVM EEPROM is located on the SOM (Module) side, whereas the Carrier Board typically houses the CVB EEPROM. Our current custom carrier board design does not include an EEPROM by default. Will this absence impact the system’s ability to read SOM information or affect the overall boot flow?
MAC Information Update Mechanism: Concerning the maintenance of CVM EEPROM content, is it possible to use the tegra-eeprom-tool to add an additional MAC address (e.g., for a second Ethernet port) or directly update existing fields? Furthermore, are there any specific constraints we should be aware of in practice, such as hardware Write Protection (WP) or CRC checksum recalculation requirements?
In terms of design, my first Mass Production (Risk Production) priority was to adhere to Nvidia’s design principles.
This is not the problem because the EEPROM that would be in use is only the CVM one. So lacking of a EEPROM on your carrier board is okay.
MAC Information Update Mechanism: Concerning the maintenance of CVM EEPROM content, is it possible to use the tegra-eeprom-tool to add an additional MAC address (e.g., for a second Ethernet port) or directly update existing fields? Furthermore, are there any specific constraints we should be aware of in practice, such as hardware Write Protection (WP) or CRC checksum recalculation requirements?
This is a 3rdparty tool so I am uncertain if it would work fine or not. You could directly modify the original MAC address we are reading now. But remember to update the CRC bit in byte 255. Otherwise it would have flash problem in your later flash attempt.
There is no WP enabled in the default CVM EEPROM setting but only the CRC checksum mechanism.
