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.
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):
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).
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’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.
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
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.
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