Dear Stefan,
in message 200804210729.53635.sr@denx.de you wrote:
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? ...
You are the 440 expert, not me :-)
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.
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.
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.
Best regards,
Wolfgang Denk