Change Eth0 MAC address in OrinNX

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
,
1

We are working on Jetson Orin NX based custom board.

We want to Change [MAC address] of RTL8168h.

https://docs.nvidia.com/jetson/archives/r35.2.1/DeveloperGuide/text/HR/JetsonEepromLayout.html#SystemLevelPartNumber

Referring to the above URL, We overwrite MAC address[172-177] (0xac-0xb1) of EEPROM Customer-overwriteable section and last checksum.

//Before

# i2cdump -f -y 0 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 02 00 fe 00 00 00 00 00 00 00 00 ff 00 00 00 00    ?.?.............
10: 00 01 00 01 36 39 39 2d 31 33 37 36 37 2d 30 30    .?.?699-13767-00
20: 30 30 2d 33 30 30 20 47 2e 33 00 00 00 00 00 00    00-300 G.3......
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
40: b0 48 00 00 6a ea b7 2d b0 48 31 34 32 34 39 32    ?H..j??-?H142492
50: 32 30 33 35 38 35 37 00 00 00 00 00 00 00 00 00    2035857.........
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 4e 56 43 42 00 ff 4d 31 00 00    ......NVCB..M1..
a0: 00 00 00 00 00 00 00 00 00 00 00 00 6a ea b7 2d    ............j??-
b0: b0 48 01 00 00 00 00 00 00 00 00 00 00 00 00 00    ?H?.............
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6f    ...............?

//After

# i2cdump -f -y 0 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 02 00 fe 00 00 00 00 00 00 00 00 ff 00 00 00 00    ?.?.............
10: 00 01 00 01 36 39 39 2d 31 33 37 36 37 2d 30 30    .?.?699-13767-00
20: 30 30 2d 33 30 30 20 47 2e 33 00 00 00 00 00 00    00-300 G.3......
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
40: b0 48 00 00 6a ea b7 2d b0 48 31 34 32 34 39 32    ?H..j??-?H142492
50: 32 30 33 35 38 35 37 00 00 00 00 00 00 00 00 00    2035857.........
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 4e 56 43 42 00 ff 4d 31 00 00    ......NVCB..M1..
a0: 00 00 00 00 00 00 00 00 00 00 00 00 4c a1 6b 4c    ............L?kL //overwritable MACADDR
b0: 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00    ?.?............. //overwritable MACADDR
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 15    ...............?

After rebooting, MACADDR did not change.
It appears that the NVIDIA default MAC address[68-73] (0x44-0x49) are being used.

[   13.057325] r8169 0008:01:00.0: enabling device (0000 -> 0003)
[   13.080219] r8169 0008:01:00.0 eth2: RTL8168h/8111h, 48:b0:2d:b7:ea:6a, XID 541, IRQ 319

Could you please tell me how to reflect MACADDR in phy on OrinNX?

3

Hi,

Please check the r8169 driver directly. This behavior is decided by Realtek driver.

4

Hi,WayneWWW.

According to the Jetson EEPROM Layout documentation,

Customer-overwriteable MAC addresses.
If the type signature and version are valid, the boot software builds device tree nodes for these MAC addresses.

In my understanding,

1. The boot software creates DTB node with customer Ethernet MAC address
2. UEFI, kernel r8169 driver refers to DTB node
3. Customer Ethernet MAC address is set to eth0 in r8169 driver

Is this correct?

I checked to see if a DTB node was created in 1. No such node was found in OrinNX.

# ls- la /proc/device-tree/chosen/nvidia,
nvidia,sku                   nvidia,tegra-joint_xpu_rail

On the other hand, on the Jetson XavierNX-based custom board
nvidia,ether-mac existed with the customer MAC address set as follows

# hexdump -C /proc/device-tree/chosen/nvidia,ether-mac
00000000  30 30 3a 38 30 3a 34 63  3a 36 62 3a 61 30 3a 63  |00:80:4c:6b:a0:c|
00000010  33 00                                             |3.|
00000012

OrinNX does not create nvidia,ether-mac?
So you are saying that the above document is incorrect?

5

Hi

Are you using xavier nx devkit as carrier board or you are using your own custom board?

6

We are using own custom boards.

XavierNX CPU Module + custom board[A].
OrinNX   CPU Module + custom board[B].

board[A] and board[B] are designed separately.

7

