Merge branch 'master' of git://git.denx.de/u-boot

6 files changed, 345 insertions, 26 deletions

diff --git a/doc/README.scrapyard b/doc/README.scrapyard
index c7b4fa3..2760f60 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -12,15 +12,86 @@ The list should be sorted in reverse chronological order.
 
 Board            Arch        CPU            Commit      Removed     Last known maintainer/contact
 =================================================================================================
-stxgp3           powerpc     mpc85xx        -           -           Dan Malek <dan@embeddedalley.com>
-stxssa           powerpc     mpc85xx        -           -           Dan Malek <dan@embeddedalley.com>
-cmi_mpc5xx       powerpc     mpc5xx         -           -
-zeus             powerpc     ppc4xx         -           -           Stefan Roese <sr@denx.de>
-sbc405           powerpc     ppc4xx         -           -
-pcs440ep         powerpc     ppc4xx         -           -           Stefan Roese <sr@denx.de>
-p3p440           powerpc     ppc4xx         -           -           Stefan Roese <sr@denx.de>
-csb272/csb472    powerpc     ppc4xx         -           -           Tolunay Orkun <torkun@nextio.com>
-alpr             powerpc     ppc4xx         -           -           Stefan Roese <sr@denx.de>
+lcd4_lwmon5      powerpc     ppc4xx         b6b5e394    2015-10-02  Stefan Roese <sr@denx.de>
+da830evm         arm         arm926ejs      d7e8b2b9    2015-09-12  Nick Thompson <nick.thompson@gefanuc.com>
+wireless_space   arm         arm926ejs      b352182a    2015-09-12  Albert ARIBAUD <albert.u.boot@aribaud.net>
+stxgp3           powerpc     mpc85xx        2ec69b88    2015-09-02  Dan Malek <dan@embeddedalley.com>
+stxssa           powerpc     mpc85xx        2ec69b88    2015-09-02  Dan Malek <dan@embeddedalley.com>
+cmi_mpc5xx       powerpc     mpc5xx         972f5320    2015-09-02
+zeus             powerpc     ppc4xx         eb5d1dc7    2015-09-02  Stefan Roese <sr@denx.de>
+sbc405           powerpc     ppc4xx         0e030593    2015-09-02
+pcs440ep         powerpc     ppc4xx         242836a8    2015-09-02  Stefan Roese <sr@denx.de>
+p3p440           powerpc     ppc4xx         c6999e5f    2015-09-02  Stefan Roese <sr@denx.de>
+csb272/csb472    powerpc     ppc4xx         54a3f260    2015-09-02  Tolunay Orkun <torkun@nextio.com>
+alpr             powerpc     ppc4xx         0d2fc811    2015-09-02  Stefan Roese <sr@denx.de>
+balloon3         arm         pxa            679d4456    2015-08-30  Marek Vasut <marex@denx.de>
+cpu9260_128M     arm         arm926ejs      af7f884b    2015-08-30  Eric Benard <eric@eukrea.com>
+cpu9260          arm         arm926ejs      af7f884b    2015-08-30  Eric Benard <eric@eukrea.com>
+cpu9260_nand_128M arm        arm926ejs      af7f884b    2015-08-30  Eric Benard <eric@eukrea.com>
+cpu9260_nand     arm         arm926ejs      af7f884b    2015-08-30  Eric Benard <eric@eukrea.com>
+cpu9G20_128M     arm         arm926ejs      af7f884b    2015-08-30  Eric Benard <eric@eukrea.com>
+cpu9G20          arm         arm926ejs      af7f884b    2015-08-30  Eric Benard <eric@eukrea.com>
+cpuat91          arm         arm920t        af7f884b    2015-08-30  Eric Benard <eric@eukrea.com>
+cpuat91_ram      arm         arm920t        af7f884b    2015-08-30  Eric Benard <eric@eukrea.com>
+davinci_dm355evm arm         arm926ejs      6761946f    2015-08-30
+davinci_dm355leopard arm     arm926ejs      6761946f    2015-08-30
+davinci_dm365evm arm         arm926ejs      6761946f    2015-08-30
+davinci_dm6467evm arm        arm926ejs      6761946f    2015-08-30
+davinci_dm6467Tevm arm       arm926ejs      6761946f    2015-08-30
+davinci_dvevm    arm         arm926ejs      6761946f    2015-08-30
+davinci_schmoogie arm        arm926ejs      6761946f    2015-08-30
+davinci_sffsdr   arm         arm926ejs      6761946f    2015-08-30
+davinci_sonata   arm         arm926ejs      6761946f    2015-08-30
+dig297           arm         armv7          5ff33d04    2015-08-30  Luca Ceresoli <luca.ceresoli@comelit.it>
+ea20             arm         arm926ejs      6761946f    2015-08-30
+eb_cpux9k2       arm         arm920t        5522f12b    2015-08-30  Jens Scharsig <esw@bus-elektronik.de>
+eb_cpux9k2_ram   arm         arm920t        5522f12b    2015-08-30  Jens Scharsig <esw@bus-elektronik.de>
+enbw_cmc         arm         arm926ejs      a6f7f787    2015-08-30  Heiko Schocher <hs@denx.de>
+ima3-mx53        arm         armv7          3eb8f58d    2015-08-30
+imx27lite        arm         arm926ejs      bc0840bc    2015-08-30  Wolfgang Denk <wd@denx.de>
+imx31_litekit    arm         arm1136        36d14178    2015-08-30
+jornada          arm         sa1100         df0b116d    2015-08-30  Kristoffer Ericson <kristoffer.ericson@gmail.com>
+lp8x4x           arm         pxa            9f840b8d    2015-08-30  Sergey Yanovich <ynvich@gmail.com>
+magnesium        arm         arm926ejs      bc0840bc    2015-08-30  Heiko Schocher <hs@denx.de>
+mv88f6281gtw_ge  arm         arm926ejs      7cd768cf    2015-08-30  Prafulla Wadaskar <prafulla@marvell.com>
+mx51_efikamx     arm         armv7          b6073fd2    2015-08-30
+mx51_efikasb     arm         armv7          b6073fd2    2015-08-30
+nhk8815          arm         arm926ejs      0abdd9d0    2015-08-30  Nomadik Linux Team <STN_WMM_nomadik_linux@list.st.com>
+nhk8815_onenand  arm         arm926ejs      0abdd9d0    2015-08-30  Nomadik Linux Team <STN_WMM_nomadik_linux@list.st.com>
+omap3_mvblx      arm         armv7          8dc372f9    2015-08-30  Michael Jones <michael.jones@matrix-vision.de>
+omap3_sdp3430    arm         armv7          93b25c08    2015-08-30  Nishanth Menon <nm@ti.com>
+openrd_base      arm         arm926ejs      7a2c1b13    2015-08-30  Prafulla Wadaskar <prafulla@marvell.com>
+openrd_client    arm         arm926ejs      7a2c1b13    2015-08-30  Prafulla Wadaskar <prafulla@marvell.com>
+openrd_ultimate  arm         arm926ejs      7a2c1b13    2015-08-30  Prafulla Wadaskar <prafulla@marvell.com>
+otc570           arm         arm926ejs      819216dd    2015-08-30  Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
+otc570_dataflash arm         arm926ejs      819216dd    2015-08-30  Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
+palmld           arm         pxa            35782e9c    2015-08-30  Marek Vasut <marex@denx.de>
+palmtc           arm         pxa            8896325d    2015-08-30  Marek Vasut <marex@denx.de>
+palmtreo680      arm         pxa            ad4f54ea    2015-08-30  Mike Dunn <mikedunn@newsguy.com>
+polaris          arm         pxa            f6eac00a    2015-08-30  Stefano Babic <sbabic@denx.de>
+portuxg20        arm         arm926ejs      79d19734    2015-08-30  Markus Hubig <mhubig@imko.de>
+pxa255_idp       arm         pxa            49d8899b    2015-08-30  Marek Vasut <marex@denx.de>
+qong             arm         arm1136        daf77086    2015-08-30  Wolfgang Denk <wd@denx.de>
+rd6281a          arm         arm926ejs      47b87d2e    2015-08-30  Prafulla Wadaskar <prafulla@marvell.com>
+scb9328          arm         arm920t        7650beb7    2015-08-30  Torsten Koschorrek <koschorrek@synertronixx.de>
+snowball         arm         armv7          7495e41b    2015-08-30  Mathieu Poirier <mathieu.poirier@linaro.org>
+stamp9g20        arm         arm926ejs      79d19734    2015-08-30  Markus Hubig <mhubig@imko.de>
+tk71             arm         arm926ejs      f73db66d    2015-08-30
+trizepsiv        arm         pxa            f6eac00a    2015-08-30  Stefano Babic <sbabic@denx.de>
+tt01             arm         arm1136        0c81f37d    2015-08-30  Helmut Raiger <helmut.raiger@hale.at>
+tx25             arm         arm926ejs      b9599dd8    2015-08-30  John Rigby <jcrigby@gmail.com>
+u8500_href       arm         armv7          7495e41b    2015-08-30
+versatileab      arm         arm926ejs      b928e658    2015-08-30
+versatilepb      arm         arm926ejs      b928e658    2015-08-30
+versatileqemu    arm         arm926ejs      b928e658    2015-08-30
+vision2          arm         armv7          bee2b99d    2015-08-30  Stefano Babic <sbabic@denx.de>
+vl_ma2sc         arm         arm926ejs      6e830dfc    2015-08-30  Jens Scharsig <esw@bus-elektronik.de>
+vl_ma2sc_ram     arm         arm926ejs      6e830dfc    2015-08-30  Jens Scharsig <esw@bus-elektronik.de>
+vpac270_nor_128  arm         pxa            452ef830    2015-08-30  Marek Vasut <marex@denx.de>
+vpac270_nor_256  arm         pxa            452ef830    2015-08-30  Marek Vasut <marex@denx.de>
+vpac270_ond_256  arm         pxa            452ef830    2015-08-30  Marek Vasut <marex@denx.de>
+xaeniax          arm         pxa            1c87dd76    2015-08-30
+zipitz2          arm         pxa            49d8899b    2015-08-30  Cliff Brake <cliff.brake@gmail.com>
 cam_enc_4xx      arm         arm926ejs      8d775763    2015-08-20  Heiko Schocher <hs@denx.de>
 atstk1003        avr32       -              e5354b8a    2015-06-10  Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
 atstk1004        avr32       -              e5354b8a    2015-06-10  Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
