Backup and Massflash issue with L4T 35.6.0

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
,
1

We use self-developed carrier board, onboard 64G emmc module. The modules used by Xavier NX.
L4T 35.6.0

Use the following command to successfully burn the system to the 64G emmc storage

sudo  EXT_NUM_SECTORS=120832000 ./tools/kernel_flash/l4t_initrd_flash.sh --external-device mmcblk1p1 -c ./tools/kernel_flash/flash_l4t_external.xml   --showlogs jetson-xavier-nx-devkit-emmc mmcblk1p1

After installing the Jetpack package, use the following command to successfully back up your system.

sudo ./tools/backup_restore/l4t_backup_restore.sh -b -c jetson-xavier-nx-devkit-emmc	# ć€‡ä»œ
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --use-backup-image --no-flash --network usb0 --massflash 1 jetson-xavier-nx-devkit-emmc mmcblk1p1

And successfully generated Massflash package.

However, when using Massflash package to flash image to the new device encountered a problem.
1、Use the following command to display an error

sudo ./tools/kernel_flash/l4t_initrd_flash.sh  --flash-only --massflash 1 --network usb0 --showlogs
or
sudo  EXT_NUM_SECTORS=120832000 ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --massflash 1 --external-device mmcblk1p1 -c ./tools/kernel_flash/flash_l4t_external.xml --network usb0  --showlogs jetson-xavier-nx-devkit-emmc mmcblk1p1

This is followed by the full log

/home/plink/flash/35.6.0/suzhouyunchuang/Linux_for_Tegra/mfi_jetson-xavier-nx-devkit-emmc/tools/kernel_flash/l4t_initrd_flash_internal.sh --network usb0 --usb-instance 1-1 --device-instance 0 --flash-only --network usb0 jetson-xavier-nx-devkit-emmc mmcblk1p1
**********************************************
*                                            *
*  Step 1: Build the flashing environment    *
*                                            *
**********************************************
Create flash environment 0
/home/plink/flash/35.6.0/suzhouyunchuang/Linux_for_Tegra/mfi_jetson-xavier-nx-devkit-emmc/bootloader /home/plink/flash/35.6.0/suzhouyunchuang/Linux_for_Tegra/mfi_jetson-xavier-nx-devkit-emmc
/home/plink/flash/35.6.0/suzhouyunchuang/Linux_for_Tegra/mfi_jetson-xavier-nx-devkit-emmc
Finish creating flash environment 0.
****************************************************
*                                                  *
*  Step 2: Boot the device with flash initrd image *
*                                                  *
****************************************************
/home/plink/flash/35.6.0/suzhouyunchuang/Linux_for_Tegra/mfi_jetson-xavier-nx-devkit-emmc/temp_initrdflash/bootloader0 /home/plink/flash/35.6.0/suzhouyunchuang/Linux_for_Tegra/mfi_jetson-xavier-nx-devkit-emmc
./tegraflash.py --bl nvtboot_recovery_cpu_t194_sigheader.bin.encrypt --bct br_bct_BR.bct --securedev  --bldtb tegra194-p3668-all-p3509-0000.dtb --applet rcm_2_encrypt.rcm --applet_softfuse rcm_1_encrypt.rcm --cmd "rcmboot"  --cfg secureflash.xml --chip 0x19 --mb1_bct mb1_bct_MB1_sigheader.bct.encrypt --mem_bct mem_rcm_sigheader.bct.encrypt --mb1_cold_boot_bct mb1_cold_boot_bct_MB1_sigheader.bct.encrypt --mem_bct_cold_boot mem_coldboot_sigheader.bct.encrypt  --bins "mb2_bootloader nvtboot_recovery_t194_sigheader.bin.encrypt; mts_preboot preboot_c10_prod_cr_sigheader.bin.encrypt; mts_mce mce_c10_prod_cr_sigheader.bin.encrypt; mts_proper mts_c10_prod_cr_sigheader.bin.encrypt; bpmp_fw bpmp-2_t194_sigheader.bin.encrypt; bpmp_fw_dtb tegra194-a02-bpmp-p3668-a00_lz4_sigheader.dtb.encrypt; spe_fw spe_t194_sigheader.bin.encrypt; tos tos-optee_t194_sigheader.img.encrypt; eks eks_t194_sigheader.img.encrypt; kernel boot0.img; kernel_dtb kernel_tegra194-p3668-0001-p3509-0000.dtb; bootloader_dtb tegra194-p3668-all-p3509-0000_sigheader.dtb.encrypt"    --bct_backup  --ramcode 1  --instance 1-1
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands


 Entering RCM boot

