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

[PATCH v1 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.

Note: If preferred, I can split 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.1

base-commit: 813a0df27a8af587bd25a6a4719f68066b370091
branch: am64x-various-fixes__master

[PATCH v1 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>
---

 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.1

[PATCH v1 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>
---

 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 48401bc6eb67..9d591aada276 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.1

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

[Andrew Davis]

On 10/23/25 4:46 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.
> 

size_t and ulong should both be 32bit on any reasonable 32bit machine,
odd the compiler would complain here.

Casting pointers always worries me anyway, if the var being cast is
smaller then you will read out of bounds, if the var is larger than
what it is cast to then you run into endianness issues. Always safer
to dereference into a temp variable of the correct type and pass a
pointer to that.

For this, probably fine either way,

Acked-by: Andrew Davis <afd@ti.com>

> Cast 'size' to (size_t *) to fix it.
> 
> Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
> ---
> 
>   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 48401bc6eb67..9d591aada276 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 v1 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>
---

 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.1

[PATCH v1 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>
---

 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..9255505a7944 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 *)image_addr;
+
 	/*
 	 * Output notification of successful authentication to re-assure the
 	 * user that the secure code is being processed as expected. However
-- 
2.51.1

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

[Andrew Davis]

On 10/23/25 4:46 AM, Philippe Schenker wrote:
> 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>
> ---

Seems reasonable,

Acked-by: Andrew Davis <afd@ti.com>

BTW, did you actually run into an issue with having a binary moved
by the authentication, or was this found some other way? Normally
binaries don't move (but they can, so this is still valid).

> 
>   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..9255505a7944 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 *)image_addr;
> +
>   	/*
>   	 * Output notification of successful authentication to re-assure the
>   	 * user that the secure code is being processed as expected. However

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

[Philippe Schenker]

On Thu, 2025-10-23 at 09:24 -0500, Andrew Davis wrote:
> On 10/23/25 4:46 AM, Philippe Schenker wrote:
> > 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>
> > ---
> 
> Seems reasonable,
> 
> Acked-by: Andrew Davis <afd@ti.com>
> 
> BTW, did you actually run into an issue with having a binary moved
> by the authentication, or was this found some other way? Normally
> binaries don't move (but they can, so this is still valid).

Thanks for your acked-by's! Sorry forgot to answer and just now saw it
again. Yes I ran into an issue where I have a signed elf file. The step
of loading the elf file was failing because the pointer still pointing
to the signature.

Philippe

> 
> > 
> >   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..9255505a7944 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 *)image_addr;
> > +
> >    /*
> >    * Output notification of successful authentication to re-assure
> > the
> >    * user that the secure code is being processed as expected.
> > However

[PATCH v1 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>
---

 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 9d591aada276..40163e992da8 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.1

[PATCH v1 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>

---

 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 40163e992da8..a2d3b817e406 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)
 	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.1

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

[Tom Rini]

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

On Thu, Oct 23, 2025 at 11:46:18AM +0200, Philippe Schenker wrote:

> 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.
> 
> Note: If preferred, I can split this series.

With the series applied, I see warnings now on:
j721e_beagleboneai64_r5 am62x_beagleplay_r5 am67a_beagley_ai_r5
phycore_am62ax_r5 phycore_am62ax_r5_ethboot phycore_am62ax_r5_usbdfu
phycore_am62x_r5 phycore_am62x_r5_ethboot phycore_am62x_r5_usbdfu
phycore_am64x_r5 am62ax_evm_r5 am62dx_evm_r5 am62px_evm_r5
am62px_evm_r5_ethboot am62x_evm_r5 am62x_evm_r5_ethboot am62x_lpsk_r5
am64x_evm_r5 am65x_evm_r5 am65x_evm_r5_usbdfu am65x_evm_r5_usbmsc
j7200_evm_r5 j721e_evm_r5 j721e_sk_r5 am68_sk_r5 am68_sk_r5_ethboot
j721s2_evm_r5 j722s_evm_r5 j722s_evm_r5_ethboot am69_sk_r5
am69_sk_r5_ethboot j742s2_evm_r5 j784s4_evm_r5 verdin-am62_r5
verdin-am62p_r5
like:
arch/arm/mach-k3/security.c:122:20: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   122 |         *p_image = (void *)image_addr;

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Philippe Schenker]

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

Hi Tom, 

Sorry for not spotting this. I will improve the patchset and send a v2.

On Thu, 2025-11-06 at 13:35 -0600, Tom Rini wrote:
> On Thu, Oct 23, 2025 at 11:46:18AM +0200, Philippe Schenker wrote:
> 
> > 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.
> > 
> > Note: If preferred, I can split this series.
> 
> With the series applied, I see warnings now on:
> j721e_beagleboneai64_r5 am62x_beagleplay_r5 am67a_beagley_ai_r5
> phycore_am62ax_r5 phycore_am62ax_r5_ethboot phycore_am62ax_r5_usbdfu
> phycore_am62x_r5 phycore_am62x_r5_ethboot phycore_am62x_r5_usbdfu
> phycore_am64x_r5 am62ax_evm_r5 am62dx_evm_r5 am62px_evm_r5
> am62px_evm_r5_ethboot am62x_evm_r5 am62x_evm_r5_ethboot am62x_lpsk_r5
> am64x_evm_r5 am65x_evm_r5 am65x_evm_r5_usbdfu am65x_evm_r5_usbmsc
> j7200_evm_r5 j721e_evm_r5 j721e_sk_r5 am68_sk_r5 am68_sk_r5_ethboot
> j721s2_evm_r5 j722s_evm_r5 j722s_evm_r5_ethboot am69_sk_r5
> am69_sk_r5_ethboot j742s2_evm_r5 j784s4_evm_r5 verdin-am62_r5
> verdin-am62p_r5
> like:
> arch/arm/mach-k3/security.c:122:20: error: cast to pointer from
> integer of different size [-Werror=int-to-pointer-cast]
>    122 |         *p_image = (void *)image_addr;

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