AGX Orin 64GB (699-13701-0005-502) – Flash Failure Between L.0 and K.0 Board Revisions (L4T 35.6.0)

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

We are seeing a flashing compatibility issue between different BOM revisions of the same AGX Orin 64GB modules: 699-13701-0005-502 K.0 and 699-13701-0005-502 L.0

Error during flash:

nvrestore_partitions.sh: Use the default nvpartitionmap.txt as the index file.
nvrestore_partitions.sh: You are trying to flash images from a board model that does not match the current board you're flashing onto.

Details

  • Detected module: 699-13701-0005-502 K.0

  • Flashed image that was created on: 699-13701-0005-502 L.0

  • L4T version: 35.6.0

  • Storage: eMMC

  • EEPROM readback confirms module ID:

    image
    image856×370 99.8 KB

  • Board revision: K.0

Our production image was created using a 699-13701-0005-502 L.0 module.

We recently received a batch of new 64GB 502 Orins which are K.0 revision. Attempting to flash the image created from an L.0 unit onto these K.0 units consistently fails with the board model mismatch error.

We also:

  • Swapped in another module from the same new batch.

  • Re-attempted flashing multiple times.

  • Confirmed EEPROM contents match 699-13701-0005-502 K.0.

The error persists across units from this new batch.

Observation

It appears that an image created from an L.0 revision module is not considered compatible with a K.0 revision module, despite both being 699-13701-0005-502.

Questions

  1. What specifically changed between the L.0 and K.0 BOM revisions that causes nvrestore_partitions.sh to reject the image?

  2. Is this expected behavior due to updated board IDs, fuse values, or other configuration changes?

  3. Is there a supported method to create a production image that is compatible across BOM revisions of the same module part number? Currently we use the backup restore method:
    $workingdir/tools/l4t_backup_restore.sh -r $workingdir/$target_board

  4. Is there a way to override this validation safely for production imaging?

We are preparing to generate a new production image using a K.0 module, but would like clarification on whether future BOM changes will require regenerating images each time.

Any guidance for image generation across AGX Orin BOM revisions would be appreciated.

2

*** Please note that this reply is generated by LLM automatically ***

The issue you are experiencing is related to the compatibility of the flashed image between different BOM revisions of the same AGX Orin 64GB modules. Specifically, the image created on a module with BOM revision L0 (699137010005502) is not compatible with modules with BOM revision K0 (699137010005502).

The error message “board model mismatch” indicates that the image is not compatible with the module’s board ID, fuse values, or other configuration changes. This is expected behavior, as the board ID and fuse values are used to validate the compatibility of the image with the module.

The main difference between the L0 and K0 BOM revisions is the updated board ID and fuse values. The K0 revision has updated fuse values that are not compatible with the image created on the L0 revision.

To create a production image that is compatible across BOM revisions of the same module part number, you can use the following methods:

  1. Use the backup and restore method: This method allows you to create an image that is compatible with different BOM revisions. However, this method may not be suitable for large-scale production.
  2. Use the --override-board-id option: This option allows you to override the board ID validation during the flashing process. However, this option should be used with caution, as it may lead to compatibility issues if not used correctly.
  3. Create a new production image using a K0 module: This is the recommended approach, as it ensures that the image is compatible with the latest BOM revision.

To avoid regenerating images each time there is a BOM change, you can take the following precautions:

  1. Use a generic board ID: Instead of using a specific board ID, you can use a generic board ID that is compatible with multiple BOM revisions.
  2. Use a fuse value override: You can override the fuse values during the flashing process to ensure compatibility with different BOM revisions.
  3. Test the image on multiple BOM revisions: Before deploying the image in production, test it on multiple BOM revisions to ensure compatibility.

In summary, the compatibility issue between different BOM revisions of the same AGX Orin 64GB modules is due to the updated board ID and fuse values. To create a production image that is compatible across BOM revisions, you can use the backup and restore method, override the board ID validation, or create a new production image using a K0 module. To avoid regenerating images each time there is a BOM change, you can use a generic board ID, override the fuse values, or test the image on multiple BOM revisions.

Comparison with other Jetson modules:

  • Jetson Orin NX: The Jetson Orin NX module has a similar issue with BOM revisions, where the image created on one BOM revision may not be compatible with another BOM revision.
  • Jetson Orin Nano: The Jetson Orin Nano module does not have the same issue with BOM revisions, as it uses a different board ID and fuse value scheme.
  • Jetson AGX Xavier: The Jetson AGX Xavier module has a similar issue with BOM revisions, where the image created on one BOM revision may not be compatible with another BOM revision.

In general, it is recommended to test the image on multiple BOM revisions before deploying it in production, to ensure compatibility and avoid any potential issues.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

3

Please can someone comment if the LLM response is correct. My Current plan is:

  1. Perform a clean NVIDIA flash on the K.0 module using the correct BSP/L4T version.

  2. After confirming it boots, replace the root filesystem with a tarball of my production rootfs from the L.0 system.

