.../bindings/remoteproc/fsl,imx-rproc.yaml | 9 +++ drivers/remoteproc/imx_rproc.c | 85 +++++++++++++++++++++- 2 files changed, 91 insertions(+), 3 deletions(-)
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>
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,
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, > >
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/
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/ >
© 2016 - 2026 Red Hat, Inc.