cd $TOP
make -j $(nproc) O=$TEGRA_KERNEL_OUT Image
make -j $(nproc) O=$TEGRA_KERNEL_OUT modules_prepare
make -j $(nproc) O=$TEGRA_KERNEL_OUT modules
make -j $(nproc) O=$TEGRA_KERNEL_OUT dtbs
make -j $(nproc) O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT
make -j $(nproc) O=$TEGRA_KERNEL_OUT INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT
make -j $(nproc) O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT modules_install
I don’t know if this has any dependencies. Did you edit this directly, or did you use a dependency-aware editor like menuconfig or nconfig? CONFIG_USB_MON=m
(this quite possibly does not matter, but I also don’t know if this has dependencies)
I do like your build steps, the details are correct. Keep in mind that some kernels though will need a particular compiler release to function correctly. Official docs normally talk about this for a cross compiler release. I do not know for this code what the required compiler release is, but you might check on the system it was compiled on (it seems to be native compile directly on the Jetson) with “gcc --version”. Then compare with the L4T release docs about anything that mentions a compiler version. Find the L4T release with “head -n 1 /etc/nv_tegra_release”. Then go here for docs specific to that release: https://developer.nvidia.com/linux-tegra
The initrd might be the issue, or it might not. Note that when you install a full kernel that you need to also install the newly built modules (there might be exceptions, but it is not safe to assume the modules will work when the CONFIG_LOCALVERSION has changed). So instead of just renaming the 5.15.136-tegra to 5.15.136-custom and adding the one new module there I would recommend completely installing the entire new set of modules into the initrd at the new location. Overall I think what you have is correct.
Your UEFI is not set to provide debug information, which might help, but it seems that the kernel starts normally so that probably does not matter. The log stops when the mouse loads, but it succeeded with the keyboard, so at least part of the USB HID is working.
I have not looked at the module you are using so I can’t say what the requirements are. However, do check to see if it has dependencies. Also I would try to boot without that module being available; this would cause it to fail to load, which is ok because boot does not depend on that feature (in fact you might not have needed the module in the initrd unless you wanted its use to become available immediately). Once booted, if it “fails to fail”, then you’re one step closer. Then attempt to insmod the module manually and see what happens (you might want to monitor “dmesg --follow” as you insmod).
Incidentally, is this all on eMMC? Or perhaps it is an SD card model? There are differences in cases where you have optional boot devices.
I build kernel on Jetson. Native compilation without cross compilling.
I using nvme drive. I using not devkit
gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
head -n 1 /etc/nv_tegra_release
R36 (release), REVISION: 3.0, GCID: 36191598, BOARD: generic, EABI: aarch64, DATE: Mon May 6 17:34:21 UTC 2024
Thanks for the tips. I looked at my steps and saw some mistakes.
Repack initrd without root user.
Try nconfig for add module.
Try replacing the modules directory in the initrd and the kernel started.
Now there are other problems:
The network does not work and the graphics do not work correctly.
In the original modules (-tegra) there is an updates directory and there are modules there that are not in the modules I built. Such as nvgpu.ko and others.
When I load a module (usbmon) via insmod. Dmesg does not show anything but when loading the module via depmod, an error is displayed:
Bad version passed usbmon.
lsmod show load module.
Why not build additional modules (nvgpu) I copied the .config file?
This latter part is a question perhaps @KevinFFF or @WayneWWW can answer:
Why not build additional modules (nvgpu) I copied the .config file?
I’m not certain if nvgpu.ko is in mainline now, or if it is still external.
If depmod fails in this manner, then it could be a configuration (during compile) issue. On your original source I will recommend you start with “make mrproper” (and if root owns anything, then perform this as root). Then start over using that as your $TOP (and only then setting up your environment variables). It seems like perhaps there is still something built based on a previous config. If the modules were built against the kernel that you also just built, then I would not expect there to be a depmod issue.