public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [RFC][MIPS] Remove mips_cache_lock
Date: Tue, 18 Mar 2008 21:56:14 +0900	[thread overview]
Message-ID: <47DFBBEE.1090006@ruby.dti.ne.jp> (raw)
In-Reply-To: <20080318002849.224C3246C5@gemini.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

  reply	other threads:[~2008-03-18 12:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-17 14:42 [U-Boot-Users] [RFC][MIPS] Remove mips_cache_lock Shinya Kuribayashi
2008-03-17 21:04 ` Wolfgang Denk
2008-03-17 23:55   ` Andrew Dyer
2008-03-18  0:28     ` Wolfgang Denk
2008-03-18 12:56       ` Shinya Kuribayashi [this message]
2008-03-18 13:47         ` Shinya Kuribayashi
2008-03-21 13:45           ` Shinya Kuribayashi
2008-03-24  2:29             ` Andrew Dyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47DFBBEE.1090006@ruby.dti.ne.jp \
    --to=skuribay@ruby.dti.ne.jp \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox