From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 04:08:16 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 1BC3B1065672; Tue, 2 Mar 2010 04:08:16 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E02628FC0A; Tue, 2 Mar 2010 04:08:15 +0000 (UTC) Received: by pwj1 with SMTP id 1so649163pwj.13 for ; Mon, 01 Mar 2010 20:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2YDSpMKKXcHkjKM9TnYbnmQg7s6gMqZQfJmKpTY2FcU=; b=Hpwr/+gImmT91DDAgVeQ3bMf6G6DsBtAQaXXdxYJFfquh8iShzvuElk8+j4ydxZ3gZ 6rPQiTKxDqE8MlGnoZd9v2uYezplBTgAeIsmaGYrDMd4O1ZH4nSuqx8v7O2mpAC4ZlcN DTwknIYPY+J6vaCZwmXAhEWogOAmPRgb5KLC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tCep8shF6dhRzcHgM9rpDsHKBbCHk8DEAI0M4rBz5H3OQUiNpOZalrl4aNXIEC/k2p buHgO7tdJszKhf2VK8ApEdHKFkQsnFB2XZ1ycRG2cYiLBiBH7x9wngm53+fE//q+IJoq droSA3Un9YlMX5zI8cuNciy70oC2hrjzUTK9E= MIME-Version: 1.0 Received: by 10.141.108.8 with SMTP id k8mr3035875rvm.102.1267502893117; Mon, 01 Mar 2010 20:08:13 -0800 (PST) In-Reply-To: References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> Date: Tue, 2 Mar 2010 09:38:13 +0530 Message-ID: <98a59be81003012008y5b294094mc7139dd96836fa04@mail.gmail.com> From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: n32 support patches 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: Tue, 02 Mar 2010 04:08:16 -0000 On Tue, Mar 2, 2010 at 1:07 AM, Juli Mallett wrote: > On Mon, Mar 1, 2010 at 06:28, C. Jayachandran = wrote: >> I'm in the process of getting n32 ABI support for the RMI processors. >> The plan is have n32 compiled kernel with 64-bit register_t and >> physaddr_t and 32 bit long and pointer types. > > Hi JC, > > I've been working on this too in my user/jmallett/octeon branch in > Subversion and have gotten past some of the problems you mention, but > not always in the cleanest of ways. =A0I switched to using the libgcc > softfloat implementation instead of the libc one, for example, and > have committed some changes from Warner to libc's abicalls support. =A0I > am currently running with a static root filesystem to track down some > bugs with syscalls (I think just the ones with lots of arguments, i.e. > the ones we need to do copyin to get; or maybe it's the bogus quad > stuff, I don't know yet =97 the day is young) before moving on to fixing > the problems with dynamic linking. =A0If there's any way to coordinate > our efforts and you'd like to, let me know! I was not aware of this, thanks for the update. I will have a look at this branch. > One thing I will say is that I've been talking with Warner and we > think that n32 kernels are probably a pretty bad idea =97 a lot of the > system depends on pointers being the same width as registers, etc. > Neither of us could really think of a case where you'd want an n32 > kernel instead of an n64 kernel except for the case where your > bootloader just can't handle ELF64, in which case a trampoline or an > n32/o32 loader which can load ELF64 seems more beneficial. =A0Do you > have a use case in mind, or is it just that n32 is an easier target > than n64? (I saw similar comments from Warner and Randall too, but I will reply here) My own final target is to have n64 support for XLR - I see n32 is just a first useful step in that direction. But I think the easiest way is to go n32 -> n32+64bit phys -> n64. The first step n32 will work out the ABI issues as it is very similar to n64. A lot of the initial kernel changes (for 64 bit registers, ABI support for system calls and signal handling) and user-space (ABI support for system call/ld.so etc) can be worked out here. n32+64bit phys will hopefully work out the next level of issues(TLB/page table entries). From there n64 will be getting the 64bit pmap and working out 64-bit compilation. Also I think it will be useful to have an advanced 32 bit option for mips64 and better architectures. o32 is inefficient in processors supporting mips64 instruction set (64 bit operations are split instead of using 64 bit operations). And some customers we talked to have large amounts of probably-not-64-bit-clean source code, so a 32 bit option is always useful. On the 64-bit registers and 32-bit pointers issues - RMI's initial port was o64 and 64 bit physical addres We did not have many issues in the main kernel. The intel PAE mode, which seems to be supported has a similar setup (32bit with 64bit physical addr) was already supported in kernel, so our effort was minimal here. So overall, I think of n32 as a useful thing, and I don't think there will be any additional code just for n32 because it should be a subset of n64 support. Regards, JC.