summaryrefslogtreecommitdiffstats
path: root/drivers/remoteproc/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* remoteproc: add support for starting st,stm32mp1-m4Ahmad Fatoum2019-11-251-0/+1
| | | | | | | | | | | The STM32MP157C-DK2 has a Cortex-M4 MCU in addition to the two Cortex-A7 MPUs. This remoteproc driver allows barebox running on a Cortex-A7 core to bootstrap the MCU with an ELF binary. Code ported from Linux v5.3 with rpmsg bits removed. Signed-off-by: Ahmad Fatoum <ahmad@a3f.at> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* port reduced version of remoteproc framework from linuxOleksij Rempel2019-09-261-0/+7
I tested it on phytec imx7 board with remoteproc ELF image previously used on Linux. Linux would load this image, create appropriate resource (if defined in image) and boot it. The barebox version is only loading image and boot it. Currently barebox version do not extract resources defined by rproc ELF image. On this early stage it is hard to say, if it is needed. Previously there was an attempt to port bootaux command from u-boot. Porting of remoteproc framework is my attempt to lead this topic in to the (IMO) right direction. To start remoteproc image, firmwareload command should be used: firmwareload /mnt/tftp/rproc-imx-rproc-fw Since firmwareload already support multiple targets, it is possible to specify which exact cortex m4 CPU should be started (if multiple CPU are present). This example shows the list of available firmware targets: barebox@Phytec i.MX7 phyBOARD-Zeta:/ firmwareload -l firmware programming handlers: name: model: soc:imx7d-rp0@0.of Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>