AM67A Beagleboard.org BeagleY-AI

Introduction:

BeagleBoard.org BeagleY-AI is an easy to use, affordable open source hardware single board computer based on the Texas Instruments AM67A, which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA), GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5 cores for low-power, low-latency GPIO control.

Further information can be found at:

Product Page: https://beagley-ai.org/
Hardware documentation: https://openbeagle.org/beagley-ai/beagley-ai

Boot Flow:

Below is the pictorial representation of 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. The A53 or R5F (Aux core) sends requests to TIFS/DM to accomplish these services, as illustrated in the diagram above.

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://github.com/TexasInstruments/ti-linux-firmware

branch: ti-linux-firmware

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.

TIFS Stub - The TIFS stub is a small piece of binary designed to help restore the required security context and resume the TIFS firmware when the system resumes from low-power modes such as suspend-to-RAM/Deep Sleep. This stub uses the same encryption and customer key signing model as TIFS and is loaded into the ATCM (Tightly Coupled Memory ‘A’ of the DM R5) during DM startup. Due to the independent certificate signing process, the stub is maintained separately from DM.

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=am67a_beagley_ai_r5_defconfig
export UBOOT_CFG_CORTEXA=am67a_beagley_ai_a53_defconfig
export TFA_BOARD=lite
# we dont use any extra TFA parameters
unset TFA_EXTRA_ARGS
export OPTEE_PLATFORM=k3-am62x

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

Copy these images to an SD card and boot:

tiboot3-j722s-hs-fs-evm.bin from Cortex-R5 build as tiboot3.bin.
tispl.bin and u-boot.img from Cortex-A build.

Image formats

tiboot3.bin

tispl.bin

Additional hardware for U-Boot development

Serial Console is critical for U-Boot development on BeagleY-AI. See BeagleY-AI serial console documentation.
The only onboard storage option is uSD.
(optionally) JTAG is useful when working with very early stages of boot.

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

The only storage option on the platform is uSD card. However, 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:

https://git.ti.com/cgit/arago-project/tisdk-setup-scripts/tree/create-sdcard.sh
https://elinux.org/Beagleboard:Expanding_File_System_Partition_On_A_microSD
Or manually as follows (may not take into distro needs such as EFI or swap):

# Create image with partition table
parted --script <SD CARD DEVICE> \
      mklabel msdos \
      mkpart primary fat16 4MiB 20MiB \
      mkpart primary ext4 20MiB 100% \
      set 1 boot on \
      set 1 bls_boot off \
      set 1 lba on
# Create boot partition
mkfs.vfat <SD CARD DEVICE>1
# Create root partition
mkfs.ext4 <SD CARD DEVICE>2

The simplest option is to start with a standard distribution image like those in BeagleBoard.org Distros Page and download a disk image for BeagleY-AI. 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.

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

LED patterns during boot

LED status indication as system boots up
LED Color	Indicates
Only RED at startup	Boot failure or R5 image not started up
Steady Green	A53 U-boot has started up
Red/Orange	OS boot process has been initiated
Steady Green	OS boot process failed and drops to U-Boot shell

Warning

If the “red” power LED is not glowing, the system power supply is not functional. Please refer to BeagleY-AI documentation for further information.

A53 SPL DDR Memory Layout

This provides an overview memory usage in A53 SPL stage.

Region	Start Address	End Address
EMPTY	0x80000000	0x80080000
TEXT BASE	0x80080000	0x800d8000
EMPTY	0x800d8000	0x80477660
STACK	0x80477660	0x80477e60
GD	0x80477e60	0x80478000
MALLOC	0x80478000	0x80480000
EMPTY	0x80480000	0x80a00000
BSS	0x80a00000	0x80a80000
BLOBS	0x80a80000	0x80d00400
EMPTY	0x80d00400	0x81000000

Debugging U-Boot

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

Warning

OpenOCD support since: commit 33749a7fbeb5

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:

TUMPA or equivalent dongles supported by OpenOCD.
Tag-Connect cable appropriate to the board such as TC2050-IDC-NL
In case of no-leg, version, a retaining clip
Tag-Connect to ARM20 adapter

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 BeagleY-AI (J722S/AM67A 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 j722s
}

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