firmwareload fails for cortex-m7 on imx8mp

firmwareload fails for cortex-m7 on imx8mp

[Stefano Manni]

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
elr: 00000000ffd826f4 lr : 00000000ffd829cc
x0 : 00000000007e0000 x1 : 00000000bff22a40
x2 : 0000000000003f88 x3 : 00002add00000a91
x4 : 000000000000000c x5 : 00000000ffff7478
x6 : 00000000007e0004 x7 : 727065746f6d6572
x8 : 585858203a30636f x9 : 2074736564205858
x10: 3030303030303030 x11: 3030303065373030
x12: 3030302063727320 x13: 6666623030303030
x14: 6973203433613232 x15: 0000000000000001
x16: 00000000ffff7458 x17: 0000000000000001
x18: 00000000ffff79e0 x19: 00000000bff22994
x20: 0000000000003f94 x21: 00000000007e0000
x22: 00000000bff22940 x23: 00000000bfdd0b80
x24: 00000000bfdd0b28 x25: 00000000ffff7a80
x26: 0000000000000001 x27: 00000000ffd8edc0
x28: 0000000000003f94 x29: 00000000ffff79c0

Call trace:
[<ffd826f4>] (__arch_memcpy+0x48/0x13c) from [<ffd82a00>] (memcpy+0xc/0x14)
[<ffd82a00>] (memcpy+0xc/0x14) from [<ffd5150c>]
(rproc_elf_load_segments+0x148/0x16c)
[<ffd5150c>] (rproc_elf_load_segments+0x148/0x16c) from [<ffd5115c>]
(rproc_firmware_finish+0x84/0x10c)
[<ffd5115c>] (rproc_firmware_finish+0x84/0x10c) from [<ffd141b0>]
(firmware_close+0x28/0x4c)
[<ffd141b0>] (firmware_close+0x28/0x4c) from [<ffd73c44>] (cdev_close+0x3c/0x44)
[<ffd73c44>] (cdev_close+0x3c/0x44) from [<ffd751cc>] (devfs_close+0x10/0x18)
[<ffd751cc>] (devfs_close+0x10/0x18) from [<ffd76be4>] (close+0x110/0x118)
[<ffd76be4>] (close+0x110/0x118) from [<ffd1466c>]
(firmwaremgr_load_file+0x140/0x198)
[<ffd1466c>] (firmwaremgr_load_file+0x140/0x198) from [<ffd5eac4>]
(do_firmwareload+0xc4/0xd0)
[<ffd5eac4>] (do_firmwareload+0xc4/0xd0) from [<ffd078e0>]
(execute_command+0x44/0x8c)
[<ffd078e0>] (execute_command+0x44/0x8c) from [<ffd0422c>]
(execute_binfmt+0x68/0xa0)
[<ffd0422c>] (execute_binfmt+0x68/0xa0) from [<ffd11200>]
(run_list_real+0x8cc/0x978)
[<ffd11200>] (run_list_real+0x8cc/0x978) from [<ffd10788>]
(parse_stream_outer+0x140/0x1ec)
[<ffd10788>] (parse_stream_outer+0x140/0x1ec) from [<ffd115e0>]
(run_shell+0x64/0xac)
[<ffd115e0>] (run_shell+0x64/0xac) from [<ffd01a28>] (run_init+0x114/0x258)
[<ffd01a28>] (run_init+0x114/0x258) from [<ffd01bbc>] (start_barebox+0x50/0x8c)
[<ffd01bbc>] (start_barebox+0x50/0x8c) from [<ffd81748>] (decode_cache+0x0/0x5c)
[<ffd81748>] (decode_cache+0x0/0x5c) from [<ffd0000c>]
(__bare_init_start+0x0/0x14)
[<ffd0000c>] (__bare_init_start+0x0/0x14) from [<402046c8>] (0x402046c8)
[<402046c8>] (0x402046c8) from [<40203f48>] (0x40203f48)
panic: unhandled exception


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?

Thank you.

Best,
Stefano

Re: firmwareload fails for cortex-m7 on imx8mp

[Ahmad Fatoum]

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 |

Re: firmwareload fails for cortex-m7 on imx8mp

