In message <[EMAIL PROTECTED]> 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
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
I object to intellect without discipline; I object to power without
constructive purpose.
-- Spock, "The Squire of Gothos", stardate 2124.5
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
