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 <ma...@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.l...@boschrexroth.de> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On 04.09.2015 02:23, Simon Glass wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 3 September 2015 at 05:14, Marek Vasut <ma...@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.


_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to