Hi,

Please put your Orin NX devkit to xavier nx carrier board first. Check if there is nvidia,ether-mac.

8

Unfortunately, Orin NX devkit and xavier nx carrier board is not in hand at the moment.

I just checked the MACADDR get function in the r8169 driver.
It appears to be accessing the r8169 phy register.

[drivers/net/ethernet/realtek/r8169_main.c]

static void rtl_init_mac_address(struct rtl8169_private *tp)
{
	struct net_device *dev = tp->dev;
	u8 *mac_addr = dev->dev_addr;
	int rc;
	
	rc = eth_platform_get_mac_address(tp_to_dev(tp), mac_addr);
	if (!rc)
		goto done;
	
	rtl_read_mac_address(tp, mac_addr);
	if (is_valid_ether_addr(mac_addr))
		goto done;

	rtl_read_mac_from_reg(tp, mac_addr, MAC0);
	if (is_valid_ether_addr(mac_addr))
		goto done;
	
	eth_hw_addr_random(dev);
	dev_warn(tp_to_dev(tp), "can't read MAC address, setting random one\n");
done:
	rtl_rar_set(tp, mac_addr);
}

static void rtl_read_mac_address(struct rtl8169_private *tp,
				 u8 mac_addr[ETH_ALEN])
{
	/* Get MAC address */
	if (rtl_is_8168evl_up(tp) && tp->mac_version != RTL_GIGA_MAC_VER_34) {
		u32 value = rtl_eri_read(tp, 0xe0);

		mac_addr[0] = (value >>  0) & 0xff;
		mac_addr[1] = (value >>  8) & 0xff;
		mac_addr[2] = (value >> 16) & 0xff;
		mac_addr[3] = (value >> 24) & 0xff;

		value = rtl_eri_read(tp, 0xe4);
		mac_addr[4] = (value >>  0) & 0xff;
		mac_addr[5] = (value >>  8) & 0xff;

		printk("%s() mac_addr[0]=0x%02x\n", __FUNCTION__, mac_addr[0]);
		printk("%s() mac_addr[1]=0x%02x\n", __FUNCTION__, mac_addr[1]);
		printk("%s() mac_addr[2]=0x%02x\n", __FUNCTION__, mac_addr[2]);
		printk("%s() mac_addr[3]=0x%02x\n", __FUNCTION__, mac_addr[3]);
		printk("%s() mac_addr[4]=0x%02x\n", __FUNCTION__, mac_addr[4]);
		printk("%s() mac_addr[5]=0x%02x\n", __FUNCTION__, mac_addr[5]);

	} else if (rtl_is_8125(tp)) {
		rtl_read_mac_from_reg(tp, mac_addr, MAC0_BKP);
	}
}

[   12.944226] rtl_read_mac_address() mac_addr[0]=0x48
[   12.944228] rtl_read_mac_address() mac_addr[1]=0xb0
[   12.944230] rtl_read_mac_address() mac_addr[2]=0x2d
[   12.944232] rtl_read_mac_address() mac_addr[3]=0xb7
[   12.944234] rtl_read_mac_address() mac_addr[4]=0xea
[   12.944235] rtl_read_mac_address() mac_addr[5]=0x6a

[   12.961523] r8169 0008:01:00.0 eth2: RTL8168h/8111h, 48:b0:2d:b7:ea:6a, XID 541, IRQ 319

I don’t know why the driver is able to get NVIDIA default MAC addresses
by reading the r8169 phy address instead of I2C-EEPROM.

9

Hi,

Could you enable the UEFI log and share me the boot log with your ONX NG case?

10

Rebuild UEFI and write uefi_Jetson_DEBUG.bin to Orin NX Custom Board.

20230308_orin_nx_custom_board_uefi_log.txt (74.4 KB)

Even the UEFI Network Device List seems to use the default MAC instead of the Customer-overwriteable MAC.

/------------------------------------------------------------------------------\
|                             Network Device List                              |
\------------------------------------------------------------------------------/

   Network Device List                                   Network Device
 > MAC:48:B0:2D:B7:EA:6A

   Press ESC to exit.
11

Hi,

Just confirmed. That was done by the factory to the PCIe NIC directly. So this is not matching to the behavior as our other driver.

12

Are you saying that the default MAC address is written directly inside the RTL8169 chip at the factory?

