[Top] [All Lists]

Re: Porting To New System

To: Cameron Cooper <>
Subject: Re: Porting To New System
From: Ralf Baechle <>
Date: Sat, 28 May 2005 20:27:04 +0100
Cc: Alan Cox <>, Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
In-reply-to: <1117294983.2800.12.camel@phatbox>
Original-recipient: rfc822;
References: <> <1117217584.5743.229.camel@localhost.localdomain> <1117223539.2921.15.camel@phatbox> <1117237244.5744.284.camel@localhost.localdomain> <1117294983.2800.12.camel@phatbox>
User-agent: Mutt/1.4.1i
On Sat, May 28, 2005 at 11:43:03AM -0400, Cameron Cooper wrote:

> It looks like Xiptech only did a port for R3K, which is no good for me.
> The issue that I'm running into right now is in
> arch/mipsnommu/mm/c-r4k.c

Sort of amusing to make that a separate architecture - TLB or not, the
remainder of the CPU stays pretty much the same.

> I guess the problem is that it is trying to use things which belong to
> the MM code, which are not included from mm.h becuase NO_MM is set.
> c-r3k.c was rewritten for NO_MM, but not c-r4k.c. I looked into
> rewriting c-r4k.c by taking ideas from c-r3k.c but unfortunatly they are
> not similar enough, and I'm afraid I'm not even sure what this file
> does.

The key feature of R4000 caches that causes alot of complexity in the
c-r4k code is that it needs to handle virtually indexed caches, especially
avoid cache aliases.  On a TLB-less processors aliases are not possible,
thus c-r4k.c can be significantly simplified making it quite a bit more
similar to c-r3k.c.

> Can you help me understand what this file does, and what I might
> do to rewrite it for NO_MM?

Your question would require a very long answer to be somewhat exhaustive,
so here the express version.  Start by reading Documentation/cachetlb.txt
from the kernel sources.  You can find plenty of discussions related to
this code in the linux-mips and linux-kernel archives - especially the
subtle points aren't exactly documented ;-)


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