diff --git a/doc/README.uniphier b/doc/README.uniphier
index 6ba0320..57b947b 100644
--- a/doc/README.uniphier
+++ b/doc/README.uniphier
@@ -129,10 +129,10 @@ as follows:
 
  BKSZ    Description              RAM slot            Peripherals
  --------------------------------------------------------------------
- 0b00   15MB RAM / 1MB Peri    00000000-0effffff    0f000000-0fffffff
- 0b01   31MB RAM / 1MB Peri    00000000-1effffff    1f000000-1fffffff
- 0b10   64MB RAM / 1MB Peri    00000000-3effffff    3f000000-3fffffff
- 0b11  127MB RAM / 1MB Peri    00000000-7effffff    7f000000-7fffffff
+ 0b00   15MB RAM / 1MB Peri    00000000-00efffff    00f00000-00ffffff
+ 0b01   31MB RAM / 1MB Peri    00000000-01efffff    01f00000-01ffffff
+ 0b10   64MB RAM / 1MB Peri    00000000-03efffff    03f00000-03ffffff
+ 0b11  127MB RAM / 1MB Peri    00000000-07efffff    07f00000-07ffffff
 
 Set BSKZ[1:0] to 0b01 for U-Boot.
 This mode is the most handy because EA[24] is always supported by the save pin
