J742S2, J784S4 and AM69 Platforms

Introduction

The J784S4 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration in automotive, ADAS and industrial applications requiring AI at the network edge. This SoC extends the K3 Jacinto 7 family of SoCs with focus on raising performance and integration while providing interfaces, memory architecture and compute performance for multi-sensor, high concurrency applications.

The device is partitioned into three functional domains, each containing specific processing cores and peripherals:

  1. Wake-up (WKUP) domain

    • ARM Cortex-M4F processor, runs TI Foundational Security (TIFS)

  2. Microcontroller (MCU) domain

    • Dual core ARM Cortex-R5F processor, runs device management and SoC early boot

  3. MAIN domain

    • Two clusters of quad core 64-bit ARM Cortex-A72, runs HLOS

    • Dual core ARM Cortex-R5F processor used for RTOS applications

    • Four C7x DSPs used for Machine Learning applications.

More info can be found in TRM: http://www.ti.com/lit/zip/spruj52

Platform information:

J742S2 is derivative of J784S24 SOC, More info can be found in

Boot Flow

Below is the pictorial representation of boot flow:

K3 boot flow

  • On this platform, “TI Foundational Security” (TIFS) functions as the security enclave master. While “Device Manager” (DM), also known as the “TISCI server” in TI terminology, offers all the essential services.

  • As illustrated in the diagram above, R5 SPL manages power and clock services independently before handing over control to DM. The A72 or the C7x (Aux core) software components request TIFS/DM to handle security or device management services.

Sources

Note

