Difference between revisions of "How to start the coprocessor from the bootloader"

[unchecked revision] [quality revision]
m (Start from a generic DISTRO boot script)
m
 
Applicable for STM32MP15x lines

1 Introduction[edit]

The coprocessor firmware can be loaded and started:

This article explains how the coprocessor firmware is loaded by U-Boot and started before the Linux kernel.

2 Location of the coprocessor firmware[edit]

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-m4-fw.elf /boot/
 sync
Here with TF-A update support, bootfs
it
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-m4-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. Note:

Info white.png Information
The default name of the firmware used in this WIKI is rproc-m4-fw.elf.

3 Starting the coprocessor firmware[edit]

U-Boot can boot the coprocessor before the kernel (coprocessor early boot) with remoteproc uclass . Several methods are possible:

  1. Manual start by using rproc commands
  2. Automatic start, at each boot by using

3.1 Manual start[edit]

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

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

STM32MP> load mmc 0#bootfs ${kernel_addr_r} rproc-m4-fw.elf -> SD card is mmc 0, bootfs partition
STM32MP> rproc init                                        -> initializes all coprocessors
STM32MP> rproc load 0 ${kernel_addr_r} ${filesize}         -> loads firmware for coprocessor 0 (code part found in .elf)
STM32MP> rproc start 0                                     -> starts coprocessor 0

You can then resume the normal boot process:

STM32MP> run bootcmd

3.2 Automatic start[edit]

3.2.1 Start from the bootcmd[edit]

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 \
	"m4fw_name=rproc-m4-fw.elf\0" \
        "m4fw_addr=${kernel_addr_r}\0" \
	"boot_m4fw=rproc init; rproc load 0 ${m4fw_addr} ${filesize}; rproc start 0\0" \
        "boot_m4_mmc0=if load mmc 0#bootfs ${m4fw_addr} ${m4fw_name} ; then run boot_m4fw; fi;\0"
        "bootcmd=run boot_m4_mmc0; run bootcmd_mmc0\0"

Note: It is recommended to check STM32MP15_U-Boot for compilation.

