From owner-freebsd-mips@FreeBSD.ORG Thu Feb 11 17:59:49 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 5D1211065745 for ; Thu, 11 Feb 2010 17:59:49 +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 F2AB88FC1A for ; Thu, 11 Feb 2010 17:59:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o1BHm7bP031261; Thu, 11 Feb 2010 10:48:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 11 Feb 2010 10:48:12 -0700 (MST) Message-Id: <20100211.104812.1151951657390788673.imp@bsdimp.com> To: c.jayachandran@gmail.com From: "M. Warner Losh" In-Reply-To: <98a59be81002110931h2fd2c250heec0520860768689@mail.gmail.com> References: <20100211.100530.390080239494612674.imp@bsdimp.com> <98a59be81002110931h2fd2c250heec0520860768689@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=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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:59:49 -0000 In message: <98a59be81002110931h2fd2c250heec0520860768689@mail.gmail.co= m> "C. Jayachandran" writes: : On Thu, Feb 11, 2010 at 10:35 PM, M. Warner Losh wro= te: : > : > cj> Any plan of doing n32? =A0n32 with 64-bit physical address supp= ort 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. =A0I'= ve : > done some preliminary work on this, and it doesn't look too horribl= e. : > I do think there's a place to do both n32 as well as n64 in this : > system. =A0Either 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 wit= h : > 64-bit registers' mode of operation. =A0I'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. =A0It is useful as a bootstrap, but jus= t a : > little too non-standard for my tastes. =A0We'll get better compiler= : > support if we don't try to do unnatural things like this anyway. : = : The FreeBSD 6 port to XLR was o64. Even in o32/o64, it is useful to : go enable 64bit mode in kernel (with KX bit and maybe XTLB handler) : since you can access the whole physical memory and IO without using : TLB entries. Yes. That's similar to what the Octeon port does: it compiles everything o32, including the kernel, but runs the kernel with KX bit set with an xtlb handler. On other MIPS ports, usually the I/O space is mapped into one TLB that's wired into place. Since the address space is so sparse on Octeon (and XLR?), this isn't a viable option, so doing what we're doing now is the only other alternative. : Is the plan to have full n32 (including userspace), or have : compatibility code to run o32 userspace on n32 kernel? I guess I : should have a look at the current support.... The plan is to support n32 and n64 user space binaries with an n32 or n64 kernel. The future o32 support is TBD. In other projects, I've run into tool-chain issues with o32 code for complex shared library arrangements (but this may have also been a SysV style binary vs a SGI style binary too). The in-tree MIPS toolchain is adequate, but likely we'd be better off upgrading. Warner