Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
