On Fri, 10 Apr 2026 at 21:01, Peng Fan <[email protected]> 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 > > > >> > >
