[U-Boot-Users] [RFC][MIPS] Remove mips_cache_lock

Shinya Kuribayashi skuribay at ruby.dti.ne.jp
Tue Mar 18 13:56:14 CET 2008


Wolfgang Denk wrote:
> In message <c166aa9f0803171655q7820858aoaa48b56ad57525c2 at 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





More information about the U-Boot mailing list