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.
- Configuration matters:
- Official docs are found with your L4T release (β
head -n 1 /etc/nv_tegra_release
β):
https://developer.nvidia.com/linux-tegra - If you only add modules, then the answer is much simpler than if you integrate a feature into the kernel.
- If you boot to external media, then it gets a lot more complicated.
- Configuring
CONFIG_LOCALVERSION
changes install:
https://forums.developer.nvidia.com/t/topic/262647/12 - Some general kernel build information:
- A more complete answer to your question:
https://forums.developer.nvidia.com/t/topic/193640/11
Keep in mind when reading this that some of the platforms mentioned are different Jetson models.
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.