[PATCH 0/4] Add i.MX94 remoteproc support and reset vector handling improvements

[PATCH 0/4] Add i.MX94 remoteproc support and reset vector handling improvements

[Peng Fan (OSS)]

This series adds remoteproc support for the i.MX94 family, including the
CM70, CM71, and CM33S cores, and introduces a new device‑tree property to
correctly derive the hardware reset vector for Cortex‑M processors whose
ELF entry point does not directly correspond to the actual reset address.

Background:
Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
table. While ELF images embed the entry point (e_entry), this value is
not always aligned to the hardware reset address. On platforms such as
i.MX94 CM33S, masking is required to compute the correct reset vector
address before programming the SoC reset registers.

Similarly, on i.MX95, the existing implementation always programs a reset
vector of 0x0, which only works when executing entirely from TCM. When
firmware is loaded into DDR, the driver must pass the correct reset vector
to the SM CPU/LMM interfaces.

This series addresses these issues and provides the necessary DT bindings
and driver support.

Summary of patches:
[1]dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
Adds a new DT property allowing SoCs to specify a mask for deriving the
hardware reset vector from the ELF entry point.

[2]dt-bindings: remoteproc: imx-rproc: Support i.MX9[4,52]
Adds compatible strings for i.MX94 CM70, CM71, and CM33S processors.

[3]remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
Ensures the correct reset vector is passed to SM APIs by introducing a
driver‑level helper (imx_rproc_get_boot_addr()) that applies the
reset‑vector mask.

[4]remoteproc: imx_rproc: Add support for i.MX94 remoteproc
Adds address translation tables and configuration data for CM70, CM71,
and CM33S, enabling full remoteproc operation on i.MX94.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (4):
      dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
      dt-bindings: remoteproc: imx-rproc: Support i.MX94
      remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
      remoteproc: imx_rproc: Add support for i.MX94

 .../bindings/remoteproc/fsl,imx-rproc.yaml         |  9 +++
 drivers/remoteproc/imx_rproc.c                     | 85 +++++++++++++++++++++-
 2 files changed, 91 insertions(+), 3 deletions(-)
---
base-commit: 7109a2155340cc7b21f27e832ece6df03592f2e8
change-id: 20260311-imx943-rproc-2050e00b65f7

Best regards,
-- 
Peng Fan <peng.fan@nxp.com>

[PATCH 1/4] dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Cortex-M[7,33] processors use a fixed reset vector table format:

  0x00  Initial SP value
  0x04  Reset vector
  0x08  NMI
  0x0C  ...
  ...
  IRQ[n]

In ELF images, the corresponding layout is:

reset_vectors:  --> hardware reset address
        .word __stack_end__
        .word Reset_Handler
        .word NMI_Handler
        .word HardFault_Handler
        ...
        .word UART_IRQHandler
        .word SPI_IRQHandler
        ...

Reset_Handler:  --> ELF entry point address
        ...

The hardware fetches the first two words from reset_vectors and populates
SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
Reset_Handler.

However, the ELF entry point does not always match the hardware reset
address. For example, on i.MX94 CM33S:

  ELF entry point:           0x0ffc211d
  CM33S hardware reset base: 0x0ffc0000

To derive the correct hardware reset address, the unused lower bits must
be masked off. The boot code should apply a SoC‑specific mask before
programming the reset address registers, e.g.:

  reset_address = entry & reset-vector-mask

This reset address derivation method is also applicable to i.MX8M
Cortex-M7/4 cores.

Introduces the optional DT property `fsl,reset-vector-mask` to specify the
mask used for deriving the hardware reset address from
the ELF entry point.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index ce8ec0119469c8fc0979a192b6e3d3a03108d7d2..683f0c36293c08616621daa79c0b8914b0f48bba 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -85,6 +85,12 @@ properties:
       This property is to specify the resource id of the remote processor in SoC
       which supports SCFW
 
+  fsl,reset-vector-mask:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      This property is to specify the reset vector mask which is used
+      to mask off unused bits from ELF entry address.
+
 required:
   - compatible
 

-- 
2.37.1

Re: [PATCH 1/4] dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask

[Daniel Baluta]

On 3/12/26 14:36, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Cortex-M[7,33] processors use a fixed reset vector table format:
>
>   0x00  Initial SP value
>   0x04  Reset vector
>   0x08  NMI
>   0x0C  ...
>   ...
>   IRQ[n]
>
> In ELF images, the corresponding layout is:
>
> reset_vectors:  --> hardware reset address
>         .word __stack_end__
>         .word Reset_Handler
>         .word NMI_Handler
>         .word HardFault_Handler
>         ...
>         .word UART_IRQHandler
>         .word SPI_IRQHandler
>         ...
>
> Reset_Handler:  --> ELF entry point address
>         ...
>
> The hardware fetches the first two words from reset_vectors and populates
> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> Reset_Handler.
>
> However, the ELF entry point does not always match the hardware reset
> address. For example, on i.MX94 CM33S:
>
>   ELF entry point:           0x0ffc211d
>   CM33S hardware reset base: 0x0ffc0000
>
> To derive the correct hardware reset address, the unused lower bits must
> be masked off. The boot code should apply a SoC‑specific mask before
> programming the reset address registers, e.g.:
>
>   reset_address = entry & reset-vector-mask


