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

[Stefan Roese <sr@denx.de>]

On Monday 21 April 2008, Wolfgang Denk wrote:
> > This would result in bigger changes to common code currently using those
> > functions (especially dcache_disable). Probably by using more #ifdefs
> > there which I would really like not to see.
>
> I don't like to see these either, but it's better than lying in the
> face of the user.

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? ...

> > OK, I removed this patch from my custodian repository. But I assume that
> > 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 support
> > 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 have
> > 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.

> > > Yes,  I  am  aware  that  the   current   (new)   implementation   of
> > > do_bootelf_exec()  needs  to  be fixed for this, too - and maybe some
> > > other places as well. But this is important enough to me.
> >
> > Understood. We should propably revert this patch then.
>
> 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.

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
=====================================================================