AM65x Platforms

Introduction:

The AM65x family of SoCs is the first device family from K3 Multicore SoC architecture, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products.

The device is built over three domains, each containing specific processing cores, voltage domains and peripherals:

Wake-up (WKUP) domain:
- Device Management and Security Controller (DMSC)
Microcontroller (MCU) domain:
- Dual Core ARM Cortex-R5F processor
MAIN domain:
- Quad core 64-bit ARM Cortex-A53

More info can be found in TRM: https://www.ti.com/lit/pdf/spruid7

Platform information:

https://www.ti.com/tool/TMDX654GPEVM

Boot Flow:

On AM65x family devices, ROM supports boot only via MCU(R5). This means that bootloader has to run on R5 core. In order to meet this constraint, and for the following reasons the boot flow is designed as mentioned:

1. Need to move away from R5 asap, so that we want to start any firmware on the R5 cores for example autosar can be loaded to receive CAN response and other safety operations to be started. This operation is very time critical and is applicable for all automotive use cases.

2. U-Boot on A53 should start other remotecores for various applications. This should happen before running Linux.

3. In production boot flow, we might not like to use full U-Boot, instead use Falcon boot flow to reduce boot time.

Here DMSC acts as master and provides all the critical services. R5/A53 requests DMSC to get these services done as shown in the above diagram.

Sources:

Das U-Boot

source: https://source.denx.de/u-boot/u-boot.git

branch: master
Trusted Firmware-A (TF-A)

source: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/

branch: master
Open Portable Trusted Execution Environment (OP-TEE)

source: https://github.com/OP-TEE/optee_os.git

branch: master
TI Firmware (TIFS, DM, SYSFW)

source: https://git.ti.com/git/processor-firmware/ti-linux-firmware.git

branch: ti-linux-firmware

Note

The TI Firmware required for functionality of the system can be one of the following combination (see platform specific boot diagram for further information as to which component runs on which processor):

TIFS - TI Foundational Security Firmware - Consists of purely firmware meant to run on the security enclave.

DM - Device Management firmware also called TI System Control Interface server (TISCI Server) - This component purely plays the role of managing device resources such as power, clock, interrupts, dma etc. This firmware runs on a dedicated or multi-use microcontroller outside the security enclave.

OR

SYSFW - System firmware - consists of both TIFS and DM both running on the security enclave.

Build procedure:

Setup the environment variables:

Generic environment variables
S/w Component	Env Variable	Description
All Software	CC32	Cross compiler for ARMv7 (ARM 32bit), typically arm-linux-gnueabihf-
All Software	CC64	Cross compiler for ARMv8 (ARM 64bit), typically aarch64-linux-gnu-
All Software	LNX_FW_PATH	Path to TI Linux firmware repository
All Software	TFA_PATH	Path to source of Trusted Firmware-A
All Software	OPTEE_PATH	Path to source of OP-TEE

Board specific environment variables
S/w Component	Env Variable	Description
U-Boot	UBOOT_CFG_CORTEXR	Defconfig for Cortex-R (Boot processor).
U-Boot	UBOOT_CFG_CORTEXA	Defconfig for Cortex-A (MPU processor).
Trusted Firmware-A	TFA_BOARD	Platform name used for building TF-A for Cortex-A Processor.
Trusted Firmware-A	TFA_EXTRA_ARGS	Any extra arguments used for building TF-A.
OP-TEE	OPTEE_PLATFORM	Platform name used for building OP-TEE for Cortex-A Processor.
OP-TEE	OPTEE_EXTRA_ARGS	Any extra arguments used for building OP-TEE.

Set the variables corresponding to this platform:

export CC32=arm-linux-gnueabihf-
export CC64=aarch64-linux-gnu-
export LNX_FW_PATH=path/to/ti-linux-firmware
export TFA_PATH=path/to/trusted-firmware-a
export OPTEE_PATH=path/to/optee_os

export UBOOT_CFG_CORTEXR=am65x_evm_r5_defconfig
export UBOOT_CFG_CORTEXA=am65x_evm_a53_defconfig
export TFA_BOARD=generic
# we dont use any extra TFA parameters
unset TFA_EXTRA_ARGS
export OPTEE_PLATFORM=k3-am65x
# we dont use any extra OP-TEE parameters
unset OPTEE_EXTRA_ARGS

Trusted Firmware-A:

# inside trusted-firmware-a source
make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 SPD=opteed $TFA_EXTRA_ARGS \
     TARGET_BOARD=$TFA_BOARD

OP-TEE:

# inside optee_os source
make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y $OPTEE_EXTRA_ARGS \
      PLATFORM=$OPTEE_PLATFORM

U-Boot:

3.1 R5:

# inside u-boot source
make $UBOOT_CFG_CORTEXR
make CROSS_COMPILE=$CC32 BINMAN_INDIRS=$LNX_FW_PATH

3.2 A53:

# inside u-boot source
make $UBOOT_CFG_CORTEXA
make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \
       BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \
       TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin

Note