What do you think about this idea:

Use fsl,reset-vector-base instead of a mask. It could happen that for example

a CM7 instance has explicit requirements to boot from TCM but the entry point is in DRAM.
Then masking won't help.

fsl,reset-vector-base is always fixed hardware integration dependent and you can always

specify it in DT.

Re: [PATCH 1/4] dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask

[Peng Fan]

Hi Daniel,

On Fri, Mar 20, 2026 at 11:46:53AM +0200, Daniel Baluta wrote:
>On 3/12/26 14:36, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>>
>> Cortex-M[7,33] processors use a fixed reset vector table format:
>>
>>   0x00  Initial SP value
>>   0x04  Reset vector
>>   0x08  NMI
>>   0x0C  ...
>>   ...
>>   IRQ[n]
>>
>> In ELF images, the corresponding layout is:
>>
>> reset_vectors:  --> hardware reset address
>>         .word __stack_end__
>>         .word Reset_Handler
>>         .word NMI_Handler
>>         .word HardFault_Handler
>>         ...
>>         .word UART_IRQHandler
>>         .word SPI_IRQHandler
>>         ...
>>
>> Reset_Handler:  --> ELF entry point address
>>         ...
>>
>> The hardware fetches the first two words from reset_vectors and populates
>> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
>> Reset_Handler.
>>
>> However, the ELF entry point does not always match the hardware reset
>> address. For example, on i.MX94 CM33S:
>>
>>   ELF entry point:           0x0ffc211d
>>   CM33S hardware reset base: 0x0ffc0000
>>
>> To derive the correct hardware reset address, the unused lower bits must
>> be masked off. The boot code should apply a SoC‑specific mask before
>> programming the reset address registers, e.g.:
>>
>>   reset_address = entry & reset-vector-mask
>
>
>What do you think about this idea:
>
>Use fsl,reset-vector-base instead of a mask. It could happen that for example
>
>a CM7 instance has explicit requirements to boot from TCM but the entry point is in DRAM.
>Then masking won't help.
>
>fsl,reset-vector-base is always fixed hardware integration dependent and you can always
>
>specify it in DT.
>

Thanks for sharing ideas. But this not work:
1. User start an elf which is built to run in TCM. the reset vector is in TCM.
2. User stop remote processor
3. User start an elf which is built to run in DDR. the reset vector is in DDR.

So a fixed fsl,reset-vector-base not work. We need a per elf reset vector base.

For the case you list about boot from TCM, entry is DRAM. this is i.MX8M DDR
elf demo. The hardware always fetches PC/STACK from 0, but elf entry is in
DDR. We always use 0 as boot address for i.MX8M, no matter what elf entry is.

For i.MX95/943, there is an register to configure M7 or M33S start address,
If the image is designed to run in DDR, user should set reset vector and elf
entry both in DDR. If the image is designed to run TCM, but space is not enough,
DDR is also used, the reset vector and elf entry should be both in TCM.

Per my talk with NXP SDK team, It is less that 16KB from reset vector to
elf entry address.

But in case people really want the case you list, we may use a flag
BIT0: 0 means base
BIT0: 1 means mask

fsl,reset-vector = <0x[x] | BIT(0)>;  --> mask
fsl,reset-vector = <0x[x] & ~BIT(0)>; --> base

Thanks
Peng
>

Re: [PATCH 1/4] dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask

[Daniel Baluta]

On 3/20/26 15:02, Peng Fan wrote:
> Hi Daniel,
>
> On Fri, Mar 20, 2026 at 11:46:53AM +0200, Daniel Baluta wrote:

Hi Peng,


Thanks for your explanation. Few comments inline so that we can

find the most scalable solution for all IMX platforms.

>> On 3/12/26 14:36, Peng Fan (OSS) wrote:
>>> From: Peng Fan <peng.fan@nxp.com>
>>>
>>> Cortex-M[7,33] processors use a fixed reset vector table format:
>>>
>>>   0x00  Initial SP value
>>>   0x04  Reset vector
>>>   0x08  NMI
>>>   0x0C  ...
>>>   ...
>>>   IRQ[n]
>>>
>>> In ELF images, the corresponding layout is:
>>>
>>> reset_vectors:  --> hardware reset address

Is the hardware reset address fixed by the hardware team? Can it be modified at runtime by software (e.g SM or any other firmware)?

For example, with M7 on i.MX8MP the M7 core will always boot at address 0.
See table and explanation here: https://docs.zephyrproject.org/latest/boards/nxp/imx8mp_evk/doc/index.html
So even if you build an ELF to run in DDR the reset vector won't be placed in the DDR. But instead you need

to add a small romstart code in ITCM that is you put the reset vectors in ITCM then you jump to DDR.

