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

@@ -1063,8 +1063,8 @@ static int k3_r5_core_of_get_sram_memories(struct platform_device *pdev,
 		core->sram[i].bus_addr = res.start;
 		core->sram[i].dev_addr = res.start;
 		core->sram[i].size = resource_size(&res);
-		core->sram[i].cpu_addr = ioremap(res.start,
-						 resource_size(&res));
+		core->sram[i].cpu_addr = ioremap_wc(res.start,
+						    resource_size(&res));
 		if (!core->sram[i].cpu_addr) {
 			dev_err(dev, "failed to parse and map sram%d memory at %pad\n",
 				i, &res.start);