Integrated Camera Issue - recompile the kernel

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi guys,
I have an issue concerning the use of the integrated camera on the JetsonTX2.

I recently bought a new camera of LeopardImaging (IMX390-GMSL2), but unfortunately after having recompile my jetson with the patch provided (no error during the process) I couldn’t use it properly.

After some exchange with the support team, the guy told me the camera wouldn’t actually work with Jetpac3.2.1… So now I want to re-compile my Jetson to re-use the integrated camera, how should I proceed ?

The procedure to compile for the camera was simple so I reversed it, I deleted certain of the file but I am not sure about step 7 (see the enclosed txt file describing the procedure): was the tegra186-quill-p3310-1000-c03-00-base.dtb file already there before patching ?
I mean did I just add it, in this case I just have to delete and recompile using the other .dtb file, or does the patch modify something in the file that can’t be reversed and in this case I don’t know what to do ?

Thank you in advance

IMX390-GMSL2_R28.1_TX2_NV_20180323.txt (3.93 KB)

2

FYI, so far as the kernel itself goes, you could just download the sample rootfs, unpack it somewhere, and find “Image” inside the “boot/” subdirectory. “zImage” is actually unused with the TX2 (it is a compressed version of Image).

I don’t know though about the device tree changes and other differences. You might be better off just flashing it fresh. You could clone first if you want to preserve a copy. See:
[url]https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/[/url]

Note that with U-Boot the easier way would have been to just add the modified kernel with an alternate name and then edit “/boot/extlinux/extlinux.conf”. Then, with serial console, you could just select the entry you want at boot time. Device tree itself might be a different topic for multi-boot.

3

Hi linuxdev,

I didn’t get this part of the message:

My problem now is as I have cancelled the “Image” file from boot/ in my jetson I can’t boot it again…I can put it in recovery mode and see it from the host computer using ‘lsusb’. What should I do to rebuild the kernel ? Is it possible to copy an Image file from host to Jetson in recovery mode ?

I tried doing the command from the Linux_tegra directory on my host pc:

sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

but I noticed this line, even if at the end it tells me everything went good (kernel-dtb updated successfully):

tegradevflash_v2 --iscpubl
[   3.9193 ] CPU Bootloader is not running on device.

What should I do to fix it ?

Another question: are the files lost or is it possible to recover them ?

Thank you

4

“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:

ls rootfs/boot/Image

…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:

sudo ./apply_binaries.sh

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:
sudo -s
mount -o loop ./backup.img.raw /mnt
cp /where/ever/driver/package/is/Linux_for_Tegra/rootfs/boot/Image /mnt/boot/
umount /mnt
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:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/

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:
https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/

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):
https://developer.nvidia.com/embedded/linux-tegra

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):
https://developer.nvidia.com/linux-tegra
…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.

5

Hi linuxdev,

first of all a big thank you for all your explanation !

I forgot to precise that I also apply this command:

sudo ./flash.sh -r -k APP jetson-tx2 mmcblk0p1

Which created a “bootloader” directory in my Linux_for_Tegra subdirectory (on my host), inside it I found the system.image.raw and a lot of other files (I supposed it’s the actual clone of my jetson right ?).

So if I understood well, I have to apply your procedure on my host:

sudo -s
mount -o loop ./system.image.raw /mnt
cp /where/ever/driver/package/is/Linux_for_Tegra/rootfs/boot/Image /mnt/boot/
umount /mnt
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 -r jetson-tx2 mmcblk0p1

Questions on the above procedure:

  • the “mount” command: should I first copy the system.image.raw in the /mnt directory ? or should I do it from the /bootloader cause I don’t get from which directory i should apply it…
  • the first “cp” command: i suppose the mount command will create the /mnt/boot/umount/mnt directory right ? (spaces in the text makes it hard to read the path…)

