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.