Messages in this thread |  | | From | Peng Fan <> | | Subject | RE: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector | | Date | Wed, 8 Apr 2026 01:30:16 +0000 |
| |
> 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..
Thanks, Peng.
> > > 1, Semantic mismatch (ELF vs. hardware behavior) 2, Debuggers may > > attempt to set breakpoints or start execution at the entry symbol > >
|  |