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.
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 ?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
