From: Suman Anna <s-anna@ti.com> To: Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Lokesh Vutla <lokeshvutla@ti.com>, <linux-remoteproc@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, Suman Anna <s-anna@ti.com> Subject: [PATCH v5 3/4] remoteproc: k3-r5: Initialize TCM memories for ECC Date: Fri, 2 Oct 2020 18:42:33 -0500 [thread overview] Message-ID: <20201002234234.20704-4-s-anna@ti.com> (raw) In-Reply-To: <20201002234234.20704-1-s-anna@ti.com> The R5F processors on K3 SoCs all have two TCMs (ATCM and BTCM) that support 32-bit ECC. The TCMs are typically loaded with some boot-up code to initialize the R5 MPUs to further execute code out of DDR. The ECC for the TCMs is enabled by default on K3 SoCs due to internal default tie-off values, but the TCM memories are not initialized on device power up. Any read access without the corresponding TCM memory location initialized will generate an ECC error, and any such access from a A72 or A53 core will trigger a SError. So, zero initialize both the TCM memories before loading any firmware onto a R5F in remoteproc mode. Any R5F booted from U-Boot/SPL would require a similar initialization in the bootloader. Note that both the TCMs are initialized unconditionally as the TCM enable config bits only manage the access and visibility from R5. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> --- v5: No changes v4: No changes v3: https://patchwork.kernel.org/patch/11679335/ - No code changes, picked up tags v2: https://patchwork.kernel.org/patch/11632989/ v1: https://patchwork.kernel.org/patch/11456371/ drivers/remoteproc/ti_k3_r5_remoteproc.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c index 15e52ea67bbe..a6b395ab47b6 100644 --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c @@ -362,11 +362,24 @@ static int k3_r5_rproc_prepare(struct rproc *rproc) ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP) ? k3_r5_lockstep_release(cluster) : k3_r5_split_release(core); - if (ret) + if (ret) { dev_err(dev, "unable to enable cores for TCM loading, ret = %d\n", ret); + return ret; + } - return ret; + /* + * Zero out both TCMs unconditionally (access from v8 Arm core is not + * affected by ATCM & BTCM enable configuration values) so that ECC + * can be effective on all TCM addresses. + */ + dev_dbg(dev, "zeroing out ATCM memory\n"); + memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size); + + dev_dbg(dev, "zeroing out BTCM memory\n"); + memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size); + + return 0; } /* -- 2.28.0
WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com> To: Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Mathieu Poirier <mathieu.poirier@linaro.org> Cc: devicetree@vger.kernel.org, Lokesh Vutla <lokeshvutla@ti.com>, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH v5 3/4] remoteproc: k3-r5: Initialize TCM memories for ECC Date: Fri, 2 Oct 2020 18:42:33 -0500 [thread overview] Message-ID: <20201002234234.20704-4-s-anna@ti.com> (raw) In-Reply-To: <20201002234234.20704-1-s-anna@ti.com> The R5F processors on K3 SoCs all have two TCMs (ATCM and BTCM) that support 32-bit ECC. The TCMs are typically loaded with some boot-up code to initialize the R5 MPUs to further execute code out of DDR. The ECC for the TCMs is enabled by default on K3 SoCs due to internal default tie-off values, but the TCM memories are not initialized on device power up. Any read access without the corresponding TCM memory location initialized will generate an ECC error, and any such access from a A72 or A53 core will trigger a SError. So, zero initialize both the TCM memories before loading any firmware onto a R5F in remoteproc mode. Any R5F booted from U-Boot/SPL would require a similar initialization in the bootloader. Note that both the TCMs are initialized unconditionally as the TCM enable config bits only manage the access and visibility from R5. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> --- v5: No changes v4: No changes v3: https://patchwork.kernel.org/patch/11679335/ - No code changes, picked up tags v2: https://patchwork.kernel.org/patch/11632989/ v1: https://patchwork.kernel.org/patch/11456371/ drivers/remoteproc/ti_k3_r5_remoteproc.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c index 15e52ea67bbe..a6b395ab47b6 100644 --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c @@ -362,11 +362,24 @@ static int k3_r5_rproc_prepare(struct rproc *rproc) ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP) ? k3_r5_lockstep_release(cluster) : k3_r5_split_release(core); - if (ret) + if (ret) { dev_err(dev, "unable to enable cores for TCM loading, ret = %d\n", ret); + return ret; + } - return ret; + /* + * Zero out both TCMs unconditionally (access from v8 Arm core is not + * affected by ATCM & BTCM enable configuration values) so that ECC + * can be effective on all TCM addresses. + */ + dev_dbg(dev, "zeroing out ATCM memory\n"); + memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size); + + dev_dbg(dev, "zeroing out BTCM memory\n"); + memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size); + + return 0; } /* -- 2.28.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-02 23:43 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-02 23:42 [PATCH v5 0/4] TI K3 R5F remoteproc support Suman Anna 2020-10-02 23:42 ` Suman Anna 2020-10-02 23:42 ` [PATCH v5 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs Suman Anna 2020-10-02 23:42 ` Suman Anna 2020-10-02 23:42 ` [PATCH v5 2/4] remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem Suman Anna 2020-10-02 23:42 ` Suman Anna 2020-10-02 23:42 ` Suman Anna [this message] 2020-10-02 23:42 ` [PATCH v5 3/4] remoteproc: k3-r5: Initialize TCM memories for ECC Suman Anna 2020-10-02 23:42 ` [PATCH v5 4/4] remoteproc: k3-r5: Add loading support for on-chip SRAM regions Suman Anna 2020-10-02 23:42 ` Suman Anna 2020-10-14 0:10 ` [PATCH v5 0/4] TI K3 R5F remoteproc support patchwork-bot+linux-remoteproc
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=20201002234234.20704-4-s-anna@ti.com \ --to=s-anna@ti.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-remoteproc@vger.kernel.org \ --cc=lokeshvutla@ti.com \ --cc=mathieu.poirier@linaro.org \ --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: linkBe 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.