It is also possible to pick up a custom DM binary by adding TI_DM argument pointing to the file. If not provided, it defaults to picking up the DM binary from BINMAN_INDIRS. This is only applicable to devices that utilize split firmware.

Target Images

In order to boot we need tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img. Each SoC variant (GP and HS) requires a different source for these files.

GP
- tiboot3-am65x_sr2-gp-evm.bin, sysfw-am65x_sr2-gp-evm.itb from step 3.1
- tispl.bin_unsigned, u-boot.img_unsigned from step 3.2
HS
- tiboot3-am65x_sr2-hs-evm.bin, sysfw-am65x_sr2-hs-evm.itb from step 3.1
- tispl.bin, u-boot.img from step 3.2

Image formats:

tiboot3.bin

tispl.bin

sysfw.itb

eMMC:

ROM supports booting from eMMC from boot0 partition offset 0x0

Flashing images to eMMC:

The following commands can be used to download tiboot3.bin, tispl.bin, u-boot.img, and sysfw.itb from an SD card and write them to the eMMC boot0 partition at respective addresses.

mmc dev 0 1
fatload mmc 1 ${loadaddr} tiboot3.bin
mmc write ${loadaddr} 0x0 0x400
fatload mmc 1 ${loadaddr} tispl.bin
mmc write ${loadaddr} 0x400 0x1000
fatload mmc 1 ${loadaddr} u-boot.img
mmc write ${loadaddr} 0x1400 0x2000
fatload mmc 1 ${loadaddr} sysfw.itb
mmc write ${loadaddr} 0x3600 0x800

To give the ROM access to the boot partition, the following commands must be used for the first time:

mmc partconf 0 1 1 1
mmc bootbus 0 1 0 0

To create a software partition for the rootfs, the following command can be used:

gpt write mmc 0 ${partitions}

eMMC layout:

Kernel image and DT are expected to be present in the /boot folder of rootfs. To boot kernel from eMMC, use the following commands:

setenv mmcdev 0
setenv bootpart 0
boot

OSPI:

ROM supports booting from OSPI from offset 0x0.

Flashing images to OSPI:

Below commands can be used to download tiboot3.bin, tispl.bin, u-boot.img, and sysfw.itb over tftp and then flash those to OSPI at their respective addresses.

sf probe
tftp ${loadaddr} tiboot3.bin
sf update $loadaddr 0x0 $filesize
tftp ${loadaddr} tispl.bin
sf update $loadaddr 0x80000 $filesize
tftp ${loadaddr} u-boot.img
sf update $loadaddr 0x280000 $filesize
tftp ${loadaddr} sysfw.itb
sf update $loadaddr 0x6C0000 $filesize

Flash layout for OSPI:

Kernel Image and DT are expected to be present in the /boot folder of UBIFS ospi.rootfs just like in SD card case. U-Boot looks for UBI volume named “rootfs” for rootfs.

To boot kernel from OSPI, at the U-Boot prompt:

setenv boot ubi
boot

UART:

ROM supports booting from MCU_UART0 via X-Modem protocol. The entire UART-based boot process up to U-Boot (proper) prompt goes through different stages and uses different UART peripherals as follows:

ROM UART Boot Responsibilities
Who	Loading What	Hardware Module	Protocol
Boot ROM	tiboot3.bin	MCU_UART0	X-Modem(*)
R5 SPL	sysfw.itb	MCU_UART0	Y-Modem(*)
R5 SPL	tispl.bin	MAIN_UART0	Y-Modem
A53 SPL	u-boot.img	MAIN_UART0	Y-Modem

Note that in addition to X/Y-Modem related protocol timeouts the DMSC watchdog timeout of 3min (typ.) needs to be observed until System Firmware is fully loaded (from sysfw.itb) and started.

Example bash script sequence for running on a Linux host PC feeding all boot artifacts needed to the device:

MCU_DEV=/dev/ttyUSB1
MAIN_DEV=/dev/ttyUSB0

stty -F $MCU_DEV 115200 cs8 -cstopb -parenb
stty -F $MAIN_DEV 115200 cs8 -cstopb -parenb

sb --xmodem tiboot3.bin > $MCU_DEV < $MCU_DEV
sb --ymodem sysfw.itb > $MCU_DEV < $MCU_DEV
sb --ymodem tispl.bin > $MAIN_DEV < $MAIN_DEV
sleep 1
sb --xmodem u-boot.img > $MAIN_DEV < $MAIN_DEV

Debugging U-Boot

See Common Debugging environment - OpenOCD: for detailed setup information.

Warning

OpenOCD support since: v0.12.0

If the default package version of OpenOCD in your development environment’s distribution needs to be updated, it might be necessary to build OpenOCD from the source.

Integrated JTAG adapter/dongle: The board has a micro-USB connector labelled XDS110 USB or JTAG. Connect a USB cable to the board to the mentioned port.

Note

There are multiple USB ports on a typical board, So, ensure you have read the user guide for the board and confirmed the silk screen label to ensure connecting to the correct port.

To start OpenOCD and connect to the board

openocd -f board/ti_am654evm.cfg