Re: [PATCH 1/4] dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask

[Peng Fan <peng.fan@oss.nxp.com>]

Hi Daniel,

On Fri, Mar 20, 2026 at 11:46:53AM +0200, Daniel Baluta wrote:
>On 3/12/26 14:36, Peng Fan (OSS) wrote:
>> 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
>
>
>What do you think about this idea:
>
>Use fsl,reset-vector-base instead of a mask. It could happen that for example
>
>a CM7 instance has explicit requirements to boot from TCM but the entry point is in DRAM.
>Then masking won't help.
>
>fsl,reset-vector-base is always fixed hardware integration dependent and you can always
>
>specify it in DT.
>

Thanks for sharing ideas. But this not work:
1. User start an elf which is built to run in TCM. the reset vector is in TCM.
2. User stop remote processor
3. User start an elf which is built to run in DDR. the reset vector is in DDR.

So a fixed fsl,reset-vector-base not work. We need a per elf reset vector base.

For the case you list about boot from TCM, entry is DRAM. this is i.MX8M DDR
elf demo. The hardware always fetches PC/STACK from 0, but elf entry is in
DDR. We always use 0 as boot address for i.MX8M, no matter what elf entry is.

For i.MX95/943, there is an register to configure M7 or M33S start address,
If the image is designed to run in DDR, user should set reset vector and elf
entry both in DDR. If the image is designed to run TCM, but space is not enough,
DDR is also used, the reset vector and elf entry should be both in TCM.

Per my talk with NXP SDK team, It is less that 16KB from reset vector to
elf entry address.

But in case people really want the case you list, we may use a flag
BIT0: 0 means base
BIT0: 1 means mask

fsl,reset-vector = <0x[x] | BIT(0)>;  --> mask
fsl,reset-vector = <0x[x] & ~BIT(0)>; --> base

Thanks
Peng
>