On Mon, Mar 23, 2026 at 9:16 PM Rob Herring [off-list ref] wrote:

On Thu, Mar 12, 2026 at 08:36:56PM +0800, Peng Fan (OSS) wrote:

quoted

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.