From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Date: Tue, 18 Mar 2008 21:56:14 +0900
Subject: [U-Boot-Users] [RFC][MIPS] Remove mips_cache_lock
In-Reply-To: <20080318002849.224C3246C5@gemini.denx.de>
References: <20080318002849.224C3246C5@gemini.denx.de>
Message-ID: <47DFBBEE.1090006@ruby.dti.ne.jp>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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