A common secondary piece is ACPI, which isn’t strictly mandatory, but when you provide both UEFI and ACPI then you can skip the whole dtb mess. Sadly ACPI isn’t the simplest of approaches, as it’s encoded in a way that requires executing bytecode in a stack machine. There are real and valid security concerns that come with this, but there are also big advantages- the abstraction generalizes over a lot of what would otherwise be specialization that has to be carried around in the bootloader and OS.
Uboot implements a subset of the uefi spec, but typically is used where there is no ACPI type configuration, with the gap filled by a combination of dtbs and vendor forks or patches (often before upstreaming, which sometimes never happens).
Depending on how deep your relationship is with all of this, you may live with uboot as a plain binary blob from a board vendor, in which case whatever version they formed and options they chose may bring various constraints or challenges doing anything novel like booting an alternative kernel or distro.
Typically a more complete uefi and ACPI system will be able to get much further in the boot process with far less hardware specialization, a lot of operating systems can boot very far with this combo even if they’ve never seen the specific hardware topology before.
Uboot upstream has a lot of implementations for a lot of hardware targets. There isn’t really so much of a central place for uefi implementations
