Jetson Module EEPROM "User Data Section"

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?

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.

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?

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.

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

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.

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?

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