What most people think of as a BIOS is an actual micro operating system that self-boots, and then has a job of bringing up power rails and clocks in the right order. Later, it publishes interfaces and transfers control to boot media. On a modern PC motherboard, if you don’t have a dual BIOS (basically a fallback BIOS), then a BIOS failure means scrapping the motherboard (or unsoldering memory from the BIOS, reprogramming it, then soldering it back in). Typically known as “bricking” because it cannot be repaired by software means (I see a lot of people call a non-booting system “bricked”, but this is very very incorrect terminology since the unit can simply be flashed again).
It is correct that everything has a method of bringing up power rails and clocks, training memory and bus speeds, so on. The difference is whether there is a dedicated processor which is isolated such that it is not part of the regular boot chain. Jetson’s do have a PMIC (Power Management IC) and some support for bringing up the system, but it does not exist in its own separate memory. This is flashed along with boot chain during a normal flash. This is also why it is not “standardized”. The UEFI of newer models does standardize to some extent, but you still cannot just wipe the memory used in the o/s and boot chain without also wiping the bring-up of power rails, clocks, memory training, so on…there is not an isolated micro operating system for this. Once the newer models get past the hardware-dependent side of UEFI, the Jetson becomes compatible. You just have to be careful to know that partitions or parts of QSPI need to remain untouched to get to that point.
Long ago I did work on a mainframe hard drive system (it was the worlds highest density storage at the time). The controller had 14 inch Winchester floppy drives, and was the size of a large refrigerator. The actual hard drive was the size of a washer or dryer machine. Depending on the model, the permanent magnets weighed either 42 pounds or 44 pounds and were too heavy to pick up by hand (and you certainly did not want to get between metal and the magnet in the wrong spot). It ran on 440V three-phase, and if a power supply failed, the top cage was intentionally weakened; the explosion would embed metal in the concrete ceiling. Hearing protection was required to be near one long term. Ahh, the bad old days! 😂
With a non-UEFI Jetson you would have a far more difficult job getting another o/s installed. You would have to use an initrd method I think. Jetsons (until very recently) had only kernels which have custom code. The kernel and that code (which is part of the kernel) will have requirements for the operating environment (inheriting a certain machine state), and probably unusual arguments to pass to some of the drivers (the device tree is passed as an argument, but some of the drivers this passes to are not in the stock kernel). An alternative operating system which is capable of using the default kernel stands a much better chance of succeeding since the environment is set up for that, and the device tree and other arguments passed to it are designed for that kernel and device tree.
You are also correct though about simply passing control to a particular address and beginning execution. For the Linux kernel it would be the address of IRQ vector table. Much of the environment being passed by existing state though comes from software in very early boot stages which is not public information. If JTAG or DSTREAM (which seems particular to ARM) could be used it would be a much easier job, but you won’t find support for that.
I don’t know of comprehensive docs. The earliest parts, the 3P server and TBoot, are not generally available, but if you put in the specific model at this URL, then you might find the bring-up or adaptation guides provide some help (this tends to be more for custom carrier board development, or going from one Jetson generation to another):
https://developer.nvidia.com/embedded/downloads
