[PATCHv3] remoteproc: imx_rproc: add missing DRAM ranges for i.MX93

[PATCHv3] remoteproc: imx_rproc: add missing DRAM ranges for i.MX93

[Zhiqiang Hou]

From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>

The M33 DRAM address ranges 0xA0000000-0xAFFFFFFF(None Secure)
and 0xB0000000-0xBFFFFFFF(Secure) are both mapped to
0xA0000000-0xAFFFFFFF in the A55 address space.

These ranges are currently missing from the i.MX93 remoteproc
address translation table, which may lead to invalid address
translation for firmware accessing these regions.

Add the missing mappings to complete the DRAM coverage.

Fixes: 9222fabf0e39d ("remoteproc: imx_rproc: Support i.MX93")
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
V3:
 - Added more info in the changelog.

 drivers/remoteproc/imx_rproc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7f54322244aca..175c2d3099794 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -198,6 +198,9 @@ static const struct imx_rproc_att imx_rproc_att_imx93[] = {
 	{ 0x80000000, 0x80000000, 0x10000000, 0 },
 	{ 0x90000000, 0x80000000, 0x10000000, 0 },
 
+	{ 0xA0000000, 0xA0000000, 0x10000000, 0 },
+	{ 0xB0000000, 0xA0000000, 0x10000000, 0 },
+
 	{ 0xC0000000, 0xC0000000, 0x10000000, 0 },
 	{ 0xD0000000, 0xC0000000, 0x10000000, 0 },
 };
-- 
2.43.0

Re: [PATCHv3] remoteproc: imx_rproc: add missing DRAM ranges for i.MX93

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Address translation fails for requests matching exactly the end boundary of a memory region due to a strict inequality check.
--

commit 32acb41558a7e1f55f57c27cddcfe528e4522a38
Author: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>

remoteproc: imx_rproc: add missing DRAM ranges for i.MX93

This commit adds missing M33 DRAM address mappings (secure and non-secure
ranges) to the i.MX93 remoteproc address translation table. These additions
complete the DRAM coverage and prevent invalid address translations for
firmware accessing these regions.

> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 7f54322244aca..175c2d3099794 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -198,6 +198,9 @@ static const struct imx_rproc_att imx_rproc_att_imx93[] = {
>  	{ 0x80000000, 0x80000000, 0x10000000, 0 },
>  	{ 0x90000000, 0x80000000, 0x10000000, 0 },
>  
> +	{ 0xA0000000, 0xA0000000, 0x10000000, 0 },
> +	{ 0xB0000000, 0xA0000000, 0x10000000, 0 },
> +

[Severity: High]
This is a pre-existing issue, but I noticed the boundaries of these translation
regions are checked using a strict inequality in imx_rproc_da_to_sys() and
imx_rproc_da_to_va().

In imx_rproc_da_to_sys(), the translation request is checked like this:

drivers/remoteproc/imx_rproc.c:imx_rproc_da_to_sys() {
	...
	if (da >= att->da && da + len < att->da + att->size) {
		unsigned int offset = da - att->da;
	...
}

And similarly in imx_rproc_da_to_va():

drivers/remoteproc/imx_rproc.c:imx_rproc_da_to_va() {
	...
	if (sys >= priv->mem[i].sys_addr && sys + len <
	    priv->mem[i].sys_addr +  priv->mem[i].size) {
		unsigned int offset = sys - priv->mem[i].sys_addr;
	...
}

Does this mean that if a translation request extends exactly to the end of a
memory region (da + len == att->da + att->size), it will be incorrectly
rejected?

Could this cause firmware loading or communication to fail if a resource
table, memory segment, or vring is placed exactly at the end of a memory
region?

>  	{ 0xC0000000, 0xC0000000, 0x10000000, 0 },
>  	{ 0xD0000000, 0xC0000000, 0x10000000, 0 },
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525062031.24725-1-Zhiqiang.Hou@nxp.com?part=1

Re: [PATCHv3] remoteproc: imx_rproc: add missing DRAM ranges for i.MX93

[Peng Fan]

On Mon, May 25, 2026 at 02:20:31PM +0800, Zhiqiang Hou wrote:
>From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>
>The M33 DRAM address ranges 0xA0000000-0xAFFFFFFF(None Secure)
>and 0xB0000000-0xBFFFFFFF(Secure) are both mapped to
>0xA0000000-0xAFFFFFFF in the A55 address space.
>
>These ranges are currently missing from the i.MX93 remoteproc
>address translation table, which may lead to invalid address
>translation for firmware accessing these regions.
>
>Add the missing mappings to complete the DRAM coverage.
>
>Fixes: 9222fabf0e39d ("remoteproc: imx_rproc: Support i.MX93")
>Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCHv3] remoteproc: imx_rproc: add missing DRAM ranges for i.MX93

[Mathieu Poirier]

On Mon, May 25, 2026 at 02:20:31PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> 
> The M33 DRAM address ranges 0xA0000000-0xAFFFFFFF(None Secure)

s/none/non

> and 0xB0000000-0xBFFFFFFF(Secure) are both mapped to
> 0xA0000000-0xAFFFFFFF in the A55 address space.
> 

So the M33 has secure and non-secure ranges mapped at the same address in the
A55?  Are you sure it is not the other way around, i.e A55 has secure and
non-secure address ranges that both map to the same address on M33? 

More details are needed in this changelog.

I'm also wondering how this problem hasn't been fixed before.  The original
patch (9222fabf0e39) was merged over 4 years ago...

> These ranges are currently missing from the i.MX93 remoteproc
> address translation table, which may lead to invalid address
> translation for firmware accessing these regions.
> 
> Add the missing mappings to complete the DRAM coverage.
> 
> Fixes: 9222fabf0e39d ("remoteproc: imx_rproc: Support i.MX93")

The SHA should be 12 characters.

> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> ---
> V3:
>  - Added more info in the changelog.
> 
>  drivers/remoteproc/imx_rproc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 7f54322244aca..175c2d3099794 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -198,6 +198,9 @@ static const struct imx_rproc_att imx_rproc_att_imx93[] = {
>  	{ 0x80000000, 0x80000000, 0x10000000, 0 },
>  	{ 0x90000000, 0x80000000, 0x10000000, 0 },
>  
> +	{ 0xA0000000, 0xA0000000, 0x10000000, 0 },
> +	{ 0xB0000000, 0xA0000000, 0x10000000, 0 },
> +
>  	{ 0xC0000000, 0xC0000000, 0x10000000, 0 },
>  	{ 0xD0000000, 0xC0000000, 0x10000000, 0 },
>  };
> -- 
> 2.43.0
> 

RE: [PATCHv3] remoteproc: imx_rproc: add missing DRAM ranges for i.MX93

[Peng Fan]

> Subject: Re: [PATCHv3] remoteproc: imx_rproc: add missing DRAM
> ranges for i.MX93
> 
> On Mon, May 25, 2026 at 02:20:31PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> >
> > The M33 DRAM address ranges 0xA0000000-0xAFFFFFFF(None
> Secure)
> 
> s/none/non
> 
> > and 0xB0000000-0xBFFFFFFF(Secure) are both mapped to
> > 0xA0000000-0xAFFFFFFF in the A55 address space.
> >
> 
> So the M33 has secure and non-secure ranges mapped at the same
> address in the A55? 

Yes.

Bit28 is used to differentiate secure and non-secure from M33 view
per NXP design.
Cortex-A55 cores has same view as system view.

 Are you sure it is not the other way around, i.e
> A55 has secure and non-secure address ranges that both map to the
> same address on M33?

No. only M33 use bit28 to differentiate secure/non-secure region
per NXP design.

       M33                                                                    system map / A55
-----------------------------------------------------        -----------------------------
0xA0000000 - 0xAFFFFFFF (non secure)           0xA.... -  0xAF....
-----------------------------------------------------        -----------------------------
0xB0000000 - 0xBFFFFFFF (secure)                   M33 not accessiable
-----------------------------------------------------        -----------------------------


> 
> More details are needed in this changelog.
> 
> I'm also wondering how this problem hasn't been fixed before.  The
> original patch (9222fabf0e39) was merged over 4 years ago...

At that time, I could only test remoteproc with what our MCU SW
team delivered to me.
For regions that I was not able to test, I not included them when I
added i.MX93 support.

Even this patch is marked as fix, I think it could be put in for-next tree.

Regards
Peng.