Jetson Module EEPROM "User Data Section"

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

From the NVIDIA Tegra Linux Driver Package Development Guide in the “Jetson Module EEPROM Layout” section:

Is the “User Data Section” (bytes 89-90 and 91-149) of the EEPROM usable by customers?

If the “Customer Overwritable Section” Length field (bytes 154-155) is changed to 16 does the Gigabit Ethernet MAC address move from bytes 172-177 to 160-165?

If no to the previous question, on modules that do not have a WiFi/Bluetooth chip are bytes 160-165 and 166-171 usable for customer defined purpose other than the MAC addresses?

2

Hi,

Actually I don’t think bootloader is reading this value… What is the purpose to move mac field from 172 to 160?

If no to the previous question, on modules that do not have a WiFi/Bluetooth chip are bytes 160-165 and 166-171 usable for customer defined purpose other than the MAC addresses?

The answer is also no. Bootloader just returns some errors like “mac-addr” not find on those platform.

3

What does “this value” refer to?

The purpose is to have 12 more bytes in the continuous space from 178-254. So the “Reserved for future use.” section goes from 166-254 and is available for storage.

I’m not sure I understand your response. You say no, but your explanation makes it sound like yes you can → you just get some error messages.

What about the “User Data Section” bytes 89-149? Are those bytes fully usable for customer needs?

4

What does “this value” refer to?

Ans: “Length field”. I don’t think bootloader is reading this value and use it in any function.

I’m not sure I understand your response. You say no, but your explanation makes it sound like yes you can → you just get some error messages.

Ans: Sorry, I just read your problem again. My answer was not correct. Actually, currently if you put anything in those fields, then I think nothing would happen. Bootloader may still parse it as mac address but as you know there is no wifi device existing, nothing would happen in userspace or kernel.

Actually, if you don’t modify the cboot src, then everything would just follow the old rules as TX2 platform. For those byte as “Reserved for future use.”, you could use it directly. Just be careful about the checksum field in byte 255.

5

So “Reserved for future use” technically means it is reserved for NVIDIA use, not customer use?

6

I don’t think we need to strictly define whether “it is for NVIDIA use” or for customer use.

It is open-source so you could download the cboot source and modify this part… though I know there is no rel-32 cboot src for TX2 now. You could try to use rel-31 cboot src for now.

7

I’m currently trying to use R32.3.1 (latest at this time). Is there a C-Boot source release for R32.3.1 yet?

8

Unfortunately, no. Our team is still working on the release. I will update this thread if we release it.

9

Hi JD,

I was wondering if you had success using the “extra” (i.e. Reserved for future use.) bytes in either the “User Data” or “Customer Overwritable Section”? I am interested in using a few bytes to communicate information between userspace and the CBoot. So, I would need read/write access in both the CBoot and userspace. Do you know if that is possible? Have you been able to read/write to the eeprom in Cboot and userspace?

I know that I can see the dump of the eeprom (on my NX) via i2cdump -f -y 0 0x50 but don’t see the device enumerated here /sys/bus/i2c/devices (as 0-0050). It would be cool if it had a device tree (DTS) entry so that it showed up in the /sys file system.

Thanks,
Joe

10

In userspace: Yes
In Cboot: No
I’m on the Jetson TX2 platform. Until recently NVIDIA was not even releasing the Cboot source. So I’m not familiar with how to do it there. I’m sure there are APIs to do it as NVIDIA’s code reads the EEPROM and makes DTB fragment changes to the DTB using overlays based on the read of the EEPROM board P/N.

I know what you are referring to. Most small EEPROMs are easy to address and therefore easy to read and write. Simply using i2cget and i2cset will allow you to change the data. Therefore, most people don’t add a DT entry for the EEPROM or utilize a built-in kernel EEPROM driver. You will only see them show up at that sysfs path if you have something listed at that address in your DT.

Here’s some python code you can use to generate/check the NVIDIA crc at the end of the block:

def AddToCRC(b, crc):
    b2 = b
    if (b < 0):
        b2 = b + 256
    for i in range(8):
        odd = ((b2^crc) & 1) == 1
        crc >>= 1
        b2 >>= 1
        if (odd):
            crc ^= 0x8C         # This means crc ^= 140.
    return crc

def CalculateCRC(data):
    crc = 0
    for b in data:
        crc = AddToCRC(b, crc)
    return crc

Hope that helps!