[U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440

[Stefan Roese]

Hi Wolfgang,

On Monday 21 April 2008, Wolfgang Denk wrote:
> > Please note that it is not so easy on 440 to even define *what exactly*
> > the functions/commands d/icache_en/disable mean. This is because 440 has
> > MMU support and we can have different cache setups for all TLB entries.
> > So to which TLB entries should these functions refer? Just those mapping
> > SDRAM? And/or FLASH? And/or internal SRAM? ...
>
> You are the 440 expert, not me :-)

This has nothing to do with 440. It's more a general question. But OK, from my 
understanding, it makes most sense that the i/dcache U-Boot commands touch 
the cache attributes of all SDRAM related TLB's.

> > > > you are you asking for additional changes too. Are you asking me to
> > > > remove (a) all dummy cache entries or (b) to support *real* cache
> > > > suppo> rt functions for 440? (a) would lead as explained above to
> > > > bigger code changes in the common code and (b) is extremely difficult
> > > > and I just ha> ve no time for such a thing currently.
> > >
> > > Yes, let's do either (a) or (b). There is no other choice.
> >
> > From my point of view, both "solutions" should not be done outside of a
> > merge-window. I'll try to find some time to implement on of those options
> > in the next weeks. But perhaps somebody else has more "free time" and
> > sends patches to implement (and test) this stuff.
>
> I agree that it is probably not  possible  to  fix  this  right  now,
> especially  since the actual problem is older, it just became visible
> now.

I knew they existed and still thing this is no problem. But we seem to 
disagree here.

> But I insist that this must be fixed  for  the  next  release  -  and
> actually it seems to be a good thing to really enable the instruction
> cache  -  this would allow to speed up booting on 440 systems quite a
> bit.

You might remember that I mentioned that this currently existing cache support 
for 440 is not finished yet. There are still some issues, for example some 
drivers like USB won't work currently with d-cache enabled. This is the 
reason that I didn't enable this option for any of the 4xx boards that I 
maintain. Please note that I already spent some days of my "free time" to 
this cache support on 440. Matthias Fuchs also has contributed here.

And what does this mean that you "insist that this must be fixed for the next 
release"? I'm sorry, but I personally can't promise to "fix" this issue until 
the next merge window opens.

> > > This still leaves the problem of the current "implementation" of  the
> > > other  stubs. Please note that as is, we even have *random* behaviour
> > > of the code, as the  functions  are  supposed  to  return  the  cache
> > > status, but no return value gets loaded.
> >
> > I don't see such a problem with *random* behavior. d/icache_status return
> > 0 on 440.
>
> Ah, you are  right.  I  thought  that  the  {i,d}cache_{en,dis}able()
> functions  returned a status, but they are indeed void. Sorry for the
> false alarm.

OK.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================