Need help

From ilya@gateway.total-knowledge.com Sat Feb 1 07:40:36 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Feb 2003 07:40:37 +0000 (GMT) Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:30688 "HELO gateway.total-knowledge.com") by linux-mips.org with SMTP id ; Sat, 1 Feb 2003 07:40:36 +0000 Received: (qmail 10993 invoked by uid 502); 1 Feb 2003 07:40:33 -0000 Date: Fri, 31 Jan 2003 23:40:33 -0800 From: ilya@theIlya.com To: Ralf Baechle Cc: Skippie , linux-mips@linux-mips.org Subject: Re: XFree XZ support Message-ID: <20030201074033.GL15214@gateway.total-knowledge.com> References: <20030129143237.8D59413EC09@crassus.kulnet.kuleuven.ac.be> <20030130024611.GG15214@gateway.total-knowledge.com> <20030131104814.A31631@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5VuzLDXibKSJvVYD" Content-Disposition: inline In-Reply-To: <20030131104814.A31631@linux-mips.org> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@theIlya.com Precedence: bulk X-list: linux-mips --5VuzLDXibKSJvVYD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry. I take back "lying" part. On Fri, Jan 31, 2003 at 10:48:14AM +0100, Ralf Baechle wrote: > On Wed, Jan 29, 2003 at 06:46:11PM -0800, ilya@theIlya.com wrote: >=20 > > Hold it there. I thought Impacts are the ones with i860... > > You were either lying to me back then, or now. >=20 > Watch your words. >=20 > The Reality series are using upto about a dozen i860s in the gfx pipeline. > XZ and Impact is a relativly simple gfx in comparison - I'm told there is > about a dozen different graphics platforms that share nothing but the > basic architecture and all are marketed as XZ. I just hope that isn't > true ... >=20 > Ralf >=20 --5VuzLDXibKSJvVYD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+O3nw7sVBmHZT8w8RAp9iAKDWMN0bOiItYguPwU4Bv2AzBHWUkwCgvXrL M8YAmwoA5IFm+mlSPdfinUk= =in7k -----END PGP SIGNATURE----- --5VuzLDXibKSJvVYD-- From ralf@linux-mips.org Sat Feb 1 13:50:10 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Feb 2003 14:08:22 +0000 (GMT) Received: from p508B6159.dip.t-dialin.net ([IPv6:::ffff:80.139.97.89]:25219 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 1 Feb 2003 13:50:09 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h11Do6m25446; Sat, 1 Feb 2003 14:50:06 +0100 Date: Sat, 1 Feb 2003 14:50:06 +0100 From: Ralf Baechle To: Kumba12345@aol.com Cc: linux-mips@linux-mips.org Subject: Re: mips64 glitches Message-ID: <20030201145006.A31445@linux-mips.org> References: <11e.1d78c204.2b6c10e0@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <11e.1d78c204.2b6c10e0@aol.com>; from Kumba12345@aol.com on Fri, Jan 31, 2003 at 12:48:16PM -0500 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1288 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jan 31, 2003 at 12:48:16PM -0500, Kumba12345@aol.com wrote: > (nil)) > ../../gcc/toplev.c:1367: Internal compiler error in function fatal_insn > make[3]: *** [indydog.o] Error 1 > make[3]: Leaving directory `/usr/src/t/linux-2.4.20-mips/drivers/char' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/usr/src/t/linux-2.4.20-mips/drivers/char' > make[1]: *** [_subdir_char] Error 2 > make[1]: Leaving directory `/usr/src/t/linux-2.4.20-mips/drivers' > make: *** [_dir_drivers] Error 2 Know problem; the 64-bit egcs occasionally explodes when compiling some of the funky macros from . > Second, After removing watchdog support and recompiling, I wound up with a > compiled kernel. Attempting to boot it made another error: > > Exception: > Status register: 0x30044802 > Cause register: 0x8028 > Exception PC: 0x881ebeb4, Exception RA: 0x881ec4bc > Reserved Instruction exception, contents of PC = 0x62900b > Local I/O interrupt register 2: 0xc8 > Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048): > arg: a8740000 88200000 885fff80 88000000 > tmp: a8740000 88239dc8 0 88239e07 881dc000 a87ffc20 a8746f70 9fc5c274 > sve: a8740000 c12dc13a 0 c0f9138a 0 c0edd9c9 0 bf077b8a > t8 a8740000 t9 c0dcea58 at 0 v0 c0f9138a v1 0 k1 3ff > gp a8740000 fp abfb7d4f sp 4fd7ff27 ra cf31ffcf > > PANIC: Unexpected exception Another known problem. > I used the linux-mips CVS 2_4 branch, pulled today, and the egcs-mips64 1.1.2 > compiler and it's associated binutils. As for the kernel, I wonder if this > has anything to do with the fact the kernel build passed -mcpu=r8000 when I'm > running an R4400. I was told mips64 IP22 support should be mostly > functional, just it's been neglected for some time. > > Anyways, if there is anymore information needed, please advise. This system > works wonderfully on a 32-bit kernel built off a vanilla + debian patch, but > I wnated to try out mips64 on it just for kicks. There is no advantage of running a 64-bit kernel on an Indy right now. There are no 64-bit MIPS utilities and libraries shipping so all you could do is running 32-bit software. The only reason why I made the 64-bit Indy kernel at all was using it as a stepping stone when porting Linux to the SGI Origin. Ralf From ica2_ts@csv.ica.uni-stuttgart.de Sun Feb 2 21:49:55 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Feb 2003 21:49:56 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:20299 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Sun, 2 Feb 2003 21:49:55 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 18fRzs-000rsy-00; Sun, 02 Feb 2003 22:49:52 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 18fRzs-0007Kb-00; Sun, 02 Feb 2003 22:49:52 +0100 Date: Sun, 2 Feb 2003 22:49:52 +0100 To: linux-mips@linux-mips.org Cc: Ralf Baechle Subject: [PATCH] Fix r3k exception handler location Message-ID: <20030202214952.GL30469@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Hello All, this patch is untested, but I just can't see how a r3k can boot without it. Thiemo diff -BurpN linux-orig/arch/mips/kernel/traps.c linux-2.4.20/arch/mips/kernel/traps.c --- linux-orig/arch/mips/kernel/traps.c Fri Dec 20 04:19:49 2002 +++ linux-2.4.20/arch/mips/kernel/traps.c Sun Feb 2 21:57:19 2003 @@ -1000,7 +1000,7 @@ void __init trap_init(void) else if (mips_cpu.options & MIPS_CPU_4KEX) memcpy((void *)(KSEG0 + 0x180), &except_vec3_generic, 0x80); else - memcpy((void *)(KSEG0 + 0x080), &except_vec3_generic, 0x80); + memcpy((void *)(KSEG0 + 0x180), &except_vec3_generic, 0x80); if (mips_cpu.cputype == CPU_R6000 || mips_cpu.cputype == CPU_R6000A) { /* diff -BurpN linux-orig/arch/mips64/kernel/traps.c linux-2.4.20/arch/mips64/kernel/traps.c --- linux-orig/arch/mips64/kernel/traps.c Fri Dec 20 04:19:51 2002 +++ linux-2.4.20/arch/mips64/kernel/traps.c Sun Feb 2 21:57:20 2003 @@ -755,7 +755,7 @@ void __init trap_init(void) } else if (mips_cpu.options & MIPS_CPU_4KEX) memcpy((void *)(KSEG0 + 0x180), &except_vec3_generic, 0x80); else - memcpy((void *)(KSEG0 + 0x080), &except_vec3_generic, 0x80); + memcpy((void *)(KSEG0 + 0x180), &except_vec3_generic, 0x80); if (mips_cpu.cputype == CPU_R6000 || mips_cpu.cputype == CPU_R6000A) { /* From ralf@linux-mips.org Sun Feb 2 22:08:01 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Feb 2003 22:08:02 +0000 (GMT) Received: from p508B76F7.dip.t-dialin.net ([IPv6:::ffff:80.139.118.247]:49054 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 2 Feb 2003 22:08:01 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h12M80u02256; Sun, 2 Feb 2003 23:08:00 +0100 Date: Sun, 2 Feb 2003 23:08:00 +0100 From: Ralf Baechle To: Thiemo Seufer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix r3k exception handler location Message-ID: <20030202230800.A2213@linux-mips.org> References: <20030202214952.GL30469@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.5.1i In-Reply-To: <20030202214952.GL30469@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Sun, Feb 02, 2003 at 10:49:52PM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Feb 02, 2003 at 10:49:52PM +0100, Thiemo Seufer wrote: > this patch is untested, but I just can't see how a r3k can boot without it. Because it's not a R4000 ;-) R3000 has different exception vector locations than R4000. Ralf From lindahl@keyresearch.com Sun Feb 2 22:09:02 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Feb 2003 22:09:03 +0000 (GMT) Received: from 12-234-29-241.client.attbi.com ([IPv6:::ffff:12.234.29.241]:34455 "EHLO localhost.localdomain") by linux-mips.org with ESMTP id ; Sun, 2 Feb 2003 22:09:02 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h12LHnPs012289; Sun, 2 Feb 2003 13:17:50 -0800 Received: (from lindahl@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id h12LHbx4012287; Sun, 2 Feb 2003 13:17:37 -0800 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Sun, 2 Feb 2003 13:17:37 -0800 From: Greg Lindahl To: linux-mips@linux-mips.org Cc: Karsten Merker , tom@maisl.net Subject: Re: [PATCH] Cobalt interrupthandler fix Message-ID: <20030202211737.GA12262@greglaptop.attbi.com> Mail-Followup-To: linux-mips@linux-mips.org, Karsten Merker , tom@maisl.net References: <20030124141524.GA685@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030124141524.GA685@excalibur.cologne.de> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lindahl@keyresearch.com Precedence: bulk X-list: linux-mips On Fri, Jan 24, 2003 at 03:15:24PM +0100, Karsten Merker wrote: > the Cobalt NASRaQ (as well as other RaQ models) has the problem of freezing > when there is activity on the serial port and on the ethernet at the same > time. Peter de Schrijver has tracked this down to a bug in the interrupt > handler. The handler currently does not check whether an interrupt is masked > and calls the handling routine for _every_ interrupt, not only for those > that are not masked out currently. While we're at it: [lindahl@fileserver mips]$ find . -name "*int-hand*" | xargs grep -L CP0_STATUS ./jmr3927/rbhma3100/int-handler.S ./philips/nino/int-handler.S The philips case seems to have the same bug. The jmr3927 thingie is hard to understand, so I can't tell if it has the same bug or not. -- greg From clausen@pureza.melbourne.sgi.com Mon Feb 3 04:15:03 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Feb 2003 04:15:04 +0000 (GMT) Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:33976 "EHLO rj.sgi.com") by linux-mips.org with ESMTP id ; Mon, 3 Feb 2003 04:15:03 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h132FAG8032001 for <@external-mail-relay.sgi.com:linux-mips@linux-mips.org>; Sun, 2 Feb 2003 18:15:11 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA06009 for ; Mon, 3 Feb 2003 15:14:59 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h134EXMd018235 for ; Mon, 3 Feb 2003 15:14:34 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h134EWIe018233 for linux-mips@linux-mips.org; Mon, 3 Feb 2003 15:14:32 +1100 Date: Mon, 3 Feb 2003 15:14:32 +1100 From: Andrew Clausen To: Linux/MIPS Development Subject: debian installer on mips64 (origin 200) Message-ID: <20030203041432.GF967@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Hi all, I've got Debian running smoothly on an Origin 200 :) I've also got it booting off a CD, by putting a dvh partition table, containing an xfs partition with a kernel on it. Unfortunately, I couldn't get dvhtool to put sash on it. (It complained the volume header was too small, which it wasn't) I had to use the sash off the hard disk. Anyway, in principle, I should be able write a shell script to create the above image, and add an isofs partition containing the debian mips install cd. Just, I bet it can't deal with sash / the prom properly - it's probably dependent on arcboot. Also, it would need different kernel packages. So, I guess an arcboot port would be the nicest solution? Perhaps a better approach is to get the kernel to prompt users to change disks, and stick in the vanilla debian CD? i.e. have a "mips64-bootstrap.img" CD image, which prompts for install-1 afterwards. Cheers, Andrew PS: I don't speak for SGI From Nemanja.Popov@micronasnit.com Mon Feb 3 08:57:27 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Feb 2003 08:57:28 +0000 (GMT) Received: from krt.neobee.net ([IPv6:::ffff:217.26.72.90]:5637 "EHLO krt.neobee.net") by linux-mips.org with ESMTP id ; Mon, 3 Feb 2003 08:57:27 +0000 Received: (from root@localhost) by krt.neobee.net (8.11.6/8.11.4) id h139SOu27696 for linux-mips@linux-mips.org; Mon, 3 Feb 2003 10:28:24 +0100 Received: from stanojevic ([192.168.0.224]) by krt.neobee.net (8.11.6/8.11.4) with SMTP id h139SHd27667 for ; Mon, 3 Feb 2003 10:28:23 +0100 Message-ID: <001701c2cb62$3eccd500$e000a8c0@micronasnit.com> From: "Nemanja Popov" To: Subject: Lexra' s MMU Date: Mon, 3 Feb 2003 09:57:02 +0100 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 X-scanner: scanned by Inflex 1.0.8 - (http://pldaniels.com/inflex/) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Nemanja.Popov@micronasnit.com Precedence: bulk X-list: linux-mips Hi all ! Does Lexra's CPU LX4280 has MMU. I've found from dateaheet LX4280 that there is only SMMU (S stands for Simple) which does not include TLB and exceptions related to that. I've noticed port for lexra (among others also for LX4280) on cvs. Is it possible to run linux on that kind of processor, and if so will it manage user space application as it should with mmu. Thanx. From ajc@gmx.net Mon Feb 3 10:07:42 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Feb 2003 10:07:42 +0000 (GMT) Received: from pop.gmx.net ([IPv6:::ffff:213.165.65.60]:17006 "HELO mail.gmx.net") by linux-mips.org with SMTP id ; Mon, 3 Feb 2003 10:07:42 +0000 Received: (qmail 8658 invoked by uid 0); 3 Feb 2003 10:07:33 -0000 Received: from p50819F5C.dip.t-dialin.net (HELO gmx.net) (80.129.159.92) by mail.gmx.net (mp003-rz3) with SMTP; 3 Feb 2003 10:07:33 -0000 Message-ID: <3E3E3F80.8080704@gmx.net> Date: Mon, 03 Feb 2003 11:08:00 +0100 From: Andrew Cannon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Indy bootstrap tftp problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ajc@gmx.net Precedence: bulk X-list: linux-mips I am trying to install Linux on my Indy using the network boot procedure described on the debian site at This is not getting very far because the tftp load of the bootblock fails with the Indy bootrom reporting "ip fragments error" for each tftp reply packet that arrives (with debug enabled). Does anyone know what might be happening here? Is this a known bug in the bootrom? More info - tcpdump on the server shows the tftp reply packets with blocksize 512 being sent out so there doesn't actually seem to be any ip fragmentation happening. Booting IRIX and running 'tftp get' works ok so it's only the rom that fails. Oh and this is quite an early Indy, so it may well have a buggy rom. Any help appreciated. thx Andrew Cannon From kaos@ocs.com.au Mon Feb 3 10:30:55 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Feb 2003 10:30:55 +0000 (GMT) Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:38162 "HELO mail.ocs.com.au") by linux-mips.org with SMTP id ; Mon, 3 Feb 2003 10:30:55 +0000 Received: (qmail 3612 invoked from network); 3 Feb 2003 10:30:46 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 3 Feb 2003 10:30:46 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id AEE03300087; Mon, 3 Feb 2003 21:30:43 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 2F5C18F; Mon, 3 Feb 2003 21:30:43 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Andrew Cannon Cc: linux-mips@linux-mips.org Subject: Re: Indy bootstrap tftp problem In-reply-to: Your message of "Mon, 03 Feb 2003 11:08:00 BST." <3E3E3F80.8080704@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Feb 2003 21:30:37 +1100 Message-ID: <2436.1044268237@ocs3.intra.ocs.com.au> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaos@ocs.com.au Precedence: bulk X-list: linux-mips On Mon, 03 Feb 2003 11:08:00 +0100, Andrew Cannon wrote: >I am trying to install Linux on my Indy using the network boot procedure >described on the debian site at > > >This is not getting very far because the tftp load of the bootblock >fails with the Indy bootrom reporting "ip fragments error" for each tftp >reply packet that arrives (with debug enabled). Does anyone know what >might be happening here? Is this a known bug in the bootrom? Some Indy bootroms do not cope with the "don't fragment" bit (DF) being set. If the tftp server is Linux echo "1" > /proc/sys/net/ipv4/ip_no_pmtu_disc From ralf@linux-mips.org Mon Feb 3 12:26:46 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Feb 2003 12:26:47 +0000 (GMT) Received: from p508B76F7.dip.t-dialin.net ([IPv6:::ffff:80.139.118.247]:16041 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 3 Feb 2003 12:26:46 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h13CQY021345; Mon, 3 Feb 2003 13:26:34 +0100 Date: Mon, 3 Feb 2003 13:26:34 +0100 From: Ralf Baechle To: Nemanja Popov Cc: linux-mips@linux-mips.org Subject: Re: Lexra' s MMU Message-ID: <20030203132634.C18186@linux-mips.org> References: <001701c2cb62$3eccd500$e000a8c0@micronasnit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <001701c2cb62$3eccd500$e000a8c0@micronasnit.com>; from Nemanja.Popov@micronasnit.com on Mon, Feb 03, 2003 at 09:57:02AM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 03, 2003 at 09:57:02AM +0100, Nemanja Popov wrote: > Does Lexra's CPU LX4280 has MMU. I've found from dateaheet LX4280 that > there is only SMMU (S stands for Simple) which does not include TLB and > exceptions related to that. > I've noticed port for lexra (among others also for LX4280) on cvs. Is it > possible to run linux on that kind of processor, and if so will it manage > user space application as it should with mmu. TLB-less processors aren't supported at all by Linux 2.4. Linux 2.5 has the infrastructure in place to support TLB-less processors but we don't support that on MIPS. I guess it's probably not interesting because TLB-less CPUs tend to be part of systems that are too resource constrained to be of interest for use with Linux but I certainly wouldn't refuse such patches. The CVS kernel does not support Lexra processors. There are a bit over one year old Lexra patches for 2.4. Me and the author agreed to not merge those patches into the CVS kernel because Lexra is a dead company. Ralf From vivienc@nerim.net Mon Feb 3 22:20:31 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Feb 2003 22:20:31 +0000 (GMT) Received: from smtp-102.noc.nerim.net ([IPv6:::ffff:62.4.17.102]:37894 "EHLO mallaury.noc.nerim.net") by linux-mips.org with ESMTP id ; Mon, 3 Feb 2003 22:20:31 +0000 Received: from melkor (vivienc.net1.nerim.net [213.41.134.233]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 646B762D06; Mon, 3 Feb 2003 23:20:26 +0100 (CET) Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.36 #1 (Debian)) id 18foyM-0006cc-00; Mon, 03 Feb 2003 23:21:50 +0100 Date: Mon, 3 Feb 2003 23:21:50 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle Cc: Jun Sun , linux-mips@linux-mips.org Subject: [PATCH 2.5] r4k_switch task_struct/thread_info fixes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vivienc@nerim.net Precedence: bulk X-list: linux-mips Hi, This patch fixes an incorrect use of THREAD_FLAGS instead of TI_FLAGS when clearing the TIF_USEDFPU flag of the current thread info, and an incorrect assumption when using ST_OFF, that the stack is shared with task_struct, whereas it is shared with thread_info in 2.5. Vivien. Index: arch/mips64/kernel/r4k_switch.S =================================================================== RCS file: /home/cvs/linux/arch/mips64/kernel/r4k_switch.S,v retrieving revision 1.22 diff -u -r1.22 r4k_switch.S --- arch/mips64/kernel/r4k_switch.S 5 Nov 2002 19:51:47 -0000 1.22 +++ arch/mips64/kernel/r4k_switch.S 3 Feb 2003 22:05:26 -0000 @@ -24,6 +24,10 @@ .set mips3 +/* + * Offset to the current process status flags, the first 32 bytes of the + * stack are not used. + */ #define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS) /* @@ -58,15 +62,15 @@ nor t1, zero, t1 and t0, t0, t1 - sd t0, TASK_FLAGS(t3) + sd t0, TI_FLAGS(t3) /* * clear saved user stack CU1 bit */ - ld t0, ST_OFF(a0) + ld t0, ST_OFF(t3) li t1, ~ST0_CU1 and t0, t0, t1 - sd t0, ST_OFF(a0) + sd t0, ST_OFF(t3) sll t2, t0, 5 Index: arch/mips/kernel/r4k_switch.S =================================================================== RCS file: /home/cvs/linux/arch/mips/kernel/r4k_switch.S,v retrieving revision 1.29 diff -u -r1.29 r4k_switch.S --- arch/mips/kernel/r4k_switch.S 5 Nov 2002 19:51:47 -0000 1.29 +++ arch/mips/kernel/r4k_switch.S 3 Feb 2003 22:06:17 -0000 @@ -67,10 +67,10 @@ /* * clear saved user stack CU1 bit */ - lw t0, ST_OFF(a0) + lw t0, ST_OFF(t3) li t1, ~ST0_CU1 and t0, t0, t1 - sw t0, ST_OFF(a0) + sw t0, ST_OFF(t3) FPU_SAVE_DOUBLE(a0, t0) # clobbers t0 From clausen@pureza.melbourne.sgi.com Mon Feb 3 22:56:33 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Feb 2003 22:56:34 +0000 (GMT) Received: from zok.SGI.COM ([IPv6:::ffff:204.94.215.101]:63711 "EHLO zok.sgi.com") by linux-mips.org with ESMTP id ; Mon, 3 Feb 2003 22:56:33 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h13M3OKp032202; Mon, 3 Feb 2003 14:03:25 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13568; Tue, 4 Feb 2003 09:56:28 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h13Mu2Md019955; Tue, 4 Feb 2003 09:56:02 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h13Mu1JR019953; Tue, 4 Feb 2003 09:56:01 +1100 Date: Tue, 4 Feb 2003 09:56:01 +1100 From: Andrew Clausen To: Jason Ormes Cc: linux-mips@linux-mips.org Subject: Re: debian's mips userland on mips64 Message-ID: <20030203225601.GG967@pureza.melbourne.sgi.com> References: <20030122073006.GF6262@pureza.melbourne.sgi.com> <002001c2cba5$ab641320$4437e183@fermi.win.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002001c2cba5$ab641320$4437e183@fermi.win.fnal.gov> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips On Mon, Feb 03, 2003 at 10:59:52AM -0600, Jason Ormes wrote: > I happened to see that you were running on an origin 200. I'm currently > trying to build a kernel for an origin 200 that I have laying around and > am getting a bunch of errors in the ip27-init.c file. Is there some > magic combination of flags when I build this? I've been using 2.4.x cvs. What error do you get? Please post to the list! I've been compiling with: alias mipsmake='make CROSS_COMPILE=mips64-linux ARCH=mips64' mipsmake clean mipsmake menuconfig <-- select arch/mips64/defconfig-ip27 mipsmake vmlinux.64 > You mention that you are > using the mips64-linux kernel but when I turn on ip27 support it wants > to build a little endian version? Any help you could give me would be > gratefully appreciated. Doesn't for me... Cheers, Andrew From clausen@pureza.melbourne.sgi.com Tue Feb 4 06:14:03 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 06:14:04 +0000 (GMT) Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:21676 "EHLO rj.sgi.com") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 06:14:03 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h144E3G8016877 for <@external-mail-relay.sgi.com:linux-mips@linux-mips.org>; Mon, 3 Feb 2003 20:14:06 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17449 for ; Tue, 4 Feb 2003 17:13:51 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h146DOMd027311 for ; Tue, 4 Feb 2003 17:13:25 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h146DN4h027309 for linux-mips@linux-mips.org; Tue, 4 Feb 2003 17:13:23 +1100 Date: Tue, 4 Feb 2003 17:13:23 +1100 From: Andrew Clausen To: Linux-MIPS Subject: [patch] cmdline.c rewrite Message-ID: <20030204061323.GA27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Hi all, This patch is mainly a cleanup. There is only one change (improvement!) in the semantics: Some kernel parameters are auto-generated. eg: root= (always has been broken). Anyway, the old version of cmdline.c added these auto-generated parameters unconditionally. Now, it old adds them if there's no collision with old parameters. Is that Right? Cheers, Andrew Index: cmdline.c =================================================================== RCS file: /home/cvs/linux/arch/mips/arc/cmdline.c,v retrieving revision 1.5.2.3 diff -u -r1.5.2.3 cmdline.c --- cmdline.c 5 Aug 2002 23:53:30 -0000 1.5.2.3 +++ cmdline.c 24 Jan 2003 06:43:57 -0000 @@ -6,6 +6,8 @@ * cmdline.c: Kernel command line creation using ARCS argc/argv. * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) + * Copyright (C) 2003 Silicon Graphics, Inc. + * modifications by Andrew Clausen (clausen@gnu.org) */ #include #include @@ -16,96 +18,76 @@ #undef DEBUG_CMDLINE -char arcs_cmdline[CL_SIZE]; +char arcs_cmdline[CL_SIZE]; /* initialized to empty */ +static int __initdata arg_count = 0; char * __init prom_getcmdline(void) { - return &(arcs_cmdline[0]); + return arcs_cmdline; } -static char *ignored[] = { +static void __init append_translated_arg(const char* match, const char* trans) +{ + int len = strlen(match); + int i; + + /* don't repeat arguments, like "root=X root=Y", unless the + * replacement string "trans" is empty, in which case the user is + * getting exactly what they asked for. + */ + if (strlen(trans) > 0 && strstr(arcs_cmdline, trans)) + return; + + for (i = 1; i < prom_argc; i++) { + if (!strncmp(prom_argv(i), match, len)) { + if (arg_count++) + strcat(arcs_cmdline, " "); + strcat(arcs_cmdline, trans); + strcat(arcs_cmdline, prom_argv(i) + len); + return; + } + } +} + +static char __initdata *ignored_args[] = { "ConsoleIn=", "ConsoleOut=", "SystemPartition=", "OSLoader=", "OSLoadPartition=", "OSLoadFilename=", - "OSLoadOptions=" -}; -#define NENTS(foo) ((sizeof((foo)) / (sizeof((foo[0]))))) - -static char *used_arc[][2] = { - { "OSLoadPartition=", "root=" }, - { "OSLoadOptions=", "" } + "OSLoadOptions=", + NULL }; -static char * __init move_firmware_args(char* cp) +static int __init is_arg_useful(const char* arg) { - char *s; - int actr, i; - - actr = 1; /* Always ignore argv[0] */ - - while (actr < prom_argc) { - for(i = 0; i < NENTS(used_arc); i++) { - int len = strlen(used_arc[i][0]); - - if (!strncmp(prom_argv(actr), used_arc[i][0], len)) { - /* Ok, we want it. First append the replacement... */ - strcat(cp, used_arc[i][1]); - cp += strlen(used_arc[i][1]); - /* ... and now the argument */ - s = strstr(prom_argv(actr), "="); - if (s) { - s++; - strcpy(cp, s); - cp += strlen(s); - } - *cp++ = ' '; - break; - } - } - actr++; + int i; + for (i = 0; ignored_args[i] != NULL; i++) { + if (!strncmp(arg, ignored_args[i], strlen(ignored_args[i]) - 1)) + return 0; } - - return cp; + return 1; } - -void __init prom_init_cmdline(void) +static void __init append_untranslated_args(void) { - char *cp; - int actr, i; - - actr = 1; /* Always ignore argv[0] */ - - cp = &(arcs_cmdline[0]); - /* - * Move ARC variables to the beginning to make sure they can be - * overridden by later arguments. - */ - cp = move_firmware_args(cp); - - while (actr < prom_argc) { - for (i = 0; i < NENTS(ignored); i++) { - int len = strlen(ignored[i]); - - if (!strncmp(prom_argv(actr), ignored[i], len)) - goto pic_cont; + int i; + for (i = 1; i < prom_argc; i++) { + if (is_arg_useful(prom_argv(i))) { + if (arg_count++) + strcat(arcs_cmdline, " "); + strcat(arcs_cmdline, prom_argv(i)); } - /* Ok, we want it. */ - strcpy(cp, prom_argv(actr)); - cp += strlen(prom_argv(actr)); - *cp++ = ' '; - - pic_cont: - actr++; } - if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */ - --cp; - *cp = '\0'; +} +void __init prom_init_cmdline(void) +{ + append_translated_arg("OSLoadOptions=", ""); + append_translated_arg("OSLoadPartition=", "root="); + append_untranslated_args(); #ifdef DEBUG_CMDLINE - prom_printf("prom_init_cmdline: %s\n", &(arcs_cmdline[0])); + prom_printf("prom_init_cmdline: \"%s\"\n", arcs_cmdline); #endif } From clausen@pureza.melbourne.sgi.com Tue Feb 4 06:26:14 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 06:26:15 +0000 (GMT) Received: from zok.SGI.COM ([IPv6:::ffff:204.94.215.101]:16561 "EHLO zok.sgi.com") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 06:26:14 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h145X4Kp029395 for <@external-mail-relay.sgi.com:linux-mips@linux-mips.org>; Mon, 3 Feb 2003 21:33:06 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17521 for ; Tue, 4 Feb 2003 17:26:06 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h146PdMd027333 for ; Tue, 4 Feb 2003 17:25:40 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h146PcGE027331 for linux-mips@linux-mips.org; Tue, 4 Feb 2003 17:25:38 +1100 Date: Tue, 4 Feb 2003 17:25:38 +1100 From: Andrew Clausen To: Linux-MIPS Subject: [patch] ip27-timer irq fix Message-ID: <20030204062538.GB27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Hi all, This patch sets up irq's properly. The author of this code apparently didn't understand the ugly hacks that are going on in bridge_irq_type.* (startup_bridge_irq() and friends). So, they were: (a) allocating a stupid IRQ number (that collided with something else in my case). This doesn't matter at all, since the timer interrupt comes through different channels to PCI device interrupts. (b) not calling setup_irq(), which meant, among other things, it wasn't appearing in /proc/interrupts. setup_irq() was crashing on them on startup, because startup_bridge_irq() was trying to do all kinds of PCI initialization on it (IIRC). Basically, if you pick an IRQ number less than BASE_PCI, startup_bridge_irq() will ignore it, and all works dandy :) The Right Solution TM would probably involve some other hw_interrupt_type like cpu_irq_type, or something. Cheers, Andrew Index: arch/mips/sgi-ip27/ip27-timer.c =================================================================== RCS file: /home/cvs/linux/arch/mips/sgi-ip27/ip27-timer.c,v retrieving revision 1.1.2.4 diff -u -r1.1.2.4 ip27-timer.c --- arch/mips/sgi-ip27/ip27-timer.c 2 Dec 2002 00:24:51 -0000 1.1.2.4 +++ arch/mips/sgi-ip27/ip27-timer.c 30 Jan 2003 22:38:48 -0000 @@ -90,13 +90,11 @@ return retval; } -#define IP27_TIMER_IRQ 9 /* XXX Assign number */ - void rt_timer_interrupt(struct pt_regs *regs) { int cpu = smp_processor_id(); int cpuA = ((cputoslice(cpu)) == 0); - int irq = IP27_TIMER_IRQ; + int irq = CPU_TIMER_IRQ; irq_enter(cpu, irq); write_lock(&xtime_lock); @@ -198,7 +196,7 @@ irq->handler = no_action; /* setup irqaction */ -// setup_irq(IP27_TIMER_IRQ, irq); /* XXX Can't do this yet. */ + setup_irq(CPU_TIMER_IRQ, irq); } void __init ip27_time_init(void) Index: include/asm-mips64/sn/sn0/ip27.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips64/sn/sn0/ip27.h,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 ip27.h --- include/asm-mips64/sn/sn0/ip27.h 27 Jun 2002 14:21:24 -0000 1.9.2.1 +++ include/asm-mips64/sn/sn0/ip27.h 30 Jan 2003 22:39:00 -0000 @@ -88,7 +88,8 @@ #define CPU_RESCHED_B_IRQ 1 #define CPU_CALL_A_IRQ 2 #define CPU_CALL_B_IRQ 3 -#define BASE_PCI_IRQ 4 +#define CPU_TIMER_IRQ 4 +#define BASE_PCI_IRQ 5 #define SN00_BRIDGE 0x9200000008000000 #define SN00I_BRIDGE0 0x920000000b000000 From clausen@pureza.melbourne.sgi.com Tue Feb 4 06:30:23 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 06:30:23 +0000 (GMT) Received: from zok.SGI.COM ([IPv6:::ffff:204.94.215.101]:48049 "EHLO zok.sgi.com") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 06:30:23 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h145bCKp029649; Mon, 3 Feb 2003 21:37:13 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17577; Tue, 4 Feb 2003 17:30:14 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h146TlMd027359; Tue, 4 Feb 2003 17:29:48 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h146TiTu027357; Tue, 4 Feb 2003 17:29:44 +1100 Date: Tue, 4 Feb 2003 17:29:44 +1100 From: Andrew Clausen To: wakkerma@debian.org Cc: Linux-MIPS Subject: [patch] remove bogus "struct sigaction" Message-ID: <20030204062944.GC27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Hi Wichert, Somebody made their own "struct new_sigaction". God knows why. It should be #ifdef'd if it's actually useful to someone (right?), but it's incompatible with linux-mips. My patch... using the struct sigaction out of the standard #includes... Works For Me TM. Cheers, Andrew diff -rpu strace-4.4/signal.c strace-4.4-fixed/signal.c --- strace-4.4/signal.c Sun Aug 19 22:06:50 2001 +++ strace-4.4-fixed/signal.c Thu Jan 23 23:30:59 2003 @@ -1363,26 +1363,11 @@ typedef struct siginfo } siginfo_t; #endif -/* Structure describing the action to be taken when a signal arrives. */ -struct new_sigaction -{ - union - { - __sighandler_t __sa_handler; - void (*__sa_sigaction) (int, siginfo_t *, void *); - } - __sigaction_handler; - unsigned long sa_flags; - void (*sa_restorer) (void); - unsigned long int sa_mask[2]; -}; - - int sys_rt_sigaction(tcp) struct tcb *tcp; { - struct new_sigaction sa; + struct sigaction sa; sigset_t sigset; long addr; @@ -1399,7 +1384,7 @@ sys_rt_sigaction(tcp) else if (umove(tcp, addr, &sa) < 0) tprintf("{...}"); else { - switch ((long) sa.__sigaction_handler.__sa_handler) { + switch ((long) sa.sa_handler) { case (long) SIG_ERR: tprintf("{SIG_ERR}"); break; @@ -1410,8 +1395,7 @@ sys_rt_sigaction(tcp) tprintf("{SIG_IGN}"); break; default: - tprintf("{%#lx, ", - (long) sa.__sigaction_handler.__sa_handler); + tprintf("{%#lx, ", (long) sa.sa_handler); sigemptyset(&sigset); #ifdef LINUXSPARC if (tcp->u_arg[4] <= sizeof(sigset)) From yoichi_yuasa@montavista.co.jp Tue Feb 4 06:45:53 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 06:45:54 +0000 (GMT) Received: from r-bu.iij4u.or.jp ([IPv6:::ffff:210.130.0.89]:63471 "EHLO r-bu.iij4u.or.jp") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 06:45:53 +0000 Received: from pudding.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id h146jkN01960; Tue, 4 Feb 2003 15:45:47 +0900 (JST) Date: Tue, 4 Feb 2003 15:40:25 +0900 From: Yoichi Yuasa To: ralf@linux-mips.org Cc: yoichi_yuasa@montavista.co.jp, linux-mips@linux-mips.org Subject: [patch] TANBAC TB0226(NEC VR4131) Message-Id: <20030204154025.340fdf40.yoichi_yuasa@montavista.co.jp> Organization: MontaVista Software Japan, Inc. X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Tue__4_Feb_2003_15:40:25_+0900_08258ab8" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@montavista.co.jp Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --Multipart_Tue__4_Feb_2003_15:40:25_+0900_08258ab8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello Ralf, I added support of TANBAC TB0226 to vr41xx directory. This patch is based on linux_2_4 tag cvs tree on ftp.linux-mips.org Would you apply this patch to CVS on ftp.linux-mips.org? Best Regards, Yoichi --Multipart_Tue__4_Feb_2003_15:40:25_+0900_08258ab8 Content-Type: text/plain; name="tanbac-tb0226.diff" Content-Disposition: attachment; filename="tanbac-tb0226.diff" Content-Transfer-Encoding: 7bit diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/Makefile linux/arch/mips/Makefile --- linux.orig/arch/mips/Makefile Fri Jan 24 10:25:54 2003 +++ linux/arch/mips/Makefile Tue Feb 4 15:24:28 2003 @@ -429,6 +429,17 @@ endif # +# TANBAC TB0226 Mbase (VR4131) +# +ifdef CONFIG_TANBAC_TB0226 +SUBDIRS += arch/mips/vr41xx/common \ + arch/mips/vr41xx/tanbac-tb0226 +LIBS += arch/mips/vr41xx/common/vr41xx.o \ + arch/mips/vr41xx/tanbac-tb0226/tb0226.o +LOADADDR := 0x80000000 +endif + +# # Philips Nino # ifdef CONFIG_NINO diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/config-shared.in linux/arch/mips/config-shared.in --- linux.orig/arch/mips/config-shared.in Mon Jan 27 11:06:23 2003 +++ linux/arch/mips/config-shared.in Tue Feb 4 15:24:28 2003 @@ -191,6 +191,7 @@ fi fi bool 'Support for SNI RM200 PCI' CONFIG_SNI_RM200_PCI +bool 'Support for TANBAC TB0226 (Mbase)' CONFIG_TANBAC_TB0226 dep_bool 'Support for Toshiba JMR-TX3927 board' CONFIG_TOSHIBA_JMR3927 $CONFIG_MIPS32 bool 'Support for Victor MP-C303/304' CONFIG_VICTOR_MPC30X if [ "$CONFIG_VICTOR_MPC30X" = "y" ]; then @@ -534,6 +535,19 @@ define_bool CONFIG_OLD_TIME_C y define_bool CONFIG_PC_KEYB y define_bool CONFIG_PCI y +fi +if [ "$CONFIG_TANBAC_TB0226" = "y" ]; then + define_bool CONFIG_CPU_VR41XX y + define_bool CONFIG_IRQ_CPU y + define_bool CONFIG_NEW_TIME_C y + define_bool CONFIG_VR41XX_TIME_C y + define_bool CONFIG_NONCOHERENT_IO y + define_bool CONFIG_ISA n + define_bool CONFIG_PCI y + define_bool CONFIG_NEW_PCI y + define_bool CONFIG_PCI_AUTO y + define_bool CONFIG_DUMMY_KEYB y + define_bool CONFIG_SERIAL_MANY_PORTS y fi if [ "$CONFIG_TOSHIBA_JMR3927" = "y" ]; then define_bool CONFIG_TOSHIBA_BOARDS y diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/defconfig-tb0226 linux/arch/mips/defconfig-tb0226 --- linux.orig/arch/mips/defconfig-tb0226 Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/defconfig-tb0226 Tue Feb 4 15:24:28 2003 @@ -0,0 +1,773 @@ +# +# Automatically generated make config: don't edit +# +CONFIG_MIPS=y +CONFIG_MIPS32=y +# CONFIG_MIPS64 is not set + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y + +# +# Loadable module support +# +CONFIG_MODULES=y +# CONFIG_MODVERSIONS is not set +CONFIG_KMOD=y + +# +# Machine selection +# +# CONFIG_ACER_PICA_61 is not set +# CONFIG_MIPS_PB1000 is not set +# CONFIG_MIPS_PB1100 is not set +# CONFIG_MIPS_PB1500 is not set +# CONFIG_MIPS_DB1000 is not set +# CONFIG_MIPS_DB1100 is not set +# CONFIG_MIPS_DB1500 is not set +# CONFIG_BAGET_MIPS is not set +# CONFIG_CASIO_E55 is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_DECSTATION is not set +# CONFIG_MIPS_EV64120 is not set +# CONFIG_MIPS_EV96100 is not set +# CONFIG_MIPS_IVR is not set +# CONFIG_HP_LASERJET is not set +# CONFIG_IBM_WORKPAD is not set +# CONFIG_LASAT is not set +# CONFIG_MIPS_ITE8172 is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MAGNUM_4000 is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +# CONFIG_MOMENCO_OCELOT is not set +# CONFIG_MOMENCO_OCELOT_G is not set +# CONFIG_DDB5074 is not set +# CONFIG_DDB5476 is not set +# CONFIG_DDB5477 is not set +# CONFIG_NEC_OSPREY is not set +# CONFIG_NEC_EAGLE is not set +# CONFIG_OLIVETTI_M700 is not set +# CONFIG_NINO is not set +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_SB1xxx_SOC is not set +# CONFIG_SNI_RM200_PCI is not set +CONFIG_TANBAC_TB0226=y +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_VICTOR_MPC30X is not set +# CONFIG_ZAO_CAPCELLA is not set +# CONFIG_HIGHMEM is not set +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set +CONFIG_CPU_VR41XX=y +CONFIG_IRQ_CPU=y +CONFIG_NEW_TIME_C=y +CONFIG_VR41XX_TIME_C=y +CONFIG_NONCOHERENT_IO=y +# CONFIG_ISA is not set +CONFIG_PCI=y +CONFIG_NEW_PCI=y +CONFIG_PCI_AUTO=y +CONFIG_DUMMY_KEYB=y +CONFIG_SERIAL_MANY_PORTS=y +# CONFIG_MIPS_AU1000 is not set + +# +# CPU selection +# +# CONFIG_CPU_MIPS32 is not set +# CONFIG_CPU_MIPS64 is not set +# CONFIG_CPU_R3000 is not set +# CONFIG_CPU_TX39XX is not set +CONFIG_CPU_VR41XX=y +# CONFIG_CPU_R4300 is not set +# CONFIG_CPU_R4X00 is not set +# CONFIG_CPU_TX49XX is not set +# CONFIG_CPU_R5000 is not set +# CONFIG_CPU_R5432 is not set +# CONFIG_CPU_R6000 is not set +# CONFIG_CPU_NEVADA is not set +# CONFIG_CPU_R8000 is not set +# CONFIG_CPU_R10000 is not set +# CONFIG_CPU_RM7000 is not set +# CONFIG_CPU_SB1 is not set +# CONFIG_CPU_ADVANCED is not set +# CONFIG_CPU_HAS_LLSC is not set +# CONFIG_CPU_HAS_LLDSCD is not set +# CONFIG_CPU_HAS_WB is not set +CONFIG_CPU_HAS_SYNC=y + +# +# General setup +# +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_NET=y +# CONFIG_PCI_NAMES is not set +# CONFIG_ISA is not set +# CONFIG_EISA is not set +# CONFIG_TC is not set +# CONFIG_MCA is not set +# CONFIG_SBUS is not set +# CONFIG_HOTPLUG is not set +# CONFIG_PCMCIA is not set +# CONFIG_HOTPLUG_PCI is not set +CONFIG_SYSVIPC=y +# CONFIG_BSD_PROCESS_ACCT is not set +CONFIG_SYSCTL=y +CONFIG_KCORE_ELF=y +# CONFIG_KCORE_AOUT is not set +# CONFIG_BINFMT_AOUT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_MIPS32_COMPAT is not set +# CONFIG_MIPS32_O32 is not set +# CONFIG_MIPS32_N32 is not set +# CONFIG_BINFMT_ELF32 is not set +# CONFIG_BINFMT_MISC is not set +# CONFIG_PM is not set + +# +# Memory Technology Devices (MTD) +# +# CONFIG_MTD is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play configuration +# +# CONFIG_PNP is not set +# CONFIG_ISAPNP is not set + +# +# Block devices +# +# CONFIG_BLK_DEV_FD is not set +# CONFIG_BLK_DEV_XD is not set +# CONFIG_PARIDE is not set +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_CISS_SCSI_TAPE is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_LOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_RAM is not set +# CONFIG_BLK_DEV_INITRD is not set +# CONFIG_BLK_STATS is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set +# CONFIG_BLK_DEV_MD is not set +# CONFIG_MD_LINEAR is not set +# CONFIG_MD_RAID0 is not set +# CONFIG_MD_RAID1 is not set +# CONFIG_MD_RAID5 is not set +# CONFIG_MD_MULTIPATH is not set +# CONFIG_BLK_DEV_LVM is not set + +# +# Networking options +# +CONFIG_PACKET=y +CONFIG_PACKET_MMAP=y +CONFIG_NETLINK_DEV=y +# CONFIG_NETFILTER is not set +# CONFIG_FILTER is not set +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_PNP=y +# CONFIG_IP_PNP_DHCP is not set +CONFIG_IP_PNP_BOOTP=y +# CONFIG_IP_PNP_RARP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_IP_MROUTE is not set +# CONFIG_ARPD is not set +# CONFIG_INET_ECN is not set +# CONFIG_SYN_COOKIES is not set +# CONFIG_IPV6 is not set +# CONFIG_KHTTPD is not set +# CONFIG_ATM is not set +# CONFIG_VLAN_8021Q is not set + +# +# +# +# CONFIG_IPX is not set +# CONFIG_ATALK is not set + +# +# Appletalk devices +# +# CONFIG_DEV_APPLETALK is not set +# CONFIG_DECNET is not set +# CONFIG_BRIDGE is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_LLC is not set +# CONFIG_NET_DIVERT is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set +# CONFIG_NET_FASTROUTE is not set +# CONFIG_NET_HW_FLOWCONTROL is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set +# CONFIG_PHONE_IXJ is not set +# CONFIG_PHONE_IXJ_PCMCIA is not set + +# +# ATA/IDE/MFM/RLL support +# +# CONFIG_IDE is not set +# CONFIG_BLK_DEV_IDE_MODES is not set +# CONFIG_BLK_DEV_HD is not set + +# +# SCSI support +# +CONFIG_SCSI=y + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=y +CONFIG_SD_EXTRA_DEVS=40 +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +CONFIG_BLK_DEV_SR=y +# CONFIG_BLK_DEV_SR_VENDOR is not set +CONFIG_SR_EXTRA_DEVS=2 +# CONFIG_CHR_DEV_SG is not set + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +# CONFIG_SCSI_DEBUG_QUEUES is not set +# CONFIG_SCSI_MULTI_LUN is not set +CONFIG_SCSI_CONSTANTS=y +# CONFIG_SCSI_LOGGING is not set + +# +# SCSI low-level drivers +# +# CONFIG_BLK_DEV_3W_XXXX_RAID is not set +# CONFIG_SCSI_7000FASST is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AHA152X is not set +# CONFIG_SCSI_AHA1542 is not set +# CONFIG_SCSI_AHA1740 is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_DPT_I2O is not set +# CONFIG_SCSI_ADVANSYS is not set +# CONFIG_SCSI_IN2000 is not set +# CONFIG_SCSI_AM53C974 is not set +# CONFIG_SCSI_MEGARAID is not set +# CONFIG_SCSI_BUSLOGIC is not set +# CONFIG_SCSI_CPQFCTS is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_DTC3280 is not set +# CONFIG_SCSI_EATA is not set +# CONFIG_SCSI_EATA_DMA is not set +# CONFIG_SCSI_EATA_PIO is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_GDTH is not set +# CONFIG_SCSI_GENERIC_NCR5380 is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_NCR53C406A is not set +# CONFIG_SCSI_NCR53C7xx is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +# CONFIG_SCSI_NCR53C8XX is not set +# CONFIG_SCSI_SYM53C8XX is not set +# CONFIG_SCSI_PAS16 is not set +# CONFIG_SCSI_PCI2000 is not set +# CONFIG_SCSI_PCI2220I is not set +# CONFIG_SCSI_PSI240I is not set +# CONFIG_SCSI_QLOGIC_FAS is not set +# CONFIG_SCSI_QLOGIC_ISP is not set +# CONFIG_SCSI_QLOGIC_FC is not set +# CONFIG_SCSI_QLOGIC_1280 is not set +# CONFIG_SCSI_SIM710 is not set +# CONFIG_SCSI_SYM53C416 is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_T128 is not set +# CONFIG_SCSI_U14_34F is not set +# CONFIG_SCSI_DEBUG is not set + +# +# I2O device support +# +# CONFIG_I2O is not set +# CONFIG_I2O_PCI is not set +# CONFIG_I2O_BLOCK is not set +# CONFIG_I2O_LAN is not set +# CONFIG_I2O_SCSI is not set +# CONFIG_I2O_PROC is not set + +# +# Network device support +# +CONFIG_NETDEVICES=y + +# +# ARCnet devices +# +# CONFIG_ARCNET is not set +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set +# CONFIG_ETHERTAP is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +# CONFIG_SUNLANCE is not set +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNBMAC is not set +# CONFIG_SUNQE is not set +# CONFIG_SUNGEM is not set +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_LANCE is not set +# CONFIG_NET_VENDOR_SMC is not set +# CONFIG_NET_VENDOR_RACAL is not set +# CONFIG_HP100 is not set +# CONFIG_NET_ISA is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_APRICOT is not set +# CONFIG_CS89x0 is not set +# CONFIG_TULIP is not set +# CONFIG_DE4X5 is not set +# CONFIG_DGRS is not set +# CONFIG_DM9102 is not set +CONFIG_EEPRO100=y +# CONFIG_E100 is not set +# CONFIG_LNE390 is not set +# CONFIG_FEALNX is not set +# CONFIG_NATSEMI is not set +# CONFIG_NE2K_PCI is not set +# CONFIG_NE3210 is not set +# CONFIG_ES3210 is not set +# CONFIG_8139CP is not set +# CONFIG_8139TOO is not set +# CONFIG_8139TOO_PIO is not set +# CONFIG_8139TOO_TUNE_TWISTER is not set +# CONFIG_8139TOO_8129 is not set +# CONFIG_8139_OLD_RX_RESET is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_TC35815 is not set +# CONFIG_VIA_RHINE is not set +# CONFIG_VIA_RHINE_MMIO is not set +# CONFIG_WINBOND_840 is not set +# CONFIG_LAN_SAA9730 is not set +# CONFIG_NET_POCKET is not set + +# +# Ethernet (1000 Mbit) +# +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_MYRI_SBUS is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set +# CONFIG_SK98LIN is not set +# CONFIG_TIGON3 is not set +# CONFIG_FDDI is not set +# CONFIG_HIPPI is not set +# CONFIG_PLIP is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set + +# +# Wireless LAN (non-hamradio) +# +# CONFIG_NET_RADIO is not set + +# +# Token Ring devices +# +# CONFIG_TR is not set +# CONFIG_NET_FC is not set +# CONFIG_RCPCI is not set +# CONFIG_SHAPER is not set + +# +# Wan interfaces +# +# CONFIG_WAN is not set + +# +# Amateur Radio support +# +# CONFIG_HAMRADIO is not set + +# +# IrDA (infrared) support +# +# CONFIG_IRDA is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Input core support +# +# CONFIG_INPUT is not set +# CONFIG_INPUT_KEYBDEV is not set +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_JOYDEV is not set +# CONFIG_INPUT_EVDEV is not set + +# +# Character devices +# +CONFIG_VT=y +# CONFIG_VT_CONSOLE is not set +CONFIG_SERIAL=y +CONFIG_SERIAL_CONSOLE=y +# CONFIG_SERIAL_EXTENDED is not set +# CONFIG_SERIAL_NONSTANDARD is not set +CONFIG_UNIX98_PTYS=y +CONFIG_UNIX98_PTY_COUNT=256 + +# +# I2C support +# +# CONFIG_I2C is not set + +# +# Mice +# +# CONFIG_BUSMOUSE is not set +# CONFIG_MOUSE is not set + +# +# Joysticks +# +# CONFIG_INPUT_GAMEPORT is not set + +# +# Input core support is needed for gameports +# + +# +# Input core support is needed for joysticks +# +# CONFIG_QIC02_TAPE is not set + +# +# Watchdog Cards +# +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set +# CONFIG_ACQUIRE_WDT is not set +# CONFIG_ADVANTECH_WDT is not set +# CONFIG_ALIM7101_WDT is not set +# CONFIG_SC520_WDT is not set +# CONFIG_PCWATCHDOG is not set +# CONFIG_EUROTECH_WDT is not set +# CONFIG_IB700_WDT is not set +# CONFIG_WAFER_WDT is not set +# CONFIG_I810_TCO is not set +# CONFIG_MIXCOMWD is not set +# CONFIG_60XX_WDT is not set +# CONFIG_SC1200_WDT is not set +# CONFIG_SOFT_WATCHDOG is not set +# CONFIG_W83877F_WDT is not set +# CONFIG_WDT is not set +# CONFIG_WDTPCI is not set +# CONFIG_MACHZ_WDT is not set +# CONFIG_INDYDOG is not set +# CONFIG_AMD7XX_TCO is not set +# CONFIG_NVRAM is not set +# CONFIG_RTC is not set +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set + +# +# Ftape, the floppy tape device driver +# +# CONFIG_FTAPE is not set +# CONFIG_AGP is not set +# CONFIG_DRM is not set + +# +# File systems +# +# CONFIG_QUOTA is not set +CONFIG_AUTOFS_FS=y +CONFIG_AUTOFS4_FS=y +# CONFIG_REISERFS_FS is not set +# CONFIG_REISERFS_CHECK is not set +# CONFIG_REISERFS_PROC_INFO is not set +# CONFIG_ADFS_FS is not set +# CONFIG_ADFS_FS_RW is not set +# CONFIG_AFFS_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BEFS_DEBUG is not set +# CONFIG_BFS_FS is not set +# CONFIG_EXT3_FS is not set +# CONFIG_JBD is not set +# CONFIG_JBD_DEBUG is not set +# CONFIG_FAT_FS is not set +# CONFIG_MSDOS_FS is not set +# CONFIG_UMSDOS_FS is not set +# CONFIG_VFAT_FS is not set +# CONFIG_EFS_FS is not set +# CONFIG_JFFS_FS is not set +# CONFIG_JFFS2_FS is not set +# CONFIG_CRAMFS is not set +# CONFIG_TMPFS is not set +CONFIG_RAMFS=y +# CONFIG_ISO9660_FS is not set +# CONFIG_JOLIET is not set +# CONFIG_ZISOFS is not set +# CONFIG_JFS_FS is not set +# CONFIG_JFS_DEBUG is not set +# CONFIG_JFS_STATISTICS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_VXFS_FS is not set +# CONFIG_NTFS_FS is not set +# CONFIG_NTFS_RW is not set +# CONFIG_HPFS_FS is not set +CONFIG_PROC_FS=y +# CONFIG_DEVFS_FS is not set +# CONFIG_DEVFS_MOUNT is not set +# CONFIG_DEVFS_DEBUG is not set +CONFIG_DEVPTS_FS=y +# CONFIG_QNX4FS_FS is not set +# CONFIG_QNX4FS_RW is not set +# CONFIG_ROMFS_FS is not set +CONFIG_EXT2_FS=y +# CONFIG_SYSV_FS is not set +# CONFIG_UDF_FS is not set +# CONFIG_UDF_RW is not set +# CONFIG_UFS_FS is not set +# CONFIG_UFS_FS_WRITE is not set + +# +# Network File Systems +# +# CONFIG_CODA_FS is not set +# CONFIG_INTERMEZZO_FS is not set +CONFIG_NFS_FS=y +# CONFIG_NFS_V3 is not set +CONFIG_ROOT_NFS=y +CONFIG_NFSD=y +# CONFIG_NFSD_V3 is not set +# CONFIG_NFSD_TCP is not set +CONFIG_SUNRPC=y +CONFIG_LOCKD=y +# CONFIG_SMB_FS is not set +# CONFIG_NCP_FS is not set +# CONFIG_NCPFS_PACKET_SIGNING is not set +# CONFIG_NCPFS_IOCTL_LOCKING is not set +# CONFIG_NCPFS_STRONG is not set +# CONFIG_NCPFS_NFS_NS is not set +# CONFIG_NCPFS_OS2_NS is not set +# CONFIG_NCPFS_SMALLDOS is not set +# CONFIG_NCPFS_NLS is not set +# CONFIG_NCPFS_EXTRAS is not set +# CONFIG_ZISOFS_FS is not set + +# +# Partition Types +# +CONFIG_PARTITION_ADVANCED=y +# CONFIG_ACORN_PARTITION is not set +# CONFIG_OSF_PARTITION is not set +# CONFIG_AMIGA_PARTITION is not set +# CONFIG_ATARI_PARTITION is not set +# CONFIG_MAC_PARTITION is not set +CONFIG_MSDOS_PARTITION=y +# CONFIG_BSD_DISKLABEL is not set +# CONFIG_MINIX_SUBPARTITION is not set +# CONFIG_SOLARIS_X86_PARTITION is not set +# CONFIG_UNIXWARE_DISKLABEL is not set +# CONFIG_LDM_PARTITION is not set +CONFIG_SGI_PARTITION=y +# CONFIG_ULTRIX_PARTITION is not set +# CONFIG_SUN_PARTITION is not set +# CONFIG_EFI_PARTITION is not set +# CONFIG_SMB_NLS is not set +# CONFIG_NLS is not set + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Console drivers +# +# CONFIG_VGA_CONSOLE is not set +# CONFIG_MDA_CONSOLE is not set + +# +# Frame-buffer support +# +# CONFIG_FB is not set + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# USB support +# +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +CONFIG_USB_DEVICEFS=y +CONFIG_USB_BANDWIDTH=y +CONFIG_USB_LONG_TIMEOUT=y + +# +# USB Host Controller Drivers +# +CONFIG_USB_EHCI_HCD=y +# CONFIG_USB_UHCI is not set +# CONFIG_USB_UHCI_ALT is not set +CONFIG_USB_OHCI=y + +# +# USB Device Class drivers +# +# CONFIG_USB_AUDIO is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_BLUETOOTH is not set +# CONFIG_USB_MIDI is not set +CONFIG_USB_STORAGE=y +# CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_DATAFAB is not set +# CONFIG_USB_STORAGE_FREECOM is not set +# CONFIG_USB_STORAGE_ISD200 is not set +# CONFIG_USB_STORAGE_DPCM is not set +# CONFIG_USB_STORAGE_HP8200e is not set +# CONFIG_USB_STORAGE_SDDR09 is not set +# CONFIG_USB_STORAGE_SDDR55 is not set +# CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set + +# +# USB Human Interface Devices (HID) +# +# CONFIG_USB_HID is not set + +# +# Input core support is needed for USB HID input layer or HIDBP support +# +# CONFIG_USB_HIDINPUT is not set +# CONFIG_USB_HIDDEV is not set +# CONFIG_USB_KBD is not set +# CONFIG_USB_MOUSE is not set +# CONFIG_USB_AIPTEK is not set +# CONFIG_USB_WACOM is not set + +# +# USB Imaging devices +# +# CONFIG_USB_DC2XX is not set +# CONFIG_USB_MDC800 is not set +# CONFIG_USB_SCANNER is not set +# CONFIG_USB_MICROTEK is not set +# CONFIG_USB_HPUSBSCSI is not set + +# +# USB Multimedia devices +# + +# +# Video4Linux support is needed for USB Multimedia device support +# + +# +# USB Network adaptors +# +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_CATC is not set +# CONFIG_USB_CDCETHER is not set +# CONFIG_USB_USBNET is not set + +# +# USB port drivers +# +# CONFIG_USB_USS720 is not set + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_TIGL is not set +# CONFIG_USB_BRLVGER is not set +# CONFIG_USB_LCD is not set + +# +# Bluetooth support +# +# CONFIG_BLUEZ is not set + +# +# Kernel hacking +# +CONFIG_CROSSCOMPILE=y +# CONFIG_DEBUG is not set +# CONFIG_MAGIC_SYSRQ is not set +# CONFIG_MIPS_UNCACHED is not set + +# +# Library routines +# +# CONFIG_ZLIB_INFLATE is not set +# CONFIG_ZLIB_DEFLATE is not set diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/setup.c linux/arch/mips/kernel/setup.c --- linux.orig/arch/mips/kernel/setup.c Fri Jan 24 10:25:54 2003 +++ linux/arch/mips/kernel/setup.c Tue Feb 4 15:24:28 2003 @@ -490,6 +490,7 @@ void victor_mpc30x_setup(void); void ibm_workpad_setup(void); void casio_e55_setup(void); + void tanbac_tb0226_setup(void); void jmr3927_setup(void); void it8172_setup(void); void swarm_setup(void); @@ -614,6 +615,11 @@ #ifdef CONFIG_CASIO_E55 case MACH_CASIO_E55: casio_e55_setup(); + break; +#endif +#ifdef CONFIG_TANBAC_TB0226 + case MACH_TANBAC_TB0226: + tanbac_tb0226_setup(); break; #endif } diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/Makefile linux/arch/mips/vr41xx/tanbac-tb0226/Makefile --- linux.orig/arch/mips/vr41xx/tanbac-tb0226/Makefile Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/vr41xx/tanbac-tb0226/Makefile Tue Feb 4 15:24:28 2003 @@ -0,0 +1,19 @@ +# +# Makefile for the TANBAC TB0226 specific parts of the kernel +# +# Note! Dependencies are done automagically by 'make dep', which also +# removes any old dependencies. DON'T put your own dependencies here +# unless it's something special (ie not a .c file). +# + +USE_STANDARD_AS_RULE := true + +O_TARGET := tb0226.o + +all: tb0226.o + +obj-y := init.o setup.o + +obj-$(CONFIG_PCI) += pci_fixup.o + +include $(TOPDIR)/Rules.make diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/init.c linux/arch/mips/vr41xx/tanbac-tb0226/init.c --- linux.orig/arch/mips/vr41xx/tanbac-tb0226/init.c Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/vr41xx/tanbac-tb0226/init.c Tue Feb 4 15:24:28 2003 @@ -0,0 +1,68 @@ +/* + * FILE NAME + * arch/mips/vr41xx/tanbac-tb0226/init.c + * + * BRIEF MODULE DESCRIPTION + * Initialisation code for the TANBAC TB0226. + * + * Copyright 2002,2003 Yoichi Yuasa + * yuasa@hh.iij4u.or.jp + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include + +#include +#include +#include +#include + +char arcs_cmdline[CL_SIZE]; + +const char *get_system_type(void) +{ + return "TANBAC TB0226"; +} + +void __init bus_error_init(void) +{ +} + +void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec) +{ + u32 config; + int i; + + /* + * collect args and prepare cmd_line + */ + for (i = 1; i < argc; i++) { + strcat(arcs_cmdline, argv[i]); + if (i < (argc - 1)) + strcat(arcs_cmdline, " "); + } + + mips_machgroup = MACH_GROUP_NEC_VR41XX; + mips_machtype = MACH_TANBAC_TB0226; + + switch (mips_cpu.processor_id) { + case PRID_VR4131_REV1_2: + config = read_c0_config(); + config &= ~0x00000030UL; + config |= 0x00410000UL; + write_c0_config(config); + break; + default: + break; + } +} + +void __init prom_free_prom_memory (void) +{ +} diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/pci_fixup.c linux/arch/mips/vr41xx/tanbac-tb0226/pci_fixup.c --- linux.orig/arch/mips/vr41xx/tanbac-tb0226/pci_fixup.c Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/vr41xx/tanbac-tb0226/pci_fixup.c Tue Feb 4 15:24:28 2003 @@ -0,0 +1,87 @@ +/* + * FILE NAME + * arch/mips/vr41xx/tanbac-tb0226/pci_fixup.c + * + * BRIEF MODULE DESCRIPTION + * The TANBAC TB0226 specific PCI fixups. + * + * Copyright 2002,2003 Yoichi Yuasa + * yuasa@hh.iij4u.or.jp + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include + +#include + +void __init pcibios_fixup_resources(struct pci_dev *dev) +{ +} + +void __init pcibios_fixup(void) +{ +} + +void __init pcibios_fixup_irqs(void) +{ + struct pci_dev *dev; + u8 slot, pin; + + pci_for_each_dev(dev) { + slot = PCI_SLOT(dev->devfn); + dev->irq = 0; + + switch (slot) { + case 12: + vr41xx_set_irq_trigger(GD82559_1_PIN, TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(GD82559_1_PIN, LEVEL_LOW); + dev->irq = GD82559_1_IRQ; + break; + case 13: + vr41xx_set_irq_trigger(GD82559_2_PIN, TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(GD82559_2_PIN, LEVEL_LOW); + dev->irq = GD82559_2_IRQ; + break; + case 14: + pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin); + switch (pin) { + case 1: + vr41xx_set_irq_trigger(UPD720100_INTA_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(UPD720100_INTA_PIN, LEVEL_LOW); + dev->irq = UPD720100_INTA_IRQ; + break; + case 2: + vr41xx_set_irq_trigger(UPD720100_INTB_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(UPD720100_INTB_PIN, LEVEL_LOW); + dev->irq = UPD720100_INTB_IRQ; + break; + case 3: + vr41xx_set_irq_trigger(UPD720100_INTC_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(UPD720100_INTC_PIN, LEVEL_LOW); + dev->irq = UPD720100_INTC_IRQ; + break; + } + break; + } + + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq); + } +} + +unsigned int pcibios_assign_all_busses(void) +{ + return 0; +} diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c Tue Feb 4 15:24:28 2003 @@ -0,0 +1,113 @@ +/* + * FILE NAME + * arch/mips/vr41xx/tanbac-tb0226/setup.c + * + * BRIEF MODULE DESCRIPTION + * Setup for the TANBAC TB0226. + * + * Copyright 2002,2003 Yoichi Yuasa + * yuasa@hh.iij4u.or.jp + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#ifdef CONFIG_BLK_DEV_INITRD +extern unsigned long initrd_start, initrd_end; +extern void * __rd_start, * __rd_end; +#endif + +#ifdef CONFIG_PCI +static struct resource vr41xx_pci_io_resource = { + "PCI I/O space", + VR41XX_PCI_IO_START, + VR41XX_PCI_IO_END, + IORESOURCE_IO +}; + +static struct resource vr41xx_pci_mem_resource = { + "PCI memory space", + VR41XX_PCI_MEM_START, + VR41XX_PCI_MEM_END, + IORESOURCE_MEM +}; + +extern struct pci_ops vr41xx_pci_ops; + +struct pci_channel mips_pci_channels[] = { + {&vr41xx_pci_ops, &vr41xx_pci_io_resource, &vr41xx_pci_mem_resource, 0, 256}, + {NULL, NULL, NULL, 0, 0} +}; + +struct vr41xx_pci_address_space vr41xx_pci_mem1 = { + VR41XX_PCI_MEM1_BASE, + VR41XX_PCI_MEM1_MASK, + IO_MEM1_RESOURCE_START +}; + +struct vr41xx_pci_address_space vr41xx_pci_mem2 = { + VR41XX_PCI_MEM2_BASE, + VR41XX_PCI_MEM2_MASK, + IO_MEM2_RESOURCE_START +}; + +struct vr41xx_pci_address_space vr41xx_pci_io = { + VR41XX_PCI_IO_BASE, + VR41XX_PCI_IO_MASK, + IO_PORT_RESOURCE_START +}; + +static struct vr41xx_pci_address_map pci_address_map = { + &vr41xx_pci_mem1, + &vr41xx_pci_mem2, + &vr41xx_pci_io +}; +#endif + +void __init tanbac_tb0226_setup(void) +{ + set_io_port_base(IO_PORT_BASE); + ioport_resource.start = IO_PORT_RESOURCE_START; + ioport_resource.end = IO_PORT_RESOURCE_END; + iomem_resource.start = IO_MEM1_RESOURCE_START; + iomem_resource.end = IO_MEM2_RESOURCE_END; + +#ifdef CONFIG_BLK_DEV_INITRD + ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); + initrd_start = (unsigned long)&__rd_start; + initrd_end = (unsigned long)&__rd_end; +#endif + + _machine_restart = vr41xx_restart; + _machine_halt = vr41xx_halt; + _machine_power_off = vr41xx_power_off; + + board_time_init = vr41xx_time_init; + board_timer_setup = vr41xx_timer_setup; + +#ifdef CONFIG_FB + conswitchp = &dummy_con; +#endif + + vr41xx_bcu_init(); + + vr41xx_cmu_init(0); + + vr41xx_siu_init(SIU_RS232C, 0); + +#ifdef CONFIG_PCI + vr41xx_pciu_init(&pci_address_map); +#endif +} diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/bootinfo.h linux/include/asm-mips/bootinfo.h --- linux.orig/include/asm-mips/bootinfo.h Wed Jan 29 10:29:12 2003 +++ linux/include/asm-mips/bootinfo.h Tue Feb 4 15:24:28 2003 @@ -179,6 +179,7 @@ #define MACH_VICTOR_MPC30X 3 /* Victor MP-C303/304 */ #define MACH_IBM_WORKPAD 4 /* IBM WorkPad z50 */ #define MACH_CASIO_E55 5 /* CASIO CASSIOPEIA E-10/15/55/65 */ +#define MACH_TANBAC_TB0226 6 /* TANBAC TB0226 (MBASE) */ #define CL_SIZE (256) diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/tb0226.h linux/include/asm-mips/vr41xx/tb0226.h --- linux.orig/include/asm-mips/vr41xx/tb0226.h Thu Jan 1 09:00:00 1970 +++ linux/include/asm-mips/vr41xx/tb0226.h Tue Feb 4 15:24:28 2003 @@ -0,0 +1,69 @@ +/* + * FILE NAME + * include/asm-mips/vr41xx/tb0226.h + * + * BRIEF MODULE DESCRIPTION + * Include file for TANBAC TB0226. + * + * Copyright 2002,2003 Yoichi Yuasa + * yuasa@hh.iij4u.or.jp + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#ifndef __TANBAC_TB0226_H +#define __TANBAC_TB0226_H + +#include +#include + +/* + * Board specific address mapping + */ +#define VR41XX_PCI_MEM1_BASE 0x10000000 +#define VR41XX_PCI_MEM1_SIZE 0x04000000 +#define VR41XX_PCI_MEM1_MASK 0x7c000000 + +#define VR41XX_PCI_MEM2_BASE 0x14000000 +#define VR41XX_PCI_MEM2_SIZE 0x02000000 +#define VR41XX_PCI_MEM2_MASK 0x7e000000 + +#define VR41XX_PCI_IO_BASE 0x16000000 +#define VR41XX_PCI_IO_SIZE 0x02000000 +#define VR41XX_PCI_IO_MASK 0x7e000000 + +#define VR41XX_PCI_IO_START 0x01000000 +#define VR41XX_PCI_IO_END 0x01ffffff + +#define VR41XX_PCI_MEM_START 0x12000000 +#define VR41XX_PCI_MEM_END 0x15ffffff + +#define IO_PORT_BASE KSEG1ADDR(VR41XX_PCI_IO_BASE) +#define IO_PORT_RESOURCE_START 0 +#define IO_PORT_RESOURCE_END VR41XX_PCI_IO_SIZE +#define IO_MEM1_RESOURCE_START VR41XX_PCI_MEM1_BASE +#define IO_MEM1_RESOURCE_END (VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE) +#define IO_MEM2_RESOURCE_START VR41XX_PCI_MEM2_BASE +#define IO_MEM2_RESOURCE_END (VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE) + +/* + * General-Purpose I/O Pin Number + */ +#define GD82559_1_PIN 2 +#define GD82559_2_PIN 3 +#define UPD720100_INTA_PIN 4 +#define UPD720100_INTB_PIN 8 +#define UPD720100_INTC_PIN 13 + +/* + * Interrupt Number + */ +#define GD82559_1_IRQ GIU_IRQ(GD82559_1_PIN) +#define GD82559_2_IRQ GIU_IRQ(GD82559_2_PIN) +#define UPD720100_INTA_IRQ GIU_IRQ(UPD720100_INTA_PIN) +#define UPD720100_INTB_IRQ GIU_IRQ(UPD720100_INTB_PIN) +#define UPD720100_INTC_IRQ GIU_IRQ(UPD720100_INTC_PIN) + +#endif /* __TANBAC_TB0226_H */ --Multipart_Tue__4_Feb_2003_15:40:25_+0900_08258ab8-- From agx@sigxcpu.org Tue Feb 4 09:25:57 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 09:25:58 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:1239 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 09:25:57 +0000 Received: from bogon.sigxcpu.org (unknown [134.34.147.122]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 9BD9C2BC2D for ; Tue, 4 Feb 2003 10:25:54 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 781844AF4C; Tue, 4 Feb 2003 10:24:17 +0100 (CET) Date: Tue, 4 Feb 2003 10:24:17 +0100 From: Guido Guenther To: Linux-MIPS Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030204092417.GR16674@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , Linux-MIPS References: <20030204061323.GA27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030204061323.GA27302@pureza.melbourne.sgi.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips Content-Length: 270 Lines: 5 On Tue, Feb 04, 2003 at 05:13:23PM +1100, Andrew Clausen wrote: > Some kernel parameters are auto-generated. eg: root= (always has been > broken). Anyway, the old version of cmdline.c added these auto-generated Can you explain in what way root= was broken? -- Guido From ralf@linux-mips.org Tue Feb 4 12:44:13 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 12:44:14 +0000 (GMT) Received: from p508B4EE8.dip.t-dialin.net ([IPv6:::ffff:80.139.78.232]:43711 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 12:44:13 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h14Ci7m29640; Tue, 4 Feb 2003 13:44:07 +0100 Date: Tue, 4 Feb 2003 13:44:06 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips@linux-mips.org Subject: Re: [patch] TANBAC TB0226(NEC VR4131) Message-ID: <20030204134406.A29585@linux-mips.org> References: <20030204154025.340fdf40.yoichi_yuasa@montavista.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030204154025.340fdf40.yoichi_yuasa@montavista.co.jp>; from yoichi_yuasa@montavista.co.jp on Tue, Feb 04, 2003 at 03:40:25PM +0900 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 362 Lines: 11 On Tue, Feb 04, 2003 at 03:40:25PM +0900, Yoichi Yuasa wrote: > This patch is based on linux_2_4 tag cvs tree on ftp.linux-mips.org > Would you apply this patch to CVS on ftp.linux-mips.org? Could you also make a patch against 2.5? It's a huge PITA when 2.4 and 2.5 trees are diverging so I'd really like to have a patch for 2.5 also. Patch applied, Ralf From ralf@linux-mips.org Tue Feb 4 12:54:38 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 12:54:38 +0000 (GMT) Received: from p508B4EE8.dip.t-dialin.net ([IPv6:::ffff:80.139.78.232]:51135 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 12:54:38 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h14CsVY29834; Tue, 4 Feb 2003 13:54:31 +0100 Date: Tue, 4 Feb 2003 13:54:31 +0100 From: Ralf Baechle To: Vivien Chappelier Cc: Jun Sun , linux-mips@linux-mips.org Subject: Re: [PATCH 2.5] r4k_switch task_struct/thread_info fixes Message-ID: <20030204135431.A29811@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivienc@nerim.net on Mon, Feb 03, 2003 at 11:21:50PM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 396 Lines: 10 On Mon, Feb 03, 2003 at 11:21:50PM +0100, Vivien Chappelier wrote: > This patch fixes an incorrect use of THREAD_FLAGS instead of > TI_FLAGS when clearing the TIF_USEDFPU flag of the current thread info, > and an incorrect assumption when using ST_OFF, that the stack is shared > with task_struct, whereas it is shared with thread_info in 2.5. Ok. You missed r2300_switch.S though :) Ralf From jormes@wideopenwest.com Tue Feb 4 15:33:03 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 15:33:03 +0000 (GMT) Received: from heffalump.fnal.gov ([IPv6:::ffff:131.225.9.20]:4828 "EHLO fnal.gov") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 15:33:03 +0000 Received: from ppd89948 ([131.225.55.68]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0H9S00077J70ZJ@smtp.fnal.gov> for linux-mips@linux-mips.org; Tue, 04 Feb 2003 09:33:00 -0600 (CST) Date: Tue, 04 Feb 2003 09:33:00 -0600 From: Jason Ormes Subject: ip27-init.c problem To: linux-mips@linux-mips.org Message-id: <001801c2cc62$b319a9a0$4437e183@fermi.win.fnal.gov> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jormes@wideopenwest.com Precedence: bulk X-list: linux-mips Content-Length: 2440 Lines: 57 Hello, I downloaded the linux_2_4 branch from the cvs repository and am trying to build a kernel for an origin 200. I'm using binutils-mips64-linux-2.13.1-1 and egcs-mips64-linux-1.1.2-4 on a redhat 8.0 system. I am getting these errors in ip27-init.c when trying to build the kernel. mips64-linux-gcc -D__KERNEL__ -I/home/jason/mips/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /home/jason/mips/linux/include/asm/gcc -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r8000 -mips4 -Wa,-32 -Wa,-mgp64 -nostdinc -iwithprefix include -DKBUILD_BASENAME=ip27_init -c -o ip27-init.o ip27-init.c ip27-init.c:48: parse error before `boot_cpumask' ip27-init.c:48: warning: type defaults to `int' in declaration of `boot_cpumask' ip27-init.c:48: warning: data definition has no type or storage class ip27-init.c:107: parse error before `cpumask_t' ip27-init.c:109: warning: function declaration isn't a prototype ip27-init.c: In function `do_cpumask': ip27-init.c:116: `nasid' undeclared (first use in this function) ip27-init.c:116: (Each undeclared identifier is reported only once ip27-init.c:116: for each function it appears in.) ip27-init.c:124: `cnode' undeclared (first use in this function) ip27-init.c:125: `highest' undeclared (first use in this function) ip27-init.c:130: warning: implicit declaration of function `CPUMASK_SETB' ip27-init.c:130: invalid type argument of `unary *' ip27-init.c: At top level: ip27-init.c:147: parse error before `*' ip27-init.c:148: warning: function declaration isn't a prototype ip27-init.c: In function `cpu_node_probe': ip27-init.c:163: invalid type argument of `unary *' ip27-init.c:170: invalid type argument of `unary *' ip27-init.c: In function `cpu_enabled': ip27-init.c:187: warning: implicit declaration of function `CPUMASK_TSTB' ip27-init.c: In function `mlreset': ip27-init.c:203: warning: implicit declaration of function `CPUMASK_CLRALL' make[2]: *** [ip27-init.o] Error 1 make[2]: Leaving directory `/home/jason/mips/linux/arch/mips/sgi-ip27' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/home/jason/mips/linux/arch/mips/sgi-ip27' make: *** [_dir_arch/mips/sgi-ip27] Error 2 I did make ARCH=mips64 clean make ARCH=mips64 menuconfig and turned on ip27 support make ARCH=mips64 deps make ARCH=mips64 all can someone point me in the right direction out of this problem? Jason Ormes From ralf@linux-mips.org Tue Feb 4 15:52:26 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 15:52:27 +0000 (GMT) Received: from p508B4EE8.dip.t-dialin.net ([IPv6:::ffff:80.139.78.232]:707 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 15:52:26 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h14FqMq00560; Tue, 4 Feb 2003 16:52:22 +0100 Date: Tue, 4 Feb 2003 16:52:22 +0100 From: Ralf Baechle To: Jason Ormes Cc: linux-mips@linux-mips.org Subject: Re: ip27-init.c problem Message-ID: <20030204165222.A30704@linux-mips.org> References: <001801c2cc62$b319a9a0$4437e183@fermi.win.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <001801c2cc62$b319a9a0$4437e183@fermi.win.fnal.gov>; from jormes@wideopenwest.com on Tue, Feb 04, 2003 at 09:33:00AM -0600 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1055 Lines: 23 On Tue, Feb 04, 2003 at 09:33:00AM -0600, Jason Ormes wrote: > I downloaded the linux_2_4 branch from the cvs repository and am > trying to build a kernel for an origin 200. I'm using > binutils-mips64-linux-2.13.1-1 and egcs-mips64-linux-1.1.2-4 on a redhat > 8.0 system. I am getting these errors in ip27-init.c when trying to > build the kernel. > > mips64-linux-gcc -D__KERNEL__ -I/home/jason/mips/linux/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common > -fomit-frame-pointer -I /home/jason/mips/linux/include/asm/gcc -mabi=64 > -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mcpu=r8000 -mips4 -Wa,-32 > -Wa,-mgp64 -nostdinc -iwithprefix include -DKBUILD_BASENAME=ip27_init > -c -o ip27-init.o ip27-init.c > ip27-init.c:48: parse error before `boot_cpumask' > ip27-init.c:48: warning: type defaults to `int' in declaration of > `boot_cpumask' [...] You're trying to build a uniprocessor kernel. That's currently not supported. Just enable CONFIG_SMP. Do you actually have a uniprocessor Origin? Ralf From vivienc@nerim.net Tue Feb 4 22:39:19 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 22:39:20 +0000 (GMT) Received: from smtp-102.noc.nerim.net ([IPv6:::ffff:62.4.17.102]:3596 "EHLO mallaury.noc.nerim.net") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 22:39:19 +0000 Received: from melkor (vivienc.net1.nerim.net [213.41.134.233]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 2B46C62E5E; Tue, 4 Feb 2003 23:39:16 +0100 (CET) Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.36 #1 (Debian)) id 18gBkD-0000b8-00; Tue, 04 Feb 2003 23:40:45 +0100 Date: Tue, 4 Feb 2003 23:40:45 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Jun Sun Cc: linux-mips@linux-mips.org Subject: [PATCH 2.5] daily r4k_switch fixes (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vivienc@nerim.net Precedence: bulk X-list: linux-mips Content-Length: 1560 Lines: 55 forgotten Cc: ---------- Forwarded message ---------- Date: Tue, 4 Feb 2003 22:09:08 +0100 (CET) From: Vivien Chappelier To: Ralf Baechle Subject: [PATCH 2.5] daily r4k_switch fixes Hi, TIF_USEDFPU and _TIF_USEDFPU are not the same thing at all, not surprisingly introducing bugs and confusion in r4k_switch.S (mips64) and r2300_switch.S (mips) :) On Tue, 4 Feb 2003, Ralf Baechle wrote: > Ok. You missed r2300_switch.S though :) Not this time :) Vivien. Index: arch/mips/kernel/r2300_switch.S =================================================================== RCS file: /home/cvs/linux/arch/mips/kernel/r2300_switch.S,v retrieving revision 1.28 diff -u -r1.28 r2300_switch.S --- arch/mips/kernel/r2300_switch.S 4 Feb 2003 12:53:57 -0000 1.28 +++ arch/mips/kernel/r2300_switch.S 4 Feb 2003 20:59:01 -0000 @@ -61,7 +61,7 @@ */ lw t3, TASK_THREAD_INFO(a0) lw t0, TI_FLAGS(t3) - li t1, TIF_USEDFPU + li t1, _TIF_USEDFPU and t2, t0, t1 beqz t2, 1f nor t1, zero, t1 Index: arch/mips64/kernel/r4k_switch.S =================================================================== RCS file: /home/cvs/linux/arch/mips64/kernel/r4k_switch.S,v retrieving revision 1.23 diff -u -r1.23 r4k_switch.S --- arch/mips64/kernel/r4k_switch.S 4 Feb 2003 12:53:57 -0000 1.23 +++ arch/mips64/kernel/r4k_switch.S 4 Feb 2003 20:59:09 -0000 @@ -56,7 +56,7 @@ */ ld t3, TASK_THREAD_INFO(a0) ld t0, TI_FLAGS(t3) - li t1, TIF_USEDFPU + li t1, _TIF_USEDFPU and t2, t0, t1 beqz t2, 1f nor t1, zero, t1 From clausen@pureza.melbourne.sgi.com Tue Feb 4 22:40:49 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 22:40:49 +0000 (GMT) Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:975 "EHLO rj.sgi.com") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 22:40:49 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h14KeAG8024224; Tue, 4 Feb 2003 12:40:13 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA26579; Wed, 5 Feb 2003 09:39:58 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h14MdWMd028868; Wed, 5 Feb 2003 09:39:32 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h14MdU1A028866; Wed, 5 Feb 2003 09:39:30 +1100 Date: Wed, 5 Feb 2003 09:39:30 +1100 From: Andrew Clausen To: Guido Guenther , Linux-MIPS Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030204223930.GD27302@pureza.melbourne.sgi.com> References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030204092417.GR16674@bogon.ms20.nix> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 697 Lines: 17 On Tue, Feb 04, 2003 at 10:24:17AM +0100, Guido Guenther wrote: > On Tue, Feb 04, 2003 at 05:13:23PM +1100, Andrew Clausen wrote: > > Some kernel parameters are auto-generated. eg: root= (always has been > > broken). Anyway, the old version of cmdline.c added these auto-generated > Can you explain in what way root= was broken? It was blindly copying from the environment variable a string looking like dksc(0,1,2). This should be translated (somehow) to something looking like /dev/sdb1. This would have to be done after the hard disk probes. Does Linux have some other notation for addressing devices by their location on the bus? (I recall a flamewar on the topic...) Cheers, Andrew From vivienc@nerim.net Tue Feb 4 22:53:12 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 22:53:12 +0000 (GMT) Received: from smtp-102.noc.nerim.net ([IPv6:::ffff:62.4.17.102]:35596 "EHLO mallaury.noc.nerim.net") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 22:53:12 +0000 Received: from melkor (vivienc.net1.nerim.net [213.41.134.233]) by mallaury.noc.nerim.net (Postfix) with ESMTP id C1DB962D6E; Tue, 4 Feb 2003 23:53:08 +0100 (CET) Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.36 #1 (Debian)) id 18gBxe-0000cc-00; Tue, 04 Feb 2003 23:54:38 +0100 Date: Tue, 4 Feb 2003 23:54:38 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle Cc: Jun Sun , linux-mips@linux-mips.org Subject: [PATCH 2.5] clear USEDFPU in copy_thread Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vivienc@nerim.net Precedence: bulk X-list: linux-mips Content-Length: 2103 Lines: 61 Hi, When copying a thread, access to the FPU is disabled by clearing the ST0_CU1 bit in the new thread saved CP0_STATUS register. However, the corresponding TIF_USEDFPU flag is not cleared at it should to indicate the FPU has not yet been used by the new process. This patch also clears user_tid in mips64 code, and moves it away from the FPU comment in the mips code. Vivien. Index: arch/mips64/kernel/process.c =================================================================== RCS file: /home/cvs/linux/arch/mips64/kernel/process.c,v retrieving revision 1.36 diff -u -r1.36 process.c --- arch/mips64/kernel/process.c 9 Jan 2003 19:16:50 -0000 1.36 +++ arch/mips64/kernel/process.c 4 Feb 2003 22:47:00 -0000 @@ -114,6 +114,8 @@ p->thread.reg29 = (unsigned long) childregs; p->thread.reg31 = (unsigned long) ret_from_fork; + p->user_tid = NULL; + /* * New tasks loose permission to use the fpu. This accelerates context * switching for most programs since they don't use the fpu. @@ -121,6 +123,7 @@ p->thread.cp0_status = read_c0_status() & ~(ST0_CU3|ST0_CU2|ST0_CU1|ST0_KSU); childregs->cp0_status &= ~(ST0_CU3|ST0_CU2|ST0_CU1); + clear_ti_thread_flag(ti, TIF_USEDFPU); return 0; } Index: arch/mips/kernel/process.c =================================================================== RCS file: /home/cvs/linux/arch/mips/kernel/process.c,v retrieving revision 1.50 diff -u -r1.50 process.c --- arch/mips/kernel/process.c 9 Jan 2003 19:16:50 -0000 1.50 +++ arch/mips/kernel/process.c 4 Feb 2003 22:47:04 -0000 @@ -117,6 +117,8 @@ p->thread.reg29 = (unsigned long) childregs; p->thread.reg31 = (unsigned long) ret_from_fork; + p->user_tid = NULL; + /* * New tasks loose permission to use the fpu. This accelerates context * switching for most programs since they don't use the fpu. @@ -124,7 +126,7 @@ p->thread.cp0_status = read_c0_status() & ~(ST0_CU2|ST0_CU1|KU_MASK); childregs->cp0_status &= ~(ST0_CU2|ST0_CU1); - p->user_tid = NULL; + clear_ti_thread_flag(ti, TIF_USEDFPU); return 0; } From vivienc@nerim.net Tue Feb 4 22:57:41 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 22:57:42 +0000 (GMT) Received: from smtp-102.noc.nerim.net ([IPv6:::ffff:62.4.17.102]:46860 "EHLO mallaury.noc.nerim.net") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 22:57:41 +0000 Received: from melkor (vivienc.net1.nerim.net [213.41.134.233]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 7DE6662E41; Tue, 4 Feb 2003 23:57:38 +0100 (CET) Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.36 #1 (Debian)) id 18gC20-0000cv-00; Tue, 04 Feb 2003 23:59:08 +0100 Date: Tue, 4 Feb 2003 23:59:07 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH 2.5] disable interrupts in entry.S Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vivienc@nerim.net Precedence: bulk X-list: linux-mips Content-Length: 695 Lines: 23 Hi, A mtc0 is missing in entry.S to disable interrupts while doing ret_from_irq, ret_from_exception and resume_userspace. Vivien. Index: arch/mips64/kernel/entry.S =================================================================== RCS file: /home/cvs/linux/arch/mips64/kernel/entry.S,v retrieving revision 1.23 diff -u -r1.23 entry.S --- arch/mips64/kernel/entry.S 9 Jan 2003 19:25:15 -0000 1.23 +++ arch/mips64/kernel/entry.S 4 Feb 2003 20:59:33 -0000 @@ -29,6 +29,7 @@ mfc0 t0, CP0_STATUS # make sure need_resched and ori t0, t0, 1 # signals dont change between xori t0, t0, 1 # sampling and return + mtc0 t0, CP0_STATUS SSNOP; SSNOP; SSNOP LONG_L a2, TI_FLAGS($28) From agx@sigxcpu.org Tue Feb 4 23:13:27 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 23:13:28 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:23256 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 23:13:27 +0000 Received: from bogon.sigxcpu.org (kons-d9bb55c6.pool.mediaWays.net [217.187.85.198]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id F1FAF2BC2D for ; Wed, 5 Feb 2003 00:13:22 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 0FEB24AF4C; Wed, 5 Feb 2003 00:12:03 +0100 (CET) Date: Wed, 5 Feb 2003 00:12:03 +0100 From: Guido Guenther To: linux-mips@linux-mips.org Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030204231203.GY16674@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , linux-mips@linux-mips.org References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> <20030204223930.GD27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030204223930.GD27302@pureza.melbourne.sgi.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips Content-Length: 615 Lines: 12 On Wed, Feb 05, 2003 at 09:39:30AM +1100, Andrew Clausen wrote: > It was blindly copying from the environment variable a string > looking like dksc(0,1,2). This should be translated (somehow) > to something looking like /dev/sdb1. This would have to be > done after the hard disk probes. If you set OSLoadPartition=/dev/sda1 (or whatever) - it allows you to boot from hard disk without any boot loader involved. If you have a bootloader (which is only true for IP22 [1]) it sets up the kernels commandline properly anyway - so where's the problem? nfsroot? -- Guido [1] talking only about SGI mips systems here From clausen@pureza.melbourne.sgi.com Tue Feb 4 23:19:43 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 23:19:43 +0000 (GMT) Received: from zok.sgi.com ([IPv6:::ffff:204.94.215.101]:13288 "EHLO zok.sgi.com") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 23:19:43 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h14MQZKp004980; Tue, 4 Feb 2003 14:26:36 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA27549; Wed, 5 Feb 2003 10:19:36 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h14NJ9Md028916; Wed, 5 Feb 2003 10:19:10 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h14NJ9g5028914; Wed, 5 Feb 2003 10:19:09 +1100 Date: Wed, 5 Feb 2003 10:19:09 +1100 From: Andrew Clausen To: Guido Guenther , linux-mips@linux-mips.org Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030204231909.GE27302@pureza.melbourne.sgi.com> References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> <20030204223930.GD27302@pureza.melbourne.sgi.com> <20030204231203.GY16674@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030204231203.GY16674@bogon.ms20.nix> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 943 Lines: 23 On Wed, Feb 05, 2003 at 12:12:03AM +0100, Guido Guenther wrote: > On Wed, Feb 05, 2003 at 09:39:30AM +1100, Andrew Clausen wrote: > > It was blindly copying from the environment variable a string > > looking like dksc(0,1,2). This should be translated (somehow) > > to something looking like /dev/sdb1. This would have to be > > done after the hard disk probes. > If you set OSLoadPartition=/dev/sda1 (or whatever) - it allows you to > boot from hard disk without any boot loader involved. Huh? The firmware uses something looking like OSLoadPartition=dksc(0,1,2), not /dev/sda1. > If you have a > bootloader (which is only true for IP22 [1]) it sets up the kernels > commandline properly anyway - so where's the problem? nfsroot? The problem is the firmware (on my IP27, anyway) uses a different form to Linux for OSLoadPartition. OSLoadPartition tells the firmware / bootloader (sash here) where to find the kernel. Cheers, Andrew From agx@sigxcpu.org Tue Feb 4 23:46:49 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 23:46:50 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:24536 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 23:46:49 +0000 Received: from bogon.sigxcpu.org (kons-d9bb55c6.pool.mediaWays.net [217.187.85.198]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 046142BC2D for ; Wed, 5 Feb 2003 00:46:48 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 6BD144AF4C; Wed, 5 Feb 2003 00:45:29 +0100 (CET) Date: Wed, 5 Feb 2003 00:45:29 +0100 From: Guido Guenther To: linux-mips@linux-mips.org Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030204234529.GZ16674@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , linux-mips@linux-mips.org References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> <20030204223930.GD27302@pureza.melbourne.sgi.com> <20030204231203.GY16674@bogon.ms20.nix> <20030204231909.GE27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030204231909.GE27302@pureza.melbourne.sgi.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips Content-Length: 1089 Lines: 22 On Wed, Feb 05, 2003 at 10:19:09AM +1100, Andrew Clausen wrote: > Huh? The firmware uses something looking like OSLoadPartition=dksc(0,1,2), > not /dev/sda1. Sure. But what we do on IP22 is to let the kernel look at OSLoadPartition and use that as the root device - so we're actually interested in linux device names. This is basically done since we can't store the root device in OSLoadOptions due to limited space. > > If you have a > > bootloader (which is only true for IP22 [1]) it sets up the kernels > > commandline properly anyway - so where's the problem? nfsroot? > > The problem is the firmware (on my IP27, anyway) uses a different > form to Linux for OSLoadPartition. OSLoadPartition tells the > firmware / bootloader (sash here) where to find the kernel. Again: we don't care what the firmware wants here, we're interested what the kernel expects. Why do you need sash for booting anyways? Can't you let the PROM boot the kernel directly? Anyways, I won't object to change OSLoadPartition, we have a bootloader on IP22 so this isn't actually needed anymore. -- Guido From clausen@pureza.melbourne.sgi.com Tue Feb 4 23:56:15 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Feb 2003 23:56:15 +0000 (GMT) Received: from zok.sgi.com ([IPv6:::ffff:204.94.215.101]:38125 "EHLO zok.sgi.com") by linux-mips.org with ESMTP id ; Tue, 4 Feb 2003 23:56:15 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h14N39Kp007330; Tue, 4 Feb 2003 15:03:10 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA28123; Wed, 5 Feb 2003 10:56:10 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h14NthMd028956; Wed, 5 Feb 2003 10:55:44 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h14NthTu028954; Wed, 5 Feb 2003 10:55:43 +1100 Date: Wed, 5 Feb 2003 10:55:43 +1100 From: Andrew Clausen To: Guido Guenther , linux-mips@linux-mips.org Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030204235543.GG27302@pureza.melbourne.sgi.com> References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> <20030204223930.GD27302@pureza.melbourne.sgi.com> <20030204231203.GY16674@bogon.ms20.nix> <20030204231909.GE27302@pureza.melbourne.sgi.com> <20030204234529.GZ16674@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030204234529.GZ16674@bogon.ms20.nix> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 1461 Lines: 39 On Wed, Feb 05, 2003 at 12:45:29AM +0100, Guido Guenther wrote: > On Wed, Feb 05, 2003 at 10:19:09AM +1100, Andrew Clausen wrote: > > Huh? The firmware uses something looking like OSLoadPartition=dksc(0,1,2), > > not /dev/sda1. > Sure. But what we do on IP22 is to let the kernel look at OSLoadPartition and > use that as the root device - so we're actually interested in > linux device names. This is basically done since we can't store the root > device in OSLoadOptions due to limited space. Limited space? Ah. I understand now. > > > If you have a > > > bootloader (which is only true for IP22 [1]) it sets up the kernels > > > commandline properly anyway - so where's the problem? nfsroot? > > > > The problem is the firmware (on my IP27, anyway) uses a different > > form to Linux for OSLoadPartition. OSLoadPartition tells the > > firmware / bootloader (sash here) where to find the kernel. > > Again: we don't care what the firmware wants here, I do. > Why do you need sash for booting anyways? Can't > you let the PROM boot the kernel directly? No. I can't figure out why. In any case, the PROM uses OSLoadPartition to find the kernel. > Anyways, I won't object to change OSLoadPartition, we have a bootloader > on IP22 so this isn't actually needed anymore. It is on IP27. So, we should obviously support OSLoadPartition=/dev/sda1 (=> root=/dev/sda1), but it would also be nice to support OSLoadPartition=dksc(0,1,3). Cheers, Andrew From jsun@orion.mvista.com Wed Feb 5 00:03:01 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 00:03:02 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:15863 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 00:03:00 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id h1502oT10577; Tue, 4 Feb 2003 16:02:50 -0800 Date: Tue, 4 Feb 2003 16:02:50 -0800 From: Jun Sun To: Ralf Baechle Cc: Juan Quintela , linux-mips@linux-mips.org, jsun@mvista.com, Ralf Baechle Subject: Re: [RFC & PATCH] fixing tlb flush race problem on smp Message-ID: <20030204160250.F5149@mvista.com> References: <20030121143726.C16939@mvista.com> <86bs297hpd.fsf@trasno.mitica> <20030127170346.S11633@mvista.com> <20030129090627.D7741@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030129090627.D7741@linux-mips.org>; from ralf@linux-mips.org on Wed, Jan 29, 2003 at 09:06:27AM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 20523 Lines: 743 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is a complete patch for both mips/mips64, 2.4 and 2.5. Of course only 2.4/mips combo is tested. The clear_bit/set_bit actually need to be protected. The flag setting needs to be in sync with the actual hardware setting (set_entry_hi/set current pgd). Otherwise an tlb flushing IPI may does the wrong thing. Jun On Wed, Jan 29, 2003 at 09:06:27AM +0100, Ralf Baechle wrote: > On Mon, Jan 27, 2003 at 05:03:46PM -0800, Jun Sun wrote: > > > I also find a stupid typo and a subtle hole in my original patch. > > Here is an updated version, for 2.4/mips only. If it looks ok, I > > will extend to other sub-arches/trees. > > > > This new one is pretty nice in that all mmu related operations > > are put into one file and it is much easier to ensure correctness > > later. > > I like this one. > > > + > > + /* > > + * Mark current->active_mm as not "active" anymore. > > + * We don't want to mislead possible IPI tlb flush routines. > > + */ > > + clear_bit(cpu, &prev->cpu_vm_mask); > > + set_bit(cpu, &next->cpu_vm_mask); > > + > > + local_irq_restore(flags); > > I don't think it's necessary to protect the clear_bit and set_bit operations > with local_irq_save ... local_irq_restore. > > In addition because switch_mm is always called with interrupts enabled you > can simplify that to local_irq_disable ... local_irq_enable. > > Ralf > --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="030204-2.4-smp-tlb-flush.patch" diff -Nru linux/arch/mips/mm/tlb-sb1.c.orig linux/arch/mips/mm/tlb-sb1.c --- linux/arch/mips/mm/tlb-sb1.c.orig Tue Feb 4 13:50:55 2003 +++ linux/arch/mips/mm/tlb-sb1.c Tue Feb 4 14:01:24 2003 @@ -172,9 +172,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); + drop_mmu_context(mm, cpu); } } local_irq_restore(flags); @@ -253,17 +251,10 @@ these entries, we just bump the asid. */ void local_flush_tlb_mm(struct mm_struct *mm) { - unsigned long flags; - int cpu; - local_irq_save(flags); - cpu = smp_processor_id(); + int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) { - write_c0_entryhi(cpu_asid(cpu, mm)); - } + drop_mmu_context(mm, cpu); } - local_irq_restore(flags); } /* Stolen from mips32 routines */ diff -Nru linux/arch/mips/mm/tlb-r4k.c.orig linux/arch/mips/mm/tlb-r4k.c --- linux/arch/mips/mm/tlb-r4k.c.orig Mon Jan 27 17:13:31 2003 +++ linux/arch/mips/mm/tlb-r4k.c Tue Feb 4 14:15:04 2003 @@ -76,16 +76,10 @@ int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - unsigned long flags; - #ifdef DEBUG_TLB printk("[tlbmm<%d>]", cpu_context(cpu, mm)); #endif - local_irq_save(flags); - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); - local_irq_restore(flags); + drop_mmu_context(mm,cpu); } } @@ -133,9 +127,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); + drop_mmu_context(mm, cpu); } local_irq_restore(flags); } diff -Nru linux/arch/mips/mm/tlb-r3k.c.orig linux/arch/mips/mm/tlb-r3k.c --- linux/arch/mips/mm/tlb-r3k.c.orig Mon Jan 27 17:13:31 2003 +++ linux/arch/mips/mm/tlb-r3k.c Tue Feb 4 14:09:04 2003 @@ -69,16 +69,10 @@ int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - unsigned long flags; - #ifdef DEBUG_TLB printk("[tlbmm<%lu>]", (unsigned long)cpu_context(cpu, mm)); #endif - local_irq_save(flags); - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); - local_irq_restore(flags); + drop_mmu_context(mm, cpu); } } @@ -119,9 +113,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); + drop_mmu_context(mm, cpu); } local_irq_restore(flags); } diff -Nru linux/arch/mips64/mm/tlb-sb1.c.orig linux/arch/mips64/mm/tlb-sb1.c --- linux/arch/mips64/mm/tlb-sb1.c.orig Mon Jan 27 17:13:34 2003 +++ linux/arch/mips64/mm/tlb-sb1.c Tue Feb 4 14:45:58 2003 @@ -180,9 +180,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); + drop_mmu_context(mm, cpu); } } local_irq_restore(flags); @@ -231,17 +229,10 @@ these entries, we just bump the asid. */ void local_flush_tlb_mm(struct mm_struct *mm) { - unsigned long flags; - int cpu; - local_irq_save(flags); - cpu = smp_processor_id(); + int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) { - write_c0_entryhi(cpu_asid(cpu, mm)); - } + drop_mmu_context(mm, cpu); } - local_irq_restore(flags); } /* Stolen from mips32 routines */ diff -Nru linux/arch/mips64/mm/tlb-r4k.c.orig linux/arch/mips64/mm/tlb-r4k.c --- linux/arch/mips64/mm/tlb-r4k.c.orig Mon Jan 27 17:13:34 2003 +++ linux/arch/mips64/mm/tlb-r4k.c Tue Feb 4 14:47:52 2003 @@ -80,16 +80,10 @@ int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - unsigned long flags; - #ifdef DEBUG_TLB printk("[tlbmm<%d>]", mm->context); #endif - local_irq_save(flags); - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); - local_irq_restore(flags); + drop_mmu_context(mm,cpu); } } @@ -137,9 +131,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); + drop_mmu_context(mm, cpu); } local_irq_restore(flags); } diff -Nru linux/arch/mips64/mm/tlb-andes.c.orig linux/arch/mips64/mm/tlb-andes.c --- linux/arch/mips64/mm/tlb-andes.c.orig Tue Feb 4 13:13:43 2003 +++ linux/arch/mips64/mm/tlb-andes.c Tue Feb 4 14:49:59 2003 @@ -53,18 +53,12 @@ void local_flush_tlb_mm(struct mm_struct *mm) { - if (cpu_context(smp_processor_id(), mm) != 0) { - unsigned long flags; - + int cpu = smp_processor_id(); + if (cpu_context(cpu, mm) != 0) { #ifdef DEBUG_TLB printk("[tlbmm<%d>]", mm->context); #endif - local_irq_save(flags); - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(smp_processor_id(), mm) - & ASID_MASK); - local_irq_restore(flags); + drop_mmu_context(mm,cpu); } } @@ -106,10 +100,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(smp_processor_id(), mm) - & ASID_MASK); + drop_mmu_context(mm, cpu); } local_irq_restore(flags); } diff -Nru linux/include/asm-mips/mmu_context.h.orig linux/include/asm-mips/mmu_context.h --- linux/include/asm-mips/mmu_context.h.orig Tue Feb 4 13:50:55 2003 +++ linux/include/asm-mips/mmu_context.h Tue Feb 4 13:51:03 2003 @@ -89,12 +89,25 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, struct task_struct *tsk, unsigned cpu) { + unsigned long flags; + + local_irq_save(flags); + /* Check if our ASID is of an older version and thus invalid */ if ((cpu_context(cpu, next) ^ asid_cache(cpu)) & ASID_VERSION_MASK) get_new_mmu_context(next, cpu); write_c0_entryhi(cpu_context(cpu, next)); TLBMISS_HANDLER_SETUP_PGD(next->pgd); + + /* + * Mark current->active_mm as not "active" anymore. + * We don't want to mislead possible IPI tlb flush routines. + */ + clear_bit(cpu, &prev->cpu_vm_mask); + set_bit(cpu, &next->cpu_vm_mask); + + local_irq_restore(flags); } /* @@ -112,11 +125,39 @@ static inline void activate_mm(struct mm_struct *prev, struct mm_struct *next) { + unsigned long flags; + + local_irq_save(flags); + /* Unconditionally get a new ASID. */ get_new_mmu_context(next, smp_processor_id()); write_c0_entryhi(cpu_context(smp_processor_id(), next)); TLBMISS_HANDLER_SETUP_PGD(next->pgd); + + local_irq_restore(flags); +} + +/* + * If mm is currently active_mm, we can't really drop it. Instead, + * we will get a new one for it. + */ +static inline void +drop_mmu_context(struct mm_struct *mm, unsigned cpu) +{ + unsigned long flags; + + local_irq_save(flags); + + if (test_bit(cpu, &mm->cpu_vm_mask)) { + get_new_mmu_context(mm, cpu); + set_entryhi(CPU_CONTEXT(cpu, mm) & 0xff); + } else { + /* will get a new context next time */ + CPU_CONTEXT(cpu, mm) = 0; + } + + local_irq_restore(flags); } #endif /* _ASM_MMU_CONTEXT_H */ diff -Nru linux/include/asm-mips64/mmu_context.h.orig linux/include/asm-mips64/mmu_context.h --- linux/include/asm-mips64/mmu_context.h.orig Tue Jan 21 13:55:43 2003 +++ linux/include/asm-mips64/mmu_context.h Tue Feb 4 14:46:00 2003 @@ -80,12 +80,25 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, struct task_struct *tsk, unsigned cpu) { + unsigned long flags; + + local_irq_save(flags); + /* Check if our ASID is of an older version and thus invalid */ if ((cpu_context(cpu, next) ^ asid_cache(cpu)) & ASID_VERSION_MASK) get_new_mmu_context(next, cpu); write_c0_entryhi(cpu_context(cpu, next)); TLBMISS_HANDLER_SETUP_PGD(next->pgd); + + /* + * Mark current->active_mm as not "active" anymore. + * We don't want to mislead possible IPI tlb flush routines. + */ + clear_bit(cpu, &prev->cpu_vm_mask); + set_bit(cpu, &next->cpu_vm_mask); + + local_irq_restore(flags); } /* @@ -103,11 +116,39 @@ static inline void activate_mm(struct mm_struct *prev, struct mm_struct *next) { + unsigned long flags; + + local_irq_save(flags); + /* Unconditionally get a new ASID. */ get_new_mmu_context(next, smp_processor_id()); write_c0_entryhi(cpu_context(smp_processor_id(), next)); TLBMISS_HANDLER_SETUP_PGD(next->pgd); + + local_irq_restore(flags); +} + +/* + * If mm is currently active_mm, we can't really drop it. Instead, + * we will get a new one for it. + */ +static inline void +drop_mmu_context(struct mm_struct *mm, unsigned cpu) +{ + unsigned long flags; + + local_irq_save(flags); + + if (test_bit(cpu, &mm->cpu_vm_mask)) { + get_new_mmu_context(mm, cpu); + set_entryhi(CPU_CONTEXT(cpu, mm) & 0xff); + } else { + /* will get a new context next time */ + CPU_CONTEXT(cpu, mm) = 0; + } + + local_irq_restore(flags); } #endif /* _ASM_MMU_CONTEXT_H */ --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="030204-2.5-smp-tlb-flush.patch" diff -Nru linux/arch/mips/mm/tlb-sb1.c.orig linux/arch/mips/mm/tlb-sb1.c --- linux/arch/mips/mm/tlb-sb1.c.orig Wed Dec 11 17:04:17 2002 +++ linux/arch/mips/mm/tlb-sb1.c Tue Feb 4 15:00:53 2003 @@ -172,15 +172,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) { - write_c0_entryhi(cpu_asid(cpu, mm)); - } else if (!(cpu_asid(cpu, mm)) && - cpu_context(cpu, current->active_mm)) { - /* Just wrapped ASIDs, bump the active one */ - get_new_mmu_context(current->active_mm, cpu); - write_c0_entryhi(cpu_context(cpu, current->active_mm)& 0xff); - } + drop_mmu_context(mm, cpu); } } local_irq_restore(flags); @@ -325,17 +317,10 @@ these entries, we just bump the asid. */ void local_flush_tlb_mm(struct mm_struct *mm) { - unsigned long flags; - int cpu; - local_irq_save(flags); - cpu = smp_processor_id(); + int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) { - write_c0_entryhi(cpu_context(cpu, mm) & 0xff); - } + drop_mmu_context(mm, cpu); } - local_irq_restore(flags); } /* Stolen from mips32 routines */ diff -Nru linux/arch/mips/mm/tlb-r4k.c.orig linux/arch/mips/mm/tlb-r4k.c --- linux/arch/mips/mm/tlb-r4k.c.orig Mon Jan 27 18:03:21 2003 +++ linux/arch/mips/mm/tlb-r4k.c Tue Feb 4 15:04:29 2003 @@ -76,16 +76,10 @@ int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - unsigned long flags; - #ifdef DEBUG_TLB printk("[tlbmm<%d>]", cpu_context(cpu, mm)); #endif - local_irq_save(flags); - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(cpu, mm) & ASID_MASK); - local_irq_restore(flags); + drop_mmu_context(mm,cpu); } } @@ -134,9 +128,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(cpu, mm) & ASID_MASK); + drop_mmu_context(mm, cpu); } local_irq_restore(flags); } diff -Nru linux/arch/mips/mm/tlb-r3k.c.orig linux/arch/mips/mm/tlb-r3k.c --- linux/arch/mips/mm/tlb-r3k.c.orig Mon Jan 27 18:03:21 2003 +++ linux/arch/mips/mm/tlb-r3k.c Tue Feb 4 15:05:22 2003 @@ -69,16 +69,10 @@ int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - unsigned long flags; - #ifdef DEBUG_TLB printk("[tlbmm<%lu>]", (unsigned long)cpu_context(cpu, mm)); #endif - local_irq_save(flags); - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(cpu, mm) & ASID_MASK); - local_irq_restore(flags); + drop_mmu_context(mm, cpu); } } @@ -120,9 +114,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(cpu, mm) & ASID_MASK); + drop_mmu_context(mm, cpu); } local_irq_restore(flags); } diff -Nru linux/arch/mips64/mm/tlb-sb1.c.orig linux/arch/mips64/mm/tlb-sb1.c --- linux/arch/mips64/mm/tlb-sb1.c.orig Wed Dec 11 17:04:19 2002 +++ linux/arch/mips64/mm/tlb-sb1.c Tue Feb 4 15:07:42 2003 @@ -180,9 +180,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(cpu, mm) & 0xff); + drop_mmu_context(mm, cpu); } } local_irq_restore(flags); @@ -268,17 +266,10 @@ these entries, we just bump the asid. */ void local_flush_tlb_mm(struct mm_struct *mm) { - unsigned long flags; - int cpu; - local_irq_save(flags); - cpu = smp_processor_id(); + int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) { - write_c0_entryhi(cpu_context(cpu, mm) & 0xff); - } + drop_mmu_context(mm, cpu); } - local_irq_restore(flags); } /* Stolen from mips32 routines */ diff -Nru linux/arch/mips64/mm/tlb-r4k.c.orig linux/arch/mips64/mm/tlb-r4k.c --- linux/arch/mips64/mm/tlb-r4k.c.orig Mon Jan 27 18:03:22 2003 +++ linux/arch/mips64/mm/tlb-r4k.c Tue Feb 4 15:08:21 2003 @@ -80,16 +80,10 @@ int cpu = smp_processor_id(); if (cpu_context(cpu, mm) != 0) { - unsigned long flags; - #ifdef DEBUG_TLB printk("[tlbmm<%d>]", cpu_context(cpu, mm)); #endif - local_irq_save(flags); - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); - local_irq_restore(flags); + drop_mmu_context(mm,cpu); } } @@ -138,9 +132,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, cpu); - if (mm == current->active_mm) - write_c0_entryhi(cpu_asid(cpu, mm)); + drop_mmu_context(mm, cpu); } local_irq_restore(flags); } diff -Nru linux/arch/mips64/mm/tlb-andes.c.orig linux/arch/mips64/mm/tlb-andes.c --- linux/arch/mips64/mm/tlb-andes.c.orig Tue Feb 4 13:14:43 2003 +++ linux/arch/mips64/mm/tlb-andes.c Tue Feb 4 14:53:28 2003 @@ -53,18 +53,12 @@ void local_flush_tlb_mm(struct mm_struct *mm) { - if (cpu_context(smp_processor_id(), mm) != 0) { - unsigned long flags; - + int cpu = smp_processor_id(); + if (cpu_context(cpu, mm) != 0) { #ifdef DEBUG_TLB printk("[tlbmm<%d>]", mm->context); #endif - local_irq_save(flags); - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(smp_processor_id(), mm) - & ASID_MASK); - local_irq_restore(flags); + drop_mmu_context(mm,cpu); } } @@ -108,10 +102,7 @@ } write_c0_entryhi(oldpid); } else { - get_new_mmu_context(mm, smp_processor_id()); - if (mm == current->active_mm) - write_c0_entryhi(cpu_context(smp_processor_id(), mm) - & ASID_MASK); + drop_mmu_context(mm, cpu); } local_irq_restore(flags); } diff -Nru linux/include/asm-mips/mmu_context.h.orig linux/include/asm-mips/mmu_context.h --- linux/include/asm-mips/mmu_context.h.orig Mon Jan 27 18:03:23 2003 +++ linux/include/asm-mips/mmu_context.h Tue Feb 4 14:53:28 2003 @@ -92,12 +92,25 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, struct task_struct *tsk, unsigned cpu) { + unsigned long flags; + + local_irq_save(flags); + /* Check if our ASID is of an older version and thus invalid */ if ((cpu_context(cpu, next) ^ asid_cache(cpu)) & ASID_VERSION_MASK) get_new_mmu_context(next, cpu); write_c0_entryhi(cpu_context(cpu, next)); TLBMISS_HANDLER_SETUP_PGD(next->pgd); + + /* + * Mark current->active_mm as not "active" anymore. + * We don't want to mislead possible IPI tlb flush routines. + */ + clear_bit(cpu, &prev->cpu_vm_mask); + set_bit(cpu, &next->cpu_vm_mask); + + local_irq_restore(flags); } /* @@ -115,11 +128,39 @@ static inline void activate_mm(struct mm_struct *prev, struct mm_struct *next) { + unsigned long flags; + + local_irq_save(flags); + /* Unconditionally get a new ASID. */ get_new_mmu_context(next, smp_processor_id()); write_c0_entryhi(cpu_context(smp_processor_id(), next)); TLBMISS_HANDLER_SETUP_PGD(next->pgd); + + local_irq_restore(flags); +} + +/* + * If mm is currently active_mm, we can't really drop it. Instead, + * we will get a new one for it. + */ +static inline void +drop_mmu_context(struct mm_struct *mm, unsigned cpu) +{ + unsigned long flags; + + local_irq_save(flags); + + if (test_bit(cpu, &mm->cpu_vm_mask)) { + get_new_mmu_context(mm, cpu); + set_entryhi(CPU_CONTEXT(cpu, mm) & 0xff); + } else { + /* will get a new context next time */ + CPU_CONTEXT(cpu, mm) = 0; + } + + local_irq_restore(flags); } #endif /* _ASM_MMU_CONTEXT_H */ diff -Nru linux/include/asm-mips64/mmu_context.h.orig linux/include/asm-mips64/mmu_context.h --- linux/include/asm-mips64/mmu_context.h.orig Mon Jan 27 18:03:23 2003 +++ linux/include/asm-mips64/mmu_context.h Tue Feb 4 14:53:28 2003 @@ -83,12 +83,25 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, struct task_struct *tsk, unsigned cpu) { + unsigned long flags; + + local_irq_save(flags); + /* Check if our ASID is of an older version and thus invalid */ if ((cpu_context(cpu, next) ^ asid_cache(cpu)) & ASID_VERSION_MASK) get_new_mmu_context(next, cpu); write_c0_entryhi(cpu_context(cpu, next)); TLBMISS_HANDLER_SETUP_PGD(next->pgd); + + /* + * Mark current->active_mm as not "active" anymore. + * We don't want to mislead possible IPI tlb flush routines. + */ + clear_bit(cpu, &prev->cpu_vm_mask); + set_bit(cpu, &next->cpu_vm_mask); + + local_irq_restore(flags); } /* @@ -106,11 +119,39 @@ static inline void activate_mm(struct mm_struct *prev, struct mm_struct *next) { + unsigned long flags; + + local_irq_save(flags); + /* Unconditionally get a new ASID. */ get_new_mmu_context(next, smp_processor_id()); write_c0_entryhi(cpu_context(smp_processor_id(), next)); TLBMISS_HANDLER_SETUP_PGD(next->pgd); + + local_irq_restore(flags); +} + +/* + * If mm is currently active_mm, we can't really drop it. Instead, + * we will get a new one for it. + */ +static inline void +drop_mmu_context(struct mm_struct *mm, unsigned cpu) +{ + unsigned long flags; + + local_irq_save(flags); + + if (test_bit(cpu, &mm->cpu_vm_mask)) { + get_new_mmu_context(mm, cpu); + set_entryhi(CPU_CONTEXT(cpu, mm) & 0xff); + } else { + /* will get a new context next time */ + CPU_CONTEXT(cpu, mm) = 0; + } + + local_irq_restore(flags); } #endif /* _ASM_MMU_CONTEXT_H */ --gBBFr7Ir9EOA20Yy-- From agx@sigxcpu.org Wed Feb 5 00:08:55 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 00:08:55 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:26072 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 00:08:55 +0000 Received: from bogon.sigxcpu.org (kons-d9bb55c6.pool.mediaWays.net [217.187.85.198]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id B3EC32BC2D for ; Wed, 5 Feb 2003 01:08:53 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 1F26C4AF4C; Wed, 5 Feb 2003 01:07:35 +0100 (CET) Date: Wed, 5 Feb 2003 01:07:35 +0100 From: Guido Guenther To: linux-mips@linux-mips.org Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030205000734.GA16674@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , linux-mips@linux-mips.org References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> <20030204223930.GD27302@pureza.melbourne.sgi.com> <20030204231203.GY16674@bogon.ms20.nix> <20030204231909.GE27302@pureza.melbourne.sgi.com> <20030204234529.GZ16674@bogon.ms20.nix> <20030204235543.GG27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030204235543.GG27302@pureza.melbourne.sgi.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips Content-Length: 822 Lines: 15 On Wed, Feb 05, 2003 at 10:55:43AM +1100, Andrew Clausen wrote: > No. I can't figure out why. In any case, the PROM uses OSLoadPartition > to find the kernel. On IP22 the PROM uses SystemPartition to find the kernel/bootloader. We set it to something like scsi(0)disk(1)rdisk(0)partition(8) to grab it from the vh. Is SystemPartition used differently on IP27? [..snip..] > So, we should obviously support OSLoadPartition=/dev/sda1 (=> root=/dev/sda1), > but it would also be nice to support OSLoadPartition=dksc(0,1,3). Well we could either check if OSLoadPartition matches the linux device naming scheme or the other way around and see if it looks like a valid device identifier used by the PROM (I'd prefer the later, though) - or simply make the OSLoadPartition <-> root= mapping '#ifdef CONFIG_SGI_IP22'. -- Guido From clausen@pureza.melbourne.sgi.com Wed Feb 5 00:19:44 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 00:19:45 +0000 (GMT) Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:61405 "EHLO rj.sgi.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 00:19:44 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h14MJoG8032344; Tue, 4 Feb 2003 14:19:51 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28512; Wed, 5 Feb 2003 11:19:38 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h150JCMd028980; Wed, 5 Feb 2003 11:19:12 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h150JBTN028978; Wed, 5 Feb 2003 11:19:11 +1100 Date: Wed, 5 Feb 2003 11:19:11 +1100 From: Andrew Clausen To: Guido Guenther , linux-mips@linux-mips.org Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030205001911.GH27302@pureza.melbourne.sgi.com> References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> <20030204223930.GD27302@pureza.melbourne.sgi.com> <20030204231203.GY16674@bogon.ms20.nix> <20030204231909.GE27302@pureza.melbourne.sgi.com> <20030204234529.GZ16674@bogon.ms20.nix> <20030204235543.GG27302@pureza.melbourne.sgi.com> <20030205000734.GA16674@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030205000734.GA16674@bogon.ms20.nix> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 1413 Lines: 31 On Wed, Feb 05, 2003 at 01:07:35AM +0100, Guido Guenther wrote: > On IP22 the PROM uses SystemPartition to find the kernel/bootloader. > We set it to something like scsi(0)disk(1)rdisk(0)partition(8) to grab > it from the vh. Is SystemPartition used differently on IP27? I think SystemPartition is ignored (haven't been able to see any evidence to the contrary... I should look in the source...) > [..snip..] > > So, we should obviously support OSLoadPartition=/dev/sda1 (=> root=/dev/sda1), > > but it would also be nice to support OSLoadPartition=dksc(0,1,3). > Well we could either check if OSLoadPartition matches the linux device > naming scheme or the other way around and see if it looks like a valid > device identifier used by the PROM (I'd prefer the later, though) - or > simply make the OSLoadPartition <-> root= mapping '#ifdef CONFIG_SGI_IP22'. I think the middle option (the one you prefer) of matching dksc(0,1,3) and converting it /dev/sda2 is best. Just, it has to happen after the hard disks are probed - /dev/sdXY are allocated dynamically (in a predictable-for-end-user way), so you need to find out what it was allocated to. Is this doable in a nice way? BTW, I think file system labels are a much better way of identifying FSs. Perhaps this discussion is irrelevant... people who are using OSLoadPartition to control their bootloader should just add a root= option. Cheers, Andrew From jormes@wideopenwest.com Wed Feb 5 00:36:27 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 00:36:28 +0000 (GMT) Received: from gtwy.nap.wideopenwest.com ([IPv6:::ffff:64.233.207.11]:7293 "EHLO pop-1.dnv.wideopenwest.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Wed, 5 Feb 2003 00:36:27 +0000 Received: from localhost.localdomain (s233-106-251.nap.wideopenwest.com [64.233.251.106]) by pop-1.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h150fUx19227 for ; Tue, 4 Feb 2003 18:41:30 -0600 Content-Type: text/plain; charset="us-ascii" From: Jason Ormes Reply-To: jormes@wideopenwest.com To: linux-mips@linux-mips.org Subject: kernel boot error. Date: Tue, 4 Feb 2003 18:41:10 -0600 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Message-Id: <200302041841.10507.jormes@wideopenwest.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jormes@wideopenwest.com Precedence: bulk X-list: linux-mips Content-Length: 2852 Lines: 60 hello, can someone help me with this error? Is this because the network failed? scsi0 : QLogic ISP1020 SCSI on PCI bus 00 device 00 irq 4 I/O base 0x8200000 scsi1 : QLogic ISP1020 SCSI on PCI bus 00 device 08 irq 5 I/O base 0x8400000 eth0: Auto-Negotiation unsuccessful, trying force link mode Slice A got dbe at 0xffffffff801882fc Hub information: ERR_INT_PEND = 0x200100 Hub has valid error information: Overrun is set. Error stack may contain additional information. Hub error address is 02400208 Incoming message command 0x9e Supplemental field of incoming message is 0x7f8 T5 Rn (for RRB only) is 0x0 Error type is Uncached Partial Read PRERR Cpu 0 $0 : 0000000000000000 0000000014001ce0 a8000000013b1040 a8000000013b1000 $4 : a8000000013b1080 0000000000000000 0000000000000040 ffffffff80284688 $8 : 0000000014001ce1 0000000000000000 a8000000012d3c70 0000000000000004 $12 : 0000000000000000 a8000000013b1080 a8000000012d3c80 ffffffff8026e468 $16 : a8000000013b1040 0000000000000002 a8000000013b0400 a8000000003840c0 $20 : a800000000384000 0000000000000040 0000000000000001 a8000000013a7e00 $24 : 0000000000000040 0000000000000020 $28 : a8000000012d0000 a8000000012d3af0 0000000000000000 ffffffff8010ecd8 Hi : 0000000000000000 Lo : 0000000000000040 epc : ffffffff801882fc Not tainted badvaddr: 0000000000000000 Status : 14001ce2 [ KX SX UX KERNEL EXL ] Cause : 0000901c Index: 0 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 1 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 2 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 3 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 4 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 5 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 6 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 7 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 8 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 9 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 10 pgmask=4kb va=c0000fff80000000 asid=00 [pa=00000000000 c=0 d=0 v=0 g=0] [pa=00000000000 c=0 d=0 v=0 g=0] Index: 11 pgmask=4kb va=c0000fff80000000 asid=00 Jason Ormes From clausen@pureza.melbourne.sgi.com Wed Feb 5 00:44:20 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 00:44:21 +0000 (GMT) Received: from zok.sgi.com ([IPv6:::ffff:204.94.215.101]:56198 "EHLO zok.sgi.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 00:44:20 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h14NpDKp010535; Tue, 4 Feb 2003 15:51:14 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28800; Wed, 5 Feb 2003 11:44:14 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h150hlMd029011; Wed, 5 Feb 2003 11:43:48 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h150hjcU029009; Wed, 5 Feb 2003 11:43:45 +1100 Date: Wed, 5 Feb 2003 11:43:45 +1100 From: Andrew Clausen To: Jason Ormes Cc: linux-mips@linux-mips.org Subject: Re: kernel boot error. Message-ID: <20030205004345.GI27302@pureza.melbourne.sgi.com> References: <200302041841.10507.jormes@wideopenwest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302041841.10507.jormes@wideopenwest.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 430 Lines: 14 On Tue, Feb 04, 2003 at 06:41:10PM -0600, Jason Ormes wrote: > hello, > > can someone help me with this error? Is this because the network failed? I'm getting exactly the same problem. What machine are you using? I'm using an ip27 (origin 200), and an acenic network card. It seems that there all kinds of PCI hacks in the ip27 support, and I'm currently trying to figure out how to get this card working... Cheers, Andrew From jormes@wideopenwest.com Wed Feb 5 01:07:39 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 01:07:40 +0000 (GMT) Received: from gtwy.nap.wideopenwest.com ([IPv6:::ffff:64.233.207.11]:19849 "EHLO pop-2.dnv.wideopenwest.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Wed, 5 Feb 2003 01:07:39 +0000 Received: from localhost.localdomain (s233-106-251.nap.wideopenwest.com [64.233.251.106]) by pop-2.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h151Dq325828; Tue, 4 Feb 2003 19:13:52 -0600 Content-Type: text/plain; charset="iso-8859-1" From: Jason Ormes Reply-To: jormes@wideopenwest.com To: Andrew Clausen Subject: Re: kernel boot error. Date: Tue, 4 Feb 2003 19:12:28 -0600 User-Agent: KMail/1.4.3 Cc: linux-mips@linux-mips.org References: <200302041841.10507.jormes@wideopenwest.com> <20030205004345.GI27302@pureza.melbourne.sgi.com> In-Reply-To: <20030205004345.GI27302@pureza.melbourne.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Message-Id: <200302041912.28491.jormes@wideopenwest.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jormes@wideopenwest.com Precedence: bulk X-list: linux-mips Content-Length: 1165 Lines: 34 Its an ip27 origin 200 with what hinv -v reports as a adapter IOC3 Rev 1, (pci id 2) controller multi function SuperIO controller Ethernet Rev 1 I did a little searching online anhttp://www.scd.ucar.edu/nets/docs/procs/SGI-100mbps/SGI-auto.htmld found a lot of references to origins having problems with the autonegotiation timing out to fast, but the only fix that I've found has to do with editing part of the kernel. here's a link to one that I found. http://www.scd.ucar.edu/nets/docs/procs/SGI-100mbps/SGI-auto.html could this be part of the problem? Thanks for the quick response, atleast I know I'm not alone. Jason On Tuesday 04 February 2003 06:43 pm, Andrew Clausen wrote: > On Tue, Feb 04, 2003 at 06:41:10PM -0600, Jason Ormes wrote: > > hello, > > > > can someone help me with this error? Is this because the network failed? > > I'm getting exactly the same problem. What machine are you using? > I'm using an ip27 (origin 200), and an acenic network card. > > It seems that there all kinds of PCI hacks in the ip27 support, > and I'm currently trying to figure out how to get this card working... > > Cheers, > Andrew From clausen@pureza.melbourne.sgi.com Wed Feb 5 01:15:16 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 01:15:17 +0000 (GMT) Received: from zok.sgi.com ([IPv6:::ffff:204.94.215.101]:51594 "EHLO zok.sgi.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 01:15:16 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h150MBKp012345; Tue, 4 Feb 2003 16:22:11 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA29131; Wed, 5 Feb 2003 12:15:12 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h151EjMd029087; Wed, 5 Feb 2003 12:14:46 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h151EiJG029085; Wed, 5 Feb 2003 12:14:44 +1100 Date: Wed, 5 Feb 2003 12:14:44 +1100 From: Andrew Clausen To: Jason Ormes Cc: linux-mips@linux-mips.org Subject: Re: kernel boot error. Message-ID: <20030205011444.GL27302@pureza.melbourne.sgi.com> References: <200302041841.10507.jormes@wideopenwest.com> <20030205004345.GI27302@pureza.melbourne.sgi.com> <200302041912.28491.jormes@wideopenwest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302041912.28491.jormes@wideopenwest.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 1007 Lines: 26 On Tue, Feb 04, 2003 at 07:12:28PM -0600, Jason Ormes wrote: > Its an ip27 origin 200 with what hinv -v reports as a > > adapter IOC3 Rev 1, (pci id 2) > controller multi function SuperIO > controller Ethernet Rev 1 > > I did a little searching online > anhttp://www.scd.ucar.edu/nets/docs/procs/SGI-100mbps/SGI-auto.htmld found a > lot of references to origins having problems with the autonegotiation timing > out to fast, but the only fix that I've found has to do with editing part of > the kernel. here's a link to one that I found. > http://www.scd.ucar.edu/nets/docs/procs/SGI-100mbps/SGI-auto.html > > could this be part of the problem? I doubt it. This problem is a PCI bus issue. I'm still investigating... but it could be a multitude of things. Have a look in mips/sgi-ip27/ip27-pci.c at all the functions with "fixup" in their name. Things like byte-swapping, configuring IO addresses, etc. I suspect we need something like this for other cards. Cheers, Andrew From tpolgar@freehandsystems.com Wed Feb 5 01:36:59 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 01:37:00 +0000 (GMT) Received: from bisque.propagation.net ([IPv6:::ffff:66.221.142.1]:38099 "EHLO bisque.propagation.net") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 01:36:59 +0000 Received: from freehandsystems.com (adsl-64-170-127-190.dsl.snfc21.pacbell.net [64.170.127.190]) by bisque.propagation.net (8.11.6/8.8.5) with ESMTP id h151aoA10408; Tue, 4 Feb 2003 19:36:50 -0600 Message-ID: <3E406ABC.A9D0D6F@freehandsystems.com> Date: Tue, 04 Feb 2003 17:37:00 -0800 From: Tibor Polgar X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Clausen CC: Jason Ormes , linux-mips@linux-mips.org Subject: Re: kernel boot error. References: <200302041841.10507.jormes@wideopenwest.com> <20030205004345.GI27302@pureza.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tpolgar@freehandsystems.com Precedence: bulk X-list: linux-mips Content-Length: 691 Lines: 14 > I'm getting exactly the same problem. What machine are you using? > I'm using an ip27 (origin 200), and an acenic network card. > > It seems that there all kinds of PCI hacks in the ip27 support, > and I'm currently trying to figure out how to get this card working... My buddy and I used to work at Alteon with my buddy doing most of the original NIC firmware coding. I don't remember who did the SGI driver side coding. The linux driver was done by Jes Sorensen using our OpenDriver kit. Let me know if we can help in any way. Is the Origin an SGI machine? If so, i do recall we had to do some special casing to get the card to work correctly. This was 4 years ago .... Tibor From long21st@yahoo.com Wed Feb 5 02:42:02 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 02:42:03 +0000 (GMT) Received: from web40401.mail.yahoo.com ([IPv6:::ffff:66.218.78.98]:6742 "HELO web40401.mail.yahoo.com") by linux-mips.org with SMTP id ; Wed, 5 Feb 2003 02:42:02 +0000 Message-ID: <20030205024153.67587.qmail@web40401.mail.yahoo.com> Received: from [157.165.41.125] by web40401.mail.yahoo.com via HTTP; Tue, 04 Feb 2003 18:41:53 PST Date: Tue, 4 Feb 2003 18:41:53 -0800 (PST) From: Long Li Subject: Specify the as path when gcc runs To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: long21st@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 628 Lines: 22 Hi, Is there a way that I can specify the path for 'as' on the fly when I use gcc? I have a MIPS cross compiler xgcc on Redhat 7.1. However, in the Makefile, I use both the native compiler as well as the crosscompiler. They both search the path to find the as to use, which is incorrect. I don't want to rebuild the crosscompiler to specify the path for as using --with-as=pathname, and wonder if I can specify the as path for the crosscompiler on the fly? Thanks a lot! Long __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From yoichi_yuasa@montavista.co.jp Wed Feb 5 02:46:14 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 02:46:15 +0000 (GMT) Received: from r-bu.iij4u.or.jp ([IPv6:::ffff:210.130.0.89]:17125 "EHLO r-bu.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 02:46:14 +0000 Received: from pudding.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id h152k7N23885; Wed, 5 Feb 2003 11:46:07 +0900 (JST) Date: Wed, 5 Feb 2003 11:40:45 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@montavista.co.jp, linux-mips@linux-mips.org Subject: Re: [patch] TANBAC TB0226(NEC VR4131) Message-Id: <20030205114045.281335ca.yoichi_yuasa@montavista.co.jp> In-Reply-To: <20030204134406.A29585@linux-mips.org> References: <20030204154025.340fdf40.yoichi_yuasa@montavista.co.jp> <20030204134406.A29585@linux-mips.org> Organization: MontaVista Software Japan, Inc. X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@montavista.co.jp Precedence: bulk X-list: linux-mips Content-Length: 513 Lines: 18 On Tue, 4 Feb 2003 13:44:06 +0100 Ralf Baechle wrote: > On Tue, Feb 04, 2003 at 03:40:25PM +0900, Yoichi Yuasa wrote: > > > This patch is based on linux_2_4 tag cvs tree on ftp.linux-mips.org > > Would you apply this patch to CVS on ftp.linux-mips.org? > > Could you also make a patch against 2.5? It's a huge PITA when 2.4 and > 2.5 trees are diverging so I'd really like to have a patch for 2.5 also. OK, please wait for a moment. > Patch applied, Thanks you for your help. Yoichi From clausen@pureza.melbourne.sgi.com Wed Feb 5 03:07:01 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 03:07:02 +0000 (GMT) Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:31364 "EHLO rj.sgi.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 03:07:01 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h15175G8011675; Tue, 4 Feb 2003 17:07:05 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA29989; Wed, 5 Feb 2003 14:06:53 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h1536QMd029181; Wed, 5 Feb 2003 14:06:27 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h1536PAh029179; Wed, 5 Feb 2003 14:06:25 +1100 Date: Wed, 5 Feb 2003 14:06:25 +1100 From: Andrew Clausen To: Tibor Polgar Cc: Jason Ormes , linux-mips@linux-mips.org Subject: Re: kernel boot error. Message-ID: <20030205030625.GM27302@pureza.melbourne.sgi.com> References: <200302041841.10507.jormes@wideopenwest.com> <20030205004345.GI27302@pureza.melbourne.sgi.com> <3E406ABC.A9D0D6F@freehandsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E406ABC.A9D0D6F@freehandsystems.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 1430 Lines: 40 On Tue, Feb 04, 2003 at 05:37:00PM -0800, Tibor Polgar wrote: > > I'm getting exactly the same problem. What machine are you using? > > I'm using an ip27 (origin 200), and an acenic network card. > > > > It seems that there all kinds of PCI hacks in the ip27 support, > > and I'm currently trying to figure out how to get this card working... > > My buddy and I used to work at Alteon with my buddy doing most of the original > NIC firmware coding. I don't remember who did the SGI driver side coding. > The linux driver was done by Jes Sorensen using our OpenDriver kit. Let me > know if we can help in any way. Is the Origin an SGI machine? Yep. It's sitting in an SGI machine room. > If so, i do > recall we had to do some special casing to get the card to work correctly. Yeah, that would be right. Have you had a look at pci_fixup_ioc3()? (That's the network card that seems to come with the Origin 200). I bet it's something similar. Just, the base address the card (PCI bus?) is spitting out is very odd: eth0: SGI AceNIC Gigabit Ethernet at 0xfe7fc000, irq 8 The card is in slot 6, so I'd expect the base address to be 0x8900000. Anyway, it dies on this: writel(HW_RESET | (HW_RESET << 24), ®s->HostCtrl); with: ®s->HostCtrl=9200000008900040 or ®s->HostCtrl=92000000fe7fc040 (depending on the base address... I hard coded in a more sane one, but it still crashes) Cheers, Andrew From lindahl@keyresearch.com Wed Feb 5 03:28:51 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 03:28:52 +0000 (GMT) Received: from 12-234-29-241.client.attbi.com ([IPv6:::ffff:12.234.29.241]:8832 "EHLO localhost.localdomain") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 03:28:51 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h153SgW2001260 for ; Tue, 4 Feb 2003 19:28:42 -0800 Received: (from lindahl@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id h153SZNv001258 for linux-mips@linux-mips.org; Tue, 4 Feb 2003 19:28:35 -0800 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Tue, 4 Feb 2003 19:28:35 -0800 From: Greg Lindahl To: linux-mips@linux-mips.org Subject: Re: Specify the as path when gcc runs Message-ID: <20030205032835.GA1171@greglaptop.attbi.com> Mail-Followup-To: linux-mips@linux-mips.org References: <20030205024153.67587.qmail@web40401.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030205024153.67587.qmail@web40401.mail.yahoo.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lindahl@keyresearch.com Precedence: bulk X-list: linux-mips Content-Length: 165 Lines: 8 On Tue, Feb 04, 2003 at 06:41:53PM -0800, Long Li wrote: > Is there a way that I can specify the path for 'as' on > the fly when I use gcc? -Ya,directory -- greg From hopper@pcsmail.amd.com Wed Feb 5 04:20:10 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 04:20:11 +0000 (GMT) Received: from amdext2.amd.com ([IPv6:::ffff:163.181.251.1]:46749 "EHLO amdext2.amd.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 04:20:10 +0000 Received: from SAUSGW01.amd.com (sausgw01.amd.com [163.181.250.21]) by amdext2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id WAA03923 for ; Tue, 4 Feb 2003 22:20:02 -0600 (CST) Received: from 163.181.250.1SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (MMS v5.0)); Tue, 04 Feb 2003 22:19:53 -0600 X-Server-Uuid: 262C4BA7-64EE-471D-8B02-117625D613AB Received: from pcsmail.amd.com (pcsmail.amd.com [163.181.41.222]) by amdint2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id WAA14336 for ; Tue, 4 Feb 2003 22:19:52 -0600 (CST) Received: from yeager.amd.com (yeager.amd.com [163.181.32.130]) by pcsmail.amd.com (8.11.6/8.11.6) with ESMTP id h154Jpa19408 for ; Tue, 4 Feb 2003 22:19:51 -0600 Received: from yeager.amd.com (localhost [127.0.0.1]) by yeager.amd.com (8.12.3/8.12.3/Debian -4) with ESMTP id h154JpRN014519 for ; Tue, 4 Feb 2003 22:19:51 -0600 Received: (from hopper@localhost) by yeager.amd.com ( 8.12.3/8.12.3/Debian -4) id h154JpJo014517 for linux-mips@linux-mips.org; Tue, 4 Feb 2003 22:19:51 -0600 Date: Tue, 4 Feb 2003 22:19:50 -0600 From: "Dan Hopper" To: linux-mips@linux-mips.org Subject: [patch 2.4] au1x00 prom.c hw addr case insensitivity fix Message-ID: <20030205041950.GA14502@yeager.amd.com> Mail-Followup-To: Dan Hopper , linux-mips@linux-mips.org MIME-Version: 1.0 User-Agent: Mutt/1.3.28i X-WSS-ID: 125E4F63948807-01-01 Content-Type: multipart/mixed; boundary=wRRV7LY7NUeQGEoC Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hopper@pcsmail.amd.com Precedence: bulk X-list: linux-mips Content-Length: 1203 Lines: 48 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi folks, Attached please find a short fix to str2hexnum() in arch/mips/au1000/common/prom.c of the 2.4 branch. With this fix, the contents of the "ethaddr" entry in the environment table passed by the bootloader to the kernel can have upper case hexadecimal digits. Without the patch, an address such as ethaddr = "00:50:C2:0C:20:4f" is silently converted to "00:50:02:00:20:4f", making for some serious head scratching if you're trying to bootp the kernel. Dan --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=prom.c.uppercase_macaddr.patch Content-Transfer-Encoding: 7bit --- arch/mips/au1000/common/prom.c.orig Tue Feb 4 20:38:28 2003 +++ arch/mips/au1000/common/prom.c Tue Feb 4 22:09:17 2003 @@ -105,9 +105,11 @@ inline unsigned char str2hexnum(unsigned char c) { if(c >= '0' && c <= '9') - return c - '0'; + return c - '0'; if(c >= 'a' && c <= 'f') - return c - 'a' + 10; + return c - 'a' + 10; + if(c >= 'A' && c <= 'F') + return c - 'A' + 10; return 0; /* foo */ } --wRRV7LY7NUeQGEoC-- From yaelgilad@myrealbox.com Wed Feb 5 07:07:04 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 07:07:04 +0000 (GMT) Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:60799 "EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Wed, 5 Feb 2003 07:07:04 +0000 Received: from yaelgilad [212.179.194.253] by myrealbox.com with NetMail ModWeb Module; Wed, 05 Feb 2003 07:07:05 +0000 Subject: Porting an application to mips-linux From: "Gilad Benjamini" To: linux-mips@linux-mips.org Date: Wed, 05 Feb 2003 07:07:05 +0000 X-Mailer: NetMail ModWeb Module X-Sender: yaelgilad MIME-Version: 1.0 Message-ID: <1044428825.ae2319a0yaelgilad@myrealbox.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yaelgilad@myrealbox.com Precedence: bulk X-list: linux-mips Content-Length: 243 Lines: 10 Hi, I have a source level application, ~10 c files, standard stuff, mostly sockets. I'd like it to run on my mips-linux platform. I guess my changes should mostly be in the Makefile. What should they be ? Any simple example I can use ? TIA From agx@sigxcpu.org Wed Feb 5 09:29:41 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 09:29:42 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:45272 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 09:29:41 +0000 Received: from bogon.sigxcpu.org (unknown [134.34.147.122]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 4BC712BC2D for ; Wed, 5 Feb 2003 10:29:39 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id B38234AF4C; Wed, 5 Feb 2003 10:28:00 +0100 (CET) Date: Wed, 5 Feb 2003 10:28:00 +0100 From: Guido Guenther To: Linux/MIPS Development Subject: Re: debian installer on mips64 (origin 200) Message-ID: <20030205092800.GD16674@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , Linux/MIPS Development References: <20030203041432.GF967@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030203041432.GF967@pureza.melbourne.sgi.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips Content-Length: 1053 Lines: 20 On Mon, Feb 03, 2003 at 03:14:32PM +1100, Andrew Clausen wrote: > Anyway, in principle, I should be able write a shell script to > create the above image, and add an isofs partition containing the debian > mips install cd. Just, I bet it can't deal with sash / the prom > properly - it's probably dependent on arcboot. Also, it would need > different kernel packages. It only makes sense to build 'native' kernel packages if we have the corresponding toolchain packaged. Nobody ever packaged the mips64 binutils/egcs from oss for debian. [..snip..] > Perhaps a better approach is to get the kernel to prompt users to > change disks, and stick in the vanilla debian CD? i.e. have a > "mips64-bootstrap.img" CD image, which prompts for install-1 afterwards. Why not use the CONFIG_EMBEDDED_RAMDISK option to append the installer image as initrd to the kernel and dump this into the vh? To build the vh on the CD you can probably use the same script Flo made for IP22: http://www.silicon-verl.de/home/flo/software/genisovh-0.1.tgz Regards, -- Guido From br1@4g-systems.de Wed Feb 5 11:35:09 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 11:35:10 +0000 (GMT) Received: from grey.subnet.at ([IPv6:::ffff:193.170.141.20]:12048 "EHLO grey.subnet.at") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 11:35:09 +0000 Received: from localhost ([193.170.141.10]) by grey.subnet.at ; Wed, 05 Feb 2003 12:35:00 +0100 From: Bruno Randolf To: linux-mips@linux-mips.org Subject: which kernel tree for Au1500? Date: Wed, 5 Feb 2003 12:34:01 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302051234.01252.br1@4g-systems.de> X-Rcpt-To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: br1@4g-systems.de Precedence: bulk X-list: linux-mips Content-Length: 703 Lines: 17 hello, we are developing a board based on the Au1500 SOC and we need to adapt the linux kernel for it. since we need something working soon, we will concentrate on the 2.4 version. so i wanted to ask which kernel tree is recommended for the Au1x00 chipset. i've found the tree on http://linux-mips.sourceforge.net/ and the 2_4 branch of linux-mips.org look most promising, but they have various differences, most obvious the hyd1100/ directory on sf and the db1x00/ directory on linux-mips. another significant difference is that the sf version has power management support and that linux-mips supports one more PHY in au1000_eth.c. how is kernel work for mips organized? many thanks, bruno From ralf@linux-mips.org Wed Feb 5 14:03:55 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 14:03:55 +0000 (GMT) Received: from p508B6FDE.dip.t-dialin.net ([IPv6:::ffff:80.139.111.222]:48851 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 14:03:55 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h15E3eR13181; Wed, 5 Feb 2003 15:03:40 +0100 Date: Wed, 5 Feb 2003 15:03:40 +0100 From: Ralf Baechle To: Andrew Clausen Cc: Tibor Polgar , Jason Ormes , linux-mips@linux-mips.org Subject: Re: kernel boot error. Message-ID: <20030205150339.A13033@linux-mips.org> References: <200302041841.10507.jormes@wideopenwest.com> <20030205004345.GI27302@pureza.melbourne.sgi.com> <3E406ABC.A9D0D6F@freehandsystems.com> <20030205030625.GM27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030205030625.GM27302@pureza.melbourne.sgi.com>; from clausen@melbourne.sgi.com on Wed, Feb 05, 2003 at 02:06:25PM +1100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1127 Lines: 27 On Wed, Feb 05, 2003 at 02:06:25PM +1100, Andrew Clausen wrote: > > If so, i do > > recall we had to do some special casing to get the card to work correctly. > > Yeah, that would be right. Have you had a look at pci_fixup_ioc3()? > (That's the network card that seems to come with the Origin 200). I > bet it's something similar. Pci_fixup_ioc3() is only necessary for the IOC3 nic. It's a PCI board that's about as broken are it only can be. The board runs on in PCI busses clocked at 33MHz. It only partially decodes the PCI config address space. Attempted access to one of the nimplemented registers of the IOC3 will result in access to another register. That's too buggy for any OS to cope with without that special kludge pci_fixup_ioc3. > Just, the base address the card (PCI bus?) is spitting out is very odd: > > eth0: SGI AceNIC Gigabit Ethernet at 0xfe7fc000, irq 8 > > The card is in slot 6, so I'd expect the base address to be 0x8900000. > Anyway, it dies on this: Query the address using the usual Linux PCI bus stuff from . Anything else is doomed, especially guessing ... Ralf From macro@ds2.pg.gda.pl Wed Feb 5 14:39:41 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 14:39:41 +0000 (GMT) Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:39049 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 14:39:41 +0000 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA09363; Wed, 5 Feb 2003 15:39:51 +0100 (MET) Date: Wed, 5 Feb 2003 15:39:51 +0100 (MET) From: "Maciej W. Rozycki" To: Long Li cc: linux-mips@linux-mips.org Subject: Re: Specify the as path when gcc runs In-Reply-To: <20030205024153.67587.qmail@web40401.mail.yahoo.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Content-Length: 457 Lines: 13 On Tue, 4 Feb 2003, Long Li wrote: > Is there a way that I can specify the path for 'as' on > the fly when I use gcc? I have a MIPS cross compiler Use "-B". You may use "-print-prog-name=as" to get feedback to be sure the right binary is picked. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From atulsrivastava9@rediffmail.com Wed Feb 5 15:27:43 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 15:27:44 +0000 (GMT) Received: from webmail29.rediffmail.com ([IPv6:::ffff:203.199.83.39]:34470 "HELO rediffmail.com") by linux-mips.org with SMTP id ; Wed, 5 Feb 2003 15:27:43 +0000 Received: (qmail 1898 invoked by uid 510); 5 Feb 2003 15:33:41 -0000 Date: 5 Feb 2003 15:33:41 -0000 Message-ID: <20030205153341.1897.qmail@webmail29.rediffmail.com> Received: from unknown (202.88.159.85) by rediffmail.com via HTTP; 05 feb 2003 15:33:41 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: uart 16550 undefined state... Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips Content-Length: 843 Lines: 32 Hello, A small generic question .. Have any body experienced undefined state of ns16550A Uart chip , especially during REinitialisation.. I get it when i my bootloader uses uart0 and later after loding kernel through serial link and using in my kernel command line console=ttyS0 then in init/main.c , console_init() or open("/dev/console",....) the serial port is again setup via serial_console_setup() or rs_open() like interfaces. even afer taking care of same baudspeed it just send junk characters. though initialising a uart is extremly simple.only difference betwen bootloader and kernel initialization i can see regarding polling/interrupt mode. if i mask those code in serial.c ..i don't have any problem.. but why it happens, what special sequence of initialisation can avoid this problem.. Best Regards, Atul From ralf@linux-mips.org Wed Feb 5 16:48:12 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 16:48:12 +0000 (GMT) Received: from p508B6FDE.dip.t-dialin.net ([IPv6:::ffff:80.139.111.222]:28885 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 16:48:12 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h15Gm7q16132; Wed, 5 Feb 2003 17:48:07 +0100 Date: Wed, 5 Feb 2003 17:48:07 +0100 From: Ralf Baechle To: Andrew Clausen Cc: Jason Ormes , linux-mips@linux-mips.org Subject: Re: kernel boot error. Message-ID: <20030205174807.B13033@linux-mips.org> References: <200302041841.10507.jormes@wideopenwest.com> <20030205004345.GI27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030205004345.GI27302@pureza.melbourne.sgi.com>; from clausen@melbourne.sgi.com on Wed, Feb 05, 2003 at 11:43:45AM +1100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 798 Lines: 19 On Wed, Feb 05, 2003 at 11:43:45AM +1100, Andrew Clausen wrote: > On Tue, Feb 04, 2003 at 06:41:10PM -0600, Jason Ormes wrote: > > hello, > > > > can someone help me with this error? Is this because the network failed? > > I'm getting exactly the same problem. What machine are you using? > I'm using an ip27 (origin 200), and an acenic network card. > > It seems that there all kinds of PCI hacks in the ip27 support, > and I'm currently trying to figure out how to get this card working... His particular machine is a uniprocessor machine, a very rare configuration. In all the years I'm working with Origins this is just the second I encounter. Note that disabling one of the processor doesn't suffice; this problem really only seems to hit machines with one physical processor. Ralf From ralf@linux-mips.org Wed Feb 5 16:51:16 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 16:51:17 +0000 (GMT) Received: from p508B6FDE.dip.t-dialin.net ([IPv6:::ffff:80.139.111.222]:31701 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 16:51:16 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h15GpCf16192; Wed, 5 Feb 2003 17:51:12 +0100 Date: Wed, 5 Feb 2003 17:51:12 +0100 From: Ralf Baechle To: Gilad Benjamini Cc: linux-mips@linux-mips.org Subject: Re: Porting an application to mips-linux Message-ID: <20030205175112.A14089@linux-mips.org> References: <1044428825.ae2319a0yaelgilad@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1044428825.ae2319a0yaelgilad@myrealbox.com>; from yaelgilad@myrealbox.com on Wed, Feb 05, 2003 at 07:07:05AM +0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 622 Lines: 15 On Wed, Feb 05, 2003 at 07:07:05AM +0000, Gilad Benjamini wrote: > I have a source level application, ~10 c files, standard stuff, mostly sockets. > I'd like it to run on my mips-linux platform. > I guess my changes should mostly be in the Makefile. > What should they be ? > Any simple example I can use ? A normal application simply needs to be recompiled; if you're crosscompiling the application you just have to set the CC,LD etc. variables to the crosscompiler tools instead of the native tools. If you're doing native builds no changes at all should be necessary. At least that's the general procedure. Ralf From ppopov@mvista.com Wed Feb 5 16:58:37 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 16:58:38 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:65273 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 16:58:37 +0000 Received: from [10.2.2.20] (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id IAA06766; Wed, 5 Feb 2003 08:57:52 -0800 Subject: Re: which kernel tree for Au1500? From: Pete Popov To: Bruno Randolf Cc: linux-mips In-Reply-To: <200302051234.01252.br1@4g-systems.de> References: <200302051234.01252.br1@4g-systems.de> Content-Type: text/plain Organization: MontaVista Software Message-Id: <1044464033.9562.22.camel@adsl.pacbell.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 08:53:53 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 981 Lines: 21 On Wed, 2003-02-05 at 03:34, Bruno Randolf wrote: > hello, > > we are developing a board based on the Au1500 SOC and we need to adapt the > linux kernel for it. since we need something working soon, we will > concentrate on the 2.4 version. > > so i wanted to ask which kernel tree is recommended for the Au1x00 chipset. > i've found the tree on http://linux-mips.sourceforge.net/ and the 2_4 branch > of linux-mips.org look most promising, but they have various differences, > most obvious the hyd1100/ directory on sf and the db1x00/ directory on > linux-mips. another significant difference is that the sf version has power > management support and that linux-mips supports one more PHY in au1000_eth.c. linux-mips.org is more up to date now and I don't plan on updating the sourceforge tree anymore. You don't need the hyd1100 board since it's an internal board only. The PM support ... I haven't tested it in linux-mips.org but it need a little work anyway. Pete From tor@spacetec.no Wed Feb 5 17:07:52 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 17:07:53 +0000 (GMT) Received: from firewall.spacetec.no ([IPv6:::ffff:192.51.5.5]:29161 "EHLO pallas.spacetec.no") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 17:07:52 +0000 Received: (from tor@localhost) by pallas.spacetec.no (8.12.3/8.12.6) id h15H7ocM000681 for linux-mips@linux-mips.org; Wed, 5 Feb 2003 18:07:51 +0100 Message-Id: <200302051707.h15H7ocM000681@pallas.spacetec.no> From: tor@spacetec.no (Tor Arntsen) Date: Wed, 5 Feb 2003 18:07:49 +0100 In-Reply-To: Ralf Baechle "Re: kernel boot error." (Feb 5, 17:49) X-Mailer: Mail User's Shell (7.2.6 beta(4) 03/19/98) To: linux-mips@linux-mips.org Subject: Re: kernel boot error. Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tor@spacetec.no Precedence: bulk X-list: linux-mips Content-Length: 709 Lines: 16 On Feb 5, 17:49, Ralf Baechle wrote: >> On Tue, Feb 04, 2003 at 06:41:10PM -0600, Jason Ormes wrote: >> I'm using an ip27 (origin 200), and an acenic network card. [...] >His particular machine is a uniprocessor machine, a very rare configuration. >In all the years I'm working with Origins this is just the second I >encounter. Note that disabling one of the processor doesn't suffice; >this problem really only seems to hit machines with one physical processor. 1-CPU Origin-200's are not that uncommon.. I have one right here. Although we mostly used to buy 2-CPU Origins we also bought 1-CPU Origins now and then, depending on what we planned to use them for. It's all about price in the end. -Tor From tpolgar@freehandsystems.com Wed Feb 5 17:52:06 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 17:52:06 +0000 (GMT) Received: from bisque.propagation.net ([IPv6:::ffff:66.221.142.1]:65491 "EHLO bisque.propagation.net") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 17:52:06 +0000 Received: from freehandsystems.com (adsl-64-170-127-190.dsl.snfc21.pacbell.net [64.170.127.190]) by bisque.propagation.net (8.11.6/8.8.5) with ESMTP id h15Hq1K22727; Wed, 5 Feb 2003 11:52:01 -0600 Message-ID: <3E414F48.8A6D5E74@freehandsystems.com> Date: Wed, 05 Feb 2003 09:52:08 -0800 From: Tibor Polgar X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruno Randolf CC: linux-mips@linux-mips.org Subject: Re: which kernel tree for Au1500? References: <200302051234.01252.br1@4g-systems.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tpolgar@freehandsystems.com Precedence: bulk X-list: linux-mips Content-Length: 1490 Lines: 32 > we are developing a board based on the Au1500 SOC and we need to adapt the > linux kernel for it. since we need something working soon, we will > concentrate on the 2.4 version. We are just finishing up an Au1500 project right now. FCS was yesterday!!! What we did was: 1) get from AMD the PB1500 development CD. It has an "old" 2.4.17 kernel along with MontaVista's HardHat Linux toolkit that's cross compiled to work on x86 platforms. If you have the $$$, MontaVista offers great support for the Au1500 based stuff. Their toolkit is top notch. 2) If you didn't already get from AMD a PB1500, do it. The development platform is a very nice start and will save you may weeks of code testing headaches (and cause a few special ones). At least for us here in USA, AMD "loaned" a board at no charge, i.e. a purchase order is signed but they never bill you. We're projected to buy some 25,000 Au1500s per year from them so that probably helped. 3) From there, look at the 2.4 latest CVS tree on linux-mips and Pete's own 36-bit mods in ftp://ftp.linux-mips.org/pub/linux/mips/people/ppopov/. AMD/MontaVista also released a 2.4.18 "like" linux but its a bit rough. 4) there are lots of other resources and headaches if you plan to cross compile X, gtk, etc. 5) we are flash based and used the special mods Pete put in to the 2.4.17 kernel to support zImage flash booting. We're using YAMON as our monitor and with a few changes have a pretty nice setup - boot wise. Tibor From ppopov@mvista.com Wed Feb 5 19:37:41 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 19:37:42 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:3060 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 19:37:41 +0000 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA13592; Wed, 5 Feb 2003 11:37:00 -0800 Subject: Re: which kernel tree for Au1500? From: Pete Popov To: Tibor Polgar Cc: Bruno Randolf , linux-mips@linux-mips.org In-Reply-To: <3E414F48.8A6D5E74@freehandsystems.com> References: <200302051234.01252.br1@4g-systems.de> <3E414F48.8A6D5E74@freehandsystems.com> Content-Type: text/plain Organization: MontaVista Software Message-Id: <1044473868.12615.48.camel@zeus.mvista.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 11:37:48 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 2013 Lines: 43 On Wed, 2003-02-05 at 09:52, Tibor Polgar wrote: > > we are developing a board based on the Au1500 SOC and we need to adapt the > > linux kernel for it. since we need something working soon, we will > > concentrate on the 2.4 version. > > We are just finishing up an Au1500 project right now. FCS was yesterday!!! > What we did was: > > > 1) get from AMD the PB1500 development CD. It has an "old" 2.4.17 kernel > along with MontaVista's HardHat Linux toolkit that's cross compiled to work on > x86 platforms. If you have the $$$, MontaVista offers great support for the > Au1500 based stuff. Their toolkit is top notch. > > 2) If you didn't already get from AMD a PB1500, do it. The development > platform is a very nice start and will save you may weeks of code testing > headaches (and cause a few special ones). At least for us here in USA, AMD > "loaned" a board at no charge, i.e. a purchase order is signed but they never > bill you. We're projected to buy some 25,000 Au1500s per year from them so > that probably helped. > > 3) From there, look at the 2.4 latest CVS tree on linux-mips and Pete's own > 36-bit mods in ftp://ftp.linux-mips.org/pub/linux/mips/people/ppopov/. > AMD/MontaVista also released a 2.4.18 "like" linux but its a bit rough. This was not part of a MV release, or AMD "release" for that matter. I think the rough port you got was from the working directory of an engineer at AMD, before I had a chance to update linux-mips.org. MVL 3.0 does support all three Pb1x boards and after the install, you're ready to go. > 4) there are lots of other resources and headaches if you plan to cross > compile X, gtk, etc. > > 5) we are flash based and used the special mods Pete put in to the 2.4.17 > kernel to support zImage flash booting. We're using YAMON as our monitor and > with a few changes have a pretty nice setup - boot wise. The zImage bits are not in linux-mips.org. I suppose I should create a patch and put it in my directory; one of these days :) Pete From dan@embeddededge.com Wed Feb 5 19:46:46 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 19:46:46 +0000 (GMT) Received: from 154-84-51-66.reonbroadband.com ([IPv6:::ffff:66.51.84.154]:2176 "EHLO tibook.netx4.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 19:46:46 +0000 Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1]) by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id h15JlJ205348; Wed, 5 Feb 2003 14:47:19 -0500 Message-ID: <3E416A47.2090900@embeddededge.com> Date: Wed, 05 Feb 2003 14:47:19 -0500 From: Dan Malek Organization: Embedded Edge, LLC. User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Popov CC: Bruno Randolf , linux-mips Subject: Re: which kernel tree for Au1500? References: <200302051234.01252.br1@4g-systems.de> <1044464033.9562.22.camel@adsl.pacbell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@embeddededge.com Precedence: bulk X-list: linux-mips Content-Length: 932 Lines: 26 Pete Popov wrote: > ....The PM support ... I haven't tested it in > linux-mips.org but it need a little work anyway. It needs more than a little work :-) I have lots of changes that attempt to support sleep mode on the Au1xxxx. Everything from saving/restoring core state, to sdram self refresh, to driver modifications for PM functions. I've done this in the sourceforge kernel and will update the linux-mips tree as I have time. Some of the patches will likely require some debate, as they touch software outside of the core Au1xxx functions. In addition to the kernel modifications, you need a boot rom that will support the kernel. It has to detect a wakeup condition, bring the memory back the life, perform some processor initialization, and then return to the kernel. Basically, copy what Yamon does. ;-) If someone is seriously working on this, drop me a note and we can exchange information. Thanks. -- Dan From ppopov@mvista.com Wed Feb 5 19:53:57 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 19:53:58 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:29944 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 19:53:57 +0000 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA14254; Wed, 5 Feb 2003 11:53:16 -0800 Subject: Re: which kernel tree for Au1500? From: Pete Popov To: Dan Malek Cc: Bruno Randolf , linux-mips In-Reply-To: <3E416A47.2090900@embeddededge.com> References: <200302051234.01252.br1@4g-systems.de> <1044464033.9562.22.camel@adsl.pacbell.net> <3E416A47.2090900@embeddededge.com> Content-Type: text/plain Organization: MontaVista Software Message-Id: <1044474844.12620.55.camel@zeus.mvista.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 11:54:04 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 1326 Lines: 38 On Wed, 2003-02-05 at 11:47, Dan Malek wrote: > Pete Popov wrote: > > > ....The PM support ... I haven't tested it in > > linux-mips.org but it need a little work anyway. > > It needs more than a little work :-) I only had in mind the frequency scaling work I had done, not the sleep mode. The frequency scaling "worked", but there were some bugs with the timer since using the 'wait' instruction results in the cp0 timer sleeping, but the external clock doesn't provide very good resolution. Pete > I have lots of changes that > attempt to support sleep mode on the Au1xxxx. Everything from > saving/restoring core state, to sdram self refresh, to driver > modifications for PM functions. I've done this in the sourceforge > kernel and will update the linux-mips tree as I have time. Some > of the patches will likely require some debate, as they touch software > outside of the core Au1xxx functions. > > In addition to the kernel modifications, you need a boot rom that > will support the kernel. It has to detect a wakeup condition, bring > the memory back the life, perform some processor initialization, and > then return to the kernel. Basically, copy what Yamon does. ;-) > > If someone is seriously working on this, drop me a note and we can > exchange information. > > Thanks. > > > -- Dan > > From cwu@deltartp.com Wed Feb 5 23:39:12 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Feb 2003 23:39:13 +0000 (GMT) Received: from mail.deltartp.com ([IPv6:::ffff:216.166.210.181]:47876 "EHLO dprn03.deltartp.com") by linux-mips.org with ESMTP id ; Wed, 5 Feb 2003 23:39:12 +0000 Received: by dprn03.deltartp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Feb 2003 18:21:39 -0500 Message-ID: From: Chien-Lung Wu To: "'linux-mips@linux-mips.org'" Subject: Software floating point Date: Wed, 5 Feb 2003 18:21:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: cwu@deltartp.com Precedence: bulk X-list: linux-mips Content-Length: 311 Lines: 11 Hi, I am building a cross-compiler for mips-linux on my linux box. Everything seems fine, except software floating point. How can I turn on the software floating point when I build the glibc? Is software floating point are supported in libm.a/libm.so or ant other lib*? Thanks for your help. Chien-Lung From clausen@pureza.melbourne.sgi.com Thu Feb 6 00:35:06 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 00:35:07 +0000 (GMT) Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:18879 "EHLO rj.sgi.com") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 00:35:06 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h15MZ8G8013447; Wed, 5 Feb 2003 14:35:09 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11378; Thu, 6 Feb 2003 11:34:55 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h160Ys8G001289; Thu, 6 Feb 2003 11:34:55 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h160YqpK001287; Thu, 6 Feb 2003 11:34:52 +1100 Date: Thu, 6 Feb 2003 11:34:52 +1100 From: Andrew Clausen To: Ralf Baechle Cc: Tibor Polgar , Jason Ormes , linux-mips@linux-mips.org Subject: Re: kernel boot error. Message-ID: <20030206003452.GA1278@pureza.melbourne.sgi.com> References: <200302041841.10507.jormes@wideopenwest.com> <20030205004345.GI27302@pureza.melbourne.sgi.com> <3E406ABC.A9D0D6F@freehandsystems.com> <20030205030625.GM27302@pureza.melbourne.sgi.com> <20030205150339.A13033@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030205150339.A13033@linux-mips.org> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 600 Lines: 18 On Wed, Feb 05, 2003 at 03:03:40PM +0100, Ralf Baechle wrote: > > Just, the base address the card (PCI bus?) is spitting out is very odd: > > > > eth0: SGI AceNIC Gigabit Ethernet at 0xfe7fc000, irq 8 > > > > The card is in slot 6, so I'd expect the base address to be 0x8900000. > > Anyway, it dies on this: > > Query the address using the usual Linux PCI bus stuff from . > Anything else is doomed, especially guessing ... That stuff is returning 0xfe7fc000. That is sane for an Intel configuration, but totally insane for Origins, and has no chance of working. Cheers, Andrew From lindahl@keyresearch.com Thu Feb 6 00:52:54 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 00:52:54 +0000 (GMT) Received: from 66-122-194-201.ded.pacbell.net ([IPv6:::ffff:66.122.194.201]:43652 "EHLO localhost.localdomain") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 00:52:54 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h160Tew6002587 for ; Wed, 5 Feb 2003 16:29:40 -0800 Received: (from lindahl@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id h160TdIE002585 for linux-mips@linux-mips.org; Wed, 5 Feb 2003 16:29:39 -0800 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Wed, 5 Feb 2003 16:29:39 -0800 From: Greg Lindahl To: linux-mips@linux-mips.org Subject: hidden bug in 32 bit kernel ejtag Message-ID: <20030206002939.GA2560@greglaptop.internal.keyresearch.com> Mail-Followup-To: linux-mips@linux-mips.org References: <20030124141524.GA685@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030124141524.GA685@excalibur.cologne.de> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lindahl@keyresearch.com Precedence: bulk X-list: linux-mips Content-Length: 499 Lines: 12 While inspecting the 2.4 cvs kernel, I saw that arch/mips/kernel/head.S does not have a .align for ejtag_debug_buffer -- just a ".fill 4". The alignment happens to be correct, I guess since it's the first .data segment item in the file, but anyone rearranging the code could trigger a misalignment, which causes an unaligned trap inside an exception... try debugging that one. (OK, I got lucky...) The 64 bit cvs kernel doesn't yet have this ejtag stuff in it. 2.5 looks the same as 2.4. -- greg From benyates3@comcast.net Thu Feb 6 01:36:54 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 01:36:54 +0000 (GMT) Received: from smtp.comcast.net ([IPv6:::ffff:24.153.64.2]:9504 "EHLO smtp.comcast.net") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 01:36:54 +0000 Received: from cc989312a (pcp288636pcs.owngsm01.md.comcast.net [68.55.136.50]) by mtaout06.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.09 (built Jan 7 2003)) with SMTP id <0H9V00LKC5SLBB@mtaout06.icomcast.net> for linux-mips@linux-mips.org; Wed, 05 Feb 2003 20:36:22 -0500 (EST) Date: Wed, 05 Feb 2003 20:36:24 -0500 From: benyates3@comcast.net Subject: Question To: linux-mips@linux-mips.org Cc: Ben Yates Message-id: <002301c2cd80$28e5ec20$bc00a8c0@cc989312a> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: multipart/alternative; boundary="Boundary_(ID_cc7gAPB+JO/g2bStj9eV1w)" X-Priority: 3 X-MSMail-priority: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: benyates3@comcast.net Precedence: bulk X-list: linux-mips Content-Length: 984 Lines: 28 This is a multi-part message in MIME format. --Boundary_(ID_cc7gAPB+JO/g2bStj9eV1w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT I'm a student and is wondering if you could tell me what version of Linux is suitable for a SGI Indigo 2 machine? Thanks. Ben Yates 443-677-2693 --Boundary_(ID_cc7gAPB+JO/g2bStj9eV1w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

