Wolfgang Denk wrote:
In message c166aa9f0803171655q7820858aoaa48b56ad57525c2@mail.gmail.com you wrote:
Isn't the lock necessary to use the cache as memory for stack and initial data?
Thanks, now I understand the original concept of this locking.
But from the technical POV; looking at start.S, mips_cache_lock() is processed after lowlevel_init. SDRAM is already available at this point, therefore we can use true memory for stack. No lock is needed I think.
# The reason why we have this order is that, cache initialization needs memory itself (this is used by Fill operation for I-cache, and load instruction for D-cache). This conflicts the original mips_cache_lock purpse, doesn't it?
IIRC, some MIPS cache implementations require valid zeroed RAM to init cache parity correctly.
Ah, summarized in 2 lines.
The cache never gets unlocked, so the code relies on whatever gets loaded after u-boot to reinitialize the cache and clear the locks.
And I have to say this is important. IMHO most U-Boot MIPS users must disable this locking due to above reasons. I've disabled for long time since 1.1.X (our boards initial porting), too.
But simply deleting it is definitely not a good idea, as it would most probably break existing board support.
I still think this removal will not break any existing targets, but yes agreed. I'll try to introduce a #ifdef alternative.
Thanks for your comments,
Shinya