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

[Mathieu Poirier]

On Fri, 10 Apr 2026 at 21:01, Peng Fan <peng.fan@xxxxxxx> wrote:
>
> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
> > SM CPU/LMM reset vector
> >
> > On Thu, Apr 09, 2026 at 08:30:54AM +0800, Peng Fan wrote:
> > > On Wed, Apr 08, 2026 at 09:46:32AM -0600, Mathieu Poirier wrote:
> > > >On Wed, Apr 08, 2026 at 01:30:16AM +0000, 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")
> > > >
> > > >No
> > >
> > > If your concern is about rproc->bootaddr, I could introduce
> > > imx_rproc->vector_base for i.MX.  Please help detail a bit.
> > >
> > > >
> > > >>
> > > >> 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
> > > >>
> > > >
> > > >Definitely not.
> > > >
> > > >The definition of e_entry in the specification is clear, i.e "the
> > > >address of the entry point from where the process starts executing".
> > > >If masking is required because the tool that puts the image together
> > > >gets the wrong address, then it should be fixed.
> > >
> > > The hardware reset base is the address from which the hardware
> > fetches
> > > the initial stack pointer and program counter values and loads them
> > > into the SP and PC registers.  In contrast, bootaddr (i.e. e_entry)
> > > represents the address at which the CPU starts executing code (the
> > PC
> > > value after reset). As you pointed out earlier, this distinction is clear.
> > >
> > > In our case, we need to obtain the hardware reset base and pass that
> > > value to the system firmware. However, e_entry should not be set to
> > > the hardware reset base. Doing so would introduce the issues I
> > > described in [1]. This means we should not modify the Zephyr or
> > > FreeRTOS build outputs to make e_entry equal to the hardware reset
> > base.
> >
> >
> > As I said earlier, I am _not_ suggesting to make e_entry equal to the
> > hardware reset base.
>
> Let me try to restate my understanding more precisely and please
> correct me if I am still missing the point.
>
> From your comment:
> "
> If masking is required because the tool that puts the image together gets the
> wrong address, then it should be fixed.
> "
>
> I understand this as saying that masking e_entry is not acceptable, because
> e_entry already has a clear and correct meaning: it is the execution entry
> address, and the kernel should not reinterpret or “fix up” that value.
> At the same time, we still need to provide the hardware reset vector base
> to the system firmware, and that value is distinct from e_entry.
>
> On i.MX94/5 platforms the reset base is software‑programmable, but that
> information is not represented by e_entry, nor is there currently a
> separate place in the remoteproc framework to convey a reset‑vector
> base independent of the execution entry point.
>
> Given these constraints, I see limited options on the kernel side.
>
> One conservative approach would be to rely on a fixed, platform‑defined
> reset base for the affected SoCs. And update RTOS linking script to put
> the vector to the location of fixed hardware reset base.
>

The problem with the current patchset is the overloading of
rproc->bootaddr in function rproc_fw_boot() [1].  After that point
rproc->bootaddr holds the hardware reset address communicated to the
remote processor's firmware and not the beginning of execution as
intended by the definition of e_entry.  This is very confusing to
anyone reviewing the code without a clear understanding of the
context.

To fix this I suggest masking rproc->bootaddr in
imx_rproc_sm_cpu_start() and imx_rproc_sm_lmm_start() with a copious
amount of in-lined documentation.

[1]. https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/remoteproc/remoteproc_core.c#L1401

> Thanks,
> Peng
>
> >
> > We are going in circles here.
> >
> > >
> > > Given these constraints, the feasible solutions I can see are either:
> > > - option 1 (explicitly retrieving the hardware reset base), or
> > > - continuing to use masking.
> > >
> > > Please suggest.
> > >
> > > [1]
> > >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > lore
> > > .kernel.org%2Fall%2Facs2PAZq2k3zjmDW%40shlinux89%2F&data=0
> > 5%7C02%7Cpen
> > >
> > g.fan%40nxp.com%7C8a5ce35d492b4adb2d3b08de97192cbb%7C686
> > ea1d3bc2b4c6fa
> > >
> > 92cd99c5c301635%7C0%7C0%7C639114331565834960%7CUnknow
> > n%7CTWFpbGZsb3d8e
> > >
> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> > kFOIjoiTWF
> > >
> > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pnkirz3BMEuLsJU9
> > MHQNon84HIyMX
> > > 08x1wCK04dS7VU%3D&reserved=0
> > >
> > > Thanks,
> > > Peng
> > >
> > > >
> > > >> 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
> > > >> > >