On Wed, Apr 15, 2026 at 10:49 AM Peng Fan (OSS) <[email protected]> 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 > hardware reset base: 0x0ffc0000 (default reset value, sw programmable) > > Current driver always programs the reset vector as 0. But i.MX94 CM33S's > default reset base is 0x0ffc0000, 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. Fix the issue by deriving the hardware reset > vector locally using a SoC-specific mask: > > reset_vector = rproc->bootaddr & reset_vector_mask > > The ELF entry point semantics remain unchanged. The masking is applied only > at the point where the SM reset vector is programmed. > > Add reset_vector_mask = GENMASK_U32(31, 16) to the i.MX95 M7 configuration > so the hardware reset vector is derived correctly. Without this mask, the > SM reset vector would be programmed with an unaligned ELF entry point and > the M7 core would fail to boot. > > Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Daniel Baluta <[email protected]>
