I see this in the 8_2022-11-11_16_35_03.log:
[ 6.466577] EXT4-fs (mmcblk0p1): 12 orphan inodes deleted
[ 6.473086] EXT4-fs (mmcblk0p1): recovery complete
[ 6.484061] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
The “CPU” shutdown log is not an error. This is just the power mode changing. CPU0 always runs since this handles hardware IRQs. Other CPUs (especially Denver cores) may shut down for power saving unless told to run (I think on the TX2 CPU1 and CPU2 are Denver cores).
Unless security fuses are burned you can simply use a file copy, but here is some information to note:
- The kernel itself determines the output of the command “
uname -r”. The prefix is the kernel version, the suffix is the CONFIG_LOCALVERSION feature during compile. The default is “CONFIG_LOCALVERSION=-tegra”. As an example, if the kernel source is version 4.9.190, and the default CONFIG_LOCALVERSION is set, then “uname -r” would respond with “4.9.190-tegra”.
- Each kernel looks for modules at “
/lib/modules/$(uname -r)/kernel”. If the modules are not there, or if incompatible modules are there, then modules will fail to load. Modules are part of the kernel, but load at run time.
- If you match the configuration of a kernel to the shipping version, and also match the “
uname -r”, then the kernel will find and load all of the original modules. One can add modules to this and simply copy them to the right location if you are only adding module features during a kernel build.
- If you build the kernel itself such that it has integrated new features into it, then it is possible old modules will be incompatible. In that case you’d be advised to change the “
CONFIG_LOCALVERSION” (e.g., to “-test”) and install all new modules at the new location. Not needed for additions via module if all else remains constant.
- During boot, if security fuses are burned, then the kernel can only be found in a signed partition which is updated by flash. Other than that you can generally just consider placing the new
Image file in “/boot”. However, I’d suggest a new name and adjusting “/boot/extlinux/extlinux.conf” so the original is still there. Example: Place the Image as “/boot/Image-test”, and then name that file in extlinux.conf.
An example entry for a TX2 extlinux.conf for a default case is this:
TIMEOUT 30
DEFAULT primary
MENU TITLE p2771-0000 eMMC boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
You could keep the original, and use it as a recovery system if you were to change it like this (I’m assuming your “uname -r” is now “4.9.190-test” as an example; this is just for clarity in naming and has no real effect):
TIMEOUT 30
DEFAULT testing
MENU TITLE p2771-0000 eMMC boot options
LABEL testing
MENU LABEL test kernel
LINUX /boot/Image-4.9.190-test
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
(the above implies copy of the compiled Image to become “/boot/Image-4.9.190-test”; if “uname -r” changes, then modules must also be rebuilt)
If no kernel is available via extlinux.conf naming a file, then it searches for this in the partition. During development it is easier to just use the file. You can of course just flash the kernel and skip file copy, but make sure extlinux.conf does not name a kernel.
Incidentally, the “-r” option to “flash.sh” says to “reuse” the existing “Linux_for_Tegra/bootloader/system.img” file. This prevents wasting time generating a new image. However, you need the other options to tell it to not flash the rootfs…any time you use “-r” without specifying something to flash other than rootfs it will flash rootfs, but it will be with a default image.
