From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jian Luo <Jian.Luo4@boschrexroth.de>
Date: Thu, 3 Sep 2015 12:03:44 +0200
Subject: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization
 failure after warm reset
In-Reply-To: <201509031141.22095.marex@denx.de>
References: <55E01ECE.6020309@boschrexroth.de>
 <201508311528.42937.marex@denx.de> <55E7237D.8050202@boschrexroth.de>
 <201509031141.22095.marex@denx.de>
Message-ID: <55E81B00.5090203@boschrexroth.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

 >
 >> 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.

Best regards,

Jian Luo