On 2/13/22 9:10 AM, Andrei Lalaev wrote:

It's better to restore previous value at offset because otherwise the function can corrupt memory reserved by Linux (e.g. ramoops).

With this patch, does ramoops work for you? and on which hardware? If so, I am definitely in favor of applying this patch.

I'm a bit surprised that DRAM contents are maintained (this isn't the only place where they could be destroyed). I suppose the reset state of the PRCM enables pad hold, which would put the DRAM in self-refresh. So we just have to be careful during DRAM controller init.

Regards, Samuel

Signed-off-by: Andrei Lalaev andrei.lalaev@emlid.com

arch/arm/mach-sunxi/dram_helpers.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_helpers.c b/arch/arm/mach-sunxi/dram_helpers.c index 2c873192e6..ed6db14f3c 100644 --- a/arch/arm/mach-sunxi/dram_helpers.c +++ b/arch/arm/mach-sunxi/dram_helpers.c @@ -32,12 +32,20 @@ void mctl_await_completion(u32 *reg, u32 mask, u32 val) #ifndef CONFIG_MACH_SUNIV bool mctl_mem_matches(u32 offset) {

• ulong addr = CONFIG_SYS_SDRAM_BASE + offset;
• u32 prev_val = readl(addr);
• bool ret = false;
• /* Try to write different values to RAM at two addresses */ writel(0, CONFIG_SYS_SDRAM_BASE);

• writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);

• writel(0xaa55aa55, addr); dsb(); /* Check if the same value is actually observed when reading back */

• return readl(CONFIG_SYS_SDRAM_BASE) ==

•       readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);
  

• ret = readl(CONFIG_SYS_SDRAM_BASE) == readl(addr);
• /* Restore previous value */
• writel(prev_val, addr);
• return ret;

} #endif