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