Just some added random comments (these are not in any particular order)…
When flashing some software is for the NVIDIA module, and other software is needed for specific carrier boards. Go to the “Linux_for_Tegra/” directory and examine the output of this command:
ls -l jetson*.conf
You will find that those are the flash targets if you leave out the “.conf”, and that the “jetson-*” targets are aliases. One half of that non-alias file name (the ones which are not “human friendly designations”) is for the model of module. The other half is for the model of carrier board. There might also be extra numbers (such as “-0000”) which are for revisions.
It is common for third party carrier board vendors to use a different device tree. The method usually used with this is to also provide a different .conf file naming some standard model of module, but an edited and customized content for the carrier board. If a carrier board is an exact layout match to the NVIDIA reference design, then there is no need for a custom device tree and the existing flash targets would be valid.
L4T is what normally gets flashed, while JetPack/SDK Manager is flash software. The default is that L4T is Ubuntu that has had the NVIDIA drivers added on top of it. Before flash, while installing the flash software, directory “Linux_for_Tegra/rootfs/” starts out as a purely Ubuntu o/s unpacked to there. Then the NVIDIA content is added to it, and this is when it becomes “L4T”. This needs to occur only once, and unless you are doing everything purely on command line, then you don’t need to do that yourself.
To see which L4T release you are using from the host PC go to the “Linux_for_Tegra/rootfs/etc/” directory. Then run the command “head -n 1 nv_tegra_release”. To see which L4T release is running on the Jetson itself, use “head -n 1 /etc/nv_tegra_release”.
L4T R36.x is fully UEFI now in boot content. L4T R35.x started UEFI, but I don’t think it was complete there. L4T R35.x is the earliest release an Orin can use.
No Jetson has an actual BIOS. What they have is software which performs the equivalent of what a BIOS would do. For the Orin series, especially for L4T R36.x+, it becomes possible to customize some things in boot that could not be customized in earlier releases (I have not personally tried to customize that). UEFI creates a hardware abstraction, and once that uniform interface is visible, then even programs like GRUB can work. previous releases could not use GRUB. There is still custom boot software in place, but that software is irrelevant once UEFI reaches the point of its standardized interface part way into boot.
In a normal flash both boot content and the operating system (L4T) are installed. The initrd might or might not be there, it serves as a kind of “adapter” between boot content and Linux (boot has to load the Linux environment, but if boot does not understand the filesystem, then we have a bit of a dilemma; the initrd is a simplified filesystem all bootloaders and Linux understand). If boot were to fail at the moment of the Linux kernel loading, then there might be an issue either with the initrd or lack of initrd.
If we were performing just an ordinary flash of everything, then mostly the “Linux_for_Tegra/rootfs/” content is used verbatim to create the operating system partition. Remember those jetson-*.conf flash targets? Based on the board specs and module specs you will find a kernel and device tree and boot settings copied into the “rootfs/” before creating the image. The *.conf files are human readable, and they include other files. You can go through those and see which XML or other files are used during flash. That file is the Linux_for_Tegra/bootloader/system.img.raw file, which is in turn reduced in size to become the bootloader/system.img.
Either system.img or system.img.raw can be used to flash, but the raw file is the exact size of the partition and takes longer to flash. As the content of the partition approaches full the size of the system.img approaches the size of the system.img.raw (the “sparse” file, the system.img, is the filesystem excluding the empty space).
If you were to clone a Jetson, and have a binary clone of the rootfs partition, you could flash just the rootfs. In that case the “Linux_for_Tegra/rootfs/” would be ignored, content would not be copied into it, and the o/s partition would be an exact verbatim match to the cloned image.
There are all kinds of variations on this which I couldn’t tell you about. Mass flash is one I have not used. There are also a/b backup partition schemes. This will give you a place to start though if you have issues with your mass flash.
More about device trees: Sometimes these are used in boot stages, and sometimes only in the o/s. People don’t realize this, but boot stage software is in fact its own bare metal operating system. However, boot content is dedicated to overwriting itself with a new o/s. You would want a full verbose boot log to find where any given device tree is used. Those trees also get used once the Linux kernel is loaded.
You can think of a device tree as an argument to various hardware. Drivers can read this for a number of reasons (especially to find non-plug-n-play devices known only by their physical address). If you look at a device tree for a module, then it might be assigning general purpose pins to some particular use. That’s the board layout side of it. A wrong device tree often leaves part of the system functioning, and other parts remain dead to the world.
Device tree fragments for content that does not exist is ignored. If your Linux kernel does not have a driver for a “gizmo” device, then any device tree designed to pass arguments to the “gizmo” driver would be ignored. This is similar to the kernel command line.
Sometimes device tree content ends up in “/boot” (on the host PC side, “Linux_for_Tegra/rootfs/boot/”), and sometimes it ends up in other locations (such as eMMC partitions or QSPI memory on the module). If you were look at flash logs, then you could find that information. I typically log a manual flash once and save a copy of that log for future use.
If you want to debug, then always remove the “quiet” from “/boot/extlinux/extlinux.conf” and get a full serial console boot log. You might also have to install a debug version of the boot software to get boot stage content. It is important to keep a copy of this around even if your shipping units have the “quiet” enabled.