The TI Firmwares required for functionality of the system are (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.

Build procedure

  1. 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=j784s4_evm_r5_defconfig
export UBOOT_CFG_CORTEXA=j784s4_evm_a72_defconfig
export TFA_BOARD=j784s4
export TFA_EXTRA_ARGS="K3_USART=0x8"
export OPTEE_PLATFORM=k3-j784s4
export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8"

Note

For AM69-SK, use the following U_BOOT_CFG instead:

export UBOOT_CFG_CORTEXR=am69_sk_r5_defconfig
export UBOOT_CFG_CORTEXA=am69_sk_a72_defconfig

For J742S2-EVM, use the following U_BOOT_CFG instead:

export UBOOT_CFG_CORTEXR=j742s2_evm_r5_defconfig
export UBOOT_CFG_CORTEXA=j742s2_evm_a72_defconfig

  1. 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

  1. OP-TEE

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

  1. U-Boot

  • 3.1 R5

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

  • 3.2 A72

# 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-j784s4-gp-evm.bin from step 3.1

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

Note

For J742S2, GP variant is not available.

  • HS-FS

    • tiboot3-j784s4-hs-fs-evm.bin from step 3.1

    • tiboot3-j742s2-hs-fs-evm.bin from step 3.1

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

  • HS-SE

Image formats

  • tiboot3.bin

tiboot3.bin format

  • tispl.bin

tispl.bin format

OSPI:

ROM supports booting from OSPI from offset 0x0.

Flashing images to OSPI NOR:

Below commands can be used to download tiboot3.bin, tispl.bin, and u-boot.img 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

Flash layout for OSPI NOR:

OSPI NOR flash partition layout

R5 Memory Map

Region

Start Address

End Address

SPL

0x41c00000

0x41c40000

EMPTY

0x41c40000

0x41c61f20

STACK

0x41c65f20

0x41c61f20

Global data

0x41c65f20

0x41c66000

Heap

0x41c66000

0x41c76000

BSS

0x41c76000

0x41c80000

DM DATA

0x41c80000

0x41c84130

EMPTY

0x41c84130

0x41cff9fc

MCU Scratchpad

0x41cff9fc

0x41cffbfc

ROM DATA

0x41cffbfc

0x41cfffff

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.

Boot Mode Pins for J784S4-EVM

The following tables show some common boot modes used on J784S4 EVM platform. More details can be found in the Technical Reference Manual: http://www.ti.com/lit/zip/spruj52 under the Boot Mode Pins section.

J784S4 EVM Boot Modes

Switch Label

SW11: 12345678

SW7: 12345678

SD

10000010

00000000

EMMC

10000000

01000000

OSPI

00000110

01000000

UART

00000000

01110000

PCIe

10001000

01010000

For SW7 and SW11, the switch state in the “ON” position = 1.

Boot Mode Pins for AM69-SK

The following table show some common boot modes used on AM69-SK platform. More details can be found in the User Guide for AM69-SK: https://www.ti.com/lit/ug/spruj70/spruj70.pdf under the Bootmode Settings section.

AM69 SK Boot Modes

Switch Label

SW2: 1234

SD

0000

OSPI

0010

EMMC

0110

UART

1010

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

PCIe Boot

The J784S4 SoC supports booting over PCIe, allowing the device to function as a PCIe endpoint and receive boot loader images from a PCIe Root Complex. The PCIe1 instance of PCIe is configured by Boot ROM for Endpoint Mode of operation. Hence, the PCIe Connector on the EVM corresponding to PCIe1 should be utilized for PCIe Boot.

Hardware Setup

To boot the J784S4 EVM via PCIe, the following hardware setup is required:

  1. Configure the boot mode switches on J784S4-EVM for PCIe boot:

    SW7:  01010000
SW11: 10001000

  2. Connect the J784S4-EVM (endpoint) to a PCIe Root Complex (e.g., x86 host) using a PCIe cable. Both boards should be powered off before making the connection.

Endpoint Configuration

The following configuration options are enabled by default in j784s4_evm_r5_defconfig and j784s4_evm_a72_defconfig:

  • CONFIG_SPL_PCI_DFU_BAR_SIZE: Size of the PCIe BAR for DFU/boot image download

  • CONFIG_SPL_PCI_DFU_VENDOR_ID: PCIe vendor ID advertised by the endpoint

  • CONFIG_SPL_PCI_DFU_DEVICE_ID: PCIe device ID advertised by the endpoint

  • CONFIG_SPL_PCI_DFU_MAGIC_WORD: Magic word written by Root Complex to signal image transfer completion

  • CONFIG_SPL_PCI_DFU_BOOT_PHASE: Current boot phase indicator for Root Complex

By default, PCIe Root Complex mode is enabled in the device tree. For PCIe Boot, build the Bootloaders with the following content added to k3-j784s4-evm-u-boot.dtsi:

&serdes0 {
        /delete-property/ serdes0_usb_link;
};

&serdes_refclk {
        bootph-all;
};

&serdes0_pcie1_link {
        bootph-all;
};

&serdes_ln_ctrl {
        bootph-all;
};

&pcie1_ctrl {
        bootph-all;
};

&pcie1_rc {
        status = "disabled";
};

&cbass_main {
        pcie1_ep: pcie-ep@2910000 {
                compatible = "ti,j784s4-pcie-ep";
                reg = <0x00 0x02910000 0x00 0x1000>,
                      <0x00 0x02917000 0x00 0x400>,
                      <0x00 0x0d800000 0x00 0x00800000>,
                      <0x00 0x18000000 0x00 0x08000000>;
                reg-names = "intd_cfg", "user_cfg", "reg", "mem";
                interrupt-names = "link_state";
                interrupts = <GIC_SPI 330 IRQ_TYPE_EDGE_RISING>;
                ti,syscon-pcie-ctrl = <&pcie1_ctrl 0x0>;
                max-link-speed = <3>;
                num-lanes = <2>;
                power-domains = <&k3_pds 333 TI_SCI_PD_EXCLUSIVE>;
                clocks = <&k3_clks 333 0>;
                clock-names = "fck";
                max-functions = /bits/ 8 <6>;
                max-virtual-functions = /bits/ 8 <4 4 4 4 0 0>;
                dma-coherent;
                phys = <&serdes0_pcie1_link>;
                phy-names = "pcie-phy";
                bootph-all;
        };
};

PCIe Boot Procedure

The following steps describe the process of booting J784S4-EVM over PCIe:

  1. Compile the sample host program (provided after this section):

    gcc -o pcie_boot_util pcie_boot_util.c

  2. Power on the J784S4-EVM (endpoint) after configuring boot mode switches for PCIe Boot.

  3. Copy the compiled sample host program (pcie_boot_util) and the bootloader images to the Root Complex. Check PCIe enumeration on Root Complex to ensure that the J784S4 EVM shows up as the PCIe Endpoint:

    lspci

    The endpoint will appear as a RAM device or with multiple functions:

    0000:00:00.0 PCI bridge: Texas Instruments Device b012
0000:01:00.0 RAM memory: Texas Instruments Device b012
0000:01:00.1 Non-VGA unclassified device: Texas Instruments Device 0100
0000:01:00.2 Non-VGA unclassified device: Texas Instruments Device 0100

  4. Copy tiboot3.bin to BAR1 of Physical Function Zero of the endpoint:

    tiboot3_bar_address="0x$(lspci -D -nnvv | awk '/^[0-9a-fA-F]{4}:/ {bdf=$1; ram=($0 ~ /RAM memory/ || $0 ~ /Memory controller/)} ram && /Region [1]+:/ {print bdf, $0}' | cut -d ' ' -f 6)"
sudo ./pcie_boot_util ${tiboot3_bar_address} tiboot3.bin

    The sample program automatically writes the image start address to 0x41CF3FE0 and the magic word 0xB17CEAD9 to 0x41CF3FE4.

  5. After tiboot3.bin is processed, the PCIe link will go down briefly. Remove the PCIe device and rescan the bus:

    echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/rescan
lspci

    The enumeration will change to something similar:

    0000:00:00.0 PCI bridge: Texas Instruments Device b012
0000:01:00.0 RAM memory: Texas Instruments Device b010 (rev dc)

    Note

    When the Root-Complex enumerates the PCIe Endpoint after a ‘remove-rescan’ sequence, it is possible that the ‘BAR’ appears ‘disabled’. If so, writing to the BAR via the ‘pcie_boot_util’ to transfer the bootloader image will have no effect. In such cases, run ‘setpci -s 0000:01:00.0 COMMAND=0x02’ on the Root-Complex after enumeration (with appropriate DOMAIN:BUS:DEVICE.FUNCTION corresponding to the Endpoint) to enable the BAR.

  6. Copy tispl.bin to BAR0 of Physical Function Zero of the endpoint:

    tispl_bar_address="0x$(lspci -D -nnvv | awk '/^[0-9a-fA-F]{4}:/ {bdf=$1; ram=($0 ~ /RAM memory/ || $0 ~ /Memory controller/)} ram && /Region [0]+:/ {print bdf, $0}' | head -n1 | cut -d ' ' -f 6)"
sudo ./pcie_boot_util ${tispl_bar_address} tispl.bin

  7. After tispl.bin is processed, the PCIe link will go down again. Remove and rescan the PCIe device:

    echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/rescan

  8. Copy u-boot.img to BAR0 of Physical Function Zero of the endpoint:

    uboot_bar_address="0x$(lspci -D -nnvv | awk '/^[0-9a-fA-F]{4}:/ {bdf=$1; ram=($0 ~ /RAM memory/ || $0 ~ /Memory controller/)} ram && /Region [0]+:/ {print bdf, $0}' | head -n1 | cut -d ' ' -f 6)"
sudo ./pcie_boot_util ${uboot_bar_address} u-boot.img

  9. After u-boot.img is successfully loaded, the boot process is complete and endpoint should boot till U-Boot prompt.

Note

During the boot process, “PCIe LINK DOWN” messages might appear in kernel logs. This is expected as the endpoint resets and re-initializes the PCIe link after processing each boot stage.

Sample Host Program

The following C program can be used on the Root Complex to copy bootloader images to the J784S4 endpoint:

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>
#include <string.h>

#define MAP_SIZE 0x400000

/*
 * bootloader_file: Path to the bootloader image (tiboot3.bin, tispl.bin and u-boot.img)
 * bootloader_mem: Memory allocated in RAM for reading the bootloader image file
 * bar_address: Address of BAR to which bootloader image will be written
 * bar_map_base: Mapping of the BAR Base Address for the program
 * load_address: Address in BAR region where bootloader is being transferred
 * transfer_completion_offset: Offset in BAR region to write to notify completion of transfer
 * fd_mem: File descriptor for opening /dev/mem
 * fptr: File pointer for bootloader image in filesystem
 * magic_word: Magic word to notify completion of tiboot3.bin transfer to Boot ROM
 * use_magic_word: Flag to indicate if Magic Word has to be written
 * file_size: Size of bootloader image
 * i: Iterator used during bootloader image transfer
 */
int main(int argc, char *argv[])
{
   off_t bar_address, load_address, transfer_completion_offset;
   unsigned char *bootloader_mem;
   const char *bootloader_file;
   int fd_mem, i, use_magic_word;
   unsigned int magic_word;
   void *bar_map_base;
   long file_size;
   FILE * fptr;

   if (argc != 3) {
       printf("Usage: %s <bar_address> <bootloader_file>\n", argv[0]);
       return 0;
   }

   bar_address = strtoul(argv[1], NULL, 16);
   bootloader_file = argv[2];

   printf("Bootloader File: %s\n", bootloader_file);
   printf("BAR Address: 0x%lx\n", bar_address);

   if(!strcmp(bootloader_file,"tiboot3.bin")) {
       transfer_completion_offset = 0xF3FE0;
       load_address = 0x41C00000;
       magic_word = 0xB17CEAD9;
       use_magic_word = 1;
   } else {
       transfer_completion_offset = MAP_SIZE - 0x4;
       load_address = 0xDEADBEEF;
       use_magic_word = 0;
   }

   fd_mem = open("/dev/mem", O_RDWR | O_SYNC);
   if(fd_mem == -1) {
       printf("failed to open /dev/mem\n");
       return -1;
   }

   bar_map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd_mem, bar_address);
   if(bar_map_base == (void *)-1) {
       printf("failed to map BAR\n");
       return -1;
   }

   fptr = fopen(bootloader_file, "rb");
   if (!fptr) {
       printf("failed to read bootloader file\n");
       return -1;
   }

   fseek(fptr, 0, SEEK_END);
   file_size = ftell(fptr);
   rewind(fptr);

   bootloader_mem = (unsigned char *)malloc(sizeof(char) * file_size);
   if(!bootloader_mem) {
      printf("failed to allocate local memory for bootloader file\n");
      return -1;
   }

   if (fread(bootloader_mem, 1, file_size, fptr) != file_size) {
       printf("failed to read bootloader file into local memory\n");
       return -1;
   }

   for(i = 0; i < file_size; i++) {
       *((char *)(bar_map_base) + i) = bootloader_mem[i];
   }

   *(unsigned int *)(bar_map_base + transfer_completion_offset) = (unsigned int)(load_address);

   if(use_magic_word) {
       *(unsigned int *)(bar_map_base + transfer_completion_offset + 4) = magic_word;
       printf("Magic word written for Boot ROM\n");
   }

   printf("Transferred %s to Endpoint\n", bootloader_file);
   return 0;
}

This program copies the boot image to the PCIe endpoint’s memory region and writes the necessary control words to signal image transfer completion.

Debugging U-Boot

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

Warning

OpenOCD support since: September 2023 (git master)

Until the next stable release of OpenOCD is available in your development environment’s distribution, it might be necessary to build OpenOCD from the source.

Debugging U-Boot on J784S4-EVM and AM69-SK

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 J784S4-EVM or AM69-SK board, use the following.

openocd -f board/ti_j784s4evm.cfg