In Versal devices, the Arm trusted firmware (ATF) provides access and functions that are similar to other SoCs and also provides access and functions that are unique to Versal devices. For the operating system (OS) to gain access to these underlying functions, the OS must be modified to support the secure monitor calls exported by ATF to the OS. The ATF hands off to the U-Boot, and it is uncommon for issues to occur in the ATF. The ATF is executed from on-chip memory (OCM), unless debug is enabled. If debug is enabled, the ATF source code base grows and is executed from DDR memory instead. If debug is enabled on the ATF and you do not see the expected ATF print statements on the serial port, this might indicate that there is an issue related to the DDR memory. The primary purpose of the U-Boot is to act as a secondary boot loader to load and hand off to the Linux kernel.
A typical use case is to boot from the SD Card. The SD card partition contains the image.ub, and the boot.scr. The image.ub is a flatten image tree (FIT) image created in PetaLinux using the U-Boot utility called mkimage. The FIT image typically contains the kernel image, device tree blob, and if used, the RAM-based file system used by the kernel. The image.ub has image header metadata that the U-Boot reads for information on how to load and execute the internal image. The U-Boot is executed from DDR memory and reads the memory node in the device tree, using this information to self relocate to the upper part of DDR memory.
If the ATF executes but nothing happens, this is likely due to a memory issue, and a memory test is recommended. If the U-Boot starts but later hangs, you must investigate the reason for the hang. For more information on debugging ATF and U-Boot, see the PetaLinux Image Debug Series: Debugging ARM Trusted Firmware and U-Boot in Vitis Article.