I'm a student and is wondering if you could tell me what version of Linux is suitable for a SGI Indigo 2 machine? Thanks.

Ben Yates
443-677-2693

--Boundary_(ID_cc7gAPB+JO/g2bStj9eV1w)-- From clausen@pureza.melbourne.sgi.com Thu Feb 6 02:40:02 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 02:40:03 +0000 (GMT) Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:7888 "EHLO rj.sgi.com") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 02:40:02 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h160e6G8021756; Wed, 5 Feb 2003 16:40:07 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA12628; Thu, 6 Feb 2003 13:39:54 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h162ds8G001758; Thu, 6 Feb 2003 13:39:54 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h162dqtK001756; Thu, 6 Feb 2003 13:39:52 +1100 Date: Thu, 6 Feb 2003 13:39:52 +1100 From: Andrew Clausen To: Guido Guenther , Linux/MIPS Development Subject: Re: debian installer on mips64 (origin 200) Message-ID: <20030206023952.GC1278@pureza.melbourne.sgi.com> References: <20030203041432.GF967@pureza.melbourne.sgi.com> <20030205092800.GD16674@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030205092800.GD16674@bogon.ms20.nix> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips Content-Length: 677 Lines: 18 On Wed, Feb 05, 2003 at 10:28:00AM +0100, Guido Guenther wrote: > > Perhaps a better approach is to get the kernel to prompt users to > > change disks, and stick in the vanilla debian CD? i.e. have a > > "mips64-bootstrap.img" CD image, which prompts for install-1 afterwards. > > Why not use the CONFIG_EMBEDDED_RAMDISK option to append the installer > image as initrd to the kernel and dump this into the vh? To build the vh > on the CD you can probably use the same script Flo made for IP22: > http://www.silicon-verl.de/home/flo/software/genisovh-0.1.tgz Sounds sane :) Unfortunately, I haven't been able to boot kernels stored in the volume header :( Cheers, Andrew From agx@sigxcpu.org Thu Feb 6 09:26:41 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 09:26:41 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:30440 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 09:26:41 +0000 Received: from bogon.sigxcpu.org (unknown [134.34.147.122]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 5C0D92BC2D for ; Thu, 6 Feb 2003 10:26:36 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 852114AF4C; Thu, 6 Feb 2003 10:24:56 +0100 (CET) Date: Thu, 6 Feb 2003 10:24:56 +0100 From: Guido Guenther To: linux-mips@linux-mips.org Subject: Re: Question Message-ID: <20030206092456.GB12005@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , linux-mips@linux-mips.org References: <002301c2cd80$28e5ec20$bc00a8c0@cc989312a> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002301c2cd80$28e5ec20$bc00a8c0@cc989312a> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips Content-Length: 438 Lines: 9 On Wed, Feb 05, 2003 at 08:36:24PM -0500, benyates3@comcast.net wrote: > I'm a student and is wondering if you could tell me what version of Linux is suitable for a SGI Indigo 2 machine? Thanks. There are basically two more or less complete distributions out there: ftp://ftp.linux-mips.org:/pub/linux/mips/redhat and http://ports.debian.org/mips However only XL graphics is supported on the I2, Express and Impact aren't. -- Guido From ralf@linux-mips.org Thu Feb 6 10:51:36 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 10:51:37 +0000 (GMT) Received: from p508B66FD.dip.t-dialin.net ([IPv6:::ffff:80.139.102.253]:26085 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 10:51:36 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h16ApU803231; Thu, 6 Feb 2003 11:51:30 +0100 Date: Thu, 6 Feb 2003 11:51:30 +0100 From: Ralf Baechle To: Chien-Lung Wu Cc: "'linux-mips@linux-mips.org'" Subject: Re: Software floating point Message-ID: <20030206115130.A27384@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cwu@deltartp.com on Wed, Feb 05, 2003 at 06:21:34PM -0500 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 453 Lines: 12 On Wed, Feb 05, 2003 at 06:21:34PM -0500, Chien-Lung Wu wrote: > I am building a cross-compiler for mips-linux on my linux box. > Everything seems fine, except software floating point. > How can I turn on the software floating point when I build the glibc? > Is software floating point are supported in libm.a/libm.so or ant other > lib*? The kernel includes a floating point emulator so your hard fp code will run fine on fpu-less code. Ralf From ralf@linux-mips.org Thu Feb 6 11:26:06 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 11:26:06 +0000 (GMT) Received: from p508B66FD.dip.t-dialin.net ([IPv6:::ffff:80.139.102.253]:49125 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 11:26:06 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h16BPu003825; Thu, 6 Feb 2003 12:25:56 +0100 Date: Thu, 6 Feb 2003 12:25:56 +0100 From: Ralf Baechle To: Tor Arntsen Cc: linux-mips@linux-mips.org Subject: Re: kernel boot error. Message-ID: <20030206122556.B27384@linux-mips.org> References: <200302051707.h15H7ocM000681@pallas.spacetec.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200302051707.h15H7ocM000681@pallas.spacetec.no>; from tor@spacetec.no on Wed, Feb 05, 2003 at 06:07:49PM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 679 Lines: 15 On Wed, Feb 05, 2003 at 06:07:49PM +0100, Tor Arntsen wrote: > >His particular machine is a uniprocessor machine, a very rare configuration. > >In all the years I'm working with Origins this is just the second I > >encounter. Note that disabling one of the processor doesn't suffice; > >this problem really only seems to hit machines with one physical processor. > > 1-CPU Origin-200's are not that uncommon.. I have one right here. Although > we mostly used to buy 2-CPU Origins we also bought 1-CPU Origins now and > then, depending on what we planned to use them for. It's all about price > in the end. Maybe my machine room at SGI was just equipped to well :-) Ralf From iilangov@cisco.com Thu Feb 6 14:04:49 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 14:04:50 +0000 (GMT) Received: from sj-msg-core-1.cisco.com ([IPv6:::ffff:171.71.163.11]:26519 "EHLO sj-msg-core-1.cisco.com") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 14:04:49 +0000 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16E4fSQ021769 for ; Thu, 6 Feb 2003 06:04:42 -0800 (PST) Received: from IILANGOVW2K ([10.77.139.167]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id TAA19712 for ; Thu, 6 Feb 2003 19:33:35 +0530 (IST) Message-ID: <005201c2cde8$b145e5d0$a78b4d0a@apac.cisco.com> From: "Indukumar Ilangovan" To: Subject: manipulating e_machine value in the elf Header Date: Thu, 6 Feb 2003 19:34:40 +0530 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: iilangov@cisco.com Precedence: bulk X-list: linux-mips Hi, I'm trying to port linux kernel to a mips board with a R4700 processor. It has a rom monitor program which can be used to load the image. (has support for tftp boot, xmodem....) . This bootloader has a hardcoded cpu_type which is cross checked with the e_machine value in the elf header. When I try to load the linux kernel this check (cpu_type == e_machine) fails & hence the boot loader aborts the loading of image. I tried to change the e_machine type value by changing the EM_MIPS value in include/linux/elf.h, still e_machine type is "8" in the image even after completely rebuilding the image. I even changed the EM_MIPS value in /usr/include/elf.h & couple of other locations (sde headers.....) still no luck....though hand editing the elf header is an option.. I don't want to do that ! If any of you have any idea/suggestions I would be a happy man ! Thanks in advance, Indu From Ben_Yates@cable.comcast.com Thu Feb 6 14:35:55 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 14:35:55 +0000 (GMT) Received: from [IPv6:::ffff:208.17.32.26] ([IPv6:::ffff:208.17.32.26]:39989 "EHLO cdcavux01.cable.comcast.com") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 14:35:55 +0000 Received: from cdcexsmtp01.cable.comcast.com (localhost [127.0.0.1]) by cdcavux01.cable.comcast.com (8.11.6+Sun/8.11.6) with ESMTP id h16EZk112256; Thu, 6 Feb 2003 09:35:47 -0500 (EST) Received: by cdcexsmtp01.cable.comcast.com with Internet Mail Service (5.5.2656.59) id <1L5B4S4D>; Thu, 6 Feb 2003 09:35:46 -0500 Message-ID: <94A55F1D6E06F048B4BCACA34415D78B03D314E9@whtexcg04.cable.comcast.com> From: "Yates, Ben" To: "'linux-mips@linux-mips.org'" Cc: "Benyates3 (benyates3@comcast.net)" Subject: Need help Date: Thu, 6 Feb 2003 09:35:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CDEC.E2FA8800" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Ben_Yates@cable.comcast.com Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CDEC.E2FA8800 Content-Type: text/plain Hi, I'm a student and wondering if there is anyone out there could send me full instructions step by step on how to successfully install Linux on a SGI Indigo2 machine and what particular version of Linux is needed? Thanks for any help. Ben Yates 443-677-2693 ------_=_NextPart_001_01C2CDEC.E2FA8800 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Need help

