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@denx.de =====================================================================