SPRADD1A August   2023  – September 2024 AM620-Q1 , AM623 , AM625 , AM625-Q1 , AM625SIP , AM62A1-Q1 , AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1 , AM62P , AM62P-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. Introduction
  5. Installing the SDK
  6. Configuring the SDK for a Custom Board
  7. Starting U-Boot Board Port
    1. 4.1 Introduction to Devicetrees
    2. 4.2 Capabilities of the Minimal Configuration
    3. 4.3 Preparing Custom Board Files
    4. 4.4 Initial Devicetree Modifications
    5. 4.5 Building U-Boot Binaries
    6. 4.6 U-Boot Deployment Instructions
  8. Expanding the Custom Board Devicetree
    1. 5.1 Devicetree Configuration
    2. 5.2 Describing Peripherals in Nodes
    3. 5.3 Revising the Devicetree Configuration
  9. Booting the Linux Kernel
    1. 6.1 Kernel Boot Overview
    2. 6.2 Kernel Deployment Instructions
  10. Tools and Debugging
    1. 7.1 Kernel Debug Traces
    2. 7.2 OpenOCD Debugging
  11. Future Work
  12. Summary
  13. 10References
  14.   Revision History

Building U-Boot Binaries

This section explains how to create bootloader binaries using the custom board configuration and the AM62x Processor SDK.

For AM62x devices, three images, which are all created by the build process, are required to load U-Boot:

  • tiboot3.bin
  • tispl.bin
  • u-boot.img

When the board is powered on, ROM code checks the bootmode pins and initializes the selected boot media required to load tiboot3.bin and execute it on the 32-bit R5 core. This image contains a secondary program loader (SPL) called the wakeup SPL. This SPL initializes DDR and basic board components that are used to load tispl.bin. This tispl.bin image contains the 64-bit main SPL running on an A53 core as well as firmware that is required to boot Linux. The main SPL initializes peripherals that are configured in k3-am625-<boardname>.dts, which are used to load the next artifacts in the bootflow. Finally, packaged in u-boot.img, U-Boot proper loads and additional peripherals may be initialized, preparing to boot Linux kernel components.

Since the boot process involves both 32-bit and 64-bit cores, a 32-bit and 64-bit cross compiler are required. The AM62x Processor SDK contains these cross-compilers, but the toolchain paths need to be set for each.

Set the following generic environment variables:

Table 4-1 Generic Environment Variables
Env Variable Descriptions
CROSS_COMPILE_32 Cross compiler path for Armv7 (Arm32-bit), SDK provides arm-oe-eabi-
CROSS_COMPILE_64 Cross compiler path for Armv8 (Arm 64bit),
SDK provides aarch64-oe-linux-
CC_64 Cross-compiler executable for Armv8 (Arm64bit) with default library and header paths specified, SDK provides aarch64-oe-linux-gcc
LNX_FW_PATH Path to TI Linux firmware directory provided by SDK
TFA_PATH Path to prebuilt Arm Trusted Firmware provided by SDK (bl31.bin)
OPTEE_PATH Path to prebuilt OPTEE provided by SDK (bl32.bin)

To set the compiler toolchain paths, see the AM62x Processor SDK Guide. The following is an example of how to set the firmware paths using the prebuilt binaries provided by the SDK.

$ export LNX_FW_PATH=TI_SDK/board-support/prebuilt-images/am62xx-evm/
$ export TFA_PATH=TI_SDK/board-support/prebuilt-images/am62xx-evm/bl31.bin
$ export OPTEE_PATH=TI_SDK/board-support/prebuilt-images/am62xx-evm/bl32.bin 

Set the following board-specific environment variables:

Table 4-2 Board-Specific Environment Variables
Env Variable Descriptions
UBOOT_CFG_CORTEXR Default configuration file for Cortex-R
UBOOT_CFG_CORTEXA Default configuration file for Cortex-A

Set the default configuration variable to apply the configuration fragments created earlier on top of the existing EVM default configuration. An example of setting these environment variables is below.

$ export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig am62x_<boardname>_r5.config"
$ export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig am62x_<boardname>_a53.config" 

Since both 32-bit and 64-bit binaries are built, they need to be output into separate folders for each architecture. Create this output directory on the host machine. These instructions refer to the output directory path as OUTPUT_DIR. The 32-bit and 64-bit binaries are built into subdirectories of OUTPUT_DIR. In the following instructions, these subdirectories are named r5 and a53 for the 32-bit and 64-bit builds, respectively. All build commands are run from the root of the SDK U-Boot repository.

Building tiboot3.bin

$ make clean O=OUTPUT_DIR/r5
$ make ARCH=arm CROSS_COMPILE="$CROSS_COMPILE_32" $UBOOT_CFG_CORTEXR O=OUTPUT_DIR/r5
$ make ARCH=arm CROSS_COMPILE="$CROSS_COMPILE_32" O=OUTPUT_DIR/r5 BINMAN_INDIRS=$LNX_FW_PATH

Building tispl.bin and u-boot.img

$ make clean O=OUTPUT_DIR/a53
$ make ARCH=arm CROSS_COMPILE="$CROSS_COMPILE_64" $UBOOT_CFG_CORTEXA O=OUTPUT_DIR/a53
$ make ARCH=arm CROSS_COMPILE="$CROSS_COMPILE_64" CC="$CC_64" O=OUTPUT_DIR/a53 BL31=$TFA_PATH TEE=$OPTEE_PATH BINMAN_INDIRS=$LINUX_FW_PATH

Use the following binaries depending on the security level of the device on the custom board.

Table 4-3 Generated Binaries Based on Device Security Level
Security Generated Binaries
GP tiboot3-am62x-gp-evm.bin
tispl.bin_unsigned
u-boot.img_unsigned
HS-FS tiboot3-am62x-hs-fs-evm.bin
tispl.bin
u-boot.img
HS-SE tiboot3-am62x-hs-evm.bin
tispl.bin
u-boot.img
Note: The device security level of a new board is likely to be HS-FS.

The three generated binaries are found in the root directory of the r5 and a53 subdirectories of OUTPUT_DIR. These binaries must be renamed to exactly tiboot3.bin, tispl.bin and u-boot.img. This is done with the following commands.

// in the r5 subdirectory of OUTPUT_DIR
$ mv tiboot3-am62x-{gp/hs-fs/hs}.bin tiboot3.bin
// in the a53 subdirectory of OUTPUT_DIR
$ mv tispl.bin{_unsigned} tispl.bin
$ mv u-boot.img{_unsigned} u-boot.img