About the making of the mirror of the Jetson-nano module

Dear Sir,
I am having trouble making a mirror of the nano module. I now have the Linux_for_Tegra 4.2.2 downloaded via sdkmanager.
I make sure that the nano board to be mirrored has entered recovery mode and connected to the pc via usb.
Execute the command: sudo ./flash.sh -r -k APP -G /home/somebody/system.img jetson-nano-emmc mmcblk0p1
It gives the following error: 00000004: Failed to get an accessor of secondary boot device

Someone suggested that I use TX1 to create an image file. I also tried.
[url]https://www.elinux.org/Jetson/TX1_Cloning[/url]
The input command gets the same error.
Is there any reliable step or reference for making nano module image files?

the most reliable way to do it, since Jetson Nano uses SD card, is to unplug the sd card and clone the whole sd card. just remember to clone all the partitions.

the downside is that you will not be able to use it on SD card with different sizes.

But what I am focusing on now is the production of the image of the Nano module, which uses emmc, not sdcard.

hello 1251566963,

we’re able to reproduce the same failure on Nano platform with eMMC.
please expect this might take a while for investigation, thanks

Dear JerryChang,

Is there any progress now? Because we really want to solve this problem to improve our production efficiency, waiting for your reply!

Try one:
Equipment: a nano module board with fully built environment.
After logging in, enter the df command to view the filesystem. /dev/mmcblk0p1, which has a size of 14G, so I try the command:
sudo dd if=/dev/mmcblk0p1 of=/media/JOJO/myudisk/nano.img
After 30 minutes, I got an img file named nano.
I open another board just finished burning, open the terminal and input the command.
sudo dd if = /media/JOJO/myudisk/nano.img of=/dev/mmcblk0p1
After a while, the screen went black and the board couldn’t start.

You need to copy the whole disk, not just the one partition. The rootfs you copied is the actual operating system, but I wouldn’t expect the unit to be able to boot far enough to load the operating system unless the other supporting partitions are also copied. Example:

# No "p1".
sudo dd if=/dev/mmcblk0 of=/media/JOJO/myudisk/nano.img
# New SD inserted, copy to whole SD, not just p1:
sudo dd if = /media/JOJO/myudisk/nano.img of=/dev/mmcblk0

Note that a larger block size in copy might copy faster, although it would still depend on the device being copied to/from. Just make sure you don’t pull the SD out before clean umount (“1M” is 1MiB…this implies buffering and will make this run a bit faster…I think the default when not specifying is “bs=512”, but it might actually be 1 byte):

sudo dd if=/dev/mmcblk0 of=/media/JOJO/myudisk/nano.img bs=1M
sudo dd if = /media/JOJO/myudisk/nano.img of=/dev/mmcblk0 bs=1M

Thanks for your advice,but does the command work on Nano platform with eMMC?

I tried the advice from linuxdev and got the image but couldn’t successfully burn it to another board,which is Nano platform with eMMC.

The dd command itself won’t care what it runs on…this command is an exact bit-for-bit binary copy without any knowledge of what the underlying data is.

eMMC images and SD card images are unlikely to be compatible with each other. Sometimes one revision of hardware needs changes relative to another hardware revision. Also, there are many more partitions than just the rootfs, and the rootfs needs to match the release of the other non-rootfs partitions. Are you trying to clone from an SD card release and write to an eMMC release (or the other way around)? Or are both units the same type of Jetson? Are the two units involved the same hardware revision?

I got the image file from a Nano platform with eMMC and want to burn it on another board with eMMC.I use the same Nano module carrier to run the board. Is the parameter “bs=1M” important? I forgot to enter the command with this parameter and I failed to burn the image file to another board.

The blocksize (“bs=…”) is unimportant. This just provides higher performance and less time in most cases. Actual result will be the same with or without this.

I don’t have a Nano with eMMC, but if it is like flashing with the other Jetsons (and it probably is), then you could make a dd copy of the rootfs (or a clone using the flash.sh tool), then flashing the new Nano with the same release of L4T/JetPack/SDK manager, but substituting the clone for the sample root filesystem, should do what you want.

That sounds a bit complicated, but here is some information on what a clone and flash does (just to emphasize, I haven’t worked on the Nano with eMMC, but other than a few details this should be exactly the same as doing this on Xavier or TX2 or any of the other Jetsons)…

Of the many non-rootfs partitions, flashing will produce these. The actual root filesystem (rootfs) is the operating system. Flash software normally takes a purely Ubuntu sample rootfs, applies some binary drivers on top of this, and then flashes both the non-rootfs partitions and the rootfs. One can modify the sample rootfs prior to flash, and other than some boot related edits the content will be 100% copied to the actual eMMC of the Jetson. Instead of using the sample Ubuntu distribution you can use an already existing image (such as a clone). The release which produced the system being cloned must match the system being written.

