Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: David VomLehn <dvomlehn@cisco.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, joe seb <joe.seb8@gmail.com>,
	linux-mips@linux-mips.org
Subject: Re: Linux port failing on MIPS32 24Kc
Date: Wed, 8 Jul 2009 20:11:05 +0100 (BST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0907081946240.13862@eddie.linux-mips.org> (raw)
In-Reply-To: <20090708182500.GA31285@cuplxvomd02.corp.sa.net>

On Wed, 8 Jul 2009, David VomLehn wrote:

> > (Why do people use non-zero starting addresses for memory?  Handling of
> > cache error exceptions is hard enough as it is but with no memory in the
> > low 32k the design idea of the cache architecture that stores relative to
> > $zero can be used goes down the drain and (not considering platform-specific
> > solutions here) only be handled by burning the scarce resource of a TLB
> > entry for an extremly rare event ...)
> 
> (Because hardware people are, uh, insufficiently acquainted with the MIPS
> architecture and don't know what the conventions are. Or why they are that
> way. Then, you're stuck with that architecture forever. Sigh.)

 Many processor architectures have assumptions (i.e. power-up/reset 
defaults) about or even force the existence of RAM at physical address 0.  
With the MIPS architecture actually it has been pretty a recent addition 
in its long history that you are able to get away without.  Given these 
circumstances I am afraid your suspicion sounds like an understatement.

 With the MIPS64r2 architecture though and if you want more than 400+some 
MB of memory, placing RAM from the top of the physical address space seems 
more reasonable to me as you can avoid ROM popping up in the middle then.  

 For the sake of flexibility, including but not limited to ERL operation, 
the virtual-to-physical address translation for the CKSEG0 and CKSEG1 
space could be made configurable via an additional CP0 register.  I'm a 
little bit surprised nobody had thought about it at the time CP0.EBase was 
introduced.  The remapping has to be done anyway and it does not look to 
me as it would take a lot of power and/or silicon space to make it use a 
configurable set of latches rather than a predefined set of hardwired 
logical levels.

  Maciej

  reply	other threads:[~2009-07-08 19:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-08  8:07 Linux port failing on MIPS32 24Kc joe seb
2009-07-08 10:37 ` Ralf Baechle
2009-07-08 12:47   ` joe seb
2009-07-08 18:29     ` David VomLehn
2009-07-09 11:05       ` joe seb
2009-07-12 10:39         ` Eugene Surovegin
2009-07-08 18:25   ` David VomLehn
2009-07-08 19:11     ` Maciej W. Rozycki [this message]
2009-07-13 14:47   ` joe seb

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=alpine.LFD.2.00.0907081946240.13862@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=dvomlehn@cisco.com \
    --cc=joe.seb8@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /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