If you look at the “make menuconfig” check box for features you’ll notice some of them are ‘', some ‘M’, and some empty. Empty boxes are not set, both ‘M’ and '’ are enabled. However, ‘M’ is enabled in the form of a module, whereas ‘*’ is enabled by integration directly into the kernel.
If a feature is enabled as a module, a module is built and modules can be loaded or unloaded on an existing kernel at run time. An integrated feature does not build a module, and modules cannot be loaded or unloaded for that feature. The kernel itself must be updated (which means there is a strong chance of invalidating modules which depended on certain features and traits of the kernel they were compiled against…think of it as a mix of ABI version and features).
The usual method of making sure your modules and kernel were designed to work together is the module loading scheme which you already know about (requiring the CONFIG_LOCALVERSION you have set up). Should you upgrade the kernel itself (not the source code, but the non-module configuration) expect that it is best to start with a new CONFIG_LOCALVERSION. If that new configuration extends an existing configuration you’ll probably just want a slight change to the existing CONFIG_LOCALVERRSION. For example, if you’ve been using “-gdacac96”, then you might alter this to something like “-gdacac96_1” (or something informative like “-gdacac96_1_mcast”.
In the case where you must install a kernel with a new CONFIG_LOCALVERSION (using “-gdacac96_1”) the make modules_install would put modules in “/lib/modules/3.10.40-gdacac96_1”. It’s up to you to copy the new kernel (not modules) in “/boot” and update “/boot/extlinux/extlinux.conf” (I’m assuming L4T R21.4…earlier R19.x L4T used fastboot or “/boot/extlinux.conf”).
The name of the kernel file will depend upon format, e.g., the “zImage” is popular and is compressed, the “Image” file is the same thing with no compression. Other formats do exist as well, e.g., currently u-boot uses zImage, but at one time had its own format. For a Jetson TK1, the zImage is produced in kernel source at 32-bit ARMv7 architecture-dependent location “arch/arm/boot/”. You do not normally have to worry about updating firmware for minor version changes and can ignore that part unless you change a major version or the hardware itself. I’d advise incrementing the file name in such a way that the non-module change is obvious, e.g., “-mcast” instead of including the “-gdacac96”, and then placing a zImage in “/boot” with a name like “zImage-mcast”.
Notice in the “/boot/extlinux/extlinux.conf” file that there is a prologue followed by a section for an individual kernel boot. You can duplicate one of those and alter file names to create a second bootable entry naming the new kernel. Serial console can then be used at boot time to select the alternate entry; once things work as you want, you can make the new entry default. When copying an entry note that the “APPEND” key/value pair is one very long line and must remain that way…don’t let line wrap fool you. Here’s a contrived example extlinux.conf:
TIMEOUT 30
DEFAULT primary
MENU TITLE Jetson-TK1 eMMC boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/zImage
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt
LABEL <b>mcast</b>
MENU LABEL <b>multicast</b>
LINUX /boot/<b>zImage-mcast</b>
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt
Note that the original module directory would still exist and be bootable alongside the new module directory via serial console. Changing “DEFAULT” from “primary” to “mcast” would make the “mcast” label the default entry (best done after testing). If very quickly after boot starts hit a key on the keyboard of serial console, you’ll get a prompt for the u-boot environment. You actually need to wait a moment instead and hit a key when it gets to kernel selection menu…then you can select something like “2” for the second entry. If you hit a key too early and end up on u-boot environment command line just type “boot” to continue and hit a keyboard key again after that.
Within the old module directory (“/lib/modules/3.10.40-gdacac96”) you will see a subdirectory “extra”. A normal “make modules_install” has no knowledge of this directory, it is for nVidia-specific files. You would want to recursively copy this to the new module directory, e.g.:
cd /lib/modules/3.10.40-mcast
sudo cp -adR ../3.10.40-gdacac96/extra .
Incidentally, the “extra” subdirectory is a big part of why back-porting to 3.10.40 works better than going mainline. Those files are not loadable in a 4.x.x kernel (additionally, the video driver is bound to the Xorg ABI version…this version changes frequently).