To boot the custom board using the new U-Boot configuration, transfer the three generated binaries to the target hardware via UART. This method utilizes a common, accessible peripheral to establish a U-Boot command prompt. Note that your custom board must support a UART bootmode configuration to proceed with this example. While TI EVMs utilize onboard switches to toggle between various boot methods, production boards can accomplish this through jumpers, buttons, or similar hardware mechanisms. The following steps assumes the board is already configured for UART boot.

The first step is to install a serial communication utility, such as Minicom, on the host PC and configure it to match the board's serial settings. The AM62x Quick Start Guide contains detailed instructions for setting up this serial connection. To verify that the terminal setup and hardware connections are correctly established, check for the continuous stream of 'CCC' characters output by the ROM code while it polls for a boot image. An example of this terminal output is shown below.

CCCCCCCC

If no terminal output appears, multiple hardware or configuration variables can be causing the failure. It is recommended to validate your host environment using a known-good TI EVM to isolate whether the issue resides within the host setup or the custom hardware. These communication issues must be completely resolved before proceeding with the board bring-up process.

• Hardware and Board Layout: Verify all power supply rails match the required tolerances, confirm the physical bootmode selection pins or switches are securely set for UART boot, and inspect the PCB trace continuity along the UART transmit (TX) and receive (RX) lines.
• Terminal Configuration: Verify the host serial communication utility is configured for the correct baud rate (typically 115200), 8 data bits, no parity, and 1 stop bit (8N1), with both hardware and software flow control completely disabled.

Once the serial connection is established, transmit the boot binaries over UART in the following strict order: tiboot3.bin, tispl.bin, and then u-boot.img. If you are using minicom or a similar terminal utility, these files can be sent using the program's integrated file transfer menu. Alternatively, you can transmit them directly from the command line using the lrzsz package utilities (such as sx and sb). For a comprehensive guide on using UART to load U-Boot binaries, refer to the AM62x Processor SDK: UART Boot documentation. As detailed in that guide, the XMODEM protocol must be used to transfer tiboot3.bin, while the YMODEM protocol is required to transfer both tispl.bin and u-boot.img.

The serial console outputs a initialization log block after each binary transfer completes. If tiboot3.bin and tispl.bin are successfully transferred, their respective final log signatures will match the example shown below.

Trying to boot from UART
CCCCC

After transferring u-boot.img, U-Boot provides a brief countdown to abort the autoboot process. Press any key during this window to stop the automatic boot sequence and enter the U-Boot interactive command prompt. An example boot log demonstrating a successful drop into the U-Boot prompt is shown below.

U-Boot 2024.04-00006-g49c04dedb6d-dirty (Jul 19 2024 - 14:01:17 -0500)

SoC:   AM62X SR1.0 HS-FS
Model: Texas Instruments AM625 MINIMAL
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -19
DRAM:  2 GiB
Core:  37 devices, 21 uclasses, devicetree: separate
MMC:   mmc@fa00000: 0
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Failed to probe am65_cpsw_nuss driver
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -19
Net:   No ethernet found.
Hit any key to stop autoboot:  0
=>

Successfully reaching the U-Boot command prompt confirms that the custom board's UART device tree configuration is functional. It also validates that the initial, stable DDR configuration are sufficient to execute U-Boot proper. The next milestone is to load and boot the Linux kernel to reach a login shell. This process requires a Linux kernel image, a compiled device tree Binary (DTB), and an initramfs. Because this volume of data cannot be efficiently transmitted over a slow UART connection, an alternative peripheral interface must be utilized to load these boot artifacts.