After reading the conversation between Wenwoodex and Linuxdev which was posted with the URL Install a kernel on Jetson AGX I came up with a few questions:
The build step “make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT” suggest by Linuxdev doesn’t actually generate the modules to the folder $TEGRA_MODULES_OUT. I guess it should be “make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT modules_install”, right ?
the same issue to the step to make firmware with “make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT”. BTW, “make firmware_install” is no longer supported in the 5.X kernel, right ?
After I set up CONFIG_LOCALVERSION=‘-mytestkernel’ and checkout a 5.10.104 branch and built the v5.10.104 kernel with “make O=$TEGRA_KERNEL_OUT Image”, I could see the kernel generated was named as Image. However, I didn’t see a kernel named Image-5.10.104-mytestkernel, why ? Because the name of the new kernel is remains Image, how the boot is going to figure out which /lib/modules/* to be loaded in ? Or should I rename it from Image to Image5.10.104-mytestkernel manually ?
If I follow the steps that Linuxdev provided in that post, I need to make dtbs, Image, and modules which is actually equivalent to make (without specifying a object). And I need to “make modules_install” to install the modules to a separate folder I specified. After that, I need to replace /boot/Image with the new Image, and move the modules folder to /lib/modules as well. So I wonder what the difference is between “make install/modules_install” for a PC and for Jetson, except that the former created a /boot/vmlinuz ?
So you are correct, firmware_install no longer exists (it does exist in some of the older 4.x kernels, but not in newer 4.x kernels, and not in 5.x kernels).
Some thoughts are: Firmware and device tree are not really part of the kernel. The reason device tree is in the kernel is that drivers require information to find non-plug-n-play devices, and one would not want to write a different driver for every manufacturer device when the only difference is where to find that device (basically, arguments passed to a driver are separate from the code), but there is no need to pass arguments for drivers not used (the Kconfig is a natural way to pick which drivers to pass device tree content to).
In the case of firmware, this is code which the kernel itself never touches, nor does it pass information about it to the driver (the driver itself is designed for a particular device’s API/ABI). Firmware is loaded directly into the hardware peripheral, and changes the device itself without the driver knowing this. Firmware changes the device behavior, similar to having hardware which works with different API versions depending on what is loaded into it…drivers don’t mix and match APIs and are purely for one API. The actual device and its firmware are not part of drivers. I can see why firmware was selected by the kernel in the past as an install convenience since one might pick a driver with a certain API release version to match the hardware’s behavior (to match the peripheral’s firmware-induced API). However, the drivers don’t need the firmware to find the hardware, drivers find this via either plug-n-play layers or via device tree. It would simplify kernel maintenance if there is another mechanism to load firmware and offload that functionality from the kernel source.