>>>         .word __stack_end__
>>>         .word Reset_Handler
>>>         .word NMI_Handler
>>>         .word HardFault_Handler
>>>         ...
>>>         .word UART_IRQHandler
>>>         .word SPI_IRQHandler
>>>         ...
>>>
>>> Reset_Handler:  --> ELF entry point address
>>>         ...
>>>
>>> The hardware fetches the first two words from reset_vectors and populates
>>> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
>>> Reset_Handler.
>>>
>>> However, the ELF entry point does not always match the hardware reset
>>> address. For example, on i.MX94 CM33S:
>>>
>>>   ELF entry point:           0x0ffc211d
>>>   CM33S hardware reset base: 0x0ffc0000
>>>
>>> To derive the correct hardware reset address, the unused lower bits must
>>> be masked off. The boot code should apply a SoC‑specific mask before
>>> programming the reset address registers, e.g.:
>>>
>>>   reset_address = entry & reset-vector-mask
>>
>> What do you think about this idea:
>>
>> Use fsl,reset-vector-base instead of a mask. It could happen that for example
>>
>> a CM7 instance has explicit requirements to boot from TCM but the entry point is in DRAM.
>> Then masking won't help.
>>
>> fsl,reset-vector-base is always fixed hardware integration dependent and you can always
>>
>> specify it in DT.
>>
> Thanks for sharing ideas. But this not work:
> 1. User start an elf which is built to run in TCM. the reset vector is in TCM.
> 2. User stop remote processor
> 3. User start an elf which is built to run in DDR. the reset vector is in DDR.
>
> So a fixed fsl,reset-vector-base not work. We need a per elf reset vector base.

Ok, I see. So a fixed reset-vector-base won't work! But in your case above a fixed

reset-mask won't work unless you always know that for both cases (TCM, DDR) the

entry point is within a fixed interval relative to the reset vectors.

> For the case you list about boot from TCM, entry is DRAM. this is i.MX8M DDR
> elf demo. The hardware always fetches PC/STACK from 0, but elf entry is in
> DDR. We always use 0 as boot address for i.MX8M, no matter what elf entry is.
>
> For i.MX95/943, there is an register to configure M7 or M33S start address,
> If the image is designed to run in DDR, user should set reset vector and elf
> entry both in DDR. If the image is designed to run TCM, but space is not enough,
> DDR is also used, the reset vector and elf entry should be both in TCM.
>
> Per my talk with NXP SDK team, It is less that 16KB from reset vector to
> elf entry address.

I think with this assumption it will work. Please mention this in the commit message

and we will go with your initial idea.

Re: [PATCH 1/4] dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask

[Rob Herring]

On Thu, Mar 12, 2026 at 08:36:56PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> Cortex-M[7,33] processors use a fixed reset vector table format:
> 
>   0x00  Initial SP value
>   0x04  Reset vector
>   0x08  NMI
>   0x0C  ...
>   ...
>   IRQ[n]
> 
> In ELF images, the corresponding layout is:
> 
> reset_vectors:  --> hardware reset address
>         .word __stack_end__
>         .word Reset_Handler
>         .word NMI_Handler
>         .word HardFault_Handler
>         ...
>         .word UART_IRQHandler
>         .word SPI_IRQHandler
>         ...
> 
> Reset_Handler:  --> ELF entry point address
>         ...
> 
> The hardware fetches the first two words from reset_vectors and populates
> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> Reset_Handler.
> 
> However, the ELF entry point does not always match the hardware reset
> address. For example, on i.MX94 CM33S:
> 
>   ELF entry point:           0x0ffc211d
>   CM33S hardware reset base: 0x0ffc0000
> 
> To derive the correct hardware reset address, the unused lower bits must
> be masked off. The boot code should apply a SoC‑specific mask before
> programming the reset address registers, e.g.:
> 
>   reset_address = entry & reset-vector-mask
> 
> This reset address derivation method is also applicable to i.MX8M
> Cortex-M7/4 cores.
> 
> Introduces the optional DT property `fsl,reset-vector-mask` to specify the
> mask used for deriving the hardware reset address from
> the ELF entry point.

Why can't you fix the ELF image to have the right address?

Or just imply the reset address from the compatible? It's fixed per SoC, 
right?

Rob

Re: [PATCH 1/4] dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask

[Daniel Baluta]

On Mon, Mar 23, 2026 at 9:16 PM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Mar 12, 2026 at 08:36:56PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Cortex-M[7,33] processors use a fixed reset vector table format:
> >
> >   0x00  Initial SP value
> >   0x04  Reset vector
> >   0x08  NMI
> >   0x0C  ...
> >   ...
> >   IRQ[n]
> >
> > In ELF images, the corresponding layout is:
> >
> > reset_vectors:  --> hardware reset address
> >         .word __stack_end__
> >         .word Reset_Handler
> >         .word NMI_Handler
> >         .word HardFault_Handler
> >         ...
> >         .word UART_IRQHandler
> >         .word SPI_IRQHandler
> >         ...
> >
> > Reset_Handler:  --> ELF entry point address
> >         ...
> >
> > The hardware fetches the first two words from reset_vectors and populates
> > SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> > Reset_Handler.
> >
> > However, the ELF entry point does not always match the hardware reset
> > address. For example, on i.MX94 CM33S:
> >
> >   ELF entry point:           0x0ffc211d
> >   CM33S hardware reset base: 0x0ffc0000
> >
> > To derive the correct hardware reset address, the unused lower bits must
> > be masked off. The boot code should apply a SoC‑specific mask before
> > programming the reset address registers, e.g.:
> >
> >   reset_address = entry & reset-vector-mask
> >
> > This reset address derivation method is also applicable to i.MX8M
> > Cortex-M7/4 cores.
> >
> > Introduces the optional DT property `fsl,reset-vector-mask` to specify the
> > mask used for deriving the hardware reset address from
> > the ELF entry point.
>
> Why can't you fix the ELF image to have the right address?

