From owner-freebsd-mips@FreeBSD.ORG Thu Jun 10 22:33:37 2004 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A55A16A4CE; Thu, 10 Jun 2004 22:33:37 +0000 (GMT) Received: from mail.linux-mips.net (p508B6474.dip.t-dialin.net [80.139.100.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69BAB43D49; Thu, 10 Jun 2004 22:33:35 +0000 (GMT) (envelope-from ralf@linux-mips.org) Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5AMXHuC017156; Fri, 11 Jun 2004 00:33:17 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5AMXHhs017155; Fri, 11 Jun 2004 00:33:17 +0200 Date: Fri, 11 Jun 2004 00:33:17 +0200 From: Ralf Baechle To: juli mallett Message-ID: <20040610223317.GA16814@linux-mips.org> References: <20040610090712.GA71925@FreeBSD.org> <20040610160207.GB32315@linux-mips.org> <20040610221430.GA26579@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040610221430.GA26579@FreeBSD.org> User-Agent: Mutt/1.4.1i cc: Gheorghe Ardelean cc: freebsd-mips@FreeBSD.org Subject: Re: Some MIPS status goodies. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 22:33:37 -0000 On Thu, Jun 10, 2004 at 12:14:30PM -1000, juli mallett wrote: > > > R10K and IP28 support are probably a ways away, but I'm interested > > > in supporting these systems and more. Right now it's easiest to start > > > with the, much simpler, R4400 Indigo2 I have here, and get a good base > > > of this stuff, then move into supporting the more modern and complex > > > CPUs and machines - but be assured I am taking them into account! > > > > R10000 in non-coherent systems (Indigo 2 R10000, O2) is a rather hard to > > use processor due to unwanted behaviour of speculative execution that > > leads to memory corruption. The workarounds are fairly complex; efficient > > solutions involve compiler modifications. > > Yeah, I read about the compiler mods SGI had to make, with accessing > the stack as a barrier... It sounded like that was only for the > kernel though, yeah? Yes. The CPU can't speculate memory access for virtual addresses that aren't mapped, so for usermode the trick is to keep every page unmapped while doing DMA on it. Ralf