From owner-linux-mips@oss.sgi.com Tue May 1 02:43:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f419h4415104 for linux-mips-outgoing; Tue, 1 May 2001 02:43:04 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f419h4M15101 for ; Tue, 1 May 2001 02:43:04 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA02275 for ; Tue, 1 May 2001 02:43:09 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id CAA18059 for ; Tue, 1 May 2001 02:43:06 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id LAA12301 for ; Tue, 1 May 2001 11:42:16 +0200 (MEST) Message-ID: <3AEE84F8.6BC907A7@mips.com> Date: Tue, 01 May 2001 11:42:16 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Login problem on a serial console Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have just upgraded my kernel sources from 2.4.1 to the latest 2.4.3 sources, but after doing that I can't login on my serial console. It get all the way up to the login prompt, but nothing happens when I try to press a key. So I figure that the serial line worked one way. I have tried using a single shell (booted with "init=/bin/sh") and that seemed to work fine, so I guess the serial driver works fine. I'm running on both an Atlas and a Malta board, both seem to have the same problem. Has anyone any ideas ? /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue May 1 02:57:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f419v6015640 for linux-mips-outgoing; Tue, 1 May 2001 02:57:06 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f419v5M15637 for ; Tue, 1 May 2001 02:57:05 -0700 Received: from scotty.mgnet.de (pD957B425.dip.t-dialin.net [217.87.180.37]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id LAA29019 for ; Tue, 1 May 2001 11:57:03 +0200 (MET DST) Received: (qmail 21348 invoked from network); 1 May 2001 09:57:02 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 1 May 2001 09:57:02 -0000 Date: Tue, 1 May 2001 11:57:02 +0200 (CEST) From: Klaus Naumann To: Carsten Langgaard cc: linux-mips@oss.sgi.com Subject: Re: Login problem on a serial console In-Reply-To: <3AEE84F8.6BC907A7@mips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 1 May 2001, Carsten Langgaard wrote: > I have just upgraded my kernel sources from 2.4.1 to the latest 2.4.3 > sources, but after doing that I can't login on my serial console. It get > all the way up to the login prompt, but nothing happens when I try to > press a key. So I figure that the serial line worked one way. > I have tried using a single shell (booted with "init=/bin/sh") and that > seemed to work fine, so I guess the serial driver works fine. > > I'm running on both an Atlas and a Malta board, both seem to have the > same problem. > Has anyone any ideas ? I think this has something to do with the fixes Bachus commited lately. I think he changed something which made some getty's not work anymore. Can you try an other getty ? Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Tue May 1 03:20:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41AKhZ16386 for linux-mips-outgoing; Tue, 1 May 2001 03:20:43 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41AKgM16383 for ; Tue, 1 May 2001 03:20:42 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA02442; Tue, 1 May 2001 03:20:45 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id DAA18791; Tue, 1 May 2001 03:20:43 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id MAA14029; Tue, 1 May 2001 12:19:53 +0200 (MEST) Message-ID: <3AEE8DC8.DCCCFA9B@mips.com> Date: Tue, 01 May 2001 12:19:52 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Klaus Naumann CC: linux-mips@oss.sgi.com Subject: Re: Login problem on a serial console References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Klaus Naumann wrote: > On Tue, 1 May 2001, Carsten Langgaard wrote: > > > I have just upgraded my kernel sources from 2.4.1 to the latest 2.4.3 > > sources, but after doing that I can't login on my serial console. It get > > all the way up to the login prompt, but nothing happens when I try to > > press a key. So I figure that the serial line worked one way. > > I have tried using a single shell (booted with "init=/bin/sh") and that > > seemed to work fine, so I guess the serial driver works fine. > > > > I'm running on both an Atlas and a Malta board, both seem to have the > > same problem. > > Has anyone any ideas ? > > I think this has something to do with the fixes Bachus commited > lately. I think he changed something which made some getty's > not work anymore. Can you try an other getty ? I tried another getty and that seem to work, thanks. Do you know what break things, so I could redo Bachus fixes ? > > Klaus > > -- > Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) > Nickname : Spock | Org.: Mad Guys Network > Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) > PGP Key : www.mgnet.de/keys/key_spock.txt -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue May 1 08:32:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41FWxl26943 for linux-mips-outgoing; Tue, 1 May 2001 08:32:59 -0700 Received: from mail5.svr.pol.co.uk (mail5.svr.pol.co.uk [195.92.193.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41FWtM26940 for ; Tue, 1 May 2001 08:32:56 -0700 Received: from modem-9.uranium.dialup.pol.co.uk ([62.136.65.137] helo=derfel) by mail5.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14uc8w-00016Q-00; Tue, 01 May 2001 16:32:52 +0100 From: "Andrew Linfoot" To: "'Guido Guenther'" Cc: Subject: RE: Passing kernel args Date: Tue, 1 May 2001 16:31:47 +0100 Message-ID: <000001c0d253$f36e3b20$0101a8c0@derfel> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010424230923.A5906@bilbo.physik.uni-konstanz.de> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk My fault i'm afraid! I had used an old kernel without the neccessary patches. I am now using 2.4.3 and everthing works fine. Sorry for any hassle this has caused. Andy -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Guido Guenther Sent: 24 April 2001 22:09 To: Andrew Linfoot Cc: linux-mips@oss.sgi.com Subject: Re: Passing kernel args On Tue, Apr 24, 2001 at 08:09:13PM +0100, Andrew Linfoot wrote: > Just thought i would let you know of my experience with autobooting. > > I'm having the same problems as Dave in that i must specify a space in > the OSLoadOptions " root=/dev/sda1 ro". However every time i shutdown or > reboot it is truncated to OSLoadOptions= root=/dev/s meaning i have to reset > it after every reboot. Could you please send me the kernel command line with and without using the space (e.g. dmesg | grep "command line") - i still don't see what this should be good for. BTW no need to give root= in OSLoadOptions, you can use OSLoadPartition instead. > > any ideas as to what may be causing this? > I am runnning on an Indy R5K It seems the space in the PROM for OSLoadOptions is quiet limited. The space available seems to differ between different PROM versions though(see the HOWTO, it's in there). > > Also i am using an ELF kernel and not ECOFF as specified in Guido's howto. Doesn't make a difference. ECOFF is just a save bet. -- Guido From owner-linux-mips@oss.sgi.com Tue May 1 16:29:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41NTP702903 for linux-mips-outgoing; Tue, 1 May 2001 16:29:25 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41NTNF02900 for ; Tue, 1 May 2001 16:29:23 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f41NTIv25503; Tue, 1 May 2001 16:29:18 -0700 (PDT) Date: Tue, 1 May 2001 16:29:18 -0700 (PDT) From: "John D. Davis" To: Subject: NFS -13 error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am having a problem installing linux on a 4400 indy. I downloaded a "fixed" version from: honk.physik.uni-konstanz,de/linux-mips/install and downloaded : root-be-0.04.cpio I also got the 2.4 vmlinux kernel from the sgi website. I am trying to load linux from another Indy running IRIX 6.2. Bootp and tftp seem to work but the nfs mount fails with an error -13 and getfh says the file or directory don't exist. The /etc/hosts has the machine IP address and name. /etc/ethers has the HW to IP address mapping. I also modified the /etc/bootptab and /var/dhcp/config/config... file. The SYSLOG mount request on server is this: May 1 14:39:38 7D:littledipper mountd[861]: mount request for /tftpboot/171.64.72.150: getfh failed: No such file or directory I set the client as root in /etc/exports: /ld2 \ ... -root=171.64.72.150,rw The no_root_squash flag doesn't seem to apply for IRIX. Should I be using a different distribution of Linux for SGI? The NFS mount error of /tftpboot/171.64.72.150 is a directory that I did not specify. Am I missing something? I looked through the archives and searched for the info on the web and did not find anything that helped. Thank you for your assistance, john davis From owner-linux-mips@oss.sgi.com Wed May 2 06:42:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42DgH603449 for linux-mips-outgoing; Wed, 2 May 2001 06:42:17 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42DeJF03397; Wed, 2 May 2001 06:40:35 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA25652; Wed, 2 May 2001 15:21:11 +0200 (MET DST) Date: Wed, 2 May 2001 15:21:11 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Florian Lohoff , Pete Popov , linux-mips@oss.sgi.com Subject: Re: Illegal instruction - a workaround or fix ? In-Reply-To: <20010430172419.B30998@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 30 Apr 2001, Ralf Baechle wrote: > > It could be doable with __builtin_frame_address(). Haven't investigated > > it further, though. > > MIPS ABI doesn't define that ra gets stored at a constant offset in > the stackframe, so that won't work. Hmm, I think we check look how gcc gets __builtin_return_address() (specifically for levels greater than 0) and use the same way. We don't need to stick to the ABI in the kernel (building non-PIC we already violate it anyway) and we can assume the code is to be built by gcc. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 2 06:54:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42DsTj04582 for linux-mips-outgoing; Wed, 2 May 2001 06:54:29 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42DsQF04579 for ; Wed, 2 May 2001 06:54:26 -0700 Received: from bilbo.physik.uni-konstanz.de [134.34.144.81] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 14ux5E-00042U-00; Wed, 02 May 2001 15:54:24 +0200 Received: from agx by bilbo.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 14ux5E-0002Po-00; Wed, 02 May 2001 15:54:24 +0200 Date: Wed, 2 May 2001 15:54:24 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: NFS -13 error Message-ID: <20010502155424.A9256@bilbo.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from johnd@Stanford.EDU on Tue, May 01, 2001 at 04:29:18PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 01, 2001 at 04:29:18PM -0700, John D. Davis wrote: > > I am having a problem installing linux on a 4400 indy. I downloaded a > "fixed" version from: honk.physik.uni-konstanz,de/linux-mips/install > and downloaded : > root-be-0.04.cpio This one is *very* outdated. Don't use it. It's there for purely "historic reasons". See ftp://ftp.uni-mainz.de/pub/Linux/debian-local/mips/ for an up to date root image. -- Guido From owner-linux-mips@oss.sgi.com Wed May 2 07:13:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42ED9K05606 for linux-mips-outgoing; Wed, 2 May 2001 07:13:09 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42ECSF05593; Wed, 2 May 2001 07:12:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA26564; Wed, 2 May 2001 16:12:13 +0200 (MET DST) Date: Wed, 2 May 2001 16:12:13 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jun Sun , Ian Soanes , Michael Shmulevich , Linux/MIPS Subject: Re: usermode gdb / remote gdb In-Reply-To: <20010426010457.A11453@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 26 Apr 2001, Ralf Baechle wrote: > > Hmm, I added linux-mips target for gdbserver in gdb 4.17. And I thought Ralf > > sent the patch back to FSF (as I had to fill out some copyright forms). > > Perhaps it is lost somewhere? > > As most of the 4.17 work was done by David Miller it's not upto me to > contribute the patches back. I have ported 4.17 changes to 5.0. They are available at my FTP site. I have submitted changes I wrote myself to the gdb team. I have submitting other changes on my to-do list -- it requires checking the changes against the current CVS version and contacting all interested parties. As I lack time at the moment I cannot promise I'll do it in the foreseeable future. If anyone wants to do it -- feel free. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 2 13:01:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42K1Q112445 for linux-mips-outgoing; Wed, 2 May 2001 13:01:26 -0700 Received: from sprint02.rtmx.net (IDENT:qmailr@sprint02.RTMX.NET [208.31.160.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f42K1OF12439 for ; Wed, 2 May 2001 13:01:24 -0700 Received: (qmail 24708 invoked by uid 102); 2 May 2001 20:01:23 -0000 Received: from host098.momenco.com (HELO beagle) (64.169.228.98) by 208.31.160.29 with SMTP; 2 May 2001 20:01:23 -0000 From: "Matthew Dharm" To: "Linux-MIPS" Subject: Endianness... Date: Wed, 2 May 2001 13:01:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk What's the preferred endianness for Linux-MIPS? I can't really go into why I'm asking (sensitive NDA information), but I'm basically faced with a group that wants to work in LE. However, my understanding was that Linux-MIPS generally ran BE. Or can it be built either way? I know OpenBSD runs LE.... not like that means anything to this group, tho. Matt Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From owner-linux-mips@oss.sgi.com Wed May 2 13:03:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42K3tN13423 for linux-mips-outgoing; Wed, 2 May 2001 13:03:55 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42K3rF13408 for ; Wed, 2 May 2001 13:03:53 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA23666; Wed, 2 May 2001 16:03:21 -0400 Date: Wed, 2 May 2001 16:03:21 -0400 (EDT) From: X-Sender: nick@ns To: Matthew Dharm cc: Linux-MIPS Subject: Re: Endianness... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk To the best of my knowledge Big endian is generally the way to run. Nick On Wed, 2 May 2001, Matthew Dharm wrote: > What's the preferred endianness for Linux-MIPS? I can't really go > into why I'm asking (sensitive NDA information), but I'm basically > faced with a group that wants to work in LE. However, my > understanding was that Linux-MIPS generally ran BE. > > Or can it be built either way? I know OpenBSD runs LE.... not like > that means anything to this group, tho. > > Matt Dharm > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > From owner-linux-mips@oss.sgi.com Wed May 2 13:17:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42KHwT18512 for linux-mips-outgoing; Wed, 2 May 2001 13:17:58 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42KHuF18504 for ; Wed, 2 May 2001 13:17:56 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA21919; Wed, 2 May 2001 13:18:01 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA10366; Wed, 2 May 2001 13:17:59 -0700 (PDT) Message-ID: <018301c0d345$8f56abc0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Matthew Dharm" , "Linux-MIPS" References: Subject: Re: Endianness... Date: Wed, 2 May 2001 22:21:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have one machine set up each way, an Algorithmics P5064/R5260 running LE on a 2.2.12 kernel and a MIPS Malta/4KC running BE under 2.4.1. There are pros and cons. On one hand, most of the "bleeding edge" work is only tested on BE SGI platforms before being checked-in, and the BE userland binary distributions are more complete. On the other hand, it's generally easier to port drivers for x86-oriented peripherals to a LE kernel. Regards, Kevin K. ----- Original Message ----- From: "Matthew Dharm" To: "Linux-MIPS" Sent: Wednesday, May 02, 2001 10:01 PM Subject: Endianness... > What's the preferred endianness for Linux-MIPS? I can't really go > into why I'm asking (sensitive NDA information), but I'm basically > faced with a group that wants to work in LE. However, my > understanding was that Linux-MIPS generally ran BE. > > Or can it be built either way? I know OpenBSD runs LE.... not like > that means anything to this group, tho. > > Matt Dharm > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > From owner-linux-mips@oss.sgi.com Wed May 2 13:48:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42KmOr29338 for linux-mips-outgoing; Wed, 2 May 2001 13:48:24 -0700 Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42KmMF29320 for ; Wed, 2 May 2001 13:48:22 -0700 Received: from fest.stud.fee.vutbr.cz (fest.stud.fee.vutbr.cz [147.229.9.16]) by boco.fee.vutbr.cz (8.11.3/8.11.3) with ESMTP id f42KmJc67694 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 2 May 2001 22:48:20 +0200 (CEST) Received: (from xmichl03@localhost) by fest.stud.fee.vutbr.cz (8.11.2/8.11.2) id f42KmJa91989; Wed, 2 May 2001 22:48:19 +0200 (CEST) From: Michl Ladislav Date: Wed, 2 May 2001 22:48:19 +0200 (CEST) X-processed: pine.send To: Subject: VINO - enabling DMA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk when writing Linux VINO driver i followed documentation found at: ftp://oss.sgi.com/pub/linux/mips/doc/indy/vino/vino.ps shortly (if someone is interested, i can send whole code): /* array of allocated pages */ unsigned long *pages; /* same as above, but contains physical addresses */ unsigned long *buf_desc; /* i hope page starts at 4k boundary ;) */ /* i also know that GFP_DMA is useless for MIPS */ buf_desc = (unsigned long *) __get_free_pages(GFP_KERNEL | GFP_DMA, 0); pages = (unsigned long*) kmalloc(npage * sizeof(unsigned long), GFP_KERNEL)); for (i = 0; i < npage; i++) { pages[i] = __get_free_pages(GFP_KERNEL | GFP_DMA, 0); /* fill with something to see if vino writes data */ memset((void *) pages[i], i, PAGE_SIZE); /* virt_to_bus returns PHYSADDR */ buf_desc[i] = virt_to_bus((void *)pages[i]); mem_map_reserve(virt_to_page(pages[i])); } buf_desc[npage] = VINO_DESC_STOP; /* here set all things according doc (page_index to zero and so on...) ... /* write descriptor table pointer to vino */ vino_reg_write(virt_to_bus(buf_desc), VINO_A_DESC_TLB_PTR); vino_reg_write(virt_to_bus(buf_desc), VINO_A_DESC_PTR); /* and now start DMA */ vino_reg_or(VINO_CTRL_A_DMA_ENBL, VINO_CTRL); after that memory stays untouched, no data are trasferred. any ideas how to make DMA working? or better where to get more complete vino documentation? regards, ladislav michl From owner-linux-mips@oss.sgi.com Wed May 2 13:54:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42KsKP31465 for linux-mips-outgoing; Wed, 2 May 2001 13:54:20 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42KsKF31461 for ; Wed, 2 May 2001 13:54:20 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f42KrV032684; Wed, 2 May 2001 13:53:31 -0700 Message-ID: <3AF0724B.D74D9AF9@mvista.com> Date: Wed, 02 May 2001 13:47:07 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: nick@snowman.net CC: Matthew Dharm , Linux-MIPS Subject: Re: Endianness... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk nick@snowman.net wrote: > > To the best of my knowledge Big endian is generally the way to run. > Nick > BE is better known perhaps because all SGI workstations are BE. Generally I found networking systems tend to use BE while consumer electronic devices tend to use LE (which means there are probably more MIPS CPUs running in LE.) So far I have not found much difference in terms of endianess, although occassionaly you have to IO swap in drivers for BE machine. Jun > On Wed, 2 May 2001, Matthew Dharm wrote: > > > What's the preferred endianness for Linux-MIPS? I can't really go > > into why I'm asking (sensitive NDA information), but I'm basically > > faced with a group that wants to work in LE. However, my > > understanding was that Linux-MIPS generally ran BE. > > > > Or can it be built either way? I know OpenBSD runs LE.... not like > > that means anything to this group, tho. > > > > Matt Dharm > > > > -- > > Matthew D. Dharm Senior Software Designer > > Momentum Computer Inc. 1815 Aston Ave. Suite 107 > > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > > Momentum Works For You www.momenco.com > > From owner-linux-mips@oss.sgi.com Wed May 2 13:55:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42KtLF31922 for linux-mips-outgoing; Wed, 2 May 2001 13:55:21 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42KtKF31913 for ; Wed, 2 May 2001 13:55:20 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f42Ksb032765; Wed, 2 May 2001 13:54:37 -0700 Message-ID: <3AF07385.22E94902@mvista.com> Date: Wed, 02 May 2001 13:52:21 -0700 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, bg MIME-Version: 1.0 To: Matthew Dharm CC: "linux-mips@oss.sgi.com" Subject: Re: Endianness... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Matthew Dharm wrote: > > What's the preferred endianness for Linux-MIPS? I can't really go > into why I'm asking (sensitive NDA information), but I'm basically > faced with a group that wants to work in LE. However, my > understanding was that Linux-MIPS generally ran BE. > > Or can it be built either way? I know OpenBSD runs LE.... not like > that means anything to this group, tho. I saw some of the replies. I don't think it's true that BE is "the" way to go. mips-linux runs both, le and be. We have three different LE boards and our partners have shipped our LE port to many of their customers. The Alchemy board I'm working on runs both, LE and BE and I've tested both. Depending on the peripherals you want to support, like USB, PCMCIA, etc, little endian might be a lot easier to port to. If on the other hand you're interested in a mips64 smp port, then BE is probably the easiest way to go because of the current support of mips64. As far as binary completeness, the RedHat 7.0 port is, I think, BE. But our HardHat Linux 2.0 will offer the same completeness for both, LE and BE (should be on the ftp site by the end of the month). Pete From owner-linux-mips@oss.sgi.com Wed May 2 13:55:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42KtqY32324 for linux-mips-outgoing; Wed, 2 May 2001 13:55:52 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42KtqF32319 for ; Wed, 2 May 2001 13:55:52 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f42Ktq000383; Wed, 2 May 2001 13:55:52 -0700 Message-ID: <3AF072D8.800C4FB8@mvista.com> Date: Wed, 02 May 2001 13:49:28 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: mp3 player program Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Does anybody have an MIPS mp3 player program in little endian? I'd appreciate ... Jun From owner-linux-mips@oss.sgi.com Wed May 2 16:25:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42NPvS15468 for linux-mips-outgoing; Wed, 2 May 2001 16:25:57 -0700 Received: from mail.palmchip.com ([63.203.52.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42NPuF15465 for ; Wed, 2 May 2001 16:25:56 -0700 Received: from palmchip.com (sabretooth.palmchip.com [10.1.10.110]) by mail.palmchip.com (8.11.0/8.9.3) with ESMTP id f42NPpc28762 for ; Wed, 2 May 2001 16:25:51 -0700 Message-ID: <3AF098B7.F111B230@palmchip.com> Date: Wed, 02 May 2001 16:31:03 -0700 From: Ian Thompson Organization: Palmchip Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Debug format problem with -ggdb flag Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I'm running into problems with the debug information that is generated by the kernel compilation process. Basically, I'm seeing that multiple function symbols have the same begin address in the .mdebug section. For example -- the init_arch and r3081_wait functions in my build have differnet addresses as far as compilation is concerned, and code executes correctly. When I look into the .mdebug section, I see that the begin, end, stab, and external records are all correct for the r3081_wait function, but that the begin record for the init_arch function is the same as that for the the r3081_wait function! This in turn seems to be causing the stab and external records to be incorrect, causing symbolic problems in my debugger. I've traced the problem down, and it seems to be a side-effect of partial linking. When the linker links multiple .o files into another .o file (which is later used as input to another ld command), the debug records inside the .mdebug section are getting corrupted. Has anyone run into this problem before? Any suggestions of other flags I can pass into the partial link that may help? I'm using the mipsel rpm of binutils 2.9.5-3. Or, are there any alternatives to partial linking that don't involve a lot of makefile manipulation? I've tried using the -gcoff option to remove the stab records, but that option does not allow the 2.4 kernel to compile under egcs 2.91.66. Any ideas? Thanks, -ian -- ---------------------------------------- Ian Thompson tel: 408.952.2023 Firmware Engineer fax: 408.570.0910 Palmchip Corporation www.palmchip.com From owner-linux-mips@oss.sgi.com Wed May 2 23:27:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f436ReE29254 for linux-mips-outgoing; Wed, 2 May 2001 23:27:40 -0700 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f436RVF29246; Wed, 2 May 2001 23:27:31 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id IAA01433; Thu, 3 May 2001 08:27:29 +0200 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id IAA27956; Thu, 3 May 2001 08:27:29 +0200 (MET DST) Message-Id: <200105030627.IAA27956@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: linux-mips@oss.sgi.com cc: ralf@oss.sgi.com Reply-to: vhouten@kpn.com Subject: Compilers / libstdc++ for RH7-mips X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 08:27:29 +0200 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all, I've uploaded working Compiler packages (2.95.3-19) for the RH7 mips port. They are a straight compile of Maciej's src.rpm package. Yes, this compiler can compile a kernel natively. With this libstdc++ package, the groff package is working again. Ralf: you might move the files over from 'contrib' to 'RPMS' / 'SRPMS', just as you like. For now, they are at: ftp://oss.sgi.com/pub/linux/mips/redhat/test-7.0/contrib Regards, Karel. -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Wed May 2 23:48:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f436m2M30521 for linux-mips-outgoing; Wed, 2 May 2001 23:48:02 -0700 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f436m0F30518 for ; Wed, 2 May 2001 23:48:00 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id IAA01462; Thu, 3 May 2001 08:47:58 +0200 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id IAA28522; Thu, 3 May 2001 08:47:57 +0200 (MET DST) Message-Id: <200105030647.IAA28522@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Pete Popov cc: Matthew Dharm , "linux-mips@oss.sgi.com" , karel@sparta.research.kpn.com Subject: Re: Endianness... In-reply-to: Your message of "Wed, 02 May 2001 13:52:21 PDT." <3AF07385.22E94902@mvista.com> Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 08:47:57 +0200 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Pete Popov wrote: > As far as binary completeness, the RedHat 7.0 port is, I think, > BE. But our HardHat Linux 2.0 will offer the same completeness for both, > LE and BE (should be on the ftp site by the end of the month). My RedHat 7.0 port for LE is also nearly ready. I'm still fighting with KDE, but I hope to upload a working root FS and rpms soon. Regards, Karel. -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Thu May 3 03:40:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43AeAk10003 for linux-mips-outgoing; Thu, 3 May 2001 03:40:10 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Ae9F10000 for ; Thu, 3 May 2001 03:40:09 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA28791 for ; Thu, 3 May 2001 03:40:14 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id DAA01295 for ; Thu, 3 May 2001 03:40:13 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id MAA27644 for ; Thu, 3 May 2001 12:39:20 +0200 (MEST) Message-ID: <3AF13558.F26941EE@mips.com> Date: Thu, 03 May 2001 12:39:20 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Insertion of die_if_kernel in unaligned.c Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk In the latest version of arch/mips/kernel/unaligned.c, there has been inserted some calls to the die_if_kernel, which check if we are running in kernel mode and if so dies. I'm not so sure this is the right thing to do, the floating point emulator will in some cases generate an address error (e.g. if emulating a swc1 to an unaligned address). The result is that an user application can crash the kernel. /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu May 3 04:45:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43Bj9W13174 for linux-mips-outgoing; Thu, 3 May 2001 04:45:09 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Bj7F13170 for ; Thu, 3 May 2001 04:45:07 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id GAA09498; Thu, 3 May 2001 06:45:04 -0500 Message-ID: <3AF147E5.F1FA8DDE@cotw.com> Date: Thu, 03 May 2001 06:58:29 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: mp3 player program References: <3AF072D8.800C4FB8@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > > Does anybody have an MIPS mp3 player program in little endian? I'd appreciate > ... > I would check over at and troll around in the mailing list archives. The iPAQ people have been running that sort of stuff. You might also look at the mailing lists from the ARM Linux project as there are a number of people running an MP3 player on their embedded boards. -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Thu May 3 10:16:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43HGhF08750 for linux-mips-outgoing; Thu, 3 May 2001 10:16:43 -0700 Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HGfF08747 for ; Thu, 3 May 2001 10:16:41 -0700 Received: from smtprelay-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id MAA29243; Thu, 3 May 2001 12:16:30 -0500 (CDT) (envelope-from anthony.wei@philips.com) From: anthony.wei@philips.com Received: from smtprelay-nam2.philips.com(167.81.233.16) by gw-us4.philips.com via mwrap (4.0a) id xma029234; Thu, 3 May 01 12:16:30 -0500 Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com [161.88.79.213]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA00538; Thu, 3 May 2001 12:16:29 -0500 (CDT) Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via AMEC id 0056910011804600; Thu, 3 May 2001 12:19:21 -0500 To: , Cc: Subject: Has anyone successfully reduced the size of libc.so? Message-ID: <0056910011804600000002L102*@MHS> Date: Thu, 3 May 2001 12:19:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 05/03/01 12:16:08" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f43HGgF08748 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I am trying to create a stripped version of libc.so from glibc.2.1.95 src, by including only minimal symbols. original full size libc.so: 7.9 Meg original libc.so but symbols stripped 1.7 Meg (running mipsel-linux-strip libc.so) Has anyone successfully reduced the size of the libc.so? Here is what I did. I started with glibc 2.1.95 and cross compiled for MIPS. A. Using Bradley D. LaRonde's ramdisk as a model B. Ran strings on /lib/libc-2.0.7.so and /lib/ld-2.0.7.so on LaRonde's ramdisk Removed all the messages, leaving mostly symbols. C. Ran a script, that took the symbols and found the corresponding *.os file. And resolved rescursively all undefined symbols. D. Extracted the commands used to create libc.so & ld.so, from the log while cross compiling glibc. Theses included: dl-allobjs.os libc_pic.a librtld.os ld.so libc_pic.os libc.so E. Replaced */stamp.os with the files found from step C. F. Extracted the symbols required for the ls command., and added to the *.os list. This brought the size of the libc.so back to the original size 1.7Meg (stripped)). Thanks. Anthony Wei Philips Digital Network 1000 West Maude Avenue W3-948 Sunnyvale, CA 94085-2810 +1-408-617-1673 From owner-linux-mips@oss.sgi.com Thu May 3 10:22:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43HMSD09212 for linux-mips-outgoing; Thu, 3 May 2001 10:22:28 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HMPF09209 for ; Thu, 3 May 2001 10:22:25 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f43HLEC06101; Thu, 3 May 2001 14:21:14 -0300 Date: Thu, 3 May 2001 14:21:14 -0300 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: Insertion of die_if_kernel in unaligned.c Message-ID: <20010503142114.A6081@bacchus.dhis.org> References: <3AF13558.F26941EE@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF13558.F26941EE@mips.com>; from carstenl@mips.com on Thu, May 03, 2001 at 12:39:20PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, May 03, 2001 at 12:39:20PM +0200, Carsten Langgaard wrote: > In the latest version of arch/mips/kernel/unaligned.c, there has been > inserted some calls to the die_if_kernel, which check if we are running > in kernel mode and if so dies. > I'm not so sure this is the right thing to do, the floating point > emulator will in some cases generate an address error (e.g. if emulating > a swc1 to an unaligned address). The result is that an user application > can crash the kernel. They're wrong and what's worse, I knew about them. The unaligned from kernelspace case can also be triggered from the network stack so this leaves machines open to remote DoS. Ralf From owner-linux-mips@oss.sgi.com Thu May 3 10:48:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43Hm7e11050 for linux-mips-outgoing; Thu, 3 May 2001 10:48:07 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Hm6F11045 for ; Thu, 3 May 2001 10:48:06 -0700 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14vNGm-0005uW-00; Thu, 3 May 2001 18:52:04 +0100 Subject: Re: Has anyone successfully reduced the size of libc.so? To: anthony.wei@philips.com Date: Thu, 3 May 2001 18:52:01 +0100 (BST) Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, brad@ltc.com In-Reply-To: <0056910011804600000002L102*@MHS> from "anthony.wei@philips.com" at May 03, 2001 12:19:21 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Has anyone successfully reduced the size of the libc.so? Not much. And Ulrich made very valid points about why this would fail. Someone should probably port newlib over as that is designed to be modular. From owner-linux-mips@oss.sgi.com Thu May 3 17:16:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f440G8L21675 for linux-mips-outgoing; Thu, 3 May 2001 17:16:08 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f440G6F21672 for ; Thu, 3 May 2001 17:16:06 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f440FxX14778; Thu, 3 May 2001 17:15:59 -0700 (PDT) Date: Thu, 3 May 2001 17:15:59 -0700 (PDT) From: "John D. Davis" To: Guido Guenther , Subject: Re: NFS -13 error In-Reply-To: <20010502155424.A9256@bilbo.physik.uni-konstanz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have downloaded the linux stuff and a kernel image(2.4.0-ip22) from the site listed below. I am getting a kernel panic. I am nolonger getting nfs errors. I added a link from /tftpboot/to the debian linux directory on the server. I guess dhcp_bootp doesn't have the right flag set or something. However, the message is: >Kernel panic: I have no root and I want to scream. Is there a flag that I need to set for the root? I have /etc/exports with the -root=sgilinuxIPaddress,rw for the parent directory of the linux distribution? I have tried other vmlinux kernels and gotten the same type of problem. THe one from sgi says it can't mount fs and ask for root=. I have tried to set that at the bootp():vmlinux root=/linux but that did not help either. Furthermore, I am not getting an mountd error on the SGI server. Any and all suggestions would be greatly appreciated. I am trying to install linux from an SGI Indy running IRIX over the network. thanks, john davis On Wed, 2 May 2001, Guido Guenther wrote: > On Tue, May 01, 2001 at 04:29:18PM -0700, John D. Davis wrote: > > > > I am having a problem installing linux on a 4400 indy. I downloaded a > > "fixed" version from: honk.physik.uni-konstanz,de/linux-mips/install > > and downloaded : > > root-be-0.04.cpio > This one is *very* outdated. Don't use it. It's there for purely > "historic reasons". > See > ftp://ftp.uni-mainz.de/pub/Linux/debian-local/mips/ > for an up to date root image. > -- Guido > From owner-linux-mips@oss.sgi.com Fri May 4 04:50:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44BoLx05566 for linux-mips-outgoing; Fri, 4 May 2001 04:50:21 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44BoKF05562 for ; Fri, 4 May 2001 04:50:20 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 1E6267F4; Fri, 4 May 2001 13:50:18 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 81416F38C; Fri, 4 May 2001 13:49:58 +0200 (CEST) Date: Fri, 4 May 2001 13:49:58 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: drivers/chat/vt.c - keyboard click Message-ID: <20010504134958.A513@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, i found this snippet: drivers/char/vt.c: 85 /* 86 * Generates sound of some frequency for some number of clock ticks 87 * 88 * If freq is 0, will turn off sound, else will turn it on for that time. 89 * If msec is 0, will return immediately, else will sleep for msec time, then 90 * turn sound off. 91 * 92 * We also return immediately, which is what was implied within the X 93 * comments - KDMKTONE doesn't put the process to sleep. 94 */ 95 96 #if defined(__i386__) || defined(__alpha__) || defined(__powerpc__) \ 97 || (defined(__mips__) && defined(CONFIG_ISA)) \ 98 || (defined(__arm__) && defined(CONFIG_HOST_FOOTBRIDGE)) Does any of the currently supported mips architectures actually support this ? I guess the RM200 could but i dont think that tree will actually work. I suggest to apply this: Index: drivers/char/vt.c =================================================================== RCS file: /cvs/linux/drivers/char/vt.c,v retrieving revision 1.30 diff -u -r1.30 vt.c --- drivers/char/vt.c 2001/03/09 20:33:59 1.30 +++ drivers/char/vt.c 2001/05/04 11:44:13 @@ -94,7 +94,7 @@ */ #if defined(__i386__) || defined(__alpha__) || defined(__powerpc__) \ - || (defined(__mips__) && defined(CONFIG_ISA)) \ + || !defined(__mips__) \ || (defined(__arm__) && defined(CONFIG_HOST_FOOTBRIDGE)) static void As most mips architectures having ISA dont support this - Any the ones who actually want it may enable it instead of the 10-20 subarchs which dont support it do disable this. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Fri May 4 05:34:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44CYaZ07636 for linux-mips-outgoing; Fri, 4 May 2001 05:34:36 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44CYYF07633 for ; Fri, 4 May 2001 05:34:34 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 6EAA27F9; Fri, 4 May 2001 14:34:32 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 6D02AF38C; Fri, 4 May 2001 14:34:10 +0200 (CEST) Date: Fri, 4 May 2001 14:34:10 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Patch tx3912 - inb/outb definition Message-ID: <20010504143410.A10487@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, there are incompatible definitions of inb/outb in the tx3912 header which clash the io.h definitions Index: include/asm-mips/tx3912.h =================================================================== RCS file: /cvs/linux/include/asm-mips/tx3912.h,v retrieving revision 1.1 diff -u -r1.1 tx3912.h --- include/asm-mips/tx3912.h 2001/04/01 03:28:23 1.1 +++ include/asm-mips/tx3912.h 2001/05/04 12:33:00 @@ -14,14 +14,6 @@ #include -#define inb(addr) (*(volatile unsigned char *)(addr)) -#define inw(addr) (*(volatile unsigned short *)(addr)) -#define inl(addr) (*(volatile unsigned int *)(addr)) -#define outb(b,addr) (*(volatile unsigned char *)(addr)) = (b) -#define outw(b,addr) (*(volatile unsigned short *)(addr)) = (b) -#define outl(b,addr) (*(volatile unsigned int *)(addr)) = (b) - - /****************************************************************************** * * 01 General macro definitions So i guess this is correct Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Fri May 4 05:47:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44ClrQ08310 for linux-mips-outgoing; Fri, 4 May 2001 05:47:53 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44ClpF08306 for ; Fri, 4 May 2001 05:47:51 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f44CkYY01667; Fri, 4 May 2001 09:46:34 -0300 Date: Fri, 4 May 2001 09:46:34 -0300 From: Ralf Baechle To: Jun Sun Cc: nick@snowman.net, Matthew Dharm , Linux-MIPS Subject: Re: Endianness... Message-ID: <20010504094634.B1257@bacchus.dhis.org> References: <3AF0724B.D74D9AF9@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF0724B.D74D9AF9@mvista.com>; from jsun@mvista.com on Wed, May 02, 2001 at 01:47:07PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 02, 2001 at 01:47:07PM -0700, Jun Sun wrote: > BE is better known perhaps because all SGI workstations are BE. Generally I > found networking systems tend to use BE while consumer electronic devices tend > to use LE (which means there are probably more MIPS CPUs running in LE.) > > So far I have not found much difference in terms of endianess, although > occassionaly you have to IO swap in drivers for BE machine. The difference is mostly of religious nature even though I've been told that various embedded apps can show noticable performance difference due to byteswapping. In general I prefer big endian because it tends to trigger certain bugs in software more than little endian, such as accessing a memory object with different sizes. Ralf From owner-linux-mips@oss.sgi.com Fri May 4 05:52:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44Cqsn08761 for linux-mips-outgoing; Fri, 4 May 2001 05:52:54 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44CqqF08756 for ; Fri, 4 May 2001 05:52:53 -0700 Received: from bilbo.physik.uni-konstanz.de [134.34.144.81] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 14vf4i-0000Ls-00; Fri, 04 May 2001 14:52:48 +0200 Received: from agx by bilbo.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 14vf4d-0005WE-00; Fri, 04 May 2001 14:52:43 +0200 Date: Fri, 4 May 2001 14:52:43 +0200 From: Guido Guenther To: "John D. Davis" Cc: linux-mips Subject: Re: NFS -13 error Message-ID: <20010504145243.B21147@bilbo.physik.uni-konstanz.de> Mail-Followup-To: "John D. Davis" , linux-mips References: <20010502155424.A9256@bilbo.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from johnd@stanford.edu on Thu, May 03, 2001 at 05:15:59PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, May 03, 2001 at 05:15:59PM -0700, John D. Davis wrote: [..snip..] > >Kernel panic: I have no root and I want to scream. You can try to give the rootfs on the prom command line e.g.: bootp(): nfsroot=ip.of.your.nfsserver:/path/to/rootfs See Documentation/nfsroot.txt in the kernel source for details. [..snip..] Regards, -- Guido From owner-linux-mips@oss.sgi.com Fri May 4 16:57:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44NvcN28470 for linux-mips-outgoing; Fri, 4 May 2001 16:57:38 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44NvbF28467 for ; Fri, 4 May 2001 16:57:37 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f44NvPB15778; Fri, 4 May 2001 16:57:25 -0700 (PDT) Date: Fri, 4 May 2001 16:57:24 -0700 (PDT) From: "John D. Davis" To: Bas Benschop cc: debian-mips , linux-mips Subject: Re: Indy Linux Install problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am using the recommended packages and the vmlinux kernel is on the IRIX server. I am currently getting the following error: VFS: Mounted root (nfs filesystem) readonly. Warning: unable to open an initial console. Kernel panic: Attempted to kill init! I don't know why the fs is readonly. I explicitly put rw in the /etc/exports. Is this why the initial console cannot be opened? I read the nfsroot.txt and I have come across other people with the same problem, but no soln. What am I missing? I tried both the ecoff and normal vmlinux, both panic. This is my command line: >bootp():vmlinux init=/bin/bash nfsroot=171.64.72.121:/ld2/linux/debian \ root=/dev/nfs thank you for your assistance, john davis On Fri, 4 May 2001, Bas Benschop wrote: > I also added root=/dev/nfs. Also check the config-2.4.0 to see if nfs root > fs is compiled in to the kernel. I used > kernel-image-2.4.0-test9-ip22-r4k, because 2.4.2 had no nfs root fs > compiled in. > > Bas Benschop > Faculty of Applied Physics > University of Twente > The Netherlands > > On Thu, 3 May 2001, John D. Davis wrote: > > > > > I am trying to install Linux on an R4400 Indy from another R4400 Indy > > running IRIX. I have looked at the list archives at both debian and sgi > > and found messages with the same kernel panic problem. Is there a > > solution? dhcp_bootp and tftp seem to be configured right. i don't get > > any NFS errors in the SYSLOG. I have also tried the instructions on the > > digibel.org site and added the nfs_root info for the server. I am using > > the base.2.2.2 and kernel-image-2.4.0-ip22-r4k.tgz. I had to explicitly > > add /tftpboot directory with a link to the debian linux distribution to > > rememdy the nfs errors from getfh. > > > > Any and all suggestions are greatly appreciated. > > thanks, > > john davis > > > > > > -- > > To UNSUBSCRIBE, email to debian-mips-request@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > > > > From owner-linux-mips@oss.sgi.com Fri May 4 17:07:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4507P928916 for linux-mips-outgoing; Fri, 4 May 2001 17:07:25 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4507OF28913 for ; Fri, 4 May 2001 17:07:24 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id DA315F1A9; Fri, 4 May 2001 17:06:27 -0700 (PDT) Date: Fri, 4 May 2001 17:06:27 -0700 From: Keith M Wesolowski To: "John D. Davis" Cc: Bas Benschop , debian-mips , linux-mips Subject: Re: Indy Linux Install problem Message-ID: <20010504170627.A19856@foobazco.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from johnd@Stanford.EDU on Fri, May 04, 2001 at 04:57:24PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, May 04, 2001 at 04:57:24PM -0700, John D. Davis wrote: > I am using the recommended packages and the vmlinux kernel is on the IRIX > server. I am currently getting the following error: Recommended by whom? > VFS: Mounted root (nfs filesystem) readonly. > Warning: unable to open an initial console. > Kernel panic: Attempted to kill init! > > I don't know why the fs is readonly. I explicitly put rw in the > /etc/exports. Is this why the initial console cannot be opened? I read No. That usually indicates that your root filesystem is defective. See if /dev/console exists and is c 5 1. If not, that's the source of your console problem. The init death problem seems more insidious. Try passing init=/bin/sh or so - this will be even more effective if you have a statically linked shell like ash or sash to use. Where did you get this filesystem? For that matter, where did you get this kernel? There are *lots* of both floating around, even on oss, that may be broken or out of date. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Fri May 4 17:20:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f450K1029337 for linux-mips-outgoing; Fri, 4 May 2001 17:20:01 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f450K1F29334 for ; Fri, 4 May 2001 17:20:01 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f450Jl116157; Fri, 4 May 2001 17:19:47 -0700 (PDT) Date: Fri, 4 May 2001 17:19:47 -0700 (PDT) From: "John D. Davis" To: Keith M Wesolowski cc: Bas Benschop , debian-mips , linux-mips Subject: Re: Indy Linux Install problem In-Reply-To: <20010504170627.A19856@foobazco.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is who recommended the image. I grabbed base2_2.2 and uncompressed it on an IRIX box using gzip -dc and tar xopf - . >>See >> ftp://ftp.uni-mainz.de/pub/Linux/debian-local/mips/ >>for an up to date root image. >> -- Guido On Fri, 4 May 2001, Keith M Wesolowski wrote: > On Fri, May 04, 2001 at 04:57:24PM -0700, John D. Davis wrote: > > > I am using the recommended packages and the vmlinux kernel is on the IRIX > > server. I am currently getting the following error: > > Recommended by whom? > > > VFS: Mounted root (nfs filesystem) readonly. > > Warning: unable to open an initial console. > > Kernel panic: Attempted to kill init! > > > > I don't know why the fs is readonly. I explicitly put rw in the > > /etc/exports. Is this why the initial console cannot be opened? I read > > No. That usually indicates that your root filesystem is defective. > See if /dev/console exists and is c 5 1. If not, that's the source of > your console problem. So dev console is one problem. littledipper 13% ls -l dev/console crw-rw-rw- 1 root sys 0, 0 Jan 24 06:18 dev/console Can I just use mknod and change it to c 5 1 ? > The init death problem seems more insidious. Try passing init=/bin/sh > or so - this will be even more effective if you have a statically > linked shell like ash or sash to use. Where did you get this > filesystem? For that matter, where did you get this kernel? There > are *lots* of both floating around, even on oss, that may be broken or > out of date. The kernel was downloaded from : ftp://ftp.rfc822.org/pub/local/debian-mips/kernel/ and I am using: kernel-image-2.4.0-test9 both the ecoff and elf format one fail. In bin, sh is linked to bash: littledipper 16% ls -l bin/*sh -rwxr-xr-x 1 root sys 724072 Dec 27 04:44 bin/bash lrwxr-xr-x 1 root sys 4 May 3 15:11 bin/rbash -> bash lrwxr-xr-x 1 root sys 4 May 4 16:08 bin/sh -> bash There is no s/ash. I can get another copy of the root image if that is neceassry or use an older verison. thanks, john From owner-linux-mips@oss.sgi.com Fri May 4 17:28:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f450SH729743 for linux-mips-outgoing; Fri, 4 May 2001 17:28:17 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f450SGF29740 for ; Fri, 4 May 2001 17:28:16 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f450S9L16283; Fri, 4 May 2001 17:28:09 -0700 (PDT) Date: Fri, 4 May 2001 17:28:09 -0700 (PDT) From: "John D. Davis" To: Keith M Wesolowski cc: Bas Benschop , debian-mips , linux-mips Subject: Re: Indy Linux Install problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I created a new dev/console wiht c 5 1 and I have a shell. I am going to continue the install process. Thank you all for your assistance! john davis On Fri, 4 May 2001, John D. Davis wrote: > > This is who recommended the image. I grabbed base2_2.2 and uncompressed it > on an IRIX box using gzip -dc and tar xopf - . > > >>See > >> ftp://ftp.uni-mainz.de/pub/Linux/debian-local/mips/ > >>for an up to date root image. > >> -- Guido > > > > On Fri, 4 May 2001, Keith M Wesolowski wrote: > > > On Fri, May 04, 2001 at 04:57:24PM -0700, John D. Davis wrote: > > > > > I am using the recommended packages and the vmlinux kernel is on the IRIX > > > server. I am currently getting the following error: > > > > Recommended by whom? > > > > > VFS: Mounted root (nfs filesystem) readonly. > > > Warning: unable to open an initial console. > > > Kernel panic: Attempted to kill init! > > > > > > I don't know why the fs is readonly. I explicitly put rw in the > > > /etc/exports. Is this why the initial console cannot be opened? I read > > > > No. That usually indicates that your root filesystem is defective. > > See if /dev/console exists and is c 5 1. If not, that's the source of > > your console problem. > > So dev console is one problem. > > littledipper 13% ls -l dev/console > crw-rw-rw- 1 root sys 0, 0 Jan 24 06:18 dev/console > > Can I just use mknod and change it to c 5 1 ? > > > The init death problem seems more insidious. Try passing init=/bin/sh > > or so - this will be even more effective if you have a statically > > linked shell like ash or sash to use. Where did you get this > > filesystem? For that matter, where did you get this kernel? There > > are *lots* of both floating around, even on oss, that may be broken or > > out of date. > > The kernel was downloaded from : > ftp://ftp.rfc822.org/pub/local/debian-mips/kernel/ > and I am using: kernel-image-2.4.0-test9 both the ecoff and elf format > one fail. In bin, sh is linked to bash: > > littledipper 16% ls -l bin/*sh > -rwxr-xr-x 1 root sys 724072 Dec 27 04:44 bin/bash > lrwxr-xr-x 1 root sys 4 May 3 15:11 bin/rbash -> bash > lrwxr-xr-x 1 root sys 4 May 4 16:08 bin/sh -> bash > > There is no s/ash. I can get another copy of the root image if that is > neceassry or use an older verison. > > thanks, > john > > From owner-linux-mips@oss.sgi.com Fri May 4 17:32:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f450Wx030077 for linux-mips-outgoing; Fri, 4 May 2001 17:32:59 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f450WuF30074 for ; Fri, 4 May 2001 17:32:57 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f450Vek20563; Fri, 4 May 2001 21:31:40 -0300 Date: Fri, 4 May 2001 21:31:40 -0300 From: Ralf Baechle To: Carsten Langgaard Cc: Klaus Naumann , linux-mips@oss.sgi.com Subject: Re: Login problem on a serial console Message-ID: <20010504213140.A20515@bacchus.dhis.org> References: <3AEE8DC8.DCCCFA9B@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AEE8DC8.DCCCFA9B@mips.com>; from carstenl@mips.com on Tue, May 01, 2001 at 12:19:52PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 01, 2001 at 12:19:52PM +0200, Carsten Langgaard wrote: > > I think this has something to do with the fixes Bachus commited > > lately. I think he changed something which made some getty's > > not work anymore. Can you try an other getty ? > > I tried another getty and that seem to work, thanks. > Do you know what break things, so I could redo Bachus fixes ? Bacchus is angry about your misspelling of his name and punishes you by el cheapo vine not under 5l ;-) It's a change in the architecture independant code of the kernel which result in the kernel initializing the serial tty with the CREAD flag cleared. mingetty doesn't do a fully initialization of the terminal but getty (from getty_ps) or mgetty do, so they work. I'd consider that two bugs, one in the kernel and one in mingetty. It means a user can messup terminal settings so completly that logging off wouldn't fix things but only root intervention or reboot. Ralf From owner-linux-mips@oss.sgi.com Fri May 4 17:34:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f450Ysl30298 for linux-mips-outgoing; Fri, 4 May 2001 17:34:54 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f450YpF30291 for ; Fri, 4 May 2001 17:34:52 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f450Xj320572; Fri, 4 May 2001 21:33:45 -0300 Date: Fri, 4 May 2001 21:33:45 -0300 From: Ralf Baechle To: Justin Carlson Cc: linux-mips@oss.sgi.com Subject: Re: mips64 linux glibc compilation broken? Message-ID: <20010504213345.B20515@bacchus.dhis.org> References: <0104301108411I.31854@plugh.sibyte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0104301108411I.31854@plugh.sibyte.com>; from carlson@sibyte.com on Mon, Apr 30, 2001 at 11:07:33AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 30, 2001 at 11:07:33AM -0700, Justin Carlson wrote: > I could swear I saw this topic go by before, but searching my archives, > I don't see it. > > glibc fresh out of redhat cvs doesn't compile for mips64-linux; it fails > with quite a bit of stuff like this: > > --- > In file included from dynamic-link.h:21, > from dl-load.c:32: > ../sysdeps/mips/mips64/dl-machine.h: In function `elf_machine_got_rel': > ../sysdeps/mips/mips64/dl-machine.h:178: warning: passing arg 2 of `_dl_lookup_symbol' from incompatible pointer type > ../sysdeps/mips/mips64/dl-machine.h:178: warning: passing arg 3 of `_dl_lookup_symbol' from incompatible pointer type > ../sysdeps/mips/mips64/dl-machine.h:178: warning: passing arg 4 of `_dl_lookup_symbol' from incompatible pointer type > ../sysdeps/mips/mips64/dl-machine.h:178: too few arguments to function `_dl_lookup_symbol' > ../sysdeps/mips/mips64/dl-machine.h:181: warning: passing arg 2 of `_dl_lookup_symbol' from incompatible pointer type > ../sysdeps/mips/mips64/dl-machine.h:181: warning: passing arg 3 of `_dl_lookup_symbol' from incompatible pointer type > ../sysdeps/mips/mips64/dl-machine.h:181: warning: passing arg 4 of `_dl_lookup_symbol' from incompatible pointer type > --- > > It looks like this is something that has been fixed for mips, but not mips64. > I'm sure I can fix the immediate compile problems, but am not familiar enough > with glibc to be confident of doing the Right Thing overall. > > Are there any patches for mips64 linux that haven't made it into the mainline > cvs yet? I already answered this before in private email - mips64 is not support in glibc nor was it ever working properly. And won't until somebody fixed the assembler and ld first ... All software mips64 systems are currently running is 32-bit stuff running in the binary compatibility mode. Ralf From owner-linux-mips@oss.sgi.com Fri May 4 19:34:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f452YO200785 for linux-mips-outgoing; Fri, 4 May 2001 19:34:24 -0700 Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f452YNF00782 for ; Fri, 4 May 2001 19:34:23 -0700 Received: from serendipity (GRT-215-45.RESNET.UPENN.EDU [130.91.215.45]) by sierra.seas.upenn.edu (8.9.3/8.9.3) with SMTP id WAA14857 for ; Fri, 4 May 2001 22:34:21 -0400 (EDT) Message-ID: <019801c0d50c$32024fb0$2dd75b82@serendipity> From: "Patrick Fisher" To: Subject: Executing Programs from initrd Date: Fri, 4 May 2001 22:36:31 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm plodding along working with Linux/MIPS (and Linux-VR) on a Philips Nino. I can boot linux, and fool around with the stand alone shell. I can also execute a program included on Steven Hill's Nino ramdisk - a simple Hello World program, in assembly, which I compiled with my mipsel-linux toolchain (well, also from Steven Hill, but it was compiled locally on my own machine). That program runs fine. However, I can't run any binaries other than this one and the shell. I wrote an additional Hello World program in C, compiled it for mipsel, and put it in the ramdisk. The executable is definitely there when I boot on the nino - I can send it all to the serial console and see that it exists. However, any attempt to execute it returns "No such file or directory". It's got all the right permissions, and this occurs when I'm positive I'm giving it the whole path. It simply can't see the file. I also copied "ls" from a root image for a mipsel decstation, and got the same problem. I downloaded the GNU fileutils source, set it for a mipsel target, compiled, put a few binaries on the ramdisk, and again, it can't find the file (but it's there, and I can see the contents). This occurs on a ~650k ramdisk with ~30k free, and a 2MB ramdisk with ~1.5MB free, using either the SGI Linux/MIPS sources or the Linux-VR project's sources. Any ideas? Thanks, Patrick From owner-linux-mips@oss.sgi.com Fri May 4 19:57:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f452vQZ01248 for linux-mips-outgoing; Fri, 4 May 2001 19:57:26 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f452vNF01245 for ; Fri, 4 May 2001 19:57:23 -0700 Received: (qmail 399 invoked from network); 5 May 2001 02:57:21 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 5 May 2001 02:57:21 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Patrick Fisher" cc: linux-mips@oss.sgi.com Subject: Re: Executing Programs from initrd In-reply-to: Your message of "Fri, 04 May 2001 22:36:31 -0400." <019801c0d50c$32024fb0$2dd75b82@serendipity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 May 2001 12:57:20 +1000 Message-ID: <13883.989031440@ocs3.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 4 May 2001 22:36:31 -0400, "Patrick Fisher" wrote: >However, any attempt to execute it returns "No such file or directory". That particular error message is highly misleading. Most people read it as "the file I'm trying to execute does not exist" but it is also issued when the loader cannot be found or one of the run time libraries cannot be found. At a guess you have a mismatch between the mipsel loader and the Nino loader. Run strings on a working and a failing binary and look at the required loader and libraries, usually the first few strings. From owner-linux-mips@oss.sgi.com Fri May 4 20:01:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4531Gq01535 for linux-mips-outgoing; Fri, 4 May 2001 20:01:16 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4531FF01532 for ; Fri, 4 May 2001 20:01:15 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id C8831F1A9; Fri, 4 May 2001 20:00:18 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id E164E1F428; Fri, 4 May 2001 20:00:51 -0700 (PDT) Date: Fri, 4 May 2001 20:00:51 -0700 From: Keith M Wesolowski To: Patrick Fisher Cc: linux-mips@oss.sgi.com Subject: Re: Executing Programs from initrd Message-ID: <20010504200051.A1302@foobazco.org> References: <019801c0d50c$32024fb0$2dd75b82@serendipity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <019801c0d50c$32024fb0$2dd75b82@serendipity>; from pbfisher@seas.upenn.edu on Fri, May 04, 2001 at 10:36:31PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, May 04, 2001 at 10:36:31PM -0400, Patrick Fisher wrote: > However, I can't run any binaries other than this one and the shell. I > wrote an additional Hello World program in C, compiled it for mipsel, and > put it in the ramdisk. The executable is definitely there when I boot on > the nino - I can send it all to the serial console and see that it exists. > However, any attempt to execute it returns "No such file or directory". Did you compile with -static? If not, the system will attempt to load it with /lib/ld.so.1. Do you have that file? Is it executable? What about libc? If you have a file starting with #! /bin/fux0r and /bin/fux0r does not exist, the execution will fail with that exact error. In fact from the system's point of view it's the same thing with /lib/ld.so.1 instead of /bin/fux0r. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Sat May 5 05:47:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f45ClVZ09213 for linux-mips-outgoing; Sat, 5 May 2001 05:47:31 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45ClUF09210 for ; Sat, 5 May 2001 05:47:30 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id B3E147DD; Sat, 5 May 2001 14:47:27 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id E322AF38F; Sat, 5 May 2001 14:47:08 +0200 (CEST) Date: Sat, 5 May 2001 14:47:08 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Binary compatibility break understood ? Message-ID: <20010505144708.A12575@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, the last days/weeks there was a repeated discussion of breaking the binary compatibility. I read the whole thread on linux-mips but i didnt get the point why this has to happen - If we are repairing a real bug for it. Could someone please elaborate on whats going on as i feel i missed ~200 mails discussion and i dont want to purge the whole debian archive until i know what for we actually drop the compatibility. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Sun May 6 09:11:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46GBDc05742 for linux-mips-outgoing; Sun, 6 May 2001 09:11:13 -0700 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46GBAF05739 for ; Sun, 6 May 2001 09:11:11 -0700 Received: from athena.home.krftech.com ([194.90.113.98]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with SMTP id TAA17636 for ; Sun, 6 May 2001 19:12:52 +0300 (IDT) Content-Type: text/plain; charset="iso-8859-1" From: Shay Deloya Reply-To: shay@jungo.com Organization: Jungo Corp. To: linux-mips@oss.sgi.com Subject: insmod problems Date: Sun, 6 May 2001 19:13:43 +0300 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01050619134301.01140@athena.home.krftech.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi All, I have an old problem came up again and the old solution aren't helping. I'm using busybox version 0.50 and with kernel 2.2 , and inserting some modules ,especially those with DEBUG macroes e.g: #define DEBUG_HIGH(args...) {if (debug_level >= HIGH) printk(args);} causes the message : Relocation overflow of type 4 for and insmod fails. I'm compiling the modules with -mlong-calls and still getting this message. Is it insmod knowen bugs that the relocation is done in bad way or a linker/compiler bug. I'm using compiler: egcs ver 1.0.3a I'm checking this problem at the moment and looking for insmod bug. Thanks, Shay Deloya ______________________________________ Software Developer Jungo - R&D email: shayd@jungo.com web: http://www.jungo.com Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 221 Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide) From owner-linux-mips@oss.sgi.com Sun May 6 09:25:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46GPES06500 for linux-mips-outgoing; Sun, 6 May 2001 09:25:14 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46GPEF06496 for ; Sun, 6 May 2001 09:25:14 -0700 Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5]) by mcp.csh.rit.edu (Postfix) with ESMTP id 84E6D1250 for ; Sun, 6 May 2001 12:25:12 -0400 (EDT) Date: Sun, 6 May 2001 12:25:12 -0400 (EDT) From: George Gensure To: Subject: 2.4.3 kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Can anyone explain to me how the 2.4.3 kernel available on ftp.rfc822.org was built? I've been working for about a month and a half on getting that to compile with no success. The only reason I need it is to get input core support, since linux doesn't like to recognize any device nodes that I create using mknod. If anyone could shed some light on either of these problems... the kernel or getting linux to recognize my mouse on (10,1) please contact me. George werkt@csh.rit.edu From owner-linux-mips@oss.sgi.com Sun May 6 12:49:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46JnnM11279 for linux-mips-outgoing; Sun, 6 May 2001 12:49:49 -0700 Received: from tricom.net ([200.50.8.14]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46JnlF11276 for ; Sun, 6 May 2001 12:49:47 -0700 Received: from vaio (net0port19.tricom.net [200.50.8.90]) by tricom.net (8.11.1/8.11.1) with SMTP id f46Bjkg01931 for ; Sun, 6 May 2001 15:45:46 +0400 (GMT) Message-ID: <003601c0d665$69381d20$0100a8c0@mshome.net> From: "CPMSA" To: References: Subject: DELETE Date: Sun, 6 May 2001 15:47:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From owner-linux-mips@oss.sgi.com Sun May 6 16:26:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46NQTw16041 for linux-mips-outgoing; Sun, 6 May 2001 16:26:29 -0700 Received: from serio.al.rim.or.jp (serio.al.rim.or.jp [202.247.191.123]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46NQSF16038 for ; Sun, 6 May 2001 16:26:28 -0700 Received: from mail2.rim.or.jp by serio.al.rim.or.jp (3.7W/HMX-13) id IAA26132 for ; Mon, 7 May 2001 08:26:26 +0900 (JST) Received: from speed2000 (csc2-209.kanagawa.mbn.or.jp [202.217.96.209]) by mail2.rim.or.jp (8.9.3/3.7W) id IAA11366 for ; Mon, 7 May 2001 08:26:25 +0900 (JST) From: "Yoshi.-K" To: Subject: install in the first hard disk Date: Mon, 7 May 2001 08:26:25 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello. my name is Yoshi. from Japan. SGI O2 is used. I will install hardhat-sgi-5.1.tar.gz. will be able to install in the first hard disk. I want to use on one hard disk . Is it possible? ---------------------------------------- Yoshikatsu Kida http://starimpact.com/ webmaster@starimpact.com From owner-linux-mips@oss.sgi.com Sun May 6 16:36:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46Nap716460 for linux-mips-outgoing; Sun, 6 May 2001 16:36:51 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46NaoF16457 for ; Sun, 6 May 2001 16:36:50 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 7223BF1A9; Sun, 6 May 2001 16:35:51 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 7D60E1F429; Sun, 6 May 2001 16:36:24 -0700 (PDT) Date: Sun, 6 May 2001 16:36:24 -0700 From: Keith M Wesolowski To: "Yoshi.-K" Cc: linux-mips@oss.sgi.com Subject: Re: install in the first hard disk Message-ID: <20010506163624.A871@foobazco.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ykida@yk.rim.or.jp on Mon, May 07, 2001 at 08:26:25AM +0900 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 07, 2001 at 08:26:25AM +0900, Yoshi.-K wrote: > Hello. my name is Yoshi. from Japan. Hello. > SGI O2 is used. > I will install hardhat-sgi-5.1.tar.gz. No, you won't. No linux kernel in common distribution will even load on that box. > will be able to install in the first hard disk. > I want to use on one hard disk . Is it possible? Ask me again in a few days; I've just managed to get linux to see the disks on that machine. Check the archives for my post indicating where my CVS tree is kept; it has as much O2 support as any tree I know about. Maybe you'd like to download it and tell me why it doesn't work. If this is r10k/r12k O2, you have an even longer wait as I haven't got such a system and there are extra problems supporting it. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Mon May 7 07:26:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47EQPT10345 for linux-mips-outgoing; Mon, 7 May 2001 07:26:25 -0700 Received: from srvw2kmailcon2.ixl.com (host96sub184.offices.ixl.com [209.104.184.96]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47EQ9F10335 for ; Mon, 7 May 2001 07:26:09 -0700 Received: from 216.99.0.139 by srvw2kmailcon2.ixl.com (InterScan E-Mail VirusWall NT); Mon, 07 May 2001 10:25:51 -0400 Received: by srvntsxconn3.ixl.com with Internet Mail Service (5.5.2650.21) id ; Mon, 7 May 2001 10:25:16 -0400 Message-ID: From: tmaloney@ixl.com To: aepearce@Perigee.net, andrea.hobbs@bankofamerica.com, andy.grum@ijl.com, brian.johnson@ijl.com, brian.daly@starpoint.com, brian@precisionet.net, bruce@triphop.org, bmcdonald@carolina.rr.com, bmcdonald@elogex.com, Psfunk@aol.com, david.adamec@ijl.com, dwhisel@ineteng.com, edwilk99@yahoo.com, lizardking@hotmail.com, proteus@startrekmail.com, edwilkins@prodigy.net, garrison@ijl.com, GregoryWilkins@Juno.com, tmaloney@ixl.com Cc: kirtoch@earthlink.net, teedoff@mymailstation.com, jjuva@hotmail.com, usdiver123@core.com, mccormick.jerry@emeryworld.com, ja_lukac@yahoo.com, john@GoButton.com, John.Elkins@captrust.com, ksampanthar@ibexone.com Subject: Date: Mon, 7 May 2001 10:25:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk test Tim Maloney Senior Developer iXL, Inc. 1930 Camden Road, Suite 2070 Charlotte, NC 28203 704 943-7193 phone tmaloney@ixl.com www.ixl.com From owner-linux-mips@oss.sgi.com Mon May 7 11:03:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47I3YN16652 for linux-mips-outgoing; Mon, 7 May 2001 11:03:34 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47I3TF16645 for ; Mon, 7 May 2001 11:03:31 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f45Hta001655; Sat, 5 May 2001 14:55:36 -0300 Date: Sat, 5 May 2001 14:55:36 -0300 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: Patch tx3912 - inb/outb definition Message-ID: <20010505145536.C1252@bacchus.dhis.org> References: <20010504143410.A10487@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010504143410.A10487@paradigm.rfc822.org>; from flo@rfc822.org on Fri, May 04, 2001 at 02:34:10PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, May 04, 2001 at 02:34:10PM +0200, Florian Lohoff wrote: > So i guess this is correct At least those definitions look dubious enough to be dumped ... Ralf From owner-linux-mips@oss.sgi.com Mon May 7 11:04:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47I4qK17086 for linux-mips-outgoing; Mon, 7 May 2001 11:04:52 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47I4lF17052 for ; Mon, 7 May 2001 11:04:49 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f45GFZ201292; Sat, 5 May 2001 13:15:35 -0300 Date: Sat, 5 May 2001 13:15:35 -0300 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: drivers/chat/vt.c - keyboard click Message-ID: <20010505131535.A1252@bacchus.dhis.org> References: <20010504134958.A513@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010504134958.A513@paradigm.rfc822.org>; from flo@rfc822.org on Fri, May 04, 2001 at 01:49:58PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, May 04, 2001 at 01:49:58PM +0200, Florian Lohoff wrote: > Does any of the currently supported mips architectures actually support > this ? I guess the RM200 could but i dont think that tree will actually work. > > I suggest to apply this: My plan was to eleminate all this mess and use CONFIG_PC_BEEPER instead. Ralf From owner-linux-mips@oss.sgi.com Mon May 7 11:02:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47I2q016597 for linux-mips-outgoing; Mon, 7 May 2001 11:02:52 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47I2lF16590 for ; Mon, 7 May 2001 11:02:48 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f45I5dH01698; Sat, 5 May 2001 15:05:39 -0300 Date: Sat, 5 May 2001 15:05:39 -0300 From: Ralf Baechle To: "John D. Davis" Cc: Keith M Wesolowski , Bas Benschop , debian-mips , linux-mips Subject: Re: Indy Linux Install problem Message-ID: <20010505150539.D1252@bacchus.dhis.org> References: <20010504170627.A19856@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from johnd@Stanford.EDU on Fri, May 04, 2001 at 05:19:47PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, May 04, 2001 at 05:19:47PM -0700, John D. Davis wrote: > So dev console is one problem. > > littledipper 13% ls -l dev/console > crw-rw-rw- 1 root sys 0, 0 Jan 24 06:18 dev/console > > Can I just use mknod and change it to c 5 1 ? The representation of devices accross NFS is not guaranteed, that is a device that has major / minor 5 / 1 on Linux may appear with different device numbers when imported/exported via NFS from/to another OS such as IRIX or Solaris. So make sure you unpack the image on a Linux machine. Ralf From owner-linux-mips@oss.sgi.com Mon May 7 11:04:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47I4EO16821 for linux-mips-outgoing; Mon, 7 May 2001 11:04:14 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47I47F16790 for ; Mon, 7 May 2001 11:04:09 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f45Hrjd01646; Sat, 5 May 2001 14:53:45 -0300 Date: Sat, 5 May 2001 14:53:45 -0300 From: Ralf Baechle To: Ian Thompson Cc: linux-mips@oss.sgi.com Subject: Re: Debug format problem with -ggdb flag Message-ID: <20010505145344.B1252@bacchus.dhis.org> References: <3AF098B7.F111B230@palmchip.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF098B7.F111B230@palmchip.com>; from iant@palmchip.com on Wed, May 02, 2001 at 04:31:03PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 02, 2001 at 04:31:03PM -0700, Ian Thompson wrote: > I'm running into problems with the debug information that is generated > by the kernel compilation process. Basically, I'm seeing that > multiple function symbols have the same begin address in the .mdebug > section. For example -- the init_arch and r3081_wait functions in my > build have differnet addresses as far as compilation is concerned, and > code executes correctly. When I look into the .mdebug section, I see > that the begin, end, stab, and external records are all correct for > the r3081_wait function, but that the begin record for the init_arch > function is the same as that for the the r3081_wait function! This in > turn seems to be causing the stab and external records to be incorrect, > causing symbolic problems in my debugger. > > I've traced the problem down, and it seems to be a side-effect of > partial linking. When the linker links multiple .o files into another > .o file (which is later used as input to another ld command), the > debug records inside the .mdebug section are getting corrupted. Has > anyone run into this problem before? Any suggestions of other flags > I can pass into the partial link that may help? I'm using the mipsel > rpm of binutils 2.9.5-3. Or, are there any alternatives to > partial linking that don't involve a lot of makefile manipulation? > > I've tried using the -gcoff option to remove the stab records, but that > option does not allow the 2.4 kernel to compile under egcs 2.91.66. So then is a binutils and not a compiler problem. What binutils are you using? Binutils 2.8.1 which I'm still recommending (mostly to avoid sending people into a maze of version dependencies) is getting dated and the bug may well have been fixed in the meantime. Ralf From owner-linux-mips@oss.sgi.com Mon May 7 12:34:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47JYBV19945 for linux-mips-outgoing; Mon, 7 May 2001 12:34:11 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47JY8F19941 for ; Mon, 7 May 2001 12:34:09 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f47JWAt02500; Mon, 7 May 2001 16:32:10 -0300 Date: Mon, 7 May 2001 16:32:10 -0300 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010507163210.B2381@bacchus.dhis.org> References: <20010505144708.A12575@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010505144708.A12575@paradigm.rfc822.org>; from flo@rfc822.org on Sat, May 05, 2001 at 02:47:08PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, May 05, 2001 at 02:47:08PM +0200, Florian Lohoff wrote: > Hi, > the last days/weeks there was a repeated discussion of breaking the binary > compatibility. I read the whole thread on linux-mips but i didnt get the point > why this has to happen - If we are repairing a real bug for it. > > Could someone please elaborate on whats going on as i feel i missed ~200 mails > discussion and i dont want to purge the whole debian archive until i know > what for we actually drop the compatibility. We don't. Ralf From owner-linux-mips@oss.sgi.com Mon May 7 13:40:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47Ke8B21559 for linux-mips-outgoing; Mon, 7 May 2001 13:40:08 -0700 Received: from web11904.mail.yahoo.com (web11904.mail.yahoo.com [216.136.172.188]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47Ke7F21556 for ; Mon, 7 May 2001 13:40:07 -0700 Message-ID: <20010507204006.12697.qmail@web11904.mail.yahoo.com> Received: from [209.243.184.191] by web11904.mail.yahoo.com; Mon, 07 May 2001 13:40:06 PDT Date: Mon, 7 May 2001 13:40:06 -0700 (PDT) From: Wayne Gowcher Subject: Re: usermode gdb / remote gdb To: Jun Sun Cc: Michael Shmulevich , Linux/MIPS In-Reply-To: <3AEBE34C.5070009@jungo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun, Having seen your recent posting regarding gdb, I am wondering if you could help me. I downloaded gdb from your web site, and tried compiling gdb-4.17 for a mipsel target. I got gdb to compile OK, but I couldn't get gdbserver to compile. My problems seem similar to the problems Michael Shmulevich had. I couldn't find any documentation on what order to apply patches, or which patches to apply, so I patched with the following in the following order : gdb-4.17-mips.patch gdb-4.17-mips-gdbserver.patch gdb-4.17-xref.patch I configured gdb with : ./configure -target=mips-linux-elf It configured OK and then built OK. Then I configured gdbserver with : ../../configure --target=mipsel-linux-elf And then tried compiling.This compiled so far and then gave numerous undefined references to functions such as create_inferior,mywait, myresume etc which are defined in low-linux.c. So following the previous thread on gdbserver from Micheal Shmulevich, I decided to try : ../../configure --host=mipsel-linux --target=mipsel-linux-elf This gave the following output : gdbserver/configure.in:host is mipsel-unknown-linux-gnu,target is gdbserver/configure.in:host_cpu is mipsel, target cpu is mipsel Linked "xm.h" to "./../config/mips/xm-linux.h". Linked "tm.h" to "./../config/mips-tm-embedl.h". Linked "nm.h" to "./../config/nm-empty.h". Created "Makefile" /usr/local/src/gdb-5.0/gdb-4.17/gdb/gdbserver using "../config/mips/mipsel-linux.mh" and "../config/mips/embedl.mt" I then build with : make CC=mipsel-linux-gcc. The first file it tries to compile is low-linux.c and immediately errors with : low-linux.c:In function 'fetch_register': low-linux.c:248: 'PT_READ_U' undeclared (first use in function) Looking at the source I believe PT_READ_U is undefined because the link from nm.h to nm-linux.h is not made, Michael made the same observation. >From what I have written can you tell me where I am going wrong ? Any help would be greatly appreciated Michael: If you have any tips on how to get gdbserver working they will be warmly welcome. TIA Wayne __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon May 7 13:57:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47Kvu922160 for linux-mips-outgoing; Mon, 7 May 2001 13:57:56 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47KvqF22156; Mon, 7 May 2001 13:57:53 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f47KvlF28559; Mon, 7 May 2001 13:57:47 -0700 (PDT) Date: Mon, 7 May 2001 13:57:47 -0700 (PDT) From: "John D. Davis" To: Ralf Baechle cc: debian-mips , linux-mips Subject: Re: Indy Linux Install problem In-Reply-To: <20010505150539.D1252@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The base2_2.2.tgz that I got did not have the correct major and minor nodes on IRIX. I changed them and it appears to be happy. All the nodes seem to be correct when unpacking on a linux box. Is there a way to at least have the correct major and minor nodes when it is unpacked on a IRIX box? thanks, john On Sat, 5 May 2001, Ralf Baechle wrote: > On Fri, May 04, 2001 at 05:19:47PM -0700, John D. Davis wrote: > > > So dev console is one problem. > > > > littledipper 13% ls -l dev/console > > crw-rw-rw- 1 root sys 0, 0 Jan 24 06:18 dev/console > > > > Can I just use mknod and change it to c 5 1 ? > > The representation of devices accross NFS is not guaranteed, that is a > device that has major / minor 5 / 1 on Linux may appear with different > device numbers when imported/exported via NFS from/to another OS such > as IRIX or Solaris. So make sure you unpack the image on a Linux > machine. > > Ralf > From owner-linux-mips@oss.sgi.com Mon May 7 18:01:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4811cD29439 for linux-mips-outgoing; Mon, 7 May 2001 18:01:38 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4810xF29390 for ; Mon, 7 May 2001 18:01:00 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f480wwC32752 for linux-mips@oss.sgi.com; Mon, 7 May 2001 21:58:58 -0300 Received: from guadalquivir.fnet.fr (guadalquivir.fnet.fr [193.104.112.133]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id VAA03005 for ; Mon, 7 May 2001 21:17:51 +0200 (MET DST) Received: from localhost (localhost [[UNIX: localhost]]) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id VAA07473; Mon, 7 May 2001 21:17:12 +0200 (MET DST) Date: Mon, 7 May 2001 21:17:12 +0200 (MET DST) X-From_: chief@bandits.org Mon May 7 21:17:08 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id VAA07458; Mon, 7 May 2001 21:17:08 +0200 (MET DST) Received-Date: Mon, 7 May 2001 21:17:08 +0200 (MET DST) Received: from m42-mp1-cvx1b.col.ntl.com(213.104.72.42), claiming to be "[213.104.72.42]" via SMTP by guadalquivir.fnet.fr, id smtpd007441; Mon May 7 21:15:34 2001 Received: by boreas.yi.org. (chainmail); Mon, 7 May 2001 19:14:40 GMT To: Cc: Ralf Baechle , , David S , Russell King , , , Stephen Rothwell , , , Subject: simple userspace pm interface From: John Fremlin Old-Date: 07 May 2001 20:14:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Diagnostic: Not on the accept list X-Envelope-To: linux-mips Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-=-= Here is a patch to deal with PM events (e.g. button presses) in a system independent way. Could people with the applicable hardware test out or comment on the changes? The files affected are arch/i386/kernel/apm.c arch/mips/sgi/kernel/reset.c arch/mips64/sgi-ip22/ip22-reset.c arch/sparc64/kernel/power.c drivers/acpi/driver.c drivers/char/nwbutton.c drivers/char/nwbutton.h There are many power management and button press drivers in the kernel. They all tend to have their own interface to distribute events to userspace. This is bad, because it means duplicated code, and requires arch specific userspace whatnots, which should not be necessary. Specifically, at the moment, the following approaches are taken by various subsystems: - launch /sbin/shutdown - signal init - do nothing And there 3 or so different special devices that userspace can read to see events. After this patch there are only 2 that I know of (ACPI and /dev/boxevent, perhaps the ACPI stuff could also be removed, I didn't look). The patch converts the PM drivers I found to use a single interface. (Only APM is tested because nobody has given me e.g. a SPARC box: i.e. the patch is just a suggestion.) The kernel interface is very simple. Each driver just does #include void button_interrupt() { boxevent(BUTTONEVENT_OFF,"TurboSnail","button pressed"); } and the event is exported to any number of userspace listeners on /dev/boxevent. Thereby writing a new power button driver does not involve having to deal with all the baggage of device nodes, etc. You can create /dev/boxevent with mknod boxevent c 10 137 You can see what events occur simply by "cat"ing it to the console. The format is very simple. Where is one of the strings OFF,SLEEP,WAKE,EMERGENCY,NOTIFY (if a reader does not read events quickly enough, it will get a MSGFLOOD event), is a space character, is a word denoting the kernel pm interface responsible for generating the event, is an arbitrary string. is a newline character \n. This is flexible. It means a reasonable default behaviour can be suggested by the kernel (OFF,SLEEP,etc.) for events that userspace doesn't know about, but userspace can choose fine grained policy and provide helpful error messages based on the exact event name by checking the description. In fact, here is the "daemon" I use #! /bin/perl use Sys::Syslog qw(:DEFAULT setlogsock); sub do_off { system("/sbin/shutdown -p now"); exit(0); } sub do_overflow { setlogsock("unix"); openlog("boxd","cons","daemon"); syslog('err',"messages arriving too fast"); closelog(); } while(<>){ if(/MSGFLOOD/) { do_overflow(); next } if(/^SLEEP APM user suspend/){ do_off(); next } if(/^OFF/){ do_off(); next } } The patch against 2.4.4 is attached. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=linux-2.4.4-boxevent-1.patch diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/i386/kernel/apm.c linux-2.4.4-boxevent/arch/i386/kernel/apm.c --- linux-2.4.4-orig/arch/i386/kernel/apm.c Tue May 1 14:33:34 2001 +++ linux-2.4.4-boxevent/arch/i386/kernel/apm.c Mon May 7 15:36:53 2001 @@ -148,6 +148,9 @@ * 1.14: Make connection version persist across module unload/load. * Enable and engage power management earlier. * Disengage power management on module unload. + * 1.15: Move most of the /dev/apm_bios stuff to drivers/char/boxevent.c + * Reject all events by default + * (John Fremlin ) * * APM 1.1 Reference: * @@ -186,6 +189,7 @@ #include #include #include +#include #include #include @@ -301,10 +305,6 @@ int suser: 1; int suspend_wait: 1; int suspend_result; - int suspends_pending; - int standbys_pending; - int suspends_read; - int standbys_read; int event_head; int event_tail; apm_event_t events[APM_MAX_EVENTS]; @@ -325,8 +325,7 @@ #ifdef CONFIG_APM_CPU_IDLE static int clock_slowed; #endif -static int suspends_pending; -static int standbys_pending; +static int suspend_launched; static int waiting_for_resume; static int ignore_normal_resume; static int bounce_interval = DEFAULT_BOUNCE_INTERVAL; @@ -352,7 +351,7 @@ static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue); static struct apm_user * user_list; -static char driver_version[] = "1.14"; /* no spaces */ +static char driver_version[] = "1.15"; /* no spaces */ static char * apm_event_name[] = { "system standby", @@ -579,56 +578,6 @@ clock_slowed = 0; } } - -#if 0 -extern int hlt_counter; - -/* - * If no process has been interested in this - * CPU for some time, we want to wake up the - * power management thread - we probably want - * to conserve power. - */ -#define HARD_IDLE_TIMEOUT (HZ/3) - -/* This should wake up kapmd and ask it to slow the CPU */ -#define powermanagement_idle() do { } while (0) - -/* - * This is the idle thing. - */ -static void apm_cpu_idle(void) -{ - unsigned int start_idle; - - start_idle = jiffies; - while (1) { - if (!current->need_resched) { - if (jiffies - start_idle < HARD_IDLE_TIMEOUT) { - if (!current_cpu_data.hlt_works_ok) - continue; - if (hlt_counter) - continue; - __cli(); - if (!current->need_resched) - safe_halt(); - else - __sti(); - continue; - } - - /* - * Ok, do some power management - we've been idle for too long - */ - powermanagement_idle(); - } - - schedule(); - check_pgt_cache(); - start_idle = jiffies; - } -} -#endif #endif #ifdef CONFIG_SMP @@ -791,54 +740,6 @@ } #endif -static int queue_empty(struct apm_user *as) -{ - return as->event_head == as->event_tail; -} - -static apm_event_t get_queued_event(struct apm_user *as) -{ - as->event_tail = (as->event_tail + 1) % APM_MAX_EVENTS; - return as->events[as->event_tail]; -} - -static void queue_event(apm_event_t event, struct apm_user *sender) -{ - struct apm_user * as; - - if (user_list == NULL) - return; - for (as = user_list; as != NULL; as = as->next) { - if (as == sender) - continue; - as->event_head = (as->event_head + 1) % APM_MAX_EVENTS; - if (as->event_head == as->event_tail) { - static int notified; - - if (notified++ == 0) - printk(KERN_ERR "apm: an event queue overflowed\n"); - as->event_tail = (as->event_tail + 1) % APM_MAX_EVENTS; - } - as->events[as->event_head] = event; - if (!as->suser) - continue; - switch (event) { - case APM_SYS_SUSPEND: - case APM_USER_SUSPEND: - as->suspends_pending++; - suspends_pending++; - break; - - case APM_SYS_STANDBY: - case APM_USER_STANDBY: - as->standbys_pending++; - standbys_pending++; - break; - } - } - wake_up_interruptible(&apm_waitqueue); -} - static void set_time(void) { unsigned long flags; @@ -898,8 +799,6 @@ printk(KERN_CRIT "apm: Critical suspend was vetoed, expect armageddon\n" ); return 0; } - if (apm_info.connection_version > 0x100) - apm_set_power_state(APM_STATE_REJECT); return 0; } break; @@ -913,6 +812,44 @@ return 1; } +static void announce_event(apm_event_t event) +{ + char*type = BOXEVENT_NOTIFY; + char*name; + + if (event <= NR_APM_EVENT_NAME) + name = apm_event_name[event - 1]; + else name = "unknown event"; + + switch(event){ + case APM_SYS_STANDBY: + case APM_USER_STANDBY: + case APM_SYS_SUSPEND: + case APM_USER_SUSPEND: + case APM_CRITICAL_SUSPEND: + type = BOXEVENT_SLEEP; + break; + case APM_NORMAL_RESUME: + case APM_CRITICAL_RESUME: + case APM_STANDBY_RESUME: + type = BOXEVENT_WAKE; + break; + case APM_CAPABILITY_CHANGE: + type = BOXEVENT_WAKE; + break; + case APM_LOW_BATTERY: + type = BOXEVENT_EMERGENCY; + break; + case APM_POWER_STATUS_CHANGE: + type = BOXEVENT_POWERCHANGE; + break; + default: + type = BOXEVENT_NOTIFY; + } + boxevent(type,"APM",name); +} + + static int suspend(void) { int err; @@ -929,12 +866,13 @@ apm_error("suspend", err); send_event(APM_NORMAL_RESUME); sti(); - queue_event(APM_NORMAL_RESUME, NULL); + announce_event(APM_NORMAL_RESUME); for (as = user_list; as != NULL; as = as->next) { as->suspend_wait = 0; as->suspend_result = ((err == APM_SUCCESS) ? 0 : -EIO); } ignore_normal_resume = 1; + suspend_launched = 0; wake_up_interruptible(&apm_suspend_waitqueue); return err; } @@ -989,46 +927,16 @@ if (ignore_normal_resume && (event != APM_NORMAL_RESUME)) ignore_normal_resume = 0; + announce_event(event); + switch (event) { case APM_SYS_STANDBY: case APM_USER_STANDBY: - if (send_event(event)) { - queue_event(event, NULL); - if (standbys_pending <= 0) - standby(); - } - break; - case APM_USER_SUSPEND: -#ifdef CONFIG_APM_IGNORE_USER_SUSPEND + case APM_SYS_SUSPEND: if (apm_info.connection_version > 0x100) apm_set_power_state(APM_STATE_REJECT); break; -#endif - case APM_SYS_SUSPEND: - if (ignore_bounce) { - if (apm_info.connection_version > 0x100) - apm_set_power_state(APM_STATE_REJECT); - break; - } - /* - * If we are already processing a SUSPEND, - * then further SUSPEND events from the BIOS - * will be ignored. We also return here to - * cope with the fact that the Thinkpads keep - * sending a SUSPEND event until something else - * happens! - */ - if (waiting_for_resume) - return; - if (send_event(event)) { - queue_event(event, NULL); - waiting_for_resume = 1; - if (suspends_pending <= 0) - (void) suspend(); - } - break; - case APM_NORMAL_RESUME: case APM_CRITICAL_RESUME: case APM_STANDBY_RESUME: @@ -1039,7 +947,6 @@ || (ignore_normal_resume == 0)) { set_time(); send_event(event); - queue_event(event, NULL); } break; @@ -1047,7 +954,6 @@ case APM_LOW_BATTERY: case APM_POWER_STATUS_CHANGE: send_event(event); - queue_event(event, NULL); break; case APM_UPDATE_TIME: @@ -1055,7 +961,9 @@ break; case APM_CRITICAL_SUSPEND: + suspend_launched = 1; send_event(event); + /* * We can only hope it worked - we are not allowed * to reject a critical suspend. @@ -1068,20 +976,6 @@ static void apm_event_handler(void) { - static int pending_count = 4; - int err; - - if ((standbys_pending > 0) || (suspends_pending > 0)) { - if ((apm_info.connection_version > 0x100) && (pending_count-- <= 0)) { - pending_count = 4; - if (debug) - printk(KERN_DEBUG "apm: setting state busy\n"); - err = apm_set_power_state(APM_STATE_BUSY); - if (err) - apm_error("busy", err); - } - } else - pending_count = 4; check_events(); } @@ -1146,78 +1040,10 @@ return 0; } -static ssize_t do_read(struct file *fp, char *buf, size_t count, loff_t *ppos) -{ - struct apm_user * as; - int i; - apm_event_t event; - DECLARE_WAITQUEUE(wait, current); - - as = fp->private_data; - if (check_apm_user(as, "read")) - return -EIO; - if (count < sizeof(apm_event_t)) - return -EINVAL; - if (queue_empty(as)) { - if (fp->f_flags & O_NONBLOCK) - return -EAGAIN; - add_wait_queue(&apm_waitqueue, &wait); -repeat: - set_current_state(TASK_INTERRUPTIBLE); - if (queue_empty(as) && !signal_pending(current)) { - schedule(); - goto repeat; - } - set_current_state(TASK_RUNNING); - remove_wait_queue(&apm_waitqueue, &wait); - } - i = count; - while ((i >= sizeof(event)) && !queue_empty(as)) { - event = get_queued_event(as); - if (copy_to_user(buf, &event, sizeof(event))) { - if (i < count) - break; - return -EFAULT; - } - switch (event) { - case APM_SYS_SUSPEND: - case APM_USER_SUSPEND: - as->suspends_read++; - break; - - case APM_SYS_STANDBY: - case APM_USER_STANDBY: - as->standbys_read++; - break; - } - buf += sizeof(event); - i -= sizeof(event); - } - if (i < count) - return count - i; - if (signal_pending(current)) - return -ERESTARTSYS; - return 0; -} - -static unsigned int do_poll(struct file *fp, poll_table * wait) -{ - struct apm_user * as; - - as = fp->private_data; - if (check_apm_user(as, "poll")) - return 0; - poll_wait(fp, &apm_waitqueue, wait); - if (!queue_empty(as)) - return POLLIN | POLLRDNORM; - return 0; -} - static int do_ioctl(struct inode * inode, struct file *filp, u_int cmd, u_long arg) { struct apm_user * as; - DECLARE_WAITQUEUE(wait, current); as = filp->private_data; if (check_apm_user(as, "ioctl")) @@ -1226,43 +1052,27 @@ return -EPERM; switch (cmd) { case APM_IOC_STANDBY: - if (as->standbys_read > 0) { - as->standbys_read--; - as->standbys_pending--; - standbys_pending--; - } else if (!send_event(APM_USER_STANDBY)) + if (!send_event(APM_USER_STANDBY)) return -EAGAIN; - else - queue_event(APM_USER_STANDBY, as); - if (standbys_pending <= 0) - standby(); + standby(); break; case APM_IOC_SUSPEND: - if (as->suspends_read > 0) { - as->suspends_read--; - as->suspends_pending--; - suspends_pending--; - } else if (!send_event(APM_USER_SUSPEND)) - return -EAGAIN; - else - queue_event(APM_USER_SUSPEND, as); - if (suspends_pending <= 0) { - if (suspend() != APM_SUCCESS) - return -EIO; - } else { + if(suspend_launched) { as->suspend_wait = 1; - add_wait_queue(&apm_suspend_waitqueue, &wait); - while (1) { - set_current_state(TASK_INTERRUPTIBLE); - if ((as->suspend_wait == 0) - || signal_pending(current)) - break; - schedule(); + if(wait_event_interruptible(apm_suspend_waitqueue, + as->suspend_wait == 0)) { + as->suspend_wait = 0; + return -ERESTARTSYS; } - set_current_state(TASK_RUNNING); - remove_wait_queue(&apm_suspend_waitqueue, &wait); + return as->suspend_result; } + + suspend_launched = 1; + if (!send_event(APM_USER_SUSPEND)) + return -EAGAIN; + if (suspend() != APM_SUCCESS) + return -EIO; break; default: return -EINVAL; @@ -1279,16 +1089,7 @@ return 0; filp->private_data = NULL; lock_kernel(); - if (as->standbys_pending > 0) { - standbys_pending -= as->standbys_pending; - if (standbys_pending <= 0) - standby(); - } - if (as->suspends_pending > 0) { - suspends_pending -= as->suspends_pending; - if (suspends_pending <= 0) - (void) suspend(); - } + if (user_list == as) user_list = as->next; else { @@ -1320,11 +1121,10 @@ } as->magic = APM_BIOS_MAGIC; as->event_tail = as->event_head = 0; - as->suspends_pending = as->standbys_pending = 0; - as->suspends_read = as->standbys_read = 0; + /* * XXX - this is a tiny bit broken, when we consider BSD - * process accounting. If the device is opened by root, we + * process accounting. If the device is opened by root, we * instantly flag that we used superuser privs. Who knows, * we might close the device immediately without doing a * privileged operation -- cevans @@ -1578,8 +1378,6 @@ static struct file_operations apm_bios_fops = { owner: THIS_MODULE, - read: do_read, - poll: do_poll, ioctl: do_ioctl, open: do_open, release: do_release, diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/mips/sgi/kernel/reset.c linux-2.4.4-boxevent/arch/mips/sgi/kernel/reset.c --- linux-2.4.4-orig/arch/mips/sgi/kernel/reset.c Sat May 13 16:29:14 2000 +++ linux-2.4.4-boxevent/arch/mips/sgi/kernel/reset.c Mon May 7 15:55:46 2001 @@ -7,11 +7,14 @@ * for more details. * * Copyright (C) 1997, 1998 by Ralf Baechle + * + * 2001 May 7 Mangled to use new boxevent interface by John Fremlin */ #include #include #include #include +#include #include #include #include @@ -21,22 +24,14 @@ #include /* - * Just powerdown if init hasn't done after POWERDOWN_TIMEOUT seconds. - * I'm not shure if this feature is a good idea, for now it's here just to - * make the power button make behave just like under IRIX. - */ -#define POWERDOWN_TIMEOUT 120 - -/* * Blink frequency during reboot grace period and when paniced. */ -#define POWERDOWN_FREQ (HZ / 4) #define PANIC_FREQ (HZ / 8) static unsigned char sgi_volume; -static struct timer_list power_timer, blink_timer, debounce_timer, volume_timer; -static int shuting_down, has_paniced; +static struct timer_list blink_timer, debounce_timer, volume_timer; +static int has_paniced; static void sgi_machine_restart(char *command) __attribute__((noreturn)); static void sgi_machine_halt(void) __attribute__((noreturn)); @@ -45,15 +40,11 @@ /* XXX How to pass the reboot command to the firmware??? */ static void sgi_machine_restart(char *command) { - if (shuting_down) - sgi_machine_power_off(); prom_reboot(); } static void sgi_machine_halt(void) { - if (shuting_down) - sgi_machine_power_off(); prom_imode(); } @@ -113,20 +104,7 @@ { if (has_paniced) return; - - if (shuting_down || kill_proc(1, SIGINT, 1)) { - /* No init process or button pressed twice. */ - sgi_machine_power_off(); - } - - shuting_down = 1; - blink_timer.data = POWERDOWN_FREQ; - blink_timeout(POWERDOWN_FREQ); - - init_timer(&power_timer); - power_timer.function = power_timeout; - power_timer.expires = jiffies + POWERDOWN_TIMEOUT * HZ; - add_timer(&power_timer); + boxevent(BOXEVENT_OFF,"MIPS","button pressed"); } void inline sgi_volume_set(unsigned char volume) @@ -146,9 +124,11 @@ { del_timer(&volume_timer); + boxevent(BOXEVENT_NOTIFY,"MIPS","volume up button pressed"); + if (sgi_volume < 0xff) sgi_volume++; - + hpc3c0->pbus_extregs[2][0] = sgi_volume; hpc3c0->pbus_extregs[2][1] = sgi_volume; @@ -163,6 +143,8 @@ { del_timer(&volume_timer); + boxevent(BOXEVENT_NOTIFY,"MIPS","volume down button pressed"); + if (sgi_volume > 0) sgi_volume--; diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/mips64/sgi-ip22/ip22-reset.c linux-2.4.4-boxevent/arch/mips64/sgi-ip22/ip22-reset.c --- linux-2.4.4-orig/arch/mips64/sgi-ip22/ip22-reset.c Sat May 13 16:30:17 2000 +++ linux-2.4.4-boxevent/arch/mips64/sgi-ip22/ip22-reset.c Mon May 7 15:58:56 2001 @@ -7,11 +7,14 @@ * Reset an IP22. * * Copyright (C) 1997, 1998, 1999 by Ralf Baechle + * + * 2001 May 7 Mangled to use new boxevent interface by John Fremlin */ #include #include #include #include +#include #include #include #include @@ -20,23 +23,14 @@ #include /* - * Just powerdown if init hasn't done after POWERDOWN_TIMEOUT seconds. - * I'm not shure if this feature is a good idea, for now it's here just to - * make the power button make behave just like under IRIX. - */ -#define POWERDOWN_TIMEOUT 120 - -/* * Blink frequency during reboot grace period and when paniced. */ -#define POWERDOWN_FREQ (HZ / 4) #define PANIC_FREQ (HZ / 8) static unsigned char sgi_volume; -static struct timer_list power_timer, blink_timer, debounce_timer, volume_timer; -static int shuting_down, has_paniced; - +static struct timer_list blink_timer, debounce_timer, volume_timer; +static int has_paniced; void machine_restart(char *command) __attribute__((noreturn)); void machine_halt(void) __attribute__((noreturn)); void machine_power_off(void) __attribute__((noreturn)); @@ -44,15 +38,11 @@ /* XXX How to pass the reboot command to the firmware??? */ void machine_restart(char *command) { - if (shuting_down) - machine_power_off(); ArcReboot(); } void machine_halt(void) { - if (shuting_down) - machine_power_off(); ArcEnterInteractiveMode(); } @@ -76,11 +66,6 @@ } } -static void power_timeout(unsigned long data) -{ - machine_power_off(); -} - static void blink_timeout(unsigned long data) { /* XXX Fix this for Fullhouse */ @@ -113,19 +98,7 @@ if (has_paniced) return; - if (shuting_down || kill_proc(1, SIGINT, 1)) { - /* No init process or button pressed twice. */ - machine_power_off(); - } - - shuting_down = 1; - blink_timer.data = POWERDOWN_FREQ; - blink_timeout(POWERDOWN_FREQ); - - init_timer(&power_timer); - power_timer.function = power_timeout; - power_timer.expires = jiffies + POWERDOWN_TIMEOUT * HZ; - add_timer(&power_timer); + boxevent(BOXEVENT_OFF,"MIPS64-IP22","button pressed"); } void inline ip22_volume_set(unsigned char volume) @@ -145,6 +118,8 @@ { del_timer(&volume_timer); + boxevent(BOXEVENT_NOTIFY,"MIPS64-IP22","volume up button pressed"); + if (sgi_volume < 0xff) sgi_volume++; @@ -162,6 +137,8 @@ { del_timer(&volume_timer); + boxevent(BOXEVENT_NOTIFY,"MIPS64-IP22","volume down button pressed"); + if (sgi_volume > 0) sgi_volume--; diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/sparc64/kernel/power.c linux-2.4.4-boxevent/arch/sparc64/kernel/power.c --- linux-2.4.4-orig/arch/sparc64/kernel/power.c Tue Jul 11 23:46:08 2000 +++ linux-2.4.4-boxevent/arch/sparc64/kernel/power.c Mon May 7 15:31:17 2001 @@ -10,10 +10,9 @@ #include #include #include +#include #include - -#define __KERNEL_SYSCALLS__ #include #ifdef CONFIG_PCI @@ -26,10 +25,7 @@ static void power_handler(int irq, void *dev_id, struct pt_regs *regs) { - if (button_pressed == 0) { - wake_up(&powerd_wait); - button_pressed = 1; - } + boxevent_intr(BOXEVENT_OFF,"SPARC-PCI","button pressed"); } #endif /* CONFIG_PCI */ @@ -52,30 +48,6 @@ } #ifdef CONFIG_PCI -static int powerd(void *__unused) -{ - static char *envp[] = { "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL }; - char *argv[] = { "/sbin/shutdown", "-h", "now", NULL }; - - daemonize(); - sprintf(current->comm, "powerd"); - -again: - while(button_pressed == 0) { - spin_lock_irq(¤t->sigmask_lock); - flush_signals(current); - spin_unlock_irq(¤t->sigmask_lock); - interruptible_sleep_on(&powerd_wait); - } - - /* Ok, down we go... */ - if (execve("/sbin/shutdown", argv, envp) < 0) { - printk("powerd: shutdown execution failed\n"); - button_pressed = 0; - goto again; - } - return 0; -} void __init power_init(void) { @@ -93,11 +65,7 @@ found: power_reg = (unsigned long)ioremap(edev->resource[0].start, 0x4); printk("power: Control reg at %016lx ... ", power_reg); - if (kernel_thread(powerd, 0, CLONE_FS) < 0) { - printk("Failed to start power daemon.\n"); - return; - } - printk("powerd running.\n"); + if (edev->irqs[0] != 0) { if (request_irq(edev->irqs[0], power_handler, SA_SHIRQ, "power", diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/drivers/acpi/driver.c linux-2.4.4-boxevent/drivers/acpi/driver.c --- linux-2.4.4-orig/drivers/acpi/driver.c Thu Feb 22 18:28:26 2001 +++ linux-2.4.4-boxevent/drivers/acpi/driver.c Mon May 7 15:57:08 2001 @@ -21,6 +21,8 @@ * Changes * David Woodhouse 2000-12-6 * - Fix interruptible_sleep_on() races + * John Fremlin 2001-05-07 + * - Mangled to use new boxevent interface */ #include @@ -33,6 +35,7 @@ #include #include #include +#include #include #include "acpi.h" #include "driver.h" @@ -163,9 +166,11 @@ switch (event) { case ACPI_EVENT_POWER_BUTTON: + boxevent(BOXEVENT_OFF,"ACPI","power button pressed"); mask = ACPI_PWRBTN; break; case ACPI_EVENT_SLEEP_BUTTON: + boxevent(BOXEVENT_SLEEP,"ACPI","sleep button pressed"); mask = ACPI_SLPBTN; break; default: diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/drivers/char/Config.in linux-2.4.4-boxevent/drivers/char/Config.in --- linux-2.4.4-orig/drivers/char/Config.in Tue May 1 14:32:05 2001 +++ linux-2.4.4-boxevent/drivers/char/Config.in Mon May 7 15:55:47 2001 @@ -150,9 +150,6 @@ if [ "$CONFIG_ARCH_NETWINDER" = "y" ]; then tristate 'NetWinder thermometer support' CONFIG_DS1620 tristate 'NetWinder Button' CONFIG_NWBUTTON - if [ "$CONFIG_NWBUTTON" != "n" ]; then - bool ' Reboot Using Button' CONFIG_NWBUTTON_REBOOT - fi tristate 'NetWinder flash support' CONFIG_NWFLASH fi @@ -187,6 +184,8 @@ bool ' Generic SiS support' CONFIG_AGP_SIS bool ' ALI chipset support' CONFIG_AGP_ALI fi + +tristate '/dev/boxevent (userspace async event interface)' CONFIG_BOXEVENT source drivers/char/drm/Config.in diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/drivers/char/Makefile linux-2.4.4-boxevent/drivers/char/Makefile --- linux-2.4.4-orig/drivers/char/Makefile Tue May 1 14:33:51 2001 +++ linux-2.4.4-boxevent/drivers/char/Makefile Mon May 7 14:32:49 2001 @@ -179,6 +179,8 @@ obj-$(CONFIG_QIC02_TAPE) += tpqic02.o +obj-$(CONFIG_BOXEVENT) += boxevent.o + subdir-$(CONFIG_FTAPE) += ftape subdir-$(CONFIG_DRM) += drm subdir-$(CONFIG_PCMCIA) += pcmcia diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/drivers/char/boxevent.c linux-2.4.4-boxevent/drivers/char/boxevent.c --- linux-2.4.4-orig/drivers/char/boxevent.c Thu Jan 1 01:00:00 1970 +++ linux-2.4.4-boxevent/drivers/char/boxevent.c Mon May 7 16:22:45 2001 @@ -0,0 +1,291 @@ +/* (C) 2001 John Fremlin */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +static const char msg_overflow[] = "MSGFLOOD KERNEL messages lost\n"; + +#define N_MSGS 16 +#define MSG_MAXLEN 100 + +static const char ring[N_MSGS][MSG_MAXLEN]; +static unsigned ring_next; /*=0*/ + +struct fop_priv +{ + int fp_overflow; + unsigned fp_ringpos; + unsigned fp_msgpos; + + struct list_head fp_entry; +} +; + +static DECLARE_WAIT_QUEUE_HEAD(waiters); +static LIST_HEAD(listeners); +static spinlock_t listeners_lock = SPIN_LOCK_UNLOCKED; + /* protects listeners, ring, ring_next and all the ring_pos in the fop_priv */ + +/** + * boxevent - inform userspace listeners of a power management event + * + * @event_type: one of the BOXEVENT_* defines in linux/boxevent.h, + * general event class + * @subsystem: kernel subsystem generating the event (e.g. "APM") + * @desc: longer description of event (e.g. "lid closed") + * + * The arguments are copied, so the caller is responsible for + * freeing them. This function may be called from interrupt + * context. + */ + +void boxevent(const char* event_type, + const char* subsystem, + const char* desc) +{ + unsigned ring_cur; + unsigned long flags; + + /* No snprintf in kernel */ + if(strlen(event_type)+strlen(subsystem)+strlen(desc) + 5 >= + MSG_MAXLEN) { + panic("boxevent() arguments too long\n"); + } + + printk(KERN_DEBUG "box event: %s %s %s\n",event_type,subsystem,desc); + + spin_lock_irqsave(&listeners_lock,flags); + + ring_cur = ring_next; + + if(++ring_next >= N_MSGS) + ring_next = 0; + + { + struct list_head *i; + + list_for_each(i,&listeners) { + struct fop_priv *priv = list_entry(i, struct fop_priv, fp_entry); + if(ring_next == priv->fp_ringpos) { + /* we will actually overflow next item, + * but it is easier to complain now + */ + priv->fp_msgpos = 0; + priv->fp_overflow = 1; + } + } + + + } + + sprintf((char*)ring[ring_cur],"%s %s %s\n",event_type,subsystem,desc); + + spin_unlock_irqrestore(&listeners_lock,flags); + + wake_up_all(&waiters); /* Recipe for contention */ +} + +static ssize_t do_read(struct fop_priv*priv,char*buf,size_t count) +{ + ssize_t ret = 0; + char* msg; + + if(!priv->fp_overflow) { + if(priv->fp_ringpos == ring_next) { + ret = ret ? ret : -EAGAIN; + goto out; + } + msg = (char*)ring[priv->fp_ringpos]; + } + else + msg = (char*)msg_overflow; + + msg += priv->fp_msgpos; + ret = strlen(msg); + if(ret <= count){ + if(priv->fp_overflow){ + priv->fp_overflow = 0; + priv->fp_ringpos = ring_next; + /* This means the minimum number of + * messages is lost, which might not + * be an altogether good idea, because + * the reader is not given much chance + * to catch up with the flood + */ + } + + if (++priv->fp_ringpos >= N_MSGS) + priv->fp_ringpos = 0; + + priv->fp_msgpos = 0; + } else { + ret = count; + priv->fp_msgpos += count; + } + + if (copy_to_user(buf, msg, ret)) + ret = -EFAULT; + + out: + return ret; +} + + +static ssize_t fop_read(struct file * file, char * buf, + size_t count, loff_t *ppos) +{ + ssize_t ret; + unsigned long flags; + struct fop_priv *priv = (struct fop_priv *)file->private_data; + + if (ppos != &file->f_pos) { + ret = -ESPIPE; + goto out; + } + + retry: + spin_lock_irqsave(&listeners_lock,flags); + + ret = do_read(priv,buf,count); + + spin_unlock_irqrestore(&listeners_lock,flags); + + if((ret == -EAGAIN) && !(file->f_flags&O_NONBLOCK)) { + if (wait_event_interruptible(waiters, + priv->fp_overflow || priv->fp_ringpos != ring_next) + == -ERESTARTSYS) { + ret = ret ? ret : -ERESTARTSYS; + goto out; + } + goto retry; + } + out: + return ret; +} + +static int fop_open(struct inode * inode, struct file * file) +{ + struct fop_priv*priv; + unsigned long flags; + + priv = kmalloc(sizeof *priv,GFP_KERNEL); + if(!priv) + return -ENOMEM; + + memset(priv,0,sizeof *priv); + + file->private_data = priv; + + spin_lock_irqsave(&listeners_lock,flags); + priv->fp_ringpos = ring_next; + list_add(&priv->fp_entry, &listeners); + spin_unlock_irqrestore(&listeners_lock,flags); + + return 0; +} + +static void do_remove_priv(struct fop_priv *priv) +{ + list_del(&priv->fp_entry); + kfree(priv); +} + +static int fop_release(struct inode * inode, struct file * file) +{ + struct fop_priv *priv = (struct fop_priv *)file->private_data; + unsigned long flags; + + spin_lock_irqsave(&listeners_lock,flags); + + do_remove_priv(priv); + + spin_unlock_irqrestore(&listeners_lock,flags); + + return 0; +} + +static unsigned int fop_poll(struct file *file, poll_table * wait) +{ + struct fop_priv *priv = (struct fop_priv *)file->private_data; + unsigned ret = 0; + unsigned long flags; + + poll_wait(file, &waiters, wait); + + spin_lock_irqsave(&listeners_lock,flags); + if(priv->fp_overflow || priv->fp_ringpos != ring_next) + ret = POLLIN | POLLRDNORM; + spin_unlock_irqrestore(&listeners_lock,flags); + + return ret; +} + + +static struct file_operations box_fops = { + owner: THIS_MODULE, + read: fop_read, + poll: fop_poll, + open: fop_open, + release: fop_release, +}; + +static struct miscdevice box_dev= +{ + BOXEVENT_MINOR, + "boxevent", + &box_fops +}; + +static int __init box_init(void) +{ + if(misc_register(&box_dev)){ + printk(KERN_DEBUG "boxevent: could not register device node\n"); + return -EBUSY; + } + + /* FIXME: remove if this gets into main tree */ + printk(KERN_INFO "boxevent: subsystem ready\n"); + return 0; +} + +static void __exit box_exit(void) +{ + struct list_head *i,*j; + unsigned long flags; + + if(misc_deregister(&box_dev)) + printk(KERN_DEBUG "boxevent: could not deregister device node\n"); + + /* FIXME: remove if this gets into main tree */ + printk(KERN_INFO "boxevent: shut down\n"); + + spin_lock_irqsave(&listeners_lock,flags); + + for(i=listeners.next;i!=&listeners;i=j){ + struct fop_priv *priv + = list_entry(i, struct fop_priv, fp_entry); + j = i->next; + do_remove_priv(priv); + } + + spin_unlock_irqrestore(&listeners_lock,flags); +} + +module_init(box_init); +module_exit(box_exit); + +MODULE_DESCRIPTION("Simple asynchronous event interface"); +MODULE_AUTHOR("John Fremlin"); +EXPORT_SYMBOL(boxevent); diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/drivers/char/nwbutton.c linux-2.4.4-boxevent/drivers/char/nwbutton.c --- linux-2.4.4-orig/drivers/char/nwbutton.c Sun Aug 13 17:54:15 2000 +++ linux-2.4.4-boxevent/drivers/char/nwbutton.c Mon May 7 15:26:02 2001 @@ -2,6 +2,7 @@ * NetWinder Button Driver- * Copyright (C) Alex Holden 1998, 1999. * + * 2001 May 7: Mangled for the the boxevent interface by John Fremlin */ #include @@ -12,7 +13,7 @@ #include #include #include -#include +#include #include #include #include @@ -28,11 +29,9 @@ static struct timer_list button_timer; /* Times for the end of a sequence */ static DECLARE_WAIT_QUEUE_HEAD(button_wait_queue); /* Used for blocking read */ static char button_output_buffer[32]; /* Stores data to write out of device */ -static int bcount; /* The number of bytes in the buffer */ static int bdelay = BUTTON_DELAY; /* The delay, in jiffies */ static struct button_callback button_callback_list[32]; /* The callback list */ static int callback_count; /* The number of callbacks registered */ -static int reboot_count = NUM_PRESSES_REBOOT; /* Number of presses to reboot */ /* * This function is called by other drivers to register a callback function @@ -119,19 +118,15 @@ * This function is called when the button_timer times out. * ie. When you don't press the button for bdelay jiffies, this is taken to * mean you have ended the sequence of key presses, and this function is - * called to wind things up (write the press_count out to /dev/button, call + * called to wind things up (write the press_count out to /dev/boxevent, call * any matching registered function callbacks, initiate reboot, etc.). */ static void button_sequence_finished (unsigned long parameters) { -#ifdef CONFIG_NWBUTTON_REBOOT /* Reboot using button is enabled */ - if (button_press_count == reboot_count) { - kill_proc (1, SIGINT, 1); /* Ask init to reboot us */ - } -#endif /* CONFIG_NWBUTTON_REBOOT */ button_consume_callbacks (button_press_count); - bcount = sprintf (button_output_buffer, "%d\n", button_press_count); + sprintf (button_output_buffer, "%d presses", button_press_count); + boxevent(BOXEVENT_NOTIFY,"nwbutton",button_output_buffer); button_press_count = 0; /* Reset the button press counter */ wake_up_interruptible (&button_wait_queue); } @@ -157,53 +152,11 @@ } /* - * This function is called when a user space program attempts to read - * /dev/nwbutton. It puts the device to sleep on the wait queue until - * button_sequence_finished writes some data to the buffer and flushes - * the queue, at which point it writes the data out to the device and - * returns the number of characters it has written. This function is - * reentrant, so that many processes can be attempting to read from the - * device at any one time. - */ - -static int button_read (struct file *filp, char *buffer, - size_t count, loff_t *ppos) -{ - interruptible_sleep_on (&button_wait_queue); - return (copy_to_user (buffer, &button_output_buffer, bcount)) - ? -EFAULT : bcount; -} - -/* - * This structure is the file operations structure, which specifies what - * callbacks functions the kernel should call when a user mode process - * attempts to perform these operations on the device. - */ - -static struct file_operations button_fops = { - owner: THIS_MODULE, - read: button_read, -}; - -/* - * This structure is the misc device structure, which specifies the minor - * device number (158 in this case), the name of the device (for /proc/misc), - * and the address of the above file operations structure. - */ - -static struct miscdevice button_misc_device = { - BUTTON_MINOR, - "nwbutton", - &button_fops, -}; - -/* - * This function is called to initialise the driver, either from misc.c at - * bootup if the driver is compiled into the kernel, or from init_module - * below at module insert time. It attempts to register the device node - * and the IRQ and fails with a warning message if either fails, though - * neither ever should because the device number and IRQ are unique to - * this driver. + * This function is called to initialise the driver, either from + * misc.c at bootup if the driver is compiled into the kernel, or from + * init_module below at module insert time. It attempts to register + * the IRQ and fails with a warning message if this fails, though it + * never ever should because the IRQ is unique to this driver. */ static int __init nwbutton_init(void) @@ -214,17 +167,10 @@ printk (KERN_INFO "NetWinder Button Driver Version %s (C) Alex Holden " " 1998.\n", VERSION); - if (misc_register (&button_misc_device)) { - printk (KERN_WARNING "nwbutton: Couldn't register device 10, " - "%d.\n", BUTTON_MINOR); - return -EBUSY; - } - if (request_irq (IRQ_NETWINDER_BUTTON, button_handler, SA_INTERRUPT, "nwbutton", NULL)) { printk (KERN_WARNING "nwbutton: IRQ %d is not free.\n", IRQ_NETWINDER_BUTTON); - misc_deregister (&button_misc_device); return -EIO; } return 0; @@ -233,7 +179,6 @@ static void __exit nwbutton_exit (void) { free_irq (IRQ_NETWINDER_BUTTON, NULL); - misc_deregister (&button_misc_device); } EXPORT_NO_SYMBOLS; diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/drivers/char/nwbutton.h linux-2.4.4-boxevent/drivers/char/nwbutton.h --- linux-2.4.4-orig/drivers/char/nwbutton.h Wed Jul 5 21:22:07 2000 +++ linux-2.4.4-boxevent/drivers/char/nwbutton.h Mon May 7 15:20:28 2001 @@ -10,10 +10,8 @@ /* Various defines: */ -#define NUM_PRESSES_REBOOT 2 /* How many presses to activate shutdown */ #define BUTTON_DELAY 30 /* How many jiffies for sequence to end */ #define VERSION "0.3" /* Driver version number */ -#define BUTTON_MINOR 158 /* Major 10, Minor 158, /dev/nwbutton */ /* Structure definitions: */ diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/include/linux/boxevent.h linux-2.4.4-boxevent/include/linux/boxevent.h --- linux-2.4.4-orig/include/linux/boxevent.h Thu Jan 1 01:00:00 1970 +++ linux-2.4.4-boxevent/include/linux/boxevent.h Mon May 7 16:04:11 2001 @@ -0,0 +1,34 @@ +/* (C) 2001 John Fremlin */ + +#ifndef _LINUX_BOXEVENT_H_ +#define _LINUX_BOXEVENT_H_ + +#define BOXEVENT_NOTIFY "NOTIFY" +#define BOXEVENT_SLEEP "SLEEP" +#define BOXEVENT_OFF "OFF" +#define BOXEVENT_WAKE "WAKE" +#define BOXEVENT_EMERGENCY "EMERGENCY" +#define BOXEVENT_POWERCHANGE BOXEVENT_NOTIFY + +#define BOXEVENT_FLOOD "MSGFLOOD" + /* only generated if a buffer + * internal to the pm event + * system overflows + */ +#ifdef __KERNEL__ +#include + +#ifdef CONFIG_BOXEVENT +void boxevent(const char* event_type, + const char* subsystem, + const char* desc); +#else +static inline void boxevent(const char* event_type, + const char* subsystem, + const char* desc) +{ +} +#endif +#endif + +#endif diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/include/linux/miscdevice.h linux-2.4.4-boxevent/include/linux/miscdevice.h --- linux-2.4.4-orig/include/linux/miscdevice.h Tue May 1 20:47:45 2001 +++ linux-2.4.4-boxevent/include/linux/miscdevice.h Mon May 7 16:21:26 2001 @@ -17,6 +17,7 @@ #define TEMP_MINOR 131 /* Temperature Sensor */ #define RTC_MINOR 135 #define EFI_RTC_MINOR 136 /* EFI Time services */ +#define BOXEVENT_MINOR 137 #define SUN_OPENPROM_MINOR 139 #define NVRAM_MINOR 144 #define I2O_MINOR 166 --=-=-= -- http://ape.n3.net --=-=-=-- From owner-linux-mips@oss.sgi.com Tue May 8 00:37:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f487bk304704 for linux-mips-outgoing; Tue, 8 May 2001 00:37:46 -0700 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f487beF04697; Tue, 8 May 2001 00:37:41 -0700 Received: from jungo.com ([194.90.113.98]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with ESMTP id KAA18759; Tue, 8 May 2001 10:39:16 +0300 (IDT) Message-ID: <3AF7A202.6060705@jungo.com> Date: Tue, 08 May 2001 10:36:34 +0300 From: Michael Shmulevich Organization: Jungo LTD User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8.1) Gecko/20010326 X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Ian Thompson , linux-mips@oss.sgi.com Subject: Re: binutils 2.8.1 problems References: <3AF098B7.F111B230@palmchip.com> <20010505145344.B1252@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > So then is a binutils and not a compiler problem. What binutils are you > using? Binutils 2.8.1 which I'm still recommending (mostly to avoid > sending people into a maze of version dependencies) is getting dated and > the bug may well have been fixed in the meantime. I have met a weird bug in binutils 2.8.1 on mips lately: when using ".weak" directive in some module which make use of the same asliased symbol, during linkage the symbol doesn't get relocated to a "strong" symbol: ---------------------- in foo.c: ---------------------- extern void bar(); void foo(){ printf("A\n"); } __asm__(".weak bar; bar = foo"); void f1(){ bar(); } ----------------------- in bar.c: ---------------------- void bar(){ printf("B\n"); } ---------------------- in main.c: ---------------------- extern void bar(); extern void f1(); int main(){ f1(); bar(); } ----------------------- This code produce printout of A B since f1() always calls foo() no matter that bar() is defined outside. AFIAIK, there is no ".weakext" macro in 2.8.1. Using objdump on foo.o I see there is no relocation entry for bar, however using gas-2.10 on exactly same assembly does produce relocation entry. So it must definitely be a "gas" problem. Sincerely yours, Michael Shmulevich ______________________________________ Software Developer Jungo - R&D email: michaels@jungo.com web: http://www.jungo.com Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233 Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide) From owner-linux-mips@oss.sgi.com Tue May 8 00:55:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f487tk105244 for linux-mips-outgoing; Tue, 8 May 2001 00:55:46 -0700 Received: from kauha.saunalahti.fi (kauha.saunalahti.fi [195.197.53.227]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f487tiF05241 for ; Tue, 8 May 2001 00:55:44 -0700 Received: from tori.tal.org (milang@dyn-3-081.tku.netti.fi [195.16.220.82]) by kauha.saunalahti.fi (8.10.1/8.10.1) with ESMTP id f487tXP03110 for ; Tue, 8 May 2001 10:55:34 +0300 (EEST) Date: Tue, 8 May 2001 09:56:41 +0300 (EEST) From: Kaj-Michael Lang To: Subject: Linux on a Tektronix XP217C xterm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Any chance of getting linux running on a tektronix x-terminal ? It has a LR33020 cpu, that I think is a R3000 integrated with some graphics chip. I've tried searching for documentation for the chip but I didn't find anything. -- Kaj-Michael Lang, Turku, Finland milang@tal.org http://www.tal.org From owner-linux-mips@oss.sgi.com Tue May 8 01:00:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4880vr05535 for linux-mips-outgoing; Tue, 8 May 2001 01:00:57 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4880uF05532 for ; Tue, 8 May 2001 01:00:56 -0700 Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA16600; Tue, 8 May 2001 10:00:38 +0200 (MET DST) Date: Tue, 8 May 2001 10:00:38 +0200 (MET DST) From: Geert Uytterhoeven To: Kaj-Michael Lang cc: linux-mips@oss.sgi.com Subject: Re: Linux on a Tektronix XP217C xterm In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, Kaj-Michael Lang wrote: > Any chance of getting linux running on a tektronix x-terminal ? It has > a LR33020 cpu, that I think is a R3000 integrated with some graphics > chip. I've tried searching for documentation for the chip but I didn't > find anything. IIRC there's a different separate graphics chip in the 217. I think the 33020 is not a MIPS, but a RISC chip from LSI Logic. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue May 8 01:07:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4887b605947 for linux-mips-outgoing; Tue, 8 May 2001 01:07:37 -0700 Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4887aF05944 for ; Tue, 8 May 2001 01:07:36 -0700 Received: from sci.monash.edu.au ([130.194.160.238]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #29714) with ESMTP id <01K3BWGZZGZ28WYWQR@vaxh.cc.monash.edu.au> for linux-mips@oss.sgi.com; Tue, 8 May 2001 18:05:23 +1000 Date: Tue, 08 May 2001 17:59:42 +1000 From: Mike Barnes Subject: Re: Linux on a Tektronix XP217C xterm To: Kaj-Michael Lang Cc: linux-mips@oss.sgi.com Reply-to: mike.barnes@sci.monash.edu.au Message-id: <3AF7A76E.A60DA739@sci.monash.edu.au> MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Kaj-Michael Lang wrote: > Any chance of getting linux running on a tektronix x-terminal ? It has > a LR33020 cpu, that I think is a R3000 integrated with some graphics > chip. I've tried searching for documentation for the chip but I didn't > find anything. I was wondering about these beasts the other day - I had one under my desk when this email arrived. Now I've cracked it open, what looks like the CPU is labelled ... LR33120MC-40 MIPS GRAPHXCTLR I'd be nice to get something running on these. I've got about half a dozen of them scattered around the place. Mike. From owner-linux-mips@oss.sgi.com Tue May 8 01:21:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f488LC106369 for linux-mips-outgoing; Tue, 8 May 2001 01:21:12 -0700 Received: from kauha.saunalahti.fi (kauha.saunalahti.fi [195.197.53.227]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f488LAF06366 for ; Tue, 8 May 2001 01:21:10 -0700 Received: from concertina (dyn-3-085.tku.netti.fi [195.16.220.86]) by kauha.saunalahti.fi (8.10.1/8.10.1) with SMTP id f488L5P10473; Tue, 8 May 2001 11:21:05 +0300 (EEST) Message-ID: <001d01c0d798$4303d7a0$56dc10c3@tal.org> From: "Kaj-Michael Lang" To: "Geert Uytterhoeven" Cc: References: Subject: Re: Linux on a Tektronix XP217C xterm Date: Tue, 8 May 2001 11:24:11 +0300 Organization: Tal.Org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > IIRC there's a different separate graphics chip in the 217. I think the 33020 > is not a MIPS, but a RISC chip from LSI Logic. > LR33020/33120: Embedded R3000 for X-terminals; reimplemented core; static design; 25 to 40 MHz; 4-kbyte instruction cache; 1-kbyte data cache; graphics coprocessor with bitblt processor and DMA channel. From owner-linux-mips@oss.sgi.com Tue May 8 01:46:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f488kZ107123 for linux-mips-outgoing; Tue, 8 May 2001 01:46:35 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f488kYF07119 for ; Tue, 8 May 2001 01:46:34 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA12392; Tue, 8 May 2001 01:46:39 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA11395; Tue, 8 May 2001 01:46:36 -0700 (PDT) Message-ID: <001701c0d79b$f9f10980$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Geert Uytterhoeven" , "Kaj-Michael Lang" Cc: References: Subject: Re: Linux on a Tektronix XP217C xterm Date: Tue, 8 May 2001 10:50:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Tue, 8 May 2001, Kaj-Michael Lang wrote: > > Any chance of getting linux running on a tektronix x-terminal ? It has > > a LR33020 cpu, that I think is a R3000 integrated with some graphics > > chip. I've tried searching for documentation for the chip but I didn't > > find anything. > > IIRC there's a different separate graphics chip in the 217. I think the 33020 > is not a MIPS, but a RISC chip from LSI Logic. The 33xx0 family are MIPS-compatible designs that were done in-house at LSI logic. At the level of the user-mode instruction set, they are compatible with MIPS-I/R3000 - indeed, the basic pipeline looks like it was taken directly from the R3000. But the system coprocessor was radically modified and simplified and in particular there is no TLB/MMU. Standard Linux therefore won't fly on it, though some variant of uClinux might. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue May 8 06:04:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48D4RJ14582 for linux-mips-outgoing; Tue, 8 May 2001 06:04:27 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48D4PF14577 for ; Tue, 8 May 2001 06:04:25 -0700 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14x7DA-0005br-00; Tue, 8 May 2001 14:07:32 +0100 Subject: Re: Linux on a Tektronix XP217C xterm To: milang@tal.org (Kaj-Michael Lang) Date: Tue, 8 May 2001 14:07:29 +0100 (BST) Cc: linux-mips@oss.sgi.com In-Reply-To: from "Kaj-Michael Lang" at May 08, 2001 09:56:41 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Any chance of getting linux running on a tektronix x-terminal ? It has > a LR33020 cpu, that I think is a R3000 integrated with some graphics > chip. I've tried searching for documentation for the chip but I didn't > find anything. MMUless pseudo mips embedded CPU. Hardwired TLB's for KSEG etc. Also a few other cute suprises such as multiply being interruptible and the irq handler having to save cpu magic registers before doing another one. Some of the 3com routers I hacked on used variants of these beasties. I suspect its a ucLinux target unless you have one with loadable TLB's From owner-linux-mips@oss.sgi.com Tue May 8 08:19:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48FJdr18043 for linux-mips-outgoing; Tue, 8 May 2001 08:19:39 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48FJbF18039 for ; Tue, 8 May 2001 08:19:38 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 8BBF17D9; Tue, 8 May 2001 17:19:35 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 6A5D4EFFF; Tue, 8 May 2001 17:19:08 +0200 (CEST) Date: Tue, 8 May 2001 17:19:08 +0200 From: Florian Lohoff To: George Gensure Cc: linux-mips@oss.sgi.com Subject: Re: 2.4.3 kernel Message-ID: <20010508171908.B8522@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from werkt@csh.rit.edu on Sun, May 06, 2001 at 12:25:12PM -0400 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, May 06, 2001 at 12:25:12PM -0400, George Gensure wrote: > Can anyone explain to me how the 2.4.3 kernel available on ftp.rfc822.org was > built? I've been working for about a month and a half on getting that to > compile with no success. The only reason I need it is to get input core > support, since linux doesn't like to recognize any device nodes that I create > using mknod. If anyone could shed some light on either of these problems... > the kernel or getting linux to recognize my mouse on (10,1) please contact me. Whats your exact problem ? I made the kernel and i dont think i had greater problems. Everything needed should be in the tar (config etc) except some patches which should be in the cvs by now. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Tue May 8 11:12:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48ICw423961 for linux-mips-outgoing; Tue, 8 May 2001 11:12:58 -0700 Received: from clueserver.org (216-99-213-120.dsl.aracnet.com [216.99.213.120]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48ICuF23956 for ; Tue, 8 May 2001 11:12:57 -0700 Received: by clueserver.org (Postfix, from userid 500) id 6A6466E42; Tue, 8 May 2001 12:21:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clueserver.org (Postfix) with ESMTP id 5AC4A5E86; Tue, 8 May 2001 12:21:53 -0700 (PDT) Date: Tue, 8 May 2001 12:21:53 -0700 (PDT) From: Alan Olsen To: Mike Barnes Cc: Kaj-Michael Lang , linux-mips@oss.sgi.com Subject: Re: Linux on a Tektronix XP217C xterm In-Reply-To: <3AF7A76E.A60DA739@sci.monash.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, Mike Barnes wrote: > Kaj-Michael Lang wrote: > > Any chance of getting linux running on a tektronix x-terminal ? It has > > a LR33020 cpu, that I think is a R3000 integrated with some graphics > > chip. I've tried searching for documentation for the chip but I didn't > > find anything. > > I was wondering about these beasts the other day - I had one under my > desk when this email arrived. > > Now I've cracked it open, what looks like the CPU is labelled ... > > LR33120MC-40 > MIPS GRAPHXCTLR > > I'd be nice to get something running on these. I've got about half a > dozen of them scattered around the place. Good luck. The Tek X-term business was bought by NCD a couple of years back. There is no one left at NCD who remembers how those things work anymore. (Last time I was there they had NO hardware engineers and one software engineer.) Why this occured is a long and Dilbertian story too long to fit in the margin of this message. You are on your own on that one... alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply Alan Olsen | to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." From owner-linux-mips@oss.sgi.com Tue May 8 11:26:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48IQ7C24725 for linux-mips-outgoing; Tue, 8 May 2001 11:26:07 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48IQ2F24719; Tue, 8 May 2001 11:26:03 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 7A5687F3; Tue, 8 May 2001 20:26:01 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5C97EEFFF; Tue, 8 May 2001 20:25:18 +0200 (CEST) Date: Tue, 8 May 2001 20:25:18 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010508202518.A13476@paradigm.rfc822.org> References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010507163210.B2381@bacchus.dhis.org>; from ralf@oss.sgi.com on Mon, May 07, 2001 at 04:32:10PM -0300 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 07, 2001 at 04:32:10PM -0300, Ralf Baechle wrote: > On Sat, May 05, 2001 at 02:47:08PM +0200, Florian Lohoff wrote: > > > the last days/weeks there was a repeated discussion of breaking the binary > > compatibility. I read the whole thread on linux-mips but i didnt get the point > > why this has to happen - If we are repairing a real bug for it. > > > > Could someone please elaborate on whats going on as i feel i missed ~200 mails > > discussion and i dont want to purge the whole debian archive until i know > > what for we actually drop the compatibility. > > We don't. > Could you explain a bit more - I'd like to understand the whole issue. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Tue May 8 12:07:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48J73x26565 for linux-mips-outgoing; Tue, 8 May 2001 12:07:03 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48J72F26562 for ; Tue, 8 May 2001 12:07:02 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f48J72007329; Tue, 8 May 2001 12:07:02 -0700 Message-ID: <3AF843F7.72BC47F0@mvista.com> Date: Tue, 08 May 2001 12:07:35 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: machine types for MIPS in ELF file Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The e_machine field in ELF file standard defines two values for MIPS: 8 - MIPS RS3000 BE 10 - MIPS RS4000 BE Naturally the question is: what about LE binaries? And what about other CPUs? Is there any effort to clean up this thing? All the tools that I know of are using 8, pretty much for all CPUs and both endians. No real harm has been observed, but it causes some anonying "invalid byte order" complains if you do "file" on a MIPS LE binary. Of course, it will also invariably reports "R3000" cpu as well. Jun From owner-linux-mips@oss.sgi.com Tue May 8 12:50:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48Jov528096 for linux-mips-outgoing; Tue, 8 May 2001 12:50:57 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48JotF28092 for ; Tue, 8 May 2001 12:50:56 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f48JmkC01844; Tue, 8 May 2001 16:48:46 -0300 Date: Tue, 8 May 2001 16:48:46 -0300 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: machine types for MIPS in ELF file Message-ID: <20010508164846.A1471@bacchus.dhis.org> References: <3AF843F7.72BC47F0@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF843F7.72BC47F0@mvista.com>; from jsun@mvista.com on Tue, May 08, 2001 at 12:07:35PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 08, 2001 at 12:07:35PM -0700, Jun Sun wrote: > The e_machine field in ELF file standard defines two values for MIPS: > > 8 - MIPS RS3000 BE > 10 - MIPS RS4000 BE > > Naturally the question is: what about LE binaries? And what about other > CPUs? Is there any effort to clean up this thing? > > All the tools that I know of are using 8, pretty much for all CPUs and both > endians. No real harm has been observed, but it causes some anonying "invalid > byte order" complains if you do "file" on a MIPS LE binary. Of course, it > will also invariably reports "R3000" cpu as well. EM_MIPS_RS4_BE was apparently only in use for a short time; EM_MIPS is being used for both byte order. The byteorder is nowadays identified by EI_DATA. Ralf From owner-linux-mips@oss.sgi.com Tue May 8 12:53:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48Jrqq28424 for linux-mips-outgoing; Tue, 8 May 2001 12:53:52 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48JroF28421 for ; Tue, 8 May 2001 12:53:51 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f48JpQ901860; Tue, 8 May 2001 16:51:26 -0300 Date: Tue, 8 May 2001 16:51:26 -0300 From: Ralf Baechle To: Geert Uytterhoeven Cc: Kaj-Michael Lang , linux-mips@oss.sgi.com Subject: Re: Linux on a Tektronix XP217C xterm Message-ID: <20010508165126.B1471@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Geert.Uytterhoeven@sonycom.com on Tue, May 08, 2001 at 10:00:38AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 08, 2001 at 10:00:38AM +0200, Geert Uytterhoeven wrote: > On Tue, 8 May 2001, Kaj-Michael Lang wrote: > > Any chance of getting linux running on a tektronix x-terminal ? It has > > a LR33020 cpu, that I think is a R3000 integrated with some graphics > > chip. I've tried searching for documentation for the chip but I didn't > > find anything. > > IIRC there's a different separate graphics chip in the 217. I think the 33020 > is not a MIPS, but a RISC chip from LSI Logic. Which in turn is a MIPS licensee ... Ralf From owner-linux-mips@oss.sgi.com Tue May 8 12:56:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48Junj28735 for linux-mips-outgoing; Tue, 8 May 2001 12:56:49 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48JiBF27611 for ; Tue, 8 May 2001 12:46:39 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA06088; Tue, 8 May 2001 21:34:23 +0200 (MET DST) Date: Tue, 8 May 2001 21:34:22 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: linux-mips@oss.sgi.com Subject: Re: machine types for MIPS in ELF file In-Reply-To: <3AF843F7.72BC47F0@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, Jun Sun wrote: > The e_machine field in ELF file standard defines two values for MIPS: > > 8 - MIPS RS3000 BE > 10 - MIPS RS4000 BE > > Naturally the question is: what about LE binaries? And what about other > CPUs? Is there any effort to clean up this thing? The latter has been changed to "MIPS RS3000 LE" in the latest ELF spec, AFAIK. The ISA level is further specified in the e_flags field. No idea why they want to keep redundant endianness information in e_machine -- there is an endianness specification at e_ident[5]. Also no idea why they named the CPU RS3000 and not R3000. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue May 8 13:45:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48KjMT30718 for linux-mips-outgoing; Tue, 8 May 2001 13:45:22 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48KjAF30620 for ; Tue, 8 May 2001 13:45:11 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA08120; Tue, 8 May 2001 22:21:56 +0200 (MET DST) Date: Tue, 8 May 2001 22:21:55 +0200 (MET DST) From: "Maciej W. Rozycki" To: linux-kernel@vger.kernel.org cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] 2.4.4: mmap() fails for certain legal requests Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, The mmap() call fails when addr is specified, MAP_FIXED is cleared in flags and no address space can be allocated either at addr or above it. This is a legal request and it should not fail as long as there is space available below addr. Following is a patch that fixes the problem. This is nothing new -- I already submitted a similar patch against 2.4.0-test4 once upon a time. This patch is clean(er), though, and I believe it can be safely applied to the upcoming 2.4.5 release. A simple test case to trigger the current mmap() bad behaviour for 32-bit CPUs is something like: fd = open("/dev/zero", O_RDONLY); p = mmap((void *)0xfffff000, 4096, PROT_READ, MAP_SHARED, fd, 0); With my patch the code does not fail anymore -- p is set to an available address lower than 0xfffff000. The bug was discovered when tracking down the reason of dlopen() failures when called from statically linked binaries on MIPS/Linux. The patch fixes them. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -up --recursive --new-file linux-2.4.4.macro/mm/mmap.c linux-2.4.4/mm/mmap.c --- linux-2.4.4.macro/mm/mmap.c Tue May 1 17:24:25 2001 +++ linux-2.4.4/mm/mmap.c Tue May 1 18:23:25 2001 @@ -219,7 +219,7 @@ unsigned long do_mmap_pgoff(struct file if ((len = PAGE_ALIGN(len)) == 0) return addr; - if (len > TASK_SIZE || addr > TASK_SIZE-len) + if (len > TASK_SIZE) return -EINVAL; /* offset overflow? */ @@ -405,9 +405,15 @@ static inline unsigned long arch_get_unm if (len > TASK_SIZE) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; - addr = PAGE_ALIGN(addr); + + if (addr) { + addr = PAGE_ALIGN(addr); + vma = find_vma(current->mm, addr); + if (TASK_SIZE - len >= addr && + (!vma || addr + len <= vma->vm_start)) + return addr; + } + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) { /* At this point: (!vma || addr < vma->vm_end). */ @@ -425,6 +431,8 @@ extern unsigned long arch_get_unmapped_a unsigned long get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags) { if (flags & MAP_FIXED) { + if (addr > TASK_SIZE - len) + return -EINVAL; if (addr & ~PAGE_MASK) return -EINVAL; return addr; From owner-linux-mips@oss.sgi.com Tue May 8 13:49:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48KnSd31272 for linux-mips-outgoing; Tue, 8 May 2001 13:49:28 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48KnRF31269 for ; Tue, 8 May 2001 13:49:27 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA27455; Tue, 8 May 2001 13:47:57 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.23421.564537.144351@pizda.ninka.net> Date: Tue, 8 May 2001 13:47:57 -0700 (PDT) To: "Maciej W. Rozycki" Cc: linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Maciej W. Rozycki writes: > The bug was discovered when tracking down the reason of dlopen() failures > when called from statically linked binaries on MIPS/Linux. The patch > fixes them. There are several get_unmapped_area() implementations besides the standard one (search for HAVE_ARCH_UNMAPPED_AREA). Please fix them up too. Later, David S. Miller davem@redhat.com From owner-linux-mips@oss.sgi.com Tue May 8 14:19:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48LJdo32535 for linux-mips-outgoing; Tue, 8 May 2001 14:19:39 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48LJaF32531; Tue, 8 May 2001 14:19:36 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f48LJW017350; Tue, 8 May 2001 14:19:32 -0700 Message-ID: <3AF86306.343F53D0@mvista.com> Date: Tue, 08 May 2001 14:20:06 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , macro@ds2.pg.gda.pl CC: linux-mips@oss.sgi.com Subject: Re: machine types for MIPS in ELF file References: <3AF843F7.72BC47F0@mvista.com> <20010508164846.A1471@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Tue, May 08, 2001 at 12:07:35PM -0700, Jun Sun wrote: > > > The e_machine field in ELF file standard defines two values for MIPS: > > > > 8 - MIPS RS3000 BE > > 10 - MIPS RS4000 BE > > > > Naturally the question is: what about LE binaries? And what about other > > CPUs? Is there any effort to clean up this thing? > > > > All the tools that I know of are using 8, pretty much for all CPUs and both > > endians. No real harm has been observed, but it causes some anonying "invalid > > byte order" complains if you do "file" on a MIPS LE binary. Of course, it > > will also invariably reports "R3000" cpu as well. > > EM_MIPS_RS4_BE was apparently only in use for a short time; EM_MIPS is > being used for both byte order. The byteorder is nowadays identified by > EI_DATA. > That makes a lot of sense. BTW, where is the latest ELF spec that says so? Maciej, which spec are you referring to? Jun From owner-linux-mips@oss.sgi.com Tue May 8 14:38:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48LcKY00724 for linux-mips-outgoing; Tue, 8 May 2001 14:38:20 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48Lc5F00719 for ; Tue, 8 May 2001 14:38:15 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA10834; Tue, 8 May 2001 23:32:21 +0200 (MET DST) Date: Tue, 8 May 2001 23:32:21 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "David S. Miller" cc: linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: <15096.23421.564537.144351@pizda.ninka.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, David S. Miller wrote: > There are several get_unmapped_area() implementations besides the > standard one (search for HAVE_ARCH_UNMAPPED_AREA). Please fix > them up too. Yep, I know (ia64 and sparc*). But being lazy enough (and being short on time) I won't do it until I know the idea of the change is accepted. I'm sorry -- I sent previous versions of the patch twice since last Summer with no response at all and doing bits no one is interested in is a waste of time. Thanks for your response, though -- maybe there is someone interested, after all. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue May 8 14:57:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48LvJX01316 for linux-mips-outgoing; Tue, 8 May 2001 14:57:19 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48LvIF01313 for ; Tue, 8 May 2001 14:57:18 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA27905; Tue, 8 May 2001 14:54:48 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.27432.381478.837650@pizda.ninka.net> Date: Tue, 8 May 2001 14:54:48 -0700 (PDT) To: "Maciej W. Rozycki" Cc: linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: References: <15096.23421.564537.144351@pizda.ninka.net> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Czesc, Maciej W. Rozycki writes: > Yep, I know (ia64 and sparc*). But being lazy enough (and being short on > time) I won't do it until I know the idea of the change is accepted. I'm > sorry -- I sent previous versions of the patch twice since last Summer > with no response at all and doing bits no one is interested in is a waste > of time. > > Thanks for your response, though -- maybe there is someone interested, > after all. That's pretty arrogant that cut and pasting a few lines into some architecture specific files and reporting the updated patch is too much to ask. Perhaps reviewing your change is also, too much to ask. Perhaps we are too lazy and short on time to have a look at your change. I don't think it's asking a lot to provide a complete change. I'm sure the MIPS folks know all too well whats it's like when their port is crapped up because someone only made changes to x86 port portions. At least for me on after working on Sparc for some time, I'm adamant about providing complete changes so that this kind of grief is avoided for other port maintainers. In the time you used to compose your response to me, and now to read this email from me, you could have fixed up the patch perhaps 2 or 3 times. Just do it and get it over with ok? Dziekuje. Later, David S. Miller davem@redhat.com From owner-linux-mips@oss.sgi.com Tue May 8 16:00:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48N0ji02902 for linux-mips-outgoing; Tue, 8 May 2001 16:00:45 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48N0iF02898 for ; Tue, 8 May 2001 16:00:44 -0700 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14xGS7-0000r5-00; Tue, 8 May 2001 23:59:35 +0100 Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests To: davem@redhat.com (David S. Miller) Date: Tue, 8 May 2001 23:59:33 +0100 (BST) Cc: macro@ds2.pg.gda.pl (Maciej W. Rozycki), linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com In-Reply-To: <15096.27432.381478.837650@pizda.ninka.net> from "David S. Miller" at May 08, 2001 02:54:48 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > Thanks for your response, though -- maybe there is someone interested, > > after all. > > That's pretty arrogant that cut and pasting a few lines into some > architecture specific files and reporting the updated patch is too > much to ask. And just how is he going to test it ? Considering he was just asking if the concept was reasonable I think you are a little out of order From owner-linux-mips@oss.sgi.com Tue May 8 16:52:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48NqZD04342 for linux-mips-outgoing; Tue, 8 May 2001 16:52:35 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48Np2F04311 for ; Tue, 8 May 2001 16:52:04 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id BAA14988; Wed, 9 May 2001 01:46:35 +0200 (MET DST) Date: Wed, 9 May 2001 01:46:35 +0200 (MET DST) From: "Maciej W. Rozycki" To: "David S. Miller" cc: linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: <15096.27432.381478.837650@pizda.ninka.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, David S. Miller wrote: > That's pretty arrogant that cut and pasting a few lines into some > architecture specific files and reporting the updated patch is too > much to ask. I'm sorry if you find me arrogant -- that certainly was not my intent. I did look at the files and changes are not as trivial as cut and paste. > Perhaps reviewing your change is also, too much to ask. Perhaps > we are too lazy and short on time to have a look at your change. Well, I've been using similar changes since July. I may live with patches forever and be fine. Still this is not the point with free software. It would be malicious if I had a fix and I wouldn't share it. Sooner or later someone would discover the problem again and would waste time to track it down unnecessarily. And again, and again... > I don't think it's asking a lot to provide a complete change. It's not a lot, supposedly, but look at the case from my point of view. It's a bugfix and not a new feature. I've invested a few hours in finding the cause of a weird bug on a MIPS/Linux machine. I am providing a ready solution that works for most architectures with the exception of a few ones I'm not familiar with. Well, it's great I have an opportunity to get better knowledge on these architectures, but I cannot always afford it and I know there are people who already have enough knowledge to be sure bits get written correctly immediately. I never hesitate to do job myself in the areas I am familiar with or when I have enough free time (and I do have, from time to time). I don't have time currently, I am afraid (basically I am now stealing the time I would otherwise spend sleeping for a task that was quite low on my priority list) and I am sure someone familiar with the specific ports would spend less time than I do. Finally I do consider my time equally worth to anyone else's one, so why should I have to spend x units of time, whilst some else would only spend x/2 or x/3 or whatever... Of course I consider this rule working both ways. > I'm sure the MIPS folks know all too well whats it's like when their > port is crapped up because someone only made changes to x86 port > portions. At least for me on after working on Sparc for some time, > I'm adamant about providing complete changes so that this kind of > grief is avoided for other port maintainers. The port gets crapped from time to time, although Ralf is doing great job to keep it fine, so it's more that specific MIPS hosts lag behind the rest of the kernel. Still I consider it the specific maintainer's job to get things synchronized. It just works better this way. > In the time you used to compose your response to me, and now > to read this email from me, you could have fixed up the patch > perhaps 2 or 3 times. Just do it and get it over with ok? I'm not so sure, I'm afraid, especially at this time of the day. Check timestamps of mails if curious... > Dziekuje. Nie za ma co. ;-) A patch follows. Architecture-specific changes are completely untested. I hope I got things right, otherwise I'll consider my time wasted. BTW, I've noticed the "if (flags & MAP_FIXED)" statements in arch_get_unmapped_area() in arch/sparc*/kernel/sys_sparc.c are dead code now, as get_unmapped_area() in mm/mmap.c never calls it if MAP_FIXED is set in flags. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -up --recursive --new-file linux-2.4.4.macro/arch/ia64/kernel/sys_ia64.c linux-2.4.4/arch/ia64/kernel/sys_ia64.c --- linux-2.4.4.macro/arch/ia64/kernel/sys_ia64.c Mon May 7 16:43:50 2001 +++ linux-2.4.4/arch/ia64/kernel/sys_ia64.c Tue May 8 23:25:49 2001 @@ -28,13 +28,22 @@ arch_get_unmapped_area (struct file *fil if (len > RGN_MAP_LIMIT) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; + if (addr) { + if (flags & MAP_SHARED) + addr = COLOR_ALIGN(addr); + else + addr = PAGE_ALIGN(addr); + vmm = find_vma(current->mm, addr); + if (TASK_SIZE - len >= addr && + rgn_offset(addr) + len <= RGN_MAP_LIMIT) && + (!vmm || addr + len <= vmm->vm_start)) + return addr; + } if (flags & MAP_SHARED) - addr = COLOR_ALIGN(addr); + addr = COLOR_ALIGN(TASK_UNMAPPED_BASE); else - addr = PAGE_ALIGN(addr); + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { /* At this point: (!vmm || addr < vmm->vm_end). */ diff -up --recursive --new-file linux-2.4.4.macro/arch/sparc/kernel/sys_sparc.c linux-2.4.4/arch/sparc/kernel/sys_sparc.c --- linux-2.4.4.macro/arch/sparc/kernel/sys_sparc.c Mon May 7 16:22:42 2001 +++ linux-2.4.4/arch/sparc/kernel/sys_sparc.c Tue May 8 22:50:51 2001 @@ -54,17 +54,31 @@ unsigned long arch_get_unmapped_area(str return -ENOMEM; if (ARCH_SUN4C_SUN4 && len > 0x20000000) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; + if (addr) { + if (flags & MAP_SHARED) + addr = COLOR_ALIGN(addr); + else + addr = PAGE_ALIGN(addr); + vmm = find_vma(current->mm, addr); + if (ARCH_SUN4C_SUN4 && addr < 0xe0000000 && + 0x20000000 - len < addr) { + addr = PAGE_OFFSET; + vmm = find_vma(current->mm, PAGE_OFFSET); + } + if (TASK_SIZE - PAGE_SIZE - len >= addr && + (!vmm || addr + len <= vmm->vm_start)) + return addr; + } if (flags & MAP_SHARED) - addr = COLOUR_ALIGN(addr); + addr = COLOR_ALIGN(TASK_UNMAPPED_BASE); else - addr = PAGE_ALIGN(addr); + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { /* At this point: (!vmm || addr < vmm->vm_end). */ - if (ARCH_SUN4C_SUN4 && addr < 0xe0000000 && 0x20000000 - len < addr) { + if (ARCH_SUN4C_SUN4 && addr < 0xe0000000 && + 0x20000000 - len < addr) { addr = PAGE_OFFSET; vmm = find_vma(current->mm, PAGE_OFFSET); } diff -up --recursive --new-file linux-2.4.4.macro/arch/sparc64/kernel/sys_sparc.c linux-2.4.4/arch/sparc64/kernel/sys_sparc.c --- linux-2.4.4.macro/arch/sparc64/kernel/sys_sparc.c Mon May 7 16:44:01 2001 +++ linux-2.4.4/arch/sparc64/kernel/sys_sparc.c Tue May 8 22:30:09 2001 @@ -60,15 +60,27 @@ unsigned long arch_get_unmapped_area(str task_size = 0xf0000000UL; if (len > task_size || len > -PAGE_OFFSET) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; + task_size -= len; + + if (addr) { + if (flags & MAP_SHARED) + addr = COLOR_ALIGN(addr); + else + addr = PAGE_ALIGN(addr); + vmm = find_vma(current->mm, addr); + if (addr < PAGE_OFFSET && -PAGE_OFFSET - len < addr) { + addr = PAGE_OFFSET; + vmm = find_vma(current->mm, PAGE_OFFSET); + } + if (task_size >= addr && + (!vmm || addr + len <= vmm->vm_start)) + return addr; + } if (flags & MAP_SHARED) - addr = COLOUR_ALIGN(addr); + addr = COLOR_ALIGN(TASK_UNMAPPED_BASE); else - addr = PAGE_ALIGN(addr); - - task_size -= len; + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { /* At this point: (!vmm || addr < vmm->vm_end). */ diff -up --recursive --new-file linux-2.4.4.macro/mm/mmap.c linux-2.4.4/mm/mmap.c --- linux-2.4.4.macro/mm/mmap.c Mon May 7 16:44:32 2001 +++ linux-2.4.4/mm/mmap.c Tue May 8 22:16:00 2001 @@ -219,7 +219,7 @@ unsigned long do_mmap_pgoff(struct file if ((len = PAGE_ALIGN(len)) == 0) return addr; - if (len > TASK_SIZE || addr > TASK_SIZE-len) + if (len > TASK_SIZE) return -EINVAL; /* offset overflow? */ @@ -405,9 +405,15 @@ static inline unsigned long arch_get_unm if (len > TASK_SIZE) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; - addr = PAGE_ALIGN(addr); + + if (addr) { + addr = PAGE_ALIGN(addr); + vma = find_vma(current->mm, addr); + if (TASK_SIZE - len >= addr && + (!vma || addr + len <= vma->vm_start)) + return addr; + } + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) { /* At this point: (!vma || addr < vma->vm_end). */ @@ -425,6 +431,8 @@ extern unsigned long arch_get_unmapped_a unsigned long get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags) { if (flags & MAP_FIXED) { + if (addr > TASK_SIZE - len) + return -EINVAL; if (addr & ~PAGE_MASK) return -EINVAL; return addr; From owner-linux-mips@oss.sgi.com Tue May 8 16:59:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48NxJq04686 for linux-mips-outgoing; Tue, 8 May 2001 16:59:19 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48NxJF04683 for ; Tue, 8 May 2001 16:59:19 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA28312; Tue, 8 May 2001 16:59:03 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.34887.893674.220288@pizda.ninka.net> Date: Tue, 8 May 2001 16:59:03 -0700 (PDT) To: Alan Cox Cc: macro@ds2.pg.gda.pl (Maciej W. Rozycki), linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: References: <15096.27432.381478.837650@pizda.ninka.net> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Alan Cox writes: > And just how is he going to test it ? Considering he was just > asking if the concept was reasonable I think you are a little out > of order I can't test every platform when I have to make such changes. But it always serves to show the port maintainer "what" the change was. Yes, I am slightly out of order if the intent is just "does this idea look fine" (which it does btw, I can't find any problems with it). I apologize to Maciej, but I do deplore him to actually do the final bits for the other ports when he makes his final patch submission. Later, David S. Miller davem@redhat.com From owner-linux-mips@oss.sgi.com Tue May 8 17:45:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f490jVK05799 for linux-mips-outgoing; Tue, 8 May 2001 17:45:31 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f490jUF05796 for ; Tue, 8 May 2001 17:45:30 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f490hDt12538; Tue, 8 May 2001 21:43:13 -0300 Date: Tue, 8 May 2001 21:43:13 -0300 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010508214313.A12528@bacchus.dhis.org> References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010508202518.A13476@paradigm.rfc822.org>; from flo@rfc822.org on Tue, May 08, 2001 at 08:25:18PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 08, 2001 at 08:25:18PM +0200, Florian Lohoff wrote: > > > compatibility. I read the whole thread on linux-mips but i didnt get the point > > > why this has to happen - If we are repairing a real bug for it. > > > > > > Could someone please elaborate on whats going on as i feel i missed ~200 mails > > > discussion and i dont want to purge the whole debian archive until i know > > > what for we actually drop the compatibility. > > > > We don't. > > Could you explain a bit more - I'd like to understand the whole issue. The whole point was to switch from our IRIX ELF flavoured binaries to standard ABI ELF. These two variants are close but not identical which for example made modutils missbehave. Ralf From owner-linux-mips@oss.sgi.com Wed May 9 01:00:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4980RK15926 for linux-mips-outgoing; Wed, 9 May 2001 01:00:27 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4980DF15914; Wed, 9 May 2001 01:00:13 -0700 Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA11116; Wed, 9 May 2001 09:59:56 +0200 (MET DST) Received: (from tea@localhost) by ginger.sonytel.be (8.9.0/8.8.6) id JAA08397; Wed, 9 May 2001 09:59:56 +0200 (MET DST) Date: Wed, 9 May 2001 09:59:55 +0200 From: Tom Appermont To: Ralf Baechle Cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010509095955.A8392@sonycom.com> References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010508214313.A12528@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, May 08, 2001 at 09:43:13PM -0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 08, 2001 at 09:43:13PM -0300, Ralf Baechle wrote: > On Tue, May 08, 2001 at 08:25:18PM +0200, Florian Lohoff wrote: > > > > > compatibility. I read the whole thread on linux-mips but i didnt get the point > > > > why this has to happen - If we are repairing a real bug for it. > > > > > > > > Could someone please elaborate on whats going on as i feel i missed ~200 mails > > > > discussion and i dont want to purge the whole debian archive until i know > > > > what for we actually drop the compatibility. > > > > > > We don't. > > > > Could you explain a bit more - I'd like to understand the whole issue. > > The whole point was to switch from our IRIX ELF flavoured binaries to > standard ABI ELF. These two variants are close but not identical which > for example made modutils missbehave. What is the current status on this? The patches for the tools are already integrated in their cvs trees (right?). But I don't think everybody was happy with this in the end, aspecially the people wearing debian hats. Is anybody working on a solution, or are we waiting for the debian people to rebuild all the packages? Tom From owner-linux-mips@oss.sgi.com Wed May 9 02:32:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f499WY218675 for linux-mips-outgoing; Wed, 9 May 2001 02:32:34 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f499WSF18671; Wed, 9 May 2001 02:32:28 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 7515A7D9; Wed, 9 May 2001 11:32:26 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id EF422F38D; Wed, 9 May 2001 10:46:35 +0200 (CEST) Date: Wed, 9 May 2001 10:46:35 +0200 From: Florian Lohoff To: Tom Appermont Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010509104635.D12267@paradigm.rfc822.org> References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010509095955.A8392@sonycom.com>; from tea@sonycom.com on Wed, May 09, 2001 at 09:59:55AM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 09, 2001 at 09:59:55AM +0200, Tom Appermont wrote: > On Tue, May 08, 2001 at 09:43:13PM -0300, Ralf Baechle wrote: > > On Tue, May 08, 2001 at 08:25:18PM +0200, Florian Lohoff wrote: > > > > > > > compatibility. I read the whole thread on linux-mips but i didnt get the point > > > > > why this has to happen - If we are repairing a real bug for it. > > > > > > > > > > Could someone please elaborate on whats going on as i feel i missed ~200 mails > > > > > discussion and i dont want to purge the whole debian archive until i know > > > > > what for we actually drop the compatibility. > > > > > > > > We don't. > > > > > > Could you explain a bit more - I'd like to understand the whole issue. > > > > The whole point was to switch from our IRIX ELF flavoured binaries to > > standard ABI ELF. These two variants are close but not identical which > > for example made modutils missbehave. > > What is the current status on this? The patches for the tools are already > integrated in their cvs trees (right?). But I don't think everybody was > happy with this in the end, aspecially the people wearing debian hats. > Is anybody working on a solution, or are we waiting for the debian people > to rebuild all the packages? As the binary compatibility is not going to break we dont need to rebuild. I wasnt really happy with the answer of ralf as it brought me nothing nearer in the understanding of the whole issue. But asking 3 times to get a fully explanation on where the problem is, what breaks, and how to fix is enough. I'll lean back, continue building .debs and wait for others to fix it. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Wed May 9 04:56:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49BucU21503 for linux-mips-outgoing; Wed, 9 May 2001 04:56:38 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49BubF21500 for ; Wed, 9 May 2001 04:56:37 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id GAA25018; Wed, 9 May 2001 06:51:15 -0500 Message-ID: <3AF93260.A9C63FB3@cotw.com> Date: Wed, 09 May 2001 07:04:48 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19pre17-idepci i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: machine types for MIPS in ELF file References: <3AF843F7.72BC47F0@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > > The e_machine field in ELF file standard defines two values for MIPS: > > 8 - MIPS RS3000 BE > 10 - MIPS RS4000 BE > > Naturally the question is: what about LE binaries? And what about other > CPUs? Is there any effort to clean up this thing? > > All the tools that I know of are using 8, pretty much for all CPUs and both > endians. No real harm has been observed, but it causes some anonying "invalid > byte order" complains if you do "file" on a MIPS LE binary. Of course, it > will also invariably reports "R3000" cpu as well. > This has bothered me as well. I would like to see a few machines added at least something like R5000, R8000, R10000 along with the proper ISA value being stored in the e_flags field. I would be more than happy to help make the changes as it is something that IMHO needs to be fixed. As far as the latest ABI specs go, here are 2 different links for the same documents. Ralf and I went digging for these a few weeks back. http://www.sco.com/partners/developer/devspecs/ http://www.linuxbase.org/spec/refspecs/ -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Wed May 9 05:07:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49C7gD21884 for linux-mips-outgoing; Wed, 9 May 2001 05:07:42 -0700 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49C7eF21881 for ; Wed, 9 May 2001 05:07:40 -0700 Received: from jungo.com ([194.90.113.98]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with ESMTP id PAA13119; Wed, 9 May 2001 15:05:49 +0300 (IDT) Message-ID: <3AF93224.6080304@jungo.com> Date: Wed, 09 May 2001 15:03:48 +0300 From: Michael Shmulevich Organization: Jungo LTD User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8.1) Gecko/20010326 X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk As a side question: does this patch apply to 2.2.x kernel too? While working on ld.so.1-9 port on MIPS I seen there's a try to mmap() some address > 0x80000000 which fails due to the same if(...TASK_SIZE...) mentioned in the patch. Just wondering if this applies to me too :-) Sincerely yours, Michael Shmulevich ______________________________________ Software Developer Jungo - R&D email: michaels@jungo.com web: http://www.jungo.com Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233 Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide) From owner-linux-mips@oss.sgi.com Wed May 9 05:23:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49CNb122319 for linux-mips-outgoing; Wed, 9 May 2001 05:23:37 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49CNWF22312; Wed, 9 May 2001 05:23:32 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id HAA25101; Wed, 9 May 2001 07:22:58 -0500 Message-ID: <3AF934AE.38AB0089@cotw.com> Date: Wed, 09 May 2001 07:14:38 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19pre17-idepci i686) X-Accept-Language: en MIME-Version: 1.0 To: Florian Lohoff CC: Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Florian Lohoff wrote: > > > > The whole point was to switch from our IRIX ELF flavoured binaries to > > > standard ABI ELF. These two variants are close but not identical which > > > for example made modutils missbehave. > > I will expound a bit more. When I made the changes to fix binutils and switch us from the IRIX to ABI ELF flavoured binaries the default target names changed from 'elf[32|64][little|big]mips' to 'elf[32|64]trad[little|big]mips' in binutils. This has the effect of breaking linker scripts but not a whole lot else. These will be the new targets for MIPS/Linux work. Binaries should still run just fine if you compile glibc-2.2.2 with the old or new tools. Future work though should use the 'elf[32|64]trad[little|big]mips' targets. > > What is the current status on this? The patches for the tools are already > > integrated in their cvs trees (right?). But I don't think everybody was > > happy with this in the end, aspecially the people wearing debian hats. > > Is anybody working on a solution, or are we waiting for the debian people > > to rebuild all the packages? > You bet your ass they are in CVS. The Debian MIPS people? That would be Flo and Jason M. I believe. I'm getting ready to start a flame war (well I hope not, but it has potential) on the debian-mips list right after this email. You might want to hop up there and read that if you are interested. > I'll lean back, continue building .debs and wait for others to fix it. > And this is the problem Flo. Hop up to debian-mips and lets talk. -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Wed May 9 05:27:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49CRvJ22595 for linux-mips-outgoing; Wed, 9 May 2001 05:27:57 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49CRoF22590; Wed, 9 May 2001 05:27:50 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 2E2281E24E; Wed, 9 May 2001 14:27:49 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: sjhill@cotw.com Cc: Florian Lohoff , Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> From: Andreas Jaeger Date: 09 May 2001 14:27:39 +0200 In-Reply-To: <3AF934AE.38AB0089@cotw.com> ("Steven J. Hill"'s message of "Wed, 09 May 2001 07:14:38 -0500") Message-ID: Lines: 25 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Steven J. Hill" writes: > Florian Lohoff wrote: > > > > > > The whole point was to switch from our IRIX ELF flavoured binaries to > > > > standard ABI ELF. These two variants are close but not identical which > > > > for example made modutils missbehave. > > > > I will expound a bit more. When I made the changes to fix binutils and switch > us from the IRIX to ABI ELF flavoured binaries the default target names > changed from 'elf[32|64][little|big]mips' to 'elf[32|64]trad[little|big]mips' > in binutils. This has the effect of breaking linker scripts but not a whole > lot else. These will be the new targets for MIPS/Linux work. Binaries should > still run just fine if you compile glibc-2.2.2 with the old or new tools. > Future work though should use the 'elf[32|64]trad[little|big]mips' targets. Ok, I finally understand. Can you send a new patch for glibc with an update for the FAQ? I'll add it this time. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Wed May 9 05:38:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Cc9k23069 for linux-mips-outgoing; Wed, 9 May 2001 05:38:09 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49CbrF23061; Wed, 9 May 2001 05:37:53 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id HAA25247; Wed, 9 May 2001 07:37:38 -0500 Message-ID: <3AF93D3F.5E57070@cotw.com> Date: Wed, 09 May 2001 07:51:11 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19pre17-idepci i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Jaeger CC: Florian Lohoff , Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Andreas Jaeger wrote: > > Ok, I finally understand. Can you send a new patch for glibc with an > update for the FAQ? I'll add it this time. > diff -urN glibc-2.2.3/sysdeps/mips/rtld-ldscript.in glibc-2.2.3-patched/sysdeps/ mips/rtld-ldscript.in --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in Sat Jul 12 18:23:14 1997 +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in Sun Apr 29 22:32:35 2001 @@ -1,4 +1,3 @@ -OUTPUT_FORMAT("@@rtld-oformat@@") OUTPUT_ARCH(@@rtld-arch@@) ENTRY(@@rtld-entry@@) SECTIONS There's the patch. It's not much but it is correct. I have built multiple toolchains and such using this patch. GCC out of CVS both the 3.0 and cutting edge branch work without patches for Linux. And as mentioned earlier, binutils is already fixed. As far as FAQ update...what do you want? -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Wed May 9 05:45:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49CjDD23861 for linux-mips-outgoing; Wed, 9 May 2001 05:45:13 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49Cj9F23857; Wed, 9 May 2001 05:45:09 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A0EC51E261; Wed, 9 May 2001 14:45:08 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: sjhill@cotw.com Cc: Florian Lohoff , Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <3AF93D3F.5E57070@cotw.com> From: Andreas Jaeger Date: 09 May 2001 14:45:07 +0200 In-Reply-To: <3AF93D3F.5E57070@cotw.com> ("Steven J. Hill"'s message of "Wed, 09 May 2001 07:51:11 -0500") Message-ID: Lines: 38 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Steven J. Hill" writes: > Andreas Jaeger wrote: > > > > Ok, I finally understand. Can you send a new patch for glibc with an > > update for the FAQ? I'll add it this time. > > > diff -urN glibc-2.2.3/sysdeps/mips/rtld-ldscript.in glibc-2.2.3-patched/sysdeps/ > mips/rtld-ldscript.in > --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in Sat Jul 12 18:23:14 1997 > +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in Sun Apr 29 22:32:35 2001 > @@ -1,4 +1,3 @@ > -OUTPUT_FORMAT("@@rtld-oformat@@") > OUTPUT_ARCH(@@rtld-arch@@) > ENTRY(@@rtld-entry@@) > SECTIONS > > > There's the patch. It's not much but it is correct. I have built multiple But it's not complete. AFAIK remember you posted a patch with some more changes and HJ even suggested to remove the rtld-ldscript.in file. > toolchains and such using this patch. GCC out of CVS both the 3.0 and > cutting edge branch work without patches for Linux. And as mentioned > earlier, binutils is already fixed. As far as FAQ update...what do you > want? I need an update for the FAQ that explains which binutils version is required for MIPS and I prefer to have a test that checks on MIPS-Linux for the correct emulation in ld. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Wed May 9 05:54:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49CsJi24231 for linux-mips-outgoing; Wed, 9 May 2001 05:54:19 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49CnaF24139 for ; Wed, 9 May 2001 05:49:38 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA07695; Wed, 9 May 2001 14:41:10 +0200 (MET DST) Date: Wed, 9 May 2001 14:41:10 +0200 (MET DST) From: "Maciej W. Rozycki" To: Michael Shmulevich cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: <3AF93224.6080304@jungo.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 9 May 2001, Michael Shmulevich wrote: > As a side question: does this patch apply to 2.2.x kernel too? Feel free to backport it. ;-) One hunk fails for 2.2.19, but it can be applied by hand (note the vma variable is named vmm in 2.2). > While working on ld.so.1-9 port on MIPS I seen there's a try to mmap() > some address > 0x80000000 which fails due to the same > if(...TASK_SIZE...) mentioned in the patch. Yep, that's the exact problem, assuming MAP_FIXED is not set in flags (something is screwed if it is). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 9 06:18:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49DIOY24958 for linux-mips-outgoing; Wed, 9 May 2001 06:18:24 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49DIEF24953; Wed, 9 May 2001 06:18:14 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 573241E26B; Wed, 9 May 2001 15:18:13 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f To: "Maciej W. Rozycki" Cc: "Steven J. Hill" , Florian Lohoff , Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: From: Andreas Jaeger Date: 09 May 2001 15:18:12 +0200 In-Reply-To: ("Maciej W. Rozycki"'s message of "Wed, 9 May 2001 15:07:59 +0200 (MET DST)") Message-ID: Lines: 32 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" writes: > On Wed, 9 May 2001, Steven J. Hill wrote: > > > --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in Sat Jul 12 18:23:14 1997 > > +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in Sun Apr 29 22:32:35 2001 > > @@ -1,4 +1,3 @@ > > -OUTPUT_FORMAT("@@rtld-oformat@@") > > OUTPUT_ARCH(@@rtld-arch@@) > > ENTRY(@@rtld-entry@@) > > SECTIONS > > I guess you want to remove rtld-oformat definitions from > sysdeps/mips/mipsel/rtld-parms and sysdeps/mips/rtld-parms as well. They > become dead code after your change. > > Alternatively define rtld-oformat to elf(32|64)-trad(little|big)mips > where appropriate and require a minimal version of binutils in > sysdeps/unix/sysv/linux/mips/configure.in. The requirement should be > forced anyway and I guess version 2.11.1 may be a good candidate once it's > out. Let's test features and not version numbers if possible. We have HJ Lu's binutils and the official binutils and we should be careful here testing for versions. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Wed May 9 06:21:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49DLSD25244 for linux-mips-outgoing; Wed, 9 May 2001 06:21:28 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49DKQF25200; Wed, 9 May 2001 06:20:54 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA08596; Wed, 9 May 2001 15:07:59 +0200 (MET DST) Date: Wed, 9 May 2001 15:07:59 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Steven J. Hill" cc: Andreas Jaeger , Florian Lohoff , Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? In-Reply-To: <3AF93D3F.5E57070@cotw.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 9 May 2001, Steven J. Hill wrote: > --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in Sat Jul 12 18:23:14 1997 > +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in Sun Apr 29 22:32:35 2001 > @@ -1,4 +1,3 @@ > -OUTPUT_FORMAT("@@rtld-oformat@@") > OUTPUT_ARCH(@@rtld-arch@@) > ENTRY(@@rtld-entry@@) > SECTIONS I guess you want to remove rtld-oformat definitions from sysdeps/mips/mipsel/rtld-parms and sysdeps/mips/rtld-parms as well. They become dead code after your change. Alternatively define rtld-oformat to elf(32|64)-trad(little|big)mips where appropriate and require a minimal version of binutils in sysdeps/unix/sysv/linux/mips/configure.in. The requirement should be forced anyway and I guess version 2.11.1 may be a good candidate once it's out. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 9 06:46:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Dk3W26882 for linux-mips-outgoing; Wed, 9 May 2001 06:46:03 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49DjwF26877; Wed, 9 May 2001 06:45:58 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id IAA25553; Wed, 9 May 2001 08:45:52 -0500 Message-ID: <3AF94D3C.98A4E8@cotw.com> Date: Wed, 09 May 2001 08:59:24 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19pre17-idepci i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Jaeger CC: Florian Lohoff , Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <3AF93D3F.5E57070@cotw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1033 Lines: 30 Andreas Jaeger wrote: > > > There's the patch. It's not much but it is correct. I have built multiple > > But it's not complete. AFAIK remember you posted a patch with some > more changes and HJ even suggested to remove the rtld-ldscript.in file. > I had this discussion with Ralf. He had reasons to not remove this file altogether. Perhaps some input from him would be prudent. Ralf?! > I need an update for the FAQ that explains which binutils version is > required for MIPS and I prefer to have a test that checks on > MIPS-Linux for the correct emulation in ld. > As far as the versions for binutils: HJLu binutils-2.11.90.0.5 or greater CVS binutils binutils 2.11.1? (I'm not sure what the next release number is) For the correct ld emulation, I assume you mean make changes in glibc to check for the proper target 'elf[32|64]trad[little|big]mips'? -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Wed May 9 06:49:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Dnlr27159 for linux-mips-outgoing; Wed, 9 May 2001 06:49:47 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49DniF27155; Wed, 9 May 2001 06:49:44 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 6A1D31E267; Wed, 9 May 2001 15:49:43 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: sjhill@cotw.com Cc: Florian Lohoff , Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <3AF93D3F.5E57070@cotw.com> <3AF94D3C.98A4E8@cotw.com> From: Andreas Jaeger Date: 09 May 2001 15:49:43 +0200 In-Reply-To: <3AF94D3C.98A4E8@cotw.com> ("Steven J. Hill"'s message of "Wed, 09 May 2001 08:59:24 -0500") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1151 Lines: 35 "Steven J. Hill" writes: > Andreas Jaeger wrote: > > > > > There's the patch. It's not much but it is correct. I have built multiple > > > > But it's not complete. AFAIK remember you posted a patch with some > > more changes and HJ even suggested to remove the rtld-ldscript.in file. > > > I had this discussion with Ralf. He had reasons to not remove this > file altogether. Perhaps some input from him would be prudent. Ralf?! So the one-liner you mailed should be all that has to be added? > > I need an update for the FAQ that explains which binutils version is > > required for MIPS and I prefer to have a test that checks on > > MIPS-Linux for the correct emulation in ld. > > > As far as the versions for binutils: > > HJLu binutils-2.11.90.0.5 or greater > CVS binutils > binutils 2.11.1? (I'm not sure what the next release number is) > > For the correct ld emulation, I assume you mean make changes in glibc > to check for the proper target 'elf[32|64]trad[little|big]mips'? That's what I mean, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Wed May 9 06:53:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49DrPM27436 for linux-mips-outgoing; Wed, 9 May 2001 06:53:25 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49DrPF27433 for ; Wed, 9 May 2001 06:53:25 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id IAA25596; Wed, 9 May 2001 08:53:22 -0500 Message-ID: <3AF94EFE.88B7B1BD@cotw.com> Date: Wed, 09 May 2001 09:06:54 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19pre17-idepci i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Jaeger CC: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <3AF93D3F.5E57070@cotw.com> <3AF94D3C.98A4E8@cotw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 698 Lines: 23 Andreas Jaeger wrote: > > So the one-liner you mailed should be all that has to be added? > Yes and.... > > For the correct ld emulation, I assume you mean make changes in glibc > > to check for the proper target 'elf[32|64]trad[little|big]mips'? > > That's what I mean, > And these changes. If you want to commit the one-liner fine...but I will need some time today to make the fix to glibc to check for the proper emulation target. You can either wait and I can include the one-liner with the emulation check patch or commit it. -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Wed May 9 07:05:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49E5gp27827 for linux-mips-outgoing; Wed, 9 May 2001 07:05:42 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49E5EF27817 for ; Wed, 9 May 2001 07:05:15 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA10219; Wed, 9 May 2001 15:54:33 +0200 (MET DST) Date: Wed, 9 May 2001 15:54:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Steven J. Hill" cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: machine types for MIPS in ELF file In-Reply-To: <3AF93260.A9C63FB3@cotw.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 480 Lines: 13 On Wed, 9 May 2001, Steven J. Hill wrote: > http://www.sco.com/partners/developer/devspecs/ Thanks for the reference -- I've been able to locate new draft versions up to Apr 24, 2001 at 'http://www.sco.com/developer/gabi/'. I wonder why I haven't noticed them before... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 9 07:15:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49EFAc28716 for linux-mips-outgoing; Wed, 9 May 2001 07:15:10 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49EF8F28713 for ; Wed, 9 May 2001 07:15:08 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id F04A01E275; Wed, 9 May 2001 16:15:07 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f To: sjhill@cotw.com Cc: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <3AF93D3F.5E57070@cotw.com> <3AF94D3C.98A4E8@cotw.com> <3AF94EFE.88B7B1BD@cotw.com> From: Andreas Jaeger Date: 09 May 2001 16:15:06 +0200 In-Reply-To: <3AF94EFE.88B7B1BD@cotw.com> ("Steven J. Hill"'s message of "Wed, 09 May 2001 09:06:54 -0500") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 736 Lines: 25 "Steven J. Hill" writes: > Andreas Jaeger wrote: > > > > So the one-liner you mailed should be all that has to be added? > > > Yes and.... > > > > For the correct ld emulation, I assume you mean make changes in glibc > > > to check for the proper target 'elf[32|64]trad[little|big]mips'? > > > > That's what I mean, > > > And these changes. If you want to commit the one-liner fine...but I will > need some time today to make the fix to glibc to check for the proper > emulation target. You can either wait and I can include the one-liner > with the emulation check patch or commit it. I prefer to wait, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Wed May 9 07:20:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49EKt429096 for linux-mips-outgoing; Wed, 9 May 2001 07:20:55 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49EKWF29090; Wed, 9 May 2001 07:20:33 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA09466; Wed, 9 May 2001 15:37:05 +0200 (MET DST) Date: Wed, 9 May 2001 15:37:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: Andreas Jaeger cc: "Steven J. Hill" , Florian Lohoff , Tom Appermont , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1300 Lines: 29 On 9 May 2001, Andreas Jaeger wrote: > > Alternatively define rtld-oformat to elf(32|64)-trad(little|big)mips > > where appropriate and require a minimal version of binutils in > > sysdeps/unix/sysv/linux/mips/configure.in. The requirement should be > > forced anyway and I guess version 2.11.1 may be a good candidate once it's > > out. > > Let's test features and not version numbers if possible. We have HJ > Lu's binutils and the official binutils and we should be careful here > testing for versions. You are right wrt elf(32|64)-trad(little|big)mips, indeed. Still released binutils before 2.11 have troubles with versioning and other bits on MIPS and that's tough to test for. So we should really force users to make use of a recent enough version of binutils. By choosing 2.11.1 as an absolute minimum we could supposedly eliminate a test for elf(32|64)-trad(little|big)mips, but an additional test won't hurt for sure. As to H.J.Lu's binutils I see no problem. He consciously chose an unambiguous versioning style, so we may have distinct rules for FSF and H.J.Lu's binutils. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 9 09:55:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Gtlc00913 for linux-mips-outgoing; Wed, 9 May 2001 09:55:47 -0700 Received: from drawbridge3.simpletech.com ([208.178.183.8]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49GtjF00910 for ; Wed, 9 May 2001 09:55:45 -0700 Received: from sti-sun4.simpletech.com (sti-sun4.simpletech.com [172.16.0.66]) by drawbridge3.simpletech.com (8.9.3+Sun/8.9.1) with ESMTP id JAA14237 for ; Wed, 9 May 2001 09:54:14 -0700 (PDT) Received: from neweng.simpletech.com ([172.16.2.165]) by sti-sun4.simpletech.com (8.9.3+Sun/8.9.1) with ESMTP id KAA27058 for ; Wed, 9 May 2001 10:03:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010509095019.00a90830@sti-sun4> X-Sender: tnguyen@sti-sun4 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 May 2001 09:55:34 -0700 To: linux-mips@oss.sgi.com From: Tim Nguyen Subject: MIPS 5Kc Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 607 Lines: 20 Hello all, Does anybody have any comments concerning the Alta board with a MIPS 5Kc running Linux. I hear that Linux modules aren't fully supported in their reference 2.2.12 kernel. Are there any other known issues with that kernel -- how about the 2.4.1 kernel? Any help will be greatly appreciated. Regards, Tim Nguyen ****************************************************** Tim Nguyen Sr. Software Engineer SimpleTech 3001 Daimler Street Santa Ana, CA 92705 PH: 949-476-1180 x8838 FX: 949-851-2398 tnguyen@simpletech.com www.simpletech.com ****************************************************** From owner-linux-mips@oss.sgi.com Wed May 9 10:34:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49HYhX01884 for linux-mips-outgoing; Wed, 9 May 2001 10:34:43 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49HYgF01881 for ; Wed, 9 May 2001 10:34:42 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f49HYg030874; Wed, 9 May 2001 10:34:42 -0700 Message-ID: <3AF97FD0.7F382E49@mvista.com> Date: Wed, 09 May 2001 10:35:12 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: lift the ioport_resource limit ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 778 Lines: 22 Currently IO_SPACE_LIMIT is 0xffff, which is probably borrowed from the legacy i386 code. Let us remove that limit, so that each machine does not have to laboriously reset it. BTW, a prudent machine port should probably always reset it to a more sane range - in any case having 0xffff default value does not make much sense. Jun diff -Nru linux/include/asm-mips/io.h.orig linux/include/asm-mips/io.h --- linux/include/asm-mips/io.h.orig Fri Feb 9 16:43:15 2001 +++ linux/include/asm-mips/io.h Wed May 9 10:26:44 2001 @@ -436,7 +436,7 @@ __inslc((port),(addr),(count)) : \ __insl((port),(addr),(count))) -#define IO_SPACE_LIMIT 0xffff +#define IO_SPACE_LIMIT 0xffffffff /* * The caches on some architectures aren't dma-coherent and have need to From owner-linux-mips@oss.sgi.com Wed May 9 10:36:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Ha1a02084 for linux-mips-outgoing; Wed, 9 May 2001 10:36:01 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49Ha1F02081 for ; Wed, 9 May 2001 10:36:01 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f49HZx030950; Wed, 9 May 2001 10:35:59 -0700 Message-ID: <3AF97F6F.1A8A50E4@mvista.com> Date: Wed, 09 May 2001 10:33:35 -0700 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, bg MIME-Version: 1.0 To: Tim Nguyen CC: linux-mips@oss.sgi.com Subject: Re: MIPS 5Kc References: <4.3.2.7.2.20010509095019.00a90830@sti-sun4> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 598 Lines: 15 Tim Nguyen wrote: > > Hello all, > > Does anybody have any comments concerning the Alta board with a MIPS 5Kc > running Linux. I hear that Linux modules aren't fully supported in their > reference 2.2.12 kernel. Are there any other known issues with that kernel > -- how about the 2.4.1 kernel? Any help will be greatly appreciated. You are probably referring to the "Malta" board from MIPS Tech. The 2.4.2 kernel runs on that board so I would suggest using that. We've tested and support the Malta board with a 4kc part, but running it with a 5kc part shouldn't be much of an issue. Pete From owner-linux-mips@oss.sgi.com Wed May 9 11:28:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49ISBO03972 for linux-mips-outgoing; Wed, 9 May 2001 11:28:11 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IS7F03962 for ; Wed, 9 May 2001 11:28:08 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f492eaL01318; Tue, 8 May 2001 23:40:36 -0300 Date: Tue, 8 May 2001 23:40:36 -0300 From: Ralf Baechle To: Shay Deloya Cc: linux-mips@oss.sgi.com Subject: Re: insmod problems Message-ID: <20010508234036.A1216@bacchus.dhis.org> References: <01050619134301.01140@athena.home.krftech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01050619134301.01140@athena.home.krftech.com>; from shay@jungo.com on Sun, May 06, 2001 at 07:13:43PM +0300 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 932 Lines: 22 On Sun, May 06, 2001 at 07:13:43PM +0300, Shay Deloya wrote: > I have an old problem came up again and the old solution aren't helping. > I'm using busybox version 0.50 and with kernel 2.2 , and inserting > some modules ,especially those with DEBUG macroes e.g: > #define DEBUG_HIGH(args...) {if (debug_level >= HIGH) printk(args);} > causes the message : > Relocation overflow of type 4 for > > and insmod fails. > > I'm compiling the modules with -mlong-calls and still getting this message. > > Is it insmod knowen bugs that the relocation is done in bad way or > a linker/compiler bug. I'm using compiler: egcs ver 1.0.3a > I'm checking this problem at the moment and looking for insmod bug. You'll have to upgrade to very current binutils which for mips*-linux targets default to elf32-trad{big,little}mips, not IRIX ELF format. Also it seems your modutils are a bit rotten, get the latest from ftp.kernel.org. Ralf From owner-linux-mips@oss.sgi.com Wed May 9 11:27:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49IRlL03922 for linux-mips-outgoing; Wed, 9 May 2001 11:27:47 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IRfF03906 for ; Wed, 9 May 2001 11:27:43 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f49I9Yu02151; Wed, 9 May 2001 15:09:34 -0300 Date: Wed, 9 May 2001 15:09:34 -0300 From: Ralf Baechle To: Andreas Jaeger Cc: "Maciej W. Rozycki" , "Steven J. Hill" , Florian Lohoff , Tom Appermont , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010509150934.B2073@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aj@suse.de on Wed, May 09, 2001 at 03:18:12PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1665 Lines: 40 On Wed, May 09, 2001 at 03:18:12PM +0200, Andreas Jaeger wrote: > To: "Maciej W. Rozycki" > Cc: "Steven J. Hill" , Florian Lohoff , > Tom Appermont , Ralf Baechle , > linux-mips@oss.sgi.com > Subject: Re: Binary compatibility break understood ? > From: Andreas Jaeger > Date: 09 May 2001 15:18:12 +0200 > > "Maciej W. Rozycki" writes: > > > On Wed, 9 May 2001, Steven J. Hill wrote: > > > > > --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in Sat Jul 12 18:23:14 1997 > > > +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in Sun Apr 29 22:32:35 2001 > > > @@ -1,4 +1,3 @@ > > > -OUTPUT_FORMAT("@@rtld-oformat@@") > > > OUTPUT_ARCH(@@rtld-arch@@) > > > ENTRY(@@rtld-entry@@) > > > SECTIONS > > > > I guess you want to remove rtld-oformat definitions from > > sysdeps/mips/mipsel/rtld-parms and sysdeps/mips/rtld-parms as well. They > > become dead code after your change. > > > > Alternatively define rtld-oformat to elf(32|64)-trad(little|big)mips > > where appropriate and require a minimal version of binutils in > > sysdeps/unix/sysv/linux/mips/configure.in. The requirement should be > > forced anyway and I guess version 2.11.1 may be a good candidate once it's > > out. > > Let's test features and not version numbers if possible. We have HJ > Lu's binutils and the official binutils and we should be careful here > testing for versions. It's only modutils which for correct functionality depends on the trad- format, so I don't see any real reason for raising version requirements for libc. Ralf From owner-linux-mips@oss.sgi.com Wed May 9 12:01:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49J1GD05399 for linux-mips-outgoing; Wed, 9 May 2001 12:01:16 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IxWF05355; Wed, 9 May 2001 11:59:33 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA23229; Wed, 9 May 2001 20:59:35 +0200 (MET DST) Date: Wed, 9 May 2001 20:59:34 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: Andreas Jaeger , "Steven J. Hill" , Florian Lohoff , Tom Appermont , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? In-Reply-To: <20010509150934.B2073@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 720 Lines: 19 On Wed, 9 May 2001, Ralf Baechle wrote: > It's only modutils which for correct functionality depends on the trad- > format, so I don't see any real reason for raising version requirements > for libc. That would be needed if elf(32|64)-trad(little|big)mips was specified explicitly as rtld-oformat in sysdeps/mips/mipsel/rtld-parms and sysdeps/mips/rtld-parms. Note that libc doesn't require any version of binutils at all now. This is probably bad as using pre-2.11 versions of binutils may yield weird results. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 9 12:04:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49J47d05667 for linux-mips-outgoing; Wed, 9 May 2001 12:04:07 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49J43F05663; Wed, 9 May 2001 12:04:03 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id OAA27355; Wed, 9 May 2001 14:04:02 -0500 Message-ID: <3AF997CE.E2885B9@cotw.com> Date: Wed, 09 May 2001 14:17:34 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19pre17-idepci i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Andreas Jaeger , "Maciej W. Rozycki" , Florian Lohoff , Tom Appermont , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? References: <20010509150934.B2073@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 736 Lines: 20 Ralf Baechle wrote: > > It's only modutils which for correct functionality depends on the trad- > format, so I don't see any real reason for raising version requirements > for libc. > I can see your point...but...if we are trying fix the MIPS/Linux target from this point forward we should at least make people aware of what is going on. I propose spitting out a warning message when 'configure' is ran that if an older version of binutils/ld is found, then we warn the user that they may be unable to correctly use Linux kernel features or something like that. Comments? -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Wed May 9 12:19:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49JJed06367 for linux-mips-outgoing; Wed, 9 May 2001 12:19:40 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49JJZF06362 for ; Wed, 9 May 2001 12:19:36 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f49JGsF02554; Wed, 9 May 2001 16:16:54 -0300 Date: Wed, 9 May 2001 16:16:54 -0300 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Andreas Jaeger , "Steven J. Hill" , Florian Lohoff , Tom Appermont , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010509161654.A2466@bacchus.dhis.org> References: <20010509150934.B2073@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, May 09, 2001 at 08:59:34PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 661 Lines: 18 On Wed, May 09, 2001 at 08:59:34PM +0200, Maciej W. Rozycki wrote: > > format, so I don't see any real reason for raising version requirements > > for libc. > > That would be needed if elf(32|64)-trad(little|big)mips was specified > explicitly as rtld-oformat in sysdeps/mips/mipsel/rtld-parms and > sysdeps/mips/rtld-parms. > > Note that libc doesn't require any version of binutils at all now. > This is probably bad as using pre-2.11 versions of binutils may yield > weird results. Seems like only certain version are affected; the more or less randomly choosen one I use for the RH 7 port seems to work quite well so far. What bug is that? Ralf From owner-linux-mips@oss.sgi.com Wed May 9 12:27:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49JR2P06791 for linux-mips-outgoing; Wed, 9 May 2001 12:27:02 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49JR0F06788 for ; Wed, 9 May 2001 12:27:00 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f49JOKW02599; Wed, 9 May 2001 16:24:20 -0300 Date: Wed, 9 May 2001 16:24:20 -0300 From: Ralf Baechle To: "Steven J. Hill" Cc: Andreas Jaeger , "Maciej W. Rozycki" , Florian Lohoff , Tom Appermont , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010509162420.B2466@bacchus.dhis.org> References: <20010509150934.B2073@bacchus.dhis.org> <3AF997CE.E2885B9@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF997CE.E2885B9@cotw.com>; from sjhill@cotw.com on Wed, May 09, 2001 at 02:17:34PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 750 Lines: 17 On Wed, May 09, 2001 at 02:17:34PM -0500, Steven J. Hill wrote: > > It's only modutils which for correct functionality depends on the trad- > > format, so I don't see any real reason for raising version requirements > > for libc. > > > I can see your point...but...if we are trying fix the MIPS/Linux target > from this point forward we should at least make people aware of what > is going on. I propose spitting out a warning message when 'configure' > is ran that if an older version of binutils/ld is found, then we warn > the user that they may be unable to correctly use Linux kernel features > or something like that. Comments? These binutils break the kernel compilations, so we should check them as part of kernel module compiles. Ralf From owner-linux-mips@oss.sgi.com Wed May 9 12:28:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49JSXT07028 for linux-mips-outgoing; Wed, 9 May 2001 12:28:34 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49JSVF07024 for ; Wed, 9 May 2001 12:28:32 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f49JQ8U02616; Wed, 9 May 2001 16:26:08 -0300 Date: Wed, 9 May 2001 16:26:08 -0300 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: lift the ioport_resource limit ... Message-ID: <20010509162608.C2466@bacchus.dhis.org> References: <3AF97FD0.7F382E49@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF97FD0.7F382E49@mvista.com>; from jsun@mvista.com on Wed, May 09, 2001 at 10:35:12AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 257 Lines: 9 On Wed, May 09, 2001 at 10:35:12AM -0700, Jun Sun wrote: > Currently IO_SPACE_LIMIT is 0xffff, which is probably borrowed from the legacy > i386 code. Let us remove that limit, so that each machine does not have to > laboriously reset it. ISA? Ralf From owner-linux-mips@oss.sgi.com Wed May 9 12:52:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Jq5T07774 for linux-mips-outgoing; Wed, 9 May 2001 12:52:05 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49JgpF07675; Wed, 9 May 2001 12:42:52 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA25097; Wed, 9 May 2001 21:43:16 +0200 (MET DST) Date: Wed, 9 May 2001 21:43:16 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Andreas Jaeger , "Steven J. Hill" , Florian Lohoff , Tom Appermont , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? In-Reply-To: <20010509161654.A2466@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 917 Lines: 21 On Wed, 9 May 2001, Ralf Baechle wrote: > > Note that libc doesn't require any version of binutils at all now. > > This is probably bad as using pre-2.11 versions of binutils may yield > > weird results. > > Seems like only certain version are affected; the more or less randomly > choosen one I use for the RH 7 port seems to work quite well so far. What > bug is that? Do you state you are able to build glibc 2.2 for MIPS/Linux using binutils 2.9 or 2.8 or earlier??? Even 2.10 (2.10.1) doesn't work as released, AFAIK, mostly due to unfinished versioning support for MIPS. There are other, less significant problems as well, IIRC. Relevant patches got applied in the 2.10.90 development cycle, AFAIK. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 9 14:06:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49L6XJ09979 for linux-mips-outgoing; Wed, 9 May 2001 14:06:33 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49L6UF09971; Wed, 9 May 2001 14:06:30 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f49L6T014798; Wed, 9 May 2001 14:06:29 -0700 Message-ID: <3AF9B173.5E13AD2@mvista.com> Date: Wed, 09 May 2001 14:06:59 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: lift the ioport_resource limit ... References: <3AF97FD0.7F382E49@mvista.com> <20010509162608.C2466@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 595 Lines: 27 Ralf Baechle wrote: > > On Wed, May 09, 2001 at 10:35:12AM -0700, Jun Sun wrote: > > > Currently IO_SPACE_LIMIT is 0xffff, which is probably borrowed from the legacy > > i386 code. Let us remove that limit, so that each machine does not have to > > laboriously reset it. > > ISA? > > Ralf ISA bus? The PCI IO space essentially extends the ISA bus, which effectively removes the 0xffff limits. If you are really paranoid, we can do something like this: #if defined(CONFIG_ISA) && !defined(CONFIG_PCI) #define IO_SPACE_LIMIT 0xffff #else #define IO_SPACE_LIMIT 0xffffffff #endif Jun From owner-linux-mips@oss.sgi.com Wed May 9 19:11:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A2Bdq17574 for linux-mips-outgoing; Wed, 9 May 2001 19:11:39 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A2BYF17570 for ; Wed, 9 May 2001 19:11:36 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4A28lf02466; Wed, 9 May 2001 23:08:47 -0300 Date: Wed, 9 May 2001 23:08:47 -0300 From: Ralf Baechle To: Jun Sun Cc: macro@ds2.pg.gda.pl, linux-mips@oss.sgi.com Subject: Re: machine types for MIPS in ELF file Message-ID: <20010509230847.A2456@bacchus.dhis.org> References: <3AF843F7.72BC47F0@mvista.com> <20010508164846.A1471@bacchus.dhis.org> <3AF86306.343F53D0@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF86306.343F53D0@mvista.com>; from jsun@mvista.com on Tue, May 08, 2001 at 02:20:06PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 651 Lines: 18 On Tue, May 08, 2001 at 02:20:06PM -0700, Jun Sun wrote: > > EM_MIPS_RS4_BE was apparently only in use for a short time; EM_MIPS is > > being used for both byte order. The byteorder is nowadays identified by > > EI_DATA. > > > > That makes a lot of sense. > > BTW, where is the latest ELF spec that says so? Maciej, which spec are you > referring to? I checked with the keepers of the ABI - EM_MIPS_RS4_BE was never registered and EM_MIPS_RS3_LE was already registered in '92. Anyway, my statement stays. I've never seen object files using architecture number 10 nor EM_MIPS_RS3_LE used in any source except the constant definitions. Ralf From owner-linux-mips@oss.sgi.com Wed May 9 19:15:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A2Frd17880 for linux-mips-outgoing; Wed, 9 May 2001 19:15:53 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A2FkF17877 for ; Wed, 9 May 2001 19:15:48 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4A2BDv02481; Wed, 9 May 2001 23:11:13 -0300 Date: Wed, 9 May 2001 23:11:13 -0300 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Andreas Jaeger , "Steven J. Hill" , Florian Lohoff , Tom Appermont , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010509231112.B2456@bacchus.dhis.org> References: <20010509161654.A2466@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, May 09, 2001 at 09:43:16PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 719 Lines: 16 On Wed, May 09, 2001 at 09:43:16PM +0200, Maciej W. Rozycki wrote: > > Seems like only certain version are affected; the more or less randomly > > choosen one I use for the RH 7 port seems to work quite well so far. What > > bug is that? > > Do you state you are able to build glibc 2.2 for MIPS/Linux using > binutils 2.9 or 2.8 or earlier??? Even 2.10 (2.10.1) doesn't work as > released, AFAIK, mostly due to unfinished versioning support for MIPS. > There are other, less significant problems as well, IIRC. Relevant > patches got applied in the 2.10.90 development cycle, AFAIK. Sorry, I wasn't thinking that somebody might consider using such pre-historic versions but unfortunately you're right. Ralf From owner-linux-mips@oss.sgi.com Wed May 9 22:55:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A5tDI21988 for linux-mips-outgoing; Wed, 9 May 2001 22:55:13 -0700 Received: from web11902.mail.yahoo.com (web11902.mail.yahoo.com [216.136.172.186]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4A5tCF21985 for ; Wed, 9 May 2001 22:55:12 -0700 Message-ID: <20010510055512.96321.qmail@web11902.mail.yahoo.com> Received: from [209.243.184.191] by web11902.mail.yahoo.com; Wed, 09 May 2001 22:55:12 PDT Date: Wed, 9 May 2001 22:55:12 -0700 (PDT) From: Wayne Gowcher Subject: Configuration of PCI Video card on a BIOS-less board To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1099 Lines: 36 Dear All, I was wondering if anyone has any experience in configuring the PCI registers in a PCI Video Card on a MIPS board that has no BIOS like in a PC. At the moment when I have some "home grown" PCI probing routines based on my best interpretation of the PCI spec. But it's not working. I can probe the Base Address Register successfully, determine the cards memory requirement and that it is memory rather than mapped IO. But when I try to write the address I have allocated to the PCI card ( eg 0xC000 0000 ) the address will not latch in the base address register. The card is designed for x86 PCs and when the PC bios configures the card, the base address register has the value 0xF200 0000. Any comments from anybody with any insight into what is happening here / or how I might fix my probelm, would be greatly appreciated. Does anyone know of any code that carries out PCI probing similar to that found on x86 PC's ? TIA Wayne __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-linux-mips@oss.sgi.com Wed May 9 23:02:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A62SS22364 for linux-mips-outgoing; Wed, 9 May 2001 23:02:28 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A62RF22361 for ; Wed, 9 May 2001 23:02:27 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 684FCF1A9; Wed, 9 May 2001 23:01:24 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 3D2291F42A; Wed, 9 May 2001 23:01:54 -0700 (PDT) Date: Wed, 9 May 2001 23:01:54 -0700 From: Keith M Wesolowski To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board Message-ID: <20010509230154.E15089@foobazco.org> References: <20010510055512.96321.qmail@web11902.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010510055512.96321.qmail@web11902.mail.yahoo.com>; from wgowcher@yahoo.com on Wed, May 09, 2001 at 10:55:12PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 908 Lines: 23 On Wed, May 09, 2001 at 10:55:12PM -0700, Wayne Gowcher wrote: > I can probe the Base Address Register successfully, > determine the cards memory requirement and that it is > memory rather than mapped IO. But when I try to write > the address I have allocated to the PCI card ( eg > 0xC000 0000 ) the address will not latch in the base > address register. Is that a valid bus address on your system? > Does anyone know of any code that carries out PCI > probing similar to that found on x86 PC's ? Look in drivers/pci - that can scan the bus and such - it's generic code used on many architectures. Many systems lack "bios" and work fine in linux. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Wed May 9 23:09:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A694g22700 for linux-mips-outgoing; Wed, 9 May 2001 23:09:04 -0700 Received: from yes.home.krftech.com ([194.90.113.98]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A68xF22697 for ; Wed, 9 May 2001 23:08:59 -0700 Received: from athena.home.krftech.com (athena.home.krftech.com [192.168.71.19]) by yes.home.krftech.com (8.8.7/8.8.7) with SMTP id JAA25052 for ; Thu, 10 May 2001 09:15:59 +0300 Content-Type: Multipart/Mixed; charset="iso-8859-1"; boundary="------------Boundary-00=_XTV34PRUXRABB12KU3Q8" From: Shay Deloya Reply-To: shay@jungo.com Organization: Jungo Corp. To: linux-mips@oss.sgi.com Subject: No bss cause strange values in insmod and ELF Date: Thu, 10 May 2001 09:10:45 +0300 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01051009104509.01140@athena.home.krftech.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 29058 Lines: 425 --------------Boundary-00=_XTV34PRUXRABB12KU3Q8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit ---------- Forwarded Message ---------- Subject: no bss cause strange values in insmod and ELF Date: Wed, 9 May 2001 09:47:05 +0300 From: Shay Deloya To: linux-mips@oss.sgi.com Continuing my previous problem... I have created a module with no bss , and compiled it with kernel 2.2. Comparing this module with same code that has bss and acts OK. Inserting the module with modutiles 2.2.2/ busybox insmod causes a relocation overflow message , the reasons are: 1.in function obj_relocate: corrupted intsym->secidx value (not the needed index in the ELF) for some .text segments, other segments get their index value OK. the ELF file seems to be OK. 2. in function arch_apply_relocation: the wrong index (secidx=1006a1e8) cause R_MIPS_26 symbols (jump commands) to have the value of obj_reloc_overflow and then causes relocation overflow. Does anyone knows why same module that has a variable in bss acts fine and the one without bss causes Relocation overflow in MIPS ? (in x86 there is no problem). Searching the code I see there is no initialization of the secidx , is it a problem of wrong reading of ELF files by insmod ? Attached the two ELF files , and obj_relocate values. Thanks, Shay Deloya ______________________________________ Software Developer Jungo - R&D email: shay@jungo.com web: http://www.jungo.com Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 221 Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide) ------------------------------------------------------- -- Shay Deloya ______________________________________ Software Developer Jungo - R&D email: shayd@jungo.com web: http://www.jungo.com Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 221 Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide) --------------Boundary-00=_XTV34PRUXRABB12KU3Q8 Content-Type: text/plain; charset="iso-8859-1"; name="elf.no_bss" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="elf.no_bss" RUxGIEhlYWRlcjoKICBNYWdpYzogICA3ZiA0NSA0YyA0NiAwMSAwMiAwMSAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAKICBDbGFzczogICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVMRjMy CiAgRGF0YTogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyJ3MgY29tcGxlbWVudCwgYmln IGVuZGlhbgogIFZlcnNpb246ICAgICAgICAgICAgICAgICAgICAgICAgICAgMSAoY3VycmVudCkK ICBPUy9BQkk6ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVOSVggLSBTeXN0ZW0gVgogIEFC SSBWZXJzaW9uOiAgICAgICAgICAgICAgICAgICAgICAgMAogIFR5cGU6ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUkVMIChSZWxvY2F0YWJsZSBmaWxlKQogIE1hY2hpbmU6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgTUlQUyBSMzAwMCBiaWctZW5kaWFuCiAgVmVyc2lvbjogICAgICAg ICAgICAgICAgICAgICAgICAgICAweDEKICBFbnRyeSBwb2ludCBhZGRyZXNzOiAgICAgICAgICAg ICAgIDB4MAogIFN0YXJ0IG9mIHByb2dyYW0gaGVhZGVyczogICAgICAgICAgMCAoYnl0ZXMgaW50 byBmaWxlKQogIFN0YXJ0IG9mIHNlY3Rpb24gaGVhZGVyczogICAgICAgICAgNDcyOCAoYnl0ZXMg aW50byBmaWxlKQogIEZsYWdzOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHgxMDAwMDAw MSwgbm9yZW9yZGVyLCBtaXBzMgogIFNpemUgb2YgdGhpcyBoZWFkZXI6ICAgICAgICAgICAgICAg NTIgKGJ5dGVzKQogIFNpemUgb2YgcHJvZ3JhbSBoZWFkZXJzOiAgICAgICAgICAgMCAoYnl0ZXMp CiAgTnVtYmVyIG9mIHByb2dyYW0gaGVhZGVyczogICAgICAgICAwCiAgU2l6ZSBvZiBzZWN0aW9u IGhlYWRlcnM6ICAgICAgICAgICA0MCAoYnl0ZXMpCiAgTnVtYmVyIG9mIHNlY3Rpb24gaGVhZGVy czogICAgICAgICAxNQogIFNlY3Rpb24gaGVhZGVyIHN0cmluZyB0YWJsZSBpbmRleDogMTIKClNl Y3Rpb24gSGVhZGVyczoKICBbTnJdIE5hbWUgICAgICAgICAgICAgIFR5cGUgICAgICAgICAgICBB ZGRyICAgICBPZmYgICAgU2l6ZSAgIEVTIEZsZyBMayBJbmYgQWwKICBbIDBdICAgICAgICAgICAg ICAgICAgIE5VTEwgICAgICAgICAgICAwMDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwICAgICAgMCAg IDAgMAogIFsgMV0gLnRleHQgICAgICAgICAgICAgUFJPR0JJVFMgICAgICAgIDAwMDAwMDAwIDAw MDA0MCAwMDA1YzAgMDAgIEFYICAwICAgMCAxNgogIFsgMl0gLnJlbC50ZXh0ICAgICAgICAgUkVM ICAgICAgICAgICAgIDAwMDAwMDAwIDAwMTg1NCAwMDA1MTggMDggICAgIDEzICAgMSA0CiAgWyAz XSAuZGF0YSAgICAgICAgICAgICBQUk9HQklUUyAgICAgICAgMDAwMDAwMDAgMDAwNjAwIDAwMDA1 MCAwMCBXQSAgIDAgICAwIDE2CiAgWyA0XSAucmVsLmRhdGEgICAgICAgICBSRUwgICAgICAgICAg ICAgMDAwMDAwMDAgMDAxZDZjIDAwMDAzOCAwOCAgICAgMTMgICAzIDQKICBbIDVdIC5ic3MgICAg ICAgICAgICAgIE5PQklUUyAgICAgICAgICAwMDAwMDAwMCAwMDA2NTAgMDAwMDAwIDAwIFdBICAg MCAgIDAgMTYKICBbIDZdIC5yZWdpbmZvICAgICAgICAgIE1JUFNfUkVHSU5GTyAgICAwMDAwMDAw MCAwMDA2NTAgMDAwMDE4IDAxICBBICAgMCAgIDAgNAogIFsgN10gLm1kZWJ1ZyAgICAgICAgICAg TUlQU19ERUJVRyAgICAgIDAwMDAwMDAwIDAwMDY2OCAwMDA4NDggMDEgICAgICAwICAgMCA0CiAg WyA4XSAubm90ZSAgICAgICAgICAgICBOT1RFICAgICAgICAgICAgMDAwMDAwMDAgMDAwZWIwIDAw MDAxNCAwMCAgICAgIDAgICAwIDEKICBbIDldIC5tb2RpbmZvICAgICAgICAgIFBST0dCSVRTICAg ICAgICAwMDAwMDAwMCAwMDBlYzQgMDAwMDFjIDAwICAgICAgMCAgIDAgNAogIFsxMF0gLnJvZGF0 YSAgICAgICAgICAgUFJPR0JJVFMgICAgICAgIDAwMDAwMDAwIDAwMGVlMCAwMDAyZjAgMDAgIEEg ICAwICAgMCAxNgogIFsxMV0gLmNvbW1lbnQgICAgICAgICAgUFJPR0JJVFMgICAgICAgIDAwMDAw MDAwIDAwMTFkMCAwMDAwMzUgMDAgICAgICAwICAgMCAxCiAgWzEyXSAuc2hzdHJ0YWIgICAgICAg ICBTVFJUQUIgICAgICAgICAgMDAwMDAwMDAgMDAxMjA1IDAwMDA3MSAwMCAgICAgIDAgICAwIDEK ICBbMTNdIC5zeW10YWIgICAgICAgICAgIFNZTVRBQiAgICAgICAgICAwMDAwMDAwMCAwMDE0ZDAg MDAwMjQwIDEwICAgICAxNCAgIGEgNAogIFsxNF0gLnN0cnRhYiAgICAgICAgICAgU1RSVEFCICAg ICAgICAgIDAwMDAwMDAwIDAwMTcxMCAwMDAxNDEgMDAgICAgICAwICAgMCAxCgpUaGVyZSBhcmUg bm8gcHJvZ3JhbSBoZWFkZXJzIGluIHRoaXMgZmlsZS4KClRoZXJlIGlzIG5vIGR5bmFtaWMgc2Vn bWVudCBpbiB0aGlzIGZpbGUuCgpSZWxvY2F0aW9uIHNlY3Rpb24gJy5yZWwudGV4dCcgYXQgb2Zm c2V0IDB4MTg1NCBjb250YWlucyAxNjMgZW50cmllczoKICBPZmZzZXQgICAgSW5mbyAgVHlwZSAg ICAgICAgICAgIFN5bWJvbCdzIFZhbHVlICBTeW1ib2wncyBOYW1lCiAgMDAwMDAwMDggIDAwMjA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnRleHQgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMDBjICAwMDIwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC50ZXh0 ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDAyOCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAwMmMgIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMDM4ICAwMDMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDAzYyAgMDAzMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAwNDggIDAwNDA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwMDRjICAwMDQwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDA1MCAgMDFjMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAwNTQgIDAxYzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMDYwICAwMWQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIF9fdGhp c19tb2R1bGUgICAgICAgICAgICAKICAwMDAwMDA2NCAgMDFkMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBfX3RoaXNfbW9kdWxlICAgICAgICAgICAgCiAgMDAwMDAwOTQgIDAwMjA0 IFJfTUlQU18yNiAgICAgICAgICAgICAwMDAwMDAwMCAgLnRleHQgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMDljICAwMWQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIF9fdGhp c19tb2R1bGUgICAgICAgICAgICAKICAwMDAwMDBhMCAgMDFkMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBfX3RoaXNfbW9kdWxlICAgICAgICAgICAgCiAgMDAwMDAwYWMgIDAwNDA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwMGIwICAwMDQwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDBiNCAgMDFjMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAwYjggIDAxYzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMGM4ICAwMWUwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIGF0bV9k ZXZfZGVyZWdpc3RlciAgICAgICAKICAwMDAwMDBjYyAgMDFlMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBhdG1fZGV2X2RlcmVnaXN0ZXIgICAgICAgCiAgMDAwMDAwZDggIDAxZjA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAga2ZyZWUgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMGRjICAwMWYwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIGtmcmVl ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDBlOCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAwZWMgIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMGY4ICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDBmYyAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAxMDAgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMTA0ICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDEyMCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAxMjQgIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMTNjICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDE0MCAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAxNDQgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMTQ4ICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDE1OCAgMDIwMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICBrbWFsbG9jICAgICAgICAgICAgICAgICAgCiAgMDAwMDAxNWMgIDAyMDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAga21hbGxvYyAgICAgICAgICAgICAgICAg IAogIDAwMDAwMTc0ICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDE3OCAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAxN2MgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMTgwICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDE4YyAgMDAyMDQgUl9NSVBTXzI2ICAgICAgICAg ICAgIDAwMDAwMDAwICAudGV4dCAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAxOTQgIDAwNDA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwMTk4ICAwMDQwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDFhMCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAxYTQgIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMWE4ICAwMjEwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIGF0bV9k ZXZfcmVnaXN0ZXIgICAgICAgICAKICAwMDAwMDFhYyAgMDIxMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBhdG1fZGV2X3JlZ2lzdGVyICAgICAgICAgCiAgMDAwMDAxYzggIDAwMjA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnRleHQgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMWNjICAwMDIwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC50ZXh0 ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDFkNCAgMDIzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICByZXF1ZXN0X2lycSAgICAgICAgICAgICAgCiAgMDAwMDAxZDggIDAyMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgcmVxdWVzdF9pcnEgICAgICAgICAgICAg IAogIDAwMDAwMWVjICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDFmMCAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAxZjQgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMWY4ICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDIwNCAgMDAyMDQgUl9NSVBTXzI2ICAgICAgICAg ICAgIDAwMDAwMDAwICAudGV4dCAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyMGMgIDAwMzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMjEwICAwMDMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDIxNCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyMTggIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMjI0ICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDIyOCAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyMmMgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMjMwICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDI1NCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyNTggIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMjY4ICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDI2YyAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyNzAgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMjc0ICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDI4MCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyODQgIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMjkwICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDI5NCAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyOTggIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMjljICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDJiOCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyYmMgIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMmNjICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDJkMCAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyZDQgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMmQ4ICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDJlNCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyZTggIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMmY0ICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDJmOCAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAyZmMgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMzAwICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDMxOCAgMDAzMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAzMWMgIDAwMzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMzJjICAwMDQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDMzMCAgMDA0MDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDAzMzQgIDAxYzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMzM4ICAwMWMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDM0OCAgMDFkMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICBfX3RoaXNfbW9kdWxlICAgICAgICAgICAgCiAgMDAwMDAzNGMgIDAxZDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgX190aGlzX21vZHVsZSAgICAgICAgICAg IAogIDAwMDAwMzY4ICAwMDMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDM2YyAgMDAzMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAzN2MgIDAwNDA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwMzgwICAwMDQwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDM4NCAgMDFjMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAzODggIDAxYzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwM2E0ICAwMDMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDNhOCAgMDAzMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAzYjggIDAwNDA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwM2JjICAwMDQwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDNjMCAgMDFjMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAzYzQgIDAxYzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwM2Q0ICAwMWQwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIF9fdGhp c19tb2R1bGUgICAgICAgICAgICAKICAwMDAwMDNkOCAgMDFkMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBfX3RoaXNfbW9kdWxlICAgICAgICAgICAgCiAgMDAwMDAzZjQgIDAwMzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwM2Y4ICAwMDMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDQwOCAgMDA0MDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0MGMgIDAwNDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNDEwICAwMWMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDQxNCAgMDFjMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0MmMgIDAwMzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwNDMwICAwMDMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDQ0MCAgMDA0MDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0NDQgIDAwNDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNDQ4ICAwMWMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDQ0YyAgMDFjMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0NTggIDAwMzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwNDVjICAwMDMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDQ2OCAgMDA0MDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0NmMgIDAwNDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNDcwICAwMWMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDQ3NCAgMDFjMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0OTAgIDAwMzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwNDk0ICAwMDMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDRhNCAgMDA0MDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0YTggIDAwNDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNGFjICAwMWMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDRiMCAgMDFjMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0YmMgIDAwMzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwNGMwICAwMDMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDRjYyAgMDA0MDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0ZDAgIDAwNDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNGQ0ICAwMWMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDRkOCAgMDFjMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA0ZjQgIDAwMzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwNGY4ICAwMDMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDUwYyAgMDA0MDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDA1MTAgIDAwNDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNTE0ICAwMWMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIHByaW50 ayAgICAgICAgICAgICAgICAgICAKICAwMDAwMDUxOCAgMDFjMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA1MjQgIDAwMzA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLmRhdGEgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwNTI4ICAwMDMwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDUzNCAgMDA0MDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICAucm9kYXRhICAgICAgICAgICAgICAgICAgCiAgMDAwMDA1M2MgIDAwNDA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNTUwICAwMDMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDU1NCAgMDAzMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA1NjQgIDAwNDA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNTY4ICAwMDQwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDU2YyAgMDFjMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA1NzAgIDAxYzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAogIDAwMDAwNTdjICAwMDMwNSBSX01JUFNfSEkxNiAgICAgICAgICAgMDAwMDAwMDAgIC5kYXRh ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDU4MCAgMDAzMDYgUl9NSVBTX0xPMTYgICAgICAg ICAgIDAwMDAwMDAwICAuZGF0YSAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA1OGMgIDAwNDA1 IFJfTUlQU19ISTE2ICAgICAgICAgICAwMDAwMDAwMCAgLnJvZGF0YSAgICAgICAgICAgICAgICAg IAogIDAwMDAwNTkwICAwMDQwNiBSX01JUFNfTE8xNiAgICAgICAgICAgMDAwMDAwMDAgIC5yb2Rh dGEgICAgICAgICAgICAgICAgICAKICAwMDAwMDU5NCAgMDFjMDUgUl9NSVBTX0hJMTYgICAgICAg ICAgIDAwMDAwMDAwICBwcmludGsgICAgICAgICAgICAgICAgICAgCiAgMDAwMDA1OTggIDAxYzA2 IFJfTUlQU19MTzE2ICAgICAgICAgICAwMDAwMDAwMCAgcHJpbnRrICAgICAgICAgICAgICAgICAg IAoKUmVsb2NhdGlvbiBzZWN0aW9uICcucmVsLmRhdGEnIGF0IG9mZnNldCAweDFkNmMgY29udGFp bnMgNyBlbnRyaWVzOgogIE9mZnNldCAgICBJbmZvICBUeXBlICAgICAgICAgICAgU3ltYm9sJ3Mg VmFsdWUgIFN5bWJvbCdzIE5hbWUKICAwMDAwMDAwOCAgMDAyMDIgUl9NSVBTXzMyICAgICAgICAg ICAgIDAwMDAwMDAwICAudGV4dCAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAwMGMgIDAwMjAy IFJfTUlQU18zMiAgICAgICAgICAgICAwMDAwMDAwMCAgLnRleHQgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMDEwICAwMDIwMiBSX01JUFNfMzIgICAgICAgICAgICAgMDAwMDAwMDAgIC50ZXh0 ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDAxYyAgMDAyMDIgUl9NSVBTXzMyICAgICAgICAg ICAgIDAwMDAwMDAwICAudGV4dCAgICAgICAgICAgICAgICAgICAgCiAgMDAwMDAwMjggIDAwMjAy IFJfTUlQU18zMiAgICAgICAgICAgICAwMDAwMDAwMCAgLnRleHQgICAgICAgICAgICAgICAgICAg IAogIDAwMDAwMDJjICAwMDIwMiBSX01JUFNfMzIgICAgICAgICAgICAgMDAwMDAwMDAgIC50ZXh0 ICAgICAgICAgICAgICAgICAgICAKICAwMDAwMDAzYyAgMDAyMDIgUl9NSVBTXzMyICAgICAgICAg ICAgIDAwMDAwMDAwICAudGV4dCAgICAgICAgICAgICAgICAgICAgCgpTeW1ib2wgdGFibGUgJy5z eW10YWInIGNvbnRhaW5zIDM2IGVudHJpZXM6CiAgTnVtOiAgICBWYWx1ZSAgU2l6ZSBUeXBlICAg IEJpbmQgICBPdCAgTmR4IE5hbWUKICAgIDA6ICAgICAgICAwICAgICAwIE5PVFlQRSAgTE9DQUwg ICAwICBVTkQgCiAgICAxOiAgICAgICAgMCAgICAgMCBTRUNUSU9OIExPQ0FMICAgMCAgICA5IAog ICAgMjogICAgICAgIDAgICAgIDAgU0VDVElPTiBMT0NBTCAgIDAgICAgMSB0ZXh0CiAgICAzOiAg ICAgICAgMCAgICAgMCBTRUNUSU9OIExPQ0FMICAgMCAgICAzIGRhdGEKICAgIDQ6ICAgICAgICAw ICAgICAwIFNFQ1RJT04gTE9DQUwgICAwICAgMTAgcm9kYXRhIAogICAgNTogICAgICAgIDAgICAg IDAgU0VDVElPTiBMT0NBTCAgIDAgICAgNSBic3MKICAgIDY6ICAgICAgICAwICAgICAwIFNFQ1RJ T04gTE9DQUwgICAwICAgIDYgCiAgICA3OiAgICAgICAgMCAgICAgMCBTRUNUSU9OIExPQ0FMICAg MCAgICA3IAogICAgODogICAgICAgIDAgICAgIDAgU0VDVElPTiBMT0NBTCAgIDAgICAgOCAKICAg IDk6ICAgICAgICAwICAgICAwIFNFQ1RJT04gTE9DQUwgICAwICAgMTEgCiAgIDEwOiAgICAgICAg MCAgICAgMCBOT1RZUEUgIExPQ0FMICAgMCAgICAxIGdjYzJfY29tcGlsZWQuCiAgIDExOiAgICAg ICAgMCAgICAgMCBOT1RZUEUgIExPQ0FMICAgMCAgICAxIF9fZ251X2NvbXBpbGVkX2MKICAgMTI6 ICAgICAgICAwICAgIDI4IE9CSkVDVCAgR0xPQkFMICAwICAgIDkgX19tb2R1bGVfa2VybmVsX3Zl cnNpb24KICAgMTM6ICAgICAgICAwICAgICA0IE9CSkVDVCAgTE9DQUwgICAwICAgMTAgX2Jvbml0 bwogICAxNDogICAgICAgIDAgICAgIDQgT0JKRUNUICBMT0NBTCAgIDAgICAgMyBkaXNwbGF5X3N0 cmluZwogICAxNTogICAgICAgIDQgICAgNjAgT0JKRUNUICBMT0NBTCAgIDAgICAgMyBhdG1fb3Bz CiAgIDE2OiAgICAgIDMxOCAgIDE0MCBGVU5DICAgIExPQ0FMICAgMCAgICAxIGlkZF9vcGVuCiAg IDE3OiAgICAgIDNhNCAgIDEzNiBGVU5DICAgIExPQ0FMICAgMCAgICAxIGlkZF9jbG9zZQogICAx ODogICAgICA0OTAgICAxMDAgRlVOQyAgICBMT0NBTCAgIDAgICAgMSBpZGRfaW9jdGwKICAgMTk6 ICAgICAgMjU0ICAgMTAwIEZVTkMgICAgTE9DQUwgICAwICAgIDEgaWRkX3NlbmQKICAgMjA6ICAg ICAgNGY0ICAgIDkyIEZVTkMgICAgTE9DQUwgICAwICAgIDEgaWRkX3BoeV9wdXQKICAgMjE6ICAg ICAgNTUwICAgMTAwIEZVTkMgICAgTE9DQUwgICAwICAgIDEgaWRkX3BoeV9nZXQKICAgMjI6ICAg ICAgNDJjICAgMTAwIEZVTkMgICAgTE9DQUwgICAwICAgIDEgaWRkX3Byb2NfcmVhZAogICAyMzog ICAgICAgNDAgICAgIDQgT0JKRUNUICBHTE9CQUwgIDAgICAgMyB0aGVfY2FyZAogICAyNDogICAg ICAgNDQgICAgIDQgT0JKRUNUICBHTE9CQUwgIDAgICAgMyBkYmdfbHZsCiAgIDI1OiAgICAgICAg MCAgICA0MCBGVU5DICAgIEdMT0JBTCAgMCAgICAxIGluaXRfbW9kdWxlCiAgIDI2OiAgICAgIDEy MCAgIDMwOCBGVU5DICAgIExPQ0FMICAgMCAgICAxIGlkZF9pbml0X2NhcmQKICAgMjc6ICAgICAg IDI4ICAgMjQ4IEZVTkMgICAgR0xPQkFMICAwICAgIDEgY2xlYW51cF9tb2R1bGUKICAgMjg6ICAg ICAgICAwICAgICAwIE9CSkVDVCAgR0xPQkFMICAwICBVTkQgcHJpbnRrCiAgIDI5OiAgICAgICAg MCAgICAgMCBPQkpFQ1QgIEdMT0JBTCAgMCAgVU5EIF9fdGhpc19tb2R1bGUKICAgMzA6ICAgICAg ICAwICAgICAwIE9CSkVDVCAgR0xPQkFMICAwICBVTkQgYXRtX2Rldl9kZXJlZ2lzdGVyCiAgIDMx OiAgICAgICAgMCAgICAgMCBPQkpFQ1QgIEdMT0JBTCAgMCAgVU5EIGtmcmVlCiAgIDMyOiAgICAg ICAgMCAgICAgMCBPQkpFQ1QgIEdMT0JBTCAgMCAgVU5EIGttYWxsb2MKICAgMzM6ICAgICAgICAw ICAgICAwIE9CSkVDVCAgR0xPQkFMICAwICBVTkQgYXRtX2Rldl9yZWdpc3RlcgogICAzNDogICAg ICAyYjggICAgOTYgRlVOQyAgICBMT0NBTCAgIDAgICAgMSBpZGRfaXJxX2hhbmRsZXIKICAgMzU6 ICAgICAgICAwICAgICAwIE9CSkVDVCAgR0xPQkFMICAwICBVTkQgcmVxdWVzdF9pcnEKCk5vIHZl cnNpb24gaW5mb3JtYXRpb24gZm91bmQgaW4gdGhpcyBmaWxlLgo= --------------Boundary-00=_XTV34PRUXRABB12KU3Q8 Content-Type: text/plain; charset="iso-8859-1"; name="obj_relocate_log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="obj_relocate_log" VmFsdWVzIG9mIGludHN5bSBpbiBvYmpfcmVsb2NhdGUgLCBqdXN0IGJlZm9yZSB0aGUgY2FsbCB0 byBvYmpfc3ltYm9sX2ZpbmFsX3ZhbHVlIGZ1bmN0aW9uCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQpOTyBCU1MgUmVsb2NhdGlvbiBvdmVyZmxvdwo9PT09PT09PT09PT09PT09PT09 PT09PT09PQpvYmpfcmVsb2NhdGU6IGJhc2VhZGRyPWMwMDE1MDAwIHJlbG9jYXRpb24gYWxsIHNl Y3Rpb25zIHdpdGggdGhpcyBhZGRyCm9ial9yZWxvY2F0ZTogc2VjdGlvbj0uc3ltdGFiIHJlbGVu ZD0yNjg4NjYyNTYKb2JqX3JlbG9jYXRlOiAgaW50c3ltLT5uYW1lPS50ZXh0LHN5bW5keD0yIGlu dHN5bS0+c2VjaWR4PTEwMDZhMWU4Cm9ial9yZWxvY2F0ZTogIGludHN5bS0+bmFtZT0udGV4dCxz eW1uZHg9MiBpbnRzeW0tPnNlY2lkeD0xMDA2YTFlOApvYmpfcmVsb2NhdGU6ICBpbnRzeW0tPm5h bWU9LmRhdGEsc3ltbmR4PTMgaW50c3ltLT5zZWNpZHg9MwpvYmpfcmVsb2NhdGU6ICBpbnRzeW0t Pm5hbWU9LmRhdGEsc3ltbmR4PTMgaW50c3ltLT5zZWNpZHg9MwpvYmpfcmVsb2NhdGU6ICBpbnRz eW0tPm5hbWU9LmRhdGEsc3ltbmR4PTMgaW50c3ltLT5zZWNpZHg9MwpvYmpfcmVsb2NhdGU6ICBp bnRzeW0tPm5hbWU9LmRhdGEsc3ltbmR4PTMgaW50c3ltLT5zZWNpZHg9MwpvYmpfcmVsb2NhdGU6 ICBpbnRzeW0tPm5hbWU9LnJvZGF0YSxzeW1uZHg9NCBpbnRzeW0tPnNlY2lkeD1hCm9ial9yZWxv Y2F0ZTogIGludHN5bS0+bmFtZT0ucm9kYXRhLHN5bW5keD00IGludHN5bS0+c2VjaWR4PWEKb2Jq X3JlbG9jYXRlOiAgaW50c3ltLT5uYW1lPXByaW50ayxzeW1uZHg9MjggaW50c3ltLT5zZWNpZHg9 MTAwMDAKb2JqX3JlbG9jYXRlOiAgaW50c3ltLT5uYW1lPXByaW50ayxzeW1uZHg9MjggaW50c3lt LT5zZWNpZHg9MTAwMDAKb2JqX3JlbG9jYXRlOiAgaW50c3ltLT5uYW1lPV9fdGhpc19tb2R1bGUs c3ltbmR4PTI5IGludHN5bS0+c2VjaWR4PWYKb2JqX3JlbG9jYXRlOiAgaW50c3ltLT5uYW1lPV9f dGhpc19tb2R1bGUsc3ltbmR4PTI5IGludHN5bS0+c2VjaWR4PWYKb2JqX3JlbG9jYXRlOiAgaW50 c3ltLT5uYW1lPS50ZXh0LHN5bW5keD0yIGludHN5bS0+c2VjaWR4PTEwMDZhMWU4CgoKV2l0aCBC U1MgZ29vZCBleGVjdXRpb24KPT09PT09PT09PT09PT09PT09PT09PT0Kb2JqX3JlbG9jYXRlOiBz ZWN0aW9uPS5zeW10YWIgcmVsZW5kPTI2ODg2NjI1NgpvYmpfcmVsb2NhdGU6ICBpbnRzeW0tPm5h bWU9LnRleHQsc3ltbmR4PTIgaW50c3ltLT5zZWNpZHg9MQpvYmpfcmVsb2NhdGU6ICBpbnRzeW0t Pm5hbWU9LnRleHQsc3ltbmR4PTIgaW50c3ltLT5zZWNpZHg9MQpvYmpfcmVsb2NhdGU6ICBpbnRz eW0tPm5hbWU9LHN5bW5keD0zIGludHN5bS0+c2VjaWR4PTMKb2JqX3JlbG9jYXRlOiAgaW50c3lt LT5uYW1lPSxzeW1uZHg9MyBpbnRzeW0tPnNlY2lkeD0zCm9ial9yZWxvY2F0ZTogIGludHN5bS0+ bmFtZT0sc3ltbmR4PTMgaW50c3ltLT5zZWNpZHg9MwpvYmpfcmVsb2NhdGU6ICBpbnRzeW0tPm5h bWU9LHN5bW5keD0zIGludHN5bS0+c2VjaWR4PTMKb2JqX3JlbG9jYXRlOiAgaW50c3ltLT5uYW1l PS5yb2RhdGEsc3ltbmR4PTQgaW50c3ltLT5zZWNpZHg9YQpvYmpfcmVsb2NhdGU6ICBpbnRzeW0t Pm5hbWU9LnJvZGF0YSxzeW1uZHg9NCBpbnRzeW0tPnNlY2lkeD1hCm9ial9yZWxvY2F0ZTogIGlu dHN5bS0+bmFtZT1wcmludGssc3ltbmR4PTI3IGludHN5bS0+c2VjaWR4PTEwMDAwCm9ial9yZWxv Y2F0ZTogIGludHN5bS0+bmFtZT1wcmludGssc3ltbmR4PTI3IGludHN5bS0+c2VjaWR4PTEwMDAw Cm9ial9yZWxvY2F0ZTogIGludHN5bS0+bmFtZT1fX3RoaXNfbW9kdWxlLHN5bW5keD0yOCBpbnRz eW0tPnNlY2lkeD1mCm9ial9yZWxvY2F0ZTogIGludHN5bS0+bmFtZT1fX3RoaXNfbW9kdWxlLHN5 bW5keD0yOCBpbnRzeW0tPnNlY2lkeD1mCm9ial9yZWxvY2F0ZTogIGludHN5bS0+bmFtZT0udGV4 dCxzeW1uZHg9MiBpbnRzeW0tPnNlY2lkeD0xCgo= --------------Boundary-00=_XTV34PRUXRABB12KU3Q8-- From owner-linux-mips@oss.sgi.com Wed May 9 23:11:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A6Bd322948 for linux-mips-outgoing; Wed, 9 May 2001 23:11:39 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A6BdF22945 for ; Wed, 9 May 2001 23:11:39 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA05201; Wed, 9 May 2001 23:11:45 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA22967; Wed, 9 May 2001 23:11:42 -0700 (PDT) Received: from mips.com (coppccl [172.17.27.2]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id IAA08099; Thu, 10 May 2001 08:10:46 +0200 (MEST) Message-ID: <3AFA3101.B86D47A1@mips.com> Date: Thu, 10 May 2001 08:11:13 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Nguyen CC: linux-mips@oss.sgi.com Subject: Re: MIPS 5Kc References: <4.3.2.7.2.20010509095019.00a90830@sti-sun4> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 850 Lines: 28 There is no module support in the pre-compiled kernel images on the MIPS FTP site, but you can just take the sources and recompile the kernel with module support enabled. /Carsten Tim Nguyen wrote: > Hello all, > > Does anybody have any comments concerning the Alta board with a MIPS 5Kc > running Linux. I hear that Linux modules aren't fully supported in their > reference 2.2.12 kernel. Are there any other known issues with that kernel > -- how about the 2.4.1 kernel? Any help will be greatly appreciated. > Regards, > Tim Nguyen > > ****************************************************** > Tim Nguyen > Sr. Software Engineer > SimpleTech > 3001 Daimler Street > Santa Ana, CA 92705 > PH: 949-476-1180 x8838 > FX: 949-851-2398 > tnguyen@simpletech.com www.simpletech.com > ****************************************************** From owner-linux-mips@oss.sgi.com Wed May 9 23:16:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A6GWV23369 for linux-mips-outgoing; Wed, 9 May 2001 23:16:32 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A6GUF23364 for ; Wed, 9 May 2001 23:16:30 -0700 Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id IAA01389; Thu, 10 May 2001 08:15:38 +0200 (MET DST) Date: Thu, 10 May 2001 08:15:37 +0200 (MET DST) From: Geert Uytterhoeven To: Wayne Gowcher cc: linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board In-Reply-To: <20010510055512.96321.qmail@web11902.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1926 Lines: 51 On Wed, 9 May 2001, Wayne Gowcher wrote: > I was wondering if anyone has any experience in > configuring the PCI registers in a PCI Video Card on a > MIPS board that has no BIOS like in a PC. > > At the moment when I have some "home grown" PCI > probing routines based on my best interpretation of > the PCI spec. But it's not working. > > I can probe the Base Address Register successfully, > determine the cards memory requirement and that it is > memory rather than mapped IO. But when I try to write > the address I have allocated to the PCI card ( eg > 0xC000 0000 ) the address will not latch in the base > address register. > > The card is designed for x86 PCs and when the PC bios > configures the card, the base address register has the > value 0xF200 0000. > > Any comments from anybody with any insight into what > is happening here / or how I might fix my probelm, > would be greatly appreciated. > > Does anyone know of any code that carries out PCI > probing similar to that found on x86 PC's ? Initialising video cards is a real PITA. The simplest method is to use a x86 BIOS emulator to execute the code in the video BIOS on the card. Note that some cards (mostly older cards) power up in VGA legacy mode. They will not respond to PCI memory space as specified by the BAR before you tell them to do so (in a card-specific way :-( Most modern cards power up in PCI mode. However, to use them, you still have to know the card-specific initialization sequence. BTW, what video card do you have? If you're lucky and have a Matrox Millennium, you can use matroxfb, which knows how to initialize uninitialized cards. Good luck! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Thu May 10 01:53:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A8rvw27005 for linux-mips-outgoing; Thu, 10 May 2001 01:53:57 -0700 Received: from mailgw3.netvision.net.il (mailgw3.netvision.net.il [194.90.1.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A8rPF26994; Thu, 10 May 2001 01:53:26 -0700 Received: from jungo.com ([194.90.113.98]) by mailgw3.netvision.net.il (8.9.3/8.9.3) with ESMTP id LAA27494; Thu, 10 May 2001 11:51:48 +0300 (IDT) Message-ID: <3AFA56F8.9090504@jungo.com> Date: Thu, 10 May 2001 11:53:12 +0300 From: Michael Shmulevich Organization: Jungo LTD User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8.1) Gecko/20010326 X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Shay Deloya , linux-mips@oss.sgi.com Subject: Re: insmod problems References: <01050619134301.01140@athena.home.krftech.com> <20010508234036.A1216@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1190 Lines: 37 Ralf Baechle wrote: > On Sun, May 06, 2001 at 07:13:43PM +0300, Shay Deloya wrote: > > >> I have an old problem came up again and the old solution aren't helping. >> Relocation overflow of type 4 for >> Is it insmod knowen bugs that the relocation is done in bad way or >> a linker/compiler bug. I'm using compiler: egcs ver 1.0.3a >> I'm checking this problem at the moment and looking for insmod bug. > > > You'll have to upgrade to very current binutils which for mips*-linux > targets default to elf32-trad{big,little}mips, not IRIX ELF format. Also > it seems your modutils are a bit rotten, get the latest from ftp.kernel.org. > > Ralf On the same topic: same source (!!) 'insmod' executable compiled with new (2.10) binutils doesn't exibit such relocation problem. What may be causing 'insmod' to be dependant on binutils which compile it? The module *.o is exactly same as it was before. Sincerely yours, Michael Shmulevich ______________________________________ Software Developer Jungo - R&D email: michaels@jungo.com web: http://www.jungo.com Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233 Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide) From owner-linux-mips@oss.sgi.com Thu May 10 02:01:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A91RA27342 for linux-mips-outgoing; Thu, 10 May 2001 02:01:27 -0700 Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A91PF27338 for ; Thu, 10 May 2001 02:01:26 -0700 Received: from jungo.com ([194.90.113.98]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id MAA07506; Thu, 10 May 2001 12:01:18 +0300 (IDT) Message-ID: <3AFA58B6.7010806@jungo.com> Date: Thu, 10 May 2001 12:00:38 +0300 From: Michael Shmulevich Organization: Jungo LTD User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8.1) Gecko/20010326 X-Accept-Language: en MIME-Version: 1.0 To: Tim Nguyen CC: linux-mips@oss.sgi.com Subject: Re: MIPS 5Kc References: <4.3.2.7.2.20010509095019.00a90830@sti-sun4> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1221 Lines: 38 Tim Nguyen wrote: > Hello all, > > Does anybody have any comments concerning the Alta board with a MIPS 5Kc > running Linux. I hear that Linux modules aren't fully supported in > their reference 2.2.12 kernel. Are there any other known issues with > that kernel -- how about the 2.4.1 kernel? Any help will be greatly > appreciated. > Regards, > Tim Nguyen Tim, The kernel 2.2.12 form mips' ftp site has no modules support at all. The problem may be coming from the binutils bugs that were used to create the kernel image, which is 2.8.1 which reportedly (at least from our company) do not produce usable 'insmod'. It is not 5Kc - related stuff, we have several boards with such processors (including Malta and Atlas) and all of them exibited module problems with "old" toolchain (binutils 2.8.1 - egcs 1.0.3a - glibc 2.0.6). Newer kernel 2.4.x is also available from mips' ftp site, but we haven't checked it out yet. -- Sincerely yours, Michael Shmulevich ______________________________________ Software Developer Jungo - R&D email: michaels@jungo.com web: http://www.jungo.com Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233 Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide) From owner-linux-mips@oss.sgi.com Thu May 10 02:52:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A9qup28571 for linux-mips-outgoing; Thu, 10 May 2001 02:52:56 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A9ndF28426; Thu, 10 May 2001 02:50:04 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA14125; Thu, 10 May 2001 11:43:36 +0200 (MET DST) Date: Thu, 10 May 2001 11:43:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: lift the ioport_resource limit ... In-Reply-To: <3AF9B173.5E13AD2@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 828 Lines: 18 On Wed, 9 May 2001, Jun Sun wrote: > The PCI IO space essentially extends the ISA bus, which effectively removes > the 0xffff limits. Note that while there is usually no problem with using addresses beyond 64kB in the PCI I/O space, certain PCI-to-PCI bridges may not pass such accesses across. So it's best to avoid assigning and using them. That's why Linux remaps "high" I/O space resources on Alpha, which get set up for some systems by the SRM console (firmware), e.g. in the system I was using a few years ago, SRM used to assign addresses around 0x11000 and 0x12000 for the onboard network and SCSI devices, IIRC. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 10 03:00:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AA0rs28914 for linux-mips-outgoing; Thu, 10 May 2001 03:00:53 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AA0fF28910; Thu, 10 May 2001 03:00:41 -0700 Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA12202; Thu, 10 May 2001 11:58:51 +0200 (MET DST) Date: Thu, 10 May 2001 11:58:51 +0200 (MET DST) From: Geert Uytterhoeven To: "Maciej W. Rozycki" cc: Jun Sun , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: lift the ioport_resource limit ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1140 Lines: 27 On Thu, 10 May 2001, Maciej W. Rozycki wrote: > On Wed, 9 May 2001, Jun Sun wrote: > > The PCI IO space essentially extends the ISA bus, which effectively removes > > the 0xffff limits. > > Note that while there is usually no problem with using addresses beyond > 64kB in the PCI I/O space, certain PCI-to-PCI bridges may not pass such > accesses across. So it's best to avoid assigning and using them. That's > why Linux remaps "high" I/O space resources on Alpha, which get set up for > some systems by the SRM console (firmware), e.g. in the system I was using > a few years ago, SRM used to assign addresses around 0x11000 and 0x12000 > for the onboard network and SCSI devices, IIRC. Shouldn't that be reflected in the bridge's bus resources (pci_bus.resource[])? Then the PCI resource validation/assignment code will (re)assign them when necessary. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Thu May 10 04:16:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ABGYd30699 for linux-mips-outgoing; Thu, 10 May 2001 04:16:34 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ABFgF30672; Thu, 10 May 2001 04:15:43 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA18334; Thu, 10 May 2001 13:08:32 +0200 (MET DST) Date: Thu, 10 May 2001 13:08:31 +0200 (MET DST) From: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: Jun Sun , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: lift the ioport_resource limit ... In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 641 Lines: 18 On Thu, 10 May 2001, Geert Uytterhoeven wrote: > Shouldn't that be reflected in the bridge's bus resources (pci_bus.resource[])? No idea -- if you write so then you are probably right. I was told of the problem at about 2.1.85 and I haven't investigated it further. Our PCI handling code wasn't so brillant as it is now, I guess. > Then the PCI resource validation/assignment code will (re)assign them when > necessary. Excellent. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 10 10:14:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AHE3h06453 for linux-mips-outgoing; Thu, 10 May 2001 10:14:03 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AHE2F06450 for ; Thu, 10 May 2001 10:14:02 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4AHE2011951; Thu, 10 May 2001 10:14:02 -0700 Message-ID: <3AFACBC8.DE85A67E@mvista.com> Date: Thu, 10 May 2001 10:11:36 -0700 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, bg MIME-Version: 1.0 To: Wayne Gowcher CC: linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board References: <20010510055512.96321.qmail@web11902.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1961 Lines: 48 Wayne Gowcher wrote: > > Dear All, > > I was wondering if anyone has any experience in > configuring the PCI registers in a PCI Video Card on a > MIPS board that has no BIOS like in a PC. > > At the moment when I have some "home grown" PCI > probing routines based on my best interpretation of > the PCI spec. But it's not working. > > I can probe the Base Address Register successfully, > determine the cards memory requirement and that it is > memory rather than mapped IO. But when I try to write > the address I have allocated to the PCI card ( eg > 0xC000 0000 ) the address will not latch in the base > address register. > > The card is designed for x86 PCs and when the PC bios > configures the card, the base address register has the > value 0xF200 0000. > > Any comments from anybody with any insight into what > is happening here / or how I might fix my probelm, > would be greatly appreciated. > > Does anyone know of any code that carries out PCI > probing similar to that found on x86 PC's ? The boot code on our mips boards, whether some version of pmon or yamon does that initialization. The powerpc guys have implemented pci scanning scheme that allows the kernel to complete initialize pretty much arbitrarily complex pci bus systems with pci-to-pci bridges etc. I hope I'll have time to someday port that to mips. I don't think you can wait till then :-) Are you really trying to assign 0xC000 0000 to the card or was that just an example address? Unless your pci to memory window is such that there's a translation that occurs, that address is incorrect. If the window is 1:1, the physical address 0xC000 0000 does not exist. You need to assign the card a real physical address; if your system has 32MB of memory, than that address would have to be between 0 and 0x2000000. (well, you can't give it address "0" because of interrupt vectors, but you get the point). I can point you to some examples if you have problems. Pete From owner-linux-mips@oss.sgi.com Thu May 10 10:22:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AHM5Y06849 for linux-mips-outgoing; Thu, 10 May 2001 10:22:05 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AHM4F06846 for ; Thu, 10 May 2001 10:22:04 -0700 Received: from rose.sonytel.be (rose.sonytel.be [10.17.0.5]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id TAA03417; Thu, 10 May 2001 19:21:38 +0200 (MET DST) Date: Thu, 10 May 2001 19:20:54 +0200 (MET DST) From: Geert Uytterhoeven To: Pete Popov cc: Wayne Gowcher , linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board In-Reply-To: <3AFACBC8.DE85A67E@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1061 Lines: 23 On Thu, 10 May 2001, Pete Popov wrote: > Are you really trying to assign 0xC000 0000 to the card or was that just > an example address? Unless your pci to memory window is such that > there's a translation that occurs, that address is incorrect. If the > window is 1:1, the physical address 0xC000 0000 does not exist. You > need to assign the card a real physical address; if your system has 32MB > of memory, than that address would have to be between 0 and 0x2000000. > (well, you can't give it address "0" because of interrupt vectors, but > you get the point). I can point you to some examples if you have > problems. If you have 32 MB of RAM and you put a PCI card at an address between 0 and 0x2000000 you'll have a problem! PCI cards must not overlap with real memory. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Thu May 10 10:47:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AHlDV07903 for linux-mips-outgoing; Thu, 10 May 2001 10:47:13 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AHlCF07900 for ; Thu, 10 May 2001 10:47:12 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4AHka014392; Thu, 10 May 2001 10:46:36 -0700 Message-ID: <3AFAD368.9B70E1D5@mvista.com> Date: Thu, 10 May 2001 10:44:08 -0700 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, bg MIME-Version: 1.0 To: Wayne Gowcher CC: Geert Uytterhoeven , linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1253 Lines: 24 Geert Uytterhoeven wrote: > > On Thu, 10 May 2001, Pete Popov wrote: > > Are you really trying to assign 0xC000 0000 to the card or was that just > > an example address? Unless your pci to memory window is such that > > there's a translation that occurs, that address is incorrect. If the > > window is 1:1, the physical address 0xC000 0000 does not exist. You > > need to assign the card a real physical address; if your system has 32MB > > of memory, than that address would have to be between 0 and 0x2000000. > > (well, you can't give it address "0" because of interrupt vectors, but > > you get the point). I can point you to some examples if you have > > problems. > > If you have 32 MB of RAM and you put a PCI card at an address between 0 and > 0x2000000 you'll have a problem! PCI cards must not overlap with real memory. Sorry Wayne, I'm working on an ethernet driver and was thinking of descriptors and data buffers for PCI ethernet cards, which have to be in real physical memory. Geert is right, but 0xC000 0000 still seems suspicious. That's a very high physical address and pci devices are usually mapped at lower addresses. Something like 0x2000 0000 is more reasonable and makes accessing the card through kseg1 possible. Pete From owner-linux-mips@oss.sgi.com Thu May 10 10:53:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AHrdl08564 for linux-mips-outgoing; Thu, 10 May 2001 10:53:39 -0700 Received: from web11904.mail.yahoo.com (web11904.mail.yahoo.com [216.136.172.188]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4AHrdF08561 for ; Thu, 10 May 2001 10:53:39 -0700 Message-ID: <20010510175339.83183.qmail@web11904.mail.yahoo.com> Received: from [209.243.184.191] by web11904.mail.yahoo.com; Thu, 10 May 2001 10:53:39 PDT Date: Thu, 10 May 2001 10:53:39 -0700 (PDT) From: Wayne Gowcher Subject: Re: Configuration of PCI Video card on a BIOS-less board To: Geert Uytterhoeven , Pete Popov Cc: linux-mips@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1254 Lines: 35 Geert, Pete, Thanks for your input, it makes me question things I should have questioned before. 0xC000 0000 is the actual address I am trying to use. I used it because another PCI card that I have a driver for was using it and so I just carried on its use. I didnt really question the value or its use. But obviously it works for that card. After your emails I revisited that code and now I partially understand why it works. The chip has an internal bus that translates address requests internally. So when i write to 0xC000 0000 it would never make to the actual address lines of the chip and instead be routed to the PCI controller ( I think :) ) The original card i had a problem had an ATI Rage chip. I am now experimenting with a VGA card with a Cirrus Logic chip. I've got this card to accept the programmed base address and am in teh process of studying clgenfb.c to see if I can modify it to my needs. On first inspection clgenfb.c is written for the Amiga??? and so I am trying to weed out the dependencies. If anyone knows of a more generic driver it would be much appreciated. Wayne __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-linux-mips@oss.sgi.com Thu May 10 11:09:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AI91o09067 for linux-mips-outgoing; Thu, 10 May 2001 11:09:01 -0700 Received: from straylight.cyberhqz.com (root@h24-78-251-235.vc.shawcable.net [24.78.251.235]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AI90F09064 for ; Thu, 10 May 2001 11:09:00 -0700 Received: (from rmurray@localhost) by straylight.cyberhqz.com (8.9.3/8.9.3/Debian 8.9.3-21) id LAA10011; Thu, 10 May 2001 11:08:47 -0700 Date: Thu, 10 May 2001 11:08:47 -0700 From: Ryan Murray To: "Steven J. Hill" Cc: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010510110847.A2799@cyberhqz.com> References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <3AF934AE.38AB0089@cotw.com>; from sjhill@cotw.com on Wed, May 09, 2001 at 07:14:38AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2525 Lines: 77 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 09, 2001 at 07:14:38AM -0500, Steven J. Hill wrote: > Florian Lohoff wrote: > >=20 > > > > The whole point was to switch from our IRIX ELF flavoured binaries = to > > > > standard ABI ELF. These two variants are close but not identical w= hich > > > > for example made modutils missbehave. > > > > I will expound a bit more. When I made the changes to fix binutils and sw= itch > us from the IRIX to ABI ELF flavoured binaries the default target names > changed from 'elf[32|64][little|big]mips' to 'elf[32|64]trad[little|big]m= ips' > in binutils. This has the effect of breaking linker scripts but not a who= le > lot else. These will be the new targets for MIPS/Linux work. Binaries sho= uld > still run just fine if you compile glibc-2.2.2 with the old or new tools. > Future work though should use the 'elf[32|64]trad[little|big]mips' target= s. So, in summary: * all existing binaries do not need to be recompiled, and should continue to work. (shlibs included?) * all new binaries should use the new formats. To get the new targets working correctly: * new binutils * new gcc built with new binutils (does the 2.95.4 branch have the changes= , or only 3.0?) * new libc built with new gcc * rebuild gcc with the new libc Am I missing anything? > > > Is anybody working on a solution, or are we waiting for the debian pe= ople > > > to rebuild all the packages? > >=20 > You bet your ass they are in CVS. The Debian MIPS people? That would be F= lo > and Jason M. I believe. I'm getting ready to start a flame war (well I ho= pe > not, but it has potential) on the debian-mips list right after this email. > You might want to hop up there and read that if you are interested. > > I'll lean back, continue building .debs and wait for others to fix it. > > > And this is the problem Flo. Hop up to debian-mips and lets talk. atm, I'm not building any packages, waiting for this to be resolved. --=20 Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own. --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6+tkuN2Dbz/1mRasRAtNwAJkBAT+/nlmQCVZ0hMh43+R8w4w3xQCfYvhK rRxmRrO6zetdyJj6NcWXR74= =ZpGp -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-linux-mips@oss.sgi.com Thu May 10 11:15:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AIFu209509 for linux-mips-outgoing; Thu, 10 May 2001 11:15:56 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AIFtF09506 for ; Thu, 10 May 2001 11:15:55 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4AIFN016469; Thu, 10 May 2001 11:15:23 -0700 Message-ID: <3AFADA29.674BA111@mvista.com> Date: Thu, 10 May 2001 11:12:57 -0700 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, bg MIME-Version: 1.0 To: Wayne Gowcher CC: Geert Uytterhoeven , linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board References: <20010510175339.83183.qmail@web11904.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1570 Lines: 36 Wayne Gowcher wrote: > > Geert, Pete, > > Thanks for your input, it makes me question things I > should have questioned before. > 0xC000 0000 is the actual address I am trying to use. > I used it because another PCI card that I have a > driver for was using it and so I just carried on its > use. I didnt really question the value or its use. But > obviously it works for that card. And this driver works on mips? When you read the base mem register from this card that works, it says "0xC0000000"? > After your emails I revisited that code and now I > partially understand why it works. The chip has an > internal bus that translates address requests > internally. So when i write to 0xC000 0000 it would > never make to the actual address lines of the chip and > instead be routed to the PCI controller ( I think :) ) I'm not clear on how this works with the good driver. If you write to 0xC000 0000, that's a mips virtual address in the kseg2 region, which is a mapped region. So what physical address you put on the bus when you write to 0xC000 0000 depends on the tlb entry you've setup. If 0xC000 0000 is truly a PCI memory physical address, then you need to setup a tlb entry that maps some virtual address to the physical address 0xC000 0000. I doubt you want to muck with that and would suggest you redo your PCI bus memory map so that the PCI bus is at a lower address, like 0x1000 0000. You can then access physical 0x1000 0000 through virtual address 0xB000 0000 (kseg1). I think you already told me, but what board/CPU are you working with? Pete From owner-linux-mips@oss.sgi.com Thu May 10 11:23:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AINU109917 for linux-mips-outgoing; Thu, 10 May 2001 11:23:30 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AINQF09912; Thu, 10 May 2001 11:23:26 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4AIBQ016225; Thu, 10 May 2001 11:11:26 -0700 Message-ID: <3AFAD9E8.EC4D6D80@mvista.com> Date: Thu, 10 May 2001 11:11:53 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: lift the ioport_resource limit ... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1180 Lines: 26 "Maciej W. Rozycki" wrote: > > On Wed, 9 May 2001, Jun Sun wrote: > > > The PCI IO space essentially extends the ISA bus, which effectively removes > > the 0xffff limits. > > Note that while there is usually no problem with using addresses beyond > 64kB in the PCI I/O space, certain PCI-to-PCI bridges may not pass such > accesses across. So it's best to avoid assigning and using them. That's > why Linux remaps "high" I/O space resources on Alpha, which get set up for > some systems by the SRM console (firmware), e.g. in the system I was using > a few years ago, SRM used to assign addresses around 0x11000 and 0x12000 > for the onboard network and SCSI devices, IIRC. > I would not normally assign IO space above 0xffff either. But recently I found multiple PCI buses, especially dual PCI buses, are getting popular, as examplified by two Gallelio chips and the new NEC Vrc5477 chips. Since all drivers share the same mips_io_port_base, - even though the devices may be on different PCI buses - we need to assign the PCI IO windows contiguously so that drivers can share the same base address. In most such setups, you will get more than 0xffff IO ranges. Jun From owner-linux-mips@oss.sgi.com Thu May 10 11:29:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AITvb10250 for linux-mips-outgoing; Thu, 10 May 2001 11:29:57 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AITtF10247 for ; Thu, 10 May 2001 11:29:56 -0700 Received: from rose.sonytel.be (rose.sonytel.be [10.17.0.5]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id UAA05139; Thu, 10 May 2001 20:24:23 +0200 (MET DST) Date: Thu, 10 May 2001 20:23:41 +0200 (MET DST) From: Geert Uytterhoeven To: Wayne Gowcher cc: Pete Popov , linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board In-Reply-To: <20010510175339.83183.qmail@web11904.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 932 Lines: 24 On Thu, 10 May 2001, Wayne Gowcher wrote: > The original card i had a problem had an ATI Rage > chip. I am now experimenting with a VGA card with a > Cirrus Logic chip. I've got this card to accept the > programmed base address and am in teh process of > studying clgenfb.c to see if I can modify it to my > needs. > On first inspection clgenfb.c is written for the > Amiga??? and so I am trying to weed out the > dependencies. If anyone knows of a more generic driver > it would be much appreciated. Clgenfb supports both Amiga Zorro cards with a Cirrus Logic chip and PCI cards. Note that it may depend on some chip initialisation already been done. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Thu May 10 11:43:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AIhZE10761 for linux-mips-outgoing; Thu, 10 May 2001 11:43:35 -0700 Received: from web11903.mail.yahoo.com (web11903.mail.yahoo.com [216.136.172.187]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4AIhYF10758 for ; Thu, 10 May 2001 11:43:34 -0700 Message-ID: <20010510184334.71405.qmail@web11903.mail.yahoo.com> Received: from [209.243.184.191] by web11903.mail.yahoo.com; Thu, 10 May 2001 11:43:34 PDT Date: Thu, 10 May 2001 11:43:34 -0700 (PDT) From: Wayne Gowcher Subject: Re: Configuration of PCI Video card on a BIOS-less board To: Pete Popov Cc: linux-mips@oss.sgi.com In-Reply-To: <3AFADA29.674BA111@mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 605 Lines: 22 Pete, I think I am in "dopey" mode this morning. The 0xC000 0000 I was talking about comes from another board I was working on recently that mapped a comapnion chip into kseg2 space. It seems it's been burnt into my brain :( The working PCI card is actually mapped to 0xA200 0000, and I am using that for the VGA card. My comments about the address translation were totally wrong. Sorry for any confusion. Time for a coffee and a long rethink :) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-linux-mips@oss.sgi.com Thu May 10 13:15:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AKFbw13097 for linux-mips-outgoing; Thu, 10 May 2001 13:15:37 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AKFaF13094 for ; Thu, 10 May 2001 13:15:36 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id 689B9F1A9; Thu, 10 May 2001 13:14:31 -0700 (PDT) Date: Thu, 10 May 2001 13:14:31 -0700 From: Keith M Wesolowski To: Pete Popov Cc: Wayne Gowcher , Geert Uytterhoeven , linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board Message-ID: <20010510131431.A27228@foobazco.org> References: <20010510175339.83183.qmail@web11904.mail.yahoo.com> <3AFADA29.674BA111@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFADA29.674BA111@mvista.com>; from ppopov@mvista.com on Thu, May 10, 2001 at 11:12:57AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1890 Lines: 39 On Thu, May 10, 2001 at 11:12:57AM -0700, Pete Popov wrote: > I'm not clear on how this works with the good driver. If you write to > 0xC000 0000, that's a mips virtual address in the kseg2 region, which is > a mapped region. So what physical address you put on the bus when you > write to 0xC000 0000 depends on the tlb entry you've setup. If 0xC000 > 0000 is truly a PCI memory physical address, then you need to setup a Repeat after me until done: BAR values have nothing to do with CPU addresses. If your PCI bus happens to map PCI memory location 0 onto physical address 0, then they are the same. That's almost certainly not the case. Otherwise, an address in a BAR is the *PCI bus address*, NOT a CPU physical address. A simple example: a PCI bridge exists in a system. It is wired into the CPU address bus such that it responds to 0x18000000-0x19ffffff physical. On the other side of the bridge, it maps 0x00000000-0x7fffffff bus addresses onto physical memory (for DMA), and 0x80000000-0xffffffff onto PCI memory space (for PIO). The bridge translates addresses such that: bus_address_for_BARs == 0x80000000 + (cpu_physical_address - 0x18000000) bus_address_for_DMA == cpu_physical_address and, of course, cpu_virtual_address_for_pointers == KSEG[01]ADDR (cpu_physical_address) In the example above, the PCI bus is mapped into CPU memory such that it can be accessed via ksegX, which is normal. If it were mapped at, for example, 0x40000000, that would not be the case and you would need a TLB entry. Note that for mips64, you can use KPHYS to access any physical address; ie it need not be below 0x20000000. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Thu May 10 14:11:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ALBfW14665 for linux-mips-outgoing; Thu, 10 May 2001 14:11:41 -0700 Received: from bvdexchange.eicon.com (firewall.i-data.com [195.24.22.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ALBdF14662 for ; Thu, 10 May 2001 14:11:39 -0700 Received: from eicon.com (172.16.2.231 [172.16.2.231]) by bvdexchange.eicon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id KVL8PZQ1; Thu, 10 May 2001 23:12:27 +0200 Message-ID: <3AFB03F6.7A3C7847@eicon.com> Date: Thu, 10 May 2001 23:11:18 +0200 From: "Tommy S. Christensen" X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: shay@jungo.com CC: linux-mips@oss.sgi.com, michaels@jungo.com Subject: Re: No bss cause strange values in insmod and ELF References: <01051009104509.01140@athena.home.krftech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1533 Lines: 41 Shay Deloya wrote: > > Continuing my previous problem... > > I have created a module with no bss , and compiled it with kernel 2.2. > Comparing this module with same code that has bss and acts OK. > > Inserting the module with modutiles 2.2.2/ busybox insmod causes > a relocation overflow message , the reasons are: > > 1.in function obj_relocate: corrupted intsym->secidx value > (not the needed index in the ELF) > for some .text segments, other segments get their index value OK. > the ELF file seems to be OK. > 2. in function arch_apply_relocation: the wrong index (secidx=1006a1e8) > cause R_MIPS_26 symbols (jump commands) to have the value of > obj_reloc_overflow and then causes relocation overflow. > > Does anyone knows why same module that has a variable in bss acts fine > and the one without bss causes Relocation overflow in MIPS ? (in x86 there > is no problem). > > Searching the code I see there is no initialization of the secidx , > is it a problem of wrong reading of ELF files by insmod ? > > Attached the two ELF files , and obj_relocate values. > I had a look at the attachments and I think the cause of your problem is that the module is not a relocatable file! ld can fix this for you. Try ld -r -o new.o .o, and then insert new.o instead. Regarding the effect of empty/non-empty .bss section (and of recompiling modutils), I think this is just a case of "fix by accident". Meaning that it's still broke - it just didn't die (this time). Regards, Tommy Christensen From owner-linux-mips@oss.sgi.com Thu May 10 14:18:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ALIpe15075 for linux-mips-outgoing; Thu, 10 May 2001 14:18:51 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ALInF15072 for ; Thu, 10 May 2001 14:18:49 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4ALI9028100; Thu, 10 May 2001 14:18:09 -0700 Message-ID: <3AFB04FF.353198C6@mvista.com> Date: Thu, 10 May 2001 14:15:43 -0700 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, bg MIME-Version: 1.0 To: Keith M Wesolowski CC: Wayne Gowcher , Geert Uytterhoeven , linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board References: <20010510175339.83183.qmail@web11904.mail.yahoo.com> <3AFADA29.674BA111@mvista.com> <20010510131431.A27228@foobazco.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2301 Lines: 45 Keith M Wesolowski wrote: > > On Thu, May 10, 2001 at 11:12:57AM -0700, Pete Popov wrote: > > > I'm not clear on how this works with the good driver. If you write to > > 0xC000 0000, that's a mips virtual address in the kseg2 region, which is > > a mapped region. So what physical address you put on the bus when you > > write to 0xC000 0000 depends on the tlb entry you've setup. If 0xC000 > > 0000 is truly a PCI memory physical address, then you need to setup a > Repeat after me until done: BAR values have nothing to do with CPU > addresses. If your PCI bus happens to map PCI memory location 0 onto > physical address 0, then they are the same. That's almost certainly > not the case. Otherwise, an address in a BAR is the *PCI bus > address*, NOT a CPU physical address. Wayne's email indicated, if I understood it correctly, that he is trying to access the card's registers by writing to 0xC000 0000, after he has written 0xC000 0000 to the BAR. That address cannot be an address that the host to pci controller understands as PCI memory address because it overlaps with kseg2. So if 0xC000 0000 is the correct address to write in the BAR, then he needs to access the card's registers through the PCI mem region that looks something like your example below. But if his memory map is 1:1, then 0xC000 0000 is the wrong value to write to that register. > A simple example: a PCI bridge exists in a system. It is wired into > the CPU address bus such that it responds to 0x18000000-0x19ffffff > physical. On the other side of the bridge, it maps > 0x00000000-0x7fffffff bus addresses onto physical memory (for DMA), > and 0x80000000-0xffffffff onto PCI memory space (for PIO). The bridge > translates addresses such that: > bus_address_for_BARs == 0x80000000 + (cpu_physical_address - 0x18000000) > bus_address_for_DMA == cpu_physical_address > and, of course, > cpu_virtual_address_for_pointers == KSEG[01]ADDR (cpu_physical_address) > In the example above, the PCI bus is mapped into CPU memory such that > it can be accessed via ksegX, which is normal. If it were mapped at, > for example, 0x40000000, that would not be the case and you would need > a TLB entry. Note that for mips64, you can use KPHYS to access any > physical address; ie it need not be below 0x20000000. From owner-linux-mips@oss.sgi.com Thu May 10 15:02:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AM2cS16159 for linux-mips-outgoing; Thu, 10 May 2001 15:02:38 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AM2cF16156 for ; Thu, 10 May 2001 15:02:38 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4AM24030912; Thu, 10 May 2001 15:02:04 -0700 Message-ID: <3AFB0FF6.D84A491E@mvista.com> Date: Thu, 10 May 2001 15:02:30 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith M Wesolowski CC: Pete Popov , Wayne Gowcher , Geert Uytterhoeven , linux-mips@oss.sgi.com Subject: Re: Configuration of PCI Video card on a BIOS-less board References: <20010510175339.83183.qmail@web11904.mail.yahoo.com> <3AFADA29.674BA111@mvista.com> <20010510131431.A27228@foobazco.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2557 Lines: 56 Keith M Wesolowski wrote: > > On Thu, May 10, 2001 at 11:12:57AM -0700, Pete Popov wrote: > > > I'm not clear on how this works with the good driver. If you write to > > 0xC000 0000, that's a mips virtual address in the kseg2 region, which is > > a mapped region. So what physical address you put on the bus when you > > write to 0xC000 0000 depends on the tlb entry you've setup. If 0xC000 > > 0000 is truly a PCI memory physical address, then you need to setup a > > Repeat after me until done: BAR values have nothing to do with CPU > addresses. If your PCI bus happens to map PCI memory location 0 onto > physical address 0, then they are the same. That's almost certainly > not the case. Otherwise, an address in a BAR is the *PCI bus > address*, NOT a CPU physical address. > Keith, What you said is right in theory. However not correct in practice. Most drivers read BAR address (in PCI memory space) and do ioremap() to get (usually uncached) virtual address to access the PCI memory region. On mips, the default ioremap() essentially does 1 to 1 mapping from PCI meory space to physical address space and then further maps it into KSEG1. That pretty much mandates each MIPS port must maintain 1:1 mapping between the PCI memory space and CPU physical space - unless you enjoy the fun of hacking with PCI fixups. > A simple example: a PCI bridge exists in a system. It is wired into > the CPU address bus such that it responds to 0x18000000-0x19ffffff > physical. On the other side of the bridge, it maps > 0x00000000-0x7fffffff bus addresses onto physical memory (for DMA), > and 0x80000000-0xffffffff onto PCI memory space (for PIO). The bridge > translates addresses such that: > > bus_address_for_BARs == 0x80000000 + (cpu_physical_address - 0x18000000) > bus_address_for_DMA == cpu_physical_address > > and, of course, > > cpu_virtual_address_for_pointers == KSEG[01]ADDR (cpu_physical_address) > > In the example above, the PCI bus is mapped into CPU memory such that > it can be accessed via ksegX, which is normal. If it were mapped at, > for example, 0x40000000, that would not be the case and you would need > a TLB entry. Note that for mips64, you can use KPHYS to access any > physical address; ie it need not be below 0x20000000. > > -- > Keith M Wesolowski http://foobazco.org/~wesolows > ------(( Project Foobazco Coordinator and Network Administrator ))------ > "Nothing motivates a man more than to see his boss put > in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Thu May 10 15:29:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AMTbJ17225 for linux-mips-outgoing; Thu, 10 May 2001 15:29:37 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AMTYF17222 for ; Thu, 10 May 2001 15:29:35 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4AKKIj06232; Thu, 10 May 2001 17:20:18 -0300 Date: Thu, 10 May 2001 17:20:18 -0300 From: Ralf Baechle To: Jun Sun Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: lift the ioport_resource limit ... Message-ID: <20010510172018.A6188@bacchus.dhis.org> References: <3AFAD9E8.EC4D6D80@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFAD9E8.EC4D6D80@mvista.com>; from jsun@mvista.com on Thu, May 10, 2001 at 11:11:53AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1261 Lines: 25 On Thu, May 10, 2001 at 11:11:53AM -0700, Jun Sun wrote: > I would not normally assign IO space above 0xffff either. But recently I > found multiple PCI buses, especially dual PCI buses, are getting popular, as > examplified by two Gallelio chips and the new NEC Vrc5477 chips. > > Since all drivers share the same mips_io_port_base, - even though the devices > may be on different PCI buses - we need to assign the PCI IO windows > contiguously so that drivers can share the same base address. In most such > setups, you will get more than 0xffff IO ranges. After some discussion with some of the Linux PCI guys I think we should try to avoid extend the per-bus I/O address space beyond 64k ports. This is not a very strong ``should avoid'', though. The primary concern is a number of broken peripheral chips which apparently are floating around out there in good numbers. Another reason to not extend the PCI-bus address range to 4g ports is the size of the available physical address space in the main processor's address space itself. Limited by the 32-bit address space we can only address a limited number via in/out anyway, so we better shouldn't fake what we ain't got (cited freely after Seymoure Cray), so 4g ports is silly anyway. Ralf From owner-linux-mips@oss.sgi.com Thu May 10 15:29:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AMTrf17352 for linux-mips-outgoing; Thu, 10 May 2001 15:29:53 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AMTpF17320 for ; Thu, 10 May 2001 15:29:51 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4AIkdP01574; Thu, 10 May 2001 15:46:39 -0300 Date: Thu, 10 May 2001 15:46:39 -0300 From: Ralf Baechle To: Michael Shmulevich Cc: Shay Deloya , linux-mips@oss.sgi.com Subject: Re: insmod problems Message-ID: <20010510154639.B1269@bacchus.dhis.org> References: <01050619134301.01140@athena.home.krftech.com> <20010508234036.A1216@bacchus.dhis.org> <3AFA56F8.9090504@jungo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFA56F8.9090504@jungo.com>; from michaels@jungo.com on Thu, May 10, 2001 at 11:53:12AM +0300 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 732 Lines: 17 On Thu, May 10, 2001 at 11:53:12AM +0300, Michael Shmulevich wrote: > On the same topic: same source (!!) 'insmod' executable compiled with > new (2.10) binutils doesn't exibit such relocation problem. > > What may be causing 'insmod' to be dependant on binutils which compile > it? The module *.o is exactly same as it was before. Without further explanation this one just sounds bizarre for now. There always have been differences between the code generated by binutils in the various versions; the resulting changes may result in different behaviour of a broken programs. These are fun to debug to say the least. The other possibility would be binutils bugs but I'm not aware of one with the effect you described. Ralf From owner-linux-mips@oss.sgi.com Thu May 10 15:29:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AMToq17301 for linux-mips-outgoing; Thu, 10 May 2001 15:29:50 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AMTmF17295 for ; Thu, 10 May 2001 15:29:48 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4AJMLc04324; Thu, 10 May 2001 16:22:21 -0300 Date: Thu, 10 May 2001 16:22:21 -0300 From: Ralf Baechle To: Ryan Murray Cc: "Steven J. Hill" , linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010510162221.A1736@bacchus.dhis.org> References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <20010510110847.A2799@cyberhqz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010510110847.A2799@cyberhqz.com>; from rmurray@debian.org on Thu, May 10, 2001 at 11:08:47AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 556 Lines: 19 On Thu, May 10, 2001 at 11:08:47AM -0700, Ryan Murray wrote: > So, in summary: > * all existing binaries do not need to be recompiled, and should > continue to work. (shlibs included?) > * all new binaries should use the new formats. > > To get the new targets working correctly: > * new binutils > * new gcc built with new binutils (does the 2.95.4 branch have the > changes, or only 3.0?) > * new libc built with new gcc > * rebuild gcc with the new libc > > Am I missing anything? The latter three steps are not necessary. Ralf From owner-linux-mips@oss.sgi.com Thu May 10 17:19:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4B0J6520236 for linux-mips-outgoing; Thu, 10 May 2001 17:19:06 -0700 Received: from web11901.mail.yahoo.com (web11901.mail.yahoo.com [216.136.172.185]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4B0J5F20233 for ; Thu, 10 May 2001 17:19:05 -0700 Message-ID: <20010511001905.41656.qmail@web11901.mail.yahoo.com> Received: from [209.243.184.191] by web11901.mail.yahoo.com; Thu, 10 May 2001 17:19:05 PDT Date: Thu, 10 May 2001 17:19:05 -0700 (PDT) From: Wayne Gowcher Subject: Re: Configuration of PCI Video card on a BIOS-less board To: Jun Sun , Keith M Wesolowski Cc: Pete Popov , Wayne Gowcher , Geert Uytterhoeven , linux-mips@oss.sgi.com In-Reply-To: <3AFB0FF6.D84A491E@mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1379 Lines: 42 Guys, Sorry for all the confusion, and subsequent traffic as a result of my mistakes. I'm still feeling my way with regards to programming the PCI and have mixed up terms and addresses. Just for the record : In actual fact the PCI code is writing physical addresses to the Base Address Register, eg 0x02000000. Then later on when the driver is initialising itself it reads the BAR and adds on KSEG1 : dev->base_addr = KSEG1ADDR(base_addr); It is this "dev->base_addr" that gets reported to me on boot up ( 0xA2000000 ) as being the base address of the device. The 0xC000 0000 I wrote in my first mail was from another problem I had been working and was somehow burned into my brain. There is nothing like someone questioning one's assumptions to make one re-evaluate those assumptions. For this I am grateful to those people, for spotting the gaping whole of my mistake and bringing it to my attention. For me at least it has been very useful in that respect. I still would like to understand PCI issues more particularly with respect to so called "legacy PCi devices" VGA, sound card etc. So if anyone would like to mail me off the list with tips / reading they have found useful, it would be most appreciated. Wayne __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-linux-mips@oss.sgi.com Fri May 11 00:56:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4B7uvA29973 for linux-mips-outgoing; Fri, 11 May 2001 00:56:57 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B7utF29970 for ; Fri, 11 May 2001 00:56:55 -0700 Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA03865 for ; Fri, 11 May 2001 09:56:41 +0200 (MET DST) Received: (from tea@localhost) by ginger.sonytel.be (8.9.0/8.8.6) id JAA08516 for linux-mips@oss.sgi.com; Fri, 11 May 2001 09:56:28 +0200 (MET DST) Date: Fri, 11 May 2001 09:56:28 +0200 From: Tom Appermont To: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010511095628.D8495@sonycom.com> References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <20010510110847.A2799@cyberhqz.com> <20010510162221.A1736@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010510162221.A1736@bacchus.dhis.org>; from ralf@oss.sgi.com on Thu, May 10, 2001 at 04:22:21PM -0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 505 Lines: 19 > > To get the new targets working correctly: > > * new binutils > > * new gcc built with new binutils (does the 2.95.4 branch have the > > changes, or only 3.0?) > > * new libc built with new gcc > > * rebuild gcc with the new libc > > > > Am I missing anything? > > The latter three steps are not necessary. To avoid any further confusion, which then are the versions ( & patches ) of binutils / gcc / libc needed to get a linux mips toolchain we can use until the end of time? Tom From owner-linux-mips@oss.sgi.com Fri May 11 02:26:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4B9Qwx32264 for linux-mips-outgoing; Fri, 11 May 2001 02:26:58 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B9QwF32261 for ; Fri, 11 May 2001 02:26:58 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id C94A0F1A9; Fri, 11 May 2001 02:25:52 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 6A28D1F42B; Fri, 11 May 2001 02:26:27 -0700 (PDT) Date: Fri, 11 May 2001 02:26:27 -0700 From: Keith M Wesolowski To: Tom Appermont Cc: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010511022627.A17202@foobazco.org> References: <20010505144708.A12575@paradigm.rfc822.org> <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <20010510110847.A2799@cyberhqz.com> <20010510162221.A1736@bacchus.dhis.org> <20010511095628.D8495@sonycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010511095628.D8495@sonycom.com>; from tea@sonycom.com on Fri, May 11, 2001 at 09:56:28AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1286 Lines: 28 On Fri, May 11, 2001 at 09:56:28AM +0200, Tom Appermont wrote: > To avoid any further confusion, which then are the versions > ( & patches ) of binutils / gcc / libc needed to get a > linux mips toolchain we can use until the end of time? I routinely publish just such a thing at oss.sgi.com:/pub/linux/mips/mips-linux/simple/crossdev. Many others publish similar toolchains regularly - see the list archives for pointers. None of them have expiration dates; you are free to use them forever. If you never change software you'll never lose binary compatibility. Likewise, you'll never get any bug fixes or new features either. If you mean a set of tools and libraries with which everything in the future will always be binary compatible, we should talk - I have a very attractive bridge I'm looking to get rid of. Binary compatibility is irrelevant in a source-enabled world and exists only long enough to make sure the previous release that broke compatibility finishes compiling before the next such release comes out. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Fri May 11 03:42:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BAgdt01391 for linux-mips-outgoing; Fri, 11 May 2001 03:42:39 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BAgbF01388 for ; Fri, 11 May 2001 03:42:37 -0700 Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id MAA13216; Fri, 11 May 2001 12:42:36 +0200 (MET DST) Received: (from tea@localhost) by ginger.sonytel.be (8.9.0/8.8.6) id MAA13864; Fri, 11 May 2001 12:42:35 +0200 (MET DST) Date: Fri, 11 May 2001 12:42:35 +0200 From: Tom Appermont To: Keith M Wesolowski Cc: linux-mips@oss.sgi.com Subject: Re: Binary compatibility break understood ? Message-ID: <20010511124235.E8495@sonycom.com> References: <20010507163210.B2381@bacchus.dhis.org> <20010508202518.A13476@paradigm.rfc822.org> <20010508214313.A12528@bacchus.dhis.org> <20010509095955.A8392@sonycom.com> <20010509104635.D12267@paradigm.rfc822.org> <3AF934AE.38AB0089@cotw.com> <20010510110847.A2799@cyberhqz.com> <20010510162221.A1736@bacchus.dhis.org> <20010511095628.D8495@sonycom.com> <20010511022627.A17202@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010511022627.A17202@foobazco.org>; from wesolows@foobazco.org on Fri, May 11, 2001 at 02:26:27AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1539 Lines: 37 > > To avoid any further confusion, which then are the versions > > ( & patches ) of binutils / gcc / libc needed to get a > > linux mips toolchain we can use until the end of time? > > I routinely publish just such a thing at > oss.sgi.com:/pub/linux/mips/mips-linux/simple/crossdev. Many others Thanks for the pointer. Any reason why the tar files are not compressed? > publish similar toolchains regularly - see the list archives for > pointers. Sorry for asking for a bit of clarity on this. There are indeed many others publishing their own cross-dev toolchains on their ftp site. So far it has not been easy for me to find the version that I need, i.e. a version that compiles the latest linux/mips cvs tree on solaris. Too many versions, too many patches, and no central repository for tools have caused me too many headaches. How naive I was when I started from the webpage "How to build a cross compiler for Linux/MIPS" (I use the mirror at http://www.village.org/villagers/imp/build.html), looking desperately for the files that are referenced there .... > None of them have expiration dates; you are free to use > them forever. If you never change software you'll never lose binary > compatibility. Likewise, you'll never get any bug fixes or new > features either. I was not being serious, I know it is unthinkable to be using the same version forever. I just hope there will come a time where I can spend more time on actually using the tools than trying to solve the problems I have with them. Greetz, Tom From owner-linux-mips@oss.sgi.com Fri May 11 04:53:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BBriI02822 for linux-mips-outgoing; Fri, 11 May 2001 04:53:44 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BBrhF02819 for ; Fri, 11 May 2001 04:53:43 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id GAA03395; Fri, 11 May 2001 06:53:41 -0500 Message-ID: <3AFBD5DE.A0457C6F@cotw.com> Date: Fri, 11 May 2001 07:06:54 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19pre17-idepci i686) X-Accept-Language: en MIME-Version: 1.0 To: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: glibc MIPS patch to check for binutils version... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2705 Lines: 74 Greetings. Please find attached a patch to GLIBC that is compatible with the new version of binutils (HJLu's and CVS at least). I have also added some cruft in 'configure.in' that will produce warning messages if a user attempt to use old binutils. Comments are welcome. I have gone out on a limb and also included a Changelog entry in case this patch actually gets accepted :). This patch will apply against the CVS version of GLIBC. Please regenerate 'configure'. Thanks. -Steve ***** Changelog entry ***** * sysdeps/mips/rtld-ldscript.in: removed unneeded binary output format directive * configure.in: added in checking for obsolete binutils for MIPS targets which produces a warning message if user attempts to use older tools. *************************** ******* START PATCH ******* diff -urN glibc-2.2.3/configure.in glibc-2.2.3-patched/configure.in --- glibc-2.2.3/configure.in Wed Apr 25 16:50:58 2001 +++ glibc-2.2.3-patched/configure.in Thu May 10 23:09:24 2001 @@ -590,6 +590,29 @@ AC_SUBST(cross_compiling) AC_PROG_CPP LIBC_PROG_BINUTILS + +# For MIPS targets, we need to check that the proper version of +# binutils is being used and warn that old binary compatability +# may be broken. --sjhill +case "$host_alias" in +mips*-linux) + echo $ac_n "checking versions of GNU assembler and linker... $ac_c" 1>&6 + ac_prog_version=`$AS -o conftest -v &1 | sed -n 's/^.*version \( [0-9.]*\).*$/\1/p'` + case $ac_prog_version in + '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; + 2.11.90.0.[5-9]*|2.11.[2-9]|2.1[2-9]*) + ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; + *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; + esac + echo "$ac_t""$ac_prog_version" 1>&6 + if test $ac_verc_fail = yes; then + echo "configure: warning: +*** These are older versions of the GNU linker and assembler +*** for MIPS targets. You should seriously consider upgrading +*** your tools or risk producing incompatible binaries." 1>&2 + fi +esac + AC_CHECK_TOOL(MIG, mig) # Accept binutils 2.10.1 or newer (and also any ia64 2.9 version) diff -urN glibc-2.2.3/sysdeps/mips/rtld-ldscript.in glibc-2.2.3-patched/sysdeps/ mips/rtld-ldscript.in --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in Sat Jul 12 18:23:14 1997 +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in Fri May 11 06:34:52 2001 @@ -1,4 +1,3 @@ -OUTPUT_FORMAT("@@rtld-oformat@@") OUTPUT_ARCH(@@rtld-arch@@) ENTRY(@@rtld-entry@@) SECTIONS ******* END PATCH ******* -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Fri May 11 06:08:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BD8Xb04188 for linux-mips-outgoing; Fri, 11 May 2001 06:08:33 -0700 Received: from mail.kdt.de (mail.kdt.de [195.8.224.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BD8WF04185 for ; Fri, 11 May 2001 06:08:32 -0700 Received: from arthur.inka.de (arthur.kdt.de [195.8.250.5]) by mail.kdt.de (8.11.1/8.11.0) with ESMTP id f4BD8CU31549; Fri, 11 May 2001 15:08:13 +0200 Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.inka.de with esmtp (Exim 3.14 #1) id 14yCeF-0002Nq-00; Fri, 11 May 2001 15:07:59 +0200 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 2B40C1EA2E; Fri, 11 May 2001 15:07:57 +0200 (CEST) Mail-Copies-To: never To: sjhill@cotw.com Cc: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: glibc MIPS patch to check for binutils version... References: <3AFBD5DE.A0457C6F@cotw.com> From: Andreas Jaeger Date: 11 May 2001 15:07:57 +0200 In-Reply-To: <3AFBD5DE.A0457C6F@cotw.com> ("Steven J. Hill"'s message of "Fri, 11 May 2001 07:06:54 -0500") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2006 Lines: 64 "Steven J. Hill" writes: > Greetings. > > Please find attached a patch to GLIBC that is compatible with > the new version of binutils (HJLu's and CVS at least). I have > also added some cruft in 'configure.in' that will produce > warning messages if a user attempt to use old binutils. Comments > are welcome. I have gone out on a limb and also included a > Changelog entry in case this patch actually gets accepted :). > This patch will apply against the CVS version of GLIBC. Please > regenerate 'configure'. Thanks. > > -Steve > > > ***** Changelog entry ***** > * sysdeps/mips/rtld-ldscript.in: removed unneeded binary > output format directive Ok. > * configure.in: added in checking for obsolete binutils > for MIPS targets which produces a warning message if > user attempts to use older tools. > *************************** Let's do this differently. I'm appending a patch that does it more the "glibc way". I've committed everything to CVS including a patch for the FAQ. I hope I got the version numbers right. Thanks, Andreas 2001-05-11 Andreas Jaeger * sysdeps/unix/sysv/linux/configure.in: Check binutils version on MIPS. ============================================================ Index: sysdeps/unix/sysv/linux/configure.in --- sysdeps/unix/sysv/linux/configure.in 2001/03/16 07:35:59 1.37 +++ sysdeps/unix/sysv/linux/configure.in 2001/05/11 12:58:25 @@ -191,3 +191,14 @@ AC_MSG_RESULT(ok) fi fi + +case "$machine" in + mips*) + AC_CHECK_PROG_VER(AS, $AS, --version, + [GNU assembler.* \([0-9]*\.[0-9.]*\(-ia64-[0-9]*\)*\)], + [2.11.90.0.[5-9]* | 2.11.90.[1-9]* | 2.11.9[1-9]* | 2.11.[1-9]* | 2.1[2-9]*| 2.[2-9]*], + AC_MSG_WARN([*** Your binutils versions are too old. +*** We strongly advise to update binutils. For details check +*** the FAQ and INSTALL documents.])) + ;; +esac -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Fri May 11 07:12:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BECIc05987 for linux-mips-outgoing; Fri, 11 May 2001 07:12:18 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BECIF05984 for ; Fri, 11 May 2001 07:12:18 -0700 Received: from cotw.com (dhcp-050.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id JAA03907; Fri, 11 May 2001 09:05:06 -0500 Message-ID: <3AFBF4A7.20F3D739@cotw.com> Date: Fri, 11 May 2001 09:18:15 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19pre17-idepci i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Jaeger CC: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: glibc MIPS patch to check for binutils version... References: <3AFBD5DE.A0457C6F@cotw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 727 Lines: 21 Andreas Jaeger wrote: > > > * configure.in: added in checking for obsolete binutils > > for MIPS targets which produces a warning message if > > user attempts to use older tools. > > *************************** > > Let's do this differently. I'm appending a patch that does it more > the "glibc way". I've committed everything to CVS including a patch > for the FAQ. I hope I got the version numbers right. > Oh sure...my patch wasn't good enough :). I checked your addition to the FAQ and it is correct. Thanks a lot Andreas. Cheers. -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Fri May 11 08:55:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BFt1e09225 for linux-mips-outgoing; Fri, 11 May 2001 08:55:01 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BFt0F09222 for ; Fri, 11 May 2001 08:55:00 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 1F166125BA; Fri, 11 May 2001 08:54:58 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 00D67EC13; Fri, 11 May 2001 08:54:15 -0700 (PDT) Date: Fri, 11 May 2001 08:54:15 -0700 From: "H . J . Lu" To: "Steven J. Hill" Cc: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: glibc MIPS patch to check for binutils version... Message-ID: <20010511085415.A1486@lucon.org> References: <3AFBD5DE.A0457C6F@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFBD5DE.A0457C6F@cotw.com>; from sjhill@cotw.com on Fri, May 11, 2001 at 07:06:54AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 551 Lines: 14 On Fri, May 11, 2001 at 07:06:54AM -0500, Steven J. Hill wrote: > ***** Changelog entry ***** > * sysdeps/mips/rtld-ldscript.in: removed unneeded binary > output format directive I don't believe those rtld-ldscript.in and rtld-parms are needed for the new MIPS toolchain at all. They may cause more trouble than without. Could you please tell me what breaks when you remove them? There is a chance that the old binaries compiled against glibc 2.0.x may run with the new glibc 2.2 without those linker scripts for the IRIX ABI. H.J. From owner-linux-mips@oss.sgi.com Fri May 11 09:27:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BGRbd10144 for linux-mips-outgoing; Fri, 11 May 2001 09:27:37 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BGR4F10128 for ; Fri, 11 May 2001 09:27:05 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA10230; Fri, 11 May 2001 18:26:51 +0200 (MET DST) Date: Fri, 11 May 2001 18:26:51 +0200 (MET DST) From: "Maciej W. Rozycki" To: Andreas Jaeger cc: sjhill@cotw.com, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: glibc MIPS patch to check for binutils version... In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 493 Lines: 16 On 11 May 2001, Andreas Jaeger wrote: > 2001-05-11 Andreas Jaeger > > * sysdeps/unix/sysv/linux/configure.in: Check binutils version on > MIPS. Wouldn't it be cleaner if the check was placed in sysdeps/unix/sysv/linux/mips/configure.in instead, like it's done for Alpha? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri May 11 09:47:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BGlVb10850 for linux-mips-outgoing; Fri, 11 May 2001 09:47:31 -0700 Received: from mail.kdt.de (mail.kdt.de [195.8.224.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BGlTF10846 for ; Fri, 11 May 2001 09:47:29 -0700 Received: from arthur.inka.de (arthur.kdt.de [195.8.250.5]) by mail.kdt.de (8.11.1/8.11.0) with ESMTP id f4BGl5U00904; Fri, 11 May 2001 18:47:05 +0200 Received: from gromit.moeb ([192.168.27.3] ident=postfix) by arthur.inka.de with esmtp (Exim 3.14 #1) id 14yG21-0004C7-00; Fri, 11 May 2001 18:44:45 +0200 Received: by gromit.moeb (Postfix, from userid 207) id 55EB41EA2E; Fri, 11 May 2001 18:44:44 +0200 (CEST) Mail-Copies-To: never To: "Maciej W. Rozycki" Cc: sjhill@cotw.com, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: glibc MIPS patch to check for binutils version... References: From: Andreas Jaeger Date: 11 May 2001 18:44:44 +0200 In-Reply-To: ("Maciej W. Rozycki"'s message of "Fri, 11 May 2001 18:26:51 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 523 Lines: 22 "Maciej W. Rozycki" writes: > On 11 May 2001, Andreas Jaeger wrote: > > > 2001-05-11 Andreas Jaeger > > > > * sysdeps/unix/sysv/linux/configure.in: Check binutils version on > > MIPS. > > Wouldn't it be cleaner if the check was placed in > sysdeps/unix/sysv/linux/mips/configure.in instead, like it's done for > Alpha? That would be better - I'll move it later, Thanks, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Sat May 12 11:44:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4CIitG07959 for linux-mips-outgoing; Sat, 12 May 2001 11:44:55 -0700 Received: from e67205.upc-e.chello.nl (e67205.upc-e.chello.nl [213.93.67.205]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CIisF07956 for ; Sat, 12 May 2001 11:44:54 -0700 Received: by e67205.upc-e.chello.nl (Postfix, from userid 1000) id 699361C2E7; Sat, 12 May 2001 20:44:01 +0200 (CEST) Date: Sat, 12 May 2001 20:44:01 +0200 From: peter.zijlstra@chello.nl To: linux-mips@oss.sgi.com Subject: Where to start with a R4000 Indigo Message-ID: <20010512204401.D6072@e67205.upc-e.chello.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 749 Lines: 21 Hi,. I recently acquired a R4000 50MHz Indigo without an IRIX install nor CD with it. No CD-Rom player either, however I did order one, network however does seem to work. And as I am a linux fanatic and professional programmer myself I would like to see whether I could help a bit with bringing linux to this system. As Indigo support isn't finished and I have nothing but a bare BIOS to start with; and have no experience with the machine to begin with; I have to ask for _help_ :) Where do I start reading and tinkering to get linux; for as far as it's sort of running; on my system ? Are there any specs for the machine, especially for those parts that need most urgent development and which parts are that ? kind regards, Peter Zijlstra From owner-linux-mips@oss.sgi.com Sat May 12 12:38:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4CJcJw08878 for linux-mips-outgoing; Sat, 12 May 2001 12:38:19 -0700 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CJcIF08875 for ; Sat, 12 May 2001 12:38:18 -0700 Received: from [192.168.1.3] (h00104b670a0d.ne.mediaone.net [65.96.137.220]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f4CJbb829180; Sat, 12 May 2001 15:37:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: mjpento@pop.ne.mediaone.net Message-Id: In-Reply-To: <20010512204401.D6072@e67205.upc-e.chello.nl> References: <20010512204401.D6072@e67205.upc-e.chello.nl> Date: Sat, 12 May 2001 15:39:24 -0400 To: peter.zijlstra@chello.nl From: mjpento Subject: Re: Where to start with a R4000 Indigo Cc: linux-mips@oss.sgi.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2706 Lines: 63 Hi Peter, I am in the same boat as you essentially, only I am a little worse off. I own 2 Indigo R3000's and would love to see a port of Linux or NetBSD or something of that nature done for the machine, but alas, I fear that if I don't start one on my architecture there may never be a port to the R3000. There is some hope for you. I believe someone on this list told me a while back that a port is being developed by someone to the R4000 Indigo, someone here might be able to shed some more light on that for you as I have no idea who is doing that. There is also the Plan 9 effort, which is an OS that is/was being developed by AT&T that supports the R4000 and maybe even the R3000. You may be able to get information about the architecture of the Indigo from this code. I have been unsuccessful in this respect, but, maybe you will have better luck than I. Here are some Plan 9 links to get you started: http://www.vitanuova.com/plan9/ http://www.fywss.com/plan9/plan9faq.html As far as getting information from SGI, I wouldn't bother with that, as anyone else in here would agree. The chances of them giving you any information are slim to none. The expense of having someone at SGI pull documentation for the Indigo (if it even still exists) is too high. So, architecture information and specifications are very hard to come by. I am thinking about *attempting* to start a port of some linux distribution to the R3000, but I have to admit, the task seems a bit daunting. On other platforms, this is difficult with the proper documentation. You may also want to take a look at the Linux/MIPS page and check out the Indy port, which is the only functional Linux port to the SGI platform that I am aware of. I hope that some of this information will help you out. Remember to try the MIPS website also as there may be some useful bits of data there that will shed some light for you. Thanks, Mike >Hi,. > >I recently acquired a R4000 50MHz Indigo without an IRIX install nor CD >with it. No CD-Rom player either, however I did order one, network however >does seem to work. And as I am a linux fanatic and professional programmer >myself I would like to see whether I could help a bit with bringing linux to >this system. > >As Indigo support isn't finished and I have nothing but a bare BIOS >to start with; and have no experience with the machine to begin with; >I have to ask for _help_ :) > >Where do I start reading and tinkering to get linux; for as far as it's >sort of running; on my system ? > >Are there any specs for the machine, especially for those parts that need >most urgent development and which parts are that ? > > >kind regards, > Peter Zijlstra From owner-linux-mips@oss.sgi.com Sat May 12 13:13:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4CKDpM09405 for linux-mips-outgoing; Sat, 12 May 2001 13:13:51 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CKDoF09402 for ; Sat, 12 May 2001 13:13:50 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4CKDm020012; Sat, 12 May 2001 13:13:48 -0700 Message-ID: <3AFD98E5.9090907@mvista.com> Date: Sat, 12 May 2001 13:11:17 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i586; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: en MIME-Version: 1.0 To: peter.zijlstra@chello.nl CC: linux-mips@oss.sgi.com Subject: Re: Where to start with a R4000 Indigo References: <20010512204401.D6072@e67205.upc-e.chello.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1075 Lines: 28 peter.zijlstra@chello.nl wrote: >Hi,. > >I recently acquired a R4000 50MHz Indigo without an IRIX install nor CD >with it. No CD-Rom player either, however I did order one, network however >does seem to work. And as I am a linux fanatic and professional programmer >myself I would like to see whether I could help a bit with bringing linux to >this system. > >As Indigo support isn't finished and I have nothing but a bare BIOS >to start with; and have no experience with the machine to begin with; >I have to ask for _help_ :) > >Where do I start reading and tinkering to get linux; for as far as it's >sort of running; on my system ? > >Are there any specs for the machine, especially for those parts that need >most urgent development and which parts are that ? > Are you sure this system is an Indigo and not an Indigo2? I thought the Indigo's are R3000 based and the Indigo2 is R4000 based. If it's an Indigo2, linux already runs on it. I've got our HardHat Linux 2.0 booting and running of the hard drive. There's also a port of RedHat7.1. on oss.sgi.com. Pete From owner-linux-mips@oss.sgi.com Sat May 12 13:27:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4CKR6809735 for linux-mips-outgoing; Sat, 12 May 2001 13:27:06 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CKR5F09732 for ; Sat, 12 May 2001 13:27:05 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 207F5F1A9; Sat, 12 May 2001 13:25:57 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 942381F42B; Sat, 12 May 2001 13:26:32 -0700 (PDT) Date: Sat, 12 May 2001 13:26:32 -0700 From: Keith M Wesolowski To: Pete Popov Cc: peter.zijlstra@chello.nl, linux-mips@oss.sgi.com Subject: Re: Where to start with a R4000 Indigo Message-ID: <20010512132632.B3092@foobazco.org> References: <20010512204401.D6072@e67205.upc-e.chello.nl> <3AFD98E5.9090907@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFD98E5.9090907@mvista.com>; from ppopov@mvista.com on Sat, May 12, 2001 at 01:11:17PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 641 Lines: 14 On Sat, May 12, 2001 at 01:11:17PM -0700, Pete Popov wrote: > Are you sure this system is an Indigo and not an Indigo2? I thought the > Indigo's are R3000 based and the Indigo2 is R4000 based. If it's an Indigo initially had R3000 and later had R4000, offered as both an upgrade board and a new system. Indigo2 came with various R4000 and R4400 CPUs (and then R8k and R10k later). -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Sat May 12 13:43:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4CKhcQ10199 for linux-mips-outgoing; Sat, 12 May 2001 13:43:38 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CKhaF10196 for ; Sat, 12 May 2001 13:43:36 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id WAA49438 for ; Sat, 12 May 2001 22:43:35 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 14ygEg-00009c-00 for ; Sat, 12 May 2001 22:43:34 +0200 Date: Sat, 12 May 2001 22:43:34 +0200 To: linux-mips@oss.sgi.com Subject: Re: Where to start with a R4000 Indigo Message-ID: <20010512224334.B371@rembrandt.csv.ica.uni-stuttgart.de> References: <20010512204401.D6072@e67205.upc-e.chello.nl> <3AFD98E5.9090907@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3AFD98E5.9090907@mvista.com>; from ppopov@mvista.com on Sat, May 12, 2001 at 01:11:17PM -0700 From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 277 Lines: 10 Pete Popov wrote: [snip] >Are you sure this system is an Indigo and not an Indigo2? I thought the >Indigo's are R3000 based and the Indigo2 is R4000 based. There were both R3000 and R4000 based Indigos (and a R4400 upgrade). The Indigo2 is at least a R4400 Machine. Thiemo From owner-linux-mips@oss.sgi.com Sat May 12 18:52:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4D1qiW14517 for linux-mips-outgoing; Sat, 12 May 2001 18:52:44 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D1qiF14514 for ; Sat, 12 May 2001 18:52:44 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id AFDF7F1A9 for ; Sat, 12 May 2001 18:51:36 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 64B301F42B; Sat, 12 May 2001 18:52:11 -0700 (PDT) Date: Sat, 12 May 2001 18:52:11 -0700 From: Keith M Wesolowski To: linux-mips@oss.sgi.com Subject: SGI O2 Port Message-ID: <20010512185211.C3092@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1323 Lines: 39 Hi, I'd like to encourage anyone interested in an SGI O2 port to try my current CVS tree. I have successfully reached userland with this tree. If you have an O2, please try this and let me know how it goes, then send patches for all the broken stuff. Note: This is a 64-bit port. You will need a mips64 toolchain to compile. Known problems: - Without CONFIG_UNCACHED, the PCI devices don't work properly - Userland console I/O is very slow and seems unreliable - Onboard ethernet isn't yet supported; you'll need a PCI one - Serial console only at this time - The disks probably work, but I haven't really tested them Links Boot log: http://foobazco.org/~wesolows/o2.txt Toolchain: ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev Sources: :pserver:cvs@cvs.foobazco.org:/g/cvs mod linux pass cvs Thanks: - Harald Koerfgen, for starting the 32-bit port. Some of his code still remains. - Nick Brisebois, for the loan of an O2, assistance with documentation, and lots of other stuff. - The usual suspects, for providing the basis for all this. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Sun May 13 08:26:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4DFQZM25460 for linux-mips-outgoing; Sun, 13 May 2001 08:26:35 -0700 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DFQYF25457 for ; Sun, 13 May 2001 08:26:34 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id RAA29875 for ; Sun, 13 May 2001 17:26:32 +0200 Received: (from karel@localhost) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) id RAA02985 for linux-mips@oss.sgi.com; Sun, 13 May 2001 17:26:32 +0200 (MET DST) From: Karel van Houten Message-Id: <200105131526.RAA02985@sparta.research.kpn.com> Subject: Tuxfinder To: linux-mips@oss.sgi.com Date: Sun, 13 May 2001 17:26:32 +0200 (MET DST) X-Url: http://www-lsdm.research.kpn.com/~karel X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 470 Lines: 16 Hi all, I've mailed with the maintainer of tuxfinder, and he has added support for mips.rpm and mipsel.rpm to the tuxfinder page. A great tool for finding linux software. Have a look at http://www.tuxfinder.com Regards, -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Sun May 13 11:54:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4DIsXc28095 for linux-mips-outgoing; Sun, 13 May 2001 11:54:33 -0700 Received: from straylight.cyberhqz.com (root@h24-78-251-235.vc.shawcable.net [24.78.251.235]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DIsVF28092 for ; Sun, 13 May 2001 11:54:31 -0700 Received: (from rmurray@localhost) by straylight.cyberhqz.com (8.9.3/8.9.3/Debian 8.9.3-21) id LAA00363 for linux-mips@oss.sgi.com; Sun, 13 May 2001 11:54:31 -0700 Date: Sun, 13 May 2001 11:54:31 -0700 From: Ryan Murray To: linux-mips@oss.sgi.com Subject: backwards compatible ld.so patch Message-ID: <20010513115431.A342@cyberhqz.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1041 Lines: 36 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Attached is a patch that changes the MAP_BASE_ADDR macro to one that Dan mentioned in his question about a backwards-compatible change to ld.so that allows both new and old shlibs to run. This seems to work -- I've run perl (with an old-binutils libperl.so), with a new-binutils built ld.so and libc.so, and it works fine. The comment abo= ve the change should probably be updated to indicate the new state of things, as well... Comments? --=20 Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own. --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6/thmN2Dbz/1mRasRAl4VAJ9wvDpaAHxnkfF6rZ9bXgpXAmIcrwCg1dwE dmIRs4J/3WVnpXNpAannvm8= =EGvf -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-linux-mips@oss.sgi.com Sun May 13 12:23:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4DJNQk28661 for linux-mips-outgoing; Sun, 13 May 2001 12:23:26 -0700 Received: from straylight.cyberhqz.com (root@h24-78-251-235.vc.shawcable.net [24.78.251.235]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DJNPF28658 for ; Sun, 13 May 2001 12:23:25 -0700 Received: (from rmurray@localhost) by straylight.cyberhqz.com (8.9.3/8.9.3/Debian 8.9.3-21) id MAA00509 for linux-mips@oss.sgi.com; Sun, 13 May 2001 12:23:21 -0700 Date: Sun, 13 May 2001 12:23:21 -0700 From: Ryan Murray To: linux-mips@oss.sgi.com Subject: Re: backwards compatible ld.so patch Message-ID: <20010513122321.B342@cyberhqz.com> References: <20010513115431.A342@cyberhqz.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010513115431.A342@cyberhqz.com>; from rmurray@debian.org on Sun, May 13, 2001 at 11:54:31AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1592 Lines: 55 --w7PDEPdKQumQfZlR Content-Type: multipart/mixed; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable And, of course, the actual patch....:) --=20 Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own. --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mips-shlib.patch" Content-Transfer-Encoding: quoted-printable --- sysdeps/mips/dl-machine.h Sun May 13 22:25:35 2001 +++ sysdeps/mips/dl-machine.h Sun May 13 22:28:14 2001 @@ -71,12 +71,7 @@ * libraries have their base address at 0x5ffe0000. This needs to be * fixed before we can safely get rid of this MIPSism. */ -#if 0 -#define MAP_BASE_ADDR(l) ((l)->l_info[DT_MIPS(BASE_ADDRESS)] ? \ - (l)->l_info[DT_MIPS(BASE_ADDRESS)]->d_un.d_ptr : 0) -#else -#define MAP_BASE_ADDR(l) 0x5ffe0000 -#endif +#define MAP_BASE_ADDR(l) ((l)->l_addr >=3D 0x5ffe0000 ? 0x5ffe0000 : 0) =20 /* If there is a DT_MIPS_RLD_MAP entry in the dynamic section, fill it in with the run-time address of the r_debug structure */ --Y7xTucakfITjPcLV-- --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6/t8pN2Dbz/1mRasRAvy0AKCBEcysCs7ewhIamLl79BeZ7e6zHwCfeWvQ BD8Iu9Ei6eEmpQf7kAzxM0g= =bTJi -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From owner-linux-mips@oss.sgi.com Mon May 14 05:04:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EC4Tt10317 for linux-mips-outgoing; Mon, 14 May 2001 05:04:29 -0700 Received: from ninigret.metatel.office ([63.148.55.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EC4SF10314 for ; Mon, 14 May 2001 05:04:28 -0700 Received: from ninigret.metatel.office (IDENT:rafal@localhost.metatel.office [127.0.0.1]) by ninigret.metatel.office (8.9.3/8.8.8) with ESMTP id IAA19260; Mon, 14 May 2001 08:04:11 -0400 Message-Id: <200105141204.IAA19260@ninigret.metatel.office> From: Rafal Boni To: Keith M Wesolowski Cc: linux-mips@oss.sgi.com Subject: Re: SGI O2 Port In-reply-to: Your message of "Sat, 12 May 2001 18:52:11 PDT." <20010512185211.C3092@foobazco.org> X-Mailer: NMH 1.0 / EXMH 2.0.3 Date: Mon, 14 May 2001 08:04:11 -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 759 Lines: 19 In message <20010512185211.C3092@foobazco.org>, Keith writes: -> I'd like to encourage anyone interested in an SGI O2 port to try my -> current CVS tree. I have successfully reached userland with this -> tree. If you have an O2, please try this and let me know how it goes, -> then send patches for all the broken stuff. What CPU's are supported currently? Just the R5000, or are the R10k/R12k supported as well? (I realize that the latter two are harder to support, but thought I'd ask nevertheless). Thanks, --rafal ---- Rafal Boni rafal.boni@eDial.com PGP key C7D3024C, print EA49 160D F5E4 C46A 9E91 524E 11E0 7133 C7D3 024C Need to get a hold of me? http://800.edial.com/rafal.boni@eDial.com From owner-linux-mips@oss.sgi.com Mon May 14 05:16:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ECG6f11023 for linux-mips-outgoing; Mon, 14 May 2001 05:16:06 -0700 Received: from ninigret.metatel.office ([63.148.55.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ECG5F11018 for ; Mon, 14 May 2001 05:16:05 -0700 Received: from ninigret.metatel.office (IDENT:rafal@localhost.metatel.office [127.0.0.1]) by ninigret.metatel.office (8.9.3/8.8.8) with ESMTP id IAA19297; Mon, 14 May 2001 08:15:48 -0400 Message-Id: <200105141215.IAA19297@ninigret.metatel.office> From: Rafal Boni To: mjpento Cc: peter.zijlstra@chello.nl, linux-mips@oss.sgi.com Subject: Re: Where to start with a R4000 Indigo In-reply-to: Your message of "Sat, 12 May 2001 15:39:24 EDT." X-Mailer: NMH 1.0 / EXMH 2.0.3 Date: Mon, 14 May 2001 08:15:48 -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2233 Lines: 47 In message , Mike writes: -> I am in the same boat as you essentially, only I am a little -> worse off. I own 2 Indigo R3000's and would love to see a port of -> Linux or NetBSD or something of that nature done for the machine, but -> alas, I fear that if I don't start one on my architecture there may -> never be a port to the R3000. Quick note re: NetBSD: If you get the hardware support going, there is already R3000 support in the tree, so the port to the R3000 Indigo should be no harder than the one to the R4000 Indigo. -> There is also the Plan 9 effort, which is an OS that is/was -> being developed by AT&T that supports the R4000 and maybe even the -> R3000. You may be able to get information about the architecture of -> the Indigo from this code. I have been unsuccessful in this respect, -> but, maybe you will have better luck than I. Here are some Plan 9 -> links to get you started: -> -> http://www.vitanuova.com/plan9/ -> http://www.fywss.com/plan9/plan9faq.html If you've been unsuccessful in finding the Plan9 Indigo code, I have been told it's only available on CD, and if any/either of you is interested in it, I will try and track down the info for ordering it and/or confirming that it contains useful info (I know someone who just ordered it to help with a NetBSD port to the Indigo). -> As far as getting information from SGI, I wouldn't bother -> with that, as anyone else in here would agree. The chances of them -> giving you any information are slim to none. The expense of having -> someone at SGI pull documentation for the Indigo (if it even still -> exists) is too high. So, architecture information and specifications -> are very hard to come by. Agreed. I've been told (and have no reason to disbelieve) that the primary issue is making sure the docs are unencumbered by third-party IPR before being released and since this involves both technical people and lawyers, it can't be cheap. --rafal ---- Rafal Boni rafal.boni@eDial.com PGP key C7D3024C, print EA49 160D F5E4 C46A 9E91 524E 11E0 7133 C7D3 024C Need to get a hold of me? http://800.edial.com/rafal.boni@eDial.com From owner-linux-mips@oss.sgi.com Mon May 14 08:11:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EFBFj14554 for linux-mips-outgoing; Mon, 14 May 2001 08:11:15 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFBEF14551 for ; Mon, 14 May 2001 08:11:14 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id D8400F1A9; Mon, 14 May 2001 08:10:03 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id E47471F42B; Mon, 14 May 2001 08:10:39 -0700 (PDT) Date: Mon, 14 May 2001 08:10:39 -0700 From: Keith M Wesolowski To: Rafal Boni Cc: linux-mips@oss.sgi.com Subject: Re: SGI O2 Port Message-ID: <20010514081039.B18935@foobazco.org> References: <20010512185211.C3092@foobazco.org> <200105141204.IAA19260@ninigret.metatel.office> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105141204.IAA19260@ninigret.metatel.office>; from rafal.boni@eDial.com on Mon, May 14, 2001 at 08:04:11AM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 857 Lines: 18 On Mon, May 14, 2001 at 08:04:11AM -0400, Rafal Boni wrote: > What CPU's are supported currently? Just the R5000, or are the R10k/R12k > supported as well? (I realize that the latter two are harder to support, > but thought I'd ask nevertheless). I have never built it for anything but r5k. It's very likely that 52x0 will also run fine. In theory r10k/r12k should work. In practice, however, I suspect that differences in the crime controllers will make it impossible to boot; I can probably fix that. As we run uncached only at this time anyway, the spec writes thing should not be an issue. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Mon May 14 12:16:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EJGqK20161 for linux-mips-outgoing; Mon, 14 May 2001 12:16:52 -0700 Received: from smtp3.ev1.net (smtpout.ev1.net [207.218.192.47]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EJGpF20158 for ; Mon, 14 May 2001 12:16:51 -0700 Received: from ev1.net [207.218.202.179] by smtp3.ev1.net with ESMTP (SMTPD32-6.06) id AF47A82A008A; Mon, 14 May 2001 14:17:27 -0500 Message-ID: <3B0030FA.AE9B334C@ev1.net> Date: Mon, 14 May 2001 14:24:42 -0500 From: Jason Brock X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Mips cross-compiler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 94 Lines: 3 When is there going to be a Linux version Mips Cross-Compiler for the VR4122 (Casio EM-500)? From owner-linux-mips@oss.sgi.com Mon May 14 14:06:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EL63R23257 for linux-mips-outgoing; Mon, 14 May 2001 14:06:03 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EL5xF23241 for ; Mon, 14 May 2001 14:06:00 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4EKatq09936; Mon, 14 May 2001 17:36:55 -0300 Date: Mon, 14 May 2001 17:36:55 -0300 From: Ralf Baechle To: Ryan Murray Cc: linux-mips@oss.sgi.com Subject: Re: backwards compatible ld.so patch Message-ID: <20010514173655.A9383@bacchus.dhis.org> References: <20010513115431.A342@cyberhqz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010513115431.A342@cyberhqz.com>; from rmurray@debian.org on Sun, May 13, 2001 at 11:54:31AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 750 Lines: 20 On Sun, May 13, 2001 at 11:54:31AM -0700, Ryan Murray wrote: > Attached is a patch that changes the MAP_BASE_ADDR macro to one that Dan > mentioned in his question about a backwards-compatible change to ld.so > that allows both new and old shlibs to run. > > This seems to work -- I've run perl (with an old-binutils libperl.so), with > a new-binutils built ld.so and libc.so, and it works fine. The comment above > the change should probably be updated to indicate the new state of things, > as well... > > Comments? Wrong. You're replacing a hack with something even more evil. Right thing would be to make sure that the dynamic table is loaded before MAP_BASE_ADDR gets dereferenced; then you can reactivate the commented out code. Ralf From owner-linux-mips@oss.sgi.com Mon May 14 14:05:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EL5g923174 for linux-mips-outgoing; Mon, 14 May 2001 14:05:42 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EL5cF23169 for ; Mon, 14 May 2001 14:05:39 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4EKsux10013; Mon, 14 May 2001 17:54:56 -0300 Date: Mon, 14 May 2001 17:54:55 -0300 From: Ralf Baechle To: Keith M Wesolowski Cc: Rafal Boni , linux-mips@oss.sgi.com Subject: Re: SGI O2 Port Message-ID: <20010514175455.B9383@bacchus.dhis.org> References: <20010512185211.C3092@foobazco.org> <200105141204.IAA19260@ninigret.metatel.office> <20010514081039.B18935@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514081039.B18935@foobazco.org>; from wesolows@foobazco.org on Mon, May 14, 2001 at 08:10:39AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 705 Lines: 16 On Mon, May 14, 2001 at 08:10:39AM -0700, Keith M Wesolowski wrote: > > What CPU's are supported currently? Just the R5000, or are the R10k/R12k > > supported as well? (I realize that the latter two are harder to support, > > but thought I'd ask nevertheless). > > I have never built it for anything but r5k. It's very likely that > 52x0 will also run fine. In theory r10k/r12k should work. In > practice, however, I suspect that differences in the crime controllers > will make it impossible to boot; I can probably fix that. As we run > uncached only at this time anyway, the spec writes thing should not be > an issue. Only an issue for R10k; R12k and beyond are sane in that respect. Ralf From owner-linux-mips@oss.sgi.com Mon May 14 16:35:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ENZR227074 for linux-mips-outgoing; Mon, 14 May 2001 16:35:27 -0700 Received: from sprint02.rtmx.net (IDENT:qmailr@sprint02.RTMX.NET [208.31.160.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4ENZQF27071 for ; Mon, 14 May 2001 16:35:26 -0700 Received: (qmail 2054 invoked by uid 102); 14 May 2001 23:35:24 -0000 Received: from host098.momenco.com (HELO beagle) (64.169.228.98) by 208.31.160.29 with SMTP; 14 May 2001 23:35:24 -0000 From: "Matthew Dharm" To: "Linux-MIPS" , "Ralf Baechle" Subject: PATCH: Momentum Computer Ocelot: Making the latest CVS tree build Date: Mon, 14 May 2001 16:35:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01C0DC93.EBC1BE20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2654 Lines: 86 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0DC93.EBC1BE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached is a patch against the latest CVS tree (as of about 3 hours ago). It makes the Momentum Computer Ocelot board build again -- apparently, some of the PCI code has been changed. It seems likely to me that this is not the best way to do this patch... if it's unacceptable to the powers that be (Ralf?), could someone point out to me the new convention for board-specific PCI initialization? Matt Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com ------=_NextPart_000_0014_01C0DC93.EBC1BE20 Content-Type: application/octet-stream; name="mydiff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mydiff" --- arch/mips/gt64120/common/irq.c 2001/03/09 20:33:46 1.2=0A= +++ arch/mips/gt64120/common/irq.c 2001/05/14 23:25:01=0A= @@ -61,6 +61,7 @@=0A= #define DBG(x...)=0A= #endif=0A= =0A= +void (*irq_setup)(void);=0A= =0A= /*=0A= * Generic no controller code=0A= --- arch/mips/gt64120/momenco_ocelot/setup.c 2001/02/05 01:33:01 1.1=0A= +++ arch/mips/gt64120/momenco_ocelot/setup.c 2001/05/14 23:25:01=0A= @@ -77,7 +77,7 @@=0A= {=0A= unsigned int i, j;=0A= =0A= - irq_setup =3D momenco_ocelot_irq_setup;=0A= + irq_setup =3D momenco_ocelot_irq_setup; =0A= board_time_init =3D gt64120_time_init;=0A= =0A= mips_io_port_base =3D KSEG1;=0A= --- fs/ext2/inode.c 2001/04/05 04:58:29 1.34=0A= +++ fs/ext2/inode.c 2001/05/14 23:25:11=0A= @@ -568,7 +568,7 @@=0A= =0A= changed:=0A= while (partial > chain) {=0A= - bforget(partial->bh);=0A= + brelse(partial->bh);=0A= partial--;=0A= }=0A= goto reread;=0A= @@ -799,8 +799,8 @@=0A= /* Writer: ->i_blocks */=0A= inode->i_blocks -=3D blocks * count;=0A= /* Writer: end */=0A= - ext2_free_blocks (inode, block_to_free, count);=0A= mark_inode_dirty(inode);=0A= + ext2_free_blocks (inode, block_to_free, count);=0A= free_this:=0A= block_to_free =3D nr;=0A= count =3D 1;=0A= @@ -811,8 +811,8 @@=0A= /* Writer: ->i_blocks */=0A= inode->i_blocks -=3D blocks * count;=0A= /* Writer: end */=0A= - ext2_free_blocks (inode, block_to_free, count);=0A= mark_inode_dirty(inode);=0A= + ext2_free_blocks (inode, block_to_free, count);=0A= }=0A= }=0A= =0A= ------=_NextPart_000_0014_01C0DC93.EBC1BE20-- From owner-linux-mips@oss.sgi.com Mon May 14 18:15:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4F1FvM28933 for linux-mips-outgoing; Mon, 14 May 2001 18:15:57 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F1FpF28928 for ; Mon, 14 May 2001 18:15:53 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4F15Zx14778; Mon, 14 May 2001 22:05:35 -0300 Date: Mon, 14 May 2001 22:05:35 -0300 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: PATCH: Momentum Computer Ocelot: Making the latest CVS tree build Message-ID: <20010514220535.D9945@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Mon, May 14, 2001 at 04:35:43PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 614 Lines: 16 On Mon, May 14, 2001 at 04:35:43PM -0700, Matthew Dharm wrote: > Attached is a patch against the latest CVS tree (as of about 3 hours > ago). It makes the Momentum Computer Ocelot board build again -- > apparently, some of the PCI code has been changed. Except your patch doesn't even touch the PCI but interrupt code. > It seems likely to me that this is not the best way to do this > patch... if it's unacceptable to the powers that be (Ralf?), could > someone point out to me the new convention for board-specific PCI > initialization? Applied, but without the two extra junk segment in the patch. Ralf From owner-linux-mips@oss.sgi.com Tue May 15 02:48:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4F9msK05954 for linux-mips-outgoing; Tue, 15 May 2001 02:48:54 -0700 Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F9mpF05949 for ; Tue, 15 May 2001 02:48:52 -0700 Received: from murphy.dk (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4F9mhiQ026225 for ; Tue, 15 May 2001 11:48:45 +0200 Message-ID: <3B00FB7A.12AA394B@murphy.dk> Date: Tue, 15 May 2001 11:48:42 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Problem with module loading on a 2.4 kernel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 296 Lines: 14 When we try to load a module into a 2.4.3 kernel we get the following error: # insmod /lib/modules/ipchains.o insmod: kernel: QM_SYMBOLS: Unknown error 716862128 does anyone know what the matter here. The toolchain we use is based on the patched egcs-1.1.2 and binutils-2.8.1 at oss. /Brian From owner-linux-mips@oss.sgi.com Tue May 15 04:37:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4FBb3N08998 for linux-mips-outgoing; Tue, 15 May 2001 04:37:03 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FBb2F08994 for ; Tue, 15 May 2001 04:37:02 -0700 Received: from cotw.com (laptop1.inter.net [192.168.10.50]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id GAA19275; Tue, 15 May 2001 06:31:53 -0500 Message-ID: <3B0116BA.9CDA6C63@cotw.com> Date: Tue, 15 May 2001 06:44:58 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Brian Murphy CC: "linux-mips@oss.sgi.com" Subject: Re: Problem with module loading on a 2.4 kernel References: <3B00FB7A.12AA394B@murphy.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 655 Lines: 25 Brian Murphy wrote: > > When we try to load a module into a 2.4.3 kernel we get the following > error: > > # insmod /lib/modules/ipchains.o > insmod: kernel: QM_SYMBOLS: Unknown error 716862128 > > does anyone know what the matter here. > > The toolchain we use is based on the patched egcs-1.1.2 and > binutils-2.8.1 > at oss. > And thus your problem. You need a newer toolchain. The binutils and gcc out of CVS. For binutils you can also use HJ Lu's with version 2.11.90.0.5 or better. -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D From owner-linux-mips@oss.sgi.com Tue May 15 15:11:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4FMBYZ22710 for linux-mips-outgoing; Tue, 15 May 2001 15:11:34 -0700 Received: from bvdexchange.eicon.com (firewall.i-data.com [195.24.22.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FMBXF22707 for ; Tue, 15 May 2001 15:11:33 -0700 Received: from eicon.com (172.16.2.231 [172.16.2.231]) by bvdexchange.eicon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id KVL8PZX2; Wed, 16 May 2001 00:12:18 +0200 Message-ID: <3B01A980.7C27BB9F@eicon.com> Date: Wed, 16 May 2001 00:11:12 +0200 From: "Tommy S. Christensen" X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Exception handlers get overwritten Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1144 Lines: 42 With LOADADDR set to 0x80000000, except_vec0_r4600 and except_vec0_nevada are overwritten in trap_init() before they get installed at KSEG0. The fix is easy: diff -u -r1.53 traps.c --- arch/mips/kernel/traps.c 2001/04/08 13:24:27 1.53 +++ arch/mips/kernel/traps.c 2001/05/15 21:39:56 @@ -837,7 +837,9 @@ * Copy the EJTAG debug exception vector handler code to it's final * destination. */ +#ifdef WHONEEDSTLB memcpy((void *)(KSEG0 + 0x300), &except_vec_ejtag_debug, 0x80); +#endif /* * Only some CPUs have the watch exceptions or a dedicated OK, a kinder fix would be something like: diff -u -r1.25 head.S --- arch/mips/kernel/head.S 2001/05/04 20:43:25 1.25 +++ arch/mips/kernel/head.S 2001/05/15 21:39:40 @@ -44,7 +44,7 @@ * FIXME: Use the initcode feature to get rid of unused handler * variants. */ - .fill 0x280 + .fill 0x380 /* * This is space for the interrupt handlers. * After trap_init() they are located at virtual address KSEG0. I wonder why this never hit anybody else ... Regards, Tommy Christensen From owner-linux-mips@oss.sgi.com Tue May 15 16:44:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4FNin024262 for linux-mips-outgoing; Tue, 15 May 2001 16:44:49 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FNimF24259 for ; Tue, 15 May 2001 16:44:48 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA26137; Tue, 15 May 2001 16:44:39 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA00432; Tue, 15 May 2001 16:44:36 -0700 (PDT) Message-ID: <00bf01c0dd99$9c94b4e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Tommy S. Christensen" , References: <3B01A980.7C27BB9F@eicon.com> Subject: Re: Exception handlers get overwritten Date: Wed, 16 May 2001 01:48:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3542 Lines: 96 I don't know who checked in the EJTAG vector stuff, but a few words of explanation and advice are in order. MIPS32/MIPS64 CPUs have optional support for EJTAG, which introduces a "Debug" mode of execution which is similar to, but not identical to, Kernel mode. The only way into Debug mode is to take a Debug exception - not to be confused with a breakpoint or watchpoint exception. These are caused either by EJTAG hardware breakpoints being hit, or by an external assertion on the EJTAG interface. When the CPU enters Debug mode, it transfers either to a location in the EJTAG pseudo memory (an overlay of high physical memory that maps to packet transactions on the JTAG interface) or to the boot ROM vector area. They can never vector directly to the 0x80000000 page! Now, since the hardware breakpoint channels are potentially a cool feature to be able to exploit from an OS - they allow breakpoints in ROM code, for example - I once prototyped and debugged the necessary code in OpenBSD to allow the kernel to be invoked from a Debug exception, and to allow the kernel to "call down" into the Debug mode code to set breakpoints, etc.. To do this, one *must* have support in the boot ROM of the platform. The boot ROM exception vector can take advantage of the EJTAG scratch register to save enough context to transfer control, intact, to a pseudo-vector in the OS vector page (one of those rare occasions where the jump delay slot is a lifesaver). The location of that pseudo-vector is purely a software convention, and should be chosen to be beyond *any* hardware vectors, including those for the MIPS32/64 and Nevada dedicated hardware interrupt vectors. I've been meaning for some time now to re-implement the OpenBSD EJTAG hooks in Linux, but have simply never had the time. It sounds like someone else has started down that path without having looked at all the issues. I'll try to dig out my old example ROM vector code and post it to the newsgroup (it's only a few lines), along with the EJTAG kernel interface code from OpenBSD to serve as an example. Kevin K. ----- Original Message ----- From: "Tommy S. Christensen" To: Sent: Wednesday, May 16, 2001 12:11 AM Subject: Exception handlers get overwritten > With LOADADDR set to 0x80000000, except_vec0_r4600 and > except_vec0_nevada are overwritten in trap_init() before they > get installed at KSEG0. > > The fix is easy: > > diff -u -r1.53 traps.c > --- arch/mips/kernel/traps.c 2001/04/08 13:24:27 1.53 > +++ arch/mips/kernel/traps.c 2001/05/15 21:39:56 > @@ -837,7 +837,9 @@ > * Copy the EJTAG debug exception vector handler code to it's > final > * destination. > */ > +#ifdef WHONEEDSTLB > memcpy((void *)(KSEG0 + 0x300), &except_vec_ejtag_debug, 0x80); > +#endif > > /* > * Only some CPUs have the watch exceptions or a dedicated > > > OK, a kinder fix would be something like: > > diff -u -r1.25 head.S > --- arch/mips/kernel/head.S 2001/05/04 20:43:25 1.25 > +++ arch/mips/kernel/head.S 2001/05/15 21:39:40 > @@ -44,7 +44,7 @@ > * FIXME: Use the initcode feature to get rid of unused handler > * variants. > */ > - .fill 0x280 > + .fill 0x380 > /* > * This is space for the interrupt handlers. > * After trap_init() they are located at virtual address KSEG0. > > > I wonder why this never hit anybody else ... > > Regards, > Tommy Christensen From owner-linux-mips@oss.sgi.com Tue May 15 17:39:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4G0dIN25271 for linux-mips-outgoing; Tue, 15 May 2001 17:39:18 -0700 Received: from pobox.sibyte.com (pobox.sibyte.com [208.12.96.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G0dFF25267 for ; Tue, 15 May 2001 17:39:15 -0700 Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21]) by pobox.sibyte.com (Postfix) with SMTP id 8B9B5205FA for ; Tue, 15 May 2001 17:39:36 -0700 (PDT) Received: from SMTP agent by mail gateway Tue, 15 May 2001 17:30:46 -0800 Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 4E4B51595F for ; Tue, 15 May 2001 17:39:05 -0700 (PDT) Received: by plugh.sibyte.com (Postfix, from userid 61017) id E96A7686D; Tue, 15 May 2001 17:39:00 -0700 (PDT) From: Justin Carlson Reply-To: carlson@sibyte.com Organization: Sibyte To: linux-mips@oss.sgi.com Subject: mips64, _end, tools, and relocations Date: Tue, 15 May 2001 17:25:13 -0700 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01051517390007.00784@plugh.sibyte.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1498 Lines: 40 Taking a walk on the mips64 side of the world, I'm compiling with the i386-linux=>mips64-linux cross tools from the rpms at oss.sgi.com. Looking at the build process, we build at kseg0, then objcopy and relocate to xkphys space as the last step in the build. I assume this is to work around the known elf64 compilation issues, and seems fine in theory. Unfortunately, it doesn't seem to quite work for me. Looking at bootmem_init() in arch/mips64/mm/init.c, __pa(&_end) is optimized down to a literal load during compilation: a800000000113a2c: 3c0280aa lui $v0,0x80aa a800000000113a30: 64427b18 daddiu $v0,$v0,31512 a800000000113a34: 0040202d move $a0,$v0 a800000000113a38: 3c035800 lui $v1,0x5800 a800000000113a3c: 0003183c dsll32 $v1,$v1,0x0 a800000000113a40: 34630fff ori $v1,$v1,0xfff a800000000113a44: 0043102d daddu $v0,$v0,$v1 This is the result of having &_end be in kseg0, but __pa assuming that it's in xkphys. Also, at this point, the relocation is gone. So when I objcopy, I'm left with the strange address from hell being passed in to bootmem_init(). This, of course, makes the kernel very unhappy. I could fix this instance any number of ways, but that doesn't seem to be a solution for the general problem...I'm sure this same kind of thing is going to bite me in a couple dozen other places. I assume other people are successfully building mips64 kernels with those tools; does anyone have any hints as to how to fix this? Thanks, -Justin carlson@sibyte.com From owner-linux-mips@oss.sgi.com Tue May 15 23:57:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4G6vFJ31267 for linux-mips-outgoing; Tue, 15 May 2001 23:57:15 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G6vEF31264 for ; Tue, 15 May 2001 23:57:14 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA29329; Tue, 15 May 2001 23:57:07 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA10358; Tue, 15 May 2001 23:57:03 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id IAA15734; Wed, 16 May 2001 08:56:17 +0200 (MEST) Message-ID: <3B022491.49072483@mips.com> Date: Wed, 16 May 2001 08:56:17 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: "Tommy S. Christensen" , linux-mips@oss.sgi.com Subject: Re: Exception handlers get overwritten References: <3B01A980.7C27BB9F@eicon.com> <00bf01c0dd99$9c94b4e0$0deca8c0@Ulysses> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4622 Lines: 118 I added the EJTAG stuff, what is does is simply to return to the place where the EJTAG break point was taken. It doesn't do anything, but simply report that a EJTAG exception has been taken and then returns. The EJTAG handler has been added to avoid user application, such as crashme, will crash the kernel. I don't think there are anything wrong with the handler, except that you need the fix that Tommy suggest if you are linking your code to address 0x80000000, which only very few does. I believe this has been reported before, so I actually thought it was fixed. /Carsten "Kevin D. Kissell" wrote: > I don't know who checked in the EJTAG vector stuff, > but a few words of explanation and advice are in order. > MIPS32/MIPS64 CPUs have optional support for > EJTAG, which introduces a "Debug" mode of > execution which is similar to, but not identical to, > Kernel mode. The only way into Debug mode is > to take a Debug exception - not to be confused with > a breakpoint or watchpoint exception. These are > caused either by EJTAG hardware breakpoints > being hit, or by an external assertion on the EJTAG > interface. When the CPU enters Debug mode, it > transfers either to a location in the EJTAG pseudo > memory (an overlay of high physical memory that > maps to packet transactions on the JTAG interface) > or to the boot ROM vector area. They can never > vector directly to the 0x80000000 page! > > Now, since the hardware breakpoint channels are > potentially a cool feature to be able to exploit from > an OS - they allow breakpoints in ROM code, for > example - I once prototyped and debugged the necessary > code in OpenBSD to allow the kernel to be invoked > from a Debug exception, and to allow the kernel to > "call down" into the Debug mode code to set breakpoints, > etc.. To do this, one *must* have support in the boot > ROM of the platform. The boot ROM exception vector > can take advantage of the EJTAG scratch register to > save enough context to transfer control, intact, to > a pseudo-vector in the OS vector page (one of those > rare occasions where the jump delay slot is a lifesaver). > The location of that pseudo-vector is purely a software > convention, and should be chosen to be beyond *any* > hardware vectors, including those for the MIPS32/64 > and Nevada dedicated hardware interrupt vectors. > > I've been meaning for some time now to re-implement > the OpenBSD EJTAG hooks in Linux, but have simply > never had the time. It sounds like someone else has > started down that path without having looked at all the > issues. I'll try to dig out my old example ROM vector code > and post it to the newsgroup (it's only a few lines), along > with the EJTAG kernel interface code from OpenBSD > to serve as an example. > > Kevin K. > > ----- Original Message ----- > From: "Tommy S. Christensen" > To: > Sent: Wednesday, May 16, 2001 12:11 AM > Subject: Exception handlers get overwritten > > > With LOADADDR set to 0x80000000, except_vec0_r4600 and > > except_vec0_nevada are overwritten in trap_init() before they > > get installed at KSEG0. > > > > The fix is easy: > > > > diff -u -r1.53 traps.c > > --- arch/mips/kernel/traps.c 2001/04/08 13:24:27 1.53 > > +++ arch/mips/kernel/traps.c 2001/05/15 21:39:56 > > @@ -837,7 +837,9 @@ > > * Copy the EJTAG debug exception vector handler code to it's > > final > > * destination. > > */ > > +#ifdef WHONEEDSTLB > > memcpy((void *)(KSEG0 + 0x300), &except_vec_ejtag_debug, 0x80); > > +#endif > > > > /* > > * Only some CPUs have the watch exceptions or a dedicated > > > > > > OK, a kinder fix would be something like: > > > > diff -u -r1.25 head.S > > --- arch/mips/kernel/head.S 2001/05/04 20:43:25 1.25 > > +++ arch/mips/kernel/head.S 2001/05/15 21:39:40 > > @@ -44,7 +44,7 @@ > > * FIXME: Use the initcode feature to get rid of unused handler > > * variants. > > */ > > - .fill 0x280 > > + .fill 0x380 > > /* > > * This is space for the interrupt handlers. > > * After trap_init() they are located at virtual address KSEG0. > > > > > > I wonder why this never hit anybody else ... > > > > Regards, > > Tommy Christensen -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed May 16 02:43:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4G9hcm02156 for linux-mips-outgoing; Wed, 16 May 2001 02:43:38 -0700 Received: from woody.ichilton.co.uk (woody.ichilton.co.uk [216.29.174.40]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G9hbF02153 for ; Wed, 16 May 2001 02:43:37 -0700 Received: by woody.ichilton.co.uk (Postfix, from userid 1000) id DF06B80B3; Wed, 16 May 2001 10:43:35 +0100 (BST) Date: Wed, 16 May 2001 10:43:35 +0100 From: Ian Chilton To: Jason Brock Cc: linux-mips@oss.sgi.com Subject: Re: Mips cross-compiler Message-ID: <20010516104335.D25720@woody.ichilton.co.uk> Reply-To: Ian Chilton References: <3B0030FA.AE9B334C@ev1.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: <3B0030FA.AE9B334C@ev1.net>; from sho@ev1.net on Mon, May 14, 2001 at 02:24:42PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 602 Lines: 23 Hello, > When is there going to be a Linux version Mips Cross-Compiler for the > VR4122 (Casio EM-500)? Funny you should mention this, but I have just got such a device yesturday. I am planning to use it for a month or so, then try Linux on it. >From what I have read, the kernel should not be too much of a problem because the EM1XX is already supported. The problem seems to be the bootloader. Aparently Microsoft removed the vital funtions which the bootloaders used from WinCE 3, so none of the bootloaders work anymore. As for the cross compiler, you can build your own from source. Ian From owner-linux-mips@oss.sgi.com Wed May 16 05:04:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4GC4J905147 for linux-mips-outgoing; Wed, 16 May 2001 05:04:19 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GC4HF05143 for ; Wed, 16 May 2001 05:04:17 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id FAA01081; Wed, 16 May 2001 05:04:10 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA16238; Wed, 16 May 2001 05:04:07 -0700 (PDT) Message-ID: <002d01c0de00$edf50d00$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Tommy S. Christensen" , References: <3B01A980.7C27BB9F@eicon.com> Subject: Re: Exception handlers get overwritten, and more than you ever wanted to know about EJTAG Date: Wed, 16 May 2001 14:08:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5950 Lines: 145 My previous response was written at almost 2AM local time, and I was too tired to go find my archives from May 1999 before responding. I was also too tired to fully understand the nature of the bug Tommy was describing. I took it to mean that the installation of the EJTAG KSEG0 vector was overwriting other installed vectors - which seems not to be the case. By the light of day, I take it that the problem is in fact that the *templates* for the exception vectors are linked into the kernel image starting at location 0x80000280, and that therefore the installation of the EJTAG pseudo-vector was overwriting them *before* they could be installed. In any case, Carsten had of course correctly installed the pseudo-vector at the location that we adoped at MIPS, 0x80000300. The fix is not to get rid of it, but as noted, to make an allowance for it in the .fill directive at the beginning of the module. I would actually recommend that EJTAG support be a configure-able option, and in that case the .fill selected could be a function of wheter EJTAG support will be provided. It seems to me, however, that the problem could also be solved by installing the vectors in the right order - if the EJTAG vector had been installed at 0x80000300 *after* the excep_vec0 had been copied into place, it wouldn't have mattered. So long as the vectors are both assembled and installed in order of ascending vector addresses, one should be able to pack them in the linked binary with a .fill just big enough to allow for the largest excep_vec0. I don't know that the increased risk of miscalculation is worth the savings of a few hundred bytes, though. To get back to the issue of EJTAG support, for those of you who are interested (and who are building platforms around chips that support EJTAG), the actual hardware vector used for Debug exceptions when there is no probe attached is 0xbfc00480. The code to transfer control to a pseudo-vector at 0x80000300 looks like this (the choice of temporary register is arbitrary, but I actually recommend against using k0 or k1). .noreorder (!) 0xbfc00480 mtc0 t0,COP_O_DESAVE 0xbfc00484 lui t0,0x8000 0xbfc00488 ori t0,0x0300 0xbfc0048c jr t0 0xbfc00490 mfc0 t0,COP_0_DESAVE One important thing to understand about Debug exceptions is that, while there are restrictions on how they can nest, they can otherwise occur at *any* time. Which is to say, even if EXL is set in the Status register. Which is to say, even in the middle of a TLB miss or interrupt handler. So the Debug exception handler cannot use the kernel stack, nor should it be premitted to modify any kernel data structure directly. The pre-exception context must be saved and restored from *somewhere*, and there is the further subtlety that, depending on whether or not a probe is attached, the context save RAM may be on-board or on-probe. Now, the Debug exception handler can know whether it was entered via a probe memory vector or a ROM vector, so in the OpenBSD code, I created a convention whereby the word immediately preceding the hardware vector (0xbfc0047c in the case of the ROM vector) contains a pointer to a pointer to a context save block. Why a pointer-to-a-pointer? Because a Debug exception handler can explicitly allow itself to nest, and it is far more efficient to update a pointer in RAM to the next block than it would be to copy the saved contexts around. While the pointer to the context save block is modifiable, the pointer-to-the-pointer in ROM is not, and requires yet another software convention. For OpenBSD, I chose to put the RAM pointer in the word immediately preceding the RAM pseudo-vector, wich is to say 0xbfc0047c contains the value 0x800002fc, and the startup code (or even the kernel linkage, if one wanted to be EJTAG-sane from the moment the image is loaded) needs to see to it that 0x800002fc points to a reserved block of RAM big enough to hold the register set, etc. The debug handler, if it wants to allow for reentrancy, must update 0x800002fc to point to a clean save block before allowing any further exceptions. 0xbfc00480 is fixed by hardware, but the other conventions - pseudo-vector at 0x80000300, pointer-to-pointer at 0xbfc0047c, pointer-to-context at 0x800002fc - are software conventions. If anyone on this list sees problems, or a better way to do things, speak now "or forever hold your peace". Regards, Kevin K. ----- Original Message ----- From: "Tommy S. Christensen" To: Sent: Wednesday, May 16, 2001 12:11 AM Subject: Exception handlers get overwritten > With LOADADDR set to 0x80000000, except_vec0_r4600 and > except_vec0_nevada are overwritten in trap_init() before they > get installed at KSEG0. > > The fix is easy: > > diff -u -r1.53 traps.c > --- arch/mips/kernel/traps.c 2001/04/08 13:24:27 1.53 > +++ arch/mips/kernel/traps.c 2001/05/15 21:39:56 > @@ -837,7 +837,9 @@ > * Copy the EJTAG debug exception vector handler code to it's > final > * destination. > */ > +#ifdef WHONEEDSTLB > memcpy((void *)(KSEG0 + 0x300), &except_vec_ejtag_debug, 0x80); > +#endif > > /* > * Only some CPUs have the watch exceptions or a dedicated > > > OK, a kinder fix would be something like: > > diff -u -r1.25 head.S > --- arch/mips/kernel/head.S 2001/05/04 20:43:25 1.25 > +++ arch/mips/kernel/head.S 2001/05/15 21:39:40 > @@ -44,7 +44,7 @@ > * FIXME: Use the initcode feature to get rid of unused handler > * variants. > */ > - .fill 0x280 > + .fill 0x380 > /* > * This is space for the interrupt handlers. > * After trap_init() they are located at virtual address KSEG0. > > > I wonder why this never hit anybody else ... > > Regards, > Tommy Christensen From owner-linux-mips@oss.sgi.com Wed May 16 16:27:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4GNRJC25087 for linux-mips-outgoing; Wed, 16 May 2001 16:27:19 -0700 Received: from sprint02.rtmx.net (IDENT:qmailr@sprint02.RTMX.NET [208.31.160.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4GNRHF25084 for ; Wed, 16 May 2001 16:27:17 -0700 Received: (qmail 11831 invoked by uid 102); 16 May 2001 23:27:16 -0000 Received: from host098.momenco.com (HELO beagle) (64.169.228.98) by 208.31.160.29 with SMTP; 16 May 2001 23:27:16 -0000 From: "Matthew Dharm" To: "Ralf Baechle" , "Linux-MIPS" Cc: "Chuck Storey" , "Harry White" Subject: PATCH: Extended Interrupt support for the RM7000-based Ocelot Date: Wed, 16 May 2001 16:27:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C0DE25.18CEB4D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9101 Lines: 249 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0DE25.18CEB4D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached is a patch which adds support for extended interrupt devices to the Ocelot. It was created against a current CVS snapshot. Ralf, please apply. The patch basically re-writes the interrupt handler to read the extended interrupt mask from the Set 1 registers on the QED RM7000. It also changes the support functions so that these interrupts can be masked and unmasked properly. It occurs to me that this probably should go (eventually) into an RM7k-specific file, and not an Ocelot specific file. But the current arch/mips/ tree doesn't seem to support this well, so I figured that for a first pass, keeping everything where it current is will cause the least confusion. Matt Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com ------=_NextPart_000_000B_01C0DE25.18CEB4D0 Content-Type: application/octet-stream; name="irq_diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="irq_diff" --- arch/mips/gt64120/momenco_ocelot/int-handler.S 2001/02/05 01:33:01 = 1.1=0A= +++ arch/mips/gt64120/momenco_ocelot/int-handler.S 2001/05/16 23:08:43=0A= @@ -43,6 +43,22 @@=0A= bnez t1, ll_galileo_irq=0A= andi t1, t0, STATUSF_IP7 /* cpu timer */=0A= bnez t1, ll_cputimer_irq=0A= +=0A= + /* now look at the extended interrupts */=0A= + mfc0 t0, CP0_CAUSE =0A= + cfc0 t1, CP0_INTCONTROL=0A= +=0A= + /* shift the mask 8 bits left to line up the bits */=0A= + sll t2, t1, 8=0A= +=0A= + and t0, t2=0A= + srl t0, t0, 16=0A= +=0A= + andi t1, t0, STATUSF_IP8 /* int6 hardware line */=0A= + bnez t1, ll_pmc1_irq=0A= + andi t1, t0, STATUSF_IP9 /* int7 hardware line */=0A= + bnez t1, ll_pmc2_irq=0A= +=0A= .set reorder=0A= =0A= /* wrong alarm or masked ... */=0A= @@ -87,3 +103,14 @@=0A= jal do_IRQ=0A= j ret_from_irq=0A= =0A= +ll_pmc1_irq:=0A= + li a0, 8=0A= + move a1, sp=0A= + jal do_IRQ=0A= + j ret_from_irq=0A= +=0A= +ll_pmc2_irq:=0A= + li a0, 9=0A= + move a1, sp=0A= + jal do_IRQ=0A= + j ret_from_irq=0A= Index: arch/mips/gt64120/momenco_ocelot/irq.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/gt64120/momenco_ocelot/irq.c,v=0A= retrieving revision 1.3=0A= diff -u -r1.3 irq.c=0A= --- arch/mips/gt64120/momenco_ocelot/irq.c 2001/03/11 21:52:24 1.3=0A= +++ arch/mips/gt64120/momenco_ocelot/irq.c 2001/05/16 23:08:43=0A= @@ -58,9 +58,16 @@=0A= =0A= =0A= /* Function for careful CP0 interrupt mask access */=0A= -static inline void modify_cp0_intmask(unsigned clr_mask, unsigned = set_mask)=0A= +static inline void modify_cp0_intmask(unsigned clr_mask_in, unsigned = set_mask_in)=0A= {=0A= - unsigned long status =3D read_32bit_cp0_register(CP0_STATUS);=0A= + unsigned long status;=0A= + unsigned clr_mask;=0A= + unsigned set_mask;=0A= +=0A= + /* do the low 8 bits first */=0A= + clr_mask =3D 0xFF & clr_mask_in;=0A= + set_mask =3D 0xFF & set_mask_in;=0A= + status =3D read_32bit_cp0_register(CP0_STATUS);=0A= DBG(KERN_INFO "modify_cp0_intmask clr %x, set %x\n", clr_mask,=0A= set_mask);=0A= DBG(KERN_INFO "modify_cp0_intmask status %x\n", status);=0A= @@ -68,6 +75,18 @@=0A= status |=3D (set_mask & 0xFF) << 8;=0A= DBG(KERN_INFO "modify_cp0_intmask status %x\n", status);=0A= write_32bit_cp0_register(CP0_STATUS, status);=0A= +=0A= + /* do the high 8 bits */=0A= + clr_mask =3D 0xFF & (clr_mask_in >> 8);=0A= + set_mask =3D 0xFF & (set_mask_in >> 8);=0A= + status =3D read_32bit_cp0_aux_register(CP0_INTCONTROL);=0A= + DBG(KERN_INFO "modify_cp0_intmask clr %x, set %x\n", clr_mask,=0A= + set_mask);=0A= + DBG(KERN_INFO "modify_cp0_intmask status %x\n", status);=0A= + status &=3D ~((clr_mask & 0xFF) << 8);=0A= + status |=3D (set_mask & 0xFF) << 8;=0A= + DBG(KERN_INFO "modify_cp0_intmask status %x\n", status);=0A= + write_32bit_cp0_aux_register(CP0_INTCONTROL, status);=0A= }=0A= =0A= static inline void mask_irq(unsigned int irq_nr)=0A= @@ -87,8 +106,8 @@=0A= DBG(KERN_INFO "disable_irq, irq %d\n", irq_nr);=0A= save_and_cli(flags);=0A= /* we don't support higher interrupts, nor cascaded interrupts */=0A= - if (irq_nr >=3D 8)=0A= - panic("irq_nr is greater than 8");=0A= + if (irq_nr > 15)=0A= + panic("irq_nr is greater than 15");=0A= =0A= mask_irq(1 << irq_nr);=0A= restore_flags(flags);=0A= @@ -98,10 +117,11 @@=0A= {=0A= unsigned long flags;=0A= =0A= + DBG(KERN_INFO "enable_irq, irq %d\n", irq_nr);=0A= save_and_cli(flags);=0A= =0A= - if ( irq_nr >=3D 8 )=0A= - panic("irq_nr is greater than 8");=0A= + if ( irq_nr > 15 )=0A= + panic("irq_nr is greater than 15");=0A= =0A= unmask_irq( 1 << irq_nr );=0A= restore_flags(flags);=0A= Index: arch/mips/gt64120/momenco_ocelot/pci.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/gt64120/momenco_ocelot/pci.c,v=0A= retrieving revision 1.2=0A= diff -u -r1.2 pci.c=0A= --- arch/mips/gt64120/momenco_ocelot/pci.c 2001/03/08 13:13:57 1.2=0A= +++ arch/mips/gt64120/momenco_ocelot/pci.c 2001/05/16 23:08:43=0A= @@ -53,6 +53,12 @@=0A= "found unexpected PCI device in slot 2.");=0A= }=0A= devices->irq =3D 3; /* irq_nr is 3 for INT1 */=0A= + } else if (PCI_SLOT(devices->devfn) =3D=3D 4) {=0A= + /* PMC Slot 1 */=0A= + devices->irq =3D 8; /* irq_nr is 8 for INT6 */=0A= + } else if (PCI_SLOT(devices->devfn) =3D=3D 5) {=0A= + /* PMC Slot 1 */=0A= + devices->irq =3D 9; /* irq_nr is 9 for INT7 */=0A= } else {=0A= /* We don't have assign interrupts for other devices. */=0A= devices->irq =3D 0xff;=0A= Index: include/asm-mips/mipsregs.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/include/asm-mips/mipsregs.h,v=0A= retrieving revision 1.16=0A= diff -u -r1.16 mipsregs.h=0A= --- include/asm-mips/mipsregs.h 2001/04/01 03:28:23 1.16=0A= +++ include/asm-mips/mipsregs.h 2001/05/16 23:08:44=0A= @@ -58,6 +58,9 @@=0A= #define CP0_TAGHI $29=0A= #define CP0_ERROREPC $30=0A= =0A= +/* Auxillarly registers on the RM7000 */=0A= +#define CP0_INTCONTROL $20=0A= +=0A= /*=0A= * R4640/R4650 cp0 register names. These registers are listed=0A= * here only for completeness; without MMU these CPUs are not useable=0A= @@ -165,6 +168,16 @@=0A= : "=3Dr" (__res)); \=0A= __res;})=0A= =0A= +#define read_32bit_cp0_aux_register(source) \=0A= +({ int __res; \=0A= + __asm__ __volatile__( \=0A= + ".set\tpush\n\t" \=0A= + ".set\treorder\n\t" \=0A= + "cfc0\t%0,"STR(source)"\n\t" \=0A= + ".set\tpop" \=0A= + : "=3Dr" (__res)); \=0A= + __res;})=0A= +=0A= /*=0A= * For now use this only with interrupts disabled!=0A= */=0A= @@ -183,6 +196,12 @@=0A= "nop" \=0A= : : "r" (value));=0A= =0A= +#define write_32bit_cp0_aux_register(register,value) \=0A= + __asm__ __volatile__( \=0A= + "ctc0\t%0,"STR(register)"\n\t" \=0A= + "nop" \=0A= + : : "r" (value));=0A= +=0A= #define write_64bit_cp0_register(register,value) \=0A= __asm__ __volatile__( \=0A= ".set\tmips3\n\t" \=0A= @@ -370,6 +389,22 @@=0A= #define STATUSF_IP6 (1 << 14)=0A= #define STATUSB_IP7 15=0A= #define STATUSF_IP7 (1 << 15)=0A= +#define STATUSB_IP8 0=0A= +#define STATUSF_IP8 (1 << 0)=0A= +#define STATUSB_IP9 1=0A= +#define STATUSF_IP9 (1 << 1)=0A= +#define STATUSB_IP10 2=0A= +#define STATUSF_IP10 (1 << 2)=0A= +#define STATUSB_IP11 3=0A= +#define STATUSF_IP11 (1 << 3)=0A= +#define STATUSB_IP12 4=0A= +#define STATUSF_IP12 (1 << 4)=0A= +#define STATUSB_IP13 5=0A= +#define STATUSF_IP13 (1 << 5)=0A= +#define STATUSB_IP14 6=0A= +#define STATUSF_IP14 (1 << 6)=0A= +#define STATUSB_IP15 7=0A= +#define STATUSF_IP15 (1 << 7)=0A= #define ST0_CH 0x00040000=0A= #define ST0_SR 0x00100000=0A= #define ST0_BEV 0x00400000=0A= ------=_NextPart_000_000B_01C0DE25.18CEB4D0-- From owner-linux-mips@oss.sgi.com Wed May 16 17:20:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4H0K1q26619 for linux-mips-outgoing; Wed, 16 May 2001 17:20:01 -0700 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H0K0F26616 for ; Wed, 16 May 2001 17:20:00 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id RAA04181; Wed, 16 May 2001 17:19:05 -0700 Date: Wed, 16 May 2001 17:19:05 -0700 From: Jun Sun To: Matthew Dharm Cc: Ralf Baechle , Linux-MIPS , Chuck Storey , Harry White Subject: Re: PATCH: Extended Interrupt support for the RM7000-based Ocelot Message-ID: <20010516171905.D2798@mvista.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Wed, May 16, 2001 at 04:27:27PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1180 Lines: 28 On Wed, May 16, 2001 at 04:27:27PM -0700, Matthew Dharm wrote: > Attached is a patch which adds support for extended interrupt devices > to the Ocelot. It was created against a current CVS snapshot. Ralf, > please apply. > > The patch basically re-writes the interrupt handler to read the > extended interrupt mask from the Set 1 registers on the QED RM7000. > It also changes the support functions so that these interrupts can be > masked and unmasked properly. > > It occurs to me that this probably should go (eventually) into an > RM7k-specific file, and not an Ocelot specific file. But the current > arch/mips/ tree doesn't seem to support this well, so I figured that > for a first pass, keeping everything where it current is will cause > the least confusion. > The best way to support RM7K extended interrupts is to use the new irq.c and write rm7k irq controller code, (e.g., irq_cpu_rm7k.c). It should be similar to one I sent out (irq_cpu.c file) a while back. If you cannot find it, I can send you again. The modification to the common files looks a little bit instrusive. But I won't complain if Ralf does not - he usually has a higher standard. :-) Jun From owner-linux-mips@oss.sgi.com Thu May 17 00:16:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4H7GYJ02465 for linux-mips-outgoing; Thu, 17 May 2001 00:16:34 -0700 Received: from yes.home.krftech.com ([194.90.113.98]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H7GTF02457 for ; Thu, 17 May 2001 00:16:30 -0700 Received: from athena.home.krftech.com (shay@athena.home.krftech.com [192.168.71.19]) by yes.home.krftech.com (8.8.7/8.8.7) with SMTP id KAA08083 for ; Thu, 17 May 2001 10:16:16 +0300 Content-Type: Multipart/Mixed; charset="iso-8859-1"; boundary="------------Boundary-00=_FNXG32012ZGJ3O2J9DUL" From: Shay Deloya Reply-To: shay@jungo.com Organization: Jungo Corp. To: linux-mips@oss.sgi.com Subject: Binutils 2.10 and Dynamic Loader Date: Thu, 17 May 2001 10:18:51 +0300 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <0105171018510F.16854@athena.home.krftech.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3190 Lines: 100 --------------Boundary-00=_FNXG32012ZGJ3O2J9DUL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi, I'm trying to use binutils 2.10 (BU) , and compiling x.c file that depend on libx.so file that I've created ( both files don't use glibc). The shared object has only two variables both initialized of type int and char* ("Welcome"). When compiling the SO with BU 2.8 I see that the section (see below) is created for the string with "pointing" to the <.rodata> section, loading the file with ld.so.1 makes the relocation OK , by adding the shared library address to this offset. However , compiling the SO with BU 2.10 I see that the section (see below) is created for the string without pointing to the <.rodata> section, and letting the loader to make 'complicated' relocation using the relocation table (elf header). Since rodata is a section , the dynamic loader ld.so.1 only adds the offset to that symbol , and there for the relocation is done in wrong way. Is it a problem of the 2.10 ld , or a problem of the dynamic loader (libc.2.0.6) ? does anyone had the same problem before ? BTW , the copile flags are : for the so : -Wl,-dynamic-linker,"/lib/ld.so.1" -nostdlib -Wl,-e,main and the mips-linux-ld libx.o -share libx.so and for the x.c : -nostdlib Thanks , Shay 2.10 ===== 000000005ffe0540 <.rodata>: 5ffe0540: 57656c63 0x57656c63 5ffe0544: 6f6d6500 0x6f6d6500 ... 0000000060020570 <.data>: 60020570: 0000000a 0xa ... from readelf on the .so file: Relocation section '.rel.dyn' at offset 0x550 contains 3 entries: Offset Info Type Symbol's Value Symbol's Name 00000000 00000 R_MIPS_NONE 60020574 01f03 R_MIPS_REL32 60020570 num 60020578 00703 R_MIPS_REL32 5ffe0540 .rodata 2.8 ==== 000000005ffe04d0 <.rodata>: 5ffe04d0: 57656c63 0x57656c63 5ffe04d4: 6f6d6500 0x6f6d6500 ... 0000000060020510 <.data>: 60020510: 0000000a 0xa 60020518: 5ffe04d0 0x5ffe04d0 6002051c: 00000000 nop fro readelf on the .so file: Relocation section '.rel.dyn' at offset 0x4e0 contains 3 entries: Offset Info Type Symbol's Value Symbol's Name 00000000 00000 R_MIPS_NONE 60020514 00003 R_MIPS_REL32 60020518 00003 R_MIPS_REL32 --------------Boundary-00=_FNXG32012ZGJ3O2J9DUL Content-Type: text/x-c; charset="iso-8859-1"; name="x.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="x.c" ZXh0ZXJuIGludCBudW07CmV4dGVybiBjaGFyICpteV9zdHI7IAoKaW50ICpsbnVtID0gJm51bTsK Y2hhciAqdF9zdHIgPSAiIjsgCgppbnQgeG51bTsKaW50ICpweG51bTsKY2hhciAqeHN0cjsKY2hh ciAqKnhwc3RyOwpjaGFyICp3X3N0ciA9ICJhYmMiOwppbnQgbWFpbigpCnsKICAgIHRfc3RyID0g bXlfc3RyOwogICAgCiAgICB4c3RyID0gbXlfc3RyOwogICAgeG51bSA9IG51bTsKICAgIHhwc3Ry ID0gJm15X3N0cjsKICAgIHB4bnVtID0gJm51bTsKICAgIHJldHVybiAwOwp9Cg== --------------Boundary-00=_FNXG32012ZGJ3O2J9DUL Content-Type: text/x-c; charset="iso-8859-1"; name="libx.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="libx.c" aW50IG51bSA9IDEwOwpjaGFyICogbXlfc3RyID0gIldlbGNvbWUiOwo= --------------Boundary-00=_FNXG32012ZGJ3O2J9DUL-- From owner-linux-mips@oss.sgi.com Thu May 17 11:11:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4HIBNj19644 for linux-mips-outgoing; Thu, 17 May 2001 11:11:23 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HIBIF19638; Thu, 17 May 2001 11:11:18 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4HIBI008344; Thu, 17 May 2001 11:11:18 -0700 Message-ID: <3B0413A4.8060607@mvista.com> Date: Thu, 17 May 2001 11:08:36 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i586; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: full 32bit ioremap Content-Type: multipart/mixed; boundary="------------080905050507070900050801" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8233 Lines: 272 This is a multi-part message in MIME format. --------------080905050507070900050801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ralf, I've attached a patch to add full 32 bit ioremap support for mips. It's basically x86 ioremap with a couple of small changes. I've tested it on one board and it works fine, although some driver modifications were necessary since the minimum ioremap size is 0x1000. I realize no other boards require ioremap beyond 0x2000 0000 at this time, but others may benefit from it in the future. The default is to not use it, so nothing needs to be changed in any of the boards supported, except the defconfig file. Pete --------------080905050507070900050801 Content-Type: text/plain; name="ioremap32.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ioremap32.patch" diff -Naur --exclude=CVS --exclude=.cvsignore linux/Documentation/Configure.help linux_new/Documentation/Configure.help --- linux/Documentation/Configure.help Wed Apr 4 21:56:06 2001 +++ linux_new/Documentation/Configure.help Thu May 17 10:02:46 2001 @@ -229,6 +229,14 @@ If unsure, say "off". +MIPS 32bit ioremap support +CONFIG_MIPS_32BIT_IOREMAP + If you want to be able to remap I/O devices on any 32 bit physical + address, say Y. Without this feature, I/O devices MUST reside on + a physical address less than 0x2000 0000. Do NOT say Y unless + you're absolutely sure you know what this feature is and what + are the implications for device drivers. + Normal PC floppy disk support CONFIG_BLK_DEV_FD If you want to use the floppy disk drive(s) of your PC under Linux, diff -Naur --exclude=CVS --exclude=.cvsignore linux/arch/mips/config.in linux_new/arch/mips/config.in --- linux/arch/mips/config.in Tue May 8 17:32:39 2001 +++ linux_new/arch/mips/config.in Thu May 17 10:09:16 2001 @@ -232,6 +232,7 @@ if [ "$CONFIG_CPU_ADVANCED" = "y" ]; then bool ' ll/sc Instructions available' CONFIG_CPU_HAS_LLSC bool ' Writeback Buffer available' CONFIG_CPU_HAS_WB + bool ' Enable full 32 bit ioremap' CONFIG_MIPS_32BIT_IOREMAP else if [ "$CONFIG_CPU_R3000" = "y" ]; then if [ "$CONFIG_DECSTATION" = "y" ]; then diff -Naur --exclude=CVS --exclude=.cvsignore linux/arch/mips/mm/Makefile linux_new/arch/mips/mm/Makefile --- linux/arch/mips/mm/Makefile Sat Mar 31 18:54:22 2001 +++ linux_new/arch/mips/mm/Makefile Thu May 17 10:57:19 2001 @@ -12,6 +12,7 @@ export-objs += umap.o obj-y += extable.o init.o fault.o loadmmu.o +obj-$(CONFIG_MIPS_32BIT_IOREMAP) += ioremap.o obj-$(CONFIG_CPU_R3000) += r2300.o obj-$(CONFIG_CPU_R4300) += r4xx0.o obj-$(CONFIG_CPU_R4X00) += r4xx0.o diff -Naur --exclude=CVS --exclude=.cvsignore linux/arch/mips/mm/ioremap.c linux_new/arch/mips/mm/ioremap.c --- linux/arch/mips/mm/ioremap.c Wed Dec 31 16:00:00 1969 +++ linux_new/arch/mips/mm/ioremap.c Thu May 17 10:08:37 2001 @@ -0,0 +1,180 @@ + +#include +#include +#include + +#include +#include +#include + +#undef DEBUG_MIPS_32BIT_IOREMAP + +void * __ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags); + +void * ioremap(unsigned long offset, unsigned long size) +{ + /* + * MIPS device drivers are used to ioremap returning a kseg1 address, + * so we always call __ioremap with the _CACHE_UNCACHED flag. + */ + return __ioremap(offset, size, _CACHE_UNCACHED); +} + +/* + * This one maps high address device memory and turns off caching for that area. + * it's useful if some control registers are in such an area and write combining + * or read caching is not desirable: + */ +void * ioremap_nocache (unsigned long offset, unsigned long size) +{ + return __ioremap(offset, size, _CACHE_UNCACHED); +} + +void iounmap(void *addr) +{ + if (addr > high_memory) + return vfree((void *) (PAGE_MASK & (unsigned long) addr)); +} + + +static inline void remap_area_pte(pte_t * pte, unsigned long address, unsigned long size, + unsigned long phys_addr, unsigned long flags) +{ + unsigned long end; + + address &= ~PMD_MASK; + end = address + size; + if (end > PMD_SIZE) + end = PMD_SIZE; + if (address >= end) + BUG(); + do { + if (!pte_none(*pte)) { + printk("remap_area_pte: page already exists\n"); + BUG(); + } + set_pte(pte, mk_pte_phys(phys_addr, __pgprot(_PAGE_PRESENT | __READABLE | + __WRITEABLE | flags))); + address += PAGE_SIZE; + phys_addr += PAGE_SIZE; + pte++; + } while (address && (address < end)); +} + +static inline int remap_area_pmd(pmd_t * pmd, unsigned long address, unsigned long size, + unsigned long phys_addr, unsigned long flags) +{ + unsigned long end; + + address &= ~PGDIR_MASK; + end = address + size; + if (end > PGDIR_SIZE) + end = PGDIR_SIZE; + phys_addr -= address; + if (address >= end) + BUG(); + do { + pte_t * pte = pte_alloc(&init_mm, pmd, address); + if (!pte) + return -ENOMEM; + remap_area_pte(pte, address, end - address, address + phys_addr, flags); + address = (address + PMD_SIZE) & PMD_MASK; + pmd++; + } while (address && (address < end)); + return 0; +} + +static int remap_area_pages(unsigned long address, unsigned long phys_addr, + unsigned long size, unsigned long flags) +{ + int error; + pgd_t * dir; + unsigned long end = address + size; + + phys_addr -= address; + dir = pgd_offset(&init_mm, address); + flush_cache_all(); + if (address >= end) + BUG(); + spin_lock(&init_mm.page_table_lock); + do { + pmd_t *pmd; + pmd = pmd_alloc(&init_mm, dir, address); + error = -ENOMEM; + if (!pmd) + break; + if (remap_area_pmd(pmd, address, end - address, + phys_addr + address, flags)) + break; + error = 0; + address = (address + PGDIR_SIZE) & PGDIR_MASK; + dir++; + } while (address && (address < end)); + spin_unlock(&init_mm.page_table_lock); + flush_tlb_all(); + return error; +} + +/* + * Generic mapping function (not visible outside): + */ + +/* + * Remap an arbitrary physical address space into the kernel virtual + * address space. Needed when the kernel wants to access high addresses + * directly. + * + * NOTE! We need to allow non-page-aligned mappings too: we will obviously + * have to convert them into an offset in a page-aligned mapping, but the + * caller shouldn't need to know that small detail. + */ +void * __ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags) +{ + void * addr; + struct vm_struct * area; + unsigned long offset, last_addr; + + /* Don't allow wraparound or zero size */ + last_addr = phys_addr + size - 1; + if (!size || last_addr < phys_addr) + return NULL; + + /* + * Don't allow anybody to remap normal RAM that we're using.. + */ + if (phys_addr < virt_to_phys(high_memory)) { + char *t_addr, *t_end; + struct page *page; + + t_addr = __va(phys_addr); + t_end = t_addr + (size - 1); + + for(page = virt_to_page(t_addr); page <= virt_to_page(t_end); page++) + if(!PageReserved(page)) + return NULL; + } + + /* + * Mappings have to be page-aligned + */ + offset = phys_addr & ~PAGE_MASK; + phys_addr &= PAGE_MASK; + size = PAGE_ALIGN(last_addr) - phys_addr; + + /* + * Ok, go for it.. + */ + area = get_vm_area(size, VM_IOREMAP); + if (!area) + return NULL; + addr = area->addr; + if (remap_area_pages(VMALLOC_VMADDR(addr), phys_addr, size, flags)) { + vfree(addr); + return NULL; + } + +#ifdef DEBUG_MIPS_32BIT_IOREMAP + printk("__ioremap %x: %x\n", phys_addr, offset+(char *)addr); +#endif + return (void *) (offset + (char *)addr); +} diff -Naur --exclude=CVS --exclude=.cvsignore linux/include/asm-mips/io.h linux_new/include/asm-mips/io.h --- linux/include/asm-mips/io.h Fri Feb 9 16:43:15 2001 +++ linux_new/include/asm-mips/io.h Thu May 17 10:39:35 2001 @@ -133,6 +133,7 @@ */ extern unsigned long isa_slot_offset; +#ifndef CONFIG_MIPS_32BIT_IOREMAP /* * readX/writeX() are used to access memory mapped devices. On some * architectures the memory mapped IO stuff needs to be accessed @@ -165,6 +166,7 @@ extern inline void iounmap(void *addr) { } +#endif /* * XXX We need system specific versions of these to handle EISA address bits --------------080905050507070900050801-- From owner-linux-mips@oss.sgi.com Thu May 17 11:18:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4HIIbA19961 for linux-mips-outgoing; Thu, 17 May 2001 11:18:37 -0700 Received: from mail.sonytel.be ([193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HIIZF19958 for ; Thu, 17 May 2001 11:18:36 -0700 Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id UAA27225 for ; Thu, 17 May 2001 20:18:32 +0200 (MET DST) Received: (from tea@localhost) by ginger.sonytel.be (8.9.0/8.8.6) id UAA08020 for linux-mips@oss.sgi.com; Thu, 17 May 2001 20:18:32 +0200 (MET DST) Date: Thu, 17 May 2001 20:18:32 +0200 From: Tom Appermont To: linux-mips@oss.sgi.com Subject: interrupt problem Message-ID: <20010517201832.B2352@sonycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1288 Lines: 34 Howdy, I named the subject "interrupt problem", although I am not completely sure it is really a problem with interrupts I'm having. Anyway, the symptoms are the following: - a ddb 5074 board with 3com boomerang ethernet pci card, boots with initial ramdisk (ok) - serial interrupts work (ok) - ethernet card interrupts work when doing a "simple" ping - flooding the card with network packets (ping -f) causes the ddb board to hang/freeze/stall after an unpredictible amount of time, without producing any output on the serial console. - the problem does not seem to exist when I use a realtek ethernet card (ne2k driver) in stead of the 3com card. I've tried to remedy this by: - replacing the low level interrupt handling code for ddb5074 with the new irq.c and time.c in arch/mips/kernel (needs CONFIG_NEW_TIME_C and CONFIG_NEW_IRQ). - replacing the timer interrupts with CPU timer interrupts. - getting the newest 3c59x driver (although I don't have any probs with this driver on pc). - banging my head on the table. No luck so far. I am a bit out of ideas on how to track down the cause of this problem, so it would be really helpful if somebody could either indicate a hint of a possible solution, or suggest ways to debug this situation. Greetz, Tom From owner-linux-mips@oss.sgi.com Thu May 17 16:25:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4HNPgb30138 for linux-mips-outgoing; Thu, 17 May 2001 16:25:42 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HNPgF30135 for ; Thu, 17 May 2001 16:25:42 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA19444 for ; Thu, 17 May 2001 16:25:35 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA18176 for ; Thu, 17 May 2001 16:25:32 -0700 (PDT) Message-ID: <006001c0df29$4a7c7ee0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "MIPS/Linux List \(SGI\)" Subject: Profiling under MIPS/Linux Date: Fri, 18 May 2001 01:29:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 281 Lines: 9 If I may introduce a topic that I've not seen discussed for some time, what is the current state of profiling support for MIPS/Linux? Is there a set of kernel/compiler/libc/gprof versions that work today? If not, where are the holes? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu May 17 18:08:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4I18t600704 for linux-mips-outgoing; Thu, 17 May 2001 18:08:55 -0700 Received: from smtp.psdc.com (smtp.psdc.com [209.125.203.83]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I18tF00701 for ; Thu, 17 May 2001 18:08:55 -0700 Received: from BANANA ([209.125.203.85]) by smtp.psdc.com (8.8.8/8.8.8) with SMTP id SAA11903; Thu, 17 May 2001 18:14:42 -0700 Message-ID: <001201c0df37$2befb920$dde0490a@pcs.psdc.com> From: "Steven Liu" To: "Keith M Wesolowski" Cc: References: <000801c0a572$b7471e40$dde0490a@BANANA> <20010305205516.A25870@foobazco.org> Subject: Re: mips-tfile Date: Thu, 17 May 2001 18:09:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2837 Lines: 68 Hi, All: I have a question about GCC: How can we make gcc do not use the MIPS instructions lwl, lwr, swl, and swr? Thanks, Steven ----- Original Message ----- From: "Keith M Wesolowski" To: "Steven Liu" Cc: Sent: Monday, March 05, 2001 9:55 PM Subject: Re: mips-tfile > On Mon, Mar 05, 2001 at 04:49:28AM -0800, Steven Liu wrote: > > > I am working on cross-compiler for mips R3000 on Linux now and meet a problem in egcs. > > > > My host system is i386 with Rad Hat 7.0 installed. > > > > First, I successfully built and installed binutils-2.8.1 by using > > binutils-2.8.1.tar.gz and egcs-mips-linux-1.1.2-2.i386.rpm. This created > > bin, lib, mips-linux subdirectories. > > This makes no sense...how/why did you use an rpm of egcs to build > binutils from source? That doesn't really make any sense. Could you > please indicate what exact files you are using and where you got them > from? If you are applying patches, please mention those as well. > > > Second, I installed the linux kernel source code for mips by using > > linux-2.2.14-000715.tar.gz and configured it and enabled > > CONFIG_CROSSCOMPILE. Made soft links: let mips-linux/include/asm > > pointd to linux-2.2.14-000715/include/asm-mips and > > mips-linux/include/linux pointd to linux-2.2.14-000715/include/linux. > > This is not needed to build either gcc or the kernel. > > > Third, unziped the egcs-1.1.2.tar.gz, added the patch > > egcs-mips-linux-1.1.2-2.i386.rpm and configured it as following: > > ./configure --prefix=3D/home/sliu --with-newlib --target=mips-linux > > and made it this way: > > make SUBDIRS=3D"libiberty texinfo gcc" ALL_TARGET_MODULES=3D = > > CONFIGURE_TARGET_MODULES=3D INSTALL_TARGET_MODULES=3D LANGUAGES=3D"c" > > What are you doing with both an rpm and a source tarball? An RPM is > surely not a patch. Also, it is traditional to build gcc outside the > source directory; it's possible that that is a source of trouble. The > random "3D" in your output there is either another source of trouble > or an artifact of your mailer; in either case it should be fixed. > > If you are having trouble building a cross-toolchain, you might > consider getting make-cross from > ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev - it takes > most of the hard parts out of it. There's also a source toolchain > there that seems to work fairly well; it compiles glibc, for example, > which no version of egcs 1.1.2 I have seen will. Of course, if you > want to use different versions you can do that as well. > > -- > Keith M Wesolowski http://foobazco.org/~wesolows > ------(( Project Foobazco Coordinator and Network Administrator ))------ > "I should have crushed his marketing-addled skull with a fucking bat." > From owner-linux-mips@oss.sgi.com Thu May 17 18:42:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4I1g6Q01967 for linux-mips-outgoing; Thu, 17 May 2001 18:42:06 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I1g4F01964 for ; Thu, 17 May 2001 18:42:05 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4I1VdZ30837; Thu, 17 May 2001 22:31:39 -0300 Date: Thu, 17 May 2001 22:31:39 -0300 From: Ralf Baechle To: Steven Liu Cc: Keith M Wesolowski , linux-mips@oss.sgi.com Subject: Re: mips-tfile Message-ID: <20010517223139.A19781@bacchus.dhis.org> References: <000801c0a572$b7471e40$dde0490a@BANANA> <20010305205516.A25870@foobazco.org> <001201c0df37$2befb920$dde0490a@pcs.psdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001201c0df37$2befb920$dde0490a@pcs.psdc.com>; from stevenliu@psdc.com on Thu, May 17, 2001 at 06:09:17PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 380 Lines: 11 On Thu, May 17, 2001 at 06:09:17PM -0700, Steven Liu wrote: > I have a question about GCC: > > How can we make gcc do not use the MIPS instructions lwl, lwr, swl, and swr? Modify gcc. Unless you're using a new flavour (And I'm tempted to use some curseword instead ...) of a cpu core without lwl/lwr/swl/swr there should never be a reason to avoid those instructions. Ralf From owner-linux-mips@oss.sgi.com Fri May 18 13:23:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4IKNgp05791 for linux-mips-outgoing; Fri, 18 May 2001 13:23:42 -0700 Received: from web11908.mail.yahoo.com (web11908.mail.yahoo.com [216.136.172.192]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4IKNgF05787 for ; Fri, 18 May 2001 13:23:42 -0700 Message-ID: <20010518202342.25982.qmail@web11908.mail.yahoo.com> Received: from [209.243.184.191] by web11908.mail.yahoo.com; Fri, 18 May 2001 13:23:42 PDT Date: Fri, 18 May 2001 13:23:42 -0700 (PDT) From: Wayne Gowcher Subject: Netscape on linux-mipsel ?? To: linux-mips@oss.sgi.com In-Reply-To: <3AFB04FF.353198C6@mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 582 Lines: 24 Dear All, Does anyone know if Netscape or any other browser has been compiled to run on linux mipsel ? All I can find so far are "x86" source for netscape. If it has, care to tell me the links where I may get it ? Alternatively, if no one knows of anyone having a working linux mipsel Netscape binary / rpm. Anyone care to guess the scope of attempting to modify the x86 or mips-sgi-irix sources to run on mips ? TIA Wayne __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-linux-mips@oss.sgi.com Fri May 18 13:31:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4IKVvK06510 for linux-mips-outgoing; Fri, 18 May 2001 13:31:57 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IKVuF06507 for ; Fri, 18 May 2001 13:31:57 -0700 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4IKVr001145; Fri, 18 May 2001 13:31:53 -0700 Message-ID: <3B058614.6040302@mvista.com> Date: Fri, 18 May 2001 13:29:08 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i586; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: en MIME-Version: 1.0 To: Wayne Gowcher CC: linux-mips@oss.sgi.com Subject: Re: Netscape on linux-mipsel ?? References: <20010518202342.25982.qmail@web11908.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 665 Lines: 22 Wayne Gowcher wrote: >Dear All, > >Does anyone know if Netscape or any other browser has >been compiled to run on linux mipsel ? All I can find >so far are "x86" source for netscape. > >If it has, care to tell me the links where I may get >it ? > >Alternatively, if no one knows of anyone having a >working linux mipsel Netscape binary / rpm. Anyone >care to guess the scope of attempting to modify the >x86 or mips-sgi-irix sources to run on mips ? > We're pretty close on having both, be and le mips binaries. You'll need a graphics card which has frame buffer driver support so that X can run on top of the FBdev driver. Check with me again "later". Pete From owner-linux-mips@oss.sgi.com Fri May 18 16:42:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4INg7811378 for linux-mips-outgoing; Fri, 18 May 2001 16:42:07 -0700 Received: from smtp.psdc.com (smtp.psdc.com [209.125.203.83]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4INg3F11374; Fri, 18 May 2001 16:42:03 -0700 Received: from BANANA ([209.125.203.85]) by smtp.psdc.com (8.8.8/8.8.8) with SMTP id QAA24939; Fri, 18 May 2001 16:48:02 -0700 Message-ID: <000801c0dff4$3870ba60$dde0490a@pcs.psdc.com> From: "Steven Liu" To: "Ralf Baechle" Cc: "Keith M Wesolowski" , References: <000801c0a572$b7471e40$dde0490a@BANANA> <20010305205516.A25870@foobazco.org> <001201c0df37$2befb920$dde0490a@pcs.psdc.com> <20010517223139.A19781@bacchus.dhis.org> Subject: Re: mips-tfile Date: Fri, 18 May 2001 16:42:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1022 Lines: 39 Hi ALL: I have a question regarding MIPS Makefile. In the Makefile of the Linux build directory, there are two Macros of C compiler flags: HOSTCFLAGS and CFLAGS. What are their purpose and difference? In another words, what is host gcc? Why do we use host gcc in building the target kernel? If you could give me any help, I would be very pleased. Thank you. Steven Liu ----- Original Message ----- From: "Ralf Baechle" To: "Steven Liu" Cc: "Keith M Wesolowski" ; Sent: Thursday, May 17, 2001 6:31 PM Subject: Re: mips-tfile > On Thu, May 17, 2001 at 06:09:17PM -0700, Steven Liu wrote: > > > I have a question about GCC: > > > > How can we make gcc do not use the MIPS instructions lwl, lwr, swl, and swr? > > Modify gcc. Unless you're using a new flavour (And I'm tempted to use some > curseword instead ...) of a cpu core without lwl/lwr/swl/swr there should > never be a reason to avoid those instructions. > > Ralf > From owner-linux-mips@oss.sgi.com Fri May 18 16:52:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4INqcK11718 for linux-mips-outgoing; Fri, 18 May 2001 16:52:38 -0700 Received: from pobox.sibyte.com (pobox.sibyte.com [208.12.96.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4INqcF11715 for ; Fri, 18 May 2001 16:52:38 -0700 Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21]) by pobox.sibyte.com (Postfix) with SMTP id 9A76E205FC; Fri, 18 May 2001 16:53:12 -0700 (PDT) Received: from SMTP agent by mail gateway Fri, 18 May 2001 16:44:10 -0800 Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 010AC15961; Fri, 18 May 2001 16:52:33 -0700 (PDT) Received: by plugh.sibyte.com (Postfix, from userid 61017) id 4A400686D; Fri, 18 May 2001 16:52:31 -0700 (PDT) From: Justin Carlson Reply-To: carlson@sibyte.com Organization: Sibyte To: stevenliu@psdc.com Subject: Re: mips-tfile Date: Fri, 18 May 2001 16:50:25 -0700 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain Cc: linux-mips@oss.sgi.com References: <000801c0a572$b7471e40$dde0490a@BANANA> <20010517223139.A19781@bacchus.dhis.org> <000801c0dff4$3870ba60$dde0490a@pcs.psdc.com> In-Reply-To: <000801c0dff4$3870ba60$dde0490a@pcs.psdc.com> MIME-Version: 1.0 Message-Id: <01051816523009.00779@plugh.sibyte.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 404 Lines: 15 On Fri, 18 May 2001, Steven Liu wrote: > Hi ALL: > > I have a question regarding MIPS Makefile. > > In the Makefile of the Linux build directory, there are two Macros of C > compiler flags: HOSTCFLAGS and CFLAGS. > > What are their purpose and difference? In another words, what is host gcc? > Why do we use host gcc in building the target kernel? > See Documentation/kbuild/makefiles.txt. -Justin From owner-linux-mips@oss.sgi.com Fri May 18 20:34:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4J3Y5o15336 for linux-mips-outgoing; Fri, 18 May 2001 20:34:05 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4J3Y3F15333 for ; Fri, 18 May 2001 20:34:03 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4J3N5C01285; Sat, 19 May 2001 00:23:05 -0300 Date: Sat, 19 May 2001 00:23:05 -0300 From: Ralf Baechle To: Steven Liu Cc: Keith M Wesolowski , linux-mips@oss.sgi.com Subject: Re: mips-tfile Message-ID: <20010519002305.B1209@bacchus.dhis.org> References: <000801c0a572$b7471e40$dde0490a@BANANA> <20010305205516.A25870@foobazco.org> <001201c0df37$2befb920$dde0490a@pcs.psdc.com> <20010517223139.A19781@bacchus.dhis.org> <000801c0dff4$3870ba60$dde0490a@pcs.psdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000801c0dff4$3870ba60$dde0490a@pcs.psdc.com>; from stevenliu@psdc.com on Fri, May 18, 2001 at 04:42:37PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 620 Lines: 16 On Fri, May 18, 2001 at 04:42:37PM -0700, Steven Liu wrote: > I have a question regarding MIPS Makefile. > > In the Makefile of the Linux build directory, there are two Macros of C > compiler flags: HOSTCFLAGS and CFLAGS. > > What are their purpose and difference? In another words, what is host gcc? > Why do we use host gcc in building the target kernel? During the build process of the kernel some tools like scripts/mkdep and others are built which are running on the compile machine, not the target machine. The variable HOSTCFLAGS takes some extra compiler options to be passed for such compilations. Ralf From owner-linux-mips@oss.sgi.com Fri May 18 21:00:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4J40dY15820 for linux-mips-outgoing; Fri, 18 May 2001 21:00:39 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4J40YF15817 for ; Fri, 18 May 2001 21:00:35 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4J3oI901384; Sat, 19 May 2001 00:50:18 -0300 Date: Sat, 19 May 2001 00:50:18 -0300 From: Ralf Baechle To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Subject: Re: Netscape on linux-mipsel ?? Message-ID: <20010519005018.C1209@bacchus.dhis.org> References: <3AFB04FF.353198C6@mvista.com> <20010518202342.25982.qmail@web11908.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010518202342.25982.qmail@web11908.mail.yahoo.com>; from wgowcher@yahoo.com on Fri, May 18, 2001 at 01:23:42PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 773 Lines: 22 On Fri, May 18, 2001 at 01:23:42PM -0700, Wayne Gowcher wrote: > Does anyone know if Netscape or any other browser has > been compiled to run on linux mipsel ? All I can find > so far are "x86" source for netscape. > > If it has, care to tell me the links where I may get > it ? > > Alternatively, if no one knows of anyone having a > working linux mipsel Netscape binary / rpm. Anyone > care to guess the scope of attempting to modify the > x86 or mips-sgi-irix sources to run on mips ? If you check more exactly you'll find that all the sources are actually binaries ... I had Mozilla running on Linux/MIPS three years ago but didn't continue to debug it. Getting it to work shouldn't be rocket science. The text mode browsers lynx, w3m or link just work. Ralf From owner-linux-mips@oss.sgi.com Mon May 21 03:52:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LAqjG05568 for linux-mips-outgoing; Mon, 21 May 2001 03:52:45 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LAqiF05565 for ; Mon, 21 May 2001 03:52:44 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA13389 for ; Mon, 21 May 2001 03:52:38 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id DAA28882 for ; Mon, 21 May 2001 03:52:36 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id MAA18278 for ; Mon, 21 May 2001 12:51:49 +0200 (MEST) Message-ID: <3B08F344.333B746C@mips.com> Date: Mon, 21 May 2001 12:51:48 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Memory segments Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 799 Lines: 21 In the macros PHYSADDR, KSEG0ADDR, KSEG1ADDR, KSEG2ADDR and KSEG3ADDR in include/asm-mips64/addrspace.h the addresses are and'ed with 0x000000ffffffffffUL, instead of and'ed with 0x000000001fffffffUL why is that ? I do understand the address space is extended in 64 bit mode, but the macros is used to manipulate KSEG0 and KSEG1 addresses, which is located between 0xffffffff80000000-0xffffffffbfffffff. So the macros are broken if you change an address from KSEG1 to KSEG0. /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon May 21 05:04:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LC4AB07513 for linux-mips-outgoing; Mon, 21 May 2001 05:04:10 -0700 Received: from intranet.medialincs.com ([210.126.9.6]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LC48F07506 for ; Mon, 21 May 2001 05:04:09 -0700 Received: (from root@localhost) by intranet.medialincs.com (2.5 Build 2630 (Berkeley 8.8.6)/8.8.4) id VAA12651 for linux-mips@oss.sgi.com; Mon, 21 May 2001 21:07:29 +0900 Date: Mon, 21 May 2001 21:07:29 +0900 Message-Id: <200105211207.VAA12651@intranet.medialincs.com> From: =?EUC-KR?B?wba+58iv?= To: linux-mips@oss.sgi.com Cc: Subject: udp, tcp checksum error? MIME-Version: 1.0 X-Mailer: IntraWorks Mailer 1.0 X-Deliver-Express: no X-Deliver-Reply: no X-Deliver-AutoReply: no Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f4LC49F07507 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 397 Lines: 15 hello. I'm booting up by nfs-root. nfs server is RH-7.0 and kernel 2.4.4 , this machine's nfs is good working but when target mips machine connect to host by UDP, wrong checksum UDP packet is discarded. i use mips big endian toolchains(20010303), kernel sorce is CVS update version. I thinks include/asm-mips/checksum.h logic is different from i386's anyone have idea this problem? thanx. From owner-linux-mips@oss.sgi.com Mon May 21 15:28:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LMST821945 for linux-mips-outgoing; Mon, 21 May 2001 15:28:29 -0700 Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LMSTF21941 for ; Mon, 21 May 2001 15:28:29 -0700 Received: from [192.168.1.3] (h00104b670a0d.ne.mediaone.net [65.96.137.220]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f4LMSR613462 for ; Mon, 21 May 2001 18:28:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: mjpento@pop.ne.mediaone.net Message-Id: Date: Mon, 21 May 2001 18:30:01 -0400 To: linux-mips@oss.sgi.com From: mjpento Subject: Elan in R3000??? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 187 Lines: 8 Hi Folks, My apologies if this is off topic a bit. Does anyone know if an Elan graphics subsystem will work in an Indigo R3000? Or is that something for the R4000 only? Thanks, Mike From owner-linux-mips@oss.sgi.com Mon May 21 15:44:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LMiKP22502 for linux-mips-outgoing; Mon, 21 May 2001 15:44:20 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LMiKF22498 for ; Mon, 21 May 2001 15:44:20 -0700 Received: from csh.rit.edu (anna.csh.rit.edu [129.21.60.133]) by mcp.csh.rit.edu (Postfix) with ESMTP id 85F961165 for ; Mon, 21 May 2001 18:44:18 -0400 (EDT) Message-ID: <3B099A91.5030300@csh.rit.edu> Date: Mon, 21 May 2001 18:45:37 -0400 From: George Gensure User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-pre3 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: newest kernel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 224 Lines: 7 I build the 2.4.3 #5 kernel from the CVS source, and have had some trouble with specific programs. I get illegal instruction errors on find and tar. Is there anything I can do to correct this? George werkt@csh.rit.edu From owner-linux-mips@oss.sgi.com Mon May 21 15:50:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LMos222810 for linux-mips-outgoing; Mon, 21 May 2001 15:50:54 -0700 Received: from gw.cs.nsw.gov.au (gw1.cs.nsw.gov.au [152.76.0.130]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LMorF22807 for ; Mon, 21 May 2001 15:50:53 -0700 Received: from funnelweb.cs.nsw.gov.au ([152.76.2.177]) by gw1.gw.cs.nsw.gov.au with ESMTP id <119054>; Tue, 22 May 2001 08:51:29 +1000 Received: from nuc153.crg.cs.nsw.gov.au ([152.76.85.153]) by funnelweb.cs.nsw.gov.au (Post.Office MTA v3.5.1 release 219 ID# 0-0U10L2S100) with ESMTP id au; Tue, 22 May 2001 08:50:44 +1000 Received: from nmrf.org.au (really [152.76.85.139]) by nucmed.crg.cs.nsw.gov.au via smail with esmtp (ident markp using rfc1413) id (Debian Smail3.2.0.111) for ; Tue, 22 May 2001 09:06:17 +1000 (EST) Message-ID: <3B09A060.47F9A2D3@nmrf.org.au> Date: Tue, 22 May 2001 09:10:24 +1000 From: Mark Pearson Organization: Nuclear Medicine Research Foundation X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: mjpento CC: linux-mips@oss.sgi.com Subject: Re: Elan in R3000??? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 418 Lines: 17 mjpento wrote: > Hi Folks, > > My apologies if this is off topic a bit. Does anyone know if > an Elan graphics subsystem will work in an Indigo R3000? Or is that > something for the R4000 only? > > Thanks, > Mike I have an Indigo Elan R3000. This machine was originally purchased before the R4000 was available, so I don't know if there is a processor specific version of the graphics system. Mark Pearson From owner-linux-mips@oss.sgi.com Mon May 21 16:13:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LNDXZ23525 for linux-mips-outgoing; Mon, 21 May 2001 16:13:33 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LNDVF23522 for ; Mon, 21 May 2001 16:13:31 -0700 Received: from mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4LNDM017628; Mon, 21 May 2001 16:13:22 -0700 Message-ID: <3B09A074.2010809@mvista.com> Date: Mon, 21 May 2001 16:10:44 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: en MIME-Version: 1.0 To: George Gensure CC: linux-mips@oss.sgi.com Subject: Re: newest kernel References: <3B099A91.5030300@csh.rit.edu> Content-Type: multipart/mixed; boundary="------------070109020602010607080208" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4445 Lines: 159 This is a multi-part message in MIME format. --------------070109020602010607080208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George Gensure wrote: > I build the 2.4.3 #5 kernel from the CVS source, and have had some > trouble with specific programs. I get illegal instruction errors on > find and tar. Is there anything I can do to correct this? I'm guessing you're running into the sys_sysmips problem. A patch has not yet been applied to the oss.sgi.com kernel. I've attached a patch from Florian that seems to work well and should apply cleanly. Pete --------------070109020602010607080208 Content-Type: text/plain; name="sysmips_02.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sysmips_02.patch" diff -Nur linux.orig/arch/mips/kernel/Makefile linux/arch/mips/kernel/Makefile --- linux.orig/arch/mips/kernel/Makefile Mon Apr 9 00:23:08 2001 +++ linux/arch/mips/kernel/Makefile Mon Apr 9 00:23:34 2001 @@ -20,7 +20,7 @@ obj-y += branch.o process.o signal.o entry.o \ traps.o ptrace.o vm86.o ioport.o reset.o \ semaphore.o setup.o syscall.o sysmips.o \ - ipc.o scall_o32.o unaligned.o + ipc.o scall_o32.o unaligned.o fast-sysmips.o obj-$(CONFIG_MODULES) += mips_ksyms.o ifdef CONFIG_CPU_R3000 @@ -69,5 +69,6 @@ entry.o: entry.S head.o: head.S +fast-sysmips.o: fast-sysmips.S include $(TOPDIR)/Rules.make diff -Nur linux.orig/arch/mips/kernel/fast-sysmips.S linux/arch/mips/kernel/fast-sysmips.S --- linux.orig/arch/mips/kernel/fast-sysmips.S Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/kernel/fast-sysmips.S Mon Apr 9 00:28:20 2001 @@ -0,0 +1,85 @@ +/* + * MIPS_ATOMIC_SET asm implementation for ll/sc capable cpus + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2001 Florian Lohoff + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define PT_TRACESYS 0x00000002 + + EXPORT(fast_sysmips) + + .set noreorder + + li t0, MIPS_ATOMIC_SET + beq a0, t0, 1f + nop + j sys_sysmips + nop + +1: + + # a0 - MIPS_ATOMIC_SET + # a1 - mem ptr + # a2 - value + + addiu sp, sp, -8 # Reserve space + sw a0, (sp) # Save arg0 + + addiu a0, a1, 4 # addr+size + ori v0, a1, 4 # addr | size + lw v1, THREAD_CURDS(gp) # current->thread.current_ds + or v0, v0, a0 # addr | size | (addr+size) + and v1, v1, v0 # (mask)&(addr | size | (addr+size) + bltz v1, 5f + nop + +2: + ll v0, (a1) + move t0, a2 + sc t0, (a1) + beqz t0, 2b + nop + + sw v0, PT_R2+8(sp) # Result value + sw zero, PT_R7+8(sp) # Success indicator + + lw t0, TASK_PTRACE(gp) # syscall tracing enabled? + andi t0, PT_TRACESYS + bnez t0, 3f + nop + +4: + lw a0, (sp) # Restore arg0 + addiu sp, sp, 8 # Restore sp + + j o32_ret_from_sys_call + nop + +3: + sw ra, 4(sp) + jal syscall_trace + nop + lw ra, 4(sp) + j 4b + nop + +5: + lw a0, (sp) # Restore arg0 + addiu sp, sp, 8 # Restore sp + j ra + li v0, -EFAULT + diff -Nur linux.orig/arch/mips/kernel/irix5sys.h linux/arch/mips/kernel/irix5sys.h --- linux.orig/arch/mips/kernel/irix5sys.h Mon Apr 9 00:16:29 2001 +++ linux/arch/mips/kernel/irix5sys.h Sun Apr 8 21:21:16 2001 @@ -69,7 +69,7 @@ SYS(irix_getgid, 0) /* 1047 getgid() V*/ SYS(irix_unimp, 0) /* 1048 (XXX IRIX 4 ssig) V*/ SYS(irix_msgsys, 6) /* 1049 sys_msgsys V*/ -SYS(sys_sysmips, 4) /* 1050 sysmips() HV*/ +SYS(fast_sysmips, 4) /* 1050 sysmips() HV*/ SYS(irix_unimp, 0) /* 1051 XXX sysacct() IV*/ SYS(irix_shmsys, 5) /* 1052 sys_shmsys V*/ SYS(irix_semsys, 0) /* 1053 sys_semsys V*/ diff -Nur linux.orig/arch/mips/kernel/syscalls.h linux/arch/mips/kernel/syscalls.h --- linux.orig/arch/mips/kernel/syscalls.h Mon Apr 9 00:16:30 2001 +++ linux/arch/mips/kernel/syscalls.h Sun Apr 8 21:21:43 2001 @@ -163,7 +163,7 @@ SYS(sys_writev, 3) SYS(sys_cacheflush, 3) SYS(sys_cachectl, 3) -SYS(sys_sysmips, 4) +SYS(fast_sysmips, 4) SYS(sys_ni_syscall, 0) /* 4150 */ SYS(sys_getsid, 1) SYS(sys_fdatasync, 0) --------------070109020602010607080208-- From owner-linux-mips@oss.sgi.com Mon May 21 16:24:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LNOAD23837 for linux-mips-outgoing; Mon, 21 May 2001 16:24:10 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LNO8F23833 for ; Mon, 21 May 2001 16:24:09 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4LNO7018484; Mon, 21 May 2001 16:24:07 -0700 Message-ID: <3B09A388.8AC77827@mvista.com> Date: Mon, 21 May 2001 16:23:52 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Pete Popov CC: George Gensure , linux-mips@oss.sgi.com Subject: Re: newest kernel References: <3B099A91.5030300@csh.rit.edu> <3B09A074.2010809@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5618 Lines: 155 The patch seems to be just a fast implementation of sysmips(). Why would it solve an otherwise illegal instruction problem? George, what was exactly the error and the faulty instruction? Jun Pete Popov wrote: > > George Gensure wrote: > > > I build the 2.4.3 #5 kernel from the CVS source, and have had some > > trouble with specific programs. I get illegal instruction errors on > > find and tar. Is there anything I can do to correct this? > > I'm guessing you're running into the sys_sysmips problem. A patch has > not yet been applied to the oss.sgi.com kernel. I've attached a patch > from Florian that seems to work well and should apply cleanly. > > Pete > > ------------------------------------------------------------------------------ > diff -Nur linux.orig/arch/mips/kernel/Makefile linux/arch/mips/kernel/Makefile > --- linux.orig/arch/mips/kernel/Makefile Mon Apr 9 00:23:08 2001 > +++ linux/arch/mips/kernel/Makefile Mon Apr 9 00:23:34 2001 > @@ -20,7 +20,7 @@ > obj-y += branch.o process.o signal.o entry.o \ > traps.o ptrace.o vm86.o ioport.o reset.o \ > semaphore.o setup.o syscall.o sysmips.o \ > - ipc.o scall_o32.o unaligned.o > + ipc.o scall_o32.o unaligned.o fast-sysmips.o > obj-$(CONFIG_MODULES) += mips_ksyms.o > > ifdef CONFIG_CPU_R3000 > @@ -69,5 +69,6 @@ > > entry.o: entry.S > head.o: head.S > +fast-sysmips.o: fast-sysmips.S > > include $(TOPDIR)/Rules.make > diff -Nur linux.orig/arch/mips/kernel/fast-sysmips.S linux/arch/mips/kernel/fast-sysmips.S > --- linux.orig/arch/mips/kernel/fast-sysmips.S Thu Jan 1 01:00:00 1970 > +++ linux/arch/mips/kernel/fast-sysmips.S Mon Apr 9 00:28:20 2001 > @@ -0,0 +1,85 @@ > +/* > + * MIPS_ATOMIC_SET asm implementation for ll/sc capable cpus > + * > + * This file is subject to the terms and conditions of the GNU General Public > + * License. See the file "COPYING" in the main directory of this archive > + * for more details. > + * > + * Copyright (C) 2001 Florian Lohoff > + * > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define PT_TRACESYS 0x00000002 > + > + EXPORT(fast_sysmips) > + > + .set noreorder > + > + li t0, MIPS_ATOMIC_SET > + beq a0, t0, 1f > + nop > + j sys_sysmips > + nop > + > +1: > + > + # a0 - MIPS_ATOMIC_SET > + # a1 - mem ptr > + # a2 - value > + > + addiu sp, sp, -8 # Reserve space > + sw a0, (sp) # Save arg0 > + > + addiu a0, a1, 4 # addr+size > + ori v0, a1, 4 # addr | size > + lw v1, THREAD_CURDS(gp) # current->thread.current_ds > + or v0, v0, a0 # addr | size | (addr+size) > + and v1, v1, v0 # (mask)&(addr | size | (addr+size) > + bltz v1, 5f > + nop > + > +2: > + ll v0, (a1) > + move t0, a2 > + sc t0, (a1) > + beqz t0, 2b > + nop > + > + sw v0, PT_R2+8(sp) # Result value > + sw zero, PT_R7+8(sp) # Success indicator > + > + lw t0, TASK_PTRACE(gp) # syscall tracing enabled? > + andi t0, PT_TRACESYS > + bnez t0, 3f > + nop > + > +4: > + lw a0, (sp) # Restore arg0 > + addiu sp, sp, 8 # Restore sp > + > + j o32_ret_from_sys_call > + nop > + > +3: > + sw ra, 4(sp) > + jal syscall_trace > + nop > + lw ra, 4(sp) > + j 4b > + nop > + > +5: > + lw a0, (sp) # Restore arg0 > + addiu sp, sp, 8 # Restore sp > + j ra > + li v0, -EFAULT > + > diff -Nur linux.orig/arch/mips/kernel/irix5sys.h linux/arch/mips/kernel/irix5sys.h > --- linux.orig/arch/mips/kernel/irix5sys.h Mon Apr 9 00:16:29 2001 > +++ linux/arch/mips/kernel/irix5sys.h Sun Apr 8 21:21:16 2001 > @@ -69,7 +69,7 @@ > SYS(irix_getgid, 0) /* 1047 getgid() V*/ > SYS(irix_unimp, 0) /* 1048 (XXX IRIX 4 ssig) V*/ > SYS(irix_msgsys, 6) /* 1049 sys_msgsys V*/ > -SYS(sys_sysmips, 4) /* 1050 sysmips() HV*/ > +SYS(fast_sysmips, 4) /* 1050 sysmips() HV*/ > SYS(irix_unimp, 0) /* 1051 XXX sysacct() IV*/ > SYS(irix_shmsys, 5) /* 1052 sys_shmsys V*/ > SYS(irix_semsys, 0) /* 1053 sys_semsys V*/ > diff -Nur linux.orig/arch/mips/kernel/syscalls.h linux/arch/mips/kernel/syscalls.h > --- linux.orig/arch/mips/kernel/syscalls.h Mon Apr 9 00:16:30 2001 > +++ linux/arch/mips/kernel/syscalls.h Sun Apr 8 21:21:43 2001 > @@ -163,7 +163,7 @@ > SYS(sys_writev, 3) > SYS(sys_cacheflush, 3) > SYS(sys_cachectl, 3) > -SYS(sys_sysmips, 4) > +SYS(fast_sysmips, 4) > SYS(sys_ni_syscall, 0) /* 4150 */ > SYS(sys_getsid, 1) > SYS(sys_fdatasync, 0) From owner-linux-mips@oss.sgi.com Mon May 21 16:27:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LNRrE24115 for linux-mips-outgoing; Mon, 21 May 2001 16:27:53 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LNRqF24112 for ; Mon, 21 May 2001 16:27:52 -0700 Received: from mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4LNRl018762; Mon, 21 May 2001 16:27:47 -0700 Message-ID: <3B09A3D6.1040405@mvista.com> Date: Mon, 21 May 2001 16:25:10 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: George Gensure , linux-mips@oss.sgi.com Subject: Re: newest kernel References: <3B099A91.5030300@csh.rit.edu> <3B09A074.2010809@mvista.com> <3B09A388.8AC77827@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5803 Lines: 166 Jun Sun wrote: >The patch seems to be just a fast implementation of sysmips(). Why would it >solve an otherwise illegal instruction problem? > >George, what was exactly the error and the faulty instruction? > This is the pthread patch, so it's not just fast sysmips. I think George's tar and find are probably linked with pthread, thus causing the problem. Pete >Jun > >Pete Popov wrote: > >>George Gensure wrote: >> >>>I build the 2.4.3 #5 kernel from the CVS source, and have had some >>>trouble with specific programs. I get illegal instruction errors on >>>find and tar. Is there anything I can do to correct this? >>> >>I'm guessing you're running into the sys_sysmips problem. A patch has >>not yet been applied to the oss.sgi.com kernel. I've attached a patch >>from Florian that seems to work well and should apply cleanly. >> >>Pete >> >> ------------------------------------------------------------------------------ >>diff -Nur linux.orig/arch/mips/kernel/Makefile linux/arch/mips/kernel/Makefile >>--- linux.orig/arch/mips/kernel/Makefile Mon Apr 9 00:23:08 2001 >>+++ linux/arch/mips/kernel/Makefile Mon Apr 9 00:23:34 2001 >>@@ -20,7 +20,7 @@ >> obj-y += branch.o process.o signal.o entry.o \ >> traps.o ptrace.o vm86.o ioport.o reset.o \ >> semaphore.o setup.o syscall.o sysmips.o \ >>- ipc.o scall_o32.o unaligned.o >>+ ipc.o scall_o32.o unaligned.o fast-sysmips.o >> obj-$(CONFIG_MODULES) += mips_ksyms.o >> >> ifdef CONFIG_CPU_R3000 >>@@ -69,5 +69,6 @@ >> >> entry.o: entry.S >> head.o: head.S >>+fast-sysmips.o: fast-sysmips.S >> >> include $(TOPDIR)/Rules.make >>diff -Nur linux.orig/arch/mips/kernel/fast-sysmips.S linux/arch/mips/kernel/fast-sysmips.S >>--- linux.orig/arch/mips/kernel/fast-sysmips.S Thu Jan 1 01:00:00 1970 >>+++ linux/arch/mips/kernel/fast-sysmips.S Mon Apr 9 00:28:20 2001 >>@@ -0,0 +1,85 @@ >>+/* >>+ * MIPS_ATOMIC_SET asm implementation for ll/sc capable cpus >>+ * >>+ * This file is subject to the terms and conditions of the GNU General Public >>+ * License. See the file "COPYING" in the main directory of this archive >>+ * for more details. >>+ * >>+ * Copyright (C) 2001 Florian Lohoff >>+ * >>+ */ >>+#include >>+#include >>+#include >>+#include >>+#include >>+#include >>+#include >>+#include >>+#include >>+ >>+#define PT_TRACESYS 0x00000002 >>+ >>+ EXPORT(fast_sysmips) >>+ >>+ .set noreorder >>+ >>+ li t0, MIPS_ATOMIC_SET >>+ beq a0, t0, 1f >>+ nop >>+ j sys_sysmips >>+ nop >>+ >>+1: >>+ >>+ # a0 - MIPS_ATOMIC_SET >>+ # a1 - mem ptr >>+ # a2 - value >>+ >>+ addiu sp, sp, -8 # Reserve space >>+ sw a0, (sp) # Save arg0 >>+ >>+ addiu a0, a1, 4 # addr+size >>+ ori v0, a1, 4 # addr | size >>+ lw v1, THREAD_CURDS(gp) # current->thread.current_ds >>+ or v0, v0, a0 # addr | size | (addr+size) >>+ and v1, v1, v0 # (mask)&(addr | size | (addr+size) >>+ bltz v1, 5f >>+ nop >>+ >>+2: >>+ ll v0, (a1) >>+ move t0, a2 >>+ sc t0, (a1) >>+ beqz t0, 2b >>+ nop >>+ >>+ sw v0, PT_R2+8(sp) # Result value >>+ sw zero, PT_R7+8(sp) # Success indicator >>+ >>+ lw t0, TASK_PTRACE(gp) # syscall tracing enabled? >>+ andi t0, PT_TRACESYS >>+ bnez t0, 3f >>+ nop >>+ >>+4: >>+ lw a0, (sp) # Restore arg0 >>+ addiu sp, sp, 8 # Restore sp >>+ >>+ j o32_ret_from_sys_call >>+ nop >>+ >>+3: >>+ sw ra, 4(sp) >>+ jal syscall_trace >>+ nop >>+ lw ra, 4(sp) >>+ j 4b >>+ nop >>+ >>+5: >>+ lw a0, (sp) # Restore arg0 >>+ addiu sp, sp, 8 # Restore sp >>+ j ra >>+ li v0, -EFAULT >>+ >>diff -Nur linux.orig/arch/mips/kernel/irix5sys.h linux/arch/mips/kernel/irix5sys.h >>--- linux.orig/arch/mips/kernel/irix5sys.h Mon Apr 9 00:16:29 2001 >>+++ linux/arch/mips/kernel/irix5sys.h Sun Apr 8 21:21:16 2001 >>@@ -69,7 +69,7 @@ >> SYS(irix_getgid, 0) /* 1047 getgid() V*/ >> SYS(irix_unimp, 0) /* 1048 (XXX IRIX 4 ssig) V*/ >> SYS(irix_msgsys, 6) /* 1049 sys_msgsys V*/ >>-SYS(sys_sysmips, 4) /* 1050 sysmips() HV*/ >>+SYS(fast_sysmips, 4) /* 1050 sysmips() HV*/ >> SYS(irix_unimp, 0) /* 1051 XXX sysacct() IV*/ >> SYS(irix_shmsys, 5) /* 1052 sys_shmsys V*/ >> SYS(irix_semsys, 0) /* 1053 sys_semsys V*/ >>diff -Nur linux.orig/arch/mips/kernel/syscalls.h linux/arch/mips/kernel/syscalls.h >>--- linux.orig/arch/mips/kernel/syscalls.h Mon Apr 9 00:16:30 2001 >>+++ linux/arch/mips/kernel/syscalls.h Sun Apr 8 21:21:43 2001 >>@@ -163,7 +163,7 @@ >> SYS(sys_writev, 3) >> SYS(sys_cacheflush, 3) >> SYS(sys_cachectl, 3) >>-SYS(sys_sysmips, 4) >>+SYS(fast_sysmips, 4) >> SYS(sys_ni_syscall, 0) /* 4150 */ >> SYS(sys_getsid, 1) >> SYS(sys_fdatasync, 0) >> From owner-linux-mips@oss.sgi.com Tue May 22 05:33:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4MCXeJ04368 for linux-mips-outgoing; Tue, 22 May 2001 05:33:40 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MCXdF04365 for ; Tue, 22 May 2001 05:33:39 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id ACBCF7F4; Tue, 22 May 2001 14:33:37 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 276BFF212; Tue, 22 May 2001 14:33:30 +0200 (CEST) Date: Tue, 22 May 2001 14:33:30 +0200 From: Florian Lohoff To: Jun Sun Cc: Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: newest kernel Message-ID: <20010522143330.B9891@paradigm.rfc822.org> References: <3B099A91.5030300@csh.rit.edu> <3B09A074.2010809@mvista.com> <3B09A388.8AC77827@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3B09A388.8AC77827@mvista.com>; from jsun@mvista.com on Mon, May 21, 2001 at 04:23:52PM -0700 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 925 Lines: 21 On Mon, May 21, 2001 at 04:23:52PM -0700, Jun Sun wrote: > The patch seems to be just a fast implementation of sysmips(). Why would it > solve an otherwise illegal instruction problem? > > George, what was exactly the error and the faulty instruction? Wrong - Its not only a "fast" path sysmips. It solves the illegal instruction case as it carefully doesnt touch registers it should not touch. The sysmips illegal instruction stuff came from the early exit needed to skip the -EXXXX case in the scall32.S which did not restore the modified registers. This needed fixing and there was no clean way of doing this in C thus i wrote an asm sysmips/MIPS_ATOMIC_SET and called it "fast_sysmips" which itself would go into the old sysmips function when not MIPS_ATOMIC_SET. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Tue May 22 10:04:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4MH4fl11124 for linux-mips-outgoing; Tue, 22 May 2001 10:04:41 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MH4eF11121 for ; Tue, 22 May 2001 10:04:40 -0700 Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5]) by mcp.csh.rit.edu (Postfix) with ESMTP id 6587611FD; Tue, 22 May 2001 13:04:37 -0400 (EDT) Date: Tue, 22 May 2001 13:04:37 -0400 (EDT) From: George Gensure To: Florian Lohoff Cc: Jun Sun , Pete Popov , Subject: Re: newest kernel In-Reply-To: <20010522143330.B9891@paradigm.rfc822.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1042 Lines: 26 Good call. Thanks everyone, that did it. now if i could just get my cross compiled gcc 3.1 to realize that crti.o exists and should be linked in with libgcc... George werkt@csh.rit.edu On Tue, 22 May 2001, Florian Lohoff wrote: > On Mon, May 21, 2001 at 04:23:52PM -0700, Jun Sun wrote: > > The patch seems to be just a fast implementation of sysmips(). Why would it > > solve an otherwise illegal instruction problem? > > > > George, what was exactly the error and the faulty instruction? > > Wrong - Its not only a "fast" path sysmips. It solves the illegal instruction > case as it carefully doesnt touch registers it should not touch. > > The sysmips illegal instruction stuff came from the early exit > needed to skip the -EXXXX case in the scall32.S which did not > restore the modified registers. This needed fixing and there was > no clean way of doing this in C thus i wrote an asm sysmips/MIPS_ATOMIC_SET > and called it "fast_sysmips" which itself would go into the old > sysmips function when not MIPS_ATOMIC_SET. > > Flo > From owner-linux-mips@oss.sgi.com Tue May 22 12:22:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4MJMtR14462 for linux-mips-outgoing; Tue, 22 May 2001 12:22:55 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MJMsF14459 for ; Tue, 22 May 2001 12:22:54 -0700 Received: from csh.rit.edu (anna.csh.rit.edu [129.21.60.133]) by mcp.csh.rit.edu (Postfix) with ESMTP id D4B7C1131 for ; Tue, 22 May 2001 15:22:51 -0400 (EDT) Message-ID: <3B0ABCD8.6080906@csh.rit.edu> Date: Tue, 22 May 2001 15:24:08 -0400 From: George Gensure User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-pre3 i686; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips Subject: n64 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 186 Lines: 7 I remember seeing something about having an n64 run a port of linux, since it ran (correct me if i'm wrong) an R4400 mips... has anything been done on that? George werkt@csh.rit.edu From owner-linux-mips@oss.sgi.com Tue May 22 15:47:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4MMl7Q19658 for linux-mips-outgoing; Tue, 22 May 2001 15:47:07 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MMl3F19654; Tue, 22 May 2001 15:47:03 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4MMl0004499; Tue, 22 May 2001 15:47:00 -0700 Message-ID: <3B0AEC51.B0C477E1@mvista.com> Date: Tue, 22 May 2001 15:46:41 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Florian Lohoff , ralf@oss.sgi.com CC: Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B099A91.5030300@csh.rit.edu> <3B09A074.2010809@mvista.com> <3B09A388.8AC77827@mvista.com> <20010522143330.B9891@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1712 Lines: 44 Florian Lohoff wrote: > > On Mon, May 21, 2001 at 04:23:52PM -0700, Jun Sun wrote: > > The patch seems to be just a fast implementation of sysmips(). Why would it > > solve an otherwise illegal instruction problem? > > > > George, what was exactly the error and the faulty instruction? > > Wrong - Its not only a "fast" path sysmips. It solves the illegal instruction > case as it carefully doesnt touch registers it should not touch. > > The sysmips illegal instruction stuff came from the early exit > needed to skip the -EXXXX case in the scall32.S which did not > restore the modified registers. This needed fixing and there was > no clean way of doing this in C thus i wrote an asm sysmips/MIPS_ATOMIC_SET > and called it "fast_sysmips" which itself would go into the old > sysmips function when not MIPS_ATOMIC_SET. > I see. I took a look of MIPS ABI in system V and found that the spec only specifies this extended call in C prototype: int _test_and_set(int *p, int v); It seems perfectly legal for us to add one more argument to store the return value while still have the function returns error. Of course, doing that will break binary compatibility. Otherwise, I think Flo's patch is the best fix to satisfy the spec and binary compatibility although it is a little clunky. A third possibility is the have a MIPS_NEW_ATOMIC_SET that take three arguments. If that approach is taken, I would take out the inline assembly that jumps to o32_ret_from_sys_call and documents MIPS_ATOMIC_SET as deprecated and valnerable. My preference, in the decreasing order, is 3), 2) and 1). Ralf, what do you think? We cannot let the bug sit around in the CVS tree for long. Have to have some fix. Jun From owner-linux-mips@oss.sgi.com Tue May 22 21:34:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4N4YL725727 for linux-mips-outgoing; Tue, 22 May 2001 21:34:21 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N4YJF25724 for ; Tue, 22 May 2001 21:34:19 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4N4NRG03149; Wed, 23 May 2001 01:23:27 -0300 Date: Wed, 23 May 2001 01:23:27 -0300 From: Ralf Baechle To: George Gensure Cc: linux-mips Subject: Re: n64 Message-ID: <20010523012327.D2004@bacchus.dhis.org> References: <3B0ABCD8.6080906@csh.rit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B0ABCD8.6080906@csh.rit.edu>; from werkt@csh.rit.edu on Tue, May 22, 2001 at 03:24:08PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 285 Lines: 9 On Tue, May 22, 2001 at 03:24:08PM -0400, George Gensure wrote: > I remember seeing something about having an n64 run a port of linux, > since it ran (correct me if i'm wrong) an R4400 mips... has anything > been done on that? R4300i based and no, nobody did serious work. Ralf From owner-linux-mips@oss.sgi.com Tue May 22 23:41:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4N6f8x28685 for linux-mips-outgoing; Tue, 22 May 2001 23:41:08 -0700 Received: from blackdog.wirespeed.com ([208.170.106.25]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N6f4F28681; Tue, 22 May 2001 23:41:04 -0700 Received: from redhat.com (IDENT:joe@dhcp-247.hsv.redhat.com [172.16.17.247] (may be forged)) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id BAA03739; Wed, 23 May 2001 01:27:11 -0500 Message-ID: <3B0B5AC6.6060208@redhat.com> Date: Wed, 23 May 2001 01:37:58 -0500 From: Joe deBlaquiere User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.8.1) Gecko/20010422 X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B099A91.5030300@csh.rit.edu> <3B09A074.2010809@mvista.com> <3B09A388.8AC77827@mvista.com> <20010522143330.B9891@paradigm.rfc822.org> <3B0AEC51.B0C477E1@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2485 Lines: 69 I would vote for option #4 - make sure the ll/sc emulation stuff works and use ll/sc in glibc instead of sysmips. Beyond the pthreads mutex stuff in glibc I have yet to come across usage of sysmips. Of course you still need sys_sysmips to function correctly (in case somebody did a silly thing like call sysmips directly just for the fun of it), so I like like Florian's solution. Adding a parameter is a silly thing to do, and we don't need to be adding functionality to sys_sysmips through NEW_MO_BETTER_AS_SEEN_ON_TV_ATOMIC_SET or what have you... Joe Jun Sun wrote: > Florian Lohoff wrote: > >> On Mon, May 21, 2001 at 04:23:52PM -0700, Jun Sun wrote: >> >>> The patch seems to be just a fast implementation of sysmips(). Why would it >>> solve an otherwise illegal instruction problem? >>> >>> George, what was exactly the error and the faulty instruction? >> >> Wrong - Its not only a "fast" path sysmips. It solves the illegal instruction >> case as it carefully doesnt touch registers it should not touch. >> >> The sysmips illegal instruction stuff came from the early exit >> needed to skip the -EXXXX case in the scall32.S which did not >> restore the modified registers. This needed fixing and there was >> no clean way of doing this in C thus i wrote an asm sysmips/MIPS_ATOMIC_SET >> and called it "fast_sysmips" which itself would go into the old >> sysmips function when not MIPS_ATOMIC_SET. >> > > > I see. > > I took a look of MIPS ABI in system V and found that the spec only specifies > this extended call in C prototype: > > int _test_and_set(int *p, int v); > > It seems perfectly legal for us to add one more argument to store the return > value while still have the function returns error. Of course, doing that will > break binary compatibility. > > Otherwise, I think Flo's patch is the best fix to satisfy the spec and binary > compatibility although it is a little clunky. > > A third possibility is the have a MIPS_NEW_ATOMIC_SET that take three > arguments. If that approach is taken, I would take out the inline assembly > that jumps to o32_ret_from_sys_call and documents MIPS_ATOMIC_SET as > deprecated and valnerable. > > My preference, in the decreasing order, is 3), 2) and 1). > > Ralf, what do you think? We cannot let the bug sit around in the CVS tree for > long. Have to have some fix. > > Jun -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Wed May 23 06:47:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NDli307360 for linux-mips-outgoing; Wed, 23 May 2001 06:47:44 -0700 Received: from babbage.millersville.edu (babbage.millersville.edu [166.66.24.49]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NDlhF07357 for ; Wed, 23 May 2001 06:47:43 -0700 Received: from localhost (joshua@localhost) by babbage.millersville.edu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA10521 for ; Wed, 23 May 2001 09:45:54 -0400 Date: Wed, 23 May 2001 09:45:54 -0400 (EDT) From: To: linux-mips@oss.sgi.com Subject: wrt irc In-Reply-To: <3B0AEC51.B0C477E1@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 337 Lines: 7 The other day on irc.openprojects.net #mipslinux, someone said that the initial O2 port was done using the irix header files to glean enough hardware info to make the needed changes. How would this process work? Could someone post examples of how parts of the header files indicate how to get something else to boot on the hardware? From owner-linux-mips@oss.sgi.com Wed May 23 06:51:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NDphB07592 for linux-mips-outgoing; Wed, 23 May 2001 06:51:43 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NDmwF07408; Wed, 23 May 2001 06:49:00 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA05551; Wed, 23 May 2001 15:34:14 +0200 (MET DST) Date: Wed, 23 May 2001 15:34:13 +0200 (MET DST) From: "Maciej W. Rozycki" To: Joe deBlaquiere cc: Jun Sun , Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B0B5AC6.6060208@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 713 Lines: 17 On Wed, 23 May 2001, Joe deBlaquiere wrote: > I would vote for option #4 - make sure the ll/sc emulation stuff works > and use ll/sc in glibc instead of sysmips. Beyond the pthreads mutex Please don't. The emulation is an overkill here and the overhead is painful for ISA I systems, which are usually not the fastest ones. This has already been discussed here. If you want to go for speed and use ll/sc on an ISA II+ system, then compile glibc for ISA II or better. It will never call sysmips() then. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 23 06:59:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NDxdp08072 for linux-mips-outgoing; Wed, 23 May 2001 06:59:39 -0700 Received: from delta.ds2.pg.gda.pl (root@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NDx3F08049; Wed, 23 May 2001 06:59:05 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA04954; Wed, 23 May 2001 15:18:39 +0200 (MET DST) Date: Wed, 23 May 2001 15:18:39 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Jun Sun cc: Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B0AEC51.B0C477E1@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2107 Lines: 47 On Tue, 22 May 2001, Jun Sun wrote: > I took a look of MIPS ABI in system V and found that the spec only specifies > this extended call in C prototype: > > int _test_and_set(int *p, int v); > > It seems perfectly legal for us to add one more argument to store the return > value while still have the function returns error. Of course, doing that will > break binary compatibility. We have _test_and_set() in the library. Implementing a clean underlying _test_and_set() syscall is very high on my to-do list -- lack of time prevents me from finishing it, unfortunately. There is no point to mess with sysmips() any further, I think. The library's _test_and_set() only calls sysmips() if the library was compiled for ISA I systems. As I guess from reports on the list, ISA I systems are a minority, mostly DECstations and possibly a few embedded systems. Most people have ISA II+ and they do not need to call any syscall from _test_and_set() at all. For ISA II+ systems the library implements _test_and_set() in the userland, using ll/sc appropriately. Anyone having ISA II+ systems only, please do yourself a favour and set "-mips2" (or maybe even "-mips3") somewhere in your CFLAGS for all compilations -- not only you'll get better optimized binaries, but you'll get rid of this sysmips() problem as well. > Otherwise, I think Flo's patch is the best fix to satisfy the spec and binary > compatibility although it is a little clunky. I'll have yet to look at the patch, but what I think is, we should get sysmips() work as defined by the original spec (or as reverse-engineered, as the real spec seems to be out of reach). Everything else belong to a separate implementation. Binary compatibility is not a necessity here. The only sysmips() client is glibc at the moment, and it can be updated to use a new syscall at any time. In short: let's leave sysmips() semantics alone. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 23 07:38:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NEcCB09362 for linux-mips-outgoing; Wed, 23 May 2001 07:38:12 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NEcAF09359 for ; Wed, 23 May 2001 07:38:11 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id QAA58094 for ; Wed, 23 May 2001 16:38:09 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 152Zm5-000351-00 for ; Wed, 23 May 2001 16:38:09 +0200 Date: Wed, 23 May 2001 16:38:09 +0200 To: linux-mips Subject: Re: n64 Message-ID: <20010523163809.B11643@rembrandt.csv.ica.uni-stuttgart.de> References: <3B0ABCD8.6080906@csh.rit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3B0ABCD8.6080906@csh.rit.edu>; from werkt@csh.rit.edu on Tue, May 22, 2001 at 03:24:08PM -0400 From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 429 Lines: 13 George Gensure wrote: >I remember seeing something about having an n64 run a port of linux, >since it ran (correct me if i'm wrong) an R4400 mips... has anything >been done on that? I currently do, based on the existing source under arch/mips64 with Indigo2 R10000 Impact as target. No, it isn't working yet. A recent kernel and it's bootlog can be found at http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/ Thiemo From owner-linux-mips@oss.sgi.com Wed May 23 08:20:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NFK7I11314 for linux-mips-outgoing; Wed, 23 May 2001 08:20:07 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NFK7F11311 for ; Wed, 23 May 2001 08:20:07 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 6444EF1A9; Wed, 23 May 2001 08:18:46 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 04A08BBDA; Wed, 23 May 2001 08:19:05 -0700 (PDT) Date: Wed, 23 May 2001 08:19:05 -0700 From: Keith M Wesolowski To: joshua@babbage.millersv.edu Cc: linux-mips@oss.sgi.com Subject: Re: porting from headers Message-ID: <20010523081905.A10516@foobazco.org> References: <3B0AEC51.B0C477E1@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from joshua@babbage.millersv.edu on Wed, May 23, 2001 at 09:45:54AM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1809 Lines: 37 On Wed, May 23, 2001 at 09:45:54AM -0400, joshua@babbage.millersv.edu wrote: > The other day on irc.openprojects.net #mipslinux, someone said that the > initial O2 port was done using the irix header files to glean enough > hardware info to make the needed changes. How would this process > work? Could someone post examples of how parts of the header files > indicate how to get something else to boot on the hardware? Start with common sense: 1. It's ARCS, so prom_printf and the ARCS memory map work. 2. It's got an already-supported MIPS CPU. That's enough if you don't screw it up to get to the having no root and must scream point. Then, you look at the headers and see that it has two 16550 serial ports, and you know their addresses. Plug those into the standard peecee serial driver and you have a serial console. Likewise the RTC. You look at crime.h and see the CRIME_TIME mechanism, along with its frequency, and you guess that you can calibrate your system timer from that. Now your timers are right. You want PCI, that's another matter; you can pull out the config space pointers and read/write the config space rather easily from the headers, and likewise it gives you the CPU physical addresses for device BARs. But nobody will tell you that most of these spaces need to be swapped... :-) Basically the headers give you the addresses of registers and occasionally their formats. If you're clever you can figure out how to go from there. I'm not so clever so it's been something like 8 months I've been fooling with this. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Wed May 23 08:54:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NFsaX12452 for linux-mips-outgoing; Wed, 23 May 2001 08:54:36 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NFsZF12449 for ; Wed, 23 May 2001 08:54:35 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA10315; Wed, 23 May 2001 11:55:29 -0400 Date: Wed, 23 May 2001 11:55:29 -0400 (EDT) From: X-Sender: nick@ns To: joshua@babbage.millersv.edu cc: linux-mips@oss.sgi.com Subject: Re: wrt irc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 613 Lines: 15 Most of the important addresses are listed in the irix headers. With enough hardware and knowledge you can infer how those addresses are used, and I belive he also decompiled the o2's irix kernel. Nick On Wed, 23 May 2001 joshua@babbage.millersv.edu wrote: > The other day on irc.openprojects.net #mipslinux, someone said that the > initial O2 port was done using the irix header files to glean enough > hardware info to make the needed changes. How would this process > work? Could someone post examples of how parts of the header files > indicate how to get something else to boot on the hardware? > > From owner-linux-mips@oss.sgi.com Wed May 23 08:58:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NFwi112791 for linux-mips-outgoing; Wed, 23 May 2001 08:58:44 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NFwhF12788 for ; Wed, 23 May 2001 08:58:43 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id EA2E4F1A9; Wed, 23 May 2001 08:57:22 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id A7D90BBDD; Wed, 23 May 2001 08:57:42 -0700 (PDT) Date: Wed, 23 May 2001 08:57:42 -0700 From: Keith M Wesolowski To: nick@snowman.net Cc: joshua@babbage.millersv.edu, linux-mips@oss.sgi.com Subject: Re: wrt irc Message-ID: <20010523085742.B10516@foobazco.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@snowman.net on Wed, May 23, 2001 at 11:55:29AM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 724 Lines: 15 On Wed, May 23, 2001 at 11:55:29AM -0400, nick@snowman.net wrote: > Most of the important addresses are listed in the irix headers. With > enough hardware and knowledge you can infer how those addresses are used, > and I belive he also decompiled the o2's irix kernel. Yes, I did; it was a great way to waste a few hours. Nothing of interest came of that. IRIX seems to have many layers of indirection before you actually find the code you want. Not recommended. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Wed May 23 09:02:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NG2sn13148 for linux-mips-outgoing; Wed, 23 May 2001 09:02:54 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NG2rF13145 for ; Wed, 23 May 2001 09:02:53 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA10467; Wed, 23 May 2001 12:03:43 -0400 Date: Wed, 23 May 2001 12:03:43 -0400 (EDT) From: X-Sender: nick@ns To: Keith M Wesolowski cc: joshua@babbage.millersv.edu, linux-mips@oss.sgi.com Subject: Re: wrt irc In-Reply-To: <20010523085742.B10516@foobazco.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1274 Lines: 28 I agree that the IRIX kernel is horribly obfuscated, however it still contains valuable information, and in theory can be decoded. I strongly suspect this is where harold got much of his information, and if one is demented enough, and has enough time much can be learned from it. Curiousity, what is your goal in asking this? There is no magic answer, and it will probably take you months to years if you want to port something useing just the irix headers. Nick On Wed, 23 May 2001, Keith M Wesolowski wrote: > On Wed, May 23, 2001 at 11:55:29AM -0400, nick@snowman.net wrote: > > > Most of the important addresses are listed in the irix headers. With > > enough hardware and knowledge you can infer how those addresses are used, > > and I belive he also decompiled the o2's irix kernel. > > Yes, I did; it was a great way to waste a few hours. Nothing of > interest came of that. IRIX seems to have many layers of indirection > before you actually find the code you want. Not recommended. > > -- > Keith M Wesolowski http://foobazco.org/~wesolows > ------(( Project Foobazco Coordinator and Network Administrator ))------ > "Nothing motivates a man more than to see his boss put > in an honest day's work." -- The fortune file > From owner-linux-mips@oss.sgi.com Wed May 23 10:11:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NHBaL14912 for linux-mips-outgoing; Wed, 23 May 2001 10:11:36 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NHBSF14906; Wed, 23 May 2001 10:11:29 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4NHBK031451; Wed, 23 May 2001 10:11:20 -0700 Message-ID: <3B0BEF23.6538F217@mvista.com> Date: Wed, 23 May 2001 10:10:59 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joe deBlaquiere CC: Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B099A91.5030300@csh.rit.edu> <3B09A074.2010809@mvista.com> <3B09A388.8AC77827@mvista.com> <20010522143330.B9891@paradigm.rfc822.org> <3B0AEC51.B0C477E1@mvista.com> <3B0B5AC6.6060208@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3468 Lines: 95 Joe deBlaquiere wrote: > > I would vote for option #4 - make sure the ll/sc emulation stuff works > and use ll/sc in glibc instead of sysmips. Beyond the pthreads mutex > stuff in glibc I have yet to come across usage of sysmips. Of course you > still need sys_sysmips to function correctly (in case somebody did a > silly thing like call sysmips directly just for the fun of it), so I > like like Florian's solution. > Adding a parameter is a silly thing to do, > and we don't need to be adding functionality to sys_sysmips through > NEW_MO_BETTER_AS_SEEN_ON_TV_ATOMIC_SET or what have you... > I disagree with the ll/sc emulation approach. . ll/sc is difficult to emulate (as anybody who has tried will know) . ll/sc takes a much bigger performance hit. It takes at least two syscalls to complete a sequence of ll/sc instructions. In addition, since each system call takes so much time, it increases the likelihood for the failure of sc instruction, which again decreases the performance. . Although not a strange argument, but sysmips() implementation in pthread provides MIPS I comptability which can be important for, for example, a desktop distribution. > Adding a parameter is a silly thing to do, > and we don't need to be adding functionality to sys_sysmips through > NEW_MO_BETTER_AS_SEEN_ON_TV_ATOMIC_SET or what have you... > Please forgive my silliness again - can you illustrate why this idea sound so silly to you? Jun > Jun Sun wrote: > > > Florian Lohoff wrote: > > > >> On Mon, May 21, 2001 at 04:23:52PM -0700, Jun Sun wrote: > >> > >>> The patch seems to be just a fast implementation of sysmips(). Why would it > >>> solve an otherwise illegal instruction problem? > >>> > >>> George, what was exactly the error and the faulty instruction? > >> > >> Wrong - Its not only a "fast" path sysmips. It solves the illegal instruction > >> case as it carefully doesnt touch registers it should not touch. > >> > >> The sysmips illegal instruction stuff came from the early exit > >> needed to skip the -EXXXX case in the scall32.S which did not > >> restore the modified registers. This needed fixing and there was > >> no clean way of doing this in C thus i wrote an asm sysmips/MIPS_ATOMIC_SET > >> and called it "fast_sysmips" which itself would go into the old > >> sysmips function when not MIPS_ATOMIC_SET. > >> > > > > > > I see. > > > > I took a look of MIPS ABI in system V and found that the spec only specifies > > this extended call in C prototype: > > > > int _test_and_set(int *p, int v); > > > > It seems perfectly legal for us to add one more argument to store the return > > value while still have the function returns error. Of course, doing that will > > break binary compatibility. > > > > Otherwise, I think Flo's patch is the best fix to satisfy the spec and binary > > compatibility although it is a little clunky. > > > > A third possibility is the have a MIPS_NEW_ATOMIC_SET that take three > > arguments. If that approach is taken, I would take out the inline assembly > > that jumps to o32_ret_from_sys_call and documents MIPS_ATOMIC_SET as > > deprecated and valnerable. > > > > My preference, in the decreasing order, is 3), 2) and 1). > > > > Ralf, what do you think? We cannot let the bug sit around in the CVS tree for > > long. Have to have some fix. > > > > Jun > > -- > Joe deBlaquiere > Red Hat, Inc. > 307 Wynn Drive > Huntsville AL, 35805 > voice : (256)-704-9200 > fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Wed May 23 10:41:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NHfpF15712 for linux-mips-outgoing; Wed, 23 May 2001 10:41:51 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NHfmF15708; Wed, 23 May 2001 10:41:48 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4NHdC000808; Wed, 23 May 2001 10:39:12 -0700 Message-ID: <3B0BF5AA.DE13EA3F@mvista.com> Date: Wed, 23 May 2001 10:38:50 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3153 Lines: 72 "Maciej W. Rozycki" wrote: > > On Tue, 22 May 2001, Jun Sun wrote: > > > I took a look of MIPS ABI in system V and found that the spec only specifies > > this extended call in C prototype: > > > > int _test_and_set(int *p, int v); > > > > It seems perfectly legal for us to add one more argument to store the return > > value while still have the function returns error. Of course, doing that will > > break binary compatibility. > > We have _test_and_set() in the library. Implementing a clean underlying > _test_and_set() syscall is very high on my to-do list -- lack of time > prevents me from finishing it, unfortunately. > > There is no point to mess with sysmips() any further, I think. The > library's _test_and_set() only calls sysmips() if the library was compiled > for ISA I systems. As I guess from reports on the list, ISA I systems are > a minority, mostly DECstations and possibly a few embedded systems. Most > people have ISA II+ and they do not need to call any syscall from > _test_and_set() at all. For ISA II+ systems the library implements > _test_and_set() in the userland, using ll/sc appropriately. > > Anyone having ISA II+ systems only, please do yourself a favour and set > "-mips2" (or maybe even "-mips3") somewhere in your CFLAGS for all > compilations -- not only you'll get better optimized binaries, but you'll > get rid of this sysmips() problem as well. > > > Otherwise, I think Flo's patch is the best fix to satisfy the spec and binary > > compatibility although it is a little clunky. > > I'll have yet to look at the patch, but what I think is, we should get > sysmips() work as defined by the original spec (or as reverse-engineered, > as the real spec seems to be out of reach). Everything else belong to a > separate implementation. > > Binary compatibility is not a necessity here. The only sysmips() client > is glibc at the moment, and it can be updated to use a new syscall at any > time. > > In short: let's leave sysmips() semantics alone. > Same old questions : Where is the definition of sysmips()? What is considered standard implementation of sysmips() so that we can do reverse-engineering? Irix? Even if Irix is considered standard implementation of sysmips(), I wonder if we need to mirror it. Here is my reasoning. The sytem V ABI specifies _test_and_set() as the exntended system call. Exactly how we achieve that is up to each implementation of the OS. Therefore, for MIPS I system, we simply choose to call sysmips(NEW_ATOMIC_SET, ....) with three arguments. Any application that bypasses _test_and_set() and calls sysmips() directly is running at its own risk of not being portable. Of course, we need to fix glibc, which seems to be the only client that matters at this moment. In short, I think we DON"T have to maitain the semantic of sysmips(). My understanding is that it is justed used to implement extended MIPS ABS calls. As long as we get those calls implemented correctly, the exact sysmips() semantic does not matter. Did I misundertand something? Along this line, I think I even favor "just change the current ATOMIC_SET" approach. Jun From owner-linux-mips@oss.sgi.com Wed May 23 11:04:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NI4bR16619 for linux-mips-outgoing; Wed, 23 May 2001 11:04:37 -0700 Received: from blackdog.wirespeed.com ([208.170.106.25]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NI4YF16612; Wed, 23 May 2001 11:04:34 -0700 Received: from redhat.com (IDENT:joe@uberdog.hsv.redhat.com [172.16.16.108]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id MAA05949; Wed, 23 May 2001 12:37:53 -0500 Message-ID: <3B0BF7F8.3050306@redhat.com> Date: Wed, 23 May 2001 12:48:40 -0500 From: Joe deBlaquiere User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.8.1) Gecko/20010422 X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Jun Sun , Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2030 Lines: 56 Hi Maciej, Jun, Didn't mean to bring up a sore point, but it seems that we haven't yet come to a consensus on what policy to have here. I think you both make valid points that I don't necesarily disagree with, but I would like to follow the counterpoint a little further. Maciej W. Rozycki wrote: > On Wed, 23 May 2001, Joe deBlaquiere wrote: > > >> I would vote for option #4 - make sure the ll/sc emulation stuff works >> and use ll/sc in glibc instead of sysmips. Beyond the pthreads mutex > > > Please don't. The emulation is an overkill here and the overhead is > painful for ISA I systems, which are usually not the fastest ones. This > has already been discussed here. > There's overhead to sysmips also, so neither one is going to give stunning performance. All out performance isn't likely an issue on one of these systems anyways. > If you want to go for speed and use ll/sc on an ISA II+ system, then > compile glibc for ISA II or better. It will never call sysmips() then. The problem here is that now I have mips, mipsel, and mipselnollsc configurations of the cross-tools, the c library and the binary applications. It's one extra configuration to maintain. There's no way to solve the endianness issues, but using emulation to handle missing instructions (be they floating point or ll/sc, or what-have-you) solves the minor differences in the instruction set from the library/application standpoint. If all MIPS processors used the same instruction set then we wouldn't have the problem at all. Of course there are very good reasons (and probably some silly ones too...) why ISAs are tailored. The kernel is already going to have to adjust some anyway, so keeping the differences in the kernel doesn't increase the testing burden. Throwing the problem over to glibc (and the toolchain) does increase the number of active configurations. Just my opinion. -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Wed May 23 11:15:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NIFqh17281 for linux-mips-outgoing; Wed, 23 May 2001 11:15:52 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NIFpF17278 for ; Wed, 23 May 2001 11:15:51 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA11574; Wed, 23 May 2001 11:15:45 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA28200; Wed, 23 May 2001 11:15:42 -0700 (PDT) Message-ID: <00ec01c0e3b5$00ab83c0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Joe deBlaquiere" Cc: References: <3B0BF7F8.3050306@redhat.com> Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Date: Wed, 23 May 2001 20:20:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1300 Lines: 26 > There's no way to solve the endianness issues, but using emulation to > handle missing instructions (be they floating point or ll/sc, or > what-have-you) solves the minor differences in the instruction set from > the library/application standpoint. If all MIPS processors used the same > instruction set then we wouldn't have the problem at all. Of course > there are very good reasons (and probably some silly ones too...) why > ISAs are tailored. > > The kernel is already going to have to adjust some anyway, so keeping the > differences in the kernel doesn't increase the testing burden. Throwing > the problem over to glibc (and the toolchain) does increase the number > of active configurations. And for the sake of beating a dead horse that perhaps only I can see, there is a philosophical choice that must sometimes be made whether to achieve binary portability by compiling to the lowest-common denominator, or by emulating the missing operations in the OS. The former is more efficient for downrev parts, the latter is more efficient for contemporary parts. Those of us who work on recent and future designs will always tend to favor the latter - what's the point of using MIPS32/MIPS64 and beyond CPUs if gnu/Linux binaries are going to treat them like R3000s? Kevin K. From owner-linux-mips@oss.sgi.com Wed May 23 11:46:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NIksQ18126 for linux-mips-outgoing; Wed, 23 May 2001 11:46:54 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NIkoF18122; Wed, 23 May 2001 11:46:50 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4NIgI005034; Wed, 23 May 2001 11:42:18 -0700 Message-ID: <3B0C0475.B9ACE682@mvista.com> Date: Wed, 23 May 2001 11:41:57 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joe deBlaquiere CC: "Maciej W. Rozycki" , Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B0BF7F8.3050306@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1266 Lines: 30 Joe deBlaquiere wrote: > > Please don't. The emulation is an overkill here and the overhead is > > painful for ISA I systems, which are usually not the fastest ones. This > > has already been discussed here. > > > > There's overhead to sysmips also, so neither one is going to give > stunning performance. All out performance isn't likely an issue on one > of these systems anyways. > Like I said in the previous email, ll/sc emulation is at least twice as bad as sysmips(). The likely failure of sc will make the performance even worse. In addition, the new glibc starts to pthread massively now (try 'ls' and you will see). I do think performance is a factor here. > > If you want to go for speed and use ll/sc on an ISA II+ system, then > > compile glibc for ISA II or better. It will never call sysmips() then. > > The problem here is that now I have mips, mipsel, and mipselnollsc > configurations of the cross-tools, the c library and the binary > applications. It's one extra configuration to maintain. > I see the trouble of having extra configurations. If you were planning to have separate support for MIPS I and MIPS II systems, you should be covered. After all there are only limited number of variants anyway - so far. :-) Jun From owner-linux-mips@oss.sgi.com Wed May 23 11:56:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NIu4t18538 for linux-mips-outgoing; Wed, 23 May 2001 11:56:04 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NItuF18507; Wed, 23 May 2001 11:55:56 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 9407E7F4; Wed, 23 May 2001 20:55:54 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 7EA2FEFD5; Wed, 23 May 2001 20:54:12 +0200 (CEST) Date: Wed, 23 May 2001 20:54:12 +0200 From: Florian Lohoff To: Jun Sun Cc: Joe deBlaquiere , "Maciej W. Rozycki" , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Message-ID: <20010523205412.A10981@paradigm.rfc822.org> References: <3B0BF7F8.3050306@redhat.com> <3B0C0475.B9ACE682@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3B0C0475.B9ACE682@mvista.com>; from jsun@mvista.com on Wed, May 23, 2001 at 11:41:57AM -0700 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1375 Lines: 27 On Wed, May 23, 2001 at 11:41:57AM -0700, Jun Sun wrote: > Like I said in the previous email, ll/sc emulation is at least twice as bad as > sysmips(). The likely failure of sc will make the performance even worse. In > addition, the new glibc starts to pthread massively now (try 'ls' and you will > see). I do think performance is a factor here. There are a lot of glibc issues to have a look at - Try issueing a "sleep" compiled against glibc 2.2 and you'll see at least 20-30 sysmips/shed_yield calls. As for sleep this is completely unecessary but i guess this is common glibc startup code and on most architectures atomic test/set instructions are not as painful as on non ll/sc mips cpus. > I see the trouble of having extra configurations. If you were planning to > have separate support for MIPS I and MIPS II systems, you should be covered. > After all there are only limited number of variants anyway - so far. :-) My favourit would be to let the glibc on runtime decide whether to use sysmips or ll/sc in the atomic test_and_set stuff. This would lead to an common atom op in the userspace which is fast on ll/sc cpus and gives much lesser performance penaltys in the sysmips case than emulating ll/sc. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Wed May 23 11:56:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NIu0v18515 for linux-mips-outgoing; Wed, 23 May 2001 11:56:00 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NItuF18508; Wed, 23 May 2001 11:55:56 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id B0ACC7F7; Wed, 23 May 2001 20:55:54 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 098F2EFD5; Wed, 23 May 2001 20:55:53 +0200 (CEST) Date: Wed, 23 May 2001 20:55:53 +0200 From: Florian Lohoff To: Jun Sun Cc: Joe deBlaquiere , "Maciej W. Rozycki" , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Message-ID: <20010523205552.B10981@paradigm.rfc822.org> References: <3B0BF7F8.3050306@redhat.com> <3B0C0475.B9ACE682@mvista.com> <20010523205412.A10981@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010523205412.A10981@paradigm.rfc822.org>; from flo@rfc822.org on Wed, May 23, 2001 at 08:54:12PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 828 Lines: 20 On Wed, May 23, 2001 at 08:54:12PM +0200, Florian Lohoff wrote: > My favourit would be to let the glibc on runtime decide whether > to use sysmips or ll/sc in the atomic test_and_set stuff. This would > lead to an common atom op in the userspace which is fast on ll/sc > cpus and gives much lesser performance penaltys in the sysmips case > than emulating ll/sc. But again - I tried to run this discussion again and again - As long as there is no code to use there is no point in taking a discussion. I needed a working sysmips for debian as we compile the glibc with sysmips (performance penalty but for now works everywhere) thus i fixed the sysmips. Let the code speak Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Wed May 23 12:45:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NJjLc20131 for linux-mips-outgoing; Wed, 23 May 2001 12:45:21 -0700 Received: from aeon.tvd.be (aeon.tvd.be [195.162.196.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJjCF20126 for ; Wed, 23 May 2001 12:45:13 -0700 Received: from callisto.of.borg (cable-195-162-217-46.upc.chello.be [195.162.217.46]) by aeon.tvd.be (8.9.3/8.9.3/RELAY-1.1) with ESMTP id VAA06296; Wed, 23 May 2001 21:44:55 +0200 (MET DST) Received: from localhost (geert@localhost) by callisto.of.borg (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id VAA20178; Wed, 23 May 2001 21:42:59 +0200 X-Authentication-Warning: callisto.of.borg: geert owned process doing -bs Date: Wed, 23 May 2001 21:42:59 +0200 (CEST) From: Geert Uytterhoeven To: Linux/m68k , Linux/MIPS Development , Linux/PPC on APUS development Subject: wd33c93 cleanup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 39270 Lines: 1051 Hi guys, This is something that has been on my TODO list since a while... Currently wd33c93_regs is a struct containing ugly #ifdef's to add padding, depending on the target you compile for. This has the nasty side-effect that you can no longer compile one kernel that supports both Amiga and MVME147 systems and has working wd33c93 SCSI. Since the wd33c93 has only 2 registers, there's no real need for a complex struct containing the registers, so I replaced it by a struct with two pointers to the registers. Hence no more hardware-specific stuff in wd33c93.h. Affected systems: - Amiga A3000 SCSI - Amiga A2091/A590 SCSI - Various Amiga GVP boards containing `GVP Series II'-compatible SCSI - Motorola MVME147 SCSI - SGI Indy/Indigo2 SCSI Apart from a simple compile test for the Amiga-related drivers, the patch is untested (my sole wd33c93 equipped system is still waiting for the completion of the port of uClinux to the Amiga 500 :-) But of course all feedback is welcome! diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file linux-m68k-2.4.4/drivers/scsi/a2091.c wd33c93-2.4.4/drivers/scsi/a2091.c --- linux-m68k-2.4.4/drivers/scsi/a2091.c Tue Nov 28 02:57:34 2000 +++ wd33c93-2.4.4/drivers/scsi/a2091.c Wed May 23 08:13:56 2001 @@ -190,6 +190,7 @@ struct Scsi_Host *instance; unsigned long address; struct zorro_dev *z = NULL; + wd33c93_regs regs; if (!MACH_IS_AMIGA || called) return 0; @@ -215,8 +216,9 @@ instance->irq = IRQ_AMIGA_PORTS; instance->unique_id = z->slotaddr; DMA(instance)->DAWR = DAWR_A2091; - wd33c93_init(instance, (wd33c93_regs *)&(DMA(instance)->SASR), - dma_setup, dma_stop, WD33C93_FS_8_10); + regs.SASR = &(DMA(instance)->SASR); + regs.SCMD = &(DMA(instance)->SCMD); + wd33c93_init(instance, regs, dma_setup, dma_stop, WD33C93_FS_8_10); if (num_a2091++ == 0) { first_instance = instance; a2091_template = instance->hostt; diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file linux-m68k-2.4.4/drivers/scsi/a3000.c wd33c93-2.4.4/drivers/scsi/a3000.c --- linux-m68k-2.4.4/drivers/scsi/a3000.c Mon Apr 30 13:46:14 2001 +++ wd33c93-2.4.4/drivers/scsi/a3000.c Wed May 23 08:14:54 2001 @@ -171,6 +171,8 @@ int __init a3000_detect(Scsi_Host_Template *tpnt) { + wd33c93_regs regs; + if (!MACH_IS_AMIGA || !AMIGAHW_PRESENT(A3000_SCSI)) return 0; if (!request_mem_region(0xDD0000, 256, "wd33c93")) @@ -186,8 +188,9 @@ a3000_host->base = ZTWO_VADDR(0xDD0000); a3000_host->irq = IRQ_AMIGA_PORTS; DMA(a3000_host)->DAWR = DAWR_A3000; - wd33c93_init(a3000_host, (wd33c93_regs *)&(DMA(a3000_host)->SASR), - dma_setup, dma_stop, WD33C93_FS_12_15); + regs.SASR = &(DMA(a3000_host)->SASR); + regs.SCMD = &(DMA(a3000_host)->SCMD); + wd33c93_init(a3000_host, regs, dma_setup, dma_stop, WD33C93_FS_12_15); if (request_irq(IRQ_AMIGA_PORTS, a3000_intr, SA_SHIRQ, "A3000 SCSI", a3000_intr)) goto fail_irq; diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file linux-m68k-2.4.4/drivers/scsi/gvp11.c wd33c93-2.4.4/drivers/scsi/gvp11.c --- linux-m68k-2.4.4/drivers/scsi/gvp11.c Tue Nov 28 02:57:34 2000 +++ wd33c93-2.4.4/drivers/scsi/gvp11.c Wed May 23 08:13:56 2001 @@ -186,6 +186,7 @@ unsigned int epc; struct zorro_dev *z = NULL; unsigned int default_dma_xfer_mask; + wd33c93_regs regs; #ifdef CHECK_WD33C93 volatile unsigned char *sasr_3393, *scmd_3393; unsigned char save_sasr; @@ -329,12 +330,11 @@ /* * Check for 14MHz SCSI clock */ - if (epc & GVP_SCSICLKMASK) - wd33c93_init(instance, (wd33c93_regs *)&(DMA(instance)->SASR), - dma_setup, dma_stop, WD33C93_FS_8_10); - else - wd33c93_init(instance, (wd33c93_regs *)&(DMA(instance)->SASR), - dma_setup, dma_stop, WD33C93_FS_12_15); + regs.SASR = &(DMA(instance)->SASR); + regs.SCMD = &(DMA(instance)->SCMD); + wd33c93_init(instance, regs, dma_setup, dma_stop, + (epc & GVP_SCSICLKMASK) ? WD33C93_FS_8_10 + : WD33C93_FS_12_15); if (num_gvp11++ == 0) { first_instance = instance; diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file linux-m68k-2.4.4/drivers/scsi/mvme147.c wd33c93-2.4.4/drivers/scsi/mvme147.c --- linux-m68k-2.4.4/drivers/scsi/mvme147.c Mon Feb 26 09:02:13 2001 +++ wd33c93-2.4.4/drivers/scsi/mvme147.c Wed May 23 08:13:56 2001 @@ -65,6 +65,7 @@ int mvme147_detect(Scsi_Host_Template *tpnt) { static unsigned char called = 0; + wd33c93_regs regs; if (!MACH_IS_MVME147 || called) return 0; @@ -79,8 +80,9 @@ mvme147_host->base = 0xfffe4000; mvme147_host->irq = MVME147_IRQ_SCSI_PORT; - wd33c93_init(mvme147_host, (wd33c93_regs *)0xfffe4000, - dma_setup, dma_stop, WD33C93_FS_8_10); + regs.SASR = (volatile unsigned char *)0xfffe4000; + regs.SCMD = (volatile unsigned char *)0xfffe4001; + wd33c93_init(mvme147_host, regs, dma_setup, dma_stop, WD33C93_FS_8_10); if (request_irq(MVME147_IRQ_SCSI_PORT, mvme147_intr, 0, "MVME147 SCSI PORT", mvme147_intr)) goto err_unregister; diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file linux-m68k-2.4.4/drivers/scsi/sgiwd93.c wd33c93-2.4.4/drivers/scsi/sgiwd93.c --- linux-m68k-2.4.4/drivers/scsi/sgiwd93.c Sun Nov 12 04:01:11 2000 +++ wd33c93-2.4.4/drivers/scsi/sgiwd93.c Wed May 23 08:13:56 2001 @@ -43,22 +43,23 @@ struct Scsi_Host *sgiwd93_host1 = NULL; /* Wuff wuff, wuff, wd33c93.c, wuff wuff, object oriented, bow wow. */ -static inline void write_wd33c93_count(wd33c93_regs *regp, unsigned long value) +static inline void write_wd33c93_count(const wd33c93_regs regs, + unsigned long value) { - regp->SASR = WD_TRANSFER_COUNT_MSB; - regp->SCMD = ((value >> 16) & 0xff); - regp->SCMD = ((value >> 8) & 0xff); - regp->SCMD = ((value >> 0) & 0xff); + *regs.SASR = WD_TRANSFER_COUNT_MSB; + *regs.SCMD = ((value >> 16) & 0xff); + *regs.SCMD = ((value >> 8) & 0xff); + *regs.SCMD = ((value >> 0) & 0xff); } -static inline unsigned long read_wd33c93_count(wd33c93_regs *regp) +static inline unsigned long read_wd33c93_count(const wd33c93_regs regs) { unsigned long value; - regp->SASR = WD_TRANSFER_COUNT_MSB; - value = ((regp->SCMD & 0xff) << 16); - value |= ((regp->SCMD & 0xff) << 8); - value |= ((regp->SCMD & 0xff) << 0); + *regs.SASR = WD_TRANSFER_COUNT_MSB; + value = (*regs.SCMD << 16); + value |= (*regs.SCMD << 8); + value |= (*regs.SCMD << 0); return value; } @@ -99,7 +100,7 @@ static int dma_setup(Scsi_Cmnd *cmd, int datainp) { struct WD33C93_hostdata *hdata = (struct WD33C93_hostdata *)cmd->host->hostdata; - wd33c93_regs *regp = hdata->regp; + const wd33c93_regs regs = hdata->regs; struct hpc3_scsiregs *hregs = (struct hpc3_scsiregs *) cmd->host->base; struct hpc_chunk *hcp = (struct hpc_chunk *) hdata->dma_bounce_buffer; @@ -128,7 +129,7 @@ printk(">tlen<%d>", totlen); #endif hdata->dma_bounce_len = totlen; /* a trick... */ - write_wd33c93_count(regp, totlen); + write_wd33c93_count(regs, totlen); } else { /* Non-scattered dma. */ #ifdef DEBUG_DMA @@ -144,7 +145,7 @@ if (cmd->SCp.ptr == NULL) return 1; fill_hpc_entries (&hcp, cmd->SCp.ptr,cmd->SCp.this_residual); - write_wd33c93_count(regp, cmd->SCp.this_residual); + write_wd33c93_count(regs, cmd->SCp.this_residual); } /* To make sure, if we trip an HPC bug, that we transfer @@ -171,7 +172,7 @@ int status) { struct WD33C93_hostdata *hdata = (struct WD33C93_hostdata *)instance->hostdata; - wd33c93_regs *regp = hdata->regp; + const wd33c93_regs regs = hdata->regs; struct hpc3_scsiregs *hregs; if (!SCpnt) @@ -198,7 +199,7 @@ /* Yep, we were doing the scatterlist thang. */ totlen = hdata->dma_bounce_len; - wd93_residual = read_wd33c93_count(regp); + wd93_residual = read_wd33c93_count(regs); transferred = totlen - wd93_residual; #ifdef DEBUG_DMA @@ -268,6 +269,7 @@ struct WD33C93_hostdata *hdata; struct WD33C93_hostdata *hdata1; uchar *buf; + wd33c93_regs regs; if(called) return 0; /* Should bitch on the console about this... */ @@ -284,8 +286,9 @@ init_hpc_chain(buf); dma_cache_wback_inv((unsigned long) buf, PAGE_SIZE); /* HPC_SCSI_REG0 | 0x03 | KSEG1 */ - wd33c93_init(sgiwd93_host, (wd33c93_regs *) 0xbfbc0003, - dma_setup, dma_stop, WD33C93_FS_16_20); + regs.SASR = (volatile unsigned char *)0xbfbc0003; + regs.SCMD = (volatile unsigned char *)0xbfbc0007; + wd33c93_init(sgiwd93_host, regs, dma_setup, dma_stop, WD33C93_FS_16_20); hdata = (struct WD33C93_hostdata *)sgiwd93_host->hostdata; hdata->no_sync = 0; @@ -305,8 +308,10 @@ init_hpc_chain(buf); dma_cache_wback_inv((unsigned long) buf, PAGE_SIZE); /* HPC_SCSI_REG1 | 0x03 | KSEG1 */ - wd33c93_init(sgiwd93_host1, (wd33c93_regs *) 0xbfbc8003, - dma_setup, dma_stop, WD33C93_FS_16_20); + regs.SASR = (volatile unsigned char *)0xbfbc8003; + regs.SCMD = (volatile unsigned char *)0xbfbc8007; + wd33c93_init(sgiwd93_host1, regs, dma_setup, dma_stop, + WD33C93_FS_16_20); hdata1 = (struct WD33C93_hostdata *)sgiwd93_host1->hostdata; hdata1->no_sync = 0; diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file linux-m68k-2.4.4/drivers/scsi/wd33c93.c wd33c93-2.4.4/drivers/scsi/wd33c93.c --- linux-m68k-2.4.4/drivers/scsi/wd33c93.c Tue Dec 5 21:43:48 2000 +++ wd33c93-2.4.4/drivers/scsi/wd33c93.c Wed May 23 09:33:03 2001 @@ -175,71 +175,72 @@ -static inline uchar read_wd33c93(wd33c93_regs *regp,uchar reg_num) +static inline uchar read_wd33c93(const wd33c93_regs regs, uchar reg_num) { - regp->SASR = reg_num; + *regs.SASR = reg_num; mb(); - return(regp->SCMD); + return(*regs.SCMD); } -#define READ_AUX_STAT() (regp->SASR) +#define READ_AUX_STAT() (*regs.SASR) -static inline void write_wd33c93(wd33c93_regs *regp,uchar reg_num, uchar value) +static inline void write_wd33c93(const wd33c93_regs regs, uchar reg_num, + uchar value) { - regp->SASR = reg_num; + *regs.SASR = reg_num; mb(); - regp->SCMD = value; + *regs.SCMD = value; mb(); } -static inline void write_wd33c93_cmd(wd33c93_regs *regp, uchar cmd) +static inline void write_wd33c93_cmd(const wd33c93_regs regs, uchar cmd) { - regp->SASR = WD_COMMAND; + *regs.SASR = WD_COMMAND; mb(); - regp->SCMD = cmd; + *regs.SCMD = cmd; mb(); } -static inline uchar read_1_byte(wd33c93_regs *regp) +static inline uchar read_1_byte(const wd33c93_regs regs) { uchar asr; uchar x = 0; - write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); - write_wd33c93_cmd(regp, WD_CMD_TRANS_INFO|0x80); + write_wd33c93(regs, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); + write_wd33c93_cmd(regs, WD_CMD_TRANS_INFO|0x80); do { asr = READ_AUX_STAT(); if (asr & ASR_DBR) - x = read_wd33c93(regp, WD_DATA); + x = read_wd33c93(regs, WD_DATA); } while (!(asr & ASR_INT)); return x; } -static void write_wd33c93_count(wd33c93_regs *regp,unsigned long value) +static void write_wd33c93_count(const wd33c93_regs regs, unsigned long value) { - regp->SASR = WD_TRANSFER_COUNT_MSB; + *regs.SASR = WD_TRANSFER_COUNT_MSB; mb(); - regp->SCMD = value >> 16; - regp->SCMD = value >> 8; - regp->SCMD = value; + *regs.SCMD = value >> 16; + *regs.SCMD = value >> 8; + *regs.SCMD = value; mb(); } -static unsigned long read_wd33c93_count(wd33c93_regs *regp) +static unsigned long read_wd33c93_count(const wd33c93_regs regs) { unsigned long value; - regp->SASR = WD_TRANSFER_COUNT_MSB; + *regs.SASR = WD_TRANSFER_COUNT_MSB; mb(); - value = regp->SCMD << 16; - value |= regp->SCMD << 8; - value |= regp->SCMD; + value = *regs.SCMD << 16; + value |= *regs.SCMD << 8; + value |= *regs.SCMD; mb(); return value; } @@ -423,14 +424,11 @@ */ static void wd33c93_execute (struct Scsi_Host *instance) { -struct WD33C93_hostdata *hostdata; -wd33c93_regs *regp; +struct WD33C93_hostdata *hostdata = (struct WD33C93_hostdata *)instance->hostdata; +const wd33c93_regs regs = hostdata->regs; Scsi_Cmnd *cmd, *prev; int i; - hostdata = (struct WD33C93_hostdata *)instance->hostdata; - regp = hostdata->regp; - DB(DB_EXECUTE,printk("EX(")) if (hostdata->selecting || hostdata->connected) { @@ -479,9 +477,9 @@ */ if (is_dir_out(cmd)) - write_wd33c93(regp, WD_DESTINATION_ID, cmd->target); + write_wd33c93(regs, WD_DESTINATION_ID, cmd->target); else - write_wd33c93(regp, WD_DESTINATION_ID, cmd->target | DSTID_DPD); + write_wd33c93(regs, WD_DESTINATION_ID, cmd->target | DSTID_DPD); /* Now we need to figure out whether or not this command is a good * candidate for disconnect/reselect. We guess to the best of our @@ -537,10 +535,10 @@ no: - write_wd33c93(regp, WD_SOURCE_ID, ((cmd->SCp.phase)?SRCID_ER:0)); + write_wd33c93(regs, WD_SOURCE_ID, ((cmd->SCp.phase)?SRCID_ER:0)); - write_wd33c93(regp, WD_TARGET_LUN, cmd->lun); - write_wd33c93(regp,WD_SYNCHRONOUS_TRANSFER,hostdata->sync_xfer[cmd->target]); + write_wd33c93(regs, WD_TARGET_LUN, cmd->lun); + write_wd33c93(regs, WD_SYNCHRONOUS_TRANSFER,hostdata->sync_xfer[cmd->target]); hostdata->busy[cmd->target] |= (1 << cmd->lun); if ((hostdata->level2 == L2_NONE) || @@ -571,8 +569,8 @@ if (hostdata->sync_stat[cmd->target] == SS_UNSET) hostdata->sync_stat[cmd->target] = SS_FIRST; hostdata->state = S_SELECTING; - write_wd33c93_count(regp,0); /* guarantee a DATA_PHASE interrupt */ - write_wd33c93_cmd(regp, WD_CMD_SEL_ATN); + write_wd33c93_count(regs, 0); /* guarantee a DATA_PHASE interrupt */ + write_wd33c93_cmd(regs, WD_CMD_SEL_ATN); } else { @@ -586,15 +584,15 @@ */ hostdata->connected = cmd; - write_wd33c93(regp, WD_COMMAND_PHASE, 0); + write_wd33c93(regs, WD_COMMAND_PHASE, 0); /* copy command_descriptor_block into WD chip * (take advantage of auto-incrementing) */ - regp->SASR = WD_CDB_1; + *regs.SASR = WD_CDB_1; for (i=0; icmd_len; i++) - regp->SCMD = cmd->cmnd[i]; + *regs.SCMD = cmd->cmnd[i]; /* The wd33c93 only knows about Group 0, 1, and 5 commands when * it's doing a 'select-and-transfer'. To be safe, we write the @@ -602,7 +600,7 @@ * way there won't be problems with vendor-unique, audio, etc. */ - write_wd33c93(regp, WD_OWN_ID, cmd->cmd_len); + write_wd33c93(regs, WD_OWN_ID, cmd->cmd_len); /* When doing a non-disconnect command with DMA, we can save * ourselves a DATA phase interrupt later by setting everything @@ -612,18 +610,18 @@ if ((cmd->SCp.phase == 0) && (hostdata->no_dma == 0)) { if (hostdata->dma_setup(cmd, (is_dir_out(cmd))?DATA_OUT_DIR:DATA_IN_DIR)) - write_wd33c93_count(regp,0); /* guarantee a DATA_PHASE interrupt */ + write_wd33c93_count(regs, 0); /* guarantee a DATA_PHASE interrupt */ else { - write_wd33c93_count(regp, cmd->SCp.this_residual); - write_wd33c93(regp,WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); + write_wd33c93_count(regs, cmd->SCp.this_residual); + write_wd33c93(regs, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); hostdata->dma = D_DMA_RUNNING; } } else - write_wd33c93_count(regp,0); /* guarantee a DATA_PHASE interrupt */ + write_wd33c93_count(regs, 0); /* guarantee a DATA_PHASE interrupt */ hostdata->state = S_RUNNING_LEVEL2; - write_wd33c93_cmd(regp, WD_CMD_SEL_ATN_XFER); + write_wd33c93_cmd(regs, WD_CMD_SEL_ATN_XFER); } /* @@ -638,28 +636,28 @@ -static void transfer_pio(wd33c93_regs *regp, uchar *buf, int cnt, - int data_in_dir, struct WD33C93_hostdata *hostdata) +static void transfer_pio(const wd33c93_regs regs, uchar *buf, int cnt, + int data_in_dir, struct WD33C93_hostdata *hostdata) { uchar asr; DB(DB_TRANSFER,printk("(%p,%d,%s:",buf,cnt,data_in_dir?"in":"out")) - write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); - write_wd33c93_count(regp,cnt); - write_wd33c93_cmd(regp, WD_CMD_TRANS_INFO); + write_wd33c93(regs, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); + write_wd33c93_count(regs, cnt); + write_wd33c93_cmd(regs, WD_CMD_TRANS_INFO); if (data_in_dir) { do { asr = READ_AUX_STAT(); if (asr & ASR_DBR) - *buf++ = read_wd33c93(regp, WD_DATA); + *buf++ = read_wd33c93(regs, WD_DATA); } while (!(asr & ASR_INT)); } else { do { asr = READ_AUX_STAT(); if (asr & ASR_DBR) - write_wd33c93(regp, WD_DATA, *buf++); + write_wd33c93(regs, WD_DATA, *buf++); } while (!(asr & ASR_INT)); } @@ -674,7 +672,8 @@ -static void transfer_bytes(wd33c93_regs *regp, Scsi_Cmnd *cmd, int data_in_dir) +static void transfer_bytes(const wd33c93_regs regs, Scsi_Cmnd *cmd, + int data_in_dir) { struct WD33C93_hostdata *hostdata; unsigned long length; @@ -696,7 +695,7 @@ cmd->SCp.ptr = cmd->SCp.buffer->address; } - write_wd33c93(regp,WD_SYNCHRONOUS_TRANSFER,hostdata->sync_xfer[cmd->target]); + write_wd33c93(regs, WD_SYNCHRONOUS_TRANSFER,hostdata->sync_xfer[cmd->target]); /* 'hostdata->no_dma' is TRUE if we don't even want to try DMA. * Update 'this_residual' and 'ptr' after 'transfer_pio()' returns. @@ -714,10 +713,10 @@ #ifdef PROC_STATISTICS hostdata->pio_cnt++; #endif - transfer_pio(regp, (uchar *)cmd->SCp.ptr, cmd->SCp.this_residual, + transfer_pio(regs, (uchar *)cmd->SCp.ptr, cmd->SCp.this_residual, data_in_dir, hostdata); length = cmd->SCp.this_residual; - cmd->SCp.this_residual = read_wd33c93_count(regp); + cmd->SCp.this_residual = read_wd33c93_count(regs); cmd->SCp.ptr += (length - cmd->SCp.this_residual); } @@ -734,17 +733,17 @@ #ifdef PROC_STATISTICS hostdata->dma_cnt++; #endif - write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); - write_wd33c93_count(regp,cmd->SCp.this_residual); + write_wd33c93(regs, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); + write_wd33c93_count(regs, cmd->SCp.this_residual); if ((hostdata->level2 >= L2_DATA) || (hostdata->level2 == L2_BASIC && cmd->SCp.phase == 0)) { - write_wd33c93(regp, WD_COMMAND_PHASE, 0x45); - write_wd33c93_cmd(regp, WD_CMD_SEL_ATN_XFER); + write_wd33c93(regs, WD_COMMAND_PHASE, 0x45); + write_wd33c93_cmd(regs, WD_CMD_SEL_ATN_XFER); hostdata->state = S_RUNNING_LEVEL2; } else - write_wd33c93_cmd(regp, WD_CMD_TRANS_INFO); + write_wd33c93_cmd(regs, WD_CMD_TRANS_INFO); hostdata->dma = D_DMA_RUNNING; } @@ -754,15 +753,12 @@ void wd33c93_intr (struct Scsi_Host *instance) { -struct WD33C93_hostdata *hostdata; +struct WD33C93_hostdata *hostdata = (struct WD33C93_hostdata *)instance->hostdata; +const wd33c93_regs regs = hostdata->regs; Scsi_Cmnd *patch, *cmd; -wd33c93_regs *regp; uchar asr, sr, phs, id, lun, *ucp, msg; unsigned long length, flags; - hostdata = (struct WD33C93_hostdata *)instance->hostdata; - regp = hostdata->regp; - asr = READ_AUX_STAT(); if (!(asr & ASR_INT) || (asr & ASR_BSY)) return; @@ -774,8 +770,8 @@ #endif cmd = (Scsi_Cmnd *)hostdata->connected; /* assume we're connected */ - sr = read_wd33c93(regp, WD_SCSI_STATUS); /* clear the interrupt */ - phs = read_wd33c93(regp, WD_COMMAND_PHASE); + sr = read_wd33c93(regs, WD_SCSI_STATUS); /* clear the interrupt */ + phs = read_wd33c93(regs, WD_COMMAND_PHASE); DB(DB_INTR,printk("{%02x:%02x-",asr,sr)) @@ -799,7 +795,7 @@ hostdata->dma_stop(cmd->host, cmd, 1); hostdata->dma = D_DMA_OFF; length = cmd->SCp.this_residual; - cmd->SCp.this_residual = read_wd33c93_count(regp); + cmd->SCp.this_residual = read_wd33c93_count(regs); cmd->SCp.ptr += (length - cmd->SCp.this_residual); DB(DB_TRANSFER,printk("%p/%d]",cmd->SCp.ptr,cmd->SCp.this_residual)) } @@ -894,7 +890,7 @@ case CSR_UNEXP |PHS_DATA_IN: case CSR_SRV_REQ |PHS_DATA_IN: DB(DB_INTR,printk("IN-%d.%d",cmd->SCp.this_residual,cmd->SCp.buffers_residual)) - transfer_bytes(regp, cmd, DATA_IN_DIR); + transfer_bytes(regs, cmd, DATA_IN_DIR); if (hostdata->state != S_RUNNING_LEVEL2) hostdata->state = S_CONNECTED; break; @@ -904,7 +900,7 @@ case CSR_UNEXP |PHS_DATA_OUT: case CSR_SRV_REQ |PHS_DATA_OUT: DB(DB_INTR,printk("OUT-%d.%d",cmd->SCp.this_residual,cmd->SCp.buffers_residual)) - transfer_bytes(regp, cmd, DATA_OUT_DIR); + transfer_bytes(regs, cmd, DATA_OUT_DIR); if (hostdata->state != S_RUNNING_LEVEL2) hostdata->state = S_CONNECTED; break; @@ -916,7 +912,7 @@ case CSR_UNEXP |PHS_COMMAND: case CSR_SRV_REQ |PHS_COMMAND: DB(DB_INTR,printk("CMND-%02x,%ld",cmd->cmnd[0],cmd->pid)) - transfer_pio(regp, cmd->cmnd, cmd->cmd_len, DATA_OUT_DIR, hostdata); + transfer_pio(regs, cmd->cmnd, cmd->cmd_len, DATA_OUT_DIR, hostdata); hostdata->state = S_CONNECTED; break; @@ -926,13 +922,13 @@ case CSR_SRV_REQ |PHS_STATUS: DB(DB_INTR,printk("STATUS=")) - cmd->SCp.Status = read_1_byte(regp); + cmd->SCp.Status = read_1_byte(regs); DB(DB_INTR,printk("%02x",cmd->SCp.Status)) if (hostdata->level2 >= L2_BASIC) { - sr = read_wd33c93(regp, WD_SCSI_STATUS); /* clear interrupt */ + sr = read_wd33c93(regs, WD_SCSI_STATUS); /* clear interrupt */ hostdata->state = S_RUNNING_LEVEL2; - write_wd33c93(regp, WD_COMMAND_PHASE, 0x50); - write_wd33c93_cmd(regp, WD_CMD_SEL_ATN_XFER); + write_wd33c93(regs, WD_COMMAND_PHASE, 0x50); + write_wd33c93_cmd(regs, WD_CMD_SEL_ATN_XFER); } else { hostdata->state = S_CONNECTED; @@ -945,8 +941,8 @@ case CSR_SRV_REQ |PHS_MESS_IN: DB(DB_INTR,printk("MSG_IN=")) - msg = read_1_byte(regp); - sr = read_wd33c93(regp, WD_SCSI_STATUS); /* clear interrupt */ + msg = read_1_byte(regs); + sr = read_wd33c93(regs, WD_SCSI_STATUS); /* clear interrupt */ hostdata->incoming_msg[hostdata->incoming_ptr] = msg; if (hostdata->incoming_msg[0] == EXTENDED_MESSAGE) @@ -959,25 +955,25 @@ case COMMAND_COMPLETE: DB(DB_INTR,printk("CCMP-%ld",cmd->pid)) - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_PRE_CMP_DISC; break; case SAVE_POINTERS: DB(DB_INTR,printk("SDP")) - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_CONNECTED; break; case RESTORE_POINTERS: DB(DB_INTR,printk("RDP")) if (hostdata->level2 >= L2_BASIC) { - write_wd33c93(regp, WD_COMMAND_PHASE, 0x45); - write_wd33c93_cmd(regp, WD_CMD_SEL_ATN_XFER); + write_wd33c93(regs, WD_COMMAND_PHASE, 0x45); + write_wd33c93_cmd(regs, WD_CMD_SEL_ATN_XFER); hostdata->state = S_RUNNING_LEVEL2; } else { - write_wd33c93_cmd(regp, WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_CONNECTED; } break; @@ -985,7 +981,7 @@ case DISCONNECT: DB(DB_INTR,printk("DIS")) cmd->device->disconnect = 1; - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_PRE_TMP_DISC; break; @@ -996,7 +992,7 @@ #endif if (hostdata->sync_stat[cmd->target] == SS_WAITING) hostdata->sync_stat[cmd->target] = SS_SET; - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_CONNECTED; break; @@ -1027,7 +1023,7 @@ * specifically ask for sync transfers, we won't do any. */ - write_wd33c93_cmd(regp,WD_CMD_ASSERT_ATN); /* want MESS_OUT */ + write_wd33c93_cmd(regs, WD_CMD_ASSERT_ATN); /* want MESS_OUT */ hostdata->outgoing_msg[0] = EXTENDED_MESSAGE; hostdata->outgoing_msg[1] = 3; hostdata->outgoing_msg[2] = EXTENDED_SDTR; @@ -1044,26 +1040,26 @@ printk("sync_xfer=%02x",hostdata->sync_xfer[cmd->target]); #endif hostdata->sync_stat[cmd->target] = SS_SET; - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_CONNECTED; break; case EXTENDED_WDTR: - write_wd33c93_cmd(regp,WD_CMD_ASSERT_ATN); /* want MESS_OUT */ + write_wd33c93_cmd(regs, WD_CMD_ASSERT_ATN); /* want MESS_OUT */ printk("sending WDTR "); hostdata->outgoing_msg[0] = EXTENDED_MESSAGE; hostdata->outgoing_msg[1] = 2; hostdata->outgoing_msg[2] = EXTENDED_WDTR; hostdata->outgoing_msg[3] = 0; /* 8 bit transfer width */ hostdata->outgoing_len = 4; - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_CONNECTED; break; default: - write_wd33c93_cmd(regp,WD_CMD_ASSERT_ATN); /* want MESS_OUT */ + write_wd33c93_cmd(regs, WD_CMD_ASSERT_ATN); /* want MESS_OUT */ printk("Rejecting Unknown Extended Message(%02x). ",ucp[2]); hostdata->outgoing_msg[0] = MESSAGE_REJECT; hostdata->outgoing_len = 1; - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_CONNECTED; break; } @@ -1074,17 +1070,17 @@ else { hostdata->incoming_ptr++; - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_CONNECTED; } break; default: printk("Rejecting Unknown Message(%02x) ",msg); - write_wd33c93_cmd(regp,WD_CMD_ASSERT_ATN); /* want MESS_OUT */ + write_wd33c93_cmd(regs, WD_CMD_ASSERT_ATN); /* want MESS_OUT */ hostdata->outgoing_msg[0] = MESSAGE_REJECT; hostdata->outgoing_len = 1; - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); hostdata->state = S_CONNECTED; } restore_flags(flags); @@ -1099,11 +1095,11 @@ * have been turned off for the command that just completed. */ - write_wd33c93(regp,WD_SOURCE_ID, SRCID_ER); + write_wd33c93(regs, WD_SOURCE_ID, SRCID_ER); if (phs == 0x60) { DB(DB_INTR,printk("SX-DONE-%ld",cmd->pid)) cmd->SCp.Message = COMMAND_COMPLETE; - lun = read_wd33c93(regp, WD_TARGET_LUN); + lun = read_wd33c93(regs, WD_TARGET_LUN); DB(DB_INTR,printk(":%d.%d",cmd->SCp.Status,lun)) hostdata->connected = NULL; hostdata->busy[cmd->target] &= ~(1 << cmd->lun); @@ -1133,8 +1129,8 @@ case CSR_SDP: DB(DB_INTR,printk("SDP")) hostdata->state = S_RUNNING_LEVEL2; - write_wd33c93(regp, WD_COMMAND_PHASE, 0x41); - write_wd33c93_cmd(regp, WD_CMD_SEL_ATN_XFER); + write_wd33c93(regs, WD_COMMAND_PHASE, 0x41); + write_wd33c93_cmd(regs, WD_CMD_SEL_ATN_XFER); break; @@ -1160,7 +1156,7 @@ hostdata->outgoing_len = 1; hostdata->outgoing_msg[0] = NOP; } - transfer_pio(regp, hostdata->outgoing_msg, hostdata->outgoing_len, + transfer_pio(regs, hostdata->outgoing_msg, hostdata->outgoing_len, DATA_OUT_DIR, hostdata); DB(DB_INTR,printk("%02x",hostdata->outgoing_msg[0])) hostdata->outgoing_len = 0; @@ -1182,7 +1178,7 @@ * have been turned off for the command that just completed. */ - write_wd33c93(regp,WD_SOURCE_ID, SRCID_ER); + write_wd33c93(regs, WD_SOURCE_ID, SRCID_ER); if (cmd == NULL) { printk(" - Already disconnected! "); hostdata->state = S_UNCONNECTED; @@ -1213,7 +1209,7 @@ * have been turned off for the command that just completed. */ - write_wd33c93(regp,WD_SOURCE_ID, SRCID_ER); + write_wd33c93(regs, WD_SOURCE_ID, SRCID_ER); DB(DB_INTR,printk("DISC-%ld",cmd->pid)) if (cmd == NULL) { printk(" - Already disconnected! "); @@ -1298,7 +1294,7 @@ /* OK - find out which device reselected us. */ - id = read_wd33c93(regp, WD_SOURCE_ID); + id = read_wd33c93(regs, WD_SOURCE_ID); id &= SRCID_MASK; /* and extract the lun from the ID message. (Note that we don't @@ -1307,9 +1303,9 @@ */ if (sr == CSR_RESEL_AM) { - lun = read_wd33c93(regp, WD_DATA); + lun = read_wd33c93(regs, WD_DATA); if (hostdata->level2 < L2_RESELECT) - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); lun &= 7; } else { @@ -1325,12 +1321,12 @@ } else { /* Verify this is a change to MSG_IN and read the message */ - sr = read_wd33c93(regp, WD_SCSI_STATUS); + sr = read_wd33c93(regs, WD_SCSI_STATUS); if (sr == (CSR_ABORT | PHS_MESS_IN) || sr == (CSR_UNEXP | PHS_MESS_IN) || sr == (CSR_SRV_REQ | PHS_MESS_IN)) { /* Got MSG_IN, grab target LUN */ - lun = read_1_byte(regp); + lun = read_1_byte(regs); /* Now we expect a 'paused with ACK asserted' int.. */ asr = READ_AUX_STAT(); if (!(asr & ASR_INT)) { @@ -1340,12 +1336,12 @@ printk("wd33c93: No int after LUN on RESEL (%02x)\n", asr); } - sr = read_wd33c93(regp, WD_SCSI_STATUS); + sr = read_wd33c93(regs, WD_SCSI_STATUS); if (sr != CSR_MSGIN) printk("wd33c93: Not paused with ACK on RESEL (%02x)\n", sr); lun &= 7; - write_wd33c93_cmd(regp,WD_CMD_NEGATE_ACK); + write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK); } else { printk("wd33c93: Not MSG_IN on reselect (%02x)\n", sr); @@ -1386,13 +1382,13 @@ */ if (is_dir_out(cmd)) - write_wd33c93(regp, WD_DESTINATION_ID, cmd->target); + write_wd33c93(regs, WD_DESTINATION_ID, cmd->target); else - write_wd33c93(regp, WD_DESTINATION_ID, cmd->target | DSTID_DPD); + write_wd33c93(regs, WD_DESTINATION_ID, cmd->target | DSTID_DPD); if (hostdata->level2 >= L2_RESELECT) { - write_wd33c93_count(regp, 0); /* we want a DATA_PHASE interrupt */ - write_wd33c93(regp, WD_COMMAND_PHASE, 0x45); - write_wd33c93_cmd(regp, WD_CMD_SEL_ATN_XFER); + write_wd33c93_count(regs, 0); /* we want a DATA_PHASE interrupt */ + write_wd33c93(regs, WD_COMMAND_PHASE, 0x45); + write_wd33c93_cmd(regs, WD_CMD_SEL_ATN_XFER); hostdata->state = S_RUNNING_LEVEL2; } else @@ -1413,36 +1409,33 @@ static void reset_wd33c93(struct Scsi_Host *instance) { -struct WD33C93_hostdata *hostdata; -wd33c93_regs *regp; +struct WD33C93_hostdata *hostdata = (struct WD33C93_hostdata *)instance->hostdata; +const wd33c93_regs regs = hostdata->regs; uchar sr; - hostdata = (struct WD33C93_hostdata *)instance->hostdata; - regp = hostdata->regp; - - write_wd33c93(regp, WD_OWN_ID, OWNID_EAF | OWNID_RAF | + write_wd33c93(regs, WD_OWN_ID, OWNID_EAF | OWNID_RAF | instance->this_id | hostdata->clock_freq); - write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); - write_wd33c93(regp, WD_SYNCHRONOUS_TRANSFER, + write_wd33c93(regs, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); + write_wd33c93(regs, WD_SYNCHRONOUS_TRANSFER, calc_sync_xfer(hostdata->default_sx_per/4,DEFAULT_SX_OFF)); - write_wd33c93(regp, WD_COMMAND, WD_CMD_RESET); + write_wd33c93(regs, WD_COMMAND, WD_CMD_RESET); #ifdef CONFIG_MVME147_SCSI udelay(25); /* The old wd33c93 on MVME147 needs this, at least */ #endif while (!(READ_AUX_STAT() & ASR_INT)) ; - sr = read_wd33c93(regp, WD_SCSI_STATUS); + sr = read_wd33c93(regs, WD_SCSI_STATUS); - hostdata->microcode = read_wd33c93(regp, WD_CDB_1); + hostdata->microcode = read_wd33c93(regs, WD_CDB_1); if (sr == 0x00) hostdata->chip = C_WD33C93; else if (sr == 0x01) { - write_wd33c93(regp, WD_QUEUE_TAG, 0xa5); /* any random number */ - sr = read_wd33c93(regp, WD_QUEUE_TAG); + write_wd33c93(regs, WD_QUEUE_TAG, 0xa5); /* any random number */ + sr = read_wd33c93(regs, WD_QUEUE_TAG); if (sr == 0xa5) { hostdata->chip = C_WD33C93B; - write_wd33c93(regp, WD_QUEUE_TAG, 0); + write_wd33c93(regs, WD_QUEUE_TAG, 0); } else hostdata->chip = C_WD33C93A; @@ -1450,8 +1443,8 @@ else hostdata->chip = C_UNKNOWN_CHIP; - write_wd33c93(regp, WD_TIMEOUT_PERIOD, TIMEOUT_PERIOD_VALUE); - write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); + write_wd33c93(regs, WD_TIMEOUT_PERIOD, TIMEOUT_PERIOD_VALUE); + write_wd33c93(regs, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); } @@ -1495,14 +1488,14 @@ { struct Scsi_Host *instance; struct WD33C93_hostdata *hostdata; -wd33c93_regs *regp; +wd33c93_regs regs; Scsi_Cmnd *tmp, *prev; disable_irq(cmd->host->irq); instance = cmd->host; hostdata = (struct WD33C93_hostdata *)instance->hostdata; - regp = hostdata->regp; + regs = hostdata->regs; /* * Case 1 : If the command hasn't been issued yet, we simply remove it @@ -1554,8 +1547,8 @@ } printk("sending wd33c93 ABORT command - "); - write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); - write_wd33c93_cmd(regp, WD_CMD_ABORT); + write_wd33c93(regs, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED); + write_wd33c93_cmd(regs, WD_CMD_ABORT); /* Now we have to attempt to flush out the FIFO... */ @@ -1564,11 +1557,11 @@ do { asr = READ_AUX_STAT(); if (asr & ASR_DBR) - read_wd33c93(regp, WD_DATA); + read_wd33c93(regs, WD_DATA); } while (!(asr & ASR_INT) && timeout-- > 0); - sr = read_wd33c93(regp, WD_SCSI_STATUS); + sr = read_wd33c93(regs, WD_SCSI_STATUS); printk("asr=%02x, sr=%02x, %ld bytes un-transferred (timeout=%ld) - ", - asr, sr, read_wd33c93_count(regp), timeout); + asr, sr, read_wd33c93_count(regs), timeout); /* * Abort command processed. @@ -1577,13 +1570,13 @@ */ printk("sending wd33c93 DISCONNECT command - "); - write_wd33c93_cmd(regp, WD_CMD_DISCONNECT); + write_wd33c93_cmd(regs, WD_CMD_DISCONNECT); timeout = 1000000; asr = READ_AUX_STAT(); while ((asr & ASR_CIP) && timeout-- > 0) asr = READ_AUX_STAT(); - sr = read_wd33c93(regp, WD_SCSI_STATUS); + sr = read_wd33c93(regs, WD_SCSI_STATUS); printk("asr=%02x, sr=%02x.",asr,sr); hostdata->busy[cmd->target] &= ~(1 << cmd->lun); @@ -1733,8 +1726,8 @@ -void wd33c93_init (struct Scsi_Host *instance, wd33c93_regs *regs, - dma_setup_t setup, dma_stop_t stop, int clock_freq) +void wd33c93_init(struct Scsi_Host *instance, const wd33c93_regs regs, + dma_setup_t setup, dma_stop_t stop, int clock_freq) { struct WD33C93_hostdata *hostdata; int i; @@ -1747,7 +1740,7 @@ hostdata = (struct WD33C93_hostdata *)instance->hostdata; - hostdata->regp = regs; + hostdata->regs = regs; hostdata->clock_freq = clock_freq; hostdata->dma_setup = setup; hostdata->dma_stop = stop; diff -u --recursive --exclude-from=/home/geert/diff-excludes-linux --new-file linux-m68k-2.4.4/drivers/scsi/wd33c93.h wd33c93-2.4.4/drivers/scsi/wd33c93.h --- linux-m68k-2.4.4/drivers/scsi/wd33c93.h Tue Nov 28 02:57:34 2000 +++ wd33c93-2.4.4/drivers/scsi/wd33c93.h Wed May 23 08:13:56 2001 @@ -189,14 +189,8 @@ /* This is what the 3393 chip looks like to us */ typedef struct { - volatile unsigned char SASR; -#if !defined(CONFIG_MVME147_SCSI) - char pad; -#endif -#ifdef CONFIG_SGI_IP22 - char pad2,pad3; -#endif - volatile unsigned char SCMD; + volatile unsigned char *SASR; + volatile unsigned char *SCMD; } wd33c93_regs; @@ -225,7 +219,7 @@ struct WD33C93_hostdata { struct Scsi_Host *next; - wd33c93_regs *regp; + wd33c93_regs regs; uchar clock_freq; uchar chip; /* what kind of wd33c93? */ uchar microcode; /* microcode rev */ @@ -336,7 +330,7 @@ #define PR_STOP 1<<7 -void wd33c93_init (struct Scsi_Host *instance, wd33c93_regs *regs, +void wd33c93_init (struct Scsi_Host *instance, const wd33c93_regs regs, dma_setup_t setup, dma_stop_t stop, int clock_freq); int wd33c93_abort (Scsi_Cmnd *cmd); int wd33c93_queuecommand (Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *)); Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Wed May 23 12:51:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NJpvB20485 for linux-mips-outgoing; Wed, 23 May 2001 12:51:57 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJpfF20479; Wed, 23 May 2001 12:51:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA16997; Wed, 23 May 2001 21:29:06 +0200 (MET DST) Date: Wed, 23 May 2001 21:29:06 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Joe deBlaquiere cc: Jun Sun , Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B0BF7F8.3050306@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3472 Lines: 76 On Wed, 23 May 2001, Joe deBlaquiere wrote: > Didn't mean to bring up a sore point, but it seems that we haven't yet > come to a consensus on what policy to have here. I think you both make > valid points that I don't necesarily disagree with, but I would like to > follow the counterpoint a little further. The consensus was come to in January, IIRC. I should have coded an implementation long time ago, actually, but various events keep distracting me. > There's overhead to sysmips also, so neither one is going to give > stunning performance. All out performance isn't likely an issue on one > of these systems anyways. There is a big advantage of invoking a single syscall vs faulting twice or more times on invalid opcodes. An the performance is an issue here -- wasting a few cycles may remain unnoticed on a decent system while it is extremely painful on slow systems. > The problem here is that now I have mips, mipsel, and mipselnollsc > configurations of the cross-tools, the c library and the binary > applications. It's one extra configuration to maintain. How often do you build glibc? For other programs it really doesn't matter which version of glibc you link against (given the same endianness). The linker does not fetch any code from shared objects when linking. Install binaries of glibc as appropriate but just choose any single copy of glibc for development. > There's no way to solve the endianness issues, but using emulation to > handle missing instructions (be they floating point or ll/sc, or > what-have-you) solves the minor differences in the instruction set from > the library/application standpoint. If all MIPS processors used the same Well, do you really have an ISA I CPU which implements ll/sc? No? What about other missing instructions? Emulating instructions (as well as e.g. unaligned memory accesses) might be good for debugging, but for good performance you need to target your binaries to a specific system anyway. > the library/application standpoint. If all MIPS processors used the same > instruction set then we wouldn't have the problem at all. Of course > there are very good reasons (and probably some silly ones too...) why > ISAs are tailored. The same is true for other processors. E.g. there is a noticeable performance advantage for certain code when compiled for the EV56 variation of Alpha (due to the BWX extension, i.e. instructions for byte- and halfword-wide memory accesses). Yet the resulting code does not run on an EV5 or EV4. You have to choose: either performance or compatibility. > The kernel is already going to have to adjust some anyway, so keeping the > differences in the kernel doesn't increase the testing burden. Throwing The kernel gets adjusted at the build time. It's unrelated to the topic, though -- the syscall interface remains the same. > the problem over to glibc (and the toolchain) does increase the number > of active configurations. The same can be said of other platforms. For example, glibc built for i386 does not make use of i686's cmov instructions and is thus highly inefficient on such systems. So if you care of performance you choose an appropriate glibc build-time configuration which suits your system. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 23 12:53:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NJrrC20719 for linux-mips-outgoing; Wed, 23 May 2001 12:53:53 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJmIF20413 for ; Wed, 23 May 2001 12:48:36 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA17299; Wed, 23 May 2001 21:37:18 +0200 (MET DST) Date: Wed, 23 May 2001 21:37:18 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Joe deBlaquiere , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <00ec01c0e3b5$00ab83c0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 942 Lines: 24 On Wed, 23 May 2001, Kevin D. Kissell wrote: > parts, the latter is more efficient for contemporary parts. Those > of us who work on recent and future designs will always tend > to favor the latter - what's the point of using MIPS32/MIPS64 > and beyond CPUs if gnu/Linux binaries are going to treat them > like R3000s? If you work on new processors only, then there is no problem. You configure your tools to build binaries for systems you use and you'll never see R3k compatibility code. Please do yourself a favor and look at the relevant part of glibc. If you build glibc (and any other other program that makes use of _test_and_set()) for ISA II+, the code gets actually inlined with ll/sc used as expected. So the problem is? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 23 13:06:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NK6U121221 for linux-mips-outgoing; Wed, 23 May 2001 13:06:30 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NK5pF21196; Wed, 23 May 2001 13:05:53 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA15441; Wed, 23 May 2001 20:47:34 +0200 (MET DST) Date: Wed, 23 May 2001 20:47:32 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B0BF5AA.DE13EA3F@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2466 Lines: 56 On Wed, 23 May 2001, Jun Sun wrote: > Same old questions : Where is the definition of sysmips()? What is considered > standard implementation of sysmips() so that we can do reverse-engineering? > Irix? I think Ralf can comment it. > Even if Irix is considered standard implementation of sysmips(), I wonder if > we need to mirror it. Here is my reasoning. > > The sytem V ABI specifies _test_and_set() as the exntended system call. I think we want to execute IRIX binaries. The idea of providing sysmips() was to provide compatibility to other systems, AFAIK. I reused sysmips() for pthreads support in glibc as it was non-existent for ISA I CPUs and I needeed librt to run on my R3k. Much of discussion happened later and the conclusion was it's better to make a new call than to try to fiddle with sysmips(). I was not aware of the problems with sysmips() when I wrote the glibc code as sysmips() was nowhere defined and the interface seemed to be reasonable as implemented at that time. Later I was told sysmips(MIPS_ATOMIC_SET) is expected to return an error code which makes it incompatible to _test_and_set(). > Therefore, for MIPS I system, we simply choose to call sysmips(NEW_ATOMIC_SET, > ....) with three arguments. Any application that bypasses _test_and_set() and > calls sysmips() directly is running at its own risk of not being portable. Well, I now see using sysmips() for this purpose is ugly, it complicates immplementation a lot and hits performance of these slow systems where we want to save as many CPU cycles as possible. And still the problem of the error code remains. > Of course, we need to fix glibc, which seems to be the only client that > matters at this moment. That is not a problem, as I already stated. I'll see if I can cook the new syscall I'm writing of, soon. You'll see what I mean, then. > In short, I think we DON"T have to maitain the semantic of sysmips(). My > understanding is that it is justed used to implement extended MIPS ABS calls. Adding a new subfunction of sysmips() is not a problem. The cleanness on the code and the performance is. Note that other subfunctions of sysmips() are not performance-critical. The whole idea of sysmips() appears hackish to me. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 23 13:11:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NKBe721571 for linux-mips-outgoing; Wed, 23 May 2001 13:11:40 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NKACF21532; Wed, 23 May 2001 13:10:13 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA17602; Wed, 23 May 2001 21:44:36 +0200 (MET DST) Date: Wed, 23 May 2001 21:44:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: Florian Lohoff cc: Jun Sun , Joe deBlaquiere , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <20010523205412.A10981@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 822 Lines: 20 On Wed, 23 May 2001, Florian Lohoff wrote: > My favourit would be to let the glibc on runtime decide whether > to use sysmips or ll/sc in the atomic test_and_set stuff. This would > lead to an common atom op in the userspace which is fast on ll/sc > cpus and gives much lesser performance penaltys in the sysmips case > than emulating ll/sc. How would you do it for inlined code? Anyway, I consider run-time detection of ll/sc an overkill. You only solve a single inefficiency of ISA I code when run on better CPUs. You really want to recompile code to make use of new instructions if you care about performance. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 23 13:26:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NKQrh22186 for linux-mips-outgoing; Wed, 23 May 2001 13:26:53 -0700 Received: from blackdog.wirespeed.com ([208.170.106.25]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NKQjF22170; Wed, 23 May 2001 13:26:45 -0700 Received: from redhat.com (IDENT:joe@uberdog.hsv.redhat.com [172.16.16.108]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id OAA06732; Wed, 23 May 2001 14:53:55 -0500 Message-ID: <3B0C17D9.3060600@redhat.com> Date: Wed, 23 May 2001 15:04:41 -0500 From: Joe deBlaquiere User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.8.1) Gecko/20010422 X-Accept-Language: en MIME-Version: 1.0 To: Florian Lohoff CC: Jun Sun , "Maciej W. Rozycki" , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com, "Kevin D. Kissell" Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B0BF7F8.3050306@redhat.com> <3B0C0475.B9ACE682@mvista.com> <20010523205412.A10981@paradigm.rfc822.org> <20010523205552.B10981@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1621 Lines: 42 Florian Lohoff wrote: > On Wed, May 23, 2001 at 08:54:12PM +0200, Florian Lohoff wrote: > >> My favourit would be to let the glibc on runtime decide whether >> to use sysmips or ll/sc in the atomic test_and_set stuff. This would >> lead to an common atom op in the userspace which is fast on ll/sc >> cpus and gives much lesser performance penaltys in the sysmips case >> than emulating ll/sc. > > > But again - I tried to run this discussion again and again - As long > as there is no code to use there is no point in taking a discussion. > I needed a working sysmips for debian as we compile the glibc with > sysmips (performance penalty but for now works everywhere) thus > i fixed the sysmips. > I have to agree with the pragmatism first, philosophy second approach. If it is beautiful but doesn't work it dosn't help anyone. The thing I don't understand is how glibc is going to cleanly decide at runtime which code to use. It's relatively easy to do something like that in the kernel, but I can't come up with an elegant solution to make such a choice at runtime in glibc. Assuming that we're moving forward (as Kevin points out) the percentage of systems without ll/sc is going down. While these systems don't have much CPU power to spare, we should make the baseline implementation have ll/sc emulation. If somebody wants to make a MIPS I optimized glibc, then that's fine, but allowing the 'standard' MIPSII glibc to work on all systems simplifies life ( mine at least ;) ). -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Wed May 23 14:00:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NL0kb23332 for linux-mips-outgoing; Wed, 23 May 2001 14:00:46 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NL0gF23328; Wed, 23 May 2001 14:00:42 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4NKwg013342; Wed, 23 May 2001 13:58:42 -0700 Message-ID: <3B0C246D.CF9CDA2F@mvista.com> Date: Wed, 23 May 2001 13:58:21 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Florian Lohoff , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 840 Lines: 25 "Maciej W. Rozycki" wrote: > > On Wed, 23 May 2001, Jun Sun wrote: > > > Same old questions : Where is the definition of sysmips()? What is considered > > standard implementation of sysmips() so that we can do reverse-engineering? > > Irix? > > I think Ralf can comment it. > > > Even if Irix is considered standard implementation of sysmips(), I wonder if > > we need to mirror it. Here is my reasoning. > > > > The sytem V ABI specifies _test_and_set() as the exntended system call. > > I think we want to execute IRIX binaries. That would make sense to keep sysmips() as it is if your statement is true. But I thought the binary comptability with IRIX has long been broken. Can someone confirm that? If binary compatbility with IRIX is broken now, I don't think we should care to fix it in the future - obviously. :-) Jun From owner-linux-mips@oss.sgi.com Wed May 23 14:07:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NL7t823730 for linux-mips-outgoing; Wed, 23 May 2001 14:07:55 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NL7pF23725; Wed, 23 May 2001 14:07:51 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4NL6T013900; Wed, 23 May 2001 14:06:29 -0700 Message-ID: <3B0C263F.B4BD9259@mvista.com> Date: Wed, 23 May 2001 14:06:07 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Florian Lohoff CC: Joe deBlaquiere , "Maciej W. Rozycki" , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B0BF7F8.3050306@redhat.com> <3B0C0475.B9ACE682@mvista.com> <20010523205412.A10981@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 601 Lines: 17 Florian Lohoff wrote: > My favourit would be to let the glibc on runtime decide whether > to use sysmips or ll/sc in the atomic test_and_set stuff. This would > lead to an common atom op in the userspace which is fast on ll/sc > cpus and gives much lesser performance penaltys in the sysmips case > than emulating ll/sc. > Do you have an idea how this run-time detection might be implemented? I am very curious. For example, how will you figure out the existence of ll/sc instruction? Is that a test which is a part of every process startup procedure? Or do you introduce a new syscall? Jun From owner-linux-mips@oss.sgi.com Wed May 23 14:53:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NLrE424938 for linux-mips-outgoing; Wed, 23 May 2001 14:53:14 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NLqwF24931 for ; Wed, 23 May 2001 14:53:13 -0700 Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 152gYr-0003QK-00 for ; Wed, 23 May 2001 14:52:57 -0700 Date: Wed, 23 May 2001 14:52:57 -0700 From: Daniel Jacobowitz To: linux-mips@oss.sgi.com Subject: [PATCH] incorrect asm constraints for ll/sc constructs Message-ID: <20010523145257.A13013@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline User-Agent: Mutt/1.3.16i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2107 Lines: 60 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The ll/sc constructs in the kernel use ".set noat" to inhibit use of $at, and proceed to use it themselves. This is fine, except for one problem: the constraints on memory operands are "o" and "=o", which means offsettable memory references. If I'm not mistaken, the assembler will (always?) turn these into uses of $at if the offset is not 0 - at least, it certainly seems to do that here (gcc 2.95.3, binutils 2.10.91.0.2). Just being honest with the compiler and asking for a real memory reference does the trick. Does this patch look right? -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mips-offset.diff" Index: arch/mips/kernel/sysmips.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v retrieving revision 1.18 diff -u -r1.18 sysmips.c --- arch/mips/kernel/sysmips.c 2001/04/08 13:24:27 1.18 +++ arch/mips/kernel/sysmips.c 2001/05/23 21:49:29 @@ -99,8 +99,8 @@ ".word\t1b, 3b\n\t" ".word\t2b, 3b\n\t" ".previous\n\t" - : "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno) - : "r" (arg2), "o" (* (u32 *) p), "2" (errno) + : "=&r" (tmp), "=m" (* (u32 *) p), "=r" (errno) + : "r" (arg2), "m" (* (u32 *) p), "2" (errno) : "$1"); if (errno) Index: include/asm-mips/system.h =================================================================== RCS file: /cvs/linux/include/asm-mips/system.h,v retrieving revision 1.27 diff -u -r1.27 system.h --- include/asm-mips/system.h 2001/03/28 01:35:12 1.27 +++ include/asm-mips/system.h 2001/05/23 21:49:29 @@ -219,8 +219,8 @@ " ll\t%0, %3\n\t" ".set\tat\n\t" ".set\treorder" - : "=r" (val), "=o" (*m), "=r" (dummy) - : "o" (*m), "2" (val) + : "=r" (val), "=m" (*m), "=r" (dummy) + : "m" (*m), "2" (val) : "memory"); return val; --17pEHd4RhPHOinZp-- From owner-linux-mips@oss.sgi.com Wed May 23 16:11:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NNB2Z26799 for linux-mips-outgoing; Wed, 23 May 2001 16:11:02 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NNAuF26794 for ; Wed, 23 May 2001 16:10:56 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id BAA64469 for ; Thu, 24 May 2001 01:10:54 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 152hmH-0004M8-00 for ; Thu, 24 May 2001 01:10:53 +0200 Date: Thu, 24 May 2001 01:10:53 +0200 To: linux-mips@oss.sgi.com Subject: [PATCH] mips64 typo and formatting fixes Message-ID: <20010524011053.J11643@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 24868 Lines: 872 Hi All, here is some fallout from my mips64 development, most of it is fixing of typos and source code formatting. Ok to apply? Thiemo diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/arc/Makefile linux/arch/mips64/arc/Makefile --- linux-orig/arch/mips64/arc/Makefile Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/arc/Makefile Wed May 23 23:39:56 2001 @@ -7,6 +7,6 @@ file.o obj-$(CONFIG_ARC_MEMORY) += memory.o -obj-$(CONFIG_ARC_CONSOLE) += arc_con.o +obj-$(CONFIG_ARC_CONSOLE) += arc_con.o include $(TOPDIR)/Rules.make diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/r4k_fpu.S linux/arch/mips64/kernel/r4k_fpu.S --- linux-orig/arch/mips64/kernel/r4k_fpu.S Wed Apr 11 23:21:33 2001 +++ linux/arch/mips64/kernel/r4k_fpu.S Wed May 23 23:39:56 2001 @@ -32,11 +32,11 @@ .set noreorder /* Save floating point context */ LEAF(save_fp_context) - mfc0 t1,CP0_STATUS - sll t2,t1,5 + mfc0 t1, CP0_STATUS + sll t2, t1,5 - bgez t2,1f - cfc1 t1,fcr31 + bgez t2, 1f + cfc1 t1, fcr31 /* Store the 16 odd double precision registers */ EX sdc1 $f1, SC_FPREGS+8(a0) EX sdc1 $f3, SC_FPREGS+24(a0) @@ -74,8 +74,8 @@ EX sdc1 $f28, SC_FPREGS+224(a0) EX sdc1 $f30, SC_FPREGS+240(a0) EX sw t1, SC_FPC_CSR(a0) - cfc1 t0,$0 # implementation/version - EX sw t0,SC_FPC_EIR(a0) + cfc1 t0, $0 # implementation/version + EX sw t0, SC_FPC_EIR(a0) jr ra li v0, 0 # success @@ -92,8 +92,8 @@ */ LEAF(restore_fp_context) mfc0 t1, CP0_STATUS - sll t0,t1,5 - bgez t0,1f + sll t0, t1,5 + bgez t0, 1f EX lw t0, SC_FPC_CSR(a0) /* Restore the 16 odd double precision registers only @@ -136,14 +136,13 @@ EX ldc1 $f26, SC_FPREGS+208(a0) EX ldc1 $f28, SC_FPREGS+224(a0) EX ldc1 $f30, SC_FPREGS+240(a0) - ctc1 t0,fcr31 + ctc1 t0, fcr31 jr ra li v0, 0 # success END(restore_fp_context) - .set reorder .type fault@function .ent fault -fault: li v0, -EFAULT - jr ra +fault: jr ra + li v0, -EFAULT # failure .end fault diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/scall_64.S linux/arch/mips64/kernel/scall_64.S --- linux-orig/arch/mips64/kernel/scall_64.S Tue Sep 5 03:13:01 2000 +++ linux/arch/mips64/kernel/scall_64.S Wed May 23 23:39:56 2001 @@ -131,217 +132,217 @@ END(handle_sys64) sys_call_table: - PTR sys_syscall /* 4000 */ + PTR sys_syscall /* 5000 */ PTR sys_exit PTR sys_fork PTR sys_read PTR sys_write - PTR sys_open /* 4005 */ + PTR sys_open /* 5005 */ PTR sys_close PTR sys_waitpid PTR sys_creat PTR sys_link - PTR sys_unlink /* 4010 */ + PTR sys_unlink /* 5010 */ PTR sys_execve PTR sys_chdir PTR sys_time PTR sys_mknod - PTR sys_chmod /* 4015 */ + PTR sys_chmod /* 5015 */ PTR sys_lchown PTR sys_ni_syscall PTR sys_stat PTR sys_lseek - PTR sys_getpid /* 4020 */ + PTR sys_getpid /* 5020 */ PTR sys_mount PTR sys_oldumount PTR sys_setuid PTR sys_getuid - PTR sys_stime /* 4025 */ + PTR sys_stime /* 5025 */ PTR sys_ni_syscall /* ptrace */ PTR sys_alarm PTR sys_fstat PTR sys_pause - PTR sys_utime /* 4030 */ + PTR sys_utime /* 5030 */ PTR sys_ni_syscall PTR sys_ni_syscall PTR sys_access PTR sys_nice - PTR sys_ni_syscall /* 4035 */ + PTR sys_ni_syscall /* 5035 */ PTR sys_sync PTR sys_kill PTR sys_rename PTR sys_mkdir - PTR sys_rmdir /* 4040 */ + PTR sys_rmdir /* 5040 */ PTR sys_dup PTR sys_pipe PTR sys_times PTR sys_ni_syscall - PTR sys_brk /* 4045 */ + PTR sys_brk /* 5045 */ PTR sys_setgid PTR sys_getgid PTR sys_ni_syscall /* was signal 2 */ PTR sys_geteuid - PTR sys_getegid /* 4050 */ + PTR sys_getegid /* 5050 */ PTR sys_acct PTR sys_umount PTR sys_ni_syscall PTR sys_ioctl - PTR sys_fcntl /* 4055 */ + PTR sys_fcntl /* 5055 */ PTR sys_ni_syscall PTR sys_setpgid PTR sys_ni_syscall PTR sys_ni_syscall - PTR sys_umask /* 4060 */ + PTR sys_umask /* 5060 */ PTR sys_chroot PTR sys_ustat PTR sys_dup2 PTR sys_getppid - PTR sys_getpgrp /* 4065 */ + PTR sys_getpgrp /* 5065 */ PTR sys_setsid PTR sys_sigaction PTR sys_sgetmask PTR sys_ssetmask - PTR sys_setreuid /* 4070 */ + PTR sys_setreuid /* 5070 */ PTR sys_setregid PTR sys_sigsuspend PTR sys_sigpending PTR sys_sethostname - PTR sys_setrlimit /* 4075 */ + PTR sys_setrlimit /* 5075 */ PTR sys_getrlimit PTR sys_getrusage PTR sys_gettimeofday PTR sys_settimeofday - PTR sys_getgroups /* 4080 */ + PTR sys_getgroups /* 5080 */ PTR sys_setgroups PTR sys_ni_syscall /* old_select */ PTR sys_symlink PTR sys_lstat - PTR sys_readlink /* 4085 */ + PTR sys_readlink /* 5085 */ PTR sys_uselib PTR sys_swapon PTR sys_reboot PTR sys_ni_syscall /* old_readdir */ - PTR sys_mmap /* 4090 */ + PTR sys_mmap /* 5090 */ PTR sys_munmap PTR sys_truncate PTR sys_ftruncate PTR sys_fchmod - PTR sys_fchown /* 4095 */ + PTR sys_fchown /* 5095 */ PTR sys_getpriority PTR sys_setpriority PTR sys_ni_syscall PTR sys_statfs - PTR sys_fstatfs /* 4100 */ + PTR sys_fstatfs /* 5100 */ PTR sys_ni_syscall /* sys_ioperm */ PTR sys_socketcall PTR sys_syslog PTR sys_setitimer - PTR sys_getitimer /* 4105 */ + PTR sys_getitimer /* 5105 */ PTR sys_newstat PTR sys_newlstat PTR sys_newfstat PTR sys_ni_syscall - PTR sys_ni_syscall /* sys_ioperm *//* 4110 */ + PTR sys_ni_syscall /* sys_ioperm *//* 5110 */ PTR sys_vhangup PTR sys_ni_syscall /* was sys_idle */ PTR sys_ni_syscall /* sys_vm86 */ PTR sys_wait4 - PTR sys_swapoff /* 4115 */ + PTR sys_swapoff /* 5115 */ PTR sys_sysinfo PTR sys_ipc PTR sys_fsync PTR sys_sigreturn - PTR sys_clone /* 4120 */ + PTR sys_clone /* 5120 */ PTR sys_setdomainname PTR sys_newuname PTR sys_ni_syscall /* sys_modify_ldt */ PTR sys_adjtimex - PTR sys_mprotect /* 4125 */ + PTR sys_mprotect /* 5125 */ PTR sys_sigprocmask PTR sys_create_module PTR sys_init_module PTR sys_delete_module - PTR sys_get_kernel_syms /* 4130 */ + PTR sys_get_kernel_syms /* 5130 */ PTR sys_quotactl PTR sys_getpgid PTR sys_fchdir PTR sys_bdflush - PTR sys_sysfs /* 4135 */ + PTR sys_sysfs /* 5135 */ PTR sys_personality PTR sys_ni_syscall /* for afs_syscall */ PTR sys_setfsuid PTR sys_setfsgid - PTR sys_llseek /* 4140 */ + PTR sys_llseek /* 5140 */ PTR sys_getdents PTR sys_select PTR sys_flock PTR sys_msync - PTR sys_readv /* 4145 */ + PTR sys_readv /* 5145 */ PTR sys_writev PTR sys_cacheflush PTR sys_cachectl PTR sys_sysmips - PTR sys_ni_syscall /* 4150 */ + PTR sys_ni_syscall /* 5150 */ PTR sys_getsid PTR sys_fdatasync PTR sys_sysctl PTR sys_mlock - PTR sys_munlock /* 4155 */ + PTR sys_munlock /* 5155 */ PTR sys_mlockall PTR sys_munlockall PTR sys_sched_setparam PTR sys_sched_getparam - PTR sys_sched_setscheduler /* 4160 */ + PTR sys_sched_setscheduler /* 5160 */ PTR sys_sched_getscheduler PTR sys_sched_yield PTR sys_sched_get_priority_max PTR sys_sched_get_priority_min - PTR sys_sched_rr_get_interval /* 4165 */ + PTR sys_sched_rr_get_interval /* 5165 */ PTR sys_nanosleep PTR sys_mremap PTR sys_accept PTR sys_bind - PTR sys_connect /* 4170 */ + PTR sys_connect /* 5170 */ PTR sys_getpeername PTR sys_getsockname PTR sys_getsockopt PTR sys_listen - PTR sys_recv /* 4175 */ + PTR sys_recv /* 5175 */ PTR sys_recvfrom PTR sys_recvmsg PTR sys_send PTR sys_sendmsg - PTR sys_sendto /* 4180 */ + PTR sys_sendto /* 5180 */ PTR sys_setsockopt PTR sys_shutdown PTR sys_socket PTR sys_socketpair - PTR sys_setresuid /* 4185 */ + PTR sys_setresuid /* 5185 */ PTR sys_getresuid PTR sys_query_module PTR sys_poll PTR sys_nfsservctl - PTR sys_setresgid /* 4190 */ + PTR sys_setresgid /* 5190 */ PTR sys_getresgid PTR sys_prctl PTR sys_rt_sigreturn PTR sys_rt_sigaction - PTR sys_rt_sigprocmask /* 4195 */ + PTR sys_rt_sigprocmask /* 5195 */ PTR sys_rt_sigpending PTR sys_rt_sigtimedwait PTR sys_rt_sigqueueinfo PTR sys_rt_sigsuspend - PTR sys_pread /* 4200 */ + PTR sys_pread /* 5200 */ PTR sys_pwrite PTR sys_chown PTR sys_getcwd PTR sys_capget - PTR sys_capset /* 4205 */ + PTR sys_capset /* 5205 */ PTR sys_sigaltstack PTR sys_sendfile PTR sys_ni_syscall PTR sys_ni_syscall - PTR sys_pivot_root /* 4210 */ + PTR sys_pivot_root /* 5210 */ PTR sys_mincore PTR sys_madvise PTR sys_getdents64 diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/setup.c linux/arch/mips64/kernel/setup.c --- linux-orig/arch/mips64/kernel/setup.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/kernel/setup.c Wed May 23 23:39:56 2001 @@ -150,7 +154,7 @@ bootmem_init (); #endif - strncpy (command_line, arcs_cmdline, CL_SIZE); + strncpy(command_line, arcs_cmdline, CL_SIZE); memcpy(saved_command_line, command_line, CL_SIZE); saved_command_line[CL_SIZE-1] = '\0'; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/andes.c linux/arch/mips64/mm/andes.c --- linux-orig/arch/mips64/mm/andes.c Thu Nov 30 22:09:18 2000 +++ linux/arch/mips64/mm/andes.c Wed May 23 23:39:56 2001 @@ -284,8 +284,8 @@ if((pid != (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) & 0xff)) || (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) == 0)) { - printk("update_mmu_cache: Wheee, bogus tlbpid mmpid=%d - tlbpid=%d\n", (int) (CPU_CONTEXT(smp_processor_id(), + printk("update_mmu_cache: Wheee, bogus tlbpid mmpid=%d " + "tlbpid=%d\n", (int) (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) & 0xff), pid); } diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/init.c linux/arch/mips64/mm/init.c --- linux-orig/arch/mips64/mm/init.c Thu Apr 5 20:25:43 2001 +++ linux/arch/mips64/mm/init.c Wed May 23 23:39:56 2001 @@ -119,7 +119,7 @@ } /* - * We have upto 8 empty zeroed pages so we can map one of the right colour + * We have up to 8 empty zeroed pages so we can map one of the right colour * when needed. This is necessary only on R4000 / R4400 SC and MC versions * where we have to avoid VCED / VECI exceptions for good performance at * any price. Since page is never written to after the initialization we @@ -201,7 +201,7 @@ } } -void bootmem_init (void) { +void bootmem_init(void) { #ifdef CONFIG_BLK_DEV_INITRD unsigned long tmp; unsigned long *initrd_header; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/ip22-mc.c linux/arch/mips64/sgi-ip22/ip22-mc.c --- linux-orig/arch/mips64/sgi-ip22/ip22-mc.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/sgi-ip22/ip22-mc.c Wed May 23 23:39:56 2001 @@ -3,7 +3,7 @@ * License. See the file "COPYING" in the main directory of this archive * for more details. * - * indy_mc.c: Routines for manipulating the INDY memory controller. + * ip22-mc.c: Routines for manipulating the INDY memory controller. * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) * Copyright (C) 2001 Ralf Baechle (ralf@gnu.org) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/ip22-sc.c linux/arch/mips64/sgi-ip22/ip22-sc.c --- linux-orig/arch/mips64/sgi-ip22/ip22-sc.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/sgi-ip22/ip22-sc.c Wed May 23 23:39:56 2001 @@ -29,14 +29,14 @@ static inline void indy_sc_wipe(unsigned long first, unsigned long last) { - __asm__ __volatile__(" - .set noreorder - or %0, %4 # first line to flush - or %1, %4 # last line to flush -1: sw $0, 0(%0) - bne %0, %1, 1b - daddu %0, 32 - .set reorder" + __asm__ __volatile__( + "\t.set noreorder\n\t" + "or %0, %4 # first line to flush\n\t" + "or %1, %4 # last line to flush\n" + "1: sw $0, 0(%0)\n\t" + "bne %0, %1, 1b\n\t" + "daddu %0, 32\n\t" + ".set reorder" : "=r" (first), "=r" (last) : "0" (first), "1" (last), "r" (0x9000000080000000) : "$1"); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips/sgialib.h linux/include/asm-mips/sgialib.h --- linux-orig/include/asm-mips/sgialib.h Tue Mar 20 00:03:16 2001 +++ linux/include/asm-mips/sgialib.h Wed May 23 23:39:56 2001 @@ -64,9 +64,9 @@ */ extern void prom_identify_arch(void); -/* Environemt variable routines. */ +/* Environment variable routines. */ extern PCHAR ArcGetEnvironmentVariable(CHAR *name); -extern LONG SetEnvironmentVariable(PCHAR name, PCHAR value); +extern LONG ArcSetEnvironmentVariable(PCHAR name, PCHAR value); /* ARCS command line acquisition and parsing. */ extern char *prom_getcmdline(void); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/asm.h linux/include/asm-mips64/asm.h --- linux-orig/include/asm-mips64/asm.h Tue Jan 18 00:32:47 2000 +++ linux/include/asm-mips64/asm.h Wed May 23 23:39:56 2001 @@ -94,7 +94,7 @@ TEXT(msg) /* - * Print formated string + * Print formatted string */ #define PRINT(string) \ .set push; \ @@ -105,7 +105,7 @@ TEXT(string) /* - * Print formated string + * Print formatted string */ #define PROM_PRINT(string) \ .set push; \ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/bootinfo.h linux/include/asm-mips64/bootinfo.h --- linux-orig/include/asm-mips64/bootinfo.h Tue Mar 20 00:03:16 2001 +++ linux/include/asm-mips64/bootinfo.h Wed May 23 23:39:56 2001 @@ -88,7 +88,7 @@ /* * Valid machtype for group SGI */ -#define MACH_SGI_INDY 0 /* R4?K and R5K Indy workstaions */ +#define MACH_SGI_INDY 0 /* R4?K and R5K Indy workstations */ #define MACH_SGI_CHALLENGE_S 1 /* The Challenge S server */ #define MACH_SGI_INDIGO2 2 /* The Indigo2 system */ #define MACH_SGI_IP27 3 /* Origin 200, Origin 2000, Onyx 2 */ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/checksum.h linux/include/asm-mips64/checksum.h --- linux-orig/include/asm-mips64/checksum.h Tue Mar 7 16:45:42 2000 +++ linux/include/asm-mips64/checksum.h Wed May 23 23:39:56 2001 @@ -70,15 +70,15 @@ static inline unsigned short int csum_fold(unsigned int sum) { - __asm__(" - .set noat - sll $1, %0, 16 - addu %0, $1 - sltu $1, %0, $1 - srl %0, %0, 16 - addu %0, $1 - xori %0, 0xffff - .set at" + __asm__( +" .set noat\n" +" sll $1, %0, 16\n" +" addu %0, $1\n" +" sltu $1, %0, $1\n" +" srl %0, %0, 16\n" +" addu %0, $1\n" +" xori %0, 0xffff\n" +" .set at" : "=r" (sum) : "0" (sum) : "$1"); @@ -103,36 +103,36 @@ * This is for 32-bit processors ... but works just fine for 64-bit * processors for now ... XXX */ - __asm__ __volatile__(" - .set noreorder - .set noat - lw %0, (%1) - subu %2, 4 - dsll %2, 2 - - lw %3, 4(%1) - daddu %2, %1 - addu %0, %3 - sltu $1, %0, %3 - lw %3, 8(%1) - addu %0, $1 - addu %0, %3 - sltu $1, %0, %3 - lw %3, 12(%1) - addu %0, $1 - addu %0, %3 - sltu $1, %0, %3 - addu %0, $1 - -1: lw %3, 16(%1) - daddiu %1, 4 - addu %0, %3 - sltu $1, %0, %3 - bne %2, %1, 1b - addu %0, $1 - -2: .set at - .set reorder" + __asm__ __volatile__( +" .set noreorder\n" +" .set noat\n" +" lw %0, (%1)\n" +" subu %2, 4\n" +" dsll %2, 2\n" +"\n" +" lw %3, 4(%1)\n" +" daddu %2, %1\n" +" addu %0, %3\n" +" sltu $1, %0, %3\n" +" lw %3, 8(%1)\n" +" addu %0, $1\n" +" addu %0, %3\n" +" sltu $1, %0, %3\n" +" lw %3, 12(%1)\n" +" addu %0, $1\n" +" addu %0, %3\n" +" sltu $1, %0, %3\n" +" addu %0, $1\n" +"\n" +"1: lw %3, 16(%1)\n" +" daddiu %1, 4\n" +" addu %0, %3\n" +" sltu $1, %0, %3\n" +" bne %2, %1, 1b\n" +" addu %0, $1\n" +"\n" +"2: .set at\n" +" .set reorder" : "=&r" (sum), "=&r" (iph), "=&r" (ihl), "=&r" (dummy) : "1" (iph), "2" (ihl) : "$1"); @@ -148,15 +148,15 @@ csum_tcpudp_nofold(unsigned long saddr, unsigned long daddr, unsigned short len, unsigned short proto, unsigned int sum) { - __asm__(" - .set noat - daddu %0, %2 - daddu %0, %3 - daddu %0, %4 - dsll32 $1, %0, 0 - daddu %0, $1 # never results in an overflow - dsrl32 %0, %0, 0 - .set at" + __asm__( +" .set noat\n" +" daddu %0, %2\n" +" daddu %0, %3\n" +" daddu %0, %4\n" +" dsll32 $1, %0, 0\n" +" daddu %0, $1 # never results in an overflow\n" +" dsrl32 %0, %0, 0\n" +" .set at" : "=r" (sum) : "0" (sum), "r"(saddr), "r" (daddr), #ifdef __MIPSEL__ @@ -195,56 +195,56 @@ csum_ipv6_magic(struct in6_addr *saddr, struct in6_addr *daddr, __u32 len, unsigned short proto, unsigned int sum) { - __asm__(" - .set noreorder - .set noat - addu %0, %5 # proto (long in network byte order) - sltu $1, %0, %5 - addu %0, $1 - - addu %0, %6 # csum - sltu $1, %0, %6 - lw %1, 0(%2) # four words source address - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 4(%2) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 8(%2) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 12(%2) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 0(%3) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 4(%3) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 8(%3) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 12(%3) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - .set noat - .set noreorder" + __asm__( +" .set noreorder\n" +" .set noat\n" +" addu %0, %5 # proto (long in network byte order)\n" +" sltu $1, %0, %5\n" +" addu %0, $1\n" +"\n" +" addu %0, %6 # csum\n" +" sltu $1, %0, %6\n" +" lw %1, 0(%2) # four words source address\n" +" addu %0, $1\n" +" addu %0, %1\n" +" sltu $1, %0, $1\n" +"\n" +" lw %1, 4(%2)\n" +" addu %0, $1\n" +" addu %0, %1\n" +" sltu $1, %0, $1\n" +"\n" +" lw %1, 8(%2)\n" +" addu %0, $1\n" +" addu %0, %1\n" +" sltu $1, %0, $1\n" +"\n" +" lw %1, 12(%2)\n" +" addu %0, $1\n" +" addu %0, %1\n" +" sltu $1, %0, $1\n" +"\n" +" lw %1, 0(%3)\n" +" addu %0, $1\n" +" addu %0, %1\n" +" sltu $1, %0, $1\n" +"\n" +" lw %1, 4(%3)\n" +" addu %0, $1\n" +" addu %0, %1\n" +" sltu $1, %0, $1\n" +"\n" +" lw %1, 8(%3)\n" +" addu %0, $1\n" +" addu %0, %1\n" +" sltu $1, %0, $1\n" +"\n" +" lw %1, 12(%3)\n" +" addu %0, $1\n" +" addu %0, %1\n" +" sltu $1, %0, $1\n" +" .set noat\n" +" .set noreorder" : "=r" (sum), "=r" (proto) : "r" (saddr), "r" (daddr), "0" (htonl(len)), "1" (htonl(proto)), "r"(sum) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/cpu.h linux/include/asm-mips64/cpu.h --- linux-orig/include/asm-mips64/cpu.h Mon Mar 5 00:56:30 2001 +++ linux/include/asm-mips64/cpu.h Wed May 23 23:39:56 2001 @@ -22,14 +22,13 @@ #define PRID_IMP_R4000 0x0400 #define PRID_IMP_R6000A 0x0600 #define PRID_IMP_R10000 0x0900 -#define PRID_IMP_R12000 0x0e00 #define PRID_IMP_R4300 0x0b00 #define PRID_IMP_R12000 0x0e00 #define PRID_IMP_R8000 0x1000 #define PRID_IMP_R4600 0x2000 #define PRID_IMP_R4700 0x2100 #define PRID_IMP_R4640 0x2200 -#define PRID_IMP_R4650 0x2200 /* Same as R4640 */ +#define PRID_IMP_R4650 0x2200 /* Same as R4640 */ #define PRID_IMP_R5000 0x2300 #define PRID_IMP_SONIC 0x2400 #define PRID_IMP_MAGIC 0x2500 diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/mipsregs.h linux/include/asm-mips64/mipsregs.h --- linux-orig/include/asm-mips64/mipsregs.h Mon Oct 2 22:44:46 2000 +++ linux/include/asm-mips64/mipsregs.h Wed May 23 23:39:56 2001 @@ -246,7 +246,7 @@ #define CAUSEF_BD (1 << 31) /* - * Bits in the coprozessor 0 config register. + * Bits in the coprocessor 0 config register. */ #define CONF_CM_CACHABLE_NO_WA 0 #define CONF_CM_CACHABLE_WA 1 @@ -265,7 +265,7 @@ * R10000 performance counter definitions. * * FIXME: The R10000 performance counter opens a nice way to implement CPU - * time accounting with a precission of one cycle. I don't have + * time accounting with a precision of one cycle. I don't have * R10000 silicon but just a manual, so ... */ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgi/sgint23.h linux/include/asm-mips64/sgi/sgint23.h --- linux-orig/include/asm-mips64/sgi/sgint23.h Mon Nov 27 00:52:51 2000 +++ linux/include/asm-mips64/sgi/sgint23.h Wed May 23 23:39:56 2001 @@ -170,7 +170,7 @@ #endif #define INT2_TCLEAR_T0CLR 0x1 /* Clear timer0 IRQ */ #define INT2_TCLEAR_T1CLR 0x2 /* Clear timer1 IRQ */ -/* I am guesing there are only two unused registers here +/* I am guessing there are only two unused registers here * but I could be wrong... - andrewb */ /* u32 _unused[3]; */ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgialib.h linux/include/asm-mips64/sgialib.h --- linux-orig/include/asm-mips64/sgialib.h Tue Mar 20 00:03:16 2001 +++ linux/include/asm-mips64/sgialib.h Wed May 23 23:45:29 2001 @@ -90,9 +89,9 @@ */ extern void prom_identify_arch(void); -/* Environemt variable routines. */ +/* Environment variable routines. */ extern PCHAR ArcGetEnvironmentVariable(PCHAR name); -extern LONG SetEnvironmentVariable(PCHAR name, PCHAR value); +extern LONG ArcSetEnvironmentVariable(PCHAR name, PCHAR value); /* ARCS command line acquisition and parsing. */ extern char *prom_getcmdline(void); @@ -120,11 +119,11 @@ extern long prom_exec(char *name, long argc, char **argv, char **envp); /* Misc. routines. */ -extern void prom_halt(VOID) __attribute__((noreturn)); -extern void prom_powerdown(VOID) __attribute__((noreturn)); -extern void prom_restart(VOID) __attribute__((noreturn)); +extern VOID prom_halt(VOID) __attribute__((noreturn)); +extern VOID prom_powerdown(VOID) __attribute__((noreturn)); +extern VOID prom_restart(VOID) __attribute__((noreturn)); extern VOID ArcReboot(VOID) __attribute__((noreturn)); -extern VOID ArcEnterInteractiveMode(void) __attribute__((noreturn)); +extern VOID ArcEnterInteractiveMode(VOID) __attribute__((noreturn)); extern long prom_cfgsave(VOID); extern struct linux_sysid *prom_getsysid(VOID); extern VOID ArcFlushAllCaches(VOID); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgiarcs.h linux/include/asm-mips64/sgiarcs.h --- linux-orig/include/asm-mips64/sgiarcs.h Tue Jan 18 00:32:47 2000 +++ linux/include/asm-mips64/sgiarcs.h Wed May 23 23:45:29 2001 @@ -143,7 +143,7 @@ /* ARCS virtual dirents. */ struct linux_vdirent { - unsigned long namelen; + ULONG namelen; unsigned char attr; char fname[32]; /* XXX imperical, should be a define */ }; @@ -177,38 +177,38 @@ struct linux_bigint begin; struct linux_bigint end; struct linux_bigint cur; - enum linux_devtypes dtype; + enum linux_devtypes dtype; unsigned long namelen; unsigned char attr; char name[32]; /* XXX imperical, should be define */ }; -/* This describes the vector containing fuction pointers to the ARC +/* This describes the vector containing function pointers to the ARC firmware functions. */ struct linux_romvec { - LONG load; /* Load an executable image. */ - LONG invoke; /* Invoke a standalong image. */ - LONG exec; /* Load and begin execution of a + LONG load; /* Load an executable image. */ + LONG invoke; /* Invoke a standalong image. */ + LONG exec; /* Load and begin execution of a standalone image. */ - LONG halt; /* Halt the machine. */ - LONG pdown; /* Power down the machine. */ - LONG restart; /* XXX soft reset??? */ - LONG reboot; /* Reboot the machine. */ - LONG imode; /* Enter PROM interactive mode. */ - LONG _unused1; /* Was ReturnFromMain(). */ + LONG halt; /* Halt the machine. */ + LONG pdown; /* Power down the machine. */ + LONG restart; /* XXX soft reset??? */ + LONG reboot; /* Reboot the machine. */ + LONG imode; /* Enter PROM interactive mode. */ + LONG _unused1; /* Was ReturnFromMain(). */ /* PROM device tree interface. */ - LONG next_component; - LONG child_component; - LONG parent_component; - LONG component_data; - LONG child_add; - LONG comp_del; - LONG component_by_path; + LONG next_component; + LONG child_component; + LONG parent_component; + LONG component_data; + LONG child_add; + LONG comp_del; + LONG component_by_path; /* Misc. stuff. */ - LONG cfg_save; - LONG get_sysid; + LONG cfg_save; + LONG get_sysid; /* Probing for memory. */ LONG get_mdesc; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/system.h linux/include/asm-mips64/system.h --- linux-orig/include/asm-mips64/system.h Thu Oct 26 03:18:01 2000 +++ linux/include/asm-mips64/system.h Wed May 23 23:39:57 2001 @@ -33,7 +33,7 @@ } /* - * For cli() we have to insert nops to make shure that the new value + * For cli() we have to insert nops to make sure that the new value * has actually arrived in the status register before the end of this * macro. * R4000/R4400 need three nops, the R4600 two nops and the R10000 needs Binary files linux-orig/vmlinux.64 and linux/vmlinux.64 differ From owner-linux-mips@oss.sgi.com Wed May 23 16:45:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NNjAM27544 for linux-mips-outgoing; Wed, 23 May 2001 16:45:10 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NNj9F27541 for ; Wed, 23 May 2001 16:45:09 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA15794; Wed, 23 May 2001 16:45:02 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA10153; Wed, 23 May 2001 16:44:58 -0700 (PDT) Message-ID: <011501c0e3e3$007c4780$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: "Joe deBlaquiere" , References: Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Date: Thu, 24 May 2001 01:49:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1046 Lines: 26 > > parts, the latter is more efficient for contemporary parts. Those > > of us who work on recent and future designs will always tend > > to favor the latter - what's the point of using MIPS32/MIPS64 > > and beyond CPUs if gnu/Linux binaries are going to treat them > > like R3000s? > > If you work on new processors only, then there is no problem. You > configure your tools to build binaries for systems you use and you'll > never see R3k compatibility code. > > Please do yourself a favor and look at the relevant part of glibc. If > you build glibc (and any other other program that makes use of > _test_and_set()) for ISA II+, the code gets actually inlined with ll/sc > used as expected. > > So the problem is? The problem is that, out in industry, not everyone wants to build their entire userland from source, and nobody particularly wants to deal with the product management problems of making, maintaining, testing, and distributing all the permutations of BE/LE, FP/noFP, LLSC/noLLSC, etc, etc. Kevin K. From owner-linux-mips@oss.sgi.com Wed May 23 21:15:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4O4F8i03805 for linux-mips-outgoing; Wed, 23 May 2001 21:15:08 -0700 Received: from blackdog.wirespeed.com ([208.170.106.25]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O4F7F03801 for ; Wed, 23 May 2001 21:15:07 -0700 Received: from redhat.com (IDENT:joe@dhcp-245.hsv.redhat.com [172.16.17.245] (may be forged)) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id XAA08458; Wed, 23 May 2001 23:00:29 -0500 Message-ID: <3B0C89E0.2060204@redhat.com> Date: Wed, 23 May 2001 23:11:12 -0500 From: Joe deBlaquiere User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.8.1) Gecko/20010422 X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <011501c0e3e3$007c4780$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 887 Lines: 30 Kevin D. Kissell wrote: >> >> So the problem is? > > > The problem is that, out in industry, not everyone wants to > build their entire userland from source, and nobody particularly > wants to deal with the product management problems of making, > maintaining, testing, and distributing all the permutations of BE/LE, > FP/noFP, LLSC/noLLSC, etc, etc. > Could not have said it better myself. If you have the emulation then you can always use a noLLSC version of glibc if you are performance-driven. Otherwise you can _also_ use the generic LLSC version. The overhead of having a few hundreds of words of code is pretty small (compared with 70+k of filenames via the BUG() macro) and ensures that either glibc will work. It's the best of both worlds. -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Wed May 23 21:26:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4O4Qmv04316 for linux-mips-outgoing; Wed, 23 May 2001 21:26:48 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O4QhF04310; Wed, 23 May 2001 21:26:43 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id B8F29F1A9; Wed, 23 May 2001 21:25:21 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 42AF0BBE0; Wed, 23 May 2001 21:25:35 -0700 (PDT) Date: Wed, 23 May 2001 21:25:35 -0700 From: Keith M Wesolowski To: "Maciej W. Rozycki" Cc: Florian Lohoff , Jun Sun , Joe deBlaquiere , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Message-ID: <20010523212535.C10516@foobazco.org> References: <20010523205412.A10981@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, May 23, 2001 at 09:44:36PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 596 Lines: 14 On Wed, May 23, 2001 at 09:44:36PM +0200, Maciej W. Rozycki wrote: > solve a single inefficiency of ISA I code when run on better CPUs. You > really want to recompile code to make use of new instructions if you care > about performance. I agree. Therefore I am sure some MIPS I users will be happy to build special glibcs for their ISA. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Thu May 24 02:48:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4O9m8710574 for linux-mips-outgoing; Thu, 24 May 2001 02:48:08 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O9kWF10527; Thu, 24 May 2001 02:47:36 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA07583; Thu, 24 May 2001 11:32:30 +0200 (MET DST) Date: Thu, 24 May 2001 11:32:29 +0200 (MET DST) From: "Maciej W. Rozycki" To: Joe deBlaquiere cc: Florian Lohoff , Jun Sun , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com, "Kevin D. Kissell" Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B0C17D9.3060600@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 995 Lines: 22 On Wed, 23 May 2001, Joe deBlaquiere wrote: > ll/sc emulation. If somebody wants to make a MIPS I optimized glibc, > then that's fine, but allowing the 'standard' MIPSII glibc to work on > all systems simplifies life ( mine at least ;) ). I have no objections against providing an ll/sc emulation -- I have never had and certainly haven't expressed them. What I insist on is to keep ISA-I-compiled glibc not making use of ll/sc. Anyone feel free to finish the emulation we have. Anyway, an ISA-II-compiled glibc won't work on an ISA I system even if the ll/sc emulation works. An ISA II is more than just an addition of the ll and sc instructions. There were also branch likely, trap and doubleword coprocessor load instructions added in ISA II. Do you want to emulate these, too? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 24 04:01:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4OB1mc12202 for linux-mips-outgoing; Thu, 24 May 2001 04:01:48 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OB0MF12171 for ; Thu, 24 May 2001 04:00:24 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA10348; Thu, 24 May 2001 12:56:29 +0200 (MET DST) Date: Thu, 24 May 2001 12:56:29 +0200 (MET DST) From: "Maciej W. Rozycki" To: Joe deBlaquiere cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B0C89E0.2060204@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 799 Lines: 20 On Wed, 23 May 2001, Joe deBlaquiere wrote: > Could not have said it better myself. If you have the emulation then you > can always use a noLLSC version of glibc if you are performance-driven. I think there is some misunderstanding here -- I thought you are recommending to drop the non-ll/sc code from glibc. > Otherwise you can _also_ use the generic LLSC version. The overhead of > having a few hundreds of words of code is pretty small (compared with > 70+k of filenames via the BUG() macro) and ensures that either glibc > will work. It's the best of both worlds. Can't agree more. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 24 04:03:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4OB37N12389 for linux-mips-outgoing; Thu, 24 May 2001 04:03:07 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OB0NF12172 for ; Thu, 24 May 2001 04:00:25 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA10098; Thu, 24 May 2001 12:44:34 +0200 (MET DST) Date: Thu, 24 May 2001 12:44:33 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Joe deBlaquiere , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <011501c0e3e3$007c4780$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1839 Lines: 40 On Thu, 24 May 2001, Kevin D. Kissell wrote: > The problem is that, out in industry, not everyone wants to > build their entire userland from source, and nobody particularly > wants to deal with the product management problems of making, > maintaining, testing, and distributing all the permutations of BE/LE, > FP/noFP, LLSC/noLLSC, etc, etc. First, we are talking about glibc and not the entire userland. I insist on having the performance-wise implementation in glibc. Second, do you expect everyone compiling the entire userland from sources? I don't. The normal approach is to take a distribution and build only these pieces which are not satisfying for one reason or another. Just take an ISA I, ISA II or whatever version you need. Third, an ISA-II-hosted glibc still contains an _test_and_set() function which makes use of ll/sc, independently from an inlined version in a header. Fourth, maintaining differently optimized distributions is not that troublesome. It's mostly a matter of disk space (which is hardly an issue these days). Once you have one version ready (prepared manually), all others can be built automatically with no intervention. With RPM it's as easy as having different optflags settings in an rc file and having an autobuilder perform the boring work. It's not a theory, this is for example how the PLD distribution is being developed -- see http://www.pld.org.pl/ for details. It just works. Fifth, I don't object having an ll/sc emulation per se -- as long as you use the ABI-defined _test_and_set() function, everyone is free to recompile sources to suite their needs. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 24 06:45:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ODjnk16056 for linux-mips-outgoing; Thu, 24 May 2001 06:45:49 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ODiIF16017 for ; Thu, 24 May 2001 06:44:31 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA15307; Thu, 24 May 2001 15:42:56 +0200 (MET DST) Date: Thu, 24 May 2001 15:42:56 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <20010523145257.A13013@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1161 Lines: 23 On Wed, 23 May 2001, Daniel Jacobowitz wrote: > The ll/sc constructs in the kernel use ".set noat" to inhibit use of $at, > and proceed to use it themselves. This is fine, except for one problem: the > constraints on memory operands are "o" and "=o", which means offsettable > memory references. If I'm not mistaken, the assembler will (always?) > turn these into uses of $at if the offset is not 0 - at least, it certainly > seems to do that here (gcc 2.95.3, binutils 2.10.91.0.2). Just being honest > with the compiler and asking for a real memory reference does the trick. Both "m" and "o" seem to be incorrect here as both are the same for MIPS; "R" seems to be appropriate, OTOH. Still gcc 2.95.3 doesn't handle "R" fine for all cases, but it works most of the time and emits a warning otherwise. I can't comment on 3.0. Note that if noat is in effect and at is to be used, gas should bail out with an error. There is a bug, if it doesn't. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 24 08:11:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4OFBlh19355 for linux-mips-outgoing; Thu, 24 May 2001 08:11:47 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OFBlF19352 for ; Thu, 24 May 2001 08:11:47 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id IAA20012; Thu, 24 May 2001 08:11:36 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id IAA28775; Thu, 24 May 2001 08:11:33 -0700 (PDT) Message-ID: <001101c0e464$72c130e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: "Joe deBlaquiere" , References: Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Date: Thu, 24 May 2001 17:15:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2110 Lines: 49 > > The problem is that, out in industry, not everyone wants to > > build their entire userland from source, and nobody particularly > > wants to deal with the product management problems of making, > > maintaining, testing, and distributing all the permutations of BE/LE, > > FP/noFP, LLSC/noLLSC, etc, etc. > > First, we are talking about glibc and not the entire userland. But since essentially the entire userland is linked with glibc, I'm not sure how much that distinction matters, in practical terms. > I insist on having the performance-wise implementation in glibc. Joe and I likewise insist on having a high-performance implementation of glibc as the default. The question is whether it's to be one optimised for performance on R3000's or on contemporary parts. As has been stated by others, of *course* one wants to be able to build it either way. I'm simply saying that if one just does "./configure" and "make" for glibc with a mips target, it should default to use ll/sc, and that if one simply builds RPMs for binary distribution of MIPS/Linux binaries, they should be linked with a glibc that uses ll/sc. And that therefore the MIPS/Linux kernel for R3000's (and R4100's) should have ll/sc emulation support built in by default. > Second, do you expect everyone compiling the entire userland from > sources? I don't. The normal approach is to take a distribution and > build only these pieces which are not satisfying for one reason or > another. Just take an ISA I, ISA II or whatever version you need. >From where? I'd love to find a decently complete (with compilers, networking tools, X, etc.) mipsel distribution of any MIPS ISA level less that MIPS V to replace the antique crud that runs on my mipsel platform. > Fourth, maintaining differently optimized distributions is not that > troublesome. Please don't get me wrong here, because I tremendously respect the work that you've been doing for MIPS/Linux, but how many differently optimised distributions do you presonally build, distribute, support, and maintain? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu May 24 09:31:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4OGVg221348 for linux-mips-outgoing; Thu, 24 May 2001 09:31:42 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OGOaF21098 for ; Thu, 24 May 2001 09:25:49 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA20690; Thu, 24 May 2001 18:21:14 +0200 (MET DST) Date: Thu, 24 May 2001 18:21:14 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Joe deBlaquiere , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <001101c0e464$72c130e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3022 Lines: 73 On Thu, 24 May 2001, Kevin D. Kissell wrote: > > First, we are talking about glibc and not the entire userland. > > But since essentially the entire userland is linked with glibc, > I'm not sure how much that distinction matters, in practical > terms. Do you link statically? If not, then almost no code from glibc is incorporated into your binaries, with an unimportant exception of a few functions from libc_nonshared. > I'm simply saying that if one just does "./configure" > and "make" for glibc with a mips target, it should default > to use ll/sc, and that if one simply builds RPMs for binary > distribution of MIPS/Linux binaries, they should be linked > with a glibc that uses ll/sc. And that therefore the MIPS/Linux > kernel for R3000's (and R4100's) should have ll/sc emulation > support built in by default. Then you need to change your gcc configuration so that it assumes "-mips2" (or whatever level you want to) by default. That's typically done in the gcc's specs file. Nothing about glibc here. For RPM you might put "-mips2" into optflags in its rc file. > > Second, do you expect everyone compiling the entire userland from > > sources? I don't. The normal approach is to take a distribution and > > build only these pieces which are not satisfying for one reason or > > another. Just take an ISA I, ISA II or whatever version you need. > > >From where? I'd love to find a decently complete (with compilers, > networking tools, X, etc.) mipsel distribution of any MIPS ISA level > less that MIPS V to replace the antique crud that runs on my mipsel > platform. That's a real problem, but there is Debian available for MIPS -- is it missing anything? The main problem was to get glibc 2.2 right. Since it was done, building other programs should be easy. Then building other variants is just a matter of disk space and CPU time. > > Fourth, maintaining differently optimized distributions is not that > > troublesome. > > Please don't get me wrong here, because I tremendously > respect the work that you've been doing for MIPS/Linux, > but how many differently optimised distributions do you > presonally build, distribute, support, and maintain? I understand maintaining a distribution is serious task, but with appropriate tools maintaining two or more distributions with a common source set is not much harder than a single one. For example, using the source set as available at my FTP site, building differently optimized binaries is as easy as running a script looking more or less as follows: for rc in .rpmrc-mipsel .rpmrc-mipsel-II .rpmrc-mipsel-III .rpmrc-mipsel-IV; do for name in *.src.rpm; do rpm --rcfile=$rc --rebuild $name done done with different optflags set in .rpmrc-mipsel* files. It's boring and disk-consuming but easy and automatic. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 24 15:50:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4OMoMX09733 for linux-mips-outgoing; Thu, 24 May 2001 15:50:22 -0700 Received: from blackdog.wirespeed.com ([208.170.106.25]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OMoLF09730 for ; Thu, 24 May 2001 15:50:21 -0700 Received: from redhat.com (IDENT:joe@uberdog.hsv.redhat.com [172.16.16.108]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id RAA12329; Thu, 24 May 2001 17:35:57 -0500 Message-ID: <3B0D8F51.6000100@redhat.com> Date: Thu, 24 May 2001 17:46:41 -0500 From: Joe deBlaquiere User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.8.1) Gecko/20010422 X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 837 Lines: 40 Maciej W. Rozycki wrote: > On Thu, 24 May 2001, Kevin D. Kissell wrote: > > >>> First, we are talking about glibc and not the entire userland. >> >> But since essentially the entire userland is linked with glibc, >> I'm not sure how much that distinction matters, in practical >> terms. > > > Do you link statically? If not, then almost no code from glibc is > incorporated into your binaries, with an unimportant exception of a few > functions from libc_nonshared. > and those pesky little inlined code snippets... #define PT_EI extern inline PT_EI long int testandset (int *spinlock) which of course uses ll/sc if your world is built for _MIPS_ISA >= _MIPS_ISA_MIPS2 This can be fixed, of course. -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Thu May 24 16:26:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ONQqA10535 for linux-mips-outgoing; Thu, 24 May 2001 16:26:52 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ONQpF10532 for ; Thu, 24 May 2001 16:26:51 -0700 Received: from csh.rit.edu (anna.csh.rit.edu [129.21.60.133]) by mcp.csh.rit.edu (Postfix) with ESMTP id 960911225 for ; Thu, 24 May 2001 19:26:50 -0400 (EDT) Message-ID: <3B0D990B.6090301@csh.rit.edu> Date: Thu, 24 May 2001 19:28:11 -0400 From: George Gensure User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-pre3 i686; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips Subject: crti.o Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 379 Lines: 9 Anyone know what the problem is when building the latest gcc when I get a problem doing the final linking of the libgcc subdir? after listing a whole bunch of object files, (not including crti.o) the linker errors out, saying that it can't find crti.o. I've been muddling through this for a while and just can't figure the problem out exactly... George werkt@csh.rit.edu From owner-linux-mips@oss.sgi.com Thu May 24 16:45:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ONjQG11182 for linux-mips-outgoing; Thu, 24 May 2001 16:45:26 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ONjQF11179 for ; Thu, 24 May 2001 16:45:26 -0700 Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 1534mp-0005ie-00; Thu, 24 May 2001 16:44:59 -0700 Date: Thu, 24 May 2001 16:44:59 -0700 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Message-ID: <20010524164459.A19466@nevyn.them.org> References: <20010523145257.A13013@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, May 24, 2001 at 03:42:56PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1573 Lines: 32 On Thu, May 24, 2001 at 03:42:56PM +0200, Maciej W. Rozycki wrote: > On Wed, 23 May 2001, Daniel Jacobowitz wrote: > > > The ll/sc constructs in the kernel use ".set noat" to inhibit use of $at, > > and proceed to use it themselves. This is fine, except for one problem: the > > constraints on memory operands are "o" and "=o", which means offsettable > > memory references. If I'm not mistaken, the assembler will (always?) > > turn these into uses of $at if the offset is not 0 - at least, it certainly > > seems to do that here (gcc 2.95.3, binutils 2.10.91.0.2). Just being honest > > with the compiler and asking for a real memory reference does the trick. > > Both "m" and "o" seem to be incorrect here as both are the same for MIPS; > "R" seems to be appropriate, OTOH. Still gcc 2.95.3 doesn't handle "R" > fine for all cases, but it works most of the time and emits a warning > otherwise. I can't comment on 3.0. They aren't the same for MIPS, though. I exhibit as evidence the fact that my patch fixed the problem I was seeing. I didn't know about 'R'; I suppose that it is more correct. 'm' at least is closer than 'o', though. If 'R' will behave correctly, could that be applied to CVS, then? > Note that if noat is in effect and at is to be used, gas should bail out > with an error. There is a bug, if it doesn't. It issues a warning, currently (2.10.91.0.2 - I think 2.11 behaves the same). -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team From owner-linux-mips@oss.sgi.com Fri May 25 10:19:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PHJwu04354 for linux-mips-outgoing; Fri, 25 May 2001 10:19:58 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PHJoF04345 for ; Fri, 25 May 2001 10:19:50 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id TAA93300; Fri, 25 May 2001 19:19:38 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 153LFO-0001m0-00; Fri, 25 May 2001 19:19:34 +0200 Date: Fri, 25 May 2001 19:19:34 +0200 To: Keith M Wesolowski Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] mips64 typo and formatting fixes Message-ID: <20010525191934.A5281@rembrandt.csv.ica.uni-stuttgart.de> References: <20010524011053.J11643@rembrandt.csv.ica.uni-stuttgart.de> <20010523213448.D10516@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010523213448.D10516@foobazco.org>; from wesolows@foobazco.org on Wed, May 23, 2001 at 09:34:48PM -0700 From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 31523 Lines: 1087 Keith M Wesolowski wrote: >On Thu, May 24, 2001 at 01:10:53AM +0200, Thiemo Seufer wrote: > >> here is some fallout from my mips64 development, most of it is >> fixing of typos and source code formatting. >> >> Ok to apply? > >Could you please make sure that the checksum code matches that from >mips(32)? It can't, since it is 64bit. :-) >In the process of fixing the warnings in that file, ISTR >Ralf found a bug. If the mentioned is the handling of 'sum' in csum_tcpudp_nofold, it's now corrected. I also changed formatting to the usual one. Thiemo diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/arc/Makefile linux/arch/mips64/arc/Makefile --- linux-orig/arch/mips64/arc/Makefile Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/arc/Makefile Wed May 23 23:39:56 2001 @@ -7,6 +7,6 @@ file.o obj-$(CONFIG_ARC_MEMORY) += memory.o -obj-$(CONFIG_ARC_CONSOLE) += arc_con.o +obj-$(CONFIG_ARC_CONSOLE) += arc_con.o include $(TOPDIR)/Rules.make diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/r4k_fpu.S linux/arch/mips64/kernel/r4k_fpu.S --- linux-orig/arch/mips64/kernel/r4k_fpu.S Wed Apr 11 23:21:33 2001 +++ linux/arch/mips64/kernel/r4k_fpu.S Wed May 23 23:39:56 2001 @@ -32,11 +32,11 @@ .set noreorder /* Save floating point context */ LEAF(save_fp_context) - mfc0 t1,CP0_STATUS - sll t2,t1,5 + mfc0 t1, CP0_STATUS + sll t2, t1,5 - bgez t2,1f - cfc1 t1,fcr31 + bgez t2, 1f + cfc1 t1, fcr31 /* Store the 16 odd double precision registers */ EX sdc1 $f1, SC_FPREGS+8(a0) EX sdc1 $f3, SC_FPREGS+24(a0) @@ -74,8 +74,8 @@ EX sdc1 $f28, SC_FPREGS+224(a0) EX sdc1 $f30, SC_FPREGS+240(a0) EX sw t1, SC_FPC_CSR(a0) - cfc1 t0,$0 # implementation/version - EX sw t0,SC_FPC_EIR(a0) + cfc1 t0, $0 # implementation/version + EX sw t0, SC_FPC_EIR(a0) jr ra li v0, 0 # success @@ -92,8 +92,8 @@ */ LEAF(restore_fp_context) mfc0 t1, CP0_STATUS - sll t0,t1,5 - bgez t0,1f + sll t0, t1,5 + bgez t0, 1f EX lw t0, SC_FPC_CSR(a0) /* Restore the 16 odd double precision registers only @@ -136,14 +136,13 @@ EX ldc1 $f26, SC_FPREGS+208(a0) EX ldc1 $f28, SC_FPREGS+224(a0) EX ldc1 $f30, SC_FPREGS+240(a0) - ctc1 t0,fcr31 + ctc1 t0, fcr31 jr ra li v0, 0 # success END(restore_fp_context) - .set reorder .type fault@function .ent fault -fault: li v0, -EFAULT - jr ra +fault: jr ra + li v0, -EFAULT # failure .end fault diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/scall_64.S linux/arch/mips64/kernel/scall_64.S --- linux-orig/arch/mips64/kernel/scall_64.S Tue Sep 5 03:13:01 2000 +++ linux/arch/mips64/kernel/scall_64.S Wed May 23 23:39:56 2001 @@ -131,217 +132,217 @@ END(handle_sys64) sys_call_table: - PTR sys_syscall /* 4000 */ + PTR sys_syscall /* 5000 */ PTR sys_exit PTR sys_fork PTR sys_read PTR sys_write - PTR sys_open /* 4005 */ + PTR sys_open /* 5005 */ PTR sys_close PTR sys_waitpid PTR sys_creat PTR sys_link - PTR sys_unlink /* 4010 */ + PTR sys_unlink /* 5010 */ PTR sys_execve PTR sys_chdir PTR sys_time PTR sys_mknod - PTR sys_chmod /* 4015 */ + PTR sys_chmod /* 5015 */ PTR sys_lchown PTR sys_ni_syscall PTR sys_stat PTR sys_lseek - PTR sys_getpid /* 4020 */ + PTR sys_getpid /* 5020 */ PTR sys_mount PTR sys_oldumount PTR sys_setuid PTR sys_getuid - PTR sys_stime /* 4025 */ + PTR sys_stime /* 5025 */ PTR sys_ni_syscall /* ptrace */ PTR sys_alarm PTR sys_fstat PTR sys_pause - PTR sys_utime /* 4030 */ + PTR sys_utime /* 5030 */ PTR sys_ni_syscall PTR sys_ni_syscall PTR sys_access PTR sys_nice - PTR sys_ni_syscall /* 4035 */ + PTR sys_ni_syscall /* 5035 */ PTR sys_sync PTR sys_kill PTR sys_rename PTR sys_mkdir - PTR sys_rmdir /* 4040 */ + PTR sys_rmdir /* 5040 */ PTR sys_dup PTR sys_pipe PTR sys_times PTR sys_ni_syscall - PTR sys_brk /* 4045 */ + PTR sys_brk /* 5045 */ PTR sys_setgid PTR sys_getgid PTR sys_ni_syscall /* was signal 2 */ PTR sys_geteuid - PTR sys_getegid /* 4050 */ + PTR sys_getegid /* 5050 */ PTR sys_acct PTR sys_umount PTR sys_ni_syscall PTR sys_ioctl - PTR sys_fcntl /* 4055 */ + PTR sys_fcntl /* 5055 */ PTR sys_ni_syscall PTR sys_setpgid PTR sys_ni_syscall PTR sys_ni_syscall - PTR sys_umask /* 4060 */ + PTR sys_umask /* 5060 */ PTR sys_chroot PTR sys_ustat PTR sys_dup2 PTR sys_getppid - PTR sys_getpgrp /* 4065 */ + PTR sys_getpgrp /* 5065 */ PTR sys_setsid PTR sys_sigaction PTR sys_sgetmask PTR sys_ssetmask - PTR sys_setreuid /* 4070 */ + PTR sys_setreuid /* 5070 */ PTR sys_setregid PTR sys_sigsuspend PTR sys_sigpending PTR sys_sethostname - PTR sys_setrlimit /* 4075 */ + PTR sys_setrlimit /* 5075 */ PTR sys_getrlimit PTR sys_getrusage PTR sys_gettimeofday PTR sys_settimeofday - PTR sys_getgroups /* 4080 */ + PTR sys_getgroups /* 5080 */ PTR sys_setgroups PTR sys_ni_syscall /* old_select */ PTR sys_symlink PTR sys_lstat - PTR sys_readlink /* 4085 */ + PTR sys_readlink /* 5085 */ PTR sys_uselib PTR sys_swapon PTR sys_reboot PTR sys_ni_syscall /* old_readdir */ - PTR sys_mmap /* 4090 */ + PTR sys_mmap /* 5090 */ PTR sys_munmap PTR sys_truncate PTR sys_ftruncate PTR sys_fchmod - PTR sys_fchown /* 4095 */ + PTR sys_fchown /* 5095 */ PTR sys_getpriority PTR sys_setpriority PTR sys_ni_syscall PTR sys_statfs - PTR sys_fstatfs /* 4100 */ + PTR sys_fstatfs /* 5100 */ PTR sys_ni_syscall /* sys_ioperm */ PTR sys_socketcall PTR sys_syslog PTR sys_setitimer - PTR sys_getitimer /* 4105 */ + PTR sys_getitimer /* 5105 */ PTR sys_newstat PTR sys_newlstat PTR sys_newfstat PTR sys_ni_syscall - PTR sys_ni_syscall /* sys_ioperm *//* 4110 */ + PTR sys_ni_syscall /* sys_ioperm *//* 5110 */ PTR sys_vhangup PTR sys_ni_syscall /* was sys_idle */ PTR sys_ni_syscall /* sys_vm86 */ PTR sys_wait4 - PTR sys_swapoff /* 4115 */ + PTR sys_swapoff /* 5115 */ PTR sys_sysinfo PTR sys_ipc PTR sys_fsync PTR sys_sigreturn - PTR sys_clone /* 4120 */ + PTR sys_clone /* 5120 */ PTR sys_setdomainname PTR sys_newuname PTR sys_ni_syscall /* sys_modify_ldt */ PTR sys_adjtimex - PTR sys_mprotect /* 4125 */ + PTR sys_mprotect /* 5125 */ PTR sys_sigprocmask PTR sys_create_module PTR sys_init_module PTR sys_delete_module - PTR sys_get_kernel_syms /* 4130 */ + PTR sys_get_kernel_syms /* 5130 */ PTR sys_quotactl PTR sys_getpgid PTR sys_fchdir PTR sys_bdflush - PTR sys_sysfs /* 4135 */ + PTR sys_sysfs /* 5135 */ PTR sys_personality PTR sys_ni_syscall /* for afs_syscall */ PTR sys_setfsuid PTR sys_setfsgid - PTR sys_llseek /* 4140 */ + PTR sys_llseek /* 5140 */ PTR sys_getdents PTR sys_select PTR sys_flock PTR sys_msync - PTR sys_readv /* 4145 */ + PTR sys_readv /* 5145 */ PTR sys_writev PTR sys_cacheflush PTR sys_cachectl PTR sys_sysmips - PTR sys_ni_syscall /* 4150 */ + PTR sys_ni_syscall /* 5150 */ PTR sys_getsid PTR sys_fdatasync PTR sys_sysctl PTR sys_mlock - PTR sys_munlock /* 4155 */ + PTR sys_munlock /* 5155 */ PTR sys_mlockall PTR sys_munlockall PTR sys_sched_setparam PTR sys_sched_getparam - PTR sys_sched_setscheduler /* 4160 */ + PTR sys_sched_setscheduler /* 5160 */ PTR sys_sched_getscheduler PTR sys_sched_yield PTR sys_sched_get_priority_max PTR sys_sched_get_priority_min - PTR sys_sched_rr_get_interval /* 4165 */ + PTR sys_sched_rr_get_interval /* 5165 */ PTR sys_nanosleep PTR sys_mremap PTR sys_accept PTR sys_bind - PTR sys_connect /* 4170 */ + PTR sys_connect /* 5170 */ PTR sys_getpeername PTR sys_getsockname PTR sys_getsockopt PTR sys_listen - PTR sys_recv /* 4175 */ + PTR sys_recv /* 5175 */ PTR sys_recvfrom PTR sys_recvmsg PTR sys_send PTR sys_sendmsg - PTR sys_sendto /* 4180 */ + PTR sys_sendto /* 5180 */ PTR sys_setsockopt PTR sys_shutdown PTR sys_socket PTR sys_socketpair - PTR sys_setresuid /* 4185 */ + PTR sys_setresuid /* 5185 */ PTR sys_getresuid PTR sys_query_module PTR sys_poll PTR sys_nfsservctl - PTR sys_setresgid /* 4190 */ + PTR sys_setresgid /* 5190 */ PTR sys_getresgid PTR sys_prctl PTR sys_rt_sigreturn PTR sys_rt_sigaction - PTR sys_rt_sigprocmask /* 4195 */ + PTR sys_rt_sigprocmask /* 5195 */ PTR sys_rt_sigpending PTR sys_rt_sigtimedwait PTR sys_rt_sigqueueinfo PTR sys_rt_sigsuspend - PTR sys_pread /* 4200 */ + PTR sys_pread /* 5200 */ PTR sys_pwrite PTR sys_chown PTR sys_getcwd PTR sys_capget - PTR sys_capset /* 4205 */ + PTR sys_capset /* 5205 */ PTR sys_sigaltstack PTR sys_sendfile PTR sys_ni_syscall PTR sys_ni_syscall - PTR sys_pivot_root /* 4210 */ + PTR sys_pivot_root /* 5210 */ PTR sys_mincore PTR sys_madvise PTR sys_getdents64 diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/setup.c linux/arch/mips64/kernel/setup.c --- linux-orig/arch/mips64/kernel/setup.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/kernel/setup.c Wed May 23 23:39:56 2001 @@ -150,7 +154,7 @@ bootmem_init (); #endif - strncpy (command_line, arcs_cmdline, CL_SIZE); + strncpy(command_line, arcs_cmdline, CL_SIZE); memcpy(saved_command_line, command_line, CL_SIZE); saved_command_line[CL_SIZE-1] = '\0'; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/andes.c linux/arch/mips64/mm/andes.c --- linux-orig/arch/mips64/mm/andes.c Thu Nov 30 22:09:18 2000 +++ linux/arch/mips64/mm/andes.c Wed May 23 23:39:56 2001 @@ -284,8 +284,8 @@ if((pid != (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) & 0xff)) || (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) == 0)) { - printk("update_mmu_cache: Wheee, bogus tlbpid mmpid=%d - tlbpid=%d\n", (int) (CPU_CONTEXT(smp_processor_id(), + printk("update_mmu_cache: Wheee, bogus tlbpid mmpid=%d " + "tlbpid=%d\n", (int) (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) & 0xff), pid); } diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/init.c linux/arch/mips64/mm/init.c --- linux-orig/arch/mips64/mm/init.c Thu Apr 5 20:25:43 2001 +++ linux/arch/mips64/mm/init.c Wed May 23 23:39:56 2001 @@ -119,7 +119,7 @@ } /* - * We have upto 8 empty zeroed pages so we can map one of the right colour + * We have up to 8 empty zeroed pages so we can map one of the right colour * when needed. This is necessary only on R4000 / R4400 SC and MC versions * where we have to avoid VCED / VECI exceptions for good performance at * any price. Since page is never written to after the initialization we @@ -201,7 +201,7 @@ } } -void bootmem_init (void) { +void bootmem_init(void) { #ifdef CONFIG_BLK_DEV_INITRD unsigned long tmp; unsigned long *initrd_header; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/ip22-mc.c linux/arch/mips64/sgi-ip22/ip22-mc.c --- linux-orig/arch/mips64/sgi-ip22/ip22-mc.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/sgi-ip22/ip22-mc.c Wed May 23 23:39:56 2001 @@ -3,7 +3,7 @@ * License. See the file "COPYING" in the main directory of this archive * for more details. * - * indy_mc.c: Routines for manipulating the INDY memory controller. + * ip22-mc.c: Routines for manipulating the INDY memory controller. * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) * Copyright (C) 2001 Ralf Baechle (ralf@gnu.org) --- linux-orig/arch/mips64/sgi-ip22/ip22-sc.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/sgi-ip22/ip22-sc.c Fri May 25 19:14:41 2001 @@ -29,17 +29,17 @@ static inline void indy_sc_wipe(unsigned long first, unsigned long last) { - __asm__ __volatile__(" - .set noreorder - or %0, %4 # first line to flush - or %1, %4 # last line to flush -1: sw $0, 0(%0) - bne %0, %1, 1b - daddu %0, 32 - .set reorder" - : "=r" (first), "=r" (last) - : "0" (first), "1" (last), "r" (0x9000000080000000) - : "$1"); + __asm__ __volatile__( + ".set\tnoreorder\n\t" + "or\t%0, %4\t\t\t# first line to flush\n\t" + "or\t%1, %4\t\t\t# last line to flush\n" + "1:\tsw $0, 0(%0)\n\t" + "bne\t%0, %1, 1b\n\t" + "daddu\t%0, 32\n\t" + ".set reorder" + : "=r" (first), "=r" (last) + : "0" (first), "1" (last), "r" (0x9000000080000000) + : "$1"); } static void indy_sc_wback_invalidate(unsigned long addr, unsigned long size) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips/sgialib.h linux/include/asm-mips/sgialib.h --- linux-orig/include/asm-mips/sgialib.h Tue Mar 20 00:03:16 2001 +++ linux/include/asm-mips/sgialib.h Wed May 23 23:39:56 2001 @@ -64,9 +64,9 @@ */ extern void prom_identify_arch(void); -/* Environemt variable routines. */ +/* Environment variable routines. */ extern PCHAR ArcGetEnvironmentVariable(CHAR *name); -extern LONG SetEnvironmentVariable(PCHAR name, PCHAR value); +extern LONG ArcSetEnvironmentVariable(PCHAR name, PCHAR value); /* ARCS command line acquisition and parsing. */ extern char *prom_getcmdline(void); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/asm.h linux/include/asm-mips64/asm.h --- linux-orig/include/asm-mips64/asm.h Tue Jan 18 00:32:47 2000 +++ linux/include/asm-mips64/asm.h Wed May 23 23:39:56 2001 @@ -94,7 +94,7 @@ TEXT(msg) /* - * Print formated string + * Print formatted string */ #define PRINT(string) \ .set push; \ @@ -105,7 +105,7 @@ TEXT(string) /* - * Print formated string + * Print formatted string */ #define PROM_PRINT(string) \ .set push; \ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/bootinfo.h linux/include/asm-mips64/bootinfo.h --- linux-orig/include/asm-mips64/bootinfo.h Tue Mar 20 00:03:16 2001 +++ linux/include/asm-mips64/bootinfo.h Wed May 23 23:39:56 2001 @@ -88,7 +88,7 @@ /* * Valid machtype for group SGI */ -#define MACH_SGI_INDY 0 /* R4?K and R5K Indy workstaions */ +#define MACH_SGI_INDY 0 /* R4?K and R5K Indy workstations */ #define MACH_SGI_CHALLENGE_S 1 /* The Challenge S server */ #define MACH_SGI_INDIGO2 2 /* The Indigo2 system */ #define MACH_SGI_IP27 3 /* Origin 200, Origin 2000, Onyx 2 */ --- linux-orig/include/asm-mips/checksum.h Wed Mar 14 17:12:26 2001 +++ linux/include/asm-mips/checksum.h Fri May 25 18:30:32 2001 @@ -22,7 +22,7 @@ * * it's best to have buff aligned on a 32-bit boundary */ -unsigned int csum_partial(const unsigned char * buff, int len, unsigned int sum); +unsigned int csum_partial(const unsigned char *buff, int len, unsigned int sum); /* * this is a new version of the above that records errors it finds in *errp, @@ -41,9 +41,9 @@ * Copy and checksum to user */ #define HAVE_CSUM_COPY_USER -extern inline unsigned int -csum_and_copy_to_user (const char *src, char *dst, - int len, int sum, int *err_ptr) +extern inline unsigned int csum_and_copy_to_user (const char *src, char *dst, + int len, int sum, + int *err_ptr) { sum = csum_partial(src, len, sum); @@ -62,8 +62,9 @@ * this is obsolete and will go away. */ #define csum_partial_copy_fromuser csum_partial_copy -unsigned int csum_partial_copy(const char *src, char *dst, int len, unsigned int sum); - +unsigned int csum_partial_copy(const char *src, char *dst, int len, + unsigned int sum); + /* * Fold a partial checksum without adding pseudo headers */ @@ -92,7 +93,7 @@ * By Jorge Cwik , adapted for linux by * Arnt Gulbrandsen. */ -static inline unsigned short ip_fast_csum(unsigned char * iph, +static inline unsigned short ip_fast_csum(unsigned char *iph, unsigned int ihl) { unsigned int sum; @@ -169,7 +170,7 @@ #else "r" (((proto)<<16)+len), #endif - "r"(sum) + "r" (sum) : "$1"); return sum; @@ -185,7 +186,7 @@ unsigned short proto, unsigned int sum) { - return csum_fold(csum_tcpudp_nofold(saddr,daddr,len,proto,sum)); + return csum_fold(csum_tcpudp_nofold(saddr, daddr, len, proto, sum)); } /* @@ -256,7 +257,7 @@ ".set\tnoreorder" : "=r" (sum), "=r" (proto) : "r" (saddr), "r" (daddr), - "0" (htonl(len)), "1" (htonl(proto)), "r"(sum) + "0" (htonl(len)), "1" (htonl(proto)), "r" (sum) : "$1"); return csum_fold(sum); --- linux-orig/include/asm-mips64/checksum.h Tue Mar 7 16:45:42 2000 +++ linux/include/asm-mips64/checksum.h Fri May 25 18:32:35 2001 @@ -1,15 +1,17 @@ -/* $Id: checksum.h,v 1.6 2000/02/18 22:06:19 ralf Exp $ - * +/* * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive * for more details. * * Copyright (C) 1995, 1996, 1997, 1998, 1999 by Ralf Baechle * Copyright (C) 1999 Silicon Graphics, Inc. + * Copyright (C) 2001 Thiemo Seufer. */ #ifndef _ASM_CHECKSUM_H #define _ASM_CHECKSUM_H +#include + /* * computes the checksum of a memory block at buff, length len, * and adds in "sum" (32-bit) @@ -22,7 +24,7 @@ * * it's best to have buff aligned on a 32-bit boundary */ -unsigned int csum_partial(const unsigned char * buff, int len, unsigned int sum); +unsigned int csum_partial(const unsigned char *buff, int len, unsigned int sum); /* * this is a new version of the above that records errors it finds in *errp, @@ -41,9 +43,9 @@ * Copy and checksum to user */ #define HAVE_CSUM_COPY_USER -extern inline unsigned int -csum_and_copy_to_user (const char *src, char *dst, - int len, int sum, int *err_ptr) +extern inline unsigned int csum_and_copy_to_user (const char *src, char *dst, + int len, int sum, + int *err_ptr) { sum = csum_partial(src, len, sum); @@ -62,23 +64,23 @@ * this is obsolete and will go away. */ #define csum_partial_copy_fromuser csum_partial_copy -unsigned int csum_partial_copy(const char *src, char *dst, int len, unsigned int sum); - +unsigned int csum_partial_copy(const char *src, char *dst, int len, + unsigned int sum); + /* * Fold a partial checksum without adding pseudo headers */ -static inline unsigned short int -csum_fold(unsigned int sum) +static inline unsigned short int csum_fold(unsigned int sum) { - __asm__(" - .set noat - sll $1, %0, 16 - addu %0, $1 - sltu $1, %0, $1 - srl %0, %0, 16 - addu %0, $1 - xori %0, 0xffff - .set at" + __asm__( + ".set\tnoat\t\t\t# csum_fold\n\t" + "sll\t$1,%0,16\n\t" + "addu\t%0,$1\n\t" + "sltu\t$1,%0,$1\n\t" + "srl\t%0,%0,16\n\t" + "addu\t%0,$1\n\t" + "xori\t%0,0xffff\n\t" + ".set\tat" : "=r" (sum) : "0" (sum) : "$1"); @@ -93,8 +95,8 @@ * By Jorge Cwik , adapted for linux by * Arnt Gulbrandsen. */ -static inline unsigned short -ip_fast_csum(unsigned char * iph, unsigned int ihl) +static inline unsigned short ip_fast_csum(unsigned char *iph, + unsigned int ihl) { unsigned int sum; unsigned long dummy; @@ -103,36 +105,35 @@ * This is for 32-bit processors ... but works just fine for 64-bit * processors for now ... XXX */ - __asm__ __volatile__(" - .set noreorder - .set noat - lw %0, (%1) - subu %2, 4 - dsll %2, 2 - - lw %3, 4(%1) - daddu %2, %1 - addu %0, %3 - sltu $1, %0, %3 - lw %3, 8(%1) - addu %0, $1 - addu %0, %3 - sltu $1, %0, %3 - lw %3, 12(%1) - addu %0, $1 - addu %0, %3 - sltu $1, %0, %3 - addu %0, $1 - -1: lw %3, 16(%1) - daddiu %1, 4 - addu %0, %3 - sltu $1, %0, %3 - bne %2, %1, 1b - addu %0, $1 + __asm__ __volatile__( + ".set\tnoreorder\t\t\t# ip_fast_csum\n\t" + ".set\tnoat\n\t" + "lw\t%0, (%1)\n\t" + "subu\t%2, 4\n\t" + "dsll\t%2, 2\n\t" + "lw\t%3, 4(%1)\n\t" + "daddu\t%2, %1\n\t" + "addu\t%0, %3\n\t" + "sltu\t$1, %0, %3\n\t" + "lw\t%3, 8(%1)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %3\n\t" + "sltu\t$1, %0, %3\n\t" + "lw\t%3, 12(%1)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %3\n\t" + "sltu\t$1, %0, %3\n\t" + "addu\t%0, $1\n" + + "1:\tlw\t%3, 16(%1)\n\t" + "daddiu\t%1, 4\n" + "addu\t%0, %3\n\t" + "sltu\t$1, %0, %3\n\t" + "bne\t%2, %1, 1b\n\t" + " addu\t%0, $1\n" -2: .set at - .set reorder" + "2:\t.set\tat\n\t" + ".set\treorder" : "=&r" (sum), "=&r" (iph), "=&r" (ihl), "=&r" (dummy) : "1" (iph), "2" (ihl) : "$1"); @@ -144,26 +145,29 @@ * computes the checksum of the TCP/UDP pseudo-header * returns a 16-bit checksum, already complemented */ -static inline unsigned long -csum_tcpudp_nofold(unsigned long saddr, unsigned long daddr, - unsigned short len, unsigned short proto, unsigned int sum) -{ - __asm__(" - .set noat - daddu %0, %2 - daddu %0, %3 - daddu %0, %4 - dsll32 $1, %0, 0 - daddu %0, $1 # never results in an overflow - dsrl32 %0, %0, 0 - .set at" +static inline unsigned long csum_tcpudp_nofold(unsigned long saddr, + unsigned long daddr, + unsigned short len, + unsigned short proto, + unsigned int sum) +{ + __asm__( + ".set\tnoat\t\t\t# csum_tcpudp_nofold\n\t" + "daddu\t%0, %2\n\t" + "daddu\t%0, %3\n\t" + "daddu\t%0, %4\n\t" + "dsll32\t$1, %0, 0\n\t" + "daddu\t%0, $1\n\t" + "dsrl32\t%0, %0, 0\n\t" + ".set\tat" : "=r" (sum) - : "0" (sum), "r"(saddr), "r" (daddr), + : "r" (daddr), "r"(saddr), #ifdef __MIPSEL__ - "r" ((ntohs(len)<<16)+proto*256) + "r" ((ntohs(len)<<16)+proto*256), #else - "r" (((proto)<<16)+len) + "r" (((proto)<<16)+len), #endif + "r" (sum) : "$1"); return sum; @@ -173,82 +177,85 @@ * computes the checksum of the TCP/UDP pseudo-header * returns a 16-bit checksum, already complemented */ -static inline unsigned short int -csum_tcpudp_magic(unsigned long saddr, unsigned long daddr, unsigned short len, - unsigned short proto, unsigned int sum) +static inline unsigned short int csum_tcpudp_magic(unsigned long saddr, + unsigned long daddr, + unsigned short len, + unsigned short proto, + unsigned int sum) { - return csum_fold(csum_tcpudp_nofold(saddr,daddr,len,proto,sum)); + return csum_fold(csum_tcpudp_nofold(saddr, daddr, len, proto, sum)); } /* * this routine is used for miscellaneous IP-like checksums, mainly * in icmp.c */ -static inline unsigned short -ip_compute_csum(unsigned char * buff, int len) +static inline unsigned short ip_compute_csum(unsigned char * buff, int len) { return csum_fold(csum_partial(buff, len, 0)); } #define _HAVE_ARCH_IPV6_CSUM -static inline unsigned short int -csum_ipv6_magic(struct in6_addr *saddr, struct in6_addr *daddr, __u32 len, - unsigned short proto, unsigned int sum) -{ - __asm__(" - .set noreorder - .set noat - addu %0, %5 # proto (long in network byte order) - sltu $1, %0, %5 - addu %0, $1 - - addu %0, %6 # csum - sltu $1, %0, %6 - lw %1, 0(%2) # four words source address - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 4(%2) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 8(%2) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 12(%2) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 0(%3) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 4(%3) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 8(%3) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - - lw %1, 12(%3) - addu %0, $1 - addu %0, %1 - sltu $1, %0, $1 - .set noat - .set noreorder" - : "=r" (sum), "=r" (proto) - : "r" (saddr), "r" (daddr), - "0" (htonl(len)), "1" (htonl(proto)), "r"(sum) - : "$1"); +static inline unsigned short int csum_ipv6_magic(struct in6_addr *saddr, + struct in6_addr *daddr, + __u32 len, + unsigned short proto, + unsigned int sum) +{ + __asm__( + ".set\tnoreorder\t\t\t# csum_ipv6_magic\n\t" + ".set\tnoat\n\t" + "addu\t%0, %5\t\t\t# proto (long in network byte order)\n\t" + "sltu\t$1, %0, %5\n\t" + "addu\t%0, $1\n\t" + + "addu\t%0, %6\t\t\t# csum\n\t" + "sltu\t$1, %0, %6\n\t" + "lw\t%1, 0(%2)\t\t\t# four words source address\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %1\n\t" + "sltu\t$1, %0, $1\n\t" + + "lw\t%1, 4(%2)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %1\n\t" + "sltu\t$1, %0, $1\n\t" + + "lw\t%1, 8(%2)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %1\n\t" + "sltu\t$1, %0, $1\n\t" + + "lw\t%1, 12(%2)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %1\n\t" + "sltu\t$1, %0, $1\n\t" + + "lw\t%1, 0(%3)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %1\n\t" + "sltu\t$1, %0, $1\n\t" + + "lw\t%1, 4(%3)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %1\n\t" + "sltu\t$1, %0, $1\n\t" + + "lw\t%1, 8(%3)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %1\n\t" + "sltu\t$1, %0, $1\n\t" + + "lw\t%1, 12(%3)\n\t" + "addu\t%0, $1\n\t" + "addu\t%0, %1\n\t" + "sltu\t$1, %0, $1\n\t" + ".set\tnoat\n\t" + ".set\tnoreorder" + : "=r" (sum), "=r" (proto) + : "r" (saddr), "r" (daddr), + "0" (htonl(len)), "1" (htonl(proto)), "r" (sum) + : "$1"); return csum_fold(sum); } diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/cpu.h linux/include/asm-mips64/cpu.h --- linux-orig/include/asm-mips64/cpu.h Mon Mar 5 00:56:30 2001 +++ linux/include/asm-mips64/cpu.h Wed May 23 23:39:56 2001 @@ -22,14 +22,13 @@ #define PRID_IMP_R4000 0x0400 #define PRID_IMP_R6000A 0x0600 #define PRID_IMP_R10000 0x0900 -#define PRID_IMP_R12000 0x0e00 #define PRID_IMP_R4300 0x0b00 #define PRID_IMP_R12000 0x0e00 #define PRID_IMP_R8000 0x1000 #define PRID_IMP_R4600 0x2000 #define PRID_IMP_R4700 0x2100 #define PRID_IMP_R4640 0x2200 -#define PRID_IMP_R4650 0x2200 /* Same as R4640 */ +#define PRID_IMP_R4650 0x2200 /* Same as R4640 */ #define PRID_IMP_R5000 0x2300 #define PRID_IMP_SONIC 0x2400 #define PRID_IMP_MAGIC 0x2500 diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/mipsregs.h linux/include/asm-mips64/mipsregs.h --- linux-orig/include/asm-mips64/mipsregs.h Mon Oct 2 22:44:46 2000 +++ linux/include/asm-mips64/mipsregs.h Wed May 23 23:39:56 2001 @@ -246,7 +246,7 @@ #define CAUSEF_BD (1 << 31) /* - * Bits in the coprozessor 0 config register. + * Bits in the coprocessor 0 config register. */ #define CONF_CM_CACHABLE_NO_WA 0 #define CONF_CM_CACHABLE_WA 1 @@ -265,7 +265,7 @@ * R10000 performance counter definitions. * * FIXME: The R10000 performance counter opens a nice way to implement CPU - * time accounting with a precission of one cycle. I don't have + * time accounting with a precision of one cycle. I don't have * R10000 silicon but just a manual, so ... */ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgi/sgint23.h linux/include/asm-mips64/sgi/sgint23.h --- linux-orig/include/asm-mips64/sgi/sgint23.h Mon Nov 27 00:52:51 2000 +++ linux/include/asm-mips64/sgi/sgint23.h Wed May 23 23:39:56 2001 @@ -170,7 +170,7 @@ #endif #define INT2_TCLEAR_T0CLR 0x1 /* Clear timer0 IRQ */ #define INT2_TCLEAR_T1CLR 0x2 /* Clear timer1 IRQ */ -/* I am guesing there are only two unused registers here +/* I am guessing there are only two unused registers here * but I could be wrong... - andrewb */ /* u32 _unused[3]; */ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgialib.h linux/include/asm-mips64/sgialib.h --- linux-orig/include/asm-mips64/sgialib.h Tue Mar 20 00:03:16 2001 +++ linux/include/asm-mips64/sgialib.h Wed May 23 23:45:29 2001 @@ -90,9 +89,9 @@ */ extern void prom_identify_arch(void); -/* Environemt variable routines. */ +/* Environment variable routines. */ extern PCHAR ArcGetEnvironmentVariable(PCHAR name); -extern LONG SetEnvironmentVariable(PCHAR name, PCHAR value); +extern LONG ArcSetEnvironmentVariable(PCHAR name, PCHAR value); /* ARCS command line acquisition and parsing. */ extern char *prom_getcmdline(void); @@ -120,11 +119,11 @@ extern long prom_exec(char *name, long argc, char **argv, char **envp); /* Misc. routines. */ -extern void prom_halt(VOID) __attribute__((noreturn)); -extern void prom_powerdown(VOID) __attribute__((noreturn)); -extern void prom_restart(VOID) __attribute__((noreturn)); +extern VOID prom_halt(VOID) __attribute__((noreturn)); +extern VOID prom_powerdown(VOID) __attribute__((noreturn)); +extern VOID prom_restart(VOID) __attribute__((noreturn)); extern VOID ArcReboot(VOID) __attribute__((noreturn)); -extern VOID ArcEnterInteractiveMode(void) __attribute__((noreturn)); +extern VOID ArcEnterInteractiveMode(VOID) __attribute__((noreturn)); extern long prom_cfgsave(VOID); extern struct linux_sysid *prom_getsysid(VOID); extern VOID ArcFlushAllCaches(VOID); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgiarcs.h linux/include/asm-mips64/sgiarcs.h --- linux-orig/include/asm-mips64/sgiarcs.h Tue Jan 18 00:32:47 2000 +++ linux/include/asm-mips64/sgiarcs.h Wed May 23 23:45:29 2001 @@ -143,7 +143,7 @@ /* ARCS virtual dirents. */ struct linux_vdirent { - unsigned long namelen; + ULONG namelen; unsigned char attr; char fname[32]; /* XXX imperical, should be a define */ }; @@ -177,38 +177,38 @@ struct linux_bigint begin; struct linux_bigint end; struct linux_bigint cur; - enum linux_devtypes dtype; + enum linux_devtypes dtype; unsigned long namelen; unsigned char attr; char name[32]; /* XXX imperical, should be define */ }; -/* This describes the vector containing fuction pointers to the ARC +/* This describes the vector containing function pointers to the ARC firmware functions. */ struct linux_romvec { - LONG load; /* Load an executable image. */ - LONG invoke; /* Invoke a standalong image. */ - LONG exec; /* Load and begin execution of a + LONG load; /* Load an executable image. */ + LONG invoke; /* Invoke a standalong image. */ + LONG exec; /* Load and begin execution of a standalone image. */ - LONG halt; /* Halt the machine. */ - LONG pdown; /* Power down the machine. */ - LONG restart; /* XXX soft reset??? */ - LONG reboot; /* Reboot the machine. */ - LONG imode; /* Enter PROM interactive mode. */ - LONG _unused1; /* Was ReturnFromMain(). */ + LONG halt; /* Halt the machine. */ + LONG pdown; /* Power down the machine. */ + LONG restart; /* XXX soft reset??? */ + LONG reboot; /* Reboot the machine. */ + LONG imode; /* Enter PROM interactive mode. */ + LONG _unused1; /* Was ReturnFromMain(). */ /* PROM device tree interface. */ - LONG next_component; - LONG child_component; - LONG parent_component; - LONG component_data; - LONG child_add; - LONG comp_del; - LONG component_by_path; + LONG next_component; + LONG child_component; + LONG parent_component; + LONG component_data; + LONG child_add; + LONG comp_del; + LONG component_by_path; /* Misc. stuff. */ - LONG cfg_save; - LONG get_sysid; + LONG cfg_save; + LONG get_sysid; /* Probing for memory. */ LONG get_mdesc; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/system.h linux/include/asm-mips64/system.h --- linux-orig/include/asm-mips64/system.h Thu Oct 26 03:18:01 2000 +++ linux/include/asm-mips64/system.h Wed May 23 23:39:57 2001 @@ -33,7 +33,7 @@ } /* - * For cli() we have to insert nops to make shure that the new value + * For cli() we have to insert nops to make sure that the new value * has actually arrived in the status register before the end of this * macro. * R4000/R4400 need three nops, the R4600 two nops and the R10000 needs Binary files linux-orig/vmlinux.64 and linux/vmlinux.64 differ From owner-linux-mips@oss.sgi.com Fri May 25 11:11:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PIBW305955 for linux-mips-outgoing; Fri, 25 May 2001 11:11:32 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PIBSF05952 for ; Fri, 25 May 2001 11:11:29 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4PHxxJ02133; Fri, 25 May 2001 14:59:59 -0300 Date: Fri, 25 May 2001 14:59:59 -0300 From: Ralf Baechle To: George Gensure Cc: linux-mips Subject: Re: crti.o Message-ID: <20010525145959.C1196@bacchus.dhis.org> References: <3B0D990B.6090301@csh.rit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B0D990B.6090301@csh.rit.edu>; from werkt@csh.rit.edu on Thu, May 24, 2001 at 07:28:11PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 476 Lines: 11 On Thu, May 24, 2001 at 07:28:11PM -0400, George Gensure wrote: > Anyone know what the problem is when building the latest gcc when I get > a problem doing the final linking of the libgcc subdir? after listing a > whole bunch of object files, (not including crti.o) the linker errors > out, saying that it can't find crti.o. I've been muddling through this > for a while and just can't figure the problem out exactly... This file is part of the glibc package. Ralf From owner-linux-mips@oss.sgi.com Fri May 25 11:48:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PImwr07067 for linux-mips-outgoing; Fri, 25 May 2001 11:48:58 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PIZcF06589 for ; Fri, 25 May 2001 11:41:39 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA29592; Fri, 25 May 2001 19:19:35 +0200 (MET DST) Date: Fri, 25 May 2001 19:19:35 +0200 (MET DST) From: "Maciej W. Rozycki" To: Joe deBlaquiere cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B0D8F51.6000100@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1318 Lines: 34 On Thu, 24 May 2001, Joe deBlaquiere wrote: > and those pesky little inlined code snippets... > > #define PT_EI extern inline > > PT_EI long int > testandset (int *spinlock) > > which of course uses ll/sc if your world is built for _MIPS_ISA >= > _MIPS_ISA_MIPS2 The glibc's non-inlined _test_and_set() also uses ll/sc, if built for _MIPS_ISA >= _MIPS_ISA_MIPS2. We might remove the inline version of _test_and_set() for _MIPS_ISA == _MIPS_ISA_MIPS1 (I forgot about this one previously, sorry) from , but at a cost of an additional function call. I'm not sure if that's fine performance-wise at this moment... However, when I finish my implementation of a _test_and_set() syscall, it will be perfectly fine and even necessary to remove the inline wrapper for _MIPS_ISA == _MIPS_ISA_MIPS1 -- the only reason the wrapper is needed now is the incompatibility of the arguments of sysmips() and _test_and_set(). The good news is I already started the implementation -- hopefully it'll be ready over this weekend and the never-ending discussion about sysmips(MIPS_ATOMIC_SET) will be over. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri May 25 11:51:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PIpEk07390 for linux-mips-outgoing; Fri, 25 May 2001 11:51:14 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PITuF06450 for ; Fri, 25 May 2001 11:34:46 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA22390; Fri, 25 May 2001 15:13:04 +0200 (MET DST) Date: Fri, 25 May 2001 15:13:04 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <20010524164459.A19466@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1290 Lines: 48 On Thu, 24 May 2001, Daniel Jacobowitz wrote: > They aren't the same for MIPS, though. I exhibit as evidence the fact > that my patch fixed the problem I was seeing. I didn't know about 'R'; > I suppose that it is more correct. 'm' at least is closer than 'o', > though. The following program cannot be compiled with gcc 2.95.3, because the offset is out of range (I consider it a bug in gcc -- it should allocate and load a temporary register itself and pass it appropriately as %0, matching the "R" constraint; still it's better than generating bad code): int main(void) { int *p; asm volatile(".set push\n\t" ".set noat\n\t" "lw $0,%0\n\t" ".set pop" : : "R" (p[0x10000])); return 0; } After changing "R" to "m" or "o", bad assembly is generated if optimizing as follows: #APP .set push .set noat lw $0,262144($2) .set pop #NO_APP Note that it's an expected behaviour -- there are no non-offsettable address modes for MIPS. > If 'R' will behave correctly, could that be applied to CVS, then? I suppose so -- I'm not in a position to apply changes. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri May 25 13:09:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PK9xW10442 for linux-mips-outgoing; Fri, 25 May 2001 13:09:59 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PK9tF10436 for ; Fri, 25 May 2001 13:09:56 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4PJvfV06583; Fri, 25 May 2001 16:57:41 -0300 Date: Fri, 25 May 2001 16:57:41 -0300 From: Ralf Baechle To: Thiemo Seufer Cc: Keith M Wesolowski , linux-mips@oss.sgi.com Subject: Re: [PATCH] mips64 typo and formatting fixes Message-ID: <20010525165741.A6578@bacchus.dhis.org> References: <20010524011053.J11643@rembrandt.csv.ica.uni-stuttgart.de> <20010523213448.D10516@foobazco.org> <20010525191934.A5281@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010525191934.A5281@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Fri, May 25, 2001 at 07:19:34PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 337 Lines: 13 On Fri, May 25, 2001 at 07:19:34PM +0200, Thiemo Seufer wrote: > It can't, since it is 64bit. :-) > > >In the process of fixing the warnings in that file, ISTR > >Ralf found a bug. > > If the mentioned is the handling of 'sum' in csum_tcpudp_nofold, > it's now corrected. I also changed formatting to the usual one. Applied. Ralf From owner-linux-mips@oss.sgi.com Fri May 25 13:39:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PKdea11625 for linux-mips-outgoing; Fri, 25 May 2001 13:39:40 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PKdZF11617 for ; Fri, 25 May 2001 13:39:37 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4PKRk406697; Fri, 25 May 2001 17:27:46 -0300 Date: Fri, 25 May 2001 17:27:46 -0300 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Message-ID: <20010525172746.B6578@bacchus.dhis.org> References: <20010523145257.A13013@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, May 24, 2001 at 03:42:56PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 980 Lines: 19 On Thu, May 24, 2001 at 03:42:56PM +0200, Maciej W. Rozycki wrote: > > The ll/sc constructs in the kernel use ".set noat" to inhibit use of $at, > > and proceed to use it themselves. This is fine, except for one problem: the > > constraints on memory operands are "o" and "=o", which means offsettable > > memory references. If I'm not mistaken, the assembler will (always?) > > turn these into uses of $at if the offset is not 0 - at least, it certainly > > seems to do that here (gcc 2.95.3, binutils 2.10.91.0.2). Just being honest > > with the compiler and asking for a real memory reference does the trick. > > Both "m" and "o" seem to be incorrect here as both are the same for MIPS; > "R" seems to be appropriate, OTOH. Still gcc 2.95.3 doesn't handle "R" > fine for all cases, but it works most of the time and emits a warning > otherwise. I can't comment on 3.0. I admit the construction is somewhat fragile and will take any patches to cleanup this. Ralf From owner-linux-mips@oss.sgi.com Fri May 25 13:49:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PKnLF12187 for linux-mips-outgoing; Fri, 25 May 2001 13:49:21 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PKn8F12178; Fri, 25 May 2001 13:49:08 -0700 Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 153OWD-0006n3-00; Fri, 25 May 2001 13:49:09 -0700 Date: Fri, 25 May 2001 13:49:09 -0700 From: Daniel Jacobowitz To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Message-ID: <20010525134909.A26065@nevyn.them.org> References: <20010523145257.A13013@nevyn.them.org> <20010525172746.B6578@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="huq684BweRXVnRxX" Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20010525172746.B6578@bacchus.dhis.org>; from ralf@oss.sgi.com on Fri, May 25, 2001 at 05:27:46PM -0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2773 Lines: 74 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 25, 2001 at 05:27:46PM -0300, Ralf Baechle wrote: > On Thu, May 24, 2001 at 03:42:56PM +0200, Maciej W. Rozycki wrote: > > > > The ll/sc constructs in the kernel use ".set noat" to inhibit use of $at, > > > and proceed to use it themselves. This is fine, except for one problem: the > > > constraints on memory operands are "o" and "=o", which means offsettable > > > memory references. If I'm not mistaken, the assembler will (always?) > > > turn these into uses of $at if the offset is not 0 - at least, it certainly > > > seems to do that here (gcc 2.95.3, binutils 2.10.91.0.2). Just being honest > > > with the compiler and asking for a real memory reference does the trick. > > > > Both "m" and "o" seem to be incorrect here as both are the same for MIPS; > > "R" seems to be appropriate, OTOH. Still gcc 2.95.3 doesn't handle "R" > > fine for all cases, but it works most of the time and emits a warning > > otherwise. I can't comment on 3.0. > > I admit the construction is somewhat fragile and will take any patches to > cleanup this. How about the attached, then? If the p[0x100000] case is of sufficient concern, we can work around that too, but this catches all current uses. -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mips-offset2.diff" Index: arch/mips/kernel/sysmips.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v retrieving revision 1.18 diff -u -r1.18 sysmips.c --- arch/mips/kernel/sysmips.c 2001/04/08 13:24:27 1.18 +++ arch/mips/kernel/sysmips.c 2001/05/23 21:49:29 @@ -99,8 +99,8 @@ ".word\t1b, 3b\n\t" ".word\t2b, 3b\n\t" ".previous\n\t" - : "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno) - : "r" (arg2), "o" (* (u32 *) p), "2" (errno) + : "=&r" (tmp), "=R" (* (u32 *) p), "=r" (errno) + : "r" (arg2), "R" (* (u32 *) p), "2" (errno) : "$1"); if (errno) Index: include/asm-mips/system.h =================================================================== RCS file: /cvs/linux/include/asm-mips/system.h,v retrieving revision 1.27 diff -u -r1.27 system.h --- include/asm-mips/system.h 2001/03/28 01:35:12 1.27 +++ include/asm-mips/system.h 2001/05/23 21:49:29 @@ -219,8 +219,8 @@ " ll\t%0, %3\n\t" ".set\tat\n\t" ".set\treorder" - : "=r" (val), "=o" (*m), "=r" (dummy) - : "o" (*m), "2" (val) + : "=r" (val), "=R" (*m), "=r" (dummy) + : "R" (*m), "2" (val) : "memory"); return val; --huq684BweRXVnRxX-- From owner-linux-mips@oss.sgi.com Fri May 25 14:11:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PLBfT13128 for linux-mips-outgoing; Fri, 25 May 2001 14:11:41 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PLBeF13125 for ; Fri, 25 May 2001 14:11:40 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA04224; Fri, 25 May 2001 14:11:33 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA17250; Fri, 25 May 2001 14:11:30 -0700 (PDT) Message-ID: <011801c0e55f$e4d39820$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" , "Daniel Jacobowitz" Cc: References: Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Date: Fri, 25 May 2001 23:15:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 546 Lines: 24 > The following program cannot be compiled with gcc 2.95.3, because the > offset is out of range (I consider it a bug in gcc -- it should allocate > and load a temporary register itself and pass it appropriately as %0, I think gcc can be forgiven for not allocating a temporary, given the ".set noat"... > matching the "R" constraint; still it's better than generating bad code): > > int main(void) > { > int *p; > > asm volatile(".set push\n\t" > ".set noat\n\t" > "lw $0,%0\n\t" > ".set pop" > : > : "R" (p[0x10000])); > > return 0; > } From owner-linux-mips@oss.sgi.com Fri May 25 14:49:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PLnjN14331 for linux-mips-outgoing; Fri, 25 May 2001 14:49:45 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PLniF14328 for ; Fri, 25 May 2001 14:49:44 -0700 Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 153PSj-0007No-00; Fri, 25 May 2001 14:49:37 -0700 Date: Fri, 25 May 2001 14:49:37 -0700 From: Daniel Jacobowitz To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Message-ID: <20010525144937.A28370@nevyn.them.org> References: <011801c0e55f$e4d39820$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <011801c0e55f$e4d39820$0deca8c0@Ulysses>; from kevink@mips.com on Fri, May 25, 2001 at 11:15:48PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 928 Lines: 34 On Fri, May 25, 2001 at 11:15:48PM +0200, Kevin D. Kissell wrote: > > The following program cannot be compiled with gcc 2.95.3, because the > > offset is out of range (I consider it a bug in gcc -- it should allocate > > and load a temporary register itself and pass it appropriately as %0, > > I think gcc can be forgiven for not allocating a temporary, > given the ".set noat"... Except, of course, gcc doesn't even know the set noat is there. It doesn't parse the interior of asm() statements. > > > matching the "R" constraint; still it's better than generating bad code): > > > > int main(void) > > { > > int *p; > > > > asm volatile(".set push\n\t" > > ".set noat\n\t" > > "lw $0,%0\n\t" > > ".set pop" > > : > > : "R" (p[0x10000])); > > > > return 0; > > } > > > -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team From owner-linux-mips@oss.sgi.com Fri May 25 15:20:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PMKU315410 for linux-mips-outgoing; Fri, 25 May 2001 15:20:30 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PMKSF15404 for ; Fri, 25 May 2001 15:20:28 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4PM3F023115; Fri, 25 May 2001 15:03:15 -0700 Message-ID: <3B0ED686.C1D85CE1@mvista.com> Date: Fri, 25 May 2001 15:02:46 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joe deBlaquiere CC: "Maciej W. Rozycki" , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B0D8F51.6000100@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2938 Lines: 75 Alright, I rolled my sleeve and digged into IRIX 6.5, and guess what? sysmips() does NOT have MIPS_ATOMIC_SET (2001) on IRIX! See the header below. So apparently MIPS_ATOMIC_SET was invented for Linux only, probably just to implement _test_and_set(). (It would be interesting to see how IRIX implement _test_and_set() on MIPS I machines. However, the machine I have access uses ll/sc instructions). Given the above understanding, I think we are free to add a new sysmips subcall or even just change the current one if we want to. Through the discussions, I hope we have achived the following concensus: 1. We need a correct syscall support to implement _test_and_set() on MIPS I machine. ll/sc emulation is not considered good enough to eliminate this need due to performance concerns. People who take this route understand that they may have to create extra user land configurations. 2. Nobody seems to object the idea of ll/sc emulation per se, althought it is not currently fully implemented based on my understanding. People who prefer this route will enjoy the same ll/sc-enabled userland but presumably take a performance hit on machines without ll/sc. Anybody still have objections to the above conclusions? ------------- Now back to the fix for syscall: the cvs tree is buggy as it is, as pointed out by Florian. I see several possibilities, which more or less the same as I brought up at the beginning: 1) Florian's fix - introduce a new assembly routine to intercept MIPS_ATOMIC_SET call so that correct return value is returned when there is no error and error value is returned when there is an error. 1.a) A slight modification to 1) - we send a seg fault when there is access error. This solves two problems in 1). With 1), _test_and_set() will not be able to distinguish whether an error has happened or a negative value is returned. So in effect, error is mistakenly ignored. The second benenfit is that with seg fault MIPS I implementation will have the same behavior as MIPS II implementation which uses ll/sc. 2) Add a new subcall to sysmips, MIPS_NEW_ATOMIC_SET. It takes three arguments with the third one being the address to hold return value. Again, I think we should send seg fault on access errors. The advantage of 2) is that we can still use the same sysmips() call without introducing any new files. The disadvantage is that people who use MIPS_ATOMIC_SET directly is still subject to error, either in one form or another. To me, either 1.a) or 2) is fine with me, although I have a slight faovr over 2) (perhaps because I don't like assembly code and the extra "vertical" calling layer introduced in 1.a) -------------- So, please do us all a favor, can everybody who cares let us know : 1) can we agree on the concensus? 2) which fix do you like (naturally assuming you agree with the concensus)? Let us work together and put a closure on this recurring matter! Jun From owner-linux-mips@oss.sgi.com Fri May 25 16:59:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4PNxV818238 for linux-mips-outgoing; Fri, 25 May 2001 16:59:31 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PNxVF18235 for ; Fri, 25 May 2001 16:59:31 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4PNun028732; Fri, 25 May 2001 16:56:49 -0700 Message-ID: <3B0EF123.B1C6D480@mvista.com> Date: Fri, 25 May 2001 16:56:19 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joe deBlaquiere , "Maciej W. Rozycki" , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B0D8F51.6000100@redhat.com> <3B0ED686.C1D85CE1@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 960 Lines: 26 Oops! I guess I forgot to include the sysmips.h header file from IRIX. Jun /* Copyright (c) 1984 AT&T */ /* All Rights Reserved */ /* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T */ /* The copyright notice above does not evidence any */ /* actual or intended publication of such source code. */ #ident "$Revision: 3.12 $" /* * Sysmips() system call commands. */ #define SETNAME 1 /* rename the system */ #define STIME 2 /* set time */ #define FLUSH_CACHE 3 /* flush caches */ #define MIPS_FPSIGINTR 5 /* generate a SIGFPE on every fp interrupt */ #define MIPS_FPU 6 /* turn on/off the fpu */ #define MIPS_FIXADE 7 /* fix address error (unaligned) */ #define POSTWAIT 8 /* post wait driver for Oracle */ #define PPHYSIO 9 /* parallel IO */ #define PPHYSIO64 10 /* parallel IO - big offsets */ From owner-linux-mips@oss.sgi.com Sat May 26 15:10:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4QMAcV15144 for linux-mips-outgoing; Sat, 26 May 2001 15:10:38 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QMAbd15141 for ; Sat, 26 May 2001 15:10:37 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id PAA09139; Sat, 26 May 2001 15:10:30 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA15156; Sat, 26 May 2001 15:10:25 -0700 (PDT) Message-ID: <00c901c0e631$4bcebd80$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" Cc: References: <011801c0e55f$e4d39820$0deca8c0@Ulysses> <20010525144937.A28370@nevyn.them.org> Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Date: Sun, 27 May 2001 00:14:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1087 Lines: 26 > On Fri, May 25, 2001 at 11:15:48PM +0200, Kevin D. Kissell wrote: > > > The following program cannot be compiled with gcc 2.95.3, because the > > > offset is out of range (I consider it a bug in gcc -- it should allocate > > > and load a temporary register itself and pass it appropriately as %0, > > > > I think gcc can be forgiven for not allocating a temporary, > > given the ".set noat"... > > Except, of course, gcc doesn't even know the set noat is there. It > doesn't parse the interior of asm() statements. Fair enough. It was an offhand remark. But seriously, what does the "R" constraint mean here? The only documentation I've got (http://linux.fh-heilbronn.de/doku/GNU/docs/gcc/gcc_163.html#SEC163) says that "Q" through "U" are reserved for use with EXTRA_CONSTRAINT in machine-dependent definitions of arbitrary operand types. When and where does it get bound for MIPS gcc, and what is it supposed to mean? If I compile this kind of fragment using a "m" constraint, it seems to do the right thing, at least on my archaic native compiler. Kevin K. From owner-linux-mips@oss.sgi.com Sat May 26 15:35:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4QMZKh15543 for linux-mips-outgoing; Sat, 26 May 2001 15:35:20 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4QMZId15540 for ; Sat, 26 May 2001 15:35:18 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4QMNeD01589; Sat, 26 May 2001 19:23:40 -0300 Date: Sat, 26 May 2001 19:23:40 -0300 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Message-ID: <20010526192340.B1415@bacchus.dhis.org> References: <011801c0e55f$e4d39820$0deca8c0@Ulysses> <20010525144937.A28370@nevyn.them.org> <00c901c0e631$4bcebd80$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00c901c0e631$4bcebd80$0deca8c0@Ulysses>; from kevink@mips.com on Sun, May 27, 2001 at 12:14:43AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1019 Lines: 19 On Sun, May 27, 2001 at 12:14:43AM +0200, Kevin D. Kissell wrote: > Fair enough. It was an offhand remark. But seriously, what does > the "R" constraint mean here? The only documentation I've got > (http://linux.fh-heilbronn.de/doku/GNU/docs/gcc/gcc_163.html#SEC163) > says that "Q" through "U" are reserved for use with EXTRA_CONSTRAINT > in machine-dependent definitions of arbitrary operand types. When > and where does it get bound for MIPS gcc, and what is it supposed > to mean? If I compile this kind of fragment using a "m" constraint, > it seems to do the right thing, at least on my archaic native compiler. Correct, "R" is a machine dependent constraint. At least when it's working right it's supposed to expand into offset(reg) where offset is limited to 16 bits. That's implemented in gcc/config/gcc/mips/mips.h's EXTRA_CONSTRAINT macro. In case of an "R" constraint gcc calls the simple_memory_operand() function which will return 1 if the memory operand fits into a single instruction. Ralf From owner-linux-mips@oss.sgi.com Sat May 26 20:05:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4R359x21185 for linux-mips-outgoing; Sat, 26 May 2001 20:05:09 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R34vd21147; Sat, 26 May 2001 20:04:58 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 587177F6; Sat, 26 May 2001 15:56:51 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 00718EFDB; Sat, 26 May 2001 15:15:50 +0200 (CEST) Date: Sat, 26 May 2001 15:15:50 +0200 From: Florian Lohoff To: Joe deBlaquiere Cc: Jun Sun , "Maciej W. Rozycki" , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com, "Kevin D. Kissell" Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Message-ID: <20010526151550.B611@paradigm.rfc822.org> References: <3B0BF7F8.3050306@redhat.com> <3B0C0475.B9ACE682@mvista.com> <20010523205412.A10981@paradigm.rfc822.org> <20010523205552.B10981@paradigm.rfc822.org> <3B0C17D9.3060600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3B0C17D9.3060600@redhat.com>; from jadb@redhat.com on Wed, May 23, 2001 at 03:04:41PM -0500 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1198 Lines: 25 On Wed, May 23, 2001 at 03:04:41PM -0500, Joe deBlaquiere wrote: > The thing I don't understand is how glibc is going to cleanly decide at > runtime which code to use. It's relatively easy to do something like > that in the kernel, but I can't come up with an elegant solution to make > such a choice at runtime in glibc. Export the existance of ll/sc via /proc/cpuinfo or whatever. > Assuming that we're moving forward (as Kevin points out) the percentage > of systems without ll/sc is going down. While these systems don't have > much CPU power to spare, we should make the baseline implementation have > ll/sc emulation. If somebody wants to make a MIPS I optimized glibc, > then that's fine, but allowing the 'standard' MIPSII glibc to work on > all systems simplifies life ( mine at least ;) ). I dont think this is true necessarly - There are still people building embedded x86 systems based on 386 cores. Look at the vr41xx systems - They do also lack the ll/sc afaik. This is nowadays the most commonly used embedded/pda cpu. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Sat May 26 20:05:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4R351v21155 for linux-mips-outgoing; Sat, 26 May 2001 20:05:01 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R34vd21148; Sat, 26 May 2001 20:04:58 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 3F70D7F4; Sat, 26 May 2001 15:56:51 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id CFD74EFD9; Sat, 26 May 2001 15:14:28 +0200 (CEST) Date: Sat, 26 May 2001 15:14:28 +0200 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: Joe deBlaquiere , Jun Sun , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com, "Kevin D. Kissell" Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Message-ID: <20010526151427.A611@paradigm.rfc822.org> References: <3B0C17D9.3060600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, May 24, 2001 at 11:32:29AM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1126 Lines: 25 On Thu, May 24, 2001 at 11:32:29AM +0200, Maciej W. Rozycki wrote: > On Wed, 23 May 2001, Joe deBlaquiere wrote: > > > ll/sc emulation. If somebody wants to make a MIPS I optimized glibc, > > then that's fine, but allowing the 'standard' MIPSII glibc to work on > > all systems simplifies life ( mine at least ;) ). > > I have no objections against providing an ll/sc emulation -- I have never > had and certainly haven't expressed them. What I insist on is to keep > ISA-I-compiled glibc not making use of ll/sc. Anyone feel free to finish > the emulation we have. > > Anyway, an ISA-II-compiled glibc won't work on an ISA I system even if > the ll/sc emulation works. An ISA II is more than just an addition of the > ll and sc instructions. There were also branch likely, trap and > doubleword coprocessor load instructions added in ISA II. Do you want to > emulate these, too? Isnt this the reason why Linux/Mips userspace is compiles with ISA I + ll/sc ? Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Mon May 28 06:44:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SDi1622827 for linux-mips-outgoing; Mon, 28 May 2001 06:44:01 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SDi0d22823 for ; Mon, 28 May 2001 06:44:00 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA16523; Mon, 28 May 2001 06:43:53 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA26301; Mon, 28 May 2001 06:43:51 -0700 (PDT) Message-ID: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: "Daniel Jacobowitz" , References: Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Date: Mon, 28 May 2001 15:48:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2084 Lines: 45 > > says that "Q" through "U" are reserved for use with EXTRA_CONSTRAINT > > in machine-dependent definitions of arbitrary operand types. When > > and where does it get bound for MIPS gcc, and what is it supposed > > to mean? If I compile this kind of fragment using a "m" constraint, > > it seems to do the right thing, at least on my archaic native compiler. > > Is it gcc generating right code or gas expanding a macro? Try `gcc -S' > -- for me "m" generates "lw $0,262144($2)", which is unacceptable when > ".set noat" is in effect (and perfectly fine otherwise). I'd been disassembling the resulting .o files, as I didn't care whether it's the compiler or the assembler that ultimately makes things right. Repeating your experiment using -S gives the following results: egcs-2.90.29 (native) and egcs-2.91.66 (x86 cross) : Optimiser produces "impossible" load offset you describe if "m" or "o" constraint, compiler barfs if "R" constraint. gcc 2.96-mips3264-000710 from Algorithmics (x86 cross): Compiler generates "correct" code (Address is calculated with an explicit add prior to the asm expansion) for any of the three constraints. However, if one compiles all the way to object code and looks at what the assembler is actually doing with those "impossible" offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat" in the "m" and "o" constraint cases. It is *not* using the "at" register. It is, however, cleverly using the load destination register as a temporary to calculate the correct address. As there are no memory operations, these instructions should have no effect on the correct execution of the ll/sc sequence (though they will increase the statistical probability of a context switch between ll and sc). Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon May 28 07:03:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SE3qn23434 for linux-mips-outgoing; Mon, 28 May 2001 07:03:52 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SE3Kd23421 for ; Mon, 28 May 2001 07:03:22 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA18358; Mon, 28 May 2001 13:20:41 +0200 (MET DST) Date: Mon, 28 May 2001 13:20:41 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <00c901c0e631$4bcebd80$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1066 Lines: 23 On Sun, 27 May 2001, Kevin D. Kissell wrote: > Fair enough. It was an offhand remark. But seriously, what does > the "R" constraint mean here? The only documentation I've got > (http://linux.fh-heilbronn.de/doku/GNU/docs/gcc/gcc_163.html#SEC163) `info gcc' has most relevant data, at least for 2.95.3. > says that "Q" through "U" are reserved for use with EXTRA_CONSTRAINT > in machine-dependent definitions of arbitrary operand types. When > and where does it get bound for MIPS gcc, and what is it supposed > to mean? If I compile this kind of fragment using a "m" constraint, > it seems to do the right thing, at least on my archaic native compiler. Is it gcc generating right code or gas expanding a macro? Try `gcc -S' -- for me "m" generates "lw $0,262144($2)", which is unacceptable when ".set noat" is in effect (and perfectly fine otherwise). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 07:07:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SE7vt23974 for linux-mips-outgoing; Mon, 28 May 2001 07:07:57 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SE6Rd23696; Mon, 28 May 2001 07:06:58 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA18070; Mon, 28 May 2001 13:09:50 +0200 (MET DST) Date: Mon, 28 May 2001 13:09:49 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <20010525134909.A26065@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 581 Lines: 15 On Fri, 25 May 2001, Daniel Jacobowitz wrote: > How about the attached, then? If the p[0x100000] case is of sufficient > concern, we can work around that too, but this catches all current > uses. Fine for me. Don't worry of the gcc bug -- such large offests are rare and I doubt anyone will get hurt. Hopefully gcc will get fixed meanwhile, either by me or by someone else. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 07:28:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SESxu25258 for linux-mips-outgoing; Mon, 28 May 2001 07:28:59 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SEM1d25101 for ; Mon, 28 May 2001 07:23:20 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA18358; Mon, 28 May 2001 13:20:41 +0200 (MET DST) Date: Mon, 28 May 2001 13:20:41 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <00c901c0e631$4bcebd80$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1066 Lines: 23 On Sun, 27 May 2001, Kevin D. Kissell wrote: > Fair enough. It was an offhand remark. But seriously, what does > the "R" constraint mean here? The only documentation I've got > (http://linux.fh-heilbronn.de/doku/GNU/docs/gcc/gcc_163.html#SEC163) `info gcc' has most relevant data, at least for 2.95.3. > says that "Q" through "U" are reserved for use with EXTRA_CONSTRAINT > in machine-dependent definitions of arbitrary operand types. When > and where does it get bound for MIPS gcc, and what is it supposed > to mean? If I compile this kind of fragment using a "m" constraint, > it seems to do the right thing, at least on my archaic native compiler. Is it gcc generating right code or gas expanding a macro? Try `gcc -S' -- for me "m" generates "lw $0,262144($2)", which is unacceptable when ".set noat" is in effect (and perfectly fine otherwise). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 09:21:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SGLJQ30012 for linux-mips-outgoing; Mon, 28 May 2001 09:21:19 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SGLId30009 for ; Mon, 28 May 2001 09:21:18 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA17192; Mon, 28 May 2001 09:21:12 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA29013; Mon, 28 May 2001 09:21:09 -0700 (PDT) Message-ID: <00d001c0e792$d48b14e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: References: Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Date: Mon, 28 May 2001 18:25:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 761 Lines: 22 > > Export the existance of ll/sc via /proc/cpuinfo or whatever. > > That's a valid approach and also nothing new to glibc -- see Alpha and > in()/out() support. But do we want an extra overhead due to an indirect > call? Especially as _test_and_set() gets usually inlined? Use a global variable testable by the inline code? > > I dont think this is true necessarly - There are still people building > > embedded x86 systems based on 386 cores. Look at the vr41xx systems - They > > do also lack the ll/sc afaik. This is nowadays the most commonly > > used embedded/pda cpu. > > Are vr41xx plain ISA I or crippled ISA II+ CPUs? Actually, they are crippled MIPS III+ 64-bit CPUs (with added stuff like16x16 bit MAC instructions!). Kevin K. From owner-linux-mips@oss.sgi.com Mon May 28 10:55:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SHtav31896 for linux-mips-outgoing; Mon, 28 May 2001 10:55:36 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SHtPd31883 for ; Mon, 28 May 2001 10:55:26 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA29654; Mon, 28 May 2001 19:10:56 +0200 (MET DST) Date: Mon, 28 May 2001 19:10:55 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <00d001c0e792$d48b14e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 603 Lines: 18 On Mon, 28 May 2001, Kevin D. Kissell wrote: > Use a global variable testable by the inline code? With both variants inlined? Now that's really ugly. > > Are vr41xx plain ISA I or crippled ISA II+ CPUs? > > Actually, they are crippled MIPS III+ 64-bit CPUs Then an ll/sc and lld/scd emulation seems to be most appropriate here. I don't think we want to add _test_and_set() to mips64*-linux. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 11:05:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SI5Q332333 for linux-mips-outgoing; Mon, 28 May 2001 11:05:26 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SHv5d32057 for ; Mon, 28 May 2001 10:57:31 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA26147; Mon, 28 May 2001 17:21:59 +0200 (MET DST) Date: Mon, 28 May 2001 17:21:59 +0200 (MET DST) From: "Maciej W. Rozycki" To: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle Subject: [patch] RFC: A sys__test_and_set() implementation Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5215 Lines: 183 Hi, Following is a sys__test_and_set() syscall implementation that should suite well the _test_and_set() library call as defined by the MIPS ABI. I didn't have enough time to implement a glibc wrapper, yet, but I have written a test program that is much similar to how the wrapper will look like. The syscall uses a slightly modified calling convention which allows it to avoid errno mangling code and always return consistent results. The call never returns an error -- there is no reason to. If an illegal access is detected, a SIGBUS or a SIGSEGV is sent appropriately, depending on the kind of the violation. This mimics the ll/sc behaviour in these circumstances and makes the kernel vs library implementation more consistent. Here is the test program: #include #include #ifndef __NR__test_and_set #define __NR__test_and_set (__NR_Linux + 221) #endif static inline int _test_and_set(int *p, int v) { int r; asm volatile( "la $4,%1\n\t" "move $5,%2\n\t" "li $2,%3\n\t" "syscall\n\t" "move %0,$3" : "=r" (r) : "m" (*p), "r" (v), "i" (__NR__test_and_set) : "$2", "$3", "$4", "$5", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", "memory"); return r; } int main(void) { volatile int v = 1; int v0, v1, r; v0 = v; r = _test_and_set((int *)&v, -1); v1 = v; printf("v0: %i, v1: %i, r: %i\n", v0, v1, r); return 0; } Following it the patch. It was built and tested using a linux 2.4.0-test12 CVS snapshot from oss. It applies to a current snapshot of 2.4.3, but it wasn't run-time tested in this configuration. Given it's self-contained, I hope it works for 2.4.3 as well. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.0-test12-20010110-tas-11 diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscall.c linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscall.c --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscall.c Sun Oct 29 05:26:54 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscall.c Sun May 27 22:56:21 2001 @@ -174,6 +174,82 @@ asmlinkage int sys_olduname(struct oldol return error; } +/* Note: errno is always zero and the result is in v1. */ +asmlinkage int sys__test_and_set(struct pt_regs regs) +{ + int *ptr, val, ret, err, tmp; + + ptr = (int *)(regs.regs[4]); + val = (int)(regs.regs[5]); + + /* Don't emulate unaligned accesses. */ + if ((int)ptr & 3) + goto fault; + +#ifdef CONFIG_CPU_HAS_LLSC + __asm__(".set mips2\n\t" + "1:\n\t" + "ll %0,%5\n\t" + "move %3,%4\n" + "2:\n\t" + "sc %3,%1\n\t" + "beqz %3,1b\n\t" + "3:\n\t" + ".set mips0\n\t" + ".section .fixup,\"ax\"\n" + "4:\n\t" + "li %2,%7\n\t" + "j 3b\n\t" + ".previous\n\t" + ".section __ex_table,\"a\"\n\t" + ".word 1b,4b\n\t" + ".word 2b,4b\n\t" + ".previous" + : "=&r" (ret), "=R" (*ptr), "=r" (err), "=&r" (tmp) + : "r" (val), "1" (*ptr), "2" (0), "i" (-EFAULT)); +#else + /* A zero here saves us three instructions. */ + err = verify_area(VERIFY_WRITE, ptr, 0); + + save_and_cli(tmp); + err |= __get_user(ret, ptr); + err |= __put_user(val, ptr); /* No fault unless unwriteable. */ + restore_flags(tmp); +#endif + + if (err) + goto fault; + + (int)(regs.regs[3]) = ret; + + return 0; + +fault: + regs.cp0_epc -= 4; /* Go back to SYSCALL. */ + + { + struct siginfo info; + + + if ((int)ptr & 3) { + info.si_signo = SIGBUS; + info.si_code = BUS_ADRALN; + } else { + info.si_signo = SIGSEGV; + if (verify_area(VERIFY_WRITE, ptr, 0)) + info.si_code = SEGV_ACCERR; + else + info.si_code = SEGV_MAPERR; + } + info.si_errno = 0; + info.si_addr = (void *)regs.cp0_epc; + + force_sig_info(info.si_signo, &info, current); + } + + return 0; +} + /* * Do the indirect syscall syscall. * Don't care about kernel locking; the actual syscall will do it. diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscalls.h linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscalls.h --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscalls.h Wed Nov 8 05:26:57 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscalls.h Wed May 23 23:59:02 2001 @@ -235,3 +235,4 @@ SYS(sys_mincore, 3) SYS(sys_madvise, 3) SYS(sys_getdents64, 3) SYS(sys_fcntl64, 3) /* 4220 */ +SYS(sys__test_and_set, 0) diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/unistd.h linux-mips-2.4.0-test12-20010110/include/asm-mips/unistd.h --- linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/unistd.h Thu Oct 26 04:27:09 2000 +++ linux-mips-2.4.0-test12-20010110/include/asm-mips/unistd.h Wed May 23 23:09:00 2001 @@ -233,11 +233,12 @@ #define __NR_madvise (__NR_Linux + 218) #define __NR_getdents64 (__NR_Linux + 219) #define __NR_fcntl64 (__NR_Linux + 220) +#define __NR__test_and_set (__NR_Linux + 221) /* * Offset of the last Linux flavoured syscall */ -#define __NR_Linux_syscalls 220 +#define __NR_Linux_syscalls 221 #ifndef _LANGUAGE_ASSEMBLY From owner-linux-mips@oss.sgi.com Mon May 28 11:07:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SI7KC32547 for linux-mips-outgoing; Mon, 28 May 2001 11:07:20 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SI6sd32513 for ; Mon, 28 May 2001 11:06:55 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA26502; Mon, 28 May 2001 17:34:27 +0200 (MET DST) Date: Mon, 28 May 2001 17:34:26 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun , Ralf Baechle cc: Joe deBlaquiere , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B0ED686.C1D85CE1@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1293 Lines: 31 On Fri, 25 May 2001, Jun Sun wrote: > Alright, I rolled my sleeve and digged into IRIX 6.5, and guess what? > sysmips() does NOT have MIPS_ATOMIC_SET (2001) on IRIX! See the header below. I remember Ralf writing of this being a compatibility call with RISC/OS (is it the original OS of MIPS, Inc.?), IIRC. Ralf: am I right? > So apparently MIPS_ATOMIC_SET was invented for Linux only, probably just to > implement _test_and_set(). (It would be interesting to see how IRIX implement > _test_and_set() on MIPS I machines. However, the machine I have access uses > ll/sc instructions). Does IRIX actually run on anything below ISA II? > To me, either 1.a) or 2) is fine with me, although I have a slight faovr over > 2) (perhaps because I don't like assembly code and the extra "vertical" > calling layer introduced in 1.a) What about 3) -- a new syscall with a different semantics and no need to care about limitations of current implementations (especially the sysmips() bag). I've just sent a proposal for discussion. I'm looking forward for constructive feedback. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 12:54:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SJsOd02046 for linux-mips-outgoing; Mon, 28 May 2001 12:54:24 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SJr7d02022; Mon, 28 May 2001 12:53:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA26579; Mon, 28 May 2001 17:37:00 +0200 (MET DST) Date: Mon, 28 May 2001 17:37:00 +0200 (MET DST) From: "Maciej W. Rozycki" To: Florian Lohoff cc: Joe deBlaquiere , Jun Sun , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com, "Kevin D. Kissell" Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <20010526151427.A611@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 690 Lines: 17 On Sat, 26 May 2001, Florian Lohoff wrote: > > Anyway, an ISA-II-compiled glibc won't work on an ISA I system even if > > the ll/sc emulation works. An ISA II is more than just an addition of the > > ll and sc instructions. There were also branch likely, trap and > > doubleword coprocessor load instructions added in ISA II. Do you want to > > emulate these, too? > > Isnt this the reason why Linux/Mips userspace is compiles with ISA I + ll/sc ? Is it? Mine certainly is not. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 13:19:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SKJ7Z02557 for linux-mips-outgoing; Mon, 28 May 2001 13:19:07 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SK1nd02341; Mon, 28 May 2001 13:05:50 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA26818; Mon, 28 May 2001 17:43:19 +0200 (MET DST) Date: Mon, 28 May 2001 17:43:19 +0200 (MET DST) From: "Maciej W. Rozycki" To: Florian Lohoff cc: Joe deBlaquiere , Jun Sun , ralf@oss.sgi.com, Pete Popov , George Gensure , linux-mips@oss.sgi.com, "Kevin D. Kissell" Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <20010526151550.B611@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 808 Lines: 20 On Sat, 26 May 2001, Florian Lohoff wrote: > Export the existance of ll/sc via /proc/cpuinfo or whatever. That's a valid approach and also nothing new to glibc -- see Alpha and in()/out() support. But do we want an extra overhead due to an indirect call? Especially as _test_and_set() gets usually inlined? > I dont think this is true necessarly - There are still people building > embedded x86 systems based on 386 cores. Look at the vr41xx systems - They > do also lack the ll/sc afaik. This is nowadays the most commonly > used embedded/pda cpu. Are vr41xx plain ISA I or crippled ISA II+ CPUs? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 13:20:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SKKIq02722 for linux-mips-outgoing; Mon, 28 May 2001 13:20:18 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SKJkd02699 for ; Mon, 28 May 2001 13:19:47 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23240; Mon, 28 May 2001 15:59:30 +0200 (MET DST) Date: Mon, 28 May 2001 15:59:29 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1458 Lines: 36 On Mon, 28 May 2001, Kevin D. Kissell wrote: > I'd been disassembling the resulting .o files, as I didn't care whether > it's the compiler or the assembler that ultimately makes things right. It's good to check the generated assembly if you suspect a tool bug. > Repeating your experiment using -S gives the following results: Thanks for testing other versions. > However, if one compiles all the way to object code and looks > at what the assembler is actually doing with those "impossible" > offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat" > in the "m" and "o" constraint cases. It is *not* using the "at" register. > It is, however, cleverly using the load destination register as a temporary > to calculate the correct address. As there are no memory operations, That's clever, indeed... > these instructions should have no effect on the correct execution > of the ll/sc sequence (though they will increase the statistical > probability > of a context switch between ll and sc). ... but that won't work for a lone store, so we need a properly working 'R' constraint in the compiler. Since 3.0 works, as you report, there is no need to worry (but I might consider backporting changes to 2.95.3). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 13:40:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SKeMV03270 for linux-mips-outgoing; Mon, 28 May 2001 13:40:22 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SKaGd03195 for ; Mon, 28 May 2001 13:36:25 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23240; Mon, 28 May 2001 15:59:30 +0200 (MET DST) Date: Mon, 28 May 2001 15:59:29 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1458 Lines: 36 On Mon, 28 May 2001, Kevin D. Kissell wrote: > I'd been disassembling the resulting .o files, as I didn't care whether > it's the compiler or the assembler that ultimately makes things right. It's good to check the generated assembly if you suspect a tool bug. > Repeating your experiment using -S gives the following results: Thanks for testing other versions. > However, if one compiles all the way to object code and looks > at what the assembler is actually doing with those "impossible" > offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat" > in the "m" and "o" constraint cases. It is *not* using the "at" register. > It is, however, cleverly using the load destination register as a temporary > to calculate the correct address. As there are no memory operations, That's clever, indeed... > these instructions should have no effect on the correct execution > of the ll/sc sequence (though they will increase the statistical > probability > of a context switch between ll and sc). ... but that won't work for a lone store, so we need a properly working 'R' constraint in the compiler. Since 3.0 works, as you report, there is no need to worry (but I might consider backporting changes to 2.95.3). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 13:51:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SKpuG03736 for linux-mips-outgoing; Mon, 28 May 2001 13:51:56 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SKpdd03733 for ; Mon, 28 May 2001 13:51:40 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23240; Mon, 28 May 2001 15:59:30 +0200 (MET DST) Date: Mon, 28 May 2001 15:59:29 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1458 Lines: 36 On Mon, 28 May 2001, Kevin D. Kissell wrote: > I'd been disassembling the resulting .o files, as I didn't care whether > it's the compiler or the assembler that ultimately makes things right. It's good to check the generated assembly if you suspect a tool bug. > Repeating your experiment using -S gives the following results: Thanks for testing other versions. > However, if one compiles all the way to object code and looks > at what the assembler is actually doing with those "impossible" > offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat" > in the "m" and "o" constraint cases. It is *not* using the "at" register. > It is, however, cleverly using the load destination register as a temporary > to calculate the correct address. As there are no memory operations, That's clever, indeed... > these instructions should have no effect on the correct execution > of the ll/sc sequence (though they will increase the statistical > probability > of a context switch between ll and sc). ... but that won't work for a lone store, so we need a properly working 'R' constraint in the compiler. Since 3.0 works, as you report, there is no need to worry (but I might consider backporting changes to 2.95.3). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 14:18:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SLIPI05324 for linux-mips-outgoing; Mon, 28 May 2001 14:18:25 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SL9kd04828 for ; Mon, 28 May 2001 14:10:02 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23240; Mon, 28 May 2001 15:59:30 +0200 (MET DST) Date: Mon, 28 May 2001 15:59:29 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1458 Lines: 36 On Mon, 28 May 2001, Kevin D. Kissell wrote: > I'd been disassembling the resulting .o files, as I didn't care whether > it's the compiler or the assembler that ultimately makes things right. It's good to check the generated assembly if you suspect a tool bug. > Repeating your experiment using -S gives the following results: Thanks for testing other versions. > However, if one compiles all the way to object code and looks > at what the assembler is actually doing with those "impossible" > offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat" > in the "m" and "o" constraint cases. It is *not* using the "at" register. > It is, however, cleverly using the load destination register as a temporary > to calculate the correct address. As there are no memory operations, That's clever, indeed... > these instructions should have no effect on the correct execution > of the ll/sc sequence (though they will increase the statistical > probability > of a context switch between ll and sc). ... but that won't work for a lone store, so we need a properly working 'R' constraint in the compiler. Since 3.0 works, as you report, there is no need to worry (but I might consider backporting changes to 2.95.3). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 14:37:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SLb7D05796 for linux-mips-outgoing; Mon, 28 May 2001 14:37:07 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SLb2d05793 for ; Mon, 28 May 2001 14:37:03 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23240; Mon, 28 May 2001 15:59:30 +0200 (MET DST) Date: Mon, 28 May 2001 15:59:29 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1458 Lines: 36 On Mon, 28 May 2001, Kevin D. Kissell wrote: > I'd been disassembling the resulting .o files, as I didn't care whether > it's the compiler or the assembler that ultimately makes things right. It's good to check the generated assembly if you suspect a tool bug. > Repeating your experiment using -S gives the following results: Thanks for testing other versions. > However, if one compiles all the way to object code and looks > at what the assembler is actually doing with those "impossible" > offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat" > in the "m" and "o" constraint cases. It is *not* using the "at" register. > It is, however, cleverly using the load destination register as a temporary > to calculate the correct address. As there are no memory operations, That's clever, indeed... > these instructions should have no effect on the correct execution > of the ll/sc sequence (though they will increase the statistical > probability > of a context switch between ll and sc). ... but that won't work for a lone store, so we need a properly working 'R' constraint in the compiler. Since 3.0 works, as you report, there is no need to worry (but I might consider backporting changes to 2.95.3). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 15:04:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4SM4a206373 for linux-mips-outgoing; Mon, 28 May 2001 15:04:36 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SM4Dd06370 for ; Mon, 28 May 2001 15:04:31 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23240; Mon, 28 May 2001 15:59:30 +0200 (MET DST) Date: Mon, 28 May 2001 15:59:29 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs In-Reply-To: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1458 Lines: 36 On Mon, 28 May 2001, Kevin D. Kissell wrote: > I'd been disassembling the resulting .o files, as I didn't care whether > it's the compiler or the assembler that ultimately makes things right. It's good to check the generated assembly if you suspect a tool bug. > Repeating your experiment using -S gives the following results: Thanks for testing other versions. > However, if one compiles all the way to object code and looks > at what the assembler is actually doing with those "impossible" > offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat" > in the "m" and "o" constraint cases. It is *not* using the "at" register. > It is, however, cleverly using the load destination register as a temporary > to calculate the correct address. As there are no memory operations, That's clever, indeed... > these instructions should have no effect on the correct execution > of the ll/sc sequence (though they will increase the statistical > probability > of a context switch between ll and sc). ... but that won't work for a lone store, so we need a properly working 'R' constraint in the compiler. Since 3.0 works, as you report, there is no need to worry (but I might consider backporting changes to 2.95.3). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon May 28 18:39:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4T1dTO09528 for linux-mips-outgoing; Mon, 28 May 2001 18:39:29 -0700 Received: from smtp.huawei.com ([202.96.135.132]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T1dQd09524 for ; Mon, 28 May 2001 18:39:26 -0700 Received: from hechendong11752 ([10.105.33.128]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GE2POQ00.P0F for ; Tue, 29 May 2001 09:34:02 +0800 Message-ID: <002501c0e7e0$7fba9a00$8021690a@huawei.com> From: "machael thailer" To: Subject: Does Linux support RC32332 CPU now? Date: Tue, 29 May 2001 09:41:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 296 Lines: 13 Hi, folks: I am a newbie in linux-mips. I have questions to ask: 1 Does Linux support RC32332 CPU now? 2 I want to build my cross-compile environment for MIPS target on my X86 host. Are there any documents about how to implement it? Thank you very much. machael thailer From owner-linux-mips@oss.sgi.com Tue May 29 00:00:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4T70AH17997 for linux-mips-outgoing; Tue, 29 May 2001 00:00:10 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T708d17994 for ; Tue, 29 May 2001 00:00:08 -0700 Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id IAA03833; Tue, 29 May 2001 08:57:33 +0200 (MET DST) Date: Tue, 29 May 2001 08:57:33 +0200 (MET DST) From: Geert Uytterhoeven To: "Maciej W. Rozycki" cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 811 Lines: 22 On Mon, 28 May 2001, Maciej W. Rozycki wrote: > On Mon, 28 May 2001, Kevin D. Kissell wrote: > > > Are vr41xx plain ISA I or crippled ISA II+ CPUs? > > > > Actually, they are crippled MIPS III+ 64-bit CPUs > > Then an ll/sc and lld/scd emulation seems to be most appropriate here. I > don't think we want to add _test_and_set() to mips64*-linux. Do you want to run a 64-bit kernel on a Vr41xx? Most of these are used in embedded systems, where the amount of RAM is a few orders of magnitude smaller than the 32-bit RAM limit. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue May 29 05:52:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4TCqp824428 for linux-mips-outgoing; Tue, 29 May 2001 05:52:51 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TCpsd24395 for ; Tue, 29 May 2001 05:52:16 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA28041; Tue, 29 May 2001 12:45:16 +0200 (MET DST) Date: Tue, 29 May 2001 12:45:14 +0200 (MET DST) From: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 852 Lines: 21 On Tue, 29 May 2001, Geert Uytterhoeven wrote: > > Then an ll/sc and lld/scd emulation seems to be most appropriate here. I > > don't think we want to add _test_and_set() to mips64*-linux. > > Do you want to run a 64-bit kernel on a Vr41xx? Most of these are used in > embedded systems, where the amount of RAM is a few orders of magnitude smaller > than the 32-bit RAM limit. I have no preference on a Vr41xx, at least as long as I don't have one. You need an ll/sc emulation for it anyway, as you don't want to run ISA I binaries on it, I suppose. I wonder why ll/sc was skipped from it -- its hardware implementation is quite simple... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue May 29 06:18:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4TDI1a25640 for linux-mips-outgoing; Tue, 29 May 2001 06:18:01 -0700 Received: from blackdog.wirespeed.com ([208.170.106.25]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TDHwd25635 for ; Tue, 29 May 2001 06:17:58 -0700 Received: from redhat.com (IDENT:joe@uberdog.hsv.redhat.com [172.16.16.108]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id HAA24136; Tue, 29 May 2001 07:51:54 -0500 Message-ID: <3B139DF6.2060203@redhat.com> Date: Tue, 29 May 2001 08:02:46 -0500 From: Joe deBlaquiere User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.8.1) Gecko/20010422 X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 694 Lines: 33 Maciej W. Rozycki wrote: > On Mon, 28 May 2001, Kevin D. Kissell wrote: > > >> Use a global variable testable by the inline code? > > > With both variants inlined? Now that's really ugly. > > >>> Are vr41xx plain ISA I or crippled ISA II+ CPUs? >> >> Actually, they are crippled MIPS III+ 64-bit CPUs > > > Then an ll/sc and lld/scd emulation seems to be most appropriate here. I > don't think we want to add _test_and_set() to mips64*-linux. All the cases I've seen have been for 32-bit kernels. A 64-bit PDA kernel seems like a wee tiny bit of overkill -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Tue May 29 15:35:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4TMZUB13580 for linux-mips-outgoing; Tue, 29 May 2001 15:35:30 -0700 Received: from hermes.mvista.com ([12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TMZQd13577 for ; Tue, 29 May 2001 15:35:26 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4TMWp024909; Tue, 29 May 2001 15:32:51 -0700 Message-ID: <3B142367.791F28AF@mvista.com> Date: Tue, 29 May 2001 15:32:07 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Joe deBlaquiere , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1739 Lines: 44 "Maciej W. Rozycki" wrote: > > On Fri, 25 May 2001, Jun Sun wrote: > > > Alright, I rolled my sleeve and digged into IRIX 6.5, and guess what? > > sysmips() does NOT have MIPS_ATOMIC_SET (2001) on IRIX! See the header below. > > I remember Ralf writing of this being a compatibility call with RISC/OS > (is it the original OS of MIPS, Inc.?), IIRC. Ralf: am I right? > > > So apparently MIPS_ATOMIC_SET was invented for Linux only, probably just to > > implement _test_and_set(). (It would be interesting to see how IRIX implement > > _test_and_set() on MIPS I machines. However, the machine I have access uses > > ll/sc instructions). > > Does IRIX actually run on anything below ISA II? > I assume nobody answering the above questions means nobody really care. So we can safely move ahead without worrying about them. :-) > > To me, either 1.a) or 2) is fine with me, although I have a slight faovr over > > 2) (perhaps because I don't like assembly code and the extra "vertical" > > calling layer introduced in 1.a) > > What about 3) -- a new syscall with a different semantics and no need to > care about limitations of current implementations (especially the > sysmips() bag). Having a new syscall is fine with me, although seems a little more instrusive than adding a subcall to sysmips(). > I've just sent a proposal for discussion. I'm looking > forward for constructive feedback. > The patch looks good to me. BTW, why wouldn't you choose to have three arguments in the syscall, where the last one is a pointer to the variable to hold the return value? Doing that would avoid tricky register manipulation on both calling side (fetching return value from $v1) and kernel side (setting regs.regs[3]). Jun From owner-linux-mips@oss.sgi.com Tue May 29 15:38:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4TMcb813732 for linux-mips-outgoing; Tue, 29 May 2001 15:38:37 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TMcXd13728 for ; Tue, 29 May 2001 15:38:34 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4TMbr025239; Tue, 29 May 2001 15:37:53 -0700 Message-ID: <3B142495.66677A18@mvista.com> Date: Tue, 29 May 2001 15:37:09 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 810 Lines: 27 "Maciej W. Rozycki" wrote: > > On Mon, 28 May 2001, Kevin D. Kissell wrote: > > > Use a global variable testable by the inline code? > > With both variants inlined? Now that's really ugly. I think system V requires _test_and_set() being included in the libsys dynamic library. Does Linux want to be sysv compatible? If so, we should removed the inlined _test_and_set(). > > > > Are vr41xx plain ISA I or crippled ISA II+ CPUs? > > > > Actually, they are crippled MIPS III+ 64-bit CPUs > > Then an ll/sc and lld/scd emulation seems to be most appropriate here. I > don't think we want to add _test_and_set() to mips64*-linux. > 64 bit is a overkill for the pityful vr41xx CPUs. The need for kernel emulated test_and_set() in 64bit kernel is not obvious yet, and hopefully will never come. Jun From owner-linux-mips@oss.sgi.com Tue May 29 17:18:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U0I8915983 for linux-mips-outgoing; Tue, 29 May 2001 17:18:08 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U0Hkh15975; Tue, 29 May 2001 17:17:52 -0700 Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 154tgK-0001yQ-00; Tue, 29 May 2001 17:17:48 -0700 Date: Tue, 29 May 2001 17:17:48 -0700 From: Daniel Jacobowitz To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Message-ID: <20010529171748.A7362@nevyn.them.org> References: <20010523145257.A13013@nevyn.them.org> <20010525172746.B6578@bacchus.dhis.org> <20010525134909.A26065@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20010525134909.A26065@nevyn.them.org>; from dan@debian.org on Fri, May 25, 2001 at 01:49:09PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1657 Lines: 31 On Fri, May 25, 2001 at 01:49:09PM -0700, Daniel Jacobowitz wrote: > On Fri, May 25, 2001 at 05:27:46PM -0300, Ralf Baechle wrote: > > On Thu, May 24, 2001 at 03:42:56PM +0200, Maciej W. Rozycki wrote: > > > > > > The ll/sc constructs in the kernel use ".set noat" to inhibit use of $at, > > > > and proceed to use it themselves. This is fine, except for one problem: the > > > > constraints on memory operands are "o" and "=o", which means offsettable > > > > memory references. If I'm not mistaken, the assembler will (always?) > > > > turn these into uses of $at if the offset is not 0 - at least, it certainly > > > > seems to do that here (gcc 2.95.3, binutils 2.10.91.0.2). Just being honest > > > > with the compiler and asking for a real memory reference does the trick. > > > > > > Both "m" and "o" seem to be incorrect here as both are the same for MIPS; > > > "R" seems to be appropriate, OTOH. Still gcc 2.95.3 doesn't handle "R" > > > fine for all cases, but it works most of the time and emits a warning > > > otherwise. I can't comment on 3.0. Back to quibbling - that's just not true. For one thing, from the info documentation: `R' Memory reference that can be loaded with one instruction (`m' is preferable for `asm' statements) For another, using the patch I posted below, I get inconsistent constraint errors. I'm not entirely sure why. Is there any reason not to use the "m" version? I can't see any case in which it would not behave correctly. -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team From owner-linux-mips@oss.sgi.com Tue May 29 17:41:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U0flH16394 for linux-mips-outgoing; Tue, 29 May 2001 17:41:47 -0700 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U0fhh16390 for ; Tue, 29 May 2001 17:41:43 -0700 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id IAA13454; Tue, 29 May 2001 08:45:20 -0700 Message-Id: <200105291545.IAA13454@saturn.mikemac.com> To: Joe deBlaquiere cc: linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: Your message of "Tue, 29 May 2001 08:02:46 CDT." <3B139DF6.2060203@redhat.com> Date: Tue, 29 May 2001 08:45:20 -0700 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 882 Lines: 33 >Date: Tue, 29 May 2001 08:02:46 -0500 >From: Joe deBlaquiere >To: "Maciej W. Rozycki" >Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel > > > >Maciej W. Rozycki wrote: > >> On Mon, 28 May 2001, Kevin D. Kissell wrote: >> >> >>> Use a global variable testable by the inline code? >> >> >> With both variants inlined? Now that's really ugly. >> >> >>>> Are vr41xx plain ISA I or crippled ISA II+ CPUs? >>> >>> Actually, they are crippled MIPS III+ 64-bit CPUs >> >> >> Then an ll/sc and lld/scd emulation seems to be most appropriate here. I >> don't think we want to add _test_and_set() to mips64*-linux. > >All the cases I've seen have been for 32-bit kernels. A 64-bit PDA kernel seems like a wee tiny bit of overkill I've been asked about running 64 bit binaries on a VR4121. Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Tue May 29 18:32:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U1WbI18030 for linux-mips-outgoing; Tue, 29 May 2001 18:32:37 -0700 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U1WYh18027 for ; Tue, 29 May 2001 18:32:34 -0700 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id SAA22750 for ; Tue, 29 May 2001 18:32:32 -0700 Message-Id: <200105300132.SAA22750@saturn.mikemac.com> cc: linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: Your message of "Tue, 29 May 2001 08:45:20 PDT." <200105291545.IAA13454@saturn.mikemac.com> Date: Tue, 29 May 2001 18:32:32 -0700 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 414 Lines: 14 >To: Joe deBlaquiere >Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel >Date: Tue, 29 May 2001 08:45:20 -0700 >From: Mike McDonald > I've been asked about running 64 bit binaries on a VR4121. ^^^^^^ VR4122! I shouldn't try writing before I have my tea in the morning! Mike "Banned from sgi.bad-attitude" McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Wed May 30 01:44:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U8irX23769 for linux-mips-outgoing; Wed, 30 May 2001 01:44:53 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U8ijh23742; Wed, 30 May 2001 01:44:45 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA03670; Tue, 29 May 2001 23:57:57 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id XAA24167; Tue, 29 May 2001 23:57:53 -0700 (PDT) Message-ID: <001e01c0e8d6$7b73b5c0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" , "Ralf Baechle" Cc: References: <20010523145257.A13013@nevyn.them.org> <20010525172746.B6578@bacchus.dhis.org> <20010525134909.A26065@nevyn.them.org> <20010529171748.A7362@nevyn.them.org> Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs Date: Wed, 30 May 2001 09:02:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2361 Lines: 55 > > > > > The ll/sc constructs in the kernel use ".set noat" to inhibit use of $at, > > > > > and proceed to use it themselves. This is fine, except for one problem: the > > > > > constraints on memory operands are "o" and "=o", which means offsettable > > > > > memory references. If I'm not mistaken, the assembler will (always?) > > > > > turn these into uses of $at if the offset is not 0 - at least, it certainly > > > > > seems to do that here (gcc 2.95.3, binutils 2.10.91.0.2). Just being honest > > > > > with the compiler and asking for a real memory reference does the trick. > > > > > > > > Both "m" and "o" seem to be incorrect here as both are the same for MIPS; > > > > "R" seems to be appropriate, OTOH. Still gcc 2.95.3 doesn't handle "R" > > > > fine for all cases, but it works most of the time and emits a warning > > > > otherwise. I can't comment on 3.0. > > Back to quibbling - that's just not true. For one thing, from the info > documentation: > `R' > Memory reference that can be loaded with one instruction (`m' > is preferable for `asm' statements) > > For another, using the patch I posted below, I get inconsistent > constraint errors. I'm not entirely sure why. Is there any reason not > to use the "m" version? I can't see any case in which it would not > behave correctly. There seems to be a bug in many older gcc's, where if you use "m" or "o", and the effective address requires more than 16 bits of offset relative to an available base register, store address calculations override the "noat" setting. Load address calculations are at least smart enough to use the load destination as the temporary register. Of the compilers that I was able to test, "R" constraint worked only on the most recent gcc version. And with that compiler, "m" also generated correct code. The "m" constraint also worked on earlier gcc's, but violated the noat constraint on stores. The compilers where "m" violated noat were also those where the "R" constraint was rejected as being inconsistent. None of the compilers tested generated correct code for "R" but incorrect code for "m". So it could be argued that "m" constraints will in fact function with a broader range of compilers, albeit with the quirk that a "noat" override warning may be produced in the case of older gcc's. Kevin K. From owner-linux-mips@oss.sgi.com Wed May 30 01:44:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U8il623748 for linux-mips-outgoing; Wed, 30 May 2001 01:44:47 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U8iih23739 for ; Wed, 30 May 2001 01:44:44 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA03724; Wed, 30 May 2001 00:05:35 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA24380; Wed, 30 May 2001 00:05:32 -0700 (PDT) Message-ID: <002201c0e8d7$8c9ebd80$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Joe deBlaquiere" , "Mike McDonald" Cc: References: <200105291545.IAA13454@saturn.mikemac.com> Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel Date: Wed, 30 May 2001 09:09:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1005 Lines: 25 > >>>> Are vr41xx plain ISA I or crippled ISA II+ CPUs? > >>> > >>> Actually, they are crippled MIPS III+ 64-bit CPUs > >> > >> > >> Then an ll/sc and lld/scd emulation seems to be most appropriate here. I > >> don't think we want to add _test_and_set() to mips64*-linux. > > > >All the cases I've seen have been for 32-bit kernels. A 64-bit PDA kernel seems like a wee tiny bit of overkill > > I've been asked about running 64 bit binaries on a VR4121. Being able to use all 64-bits of the registers is a huge win for certain embedded/handheld applications, even if 64-bit addressing is worse than useless. It's unfortunate that the original R4000 merged the enabling of 64-bit data types with the generation of 64-bit addresses. The newer MIPS64 CPUs have a bit in the Status register to enable the data types without enabling the addresses. I don't know that NEC has implemented this for the VR41xx family, but they really should. And fix ll/sc while they are at it. ;-) Kevin K. From owner-linux-mips@oss.sgi.com Wed May 30 01:44:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U8inf23754 for linux-mips-outgoing; Wed, 30 May 2001 01:44:49 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U8ijh23744 for ; Wed, 30 May 2001 01:44:45 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA03555; Tue, 29 May 2001 23:42:07 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id XAA23826; Tue, 29 May 2001 23:42:03 -0700 (PDT) Message-ID: <000901c0e8d4$4525f480$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: References: <3B142367.791F28AF@mvista.com> Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel Date: Wed, 30 May 2001 08:46:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 896 Lines: 28 > > > So apparently MIPS_ATOMIC_SET was invented for Linux only, probably just to > > > implement _test_and_set(). (It would be interesting to see how IRIX implement > > > _test_and_set() on MIPS I machines. However, the machine I have access uses > > > ll/sc instructions). > > > > Does IRIX actually run on anything below ISA II? > > > > I assume nobody answering the above questions means nobody > really care. So we can safely move ahead without worrying about > them. :-) I was waiting for someone to give a more authoritative answer, but IIRC from my days at SGI, IRIX did of course run on the R3000-based products, but support for them was dropped in IRIX 6.x. I couldn't give you the version number of the last IRIX version that did support the R3K, though. And as others have observed, it was in any case not IRIX, but MIPS' own RiscOS that drove the ABI. Keivn K. From owner-linux-mips@oss.sgi.com Wed May 30 05:36:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UCaFn27509 for linux-mips-outgoing; Wed, 30 May 2001 05:36:15 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UCZXh27479 for ; Wed, 30 May 2001 05:35:33 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id WAA151484 for ; Mon, 28 May 2001 22:58:17 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 154U5d-00082y-00 for ; Mon, 28 May 2001 22:58:13 +0200 Date: Mon, 28 May 2001 22:58:13 +0200 To: linux-mips@oss.sgi.com Subject: [PATCH] More (mostly minor) fixes mostly for mips64 Message-ID: <20010528225813.A14867@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 27495 Lines: 861 Hello All, This patch does for both mips and mips64: - save return address in process:kernel_thread (How did this ever work?) - code cosmetics and removal of unused code and for mips64 only: - introduce CPU_R12000 - correct use of CONFIG_BOARD_CACHE - fix undefined expression evaluation in lib/dump_tlb.c - fix possible counter overflow in sgi-ip22/ip22-timer.c:dosample - some minor fixes due to bitrot - more code cosmetics, removal of unused code, typo fixes, etc. Thiemo diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips/kernel/entry.S linux/arch/mips/kernel/entry.S --- linux-orig/arch/mips/kernel/entry.S Thu Mar 29 17:11:05 2001 +++ linux/arch/mips/kernel/entry.S Sat May 26 01:24:21 2001 @@ -27,7 +27,7 @@ #include .text - .align 4 + .align 5 .set push .set reorder EXPORT(ret_from_fork) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c --- linux-orig/arch/mips/kernel/process.c Thu Mar 29 17:11:05 2001 +++ linux/arch/mips/kernel/process.c Sat May 26 01:24:21 2001 @@ -186,7 +186,7 @@ * at, result, argument or temporary registers ... */ :"$1", "$2", "$3", "$4", "$5", "$6", "$7", "$8", - "$9","$10","$11","$12","$13","$14","$15","$24","$25"); + "$9","$10","$11","$12","$13","$14","$15","$24","$25", "$31"); return retval; } diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips/tools/Makefile linux/arch/mips/tools/Makefile --- linux-orig/arch/mips/tools/Makefile Sat May 27 13:53:31 2000 +++ linux/arch/mips/tools/Makefile Sat May 26 01:24:21 2001 @@ -23,8 +23,7 @@ clean: rm -f offset.[hs] $(TARGET).new -mrproper: - rm -f offset.[hs] $(TARGET).new +mrproper: clean: rm -f $(TARGET) include $(TOPDIR)/Rules.make diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips/arc/init.c linux/arch/mips/arc/init.c --- linux-orig/arch/mips/arc/init.c Fri Feb 9 19:38:49 2001 +++ linux/arch/mips/arc/init.c Sat May 26 01:24:21 2001 @@ -16,10 +16,8 @@ /* Master romvec interface. */ struct linux_romvec *romvec; -struct linux_promblock *sgi_pblock; int prom_argc; char **prom_argv, **prom_envp; -unsigned short prom_vers, prom_rev; extern void prom_testtree(void); @@ -28,9 +26,10 @@ void __init prom_init(int argc, char **argv, char **envp, int *prom_vec) { struct linux_promblock *pb; + unsigned short prom_vers, prom_rev; romvec = ROMVECTOR; - pb = sgi_pblock = PROMBLOCK; + pb = PROMBLOCK; prom_argc = argc; prom_argv = argv; prom_envp = envp; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/arc/identify.c linux/arch/mips64/arc/identify.c --- linux-orig/arch/mips64/arc/identify.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/arc/identify.c Sat May 26 01:24:23 2001 @@ -63,9 +64,11 @@ p = ArcGetChild(PROM_NULL_COMPONENT); if (p == NULL) { #ifdef CONFIG_SGI_IP27 - /* IP27 PROM bisbehaves, seems to not implement ARC + /* IP27 PROM misbehaves, seems to not implement ARC GetChild(). So we just assume it's an IP27. */ iname = "SGI-IP27"; +#else + iname = "Unknown"; #endif } else iname = (char *) (long) p->iname; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/arc/init.c linux/arch/mips64/arc/init.c --- linux-orig/arch/mips64/arc/init.c Tue Mar 7 16:45:28 2000 +++ linux/arch/mips64/arc/init.c Sat May 26 01:24:23 2001 @@ -17,43 +17,35 @@ /* Master romvec interface. */ struct linux_romvec *romvec; -PSYSTEM_PARAMETER_BLOCK sgi_pblock; int prom_argc; LONG *_prom_argv, *_prom_envp; -unsigned short prom_vers, prom_rev; - -extern void prom_testtree(void); int __init prom_init(int argc, char **argv, char **envp) { - PSYSTEM_PARAMETER_BLOCK pb; - + PSYSTEM_PARAMETER_BLOCK pb = PROMBLOCK; romvec = ROMVECTOR; - pb = sgi_pblock = PROMBLOCK; prom_argc = argc; _prom_argv = (LONG *) argv; _prom_envp = (LONG *) envp; - if(pb->magic != 0x53435241) { - prom_printf("Aieee, bad prom vector magic %08lx\n", pb->magic); + if(pb->magic != 0x53435241) { + prom_printf("Aieee, bad prom vector magic %08lx\n", + pb->magic); while(1) ; } prom_init_cmdline(); - - prom_vers = pb->ver; - prom_rev = pb->rev; prom_identify_arch(); printk("PROMLIB: ARC firmware Version %d Revision %d\n", - prom_vers, prom_rev); + pb->ver, pb->rev); prom_meminit(); #ifdef DEBUG_PROM_INIT { prom_printf("Press a key to reboot\n"); - (void) prom_getchar(); + prom_getchar(); ArcEnterInteractiveMode(); } #endif diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/arc/memory.c linux/arch/mips64/arc/memory.c --- linux-orig/arch/mips64/arc/memory.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/arc/memory.c Sat May 26 01:24:23 2001 @@ -141,7 +141,6 @@ void __init prom_free_prom_memory (void) { - struct prom_pmemblock *p; unsigned long freed = 0; unsigned long addr; int i; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/linux32.c linux/arch/mips64/kernel/linux32.c --- linux-orig/arch/mips64/kernel/linux32.c Thu Apr 5 20:25:43 2001 +++ linux/arch/mips64/kernel/linux32.c Sat May 26 01:24:23 2001 @@ -406,10 +406,10 @@ /* egcs is stupid */ if (!access_ok(VERIFY_READ, arg, sizeof (unsigned int))) return -EFAULT; - if (IS_ERR(ret = __get_user((long)ptr,(int *)A(arg)))) + if ((ret = __get_user((long)ptr, (int *)A(arg)))) return ret; if (ap) /* no access_ok needed, we allocated */ - if (IS_ERR(ret = __put_user(ptr, ap++))) + if ((ret = __put_user(ptr, ap++))) return ret; arg += sizeof(unsigned int); n++; @@ -429,10 +429,10 @@ char * filename; na = nargs(argv, NULL); - if (IS_ERR(na)) + if (na) return(na); ne = nargs(envp, NULL); - if (IS_ERR(ne)) + if (ne) return(ne); len = (na + ne + 2) * sizeof(*av); /* @@ -441,7 +441,7 @@ * on a kernel address (simplifies `get_user'). Instead we * do an mmap to get a user address. Note that since a successful * `execve' frees all current memory we only have to do an - * `munmap' if the `execve' failes. + * `munmap' if the `execve' fails. */ down_write(¤t->mm->mmap_sem); av = (char **) do_mmap_pgoff(0, 0, len, PROT_READ | PROT_WRITE, @@ -451,13 +451,13 @@ if (IS_ERR(av)) return (long) av; ae = av + na + 1; - if (IS_ERR(r = __put_user(0, (av + na)))) + if ((r = __put_user(0, (av + na)))) goto out; - if (IS_ERR(r = __put_user(0, (ae + ne)))) + if ((r = __put_user(0, (ae + ne)))) goto out; - if (IS_ERR(r = nargs(argv, av))) + if ((r = nargs(argv, av))) goto out; - if (IS_ERR(r = nargs(envp, ae))) + if ((r = nargs(envp, ae))) goto out; filename = getname((char *) (long)regs.regs[4]); r = PTR_ERR(filename); @@ -466,7 +466,7 @@ r = do_execve(filename, av, ae, ®s); putname(filename); - if (IS_ERR(r)) + if (r) out: sys_munmap((unsigned long)av, len); return(r); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/process.c linux/arch/mips64/kernel/process.c --- linux-orig/arch/mips64/kernel/process.c Wed Mar 14 17:11:47 2001 +++ linux/arch/mips64/kernel/process.c Sat May 26 01:24:24 2001 @@ -173,7 +173,7 @@ /* The called subroutine might have destroyed any of the * at, result, argument or temporary registers ... */ :"$1", "$2", "$3", "$4", "$5", "$6", "$7", "$8", - "$9","$10","$11","$12","$13","$14","$15","$24","$25"); + "$9","$10","$11","$12","$13","$14","$15","$24","$25", "$31"); return retval; } diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/setup.c linux/arch/mips64/kernel/setup.c --- linux-orig/arch/mips64/kernel/setup.c Sat May 26 00:25:39 2001 +++ linux/arch/mips64/kernel/setup.c Sat May 26 01:24:25 2001 @@ -99,6 +99,8 @@ extern void ip22_setup(void); extern void ip27_setup(void); +extern void bootmem_init(void); + static inline void cpu_probe(void) { unsigned int prid = read_32bit_cp0_register(CP0_PRID); @@ -126,9 +128,11 @@ mips_cputype = CPU_R8000; break; case PRID_IMP_R10000: - case PRID_IMP_R12000: mips_cputype = CPU_R10000; break; + case PRID_IMP_R12000: + mips_cputype = CPU_R12000; + break; default: mips_cputype = CPU_UNKNOWN; } diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/signal.c linux/arch/mips64/kernel/signal.c --- linux-orig/arch/mips64/kernel/signal.c Fri Feb 9 19:38:53 2001 +++ linux/arch/mips64/kernel/signal.c Sat May 26 01:24:25 2001 @@ -601,11 +601,6 @@ } #endif -#ifdef CONFIG_BINFMT_IRIX - if (current->personality != PER_LINUX) - return do_irix_signal(oldset, regs); -#endif - if (!oldset) oldset = ¤t->blocked; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/softfp.S linux/arch/mips64/kernel/softfp.S --- linux-orig/arch/mips64/kernel/softfp.S Mon Jul 10 01:59:56 2000 +++ linux/arch/mips64/kernel/softfp.S Sat May 26 02:42:41 2001 @@ -46,7 +46,7 @@ #define ft_shift 16 /* - * NaNs as use by the MIPS architecture + * NaNs as used by the MIPS architecture */ #define S_QNaN 0x7fbfffff #define D_QNaN 0x7ff7ffffffffffff @@ -70,7 +70,7 @@ and reg, res /* - * Some constants that define the properties of single precission numbers. + * Some constants that define the properties of single precision numbers. */ #define S_M_prec 24 #define S_E_max 127 @@ -103,7 +103,7 @@ /* - * Some constants that define the properties of double precission numbers. + * Some constants that define the properties of double precision numbers. */ #define D_M_prec 53 #define D_E_max 1023 @@ -366,7 +366,7 @@ /* XXX Ok, it's a normal number. We don't handle that case yet. If we have fp hardware this case is only reached if the value of the source register exceeds the range which is representable - in a single precission register. For now we kludge by returning + in a single precision register. For now we kludge by returning +/- maxint and don't signal overflow. */ srl ta1, ta1, 31 # Extract sign bit @@ -407,7 +407,7 @@ BITCH(c.le) BITCH(c.ngt) -/* Get the single precission register which's number is in ta1. */ +/* Get the single precision register which's number is in ta1. */ s_get_fpreg: .set noat sll ta1, 3 @@ -482,7 +482,7 @@ jr ra /* - * Put the value in ta2 into the single precission register which's number + * Put the value in ta2 into the single precision register which's number * is in ta1. */ s_put_fpreg: @@ -558,7 +558,7 @@ mtc1 ta2, $31 jr ra -/* Get the double precission register which's number is in ta1 into ta1/ta2. */ +/* Get the double precision register which's number is in ta1 into ta1/ta2. */ d_get_fpreg: .set noat sll AT, ta1, 1 diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/traps.c linux/arch/mips64/kernel/traps.c --- linux-orig/arch/mips64/kernel/traps.c Mon Mar 5 00:56:10 2001 +++ linux/arch/mips64/kernel/traps.c Sat May 26 02:28:13 2001 @@ -382,6 +382,7 @@ static inline void watch_init(unsigned long cputype) { switch(cputype) { + case CPU_R12000: case CPU_R10000: case CPU_R4000MC: case CPU_R4400MC: @@ -440,6 +441,7 @@ case CPU_NEVADA: case CPU_R8000: case CPU_R10000: + case CPU_R12000: mips4_available = 1; set_cp0_status(ST0_XX, ST0_XX); } @@ -489,13 +487,13 @@ * Handling the following exceptions depends mostly of the cpu type */ switch(mips_cputype) { + case CPU_R12000: case CPU_R10000: /* * The R10000 is in most aspects similar to the R4400. It * should get some special optimizations. */ write_32bit_cp0_register(CP0_FRAMEMASK, 0); - set_cp0_status(ST0_XX, ST0_XX); goto r4k; case CPU_R4000MC: diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/kernel/unaligned.c linux/arch/mips64/kernel/unaligned.c --- linux-orig/arch/mips64/kernel/unaligned.c Wed Mar 14 17:11:47 2001 +++ linux/arch/mips64/kernel/unaligned.c Sat May 26 01:24:25 2001 @@ -87,6 +87,9 @@ #define STR(x) __STR(x) #define __STR(x) #x +extern void +die_if_kernel(const char * str, struct pt_regs * regs, unsigned long err); + /* * User code may only access USEG; kernel code may access the * entire address space. @@ -365,15 +368,15 @@ return; } - die_if_kernel ("Unhandled kernel unaligned access", regs); + die_if_kernel ("Unhandled kernel unaligned access", regs, SIGSEGV); send_sig(SIGSEGV, current, 1); return; sigbus: - die_if_kernel ("Unhandled kernel unaligned access", regs); + die_if_kernel ("Unhandled kernel unaligned access", regs, SIGBUS); send_sig(SIGBUS, current, 1); return; sigill: - die_if_kernel ("Unhandled kernel unaligned access or invalid instruction", regs); + die_if_kernel ("Unhandled kernel unaligned access or invalid instruction", regs, SIGILL); send_sig(SIGILL, current, 1); return; } @@ -404,6 +407,6 @@ return; sigbus: - die_if_kernel ("Kernel unaligned instruction access", regs); + die_if_kernel ("Kernel unaligned instruction access", regs, SIGBUS); force_sig(SIGBUS, current); } diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/lib/dump_tlb.c linux/arch/mips64/lib/dump_tlb.c --- linux-orig/arch/mips64/lib/dump_tlb.c Sat Jul 8 02:53:02 2000 +++ linux/arch/mips64/lib/dump_tlb.c Sat May 26 01:24:25 2001 @@ -200,8 +200,10 @@ for(i=0;i<8;i++) { printk("*%08lx == %08lx, ", - (unsigned long)p, (unsigned long)*p++); + (unsigned long)p, (unsigned long)*p); + p++; printk("*%08lx == %08lx\n", - (unsigned long)p, (unsigned long)*p++); + (unsigned long)p, (unsigned long)*p); + p++; } } diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/init.c linux/arch/mips64/mm/init.c --- linux-orig/arch/mips64/mm/init.c Sat May 26 00:25:39 2001 +++ linux/arch/mips64/mm/init.c Sat May 26 02:29:36 2001 @@ -177,6 +177,7 @@ boot_mem_map.nr_map++; } +#ifdef DEBUG static void __init print_memory_map(void) { int i; @@ -200,6 +201,7 @@ } } } +#endif /* DEBUG */ void bootmem_init(void) { #ifdef CONFIG_BLK_DEV_INITRD diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/umap.c linux/arch/mips64/mm/umap.c --- linux-orig/arch/mips64/mm/umap.c Thu Apr 5 20:25:43 2001 +++ linux/arch/mips64/mm/umap.c Sat May 26 01:24:28 2001 @@ -178,7 +178,7 @@ end = PGDIR_SIZE; vaddr -= address; do { - pte_t * pte = pte_alloc(pmd, address); + pte_t * pte = pte_alloc(current->mm, pmd, address); if (!pte) return -ENOMEM; vmap_pte_range(pte, address, end - address, address + vaddr); @@ -200,7 +200,7 @@ dir = pgd_offset(current->mm, from); flush_cache_range(current->mm, beg, end); while (from < end) { - pmd_t *pmd = pmd_alloc(dir, from); + pmd_t *pmd = pmd_alloc(current->mm, dir, from); error = -ENOMEM; if (!pmd) break; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/Makefile linux/arch/mips64/sgi-ip22/Makefile --- linux-orig/arch/mips64/sgi-ip22/Makefile Fri Feb 9 19:38:53 2001 +++ linux/arch/mips64/sgi-ip22/Makefile Sat May 26 01:24:28 2001 @@ -10,7 +10,9 @@ L_TARGET = ip22.a -obj-y += ip22-berr.o ip22-mc.o ip22-sc.o ip22-hpc.o ip22-int.o ip22-rtc.o \ +obj-y += ip22-berr.o ip22-mc.o ip22-hpc.o ip22-int.o ip22-rtc.o \ ip22-setup.o system.o ip22-timer.o ip22-irq.o ip22-reset.o time.o + +obj-$(CONFIG_BOARD_SCACHE) += ip22-sc.o include $(TOPDIR)/Rules.make diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/ip22-berr.c linux/arch/mips64/sgi-ip22/ip22-berr.c --- linux-orig/arch/mips64/sgi-ip22/ip22-berr.c Thu Feb 24 01:12:41 2000 +++ linux/arch/mips64/sgi-ip22/ip22-berr.c Sat May 26 01:24:28 2001 @@ -14,6 +14,9 @@ #include #include +extern void dump_tlb_addr(unsigned long addr); +extern void dump_tlb_all(void); + extern asmlinkage void handle_ibe(void); extern asmlinkage void handle_dbe(void); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/ip22-irq.S linux/arch/mips64/sgi-ip22/ip22-irq.S --- linux-orig/arch/mips64/sgi-ip22/ip22-irq.S Sat Dec 4 04:59:01 1999 +++ linux/arch/mips64/sgi-ip22/ip22-irq.S Sat May 26 02:48:46 2001 @@ -56,8 +56,8 @@ .text .set noreorder .set noat - .align 5 NESTED(indyIRQ, PT_SIZE, sp) + .align 5 SAVE_ALL CLI .set at @@ -69,9 +69,8 @@ andi a0, s0, CAUSEF_IP2 # delay slot, check local level zero /* Wheee, a timer interrupt. */ - move a0, sp jal indy_timer_interrupt - nop # delay slot + move a0, sp # delay slot j ret_from_irq nop # delay slot @@ -92,38 +91,35 @@ andi a0, s0, CAUSEF_IP6 # delay slot, check bus error /* Wheee, local level one interrupt. */ - move a0, sp jal indy_local1_irqdispatch - nop + move a0, sp # delay slot j ret_from_irq - nop + nop # delay slot 1: beq a0, zero, 1f - nop + andi a0, s0, (CAUSEF_IP4 | CAUSEF_IP5) # delay slot, check timer /* Wheee, an asynchronous bus error... */ - move a0, sp jal indy_buserror_irq - nop + move a0, sp # delay slot j ret_from_irq - nop + nop # delay slot 1: /* Here by mistake? This is possible, what can happen * is that by the time we take the exception the IRQ * pin goes low, so just leave if this is the case. */ - andi a0, s0, (CAUSEF_IP4 | CAUSEF_IP5) beq a0, zero, 1f + move a0, sp # delay slot /* Must be one of the 8254 timers... */ - move a0, sp jal indy_8254timer_irq nop 1: j ret_from_irq - nop + nop # delay slot END(indyIRQ) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/ip22-mc.c linux/arch/mips64/sgi-ip22/ip22-mc.c --- linux-orig/arch/mips64/sgi-ip22/ip22-mc.c Sat May 26 00:25:39 2001 +++ linux/arch/mips64/sgi-ip22/ip22-mc.c Sat May 26 01:24:28 2001 @@ -16,6 +16,10 @@ /* #define DEBUG_SGIMC */ +#ifdef DEBUG_SGIMC +extern void prom_printf(char *fmt, ...); +#endif + struct sgimc_misc_ctrl *mcmisc_regs; u32 *rpsscounter; struct sgimc_dma_ctrl *dmactrlregs; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/ip22-setup.c linux/arch/mips64/sgi-ip22/ip22-setup.c --- linux-orig/arch/mips64/sgi-ip22/ip22-setup.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/sgi-ip22/ip22-setup.c Sat May 26 01:24:28 2001 @@ -33,11 +33,14 @@ #include #include +extern int console_setup(char *str); + +extern struct hpc3_miscregs *hpc3mregs; extern struct rtc_ops indy_rtc_ops; extern void ip22_reboot_setup(void); extern void ip22_volume_set(unsigned char); -#define sgi_kh ((struct hpc_keyb *) (KSEG1 + 0x1fbd9800 + 64)) +#define sgi_kh ((struct hpc_keyb *) &(hpc3mregs->kbdmouse0)) #define KBD_STAT_IBF 0x02 /* Keyboard input buffer full */ @@ -137,8 +140,10 @@ /* Init INDY memory controller. */ sgimc_init(); +#ifdef CONFIG_BOARD_SCACHE /* Now enable boardcaches, if any. */ indy_sc_init(); +#endif #ifdef CONFIG_SERIAL_CONSOLE /* ARCS console environment variable is set to "g?" for diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/ip22-timer.c linux/arch/mips64/sgi-ip22/ip22-timer.c --- linux-orig/arch/mips64/sgi-ip22/ip22-timer.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/sgi-ip22/ip22-timer.c Sat May 26 01:24:28 2001 @@ -34,6 +34,11 @@ extern rwlock_t xtime_lock; +static inline int abs(int i) +{ + return (i < 0) ? -i : i; +} + static inline void ack_r4ktimer(unsigned long newval) { write_32bit_cp0_register(CP0_COMPARE, newval); @@ -122,32 +127,30 @@ static unsigned long dosample(volatile unsigned char *tcwp, volatile unsigned char *tc2p) { - unsigned long ct0, ct1; - unsigned char msb, lsb; + unsigned int ct = 0; + volatile unsigned char msb, lsb; /* Start the counter. */ - *tcwp = (SGINT_TCWORD_CNT2 | SGINT_TCWORD_CALL | SGINT_TCWORD_MRGEN); - *tc2p = (SGINT_TCSAMP_COUNTER & 0xff); - *tc2p = (SGINT_TCSAMP_COUNTER >> 8); + *tcwp = SGINT_TCWORD_CNT2 | SGINT_TCWORD_CALL | SGINT_TCWORD_MRGEN; + *tc2p = SGINT_TCSAMP_COUNTER & 0xff; + *tc2p = (SGINT_TCSAMP_COUNTER >> 8) & 0xff; - /* Get initial counter invariant */ - ct0 = read_32bit_cp0_register(CP0_COUNT); + /* Set initial counter invariant to zero to avoid overflow hassle. */ + write_32bit_cp0_register(CP0_COUNT, ct); /* Latch and spin until top byte of counter2 is zero */ do { - *tcwp = (SGINT_TCWORD_CNT2 | SGINT_TCWORD_CLAT); + *tcwp = SGINT_TCWORD_CNT2 | SGINT_TCWORD_CLAT; lsb = *tc2p; msb = *tc2p; - ct1 = read_32bit_cp0_register(CP0_COUNT); + ct = read_32bit_cp0_register(CP0_COUNT); } while(msb); /* Stop the counter. */ - *tcwp = (SGINT_TCWORD_CNT2 | SGINT_TCWORD_CALL | SGINT_TCWORD_MSWST); + *tcwp = SGINT_TCWORD_CNT2 | SGINT_TCWORD_CALL | SGINT_TCWORD_MSWST; - /* Return the difference, this is how far the r4k counter increments - * for every one HZ. - */ - return ct1 - ct0; + /* Return how far the r4k counter increments for every one HZ. */ + return ct; } static unsigned long __init get_indy_time(void) @@ -219,7 +222,7 @@ printk("%08lx(%d)\n", r4k_offset, (int) r4k_offset); - r4k_cur = (read_32bit_cp0_register(CP0_COUNT) + r4k_offset); + r4k_cur = read_32bit_cp0_register(CP0_COUNT) + r4k_offset; write_32bit_cp0_register(CP0_COMPARE, r4k_cur); set_cp0_status(ST0_IM, ALLINTS); sti(); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/sgi-ip22/system.c linux/arch/mips64/sgi-ip22/system.c --- linux-orig/arch/mips64/sgi-ip22/system.c Tue Mar 20 00:02:37 2001 +++ linux/arch/mips64/sgi-ip22/system.c Sat May 26 01:24:28 2001 @@ -33,10 +33,12 @@ { "MIPS-R4600", CPU_R4600 }, { "MIPS-R8000", CPU_R8000 }, { "MIPS-R5000", CPU_R5000 }, - { "MIPS-R5000A", CPU_R5000A } + { "MIPS-R5000A", CPU_R5000A }, + { "MIPS-R10000", CPU_R10000 }, + { "MIPS-R12000", CPU_R12000 } }; -#define NUM_CPUS 9 /* for now */ +static const int NUM_CPUS = sizeof(sgi_cputable) / sizeof(struct smatch); static int __init string_to_cpu(char *s) { diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/tools/Makefile linux/arch/mips64/tools/Makefile --- linux-orig/arch/mips64/tools/Makefile Fri Feb 9 19:38:54 2001 +++ linux/arch/mips64/tools/Makefile Sat May 26 01:24:28 2001 @@ -23,8 +23,7 @@ clean: rm -f offset.[hs] $(TARGET).new -mrproper: - rm -f offset.[hs] $(TARGET).new +mrproper: clean rm -f $(TARGET) include $(TOPDIR)/Rules.make diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/drivers/char/tty_io.c linux/drivers/char/tty_io.c --- linux-orig/drivers/char/tty_io.c Sun May 6 17:28:52 2001 +++ linux/drivers/char/tty_io.c Sat May 26 01:24:28 2001 @@ -156,6 +156,7 @@ extern void sci_console_init(void); extern void tx3912_console_init(void); extern void tx3912_rs_init(void); +extern void arc_console_init(void); #ifndef MIN #define MIN(a,b) ((a) < (b) ? (a) : (b)) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/drivers/sgi/char/sgiserial.c linux/drivers/sgi/char/sgiserial.c --- linux-orig/drivers/sgi/char/sgiserial.c Tue Mar 20 00:03:16 2001 +++ linux/drivers/sgi/char/sgiserial.c Sat May 26 01:24:29 2001 @@ -137,7 +137,7 @@ * buffer across all the serial ports, since it significantly saves * memory if large numbers of serial ports are open. */ -static unsigned char tmp_buf[4096]; /* This is cheating */ +static unsigned char tmp_buf[PAGE_SIZE]; /* This is cheating */ static DECLARE_MUTEX(tmp_buf_sem); static inline int serial_paranoia_check(struct sgi_serial *info, @@ -785,8 +785,8 @@ */ static void change_speed(struct sgi_serial *info) { - unsigned short port; - unsigned cflag; + unsigned int port; + unsigned int cflag; int i; int brg; @@ -1982,7 +1982,8 @@ for(info=zs_chain, i=0; info; info = info->zs_next, i++) { info->magic = SERIAL_MAGIC; - info->port = (int) info->zs_channel; + /* This hopefully lives always in 32bit space. */ + info->port = (unsigned int) (unsigned long) info->zs_channel; info->line = i; info->tty = 0; info->irq = zilog_irq; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/drivers/sgi/char/sgiserial.h linux/drivers/sgi/char/sgiserial.h --- linux-orig/drivers/sgi/char/sgiserial.h Sun Oct 15 14:57:35 2000 +++ linux/drivers/sgi/char/sgiserial.h Sat May 26 01:24:29 2001 @@ -33,7 +33,7 @@ struct serial_struct { int type; int line; - int port; + unsigned int port; int irq; int flags; int xmit_fifo_size; @@ -129,7 +129,7 @@ int magic; int baud_base; - int port; + unsigned int port; int irq; int flags; /* defined in tty.h */ int type; /* UART type */ @@ -166,9 +166,9 @@ #define SERIAL_MAGIC 0x5301 /* - * The size of the serial xmit buffer is 1 page, or 4096 bytes + * The size of the serial xmit buffer is 1 page */ -#define SERIAL_XMIT_SIZE 4096 +#define SERIAL_XMIT_SIZE PAGE_SIZE /* * Events are used to schedule things to happen at timer-interrupt diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/bootinfo.h linux/include/asm-mips64/bootinfo.h --- linux-orig/include/asm-mips64/bootinfo.h Sat May 26 00:25:54 2001 +++ linux/include/asm-mips64/bootinfo.h Sat May 26 01:35:01 2001 @@ -134,13 +134,14 @@ #define CPU_R5000A 25 #define CPU_R4640 26 #define CPU_NEVADA 27 /* RM5230, RM5260 */ -#define CPU_LAST 27 +#define CPU_R12000 28 +#define CPU_LAST 28 #define CPU_NAMES { "unknown", "R2000", "R3000", "R3000A", "R3041", "R3051", \ "R3052", "R3081", "R3081E", "R4000PC", "R4000SC", "R4000MC", \ "R4200", "R4400PC", "R4400SC", "R4400MC", "R4600", "R6000", \ "R6000A", "R8000", "R10000", "R4300", "R4650", "R4700", "R5000", \ - "R5000A", "R4640", "Nevada" } + "R5000A", "R4640", "Nevada", "R12000" } #define CL_SIZE (80) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/pgtable.h linux/include/asm-mips64/pgtable.h --- linux-orig/include/asm-mips64/pgtable.h Wed May 23 21:12:25 2001 +++ linux/include/asm-mips64/pgtable.h Sat May 26 02:16:29 2001 @@ -69,7 +69,8 @@ #define flush_icache_page(vma, page) \ do { \ if ((vma)->vm_flags & VM_EXEC) \ - andes_flush_icache_page(page_address(page)); \ + andes_flush_icache_page( \ + (unsigned long)page_address(page)); \ } while (0) #endif /* !CONFIG_CPU_R10000 */ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgi/sgihpc.h linux/include/asm-mips64/sgi/sgihpc.h --- linux-orig/include/asm-mips64/sgi/sgihpc.h Sat Dec 4 04:59:13 1999 +++ linux/include/asm-mips64/sgi/sgihpc.h Sat May 26 02:17:25 2001 @@ -334,8 +334,6 @@ /* We need software copies of these because they are write only. */ extern unsigned int sgi_hpc_write1, sgi_hpc_write2; -#define SGI_KEYBOARD_IRQ 20 - struct hpc_keyb { #ifdef __MIPSEB__ unsigned char _unused0[3]; diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgi/sgint23.h linux/include/asm-mips64/sgi/sgint23.h --- linux-orig/include/asm-mips64/sgi/sgint23.h Sat May 26 00:25:54 2001 +++ linux/include/asm-mips64/sgi/sgint23.h Sat May 26 01:35:44 2001 @@ -199,7 +199,6 @@ extern struct sgi_ioc_timers *ioc_timers; extern volatile unsigned char *ioc_tclear; -extern void sgint_init(void); extern void indy_timer_init(void); #endif /* _ASM_SGI_SGINT23_H */ diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgialib.h linux/include/asm-mips64/sgialib.h --- linux-orig/include/asm-mips64/sgialib.h Sat May 26 00:25:54 2001 +++ linux/include/asm-mips64/sgialib.h Sat May 26 02:16:52 2001 @@ -13,7 +13,6 @@ #include -extern PSYSTEM_PARAMETER_BLOCK sgi_pblock; extern struct linux_romvec *romvec; extern int prom_argc; From owner-linux-mips@oss.sgi.com Wed May 30 07:53:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UErRn30075 for linux-mips-outgoing; Wed, 30 May 2001 07:53:27 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UErPh30072 for ; Wed, 30 May 2001 07:53:25 -0700 Received: from thor ([207.246.91.243]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id HAA01791 for ; Wed, 30 May 2001 07:53:19 -0700 (PDT) mail_from (jsk@tetracon-eng.net) Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10025 for ; Wed, 30 May 2001 10:48:58 -0400 Date: Wed, 30 May 2001 10:48:58 -0400 From: "J. Scott Kasten" To: Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <200105291545.IAA13454@saturn.mikemac.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 271 Lines: 7 > >All the cases I've seen have been for 32-bit kernels. A 64-bit PDA kernel seems like a wee tiny bit of overkill > > I've been asked about running 64 bit binaries on a VR4121. Unless you're doing encryption in an embedded device, then 64 bit regs are quite nice... From owner-linux-mips@oss.sgi.com Wed May 30 08:06:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UF6OR30527 for linux-mips-outgoing; Wed, 30 May 2001 08:06:24 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UF6Kh30520 for ; Wed, 30 May 2001 08:06:20 -0700 Received: from thor ([207.246.91.243]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA03361 for ; Wed, 30 May 2001 08:06:19 -0700 (PDT) mail_from (jsk@tetracon-eng.net) Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10072 for ; Wed, 30 May 2001 11:02:22 -0400 Date: Wed, 30 May 2001 11:02:22 -0400 From: "J. Scott Kasten" To: Subject: Pthreads. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 361 Lines: 16 If I recall correctly, some time ago, Jun Sun was looking at pthreads. What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips? I.E. works, broken, how bad, to do??? Thanks. -- J. Scott Kasten Email: jsk AT tetracon-eng DOT net "Nearly all men can stand adversity, but if you want to test a man's charater, give him power. - A Lincoln" From owner-linux-mips@oss.sgi.com Wed May 30 09:15:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UGF0J00600 for linux-mips-outgoing; Wed, 30 May 2001 09:15:00 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UGEuh00597 for ; Wed, 30 May 2001 09:14:56 -0700 Received: (qmail 7976 invoked by uid 502); 30 May 2001 16:14:50 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: linux-mips@oss.sgi.com Subject: Toolchain patches Date: Wed, 30 May 2001 09:14:43 -0700 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01053009144307.01259@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1330 Lines: 28 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey people. As we all well know, toolchain is one of major issues for Linux/MIPS. Probably the worst one. Personally I had just gone through getting it at least semi-straight, and blood, sweat, tears, and peaces of raw flesh are still lying arround. I don't think I'd like my enemies to go through this. Now, one of the reasons for this is that maintainers of some important tools (like gcc :-) are little bit too concentrated on Inhell architecture. They do not apply our patches, they do not fix bugs reported by us, and in general hurt our feelings :). Of course we could start maintaining our own trees for respective tools, but unfortunately we simply do not have manpower right now for that (and many people would give lots of other good arguments against this). So, I decided to put together at least a page with collection of patches to toolchain, that didn't go into tree to make life at least a bit easier. Send comments, patches, and anything else, you see appropriate to me. I hope to get initial page up in couple of days. Ilya. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsVHHoACgkQtKh84cA8u2k+rQCeLHzpSVBroqru0g95cyo5uJbB askAnRmYdw28hSC06Sp/aYk1AbbTJzCX =a6hH -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Wed May 30 10:13:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UHDi705113 for linux-mips-outgoing; Wed, 30 May 2001 10:13:44 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHDeh05104 for ; Wed, 30 May 2001 10:13:41 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id SAA185634 for ; Wed, 30 May 2001 18:43:46 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15594U-0004Io-00 for ; Wed, 30 May 2001 18:43:46 +0200 Date: Wed, 30 May 2001 18:43:46 +0200 To: linux-mips@oss.sgi.com Subject: Re: Toolchain patches Message-ID: <20010530184346.A16307@rembrandt.csv.ica.uni-stuttgart.de> References: <01053009144307.01259@gateway> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <01053009144307.01259@gateway>; from ilya@theIlya.com on Wed, May 30, 2001 at 09:14:43AM -0700 From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 389 Lines: 11 Ilya Volynets wrote: [snip] >Now, one of the reasons for this is that maintainers of some important >tools (like gcc :-) are little bit too concentrated on Inhell architecture. >They do not apply our patches, they do not fix bugs reported by us, I don't know about gcc, but with binutils I haven't such problems so far. Which of Your patches were rejected (and for what reason)? Thiemo From owner-linux-mips@oss.sgi.com Wed May 30 10:31:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UHVsH07113 for linux-mips-outgoing; Wed, 30 May 2001 10:31:54 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHVph07107 for ; Wed, 30 May 2001 10:31:51 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4UHVi022119; Wed, 30 May 2001 10:31:44 -0700 Message-ID: <3B152E51.ACF145BE@mvista.com> Date: Wed, 30 May 2001 10:30:57 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "J. Scott Kasten" CC: linux-mips@oss.sgi.com Subject: Re: Pthreads. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 451 Lines: 14 "J. Scott Kasten" wrote: > > If I recall correctly, some time ago, Jun Sun was looking at pthreads. > What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips? > I.E. works, broken, how bad, to do??? > I found a bug in the kernel that causes register corruption, which causes pthread to fail. The bug has been fixed for a while in the CVS tree. I don't recall any glibc specific patches. Yes, it runs fine on my machines. Jun From owner-linux-mips@oss.sgi.com Wed May 30 10:37:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UHbtU07613 for linux-mips-outgoing; Wed, 30 May 2001 10:37:55 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHboh07610 for ; Wed, 30 May 2001 10:37:50 -0700 Received: (qmail 925 invoked by uid 502); 30 May 2001 17:37:49 -0000 Content-Type: text/plain; charset="koi8-u" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: linux-mips@oss.sgi.com Subject: Re: Toolchain patches Date: Wed, 30 May 2001 10:37:46 -0700 X-Mailer: KMail [version 1.2] References: <01053009144307.01259@gateway> <20010530184346.A16307@rembrandt.csv.ica.uni-stuttgart.de> In-Reply-To: <20010530184346.A16307@rembrandt.csv.ica.uni-stuttgart.de> MIME-Version: 1.0 Message-Id: <01053010374600.00826@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1008 Lines: 26 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 30 May 2001 09:43, Thiemo Seufer wrote: > Ilya Volynets wrote: > [snip] > >Now, one of the reasons for this is that maintainers of some important > >tools (like gcc :-) are little bit too concentrated on Inhell architecture. > >They do not apply our patches, they do not fix bugs reported by us, > > I don't know about gcc, but with binutils I haven't such problems > so far. That's why I didn't mention them. GCC is my primary concern now. > Which of Your patches were rejected (and for what reason)? I'm not talking about myself, but if you mention it to Keith, for example, you'll hear a lot of loud sound :). In general I think collecting stuff that floats around into one central place will be useful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsVL+0ACgkQtKh84cA8u2lAKgCfXYgHdrJ3APYKr8vuZhAFQ9N7 fDMAoNv5rpUtkE5iZ1wMqCTjVGjjdbyR =gik0 -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Wed May 30 10:41:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UHf5X07904 for linux-mips-outgoing; Wed, 30 May 2001 10:41:05 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHf1h07897 for ; Wed, 30 May 2001 10:41:01 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4UHef022710; Wed, 30 May 2001 10:40:41 -0700 Message-ID: <3B15306A.3AACAF3E@mvista.com> Date: Wed, 30 May 2001 10:39:54 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Joe deBlaquiere , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 955 Lines: 26 "Maciej W. Rozycki" wrote: > > On Tue, 29 May 2001, Jun Sun wrote: > > > > What about 3) -- a new syscall with a different semantics and no need to > > > care about limitations of current implementations (especially the > > > sysmips() bag). > > > > Having a new syscall is fine with me, although seems a little more instrusive > > than adding a subcall to sysmips(). > > Actually whole sysmips() looks like a crazy hack, much like ioctl(), but > even worse (passing a pointer in an integer argument, even if it works... > yuck!). And it is weird, to say at least, to have different > interpretations of the return value -- sometimes it's errno and sometimes > it's something different. > Agree. Having dual semantics for the return value is bad. I was actually suggesting to have a new subcall in sysmips (e.g., MIPS_NEW_ATOMIC_SET) and still working within the sysmips() call framework. Is there any concern as for adding a new syscall? Jun From owner-linux-mips@oss.sgi.com Wed May 30 10:56:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UHum109881 for linux-mips-outgoing; Wed, 30 May 2001 10:56:48 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHuih09871 for ; Wed, 30 May 2001 10:56:44 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4UHtc023885; Wed, 30 May 2001 10:55:38 -0700 Message-ID: <3B1533EB.924ACA05@mvista.com> Date: Wed, 30 May 2001 10:54:51 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1104 Lines: 31 "Maciej W. Rozycki" wrote: > > On Tue, 29 May 2001, Jun Sun wrote: > > > I think system V requires _test_and_set() being included in the libsys dynamic > > library. Does Linux want to be sysv compatible? If so, we should removed the > > inlined _test_and_set(). > > Why should we remove the inlined _test_and_set()? We do have a number of > other inlined functions in glibc, e.g. memcpy() and friends in > (not for MIPS, actually, but for other hosts), yet it does > not make glibc SVR4 incompatible. Of course we always provide non-inlined > versions of such functions as well -- check with objdump if unsure. > Hmm, I think to write SYSV compatible code one should not used inlined ABI calls. Otherwise the binary would bypass libsys and becomes not portable among SYSV machines. On the other hand, what other MIPS SYSV platforms are there for us to be compatible? IRIX? :-) > Note they are *extern* inline. > I don't think "extern" changes the picture here because once the call is inlined the code will bypass libsys - unless my previous understanding is wrong. Jun From owner-linux-mips@oss.sgi.com Wed May 30 11:39:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UIdaD12700 for linux-mips-outgoing; Wed, 30 May 2001 11:39:36 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UIdWh12697 for ; Wed, 30 May 2001 11:39:32 -0700 Received: from thor ([207.246.91.243]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id LAA09986 for ; Wed, 30 May 2001 11:39:30 -0700 (PDT) mail_from (jsk@tetracon-eng.net) Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA11379; Wed, 30 May 2001 14:34:41 -0400 Date: Wed, 30 May 2001 14:34:41 -0400 From: "J. Scott Kasten" To: Jun Sun cc: Subject: Re: Pthreads. In-Reply-To: <3B152E51.ACF145BE@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 721 Lines: 27 On Wed, 30 May 2001, Jun Sun wrote: > "J. Scott Kasten" wrote: > > > > If I recall correctly, some time ago, Jun Sun was looking at pthreads. > > What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips? > > I.E. works, broken, how bad, to do??? > > > > I found a bug in the kernel that causes register corruption, which causes > pthread to fail. The bug has been fixed for a while in the CVS tree. I don't > recall any glibc specific patches. If I recall correctly, that was S0 not being preserved under certain system calls. Which I have taken care of. > > Yes, it runs fine on my machines. > > Jun > When you say runs fine, do you mean the 2.0.x, the 2.2.x or both? Thanks for your response. From owner-linux-mips@oss.sgi.com Wed May 30 12:38:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UJcim16133 for linux-mips-outgoing; Wed, 30 May 2001 12:38:44 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UJceh16128 for ; Wed, 30 May 2001 12:38:40 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4UIxH028029; Wed, 30 May 2001 11:59:17 -0700 Message-ID: <3B1542D5.7D74C295@mvista.com> Date: Wed, 30 May 2001 11:58:29 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "J. Scott Kasten" CC: linux-mips@oss.sgi.com Subject: Re: Pthreads. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 930 Lines: 32 "J. Scott Kasten" wrote: > > On Wed, 30 May 2001, Jun Sun wrote: > > > "J. Scott Kasten" wrote: > > > > > > If I recall correctly, some time ago, Jun Sun was looking at pthreads. > > > What is the status of threads in glibc-2.0.6/.7 and glibc-2.2.x for mips? > > > I.E. works, broken, how bad, to do??? > > > > > > > I found a bug in the kernel that causes register corruption, which causes > > pthread to fail. The bug has been fixed for a while in the CVS tree. I don't > > recall any glibc specific patches. > > If I recall correctly, that was S0 not being preserved under certain > system calls. Which I have taken care of. > > > > > Yes, it runs fine on my machines. > > > > Jun > > > > When you say runs fine, do you mean the 2.0.x, the 2.2.x or both? > > Thanks for your response. Both. There are some bug fixes needed to the get the new glibc 2.2.x working. Once the fixes are settled, we will post them. Jun From owner-linux-mips@oss.sgi.com Wed May 30 15:50:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UMo6B22614 for linux-mips-outgoing; Wed, 30 May 2001 15:50:06 -0700 Received: from mail.palmchip.com ([63.203.52.8]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UMo1h22611 for ; Wed, 30 May 2001 15:50:02 -0700 Received: from palmchip.com (sabretooth.palmchip.com [10.1.10.110]) by mail.palmchip.com (8.11.0/8.9.3) with ESMTP id f4UMnuc16798 for ; Wed, 30 May 2001 15:49:56 -0700 Message-ID: <3B157A53.5728029@palmchip.com> Date: Wed, 30 May 2001 15:55:15 -0700 From: Ian Thompson Organization: Palmchip Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: ramdisk funkiness Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1314 Lines: 32 Hi, I'm porting the 2.4 kernel to a custom board, and I'm running into some trouble while trying to mount the root filesystem. There is no media (hard drives, cdrom drives, etc) attached to the system, but of course the kernel needs a root filesystem to boot. So, I'm trying to create an empty ramdisk and have the kernel mount that as the root fs. The kernel installs the ramdisk driver fine, but when it tries to open the ramdisk, I get this error message: RAMDISK driver initialized: 16 RAM disks of 128K size 1024 blocksize VFS: Cannot open root device "ram0" or 01:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 01:00 Now for some possible complications: I'm not using LILO as of yet. I've written a custom bootloader, and one of the arguments I pass to the kernel is "root=/dev/ram0" as it says to do in Documentation/initrd.txt. So my question is: what other setup am I skipping? I'd rather not have to store a ramdisk image in ROM, but I'm guessing I'll run into problems just creating an empty one. What else do I need to do to get VFS to open the device correctly? Thanks, -ian -- ---------------------------------------- Ian Thompson tel: 408.952.2023 Firmware Engineer fax: 408.570.0910 Palmchip Corporation www.palmchip.com From owner-linux-mips@oss.sgi.com Wed May 30 16:18:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UNICc23521 for linux-mips-outgoing; Wed, 30 May 2001 16:18:12 -0700 Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UNI8h23515 for ; Wed, 30 May 2001 16:18:08 -0700 Received: from murphy.dk (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4UNHwbo021819 for ; Thu, 31 May 2001 01:18:00 +0200 Message-ID: <3B157FA4.ECCFEC76@murphy.dk> Date: Thu, 31 May 2001 01:17:56 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-mips@oss.sgi.com Subject: Re: ramdisk funkiness References: <3B157A53.5728029@palmchip.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 775 Lines: 22 Ian Thompson wrote: > Hi, > > I'm porting the 2.4 kernel to a custom board, and I'm running into some > trouble while trying to mount the root filesystem. There is no media > (hard drives, cdrom drives, etc) attached to the system, but of course > the kernel needs a root filesystem to boot. So, I'm trying to create an > empty ramdisk and have the kernel mount that as the root fs. The kernel > installs the ramdisk driver fine, but when it tries to open the ramdisk, > I get this error message: > > RAMDISK driver initialized: 16 RAM disks of 128K size 1024 blocksize > VFS: Cannot open root device "ram0" or 01:00 > Please append a correct "root=" boot option > Kernel panic: VFS: Unable to mount root fs on 01:00 > Have you got a filesystem on the ramdisk? /Brian From owner-linux-mips@oss.sgi.com Wed May 30 17:21:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4V0LhQ24770 for linux-mips-outgoing; Wed, 30 May 2001 17:21:43 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V0Lbh24767 for ; Wed, 30 May 2001 17:21:37 -0700 Received: (qmail 5478 invoked by uid 502); 31 May 2001 00:21:36 -0000 Content-Type: text/plain; charset="koi8-u" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Ian Thompson Subject: Re: ramdisk funkiness Date: Wed, 30 May 2001 17:21:33 -0700 X-Mailer: KMail [version 1.2] References: <3B157A53.5728029@palmchip.com> <01053016114302.00826@gateway> <3B158C4A.98CB5C26@palmchip.com> In-Reply-To: <3B158C4A.98CB5C26@palmchip.com> Cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Message-Id: <01053017213300.05410@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3464 Lines: 84 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 30 May 2001 17:11, you wrote: > Do I simply need to compile my kernel with ext2 support enabled, or do I > need to somehow create a ramdisk image with that type of a format? Yes, you need ramdisk with filesystem on it. > If > you don't mind, could you explain a little about how I can go about > pointing the kernel at a ramdisk image, assuming I don't have LILO to > help me out? LILO doesn't matter here, problem is that you don't have filesystem at all. What good is linux kernel, if it can't run any programs? In short to create ramdisk with filesystem on it, create file of needed size, use mke2fs to make filesystem on it, then use loopback device to mount it, and put files in there. Once you've done it, look at ramdisk HOWTO for instructions on where to put resulting image. Bootdisk HOWTO might also be helpfull. And YES, you will need to put ramdisk in ROM (unnless you can download it from network, in which case you don't need ramdisk anyways - -- use NFS). BTW, it doesn't really have to be ext2fs, it could be any other fs (like ROMFS or RAMFS) You just need support for it comiled into your kernel. > thanks for your help! > > Ilya Volynets wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > At minimum you have to have ext2 fs on your ramdisk. init of some kind is > > probably also something you want :) > > > > On Wednesday 30 May 2001 15:55, you wrote: > > > Hi, > > > > > > I'm porting the 2.4 kernel to a custom board, and I'm running into some > > > trouble while trying to mount the root filesystem. There is no media > > > (hard drives, cdrom drives, etc) attached to the system, but of course > > > the kernel needs a root filesystem to boot. So, I'm trying to create > > > an empty ramdisk and have the kernel mount that as the root fs. The > > > kernel installs the ramdisk driver fine, but when it tries to open the > > > ramdisk, I get this error message: > > > > > > RAMDISK driver initialized: 16 RAM disks of 128K size 1024 blocksize > > > VFS: Cannot open root device "ram0" or 01:00 > > > Please append a correct "root=" boot option > > > Kernel panic: VFS: Unable to mount root fs on 01:00 > > > > > > Now for some possible complications: I'm not using LILO as of yet. > > > I've written a custom bootloader, and one of the arguments I pass to > > > the kernel is "root=/dev/ram0" as it says to do in > > > Documentation/initrd.txt. So my question is: what other setup am I > > > skipping? I'd rather not have to store a ramdisk image in ROM, but I'm > > > guessing I'll run into problems just creating an empty one. What else > > > do I need to do to get VFS to open the device correctly? > > > > > > Thanks, > > > -ian > > > > > > -- > > > ---------------------------------------- > > > Ian Thompson tel: 408.952.2023 > > > Firmware Engineer fax: 408.570.0910 > > > Palmchip Corporation www.palmchip.com > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.0.4 (GNU/Linux) > > Comment: For info see http://www.gnupg.org > > > > iEYEARECAAYFAjsVfjIACgkQtKh84cA8u2ldHgCgt7l1wtJPlPQXh0dgCR6ctP9r > > noUAoMRAbSqIjwoiU1jEz23vpOlgD0ZX > > =GGkM > > -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsVjpAACgkQtKh84cA8u2kLHgCffusU/629H1ChSPMvGGVlliuu 0pIAoMTgAL/suL87rW6q0NoaKrh7WRKk =Cypj -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Wed May 30 18:07:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4V17t225925 for linux-mips-outgoing; Wed, 30 May 2001 18:07:55 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V17oh25922 for ; Wed, 30 May 2001 18:07:50 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA09195 for ; Wed, 30 May 2001 17:42:16 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4V0g9018348; Wed, 30 May 2001 17:42:09 -0700 Message-ID: <3B159331.CC353580@mvista.com> Date: Wed, 30 May 2001 17:41:21 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ian Thompson CC: linux-mips@oss.sgi.com Subject: Re: ramdisk funkiness References: <3B157A53.5728029@palmchip.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 903 Lines: 24 Ian Thompson wrote: > > Hi, > > I'm porting the 2.4 kernel to a custom board, and I'm running into some > trouble while trying to mount the root filesystem. There is no media > (hard drives, cdrom drives, etc) attached to the system, but of course > the kernel needs a root filesystem to boot. So, I'm trying to create an > empty ramdisk and have the kernel mount that as the root fs. The kernel > installs the ramdisk driver fine, but when it tries to open the ramdisk, > I get this error message: > > RAMDISK driver initialized: 16 RAM disks of 128K size 1024 blocksize > VFS: Cannot open root device "ram0" or 01:00 > Please append a correct "root=" boot option > Kernel panic: VFS: Unable to mount root fs on 01:00 > You don't need to supply "root=/dev/ram0" argument as long as you give the configure in the following option: Initial RAM disk (initrd) support (CONFIG_BLK_DEV_INITRD) Jun From owner-linux-mips@oss.sgi.com Wed May 30 20:26:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4V3Q2P28397 for linux-mips-outgoing; Wed, 30 May 2001 20:26:02 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V3Pkh28394 for ; Wed, 30 May 2001 20:25:47 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA03643 for ; Wed, 30 May 2001 20:25:44 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA21204; Wed, 30 May 2001 19:58:44 +0200 (MET DST) Date: Wed, 30 May 2001 19:58:43 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Andreas Jaeger , Jun Sun Subject: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8886 Lines: 270 Hi, Here is the second version of the sys__test_and_set() syscall suite. A glibc patch is included this time as well. There are two small changes to the sys__test_and_set() implementation: 1. verify_area() is now called for the ll/sc version as well. Otherwise one could pass a KSEG address and gain unauthorized access. 2. The fuction now returns immediately without performing a write access if the value stored in the memory wouldn't change. This is to avoid the need of a potentially costful sc operation; for consistency, this is also done for the non-ll/sc version. The glibc patch should be fairly obvious. There is no inline version of the _test_and_set() function for MIPS I anymore -- while previously it saved an extra stack frame just to call sysmips(), this would be pointless now (well, not quite as long as we fallback to sysmips(), actually, but that is a temporary compatibility bit that will soon get removed, I hope). Note that while sys__test_and_set() never returns an error, there might one happen if someone tries to execute the syscall running a kernel that does not support it. Hence we fall back to sysmips(). The official entry point is _test_and_set(). There is also the ___test_and_set() entry point defined, mostly for completeness for MIPS II+ systems, to be sure all syscalls actually have their wrappers exported. Not to be used under normal circumstances, though. Andreas, what do you think: Should we fall back to sysmips() as in the following patch (at a considerable performance hit -- without the fallback the entire ___test_and_set() wrapper is seven instructions long) or just require a specific minimum kernel version bail out at the compile time if no __NR__test_and_set is defined? Granted, pthreads don't run for MIPS/Linux for a long time, so it's possible the user base is not that large such an abrupt switch would be impossible. Especially as sysmips() seems to be continuously in flux for the last few months. I assume the switch to the new syscall would be mandatory for glibc 2.3 in any case. I'm open to constructive feedback. An open question is whether returning the result in v1 is clean. I believe it is -- I haven't been convinced that storing the result in a memory location passed as the third argument is cleaner. Certainly it's not faster and v1 is still dedicated to be a result register. It's used by sys_pipe() this way, for example. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.0-test12-20010110-tas-12 diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscall.c linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscall.c --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscall.c Sun Oct 29 05:26:54 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscall.c Wed May 30 13:01:00 2001 @@ -174,6 +174,90 @@ asmlinkage int sys_olduname(struct oldol return error; } +/* Note: errno is always zero and the result is in v1. */ +asmlinkage int sys__test_and_set(struct pt_regs regs) +{ + int *ptr, val, ret, err, tmp; + + ptr = (int *)(regs.regs[4]); + val = (int)(regs.regs[5]); + + /* Don't emulate unaligned accesses. */ + if ((int)ptr & 3) + goto fault; + + /* A zero here saves us three instructions. */ + err = verify_area(VERIFY_WRITE, ptr, 0); + if (err) + goto fault; + +#ifdef CONFIG_CPU_HAS_LLSC + __asm__(".set mips2\n\t" + "1:\n\t" + "ll %0,%5\n\t" + ".set push\n\t" + ".set noreorder\n\t" + "beq %0,%4,3f\n\t" + " move %3,%4\n" + ".set pop\n\t" + "2:\n\t" + "sc %3,%1\n\t" + "beqz %3,1b\n\t" + "3:\n\t" + ".set mips0\n\t" + ".section .fixup,\"ax\"\n" + "4:\n\t" + "li %2,%7\n\t" + "j 3b\n\t" + ".previous\n\t" + ".section __ex_table,\"a\"\n\t" + ".word 1b,4b\n\t" + ".word 2b,4b\n\t" + ".previous" + : "=&r" (ret), "=R" (*ptr), "=r" (err), "=&r" (tmp) + : "r" (val), "1" (*ptr), "2" (0), "i" (-EFAULT)); +#else + save_and_cli(tmp); + err = __get_user(ret, ptr); + if (ret != val) + err |= __put_user(val, ptr); /* No fault + unless unwriteable. */ + restore_flags(tmp); +#endif + + if (err) + goto fault; + + (int)(regs.regs[3]) = ret; + + return 0; + +fault: + regs.cp0_epc -= 4; /* Go back to SYSCALL. */ + + { + struct siginfo info; + + + if ((int)ptr & 3) { + info.si_signo = SIGBUS; + info.si_code = BUS_ADRALN; + } else { + info.si_signo = SIGSEGV; + if (verify_area(VERIFY_WRITE, ptr, 0)) + info.si_code = SEGV_ACCERR; + else + info.si_code = SEGV_MAPERR; + } + info.si_errno = 0; + info.si_addr = (void *)regs.cp0_epc; + + force_sig_info(info.si_signo, &info, current); + } + + return 0; +} + /* * Do the indirect syscall syscall. * Don't care about kernel locking; the actual syscall will do it. diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscalls.h linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscalls.h --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscalls.h Wed Nov 8 05:26:57 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscalls.h Wed May 23 23:59:02 2001 @@ -235,3 +235,4 @@ SYS(sys_mincore, 3) SYS(sys_madvise, 3) SYS(sys_getdents64, 3) SYS(sys_fcntl64, 3) /* 4220 */ +SYS(sys__test_and_set, 0) diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/unistd.h linux-mips-2.4.0-test12-20010110/include/asm-mips/unistd.h --- linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/unistd.h Thu Oct 26 04:27:09 2000 +++ linux-mips-2.4.0-test12-20010110/include/asm-mips/unistd.h Wed May 23 23:09:00 2001 @@ -233,11 +233,12 @@ #define __NR_madvise (__NR_Linux + 218) #define __NR_getdents64 (__NR_Linux + 219) #define __NR_fcntl64 (__NR_Linux + 220) +#define __NR__test_and_set (__NR_Linux + 221) /* * Offset of the last Linux flavoured syscall */ -#define __NR_Linux_syscalls 220 +#define __NR_Linux_syscalls 221 #ifndef _LANGUAGE_ASSEMBLY glibc-2.2.3-mips-tas.patch diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/Versions glibc-2.2.3/sysdeps/unix/sysv/linux/mips/Versions --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/Versions Wed Aug 2 21:53:16 2000 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/Versions Wed May 30 02:20:28 2001 @@ -16,6 +16,6 @@ libc { } GLIBC_2.2 { # _* - _test_and_set; + _test_and_set; ___test_and_set; } } diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c Fri Jul 28 13:37:25 2000 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c Wed May 30 12:05:33 2001 @@ -21,10 +21,47 @@ defined in sys/tas.h */ #include +#include +#include +#include +#include #define _EXTERN_INLINE #ifndef __USE_EXTERN_INLINES # define __USE_EXTERN_INLINES 1 #endif +#ifdef __NR__test_and_set +#define __HAVE__TEST_AND_SET 1 +#else +#define __HAVE__TEST_AND_SET 0 +#endif + #include "sys/tas.h" + +int ___test_and_set (int *p, int v) +{ + if (__HAVE__TEST_AND_SET) + { + register int *__p asm ("$4") = p; + register int __v asm ("$5") = v; + register int __n asm ("$2") = SYS_ify (_test_and_set); + register int __e asm ("$7"); + register int __r asm ("$3"); + + asm + ("syscall" + : "=r" (__r), "=r" (__e) + : "r" (__p), "r" (__v), "r" (__n) + : "$2", + "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", + "memory"); + if (!__e) + return __r; + } + return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); +} + +#if (_MIPS_ISA < _MIPS_ISA_MIPS2) +strong_alias (___test_and_set, _test_and_set) +#endif diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h Sun Jan 7 04:35:41 2001 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h Wed May 30 02:18:19 2001 @@ -22,11 +22,11 @@ #include #include -#include __BEGIN_DECLS extern int _test_and_set (int *p, int v) __THROW; +extern int ___test_and_set (int *p, int v) __THROW; #ifdef __USE_EXTERN_INLINES @@ -59,15 +59,7 @@ _test_and_set (int *p, int v) __THROW return r; } -# else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - -_EXTERN_INLINE int -_test_and_set (int *p, int v) __THROW -{ - return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); -} - -# endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +# endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ #endif /* __USE_EXTERN_INLINES */ From owner-linux-mips@oss.sgi.com Wed May 30 20:29:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4V3TH028532 for linux-mips-outgoing; Wed, 30 May 2001 20:29:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V3TEh28524 for ; Wed, 30 May 2001 20:29:14 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA02693 for ; Wed, 30 May 2001 20:29:13 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA10066; Wed, 30 May 2001 14:01:10 +0200 (MET DST) Date: Wed, 30 May 2001 14:01:09 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B142495.66677A18@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 944 Lines: 24 On Tue, 29 May 2001, Jun Sun wrote: > I think system V requires _test_and_set() being included in the libsys dynamic > library. Does Linux want to be sysv compatible? If so, we should removed the > inlined _test_and_set(). Why should we remove the inlined _test_and_set()? We do have a number of other inlined functions in glibc, e.g. memcpy() and friends in (not for MIPS, actually, but for other hosts), yet it does not make glibc SVR4 incompatible. Of course we always provide non-inlined versions of such functions as well -- check with objdump if unsure. Note they are *extern* inline. > The need for kernel emulated test_and_set() in 64bit kernel is not obvious > yet, and hopefully will never come. Agreed. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 30 20:29:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4V3TH928530 for linux-mips-outgoing; Wed, 30 May 2001 20:29:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V3TBh28518 for ; Wed, 30 May 2001 20:29:11 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA05204 for ; Wed, 30 May 2001 20:29:08 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA13602; Wed, 30 May 2001 15:42:21 +0200 (MET DST) Date: Wed, 30 May 2001 15:42:21 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , Joe deBlaquiere , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B142367.791F28AF@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2353 Lines: 55 On Tue, 29 May 2001, Jun Sun wrote: > > What about 3) -- a new syscall with a different semantics and no need to > > care about limitations of current implementations (especially the > > sysmips() bag). > > Having a new syscall is fine with me, although seems a little more instrusive > than adding a subcall to sysmips(). Actually whole sysmips() looks like a crazy hack, much like ioctl(), but even worse (passing a pointer in an integer argument, even if it works... yuck!). And it is weird, to say at least, to have different interpretations of the return value -- sometimes it's errno and sometimes it's something different. A separate syscall has the advantage we can write it cleanly and optimally, not caring of the calling convention of the incorporating syscall as in the case of sysmips(). And the overhead is a bit smaller. > The patch looks good to me. Great! > BTW, why wouldn't you choose to have three arguments in the syscall, where the > last one is a pointer to the variable to hold the return value? Doing that > would avoid tricky register manipulation on both calling side (fetching return > value from $v1) and kernel side (setting regs.regs[3]). You may treat this as a syscall returning long long. ;-) A few other syscalls have non-standard register allocations as well. I think it's cleaner to return a value in a register -- no need to handle passing an invalid pointer. And the overhead is a bit smaller -- no need for two memory accesses, which require an auxillary register anyway and which may cause a TLB fault and/or a cache line reload. This is to be discussed though. I have the glibc patch basically ready. It's nice -- the target sys__test_and_set() wrapper is only seven instructions long (of which three are the gp PIC preamble, sigh). The v1 to v0 move is free -- it fits in the delay slot of "jr $ra" nicely. :-) Unfortunately, for glibc 2.2.x we should probably fall back to sysmips(MIPS_ATOMIC_SET) if the sys__test_and_set() fails (with ENOSYS), for compatibility. This lengthens the function to 27 instructions. We can hopefully remove the crap in glibc 2.3. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed May 30 23:54:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4V6s7N31969 for linux-mips-outgoing; Wed, 30 May 2001 23:54:07 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V6s1h31964 for ; Wed, 30 May 2001 23:54:01 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 105C61E10F; Thu, 31 May 2001 08:53:55 +0200 (MEST) X-Authentication-Warning: D139.suse.de: aj set sender to aj@suse.de using -f To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Jun Sun Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration References: From: Andreas Jaeger Date: 31 May 2001 08:52:58 +0200 In-Reply-To: ("Maciej W. Rozycki"'s message of "Wed, 30 May 2001 19:58:43 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3261 Lines: 74 "Maciej W. Rozycki" writes: > Hi, > > Here is the second version of the sys__test_and_set() syscall suite. A > glibc patch is included this time as well. > > There are two small changes to the sys__test_and_set() implementation: > > 1. verify_area() is now called for the ll/sc version as well. Otherwise > one could pass a KSEG address and gain unauthorized access. > > 2. The fuction now returns immediately without performing a write access > if the value stored in the memory wouldn't change. This is to avoid the > need of a potentially costful sc operation; for consistency, this is also > done for the non-ll/sc version. > > The glibc patch should be fairly obvious. There is no inline version of > the _test_and_set() function for MIPS I anymore -- while previously it > saved an extra stack frame just to call sysmips(), this would be pointless > now (well, not quite as long as we fallback to sysmips(), actually, but > that is a temporary compatibility bit that will soon get removed, I hope). > Note that while sys__test_and_set() never returns an error, there might > one happen if someone tries to execute the syscall running a kernel that > does not support it. Hence we fall back to sysmips(). > > The official entry point is _test_and_set(). There is also the > ___test_and_set() entry point defined, mostly for completeness for MIPS > II+ systems, to be sure all syscalls actually have their wrappers > exported. Not to be used under normal circumstances, though. > > Andreas, what do you think: Should we fall back to sysmips() as in the > following patch (at a considerable performance hit -- without the fallback > the entire ___test_and_set() wrapper is seven instructions long) or just > require a specific minimum kernel version bail out at the compile time if > no __NR__test_and_set is defined? Granted, pthreads don't run for > MIPS/Linux for a long time, so it's possible the user base is not that > large such an abrupt switch would be impossible. Especially as sysmips() > seems to be continuously in flux for the last few months. I assume the > switch to the new syscall would be mandatory for glibc 2.3 in any case. Do it the following way: - Define in sysdeps/unix/sysv/linux/kernel-features a new macro, e.g. __ASSUME_TEST_AND_SET with the appropriate guards - Do *both* implementations like this: #include #if __ASSUME_TEST_AND_SET fast code without fallback #else slow code that first tries kernel call and then falls back to sysmips #endif This way you get the fast one if you configure glibc with --enable-kernel=2.4.6 if we assume that 2.4.6 is the first kernel with those features. Check other places in glibc for details how this can be done. Thanks, Andreas > I'm open to constructive feedback. An open question is whether returning > the result in v1 is clean. I believe it is -- I haven't been convinced > that storing the result in a memory location passed as the third argument > is cleaner. Certainly it's not faster and v1 is still dedicated to be a > result register. It's used by sys_pipe() this way, for example. > > Maciej -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Thu May 31 01:09:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4V89dm01666 for linux-mips-outgoing; Thu, 31 May 2001 01:09:39 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V89ah01662 for ; Thu, 31 May 2001 01:09:36 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA04756 for ; Thu, 31 May 2001 01:09:02 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA12055; Thu, 31 May 2001 09:39:40 +0200 (MET DST) Date: Thu, 31 May 2001 09:39:40 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B1533EB.924ACA05@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 466 Lines: 13 On Wed, 30 May 2001, Jun Sun wrote: > I don't think "extern" changes the picture here because once the call is > inlined the code will bypass libsys - unless my previous understanding is > wrong. Yes, it does. If you insist on not inlining it -- you can do it. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 31 03:11:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4VABVx05091 for linux-mips-outgoing; Thu, 31 May 2001 03:11:31 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VABRh05086 for ; Thu, 31 May 2001 03:11:27 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id DAA07985 for ; Thu, 31 May 2001 03:08:32 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA13793; Thu, 31 May 2001 10:37:42 +0200 (MET DST) Date: Thu, 31 May 2001 10:37:42 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , Joe deBlaquiere , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel In-Reply-To: <3B15306A.3AACAF3E@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 823 Lines: 22 On Wed, 30 May 2001, Jun Sun wrote: > Agree. Having dual semantics for the return value is bad. > > I was actually suggesting to have a new subcall in sysmips (e.g., > MIPS_NEW_ATOMIC_SET) and still working within the sysmips() call framework. > > Is there any concern as for adding a new syscall? I'd prefer to avoid sysmips() (as a whole, not only the MIPS_ATOMIC_SET subcall) for the reasons I've written previously. There is really no point in saving five bytes in the syscall tables just to make use of the existing mess. Note that adding MIPS_NEW_ATOMIC_SET doesn't make sysmips() more consistent at all. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu May 31 05:42:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4VCgPG09960 for linux-mips-outgoing; Thu, 31 May 2001 05:42:25 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VCgCh09943 for ; Thu, 31 May 2001 05:42:12 -0700 Received: from dea.waldorf-gmbh.de (u-238-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.238]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAB02859 for ; Thu, 31 May 2001 05:42:10 -0700 (PDT) mail_from (ralf@dea.waldorf-gmbh.de) Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4VBstT30532; Thu, 31 May 2001 13:54:55 +0200 Date: Thu, 31 May 2001 13:54:55 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jun Sun , Joe deBlaquiere , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel Message-ID: <20010531135454.A1195@bacchus.dhis.org> References: <3B0ED686.C1D85CE1@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, May 28, 2001 at 05:34:26PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1031 Lines: 25 On Mon, May 28, 2001 at 05:34:26PM +0200, Maciej W. Rozycki wrote: > > Alright, I rolled my sleeve and digged into IRIX 6.5, and guess what? > > sysmips() does NOT have MIPS_ATOMIC_SET (2001) on IRIX! See the header below. > > I remember Ralf writing of this being a compatibility call with RISC/OS > (is it the original OS of MIPS, Inc.?), IIRC. Ralf: am I right? Yes; this function is also implemented for IRIX 5 which we have some binary compatibility code for. > > So apparently MIPS_ATOMIC_SET was invented for Linux only, probably just to > > implement _test_and_set(). (It would be interesting to see how IRIX > > implement _test_and_set() on MIPS I machines. However, the machine I > > have access uses ll/sc instructions). I don't recall seeing a _test_and_set() in the IRIX API/ABI. > Does IRIX actually run on anything below ISA II? Well, it ran. A loong time ago. IRIX dropped support for MIPS I in IRIX 6. That makes sense as IRIX 6 is only running on R4000 and better, that is MIPS III CPUs. Ralf From owner-linux-mips@oss.sgi.com Thu May 31 08:29:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4VFTbh16836 for linux-mips-outgoing; Thu, 31 May 2001 08:29:37 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VFT3h16778 for ; Thu, 31 May 2001 08:29:03 -0700 Received: from dea.waldorf-gmbh.de (u-133-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.133]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08483 for ; Thu, 31 May 2001 08:28:54 -0700 (PDT) mail_from (ralf@dea.waldorf-gmbh.de) Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4VDm4N31197; Thu, 31 May 2001 15:48:04 +0200 Date: Thu, 31 May 2001 15:48:04 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: semaphore.c Message-ID: <20010531154804.A31184@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 336 Lines: 10 I've had a number of crashes in semaphore.c of the mips64 kernel; enough to no longer believe this might be some sort of memory corruption or otherwise unrelated to semaphore code: kernel BUG at semaphore.c:235! Cpu 0 Unable to handle kernel paging request at address 00000000, epc == 800208ac, ra == 800208ac Oops: 0001 Cpu 0 Ralf From owner-linux-mips@oss.sgi.com Thu May 31 08:29:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4VFT8416781 for linux-mips-outgoing; Thu, 31 May 2001 08:29:08 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VFSoh16773 for ; Thu, 31 May 2001 08:28:50 -0700 Received: from dea.waldorf-gmbh.de (u-133-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.133]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA07310 for ; Thu, 31 May 2001 08:28:34 -0700 (PDT) mail_from (ralf@dea.waldorf-gmbh.de) Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4VDwnS31228; Thu, 31 May 2001 15:58:49 +0200 Date: Thu, 31 May 2001 15:58:49 +0200 From: Ralf Baechle To: Ilya Volynets Cc: linux-mips@oss.sgi.com Subject: Re: Toolchain patches Message-ID: <20010531155849.C1195@bacchus.dhis.org> References: <01053009144307.01259@gateway> <20010530184346.A16307@rembrandt.csv.ica.uni-stuttgart.de> <01053010374600.00826@gateway> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01053010374600.00826@gateway>; from ilya@theIlya.com on Wed, May 30, 2001 at 10:37:46AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 768 Lines: 19 On Wed, May 30, 2001 at 10:37:46AM -0700, Ilya Volynets wrote: > That's why I didn't mention them. GCC is my primary concern now. > > Which of Your patches were rejected (and for what reason)? > I'm not talking about myself, but if you mention it to Keith, for example, > you'll hear a lot of loud sound :). He just loves to express his appreciation of The Evil Empire (TM) :-) > In general I think collecting stuff that floats around into one central place > will be useful. Alot of those patches are not suitable for public consumption or require additional modifications etc. For the casual user who doesn't want to dive into system internal too deep they're generally not recommended. Ralf The Evil Empire (TM) is a trademark of Ronald Raygun Industries. From owner-linux-mips@oss.sgi.com Thu May 31 12:17:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4VJHSa00529 for linux-mips-outgoing; Thu, 31 May 2001 12:17:28 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VJHKh00518; Thu, 31 May 2001 12:17:20 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA03791; Thu, 31 May 2001 12:17:19 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4VJHF014178; Thu, 31 May 2001 12:17:15 -0700 Message-ID: <3B169888.1F5DBDFF@mvista.com> Date: Thu, 31 May 2001 12:16:24 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , Joe deBlaquiere , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel References: <3B0ED686.C1D85CE1@mvista.com> <20010531135454.A1195@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1040 Lines: 28 Ralf Baechle wrote: > > On Mon, May 28, 2001 at 05:34:26PM +0200, Maciej W. Rozycki wrote: > > > > Alright, I rolled my sleeve and digged into IRIX 6.5, and guess what? > > > sysmips() does NOT have MIPS_ATOMIC_SET (2001) on IRIX! See the header below. > > > > I remember Ralf writing of this being a compatibility call with RISC/OS > > (is it the original OS of MIPS, Inc.?), IIRC. Ralf: am I right? > > Yes; this function is also implemented for IRIX 5 which we have some > binary compatibility code for. > Is anybody at all still running IRIX binary on Linux? My impression the compatibility is broken a while back. > > > So apparently MIPS_ATOMIC_SET was invented for Linux only, probably just to > > > implement _test_and_set(). (It would be interesting to see how IRIX > > > implement _test_and_set() on MIPS I machines. However, the machine I > > > have access uses ll/sc instructions). > > I don't recall seeing a _test_and_set() in the IRIX API/ABI. > It is part of SYSV MIPS supplement spec. IRIX 6.5 has it. Jun From owner-linux-mips@oss.sgi.com Thu May 31 12:21:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4VJL0X00984 for linux-mips-outgoing; Thu, 31 May 2001 12:21:00 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VJKgh00954 for ; Thu, 31 May 2001 12:20:42 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA00913 for ; Thu, 31 May 2001 12:20:41 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4VJDr014020; Thu, 31 May 2001 12:13:53 -0700 Message-ID: <3B1697BE.3F3765A2@mvista.com> Date: Thu, 31 May 2001 12:13:02 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Jaeger CC: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4159 Lines: 88 Andreas Jaeger wrote: > > "Maciej W. Rozycki" writes: > > > Hi, > > > > Here is the second version of the sys__test_and_set() syscall suite. A > > glibc patch is included this time as well. > > > > There are two small changes to the sys__test_and_set() implementation: > > > > 1. verify_area() is now called for the ll/sc version as well. Otherwise > > one could pass a KSEG address and gain unauthorized access. > > > > 2. The fuction now returns immediately without performing a write access > > if the value stored in the memory wouldn't change. This is to avoid the > > need of a potentially costful sc operation; for consistency, this is also > > done for the non-ll/sc version. > > > > The glibc patch should be fairly obvious. There is no inline version of > > the _test_and_set() function for MIPS I anymore -- while previously it > > saved an extra stack frame just to call sysmips(), this would be pointless > > now (well, not quite as long as we fallback to sysmips(), actually, but > > that is a temporary compatibility bit that will soon get removed, I hope). > > Note that while sys__test_and_set() never returns an error, there might > > one happen if someone tries to execute the syscall running a kernel that > > does not support it. Hence we fall back to sysmips(). > > > > The official entry point is _test_and_set(). There is also the > > ___test_and_set() entry point defined, mostly for completeness for MIPS > > II+ systems, to be sure all syscalls actually have their wrappers > > exported. Not to be used under normal circumstances, though. > > > > Andreas, what do you think: Should we fall back to sysmips() as in the > > following patch (at a considerable performance hit -- without the fallback > > the entire ___test_and_set() wrapper is seven instructions long) or just > > require a specific minimum kernel version bail out at the compile time if > > no __NR__test_and_set is defined? Granted, pthreads don't run for > > MIPS/Linux for a long time, so it's possible the user base is not that > > large such an abrupt switch would be impossible. Especially as sysmips() > > seems to be continuously in flux for the last few months. I assume the > > switch to the new syscall would be mandatory for glibc 2.3 in any case. > > Do it the following way: > - Define in sysdeps/unix/sysv/linux/kernel-features a new macro, e.g. > __ASSUME_TEST_AND_SET with the appropriate guards > - Do *both* implementations like this: > #include > #if __ASSUME_TEST_AND_SET > fast code without fallback > #else > slow code that first tries kernel call and then falls back to sysmips > #endif > > This way you get the fast one if you configure glibc with > --enable-kernel=2.4.6 if we assume that 2.4.6 is the first kernel with > those features. > > Check other places in glibc for details how this can be done. > This might be an overkill - the slow code on a newer kernel costs about 1 or 2 cycle longer per call. > > I'm open to constructive feedback. An open question is whether returning > > the result in v1 is clean. I believe it is -- I haven't been convinced > > that storing the result in a memory location passed as the third argument > > is cleaner. Certainly it's not faster and v1 is still dedicated to be a > > result register. It's used by sys_pipe() this way, for example. On a second thought I feel stronger using $v1 is not a good idea - what if the return path of syscall suddenly needs to modify $v1? Also we have generic syscall routine in glibc, what if someday that routine starts to check $v1 as well? I understand the chances of these "what if" are low (and perhaps sys_pipe() is already this way), but I am still convinced we should the right thing. (Whoever invented MIPS_ATOMIC_SET might have been thinking it should never need to return an error code!) I don't see any "dirtiness" in using the third argument. The slowdown in performance should be negligible under the context of the whole system call. A syscall is invented to be here and stay. I personally feel more comfortable to play a little safer rather than a littel faster. Jun