In message <[EMAIL PROTECTED]> you wrote: > > > Isn't the lock necessary to use the cache as memory for stack and > > initial data? > > This code has some problems: > > Cache locking is not consistent across MIPS implementations. Some > implementations do not support locking at all. The style of locking > varies - some support per line locking, others per way, etc, etc. > Some parts use bits in status registers instead of the cache ops. > > IIRC, some MIPS cache implementations require valid zeroed RAM to init > cache parity correctly. > > The cache never gets unlocked, so the code relies on whatever gets > loaded after u-boot to reinitialize the cache and clear the locks.
This is most probably true. When this code was implemented first, it was most probably with a single CPU in mind. But simply deleting it is definitely not a good idea, as it would most probably break existing board support. 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] "In the long run, every program becomes rococo, and then rubble." - Alan Perlis ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/u-boot-users
