Dear NVidia Team
We cannot flash one of our custom systems with JetPack 7.2. It gets stuck at the message “Sending blob”. Here is the full flash log:
logfile.txt (84.9 KB)
We noticed that this jetson agx orin 64gb module has the ID 699-13701-0005-502, whereas the system that can be flashed have the ID 699-13701-0005-501.
JetPack 6.2.1 works with both module IDs. There we do not see any flashing issues.
Can you please check this?
Let us know if you need further information.
Thank you.
— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —
I could not find clear support for that in the provided Jetson AGX Orin documentation.
— We support team will also look into your issue to have further suggestions soon. please stay tuned. —
Thanks for reporting this. Let me check internally.
BTW, could you also share the UART log of failure for me to double check?
Hi WayneWWW
We do not have an easy access to the UART log and therefore hope you can solve this without it.
Thank you.
Hi sevm89,
Could you help me check if these 2 files are present in your JetPack-7.2/Linux_for_Tegra/bootloader?
tegra234-mb1-bct-p3701-0005-rc03-204mhz.dtsi
tegra234-mb1-bct-p3701-0005-rc03-665mhz.dtsi
And the content shall have lots parameters but not just few lines.
and if possible, could you share me the passing log of your rel-36.x flash log?
hi,
need your help to share the log of rel-36. Thanks.
Hi,
I notice that these are all based on your custom board config. Could you test if NV devkit + default board config even hit the issue or not?
We already flashed the system using “jetson-agx-orin-devkit” getting stuck at the same place.
Could you give me a devkit flash log? Either rel-36 or rel-39 is fine.
Here is the log file while we flash with the board configuration jetson-agx-orin-devkit (JetPack 7.2):
logfile_jetson_agx_orin_devkit.txt (92.7 KB)
thanks for sharing. Let me check this internally.
Hi WanyeWWW
Any update?
Thank you.
I believe this is the same issue as AGX Jetson Orin SOM flashing failure in MB2 init - there is likely a difference in the eMMC.
If you check dmesg, on both units, like
sudo dmesg | grep mmcblk
you should see something like
[ 11.529605] mmcblk0: mmc0:0001 TY2964 58.3 GiB
The non-working one for me is TY2964, which is a Kingston eMMC.
The working one for me on Jetpack 7.2 is DG4064.
Based on Gemini:
NVIDIA implemented a global supply chain adjustment across the Jetson AGX Orin 64GB lineups (notably marked via Product Change Notification PCN210100). As a result, older modules used SanDisk storage (DG4064), while newer batches transitioned to Micron (G1M15M) and Kingston (TY2964) components. [1, 2]
Why the “TY2964” Kingston Chip Causes Issues
1. Image Size Mismatches (Flashing Failures)
The primary issue with mixing these eMMC suppliers is that they do not have identical byte capacities. [1]
DG4064 chip is slightly larger.TY2964 chip has a slightly smaller exact sector layout. [1]If your team is attempting to take a raw sector-by-sector system image backup (system.img) created on an older SanDisk board and flash/clone it directly onto a new Kingston board, the flash script will fail or hang because the target partition boundary physically overflows the Kingston storage bounds. [1]
2. Device Tree Timing Errors (I/O Timeouts)
The Linux kernel uses specialized clock signaling parameters inside the Device Tree (mmc@3460000 node) to communicate with the flash storage. Because the Kingston TY2964 has different electrical parameters and bus response behaviors compared to the SanDisk module, unpatched/older NVIDIA JetPack software configurations can throw severe I/O errors: [1]
mmcblk0: error -110 regardless... or timeout happened in your dmesg history. [1]How to Fix the Problems
Step 1: Force a Partition Shrink During Restore
If you are running into clone/flash deployment failures via NVIDIA’s CLI, you must explicitly tell the flash system to calculate partition allocations based on the exact drive geometry of the device instead of relying on a hardcoded image size limit. Add the -r flag to reuse the image, but adjust the sizing array: [1]
bash
# Force the system to adapt the base layout down to the connected eMMC target
sudo ./flash.sh -r jetson-agx-orin-devkit internal
Use code with caution.
Step 2: Use File-Based System Backups Instead of Raw Backups
Avoid flashing raw sector bitstreams (system.img) across varying Orin modules. Instead, build your fleet software using NVIDIA’s file-based system management tools, or generate a customized rootfs archive via the nvbackup_tar.sh workflow. This method ignores physical block sector counts and simply extracts files safely onto the underlying filesystem layout. [1]
Step 3: Upgrade Your JetPack BSP Version
NVIDIA introduced necessary timing updates to their Linux for Tegra (L4T) driver configurations to seamlessly accommodate the Kingston TY2964 profile. Ensure you are deploying your system using a stable, up-to-date JetPack BSP package to resolve driver-level timeout bugs. [1]
Does NVidia has a solution for us?
We create a new image for flashing and are using the newest JetPack Version available.
@WayneWWW Were you able to reproduce internally? I assume you can put a 64GB Orin AGX (FAB 502) in devkit, flash internal and see the issue?
I take it back. Not all FAB 502s are using Kingston (TY2964)
On one of our systems that all went well with Jetpack 7.2, it shows FAB 502 but uses SanDisk (DG4064):
user@localhost:~$ cat /etc/nv_boot_control.conf
TNSPEC 3701-502-0005-K.0-1-0-jetson-agx-orin-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-agx-orin-devkit-
TEGRA_BOOT_STORAGE mmcblk0
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
user@localhost:~$ cat /etc/nv_tegra_release
# R39 (release), REVISION: 2.0, GCID: 45755727, BOARD: generic, EABI: aarch64, DATE: Mon Jun 1 09:28:48 PM UTC 2026
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia
user@localhost:~$ uname -a
Linux localhost.localdomain 6.8.12-1021-tegra #1 SMP PREEMPT Mon Jun 1 13:25:46 PDT 2026 aarch64 aarch64 aarch64 GNU/Linux
user@localhost:~$ cat /sys/class/dmi/id/bios_version
39.2.0-gcid-45755727
user@localhost:~$ cat /sys/block/mmcblk0/device/name
DG4064