I would not overwrite:

  • /boot

  • /lib/modules

  • DTBs

  • QSPI / bootloader components

  • Any BSP-specific firmware

The goal is to preserve the K.0 boot chain, kernel, and board-specific components while restoring only userland and application data from the L.0 production image.

Questions:

  • Is this approach supported between L.0 and K.0 revisions?

  • Are there any known incompatibilities at the rootfs level between these revisions?

  • Are there specific directories (e.g., /opt/nvidia, firmware paths, etc.) that must not be overwritten?

  • Is it safer to rebuild the production image starting from the K.0 BSP instead?

5

Hi, can you follow the solution in this forum thread?

6

Please can I still have clarification on the questions below. I want to avoid introducing instability.

Specifically:

  1. What specifically changed between the L.0 and K.0 BOM revisions?

  2. Are there any documented differences in firmware, bootloader, or low-level components between L.0 and K.0?

  3. Is it supported to perform a clean flash on the newer K.0 module and then selectively copy portions of the rootfs from a working L.0 production image?

I Have still proceeded with the bypass solution. This is the error I now get:
40+0 records in
40+0 records out
20480 bytes (20 kB, 20 KiB) copied, 0.00012496 s, 164 MB/s
Error: Unable to partprobe /dev/mmcblk0

7

We use three types of eMMc for the BOM that have different sizes:

      -  Micron 170-0547-900 Original eMMC: 63652757504 / 512 = 124321792 sectors
      -  Sandisk 170-0637-300 Second eMMC: 63585648640 / 512 = 124190720 sectors
     -   Kingston 170-0695-000 Third eMMC: 62625153024 / 512 = 122314752 sectors

So the K.0 probably use a smaller eMMC size comparing to the L.0. I think you should perform a clean flash on K.0, create a production rootfs on the K.0, then create the backup image from the K.0 and use it for both K.0 and L.0.

Officially backup / restore across revision like that is not supported. Eventhough L.0 and K.0 use similar firmwares, bootloader, low level component and root filesystems, during the clean flashing process, the flash script generates file /etc/nv_boot_control.conf for the rootfs which depends on the content of the eeprom. Because the board revision in the EEPROM of L.0 and K.0 are L.0 and K.0 respectively, the nv_boot_control.conf are different. This file are used for the Software Packages and the Update Mechanism — NVIDIA Jetson Linux Developer Guide 1 documentation

By using the same nv_boot_control.conf for both revision, you lose the ability to provide different image-based OTA payload for each version if you ever decide to use this feature in the future.

For the changes in BOM, we will get back to you later.

8

Thank you for the clarification.

Based on your guidance, I will proceed with a clean flash on the K.0 module and recreate the production image from scratch on K.0. I will then generate the backup image from the K.0 build and use that as the new baseline going forward.

I do have a couple of follow-up questions:

  1. I am currently unable to find a PCN related to the K.0 eMMC change unless its covered in PCN211462. Is there an official PCN covering the transition to the smaller eMMC device for this BOM?

  2. We are using the L4T 35.6.0 BSP. Is this BSP fully supported for the eMMC variants you mentioned (Micron, Sandisk, Kingston), including the smaller-capacity device on K.0?

Please let me know if there are any additional considerations specific to L4T 35.6.0 with these eMMC changes.

Thank you.

9
  1. I believe it is covered in PCN211462 which mentions Kingston eMMc.
  2. That BSP does support all variants.
10

Matt,

Thanks for your patience. Besides what lhoang indicated, here are a few Product Change Notifications for the eMMCs on AGX Orin for your reference,

11

Hi,
Please apply the overlay package to r35.6.0 and try again:

https://developer.nvidia.com/embedded/jetson-pcn-center
t234-pcn210100-pcn211461-emmc-35.6.0.tbz2

12

Hi @DaneLLL

I have just looked at PCN210100 (February 5th, 2024) with the t234-pcn210100-pcn211461-emmc-35.6.0.tbz2 overlay and this PCN states the following:

image
image734×252 46.2 KB

So I don’t think I need this overlay as this PCN states BSP 35.4 or later will include the required changes and I’m on BSP 35.6.0.

If all BSP’s 35.4 or later include the required changes, then why are the overlays I have circled below needed?

image
image2207×1028 117 KB

13

Hi,
The patch is for PCN211461 and PCN211462, and it does not catch Jetpack 5.1.2. If you don’t use the script l4t_initrd_flash.sh, you may ignore it.

Please generate the image with Orin 64GB module with Kingston eMMC(PCN211462). The module has minimum eMMC size and the generated image should be well applied to the modules with larger eMMC size.

14

Hi @DaneLLL

Thanks for your help, we use the flash.sh script so we will ignore the patches. We are also running Jetpack 5.1.4 not 5.1.2 so patches for PCN211461 and PCN211462 does catch the BOM changes.

Thanks