[PATCH v2 0/6] remoteproc: k3-r5: Build fixes and security improvements

[PATCH v2 0/6] remoteproc: k3-r5: Build fixes and security improvements

[Philippe Schenker]

From: Philippe Schenker <philippe.schenker@impulsing.ch>


This series fixes compilation errors when building for R5 cores and
addresses a security issue where authenticated images were not being
used correctly.

Patch 1: Cosmetic removal of duplicate code

Patches 2-3: Fix build errors caused by type mismatches between
function signatures and the types used in R5 builds.

Patches 4-5: fix a bug where ti_secure_image_post_process() relocates
images during authentication, but callers were still using the original
unverified addresses.

Patch 6: Implements is_running operation to allow querying R5F core status.


Changes in v2:
- Made sure there are no build-warnings caused by this series.

Philippe Schenker (6):
  arm: dts: k3-am642-evm: Remove duplicate node
  remoteproc: k3-r5: cast size to size_t
  soc: ti: pruss: Fix size ptr type in probe
  mach-k3: security: Propagate verified image addr
  remoteproc: k3-r5: Use verified image address
  remoteproc: k3-r5: Implement is_running operation

 arch/arm/dts/k3-am642-evm-u-boot.dtsi |  4 ----
 arch/arm/mach-k3/security.c           |  2 ++
 drivers/remoteproc/ti_k3_r5f_rproc.c  | 23 ++++++++++++++++++++---
 drivers/soc/ti/pruss.c                |  2 +-
 4 files changed, 23 insertions(+), 8 deletions(-)

-- 
2.51.2

base-commit: ddc916334a7a7e180b532dbb2cf1b778466d2b9b
branch: am64x-various-fixes__master

[PATCH v2 1/6] arm: dts: k3-am642-evm: Remove duplicate node

[Philippe Schenker]

From: Philippe Schenker <philippe.schenker@impulsing.ch>

The device tree contained a duplicate DT node 'main_mmc1_pins_default',
which was already defined a few lines below. This patch removes the
redundant entry.

Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
---

(no changes since v1)

 arch/arm/dts/k3-am642-evm-u-boot.dtsi | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 705b3baa81cf..6469f43fca81 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -19,10 +19,6 @@
 	dr_mode="peripheral";
 };
 
-&main_mmc1_pins_default {
-	bootph-all;
-};
-
 &sdhci0 {
 	bootph-all;
 };
-- 
2.51.2

Re: [PATCH v2 1/6] arm: dts: k3-am642-evm: Remove duplicate node

[Anshul Dalal]

On Fri Nov 7, 2025 at 6:31 PM IST, Philippe Schenker wrote:
> From: Philippe Schenker <philippe.schenker@impulsing.ch>
>
> The device tree contained a duplicate DT node 'main_mmc1_pins_default',
> which was already defined a few lines below. This patch removes the
> redundant entry.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>

Reviewed-by: Anshul Dalal <anshuld@ti.com>

> ---
>
> (no changes since v1)
>
>  arch/arm/dts/k3-am642-evm-u-boot.dtsi | 4 ----
>  1 file changed, 4 deletions(-)
>
> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> index 705b3baa81cf..6469f43fca81 100644
> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> @@ -19,10 +19,6 @@
>  	dr_mode="peripheral";
>  };
>  
> -&main_mmc1_pins_default {
> -	bootph-all;
> -};
> -
>  &sdhci0 {
>  	bootph-all;
>  };

[PATCH v2 2/6] remoteproc: k3-r5: cast size to size_t

[Philippe Schenker]

From: Philippe Schenker <philippe.schenker@impulsing.ch>

When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
passing 'size' (ulong) to ti_secure_image_post_process() caused
a type mismatch compiler error.

Cast 'size' to (size_t *) to fix it.

Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
Acked-by: Andrew Davis <afd@ti.com>

---

Changes in v2:
- Added Andrew's Acked-by

 drivers/remoteproc/ti_k3_r5f_rproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c b/drivers/remoteproc/ti_k3_r5f_rproc.c
index c738607c1092..e7bd97a9088b 100644
--- a/drivers/remoteproc/ti_k3_r5f_rproc.c
+++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
@@ -341,7 +341,7 @@ static int k3_r5f_load(struct udevice *dev, ulong addr, ulong size)
 
 	k3_r5f_init_tcm_memories(core, mem_auto_init);
 
