While the primary focus of the T3-GEM-O1 development board is Linux, it also leverages the power of the R5 and C7x cores within the Texas AM67 microprocessor. This section will explore topics such as how to compile software for the R5 cores, perform debugging, and more.
By the end of this section, you will gain knowledge and experience in the following areas:
  • Compiling Texas AM67 MCU software and running it on the Gemstone Obsidian
  • Understanding the boot stages of the system when the development board is first powered on

​
1. MCU Software Development

The tools required to compile MCU projects are listed below.
  1. Texas Instruments Processor SDK RTOS J722S
  2. Texas Instruments Sysconfig
  3. Texas Instruments Code Generation Tools C7000
  4. Texas Instruments Code Generation Tools ARM LLVM
Since downloading and installing these tools one by one from the Texas Instruments website is cumbersome, the t3gemstone/examples repository has been set up to download all the necessary tools and provide the infrastructure to compile MCU projects.

​
1.1. Download example projects via Git clone

ubuntu@host:~$ git clone https://github.com/t3gemstone/examples.git
ubuntu@host:~$ cd examples

​
1.2. Install tools and libraries required for compilation

ubuntu@host:examples$ ./setup.sh
ubuntu@host:examples$ devbox shell
ubuntu@host:examples$ task fetch-ti

​
1.3. Create a template project

The mcu project in the t3gemstone/examples repository contains sample projects for two R5F real-time cores and two C7x DSP cores. Similar examples can be found in the build/ti/ti-processor-sdk-rtos-j722s-evm-10_01_00_04/mcu_plus_sdk_j722s_10_01_00_22/examples directory. It is recommended to find an example project that suits your purpose, copy it to the mcu project directory, and develop on it. Each example project has subdirectories for different cores. For example, the hello_world project contains the following directories:
  1. c75ss0-0_freertos
  2. c75ss1-0_freertos
  3. main-r5fss0-0_freertos
  4. mcu-r5fss0-0_freertos
Development should be done in the directory corresponding to the core where the code will run, and the compiled outputs from that directory should be used. The MCU projects to be compiled are defined in the .env file as the MCU_TARGETS variable. Add the absolute or relative path of the project’s makefile directory to the MCU_TARGETS variable. Below is an example for the mcu-r5fss0-0_freertos core of the hello_world project. 
MCU_TARGETS="
ipc_rpmsg_echo_linux/j722s-evm/c75ss0-0_freertos/ti-c7000
ipc_rpmsg_echo_linux/j722s-evm/c75ss1-0_freertos/ti-c7000
ipc_rpmsg_echo_linux/j722s-evm/main-r5fss0-0_freertos/ti-arm-clang
ipc_rpmsg_echo_linux/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang
hello_world/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang
"

​
1.4. Configure peripherals with SysConfig

The peripherals used by the project (GPIO, I2C, UART, etc.) and their configurations are defined in the .syscfg file. The SysConfig GUI tool is used to add new peripherals or modify the Pin Mux settings of existing ones. To launch SysConfig for an MCU project:
  • Change the SYSCONFIG_TARGET variable to the desired project.
    • You can edit this variable in the .env file or
    • Pass it as an environment variable to the task program.
SYSCONFIG_TARGET=hello_world/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang task sysconfig
After saving your changes with the Ctrl + S shortcut, you can close the SysConfig interface.
The remoteproc infrastructure is used to remotely load software onto the R5F and C7x cores from Linux. Certain settings must be configured in the SysConfig interface for a compiled .out file to be loaded via remoteproc. After copying a new project, follow these steps:
  1. Open the IPC tab under TI DRIVERS.
  2. Click the ADD button.
  3. Ensure the Linux A53 IPC RP Message setting is active.
  4. Save the .syscfg file with the Ctrl + S shortcut and exit.

​
1.5. Compile the project

ubuntu@host:examples$ PROJECT=mcu task clean build

​
1.6. Upload the compiled project to the development board

