On Mon, Jul 27, 2020 at 06:44:32AM +0000, Peng Fan wrote:

Hi Oleksij,

quoted

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:

quoted

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.

quoted

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.

quoted

Correct?

quoted

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

++++++++++++++++++++-

quoted

 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 |