On Wed, Mar 25, 2026 at 10:41:29AM +0200, Daniel Baluta wrote: >On 3/23/26 16:32, Mathieu Poirier wrote: >> On Fri, Mar 20, 2026 at 11:19:06AM +0200, Daniel Baluta wrote: >>> On 3/12/26 14:36, Peng Fan (OSS) wrote: >>>> This series adds remoteproc support for the i.MX94 family, including the >>>> CM70, CM71, and CM33S cores, and introduces a new device‑tree property to >>>> correctly derive the hardware reset vector for Cortex‑M processors whose >>>> ELF entry point does not directly correspond to the actual reset address. >>>> >>>> Background: >>>> Cortex‑M processors fetch their initial SP and PC from a fixed reset vector >>>> table. While ELF images embed the entry point (e_entry), this value is >>>> not always aligned to the hardware reset address. On platforms such as >>>> i.MX94 CM33S, masking is required to compute the correct reset vector >>>> address before programming the SoC reset registers. >>> What happens if the reset vector is at 0 and the e_entry point is at >>> 0x800...? >>> >>> In this case masking will no longer work! Can we implement a generic >>> approach? >>> >> I will wait to see an R-B from Daniel before looking at this set. >> >> Thanks, >> Mathieu >> >> >Hi Mathieu, Peng, > >Patchseries mostly looks good to me. The only blocking issue here is how to >correctly specify the hardware reset address. > >I see two options here: > >1) Create a special section in TCM that holds the PC/Stack initial value as >concluded here [1]. But this > >doesn't work in all the cases > >2) Add a per device data that holds the hardware reset mask that gets applied >to entry address read from ELF. > >I'm fine going with option 2) and that's because this change is IMX rproc >driver specific, it scales well and will be maintained by Peng.
Thanks, I will go with option 2. Thanks Peng > >thanks, > >Daniel. > >[1] >https://lore.kernel.org/linux-remoteproc/[email protected]/ >
