This probably isn’t everything you want to know, but will likely be part of it. The shorter answer is “no”, U-Boot is not directly supported or Orin. It would be useful though for someone actually working with Yocto on Orin to comment, I don’t have that specific experience.
If your Yocto supports a mainline kernel, and if you are using L4T R36.x+, then it might be easier to just adapt the existing NVIDIA boot chain due to the abstraction UEFI provides part way through boot. Between that and any initrd support a lot becomes possible if you want to do the work. For Orin you pretty much must have the earlier phases of UEFI anyway, it is custom and not something you’d want to modify even if the information were all public. Even if you go to the earlier L4T R35.x part of this is migrated to UEFI and is not U-Boot, but maybe with a lot of effort U-Boot could have some features merged back in (I have no idea what your Yocto requires).
To start with, keep in mind that Jetsons do not have a hardware BIOS. A real BIOS is its own micro operating system with minimal drivers for all of the hardware used in boot. All of this is done only in software for a Jetson. On eMMC models this exists in the non-rootfs partitions; part of that content is the bootloader, but a large part of it is the equivalent of a BIOS leading up to the bootloader.
"In the early days"™ things were purely U-Boot. Think 32-bit hardware of the Jetson TK-1 and earlier (non-Jetson embedded systems, e.g., the Tegra 3 or 4). The TK-1 was the last of the 32-bit. As soon as the TX-1 made it to 64-bit U-Boot had problems that had not yet been solved; no 64-bit bootloader existed, no ARMv8-a software existed (arm64/aarch64), and all software was new. Still, there is a compatibility mode for arm64 which allows it to run in the older ARM EABI. This was when many parts of the ARMv7-a/armhf CPU were optional, e.g., some did not have hardware floating point. All of the standardization revolved around the EABI (E version of Application Binary Interface), whereas 64-bit compatibility made all of those options (e.g., NEON) a requirement. U-Boot was used in 32-bit compatibility mode. U-Boot could not use 64-bit features.
Many years ago, when the TX1 came out, the bootloader was entirely custom and U-Boot itself began being phased out. Various features of U-Boot were migrated into the NVIDIA boot chain. The NVIDIA boot chain began to be U-Boot “compatible”, and the actual U-Boot was phased out in steps. What people called U-Boot after that was not really U-Boot, it was the NVIDIA boot chain customized to become compatible with U-Boot such that the software using it did not know the difference.
FYI, for terms, L4T is what actually gets flashed and is just Ubuntu with NVIDIA content on top of it. JetPack/SDK Manager is just a GUI front end to the flash software. Due to the nature of the software-BIOS without a true hardware-BIOS this flashes the BIOS equivalent every time the Jetson is flashed. By the time L4T R32.x the entire U-Boot chain had been replaced with a subset of the standard within the NVIDIA software and the real U-Boot was no longer used. You could pretend it was U-Boot since it was more or less standards compliant (it is a subset of U-Boot though, not a full U-Boot). There is no actual U-Boot even in R32.x, there is only the NVIDIA equivalent.
This custom boot chain implied NVIDIA could not use a mainline kernel or other bootloaders. There was no BIOS capable of using other bootloaders. Starting with Xavier in R35.x there is a large migration towards UEFI which began, but it wasn’t until R36.x that full UEFI compliance exists. This has a hardware dependent starting layer, and still does not have a real BIOS, but the UEFI model itself abstracts the hardware in a somewhat object-oriented way. Once the hardware abstraction point is reached, then any bootloader which UEFI can load becomes possible. This results in L4T R36.x being able to use the mainline kernel and other bootloaders, but you’d want a 64-bit bootloader. I don’t know if U-Boot ever built a 64-bit release for arm64/aarch64 (I have not kept up with newer U-Boot, maybe they have this now). However, the UEFI abstraction is itself not truly a bootloader, it is BIOS (in software). If you were to try to use U-Boot, then it would be the case of UEFI offloading to U-Boot.
UEFI does have a lot of advantages over old style BIOS, and of course all embedded systems which I know of which have some sort of boot standard tend to revolve around GPT partition schemes. Prior to UEFI there was the older and much less flexible BIOS scheme. fdisk was for old style BIOS, and gdisk is for newer GPT scheme (it used to be that fdisk did not correctly handle GPT partitions, but it eventually had some adaptation). Everything you do with a Jetson should stick to GPT, and so long as U-Boot can work with the 64-bit environment and deal with GPT partition schemes, it would perhaps be possible to do what you want to do. If U-Boot still runs in 32-bit mode, then this could probably also work if and only if the UEFI is in 32-bit compatibility mode (I don’t know if this is the case or not for L4T R36.x).