After rebuilding the kernel with few added modules, I copied the Image from arch/arm64/boot/Image in the l4t source, to /boot/Image. The modules for my custom kernel were installed to /lib/modules/ when I ran make modules_install.
After rebooting, uname -a shows the original 4.9.108-tegra kernel still running. With previous Jetsons, if I recall, the steps I took were all that was required to install a new kernel. Is there an additional step I’m missing?
In the “.config” file you used to build, what is the “CONFIG_LOCALVERSION”? If it is “-tegra”, and if the original source is “4.9.108”, then “uname -r” would be “4.9.108-tegra”. Modules are searched for in “/lib/modules/$(uname -r)/”.
If the same source was compiled with the same CONFIG_LOCALVERSION, then this is normal. I have not looked at kernel install on Xavier yet, but you’d need to verify the version should actually differ…it might be valid that the “uname -r” is the same.
I have CONFIG_LOCALVERSION=“csg” in the .config in my kernel source.
I used zcat /proc/config.gz > .config then ran make menuconfig to make my changes, then I verified the changes were in my .config before building the kernel.
When the kernel compiled, I could see the modules I added being build.
Copying the new Image to /boot/Image doesn’t appear to be loading it.
That does confirm then that your Image isn’t loading. I have not read yet about custom kernel installs, but it is known that U-Boot isn’t used anymore. Perhaps the Image in “/boot” has become deprecated and now exists in a partition instead of on the file system.
On the other hand, you don’t need to change Image unless one of the integrated features has changed…modules can use the same base kernel when all else remains the same.
Uh Wow! Wasn’t expecting this. Just ran fdisk -l and there are 36 partitions on /dev/mmcblk0p plus two boot partitions. Any idea why the emmc would be partitioned this way?
Disk /dev/mmcblk0: 29.1 GiB, 31272730624 bytes, 61079552 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 00000000-0000-0000-0000-000000000000
Device Start End Sectors Size Type
/dev/mmcblk0p1 40 58720295 58720256 28G Microsoft basic data
/dev/mmcblk0p2 58720296 58721295 1000 500K Microsoft basic data
/dev/mmcblk0p3 58721296 58722295 1000 500K Microsoft basic data
/dev/mmcblk0p4 58722296 58730487 8192 4M Microsoft basic data
/dev/mmcblk0p5 58730488 58738679 8192 4M Microsoft basic data
/dev/mmcblk0p6 58738680 58739703 1024 512K Microsoft basic data
/dev/mmcblk0p7 58739704 58740727 1024 512K Microsoft basic data
/dev/mmcblk0p8 58740728 58741495 768 384K Microsoft basic data
/dev/mmcblk0p9 58741496 58742263 768 384K Microsoft basic data
/dev/mmcblk0p10 58742264 58746359 4096 2M Microsoft basic data
/dev/mmcblk0p11 58746360 58750455 4096 2M Microsoft basic data
/dev/mmcblk0p12 58750456 58750711 256 128K Microsoft basic data
/dev/mmcblk0p13 58750712 58752759 2048 1M Microsoft basic data
/dev/mmcblk0p14 58752760 58754807 2048 1M Microsoft basic data
/dev/mmcblk0p15 58754808 58756855 2048 1M Microsoft basic data
/dev/mmcblk0p16 58756856 58758903 2048 1M Microsoft basic data
/dev/mmcblk0p17 58758904 58759415 512 256K Microsoft basic data
/dev/mmcblk0p18 58759416 58759927 512 256K Microsoft basic data
/dev/mmcblk0p19 58759928 58760951 1024 512K Microsoft basic data
/dev/mmcblk0p20 58760952 58761975 1024 512K Microsoft basic data
/dev/mmcblk0p21 58761976 58770167 8192 4M Microsoft basic data
/dev/mmcblk0p22 58770168 58778359 8192 4M Microsoft basic data
/dev/mmcblk0p23 58778360 58779383 1024 512K Microsoft basic data
/dev/mmcblk0p24 58779384 58780407 1024 512K Microsoft basic data
/dev/mmcblk0p25 58780408 58792695 12288 6M Microsoft basic data
/dev/mmcblk0p26 58792696 58804983 12288 6M Microsoft basic data
/dev/mmcblk0p27 58804984 59067127 262144 128M Microsoft basic data
/dev/mmcblk0p28 59067128 59329271 262144 128M Microsoft basic data
/dev/mmcblk0p29 59329272 59460343 131072 64M Microsoft basic data
/dev/mmcblk0p30 59460344 59591415 131072 64M Microsoft basic data
/dev/mmcblk0p31 59591416 59592439 1024 512K Microsoft basic data
/dev/mmcblk0p32 59592440 59593463 1024 512K Microsoft basic data
/dev/mmcblk0p33 59593464 59595511 2048 1M Microsoft basic data
/dev/mmcblk0p34 59595512 59611895 16384 8M Microsoft basic data
/dev/mmcblk0p35 59611896 59628279 16384 8M Microsoft basic data
/dev/mmcblk0p36 59628280 61079518 1451239 708.6M Microsoft basic data
Disk /dev/mmcblk0boot1: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mmcblk0boot0: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Embedded systems don’t have a BIOS/UEFI to bring the system up to a standardized bootloader interface. Those extra partitions are typically used for something in boot which might not be needed on a desktop PC. Add to this that there seems to be a system being developed for redundancy (I have no details on that), and this would double the number of non-rootfs partitions (notice you have a lot of “partition_name” and “partition_name_b” mirrors).
Even on the desktop PC UEFI firmware can exist at the start of the drive, but you won’t notice it as a named partition. It seems as if some of those extra partitions are simply firmware or device tree which work in a manner similar to the PC’s UEFI boot drive content…but I am just guessing.
I was able to get the modules I compiled working with the stock 4.9.108-tegra Image.
This is what worked for me.
as root from kernel source dir:
zcat /proc/config.gz > .config
// CONFIG_LOCALVERSION=“-tegra” must be set to add modules to stock kernel modules
make menuconfig //load .config, add modules, set local version to “-tegra”, save
nvpmodel -m 3
make -j7 modules_prepare
make -j7 modules
make -j7 modules_install
reboot