Compiling Kernel and DTB

[edward.dow]

Greetings All,
I’ve been following the RidgeRun guide to compile the kernel, dtb and modules on a host machine and then move them over to the Xavier.
https://developer.ridgerun.com/wiki/index.php?title=Compiling_Jetson_Xavier_NX_source_code_L4T_32.4.3

After all is compiled I do the following:

1. move the kernel Image to the Xavier in the /boot partition

2. modify the /boot/extlinux/extlinux.conf for this new kernel
   LABEL Lontium Toshiba
   MENU LABEL Toshiba Kernel
   LINUX /boot/Image.Toshiba
   INITRD /boot/initrd
   APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

3. boot to the new kernel using the debug console ( J14 pin block UART pins)

4. verify the new kernel was loaded
   uname -a
   Linux ams2 4.9.201-tegra #3 SMP PREEMPT Mon Sep 27 12:19:56 MDT 2021 aarch64 aarch64 aarch64 GNU/Linux

My question is on the DTB file(s). It is my understanding that the dtb file loaded at boot can be specified with the FDT line in the extlinux.conf file. Also, the dtb file that lives in /boot/dtb can be decompiled, modified, and recompiled.
dtc -I dtb -O dts -o kernel_tegra194-p3668-all-p3509-0000.dts kernel_tegra194-p3668-all-p3509-0000.dtb
dtc -I dts -O dtb -o kernel_tegra194-p3668-all-p3509-0000.dtb kernel_tegra194-p3668-all-p3509-0000.dts
Based on this:

Dtb files

This is incorrect due to the “.dtsi” file. An analogy with a C header file is a good way to describe a “.dtsi” file. Like a header a “.dtsi” is only part of a source file. You cannot compile a header any more than you can compile a “.dtsi” file. You need to include the dtsi into another dts file, and then build the whole file. It gets more complicated because this analogy only works when building the entire kernel source. Whenever you build a kernel or any part of a kernel there is a configura…

The RidgeRun guide outlines a different process of “flashing” these files. So, are either of these methods good to use when modifying the dtb file?

I have only used the decompile and recompile method for the dtb file but I haven’t been able to verify the new drivers I compiled are working with the devices. I suspect it has to do with the device tree and incorrect settings but I can’t rule out the process to build the dtb file because I’ve never done this before.

Thoughts?

Ed

[JerryChang]

hello edward.dow,

there’re two approaches for loading kernel image and device tree. loads by (1) partitions, and (2) root file system.
if you perform flash.sh to include -k options for partition update, it’ll update the binaries accordingly.
however, it’s cboot functionality to have higher priority by checking extlinux.conf and load binaries via root file system.
for example,
if you have LINUX specified, it’ll always load kerenl image via /boot/Image.Toshiba instead of kernel partition. you’ll need to remove the entry to make the binary load from partition. those binary doesn’t need to be sign/encrypt if they’re loaded by file system.

[edward.dow]

Thanks Jerry! This certainly clears it up.

So, when you flash the kernel and dtb files this is in separate hardware like an emmc, correct? It’s not doing anything with the SD card and the OS.

I did see that there is a signed dtb file in /boot/dtb/. My next question is how do you sign/encrypt but I see you have already answered that as they get signed when you flash the boot partition: Create .sig files for kernel and dtb

I think for now I just want to work with the kernel and dtb files in the root filesystem since we are making changes trying to get these drivers working with hardware.

[terrysu50z]

First you need to do a sudo blkid on the mmc and you will get a hint to what nvidia does with info and partitions.

To put a new kernel Image on the system, build it and move it to /boot/Image on your system, reboot and uname -a will show you the new kernel image.

the device tree, dtb is in a partition so you have to use flash.sh to put it on the system.

I have a makefile and I use these three lines to put a new dtb on the system, of course I do a make of the system and get a new dtb built and then do this. This is for my system, you might need to change files based on your hardware. Mine is tx2-4g. the -k kernel-dtb only moves the dtb to your system.

Of course you have to have the usb connection between your build machine and your system

I have this in my .bashrc, and it puts the machine in recovery mode without having to touch the switches.

alias recover=‘sync;sync;sudo reboot --force forced-recovery’

    sudo $(RM) bootloader/tegra186-quill-p3489-0888-a00-00-base.dtb
    cp sources/kernel/kernel-4.9/arch/arm64/boot/dts/tegra186-quill-p3489-0888-a00-00-base.dtb kernel/dtb/tegra186-quill-p3489-0888-a00-00-base.dtb
    sudo ./flash.sh -r -k kernel-dtb jetson-tx2-4GB mmcblk0p1