Hi,
I'm a student and wondering if there = is anyone out there could send me full instructions step by step on how = to successfully install Linux on a SGI Indigo2 machine and what = particular version of Linux is needed? Thanks for any help.

Ben = Yates
443-677-2693

------_=_NextPart_001_01C2CDEC.E2FA8800-- From ralf@linux-mips.org Thu Feb 6 14:52:42 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 14:52:42 +0000 (GMT) Received: from p508B66FD.dip.t-dialin.net ([IPv6:::ffff:80.139.102.253]:28392 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 14:52:42 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h16EqU821641; Thu, 6 Feb 2003 15:52:30 +0100 Date: Thu, 6 Feb 2003 15:52:30 +0100 From: Ralf Baechle To: Indukumar Ilangovan Cc: linux-mips@linux-mips.org Subject: Re: manipulating e_machine value in the elf Header Message-ID: <20030206155230.A21248@linux-mips.org> References: <005201c2cde8$b145e5d0$a78b4d0a@apac.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <005201c2cde8$b145e5d0$a78b4d0a@apac.cisco.com>; from iilangov@cisco.com on Thu, Feb 06, 2003 at 07:34:40PM +0530 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 06, 2003 at 07:34:40PM +0530, Indukumar Ilangovan wrote: > I'm trying to port linux kernel to a mips board with a R4700 processor. It > has a rom monitor program which can be used to load the image. (has support > for tftp boot, xmodem....) . This bootloader has a hardcoded cpu_type which > is cross checked with the e_machine value in the elf header. When I try to > load the linux kernel this check (cpu_type == e_machine) fails & hence the > boot loader aborts the loading of image. > > I tried to change the e_machine type value by changing the EM_MIPS value in > include/linux/elf.h, still e_machine type is "8" in the image even after > completely rebuilding the image. I even changed the EM_MIPS value in > /usr/include/elf.h & couple of other locations (sde headers.....) still no > luck....though hand editing the elf header is an option.. I don't want to do > that ! I guess you're hunting the problem at the wrong place. All MIPS ELF systems are using EM_MIPS (8) for the e_machine. A few ancient systems have been using EM_MIPS_RS3_LE (10) but I've yet to see a system using that value. So probably the bootloader is expecting the wrong value? Your attempt at changing that value didn't work because the value is hardcoded in binutils. However if you change that value you'd break binary compatibility with each and every Linux/MIPS binary. Ralf From ralf@linux-mips.org Thu Feb 6 16:55:11 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Feb 2003 16:55:12 +0000 (GMT) Received: from p508B66FD.dip.t-dialin.net ([IPv6:::ffff:80.139.102.253]:52202 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 6 Feb 2003 16:55:11 +0000 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h16GrX923933; Thu, 6 Feb 2003 17:53:33 +0100 Date: Thu, 6 Feb 2003 17:53:33 +0100 From: Ralf Baechle To: Andrew Clausen Cc: Guido Guenther , linux-mips@linux-mips.org Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030206175333.A22327@linux-mips.org> References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> <20030204223930.GD27302@pureza.melbourne.sgi.com> <20030204231203.GY16674@bogon.ms20.nix> <20030204231909.GE27302@pureza.melbourne.sgi.com> <20030204234529.GZ16674@bogon.ms20.nix> <20030204235543.GG27302@pureza.melbourne.sgi.com> <20030205000734.GA16674@bogon.ms20.nix> <20030205001911.GH27302@pureza.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030205001911.GH27302@pureza.melbourne.sgi.com>; from clausen@melbourne.sgi.com on Wed, Feb 05, 2003 at 11:19:11AM +1100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 05, 2003 at 11:19:11AM +1100, Andrew Clausen wrote: > On Wed, Feb 05, 2003 at 01:07:35AM +0100, Guido Guenther wrote: > > On IP22 the PROM uses SystemPartition to find the kernel/bootloader. > > We set it to something like scsi(0)disk(1)rdisk(0)partition(8) to grab > > it from the vh. Is SystemPartition used differently on IP27? > > I think SystemPartition is ignored (haven't been able to see any > evidence to the contrary... I should look in the source...) SystemPartition is to be used by the bootloader, that is sash in SGI's case. So when booting a kernel directly from the volume header from the firmware's point of view SystemPartition's value is irrelevant. Afair it's used for all non-absolute filenames where absolute ARC filenames are starting with a device specificer like scsi(0)disk(1)partition(1), not just a slash to indicate search from the fs root. > > [..snip..] > > > So, we should obviously support OSLoadPartition=/dev/sda1 (=> root=/dev/sda1), > > > but it would also be nice to support OSLoadPartition=dksc(0,1,3). > > Well we could either check if OSLoadPartition matches the linux device > > naming scheme or the other way around and see if it looks like a valid > > device identifier used by the PROM (I'd prefer the later, though) - or > > simply make the OSLoadPartition <-> root= mapping '#ifdef CONFIG_SGI_IP22'. > > I think the middle option (the one you prefer) of matching dksc(0,1,3) > and converting it /dev/sda2 is best. Just, it has to happen after the > hard disks are probed - /dev/sdXY are allocated dynamically (in > a predictable-for-end-user way), so you need to find out what it was > allocated to. Is this doable in a nice way? Checkout ROOT_DEV and it's use in init/main.c. Options such as root=... are parsed very early during bootup. After that is done you could check if the value of ROOT_DEV is still 0 that is no root=... was passed and fallback to a value derived from SystemPartition at some later stage. Feel free to read the devfs code for additional transpiration ;) > BTW, I think file system labels are a much better way of identifying FSs. ARC dates back more than 10 years back. It was written with PC partitions and NT as OS in mind. So don't expect fancy concepts or sanity ;-) > Perhaps this discussion is irrelevant... people who are using > OSLoadPartition to control their bootloader should just add a root= > option. The ARC code is also used by non-SGI systems and on some of those using a non-standard variables is a bit of a pita. SystemPartition The default path for the system partition. OSLoader The default path for an operating-system loader program. OSLoadPartition The default pathname of the partition containing the program to be loaded by the operating-system loader. OSLoadFilename The default filename of the program the operating system loader is to load. Btw, device names like dksc(0,1,2) came from SGI's / MIPS's pre-ARC firmware so are deprecated since 10 years. Some things just don't want to die. Ralf From clausen@pureza.melbourne.sgi.com Fri Feb 7 00:25:00 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Feb 2003 00:25:01 +0000 (GMT) Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:5048 "EHLO rj.sgi.com") by linux-mips.org with ESMTP id ; Fri, 7 Feb 2003 00:25:00 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h16MP6G8025142; Thu, 6 Feb 2003 14:25:07 -0800 Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23045; Fri, 7 Feb 2003 11:24:54 +1100 Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h170Os8G007942; Fri, 7 Feb 2003 11:24:55 +1100 Received: (from clausen@localhost) by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h170OrDY007940; Fri, 7 Feb 2003 11:24:53 +1100 Date: Fri, 7 Feb 2003 11:24:53 +1100 From: Andrew Clausen To: Ralf Baechle Cc: Andrew Clausen , Guido Guenther , linux-mips@linux-mips.org Subject: Re: [patch] cmdline.c rewrite Message-ID: <20030207002453.GG1278@pureza.melbourne.sgi.com> References: <20030204061323.GA27302@pureza.melbourne.sgi.com> <20030204092417.GR16674@bogon.ms20.nix> <20030204223930.GD27302@pureza.melbourne.sgi.com> <20030204231203.GY16674@bogon.ms20.nix> <20030204231909.GE27302@pureza.melbourne.sgi.com> <20030204234529.GZ16674@bogon.ms20.nix> <20030204235543.GG27302@pureza.melbourne.sgi.com> <20030205000734.GA16674@bogon.ms20.nix> <20030205001911.GH27302@pureza.melbourne.sgi.com> <20030206175333.A22327@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030206175333.A22327@linux-mips.org> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clausen@melbourne.sgi.com Precedence: bulk X-list: linux-mips On Thu, Feb 06, 2003 at 05:53:33PM +0100, Ralf Baechle wrote: > > I think SystemPartition is ignored (haven't been able to see any > > evidence to the contrary... I should look in the source...) > > SystemPartition is to be used by the bootloader, that is sash in SGI's case. AFAICT, sash ignores SystemPartition here. > > BTW, I think file system labels are a much better way of identifying FSs. > > ARC dates back more than 10 years back. It was written with PC partitions > and NT as OS in mind. So don't expect fancy concepts or sanity ;-) I'm talking about linux. Linux should default to "root=rootfs", or something. If linux installers set labels, that is. > The ARC code is also used by non-SGI systems and on some of those using a > non-standard variables is a bit of a pita. > > SystemPartition The default path for the system partition. What's the "system partition"? I think this is an Irix thing, but I don't have any evidence. > Btw, device names like dksc(0,1,2) came from SGI's / MIPS's pre-ARC firmware > so are deprecated since 10 years. Some things just don't want to die. It requires a lot less typing ;) Cheers, Andrew From jsun@orion.mvista.com Fri Feb 7 00:36:59 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Feb 2003 00:37:00 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:46331 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Fri, 7 Feb 2003 00:36:59 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id h170alO03746; Thu, 6 Feb 2003 16:36:47 -0800 Date: Thu, 6 Feb 2003 16:36:47 -0800 From: Jun Sun To: Vivien Chappelier Cc: Ralf Baechle , linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [PATCH 2.5] r4k_switch task_struct/thread_info fixes Message-ID: <20030206163647.F13258@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 vivienc@nerim.net on Mon, Feb 03, 2003 at 11:21:50PM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips Actually the following hunks are not right. ST_OFF should be applied against the task_struct, which is a0, not thread_info (t3). Try to back off the change and see if things are ok. Also see my next email before you rush into trying :-) Jun On Mon, Feb 03, 2003 at 11:21:50PM +0100, Vivien Chappelier wrote: > /* > * clear saved user stack CU1 bit > */ > - ld t0, ST_OFF(a0) > + ld t0, ST_OFF(t3) > li t1, ~ST0_CU1 > and t0, t0, t1 > - sd t0, ST_OFF(a0) > + sd t0, ST_OFF(t3) > > > sll t2, t0, 5 > Index: arch/mips/kernel/r4k_switch.S > =================================================================== > RCS file: /home/cvs/linux/arch/mips/kernel/r4k_switch.S,v > retrieving revision 1.29 > diff -u -r1.29 r4k_switch.S > --- arch/mips/kernel/r4k_switch.S 5 Nov 2002 19:51:47 -0000 1.29 > +++ arch/mips/kernel/r4k_switch.S 3 Feb 2003 22:06:17 -0000 > @@ -67,10 +67,10 @@ > /* > * clear saved user stack CU1 bit > */ > - lw t0, ST_OFF(a0) > + lw t0, ST_OFF(t3) > li t1, ~ST0_CU1 > and t0, t0, t1 > - sw t0, ST_OFF(a0) > + sw t0, ST_OFF(t3) > > FPU_SAVE_DOUBLE(a0, t0) # clobbers t0 > > From jsun@orion.mvista.com Fri Feb 7 00:43:52 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Feb 2003 00:43:52 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:20733 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Fri, 7 Feb 2003 00:43:51 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id h170hgF03759; Thu, 6 Feb 2003 16:43:42 -0800 Date: Thu, 6 Feb 2003 16:43:42 -0800 From: Jun Sun To: Vivien Chappelier Cc: Ralf Baechle , linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [PATCH 2.5] clear USEDFPU in copy_thread Message-ID: <20030206164342.G13258@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 vivienc@nerim.net on Tue, Feb 04, 2003 at 11:54:38PM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips You should *not* clear USEDFPU in copy_thread(). Imagine you assign a floating point variable f=0.3, then do fork() and then in the child process, alas, f is undefined (zero most likely). If you really want to do it, it should be in start_thread(). Even if you don't have it cleared in start_thread(), things should be generally OK. You will have some dirty FPU content instead of a all-zero one when you start a new program. But then since all sane program should assign register values before they first time use them, so this bug should be well hidden. I am still curious whether this is a bug in i386 as well or they do clear the flag in some non-obvious way. Note that the unlazy_fpu() in copy_thread won't do it. It only clears the current process's USEDFPU flag, while the child process's flag is set way back in copy_flags() calls inside do_fork(). Jun On Tue, Feb 04, 2003 at 11:54:38PM +0100, Vivien Chappelier wrote: > Hi, > > When copying a thread, access to the FPU is disabled by clearing > the ST0_CU1 bit in the new thread saved CP0_STATUS register. However, the > corresponding TIF_USEDFPU flag is not cleared at it should to indicate the > FPU has not yet been used by the new process. > This patch also clears user_tid in mips64 code, and moves it away > from the FPU comment in the mips code. > > Vivien. > > Index: arch/mips64/kernel/process.c > =================================================================== > RCS file: /home/cvs/linux/arch/mips64/kernel/process.c,v > retrieving revision 1.36 > diff -u -r1.36 process.c > --- arch/mips64/kernel/process.c 9 Jan 2003 19:16:50 -0000 1.36 > +++ arch/mips64/kernel/process.c 4 Feb 2003 22:47:00 -0000 > @@ -114,6 +114,8 @@ > p->thread.reg29 = (unsigned long) childregs; > p->thread.reg31 = (unsigned long) ret_from_fork; > > + p->user_tid = NULL; > + > /* > * New tasks loose permission to use the fpu. This accelerates context > * switching for most programs since they don't use the fpu. > @@ -121,6 +123,7 @@ > p->thread.cp0_status = read_c0_status() & > ~(ST0_CU3|ST0_CU2|ST0_CU1|ST0_KSU); > childregs->cp0_status &= ~(ST0_CU3|ST0_CU2|ST0_CU1); > + clear_ti_thread_flag(ti, TIF_USEDFPU); > > return 0; > } > Index: arch/mips/kernel/process.c > =================================================================== > RCS file: /home/cvs/linux/arch/mips/kernel/process.c,v > retrieving revision 1.50 > diff -u -r1.50 process.c > --- arch/mips/kernel/process.c 9 Jan 2003 19:16:50 -0000 1.50 > +++ arch/mips/kernel/process.c 4 Feb 2003 22:47:04 -0000 > @@ -117,6 +117,8 @@ > p->thread.reg29 = (unsigned long) childregs; > p->thread.reg31 = (unsigned long) ret_from_fork; > > + p->user_tid = NULL; > + > /* > * New tasks loose permission to use the fpu. This accelerates context > * switching for most programs since they don't use the fpu. > @@ -124,7 +126,7 @@ > p->thread.cp0_status = read_c0_status() & > ~(ST0_CU2|ST0_CU1|KU_MASK); > childregs->cp0_status &= ~(ST0_CU2|ST0_CU1); > - p->user_tid = NULL; > + clear_ti_thread_flag(ti, TIF_USEDFPU); > > return 0; > } > From quintela@mandrakesoft.com Fri Feb 7 01:21:23 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Feb 2003 01:21:24 +0000 (GMT) Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:8489 "EHLO trasno.mitica") by linux-mips.org with ESMTP id ; Fri, 7 Feb 2003 01:21:23 +0000 Received: by trasno.mitica (Postfix, from userid 1001) id C31C4C4B1; Fri, 7 Feb 2003 02:20:58 +0100 (CET) To: Jun Sun Cc: Vivien Chappelier , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH 2.5] clear USEDFPU in copy_thread X-Url: http://people.mandrakesoft.com/~quintela From: Juan Quintela In-Reply-To: <20030206164342.G13258@mvista.com> (Jun Sun's message of "Thu, 6 Feb 2003 16:43:42 -0800") User-Agent: Gnus/5.090012 (Oort Gnus v0.12) Emacs/21.2.92 (i386-mandrake-linux-gnu) References: <20030206164342.G13258@mvista.com> Date: Fri, 07 Feb 2003 02:20:58 +0100 Message-ID: <86hebgj37p.fsf@trasno.mitica> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: quintela@mandrakesoft.com Precedence: bulk X-list: linux-mips >>>>> "jun" == Jun Sun writes: Hi jun> Even if you don't have it cleared in start_thread(), things jun> should be generally OK. You will have some dirty FPU content jun> instead of a all-zero one when you start a new program. But then jun> since all sane program should assign register values before they jun> first time use them, so this bug should be well hidden. I don't remind the exact details, but the problem appears to be the security implications, you can see last values of previous process. Yes, I still have to find a way where that is useful, but ... Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From vivienc@nerim.net Fri Feb 7 09:29:16 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Feb 2003 09:29:17 +0000 (GMT) Received: from smtp-102.noc.nerim.net ([IPv6:::ffff:62.4.17.102]:63504 "EHLO mallaury.noc.nerim.net") by linux-mips.org with ESMTP id ; Fri, 7 Feb 2003 09:29:16 +0000 Received: from melkor (vivienc.net1.nerim.net [213.41.134.233]) by mallaury.noc.nerim.net (Postfix) with ESMTP id B19F062E2A; Fri, 7 Feb 2003 10:29:14 +0100 (CET) Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.36 #1 (Debian)) id 18h4ou-0000Vn-00; Fri, 07 Feb 2003 10:29:16 +0100 Date: Fri, 7 Feb 2003 10:29:16 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Jun Sun Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH 2.5] r4k_switch task_struct/thread_info fixes In-Reply-To: <20030206163647.F13258@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 1361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vivienc@nerim.net Precedence: bulk X-list: linux-mips On Thu, 6 Feb 2003, Jun Sun wrote: > Actually the following hunks are not right. ST_OFF > should be applied against the task_struct, which is a0, > not thread_info (t3). In 2.4 yes, not in 2.5. include/linux/sched.h:469 > union thread_union { > struct thread_info thread_info; > unsigned long stack[INIT_THREAD_SIZE/sizeof(long)]; > }; That means the top of the stack is actually at (task->thread_info + KERNEL_STACK_SIZE) in 2.5. See for example arch/mips64/kernel/ptrace.c:107 > Also see my next email before you rush into trying :-) Ok, I'll look at it later. Vivien. From andreev@niisi.msk.ru Fri Feb 7 14:39:10 2003 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Feb 2003 14:39:11 +0000 (GMT) Received: from t111.niisi.ras.ru ([IPv6:::ffff:193.232.173.111]:15426 "EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP id ; Fri, 7 Feb 2003 14:39:10 +0000 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id RAA29876 for ; Fri, 7 Feb 2003 17:39:19 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id RAA22448 for linux-mips@linux-mips.org; Fri, 7 Feb 2003 17:41:33 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id h17ELqxl009762 for ; Fri, 7 Feb 2003 17:21:53 +0300 (MSK) Message-ID: <3E43ECC6.8090109@niisi.msk.ru> Date: Fri, 07 Feb 2003 17:28:38 +0000 From: Alexandr Andreev