Xavier NX APX Carrier Board Eeprom Read

I have written custom flash scripts as a thin wrapper around tegraflash. As part of that, I read the module and carrier eeproms to make sure stuff doesn’t get flashed to the wrong hardware. The logic is similar to what the nvautoflash script does. I noticed that reading the carrier board eeprom is disabled for the xavier nx soc in the nvautoflash script. And verified that what works to read the AGX Xavier devkit carrier booard eeprom does not work on the Xavier NX devkit. And also verified that a TX2 NX module is able to read the p3509 carrier board eeprom.

What works on AGX Xavier, but does not on Xavier NX is:

tegraflash.py \
  --applet mb1_t194_prod.bin \
  --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg \
  --chip 0x19 \
  --bin "mb2_applet nvtboot_applet_t194.bin" \
  --instance ${INTERFACE} \
  --cmd "dump eeprom baseinfo eeprom_baseinfo.bin"

My question is: Is this a hardware bug or limitation? Or is it software, able to be fixed in future l4t releases? If the latter, is it a priority to be fixed on a near future release?

Hi,

We don’t have plan to fix this.

Actually, the flash tool does not read the eeprom on carrier board because we already told users they don’t need eeprom on their cvb. Thus, it is not a common use case.

Alright, I’ll exclude cvb read on the xavier nx soc, then. And hope no one ever tries to use the scripts on anything other than a p3509 compatible carrier.

Not being able to differentiate cvb seems to mean automation would be difficult, though. Unless all custom boards a single entity cares about work with the same dtb and everything else. Wouldn’t lack of cvb also prevent much useful use of plugin-manager? Could trigger on different modules, but would have to hardcode anything carrier board related and somehow make sure the right one ends up on the right device. Whereas the p3518 devkit dtb uses plugin-manager to support the p3449 carrier board, for example.

Am I missing something else for how to differentiate carrier boards in an automated manner?

Yes, you can use plugin-manager to control the dtb.

But actually plugin-manager is not intended for public users from the beginning. I mean… You can use it but we don’t have a standalone document to tell you how to use.

Usually we expect each module will be in same usecase for each custom product.

Is it expected for users of the modules to rewrite the cvm with something unique? I was working under the assumption that a xavier nx production module for instance would always be board id 3668 sku 1, thus each custom product would have identical cvm’s besides the serial.

CVM board id should always be the same. FAB ID may be different but should not affect function.

If you see anything wrong, please let us know.

For a bit more context: I have a testbed with upwards of twenty tegra devices. Various modules and carrier boards. For my personal use case, I do a lot of remote interaction with the devices, not sitting there looking at what’s happening. I want to make very sure that I don’t accidentally flash a p2972 bct to a p3518 or worse. A bit of an extreme example, but accidents can happen and be expensive if they cause hardware failure. And if I release these scripts to others, I want to do my due diligence that the scripts won’t fry someone else’s hardware. Right now, I think every nx carrier board I’ve seen publicly is compatible with the p3509 dtb, but afaik, that’s not a hard requirement. And seems there’s no way for a script to tell if flashing would be fatal. Not beyond fusing the device anyways.

Thank you for explaining things. Think I’ve got a better handle on expectations now.