-	ti_secure_image_post_process(&image_addr, &size);
+	ti_secure_image_post_process(&image_addr, (size_t *)&size);
 
 	ret = rproc_elf_load_image(dev, addr, size);
 	if (ret < 0) {
-- 
2.51.2

Re: [PATCH v2 2/6] remoteproc: k3-r5: cast size to size_t

[Andrew Davis]

On 11/7/25 7:01 AM, Philippe Schenker wrote:
> From: Philippe Schenker <philippe.schenker@impulsing.ch>
> 
> When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
> passing 'size' (ulong) to ti_secure_image_post_process() caused
> a type mismatch compiler error.
> 
> Cast 'size' to (size_t *) to fix it.

If the size of `size_t` and `ulong` are not the same this doesn't
really fix the issue, just silence the compiler warning. If ulong
is smaller than size_t on some platform we will read data outside
the variable address when de-referencing.

Might be more correct to assign size to a variable of the correct
size first, then pass a pointer to that.

Andrew

> 
> Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
> Acked-by: Andrew Davis <afd@ti.com>
> 
> ---
> 
> Changes in v2:
> - Added Andrew's Acked-by
> 
>   drivers/remoteproc/ti_k3_r5f_rproc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c b/drivers/remoteproc/ti_k3_r5f_rproc.c
> index c738607c1092..e7bd97a9088b 100644
> --- a/drivers/remoteproc/ti_k3_r5f_rproc.c
> +++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
> @@ -341,7 +341,7 @@ static int k3_r5f_load(struct udevice *dev, ulong addr, ulong size)
>   
>   	k3_r5f_init_tcm_memories(core, mem_auto_init);
>   
> -	ti_secure_image_post_process(&image_addr, &size);
> +	ti_secure_image_post_process(&image_addr, (size_t *)&size);
>   
>   	ret = rproc_elf_load_image(dev, addr, size);
>   	if (ret < 0) {

Re: [PATCH v2 2/6] remoteproc: k3-r5: cast size to size_t

[Philippe Schenker]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]



On Fri, 2025-11-07 at 09:24 -0600, Andrew Davis wrote:
> On 11/7/25 7:01 AM, Philippe Schenker wrote:
> > From: Philippe Schenker <philippe.schenker@impulsing.ch>
> > 
> > When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
> > passing 'size' (ulong) to ti_secure_image_post_process() caused
> > a type mismatch compiler error.
> > 
> > Cast 'size' to (size_t *) to fix it.
> 
> If the size of `size_t` and `ulong` are not the same this doesn't
> really fix the issue, just silence the compiler warning. If ulong
> is smaller than size_t on some platform we will read data outside
> the variable address when de-referencing.
> 
> Might be more correct to assign size to a variable of the correct
> size first, then pass a pointer to that.
> 
> Andrew

Hi Andrew, Thanks for your comment. If I understand it correctly and
explained in different words: If size_t is larger than ulong unknown
memory could be accessed. Isn't it very unlikely that this ever
happens?

At least I did interpret your first comment that way.

Anyway I will send a v3 to really catch all cases.

> 
> > 
> > Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
> > Acked-by: Andrew Davis <afd@ti.com>
> > 
> > ---
> > 
> > Changes in v2:
> > - Added Andrew's Acked-by
> > 
> >   drivers/remoteproc/ti_k3_r5f_rproc.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c
> > b/drivers/remoteproc/ti_k3_r5f_rproc.c
> > index c738607c1092..e7bd97a9088b 100644
> > --- a/drivers/remoteproc/ti_k3_r5f_rproc.c
> > +++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
> > @@ -341,7 +341,7 @@ static int k3_r5f_load(struct udevice *dev,
> > ulong addr, ulong size)
> >   
> >    k3_r5f_init_tcm_memories(core, mem_auto_init);
> >   
> > - ti_secure_image_post_process(&image_addr, &size);
> > + ti_secure_image_post_process(&image_addr, (size_t *)&size);
> >   
> >    ret = rproc_elf_load_image(dev, addr, size);
> >    if (ret < 0) {

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v2 2/6] remoteproc: k3-r5: cast size to size_t

[Andrew Davis]

On 11/7/25 10:00 AM, Philippe Schenker wrote:
> 
> 
> On Fri, 2025-11-07 at 09:24 -0600, Andrew Davis wrote:
>> On 11/7/25 7:01 AM, Philippe Schenker wrote:
>>> From: Philippe Schenker <philippe.schenker@impulsing.ch>
>>>
>>> When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
>>> passing 'size' (ulong) to ti_secure_image_post_process() caused
>>> a type mismatch compiler error.
>>>
>>> Cast 'size' to (size_t *) to fix it.
>>
>> If the size of `size_t` and `ulong` are not the same this doesn't
>> really fix the issue, just silence the compiler warning. If ulong
>> is smaller than size_t on some platform we will read data outside
>> the variable address when de-referencing.
>>
>> Might be more correct to assign size to a variable of the correct
>> size first, then pass a pointer to that.
>>
>> Andrew
> 
> Hi Andrew, Thanks for your comment. If I understand it correctly and
> explained in different words: If size_t is larger than ulong unknown
> memory could be accessed.

Correct. And if size_t is smaller then on big-endian systems you
will read the wrong data.

> Isn't it very unlikely that this ever
> happens?
> 

Also correct, I don't think either scenario is likely, it is
just about formal correctness. And I also didn't think any system
would have ulong and size_t be different sizes, but guess you
found a case (not sure why on R5 they are both not 32bits but
if the compiler is complaining then I guess they aren't).

> At least I did interpret your first comment that way.
> 
> Anyway I will send a v3 to really catch all cases.
> 

Thanks :)

Andrew

>>
>>>
>>> Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
>>> Acked-by: Andrew Davis <afd@ti.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Added Andrew's Acked-by
>>>
>>>    drivers/remoteproc/ti_k3_r5f_rproc.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c
>>> b/drivers/remoteproc/ti_k3_r5f_rproc.c
>>> index c738607c1092..e7bd97a9088b 100644
>>> --- a/drivers/remoteproc/ti_k3_r5f_rproc.c
>>> +++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
>>> @@ -341,7 +341,7 @@ static int k3_r5f_load(struct udevice *dev,
>>> ulong addr, ulong size)
>>>    
>>>     k3_r5f_init_tcm_memories(core, mem_auto_init);
>>>    
>>> - ti_secure_image_post_process(&image_addr, &size);
>>> + ti_secure_image_post_process(&image_addr, (size_t *)&size);
>>>    
>>>     ret = rproc_elf_load_image(dev, addr, size);
>>>     if (ret < 0) {

[PATCH v2 3/6] soc: ti: pruss: Fix size ptr type in probe

[Philippe Schenker]

From: Philippe Schenker <philippe.schenker@impulsing.ch>

When compiling for R5 with CONFIG_TI_PRUSS enabled, the
pruss_probe() function passed a u64* to ofnode_get_addr_size_index(),
which expects an fdt_size_t*. This caused a compiler error
about incompatible pointer types.

Cast the size pointer to fdt_size_t* to match the function
signature.

Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
---

(no changes since v1)

 drivers/soc/ti/pruss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
index e3bb2ede554a..4bc0ff8c2c17 100644
--- a/drivers/soc/ti/pruss.c
+++ b/drivers/soc/ti/pruss.c
@@ -163,7 +163,7 @@ static int pruss_probe(struct udevice *dev)
 	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
 		idx = ofnode_stringlist_search(memories, "reg-names", mem_names[i]);
 		priv->mem_regions[i].pa = ofnode_get_addr_size_index(memories, idx,
-						       (u64 *)&priv->mem_regions[i].size);
+						       (fdt_size_t *)&priv->mem_regions[i].size);
 	}
 
 	sub_node = ofnode_find_subnode(node, "cfg");