3.2.2 Start from a generic DISTRO boot script[edit]

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 m4fw_name "rproc-m4-fw.elf"
 env set m4fw_addr ${kernel_addr_r}
 
 #load M4 firmware
 if load mmc 0#bootfs ${m4fw_addr} ${m4fw_name}
 then
   rproc init
   rproc load 0 ${m4fw_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:

# M4 Firmware load
env set m4fw_name "rproc-m4-fw.elf"
env set m4fw_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 ${m4fw_addr} ${m4fw_name}
then
   rproc init
   rproc load 0 ${m4fw_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
Info white.png 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
.
Warning white.png Warning
The 'boot.scr.uimg' U-Boot script is executed only if 'extlinux/extlinux.conf' is not found (scan_dev_for_scripts is called after scan_dev_for_extlinux)
You should remove pre-existing file in bootfs partition:
 mount /dev/mmcblk0p6 /boot
 rm -r /boot/extlinux
 sync

3.2.3 Start from the FIT image[edit]

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.

Info white.png Information
Please note that the upstreaming of this example is in progress, only a part of the files are present in the U-boot sources provided by STMicroelectronics

Refer to chapter 'Coprocessor firmware' in board/st/stm32mp1/README : it contains an example of '.its' file, <U-Boot directory>/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:

To go deeper, read:

4 Synchronizing the remote firmware with Linux[edit]

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]

The developer must pay attention to how he/she implements the Arm Cortex-M4 firmware, if the RPMsg is used to communicate with Linux. In this case a synchronization is required. The Arm Cortex-M4 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-M4 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-M4 core using the IPCC peripheral. This interrupt can be used by the Arm Cortex-M4 firmware to initialize the OpenAMP middleware and start the RPMsg protocol.

4.2 Linux kernel[edit]

On Linux kernel boot, The Linux remoteproc framework is able to detect if a firmware is already running on the Cortex-M4. If detected, the remoteproc state is set to "detached".

 cat >/sys/class/remoteproc/remoteproc0/state
detached
  • To manually attach to the Cortex-M4 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
&m4_rproc {
	st,auto-boot = <1>;
};


<noinclude>{{ApplicableFor
|MPUs list=STM32MP15x
|MPUs checklist=STM32MP13x, STM32MP15x
}}</noinclude>

== Introduction ==
The [[Coprocessor_management_overview|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<sup>&reg;</sup> kernel (see [[Linux_remoteproc_framework_overview]] for details)

This article explains how the coprocessor firmware is loaded by [[U-Boot_overview|U-Boot]] and started before the Linux kernel.

== Location of the coprocessor firmware ==

With [[U-Boot_overview#Generic_Distro_configuration|generic DISTRO configuration]], U-Boot searches and loads the required binaries in the first GPT bootable partition for block device, which is {{Highlight|bootfs}} in the  OpenSTLinux distribution, or the {{Highlight|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:'''

 {{Board$}} mount /dev/mmcblk0p{{Highlight|6}} /boot
 {{Board$}} cp rproc-m4-fw.elf /boot/
 {{Board$}} sync
:Here with TF-A update support, bootfs itis the {{Highlight|6th}} partition on SD card. 
To check the partition name,  following commands can be used:
 {{Board$}} ls -l /dev/disk/by-partlabel/

* '''Boot from with UBI mtd partition "boot":'''
 {{Board$}} mount -t ubifs ubi0:boot /mnt
 {{Board$}} cp rproc-m4-fw.elf /mnt/
 {{Board$}} sync
As an alternative method, you can use the Eclipse IDE, or transfer the firmware [[How to transfer a file over serial console|over the serial console]] or [[How to transfer a file over network|over the network]].
''Note: {{Info|The default name of the firmware used in this WIKI is '''rproc-m4-fw.elf'''''.}}


== Starting the coprocessor firmware ==

U-Boot can boot the coprocessor before the kernel (coprocessor early boot) with remoteproc {{CodeSource|U-Boot|doc/driver-model/remoteproc-framework.rst|uclass}}. Several methods are possible:

# [[#Manual start|Manual start]] by using rproc commands
# [[#Automatic start|Automatic start]], at each boot by using 
#* [[#Start from the bootcmd|the bootcmd]] (needing U-Boot recompilation)
#* [[#Start from a generic DISTRO boot script|a generic DISTRO boot script]]
#* [[#Start from the FIT image|the FIT image]]

=== Manual start ===
You can load and start the coprocessor firmware by using the <code>rproc</code> command in the [[U-Boot_overview#U-Boot_command_line_interface_(CLI)|U-Boot console]] (to access to the U-boot console, press any key during the U-Boot execution).

  {{U-Boot$}} 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.

 {{U-Boot$}} load mmc 0#bootfs ${kernel_addr_r} rproc-m4-fw.elf {{Highlight|-> SD card is mmc 0, bootfs partition}}
 {{U-Boot$}} rproc init                                        {{Highlight|-> initializes all coprocessors}}
 {{U-Boot$}} rproc load 0 ${kernel_addr_r} ${filesize}         {{Highlight|-> loads firmware for coprocessor 0 (code part found in .elf)}}
 {{U-Boot$}} rproc start 0                                     {{Highlight|-> starts coprocessor 0}}

You can then resume the normal boot process:
 {{U-Boot$}} run bootcmd

=== Automatic start ===
==== Start from the bootcmd ====
You can update the [[U-Boot_overview#bootcmd|bootcmd]] which is exectued automatically: modify '''CONFIG_EXTRA_ENV_SETTINGS''' in your [[How_to_configure_U-Boot_for_your_board#Configuration_file|Configuration file]] (for example {{CodeSource | U-Boot | include/configs/stm32mp15_st_common.h}} for STM32MP15x STMicroelectronics board) and then [[U-Boot_overview#U-Boot_build|recompile U-Boot]].

For example, to boot a firmware from an SD card, proceed as follows:<pre>

#define CONFIG_EXTRA_ENV_SETTINGS \
	"stdin=serial\0" \
	"stdout=serial\0" \
	"stderr=serial\0" \
	...
	BOOTENV \
	"m4fw_name=rproc-m4-fw.elf\0" \
        "m4fw_addr=${kernel_addr_r}\0" \
	"boot_m4fw=rproc init; rproc load 0 ${m4fw_addr} ${filesize}; rproc start 0\0" \
        "boot_m4_mmc0=if load mmc 0#bootfs ${m4fw_addr} ${m4fw_name} ; then run boot_m4fw; fi;\0"
        "bootcmd=run boot_m4_mmc0; run bootcmd_mmc0\0"</pre>


Note: It is recommended to check [[STM32MP15_U-Boot]] for compilation.

==== Start from a generic DISTRO boot script ====

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 m4fw_name "rproc-m4-fw.elf"
  env set m4fw_addr ${kernel_addr_r}

  #load M4 firmware
  if load mmc 0#bootfs ${m4fw_addr} ${m4fw_name}
  then
    rproc init
    rproc load 0 ${m4fw_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:

 # M4 Firmware load
 env set m4fw_name "rproc-m4-fw.elf"
 env set m4fw_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 ${m4fw_addr} ${m4fw_name}
 then
    rproc init
    rproc load 0 ${m4fw_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:

 {{PC$}} 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 [[#Location of the coprocessor firmware|coprocessor firmware]])

 {{Board$}} mount /dev/mmcblk0p{{Highlight|6}} /boot
 {{Board$}} cp boot.scr.uimg  /boot/
 {{Board$}} sync

{{Info|The name of '''boot.scr.uimg''' may be adapted according to your configuration. For example, it may be '''mmc0_boot.scr.uimg'''.'<br/>The distro variables can be used in script ${devtype} ${devnum}:${distro_bootpart} to identify the boot device and have more generic script}}.

{{Warning|The 'boot.scr.uimg' U-Boot script is executed only if 'extlinux/extlinux.conf' is not found (scan_dev_for_scripts is called after scan_dev_for_extlinux)<br>You should remove pre-existing file in bootfs partition:

 {{Board$}} mount /dev/mmcblk0p{{Highlight|6}} /boot
 {{Board$}} rm -r /boot/extlinux
 {{Board$}} sync
}}

==== Start from the FIT image ====

The coprocessor firmware can also be included in the new U-Boot image format, {{CodeSource | U-Boot | doc/uImage.FIT/ |Flattened uImage Tree (FIT)}}. This firmware is then automatically loaded when it is detected by U-Boot.

{{Info|Please note that the upstreaming of this example is in progress, only a part of the files are present in the U-boot sources provided by STMicroelectronics}}

Refer to chapter 'Coprocessor firmware' in {{CodeSource | U-Boot | board/st/stm32mp1/README}}: it contains an example of '.its' file, <U-Boot directory>/board/st/stm32mp1/fit_copro_kernel_dtb.its, and shows how to generate the FIT with U-Boot mkimage tool:
 {{PC$}} mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb

You can load the generated FIT using:
* 'bootm' command (see {{ CodeSource | U-Boot | doc/uImage.FIT/command_syntax_extensions.txt}})
* extlinux.conf in bootfs in extlinux directory to automatically load the FIT by [[U-Boot_overview#Generic_Distro_configuration|generic DISTRO]],<br/>for example: < U-Boot directory>/board/st/stm32mp1/extlinux.conf

To go deeper, read:
* {{ CodeSource | U-Boot | doc/README.pxe }}
* {{ CodeSource | U-Boot | doc/uImage.FIT/howto.txt }}
* support of firmware in FIT is done in board_stm32copro_image_process() function in {{CodeSource | U-Boot | board/st/stm32mp1/stm32mp1.c}} associated to image type IH_TYPE_STM32COPRO.

== Synchronizing the remote firmware with Linux ==
The [[STM32MPU Embedded Software distribution]] provides the ability to detect and manage a firmware loaded by U-Boot thanks to the [[Linux_remoteproc_framework_overview#Remote_processor_.27early.27_boot | remoteproc]] Linux framework.<BR>


=== STM32Cube ===
The developer must pay attention to how he/she implements the Arm Cortex-M4 firmware, if the RPMsg is used to communicate with Linux. In this case a synchronization is required. The Arm Cortex-M4 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  [[Coprocessor_resource_table | resource table]], and sends a signal to the Arm Cortex-M4 core using the [[IPCC_internal_peripheral | IPCC peripheral]].<BR>

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-M4 core using the [[IPCC_internal_peripheral | IPCC peripheral]]. This interrupt can be used by the Arm Cortex-M4 firmware to initialize the OpenAMP middleware and start the RPMsg protocol.

=== Linux kernel ===
On Linux kernel boot, The [[Linux remoteproc framework overview | Linux remoteproc framework]]  is able to detect if a firmware is already running on the Cortex-M4. If detected, the remoteproc state is set to '''"detached"'''.

 {{Board$}} cat >/sys/class/remoteproc/remoteproc0/state
 detached

* To manually attach to the Cortex-M4 and start the RPMsg communication, the state has to be updated to '''"running"''':
 {{Board$}} echo start > /sys/class/remoteproc/remoteproc0/state
 {{Board$}} cat /sys/class/remoteproc/remoteproc0/state
 running

* To automatically attach to the Cortex-M4 on [[Linux remoteproc framework overview | Linux remoteproc framework]] probe, add the '''"st,auto-boot"''' property in the remote proc node of the Linux kernel [[Device tree|device tree]]:

 &m4_rproc {
 	st,auto-boot = <1>;
 };
<noinclude>

[[Category:How to run use cases]]
[[Category:Coprocessor management STM32Cube]]
[[Category:U-Boot|U-Boot - 9]]
{{PublicationRequestId | 16353| 2020-06-09 | (previous version reviewed by AlainF)}}</noinclude>
Line 14: Line 14:
 
With [[U-Boot_overview#Generic_Distro_configuration|generic DISTRO configuration]], U-Boot searches and loads the required binaries in the first GPT bootable partition for block device, which is {{Highlight|bootfs}} in the  OpenSTLinux distribution, or the {{Highlight|boot}} UBIFS volume in UBI mtd partition (see [[STM32 MPU Flash mapping]]), so the coprocessor firmware must be installed in this partition.
 
With [[U-Boot_overview#Generic_Distro_configuration|generic DISTRO configuration]], U-Boot searches and loads the required binaries in the first GPT bootable partition for block device, which is {{Highlight|bootfs}} in the  OpenSTLinux distribution, or the {{Highlight|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:
+
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:'''
 
  {{Board$}} mount /dev/mmcblk0p{{Highlight|6}} /boot
 
  {{Board$}} mount /dev/mmcblk0p{{Highlight|6}} /boot
 
  {{Board$}} cp rproc-m4-fw.elf /boot/
 
  {{Board$}} cp rproc-m4-fw.elf /boot/
 
  {{Board$}} sync
 
  {{Board$}} sync
   
Here with TF-A update support, bootfs it the {{Highlight|6th}} partition on SD card.
+
:Here with TF-A update support, bootfs is the {{Highlight|6th}} partition on SD card. To check the partition name,  following commands can be used:
  +
{{Board$}} ls -l /dev/disk/by-partlabel/
  +
 
  +
* '''Boot from with UBI mtd partition "boot":'''
  +
{{Board$}} mount -t ubifs ubi0:boot /mnt
  +
{{Board$}} cp rproc-m4-fw.elf /mnt/
  +
{{Board$}} sync
   
 
As an alternative method, you can use the Eclipse IDE, or transfer the firmware [[How to transfer a file over serial console|over the serial console]] or [[How to transfer a file over network|over the network]].
 
As an alternative method, you can use the Eclipse IDE, or transfer the firmware [[How to transfer a file over serial console|over the serial console]] or [[How to transfer a file over network|over the network]].
   
''Note: The default name of the firmware used in this WIKI is '''rproc-m4-fw.elf'''''.
+
{{Info|The default name of the firmware used in this WIKI is '''rproc-m4-fw.elf'''''.}}
   
 
== Starting the coprocessor firmware ==
 
== Starting the coprocessor firmware ==