Cross-compilation kernel

Hi all, I followed this link Kernel Customization β€” Jetson Linux<br/>Developer Guide 34.1 documentation to customize my kernel with cross-compilation, I was wondering once I get the kernel image, when I go back to the jetson should I copy the image to the boot folder? and then as for the kernel modules how do I go about it? If someone could explain me the steps to do when doing cross-compilation thanks

FYI, most of the procedure for this are the same on L4T R34.x, but R34.x software is incompatible with a Jetson Nano (Orin Nano differs from plain Nano).

Here are some URLs you might be interested in, but keep in mind that it is possible to add a second kernel without deleting the original if you are using a serial console (one can interrupt boot at the right moment in serial console and pick a kernel entry). It is best to keep the old kernel until you know the new kernel works.

Keep in mind when reading this that some of the platforms mentioned are different Jetson models.

1 Like

the thing I was wondering is at the time I put the modules in β€œTEGRA_KERNEL_OUT” and do cross-compilation, when I go to the target platform besides copying the kernel image with these modules what do I do?

The first thing to know is that if you are building a kernel which differs only by modules (β€œ=m”), and not by what is integrated (β€œ=y”), which includes the CONFIG_LOCALVERSION (see the suffix of command β€œuname -r” to see the CONFIG_LOCALVERSION of the running kernel; usually it will be β€œ-tegra” on a Jetson), then all modules currently in existence will continue to work. For that case the entire task is to copy just the new module(s) to the right place.

Each kernel looks for its modules at β€œ/lib/modules/$(uname -r)/kernel”. The β€œuname -r” itself is a combination of the kernel version (contrived examples: β€œ5.15.0” or β€œ4.10.140”), and that β€œCONFIG_LOCALVERSION” is appended to that. In those examples, if β€œCONFIG_LOCALVERSION” is β€œ-tegra”, then modules would be searched for at one of these examples:

  • /lib/modules/5.15.0-tegra/kernel/
  • /lib/modules/4.10.140-tegra/kernel/

You should set a matching CONFIG_LOCALVERSION if and only if the integrated features of the new kernel (the ones chosen with β€œ=y”) are a match to the running kernel. You should alter CONFIG_LOCALVERSION (e.g., β€œ-modified”) if one of the integrated features change.

If this is a match to the old integrated features, ignore every module (and even the kernel Image) and copy in only the new modules to the correct location.

If this is not a match to the old integrated features, then use a renamed Image (e.g., β€œImage-modified”…it is convenient to name the kernel after the CONFIG_LOCALVERSION, but that’s just my taste in naming), and add an entirely set of new modules to the new location.

Have you kept your old integrated features? Have you created only a module format driver? Or have you changed either β€œCONFIG_LOCALVERSION” or integrated features?

Yes I kept the same functionality, and i put config_localversion=-tegra, so here if I follow these steps: Kernel Customization β€” Jetson Linux Developer Guide documentation I have to copy kernel_supplements.tbz2 from my pc to my target platform (jetson nano) and the content (that would be the modules) I put them in lib/modules of my target platform?

First of all, be sure you are not using the source code or instructions for L4T R34.x. Use the content from your L4T release (β€œhead -n 1 /etc/nv_tegra_release”).

Second, the docs concentrate on setting up everything, and not on minimum effort. If you’ve received kernel source, then the source itself does not need to go on the Jetson. If the .tbz2 file is from you packaging a kernel and modules that you’ve built, then you can use that. If you’ve simply added modules with all other information correct, and if your Nano is not using some optional boot device other than the SD card on a dev kit, then you would have to do much more work.

In the case that your kernel and config matches, and you are not using any special boot (e.g., and initrd to an NVMe is a special boot), then you only have to copy any new module files in place, and then run β€œsudo depmod -a”. After that you can reboot or not, and then run whatever uses that module.

Note that when you build something in the kernel as a module, that the kernel source will have a subdirectory β€œdrivers/” and other subdirectories within that. Let’s say for example your module is created as β€œsomething.ko”, and that this is located in the kernel source at β€œdrivers/examples/” as β€œdrivers/examples/something.ko”. When you go to the actual Jetson, and you β€œcd /lib/modules/$(uname -r)/kernel”, then you will see subdirectory β€œdrivers/examples/”. You would copy β€œsomething.ko” to β€œdrivers/examples/something.ko”. Then run β€œsudo depmod -a”. You’re done, although you could reboot.

yes the .tbz as you can see it is obtained from this command here tar --owner root --group root -cjf kernel_supplements.tbz2 lib/modules and I used the base configuration which would be tegra_defconfig so I shouldn’t have any additional functionality

What module or feature did you add? What edit? For example, for some feature name, did you use the menu editor with the β€œm” key to turn that feature into a module? The goal is to find the .ko file generated by this, but there are likely a lot of files to pick among.

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