[Stefano Manni]

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@pengutronix.de/
[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@pengutronix.de> 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 |

Re: firmwareload fails for cortex-m7 on imx8mp

[Ahmad Fatoum]

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@pengutronix.de/
> [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@pengutronix.de> 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 |

Re: firmwareload fails for cortex-m7 on imx8mp

[Stefano Manni]

Hello Ahmad,

I put it on here: https://we.tl/t-HrzdMMJXpU
because I didn't know if I can attach files in the mailing list.

Best,
Stefano


Il giorno ven 15 nov 2024 alle ore 15:49 Ahmad Fatoum

<a.fatoum@pengutronix.de> ha scritto:
>
> 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@pengutronix.de/
> > [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@pengutronix.de> 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 |

Re: firmwareload fails for cortex-m7 on imx8mp

[Ahmad Fatoum]

Hi Stefano,

On 15.11.24 16:01, Stefano Manni wrote:
> Il giorno ven 15 nov 2024 alle ore 15:49 Ahmad Fatoum
> 
> <a.fatoum@pengutronix.de> ha scritto:
>>
>> 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.

I am surprised it works for you in Linux. To get it working with barebox:

 1) run iomem and note where your malloc area begins. Set CONFIG_MALLOC_SIZE,
    so it starts after 0x90000000 

 2) Add the following to your DT:

&{/reserved-memory} {
	rproc_reserved: rproc@80000000 {
        	reg = <0 0x80000000 0 0x10000000>;
	};
};

&remoteproc_cm7 {
	memory-region = <&rproc_reserved>;
};

Do you not have an equivalent memory-region definition in your kernel DT?

 3) I found some issues that I just Cc'd you on the fixes for. They may not be
    necessary for the simple hello-ddr.elf example though.

Cheers,
Ahmad

>>>
>>> [1] https://lore.barebox.org/barebox/20241115135242.1251691-1-a.fatoum@pengutronix.de/
>>> [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@pengutronix.de> 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 |
> 


-- 
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 |

Re: firmwareload fails for cortex-m7 on imx8mp

[Stefano Manni]

Il giorno mar 19 nov 2024 alle ore 10:03 Ahmad Fatoum
<a.fatoum@pengutronix.de> ha scritto:
>
> I am surprised it works for you in Linux. To get it working with barebox:
>
>  1) run iomem and note where your malloc area begins. Set CONFIG_MALLOC_SIZE,
>     so it starts after 0x90000000
>
>  2) Add the following to your DT:
>
> &{/reserved-memory} {
>         rproc_reserved: rproc@80000000 {
>                 reg = <0 0x80000000 0 0x10000000>;
>         };
> };
>
> &remoteproc_cm7 {
>         memory-region = <&rproc_reserved>;
> };
>
> Do you not have an equivalent memory-region definition in your kernel DT?

Yes, I have. Adding rproc_reserved to barebox as in kernel DT it fixes
the issue.

>
>  3) I found some issues that I just Cc'd you on the fixes for. They may not be
>     necessary for the simple hello-ddr.elf example though.

Do you need that I test them?

Thank you.
Best,
Stefano

Re: firmwareload fails for cortex-m7 on imx8mp

[Ahmad Fatoum]

Hello Stefano,

On 19.11.24 11:40, Stefano Manni wrote:
> Il giorno mar 19 nov 2024 alle ore 10:03 Ahmad Fatoum
> <a.fatoum@pengutronix.de> ha scritto:
>>
>> I am surprised it works for you in Linux. To get it working with barebox:
>>
>>  1) run iomem and note where your malloc area begins. Set CONFIG_MALLOC_SIZE,
>>     so it starts after 0x90000000
>>
>>  2) Add the following to your DT:
>>
>> &{/reserved-memory} {
>>         rproc_reserved: rproc@80000000 {
>>                 reg = <0 0x80000000 0 0x10000000>;
>>         };
>> };
>>
>> &remoteproc_cm7 {
>>         memory-region = <&rproc_reserved>;
>> };
>>
>> Do you not have an equivalent memory-region definition in your kernel DT?
> 
> Yes, I have. Adding rproc_reserved to barebox as in kernel DT it fixes
> the issue.

Great. :)

>>
>>  3) I found some issues that I just Cc'd you on the fixes for. They may not be
>>     necessary for the simple hello-ddr.elf example though.
> 
> Do you need that I test them?

I have already tested that they don't break anything using the ELF
file you provided, so this is just a heads up if you run into
further problems with different firmware ELF files.

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 |