Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralph Metzler" <rjkm@metzlerbros.de>, "Bob Lund" <bob.lund@visi.com>
Cc: <linux-mips@linux-mips.org>
Subject: Re: Linux on LSI SC2005
Date: Mon, 18 Nov 2002 09:58:15 +0100	[thread overview]
Message-ID: <007301c28ee0$cb2eb6d0$10eca8c0@grendel> (raw)
In-Reply-To: 15832.25401.226111.893020@gargle.gargle.HOWL

From: "Ralph Metzler" <rjkm@metzlerbros.de>
> Hi, 
> 
> Bob Lund writes:
>  > I'm trying to figure out how much effort would be involved in getting Linux
>  > running on the MIPS core found in the LSI Logic SC2005. According to the LSI
>  > documentation:
>  > 
>  > MIPS R3000 CPU, executing MIPS I & II and 16 instructions
>  > BBCC with four write back buffers included
>  > Two 32-bit timers
>  > MMU 64-entry TLB RAM
>  > 1 to 32 Kbytes of direct mapped or 2 to 64 Kbytes of set associative I-cache
>  > 1 to 32 Kbytes of direct mapped D-cache
>  > 
>  > Any information is appreciated.
> 
> I did some work on an SC2000 about 18 months ago but only for one or two
> weeks. The kernel and networking on the eval board was basically
> working then but, AFAIR, there were problems (as in total lock up) with 
> enabled cache in user mode. Without cache it was veeeeery slow.

I don't have documentation on the SC2000, so I had hesitated
to respond to the question, but I can at least make the general
comment that LSI put a lot of different cache and MMU designs
around the basic R3000 execution pipe.  Some of those were
close enough to the original R3000 design to be easily supported
by Linux, others less so.  The MMU is the nastiest part of the problem,
so if you managed to get Linux running uncached, I am more
optimistic than I would otherwise be.  The LSI cores for which
I do have documantation use a non-standard mechanism
(an explicit cache control register in the System Coprocessor)
for cache management.  I would not be surprised if the SC2000
used much the same techniques, and if so, it would be necessary
to either hack up arch/mips/mm/c-r3k.c or (better software
engineering but more work) create arch/mips/mm/c-sc2k.c
with the SC2000 cache manipulation routines and add the
necessary configuration hooks to use it for your build.

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Ralph Metzler <rjkm@metzlerbros.de>, Bob Lund <bob.lund@visi.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Linux on LSI SC2005
Date: Mon, 18 Nov 2002 09:58:15 +0100	[thread overview]
Message-ID: <007301c28ee0$cb2eb6d0$10eca8c0@grendel> (raw)
Message-ID: <20021118085815.Ib7251njLped2IGAjco0l31CdlyoWkl43yJszHuAf1M@z> (raw)
In-Reply-To: 15832.25401.226111.893020@gargle.gargle.HOWL

From: "Ralph Metzler" <rjkm@metzlerbros.de>
> Hi, 
> 
> Bob Lund writes:
>  > I'm trying to figure out how much effort would be involved in getting Linux
>  > running on the MIPS core found in the LSI Logic SC2005. According to the LSI
>  > documentation:
>  > 
>  > MIPS R3000 CPU, executing MIPS I & II and 16 instructions
>  > BBCC with four write back buffers included
>  > Two 32-bit timers
>  > MMU 64-entry TLB RAM
>  > 1 to 32 Kbytes of direct mapped or 2 to 64 Kbytes of set associative I-cache
>  > 1 to 32 Kbytes of direct mapped D-cache
>  > 
>  > Any information is appreciated.
> 
> I did some work on an SC2000 about 18 months ago but only for one or two
> weeks. The kernel and networking on the eval board was basically
> working then but, AFAIR, there were problems (as in total lock up) with 
> enabled cache in user mode. Without cache it was veeeeery slow.

I don't have documentation on the SC2000, so I had hesitated
to respond to the question, but I can at least make the general
comment that LSI put a lot of different cache and MMU designs
around the basic R3000 execution pipe.  Some of those were
close enough to the original R3000 design to be easily supported
by Linux, others less so.  The MMU is the nastiest part of the problem,
so if you managed to get Linux running uncached, I am more
optimistic than I would otherwise be.  The LSI cores for which
I do have documantation use a non-standard mechanism
(an explicit cache control register in the System Coprocessor)
for cache management.  I would not be surprised if the SC2000
used much the same techniques, and if so, it would be necessary
to either hack up arch/mips/mm/c-r3k.c or (better software
engineering but more work) create arch/mips/mm/c-sc2k.c
with the SC2000 cache manipulation routines and add the
necessary configuration hooks to use it for your build.

            Kevin K.

  parent reply	other threads:[~2002-11-18  8:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-17 16:33 Linux on LSI SC2005 Bob Lund
2002-11-17 16:33 ` Bob Lund
2002-11-18  3:49 ` Ralph Metzler
2002-11-18  3:49   ` Ralph Metzler
2002-11-18  8:58   ` Kevin D. Kissell [this message]
2002-11-18  8:58     ` Kevin D. Kissell

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='007301c28ee0$cb2eb6d0$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=bob.lund@visi.com \
    --cc=linux-mips@linux-mips.org \
    --cc=rjkm@metzlerbros.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