On 3/27/26 04:42, 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 > hardware reset base: 0x0ffc0000 (default reset value, sw programmable) > > 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 > > 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. To derive the proper reset vector, this > patch introduces imx_rproc_get_boot_addr(), which masks the ELF entry > point using the SoC‑specific 'reset_vector_mask'. The resulting reset > vector address is then passed to the SM CPU/LMM reset vector API calls. > > Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Daniel Baluta <[email protected]>
