How can I flash jetpack 4.2.2 to my TX2?

Hi emrahbaysan,

Are you using the devkit or custom board?

I don’t know the exactly reason why you want to use old Jetpack4.2.2 release.
But you can download the SD card image (for the devkit) of Jetpack 4.2.2 from the following link
JetPack 4.2.2 Archive | NVIDIA Developer

1 Like

Hi Kevin,
I have a camera system working with multiple TX2s. one of them have failed and i want to replace it. But replacement TX2 doesnt have the proper software installed and I want to clone one of the others.
Multiple attempts are failed and as I understand from previous posts I need to have same jetpack/l4t versions in the new board. below link to show you the carrier board.

Currently I have found the 4.2.2 and able to flash it over sdk manager. But I am facing an issue with it.
It starts flashing properly in recovery mode. in some point it restarts the TX2 and expecting to continue flashing for SDK components.
When I check the TX2 screen I can see the agreements to be approved but USB of the carrier board do not work. Keyboard is not functioning, even no power on the usb. Same carrier board is properly working with another TX2.
Means I have no control over the TX2 to continue the installation. SDK manager is not connecting to continue sdk components installation.
I took the TX2 back to recovery mode and SDK manager giving warning about ssh connection, even usb selected. I connected TX2 to a network and make it to get an IP address. But its same. SSH error. even usb or ethernet selected in sdk manager.
No idea how to continue currently.

@emrahbaysan So is the flash successfully finished or not?

Also, is this your first time flashing a device or not? Your comment sounds like so. You need to configure your user account in either headless or monitor to proceed.

Incidentally, since this is a third party carrier board, unless it is an exact duplicate of the dev kit carrier board, the device tree will differ. It is quite possible the software provided for the Leapard Imaging board differs from the 4.2.2 only by a device tree (it would be a bit rare, but perhaps this is a duplicate of the dev kit…but highly likely not). This means that you would need not just the dev kit 4.2.2 flash software, but instead you would want the board support package from Leapard (the same release they used when the rootfs was created). Does Leapard have their own flash software for that model?

Yes Wayne, it is first time for me. I couldn’t complete the flashing because I was not able to complete account creation because of usb is not working.

I’ll check with the leopard imaging if they have something for this as @linuxdev suggested.

Hi everyone,
I have contacted with the board producer and they send me dtb file to flash with kernel. USB worked after that and 4.2.2 flashing finalized successfully. thanks to @linuxdev

But I have another issue, not sure if i should open another sub, but I will ask from here.

I have flashed the jetpack 4.2.2 and copy the backup to it with below command
sudo ./ -r -k APP jetson-tx2 mmcblk0p1

When I restarted the new cloned tx2 I got an error mentioning /var/log cant be mounted.

when I search in forum I found @linuxdev 's comment in another sub . but not sure if it may help me.

Also i found (cant find now) another solution to remove mounting of /var/log from some settings. but not sure how it will affect. my aim is to create an exact copy of the master TX2.

One common point to consider is that there is a lot of boot content in other partitions. That content must be compatible with the rootfs. If at some point you only flash the rootfs, then it is possible the previous non-rootfs content is from the wrong release (unless that Jetson has been specifically flashed before with that release). If you flashed everything, but reused the rootfs from a clone, then the release being used to flash should be the same release which originally flashed the Jetson the clone came from.

Also, before you clone, make sure the Jetson has a clean filesystem. The point there is that if the Jetson is shut down improperly, e.g., power cut instead of a software command, then the filesystem corruption will also exist on the clone. Incidentally, you can loopback mount the raw clone on the host PC and see if it has corruption if you wish. Mounting it read-only from the host PC, directly mounting “bootloader/system.img” (if it is a raw image), is a useful test.

One does not normally back up the boot content. The idea is to install the boot content fresh with a release matching the original.

Unfortunately same result.
I have checked multiple times, get backup again from properly closed master device. Double checked the jet pack versions etc.
I am getting can’t mount /var/log error.
Can you suggest to pass this and find a way to mount on Linux?


I would like to suggest another way to debug here.

Please follow this website and dump the boot up log from serial console.

This will tell more about your situation instead of depending what you saw on monitor.

Thanks @WayneWWW , I’ll try by tomorrow and update in here.

Hi @WayneWWW ,
I was struggling to reach to serial port as producer was placed a resistor wrong. we have reworked and able to reach it now.
You can find boot up log in attached txt file. looks like it can not find an ext4 file system.
tx2 boot-up log.txt (109.9 KB)

Hi @emrahbaysan

Just a reminder that, your log seems not copied correctly. As I saw, it looks like below… seems not quite readable.

Also, could you clarify this again about how did you flash your board exactly? I has been almost 2 weeks from you so actually I forgot about how you flashed your board.

And it sounds like it is a custom carrier board?

tx2 boot-up log.txt (86.6 KB)

I have copied it over putty. not selecting the text but just right click to the header and select copy all to clipboard function. then past it to notepad ++ and save it as txt. its showing good in notepad in windows.

reminder for previous steps:
I have a tx2 not functioning properly and wanted to fix it by cloning from another functioning one. This way I would be able to keep all services and apps running properly. I dont have chance to install them from scratch.

As I understand from other people’s posts I need to have same version of jetson of master in the copy to make it working properly. Because of that I have flashed the new TX2 with same jetpack version over a linux machine with SDK manager. Flash was successful and I was able reach to the clean TX2 interface.

Then I have clone the APP part of master TX2 with below command,
sudo ./ -r -k APP -G backup.img jetson-tx2 mmcblk0p1

then copied the img file to bootloader,
sudo cp backup.img.raw bootloader/system.img

and connect the new TX2 to copy APP to it
sudo ./ -r -k APP jetson-tx2 mmcblk0p1

Then I received error on bootscreen
FAILED : Failed to mount /var/log
DEPEND: Dependency failed for local file systems

Couldnt move further yet.


I just want to double confirm,

  1. So this TX2 problematic device could be flashed by pure sdkmanager jetpack4.2.2?

  2. Is the “master TX2” also using a jp4.2.2?

I need to correct something on the versioning. Its 4.2.1.

  1. Yes, it can be flashed with 4.2.1 and I could reach to its interface.
  2. yes, it is 4.2.1


I have more things to clarify here.
To make it easier to tell, I will name your problematic TX2 as TX2-NG and master TX2 as TX2-M.

Are you sure the TX2-NG was previously flashed with jp4.2.1 before you did the clone? Just a reminder that “-r -k APP” will not flash the whole board, it will just flash the APP partition.

From what I saw, your device tree running on TX2-NG is based on rel-32.5. I guess it should be rel-32.5 unless you have some weird naming to name a 32.2.1 kernel with rel-32.5 name…

[ 0.181801] DTS File Name: /home/sjx/32.5.0_code/code/kernel/kernel-4.9/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts

I was sure until you told this :) what I ll do is to flash TX2-NG again with jp4.2.1 from sdk manager and share screenshots as well.
I ll update in here.

Thanks for helping.

The log is actually ok, but hard to read because it has a forced line wrap. This might be a feature of the serial console program being used. Turning off line wrap at a specific column would solve that and make reading easier (the person viewing would then be where line wrap is chosen). Or you could perhaps tell it to wrap about 30 columns further to the right.

I noticed some i2c errors. Is the device tree correct for that carrier board’s i2c items?

Hi @linuxdev , thanks for comment. How can I check the device tree is correct or not? May master tx2 logs from serial port helps?