All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Bailon <abailon@baylibre.com>
To: ohad@wizery.com, bjorn.andersson@linaro.org, robh+dt@kernel.org,
	matthias.bgg@gmail.com
Cc: linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	Alexandre Bailon <abailon@baylibre.com>
Subject: [PATCH 5/6] remoteproc: mtk_apu: Don't try to use the APU local RAM
Date: Mon, 13 Jul 2020 15:29:26 +0200	[thread overview]
Message-ID: <20200713132927.24925-6-abailon@baylibre.com> (raw)
In-Reply-To: <20200713132927.24925-1-abailon@baylibre.com>

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 <abailon@baylibre.com>
---
 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


WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Bailon <abailon@baylibre.com>
To: ohad@wizery.com, bjorn.andersson@linaro.org, robh+dt@kernel.org,
	matthias.bgg@gmail.com
Cc: devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	Alexandre Bailon <abailon@baylibre.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/6] remoteproc: mtk_apu: Don't try to use the APU local RAM
Date: Mon, 13 Jul 2020 15:29:26 +0200	[thread overview]
Message-ID: <20200713132927.24925-6-abailon@baylibre.com> (raw)
In-Reply-To: <20200713132927.24925-1-abailon@baylibre.com>

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 <abailon@baylibre.com>
---
 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


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Bailon <abailon@baylibre.com>
To: ohad@wizery.com, bjorn.andersson@linaro.org, robh+dt@kernel.org,
	matthias.bgg@gmail.com
Cc: devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	Alexandre Bailon <abailon@baylibre.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/6] remoteproc: mtk_apu: Don't try to use the APU local RAM
Date: Mon, 13 Jul 2020 15:29:26 +0200	[thread overview]
Message-ID: <20200713132927.24925-6-abailon@baylibre.com> (raw)
In-Reply-To: <20200713132927.24925-1-abailon@baylibre.com>

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 <abailon@baylibre.com>
---
 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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-07-13 13:29 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 13:29 [PATCH 0/6] Add support of mt8183 APU Alexandre Bailon
2020-07-13 13:29 ` Alexandre Bailon
2020-07-13 13:29 ` Alexandre Bailon
2020-07-13 13:29 ` [PATCH 1/6] dt bindings: remoteproc: Add bindings for MT8183 APU Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-14 17:19   ` Rob Herring
2020-07-14 17:19     ` Rob Herring
2020-07-14 17:19     ` Rob Herring
2020-07-14 17:22   ` Rob Herring
2020-07-14 17:22     ` Rob Herring
2020-07-14 17:22     ` Rob Herring
2020-07-13 13:29 ` [PATCH 2/6] remoteproc: Add a remoteproc driver for the MT8183's APU Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-20 22:17   ` Mathieu Poirier
2020-07-20 22:17     ` Mathieu Poirier
2020-07-20 22:17     ` Mathieu Poirier
2020-08-06 13:25     ` Alexandre Bailon
2020-08-06 13:25       ` Alexandre Bailon
2020-08-06 13:25       ` Alexandre Bailon
2020-07-20 22:19   ` Mathieu Poirier
2020-07-20 22:19     ` Mathieu Poirier
2020-07-20 22:19     ` Mathieu Poirier
2020-07-13 13:29 ` [PATCH 3/6] remoteproc: mtk_vpu_rproc: Add support of JTAG Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-21 19:52   ` Mathieu Poirier
2020-07-21 19:52     ` Mathieu Poirier
2020-07-21 19:52     ` Mathieu Poirier
2020-08-06 13:49     ` Alexandre Bailon
2020-08-06 13:49       ` Alexandre Bailon
2020-08-06 13:49       ` Alexandre Bailon
2020-07-13 13:29 ` [PATCH 4/6] remoteproc: mtk_vpu_rproc: Don't try to load empty PT_LOAD segment Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-13 22:20   ` kernel test robot
2020-07-13 22:20     ` kernel test robot
2020-07-13 22:20     ` kernel test robot
2020-07-21 20:21   ` Mathieu Poirier
2020-07-21 20:21     ` Mathieu Poirier
2020-07-21 20:21     ` Mathieu Poirier
2020-07-13 13:29 ` Alexandre Bailon [this message]
2020-07-13 13:29   ` [PATCH 5/6] remoteproc: mtk_apu: Don't try to use the APU local RAM Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-21 20:43   ` Mathieu Poirier
2020-07-21 20:43     ` Mathieu Poirier
2020-07-21 20:43     ` Mathieu Poirier
2020-07-13 13:29 ` [PATCH 6/6] ARM64: mt8183: Add support of APU to mt8183 Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-13 13:29   ` Alexandre Bailon
2020-07-17 21:02   ` kernel test robot
2020-07-17 21:02     ` kernel test robot
2020-07-17 21:02     ` kernel test robot
2020-07-17 21:02     ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200713132927.24925-6-abailon@baylibre.com \
    --to=abailon@baylibre.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=ohad@wizery.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.