Can't build custom kernel on the Nvidia Jetson Nano Dev Kit

Hi All,

I am having problems trying to change some of the CONFIG variables in my Jetson Nano Dev Board’s kernel. I follow the steps exactly as they are in this link: https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3261/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/kernel_custom.html#wwpID0E0WD0HA, and in between steps 3 and 4 i run the following command: make O=$TEGRA_KERNEL_OUT menuconfig to make the changes I want. I set VERSION to -tegra and CONFIG_TEGRA_HTS_GTE to y. I am doing this so I can access the iio drivers for the BMI088 IMU from Bosch.

After following the steps in the above link and restarting my Jetson Nano Dev Board i run zcat /proc/config\.gz | grep CONFIG_TEGRA_HTS_GTE and see it has not been set. Furthermore if i look at the .config file in /usr/src/linux-headers-4.9.253-tegra-ubuntu18.04_aarch64/kernel4.9 i see no change has been made.

Any help that can be offered is much appreciated.

It sounds like you started correctly. How did you actually install the kernel? Also, do you boot any external device for storage as the root filesystem, e.g., NVMe, or is it a purely SD card model with no special storage? My guess is the installation is the key, and knowing the above would help in giving correct instructions.

1 Like

Hi,

I think what linuxdev says is correct, the problem is the installation.
If you want to confirm the kernel Image was updated, run the command uname -v, it provides the kernel build time.
For debugging purposes, since you are enabling the driver as built-in module, you could copy the new kernel Image into the root file system (/boot/Image). For example using scp

Then confirm the new kernel was installed with uname -v then try zcat /proc/config\.gz | grep CONFIG_TEGRA_HTS_GTE

I assumed the install was done using step 7 from the link above: $ sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install \ INSTALL_MOD_PATH=<top>/Linux_for_Tegra/rootfs/ where ‘top’ is /usr/src/linux-headers-4.9.253-tegra-ubuntu18.04_aarch64/kernel4.9 . After this i rebooted. The Dev Board is only using a microSD card, nothing external. I also store the L4T Driver Package and L4T Driver Package Sources in the Downloads folder, not sure if that makes a difference or not. uname -v returns feb 2022, thus you are correct i did something wrong in terms of the installation.

Samir,

Are you building the kernel in the host PC?
After step 8, keep the SD card in the board, set the recovery mode, and flash the SD.
Then, you should see that a new kernel image is running.

Manuel Leiva
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: www.ridgerun.com

Hi Manuel,

I am building natively on the Jetson. How do I do those steps please?

I have not tried to build the kernel natively, but If you already have an Image kernel file using a native compilation, you can try to replace the original kernel Image (/boot/Image) and reboot the board.

Manuel Leiva
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: www.ridgerun.com

That would install modules to the rootfs. This does not install the kernel Image file. So you have new modules in place, but Image is the old one.

Try this experiment:

  • Copy Image to the running Jetson as:
    /boot/Image-new
  • Edit “/boot/extlinux/extlinux.conf” (more on that below) to point at the new Image-new.

Technically, you could just replace the old Image with Image and not rename it. I prefer a testing step though, as well as having the old kernel in place for backup if something goes wrong. You’ve been installing via flash, but it might be better to test first and have a backup entry.

In extlinux.conf you will have a block similar to this (this isn’t from a Nano, so it won’t match, but it will be similar):

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      FDT /boot/dtb/kernel_tegra234-p3701-0000-p3737-0000.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 usbcore.usbfs_memory_mb=256

You could copy that to a new entry which contains the old Image, and edit the first (which would make your kernel the default, but if it failed, serial console could interrupt boot and pick the original). We’ll give a new LABEL and new MENU LABEL and name the different Image (which has file name Image-new):

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image-new
      FDT /boot/dtb/kernel_tegra234-p3701-0000-p3737-0000.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 usbcore.usbfs_memory_mb=256

LABEL original
      MENU LABEL original kernel
      LINUX /boot/Image
      FDT /boot/dtb/kernel_tegra234-p3701-0000-p3737-0000.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 usbcore.usbfs_memory_mb=256

Summary:

  • The primary entry is the default. We changed the file /boot/Image to /boot/Image-new.
  • A copy of the primary entry has new LABELoriginal”.
  • The copy of the primary entry has new MENU LABELoriginal kernel”.
  • The default will use Image-new.
  • Serial console interrupt would place the new (primary) entry as “1” on choices, with label primary kernel.
  • Serial console interrupt would place the stock (original) entry as choice “2”, with label “original kernel
  • If it works, you don’t need to do anything. Image-new will load, boot logs will show this, and “uname -v” will show a new time. This new kernel will load the proper module directory.

If testing works, then you could remove the backup entry. You could also investigate proper placement in the flash content so that it flashes not just the new modules, but also the Image. The Image contains every kernel feature which is enabled via “=y”, while modules are a result of options via “=m” in configuration. The “integrated” set of “=y” is what starts the system. Without that it won’t load the modules.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.