In message 200804211023.57611.sr@denx.de you wrote:
You are the 440 expert, not me :-)
This has nothing to do with 440. It's more a general question. But OK, from my
Well, it affects only processors which need MMU support. Most doen't.
understanding, it makes most sense that the i/dcache U-Boot commands touch the cache attributes of all SDRAM related TLB's.
In general, the chackes should be enabled whenever and whereever possible.
I think it should be pretty safe to enable the I cache for all SDRAM, SRAM and flash areas; or, put differently, for all memory areas except maybe any mapped PCI memory windows.
If possible, also D cahce should be enabled, but I cannot judge if this works or not with the given driver code.
Also, it depends on where the initial stack and data is located (you probably cannot disable caches if you put initial data in cache).
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.
The problem is that the code is misleading. I read some source file and see "icache_enable()", so I expect that the I cache is on afterwards. It is completely counterintuitive if it isn't. Such things have caused debugging nightmares before, and I don't have enough hair left to tear the rest on such things.
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
Yes, I do remember that. But I assumed that the implementation is just missing. Those fake functions are unacceptable.
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.
I appreciate this.
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.
Next release means the one that comes after the next merge window.
Best regards,
Wolfgang Denk