> Subject: RE: [PATCH] remoteproc: imx_rproc: merge ITCM and DTCM > regions > > > Subject: Re: [PATCH] remoteproc: imx_rproc: merge ITCM and DTCM > > regions > > > > Hi Mathieu, > > > > On Fri, Jul 04, 2025 at 10:25:19AM -0600, Mathieu Poirier wrote: > > > Good morning, > > > > > > On Thu, Jul 03, 2025 at 10:08:31AM -0300, Hiago De Franco wrote: > > > > From: Hiago De Franco <hiago.fra...@toradex.com> > > > > > > > > Merge the contiguous ITCM and DTCM regions into a single region > > to > > > > prevent failures when loading ELF files with large sections: > > > > > > > > remoteproc remoteproc0: powering up imx-rproc remoteproc > > > > remoteproc0: Booting fw image rproc-imx-rproc-fw, size 151824 > > > > imx-rproc imx8mp-cm7: Translation failed: da = 0x1f48 len = > > 0x1fcb0 > > > > remoteproc remoteproc0: bad phdr da 0x1f48 mem 0x1fcb0 > > remoteproc > > > > remoteproc0: Failed to load program segments: -22 remoteproc > > > > remoteproc0: Boot failed: -22 > > > > > > > > This approach is the same as commit 8749919defb8 ("remoteproc: > > > > imx_rproc: Merge TCML/U"). > > > > > > > > Suggested-by: Ritesh Kumar <ritesh.ku...@toradex.com> > > > > Signed-off-by: Hiago De Franco <hiago.fra...@toradex.com> > > > > --- > > > > Hi, > > > > > > > > The ELF I tested had the following data section: > > > > > > > > Memory region Used Size Region Size %age Used > > > > m_interrupts: 680 B 1 KB 66.41% > > > > m_text: 6984 B 127 KB 5.37% > > > > m_data: 130224 B 128 KB 99.35% > > > > m_data2: 0 GB 16 MB 0.00% > > > > [100%] Built target hello_world_cm7.elf > > > > > > > > Which triggered the error. After this patch, remoteproc was able > > > > to boot and work fine. Thanks! > > > > --- > > > > drivers/remoteproc/imx_rproc.c | 6 ++---- > > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/remoteproc/imx_rproc.c > > > > b/drivers/remoteproc/imx_rproc.c index > > 74299af1d7f1..bbf089ef48ee > > > > 100644 > > > > --- a/drivers/remoteproc/imx_rproc.c > > > > +++ b/drivers/remoteproc/imx_rproc.c > > > > @@ -166,8 +166,8 @@ static const struct imx_rproc_att > > > > imx_rproc_att_imx8qxp[] = { > > > > > > > > static const struct imx_rproc_att imx_rproc_att_imx8mn[] = { > > > > /* dev addr , sys addr , size , flags */ > > > > - /* ITCM */ > > > > - { 0x00000000, 0x007E0000, 0x00020000, ATT_OWN | > > ATT_IOMEM }, > > > > + /* D/ITCM */ > > > > + { 0x00000000, 0x007E0000, 0x00040000, ATT_OWN | > > ATT_IOMEM }, > > > > /* OCRAM_S */ > > > > { 0x00180000, 0x00180000, 0x00009000, 0 }, > > > > /* OCRAM */ > > > > @@ -180,8 +180,6 @@ static const struct imx_rproc_att > > imx_rproc_att_imx8mn[] = { > > > > { 0x08000000, 0x08000000, 0x08000000, 0 }, > > > > /* DDR (Code) - alias */ > > > > { 0x10000000, 0x40000000, 0x0FFE0000, 0 }, > > > > - /* DTCM */ > > > > - { 0x20000000, 0x00800000, 0x00020000, ATT_OWN | > > ATT_IOMEM }, > > > > > > In commit 8749919defb8 "dev addr" and "sys addr" were both > > contiguous, > > > but in this patch "dev addr" is not. How will this work with new > > > kernel that use old FW images? Am I missing something? > > > > No, you are correct, I think the use case I tested was not good enough. > > > > If I understand correctly, this will break older firmware expecting > > .data at 0x20000000 because dev_addr is no longer mapped for > DTCM entry. > > > > The ITCM in M7 starts from 0, DTCM in M7 starts from 0x20000000. > The ITCM/DTCM is continuous from A53 perspective. > > You let linux to load continuous text/data, but if the dev addr start > from ITCM_START+128KB is not reserved from Reference manual.
Typo: ITCM_START + 128KB is reserved. > > How could M7 still work proper if M7 accessing [0x20000, x] dev_addr? > > You need update your linker script to separate text into different > sections. > > Regards, > Peng. > > > Do you think it is possible (or reccomend) another approach to fix > > this issue? In this case to keep using the TCM, > > > > instead of going to OCRAM > > or DDR. > > > > Thanks, > > Hiago. > > > > > > > > Thanks, > > > Mathieu > > > > > > > /* OCRAM_S - alias */ > > > > { 0x20180000, 0x00180000, 0x00008000, ATT_OWN }, > > > > /* OCRAM */ > > > > -- > > > > 2.39.5 > > > >