Hello Stefano, On 15.11.24 15:47, Stefano Manni wrote: > Hello Ahmad, > > patch [1] works fine when M7 firmware is compiled to run from ITCM. Thank you! Thanks for testing. > 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 Can you send me the ELF file, so I can look at the headers myself? Cheers, Ahmad > > 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 | > -- 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 |
