[Ubuntu 16.04.6][L4T 32.4.3] Stuck making system.img during nvmassflashgen

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hello,

I am trying to create a mass image for Jetson Nano production modules using a B02 carrier board. However, when I try to run ./nvmassflashgen.sh, it is always stuck “Making system.img” (please see printout below). How can we diagnose this issue?

Thank you so much.

|| Generate Massflash Image in the master host:                               ||
|| Requires the Jetson connected in RCM mode.                                 ||
================================================================================
1 Jetson devices in RCM mode. USB: 3-2
+-------------------------------------------------------------------------------
| Step 1: Generate Command File
+-------------------------------------------------------------------------------
###############################################################################
# L4T BSP Information:
# R32 , REVISION: 4.3
###############################################################################
./tegraflash.py --chip 0x21 --applet "/home/user/Desktop/Linux_for_Tegra/bootloader/nvtboot_recovery.bin" --skipuid --cmd "dump eeprom boardinfo cvm.bin" 
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0011 ] Generating RCM messages
[   0.0020 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm /home/user/Desktop/Linux_for_Tegra/bootloader/nvtboot_recovery.bin 0 0
[   0.0028 ] RCM 0 is saved as rcm_0.rcm
[   0.0032 ] RCM 1 is saved as rcm_1.rcm
[   0.0032 ] List of rcm files are saved in rcm_list.xml
[   0.0032 ] 
[   0.0032 ] Signing RCM messages
[   0.0040 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0048 ] Assuming zero filled SBK key
[   0.0088 ] 
[   0.0088 ] Copying signature to RCM mesages
[   0.0097 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
[   0.0111 ] 
[   0.0111 ] Boot Rom communication
[   0.0119 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
[   0.0127 ] RCM version 0X210001
[   0.0546 ] Boot Rom communication completed
[   1.0670 ] 
[   1.0672 ] dump EEPROM info
[   1.0709 ] tegrarcm --oem platformdetails eeprom /home/user/Desktop/Linux_for_Tegra/bootloader/cvm.bin
[   1.0741 ] Applet version 00.01.0000
[   1.1030 ] Saved platform info in /home/user/Desktop/Linux_for_Tegra/bootloader/cvm.bin
[   1.1843 ] 
Board ID(3448) version(400) 
copying bctfile(/home/user/Desktop/Linux_for_Tegra/bootloader/t210ref/BCT/P3448_A00_4GB_Micron_4GB_lpddr4_204Mhz_P987.cfg)... done.
copying bootloader(/home/user/Desktop/Linux_for_Tegra/bootloader/t210ref/cboot.bin)... done.
copying initrd(/home/user/Desktop/Linux_for_Tegra/bootloader/l4t_initrd.img)... done.
	populating kernel to rootfs... done.
	populating initrd to rootfs... done.
	populating /home/user/Desktop/Linux_for_Tegra/kernel/dtb/tegra210-p3448-0002-p3449-0000-b00.dtb to rootfs... done.
Making Boot image... done.
Existing sosfile(/home/user/Desktop/Linux_for_Tegra/bootloader/nvtboot_recovery.bin) reused.
copying tegraboot(/home/user/Desktop/Linux_for_Tegra/bootloader/t210ref/nvtboot.bin)... done.
copying cpu_bootloader(/home/user/Desktop/Linux_for_Tegra/bootloader/t210ref/cboot.bin)... done.
copying bpffile(/home/user/Desktop/Linux_for_Tegra/bootloader/t210ref/sc7entry-firmware.bin)... done.
Existing badpagefile(/home/user/Desktop/Linux_for_Tegra/bootloader/badpage.bin) reused.
copying wb0boot(/home/user/Desktop/Linux_for_Tegra/bootloader/t210ref/warmboot.bin)... done.
Existing tosfile(/home/user/Desktop/Linux_for_Tegra/bootloader/tos-mon-only.img) reused.
Existing eksfile(/home/user/Desktop/Linux_for_Tegra/bootloader/eks.img) reused.
copying dtbfile(/home/user/Desktop/Linux_for_Tegra/kernel/dtb/tegra210-p3448-0002-p3449-0000-b00.dtb)... done.
Copying nv_boot_control.conf to rootfs
Making system.img...
2

“system.img” is a very large file. First this is created as an empty loopback mounted partition with the full size as the end partition. Then content is copied into this, the file is renamed “system.img.raw”, and a smaller “sparse” file is created as “system.img”. This can take a long time. How much time did you allow?

While the process seems stuck, and when the process seems to have been stuck for at least several minutes, what do you see from this command (assumes you are in the “~/nvidia/nvidia/JetPack_...version.../Linux_for_Tegra/” directory):
ls -l bootloader/system.img*

If you then run that command a second time, about a minute later, have any file sizes changed?

I don’t know if there is any difference with mass flash, but at least one image would need to be created. I have not used mass flash, and I could see extra time required to create edits to multiple sparse versions of the content.

3

I waited about an hour several times for system.img, so I assume it’s legitimately stuck.

A solution I found so far is that I need to run ./apply_binaries.sh before using ./nvmassflashgen.sh. I originally used ./apply_binaries.sh->./flash.sh to make the original image, and then run ./nvmassflashgen.sh. Now it seems I have to do ./apply_binaries.sh->./flash.sh->./apply_binaries.sh->./nvmassflashgen.sh.

4

In theory apply_binaries.sh overlays the NVIDIA-specific drivers into the sample rootfs and will not have any effect on the actual flash operation. Flash creates a partition to use, but this is only preparation…the actual flash of that is treated as generic binary data and won’t care if apply_binaries.sh touch the data or not. So I am surprised that a second apply_binaries.sh changed anything…it sounds like a bug, but I have no way to test this.

And yes, an hour is definitely too long (at least for single unit flash). How many units are you flashing?

5

Hello @linuxdev
I was just just creating the mass image, so only one board was connected.

6

Are you in any way able to sudo ./apply_binaries.sh first, add your content, and then flash? If it refuses, then I think this is a bug.

7

Please excuse me, I was mistaken.
./apply_binaries.sh does NOT need to be ran first before ./flash.sh. It was just sheer coincidence that it worked the one time.