* [U-Boot] [PATCH v2 01/26] dm: core: Add a function to count the children of a device
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 02/26] remoteproc: ops: Add elf section size as input parameter to device_to_virt api Lokesh Vutla
` (24 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
Add a function to count the available children of a device.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/core/device.c | 11 +++++++++++
include/dm/device.h | 9 +++++++++
test/dm/bus.c | 41 +++++++++++++++--------------------------
3 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 474c1642ee..beff52009d 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -565,6 +565,17 @@ int device_get_child(struct udevice *parent, int index, struct udevice **devp)
return -ENODEV;
}
+int device_get_child_count(struct udevice *parent)
+{
+ struct udevice *dev;
+ int count = 0;
+
+ list_for_each_entry(dev, &parent->child_head, sibling_node)
+ count++;
+
+ return count;
+}
+
int device_find_child_by_seq(struct udevice *parent, int seq_or_req_seq,
bool find_req_seq, struct udevice **devp)
{
diff --git a/include/dm/device.h b/include/dm/device.h
index 27a6d7b9fd..7e2a097de2 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -404,6 +404,15 @@ const char *dev_get_uclass_name(const struct udevice *dev);
*/
int device_get_child(struct udevice *parent, int index, struct udevice **devp);
+/**
+ * device_get_child_count() - Get the available child count of a device
+ *
+ * Returns the number of children to a device.
+ *
+ * @parent: Parent device to check
+ */
+int device_get_child_count(struct udevice *parent);
+
/**
* device_find_child_by_seq() - Find a child device based on a sequence
*
diff --git a/test/dm/bus.c b/test/dm/bus.c
index 93f3acd430..1ad45adb60 100644
--- a/test/dm/bus.c
+++ b/test/dm/bus.c
@@ -8,6 +8,7 @@
#include <os.h>
#endif
#include <dm.h>
+#include <dm/device.h>
#include <dm/device-internal.h>
#include <dm/test.h>
#include <dm/uclass-internal.h>
@@ -371,7 +372,6 @@ static int test_bus_parent_platdata(struct unit_test_state *uts)
{
struct dm_test_parent_platdata *plat;
struct udevice *bus, *dev;
- int child_count;
/* Check that the bus has no children */
ut_assertok(uclass_find_device(UCLASS_TEST_BUS, 0, &bus));
@@ -380,7 +380,7 @@ static int test_bus_parent_platdata(struct unit_test_state *uts)
ut_assertok(uclass_get_device(UCLASS_TEST_BUS, 0, &bus));
- for (device_find_first_child(bus, &dev), child_count = 0;
+ for (device_find_first_child(bus, &dev);
dev;
device_find_next_child(&dev)) {
/* Check that platform data is allocated */
@@ -399,22 +399,20 @@ static int test_bus_parent_platdata(struct unit_test_state *uts)
ut_asserteq_ptr(plat, dev_get_parent_platdata(dev));
ut_asserteq(1, plat->count);
ut_assertok(device_probe(dev));
- child_count++;
}
- ut_asserteq(3, child_count);
+ ut_asserteq(3, device_get_child_count(bus));
/* Removing the bus should also have no effect (it is still bound) */
device_remove(bus, DM_REMOVE_NORMAL);
- for (device_find_first_child(bus, &dev), child_count = 0;
+ for (device_find_first_child(bus, &dev);
dev;
device_find_next_child(&dev)) {
/* Check that platform data is allocated */
plat = dev_get_parent_platdata(dev);
ut_assert(plat != NULL);
ut_asserteq(1, plat->count);
- child_count++;
}
- ut_asserteq(3, child_count);
+ ut_asserteq(3, device_get_child_count(bus));
/* Unbind all the children */
do {
@@ -425,16 +423,15 @@ static int test_bus_parent_platdata(struct unit_test_state *uts)
/* Now the child platdata should be removed and re-added */
device_probe(bus);
- for (device_find_first_child(bus, &dev), child_count = 0;
+ for (device_find_first_child(bus, &dev);
dev;
device_find_next_child(&dev)) {
/* Check that platform data is allocated */
plat = dev_get_parent_platdata(dev);
ut_assert(plat != NULL);
ut_asserteq(0, plat->count);
- child_count++;
}
- ut_asserteq(3, child_count);
+ ut_asserteq(3, device_get_child_count(bus));
return 0;
}
@@ -480,19 +477,17 @@ static int dm_test_bus_child_post_bind(struct unit_test_state *uts)
{
struct dm_test_parent_platdata *plat;
struct udevice *bus, *dev;
- int child_count;
ut_assertok(uclass_get_device(UCLASS_TEST_BUS, 0, &bus));
- for (device_find_first_child(bus, &dev), child_count = 0;
+ for (device_find_first_child(bus, &dev);
dev;
device_find_next_child(&dev)) {
/* Check that platform data is allocated */
plat = dev_get_parent_platdata(dev);
ut_assert(plat != NULL);
ut_asserteq(1, plat->bind_flag);
- child_count++;
}
- ut_asserteq(3, child_count);
+ ut_asserteq(3, device_get_child_count(bus));
return 0;
}
@@ -503,19 +498,17 @@ static int dm_test_bus_child_post_bind_uclass(struct unit_test_state *uts)
{
struct dm_test_parent_platdata *plat;
struct udevice *bus, *dev;
- int child_count;
ut_assertok(uclass_get_device(UCLASS_TEST_BUS, 0, &bus));
- for (device_find_first_child(bus, &dev), child_count = 0;
+ for (device_find_first_child(bus, &dev);
dev;
device_find_next_child(&dev)) {
/* Check that platform data is allocated */
plat = dev_get_parent_platdata(dev);
ut_assert(plat != NULL);
ut_asserteq(2, plat->uclass_bind_flag);
- child_count++;
}
- ut_asserteq(3, child_count);
+ ut_asserteq(3, device_get_child_count(bus));
return 0;
}
@@ -529,14 +522,13 @@ DM_TEST(dm_test_bus_child_post_bind_uclass,
static int dm_test_bus_child_pre_probe_uclass(struct unit_test_state *uts)
{
struct udevice *bus, *dev;
- int child_count;
/*
* See testfdt_drv_probe() which effectively checks that the uclass
* flag is set before that method is called
*/
ut_assertok(uclass_get_device(UCLASS_TEST_BUS, 0, &bus));
- for (device_find_first_child(bus, &dev), child_count = 0;
+ for (device_find_first_child(bus, &dev);
dev;
device_find_next_child(&dev)) {
struct dm_test_priv *priv = dev_get_priv(dev);
@@ -549,9 +541,8 @@ static int dm_test_bus_child_pre_probe_uclass(struct unit_test_state *uts)
ut_assert(priv != NULL);
ut_asserteq(1, priv->uclass_flag);
ut_asserteq(1, priv->uclass_total);
- child_count++;
}
- ut_asserteq(3, child_count);
+ ut_asserteq(3, device_get_child_count(bus));
return 0;
}
@@ -565,14 +556,13 @@ DM_TEST(dm_test_bus_child_pre_probe_uclass,
static int dm_test_bus_child_post_probe_uclass(struct unit_test_state *uts)
{
struct udevice *bus, *dev;
- int child_count;
/*
* See testfdt_drv_probe() which effectively initializes that
* the uclass postp flag is set to a value
*/
ut_assertok(uclass_get_device(UCLASS_TEST_BUS, 0, &bus));
- for (device_find_first_child(bus, &dev), child_count = 0;
+ for (device_find_first_child(bus, &dev);
dev;
device_find_next_child(&dev)) {
struct dm_test_priv *priv = dev_get_priv(dev);
@@ -584,9 +574,8 @@ static int dm_test_bus_child_post_probe_uclass(struct unit_test_state *uts)
priv = dev_get_priv(dev);
ut_assert(priv != NULL);
ut_asserteq(0, priv->uclass_postp);
- child_count++;
}
- ut_asserteq(3, child_count);
+ ut_asserteq(3, device_get_child_count(bus));
return 0;
}
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 02/26] remoteproc: ops: Add elf section size as input parameter to device_to_virt api
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
2019-09-04 10:31 ` [U-Boot] [PATCH v2 01/26] dm: core: Add a function to count the children of a device Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-09-04 15:04 ` Fabien DESSENNE
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 03/26] remoteproc: elf_loader: Always check the validity of the image before loading Lokesh Vutla
` (23 subsequent siblings)
25 siblings, 2 replies; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
Introduce a new parameter "size" that accepts size of the region to
remoteproc ops callback device_to_virt(). This can enforce more checks
on the region that device_to_virt() is dealing with.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/remoteproc/rproc-elf-loader.c | 3 ++-
drivers/remoteproc/sandbox_testproc.c | 4 +++-
drivers/remoteproc/stm32_copro.c | 12 ++++++++++--
include/remoteproc.h | 3 ++-
4 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
index 67937a7595..7574ba3fb3 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -86,7 +86,8 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned long addr)
continue;
if (ops->device_to_virt)
- dst = ops->device_to_virt(dev, (ulong)dst);
+ dst = ops->device_to_virt(dev, (ulong)dst,
+ phdr->p_memsz);
dev_dbg(dev, "Loading phdr %i to 0x%p (%i bytes)\n",
i, dst, phdr->p_filesz);
diff --git a/drivers/remoteproc/sandbox_testproc.c b/drivers/remoteproc/sandbox_testproc.c
index 5f35119ab7..eeee49c4dd 100644
--- a/drivers/remoteproc/sandbox_testproc.c
+++ b/drivers/remoteproc/sandbox_testproc.c
@@ -306,9 +306,11 @@ static int sandbox_testproc_ping(struct udevice *dev)
* sandbox_testproc_device_to_virt() - Convert device address to virtual address
* @dev: device to operate upon
* @da: device address
+ * @size: Size of the memory region @da is pointing to
* @return converted virtual address
*/
-static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da)
+static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da,
+ ulong size)
{
u64 paddr;
diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
index ad941f67e8..71895daf9c 100644
--- a/drivers/remoteproc/stm32_copro.c
+++ b/drivers/remoteproc/stm32_copro.c
@@ -107,11 +107,13 @@ static int stm32_copro_set_hold_boot(struct udevice *dev, bool hold)
* stm32_copro_device_to_virt() - Convert device address to virtual address
* @dev: corresponding STM32 remote processor device
* @da: device address
+ * @size: Size of the memory region @da is pointing to
* @return converted virtual address
*/
-static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da)
+static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da,
+ ulong size)
{
- fdt32_t in_addr = cpu_to_be32(da);
+ fdt32_t in_addr = cpu_to_be32(da), end_addr;
u64 paddr;
paddr = dev_translate_dma_address(dev, &in_addr);
@@ -120,6 +122,12 @@ static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da)
return NULL;
}
+ end_addr = cpu_to_be32(da + size - 1);
+ if (dev_translate_dma_address(dev, &end_addr) == OF_BAD_ADDR) {
+ dev_err(dev, "Unable to convert address %ld\n", da + size - 1);
+ return NULL;
+ }
+
return phys_to_virt(paddr);
}
diff --git a/include/remoteproc.h b/include/remoteproc.h
index 4987194905..dbff1ce3cf 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -122,9 +122,10 @@ struct dm_rproc_ops {
*
* @dev: Remote proc device
* @da: Device address
+ * @size: Size of the memory region @da is pointing to
* @return virtual address.
*/
- void * (*device_to_virt)(struct udevice *dev, ulong da);
+ void * (*device_to_virt)(struct udevice *dev, ulong da, ulong size);
};
/* Accessor */
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 02/26] remoteproc: ops: Add elf section size as input parameter to device_to_virt api
2019-09-04 10:31 ` [U-Boot] [PATCH v2 02/26] remoteproc: ops: Add elf section size as input parameter to device_to_virt api Lokesh Vutla
@ 2019-09-04 15:04 ` Fabien DESSENNE
2019-10-12 20:24 ` Tom Rini
1 sibling, 0 replies; 57+ messages in thread
From: Fabien DESSENNE @ 2019-09-04 15:04 UTC (permalink / raw)
To: u-boot
Hi Lokesh
I have successfully tested this patch for stm32_copro.
BR
Fabien
On 04/09/2019 12:31 PM, Lokesh Vutla wrote:
> Introduce a new parameter "size" that accepts size of the region to
> remoteproc ops callback device_to_virt(). This can enforce more checks
> on the region that device_to_virt() is dealing with.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
> ---
> drivers/remoteproc/rproc-elf-loader.c | 3 ++-
> drivers/remoteproc/sandbox_testproc.c | 4 +++-
> drivers/remoteproc/stm32_copro.c | 12 ++++++++++--
> include/remoteproc.h | 3 ++-
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
> index 67937a7595..7574ba3fb3 100644
> --- a/drivers/remoteproc/rproc-elf-loader.c
> +++ b/drivers/remoteproc/rproc-elf-loader.c
> @@ -86,7 +86,8 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned long addr)
> continue;
>
> if (ops->device_to_virt)
> - dst = ops->device_to_virt(dev, (ulong)dst);
> + dst = ops->device_to_virt(dev, (ulong)dst,
> + phdr->p_memsz);
>
> dev_dbg(dev, "Loading phdr %i to 0x%p (%i bytes)\n",
> i, dst, phdr->p_filesz);
> diff --git a/drivers/remoteproc/sandbox_testproc.c b/drivers/remoteproc/sandbox_testproc.c
> index 5f35119ab7..eeee49c4dd 100644
> --- a/drivers/remoteproc/sandbox_testproc.c
> +++ b/drivers/remoteproc/sandbox_testproc.c
> @@ -306,9 +306,11 @@ static int sandbox_testproc_ping(struct udevice *dev)
> * sandbox_testproc_device_to_virt() - Convert device address to virtual address
> * @dev: device to operate upon
> * @da: device address
> + * @size: Size of the memory region @da is pointing to
> * @return converted virtual address
> */
> -static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da)
> +static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da,
> + ulong size)
> {
> u64 paddr;
>
> diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
> index ad941f67e8..71895daf9c 100644
> --- a/drivers/remoteproc/stm32_copro.c
> +++ b/drivers/remoteproc/stm32_copro.c
> @@ -107,11 +107,13 @@ static int stm32_copro_set_hold_boot(struct udevice *dev, bool hold)
> * stm32_copro_device_to_virt() - Convert device address to virtual address
> * @dev: corresponding STM32 remote processor device
> * @da: device address
> + * @size: Size of the memory region @da is pointing to
> * @return converted virtual address
> */
> -static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da)
> +static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da,
> + ulong size)
> {
> - fdt32_t in_addr = cpu_to_be32(da);
> + fdt32_t in_addr = cpu_to_be32(da), end_addr;
> u64 paddr;
>
> paddr = dev_translate_dma_address(dev, &in_addr);
> @@ -120,6 +122,12 @@ static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da)
> return NULL;
> }
>
> + end_addr = cpu_to_be32(da + size - 1);
> + if (dev_translate_dma_address(dev, &end_addr) == OF_BAD_ADDR) {
> + dev_err(dev, "Unable to convert address %ld\n", da + size - 1);
> + return NULL;
> + }
> +
> return phys_to_virt(paddr);
> }
>
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 4987194905..dbff1ce3cf 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -122,9 +122,10 @@ struct dm_rproc_ops {
> *
> * @dev: Remote proc device
> * @da: Device address
> + * @size: Size of the memory region @da is pointing to
> * @return virtual address.
> */
> - void * (*device_to_virt)(struct udevice *dev, ulong da);
> + void * (*device_to_virt)(struct udevice *dev, ulong da, ulong size);
> };
>
> /* Accessor */
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 02/26] remoteproc: ops: Add elf section size as input parameter to device_to_virt api
2019-09-04 10:31 ` [U-Boot] [PATCH v2 02/26] remoteproc: ops: Add elf section size as input parameter to device_to_virt api Lokesh Vutla
2019-09-04 15:04 ` Fabien DESSENNE
@ 2019-10-12 20:24 ` Tom Rini
1 sibling, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:24 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:27PM +0530, Lokesh Vutla wrote:
> Introduce a new parameter "size" that accepts size of the region to
> remoteproc ops callback device_to_virt(). This can enforce more checks
> on the region that device_to_virt() is dealing with.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Tested-by: Fabien Dessenne <fabien.dessenne@st.com>
> Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/dbfd8f2a/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 03/26] remoteproc: elf_loader: Always check the validity of the image before loading
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
2019-09-04 10:31 ` [U-Boot] [PATCH v2 01/26] dm: core: Add a function to count the children of a device Lokesh Vutla
2019-09-04 10:31 ` [U-Boot] [PATCH v2 02/26] remoteproc: ops: Add elf section size as input parameter to device_to_virt api Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-09-04 15:05 ` Fabien DESSENNE
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 04/26] remoteproc: elf-loader: Add 64 bit elf loading support Lokesh Vutla
` (22 subsequent siblings)
25 siblings, 2 replies; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
rproc_elf32_load_image() rely on user to send a valid address for elf loading.
Instead do a sanity check on the address passed by user. This will help
all rproc elf users to not call sanity_check explicitly before calling
elf_loading.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/remoteproc/rproc-elf-loader.c | 11 ++++++++---
drivers/remoteproc/stm32_copro.c | 9 +--------
include/remoteproc.h | 6 ++++--
test/dm/remoteproc.c | 5 +----
4 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
index 7574ba3fb3..238f51d3b5 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -64,13 +64,18 @@ int rproc_elf32_sanity_check(ulong addr, ulong size)
return 0;
}
-/* A very simple elf loader, assumes the image is valid */
-int rproc_elf32_load_image(struct udevice *dev, unsigned long addr)
+int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
{
Elf32_Ehdr *ehdr; /* Elf header structure pointer */
Elf32_Phdr *phdr; /* Program header structure pointer */
const struct dm_rproc_ops *ops;
- unsigned int i;
+ unsigned int i, ret;
+
+ ret = rproc_elf32_sanity_check(addr, size);
+ if (ret) {
+ dev_err(dev, "Invalid ELF32 Image %d\n", ret);
+ return ret;
+ }
ehdr = (Elf32_Ehdr *)addr;
phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
index 71895daf9c..40bba37211 100644
--- a/drivers/remoteproc/stm32_copro.c
+++ b/drivers/remoteproc/stm32_copro.c
@@ -155,14 +155,7 @@ static int stm32_copro_load(struct udevice *dev, ulong addr, ulong size)
return ret;
}
- /* Support only ELF32 image */
- ret = rproc_elf32_sanity_check(addr, size);
- if (ret) {
- dev_err(dev, "Invalid ELF32 image (%d)\n", ret);
- return ret;
- }
-
- return rproc_elf32_load_image(dev, addr);
+ return rproc_elf32_load_image(dev, addr, size);
}
/**
diff --git a/include/remoteproc.h b/include/remoteproc.h
index dbff1ce3cf..1ef88be7f7 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -218,9 +218,10 @@ int rproc_elf32_sanity_check(ulong addr, ulong size);
* rproc_elf32_load_image() - load an ELF32 image
* @dev: device loading the ELF32 image
* @addr: valid ELF32 image address
+ * @size: size of the image
* @return 0 if the image is successfully loaded, else appropriate error value.
*/
-int rproc_elf32_load_image(struct udevice *dev, unsigned long addr);
+int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size);
#else
static inline int rproc_init(void) { return -ENOSYS; }
static inline int rproc_dev_init(int id) { return -ENOSYS; }
@@ -234,7 +235,8 @@ static inline int rproc_is_running(int id) { return -ENOSYS; }
static inline int rproc_elf32_sanity_check(ulong addr,
ulong size) { return -ENOSYS; }
static inline int rproc_elf32_load_image(struct udevice *dev,
- unsigned long addr) { return -ENOSYS; }
+ unsigned long addr, ulong size)
+{ return -ENOSYS; }
#endif
#endif /* _RPROC_H_ */
diff --git a/test/dm/remoteproc.c b/test/dm/remoteproc.c
index a2c4be7c27..c77361c8f4 100644
--- a/test/dm/remoteproc.c
+++ b/test/dm/remoteproc.c
@@ -171,11 +171,8 @@ static int dm_test_remoteproc_elf(struct unit_test_state *uts)
ut_assertnonnull(loaded_firmware);
memset(loaded_firmware, 0, loaded_firmware_size);
- /* Verify valid ELF format */
- ut_assertok(rproc_elf32_sanity_check((ulong)valid_elf32, size));
-
/* Load firmware in loaded_firmware, and verify it */
- ut_assertok(rproc_elf32_load_image(dev, (unsigned long)valid_elf32));
+ ut_assertok(rproc_elf32_load_image(dev, (ulong)valid_elf32, size));
ut_assertok(memcmp(loaded_firmware, valid_elf32, loaded_firmware_size));
unmap_physmem(loaded_firmware, MAP_NOCACHE);
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 03/26] remoteproc: elf_loader: Always check the validity of the image before loading
2019-09-04 10:31 ` [U-Boot] [PATCH v2 03/26] remoteproc: elf_loader: Always check the validity of the image before loading Lokesh Vutla
@ 2019-09-04 15:05 ` Fabien DESSENNE
2019-10-12 20:24 ` Tom Rini
1 sibling, 0 replies; 57+ messages in thread
From: Fabien DESSENNE @ 2019-09-04 15:05 UTC (permalink / raw)
To: u-boot
Hi Lokesh
On 04/09/2019 12:31 PM, Lokesh Vutla wrote:
> rproc_elf32_load_image() rely on user to send a valid address for elf loading.
> Instead do a sanity check on the address passed by user. This will help
> all rproc elf users to not call sanity_check explicitly before calling
> elf_loading.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
> ---
> drivers/remoteproc/rproc-elf-loader.c | 11 ++++++++---
> drivers/remoteproc/stm32_copro.c | 9 +--------
> include/remoteproc.h | 6 ++++--
> test/dm/remoteproc.c | 5 +----
> 4 files changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
> index 7574ba3fb3..238f51d3b5 100644
> --- a/drivers/remoteproc/rproc-elf-loader.c
> +++ b/drivers/remoteproc/rproc-elf-loader.c
> @@ -64,13 +64,18 @@ int rproc_elf32_sanity_check(ulong addr, ulong size)
> return 0;
> }
>
> -/* A very simple elf loader, assumes the image is valid */
> -int rproc_elf32_load_image(struct udevice *dev, unsigned long addr)
> +int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
> {
> Elf32_Ehdr *ehdr; /* Elf header structure pointer */
> Elf32_Phdr *phdr; /* Program header structure pointer */
> const struct dm_rproc_ops *ops;
> - unsigned int i;
> + unsigned int i, ret;
> +
> + ret = rproc_elf32_sanity_check(addr, size);
> + if (ret) {
> + dev_err(dev, "Invalid ELF32 Image %d\n", ret);
> + return ret;
> + }
>
> ehdr = (Elf32_Ehdr *)addr;
> phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
> diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
> index 71895daf9c..40bba37211 100644
> --- a/drivers/remoteproc/stm32_copro.c
> +++ b/drivers/remoteproc/stm32_copro.c
> @@ -155,14 +155,7 @@ static int stm32_copro_load(struct udevice *dev, ulong addr, ulong size)
> return ret;
> }
>
> - /* Support only ELF32 image */
> - ret = rproc_elf32_sanity_check(addr, size);
> - if (ret) {
> - dev_err(dev, "Invalid ELF32 image (%d)\n", ret);
> - return ret;
> - }
> -
> - return rproc_elf32_load_image(dev, addr);
> + return rproc_elf32_load_image(dev, addr, size);
> }
>
> /**
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index dbff1ce3cf..1ef88be7f7 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -218,9 +218,10 @@ int rproc_elf32_sanity_check(ulong addr, ulong size);
> * rproc_elf32_load_image() - load an ELF32 image
> * @dev: device loading the ELF32 image
> * @addr: valid ELF32 image address
> + * @size: size of the image
> * @return 0 if the image is successfully loaded, else appropriate error value.
> */
> -int rproc_elf32_load_image(struct udevice *dev, unsigned long addr);
> +int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size);
> #else
> static inline int rproc_init(void) { return -ENOSYS; }
> static inline int rproc_dev_init(int id) { return -ENOSYS; }
> @@ -234,7 +235,8 @@ static inline int rproc_is_running(int id) { return -ENOSYS; }
> static inline int rproc_elf32_sanity_check(ulong addr,
> ulong size) { return -ENOSYS; }
> static inline int rproc_elf32_load_image(struct udevice *dev,
> - unsigned long addr) { return -ENOSYS; }
> + unsigned long addr, ulong size)
> +{ return -ENOSYS; }
> #endif
>
> #endif /* _RPROC_H_ */
> diff --git a/test/dm/remoteproc.c b/test/dm/remoteproc.c
> index a2c4be7c27..c77361c8f4 100644
> --- a/test/dm/remoteproc.c
> +++ b/test/dm/remoteproc.c
> @@ -171,11 +171,8 @@ static int dm_test_remoteproc_elf(struct unit_test_state *uts)
> ut_assertnonnull(loaded_firmware);
> memset(loaded_firmware, 0, loaded_firmware_size);
>
> - /* Verify valid ELF format */
> - ut_assertok(rproc_elf32_sanity_check((ulong)valid_elf32, size));
> -
> /* Load firmware in loaded_firmware, and verify it */
> - ut_assertok(rproc_elf32_load_image(dev, (unsigned long)valid_elf32));
> + ut_assertok(rproc_elf32_load_image(dev, (ulong)valid_elf32, size));
> ut_assertok(memcmp(loaded_firmware, valid_elf32, loaded_firmware_size));
> unmap_physmem(loaded_firmware, MAP_NOCACHE);
>
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 03/26] remoteproc: elf_loader: Always check the validity of the image before loading
2019-09-04 10:31 ` [U-Boot] [PATCH v2 03/26] remoteproc: elf_loader: Always check the validity of the image before loading Lokesh Vutla
2019-09-04 15:05 ` Fabien DESSENNE
@ 2019-10-12 20:24 ` Tom Rini
1 sibling, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:24 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:28PM +0530, Lokesh Vutla wrote:
> rproc_elf32_load_image() rely on user to send a valid address for elf loading.
> Instead do a sanity check on the address passed by user. This will help
> all rproc elf users to not call sanity_check explicitly before calling
> elf_loading.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/caa054d5/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 04/26] remoteproc: elf-loader: Add 64 bit elf loading support
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (2 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 03/26] remoteproc: elf_loader: Always check the validity of the image before loading Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-09-04 15:06 ` Fabien DESSENNE
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 05/26] remoteproc: elf_loader: Introduce a common elf loader and checker functions Lokesh Vutla
` (21 subsequent siblings)
25 siblings, 2 replies; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
The current rproc-elf-loader supports loading of only 32 bit elf files.
Introduce support for loading of 64 bit elf files in rproc-elf-loader.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/remoteproc/rproc-elf-loader.c | 110 ++++++++++++++++++++++++++
include/remoteproc.h | 26 ++++++
2 files changed, 136 insertions(+)
diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
index 238f51d3b5..1aece2fc31 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -64,6 +64,62 @@ int rproc_elf32_sanity_check(ulong addr, ulong size)
return 0;
}
+/* Basic function to verify ELF64 image format */
+int rproc_elf64_sanity_check(ulong addr, ulong size)
+{
+ Elf64_Ehdr *ehdr = (Elf64_Ehdr *)addr;
+ char class;
+
+ if (!addr) {
+ pr_debug("Invalid fw address?\n");
+ return -EFAULT;
+ }
+
+ if (size < sizeof(Elf64_Ehdr)) {
+ pr_debug("Image is too small\n");
+ return -ENOSPC;
+ }
+
+ class = ehdr->e_ident[EI_CLASS];
+
+ if (!IS_ELF(*ehdr) || ehdr->e_type != ET_EXEC || class != ELFCLASS64) {
+ pr_debug("Not an executable ELF64 image\n");
+ return -EPROTONOSUPPORT;
+ }
+
+ /* We assume the firmware has the same endianness as the host */
+# ifdef __LITTLE_ENDIAN
+ if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
+# else /* BIG ENDIAN */
+ if (ehdr->e_ident[EI_DATA] != ELFDATA2MSB) {
+# endif
+ pr_debug("Unsupported firmware endianness\n");
+ return -EILSEQ;
+ }
+
+ if (size < ehdr->e_shoff + sizeof(Elf64_Shdr)) {
+ pr_debug("Image is too small\n");
+ return -ENOSPC;
+ }
+
+ if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
+ pr_debug("Image is corrupted (bad magic)\n");
+ return -EBADF;
+ }
+
+ if (ehdr->e_phnum == 0) {
+ pr_debug("No loadable segments\n");
+ return -ENOEXEC;
+ }
+
+ if (ehdr->e_phoff > size) {
+ pr_debug("Firmware size is too small\n");
+ return -ENOSPC;
+ }
+
+ return 0;
+}
+
int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
{
Elf32_Ehdr *ehdr; /* Elf header structure pointer */
@@ -110,3 +166,57 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
return 0;
}
+
+int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size)
+{
+ const struct dm_rproc_ops *ops = rproc_get_ops(dev);
+ u64 da, memsz, filesz, offset;
+ Elf64_Ehdr *ehdr;
+ Elf64_Phdr *phdr;
+ int i, ret = 0;
+ void *ptr;
+
+ dev_dbg(dev, "%s: addr = 0x%lx size = 0x%lx\n", __func__, addr, size);
+
+ if (rproc_elf64_sanity_check(addr, size))
+ return -EINVAL;
+
+ ehdr = (Elf64_Ehdr *)addr;
+ phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
+
+ /* go through the available ELF segments */
+ for (i = 0; i < ehdr->e_phnum; i++, phdr++) {
+ da = phdr->p_paddr;
+ memsz = phdr->p_memsz;
+ filesz = phdr->p_filesz;
+ offset = phdr->p_offset;
+
+ if (phdr->p_type != PT_LOAD)
+ continue;
+
+ dev_dbg(dev, "%s:phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
+ __func__, phdr->p_type, da, memsz, filesz);
+
+ ptr = (void *)(uintptr_t)da;
+ if (ops->device_to_virt) {
+ ptr = ops->device_to_virt(dev, da, phdr->p_memsz);
+ if (!ptr) {
+ dev_err(dev, "bad da 0x%llx mem 0x%llx\n", da,
+ memsz);
+ ret = -EINVAL;
+ break;
+ }
+ }
+
+ if (filesz)
+ memcpy(ptr, (void *)addr + offset, filesz);
+ if (filesz != memsz)
+ memset(ptr + filesz, 0x00, memsz - filesz);
+
+ flush_cache(rounddown((ulong)ptr, ARCH_DMA_MINALIGN),
+ roundup((ulong)ptr + filesz, ARCH_DMA_MINALIGN) -
+ rounddown((ulong)ptr, ARCH_DMA_MINALIGN));
+ }
+
+ return ret;
+}
diff --git a/include/remoteproc.h b/include/remoteproc.h
index 1ef88be7f7..56a11db6e3 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -214,6 +214,18 @@ int rproc_is_running(int id);
*/
int rproc_elf32_sanity_check(ulong addr, ulong size);
+/**
+ * rproc_elf64_sanity_check() - Verify if an image is a valid ELF32 one
+ *
+ * Check if a valid ELF64 image exists at the given memory location. Verify
+ * basic ELF64 format requirements like magic number and sections size.
+ *
+ * @addr: address of the image to verify
+ * @size: size of the image
+ * @return 0 if the image looks good, else appropriate error value.
+ */
+int rproc_elf64_sanity_check(ulong addr, ulong size);
+
/**
* rproc_elf32_load_image() - load an ELF32 image
* @dev: device loading the ELF32 image
@@ -222,6 +234,15 @@ int rproc_elf32_sanity_check(ulong addr, ulong size);
* @return 0 if the image is successfully loaded, else appropriate error value.
*/
int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size);
+
+/**
+ * rproc_elf64_load_image() - load an ELF64 image
+ * @dev: device loading the ELF64 image
+ * @addr: valid ELF64 image address
+ * @size: size of the image
+ * @return 0 if the image is successfully loaded, else appropriate error value.
+ */
+int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size);
#else
static inline int rproc_init(void) { return -ENOSYS; }
static inline int rproc_dev_init(int id) { return -ENOSYS; }
@@ -234,9 +255,14 @@ static inline int rproc_ping(int id) { return -ENOSYS; }
static inline int rproc_is_running(int id) { return -ENOSYS; }
static inline int rproc_elf32_sanity_check(ulong addr,
ulong size) { return -ENOSYS; }
+static inline int rproc_elf64_sanity_check(ulong addr,
+ ulong size) { return -ENOSYS; }
static inline int rproc_elf32_load_image(struct udevice *dev,
unsigned long addr, ulong size)
{ return -ENOSYS; }
+static inline int rproc_elf64_load_image(struct udevice *dev, ulong addr,
+ ulong size)
+{ return -ENOSYS; }
#endif
#endif /* _RPROC_H_ */
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 04/26] remoteproc: elf-loader: Add 64 bit elf loading support
2019-09-04 10:31 ` [U-Boot] [PATCH v2 04/26] remoteproc: elf-loader: Add 64 bit elf loading support Lokesh Vutla
@ 2019-09-04 15:06 ` Fabien DESSENNE
2019-10-12 20:24 ` Tom Rini
1 sibling, 0 replies; 57+ messages in thread
From: Fabien DESSENNE @ 2019-09-04 15:06 UTC (permalink / raw)
To: u-boot
Hi Lokesh
Thank you for the patch.
BR
Fabien
On 04/09/2019 12:31 PM, Lokesh Vutla wrote:
> The current rproc-elf-loader supports loading of only 32 bit elf files.
> Introduce support for loading of 64 bit elf files in rproc-elf-loader.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
> ---
> drivers/remoteproc/rproc-elf-loader.c | 110 ++++++++++++++++++++++++++
> include/remoteproc.h | 26 ++++++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
> index 238f51d3b5..1aece2fc31 100644
> --- a/drivers/remoteproc/rproc-elf-loader.c
> +++ b/drivers/remoteproc/rproc-elf-loader.c
> @@ -64,6 +64,62 @@ int rproc_elf32_sanity_check(ulong addr, ulong size)
> return 0;
> }
>
> +/* Basic function to verify ELF64 image format */
> +int rproc_elf64_sanity_check(ulong addr, ulong size)
> +{
> + Elf64_Ehdr *ehdr = (Elf64_Ehdr *)addr;
> + char class;
> +
> + if (!addr) {
> + pr_debug("Invalid fw address?\n");
> + return -EFAULT;
> + }
> +
> + if (size < sizeof(Elf64_Ehdr)) {
> + pr_debug("Image is too small\n");
> + return -ENOSPC;
> + }
> +
> + class = ehdr->e_ident[EI_CLASS];
> +
> + if (!IS_ELF(*ehdr) || ehdr->e_type != ET_EXEC || class != ELFCLASS64) {
> + pr_debug("Not an executable ELF64 image\n");
> + return -EPROTONOSUPPORT;
> + }
> +
> + /* We assume the firmware has the same endianness as the host */
> +# ifdef __LITTLE_ENDIAN
> + if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
> +# else /* BIG ENDIAN */
> + if (ehdr->e_ident[EI_DATA] != ELFDATA2MSB) {
> +# endif
> + pr_debug("Unsupported firmware endianness\n");
> + return -EILSEQ;
> + }
> +
> + if (size < ehdr->e_shoff + sizeof(Elf64_Shdr)) {
> + pr_debug("Image is too small\n");
> + return -ENOSPC;
> + }
> +
> + if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
> + pr_debug("Image is corrupted (bad magic)\n");
> + return -EBADF;
> + }
> +
> + if (ehdr->e_phnum == 0) {
> + pr_debug("No loadable segments\n");
> + return -ENOEXEC;
> + }
> +
> + if (ehdr->e_phoff > size) {
> + pr_debug("Firmware size is too small\n");
> + return -ENOSPC;
> + }
> +
> + return 0;
> +}
> +
> int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
> {
> Elf32_Ehdr *ehdr; /* Elf header structure pointer */
> @@ -110,3 +166,57 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
>
> return 0;
> }
> +
> +int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size)
> +{
> + const struct dm_rproc_ops *ops = rproc_get_ops(dev);
> + u64 da, memsz, filesz, offset;
> + Elf64_Ehdr *ehdr;
> + Elf64_Phdr *phdr;
> + int i, ret = 0;
> + void *ptr;
> +
> + dev_dbg(dev, "%s: addr = 0x%lx size = 0x%lx\n", __func__, addr, size);
> +
> + if (rproc_elf64_sanity_check(addr, size))
> + return -EINVAL;
> +
> + ehdr = (Elf64_Ehdr *)addr;
> + phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
> +
> + /* go through the available ELF segments */
> + for (i = 0; i < ehdr->e_phnum; i++, phdr++) {
> + da = phdr->p_paddr;
> + memsz = phdr->p_memsz;
> + filesz = phdr->p_filesz;
> + offset = phdr->p_offset;
> +
> + if (phdr->p_type != PT_LOAD)
> + continue;
> +
> + dev_dbg(dev, "%s:phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
> + __func__, phdr->p_type, da, memsz, filesz);
> +
> + ptr = (void *)(uintptr_t)da;
> + if (ops->device_to_virt) {
> + ptr = ops->device_to_virt(dev, da, phdr->p_memsz);
> + if (!ptr) {
> + dev_err(dev, "bad da 0x%llx mem 0x%llx\n", da,
> + memsz);
> + ret = -EINVAL;
> + break;
> + }
> + }
> +
> + if (filesz)
> + memcpy(ptr, (void *)addr + offset, filesz);
> + if (filesz != memsz)
> + memset(ptr + filesz, 0x00, memsz - filesz);
> +
> + flush_cache(rounddown((ulong)ptr, ARCH_DMA_MINALIGN),
> + roundup((ulong)ptr + filesz, ARCH_DMA_MINALIGN) -
> + rounddown((ulong)ptr, ARCH_DMA_MINALIGN));
> + }
> +
> + return ret;
> +}
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 1ef88be7f7..56a11db6e3 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -214,6 +214,18 @@ int rproc_is_running(int id);
> */
> int rproc_elf32_sanity_check(ulong addr, ulong size);
>
> +/**
> + * rproc_elf64_sanity_check() - Verify if an image is a valid ELF32 one
> + *
> + * Check if a valid ELF64 image exists at the given memory location. Verify
> + * basic ELF64 format requirements like magic number and sections size.
> + *
> + * @addr: address of the image to verify
> + * @size: size of the image
> + * @return 0 if the image looks good, else appropriate error value.
> + */
> +int rproc_elf64_sanity_check(ulong addr, ulong size);
> +
> /**
> * rproc_elf32_load_image() - load an ELF32 image
> * @dev: device loading the ELF32 image
> @@ -222,6 +234,15 @@ int rproc_elf32_sanity_check(ulong addr, ulong size);
> * @return 0 if the image is successfully loaded, else appropriate error value.
> */
> int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size);
> +
> +/**
> + * rproc_elf64_load_image() - load an ELF64 image
> + * @dev: device loading the ELF64 image
> + * @addr: valid ELF64 image address
> + * @size: size of the image
> + * @return 0 if the image is successfully loaded, else appropriate error value.
> + */
> +int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size);
> #else
> static inline int rproc_init(void) { return -ENOSYS; }
> static inline int rproc_dev_init(int id) { return -ENOSYS; }
> @@ -234,9 +255,14 @@ static inline int rproc_ping(int id) { return -ENOSYS; }
> static inline int rproc_is_running(int id) { return -ENOSYS; }
> static inline int rproc_elf32_sanity_check(ulong addr,
> ulong size) { return -ENOSYS; }
> +static inline int rproc_elf64_sanity_check(ulong addr,
> + ulong size) { return -ENOSYS; }
> static inline int rproc_elf32_load_image(struct udevice *dev,
> unsigned long addr, ulong size)
> { return -ENOSYS; }
> +static inline int rproc_elf64_load_image(struct udevice *dev, ulong addr,
> + ulong size)
> +{ return -ENOSYS; }
> #endif
>
> #endif /* _RPROC_H_ */
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 04/26] remoteproc: elf-loader: Add 64 bit elf loading support
2019-09-04 10:31 ` [U-Boot] [PATCH v2 04/26] remoteproc: elf-loader: Add 64 bit elf loading support Lokesh Vutla
2019-09-04 15:06 ` Fabien DESSENNE
@ 2019-10-12 20:24 ` Tom Rini
1 sibling, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:24 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:29PM +0530, Lokesh Vutla wrote:
> The current rproc-elf-loader supports loading of only 32 bit elf files.
> Introduce support for loading of 64 bit elf files in rproc-elf-loader.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/1a6a61d7/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 05/26] remoteproc: elf_loader: Introduce a common elf loader and checker functions
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (3 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 04/26] remoteproc: elf-loader: Add 64 bit elf loading support Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-09-04 15:05 ` Fabien DESSENNE
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 06/26] remoteproc: elf_loader: Introduce rproc_elf_get_boot_addr() api Lokesh Vutla
` (20 subsequent siblings)
25 siblings, 2 replies; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
Introduce a common remoteproc elf loader and checker functions that
automatically detects the 64 bit elf file or 32 bit elf file and
loads/checks the sections accordingly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/remoteproc/rproc-elf-loader.c | 31 +++++++++++++++++++++++++++
include/remoteproc.h | 29 +++++++++++++++++++++++++
2 files changed, 60 insertions(+)
diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
index 1aece2fc31..42a78f4207 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -120,6 +120,22 @@ int rproc_elf64_sanity_check(ulong addr, ulong size)
return 0;
}
+/* Basic function to verify ELF image format */
+int rproc_elf_sanity_check(ulong addr, ulong size)
+{
+ Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
+
+ if (!addr) {
+ dev_err(dev, "Invalid firmware address\n");
+ return -EFAULT;
+ }
+
+ if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
+ return rproc_elf64_sanity_check(addr, size);
+ else
+ return rproc_elf32_sanity_check(addr, size);
+}
+
int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
{
Elf32_Ehdr *ehdr; /* Elf header structure pointer */
@@ -220,3 +236,18 @@ int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size)
return ret;
}
+
+int rproc_elf_load_image(struct udevice *dev, ulong addr, ulong size)
+{
+ Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
+
+ if (!addr) {
+ dev_err(dev, "Invalid firmware address\n");
+ return -EFAULT;
+ }
+
+ if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
+ return rproc_elf64_load_image(dev, addr, size);
+ else
+ return rproc_elf32_load_image(dev, addr, size);
+}
diff --git a/include/remoteproc.h b/include/remoteproc.h
index 56a11db6e3..812e0f47c4 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -226,6 +226,19 @@ int rproc_elf32_sanity_check(ulong addr, ulong size);
*/
int rproc_elf64_sanity_check(ulong addr, ulong size);
+/**
+ * rproc_elf_sanity_check() - Verify if an image is a valid ELF one
+ *
+ * Check if a valid ELF image exists at the given memory location. Auto
+ * detects ELF32/ELF64 and verifies basic ELF64/ELF32 format requirements
+ * like magic number and sections size.
+ *
+ * @addr: address of the image to verify
+ * @size: size of the image
+ * @return 0 if the image looks good, else appropriate error value.
+ */
+int rproc_elf_sanity_check(ulong addr, ulong size);
+
/**
* rproc_elf32_load_image() - load an ELF32 image
* @dev: device loading the ELF32 image
@@ -243,6 +256,17 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size);
* @return 0 if the image is successfully loaded, else appropriate error value.
*/
int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size);
+
+/**
+ * rproc_elf_load_image() - load an ELF image
+ * @dev: device loading the ELF image
+ * @addr: valid ELF image address
+ * @size: size of the image
+ *
+ * Auto detects if the image is ELF32 or ELF64 image and load accordingly.
+ * @return 0 if the image is successfully loaded, else appropriate error value.
+ */
+int rproc_elf_load_image(struct udevice *dev, unsigned long addr, ulong size);
#else
static inline int rproc_init(void) { return -ENOSYS; }
static inline int rproc_dev_init(int id) { return -ENOSYS; }
@@ -257,12 +281,17 @@ static inline int rproc_elf32_sanity_check(ulong addr,
ulong size) { return -ENOSYS; }
static inline int rproc_elf64_sanity_check(ulong addr,
ulong size) { return -ENOSYS; }
+static inline int rproc_elf_sanity_check(ulong addr,
+ ulong size) { return -ENOSYS; }
static inline int rproc_elf32_load_image(struct udevice *dev,
unsigned long addr, ulong size)
{ return -ENOSYS; }
static inline int rproc_elf64_load_image(struct udevice *dev, ulong addr,
ulong size)
{ return -ENOSYS; }
+static inline int rproc_elf_load_image(struct udevice *dev, ulong addr,
+ ulong size)
+{ return -ENOSYS; }
#endif
#endif /* _RPROC_H_ */
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 05/26] remoteproc: elf_loader: Introduce a common elf loader and checker functions
2019-09-04 10:31 ` [U-Boot] [PATCH v2 05/26] remoteproc: elf_loader: Introduce a common elf loader and checker functions Lokesh Vutla
@ 2019-09-04 15:05 ` Fabien DESSENNE
2019-10-12 20:24 ` Tom Rini
1 sibling, 0 replies; 57+ messages in thread
From: Fabien DESSENNE @ 2019-09-04 15:05 UTC (permalink / raw)
To: u-boot
Hi Lokesh
On 04/09/2019 12:31 PM, Lokesh Vutla wrote:
> Introduce a common remoteproc elf loader and checker functions that
> automatically detects the 64 bit elf file or 32 bit elf file and
> loads/checks the sections accordingly.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
> ---
> drivers/remoteproc/rproc-elf-loader.c | 31 +++++++++++++++++++++++++++
> include/remoteproc.h | 29 +++++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
> index 1aece2fc31..42a78f4207 100644
> --- a/drivers/remoteproc/rproc-elf-loader.c
> +++ b/drivers/remoteproc/rproc-elf-loader.c
> @@ -120,6 +120,22 @@ int rproc_elf64_sanity_check(ulong addr, ulong size)
> return 0;
> }
>
> +/* Basic function to verify ELF image format */
> +int rproc_elf_sanity_check(ulong addr, ulong size)
> +{
> + Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
> +
> + if (!addr) {
> + dev_err(dev, "Invalid firmware address\n");
> + return -EFAULT;
> + }
> +
> + if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
> + return rproc_elf64_sanity_check(addr, size);
> + else
> + return rproc_elf32_sanity_check(addr, size);
> +}
> +
> int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
> {
> Elf32_Ehdr *ehdr; /* Elf header structure pointer */
> @@ -220,3 +236,18 @@ int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size)
>
> return ret;
> }
> +
> +int rproc_elf_load_image(struct udevice *dev, ulong addr, ulong size)
> +{
> + Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
> +
> + if (!addr) {
> + dev_err(dev, "Invalid firmware address\n");
> + return -EFAULT;
> + }
> +
> + if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
> + return rproc_elf64_load_image(dev, addr, size);
> + else
> + return rproc_elf32_load_image(dev, addr, size);
> +}
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 56a11db6e3..812e0f47c4 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -226,6 +226,19 @@ int rproc_elf32_sanity_check(ulong addr, ulong size);
> */
> int rproc_elf64_sanity_check(ulong addr, ulong size);
>
> +/**
> + * rproc_elf_sanity_check() - Verify if an image is a valid ELF one
> + *
> + * Check if a valid ELF image exists at the given memory location. Auto
> + * detects ELF32/ELF64 and verifies basic ELF64/ELF32 format requirements
> + * like magic number and sections size.
> + *
> + * @addr: address of the image to verify
> + * @size: size of the image
> + * @return 0 if the image looks good, else appropriate error value.
> + */
> +int rproc_elf_sanity_check(ulong addr, ulong size);
> +
> /**
> * rproc_elf32_load_image() - load an ELF32 image
> * @dev: device loading the ELF32 image
> @@ -243,6 +256,17 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size);
> * @return 0 if the image is successfully loaded, else appropriate error value.
> */
> int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size);
> +
> +/**
> + * rproc_elf_load_image() - load an ELF image
> + * @dev: device loading the ELF image
> + * @addr: valid ELF image address
> + * @size: size of the image
> + *
> + * Auto detects if the image is ELF32 or ELF64 image and load accordingly.
> + * @return 0 if the image is successfully loaded, else appropriate error value.
> + */
> +int rproc_elf_load_image(struct udevice *dev, unsigned long addr, ulong size);
> #else
> static inline int rproc_init(void) { return -ENOSYS; }
> static inline int rproc_dev_init(int id) { return -ENOSYS; }
> @@ -257,12 +281,17 @@ static inline int rproc_elf32_sanity_check(ulong addr,
> ulong size) { return -ENOSYS; }
> static inline int rproc_elf64_sanity_check(ulong addr,
> ulong size) { return -ENOSYS; }
> +static inline int rproc_elf_sanity_check(ulong addr,
> + ulong size) { return -ENOSYS; }
> static inline int rproc_elf32_load_image(struct udevice *dev,
> unsigned long addr, ulong size)
> { return -ENOSYS; }
> static inline int rproc_elf64_load_image(struct udevice *dev, ulong addr,
> ulong size)
> { return -ENOSYS; }
> +static inline int rproc_elf_load_image(struct udevice *dev, ulong addr,
> + ulong size)
> +{ return -ENOSYS; }
> #endif
>
> #endif /* _RPROC_H_ */
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 05/26] remoteproc: elf_loader: Introduce a common elf loader and checker functions
2019-09-04 10:31 ` [U-Boot] [PATCH v2 05/26] remoteproc: elf_loader: Introduce a common elf loader and checker functions Lokesh Vutla
2019-09-04 15:05 ` Fabien DESSENNE
@ 2019-10-12 20:24 ` Tom Rini
1 sibling, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:24 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:30PM +0530, Lokesh Vutla wrote:
> Introduce a common remoteproc elf loader and checker functions that
> automatically detects the 64 bit elf file or 32 bit elf file and
> loads/checks the sections accordingly.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/cca902ac/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 06/26] remoteproc: elf_loader: Introduce rproc_elf_get_boot_addr() api
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (4 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 05/26] remoteproc: elf_loader: Introduce a common elf loader and checker functions Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 07/26] remoteproc: tisci_proc: Add helper api for controlling core power domain Lokesh Vutla
` (19 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
Introduce rproc_elf_get_boot_addr() that returns the entry point of
the elf file. This api auto detects the 64/32 bit elf file and returns
the boot addr accordingly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/remoteproc/rproc-elf-loader.c | 24 ++++++++++++++++++++++++
include/remoteproc.h | 12 ++++++++++++
test/dm/remoteproc.c | 2 ++
3 files changed, 38 insertions(+)
diff --git a/drivers/remoteproc/rproc-elf-loader.c b/drivers/remoteproc/rproc-elf-loader.c
index 42a78f4207..b38a226065 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -251,3 +251,27 @@ int rproc_elf_load_image(struct udevice *dev, ulong addr, ulong size)
else
return rproc_elf32_load_image(dev, addr, size);
}
+
+static ulong rproc_elf32_get_boot_addr(ulong addr)
+{
+ Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
+
+ return ehdr->e_entry;
+}
+
+static ulong rproc_elf64_get_boot_addr(ulong addr)
+{
+ Elf64_Ehdr *ehdr = (Elf64_Ehdr *)addr;
+
+ return ehdr->e_entry;
+}
+
+ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong addr)
+{
+ Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
+
+ if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
+ return rproc_elf64_get_boot_addr(addr);
+ else
+ return rproc_elf32_get_boot_addr(addr);
+}
diff --git a/include/remoteproc.h b/include/remoteproc.h
index 812e0f47c4..046cd9e54e 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -267,6 +267,16 @@ int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size);
* @return 0 if the image is successfully loaded, else appropriate error value.
*/
int rproc_elf_load_image(struct udevice *dev, unsigned long addr, ulong size);
+
+/**
+ * rproc_elf_get_boot_addr() - Get rproc's boot address.
+ * @dev: device loading the ELF image
+ * @addr: valid ELF image address
+ *
+ * This function returns the entry point address of the ELF
+ * image.
+ */
+ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong addr);
#else
static inline int rproc_init(void) { return -ENOSYS; }
static inline int rproc_dev_init(int id) { return -ENOSYS; }
@@ -292,6 +302,8 @@ static inline int rproc_elf64_load_image(struct udevice *dev, ulong addr,
static inline int rproc_elf_load_image(struct udevice *dev, ulong addr,
ulong size)
{ return -ENOSYS; }
+static inline ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong addr)
+{ return 0; }
#endif
#endif /* _RPROC_H_ */
diff --git a/test/dm/remoteproc.c b/test/dm/remoteproc.c
index c77361c8f4..1d9a9b32d5 100644
--- a/test/dm/remoteproc.c
+++ b/test/dm/remoteproc.c
@@ -174,6 +174,8 @@ static int dm_test_remoteproc_elf(struct unit_test_state *uts)
/* Load firmware in loaded_firmware, and verify it */
ut_assertok(rproc_elf32_load_image(dev, (ulong)valid_elf32, size));
ut_assertok(memcmp(loaded_firmware, valid_elf32, loaded_firmware_size));
+ ut_asserteq(rproc_elf_get_boot_addr(dev, (unsigned long)valid_elf32),
+ 0x08000000);
unmap_physmem(loaded_firmware, MAP_NOCACHE);
/* Invalid ELF Magic */
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 07/26] remoteproc: tisci_proc: Add helper api for controlling core power domain
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (5 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 06/26] remoteproc: elf_loader: Introduce rproc_elf_get_boot_addr() api Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 08/26] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Lokesh Vutla
` (18 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
Power domain for the remote cores needs to be handled in a right
sequence as mandated by the spec. Introduce tisci helper apis
that can control power-domains of remote cores. TISCI clients
can use this api and control the remote cores power domain instead
of hooking it to power-domain layer.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/remoteproc/ti_sci_proc.h | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/remoteproc/ti_sci_proc.h b/drivers/remoteproc/ti_sci_proc.h
index ccfc39ec88..f8299d1aff 100644
--- a/drivers/remoteproc/ti_sci_proc.h
+++ b/drivers/remoteproc/ti_sci_proc.h
@@ -19,12 +19,14 @@
* @proc_id: processor id for the consumer remoteproc device
* @host_id: host id to pass the control over for this consumer remoteproc
* device
+ * @dev_id: Device ID as identified by system controller.
*/
struct ti_sci_proc {
const struct ti_sci_handle *sci;
const struct ti_sci_proc_ops *ops;
u8 proc_id;
u8 host_id;
+ u16 dev_id;
};
static inline int ti_sci_proc_request(struct ti_sci_proc *tsp)
@@ -118,4 +120,29 @@ static inline int ti_sci_proc_set_control(struct ti_sci_proc *tsp,
return ret;
}
+static inline int ti_sci_proc_power_domain_on(struct ti_sci_proc *tsp)
+{
+ int ret;
+
+ debug("%s: dev_id = %d\n", __func__, tsp->dev_id);
+
+ ret = tsp->sci->ops.dev_ops.get_device_exclusive(tsp->sci, tsp->dev_id);
+ if (ret)
+ pr_err("Power-domain on failed for dev = %d\n", tsp->dev_id);
+
+ return ret;
+}
+
+static inline int ti_sci_proc_power_domain_off(struct ti_sci_proc *tsp)
+{
+ int ret;
+
+ debug("%s: dev_id = %d\n", __func__, tsp->dev_id);
+
+ ret = tsp->sci->ops.dev_ops.put_device(tsp->sci, tsp->dev_id);
+ if (ret)
+ pr_err("Power-domain off failed for dev = %d\n", tsp->dev_id);
+
+ return ret;
+}
#endif /* REMOTEPROC_TI_SCI_PROC_H */
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 08/26] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (6 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 07/26] remoteproc: tisci_proc: Add helper api for controlling core power domain Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 09/26] remoteproc: Introduce K3 remoteproc driver for R5F subsystem Lokesh Vutla
` (17 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
The Texas Instruments K3 family of SoCs have one of more dual-core
Arm Cortex R5F processor subsystems/clusters (R5FSS). Add the device
tree bindings document for these R5F subsystem devices. These R5F
processors do not have an MMU, and so require fixed memory carveout
regions matching the firmware image addresses. The nodes require more
than one memory region, with the first memory region used for DMA
allocations at runtime. The remaining memory regions are reserved
and are used for the loading and running of the R5F remote processors.
The added example illustrates the DT nodes for the single R5FSS device
present on K3 AM65x family of SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../remoteproc/ti,k3-r5f-rproc.txt | 164 ++++++++++++++++++
1 file changed, 164 insertions(+)
create mode 100644 doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
diff --git a/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt b/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
new file mode 100644
index 0000000000..c2fa6e8344
--- /dev/null
+++ b/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
@@ -0,0 +1,164 @@
+TI K3 R5F processor subsystems
+==============================
+
+The TI K3 family of SoCs usually have one or more dual-core Arm Cortex
+R5F processor subsystems/clusters (R5FSS). The dual core cluster can be
+used either in a LockStep mode providing safety/fault tolerance features
+or in a Split mode providing two individual compute cores for doubling
+the compute capacity. These are used together with other processors
+present on the SoC to achieve various system level goals.
+
+R5F Sub-System Device Node:
+===========================
+Each Dual-Core R5F sub-system is represented as a single DTS node representing
+the cluster, with a pair of child DT nodes representing the individual R5F
+cores. Each node has a number of required or optional properties that enable
+the OS running on the host processor to perform the device management of the
+remote processor and to communicate with the remote processor.
+
+Required properties:
+--------------------
+The following are the mandatory properties:
+
+- compatible: Should be one of the following,
+ "ti,am654-r5fss" for R5F clusters/subsystems on
+ K3 AM65x SoCs
+ "ti,j721e-r5fss" for R5F clusters/subsystems on
+ K3 J721E SoCs
+- power-domains: Should contain a phandle to a PM domain provider node
+ and an args specifier containing the R5FSS device id
+ value. This property is as per the binding,
+ Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+- #address-cells: Should be 1
+- #size-cells: Should be 1
+- ranges: Standard ranges definition providing translations for
+ R5F TCM address spaces
+
+Optional properties:
+--------------------
+- lockstep-mode: Configuration Mode for the Dual R5F cores within the R5F
+ cluster. Should be either a value of 1 (LockStep mode) or
+ 0 (Split mode), default is LockStep mode if omitted.
+
+
+R5F Processor Child Nodes:
+==========================
+The R5F Sub-System device node should define two R5F child nodes, each node
+representing a TI instantiation of the Arm Cortex R5F core. There are some
+specific integration differences for the IP like the usage of a Region Address
+Translator (RAT) for translating the larger SoC bus addresses into a 32-bit
+address space for the processor.
+
+Required properties:
+--------------------
+The following are the mandatory properties:
+
+- compatible: Should be one of the following,
+ "ti,am654-r5f" for the R5F cores in K3 AM65x SoCs
+ "ti,j721e-r5f" for the R5F cores in K3 J721E SOCs
+- reg: Should contain an entry for each value in 'reg-names'.
+ Each entry should have the memory region's start address
+ and the size of the region, the representation matching
+ the parent node's '#address-cells' and '#size-cells' values.
+- reg-names: Should contain strings with the following names, each
+ representing a specific internal memory region, and
+ should be defined in this order,
+ "atcm", "btcm"
+- ti,sci: Should be a phandle to the TI-SCI System Controller node
+- ti,sci-dev-id: Should contain the TI-SCI device id corresponding to the
+ R5F Core. Please refer to the corresponding System
+ Controller documentation for valid values for the R5F
+ cores.
+- ti,sci-proc-ids: Should contain 2 integer values. The first cell should
+ contain the TI-SCI processor id for the R5F core device
+ and the second cell should contain the TI-SCI host id to
+ which the processor control ownership should be
+ transferred to.
+- resets: Should contain the phandle to the reset controller node
+ managing the resets for this device, and a reset
+ specifier. Please refer to the following reset bindings
+ for the reset argument specifier,
+ Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+ for AM65x and J721E SoCs
+
+Optional properties:
+--------------------
+The following properties are optional properties for each of the R5F cores:
+
+- atcm-enable: R5F core configuration mode dictating if ATCM should be
+ enabled. Should be either a value of 1 (enabled) or
+ 0 (disabled), default is disabled if omitted. R5F view
+ of ATCM dictated by loczrama property.
+- btcm-enable: R5F core configuration mode dictating if BTCM should be
+ enabled. Should be either a value of 1 (enabled) or
+ 0 (disabled), default is enabled if omitted. R5F view
+ of BTCM dictated by loczrama property.
+- loczrama: R5F core configuration mode dictating which TCM should
+ appear at address 0 (from core's view). Should be either
+ a value of 1 (ATCM at 0x0) or 0 (BTCM at 0x0), default
+ value is 1 if omitted.
+
+Example:
+--------
+1. AM654 SoC
+ /* AM65x remoteproc alias */
+ aliases {
+ remoteproc0 = &mcu_r5fss0_core0;
+ };
+
+ cbass_main: interconnect at 100000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x41000000 0x00 0x41000000 0x00 0x00020000>,
+ <0x00 0x41400000 0x00 0x41400000 0x00 0x00020000>,
+ <0x00 0x41c00000 0x00 0x41c00000 0x00 0x00080000>;
+
+ cbass_mcu: interconnect at 28380000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x41000000 0x00 0x41000000 0x00 0x00020000>, /* MCU R5F Core0 */
+ <0x00 0x41400000 0x00 0x41400000 0x00 0x00020000>, /* MCU R5F Core1 */
+ <0x00 0x41c00000 0x00 0x41c00000 0x00 0x00080000>; /* MCU SRAM */
+
+ /* AM65x MCU R5FSS node */
+ mcu_r5fss0: r5fss at 41000000 {
+ compatible = "ti,am654-r5fss";
+ power-domains = <&k3_pds 129>;
+ lockstep-mode = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x41000000 0x00 0x41000000 0x20000>,
+ <0x41400000 0x00 0x41400000 0x20000>;
+
+ mcu_r5f0: r5f at 41000000 {
+ compatible = "ti,am654-r5f";
+ reg = <0x41000000 0x00008000>,
+ <0x41010000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <159>;
+ ti,sci-proc-ids = <0x01 0xFF>;
+ resets = <&k3_reset 159 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+
+ mcu_r5f1: r5f at 41400000 {
+ compatible = "ti,am654-r5f";
+ reg = <0x41400000 0x00008000>,
+ <0x41410000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <245>;
+ ti,sci-proc-ids = <0x02 0xFF>;
+ resets = <&k3_reset 245 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+ };
+ };
+ };
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 08/26] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
2019-09-04 10:31 ` [U-Boot] [PATCH v2 08/26] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Lokesh Vutla
@ 2019-10-12 20:24 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:24 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:33PM +0530, Lokesh Vutla wrote:
> From: Suman Anna <s-anna@ti.com>
>
> The Texas Instruments K3 family of SoCs have one of more dual-core
> Arm Cortex R5F processor subsystems/clusters (R5FSS). Add the device
> tree bindings document for these R5F subsystem devices. These R5F
> processors do not have an MMU, and so require fixed memory carveout
> regions matching the firmware image addresses. The nodes require more
> than one memory region, with the first memory region used for DMA
> allocations at runtime. The remaining memory regions are reserved
> and are used for the loading and running of the R5F remote processors.
>
> The added example illustrates the DT nodes for the single R5FSS device
> present on K3 AM65x family of SoCs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/84504be0/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 09/26] remoteproc: Introduce K3 remoteproc driver for R5F subsystem
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (7 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 08/26] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:24 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 10/26] dt-bindings: remoteproc: Add bindings for DSP C66x clusters on TI K3 SoCs Lokesh Vutla
` (16 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
SoCs with K3 architecture have an integrated Arm Cortex-R5F subsystem
that is comprised of dual-core Arm Cortex-R5F processor cores. This R5
subsytem can be configured at boot time to be either run in a LockStep
mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
This subsystem has each Tightly-Coupled Memory (TCM) internal memories
for each core split between two banks - TCMA and TCMB.
Add a remoteproc driver to support this subsystem to be able to load
and boot the R5 cores primarily in LockStep mode or split mode.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_r5f_rproc.c | 816 +++++++++++++++++++++++++++
3 files changed, 827 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_r5f_rproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f54a245424..c2d59ba000 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -52,6 +52,16 @@ config REMOTEPROC_TI_K3_ARM64
on various TI K3 family of SoCs through the remote processor
framework.
+config REMOTEPROC_TI_K3_R5F
+ bool "TI K3 R5F remoteproc support"
+ select REMOTEPROC
+ depends on ARCH_K3
+ depends on TI_SCI_PROTOCOL
+ help
+ Say y here to support TI's R5F remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
config REMOTEPROC_TI_POWER
bool "Support for TI Power processor"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 271ba55b09..9d247ba5e7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,4 +11,5 @@ obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
+obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c b/drivers/remoteproc/ti_k3_r5f_rproc.c
new file mode 100644
index 0000000000..ae1e4b9e04
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
@@ -0,0 +1,816 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments' K3 R5 Remoteproc driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla <lokeshvutla@ti.com>
+ */
+
+#include <common.h>
+#include <dm.h>
+#include <remoteproc.h>
+#include <errno.h>
+#include <clk.h>
+#include <reset.h>
+#include <asm/io.h>
+#include <linux/kernel.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+#include "ti_sci_proc.h"
+
+/*
+ * R5F's view of this address can either be for ATCM or BTCM with the other
+ * at address 0x0 based on loczrama signal.
+ */
+#define K3_R5_TCM_DEV_ADDR 0x41010000
+
+/* R5 TI-SCI Processor Configuration Flags */
+#define PROC_BOOT_CFG_FLAG_R5_DBG_EN 0x00000001
+#define PROC_BOOT_CFG_FLAG_R5_DBG_NIDEN 0x00000002
+#define PROC_BOOT_CFG_FLAG_R5_LOCKSTEP 0x00000100
+#define PROC_BOOT_CFG_FLAG_R5_TEINIT 0x00000200
+#define PROC_BOOT_CFG_FLAG_R5_NMFI_EN 0x00000400
+#define PROC_BOOT_CFG_FLAG_R5_TCM_RSTBASE 0x00000800
+#define PROC_BOOT_CFG_FLAG_R5_BTCM_EN 0x00001000
+#define PROC_BOOT_CFG_FLAG_R5_ATCM_EN 0x00002000
+#define PROC_BOOT_CFG_FLAG_GEN_IGN_BOOTVECTOR 0x10000000
+
+/* R5 TI-SCI Processor Control Flags */
+#define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT 0x00000001
+
+/* R5 TI-SCI Processor Status Flags */
+#define PROC_BOOT_STATUS_FLAG_R5_WFE 0x00000001
+#define PROC_BOOT_STATUS_FLAG_R5_WFI 0x00000002
+#define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED 0x00000004
+#define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED 0x00000100
+
+#define NR_CORES 2
+
+enum cluster_mode {
+ CLUSTER_MODE_SPLIT = 0,
+ CLUSTER_MODE_LOCKSTEP,
+};
+
+/**
+ * struct k3_r5_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from remoteproc view
+ * @size: Size of the memory region
+ */
+struct k3_r5f_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_r5f_core - K3 R5 core structure
+ * @dev: cached device pointer
+ * @cluster: pointer to the parent cluster.
+ * @reset: reset control handle
+ * @tsp: TI-SCI processor control handle
+ * @mem: Array of available internal memories
+ * @num_mem: Number of available memories
+ * @atcm_enable: flag to control ATCM enablement
+ * @btcm_enable: flag to control BTCM enablement
+ * @loczrama: flag to dictate which TCM is at device address 0x0
+ * @in_use: flag to tell if the core is already in use.
+ */
+struct k3_r5f_core {
+ struct udevice *dev;
+ struct k3_r5f_cluster *cluster;
+ struct reset_ctl reset;
+ struct ti_sci_proc tsp;
+ struct k3_r5f_mem *mem;
+ int num_mems;
+ u32 atcm_enable;
+ u32 btcm_enable;
+ u32 loczrama;
+ bool in_use;
+};
+
+/**
+ * struct k3_r5f_cluster - K3 R5F Cluster structure
+ * @mode: Mode to configure the Cluster - Split or LockStep
+ * @cores: Array of pointers to R5 cores within the cluster
+ */
+struct k3_r5f_cluster {
+ enum cluster_mode mode;
+ struct k3_r5f_core *cores[NR_CORES];
+};
+
+static bool is_primary_core(struct k3_r5f_core *core)
+{
+ return core == core->cluster->cores[0];
+}
+
+static int k3_r5f_proc_request(struct k3_r5f_core *core)
+{
+ struct k3_r5f_cluster *cluster = core->cluster;
+ int i, ret;
+
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
+ for (i = 0; i < NR_CORES; i++) {
+ ret = ti_sci_proc_request(&cluster->cores[i]->tsp);
+ if (ret)
+ goto proc_release;
+ }
+ } else {
+ ret = ti_sci_proc_request(&core->tsp);
+ }
+
+ return 0;
+
+proc_release:
+ while (i >= 0) {
+ ti_sci_proc_release(&cluster->cores[i]->tsp);
+ i--;
+ }
+ return ret;
+}
+
+static void k3_r5f_proc_release(struct k3_r5f_core *core)
+{
+ struct k3_r5f_cluster *cluster = core->cluster;
+ int i;
+
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP)
+ for (i = 0; i < NR_CORES; i++)
+ ti_sci_proc_release(&cluster->cores[i]->tsp);
+ else
+ ti_sci_proc_release(&core->tsp);
+}
+
+static int k3_r5f_lockstep_release(struct k3_r5f_cluster *cluster)
+{
+ int ret, c;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ for (c = NR_CORES - 1; c >= 0; c--) {
+ ret = ti_sci_proc_power_domain_on(&cluster->cores[c]->tsp);
+ if (ret)
+ goto unroll_module_reset;
+ }
+
+ /* deassert local reset on all applicable cores */
+ for (c = NR_CORES - 1; c >= 0; c--) {
+ ret = reset_deassert(&cluster->cores[c]->reset);
+ if (ret)
+ goto unroll_local_reset;
+ }
+
+ return 0;
+
+unroll_local_reset:
+ while (c < NR_CORES) {
+ reset_assert(&cluster->cores[c]->reset);
+ c++;
+ }
+ c = 0;
+unroll_module_reset:
+ while (c < NR_CORES) {
+ ti_sci_proc_power_domain_off(&cluster->cores[c]->tsp);
+ c++;
+ }
+
+ return ret;
+}
+
+static int k3_r5f_split_release(struct k3_r5f_core *core)
+{
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ret = ti_sci_proc_power_domain_on(&core->tsp);
+ if (ret) {
+ dev_err(core->dev, "module-reset deassert failed, ret = %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = reset_deassert(&core->reset);
+ if (ret) {
+ dev_err(core->dev, "local-reset deassert failed, ret = %d\n",
+ ret);
+ if (ti_sci_proc_power_domain_off(&core->tsp))
+ dev_warn(core->dev, "module-reset assert back failed\n");
+ }
+
+ return ret;
+}
+
+static int k3_r5f_prepare(struct udevice *dev)
+{
+ struct k3_r5f_core *core = dev_get_priv(dev);
+ struct k3_r5f_cluster *cluster = core->cluster;
+ int ret = 0;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP)
+ ret = k3_r5f_lockstep_release(cluster);
+ else
+ ret = k3_r5f_split_release(core);
+
+ if (ret)
+ dev_err(dev, "Unable to enable cores for TCM loading %d\n",
+ ret);
+
+ return ret;
+}
+
+static int k3_r5f_core_sanity_check(struct k3_r5f_core *core)
+{
+ struct k3_r5f_cluster *cluster = core->cluster;
+
+ if (core->in_use) {
+ dev_err(dev, "Invalid op: Trying to load/start on already running core %d\n",
+ core->tsp.proc_id);
+ return -EINVAL;
+ }
+
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP && !cluster->cores[1]) {
+ printf("Secondary core is not probed in this cluster\n");
+ return -EAGAIN;
+ }
+
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP && !is_primary_core(core)) {
+ dev_err(dev, "Invalid op: Trying to start secondary core %d in lockstep mode\n",
+ core->tsp.proc_id);
+ return -EINVAL;
+ }
+
+ if (cluster->mode == CLUSTER_MODE_SPLIT && !is_primary_core(core)) {
+ if (!core->cluster->cores[0]->in_use) {
+ dev_err(dev, "Invalid seq: Enable primary core before loading secondary core\n");
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * k3_r5f_load() - Load up the Remote processor image
+ * @dev: rproc device pointer
+ * @addr: Address at which image is available
+ * @size: size of the image
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_r5f_load(struct udevice *dev, ulong addr, ulong size)
+{
+ struct k3_r5f_core *core = dev_get_priv(dev);
+ u32 boot_vector;
+ int ret;
+
+ dev_dbg(dev, "%s addr = 0x%lx, size = 0x%lx\n", __func__, addr, size);
+
+ ret = k3_r5f_core_sanity_check(core);
+ if (ret)
+ return ret;
+
+ ret = k3_r5f_proc_request(core);
+ if (ret)
+ return ret;
+
+ ret = k3_r5f_prepare(dev);
+ if (ret) {
+ dev_err(dev, "R5f prepare failed for core %d\n",
+ core->tsp.proc_id);
+ goto proc_release;
+ }
+
+ /* Zero out TCMs so that ECC can be effective on all TCM addresses */
+ if (core->atcm_enable)
+ memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size);
+ if (core->btcm_enable)
+ memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size);
+
+ ret = rproc_elf_load_image(dev, addr, size);
+ if (ret < 0) {
+ dev_err(dev, "Loading elf failedi %d\n", ret);
+ goto proc_release;
+ }
+
+ boot_vector = rproc_elf_get_boot_addr(dev, addr);
+
+ dev_dbg(dev, "%s: Boot vector = 0x%x\n", __func__, boot_vector);
+
+ ret = ti_sci_proc_set_config(&core->tsp, boot_vector, 0, 0);
+
+proc_release:
+ k3_r5f_proc_release(core);
+
+ return ret;
+}
+
+static int k3_r5f_core_halt(struct k3_r5f_core *core)
+{
+ int ret;
+
+ ret = ti_sci_proc_set_control(&core->tsp,
+ PROC_BOOT_CTRL_FLAG_R5_CORE_HALT, 0);
+ if (ret)
+ dev_err(core->dev, "Core %d failed to stop\n",
+ core->tsp.proc_id);
+
+ return ret;
+}
+
+static int k3_r5f_core_run(struct k3_r5f_core *core)
+{
+ int ret;
+
+ ret = ti_sci_proc_set_control(&core->tsp,
+ 0, PROC_BOOT_CTRL_FLAG_R5_CORE_HALT);
+ if (ret) {
+ dev_err(core->dev, "Core %d failed to start\n",
+ core->tsp.proc_id);
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * k3_r5f_start() - Start the remote processor
+ * @dev: rproc device pointer
+ *
+ * Return: 0 if all went ok, else return appropriate error
+ */
+static int k3_r5f_start(struct udevice *dev)
+{
+ struct k3_r5f_core *core = dev_get_priv(dev);
+ struct k3_r5f_cluster *cluster = core->cluster;
+ int ret, c;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ret = k3_r5f_core_sanity_check(core);
+ if (ret)
+ return ret;
+
+ ret = k3_r5f_proc_request(core);
+ if (ret)
+ return ret;
+
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
+ if (is_primary_core(core)) {
+ for (c = NR_CORES - 1; c >= 0; c--) {
+ ret = k3_r5f_core_run(cluster->cores[c]);
+ if (ret)
+ goto unroll_core_run;
+ }
+ } else {
+ dev_err(dev, "Invalid op: Trying to start secondary core %d in lockstep mode\n",
+ core->tsp.proc_id);
+ ret = -EINVAL;
+ goto proc_release;
+ }
+ } else {
+ ret = k3_r5f_core_run(core);
+ if (ret)
+ goto proc_release;
+ }
+
+ core->in_use = true;
+
+ k3_r5f_proc_release(core);
+ return 0;
+
+unroll_core_run:
+ while (c < NR_CORES) {
+ k3_r5f_core_halt(cluster->cores[c]);
+ c++;
+ }
+proc_release:
+ k3_r5f_proc_release(core);
+
+ return ret;
+}
+
+static int k3_r5f_split_reset(struct k3_r5f_core *core)
+{
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (reset_assert(&core->reset))
+ ret = -EINVAL;
+
+ if (ti_sci_proc_power_domain_off(&core->tsp))
+ ret = -EINVAL;
+
+ return ret;
+}
+
+static int k3_r5f_lockstep_reset(struct k3_r5f_cluster *cluster)
+{
+ int ret = 0, c;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ for (c = 0; c < NR_CORES; c++)
+ if (reset_assert(&cluster->cores[c]->reset))
+ ret = -EINVAL;
+
+ /* disable PSC modules on all applicable cores */
+ for (c = 0; c < NR_CORES; c++)
+ if (ti_sci_proc_power_domain_off(&cluster->cores[c]->tsp))
+ ret = -EINVAL;
+
+ return ret;
+}
+
+static int k3_r5f_unprepare(struct udevice *dev)
+{
+ struct k3_r5f_core *core = dev_get_priv(dev);
+ struct k3_r5f_cluster *cluster = core->cluster;
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
+ if (is_primary_core(core))
+ ret = k3_r5f_lockstep_reset(cluster);
+ } else {
+ ret = k3_r5f_split_reset(core);
+ }
+
+ if (ret)
+ dev_warn(dev, "Unable to enable cores for TCM loading %d\n",
+ ret);
+
+ return 0;
+}
+
+static int k3_r5f_stop(struct udevice *dev)
+{
+ struct k3_r5f_core *core = dev_get_priv(dev);
+ struct k3_r5f_cluster *cluster = core->cluster;
+ int c, ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ret = k3_r5f_proc_request(core);
+ if (ret)
+ return ret;
+
+ core->in_use = false;
+
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
+ if (is_primary_core(core)) {
+ for (c = 0; c < NR_CORES; c++)
+ k3_r5f_core_halt(cluster->cores[c]);
+ } else {
+ dev_err(dev, "Invalid op: Trying to stop secondary core in lockstep mode\n");
+ ret = -EINVAL;
+ goto proc_release;
+ }
+ } else {
+ k3_r5f_core_halt(core);
+ }
+
+ ret = k3_r5f_unprepare(dev);
+proc_release:
+ k3_r5f_proc_release(core);
+ return ret;
+}
+
+static void *k3_r5f_da_to_va(struct udevice *dev, ulong da, ulong size)
+{
+ struct k3_r5f_core *core = dev_get_priv(dev);
+ void __iomem *va = NULL;
+ phys_addr_t bus_addr;
+ u32 dev_addr, offset;
+ ulong mem_size;
+ int i;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (size <= 0)
+ return NULL;
+
+ for (i = 0; i < core->num_mems; i++) {
+ bus_addr = core->mem[i].bus_addr;
+ dev_addr = core->mem[i].dev_addr;
+ mem_size = core->mem[i].size;
+
+ if (da >= bus_addr && (da + size) <= (bus_addr + mem_size)) {
+ offset = da - bus_addr;
+ va = core->mem[i].cpu_addr + offset;
+ return (__force void *)va;
+ }
+
+ if (da >= dev_addr && (da + size) <= (dev_addr + mem_size)) {
+ offset = da - dev_addr;
+ va = core->mem[i].cpu_addr + offset;
+ return (__force void *)va;
+ }
+ }
+
+ /* Assume it is DDR region and return da */
+ return map_physmem(da, size, MAP_NOCACHE);
+}
+
+static int k3_r5f_init(struct udevice *dev)
+{
+ return 0;
+}
+
+static int k3_r5f_reset(struct udevice *dev)
+{
+ return 0;
+}
+
+static const struct dm_rproc_ops k3_r5f_rproc_ops = {
+ .init = k3_r5f_init,
+ .reset = k3_r5f_reset,
+ .start = k3_r5f_start,
+ .stop = k3_r5f_stop,
+ .load = k3_r5f_load,
+ .device_to_virt = k3_r5f_da_to_va,
+};
+
+static int k3_r5f_rproc_configure(struct k3_r5f_core *core)
+{
+ struct k3_r5f_cluster *cluster = core->cluster;
+ u32 set_cfg = 0, clr_cfg = 0, cfg, ctrl, sts;
+ u64 boot_vec = 0;
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ret = ti_sci_proc_request(&core->tsp);
+ if (ret < 0)
+ return ret;
+
+ /* Do not touch boot vector now. Load will take care of it. */
+ clr_cfg |= PROC_BOOT_CFG_FLAG_GEN_IGN_BOOTVECTOR;
+
+ ret = ti_sci_proc_get_status(&core->tsp, &boot_vec, &cfg, &ctrl, &sts);
+ if (ret)
+ goto out;
+
+ /* Sanity check for Lockstep mode */
+ if (cluster->mode && is_primary_core(core) &&
+ !(sts & PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED)) {
+ dev_err(core->dev, "LockStep mode not permitted on this device\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* Primary core only configuration */
+ if (is_primary_core(core)) {
+ /* always enable ARM mode */
+ clr_cfg |= PROC_BOOT_CFG_FLAG_R5_TEINIT;
+ if (cluster->mode == CLUSTER_MODE_LOCKSTEP)
+ set_cfg |= PROC_BOOT_CFG_FLAG_R5_LOCKSTEP;
+ else
+ clr_cfg |= PROC_BOOT_CFG_FLAG_R5_LOCKSTEP;
+ }
+
+ if (core->atcm_enable)
+ set_cfg |= PROC_BOOT_CFG_FLAG_R5_ATCM_EN;
+ else
+ clr_cfg |= PROC_BOOT_CFG_FLAG_R5_ATCM_EN;
+
+ if (core->btcm_enable)
+ set_cfg |= PROC_BOOT_CFG_FLAG_R5_BTCM_EN;
+ else
+ clr_cfg |= PROC_BOOT_CFG_FLAG_R5_BTCM_EN;
+
+ if (core->loczrama)
+ set_cfg |= PROC_BOOT_CFG_FLAG_R5_TCM_RSTBASE;
+ else
+ clr_cfg |= PROC_BOOT_CFG_FLAG_R5_TCM_RSTBASE;
+
+ ret = k3_r5f_core_halt(core);
+ if (ret)
+ goto out;
+
+ ret = ti_sci_proc_set_config(&core->tsp, boot_vec, set_cfg, clr_cfg);
+out:
+ ti_sci_proc_release(&core->tsp);
+ return ret;
+}
+
+static int ti_sci_proc_of_to_priv(struct udevice *dev, struct ti_sci_proc *tsp)
+{
+ u32 ids[2];
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ tsp->sci = ti_sci_get_by_phandle(dev, "ti,sci");
+ if (IS_ERR(tsp->sci)) {
+ dev_err(dev, "ti_sci get failed: %ld\n", PTR_ERR(tsp->sci));
+ return PTR_ERR(tsp->sci);
+ }
+
+ ret = dev_read_u32_array(dev, "ti,sci-proc-ids", ids, 2);
+ if (ret) {
+ dev_err(dev, "Proc IDs not populated %d\n", ret);
+ return ret;
+ }
+
+ tsp->ops = &tsp->sci->ops.proc_ops;
+ tsp->proc_id = ids[0];
+ tsp->host_id = ids[1];
+ tsp->dev_id = dev_read_u32_default(dev, "ti,sci-dev-id",
+ TI_SCI_RESOURCE_NULL);
+ if (tsp->dev_id == TI_SCI_RESOURCE_NULL) {
+ dev_err(dev, "Device ID not populated %d\n", ret);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int k3_r5f_of_to_priv(struct k3_r5f_core *core)
+{
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ core->atcm_enable = dev_read_u32_default(core->dev, "atcm-enable", 0);
+ core->btcm_enable = dev_read_u32_default(core->dev, "btcm-enable", 1);
+ core->loczrama = dev_read_u32_default(core->dev, "loczrama", 1);
+
+ ret = ti_sci_proc_of_to_priv(core->dev, &core->tsp);
+ if (ret)
+ return ret;
+
+ ret = reset_get_by_index(core->dev, 0, &core->reset);
+ if (ret) {
+ dev_err(core->dev, "Reset lines not available: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int k3_r5f_core_of_get_memories(struct k3_r5f_core *core)
+{
+ static const char * const mem_names[] = {"atcm", "btcm"};
+ struct udevice *dev = core->dev;
+ int i;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ core->num_mems = ARRAY_SIZE(mem_names);
+ core->mem = calloc(core->num_mems, sizeof(*core->mem));
+ if (!core->mem)
+ return -ENOMEM;
+
+ for (i = 0; i < core->num_mems; i++) {
+ core->mem[i].bus_addr = dev_read_addr_size_name(dev,
+ mem_names[i],
+ (fdt_addr_t *)&core->mem[i].size);
+ if (core->mem[i].bus_addr == FDT_ADDR_T_NONE) {
+ dev_err(dev, "%s bus address not found\n",
+ mem_names[i]);
+ return -EINVAL;
+ }
+ core->mem[i].cpu_addr = map_physmem(core->mem[i].bus_addr,
+ core->mem[i].size,
+ MAP_NOCACHE);
+ if (!strcmp(mem_names[i], "atcm")) {
+ core->mem[i].dev_addr = core->loczrama ?
+ 0 : K3_R5_TCM_DEV_ADDR;
+ } else {
+ core->mem[i].dev_addr = core->loczrama ?
+ K3_R5_TCM_DEV_ADDR : 0;
+ }
+
+ dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %p da 0x%x\n",
+ mem_names[i], &core->mem[i].bus_addr,
+ core->mem[i].size, core->mem[i].cpu_addr,
+ core->mem[i].dev_addr);
+ }
+
+ return 0;
+}
+
+/**
+ * k3_r5f_probe() - Basic probe
+ * @dev: corresponding k3 remote processor device
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_r5f_probe(struct udevice *dev)
+{
+ struct k3_r5f_cluster *cluster = dev_get_priv(dev->parent);
+ struct k3_r5f_core *core = dev_get_priv(dev);
+ bool r_state;
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ core->dev = dev;
+ ret = k3_r5f_of_to_priv(core);
+ if (ret)
+ return ret;
+
+ core->cluster = cluster;
+ /* Assume Primary core gets probed first */
+ if (!cluster->cores[0])
+ cluster->cores[0] = core;
+ else
+ cluster->cores[1] = core;
+
+ ret = k3_r5f_core_of_get_memories(core);
+ if (ret) {
+ dev_err(dev, "Rproc getting internal memories failed\n");
+ return ret;
+ }
+
+ ret = core->tsp.sci->ops.dev_ops.is_on(core->tsp.sci, core->tsp.dev_id,
+ &r_state, &core->in_use);
+ if (ret)
+ return ret;
+
+ if (core->in_use) {
+ dev_info(dev, "Core %d is already in use. No rproc commands work\n",
+ core->tsp.proc_id);
+ return 0;
+ }
+
+ /* Make sure Local reset is asserted. Redundant? */
+ reset_assert(&core->reset);
+
+ ret = k3_r5f_rproc_configure(core);
+ if (ret) {
+ dev_err(dev, "rproc configure failed %d\n", ret);
+ return ret;
+ }
+
+ dev_dbg(dev, "Remoteproc successfully probed\n");
+
+ return 0;
+}
+
+static int k3_r5f_remove(struct udevice *dev)
+{
+ struct k3_r5f_core *core = dev_get_priv(dev);
+
+ free(core->mem);
+
+ ti_sci_proc_release(&core->tsp);
+
+ return 0;
+}
+
+static const struct udevice_id k3_r5f_rproc_ids[] = {
+ { .compatible = "ti,am654-r5f"},
+ { .compatible = "ti,j721e-r5f"},
+ {}
+};
+
+U_BOOT_DRIVER(k3_r5f_rproc) = {
+ .name = "k3_r5f_rproc",
+ .of_match = k3_r5f_rproc_ids,
+ .id = UCLASS_REMOTEPROC,
+ .ops = &k3_r5f_rproc_ops,
+ .probe = k3_r5f_probe,
+ .remove = k3_r5f_remove,
+ .priv_auto_alloc_size = sizeof(struct k3_r5f_core),
+};
+
+static int k3_r5f_cluster_probe(struct udevice *dev)
+{
+ struct k3_r5f_cluster *cluster = dev_get_priv(dev);
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ cluster->mode = dev_read_u32_default(dev, "lockstep-mode",
+ CLUSTER_MODE_LOCKSTEP);
+
+ if (device_get_child_count(dev) != 2) {
+ dev_err(dev, "Invalid number of R5 cores");
+ return -EINVAL;
+ }
+
+ dev_dbg(dev, "%s: Cluster successfully probed in %s mode\n",
+ __func__, cluster->mode ? "lockstep" : "split");
+
+ return 0;
+}
+
+static const struct udevice_id k3_r5fss_ids[] = {
+ { .compatible = "ti,am654-r5fss"},
+ { .compatible = "ti,j721e-r5fss"},
+ {}
+};
+
+U_BOOT_DRIVER(k3_r5fss) = {
+ .name = "k3_r5fss",
+ .of_match = k3_r5fss_ids,
+ .id = UCLASS_MISC,
+ .probe = k3_r5f_cluster_probe,
+ .priv_auto_alloc_size = sizeof(struct k3_r5f_cluster),
+};
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 09/26] remoteproc: Introduce K3 remoteproc driver for R5F subsystem
2019-09-04 10:31 ` [U-Boot] [PATCH v2 09/26] remoteproc: Introduce K3 remoteproc driver for R5F subsystem Lokesh Vutla
@ 2019-10-12 20:24 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:24 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:34PM +0530, Lokesh Vutla wrote:
> SoCs with K3 architecture have an integrated Arm Cortex-R5F subsystem
> that is comprised of dual-core Arm Cortex-R5F processor cores. This R5
> subsytem can be configured at boot time to be either run in a LockStep
> mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
> This subsystem has each Tightly-Coupled Memory (TCM) internal memories
> for each core split between two banks - TCMA and TCMB.
>
> Add a remoteproc driver to support this subsystem to be able to load
> and boot the R5 cores primarily in LockStep mode or split mode.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/460cb0ef/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 10/26] dt-bindings: remoteproc: Add bindings for DSP C66x clusters on TI K3 SoCs
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (8 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 09/26] remoteproc: Introduce K3 remoteproc driver for R5F subsystem Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 11/26] remoteproc: Introduce K3 C66 and C71 remoteproc driver Lokesh Vutla
` (15 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
Add the device tree bindings document for the C66x DSP devices on these
SoCs. The added example illustrates the DT nodes for the first C66x DSP
device present on the K3 J721E family of SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../remoteproc/ti,k3-dsp-rproc.txt | 101 ++++++++++++++++++
1 file changed, 101 insertions(+)
create mode 100644 doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt
diff --git a/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt b/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt
new file mode 100644
index 0000000000..80ab7a4090
--- /dev/null
+++ b/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt
@@ -0,0 +1,101 @@
+TI K3 DSP devices
+=================
+
+The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems that
+are used to offload some of the processor-intensive tasks or algorithms, for
+achieving various system level goals.
+
+These processor sub-systems usually contain additional sub-modules like L1
+and/or L2 caches/SRAMs, an Interrupt Controller, an external memory controller,
+a dedicated local power/sleep controller etc. The DSP processor cores in the
+K3 SoCs is usually either a TMS320C66x CorePac processor or a TMS320C71x CorePac
+processor.
+
+DSP Device Node:
+================
+Each DSP Core sub-system is represented as a single DT node. Each node has a
+number of required or optional properties that enable the OS running on the
+host processor (Arm CorePac) to perform the device management of the remote
+processor and to communicate with the remote processor.
+
+Required properties:
+--------------------
+The following are the mandatory properties:
+
+- compatible: Should be one of the following,
+ "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
+ "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs
+
+- reg: Should contain an entry for each value in 'reg-names'.
+ Each entry should have the memory region's start address
+ and the size of the region, the representation matching
+ the parent node's '#address-cells' and '#size-cells' values.
+
+- reg-names: Should contain strings with the following names, each
+ representing a specific internal memory region (if
+ present), and should be defined in this order,
+ "l2sram", "l1pram", "l1dram"
+ NOTE: C71x DSPs do not have a "l1pram" memory.
+
+- ti,sci: Should be a phandle to the TI-SCI System Controller node
+
+- ti,sci-dev-id: Should contain the TI-SCI device id corresponding to the
+ DSP Core. Please refer to the corresponding System
+ Controller documentation for valid values for the DSP
+ cores.
+
+- ti,sci-proc-ids: Should contain 2 integer values. The first cell should
+ contain the TI-SCI processor id for the DSP core device
+ and the second cell should contain the TI-SCI host id to
+ which the processor control ownership should be
+ transferred to.
+
+- resets: Should contain the phandle to the reset controller node
+ managing the resets for this device, and a reset
+ specifier. Please refer to the following reset bindings
+ for the reset argument specifier,
+ Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+
+Example:
+---------
+
+1. J721E SoC
+ /* J721E remoteproc alias */
+ aliases {
+ rproc6 = &c66_0;
+ rproc8 = &c71_0;
+ };
+
+ cbass_main: interconnect at 100000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x64800000 0x00 0x64800000 0x00 0x00800000>, /* C71_0 */
+ <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
+ <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
+
+ /* J721E C66_0 DSP node */
+ c66_0: dsp at 4d80800000 {
+ compatible = "ti,j721e-c66-dsp";
+ reg = <0x4d 0x80800000 0x00 0x00048000>,
+ <0x4d 0x80e00000 0x00 0x00008000>,
+ <0x4d 0x80f00000 0x00 0x00008000>;
+ reg-names = "l2sram", "l1pram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <142>;
+ ti,sci-proc-ids = <0x03 0xFF>;
+ resets = <&k3_reset 142 1>;
+ };
+
+ /* J721E C71_0 DSP node */
+ c71_0: dsp at 64800000 {
+ compatible = "ti,j721e-c71-dsp";
+ reg = <0x00 0x64800000 0x00 0x00080000>,
+ <0x00 0x64e00000 0x00 0x0000c000>;
+ reg-names = "l2sram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <15>;
+ ti,sci-proc-ids = <0x30 0xFF>;
+ resets = <&k3_reset 15 1>;
+ };
+ };
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 11/26] remoteproc: Introduce K3 C66 and C71 remoteproc driver
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (9 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 10/26] dt-bindings: remoteproc: Add bindings for DSP C66x clusters on TI K3 SoCs Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 12/26] arm: dts: k3-j721e-mcu: Add MCU domain R5F cluster node Lokesh Vutla
` (14 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
Certain SoCs with K3 architecture have integrated a C66 Corepac DSP
subsystem and an advanced C71 DSPs. Introduce a remoteproc driver
that that does take care of loading an elf to any of the specified
DSPs and start it.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_dsp_rproc.c | 354 +++++++++++++++++++++++++++
3 files changed, 365 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_dsp_rproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c2d59ba000..7c2e4804b5 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -52,6 +52,16 @@ config REMOTEPROC_TI_K3_ARM64
on various TI K3 family of SoCs through the remote processor
framework.
+config REMOTEPROC_TI_K3_DSP
+ bool "TI K3 C66 and C71 remoteproc support"
+ select REMOTEPROC
+ depends on ARCH_K3
+ depends on TI_SCI_PROTOCOL
+ help
+ Say y here to support TI's C66/C71 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
config REMOTEPROC_TI_K3_R5F
bool "TI K3 R5F remoteproc support"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 9d247ba5e7..69ae7bd1e8 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
+obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
diff --git a/drivers/remoteproc/ti_k3_dsp_rproc.c b/drivers/remoteproc/ti_k3_dsp_rproc.c
new file mode 100644
index 0000000000..c5dc6b25da
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_dsp_rproc.c
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments' K3 DSP Remoteproc driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla <lokeshvutla@ti.com>
+ *
+ */
+
+#include <common.h>
+#include <dm.h>
+#include <remoteproc.h>
+#include <errno.h>
+#include <clk.h>
+#include <reset.h>
+#include <asm/io.h>
+#include <power-domain.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+#include "ti_sci_proc.h"
+
+#define KEYSTONE_RPROC_LOCAL_ADDRESS_MASK (SZ_16M - 1)
+
+/**
+ * struct k3_dsp_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from remoteproc view
+ * @size: Size of the memory region
+ */
+struct k3_dsp_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ phys_addr_t dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_dsp_privdata - Structure representing Remote processor data.
+ * @rproc_rst: rproc reset control data
+ * @tsp: Pointer to TISCI proc contrl handle
+ * @mem: Array of available memories
+ * @num_mem: Number of available memories
+ */
+struct k3_dsp_privdata {
+ struct reset_ctl dsp_rst;
+ struct ti_sci_proc tsp;
+ struct k3_dsp_mem *mem;
+ int num_mems;
+};
+
+/**
+ * k3_dsp_load() - Load up the Remote processor image
+ * @dev: rproc device pointer
+ * @addr: Address at which image is available
+ * @size: size of the image
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_dsp_load(struct udevice *dev, ulong addr, ulong size)
+{
+ struct k3_dsp_privdata *dsp = dev_get_priv(dev);
+ u32 boot_vector;
+ int ret;
+
+ dev_dbg(dev, "%s addr = 0x%lx, size = 0x%lx\n", __func__, addr, size);
+ ret = ti_sci_proc_request(&dsp->tsp);
+ if (ret)
+ return ret;
+
+ ret = rproc_elf_load_image(dev, addr, size);
+ if (ret < 0) {
+ dev_err(dev, "Loading elf failed %d\n", ret);
+ goto proc_release;
+ }
+
+ boot_vector = rproc_elf_get_boot_addr(dev, addr);
+
+ dev_dbg(dev, "%s: Boot vector = 0x%x\n", __func__, boot_vector);
+
+ ret = ti_sci_proc_set_config(&dsp->tsp, boot_vector, 0, 0);
+proc_release:
+ ti_sci_proc_release(&dsp->tsp);
+ return ret;
+}
+
+/**
+ * k3_dsp_start() - Start the remote processor
+ * @dev: rproc device pointer
+ *
+ * Return: 0 if all went ok, else return appropriate error
+ */
+static int k3_dsp_start(struct udevice *dev)
+{
+ struct k3_dsp_privdata *dsp = dev_get_priv(dev);
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ret = ti_sci_proc_request(&dsp->tsp);
+ if (ret)
+ return ret;
+ /*
+ * Setting the right clock frequency would have taken care by
+ * assigned-clock-rates during the device probe. So no need to
+ * set the frequency again here.
+ */
+ ret = ti_sci_proc_power_domain_on(&dsp->tsp);
+ if (ret)
+ goto proc_release;
+
+ ret = reset_deassert(&dsp->dsp_rst);
+
+proc_release:
+ ti_sci_proc_release(&dsp->tsp);
+
+ return ret;
+}
+
+static int k3_dsp_stop(struct udevice *dev)
+{
+ struct k3_dsp_privdata *dsp = dev_get_priv(dev);
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ti_sci_proc_request(&dsp->tsp);
+ reset_assert(&dsp->dsp_rst);
+ ti_sci_proc_power_domain_off(&dsp->tsp);
+ ti_sci_proc_release(&dsp->tsp);
+
+ return 0;
+}
+
+/**
+ * k3_dsp_init() - Initialize the remote processor
+ * @dev: rproc device pointer
+ *
+ * Return: 0 if all went ok, else return appropriate error
+ */
+static int k3_dsp_init(struct udevice *dev)
+{
+ dev_dbg(dev, "%s\n", __func__);
+
+ return 0;
+}
+
+static int k3_dsp_reset(struct udevice *dev)
+{
+ dev_dbg(dev, "%s\n", __func__);
+
+ return 0;
+}
+
+static void *k3_dsp_da_to_va(struct udevice *dev, ulong da, ulong len)
+{
+ struct k3_dsp_privdata *dsp = dev_get_priv(dev);
+ phys_addr_t bus_addr, dev_addr;
+ void __iomem *va = NULL;
+ size_t size;
+ u32 offset;
+ int i;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (len <= 0)
+ return NULL;
+
+ for (i = 0; i < dsp->num_mems; i++) {
+ bus_addr = dsp->mem[i].bus_addr;
+ dev_addr = dsp->mem[i].dev_addr;
+ size = dsp->mem[i].size;
+
+ if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
+ offset = da - dev_addr;
+ va = dsp->mem[i].cpu_addr + offset;
+ return (__force void *)va;
+ }
+
+ if (da >= bus_addr && (da + len) <= (bus_addr + size)) {
+ offset = da - bus_addr;
+ va = dsp->mem[i].cpu_addr + offset;
+ return (__force void *)va;
+ }
+ }
+
+ /* Assume it is DDR region and return da */
+ return map_physmem(da, len, MAP_NOCACHE);
+}
+
+static const struct dm_rproc_ops k3_dsp_ops = {
+ .init = k3_dsp_init,
+ .load = k3_dsp_load,
+ .start = k3_dsp_start,
+ .stop = k3_dsp_stop,
+ .reset = k3_dsp_reset,
+ .device_to_virt = k3_dsp_da_to_va,
+};
+
+static int ti_sci_proc_of_to_priv(struct udevice *dev, struct ti_sci_proc *tsp)
+{
+ u32 ids[2];
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ tsp->sci = ti_sci_get_by_phandle(dev, "ti,sci");
+ if (IS_ERR(tsp->sci)) {
+ dev_err(dev, "ti_sci get failed: %ld\n", PTR_ERR(tsp->sci));
+ return PTR_ERR(tsp->sci);
+ }
+
+ ret = dev_read_u32_array(dev, "ti,sci-proc-ids", ids, 2);
+ if (ret) {
+ dev_err(dev, "Proc IDs not populated %d\n", ret);
+ return ret;
+ }
+
+ tsp->ops = &tsp->sci->ops.proc_ops;
+ tsp->proc_id = ids[0];
+ tsp->host_id = ids[1];
+ tsp->dev_id = dev_read_u32_default(dev, "ti,sci-dev-id",
+ TI_SCI_RESOURCE_NULL);
+ if (tsp->dev_id == TI_SCI_RESOURCE_NULL) {
+ dev_err(dev, "Device ID not populated %d\n", ret);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int k3_dsp_of_get_memories(struct udevice *dev)
+{
+ static const char * const mem_names[] = {"l2sram", "l1pram", "l1dram"};
+ struct k3_dsp_privdata *dsp = dev_get_priv(dev);
+ int i;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ dsp->num_mems = ARRAY_SIZE(mem_names);
+ dsp->mem = calloc(dsp->num_mems, sizeof(*dsp->mem));
+ if (!dsp->mem)
+ return -ENOMEM;
+
+ for (i = 0; i < dsp->num_mems; i++) {
+ /* C71 cores only have a L1P Cache, there are no L1P SRAMs */
+ if (device_is_compatible(dev, "ti,j721e-c71-dsp") &&
+ !strcmp(mem_names[i], "l1pram")) {
+ dsp->mem[i].bus_addr = FDT_ADDR_T_NONE;
+ dsp->mem[i].dev_addr = FDT_ADDR_T_NONE;
+ dsp->mem[i].cpu_addr = NULL;
+ dsp->mem[i].size = 0;
+ continue;
+ }
+
+ dsp->mem[i].bus_addr = dev_read_addr_size_name(dev, mem_names[i],
+ (fdt_addr_t *)&dsp->mem[i].size);
+ if (dsp->mem[i].bus_addr == FDT_ADDR_T_NONE) {
+ dev_err(dev, "%s bus address not found\n", mem_names[i]);
+ return -EINVAL;
+ }
+ dsp->mem[i].cpu_addr = map_physmem(dsp->mem[i].bus_addr,
+ dsp->mem[i].size,
+ MAP_NOCACHE);
+ dsp->mem[i].dev_addr = dsp->mem[i].bus_addr &
+ KEYSTONE_RPROC_LOCAL_ADDRESS_MASK;
+
+ dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %p da %pa\n",
+ mem_names[i], &dsp->mem[i].bus_addr,
+ dsp->mem[i].size, dsp->mem[i].cpu_addr,
+ &dsp->mem[i].dev_addr);
+ }
+
+ return 0;
+}
+
+/**
+ * k3_of_to_priv() - generate private data from device tree
+ * @dev: corresponding k3 dsp processor device
+ * @dsp: pointer to driver specific private data
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_dsp_of_to_priv(struct udevice *dev, struct k3_dsp_privdata *dsp)
+{
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ret = reset_get_by_index(dev, 0, &dsp->dsp_rst);
+ if (ret) {
+ dev_err(dev, "reset_get() failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = ti_sci_proc_of_to_priv(dev, &dsp->tsp);
+ if (ret)
+ return ret;
+
+ ret = k3_dsp_of_get_memories(dev);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+/**
+ * k3_dsp_probe() - Basic probe
+ * @dev: corresponding k3 remote processor device
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_dsp_probe(struct udevice *dev)
+{
+ struct k3_dsp_privdata *dsp;
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ dsp = dev_get_priv(dev);
+
+ ret = k3_dsp_of_to_priv(dev, dsp);
+ if (ret) {
+ dev_dbg(dev, "%s: Probe failed with error %d\n", __func__, ret);
+ return ret;
+ }
+
+ dev_dbg(dev, "Remoteproc successfully probed\n");
+
+ return 0;
+}
+
+static int k3_dsp_remove(struct udevice *dev)
+{
+ struct k3_dsp_privdata *dsp = dev_get_priv(dev);
+
+ free(dsp->mem);
+
+ return 0;
+}
+
+static const struct udevice_id k3_dsp_ids[] = {
+ { .compatible = "ti,j721e-c66-dsp"},
+ { .compatible = "ti,j721e-c71-dsp"},
+ {}
+};
+
+U_BOOT_DRIVER(k3_dsp) = {
+ .name = "k3_dsp",
+ .of_match = k3_dsp_ids,
+ .id = UCLASS_REMOTEPROC,
+ .ops = &k3_dsp_ops,
+ .probe = k3_dsp_probe,
+ .remove = k3_dsp_remove,
+ .priv_auto_alloc_size = sizeof(struct k3_dsp_privdata),
+};
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 12/26] arm: dts: k3-j721e-mcu: Add MCU domain R5F cluster node
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (10 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 11/26] remoteproc: Introduce K3 C66 and C71 remoteproc driver Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 13/26] arm: dts: k3-j721e-main: Add MAIN domain R5F cluster nodes Lokesh Vutla
` (13 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.
Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5 cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in LockStep mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/dts/k3-j721e-common-proc-board.dts | 5 +++
arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 38 +++++++++++++++++++++
2 files changed, 43 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts b/arch/arm/dts/k3-j721e-common-proc-board.dts
index b5b8c3c5cc..070d21cd05 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -12,6 +12,11 @@
stdout-path = "serial2:115200n8";
bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
};
+
+ aliases {
+ remoteproc0 = &mcu_r5fss0_core0;
+ remoteproc1 = &mcu_r5fss0_core1;
+ };
};
&wkup_uart0 {
diff --git a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
index 1175fa9a50..b958b5b3c1 100644
--- a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
@@ -69,4 +69,42 @@
clocks = <&k3_clks 149 0>;
clock-names = "fclk";
};
+
+ mcu_r5fss0: r5fss at 41000000 {
+ compatible = "ti,j721e-r5fss";
+ lockstep-mode = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x41000000 0x00 0x41000000 0x20000>,
+ <0x41400000 0x00 0x41400000 0x20000>;
+ power-domains = <&k3_pds 249 TI_SCI_PD_EXCLUSIVE>;
+
+ mcu_r5fss0_core0: r5f at 41000000 {
+ compatible = "ti,j721e-r5f";
+ reg = <0x41000000 0x00008000>,
+ <0x41010000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <250>;
+ ti,sci-proc-ids = <0x01 0xFF>;
+ resets = <&k3_reset 250 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+
+ mcu_r5fss0_core1: r5f at 41400000 {
+ compatible = "ti,j721e-r5f";
+ reg = <0x41400000 0x00008000>,
+ <0x41410000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <251>;
+ ti,sci-proc-ids = <0x02 0xFF>;
+ resets = <&k3_reset 251 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+ };
};
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 12/26] arm: dts: k3-j721e-mcu: Add MCU domain R5F cluster node
2019-09-04 10:31 ` [U-Boot] [PATCH v2 12/26] arm: dts: k3-j721e-mcu: Add MCU domain R5F cluster node Lokesh Vutla
@ 2019-10-12 20:25 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:25 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:37PM +0530, Lokesh Vutla wrote:
> The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
> subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
> the MCU domain, and the remaining two clusters are present in the
> MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
> configured at boot time to be either run in a LockStep mode or in
> an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
> subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
> memories for each core split between two banks - ATCM and BTCM
> (further interleaved into two banks). There are some IP integration
> differences from standard Arm R5 clusters such as the absence of
> an ACP port, presence of an additional TI-specific Region Address
> Translater (RAT) module for translating 32-bit CPU addresses into
> larger system bus addresses etc.
>
> Add the DT node for the MCU domain R5F cluster/subsystem, the two
> R5 cores are added as child nodes to the main cluster/subsystem node.
> The cluster is configured to run in LockStep mode by default, with the
> ATCMs enabled to allow the R5 cores to execute code from DDR with
> boot-strapping code from ATCM. The inter-processor communication
> between the main A72 cores and these processors is achieved through
> shared memory and Mailboxes.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/88d11fd7/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 13/26] arm: dts: k3-j721e-main: Add MAIN domain R5F cluster nodes
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (11 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 12/26] arm: dts: k3-j721e-mcu: Add MCU domain R5F cluster node Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 14/26] arm: dts: k3-j721e-main: Add C66x DSP nodes Lokesh Vutla
` (12 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.
Add the DT nodes for these two MAIN domain R5F cluster/subsystems,
the two R5 cores are each added as child nodes to the corresponding
main cluster node. Configure SS0 in split mode an SS1 in lockstep mode,
with the ATCMs enabled to allow the R5 cores to execute code from DDR
with boot-strapping code from ATCM.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/dts/k3-j721e-common-proc-board.dts | 4 ++
arch/arm/dts/k3-j721e-main.dtsi | 76 +++++++++++++++++++++
2 files changed, 80 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts b/arch/arm/dts/k3-j721e-common-proc-board.dts
index 070d21cd05..21afdc8ce0 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -16,6 +16,10 @@
aliases {
remoteproc0 = &mcu_r5fss0_core0;
remoteproc1 = &mcu_r5fss0_core1;
+ remoteproc2 = &main_r5fss0_core0;
+ remoteproc3 = &main_r5fss0_core1;
+ remoteproc4 = &main_r5fss1_core0;
+ remoteproc5 = &main_r5fss1_core1;
};
};
diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
index 3445784293..59ca4e5686 100644
--- a/arch/arm/dts/k3-j721e-main.dtsi
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -228,4 +228,80 @@
ti,trm-icp = <0x8>;
dma-coherent;
};
+
+ main_r5fss0: r5fss at 5c00000 {
+ compatible = "ti,j721e-r5fss";
+ lockstep-mode = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x5c00000 0x00 0x5c00000 0x20000>,
+ <0x5d00000 0x00 0x5d00000 0x20000>;
+ power-domains = <&k3_pds 243 TI_SCI_PD_EXCLUSIVE>;
+
+ main_r5fss0_core0: r5f at 5c00000 {
+ compatible = "ti,j721e-r5f";
+ reg = <0x5c00000 0x00008000>,
+ <0x5c10000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <245>;
+ ti,sci-proc-ids = <0x06 0xFF>;
+ resets = <&k3_reset 245 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+
+ main_r5fss0_core1: r5f at 5d00000 {
+ compatible = "ti,j721e-r5f";
+ reg = <0x5d00000 0x00008000>,
+ <0x5d10000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <246>;
+ ti,sci-proc-ids = <0x07 0xFF>;
+ resets = <&k3_reset 246 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+ };
+
+ main_r5fss1: r5fss at 5e00000 {
+ compatible = "ti,j721e-r5fss";
+ lockstep-mode = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x5e00000 0x00 0x5e00000 0x20000>,
+ <0x5f00000 0x00 0x5f00000 0x20000>;
+ power-domains = <&k3_pds 244 TI_SCI_PD_EXCLUSIVE>;
+
+ main_r5fss1_core0: r5f at 5e00000 {
+ compatible = "ti,j721e-r5f";
+ reg = <0x5e00000 0x00008000>,
+ <0x5e10000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <247>;
+ ti,sci-proc-ids = <0x08 0xFF>;
+ resets = <&k3_reset 247 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+
+ main_r5fss1_core1: r5f at 5f00000 {
+ compatible = "ti,j721e-r5f";
+ reg = <0x5f00000 0x00008000>,
+ <0x5f10000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <248>;
+ ti,sci-proc-ids = <0x09 0xFF>;
+ resets = <&k3_reset 248 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+ };
};
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 13/26] arm: dts: k3-j721e-main: Add MAIN domain R5F cluster nodes
2019-09-04 10:31 ` [U-Boot] [PATCH v2 13/26] arm: dts: k3-j721e-main: Add MAIN domain R5F cluster nodes Lokesh Vutla
@ 2019-10-12 20:25 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:25 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:38PM +0530, Lokesh Vutla wrote:
> The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
> subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
> the MCU domain, and the remaining two clusters are present in the
> MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
> configured at boot time to be either run in a LockStep mode or in
> an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
> subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
> memories for each core split between two banks - ATCM and BTCM
> (further interleaved into two banks). There are some IP integration
> differences from standard Arm R5 clusters such as the absence of
> an ACP port, presence of an additional TI-specific Region Address
> Translater (RAT) module for translating 32-bit CPU addresses into
> larger system bus addresses etc.
>
> Add the DT nodes for these two MAIN domain R5F cluster/subsystems,
> the two R5 cores are each added as child nodes to the corresponding
> main cluster node. Configure SS0 in split mode an SS1 in lockstep mode,
> with the ATCMs enabled to allow the R5 cores to execute code from DDR
> with boot-strapping code from ATCM.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/674de0c5/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 14/26] arm: dts: k3-j721e-main: Add C66x DSP nodes
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (12 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 13/26] arm: dts: k3-j721e-main: Add MAIN domain R5F cluster nodes Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 15/26] arm: dts: k3-j721e-main: Add C71x DSP node Lokesh Vutla
` (11 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
The J721E SoCs have two TMS320C66x DSP Core Subsystems (C66x CorePacs)
in the MAIN voltage domain, each with a C66x Fixed/Floating-Point DSP
Core, and 32 KB of L1P & L1D configurable SRAMs/Cache and an additional
288 KB of L2 configurable SRAM/Cache. These subsystems do not have
an MMU but contain a Region Address Translator (RAT) sub-module for
translating 32-bit processor addresses into larger bus addresses.
The inter-processor communication between the main A72 cores and
these processors is achieved through shared memory and Mailboxes.
Add the DT nodes for these DSP processor sub-systems in the common
k3-j721e-main.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/dts/k3-j721e-common-proc-board.dts | 2 ++
arch/arm/dts/k3-j721e-main.dtsi | 24 +++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts b/arch/arm/dts/k3-j721e-common-proc-board.dts
index 21afdc8ce0..a548277718 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -20,6 +20,8 @@
remoteproc3 = &main_r5fss0_core1;
remoteproc4 = &main_r5fss1_core0;
remoteproc5 = &main_r5fss1_core1;
+ remoteproc6 = &c66_0;
+ remoteproc7 = &c66_1;
};
};
diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
index 59ca4e5686..c3aa0cdcf1 100644
--- a/arch/arm/dts/k3-j721e-main.dtsi
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -304,4 +304,28 @@
loczrama = <1>;
};
};
+
+ c66_0: dsp at 4d80800000 {
+ compatible = "ti,j721e-c66-dsp";
+ reg = <0x4d 0x80800000 0x00 0x00048000>,
+ <0x4d 0x80e00000 0x00 0x00008000>,
+ <0x4d 0x80f00000 0x00 0x00008000>;
+ reg-names = "l2sram", "l1pram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <142>;
+ ti,sci-proc-ids = <0x03 0xFF>;
+ resets = <&k3_reset 142 1>;
+ };
+
+ c66_1: dsp at 4d81800000 {
+ compatible = "ti,j721e-c66-dsp";
+ reg = <0x4d 0x81800000 0x00 0x00048000>,
+ <0x4d 0x81e00000 0x00 0x00008000>,
+ <0x4d 0x81f00000 0x00 0x00008000>;
+ reg-names = "l2sram", "l1pram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <143>;
+ ti,sci-proc-ids = <0x04 0xFF>;
+ resets = <&k3_reset 143 1>;
+ };
};
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 14/26] arm: dts: k3-j721e-main: Add C66x DSP nodes
2019-09-04 10:31 ` [U-Boot] [PATCH v2 14/26] arm: dts: k3-j721e-main: Add C66x DSP nodes Lokesh Vutla
@ 2019-10-12 20:25 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:25 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:39PM +0530, Lokesh Vutla wrote:
> The J721E SoCs have two TMS320C66x DSP Core Subsystems (C66x CorePacs)
> in the MAIN voltage domain, each with a C66x Fixed/Floating-Point DSP
> Core, and 32 KB of L1P & L1D configurable SRAMs/Cache and an additional
> 288 KB of L2 configurable SRAM/Cache. These subsystems do not have
> an MMU but contain a Region Address Translator (RAT) sub-module for
> translating 32-bit processor addresses into larger bus addresses.
> The inter-processor communication between the main A72 cores and
> these processors is achieved through shared memory and Mailboxes.
> Add the DT nodes for these DSP processor sub-systems in the common
> k3-j721e-main.dtsi file.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/6c1df2f5/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 15/26] arm: dts: k3-j721e-main: Add C71x DSP node
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (13 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 14/26] arm: dts: k3-j721e-main: Add C66x DSP nodes Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 16/26] arm: dts: k3-am65-mcu: Add MCU domain R5F DT nodes Lokesh Vutla
` (10 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
The J721E SoCs have a single TMS320C71x DSP Subsystem in the MAIN
voltage domain containing the next-generation C711 CPU core. The
subsystem has 32 KB of L1D configurable SRAM/Cache and 512 KB of
L2 configurable SRAM/Cache. This subsystem has a CMMU but is not
used currently. The inter-processor communication between the main
A72 cores and the C711 processor is achieved through shared memory
and a Mailbox. Add the DT node for this DSP processor sub-system
in the common k3-j721e-main.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/dts/k3-j721e-common-proc-board.dts | 1 +
arch/arm/dts/k3-j721e-main.dtsi | 11 +++++++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts b/arch/arm/dts/k3-j721e-common-proc-board.dts
index a548277718..b21f597a80 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -22,6 +22,7 @@
remoteproc5 = &main_r5fss1_core1;
remoteproc6 = &c66_0;
remoteproc7 = &c66_1;
+ remoteproc8 = &c71_0;
};
};
diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
index c3aa0cdcf1..6bd59bac52 100644
--- a/arch/arm/dts/k3-j721e-main.dtsi
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -328,4 +328,15 @@
ti,sci-proc-ids = <0x04 0xFF>;
resets = <&k3_reset 143 1>;
};
+
+ c71_0: dsp at 64800000 {
+ compatible = "ti,j721e-c71-dsp";
+ reg = <0x00 0x64800000 0x00 0x00080000>,
+ <0x00 0x64e00000 0x00 0x0000c000>;
+ reg-names = "l2sram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <15>;
+ ti,sci-proc-ids = <0x30 0xFF>;
+ resets = <&k3_reset 15 1>;
+ };
};
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 15/26] arm: dts: k3-j721e-main: Add C71x DSP node
2019-09-04 10:31 ` [U-Boot] [PATCH v2 15/26] arm: dts: k3-j721e-main: Add C71x DSP node Lokesh Vutla
@ 2019-10-12 20:25 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:25 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:40PM +0530, Lokesh Vutla wrote:
> The J721E SoCs have a single TMS320C71x DSP Subsystem in the MAIN
> voltage domain containing the next-generation C711 CPU core. The
> subsystem has 32 KB of L1D configurable SRAM/Cache and 512 KB of
> L2 configurable SRAM/Cache. This subsystem has a CMMU but is not
> used currently. The inter-processor communication between the main
> A72 cores and the C711 processor is achieved through shared memory
> and a Mailbox. Add the DT node for this DSP processor sub-system
> in the common k3-j721e-main.dtsi file.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/eda0177b/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 16/26] arm: dts: k3-am65-mcu: Add MCU domain R5F DT nodes
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (14 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 15/26] arm: dts: k3-j721e-main: Add C71x DSP node Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 17/26] env: ti: k3_rproc: Add common rproc environment variables Lokesh Vutla
` (9 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
The AM65x SoCs has a single dual-core Arm Cortex-R5F processor
subsystem/cluster (MCU_R5FSS0) within the MCU domain. This cluster
can be configured at boot time to be either run in a LockStep mode
or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
This subsystem has 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.
Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5 cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in Split-mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/dts/k3-am65-mcu.dtsi | 40 +++++++++++++++++++++++++++-
arch/arm/dts/k3-am654-base-board.dts | 5 ++++
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
index c9bfd9b80f..c42e7553c7 100644
--- a/arch/arm/dts/k3-am65-mcu.dtsi
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -2,7 +2,7 @@
/*
* Device Tree Source for AM6 SoC Family MCU Domain peripherals
*
- * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2016-2019 Texas Instruments Incorporated - http://www.ti.com/
*/
&cbass_mcu {
@@ -26,4 +26,42 @@
clocks = <&k3_clks 114 1>;
power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
};
+
+ mcu_r5fss0: r5fss at 41000000 {
+ compatible = "ti,am654-r5fss";
+ lockstep-mode = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x41000000 0x00 0x41000000 0x20000>,
+ <0x41400000 0x00 0x41400000 0x20000>;
+ power-domains = <&k3_pds 129 TI_SCI_PD_EXCLUSIVE>;
+
+ mcu_r5fss0_core0: r5f at 41000000 {
+ compatible = "ti,am654-r5f";
+ reg = <0x41000000 0x00008000>,
+ <0x41010000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <159>;
+ ti,sci-proc-ids = <0x01 0xFF>;
+ resets = <&k3_reset 159 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+
+ mcu_r5fss0_core1: r5f at 41400000 {
+ compatible = "ti,am654-r5f";
+ reg = <0x41400000 0x00008000>,
+ <0x41410000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <245>;
+ ti,sci-proc-ids = <0x02 0xFF>;
+ resets = <&k3_reset 245 1>;
+ atcm-enable = <1>;
+ btcm-enable = <1>;
+ loczrama = <1>;
+ };
+ };
};
diff --git a/arch/arm/dts/k3-am654-base-board.dts b/arch/arm/dts/k3-am654-base-board.dts
index e73b9aa6b1..573ead0b4d 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -17,6 +17,11 @@
bootargs = "earlycon=ns16550a,mmio32,0x02800000";
};
+ aliases {
+ remoteproc0 = &mcu_r5fss0_core0;
+ remoteproc1 = &mcu_r5fss0_core1;
+ };
+
memory at 80000000 {
device_type = "memory";
/* 4G RAM */
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 16/26] arm: dts: k3-am65-mcu: Add MCU domain R5F DT nodes
2019-09-04 10:31 ` [U-Boot] [PATCH v2 16/26] arm: dts: k3-am65-mcu: Add MCU domain R5F DT nodes Lokesh Vutla
@ 2019-10-12 20:25 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:25 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:41PM +0530, Lokesh Vutla wrote:
> From: Suman Anna <s-anna@ti.com>
>
> The AM65x SoCs has a single dual-core Arm Cortex-R5F processor
> subsystem/cluster (MCU_R5FSS0) within the MCU domain. This cluster
> can be configured at boot time to be either run in a LockStep mode
> or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
> This subsystem has 64 KB each Tightly-Coupled Memory (TCM) internal
> memories for each core split between two banks - ATCM and BTCM
> (further interleaved into two banks). There are some IP integration
> differences from standard Arm R5 clusters such as the absence of
> an ACP port, presence of an additional TI-specific Region Address
> Translater (RAT) module for translating 32-bit CPU addresses into
> larger system bus addresses etc.
>
> Add the DT node for the MCU domain R5F cluster/subsystem, the two
> R5 cores are added as child nodes to the main cluster/subsystem node.
> The cluster is configured to run in Split-mode by default, with the
> ATCMs enabled to allow the R5 cores to execute code from DDR with
> boot-strapping code from ATCM. The inter-processor communication
> between the main A72 cores and these processors is achieved through
> shared memory and Mailboxes.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/910c08be/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 17/26] env: ti: k3_rproc: Add common rproc environment variables
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (15 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 16/26] arm: dts: k3-am65-mcu: Add MCU domain R5F DT nodes Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 18/26] env: ti: j721e-evm: Add support to boot rprocs including R5Fs and DSPs Lokesh Vutla
` (8 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
Add a new file include/environment/ti/k3_rproc.h that defines
common environment variables useful for booting various remote
processors from U-Boot. This file is expected to be included in
the board config files with the EXTRA_ENV_RPROC_SETTINGS added
to CONFIG_EXTRA_ENV_SETTINGS and DEFAULT_RPROCS macro overwritten
to include the actual list of processors to be booted.
The 'boot_rprocs' variable just needs to be added to the board's
bootcmd to automatically boot the processors, and runtime control
can be achieved through the 'dorprocboot' variable.
The variables are currently defined to use MMC as the boot media,
and can be expanded in the future to include other boot media.
The immediate usage is intended for K3 J721E SoCs.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
include/environment/ti/k3_rproc.h | 52 +++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 include/environment/ti/k3_rproc.h
diff --git a/include/environment/ti/k3_rproc.h b/include/environment/ti/k3_rproc.h
new file mode 100644
index 0000000000..3418cb42be
--- /dev/null
+++ b/include/environment/ti/k3_rproc.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * rproc environment variable definitions for various TI K3 SoCs.
+ */
+
+#ifndef __TI_RPROC_H
+#define __TI_RPROC_H
+
+/*
+ * should contain a list of <rproc_id fw_name> tuplies,
+ * override in board config files with the actual list
+ */
+#define DEFAULT_RPROCS ""
+
+#ifdef CONFIG_CMD_REMOTEPROC
+#define EXTRA_ENV_RPROC_SETTINGS \
+ "dorprocboot=0\0" \
+ "boot_rprocs=" \
+ "if test ${dorprocboot} -eq 1 && test ${boot} = mmc; then "\
+ "rproc init;" \
+ "run boot_rprocs_mmc;" \
+ "fi;\0" \
+ "rproc_load_and_boot_one=" \
+ "if load mmc ${bootpart} $loadaddr ${rproc_fw}; then " \
+ "if rproc load ${rproc_id} ${loadaddr} ${filesize}; then "\
+ "rproc start ${rproc_id};" \
+ "fi;" \
+ "fi\0" \
+ "boot_rprocs_mmc=" \
+ "env set rproc_id;" \
+ "env set rproc_fw;" \
+ "for i in ${rproc_fw_binaries} ; do " \
+ "if test -z \"${rproc_id}\" ; then " \
+ "env set rproc_id $i;" \
+ "else " \
+ "env set rproc_fw $i;" \
+ "run rproc_load_and_boot_one;" \
+ "env set rproc_id;" \
+ "env set rproc_fw;" \
+ "fi;" \
+ "done\0" \
+ "rproc_fw_binaries=" \
+ DEFAULT_RPROCS \
+ "\0"
+#else
+#define EXTRA_ENV_RPROC_SETTINGS \
+ "boot_rprocs= \0"
+#endif /* CONFIG_CMD_REMOTEPROC */
+
+#endif /* __TI_RPROC_H */
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 17/26] env: ti: k3_rproc: Add common rproc environment variables
2019-09-04 10:31 ` [U-Boot] [PATCH v2 17/26] env: ti: k3_rproc: Add common rproc environment variables Lokesh Vutla
@ 2019-10-12 20:25 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:25 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:42PM +0530, Lokesh Vutla wrote:
> From: Suman Anna <s-anna@ti.com>
>
> Add a new file include/environment/ti/k3_rproc.h that defines
> common environment variables useful for booting various remote
> processors from U-Boot. This file is expected to be included in
> the board config files with the EXTRA_ENV_RPROC_SETTINGS added
> to CONFIG_EXTRA_ENV_SETTINGS and DEFAULT_RPROCS macro overwritten
> to include the actual list of processors to be booted.
>
> The 'boot_rprocs' variable just needs to be added to the board's
> bootcmd to automatically boot the processors, and runtime control
> can be achieved through the 'dorprocboot' variable.
>
> The variables are currently defined to use MMC as the boot media,
> and can be expanded in the future to include other boot media.
> The immediate usage is intended for K3 J721E SoCs.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/dc0b35e6/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 18/26] env: ti: j721e-evm: Add support to boot rprocs including R5Fs and DSPs
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (16 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 17/26] env: ti: k3_rproc: Add common rproc environment variables Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 19/26] env: ti: am65x_evm: Add env support to boot the MCU R5F rprocs Lokesh Vutla
` (7 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
Add support to boot some remoteprocs at U-boot prompt on the J721E EVM
boards by using the 'boot_rprocs' and other env variables defined in the
common environment file k3_rproc.h, and updating the 'DEFAULT_RPROCS'
macro.
The list of R5F cores to be started before loading and booting the Linux
kernel are as follows, and in this order:
Main R5FSS0 (Split) Core1 : 3 /lib/firmware/j7-main-r5f0_1-fw
Main R5FSS1 (LockStep) : 4 /lib/firmware/j7-main-r5f1_0-fw
The MCU R5FSS0 and Main R5FSS1 are currently in LockStep mode, so the
equivalent Core1 rprocs (rproc #1 and #5) are not included. The Main
R5FSS0 Core0 (rproc #2) is already started by R5 SPL, so is not included
in the list either.
The DSP cores are started in the following order before loading and
booting the Linux kernel:
C66_0: 6 /lib/firmware/j7-c66_0-fw
C66_1: 7 /lib/firmware/j7-c66_1-fw
C71_0: 8 /lib/firmware/j7-c71_0-fw
The order of the rprocs to boot can be changed at runtime if desired by
overwriting the 'rproc_fw_binaries' environment variable at U-boot prompt.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
include/configs/j721e_evm.h | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index 5fe77ef16d..dbe226b46d 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -12,6 +12,7 @@
#include <linux/sizes.h>
#include <config_distro_bootcmd.h>
#include <environment/ti/mmc.h>
+#include <environment/ti/k3_rproc.h>
#define CONFIG_ENV_SIZE (128 << 10)
@@ -87,11 +88,22 @@
"get_kern_mmc=load mmc ${bootpart} ${loadaddr} " \
"${bootdir}/${name_kern}\0"
+#ifdef DEFAULT_RPROCS
+#undef DEFAULT_RPROCS
+#endif
+#define DEFAULT_RPROCS "" \
+ "3 /lib/firmware/j7-main-r5f0_1-fw " \
+ "4 /lib/firmware/j7-main-r5f1_0-fw " \
+ "6 /lib/firmware/j7-c66_0-fw " \
+ "7 /lib/firmware/j7-c66_1-fw " \
+ "8 /lib/firmware/j7-c71_0-fw "
+
/* Incorporate settings into the U-Boot environment */
#define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_MMC_TI_ARGS \
EXTRA_ENV_J721E_BOARD_SETTINGS \
- EXTRA_ENV_J721E_BOARD_SETTINGS_MMC
+ EXTRA_ENV_J721E_BOARD_SETTINGS_MMC \
+ EXTRA_ENV_RPROC_SETTINGS
/* Now for the remaining common defines */
#include <configs/ti_armv7_common.h>
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 18/26] env: ti: j721e-evm: Add support to boot rprocs including R5Fs and DSPs
2019-09-04 10:31 ` [U-Boot] [PATCH v2 18/26] env: ti: j721e-evm: Add support to boot rprocs including R5Fs and DSPs Lokesh Vutla
@ 2019-10-12 20:25 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:25 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:43PM +0530, Lokesh Vutla wrote:
> From: Suman Anna <s-anna@ti.com>
>
> Add support to boot some remoteprocs at U-boot prompt on the J721E EVM
> boards by using the 'boot_rprocs' and other env variables defined in the
> common environment file k3_rproc.h, and updating the 'DEFAULT_RPROCS'
> macro.
>
> The list of R5F cores to be started before loading and booting the Linux
> kernel are as follows, and in this order:
> Main R5FSS0 (Split) Core1 : 3 /lib/firmware/j7-main-r5f0_1-fw
> Main R5FSS1 (LockStep) : 4 /lib/firmware/j7-main-r5f1_0-fw
>
> The MCU R5FSS0 and Main R5FSS1 are currently in LockStep mode, so the
> equivalent Core1 rprocs (rproc #1 and #5) are not included. The Main
> R5FSS0 Core0 (rproc #2) is already started by R5 SPL, so is not included
> in the list either.
>
> The DSP cores are started in the following order before loading and
> booting the Linux kernel:
> C66_0: 6 /lib/firmware/j7-c66_0-fw
> C66_1: 7 /lib/firmware/j7-c66_1-fw
> C71_0: 8 /lib/firmware/j7-c71_0-fw
>
> The order of the rprocs to boot can be changed at runtime if desired by
> overwriting the 'rproc_fw_binaries' environment variable at U-boot prompt.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/86642ed6/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 19/26] env: ti: am65x_evm: Add env support to boot the MCU R5F rprocs
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (17 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 18/26] env: ti: j721e-evm: Add support to boot rprocs including R5Fs and DSPs Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 20/26] configs: j721e_evm_a72: Enable R5F and DSP remoteproc driver Lokesh Vutla
` (6 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
Add support to boot the MCU domain R5F Core0 remoteproc at U-boot prompt
on the AM65x EVM boards by using the 'boot_rprocs' and other env variables
defined in the common environment file k3_rproc.h, and updating the
'DEFAULT_RPROCS' macro.
The default configuration is to use the MCU R5F in Split mode, so both
the R5F Core0 and Core1 are started before loading and booting the Linux
kernel using the following firmware:
MCU R5FSS0 Core0 (Split) : 0 /lib/firmware/am65x-mcu-r5f0_0-fw
MCU R5FSS0 Core1 (Split) : 1 /lib/firmware/am65x-mcu-r5f0_1-fw
The MCU R5FSS was initially running the R5 SPL in LockStep mode with ATCM
disabled, and is actually shutdown to enable it to be reconfigured and
booted by either A53 U-Boot or Linux kernel in remoteproc mode and using
ATCM.
The MCU R5FSS would need to be reconfigured for Lockstep mode through
DT if a fault-tolerant/safety application were to be run on the cluster
with the DEFAULT_RPROCS macro updated to remove the Core1 firmware.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
include/configs/am65x_evm.h | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 6072e4a48c..5c44b22ead 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -12,6 +12,7 @@
#include <linux/sizes.h>
#include <config_distro_bootcmd.h>
#include <environment/ti/mmc.h>
+#include <environment/ti/k3_rproc.h>
#define CONFIG_ENV_SIZE (128 << 10)
@@ -96,11 +97,19 @@
"${bootdir}/${name_kern}\0" \
"partitions=" PARTS_DEFAULT
+#ifdef DEFAULT_RPROCS
+#undef DEFAULT_RPROCS
+#endif
+#define DEFAULT_RPROCS "" \
+ "0 /lib/firmware/am65x-mcu-r5f0_0-fw " \
+ "1 /lib/firmware/am65x-mcu-r5f0_1-fw "
+
/* Incorporate settings into the U-Boot environment */
#define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_MMC_TI_ARGS \
EXTRA_ENV_AM65X_BOARD_SETTINGS \
- EXTRA_ENV_AM65X_BOARD_SETTINGS_MMC
+ EXTRA_ENV_AM65X_BOARD_SETTINGS_MMC \
+ EXTRA_ENV_RPROC_SETTINGS
/* MMC ENV related defines */
#ifdef CONFIG_ENV_IS_IN_MMC
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 19/26] env: ti: am65x_evm: Add env support to boot the MCU R5F rprocs
2019-09-04 10:31 ` [U-Boot] [PATCH v2 19/26] env: ti: am65x_evm: Add env support to boot the MCU R5F rprocs Lokesh Vutla
@ 2019-10-12 20:25 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:25 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:44PM +0530, Lokesh Vutla wrote:
> From: Suman Anna <s-anna@ti.com>
>
> Add support to boot the MCU domain R5F Core0 remoteproc at U-boot prompt
> on the AM65x EVM boards by using the 'boot_rprocs' and other env variables
> defined in the common environment file k3_rproc.h, and updating the
> 'DEFAULT_RPROCS' macro.
>
> The default configuration is to use the MCU R5F in Split mode, so both
> the R5F Core0 and Core1 are started before loading and booting the Linux
> kernel using the following firmware:
> MCU R5FSS0 Core0 (Split) : 0 /lib/firmware/am65x-mcu-r5f0_0-fw
> MCU R5FSS0 Core1 (Split) : 1 /lib/firmware/am65x-mcu-r5f0_1-fw
>
> The MCU R5FSS was initially running the R5 SPL in LockStep mode with ATCM
> disabled, and is actually shutdown to enable it to be reconfigured and
> booted by either A53 U-Boot or Linux kernel in remoteproc mode and using
> ATCM.
>
> The MCU R5FSS would need to be reconfigured for Lockstep mode through
> DT if a fault-tolerant/safety application were to be run on the cluster
> with the DEFAULT_RPROCS macro updated to remove the Core1 firmware.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/78750ce8/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 20/26] configs: j721e_evm_a72: Enable R5F and DSP remoteproc driver
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (18 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 19/26] env: ti: am65x_evm: Add env support to boot the MCU R5F rprocs Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 21/26] configs: j721e_evm_a72: Enhance bootcmd to start remoteprocs Lokesh Vutla
` (5 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
Enable R5F and DSP remoteproc drivers for j721e running on a72.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
configs/j721e_evm_a72_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 6e355f5247..6e0c3f05fb 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -34,6 +34,7 @@ CONFIG_SPL_YMODEM_SUPPORT=y
CONFIG_CMD_ASKENV=y
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
CONFIG_CMD_SF=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_TIME=y
@@ -72,6 +73,8 @@ CONFIG_SPL_PINCTRL=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_POWER_DOMAIN=y
CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_REMOTEPROC_TI_K3_DSP=y
+CONFIG_REMOTEPROC_TI_K3_R5F=y
CONFIG_DM_RESET=y
CONFIG_RESET_TI_SCI=y
CONFIG_DM_SERIAL=y
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 21/26] configs: j721e_evm_a72: Enhance bootcmd to start remoteprocs
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (19 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 20/26] configs: j721e_evm_a72: Enable R5F and DSP remoteproc driver Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:25 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 22/26] configs: am65x_evm_a53: Enable R5F remoteproc driver Lokesh Vutla
` (4 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
The A72 U-boot can support early booting of any of the R5F or C66x
or C71x remote processors from U-boot prompt to achieve various system
usecases before booting the Linux kernel. Update the default BOOTCOMMAND
to provide an automatic and easier way to start various remote processors
through added environment variables.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
configs/j721e_evm_a72_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 6e0c3f05fb..56df452fb6 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -17,7 +17,7 @@ CONFIG_SPL_SPI_SUPPORT=y
CONFIG_DISTRO_DEFAULTS=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_TEXT_BASE=0x80080000
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 22/26] configs: am65x_evm_a53: Enable R5F remoteproc driver
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (20 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 21/26] configs: j721e_evm_a72: Enhance bootcmd to start remoteprocs Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:26 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 23/26] configs: am65x_evm_a53: Enhance bootcmd to start remoteprocs Lokesh Vutla
` (3 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
Enable the R5F remoteproc driver for the AM65x GP EVM so that the
MCU domain R5F cores can be booted from A53 U-boot.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
configs/am65x_evm_a53_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 9d02dbc01a..d6a0d8583c 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_GPT=y
CONFIG_CMD_I2C=y
CONFIG_CMD_MMC=y
CONFIG_CMD_PCI=y
+CONFIG_CMD_REMOTEPROC=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_TIME=y
# CONFIG_ISO_PARTITION is not set
@@ -83,6 +84,7 @@ CONFIG_SPL_PINCTRL=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_POWER_DOMAIN=y
CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_REMOTEPROC_TI_K3_R5F=y
CONFIG_DM_RESET=y
CONFIG_RESET_TI_SCI=y
CONFIG_DM_SERIAL=y
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 23/26] configs: am65x_evm_a53: Enhance bootcmd to start remoteprocs
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (21 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 22/26] configs: am65x_evm_a53: Enable R5F remoteproc driver Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:26 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 24/26] armv8: K3: am65x: Update DDR address regions in MMU table Lokesh Vutla
` (2 subsequent siblings)
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
The A53 U-boot can support early booting of the MCU R5F remote processor(s)
from U-boot prompt to achieve various system usecases before booting the
Linux kernel. Update the default BOOTCOMMAND to provide an automatic and
easier way to start the MCU R5F cores through added environment variables.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
configs/am65x_evm_a53_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index d6a0d8583c..2d91d25b6a 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -16,7 +16,7 @@ CONFIG_DISTRO_DEFAULTS=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_TEXT_BASE=0x80080000
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 24/26] armv8: K3: am65x: Update DDR address regions in MMU table
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (22 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 23/26] configs: am65x_evm_a53: Enhance bootcmd to start remoteprocs Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:26 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 25/26] armv8: K3: j721e: Updated ddr " Lokesh Vutla
2019-09-04 10:31 ` [U-Boot] [PATCH v2 26/26] board: j721e: Add README Lokesh Vutla
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Suman Anna <s-anna@ti.com>
The A53 U-Boot code can load and boot the MCU domain R5F cores (either a
single core in LockStep mode or 2 cores in Split mode) to achieve various
early system functionalities. Change the memory attributes for the DDR
regions used by the remote processors so that the cores can see and
execute the proper code loaded by U-Boot.
These regions are currently limited to 0xa0000000 to 0xa2100000 as per
the DDR carveouts assigned for these R5F cores in the overall DDR memory
map.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/mach-k3/arm64-mmu.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 82778d2197..98c5a777e5 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -14,7 +14,7 @@
#ifdef CONFIG_SOC_K3_AM6
/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3)
+#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 5)
/* ToDo: Add 64bit IO */
struct mm_region am654_mem_map[NR_MMU_REGIONS] = {
@@ -28,7 +28,19 @@ struct mm_region am654_mem_map[NR_MMU_REGIONS] = {
}, {
.virt = 0x80000000UL,
.phys = 0x80000000UL,
- .size = 0x80000000UL,
+ .size = 0x20000000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0xa0000000UL,
+ .phys = 0xa0000000UL,
+ .size = 0x02100000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
+ PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0xa2100000UL,
+ .phys = 0xa2100000UL,
+ .size = 0x5df00000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 24/26] armv8: K3: am65x: Update DDR address regions in MMU table
2019-09-04 10:31 ` [U-Boot] [PATCH v2 24/26] armv8: K3: am65x: Update DDR address regions in MMU table Lokesh Vutla
@ 2019-10-12 20:26 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:26 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:49PM +0530, Lokesh Vutla wrote:
> From: Suman Anna <s-anna@ti.com>
>
> The A53 U-Boot code can load and boot the MCU domain R5F cores (either a
> single core in LockStep mode or 2 cores in Split mode) to achieve various
> early system functionalities. Change the memory attributes for the DDR
> regions used by the remote processors so that the cores can see and
> execute the proper code loaded by U-Boot.
>
> These regions are currently limited to 0xa0000000 to 0xa2100000 as per
> the DDR carveouts assigned for these R5F cores in the overall DDR memory
> map.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/72bddca7/attachment-0001.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 25/26] armv8: K3: j721e: Updated ddr address regions in MMU table
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (23 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 24/26] armv8: K3: am65x: Update DDR address regions in MMU table Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:26 ` Tom Rini
2019-09-04 10:31 ` [U-Boot] [PATCH v2 26/26] board: j721e: Add README Lokesh Vutla
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
From: Kedar Chitnis <kedarc@ti.com>
The A72 U-Boot code loads and boots a number of remote processors
including the C71x DSP, both the C66_0 and C66_1 DSPs, and the various
Main R5FSS Cores. In order to view the code loaded by the U-Boot by
remote cores, U-Boot should configure the memory region with right
memory attributes. Right now U-Boot carves out a memory region which
is not sufficient for all the images to be loaded. So, increase this
carve out region by 256MB.
Signed-off-by: Kedar Chitnis <kedarc@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/mach-k3/arm64-mmu.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 98c5a777e5..7f908eee80 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -80,13 +80,13 @@ struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
}, {
.virt = 0xa0000000UL,
.phys = 0xa0000000UL,
- .size = 0x0bc00000UL,
+ .size = 0x1bc00000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
PTE_BLOCK_NON_SHARE
}, {
- .virt = 0xabc00000UL,
- .phys = 0xabc00000UL,
- .size = 0x54400000UL,
+ .virt = 0xbbc00000UL,
+ .phys = 0xbbc00000UL,
+ .size = 0x44400000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [PATCH v2 25/26] armv8: K3: j721e: Updated ddr address regions in MMU table
2019-09-04 10:31 ` [U-Boot] [PATCH v2 25/26] armv8: K3: j721e: Updated ddr " Lokesh Vutla
@ 2019-10-12 20:26 ` Tom Rini
0 siblings, 0 replies; 57+ messages in thread
From: Tom Rini @ 2019-10-12 20:26 UTC (permalink / raw)
To: u-boot
On Wed, Sep 04, 2019 at 04:01:50PM +0530, Lokesh Vutla wrote:
> From: Kedar Chitnis <kedarc@ti.com>
>
> The A72 U-Boot code loads and boots a number of remote processors
> including the C71x DSP, both the C66_0 and C66_1 DSPs, and the various
> Main R5FSS Cores. In order to view the code loaded by the U-Boot by
> remote cores, U-Boot should configure the memory region with right
> memory attributes. Right now U-Boot carves out a memory region which
> is not sufficient for all the images to be loaded. So, increase this
> carve out region by 256MB.
>
> Signed-off-by: Kedar Chitnis <kedarc@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191012/b8874664/attachment.sig>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [PATCH v2 26/26] board: j721e: Add README
2019-09-04 10:31 [U-Boot] [PATCH v2 00/26] remoteproc: Add support for R5F and DSP processors Lokesh Vutla
` (24 preceding siblings ...)
2019-09-04 10:31 ` [U-Boot] [PATCH v2 25/26] armv8: K3: j721e: Updated ddr " Lokesh Vutla
@ 2019-09-04 10:31 ` Lokesh Vutla
2019-10-12 20:26 ` Tom Rini
25 siblings, 1 reply; 57+ messages in thread
From: Lokesh Vutla @ 2019-09-04 10:31 UTC (permalink / raw)
To: u-boot
Add README file explaining the build and boot procedure for J721E evm.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
board/ti/j721e/README | 227 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 227 insertions(+)
create mode 100644 board/ti/j721e/README
diff --git a/board/ti/j721e/README b/board/ti/j721e/README
new file mode 100644
index 0000000000..5be7d099db
--- /dev/null
+++ b/board/ti/j721e/README
@@ -0,0 +1,227 @@
+Introduction:
+-------------
+The J721e family of SoCs are part of K3 Multicore SoC architecture platform
+targeting automotive applications. They are designed as a low power, high
+performance and highly integrated device architecture, adding significant
+enhancement on processing power, graphics capability, video and imaging
+processing, virtualization and coherent memory support.
+
+The device is partitioned into three functional domains, each containing
+specific processing cores and peripherals:
+1. Wake-up (WKUP) domain:
+ - Device Management and Security Controller (DMSC)
+2. Microcontroller (MCU) domain:
+ - Dual Core ARM Cortex-R5F processor
+3. MAIN domain:
+ - Dual core 64-bit ARM Cortex-A72
+ - 2 x Dual cortex ARM Cortex-R5 subsystem
+ - 2 x C66x Digital signal processor sub system
+ - C71x Digital signal processor sub-system with MMA.
+
+More info can be found in TRM: http://www.ti.com/lit/pdf/spruil1
+
+Boot Flow:
+----------
+Boot flow is similar to that of AM65x SoC and extending it with remoteproc
+support. Below is the pictorial representation of boot flow:
+
++------------------------------------------------------------------------+-----------------------+
+| DMSC | MCU R5 | A72 | MAIN R5/C66x/C7x |
++------------------------------------------------------------------------+-----------------------+
+| +--------+ | | | |
+| | Reset | | | | |
+| +--------+ | | | |
+| : | | | |
+| +--------+ | +-----------+ | | |
+| | *ROM* |----------|-->| Reset rls | | | |
+| +--------+ | +-----------+ | | |
+| | | | : | | |
+| | ROM | | : | | |
+| |services| | : | | |
+| | | | +-------------+ | | |
+| | | | | *R5 ROM* | | | |
+| | | | +-------------+ | | |
+| | |<---------|---|Load and auth| | | |
+| | | | | tiboot3.bin | | | |
+| | | | +-------------+ | | |
+| | | | : | | |
+| | | | : | | |
+| | | | : | | |
+| | | | +-------------+ | | |
+| | | | | *R5 SPL* | | | |
+| | | | +-------------+ | | |
+| | | | | Load | | | |
+| | | | | sysfw.itb | | | |
+| | Start | | +-------------+ | | |
+| | System |<---------|---| Start | | | |
+| |Firmware| | | SYSFW | | | |
+| +--------+ | +-------------+ | | |
+| : | | | | | |
+| +---------+ | | Load | | | |
+| | *SYSFW* | | | system | | | |
+| +---------+ | | Config data | | | |
+| | |<--------|---| | | | |
+| | | | +-------------+ | | |
+| | | | | DDR | | | |
+| | | | | config | | | |
+| | | | +-------------+ | | |
+| | | | | Load | | | |
+| | | | | tispl.bin | | | |
+| | | | +-------------+ | | |
+| | | | | Load R5 | | | |
+| | | | | firmware | | | |
+| | | | +-------------+ | | |
+| | |<--------|---| Start A72 | | | |
+| | | | | and jump to | | | |
+| | | | | next image | | | |
+| | | | +-------------+ | | |
+| | | | | +-----------+ | |
+| | |---------|-----------------------|---->| Reset rls | | |
+| | | | | +-----------+ | |
+| | DMSC | | | : | |
+| |Services | | | +-----------+ | |
+| | |<--------|-----------------------|---->|*ATF/OPTEE*| | |
+| | | | | +-----------+ | |
+| | | | | : | |
+| | | | | +-----------+ | |
+| | |<--------|-----------------------|---->| *A72 SPL* | | |
+| | | | | +-----------+ | |
+| | | | | | Load | | |
+| | | | | | u-boot.img| | |
+| | | | | +-----------+ | |
+| | | | | : | |
+| | | | | +-----------+ | |
+| | |<--------|-----------------------|---->| *U-Boot* | | |
+| | | | | +-----------+ | |
+| | | | | | prompt | | |
+| | | | | +-----------+ | |
+| | | | | | Load R5 | | |
+| | | | | | Firmware | | |
+| | | | | +-----------+ | |
+| | |<--------|-----------------------|-----| Start R5 | | +-----------+ |
+| | |---------|-----------------------|-----+-----------+-----|----->| R5 starts | |
+| | | | | | Load C6 | | +-----------+ |
+| | | | | | Firmware | | |
+| | | | | +-----------+ | |
+| | |<--------|-----------------------|-----| Start C6 | | +-----------+ |
+| | |---------|-----------------------|-----+-----------+-----|----->| C6 starts | |
+| | | | | | Load C7 | | +-----------+ |
+| | | | | | Firmware | | |
+| | | | | +-----------+ | |
+| | |<--------|-----------------------|-----| Start C7 | | +-----------+ |
+| | |---------|-----------------------|-----+-----------+-----|----->| C7 starts | |
+| +---------+ | | | +-----------+ |
+| | | | |
++------------------------------------------------------------------------+-----------------------+
+
+- Here DMSC acts as master and provides all the critical services. R5/A72
+requests DMSC to get these services done as shown in the above diagram.
+
+Sources:
+--------
+1. SYSFW:
+ Tree: git://git.ti.com/processor-firmware/system-firmware-image-gen.git
+ Branch: master
+
+2. ATF:
+ Tree: https://github.com/ARM-software/arm-trusted-firmware.git
+ Branch: master
+
+3. OPTEE:
+ Tree: https://github.com/OP-TEE/optee_os.git
+ Branch: master
+
+4. U-Boot:
+ Tree: https://gitlab.denx.de/u-boot/u-boot
+ Branch: master
+
+Build procedure:
+----------------
+1. SYSFW:
+$ make CROSS_COMPILE=arm-linux-gnueabihf-
+
+2. ATF:
+$ make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic SPD=opteed
+
+3. OPTEE:
+$ make PLATFORM=k3-j721e CFG_ARM64_core=y
+
+4. U-Boot:
+
+4.1. R5:
+$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- j721e_evm_r5_defconfig O=/tmp/r5
+$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=/tmp/r5
+
+4.2. A72:
+$ make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- j721e_evm_a72_defconfig O=/tmp/a72
+$ make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- ATF=<path to ATF dir>/build/k3/generic/release/bl31.bin TEE=<path to OPTEE OS dir>/out/arm-plat-k3/core/tee-pager.bin O=/tmp/a72
+
+Target Images
+--------------
+Copy the below images to an SD card and boot:
+- sysfw.itb from step 1
+- tiboot3.bin from step 4.1
+- tispl.bin, u-boot.img from 4.2
+
+Image formats:
+--------------
+
+- tiboot3.bin:
+ +-----------------------+
+ | X.509 |
+ | Certificate |
+ | +-------------------+ |
+ | | | |
+ | | R5 | |
+ | | u-boot-spl.bin | |
+ | | | |
+ | +-------------------+ |
+ | | | |
+ | | FIT header | |
+ | | +---------------+ | |
+ | | | | | |
+ | | | DTB 1...N | | |
+ | | +---------------+ | |
+ | +-------------------+ |
+ +-----------------------+
+
+- tispl.bin
+ +-----------------------+
+ | |
+ | FIT HEADER |
+ | +-------------------+ |
+ | | | |
+ | | A72 ATF | |
+ | +-------------------+ |
+ | | | |
+ | | A72 OPTEE | |
+ | +-------------------+ |
+ | | | |
+ | | A72 SPL | |
+ | +-------------------+ |
+ | | | |
+ | | SPL DTB 1...N | |
+ | +-------------------+ |
+ +-----------------------+
+
+- sysfw.itb
+ +-----------------------+
+ | |
+ | FIT HEADER |
+ | +-------------------+ |
+ | | | |
+ | | sysfw.bin | |
+ | +-------------------+ |
+ | | | |
+ | | board config | |
+ | +-------------------+ |
+ | | | |
+ | | PM config | |
+ | +-------------------+ |
+ | | | |
+ | | RM config | |
+ | +-------------------+ |
+ | | | |
+ | | Secure config | |
+ | +-------------------+ |
+ +-----------------------+
--
2.22.0
^ permalink raw reply related [flat|nested] 57+ messages in thread