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