[   0.0000 ] rcm boot with presigned binaries
[   0.0000 ] Boot Rom communication
[   0.0015 ] tegrarcm_v2 --instance 1-1 --chip 0x19 0 --rcm rcm_1_encrypt.rcm --rcm rcm_2_encrypt.rcm
[   0.0018 ] BR_CID: 0x88021911642a01420800000004008100
[   0.0089 ] Boot Rom communication completed
[   2.0376 ] tegrarcm_v2 --instance 1-1 --isapplet
[   2.0386 ] Applet version 01.00.0000
[   2.0568 ] Sending BCTs
[   2.0582 ] tegrarcm_v2 --instance 1-1 --download bct_bootrom br_bct_BR.bct --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt --download bct_mem mem_rcm_sigheader.bct.encrypt
[   2.0584 ] Applet version 01.00.0000
[   2.0717 ] Sending bct_bootrom
[   2.0718 ] [................................................] 100%
[   2.0729 ] Sending bct_mb1
[   2.0779 ] [................................................] 100%
[   2.0812 ] Sending bct_mem
[   2.1294 ] [................................................] 100%
[   2.1658 ] Generating blob
[   2.3840 ] Disable RCE in rcm kernel-dtb.
[   2.4219 ] tegrahost_v2 --chip 0x19 --generateblob blob.xml blob.bin
[   2.4223 ] number of images in blob are 13
[   2.4225 ] blobsize is 71126912
[   2.4226 ] Added binary blob_nvtboot_recovery_cpu_t194_sigheader.bin.encrypt of size 232976
[   2.4429 ] Added binary blob_nvtboot_recovery_t194_sigheader.bin.encrypt of size 206016
[   2.4431 ] Added binary blob_preboot_c10_prod_cr_sigheader.bin.encrypt of size 24016
[   2.4434 ] Added binary blob_mce_c10_prod_cr_sigheader.bin.encrypt of size 145184
[   2.4435 ] Added binary blob_mts_c10_prod_cr_sigheader.bin.encrypt of size 3429968
[   2.4446 ] Added binary blob_bpmp-2_t194_sigheader.bin.encrypt of size 1007392
[   2.4454 ] Added binary blob_tegra194-a02-bpmp-p3668-a00_lz4_sigheader.dtb.encrypt of size 42864
[   2.4456 ] Added binary blob_spe_t194_sigheader.bin.encrypt of size 95232
[   2.4457 ] Added binary blob_tos-optee_t194_sigheader.img.encrypt of size 1137424
[   2.4462 ] Added binary blob_eks_t194_sigheader.img.encrypt of size 5136
[   2.4463 ] Added binary blob_boot0.img of size 64133120
[   2.4750 ] Added binary blob_kernel_tegra194-p3668-0001-p3509-0000.dtb of size 327336
[   2.4851 ] Added binary blob_tegra194-p3668-all-p3509-0000_sigheader.dtb.encrypt of size 340032
[   2.5115 ] Sending bootloader and pre-requisite binaries
[   2.5131 ] tegrarcm_v2 --instance 1-1 --download blob blob.bin
[   2.5134 ] Applet version 01.00.0000
[   2.5279 ] Sending blob
[   2.5279 ] [................................................] 100%
[  12.6952 ] tegrarcm_v2 --instance 1-1 --boot rcm
[  12.6963 ] Applet version 01.00.0000
[  12.7184 ] RCM-boot started

/home/plink/flash/35.6.0/suzhouyunchuang/Linux_for_Tegra/mfi_jetson-xavier-nx-devkit-emmc
***************************************
*                                     *
*  Step 3: Start the flashing process *
*                                     *
***************************************
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for device to expose ssh ......Error: ipv6: address already assigned.
Error: ipv6: address already assigned.
Waiting for device to expose ssh ...Run command: flash on fc00:1:1:0::2
SSH ready
4194304
[ 0]: l4t_flash_from_kernel: Serial Number: 1425021070584
[ 0]: l4t_flash_from_kernel: Starting to create gpt for emmc
Active index file is /mnt/internal/flash.idx
Number of lines is 20
max_index=19
writing item=3, 1:3:primary_gpt,0,20480,gptmbr.img,20480,fixed-<reserved>-0,66e8a2220e182e02f84dbd1e7574dea43304c6d7
Writing primary_gpt partition with gptmbr.img
20480 bytes from /mnt/internal/gptmbr.img to /dev/mmcblk0: 1KB block=20 remainder=0
dd if=/mnt/internal/gptmbr.img of=/dev/mmcblk0 bs=1K skip=0  seek=0 count=20
20+0 records in
20+0 records out
20480 bytes (20 kB, 20 KiB) copied, 0.00135331 s, 15.1 MB/s
Writing primary_gpt partition done
Error: Invalid argument during seek for read on /dev/mmcblk0
[ 28]: l4t_flash_from_kernel: Error: partprobe failed. This indicates that:
 -   the xml indicates the gpt is larger than the device storage
 -   the xml might be invalid
 -   the device might have a problem.
 Please make correction.
Flash failure
Cleaning up...

