| Message ID | 20200630024922.32491-4-s-anna@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | TI K3 R5F remoteproc support | expand |
On Mon, Jun 29, 2020 at 09:49:21PM -0500, Suman Anna wrote: > 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> > --- > v2: > - Fixed the logic of initializing TCMs even when the resets deassertion > failed > - Dropped the confusing last sentence from the 2nd paragraph of the > patch description > - Revised the patch title to move away from remoteproc/k3-r5 > - Dropped Mathieu's Acked-by because of the changes > 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 c4f99e59dc2f..aca0eaf42a38 100644 > --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c > +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c > @@ -363,11 +363,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; Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> > } > > /* > -- > 2.26.0 >
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c index c4f99e59dc2f..aca0eaf42a38 100644 --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c @@ -363,11 +363,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; } /*
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> --- v2: - Fixed the logic of initializing TCMs even when the resets deassertion failed - Dropped the confusing last sentence from the 2nd paragraph of the patch description - Revised the patch title to move away from remoteproc/k3-r5 - Dropped Mathieu's Acked-by because of the changes v1: https://patchwork.kernel.org/patch/11456371/ drivers/remoteproc/ti_k3_r5_remoteproc.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)