AM64 Platforms

Introduction:

The AM642 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable applications such as Motor Drives, PLC, Remote IO and IoT Gateways.

Some highlights of this SoC are:

Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F MCUs, and a single Cortex-M4F.
Two Gigabit Industrial Communication Subsystems (ICSSG).
Integrated Ethernet switch supporting up to a total of two external ports.
PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other peripherals.
Centralized System Controller for Security, Power, and Resource Management (DMSC).

More details can be found in the Technical Reference Manual:: https://www.ti.com/lit/pdf/spruim2

Platform information:

AM64-EVM: https://www.ti.com/tool/TMDS64EVM
AM64-SK: https://www.ti.com/tool/SK-AM64B

Boot Flow:

Below is the pictorial representation of boot flow:

Here TIFS acts as master and provides all the critical services. R5/A53 requests TIFS 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=am64x_evm_r5_defconfig
export UBOOT_CFG_CORTEXA=am64x_evm_a53_defconfig
export TFA_BOARD=lite
# we dont use any extra TFA parameters
unset TFA_EXTRA_ARGS
export OPTEE_PLATFORM=k3-am64x
# we dont use any extra TFA 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, tispl.bin and u-boot.img. Each SoC variant (GP, HS-FS, HS-SE) requires a different source for these files.

GP

tiboot3-am64x-gp-evm.bin from step 3.1

tispl.bin_unsigned, u-boot.img_unsigned from step 3.2

HS-FS

tiboot3-am64x-hs-fs-evm.bin from step 3.1

tispl.bin, u-boot.img from step 3.2

HS-SE

tiboot3-am64x-hs-evm.bin from step 3.1

tispl.bin, u-boot.img from step 3.2

Image formats:

tiboot3.bin

tispl.bin

Switch Setting for Boot Mode

Boot Mode pins provide means to select the boot mode and options before the device is powered up. After every POR, they are the main source to populate the Boot Parameter Tables.

The following table shows some common boot modes used on AM64 platform. More details can be found in the Technical Reference Manual: https://www.ti.com/lit/pdf/spruim2 under the Boot Mode Pins section.

Boot Modes for AM64x-EVM
Switch Label	SW2: 12345678	SW3: 12345678
SD/MMC	11000010	01000000
xSPI/SFDP (OSPI)	11001110	01000000
UART	11011100	00000000

Note

For SW2 and SW3, the switch state in the “ON” position = 1.

Boot Modes for AM64x-SK
Switch Label	SW2: 12345678	SW3: 12345678
SD/MMC	00000010	01000011
xSPI/SFDP (OSPI)	00000010	01110011
UART	00000000	00111011

Note

For SW2 and SW3, the switch state in the “ON” position = 1. Boot bits on SK is reversed bits to the bootmode signals