“How to start the coprocessor from the bootloader”的版本间的差异
(创建页面,内容为“Category:How_to Category:How_to_run_use_cases ”) |
Zhouyuebiao(讨论 | 贡献) |
||
(未显示同一用户的1个中间版本) | |||
第1行: | 第1行: | ||
− | [[Category: | + | == Introduction == |
+ | The [[Coprocessor_management_overview|coprocessor]] firmware can be loaded and started by: | ||
+ | * the second stage boot loader = U-Boot (see [[Boot_chains_overview]] for details) | ||
+ | * the Linux<sup>®</sup> kernel (see [[Linux_remoteproc_framework_overview]] for details) | ||
+ | |||
+ | This article explains how this coprocessor firmware is loaded by [[U-Boot_overview|U-Boot]] and started before the Linux kernel. | ||
+ | {{ReviewsComments|ECO: nowhere the Vitrual UART behavior is decribed when Fw is launched from Uboot. The FW is blocked in OpenAMP_Init function through rproc_virtio_wait_remote_ready(vdev) until the kernel start the TTY}} | ||
+ | == Location of the coprocessor firmware == | ||
+ | ''Note: the default name for this firmware used in this WIKI is '''rproc-m4-fw.elf''''' | ||
+ | |||
+ | U-Boot searches and loads the needed binaries in the first bootable partition ([[U-Boot_overview#Generic_Distro_configuration|generic DISTRO configuration]]) which is '''bootfs''' in the OpenSTLinux distribution (see [[STM32MP15_Flash_mapping]]). | ||
+ | |||
+ | So the coprocessor firmware must be installed in that bootfs partition. The simplest way to do this, consists in copying the firmware from the rootfs partition to the bootfs partition as follows: | ||
+ | {{Board$}} mount /dev/mmcblk0p4 /boot | ||
+ | {{Board$}} cp rproc-m4-fw.elf /boot/ | ||
+ | {{Board$}} sync | ||
+ | |||
+ | As an alternate method, you can also 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]]. | ||
+ | |||
+ | == Starting the coprocessor firmware == | ||
+ | |||
+ | U-Boot can boot the coprocessor before the kernel (coprocessor early boot) with remoteproc {{CodeSource|U-Boot|doc/driver-model/README.txt|uclass}}: | ||
+ | |||
+ | # [[#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]] | ||
+ | |||
+ | {{Info| In the following examples it is assumed that the firmware declares a resource table. If your firmware does not declare such a resource table, you do not need to call the '''load_rsc''' rproc command. }} | ||
+ | |||
+ | === Manual start === | ||
+ | You can load and start the coprocessor firmware by using the '''rproc''' 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). | ||
+ | |||
+ | {{Board$}} 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 are dependent on the driver capability | ||
+ | 'list' command shows the capability of each device | ||
+ | |||
+ | Subcommands: | ||
+ | init - Enumerate and initalize the remote processors | ||
+ | list - list available remote processors | ||
+ | load <id> [addr] [size]- Load the remote processor with | ||
+ | image stored at address [addr] in memory | ||
+ | load_rsc <id> [addr] [size]- Load resource table from remote | ||
+ | processor provided image at address [addr] | ||
+ | start <id> - Start the remote processor(must be loaded) | ||
+ | stop <id> - Stop the remote processor | ||
+ | reset <id> - Reset the remote processor | ||
+ | is_running <id> - Reports if the remote processor is running | ||
+ | ping <id> - Ping the remote processor for communication | ||
+ | |||
+ | In this example, the firmware is loaded from SDCARD in RAM (at ${kernel_addr_r}), and then started | ||
+ | |||
+ | {{Board$}} ext4load mmc 0:4 ${kernel_addr_r} rproc-m4-fw.elf {{Highlight|-> SDCARD is mmc 0, bootfs is ext4 partition number 4)}} | ||
+ | {{Board$}} rproc init {{Highlight|-> initializes all coprocessors}} | ||
+ | {{Board$}} rproc load 0 ${kernel_addr_r} ${filesize} {{Highlight|-> loads firmware for coprocessor 0 (code part found in .elf)}} | ||
+ | {{Board$}} rproc load_rsc 0 ${kernel_addr_r} ${filesize} {{Highlight|-> loads resource table for coprocessor 0 (found in .elf)}} | ||
+ | {{Board$}} rproc start 0 {{Highlight|-> starts coprocessor 0}} | ||
+ | |||
+ | You can then resume the normal boot process: | ||
+ | {{Board$}} 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 {{CodeSource | U-Boot | include/configs/stm32mp1.h}} and then [[U-Boot_overview#U-Boot_build|recompile U-Boot]]. | ||
+ | |||
+ | Example : boot a firmware on the SDCARD: | ||
+ | <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 load_rsc 0 ${m4fw_addr} ${filesize}; rproc start 0\0" \ | ||
+ | "boot_m4_mmc0=if ext4load mmc 0:4 ${m4fw_addr} ${m4fw_name} ; then run boot_m4fw; fi;\0" | ||
+ | "bootcmd=run boot_m4_mmc0; run bootcmd_mmc0\0" | ||
+ | </pre> | ||
+ | |||
+ | NB: check [[STM32MP15_U-Boot]] for compilation. | ||
+ | {{ReviewsComments|--ECO 1/4/2020 What happen with Virtual UART when FW is loaded by Uboot ? | ||
+ | The FW is blocked in MX_OPENAMP_Init until the kernel start | ||
+ | (rproc_virtio_wait_remote_ready() at remoteproc_virtio.c:326) | ||
+ | |||
+ | }} | ||
+ | ==== 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 for boot from mmc 0, '''boot.scr.cmd''': | ||
+ | |||
+ | env set m4fw_name "rproc-m4-fw.elf" | ||
+ | env set m4fw_addr ${kernel_addr_r} | ||
+ | |||
+ | #load M4 firmware | ||
+ | if ext4load mmc 0:4 ${m4fw_addr} ${m4fw_name} | ||
+ | then | ||
+ | rproc init | ||
+ | rproc load 0 ${m4fw_addr} ${filesize} | ||
+ | rproc load_rsc 0 ${m4fw_addr} ${filesize} | ||
+ | rproc start 0 | ||
+ | fi | ||
+ | |||
+ | #load kernel and device tree | ||
+ | ext4load mmc 0:4 ${kernel_addr_r} uImage | ||
+ | ext4load mmc 0:4 ${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} | ||
+ | |||
+ | Then generate associated image using mkimage U-Boot tool: | ||
+ | |||
+ | {{PC$}} mkimage -T script -C none -A arm -d boot.scr.cmd boot.scr.uimg | ||
+ | |||
+ | Finally, install '''boot.scr.uimg''' in the bootfs partition (following the same procedure used for [[#Location of the coprocessor firmware|coprocessor firmware]]) | ||
+ | {{PC$}} sudo cp boot.scr.uimg /media/$USER/bootfs | ||
+ | {{PC$}} sync | ||
+ | |||
+ | {{Warning|The U-Boot script 'boot.scr.uimg' 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:}} | ||
+ | {{PC$}} sudo rm -r /media/$USER/bootfs/extlinux | ||
+ | {{PC$}} sync | ||
+ | |||
+ | ==== Start from the FIT image ==== | ||
+ | |||
+ | The coprocessor firmware can be also included in the new U-Boot image format = {{CodeSource | U-Boot | doc/uImage.FIT/ |Flattened uImage Tree (FIT)}} and then this firmware will be loaded automatically when detected by U-Boot. | ||
+ | |||
+ | {{Info|Please note that the upstreaming of this example is in progress, some files are only present in U-boot sources provided by STMicroelectronics}} | ||
+ | |||
+ | See chapter 'Coprocessor firmware' in {{CodeSource | U-Boot | board/st/stm32mp1/README}}: | ||
+ | * example of '.its' file is provided < U-Boot directory>/board/st/stm32mp1/fit_copro_kernel_dtb.its | ||
+ | * you 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 with: | ||
+ | * '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: | ||
+ | * {{ 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. | ||
+ | |||
+ | <noinclude> | ||
+ | [[Category:How to run use cases]] | ||
+ | [[Category:Coprocessor management STM32Cube]] | ||
+ | [[Category:U-Boot]] | ||
+ | {{PublicationRequestId | 10438 | 2019-01-23 | AlainF}} | ||
+ | {{ReviewsComments|FDE Oct'19 . load rsc_table shall be removed with u-boot 2019 (shall be v2.0.0 release)}} | ||
+ | </noinclude> |
2020年5月6日 (三) 18:09的最新版本
目录
Introduction
The coprocessor firmware can be loaded and started by:
- the second stage boot loader = U-Boot (see Boot_chains_overview for details)
- the Linux® kernel (see Linux_remoteproc_framework_overview for details)
This article explains how this coprocessor firmware is loaded by U-Boot and started before the Linux kernel.
<securetransclude src="ProtectedTemplate:ReviewsComments" params="ECO: nowhere the Vitrual UART behavior is decribed when Fw is launched from Uboot. The FW is blocked in OpenAMP_Init function through rproc_virtio_wait_remote_ready(vdev) until the kernel start the TTY"></securetransclude>{{#set:Has reviews comments=true}}
Location of the coprocessor firmware
Note: the default name for this firmware used in this WIKI is rproc-m4-fw.elf
U-Boot searches and loads the needed binaries in the first bootable partition (generic DISTRO configuration) which is bootfs in the OpenSTLinux distribution (see STM32MP15_Flash_mapping).
So the coprocessor firmware must be installed in that bootfs partition. The simplest way to do this, consists in copying the firmware from the rootfs partition to the bootfs partition as follows:
Board $> mount /dev/mmcblk0p4 /boot Board $> cp rproc-m4-fw.elf /boot/ Board $> sync
As an alternate method, you can also use the Eclipse IDE, or transfer the firmware over the serial console or over the network.
Starting the coprocessor firmware
U-Boot can boot the coprocessor before the kernel (coprocessor early boot) with remoteproc |}} uclass :
- 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
In the following examples it is assumed that the firmware declares a resource table. If your firmware does not declare such a resource table, you do not need to call the load_rsc rproc command. |
Manual start
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).
Board $> 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 are dependent on the driver capability 'list' command shows the capability of each device Subcommands: init - Enumerate and initalize the remote processors list - list available remote processors load <id> [addr] [size]- Load the remote processor with image stored at address [addr] in memory load_rsc <id> [addr] [size]- Load resource table from remote processor provided image at address [addr] start <id> - Start the remote processor(must be loaded) stop <id> - Stop the remote processor reset <id> - Reset the remote processor is_running <id> - Reports if the remote processor is running ping <id> - Ping the remote processor for communication
In this example, the firmware is loaded from SDCARD in RAM (at ${kernel_addr_r}), and then started
Board $> ext4load mmc 0:4 ${kernel_addr_r} rproc-m4-fw.elf -> SDCARD is mmc 0, bootfs is ext4 partition number 4) Board $> rproc init -> initializes all coprocessors Board $> rproc load 0 ${kernel_addr_r} ${filesize} -> loads firmware for coprocessor 0 (code part found in .elf) Board $> rproc load_rsc 0 ${kernel_addr_r} ${filesize} -> loads resource table for coprocessor 0 (found in .elf) Board $> rproc start 0 -> starts coprocessor 0
You can then resume the normal boot process:
Board $> run bootcmd
Automatic start
Start from the bootcmd
You can update the bootcmd which is exectued automatically: modify CONFIG_EXTRA_ENV_SETTINGS in include/configs/stm32mp1.h| |}} include/configs/stm32mp1.h and then recompile U-Boot.
Example : boot a firmware on the SDCARD:
#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 load_rsc 0 ${m4fw_addr} ${filesize}; rproc start 0\0" \ "boot_m4_mmc0=if ext4load mmc 0:4 ${m4fw_addr} ${m4fw_name} ; then run boot_m4fw; fi;\0" "bootcmd=run boot_m4_mmc0; run bootcmd_mmc0\0"
NB: check STM32MP15_U-Boot for compilation. <securetransclude src="ProtectedTemplate:ReviewsComments" params="--ECO 1/4/2020 What happen with Virtual UART when FW is loaded by Uboot ? The FW is blocked in MX_OPENAMP_Init until the kernel start (rproc_virtio_wait_remote_ready() at remoteproc_virtio.c:326)"></securetransclude>{{#set:Has reviews comments=true}}
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 for boot from mmc 0, boot.scr.cmd:
env set m4fw_name "rproc-m4-fw.elf" env set m4fw_addr ${kernel_addr_r} #load M4 firmware if ext4load mmc 0:4 ${m4fw_addr} ${m4fw_name} then rproc init rproc load 0 ${m4fw_addr} ${filesize} rproc load_rsc 0 ${m4fw_addr} ${filesize} rproc start 0 fi #load kernel and device tree ext4load mmc 0:4 ${kernel_addr_r} uImage ext4load mmc 0:4 ${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}
Then generate associated image using mkimage U-Boot tool:
PC $> mkimage -T script -C none -A arm -d boot.scr.cmd boot.scr.uimg
Finally, install boot.scr.uimg in the bootfs partition (following the same procedure used for coprocessor firmware)
PC $> sudo cp boot.scr.uimg /media/$USER/bootfs PC $> sync
The U-Boot script 'boot.scr.uimg' 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: |
PC $> sudo rm -r /media/$USER/bootfs/extlinux PC $> sync
Start from the FIT image
The coprocessor firmware can be also included in the new U-Boot image format = doc/uImage.FIT/ | |}} Flattened uImage Tree (FIT) and then this firmware will be loaded automatically when detected by U-Boot.
Please note that the upstreaming of this example is in progress, some files are only present in U-boot sources provided by STMicroelectronics |
See chapter 'Coprocessor firmware' in board/st/stm32mp1/README| |}} board/st/stm32mp1/README :
- example of '.its' file is provided < U-Boot directory>/board/st/stm32mp1/fit_copro_kernel_dtb.its
- you 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 with:
- 'bootm' command (see doc/uImage.FIT/command_syntax_extensions.txt| |}} doc/uImage.FIT/command_syntax_extensions.txt )
- extlinux.conf in bootfs in extlinux directory to automatically load the FIT by generic DISTRO,
for example: < U-Boot directory>/board/st/stm32mp1/extlinux.conf
To go deeper:
- doc/README.pxe | |}} doc/README.pxe
- doc/uImage.FIT/howto.txt | |}} doc/uImage.FIT/howto.txt
- support of firmware in FIT is done in board_stm32copro_image_process() function in board/st/stm32mp1/stm32mp1.c| |}} board/st/stm32mp1/stm32mp1.c associated to image type IH_TYPE_STM32COPRO.
<securetransclude src="ProtectedTemplate:PublicationRequestId" params="10438 | 2019-01-23 | AlainF"></securetransclude> <securetransclude src="ProtectedTemplate:ReviewsComments" params="FDE Oct'19 . load rsc_table shall be removed with u-boot 2019 (shall be v2.0.0 release)"></securetransclude>{{#set:Has reviews comments=true}}