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

[Jian Luo <Jian.Luo4@boschrexroth.de>]

Hi Dinh, Hi Marek,

any updates on this issue?

Best regards,

Jian Luo


On 04.09.2015 16:32, Marek Vasut wrote:
 > On Friday, September 04, 2015 at 04:26:46 PM, Simon Glass wrote:
 >> On 4 September 2015 at 08:25, Marek Vasut <marex@denx.de> wrote:
 >>> On Friday, September 04, 2015 at 04:16:21 PM, Simon Glass wrote:
 >>>> Hi,
 >>>>
 >>>> On 4 September 2015 at 01:36, Jian Luo <Jian.Luo4@boschrexroth.de> 
wrote:
 >>>>> Hi Simon,
 >>>>>
 >>>>> On 04.09.2015 02:23, Simon Glass wrote:
 >>>>>> Hi,
 >>>>>>
 >>>>>> On 3 September 2015 at 05:14, Marek Vasut <marex@denx.de> wrote:
 >>>>>>> On Thursday, September 03, 2015 at 01:12:03 PM, Jian Luo wrote:
 >>>>>>>> On 03.09.2015 12:46, Marek Vasut wrote:
 >>>>>>>>  > On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote:
 >>>>>>>>  >
 >>>>>>>>  > Hi!
 >>>>>>>>  >
 >>>>>>>>  > [...]
 >>>>>>>>  >
 >>>>>>>>  >>  >> 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.
 >>>>>>>>  >
 >>>>>>>>  > OK, but what about turning the ECC off in the SPL, will that
 >>>>>>>>  > also
 >>>>>>>>
 >>>>>>>> introduce
 >>>>>>>>
 >>>>>>>>  > corruption or not ? That might be the right fix, no ?
 >>>>>>>>
 >>>>>>>> Hi Marek,
 >>>>>>>>
 >>>>>>>> Sorry, I don't know the detail of ECC implementation in socfpga.
 >>>>>>>> Dinh might have the answer to that.
 >>>>>>>>
 >>>>>>>> Anyhow I still think let the setting untouched is the safest fix.
 >>>>>>>> SPL should use the same ECC setting which BROM loads SPL with.
 >>>>>>>
 >>>>>>> That's right, but I'd also like to have this bit in some defined
 >>>>>>> state from the boot instead of having this in some random setting.
 >>>>>>> Dinh, can you comment on this corruption please ?
 >>>>>>
 >>>>>> Also I'm still a bit confused.
 >>>>>>
 >>>>>> The code in crt0.S zeroes global_data so how can it be non-zero a
 >>>>>> little later in board_init_f()?
 >>>>>
 >>>>> board_init_f() enables the ECC of the SRAM regardless its previous
 >>>>> state. If ECC is disabled beborehand, re-enabling it can cause SRAM
 >>>>> misreading.
 >>>>
 >>>> OK thanks. It might be possible to do this earlier, say in
 >>>> cpu_init_crit().
 >>>
 >>> You cannot enable the bit, because it'd corrupt your OCRAM and your 
code
 >>> is running from the OCRAM, thus you'd be susceptible to corrupting the
 >>> code you're running itself :(
 >>
 >> Oh joy. Well anyway I think this is a chip-specific problem and there
 >> is nothing wrong in general with the current init process.
 >
 > That's absolutelly correct.
 >
 > I'd like to hear Dinh's opinion on this, because this seems quite 
important.