L4T 32.4.2: DTB & Image files vs. nvidia-l4t-kernel* debian packages

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi,

I am trying to understand the image build process in L4T 32.4.2, and it appears that new debian packages are included in the process that I haven’t noticed before (nvidia-l4t-kernel, nvidia-l4t-kernel-dtbs).

It seems that the nvidia-l4t-kernel package contains the kernel Image and modules, and that the nvidia-l4t-kernel-dtbs includes the dtbs.
If I understand correctly, those debian packages are the ones installed to the rootfs when running apply_binaries.

This raised some questions:

  1. If those debian packages are the ones used in the rootfs, then what is the purpose of the Linux_for_Tegra/kernel/Image file, and Linux_for_Tegra/kernel/dtb? It seems that there are still used in the process. Can someone explain why?
  2. General question about dtbs - if I understand correctly, they are flahed into a dedicated partition, but they also exist in the rootfs - why do we need both? What happens if only one is updated?
  3. If I am building a custom kernel, do I have to replace both Linux_for_Tegra/kernel/Image and the nvidia-l4t-kernel package?

Thanks!
Koby

3

Hi,

If those debian packages are the ones used in the rootfs, then what is the purpose of the Linux_for_Tegra/kernel/Image file, and Linux_for_Tegra/kernel/dtb? It seems that there are still used in the process. Can someone explain why?

General question about dtbs - if I understand correctly, they are flahed into a dedicated partition, but they also exist in the rootfs - why do we need both? What happens if only one is updated?

I think these two are actually same question.

There is a back-story about how this works. Prior to rel-32.3, since Xavier series platform does not support extlinux boot, the cboot could only read the kernel and dtb from partition. But on other platform which has uboot like TX1/TX2, they can load the kernel image and dtb from rootfs.

However, after rel-32.3 (included), xavier starts to support extlinux boot so it can read the image and dtb from rootfs too.

If above story is clear to you, we come back to your questions…

For kernel image:
When you run “sudo ./flash …” command to flash your board, it will actually update the kernel image in rootfs again.
So if you put kernel image under Linux_for_Tegra/kernel/Image, it will take effect.

For dtb:

Though I said rel-32.3 supports extlinux boot, we don’t enable it by default. Thus, the dtb is still reading from partition.
You could try to remove the dtb from /boot/ and it shall still boot up without problem.

If I am building a custom kernel, do I have to replace both Linux_for_Tegra/kernel/Image and the nvidia-l4t-kernel package?

Since Linux_for_Tegra/kernel/Image will take effect, you don’t need to update the nvidia-l4t-kernel package at all.

1 Like
4

Hi,

Thanks for your detailed answer.

Regarding the Linux_for_Tegra/kernel/Image note - are you 100% sure this is the case?

From my testings, and also from the apply_binaries.sh code, the Linux_for_Tegra/kernel/Image is only copied to rootfs if TARGET_OVERLAY != true (and in my setup it seems to be set to true, which triggers the debian installation instead)

5

Hi,

I think we should clarify this question to a simple one.
→ What is the file that would make kernel image update correctly?

My answer is also simple, the rootfs/boot/Image file is the one that will be read.

You should firstly clarify what is your test steps for us too so that we can check which part might be wrong.

For me, I update the kernel image almost everyday by directly replacing the Image under /boot on device.

When I want to use flash to update kernel, I put the Image under Linux_for_Tegra/kernel/Image and that’s all. I won’t run apply_binaries.sh anymore because I don’t need it.

6

Yeah, I agree that according to my tests and understanding (from what you’ve wrote before), the kernel file that is eventually read is rootfs/boot/Image
Also, I understand that replacing /boot/Image on a running device will do the trick

However, the thing that doesn’t make sense to me yet, is while flashing from scratch, if updating Linux_for_Tegra/kernel/Image eventually makes it to rootfs/boot/Image - from my understanding it doesn’t (when TARGET_OVERLAY != true, which is the default).

My setup is NX installation with L4T 32.4.2. In the past, I know that your statement was true, I am just wondering whether it is still true with L4T 32.4.2 and I’m missing something

