Flashing Jetson AGX Xavier fails on 'tegrarcm_v2 --download blob blob.bin', result code 1

Robotics & Edge Computing Jetson Systems Jetson AGX Xavier
1

Hi,

I have a Jetson AGX Xavier, on which i’ve recently installed The ‘Thud’ release of the Yocto OS (using meta-tegra).

However, today, when trying to flash yet another time (after building a modified image based on the thud release), I got the following error when running the CLI deployment utility (which eventually calls tegrarcm_v2):

Error: Return value 1
Command tegrarcm_v2 --download blob blob.bin

I then tried to just reflash the device with L4T using NVidia SDK Manager (choosing ‘JetPack 4.4 DP’), and got the same error in the GUI:

2020-07-08 17:38:50.821 - info: [   7.6641 ] Sending bootloader and pre-requisite binaries
2020-07-08 17:38:50.821 - info: [   7.6652 ] tegrarcm_v2 --download blob blob.bin
2020-07-08 17:38:50.857 - info: [   7.6662 ] Applet version 01.00.0000
2020-07-08 17:38:50.857 - info: [   8.0759 ] Sending blob
2020-07-08 17:38:51.323 - info: [   8.5294 ] 
2020-07-08 17:38:51.323 - info: Error: Return value 1
2020-07-08 17:38:51.323 - info: Command tegrarcm_v2 --download blob blob.bin
2020-07-08 17:38:51.338 - info: Failed flashing t186ref.
2020-07-08 17:38:51.344 - error: [exec_command]: /bin/bash -c /tmp/tmp_NV_L4T_FLASH_XAVIER_WITH_OS_IMAGE_COMP.sh; [error]: exit status 1
2020-07-08 17:38:51.345 - info: [ Component Install Finished with Error ]
2020-07-08 17:38:51.345 - info: [ 9.09 GB used. Disk Avail: 51.92 GB ]
2020-07-08 17:38:51.345 - info: [ NV_L4T_FLASH_XAVIER_WITH_OS_IMAGE_COMP Install took 1m53s ]
2020-07-08 17:38:51.345 - error: [error]: Run commands failed at step Install: command /tmp/tmp_NV_L4T_FLASH_XAVIER_WITH_OS_IMAGE_COMP.sh finished with error
2020-07-08 17:38:51.345 - info:  
2020-07-08 17:38:51.346 - error: cmd finished failure SDKM_END_CODE_FAILURE_7792ebba-4dbc-41bc-8581-d8333b5d692a_11
2020-07-08 17:38:51.346 - error: command error code: 11
2020-07-08 17:38:51.347 - error: command terminated with error

When I boot the device to the current OS (not in recovery mode), then it seems to work perfectly fine (currently there’s a Yocto ‘thud’ OS on it), and the flash seems to work (i manage mount ext4 on it and write).

I’ve uploaded the log for the flash attempt from the NVidia SDK Manager- flash-attempt-sdkm-2020-07-07-16-13-19.log (654.8 KB) .

I’ve also noticed that there are several variations of this issue on the internet, but none of them helps me (please correct me if i’m wrong, but i didn’t see an answer that is relevant for me in one of the posts)-

So, my questions are:

  1. Can you help me solve the issue?
  2. Is the flashing process of the SDK Manager affected by what previously resided on the device? (bad filesystem/kernel/etc.)? If so, is there a way to complete ‘factory reset’ that isn’t dependent on anything?
  3. Is there a guide/tutorial for such tools (like tegrarcm_v2) to be able to perform more low level operations on the device for diagnosis?

Would appreciate any help.
Eliran

3

Hi,

According to the flash log, this is the problem that causes failure.

2020-07-08 17:33:29.415 - info: Error: The Actual SoC ID(0x00) mismatches intended jetson-xavier SoC ID(0x19).

This brings out several questions

  1. Are you sure this is a Jeton-Xavier platform but jetson xavier 8GB or something else

  2. Is this system still able to boot up? If it can, could you share the serial console log?

  3. How did this board get flashed last time?

And you could read this wiki page to dump UART log during flash too.
https://elinux.org/Jetson/General_debug

4

Hi, thanks for the quick reply!

TL;DR the error has stopped showing, i now have different issue - my Yocto release doesn’t boot well (rootfs missing with essential commands like mount and ls).

  1. This is a Jeston AGX Xavier (16GB, just looked in /proc/meminfo).

  2. The system was still able to boot (with the Yocto OS). I’ve attached the serial log - yocto-thud-boot-log.txt (201.0 KB)

  3. The board originally got flashed (successfully) with a Thud release of the Yocto OS (using the meta-tegra layer), by running ‘doflash.sh’ script (generated by as part of the Yocto OS artifacts) that contains the following line:

    MACHINE=jetson-xavier ./tegra194-flash-helper.sh flash.xml.in tegra194-p2888-0001-p2822-0000.dtb jetson-xavier.cfg,jetson-xavier-override.cfg 0x9190000 tegra-minimal-initramfs-jetson-xavier.cboot "$@"

    I then tried to flash a modified version of the Thud release, which gave the afformentioned tegrarcm_v2 --download blob blob.bin error.

I’ve tried to produce the serial log, with the flashing error, by installing L4T with the NVidia SDK manager, but for some reason, the error does not reproduce anymore (ever since the serial is connected, not sure if it’s related), and the regular L4T successfully booted.

I now have a different problem; So I tried to flash (using doflash.sh) my modified Thud release again (the one which before gave the SoC ID mismatch). The flash seems to have succeeded (serial log is from during flash -successful-flash-log-sdk-manager.txt (40.2 KB) , but then It booted into a very degenerate filesystem, that fails event to mount dirs, as even the mount and ls commands were not present (bad-thud-boot-serial-log.txt (100.0 KB) . I’ve also uploaded a picture of the screen as the message for missing mount command doesn’t appear in the serial log for some reason

bad-thud-boot
bad-thud-boot2000×1500 1.53 MB
.

It likely that my Yocto release is faulty, but i’m not sure how to debug this, because when i look at the rootfs image (created a .tar.gz image to observe inside, in addition to the .tegraflash.zip image), i do see all the utils (ls, mount, etc.). I’m not really familiar with the boot process, so i might be missing something basic here (like initramfs not containing the mount command mount and therefore it can’t mount the flash device). I’ll keep investigating what’s wrong with my image. If you have an idea as to what went wrong from the log, i’d love to know.

Thanks.
Eliran

5

The second issue was because of a bad rootfs i’ve produced (busybox was missing in initramfs).
As for the main issue (flashing error), it does not reproduce for me anymore. I’ll update if i get another repro.
Thanks!