[Top] [All Lists]

Re: Can't build a CONFIG_CPU_NEVADA kernel

To: Ralf Baechle <>
Subject: Re: Can't build a CONFIG_CPU_NEVADA kernel
From: Daniel Jacobowitz <>
Date: Wed, 14 Mar 2001 15:56:17 -0500
In-reply-to: <>; from on Wed, Mar 14, 2001 at 08:20:58PM +0100
References: <> <> <> <>
User-agent: Mutt/1.3.16i
On Wed, Mar 14, 2001 at 08:20:58PM +0100, Ralf Baechle wrote:
> On Wed, Mar 14, 2001 at 02:05:29PM -0500, Daniel Jacobowitz wrote:
> > OK, so that needs to change.  That's pretty easy to do, at least in our
> > local toolchains.
> If it's only in your local toolchains, it's lost.  Send your changes to
> the FSF!

Of course.  Let me clarify that statement - it's easy to do in a way
that would be acceptable in our local toolchains, and somewhat harder
to do in a way acceptable to the FSF.

In this case, though, not much harder.  I'm going to try to have a
-mmad patch later today for binutils, and a trivial patch for GCC to
use it instead of -m4650.

> > If it does, I can probably whip up a -mmad patch to binutils to allow
> > those opcodes - or I could introduce -mnevada, or whatever the
> > appropriate term would be, to mean "r8000 with the mad* extensions". 
> > In fact, that would probably be easiest, and sounds like the most
> > correct.
> Don't think of the r8000; the kernel only uses the -mcpu=r8000 option
> because the Nevada CPUs have _somewhat_ similar scheduling properties
> to the R8000.  This of it as an independant ISA expension which can
> be used with an arbitrary MIPS processor - even a R3000 processor.

Oh, I see.  Thanks for the clarification.

Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team
                         "I am croutons!"

<Prev in Thread] Current Thread [Next in Thread>