Yes. I tend to say Xavier for the full Xavier, and NX for the NX form factor. AGX was the first Xavier, and is a bit more powerful than the NX.
Any time you want to boot the boot software will eventually get to a step where it follows rules to find a boot device. In many Jetsons the CBoot code transfers execution to U-Boot, and the functions of U-Boot (such as environment variables and macro expansion of those variables) are what determine if a boot device has been found. However, the Xavier and NX do not have U-Boot. Instead, some of the U-Boot behavior was ported from U-Boot into CBoot (not a direct port, but to the user it looks the same).
CBoot, when it performs with U-Boot functionality, is usually a subset of the full U-Boot capabilities. If it works in U-Boot, then it is worth testing if it works in the CBoot version, but it isn’t a guarantee. Those parts where one might set up a boot order by changing the environment variables in the bootloader console most likely will work identically regardless of it being CBoot or U-Boot, but there is a catch: Suppose (this is just a contrived example for illustration) U-Boot is using a USB driver for an external disk to find the boot partition, and suppose CBoot does not have a USB driver for that external disk…then the environment would make the same attempt in both cases, but the CBoot would have failed…not for lack of trying, but for lack of support in infrastructure drivers.
Historically, CBoot has always been there, and the only thing which changed for the CBoot-only-but-not-U-Boot models is that it was that CBoot used to always transfer boot to U-Boot. Cutting out U-Boot meant that some of that end user friendliness of U-Boot needed porting to CBoot. You might wonder why this complication was added. I think the answer centers on A/B boot redundancy and secure boot with a fuse. It would be far easier to put some U-Boot console environment into CBoot than it would be for U-Boot to understand the workings of a Jetson with secure boot fuses or A/B partition redundancies.
For the boot code to support A/B redundancy, or secure boot with fuses, the hardware to deal with it must be present. For eMMC models this requirement is met. However, the less expensive SD card models do not have all of the hardware. In part I don’t think this would be possible because secure boot mandates being able to stop access to some of the persistent memory, and there is no way you could stop access to the SD card. The code for the SD card boot, as a result, is very different from the code for eMMC with support of both redundancy and secure boot.
I can’t say for certain, but so far as picking between two different devices to boot to, I’m thinking one could change the boot sequence by changing the environment variables you see in the bootloader console over the serial console. But you’d have to try it to know for sure, or someone from NVIDIA would need to say that particular case works for a given L4T/JetPack/SDKM release and the particular Jetson model.