The device I use is jetson-tx2 4GB, and it is normal to use JetPack4.4 to flash the machine, and there is a problem with the debugging kernel.
Use L4T Driver Package (32.4.3), add debugging information to the kernel source code, compile, copy the Image to the Linux_for_Tegra/kernel/ directory, and then use the command to flash to the target board, but it was unsuccessful:
sudo ./flash.sh -r -K kernel/Image jetson-tx2-4GB mmcblk0p1, but the kernel has not been flashed successfully, and the previous kernel is used.
sudo ./flash.sh -r jetson-tx2-4GB mmcblk0p1, the device cannot start normally.
I suspect that the way to update the kernel is incorrect?
Just a note which might help: During a flash the kernel in “Linux_for_Tegra/kernel/” is copied to “rootfs/boot/” (some content is also alternatively copied into a partition after signing). Then the partition for rootfs (“APP”) is generated based on that content (creating “bootloader/system.img.raw” and “bootloader/system.img”). When the new rootfs is installed the kernel is installed (at least for the rootfs copy method). If you use “-r” then the APP/rootfs image is never generated. Should you be installing the old “bootloader/system.img” (because you used “-r” to tell it to not update), then no new “Linux_for_Tegra/kernel/” content will be installed, only the previous system.img will install.
Also, if content has two possible install locations, and boot uses the other content (e.g., a device tree can be a file in “/boot”, or it can be a signed partition), then even though you installed the content to one location the changes won’t show up (since the other location is being used).
If you really want to install a new kernel, and if the kernel is in “/boot” of the Jetson (versus in a partition using signed content), then it is simpler to just add it via copy to “/boot” (and perhaps use an alternate name and new extlinux.conf boot entry while testing). If you are using more advanced features, e.g., secure boot or redundancy partitions, then you would want to use the flash tool.
When you perform any kind of command line flash I recommend you save a log. The log will be something you can go back to and clearly see which files are copied where. Just append “2>&1 | tee log_flash.txt”. Example: sudo ./flash.sh jetson-tx2-4GB mmcblk0p1 2>&1 | tee log_flash.txt
I deleted the parameter “-r” and the flashing machine still cannot start.
In order to locate the problem, only use “printk” in the source code to add printing information, without other modifications.
In the TX2 (8GB) version of the device, the kernel can be updated by replacing /boot/Image directly before the device. Is the 4GB version possible? The result of my attempt was failure.
In addition, in a normal 4GB device, I tried to delete /boot/Image, but the system can still boot normally. Is the system not using /boot/Image? Please give me some help, thanks
Try it: With Jetpack4.4, the device works. Use the kernel source code (L4T 32.4.3), compile Image without modification, replace it to Linux_for_Tegra/kernel/ directory, and use the command to refresh.
The device can start, but the startup screen keeps flashing with a printed message:
Failed to start Load Kernel Modules.
Failed to start nvpmodel service.
Resolved. 4.9.140 does not match the kernel before 4.9.140-tegra and CONFIG_LOCALVERSION is required.
Thank you linuxdev! Failed to start Load Kernel Modules
When you say “without modification”, do you mean that the configuration was set to the default, and that CONFIG_LOCALVERSION was “-tegra”? Or just no source code change? I’m thinking the former, but want to confirm. If the former, then “uname -r” would have had “-tegra” appended to the command’s result, and the path to finding modules would be valid for the existing kernel modules.
For the log_flash.txt, what was the command line you used which provided the log? It doesn’t look like it was from directly running flash.sh, so I am uncertain about some of the output. The log looks more like something which JetPack/SDKM would produce.
In the case where a kernel boots, but flashing occurs, I suspect there is something preventing the GPU driver from loading into the X server. In that case serial console and ssh should still function, and it would be possible to get a copy of the “/var/log/Xorg.0.log” file. Additionally, a serial console boot log under those exact circumstances would be very valuable.
Note that the message about “Failed to start Load Kernel Modules” is different than failing to load an Xorg compatible GPU driver, and it makes me suspicious that CONFIG_LOCALVERSION was not correctly set (which would normally be “CONFIG_LOCALVERSION=-tegra”), and thus “uname -r” changed, making it impossible to find the kernel modules. If you have serial console, then you might provide the output of “uname -r” in addition to the Xorg log. A serial console boot log would include that detail.
FYI, the kernel appends the “CONFIG_LOCALVERSION” to the base kernel version when producing the output for the command “uname -r”. For example, if the kernel were source version “4.9.140”, and if “CONFIG_LOCALVERSION” is “-tegra”, then “uname -r” produces “4.9.140-tegra”. The location where the kernel expects the modules to be found is: /lib/modules/$(uname -r)/kernel
If you don’t have the kernel modules at “/lib/modules/$(uname -r)/kernel”, then this guarantees kernel module load failure.