我的jetson orin nano 用SD卡烧录的JetPack5.1.1的镜像，我需要修改一下内核源码，移植4G的驱动，请问我在哪里可以下载对应版本的内核源码
Moving this to the Jetson forums for visibility.
Each L4T release (which is Ubuntu plus NVIDIA drivers) is tied to a given JetPack/SDK Manager release. You can get the source matching this by going to either of these (on your Jetson find the L4T release with “head -n 1 /etc/nv_tegra_release”):
You will find a “Driver Package (BSP) Sources”. This package contains other packages, one of which is the kernel source. Keep in mind that if you build the kernel you should start with a matching config to the running system. If you are to reuse existing drivers this also includes needing to match the CONFIG_LOCALVERSION. If you modify only by adding a driver then you probably want to keep the CONFIG_LOCALVERSION, but if you are modifying the source anywhere other than your ported driver, then you want to rebuild everything with a new CONFIG_LOCALVERSION.
我只需要在内核源代码种移植进去4G模块的驱动程序，有什么需要注意的吗?
还有就是想问一下有没有移植好后烧录程序的帮助手册,以便于我后续移植的时候查看.
For whatever reason the language translation mechanism is not showing up. Not sure why. I may not be able to fully respond, but I will add what I think you are asking about.
First, understand that if you create a module which is designed to work with the current kernel configuration, that the module install is a mere file copy, followed by something like “sudo depmod -a” to let the kernel know there is a new module. The Jetson documentation tends to concentrate on adding the content to the flash software and flashing the entire system.
Each kernel has either an “integrated” feature (something built in and not modular) via configuration, or it has a “modular” feature (something in the form of a loadable module). Not all features can be modules, and not all features can be integrated, but most have the choice. Virtual memory is an example of something which cannot be modular since it is too invasive. When you use a dependency-aware kernel feature editor (such as the menuconfig or nconfig targets during build) the “n” key is “no”, and disables the feature; the “m” key (short for “module”) enables a module; and the the “y” key (short for “yes”) integrates the feature into the kernel. If you modify source code of anything other than your module, or if any other feature is a dependency of that module, then you should treat this as if it is a change to the integrated kernel Image and not just a module change.
If you start with a matching configuration to the running kernel, including the CONFIG_LOCALVERSION feature, and you only add modules, then it is safe to only copy the module in place and leave all other existing modules and the integrated kernel Image untouched. If you start the same way, but you modify an integrated feature, then you should treat the situation as needing a new integrated kernel Image, and all modules would also need rebuilding and installing. When installing an actual kernel and not just a module it gets more complicated, and perhaps the initrd flash is required. This is riskier if something goes wrong; a module addition is very little risk. If you don’t need to add the kernel to the initrd (especially true for eMMC models which are not booting external media), then installation without any kind of flash is possible, but you need to be more careful than the case of installing just a module.
If you wish to follow the official documentation, then you would start by finding your L4T release (L4T is just Ubuntu plus NVIDIA drivers). That release can be found via “head -n 1 /etc/nv_tegra_release”. Then you go to the particular L4T release URL:
https://developer.nvidia.com/linux-tegra
That link will take you to both documentation and source code which is compatible with your particular installation.
Are you merely adding a module? If so, and if that module is compiled against the matching configuration to the running kernel, then take note on the Jetson of the output of the command “uname -r”. This is part of the path that the kernel will use when trying to find modules. The base prefix of the module path is this:
/lib/modules/$(uname -r)/kernel/
Note that if you were to look in your kernel source code, and to find the compiled module file, that the subdirectory within the kernel source would match the subdirectory of where to place the module within “/lib/modules/$(uname -r)/kernel/”. For example, if your module file is “custom.ko”, and if you find that module in the source code after build within subdirectory “drivers/custom/custom.ko”, then you would copy this file to:
/lib/modules/$(uname -r)/kernel/drivers/custom/custom.ko
You would then run the command “sudo depmod -a” and you would be ready to use that module (you might reboot, but even that is not mandatory if the module loads).
Note that a module not compiled against the running kernel might not load correctly. If we ignore an initrd for external media boot, then typically any change to the kernel itself (not the modules) would require updating:
- “
/boot/Image” (the kernel itself, everything with “=y” in the config editor, and more). - Everything in “
/lib/modules/$(uname -r)/”, and expect a new$(uname -r). - The
CONFIG_LOCALVERSIONwould need to change to work with the new “uname -r”. - Technically the above can just be copied, but there are some methods of copy which are safer than others, e.g., ones which leave the old kernel and modules in place but pick a new boot entry such that there is still a backup via the old kernel.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.