2、After changing mmcblk0 to mmcblk1 in all files in the tools/kernel_flash path, the flush will succeed, but it will not enter the system.

image
image532×318 63.5 KB

All are based on my previous posts.
How to backup system from nvme then flash to new nvme - Jetson & Embedded Systems / Jetson Orin NX - NVIDIA Developer Forums

Do you have any good solutions?

2

I can see that there are backup files in the onboard 64G emmc through the devices of other systems in the emmc module and put them on the self-developed board.

It seems that the problem is related to the bootloader on the core storage after Massflash.

4

It is not the expected option to me.

Do you mean that you are using the eMMC from your custom board rather than internal eMMC from the Xavier NX module?

5

yesXavier NX’s emmc storage space is only 16G. In L4T 35.6.0 version, after installing the system, the remaining space is not enough to install Jetpack packages.

6

Have you tried using NVMe SSD instead of eMMC from your custom board? Since we don’t have such carrier board with external eMMC.

Please check the log when you run this command to backup.
I remember it would backup internal eMMC mmcblk0p* instead of mmcblk1p* by default.

7

At present, this self-developed carrier board does not reserve the interface of hard disk because of the project requirements.

Before backup, modify the information in the file under the backup path, change mmcblk0 to mmcblk1

From the actual situation, it can directly flash to the external on-board emmc, and can also be backed up from the external on-board emmc, and the backup system can also flash to the emmc of other on-board, but it is not sure whether the core is missing some files, resulting in the stuck in the shell stage of UEFI.

8

I put the module from the motherboard used to extract the image on the target board, and the system started normally. Before this, the emmc of the target board is completed without any files. Motherboard modules also have only one boot file.

When the boot device cannot be found. Normally, a boot device cannot be found after entering the kernel. But the module of the target board. Whether in devkit or on our board, we are directly into the shell interface of UEFI.

9

If you use the l4t_backup_restored.sh script to backup, will you only backup the files in the external emmc storage? The same operation is normal for modules using ORIN NX. The difference should be that Xavier NX needs the built-in emmc to have a boot file in order to start properly.

10

It is expected that bootchain exists in internal QSPI/eMMC even if you flash into external eMMC on custom carrier board.

What’s the “motherboard” and “target board” you mentioned here?

Do you mean that you’ve customized the backup/restore script for mmcblk1?

Do you mean the issue is specific to current board?
(i.e. it works on other custom carrier board?)

11

“motherboard” means Self-developed carrier board A + module A for backup
“target board” means Self-developed carrier board B + module B for restore

Just change mmcblk0 to mmcblk1 in the files in the tools/backup_restore/ path, and then successfully backup all files in the external emmc.

The files in tools/kernel_flash were not modified before the mfi archive was made.

Before using the generated mfi_jetson-xxavier -nx-devkit-emmc.tar.gz to burn to the target board, modify mmcblk0 to mmcblk1 in all files under the tools/kernel_flash path in this file.

Then I was able to burn all the files I wanted to back up to the external emmc storage on the target board,

I think this problem may be applicable to all carrier boards with external emmc storage.

From the current phenomenon, only the data from the external storage is backed up, but Xavier NX starts from the external storage and also needs the data from the built-in emmc storage.

12

image
image1458×189 48.3 KB

It looks like this script can only write backup files to one store. Can it be optimized?
mfi_jetson-xavier-nx-devkit-emmc/tools/kernel_flash/images/l4t_flash_from_kernel.sh

13

If you’ve configured the script for mmcblk1p* instead of mmcblk0p*, why you have mmcblk0p* here?
Actually, we don’t have such hardware(external eMMC) on the devkit so that we don’t verify this use case.
You can try to customize the script for your requirment.

Have you tried using the similar command(but with -r option) to restore the image on your “target board”?

1 Like
14

Before making changes, the module’s built-in emmc data is backed up. Then the data in the onboard external emmc is backed up by modifying. Therefore, the packet of the final generated mfi contains the data of the two storage devices.

This approach can only restore data from external emmc storage, which ultimately requires a full burn in production.

15

Could you please help to determine whether you only need to modify the filemfi_jetson-xavier-nx-devkit-emmc/tools/kernel_flash/images/l4t_flash_from_kernel.sh, so that you can use the mfi environment to flash image

16

Okay, it seems you want to create a mfi package for your custom board equipped with both internal and external eMMC.
In this case, I don’t think you need to run l4t_backup_restore.sh.

Please share the full logs when you were generating mfi package and the log when you were flashing mfi package for further check.

17

mfi_flash.log (23.3 KB)
The logs that generated the mfi packet were gone, and only the logs that used the mfi packet to go to flash were found.

18

From the log you shared, it seems the flash is successful.

19

It is certain that XavierNX extracts the data from the external emmc and does not backup the data from the built-in emmc at the same time, so at present, we split the operation into two operations, after backing up the data respectively, we restore the data from the external storage first, and then restore the data from the internal storage.