[U-Boot] [PATCH 3/7] 86xx: Unlock l1 cache unconditionally

[Peter Tyser]

On Fri, 2009-07-10 at 22:37 +0200, Wolfgang Denk wrote:
> Dear Kumar Gala,
> 
> In message <4B5A7126-FCDF-4EB0-9181-FB1BE571C715 at kernel.crashing.org> you wrote:
> > 
> > On May 22, 2009, at 10:26 AM, Peter Tyser wrote:
> > 
> > > Previously, it was only unlocked when Linux was executed using the
> > > "bootm" command.  Unlocking it unconditionally improves U-Boot
> > > performance and provides a common cache state when booting OSes.
> > >
> > > Signed-off-by: Peter Tyser <ptyser at xes-inc.com>
> > > ---
> > > lib_ppc/board.c |    8 +++++---
> > > lib_ppc/bootm.c |    3 ++-
> > > 2 files changed, 7 insertions(+), 4 deletions(-)
> > 
> > Wolfgang, do you know any reason we can't do the unlock for ALL ppc's  
> > in board_init_r()?
> 
> Sorry, I don't remember if there was any speciofic reason, or what
> that might have been.  Maybe the CHANGELOGs contain some hints?

The only platforms the define unlock_ram_in_cache() are 83xx, 85xx,
86xx, and 74xx_7xx.

It looks like the most of them had "issues" in their implementation that
could explain why there weren't enabled:
83xx - ade50c7fa1b16ef98be17e9c3ae286aecf4f5605,
6eb2a44e27919fdc601e0c05404b298a7602c0e3

86xx - 392438406041415fe64ab8748ec5ab5ad01d1cf7

74xx - d685b74c64a38849f1a129b3ab846fbf67dd937e

85xx - this one works

My best guess was all the non-85xx implementations had bugs or other
issues that caused U-Boot to become unstable after unlocking the cache.
Perhaps those bugs are fixed now, but I only have 86xx hardware to test
on.  I've been running a few 86xx boards with the cache unlocked with no
noticeable problems.

Peter