J721E/TDA4VM Beagleboard.org BeagleBone AI-64

Introduction:

BeagleBoard.org BeagleBone AI-64 is an open source hardware single board computer based on the Texas Instruments TDA4VM SoC featuring dual-core 2.0GHz Arm Cortex-A72 processor, C7x+MMA and 2 C66x floating-point VLIW DSPs, 3x dual ARM Cortex-R5 co-processors, 2x 6-core Programmable Real-Time Unit and Industrial Communication SubSystem, PowerVR Rogue 8XE GE8430 3D GPU. The board features 4GB DDR4, USB3.0 Type-C, 2x USB SS Type-A, miniDisplayPort, 2x 4-lane CSI, DSI, 16GB eMMC flash, 1G Ethernet, M.2 E-key for WiFi/BT, and BeagleBone expansion headers.

Further information can be found at:

Boot Flow:

Below is the pictorial representation of boot flow:

Boot flow diagram
  • On this platform, DMSC runs ‘TI Foundational Security’ (TIFS) which functions as the security enclave master. The ‘Device Manager’ (DM), also known as the ‘TISCI server’ in “TI terminology”, running on boot R5F, offers all the essential services required for device management. The A72, C7x, C6x or R5F (Aux cores) sends requests to TIFS/DM to accomplish the needed services, as illustrated in the diagram above.

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=j721e_beagleboneai64_r5_defconfig
export UBOOT_CFG_CORTEXA=j721e_beagleboneai64_a72_defconfig
export TFA_BOARD=generic
# we dont use any extra TFA parameters
unset TFA_EXTRA_ARGS
export OPTEE_PLATFORM=k3-j721e
# we dont use any extra OP-TEE parameters
unset OPTEE_EXTRA_ARGS
  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

Copy the below images to an SD card and boot:

  • tiboot3-j721e-gp-evm.bin from R5 build as tiboot3.bin

  • tispl.bin_unsigned from Cortex-A build as tispl.bin

  • u-boot.img_unsigned from Cortex-A build as u-boot.img

Image formats

  • tiboot3.bin

tiboot3.bin image format
  • tispl.bin

tispl.bin image format
  • sysfw.itb

sysfw.itb image format

Additional hardware for U-Boot development

  • Serial Console is critical for U-Boot development on BeagleBone AI-64. See BeagleBone AI-64 connector documentation.

  • uSD is preferred option over eMMC, and a SD/MMC reader will be needed.

  • (optionally) JTAG is useful when working with very early stages of boot.

Default storage options

There are multiple storage media options on BeagleBone AI-64, but primarily:

  • Onboard eMMC (default) - reliable, fast and meant for deployment use.

  • SD/MMC card interface (hold ‘BOOT’ switch and power on) - Entirely depends on the SD card quality.

Flash to uSD card or how to deal with “bricked” Board

When deploying or working on Linux, it’s common to use the onboard eMMC. However, avoiding the eMMC and using the uSD card is safer when working with U-Boot.

If you choose to hand format your own bootable uSD card, be aware that it can be difficult. The following information may be helpful, but remember that it is only sometimes reliable, and partition options can cause issues. These can potentially help:

The simplest option is to start with a standard distribution image like those in BeagleBoard.org Distros Page and download a disk image for BeagleBone AI-64. Pick a 16GB+ uSD card to be on the safer side.

With an SD/MMC Card reader and Balena Etcher, having a functional setup in minutes is a trivial matter, and it works on almost all Host Operating Systems. Yes Windows users, Windows Subsystem for Linux(WSL) based development with U-Boot and update uSD card is practical.

Updating U-Boot is a matter of copying the tiboot3.bin, tispl.bin and u-boot.img to the “BOOT” partition of the uSD card. Remember to sync and unmount (or Eject - depending on the Operating System) the uSD card prior to physically removing from SD card reader.

Also see following section on switch setting used for booting using uSD card.

Note

Great news! If the board has not been damaged physically, there’s no need to worry about it being “bricked” on this platform. You only have to flash an uSD card, plug it in, and reinstall the image on eMMC. This means that even if you make a mistake, you can quickly fix it and rest easy.

