On Monday 21 April 2008, Wolfgang Denk wrote:
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.
I'm not so sure here anymore with all the newer PPC's and other platforms. But I have to admit that I'm no expert for those other platforms.
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).
Another problemtic issue could be the POST area for caches etc. I know that self modifying code is used here in some places. This could be more problematic with caches enabled.
<snip>
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.
I did understand this part of the sentence. I'm just not sure what should happen with the current code if it doesn't get changed. Again, I personally can't promise to "fix" this issue until the next merge window opens.
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 =====================================================================