1. Introduction[edit | edit source]
The coprocessor firmware can be loaded and started:
- either by the second stage bootloader, U-Boot (see Boot_chain_overview for details) or
- by the Linux® kernel (see Linux_remoteproc_framework_overview for details)
This article explains how the coprocessor firmware is loaded by U-Boot and started before the Linux kernel.
 Information
|
|
The STM32MPU Embedded Software distribution enables the loading of the following firmware format in U-Boot:
The firmware image name rproc-copro-fw.elf is used for the examples on this page. It can be replaced by another name, e.g. |
2. Location of the coprocessor firmware[edit | edit source]
With generic DISTRO configuration, U-Boot searches and loads the required binaries in the first GPT bootable partition for block device, which is bootfs in the OpenSTLinux distribution, or the boot UBIFS volume in UBI mtd partition (see STM32 MPU Flash mapping), so the coprocessor firmware must be installed in this partition.
For block device, the simplest way to do it consists in copying the firmware from the rootfs partition to the bootfs partition as follows.
- Boot from an SD card:
mount /dev/mmcblk0p6 /boot cp rproc-copro-fw.elf /boot/ sync
- Here with TF-A update support, bootfs is the 6th partition on SD card. To check the partition name, following commands can be used:
ls -l /dev/disk/by-partlabel/
- Boot from with UBI mtd partition "boot":
mount -t ubifs ubi0:boot /mnt
cp rproc-copro-fw.elf /mnt/
sync
As an alternative method, you can use the Eclipse IDE, or transfer the firmware over the serial console or over the network.
3. Starting the coprocessor firmware[edit | edit source]
U-Boot can boot the coprocessor before the kernel (coprocessor early boot) with remoteproc uclass . Several methods are possible:
- Manual start by using rproc commands
- Automatic start, at each boot by using
- the bootcmd (needing U-Boot recompilation)
- a generic DISTRO boot script
- the FIT image
3.1. Manual start[edit | edit source]
You can load and start the coprocessor firmware by using the rproc command in the U-Boot console (to access to the U-boot console, press any key during the U-Boot execution).
rproc rproc - Control operation of remote processors in an SoC Usage: rproc [init|list|load|start|stop|reset|is_running|ping] Where: [addr] is a memory address <id> is a numerical identifier for the remote processor provided by 'list' command. Note: Remote processors must be initalized prior to usage Note: Services depend on the driver capability 'list' command shows the capability of each device Subcommands: init - Enumerates and initializes the remote processors list - lists available remote processors load <id> [addr] [size]- Loads the remote processor with image stored at address [addr] in memory start <id> - Starts the remote processor(must be loaded) stop <id> - Stops the remote processor reset <id> - Resets the remote processor is_running <id> - Reports if the remote processor is running ping <id> - Pings the remote processor for communication
In this example, the firmware is loaded from an SD card into RAM (at ${kernel_addr_r}), and then launched.
load mmc 0#bootfs ${kernel_addr_r} rproc-copro-fw.elf -> SD card is mmc 0, bootfs partition
rproc init -> initializes all coprocessors
rproc load 0 ${kernel_addr_r} ${filesize} -> loads firmware for coprocessor 0 (code part found in .elf)
rproc start 0 -> starts coprocessor 0
You can then resume the normal boot process:
run bootcmd
3.2. Automatic start[edit | edit source]
3.2.1. Start from the bootcmd[edit | edit source]
You can update the bootcmd which is exectued automatically: modify CONFIG_EXTRA_ENV_SETTINGS in your Configuration file (for example include/configs/stm32mp15_st_common.h for STM32MP15x STMicroelectronics board) and then recompile U-Boot.
For example, to boot a firmware from an SD card, proceed as follows:
#define CONFIG_EXTRA_ENV_SETTINGS \ "stdin=serial\0" \ "stdout=serial\0" \ "stderr=serial\0" \ ... BOOTENV \ "copro_fw_name=rproc-copro-fw.elf\0" \ "boot_copro_fw=rproc init; rproc load 0 ${kernel_addr_r} ${filesize}; rproc start 0 \0" \ "load_copro_fw=if test -e mmc 0#bootfs ${copro_fw_name};then echo Found Cortex-M FW $copro_fw_name; if load mmc 0#bootfs ${kernel_addr_r} ${copro_fw_name}; then run boot_copro_fw; fi; fi; \0"
Note: It is recommended to check the U-Boot page for compilation on your board.
3.2.2. Start from a generic DISTRO boot script[edit | edit source]
Without U-boot recompilation, you can also use a DISTRO boot script boot.scr.uimg to automatically load and run the firmware.
For example, use the following script boot.scr.cmd to boot from mmc 0 with GPT partition bootfs:
env set copro_fw_name "rproc-copro-fw.elf" env set copro_fw_addr ${kernel_addr_r} # Load Cortex-M firmware with remoteproc if load mmc 0#bootfs ${copro_fw_addr} ${copro_fw_name} then rproc init rproc load 0 ${copro_fw_addr} ${filesize} rproc start 0 fi #load kernel and device tree load mmc 0#bootfs ${kernel_addr_r} uImage load mmc 0#bootfs ${fdt_addr_r} ${board_name}.dtb # start kernel env set bootargs root=/dev/mmcblk0p6 rootwait rw console=ttySTM0,115200 bootm ${kernel_addr_r} - ${fdt_addr_r}
or this one to boot from a nand 0 with UBI mtd partition and boot UBI volume mounted as ubi 0:
# Load Cortex-M firmware with remoteproc env set copro_fw_name "rproc-copro-fw.elf" env set copro_fw_addr ${kernel_addr_r} # mount UBIFS on boot UBI volume is not required: it is already done in DISTRO bootcmd # ubi part UBI # ubifsmount ubi0:boot if load ubi 0 ${copro_fw_addr} ${copro_fw_name} then rproc init rproc load 0 ${copro_fw_addr} ${filesize} rproc start 0 fi #load kernel and device tree load ubi 0 ${kernel_addr_r} uImage load ubi 0 ${fdt_addr_r} ${board_name}.dtb # start kernel env set bootargs ubi.mtd=UBI rootfstype=ubifs root=ubi0:rootfs rootwait rw console=ttySTM0,115200 bootm ${kernel_addr_r} - ${fdt_addr_r}
Then generate the associated image using mkimage U-Boot tool:
mkimage -T script -C none -A arm -d boot.scr.cmd boot.scr.uimg
Lastly, install boot.scr.uimg in the bootfs partition (following the same procedure used for coprocessor firmware)
mount /dev/mmcblk0p6 /boot
cp boot.scr.uimg /boot/
sync
| Information
|
| The name of boot.scr.uimg may be adapted according to your configuration. For example, it may be mmc0_boot.scr.uimg.' The distro variables can be used in script ${devtype} ${devnum}:${distro_bootpart} to identify the boot device and have more generic script |
.
3.2.3. Start from the FIT image[edit | edit source]
For STM32MP15x lines 
, the coprocessor firmware can also be included in the new U-Boot image format, Flattened uImage Tree (FIT) . This firmware is then automatically loaded when it is detected by U-Boot.
Refer to chapter 'Coprocessor firmware' in board/st/stm32mp1.html#coprocessor-firmware-on-stm32mp15x: it contains an example of '.its' file, board/st/stm32mp1/fit_copro_kernel_dtb.its , and shows how to generate the FIT with U-Boot mkimage tool:
mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb
You can load the generated FIT using:
- 'bootm' command (see doc/uImage.FIT/command_syntax_extensions.txt )
- extlinux.conf in bootfs in extlinux directory to automatically load the FIT by generic DISTRO,
for example: {CodeSource | U-Boot | board/st/stm32mp1/extlinux.conf }}
To go deeper, read:
- doc/README.pxe
- doc/uImage.FIT/howto.txt
- support of firmware in FIT is done in board_stm32copro_image_process() function in board/st/stm32mp1/stm32mp1.c associated to image type
IH_TYPE_COPRO.
4. Synchronizing the remote firmware with Linux[edit | edit source]
The STM32MPU Embedded Software distribution provides the ability to detect and manage a firmware loaded by U-Boot thanks to the remoteproc Linux framework.
4.1. STM32Cube[edit | edit source]
The developer must pay attention to how he/she implements the Arm Cortex-M firmware (Arm Cortex-M4 or Arm Cortex-M33), if the RPMsg is used to communicate with Linux. In this case a synchronization is required. The Arm Cortex-M core has to wait until Linux is booted to start RPMsg communications. When Linux is ready, the Linux kernel automatically updates the vdev status in the resource table, and sends a signal to the Arm Cortex-M core using the IPCC peripheral.
Two methods can be implemented to wait for the synchronization:
- Blocking method: the firmware is blocked on MX_OPENAMP_Init call (by the rproc_virtio_wait_remote_ready function) until the Linux kernel is ready to communicate (update of the vdev status in the resource table).
- Non-blocking method: when it is ready to communicate, the Linux kernel generates an interrupt towards the Arm Cortex-M core using the IPCC peripheral. This interrupt can be used by the Arm Cortex-M firmware to initialize the OpenAMP middleware and start the RPMsg protocol.
4.2. Linux kernel[edit | edit source]
On Linux kernel boot, The Linux remoteproc framework is able to detect if a firmware is already running on the Arm Cortex-M of the STM32 Arm® Cortex® MPUs (Arm Cortex-M4 or Arm Cortex-M33). If detected, the remoteproc state is set to "detached".
cat /sys/class/remoteproc/remoteproc0/state detached
- To manually attach to the Cortex-M and start the RPMsg communication, the state has to be updated to "running":
echo start > /sys/class/remoteproc/remoteproc0/state cat /sys/class/remoteproc/remoteproc0/state running
- To automatically attach to the Cortex-M on Linux remoteproc framework probe, add the "st,auto-boot" property (not recommended by STMicroelectronics) in the remote proc node of the Linux kernel device tree, see remote processor 'auto' boot for details.
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.