On Fri, 2014-10-03 at 21:31 -0500, Sun York-R58495 wrote:
>
> On 10/3/14 7:21 PM, "Simon Glass" <s...@chromium.org> wrote:
>
> >On 2 October 2014 16:20, York Sun <york...@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 <york...@freescale.com>
> >> CC: Scott Wood <scottw...@freescale.com>
> >> CC: Simon Glass <s...@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 <s...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