my make file FYI is. I use clone and install to make copies of my system to multiple systems.
make build builds everything
make seattleDTB installs a dtb
copy Image to /boot/Image gets me a new kernel

cat Makefile

make build – will bulid the device tree and kernel

make seattleInstall – will install a complete seattle system

make seattleDTB – will install a new DTB for the seattle system

make seattleClone – clone the rootfs from the seattle connected via the usb debug cable

all:

build:
cd sources/kernel/kernel-4.9 && CROSS_COMPILE=~/l4t-gcc/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- $(MAKE) ARCH=arm64 -j10

seattleInstall:
sudo $(RM) bootloader/tegra186-quill-p3489-0888-a00-00-base.dtb
cp sources/kernel/kernel-4.9/arch/arm64/boot/dts/tegra186-quill-p3489-0888-a00-00-base.dtb kernel/dtb/tegra186-quill-p3489-0888-a00-00-base.dtb
sudo ./flash.sh -r jetson-tx2-4GB mmcblk0p1

seattleDTB:
sudo $(RM) bootloader/tegra186-quill-p3489-0888-a00-00-base.dtb
cp sources/kernel/kernel-4.9/arch/arm64/boot/dts/tegra186-quill-p3489-0888-a00-00-base.dtb kernel/dtb/tegra186-quill-p3489-0888-a00-00-base.dtb
sudo ./flash.sh -r -k kernel-dtb jetson-tx2-4GB mmcblk0p1

seattleClone:
sudo ./flash.sh -r -k APP -G backup.img jetson-tx2-4GB mmcblk0p1

seattleBPMPDTB:
sudo ./flash.sh -r -k bpmp-fw-dtb jetson-tx2-4GB mmcblk0p1

Good Luck,
Terry

[edward.dow]

Thanks for all the great info Terry! There are some good gems in there.

On a general note with compiling the kernel, dtb and modules all the files are coming from the …/Linux_for_Tegra/source/public/ correct?
The reason I ask is I’m trying to compile the kernel with the tc358743 driver. I have a tc358743 .c and tc358743 _regs.h but no tc358743 .h. I’ve compiled the kernel and the module compiles as I get the tc358743 .ko. But I’m wondering if there needs to be a tc358743 .h in that directory with the .c and regs.h files. I found the tc358743 .h file in /usr/src/linux-hwe-5.4-headers-5.4.0-74/include/media/i2c/ but would it pull the .h file from there?

UPDATE: not sure why the find didn’t see it but it looks like all the header files are here: Linux_for_Tegra/source/public/kernel/kernel-4.9/include/

[terrysu50z]

source_sync.sh built sources in my Linux_for_Tegra. I put my Makefile in that dir, you can see i cd to sources/kernel/kernel-4.9 and do the make there.

when you copy Image you only get the kernel. Because you are using loadable modules, you don’t get to cross compile them unless you do a make install in the kernel dir and them also transfer the /lib/modules/… to get your loadable module.

I build my modules on the actual platform. and unload load to do the testing, while watching /var/log/syslog

rs232 console is very helpful also.

Remember clone will make a copy of your complete file system and create a backup.img and backup.img.raw on you build machine, you can then mv backup to bootloader/system.img to flash a copy of your system clone image. This is a good idea in case you brick your system, you can fall back to your last clone. You get back any system changes, sudo apt-gets and any /home/dir stuff you have, instead of going back to the very beginning and starting over again with your original flash, if you do a make install you do update system.img and get your new Image and *.ko files.

Terry

[edward.dow]

Thanks Terry… good info again.

Yes, I’ve been transferring the kernel over to the Xavier after I build it.
Also, transferring over the the loadable modules to the Xavier.

Something I ran into last night was the kernel build failed on the host box.
Tried to run ‘make mrproper’ to resolve but it didn’t work.
I had to delete the build directory in order to resolve the issue.

[terrysu50z]

try the make clean in the kernel dir, I don’t have problems, but the make clean normally makes things better,

Revert back to linux build/clean mine set, it is the same in the Nvidia environment. Only device tree is different because they have there low level boot environment and a different way of loading the device tree.

Terry