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
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
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.
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.
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 >
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.
© 2016 - 2026 Red Hat, Inc.