Flashing by SDK Manager ever updates /boot/Image?

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

This is a follow on regardng the issue of rebuilding DTB for IMX219 cameras with the latest L4T 32.4.3

We have a custom carrier board which supports RPi’s IMX219 and OV5647 sensors, working well on previous L4T versions. As the OS changes, we need to rebuild the kernel and DTB for the newer environment. We ran into several issues.

One of problems is to figure out the way to update the kernel and DTB on TX2. We are developing the DTS and driver C codes on a host PC running Ubuntu 18.04. There seems getting different results by flashing the Image and DTB using SDK Manager versus copy Image and flashing DTB only.

From the timestamps in /boot/, the files seem not all got updated by SDKM flashing. Here is the list:

tmx3@tmx3:/boot$ ll
total 56960
drwxr-xr-x 5 root root 4096 Aug 17 23:50 ./
drwxr-xr-x 22 root root 4096 Jul 28 15:33 …/
drwxr-xr-x 2 root root 4096 Jul 28 15:28 dtb/
drwxr-xr-x 2 root root 4096 Jul 28 15:34 extlinux/
drwxr-xr-x 2 root root 4096 Aug 17 23:50 grub/
-rw-r–r-- 1 root root 34330632 Jul 28 15:28 Image
-rw-r–r-- 1 root root 5565615 Jul 28 15:28 initrd
lrwxrwxrwx 1 root root 24 Aug 17 23:49 initrd.img → initrd.img-4.9.140-tegra
-rw-r–r-- 1 root root 15232206 Aug 17 23:50 initrd.img-4.9.140-tegra
-rw-r–r-- 1 root root 370903 Jun 25 21:38 tegra186-quill-p3310-1000-a00-00-base.dtb
-rw-r–r-- 1 root root 368634 Jun 25 21:38 tegra186-quill-p3310-1000-as-0888.dtb
-rw-r–r-- 1 root root 1010 Jun 25 21:38 tegra186-quill-p3310-1000-c03-00-base-adafruit-sph0645lm4h.dtbo
-rw-r–r-- 1 root root 371412 Jul 28 15:28 tegra186-quill-p3310-1000-c03-00-base.dtb
-rw-r–r-- 1 root root 2716 Jun 25 21:38 tegra186-quill-p3310-1000-c03-00-base-fe-pi-audio-z-v2.dtbo
-rw-r–r-- 1 root root 3381 Jun 25 21:38 tegra186-quill-p3310-1000-c03-00-base-hdr40.dtbo
-rw-r–r-- 1 root root 371432 Jun 25 21:38 tegra186-quill-p3310-1000-c03-00-dsi-hdmi-dp.dtb
-rw-r–r-- 1 root root 364294 Jun 25 21:38 tegra186-quill-p3489-0888-a00-00-base.dtb
-rw-r–r-- 1 root root 364388 Jun 25 21:38 tegra186-quill-p3489-1000-a00-00-ucm1.dtb
-rw-r–r-- 1 root root 364388 Jun 25 21:38 tegra186-quill-p3489-1000-a00-00-ucm2.dtb
-rw-r–r-- 1 root root 1010 Jun 25 21:38 tegra194-p2888-0001-p2822-0000-adafruit-sph0645lm4h.dtbo
-rw-r–r-- 1 root root 275957 Jun 25 21:38 tegra194-p2888-0001-p2822-0000.dtb
-rw-r–r-- 1 root root 2716 Jun 25 21:38 tegra194-p2888-0001-p2822-0000-fe-pi-audio-z-v2.dtbo
-rw-r–r-- 1 root root 3505 Jun 25 21:38 tegra194-p2888-0001-p2822-0000-hdr40.dtbo
-rw-r–r-- 1 root root 275994 Jun 25 21:38 tegra194-p2888-0001-p2822-0000-maxn.dtb
-rw-r–r-- 1 root root 1010 Jun 25 21:38 tegra194-p3668-all-p3509-0000-adafruit-sph0645lm4h.dtbo
-rw-r–r-- 1 root root 2716 Jun 25 21:38 tegra194-p3668-all-p3509-0000-fe-pi-audio-z-v2.dtbo
-rw-r–r-- 1 root root 3697 Jun 25 21:38 tegra194-p3668-all-p3509-0000-hdr40.dtbo

