“kernel-dtb” is not the kernel, it is a device tree. If the correct device tree was already in place, then this is probably equivalent to doing nothing…so if your flash software had already been set up for the same release (such as either having used command line flash before or from JetPack having completed a flash), it would probably be harmless. I won’t guarantee it though, I don’t know what was there.
The “Image” file does not require flash. It is just an ordinary file copy.
The original “Image” file is lost on the Jetson, but is not truly lost because it is part of the install software. Tip: Never overwrite “/boot/Image”. Always copy with an alternate name, and then edit “/boot/extlinux/extlinux.conf” to point at the alternate Image name. Don’t remove the original boot entry of extlinux.conf, simply copy it and then use that altered Image name in the new entry. Use a serial console to pick the one you want at boot time…when it works as you want, then change the “default”. If you don’t have a serial console cable, then get one.
The reason the original Image file is not “truly” lost is because it is in the install software. If you used JetPack, then JetPack acts as a front end to the driver package and doesn’t actually do any flashing of its own. JetPack also unpacks some software. If you were to unpack the driver package, then you would have the “Linux_for_Tegra/” sub-directory within that. If you ran JetPack, then this too would have the same “Linux_for_Tegra/” sub-directory…but only because it unpacked the driver package for you.
Within “Linux_for_Tegra/” there is sub-directory “rootfs/”. Your entire root file system, other than a few edits, is then unpacked here. This is the “sample rootfs”. Mostly this is an exact duplicate of your whole Jetson. This sample rootfs only lacks some hardware-specific files. One of those is the “Image” file. The utility within “Linux_for_Tegra/” is designed to unpack those final files into “rootfs/”. In your case you don’t even need the sample rootfs, you just need the “apply_binaries.sh” step to put “Image” in “rootfs/boot/”.
Example, if you are in “Linux_for_Tegra/” directory and have flashed from here before using the same release as your Jetson:
…this should show the file is still there.
If you don’t have the “rootfs/boot/Image” file, then perhaps it was removed after the flash to save space. If you happen to have “Linux_for_Tegra/apply_binaries.sh”, then this would put it in the correct location:
If you have none of this, then simply download the driver package. That’s all you would need for that file. Since you probably have to flash it also means you might need the sample rootfs. However, a clone of your Jetson can substitute for the sample rootfs. If you have configured your jetson and customized it and are willing to spend the time to clone, then you can simply put the correct Image file onto the clone on your PC, then flash again using the fixed clone instead of the sample rootfs. You’ll be magically (minus perhaps some pain) be back with your original system.
FYI, when you clone you will get both a “.img” file and a “.img.raw” file. I always throw away the “.img” file because it can’t be edited or examined. In theory it is a “sparse” file, but the method of making it sparse is not standard and open source tools don’t seem to work with those. The “.img.raw” file is basically the entire rootfs of the Jetson (so probably close to 30GB in size). Assuming the name is “backup.img.raw”, then you can mount it on your host’s “/mnt” directory like this, and fix it:
mount -o loop ./backup.img.raw /mnt
cp /where/ever/driver/package/is/Linux_for_Tegra/rootfs/boot/Image /mnt/boot/
cp backup.img.raw /where/ever/driver/package/is/Linux_for_Tegra/bootloader/system.img
…then if in recovery mode with micro-B USB connected, this is a long flash:
sudo ./flash.sh <i><u><b>-r</b></u></i> jetson-tx2 mmcblk0p1
That “-r” option is important. With that option flash will not generate a new system.img. Instead flash will use the fixed clone since it was copied there and renamed “system.img”. If “-r” is missing, then a completely new root file system is generated from “rootfs/” and any “system.img” already in existence is destroyed. With “-r” you are all set. If something went wrong, you still have “backup.img.raw” and can simply try again. These uncompressed raw images are quite large and even a file copy takes a lot of time…flashes also take longer. But you can make as many mistakes as you want so long as you have an original image.
Do invest in a serial console cable. See:
Information on cloning is here. There may be differences depending on release, and you should not flash with a release which is different than what the original rootfs was built for. See:
The current L4T driver package and sample rootfs are here, but this is not what you want since it is a pre-release for Xavier (listed here for completeness):
Historic version listings are here (which you want…on the clone see “head -n 1 etc/nv_tegra_release” to see version if you don’t know):
…however, this URL requires you to go there, log in (same login as this forum), and then go there again…logging in won’t redirect you to the page you were looking for, and hitting the link prior to logging in won’t show what is there. Once you are logged and hit the URL again you will search for your release, e.g., for “R28.2” or “R28.2.1”.
Incidentally, if your kernel-dtb change did put the wrong device tree in, then the “-r” option clone flash will also fix that. The purpose of all that work is to copy “Image” from host PC to “/boot” of Jetson. Had the system been bootable, then that is all you’d need to do to put in a new Image. Recovery mode is not a bulk storage device, so it won’t allow a non-bootable Jetson to have simple file copies performed.