Issue flashing Jetpack 6.2

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

Hello,

I am getting a timeout error trying to flash jetpack 6.2. I have twice cycled back to flashing 5.1.5 to make sure the cable hasn’t broken or something and flashing 5.1.5 works fine as always but 6.2 has failed twice with the same error. The full log is here which includes all the commands run etc. The host is Ubuntu 20.04 LTS and I have never encountered this error flashing all jetpacks <6.0.

failed_jp6_flash.txt (59.1 KB)

the specific error is

[ 9.4033 ] Sending bct_br
[ 9.4036 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
Failed flashing generic.

Browsing the forums I was only able to find posts that linked to the FAQs here. I tried disabling autosuspend as suggested but it did not help.

Cheers

2

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

Based on the provided context, it appears that you are experiencing a timeout error while trying to flash JetPack 6.2 on your Jetson AGX Orin device. You have tried flashing JetPack 5.1.5 twice, which worked fine, but flashing JetPack 6.2 has failed twice with the same error.

The specific error message is not provided in the question, but based on the log file you mentioned (failedjp6flash.txt), I assume it’s related to a timeout issue.

After browsing the forums, you found a suggestion to disable autosuspend, but it didn’t help resolve the issue.

To troubleshoot this issue, I would recommend the following steps:

  1. Check the cable and connection: Although you’ve already tried flashing JetPack 5.1.5 successfully, it’s still possible that there’s an issue with the cable or connection. Try using a different cable or checking the connection to ensure it’s secure.
  2. Verify the host system: Ensure that your host system (Ubuntu 20.04 LTS) is configured correctly and that there are no issues with the USB ports or drivers.
  3. Check the device tree: Verify that the device tree is correctly configured for your Jetson AGX Orin device. You can check the device tree by running the command dtc -I fs /sys/firmware/devicetree.
  4. Try a different flashing method: Instead of using the SDK Manager, try flashing the device using the flash.sh script provided in the JetPack 6.2 package. This script can be found in the Linux_for_Tegra directory.
  5. Check for firmware issues: It’s possible that there’s an issue with the firmware on your Jetson AGX Orin device. Try updating the firmware to the latest version using the flash.sh script.
  6. Consult the NVIDIA forums: If none of the above steps resolve the issue, I recommend consulting the NVIDIA forums, where you can find more detailed troubleshooting guides and potentially connect with other users who have experienced similar issues.

In comparison to other issues mentioned in the context, your issue seems to be related to a timeout error during the flashing process, which is different from the other issues mentioned, such as:

  • OSError:[Errno 121] Remote I/O error on Jetson Orin Nano
  • Detectnet_v2 training failure using TAO Toolkit on DeepStream
  • Errors during Detectnet_v2 inference on DeepStream
  • Rin Nano 8GB Developer Kit - Realtek PHY MAC Address Change Causes Boot Issue
  • Jetson tx2 nx wakeup issue
  • Nvbufsurftransform_copy.cpp failed in mem copy issue

These issues seem to be unrelated to your specific problem, and I would recommend focusing on troubleshooting the flashing process and timeout error specifically.

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

5

Hi,

How do you flash your device?

Do you use the sdk manager or the manual cli to flash?

Is your host a native or a virtual machine?

Is your AGX orin a dev kit or a custom board?

Thanks

6

Hi @DavidDDD

In the log is all the flashing commands used. I directly use the BSP sources and the provided flashing scripts. It is flashing from an Ubuntu 20.04 host as I mentioned above. And the target device is a Jetson Orgin AGX Devkit.

Cheers

7

Hi,

If you use bsp source, please make sure

  1. download bsp source and rootfs
  2. Follow the official doc to setup
$ tar xf ${L4T_RELEASE_PACKAGE}
$ sudo tar xpf ${SAMPLE_FS_PACKAGE} -C Linux_for_Tegra/rootfs/
$ cd Linux_for_Tegra/
$ sudo ./tools/l4t_flash_prerequisites.sh
$ sudo ./apply_binaries.sh

Please try below commands as official doc suggestion

$ sudo ./flash.sh jetson-agx-orin-devkit internal

Also record the serial console log as below doc show:

Thanks

8

Two things you probably have already done.

disable autosuspend for usb devices on host.

echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend

do you want rootfs a/b ?

rootfs/flash_jetson_ALL_sdmmc_partition_qspi.sh 
if [[ "${ROOTFS_AB}" == 1 && "${ROOTFS_ENC}" == "" ]]; then
        EMMC_CFG=flash_t234_qspi_sdmmc_rootfs_ab.xml;
9

@DavidDDD This is what all of my setup processes boil down to. The only things I do additionally is change the kernel image and preinstall some debian packages into the rootfs via chroot. Here is a log of the flashing process; the first output is that of the prerequisites script, and the binaries have already been applied to the roots, although I can’t see this particular step being important for the actual flashing.

62flash.log (94.0 KB)

@whitesscott I have indeed tried to disable the auto suspend, but it didn’t make a difference unfortunately.

As for a/b I know that the Jetson by default has it enabled, so far I really have no preference for it, maybe in the future but at the moment it is not something I explicitly need enabled which is why I have been using flash_t234_qspi_sdmmc.xml

10

Hi,

We’d like to confirm whether the issue still persists.

Could you please check by following the standard flashing steps and using the standard commands, without applying any additional settings?

We just want to make sure the standard procedure works normally on your device.

Thanks

11

Hi @DavidDDD

I have removed any custom setup from my scripts and this now is essentially just doing the following:

  • Pulls BSP sources directly from Nvidia
  • Runs prerequisites script
  • Runs apply_binaries.sh
  • Runs l4t_create_default_user.sh
  • Gets pinmux files
  • Disables USB auto-suspend
  • Flashes using flash.sh

Here is the setup of the L4T sources:

setup62.log (43.0 KB)

And here is the flashing log until the timeout error:

flashing62.log (83.9 KB)

Cheers

12

Hi,

Thank you for your update.

Please record the serial console log for the further analysis.

Thanks

13

Hi @DavidDDD

here is the serial output during flashing

62flash_serial.log (15.9 KB)

Cheers

15

Hi,

What do you mean about the Gets pinmux files?

Have you made any changes, deletions, or modifications to those files?

Thanks

16

This just pulls the pinmux files I use down and puts them into the L4T sources. These files were generated using the spreadsheet and apply and work no problem when used with jetpack 5.1.5. As far as I can tell this sheet is device specific and not jetspack specific.

17

Hi,

What we want to clarify here is, if this is really a NV devkit, please do not do any customization. You just need to let sdkmanager flash the board directly.

* Runs prerequisites script
* Runs apply_binaries.sh
* Runs l4t_create_default_user.sh
* Gets pinmux files
* Disables USB auto-suspend
* Flashes using flash.sh

None of these thing should be done by you. What you need to do is just let sdkmanager flash it.

Make sure such base line could work first. Then go further with your customization.

18

We do not flash with SDKManager but with flash.sh, the only modifications that are made are preinstalling debian packages into the rootfs and other configurations of the sytem services so that the jetson has network when booted, for example.

19

Let sdkmanager do the work for you in case any of your customization there is making this problem.

That is my point to do that. I am afraid that you already messed up something there so I want a clean setup first. Sdkm will do that.

20

The what is the purpose of flash.sh? Have never had any issue with all 5.X jetspacks

21

Hi,

My point is just a clean setup. If you are 100% sure that your setup is clean enough, then using flash.sh is also fine. But it sounds like this discussion has taken almost 2 months and you are still making new variables here. That is not a right direction.

Go back to the very basic case first. I am 100% sure the true NV devkit will work with sdkmanager there. Validate that first. If you want to discuss about any customization, then we could discuss that later.

22

I will remove the customization and try and keep you updated

23

My suggestion is you don’t need to “remove your customization”… just let sdkmanger do the work for you…
Download a fresh one…

Nobody really knows whether your “removal” is really a clean removal or not…