Clarification about Customer Version EEPROM field

After finding this document about the Jetson Module EEPROM layout here:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3243/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide%2Fjetson_eeprom_layout.html

I was hoping to get some clarification about the intent and use of the “Version” field in the the “Customer Overwritable Section”. Bytes 158-159. It appears to contain two bytes of hex data, but the description of “version” is lacking. Is this field meant to be used by custom board manufacturers? If yes, could an example use case be given using this version field?

hello wesley.lindauer,

FYI, the SOM and carrier board each have an EEPROM where the board ID is saved. (Product Part Number), The SOM can be used without any software configuration modifications.
it depends-on your use-case to program eeprom in this [Customer Overwritable Section]

Additional context. We have a custom carrier card which does not contain a EEPROM. We’ve iterated on the card design so we’re looking for a way to dynamically select the proper device tree at run-time. Without a EEPROM on the carrier card that leaves us with the SOM’s EEPROM. Are there any fields in the SOM’s EEPROM which we can write to which would be within the original design intent to handle this use case or did we miss out by not putting down a EEPROM on the carrier card? Wes was possibly looking to modify ‘version’, but there are questions about whether that goes against its intended use.

What kind of device-tree is that? I mean what is this device tree for?

A device tree change always comes along with a hardware change. What is the hardware change here? I don’t suggest to change board info on the SOM eeprom because you may come back here and file another topic and tell us your module cannot work normally.

If you need a different device tree for different carrier board, then your carrier board should have eeprom.

It is device tree changes relating to the carrier board. So, I think you’ve answered our question which is that the SOM eeprom is not meant to identify such changes. EEPROM required on carrier board.

If you want to change the device tree when the carrier board changes, then yes, EEPROM is required on each of your custom board.

I appreciate the responses so far. Can you please explain the intended use of bytes 158-159 in the referenced EEPROM document?

I don’t have access to the code now, so not sure if this byte is getting read in any bootloader.

Honestly, if you really want to use something in eeprom, I would suggest you can use 178–254. The most important thing is to update byte 255 CRC value after you change 178~254.