Notice that initrd.img link was created last near midnight, which was the time SDKM ran. However, the Image file stays at “July 28”.

My questions are:

  1. Does SDK Manager take the Image from the host and put it to /boot/Image? If not, where is the Image placed on TX2?
  2. As suggested by various sources online, can I directly copy the Image built on the host to TX2’s /boot/Image? If that’s the case, how the boot sequence load the Image?
  3. Do I need to do “sync” aferward?
  4. What about DTB? How the files relates the dtb under /boot?

I’ll report on DTB and kernel driver related coding issues on a separate topic.

Thanks in advance.

3

hello tmx3,

you may refer to NVIDIA SDK Manager, it download all the necessary packages to your host for setting up your environment.

please refer to /boot/extlinux/extlinux.conf for the boot sequence.
it loads the kernel binary file from the LINUX entry, you may replace /boot/Image with your customize kernel image, perform a warm-reboot to make it works.
device tree by default loads from the kernel-dtb partition; you may enable flash commands to update kernel-dtb partition, or, you may modify /boot/extlinux/extlinux.conf by adding FDT entry to specify the path of kernel-dtb binary file.

you may also check flashing messages for details,
for example,

[  86.0954 ] Writing partition kernel with boot_sigheader.img.encrypt
[  86.1045 ] [................................................] 100%
[  86.1603 ] Writing partition kernel-dtb with tegra186-quill-p3310-1000-a00-00-base_sigheader.dtb.encrypt
[  86.1701 ] [................................................] 100%
4

@JerryChang, thanks for detailed instruction and confirming the replacement of kernel image to /boot/Image is a proper thing to do.

Now, on the other hand, flashing TX2 with SDK Manager seemed not replacing the file to /boot/Image directly. Is that correct? Just want to make sure the timestamp on the /boot/Image stays unchanged is not a concern, so I can rule it out in the debugging process. For example as shown above, After flashing with SDKM on Aug 17, the /boot/Image file remains from July 28:

-rw-r–r-- 1 root root 34330632 Jul 28 15:28 Image
-rw-r–r-- 1 root root 5565615 Jul 28 15:28 initrd
lrwxrwxrwx 1 root root 24 Aug 17 23:49 initrd.img → initrd.img-4.9.140-tegra

Is that normal?

5

hello tmx3,

if you’re using SDK Manager to flash the board. for example, you’re installing JetPack-4.4 GA, those binaries will be the date you’d download JetPack-4.4 GA images.

you may update those binaries to perform partition update.
for example,
to enable flash script to update kernel-dtb,
you may go to the download path, i.e. ~/nvidia/nvidia_sdk/JetPack_4.4_Linux_JETSON_TX2/Linux_for_Tegra/
replace kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb with your customize device tree,
after that, using flash scripts $ sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1 to perform an update.

you may also refer to documentation, such as Building the NVIDIA Kernel, and Flash Script Usage for reference,
thanks

6

Hi JerryChang,
That’s the step we used to take to flash the DTB. Since our camera carrier board support both IMX219 and OV5647 cameras (as for Raspberry Pi), we did the other half of the work by following JetsonHacks’ script to build the kernel on TX2 directly.
With the release of latest JetPack 4.4 and L4T 32.4.3, I don’t know if JetsonHack’s script is still applicable. That’s why I used SDK Manager to flashing the Image and DTB from a host machine instead.

I have followed the " NVIDIA Jetson Linux Developer Guide, 32.4.3 Release" closely to re-build the kernel and DTB on a host PC. The results are copied to ~/nvidia/nvidia_sdk/JetPack_4.4_Linux_JETSON_TX2/Linux_for_Tegra/kernel/ in order to run SDKM.

For the purpose of IMX219 and OV5647 sensors, I did not do the step 7 and 8 of “Building the NVIDIA Kernel” as described in kernel customization of the developer guide.
Specifically, they are:

$ sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=/Linux_for_Tegra/rootfs/

$ cd <modules_install_path>
$ tar --owner root --group root -cjf kernel_supplements.tbz2 lib/modules

So, is it that okay to skip the step of module installation?
Actually, I don’t know what’s to install in the process.

Please elaborate. Thanks.

7

I have not followed all you are doing, so is just a general comment on modules, and incomplete for your case…

Any time you change the Image you might have changed the output of uname -r. That Image always looks for modules at “/lib/modules/$(uname -r)/kernel/”. If your old Image and new Image share uname -r, then the old modules will still be there and found, although this might or might not be “a good thing” (will say more below). If your “uname -r” changed, then it guarantees you must install modules to the new location even if the modules themselves are otherwise exactly the same.

Whenever you build a kernel, if you fail to set the CONFIG_LOCALVERSION to match the old one, or if the actual source release version changes, then you are guaranteed “uname -r” will no longer match. There is also a pesky “+” which might show up if the scm_version decides to kick in, but this can be dealt with.

Regarding whether or not it is good to keep the “uname -r”, if you were to build a kernel with the exact configuration of the previously running kernel, then yes, it would be better to just keep all of the old modules and reuse them. If you were doing debugging and the existing modules were stripped, then you might find it useful to install (and overwrite) the existing modules with what is essentially already an exact match…the difference then would be having debug symbols. Or the reverse, have small stripped modules, and unknowingly adding size not necessary for normal operation.

If you were to change a kernel Image configuration such that it only adds modules to an otherwise matching configuration, then it is highly likely that all you need to do is copy the extra modules in place, but I’d do that a single module at a time. I would recommend not using the “... INSTALL_MOD_PATH=/where/ever/Linux_for_Tegra/rootfs/” option directly to the module directory. This will install more than you intended if you are just working on adding new modules. I’d always recommend on installing to a temp location first and looking through to see what is actually going in place. You might look at it and say you want everything, but you might examine it and find it installs far more than you expected.

If you were to instead significantly change the Image configuration, then you would definitely want the uname -r to change. There are dependencies, and when you remove non-module features, you might get lucky and it will work, but it would be logically better to not take that chance and purposely change the CONFIG_LOCALVERSION so your “uname -r” intentionally changes (and then install the full set of modules).

You can of course strip debug symbols and reduce module size at any time. See:
https://forums.developer.nvidia.com/t/why-the-built-modules-based-on-nvidia-official-kernel-source/107328/2

8

Hi linuxdev, thanks for the notes. That truly explained the idea of rootfs configuration. After a few days of scrambling, we finally figured out our problem and got the imx219 DTB built / flashed with the latest r32.4.3.

I’ll report later on the details of settings to build imx219. Let me first share an experience regarding the timestamp of /boot/ so readers can tell quickly if SDK Manager indeed flashed the desired Image and DTB or not.

Check out the timestamp below on Image and tegra186-quill-p3310-1000-c03-00-base.dtb. They should be new at the built-time while the rest might stay older when SDKM made them the first time.