7

Hi,

However, the thing that doesn’t make sense to me yet, is while flashing from scratch, if updating Linux_for_Tegra/kernel/Image eventually makes it to rootfs/boot/Image - from my understanding it doesn’t (when TEGRA_FLASH != true).

Maybe you are right. Actually, I seldom do this update because it is wasting time to do all this work just for updating kernel image.

I think you could directly do the test. No need to keep checking the source code.

Please just copy your new Image to Linux_for_Tegra/kernel/Image and do the full flash directly. No need to run apply_binaries.sh.

Also, remember you have to run without “-r” because “-r” will not create new system.img so the rootfs is still the old one.

8

Ok I think I’ve came into an understanding here - and I think both of us were right in some sense :)

  1. In newer versions of L4T, ./apply_binaries.sh doesn’t overwrite rootfs with kernel/dtb, kernel/Image and kernel_supplements.tbz2 like it used to be. This functionality can be restored with --target-overlay flag, which skips the debians usage and falls back to the older approach
  2. Specifically for kernel/Image and the specific DTB file - ./flash.sh is the one that “saves you”. Apparently, it also does an overlay (that is, it copies the kernel/Image file to rootfs/boot/Image). This is not true for kernel modules (kernel_supplements.tbz2)

(The thing that confused me before I think was that I was comparing md5sums which is incorrect (probably some signing process))

BTW, solution #2 is probably quite bad - overwriting a file that was originally installed by a Debian package is something one should usually avoid, but it definately works.

Thanks for your help @WayneWWW

11

Yes, you are right. We finally get this test on rel-32.3.1. Put the file under Linux_for_Tegra/kernel will not take effect anymore.

I guess it still flashes the partition but it is just no working for rootfs.

There may be a fallback mechanism. If you delete the Image from rootfs, it would probably fallback to partition to read Image.

12

Hi WayneNNN,

Just to correct here, ./flash.sh does overwrite the rootfs/boot/Image with the kernel/Image (Line 1479: cp -f "${kernel_fs}" "${rootfs_dir}/boot"; chkerr;)
However, if apt-upgrade is run on the system, it will be overridden (when a new nvidia-l4t-kernel dpkg is installed)

In genral, once nvidia chose to package the kernel using debian files, any attempt to apply something behind the debian package back, is wrong and should probably be removed

13

Hi,

Actually I am not sure what is going on either.
I would like to know why did you mention apt-upgrade or deb filese here. The flash.sh should not call the apply_binaries.sh so these deb files should not get involved here.

15

I just had a quick check about the sha1sum value of different kinds of release.

For every Xavier series, the value between kernel/Image and rootfs/boot/Image are different
But the one which uses uboot are all the same.

Sorry that I didn’t check the code to find out the cause of it.

What really confused me is the question you want to ask here.
Sorry that I don’t get what is your purpose and what you wanted to ask. Could you give some explanation?

16

Sorry, wasn’t too clear before.

I didn’t mean that flash.sh is running apply_binaries.sh or apt-upgrade.

The note about “apt upgrade” is not related to the nvidia scripts at all. It is just a note on why overriding a file (in this case /boot/Image) that some debian package provides (in this case, nvidia-l4t-kernel) is a room for chaos. For example, let’s say the nvidia scripts override the /boot/Image, and then the user or ubuntu decides to do apt upgrade, this change is likely to be overridden.

Right now I don’t have any open question, you helped me a lot with your first description and it really helped clearing stuff for me.

In my last post I just wanted to notify you that ./flash.sh does replace the rootfs/boot/Image with kernel/Image, because here you said it doesn’t:

17

Got it.

There is unknown reason that causes NX/Xavier will have different image under kernel and rootfs/boot.
I will check it if I have time. Looks like my earliest comment about the behavior of flash.sh is correct.

18

Yes it is

Maybe the different image behavior you’re seeing is because of signing? I see signing occurs when tegraid = 0x19

19

Yes, it could probably be signing.