Recompile Jetson Nano Developer Kit Kernel

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
12

Short answer: You always need to set CONFIG_LOCALVERSION. The value can be arbitrary, and my example will use “-rfcomm”, but missing a correct CONFIG_LOCALVERSION implies losing all kernel module drivers. The kernel cannot find modules if this is not correct. A kernel would also use the wrong modules if this remains the same and certain things change without changing the CONFIG_LOCALVERSION.

Can you use an editor like menuconfig or nconfig to set this “=m”? That would greatly simplify installation. Do be certain to not edit the .config file directly with an ordinary editor.

In the case where you do integrate this with “=y”, then you want a new CONFIG_LOCALVERSION, and you also will need to build all modules, and install both kernel Image and all modules. The location of the install of the modules will change. You can, for safety reasons, leave the old kernel Image there, and change a boot entry such that serial console can pick alternate entries if something goes wrong. This isn’t actually as bad as it sounds in the case of an SD card model Jetson since you can unplug the SD card from the Jetson and plug it into a host PC to fix. Then again, this too can change if an initrd is used.

I would suggest something like:
CONFIG_LOCALVERSION="-rfcomm"

I don’t know what your kernel version is, but let’s pretend it is 4.9.140, and that the existing or previous kernel responds to “uname -r” with “4.9.140-tegra” (which would be because 4.9.140 was compiled with CONFIG_LOCALVERSION=-tegra). You will have:

  • /boot/Image
  • /lib/modules/4.9.140-tegra/kernel/

A boot entry in “/boot/extlinux/extlinux.conf” will name:
LINUX /boot/Image

Thus boot will use “/boot/Image”, and modules will be found based on its “uname -r”. To add a new kernel, with an alternate entry, using the example version I mention above, you would also add:

  • /boot/Image-rfcomm
    (the suffix doesn’t actually do anything, it is just that I don’t want to overwrite the original kernel)
  • /lib/modules/4.9.140-rfcomm
  • A new entry in extlinux.conf.

This would leave both kernels present, and the old kernel would be the default, at least for testing. You’d have to install all content of modules in that location, and copy the renamed Image to the new name. Then, if your extlinux.conf looks like this, you’d extend it with the part at the end of the file:

TIMEOUT 30
DEFAULT primary

MENU TITLE p2771-0000 eMMC boot options

# This is the original default.
LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

# This is brand new, and an edit:
LABEL rfcomm
      MENU LABEL rfcomm
      LINUX /boot/Image-rfcomm
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

In that extlinux.conf above:

  • The “LINUX” key/value pair names the kernel itself. We did not overwrite the original Image file, it is still there.
  • The “LABEL” is not visible to the user, this is what the bootloader looks for internally. You need a new LABEL for the non-default entry, and I just used rfcomm because of obvious reasons.
  • The “MENU LABEL” is visible to the end user. When serial console is stopped to pick a new kernel during boot, it is numbered, and you pick by number, but that MENU LABEL is visible beside the number. So entry 1 will show “primary”, and entry 2 will show “rfcomm”.
  • I’m not sure if TIMEOUT is actually honored. But 30 seconds is a good value while testing. It might actually be that you have less than two seconds to hit a button at the right moment to interrupt boot and enter a different kernel choice (choice “2” for our example is the new kernel).

If you have serial console attached, and you pick 2, and something goes wrong, then you still have 1. If things work well, then you could make the new entry the first entry, and then change DEFAULT to rfcomm. If anything ever goes wrong, you still have a second kernel, e.g., if some update does something unexpected.

Really though, since this is on an SD card, you could leave the old content there (the Image file), but renamed, and leave the old modules in place, and simply make Image-rfcomm the default. I recommend always adding a new entry when you can (eMMC models with security fuses burned cannot do this; an initrd for booting external media will also alter the procedure). If space is an issue, then you could just directly replace Image, but I’d still recommend renaming it Image-rfcomm so it is never mistaken for the stock kernel (and you’d also have to edit LINUX to name Image-rfcomm in extlinux.conf).

1 Like