diff --git a/doc/README.vxworks b/doc/README.vxworks
index 4cb302e..3433e4f 100644
--- a/doc/README.vxworks
+++ b/doc/README.vxworks
@@ -1,19 +1,85 @@
-From VxWorks 6.9+ (not include 6.9), VxWorks starts adopting device tree as its hardware
-decription mechansim (for PowerPC and ARM), thus requiring boot interface changes.
+#
+# Copyright (C) 2013, Miao Yan <miao.yan@windriver.com>
+# Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+VxWorks Support
+===============
+
+This document describes the information about U-Boot loading VxWorks kernel.
+
+Status
+------
+U-Boot supports loading VxWorks kernels via 'bootvx' and 'bootm' commands.
+For booting old kernels (6.9.x) on PowerPC and ARM, and all kernel versions
+on other architectures, 'bootvx' shall be used. For booting VxWorks 7 kernels
+on PowerPC and ARM, 'bootm' shall be used.
+
+64-bit x86 kernel cannot be loaded as of today.
+
+VxWork 7 on PowerPC and ARM
+---------------------------
+From VxWorks 7, VxWorks starts adopting device tree as its hardware decription
+mechansim (for PowerPC and ARM), thus requiring boot interface changes.
 This section will describe the new interface.
 
-For PowerPC, the calling convention of the new VxWorks entry point conforms to the ePAPR standard,
-which is shown below (see ePAPR for more details):
+For PowerPC, the calling convention of the new VxWorks entry point conforms to
+the ePAPR standard, which is shown below (see ePAPR for more details):
 
