
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.