I believe that the RTL 8169 chip and the I2C-EEPROM chip are separate CHIPs.

There is a MAC address with the same value stored in the I2C-EEPROM.
Isn’t the MACADDR value of the I2C-EEPROM used as the MACADDR of the RTL8169?

# i2cdump -f -y 0 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 02 00 fe 00 00 00 00 00 00 00 00 ff 00 00 00 00    ?.?.............
10: 00 01 00 01 36 39 39 2d 31 33 37 36 37 2d 30 30    .?.?699-13767-00
20: 30 30 2d 33 30 30 20 47 2e 33 00 00 00 00 00 00    00-300 G.3......
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
40: b0 48 00 00 6a ea b7 2d b0 48 31 34 32 34 39 32    ?H..j??-?H142492 //default MAC
50: 32 30 33 35 38 35 37 00 00 00 00 00 00 00 00 00    2035857.........

[   12.961523] r8169 0008:01:00.0 eth2: RTL8168h/8111h, 48:b0:2d:b7:ea:6a, XID 541, IRQ 319
13

I debugged UEFI, and it seems that Customer-overwriteable MAC
seems to be loaded in PopulateEepromData() as follows.
However, it is not used in the UEFI Network Device List.

ttps://github.com/NVIDIA/edk2-nvidia/blob/c647e59d6032aa721989e0824579de192b925277/Silicon/NVIDIA/Drivers/EepromDxe/Eeprom.c#L37

[nvidia-uefi/edk2-nvidia/Silicon/NVIDIA/Drivers/EepromDxe/Eeprom.c]

EFI_STATUS
EFIAPI
PopulateEepromData (
  IN  UINT8  *EepromData,
  OUT VOID   *BoardInfo
  )
{
...

  } else if (ChipID == T234_CHIP_ID) {
    T234EepromData  = (T234_EEPROM_DATA *)EepromData;
    EepromBoardInfo = (TEGRA_EEPROM_BOARD_INFO *)BoardInfo;
    CopyMem ((VOID *)EepromBoardInfo->BoardId, (VOID *)&T234EepromData->PartNumber.Id, BOARD_ID_LEN);
    CopyMem ((VOID *)EepromBoardInfo->ProductId, (VOID *)&T234EepromData->PartNumber, sizeof (T234EepromData->PartNumber));
    CopyMem ((VOID *)EepromBoardInfo->SerialNumber, (VOID *)&T234EepromData->SerialNumber, sizeof (T234EepromData->SerialNumber));

	DEBUG ((DEBUG_ERROR, "%a: CustomerBlockSignature = %x\r\n", __FUNCTION__, T234EepromData->CustomerBlockSignature));
	DEBUG ((DEBUG_ERROR, "%a: CustomerTypeSignature = %x\r\n", __FUNCTION__, T234EepromData->CustomerTypeSignature));

    if ((CompareMem (T234EepromData->CustomerBlockSignature, EEPROM_CUSTOMER_BLOCK_SIGNATURE, sizeof (T234EepromData->CustomerBlockSignature)) == 0) &&
        (CompareMem (T234EepromData->CustomerTypeSignature, EEPROM_CUSTOMER_TYPE_SIGNATURE, sizeof (T234EepromData->CustomerTypeSignature)) == 0))
    {
      CopyMem ((VOID *)EepromBoardInfo->MacAddr, (VOID *)T234EepromData->CustomerEthernetMacAddress, NET_ETHER_ADDR_LEN);
      EepromBoardInfo->NumMacs = T234EepromData->CustomerNumEthernetMacs;
    } else {
      CopyMem ((VOID *)EepromBoardInfo->MacAddr, (VOID *)T234EepromData->EthernetMacAddress, NET_ETHER_ADDR_LEN);
      EepromBoardInfo->NumMacs = T234EepromData->NumEthernetMacs;
    }

	DEBUG ((DEBUG_ERROR, "%a: EepromBoardInfo->MacAddr[0] %x\r\n", __FUNCTION__, EepromBoardInfo->MacAddr[0]));
	DEBUG ((DEBUG_ERROR, "%a: EepromBoardInfo->MacAddr[1] %x\r\n", __FUNCTION__, EepromBoardInfo->MacAddr[1]));
	DEBUG ((DEBUG_ERROR, "%a: EepromBoardInfo->MacAddr[2] %x\r\n", __FUNCTION__, EepromBoardInfo->MacAddr[2]));
	DEBUG ((DEBUG_ERROR, "%a: EepromBoardInfo->MacAddr[3] %x\r\n", __FUNCTION__, EepromBoardInfo->MacAddr[3]));
	DEBUG ((DEBUG_ERROR, "%a: EepromBoardInfo->MacAddr[4] %x\r\n", __FUNCTION__, EepromBoardInfo->MacAddr[4]));
	DEBUG ((DEBUG_ERROR, "%a: EepromBoardInfo->MacAddr[5] %x\r\n", __FUNCTION__, EepromBoardInfo->MacAddr[5]));

  } else {
    return EFI_UNSUPPORTED;
  }

  return EFI_SUCCESS;
}