This is a good suggestion! Or parse the ELF file and figure out the
reset address at runtime.
>
> Or just imply the reset address from the compatible? It's fixed per SoC,
> right?

This won't work because for the same SoC depending on where you want
to boot from (e.g ITCM, DRAM)
the reset address might be different.

[PATCH 2/4] dt-bindings: remoteproc: imx-rproc: Support i.MX94

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Add compatible string for:
 Cortex-M7 core[0,1] in i.MX94
 Cortex-M33 Sync core in i.MX94

To i.MX94, Cortex-M7 core0 and core1 have different memory view from
Cortex-A55 core, so different compatible string is used.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 683f0c36293c08616621daa79c0b8914b0f48bba..b136b3c3ca3ce9ff92d91f4b8ffc29c614edb66a 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -28,6 +28,9 @@ properties:
       - fsl,imx8qxp-cm4
       - fsl,imx8ulp-cm33
       - fsl,imx93-cm33
+      - fsl,imx94-cm33s
+      - fsl,imx94-cm70
+      - fsl,imx94-cm71
       - fsl,imx95-cm7
 
   clocks:

-- 
2.37.1

Re: [PATCH 2/4] dt-bindings: remoteproc: imx-rproc: Support i.MX94

[Frank Li]

On Thu, Mar 12, 2026 at 08:36:57PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add compatible string for:
>  Cortex-M7 core[0,1] in i.MX94
>  Cortex-M33 Sync core in i.MX94
>
> To i.MX94, Cortex-M7 core0 and core1 have different memory view from
> Cortex-A55 core, so different compatible string is used.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>
>  Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index 683f0c36293c08616621daa79c0b8914b0f48bba..b136b3c3ca3ce9ff92d91f4b8ffc29c614edb66a 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -28,6 +28,9 @@ properties:
>        - fsl,imx8qxp-cm4
>        - fsl,imx8ulp-cm33
>        - fsl,imx93-cm33
> +      - fsl,imx94-cm33s
> +      - fsl,imx94-cm70
> +      - fsl,imx94-cm71
>        - fsl,imx95-cm7
>
>    clocks:
>
> --
> 2.37.1
>

Re: [PATCH 2/4] dt-bindings: remoteproc: imx-rproc: Support i.MX94

[Daniel Baluta]

On 3/12/26 14:36, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add compatible string for:
>  Cortex-M7 core[0,1] in i.MX94
>  Cortex-M33 Sync core in i.MX94
>
> To i.MX94, Cortex-M7 core0 and core1 have different memory view from
> Cortex-A55 core, so different compatible string is used.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>


Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>

Re: [PATCH 2/4] dt-bindings: remoteproc: imx-rproc: Support i.MX94

[Rob Herring (Arm)]

On Thu, 12 Mar 2026 20:36:57 +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> Add compatible string for:
>  Cortex-M7 core[0,1] in i.MX94
>  Cortex-M33 Sync core in i.MX94
> 
> To i.MX94, Cortex-M7 core0 and core1 have different memory view from
> Cortex-A55 core, so different compatible string is used.
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>  Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH 3/4] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Current driver always programs the reset vector as 0. This works when
the Cortex‑M7 on i.MX95 executes from TCM, since the reset vector is
naturally located at address 0. However, when the firmware is loaded into
DDR, the reset vector must be set to the actual reset address instead of 0.

For the Cortex‑M33 Sync core on i.MX94, the CODE TCM base is also not 0,
so the correct reset vector must be passed to the SM API; otherwise the
M33 Sync core cannot boot successfully.

rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
hardware reset vector address. To derive the proper reset vector, this
patch introduces imx_rproc_get_boot_addr(), which masks the ELF entry
point using the SoC‑specific 'reset_vector_mask'. The resulting reset
vector address is then passed to the appropriate SM CPU/LMM reset vector
API calls.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 0dd80e688b0ea3df4c66e5726884dc86c8a5a881..9b07103857b13018bdf62431cbfeffa3e3c1a15c 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -124,6 +124,7 @@ struct imx_rproc {
 	u32				rsrc_id;	/* resource id */
 	u32				entry;		/* cpu start address */
 	u32				core_index;
+	u32				reset_vector_mask;
 	struct dev_pm_domain_list	*pd_list;
 	const struct imx_rproc_plat_ops	*ops;
 	/*
@@ -345,7 +346,7 @@ static int imx_rproc_sm_cpu_start(struct rproc *rproc)
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	int ret;
 
-	ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, 0, true, false, false);
+	ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, rproc->bootaddr, true, false, false);
 	if (ret) {
 		dev_err(priv->dev, "Failed to set reset vector cpuid(%u): %d\n", dcfg->cpuid, ret);
 		return ret;
@@ -365,7 +366,7 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
 	 * If the remoteproc core can't start the M7, it will already be
 	 * handled in imx_rproc_sm_lmm_prepare().
 	 */
-	ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, 0);
+	ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, rproc->bootaddr);
 	if (ret) {
 		dev_err(dev, "Failed to set reset vector lmid(%u), cpuid(%u): %d\n",
 			dcfg->lmid, dcfg->cpuid, ret);
@@ -739,6 +740,13 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
 	return rproc_elf_find_loaded_rsc_table(rproc, fw);
 }
 
