On Fri, 2014-10-03 at 21:31 -0500, Sun York-R58495 wrote:
On 10/3/14 7:21 PM, "Simon Glass" sjg@chromium.org wrote:
On 2 October 2014 16:20, York Sun yorksun@freescale.com wrote:
Commit 294b91a5817147d4b7f47be2ac69bac2a1f26491 moved initr_malloc earlier than initr_unlock_ram_in_cache. This causes issue on T4240. It may be related to locked L1 d-cache and unlocked L2 cache. D- cache could and should be unlock earlier for normal operation.
This patch moves initr_unlock_ram_in_cache before initr_malloc. It has been verified on the following boards, in which only T4240QDS suffered and has been since fixed: T4240QDS, T2080QDS, P5040DS, P4080DS, MPC8572DS, MPC8536DS, MPC8641HPCN, B4860QDS.
Signed-off-by: York Sun yorksun@freescale.com CC: Scott Wood scottwood@freescale.com CC: Simon Glass sjg@chromium.org
The root cause of the this failure wasn't identified. It may be hidden too deep to be dug out in time. This fix preserves the order of original code between initr_malloc and initr_unlock_ram_in_cache.
common/board_r.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c index 231c6d6..c339aad 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -717,6 +717,9 @@ init_fnc_t init_sequence_r[] = { initr_caches, #endif initr_reloc_global_data, +#if defined(CONFIG_SYS_INIT_RAM_LOCK) && defined(CONFIG_E500)
initr_unlock_ram_in_cache,+#endif
The code looks fine. Are we sure it shouldn't go above initr_reloc_global_data()?
Acked-by: Simon Glass sjg@chromium.org
Simon,
From the code, I don't see why it can't be moved above. But since we didn't identify the root cause, I am less confident to do so. I was focusing on fixing this issue and test.
It could be called as soon as we've stopped using the init ram area.
In the long term, though, a more robust fix would be to stop abusing L1 cache on e6500, and use CPC SRAM instead.
-Scott