[U-Boot] [PATCH] common/board_r: Fix booting issue on T4240QDS

[Scott Wood]

On Fri, 2014-10-03 at 21:31 -0500, Sun York-R58495 wrote:
> 
> On 10/3/14 7:21 PM, "Simon Glass" <sjg at chromium.org> wrote:
> 
> >On 2 October 2014 16:20, York Sun <yorksun at 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 at freescale.com>
> >> CC: Scott Wood <scottwood at freescale.com>
> >> CC: Simon Glass <sjg at 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 at 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