On Mon, Mar 30, 2026 at 10:22:35AM -0600, Mathieu Poirier wrote:
>On Fri, Mar 27, 2026 at 10:42:03AM +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
>> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>>
>
>But why? Why can't the ELF image be set to the right reset base?
Per zephyr general link script[1]:
ENTRY(CONFIG_KERNEL_ENTRY)
CONFIG_KERNEL_ENTRY(_start) is the first instruction that Cortex-M starts to
execute.
config KERNEL_ENTRY
string "Kernel entry symbol"
default "__start"
help
Code entry symbol, to be set at linking phase.
The hardware reset base is different: it is the address where the hardware
fetches the initial MSP and PC values from the vector table. Hardware uses
this base to initialize the stack pointer and program counter, and only then
does the Cortex‑M begin execution at the reset handler.
Aligning the ELF entry point with the hardware reset base on Cortex‑M systems
is possible, but it comes with several risks.
1, Semantic mismatch (ELF vs. hardware behavior)
2, Debuggers may attempt to set breakpoints or start execution at the entry
symbol
[1]
https://elixir.bootlin.com/zephyr/v4.4.0-rc1/source/include/zephyr/arch/arm/cortex_m/scripts/linker.ld#L103
Regards
Peng.
>