tmx3@tmx3:~$ ll /boot
total 127924
drwxr-xr-x 5 root root 4096 Jan 28 2018 ./
drwxr-xr-x 22 root root 4096 Aug 20 15:30 …/
drwxr-xr-x 2 root root 4096 Aug 20 15:25 dtb/
drwxr-xr-x 2 root root 4096 Aug 20 15:31 extlinux/
drwxr-xr-x 2 root root 4096 Jan 28 2018 grub/
-rw-r–r-- 1 root root 34199560 Aug 20 15:25 Image
-rw-r–r-- 1 root root 5565615 Aug 20 15:25 initrd
lrwxrwxrwx 1 root root 24 Jan 28 2018 initrd.img → initrd.img-4.9.140-tegra
-rw-r–r-- 1 root root 88119321 Jan 28 2018 initrd.img-4.9.140-tegra
-rw-r–r-- 1 root root 370903 Jun 25 21:38 tegra186-quill-p3310-1000-a00-00-base.dtb
-rw-r–r-- 1 root root 368634 Jun 25 21:38 tegra186-quill-p3310-1000-as-0888.dtb
-rw-r–r-- 1 root root 1010 Jun 25 21:38 tegra186-quill-p3310-1000-c03-00-base-adafruit-sph0645lm4h.dtbo
-rw-r–r-- 1 root root 279993 Aug 20 15:25 tegra186-quill-p3310-1000-c03-00-base.dtb
-rw-r–r-- 1 root root 2716 Jun 25 21:38 tegra186-quill-p3310-1000-c03-00-base-fe-pi-audio-z-v2.dtbo
-rw-r–r-- 1 root root 3381 Jun 25 21:38 tegra186-quill-p3310-1000-c03-00-base-hdr40.dtbo
-rw-r–r-- 1 root root 371432 Jun 25 21:38 tegra186-quill-p3310-1000-c03-00-dsi-hdmi-dp.dtb
-rw-r–r-- 1 root root 364294 Jun 25 21:38 tegra186-quill-p3489-0888-a00-00-base.dtb
-rw-r–r-- 1 root root 364388 Jun 25 21:38 tegra186-quill-p3489-1000-a00-00-ucm1.dtb
-rw-r–r-- 1 root root 364388 Jun 25 21:38 tegra186-quill-p3489-1000-a00-00-ucm2.dtb
-rw-r–r-- 1 root root 1010 Jun 25 21:38 tegra194-p2888-0001-p2822-0000-adafruit-sph0645lm4h.dtbo
-rw-r–r-- 1 root root 275957 Jun 25 21:38 tegra194-p2888-0001-p2822-0000.dtb
-rw-r–r-- 1 root root 2716 Jun 25 21:38 tegra194-p2888-0001-p2822-0000-fe-pi-audio-z-v2.dtbo
-rw-r–r-- 1 root root 3505 Jun 25 21:38 tegra194-p2888-0001-p2822-0000-hdr40.dtbo
-rw-r–r-- 1 root root 275994 Jun 25 21:38 tegra194-p2888-0001-p2822-0000-maxn.dtb
-rw-r–r-- 1 root root 1010 Jun 25 21:38 tegra194-p3668-all-p3509-0000-adafruit-sph0645lm4h.dtbo
-rw-r–r-- 1 root root 2716 Jun 25 21:38 tegra194-p3668-all-p3509-0000-fe-pi-audio-z-v2.dtbo
-rw-r–r-- 1 root root 3697 Jun 25 21:38 tegra194-p3668-all-p3509-0000-hdr40.dtbo

More on the setup for IMX219 driver/dts soon…

9

hello tmx3,

please have a try to modify /boot/extlinux/extlinux.conf by adding FDT entry to specify the path of kernel-dtb binary file. for example, /boot/dtb/tegra186.dtb, and you should replace that with your customize one, perform a warm-reboot it make it works.
thanks

10

Good to know that FDT in extlinux.conf can work now. Saw some notes back in 2017 that FDT and extlinux.conf were removed in favor of u-boot. That could be a useful alternative.

Now, we are in the process to finish up the installation of Jetson SDK Components after flashing the Image and DTB.

By the way, we learned another little experience with SDKM when the USB connection no longer worked after flashing. We struggled a little with the USB connection to continue STEP03 on SDK Manager.

The thread of Unable to install Jetson SDK Components with SDK Manager on Jetson TX2 saved our day. Basically, log into TX2 after a successful flashing, connect the network (wifi in my case), enter command ifconfig to find the IP address of TX2.

Go back to the host PC, use the TX2’s IP address to continue the STEP03 on SDKM. Pretty simple, and it works!

11

Let me close this thread for now. I think the answer to my subject is no. We found two ways to flash a customized kernel and dtb, but not with SDKM.

I will write a follow up on how to build and flash TX2 for RPi IMX219 camera. Until a better way is present, I’d say the answer is no for the moment because SDKM won’t take the updated Image from Linux_for_Tegra/kernel/Image to flash TX2.