When a partition is read by “dd” and then saved somewhere this is the same as cloning. The use of “dd” will not work as expected unless the partition is read-only during the dd read. The clone mechanism guarantees read-only because the Jetson is in recovery mode and an external tool is doing the reading (sort of a substitute for dd).

The “flash.sh” program (command line, found in one of the subdirectories of “~/nvidia/nvidia_sdk//Linux_for_Tegra/”) can be told to “reuse” the existing image (the “-r” option) during flash. If it turns out you’ve run the flash before, then this will reuse the sample rootfs image; if you’ve replaced that with a clone or dd, then the rootfs becomes the clone or dd instead.

I am unsure of command lines for cloning the eMMC type of Nano module, but this should do the job if someone can comment on clone/flash on command line for this version of the Nano.

Note that a clone provides both a “backup.img” file and a “backup.img.raw” file. The “raw” file is larger, but is much more useful. The “backup.img” file is a “sparse” file, and is much smaller, but can only be used for flashing (it can’t be examined or edited the way a raw image can). When either of these are placed in the “Linux_for_Tegra/bootloader/” directory with file name “system.img” the flash will succeed. The only reason the smaller “sparse” file is used is that it takes less time to flash this.

To reemphasize, the flash with the “-r” option will still flash the non-rootfs files, but the actual rootfs will be your file instead of the default sample. These files must use the same release of software.

Hello friends, I have a new idea but I don’t know if it works. I used a mobile hard drive and entered the following command on the pc:

sudo umount /dev/sdb1
mkfs.ext4 /dev/sdb1

Then I inserted the mobile hard disk into the nano module board and entered the command

df -h

I could see the /dev/mmcblk0p1 and the /dev/sda1
Then I entered the command

sudo dd if=/dev/mmcblk0p1 of=/dev/sda1 bs=1M

When it finished, I enter the mobile hard disk and found it was same as the nano rootfs.
The new board is plugged into the nano carrier. I guess if I can boot the nano from the mobile hard disk, I can enter the command

sudo dd if=/dev/sda1 of=/dev/mmcblk0p1 bs=1M

to finish the burn task?
How can I start nano from the mobile hard disk?

.

I can’t answer the boot questions, but there is a flaw in the dd copy. The problem is that although the commands are technically correct, the content of the mounted partition can change in the middle of the copy. “dd” is unable to compensate for content which changes during the copy. There is a possibility of corruption or broken content depending on the combination of the moment of copy and the moment of something changing.

That said, it might work, but if it works, then I wouldn’t expect it to always work.

Someone else will need to suggest how to boot from an external disk on the Nano (I am unsure of what drivers are present in U-Boot).

I am also trying to get this to work. Any update would be very much appreciated.

I’ve been thinking about this, and I was wondering if this might work. We have access to both development Nano modules and production Nano modules. Would it be possible to create and modify an image from an SD card on a running Nano, take that SD card to another computer, capture the APP partition on that SD card as an image using dd, and then write that captured image to the APP partition of a production Nano using flash.sh?

Or would this cause problems? I can’t actually think of a reason why this would necessarily cause problems. As far as I know, the development and production versions of the Nano both use the same rootfs initially. The only difference I know of between them is in the device tree. But there could easily be something I’m missing.

hello waynegqfwh,

may I know what’s your requirement for using dd commands to clone APP partition.
did you expect to duplicate all your customization and also pre-install applications to the other Nano boards?

you may execute below commands on your platforms, and you’ll found there’re several partitions.

$ ls -al /dev/disk/by-partlabel

you may clone the APP partition (i.e. back-up.img), and then replace $OUT/Linux_for_Tegra/bootloader/system.img with it.
you’ll still need local machine to perform flash script to flash the other Nano boards.
please also do remember to add “-r” commands, which skip building and reuse existing system.img.
thanks

Thank you!

In answer to your questions, yes. This won’t duplicate all our customizations (some are done in the device trees and in the bootloaders), but it will hit everything in rootfs, and that is where the majority of our changes are made. We want to be able to load a new Nano or reload an existing Nano without having to go through and make all the changes by hand, or having to maintain a script. Actually, there are a lot of benefits, including not having to connect the Nanos to the Internet, or even have Internet networking enabled on the device, in order to get all the packages that we need installed.

hello waynegqfwh,

there’re several allocated partitions,
you’ll need to update DTB partition for device trees changes; please update LNX partition for bootloaders (u-boot) changes.

you should also refer to Jetson Nano Boot Flow, you’ll need to execute flash script to generate encrypt files for these partitions.
FYI,
here’s a discussion thread, Topic 1064654, sharing the tool to create a signed DTB file without host machine.
thanks

Any news on this as I am in the same position. I have a production module setup, 10+ manual steps, and need to make 9 more copies.

BR

Joolz