+static u64 imx_rproc_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
+{
+	struct imx_rproc *priv = rproc->priv;
+
+	return rproc_elf_get_boot_addr(rproc, fw) & priv->reset_vector_mask;
+}
+
 static const struct rproc_ops imx_rproc_ops = {
 	.prepare	= imx_rproc_prepare,
 	.attach		= imx_rproc_attach,
@@ -752,7 +760,7 @@ static const struct rproc_ops imx_rproc_ops = {
 	.find_loaded_rsc_table = imx_rproc_elf_find_loaded_rsc_table,
 	.get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
 	.sanity_check	= rproc_elf_sanity_check,
-	.get_boot_addr	= rproc_elf_get_boot_addr,
+	.get_boot_addr	= imx_rproc_get_boot_addr,
 };
 
 static int imx_rproc_addr_init(struct imx_rproc *priv,
@@ -1244,6 +1252,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	priv->rproc = rproc;
 	priv->dcfg = dcfg;
 	priv->dev = dev;
+	priv->reset_vector_mask = GENMASK(31, 0);
+
+	of_property_read_u32(np, "fsl,reset-vector-mask", &priv->reset_vector_mask);
 
 	if (dcfg->ops)
 		priv->ops = dcfg->ops;

-- 
2.37.1

[PATCH 4/4] remoteproc: imx_rproc: Add support for i.MX94

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Add basic remoteproc support for the i.MX94 M-core processors, including
address translation tables and device configuration data for the CM70,
CM71, and CM33S cores.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 68 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 9b07103857b13018bdf62431cbfeffa3e3c1a15c..8278643eeb390518981e8beae086b73be265f50b 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -146,6 +146,47 @@ static const struct imx_rproc_att imx_rproc_att_imx95_m7[] = {
 	{ 0x80000000, 0x80000000, 0x50000000, 0 },
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx94_m70[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* TCM CODE NON-SECURE */
+	{ 0x00000000, 0x203C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+	/* TCM SYS NON-SECURE*/
+	{ 0x20000000, 0x20400000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+	/* DDR */
+	{ 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m71[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* TCM CODE NON-SECURE */
+	{ 0x00000000, 0x202C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+	/* TCM SYS NON-SECURE*/
+	{ 0x20000000, 0x20300000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+	/* DDR */
+	{ 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m33s[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* TCM CODE NON-SECURE */
+	{ 0x0FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+	/* TCM CODE SECURE */
+	{ 0x1FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+	/* TCM SYS NON-SECURE */
+	{ 0x20000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
+	/* TCM SYS NON-SECURE */
+	{ 0x30000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+	/* M33S OCRAM */
+	{ 0x20800000, 0x20800000, 0x180000, ATT_OWN | ATT_IOMEM },
+
+	/* DDR */
+	{ 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx93[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* TCM CODE NON-SECURE */
@@ -1466,6 +1507,30 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx93 = {
 	.flags		= IMX_RPROC_NEED_CLKS,
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m70 = {
+	.att		= imx_rproc_att_imx94_m70,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m70),
+	.ops		= &imx_rproc_ops_sm_lmm,
+	.cpuid		= 1,
+	.lmid		= 2,
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m71 = {
+	.att		= imx_rproc_att_imx94_m71,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m71),
+	.ops		= &imx_rproc_ops_sm_lmm,
+	.cpuid		= 7,
+	.lmid		= 3,
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m33s = {
+	.att		= imx_rproc_att_imx94_m33s,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m33s),
+	.ops		= &imx_rproc_ops_sm_lmm,
+	.cpuid		= 8,
+	.lmid		= 1,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
 	.att		= imx_rproc_att_imx95_m7,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx95_m7),
@@ -1489,6 +1554,9 @@ static const struct of_device_id imx_rproc_of_match[] = {
 	{ .compatible = "fsl,imx8qm-cm4", .data = &imx_rproc_cfg_imx8qm },
 	{ .compatible = "fsl,imx8ulp-cm33", .data = &imx_rproc_cfg_imx8ulp },
 	{ .compatible = "fsl,imx93-cm33", .data = &imx_rproc_cfg_imx93 },
+	{ .compatible = "fsl,imx94-cm70", .data = &imx_rproc_cfg_imx94_m70 },
+	{ .compatible = "fsl,imx94-cm71", .data = &imx_rproc_cfg_imx94_m71 },
+	{ .compatible = "fsl,imx94-cm33s", .data = &imx_rproc_cfg_imx94_m33s },
 	{ .compatible = "fsl,imx95-cm7", .data = &imx_rproc_cfg_imx95_m7 },
 	{},
 };

-- 
2.37.1

Re: [PATCH 4/4] remoteproc: imx_rproc: Add support for i.MX94

[Frank Li]

From: Frank Li (AI-BOT) <frank.li@nxp.com>

> +	/* TCM CODE SECURE */
> +	{ 0x1FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +
> +	/* TCM SYS NON-SECURE */
> +	{ 0x20000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +	/* TCM SYS NON-SECURE */
AI: Duplicate comment label. The second one should clarify which TCM SYS region
this is (e.g., "TCM SYS NON-SECURE (alias)" or similar).

Frank

Re: [PATCH 4/4] remoteproc: imx_rproc: Add support for i.MX94

[Daniel Baluta]

On 3/12/26 14:36, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add basic remoteproc support for the i.MX94 M-core processors, including
> address translation tables and device configuration data for the CM70,
> CM71, and CM33S cores.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>

Can you please mention in the commit message what is 'dev addr' and 'sys addr'. This

is a thing that I always spent some time to figure it out. 

Thus adding this information to the commit message will help for future users.

With that,

Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>


> ---
>  drivers/remoteproc/imx_rproc.c | 68 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 9b07103857b13018bdf62431cbfeffa3e3c1a15c..8278643eeb390518981e8beae086b73be265f50b 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -146,6 +146,47 @@ static const struct imx_rproc_att imx_rproc_att_imx95_m7[] = {
>  	{ 0x80000000, 0x80000000, 0x50000000, 0 },
>  };
>  
> +static const struct imx_rproc_att imx_rproc_att_imx94_m70[] = {
> +	/* dev addr , sys addr  , size	    , flags */
> +	/* TCM CODE NON-SECURE */
> +	{ 0x00000000, 0x203C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +	/* TCM SYS NON-SECURE*/
> +	{ 0x20000000, 0x20400000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +
> +	/* DDR */
> +	{ 0x80000000, 0x80000000, 0x50000000, 0 },
> +};
> +
> +static const struct imx_rproc_att imx_rproc_att_imx94_m71[] = {
> +	/* dev addr , sys addr  , size	    , flags */
> +	/* TCM CODE NON-SECURE */
> +	{ 0x00000000, 0x202C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +	/* TCM SYS NON-SECURE*/
> +	{ 0x20000000, 0x20300000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +
> +	/* DDR */
> +	{ 0x80000000, 0x80000000, 0x50000000, 0 },
> +};
> +
> +static const struct imx_rproc_att imx_rproc_att_imx94_m33s[] = {
> +	/* dev addr , sys addr  , size	    , flags */
> +	/* TCM CODE NON-SECURE */
> +	{ 0x0FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +	/* TCM CODE SECURE */
> +	{ 0x1FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +
> +	/* TCM SYS NON-SECURE */
> +	{ 0x20000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +	/* TCM SYS NON-SECURE */
> +	{ 0x30000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
> +
> +	/* M33S OCRAM */
> +	{ 0x20800000, 0x20800000, 0x180000, ATT_OWN | ATT_IOMEM },
> +
> +	/* DDR */
> +	{ 0x80000000, 0x80000000, 0x50000000, 0 },
> +};
> +
>  static const struct imx_rproc_att imx_rproc_att_imx93[] = {
>  	/* dev addr , sys addr  , size	    , flags */
>  	/* TCM CODE NON-SECURE */
> @@ -1466,6 +1507,30 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx93 = {
>  	.flags		= IMX_RPROC_NEED_CLKS,
>  };
>  
> +static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m70 = {
> +	.att		= imx_rproc_att_imx94_m70,
> +	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m70),
> +	.ops		= &imx_rproc_ops_sm_lmm,
> +	.cpuid		= 1,
> +	.lmid		= 2,
> +};
> +
> +static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m71 = {
> +	.att		= imx_rproc_att_imx94_m71,
> +	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m71),
> +	.ops		= &imx_rproc_ops_sm_lmm,
> +	.cpuid		= 7,
> +	.lmid		= 3,
> +};
> +
> +static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m33s = {
> +	.att		= imx_rproc_att_imx94_m33s,
> +	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m33s),
> +	.ops		= &imx_rproc_ops_sm_lmm,
> +	.cpuid		= 8,
> +	.lmid		= 1,
> +};
> +
>  static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
>  	.att		= imx_rproc_att_imx95_m7,
>  	.att_size	= ARRAY_SIZE(imx_rproc_att_imx95_m7),
> @@ -1489,6 +1554,9 @@ static const struct of_device_id imx_rproc_of_match[] = {
>  	{ .compatible = "fsl,imx8qm-cm4", .data = &imx_rproc_cfg_imx8qm },
>  	{ .compatible = "fsl,imx8ulp-cm33", .data = &imx_rproc_cfg_imx8ulp },
>  	{ .compatible = "fsl,imx93-cm33", .data = &imx_rproc_cfg_imx93 },
> +	{ .compatible = "fsl,imx94-cm70", .data = &imx_rproc_cfg_imx94_m70 },
> +	{ .compatible = "fsl,imx94-cm71", .data = &imx_rproc_cfg_imx94_m71 },
> +	{ .compatible = "fsl,imx94-cm33s", .data = &imx_rproc_cfg_imx94_m33s },
>  	{ .compatible = "fsl,imx95-cm7", .data = &imx_rproc_cfg_imx95_m7 },
>  	{},
>  };
>

Re: [PATCH 0/4] Add i.MX94 remoteproc support and reset vector handling improvements

[Daniel Baluta]

On 3/12/26 14:36, Peng Fan (OSS) wrote:
> This series adds remoteproc support for the i.MX94 family, including the
> CM70, CM71, and CM33S cores, and introduces a new device‑tree property to
> correctly derive the hardware reset vector for Cortex‑M processors whose
> ELF entry point does not directly correspond to the actual reset address.
>
> Background:
> Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
> table. While ELF images embed the entry point (e_entry), this value is
> not always aligned to the hardware reset address. On platforms such as
> i.MX94 CM33S, masking is required to compute the correct reset vector
> address before programming the SoC reset registers.

What happens if the reset vector is at 0 and the e_entry point is at 0x800...?

In this case masking will no longer work! Can we implement a generic approach?


>
> Similarly, on i.MX95, the existing implementation always programs a reset
> vector of 0x0, which only works when executing entirely from TCM. When
> firmware is loaded into DDR, the driver must pass the correct reset vector
> to the SM CPU/LMM interfaces.
>
> This series addresses these issues and provides the necessary DT bindings
> and driver support.
>
> Summary of patches:
> [1]dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
> Adds a new DT property allowing SoCs to specify a mask for deriving the
> hardware reset vector from the ELF entry point.
>
> [2]dt-bindings: remoteproc: imx-rproc: Support i.MX9[4,52]
> Adds compatible strings for i.MX94 CM70, CM71, and CM33S processors.
>
> [3]remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
> Ensures the correct reset vector is passed to SM APIs by introducing a
> driver‑level helper (imx_rproc_get_boot_addr()) that applies the
> reset‑vector mask.
>
> [4]remoteproc: imx_rproc: Add support for i.MX94 remoteproc
> Adds address translation tables and configuration data for CM70, CM71,
> and CM33S, enabling full remoteproc operation on i.MX94.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (4):
>       dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
>       dt-bindings: remoteproc: imx-rproc: Support i.MX94
>       remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
>       remoteproc: imx_rproc: Add support for i.MX94
>
>  .../bindings/remoteproc/fsl,imx-rproc.yaml         |  9 +++
>  drivers/remoteproc/imx_rproc.c                     | 85 +++++++++++++++++++++-
>  2 files changed, 91 insertions(+), 3 deletions(-)
> ---
> base-commit: 7109a2155340cc7b21f27e832ece6df03592f2e8
> change-id: 20260311-imx943-rproc-2050e00b65f7
>
> Best regards,

Re: [PATCH 0/4] Add i.MX94 remoteproc support and reset vector handling improvements

[Mathieu Poirier]

On Fri, Mar 20, 2026 at 11:19:06AM +0200, Daniel Baluta wrote:
> On 3/12/26 14:36, Peng Fan (OSS) wrote:
> > This series adds remoteproc support for the i.MX94 family, including the
> > CM70, CM71, and CM33S cores, and introduces a new device‑tree property to
> > correctly derive the hardware reset vector for Cortex‑M processors whose
> > ELF entry point does not directly correspond to the actual reset address.
> >
> > Background:
> > Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
> > table. While ELF images embed the entry point (e_entry), this value is
> > not always aligned to the hardware reset address. On platforms such as
> > i.MX94 CM33S, masking is required to compute the correct reset vector
> > address before programming the SoC reset registers.
> 
> What happens if the reset vector is at 0 and the e_entry point is at 0x800...?
> 
> In this case masking will no longer work! Can we implement a generic approach?
>

I will wait to see an R-B from Daniel before looking at this set.

Thanks,
Mathieu
 
> 
> >
> > Similarly, on i.MX95, the existing implementation always programs a reset
> > vector of 0x0, which only works when executing entirely from TCM. When
> > firmware is loaded into DDR, the driver must pass the correct reset vector
> > to the SM CPU/LMM interfaces.
> >
> > This series addresses these issues and provides the necessary DT bindings
> > and driver support.
> >
> > Summary of patches:
> > [1]dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
> > Adds a new DT property allowing SoCs to specify a mask for deriving the
> > hardware reset vector from the ELF entry point.
> >
> > [2]dt-bindings: remoteproc: imx-rproc: Support i.MX9[4,52]
> > Adds compatible strings for i.MX94 CM70, CM71, and CM33S processors.
> >
> > [3]remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
> > Ensures the correct reset vector is passed to SM APIs by introducing a
> > driver‑level helper (imx_rproc_get_boot_addr()) that applies the
> > reset‑vector mask.
> >
> > [4]remoteproc: imx_rproc: Add support for i.MX94 remoteproc
> > Adds address translation tables and configuration data for CM70, CM71,
> > and CM33S, enabling full remoteproc operation on i.MX94.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > Peng Fan (4):
> >       dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
> >       dt-bindings: remoteproc: imx-rproc: Support i.MX94
> >       remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
> >       remoteproc: imx_rproc: Add support for i.MX94
> >
> >  .../bindings/remoteproc/fsl,imx-rproc.yaml         |  9 +++
> >  drivers/remoteproc/imx_rproc.c                     | 85 +++++++++++++++++++++-
> >  2 files changed, 91 insertions(+), 3 deletions(-)
> > ---
> > base-commit: 7109a2155340cc7b21f27e832ece6df03592f2e8
> > change-id: 20260311-imx943-rproc-2050e00b65f7
> >
> > Best regards,
> 
> 

Re: [PATCH 0/4] Add i.MX94 remoteproc support and reset vector handling improvements

[Daniel Baluta]

On 3/23/26 16:32, Mathieu Poirier wrote:
> On Fri, Mar 20, 2026 at 11:19:06AM +0200, Daniel Baluta wrote:
>> On 3/12/26 14:36, Peng Fan (OSS) wrote:
>>> This series adds remoteproc support for the i.MX94 family, including the
>>> CM70, CM71, and CM33S cores, and introduces a new device‑tree property to
>>> correctly derive the hardware reset vector for Cortex‑M processors whose
>>> ELF entry point does not directly correspond to the actual reset address.
>>>
>>> Background:
>>> Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
>>> table. While ELF images embed the entry point (e_entry), this value is
>>> not always aligned to the hardware reset address. On platforms such as
>>> i.MX94 CM33S, masking is required to compute the correct reset vector
>>> address before programming the SoC reset registers.
>> What happens if the reset vector is at 0 and the e_entry point is at 0x800...?
>>
>> In this case masking will no longer work! Can we implement a generic approach?
>>
> I will wait to see an R-B from Daniel before looking at this set.
>
> Thanks,
> Mathieu
>  
>
Hi Mathieu, Peng,

Patchseries mostly looks good to me. The only blocking issue here is how to correctly specify the hardware reset address.

I see two options here:

1) Create a special section in TCM that holds the PC/Stack initial value as concluded here [1]. But this

doesn't work in all the cases 

2) Add a per device data that holds the hardware reset mask that gets applied to entry address read from ELF.

I'm fine going with option 2) and that's because this change is IMX rproc driver specific, it scales well and will be maintained by Peng.

thanks,

Daniel.

[1] https://lore.kernel.org/linux-remoteproc/38476dd0-07a6-310f-1fba-2b3021a5b007@kontron.de/

Re: [PATCH 0/4] Add i.MX94 remoteproc support and reset vector handling improvements

[Peng Fan]

On Wed, Mar 25, 2026 at 10:41:29AM +0200, Daniel Baluta wrote:
>On 3/23/26 16:32, Mathieu Poirier wrote:
>> On Fri, Mar 20, 2026 at 11:19:06AM +0200, Daniel Baluta wrote:
>>> On 3/12/26 14:36, Peng Fan (OSS) wrote:
>>>> This series adds remoteproc support for the i.MX94 family, including the
>>>> CM70, CM71, and CM33S cores, and introduces a new device‑tree property to
>>>> correctly derive the hardware reset vector for Cortex‑M processors whose
>>>> ELF entry point does not directly correspond to the actual reset address.
>>>>
>>>> Background:
>>>> Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
>>>> table. While ELF images embed the entry point (e_entry), this value is
>>>> not always aligned to the hardware reset address. On platforms such as
>>>> i.MX94 CM33S, masking is required to compute the correct reset vector
>>>> address before programming the SoC reset registers.
>>> What happens if the reset vector is at 0 and the e_entry point is at 0x800...?
>>>
>>> In this case masking will no longer work! Can we implement a generic approach?
>>>
>> I will wait to see an R-B from Daniel before looking at this set.
>>
>> Thanks,
>> Mathieu
>>  
>>
>Hi Mathieu, Peng,
>
>Patchseries mostly looks good to me. The only blocking issue here is how to correctly specify the hardware reset address.
>
>I see two options here:
>
>1) Create a special section in TCM that holds the PC/Stack initial value as concluded here [1]. But this
>
>doesn't work in all the cases 
>
>2) Add a per device data that holds the hardware reset mask that gets applied to entry address read from ELF.
>
>I'm fine going with option 2) and that's because this change is IMX rproc driver specific, it scales well and will be maintained by Peng.

Thanks, I will go with option 2.

Thanks
Peng

>
>thanks,
>
>Daniel.
>
>[1] https://lore.kernel.org/linux-remoteproc/38476dd0-07a6-310f-1fba-2b3021a5b007@kontron.de/
>