On Mon, Mar 23, 2026 at 9:16 PM Rob Herring <[email protected]> wrote: > > On Thu, Mar 12, 2026 at 08:36:56PM +0800, Peng Fan (OSS) wrote: > > From: Peng Fan <[email protected]> > > > > 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.
