| Message ID | 20200724080813.24884-1-peng.fan@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | remoteproc: imx_rproc: support iMX8M and early boot | expand |
Hi, On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > This patchset is to support i.MX8MQ/M coproc booted before linux. > Since i.MX8MQ/M was not supported, several patches are needed > to first support the platform, then support early boot case. > > I intended to included i.MX8QM/QXP, but that would introduce a large > patchset, so not included. But the clk/syscon optional patch for > i.MX8QM/QXP was still kept here to avoid rebase error. Thank you for your work. Can you please provide more information about big picture of this work. If I see it correctly, we have here support for i.MX8MM, which seems to be able to fully control Cortex M4 (enable CPU core, etc...). And other case, where remoteproc is running on application processor and can't or should not touch M4 (i.MX7ULP, i.MX8QM/QXP..). Since M4 provides some functionality, you are trying to reuse remoteproc framework to get resource table present in ELF header and to dynamically load things. For some reasons this header provides more information then needed, so you are changing the ELF parser in the kernel to workaround it. Correct? > Peng Fan (10): > dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M > remoteproc: imx_rproc: correct err message > remoteproc: imx: use devm_ioremap > remoteproc: imx_rproc: make syscon optional > remoteproc: imx_rproc: make clk optional > remoteproc: imx_rproc: add load hook > remoteproc: imx_rproc: add i.MX specific parse fw hook > remoteproc: imx_rproc: support i.MX8MQ/M > remoteproc: imx_proc: enable virtio/mailbox > remoteproc: imx_rproc: support coproc booting before Linux > > .../devicetree/bindings/remoteproc/imx-rproc.txt | 3 + > drivers/remoteproc/imx_rproc.c | 409 ++++++++++++++++++++- > 2 files changed, 401 insertions(+), 11 deletions(-) > > -- > 2.16.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Hi Oleksij, > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > boot > > Hi, > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > Since i.MX8MQ/M was not supported, several patches are needed to first > > support the platform, then support early boot case. > > > > I intended to included i.MX8QM/QXP, but that would introduce a large > > patchset, so not included. But the clk/syscon optional patch for > > i.MX8QM/QXP was still kept here to avoid rebase error. > > Thank you for your work. > > Can you please provide more information about big picture of this work. > > If I see it correctly, we have here support for i.MX8MM, which seems to be > able to fully control Cortex M4 (enable CPU core, etc...). Yes. > > And other case, where remoteproc is running on application processor and > can't or should not touch M4 (i.MX7ULP, i.MX8QM/QXP..). Since M4 provides > some functionality, you are trying to reuse remoteproc framework to get > resource table present in ELF header and to dynamically load things. For some > reasons this header provides more information then needed, so you are > changing the ELF parser in the kernel to workaround it. Not exactly. For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked by Linux remoteproc. For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we will also add M4 kicked by Linux remoteproc. For i.MX7ULP, I would only support M4 dual boot case, M4 control everything. The reason the change the elf parser is that when M4 elf is loaded by Linux remoteproc, It use memset to clear area. However we use ioremap, memset on ARM64 will report crash to device nGnRE memory. And we could not use ioremap_wc to TCM area, since it could have data correctly written into TCM. Maintainer not wanna to drop memset in common code, and TI guys suggest add i.MX specific elf stuff. So I add elf handler in i.MX code. Thanks, Peng. > > Correct? > > > Peng Fan (10): > > dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M > > remoteproc: imx_rproc: correct err message > > remoteproc: imx: use devm_ioremap > > remoteproc: imx_rproc: make syscon optional > > remoteproc: imx_rproc: make clk optional > > remoteproc: imx_rproc: add load hook > > remoteproc: imx_rproc: add i.MX specific parse fw hook > > remoteproc: imx_rproc: support i.MX8MQ/M > > remoteproc: imx_proc: enable virtio/mailbox > > remoteproc: imx_rproc: support coproc booting before Linux > > > > .../devicetree/bindings/remoteproc/imx-rproc.txt | 3 + > > drivers/remoteproc/imx_rproc.c | 409 > ++++++++++++++++++++- > > 2 files changed, 401 insertions(+), 11 deletions(-) > > > > -- > > 2.16.4 > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > -- > 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 |
On Mon, Jul 27, 2020 at 06:44:32AM +0000, Peng Fan wrote: > Hi Oleksij, > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > > boot > > > > Hi, > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > > Since i.MX8MQ/M was not supported, several patches are needed to first > > > support the platform, then support early boot case. > > > > > > I intended to included i.MX8QM/QXP, but that would introduce a large > > > patchset, so not included. But the clk/syscon optional patch for > > > i.MX8QM/QXP was still kept here to avoid rebase error. > > > > Thank you for your work. > > > > Can you please provide more information about big picture of this work. > > > > If I see it correctly, we have here support for i.MX8MM, which seems to be > > able to fully control Cortex M4 (enable CPU core, etc...). > > Yes. In this case, I would recommend to mainline the i.MX8MM part first/separately. > > > > And other case, where remoteproc is running on application processor and > > can't or should not touch M4 (i.MX7ULP, i.MX8QM/QXP..). Since M4 provides > > some functionality, you are trying to reuse remoteproc framework to get > > resource table present in ELF header and to dynamically load things. For some > > reasons this header provides more information then needed, so you are > > changing the ELF parser in the kernel to workaround it. > > Not exactly. > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked by Linux remoteproc. > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we will also add M4 kicked > by Linux remoteproc. > For i.MX7ULP, I would only support M4 dual boot case, M4 control everything. From current state of discussion, i'm not sure what role plays remoteproc in the scenario where M4 is started before linux. Especially if we are not using resource table. > The reason the change the elf parser is that when M4 elf is loaded by Linux remoteproc, > It use memset to clear area. The use of memset, depends on ELF format. Fix/change the linker script on your firmware and memset will be never called. > However we use ioremap, memset on ARM64 will report > crash to device nGnRE memory. And we could not use ioremap_wc to TCM area, since > it could have data correctly written into TCM. I have strong feeling, that we are talking about badly or not properly formatted ELF binary. I would prefer to double check it, before we will apply fixes on wrong place. > Maintainer not wanna to drop memset in common code, and TI guys suggest > add i.MX specific elf stuff. So I add elf handler in i.MX code. I think, removing memset may damage current users of imx_rproc driver. Since, like I said: the use of memset depends on ELF format. > Thanks, > Peng. > > > > > Correct? > > > > > Peng Fan (10): > > > dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M > > > remoteproc: imx_rproc: correct err message > > > remoteproc: imx: use devm_ioremap > > > remoteproc: imx_rproc: make syscon optional > > > remoteproc: imx_rproc: make clk optional > > > remoteproc: imx_rproc: add load hook > > > remoteproc: imx_rproc: add i.MX specific parse fw hook > > > remoteproc: imx_rproc: support i.MX8MQ/M > > > remoteproc: imx_proc: enable virtio/mailbox > > > remoteproc: imx_rproc: support coproc booting before Linux > > > > > > .../devicetree/bindings/remoteproc/imx-rproc.txt | 3 + > > > drivers/remoteproc/imx_rproc.c | 409 > > ++++++++++++++++++++- > > > 2 files changed, 401 insertions(+), 11 deletions(-) > > > > > > -- > > > 2.16.4 > > > > > > > > > _______________________________________________ > > > linux-arm-kernel mailing list > > > linux-arm-kernel@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > > > > -- > > 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 |
> Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > boot > > On Mon, Jul 27, 2020 at 06:44:32AM +0000, Peng Fan wrote: > > Hi Oleksij, > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and > > > early boot > > > > > > Hi, > > > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > > > Since i.MX8MQ/M was not supported, several patches are needed to > > > > first support the platform, then support early boot case. > > > > > > > > I intended to included i.MX8QM/QXP, but that would introduce a > > > > large patchset, so not included. But the clk/syscon optional patch > > > > for i.MX8QM/QXP was still kept here to avoid rebase error. > > > > > > Thank you for your work. > > > > > > Can you please provide more information about big picture of this work. > > > > > > If I see it correctly, we have here support for i.MX8MM, which seems > > > to be able to fully control Cortex M4 (enable CPU core, etc...). > > > > Yes. > > In this case, I would recommend to mainline the i.MX8MM part > first/separately. Only the last patch is to support earlyboot, all others is imx8mm part. > > > > > > > And other case, where remoteproc is running on application processor > > > and can't or should not touch M4 (i.MX7ULP, i.MX8QM/QXP..). Since M4 > > > provides some functionality, you are trying to reuse remoteproc > > > framework to get resource table present in ELF header and to > > > dynamically load things. For some reasons this header provides more > > > information then needed, so you are changing the ELF parser in the kernel > to workaround it. > > > > Not exactly. > > > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked by > Linux remoteproc. > > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we will > > also add M4 kicked by Linux remoteproc. > > For i.MX7ULP, I would only support M4 dual boot case, M4 control > everything. > > From current state of discussion, i'm not sure what role plays remoteproc in > the scenario where M4 is started before linux. Especially if we are not using > resource table. We are using resource table from an address, not in elf file. This is the new feature in Linux-next to support coproc booted early. > > > The reason the change the elf parser is that when M4 elf is loaded by > > Linux remoteproc, It use memset to clear area. > > The use of memset, depends on ELF format. Fix/change the linker script on > your firmware and memset will be never called. > > > However we use ioremap, memset on ARM64 will report crash to device > > nGnRE memory. And we could not use ioremap_wc to TCM area, since it > > could have data correctly written into TCM. > > I have strong feeling, that we are talking about badly or not properly > formatted ELF binary. I would prefer to double check it, before we will apply > fixes on wrong place. > > > Maintainer not wanna to drop memset in common code, and TI guys > > suggest add i.MX specific elf stuff. So I add elf handler in i.MX code. > > I think, removing memset may damage current users of imx_rproc driver. > Since, like I said: the use of memset depends on ELF format. In my elf file, the last PT_LOAD contains data/bss/heap/stack. I'll check with our MCU guys, we only need the specific data loaded. Elf file type is EXEC (Executable file) Entry point 0x1ffe0355 There are 3 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0x1ffe0000 0x1ffe0000 0x00240 0x00240 R 0x10000 LOAD 0x010240 0x1ffe0240 0x1ffe0240 0x03e90 0x03e90 RWE 0x10000 LOAD 0x020000 0x20000000 0x1ffe40d0 0x00068 0x0ad00 RW 0x10000 Section to Segment mapping: Segment Sections... 00 .interrupts 01 .resource_table .text .ARM .init_array .fini_array 02 .data .bss .heap .stack Thanks, Peng. > > > Thanks, > > Peng. > > > > > > > > Correct? > > > > > > > Peng Fan (10): > > > > dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M > > > > remoteproc: imx_rproc: correct err message > > > > remoteproc: imx: use devm_ioremap > > > > remoteproc: imx_rproc: make syscon optional > > > > remoteproc: imx_rproc: make clk optional > > > > remoteproc: imx_rproc: add load hook > > > > remoteproc: imx_rproc: add i.MX specific parse fw hook > > > > remoteproc: imx_rproc: support i.MX8MQ/M > > > > remoteproc: imx_proc: enable virtio/mailbox > > > > remoteproc: imx_rproc: support coproc booting before Linux > > > > > > > > .../devicetree/bindings/remoteproc/imx-rproc.txt | 3 + > > > > drivers/remoteproc/imx_rproc.c | 409 > > > ++++++++++++++++++++- > > > > 2 files changed, 401 insertions(+), 11 deletions(-) > > > > > > > > -- > > > > 2.16.4 > > > > > > > > > > > > _______________________________________________ > > > > linux-arm-kernel mailing list > > > > linux-arm-kernel@lists.infradead.org > > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > > > > > > > -- > > > 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 |
On Mon, Jul 27, 2020 at 09:18:31AM +0000, Peng Fan wrote: > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > > boot > > > > On Mon, Jul 27, 2020 at 06:44:32AM +0000, Peng Fan wrote: > > > Hi Oleksij, > > > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and > > > > early boot > > > > > > > > Hi, > > > > > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > > > > Since i.MX8MQ/M was not supported, several patches are needed to > > > > > first support the platform, then support early boot case. > > > > > > > > > > I intended to included i.MX8QM/QXP, but that would introduce a > > > > > large patchset, so not included. But the clk/syscon optional patch > > > > > for i.MX8QM/QXP was still kept here to avoid rebase error. > > > > > > > > Thank you for your work. > > > > > > > > Can you please provide more information about big picture of this work. > > > > > > > > If I see it correctly, we have here support for i.MX8MM, which seems > > > > to be able to fully control Cortex M4 (enable CPU core, etc...). > > > > > > Yes. > > > > In this case, I would recommend to mainline the i.MX8MM part > > first/separately. > > Only the last patch is to support earlyboot, all others is imx8mm part. ok > > > > > > > > > > And other case, where remoteproc is running on application processor > > > > and can't or should not touch M4 (i.MX7ULP, i.MX8QM/QXP..). Since M4 > > > > provides some functionality, you are trying to reuse remoteproc > > > > framework to get resource table present in ELF header and to > > > > dynamically load things. For some reasons this header provides more > > > > information then needed, so you are changing the ELF parser in the kernel > > to workaround it. > > > > > > Not exactly. > > > > > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked by > > Linux remoteproc. > > > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we will > > > also add M4 kicked by Linux remoteproc. > > > For i.MX7ULP, I would only support M4 dual boot case, M4 control > > everything. > > > > From current state of discussion, i'm not sure what role plays remoteproc in > > the scenario where M4 is started before linux. Especially if we are not using > > resource table. > > We are using resource table from an address, not in elf file. > This is the new feature in Linux-next to support coproc booted early. > > > > > > The reason the change the elf parser is that when M4 elf is loaded by > > > Linux remoteproc, It use memset to clear area. > > > > The use of memset, depends on ELF format. Fix/change the linker script on > > your firmware and memset will be never called. > > > > > However we use ioremap, memset on ARM64 will report crash to device > > > nGnRE memory. And we could not use ioremap_wc to TCM area, since it > > > could have data correctly written into TCM. > > > > I have strong feeling, that we are talking about badly or not properly > > formatted ELF binary. I would prefer to double check it, before we will apply > > fixes on wrong place. > > > > > Maintainer not wanna to drop memset in common code, and TI guys > > > suggest add i.MX specific elf stuff. So I add elf handler in i.MX code. > > > > I think, removing memset may damage current users of imx_rproc driver. > > Since, like I said: the use of memset depends on ELF format. > > In my elf file, the last PT_LOAD contains data/bss/heap/stack. I'll check > with our MCU guys, we only need the specific data loaded. > > Elf file type is EXEC (Executable file) > Entry point 0x1ffe0355 > There are 3 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x010000 0x1ffe0000 0x1ffe0000 0x00240 0x00240 R 0x10000 > LOAD 0x010240 0x1ffe0240 0x1ffe0240 0x03e90 0x03e90 RWE 0x10000 > LOAD 0x020000 0x20000000 0x1ffe40d0 0x00068 0x0ad00 RW 0x10000 > > Section to Segment mapping: > Segment Sections... > 00 .interrupts > 01 .resource_table .text .ARM .init_array .fini_array > 02 .data .bss .heap .stack Here is an example of formatting ELF for remoteproc: https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/local_src/remoteproc-elf/linker.ld https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/local_src/remoteproc-elf/imx7m4.S In this example I pack linux in to remoteproc elf image and start linux on imx7d-m4 part. Will be interesting if you can do the same on imx8* SoCs ;) Regards, Oleksij
> Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > boot > > On Mon, Jul 27, 2020 at 09:18:31AM +0000, Peng Fan wrote: > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and > > > early boot > > > > > > On Mon, Jul 27, 2020 at 06:44:32AM +0000, Peng Fan wrote: > > > > Hi Oleksij, > > > > > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M > > > > > and early boot > > > > > > > > > > Hi, > > > > > > > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > > > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > > > > > Since i.MX8MQ/M was not supported, several patches are needed > > > > > > to first support the platform, then support early boot case. > > > > > > > > > > > > I intended to included i.MX8QM/QXP, but that would introduce a > > > > > > large patchset, so not included. But the clk/syscon optional > > > > > > patch for i.MX8QM/QXP was still kept here to avoid rebase error. > > > > > > > > > > Thank you for your work. > > > > > > > > > > Can you please provide more information about big picture of this > work. > > > > > > > > > > If I see it correctly, we have here support for i.MX8MM, which > > > > > seems to be able to fully control Cortex M4 (enable CPU core, etc...). > > > > > > > > Yes. > > > > > > In this case, I would recommend to mainline the i.MX8MM part > > > first/separately. > > > > Only the last patch is to support earlyboot, all others is imx8mm part. > > ok > > > > > > > > > > > > > > And other case, where remoteproc is running on application > > > > > processor and can't or should not touch M4 (i.MX7ULP, > > > > > i.MX8QM/QXP..). Since M4 provides some functionality, you are > > > > > trying to reuse remoteproc framework to get resource table > > > > > present in ELF header and to dynamically load things. For some > > > > > reasons this header provides more information then needed, so > > > > > you are changing the ELF parser in the kernel > > > to workaround it. > > > > > > > > Not exactly. > > > > > > > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked > > > > by > > > Linux remoteproc. > > > > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we > > > > will also add M4 kicked by Linux remoteproc. > > > > For i.MX7ULP, I would only support M4 dual boot case, M4 control > > > everything. > > > > > > From current state of discussion, i'm not sure what role plays > > > remoteproc in the scenario where M4 is started before linux. > > > Especially if we are not using resource table. > > > > We are using resource table from an address, not in elf file. > > This is the new feature in Linux-next to support coproc booted early. > > > > > > > > > The reason the change the elf parser is that when M4 elf is loaded > > > > by Linux remoteproc, It use memset to clear area. > > > > > > The use of memset, depends on ELF format. Fix/change the linker > > > script on your firmware and memset will be never called. > > > > > > > However we use ioremap, memset on ARM64 will report crash to > > > > device nGnRE memory. And we could not use ioremap_wc to TCM area, > > > > since it could have data correctly written into TCM. > > > > > > I have strong feeling, that we are talking about badly or not > > > properly formatted ELF binary. I would prefer to double check it, > > > before we will apply fixes on wrong place. > > > > > > > Maintainer not wanna to drop memset in common code, and TI guys > > > > suggest add i.MX specific elf stuff. So I add elf handler in i.MX code. > > > > > > I think, removing memset may damage current users of imx_rproc driver. > > > Since, like I said: the use of memset depends on ELF format. > > > > In my elf file, the last PT_LOAD contains data/bss/heap/stack. I'll > > check with our MCU guys, we only need the specific data loaded. > > > > Elf file type is EXEC (Executable file) Entry point 0x1ffe0355 There > > are 3 program headers, starting at offset 52 > > > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz > Flg Align > > LOAD 0x010000 0x1ffe0000 0x1ffe0000 0x00240 0x00240 > R 0x10000 > > LOAD 0x010240 0x1ffe0240 0x1ffe0240 0x03e90 0x03e90 > RWE 0x10000 > > LOAD 0x020000 0x20000000 0x1ffe40d0 0x00068 0x0ad00 > RW 0x10000 > > > > Section to Segment mapping: > > Segment Sections... > > 00 .interrupts > > 01 .resource_table .text .ARM .init_array .fini_array > > 02 .data .bss .heap .stack > > Here is an example of formatting ELF for remoteproc: > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/loc > al_src/remoteproc-elf/linker.ld > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/loc > al_src/remoteproc-elf/imx7m4.S > > In this example I pack linux in to remoteproc elf image and start linux on > imx7d-m4 part. > Will be interesting if you can do the same on imx8* SoCs ;) In NXP release, the m4 elf files have data/bss/heap/stack in the same data area, so the linker merged them into one segment and cause memsz > filesz. I think I need to propose platform specific elf memset/memcpy, such as rproc_elf_memcpy, rproc_elf_memset, To i.MX, need use memset_io and memcpy_toio, taking TCM as device memory. Note: memset without io will cause abort when memsz>filesz. So use memset_io is safe. Thanks, Peng. > > Regards, > Oleksij > -- > 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 |
On Tue, Jul 28, 2020 at 07:50:04AM +0000, Peng Fan wrote: > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > > boot > > > > On Mon, Jul 27, 2020 at 09:18:31AM +0000, Peng Fan wrote: > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and > > > > early boot > > > > > > > > On Mon, Jul 27, 2020 at 06:44:32AM +0000, Peng Fan wrote: > > > > > Hi Oleksij, > > > > > > > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M > > > > > > and early boot > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > > > > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > > > > > > Since i.MX8MQ/M was not supported, several patches are needed > > > > > > > to first support the platform, then support early boot case. > > > > > > > > > > > > > > I intended to included i.MX8QM/QXP, but that would introduce a > > > > > > > large patchset, so not included. But the clk/syscon optional > > > > > > > patch for i.MX8QM/QXP was still kept here to avoid rebase error. > > > > > > > > > > > > Thank you for your work. > > > > > > > > > > > > Can you please provide more information about big picture of this > > work. > > > > > > > > > > > > If I see it correctly, we have here support for i.MX8MM, which > > > > > > seems to be able to fully control Cortex M4 (enable CPU core, etc...). > > > > > > > > > > Yes. > > > > > > > > In this case, I would recommend to mainline the i.MX8MM part > > > > first/separately. > > > > > > Only the last patch is to support earlyboot, all others is imx8mm part. > > > > ok > > > > > > > > > > > > > > > > > > And other case, where remoteproc is running on application > > > > > > processor and can't or should not touch M4 (i.MX7ULP, > > > > > > i.MX8QM/QXP..). Since M4 provides some functionality, you are > > > > > > trying to reuse remoteproc framework to get resource table > > > > > > present in ELF header and to dynamically load things. For some > > > > > > reasons this header provides more information then needed, so > > > > > > you are changing the ELF parser in the kernel > > > > to workaround it. > > > > > > > > > > Not exactly. > > > > > > > > > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked > > > > > by > > > > Linux remoteproc. > > > > > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we > > > > > will also add M4 kicked by Linux remoteproc. > > > > > For i.MX7ULP, I would only support M4 dual boot case, M4 control > > > > everything. > > > > > > > > From current state of discussion, i'm not sure what role plays > > > > remoteproc in the scenario where M4 is started before linux. > > > > Especially if we are not using resource table. > > > > > > We are using resource table from an address, not in elf file. > > > This is the new feature in Linux-next to support coproc booted early. > > > > > > > > > > > > The reason the change the elf parser is that when M4 elf is loaded > > > > > by Linux remoteproc, It use memset to clear area. > > > > > > > > The use of memset, depends on ELF format. Fix/change the linker > > > > script on your firmware and memset will be never called. > > > > > > > > > However we use ioremap, memset on ARM64 will report crash to > > > > > device nGnRE memory. And we could not use ioremap_wc to TCM area, > > > > > since it could have data correctly written into TCM. > > > > > > > > I have strong feeling, that we are talking about badly or not > > > > properly formatted ELF binary. I would prefer to double check it, > > > > before we will apply fixes on wrong place. > > > > > > > > > Maintainer not wanna to drop memset in common code, and TI guys > > > > > suggest add i.MX specific elf stuff. So I add elf handler in i.MX code. > > > > > > > > I think, removing memset may damage current users of imx_rproc driver. > > > > Since, like I said: the use of memset depends on ELF format. > > > > > > In my elf file, the last PT_LOAD contains data/bss/heap/stack. I'll > > > check with our MCU guys, we only need the specific data loaded. > > > > > > Elf file type is EXEC (Executable file) Entry point 0x1ffe0355 There > > > are 3 program headers, starting at offset 52 > > > > > > Program Headers: > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz > > Flg Align > > > LOAD 0x010000 0x1ffe0000 0x1ffe0000 0x00240 0x00240 > > R 0x10000 > > > LOAD 0x010240 0x1ffe0240 0x1ffe0240 0x03e90 0x03e90 > > RWE 0x10000 > > > LOAD 0x020000 0x20000000 0x1ffe40d0 0x00068 0x0ad00 > > RW 0x10000 > > > > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .interrupts > > > 01 .resource_table .text .ARM .init_array .fini_array > > > 02 .data .bss .heap .stack > > > > Here is an example of formatting ELF for remoteproc: > > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/loc > > al_src/remoteproc-elf/linker.ld > > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/loc > > al_src/remoteproc-elf/imx7m4.S > > > > In this example I pack linux in to remoteproc elf image and start linux on > > imx7d-m4 part. > > Will be interesting if you can do the same on imx8* SoCs ;) > > In NXP release, the m4 elf files have data/bss/heap/stack in the same > data area, so the linker merged them into one segment and cause > memsz > filesz. > > I think I need to propose platform specific elf memset/memcpy, > such as rproc_elf_memcpy, rproc_elf_memset, > > To i.MX, need use memset_io and memcpy_toio, taking TCM > as device memory. > > Note: memset without io will cause abort when memsz>filesz. > So use memset_io is safe. Sounds good, i would prefer this way.
> Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > boot > > On Tue, Jul 28, 2020 at 07:50:04AM +0000, Peng Fan wrote: > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and > > > early boot > > > > > > On Mon, Jul 27, 2020 at 09:18:31AM +0000, Peng Fan wrote: > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M > > > > > and early boot > > > > > > > > > > On Mon, Jul 27, 2020 at 06:44:32AM +0000, Peng Fan wrote: > > > > > > Hi Oleksij, > > > > > > > > > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support > > > > > > > iMX8M and early boot > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > > > > > > This patchset is to support i.MX8MQ/M coproc booted before > linux. > > > > > > > > Since i.MX8MQ/M was not supported, several patches are > > > > > > > > needed to first support the platform, then support early boot > case. > > > > > > > > > > > > > > > > I intended to included i.MX8QM/QXP, but that would > > > > > > > > introduce a large patchset, so not included. But the > > > > > > > > clk/syscon optional patch for i.MX8QM/QXP was still kept here to > avoid rebase error. > > > > > > > > > > > > > > Thank you for your work. > > > > > > > > > > > > > > Can you please provide more information about big picture of > > > > > > > this > > > work. > > > > > > > > > > > > > > If I see it correctly, we have here support for i.MX8MM, > > > > > > > which seems to be able to fully control Cortex M4 (enable CPU > core, etc...). > > > > > > > > > > > > Yes. > > > > > > > > > > In this case, I would recommend to mainline the i.MX8MM part > > > > > first/separately. > > > > > > > > Only the last patch is to support earlyboot, all others is imx8mm part. > > > > > > ok > > > > > > > > > > > > > > > > > > > > > > And other case, where remoteproc is running on application > > > > > > > processor and can't or should not touch M4 (i.MX7ULP, > > > > > > > i.MX8QM/QXP..). Since M4 provides some functionality, you > > > > > > > are trying to reuse remoteproc framework to get resource > > > > > > > table present in ELF header and to dynamically load things. > > > > > > > For some reasons this header provides more information then > > > > > > > needed, so you are changing the ELF parser in the kernel > > > > > to workaround it. > > > > > > > > > > > > Not exactly. > > > > > > > > > > > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 > > > > > > kicked by > > > > > Linux remoteproc. > > > > > > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but > > > > > > we will also add M4 kicked by Linux remoteproc. > > > > > > For i.MX7ULP, I would only support M4 dual boot case, M4 > > > > > > control > > > > > everything. > > > > > > > > > > From current state of discussion, i'm not sure what role plays > > > > > remoteproc in the scenario where M4 is started before linux. > > > > > Especially if we are not using resource table. > > > > > > > > We are using resource table from an address, not in elf file. > > > > This is the new feature in Linux-next to support coproc booted early. > > > > > > > > > > > > > > > The reason the change the elf parser is that when M4 elf is > > > > > > loaded by Linux remoteproc, It use memset to clear area. > > > > > > > > > > The use of memset, depends on ELF format. Fix/change the linker > > > > > script on your firmware and memset will be never called. > > > > > > > > > > > However we use ioremap, memset on ARM64 will report crash to > > > > > > device nGnRE memory. And we could not use ioremap_wc to TCM > > > > > > area, since it could have data correctly written into TCM. > > > > > > > > > > I have strong feeling, that we are talking about badly or not > > > > > properly formatted ELF binary. I would prefer to double check > > > > > it, before we will apply fixes on wrong place. > > > > > > > > > > > Maintainer not wanna to drop memset in common code, and TI > > > > > > guys suggest add i.MX specific elf stuff. So I add elf handler in i.MX > code. > > > > > > > > > > I think, removing memset may damage current users of imx_rproc > driver. > > > > > Since, like I said: the use of memset depends on ELF format. > > > > > > > > In my elf file, the last PT_LOAD contains data/bss/heap/stack. > > > > I'll check with our MCU guys, we only need the specific data loaded. > > > > > > > > Elf file type is EXEC (Executable file) Entry point 0x1ffe0355 > > > > There are 3 program headers, starting at offset 52 > > > > > > > > Program Headers: > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz > > > Flg Align > > > > LOAD 0x010000 0x1ffe0000 0x1ffe0000 0x00240 > 0x00240 > > > R 0x10000 > > > > LOAD 0x010240 0x1ffe0240 0x1ffe0240 0x03e90 > 0x03e90 > > > RWE 0x10000 > > > > LOAD 0x020000 0x20000000 0x1ffe40d0 0x00068 > 0x0ad00 > > > RW 0x10000 > > > > > > > > Section to Segment mapping: > > > > Segment Sections... > > > > 00 .interrupts > > > > 01 .resource_table .text .ARM .init_array .fini_array > > > > 02 .data .bss .heap .stack > > > > > > Here is an example of formatting ELF for remoteproc: > > > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/t > > > ree/loc > > > al_src/remoteproc-elf/linker.ld > > > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/t > > > ree/loc > > > al_src/remoteproc-elf/imx7m4.S > > > > > > In this example I pack linux in to remoteproc elf image and start > > > linux on > > > imx7d-m4 part. > > > Will be interesting if you can do the same on imx8* SoCs ;) > > > > In NXP release, the m4 elf files have data/bss/heap/stack in the same > > data area, so the linker merged them into one segment and cause memsz > > > filesz. > > > > I think I need to propose platform specific elf memset/memcpy, such as > > rproc_elf_memcpy, rproc_elf_memset, > > > > To i.MX, need use memset_io and memcpy_toio, taking TCM as device > > memory. > > > > Note: memset without io will cause abort when memsz>filesz. > > So use memset_io is safe. > > Sounds good, i would prefer this way. Just sent out, please help review there. https://patchwork.kernel.org/patch/11688751/ https://patchwork.kernel.org/patch/11688753/ Thanks, Peng. > > -- > 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 |