/boot/initrd” (at least on a Jetson) is just a symbolic link to the real file. For example, in this “
ls -l /boot/initrd*”, the “
initrd.img” is not a real file:
/boot# ls -l initrd*
-rw-r--r-- 1 root root 5488163 Jul 1 03:52 initrd
lrwxrwxrwx 1 root root 24 Jan 28 2018 initrd.img -> initrd.img-4.9.140-tegra
-rw-r--r-- 1 root root 15225477 Jul 27 12:42 initrd.img-4.9.140-tegra
Depending on the boot software, it wouldn’t be unusual that the one being used is from the “
INITRD” key/value pair of “
Quite often Linux (or any *NIX) will have several versions of files available. Perhaps a library, perhaps an initrd…it doesn’t really matter. In case an application looks for only the most generic file name, then typically this will be a symbolic link pointing to the real file which has a specific release verison in its name. Then, if the more specific version is updated, then the symbolic link can point at the new version without the end application needing to make any such distinction.
Not all of the Jetsons use
extlinux.conf in the same way. Earlier releases used this all the time since U-Boot was always used. There is an earlier boot stage though, CBoot, and in Xavier (and I think NX) U-Boot is not used. For a while L4T releases on those platforms no longer used extlinux.conf, but U-Boot functionality has been slowly added back in via CBoot (U-Boot is still not used for these, but the behavior now mimics U-Boot for the extlinux.conf file), and so more recent L4T releases on these relevant platforms use extlinux.conf (and thus the INITRD key/value pair) to determine which initrd image to use.
In the end, if the initrd comes from “
/boot”, the actual file is just a tar and cpio archive. This is rather simple and has a tree of files, but there is no traditional filesystem, and thus no need for special drivers. The initrd itself is not custom, but the process of finding and using the initrd might be different on a Jetson. More than one initrd can be used if you create extra boot entries in extlinux.conf, and then use serial console to pick the entry at boot.
Although the initrd is itself 100% generic in its mechanism, and not different from that of a desktop PC, the boot environment and architecture is different, and there would be some reflection of this in the initrd content. A PC has a CMOS BIOS/UEFI, and a Jetson does not…most of those other non-rootfs partitions of a Jetson are the equivalent of the CMOS setting things up for the bootloader. Once those services load the Linux kernel and initrd (if used), then the content of the initrd supports arm64, and any custom “BIOS” style functions do not exist. The mechanism of the initrd itself is entirely stock, the content surrounding initrd are mandated by the boot environment.