Random MAC. Is this Orin NX 16GB module faulty?

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

Hi,

We’ve flashing a new batch of Orin NX 16GB modules, the first with SK Hynix we’ve received (which has rendered our recovery images useless, but that’s a different story). We’re using R36.4.0 and our own carrier board.

The 2D matrix on the label decodes to:
1614824601937,3C6D662238BB,699-13767-0000-301,161-0546-10X

This one module has a random ethernet MAC address assigned on every boot, with the driver complainig:
[ 3.915382] r8168 0008:01:00.0 (unnamed net_device) (uninitialized): Invalid ether addr 00:00:00:00:00:00
[ 3.915387] r8168 0008:01:00.0 (unnamed net_device) (uninitialized): Random ether addr 4e:52:f9:86:23:0e

The EEPROM doesn’t seem corrupted, and it can be dumped with 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 35 30 30 00 00 00 00 00 00 00 00 00 00    00-500..........
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
40: b0 48 00 00 bb 38 22 66 6d 3c 31 36 31 34 38 32    ?H..?8"fm<161482
50: 34 36 30 31 39 33 37 00 00 00 00 00 00 00 00 00    4601937.........
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 bb 38 22 66    ............?8"f
b0: 6d 3c 01 00 00 00 00 00 00 00 00 00 00 00 00 00    m<?.............
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 e6    ...............?

We’ve tried flashing using a backup image taken from another successfully flashed module from the same batch, and from scratch passing --flash-only to the l4t_initrd_flash.sh script. No difference.

Is this a faulty module that should be returned?

Thanks in advance for your help.

2

Hi,

Please do not grep any log by yourself. Just attach the full dmesg first.

Also, actually Orin NX and Orin Nano do not read MAC address from EEPROM, so checking EEPROM does not really matter here.

Your dmesg will help clarify first.

4

Hi Wayne, thank you for answer.

Please, find attached the output of dmesg.
dmesg.txt (56.4 KB)

5

In case these issues are related, we’ve got another request for help open regarding this batch of Jetsons we’ve just received, as we’re not certain the FAB value in EEPROM is correct. It’s this thread:

6

Hi @jlperez

Do you have NV devkit that can validate whether those modules have same behaviors when putting them on devkit and also flashed with pure Jetpack image?

7

We only have NV Orin AGX devkits, I’m afraid.

We can get hold of a Seeed Studio’s J401. But we’d obviously need to flash them with Seeed’s own firmware, so I’m not sure this would be a valid test.

8

Re-reading my initial comment I’ve realised I might not make it as clear as I thought I had: so far only this one module shows this issue with the MAC address. However, only two modules from this last batch have been tested, the other module sets the MAC address just fine; we’re awaiting further information on this issue and the linked FAB query to proceed with the rest.

9

Hi,

No, we don’t guarantee it would be a valid test with a custom board from other vendor.

Are you talking about you have some modules which have mismatched info with labels but only one of a module from them would hit this EEPROM issue?

10

Hi,

Yes, we’ve received a new batch of modules. We’ve only checked two of them so far. Both have the same mismatch info between label and EEPROM (or at least we think it’s a mismatch, we’re awaiting confirmation about this), but only this one module has this problem with the MAC address.

11

You could try to enable UEFI logs by rebuilding UEFI and that might tell why MAC addrs is missing. But in the end I guess it would lead to a RMA.

12

I’ll discuss this with the team. But if you haven’t found anything out of the ordinary in the dmesg output, I fear that you might be right and any further investigation will lead to an RMA anyway. More so, depending on the feedback from the other linked issue.

I’ll mark your last comment as the answer. Thank you very much for your help, much appreciated.

13

The MAC address is read and append to device tree by the UEFI bootloader.

From kernel log dmesg, I only saw it read all 00s . It means UEFI side cannot or the read out value is abnormal.

1 Like
14

HI @WayneWWW ,

This module was flashed with the UEFI stock binary, and not with any of our own builds. So yes, this certainly points to a problem with the module itself.

Once again, thank you for your help.

1 Like
15

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