Hello Ahmad, patch [1] works fine when M7 firmware is compiled to run from ITCM. Thank you! But when I use exactly the same firmware but compiled to run from DDR (see [2]) I got: barebox@NXP i.MX8MPlus EVK board:/ firmwareload hello-ddr.elf remoteproc0: powering up remoteproc-cm7.of ERROR: remoteproc0: bad phdr da 0x80000000 mem 0x3de4 ERROR: remoteproc0: Failed to load program segments: -22 Note that I can run it both from linux and u-boot. [1] https://lore.barebox.org/barebox/20241115135242.1251691-1-a.fatoum@xxxxxxxxxxxxxx/ [2] https://docs.zephyrproject.org/latest/boards/nxp/imx8mp_evk/doc/index.html#programming-and-debugging-m7 Il giorno ven 15 nov 2024 alle ore 15:02 Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> ha scritto: > > Hello Stefano, > > On 15.11.24 14:43, Stefano Manni wrote: > > Dear all, > > > > I cannot run an ELF image on the M7 core on the imx8mp soc. > > The ELF comes from zephyr and it runs as expected when I load it from linux, > > but in barebox I encounter this error: > > > > barebox@NXP i.MX8MPlus EVK board:/ tftp zephyr.elf > > [################################################################] > > barebox@NXP i.MX8MPlus EVK board:/ firmwareload zephyr.elf > > remoteproc0: powering up remoteproc-cm7.of > > DABT (current EL) exception (ESR 0x96000061) at 0x00000000007e0004 > > https://esr.arm64.dev/#0x96000061 decodes this as > "Abort caused by writing to memory" (Alignment fault) with valid FAR. > > FAR is the addresss listed here (0x00000000007e0004), which is indeed > not divisible by 8. > > > [<ffd826f4>] (__arch_memcpy+0x48/0x13c) from [<ffd82a00>] (memcpy+0xc/0x14) > > The optimized memcpy used here expects misalignment not to trap. > > > As you can see the exception happens when rproc_elf_load_segments() tries to > > memcpy a segment where the M7 expects it. The ELF has been compiled to run > > from ITCM memory (0x007E0000-0x007FFFFF). > > > > Do you have any idea? Maybe may I have to put a reserved-memory for ITCM? > > I think I may have broken this when I changed barebox to map everything outside > main memory as uncached. > > I did this, because we 1) don't want to risk the main CPU speculating into I/O > memory and 2) don't want to have to use memory barriers for synchronization. > > The flipside is that drivers that access I/O memory must do this via > readl/writel and friends or via memcpy_io/memset_io. This was already required > before, but some drivers that didn't do this were lucky enough to fly under > the radar. At least for remoteproc, this seems no longer the case. > > I just Cc'd you on a patch to fix this for remoteproc. > Please let me know with a Tested-by if this resolves your issue. > > Cheers, > Ahmad > > > > > Thank you. > > > > Best, > > Stefano > > > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
