AM62x Beagleboard.org Beagleplay
Introduction:
BeagleBoard.org BeaglePlay is an easy to use, affordable open source hardware single board computer based on the Texas Instruments AM625 SoC that allows you to create connected devices that work even at long distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L. Expansion is provided over open standards based mikroBUS, Grove and QWIIC headers among other interfaces.
Further information can be found at:
Product Page: https://beagleplay.org/
Hardware documentation: https://git.beagleboard.org/beagleplay/beagleplay
Boot Flow:
Below is the pictorial representation of boot flow:
Boot flow diagramOn 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 M4F (Aux core) sends requests to TIFS/DM to accomplish these services, as illustrated in the diagram above.
Sources:
Das U-Boot
branch: masterTrusted Firmware-A (TF-A)
branch: masterOpen Portable Trusted Execution Environment (OP-TEE)
branch: masterTI Firmware (TIFS, DM, SYSFW)
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:
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 |
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:
exportCC32=arm-linux-gnueabihf- exportCC64=aarch64-linux-gnu- exportLNX_FW_PATH=path/to/ti-linux-firmware exportTFA_PATH=path/to/trusted-firmware-a exportOPTEE_PATH=path/to/optee_os
exportUBOOT_CFG_CORTEXR=am62x_beagleplay_r5_defconfig exportUBOOT_CFG_CORTEXA=am62x_beagleplay_a53_defconfig exportTFA_BOARD=lite # we dont use any extra TFA parameters unsetTFA_EXTRA_ARGS exportOPTEE_PLATFORM=k3-am62x exportOPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
Trusted Firmware-A:
# inside trusted-firmware-a source makeCROSS_COMPILE=$CC64ARCH=aarch64PLAT=k3SPD=opteed$TFA_EXTRA_ARGS\ TARGET_BOARD=$TFA_BOARD
OP-TEE:
# inside optee_os source makeCROSS_COMPILE=$CC32CROSS_COMPILE64=$CC64CFG_ARM64_core=y$OPTEE_EXTRA_ARGS\ PLATFORM=$OPTEE_PLATFORM
U-Boot:
3.1 R5:
# inside u-boot source make$UBOOT_CFG_CORTEXR makeCROSS_COMPILE=$CC32BINMAN_INDIRS=$LNX_FW_PATH
3.1.1 Alternative build of R5 for DFU boot:
As the SPL size can get too big when building with support for booting both from local storage and DFU an extra config fragment should be used to enable DFU support (and disable storage support)
exportUBOOT_CFG_CORTEXR="${UBOOT_CFG_CORTEXR} am62x_r5_usbdfu.config"
# inside u-boot source make$UBOOT_CFG_CORTEXR makeCROSS_COMPILE=$CC32BINMAN_INDIRS=$LNX_FW_PATH
3.2 A53:
# inside u-boot source make$UBOOT_CFG_CORTEXA makeCROSS_COMPILE=$CC64BINMAN_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.
3.2.1 Alternative build of A53 for Android bootflow:
Since the Android requires many more dependencies, it is disabled by default. An extra config fragment should be used to enable Android bootflow support.
exportUBOOT_CFG_CORTEXR="${UBOOT_CFG_CORTEXA} am62x_a53_android.config"
# inside u-boot source make$UBOOT_CFG_CORTEXA makeCROSS_COMPILE=$CC64BINMAN_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.bin from Cortex-R5 build.
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 BeaglePlay. See BeaglePlay serial console 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 BeaglePlay, but primarily:
Onboard eMMC (default) - reliable, fast and meant for deployment use.
SD/MMC card interface (hold ‘USR’ 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:
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
The simplest option is to start with a standard distribution image like those in BeagleBoard.org Distros Page and download a disk image for BeaglePlay. 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 BeaglePlayThe following are the steps from Linux shell to program eMMC:
# Enable Boot0 boot mmcbootpartenable12/dev/mmcblk0 mmcbootbussetsingle_backwardx1x8/dev/mmcblk0 mmchwresetenable/dev/mmcblk0 # Clear eMMC boot0 echo'0'>>/sys/class/block/mmcblk0boot0/force_ro ddif=/dev/zeroof=/dev/mmcblk0boot0count=32bs=128k # Write tiboot3.bin ddif=tiboot3.binof=/dev/mmcblk0boot0bs=128k # Copy the rest of the boot binaries mount/dev/mmcblk0p1/boot/firmware cptispl.bin/boot/firmware cpu-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 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
If the "red" power LED is not glowing, the system power supply is not functional. Please refer to BeaglePlay 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 |
0x80200000 |
BMP IMAGE |
0x80200000 |
0x80b77660 |
STACK |
0x80b77660 |
0x80b77e60 |
GD |
0x80b77e60 |
0x80b78000 |
MALLOC |
0x80b78000 |
0x80b80000 |
EMPTY |
0x80b80000 |
0x80c80000 |
BSS |
0x80c80000 |
0x80d00000 |
BLOBS |
0x80d00000 |
0x80d00400 |
EMPTY |
0x80d00400 |
0x81000000 |
Switch Setting for Boot Mode
The boot time option is configured via "USR" button on the board. See Beagleplay Schematics for details.
USR Switch Position |
Primary Boot |
Secondary Boot |
|---|---|---|
Not Pressed |
eMMC |
UART |
Pressed |
SD/MMC File System (FS) mode |
USB Device Firmware Upgrade (DFU) mode |
To switch to SD card boot mode, hold the USR button while powering on with a USB type C power supply, then release when power LED lights up.
DFU based boot
To boot the board over DFU, ensure there is no SD card inserted with a bootloader. Hold the USR switch while plugging into the type C to boot into DFU mode. After power-on the build artifacts needs to be uploaded one by one with a tool like dfu-util.
The initial ROM will have a DFU alt named bootloader for the initial R5 spl upload. The next stages as exposed by U-Boot have target alts matching the name of the artifacts, for these a USB reset has to be done after each upload.
When using dfu-util the following commands can be used to boot to a U-Boot shell:
dfu-util-abootloader-Dtiboot3.bin dfu-util-R-atispl-Dtispl.bin dfu-util-R-au-boot.img-Du-boot.img
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:
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-fopenocd_connect.cfg
For example, with BeaglePlay (AM62X platform), the openocd_connect.cfg:
# TUMPA example: # http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User's_Manual source[findinterface/ftdi/tumpa.cfg] transportselectjtag # default JTAG configuration has only SRST and no TRST reset_configsrst_onlysrst_push_pull # delay after SRST goes inactive adaptersrstdelay20 if{![infoexistsSOC]}{ # Set the SoC of interest setSOCam625 } source[findtarget/ti_k3.cfg] ftditdo_sample_edgefalling # Speeds for FT2232H are in multiples of 2, and 32MHz is tops # max speed we seem to achieve is ~20MHz.. so we pick 16MHz adapterspeed16000