remoteproc: add support for starting st,stm32mp1-m4 ...

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>

remoteproc: register a device for new remoteproc instances ...

struct rproc has a device_d dev field, but so far it was unregistered.
The implementation had a few downsides:

- dev_printf prints NULL, because the unique_name of the device is NULL
- The name used by firmwareload is the device tree node's name, which
  might be unnecessarily verbose, e.g. mlahb:m4@10000000.of
- All remoteproc devices are given the same (unused) name and index

Fix these by registering a device for the remoteproc and using it where
appropriate. While at it, allow the remoteproc name to come from a
device tree alias as well.

This breaks user behavior in that firmwareload now uses the alias or
remoteprocN to reference the remoteproc instance. This is probably
acceptable as the driver is a very recent addition.

Cc: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Ahmad Fatoum <ahmad@a3f.at>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

port reduced version of remoteproc framework from linux ...

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>