add-symbol-file /build/nvidia-uefi/Build/Jetson/DEBUG_GCC5/AARCH64/Silicon/NVIDIA/Drivers/EepromDxe/Eeprom/DEBUG/EepromDxe.dll 0x4084F7000
Loading driver at 0x004084F6000 EntryPoint=0x004084FB248 EepromDxe.efi

PopulateEepromData: ChipID = 23
PopulateEepromData: CustomerBlockSignature = 36000286
PopulateEepromData: CustomerTypeSignature = 3600028C
PopulateEepromData: EepromBoardInfo->MacAddr[0] 4C
PopulateEepromData: EepromBoardInfo->MacAddr[1] A1
PopulateEepromData: EepromBoardInfo->MacAddr[2] 6B
PopulateEepromData: EepromBoardInfo->MacAddr[3] 4C
PopulateEepromData: EepromBoardInfo->MacAddr[4] 80
PopulateEepromData: EepromBoardInfo->MacAddr[5] 0
Cvm Eeprom Product Id: 699-13767-0000-300 G.3
Cvb Eeprom data validation failed(Success)

...
add-symbol-file /build/nvidia-uefi/Build/Jetson/DEBUG_GCC5/AARCH64/Silicon/NVIDIA/Drivers/TegraI2c/TegraI2cDxe/DEBUG/TegraI2cDxe.dll 0x4080F5000
Loading driver at 0x004080F4000 EntryPoint=0x004080FE2FC TegraI2cDxe.efi
PROGRESS CODE: V03040002 I0

PopulateEepromData: ChipID = 23
PopulateEepromData: CustomerBlockSignature = 25C99D2E
PopulateEepromData: CustomerTypeSignature = 25C99D34
PopulateEepromData: EepromBoardInfo->MacAddr[0] 4C
PopulateEepromData: EepromBoardInfo->MacAddr[1] A1
PopulateEepromData: EepromBoardInfo->MacAddr[2] 6B
PopulateEepromData: EepromBoardInfo->MacAddr[3] 4C
PopulateEepromData: EepromBoardInfo->MacAddr[4] 80
PopulateEepromData: EepromBoardInfo->MacAddr[5] 0
Eeprom Product Id: 699-13767-0000-300 G.3
TegraI2cStartRequest: No ACK received
Failed to read eeprom (No Response)
ValidateEepromData: CRC mismatch, expected 50 got AD
Eeprom data validation failed(Device Error)

20230308_orin_nx_custom_board_uefi_log2.txt (68.1 KB)

14

Hi,

The Orin NX MAC address is different from other platform. The NIC already had the mac address which is same as the one you saw in cvm eeprom in our factory.

There is no need to check UEFI code. The mac address of ONX is not from UEFI.

15

I understand that the default MAC address comes from the NIC.

So, what is the official way to use customer-overwritable MAC address
as MAC address for r8169, like XavierNX?
Is it currently not supported and will it be supported in the next Vesion (Jetpack 5.1.1)?

We would like to rewrite r8169 MACADDR to the original one when we ship the product.

Does what is written in the following article not apply to OrinNX?
Does the string Orin refer to Orin Nano at this moment ?

Eeeprom_OrinNX
Eeeprom_OrinNX958×335 63.8 KB

16

Hi,

Confirmed with internal team.

Is it currently not supported and will it be supported in the next Vesion (Jetpack 5.1.1)?

This is not supported and has no plan to support it either.

18

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.