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

Peng Fan
2026-04-08T01:30:21Z

> 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
> >