From owner-freebsd-mips@FreeBSD.ORG Mon Mar 1 05:17:28 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 348E01065695; Mon, 1 Mar 2010 05:17:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D95AB8FC14; Mon, 1 Mar 2010 05:17:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o215HRxI026159; Mon, 1 Mar 2010 00:17:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o215HRXw026153; Mon, 1 Mar 2010 05:17:27 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 1 Mar 2010 05:17:27 GMT Message-Id: <201003010517.o215HRXw026153@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 05:17:28 -0000 TB --- 2010-03-01 04:30:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-01 04:30:50 - starting HEAD tinderbox run for mips/mips TB --- 2010-03-01 04:30:50 - cleaning the object tree TB --- 2010-03-01 04:30:59 - cvsupping the source tree TB --- 2010-03-01 04:30:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-03-01 04:33:31 - building world TB --- 2010-03-01 04:33:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-01 04:33:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-01 04:33:31 - TARGET=mips TB --- 2010-03-01 04:33:31 - TARGET_ARCH=mips TB --- 2010-03-01 04:33:31 - TZ=UTC TB --- 2010-03-01 04:33:31 - __MAKE_CONF=/dev/null TB --- 2010-03-01 04:33:31 - cd /src TB --- 2010-03-01 04:33:31 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 1 04:33:32 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DUSE_BSM_AUDIT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -o su su.o -lutil -lpam -lbsm gzip -cn /src/usr.bin/su/su.1 > su.1.gz ===> usr.bin/systat (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DINET6 -std=gnu99 -Wno-pointer-sign -c /src/usr.bin/systat/cmds.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DINET6 -std=gnu99 -Wno-pointer-sign -c /src/usr.bin/systat/cmdtab.c In file included from /src/usr.bin/systat/extern.h:39, from /src/usr.bin/systat/cmdtab.c:43: /obj/mips/src/tmp/usr/include/kvm.h:72: error: expected declaration specifiers or '...' before 'u_int' *** Error code 1 Stop in /src/usr.bin/systat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-01 05:17:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-01 05:17:27 - ERROR: failed to build world TB --- 2010-03-01 05:17:27 - 1933.53 user 451.70 system 2796.39 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Mon Mar 1 14:28:23 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 33BDB1065670 for ; Mon, 1 Mar 2010 14:28:23 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-px0-f198.google.com (mail-px0-f198.google.com [209.85.216.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1C48FC13 for ; Mon, 1 Mar 2010 14:28:22 +0000 (UTC) Received: by pxi36 with SMTP id 36so1033069pxi.13 for ; Mon, 01 Mar 2010 06:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=jzt5jhm8K8VO8R4T3yDr/BHpEOsQVb5adRIDRXbEzm8=; b=hFT4u++o/xe78CbMR4bVWukE31pHR0FWZbz+ETZQNLKzrMrBSMrDYsYpTfX1Vj5mEQ drfbURx1/HrX5l+ws9OZw86yQEgT1YJLs2wDyCMiOh+AT0vEIFimaF2ikcfoTF2e34YH voCYS/HQ/RU7VKeJ/oqPs3aoBm7WITMR1bsOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=G0HIcprSdsueDyNsbHy7Dbt3d2lv8TfC8XKoD+9dKX2bIoBowChH/xAfycUHdpQ+Nq TvjxQYJnaE/IaP7uDalDJJXbQOiiYvNWEoLQAIaR1H+R+d4HILkzL+OygxXaFFXdhR5+ Yo4l5jALJ7CVVkV24GW2bzYp5SzY5PkWj3iKI= MIME-Version: 1.0 Received: by 10.141.125.9 with SMTP id c9mr2544153rvn.36.1267453698432; Mon, 01 Mar 2010 06:28:18 -0800 (PST) Date: Mon, 1 Mar 2010 19:58:18 +0530 Message-ID: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> From: "C. Jayachandran" To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: 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: Mon, 01 Mar 2010 14:28:23 -0000 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. I've attached two patches, one for support for n32 in toolchain and one for n32 support in kernel compilation. With this I am able to compile the kernel and user space with n32, and the boot-up reaches until init. There is a lot more work on user-space and kernel (esp in mips/mips/*.S) before it can complete boot-up. Please review and let me know if you have any comments or objections on this approach. The patches are: http://sites.google.com/site/cjayachandran/files/n32-toolchain.patch Toolchain support for N32 - Adds the linker emulations needed for n32 - Common preprocessor defines for ABI (_ABI_MIPS_SIM and _ABI???). - Sets the long double type as 64 bit (this should be 128 bit in n32, but there is some work needed to get the 128 bit soft-float working). http://sites.google.com/site/cjayachandran/files/n32-kernel.patch N32 compilation - makefiles and conf - Adds ldscript.mips.n32. - Some cleanup in Makefile.mips, add ABI flags - bsd.cpu.mk CFLAGS for n32 compilation and linking I have introduced a TARGET_N32 similart to TARGET_64 for n32 compilation. But I think on the long term, we need clean up the different flags that affect architecture and ABI. Currently there is an overlap between the TARGET_CPUTYPE flag, the ISA_ flags and the TARGET_ flags. Regards, JC. From owner-freebsd-mips@FreeBSD.ORG Mon Mar 1 14:32:58 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 35CA81065670 for ; Mon, 1 Mar 2010 14:32:58 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0548FC16 for ; Mon, 1 Mar 2010 14:32:57 +0000 (UTC) Received: by pzk36 with SMTP id 36so3682pzk.8 for ; Mon, 01 Mar 2010 06:32:52 -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; bh=eV2p9ORSoR+LQRnTMHy1o9EMr4omE1s5oR0EEqbuOiY=; b=gvNEdjqTIcm6mIPSrcqXX/P5EAR4zEpaOFHZ95rJG2Lt7gEllKuXygWWPAnYHRtGOa T/UfzozkCEof9lKmfC+NaUwPOhyAYinuyFLE06T5muJzikmklMoxdwx/c78oJHe84Y/P czSkKMZMHzzF76wwwdLsGPrsF5f++5Zp1z32o= 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; b=eKmNGSNmMQ6fgkmov4To4VQDFL1sbdiCixZK4AXmXLbLCbwHLIwrgLpN8OIa5OAlHc 9XAJUKlpCLOVIqr/0zdDSFiToeFGkDsB3BLlxAySnYB1ubzkQpza/sju182JPWCln6p3 QXeSJpEiIifMUayDM2hvTNc4jZgHLR4A57sFY= MIME-Version: 1.0 Received: by 10.141.213.4 with SMTP id p4mr2489348rvq.159.1267453971888; Mon, 01 Mar 2010 06:32:51 -0800 (PST) In-Reply-To: <98a59be81002230021j6a0cc408j99fe6a5d57a21aff@mail.gmail.com> References: <98a59be81002230021j6a0cc408j99fe6a5d57a21aff@mail.gmail.com> Date: Mon, 1 Mar 2010 20:02:51 +0530 Message-ID: <98a59be81003010632n526acfd0i57c58bca8645d62@mail.gmail.com> From: "C. Jayachandran" To: Randall Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: USB support for RMI processors 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: Mon, 01 Mar 2010 14:32:58 -0000 Hi Randy, I'd send these patches last week, did you get a chance to look over them? Let me know if you have any comments. Also, let me know if this is your preferred way for changes, otherwise I can send them as attachments too. The mailing list will strip the attachments, but your copy would be safe. Thanks, JC. On Tue, Feb 23, 2010 at 1:51 PM, C. Jayachandran wrote: > I've two patches to add USB EHCI support for XLS processors. This is tested > with umass driver on a USB attached disk and flash drive. Please review - > I've left the original NetBSD license on xls_ehci.c (which came from > ehci_pci.c), I hope this is not an issue. > > http://sites.google.com/site/cjayachandran/files/iodi-bus.patch > - Move rmi_pci_bus_space to header and avoid extern > - remove unused and commented code (MIPS_BUS_SPACE_PCI, pic_usb_ack) > - use rmi_pci_bus_space for USB too (needs byteswap) > > http://sites.google.com/site/cjayachandran/files/xls-ehci.patch > - uncomment xls_ehci.c in files.xlr > - changes to xls_ehci.c - updated with dev/usb/controller/ehci_*.c as > reference > > The files sys/mips/rmi/ehcireg.h and sys/mips/rmi/ehcivar.h can be deleted > since they are not used now. Also sys/mips/rmi/pcibus.c is unused. > > Thanks, > JC. > -- C. Jayachandran c.jayachandran@gmail.com From owner-freebsd-mips@FreeBSD.ORG Mon Mar 1 19:38:23 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 690AC106564A for ; Mon, 1 Mar 2010 19:38:23 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB598FC0C for ; Mon, 1 Mar 2010 19:38:22 +0000 (UTC) Received: by ewy26 with SMTP id 26so1548747ewy.3 for ; Mon, 01 Mar 2010 11:38:17 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.102.14.3 with SMTP id 3mr3904960mun.90.1267472295132; Mon, 01 Mar 2010 11:38:15 -0800 (PST) In-Reply-To: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> From: Juli Mallett Date: Mon, 1 Mar 2010 11:37:54 -0800 X-Google-Sender-Auth: 3dab08f1011b1950 Message-ID: To: "C. Jayachandran" 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: Mon, 01 Mar 2010 19:38:23 -0000 On Mon, Mar 1, 2010 at 06:28, C. Jayachandran wr= ote: > 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. I 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. I 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. If there's any way to coordinate our efforts and you'd like to, let me know! 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. Do you have a use case in mind, or is it just that n32 is an easier target than n64? Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Mon Mar 1 20:57:55 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 6A66B106564A for ; Mon, 1 Mar 2010 20:57:55 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f183.google.com (mail-iw0-f183.google.com [209.85.223.183]) by mx1.freebsd.org (Postfix) with ESMTP id 2E7AB8FC08 for ; Mon, 1 Mar 2010 20:57:54 +0000 (UTC) Received: by iwn13 with SMTP id 13so3316431iwn.14 for ; Mon, 01 Mar 2010 12:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ezryxrcWiIb637lxeD3Spc9O+fTJ0eBpULw/p4Gf9bs=; b=iPY2UMnxZlbA1RI/8kRvgIHsV8pPCNhdL/ug29NOUV/B7TdBTcv2MHNFFuAasy47mO APsih0t+pQQgL7YYIxcUaGJkfO+wWcCmE3tQtPEA7fqVmZdhtvv+rVXrUrnYcDEbSx42 UMG1stn+zr5HWbunlfju5uhsSorts0D+B0fak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TBy6UqQPWTEbFSCk3ckBtRV5xHjAKsoWvjvFGxd1nizPfc28NrXwz9kQ1dHw/psZX3 JO59RoHjeTD1bkgiIIJRaUv/pZ0boldGOJZ+IeQjQ0sGWgLTFbxPNs5EbeZJib4gCzri vcmK1NMeG76sFHQLX6eu2NlM2bnoa0wXe4qaM= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.147.148 with SMTP id l20mr208352ibv.77.1267475419924; Mon, 01 Mar 2010 12:30:19 -0800 (PST) In-Reply-To: References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> Date: Mon, 1 Mar 2010 12:30:19 -0800 X-Google-Sender-Auth: ec53659eaea63b7d Message-ID: From: Artem Belevich 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: Mon, 01 Mar 2010 20:57:55 -0000 n32 could be helpful when one has a lot of third-party code that's not 64-bit clean. It may also be arguably a bit more efficient than n64 as 32-bit pointers would result in smaller structures and thus less cache thrashing. It's hard to tell, though whether the difference is large enough to be worth bothering with. Does anyone know of any benchmark results comparing n32 vs. n64? In any case, those are marginal factors. I do believe than n64 kernel is the way to go. BTW, Some of 64-bit inefficiencies can be mitigated with -msym32: http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=3DAttac= hFile&do=3Dget&target=3Dnew-tricks-mips-linux.pdf --Artem On Mon, Mar 1, 2010 at 11:37 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! > > 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? > > Thanks, > Juli. > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-mips@FreeBSD.ORG Mon Mar 1 21:23:18 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 88413106566C; Mon, 1 Mar 2010 21:23:18 +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 2ECDA8FC1A; Mon, 1 Mar 2010 21:23:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o21LEZAG051767; Mon, 1 Mar 2010 14:14:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 01 Mar 2010 14:14:51 -0700 (MST) Message-Id: <20100301.141451.72112000461331978.imp@bsdimp.com> To: fbsdlist@src.cx From: "M. Warner Losh" In-Reply-To: References: <98a59be81003010628g6099768erc397bc90841840f8@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=utf-8 Content-Transfer-Encoding: base64 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: Mon, 01 Mar 2010 21:23:18 -0000 SW4gbWVzc2FnZTogPGVkOTFkNGE4MTAwMzAxMTIzMGoxNTMwMTg4ZHU0NDViY2RkM2FiMGUxOWNl QG1haWwuZ21haWwuY29tPg0KICAgICAgICAgICAgQXJ0ZW0gQmVsZXZpY2ggPGZic2RsaXN0QHNy Yy5jeD4gd3JpdGVzOg0KOiBuMzIgY291bGQgYmUgaGVscGZ1bCB3aGVuIG9uZSBoYXMgYSBsb3Qg b2YgdGhpcmQtcGFydHkgY29kZSB0aGF0J3Mgbm90DQo6IDY0LWJpdCBjbGVhbi4NCg0KVHJ1ZSwg YnV0IG5vdCBhIGh1Z2UgY29uY2VybiB3aXRoIHRoZSBGcmVlQlNEIGtlcm5lbCA6KQ0KDQo6IEl0 IG1heSBhbHNvIGJlIGFyZ3VhYmx5IGEgYml0IG1vcmUgZWZmaWNpZW50IHRoYW4gbjY0IGFzIDMy LWJpdA0KOiBwb2ludGVycyB3b3VsZCByZXN1bHQgaW4gc21hbGxlciBzdHJ1Y3R1cmVzIGFuZCB0 aHVzIGxlc3MgY2FjaGUNCjogdGhyYXNoaW5nLiBJdCdzIGhhcmQgdG8gdGVsbCwgdGhvdWdoIHdo ZXRoZXIgdGhlIGRpZmZlcmVuY2UgaXMgbGFyZ2UNCjogZW5vdWdoIHRvIGJlIHdvcnRoIGJvdGhl cmluZyB3aXRoLiBEb2VzIGFueW9uZSBrbm93IG9mIGFueSBiZW5jaG1hcmsNCjogcmVzdWx0cyBj b21wYXJpbmcgbjMyIHZzLiBuNjQ/DQoNCkFsc28gbWVtb3J5IHRyYWZmaWMgYmFuZHdpZHRoIGNh biBiZSBhIHByb2JsZW0sIGJ1dCB0aGF0J3MgY2xvc2VseQ0KcmVsYXRlZCB0byBjYWNoZSB0aHJh c2hpbmcuLi4NCg0KOiBJbiBhbnkgY2FzZSwgdGhvc2UgYXJlIG1hcmdpbmFsIGZhY3RvcnMuIEkg ZG8gYmVsaWV2ZSB0aGFuIG42NCBrZXJuZWwNCjogaXMgdGhlIHdheSB0byBnby4NCjogDQo6IEJU VywgU29tZSBvZiA2NC1iaXQgaW5lZmZpY2llbmNpZXMgY2FuIGJlIG1pdGlnYXRlZCB3aXRoIC1t c3ltMzI6DQo6IGh0dHA6Ly93d3cuY2VsaW51eGZvcnVtLm9yZy9DZWxmUHViV2lraS9FTEMyMDA5 UHJlc2VudGF0aW9ucz9hY3Rpb249QXR0YWNoRmlsZSZkbz1nZXQmdGFyZ2V0PW5ldy10cmlja3Mt bWlwcy1saW51eC5wZGYNCg0KY29vbCB0cmlja3MuLi4NCg0KQlRXLCBJJ20gdHJ5aW5nIHRvIHB1 bGwgdG9nZXRoZXIgdGhlIHZhcmlvdXMgbjMyL242NCBwYXRjaGVzIGludG8NCnNvbWV0aGluZyB0 byBjb21taXQgdG8gdGhlIHRyZWUgc29vbi4uLiAgRmlyc3Qgc3RvcCB3aWxsIGJlIHRoZQ0KdG9v bGNoYWluLg0KDQpXYXJuZXINCg0KOiBPbiBNb24sIE1hciAxLCAyMDEwIGF0IDExOjM3IEFNLCBK dWxpIE1hbGxldHQgPGptYWxsZXR0QGZyZWVic2Qub3JnPiB3cm90ZToNCjogPiBPbiBNb24sIE1h ciAxLCAyMDEwIGF0IDA2OjI4LCBDLiBKYXlhY2hhbmRyYW4gPGMuamF5YWNoYW5kcmFuQGdtYWls LmNvbT4gd3JvdGU6DQo6ID4+IEknbSBpbiB0aGUgcHJvY2VzcyBvZiBnZXR0aW5nIG4zMiBBQkkg c3VwcG9ydCBmb3IgdGhlIFJNSSBwcm9jZXNzb3JzLg0KOiA+PiBUaGUgcGxhbiBpcyBoYXZlIG4z MiBjb21waWxlZCBrZXJuZWwgd2l0aCA2NC1iaXQgcmVnaXN0ZXJfdCBhbmQNCjogPj4gcGh5c2Fk ZHJfdCBhbmQgMzIgYml0IGxvbmcgYW5kIHBvaW50ZXIgdHlwZXMuDQo6ID4NCjogPiBIaSBKQywN CjogPg0KOiA+IEkndmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgdG9vIGluIG15IHVzZXIvam1hbGxl dHQvb2N0ZW9uIGJyYW5jaCBpbg0KOiA+IFN1YnZlcnNpb24gYW5kIGhhdmUgZ290dGVuIHBhc3Qg c29tZSBvZiB0aGUgcHJvYmxlbXMgeW91IG1lbnRpb24sIGJ1dA0KOiA+IG5vdCBhbHdheXMgaW4g dGhlIGNsZWFuZXN0IG9mIHdheXMuIMKgSSBzd2l0Y2hlZCB0byB1c2luZyB0aGUgbGliZ2NjDQo6 ID4gc29mdGZsb2F0IGltcGxlbWVudGF0aW9uIGluc3RlYWQgb2YgdGhlIGxpYmMgb25lLCBmb3Ig ZXhhbXBsZSwgYW5kDQo6ID4gaGF2ZSBjb21taXR0ZWQgc29tZSBjaGFuZ2VzIGZyb20gV2FybmVy IHRvIGxpYmMncyBhYmljYWxscyBzdXBwb3J0LiDCoEkNCjogPiBhbSBjdXJyZW50bHkgcnVubmlu ZyB3aXRoIGEgc3RhdGljIHJvb3QgZmlsZXN5c3RlbSB0byB0cmFjayBkb3duIHNvbWUNCjogPiBi dWdzIHdpdGggc3lzY2FsbHMgKEkgdGhpbmsganVzdCB0aGUgb25lcyB3aXRoIGxvdHMgb2YgYXJn dW1lbnRzLCBpLmUuDQo6ID4gdGhlIG9uZXMgd2UgbmVlZCB0byBkbyBjb3B5aW4gdG8gZ2V0OyBv ciBtYXliZSBpdCdzIHRoZSBib2d1cyBxdWFkDQo6ID4gc3R1ZmYsIEkgZG9uJ3Qga25vdyB5ZXQg 4oCUIHRoZSBkYXkgaXMgeW91bmcpIGJlZm9yZSBtb3Zpbmcgb24gdG8gZml4aW5nDQo6ID4gdGhl IHByb2JsZW1zIHdpdGggZHluYW1pYyBsaW5raW5nLiDCoElmIHRoZXJlJ3MgYW55IHdheSB0byBj b29yZGluYXRlDQo6ID4gb3VyIGVmZm9ydHMgYW5kIHlvdSdkIGxpa2UgdG8sIGxldCBtZSBrbm93 IQ0KOiA+DQo6ID4gT25lIHRoaW5nIEkgd2lsbCBzYXkgaXMgdGhhdCBJJ3ZlIGJlZW4gdGFsa2lu ZyB3aXRoIFdhcm5lciBhbmQgd2UNCjogPiB0aGluayB0aGF0IG4zMiBrZXJuZWxzIGFyZSBwcm9i YWJseSBhIHByZXR0eSBiYWQgaWRlYSDigJQgYSBsb3Qgb2YgdGhlDQo6ID4gc3lzdGVtIGRlcGVu ZHMgb24gcG9pbnRlcnMgYmVpbmcgdGhlIHNhbWUgd2lkdGggYXMgcmVnaXN0ZXJzLCBldGMuDQo6 ID4gTmVpdGhlciBvZiB1cyBjb3VsZCByZWFsbHkgdGhpbmsgb2YgYSBjYXNlIHdoZXJlIHlvdSdk IHdhbnQgYW4gbjMyDQo6ID4ga2VybmVsIGluc3RlYWQgb2YgYW4gbjY0IGtlcm5lbCBleGNlcHQg Zm9yIHRoZSBjYXNlIHdoZXJlIHlvdXINCjogPiBib290bG9hZGVyIGp1c3QgY2FuJ3QgaGFuZGxl IEVMRjY0LCBpbiB3aGljaCBjYXNlIGEgdHJhbXBvbGluZSBvciBhbg0KOiA+IG4zMi9vMzIgbG9h ZGVyIHdoaWNoIGNhbiBsb2FkIEVMRjY0IHNlZW1zIG1vcmUgYmVuZWZpY2lhbC4gwqBEbyB5b3UN CjogPiBoYXZlIGEgdXNlIGNhc2UgaW4gbWluZCwgb3IgaXMgaXQganVzdCB0aGF0IG4zMiBpcyBh biBlYXNpZXIgdGFyZ2V0DQo6ID4gdGhhbiBuNjQ/DQo6ID4NCjogPiBUaGFua3MsDQo6ID4gSnVs aS4NCjogPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K OiA+IGZyZWVic2QtbWlwc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCjogPiBodHRwOi8vbGlz dHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLW1pcHMNCjogPiBUbyB1bnN1 YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1taXBzLXVuc3Vic2NyaWJlQGZyZWVi c2Qub3JnIg0KOiA+DQo6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo6IGZyZWVic2QtbWlwc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCjogaHR0cDov L2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1taXBzDQo6IFRvIHVu c3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLW1pcHMtdW5zdWJzY3JpYmVAZnJl ZWJzZC5vcmciDQo6IA0KOiANCg== From owner-freebsd-mips@FreeBSD.ORG Mon Mar 1 21:27:54 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 124CC1065670; Mon, 1 Mar 2010 21:27:54 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 95F608FC17; Mon, 1 Mar 2010 21:27:53 +0000 (UTC) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o21LRb9T074747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Mar 2010 16:27:52 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <5B27996C-CAAC-4C87-BF9A-D914B57E175F@lakerest.net> From: Randall Stewart To: "C. Jayachandran" , Warner Losh In-Reply-To: <98a59be81003010632n526acfd0i57c58bca8645d62@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Mar 2010 13:27:37 -0800 References: <98a59be81002230021j6a0cc408j99fe6a5d57a21aff@mail.gmail.com> <98a59be81003010632n526acfd0i57c58bca8645d62@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: freebsd-mips@freebsd.org Subject: Re: USB support for RMI processors 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: Mon, 01 Mar 2010 21:27:54 -0000 Hmm I might have missed these.. I got some in. The n32 ones I will leave for Warner to look at.. I personally think we should be working on n64 not n32.. But I will go with whatever our fearless leader says (the passer of the cold).. R On Mar 1, 2010, at 6:32 AM, C. Jayachandran wrote: > Hi Randy, > > I'd send these patches last week, did you get a chance to look over > them? Let me know if you have any comments. > > Also, let me know if this is your preferred way for changes, otherwise > I can send them as attachments too. The mailing list will strip the > attachments, but your copy would be safe. > > Thanks, > JC. > > On Tue, Feb 23, 2010 at 1:51 PM, C. Jayachandran > wrote: >> I've two patches to add USB EHCI support for XLS processors. This >> is tested >> with umass driver on a USB attached disk and flash drive. Please >> review - >> I've left the original NetBSD license on xls_ehci.c (which came from >> ehci_pci.c), I hope this is not an issue. >> >> http://sites.google.com/site/cjayachandran/files/iodi-bus.patch >> - Move rmi_pci_bus_space to header and avoid extern >> - remove unused and commented code (MIPS_BUS_SPACE_PCI, pic_usb_ack) >> - use rmi_pci_bus_space for USB too (needs byteswap) >> >> http://sites.google.com/site/cjayachandran/files/xls-ehci.patch >> - uncomment xls_ehci.c in files.xlr >> - changes to xls_ehci.c - updated with dev/usb/controller/ehci_*.c as >> reference >> >> The files sys/mips/rmi/ehcireg.h and sys/mips/rmi/ehcivar.h can be >> deleted >> since they are not used now. Also sys/mips/rmi/pcibus.c is unused. >> >> Thanks, >> JC. >> > > > > -- > C. Jayachandran c.jayachandran@gmail.com > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-mips@FreeBSD.ORG Mon Mar 1 23:39:58 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 64E4E106583F for ; Mon, 1 Mar 2010 23:39:58 +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 C4AB48FC28 for ; Mon, 1 Mar 2010 23:39:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o21NWcFc053497; Mon, 1 Mar 2010 16:32:40 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 01 Mar 2010 16:32:33 -0700 (MST) Message-Id: <20100301.163233.4959786962507439.imp@bsdimp.com> To: rrs@lakerest.net From: "M. Warner Losh" In-Reply-To: <5B27996C-CAAC-4C87-BF9A-D914B57E175F@lakerest.net> References: <98a59be81002230021j6a0cc408j99fe6a5d57a21aff@mail.gmail.com> <98a59be81003010632n526acfd0i57c58bca8645d62@mail.gmail.com> <5B27996C-CAAC-4C87-BF9A-D914B57E175F@lakerest.net> 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: freebsd-mips@FreeBSD.org Subject: Re: USB support for RMI processors 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: Mon, 01 Mar 2010 23:39:58 -0000 In message: <5B27996C-CAAC-4C87-BF9A-D914B57E175F@lakerest.net> Randall Stewart writes: : Hmm I might have missed these.. I got some in. : : The n32 ones I will leave for Warner to look at.. : : I personally think we should be working on n64 not n32.. But : I will go with whatever our fearless leader says (the passer : of the cold).. n64 for the kernel definitely is the way to go. However, I'd like to get the n32 and n64 userland support in place too. And the first place to start with that is tools... Warner : R : On Mar 1, 2010, at 6:32 AM, C. Jayachandran wrote: : : > Hi Randy, : > : > I'd send these patches last week, did you get a chance to look over : > them? Let me know if you have any comments. : > : > Also, let me know if this is your preferred way for changes, otherwise : > I can send them as attachments too. The mailing list will strip the : > attachments, but your copy would be safe. : > : > Thanks, : > JC. : > : > On Tue, Feb 23, 2010 at 1:51 PM, C. Jayachandran : > wrote: : >> I've two patches to add USB EHCI support for XLS processors. This is : >> tested : >> with umass driver on a USB attached disk and flash drive. Please : >> review - : >> I've left the original NetBSD license on xls_ehci.c (which came from : >> ehci_pci.c), I hope this is not an issue. : >> : >> http://sites.google.com/site/cjayachandran/files/iodi-bus.patch : >> - Move rmi_pci_bus_space to header and avoid extern : >> - remove unused and commented code (MIPS_BUS_SPACE_PCI, pic_usb_ack) : >> - use rmi_pci_bus_space for USB too (needs byteswap) : >> : >> http://sites.google.com/site/cjayachandran/files/xls-ehci.patch : >> - uncomment xls_ehci.c in files.xlr : >> - changes to xls_ehci.c - updated with dev/usb/controller/ehci_*.c as : >> reference : >> : >> The files sys/mips/rmi/ehcireg.h and sys/mips/rmi/ehcivar.h can be : >> deleted : >> since they are not used now. Also sys/mips/rmi/pcibus.c is unused. : >> : >> Thanks, : >> JC. : >> : > : > : > : > -- : > C. Jayachandran c.jayachandran@gmail.com : > : : ------------------------------ : Randall Stewart : 803-317-4952 (cell) : 803-345-0391(direct) : : _______________________________________________ : freebsd-mips@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-mips : To unsubscribe, send any mail to : "freebsd-mips-unsubscribe@freebsd.org" : : 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. From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 04:38:24 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 1672A106566B for ; Tue, 2 Mar 2010 04:38:24 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id AA1A48FC13 for ; Tue, 2 Mar 2010 04:38:23 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so335644fga.13 for ; Mon, 01 Mar 2010 20:38:14 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.103.86.14 with SMTP id o14mr4339397mul.15.1267504694081; Mon, 01 Mar 2010 20:38:14 -0800 (PST) In-Reply-To: <98a59be81003012008y5b294094mc7139dd96836fa04@mail.gmail.com> References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> <98a59be81003012008y5b294094mc7139dd96836fa04@mail.gmail.com> From: Juli Mallett Date: Mon, 1 Mar 2010 20:37:54 -0800 X-Google-Sender-Auth: 6438c33f46fefc0e Message-ID: To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 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:38:24 -0000 On Mon, Mar 1, 2010 at 20:08, C. Jayachandran wr= ote: > On Tue, Mar 2, 2010 at 1:07 AM, Juli Mallett wrote= : > 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. It's easy, but I don't think much of the work is actually transferable besides trivial stuff like syscall args. > 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. =A0n32+64bit > phys will hopefully work out the next level of issues(TLB/page table > entries). =A0From there n64 will be getting the 64bit pmap and working > out 64-bit compilation. There's no reason you can't run n64 with 32-bit addresses and old pmap, you just have to sign extent -- no problem. I have an n64 kernel from my branch that gets as far as the first call to pmap_map(), but it blows up, I believe, due to brokenness of the segmap macros and shifts. Suddenly 0xc..... becomes 0xffffffffc.... and there's a lot more to index into the segmap. Easy to fix, but I'm spending my effort on n32 right now because I have an immediate deadline. I think that n32 is so degenerate (registers > pointers) that it actually breaks a lot of things elsewhere in the system. See my commits to DDB on my branch to deal with db_expr_t fallout, for example. n64 is standard LP64 and much less likely to be broken. A lot of n32 effort is spent on the degenerate cases that don't actually apply to n64 since, for example, long is the size of registers and pointers on n64. > 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). =A0And some customers we talked to have > large amounts of probably-not-64-bit-clean source code, so a 32 bit > option is always useful. Do they actually want to run 32-bit code in the kernel? The differences between n32 and n64 aren't that great in the kernel except for memory usage for the stack and trapframes, so I'd hope performance wouldn't be the problem. Bad code that can't handle big longs and pointers is going to have huge problems in the kernel where there are many opportunities to shoot your foot off. > 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. o64 has 64-bit pointers, even if you're using the compatibility segments and sign extending (and, thus, using a ~32-bit pmap.) Symbols in ELF have only 32-bits, but the pointers are definitely 64-bits. > 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. That just isn't true unless you're going to (to pick the most grotesque example) have db_expr_t and the like be only 32-bits for n32, which is really bad because then ddb becomes pretty useless. Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 04:43:21 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 F3D811065672 for ; Tue, 2 Mar 2010 04:43:20 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id C9E0C8FC12 for ; Tue, 2 Mar 2010 04:43:20 +0000 (UTC) Received: by pvg3 with SMTP id 3so1139922pvg.13 for ; Mon, 01 Mar 2010 20:43:12 -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=4WetbxhuWG6ct6r/FtVg3V+cY+eVl5CTmNsM8PPtlLQ=; b=rXKOaiUFN0oRs0Gt1kbNZ3lTDSg/LkoqyQeydSadQGDWkXZi9RMwxyGSBCyR/nMz2L zf89Esj2KNx0hVVxGUBAttw4kPsu/mQRFBsr38TmJ2mHhvtlFVxJY+Fd6Cq3Uzck6OjL tqTF6TyTqTiX2nYNRm6++YMNZhF6x5xluomto= 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=Cxga0d5kou3eVMZiDjPjPW3WSW37hydiKQZM4A+lP3jgDqK1raNZIvK9+7dxcewHmB MTQTM3f1CD7fVqAFBMohodIPkVG1enAIaq8bANxuBs1KBmiBBALbp8rvcJKL8fc7t88S UY1CtMNCU9XkA9piZBk3ttfaaf3Ue5Oso386Y= MIME-Version: 1.0 Received: by 10.142.195.16 with SMTP id s16mr3124303wff.306.1267504991927; Mon, 01 Mar 2010 20:43:11 -0800 (PST) In-Reply-To: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> Date: Mon, 1 Mar 2010 20:43:11 -0800 Message-ID: From: Neel Natu To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 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:43:21 -0000 Hi JC, The changes to bsd.cpu.mk that append to LDFLAGS will most likely break building kernel modules. Can you build a kernel module in a tree with your patch? The problem is that LDFLAGS are directly passed as arguments to the linker in bsd.kmod.mk and the linker does not like the -Wl,-linker_option style of setting options. Do you really need to set LDFLAGS in bsd.cpu.mk? It would seem that simply setting LD would work. best Neel On Mon, Mar 1, 2010 at 6:28 AM, 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. > > I've attached two patches, one for support for n32 in toolchain and > one for n32 support in kernel compilation. =A0With this I am able to > compile the kernel and user space with n32, and the boot-up reaches > until init. There is a lot more work on user-space and kernel (esp in > mips/mips/*.S) before it can complete boot-up. > > Please review and let me know if you have any comments or objections > on this approach. The patches are: > > http://sites.google.com/site/cjayachandran/files/n32-toolchain.patch > Toolchain support for N32 > - Adds the linker emulations needed for n32 > - Common preprocessor defines for ABI (_ABI_MIPS_SIM and _ABI???). > - Sets the long double type as 64 bit (this should be 128 bit in n32, > but there is some work needed to get the 128 bit soft-float working). > > http://sites.google.com/site/cjayachandran/files/n32-kernel.patch > N32 compilation - makefiles and conf > - Adds ldscript.mips.n32. > - Some cleanup in Makefile.mips, add ABI flags > - bsd.cpu.mk CFLAGS for n32 compilation and linking > > I have introduced a TARGET_N32 similart to TARGET_64 for n32 > compilation. =A0But I think on the long term, we need clean up the > different flags that affect architecture and ABI. Currently there is > an overlap between the TARGET_CPUTYPE flag, the ISA_ flags =A0and > the TARGET_ flags. > > Regards, > JC. > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 04:54:05 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 B782F1065674 for ; Tue, 2 Mar 2010 04:54:05 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-px0-f197.google.com (mail-px0-f197.google.com [209.85.216.197]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4DE8FC08 for ; Tue, 2 Mar 2010 04:54:05 +0000 (UTC) Received: by pxi36 with SMTP id 36so253941pxi.13 for ; Mon, 01 Mar 2010 20:53:58 -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=VNPXQju4TS/bkFZgwIiHtALUgk2gkXAFlWCoLTEqgho=; b=v5XGEUWQsgKLfjEVZqo0EHrySIobO6H9pYyMg9nQchS+Cs2d6srC9hD6Nc4mZ7X3d9 Q55E2iaU9iR9jrV2FRMBD0kMtnPBq1oQgu+EZ+BiRJ9uBS2u/PlG11qBC+oApaOxEpA3 4ZdJu+yK7TSSe7/NZK3249W9n+MJqhVcTis/A= 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=mf1TDXUkw2zZO6sUH69PDobOC9qOMOrESqMriPgQysMS/1baIi2etzGMDHTFLoB1dt +9ON0lYQrELGxmo/jACPKU4r+oVfjvnEWSq3Bk535/0AJPQeNlvmtvdjyvHtCkwKcvI3 FsM6SXdv6nsbAVgTMsbOn9+lElEWrDZ7Y0PRc= MIME-Version: 1.0 Received: by 10.141.124.12 with SMTP id b12mr3085505rvn.55.1267505638048; Mon, 01 Mar 2010 20:53:58 -0800 (PST) In-Reply-To: <20100301.163233.4959786962507439.imp@bsdimp.com> References: <98a59be81002230021j6a0cc408j99fe6a5d57a21aff@mail.gmail.com> <98a59be81003010632n526acfd0i57c58bca8645d62@mail.gmail.com> <5B27996C-CAAC-4C87-BF9A-D914B57E175F@lakerest.net> <20100301.163233.4959786962507439.imp@bsdimp.com> Date: Tue, 2 Mar 2010 10:23:58 +0530 Message-ID: <98a59be81003012053w81c3b4cxf25d1157abfe3114@mail.gmail.com> From: "C. Jayachandran" To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: USB support for RMI processors 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:54:05 -0000 On Tue, Mar 2, 2010 at 5:02 AM, M. Warner Losh wrote: > In message: <5B27996C-CAAC-4C87-BF9A-D914B57E175F@lakerest.net> > =A0 =A0 =A0 =A0 =A0 =A0Randall Stewart writes: > : Hmm I might have missed these.. I got some in. Thanks. > : The n32 ones I will leave for Warner to look at.. > : > : I personally think we should be working on n64 not n32.. But > : I will go with whatever our fearless leader says (the passer > : of the cold).. > > n64 for the kernel definitely is the way to go. =A0However, I'd like to > get the n32 and n64 userland support in place too. =A0And the first > place to start with that is tools... Please see my reply on the list on n32. The userland compiles with the patches and with -DNO_USB -DNO_BLUETOOTH (using ld to convert binary to n32 obj fails - needs to look at this). But the main battle will be ahead, the syscall, exception and pobably signal handling and executable support needs to be fixed before init goes thru. I'm working on this. Regards, JC. From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 04:58:00 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 18A6C1065672 for ; Tue, 2 Mar 2010 04:58:00 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id AA8C18FC1B for ; Tue, 2 Mar 2010 04:57:59 +0000 (UTC) Received: by fxm23 with SMTP id 23so875461fxm.3 for ; Mon, 01 Mar 2010 20:57:53 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.102.183.40 with SMTP id g40mr4347186muf.85.1267505873073; Mon, 01 Mar 2010 20:57:53 -0800 (PST) In-Reply-To: <98a59be81003012053w81c3b4cxf25d1157abfe3114@mail.gmail.com> References: <98a59be81002230021j6a0cc408j99fe6a5d57a21aff@mail.gmail.com> <98a59be81003010632n526acfd0i57c58bca8645d62@mail.gmail.com> <5B27996C-CAAC-4C87-BF9A-D914B57E175F@lakerest.net> <20100301.163233.4959786962507439.imp@bsdimp.com> <98a59be81003012053w81c3b4cxf25d1157abfe3114@mail.gmail.com> From: Juli Mallett Date: Mon, 1 Mar 2010 20:57:33 -0800 X-Google-Sender-Auth: c030c50424fc8527 Message-ID: To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: USB support for RMI processors 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:58:00 -0000 On Mon, Mar 1, 2010 at 20:53, C. Jayachandran wr= ote: > The userland compiles with the patches and with -DNO_USB > -DNO_BLUETOOTH (using ld to convert binary to n32 obj fails - needs to > look at this). But the main battle will be ahead, the syscall, > exception and pobably signal handling and executable support needs to > be fixed before init goes thru. =A0I'm working on this. I've made a hackish change to syscall stuff that works well enough but breaks o32 support; it should be obvious how to fix that: http://svn.freebsd.org/viewvc/base/user/jmallett/octeon/sys/mips/mips/trap.= c?r1=3D204399&r2=3D204534&sortby=3Ddate I'm fighting with rtld right now and believe I know the source of my misery but my tree has stopped working for some unrelated reason so now I'm trying to figure out what I messed up. BTW I've found it very useful to work with WITHOUT_DYNAMICROOT while I worked on the issues more fundamental than the rtld problem. Trivial signals seemed to work fine. Juli. From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 05:07:44 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 9F066106566B for ; Tue, 2 Mar 2010 05:07:44 +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 508C38FC14 for ; Tue, 2 Mar 2010 05:07:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2255vF7056829; Mon, 1 Mar 2010 22:05:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 01 Mar 2010 22:06:11 -0700 (MST) Message-Id: <20100301.220611.787670930824834909.imp@bsdimp.com> To: neelnatu@gmail.com From: "M. Warner Losh" In-Reply-To: References: <98a59be81003010628g6099768erc397bc90841840f8@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: 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 05:07:44 -0000 In message: Neel Natu writes: : The changes to bsd.cpu.mk that append to LDFLAGS will most likely : break building kernel modules. Can you build a kernel module in a tre= e : with your patch? Chances are all of those will go away anyway :) But I haven't thought about ABI changes in my TBEMD tree.... : The problem is that LDFLAGS are directly passed as arguments to the : linker in bsd.kmod.mk and the linker does not like the : -Wl,-linker_option style of setting options. : = : Do you really need to set LDFLAGS in bsd.cpu.mk? It would seem that : simply setting LD would work. But in the current world order, I have the same questions... Warner : best : Neel : = : On Mon, Mar 1, 2010 at 6:28 AM, C. Jayachandran : wrote: : > I'm in the process of getting n32 ABI support for the RMI processor= s. : > The plan is have n32 compiled kernel with 64-bit register_t and : > physaddr_t and 32 bit long and pointer types. : > : > I've attached two patches, one for support for n32 in toolchain and= : > one for n32 support in kernel compilation. =A0With this I am able t= o : > compile the kernel and user space with n32, and the boot-up reaches= : > until init. There is a lot more work on user-space and kernel (esp = in : > mips/mips/*.S) before it can complete boot-up. : > : > Please review and let me know if you have any comments or objection= s : > on this approach. The patches are: : > : > http://sites.google.com/site/cjayachandran/files/n32-toolchain.patc= h : > Toolchain support for N32 : > - Adds the linker emulations needed for n32 : > - Common preprocessor defines for ABI (_ABI_MIPS_SIM and _ABI???). : > - Sets the long double type as 64 bit (this should be 128 bit in n3= 2, : > but there is some work needed to get the 128 bit soft-float working= ). : > : > http://sites.google.com/site/cjayachandran/files/n32-kernel.patch : > N32 compilation - makefiles and conf : > - Adds ldscript.mips.n32. : > - Some cleanup in Makefile.mips, add ABI flags : > - bsd.cpu.mk CFLAGS for n32 compilation and linking : > : > I have introduced a TARGET_N32 similart to TARGET_64 for n32 : > compilation. =A0But I think on the long term, we need clean up the : > different flags that affect architecture and ABI. Currently there i= s : > an overlap between the TARGET_CPUTYPE flag, the ISA_ flags =A0= and : > the TARGET_ flags. : > : > Regards, : > JC. : > _______________________________________________ : > freebsd-mips@freebsd.org mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-mips : > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.= org" : > : _______________________________________________ : freebsd-mips@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-mips : To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.or= g" : = : = From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 05:19:59 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 20E68106566C; Tue, 2 Mar 2010 05:19:59 +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 D43998FC12; Tue, 2 Mar 2010 05:19:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o225EWFJ056916; Mon, 1 Mar 2010 22:14:32 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 01 Mar 2010 22:14:46 -0700 (MST) Message-Id: <20100301.221446.690091871650373431.imp@bsdimp.com> To: jmallett@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20100301.163233.4959786962507439.imp@bsdimp.com> <98a59be81003012053w81c3b4cxf25d1157abfe3114@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: freebsd-mips@freebsd.org Subject: Re: USB support for RMI processors 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 05:19:59 -0000 In message: Juli Mallett writes: : On Mon, Mar 1, 2010 at 20:53, C. Jayachandran wrote: : > The userland compiles with the patches and with -DNO_USB : > -DNO_BLUETOOTH (using ld to convert binary to n32 obj fails - needs= to : > look at this). But the main battle will be ahead, the syscall, : > exception and pobably signal handling and executable support needs = to : > be fixed before init goes thru. =A0I'm working on this. : = : I've made a hackish change to syscall stuff that works well enough bu= t : breaks o32 support; it should be obvious how to fix that: : = : http://svn.freebsd.org/viewvc/base/user/jmallett/octeon/sys/mips/mips= /trap.c?r1=3D204399&r2=3D204534&sortby=3Ddate I think this is why we'll need to know the ABI that the binary is running :) : I'm fighting with rtld right now and believe I know the source of my : misery but my tree has stopped working for some unrelated reason so : now I'm trying to figure out what I messed up. __start and rtld is very intimately linked. And both are sensitive to the ABI. I have some saved patches in my tree that I've not had a chance to test... : BTW I've found it very useful to work with WITHOUT_DYNAMICROOT while = I : worked on the issues more fundamental than the rtld problem. Trivial= : signals seemed to work fine. Yea, me too. :) Warner From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 05:53:42 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 53BDF106572E; Tue, 2 Mar 2010 05:53:42 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pz0-f173.google.com (mail-pz0-f173.google.com [209.85.222.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF208FC29; Tue, 2 Mar 2010 05:53:41 +0000 (UTC) Received: by pzk3 with SMTP id 3so2595970pzk.24 for ; Mon, 01 Mar 2010 21:53:31 -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=E8YKtbe6yuk64y/efh3zw8h+511jrF/66ixotJ9nKdo=; b=nQj96jC0WzXzc2qzMrPKNWF+4/XmHfLsc5WgLNPBd1tqXtRNoI+juepMoKrRlaabpc TEWLYb34HTtYWLhPG3MImswiCvIzJMk00BlDnvk1bKlilBXFmQN/SlNLqtqtk7Dgiv/K YUJeNnftVhvssJaCmYv3t4TxZocgFsWKYHrMw= 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=kHQU/Q4yZOEm/efowE7u6ozk+PMFOji2tLOVB1aJJ/GjrPbC8UV2bIFgiq5sbmmr5q OljpoelzKt/8pXfqy6Z3voaMzrhVJieZRyC9lUDcJhDThKB/U2zbj4IOaUfg2MkE7joG 1Q9jWnImiNfKD0vh69AYAE9Jby/txjoINKjxA= MIME-Version: 1.0 Received: by 10.140.248.7 with SMTP id v7mr3104726rvh.237.1267509211037; Mon, 01 Mar 2010 21:53:31 -0800 (PST) In-Reply-To: References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> <98a59be81003012008y5b294094mc7139dd96836fa04@mail.gmail.com> Date: Tue, 2 Mar 2010 11:23:31 +0530 Message-ID: <98a59be81003012153m3e8e3a49t52747cc43cd719c3@mail.gmail.com> From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 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 05:53:42 -0000 On Tue, Mar 2, 2010 at 10:07 AM, Juli Mallett wrote: > On Mon, Mar 1, 2010 at 20:08, C. Jayachandran = wrote: >> On Tue, Mar 2, 2010 at 1:07 AM, Juli Mallett wrot= e: >> 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. > > It's easy, but I don't think much of the work is actually transferable > besides trivial stuff like syscall args. > >> 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. =A0n32+64bit >> phys will hopefully work out the next level of issues(TLB/page table >> entries). =A0From there n64 will be getting the 64bit pmap and working >> out 64-bit compilation. > > There's no reason you can't run n64 with 32-bit addresses and old > pmap, you just have to sign extent -- no problem. =A0I have an n64 > kernel from my branch that gets as far as the first call to > pmap_map(), but it blows up, I believe, due to brokenness of the > segmap macros and shifts. =A0Suddenly 0xc..... becomes 0xffffffffc.... > and there's a lot more to index into the segmap. =A0Easy to fix, but I'm > spending my effort on n32 right now because I have an immediate > deadline. > > I think that n32 is so degenerate (registers > pointers) that it > actually breaks a lot of things elsewhere in the system. =A0See my > commits to DDB on my branch to deal with db_expr_t fallout, for > example. =A0n64 is standard LP64 and much less likely to be broken. =A0A > lot of n32 effort is spent on the degenerate cases that don't actually > apply to n64 since, for example, long is the size of registers and > pointers on n64. My own experience with o64 (please see below on o64), was not as bad, which is the main reason why I started on this path. I guess if n32 user-space will be supported, n32 tool-chain and compilation will have to be supported, so n32 kernel is worth a shot, and not a distraction. >> 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). =A0And some customers we talked to have >> large amounts of probably-not-64-bit-clean source code, so a 32 bit >> option is always useful. > > Do they actually want to run 32-bit code in the kernel? =A0The > differences between n32 and n64 aren't that great in the kernel except > for memory usage for the stack and trapframes, so I'd hope performance > wouldn't be the problem. =A0Bad code that can't handle big longs and > pointers is going to have huge problems in the kernel where there are > many opportunities to shoot your foot off. I hope we can keep the trapframes same for n32 and n64 along with other user-visible structures (have not fully looked at it yet). Getting pointers to 64 bit increases your memory usage and cache foot print. >> 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. > > o64 has 64-bit pointers, even if you're using the compatibility > segments and sign extending (and, thus, using a ~32-bit pmap.) > Symbols in ELF have only 32-bits, but the pointers are definitely > 64-bits. o64 (http://gcc.gnu.org/projects/mipso64-abi.html) has 32 bit long and 32 bit pointers, but the registers, argument passing and stack alignment is 64bit, so when used with mips64 architecture, you get to use the 64bit registers and operations for 64 bit types (uint64_t and int64_t), without having the footprint of LP64. But o64 is old (even when they named it, it was old :) ) - and n32 gives the same results. >> 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. > > That just isn't true unless you're going to (to pick the most > grotesque example) have db_expr_t and the like be only 32-bits for > n32, which is really bad because then ddb becomes pretty useless. The default ddb seems to work on my n32 compilation of HEAD, with the key sequence, I was sure the register_t is 64bit, I will have to look at this then..... Regards, JC. From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 06:07:41 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 839761065674; Tue, 2 Mar 2010 06:07:41 +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 501C08FC16; Tue, 2 Mar 2010 06:07:40 +0000 (UTC) Received: by pwj1 with SMTP id 1so712394pwj.13 for ; Mon, 01 Mar 2010 22:07:31 -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=cKLZc3PAPTRrRuvAP+HyjAyZRyV7jwblkj+g0p9Lb1A=; b=VJhkEDhYkQIqaE1pgFLtBnIvukraapQFdDJGhls8SjTe5OszI8hz3uT49Q0GWhPbyr 2EbbE7paDaetuSSKIDq5g03WXfS9x25IPIDVKdD+T4ipCk3VXwY5ogElKLC3GZyZ6okv H3xtrSvJLlqEFJ5/ppSMfBIILsa0JBlTSj9GI= 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=Mq8HKr4pQgk3WgUUmNG2oEW2s9vHExGw4PE+NU10+eoiBFfE6XyChah5ozSrQKnT32 S9qdm/B4Hp4h+uTP3WRhLr8hBqaBE3MRcVH2IOchOr310/xwQFxIoZrWfvouSE6fPSlh HRax+cWSvzG0WRQG4+U1qBp6q9dsBO9DcfKm8= MIME-Version: 1.0 Received: by 10.141.214.24 with SMTP id r24mr3124537rvq.27.1267510051698; Mon, 01 Mar 2010 22:07:31 -0800 (PST) In-Reply-To: References: <98a59be81002230021j6a0cc408j99fe6a5d57a21aff@mail.gmail.com> <98a59be81003010632n526acfd0i57c58bca8645d62@mail.gmail.com> <5B27996C-CAAC-4C87-BF9A-D914B57E175F@lakerest.net> <20100301.163233.4959786962507439.imp@bsdimp.com> <98a59be81003012053w81c3b4cxf25d1157abfe3114@mail.gmail.com> Date: Tue, 2 Mar 2010 11:37:31 +0530 Message-ID: <98a59be81003012207s1f0af94bse9caa468d76ec989@mail.gmail.com> From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: USB support for RMI processors 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 06:07:41 -0000 On Tue, Mar 2, 2010 at 10:27 AM, Juli Mallett wrote: > On Mon, Mar 1, 2010 at 20:53, C. Jayachandran = wrote: >> The userland compiles with the patches and with -DNO_USB >> -DNO_BLUETOOTH (using ld to convert binary to n32 obj fails - needs to >> look at this). But the main battle will be ahead, the syscall, >> exception and pobably signal handling and executable support needs to >> be fixed before init goes thru. =A0I'm working on this. > > I've made a hackish change to syscall stuff that works well enough but > breaks o32 support; it should be obvious how to fix that: > > http://svn.freebsd.org/viewvc/base/user/jmallett/octeon/sys/mips/mips/tra= p.c?r1=3D204399&r2=3D204534&sortby=3Ddate > > I'm fighting with rtld right now and believe I know the source of my > misery but my tree has stopped working for some unrelated reason so > now I'm trying to figure out what I messed up. > > BTW I've found it very useful to work with WITHOUT_DYNAMICROOT while I > worked on the issues more fundamental than the rtld problem. =A0Trivial > signals seemed to work fine. I did the rtld internally for 6.4 almost the same way, i.e, have a static root and get a simple program going, in my case it was on the lines of 'printf("%p\n", printf);'. Another useful thing is to have is a hacked version of printf which does not the libc but does the write syscall in assembly directly, this was useful to print out debug stuff from rtld code. Regards, JC. From owner-freebsd-mips@FreeBSD.ORG Tue Mar 2 13:36:17 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 38F52106566C for ; Tue, 2 Mar 2010 13:36:17 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-px0-f195.google.com (mail-px0-f195.google.com [209.85.216.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8B28FC1F for ; Tue, 2 Mar 2010 13:36:16 +0000 (UTC) Received: by pxi33 with SMTP id 33so76090pxi.14 for ; Tue, 02 Mar 2010 05:35:59 -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=mGYYY5MtLDsQi2QvT44x8ybbLW1L2tY7t88phVus8b0=; b=sx6JmhkW1onaMRabosqXctjL/xH5ApXFbj+xGafQM/tjBtE7ntyCz5gsdSzPYwkbwo USW87zzKpCIsHsjzoNE4xJzPsJQxWQ47Fz3eDQFwvrb+R7cWGIRnRqVx7XlV4sGDl5SO BCwVVQZDVTbJL9SyECb2R/aSM8Kxgb0C1gSoU= 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=Ip0JTwkQwsHYrqemGdy90893Or68LWKjZH38pVIq05dW5JeRiXDw2bGq3c8ArPCzQC k0ebtn4xry7xkT2dMUD3rQxREtu951cLPWuQeGxSRTac27iN+AZ97c5hw9Hn8neMBfx+ 0yalRBd6rJmp1sQzco+2pu0/YJz0qRnW9nOTE= MIME-Version: 1.0 Received: by 10.141.90.21 with SMTP id s21mr207087rvl.240.1267536958835; Tue, 02 Mar 2010 05:35:58 -0800 (PST) In-Reply-To: <20100301.220611.787670930824834909.imp@bsdimp.com> References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> <20100301.220611.787670930824834909.imp@bsdimp.com> Date: Tue, 2 Mar 2010 19:05:58 +0530 Message-ID: <98a59be81003020535l38c0e2eav8f2478cb58a38e3f@mail.gmail.com> From: "C. Jayachandran" To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 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 13:36:17 -0000 On Tue, Mar 2, 2010 at 10:36 AM, M. Warner Losh wrote: > In message: > =A0 =A0 =A0 =A0 =A0 =A0Neel Natu writes: > : The changes to bsd.cpu.mk that append to LDFLAGS will most likely > : break building kernel modules. Can you build a kernel module in a tree > : with your patch? > > Chances are all of those will go away anyway :) =A0But I haven't thought > about ABI changes in my TBEMD tree.... > > : The problem is that LDFLAGS are directly passed as arguments to the > : linker in bsd.kmod.mk and the linker does not like the > : -Wl,-linker_option style of setting options. > : > : Do you really need to set LDFLAGS in bsd.cpu.mk? It would seem that > : simply setting LD would work. > > But in the current world order, I have the same questions... If you look at the bsd.lib.mk and bsd.prog.mk used for userspace compilation, it seems that LDFLAGS are passed to ${CC} when creating an final executable or library as I had written. So for user-space compilation we need the -Wl in LDFLAGS. In kmod.mk, LDFLAGS is passed to ${LD} which will cause problems as Neel noted. The easy fix is to clear LDFLAGS in kmod.mk, since ${LD} already has the emulation flag. The proper fix would be to have the emulation flags like elf64btsmip_fbsd passed by the compiler to the linker, based on arch and abi flags, and avoid using LDFLAGS for doing this. But this still has a problem because the arch and abi settings are in CFLAGS which is not passed in while creating shared libraries in bsd.lib.mk, so shared libraries creation won't work. So for this to completely work, we should not rely on CFLAGS either. Instead the toolchain should have default abi and arch settings, based on the target. I think the proper fix would be needed anyway, as we should be able to do 'cc x.c' on an n64 or n32 userspace and get an n64 or n32 executable, not o32 executable. I will make a initial patch that removes the LDFLAGS from bsd.cpu.mk and changes gcc/config/mips/freebsd.h to have the correct defaults, and see how it works out. Regards, JC. From owner-freebsd-mips@FreeBSD.ORG Wed Mar 3 09:13:45 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44D32106566B for ; Wed, 3 Mar 2010 09:13:45 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 032458FC0C for ; Wed, 3 Mar 2010 09:13:44 +0000 (UTC) Received: from gw ([192.168.10.10] helo=terran) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Nmkbq-0000VL-QT for mips@freebsd.org; Wed, 03 Mar 2010 11:11:14 +0200 Date: Wed, 3 Mar 2010 11:14:05 +0200 From: Alexandr Rybalko To: mips@freebsd.org Message-Id: <20100303111405.05b3c3b3.ray@dlink.ua> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: MIPS_MEM_RID 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: Wed, 03 Mar 2010 09:13:45 -0000 Hi, Question: We really need MIPS_MEM_RID different form other platforms? I work on siba drivers, and we already know what siba can be in not MIPS device. Such as Broadcom Wi-Fi cards. -- Alexandr Rybalko aka Alex RAY From owner-freebsd-mips@FreeBSD.ORG Wed Mar 3 12:46:36 2010 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55057106566C for ; Wed, 3 Mar 2010 12:46:36 +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 009B98FC1D for ; Wed, 3 Mar 2010 12:46:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o23Cb02n079100; Wed, 3 Mar 2010 05:37:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 03 Mar 2010 05:37:16 -0700 (MST) Message-Id: <20100303.053716.584432776655158376.imp@bsdimp.com> To: ray@dlink.ua From: "M. Warner Losh" In-Reply-To: <20100303111405.05b3c3b3.ray@dlink.ua> References: <20100303111405.05b3c3b3.ray@dlink.ua> 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: mips@FreeBSD.org Subject: Re: MIPS_MEM_RID 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: Wed, 03 Mar 2010 12:46:36 -0000 In message: <20100303111405.05b3c3b3.ray@dlink.ua> Alexandr Rybalko writes: : Question: We really need MIPS_MEM_RID different form other : platforms? I work on siba drivers, and we already know what siba : can be in not MIPS device. Such as Broadcom Wi-Fi cards. I don't understand this question. It doesn't look like we define MIPS_MEM_RID at all for mips. It looks to be purely an internal thing to sys/dev/siba/siba.c. Warner From owner-freebsd-mips@FreeBSD.ORG Wed Mar 3 13:02:26 2010 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3C3106564A for ; Wed, 3 Mar 2010 13:02:26 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id ECA4B8FC1B for ; Wed, 3 Mar 2010 13:02:25 +0000 (UTC) Received: from gw ([192.168.10.10] helo=terran) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1NmoB9-0003Oi-7Y; Wed, 03 Mar 2010 14:59:55 +0200 Date: Wed, 3 Mar 2010 15:02:38 +0200 From: Alexandr Rybalko To: "M. Warner Losh" Message-Id: <20100303150238.68be18a3.ray@dlink.ua> In-Reply-To: <20100303.053716.584432776655158376.imp@bsdimp.com> References: <20100303111405.05b3c3b3.ray@dlink.ua> <20100303.053716.584432776655158376.imp@bsdimp.com> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org Subject: Re: MIPS_MEM_RID 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: Wed, 03 Mar 2010 13:02:26 -0000 On Wed, 03 Mar 2010 05:37:16 -0700 (MST) "M. Warner Losh" wrote: >> In message: <20100303111405.05b3c3b3.ray@dlink.ua> >> Alexandr Rybalko writes: >> >> : Question: We really need MIPS_MEM_RID different form other >> : platforms? I work on siba drivers, and we already know what siba >> : can be in not MIPS device. Such as Broadcom Wi-Fi cards. >> >> I don't understand this question. It doesn't look like we define >> MIPS_MEM_RID at all for mips. It looks to be purely an internal thing >> to sys/dev/siba/siba.c. >> >> Warner I apologize for my English and for the question. There remained only the small tail :) sys/mips/mips/nexus.c:76: #define MIPS_MEM_RID 0x20 Sorry that took time. -- Alexandr Rybalko aka Alex RAY From owner-freebsd-mips@FreeBSD.ORG Wed Mar 3 16:12:55 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 341481065674; Wed, 3 Mar 2010 16:12:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D792F8FC16; Wed, 3 Mar 2010 16:12:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o23GCsY7094806; Wed, 3 Mar 2010 11:12:54 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o23GCsgk094788; Wed, 3 Mar 2010 16:12:54 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 3 Mar 2010 16:12:54 GMT Message-Id: <201003031612.o23GCsgk094788@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:12:55 -0000 TB --- 2010-03-03 15:45:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-03 15:45:41 - starting HEAD tinderbox run for mips/mips TB --- 2010-03-03 15:45:41 - cleaning the object tree TB --- 2010-03-03 15:45:53 - cvsupping the source tree TB --- 2010-03-03 15:45:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-03-03 15:46:17 - building world TB --- 2010-03-03 15:46:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-03 15:46:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-03 15:46:17 - TARGET=mips TB --- 2010-03-03 15:46:17 - TARGET_ARCH=mips TB --- 2010-03-03 15:46:17 - TZ=UTC TB --- 2010-03-03 15:46:17 - __MAKE_CONF=/dev/null TB --- 2010-03-03 15:46:17 - cd /src TB --- 2010-03-03 15:46:17 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 3 15:46:20 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] lex -t /src/usr.bin/csup/token.l > token.c rm -f .depend mkdep -f .depend -a -I. -DHAVE_FFLAGS -DNDEBUG /src/usr.bin/csup/attrstack.c /src/usr.bin/csup/auth.c /src/usr.bin/csup/config.c /src/usr.bin/csup/detailer.c /src/usr.bin/csup/diff.c /src/usr.bin/csup/fattr.c /src/usr.bin/csup/fixups.c /src/usr.bin/csup/fnmatch.c /src/usr.bin/csup/globtree.c /src/usr.bin/csup/idcache.c /src/usr.bin/csup/keyword.c /src/usr.bin/csup/lex.rcs.c /src/usr.bin/csup/lister.c /src/usr.bin/csup/main.c /src/usr.bin/csup/misc.c /src/usr.bin/csup/mux.c parse.c /src/usr.bin/csup/pathcomp.c /src/usr.bin/csup/proto.c /src/usr.bin/csup/rcsfile.c /src/usr.bin/csup/rcsparse.c /src/usr.bin/csup/rsyncfile.c /src/usr.bin/csup/status.c /src/usr.bin/csup/stream.c /src/usr.bin/csup/threads.c token.c /src/usr.bin/csup/updater.c /src/usr.bin/csup/parse.y:32:20: error: config.h: No such file or directory /src/usr.bin/csup/parse.y:33:19: error: token.h: No such file or directory /src/usr.bin/csup/token.l:35:18: error: misc.h: No such file or directory /src/usr.bin/csup/token.l:36:19: error: token.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/usr.bin/csup. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-03 16:12:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-03 16:12:54 - ERROR: failed to build world TB --- 2010-03-03 16:12:54 - 1137.04 user 295.90 system 1632.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Wed Mar 3 20:09:36 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4151106566B for ; Wed, 3 Mar 2010 20:09:36 +0000 (UTC) (envelope-from neelnatu@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 8BB958FC1C for ; Wed, 3 Mar 2010 20:09:36 +0000 (UTC) Received: by pwj1 with SMTP id 1so1250029pwj.13 for ; Wed, 03 Mar 2010 12:09:33 -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; bh=lyt/YA2XASEHIs53A+5vAgpZnlmSpOP9QwLi1lTfsKk=; b=mUKZcD9Frw6YGG4eM6ls7GBGM1sduxrG7VVnu51Zh8dT1IBHM/WTbgYFQXHFa765Js BUckicCq2rVDd9wETj5rJhVx0Hjz3XU0Qq8Jhp8uzy2anO2ftouSDqFh+qu1DWin7kRC mYzr44WmZLni3oOmMfU8UXPcc6oJuo1VT73ms= 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; b=lQ9YxJd/xWoH9rfISj8+lqWiE/bMXIi+o5UdXoSCztAz6MKavRZBK6WJjXu59IVhPi STjPxCvb6eA1w2sDyhJPJlIdhXYlP5gQqlQHD8odfNlF5ylLMXnQkBDUbbGeIraDj7Oy 1ey3z6TCNxzZ7MKt7f4HApK8wHZK4WkncsLxk= MIME-Version: 1.0 Received: by 10.142.202.11 with SMTP id z11mr4038972wff.64.1267645597928; Wed, 03 Mar 2010 11:46:37 -0800 (PST) In-Reply-To: <20100303150238.68be18a3.ray@dlink.ua> References: <20100303111405.05b3c3b3.ray@dlink.ua> <20100303.053716.584432776655158376.imp@bsdimp.com> <20100303150238.68be18a3.ray@dlink.ua> Date: Wed, 3 Mar 2010 11:46:37 -0800 Message-ID: From: Neel Natu To: Alexandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: mips@freebsd.org Subject: Re: MIPS_MEM_RID 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: Wed, 03 Mar 2010 20:09:36 -0000 Hi Alexandr, On Wed, Mar 3, 2010 at 5:02 AM, Alexandr Rybalko wrote: > On Wed, 03 Mar 2010 05:37:16 -0700 (MST) > "M. Warner Losh" wrote: > >>> In message: <20100303111405.05b3c3b3.ray@dlink.ua> >>> Alexandr Rybalko writes: >>> >>> : Question: We really need MIPS_MEM_RID different form other >>> : platforms? I work on siba drivers, and we already know what siba >>> : can be in not MIPS device. Such as Broadcom Wi-Fi cards. >>> >>> I don't understand this question. It doesn't look like we define >>> MIPS_MEM_RID at all for mips. It looks to be purely an internal thing >>> to sys/dev/siba/siba.c. >>> >>> Warner > > I apologize for my English and for the question. > > There remained only the small tail :) > sys/mips/mips/nexus.c:76: #define MIPS_MEM_RID 0x20 > Do you want to get rid of this macro from nexus.c? I don't see anybody using it so it should be fine. best Neel > Sorry that took time. > > -- > Alexandr Rybalko > aka Alex RAY > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-mips@FreeBSD.ORG Wed Mar 3 21:30:14 2010 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43FAF106564A for ; Wed, 3 Mar 2010 21:30:14 +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 038538FC23 for ; Wed, 3 Mar 2010 21:30:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o23LKCan084733; Wed, 3 Mar 2010 14:20:12 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 03 Mar 2010 14:20:28 -0700 (MST) Message-Id: <20100303.142028.706189011771610223.imp@bsdimp.com> To: neelnatu@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20100303.053716.584432776655158376.imp@bsdimp.com> <20100303150238.68be18a3.ray@dlink.ua> 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: mips@FreeBSD.org Subject: Re: MIPS_MEM_RID 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: Wed, 03 Mar 2010 21:30:14 -0000 In message: Neel Natu writes: : Hi Alexandr, : : On Wed, Mar 3, 2010 at 5:02 AM, Alexandr Rybalko wrote: : > On Wed, 03 Mar 2010 05:37:16 -0700 (MST) : > "M. Warner Losh" wrote: : > : >>> In message: <20100303111405.05b3c3b3.ray@dlink.ua> : >>> Alexandr Rybalko writes: : >>> : >>> : Question: We really need MIPS_MEM_RID different form other : >>> : platforms? I work on siba drivers, and we already know what siba : >>> : can be in not MIPS device. Such as Broadcom Wi-Fi cards. : >>> : >>> I don't understand this question. It doesn't look like we define : >>> MIPS_MEM_RID at all for mips. It looks to be purely an internal thing : >>> to sys/dev/siba/siba.c. : >>> : >>> Warner : > : > I apologize for my English and for the question. : > : > There remained only the small tail :) : > sys/mips/mips/nexus.c:76: #define MIPS_MEM_RID 0x20 : > : : Do you want to get rid of this macro from nexus.c? I don't see anybody : using it so it should be fine. The only place it is used is the #define here... I'm not sure why dev/siba would need it, but even there I think it is unnecessary.c Warner From owner-freebsd-mips@FreeBSD.ORG Thu Mar 4 05:21:26 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 2B09F106564A for ; Thu, 4 Mar 2010 05:21:26 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f189.google.com (mail-qy0-f189.google.com [209.85.221.189]) by mx1.freebsd.org (Postfix) with ESMTP id D6A958FC0A for ; Thu, 4 Mar 2010 05:21:25 +0000 (UTC) Received: by qyk27 with SMTP id 27so1841395qyk.13 for ; Wed, 03 Mar 2010 21:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=C+RCsxfgqXB7h5lLSdDF3HaXx1wslNLa73MrO4kFFpE=; b=cXLlFvoIupcW7aUr5OFFEX5ttZ7fu2dDPZuy8Tmu52itwwqOwfiSdoQ1CT+Fnp0VWl NQfimSxZO6BHY9a5jkSeIyyTsMGLK6XritLqodpUPFCl/WuIRZgrPGmVg8JGojGW5J2Q uPK/P4kXcYxO+tEQtjR7+7vxQARsc0IRIx4nY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=IYA9R8NV43rnBGE5RhKG+rKrh+bx/0HtNjJbL9MFyIPFEWMZrrrH82huRyiVVS+DGq eOOVNrK8VJ62Ni/n4j4WwBvzujs+OwH7Pr2DwWztLhbpMuXw1m8v4zLHLAcSNbgv9E8B vOruWSG8M6ZyFAzyyyr02gqsYSg6RHzufBEHM= Received: by 10.224.53.105 with SMTP id l41mr293922qag.365.1267678419999; Wed, 03 Mar 2010 20:53:39 -0800 (PST) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id 5sm18552018qwg.43.2010.03.03.20.53.39 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Mar 2010 20:53:39 -0800 (PST) Date: Wed, 3 Mar 2010 23:53:33 -0500 From: Alexander Kabaev To: freebsd-mips@freebsd.org Message-ID: <20100303235333.794674a4@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/+5sS/EPljUHVmZq/wFqAbda"; protocol="application/pgp-signature" Subject: Missing hack to resolve umass issues on RouterStation Pro 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, 04 Mar 2010 05:21:26 -0000 --Sig_/+5sS/EPljUHVmZq/wFqAbda Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, in order to fix issues with umass on RouterStation Pro, I had to fix/hack the kenel in two places. One was related in the way we handled partial cache line invaidations and I committed it to -current already as http://svn.freebsd.org/changeset/base/203080. Another one is a hack that is not suitable for inclusion into official sources, but still is good enough to get RouterStation Pro to work reliably. Get it from here: http://people.freebsd.org/~kan/usb_rspro.diff I would appreciate if people who still have issues getting their USB-attached storage working reliably with RSPro can test it and report success/failure. Thanks, --=20 Alexander Kabaev --Sig_/+5sS/EPljUHVmZq/wFqAbda Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFLjzzSQ6z1jMm+XZYRAjHaAKCh1XKSX9oIE+zi63nwxJzifQgWeACghRcL j6bUw2FgKiBK3h1i8toEJd0= =lvpF -----END PGP SIGNATURE----- --Sig_/+5sS/EPljUHVmZq/wFqAbda-- From owner-freebsd-mips@FreeBSD.ORG Thu Mar 4 05:53:42 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 6EFB91065672 for ; Thu, 4 Mar 2010 05:53:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3FC8FC1D for ; Thu, 4 Mar 2010 05:53:41 +0000 (UTC) Received: by gwaa20 with SMTP id a20so1207100gwa.13 for ; Wed, 03 Mar 2010 21:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=uROo0lxyFgpu0/7p9TE5A2Ke3CvS6EEmqGpPUkZP5JM=; b=TVo9Uxmc8N4CaVLNkMuMP3H6hlMrH1Kz69VUqYi9d9llt2fVwZ0n9SBgzblCoaELqB BgyteqbP2w6Asst2+NIo8zHUx8MQ+Q0mNKPBFWRiSKbD/f9s/khzBiyj2OWbGH+N9vV9 eN//mSRUhr33zmGZDJCMZ37Mtiy5fphs4ECDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=PFhXlDSDFWmcXRmLJisG6Z96L28wZHbJySTpj/KrUAyiO++lKoEOOqFqgJqQ3B96ev A3TBJwTPntgvvHQhTTNWGYOLgr9LOm5rryBtUDocfmJ/xZIsb5rwgYfISn/13T1Z0loS qSVQiHh4VMHzkecLoO/oLZGI1DwuVCk1v7as4= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.101.130.5 with SMTP id h5mr4363039ann.116.1267682010598; Wed, 03 Mar 2010 21:53:30 -0800 (PST) In-Reply-To: <20100303235333.794674a4@kan.dnsalias.net> References: <20100303235333.794674a4@kan.dnsalias.net> Date: Thu, 4 Mar 2010 13:53:30 +0800 X-Google-Sender-Auth: fd405be2f5e96c5c Message-ID: From: Adrian Chadd To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: Missing hack to resolve umass issues on RouterStation Pro 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, 04 Mar 2010 05:53:42 -0000 On 4 March 2010 12:53, Alexander Kabaev wrote: > Hi, > > in order to fix issues with umass on RouterStation Pro, I had to > fix/hack the kenel in two places. One was related in the way we handled > partial cache line invaidations and I committed it to -current already > as http://svn.freebsd.org/changeset/base/203080. > > Another one is a hack that is not suitable for inclusion into official > sources, but still is good enough to get RouterStation Pro to work > reliably. Get it from here: > > http://people.freebsd.org/~kan/usb_rspro.diff > > I would appreciate if people who still have issues getting their > USB-attached storage working reliably with RSPro can test it and report > success/failure. It works fine for me. I do see occasional segfault-on-exec which I wonder whether is due to USB or VM/TLB magic; this smells somewhat like it could be both. I'll have to re-test things on an NFS root (and hope there's not MIPS/rspro-y issues with the NFS and NIC code. :) Is this USB alignment patch something that is needed for all MIPS/USB stuff, or just this specific SoC. If so, why? And will it potentially be an issue with other SoCs? Adrian From owner-freebsd-mips@FreeBSD.ORG Thu Mar 4 06:22:43 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 81C11106564A for ; Thu, 4 Mar 2010 06:22:43 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-iw0-f183.google.com (mail-iw0-f183.google.com [209.85.223.183]) by mx1.freebsd.org (Postfix) with ESMTP id 400558FC17 for ; Thu, 4 Mar 2010 06:22:42 +0000 (UTC) Received: by iwn13 with SMTP id 13so1850725iwn.14 for ; Wed, 03 Mar 2010 22:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=JZklILbarasEynhd3NnUdeRnQX0Lee6qM8W0qmbOfr0=; b=qRb2IBLGGz4OxG1ys09P0rp0hYAUREYWMAk8V3j/Ye/TsgwHKondDaNT4V9NuMcufE wxgJESnqWwP3DamwhHwM5hUTAXk+LsXUOQlCPNWM5rYaQykriCjCLKtKjUKZMsBDf3JI 0IABS6eoglmPSgV9RlyFHQg2aDlP68SQrk7uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=tEKPR5jvaX7wrUOWUZWrtP+Ttf74M7dP8e+feaMIT/vJ4Wvq5t/D5WKysa7wxIjEzd WAOpAFIl+Mtp1SoyG8cFaGREnhh2i11qGQ9Sz7FQsHI2Bhxo372PR2s6cHRjWYuHIg5K wihQJ6//pIoaum8Ijz5pVRpdS+ZrR8l8cWxy0= Received: by 10.231.146.211 with SMTP id i19mr741390ibv.22.1267683757827; Wed, 03 Mar 2010 22:22:37 -0800 (PST) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id y67sm336329iby.3.2010.03.03.22.22.36 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Mar 2010 22:22:36 -0800 (PST) Date: Thu, 4 Mar 2010 01:22:29 -0500 From: Alexander Kabaev To: Adrian Chadd Message-ID: <20100304012229.3bec1492@kan.dnsalias.net> In-Reply-To: References: <20100303235333.794674a4@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/HpDcetHcX6_L5nG/YTHl4qn"; protocol="application/pgp-signature" Cc: freebsd-mips@freebsd.org Subject: Re: Missing hack to resolve umass issues on RouterStation Pro 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, 04 Mar 2010 06:22:43 -0000 --Sig_/HpDcetHcX6_L5nG/YTHl4qn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 4 Mar 2010 13:53:30 +0800 Adrian Chadd wrote: > On 4 March 2010 12:53, Alexander Kabaev wrote: > > Hi, > > > > in order to fix issues with umass on RouterStation Pro, I had to > > fix/hack the kenel in two places. One was related in the way we > > handled partial cache line invaidations and I committed it to > > -current already as http://svn.freebsd.org/changeset/base/203080. > > > > Another one is a hack that is not suitable for inclusion into > > official sources, but still is good enough to get RouterStation Pro > > to work reliably. Get it from here: > > > > http://people.freebsd.org/~kan/usb_rspro.diff > > > > I would appreciate if people who still have issues getting their > > USB-attached storage working reliably with RSPro can test it and > > report success/failure. >=20 > It works fine for me. I do see occasional segfault-on-exec which I > wonder whether is due to USB or VM/TLB magic; this smells somewhat > like it could be both. I'll have to re-test things on an NFS root (and > hope there's not MIPS/rspro-y issues with the NFS and NIC code. :) >=20 > Is this USB alignment patch something that is needed for all MIPS/USB > stuff, or just this specific SoC. If so, why? And will it potentially > be an issue with other SoCs? >=20 This alignment hack is required for all MIPS or non-MIPS platforms that do not have cache coherent DMA. Our existing USB code allocates buffer used for DMA transfer that shares cache lines with other structures and write accesses to these structures can easily interfere with in-progress DMA transfers by uncontrollably re-dirtying and by the CPU flushing the cache line out. My hack just uses brute force to align the buffer start and end to 32, which happens to be the cache line size on RSPro. If other SOCs use different cache geometry, they should use their cache line size there instead. The proper fix is to make USB stack aware of cache line sizes and unfortunate effects of cache line sharing.=20 --=20 Alexander Kabaev --Sig_/HpDcetHcX6_L5nG/YTHl4qn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFLj1GrQ6z1jMm+XZYRAt1BAJ404agCg6KUG0tFcWhwmPR8MVCfYACg54aN 8Q3p6A550IU3RaPorW5M/n8= =bBH7 -----END PGP SIGNATURE----- --Sig_/HpDcetHcX6_L5nG/YTHl4qn-- From owner-freebsd-mips@FreeBSD.ORG Thu Mar 4 06:34:30 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 3F0F3106564A; Thu, 4 Mar 2010 06:34:30 +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 ED7588FC08; Thu, 4 Mar 2010 06:34:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o246RF0A094815; Wed, 3 Mar 2010 23:27:15 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 03 Mar 2010 23:27:32 -0700 (MST) Message-Id: <20100303.232732.886714142388177854.imp@bsdimp.com> To: adrian@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <20100303235333.794674a4@kan.dnsalias.net> 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: freebsd-mips@FreeBSD.org Subject: Re: Missing hack to resolve umass issues on RouterStation Pro 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, 04 Mar 2010 06:34:30 -0000 In message: Adrian Chadd writes: : On 4 March 2010 12:53, Alexander Kabaev wrote: : > Hi, : > : > in order to fix issues with umass on RouterStation Pro, I had to : > fix/hack the kenel in two places. One was related in the way we handled : > partial cache line invaidations and I committed it to -current already : > as http://svn.freebsd.org/changeset/base/203080. : > : > Another one is a hack that is not suitable for inclusion into official : > sources, but still is good enough to get RouterStation Pro to work : > reliably. Get it from here: : > : > http://people.freebsd.org/~kan/usb_rspro.diff : > : > I would appreciate if people who still have issues getting their : > USB-attached storage working reliably with RSPro can test it and report : > success/failure. : : It works fine for me. I do see occasional segfault-on-exec which I : wonder whether is due to USB or VM/TLB magic; this smells somewhat : like it could be both. I'll have to re-test things on an NFS root (and : hope there's not MIPS/rspro-y issues with the NFS and NIC code. :) That's weird, and something we should track to ground.. : Is this USB alignment patch something that is needed for all MIPS/USB : stuff, or just this specific SoC. If so, why? And will it potentially : be an issue with other SoCs? It is a fundamental flaw in the USB stack. It co-locates data about the transfer and the data from the transfer within a cache-line without the change. As such, bad thing happen to one set of data depending on the scenario. The patch pushes the two apart. All MIPS chips likely suffer from this problem, although their cache line sizes differ. We should export cache-line size in an MI variable from MD code for all CPUs. The USB code should use that to allocate properly aligned data and meta-data buffers for the transfers. Warner From owner-freebsd-mips@FreeBSD.ORG Thu Mar 4 09:17:18 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9032D106566B for ; Thu, 4 Mar 2010 09:17:18 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 49B108FC08 for ; Thu, 4 Mar 2010 09:17:17 +0000 (UTC) Received: from gw ([192.168.10.10] helo=terran) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Nn78l-0002Eb-38; Thu, 04 Mar 2010 11:14:43 +0200 Date: Thu, 4 Mar 2010 11:16:47 +0200 From: Alexandr Rybalko To: Neel Natu Message-Id: <20100304111647.6ce8fcec.ray@dlink.ua> In-Reply-To: References: <20100303111405.05b3c3b3.ray@dlink.ua> <20100303.053716.584432776655158376.imp@bsdimp.com> <20100303150238.68be18a3.ray@dlink.ua> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mips@freebsd.org Subject: Re: MIPS_MEM_RID 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, 04 Mar 2010 09:17:18 -0000 On Wed, 3 Mar 2010 11:46:37 -0800 Neel Natu wrote: >> Hi Alexandr, >> >> On Wed, Mar 3, 2010 at 5:02 AM, Alexandr Rybalko wrote: >> > On Wed, 03 Mar 2010 05:37:16 -0700 (MST) >> > "M. Warner Losh" wrote: >> > >> >>> In message: <20100303111405.05b3c3b3.ray@dlink.ua> >> >>> Alexandr Rybalko writes: >> >>> >> >>> : Question: We really need MIPS_MEM_RID different form other >> >>> : platforms? I work on siba drivers, and we already know what siba >> >>> : can be in not MIPS device. Such as Broadcom Wi-Fi cards. >> >>> >> >>> I don't understand this question. It doesn't look like we define >> >>> MIPS_MEM_RID at all for mips. It looks to be purely an internal thing >> >>> to sys/dev/siba/siba.c. >> >>> >> >>> Warner >> > >> > I apologize for my English and for the question. >> > >> > There remained only the small tail :) >> > sys/mips/mips/nexus.c:76: #define MIPS_MEM_RID 0x20 >> > >> >> Do you want to get rid of this macro from nexus.c? I don't see anybody >> using it so it should be fine. >> Yes, I looked at the code and deleted the reference MIPS_MEM_RID. Work fine :) >> best >> Neel >> >> > Sorry that took time. >> > >> > -- >> > Alexandr Rybalko >> > aka Alex RAY >> > _______________________________________________ >> > freebsd-mips@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >> > -- Рыбалко Александр Консультант D-Link Украина From owner-freebsd-mips@FreeBSD.ORG Fri Mar 5 10:15:37 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 87D901065672; Fri, 5 Mar 2010 10:15:37 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pz0-f199.google.com (mail-pz0-f199.google.com [209.85.222.199]) by mx1.freebsd.org (Postfix) with ESMTP id 5D56B8FC0A; Fri, 5 Mar 2010 10:15:37 +0000 (UTC) Received: by pzk37 with SMTP id 37so2419169pzk.7 for ; Fri, 05 Mar 2010 02:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=1NVrYK3+UeX1nM1KepxbOdmipUw7fImSsxtzJ991Rbc=; b=hpjrWLKyNMNItSQMKDQEAOzUX4slq7EkIzUj3wEgf1uB5IEsQHTxMCtXPqHK/L0ION Lf9qQXwcIKssaidxg6MvR/1c/K86DYp+OuBiRBvp7CJoCmhRwXac2IYvKHSUXpbfdjkR rERd4NOn1ydkAXQgYQaTKv1bPry3WR1pUHhKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=wwvgZEPeapOrn6U0rdfY/1W4pNKexIWhvzKTQ3N8ok9TpFQ+rAf+B1MK+WeL0lfVPb k555IC4IbXQH5Se1PxzSsSoRpWSpEoPGVHYidV4MkDLNLLXoo4IOCeTHIWxKA17ucKNt FcDLnzqwN+vGXrRTsvljZl5ngSVsEZbkXvykU= MIME-Version: 1.0 Received: by 10.141.23.16 with SMTP id a16mr454110rvj.290.1267784131094; Fri, 05 Mar 2010 02:15:31 -0800 (PST) Date: Fri, 5 Mar 2010 15:45:31 +0530 Message-ID: <98a59be81003050215m753799dbu35d2b2eab65e75db@mail.gmail.com> From: "C. Jayachandran" To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: n64/n32 - build 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: Fri, 05 Mar 2010 10:15:37 -0000 I've updated the patches for building n64 and n32 kernel and userspace, please review. The patches are: Tool chain support for n64 and n32:: http://sites.google.com/site/cjayachandran/files/n64-n32-toolchain.patch This updates the gcc configuration to provide the default ABI, linker scripts and endianness flags during n64/n32 and o32 builds. With this change, we don't need the -Wl, flags for linker emulation, the mabi flags or the -EB/-EL for compiler. I had to add a make variable in TARGET_DEFINES in gnu/usr.bin/cc/Makefile.tgt and use that to pass the defaults while creating 'tm.h' - this change is not MIPS-specific. User/kernel build with n64 and n32: http://sites.google.com/site/cjayachandran/files/n64-n32-build.patch updated bsd.cpu.mk which does not set LDFLAGS, adds ldscript.mips.n32 and removes unnecessary flags from Makefile.mips. Thanks, JC. From owner-freebsd-mips@FreeBSD.ORG Fri Mar 5 15:22:34 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 5BF6A106566B; Fri, 5 Mar 2010 15:22:34 +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 DD2288FC15; Fri, 5 Mar 2010 15:22:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o25FJU6O016602; Fri, 5 Mar 2010 08:19:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 05 Mar 2010 08:19:48 -0700 (MST) Message-Id: <20100305.081948.255476964173693445.imp@bsdimp.com> To: c.jayachandran@gmail.com From: "M. Warner Losh" In-Reply-To: <98a59be81003050215m753799dbu35d2b2eab65e75db@mail.gmail.com> References: <98a59be81003050215m753799dbu35d2b2eab65e75db@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: jmallett@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: n64/n32 - build 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: Fri, 05 Mar 2010 15:22:34 -0000 CJ, Thanks for all the work in this area. I know that Julie Mallett is also working in this area, and I've done some work to clean up the build system. I'm afraid that we now have some conflicts between the different efforts, and that it may take a little to resolve the conflicts. In message: <98a59be81003050215m753799dbu35d2b2eab65e75db@mail.gmail.com> "C. Jayachandran" writes: : I've updated the patches for building n64 and n32 kernel and : userspace, please review. The patches are: : : Tool chain support for n64 and n32:: : http://sites.google.com/site/cjayachandran/files/n64-n32-toolchain.patch : This updates the gcc configuration to provide the default ABI, linker : scripts and endianness flags during n64/n32 and o32 builds. With this : change, we don't need the -Wl, flags for linker emulation, the mabi : flags or the -EB/-EL for compiler. This part of the patch looks good. : I had to add a make variable in TARGET_DEFINES in : gnu/usr.bin/cc/Makefile.tgt and use that to pass the defaults while : creating 'tm.h' - this change is not MIPS-specific. TARGET_DEFINES is OK. I'm not sure about the other Makefile variables and would like to find some way to not need them. : User/kernel build with n64 and n32: : http://sites.google.com/site/cjayachandran/files/n64-n32-build.patch : : updated bsd.cpu.mk which does not set LDFLAGS, adds ldscript.mips.n32 : and removes unnecessary flags from Makefile.mips. +.if ${MACHINE_ARCH} == "mips" +. if defined(TARGET_64BIT) +. if defined(TARGET_BIG_ENDIAN) +LD += -melf64btsmip_fbsd +. else +LD += -melf64ltsmip_fbsd +. endif +. elif defined(TARGET_N32) +. if defined(TARGET_BIG_ENDIAN) +LD += -melf32btsmipn32_fbsd +. else +LD += -melf32ltsmipn32_fbsd +. endif I'd rather find some way to avoid adding TARGET_64BIT, TARGET_N32. I've been working to eliminate TARGET_BIG_ENDIAN because it is proving to be unworkable in practice, especially as these machines become more self-hosting. If you don't mind, I'll pull in the parts that don't conflict with the other work in this area, and we can then look at the harder problem of which pieces of that goes in. Warner From owner-freebsd-mips@FreeBSD.ORG Fri Mar 5 16:23:20 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 277E51065686; Fri, 5 Mar 2010 16:23:20 +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 E86408FC1D; Fri, 5 Mar 2010 16:23:19 +0000 (UTC) Received: by pwj1 with SMTP id 1so2737825pwj.13 for ; Fri, 05 Mar 2010 08:23: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=/YrrboqI4ecLw6OBAZpblt85rGwzxSdx1CDuEh3SlqQ=; b=Csatrst/w1J/A5Ffi6WlsB0yzGl6S+oeBjkCo9OgYpOwqkkuRp0ogN6ZlYYIgp7TuA gFaGspTZT4QHvr6DYLrRnx+daXmR/0Z9vvThcdI+XmHi+wa4SZ2tOUCPGvLorT8rhEAo OT+L7kMSbUZzi0yOMtD0MX7hWdeFrNz/U0W6U= 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=Iv8ctofIYqkROOL+nlxpO2aBdmxjCPSGwJUy+Y7P7iqpdGWrZvAUrpiP/OWPC/fW9H D/TmRTbEOuywIeG2HxN7UWiqYWsKXur1y6aK/dKFYQCrTqZdmcpyKIC+bnrAIRXhS9te gxEkSkVZKptCcXBL0zDKILy0D5AH2kbHdrOXg= MIME-Version: 1.0 Received: by 10.140.55.5 with SMTP id d5mr730584rva.243.1267806193751; Fri, 05 Mar 2010 08:23:13 -0800 (PST) In-Reply-To: <20100305.081948.255476964173693445.imp@bsdimp.com> References: <98a59be81003050215m753799dbu35d2b2eab65e75db@mail.gmail.com> <20100305.081948.255476964173693445.imp@bsdimp.com> Date: Fri, 5 Mar 2010 21:53:13 +0530 Message-ID: <98a59be81003050823r57b5dc4alfc58018ffbb74731@mail.gmail.com> From: "C. Jayachandran" To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: n64/n32 - build 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: Fri, 05 Mar 2010 16:23:20 -0000 On Fri, Mar 5, 2010 at 8:49 PM, M. Warner Losh wrote: > CJ, > > Thanks for all the work in this area. =A0I know that Julie Mallett is > also working in this area, and I've done some work to clean up the > build system. =A0I'm afraid that we now have some conflicts between the > different efforts, and that it may take a little to resolve the > conflicts. This is okay, I can rebase the patch when the other efforts are in, (or can merge other efforts after this goes in). I need a base on which to start work on n64/n32 and I'm making my changes available as it may be useful for others working in the same area. Regards, JC. > In message: <98a59be81003050215m753799dbu35d2b2eab65e75db@mail.gmail.com> > =A0 =A0 =A0 =A0 =A0 =A0"C. Jayachandran" write= s: > : I've updated the patches for building n64 and n32 kernel and > : userspace, =A0please review. The patches are: > : > : Tool chain support for n64 and n32:: > : http://sites.google.com/site/cjayachandran/files/n64-n32-toolchain.patc= h > > : This updates the gcc configuration =A0to provide the default ABI, linke= r > : scripts and endianness flags during n64/n32 and o32 builds. With this > : change, we don't need the -Wl, flags for linker emulation, the mabi > : flags or the -EB/-EL for compiler. > > This part of the patch looks good. > > : I had to add a make variable in TARGET_DEFINES in > : gnu/usr.bin/cc/Makefile.tgt and use that to pass the defaults while > : creating 'tm.h' - this change is not MIPS-specific. > > TARGET_DEFINES is OK. =A0I'm not sure about the other Makefile variables > and would like to find some way to not need them. > > : User/kernel build with n64 and n32: > : http://sites.google.com/site/cjayachandran/files/n64-n32-build.patch > : > : updated bsd.cpu.mk which does not set LDFLAGS, adds ldscript.mips.n32 > : and removes unnecessary flags from Makefile.mips. > > +.if ${MACHINE_ARCH} =3D=3D "mips" > +. if defined(TARGET_64BIT) > +. =A0if defined(TARGET_BIG_ENDIAN) > +LD +=3D -melf64btsmip_fbsd > +. =A0else > +LD +=3D =A0-melf64ltsmip_fbsd > +. =A0endif > +. elif defined(TARGET_N32) > +. =A0if defined(TARGET_BIG_ENDIAN) > +LD +=3D -melf32btsmipn32_fbsd > +. =A0else > +LD +=3D =A0-melf32ltsmipn32_fbsd > +. =A0endif > > I'd rather find some way to avoid adding TARGET_64BIT, TARGET_N32. > I've been working to eliminate TARGET_BIG_ENDIAN because it is proving > to be unworkable in practice, especially as these machines become more > self-hosting. > > If you don't mind, I'll pull in the parts that don't conflict with the > other work in this area, and we can then look at the harder problem of > which pieces of that goes in. > > Warner > --=20 C. Jayachandran c.jayachandran@gmail.com From owner-freebsd-mips@FreeBSD.ORG Fri Mar 5 16:51:28 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 D63941065677; Fri, 5 Mar 2010 16:51:28 +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 852948FC30; Fri, 5 Mar 2010 16:51:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o25Gi72L017505; Fri, 5 Mar 2010 09:44:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 05 Mar 2010 09:44:26 -0700 (MST) Message-Id: <20100305.094426.635700942582031821.imp@bsdimp.com> To: c.jayachandran@gmail.com From: "M. Warner Losh" In-Reply-To: <98a59be81003050823r57b5dc4alfc58018ffbb74731@mail.gmail.com> References: <98a59be81003050215m753799dbu35d2b2eab65e75db@mail.gmail.com> <20100305.081948.255476964173693445.imp@bsdimp.com> <98a59be81003050823r57b5dc4alfc58018ffbb74731@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: freebsd-mips@freebsd.org Subject: Re: n64/n32 - build 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: Fri, 05 Mar 2010 16:51:29 -0000 In message: <98a59be81003050823r57b5dc4alfc58018ffbb74731@mail.gmail.co= m> "C. Jayachandran" writes: : On Fri, Mar 5, 2010 at 8:49 PM, M. Warner Losh wrote= : : > CJ, : > : > Thanks for all the work in this area. =A0I know that Julie Mallett = is : > also working in this area, and I've done some work to clean up the : > build system. =A0I'm afraid that we now have some conflicts between= the : > different efforts, and that it may take a little to resolve the : > conflicts. : = : This is okay, I can rebase the patch when the other efforts are in, : (or can merge other efforts after this goes in). I need a base on : which to start work on n64/n32 and I'm making my changes available as= : it may be useful for others working in the same area. Excellent. And your patches often fill in holes that others haven't gotten to yet. I think between everybody working in this area, we'll have a really good solution to the problem. BTW, have you given any thought to multilib yet? :) Warner : Regards, : JC. : = : = : > In message: <98a59be81003050215m753799dbu35d2b2eab65e75db@mail.gmai= l.com> : > =A0 =A0 =A0 =A0 =A0 =A0"C. Jayachandran" = writes: : > : I've updated the patches for building n64 and n32 kernel and : > : userspace, =A0please review. The patches are: : > : : > : Tool chain support for n64 and n32:: : > : http://sites.google.com/site/cjayachandran/files/n64-n32-toolchai= n.patch : > : > : This updates the gcc configuration =A0to provide the default ABI,= linker : > : scripts and endianness flags during n64/n32 and o32 builds. With = this : > : change, we don't need the -Wl, flags for linker emulation, the ma= bi : > : flags or the -EB/-EL for compiler. : > : > This part of the patch looks good. : > : > : I had to add a make variable in TARGET_DEFINES in : > : gnu/usr.bin/cc/Makefile.tgt and use that to pass the defaults whi= le : > : creating 'tm.h' - this change is not MIPS-specific. : > : > TARGET_DEFINES is OK. =A0I'm not sure about the other Makefile vari= ables : > and would like to find some way to not need them. : > : > : User/kernel build with n64 and n32: : > : http://sites.google.com/site/cjayachandran/files/n64-n32-build.pa= tch : > : : > : updated bsd.cpu.mk which does not set LDFLAGS, adds ldscript.mips= .n32 : > : and removes unnecessary flags from Makefile.mips. : > : > +.if ${MACHINE_ARCH} =3D=3D "mips" : > +. if defined(TARGET_64BIT) : > +. =A0if defined(TARGET_BIG_ENDIAN) : > +LD +=3D -melf64btsmip_fbsd : > +. =A0else : > +LD +=3D =A0-melf64ltsmip_fbsd : > +. =A0endif : > +. elif defined(TARGET_N32) : > +. =A0if defined(TARGET_BIG_ENDIAN) : > +LD +=3D -melf32btsmipn32_fbsd : > +. =A0else : > +LD +=3D =A0-melf32ltsmipn32_fbsd : > +. =A0endif : > : > I'd rather find some way to avoid adding TARGET_64BIT, TARGET_N32. : > I've been working to eliminate TARGET_BIG_ENDIAN because it is prov= ing : > to be unworkable in practice, especially as these machines become m= ore : > self-hosting. : > : > If you don't mind, I'll pull in the parts that don't conflict with = the : > other work in this area, and we can then look at the harder problem= of : > which pieces of that goes in. : > : > Warner : > : = : = : = : -- = : C. Jayachandran c.jayachandran@gmail.com : = : = From owner-freebsd-mips@FreeBSD.ORG Fri Mar 5 18:23:57 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17F581065672; Fri, 5 Mar 2010 18:23:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BB19D8FC0A; Fri, 5 Mar 2010 18:23:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o25INutq094829; Fri, 5 Mar 2010 13:23:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o25INtWo094820; Fri, 5 Mar 2010 18:23:55 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 5 Mar 2010 18:23:55 GMT Message-Id: <201003051823.o25INtWo094820@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 18:23:57 -0000 TB --- 2010-03-05 18:12:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-05 18:12:25 - starting HEAD tinderbox run for mips/mips TB --- 2010-03-05 18:12:25 - cleaning the object tree TB --- 2010-03-05 18:12:34 - cvsupping the source tree TB --- 2010-03-05 18:12:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-03-05 18:12:58 - building world TB --- 2010-03-05 18:12:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-05 18:12:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-05 18:12:58 - TARGET=mips TB --- 2010-03-05 18:12:58 - TARGET_ARCH=mips TB --- 2010-03-05 18:12:58 - TZ=UTC TB --- 2010-03-05 18:12:58 - __MAKE_CONF=/dev/null TB --- 2010-03-05 18:12:58 - cd /src TB --- 2010-03-05 18:12:58 - /usr/bin/make -B buildworld >>> World build started on Fri Mar 5 18:12:59 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] /obj/mips/src/tmp/usr/bin/ld: /obj/mips/src/tmp/usr/lib/crtendS.o: endianness incompatible with that of the selected emulation /obj/mips/src/tmp/usr/bin/ld: failed to merge target specific data of file /obj/mips/src/tmp/usr/lib/crtendS.o /obj/mips/src/tmp/usr/bin/ld: /obj/mips/src/tmp/usr/lib/crtn.o: compiled for a little endian system and target is big endian /obj/mips/src/tmp/usr/bin/ld: /obj/mips/src/tmp/usr/lib/crtn.o: endianness incompatible with that of the selected emulation /obj/mips/src/tmp/usr/bin/ld: failed to merge target specific data of file /obj/mips/src/tmp/usr/lib/crtn.o cc: Internal error: Segmentation fault: 11 (program ld) Please submit a full bug report. See for instructions. *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-05 18:23:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-05 18:23:55 - ERROR: failed to build world TB --- 2010-03-05 18:23:55 - 483.83 user 95.18 system 690.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full