From owner-freebsd-mips@FreeBSD.ORG Thu Feb 11 17:13:46 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E683A1065692 for ; Thu, 11 Feb 2010 17:13:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A3F898FC0A for ; Thu, 11 Feb 2010 17:13:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o1BH5P3O030706; Thu, 11 Feb 2010 10:05:26 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 11 Feb 2010 10:05:30 -0700 (MST) Message-Id: <20100211.100530.390080239494612674.imp@bsdimp.com> To: rrs@lakerest.net From: "M. Warner Losh" In-Reply-To: References: <5709963B-3F83-44FE-991F-A3227A2052DC@lakerest.net> <98a59be81002110655y60ab4e8cj473f4b6ecf6f5ae4@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hzou@netlogicmicro.com, jayachandranc@netlogicmicro.com, freebsd-mips@FreeBSD.org Subject: Re: RMI status X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:13:47 -0000 cj> Any plan of doing n32? n32 with 64-bit physical address support may cj> be a better suited base configuration for XLR than o32, because we can cj> use all of the memory and the 64 bit support, without having to go cj> full 64-bit. rrs>Not sure.. Warner, what do you think.. should we mess with n32? My plans are to mine the Cavium port for n32 and n64 support. I've done some preliminary work on this, and it doesn't look too horrible. I do think there's a place to do both n32 as well as n64 in this system. Either one, in the kernel, could more easily access the hardware on Octeon (and I think XLR) that has a bunch of funky bits set in the higher bits and is too sparse to be covered by one wired TLB entry. I have no plans to support the so-called 'o64' mode or the 'o32 with 64-bit registers' mode of operation. I'd like to retire the 'let's run an o32 binary in 64-bit mode while in the kernel' mode that we're using for Octeon right now. It is useful as a bootstrap, but just a little too non-standard for my tastes. We'll get better compiler support if we don't try to do unnatural things like this anyway. Warner