2020-07-13 13:30:18

by Alexandre Bailon

Subject: [PATCH 5/6] remoteproc: mtk_apu: Don't try to use the APU local RAM

Currently, this local RAM is not accessible from the CPU.
If the CPU tries to access it, then the CPU will hang.

Remoteproc may try to use it when it load a firmware
that has some sections in the local RAM.
This workarounds the issue by skiping this section.

Signed-off-by: Alexandre Bailon <[email protected]>
---
drivers/remoteproc/mtk_apu_rproc.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)

diff --git a/drivers/remoteproc/mtk_apu_rproc.c b/drivers/remoteproc/mtk_apu_rproc.c
index 565b3adca5de..e16d3258a785 100644
--- a/drivers/remoteproc/mtk_apu_rproc.c
+++ b/drivers/remoteproc/mtk_apu_rproc.c
@@ -57,6 +57,9 @@
#define CORE_DEFAULT2_SPIDEN BIT(0)
#define CORE_XTENSA_ALTRESETVEC (0x000001F8)

+#define DRAM0_START (0x7ff00000)
+#define IRAM0_END (0x7ff80000)
+
struct mtk_vpu_rproc {
struct device *dev;
struct rproc *rproc;
@@ -139,6 +142,7 @@ static void mtk_vpu_rproc_kick(struct rproc *rproc, int vqid)

int mtk_vpu_elf_sanity_check(struct rproc *rproc, const struct firmware *fw)
{
+ struct mtk_vpu_rproc *vpu_rproc = rproc->priv;
const u8 *elf_data = fw->data;
struct elf32_hdr *ehdr;
struct elf32_phdr *phdr;
@@ -156,6 +160,16 @@ int mtk_vpu_elf_sanity_check(struct rproc *rproc, const struct firmware *fw)
/* Remove empty PT_LOAD section */
if (phdr->p_type == PT_LOAD && !phdr->p_paddr)
phdr->p_type = PT_NULL;
+ /*
+ * Workaround: Currently, the CPU can't access to the APU
+ * local RAM. This removes the local RAM section from the
+ * firmware. Please note that may cause some issues.
+ */
+ if (phdr->p_paddr >= DRAM0_START && phdr->p_paddr < IRAM0_END) {
+ dev_warn_once(vpu_rproc->dev,
+ "Skipping the APU local RAM section\n");
+ phdr->p_type = PT_NULL;
+ }
}

return 0;
--
2.26.2

2020-07-21 20:44:49

by Mathieu Poirier

Subject: Re: [PATCH 5/6] remoteproc: mtk_apu: Don't try to use the APU local RAM

On Mon, Jul 13, 2020 at 03:29:26PM +0200, Alexandre Bailon wrote:
> Currently, this local RAM is not accessible from the CPU.
> If the CPU tries to access it, then the CPU will hang.
>
> Remoteproc may try to use it when it load a firmware
> that has some sections in the local RAM.
> This workarounds the issue by skiping this section.
>
> Signed-off-by: Alexandre Bailon <[email protected]>
> ---
> drivers/remoteproc/mtk_apu_rproc.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/remoteproc/mtk_apu_rproc.c b/drivers/remoteproc/mtk_apu_rproc.c
> index 565b3adca5de..e16d3258a785 100644
> --- a/drivers/remoteproc/mtk_apu_rproc.c
> +++ b/drivers/remoteproc/mtk_apu_rproc.c
> @@ -57,6 +57,9 @@
> #define CORE_DEFAULT2_SPIDEN BIT(0)
> #define CORE_XTENSA_ALTRESETVEC (0x000001F8)
>
> +#define DRAM0_START (0x7ff00000)
> +#define IRAM0_END (0x7ff80000)
> +
> struct mtk_vpu_rproc {
> struct device *dev;
> struct rproc *rproc;
> @@ -139,6 +142,7 @@ static void mtk_vpu_rproc_kick(struct rproc *rproc, int vqid)
>
> int mtk_vpu_elf_sanity_check(struct rproc *rproc, const struct firmware *fw)
> {
> + struct mtk_vpu_rproc *vpu_rproc = rproc->priv;
> const u8 *elf_data = fw->data;
> struct elf32_hdr *ehdr;
> struct elf32_phdr *phdr;
> @@ -156,6 +160,16 @@ int mtk_vpu_elf_sanity_check(struct rproc *rproc, const struct firmware *fw)
> /* Remove empty PT_LOAD section */
> if (phdr->p_type == PT_LOAD && !phdr->p_paddr)
> phdr->p_type = PT_NULL;
> + /*
> + * Workaround: Currently, the CPU can't access to the APU
> + * local RAM. This removes the local RAM section from the
> + * firmware. Please note that may cause some issues.
> + */
> + if (phdr->p_paddr >= DRAM0_START && phdr->p_paddr < IRAM0_END) {
> + dev_warn_once(vpu_rproc->dev,
> + "Skipping the APU local RAM section\n");
> + phdr->p_type = PT_NULL;

We can't selectively decide to not load sections of a program due to a platform
driver shortcoming. Either a real solution is found or booting the remote
processor is interrupted, with a strong incline toward the former.

I guess you're dealing with tightly coupled memory or on-chip RAM areas -
both are accessed on other platform using ioremap_wc() or devm_ioremap_wc().
You might want to try doing what Suman has done in this patchset [1], with
specific attention to TCMs and SRAM.

Thanks,
Mathieu

[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=310325

> + }
> }
>
> return 0;
> --
> 2.26.2
>