-- 
2.51.2

[PATCH v2 4/6] mach-k3: security: Propagate verified image addr

[Philippe Schenker]

From: Philippe Schenker <philippe.schenker@impulsing.ch>

The ti_secure_image_check() function may relocate the image during
authentication, updating image_addr to point to the verified location.
The caller was not updated with this new address, causing it to
reference the original unverified location.

Update p_image with the verified image address after authentication
to ensure subsequent operations use the correct location.

Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>

---

Changes in v2:
- Fixed pointer cast warning by using uintptr_t intermediate cast. The
  direct cast from u64 to pointer caused a -Wint-to-pointer-cast warning
  on 32-bit ARM R5 targets. Using (uintptr_t) as intermediate cast is
  safer and architecture-aware, ensuring proper handling on both 32-bit
  and 64-bit targets.

 arch/arm/mach-k3/security.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-k3/security.c b/arch/arm/mach-k3/security.c
index 3468a370a455..c7017bba99ab 100644
--- a/arch/arm/mach-k3/security.c
+++ b/arch/arm/mach-k3/security.c
@@ -119,6 +119,8 @@ void ti_secure_image_post_process(void **p_image, size_t *p_size)
 	 */
 	*p_size = image_size;
 
+	*p_image = (void *)(uintptr_t)image_addr;
+
 	/*
 	 * Output notification of successful authentication to re-assure the
 	 * user that the secure code is being processed as expected. However
-- 
2.51.2

[PATCH v2 5/6] remoteproc: k3-r5: Use verified image address

[Philippe Schenker]

From: Philippe Schenker <philippe.schenker@impulsing.ch>

After ti_secure_image_post_process() authenticates the image, it may
relocate it to a different memory location and update image_addr to
point to the verified image.

However, rproc_elf_load_image() and rproc_elf_get_boot_addr() were
still using the original "addr" parameter, potentially operating on
the unverified or stale image location instead of the authenticated
image.

Use image_addr (cast to ulong to match function signatures) after
authentication to ensure all operations work with the verified image.

Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
---

(no changes since v1)

 drivers/remoteproc/ti_k3_r5f_rproc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c b/drivers/remoteproc/ti_k3_r5f_rproc.c
index e7bd97a9088b..36ea449f5121 100644
--- a/drivers/remoteproc/ti_k3_r5f_rproc.c
+++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
@@ -343,13 +343,13 @@ static int k3_r5f_load(struct udevice *dev, ulong addr, ulong size)
 
 	ti_secure_image_post_process(&image_addr, (size_t *)&size);
 
-	ret = rproc_elf_load_image(dev, addr, size);
+	ret = rproc_elf_load_image(dev, (ulong)image_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);
+	boot_vector = rproc_elf_get_boot_addr(dev, (ulong)image_addr);
 
 	dev_dbg(dev, "%s: Boot vector = 0x%llx\n", __func__, boot_vector);
 
-- 
2.51.2

[PATCH v2 6/6] remoteproc: k3-r5: Implement is_running operation

[Philippe Schenker]

From: Philippe Schenker <philippe.schenker@impulsing.ch>

Add is_running callback to query the R5F core halt status via the
TI-SCI processor control API. This allows the remoteproc framework
to determine whether the R5F core is currently runnin.

The core is considered running when the PROC_BOOT_CTRL_FLAG_R5_CORE_HALT
bit is not set in the control flags.

Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>

---

Changes in v2:
- Made sure there are no build-warnings caused by this series.

 drivers/remoteproc/ti_k3_r5f_rproc.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c b/drivers/remoteproc/ti_k3_r5f_rproc.c
index 36ea449f5121..78739ca55942 100644
--- a/drivers/remoteproc/ti_k3_r5f_rproc.c
+++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
@@ -570,6 +570,22 @@ static void *k3_r5f_da_to_va(struct udevice *dev, ulong da, ulong size, bool *is
 	return map_physmem(da, size, MAP_NOCACHE);
 }
 
+static int k3_r5f_is_running(struct udevice *dev)
+{
+	struct k3_r5f_core *core = dev_get_priv(dev);
+	u32 cfg, ctrl, sts;
+	u64 boot_vec;
+	int ret;
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	ret = ti_sci_proc_get_status(&core->tsp, &boot_vec, &cfg, &ctrl, &sts);
+	if (ret)
+		return -1;
+
+	return !!(ctrl & PROC_BOOT_CTRL_FLAG_R5_CORE_HALT);
+}
+
 static int k3_r5f_init(struct udevice *dev)
 {
 	return 0;
@@ -587,6 +603,7 @@ static const struct dm_rproc_ops k3_r5f_rproc_ops = {
 	.stop = k3_r5f_stop,
 	.load = k3_r5f_load,
 	.device_to_virt = k3_r5f_da_to_va,
+	.is_running = k3_r5f_is_running,
 };
 
 static int k3_r5f_rproc_configure(struct k3_r5f_core *core)
-- 
2.51.2