-    void (*kernel_entry)(fdt_addr,
-              0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
+    void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
 
 For ARM, the calling convention is show below:
 
     void (*kernel_entry)(void *fdt_addr)
 
-When booting new VxWorks kernel (uImage format), the parameters passed to bootm is like below:
+When booting new VxWorks kernel (uImage format), the parameters passed to bootm
+is like below:
 
     bootm <kernel image address> - <device tree address>
 
-The do_bootvx command still works as it was for older VxWorks kernels.
+VxWorks bootline
+----------------
+When using 'bootvx', the kernel bootline must be prepared by U-Boot at a
+board-specific address before loading VxWorks. U-Boot supplies its address
+via "bootaddr" environment variable. To check where the bootline should be
+for a specific board, go to the VxWorks BSP for that board, and look for a
+parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr". A typical
+value for "bootaddr" is 0x101200.
+
+If a "bootargs" variable is defined, its content will be copied to the memory
+location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not
+there, command 'bootvx' can construct a valid bootline using the following
+environments variables: bootdev, bootfile, ipaddr, netmask, serverip,
+gatewayip, hostname, othbootargs.
+
+When using 'bootm', just define "bootargs" in the environment and U-Boot will
+handle bootline fix up for the kernel dtb automatically.
+
+Serial console
+--------------
+It's very common that VxWorks BSPs configure a different baud rate for the
+serial console from what is being used by U-Boot. For example, VxWorks tends
+to use 9600 as the default baud rate on all x86 BSPs while U-Boot uses 115200.
+Please configure both U-Boot and VxWorks to use the same baud rate, or it may
+look like VxWorks hangs somewhere as nothing outputs on the serial console.
+
+x86-specific information
+------------------------
+Before loading an x86 kernel, two additional environment variables need to be
+provided. They are "e820data" and "e820info", which represent the address of
+E820 table and E820 information (defined by VxWorks) in system memory.
+
+Check VxWorks kernel configuration to look for BIOS_E820_DATA_START and
+BIOS_E820_INFO_START, and assign their values to "e820data" and "e820info"
+accordingly. If neither of these two are supplied, U-Boot assumes a default
+location at 0x4000 for "e820data" and 0x4a00 for "e820info". Typical values
+for "e820data" and "e820info" are 0x104000 and 0x104a00. But there is one
+exception on Intel Galileo, where "e820data" and "e820info" should be left
+unset, which assume the default location for VxWorks.
+
+Note since currently U-Boot does not support ACPI yet, VxWorks kernel must
+be configured to use MP table and virtual wire interrupt mode. This requires
+INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a
+VxWorks kernel configuration.
diff --git a/doc/README.x86 b/doc/README.x86
index 6cf293b..1271e5e 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -25,6 +25,8 @@ targets and all Intel boards support running U-Boot 'bare metal'.
 
 As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
 Linux kernel as part of a FIT image. It also supports a compressed zImage.
+U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks
+for more details.
 
 Build Instructions for U-Boot as coreboot payload
 -------------------------------------------------
@@ -188,6 +190,7 @@ Offset   Description         Controlling config
 000000   descriptor.bin      Hard-coded to 0 in ifdtool
 001000   me.bin              Set by the descriptor
 500000   <spare>
+6f0000   MRC cache           CONFIG_ENABLE_MRC_CACHE
 700000   u-boot-dtb.bin      CONFIG_SYS_TEXT_BASE
 790000   vga.bin             CONFIG_VGA_BIOS_ADDR
 7c0000   fsp.bin             CONFIG_FSP_ADDR
@@ -330,9 +333,8 @@ In keeping with the U-Boot philosophy of providing functions to check and
 adjust internal settings, there are several x86-specific commands that may be
 useful:
 
-hob  - Display information about Firmware Support Package (FSP) Hand-off
-	 Block. This is only available on platforms which use FSP, mostly
-	 Atom.
+fsp  - Display information about Intel Firmware Support Package (FSP).
+	 This is only available on platforms which use FSP, mostly Atom.
 iod  - Display I/O memory
 iow  - Write I/O memory
 mtrr - List and set the Memory Type Range Registers (MTRR). These are used to
@@ -762,7 +764,6 @@ TODO List
 - Audio
 - Chrome OS verified boot
 - SMI and ACPI support, to provide platform info and facilities to Linux
-- Desktop Management Interface (DMI) [15] support
 
 References
 ----------
@@ -780,4 +781,3 @@ References
 [12] http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf
 [13] http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf
 [14] doc/device-tree-bindings/misc/intel,irq-router.txt
-[15] http://en.wikipedia.org/wiki/Desktop_Management_Interface
diff --git a/doc/device-tree-bindings/remoteproc/remoteproc.txt b/doc/device-tree-bindings/remoteproc/remoteproc.txt
new file mode 100644
index 0000000..031764f
--- /dev/null
+++ b/doc/device-tree-bindings/remoteproc/remoteproc.txt
@@ -0,0 +1,14 @@
+Remote Processor uclass
+
+Binding:
+
+Remoteproc devices shall have compatible corresponding to thier
+drivers. However the following generic properties will be supported
+
+Optional Properties:
+- remoteproc-name: a string, used if provided to describe the processor.
+  This must be unique in an operational system.
+- remoteproc-internal-memory-mapped: a bool, indicates that the remote
+  processor has internal memory that it uses to execute code and store
+  data. Such a device is not expected to have a MMU. If no type property
+  is provided, the device is assumed to map to such a model.
diff --git a/doc/driver-model/remoteproc-framework.txt b/doc/driver-model/remoteproc-framework.txt
new file mode 100644
index 0000000..094e98b
--- /dev/null
+++ b/doc/driver-model/remoteproc-framework.txt
@@ -0,0 +1,168 @@
+#
+# (C) Copyright 2015
+# Texas Instruments Incorporated - http://www.ti.com/
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+Remote Processor Framework
+==========================
+TOC:
+1. Introduction
+2. How does it work - The driver
+3. Describing the device using platform data
+4. Describing the device using device tree
+
+1. Introduction
+===============
+
+This is an introduction to driver-model for Remote Processors found
+on various System on Chip(SoCs). The term remote processor is used to
+indicate that this is not the processor on which U-Boot is operating
+on, instead is yet another processing entity that may be controlled by
+the processor on which we are functional.
+
+The simplified model depends on a single UCLASS - UCLASS_REMOTEPROC
+
+UCLASS_REMOTEPROC:
+- drivers/remoteproc/rproc-uclass.c
+- include/remoteproc.h
+
+Commands:
+- common/cmd_remoteproc.c
+
+Configuration:
+CONFIG_REMOTEPROC is selected by drivers as needed
+CONFIG_CMD_REMOTEPROC for the commands if required.
+
+2. How does it work - The driver
+=================================
+
+Overall, the driver statemachine transitions are typically as follows:
+        (entry)
+        +-------+
+    +---+ init  |
+    |   |       | <---------------------+
+    |   +-------+                       |
+    |                                   |
+    |                                   |
+    |   +--------+                      |
+Load|   |  reset |                      |
+    |   |        | <----------+         |
+    |   +--------+            |         |
+    |        |Load            |         |
+    |        |                |         |
+    |   +----v----+   reset   |         |
+    +-> |         |    (opt)  |         |
+        |  Loaded +-----------+         |
+        |         |                     |
+        +----+----+                     |
+             | Start                    |
+         +---v-----+        (opt)       |
+      +->| Running |        Stop        |
+Ping  +- |         +--------------------+
+(opt)    +---------+
+
+(is_running does not change state)
+opt: Optional state transition implemented by driver.
+
+NOTE: It depends on the remote processor as to the exact behavior
+of the statemachine, remoteproc core does not intent to implement
+statemachine logic. Certain processors may allow start/stop without
+reloading the image in the middle, certain other processors may only
+allow us to start the processor(image from a EEPROM/OTP) etc.
+
+It is hence the responsibility of the driver to handle the requisite
+state transitions of the device as necessary.
+
+Basic design assumptions:
+
+Remote processor can operate on a certain firmware that maybe loaded
+and released from reset.
+
+The driver follows a standard UCLASS DM.
+
+in the bare minimum form:
+
+static const struct dm_rproc_ops sandbox_testproc_ops = {
+	.load = sandbox_testproc_load,
+	.start = sandbox_testproc_start,
+};
+
+static const struct udevice_id sandbox_ids[] = {
+	{.compatible = "sandbox,test-processor"},
+	{}
+};
+
+U_BOOT_DRIVER(sandbox_testproc) = {
+	.name = "sandbox_test_proc",
+	.of_match = sandbox_ids,
+	.id = UCLASS_REMOTEPROC,
+	.ops = &sandbox_testproc_ops,
+	.probe = sandbox_testproc_probe,
+};
+
+This allows for the device to be probed as part of the "init" command
+or invocation of 'rproc_init()' function as the system dependencies define.
+
+The driver is expected to maintain it's own statemachine which is
+appropriate for the device it maintains. It must, at the very least
+provide a load and start function. We assume here that the device
+needs to be loaded and started, else, there is no real purpose of
+using the remoteproc framework.
+
+3. Describing the device using platform data
+============================================
+
+*IMPORTANT* NOTE: THIS SUPPORT IS NOT MEANT FOR USE WITH NEWER PLATFORM
+SUPPORT. THIS IS ONLY FOR LEGACY DEVICES. THIS MODE OF INITIALIZATION
+*WILL* BE EVENTUALLY REMOVED ONCE ALL NECESSARY PLATFORMS HAVE MOVED
+TO DM/FDT.
+
+Considering that many platforms are yet to move to device-tree model,
+a simplified definition of a device is as follows:
+
+struct dm_rproc_uclass_pdata proc_3_test = {
+	.name = "proc_3_legacy",
+	.mem_type = RPROC_INTERNAL_MEMORY_MAPPED,
+	.driver_plat_data = &mydriver_data;
+};
+
+U_BOOT_DEVICE(proc_3_demo) = {
+	.name = "sandbox_test_proc",
+	.platdata = &proc_3_test,
+};
+
+There can be additional data that may be desired depending on the
+remoteproc driver specific needs (for example: SoC integration
+details such as clock handle or something similar). See appropriate
+documentation for specific remoteproc driver for further details.
+These are passed via driver_plat_data.
+
+3. Describing the device using device tree
+==========================================
+/ {
+	...
+	aliases {
+		...
+		remoteproc0 = &rproc_1;
+		remoteproc1 = &rproc_2;
+
+	};
+	...
+
+	rproc_1: rproc@1 {
+		compatible = "sandbox,test-processor";
+		remoteproc-name = "remoteproc-test-dev1";
+	};
+
+	rproc_2: rproc@2 {
+		compatible = "sandbox,test-processor";
+		internal-memory-mapped;
+		remoteproc-name = "remoteproc-test-dev2";
+	};
+	...
+};
+
+aliases usage is optional, but it is usually recommended to ensure the
+users have a consistent usage model for a platform.
+the compatible string used here is specific to the remoteproc driver involved.