remoteproc/k3-r5: fix memzero issues on reserved SRAM regions
authorSuman Anna <s-anna@ti.com>
Tue, 1 Oct 2019 23:42:45 +0000 (18:42 -0500)
committerSuman Anna <s-anna@ti.com>
Wed, 2 Oct 2019 02:38:15 +0000 (21:38 -0500)
commitac2007e488785c247f4c2dd67dff377ae2d1c9be
tree42df5e8b44c8fd13f3ae2d5c04aae964294ad4be
parent91b50d6d1d8ec21d87358f77dfe7046bd9e74fef
remoteproc/k3-r5: fix memzero issues on reserved SRAM regions

The K3 R5 remoteproc driver can support loading into and executing
code from various on-chip SRAM regions like MCU SRAM or NavSS SRAM,
and these regions are mapped as device type memory because of the
usage of ioremap().

The remoteproc core ELF loader function zeroes out any remaining
portions of a program segment if the actual memory size (p_memsz)
is more than the loadable content (p_filesz), and this memset is
throwing a kernel crash on these reserved SRAM regions at present.
This is because of the usage of the "DC ZVA" instruction within the
Arm64 memset library function when zeroing out memory, which throws
an alignment fault on device type memory.

Fix this by switching to ioremap_wc() function instead of ioremap()
function for mapping the SRAM regions. The ioremap_wc() maps the
SRAM regions as normal non-cacheable memory instead. The solution
follows the similar logic used in the core SRAM driver in
commit 0ab163ad1ea0 ("misc: sram: switch to ioremap_wc from ioremap").

Fixes: 7091176e2f99 ("remoteproc/k3-r5: add loading support for on-chip SRAM regions")
Signed-off-by: Suman Anna <s-anna@ti.com>
drivers/remoteproc/ti_k3_r5_remoteproc.c