And I should have my jetson back to normal right ? but with or without all my files that were there before (script,packages I downloaded etc… ?

Thank you a lot again !

6
  • Do not copy your ".img.raw" to "/mnt".
  • "/mnt" is a customary pre-existing directory for mounting block devices. It is already there. Any directory could be used if you are not currently browsing that directory (if you "cd /mnt", then mount will refuse...the directory can't already be in use).
  • You could mount to any directory you want, "/mnt" is just convenient.
  • During a mount to a directory all content within that directory will be inaccessible. Unmounting brings the content back since it only became invisible or occluded by what you mounted there being on top of it.
  • Tip: Run "ls -ltr" within the directory you ran the clone in. This will sort by time and show the most recently modified or created files at the bottom of the list. Likely you will see a ".img" as newest file, and a ".img.raw" as second to newest. This is from where you ran the flash.sh directory, not from the "bootloader/" directory.

If the “flash.sh” command created an otherwise missing or unpopulated “bootloader/” sub-directory, then something was wrong when unpacking the driver package. It is true that among the reference files within the sub-directories of that directory chosen binaries will be copied to “bootloader/” based on the config of the flash command…I suspect this is what you are seeing and “bootloader/” probably existed prior to flash.sh.

The “system.img” and “system.img.raw” in that directory are left over from a previous flash. These are not from your clone, although you will be replacing “system.img” with your “.img.raw” (sorry, I can’t resist: “These are not the droidsclones you are looking for…”).

When you clone your command line determines the the backup file name prefix to use (if it is “backup.img” in the clone command line, then “backup.img” and “backup.img.raw” will be created). That name, in the directory where the clone command is run, will exist with both a “.img” and a “.img.raw” name. You probably want to delete the “.img”, but protect the “.img.raw” as it is the usable backup for editing. If you were to rename this “system.img”, and place it in the “bootloader/” sub-directory, then a flash with the “-r” (“re-use”) option would not overwrite this system.img and would use this for flashing the Jetson. Your Jetson would have whatever edits you made to the clone while it was loopback mounted. The first time you forget the “-r” option your system.img will be overwritten…this is why I warn you to use a copy of your “.img.raw” clone and to not put it directly there. This may be difficult since the clone is around 30GB.

Loopback can cause the file to pretend to be a block storage device (the loopback device which covers the image becomes a hard drive partition). You do not want the image file in “/mnt”, this is only where you will explore the loopback device, not the file. Changes to the content of the mount point will change the actual “.img.raw” file, but it will do it in a way which follows the ext4 file system structure instead of looking at it as a binary file. Basically, once the loopback of the image is mounted to “/mnt”, the content you see in “/mnt” is from a driver glued to the image. Normally the “mount” command mounts a partition, the “-o loop” allows it to mount an image pretending to be a partition.

When you do this, think of anything under “/mnt” as your actual Jetson’s “/” (use “ls” and cd to locations to verify, e.g, you should have a “/mnt/home/ubuntu/” which is ubuntu’s home directory with the exact content it last held). If you “cd /mnt”, then you are in the Jetson’s “/”. If you copy Image to “/mnt/boot/”, then you have copied Image to “/boot/” of the Jetson. When you umount and then flash (you shouldn’t flash with a mounted image…umount unmounts) using that “.img.raw” renamed or copied as “bootloader/system.img”, then any edits you made in “/mnt/” will appear on the flashed Jetson.

7

Hi linuxdev,

I really want to thank you for all your explanation, I’ve been able to reboot my jetson.

Problem: I lost all the package and even CUDA or cuDNN that is suppose to be with Jetpack…is it normal ?

8

The clone will have everything which was on the rootfs originally. Nothing should disappear unless either it wasn’t the clone which was flashed, or if the file system cloned had somehow been modified. If you mount your raw image from the clone on loopback on the host you should be able to look at the file location which was originally there and verify if the clone has this content. If flash did not provide that content, then it wasn’t the clone which was flashed. If the clone didn’t have that content, then the clone won’t have the ability to save something which is already missing.

One possible issue is if you experimented with flash commands prior to cloning…perhaps it flashed a new file system and the clone only saw what was new.

Another possibility is that if you replaced “system.img.raw” instead of “system.img” you would still be using a non-clone for flash. The original clone you must use is the “.img.raw”, but it needs to be renamed “.img”. Flash software works with either the raw image (“.img.raw”) or the sparse image (“.img”) and will automatically do the right thing…but flash always looks at the “system.img” file name and ignores “system.img.raw”…this latter raw file is a side effect of generating a brand new rootfs and is ignored by flash.sh.

There are also cases where a host PC file system can fill and truncate images…the images will be “normal” other than missing content due to no space left on device.