[U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset

[Jian Luo]

On 03.09.2015 12:09, Marek Vasut wrote:
 > On Thursday, September 03, 2015 at 12:03:44 PM, Jian Luo wrote:
 >> Hi!
 >
 > Hi!
 >
 >> On 03.09.2015 11:41, Marek Vasut wrote:
 >>  > On Wednesday, September 02, 2015 at 06:27:41 PM, Jian Luo wrote:
 >>  >> Hi!
 >>  >>
 >>  >> this error comes again. It isn't a compiler error after all. :(
 >>  >>
 >>  >> JTAG inspection shows that the problem is located in
 >>  >> arch/arm/mach-socfpga/spl.c line94.
 >>  >> It seems that re-enable ECC on OCRAM can cause some strange value
 >>  >> changes in SRAM.
 >>  >> Disabling ECC might also cause value changes, which I didn't test.
 >>  >>
 >>  >> On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19 
(derr|serr|en). So
 >>  >> gd keeps intact.
 >>  >>
 >>  >> In our VxWorks Image ECC on OCRAM happens to be disabled.
 >>  >> After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr).
 >>  >> Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.
 >>  >
 >>  > Ew, Dinh, can you check this please ? This is scary.
 >>
 >> You can also reproduce the problem directly in U-Boot with 2 steps:
 >>    => mw.l 0xFFD08144 0
 >>    => reset
 >>
 >> On my ade0-nano-soc it hangs even before serial output,
 >> which means it did corrupt the SPL. I guess I just got (un)lucky with
 >> socdk.
 >
 > Oh, nice testcase, thanks!
 >
 >>  >> My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it 
works
 >>  >> for me.
 >>  >>
 >>  >> diff --git a/arch/arm/mach-socfpga/spl.c 
b/arch/arm/mach-socfpga/spl.c
 >>  >> index 775a827..c858406 100644
 >>  >> --- a/arch/arm/mach-socfpga/spl.c
 >>  >> +++ b/arch/arm/mach-socfpga/spl.c
 >>  >> @@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
 >>  >>
 >>  >>           * and DBE might triggered during power on
 >>  >>           */
 >>  >>
 >>  >>          reg = readl(&sysmgr_regs->eccgrp_ocram);
 >>  >>
 >>  >> -       if (reg & SYSMGR_ECC_OCRAM_SERR)
 >>  >> -               writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
 >>  >> - &sysmgr_regs->eccgrp_ocram);
 >>  >> -       if (reg & SYSMGR_ECC_OCRAM_DERR)
 >>  >> -               writel(SYSMGR_ECC_OCRAM_DERR  | SYSMGR_ECC_OCRAM_EN,
 >>  >> - &sysmgr_regs->eccgrp_ocram);
 >>  >> +       if (reg & SYSMGR_ECC_OCRAM_SERR) {
 >>  >> +               reg &= ~SYSMGR_ECC_OCRAM_SERR;
 >>  >> +               writel(reg, &sysmgr_regs->eccgrp_ocram);
 >>  >> +       }
 >>  >> +       if (reg & SYSMGR_ECC_OCRAM_DERR) {
 >>  >> +               reg &= ~SYSMGR_ECC_OCRAM_DERR;
 >>  >> +               writel(reg, &sysmgr_regs->eccgrp_ocram);
 >>  >> +       }
 >>  >>
 >>  >>          memset(__bss_start, 0, __bss_end - __bss_start);
 >>  >>
 >>  >> Other solution:
 >>  >> 1. Moving OCRAM ECC setting to earlier stage: requires change in
 >>  >> generic code.
 >>  >> 2. Clear gd afterwards: requires replication of every early stage gd
 >>  >> setting.
 >>  >
 >>  > What I would be worried is that if this really happens, it likely
 >>
 >> also corrupts
 >>
 >>  > the SPL code which is loaded in OCRAM.
 >>  >
 >>  > Can't you tune the VxWorks to keep the ECC enabled ?
 >>
 >> Yes, I can. But U-Boot can still have problem with other Image which
 >> disables ECC.
 >> I found another post related to this problem
 >> https://lkml.org/lkml/2015/2/6/685 .
 >>      Quote: To initialize ECC, the OCRAM needs to enable ECC then clear
 >> the entire
 >>      memory to zero before using it.
Hi!
 >
 > Oh, but that is a problem, since we're running from the OCRAM ourselves,
 > thus we cannot clear the OCRAM. Maybe we should force-disable the ECC
 > instead? But can we be sure that the corruption does not happen when
 > you disable ECC ?

Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN 
bit intact in the patch.

Best regards,

Jian Luo