Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector

Daniel Baluta
2026-04-08T15:57:51Z

On 4/8/26 04:30, Peng Fan wrote:
>> Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
>> SM CPU/LMM reset vector
>>
> [...]
>>> Aligning the ELF entry point with the hardware reset base on
>> Cortex‑M
>>> systems is possible, but it comes with several risks.
>> I'm not asking to align the ELF entry point with the hardware reset base.
>> All I want is to have the correct start address embedded in the ELF file
>> to avoid having to use a mask.
> I see, per my understanding:
> FreeRTOS typically exposes __isr_vector, which corresponds to the hardware
> reset / vector table base.
> Zephyr (Cortex‑M) exposes _vector_table, which serves the same purpose.
> I am not certain about other RTOSes, but the pattern seems consistent:
> the vector table base is already available as a named ELF symbol.
>
> Given that, if the preferred approach is to parse the ELF and explicitly
> retrieve the hardware reset base, I can update the implementation accordingly.
> If you prefer to parse the elf file to get the hardware reset base,
> I could update to use them.
>
> Options1: Something as below:
> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c
> 2. Use below in imx_rproc.c
> ret = rproc_elf_find_symbol(rproc, fw, "__isr_vector", &vector_base);
> if (ret)
> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table", &vector_base);
>
> if (!ret)
> rproc->bootaddr = vector_base
> else
> dev_info(dev, "no __isr_vector or __vector_table\n")
>
> This makes the hardware reset base explicit, avoids masking e_entry.
>
> Option 2: User‑provided reset symbol via sysfs
> As an alternative, we could expose a sysfs attribute,
> e.g. reset_symbol, allowing users to specify the symbol name
> to be used as the reset base:
>
> echo __isr_vector > /sys/class/remoteproc/remoteprocX/reset_symbol
>
> The remoteproc core would then resolve that symbol from
> the ELF and set rproc->bootaddr accordingly.
> This provides maximum flexibility but does introduce a new user‑visible ABI,
> so I see it more as an opt‑in or fallback mechanism.
>
> Please let me know which approach you prefer, and I will update
> this series accordingly in v3..

I would go with option 1) as this and having something like this:

#define IMX_RPROC_DEFAULT_RST_VECTOR_NAME "..."

later we can expand that with a configurable name via sysfs.

This was along my initial proposal where you would determine

the reset vector address from the elf file.