ubuntu@host:examples$ scp mcu/hello_world/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang/hello_world.release.out gemstone@10.0.0.1:

​
1.7. Run the compiled project

The .out files to be loaded onto the cores via remoteproc must be copied to the /lib/firmware directory with predefined names. The firmware names for each core are listed in the table below.
CoreFirmware
mcu-r5fss0-0j722s-mcu-r5f0_0-fw
main-r5fss0-0j722s-main-r5f0_0-fw
c7xss0-0j722s-c71_0-fw
c7xss1-0j722s-c71_1-fw
The firmware names and which core corresponds to which remoteproc device can be accessed with the head /sys/class/remoteproc/remoteproc*/firmware command. Since the cores may correspond to different remoteproc devices after each boot, this must be checked.
The above procedure ensures that the remote cores are shut down and restarted smoothly. In some cases, a smooth shutdown may fail. In such cases, we recommend the following steps:
  1. Place the new firmware files in the /lib/firmware directory.
  2. Reboot the board.
During system startup, the remoteproc mechanism will automatically load the firmware onto the relevant cores.Note: This approach is particularly useful in the following scenarios:
  • When core crashes occur
  • When IPC communication is interrupted
  • When unexpected behavior is observed during dynamic loading

​
2. Boot Diagram

The flowchart below is specific to the Gemstone Obsidian development board, but many ARM-based embedded Linux development boards have a similar structure.

​
2.1. ROM Bootloader (RBL)

The RBL (ROM Bootloader), often distributed only as compiled binaries without source code by manufacturers, has the primary purpose of performing hardware health checks and initialization when the board is first powered on, then transitioning to the SBL (Secondary Bootloader), whose source code can be modified. The location from which the SBL is read and started is determined by the RBL based on Bootmode switches.

​
2.2. Secondary Bootloader (SBL)

The purpose of the Secondary Boot Loader on the T3-GEM-O1 development boards is to start the more advanced U-Boot bootloader and enable the writing of images to eMMC via the Gemstone Imager application. U-Boot is commonly preferred in embedded boards running Linux. While pre-bootloaders like SBL can perform basic initialization, U-Boot offers many more advanced features. For example, U-Boot has its own Terminal/Console interface and supports many drivers not available in SBL, enabling more sophisticated customizations.

​
2.3. U-Boot

After the SBL, U-Boot takes control of the development board. Based on the configurations defined in the Device Tree, it activates the relevant hardware drivers and executes predefined commands to load components like the Linux Kernel and Initrd into RAM, then hands control over to the Linux Kernel.

​
2.3.1. U-Boot Console Exercises

This section demonstrates the use of the U-Boot console by connecting to the Gemstone development board via TTL. You can quickly skim the documents below.

Todo: U-Boot TTL

​
2.4. Linux Kernel

Loads the drivers for the hardware defined in the Device Tree. Then, if present, it starts the initrd/initramfs and executes the init program located in the rootfs.
The device tree files for U-Boot and the Linux kernel are different. The device tree in U-Boot typically only activates enough hardware to load the kernel and initramfs into RAM from various storage devices (MMC, SSD, SPI flash, etc.). The actual hardware activation is performed by the kernel.

​
2.5. Initial RAM Disk (Initrd)

A temporary filesystem in RAM that performs intermediate tasks such as loading kernel modules, decrypting disks, or performing software updates before the rootfs is started.
If the rootfs is stored encrypted on disk, the kernel cannot directly start the init program. First, the disk encryption must be decrypted by the initramfs.

​
2.6. Root Filesystem (Rootfs)

After completing its tasks, the initrd mounts the root filesystem (rootfs), which contains system and user programs, libraries, and various configuration files, to the / directory. The kernel then executes the init program located in /init, /sbin/init, or a similar directory in the rootfs. This program loads some hardware drivers (kernel modules), starts system services (such as network connectivity, time synchronization, package updates, and Bluetooth), and launches the desktop environment (gnome, kde, xfce, etc.).

​
3. Conclusion

Below are a few example articles about the boot process.