I will add some trivia regarding kernels and modules and initrd. I did not follow any original post, but it seems like this applies. Here are some URLs you might find regarding kernel configuration and installation (not using flash); beware that some are from older 4.x kernels, but the concepts and commands are the same:
- https://forums.developer.nvidia.com/t/orin-nano-wont-detect-arduino-dev-ttyusb-or-dev-ttyacm/284955/16
- https://forums.developer.nvidia.com/t/recompile-jetson-nano-developer-kit-kernel/276277/12
- https://forums.developer.nvidia.com/t/topic/262647/12
- https://forums.developer.nvidia.com/t/how-to-use-hiddev-device-on-jetson-nano-4gb/254048/8
- https://forums.developer.nvidia.com/t/topic/238718/25
- https://forums.developer.nvidia.com/t/topic/238718/25
- https://forums.developer.nvidia.com/t/problem-smb-jetson-nano/193640/11
Regarding the initrd, you can think of this as an “adapter” between boot stages and handing over control to the Linux kernel. If the bootloader understands the filesystem type being mounted, and if the “integrated” kernel Image file (or one of the modules which the kernel has access to) understands the filesystem being mounted, then one does not necessarily need an initrd. Restated, if both kernel and bootloader understand everything needed to pass to the kernel and for the kernel to run, then it is a trivial hand-off. That’s somewhat simplified, because it implies also that the hardware drivers are present. For example, if the device is a USB external device, and either the bootloader or the Linux kernel do not have the correct USB driver, then this too would require an initrd. Anything needed for the kernel to take ownership of execution, but missing, can be added into the initrd. For the case of kernel features, those would be in the form of modules.
Sometimes an initrd is used even if technically it is not needed. This might lead to a simplified installation. If that initrd has a module which needs to load into the kernel, and if you’ve changed the kernel Image such that this module cannot load, then the boot will fail. The URLs above show a lot of ways modules might fail to load.
The l4t_update_initrd.sh script is just a wrapper to create an initrd. There are multiple ways to view and edit an initrd. The real trick is that the correct modules for that Image file currently being used must be compatible, and they must be in the correct location of the initrd.
Note that an initrd is just a filesystem type. It is very simplified compared to ext4. The initrd filesystem is just a tree structure of files with simplified permissions, and it lives entirely in RAM. The initrd contains a full operating system, other than the Image (which is outside of the initrd), but is cut down to be as tiny as possible. Once the kernel loads the modules it needs to continue boot, a pivot root operation occurs. What this does is to transplant the “/” directory of the RAM disk to instead point at the true storage device (such as eMMC or NVMe). The RAM disk is discarded. Because the kernel Image itself is not on the initrd, and only modules are on this, there is a continuity of service where the Image itself does not change. However, now that one is on a new root filesystem, the kernel can continue loading modules and operating from the full filesystem.