Jetson orin nx 不使用源码的方式,不进去刷机模式,如何克隆系统到另一块板子上?



Thanks for visiting the forums! Your topic will be best served in the Jetson category.

I will move this topic over for better visibility.


A Jetson uses recovery mode to access the functions needed for flash. Recovery mode is the Jetson becoming (temporarily) a custom USB device. Jetsons do not have a BIOS, and cannot self-flash, which is why the custom USB device method was chosen. The result is that the flash software is really a custom USB driver. That driver runs only on a Linux desktop PC architecture, but Jetsons are aarch64/arm64, and so other Jetsons have no driver for flashing other Jetsons.

If a Jetson is fully booted and running, then there are things you can do to back up partitions or data. Or you can backup and restore in recovery mode even if nothing works. For one Jetson to help another both Jetsons must be fully up and running, and there are a lot of limitations on what can be done.

Incidentally, JetPack/SDK Manager is a front end GUI to the actual flash software. The flash software itself, when downloaded without that GUI, is known as the “driver package” (it is, after all, a custom USB device driver). Answering ways to deal with your issue depends on knowing a lot of detail about which model of Jetsons are used, whether or not they use external storage, whether they use eMMC storage, whether they use SD card storage, whether the carrier boards are from third parties, so on. It isn’t possible to make better recommendations without knowing those details, but beware that recovery mode Jetsons are not bulk/mass storage devices.

目前我们基于jetson Orin nx开发的控制器,系统存储用的是外部nvme ssd卡,出厂系统都是通过硬盘拷贝机拷贝的,核心板单独通过源码刷spi flash。但是如果是整机组装好后,ssd卡就不方便拿下来拷贝。所以想探索一种不适用recover mode模式,能够从一台系统复制到另外一台系统的方法;

I am only speculating, but do your Jetsons have the A/B partition redundancy enabled, and is the system in question fully up and running? If so, there might be a way to use dd or rsync. rsync would be preferable for a number of reasons, but the recipient would have to be able to mount that partition to write via rsync. Although dd will possibly work it is quite dangerous to do so with a partition which is mounted…which means you’d have to write to the backup partition, boot to that, and then write to the original partition. I have not worked with A/B redundancy though, so I don’t know the details for that. However, if you are interested in trying to work with the unmounted backup partition, I can give some suggestions on writing to this partition over ssh and/or rsync. It would be up to you to work with A/B switchover.


If one system can directly plug in the NVMe of another system (which means physical access, removing the drive from one, then making it available to the other), then this is trivial. If the NVMe is not directly accessible from the restore source, then the only possibility is if the other system is up and running. However, a complete restore simply isn’t going to work since there are too many files which are in use and locked. You could easily restore some content, including home directories, but system content is another story.

If your destination of restore has multiple boot entries with multiple rootfs partitions, then in theory it would also be easy for the case that you can restore a partition that is from the other boot entry (and thus that rootfs is not locked and is not in use).

Do keep in mind that Jetsons don’t have a BIOS. This is why they cannot self-flash and need a host PC (recovery mode temporarily turns a Jetson into a custom USB device…this is not mass storage). During boot software must do everything that a BIOS would have done, including setting up power rails and clocks. If the boot content is too far out of date, or using something incompatible from a release that does not match what the rootfs is attempting to boot with, then boot will fail. The boot chain itself is not necessarily standardized, although UEFI has helped a lot. An example is that you are guaranteed to have boot failure if you use an L4T R35.x (JetPack 5) boot environment with an L4T R36.x (JetPack 6) boot environment and the rootfs is not from the same release (you cannot use the boot environment of a different major release; sometimes you can use the same boot environment with a different rootfs release if it is a minor patch and not a major release difference).

The basic story boils down to restoring an NVMe is not 100% of what is needed to boot unless the boot environment content also matches. Restoring an NVMe is not so easy on a running system which has locked part of that content unless you wish to restore only the unlocked content.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.