If you are frequently working with uSD cards, you might find the following useful:

Flash to eMMC

The eMMC layout selected is user-friendly for developers. The boot hardware partition of the eMMC only contains the fixed-size tiboot3.bin image. This is because the contents of the boot partitions need to run from the SoC’s internal SRAM, which remains a fixed size constant. The other components of the boot sequence, such as tispl.bin and u-boot.img, are located in the /BOOT partition in the User Defined Area (UDA) hardware partition of the eMMC. These components can vary significantly in size. The choice of keeping tiboot3.bin in boot0 or boot1 partition depends on A/B update requirements.

eMMC partitions and boot file organization for BeagleBone AI-64

The following are the steps from Linux shell to program eMMC:

# Enable Boot0 boot
mmc bootpart enable 1 2 /dev/mmcblk0
mmc bootbus set single_backward x1 x8 /dev/mmcblk0
mmc hwreset enable /dev/mmcblk0

# Clear eMMC boot0
echo '0' >> /sys/class/block/mmcblk0boot0/force_ro
dd if=/dev/zero of=/dev/mmcblk0boot0 count=32 bs=128k
# Write tiboot3.bin
dd if=tiboot3.bin of=/dev/mmcblk0boot0 bs=128k

# Copy the rest of the boot binaries
mount /dev/mmcblk0p1 /boot/firmware
cp tispl.bin /boot/firmware
cp u-boot.img /boot/firmware
sync

Warning

U-Boot is configured to prioritize booting from an SD card if it detects a valid boot partition and boot files on it, even if the system initially booted from eMMC. The boot order is set as follows:

  • SD/MMC

  • eMMC

  • USB

  • PXE

LED patterns during boot

USR LED status indication

USR LEDs (012345)

Indicates

00000

Boot failure or R5 image not started up

11111

A53 SPL/U-boot has started up

10101

OS boot process has been initiated

01010

OS boot process failed and drops to U-Boot shell

Note

In the table above, 0 indicates LED switched off and 1 indicates LED switched ON.

Warning

The green LED very next to the serial connector labelled “WKUP UART0” is the power LED (LED6). This is the same color as the rest of the USR LEDs. If the “green” LED6 power LED is not glowing, the system power supply is not functional. Please refer to BeagleBone AI-64 documentation for further information.

Switch Setting for Boot Mode

The boot time option is configured via “BOOT” button on the board. See BeagleBone AI-64 Schematics for details.

Boot Modes

BOOT Switch Position

Primary Boot

Secondary Boot

Not Pressed

eMMC

SD Card

Pressed

SD Card

SD Card

To switch to SD card boot mode, hold the BOOT button while powering on with Type-C power supply, then release when power LED lights up.

Debugging U-Boot

See Common Debugging environment - OpenOCD: for detailed setup and debugging 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.

Tag-Connect: Tag-Connect pads on the boards which require special cable. Please check the documentation to identify if “legged” or “no-leg” version of the cable is appropriate for the board.

To debug on these boards, you will need:

Note

You can optionally use a 3d printed solution such as Protective cap or clip to replace the retaining clip.

Warning

With the Tag-Connect to ARM20 adapter, Please solder the “Trst” signal for connection to work.

  • External JTAG adapter/interface: In other cases, where an adapter/dongle is used, a simple cfg file can be created to integrate the SoC and adapter information. See supported TI K3 SoCs to decide if the SoC is supported or not.

openocd -f openocd_connect.cfg

For example, with BeagleBone AI-64 (J721e platform), the openocd_connect.cfg:

# TUMPA example:
# http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User's_Manual
source [find interface/ftdi/tumpa.cfg]

transport select jtag

# default JTAG configuration has only SRST and no TRST
reset_config srst_only srst_push_pull

# delay after SRST goes inactive
adapter srst delay 20

if { ![info exists SOC] } {
  # Set the SoC of interest
  set SOC j721e
}

source [find target/ti_k3.cfg]

ftdi tdo_sample_edge falling

# Speeds for FT2232H are in multiples of 2, and 32MHz is tops
# max speed we seem to achieve is ~20MHz.. so we pick 16MHz
adapter speed 16000