From anemo@mba.ocn.ne.jp Thu Jul 1 13:09:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jul 2004 13:10:01 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:38379 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Thu, 1 Jul 2004 13:09:56 +0100 Received: from localhost (p6018-ipad28funabasi.chiba.ocn.ne.jp [220.107.205.18]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id F207B6D7A for ; Thu, 1 Jul 2004 21:09:51 +0900 (JST) Date: Thu, 01 Jul 2004 21:14:56 +0900 (JST) Message-Id: <20040701.211456.59461492.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: possible overflow in __udelay From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 5388 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: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Current __udelay implementation will cause internal overflow on the first multiplication. Basically, the multiplication is: X = usecs * 2**64 / (100000 / HZ) And maximum input usecs value is 5000 (MAX_UDELAY_MS * 1000). If usecs == 5000 and HZ == 1000, X is 5 * 2**64. Of course this can not be held in 64bit variable. How should we avoid the overflow? 1. Use smaller HZ. HZ < 200 should be OK. 2. Use smaller MAX_UDELAY_MS. The arch specific delay.h can provide its own MAX_UDELAY_MS. MAX_UDELAY_MS == 1 should be OK. 3. Use smaller multiplier. This example should be OK (but lose some precision on larger HZ) #if HZ < (1000 / MAX_UDELAY_MS) usecs *= (0x8000000000000000UL / (500000 / HZ)); #elif HZ < ((1000 / MAX_UDELAY_MS) << 1) usecs *= (0x8000000000000000UL / (500000 / HZ)) >> 1; lpj <<= 1 #elif HZ < ((1000 / MAX_UDELAY_MS) << 2) usecs *= (0x8000000000000000UL / (500000 / HZ)) >> 2; lpj <<= 2 #else usecs *= (0x8000000000000000UL / (500000 / HZ)) >> 3; lpj <<= 3 #endif Any idea? --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Thu Jul 1 14:16:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jul 2004 14:16:24 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:9408 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Thu, 1 Jul 2004 14:16:20 +0100 Received: from localhost (p6018-ipad28funabasi.chiba.ocn.ne.jp [220.107.205.18]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 1DC986E7B; Thu, 1 Jul 2004 22:16:16 +0900 (JST) Date: Thu, 01 Jul 2004 22:21:20 +0900 (JST) Message-Id: <20040701.222120.41626500.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: 2.4 pci_dma_sync_sg fix From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 5389 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: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips pci_dma_sync_sg in 2.4 tree seems broken. pci_map_sg were fixed a while ago. Please fix pci_dma_sync_sg also. Here is a patch. Index: pci.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/pci.h,v retrieving revision 1.24.2.16 diff -u -r1.24.2.16 pci.h --- pci.h 17 Nov 2003 01:07:45 -0000 1.24.2.16 +++ pci.h 1 Jul 2004 13:10:48 -0000 @@ -270,20 +270,28 @@ */ static inline void pci_dma_sync_sg(struct pci_dev *hwdev, struct scatterlist *sg, - int nelems, int direction) + int nents, int direction) { -#ifdef CONFIG_NONCOHERENT_IO int i; -#endif if (direction == PCI_DMA_NONE) out_of_line_bug(); - /* Make sure that gcc doesn't leave the empty loop body. */ -#ifdef CONFIG_NONCOHERENT_IO - for (i = 0; i < nelems; i++, sg++) - dma_cache_wback_inv((unsigned long)sg->address, sg->length); -#endif + for (i = 0; i < nents; i++, sg++) { + if (sg->address && sg->page) + out_of_line_bug(); + else if (!sg->address && !sg->page) + out_of_line_bug(); + + if (sg->address) { + dma_cache_wback_inv((unsigned long)sg->address, + sg->length); + } else { + dma_cache_wback_inv((unsigned long) + (page_address(sg->page) + sg->offset), + sg->length); + } + } } /* --- Atsushi Nemoto From ralf@linux-mips.org Thu Jul 1 14:22:43 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jul 2004 14:22:47 +0100 (BST) Received: from p508B68D3.dip.t-dialin.net ([IPv6:::ffff:80.139.104.211]:51224 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 1 Jul 2004 14:22:43 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i61DMfMd006291; Thu, 1 Jul 2004 15:22:41 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i61DMeQa006290; Thu, 1 Jul 2004 15:22:40 +0200 Date: Thu, 1 Jul 2004 15:22:40 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: 2.4 pci_dma_sync_sg fix Message-ID: <20040701132240.GA6219@linux-mips.org> References: <20040701.222120.41626500.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040701.222120.41626500.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.1i 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: 5390 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, Jul 01, 2004 at 10:21:20PM +0900, Atsushi Nemoto wrote: > pci_dma_sync_sg in 2.4 tree seems broken. pci_map_sg were fixed a > while ago. Please fix pci_dma_sync_sg also. Leave the #ifdef stuff there - or otherwise gcc might optimize this into empty loops ... Ralf From anemo@mba.ocn.ne.jp Thu Jul 1 14:40:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jul 2004 14:40:38 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:45013 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Thu, 1 Jul 2004 14:40:34 +0100 Received: from localhost (p6018-ipad28funabasi.chiba.ocn.ne.jp [220.107.205.18]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 78E307346; Thu, 1 Jul 2004 22:40:30 +0900 (JST) Date: Thu, 01 Jul 2004 22:45:35 +0900 (JST) Message-Id: <20040701.224535.71082878.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: 2.4 pci_dma_sync_sg fix From: Atsushi Nemoto In-Reply-To: <20040701132240.GA6219@linux-mips.org> References: <20040701.222120.41626500.anemo@mba.ocn.ne.jp> <20040701132240.GA6219@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 5391 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: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Thu, 1 Jul 2004 15:22:40 +0200, Ralf Baechle said: ralf> Leave the #ifdef stuff there - or otherwise gcc might optimize ralf> this into empty loops ... The loop contains paranoid out_of_line_bug, so it never be optimized to empty. --- Atsushi Nemoto From ralf@linux-mips.org Thu Jul 1 17:03:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jul 2004 17:03:56 +0100 (BST) Received: from p508B68D3.dip.t-dialin.net ([IPv6:::ffff:80.139.104.211]:55321 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 1 Jul 2004 17:03:52 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i61DxJ5Z006983; Thu, 1 Jul 2004 15:59:19 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i61DxJx9006982; Thu, 1 Jul 2004 15:59:19 +0200 Date: Thu, 1 Jul 2004 15:59:19 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: 2.4 pci_dma_sync_sg fix Message-ID: <20040701135919.GA6906@linux-mips.org> References: <20040701.222120.41626500.anemo@mba.ocn.ne.jp> <20040701132240.GA6219@linux-mips.org> <20040701.224535.71082878.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040701.224535.71082878.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.1i 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: 5392 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, Jul 01, 2004 at 10:45:35PM +0900, Atsushi Nemoto wrote: > >>>>> On Thu, 1 Jul 2004 15:22:40 +0200, Ralf Baechle said: > > ralf> Leave the #ifdef stuff there - or otherwise gcc might optimize > ralf> this into empty loops ... > > The loop contains paranoid out_of_line_bug, so it never be optimized > to empty. Indeed and I think that's a bit of overkill. I've never seen these assertions catch any bugs - and 2.4 isn't exactly new anymore. Anyway, even if the loop was empty gcc would not eleminate it. Ralf From confirm-return-linux-mips=linux-mips.org@returns.groups.yahoo.com Fri Jul 2 08:07:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jul 2004 08:07:41 +0100 (BST) Received: from n38.grp.scd.yahoo.com ([IPv6:::ffff:66.218.66.106]:22362 "HELO n38.grp.scd.yahoo.com") by linux-mips.org with SMTP id ; Fri, 2 Jul 2004 08:07:36 +0100 X-eGroups-Return: confirm-return-linux-mips=linux-mips.org@returns.groups.yahoo.com Received: from [66.218.66.31] by n38.grp.scd.yahoo.com with NNFMP; 02 Jul 2004 07:07:28 -0000 Received: (qmail 31372 invoked by uid 7800); 2 Jul 2004 07:07:28 -0000 Date: 2 Jul 2004 07:07:28 -0000 Message-ID: <1088752048.43.31366.m25@yahoogroups.com> From: Yahoo! Groups Reply-To: confirm-s2-6dRWjwu8pX6ZCGQTPDDZbi2dR44-linux-mips=linux-mips.org@yahoogroups.com To: linux-mips@linux-mips.org Subject: Please confirm your request to join movaznaustva MIME-Version: 1.0 Content-Type: text/plain 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: 5393 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: confirm-s2-6dRWjwu8pX6ZCGQTPDDZbi2dR44-linux-mips=linux-mips.org@yahoogroups.com Precedence: bulk X-list: linux-mips Hello linux-mips@linux-mips.org, We have received your request to join the movaznaustva group hosted by Yahoo! Groups, a free, easy-to-use community service. This request will expire in 7 days. TO BECOME A MEMBER OF THE GROUP: 1) Go to the Yahoo! Groups site by clicking on this link: http://groups.yahoo.com/i?i=6dRWjwu8pX6ZCGQTPDDZbi2dR44&e=linux-mips%40linux-mips%2Eorg (If clicking doesn't work, "Cut" and "Paste" the line above into your Web browser's address bar.) -OR- 2) REPLY to this email by clicking "Reply" and then "Send" in your email program If you did not request, or do not want, a membership in the movaznaustva group, please accept our apologies and ignore this message. Regards, Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From macro@linux-mips.org Fri Jul 2 16:09:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jul 2004 16:09:40 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:57826 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 2 Jul 2004 16:09:35 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 7FD6547777; Fri, 2 Jul 2004 17:09:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 6D5994762F; Fri, 2 Jul 2004 17:09:28 +0200 (CEST) Date: Fri, 2 Jul 2004 17:09:28 +0200 (CEST) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Geert Uytterhoeven , Linux/MIPS Development Subject: Re: [patch] Incorrect mapping of serial ports to lines In-Reply-To: <20040629150316.GB23741@linux-mips.org> Message-ID: References: <20040628235908.GC5736@linux-mips.org> <20040629150316.GB23741@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: 5394 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@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 29 Jun 2004, Ralf Baechle wrote: > How about you leave CONFIG_HAVE_STD_PC_SERIAL_PORT disabled for Malta then > and supply your own MALTA_SERIAL_PORT_DEFNS instead then? That would > require some small changes to no longer nest the CONFIG_SERIAL_MANY_PORTS > ifdef inside CONFIG_HAVE_STD_PC_SERIAL_PORT - about as below. I couldn't care less about CONFIG_SERIAL_MANY_PORTS for Malta -- the ports it adds are AFAIK all ISA boards. While in theory one can have a PCI-ISA bridge and a bus extender on an option card (such devices exist, I'm told), I don't think it's possible to use one with Malta as it already includes a PCI-ISA bridge onboard. If there's a need for such stuff in the future, it can be added then. After a brief look at the sources I think the option itself might actually depend on CONFIG_ISA. So I propose the following simpler patch instead. I'd like to have the comment included so that no one tries to "fix" the order in the future without a careful consideration. It works for me. OK to apply? Maciej patch-mips-2.4.26-20040531-mips-serial-2 diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/include/asm-mips/serial.h linux-mips-2.4.26-20040531/include/asm-mips/serial.h --- linux-mips-2.4.26-20040531.macro/include/asm-mips/serial.h 2004-06-13 23:16:56.000000000 +0000 +++ linux-mips-2.4.26-20040531/include/asm-mips/serial.h 2004-07-02 00:40:52.000000000 +0000 @@ -410,14 +410,23 @@ #define DDB5477_SERIAL_PORT_DEFNS #endif +/* + * The order matters here and should be as follows: + * + * 1. board-specific ports (please keep sorted) + * 2. STD_SERIAL_PORT_DEFNS + * 3. EXTRA_SERIAL_PORT_DEFNS + * 4. HUB6_SERIAL_PORT_DFNS + * + * otherwise serial line numbers may change across + * kernel builds if configuration changes. --macro + */ #define SERIAL_PORT_DFNS \ ATLAS_SERIAL_PORT_DEFNS \ AU1000_SERIAL_PORT_DEFNS \ COBALT_SERIAL_PORT_DEFNS \ DDB5477_SERIAL_PORT_DEFNS \ EV96100_SERIAL_PORT_DEFNS \ - EXTRA_SERIAL_PORT_DEFNS \ - HUB6_SERIAL_PORT_DFNS \ ITE_SERIAL_PORT_DEFNS \ IVR_SERIAL_PORT_DEFNS \ JAZZ_SERIAL_PORT_DEFNS \ @@ -426,8 +435,11 @@ MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS \ MOMENCO_JAGUAR_ATX_SERIAL_PORT_DEFNS \ SEAD_SERIAL_PORT_DEFNS \ - STD_SERIAL_PORT_DEFNS \ TITAN_SERIAL_PORT_DEFNS \ - TXX927_SERIAL_PORT_DEFNS + TXX927_SERIAL_PORT_DEFNS \ + \ + STD_SERIAL_PORT_DEFNS \ + EXTRA_SERIAL_PORT_DEFNS \ + HUB6_SERIAL_PORT_DFNS #endif /* _ASM_SERIAL_H */ diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/include/asm-mips64/serial.h linux-mips-2.4.26-20040531/include/asm-mips64/serial.h --- linux-mips-2.4.26-20040531.macro/include/asm-mips64/serial.h 2003-12-18 03:57:25.000000000 +0000 +++ linux-mips-2.4.26-20040531/include/asm-mips64/serial.h 2004-07-02 00:41:05.000000000 +0000 @@ -146,13 +146,23 @@ #define IP27_SERIAL_PORT_DEFNS #endif /* CONFIG_SGI_IP27 */ +/* + * The order matters here and should be as follows: + * + * 1. board-specific ports (please keep sorted) + * 2. STD_SERIAL_PORT_DEFNS + * + * otherwise serial line numbers may change across + * kernel builds if configuration changes. --macro + */ #define SERIAL_PORT_DFNS \ IP27_SERIAL_PORT_DEFNS \ MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS \ MOMENCO_JAGUAR_ATX_SERIAL_PORT_DEFNS \ SEAD_SERIAL_PORT_DEFNS \ - STD_SERIAL_PORT_DEFNS \ - TITAN_SERIAL_PORT_DEFNS + TITAN_SERIAL_PORT_DEFNS \ + \ + STD_SERIAL_PORT_DEFNS #define RS_TABLE_SIZE 64 From no-reply@arXiv.org Sat Jul 3 01:28:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Jul 2004 01:28:36 +0100 (BST) Received: from xxx.arxiv.cornell.edu ([IPv6:::ffff:132.236.180.11]:26303 "EHLO xxx.arxiv.cornell.edu") by linux-mips.org with ESMTP id ; Sat, 3 Jul 2004 01:28:29 +0100 Received: (from e-prints@localhost) by xxx.arxiv.cornell.edu (8.11.6/x.x.x) id i630SOp10111; Fri, 2 Jul 2004 20:28:24 -0400 Date: Fri, 2 Jul 2004 20:28:24 -0400 Message-Id: <200407030028.i630SOp10111@xxx.arxiv.cornell.edu> Precedence: bulk X-Note: e-print arXiv software written by PG at LANL (8/91,...,4/99) X-Supported-By: U.S. National Science Foundation, Agreement 0132355 (7/01-6/04) From: no-reply@arXiv.org (send mail ONLY to cond-mat) Reply-To: cond-mat@arXiv.org To: linux-mips@linux-mips.org Subject: RE: Hello 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: 5395 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: no-reply@arXiv.org Precedence: bulk X-list: linux-mips cond-mat@arXiv.org is a fully automated e-print archive for condensed matter preprints (starting from April, 1992) The list of subject classes within cond-mat is: Disordered Systems and Neural Networks, Materials Science (the mtrl-th archive has been moved into cond-mat), Mesoscopic Systems and Quantum Hall Effect, Soft Condensed Matter, Statistical Mechanics, Strongly Correlated Electrons, Superconductivity (the supr-con archive has been moved into cond-mat) (From Nov, 1994 though September 1996, there were also archives mtrl-th for materials theory, and supr-con for superconductivity.) To communicate with the archive via e-mail, send messages to cond-mat@arXiv.org WorldWideWeb access is available via "http://arXiv.org/" Anonymous ftp access is available via arXiv.org ------------------------------------------------------------------------- ------------------------------------------------------------------------- In the generic arXiv help text, substitute cond-mat@arXiv.org for the generic e-mail address arch-ive@arXiv.org ------------------------------------------------------------------------- ------------------------------------------------------------------------- Outgoing mail from the e-print archive has the username no-reply (to avoid problems due to occasional mail that bounces back). Commands to the system should always be sent to arch-ive@arXiv.org with the command in the subject field (e.g. Subject: help). Only one command at a time is accepted. Subscribers automatically receive a listing of new titles/abstracts on days papers are received. You will have a more pleasurable time using the archives if you read this file carefully, read ALL responses you get to your interactions with the archives, and follow the instructions therein. This help file summarizes the email interface commands. This information can be more easily accessed via the WorldWideWeb at http://arXiv.org/help/ . ========================================================================== Additional help is available by using the `get' command to retrieve the following files: (this file): summary of e-mail commands prep.txt: how to prepare your abstract and paper for submission submit.txt: instructions for submitting to the archive eput.txt: instructions for e-mail submissions, including appraisal of different packaging formats fput.txt: how to use anonymous ftp to put and replace papers utilities.txt: utilities and applications to install for use with the archives, and where to find them for many platforms sizes.txt: how to slim down your PostScript files ========================================================================== Summary of Commands for the e-Mail Interface: All commands to arch-ive@xxx may be abbreviated by any truncation that includes at least the first three letters (e.g. rep, sub, can, dis, lis, com, ...). (The term arch-ive a generic one; substitute an appropriate archive name like hep-th when actually doing something). The command must be given in the subject field (e.g., Subject: help ). Commands for retrieving information (get, cget, uget, list, find, distribution): get Returns paper specified by paper# (e.g. `get 9109001'), or macro specified by macroname. For abstracts alone, append .abs to the paper# (e.g. `get 9109001.abs'). Multiple requests in one `get' are allowed and preferred. For example, `get 3 2.abs 9108001' returns multiple papers and abstracts. get defaults to the current year/month so that during 10/91, `get 1 2 5' or `get 01 2 005' will automatically prepend 9110's and the necessary zeroes to result in `get 9110001 9110002 9110005'. Numbers too large for the current year/month will have the previous year/month prepended. get also defaults to the current year, e.g. `get 9005' during 1995 gives `get 9509005', and months/numbers too big for the current year default to the previous year. You can freely mix formats, as in `get 1 08005 harvmac.tex 9109058 2.abs'. As of 1 Jan 1996, the get command returns a single uuencoded, gzipped, tar archive containing all files in a submission (except in the case of a submission consisting of a single file [e.g. TeX, PS, or PDF], which is instead just gzipped [i.e. not tarred] and uuencoded for e-mail). For utilities to unpack these, read utilities.txt (available via `get utilities.txt'). For those unable to process this new format, there is now the `uget' command. cget Same as the get command, but the file is cut into multiple parts of size < 100 kB (195 blocks) to accommodate certain capricious or limited mail routers and to speed bitnet transmission. uget Same as the get command, but files are unpacked from our storage format (gzipped tar files) and sent out individually. Meant for those unable to adapt to our new (1 Jan 1996) packaging. Users should feel encouraged to modernize to use gzip and tar (see utilities.txt for more info, including cross-platform availability) in order to use the normal get command. listing Returns list of year/month's currently available list Returns title/author's of papers currently held for given year/month subset, e.g. `list 9109'. `list macros' returns a list of the available TeX macros and various utilities such as reform and uufiles. `list new' resends the most recently sent title/abstract listing of papers received (typically from the previous day). `list pastweek' returns past week of title/author listings. For title/author/abstract's of papers held for given yr/mo subsets, append .abs: e.g. `list 9109.abs 9110.abs' multiple requests allowed: e.g. `list 9109 9110.abs macros new pastweek' clist Same as the list command, but files are cut into multiple parts of size < 100 kB (195 blocks) to accommodate certain capricious or limited mail routers and to speed bitnet transmission. find Searches the title/author list for search-string (either author or word in title, case insensitive) to retrieve paper number, e.g. `find goldstone'. Find defaults to the past 12 months, so for earlier years use e.g. `find goldstone 91'. distribution Search for `name' in e-mail distribution list. Commands for submitting information: (put, fput, replace, freplace, figures, add, cross, published) put Submit a paper (body of the message must be in the format described in prep.txt, available via `get prep.txt'). Paper will be assigned a paper number, and added to the listings (do not `put' the same paper to more than one e-print archive, instead use the `cross' command to cross list the paper). Never `put' the same paper twice. Instead use the `replace' command. The preferred format for `put' is TeX/LaTeX source. Please don't submit PostScript generated from TeX. We have an automatic TeX'ing script on-line that will generate PostScript from your TeX source. As of 1 Jan 1996, all submissions are tested for automatic PostScript generation before they can be entered into the archives. See neworder.txt for more info. fput Submit a paper using ftp. First transfer files (filename1 ...) for paper via anonymous ftp to arXiv.org's /incoming ftp directory. Body of `fput' e-mail message is in same format as that of `put' command (i.e. title/author and abstract fields delimited by \\'s), as described in prep.txt, but nothing need follow the final \\ terminating the abstract. It is advisable to read the complete fput help before using (available via `get fput.txt' ). replace Replace a paper specified by paper# with a revised version (only original submitter can do this, from the original e-mail account). The paper should be resubmitted in the same format as for the `put' command. Be sure to include the full abstract, since this is replaced as well, although it won't appear in the daily mailing (unless the `replace' is on the same day as the `put'). The Comments: field (i.e. after Title: and Authors: ) should contain a short comment describing the severity of the changes so that others can determine if it is worth their time to get your paper again. Remember to include your original Comments: as well, because the replacement wipes these out, and the original comments still contain useful information. Any cross-listed entries, e.g. hep-ph/9204201 already cross-listed to hep-th, are automatically replaced, e.g. on hep-th, when you replace hep-ph/9204201 on hep-ph -- additional action is no longer necessary. You must resend all files contained in your submission. You can only replace your entire submission. There is no way to replace only part of it (e.g. a single figure). In addition, replacements are subject to the same test for automatic processing as for puts. As of 1 Jan 1996, the text of the original submission is retained if it is replaced after the first day (i.e, if it has already appeared in a newlistings mailing). This is to prevent excessive backdating of content. (The original submissions are not currently publicly available, but will probably be made so at some later date.) If you are replacing a paper to update the results because of subsequent work by others, we require that you exercise professional courtesy and refer to this work, preferably in the Comments: field. (This avoids sticky priority disputes.) The replace command can be used to withdraw a paper from the archives. You cannot completely remove a paper that has appeared in a mailing; you can only replace it with a statement that it is withdrawn. freplace Submit a replacement using anonymous ftp, where filename1 ... have already been deposited to arXiv.org's /incoming ftp directory. The paper number must be the FIRST argument. The body of an `freplace' message is the same as that for `fput'. Remember to include the full abstract. It is advisable to read the complete `fput/freplace' help before using (available via `get fput.txt'). The caveats for the replace command apply here as well. figures This command is now obsolete (1 Jan '96). All files should be sent in a single package. See eput.txt for more info. add This command is now obsolete (1 Jan '96). If your mailer imposes size limits on outgoing mail, than you must use fput or freplace. cross Cross-list paper from another e-print archive. e.g. a) first put paper To: hep-ph@arXiv.org which assigns it hep-ph/9204201 b) wait until you see your paper listing in the next daily mailing. This is important because paper numbers are not permanent until then. c) then send an e-mail message (with blank message body) To: astro-ph@arXiv.org Subject: cross hep-ph/9204201 so that the hep-ph entry will appear as well on astro-ph. (NOTE: In the above case of a paper originally submitted to hep-ph, obviously do not send the cross-list command To: hep-ph@arXiv.org .) Generates abstract entry for daily listings and for access by `find' and `list' commands. Cross-listed papers must be obtained directly from the archive where the paper was originally submitted (i.e. hep-ph in example above). To cross-list to an archive that allows (or requires) subject classes, include your desired subject class at the end of the cross command, e.g. To: physics@arXiv.org Subject: cross hep-th/9611010 Mathematical Methods in Physics This can also be used to cross-list submissions to different subject classes within an archive, e.g., for a submission originally submitted to the cond-mat archive with Subj-class: Materials Science, To: cond-mat@arXiv.org Subject: cross cond-mat/9611010 Superconductivty will add Superconductivity as a secondary subject class. Note that cross-listings should not be abused and inappropriate crosses will be removed. published Adds a Journal reference to paper's entry, accessible via `find', `list', `list [].abs', `get [].abs' commands; e.g., `published 9107001 Rec. Jnl. 180 (1992) 101'. Journal-ref's should be complete bibliographic references, i.e. they should include the journal name, volume, year, and page number. Anything short of this belongs in the Comments: field. Subscription commands (subscribe, cancel, subscribe all, cancel all): subscribe Add new username to daily distribution list (e-mail address will automatically be extracted from return address), `your full name' is your full name (any number of words and initials) as you wish it to appear on the distribution list. <<>> (It is of course no longer obvious why people subscribe for intrusive e-mail receipt of abstracts when they have www access on-demand from http://arXiv.org/ ). e-Mail addresses that bounce three consecutive times are automatically cancelled. If you do not receive a response to your `subscribe' message, it is most likely because your mailer is misconfigured and the return address in the From: line or Reply-To: line is broken. We have no way of contacting you if this is the case, so you are on your own to figure out what is wrong. cancel Remove user@nodename from daily distribution list. The e-mail address is extracted automatically, so cancel message must be sent from the same account as originally used to subscribe. Note that you may be subscribed instead through a remote listserv, or through some local preprint distribution list at your end. You can determine the origin of your subscription by examining the the header from the daily mailing you receive. If you no longer have access to your original subscription account, the administrators at arXiv.org may be able to cancel it for you. Send request as a comment, and be certain to to include the entire header of a daily abstract mailing that you have received so that we can determine how you are subscribed. (Do not send a useless header from the failed `cancel' or from a `get', etc.) subscribe all Receive daily list of changes to database. The list of changes comes formatted in a form suitable for automated ftp scripts. The password will be added to the Subject: line of the daily message so that automated scripts can be reasonably sure that the messages are authentic. Don't use your account password. If you do not include a password then a random one will automatically be generated for you. cancel all Cancel previously entered `subscribe all' (i.e. in order to no longer receive daily list of changes to database). `cancel all' will not cancel a regular subscription (one that sends you the complete abstracts each day). You must use the `cancel' command for each individual archive to which you are subscribed. Miscellaneous commands (comment, help): comment Forward message for human perusal. If you have any doubts about how to submit something or where it should go, you can use this command to ask questions. They are usually answered on a one day turn around, often sooner. Style files of use to other authors can also be sent in, along with a one-line description of the style. help Returns this file. --------------------------------------------------------------------- Do not make multiple requests for the same paper. If you receive nothing (or if the response is slow) it means there is a problem at your end. Anonymous ftp for getting and retrieving files is enabled on arXiv.org. use login: anonymous password: yourusername The relevant directories are listings and papers (the latter has subdirectories 9108, 9109, ... ). If you are not already familiar with anonymous ftp, this is not a good place to practice. Papers can be put on the archives via anonymous ftp using `fput' and `freplace' (see above, or `get fput.txt' for further info). For european users, many of these databases are mirrored as the equivalent arch-ive@babbage.sissa.it, which allows access both via the above e-mail requests and via anonymous ftp. WorldWideWeb access is available via http://arXiv.org/ and other mirror sites worldwide Some other e-print archives running the same software: Physics hep-th@arXiv.org High Energy Physics - Theory, 8/91 hep-lat@arXiv.org High Energy Physics - Lattice, 2/92 hep-ph@arXiv.org High Energy Physics - Phenomenology, 3/92 astro-ph@arXiv.org Astrophysics, 4/92 cond-mat@arXiv.org Condensed Matter, 4/92 gr-qc@arXiv.org General Relativity and Quantum Cosmology, 7/92 nucl-th@arXiv.org Nuclear Theory, 10/92 chem-ph@arXiv.org Chemical Physics, 3/94 hep-ex@arXiv.org High Energy Physics - Experiment, 4/94 acc-phys@arXiv.org Accelerator Physics, 11/94 mtrl-th@arXiv.org Materials Theory, 11/94 supr-con@arXiv.org Superconductivity, 11/94 nucl-ex@arXiv.org Nuclear Experiment, 12/94 quant-ph@arXiv.org Quantum Physics, 12/94 atom-ph@arXiv.org Atomic, Molecular and Optical Physics, 9/95 plasm-ph@arXiv.org Plasma Physics, 9/95 physics@arXiv.org Physics, 10/96 Mathematics alg-geom@arXiv.org Algebraic Geometry, 2/92 funct-an@arXiv.org Functional Analysis, 4/92 dg-ga@arXiv.org Differential Geometry, 6/94 q-alg@qrXiv.org Quantum Algebra and Topology, 12/94 Other nlin-sys@arXiv.org Nonlinear Sciences, 1/93 cmp-lg@arXiv.org Computation and Language, 4/94 ao-sci@arXiv.org Atmospheric-Oceanic Sciences, 2/95 --------------------------------------------------------------------- Disclaimer: Problems printing a paper should be directed to its authors. Papers will be entered in the listings in order of receipt on an impartial basis and appearance of a paper is not intended in any way to convey tacit approval of its assumptions, methods, or conclusions by any agent (electronic, mechanical, or other). We reserve the right to reject any inappropriate submissions. This e-print archive should not be used to distribute non-technical information (such as news or information about political causes of potential special interest to the academic community). Finally, this is an e-print archive. Submissions of an abstract without a paper will be rejected outright. From anemo@mba.ocn.ne.jp Sat Jul 3 13:39:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Jul 2004 13:39:12 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:9209 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Sat, 3 Jul 2004 13:39:08 +0100 Received: from localhost (p7041-ipad204funabasi.chiba.ocn.ne.jp [222.146.94.41]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 9DA866CA3; Sat, 3 Jul 2004 21:38:59 +0900 (JST) Date: Sat, 03 Jul 2004 21:44:11 +0900 (JST) Message-Id: <20040703.214411.74757075.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: 2.4 pci_dma_sync_sg fix From: Atsushi Nemoto In-Reply-To: <20040701135919.GA6906@linux-mips.org> References: <20040701132240.GA6219@linux-mips.org> <20040701.224535.71082878.anemo@mba.ocn.ne.jp> <20040701135919.GA6906@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 5396 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: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Thu, 1 Jul 2004 15:59:19 +0200, Ralf Baechle said: >> The loop contains paranoid out_of_line_bug, so it never be >> optimized to empty. ralf> Indeed and I think that's a bit of overkill. I've never seen ralf> these assertions catch any bugs - and 2.4 isn't exactly new ralf> anymore. Anyway, even if the loop was empty gcc would not ralf> eleminate it. Then how about this? Index: pci.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/pci.h,v retrieving revision 1.24.2.16 diff -u -r1.24.2.16 pci.h --- pci.h 17 Nov 2003 01:07:45 -0000 1.24.2.16 +++ pci.h 3 Jul 2004 12:30:36 -0000 @@ -281,8 +281,16 @@ /* Make sure that gcc doesn't leave the empty loop body. */ #ifdef CONFIG_NONCOHERENT_IO - for (i = 0; i < nelems; i++, sg++) - dma_cache_wback_inv((unsigned long)sg->address, sg->length); + for (i = 0; i < nelems; i++, sg++) { + if (sg->address) { + dma_cache_wback_inv((unsigned long)sg->address, + sg->length); + } else { + dma_cache_wback_inv((unsigned long) + (page_address(sg->page) + sg->offset), + sg->length); + } + } #endif } From milang@tal.org Sun Jul 4 11:12:43 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jul 2004 11:12:47 +0100 (BST) Received: from gw01.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.115]:39594 "EHLO gw01.mail.saunalahti.fi") by linux-mips.org with ESMTP id ; Sun, 4 Jul 2004 11:12:43 +0100 Received: from fairytale.tal.org (cruel.tal.org [195.16.220.85]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 77C5129F3D for ; Sun, 4 Jul 2004 13:12:41 +0300 (EEST) Received: from amos (unknown [195.16.220.84]) by fairytale.tal.org (Postfix) with SMTP id 1F6098DA4 for ; Sun, 4 Jul 2004 13:15:19 +0300 (EEST) Message-ID: <00b201c461af$fd26dc50$0000fea9@amos> From: "Kaj-Michael Lang" To: "linux-mips" Subject: something like sparc32/setarch for mips? Date: Sun, 4 Jul 2004 13:16:35 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 5397 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: milang@tal.org Precedence: bulk X-list: linux-mips Is there something like sparc32 or setarch for mips ? -- Kaj-Michael Lang , milang@tal.org From yuasa@hh.iij4u.or.jp Sun Jul 4 16:30:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jul 2004 16:30:07 +0100 (BST) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:8956 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Sun, 4 Jul 2004 16:30:02 +0100 Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA19669; Mon, 5 Jul 2004 00:29:58 +0900 (JST) Received: 4UMDO00 id i64FTv024833; Mon, 5 Jul 2004 00:29:58 +0900 (JST) Received: 4UMRO00 id i64FTuT5004528; Mon, 5 Jul 2004 00:29:57 +0900 (JST) from stratos (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Mon, 5 Jul 2004 00:29:56 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH] vr41xx: fixes the compile error in giu.c Message-Id: <20040705002956.20bbcc5c.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-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: 5398 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: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, The following patch fixes the compile error in arch/mips/vr41xx/common/giu.c. Please apply this patch to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c --- linux-orig/arch/mips/vr41xx/common/giu.c Mon Jun 28 11:12:23 2004 +++ linux/arch/mips/vr41xx/common/giu.c Mon Jul 5 00:11:01 2004 @@ -63,6 +63,12 @@ static uint32_t giu_base; +static struct irqaction giu_cascade = { + .handler = no_action, + .mask = CPU_MASK_NONE, + .name = "cascade", +}; + #define read_giuint(offset) readw(giu_base + (offset)) #define write_giuint(val, offset) writew((val), giu_base + (offset)) @@ -303,7 +309,6 @@ }; static struct vr41xx_giuint_cascade giuint_cascade[GIUINT_NR_IRQS]; -static struct irqaction giu_cascade = {no_action, 0, CPU_MASK_NONE, "cascade", NULL, NULL}; static int no_irq_number(int irq) { From yuasa@hh.iij4u.or.jp Sun Jul 4 16:32:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jul 2004 16:32:49 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:17393 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Sun, 4 Jul 2004 16:32:44 +0100 Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA03358; Mon, 5 Jul 2004 00:32:41 +0900 (JST) Received: 4UMDO00 id i64FWf024855; Mon, 5 Jul 2004 00:32:41 +0900 (JST) Received: 4UMRO00 id i64FWeT5004765; Mon, 5 Jul 2004 00:32:40 +0900 (JST) from stratos (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Mon, 5 Jul 2004 00:32:39 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH] vr41xx: fixes the initialization error in icu.c Message-Id: <20040705003239.5433da3e.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-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: 5399 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: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, The following patch fixes the initialization error in arch/mips/vr41xx/common/icu.c. Please apply this patch to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c --- linux-orig/arch/mips/vr41xx/common/icu.c Thu May 27 02:11:11 2004 +++ linux/arch/mips/vr41xx/common/icu.c Mon Jul 5 00:10:57 2004 @@ -51,6 +51,12 @@ static uint32_t icu1_base; static uint32_t icu2_base; +static struct irqaction icu_cascade = { + .handler = no_action, + .mask = CPU_MASK_NONE, + .name = "cascade", +}; + static unsigned char sysint1_assign[16] = { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; static unsigned char sysint2_assign[16] = { @@ -673,8 +679,6 @@ early_initcall(vr41xx_icu_init); /*=======================================================================*/ - -static struct irqaction icu_cascade = {no_action, 0, 0, "cascade", NULL, NULL}; static inline void init_vr41xx_icu_irq(void) { From sshtylyov@dev.rtsoft.ru Mon Jul 5 16:04:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jul 2004 16:04:49 +0100 (BST) Received: from RT-soft-2.Moscow.itn.ru ([IPv6:::ffff:80.240.96.70]:32911 "HELO mail.dev.rtsoft.ru") by linux-mips.org with SMTP id ; Mon, 5 Jul 2004 16:04:44 +0100 Received: (qmail 2493 invoked from network); 5 Jul 2004 14:59:57 -0000 Received: from unknown (HELO dev.rtsoft.ru) (192.168.1.227) by mail.dev.rtsoft.ru with SMTP; 5 Jul 2004 14:59:57 -0000 Message-ID: <40E96E2A.2000403@dev.rtsoft.ru> Date: Mon, 05 Jul 2004 19:05:14 +0400 From: Sergei Shtylyov Organization: RTSoft, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040113 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: linux-mips@ftp.linux-mips.org Subject: LO reg. gets trashed by kgdb in 2.4.x and older kernels 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@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 5400 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: sshtylyov@dev.rtsoft.ru Precedence: bulk X-list: linux-mips Hi. I have discovered that the gdb-low.S trashes the LO reg. instead of restoring it. This was fixed for the 2.6 kernels but, as it seems, was left unfixed in the earlier ones (run into this on 2.4.18/2.4.20). Here's the patch against the lastest 2.4.x revision of the file... Index: linux/arch/mips/kernel/gdb-low.S =================================================================== RCS file: /home/cvs/linux/arch/mips/kernel/gdb-low.S,v retrieving revision 1.11.2.3 diff -a -u -r1.11.2.3 gdb-low.S --- linux/arch/mips/kernel/gdb-low.S 20 Feb 2003 18:19:01 -0000 1.11.2.3 +++ linux/arch/mips/kernel/gdb-low.S 5 Jul 2004 14:48:08 -0000 @@ -283,7 +283,7 @@ lw v0,GDB_FR_HI(sp) lw v1,GDB_FR_LO(sp) mthi v0 - mtlo v0 + mtlo v1 lw ra,GDB_FR_REG31(sp) lw fp,GDB_FR_REG30(sp) lw gp,GDB_FR_REG28(sp) From thomas.kunze@xmail.net Tue Jul 6 09:12:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 09:12:26 +0100 (BST) Received: from mailer.x-mail.net ([IPv6:::ffff:65.110.6.10]:25860 "EHLO mailer.xmail.net") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 09:12:21 +0100 Received: from [217.115.67.74] by www.xmail.net with HTTP for ; Tue, 06 Jul 2004 01:12:20 -0800 Message-ID: <1089101540.40ea5ee467311@www.x-mail.net> Date: Tue, 06 Jul 2004 01:12:20 -0800 From: Thomas Kunze To: linux-mips@linux-mips.org Subject: Linux on SNI RM300E ? X-Mailer: Web XMail 3.2a X-Mail.net: *** Free Web Based E-Mail & Hosting *** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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: 5401 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: thomas.kunze@xmail.net Precedence: bulk X-list: linux-mips Hi, i've tried to install Debian Woody MIPS on my SNI RM300E but i can't get it work. bootp() and tftp() works. the bios load's the tftpboot.img over the net. after that only an exception appears on the screen. the boot screen looks like this: Obtaining /tftpboot/sash_pci from server 2027520+1762928+95120 entry 0x8800246C EXCEPTION: EXCEPTION pc: 0x8800246C Cause register: 0x800C Status register: 0x200010003 Bad Vaddress: 0x3C40 is anybody out there how can help me? with best regards thomas ------------------------------------------------------------------------------------------- ***Protect your PC from local E-Mail Application security holes*** ***Maintain your Privacy - MS Passport Free*** ***Anti SPAM "Whitelist" feature*** http://www.xmail.net Web E-Mail, accessible anywhere, 128 bit SSL Secure Voice Messages, Voice Calls (VoIP), Video Conferencing, XMail Messenger, Personal Web Hosting, Private Disk Storage, Calendar, Bookmarks, Forwarding, Virtual Mail Map Aliasing XMail Premium: 20 - 250MB Storage, 20MB Messages, SMTP, POP3, Ad Free Starting at $9.95 per year ------------------------------------------------------------------------------------------- Anonymous Web Surfing http://www.snoopblocker.com Search http://www.teradex.com From thomas.kunze@xmail.net Tue Jul 6 10:14:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 10:14:27 +0100 (BST) Received: from mailer.x-mail.net ([IPv6:::ffff:65.110.6.10]:14861 "EHLO mailer.xmail.net") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 10:14:22 +0100 Received: from [217.115.67.74] by www.xmail.net with HTTP for ; Tue, 06 Jul 2004 02:14:20 -0800 Message-ID: <1089105260.40ea6d6cf2f9c@www.x-mail.net> Date: Tue, 06 Jul 2004 02:14:20 -0800 From: Thomas Kunze To: a.voropay@vmb-service.ru Cc: linux-mips@linux-mips.org Subject: RE: Linux on SNI RM300E ? References: <038c01c46334$38621de0$0200000a@ALEC> In-Reply-To: <038c01c46334$38621de0$0200000a@ALEC> X-Mailer: Web XMail 3.2a X-Mail.net: *** Free Web Based E-Mail & Hosting *** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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: 5402 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: thomas.kunze@xmail.net Precedence: bulk X-list: linux-mips Quoting Alexander Voropay : > AFAIK, the RM300E is an ARC compatible. (?) i don't no. i saw something like that on the net. but nothing about that in the manuals that i have. > > So, try to load "arcdiag" utility instead of kernel : > > ftp://ftp.sra.co.jp/pub/os/NetBSD/misc/arc/ > i've downloaded the arcdiag-0.2 and served it via tftp. but the RM300E don't like that file. it only says "Bad magic number". what does this mean (little/bigendian)? the same error-message appears when the to load mipsel boot-images. with best regards thomas ------------------------------------------------------------------------------------------- ***Protect your PC from local E-Mail Application security holes*** ***Maintain your Privacy - MS Passport Free*** ***Anti SPAM "Whitelist" feature*** http://www.xmail.net Web E-Mail, accessible anywhere, 128 bit SSL Secure Voice Messages, Voice Calls (VoIP), Video Conferencing, XMail Messenger, Personal Web Hosting, Private Disk Storage, Calendar, Bookmarks, Forwarding, Virtual Mail Map Aliasing XMail Premium: 20 - 250MB Storage, 20MB Messages, SMTP, POP3, Ad Free Starting at $9.95 per year ------------------------------------------------------------------------------------------- Anonymous Web Surfing http://www.snoopblocker.com Search http://www.teradex.com From ica2_ts@csv.ica.uni-stuttgart.de Tue Jul 6 11:06:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 11:06:58 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:29199 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 11:06:52 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1Bhmqe-0004Ok-00; Tue, 06 Jul 2004 12:06:48 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1Bhmqd-0003DQ-00; Tue, 06 Jul 2004 12:06:47 +0200 Date: Tue, 6 Jul 2004 12:06:47 +0200 To: Thomas Kunze Cc: a.voropay@vmb-service.ru, linux-mips@linux-mips.org Subject: Re: Linux on SNI RM300E ? Message-ID: <20040706100647.GB21982@rembrandt.csv.ica.uni-stuttgart.de> References: <038c01c46334$38621de0$0200000a@ALEC> <1089105260.40ea6d6cf2f9c@www.x-mail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089105260.40ea6d6cf2f9c@www.x-mail.net> User-Agent: Mutt/1.5.6i 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: 5403 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 Thomas Kunze wrote: > Quoting Alexander Voropay : > > > AFAIK, the RM300E is an ARC compatible. (?) > i don't no. i saw something like that on the net. but nothing about that in the manuals > that i have. It is, AFAIK. But the woody kernel is for a SGI Indy/Indigo2, not for RM300E. The linux-mips.org tree has only support for RM200C, adding support for RM300E is probably not that complicated if it is similiar enough. > > So, try to load "arcdiag" utility instead of kernel : > > > > ftp://ftp.sra.co.jp/pub/os/NetBSD/misc/arc/ > > > i've downloaded the arcdiag-0.2 and served it via tftp. but the RM300E don't like that > file. it only says "Bad magic number". what does this mean (little/bigendian)? Wrong endianness. Your machine apparently has big endian firmware. Thiemo From a.voropay@vmb-service.ru Tue Jul 6 11:17:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 11:17:27 +0100 (BST) Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:42664 "EHLO smtp.vmb-service.ru") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 11:17:22 +0100 Received: from office.vmb-service.ru ([80.73.192.47]:4107 "EHLO ALEC") by Altair with ESMTP id ; Tue, 6 Jul 2004 14:17:09 +0400 Reply-To: From: "Alexander Voropay" To: "'Thomas Kunze'" Cc: Subject: RE: Linux on SNI RM300E ? Date: Tue, 6 Jul 2004 14:18:01 +0400 Organization: VMB-Service Message-ID: <03a001c46342$84ce7210$0200000a@ALEC> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <1089105260.40ea6d6cf2f9c@www.x-mail.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: 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: 5404 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: a.voropay@vmb-service.ru Precedence: bulk X-list: linux-mips >i've downloaded the arcdiag-0.2 and served it via tftp. but the RM300E don't like that file. >it only says "Bad magic number". what does this mean (little/bigendian)? >the same error-message appears when the to load mipsel boot-images. Do you have an originas OS (SINIX ?) supplied with this server ? Try a `file` GNU utility: $ file or $ file Some modern loaders requires ELF binaries (not COFF) so you should know a full binary file format to load (ELF/COFF/little/bigendian). -- -=AV=- From thomas.kunze@xmail.net Tue Jul 6 11:41:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 11:41:23 +0100 (BST) Received: from mailer.x-mail.net ([IPv6:::ffff:65.110.6.10]:3849 "EHLO mailer.xmail.net") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 11:41:19 +0100 Received: from [217.115.67.73] by www.xmail.net with HTTP for ; Tue, 06 Jul 2004 03:41:17 -0800 Message-ID: <1089110477.40ea81cd8e976@www.x-mail.net> Date: Tue, 06 Jul 2004 03:41:17 -0800 From: Thomas Kunze To: a.voropay@vmb-service.ru Cc: linux-mips@linux-mips.org Subject: RE: Linux on SNI RM300E ? References: <03a001c46342$84ce7210$0200000a@ALEC> In-Reply-To: <03a001c46342$84ce7210$0200000a@ALEC> X-Mailer: Web XMail 3.2a X-Mail.net: *** Free Web Based E-Mail & Hosting *** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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: 5405 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: thomas.kunze@xmail.net Precedence: bulk X-list: linux-mips > Do you have an originas OS (SINIX ?) supplied with this server ? > Try a `file` GNU utility: > $ file > or > $ file > > Some modern loaders requires ELF binaries (not COFF) so you should > know a full binary file format to load (ELF/COFF/little/bigendian). yepp, sinix reliant 5.44 is installed and boots up. BUT, i have no login no password. and the previous owner can't remember any login or password. also, i don't have any orig. CD's for the RM300E. it seems that the machine is running in bigendian mode. with best regards thomas ------------------------------------------------------------------------------------------- ***Protect your PC from local E-Mail Application security holes*** ***Maintain your Privacy - MS Passport Free*** ***Anti SPAM "Whitelist" feature*** http://www.xmail.net Web E-Mail, accessible anywhere, 128 bit SSL Secure Voice Messages, Voice Calls (VoIP), Video Conferencing, XMail Messenger, Personal Web Hosting, Private Disk Storage, Calendar, Bookmarks, Forwarding, Virtual Mail Map Aliasing XMail Premium: 20 - 250MB Storage, 20MB Messages, SMTP, POP3, Ad Free Starting at $9.95 per year ------------------------------------------------------------------------------------------- Anonymous Web Surfing http://www.snoopblocker.com Search http://www.teradex.com From jbglaw@dvmwest.gt.owl.de Tue Jul 6 11:45:54 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 11:45:58 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:12221 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 11:45:54 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id C88D74B7A9; Tue, 6 Jul 2004 12:45:52 +0200 (CEST) Date: Tue, 6 Jul 2004 12:45:52 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: Linux on SNI RM300E ? Message-ID: <20040706104552.GX18841@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <03a001c46342$84ce7210$0200000a@ALEC> <1089110477.40ea81cd8e976@www.x-mail.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vJ/whQCgo58Oj3Wa" Content-Disposition: inline In-Reply-To: <1089110477.40ea81cd8e976@www.x-mail.net> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6i 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: 5406 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --vJ/whQCgo58Oj3Wa Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2004-07-06 03:41:17 -0800, Thomas Kunze wrote in message <1089110477.40ea81cd8e976@www.x-mail.net>: > > Do you have an originas OS (SINIX ?) supplied with this server ? > > Try a `file` GNU utility: > > $ file > > or > > $ file > >=20 > > Some modern loaders requires ELF binaries (not COFF) so you should > > know a full binary file format to load (ELF/COFF/little/bigendian). >=20 > yepp, sinix reliant 5.44 is installed and boots up. BUT, i have no login = no password. > and the previous owner can't remember any login or password. also, i don'= t have any > orig. CD's for the RM300E. it seems that the machine is running in bigend= ian mode. I don't know what filesystem Sinix used, maybe you can rip off the disks and attach them to any other Linux box. Possibly you can mount the filesystem(s), but even if not, you can use a hex editor to zero out root's password on the raw disk :-) MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --vJ/whQCgo58Oj3Wa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6oLgHb1edYOZ4bsRAo+lAJ9jG7niGvjY6i72pfihNvqiL9KpVACgi/58 XBXLh5qY5LKmpetNZviaj9k= =8YMb -----END PGP SIGNATURE----- --vJ/whQCgo58Oj3Wa-- From thomas.kunze@xmail.net Tue Jul 6 11:48:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 11:48:13 +0100 (BST) Received: from mailer.x-mail.net ([IPv6:::ffff:65.110.6.10]:36620 "EHLO mailer.xmail.net") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 11:48:09 +0100 Received: from [217.115.67.74] by www.xmail.net with HTTP for ; Tue, 06 Jul 2004 03:48:07 -0800 Message-ID: <1089110887.40ea8367df720@www.x-mail.net> Date: Tue, 06 Jul 2004 03:48:07 -0800 From: Thomas Kunze To: "Thiemo Seufer" Cc: linux-mips@linux-mips.org Subject: Re: Linux on SNI RM300E ? References: <038c01c46334$38621de0$0200000a@ALEC> <1089105260.40ea6d6cf2f9c@www.x-mail.net> <20040706100647.GB21982@rembrandt.csv.ica.uni-stuttgart.de> In-Reply-To: <20040706100647.GB21982@rembrandt.csv.ica.uni-stuttgart.de> X-Mailer: Web XMail 3.2a X-Mail.net: *** Free Web Based E-Mail & Hosting *** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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: 5407 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: thomas.kunze@xmail.net Precedence: bulk X-list: linux-mips Quoting Thiemo Seufer : > It is, AFAIK. But the woody kernel is for a SGI Indy/Indigo2, not for > RM300E. The linux-mips.org tree has only support for RM200C, adding > support for RM300E is probably not that complicated if it is similiar > enough. OK. what are the next steps to get a bigendian bootimage for the RM300E? are there any sources available to compile for the RM300? is there a bootimage for the RM200C that i can give a try? with best regards thomas ------------------------------------------------------------------------------------------- ***Protect your PC from local E-Mail Application security holes*** ***Maintain your Privacy - MS Passport Free*** ***Anti SPAM "Whitelist" feature*** http://www.xmail.net Web E-Mail, accessible anywhere, 128 bit SSL Secure Voice Messages, Voice Calls (VoIP), Video Conferencing, XMail Messenger, Personal Web Hosting, Private Disk Storage, Calendar, Bookmarks, Forwarding, Virtual Mail Map Aliasing XMail Premium: 20 - 250MB Storage, 20MB Messages, SMTP, POP3, Ad Free Starting at $9.95 per year ------------------------------------------------------------------------------------------- Anonymous Web Surfing http://www.snoopblocker.com Search http://www.teradex.com From ica2_ts@csv.ica.uni-stuttgart.de Tue Jul 6 12:41:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 12:41:09 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:55057 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 12:41:05 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1BhoJr-0005EP-00; Tue, 06 Jul 2004 13:41:03 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1BhoJq-0003QU-00; Tue, 06 Jul 2004 13:41:02 +0200 Date: Tue, 6 Jul 2004 13:41:02 +0200 To: Thomas Kunze Cc: linux-mips@linux-mips.org Subject: Re: Linux on SNI RM300E ? Message-ID: <20040706114102.GC21982@rembrandt.csv.ica.uni-stuttgart.de> References: <038c01c46334$38621de0$0200000a@ALEC> <1089105260.40ea6d6cf2f9c@www.x-mail.net> <20040706100647.GB21982@rembrandt.csv.ica.uni-stuttgart.de> <1089110887.40ea8367df720@www.x-mail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089110887.40ea8367df720@www.x-mail.net> User-Agent: Mutt/1.5.6i 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: 5408 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 Thomas Kunze wrote: > Quoting Thiemo Seufer : > > > It is, AFAIK. But the woody kernel is for a SGI Indy/Indigo2, not for > > RM300E. The linux-mips.org tree has only support for RM200C, adding > > support for RM300E is probably not that complicated if it is similiar > > enough. > > OK. what are the next steps to get a bigendian bootimage for the RM300E? > are there any sources available to compile for the RM300? > is there a bootimage for the RM200C that i can give a try? I would try current CVS HEAD, compile the RM200C configuration and see where it dies. No need to bother about a complete boot image at this stage. Welcome to the world of kernel porting. :-) (You need a kernel converted to ECOFF for this, like it is done for some other machines via elf2ecoff.) Thiemo From thomas.kunze@xmail.net Tue Jul 6 15:11:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 15:11:59 +0100 (BST) Received: from mailer.x-mail.net ([IPv6:::ffff:65.110.6.10]:64524 "EHLO mailer.xmail.net") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 15:11:55 +0100 Received: from [217.115.67.73] by www.xmail.net with HTTP for ; Tue, 06 Jul 2004 07:11:53 -0800 Message-ID: <1089123113.40eab32979315@www.x-mail.net> Date: Tue, 06 Jul 2004 07:11:53 -0800 From: Thomas Kunze To: linux-mips@linux-mips.org Subject: bootimage for RM300E ? References: <03b101c46351$96679c90$0200000a@ALEC> In-Reply-To: <03b101c46351$96679c90$0200000a@ALEC> X-Mailer: Web XMail 3.2a X-Mail.net: *** Free Web Based E-Mail & Hosting *** MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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: 5409 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: thomas.kunze@xmail.net Precedence: bulk X-list: linux-mips Quoting Alexander Voropay : > > >OK. what are the next steps to get a bigendian bootimage for the > RM300E? > >are there any sources available to compile for the RM300? > >is there a bootimage for the RM200C that i can give a try? > > 1) Install a bigendian toolchain at the x86 host box and recompile the > Linux kernel. > P.5 http://howto.linux-mips.org/mips-howto.html ok i downloaded toolchain. which kernel should i use? that one from kernel.org or from linux-mips.org ? what should be done next, after create a kernel ? what do i need to create a bootimage for the RM300 ? how must this bootimage looks like ? any howto's ? with best regards thomas ------------------------------------------------------------------------------------------- ***Protect your PC from local E-Mail Application security holes*** ***Maintain your Privacy - MS Passport Free*** ***Anti SPAM "Whitelist" feature*** http://www.xmail.net Web E-Mail, accessible anywhere, 128 bit SSL Secure Voice Messages, Voice Calls (VoIP), Video Conferencing, XMail Messenger, Personal Web Hosting, Private Disk Storage, Calendar, Bookmarks, Forwarding, Virtual Mail Map Aliasing XMail Premium: 20 - 250MB Storage, 20MB Messages, SMTP, POP3, Ad Free Starting at $9.95 per year ------------------------------------------------------------------------------------------- Anonymous Web Surfing http://www.snoopblocker.com Search http://www.teradex.com From jbglaw@dvmwest.gt.owl.de Tue Jul 6 16:16:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 16:16:15 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:12992 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 16:16:09 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 5B5D04B7A6; Tue, 6 Jul 2004 17:16:07 +0200 (CEST) Date: Tue, 6 Jul 2004 17:16:07 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: bootimage for RM300E ? Message-ID: <20040706151607.GH18841@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <03b101c46351$96679c90$0200000a@ALEC> <1089123113.40eab32979315@www.x-mail.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HywGgDAwzDJj9z7S" Content-Disposition: inline In-Reply-To: <1089123113.40eab32979315@www.x-mail.net> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6i 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: 5410 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --HywGgDAwzDJj9z7S Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2004-07-06 07:11:53 -0800, Thomas Kunze wrote in message <1089123113.40eab32979315@www.x-mail.net>: > Quoting Alexander Voropay : > > 1) Install a bigendian toolchain at the x86 host box and recompile the > > Linux kernel. > > P.5 http://howto.linux-mips.org/mips-howto.html >=20 > ok i downloaded toolchain.=20 > which kernel should i use? that one from kernel.org or from linux-mips.or= g ? linux-mips.org, current CVS checkout. However, I can't tell you if you're better off using HEAD or the linux_2_4 branch (probably HEAD, though...). > what should be done next, after create a kernel ?=20 > what do i need to create a bootimage for the RM300 ? > how must this bootimage looks like ? > any howto's ? Try to feed the kernel image either as ELF or ECOFF via network. The first step is to make the machine actually *accept* the image (let alone properly executing it). MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --HywGgDAwzDJj9z7S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6sI2Hb1edYOZ4bsRAnBjAJ4iskogMpzzJwom4cJK17EjYPQP+ACfaGUS h4vo1ntdtoPVim4VHUusgqE= =0H9n -----END PGP SIGNATURE----- --HywGgDAwzDJj9z7S-- From ralf@linux-mips.org Tue Jul 6 20:35:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 20:35:21 +0100 (BST) Received: from p508B5E19.dip.t-dialin.net ([IPv6:::ffff:80.139.94.25]:19303 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 20:35:17 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i66JZF3d010806; Tue, 6 Jul 2004 21:35:15 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i66JZAjO010805; Tue, 6 Jul 2004 21:35:10 +0200 Date: Tue, 6 Jul 2004 21:35:10 +0200 From: Ralf Baechle To: Thomas Kunze Cc: linux-mips@linux-mips.org Subject: Re: Linux on SNI RM300E ? Message-ID: <20040706193510.GA10125@linux-mips.org> References: <1089101540.40ea5ee467311@www.x-mail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089101540.40ea5ee467311@www.x-mail.net> User-Agent: Mutt/1.4.1i 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: 5411 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 Tue, Jul 06, 2004 at 01:12:20AM -0800, Thomas Kunze wrote: > i've tried to install Debian Woody MIPS on my SNI RM300E but i can't get > it work. I support the RM200C in the little endian configuration and I'm probably the only user of Linux on an RM machine at all. Afaik no little endian systems have been shipped since SNI and Microsoft axed NT for MIPS making my configuration extremly rare and I've not been able to obtain the big endian firmware for the system - which is showing signs of upcoming hardware death so whenever that happens I won't be able to support the SNI [1] code anymore. Just to make life a little bit more misserable I only have hardware documentation on the RM200/300 C (possibly D, would have to check) series so I have not idea to what degree the architecture differs the RM300. Conversion of the existing code to work on a big endian RM200/300C would be easy to do though and I can help whoever wants to try ... Ralf [1] RM hardware dumped in front of my door accepted ;-) From ralf@linux-mips.org Tue Jul 6 20:38:49 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jul 2004 20:38:53 +0100 (BST) Received: from p508B5E19.dip.t-dialin.net ([IPv6:::ffff:80.139.94.25]:22631 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 6 Jul 2004 20:38:49 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i66Jcmkm010884; Tue, 6 Jul 2004 21:38:48 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i66Jcm26010883; Tue, 6 Jul 2004 21:38:48 +0200 Date: Tue, 6 Jul 2004 21:38:48 +0200 From: Ralf Baechle To: Thomas Kunze Cc: linux-mips@linux-mips.org Subject: Re: bootimage for RM300E ? Message-ID: <20040706193848.GB10125@linux-mips.org> References: <03b101c46351$96679c90$0200000a@ALEC> <1089123113.40eab32979315@www.x-mail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089123113.40eab32979315@www.x-mail.net> User-Agent: Mutt/1.4.1i 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: 5412 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 Tue, Jul 06, 2004 at 07:11:53AM -0800, Thomas Kunze wrote: > ok i downloaded toolchain. > which kernel should i use? that one from kernel.org or from linux-mips.org ? Wipe the word kernel.org from your brain ;-) > what should be done next, after create a kernel ? > what do i need to create a bootimage for the RM300 ? > how must this bootimage looks like ? Just "make rm200_defconfig; make" which will build vmlinux.ecoff which is the file which can be netbooted via bootp/tftp. Same procedure as with SGI machines basically so the usual howtos for SGI IP22 netbooting Linux apply. > any howto's ? In the back of my brain. Ralf From wsonguci@yahoo.com Wed Jul 7 00:00:59 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jul 2004 00:01:07 +0100 (BST) Received: from web40006.mail.yahoo.com ([IPv6:::ffff:66.218.78.24]:49590 "HELO web40006.mail.yahoo.com") by linux-mips.org with SMTP id ; Wed, 7 Jul 2004 00:00:59 +0100 Message-ID: <20040706230050.53313.qmail@web40006.mail.yahoo.com> Received: from [63.87.1.243] by web40006.mail.yahoo.com via HTTP; Tue, 06 Jul 2004 16:00:50 PDT Date: Tue, 6 Jul 2004 16:00:50 -0700 (PDT) From: Song Wang Subject: kbuild support to build one module with multiple separate components? 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: 5413 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: wsonguci@yahoo.com Precedence: bulk X-list: linux-mips Hi, Folks I'm puzzled by the kbuild system in 2.6 kernel. I want to write a kernel module, which consists of several components. The module is produced by linking these components. These components are located in separate subdirectories (for example A, B,C). Each component is generated also by linking multiple files. (For example, a_1.c, a_2.c for building A.o, b_1.c, b_2.c for building B.o, then A.o and B.o should be linked to produce mymodule.o) I know if I put all the files in a single directory The makefile of the module looks like obj-$(CONFIG_MYMODULE) += mymodule.o mymodule-objs := a_1.o a_2.o b_1.o b_2.o c_1.o c_2.o It should work. But it is really messy, especially there are a lot of files or each component requires different EXTRA_CFLAGS. However, if I write separate Makefiles for each component in their own subdirectory, the Makefile of component A looks like obj-y := A.o (or obj-$(CONFIG_MYMODULE) += A.o) A-objs := a_1.o a_2.o And the Makefile of mymodule looks like obj-$(CONFIG_MYMODULE) += A/ This is wrong, because kbuild will treat A as independent module. All I want is to treat A as component of the only module mymodule.o. It should be linked to mymodule.o Any idea on how to write a kbuild Makefile to support such kind of single module produced by linking multiple components and each component is located in separate directory? Thanks. -Song __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From macindiard@vsnl.net Wed Jul 7 04:22:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jul 2004 04:22:22 +0100 (BST) Received: from PPP-219-65-135-21.bng.vsnl.net.in ([IPv6:::ffff:219.65.135.21]:12812 "EHLO mac.com") by linux-mips.org with ESMTP id ; Wed, 7 Jul 2004 04:22:17 +0100 Received: from eng32 [192.168.48.96] by mac.com [192.168.48.242] with SMTP (MDaemon.v3.0.0.R) for ; Wed, 07 Jul 2004 08:51:43 +0530 Message-ID: <000d01c463d1$994e59a0$6030a8c0@eng32> From: "hemanth" To: Subject: querries on cross compiler Date: Wed, 7 Jul 2004 08:52:14 +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 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-MDaemon-Deliver-To: linux-mips@linux-mips.org X-Return-Path: hemanth@mac.com X-MDRcpt-To: linux-mips@linux-mips.org X-MDRemoteIP: 192.168.48.96 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: 5414 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: macindiard@vsnl.net Precedence: bulk X-list: linux-mips Hi, Iam trying to build a cross compiler for MIPS processor on "i686-pc-linux-gcc" host. Iam getting some errors during the installation of BINUTILS(binutils-2.9.1) i.e, after configure, when I type "make" Iam getting errors. Can u please suggest how to remove these errors. These are the errors, root@localhost binutils-2.9.1]# make make[1]: Entering directory `/root/cross_compiler/binutils-2.9.1/libiberty' if [ -n "" ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir echo "# !Automatically generated from ./functions.def"\ "- DO NOT EDIT!" >needed2.awk grep '^DEFVAR(' < ./functions.def \ | sed -e '/DEFVAR/s|DEFVAR.\([^,]*\).*|/\1/ { printf "#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|' \ >>needed2.awk grep '^DEFFUNC(' < ./functions.def \ | sed -e '/DEFFUNC/s|DEFFUNC.\([^,]*\).*|/\1/ { printf "#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|' \ >>needed2.awk gcc -c -g -O2 -I. -I./../include ./dummy.c 2>/dev/null make[1]: *** [dummy.o] Error 1 make[1]: Leaving directory `/root/cross_compiler/binutils-2.9.1/libiberty' make: *** [all-libiberty] Error 2 regards, Hemanth MACIL Electronics city Bangalore From kumba@gentoo.org Wed Jul 7 10:09:54 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jul 2004 10:09:59 +0100 (BST) Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:38607 "EHLO sccrmhc12.comcast.net") by linux-mips.org with ESMTP id ; Wed, 7 Jul 2004 10:09:54 +0100 Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58]) by comcast.net (sccrmhc12) with ESMTP id <2004070709094701200t9307e> (Authid: kumba12345); Wed, 7 Jul 2004 09:09:47 +0000 Message-ID: <40EBBE66.2000605@gentoo.org> Date: Wed, 07 Jul 2004 05:12:06 -0400 From: Kumba Reply-To: kumba@gentoo.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: 2.6.7 + gcc-3.4.1 = bada boom Content-Type: multipart/mixed; boundary="------------060201020207080706050901" 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: 5415 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: kumba@gentoo.org Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------060201020207080706050901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Gave a shot at building a 2.6.7-bk13 kernel checkout (20040707) for SGI O2 w/ gcc-3.4.1. Didn't get very far... First was the old "accum" issue visited back in April[1]. Maciej posted a patch to 2.4, which I used to generate a similar patch for 2.6. arch/mips/kernel/time.c needed the same four removals of accum as the 2.4 patch did, but there was one instance of "accum" in arch/mips/kernel/cpu-bugs64.c (which seems to be the one accum Maciej's 2.4 patch removed from cpu-probe.c). The attached patch removes these as per the discussion in April. Following that, the build, while filled with a gazillion warnings about passing different var types to functions, built fine. The resulting kernel even booted -- a little. The second attached file has the Oops, which happens right after "Checking for the daddiu bug... no.". Ideas on this, anyone? I haven't tried this on a raq2/mipsel yet, but I can if needed --Kumba [1]: http://www.linux-mips.org/archives/linux-mips/2004-04/msg00049.html -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond --------------060201020207080706050901 Content-Type: text/plain; name="sgi-o2-2607bk13-gcc341-b00m.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sgi-o2-2607bk13-gcc341-b00m.txt" System Maintenance Menu 1) Start System 2) Install System Software 3) Run Diagnostics 4) Recover System 5) Enter Command Monitor Option? 5 Command Monitor. Type "exit" to return to the menu. > > > bootp(): root=/dev/sda3 console=ttyS0,38400 Setting $netaddr to 192.168.1.12 (from server ) Obtaining from server 5034117+171179 entry: 0xffffffff8046f020 Linux version 2.6.7-mipscvs-20040707 (root@khazad-dum) (gcc version 3.4.1 (Gentoo Linux 3.4.1, ssp-3.4-2, pie-8.7.6.3)) #2 Wed Jul 7 04 :18:31 EDT 2004 ARCH: SGI-IP32 PROMLIB: ARC firmware Version 1 Revision 10 CPU revision is: 00002321 FPU revision is: 00002310 CRIME id a rev 1 at 0x0000000014000000 Determined physical RAM map: memory: 0000000000002000 @ 0000000000000000 (reserved) memory: 0000000000002000 @ 0000000000002000 (usable) memory: 00000000004f7000 @ 0000000000004000 (reserved) memory: 0000000000855000 @ 00000000004fb000 (usable) memory: 00000000002b0000 @ 0000000000d50000 (ROM data) memory: 0000000000100000 @ 0000000001000000 (reserved) memory: 0000000000300000 @ 0000000001100000 (ROM data) memory: 000000000ac00000 @ 0000000001400000 (usable) On node 0 totalpages: 49152 DMA zone: 49152 pages, LIFO batch:12 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: root=/dev/sda3 console=ttyS0,38400 root=/dev/sda3 console=ttyS0,38400 Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes. Primary data cache 32kB 2-way, linesize 32 bytes. R5000 SCACHE size 1024kB, linesize 32 bytes. PID hash table entries: 1024 (order 10: 16384 bytes) Calibrating system timer... 200 MHz CPU detected Using 100.250 MHz high precision timer. Console: colour dummy device 80x25 CRIME memory error at 0x3fffffe0 ST 0x0400a828 Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Memory: 181248k/184668k available (3279k kernel code, 3164k reserved, 1241k data, 396k init, 0k highmem) Calibrating delay loop... 199.68 BogoMIPS Mount-cache hash table entries: 256 (order: 0, 4096 bytes) Checking for 'wait' instruction... available. Checking for the multiply/shift bug... no. Checking for the daddi bug... no. Checking for the daddiu bug... no. CPU 0 Unable to handle kernel paging request at virtual address 0000000000000028, epc == ffffffff80088290, ra == ffffffff80088298 Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]: Cpu 0 $ 0 : 0000000000000000 0000000000000018 0000000000000000 ffffffff80398000 $ 4 : ffffffff81715d60 0000000000000000 0000000000000000 000000000000000d $ 8 : ffffffff8bfd0068 ffffffffffffffff ffffffff8bfd0010 000000000000ffff $12 : 0000000000000030 ffffffff8020bc44 ffffffff8bfd2e40 ffffffffffffffff $16 : 0000000000000000 ffffffffffffffe9 ffffffff81715e60 ffffffff81715d60 $20 : ffffffffa13fb98c ffffffff81072430 ffffffff81054100 0000000000000000 $24 : 0000000000000001 0000000000000020 $28 : ffffffff8038c000 ffffffff8038fd80 0000000000000001 ffffffff80088298 Hi : 0000000000000000 Lo : 0000000000000e00 epc : ffffffff80088290 pgd_current+0xfffffffeffb8d568/0xfffffffeffe3d050 Not tainted ra : ffffffff80088298 pgd_current+0xfffffffeffb8d570/0xfffffffeffe3d050 Status: 9401fce3 KX SX UX KERNEL EXL IE Cause : 80000008 BadVA : 0000000000000028 PrId : 00002321 Process swapper (pid: 0, threadinfo=ffffffff8038c000, task=ffffffff80398000) Stack : 0000000000000004 0000000000000000 ffffffff803b97c0 0000000000000004 0000000000000800 000000000000003c 000000000000003e 0000000000000004 ffffffff8038fe20 0000000000000000 0000000000000000 ffffffff80004470 0000000000800b00 ffffffffa13fb028 ffffffffa13fb98c ffffffff81072430 ffffffff81054100 0000000000000000 0000000000000001 ffffffff8000c7f8 000000000000003c ffffffff8003a928 ffffffff800102f8 ffffffffa13fb028 0000000000000000 ffffffff81072430 00000000000013bf 0000000000000001 0000000000800b00 0000000000000000 ffffffff8038ff70 dfffffffffffffff ffffffff804d3f50 0000000000000804 0000000000000001 0000000000000100 0000000000000000 ffffffff804ef1a8 0000000000000000 0000000000000800 ... Call Trace: [] pgd_current+0xfffffffeffb09748/0xfffffffeffe3d050 [] pgd_current+0xfffffffeffb11ad0/0xfffffffeffe3d050 [] pgd_current+0xfffffffeffb3fc00/0xfffffffeffe3d050 [] pgd_current+0xfffffffeffb155d0/0xfffffffeffe3d050 [] pgd_current+0xfffffffeffb09748/0xfffffffeffe3d050 [] pgd_current+0xfffffffeffb096f4/0xfffffffeffe3d050 [] pgd_current+0xfffffffeffb0fd58/0xfffffffeffe3d050 [] pgd_current+0xfffffffeffb096f4/0xfffffffeffe3d050 [] pgd_current+0xfffffffefff74bac/0xfffffffefff932b8 [] pgd_current+0xfffffffefff74ba4/0xfffffffefff932b8 [] pgd_current+0xfffffffefff74378/0xfffffffefff932b8 Code: 0040982d 3c02804e dc4251d0 <0c0255e6> dc440028 10400098 0040802d 0c02205a 0040202d Kernel panic: Attempted to kill the idle task! In idle task - not syncing --------------060201020207080706050901 Content-Type: text/plain; name="mipscvs-2.6.7-remove-accum.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mipscvs-2.6.7-remove-accum.patch" --- arch/mips/kernel/time.c.orig 2004-07-07 03:56:59.819260432 -0400 +++ arch/mips/kernel/time.c 2004-07-07 03:58:16.645581056 -0400 @@ -278,7 +278,7 @@ static unsigned long fixed_rate_gettimeo __asm__("multu %1,%2" : "=h" (res) : "r" (count), "r" (sll32_usecs_per_cycle) - : "lo", "accum"); + : "lo"); /* * Due to possible jiffies inconsistencies, we need to check @@ -333,7 +333,7 @@ static unsigned long calibrate_div32_get __asm__("multu %1,%2" : "=h" (res) : "r" (count), "r" (quotient) - : "lo", "accum"); + : "lo"); /* * Due to possible jiffies inconsistencies, we need to check @@ -375,7 +375,7 @@ static unsigned long calibrate_div64_get : "r" (timerhi), "m" (timerlo), "r" (tmp), "r" (USECS_PER_JIFFY), "r" (USECS_PER_JIFFY_FRAC) - : "hi", "lo", "accum"); + : "hi", "lo"); cached_quotient = quotient; } } @@ -389,7 +389,7 @@ static unsigned long calibrate_div64_get __asm__("multu %1,%2" : "=h" (res) : "r" (count), "r" (quotient) - : "lo", "accum"); + : "lo"); /* * Due to possible jiffies inconsistencies, we need to check --- arch/mips/kernel/cpu-bugs64.c.orig 2004-07-07 04:54:01.762046056 -0400 +++ arch/mips/kernel/cpu-bugs64.c 2004-07-07 04:54:26.501285120 -0400 @@ -82,7 +82,7 @@ static inline void mult_sh_align_mod(lon ".set pop" : "=&r" (lv1), "=r" (lw) : "r" (m1), "r" (m2), "r" (s), "I" (0) - : "hi", "lo", "accum"); + : "hi", "lo"); /* We have to use single integers for m1 and m2 and a double * one for p to be sure the mulsidi3 gcc's RTL multiplication * instruction has the workaround applied. Older versions of --------------060201020207080706050901-- From milang@tal.org Wed Jul 7 15:36:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jul 2004 15:36:56 +0100 (BST) Received: from [IPv6:::ffff:195.197.172.115] ([IPv6:::ffff:195.197.172.115]:43740 "EHLO gw01.mail.saunalahti.fi") by linux-mips.org with ESMTP id ; Wed, 7 Jul 2004 15:36:46 +0100 Received: from fairytale.tal.org (cruel.tal.org [195.16.220.85]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 67B7036364 for ; Wed, 7 Jul 2004 17:36:35 +0300 (EEST) Received: from amos (unknown [195.16.220.84]) by fairytale.tal.org (Postfix) with SMTP id 0CF4F8D77 for ; Wed, 7 Jul 2004 17:38:14 +0300 (EEST) Message-ID: <00e201c46430$5cc18250$54dc10c3@amos> From: "Kaj-Michael Lang" To: References: <000d01c463d1$994e59a0$6030a8c0@eng32> Subject: Re: querries on cross compiler Date: Wed, 7 Jul 2004 17:40:32 +0300 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.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 5416 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: milang@tal.org Precedence: bulk X-list: linux-mips > Iam trying to build a cross compiler for MIPS processor on > "i686-pc-linux-gcc" host. Iam getting some errors during the installation of > BINUTILS(binutils-2.9.1) i.e, after configure, when I type "make" Iam > getting errors. Can u please suggest how to remove these errors. That binutils is extremly old, try using something a little more uptodate... I'd recommend using crosstool to build you cross compiler. -- Kaj-Michael Lang , milang@tal.org From anemo@mba.ocn.ne.jp Wed Jul 7 15:52:01 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jul 2004 15:52:05 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:48613 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Wed, 7 Jul 2004 15:52:01 +0100 Received: from localhost (p1005-ipad202funabasi.chiba.ocn.ne.jp [222.146.72.5]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 25A1970FB for ; Wed, 7 Jul 2004 23:51:58 +0900 (JST) Date: Wed, 07 Jul 2004 23:57:23 +0900 (JST) Message-Id: <20040707.235723.74756758.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: Re: possible overflow in __udelay From: Atsushi Nemoto In-Reply-To: <20040701.211456.59461492.anemo@mba.ocn.ne.jp> References: <20040701.211456.59461492.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 5417 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: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Thu, 01 Jul 2004 21:14:56 +0900 (JST), Atsushi Nemoto said: anemo> Current __udelay implementation will cause internal overflow on anemo> the first multiplication. anemo> Basically, the multiplication is: anemo> X = usecs * 2**64 / (100000 / HZ) anemo> And maximum input usecs value is 5000 (MAX_UDELAY_MS * 1000). anemo> If usecs == 5000 and HZ == 1000, X is 5 * 2**64. Of course anemo> this can not be held in 64bit variable. anemo> How should we avoid the overflow? anemo> .... Don't you really have any comments? I believe, for example, mdelay(10) does not work properly on most MIPS ports (except for DECSTATION and JAZZ which have smaller HZ value). --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Wed Jul 7 16:06:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jul 2004 16:06:48 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:12525 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Wed, 7 Jul 2004 16:06:44 +0100 Received: from localhost (p4055-ipad01funabasi.chiba.ocn.ne.jp [61.207.78.55]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id DF3736F74 for ; Thu, 8 Jul 2004 00:06:41 +0900 (JST) Date: Thu, 08 Jul 2004 00:12:07 +0900 (JST) Message-Id: <20040708.001207.74754796.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: Re: possible overflow in __udelay From: Atsushi Nemoto In-Reply-To: <20040707.235723.74756758.anemo@mba.ocn.ne.jp> References: <20040701.211456.59461492.anemo@mba.ocn.ne.jp> <20040707.235723.74756758.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 5418 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: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Wed, 07 Jul 2004 23:57:23 +0900 (JST), Atsushi Nemoto said: anemo> I believe, for example, mdelay(10) does not work properly on anemo> most MIPS ports (except for DECSTATION and JAZZ which have anemo> smaller HZ value). Oops, mdelay(10) should work. But mdelay(5) (mdelay(MAX_UDELAY_MS)) does not work. --- Atsushi Nemoto From ralf@linux-mips.org Thu Jul 8 01:49:54 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 01:49:58 +0100 (BST) Received: from p508B762C.dip.t-dialin.net ([IPv6:::ffff:80.139.118.44]:46972 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 01:49:54 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i680nq4w017081; Thu, 8 Jul 2004 02:49:52 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i680np0X017080; Thu, 8 Jul 2004 02:49:51 +0200 Date: Thu, 8 Jul 2004 02:49:51 +0200 From: Ralf Baechle To: "Randy.Dunlap" Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] MIPS getdomainname() off by 1; Message-ID: <20040708004951.GA17045@linux-mips.org> References: <20040531202101.4ace5e95.rddunlap@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040531202101.4ace5e95.rddunlap@osdl.org> User-Agent: Mutt/1.4.1i 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: 5419 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, May 31, 2004 at 08:21:01PM -0700, Randy.Dunlap wrote: > irix_getdomainname() max size appears to be off by 1; > other similar code in kernel uses __NEW_UTS_LEN as the max size, > and includes an extra byte for the terminating > null character. > > Does sysirix.c need to limit to 63 instead of 64 for some > reason? I would know why - and it has other bugs also, so I removed it by the normal Linux getdomainname(2) for SysV flavour syscalls, too. Ralf From ralf@linux-mips.org Thu Jul 8 01:59:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 01:59:50 +0100 (BST) Received: from p508B762C.dip.t-dialin.net ([IPv6:::ffff:80.139.118.44]:55420 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 01:59:46 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i680xjaR017340; Thu, 8 Jul 2004 02:59:45 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i680xjaF017339; Thu, 8 Jul 2004 02:59:45 +0200 Date: Thu, 8 Jul 2004 02:59:45 +0200 From: Ralf Baechle To: Mika Kukkonen Cc: Andrew Morton , linux-mips@linux-mips.org Subject: Re: MIPS defines __kernel_uid_t as int? Message-ID: <20040708005945.GA17133@linux-mips.org> References: <1089223996.20452.31.camel@miku.mobile.lnx.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089223996.20452.31.camel@miku.mobile.lnx.nokia.com> User-Agent: Mutt/1.4.1i 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: 5420 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, Jul 07, 2004 at 11:13:16AM -0700, Mika Kukkonen wrote: > I was doing > $ grep __kernel_uid_t include/*/posix_types.h > > and noticed that MIPS is the only architecture that > defines that to be signed (int) and not unsigned? > > Same with __kernel_uid32_t. Is this intentional > deviation or just an oversight? Intentional but with a really weak reason. Linux/MIPS uses the same type definitions as SysV rsp. the MIPS ABI in it's EFT (Extended Fundamental Types). Not a great idea in retroperspective but that's a choice made 10 years ago. I don't think we'd break anything by changing this. Objections to changing it? Ralf From ralf@linux-mips.org Thu Jul 8 02:43:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 02:43:39 +0100 (BST) Received: from p508B762C.dip.t-dialin.net ([IPv6:::ffff:80.139.118.44]:30333 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 02:43:33 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i681hW3b018351; Thu, 8 Jul 2004 03:43:32 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i681hUBa018350; Thu, 8 Jul 2004 03:43:30 +0200 Date: Thu, 8 Jul 2004 03:43:30 +0200 From: Ralf Baechle To: Kaj-Michael Lang Cc: linux-mips Subject: Re: something like sparc32/setarch for mips? Message-ID: <20040708014330.GA16587@linux-mips.org> References: <00b201c461af$fd26dc50$0000fea9@amos> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b201c461af$fd26dc50$0000fea9@amos> User-Agent: Mutt/1.4.1i 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: 5421 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, Jul 04, 2004 at 01:16:35PM +0300, Kaj-Michael Lang wrote: > Is there something like sparc32 or setarch for mips ? Surprise. It's called mips32 :-) and - surprise #2 it's on available on ftp.linux-mips.org. Ralf From asridhars@gmail.com Thu Jul 8 07:38:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 07:38:50 +0100 (BST) Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.193]:35734 "HELO mproxy.gmail.com") by linux-mips.org with SMTP id ; Thu, 8 Jul 2004 07:38:45 +0100 Received: by mproxy.gmail.com with SMTP id d5so180660rng for ; Wed, 07 Jul 2004 23:38:40 -0700 (PDT) Received: by 10.38.3.58 with SMTP id 58mr203354rnc; Wed, 07 Jul 2004 23:38:40 -0700 (PDT) Message-ID: Date: Thu, 8 Jul 2004 12:08:40 +0530 From: Sridhar Adagada To: linux-mips@linux-mips.org Subject: Optimisation 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: 5422 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: asridhars@gmail.com Precedence: bulk X-list: linux-mips Hello everybody, I am sorry if the mail is too long had to include assembly code, which i am still learning. I am trying some optimization on some my code. Listed below is the c-code of a function which is obvious, but the assembly from compiler with optimization for speed, is confusing to me can any one explain? As you can see $6 is the length, my confusion is at the lines 12-14, 19, 20 why is the length added with 65535 and the comparison with 0 for max and the right shift. The same operation is done the base ($7) can any one explain why this is needed. Can i replace all these three instructions with "ori $9 $0 $6" One more thing does the instruction at line 25 "madl $25, $24" do? Any help with be greatly appresciated Thanks Sri C-code: short cal_xxx(short *abs, short *coef, short len, short base) { short i; short sum = 0; for (i = 0; i < length; i++) { sum += ( (unsigned int)abs[i] * (unsigned int)coef[i] ); } return ( ((sum + 1 << (base -1)) >> base) ); } Assmebly code: 1 .set noat 2 .set noreorder 3 .set nomacro 4 .text 5 .align 4 6 .globl cal_xxx 7 /* short i; 8 short sum = 0; */ 9 ori $9, $0, 0 10 ori $3, $0, 0 11 /* for( i = 0; i < length; i++ ) */ 12 andi $6, $6, 65535 13 imax $8, $6, 0 14 srl $10, $8, 3 15 beq $10, $0, .L62 16 andi $7, $7, 65535 17 move $2, $5 18 move $11, $4 19 sll $24, $10, 3 20 andi $9, $24, 65528 21 .L78: 22 lh $25, 0($11) 23 lh $24, 0($2) 24 mtlo $3 25 madl $25, $24 26 lh $25, 2($11) 27 lh $24, 2($2) 28 nop 29 madl $25, $24 30 lh $25, 4($11) 31 lh $24, 4($2) 32 nop 33 madl $25, $24 34 lh $25, 6($11) 35 lh $24, 6($2) 36 nop 37 madl $25, $24 38 lh $25, 8($11) 39 lh $24, 8($2) 40 nop 41 madl $25, $24 42 lh $25, 10($11) 43 lh $24, 10($2) 44 nop 45 madl $25, $24 46 lh $25, 12($11) 47 lh $24, 12($2) 48 nop 49 madl $25, $24 50 lh $25, 14($11) 51 lh $24, 14($2) 52 addiu $10, $10, -1 53 madl $25, $24 54 addiu $11, $11, 16 55 addiu $2, $2, 16 56 mflo $3 57 bne $10, $0, .L78 58 nop 59 nop 60 .L62: 61 andi $10, $8, 7 62 beq $10, $0, .L44 63 sll $9, $9, 1 64 addu $2, $5, $9 65 addu $25, $4, $9 66 addiu $10, $10, -1 67 .L1000082: 68 lh $15, 0($2) 69 lh $24, 0($25) 70 mtlo $3 71 madl $24, $15 72 addiu $25, $25, 2 73 addiu $2, $2, 2 74 mflo $3 75 bne $10, $0, .L1000082 76 addiu $10, $10, -1 77 .L44: 78 /* } for-end */ 79 addiu $25, $7, -1 80 ori $15, $0, 1 81 sllv $24, $15, $25 82 addu $14, $3, $24 83 srav $13, $14, $7 84 sll $2, $13, 16 85 # .ef 86 jr $ra 87 sra $2, $2, 16 88 .type cal_xxx,@function 89 .size cal_xxx,.-cal_xxx 90 .align 4 91 #i $9 local 92 #sum $3 local 93 94 #abs $4 param 95 #coef $5 param 96 #length $6 param 97 #base $7 param 98 99 .data 100 .L139: 101 .text 102 /* } end-function */ From geert@linux-m68k.org Thu Jul 8 09:46:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 09:46:25 +0100 (BST) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:39673 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 09:46:21 +0100 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i688kJXK023575; Thu, 8 Jul 2004 10:46:19 +0200 (MEST) Date: Thu, 8 Jul 2004 10:46:19 +0200 (MEST) From: Geert Uytterhoeven To: Ralf Baechle cc: "Randy.Dunlap" , Linux/MIPS Development Subject: Re: [PATCH] MIPS getdomainname() off by 1; In-Reply-To: <20040708004951.GA17045@linux-mips.org> Message-ID: References: <20040531202101.4ace5e95.rddunlap@osdl.org> <20040708004951.GA17045@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: 5423 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: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Thu, 8 Jul 2004, Ralf Baechle wrote: > On Mon, May 31, 2004 at 08:21:01PM -0700, Randy.Dunlap wrote: > > irix_getdomainname() max size appears to be off by 1; > > other similar code in kernel uses __NEW_UTS_LEN as the max size, > > and includes an extra byte for the terminating > > null character. > > > > Does sysirix.c need to limit to 63 instead of 64 for some > > reason? > > I would know why - and it has other bugs also, so I removed it by the > normal Linux getdomainname(2) for SysV flavour syscalls, too. I saw you even removed it from 2.0. Woow! ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From geert@linux-m68k.org Thu Jul 8 10:00:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 10:00:05 +0100 (BST) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:37510 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 10:00:00 +0100 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i688xwXK025081; Thu, 8 Jul 2004 10:59:58 +0200 (MEST) Date: Thu, 8 Jul 2004 10:59:58 +0200 (MEST) From: Geert Uytterhoeven To: Sridhar Adagada cc: Linux/MIPS Development Subject: Re: Optimisation In-Reply-To: Message-ID: References: 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: 5424 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: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Thu, 8 Jul 2004, Sridhar Adagada wrote: > As you can see $6 is the length, my confusion is at the lines 12-14, > 19, 20 why is the length added with 65535 and the comparison with 0 It's not `added with 65535', but `ANDed with 65535'. MIPS32 has 32-bit integer operations only. If you want to do 16-bit math, all data has to be masked. Anyway, for performance, it's better to do 32-bit math only. > short cal_xxx(short *abs, short *coef, short len, short base) > { > short i; > short sum = 0; > > for (i = 0; i < length; i++) > { > sum += ( (unsigned int)abs[i] * (unsigned int)coef[i] ); Why cast to unsigned int while sum is a short? Unless you really want to rely on sum being a short, you better make it int and do the truncation to short after the loop. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From geert@sonycom.com Thu Jul 8 10:25:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 10:25:26 +0100 (BST) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:19871 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 10:25:21 +0100 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i689PFXK028049 for ; Thu, 8 Jul 2004 11:25:15 +0200 (MEST) X-Received: from dolphin.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i689M4XJ027801 for ; Thu, 8 Jul 2004 11:22:04 +0200 (MEST) X-Received: from ns1.nerdnet.nl ([217.170.15.1] helo=nerdnet.nl ident=root) by dolphin.sonytel.be with esmtp (Exim 4.34) id 1BiV6S-0002PF-AM for Geert.Uytterhoeven@sonycom.com; Thu, 08 Jul 2004 11:22:04 +0200 X-Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by nerdnet.nl (8.12.11/8.12.11/Debian-5) with SMTP id i689M2NV001813 for ; Thu, 8 Jul 2004 11:22:03 +0200 X-Received: by mproxy.gmail.com with SMTP id d5so184491rng for ; Thu, 08 Jul 2004 02:22:00 -0700 (PDT) X-Received: by 10.38.9.68 with SMTP id 68mr172039rni; Thu, 08 Jul 2004 02:21:59 -0700 (PDT) Message-ID: Date: Thu, 8 Jul 2004 14:51:59 +0530 From: Sridhar Adagada To: Geert Uytterhoeven Subject: Re: Optimisation In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on nerdnet.nl X-Virus-Status: Clean X-Spambayes-Classification: ham; 0.00 ReSent-Date: Thu, 8 Jul 2004 11:25:13 +0200 (MEST) ReSent-From: Geert Uytterhoeven ReSent-To: Linux/MIPS Development ReSent-Subject: Re: Optimisation ReSent-Message-ID: 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: 5425 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: geert@sonycom.com Precedence: bulk X-list: linux-mips Thank you. For some reason i have been reading ANDI ans ADDI. But i am still confused at lines 13, 14 and 15 13 imax $8, $6, 0 14 srl $10, $8, 3 15 beq $10, $0, .L62 Thanks for correcting me Sri On Thu, 8 Jul 2004 10:59:58 +0200 (MEST), Geert Uytterhoeven wrote: > On Thu, 8 Jul 2004, Sridhar Adagada wrote: > > As you can see $6 is the length, my confusion is at the lines 12-14, > > 19, 20 why is the length added with 65535 and the comparison with 0 > > It's not `added with 65535', but `ANDed with 65535'. MIPS32 has 32-bit integer > operations only. If you want to do 16-bit math, all data has to be masked. > > Anyway, for performance, it's better to do 32-bit math only. > > > short cal_xxx(short *abs, short *coef, short len, short base) > > { > > short i; > > short sum = 0; > > > > for (i = 0; i < length; i++) > > { > > sum += ( (unsigned int)abs[i] * (unsigned int)coef[i] ); > > Why cast to unsigned int while sum is a short? Unless you really want to rely > on sum being a short, you better make it int and do the truncation to short > after the loop. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > From geert@sonycom.com Thu Jul 8 10:50:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 10:50:20 +0100 (BST) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:7858 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 10:50:16 +0100 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i689oFXK000414 for ; Thu, 8 Jul 2004 11:50:15 +0200 (MEST) X-Received: from dolphin.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i689meXJ000280 for ; Thu, 8 Jul 2004 11:48:40 +0200 (MEST) X-Received: from ns1.nerdnet.nl ([217.170.15.1] helo=nerdnet.nl ident=root) by dolphin.sonytel.be with esmtp (Exim 4.34) id 1BiVWC-00030R-CP for Geert.Uytterhoeven@sonycom.com; Thu, 08 Jul 2004 11:48:40 +0200 X-Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by nerdnet.nl (8.12.11/8.12.11/Debian-5) with SMTP id i689mdYd003671 for ; Thu, 8 Jul 2004 11:48:39 +0200 X-Received: by mproxy.gmail.com with SMTP id d5so185080rng for ; Thu, 08 Jul 2004 02:48:35 -0700 (PDT) X-Received: by 10.38.3.58 with SMTP id 58mr215311rnc; Thu, 08 Jul 2004 02:48:35 -0700 (PDT) Message-ID: Date: Thu, 8 Jul 2004 15:18:35 +0530 From: Sridhar Adagada To: Geert Uytterhoeven Subject: Re: Optimisation In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on nerdnet.nl X-Virus-Status: Clean X-Spambayes-Classification: ham; 0.00 ReSent-Date: Thu, 8 Jul 2004 11:50:10 +0200 (MEST) ReSent-From: Geert Uytterhoeven ReSent-To: Linux/MIPS Development ReSent-Subject: Re: Optimisation ReSent-Message-ID: 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: 5426 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: geert@sonycom.com Precedence: bulk X-list: linux-mips Thank you! I got it now If the length is less then 7, the loop is handled differently for the fast access of the abs and coef. Thanks you very much Sri On Thu, 8 Jul 2004 14:51:59 +0530, Sridhar Adagada wrote: > Thank you. For some reason i have been reading ANDI ans ADDI. But i > am still confused at lines 13, 14 and 15 > 13 imax $8, $6, 0 > 14 srl $10, $8, 3 > 15 beq $10, $0, .L62 > > Thanks for correcting me > > Sri > > > > > On Thu, 8 Jul 2004 10:59:58 +0200 (MEST), Geert Uytterhoeven > wrote: > > On Thu, 8 Jul 2004, Sridhar Adagada wrote: > > > As you can see $6 is the length, my confusion is at the lines 12-14, > > > 19, 20 why is the length added with 65535 and the comparison with 0 > > > > It's not `added with 65535', but `ANDed with 65535'. MIPS32 has 32-bit integer > > operations only. If you want to do 16-bit math, all data has to be masked. > > > > Anyway, for performance, it's better to do 32-bit math only. > > > > > short cal_xxx(short *abs, short *coef, short len, short base) > > > { > > > short i; > > > short sum = 0; > > > > > > for (i = 0; i < length; i++) > > > { > > > sum += ( (unsigned int)abs[i] * (unsigned int)coef[i] ); > > > > Why cast to unsigned int while sum is a short? Unless you really want to rely > > on sum being a short, you better make it int and do the truncation to short > > after the loop. > > > > Gr{oetje,eeting}s, > > > > Geert > > > > -- > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > > > In personal conversations with technical people, I call myself a hacker. But > > when I'm talking to journalists I just say "programmer" or something like that. > > -- Linus Torvalds > > > From ralf@linux-mips.org Thu Jul 8 11:57:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 11:57:32 +0100 (BST) Received: from p508B72ED.dip.t-dialin.net ([IPv6:::ffff:80.139.114.237]:44308 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 11:57:06 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i68Aup7n030958; Thu, 8 Jul 2004 12:56:51 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i68AuonB030957; Thu, 8 Jul 2004 12:56:50 +0200 Date: Thu, 8 Jul 2004 12:56:50 +0200 From: Ralf Baechle To: Geert Uytterhoeven Cc: "Randy.Dunlap" , Linux/MIPS Development Subject: Re: [PATCH] MIPS getdomainname() off by 1; Message-ID: <20040708105650.GE17133@linux-mips.org> References: <20040531202101.4ace5e95.rddunlap@osdl.org> <20040708004951.GA17045@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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: 5427 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, Jul 08, 2004 at 10:46:19AM +0200, Geert Uytterhoeven wrote: > > > Does sysirix.c need to limit to 63 instead of 64 for some > > > reason? > > > > I would know why - and it has other bugs also, so I removed it by the > > normal Linux getdomainname(2) for SysV flavour syscalls, too. > > I saw you even removed it from 2.0. Woow! ;-) Yep :-) But whoever is still runing 2.0 on MIPS must be suffering from a suicidal tendences. Too many bugs left unfixed. Ralf From ralf@linux-mips.org Thu Jul 8 12:43:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 12:43:31 +0100 (BST) Received: from p508B72ED.dip.t-dialin.net ([IPv6:::ffff:80.139.114.237]:30229 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 12:43:27 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i68BhOuq032141; Thu, 8 Jul 2004 13:43:24 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i68BhNgJ032138; Thu, 8 Jul 2004 13:43:23 +0200 Date: Thu, 8 Jul 2004 13:43:23 +0200 From: Ralf Baechle To: Sergei Shtylyov Cc: linux-mips@ftp.linux-mips.org Subject: Re: LO reg. gets trashed by kgdb in 2.4.x and older kernels Message-ID: <20040708114323.GB16587@linux-mips.org> References: <40E96E2A.2000403@dev.rtsoft.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40E96E2A.2000403@dev.rtsoft.ru> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 5428 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, Jul 05, 2004 at 07:05:14PM +0400, Sergei Shtylyov wrote: > I have discovered that the gdb-low.S trashes the LO reg. instead of > restoring it. This was fixed for the 2.6 kernels but, as it seems, was left > unfixed in the earlier ones (run into this on 2.4.18/2.4.20). Here's the > patch > against the lastest 2.4.x revision of the file... Thanks. This also was an ancient bug probably dating back to late '94 or early '95 so all branches other than 2.6 were affected. Ralf From ralf@linux-mips.org Thu Jul 8 13:50:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 13:50:32 +0100 (BST) Received: from p508B72ED.dip.t-dialin.net ([IPv6:::ffff:80.139.114.237]:29206 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 13:50:27 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i68CoQhb001258; Thu, 8 Jul 2004 14:50:26 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i68CoOoH001257; Thu, 8 Jul 2004 14:50:24 +0200 Date: Thu, 8 Jul 2004 14:50:24 +0200 From: Ralf Baechle To: Trivial Patch Monkey Cc: linux-mips@linux-mips.org Subject: Re: [TRIVIAL] [TRIVIAL 2.6] arch_mips_pmc-sierra_yosemite_setup.c: kill Message-ID: <20040708125024.GC31620@linux-mips.org> References: <1089184944.1160.62.camel@bach> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089184944.1160.62.camel@bach> User-Agent: Mutt/1.4.1i 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: 5429 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 Dear Patchmonkey, On Wed, Jul 07, 2004 at 05:22:24PM +1000, Trivial Patch Monkey wrote: > Subject: [TRIVIAL] [TRIVIAL 2.6] arch_mips_pmc-sierra_yosemite_setup.c: kill > From: Trivial Patch Monkey > ./arch/mips/pmc-sierra/yosemite/setup.c: asm/bootinfo.h is included more than once. > > Against 2.6.5. Thanks. Applied, Ralf From Volker.Jahns@thalreit.de Thu Jul 8 13:52:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 13:52:57 +0100 (BST) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.187]:54524 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 13:52:52 +0100 Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BiYOQ-0003sj-00 for linux-mips@linux-mips.org; Thu, 08 Jul 2004 14:52:50 +0200 Received: from [84.128.28.95] (helo=pegasus.thalreit) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BiYOQ-0000xY-00 for linux-mips@linux-mips.org; Thu, 08 Jul 2004 14:52:50 +0200 Received: from thalreit.dyndns.org (localhost.thalreit [127.0.0.1]) by pegasus.thalreit (8.12.6/8.12.6) with SMTP id i68CqiDk079410 for ; Thu, 8 Jul 2004 14:52:44 +0200 (CEST) (envelope-from Volker.Jahns@thalreit.de) Received: from 194.59.120.11 (SquirrelMail authenticated user volker) by thalreit.dyndns.org with HTTP; Thu, 8 Jul 2004 14:52:44 +0200 (CEST) Message-ID: <33009.194.59.120.11.1089291164.squirrel@thalreit.dyndns.org> Date: Thu, 8 Jul 2004 14:52:44 +0200 (CEST) Subject: sharp mobilon hc-4100 From: "Volker Jahns" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:5b79f71352ef1364d4beaa70fe75636d 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: 5430 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: Volker.Jahns@thalreit.de Precedence: bulk X-list: linux-mips Linux on Sharp Mobilon HC-4100 I would like to have Linux boot on the Sharp HC-4100 and have tried a couple of suitable kernels with the following outcome: Booting ------- netbsd tx3912 - netbsd 1.5.3 , keyboard functional linux for philips velo - vmlinux-2.4.0-test4-pre3 , keyboard not functional Booting, but framebuffer scrambled ---------------------------------- linux nino - vmlinux-2.4.17 linux sharp HC-4500/HC-4600 - vmlinux-2.3.21. vmlinux-2.3.47 I have tried to compile a kernel from versions - 2.4.20 and 2.4.0-test9 - ( sharp mobilon, philips velo, philips nino) which all boot but have the framebuffer device scrambled. Which kernel version is good to start from, and where would I find its code ? Has somebody a working .config vor the Velo 500 available, so that I get the correct options to have this damn framebuffer device working? Please redirect, in case this should be the wrong place to post. -- Volker Jahns, volker@thalreit.de, http://thalreit.de, DG7PM From ricardo.mendoza@kanux.com Thu Jul 8 19:21:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 19:21:24 +0100 (BST) Received: from mail.supercable.net.ve ([IPv6:::ffff:216.72.155.13]:62416 "EHLO supercable.net.ve") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 19:21:19 +0100 Received: from [200.85.73.10] (unverified [200.85.73.10]) by supercable.net.ve (TRUE) with ESMTP id 7708807 for multiple; Thu, 08 Jul 2004 14:20:50 GMT -4 Message-ID: <40ED9097.6040800@kanux.com> Date: Thu, 08 Jul 2004 14:21:11 -0400 From: Ricardo Mendoza Reply-To: ricardo.mendoza@kanux.com User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Volker Jahns , linux-mips@linux-mips.org Subject: Re: sharp mobilon hc-4100 References: <33009.194.59.120.11.1089291164.squirrel@thalreit.dyndns.org> In-Reply-To: <33009.194.59.120.11.1089291164.squirrel@thalreit.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Server: High Performance Mail Server - http://surgemail.com X-Authenticated-User: numen Domain supercable.net.ve 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: 5431 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: ricardo.mendoza@kanux.com Precedence: bulk X-list: linux-mips Volker Jahns wrote: > Linux on Sharp Mobilon HC-4100 > > I would like to have Linux boot on the Sharp HC-4100 and have tried a > couple of suitable kernels with the following outcome: > > Booting > ------- > netbsd tx3912 - netbsd 1.5.3 , keyboard functional > linux for philips velo - vmlinux-2.4.0-test4-pre3 , keyboard not > functional > > > Booting, but framebuffer scrambled > ---------------------------------- > linux nino - vmlinux-2.4.17 > linux sharp HC-4500/HC-4600 - vmlinux-2.3.21. vmlinux-2.3.47 > > I have tried to compile a kernel from versions - 2.4.20 and 2.4.0-test9 - > ( sharp mobilon, philips velo, philips nino) which all boot but have the > framebuffer device scrambled. > > Which kernel version is good to start from, and where would I find its code ? > Has somebody a working .config vor the Velo 500 available, so that I get > the correct options to have this damn framebuffer device working? > > > Please redirect, in case this should be the wrong place to post. Hi, sometimes the scrambled problem happens when you are using a linked inside ramdisk image and it corrupts the kernel itself in some way, it has happened to me quite many times with the nino kernel. It would help to check your config, I can assure you that the 2.4.17 nino code is working, I use it myself but on the nino, it might require some modifications for the Mobilon. -- Ricardo Mendoza Meinhardt ricardo.mendoza@kanux.com .knxTech Administrador Linux Programador/PHP "get ready for a bit of the old Ultra Violence" From volker@thalreit.de Thu Jul 8 20:16:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 20:16:20 +0100 (BST) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.176]:47341 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 20:16:16 +0100 Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BieNN-0005pd-00; Thu, 08 Jul 2004 21:16:09 +0200 Received: from [84.128.28.95] (helo=ikarus.thalreit) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BieNN-0003la-00; Thu, 08 Jul 2004 21:16:09 +0200 Received: by ikarus.thalreit (Postfix, from userid 501) id E6D073368C; Thu, 8 Jul 2004 21:26:25 +0200 (CEST) Date: Thu, 8 Jul 2004 21:26:25 +0200 From: Volker Jahns To: Ricardo Mendoza Cc: linux-mips@linux-mips.org Subject: Re: sharp mobilon hc-4100 Message-ID: <20040708192625.GB9312@ikarus.thalreit> Mail-Followup-To: Ricardo Mendoza , linux-mips@linux-mips.org References: <33009.194.59.120.11.1089291164.squirrel@thalreit.dyndns.org> <40ED9097.6040800@kanux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40ED9097.6040800@kanux.com> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:5b79f71352ef1364d4beaa70fe75636d 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: 5432 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: volker@thalreit.de Precedence: bulk X-list: linux-mips On Thu, Jul 08, 2004 at 02:21:11PM -0400, Ricardo Mendoza wrote: > Volker Jahns wrote: > >Linux on Sharp Mobilon HC-4100 > > > >I would like to have Linux boot on the Sharp HC-4100 and have tried a > >couple of suitable kernels with the following outcome: > > ... > It would help to check your config, I can assure you that the 2.4.17 > nino code is working, I use it myself but on the nino, it might require > some modifications for the Mobilon. Modifications are certainly a must: e.g. 2.4.20 in drivers/video/tx3912fb.h thereis _only_ framebuffer definitions for the nino: 
#if defined(CONFIG_NINO_4MB) || defined(CONFIG_NINO_8MB)
#define FB_X_RES       240 
#define FB_Y_RES       320
#if defined(CONFIG_FBCON_CFB4)
#define FB_BPP         4
while 2.4.0-test9 carries the _good_ information for the velo 1, velo 500 and for the helio ( the code for the nino is missing here). In drivers/video/r3912fb.h ( which seems to be the historic version of tx3912fb.h, ouch what a chaos :-( 
#ifdef CONFIG_PHILIPS_VELO
#       ifdef CONFIG_PHILIPS_VELO1
#               define FB_X_RES         480
#       elif defined(CONFIG_PHILIPS_VELO500)
#               define FB_X_RES         640
#       endif
#       define  FB_Y_RES        240
#       ifdef CONFIG_PHILIPS_VELO_4GRAY
#               define FB_BPP   2
#       else /* CONFIG_PHILIPS_VELO_16GRAY */
#               define FB_BPP   4
#       endif
#       define FB_IS_GREY     1
#       define FB_IS_INVERSE  0
#       define VIDEORAM_SIZE  (FB_X_RES * FB_Y_RES * FB_BPP / 8)
On the other hand the mobilon needs 
#               define FB_X_RES         640
#               define FB_X_RES         240
#               define FB_BPP           4
This information ( and what else which might be of interest to make the LCD working on this thing) must have get lost on the kernel's way. I really wonder where to find a more or less functional version of the kernel code to start with. -- Volker Jahns, Volker.Jahns@thalreit.de, http://thalreit.de, DG7PM From tbm@cyrius.com Thu Jul 8 20:49:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 20:49:36 +0100 (BST) Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:48907 "EHLO sorrow.cyrius.com") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 20:49:32 +0100 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 2AA0C64D3B; Thu, 8 Jul 2004 19:49:28 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id B62E710009; Thu, 8 Jul 2004 21:48:21 +0200 (CEST) Date: Thu, 8 Jul 2004 21:48:21 +0200 From: Martin Michlmayr To: linux-mips@linux-mips.org Subject: Re: sharp mobilon hc-4100 Message-ID: <20040708194821.GA6925@deprecation.cyrius.com> References: <33009.194.59.120.11.1089291164.squirrel@thalreit.dyndns.org> <40ED9097.6040800@kanux.com> <20040708192625.GB9312@ikarus.thalreit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040708192625.GB9312@ikarus.thalreit> User-Agent: Mutt/1.5.6+20040523i 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: 5433 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: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Volker Jahns [2004-07-08 21:26]: > On the other hand the mobilon needs > # define FB_X_RES 640 > # define FB_X_RES 240 I thought it was 800x480. BTW, how do you boot this thing? From WinCE or can you override the ROM? -- Martin Michlmayr tbm@cyrius.com From ricardo.mendoza@kanux.com Thu Jul 8 21:03:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jul 2004 21:03:22 +0100 (BST) Received: from mail.supercable.net.ve ([IPv6:::ffff:216.72.155.13]:39901 "EHLO supercable.net.ve") by linux-mips.org with ESMTP id ; Thu, 8 Jul 2004 21:03:17 +0100 Received: from [200.85.73.10] (unverified [200.85.73.10]) by supercable.net.ve (TRUE) with ESMTP id 7711177 for ; Thu, 08 Jul 2004 16:02:49 GMT -4 Message-ID: <40EDA87E.3060509@kanux.com> Date: Thu, 08 Jul 2004 16:03:10 -0400 From: Ricardo Mendoza Reply-To: ricardo.mendoza@kanux.com User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: [Fwd: Re: sharp mobilon hc-4100] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Server: High Performance Mail Server - http://surgemail.com X-Authenticated-User: numen Domain supercable.net.ve 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: 5434 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: ricardo.mendoza@kanux.com Precedence: bulk X-list: linux-mips Volker Jahns wrote: > > Modifications are certainly a must: > > e.g. 2.4.20 in drivers/video/tx3912fb.h thereis _only_ framebuffer definitions for the nino: > 
> #if defined(CONFIG_NINO_4MB) || defined(CONFIG_NINO_8MB)
> #define FB_X_RES       240 
> #define FB_Y_RES       320
> #if defined(CONFIG_FBCON_CFB4)
> #define FB_BPP         4
>
> > while 2.4.0-test9 carries the _good_ information for the velo 1, velo 500 and for the helio ( the code for the nino is missing here). In drivers/video/r3912fb.h ( which seems to be the historic version of tx3912fb.h, ouch what a chaos :-( > 
> #ifdef CONFIG_PHILIPS_VELO
> #       ifdef CONFIG_PHILIPS_VELO1
> #               define FB_X_RES         480
> #       elif defined(CONFIG_PHILIPS_VELO500)
> #               define FB_X_RES         640
> #       endif
> #       define  FB_Y_RES        240
> #       ifdef CONFIG_PHILIPS_VELO_4GRAY
> #               define FB_BPP   2
> #       else /* CONFIG_PHILIPS_VELO_16GRAY */
> #               define FB_BPP   4
> #       endif
> #       define FB_IS_GREY     1
> #       define FB_IS_INVERSE  0
> #       define VIDEORAM_SIZE  (FB_X_RES * FB_Y_RES * FB_BPP / 8)
>
> > On the other hand the mobilon needs > 
> #               define FB_X_RES         640
> #               define FB_X_RES         240
> #               define FB_BPP           4
>
> > This information ( and what else which might be of interest to make the LCD working on this thing) must have get lost on the kernel's way. I really wonder where to find a more or less functional version of the kernel code to start with. > The 2.4.17 tree on Steven J. Hill's website is functional, I can give it to you if you cant find it, just let me know. By the way, when I refer to functional is for the TX3912 generic stuff, one thing for sure is that you _WILL_ need to make an specific machine directory for the mobilon, and you can use the same code for it, after removing the non-generic tx3912 stuff and perhaps changing some stuff that matters only to the mobilon. You can also try hacking on the nino files as if you were using a nino. P.D. Remove the html tags -- Ricardo Mendoza Meinhardt ricardo.mendoza@kanux.com .knxTech Administrador Linux Programador/PHP "get ready for a bit of the old Ultra Violence" From ralf@linux-mips.org Fri Jul 9 01:17:03 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jul 2004 01:17:11 +0100 (BST) Received: (from localhost user: 'ralf' uid#501 fake: STDIN (ralf@3ffe:8260:2028:fffe::1)) by linux-mips.org id ; Fri, 9 Jul 2004 01:17:02 +0100 Date: Fri, 9 Jul 2004 01:17:02 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: New CVS Mailing List Message-ID: <20040709001702.GA2795@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i 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: 5435 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 I've created a new mailing list maltalinux-cvs@linux-mips.org for tracking of MIPS's stable Malta tree. Unlike the main Linux CVS repository which is more slanted towards development maltalinux-cvs is primarily oriented towards stability on the Malta platform and it's processors. Subscription to maltalinux-cvs@linux-mips.org is handled via Ecartis (ecartis@linux-mips.org), just send an email with the words subscribe maltalinux-cvs. In order to unsubscribe, send unsubscribe maltalinux-cvs. Sending the word help will reveal further secrets about the advanced use of Ecartis. At http://www.linux-mips.org/ecartis you'll also find a web-based interface to Ecartis. Similarly as with the main CVS tree the new tree may be followed in cvsweb at http://www.linux-mips.org/cvsweb/malta/ in xcvs and via anon cvs by cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs login (Only needed the first time you use anonymous CVS, the password is "cvs") cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co malta Ralf From Volker.Jahns@thalreit.de Fri Jul 9 07:56:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jul 2004 07:56:36 +0100 (BST) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.189]:52428 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Fri, 9 Jul 2004 07:56:31 +0100 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BipJ7-0005dy-00; Fri, 09 Jul 2004 08:56:29 +0200 Received: from [84.128.29.15] (helo=pegasus.thalreit) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BipJ5-00023r-00; Fri, 09 Jul 2004 08:56:27 +0200 Received: from thalreit.dyndns.org (localhost.thalreit [127.0.0.1]) by pegasus.thalreit (8.12.6/8.12.6) with SMTP id i696uGDk092590; Fri, 9 Jul 2004 08:56:20 +0200 (CEST) (envelope-from Volker.Jahns@thalreit.de) Received: from 194.59.120.11 (SquirrelMail authenticated user volker) by thalreit.dyndns.org with HTTP; Fri, 9 Jul 2004 08:56:26 +0200 (CEST) Message-ID: <59553.194.59.120.11.1089356186.squirrel@thalreit.dyndns.org> In-Reply-To: <20040708194821.GA6925@deprecation.cyrius.com> References: <33009.194.59.120.11.1089291164.squirrel@thalreit.dyndns.org> <40ED9097.6040800@kanux.com> <20040708192625.GB9312@ikarus.thalreit> <20040708194821.GA6925@deprecation.cyrius.com> Date: Fri, 9 Jul 2004 08:56:26 +0200 (CEST) Subject: Re: sharp mobilon hc-4100 From: "Volker Jahns" To: "Martin Michlmayr" Cc: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:5b79f71352ef1364d4beaa70fe75636d 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: 5436 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: Volker.Jahns@thalreit.de Precedence: bulk X-list: linux-mips > * Volker Jahns [2004-07-08 21:26]: >> On the other hand the mobilon needs >> # define FB_X_RES 640 >> # define FB_X_RES 240 that is correct. > > I thought it was 800x480. BTW, how do you boot this thing? From > WinCE or can you override the ROM? pbsdboot :-( But if you have an idea on how to write the ROM, please let me know. -- Volker Jahns, volker@thalreit.de, http://thalreit.de, DG7PM From ralf@linux-mips.org Fri Jul 9 12:21:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jul 2004 12:21:56 +0100 (BST) Received: from p508B6BD7.dip.t-dialin.net ([IPv6:::ffff:80.139.107.215]:45095 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 9 Jul 2004 12:21:51 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i69BLmPH029669; Fri, 9 Jul 2004 13:21:48 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i69BLl8n029668; Fri, 9 Jul 2004 13:21:47 +0200 Date: Fri, 9 Jul 2004 13:21:47 +0200 From: Ralf Baechle To: Ricardo Mendoza Cc: linux-mips@linux-mips.org Subject: Re: [Fwd: Re: sharp mobilon hc-4100] Message-ID: <20040709112147.GB20141@linux-mips.org> References: <40EDA87E.3060509@kanux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40EDA87E.3060509@kanux.com> User-Agent: Mutt/1.4.1i 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: 5437 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, Jul 08, 2004 at 04:03:10PM -0400, Ricardo Mendoza wrote: > The 2.4.17 tree on Steven J. Hill's website is functional, I can give it > to you if you cant find it, just let me know. Would be nice if somebody can resurrect this platform. It's rotting for too long and Steven even convinced me to remove it from 2.6. I hope we can add functional code back somewhen. Ralf From ricardo.mendoza@kanux.com Fri Jul 9 16:46:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jul 2004 16:46:51 +0100 (BST) Received: from mail.supercable.net.ve ([IPv6:::ffff:216.72.155.13]:40324 "EHLO supercable.net.ve") by linux-mips.org with ESMTP id ; Fri, 9 Jul 2004 16:46:47 +0100 Received: from [200.85.73.10] (unverified [200.85.73.10]) by supercable.net.ve (TRUE) with ESMTP id 7730830 for multiple; Fri, 09 Jul 2004 11:46:12 GMT -4 Message-ID: <40EEBDDE.9070005@kanux.com> Date: Fri, 09 Jul 2004 11:46:38 -0400 From: Ricardo Mendoza Reply-To: ricardo.mendoza@kanux.com User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [Fwd: Re: sharp mobilon hc-4100] References: <40EDA87E.3060509@kanux.com> <20040709112147.GB20141@linux-mips.org> In-Reply-To: <20040709112147.GB20141@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Server: High Performance Mail Server - http://surgemail.com X-Authenticated-User: numen Domain supercable.net.ve 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: 5438 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: ricardo.mendoza@kanux.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > Would be nice if somebody can resurrect this platform. It's rotting > for too long and Steven even convinced me to remove it from 2.6. I > hope we can add functional code back somewhen. Hey Ralf, well as you know I have been getting involved in that, as far as today PCMCIA IDE kind of works, but the real plan is to develop a PCMCIA driver for the controller. Im ricmm, perhaps now that vacations started for me I can really get into the stuff, I will let you know if I get into porting it to the 2.6 kernel. -- Ricardo Mendoza Meinhardt ricardo.mendoza@kanux.com .knxTech Administrador Linux Programador/PHP "get ready for a bit of the old Ultra Violence" From theansweriz42@hotmail.com Fri Jul 9 19:50:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jul 2004 19:50:12 +0100 (BST) Received: from bay2-f21.bay2.hotmail.com ([IPv6:::ffff:65.54.247.21]:24582 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Fri, 9 Jul 2004 19:50:08 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 Jul 2004 11:50:00 -0700 Received: from 209.243.128.191 by by2fd.bay2.hotmail.msn.com with HTTP; Fri, 09 Jul 2004 18:50:00 GMT X-Originating-IP: [209.243.128.191] X-Originating-Email: [theansweriz42@hotmail.com] X-Sender: theansweriz42@hotmail.com From: "S C" To: linux-mips@linux-mips.org Subject: Strange, strange occurence Date: Fri, 09 Jul 2004 18:50:00 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jul 2004 18:50:00.0703 (UTC) FILETIME=[89CCC0F0:01C465E5] 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: 5439 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: theansweriz42@hotmail.com Precedence: bulk X-list: linux-mips Well I'm hoping it isn't so strange to some of you folks and you'll be able to tell what's going on :) Here's my problem: Using MontaVista Linux 3.1 on a Toshiba RBTx4938 board. Using YAMON, when I download the kernel via the debug ethernet port it runs fine. If I download the kernel via the Tx4938 inbuilt ethernet controller, it crashes! Memory checksumming and a quick manual memory dump inspection reveals that the kernel download went perfectly ok, and the image is completely and correctly downloaded to RAM. The crash is occuring inside the function r4k_flush_icache_range(). I tried 'flush -i' and 'flush -d' on YAMON after the download but before the 'go', but that didn't help. I also tried completely disabling caches and loading/running uncached, but it gave the same error. Now, the final twist! Using an ICE, I set a breakpoint at the r4k_flush_icache_range function. Then I loaded the kernel as usual, ran it with the ICE, stepped through a few instructions inside the r4k_flush_icache_range function and then did a 'cont'. The kernel now booted fine! If I don't set the breakpoint inside that function though, and just try to run with the ICE the same error (Inst fetch/Load error) occurs. I'm at a loss trying to figure out what's going on. I suspect it has something to do with caches perhaps (duh!), but have no clue what! Anybody out there face a similar kind of a situation before? Thanks in advance for any help offered. Regards, -Steve _________________________________________________________________ MSN 9 Dial-up Internet Access helps fight spam and pop-ups – now 2 months FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/ From ralf@linux-mips.org Fri Jul 9 22:57:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jul 2004 22:57:06 +0100 (BST) Received: from p508B6BD7.dip.t-dialin.net ([IPv6:::ffff:80.139.107.215]:28974 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 9 Jul 2004 22:57:02 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i69Lv1mr010291; Fri, 9 Jul 2004 23:57:01 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i69Lv0Y9010290; Fri, 9 Jul 2004 23:57:00 +0200 Date: Fri, 9 Jul 2004 23:57:00 +0200 From: Ralf Baechle To: Song Wang Cc: linux-mips@linux-mips.org Subject: Re: kbuild support to build one module with multiple separate components? Message-ID: <20040709215700.GB4316@linux-mips.org> References: <20040706230050.53313.qmail@web40006.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040706230050.53313.qmail@web40006.mail.yahoo.com> User-Agent: Mutt/1.4.1i 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: 5440 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 Tue, Jul 06, 2004 at 04:00:50PM -0700, Song Wang wrote: > This is wrong, because kbuild will treat A as > independent module. All I want is to treat > A as component of the only module mymodule.o. It > should be linked to mymodule.o > > Any idea on how to write a kbuild Makefile to > support such kind of single module produced > by linking multiple components and each component > is located in separate directory? Thanks. That's a limitation in the current kbuild system. You either have to put all files into a single directory or if you don't want that split your module into several independant modules. What I haven't tried is using .a libraries but they're generally deprecated in kbuild. Ralf From niels.sterrenburg@philips.com Sat Jul 10 08:34:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Jul 2004 08:34:20 +0100 (BST) Received: from [IPv6:::ffff:213.189.19.80] ([IPv6:::ffff:213.189.19.80]:55558 "EHLO mail.kpsws.com") by linux-mips.org with ESMTP id ; Sat, 10 Jul 2004 08:34:15 +0100 Received: (qmail 46330 invoked by uid 89); 10 Jul 2004 07:33:57 -0000 Received: from unknown (HELO mail.kpsws.com) (127.0.0.1) by localhost with SMTP; 10 Jul 2004 07:33:57 -0000 Received: from 80.56.56.210 (SquirrelMail authenticated user pulsar@kpsws.com) by mail.kpsws.com with HTTP; Sat, 10 Jul 2004 09:33:57 +0200 (CEST) Message-ID: <1557.80.56.56.210.1089444837.squirrel@mail.kpsws.com> In-Reply-To: References: Date: Sat, 10 Jul 2004 09:33:57 +0200 (CEST) Subject: Re: Strange, strange occurence From: "Niels Sterrenburg" To: "S C" Cc: linux-mips@linux-mips.org Reply-To: niels.sterrenburg@philips.com User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: 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: 5441 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: niels.sterrenburg@philips.com Precedence: bulk X-list: linux-mips Hi Steve, When you set a breakpoint with the ice and step through, for each step the ICE set's a breakpoint on the next instruction: e.g.: - modifies next instruction in memory (via CPU !!!) with a breakpoint instruction, - and update the cache so that the breakpoint instruction is really in memory and that i-cache is invalid. (or something like that) So indead you have a cache problem which is explanable solved/disapeared by steppig through with the ICE. Maybe a stupid question from me but why flushing an icache ?: r4k_flush_icache_range regards, Niels > Well I'm hoping it isn't so strange to some of you folks and you'll be > able > to tell what's going on :) > > Here's my problem: > > Using MontaVista Linux 3.1 on a Toshiba RBTx4938 board. Using YAMON, when > I > download the kernel via the debug ethernet port it runs fine. If I > download > the kernel via the Tx4938 inbuilt ethernet controller, it crashes! > > Memory checksumming and a quick manual memory dump inspection reveals that > the kernel download went perfectly ok, and the image is completely and > correctly downloaded to RAM. > > The crash is occuring inside the function r4k_flush_icache_range(). > > I tried 'flush -i' and 'flush -d' on YAMON after the download but before > the > 'go', but that didn't help. I also tried completely disabling caches and > loading/running uncached, but it gave the same error. > > Now, the final twist! Using an ICE, I set a breakpoint at the > r4k_flush_icache_range function. Then I loaded the kernel as usual, ran it > with the ICE, stepped through a few instructions inside the > r4k_flush_icache_range function and then did a 'cont'. The kernel now > booted > fine! > > If I don't set the breakpoint inside that function though, and just try to > run with the ICE the same > error (Inst fetch/Load error) occurs. > > I'm at a loss trying to figure out what's going on. I suspect it has > something to do with caches perhaps (duh!), but have no clue what! > Anybody > out there face a similar kind of a situation before? > > Thanks in advance for any help offered. > > Regards, > -Steve > > _________________________________________________________________ > MSN 9 Dial-up Internet Access helps fight spam and pop-ups – now 2 months > FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/ > > > From ralf@linux-mips.org Sat Jul 10 11:05:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Jul 2004 11:05:21 +0100 (BST) Received: from p508B77FA.dip.t-dialin.net ([IPv6:::ffff:80.139.119.250]:17460 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 10 Jul 2004 11:05:17 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6AA4D5H023994; Sat, 10 Jul 2004 12:04:13 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6AA4CaF023993; Sat, 10 Jul 2004 12:04:12 +0200 Date: Sat, 10 Jul 2004 12:04:12 +0200 From: Ralf Baechle To: S C Cc: linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Message-ID: <20040710100412.GA23624@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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: 5442 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, Jul 09, 2004 at 06:50:00PM +0000, S C wrote: > Using MontaVista Linux 3.1 on a Toshiba RBTx4938 board. Using YAMON, when I > download the kernel via the debug ethernet port it runs fine. If I download > the kernel via the Tx4938 inbuilt ethernet controller, it crashes! If you're using a Montavista kernel you should report to Montavista. We don't have the source so any comment here is speculation. > The crash is occuring inside the function r4k_flush_icache_range(). > > I tried 'flush -i' and 'flush -d' on YAMON after the download but before > the 'go', but that didn't help. I also tried completely disabling caches > and loading/running uncached, but it gave the same error. > > Now, the final twist! Using an ICE, I set a breakpoint at the > r4k_flush_icache_range function. Then I loaded the kernel as usual, ran it > with the ICE, stepped through a few instructions inside the > r4k_flush_icache_range function and then did a 'cont'. The kernel now > booted fine! As already pointed out by the other poster Niels Sterrenburg using a debugger unavoidably changes the state of the system to be debugged. For at least some of the TX49xx processors there is a problem under certain circumstances if a flush of an I-cache line flushes that cache instruction itself. Make sure you're not getting hit by that one. Ralf From bunk@fs.tum.de Mon Jul 12 01:16:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jul 2004 01:16:14 +0100 (BST) Received: from hermes.fachschaften.tu-muenchen.de ([IPv6:::ffff:129.187.202.12]:18905 "HELO hermes.fachschaften.tu-muenchen.de") by linux-mips.org with SMTP id ; Mon, 12 Jul 2004 01:16:09 +0100 Received: (qmail 10531 invoked from network); 12 Jul 2004 00:10:25 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 12 Jul 2004 00:10:25 -0000 Date: Mon, 12 Jul 2004 02:16:04 +0200 From: Adrian Bunk To: ralf@linux-mips.org, kwalker@broadcom.com Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: 2.6: sound/oss/swarm_cs4297a.c still required? Message-ID: <20040712001604.GH4701@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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: 5443 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: bunk@fs.tum.de Precedence: bulk X-list: linux-mips Hi, in 2.6 (I've checked 2.6.7-mm7) sound/oss/swarm_cs4297a.c is no longer listed in sound/oss/Makefile. Was this accidential, or should this file be removed? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From ralf@linux-mips.org Mon Jul 12 02:01:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jul 2004 02:01:09 +0100 (BST) Received: from p508B7511.dip.t-dialin.net ([IPv6:::ffff:80.139.117.17]:53320 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 12 Jul 2004 02:01:05 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6C0x33h019601; Mon, 12 Jul 2004 02:59:03 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6C0x2nj019600; Mon, 12 Jul 2004 02:59:02 +0200 Date: Mon, 12 Jul 2004 02:59:02 +0200 From: Ralf Baechle To: Adrian Bunk Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: 2.6: sound/oss/swarm_cs4297a.c still required? Message-ID: <20040712005902.GA19170@linux-mips.org> References: <20040712001604.GH4701@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040712001604.GH4701@fs.tum.de> User-Agent: Mutt/1.4.1i 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: 5444 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, Jul 12, 2004 at 02:16:04AM +0200, Adrian Bunk wrote: > in 2.6 (I've checked 2.6.7-mm7) sound/oss/swarm_cs4297a.c is no longer > listed in sound/oss/Makefile. Was this accidential, or should this file > be removed? Still partially merged only. Ralf From KevinK@mips.com Mon Jul 12 16:19:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jul 2004 16:19:12 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:34987 "EHLO dns0.mips.com") by linux-mips.org with ESMTP id ; Mon, 12 Jul 2004 16:19:07 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id i6CFIvi1025964; Mon, 12 Jul 2004 08:18:58 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i6CFIukJ023378; Mon, 12 Jul 2004 08:18:57 -0700 (PDT) Message-ID: <00ba01c46823$3729b200$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , "S C" Cc: References: <20040710100412.GA23624@linux-mips.org> Subject: Re: Strange, strange occurence Date: Mon, 12 Jul 2004 17:16:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Scanned-By: MIMEDefang 2.39 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: 5445 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: KevinK@mips.com Precedence: bulk X-list: linux-mips [snip] > > The crash is occuring inside the function r4k_flush_icache_range(). > > > > I tried 'flush -i' and 'flush -d' on YAMON after the download but before > > the 'go', but that didn't help. I also tried completely disabling caches > > and loading/running uncached, but it gave the same error. > > > > Now, the final twist! Using an ICE, I set a breakpoint at the > > r4k_flush_icache_range function. Then I loaded the kernel as usual, ran it > > with the ICE, stepped through a few instructions inside the > > r4k_flush_icache_range function and then did a 'cont'. The kernel now > > booted fine! > > As already pointed out by the other poster Niels Sterrenburg using a > debugger unavoidably changes the state of the system to be debugged. > > For at least some of the TX49xx processors there is a problem under certain > circumstances if a flush of an I-cache line flushes that cache instruction > itself. Make sure you're not getting hit by that one. It's not just the TX49xx series. While many MIPS-compatible processors do handle the special case of flushing the active CACHE instruction itself, not all of them do, and the MIPS32 spec calls it out as having an "UNPREDICTABLE" result. A truly safe and general I-cache flush routine should itself run uncached, but a cursory glance at the linux-mips.org sources makes me think that we do not take that precaution by default - the flush_icache_range pointer looks to be set to the address of r4k_flush_icache_range() function, rather than its (uncacheable) alias in kseg1. Is this something that's fixed in a linker script, or are we just living dangerously? Regards, Kevin K. From theansweriz42@hotmail.com Mon Jul 12 21:54:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jul 2004 21:54:56 +0100 (BST) Received: from bay2-f6.bay2.hotmail.com ([IPv6:::ffff:65.54.247.6]:15109 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Mon, 12 Jul 2004 21:54:51 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Jul 2004 13:49:10 -0700 Received: from 209.243.128.191 by by2fd.bay2.hotmail.msn.com with HTTP; Mon, 12 Jul 2004 20:49:10 GMT X-Originating-IP: [209.243.128.191] X-Originating-Email: [theansweriz42@hotmail.com] X-Sender: theansweriz42@hotmail.com From: "S C" To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Date: Mon, 12 Jul 2004 20:49:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2004 20:49:10.0816 (UTC) FILETIME=[AED6AA00:01C46851] 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: 5446 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: theansweriz42@hotmail.com Precedence: bulk X-list: linux-mips Hi Niels, Ralf, Kevin Thanks for responding to my query! For the moment, I have fixed the symptoms, but still don't know what the problem is (it could be what you guys suspect it to be). The r4k_flush_icache_range() was being called from inside r4k_tlb_init() and the range being specified was KSEG0 to KSEG0 + 0x80, i.e. the TLB handler. I commented out the call to r4k_flush_icache_range and now the kernel seems to boot normally! But I suspect I have not fixed a problem, merely sidestepped it. So now maybe I should repeat the question Niels asked: why was that call necessary? Thanks again, -Steve. >From: Ralf Baechle >To: S C >CC: linux-mips@linux-mips.org >Subject: Re: Strange, strange occurence >Date: Sat, 10 Jul 2004 12:04:12 +0200 > >On Fri, Jul 09, 2004 at 06:50:00PM +0000, S C wrote: > > > Using MontaVista Linux 3.1 on a Toshiba RBTx4938 board. Using YAMON, >when I > > download the kernel via the debug ethernet port it runs fine. If I >download > > the kernel via the Tx4938 inbuilt ethernet controller, it crashes! > >If you're using a Montavista kernel you should report to Montavista. We >don't have the source so any comment here is speculation. > > > The crash is occuring inside the function r4k_flush_icache_range(). > > > > I tried 'flush -i' and 'flush -d' on YAMON after the download but before > > the 'go', but that didn't help. I also tried completely disabling caches > > and loading/running uncached, but it gave the same error. > > > > Now, the final twist! Using an ICE, I set a breakpoint at the > > r4k_flush_icache_range function. Then I loaded the kernel as usual, ran >it > > with the ICE, stepped through a few instructions inside the > > r4k_flush_icache_range function and then did a 'cont'. The kernel now > > booted fine! > >As already pointed out by the other poster Niels Sterrenburg using a >debugger unavoidably changes the state of the system to be debugged. > >For at least some of the TX49xx processors there is a problem under certain >circumstances if a flush of an I-cache line flushes that cache instruction >itself. Make sure you're not getting hit by that one. > > Ralf _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From theansweriz42@hotmail.com Mon Jul 12 22:23:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jul 2004 22:23:46 +0100 (BST) Received: from bay2-f27.bay2.hotmail.com ([IPv6:::ffff:65.54.247.27]:12046 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Mon, 12 Jul 2004 22:23:41 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Jul 2004 14:23:20 -0700 Received: from 209.243.128.191 by by2fd.bay2.hotmail.msn.com with HTTP; Mon, 12 Jul 2004 21:23:20 GMT X-Originating-IP: [209.243.128.191] X-Originating-Email: [theansweriz42@hotmail.com] X-Sender: theansweriz42@hotmail.com From: "S C" To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Date: Mon, 12 Jul 2004 21:23:20 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2004 21:23:20.0394 (UTC) FILETIME=[747B72A0:01C46856] 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: 5447 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: theansweriz42@hotmail.com Precedence: bulk X-list: linux-mips And thinking about it a little more, I might as well clarfy my understanding while we're on the topic. Here's a code snippet from r4k_tlb_init() in arch/mips/mm/c-r4k.c memcpy((void *)KSEG0, &except_vec0_r4000, 0x80); flush_icache_range(KSEG0, KSEG0 + 0x80); So my understanding is that the TLB exception handler is being copied to the right memory location, and just in case some other TLB exception handler (YAMON's presumably) is residing in I-cache, to flush ( hit invalidate) it. Is this correct? Shouldn't there be code to writeback_invalidate the exception handler from the data cache ? Presumably the memcpy causes the TLB handler to lodge itself in the D cache till it is moved to RAM (either explicitly or when some other lines replace the cache lines where the handler is), right? Thanks in advance for helping me understand the issue here. Regards, -Steve. >From: Ralf Baechle >To: S C >CC: linux-mips@linux-mips.org >Subject: Re: Strange, strange occurence >Date: Sat, 10 Jul 2004 12:04:12 +0200 > >On Fri, Jul 09, 2004 at 06:50:00PM +0000, S C wrote: > > > Using MontaVista Linux 3.1 on a Toshiba RBTx4938 board. Using YAMON, >when I > > download the kernel via the debug ethernet port it runs fine. If I >download > > the kernel via the Tx4938 inbuilt ethernet controller, it crashes! > >If you're using a Montavista kernel you should report to Montavista. We >don't have the source so any comment here is speculation. > > > The crash is occuring inside the function r4k_flush_icache_range(). > > > > I tried 'flush -i' and 'flush -d' on YAMON after the download but before > > the 'go', but that didn't help. I also tried completely disabling caches > > and loading/running uncached, but it gave the same error. > > > > Now, the final twist! Using an ICE, I set a breakpoint at the > > r4k_flush_icache_range function. Then I loaded the kernel as usual, ran >it > > with the ICE, stepped through a few instructions inside the > > r4k_flush_icache_range function and then did a 'cont'. The kernel now > > booted fine! > >As already pointed out by the other poster Niels Sterrenburg using a >debugger unavoidably changes the state of the system to be debugged. > >For at least some of the TX49xx processors there is a problem under certain >circumstances if a flush of an I-cache line flushes that cache instruction >itself. Make sure you're not getting hit by that one. > > Ralf _________________________________________________________________ Check out the latest news, polls and tools in the MSN 2004 Election Guide! http://special.msn.com/msn/election2004.armx From KevinK@mips.com Mon Jul 12 22:51:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jul 2004 22:51:11 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:2261 "EHLO dns0.mips.com") by linux-mips.org with ESMTP id ; Mon, 12 Jul 2004 22:51:07 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id i6CLowPb028303; Mon, 12 Jul 2004 14:50:58 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i6CLovAL003625; Mon, 12 Jul 2004 14:50:58 -0700 (PDT) Message-ID: <020201c46859$fa6b98b0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "S C" , "Ralf Baechle" Cc: References: Subject: Re: Strange, strange occurence Date: Mon, 12 Jul 2004 23:48:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Scanned-By: MIMEDefang 2.39 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: 5448 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: KevinK@mips.com Precedence: bulk X-list: linux-mips > And thinking about it a little more, I might as well clarfy my understanding > while we're on the topic. > > Here's a code snippet from r4k_tlb_init() in arch/mips/mm/c-r4k.c > > memcpy((void *)KSEG0, &except_vec0_r4000, 0x80); > flush_icache_range(KSEG0, KSEG0 + 0x80); > > So my understanding is that the TLB exception handler is being copied to the > right memory location, and just in case some other TLB exception handler > (YAMON's presumably) is residing in I-cache, to flush ( hit invalidate) it. > Is this correct? > > Shouldn't there be code to writeback_invalidate the exception handler from > the data cache ? Presumably the memcpy causes the TLB handler to lodge > itself in the D cache till it is moved to RAM (either explicitly or when > some other lines replace the cache lines where the handler is), right? > > Thanks in advance for helping me understand the issue here. Your intuition is correct, and the code in r4k_tlb_init() does look scary. But at least in the linux-mips CVS tree, flush_icache_range() tests to see if "cpu_has_ic_fills_f_dc" (CPU has Icache fills from Dcache, I presume) is set, and if it isn't, it pushes the specified range out of the Dcache before flushing the Icache. I would speculate that either your c-r4k.c is out of sync with yout tlb-r4k.c, or you erroneously have cpu_has_ic_fills_f_dc set. Regards, Kevin K. From KevinK@mips.com Mon Jul 12 23:35:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jul 2004 23:35:50 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:64985 "EHLO dns0.mips.com") by linux-mips.org with ESMTP id ; Mon, 12 Jul 2004 23:35:46 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id i6CMS4pN028506; Mon, 12 Jul 2004 15:28:04 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i6CMS316007379; Mon, 12 Jul 2004 15:28:03 -0700 (PDT) Message-ID: <021201c4685f$2925ee30$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Kevin D. Kissell" , "S C" , "Ralf Baechle" Cc: References: <020201c46859$fa6b98b0$0deca8c0@Ulysses> Subject: Re: Strange, strange occurence Date: Tue, 13 Jul 2004 00:25:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Scanned-By: MIMEDefang 2.39 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: 5449 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: KevinK@mips.com Precedence: bulk X-list: linux-mips > Your intuition is correct, and the code in r4k_tlb_init() does look scary. > But at least in the linux-mips CVS tree, flush_icache_range() tests to see > if "cpu_has_ic_fills_f_dc" (CPU has Icache fills from Dcache, I presume) > is set, and if it isn't, it pushes the specified range out of the Dcache before > flushing the Icache. I would speculate that either your c-r4k.c is out of > sync with yout tlb-r4k.c, or you erroneously have cpu_has_ic_fills_f_dc > set. Hmm. On closer examination, there *is* a bug in the current r4k_flush_icache_range(), in that it computes its cache flush loop for the I-cache based on the D-cache line size. Those line sizes are *usually* the same. By any chance are they different for the TX49 family? If the icache line is longer than the dcache line, there should be no functional problem, just some wasted cycles. But if the dcache line were, say, twice the length of the Icache line, only half of the icache lines would be invalidated... Regards, Kevin K. From ralf@linux-mips.org Tue Jul 13 00:00:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 00:00:55 +0100 (BST) Received: from p508B5DDF.dip.t-dialin.net ([IPv6:::ffff:80.139.93.223]:43093 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 00:00:51 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6CN0lm5013743; Tue, 13 Jul 2004 01:00:47 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6CN0kno013734; Tue, 13 Jul 2004 01:00:46 +0200 Date: Tue, 13 Jul 2004 01:00:46 +0200 From: Ralf Baechle To: S C Cc: linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Message-ID: <20040712230046.GA6176@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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: 5450 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, Jul 12, 2004 at 09:23:20PM +0000, S C wrote: > And thinking about it a little more, I might as well clarfy my > understanding while we're on the topic. > > Here's a code snippet from r4k_tlb_init() in arch/mips/mm/c-r4k.c > > memcpy((void *)KSEG0, &except_vec0_r4000, 0x80); > flush_icache_range(KSEG0, KSEG0 + 0x80); > > So my understanding is that the TLB exception handler is being copied to > the right memory location, and just in case some other TLB exception > handler (YAMON's presumably) is residing in I-cache, to flush ( hit > invalidate) it. Is this correct? > > Shouldn't there be code to writeback_invalidate the exception handler from > the data cache ? flush_icache_range() does that where necessary. > Presumably the memcpy causes the TLB handler to lodge > itself in the D cache till it is moved to RAM Correct. All MIPS processors [1] do their primary I-cache refills from second or third level cache or memory - whatever hits first. If code was changed a flush of the data cache is required so the I-cache can actually fetch the new data and because old stale code might still be in the I-cache an I-cache flush is also required. > (either explicitly or when > some other lines replace the cache lines where the handler is), right? > > Thanks in advance for helping me understand the issue here. Ralf [1] Exceptions are the R4000/R4400 SC and MC versions in a split S-cache configuration where the primary I-cache is refilled from the secondary I-cache which mean this flush has to flush the secondary data cache back to memory also. Linux doesn't support this configuration because no known system uses it iow it's only a theoretically possible config. The second exception are the AMD MIPS32 processors where the I-cache is snooping the D-cache and therefore the D-cache flush can is unnecessary. The third exception are R1x000 in SMP configurations where I-caches snoop remote stores so coherency doesn't need any maintenance in software at all. Only the I-cache of the CPU that did modify the code needs flushing. From theansweriz42@hotmail.com Tue Jul 13 00:10:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 00:10:41 +0100 (BST) Received: from bay2-f19.bay2.hotmail.com ([IPv6:::ffff:65.54.247.19]:52233 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 00:10:37 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Jul 2004 16:10:30 -0700 Received: from 209.243.128.191 by by2fd.bay2.hotmail.msn.com with HTTP; Mon, 12 Jul 2004 23:10:29 GMT X-Originating-IP: [209.243.128.191] X-Originating-Email: [theansweriz42@hotmail.com] X-Sender: theansweriz42@hotmail.com From: "S C" To: KevinK@mips.com, ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Date: Mon, 12 Jul 2004 23:10:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2004 23:10:30.0227 (UTC) FILETIME=[6CF61A30:01C46865] 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: 5451 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: theansweriz42@hotmail.com Precedence: bulk X-list: linux-mips Hi Kevin and Ralf, Thanks for your inputs and suggestions! In the case of the Tx49 family, the primary I and D cache lines are both the same size (8 words), so the problem you mention below will not arise. I didn't think about the meaning of cpu_has_ic_fills_f_dc before writing my previous mail, and I see now that my intuition (and your explanation helps) was correct. For the moment, the problem is fixed. But I'm going to try and get to the bottom of this when I have the time. Thanks, -Steve. >From: "Kevin D. Kissell" >To: "Kevin D. Kissell" , "S C" >, "Ralf Baechle" >CC: >Subject: Re: Strange, strange occurence >Date: Tue, 13 Jul 2004 00:25:37 +0200 > > > Your intuition is correct, and the code in r4k_tlb_init() does look >scary. > > But at least in the linux-mips CVS tree, flush_icache_range() tests to >see > > if "cpu_has_ic_fills_f_dc" (CPU has Icache fills from Dcache, I presume) > > is set, and if it isn't, it pushes the specified range out of the Dcache >before > > flushing the Icache. I would speculate that either your c-r4k.c is out >of > > sync with yout tlb-r4k.c, or you erroneously have cpu_has_ic_fills_f_dc > > set. > >Hmm. On closer examination, there *is* a bug in the current >r4k_flush_icache_range(), >in that it computes its cache flush loop for the I-cache based on the >D-cache line size. >Those line sizes are *usually* the same. By any chance are they different >for the >TX49 family? If the icache line is longer than the dcache line, there >should be no >functional problem, just some wasted cycles. But if the dcache line were, >say, >twice the length of the Icache line, only half of the icache lines would be >invalidated... > > Regards, > > Kevin K. > _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From ralf@linux-mips.org Tue Jul 13 00:11:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 00:11:49 +0100 (BST) Received: from p508B5DDF.dip.t-dialin.net ([IPv6:::ffff:80.139.93.223]:52821 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 00:11:45 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6CNBdng014006; Tue, 13 Jul 2004 01:11:39 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6CNBcDZ014005; Tue, 13 Jul 2004 01:11:38 +0200 Date: Tue, 13 Jul 2004 01:11:38 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: S C , linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Message-ID: <20040712231138.GB6176@linux-mips.org> References: <020201c46859$fa6b98b0$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020201c46859$fa6b98b0$0deca8c0@Ulysses> User-Agent: Mutt/1.4.1i 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: 5452 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, Jul 12, 2004 at 11:48:31PM +0200, Kevin D. Kissell wrote: > Your intuition is correct, and the code in r4k_tlb_init() does look scary. Not scarry at all. flush_icache_range() has to do whatever is needed to maintain I-cache coherency for the range passed in as the argument. And I don't think we should really have to deal with all the complicated details of cache maintenance in a function like r4k_tlb_init(). > But at least in the linux-mips CVS tree, flush_icache_range() tests to see > if "cpu_has_ic_fills_f_dc" (CPU has Icache fills from Dcache, I presume) Right. Cpu_has_ic_fills_f_dc is only non-zero for the AMD processors where the I-cache is refilled from the D-cache. For typical kernel configurations The definition of cpu_has_ic_fills_f_dc is a constant so the compiler can optimize this further. Ralf From ralf@linux-mips.org Tue Jul 13 00:14:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 00:14:06 +0100 (BST) Received: from p508B5DDF.dip.t-dialin.net ([IPv6:::ffff:80.139.93.223]:55893 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 00:14:02 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6CNDx8U014071; Tue, 13 Jul 2004 01:13:59 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6CNDxXt014070; Tue, 13 Jul 2004 01:13:59 +0200 Date: Tue, 13 Jul 2004 01:13:59 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: S C , linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Message-ID: <20040712231359.GC6176@linux-mips.org> References: <020201c46859$fa6b98b0$0deca8c0@Ulysses> <021201c4685f$2925ee30$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <021201c4685f$2925ee30$0deca8c0@Ulysses> User-Agent: Mutt/1.4.1i 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: 5453 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 Tue, Jul 13, 2004 at 12:25:37AM +0200, Kevin D. Kissell wrote: > Hmm. On closer examination, there *is* a bug in the current r4k_flush_icache_range(), > in that it computes its cache flush loop for the I-cache based on the D-cache line size. > Those line sizes are *usually* the same. By any chance are they different for the > TX49 family? If the icache line is longer than the dcache line, there should be no > functional problem, just some wasted cycles. But if the dcache line were, say, > twice the length of the Icache line, only half of the icache lines would be invalidated... Whoops. Fixing ... Ralf From ralf@linux-mips.org Tue Jul 13 01:33:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 01:33:26 +0100 (BST) Received: from p508B5DDF.dip.t-dialin.net ([IPv6:::ffff:80.139.93.223]:59734 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 01:33:22 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6D0XInj026951; Tue, 13 Jul 2004 02:33:18 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6D0XHmV026950; Tue, 13 Jul 2004 02:33:17 +0200 Date: Tue, 13 Jul 2004 02:33:17 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: S C , linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Message-ID: <20040713003317.GA26715@linux-mips.org> References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ba01c46823$3729b200$0deca8c0@Ulysses> User-Agent: Mutt/1.4.1i 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: 5454 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, Jul 12, 2004 at 05:16:31PM +0200, Kevin D. Kissell wrote: > A truly safe and general I-cache flush routine should itself run uncached, > but a cursory glance at the linux-mips.org sources makes me think > that we do not take that precaution by default - the flush_icache_range > pointer looks to be set to the address of r4k_flush_icache_range() > function, rather than its (uncacheable) alias in kseg1. Is this something > that's fixed in a linker script, or are we just living dangerously? That's a new restriction in MIPS32 v2.0 and you're right, we're not trying to deal with it yet except for the TX49xx. Ralf From collin_no_spam_for_me@xorotude.com Tue Jul 13 08:52:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 08:52:30 +0100 (BST) Received: from eezi.conceptual.net.au ([IPv6:::ffff:203.190.192.22]:58758 "EHLO eezi.net.au") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 08:52:25 +0100 Received: from swift (203-190-200-060.dial.usertools.net [::ffff:203.190.200.60]) by eezi.net.au with esmtp; Tue, 13 Jul 2004 15:51:57 +0800 Message-ID: <000701c468ae$141c3e50$0a9913ac@swift> From: "Collin Baillie" To: linux-mips@linux-mips.org References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> Subject: Help with MOP network boot install on DECstation 5000/240 Date: Tue, 13 Jul 2004 15:49:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 5455 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: collin_no_spam_for_me@xorotude.com Precedence: bulk X-list: linux-mips Hi Guys, I'm trying to install linux-mips on a DECsation 5000/240 I have in my posession. It has the 5.1b rom so tftp boot is apparently out. I've setup mopd on a linux (i386) box here and I'm getting the following on my DECstation: >>boot 3/mop ??? ? PC: 0xa0010aa4 ? CR: 0x8000200c ? SR: 0x30080000 ? VA: 0x1000 ? ER: 0xe7d43000 ? CK: 0xef00ffe2 >> In /var/log/messages I'm seeing: Jul 13 15:44:36 phoenix mopd[10437]: 8:0:2b:2a:fe:c0 (1) Do you have 08002b2afec0? (Yes) Jul 13 15:44:36 phoenix mopd[10437]: 8:0:2b:2a:fe:c0 Send me 08002b2afec0 and using moptrace I get the following: Dst : ab:0:0:1:0:0 MOP Dump/Load Multicast Src : 8:0:2b:2a:fe:c0 Proto : 6001 MOP Dump/Load Length : 000b (11) Code : 08 Request program Device Type : 76 MNE '3MIN (KN02-BA)' Format : 01 Program Type : 02 Operating System Software : 00 '' Processor : 00 System Processor DL Buff Size : 041c (1052) Dst : ab:0:0:2:0:0 MOP Remote Console Multicast Src : 8:0:2b:2a:fe:c0 Proto : 6002 MOP Remote Console Length : 001c (28) Code : 07 System ID Reserved : 00 Receipt Nbr : 0000 Hardware Addr: 8:0:2b:2a:fe:c0 Maint Version: 3.0.0 Maint Funcion: 004b ( Loop Dump MLdr DLC ) Comm Device : 76 MNE '3MIN (KN02-BA)' Dst : 0:80:ad:72:e3:6f Src : 8:0:2b:2a:fe:c0 Proto : 6001 MOP Dump/Load Length : 000b (11) Code : 08 Request program Device Type : 76 MNE '3MIN (KN02-BA)' Format : 01 Program Type : 02 Operating System Software : 00 '' Processor : 00 System Processor DL Buff Size : 041c (1052) Dst : 0:80:ad:72:e3:6f Src : 8:0:2b:2a:fe:c0 Proto : 6001 MOP Dump/Load Length : 0002 (2) Code : 0a Request memory load Load Number : 01 Error : 00 (no error) Dst : 0:80:ad:72:e3:6f Src : 8:0:2b:2a:fe:c0 Proto : 6001 MOP Dump/Load Length : 0002 (2) Code : 0a Request memory load Load Number : 02 Error : 00 (no error) Dst : 0:80:ad:72:e3:6f Src : 8:0:2b:2a:fe:c0 Proto : 6001 MOP Dump/Load Length : 0002 (2) Code : 0a Request memory load Load Number : 03 Error : 00 (no error) I've tried with both the ecoff and the elf kernels (2.4.18) listed on Karel's web pages. I was wondering if anyone on the list has had any success installing via MOP onto a DECstation 5000/240 and would be able to offer me any assistance. Cheers, Collin Baillie From jbglaw@dvmwest.gt.owl.de Tue Jul 13 09:03:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 09:03:27 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:31718 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 09:03:22 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 20F8C4B67D; Tue, 13 Jul 2004 10:03:21 +0200 (CEST) Date: Tue, 13 Jul 2004 10:03:21 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 Message-ID: <20040713080320.GC18841@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PcDVawgyoD+Fem/v" Content-Disposition: inline In-Reply-To: <000701c468ae$141c3e50$0a9913ac@swift> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6i 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: 5456 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --PcDVawgyoD+Fem/v Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2004-07-13 15:49:30 +0800, Collin Baillie wrote in message <000701c468ae$141c3e50$0a9913ac@swift>: [Thanks for *not* hijacking threads] > I'm trying to install linux-mips on a DECsation 5000/240 I have in my > posession. It has the 5.1b rom so tftp boot is apparently out. >=20 > I've setup mopd on a linux (i386) box here and I'm getting the following = on > my DECstation: >=20 > >>boot 3/mop [...] > I've tried with both the ecoff and the elf kernels (2.4.18) listed on > Karel's web pages. So it seems to try to get a file some times and gives up on it. > I was wondering if anyone on the list has had any success installing via = MOP > onto a DECstation 5000/240 and would be able to offer me any assistance. Maybe you'd try Debian's install image? By the way, which mopd are you using? There are several of them around, some quite unuseable... MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --PcDVawgyoD+Fem/v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA85dIHb1edYOZ4bsRAkZUAJ92ropZuea1jtsR5LeozUZ/5kq5aQCdEOQ2 tzyqf5hwDPG9jd2k8soak60= =4hE8 -----END PGP SIGNATURE----- --PcDVawgyoD+Fem/v-- From safiudeen@hotmail.com Tue Jul 13 09:23:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 09:23:13 +0100 (BST) Received: from bay15-f33.bay15.hotmail.com ([IPv6:::ffff:65.54.185.33]:61709 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 09:23:08 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jul 2004 01:23:02 -0700 Received: from 220.247.254.194 by by15fd.bay15.hotmail.msn.com with HTTP; Tue, 13 Jul 2004 08:23:01 GMT X-Originating-IP: [220.247.254.194] X-Originating-Email: [safiudeen@hotmail.com] X-Sender: safiudeen@hotmail.com From: "safiudeen Ts" To: linux-mips@linux-mips.org Subject: Jtag spec. and the firmware for Au1100 Date: Tue, 13 Jul 2004 08:23:01 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2004 08:23:02.0205 (UTC) FILETIME=[9D147ED0:01C468B2] 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: 5457 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: safiudeen@hotmail.com Precedence: bulk X-list: linux-mips How can we copy the kernel image to target board (processor au1100 )? if we want to use JTAG where can I get the jatg schemetic detailes and the firmware for Red Hat linux 9 please any one can help me in this regards than you safi _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From safiudeen@hotmail.com Tue Jul 13 09:25:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 09:25:14 +0100 (BST) Received: from bay15-f12.bay15.hotmail.com ([IPv6:::ffff:65.54.185.12]:4362 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 09:25:10 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jul 2004 01:25:03 -0700 Received: from 220.247.254.194 by by15fd.bay15.hotmail.msn.com with HTTP; Tue, 13 Jul 2004 08:25:03 GMT X-Originating-IP: [220.247.254.194] X-Originating-Email: [safiudeen@hotmail.com] X-Sender: safiudeen@hotmail.com From: "safiudeen Ts" To: linux-mips@linux-mips.org, ecartis@linux-mips.org Subject: Jtag spec. and firmware for au1100 Date: Tue, 13 Jul 2004 08:25:03 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2004 08:25:03.0277 (UTC) FILETIME=[E53E9DD0:01C468B2] 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: 5458 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: safiudeen@hotmail.com Precedence: bulk X-list: linux-mips can anyone help me to get Jtag spec . and the firware for au1100 prcessor based target. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From wd@denx.de Tue Jul 13 09:32:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 09:32:10 +0100 (BST) Received: from mail-out.m-online.net ([IPv6:::ffff:212.18.0.9]:41631 "EHLO mail-out.m-online.net") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 09:32:05 +0100 Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id 012AF52A69; Tue, 13 Jul 2004 10:32:01 +0200 (CEST) Received: from denx.de (host-82-135-33-74.customer.m-online.net [82.135.33.74]) by mail.m-online.net (Postfix) with ESMTP id E4A0CE4287; Tue, 13 Jul 2004 10:32:00 +0200 (CEST) Received: from atlas.denx.de (atlas.denx.de [10.0.0.14]) by denx.de (Postfix) with ESMTP id 6D23E422AE; Tue, 13 Jul 2004 10:32:00 +0200 (MEST) Received: by atlas.denx.de (Postfix, from userid 15) id 20933C109F; Tue, 13 Jul 2004 10:32:00 +0200 (MEST) Received: from atlas.denx.de (localhost [127.0.0.1]) by atlas.denx.de (Postfix) with ESMTP id 1DC6513D6D2; Tue, 13 Jul 2004 10:32:00 +0200 (MEST) To: "safiudeen Ts" Cc: linux-mips@linux-mips.org From: Wolfgang Denk Subject: Re: Jtag spec. and the firmware for Au1100 X-Mailer: exmh version 1.6.4 10/10/1995 Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Tue, 13 Jul 2004 08:23:01 -0000." Date: Tue, 13 Jul 2004 10:31:55 +0200 Message-Id: <20040713083200.20933C109F@atlas.denx.de> 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: 5459 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: wd@denx.de Precedence: bulk X-list: linux-mips In message you wrote: > How can we copy the kernel image to target board (processor au1100 )? > if we want to use JTAG where can I get the jatg schemetic detailes and the > firmware for Red Hat linux 9 You don't need any special information about the JTAG interface (and you will find that it is very difficult to get and under strict NDA if at all). All you need is a JTAG debugger which understands how to deal with this interface, for example the Abatron BDI2000 (which is just great especially for Linux). Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de The C-shell doesn't parse. It adhoculates. - Casper.Dik@Holland.Sun.COM in <3ol96k$b2j@engnews2.Eng.Sun.COM> From tk@mycable.de Tue Jul 13 09:37:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 09:37:14 +0100 (BST) Received: from mail.oricom.de ([IPv6:::ffff:62.116.167.249]:43712 "EHLO oricom4.internetx.de") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 09:37:10 +0100 Received: from mycable.de (c192176.adsl.hansenet.de [213.39.192.176]) (authenticated bits=0) by oricom4.internetx.de (8.13.0/8.13.0) with ESMTP id i6D8bNE2015286; Tue, 13 Jul 2004 10:37:27 +0200 Message-ID: <40F39F31.70102@mycable.de> Date: Tue, 13 Jul 2004 10:37:05 +0200 From: Tiemo Krueger - mycable GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: safiudeen Ts , linux-mips@linux-mips.org Subject: Re: Jtag spec. and the firmware for Au1100 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: 5460 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: tk@mycable.de Precedence: bulk X-list: linux-mips Normally you could use a boatloader like Yamon or uboot to load something from a tftp-server or serial conenction on the board. If there isn't any bootloader on the board you have to flash one on your board. This should normally be provided with the board (which one do you have?). Ejtag: The pin specification for ejtag should be in the board documentation, normally it's quite easy to build an adapter to connect it to ejtag hardware like the bdi2000 or similar. firmware: So you mean a kernel and maybe a rootfile-system? Didn't came anything with the board? Depending on the HW-components on the board you may require your own kernel which you can build from the sources on Linux-mips.org, try at first a default configuration for the Au1100. Tiemo safiudeen Ts wrote: > How can we copy the kernel image to target board (processor au1100 )? > if we want to use JTAG where can I get the jatg schemetic detailes and > the firmware for Red Hat linux 9 > please any one can help me in this regards > > than you > safi > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > From safiudeen@hotmail.com Tue Jul 13 10:04:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 10:04:35 +0100 (BST) Received: from bay15-f8.bay15.hotmail.com ([IPv6:::ffff:65.54.185.8]:34315 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 10:04:31 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jul 2004 02:04:24 -0700 Received: from 220.247.254.194 by by15fd.bay15.hotmail.msn.com with HTTP; Tue, 13 Jul 2004 09:04:24 GMT X-Originating-IP: [220.247.254.194] X-Originating-Email: [safiudeen@hotmail.com] X-Sender: safiudeen@hotmail.com From: "safiudeen Ts" To: linux-mips@linux-mips.org Subject: Re: Jtag spec. and the firmware for Au1100 Date: Tue, 13 Jul 2004 09:04:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2004 09:04:24.0934 (UTC) FILETIME=[64E6E060:01C468B8] 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: 5461 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: safiudeen@hotmail.com Precedence: bulk X-list: linux-mips Is there any software tool that can used to transfer kernel image to db1100 board with the following cofigartion ? Db1100's jtag connected a linux pc's lpt port through a 5v to 3.3v converter _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From daff_vadi@hotmail.com Tue Jul 13 14:01:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 14:01:14 +0100 (BST) Received: from bay15-f22.bay15.hotmail.com ([IPv6:::ffff:65.54.185.22]:35343 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 14:01:08 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Jul 2004 06:01:01 -0700 Received: from 202.56.254.194 by by15fd.bay15.hotmail.msn.com with HTTP; Tue, 13 Jul 2004 13:01:01 GMT X-Originating-IP: [202.56.254.194] X-Originating-Email: [daff_vadi@hotmail.com] X-Sender: daff_vadi@hotmail.com From: "Vadivelan Mani" To: linux-mips@linux-mips.org Subject: pci_alloc_consistent() usage Date: Tue, 13 Jul 2004 18:31:01 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2004 13:01:01.0650 (UTC) FILETIME=[72CDD320:01C468D9] 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: 5462 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: daff_vadi@hotmail.com Precedence: bulk X-list: linux-mips hi, I'm writing a wireless driver which requires 8 transmit and 8 receive buffers each of size 3KB approx. These buffers should be in dma capable space. I've allocated them using pci_alloc_consistent(). I've allocated 128KBytes just to make more space. I've got few doubts. 1. Can pci_alloc_consistent() be used to allocate memory upto 128KBytes? If this is not possible, how much can it allocate? 2.) I would also like to know the exact use of this allocated space to transmit or receive a packet. During transmission i do the following. Plz correct me if i'm wrong because i'm new to driver writing. The device has a register which should be loaded with the transmit buffers starting address. I copy the packet coming from the Kernel in the form of sk_buff structure into one of the transmit buffers that i've allocated using memcpy(). And i set the register in the device to initiate transmission of the packet. Where does the dma transfer concept come in this? There is no mention of the direction of data transfer in pci_alloc_consistent(). I also assumed that allocating buffer in dma capable space was itself enough to start dma transfers. Since i do not have the device now i'm not able to test the code. But i would like to write the code before i get the device. Kindly help me in this. thanking u in advance. regards, vadi. _________________________________________________________________ Marriage by choice.... http://www.shaadi.com/ptnr.php?ptnr=hmltag Log onto Shaadi.com From KevinK@mips.com Tue Jul 13 16:38:18 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 16:38:22 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:25277 "EHLO dns0.mips.com") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 16:38:18 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id i6DFYFjd003365; Tue, 13 Jul 2004 08:34:15 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i6DFYDv0011781; Tue, 13 Jul 2004 08:34:13 -0700 (PDT) Message-ID: <003301c468ee$80c5fa60$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: "S C" , References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> Subject: Re: Strange, strange occurence Date: Tue, 13 Jul 2004 17:31:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Scanned-By: MIMEDefang 2.39 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: 5463 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: KevinK@mips.com Precedence: bulk X-list: linux-mips > > A truly safe and general I-cache flush routine should itself run uncached, > > but a cursory glance at the linux-mips.org sources makes me think > > that we do not take that precaution by default - the flush_icache_range > > pointer looks to be set to the address of r4k_flush_icache_range() > > function, rather than its (uncacheable) alias in kseg1. Is this something > > that's fixed in a linker script, or are we just living dangerously? > > That's a new restriction in MIPS32 v2.0 and you're right, we're not trying > to deal with it yet except for the TX49xx. I'm pretty sure that restriction is not new to MIPS32 v2.0. In any case, there are pre-MIPS32/MIPS64 chips in current mass production and use, under Linux among other OSes, which specify in their user manuals that one should not invalidate the Icache line from which one is currently executing. The clause about unpredictable behavior in that case went into the MIPS32 spec because it was known that such parts existed, and we wanted to make it as easy as possible for such designs to be made compliant Invalidating the entire Icache with a routine executing out of the Icache is a Bad Idea, and will almost certainly cause problems some of the time on some MIPS processors. Reasonable people could disagree on whether we want to handle that in the generic code, or create a variant icache flush routine which gets plugged in only for those parts that really need it. Regards, Kevin K. From ralf@linux-mips.org Tue Jul 13 20:30:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jul 2004 20:30:58 +0100 (BST) Received: from p508B6087.dip.t-dialin.net ([IPv6:::ffff:80.139.96.135]:5474 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 13 Jul 2004 20:30:53 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6DJTOik018348; Tue, 13 Jul 2004 21:29:24 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6DJTNHD018347; Tue, 13 Jul 2004 21:29:23 +0200 Date: Tue, 13 Jul 2004 21:29:23 +0200 From: Ralf Baechle To: Vadivelan Mani Cc: linux-mips@linux-mips.org Subject: Re: pci_alloc_consistent() usage Message-ID: <20040713192923.GA17250@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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: 5464 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 Tue, Jul 13, 2004 at 06:31:01PM +0530, Vadivelan Mani wrote: > I'm writing a wireless driver which requires 8 transmit and 8 receive > buffers each of size 3KB approx. I hope this device isn't really as simplistic as you make it sound ... > These buffers should be in dma capable space. > > I've allocated them using pci_alloc_consistent(). > > I've allocated 128KBytes just to make more space. I've got few doubts. > > 1. Can pci_alloc_consistent() be used to allocate memory upto 128KBytes? Yes. For MIPS MAX_ORDER defaults to 11 so you even do alloc_page (which is the underlying allocator of pci_alloc_consistent) upto 2^11 page that is 8MB. Downside - memory allocation is making such large allocations unreliable; the more unreliable the larger the allocation. In general try to stick to allocations of order 0 that is PAGE_SIZE which atm is 4k on MIPS. They're ok for permanent allocations such as rx/tx rings which only happen rarely. > 2.) I would also like to know the exact use of this allocated space to > transmit or receive a packet. pci_alloc_consistent() is meant to be used for permanent allocations such as rx/tx rings. It's not suitable for allocating skbufs; there are other mechanisms available for that. > During transmission i do the following. Plz correct me if i'm wrong because > i'm new to driver writing. > > The device has a register which should be loaded with the transmit buffers > starting address. > > I copy the packet coming from the Kernel in the form of sk_buff structure > into one of the transmit buffers that i've allocated using memcpy(). That's usually an idea only for very small packets. pci_alloc_consistent allocates uncached memory on a system withour hardware coherency so this copy operation would be very slow. In any case you should experiment to find the breakeven point. For larger packets you should use pci_map_single() in the start_xmit() method of the driver, then pci_unmap_single() later when cleaning that is typically in an interrupt handler. Reception of packets would work fairly similar. > And i set the register in the device to initiate transmission of the packet. > > Where does the dma transfer concept come in this? > There is no mention of the direction of data transfer in > pci_alloc_consistent(). pci_alloc_consistent will allocate consistent memory that is it's suitable for transfers in both directions. On the typical MIPS processor which doesn't maintain coherency in hardware this means it will return uncached memory. Obviously that will work for any direction of transfer. But: uncached memory is slow - so avoid copying packets there. > I also assumed that allocating buffer in dma capable space was itself > enough to start dma transfers. No. DMA capable space means some memory that can be accessed somehow by a DMA engine. You still have to tell the device to start the operation. > Since i do not have the device now i'm not able to test the code. But i > would like to write the code before i get the device. Ralf From collin@xorotude.com Wed Jul 14 07:58:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 07:58:46 +0100 (BST) Received: from eezi.conceptual.net.au ([IPv6:::ffff:203.190.192.22]:61588 "EHLO eezi.net.au") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 07:58:42 +0100 Received: from swift (203-190-195-081.dial.usertools.net [::ffff:203.190.195.81]) by eezi.net.au with esmtp; Wed, 14 Jul 2004 14:58:26 +0800 Message-ID: <000e01c4696f$f65cf4f0$0a9913ac@swift> From: "Collin Baillie" To: linux-mips@linux-mips.org References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> Subject: Re: Help with MOP network boot install on DECstation 5000/240 Date: Wed, 14 Jul 2004 14:57:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 5465 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: collin@xorotude.com Precedence: bulk X-list: linux-mips > [Thanks for *not* hijacking threads] Sorry *blush* > So it seems to try to get a file some times and gives up on it. Oh.. I think it asks for the file, but the mopd server is not sending it. I am only guessing though. > Maybe you'd try Debian's install image? Maybe, but on a _shared_ 31.2k dialup link, it takes a while to download... and other people tend to get upset... I am using jigdo to get the 4 - 6 ISO images.. if there's a better (smaller / faster to download) method, I'd love to hear about it. I really would like to get to know Debian as I'm a Slackware man and have had to use RedHat at work.. Debian would be another nice addition to my Linux skillset. > By the way, which mopd are you using? There are several of them around, > some quite unuseable... Umm.. 2.5.3. I downloaded one from linux-mips.org, and applied all the patches in the order listed in the spec file, but it doesn't compile. So I compiled another 2.5.3 (79k as opposed to the 48k tgz file I got from linux-mips.org) and it compiles and responds, but still no file transfer. (I am compiling/running on i386 arch, so I am wondering if all those patches are necessary...) I've read that MOP images usually have some special header in them (NetBSD website) and someone mentioned that mopd-linux will fudge those headers if the kernel doesn't have them... or something... I am perservering with it, and will eventually get there... but for now, I just thought someone might have more of a clue than I do. Thanks, Collin Baillie From maksik@gmx.co.uk Wed Jul 14 09:42:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 09:42:24 +0100 (BST) Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:37846 "EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 09:42:19 +0100 Received: from ktl77.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77]) by relay1.uniklinik-freiburg.de (Email) with ESMTP id 741422F3FB; Wed, 14 Jul 2004 10:42:14 +0200 (CEST) From: Max Zaitsev Organization: Mutella Dev co. To: linux-mips@linux-mips.org Subject: is there *any* way to boot IP32 from hard drive ? Date: Wed, 14 Jul 2004 10:42:18 +0200 User-Agent: KMail/1.6.2 Cc: Guido Guenther , Ilya Volynets , Kumba , Jan Seidel MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200407141042.18505.maksik@gmx.co.uk> 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: 5466 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: maksik@gmx.co.uk Precedence: bulk X-list: linux-mips Hi List, I've asked the very same question here before, but got no answer. Probably, the experts, who might have known the answer just overlooked it... (sorry guys for addressing some of you directly, but I'm really in trouble). The thing is that I desperately need to get the O2 to boot from its HDD, it's all installed and supposed to be used as a standalone box. I'm using kernel 2.6.6 with minimal patches from Ilya and as to be expected it does not boot from the volume header. Arcboot seems to be the way to go, but I'm not able to compile the bootable arcboot.IP32 image. When I've tried to self-compile it with gcc 3.3.3 the image size was over 500K and it did not do anything at all. Self-compilation with gcc 3.4 fails during linking. In a mean time I've extracted the binary arcboot.IP32 image from the debian package and this one at least does something: it loads the kernel into memory (goes very slow), recognises a 64-bit executable and even starts it... But immediately after the kernel crashes. Any idea why it could be happening? In some other thread, Ilya have mentioned, that he has a "highly hacked" version of arcboot. Is it available anywhere? Or are other other solutions? Thanks in advance, Max From macro@linux-mips.org Wed Jul 14 10:54:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 10:54:36 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:45003 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 10:54:30 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id CC97447B41; Wed, 14 Jul 2004 11:54:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id C0E4647AAC; Wed, 14 Jul 2004 11:54:23 +0200 (CEST) Date: Wed, 14 Jul 2004 11:54:23 +0200 (CEST) From: "Maciej W. Rozycki" To: Collin Baillie Cc: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 In-Reply-To: <000e01c4696f$f65cf4f0$0a9913ac@swift> Message-ID: References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> 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: 5467 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@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 14 Jul 2004, Collin Baillie wrote: > > So it seems to try to get a file some times and gives up on it. > > Oh.. I think it asks for the file, but the mopd server is not sending it. I > am only guessing though. It looks so. You may try to verify with `tcpdump', too. > > By the way, which mopd are you using? There are several of them around, > > some quite unuseable... > > Umm.. 2.5.3. I downloaded one from linux-mips.org, and applied all the > patches in the order listed in the spec file, but it doesn't compile. So I Hmm, there's no mopd at linux-mips.org. Do you refer to one at my site, i.e. "ftp://ftp.ds2.pg.gda.pl/pub/macro/"? If so, then please report compiler errors to me. > compiled another 2.5.3 (79k as opposed to the 48k tgz file I got from > linux-mips.org) and it compiles and responds, but still no file transfer. (I > am compiling/running on i386 arch, so I am wondering if all those patches > are necessary...) They are. They are not processor-dependent. > I've read that MOP images usually have some special header in them (NetBSD > website) and someone mentioned that mopd-linux will fudge those headers if > the kernel doesn't have them... or something... You've been misled. The MOP protocol sends raw data annotated with addresses. It's up to the MOP server to obtain both of them. For example they can be retrieved from ordinary ELF images. > I am perservering with it, and will eventually get there... but for now, I > just thought someone might have more of a clue than I do. Try running `mopchk ' to check if it's interpreted correctly. Maciej From macro@linux-mips.org Wed Jul 14 13:02:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 13:02:27 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:64971 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 13:02:22 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 990AE36DB2; Wed, 14 Jul 2004 14:02:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id B8A3235196; Wed, 14 Jul 2004 14:02:15 +0200 (CEST) Date: Wed, 14 Jul 2004 14:02:15 +0200 (CEST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" Cc: Ralf Baechle , S C , linux-mips@linux-mips.org Subject: Re: Strange, strange occurence In-Reply-To: <003301c468ee$80c5fa60$0deca8c0@Ulysses> Message-ID: References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <003301c468ee$80c5fa60$0deca8c0@Ulysses> 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: 5468 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@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 13 Jul 2004, Kevin D. Kissell wrote: > > That's a new restriction in MIPS32 v2.0 and you're right, we're not trying > > to deal with it yet except for the TX49xx. > > I'm pretty sure that restriction is not new to MIPS32 v2.0. In any The restriction was apparently added in revision 1.00 of the MIPS32 architecture vol.II document. I don't have that revision -- I have versions 0.95 and 2.00 only -- without looking at the revision history in 2.00 I'd expect the original MIPS32 spec not to enforce such a restriction, either. > case, there are pre-MIPS32/MIPS64 chips in current mass production > and use, under Linux among other OSes, which specify in their user > manuals that one should not invalidate the Icache line from which one > is currently executing. The clause about unpredictable behavior in > that case went into the MIPS32 spec because it was known that such > parts existed, and we wanted to make it as easy as possible for such > designs to be made compliant Ugh, although I can imagine valid arguments for such a decision. > Invalidating the entire Icache with a routine executing out of the Icache > is a Bad Idea, and will almost certainly cause problems some of the time > on some MIPS processors. Reasonable people could disagree on whether > we want to handle that in the generic code, or create a variant icache flush > routine which gets plugged in only for those parts that really need it. As executing code from an uncached space is terribly slow, there are at least two points of optimization: 1. The Icache invalidation handler should run cached on processors known to handle it gracefully. 2. For others, as you suggest, it should attempt to figure out whether its code may invalidate itself and run uncached then, perhaps for the problematic lines only. Maciej From jbglaw@dvmwest.gt.owl.de Wed Jul 14 13:43:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 13:43:25 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:27309 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 13:43:20 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 412764B71B; Wed, 14 Jul 2004 14:43:18 +0200 (CEST) Date: Wed, 14 Jul 2004 14:43:18 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 Message-ID: <20040714124318.GQ2019@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FmdPcZLZZW6lDAYm" Content-Disposition: inline In-Reply-To: <000e01c4696f$f65cf4f0$0a9913ac@swift> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6i 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: 5469 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --FmdPcZLZZW6lDAYm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2004-07-14 14:57:52 +0800, Collin Baillie wrote in message <000e01c4696f$f65cf4f0$0a9913ac@swift>: > > [Thanks for *not* hijacking threads] > > Maybe you'd try Debian's install image? >=20 > Maybe, but on a _shared_ 31.2k dialup link, it takes a while to download.= =2E. > and other people tend to get upset... I am using jigdo to get the 4 - 6 I= SO It's only a couple of megabytes, not a number of CD images. > I've read that MOP images usually have some special header in them (NetBSD > website) and someone mentioned that mopd-linux will fudge those headers if > the kernel doesn't have them... or something... Right, eg. Maciej's MOPD does that. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --FmdPcZLZZW6lDAYm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9SplHb1edYOZ4bsRArbnAJ95Lq0KBZFfoI/fSXFeQCt1jW4usgCfR5bs h18Nq15W9aCl+Fy8T66112w= =WaV8 -----END PGP SIGNATURE----- --FmdPcZLZZW6lDAYm-- From jbglaw@dvmwest.gt.owl.de Wed Jul 14 13:44:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 13:44:40 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:29613 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 13:44:36 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 585214B71B; Wed, 14 Jul 2004 14:44:35 +0200 (CEST) Date: Wed, 14 Jul 2004 14:44:35 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 Message-ID: <20040714124435.GR2019@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DzFMwNuU1QL7hgxO" Content-Disposition: inline In-Reply-To: X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6i 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: 5470 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --DzFMwNuU1QL7hgxO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2004-07-14 11:54:23 +0200, Maciej W. Rozycki wrote in message : > Hmm, there's no mopd at linux-mips.org. Do you refer to one at my site, > i.e. "ftp://ftp.ds2.pg.gda.pl/pub/macro/"? If so, then please report > compiler errors to me. While we are at it. I'll have to re-verify that, but my mopd is loosing file descriptors if you ^A-F your box during a load. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --DzFMwNuU1QL7hgxO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9SqyHb1edYOZ4bsRArC/AJ95evjRVsMngCivlArA47jsnLgWwwCfabHZ c/IUbzqfT3YXEGPd/yTbMqU= =z6qE -----END PGP SIGNATURE----- --DzFMwNuU1QL7hgxO-- From macro@linux-mips.org Wed Jul 14 13:51:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 13:51:45 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:4556 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 13:51:41 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 873D947AAC; Wed, 14 Jul 2004 14:51:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 73C4947777; Wed, 14 Jul 2004 14:51:35 +0200 (CEST) Date: Wed, 14 Jul 2004 14:51:35 +0200 (CEST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw Cc: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 In-Reply-To: <20040714124435.GR2019@lug-owl.de> Message-ID: References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124435.GR2019@lug-owl.de> 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: 5471 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@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 14 Jul 2004, Jan-Benedict Glaw wrote: > While we are at it. I'll have to re-verify that, but my mopd is loosing > file descriptors if you ^A-F your box during a load. Hmm, while I get what you mean, what is "^A-F" specifically? Anyway, this may be true -- probably the server is still waiting for following requests to come. A timeout might be a good thing to add. Unfortunately I don't have time to work on mopd ATM. It would be good to do a serious rewrite and I plan to do that in the future. No established plan, though. Another problem which is already known is mopd dying when one of interfaces it's listening on goes down. Maciej From jbglaw@dvmwest.gt.owl.de Wed Jul 14 14:30:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 14:30:45 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:60333 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 14:30:40 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id ABD524B7BD; Wed, 14 Jul 2004 15:30:39 +0200 (CEST) Date: Wed, 14 Jul 2004 15:30:39 +0200 From: Jan-Benedict Glaw To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 Message-ID: <20040714133039.GS2019@lug-owl.de> Mail-Followup-To: "Maciej W. Rozycki" , linux-mips@linux-mips.org References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124435.GR2019@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LmUdgXdNLPkN/XLh" Content-Disposition: inline In-Reply-To: X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6i 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: 5472 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --LmUdgXdNLPkN/XLh Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2004-07-14 14:51:35 +0200, Maciej W. Rozycki wrote in message : > On Wed, 14 Jul 2004, Jan-Benedict Glaw wrote: > > While we are at it. I'll have to re-verify that, but my mopd is loosing > > file descriptors if you ^A-F your box during a load. >=20 > Hmm, while I get what you mean, what is "^A-F" specifically? Sending a break from minicom :) That is, I just ask the MOP client to stop loading. > Anyway, this may be true -- probably the server is still waiting for > following requests to come. A timeout might be a good thing to add. =20 > Unfortunately I don't have time to work on mopd ATM. It would be good to > do a serious rewrite and I plan to do that in the future. No established= =20 > plan, though. Eventually I'll re-get all the sources and compile again. Adding a timeout shouldn't be all that hard. It should be a matter of extending the "connection" table by "last packet's recv/send time" and check this table entry upon each new request. > Another problem which is already known is mopd dying when one of > interfaces it's listening on goes down. Haven't seen that, but my interfaces tend to not go down (at least not until the whole machine goes down...). MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --LmUdgXdNLPkN/XLh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9TV/Hb1edYOZ4bsRAimRAKCBLdIZkrAEWyzx3vEWQ8GEJm9DTgCfa+pp TuGWCrJFrg4Z6LBJgeqVyRI= =P4E0 -----END PGP SIGNATURE----- --LmUdgXdNLPkN/XLh-- From a.voropay@vmb-service.ru Wed Jul 14 14:52:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 14:52:12 +0100 (BST) Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:58282 "EHLO smtp.vmb-service.ru") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 14:52:08 +0100 Received: from office.vmb-service.ru ([80.73.192.47]:54286 "EHLO ALEC") by Altair with ESMTP id ; Wed, 14 Jul 2004 17:52:05 +0400 Reply-To: From: "Alexander Voropay" To: Subject: MS VC++ compiler / MIPS Date: Wed, 14 Jul 2004 17:53:11 +0400 Organization: VMB-Service Message-ID: <07d301c469a9$e708f550$0200000a@ALEC> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: 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: 5473 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: a.voropay@vmb-service.ru Precedence: bulk X-list: linux-mips Hi! Is it possible to use it for the something useful ?? (to compie a kernel 8-)) As it is known, MS provides eMbedded Visual Tools 3.0 for free download. It contains a free C++ MIPS cross compiler . evt2002web_min.exe [210485 KB] ======================== C:\...ft eMbedded Tools\EVC\WCE300\BIN>CLMIPS.EXE /help Microsoft (R) 32-bit/16-bit C/C++ Optimizing Compiler Version 12.01.8667 for MIPS R-Series Copyright (C) Microsoft Corp 1984-1999. All rights reserved. [....] -CODE GENERATION- /QMRWCE optimize for WinCE (Default) /QMOb basic block threshold /QMR3900 optimize for r3900 /QMOu unroll n loop iterations /QMR4100 optimize for r4100 /QMFPE[-] FP emulation (default) /QMR4200 optimize for r4200 /Gd __cdecl calling convention /QMR4300 optimize for r4300 /GA optimize for Windows Application /QMmips16 code for MIPS16 ASE /GD optimize for Windows DLL /QMmips1 MIPS1 ISA /Gr __fastcall calling convention /QMmips2 MIPS2 ISA (default) /Gf enable string pooling /QMNoDivCheck no divide by zero check /GF enable read-only string pooling /QMNoUnalign no LWL,LWR,SWL,SWR /Gh enable hook function call /QMNoULoad do not generate LWL,LWR /GR[-] enable C++ RTTI /QMNoUStore do not generate SWL,SWR /Gy separate functions for linker /QMOC use old float comparison helpers [....] -- -=AV=- From heinold@physik.tu-cottbus.de Wed Jul 14 15:05:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 15:05:35 +0100 (BST) Received: from flood.physik.TU-Cottbus.De ([IPv6:::ffff:141.43.75.21]:44676 "EHLO flood.physik.tu-cottbus.de") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 15:05:30 +0100 Received: from storm.physik.tu-cottbus.de (storm.physik.tu-cottbus.de [141.43.75.8]) by flood.physik.tu-cottbus.de (Postfix) with ESMTP id 106B5701E00 for ; Wed, 14 Jul 2004 16:05:29 +0200 (CEST) Received: by storm.physik.tu-cottbus.de (Postfix, from userid 7215) id 5C91AF9BE; Wed, 14 Jul 2004 16:05:26 +0200 (CEST) Date: Wed, 14 Jul 2004 16:05:26 +0200 To: "To:linux-mips"@linux-mips.org Subject: Re: MS VC++ compiler / MIPS Message-ID: <20040714140526.GA30331@physik.tu-cottbus.de> Mail-Followup-To: heinold@physik.tu-cottbus.de, "To:linux-mips"@linux-mips.org References: <07d301c469a9$e708f550$0200000a@ALEC> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07d301c469a9$e708f550$0200000a@ALEC> User-Agent: Mutt/1.3.28i From: heinold@physik.tu-cottbus.de (H.Heinold) 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: 5474 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: heinold@physik.tu-cottbus.de Precedence: bulk X-list: linux-mips Hi, look at which prozessors are supported, mainly embbeded devices and why should it useful for linux. -- Bye Henning From geert@linux-m68k.org Wed Jul 14 15:10:03 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 15:10:10 +0100 (BST) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:22691 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 15:10:03 +0100 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i6EEA2XK029676; Wed, 14 Jul 2004 16:10:02 +0200 (MEST) Date: Wed, 14 Jul 2004 16:10:01 +0200 (MEST) From: Geert Uytterhoeven To: Alexander Voropay cc: Linux/MIPS Development Subject: Re: MS VC++ compiler / MIPS In-Reply-To: <07d301c469a9$e708f550$0200000a@ALEC> Message-ID: References: <07d301c469a9$e708f550$0200000a@ALEC> 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: 5475 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: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Wed, 14 Jul 2004, Alexander Voropay wrote: > Is it possible to use it for the something useful ?? > (to compie a kernel 8-)) If `kernel' stands for `Linux kernel', most probably not. > As it is known, MS provides eMbedded Visual Tools 3.0 > for free download. It contains a free C++ MIPS cross compiler . Whether it's `free' or not, depends on your definition of `free'... > evt2002web_min.exe [210485 KB] A filename that ends in `*.exe'.... What's that? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From kevink@mips.com Wed Jul 14 16:03:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 16:03:28 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:31175 "EHLO dns0.mips.com") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 16:03:23 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id i6EF3Eko010422; Wed, 14 Jul 2004 08:03:14 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i6EF3CWR021983; Wed, 14 Jul 2004 08:03:13 -0700 (PDT) Message-ID: <003001c469b4$3b5ae960$10eca8c0@grendel> From: "Kevin D. Kissell" To: , References: <07d301c469a9$e708f550$0200000a@ALEC> Subject: Re: MS VC++ compiler / MIPS Date: Wed, 14 Jul 2004 17:07:06 +0200 Organization: MIPS Technologies Inc. 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.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.39 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: 5476 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: kevink@mips.com Precedence: bulk X-list: linux-mips If I recall correctly, the MS compiler uses a subltly different calling convention/ABI than the "o32" gcc conventions assumed by MIPS Linux, and certainly the assembler directives will be different from those assumed by the Linux sources. It *might* be possible to hack up a MIPS Linux kernel source tree to build with the MS tool kit, but it would be a lot of work, some of it subtle. Regards, Kevin K. From dom@mips.com Wed Jul 14 17:35:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 17:35:47 +0100 (BST) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:62220 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 17:35:38 +0100 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1BkmvQ-0007Vc-00; Wed, 14 Jul 2004 17:48:08 +0100 Received: from arsenal.mips.com ([192.168.192.197]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Bkmj2-0007aP-00; Wed, 14 Jul 2004 17:35:20 +0100 Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian)) id 1Bkmj2-0006WL-00; Wed, 14 Jul 2004 17:35:20 +0100 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16629.24775.778491.754688@arsenal.mips.com> Date: Wed, 14 Jul 2004 17:35:19 +0100 To: Ralf Baechle Cc: "Kevin D. Kissell" , S C , linux-mips@linux-mips.org Subject: Re: Strange, strange occurence In-Reply-To: <20040713003317.GA26715@linux-mips.org> References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.848, required 4, AWL, BAYES_00) 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: 5477 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: dom@mips.com Precedence: bulk X-list: linux-mips Ralf Baechle (ralf@linux-mips.org) writes: > > A truly safe and general I-cache flush routine should itself run > > uncached... It depends what you mean by general, and uncached is not the only option. The spec says: "The operation of the instruction is UNPREDICTABLE if the cache line that contains the CACHE instruction is the target of an invalidate..." If you use hit-type cache operations in a kernel routine, then you're safe. I can't envisage any circumstance in which Linux would try to invalidate kernel mainline code locations from the I-cache (well, you might be doing something fabulous with debugging the kernel, but that's not normal and you'd hardly expect to be able to support such an activity with standard cache management calls). So this problem can only arise on index-type I-cache invalidation. I claim that a running kernel on a MIPS CPU should only use index-type invalidation when it is necessary to invalidate the entire I-cache. (If you use index-type operations for a range which doesn't resolve to "the whole cache" then that should be fixed). That implies that a MIPS32-paranoid "invalidate-whole-I-cache" routine should: 1. Identify which indexes might alias to cache lines containing the routines's own 'cache invalidate' instruction(s), and thus hit the problem. There won't be that many of them. 2. Arrange to skip those indexes when zapping the cache, then do something weird to invalidate that handful of lines. You could do that by running uncached, but you could also do it just by using some auxiliary routine which is known to be more than a cache line but much less than a whole I-cache span distant, so can't possibly alias to the same thing... This is fiddly, but not terribly difficult and should have a negligible performance impact. Does that make sense? Am I now, having named the solution, responsible for figuring out a patch (yeuch, I never wanted to be a kernel programmer again...). -- Dominic Sweetman MIPS Technologies From a.voropay@vmb-service.ru Wed Jul 14 18:31:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 18:31:26 +0100 (BST) Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:16092 "EHLO smtp.vmb-service.ru") by linux-mips.org with ESMTP id ; Wed, 14 Jul 2004 18:31:21 +0100 Received: from office.vmb-service.ru ([80.73.192.47]:40454 "EHLO ALEC") by Altair with ESMTP id ; Wed, 14 Jul 2004 21:31:16 +0400 Reply-To: From: "Alexander Voropay" To: "'Kevin D. Kissell'" , Subject: RE: MS VC++ compiler / MIPS Date: Wed, 14 Jul 2004 21:32:23 +0400 Organization: VMB-Service Message-ID: <07f501c469c8$85f86240$0200000a@ALEC> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <003001c469b4$3b5ae960$10eca8c0@grendel> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: 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: 5478 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: a.voropay@vmb-service.ru Precedence: bulk X-list: linux-mips Kevin D. Kissell [mailto:kevink@mips.com] wrote: >If I recall correctly, the MS compiler uses a subltly different calling convention/ABI >than the "o32" gcc conventions assumed by MIPS Linux, The ABI is identical if the number of the int arguments <=4 (n1-> $4, n2 -> $5, n3 -> $6, n4 -> $7) (return value --> $2) It should be enought for simply functions. Otherwise, the MSVC/MIPS does not use $fp, so stack frame structure seems different. MSVC/MIPS supports 2 calling conventions (/Gd __cdecl calling convention; /Gr __fastcall calling convention) but I can't grok a difference. > and certainly the assembler directives will be different from those assumed by the Linux sources. Yes. It sems, it is impossible to build a full Linux toolcain at the MSVC base. The MS linker (LINK.EXE) is weak (comparing to `ld` monster) and can produce only COFF .EXE (a.out) MIPS executables. > It *might* be possible to hack up a MIPS Linux kernel source tree to build with the MS >tool kit, but it would be a lot of work, some of it subtle. I have no plans to do it, I'm not a MIPS guru :) -- -=AV=- From uhler@mips.com Wed Jul 14 18:49:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jul 2004 18:49:15 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:63448 "EHLO dns0.mips.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Wed, 14 Jul 2004 18:49:09 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id i6EHj9UX011470; Wed, 14 Jul 2004 10:45:09 -0700 (PDT) Received: from laptopuhler ([192.168.1.193]) by mercury.mips.com (8.12.11/8.12.11) with ESMTP id i6EHixx9007630; Wed, 14 Jul 2004 10:45:03 -0700 (PDT) From: "Michael Uhler" To: "'Dominic Sweetman'" , "'Ralf Baechle'" Cc: "'Kevin D. Kissell'" , "'S C'" , Subject: RE: Strange, strange occurence Date: Wed, 14 Jul 2004 10:45:15 -0700 Organization: MIPS Technologies, Inc. Message-ID: <001101c469ca$573be5b0$4001a8c0@MIPS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <16629.24775.778491.754688@arsenal.mips.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Scanned-By: MIMEDefang 2.39 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: 5479 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: uhler@mips.com Precedence: bulk X-list: linux-mips Dom's proposed solution is probably the right thing to do. We've got some code in MIPS that does exactly this, and I've suggested that we convert this to provide to the Linux community. /gmu --- Michael Uhler, Chief Technology Officer MIPS Technologies, Inc. Email: uhler@mips.com 1225 Charleston Road Voice: (650)567-5025 FAX: (650)567-5225 Mountain View, CA 94043 Mobile: (650)868-6870 Admin: (650)567-5085 > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of > Dominic Sweetman > Sent: Wednesday, July 14, 2004 9:35 AM > To: Ralf Baechle > Cc: Kevin D. Kissell; S C; linux-mips@linux-mips.org > Subject: Re: Strange, strange occurence > > > > Ralf Baechle (ralf@linux-mips.org) writes: > > > > A truly safe and general I-cache flush routine should itself run > > > uncached... > > It depends what you mean by general, and uncached is not the > only option. The spec says: > > "The operation of the instruction is UNPREDICTABLE if the cache line > that contains the CACHE instruction is the target of an > invalidate..." > > If you use hit-type cache operations in a kernel routine, > then you're safe. I can't envisage any circumstance in which > Linux would try to invalidate kernel mainline code locations > from the I-cache (well, you might be doing something fabulous > with debugging the kernel, but that's not normal and you'd > hardly expect to be able to support such an activity with > standard cache management calls). > > So this problem can only arise on index-type I-cache > invalidation. I claim that a running kernel on a MIPS CPU > should only use index-type invalidation when it is necessary > to invalidate the entire I-cache. (If you use index-type > operations for a range which doesn't resolve to "the whole > cache" then that should be fixed). > > That implies that a MIPS32-paranoid "invalidate-whole-I-cache" routine > should: > > 1. Identify which indexes might alias to cache lines > containing the routines's own 'cache invalidate' instruction(s), > and thus hit the problem. There won't be that many of them. > > 2. Arrange to skip those indexes when zapping the cache, then do > something weird to invalidate that handful of lines. You could > do that by running uncached, but you could also do it just by using > some auxiliary routine which is known to be more than a cache line > but much less than a whole I-cache span distant, so can't possibly > alias to the same thing... > > This is fiddly, but not terribly difficult and should have a > negligible performance impact. > > Does that make sense? Am I now, having named the solution, > responsible for figuring out a patch (yeuch, I never wanted > to be a kernel programmer again...). > > -- > Dominic Sweetman > MIPS Technologies > > From ralf@linux-mips.org Thu Jul 15 01:24:58 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jul 2004 01:25:02 +0100 (BST) Received: from p508B68D1.dip.t-dialin.net ([IPv6:::ffff:80.139.104.209]:23155 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 15 Jul 2004 01:24:58 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6F0Ou7B025329; Thu, 15 Jul 2004 02:24:56 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6F0OsU9025328; Thu, 15 Jul 2004 02:24:54 +0200 Date: Thu, 15 Jul 2004 02:24:54 +0200 From: Ralf Baechle To: Alexander Voropay Cc: "'Kevin D. Kissell'" , linux-mips@linux-mips.org Subject: Re: MS VC++ compiler / MIPS Message-ID: <20040715002454.GA25279@linux-mips.org> References: <003001c469b4$3b5ae960$10eca8c0@grendel> <07f501c469c8$85f86240$0200000a@ALEC> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07f501c469c8$85f86240$0200000a@ALEC> User-Agent: Mutt/1.4.1i 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: 5480 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, Jul 14, 2004 at 09:32:23PM +0400, Alexander Voropay wrote: > MSVC/MIPS supports 2 calling conventions (/Gd __cdecl calling > convention; > /Gr __fastcall calling convention) but I can't grok a difference. Probably more argument registers etc. I'd expect something along the NABI callign conventions. > > and certainly the assembler directives will be different from those > assumed by the Linux sources. > > Yes. > > It sems, it is impossible to build a full Linux toolcain at the MSVC > base. The MS linker > (LINK.EXE) is weak (comparing to `ld` monster) and can produce only COFF > .EXE (a.out) > MIPS executables. PECOFF, Microsoft's ECOFF variant which basically is ECOFF plus an MSDOS executable header. Yes, we all run MSDOS on our MIPS boxes so that's and important feature ;-) Ralf From ralf@linux-mips.org Thu Jul 15 01:39:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jul 2004 01:39:19 +0100 (BST) Received: from p508B68D1.dip.t-dialin.net ([IPv6:::ffff:80.139.104.209]:35443 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 15 Jul 2004 01:39:15 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6F0dEk0025682; Thu, 15 Jul 2004 02:39:14 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6F0dEQI025681; Thu, 15 Jul 2004 02:39:14 +0200 Date: Thu, 15 Jul 2004 02:39:14 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: a.voropay@vmb-service.ru, linux-mips@linux-mips.org Subject: Re: MS VC++ compiler / MIPS Message-ID: <20040715003914.GB25279@linux-mips.org> References: <07d301c469a9$e708f550$0200000a@ALEC> <003001c469b4$3b5ae960$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003001c469b4$3b5ae960$10eca8c0@grendel> User-Agent: Mutt/1.4.1i 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: 5481 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, Jul 14, 2004 at 05:07:06PM +0200, Kevin D. Kissell wrote: > If I recall correctly, the MS compiler uses a subltly different > calling convention/ABI than the "o32" gcc conventions assumed > by MIPS Linux, and certainly the assembler directives will be > different from those assumed by the Linux sources. It *might* > be possible to hack up a MIPS Linux kernel source tree to > build with the MS tool kit, but it would be a lot of work, > some of it subtle. A few years ago we got SGI's IA-64 kernel to compile with their Pro64 compiler. Despite the usually rather dramatic superiority of Pro64's code generation compared to the gcc of that time - half the time to generate twice as fast application code was common - the huge effort it took was essentially wasted time to achieve a hard to meassure amount of extra performance. Most of the kernel code is well optimized, was written with being compiled by gcc in mind and performance is more limited by the hardware and kernel algorithms than by the compiler's code generation. So I wouldn't invest any time into trying to get the kernel working on yet another non-gcc compiler ... Ralf From anemo@mba.ocn.ne.jp Thu Jul 15 02:34:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jul 2004 02:34:44 +0100 (BST) Received: from [IPv6:::ffff:202.230.225.5] ([IPv6:::ffff:202.230.225.5]:61725 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Thu, 15 Jul 2004 02:34:38 +0100 Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 15 Jul 2004 01:34:37 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by newms.toshiba-tops.co.jp (Postfix) with ESMTP id 721E1239E50; Thu, 15 Jul 2004 10:36:39 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i6F1YSwB080186; Thu, 15 Jul 2004 10:34:28 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 15 Jul 2004 10:34:44 +0900 (JST) Message-Id: <20040715.103444.70224080.nemoto@toshiba-tops.co.jp> To: dom@mips.com Cc: ralf@linux-mips.org, KevinK@mips.com, theansweriz42@hotmail.com, linux-mips@linux-mips.org Subject: Re: Strange, strange occurence From: Atsushi Nemoto In-Reply-To: <16629.24775.778491.754688@arsenal.mips.com> References: <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <16629.24775.778491.754688@arsenal.mips.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F Organization: TOSHIBA Personal Computer System Corporation X-Mailer: Mew version 3.3 on Emacs 21.2 / Mule 5.0 (SAKAKI) 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: 5482 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: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Wed, 14 Jul 2004 17:35:19 +0100, Dominic Sweetman said: dom> 2. Arrange to skip those indexes when zapping the cache, then do dom> something weird to invalidate that handful of lines. You could dom> do that by running uncached, but you could also do it just by dom> using some auxiliary routine which is known to be more than a dom> cache line but much less than a whole I-cache span distant, so dom> can't possibly alias to the same thing... dom> This is fiddly, but not terribly difficult and should have a dom> negligible performance impact. Yes. The cache routines for TX49XX surely do it (2 phase invalidating). Please look at tx49_blast_icache32() in c-r4k.c. --- Atsushi Nemoto From ralf@linux-mips.org Thu Jul 15 02:53:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jul 2004 02:53:38 +0100 (BST) Received: from p508B68D1.dip.t-dialin.net ([IPv6:::ffff:80.139.104.209]:24180 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 15 Jul 2004 02:53:34 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6F1rUg8027469; Thu, 15 Jul 2004 03:53:30 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6F1rSst027468; Thu, 15 Jul 2004 03:53:28 +0200 Date: Thu, 15 Jul 2004 03:53:28 +0200 From: Ralf Baechle To: Dominic Sweetman Cc: "Kevin D. Kissell" , S C , linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Message-ID: <20040715015328.GA26425@linux-mips.org> References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <16629.24775.778491.754688@arsenal.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16629.24775.778491.754688@arsenal.mips.com> User-Agent: Mutt/1.4.1i 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: 5483 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, Jul 14, 2004 at 05:35:19PM +0100, Dominic Sweetman wrote: > If you use hit-type cache operations in a kernel routine, then you're > safe. I can't envisage any circumstance in which Linux would try to > invalidate kernel mainline code locations from the I-cache (well, you > might be doing something fabulous with debugging the kernel, but > that's not normal and you'd hardly expect to be able to support such > an activity with standard cache management calls). > > So this problem can only arise on index-type I-cache invalidation. I > claim that a running kernel on a MIPS CPU should only use index-type > invalidation when it is necessary to invalidate the entire I-cache. > (If you use index-type operations for a range which doesn't resolve to > "the whole cache" then that should be fixed). > > That implies that a MIPS32-paranoid "invalidate-whole-I-cache" routine > should: > > 1. Identify which indexes might alias to cache lines > containing the routines's own 'cache invalidate' instruction(s), > and thus hit the problem. There won't be that many of them. > > 2. Arrange to skip those indexes when zapping the cache, then do > something weird to invalidate that handful of lines. You could > do that by running uncached, but you could also do it just by using > some auxiliary routine which is known to be more than a cache line > but much less than a whole I-cache span distant, so can't possibly > alias to the same thing... > > This is fiddly, but not terribly difficult and should have a > negligible performance impact. > > Does that make sense? Am I now, having named the solution, > responsible for figuring out a patch (yeuch, I never wanted to be a > kernel programmer again...). You don't have to :-) What became a architectural restriction for MIPS32 did already show up earlier as an erratum for the TX49/H2 core. This is the solution which we currently have in the kernel code: #define JUMP_TO_ALIGN(order) \ __asm__ __volatile__( \ "b\t1f\n\t" \ ".align\t" #order "\n\t" \ "1:\n\t" \ ) #define CACHE32_UNROLL32_ALIGN JUMP_TO_ALIGN(10) /* 32 * 32 = 1024 */ #define CACHE32_UNROLL32_ALIGN2 JUMP_TO_ALIGN(11) static inline void mips32_blast_icache32(void) { unsigned long start = INDEX_BASE; unsigned long end = start + current_cpu_data.icache.waysize; unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit; unsigned long ws_end = current_cpu_data.icache.ways << current_cpu_data.icache.waybit; unsigned long ws, addr; CACHE32_UNROLL32_ALIGN2; /* I'm in even chunk. blast odd chunks */ for (ws = 0; ws < ws_end; ws += ws_inc) for (addr = start + 0x400; addr < end; addr += 0x400 * 2) cache32_unroll32(addr|ws,Index_Invalidate_I); CACHE32_UNROLL32_ALIGN; /* I'm in odd chunk. blast even chunks */ for (ws = 0; ws < ws_end; ws += ws_inc) for (addr = start; addr < end; addr += 0x400 * 2) cache32_unroll32(addr|ws,Index_Invalidate_I); } All it takes is using this for all MIPS32 / MIPS64 or maybe even all processors and some tuning of constants to make this suitable for all possible I-cache configurations. Ralf From macro@linux-mips.org Thu Jul 15 12:33:24 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jul 2004 12:33:29 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:59600 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 15 Jul 2004 12:33:24 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 989A847A65; Thu, 15 Jul 2004 13:33:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 851224787C; Thu, 15 Jul 2004 13:33:17 +0200 (CEST) Date: Thu, 15 Jul 2004 13:33:17 +0200 (CEST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw Cc: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 In-Reply-To: <20040714133039.GS2019@lug-owl.de> Message-ID: References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124435.GR2019@lug-owl.de> <20040714133039.GS2019@lug-owl.de> 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: 5484 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@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 14 Jul 2004, Jan-Benedict Glaw wrote: > Eventually I'll re-get all the sources and compile again. Adding a > timeout shouldn't be all that hard. It should be a matter of extending > the "connection" table by "last packet's recv/send time" and check this > table entry upon each new request. But you probably have to take resumption into account -- a client may restart sending requests from the point it stopped. It may happen after a link is restored somewhere on the way after a break, for example. Though I haven't checked if there's any timeout defined in the MOP spec or imposed by specific MOP download clients -- perhaps there is. > > Another problem which is already known is mopd dying when one of > > interfaces it's listening on goes down. > > Haven't seen that, but my interfaces tend to not go down (at least not > until the whole machine goes down...). Mine tend to do that after I do `ifconfig down', which is what I sometimes do. I need to remember to restart mopd then. Perhaps mopd should monitor interfaces appearing and disappearing in general, taking the restriction on the command line into account, of course. Maciej From wsonguci@yahoo.com Thu Jul 15 23:22:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jul 2004 23:22:46 +0100 (BST) Received: from web40007.mail.yahoo.com ([IPv6:::ffff:66.218.78.25]:44198 "HELO web40007.mail.yahoo.com") by linux-mips.org with SMTP id ; Thu, 15 Jul 2004 23:22:41 +0100 Message-ID: <20040715222234.16094.qmail@web40007.mail.yahoo.com> Received: from [63.87.1.243] by web40007.mail.yahoo.com via HTTP; Thu, 15 Jul 2004 15:22:34 PDT Date: Thu, 15 Jul 2004 15:22:34 -0700 (PDT) From: Song Wang Subject: asm-mips/processor.h breaks compiling user applications such as iptables 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: 5485 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: wsonguci@yahoo.com Precedence: bulk X-list: linux-mips Hi, Ralf I am building the latest iptables-1.2.11 against linux-mips kernel 2.6.6. When compiling extensions/libipt_state.c #mips-linux-uclibc-gcc -s -Os -Wall -Wunused -I/mipslinux2.6.6/linux/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.11\" -DNO_SHARED_LIBS=1 -D_INIT=ipt_state_init -c -o extensions/libipt_state.o extensions/libipt_state.c I got error In file included from /mipslinux2.6.6/linux/include/linux/spinlock.h:16, from /mipslinux2.6.6/linux/include/asm/atomic.h:21, from /mipslinux2.6.6/linux/include/linux/netfilter_ipv4/ip_conntrack.h:11, from extensions/libipt_state.c:8: /mipslinux2.6.6/linux/include/asm/processor.h:146: error: parse error before "fpureg_t" /mipslinux2.6.6/linux/include/asm/processor.h:146: warning: type defaults to `int' in declaration of `fpureg_t' /mipslinux2.6.6/linux/include/asm/processor.h:146: warning: data definition has no type or storage class /mipslinux2.6.6/linux/include/asm/processor.h:149: error: parse error before "fpureg_t" /mipslinux2.6.6/linux/include/asm/processor.h:149: warning: no semicolon at end of struct or union /mipslinux2.6.6/linux/include/asm/processor.h:151: error: parse error before '}' token /mipslinux2.6.6/linux/include/asm/processor.h:161: error: parse error before "fpureg_t" /mipslinux2.6.6/linux/include/asm/processor.h:161: warning: no semicolon at end of struct or union /mipslinux2.6.6/linux/include/asm/processor.h:163: error: parse error before '}' token /mipslinux2.6.6/linux/include/asm/processor.h:166: error: field `hard' has incomplete type /mipslinux2.6.6/linux/include/asm/processor.h:167: error: field `soft' has incomplete type make[1]: *** [extensions/libipt_state.o] Error 1 I think the error is due to the line 146 typedef u64 fpureg_t; The type 'u64' is defined in asm-mips/types.h, but wrapped by #ifdef __KERNEL__, so when the compiler compiles the user-level application, it cannot recognize u64. -Song __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From ralf@linux-mips.org Thu Jul 15 23:56:59 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jul 2004 23:57:03 +0100 (BST) Received: from p508B70D0.dip.t-dialin.net ([IPv6:::ffff:80.139.112.208]:58661 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 15 Jul 2004 23:56:59 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6FMuwVH032434; Fri, 16 Jul 2004 00:56:58 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6FMuvf4032433; Fri, 16 Jul 2004 00:56:57 +0200 Date: Fri, 16 Jul 2004 00:56:57 +0200 From: Ralf Baechle To: Song Wang Cc: linux-mips@linux-mips.org Subject: Re: asm-mips/processor.h breaks compiling user applications such as iptables Message-ID: <20040715225657.GA17585@linux-mips.org> References: <20040715222234.16094.qmail@web40007.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040715222234.16094.qmail@web40007.mail.yahoo.com> User-Agent: Mutt/1.4.1i 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: 5486 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, Jul 15, 2004 at 03:22:34PM -0700, Song Wang wrote: > I think the error is due to the line 146 > > typedef u64 fpureg_t; > > The type 'u64' is defined in asm-mips/types.h, but > wrapped by #ifdef __KERNEL__, so when the compiler > compiles the user-level application, it cannot > recognize u64. Correct. In general the policy is to avoid the use of kernel header files in user space and copy it but there are still a few crucial tools that don't follow this rule of Linus, so try below patch. It also removes the __KERNEL__ things left. Cleaning up the use of kernel header to make them more usable for userspace is one of the things on the agenda for 2.7. It'll be alot of hard and boring work but MIPS will be one of the architectures that will greatly benefit from this. Ralf Index: include/asm-mips/processor.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/processor.h,v retrieving revision 1.94 diff -u -r1.94 processor.h --- include/asm-mips/processor.h 28 Jun 2004 21:04:16 -0000 1.94 +++ include/asm-mips/processor.h 15 Jul 2004 22:42:29 -0000 @@ -143,7 +143,7 @@ #define NUM_FPU_REGS 32 -typedef u64 fpureg_t; +typedef __u64 fpureg_t; struct mips_fpu_hard_struct { fpureg_t fpr[NUM_FPU_REGS]; @@ -235,8 +235,6 @@ MF_FIXADE, 0, 0 \ } -#ifdef __KERNEL__ - struct task_struct; /* Free all resources held by a thread. */ @@ -264,8 +262,6 @@ #define cpu_relax() barrier() -#endif /* __KERNEL__ */ - /* * Return_address is a replacement for __builtin_return_address(count) * which on certain architectures cannot reasonably be implemented in GCC From wsonguci@yahoo.com Fri Jul 16 03:01:54 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 03:02:00 +0100 (BST) Received: from web40005.mail.yahoo.com ([IPv6:::ffff:66.218.78.23]:59499 "HELO web40005.mail.yahoo.com") by linux-mips.org with SMTP id ; Fri, 16 Jul 2004 03:01:54 +0100 Message-ID: <20040716020147.71295.qmail@web40005.mail.yahoo.com> Received: from [63.87.1.243] by web40005.mail.yahoo.com via HTTP; Thu, 15 Jul 2004 19:01:47 PDT Date: Thu, 15 Jul 2004 19:01:47 -0700 (PDT) From: Song Wang Subject: Re: asm-mips/processor.h breaks compiling user applications such as iptables To: Ralf Baechle Cc: linux-mips@linux-mips.org In-Reply-To: <20040715225657.GA17585@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: 5487 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: wsonguci@yahoo.com Precedence: bulk X-list: linux-mips --- Ralf Baechle wrote: > On Thu, Jul 15, 2004 at 03:22:34PM -0700, Song Wang > wrote: > > > I think the error is due to the line 146 > > > > typedef u64 fpureg_t; > > > > The type 'u64' is defined in asm-mips/types.h, but > > wrapped by #ifdef __KERNEL__, so when the compiler > > compiles the user-level application, it cannot > > recognize u64. > > Correct. In general the policy is to avoid the use > of kernel header > files in user space and copy it but there are still > a few crucial tools > that don't follow this rule of Linus, so try below > patch. It also > removes the __KERNEL__ things left. > > Cleaning up the use of kernel header to make them > more usable for > userspace is one of the things on the agenda for > 2.7. It'll be alot of > hard and boring work but MIPS will be one of the > architectures that will > greatly benefit from this. > > Ralf > Hi, Ralf I tested the patch and it compiles fine now, although when iptables actually runs on mips32, all the tcp/udp port numbers are shown as 0 and IP address shown as 0.0.0.0. I'll dig more. Anyway, you made a good point for kernel headers problem. It's kinda headache. Similar problem happened to asm-mips/page.h when including in 2.6.6, but it seemed that you already fixed in the latest cvs version. Thanks. -Song __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From ralf@linux-mips.org Fri Jul 16 13:24:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 13:24:21 +0100 (BST) Received: from p508B5A48.dip.t-dialin.net ([IPv6:::ffff:80.139.90.72]:12115 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 13:24:16 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6GCO9xd021603; Fri, 16 Jul 2004 14:24:09 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6GCO9TY021602; Fri, 16 Jul 2004 14:24:09 +0200 Date: Fri, 16 Jul 2004 14:24:09 +0200 From: Ralf Baechle To: Dominic Sweetman Cc: "Kevin D. Kissell" , S C , linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Message-ID: <20040716122409.GA19192@linux-mips.org> References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <16629.24775.778491.754688@arsenal.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16629.24775.778491.754688@arsenal.mips.com> User-Agent: Mutt/1.4.1i 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: 5488 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, Jul 14, 2004 at 05:35:19PM +0100, Dominic Sweetman wrote: > This is fiddly, but not terribly difficult and should have a > negligible performance impact. > > Does that make sense? Am I now, having named the solution, > responsible for figuring out a patch (yeuch, I never wanted to be a > kernel programmer again...). No and yes - but here is a simpler solution. Below patch solves the problem and adds just 32 bytes of code but removes the special case for TX49/H2 entirely. Ralf arch/mips/mm/c-r4k.c | 59 -------------------------------------------- include/asm-mips/r4kcache.h | 18 ++++++++----- include/asm-mips/war.h | 14 ---------- 3 files changed, 13 insertions(+), 78 deletions(-) Index: arch/mips/mm/c-r4k.c =================================================================== RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.88 diff -u -r1.88 c-r4k.c --- arch/mips/mm/c-r4k.c 16 Jul 2004 12:06:13 -0000 1.88 +++ arch/mips/mm/c-r4k.c 16 Jul 2004 12:17:05 -0000 @@ -96,16 +96,6 @@ r4k_blast_dcache = blast_dcache32; } -/* force code alignment (used for TX49XX_ICACHE_INDEX_INV_WAR) */ -#define JUMP_TO_ALIGN(order) \ - __asm__ __volatile__( \ - "b\t1f\n\t" \ - ".align\t" #order "\n\t" \ - "1:\n\t" \ - ) -#define CACHE32_UNROLL32_ALIGN JUMP_TO_ALIGN(10) /* 32 * 32 = 1024 */ -#define CACHE32_UNROLL32_ALIGN2 JUMP_TO_ALIGN(11) - static inline void blast_r4600_v1_icache32(void) { unsigned long flags; @@ -115,27 +105,6 @@ local_irq_restore(flags); } -static inline void tx49_blast_icache32(void) -{ - unsigned long start = INDEX_BASE; - unsigned long end = start + current_cpu_data.icache.waysize; - unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit; - unsigned long ws_end = current_cpu_data.icache.ways << - current_cpu_data.icache.waybit; - unsigned long ws, addr; - - CACHE32_UNROLL32_ALIGN2; - /* I'm in even chunk. blast odd chunks */ - for (ws = 0; ws < ws_end; ws += ws_inc) - for (addr = start + 0x400; addr < end; addr += 0x400 * 2) - cache32_unroll32(addr|ws,Index_Invalidate_I); - CACHE32_UNROLL32_ALIGN; - /* I'm in odd chunk. blast even chunks */ - for (ws = 0; ws < ws_end; ws += ws_inc) - for (addr = start; addr < end; addr += 0x400 * 2) - cache32_unroll32(addr|ws,Index_Invalidate_I); -} - static inline void blast_icache32_r4600_v1_page_indexed(unsigned long page) { unsigned long flags; @@ -145,27 +114,6 @@ local_irq_restore(flags); } -static inline void tx49_blast_icache32_page_indexed(unsigned long page) -{ - unsigned long start = page; - unsigned long end = start + PAGE_SIZE; - unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit; - unsigned long ws_end = current_cpu_data.icache.ways << - current_cpu_data.icache.waybit; - unsigned long ws, addr; - - CACHE32_UNROLL32_ALIGN2; - /* I'm in even chunk. blast odd chunks */ - for (ws = 0; ws < ws_end; ws += ws_inc) - for (addr = start + 0x400; addr < end; addr += 0x400 * 2) - cache32_unroll32(addr|ws,Index_Invalidate_I); - CACHE32_UNROLL32_ALIGN; - /* I'm in odd chunk. blast even chunks */ - for (ws = 0; ws < ws_end; ws += ws_inc) - for (addr = start; addr < end; addr += 0x400 * 2) - cache32_unroll32(addr|ws,Index_Invalidate_I); -} - static void (* r4k_blast_icache_page)(unsigned long addr); static inline void r4k_blast_icache_page_setup(void) @@ -190,10 +138,7 @@ if (ic_lsize == 16) r4k_blast_icache_page_indexed = blast_icache16_page_indexed; else if (ic_lsize == 32) { - if (TX49XX_ICACHE_INDEX_INV_WAR) - r4k_blast_icache_page_indexed = - tx49_blast_icache32_page_indexed; - else if (R4600_V1_INDEX_ICACHEOP_WAR && cpu_is_r4600_v1_x()) + if (R4600_V1_INDEX_ICACHEOP_WAR && cpu_is_r4600_v1_x()) r4k_blast_icache_page_indexed = blast_icache32_r4600_v1_page_indexed; else @@ -214,8 +159,6 @@ else if (ic_lsize == 32) { if (R4600_V1_INDEX_ICACHEOP_WAR && cpu_is_r4600_v1_x()) r4k_blast_icache = blast_r4600_v1_icache32; - else if (TX49XX_ICACHE_INDEX_INV_WAR) - r4k_blast_icache = tx49_blast_icache32; else r4k_blast_icache = blast_icache32; } else if (ic_lsize == 64) Index: include/asm-mips/r4kcache.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/r4kcache.h,v retrieving revision 1.22 diff -u -r1.22 r4kcache.h --- include/asm-mips/r4kcache.h 5 Jan 2004 01:56:01 -0000 1.22 +++ include/asm-mips/r4kcache.h 16 Jul 2004 12:17:05 -0000 @@ -192,7 +192,7 @@ static inline void blast_icache16(void) { - unsigned long start = INDEX_BASE; + unsigned long start = (unsigned long) &&body + 0x100; unsigned long end = start + current_cpu_data.icache.waysize; unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit; unsigned long ws_end = current_cpu_data.icache.ways << @@ -200,8 +200,10 @@ unsigned long ws, addr; for (ws = 0; ws < ws_end; ws += ws_inc) - for (addr = start; addr < end; addr += 0x200) + for (addr = start; addr < end; addr += 0x200) { +body: cache16_unroll32(addr|ws,Index_Invalidate_I); + } } static inline void blast_icache16_page(unsigned long page) @@ -335,7 +337,7 @@ static inline void blast_icache32(void) { - unsigned long start = INDEX_BASE; + unsigned long start = (unsigned long) &&body + 0x200; unsigned long end = start + current_cpu_data.icache.waysize; unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit; unsigned long ws_end = current_cpu_data.icache.ways << @@ -343,8 +345,10 @@ unsigned long ws, addr; for (ws = 0; ws < ws_end; ws += ws_inc) - for (addr = start; addr < end; addr += 0x400) + for (addr = start; addr < end; addr += 0x400) { +body: cache32_unroll32(addr|ws,Index_Invalidate_I); + } } static inline void blast_icache32_page(unsigned long page) @@ -439,7 +443,7 @@ static inline void blast_icache64(void) { - unsigned long start = INDEX_BASE; + unsigned long start = (unsigned long) &&body + 0x400; unsigned long end = start + current_cpu_data.icache.waysize; unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit; unsigned long ws_end = current_cpu_data.icache.ways << @@ -447,8 +451,10 @@ unsigned long ws, addr; for (ws = 0; ws < ws_end; ws += ws_inc) - for (addr = start; addr < end; addr += 0x800) + for (addr = start; addr < end; addr += 0x800) { +body: cache64_unroll32(addr|ws,Index_Invalidate_I); + } } static inline void blast_icache64_page(unsigned long page) Index: include/asm-mips/war.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/war.h,v retrieving revision 1.18 diff -u -r1.18 war.h --- include/asm-mips/war.h 5 Mar 2004 02:47:19 -0000 1.18 +++ include/asm-mips/war.h 16 Jul 2004 12:17:05 -0000 @@ -158,17 +158,6 @@ #endif /* - * From TX49/H2 manual: "If the instruction (i.e. CACHE) is issued for - * the line which this instruction itself exists, the following - * operation is not guaranteed." - * - * Workaround: do two phase flushing for Index_Invalidate_I - */ -#ifdef CONFIG_CPU_TX49XX -#define TX49XX_ICACHE_INDEX_INV_WAR 1 -#endif - -/* * On the RM9000 there is a problem which makes the CreateDirtyExclusive * cache operation unusable on SMP systems. */ @@ -203,9 +192,6 @@ #ifndef MIPS_CACHE_SYNC_WAR #define MIPS_CACHE_SYNC_WAR 0 #endif -#ifndef TX49XX_ICACHE_INDEX_INV_WAR -#define TX49XX_ICACHE_INDEX_INV_WAR 0 -#endif #ifndef RM9000_CDEX_SMP_WAR #define RM9000_CDEX_SMP_WAR 0 #endif From collin@xorotude.com Fri Jul 16 15:41:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 15:41:48 +0100 (BST) Received: from eezi.conceptual.net.au ([IPv6:::ffff:203.190.192.22]:55991 "EHLO eezi.net.au") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 15:41:44 +0100 Received: from swift (203-190-199-165.dial.usertools.net [::ffff:203.190.199.165]) by eezi.net.au with esmtp; Fri, 16 Jul 2004 22:41:34 +0800 Message-ID: <000c01c46b42$fd6f9b60$0a9913ac@swift> From: "Collin Baillie" To: "Jan-Benedict Glaw" Cc: linux-mips@linux-mips.org References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124318.GQ2019@lug-owl.de> Subject: Re: Help with MOP network boot install on DECstation 5000/240 Date: Fri, 16 Jul 2004 22:41:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 5489 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: collin@xorotude.com Precedence: bulk X-list: linux-mips > > > Maybe you'd try Debian's install image? > > Maybe, but on a _shared_ 31.2k dialup link, it takes a while to download... > It's only a couple of megabytes, not a number of CD images. Ok, I found a 4.5MB boot.img file which is supposed to be the netboot debian installer for r3k-kn03 mipsel. mopd doesn't seem to like it's a.out-ness. mopchk gives (I named it DEBIAN.SYS for the purpose of mop booting): Checking: DEBIAN.SYS Some failure in GetAOutFileInfo Does mopd work with a.out files? I read somewhere it doesn't. Is this the install image you speak of? There doesn't seem to be a cd-rom version. I really have difficulties with Debian's site. Any help you guys could offer me would be appreciated. Cheers, Collin From jbglaw@dvmwest.gt.owl.de Fri Jul 16 16:04:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 16:04:20 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:47584 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 16:04:16 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 392844B7F9; Fri, 16 Jul 2004 17:04:15 +0200 (CEST) Date: Fri, 16 Jul 2004 17:04:15 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 Message-ID: <20040716150414.GB2019@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124318.GQ2019@lug-owl.de> <000c01c46b42$fd6f9b60$0a9913ac@swift> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8QTINAT9I+GWM3JK" Content-Disposition: inline In-Reply-To: <000c01c46b42$fd6f9b60$0a9913ac@swift> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6i 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: 5490 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --8QTINAT9I+GWM3JK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2004-07-16 22:41:01 +0800, Collin Baillie wrote in message <000c01c46b42$fd6f9b60$0a9913ac@swift>: > > > > Maybe you'd try Debian's install image? > > > Maybe, but on a _shared_ 31.2k dialup link, it takes a while to > download... > > It's only a couple of megabytes, not a number of CD images. >=20 > Ok, I found a 4.5MB boot.img file which is supposed to be the netboot deb= ian > installer for r3k-kn03 mipsel. mopd doesn't seem to like it's a.out-ness. > mopchk gives (I named it DEBIAN.SYS for the purpose of mop booting): >=20 > Checking: DEBIAN.SYS > Some failure in GetAOutFileInfo >=20 > Does mopd work with a.out files? I read somewhere it doesn't. Is this the Depends on your mopd:) There are several mopds around... > install image you speak of? There doesn't seem to be a cd-rom version. I Most probably. > really have difficulties with Debian's site. Any help you guys could offer > me would be appreciated. Use a proper mopd like that one from Maciej (he replied earlier in this thread, containing an URL for it. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --8QTINAT9I+GWM3JK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9+5uHb1edYOZ4bsRAhh2AJ401VrEjaCluRY+rlPiSyR4AgIA/QCfcF+j VjpDQt97pTAa7P7Y0hIGAK0= =Lgbp -----END PGP SIGNATURE----- --8QTINAT9I+GWM3JK-- From macro@linux-mips.org Fri Jul 16 16:08:49 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 16:09:03 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:56022 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 16:08:49 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id BE80047855; Fri, 16 Jul 2004 17:08:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id B2D7E47392; Fri, 16 Jul 2004 17:08:42 +0200 (CEST) Date: Fri, 16 Jul 2004 17:08:42 +0200 (CEST) From: "Maciej W. Rozycki" To: Collin Baillie Cc: Jan-Benedict Glaw , linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 In-Reply-To: <000c01c46b42$fd6f9b60$0a9913ac@swift> Message-ID: References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124318.GQ2019@lug-owl.de> <000c01c46b42$fd6f9b60$0a9913ac@swift> 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: 5491 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@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 16 Jul 2004, Collin Baillie wrote: > Ok, I found a 4.5MB boot.img file which is supposed to be the netboot debian > installer for r3k-kn03 mipsel. mopd doesn't seem to like it's a.out-ness. > mopchk gives (I named it DEBIAN.SYS for the purpose of mop booting): > > Checking: DEBIAN.SYS > Some failure in GetAOutFileInfo > > Does mopd work with a.out files? I read somewhere it doesn't. Is this the > install image you speak of? There doesn't seem to be a cd-rom version. I > really have difficulties with Debian's site. Any help you guys could offer > me would be appreciated. This is supposedly an ECOFF image for booting with TFTP. If you can't get the ELF image it was converted from, you may try converting it back to ELF like this: $ mipsel-linux-objcopy -O elf32-tradlittlemips boot.img DEBIAN.SYS I have never used that, though, so I can't say if it works. Actually objcopy from more or less current binutils emits a bogus warning when executing the above command. Maciej From macro@linux-mips.org Fri Jul 16 16:14:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 16:14:10 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:57558 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 16:14:05 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id DB5A747392; Fri, 16 Jul 2004 17:13:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id CAACA36DB2; Fri, 16 Jul 2004 17:13:59 +0200 (CEST) Date: Fri, 16 Jul 2004 17:13:59 +0200 (CEST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw Cc: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 In-Reply-To: <20040716150414.GB2019@lug-owl.de> Message-ID: References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124318.GQ2019@lug-owl.de> <000c01c46b42$fd6f9b60$0a9913ac@swift> <20040716150414.GB2019@lug-owl.de> 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: 5492 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@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 16 Jul 2004, Jan-Benedict Glaw wrote: > > Does mopd work with a.out files? I read somewhere it doesn't. Is this the > > Depends on your mopd:) There are several mopds around... I don't think any version supports MIPS ECOFF. COFF and ECOFF are nasty formats defined differently for different processors, so generic support, similar to one for ELF, is impossible. Just don't use ECOFF unless you absolutely have to. Maciej From anemo@mba.ocn.ne.jp Fri Jul 16 16:59:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 16:59:34 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:1247 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Fri, 16 Jul 2004 16:59:29 +0100 Received: from localhost (p5177-ipad03funabasi.chiba.ocn.ne.jp [219.160.85.177]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 35AA17409; Sat, 17 Jul 2004 00:59:26 +0900 (JST) Date: Sat, 17 Jul 2004 01:05:21 +0900 (JST) Message-Id: <20040717.010521.74757110.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: dom@mips.com, KevinK@mips.com, theansweriz42@hotmail.com, linux-mips@linux-mips.org Subject: Re: Strange, strange occurence From: Atsushi Nemoto In-Reply-To: <20040716122409.GA19192@linux-mips.org> References: <20040713003317.GA26715@linux-mips.org> <16629.24775.778491.754688@arsenal.mips.com> <20040716122409.GA19192@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 5493 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: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Fri, 16 Jul 2004 14:24:09 +0200, Ralf Baechle said: ralf> No and yes - but here is a simpler solution. Below patch solves ralf> the problem and adds just 32 bytes of code but removes the ralf> special case for TX49/H2 entirely. Hmm... Does this patch really solves the problem? Here is a disassemble list of blast_icache32 (gcc 3.3.3). The comments on CACHE instructions are indices of cachelines which the instruction invalidates. (for 4 way 16KB cache --- 4KB waysize). 80039ca0 : 80039ca0: 3c048038 lui a0,0x8038 80039ca4: 8c849e2c lw a0,-25044(a0) 80039ca8: 3c028038 lui v0,0x8038 80039cac: 94429e22 lhu v0,-25054(v0) 80039cb0: 3c038038 lui v1,0x8038 80039cb4: 8c639e28 lw v1,-25048(v1) 80039cb8: 00824004 sllv t0,v0,a0 80039cbc: 24020001 li v0,1 80039cc0: 3c018004 lui at,0x8004 80039cc4: 24219ef4 addiu at,at,-24844 # 80039ef4 80039cc8: 00231821 addu v1,at,v1 80039ccc: 00823804 sllv a3,v0,a0 80039cd0: 11000031 beqz t0,80039d98 80039cd4: 00002821 move a1,zero 80039cd8: 3c028004 lui v0,0x8004 80039cdc: 24429ef4 addiu v0,v0,-24844 # 80039ef4 80039ce0: 0043302b sltu a2,v0,v1 80039ce4: 3c048004 lui a0,0x8004 80039ce8: 24849ef4 addiu a0,a0,-24844 # 80039ef4 80039cec: 50c00027 beqzl a2,80039d8c 80039cf0: 00a72821 addu a1,a1,a3 80039cf4: 00851025 or v0,a0,a1 80039cf8: bc400000 cache 0x0,0(v0) # ee0 2e0 6e0 ae0 80039cfc: bc400020 cache 0x0,32(v0) # f00 300 700 b00 80039d00: bc400040 cache 0x0,64(v0) 80039d04: bc400060 cache 0x0,96(v0) 80039d08: bc400080 cache 0x0,128(v0) 80039d0c: bc4000a0 cache 0x0,160(v0) 80039d10: bc4000c0 cache 0x0,192(v0) 80039d14: bc4000e0 cache 0x0,224(v0) 80039d18: bc400100 cache 0x0,256(v0) 80039d1c: bc400120 cache 0x0,288(v0) # 000 400 800 c00 80039d20: bc400140 cache 0x0,320(v0) 80039d24: bc400160 cache 0x0,352(v0) 80039d28: bc400180 cache 0x0,384(v0) 80039d2c: bc4001a0 cache 0x0,416(v0) 80039d30: bc4001c0 cache 0x0,448(v0) 80039d34: bc4001e0 cache 0x0,480(v0) 80039d38: bc400200 cache 0x0,512(v0) 80039d3c: bc400220 cache 0x0,544(v0) # 100 500 900 d00 80039d40: bc400240 cache 0x0,576(v0) # 120 520 920 d20 80039d44: bc400260 cache 0x0,608(v0) # 140 540 940 d40 !!! 80039d48: bc400280 cache 0x0,640(v0) 80039d4c: bc4002a0 cache 0x0,672(v0) 80039d50: bc4002c0 cache 0x0,704(v0) 80039d54: bc4002e0 cache 0x0,736(v0) 80039d58: bc400300 cache 0x0,768(v0) 80039d5c: bc400320 cache 0x0,800(v0) # 200 600 a00 e00 80039d60: bc400340 cache 0x0,832(v0) 80039d64: bc400360 cache 0x0,864(v0) 80039d68: bc400380 cache 0x0,896(v0) 80039d6c: bc4003a0 cache 0x0,928(v0) 80039d70: bc4003c0 cache 0x0,960(v0) 80039d74: bc4003e0 cache 0x0,992(v0) 80039d78: 24840400 addiu a0,a0,1024 80039d7c: 0083102b sltu v0,a0,v1 80039d80: 1440ffdd bnez v0,80039cf8 80039d84: 00851025 or v0,a0,a1 80039d88: 00a72821 addu a1,a1,a3 80039d8c: 00a8102b sltu v0,a1,t0 80039d90: 1440ffd4 bnez v0,80039ce4 80039d94: 00000000 nop 80039d98: 03e00008 jr ra 80039d9c: 00000000 nop The target address of the first CACHE instruction is 0x80039ef4. It invalidates index 0xee0 line. The CACHE instruction on 0x80039d44 invalidates index 0xd40 line which may contains the instruction... Ouch!!! I suppose "two-phase invalidating" must be required to solve this problem. --- Atsushi Nemoto From ica2_ts@csv.ica.uni-stuttgart.de Fri Jul 16 17:31:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 17:31:47 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:47193 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 17:31:42 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1BlVcc-0007bn-00 for ; Fri, 16 Jul 2004 18:31:42 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1BlVcb-0001hE-00 for ; Fri, 16 Jul 2004 18:31:41 +0200 Date: Fri, 16 Jul 2004 18:31:41 +0200 To: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 Message-ID: <20040716163141.GE24828@rembrandt.csv.ica.uni-stuttgart.de> References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124318.GQ2019@lug-owl.de> <000c01c46b42$fd6f9b60$0a9913ac@swift> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i 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: 5494 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 Maciej W. Rozycki wrote: [snip] > This is supposedly an ECOFF image for booting with TFTP. If you can't > get the ELF image it was converted from, you may try converting it back to > ELF like this: It isn't converted ELF but the output of the t-rex utility, which combines ECOFF header, ELF stub, kernel and ramdisk into one file. Thiemo From dom@mips.com Fri Jul 16 17:50:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 17:50:43 +0100 (BST) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:11790 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 17:50:38 +0100 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1BlW6y-000602-00 for ; Fri, 16 Jul 2004 18:03:04 +0100 Received: from arsenal.mips.com ([192.168.192.197]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1BlVuk-0000RZ-00 for ; Fri, 16 Jul 2004 17:50:26 +0100 Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian)) id 1BlVuk-0002t9-00 for ; Fri, 16 Jul 2004 17:50:26 +0100 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16632.1873.997612.349827@arsenal.mips.com> Date: Fri, 16 Jul 2004 17:50:25 +0100 To: linux-mips@linux-mips.org Subject: Linux kernel engineer job at MIPS Technologies, Cambridge X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.847, required 4, AWL, BAYES_00) 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: 5495 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: dom@mips.com Precedence: bulk X-list: linux-mips I hope you'll excuse us putting this out once on this list. MIPS Technologies needs a Linux kernel engineer to work in Cambridge, UK. We could use you right now! This engineer will work in a tight-knit team exploiting the multithreading capacities for MIPS synthesizable cores. We're a small team, and the successful candidate will get to share in the everyday, difficult work: maintaining the Linux kernel, testing toolchains, and debugging new hardware. This position requires a knowledgeable, experienced software engineer with significant Linux kernel experience. You should have a track record of contribution to Linux code, experience with coding device drivers, strong knowledge of C, and an understanding of microprocessors at the machine level. A degree-level qualification is desirable but not specifically required. This position is open to E.U. citizens; however, a relocation package is not provided. To apply for this position, email resume to mailto:johnrob@mips.com or mailto:getajob@mips.com. MIPS is an equal opportunity employer. -- Dominic Sweetman, MIPS Technologies (UK) The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706205 / fax: +44 1223 706250 / swbrd: +44 1223 706200 http://www.mips.com From macro@linux-mips.org Fri Jul 16 17:51:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 17:51:36 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:36823 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 17:51:32 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 39C9C4787C; Fri, 16 Jul 2004 18:51:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 2349747855; Fri, 16 Jul 2004 18:51:26 +0200 (CEST) Date: Fri, 16 Jul 2004 18:51:26 +0200 (CEST) From: "Maciej W. Rozycki" To: Thiemo Seufer Cc: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 In-Reply-To: <20040716163141.GE24828@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: References: <20040710100412.GA23624@linux-mips.org> <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124318.GQ2019@lug-owl.de> <000c01c46b42$fd6f9b60$0a9913ac@swift> <20040716163141.GE24828@rembrandt.csv.ica.uni-stuttgart.de> 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: 5496 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@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 16 Jul 2004, Thiemo Seufer wrote: > > This is supposedly an ECOFF image for booting with TFTP. If you can't > > get the ELF image it was converted from, you may try converting it back to > > ELF like this: > > It isn't converted ELF but the output of the t-rex utility, which combines > ECOFF header, ELF stub, kernel and ramdisk into one file. I stand corrected. The image should still work if converted to ELF and then loaded, though, shouldn't it? Maciej From kokje@linuxmail.org Fri Jul 16 19:54:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 19:54:34 +0100 (BST) Received: from webmail-outgoing.us4.outblaze.com ([IPv6:::ffff:205.158.62.67]:52942 "EHLO webmail-outgoing.us4.outblaze.com") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 19:54:27 +0100 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 740C81801461 for ; Fri, 16 Jul 2004 18:54:21 +0000 (GMT) X-OB-Received: from unknown (205.158.62.131) by wfilter.us4.outblaze.com; 16 Jul 2004 18:52:30 -0000 Received: by ws5-1.us4.outblaze.com (Postfix, from userid 1001) id D3CA6398199; Fri, 16 Jul 2004 18:54:20 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [128.125.139.44] by ws5-1.us4.outblaze.com with http for kokje@linuxmail.org; Fri, 16 Jul 2004 10:54:20 -0800 From: "Tejas Kokje" To: linux-mips@linux-mips.org Date: Fri, 16 Jul 2004 10:54:20 -0800 Subject: libpcap.a X-Originating-Ip: 128.125.139.44 X-Originating-Server: ws5-1.us4.outblaze.com Message-Id: <20040716185420.D3CA6398199@ws5-1.us4.outblaze.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: 5497 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: kokje@linuxmail.org Precedence: bulk X-list: linux-mips Hello, Can somebody share libpcap.a for MIPS platform. Please email me or give me a link to download. Thank You Tejas Kokje Graduate Student (Computer Science) University of Southern California URL : http://www-scf.usc.edu/~kokje Registered Linux User #: 337673 -- ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze From ica2_ts@csv.ica.uni-stuttgart.de Fri Jul 16 19:56:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 19:56:46 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:57182 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 19:56:42 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1BlXsv-0000q6-00 for ; Fri, 16 Jul 2004 20:56:41 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1BlXsv-0002As-00 for ; Fri, 16 Jul 2004 20:56:41 +0200 Date: Fri, 16 Jul 2004 20:56:41 +0200 To: linux-mips@linux-mips.org Subject: Re: Help with MOP network boot install on DECstation 5000/240 Message-ID: <20040716185640.GF24828@rembrandt.csv.ica.uni-stuttgart.de> References: <00ba01c46823$3729b200$0deca8c0@Ulysses> <20040713003317.GA26715@linux-mips.org> <000701c468ae$141c3e50$0a9913ac@swift> <20040713080320.GC18841@lug-owl.de> <000e01c4696f$f65cf4f0$0a9913ac@swift> <20040714124318.GQ2019@lug-owl.de> <000c01c46b42$fd6f9b60$0a9913ac@swift> <20040716163141.GE24828@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i 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: 5498 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 Maciej W. Rozycki wrote: > On Fri, 16 Jul 2004, Thiemo Seufer wrote: > > > > This is supposedly an ECOFF image for booting with TFTP. If you can't > > > get the ELF image it was converted from, you may try converting it back to > > > ELF like this: > > > > It isn't converted ELF but the output of the t-rex utility, which combines > > ECOFF header, ELF stub, kernel and ramdisk into one file. > > I stand corrected. The image should still work if converted to ELF and > then loaded, though, shouldn't it? At least I don't see a reason for it to break. I've never tried to convert it to ELF, though, and binutils support for format conversion generally isn't as reliable as it should be. Thiemo From wd@denx.de Fri Jul 16 20:29:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 20:29:36 +0100 (BST) Received: from mail-out.m-online.net ([IPv6:::ffff:212.18.0.9]:21420 "EHLO mail-out.m-online.net") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 20:29:32 +0100 Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id B0A5552BFE; Fri, 16 Jul 2004 21:29:30 +0200 (CEST) Received: from denx.de (host-82-135-33-74.customer.m-online.net [82.135.33.74]) by mail.m-online.net (Postfix) with ESMTP id A77C9ECD5D; Fri, 16 Jul 2004 21:29:30 +0200 (CEST) Received: from atlas.denx.de (atlas.denx.de [10.0.0.14]) by denx.de (Postfix) with ESMTP id 2992D4287D; Fri, 16 Jul 2004 21:29:30 +0200 (MEST) Received: by atlas.denx.de (Postfix, from userid 15) id B7451C109F; Fri, 16 Jul 2004 21:29:29 +0200 (MEST) Received: from atlas.denx.de (localhost [127.0.0.1]) by atlas.denx.de (Postfix) with ESMTP id B422B13D6DB; Fri, 16 Jul 2004 21:29:29 +0200 (MEST) To: "Tejas Kokje" Cc: linux-mips@linux-mips.org From: Wolfgang Denk Subject: Re: libpcap.a X-Mailer: exmh version 1.6.4 10/10/1995 Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Fri, 16 Jul 2004 10:54:20 -0800." <20040716185420.D3CA6398199@ws5-1.us4.outblaze.com> Date: Fri, 16 Jul 2004 21:29:24 +0200 Message-Id: <20040716192929.B7451C109F@atlas.denx.de> 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: 5499 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: wd@denx.de Precedence: bulk X-list: linux-mips In message <20040716185420.D3CA6398199@ws5-1.us4.outblaze.com> you wrote: > > Can somebody share libpcap.a for MIPS platform. Please email me or give me a link to download. LE or BE? Compatible with which version of GLIBC? [http://www.denx.de/ELDK.html ??] Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de There is only one way to console a widow. But remember the risk. -- Robert Heinlein From kokje@linuxmail.org Fri Jul 16 20:35:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jul 2004 20:35:39 +0100 (BST) Received: from webmail-outgoing.us4.outblaze.com ([IPv6:::ffff:205.158.62.67]:34448 "EHLO webmail-outgoing.us4.outblaze.com") by linux-mips.org with ESMTP id ; Fri, 16 Jul 2004 20:35:34 +0100 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 286DF1802482 for ; Fri, 16 Jul 2004 19:35:28 +0000 (GMT) X-OB-Received: from unknown (205.158.62.133) by wfilter.us4.outblaze.com; 16 Jul 2004 19:33:35 -0000 Received: by ws5-3.us4.outblaze.com (Postfix, from userid 1001) id 92CAE23C09; Fri, 16 Jul 2004 19:35:48 +0000 (GMT) Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [128.125.139.44] by ws5-3.us4.outblaze.com with http for kokje@linuxmail.org; Fri, 16 Jul 2004 11:35:48 -0800 From: "Tejas Kokje" To: "Wolfgang Denk" Cc: linux-mips@linux-mips.org Date: Fri, 16 Jul 2004 11:35:48 -0800 Subject: Re: libpcap.a X-Originating-Ip: 128.125.139.44 X-Originating-Server: ws5-3.us4.outblaze.com Message-Id: <20040716193548.92CAE23C09@ws5-3.us4.outblaze.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: 5500 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: kokje@linuxmail.org Precedence: bulk X-list: linux-mips Sorry completely missed out those points. I want libpcap.a for Little Endian (mipsel). I am writing a small sniffer utility for Linksys WRT54GS router. glibc version on the router is 2.2.3. Thanks ----- Original Message ----- From: Wolfgang Denk Date: Fri, 16 Jul 2004 21:29:24 +0200 To: "Tejas Kokje" Subject: Re: libpcap.a > In message <20040716185420.D3CA6398199@ws5-1.us4.outblaze.com> you wrote: > > > > Can somebody share libpcap.a for MIPS platform. Please email me or give me a link to download. > > LE or BE? Compatible with which version of GLIBC? > > [http://www.denx.de/ELDK.html ??] > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de > There is only one way to console a widow. But remember the risk. > -- Robert Heinlein Tejas Kokje Graduate Student (Computer Science) University of Southern California URL : http://www-scf.usc.edu/~kokje Registered Linux User #: 337673 -- ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze From macro@linux-mips.org Mon Jul 19 15:22:03 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 15:22:10 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:25057 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 15:22:03 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id D37B0477EF; Mon, 19 Jul 2004 16:21:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id A70CF475C1; Mon, 19 Jul 2004 16:21:56 +0200 (CEST) Date: Mon, 19 Jul 2004 16:21:56 +0200 (CEST) From: "Maciej W. Rozycki" To: binutils@sources.redhat.com, cgd@broadcom.com Cc: ddaney@avtrex.com, linux-mips@linux-mips.org, Ralf Baechle , Richard Sandiford Subject: Re: [Patch] / 0 should send SIGFPE not SIGTRAP... In-Reply-To: <200406281519.IAA29663@mail-sj1-2.sj.broadcom.com> Message-ID: References: <200406281519.IAA29663@mail-sj1-2.sj.broadcom.com> 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: 5501 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@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 28 Jun 2004 cgd@broadcom.com wrote: > personally, i'd make the comment on the 'break' testcase in mips32.s a bit > clearer and more explicit. e.g. "for a while, break for mips32 > took a 20 bit code. But that was incompatible and caused problems, so > now it's back to the old 10 bit code, or two comma-separated 10 bit codes." Here is an update, including your suggested comment changes as well as an additional test case to assure single-argument "break" instructions have the code placed correctly (this has led to an address shift enlarging the patch significantly, unfortunately). The gas testsuite has been verified to pass after the change. opcodes/: 2004-07-19 Maciej W. Rozycki * mips-opc.c (mips_builtin_opcodes): Remove the MIPS32 ISA-specific "break" encoding. gas/testsuite/: 2004-07-19 Maciej W. Rozycki * gas/mips/mips32.s: Adjust for the unified "break" syntax. Add another "break" case. Update the comment accordingly. * gas/mips/set-arch.s: Likewise. * gas/mips/mips32.d: Adjust for the new output. * gas/mips/set-arch.d: Likewise. OK to apply? Maciej binutils-2.15.91-20040715-mips-break20.patch diff -up --recursive --new-file binutils-2.15.91-20040715.macro/gas/testsuite/gas/mips/mips32.d binutils-2.15.91-20040715/gas/testsuite/gas/mips/mips32.d --- binutils-2.15.91-20040715.macro/gas/testsuite/gas/mips/mips32.d 2003-05-08 03:25:35.000000000 +0000 +++ binutils-2.15.91-20040715/gas/testsuite/gas/mips/mips32.d 2004-07-18 19:10:00.000000000 +0000 @@ -48,8 +48,9 @@ Disassembly of section .text: 0+0098 <[^>]*> 4359e260 wait 0x56789 0+009c <[^>]*> 0000000d break 0+00a0 <[^>]*> 0000000d break -0+00a4 <[^>]*> 0048d14d break 0x12345 -0+00a8 <[^>]*> 7000003f sdbbp +0+00a4 <[^>]*> 0345000d break 0x345 +0+00a8 <[^>]*> 0048d14d break 0x48,0x345 0+00ac <[^>]*> 7000003f sdbbp -0+00b0 <[^>]*> 7159e27f sdbbp 0x56789 +0+00b0 <[^>]*> 7000003f sdbbp +0+00b4 <[^>]*> 7159e27f sdbbp 0x56789 ... diff -up --recursive --new-file binutils-2.15.91-20040715.macro/gas/testsuite/gas/mips/mips32.s binutils-2.15.91-20040715/gas/testsuite/gas/mips/mips32.s --- binutils-2.15.91-20040715.macro/gas/testsuite/gas/mips/mips32.s 2002-09-05 03:25:40.000000000 +0000 +++ binutils-2.15.91-20040715/gas/testsuite/gas/mips/mips32.s 2004-07-18 19:30:04.000000000 +0000 @@ -58,11 +58,17 @@ text_label: wait 0 # disassembles without code wait 0x56789 - # Instructions in previous ISAs or CPUs which are now slightly - # different. + # For a while break for the mips32 ISA interpreted a single argument + # as a 20-bit code, placing it in the opcode differently to + # traditional ISAs. This turned out to cause problems, so it has + # been removed. This test is to assure consistent interpretation. break break 0 # disassembles without code - break 0x12345 + break 0x345 + break 0x48,0x345 # this still specifies a 20-bit code + + # Instructions in previous ISAs or CPUs which are now slightly + # different. sdbbp sdbbp 0 # disassembles without code sdbbp 0x56789 diff -up --recursive --new-file binutils-2.15.91-20040715.macro/gas/testsuite/gas/mips/set-arch.d binutils-2.15.91-20040715/gas/testsuite/gas/mips/set-arch.d --- binutils-2.15.91-20040715.macro/gas/testsuite/gas/mips/set-arch.d 2003-10-01 03:25:36.000000000 +0000 +++ binutils-2.15.91-20040715/gas/testsuite/gas/mips/set-arch.d 2004-07-18 21:41:02.000000000 +0000 @@ -160,207 +160,208 @@ Disassembly of section \.text: 00000260 <[^>]*> 4359e260 wait 0x56789 00000264 <[^>]*> 0000000d break 00000268 <[^>]*> 0000000d break -0000026c <[^>]*> 0048d14d break 0x12345 -00000270 <[^>]*> 7000003f sdbbp +0000026c <[^>]*> 0345000d break 0x345 +00000270 <[^>]*> 0048d14d break 0x48,0x345 00000274 <[^>]*> 7000003f sdbbp -00000278 <[^>]*> 7159e27f sdbbp 0x56789 -0000027c <[^>]*> 000000c0 sll zero,zero,0x3 -00000280 <[^>]*> 7ca43980 0x7ca43980 -00000284 <[^>]*> 7ca46984 0x7ca46984 -00000288 <[^>]*> 0100fc09 0x100fc09 -0000028c <[^>]*> 0120a409 0x120a409 -00000290 <[^>]*> 01000408 0x1000408 -00000294 <[^>]*> 7c0a003b 0x7c0a003b -00000298 <[^>]*> 7c0b083b 0x7c0b083b -0000029c <[^>]*> 7c0c103b 0x7c0c103b -000002a0 <[^>]*> 7c0d183b 0x7c0d183b -000002a4 <[^>]*> 7c0e203b 0x7c0e203b -000002a8 <[^>]*> 7c0f283b 0x7c0f283b -000002ac <[^>]*> 002acf02 0x2acf02 -000002b0 <[^>]*> 002ac902 0x2ac902 -000002b4 <[^>]*> 0004c823 negu t9,a0 -000002b8 <[^>]*> 032ac846 0x32ac846 -000002bc <[^>]*> 008ac846 0x8ac846 +00000278 <[^>]*> 7000003f sdbbp +0000027c <[^>]*> 7159e27f sdbbp 0x56789 +00000280 <[^>]*> 000000c0 sll zero,zero,0x3 +00000284 <[^>]*> 7ca43980 0x7ca43980 +00000288 <[^>]*> 7ca46984 0x7ca46984 +0000028c <[^>]*> 0100fc09 0x100fc09 +00000290 <[^>]*> 0120a409 0x120a409 +00000294 <[^>]*> 01000408 0x1000408 +00000298 <[^>]*> 7c0a003b 0x7c0a003b +0000029c <[^>]*> 7c0b083b 0x7c0b083b +000002a0 <[^>]*> 7c0c103b 0x7c0c103b +000002a4 <[^>]*> 7c0d183b 0x7c0d183b +000002a8 <[^>]*> 7c0e203b 0x7c0e203b +000002ac <[^>]*> 7c0f283b 0x7c0f283b +000002b0 <[^>]*> 002acf02 0x2acf02 +000002b4 <[^>]*> 002ac902 0x2ac902 +000002b8 <[^>]*> 0004c823 negu t9,a0 +000002bc <[^>]*> 032ac846 0x32ac846 000002c0 <[^>]*> 008ac846 0x8ac846 -000002c4 <[^>]*> 7c073c20 0x7c073c20 -000002c8 <[^>]*> 7c0a4420 0x7c0a4420 -000002cc <[^>]*> 7c073e20 0x7c073e20 -000002d0 <[^>]*> 7c0a4620 0x7c0a4620 -000002d4 <[^>]*> 055f5555 0x55f5555 -000002d8 <[^>]*> 7c0738a0 0x7c0738a0 -000002dc <[^>]*> 7c0a40a0 0x7c0a40a0 -000002e0 <[^>]*> 41606000 0x41606000 +000002c4 <[^>]*> 008ac846 0x8ac846 +000002c8 <[^>]*> 7c073c20 0x7c073c20 +000002cc <[^>]*> 7c0a4420 0x7c0a4420 +000002d0 <[^>]*> 7c073e20 0x7c073e20 +000002d4 <[^>]*> 7c0a4620 0x7c0a4620 +000002d8 <[^>]*> 055f5555 0x55f5555 +000002dc <[^>]*> 7c0738a0 0x7c0738a0 +000002e0 <[^>]*> 7c0a40a0 0x7c0a40a0 000002e4 <[^>]*> 41606000 0x41606000 -000002e8 <[^>]*> 416a6000 0x416a6000 -000002ec <[^>]*> 41606020 0x41606020 +000002e8 <[^>]*> 41606000 0x41606000 +000002ec <[^>]*> 416a6000 0x416a6000 000002f0 <[^>]*> 41606020 0x41606020 -000002f4 <[^>]*> 416a6020 0x416a6020 -000002f8 <[^>]*> 41595000 0x41595000 -000002fc <[^>]*> 41d95000 0x41d95000 -00000300 <[^>]*> 44710000 0x44710000 -00000304 <[^>]*> 44f10000 0x44f10000 -00000308 <[^>]*> 48715555 0x48715555 -0000030c <[^>]*> 48f15555 0x48f15555 -00000310 <[^>]*> 70410825 dclo at,v0 -00000314 <[^>]*> 70831824 dclz v1,a0 -00000318 <[^>]*> 48232000 dmfc2 v1,\$4 -0000031c <[^>]*> 48242800 dmfc2 a0,\$5 -00000320 <[^>]*> 48253007 dmfc2 a1,\$6,7 -00000324 <[^>]*> 48a63800 dmtc2 a2,\$7 -00000328 <[^>]*> 48a74000 dmtc2 a3,\$8 -0000032c <[^>]*> 48a84807 dmtc2 t0,\$9,7 -00000330 <[^>]*> 00850029 0x850029 -00000334 <[^>]*> 00a60028 0xa60028 -00000338 <[^>]*> 00002012 mflo a0 -0000033c <[^>]*> 00a62029 0xa62029 -00000340 <[^>]*> 00a62229 0xa62229 -00000344 <[^>]*> 00a62629 0xa62629 -00000348 <[^>]*> 00a62269 0xa62269 -0000034c <[^>]*> 00a62669 0xa62669 -00000350 <[^>]*> 00a62429 0xa62429 -00000354 <[^>]*> 00a62069 0xa62069 -00000358 <[^>]*> 00a62469 0xa62469 -0000035c <[^>]*> 00002012 mflo a0 -00000360 <[^>]*> 00a62028 0xa62028 -00000364 <[^>]*> 00a62228 0xa62228 -00000368 <[^>]*> 00a62628 0xa62628 -0000036c <[^>]*> 00a62268 0xa62268 -00000370 <[^>]*> 00a62668 0xa62668 -00000374 <[^>]*> 00a62428 0xa62428 -00000378 <[^>]*> 00a62068 0xa62068 -0000037c <[^>]*> 00a62468 0xa62468 -00000380 <[^>]*> 00a62059 0xa62059 -00000384 <[^>]*> 00a62258 0xa62258 -00000388 <[^>]*> 00a62259 0xa62259 -0000038c <[^>]*> 00a620d8 0xa620d8 -00000390 <[^>]*> 00a620d9 0xa620d9 -00000394 <[^>]*> 00a622d8 0xa622d8 -00000398 <[^>]*> 00a622d9 0xa622d9 -0000039c <[^>]*> 00a62158 0xa62158 -000003a0 <[^>]*> 00a62159 0xa62159 -000003a4 <[^>]*> 00a62358 0xa62358 -000003a8 <[^>]*> 00a62359 0xa62359 -000003ac <[^>]*> 00a621d8 0xa621d8 -000003b0 <[^>]*> 00a621d9 0xa621d9 -000003b4 <[^>]*> 00a623d8 0xa623d8 -000003b8 <[^>]*> 00a623d9 0xa623d9 -000003bc <[^>]*> 00252642 0x252642 -000003c0 <[^>]*> 00c52046 0xc52046 -000003c4 <[^>]*> 0025267a 0x25267a -000003c8 <[^>]*> 0025267e 0x25267e +000002f4 <[^>]*> 41606020 0x41606020 +000002f8 <[^>]*> 416a6020 0x416a6020 +000002fc <[^>]*> 41595000 0x41595000 +00000300 <[^>]*> 41d95000 0x41d95000 +00000304 <[^>]*> 44710000 0x44710000 +00000308 <[^>]*> 44f10000 0x44f10000 +0000030c <[^>]*> 48715555 0x48715555 +00000310 <[^>]*> 48f15555 0x48f15555 +00000314 <[^>]*> 70410825 dclo at,v0 +00000318 <[^>]*> 70831824 dclz v1,a0 +0000031c <[^>]*> 48232000 dmfc2 v1,\$4 +00000320 <[^>]*> 48242800 dmfc2 a0,\$5 +00000324 <[^>]*> 48253007 dmfc2 a1,\$6,7 +00000328 <[^>]*> 48a63800 dmtc2 a2,\$7 +0000032c <[^>]*> 48a74000 dmtc2 a3,\$8 +00000330 <[^>]*> 48a84807 dmtc2 t0,\$9,7 +00000334 <[^>]*> 00850029 0x850029 +00000338 <[^>]*> 00a60028 0xa60028 +0000033c <[^>]*> 00002012 mflo a0 +00000340 <[^>]*> 00a62029 0xa62029 +00000344 <[^>]*> 00a62229 0xa62229 +00000348 <[^>]*> 00a62629 0xa62629 +0000034c <[^>]*> 00a62269 0xa62269 +00000350 <[^>]*> 00a62669 0xa62669 +00000354 <[^>]*> 00a62429 0xa62429 +00000358 <[^>]*> 00a62069 0xa62069 +0000035c <[^>]*> 00a62469 0xa62469 +00000360 <[^>]*> 00002012 mflo a0 +00000364 <[^>]*> 00a62028 0xa62028 +00000368 <[^>]*> 00a62228 0xa62228 +0000036c <[^>]*> 00a62628 0xa62628 +00000370 <[^>]*> 00a62268 0xa62268 +00000374 <[^>]*> 00a62668 0xa62668 +00000378 <[^>]*> 00a62428 0xa62428 +0000037c <[^>]*> 00a62068 0xa62068 +00000380 <[^>]*> 00a62468 0xa62468 +00000384 <[^>]*> 00a62059 0xa62059 +00000388 <[^>]*> 00a62258 0xa62258 +0000038c <[^>]*> 00a62259 0xa62259 +00000390 <[^>]*> 00a620d8 0xa620d8 +00000394 <[^>]*> 00a620d9 0xa620d9 +00000398 <[^>]*> 00a622d8 0xa622d8 +0000039c <[^>]*> 00a622d9 0xa622d9 +000003a0 <[^>]*> 00a62158 0xa62158 +000003a4 <[^>]*> 00a62159 0xa62159 +000003a8 <[^>]*> 00a62358 0xa62358 +000003ac <[^>]*> 00a62359 0xa62359 +000003b0 <[^>]*> 00a621d8 0xa621d8 +000003b4 <[^>]*> 00a621d9 0xa621d9 +000003b8 <[^>]*> 00a623d8 0xa623d8 +000003bc <[^>]*> 00a623d9 0xa623d9 +000003c0 <[^>]*> 00252642 0x252642 +000003c4 <[^>]*> 00c52046 0xc52046 +000003c8 <[^>]*> 0025267a 0x25267a 000003cc <[^>]*> 0025267e 0x25267e -000003d0 <[^>]*> 00c52056 0xc52056 -000003d4 <[^>]*> 7000003f sdbbp -000003d8 <[^>]*> 7000003e 0x7000003e -000003dc <[^>]*> 7003183d 0x7003183d -000003e0 <[^>]*> 7083183d 0x7083183d -000003e4 <[^>]*> 4004c803 mfc0 a0,c0_perfcnt,3 -000003e8 <[^>]*> 4004c802 mfc0 a0,c0_perfcnt,2 -000003ec <[^>]*> 4084c803 mtc0 a0,c0_perfcnt,3 -000003f0 <[^>]*> 4084c802 mtc0 a0,c0_perfcnt,2 -000003f4 <[^>]*> 4ac4100b c2 0xc4100b -000003f8 <[^>]*> 4886208b 0x4886208b -000003fc <[^>]*> 4bcf218b c2 0x1cf218b -00000400 <[^>]*> 4bdf310b c2 0x1df310b -00000404 <[^>]*> 4ac4100c c2 0xc4100c -00000408 <[^>]*> 4886208c 0x4886208c -0000040c <[^>]*> 4bcf218c c2 0x1cf218c -00000410 <[^>]*> 4bdf310c c2 0x1df310c -00000414 <[^>]*> 4ac20001 c2 0xc20001 -00000418 <[^>]*> 48862001 mtc2 a2,\$4,1 -0000041c <[^>]*> 4bcf3001 c2 0x1cf3001 -00000420 <[^>]*> 4bdf2001 c2 0x1df2001 -00000424 <[^>]*> 4ac20005 c2 0xc20005 -00000428 <[^>]*> 48862005 mtc2 a2,\$4,5 -0000042c <[^>]*> 4bcf3005 c2 0x1cf3005 -00000430 <[^>]*> 4bdf2005 c2 0x1df2005 -00000434 <[^>]*> 4ac20004 c2 0xc20004 -00000438 <[^>]*> 48862004 mtc2 a2,\$4,4 -0000043c <[^>]*> 4bcf3004 c2 0x1cf3004 -00000440 <[^>]*> 4bdf2004 c2 0x1df2004 -00000444 <[^>]*> 4ac41007 c2 0xc41007 -00000448 <[^>]*> 48862087 0x48862087 -0000044c <[^>]*> 4bcf2187 c2 0x1cf2187 -00000450 <[^>]*> 4bdf3107 c2 0x1df3107 -00000454 <[^>]*> 4ac41006 c2 0xc41006 -00000458 <[^>]*> 48862086 0x48862086 -0000045c <[^>]*> 4bcf2186 c2 0x1cf2186 -00000460 <[^>]*> 4bdf3106 c2 0x1df3106 -00000464 <[^>]*> 4ac41030 c2 0xc41030 -00000468 <[^>]*> 488620b0 0x488620b0 -0000046c <[^>]*> 4bcf21b0 c2 0x1cf21b0 -00000470 <[^>]*> 4bdf3130 c2 0x1df3130 -00000474 <[^>]*> 4ac20033 c2 0xc20033 -00000478 <[^>]*> 48862033 0x48862033 -0000047c <[^>]*> 4bcf3033 c2 0x1cf3033 -00000480 <[^>]*> 4bdf2033 c2 0x1df2033 -00000484 <[^>]*> 4ac20433 c2 0xc20433 -00000488 <[^>]*> 48862433 0x48862433 -0000048c <[^>]*> 4bcf3433 c2 0x1cf3433 -00000490 <[^>]*> 4bdf2433 c2 0x1df2433 -00000494 <[^>]*> 4ac20032 c2 0xc20032 -00000498 <[^>]*> 48862032 0x48862032 -0000049c <[^>]*> 4bcf3032 c2 0x1cf3032 -000004a0 <[^>]*> 4bdf2032 c2 0x1df2032 -000004a4 <[^>]*> 4ac20432 c2 0xc20432 -000004a8 <[^>]*> 48862432 0x48862432 -000004ac <[^>]*> 4bcf3432 c2 0x1cf3432 -000004b0 <[^>]*> 4bdf2432 c2 0x1df2432 -000004b4 <[^>]*> 4ac4100f c2 0xc4100f -000004b8 <[^>]*> 4886208f 0x4886208f -000004bc <[^>]*> 4bcf218f c2 0x1cf218f -000004c0 <[^>]*> 4bdf310f c2 0x1df310f -000004c4 <[^>]*> 4ac4100e c2 0xc4100e -000004c8 <[^>]*> 4886208e 0x4886208e -000004cc <[^>]*> 4bcf218e c2 0x1cf218e -000004d0 <[^>]*> 4bdf310e c2 0x1df310e -000004d4 <[^>]*> 4ac41002 c2 0xc41002 -000004d8 <[^>]*> 48862082 0x48862082 -000004dc <[^>]*> 4bcf2182 c2 0x1cf2182 -000004e0 <[^>]*> 4bdf3102 c2 0x1df3102 -000004e4 <[^>]*> 4ac41003 c2 0xc41003 -000004e8 <[^>]*> 48862083 0x48862083 -000004ec <[^>]*> 4bcf2183 c2 0x1cf2183 -000004f0 <[^>]*> 4bdf3103 c2 0x1df3103 -000004f4 <[^>]*> 4ac4100a c2 0xc4100a -000004f8 <[^>]*> 4886208a 0x4886208a -000004fc <[^>]*> 4bcf218a c2 0x1cf218a -00000500 <[^>]*> 4bdf310a c2 0x1df310a -00000504 <[^>]*> 4ac4100d c2 0xc4100d -00000508 <[^>]*> 4886208d 0x4886208d -0000050c <[^>]*> 4bcf218d c2 0x1cf218d -00000510 <[^>]*> 4bdf310d c2 0x1df310d -00000514 <[^>]*> 48a41018 0x48a41018 -00000518 <[^>]*> 4984101f 0x4984101f -0000051c <[^>]*> 49c4101f 0x49c4101f -00000520 <[^>]*> 4904101f 0x4904101f -00000524 <[^>]*> 4944101f 0x4944101f -00000528 <[^>]*> 48c62090 0x48c62090 -0000052c <[^>]*> 4bce3110 c2 0x1ce3110 -00000530 <[^>]*> 48c62092 0x48c62092 -00000534 <[^>]*> 4bce3112 c2 0x1ce3112 -00000538 <[^>]*> 4bcd00a0 c2 0x1cd00a0 -0000053c <[^>]*> 4a0000bf c2 0xbf -00000540 <[^>]*> 480000bf 0x480000bf -00000544 <[^>]*> 490000bf bc2f 00000844 <[^>]*> -00000548 <[^>]*> 4a00103e c2 0x103e -0000054c <[^>]*> 4804103e 0x4804103e -00000550 <[^>]*> 00c52046 0xc52046 -00000554 <[^>]*> 00252442 0x252442 -00000558 <[^>]*> 00c52056 0xc52056 -0000055c <[^>]*> 0025207e 0x25207e -00000560 <[^>]*> 002520ba 0x2520ba -00000564 <[^>]*> 4ca4200f prefx 0x4,a0\(a1\) -00000568 <[^>]*> 42000020 wait +000003d0 <[^>]*> 0025267e 0x25267e +000003d4 <[^>]*> 00c52056 0xc52056 +000003d8 <[^>]*> 7000003f sdbbp +000003dc <[^>]*> 7000003e 0x7000003e +000003e0 <[^>]*> 7003183d 0x7003183d +000003e4 <[^>]*> 7083183d 0x7083183d +000003e8 <[^>]*> 4004c803 mfc0 a0,c0_perfcnt,3 +000003ec <[^>]*> 4004c802 mfc0 a0,c0_perfcnt,2 +000003f0 <[^>]*> 4084c803 mtc0 a0,c0_perfcnt,3 +000003f4 <[^>]*> 4084c802 mtc0 a0,c0_perfcnt,2 +000003f8 <[^>]*> 4ac4100b c2 0xc4100b +000003fc <[^>]*> 4886208b 0x4886208b +00000400 <[^>]*> 4bcf218b c2 0x1cf218b +00000404 <[^>]*> 4bdf310b c2 0x1df310b +00000408 <[^>]*> 4ac4100c c2 0xc4100c +0000040c <[^>]*> 4886208c 0x4886208c +00000410 <[^>]*> 4bcf218c c2 0x1cf218c +00000414 <[^>]*> 4bdf310c c2 0x1df310c +00000418 <[^>]*> 4ac20001 c2 0xc20001 +0000041c <[^>]*> 48862001 mtc2 a2,\$4,1 +00000420 <[^>]*> 4bcf3001 c2 0x1cf3001 +00000424 <[^>]*> 4bdf2001 c2 0x1df2001 +00000428 <[^>]*> 4ac20005 c2 0xc20005 +0000042c <[^>]*> 48862005 mtc2 a2,\$4,5 +00000430 <[^>]*> 4bcf3005 c2 0x1cf3005 +00000434 <[^>]*> 4bdf2005 c2 0x1df2005 +00000438 <[^>]*> 4ac20004 c2 0xc20004 +0000043c <[^>]*> 48862004 mtc2 a2,\$4,4 +00000440 <[^>]*> 4bcf3004 c2 0x1cf3004 +00000444 <[^>]*> 4bdf2004 c2 0x1df2004 +00000448 <[^>]*> 4ac41007 c2 0xc41007 +0000044c <[^>]*> 48862087 0x48862087 +00000450 <[^>]*> 4bcf2187 c2 0x1cf2187 +00000454 <[^>]*> 4bdf3107 c2 0x1df3107 +00000458 <[^>]*> 4ac41006 c2 0xc41006 +0000045c <[^>]*> 48862086 0x48862086 +00000460 <[^>]*> 4bcf2186 c2 0x1cf2186 +00000464 <[^>]*> 4bdf3106 c2 0x1df3106 +00000468 <[^>]*> 4ac41030 c2 0xc41030 +0000046c <[^>]*> 488620b0 0x488620b0 +00000470 <[^>]*> 4bcf21b0 c2 0x1cf21b0 +00000474 <[^>]*> 4bdf3130 c2 0x1df3130 +00000478 <[^>]*> 4ac20033 c2 0xc20033 +0000047c <[^>]*> 48862033 0x48862033 +00000480 <[^>]*> 4bcf3033 c2 0x1cf3033 +00000484 <[^>]*> 4bdf2033 c2 0x1df2033 +00000488 <[^>]*> 4ac20433 c2 0xc20433 +0000048c <[^>]*> 48862433 0x48862433 +00000490 <[^>]*> 4bcf3433 c2 0x1cf3433 +00000494 <[^>]*> 4bdf2433 c2 0x1df2433 +00000498 <[^>]*> 4ac20032 c2 0xc20032 +0000049c <[^>]*> 48862032 0x48862032 +000004a0 <[^>]*> 4bcf3032 c2 0x1cf3032 +000004a4 <[^>]*> 4bdf2032 c2 0x1df2032 +000004a8 <[^>]*> 4ac20432 c2 0xc20432 +000004ac <[^>]*> 48862432 0x48862432 +000004b0 <[^>]*> 4bcf3432 c2 0x1cf3432 +000004b4 <[^>]*> 4bdf2432 c2 0x1df2432 +000004b8 <[^>]*> 4ac4100f c2 0xc4100f +000004bc <[^>]*> 4886208f 0x4886208f +000004c0 <[^>]*> 4bcf218f c2 0x1cf218f +000004c4 <[^>]*> 4bdf310f c2 0x1df310f +000004c8 <[^>]*> 4ac4100e c2 0xc4100e +000004cc <[^>]*> 4886208e 0x4886208e +000004d0 <[^>]*> 4bcf218e c2 0x1cf218e +000004d4 <[^>]*> 4bdf310e c2 0x1df310e +000004d8 <[^>]*> 4ac41002 c2 0xc41002 +000004dc <[^>]*> 48862082 0x48862082 +000004e0 <[^>]*> 4bcf2182 c2 0x1cf2182 +000004e4 <[^>]*> 4bdf3102 c2 0x1df3102 +000004e8 <[^>]*> 4ac41003 c2 0xc41003 +000004ec <[^>]*> 48862083 0x48862083 +000004f0 <[^>]*> 4bcf2183 c2 0x1cf2183 +000004f4 <[^>]*> 4bdf3103 c2 0x1df3103 +000004f8 <[^>]*> 4ac4100a c2 0xc4100a +000004fc <[^>]*> 4886208a 0x4886208a +00000500 <[^>]*> 4bcf218a c2 0x1cf218a +00000504 <[^>]*> 4bdf310a c2 0x1df310a +00000508 <[^>]*> 4ac4100d c2 0xc4100d +0000050c <[^>]*> 4886208d 0x4886208d +00000510 <[^>]*> 4bcf218d c2 0x1cf218d +00000514 <[^>]*> 4bdf310d c2 0x1df310d +00000518 <[^>]*> 48a41018 0x48a41018 +0000051c <[^>]*> 4984101f 0x4984101f +00000520 <[^>]*> 49c4101f 0x49c4101f +00000524 <[^>]*> 4904101f 0x4904101f +00000528 <[^>]*> 4944101f 0x4944101f +0000052c <[^>]*> 48c62090 0x48c62090 +00000530 <[^>]*> 4bce3110 c2 0x1ce3110 +00000534 <[^>]*> 48c62092 0x48c62092 +00000538 <[^>]*> 4bce3112 c2 0x1ce3112 +0000053c <[^>]*> 4bcd00a0 c2 0x1cd00a0 +00000540 <[^>]*> 4a0000bf c2 0xbf +00000544 <[^>]*> 480000bf 0x480000bf +00000548 <[^>]*> 490000bf bc2f 00000848 <[^>]*> +0000054c <[^>]*> 4a00103e c2 0x103e +00000550 <[^>]*> 4804103e 0x4804103e +00000554 <[^>]*> 00c52046 0xc52046 +00000558 <[^>]*> 00252442 0x252442 +0000055c <[^>]*> 00c52056 0xc52056 +00000560 <[^>]*> 0025207e 0x25207e +00000564 <[^>]*> 002520ba 0x2520ba +00000568 <[^>]*> 4ca4200f prefx 0x4,a0\(a1\) 0000056c <[^>]*> 42000020 wait -00000570 <[^>]*> 4359e260 wait 0x56789 -00000574 <[^>]*> 00000040 ssnop -00000578 <[^>]*> 70831821 clo v1,a0 -0000057c <[^>]*> 70831825 dclo v1,a0 -00000580 <[^>]*> 70831820 clz v1,a0 -00000584 <[^>]*> 70831824 dclz v1,a0 -00000588 <[^>]*> 4c440005 luxc1 \$f0,a0\(v0\) -0000058c <[^>]*> 4c44100d suxc1 \$f2,a0\(v0\) -00000590 <[^>]*> 42000008 tlbp -00000594 <[^>]*> 42000001 tlbr +00000570 <[^>]*> 42000020 wait +00000574 <[^>]*> 4359e260 wait 0x56789 +00000578 <[^>]*> 00000040 ssnop +0000057c <[^>]*> 70831821 clo v1,a0 +00000580 <[^>]*> 70831825 dclo v1,a0 +00000584 <[^>]*> 70831820 clz v1,a0 +00000588 <[^>]*> 70831824 dclz v1,a0 +0000058c <[^>]*> 4c440005 luxc1 \$f0,a0\(v0\) +00000590 <[^>]*> 4c44100d suxc1 \$f2,a0\(v0\) +00000594 <[^>]*> 42000008 tlbp +00000598 <[^>]*> 42000001 tlbr \.\.\. diff -up --recursive --new-file binutils-2.15.91-20040715.macro/gas/testsuite/gas/mips/set-arch.s binutils-2.15.91-20040715/gas/testsuite/gas/mips/set-arch.s --- binutils-2.15.91-20040715.macro/gas/testsuite/gas/mips/set-arch.s 2003-06-29 19:41:33.000000000 +0000 +++ binutils-2.15.91-20040715/gas/testsuite/gas/mips/set-arch.s 2004-07-18 19:21:55.000000000 +0000 @@ -200,11 +200,17 @@ text_label: wait 0 # disassembles without code wait 0x56789 - # Instructions in previous ISAs or CPUs which are now slightly - # different. + # For a while break for the mips32 ISA interpreted a single argument + # as a 20-bit code, placing it in the opcode differently to + # traditional ISAs. This turned out to cause problems, so it has + # been removed. This test is to assure consistent interpretation. break break 0 # disassembles without code - break 0x12345 + break 0x345 + break 0x48,0x345 # this still specifies a 20-bit code + + # Instructions in previous ISAs or CPUs which are now slightly + # different. sdbbp sdbbp 0 # disassembles without code sdbbp 0x56789 diff -up --recursive --new-file binutils-2.15.91-20040715.macro/opcodes/mips-opc.c binutils-2.15.91-20040715/opcodes/mips-opc.c --- binutils-2.15.91-20040715.macro/opcodes/mips-opc.c 2003-11-19 04:25:23.000000000 +0000 +++ binutils-2.15.91-20040715/opcodes/mips-opc.c 2004-06-26 12:42:46.000000000 +0000 @@ -274,7 +274,6 @@ const struct mips_opcode mips_builtin_op {"bnel", "s,t,p", 0x54000000, 0xfc000000, CBL|RD_s|RD_t, I2|T3 }, {"bnel", "s,I,p", 0, (int) M_BNEL_I, INSN_MACRO, I2|T3 }, {"break", "", 0x0000000d, 0xffffffff, TRAP, I1 }, -{"break", "B", 0x0000000d, 0xfc00003f, TRAP, I32 }, {"break", "c", 0x0000000d, 0xfc00ffff, TRAP, I1 }, {"break", "c,q", 0x0000000d, 0xfc00003f, TRAP, I1 }, {"c.f.d", "S,T", 0x46200030, 0xffe007ff, RD_S|RD_T|WR_CC|FP_D, I1 }, From cgd@broadcom.com Mon Jul 19 16:19:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 16:19:36 +0100 (BST) Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:29713 "EHLO mms1.broadcom.com") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 16:19:31 +0100 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 19 Jul 2004 08:19:18 -0700 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id IAA19526; Mon, 19 Jul 2004 08:18:43 -0700 (PDT) Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id i6JFJHov029224; Mon, 19 Jul 2004 08:19:17 -0700 (PDT) Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com ( 8.11.6/8.9.3) id i6JFJHI03530; Mon, 19 Jul 2004 08:19:17 -0700 X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f To: macro@linux-mips.org cc: binutils@sources.redhat.com, ddaney@avtrex.com, linux-mips@linux-mips.org, "Ralf Baechle" , "Richard Sandiford" Subject: Re: [Patch] / 0 should send SIGFPE not SIGTRAP... References: <200406281519.IAA29663@mail-sj1-2.sj.broadcom.com> From: cgd@broadcom.com Date: 19 Jul 2004 08:19:17 -0700 In-Reply-To: Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 6CE539FC2QW21899679-01-01 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: 5502 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: cgd@broadcom.com Precedence: bulk X-list: linux-mips At Mon, 19 Jul 2004 14:22:29 +0000 (UTC), "Maciej W. Rozycki" wrote: > (this has led to an address shift enlarging the > patch significantly, unfortunately). maybe add nops to pad, instead? cgd From macro@linux-mips.org Mon Jul 19 16:35:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 16:35:13 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:31457 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 16:35:07 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id D4F75477EF; Mon, 19 Jul 2004 17:35:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id BC8234762E; Mon, 19 Jul 2004 17:35:00 +0200 (CEST) Date: Mon, 19 Jul 2004 17:35:00 +0200 (CEST) From: "Maciej W. Rozycki" To: Richard Sandiford Cc: Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets 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: 5503 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@linux-mips.org Precedence: bulk X-list: linux-mips Hello Richard, Your change to gcc 3.5: 2004-05-17 Richard Sandiford * config/mips/mips.h (MASK_DEBUG_G, TARGET_DEBUG_G_MODE): Delete. (TARGET_SWITCHES): Remove debugg. * config/mips/mips.md (adddi3, ashldi3, ashrdi3, lshrdi3): Only handle TARGET_64BIT. (subdi3): Replace the define_expand with a define_insn, the latter renamed from subdi3_internal_3. (negdi2): Likewise negdi2_internal_2. (adddi3_internal_[12], subdi3_internal, ashldi3_internal{,2,3}) (ashrdi3_internal{,2,3}, lshrdi3_internal{,2,3}): Remove patterns and associated define_splits. (adddi3_internal): Renamed from adddi3_internal_3. (ashldi3_internal): Likewise ashldi3_internal4. (ashrdi3_internal): Likewise ashrdi3_internal4. (lshrdi3_internal): Likewise lshrdi3_internal4. breaks 32-bit Linux builds. Linux relies on simple operations (addition/subtraction and shifts) on "long long" variables being implemented inline without a call to libgcc, which isn't linked in. After your change Linux has unresolved references to external __ashldi3(), __ashrdi3() and __lshrdi3() functions at the final link. Here is a complete revert of the relevant changes that works for me, but please feel free to provide a replacement. Either way, please make ashldi3, ashrdi3 and lshrdi3 available for 32-bit targets again. 2004-07-19 Maciej W. Rozycki * config/mips/mips.md (ashldi3, ashrdi3, lshrdi3): Handle !TARGET_64BIT again, partially reverting the change from 2004-05-17. (ashldi3_internal{,2,3}, ashrdi3_internal{,2,3}, lshrdi3_internal{,2,3}): Restore patterns and associated define_splits. (ashldi3_internal4): Rename from ashldi3_internal. (ashrdi3_internal4): Likewise ashrdi3_internal. (lshrdi3_internal4): Likewise lshrdi3_internal. Maciej gcc-3.5.0-20040714-mips-xshxdi32.patch diff -up --recursive --new-file gcc-3.5.0-20040714.macro/gcc/config/mips/mips.md gcc-3.5.0-20040714/gcc/config/mips/mips.md --- gcc-3.5.0-20040714.macro/gcc/config/mips/mips.md 2004-07-13 04:59:54.000000000 +0000 +++ gcc-3.5.0-20040714/gcc/config/mips/mips.md 2004-07-17 19:00:14.000000000 +0000 @@ -4997,37 +4997,213 @@ dsrl\t%3,%3,1\n\ { operands[2] = GEN_INT (INTVAL (operands[2]) - 8); }) (define_expand "ashldi3" - [(set (match_operand:DI 0 "register_operand") - (ashift:DI (match_operand:DI 1 "register_operand") - (match_operand:SI 2 "arith_operand")))] - "TARGET_64BIT" + [(parallel [(set (match_operand:DI 0 "register_operand") + (ashift:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "arith_operand"))) + (clobber (match_dup 3))])] + "TARGET_64BIT || !TARGET_MIPS16" { - /* On the mips16, a shift of more than 8 is a four byte - instruction, so, for a shift between 8 and 16, it is just as - fast to do two shifts of 8 or less. If there is a lot of - shifting going on, we may win in CSE. Otherwise combine will - put the shifts back together again. This can be called by - function_arg, so we must be careful not to allocate a new - register if we've reached the reload pass. */ - if (TARGET_MIPS16 - && optimize - && GET_CODE (operands[2]) == CONST_INT - && INTVAL (operands[2]) > 8 - && INTVAL (operands[2]) <= 16 - && ! reload_in_progress - && ! reload_completed) + if (TARGET_64BIT) { - rtx temp = gen_reg_rtx (DImode); + /* On the mips16, a shift of more than 8 is a four byte + instruction, so, for a shift between 8 and 16, it is just as + fast to do two shifts of 8 or less. If there is a lot of + shifting going on, we may win in CSE. Otherwise combine will + put the shifts back together again. This can be called by + function_arg, so we must be careful not to allocate a new + register if we've reached the reload pass. */ + if (TARGET_MIPS16 + && optimize + && GET_CODE (operands[2]) == CONST_INT + && INTVAL (operands[2]) > 8 + && INTVAL (operands[2]) <= 16 + && ! reload_in_progress + && ! reload_completed) + { + rtx temp = gen_reg_rtx (DImode); - emit_insn (gen_ashldi3_internal (temp, operands[1], GEN_INT (8))); - emit_insn (gen_ashldi3_internal (operands[0], temp, - GEN_INT (INTVAL (operands[2]) - 8))); + emit_insn (gen_ashldi3_internal4 (temp, operands[1], GEN_INT (8))); + emit_insn (gen_ashldi3_internal4 (operands[0], temp, + GEN_INT (INTVAL (operands[2]) - 8))); + DONE; + } + + emit_insn (gen_ashldi3_internal4 (operands[0], operands[1], + operands[2])); DONE; } + + operands[3] = gen_reg_rtx (SImode); }) (define_insn "ashldi3_internal" + [(set (match_operand:DI 0 "register_operand" "=&d") + (ashift:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "register_operand" "d"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && !TARGET_MIPS16" + "sll\t%3,%2,26\;\ +bgez\t%3,1f%#\;\ +sll\t%M0,%L1,%2\;\ +%(b\t3f\;\ +move\t%L0,%.%)\ +\n\n\ +%~1:\;\ +%(beq\t%3,%.,2f\;\ +sll\t%M0,%M1,%2%)\ +\n\;\ +subu\t%3,%.,%2\;\ +srl\t%3,%L1,%3\;\ +or\t%M0,%M0,%3\n\ +%~2:\;\ +sll\t%L0,%L1,%2\n\ +%~3:" + [(set_attr "type" "multi") + (set_attr "mode" "SI") + (set_attr "length" "48")]) + + +(define_insn "ashldi3_internal2" + [(set (match_operand:DI 0 "register_operand" "=d") + (ashift:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "small_int" "IJK"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && !TARGET_MIPS16 + && (INTVAL (operands[2]) & 32) != 0" +{ + operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f); + return "sll\t%M0,%L1,%2\;move\t%L0,%."; +} + [(set_attr "type" "multi") + (set_attr "mode" "DI") + (set_attr "length" "8")]) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (ashift:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && !WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 32) != 0" + + [(set (subreg:SI (match_dup 0) 4) (ashift:SI (subreg:SI (match_dup 1) 0) (match_dup 2))) + (set (subreg:SI (match_dup 0) 0) (const_int 0))] + + "operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f);") + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (ashift:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 32) != 0" + + [(set (subreg:SI (match_dup 0) 0) (ashift:SI (subreg:SI (match_dup 1) 4) (match_dup 2))) + (set (subreg:SI (match_dup 0) 4) (const_int 0))] + + "operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f);") + + +(define_insn "ashldi3_internal3" + [(set (match_operand:DI 0 "register_operand" "=d") + (ashift:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "small_int" "IJK"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && !TARGET_MIPS16 + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" +{ + int amount = INTVAL (operands[2]); + + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); + + return "sll\t%M0,%M1,%2\;srl\t%3,%L1,%4\;or\t%M0,%M0,%3\;sll\t%L0,%L1,%2"; +} + [(set_attr "type" "multi") + (set_attr "mode" "DI") + (set_attr "length" "16")]) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (ashift:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && !WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" + + [(set (subreg:SI (match_dup 0) 4) + (ashift:SI (subreg:SI (match_dup 1) 4) + (match_dup 2))) + + (set (match_dup 3) + (lshiftrt:SI (subreg:SI (match_dup 1) 0) + (match_dup 4))) + + (set (subreg:SI (match_dup 0) 4) + (ior:SI (subreg:SI (match_dup 0) 4) + (match_dup 3))) + + (set (subreg:SI (match_dup 0) 0) + (ashift:SI (subreg:SI (match_dup 1) 0) + (match_dup 2)))] +{ + int amount = INTVAL (operands[2]); + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); +}) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (ashift:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" + + [(set (subreg:SI (match_dup 0) 0) + (ashift:SI (subreg:SI (match_dup 1) 0) + (match_dup 2))) + + (set (match_dup 3) + (lshiftrt:SI (subreg:SI (match_dup 1) 4) + (match_dup 4))) + + (set (subreg:SI (match_dup 0) 0) + (ior:SI (subreg:SI (match_dup 0) 0) + (match_dup 3))) + + (set (subreg:SI (match_dup 0) 4) + (ashift:SI (subreg:SI (match_dup 1) 4) + (match_dup 2)))] +{ + int amount = INTVAL (operands[2]); + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); +}) + + +(define_insn "ashldi3_internal4" [(set (match_operand:DI 0 "register_operand" "=d") (ashift:DI (match_operand:DI 1 "register_operand" "d") (match_operand:SI 2 "arith_operand" "dI")))] @@ -5157,33 +5333,208 @@ dsrl\t%3,%3,1\n\ { operands[2] = GEN_INT (INTVAL (operands[2]) - 8); }) (define_expand "ashrdi3" - [(set (match_operand:DI 0 "register_operand") - (ashiftrt:DI (match_operand:DI 1 "register_operand") - (match_operand:SI 2 "arith_operand")))] - "TARGET_64BIT" + [(parallel [(set (match_operand:DI 0 "register_operand") + (ashiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "arith_operand"))) + (clobber (match_dup 3))])] + "TARGET_64BIT || !TARGET_MIPS16" { - /* On the mips16, a shift of more than 8 is a four byte - instruction, so, for a shift between 8 and 16, it is just as - fast to do two shifts of 8 or less. If there is a lot of - shifting going on, we may win in CSE. Otherwise combine will - put the shifts back together again. */ - if (TARGET_MIPS16 - && optimize - && GET_CODE (operands[2]) == CONST_INT - && INTVAL (operands[2]) > 8 - && INTVAL (operands[2]) <= 16) + if (TARGET_64BIT) { - rtx temp = gen_reg_rtx (DImode); + /* On the mips16, a shift of more than 8 is a four byte + instruction, so, for a shift between 8 and 16, it is just as + fast to do two shifts of 8 or less. If there is a lot of + shifting going on, we may win in CSE. Otherwise combine will + put the shifts back together again. */ + if (TARGET_MIPS16 + && optimize + && GET_CODE (operands[2]) == CONST_INT + && INTVAL (operands[2]) > 8 + && INTVAL (operands[2]) <= 16) + { + rtx temp = gen_reg_rtx (DImode); + + emit_insn (gen_ashrdi3_internal4 (temp, operands[1], GEN_INT (8))); + emit_insn (gen_ashrdi3_internal4 (operands[0], temp, + GEN_INT (INTVAL (operands[2]) - 8))); + DONE; + } - emit_insn (gen_ashrdi3_internal (temp, operands[1], GEN_INT (8))); - emit_insn (gen_ashrdi3_internal (operands[0], temp, - GEN_INT (INTVAL (operands[2]) - 8))); + emit_insn (gen_ashrdi3_internal4 (operands[0], operands[1], + operands[2])); DONE; } + + operands[3] = gen_reg_rtx (SImode); }) (define_insn "ashrdi3_internal" + [(set (match_operand:DI 0 "register_operand" "=&d") + (ashiftrt:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "register_operand" "d"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && !TARGET_MIPS16" + "sll\t%3,%2,26\;\ +bgez\t%3,1f%#\;\ +sra\t%L0,%M1,%2\;\ +%(b\t3f\;\ +sra\t%M0,%M1,31%)\ +\n\n\ +%~1:\;\ +%(beq\t%3,%.,2f\;\ +srl\t%L0,%L1,%2%)\ +\n\;\ +subu\t%3,%.,%2\;\ +sll\t%3,%M1,%3\;\ +or\t%L0,%L0,%3\n\ +%~2:\;\ +sra\t%M0,%M1,%2\n\ +%~3:" + [(set_attr "type" "multi") + (set_attr "mode" "DI") + (set_attr "length" "48")]) + + +(define_insn "ashrdi3_internal2" + [(set (match_operand:DI 0 "register_operand" "=d") + (ashiftrt:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "small_int" "IJK"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && (INTVAL (operands[2]) & 32) != 0" +{ + operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f); + return "sra\t%L0,%M1,%2\;sra\t%M0,%M1,31"; +} + [(set_attr "type" "multi") + (set_attr "mode" "DI") + (set_attr "length" "8")]) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (ashiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && !WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 32) != 0" + + [(set (subreg:SI (match_dup 0) 0) (ashiftrt:SI (subreg:SI (match_dup 1) 4) (match_dup 2))) + (set (subreg:SI (match_dup 0) 4) (ashiftrt:SI (subreg:SI (match_dup 1) 4) (const_int 31)))] + + "operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f);") + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (ashiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 32) != 0" + + [(set (subreg:SI (match_dup 0) 4) (ashiftrt:SI (subreg:SI (match_dup 1) 0) (match_dup 2))) + (set (subreg:SI (match_dup 0) 0) (ashiftrt:SI (subreg:SI (match_dup 1) 0) (const_int 31)))] + + "operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f);") + + +(define_insn "ashrdi3_internal3" + [(set (match_operand:DI 0 "register_operand" "=d") + (ashiftrt:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "small_int" "IJK"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && !TARGET_MIPS16 + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" +{ + int amount = INTVAL (operands[2]); + + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); + + return "srl\t%L0,%L1,%2\;sll\t%3,%M1,%4\;or\t%L0,%L0,%3\;sra\t%M0,%M1,%2"; +} + [(set_attr "type" "multi") + (set_attr "mode" "DI") + (set_attr "length" "16")]) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (ashiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && !WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" + + [(set (subreg:SI (match_dup 0) 0) + (lshiftrt:SI (subreg:SI (match_dup 1) 0) + (match_dup 2))) + + (set (match_dup 3) + (ashift:SI (subreg:SI (match_dup 1) 4) + (match_dup 4))) + + (set (subreg:SI (match_dup 0) 0) + (ior:SI (subreg:SI (match_dup 0) 0) + (match_dup 3))) + + (set (subreg:SI (match_dup 0) 4) + (ashiftrt:SI (subreg:SI (match_dup 1) 4) + (match_dup 2)))] +{ + int amount = INTVAL (operands[2]); + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); +}) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (ashiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" + + [(set (subreg:SI (match_dup 0) 4) + (lshiftrt:SI (subreg:SI (match_dup 1) 4) + (match_dup 2))) + + (set (match_dup 3) + (ashift:SI (subreg:SI (match_dup 1) 0) + (match_dup 4))) + + (set (subreg:SI (match_dup 0) 4) + (ior:SI (subreg:SI (match_dup 0) 4) + (match_dup 3))) + + (set (subreg:SI (match_dup 0) 0) + (ashiftrt:SI (subreg:SI (match_dup 1) 0) + (match_dup 2)))] +{ + int amount = INTVAL (operands[2]); + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); +}) + + +(define_insn "ashrdi3_internal4" [(set (match_operand:DI 0 "register_operand" "=d") (ashiftrt:DI (match_operand:DI 1 "register_operand" "d") (match_operand:SI 2 "arith_operand" "dI")))] @@ -5332,33 +5683,209 @@ dsrl\t%3,%3,1\n\ (set_attr "length" "16")]) (define_expand "lshrdi3" - [(set (match_operand:DI 0 "register_operand") - (lshiftrt:DI (match_operand:DI 1 "register_operand") - (match_operand:SI 2 "arith_operand")))] - "TARGET_64BIT" + [(parallel [(set (match_operand:DI 0 "register_operand") + (lshiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "arith_operand"))) + (clobber (match_dup 3))])] + "TARGET_64BIT || !TARGET_MIPS16" { - /* On the mips16, a shift of more than 8 is a four byte - instruction, so, for a shift between 8 and 16, it is just as - fast to do two shifts of 8 or less. If there is a lot of - shifting going on, we may win in CSE. Otherwise combine will - put the shifts back together again. */ - if (TARGET_MIPS16 - && optimize - && GET_CODE (operands[2]) == CONST_INT - && INTVAL (operands[2]) > 8 - && INTVAL (operands[2]) <= 16) + if (TARGET_64BIT) { - rtx temp = gen_reg_rtx (DImode); + /* On the mips16, a shift of more than 8 is a four byte + instruction, so, for a shift between 8 and 16, it is just as + fast to do two shifts of 8 or less. If there is a lot of + shifting going on, we may win in CSE. Otherwise combine will + put the shifts back together again. */ + if (TARGET_MIPS16 + && optimize + && GET_CODE (operands[2]) == CONST_INT + && INTVAL (operands[2]) > 8 + && INTVAL (operands[2]) <= 16) + { + rtx temp = gen_reg_rtx (DImode); - emit_insn (gen_lshrdi3_internal (temp, operands[1], GEN_INT (8))); - emit_insn (gen_lshrdi3_internal (operands[0], temp, - GEN_INT (INTVAL (operands[2]) - 8))); + emit_insn (gen_lshrdi3_internal4 (temp, operands[1], GEN_INT (8))); + emit_insn (gen_lshrdi3_internal4 (operands[0], temp, + GEN_INT (INTVAL (operands[2]) - 8))); + DONE; + } + + emit_insn (gen_lshrdi3_internal4 (operands[0], operands[1], + operands[2])); DONE; } + + operands[3] = gen_reg_rtx (SImode); }) (define_insn "lshrdi3_internal" + [(set (match_operand:DI 0 "register_operand" "=&d") + (lshiftrt:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "register_operand" "d"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && !TARGET_MIPS16" + "sll\t%3,%2,26\;\ +bgez\t%3,1f%#\;\ +srl\t%L0,%M1,%2\;\ +%(b\t3f\;\ +move\t%M0,%.%)\ +\n\n\ +%~1:\;\ +%(beq\t%3,%.,2f\;\ +srl\t%L0,%L1,%2%)\ +\n\;\ +subu\t%3,%.,%2\;\ +sll\t%3,%M1,%3\;\ +or\t%L0,%L0,%3\n\ +%~2:\;\ +srl\t%M0,%M1,%2\n\ +%~3:" + [(set_attr "type" "multi") + (set_attr "mode" "DI") + (set_attr "length" "48")]) + + +(define_insn "lshrdi3_internal2" + [(set (match_operand:DI 0 "register_operand" "=d") + (lshiftrt:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "small_int" "IJK"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && !TARGET_MIPS16 + && (INTVAL (operands[2]) & 32) != 0" +{ + operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f); + return "srl\t%L0,%M1,%2\;move\t%M0,%."; +} + [(set_attr "type" "multi") + (set_attr "mode" "DI") + (set_attr "length" "8")]) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (lshiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && !WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 32) != 0" + + [(set (subreg:SI (match_dup 0) 0) (lshiftrt:SI (subreg:SI (match_dup 1) 4) (match_dup 2))) + (set (subreg:SI (match_dup 0) 4) (const_int 0))] + + "operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f);") + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (lshiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 32) != 0" + + [(set (subreg:SI (match_dup 0) 4) (lshiftrt:SI (subreg:SI (match_dup 1) 0) (match_dup 2))) + (set (subreg:SI (match_dup 0) 0) (const_int 0))] + + "operands[2] = GEN_INT (INTVAL (operands[2]) & 0x1f);") + + +(define_insn "lshrdi3_internal3" + [(set (match_operand:DI 0 "register_operand" "=d") + (lshiftrt:DI (match_operand:DI 1 "register_operand" "d") + (match_operand:SI 2 "small_int" "IJK"))) + (clobber (match_operand:SI 3 "register_operand" "=d"))] + "!TARGET_64BIT && !TARGET_MIPS16 + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" +{ + int amount = INTVAL (operands[2]); + + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); + + return "srl\t%L0,%L1,%2\;sll\t%3,%M1,%4\;or\t%L0,%L0,%3\;srl\t%M0,%M1,%2"; +} + [(set_attr "type" "multi") + (set_attr "mode" "DI") + (set_attr "length" "16")]) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (lshiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && !WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" + + [(set (subreg:SI (match_dup 0) 0) + (lshiftrt:SI (subreg:SI (match_dup 1) 0) + (match_dup 2))) + + (set (match_dup 3) + (ashift:SI (subreg:SI (match_dup 1) 4) + (match_dup 4))) + + (set (subreg:SI (match_dup 0) 0) + (ior:SI (subreg:SI (match_dup 0) 0) + (match_dup 3))) + + (set (subreg:SI (match_dup 0) 4) + (lshiftrt:SI (subreg:SI (match_dup 1) 4) + (match_dup 2)))] +{ + int amount = INTVAL (operands[2]); + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); +}) + + +(define_split + [(set (match_operand:DI 0 "register_operand") + (lshiftrt:DI (match_operand:DI 1 "register_operand") + (match_operand:SI 2 "small_int"))) + (clobber (match_operand:SI 3 "register_operand"))] + "reload_completed && WORDS_BIG_ENDIAN && !TARGET_64BIT + && !TARGET_DEBUG_D_MODE && !TARGET_MIPS16 + && GET_CODE (operands[0]) == REG && REGNO (operands[0]) < FIRST_PSEUDO_REGISTER + && GET_CODE (operands[1]) == REG && REGNO (operands[1]) < FIRST_PSEUDO_REGISTER + && (INTVAL (operands[2]) & 63) < 32 + && (INTVAL (operands[2]) & 63) != 0" + + [(set (subreg:SI (match_dup 0) 4) + (lshiftrt:SI (subreg:SI (match_dup 1) 4) + (match_dup 2))) + + (set (match_dup 3) + (ashift:SI (subreg:SI (match_dup 1) 0) + (match_dup 4))) + + (set (subreg:SI (match_dup 0) 4) + (ior:SI (subreg:SI (match_dup 0) 4) + (match_dup 3))) + + (set (subreg:SI (match_dup 0) 0) + (lshiftrt:SI (subreg:SI (match_dup 1) 0) + (match_dup 2)))] +{ + int amount = INTVAL (operands[2]); + operands[2] = GEN_INT (amount & 31); + operands[4] = GEN_INT ((-amount) & 31); +}) + + +(define_insn "lshrdi3_internal4" [(set (match_operand:DI 0 "register_operand" "=d") (lshiftrt:DI (match_operand:DI 1 "register_operand" "d") (match_operand:SI 2 "arith_operand" "dI")))] From macro@linux-mips.org Mon Jul 19 16:42:49 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 16:42:53 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:33249 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 16:42:49 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id DC323477EF; Mon, 19 Jul 2004 17:42:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id BD9834762E; Mon, 19 Jul 2004 17:42:42 +0200 (CEST) Date: Mon, 19 Jul 2004 17:42:42 +0200 (CEST) From: "Maciej W. Rozycki" To: cgd@broadcom.com Cc: binutils@sources.redhat.com, ddaney@avtrex.com, linux-mips@linux-mips.org, Ralf Baechle , Richard Sandiford Subject: Re: [Patch] / 0 should send SIGFPE not SIGTRAP... In-Reply-To: Message-ID: References: <200406281519.IAA29663@mail-sj1-2.sj.broadcom.com> 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: 5504 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@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 19 Jul 2004 cgd@broadcom.com wrote: > At Mon, 19 Jul 2004 14:22:29 +0000 (UTC), "Maciej W. Rozycki" wrote: > > (this has led to an address shift enlarging the > > patch significantly, unfortunately). > > maybe add nops to pad, instead? Well, addresses have been shifted down, so you'd have to remove something. I suppose the break tests could be moved to the end of file, but I fail to see an advantage. Test cases that embed addresses in output patterns are doomed to suffer from such changes. Maciej From martin.nichols@oxinst.co.uk Mon Jul 19 16:45:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 16:45:26 +0100 (BST) Received: from mail57.messagelabs.com ([IPv6:::ffff:195.245.230.115]:58090 "HELO mail57.messagelabs.com") by linux-mips.org with SMTP id ; Mon, 19 Jul 2004 16:45:21 +0100 X-VirusChecked: Checked X-Env-Sender: martin.nichols@oxinst.co.uk X-Msg-Ref: server-2.tower-57.messagelabs.com!1090251907!10403102 X-StarScan-Version: 5.2.10; banners=-,-,- X-Originating-IP: [194.200.52.193] Received: (qmail 16908 invoked from network); 19 Jul 2004 15:45:07 -0000 Received: from smtp1.oxinst.co.uk (HELO ukhontx01.oxinst.co.uk) (194.200.52.193) by server-2.tower-57.messagelabs.com with SMTP; 19 Jul 2004 15:45:07 -0000 Received: by UKHONTX01 with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Jul 2004 16:45:05 +0100 Message-ID: From: martin.nichols@oxinst.co.uk To: linux-mips@linux-mips.org Subject: Link errors Date: Mon, 19 Jul 2004 16:48:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: 5505 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: martin.nichols@oxinst.co.uk Precedence: bulk X-list: linux-mips Hi All, I'm new to MIPs architecture and Linux so apologies in advance! I'm trying to build an application to run on the Au1100. I have a crosscompiler setup (gcc 3.2) and can build a 'hello world' that runs on the target. When I try building a more serious application using Kdevelop - with the appropriate settings for the crosstools - I get lots of errors like this: assert.o(.text+0x1cc): relocation truncated to fit: R_MIPS_GOT16 __assert_program_name /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/mipsel-unknown -linux-gnu/lib/libc.a(dcigettext.o): In function `_nl_find_msg': dcigettext.o(.text+0x153c): relocation truncated to fit: R_MIPS_CALL16 _nl_load_domain /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/mipsel-unknown -linux-gnu/lib/libc.a(finddomain.o): In function `_nl_find_domain': Could someone tell me what I'm doing wrong please. Thanks, Martin. ### OXFORD INSTRUMENTS http://www.oxford-instruments.com/ ### Unless stated above to be non-confidential, this E-mail and any attachments are private and confidential and are for the addressee only and may not be used, copied or disclosed save to the addressee. If you have received this E-mail in error please notify us upon receipt and delete it from your records. Internet communications are not secure and Oxford Instruments is not responsible for their abuse by third parties nor for any alteration or corruption in transmission. From ddaney@avtrex.com Mon Jul 19 17:47:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 17:48:04 +0100 (BST) Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:64303 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 17:47:57 +0100 Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jul 2004 09:47:43 -0700 Message-ID: <40FBFA43.4080305@avtrex.com> Date: Mon, 19 Jul 2004 09:43:47 -0700 From: David Daney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: martin.nichols@oxinst.co.uk CC: linux-mips@linux-mips.org Subject: Re: Link errors References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2004 16:47:43.0905 (UTC) FILETIME=[1CDBB910:01C46DB0] 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: 5506 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: ddaney@avtrex.com Precedence: bulk X-list: linux-mips martin.nichols@oxinst.co.uk wrote: > Hi All, > > I'm new to MIPs architecture and Linux so apologies in advance! > > I'm trying to build an application to run on the Au1100. > I have a crosscompiler setup (gcc 3.2) and can build a 'hello world' that > runs on the target. > When I try building a more serious application using Kdevelop - with the > appropriate settings > for the crosstools - I get lots of errors like this: > assert.o(.text+0x1cc): relocation truncated to fit: R_MIPS_GOT16 > __assert_program_name > /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/mipsel-unknown > -linux-gnu/lib/libc.a(dcigettext.o): In function `_nl_find_msg': > dcigettext.o(.text+0x153c): relocation truncated to fit: R_MIPS_CALL16 > _nl_load_domain > /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/mipsel-unknown > -linux-gnu/lib/libc.a(finddomain.o): In function `_nl_find_domain': > > Could someone tell me what I'm doing wrong please. > This is the got overflow problem. Later versions of binutils have multi-got support (2.15 for example), which under most circumstances will fix the problem. If you have extreamly large compilation units you might have to use a 32bit got index. In GCC3.4 and later this is done with the -mxgot option. With eariler versions of GCC you have to pass -xgot to the assembler (-Wa,-xgot IIRC). David Daney. From rsandifo@redhat.com Mon Jul 19 17:59:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 17:59:20 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:45728 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 17:59:15 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6JGxEe1026873; Mon, 19 Jul 2004 12:59:14 -0400 Received: from localhost (mail@vpnuser5.surrey.redhat.com [172.16.9.5]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6JGxDa23738; Mon, 19 Jul 2004 12:59:13 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1BmbTr-000087-00; Mon, 19 Jul 2004 17:59:11 +0100 To: "Maciej W. Rozycki" Cc: Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets References: From: Richard Sandiford Date: Mon, 19 Jul 2004 17:59:11 +0100 In-Reply-To: (Maciej W. Rozycki's message of "Mon, 19 Jul 2004 17:35:00 +0200 (CEST)") Message-ID: <87hds49bmo.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: 5507 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: rsandifo@redhat.com Precedence: bulk X-list: linux-mips "Maciej W. Rozycki" writes: > Linux relies on simple operations (addition/subtraction and shifts) on > "long long" variables being implemented inline without a call to > libgcc, which isn't linked in. Sorry, but I don't think this is a reasonable expection for 64-bit shifts on 32-bit targets. If linux insists on not using libgcc, it should provide: > After your change Linux has unresolved references to external __ashldi3(), > __ashrdi3() and __lshrdi3() functions at the final link. ...these functions itself. Richard From dje@watson.ibm.com Mon Jul 19 18:33:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 18:33:20 +0100 (BST) Received: from igw2.watson.ibm.com ([IPv6:::ffff:129.34.20.6]:32222 "EHLO igw2.watson.ibm.com") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 18:33:16 +0100 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i6JHVvW37280; Mon, 19 Jul 2004 13:31:58 -0400 Received: from makai.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i6JHWxs50616; Mon, 19 Jul 2004 13:32:59 -0400 Received: from watson.ibm.com (localhost [127.0.0.1]) by makai.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i6JHWpD28554; Mon, 19 Jul 2004 13:32:52 -0400 Message-Id: <200407191732.i6JHWpD28554@makai.watson.ibm.com> To: Richard Sandiford cc: "Maciej W. Rozycki" , Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bittargets References: <87hds49bmo.fsf@redhat.com> Date: Mon, 19 Jul 2004 13:32:51 -0400 From: David Edelsohn 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: 5508 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: dje@watson.ibm.com Precedence: bulk X-list: linux-mips >>>>> Richard Sandiford writes: > Sorry, but I don't think this is a reasonable expection for 64-bit > shifts on 32-bit targets. If linux insists on not using libgcc, > it should provide: Other targets provide those DImode operations. Part of the mission of GCC is to support GNU and GNU/Linux. David From macro@linux-mips.org Mon Jul 19 18:33:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 18:33:48 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:62177 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 18:33:20 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 1FE1C47B51; Mon, 19 Jul 2004 19:33:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 1231B477EF; Mon, 19 Jul 2004 19:33:14 +0200 (CEST) Date: Mon, 19 Jul 2004 19:33:14 +0200 (CEST) From: "Maciej W. Rozycki" To: Richard Sandiford Cc: Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets In-Reply-To: <87hds49bmo.fsf@redhat.com> Message-ID: References: <87hds49bmo.fsf@redhat.com> 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: 5509 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@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 19 Jul 2004, Richard Sandiford wrote: > > Linux relies on simple operations (addition/subtraction and shifts) on > > "long long" variables being implemented inline without a call to > > libgcc, which isn't linked in. > > Sorry, but I don't think this is a reasonable expection for 64-bit > shifts on 32-bit targets. If linux insists on not using libgcc, See e.g: "http://www.ussg.iu.edu/hypermail/linux/kernel/0009.2/0655.html" for a rationale behind that. > it should provide: > > > After your change Linux has unresolved references to external __ashldi3(), > > __ashrdi3() and __lshrdi3() functions at the final link. > > ...these functions itself. Well, other targets, like the i386 (which didn't even have a 64-bit variation till recently), do not force Linux to go through such contortions. I can't see a reason why MIPS should be different -- it's not any harder to implement shifts for this processor than for an average other platform. Anyway, the patch works for me and it has been published so that others can use it, thus I have no incentive to do anything else, sorry. Maciej From rsandifo@redhat.com Mon Jul 19 18:37:11 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 18:37:15 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:47540 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 18:37:11 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6JHbAe1004699; Mon, 19 Jul 2004 13:37:10 -0400 Received: from localhost (mail@vpnuser5.surrey.redhat.com [172.16.9.5]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6JHb9a03018; Mon, 19 Jul 2004 13:37:09 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1Bmc4a-00009l-00; Mon, 19 Jul 2004 18:37:08 +0100 To: "Maciej W. Rozycki" Cc: Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets References: <87hds49bmo.fsf@redhat.com> From: Richard Sandiford Date: Mon, 19 Jul 2004 18:37:08 +0100 In-Reply-To: (Maciej W. Rozycki's message of "Mon, 19 Jul 2004 19:33:14 +0200 (CEST)") Message-ID: <87zn5v99vf.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: 5510 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: rsandifo@redhat.com Precedence: bulk X-list: linux-mips "Maciej W. Rozycki" writes: > Well, other targets, like the i386 (which didn't even have a 64-bit > variation till recently), do not force Linux to go through such > contortions. But arm targets (for instance) don't provide inline 64-bit shifts, do they? I don't think there's anything special in the MIPS ISA that makes them easier for MIPS than they are for ARM. Richard From havner@pld-linux.org Mon Jul 19 20:00:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 20:00:50 +0100 (BST) Received: from sirius.livecd.pl ([IPv6:::ffff:83.243.111.250]:8969 "EHLO sirius.livecd.pl") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Mon, 19 Jul 2004 20:00:45 +0100 Received: from localhost ([127.0.0.1] ident=havner) by sirius.livecd.pl with esmtp (Exim 4.32) id 1BmdOx-0004S5-Gq for linux-mips@linux-mips.org; Mon, 19 Jul 2004 21:02:15 +0200 From: havner To: linux-mips@linux-mips.org Subject: DECstation 5000/20 Date: Mon, 19 Jul 2004 21:02:14 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Message-Id: <200407192102.15261.havner@pld-linux.org> 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: 5511 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: havner@pld-linux.org Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What's the recommended kernel for this machine? I've only managed to boot 2.4.17 from debian and 2.4.18 http://www.xs4all.nl/~vhouten/mipsel/vmlinux-2.4.18-decR3k.ecoff.tgz Unfortunately both of them freezes system (RH7.1/RH7.3) f.e. when trying to cat /proc/cpuinfo. No oops, no message on serial, just hard freeze. using rpm also likes to freeze this machine. I've tried co cross compile kernel from cvs at linux-mips.org, but it stop at boot time just after setting high precission timer. vanila kernel (2.6.7) ends with kernel panic. cross tools used: 1. the newest versions from: ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/mipsel-linux 2. self compiled: $ mipsel-pld-linux-gcc -v Reading specs from /usr/lib/gcc-lib/mipsel-pld-linux/3.3.4/specs Configured with: ../configure --prefix=/usr --infodir=/usr/share/info - --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/lib - --libexecdir=/usr/lib --includedir=/usr/mipsel-pld-linux/include - --disable-shared --disable-threads --enable-languages=c --with-gnu-as - --with-gnu-ld --with-system-zlib --with-multilib --without-x - --build=athlon-pld-linux --host=athlon-pld-linux --target=mipsel-pld-linux Thread model: single gcc version 3.3.4 $ mipsel-pld-linux-ld -v GNU ld version 2.15.91.0.1 20040527 The same effect on both. I cannot find any patches for decstation on the net Are there any more mips kernel repositories over the net? I've got this machine two days ago and I'm trying to make small PLD port there. I would be gratefull for any help. - -- Regards Havner http://livecd.pld-linux.org GG: 2846839 jid,mail: havner(at)pld-linux.org "We live as we dream, alone" - Joseph Conrad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/Bq2gvS01FGjsR8RAvf+AKDKvYER+aHg9MllDJ0do8xwpBswpgCfY829 cj2WQZc1m+lpU8+aQxo8T7Q= =RDi8 -----END PGP SIGNATURE----- From rth@redhat.com Mon Jul 19 22:38:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 22:38:12 +0100 (BST) Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:50562 "EHLO mx2.redhat.com") by linux-mips.org with ESMTP id ; Mon, 19 Jul 2004 22:38:08 +0100 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i6JLY0St018951; Mon, 19 Jul 2004 17:34:00 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6JLc2H20039; Mon, 19 Jul 2004 17:38:02 -0400 Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i6JLc1L15600; Mon, 19 Jul 2004 14:38:01 -0700 Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1]) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i6JLc1Qw016347; Mon, 19 Jul 2004 14:38:01 -0700 Received: (from rth@localhost) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i6JLc1ud016345; Mon, 19 Jul 2004 14:38:01 -0700 X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Mon, 19 Jul 2004 14:38:01 -0700 From: Richard Henderson To: "Maciej W. Rozycki" Cc: Richard Sandiford , Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets Message-ID: <20040719213801.GD14931@redhat.com> Mail-Followup-To: Richard Henderson , "Maciej W. Rozycki" , Richard Sandiford , Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org References: <87hds49bmo.fsf@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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: 5512 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: rth@redhat.com Precedence: bulk X-list: linux-mips On Mon, Jul 19, 2004 at 07:33:14PM +0200, Maciej W. Rozycki wrote: > Well, other targets, like the i386 (which didn't even have a 64-bit > variation till recently)... Except that 80386 has 64-bit shifts in hardware. And in rebuttal to the "does not make linux jump through hoops" argument, see arch/*/lib/ for arm, h8300, m68k, sparc, v850. r~ From havner@pld-linux.org Mon Jul 19 23:20:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jul 2004 23:20:09 +0100 (BST) Received: from sirius.livecd.pl ([IPv6:::ffff:83.243.111.250]:18188 "EHLO sirius.livecd.pl") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Mon, 19 Jul 2004 23:20:04 +0100 Received: from localhost ([127.0.0.1] ident=havner) by sirius.livecd.pl with esmtp (Exim 4.32) id 1BmgVq-0000mp-HE for linux-mips@linux-mips.org; Tue, 20 Jul 2004 00:21:34 +0200 From: havner To: linux-mips@linux-mips.org Subject: -r linux_2_4, undefined references Date: Tue, 20 Jul 2004 00:21:31 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Message-Id: <200407200021.33512.havner@pld-linux.org> 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: 5513 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: havner@pld-linux.org Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 log from building -r linux_2_4 (linux module from linux-mips.org) cross development tools as described in my previous post in point 2. http://ep09.pld-linux.org/~havner/log.gz http://ep09.pld-linux.org/~havner/.config - -- Regards Havner http://livecd.pld-linux.org GG: 2846839 jid,mail: havner(at)pld-linux.org "We live as we dream, alone" - Joseph Conrad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/ElsgvS01FGjsR8RAqEAAKCpRNFLu2smwFuBWl6bSOIWcis7IACfWcOP VRzBr7Pw5yTxRN9TLNlYHJM= =3nxo -----END PGP SIGNATURE----- From ica2_ts@csv.ica.uni-stuttgart.de Tue Jul 20 00:24:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 00:24:59 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:59707 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Tue, 20 Jul 2004 00:24:53 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1BmhV4-0008TH-00; Tue, 20 Jul 2004 01:24:50 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1BmhV3-0002pL-00; Tue, 20 Jul 2004 01:24:49 +0200 Date: Tue, 20 Jul 2004 01:24:49 +0200 To: havner Cc: linux-mips@linux-mips.org Subject: Re: DECstation 5000/20 Message-ID: <20040719232449.GA965@rembrandt.csv.ica.uni-stuttgart.de> References: <200407192102.15261.havner@pld-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407192102.15261.havner@pld-linux.org> User-Agent: Mutt/1.5.6i 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: 5514 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 havner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > What's the recommended kernel for this machine? > I've only managed to boot 2.4.17 from debian and 2.4.18 > http://www.xs4all.nl/~vhouten/mipsel/vmlinux-2.4.18-decR3k.ecoff.tgz This is very old. > Unfortunately both of them freezes system (RH7.1/RH7.3) f.e. when trying to > cat /proc/cpuinfo. No oops, no message on serial, just hard freeze. Fixed in newer 2.4 kernels from linux-mips.org. > using rpm also likes to freeze this machine. I've tried co cross compile > kernel from cvs at linux-mips.org, but it stop at boot time just after > setting high precission timer. vanila kernel (2.6.7) ends with kernel panic. linux-mips.org CVS, -r linux_2_4, should work for serial console. Debian has a r3k-kn02 kernel package for mipsel which is supposed to work as well. Thiemo From ica2_ts@csv.ica.uni-stuttgart.de Tue Jul 20 00:29:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 00:29:19 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:3644 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Tue, 20 Jul 2004 00:29:15 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1BmhZK-0008WO-00; Tue, 20 Jul 2004 01:29:14 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1BmhZI-0002qd-00; Tue, 20 Jul 2004 01:29:12 +0200 Date: Tue, 20 Jul 2004 01:29:12 +0200 To: "Maciej W. Rozycki" Cc: binutils@sources.redhat.com, cgd@broadcom.com, ddaney@avtrex.com, linux-mips@linux-mips.org, Ralf Baechle , Richard Sandiford Subject: Re: [Patch] / 0 should send SIGFPE not SIGTRAP... Message-ID: <20040719232912.GB965@rembrandt.csv.ica.uni-stuttgart.de> References: <200406281519.IAA29663@mail-sj1-2.sj.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i 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: 5515 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 Maciej W. Rozycki wrote: [snip] > opcodes/: > 2004-07-19 Maciej W. Rozycki > > * mips-opc.c (mips_builtin_opcodes): Remove the MIPS32 > ISA-specific "break" encoding. > > gas/testsuite/: > 2004-07-19 Maciej W. Rozycki > > * gas/mips/mips32.s: Adjust for the unified "break" syntax. Add > another "break" case. Update the comment accordingly. > * gas/mips/set-arch.s: Likewise. > * gas/mips/mips32.d: Adjust for the new output. > * gas/mips/set-arch.d: Likewise. > > OK to apply? Ok. Thiemo From havner@pld-linux.org Tue Jul 20 01:00:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 01:00:51 +0100 (BST) Received: from sirius.livecd.pl ([IPv6:::ffff:83.243.111.250]:58636 "EHLO sirius.livecd.pl") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 20 Jul 2004 01:00:37 +0100 Received: from localhost ([127.0.0.1] ident=havner) by sirius.livecd.pl with esmtp (Exim 4.32) id 1Bmi5A-0006cQ-SP for linux-mips@linux-mips.org; Tue, 20 Jul 2004 02:02:08 +0200 From: havner To: linux-mips@linux-mips.org Subject: Re: DECstation 5000/20 Date: Tue, 20 Jul 2004 02:02:07 +0200 User-Agent: KMail/1.6.2 References: <200407192102.15261.havner@pld-linux.org> <20040719232449.GA965@rembrandt.csv.ica.uni-stuttgart.de> In-Reply-To: <20040719232449.GA965@rembrandt.csv.ica.uni-stuttgart.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <200407200202.08636.havner@pld-linux.org> 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: 5516 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: havner@pld-linux.org Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 July 2004 01:24, Thiemo Seufer wrote: > > Unfortunately both of them freezes system (RH7.1/RH7.3) f.e. when trying > > to cat /proc/cpuinfo. No oops, no message on serial, just hard freeze. > > Fixed in newer 2.4 kernels from linux-mips.org. I've already found, but it doesn't build (my previous post) > linux-mips.org CVS, -r linux_2_4, should work for serial console. Debian > has a r3k-kn02 kernel package for mipsel which is supposed to work as > well. The only debian image I've managed to find was 2.4.17 and it freezes the same way like 2.4.18 quoted previously :-( - -- Regards Havner http://livecd.pld-linux.org GG: 2846839 jid,mail: havner(at)pld-linux.org "We live as we dream, alone" - Joseph Conrad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/GD/gvS01FGjsR8RAiisAJ4sqiDVvk703yRN8FYOZ418UxLqvgCeO0Vp /jcXaWeh+AW1GtPZffrFC/I= =3kAl -----END PGP SIGNATURE----- From tbm@cyrius.com Tue Jul 20 01:09:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 01:09:31 +0100 (BST) Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:19217 "EHLO sorrow.cyrius.com") by linux-mips.org with ESMTP id ; Tue, 20 Jul 2004 01:09:27 +0100 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 7180E64D3B; Tue, 20 Jul 2004 00:09:24 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 867D11004E; Tue, 20 Jul 2004 01:09:09 +0100 (BST) Date: Tue, 20 Jul 2004 01:09:09 +0100 From: Martin Michlmayr To: havner Cc: linux-mips@linux-mips.org Subject: Re: DECstation 5000/20 Message-ID: <20040720000909.GA20267@deprecation.cyrius.com> References: <200407192102.15261.havner@pld-linux.org> <20040719232449.GA965@rembrandt.csv.ica.uni-stuttgart.de> <200407200202.08636.havner@pld-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407200202.08636.havner@pld-linux.org> User-Agent: Mutt/1.5.6+20040523i 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: 5517 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: tbm@cyrius.com Precedence: bulk X-list: linux-mips * havner [2004-07-20 02:02]: > The only debian image I've managed to find was 2.4.17 and it freezes the same > way like 2.4.18 quoted previously :-( http://ftp.debian.org/debian/pool/main/k/kernel-patch-2.4.26-mips/kernel-image-2.4.26-r3k-kn02_2.4.26-0.040505.1_mipsel.deb -- Martin Michlmayr tbm@cyrius.com From havner@pld-linux.org Tue Jul 20 01:24:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 01:24:35 +0100 (BST) Received: from sirius.livecd.pl ([IPv6:::ffff:83.243.111.250]:43022 "EHLO sirius.livecd.pl") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 20 Jul 2004 01:24:31 +0100 Received: from localhost ([127.0.0.1] ident=havner) by sirius.livecd.pl with esmtp (Exim 4.32) id 1BmiSJ-0000HO-BQ for linux-mips@linux-mips.org; Tue, 20 Jul 2004 02:26:03 +0200 From: havner To: linux-mips@linux-mips.org Subject: Re: DECstation 5000/20 Date: Tue, 20 Jul 2004 02:26:00 +0200 User-Agent: KMail/1.6.2 References: <200407192102.15261.havner@pld-linux.org> <200407200202.08636.havner@pld-linux.org> <20040720000909.GA20267@deprecation.cyrius.com> In-Reply-To: <20040720000909.GA20267@deprecation.cyrius.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <200407200226.02274.havner@pld-linux.org> 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: 5518 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: havner@pld-linux.org Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 July 2004 02:09, Martin Michlmayr wrote: > * havner [2004-07-20 02:02]: > > The only debian image I've managed to find was 2.4.17 and it freezes the > > same way like 2.4.18 quoted previously :-( > > http://ftp.debian.org/debian/pool/main/k/kernel-patch-2.4.26-mips/kernel-im >age-2.4.26-r3k-kn02_2.4.26-0.040505.1_mipsel.deb Thank's. I wasn't looking in packages, but around boot images. It seems thay have outdated files there. - -- Regards Havner http://livecd.pld-linux.org GG: 2846839 jid,mail: havner(at)pld-linux.org "We live as we dream, alone" - Joseph Conrad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/GaZgvS01FGjsR8RAuZYAJ99xvpk7AbXR4jIAx+/+xvlWISfDwCfQcgN 6uM1MOqMOPcALNvshvgOQZI= =m1ev -----END PGP SIGNATURE----- From havner@pld-linux.org Tue Jul 20 01:46:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 01:46:13 +0100 (BST) Received: from sirius.livecd.pl ([IPv6:::ffff:83.243.111.250]:5380 "EHLO sirius.livecd.pl") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 20 Jul 2004 01:46:09 +0100 Received: from localhost ([127.0.0.1] ident=havner) by sirius.livecd.pl with esmtp (Exim 4.32) id 1BminC-0001ZB-Ki for linux-mips@linux-mips.org; Tue, 20 Jul 2004 02:47:38 +0200 From: havner To: linux-mips@linux-mips.org Subject: Re: DECstation 5000/20 Date: Tue, 20 Jul 2004 02:47:36 +0200 User-Agent: KMail/1.6.2 References: <200407192102.15261.havner@pld-linux.org> <200407200202.08636.havner@pld-linux.org> <20040720000909.GA20267@deprecation.cyrius.com> In-Reply-To: <20040720000909.GA20267@deprecation.cyrius.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <200407200247.37881.havner@pld-linux.org> 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: 5519 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: havner@pld-linux.org Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 July 2004 02:09, you wrote: > * havner [2004-07-20 02:02]: > > The only debian image I've managed to find was 2.4.17 and it freezes the > > same way like 2.4.18 quoted previously :-( > > http://ftp.debian.org/debian/pool/main/k/kernel-patch-2.4.26-mips/kernel-im >age-2.4.26-r3k-kn02_2.4.26-0.040505.1_mipsel.deb It almost works properly. I get oopses all the time (mainly with modules operations, but not only). Maybe to old modutils and rest of the system. I'll check it tommorrow. Thank for help. I must have a look at debian patches too. - -- Regards Havner http://livecd.pld-linux.org GG: 2846839 jid,mail: havner(at)pld-linux.org "We live as we dream, alone" - Joseph Conrad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/GuogvS01FGjsR8RAtXhAKCOdGG8Vr+eikIiPCY9oP57Tbd3WgCfVyEQ 8WbsDKHhAi20jyM47m1R844= =KFzw -----END PGP SIGNATURE----- From a.voropay@vmb-service.ru Tue Jul 20 15:13:59 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 15:14:04 +0100 (BST) Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:25039 "EHLO smtp.vmb-service.ru") by linux-mips.org with ESMTP id ; Tue, 20 Jul 2004 15:13:59 +0100 Received: from office.vmb-service.ru ([80.73.192.47]:21771 "EHLO ALEC") by Altair with ESMTP id ; Tue, 20 Jul 2004 18:13:47 +0400 Reply-To: From: "Alexander Voropay" To: "'Ralf Baechle'" Cc: Subject: RE: Howto run Linux on ACER PICA 61 Date: Tue, 20 Jul 2004 18:15:04 +0400 Organization: VMB-Service Message-ID: <0aa601c46e63$f3ddbef0$0200000a@ALEC> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20040622193839.GA7082@linux-mips.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: 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: 5520 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: a.voropay@vmb-service.ru Precedence: bulk X-list: linux-mips Hi! >Linux has code for this system but it's suffering from severe bitrot. >I still have the documents here so I could help you a bit if you were willing to >resurrect the kernel - which should be relativly easy, also due to the >system's similarity to another, somewhat better supported system, >the Olivetti M700-10. I'm trying to cross-compile a kernel from the linux-mips CVS. Unfortunately, the build script does not provide a selection for the SCSI driver for the ACER PICA (/linux/drivers/scsi/NCR53C9x.h ??) and SONIC DP83932 Ethernet controller. -- -=AV=- From martin.nichols@oxinst.co.uk Tue Jul 20 15:45:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 15:45:27 +0100 (BST) Received: from mail57.messagelabs.com ([IPv6:::ffff:195.245.230.115]:14522 "HELO mail57.messagelabs.com") by linux-mips.org with SMTP id ; Tue, 20 Jul 2004 15:45:23 +0100 X-VirusChecked: Checked X-Env-Sender: martin.nichols@oxinst.co.uk X-Msg-Ref: server-6.tower-57.messagelabs.com!1090334713!10747510 X-StarScan-Version: 5.2.10; banners=-,-,- X-Originating-IP: [194.200.52.193] Received: (qmail 18160 invoked from network); 20 Jul 2004 14:45:13 -0000 Received: from smtp1.oxinst.co.uk (HELO ukhontx01.oxinst.co.uk) (194.200.52.193) by server-6.tower-57.messagelabs.com with SMTP; 20 Jul 2004 14:45:13 -0000 Received: by UKHONTX01 with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jul 2004 15:44:59 +0100 Message-ID: From: martin.nichols@oxinst.co.uk To: ddaney@avtrex.com Cc: linux-mips@linux-mips.org Subject: RE: Link errors Date: Tue, 20 Jul 2004 15:47:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: 5521 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: martin.nichols@oxinst.co.uk Precedence: bulk X-list: linux-mips David, Many thanks. I should have Googled first ;) Best regards, Martin Nichols. > -----Original Message----- > From: David Daney [SMTP:ddaney@avtrex.com] > Sent: 19 July 2004 17:44 > To: martin.nichols@oxinst.co.uk > Cc: linux-mips@linux-mips.org > Subject: Re: Link errors > > martin.nichols@oxinst.co.uk wrote: > > Hi All, > > > > I'm new to MIPs architecture and Linux so apologies in advance! > > > > I'm trying to build an application to run on the Au1100. > > I have a crosscompiler setup (gcc 3.2) and can build a 'hello world' > that > > runs on the target. > > When I try building a more serious application using Kdevelop - with the > > appropriate settings > > for the crosstools - I get lots of errors like this: > > assert.o(.text+0x1cc): relocation truncated to fit: R_MIPS_GOT16 > > __assert_program_name > > > /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/mipsel-unkno > wn > > -linux-gnu/lib/libc.a(dcigettext.o): In function `_nl_find_msg': > > dcigettext.o(.text+0x153c): relocation truncated to fit: R_MIPS_CALL16 > > _nl_load_domain > > > /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/mipsel-unkno > wn > > -linux-gnu/lib/libc.a(finddomain.o): In function `_nl_find_domain': > > > > Could someone tell me what I'm doing wrong please. > > > This is the got overflow problem. > > Later versions of binutils have multi-got support (2.15 for example), > which under most circumstances will fix the problem. > > If you have extreamly large compilation units you might have to use a > 32bit got index. In GCC3.4 and later this is done with the -mxgot > option. With eariler versions of GCC you have to pass -xgot to the > assembler (-Wa,-xgot IIRC). > > David Daney. > > > +++ Virus-scanned by Messagelabs for Oxford Instruments +++ > ### OXFORD INSTRUMENTS http://www.oxford-instruments.com/ ### Unless stated above to be non-confidential, this E-mail and any attachments are private and confidential and are for the addressee only and may not be used, copied or disclosed save to the addressee. If you have received this E-mail in error please notify us upon receipt and delete it from your records. Internet communications are not secure and Oxford Instruments is not responsible for their abuse by third parties nor for any alteration or corruption in transmission. From deepfire@elvees.com Tue Jul 20 16:01:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 16:01:32 +0100 (BST) Received: from mail.elvees.com ([IPv6:::ffff:80.92.98.198]:11459 "EHLO narwhal.elvees.dmz") by linux-mips.org with ESMTP id ; Tue, 20 Jul 2004 16:01:28 +0100 Received: from (IP:192.168.2.1) =?ISO-8859-1?Q?=9C(authenticated?= with LOGIN user mail-deepfire) =?ISO-8859-1?Q?=9Cby?= mail.elvees.com with ESMTP id i6KF0vvp006317; Tue, 20 Jul 2004 19:01:00 +0400 (MSD) (envelope-from deepfire@elvees.com) From: Samium Gromoff To: maksik@gmx.co.uk Subject: Re: is there *any* way to boot IP32 from hard drive ? Date: Tue, 20 Jul 2004 18:01:54 +0400 User-Agent: KMail/1.6.2 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200407201801.55096.deepfire@elvees.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: 5522 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: deepfire@elvees.com Precedence: bulk X-list: linux-mips > Hi List, > > I've asked the very same question here before, but got no answer. Probably, > the experts, who might have known the answer just overlooked it... (sorry > guys for addressing some of you directly, but I'm really in trouble). The > thing is that I desperately need to get the O2 to boot from its HDD, it'sall > installed and supposed to be used as a standalone box. First -- you`re right to use the arcboot image from debian -- that`s how i got it working. Second -- not all kernels will run successfully, indeed -- the one i used was the glaurung 2.6.1 kernel from: http://www.linux-mips.org/~glaurung/ This is the only kernel which worked for me so far, and it is not without it`s share of flaws, namely -- RTC, framebuffer, the AD-based sound chip and mouse all having issues. Also it hangs (at times) =) Hope this helps. regards, Samium Gromoff From a.voropay@vmb-service.ru Tue Jul 20 16:58:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 16:58:48 +0100 (BST) Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:49131 "EHLO smtp.vmb-service.ru") by linux-mips.org with ESMTP id ; Tue, 20 Jul 2004 16:58:44 +0100 Received: from office.vmb-service.ru ([80.73.192.47]:30725 "EHLO ALEC") by Altair with ESMTP id ; Tue, 20 Jul 2004 19:58:35 +0400 Reply-To: From: "Alexander Voropay" To: "'Ralf Baechle'" Cc: Subject: RE: Howto run Linux on ACER PICA 61 Date: Tue, 20 Jul 2004 19:59:52 +0400 Organization: VMB-Service Message-ID: <0ab701c46e72$97b49d60$0200000a@ALEC> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <0aa601c46e63$f3ddbef0$0200000a@ALEC> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: 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: 5523 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: a.voropay@vmb-service.ru Precedence: bulk X-list: linux-mips Hi! > Unfortunately, the build script does not provide a selection for the SCSI driver for >the ACER PICA It seems, this is a typo in Kconfigs... The JAZZ machine name is a "MACH_JAZZ", not a "MIPS_JAZZ" [root@monitor linux]# find . -name "Kconfig" | xargs grep MIPS_JAZZ ./drivers/net/Kconfig:config MIPS_JAZZ_SONIC ./drivers/net/Kconfig: depends on NET_ETHERNET && MIPS_JAZZ ./drivers/scsi/Kconfig: depends on MIPS_JAZZ && SCSI ./linux/drivers/net/Kconfig:config MIPS_JAZZ_SONIC ./linux/drivers/net/Kconfig: depends on NET_ETHERNET && MIPS_JAZZ ./linux/drivers/scsi/Kconfig: depends on MIPS_JAZZ && SCSI -- -=AV=- From wgowcher@yahoo.com Tue Jul 20 17:23:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jul 2004 17:24:00 +0100 (BST) Received: from web11902.mail.yahoo.com ([IPv6:::ffff:216.136.172.186]:8792 "HELO web11902.mail.yahoo.com") by linux-mips.org with SMTP id ; Tue, 20 Jul 2004 17:23:55 +0100 Message-ID: <20040720162349.45167.qmail@web11902.mail.yahoo.com> Received: from [65.204.143.11] by web11902.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 09:23:49 PDT Date: Tue, 20 Jul 2004 09:23:49 -0700 (PDT) From: Wayne Gowcher Subject: Should pci driver probe behind a cardbus bridge at boot up ? 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: 5524 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: wgowcher@yahoo.com Precedence: bulk X-list: linux-mips I am having a problem with a Ti cardbus chip and yenta on the 2.6.4 mips kernel whereby when yenta tries to configure the cardbus chip, it finds all the resources busy ( because they have already been allocated in the pci driver ) and so starts allocating new ones. Here's the output of the PCI driver PCI: Bus 1, cardbus bridge: 0000:00:0c.0 IO window: 00001000-00001fff IO window: 00002000-00002fff PREFETCH window: 40000000-41ffffff MEM window: 42000000-43ffffff PCI: Bus 5, cardbus bridge: 0000:00:0c.1 IO window: 00003000-00003fff IO window: 00004000-00004fff PREFETCH window: 44000000-45ffffff MEM window: 46000000-47ffffff and here's what yenta reports: Yenta: CardBus bridge found at 0000:00:0c.0 [0000:0000] yenta 0000:00:0c.0: Preassigned resource 1 busy, reconfiguring... Yenta: CardBus bridge found at 0000:00:0c.1 [0000:0000] When I run the same 2.6.4 kernel compiled for x86 on a x86 laptop, the x86 kernel finds the bar 0 registers of the cardbus chip and adds them to it's resource space, but probes no further. So that later when yenta probes the cardbus chip, it can allocate the resources without conflict. I also found the following comment in drivers/pci/probe.c pci_scan_bridge : * If it's a bridge, configure it and scan the bus behind it. * For CardBus bridges, we don't scan behind as the devices will * be handled by the bridge driver itself. But the code does scan behind teh cardbus bridge and add resources to iomem_resources and ioport_resources. So as I wrote in my title, does anyone know if : the pci driver should probe behind a cardbus bridge at boot up or if it should be left to the yenta cardbus ? __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ From wsonguci@yahoo.com Wed Jul 21 01:04:03 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 01:04:08 +0100 (BST) Received: from web40003.mail.yahoo.com ([IPv6:::ffff:66.218.78.21]:1672 "HELO web40003.mail.yahoo.com") by linux-mips.org with SMTP id ; Wed, 21 Jul 2004 01:04:03 +0100 Message-ID: <20040721000356.39366.qmail@web40003.mail.yahoo.com> Received: from [63.87.1.243] by web40003.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 17:03:56 PDT Date: Tue, 20 Jul 2004 17:03:56 -0700 (PDT) From: Song Wang Subject: Should #ifdef __KERNEL__ be added before #include in asm-mips/addrspace.h ? To: Ralf Baechle Cc: 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: 5525 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: wsonguci@yahoo.com Precedence: bulk X-list: linux-mips Hi, Ralf Should #ifdef _KERNEL__ be added before #include in asm-mips/addrspace.h? I think the reason is the same as when you added the #ifdef __KERNEL__ before #include for asm-mips/page.h. -Song __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ From taoyong2002cncq@yahoo.com.cn Wed Jul 21 04:04:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 04:10:14 +0100 (BST) Received: from smtp104.mail.sc5.yahoo.com ([IPv6:::ffff:66.163.169.223]:63831 "HELO smtp104.mail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Wed, 21 Jul 2004 04:04:36 +0100 Received: from unknown (HELO ime?ty) (taoyong2002cncq@202.202.6.143 with login) by smtp104.mail.sc5.yahoo.com with SMTP; 21 Jul 2004 03:04:34 -0000 Date: Wed, 21 Jul 2004 11:04:52 +0800 From: "taoyong" Reply-To: taoyong2002cncq@yahoo.com.cn To: "linux-mips@linux-mips.org" Subject: about the uMon Organization: cqu-swcims X-mailer: Foxmail 5.0 beta2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20040721030436Z8224950-1530+7111@linux-mips.org> 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: 5526 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: taoyong2002cncq@yahoo.com.cn Precedence: bulk X-list: linux-mips Hi linux-mips@linux-mips.org, We use the CSB350 (CPU is A1100) and use the uMon ,too. There are some questions after our zImage is tftped to the RAM. the reason may be the file format of the zImage. Would you please tell us your zImage is an ELF file or other file format? [root@server tftpboot]# file zImage zImage: ELF 32-bit LSB MIPS-I executable, MIPS, version 1 (SYSV), statically linked, not stripped uMON>tfs ls Name Size Location Flags Info boot 52 0xbf953f4c e hello 8938 0xbf95632c e monrc 322 0xbf953d1c e envsetup netcfg 322 0xbf9539dc e envsetup zImage 347336 0xbf8fecac e zImage2 685692 0xbf9ffd5c e Total: 6 items listed (1042662 bytes). uMON>tfs run zImage Command not found: .ELF.. Terminating script 'zImage' at line 1 uMON> uMON> uMON>tfs cp zImage 0xa0300000 uMON>dm 0xa0300000 a0300000: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 .ELF............ a0300010: 02 00 08 00 01 00 00 00 00 00 00 81 34 00 00 00 ............4... a0300020: 90 38 05 00 01 01 00 00 34 00 20 00 03 00 28 00 .8......4. ...(. a0300030: 0b 00 08 00 00 00 00 70 00 60 00 00 00 60 00 81 .......p.`...`.. a0300040: 00 60 00 81 18 00 00 00 18 00 00 00 04 00 00 00 .`.............. a0300050: 04 00 00 00 01 00 00 00 00 10 00 00 00 00 00 81 ................ a0300060: 00 00 00 81 70 4b 00 00 70 4b 00 00 05 00 00 00 ....pK..pK...... a0300070: 00 10 00 00 01 00 00 00 00 60 00 00 00 60 00 81 .........`...`.. Best regards, > Yong Tao > Insitute of Manufacture Engineering of Chongqing University, > Chongqing, > China > 400030 > tel:(+8623)65111224-108 > (+86)13752931429 From ppopov@mvista.com Wed Jul 21 04:20:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 04:20:59 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:20987 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 04:20:55 +0100 Received: from [10.2.2.64] (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id UAA29718; Tue, 20 Jul 2004 20:20:47 -0700 Subject: Re: about the uMon From: Pete Popov To: taoyong2002cncq@yahoo.com.cn Cc: "linux-mips@linux-mips.org" In-Reply-To: <20040721030436Z8224950-1530+7111@linux-mips.org> References: <20040721030436Z8224950-1530+7111@linux-mips.org> Content-Type: text/plain Organization: Message-Id: <1090380024.4622.4.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 20 Jul 2004 20:20:24 -0700 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: 5527 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 On Tue, 2004-07-20 at 20:04, taoyong wrote: > Hi linux-mips@linux-mips.org, > > We use the CSB350 (CPU is A1100) and use the uMon ,too. There are some questions after our zImage is tftped to the RAM. the reason may be the file format of the zImage. > Would you please tell us your zImage is an ELF file or other file format? The zboot patch in my directory creates two images: an image ready to be programmed in flash, and an image that can be downloaded to RAM instead. The first is an srec image that yamon understands (it understands the flash addresses and programs the file in flash). The latter is a binary image. Pete > > [root@server tftpboot]# file zImage > zImage: ELF 32-bit LSB MIPS-I executable, MIPS, version 1 (SYSV), statically linked, not stripped > > > uMON>tfs ls > Name Size Location Flags Info > boot 52 0xbf953f4c e > hello 8938 0xbf95632c e > monrc 322 0xbf953d1c e envsetup > netcfg 322 0xbf9539dc e envsetup > zImage 347336 0xbf8fecac e > zImage2 685692 0xbf9ffd5c e > > Total: 6 items listed (1042662 bytes). > uMON>tfs run zImage > Command not found: .ELF.. > Terminating script 'zImage' at line 1 > uMON> > uMON> > uMON>tfs cp zImage 0xa0300000 > uMON>dm 0xa0300000 > a0300000: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 .ELF............ > a0300010: 02 00 08 00 01 00 00 00 00 00 00 81 34 00 00 00 ............4... > a0300020: 90 38 05 00 01 01 00 00 34 00 20 00 03 00 28 00 .8......4. ...(. > a0300030: 0b 00 08 00 00 00 00 70 00 60 00 00 00 60 00 81 .......p.`...`.. > a0300040: 00 60 00 81 18 00 00 00 18 00 00 00 04 00 00 00 .`.............. > a0300050: 04 00 00 00 01 00 00 00 00 10 00 00 00 00 00 81 ................ > a0300060: 00 00 00 81 70 4b 00 00 70 4b 00 00 05 00 00 00 ....pK..pK...... > a0300070: 00 10 00 00 01 00 00 00 00 60 00 00 00 60 00 81 .........`...`.. > > > > > > > Best regards, > > > Yong Tao > > Insitute of Manufacture Engineering of Chongqing University, > > Chongqing, > > China > > 400030 > > tel:(+8623)65111224-108 > > (+86)13752931429 > > > > > From mrv@tusur.ru Wed Jul 21 05:38:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 05:38:39 +0100 (BST) Received: from mx1.tusur.ru ([IPv6:::ffff:212.192.163.19]:23054 "EHLO tusur.ru") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 05:38:33 +0100 Received: from localhost (localhost.tusur.ru [127.0.0.1]) by tusur.ru (Postfix) with SMTP id 1DA93B68FC for ; Wed, 21 Jul 2004 11:34:40 +0700 (TSD) X-AV-Checked: Wed Jul 21 11:34:40 2004 Ok Received: from roman (unknown [211.189.32.204]) by tusur.ru (Postfix) with ESMTP id 90E2EB68D7 for ; Wed, 21 Jul 2004 11:34:32 +0700 (TSD) Message-ID: <002601c46edc$809fe700$cc20bdd3@roman> From: "Roman Mashak" To: Subject: YAMON compiling Date: Wed, 21 Jul 2004 13:37:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 FL-Build: Fidolook 2002 (SL) 6.0.2800.85 - 28/1/2003 19:07:30 X-Spam-DCC: : 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: 5528 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: mrv@tusur.ru Precedence: bulk X-list: linux-mips Hello! After installing SDE toolkit onto Linux box I tried to compile the YAMON bootloader source code (version of YAMON is 2.00). Few errors arised: ../arch/include/mips.h: Assembler messages: ../arch/include/mips.h:397: Warning: rest of line ignored; first ignored character is `/' ../arch/include/mips.h:398: Warning: rest of line ignored; first ignored character is `/' ../arch/include/mips.h:399: Warning: rest of line ignored; first ignored character is `/' ../arch/include/pb1000.h:1: Warning: rest of line ignored; first ignored character is `/' ../arch/include/pb1000.h:3: Warning: rest of line ignored; first ignored character is `/' ../arch/include/pb1000.h:406: Warning: rest of line ignored; first ignored character is `/' ./../init/reset/reset.S:98: Warning: rest of line ignored; first ignored character is `/' ./../init/reset/reset.S:99: Warning: rest of line ignored; first ignored character is `/' ../arch/init/reset_db1550.S:641: Warning: rest of line ignored; first ignored character is `/' ../arch/init/reset_db1550.S:739: Error: absolute expression required `li' ../arch/init/reset_db1550.S:783: Error: absolute expression required `li' ../arch/init/reset_db1550.S:821: Error: absolute expression required `li' make: *** [reset.o] Error1 The lines in mips.h that arise these warnings are the following: // #define AU1000 0x00030100 //#define AU1000 0x01030200 //#define AU1000_2_1 0x00030200 It seems it doesn't understand the comment syntax. I have installed the version 5.03.06-LITE of SDE. Following is the code extract around which error occures: #define t1 $9 #define mem_sdconfiga 0x0840 #define MEM_SDCONFIGA_DDR 0x9030060A #define MEM_SDREFCFG_D_DDR MEM_SDCONFIGA_DDR li t1, MEM_SDREFCFG_D_DDR sw t1, mem_sdconfiga(t0) sync Compiler thinks 'li t1, MEM_SDREFCFG_D_DDR' is 'bad expression', may be it guesses MEM_SDREFCFG_D_DDR is not defined correctly? Thank you for every help in advance! With best regards, Roman Mashak. E-mail: mrv@tusur.ru From mrv@tusur.ru Wed Jul 21 06:17:50 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 06:17:55 +0100 (BST) Received: from mx1.tusur.ru ([IPv6:::ffff:212.192.163.19]:49682 "EHLO tusur.ru") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 06:17:50 +0100 Received: from localhost (localhost.tusur.ru [127.0.0.1]) by tusur.ru (Postfix) with SMTP id 3CE8EB6789 for ; Wed, 21 Jul 2004 12:14:08 +0700 (TSD) X-AV-Checked: Wed Jul 21 12:14:08 2004 Ok Received: from roman (unknown [211.189.32.204]) by tusur.ru (Postfix) with ESMTP id 07A83B5212 for ; Wed, 21 Jul 2004 12:13:53 +0700 (TSD) Message-ID: <002701c46ee1$feeb7fc0$cc20bdd3@roman> From: "Roman Mashak" To: Subject: simple assembler program Date: Wed, 21 Jul 2004 14:17:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 FL-Build: Fidolook 2002 (SL) 6.0.2800.85 - 28/1/2003 19:07:30 X-Spam-DCC: : 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: 5529 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: mrv@tusur.ru Precedence: bulk X-list: linux-mips Hello! I tried to compile simple assembler program: #define a 1 #define b 2 .ent main .global main main: li $3, a li $2, b addu $4, $2, $3 .end main I use SDE-lite kit version 5.03.06 and compile with sde-as: #sde-as test.S -o testtest.S: Assembler messages: test.S:9: Error: absolute expression required `li' test.S:10: Error: absolute expression required `li' When I eliminate #define and use just 'li $3, 1' and so on - everything is compiled correctly. Where is my problem? Thanks in advance! With best regards, Roman Mashak. E-mail: mrv@tusur.ru From jbglaw@dvmwest.gt.owl.de Wed Jul 21 07:56:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 07:56:52 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:14795 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 07:56:47 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id F3C834B7EF; Wed, 21 Jul 2004 08:56:44 +0200 (CEST) Date: Wed, 21 Jul 2004 08:56:44 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: simple assembler program Message-ID: <20040721065644.GI4690@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <002701c46ee1$feeb7fc0$cc20bdd3@roman> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lqaZmxkhekPBfBzr" Content-Disposition: inline In-Reply-To: <002701c46ee1$feeb7fc0$cc20bdd3@roman> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6i 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: 5530 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --lqaZmxkhekPBfBzr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2004-07-21 14:17:14 +0900, Roman Mashak wrote in message <002701c46ee1$feeb7fc0$cc20bdd3@roman>: > #define a 1 > #define b 2 >=20 > .ent main > .global main > main: > li $3, a > li $2, b > addu $4, $2, $3 > .end main >=20 > I use SDE-lite kit version 5.03.06 and compile with sde-as: > #sde-as test.S -o testtest.S: Assembler messages: > test.S:9: Error: absolute expression required `li' > test.S:10: Error: absolute expression required `li' >=20 > When I eliminate #define and use just 'li $3, 1' and so on - everything is > compiled correctly. Where is my problem? Assembler sources aren't commonly fed through a preprocessor, so your assembler just ignores the comments (your defines) and uses "a" and "b" as-is. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --lqaZmxkhekPBfBzr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/hOsHb1edYOZ4bsRAv1EAJ9bilGac8VUbjPwwhCayhxHzA+y0wCfZzp0 qDtQgdyvCskRs1K6SiniQEU= =Babe -----END PGP SIGNATURE----- --lqaZmxkhekPBfBzr-- From chris@mips.com Wed Jul 21 11:53:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 11:53:10 +0100 (BST) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:12297 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 11:53:06 +0100 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1BnEuT-0002Cz-00; Wed, 21 Jul 2004 12:05:17 +0100 Received: from holborn.mips.com ([192.168.192.237] helo=mips.com) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1BnEi6-00054Q-00; Wed, 21 Jul 2004 11:52:30 +0100 Message-ID: <40FE4AEE.7090109@mips.com> Date: Wed, 21 Jul 2004 11:52:30 +0100 From: Chris Dearman Organization: MIPS Technologies (UK) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Roman Mashak CC: linux-mips@linux-mips.org Subject: Re: YAMON compiling References: <002601c46edc$809fe700$cc20bdd3@roman> In-Reply-To: <002601c46edc$809fe700$cc20bdd3@roman> Content-Type: multipart/mixed; boundary="------------090900020700050409020205" X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam, SpamAssassin (score=-3.914, required 4, AWL, BAYES_00, USER_AGENT_MOZILLA_UA) 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: 5531 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: chris@mips.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------090900020700050409020205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Roman Mashak wrote: > Hello! > > After installing SDE toolkit onto Linux box I tried to compile the > YAMON bootloader source code (version of YAMON is 2.00). Few errors > arised: ... > The lines in mips.h that arise these warnings are the following: > > // #define AU1000 0x00030100 > //#define AU1000 0x01030200 > //#define AU1000_2_1 0x00030200 > The original MIPS assembler used '#' as a comment character. Using an ANSI style C preprocessor where preprocessor directives do not need to be at the beginning of the line can can cause problems with files using this type of comment. For this reason sde-gcc tells the preprocessor to run in "traditional" mode which disables various ANSI features. In particular, the preprocessor in traditional mode does not accept '//' style comments. > #define t1 $9 > #define mem_sdconfiga 0x0840 > #define MEM_SDCONFIGA_DDR 0x9030060A > #define MEM_SDREFCFG_D_DDR MEM_SDCONFIGA_DDR > > li t1, MEM_SDREFCFG_D_DDR > sw t1, mem_sdconfiga(t0) > sync > > Compiler thinks 'li t1, MEM_SDREFCFG_D_DDR' is 'bad expression', may be > it guesses MEM_SDREFCFG_D_DDR is not defined correctly? If the '#define' was not at the beginning of the line the preprocessor in traditional mode will ignore them and the assembler would end up treating these lines as comments which would cause this error. I've attached a patch that works on a MIPS release of the YAMON-2.00 sources to override the preprocessor mode for assembler files. See if it helps... Chris -- Chris Dearman The Fruit Farm, Ely Road voice +44 1223 706206 MIPS Technologies (UK) Chittering, Cambs, CB5 9PH fax +44 1223 706250 --------------090900020700050409020205 Content-Type: text/plain; name="yamon-makefile.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="yamon-makefile.patch" --- bin/makefile.orig Tue Jul 20 19:49:19 2004 +++ bin/makefile Tue Jul 20 19:49:49 2004 @@ -288,7 +288,7 @@ # SDE toolchain does not allow a construct like ".bss", it requires # .section bss instead. ifeq ($(TOOLCHAIN),sde) -CC_OPTS_A = $(CC_OPTS) -D_ASSEMBLER_ -D_SDE_ +CC_OPTS_A = $(CC_OPTS) -D_ASSEMBLER_ -D_SDE_ -fno-traditional-cpp else CC_OPTS_A = $(CC_OPTS) -D_ASSEMBLER_ endif --------------090900020700050409020205-- From srinivasjt@esntechnologies.co.in Wed Jul 21 13:54:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 13:54:59 +0100 (BST) Received: from [IPv6:::ffff:202.125.86.130] ([IPv6:::ffff:202.125.86.130]:35739 "EHLO ns2.astrainfonets.net") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Wed, 21 Jul 2004 13:54:55 +0100 Received: from mail.esn.co.in ([202.125.80.34]) by ns2.astrainfonets.net (8.12.8p1/8.12.8) with ESMTP id i6LCpGIW024659 for ; Wed, 21 Jul 2004 12:51:18 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: Error :Nomatch found in TLB ????? X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 21 Jul 2004 18:25:05 +0530 Message-ID: <4EE0CBA31942E547B99B3D4BFAB34811067510@mail.esn.co.in> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error :Nomatch found in TLB ????? Thread-Index: AcRvITae5sZQ4bx+RqS0jC7V+qvUtA== X-Priority: 1 Priority: Urgent Importance: high From: "Srinivas JT." 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: 5532 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: srinivasjt@esntechnologies.co.in Precedence: bulk X-list: linux-mips Dear All, I am very new to this group. I tried to load my .serc file into my Db1500 SDB. The steps that I followed are, 1) I wrote a filein C(Linux). 2) I generated an object file using gcc. 3) By using objcopy I converted my obj file into srec file. 4) Then I tried to download my srec file into Db1500 SDB in Yamon using tftp. then I got error as, Error: No match in TLB for mapped address : Address = 0x00000000 Why I am getting this error ?. Is any error there in my procedure..? Thanks in Advance. Regards, Srinivas JT From macro@linux-mips.org Wed Jul 21 14:44:11 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 14:44:16 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:46825 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 14:44:11 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id C30F947777; Wed, 21 Jul 2004 15:44:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id B4B1B47485; Wed, 21 Jul 2004 15:44:03 +0200 (CEST) Date: Wed, 21 Jul 2004 15:44:03 +0200 (CEST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw Cc: linux-mips@linux-mips.org Subject: Re: simple assembler program In-Reply-To: <20040721065644.GI4690@lug-owl.de> Message-ID: References: <002701c46ee1$feeb7fc0$cc20bdd3@roman> <20040721065644.GI4690@lug-owl.de> 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: 5533 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@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 21 Jul 2004, Jan-Benedict Glaw wrote: > > #sde-as test.S -o testtest.S: Assembler messages: > > test.S:9: Error: absolute expression required `li' > > test.S:10: Error: absolute expression required `li' > > > > When I eliminate #define and use just 'li $3, 1' and so on - everything is > > compiled correctly. Where is my problem? > > Assembler sources aren't commonly fed through a preprocessor, so your > assembler just ignores the comments (your defines) and uses "a" and "b" > as-is. However, they would be, based on the file name suffix, which is .S for assembly to be preprocessed or .s for one not to, if fed to the assembler via the gcc driver. Maciej From geert@linux-m68k.org Wed Jul 21 15:44:12 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 15:44:16 +0100 (BST) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:9960 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 15:44:12 +0100 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i6LEi6XK012280; Wed, 21 Jul 2004 16:44:06 +0200 (MEST) Date: Wed, 21 Jul 2004 16:44:06 +0200 (MEST) From: Geert Uytterhoeven To: "Srinivas JT." cc: Linux/MIPS Development Subject: Re: Error :Nomatch found in TLB ????? In-Reply-To: <4EE0CBA31942E547B99B3D4BFAB34811067510@mail.esn.co.in> Message-ID: References: <4EE0CBA31942E547B99B3D4BFAB34811067510@mail.esn.co.in> 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: 5534 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: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Wed, 21 Jul 2004, Srinivas JT. wrote: > I tried to load my .serc file into my Db1500 SDB. The steps that I followed are, > > 1) I wrote a filein C(Linux). > 2) I generated an object file using gcc. Using the plain `gcc' command, I guess? > 3) By using objcopy I converted my obj file into srec file. > 4) Then I tried to download my srec file into Db1500 SDB in Yamon using tftp. > > then I got error as, > > Error: No match in TLB for mapped address : Address = 0x00000000 > > Why I am getting this error ?. Is any error there in my procedure..? By default gcc creates ELF files for a virtual memory OS. Hence the load address (0x00000000) is virtual as well. You have to explicitly tell the linker to create an image to be loaded at a specific address, cfr. arch/mips/kernel/vmlinux.lds.S. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ppopov@mvista.com Wed Jul 21 17:53:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 17:53:34 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:49143 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 17:53:30 +0100 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA15712; Wed, 21 Jul 2004 09:53:25 -0700 Message-ID: <40FE9F7F.6040101@mvista.com> Date: Wed, 21 Jul 2004 09:53:19 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Srinivas JT." CC: linux-mips@linux-mips.org Subject: Re: Error :Nomatch found in TLB ????? References: <4EE0CBA31942E547B99B3D4BFAB34811067510@mail.esn.co.in> In-Reply-To: <4EE0CBA31942E547B99B3D4BFAB34811067510@mail.esn.co.in> 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: 5535 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 Srinivas JT. wrote: >Dear All, >I am very new to this group. >I tried to load my .serc file into my Db1500 SDB. The steps that I followed are, > >1) I wrote a filein C(Linux). >2) I generated an object file using gcc. >3) By using objcopy I converted my obj file into srec file. >4) Then I tried to download my srec file into Db1500 SDB in Yamon using tftp. > >then I got error as, > >Error: No match in TLB for mapped address : Address = 0x00000000 > >Why I am getting this error ?. Is any error there in my procedure..? > > Link your image to kseg0, not a virtual addresses like 0. The kernel, for example, is linked at kseg0 so the srec addresses are at 0x80100000. Since not tlbs are required for kseg0, yamon does not have problems loading into that region. Pete From jsun@mvista.com Wed Jul 21 19:57:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jul 2004 19:57:50 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8442 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 21 Jul 2004 19:57:46 +0100 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i6LIvi4O015574; Wed, 21 Jul 2004 11:57:44 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i6LIvhJb015573; Wed, 21 Jul 2004 11:57:43 -0700 Date: Wed, 21 Jul 2004 11:57:43 -0700 From: Jun Sun To: Wayne Gowcher Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: Should pci driver probe behind a cardbus bridge at boot up ? Message-ID: <20040721115743.C6813@mvista.com> References: <20040720162349.45167.qmail@web11902.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040720162349.45167.qmail@web11902.mail.yahoo.com>; from wgowcher@yahoo.com on Tue, Jul 20, 2004 at 09:23:49AM -0700 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: 5536 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 On Tue, Jul 20, 2004 at 09:23:49AM -0700, Wayne Gowcher wrote: > I am having a problem with a Ti cardbus chip and yenta > on the 2.6.4 mips kernel whereby when yenta tries to > configure the cardbus chip, it finds all the resources > busy ( because they have already been allocated in the > pci driver ) and so starts allocating new ones. > > Here's the output of the PCI driver > > PCI: Bus 1, cardbus bridge: 0000:00:0c.0 > IO window: 00001000-00001fff > IO window: 00002000-00002fff > PREFETCH window: 40000000-41ffffff > MEM window: 42000000-43ffffff > PCI: Bus 5, cardbus bridge: 0000:00:0c.1 > IO window: 00003000-00003fff > IO window: 00004000-00004fff > PREFETCH window: 44000000-45ffffff > MEM window: 46000000-47ffffff > > and here's what yenta reports: > > Yenta: CardBus bridge found at 0000:00:0c.0 > [0000:0000] > yenta 0000:00:0c.0: Preassigned resource 1 busy, > reconfiguring... > Yenta: CardBus bridge found at 0000:00:0c.1 > [0000:0000] > > > When I run the same 2.6.4 kernel compiled for x86 on a > x86 laptop, the x86 kernel finds the bar 0 registers > of the cardbus chip and adds them to it's resource > space, but probes no further. So that later when yenta > probes the cardbus chip, it can allocate the resources > without conflict. > > I also found the following comment in > drivers/pci/probe.c pci_scan_bridge : > > * If it's a bridge, configure it and scan the bus > behind it. > * For CardBus bridges, we don't scan behind as the > devices will > * be handled by the bridge driver itself. > > But the code does scan behind teh cardbus bridge and > add resources to iomem_resources and ioport_resources. > > So as I wrote in my title, does anyone know if : > > the pci driver should probe behind a cardbus bridge at > boot up or if it should be left to the yenta cardbus ? > It should not - me think anyway. Maybe you can tell us _why_, given the same code, i386 does not scan behind yenta. Jun From taoyong2002cncq@yahoo.com.cn Thu Jul 22 02:50:26 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jul 2004 05:50:06 +0100 (BST) Received: from smtp105.mail.sc5.yahoo.com ([IPv6:::ffff:66.163.169.225]:14240 "HELO smtp105.mail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Thu, 22 Jul 2004 02:50:26 +0100 Received: from unknown (HELO ime?ty) (taoyong2002cncq@202.202.6.143 with login) by smtp105.mail.sc5.yahoo.com with SMTP; 22 Jul 2004 01:50:23 -0000 Date: Thu, 22 Jul 2004 09:50:47 +0800 From: "taoyong" Reply-To: taoyong2002cncq@yahoo.com.cn To: "linux-mips" Subject: boot "hell world " and linux on CSB350 Organization: cqu-swcims X-mailer: Foxmail 5.0 beta2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20040722015026Z8224929-1530+7145@linux-mips.org> 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: 5537 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: taoyong2002cncq@yahoo.com.cn Precedence: bulk X-list: linux-mips Hi linux-mips, We have AMD PB1000 and openpda platform and the hardhat linux keranl. csb350 is a new board,and we want to port the hardhat kernal to the csb350. But after we download the "hello world" ,which is comopiled with the mips-elf-gcc,to the ram 0xa0300000,then "call 0xa0300000",we got "Returned: -2147239488 (0x8003b9c0)" . we tftped the kernal image to the RAM 0xa0300000,then call it ,got the same result "Returned: -2147239488 (0x8003b9c0)" or it stopped there. uMON>tftp 192.168.100.251 get /tftpboot/hello.bin 0xa0300000 Retrieving /tftpboot/hello.bin from 192.168.100.251...TFTP transfer complete. 1504 bytes uMON>call 0xa0300000 Returned: -2147239488 (0x8003b9c0) uMON>dm 0xa0300000 a0300000: 14 a0 1d 3c 00 ff bd 27 11 a0 1c 3c d0 85 9c 27 ...<...'...<...' a0300010: 04 00 bf af 54 01 04 0c 00 00 00 00 00 00 00 00 ....T........... a0300020: 04 00 bf 8f 08 00 e0 03 00 00 00 00 00 00 00 00 ................ a0300030: 08 00 e0 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0300040: 21 40 00 00 05 00 a0 14 21 48 80 00 30 00 02 24 !@......!H..0..$ a0300050: 00 00 22 a1 08 00 e0 03 01 00 02 24 1b 00 a6 00 .."........$.... a0300060: 12 28 00 00 21 20 28 01 10 10 00 00 01 00 c0 50 .(..! (........P a0300070: 0d 00 07 00 21 10 e2 00 00 00 43 90 01 00 08 25 ....!.....C....% uMON>tftp 192.168.100.251 get /tftpboot/vmlinux.bin 0xa0600000 Retrieving /tftpboot/vmlinux.bin from 192.168.100.251...TFTP transfer complete. 1548288 bytes uMON>call 0xa0600000 Returned: -2147239488 (0x8003b9c0) uMON>tftp 192.168.100.251 get /tftpboot/vmlinux.bin 0xa0300000 Retrieving /tftpboot/vmlinux.bin from 192.168.100.251...TFTP transfer complete. 1548288 bytes uMON>dm 0xa0300000 a0300000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0300010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0300020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0300030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0300040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0300050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0300060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0300070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ uMON>call 0xa0300000 it stopped here and we have to reset the csb350. what's the reason? Best regards, > Yong Tao > Insitute of Manufacture Engineering of Chongqing University, > Chongqing, > China > 400030 > tel:(+8623)65111224-108 > (+86)13752931429 From Ralf.Ackermann@KOM.tu-darmstadt.de Thu Jul 22 16:55:59 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jul 2004 16:56:04 +0100 (BST) Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:31720 "EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org with ESMTP id ; Thu, 22 Jul 2004 16:55:59 +0100 Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id RAA02189; Thu, 22 Jul 2004 17:55:54 +0200 (MEST) Date: Thu, 22 Jul 2004 17:56:19 +0200 (CEST) From: Ralf Ackermann X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de To: linux-mips@linux-mips.org cc: Ralf Ackermann Subject: Q: (cross)compiling for the Meshcube (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: 5538 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: rac@KOM.tu-darmstadt.de Precedence: bulk X-list: linux-mips Hello, I'm trying to (cross)compile some more modules/applications for the meshcube - but failed so far. I installed (on an i386 system): binutils-mipsel-linux-2.13.2.1-3.i386.rpm gcc-mipsel-linux-2.95.4-1.i386.rpm (from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/) Making a hello world program fails with: mipsel-linux-gcc hello.c -o hello /usr/mipsel-linux/bin/ld: cannot open crt1.o: No such file or directory collect2: ld returned 1 exit status My questions: - Are there any specific hints for the cross-compile environment (or: "What are you using ... and would therefore suggest ?) - Is there any chance to use a native gcc on the cube itself? (could this e.g. been done by chrooting into a (which?) existing MIPS Linux distribution that is mounted via NFS) Any hints are highly appreciated (I have worked with crosscompile/native environments for ARM so far, but these are my first experiences in the MIPS world). regards Ralf --------------------------------------------------------------- Dr. Ralf Ackermann _ rac@KOM.tu-darmstadt.de Multimedia Communications |/ | | |\/| Merckstrasse 25 |\ |_| | | 64283 Darmstadt, Germany Tel.: (+49) 6151 16-6138 Fax: (+49) 6151 16-6152 --------------------------------------------------------------- http://www.kom.tu-darmstadt.de/~rac --------------------------------------------------------------- From ratin@koperasw.com Thu Jul 22 17:15:01 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jul 2004 17:15:05 +0100 (BST) Received: from host73.ipowerweb.com ([IPv6:::ffff:12.129.211.254]:33119 "EHLO host73.ipowerweb.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Thu, 22 Jul 2004 17:15:00 +0100 Received: from c-67-170-233-233.client.comcast.net ([67.170.233.233] helo=ratwin1) by host73.ipowerweb.com with asmtp (Exim 3.36 #1) id 1BngDT-0001tJ-00; Thu, 22 Jul 2004 09:14:43 -0700 Reply-To: From: "Ratin Kumar" To: "'Ralf Ackermann'" , Subject: RE: (cross)compiling for the Meshcube (fwd) Date: Thu, 22 Jul 2004 09:14:37 -0700 Organization: Kopera Software Inc. Message-ID: <000201c47007$0010cec0$6401a8c0@ratwin1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host73.ipowerweb.com X-AntiAbuse: Original Domain - linux-mips.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - koperasw.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: 5539 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: ratin@koperasw.com Precedence: bulk X-list: linux-mips You don't mention installing libc for the platform. You will need libraries for the MIPS(el) target to be present in the cross-compile path. Try ftp://ftp.linux-mips.org/pub/linux/mips/glibc/mipsel-linux/ On doing Native build, if your platform supports tftp loading of boot kernel (or if it has a boot kernel which you can pass parameter to), load the kernel with nfsroot="IP-Address-of-server:/path" ip=ip-address-of-target This requires an NFS image to be kept somewhere reachable by your target. There is a tarball of RH7.1(mipsel) NFS dump at MIPS ftp for which worked for my MALTA. I did (sometime) ago produce NFS image of RH7.3 for my MALTA board. I can upload it if you can tell me a location where to put it. -----Original Message----- From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Ralf Ackermann Sent: Thursday, July 22, 2004 8:56 AM To: linux-mips@linux-mips.org Cc: Ralf Ackermann Subject: Q: (cross)compiling for the Meshcube (fwd) Hello, I'm trying to (cross)compile some more modules/applications for the meshcube - but failed so far. I installed (on an i386 system): binutils-mipsel-linux-2.13.2.1-3.i386.rpm gcc-mipsel-linux-2.95.4-1.i386.rpm (from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/) Making a hello world program fails with: mipsel-linux-gcc hello.c -o hello /usr/mipsel-linux/bin/ld: cannot open crt1.o: No such file or directory collect2: ld returned 1 exit status My questions: - Are there any specific hints for the cross-compile environment (or: "What are you using ... and would therefore suggest ?) - Is there any chance to use a native gcc on the cube itself? (could this e.g. been done by chrooting into a (which?) existing MIPS Linux distribution that is mounted via NFS) Any hints are highly appreciated (I have worked with crosscompile/native environments for ARM so far, but these are my first experiences in the MIPS world). regards Ralf --------------------------------------------------------------- Dr. Ralf Ackermann _ rac@KOM.tu-darmstadt.de Multimedia Communications |/ | | |\/| Merckstrasse 25 |\ |_| | | 64283 Darmstadt, Germany Tel.: (+49) 6151 16-6138 Fax: (+49) 6151 16-6152 --------------------------------------------------------------- http://www.kom.tu-darmstadt.de/~rac --------------------------------------------------------------- From ica2_ts@csv.ica.uni-stuttgart.de Thu Jul 22 17:41:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jul 2004 17:41:52 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:36660 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Thu, 22 Jul 2004 17:41:47 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1Bngdd-0006MC-00; Thu, 22 Jul 2004 18:41:45 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1Bngdc-0006fQ-00; Thu, 22 Jul 2004 18:41:44 +0200 Date: Thu, 22 Jul 2004 18:41:44 +0200 To: Ralf Ackermann Cc: linux-mips@linux-mips.org Subject: Re: Q: (cross)compiling for the Meshcube (fwd) Message-ID: <20040722164144.GG965@rembrandt.csv.ica.uni-stuttgart.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i 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: 5540 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 Ralf Ackermann wrote: [snip] > - Is there any chance to use a native gcc on the cube itself? > (could this e.g. been done by chrooting into a (which?) > existing MIPS Linux distribution that is mounted via NFS) Native compiles should work. AFAIK the Meshcube uses a customized debian, most likely a testing/unstable mix. If you have a debian system around, you can install the "debootstrap" package there and use it to create a mips chroot, configure it, export it to the Meshcube, and install the "build-essential" package there. This gives you the usual native debian development environment. Thiemo From wgowcher@yahoo.com Thu Jul 22 17:53:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jul 2004 17:53:05 +0100 (BST) Received: from web11906.mail.yahoo.com ([IPv6:::ffff:216.136.172.190]:11276 "HELO web11906.mail.yahoo.com") by linux-mips.org with SMTP id ; Thu, 22 Jul 2004 17:53:00 +0100 Message-ID: <20040722165240.35417.qmail@web11906.mail.yahoo.com> Received: from [65.204.143.11] by web11906.mail.yahoo.com via HTTP; Thu, 22 Jul 2004 09:52:40 PDT Date: Thu, 22 Jul 2004 09:52:40 -0700 (PDT) From: Wayne Gowcher Subject: Re: Should pci driver probe behind a cardbus bridge at boot up ? To: Jun Sun Cc: linux-mips@linux-mips.org, jsun@mvista.com In-Reply-To: <20040721115743.C6813@mvista.com> 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: 5541 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: wgowcher@yahoo.com Precedence: bulk X-list: linux-mips > > So as I wrote in my title, does anyone know if : > > > > the pci driver should probe behind a cardbus > bridge at > > boot up or if it should be left to the yenta > cardbus ? > > > > It should not - me think anyway. > > Maybe you can tell us _why_, given the same code, > i386 does > not scan behind yenta. > > Jun I believe for x86 targets, the PC bios has already scanned and programmed the memory / io bar registers of the PCI devices. So for an x86 target linux merely reads the bar registers - it does not try to reprogram them, and so does not go behind the cardbus bridge. For mips and any other architecture which does not have a bios to set up the pci bus like this, linux has to scan and allocate io and memory, but as it is doing so it is adding those resources to it's resource list. - Effectively reserving those io / memory regions. Then when yenta comes along, it also scans the cardbus and tries to REALLOCATE the same resources, but finds the pci probed resources, returns the "busy" and so then tries to reallocate the already allocated resources to a new memory region. Unfortunately in my case ( and I would like to know if this true for other people's platforms ), when yenta does this it seems to corrupt the proc/iomem and proc/ioport list such that if I do "cat /proc/xx" on either of these the kernel throws an oops. Can anyone else do a cat /proc/iomem or ioports with yenta configured and a cardbus chip on board ?? If yes then I have a problem with my setup, if not then I suspect the code. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From jack.villarosa@adtxsystems.com Fri Jul 23 02:52:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 02:52:50 +0100 (BST) Received: from adsl-131.111.187.info.com.ph ([IPv6:::ffff:203.131.111.187]:4360 "EHLO GVRPD03.APTIPHILS.COM") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 02:52:46 +0100 Subject: TX4938 NAND flash bootup To: linux-mips@linux-mips.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: jack.villarosa@adtxsystems.com Date: Fri, 23 Jul 2004 09:56:29 +0800 X-MIMETrack: Serialize by Router on GVRPD03/RPD/APTiPHILS(Release 5.0.4 |June 29, 2000) at 2004/07/23 09:56:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp 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: 5542 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: jack.villarosa@adtxsystems.com Precedence: bulk X-list: linux-mips Hi everyone! Has anyone tried to boot a rbhma4500 board (tx4938 uprocessor) before? I tried to read the reference board's manuals but couldn't find anything linux-related. What i have already tried was to: 1. Write NAND IPL control information (FORMAT: srec) to sram 2. Write vmlinux.srec to sram 3. Use NAND Writer to burn the data to NAND Flash. 4. Changed board settings to boot starting from NAND IPL. With these steps, neither an error nor success messages appeard. The board just hung. Im having a hard time looking for sources on the net; thus, this mail. Thank you very much! -=-=-=-=-=-=-=-$B%8%c%C%/(B=-=-=-=-=-=-=-=- || John Alexis S. Villarosa Jack || - Dev 1 Microcode - || ADTX Systems, Incorporated, HQ || -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From kommu@hotmail.com Fri Jul 23 08:49:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 08:49:25 +0100 (BST) Received: from bay1-f25.bay1.hotmail.com ([IPv6:::ffff:65.54.245.25]:45582 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 08:49:21 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Jul 2004 00:49:13 -0700 Received: from 24.6.61.8 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 23 Jul 2004 07:49:13 GMT X-Originating-IP: [24.6.61.8] X-Originating-Email: [kommu@hotmail.com] X-Sender: kommu@hotmail.com From: "Srinivas Kommu" To: linux-mips@linux-mips.org Cc: kommu@hotmail.com Subject: mips32 kernel memory mapping Date: Fri, 23 Jul 2004 00:49:13 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jul 2004 07:49:13.0935 (UTC) FILETIME=[8C448DF0:01C47089] 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: 5543 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: kommu@hotmail.com Precedence: bulk X-list: linux-mips Can a 32-bit mips kernel access beyond KSEG0 contiguously? I have a Sibyte 1250 with 1 Gig RAM, but only 256 MB is located at phyical 0x0. The rest is all located at 0x8000_0000. Does that mean the kernel can access only 256 meg contiguously? Do I need to enabled CONFIG_HIGHMEM to even reach the remaining RAM? It appears Highmem gives me only a 4 meg window at a time. Can't I set up a page mapping into KSEG2 for the rest of the memory? KSEG2 seems to be unused from what I read. Since the user space has a 2 Gig address space, it should be able to access it, right? Does the kernel allocate from the whole 1 Gig when the process issues a malloc()? thanks! Srini _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From bruno.randolf@4g-systems.biz Fri Jul 23 11:43:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 11:43:21 +0100 (BST) Received: from grey.subnet.at ([IPv6:::ffff:193.170.141.20]:48397 "EHLO grey.subnet.at") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Fri, 23 Jul 2004 11:43:16 +0100 Received: from localhost ([193.170.141.4]) by grey.subnet.at ; Fri, 23 Jul 2004 12:43:11 +0200 From: Bruno Randolf To: linux-mips@linux-mips.org, dev-list@meshcube.org Subject: Re: Q: (cross)compiling for the Meshcube (fwd) Date: Fri, 23 Jul 2004 12:41:16 +0200 User-Agent: KMail/1.6.2 Cc: Ralf Ackermann References: In-Reply-To: Organization: 4G Systems MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <200407231241.16183.bruno.randolf@4g-systems.biz> 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: 5544 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: bruno.randolf@4g-systems.biz Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi! we use crosstool from http://www.kegel.com/crosstool/ to create a cross toolchain. it is also part of our build system, we have at http://www.meshcube.org/ in the CVS. if you check it out, you can cd into the build/ directory and "make toolchain". the cross prefix is then mipsel-mtx-linux-gnu-. greetings, bruno On Thursday 22 July 2004 17:56, Ralf Ackermann wrote: > Hello, > > I'm trying to (cross)compile some more modules/applications for the > meshcube - but failed so far. > > I installed (on an i386 system): > binutils-mipsel-linux-2.13.2.1-3.i386.rpm > gcc-mipsel-linux-2.95.4-1.i386.rpm > (from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/) > > Making a hello world program fails with: > mipsel-linux-gcc hello.c -o hello > /usr/mipsel-linux/bin/ld: cannot open crt1.o: No such file or directory > collect2: ld returned 1 exit status > > My questions: > - Are there any specific hints for the cross-compile environment > (or: "What are you using ... and would therefore suggest ?) > - Is there any chance to use a native gcc on the cube itself? > (could this e.g. been done by chrooting into a (which?) > existing MIPS Linux distribution that is mounted via NFS) > > Any hints are highly appreciated (I have worked with crosscompile/native > environments for ARM so far, but these are my first experiences in the > MIPS world). > > regards > Ralf > > --------------------------------------------------------------- > Dr. Ralf Ackermann _ rac@KOM.tu-darmstadt.de > Multimedia Communications |/ | | |\/| Merckstrasse 25 > > |\ |_| | | 64283 Darmstadt, Germany > > Tel.: (+49) 6151 16-6138 Fax: (+49) 6151 16-6152 > --------------------------------------------------------------- > http://www.kom.tu-darmstadt.de/~rac > --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAOtMfg2jtUL97G4RAqaVAJkBIcsWlDTyGUr4Py9AsL/3+lWxIQCffaLI 2H+9w74+YH2YkZbK4KJ4zwQ= =7PWO -----END PGP SIGNATURE----- From macro@linux-mips.org Fri Jul 23 12:51:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 12:51:45 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:57360 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 12:51:39 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id E9997E1C7E; Fri, 23 Jul 2004 13:51:33 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21901-02; Fri, 23 Jul 2004 13:51:33 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id B0C59E1C66; Fri, 23 Jul 2004 13:51:33 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i6NBpfU5022235; Fri, 23 Jul 2004 13:51:42 +0200 Date: Fri, 23 Jul 2004 13:51:34 +0200 (CEST) From: "Maciej W. Rozycki" To: Srinivas Kommu Cc: linux-mips@linux-mips.org Subject: Re: mips32 kernel memory mapping In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 5545 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@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 23 Jul 2004, Srinivas Kommu wrote: > Can a 32-bit mips kernel access beyond KSEG0 contiguously? I have a Sibyte > 1250 with 1 Gig RAM, but only 256 MB is located at phyical 0x0. The rest is > all located at 0x8000_0000. Does that mean the kernel can access only 256 > meg contiguously? Do I need to enabled CONFIG_HIGHMEM to even reach the > remaining RAM? It appears Highmem gives me only a 4 meg window at a time. The BCM1250A is a 64-bit processor. What's the problem with using 64-bit Linux avoiding the hassle altogether? > Can't I set up a page mapping into KSEG2 for the rest of the memory? KSEG2 > seems to be unused from what I read. KSEG2 is used for modules. Maciej From macro@linux-mips.org Fri Jul 23 15:41:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 15:41:44 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:37901 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 15:41:38 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 28247E1C82; Fri, 23 Jul 2004 16:41:33 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06865-06; Fri, 23 Jul 2004 16:41:33 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id DD7DEE1C81; Fri, 23 Jul 2004 16:41:32 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i6NEfh55002842; Fri, 23 Jul 2004 16:41:44 +0200 Date: Fri, 23 Jul 2004 16:41:35 +0200 (CEST) From: "Maciej W. Rozycki" To: Richard Henderson Cc: Richard Sandiford , Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets In-Reply-To: <20040719213801.GD14931@redhat.com> Message-ID: References: <87hds49bmo.fsf@redhat.com> <20040719213801.GD14931@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 5546 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@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 19 Jul 2004, Richard Henderson wrote: > > Well, other targets, like the i386 (which didn't even have a 64-bit > > variation till recently)... > > Except that 80386 has 64-bit shifts in hardware. Indeed -- I tend to forget of these two, sigh... > And in rebuttal to the "does not make linux jump through hoops" > argument, see arch/*/lib/ for arm, h8300, m68k, sparc, v850. OK -- but then is there any way to convince gcc to embed a "static inline" version of these functions instead of emitting a call? Sometimes putting these eight (or nine for ashrdi3) instructions inline would be a performance win. Maciej From macro@linux-mips.org Fri Jul 23 18:29:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 18:29:24 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:53519 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 18:29:19 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 67E28E1C88 for ; Fri, 23 Jul 2004 19:29:12 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25426-07 for ; Fri, 23 Jul 2004 19:29:12 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 38A22E1C81 for ; Fri, 23 Jul 2004 19:29:12 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i6NHTQob018654 for ; Fri, 23 Jul 2004 19:29:26 +0200 Date: Fri, 23 Jul 2004 19:29:16 +0200 (CEST) From: "Maciej W. Rozycki" To: linux-mips@linux-mips.org Subject: [announce] ftp.ds2.pg.gda.pl site move Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 5547 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@linux-mips.org Precedence: bulk X-list: linux-mips Hello, To anyone interested: the "ftp://ftp.ds2.pg.gda.pl/pub/macro/" site is being retired and will be shut down soon. The contents have been copied to another system, located at: "ftp://ftp3.ds.pg.gda.pl/people/macro/". My address is going to stop working, too. Please use to contact me in the future. Maciej From ralf@linux-mips.org Fri Jul 23 21:25:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 21:25:48 +0100 (BST) Received: from p508B7E12.dip.t-dialin.net ([IPv6:::ffff:80.139.126.18]:40561 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 21:25:44 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6NKOePD004232; Fri, 23 Jul 2004 22:24:40 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6NKOdtO004231; Fri, 23 Jul 2004 22:24:39 +0200 Date: Fri, 23 Jul 2004 22:24:39 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Srinivas Kommu , linux-mips@linux-mips.org Subject: Re: mips32 kernel memory mapping Message-ID: <20040723202439.GA3711@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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: 5548 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, Jul 23, 2004 at 01:51:34PM +0200, Maciej W. Rozycki wrote: > > Can a 32-bit mips kernel access beyond KSEG0 contiguously? I have a Sibyte > > 1250 with 1 Gig RAM, but only 256 MB is located at phyical 0x0. The rest is > > all located at 0x8000_0000. Does that mean the kernel can access only 256 > > meg contiguously? Do I need to enabled CONFIG_HIGHMEM to even reach the > > remaining RAM? It appears Highmem gives me only a 4 meg window at a time. > > The BCM1250A is a 64-bit processor. What's the problem with using 64-bit > Linux avoiding the hassle altogether? There is a general perception among Linux users that 64-bit is new an not really needed which in part I blame on the bs Intel is spreading to hide the fact that for a long time they simply had no 64-bit roadmap at all. > > Can't I set up a page mapping into KSEG2 for the rest of the memory? KSEG2 > > seems to be unused from what I read. > > KSEG2 is used for modules. There are still improvments to be made for BCM1250 support. Somebody thought scattering the first 1GB of memory through the lowest 4GB of physical address space like a three year old his toys over the floor was a good thing ... The resulting holes in the memory map are wasting significant amounts of memory for unused memory; the worst case number that is reached for 64-bit kernel on a system with > 1GB of RAM is 96MB! > > Can't I set up a page mapping into KSEG2 for the rest of the memory? KSEG2 > > seems to be unused from what I read. > > KSEG2 is used for modules. Right. A part of KSEG2 could be used for mapping more low-memory but that's only really an interesting option for 32-bit processors and would only raise the theoretical limit from 512MB (256 on BCM1250) to somewhat less than 1.5GB (BCM1250: 1.25GB) at the cost of address space for vmalloc & ioremap. It's a pretty pointless exercise when there are still terabytes of unmapped 64-bit address space available. Ralf From rth@redhat.com Fri Jul 23 21:27:13 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 21:27:18 +0100 (BST) Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:18057 "EHLO mx2.redhat.com") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 21:27:13 +0100 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i6NKMwSt032639; Fri, 23 Jul 2004 16:22:58 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6NKR4H09696; Fri, 23 Jul 2004 16:27:04 -0400 Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i6NKR4L09438; Fri, 23 Jul 2004 13:27:04 -0700 Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1]) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i6NKR3Qw030989; Fri, 23 Jul 2004 13:27:03 -0700 Received: (from rth@localhost) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i6NKR37L030987; Fri, 23 Jul 2004 13:27:03 -0700 X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Fri, 23 Jul 2004 13:27:03 -0700 From: Richard Henderson To: "Maciej W. Rozycki" Cc: Richard Sandiford , Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets Message-ID: <20040723202703.GB30931@redhat.com> Mail-Followup-To: Richard Henderson , "Maciej W. Rozycki" , Richard Sandiford , Ralf Baechle , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org References: <87hds49bmo.fsf@redhat.com> <20040719213801.GD14931@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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: 5549 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: rth@redhat.com Precedence: bulk X-list: linux-mips On Fri, Jul 23, 2004 at 04:41:35PM +0200, Maciej W. Rozycki wrote: > OK -- but then is there any way to convince gcc to embed a "static > inline" version of these functions instead of emitting a call? No. > Sometimes putting these eight (or nine for ashrdi3) instructions > inline would be a performance win. Sometimes, maybe. I suspect you'll find that in general it's nothing but bloat. r~ From geert@linux-m68k.org Fri Jul 23 21:34:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 21:34:42 +0100 (BST) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:27122 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 21:34:38 +0100 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i6NKYZXK023323; Fri, 23 Jul 2004 22:34:35 +0200 (MEST) Date: Fri, 23 Jul 2004 22:34:35 +0200 (MEST) From: Geert Uytterhoeven To: Ralf Baechle cc: "Maciej W. Rozycki" , Srinivas Kommu , Linux/MIPS Development Subject: Re: mips32 kernel memory mapping In-Reply-To: <20040723202439.GA3711@linux-mips.org> Message-ID: References: <20040723202439.GA3711@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: 5550 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: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Fri, 23 Jul 2004, Ralf Baechle wrote: > There are still improvments to be made for BCM1250 support. Somebody > thought scattering the first 1GB of memory through the lowest 4GB of > physical address space like a three year old his toys over the floor > was a good thing ... The resulting holes in the memory map are wasting > significant amounts of memory for unused memory; the worst case number > that is reached for 64-bit kernel on a system with > 1GB of RAM is 96MB! Perhaps you want to start using virtually mapped zones, like m68k? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ralf@linux-mips.org Fri Jul 23 22:12:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jul 2004 22:12:43 +0100 (BST) Received: from p508B7E12.dip.t-dialin.net ([IPv6:::ffff:80.139.126.18]:23156 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 23 Jul 2004 22:12:39 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6NLCX6f005317; Fri, 23 Jul 2004 23:12:33 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6NLCWdJ005316; Fri, 23 Jul 2004 23:12:32 +0200 Date: Fri, 23 Jul 2004 23:12:32 +0200 From: Ralf Baechle To: Richard Henderson , "Maciej W. Rozycki" , Richard Sandiford , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets Message-ID: <20040723211232.GB5138@linux-mips.org> References: <87hds49bmo.fsf@redhat.com> <20040719213801.GD14931@redhat.com> <20040723202703.GB30931@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040723202703.GB30931@redhat.com> User-Agent: Mutt/1.4.1i 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: 5551 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, Jul 23, 2004 at 01:27:03PM -0700, Richard Henderson wrote: > > Sometimes putting these eight (or nine for ashrdi3) instructions > > inline would be a performance win. > > Sometimes, maybe. I suspect you'll find that in general it's > nothing but bloat. With a bit of hand waiving because haven't done benchmarks I guess Richard might be right. The subroutine calling overhead on modern processors is rather low and smaller code means better cache hit rates ... Ralf From ralf@linux-mips.org Sat Jul 24 01:32:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jul 2004 01:33:00 +0100 (BST) Received: from p508B7E12.dip.t-dialin.net ([IPv6:::ffff:80.139.126.18]:48511 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 24 Jul 2004 01:32:55 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6O0WmL0009166; Sat, 24 Jul 2004 02:32:48 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6O0WiHF009159; Sat, 24 Jul 2004 02:32:44 +0200 Date: Sat, 24 Jul 2004 02:32:44 +0200 From: Ralf Baechle To: Geert Uytterhoeven Cc: "Maciej W. Rozycki" , Srinivas Kommu , Linux/MIPS Development Subject: Re: mips32 kernel memory mapping Message-ID: <20040724003244.GA8802@linux-mips.org> References: <20040723202439.GA3711@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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: 5552 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, Jul 23, 2004 at 10:34:35PM +0200, Geert Uytterhoeven wrote: > On Fri, 23 Jul 2004, Ralf Baechle wrote: > > There are still improvments to be made for BCM1250 support. Somebody > > thought scattering the first 1GB of memory through the lowest 4GB of > > physical address space like a three year old his toys over the floor > > was a good thing ... The resulting holes in the memory map are wasting > > significant amounts of memory for unused memory; the worst case number > > that is reached for 64-bit kernel on a system with > 1GB of RAM is 96MB! > > Perhaps you want to start using virtually mapped zones, like m68k? We could do that, yes. In the cases that would gain most such as the BCM1250 it'd not be possible though - there simply is not enough virtual address space left in KSEG2/3. Ralf From sskowron@ET.PUT.Poznan.PL Sun Jul 25 19:59:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Jul 2004 19:59:37 +0100 (BST) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:24806 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Sun, 25 Jul 2004 19:59:32 +0100 Received: from athena (athena.et.put.poznan.pl [150.254.29.137]) by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i6PIxUF21097 for ; Sun, 25 Jul 2004 20:59:30 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ; Sun, 25 Jul 2004 20:59:30 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i6PIxTb27964 for ; Sun, 25 Jul 2004 20:59:30 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Sun, 25 Jul 2004 20:59:29 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: Octane news 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: 5553 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: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips Hello all. After a long delay I can finally announce something important about Octane Linux. We are a little nearer to having accelerated graphics support on IP30. I managed to set the card into 24-bit RGB pixel format. I can draw accelerated lines. I can draw arbitrary accelerated Gouraud-shaded (or not) triangles. I can draw accelerated characters and bitmaps. I can't read anything from the frame buffer. I can't effectively draw pixmaps. I can't change video mode (however, I'm working on it). I can't take advantage of the GE11 Geometry Engines, so all triangle setups and transforms are performed in software. If anyone has *any* information that might be helpful in achieving the mentioned goals (especially the GE11 support), please help me. Thanks for your attention, Stanislaw Skowronek --<=>-- "You're not as old as the trees, not as young as the leaves. Not as free as the breeze, not as open as the seas." From thomas.koeller@baslerweb.com Mon Jul 26 11:35:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jul 2004 11:35:50 +0100 (BST) Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:9988 "EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP id ; Mon, 26 Jul 2004 11:35:45 +0100 Received: from comm1.baslerweb.com (proxy.baslerweb.com [172.16.13.2]) by proxy.baslerweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Mon, 26 Jul 2004 12:35:16 +0200 Received: from [172.16.13.253] (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PLG5MTZ1; Mon, 26 Jul 2004 12:35:42 +0200 From: Thomas Koeller Organization: Basler AG To: linux-mips@linux-mips.org Subject: [PATCH] Fix gcc-3.4.x compilation Date: Mon, 26 Jul 2004 12:37:09 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200407261237.09965.thomas.koeller@baslerweb.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: 5554 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: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips Hi, compilation of the kernel with a 3.4.x compiler does not work, because that compiler does no longer recognize the 'accum' register pair specifier. This can easily be fixed (patch attached). Since the meaning of 'accum' used to be 'hi' and 'lo', all its uses were clearly redundant. --- linux-mips/arch/mips/kernel/time.c 2004-07-26 12:15:25.302897080 +0200 +++ linux-mips-work/arch/mips/kernel/time.c 2004-07-15 14:52:18.000000000 +0200 @@ -278,7 +278,7 @@ __asm__("multu %1,%2" : "=h" (res) : "r" (count), "r" (sll32_usecs_per_cycle) - : "lo", "accum"); + : "lo"); /* * Due to possible jiffies inconsistencies, we need to check @@ -333,7 +333,7 @@ __asm__("multu %1,%2" : "=h" (res) : "r" (count), "r" (quotient) - : "lo", "accum"); + : "lo"); /* * Due to possible jiffies inconsistencies, we need to check @@ -375,7 +375,7 @@ : "r" (timerhi), "m" (timerlo), "r" (tmp), "r" (USECS_PER_JIFFY), "r" (USECS_PER_JIFFY_FRAC) - : "hi", "lo", "accum"); + : "hi", "lo"); cached_quotient = quotient; } } @@ -389,7 +389,7 @@ __asm__("multu %1,%2" : "=h" (res) : "r" (count), "r" (quotient) - : "lo", "accum"); + : "lo"); /* * Due to possible jiffies inconsistencies, we need to check -- -------------------------------------------------- Thomas Koeller, Software Development Basler Vision Technologies thomas dot koeller at baslerweb dot com http://www.baslerweb.com ============================== From macro@linux-mips.org Mon Jul 26 12:23:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jul 2004 12:23:50 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:29700 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 26 Jul 2004 12:23:44 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id ECCBFE1CA6; Mon, 26 Jul 2004 13:23:38 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04727-02; Mon, 26 Jul 2004 13:23:38 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id A6A45E1CA4; Mon, 26 Jul 2004 13:23:38 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i6QBNkhQ027169; Mon, 26 Jul 2004 13:23:46 +0200 Date: Mon, 26 Jul 2004 13:23:41 +0200 (CEST) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Srinivas Kommu , linux-mips@linux-mips.org Subject: Re: mips32 kernel memory mapping In-Reply-To: <20040723202439.GA3711@linux-mips.org> Message-ID: References: <20040723202439.GA3711@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 5555 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@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 23 Jul 2004, Ralf Baechle wrote: > There is a general perception among Linux users that 64-bit is new an > not really needed which in part I blame on the bs Intel is spreading to > hide the fact that for a long time they simply had no 64-bit roadmap at > all. Huh? How's Intel's policy related to 64-bit Linux? Especially for other processors, like MIPS. Linux has supported 64-bit operation since ~1995 and around 1998 when I had an opportunity to use it on DEC Alpha, it (2.0.x) was already stable enough for regular use. That is the generic core and the Alpha bits, of course -- the maturity of other processor support may vary, but for MIPS it's not worse than the 32-bit support. > There are still improvments to be made for BCM1250 support. Somebody > thought scattering the first 1GB of memory through the lowest 4GB of > physical address space like a three year old his toys over the floor > was a good thing ... The resulting holes in the memory map are wasting > significant amounts of memory for unused memory; the worst case number > that is reached for 64-bit kernel on a system with > 1GB of RAM is 96MB! Well, there are some resons given in the manual. Anyway, memory seems to be remappable to 0x100000000 in the DRAM controller. Still we probably have to keep low 256MB mapped and registered within Linux at 0 for bounce buffers for broken PCI hardware ("hidden" mapping for exception handlers and kernel segments would be easier). With only 256MB installed in my system it would be tough for me to code anything interesting, though. Perhaps another time. Maciej From macro@linux-mips.org Mon Jul 26 12:56:50 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jul 2004 12:56:55 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:30476 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 26 Jul 2004 12:56:50 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id E60C3E1CA6; Mon, 26 Jul 2004 13:56:45 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16700-04; Mon, 26 Jul 2004 13:56:45 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 984F5E1CA4; Mon, 26 Jul 2004 13:56:45 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i6QBurjQ028588; Mon, 26 Jul 2004 13:56:53 +0200 Date: Mon, 26 Jul 2004 13:56:47 +0200 (CEST) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Richard Henderson , Richard Sandiford , gcc-patches@gcc.gnu.org, linux-mips@linux-mips.org Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets In-Reply-To: <20040723211232.GB5138@linux-mips.org> Message-ID: References: <87hds49bmo.fsf@redhat.com> <20040719213801.GD14931@redhat.com> <20040723202703.GB30931@redhat.com> <20040723211232.GB5138@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 5556 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@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 23 Jul 2004, Ralf Baechle wrote: > With a bit of hand waiving because haven't done benchmarks I guess Richard > might be right. The subroutine calling overhead on modern processors is > rather low and smaller code means better cache hit rates ... Well, I just worry the call may itself include at least the same number of instructions as the callee if inlined. There would be no way for it to be faster. That may happen for a leaf function -- the call itself, plus $ra saving/restoration is already four instructions. Now it's sufficient for two statics to be needed to preserve temporaries across such a call and the size of the caller is already the same. With three statics, you lose even for a non-leaf function. That's for a function containing a single call to such a shift -- if there are more, then you may win (but is it common?). So not only it may not be faster, but the resulting code may be bigger as well. That said, the current GCC's implementation of these operations is not exactly optimal for current MIPS processors. That's trivial to deal with in Linux, but would it be possible to pick a different implementation from libgcc based on the "-march=" setting, too? Maciej From toch@dfpost.ru Mon Jul 26 17:15:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jul 2004 17:16:02 +0100 (BST) Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:51099 "EHLO mail.postwin.ru") by linux-mips.org with ESMTP id ; Mon, 26 Jul 2004 17:15:57 +0100 Received: by mail.postwin.ru (Postfix, from userid 7896) id E95D8844F8; Mon, 26 Jul 2004 20:13:41 +0400 (MSD) Received: from [192.168.9.60] (unknown [192.168.9.60]) by mail.postwin.ru (Postfix) with ESMTP id D6AC9844F5 for ; Mon, 26 Jul 2004 20:13:41 +0400 (MSD) Message-ID: <41056663.6000304@dfpost.ru> Date: Mon, 26 Jul 2004 20:15:31 +0000 From: Dmitriy Tochansky User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040723 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: assembler problem Content-Type: text/plain; charset=ISO-8859-1; 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: 5557 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: toch@dfpost.ru Precedence: bulk X-list: linux-mips Hello! I have some problem with assembling my program. Here is a string from source: *//*/ jal sdram_memory_test/ in .lst file I got: /101 00c8 7600000C jal sdram_memory_test/ Looking for sdram_memory_test below.... /295 01d8 0000083C la ADDR, _etext /* Start addr of test *// Hm... Upload test2.bin in 0xbfc00000 on flash. Starting. Debugging.... Everything goes fine but when become time to jump on sdram_memory_test it jumps at 0xb00001d8 but I think it must jump to 0xbfc001d8 where real sdram_test is. Where is the problem? Dmitriy From thomas.koeller@baslerweb.com Tue Jul 27 09:56:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Jul 2004 09:56:34 +0100 (BST) Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:48136 "EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP id ; Tue, 27 Jul 2004 09:56:30 +0100 Received: from comm1.baslerweb.com (proxy.baslerweb.com [172.16.13.2]) by proxy.baslerweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Tue, 27 Jul 2004 10:55:57 +0200 Received: from [172.16.13.253] (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PLG5NBQP; Tue, 27 Jul 2004 10:56:25 +0200 From: Thomas Koeller Organization: Basler AG To: linux-mips@linux-mips.org Subject: ABI question Date: Tue, 27 Jul 2004 10:57:52 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200407271057.53237.thomas.koeller@baslerweb.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: 5558 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: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips Hi, for 2.6 kernels, arch/mips/Makefile contains the following lines: ifdef CONFIG_MIPS64 gcc-abi = 64 gas-abi = 32 tool-prefix = $(64bit-tool-prefix) UTS_MACHINE := mips64 endif Is it intentional that gcc-abi and gas-abi are different? This results in '-Wa,-32' appearing on gcc's command line, causing the asembler to complain: Error: -mgp64 used with a 32-bit ABI If I change gas-abi to 64, this error goes away. tk -- -------------------------------------------------- Thomas Koeller, Software Development Basler Vision Technologies thomas dot koeller at baslerweb dot com http://www.baslerweb.com ============================== From rsandifo@redhat.com Tue Jul 27 10:46:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Jul 2004 10:46:30 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:3781 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Tue, 27 Jul 2004 10:46:25 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6R9kMe1008195; Tue, 27 Jul 2004 05:46:22 -0400 Received: from localhost (mail@vpnuser5.surrey.redhat.com [172.16.9.5]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6R9kLa11419; Tue, 27 Jul 2004 05:46:21 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1BpOXM-0002Rh-00; Tue, 27 Jul 2004 10:46:20 +0100 To: Thomas Koeller Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix gcc-3.4.x compilation References: <200407261237.09965.thomas.koeller@baslerweb.com> From: Richard Sandiford Date: Tue, 27 Jul 2004 10:46:20 +0100 In-Reply-To: <200407261237.09965.thomas.koeller@baslerweb.com> (Thomas Koeller's message of "Mon, 26 Jul 2004 12:37:09 +0200") Message-ID: <87fz7dvl3n.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: 5559 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: rsandifo@redhat.com Precedence: bulk X-list: linux-mips Thomas Koeller writes: > Since the meaning of 'accum' used to be 'hi' and 'lo', all its uses > were clearly redundant. For the record, that isn't quite true. GCC internally treated "accum" as an entirely separate register (which is why it became such a headache). In theory, if you have an instruction that clobbers lo and hi, but doesn't clobber "accum", gcc might think that a value in "accum" will still be valid. Richard From macro@linux-mips.org Tue Jul 27 14:05:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Jul 2004 14:05:09 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:3852 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 27 Jul 2004 14:05:05 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 511ECE1CC4; Tue, 27 Jul 2004 15:04:59 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12977-07; Tue, 27 Jul 2004 15:04:59 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 3266DE1CBE; Tue, 27 Jul 2004 15:04:59 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i6RD585x012577; Tue, 27 Jul 2004 15:05:09 +0200 Date: Tue, 27 Jul 2004 15:05:02 +0200 (CEST) From: "Maciej W. Rozycki" To: Thomas Koeller Cc: linux-mips@linux-mips.org Subject: Re: ABI question In-Reply-To: <200407271057.53237.thomas.koeller@baslerweb.com> Message-ID: References: <200407271057.53237.thomas.koeller@baslerweb.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 5560 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@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 27 Jul 2004, Thomas Koeller wrote: > for 2.6 kernels, arch/mips/Makefile contains the following lines: > > ifdef CONFIG_MIPS64 > gcc-abi = 64 > gas-abi = 32 > tool-prefix = $(64bit-tool-prefix) > UTS_MACHINE := mips64 > endif > > Is it intentional that gcc-abi and gas-abi are different? This It is -- some people want to use 32-bit pointers within Linux, to conserve memory. It seems to work with older tools, but I've never tried that. > results in '-Wa,-32' appearing on gcc's command line, causing > the asembler to complain: > > Error: -mgp64 used with a 32-bit ABI > > If I change gas-abi to 64, this error goes away. You may run `make "gas-abi=64" ' as a workaround. I'm going to make it selectable in the configuration one day. Maciej From nickiecoor@evanfarmercc.every1.net Wed Jul 28 16:13:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Jul 2004 16:13:34 +0100 (BST) Received: from [IPv6:::ffff:222.65.103.147] ([IPv6:::ffff:222.65.103.147]:38917 "HELO evanfarmercc.every1.net") by linux-mips.org with SMTP id ; Wed, 28 Jul 2004 16:13:30 +0100 Message-ID: Date: Wed, 28 Jul 2004 06:06:45 -0800 Reply-To: "mose munson" From: "mose munson" User-Agent: mPOP Web-Mail 2.19 X-Accept-Language: en-us MIME-Version: 1.0 To: "ronny stojanovic" Cc: "coy caudle" , "donovan blanton" Subject: 2004 health watch 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: 5561 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: nickiecoor@evanfarmercc.every1.net Precedence: bulk X-list: linux-mips ^fotoluz~afhøstningen_indicizzati. eur^`ope'-an m'`e^ds & 0v~^e_rnig~`ht d~~e`,liver bigamister^ http://www.bestplace4meds.com/track.asp?cg=hot&c=info -----Original Message----- From: Beula Fields [mailto:lq@hno.com] To: russel wings; conrad henriquez Sent: Saturday, September, 2004 6:49 AM Subject: 2004 health watch kunu meginjardir brisingi Should further research be conducted to assess combination versus monotherapy? Novel lactams should not be compared with older generation lactams or penicillins combined with aminoglycosides The reason for further trials assessing the addition of an aminglycoside to a lactam seems dubious as well How come you're here?'trills from my tonsils. 'We're friends of Bruce and Sophie Robinson and he invited us.We loved Withnail.If you're interested I've written a script called LA Story that has a part you might wanna do.if it happens.Prabably a year from now.Depending.Not the lead role.Wrote that for myself.'He's doing that ironic dumb act I know from his records and tapes.Voice and all. entricar11zarpa10nectarino,mamancona frijo`n. From hjl@lucon.org Wed Jul 28 17:19:54 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Jul 2004 17:19:59 +0100 (BST) Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:21726 "EHLO sccrmhc12.comcast.net") by linux-mips.org with ESMTP id ; Wed, 28 Jul 2004 17:19:54 +0100 Received: from lucon.org ([24.6.43.109]) by comcast.net (sccrmhc12) with ESMTP id <2004072816194701200qmr3be>; Wed, 28 Jul 2004 16:19:48 +0000 Received: by lucon.org (Postfix, from userid 1000) id 3704964297; Wed, 28 Jul 2004 09:19:47 -0700 (PDT) Date: Wed, 28 Jul 2004 09:19:47 -0700 From: "H. J. Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Mat Hostetter , Warner Losh , linux-mips@linux-mips.org, Ralf Baechle , Linas Vepstas Subject: The Linux binutils 2.15.91.0.2 is released Message-ID: <20040728161947.GA2003@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i 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: 5562 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: hjl@lucon.org Precedence: bulk X-list: linux-mips This is the beta release of binutils 2.15.91.0.2 for Linux, which is based on binutils 2004 0727 in CVS on sources.redhat.com plus various changes. It is purely for Linux. Please report any bugs related to binutils 2.15.91.0.2 to hjl@lucon.org and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.15.91.0.1: 1. Update from binutils 2004 0727. 2. Fix the x86_64 linker to prevent non-PIC code in shared library. 3. Fix the ia64 linker to warn the relotable files which can't be relaxed. 4. Fix the comdat group support. Allow mix single-member comdat group with linkonce section. 5. Added --add-needed/--no-add-needed options to linker. 6. Fix the SHF_LINK_ORDER support. 7. Fix the ia64 assembler for multiple sections with the same name and SHT_IA_64_UNWIND sections. 8. Fix the ia64 assembler for merge section and relaxation. Changes from binutils 2.15.90.0.3: 1. Update from binutils 2004 0527. 2. Fix -x auto option in the ia64 assembler. 3. Add the AR check in the ia64 assembler. 4. Fix the section group support. 5. Add a new -z relro linker option. 6. Fix an exception section placement bug in linker. 7. Add .serialize.data and .serialize.instruction to the ia64 assembler. Changes from binutils 2.15.90.0.2: 1. Update from binutils 2004 0415. 2. Fix the linker for weak undefined symbol handling. 3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC code. Changes from binutils 2.15.90.0.1.1: 1. Update from binutils 2004 0412. 2. Add --as-needed/--no-as-needed to linker. 3. Fix -z defs in linker. 4. Always reserve the memory for ia64 dynamic linker. 5. Fix a race condition in ia64 lazy binding. Changes from binutils 2.15.90.0.1: 1. Fixed an ia64 assembler bug. 2. Install the assembler man page. Changes from binutils 2.14.90.0.8: 1. Update from binutils 2004 0303. 2. Fixed linker for undefined symbols with non-default visibility. 3. Sped up linker weakdef symbol handling. 4. Fixed mixing ELF32 and ELF64 object files in archive. 5. Added ia64 linker brl optimization. 6. Fixed ia64 linker to disallow invalid dynamic relocations. 7. Fixed DT_TEXTREL handling in ia64 linker. 8. Fixed alignment handling in ia64 assembler. 9. Improved ia64 assembler unwind table handling. Changes from binutils 2.14.90.0.7: 1. Update from binutils 2004 0114. 2. Fixed an ia64 assembler unwind table bug. 3. Better handle IPF linker relaxation overflow. 4. Fixed misc PPC bugs. Changes from binutils 2.14.90.0.6: 1. Update from binutils 2003 1029. 2. Allow type changes for undefined symbols. 3. Fix EH frame optimization. 4. Fix the check for undefined versioned symbol with wildcard. 5. Support generating code for Itanium. 6. Detect and warn bad symbol index. 7. Update IPF assemebler DV check. Changes from binutils 2.14.90.0.5: 1. Update from binutils 2003 0820. 2. No longer use section names for ELF section types nor flags. 3. Fix some ELF/IA64 linker bugs. 4. Fix some ELF/ppc bugs. 5. Add archive support to readelf. Changes from binutils 2.14.90.0.4.1: 1. Update from binutils 2003 0722. 2. Fix an ELF/mips linker bug. 3. Fix an ELF/hpppa linker bug. 4. Fix an ELF/ia64 assembler bug. 5. Fix a linkonce support with C++ debug. 6. A new working C++ demangler. 7. Various alpha, mips, ia64, ... bug fixes. 8. Support for the current gcc and glibc. Changes from binutils 2.14.90.0.4: 1. Fix an ia64 assembler hint@pause bug. 2. Support Intel Prescott New Instructions. Changes from binutils 2.14.90.0.3: 1. Work around the brain dead libtool. Changes from binutils 2.14.90.0.2: 1. Update from binutils 2003 0523. 2. Fix 2 ELF visibility bugs. 3. Fix ELF/ppc linker bugs. Changes from binutils 2.14.90.0.1: 1. Update from binutils 2003 0515. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Add more IAS compatibilities to ia64 assembler. Changes from binutils 2.13.90.0.20: 1. Update from binutils 2003 0505. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Fix some ia64 assembler bugs. 5. Add some IAS compatibilities to ia64 assembler. 6. Fix ELF common symbol alignment. 7. Fix ELF weak symbol handling. Changes from binutils 2.13.90.0.18: 1. Update from binutils 2003 0319. 2. Fix an ia64 linker brl relaxation bug. 3. Fix some ELF/ppc linker bugs. Changes from binutils 2.13.90.0.16: 1. Update from binutils 2003 0121. 2. Fix an ia64 gas bug. 3. Fix some TLS bugs. 4. Fix some ELF/ppc bugs. 5. Fix an ELF/m68k bug. 2. Include /usr/bin/c++filt. Changes from binutils 2.13.90.0.14: 1. Update from binutils 2002 1126. 2. Include /usr/bin/c++filt. 3. Fix "ld -r" with execption handling. Changes from binutils 2.13.90.0.10: 1. Update from binutils 2002 1114. 2. Fix ELF/alpha bugs. 3. Fix an ELF/i386 assembler bug. Changes from binutils 2.13.90.0.4: 1. Update from binutils 2002 1010. 2. More ELF/PPC linker bug fixes. 3. Fix an ELF/alpha linker bug. 4. Fix an ELF/sparc linker bug to support Solaris. 5. More TLS updates. Changes from binutils 2.13.90.0.3: 1. Update from binutils 2002 0814. 2. Fix symbol versioning bugs for gcc 3.2. 3. Fix mips gas. Changes from binutils 2.13.90.0.2: 1. Update from binutils 2002 0809. 2. Fix a mips gas compatibility bug. 3. Fix an x86 TLS bfd bug. 4. Fix an x86 PIC gas bug. 5. Improve symbol versioning support. The file list: 1. binutils-2.15.91.0.2.tar.bz2. Source code. 2. binutils-2.15.91.0.1-2.15.91.0.2.diff.bz2. Patch against the previous beta source code. 3. binutils-2.15.91.0.2-1.i386.rpm. IA-32 binary RPM for RedHat EL 3. 4. binutils-2.15.91.0.2-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3. 5. binutils-2.15.91.0.2-1.x86_64.rpm. X64_64 binary RPM for RedHat EL 3. There is no separate source rpm. You can do # rpmbuild -ta binutils-2.15.91.0.2.tar.bz2 to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://www.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 07/28/2004 From Ralf.Ackermann@KOM.tu-darmstadt.de Wed Jul 28 19:32:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Jul 2004 19:33:01 +0100 (BST) Received: from drum.kom.e-technik.tu-darmstadt.de ([IPv6:::ffff:130.83.139.190]:27368 "EHLO mailserver.KOM.e-technik.tu-darmstadt.de") by linux-mips.org with ESMTP id ; Wed, 28 Jul 2004 19:32:56 +0100 Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id UAA27903; Wed, 28 Jul 2004 20:32:50 +0200 (MEST) Date: Wed, 28 Jul 2004 20:33:40 +0200 (CEST) From: Ralf Ackermann X-X-Sender: rac@shofar.kom.e-technik.tu-darmstadt.de To: linux-mips@linux-mips.org cc: Ralf Ackermann Subject: [meshcube-dev] Q: 2.6 kernel anybody? (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: 5563 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: rac@KOM.tu-darmstadt.de Precedence: bulk X-list: linux-mips Hello, has anybody made experiences in running a 2.6.x kernel on the Meshcube? Where to look at / start with for that purpose? (The main reason for my question is the potential support for a MiniPCI ATI rage VGA card in 2.6.x - as mentioned on the list before, 2.6.x takes care of the initialization that is the BIOS's work on x86 platforms). best regards Ralf --------------------------------------------------------------- Dr. Ralf Ackermann _ rac@KOM.tu-darmstadt.de Multimedia Communications |/ | | |\/| Merckstrasse 25 |\ |_| | | 64283 Darmstadt, Germany Tel.: (+49) 6151 16-6138 Fax: (+49) 6151 16-6152 --------------------------------------------------------------- http://www.kom.tu-darmstadt.de/~rac --------------------------------------------------------------- _______________________________________________ dev-list mailing list dev-list@meshcube.org https://meshcube.org/cgi-bin/mailman/listinfo/dev-list From greg.roelofs@philips.com Wed Jul 28 20:52:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Jul 2004 20:52:48 +0100 (BST) Received: from gw-nam4.philips.com ([IPv6:::ffff:161.88.253.58]:60065 "EHLO gw-nam4.philips.com") by linux-mips.org with ESMTP id ; Wed, 28 Jul 2004 20:52:44 +0100 Received: from smtpscan-nam4.philips.com (smtpscan-nam4.mail.philips.com [167.81.103.7]) by gw-nam4.philips.com (Postfix) with ESMTP id 369F996085 for ; Wed, 28 Jul 2004 19:52:37 +0000 (UTC) Received: from smtpscan-nam4.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 16D0195 for ; Wed, 28 Jul 2004 19:52:37 +0000 (GMT) Received: from smtprelay-nam2.philips.com (smtprelay-nam2.philips.com [167.81.103.9]) by smtpscan-nam4.philips.com (Postfix) with ESMTP id E38246B for ; Wed, 28 Jul 2004 19:52:36 +0000 (GMT) Received: from anrrmh02.diamond.philips.com (anrrmh02-srv.diamond.philips.com [167.81.112.96]) by smtprelay-nam2.philips.com (8.9.3p3/8.9.3-1.2.2m-20040401) with ESMTP id TAA26770 for ; Wed, 28 Jul 2004 19:52:36 GMT From: greg.roelofs@philips.com To: Subject: apparent math-emu hang on movf instruction Date: Wed, 28 Jul 2004 12:54:04 -0700 Message-ID: X-MIMETrack: Serialize by Router on anrrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1HF681 | June 22, 2004) at 28/07/2004 15:51:10, Serialize complete at 28/07/2004 15:51:10 MIME-Version: 1.0 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: 5564 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: greg.roelofs@philips.com Precedence: bulk X-list: linux-mips I hope this isn't a FAQ or a complete newbie oversight, but I haven't found any mention of a similar problem in the FAQs or in the last 18 months' archives of this list. I have some floating-point code that hangs, apparently on a movf instruction, with CPU usage pegged at 99%. It's interruptible, but that's the best that can be said about it. The C code in question is a simple comparison of an integer array element with a floating-point constant (0.0, in fact). When (cross-) compiled with either gcc 3.3.4 or 3.3.1 and -O1 (or -O2) and -mtune=r4600 -mips32, it generates the movf instruction. Compiled either without optimization or without the r4600/mips32 options, it generates a branch instead; that version works. My attempts so far to create a simplified test case have not succeeded; it seems to be slightly tricky to get GCC to emit this instruction. (I'm not an expert in either GCC, the Linux kernel, or MIPS hardware, btw, so apologies if I'm completely off-track here.) The kernel is question is a 2.4.20 derivative (MontaVista Linux 3.1), and the processor is a Philips PR4450: MIPS32 core, no floating-point, some minor extensions and timing differences in a few instructions. We're using the kernel's FP emulation rather than GCC's soft-float, and my working assumption at this point is that it's a problem with the emulation, since movf is described as "move conditional on floating- point false." Q1: Is that a correct assumption? I've just started looking at the kernel's emulation code, and one thing that pops out immediately is that there's no mention of movf anywhere in arch/mips/math-emu, though cp1emu.c does cover movc, movn, movz, and plain mov (at least, their .fmt variants). Nor does the latest(?) CVS version (http://www.linux-mips.org/cvsweb/linux/arch/mips/math-emu/ cp1emu.c?rev=1.32&content-type=text/x-cvsweb-markup). On the other hand, they also don't mention bc1t, "branch on FP true"--which works--so I'm probably not on the right track here. Q2: Am I? I would have expected an unemulated instruction to throw an illegal instruction exception or cause an oops or something, not to spin indefinitely. Q3: Any suggestions for what to test/look at/do next? (Of course, it's also possible that it's a hardware problem of some sort, although it doesn't feel that way to me. Then again, I don't trust such feelings very far...) Here's the C code that fails: if (a[m][n] != 0.0) i++; Here's its assembler output ($f20 was previously loaded with zero via "mtc1 $0,$f20", and $16 contains the pointer a[m]): l.s $f2,0($16) # $f2 = a[m][n] (32-bit) lw $3,24($sp) # $3 = i cvt.d.w $f0,$f2 # FP: convert int32 ($f2) to double ($f0) c.eq.d $f0,$f20 # FP: conditional: $f0 == $f20 ? addu $2,$3,1 # add unsigned: $2 = i + 1 la $4,$LC32 # "DEBUG: checking ..." (later printf) movf $3,$2,$fcc0 # move if FP false (fcc0 = 0): $3 = $2 = i+1 sw $3,24($sp) # i = $3 (store on stack) ... [printf stuff, etc.] Thanks for any help/suggestions, -- Greg Roelofs `Name an animal that's small and fuzzy.' `Mold.' Philips Semiconductors greg.roelofs@philips.com From rsandifo@redhat.com Thu Jul 29 07:54:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Jul 2004 07:54:59 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:31940 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Thu, 29 Jul 2004 07:54:55 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T6sre1015042; Thu, 29 Jul 2004 02:54:53 -0400 Received: from localhost (mail@vpnuser3.surrey.redhat.com [172.16.9.3]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T6sqa03999; Thu, 29 Jul 2004 02:54:52 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1Bq4oU-0000LZ-00; Thu, 29 Jul 2004 07:54:50 +0100 To: greg.roelofs@philips.com Cc: Subject: Re: apparent math-emu hang on movf instruction References: From: Richard Sandiford Date: Thu, 29 Jul 2004 07:54:50 +0100 In-Reply-To: (greg roelofs's message of "Wed, 28 Jul 2004 12:54:04 -0700") Message-ID: <876587uwud.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: 5565 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: rsandifo@redhat.com Precedence: bulk X-list: linux-mips greg.roelofs@philips.com writes: > I've just started looking at the kernel's emulation code, and one thing > that pops out immediately is that there's no mention of movf anywhere > in arch/mips/math-emu, though cp1emu.c does cover movc, movn, movz, and > plain mov (at least, their .fmt variants). "movc" covers both movf and movt (bit 16 says which). But yes, it does look like an emulation bug. It seems that the code to handle GPR conditional moves (in cop1Emulate) was copied from the code to handle FPR moves (in fpu_emu). The cop1Emulate() code reads: if (((ctx->fcr31 & cond) != 0) != ((MIPSInst_RT(ir) & 1) != 0)) return 0; xcp->regs[MIPSInst_RD(ir)] = xcp->regs[MIPSInst_RS(ir)]; "return 0" was fine in fpu_emu(), but not here, since it skips the all-important: /* we did it !! */ xcp->cp0_epc = VA_TO_REG(contpc); xcp->cp0_cause &= ~CAUSEF_BD; return 0; So we'd reenter the exception handler on exit. Does the patch below (against 2.6) fix things? Only the first hunk is needed to fix the bug, the rest is just there for consistency. Richard Index: arch/mips/math-emu/cp1emu.c =================================================================== RCS file: /home/cvs/linux/arch/mips/math-emu/cp1emu.c,v retrieving revision 1.32 diff -u -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.32 cp1emu.c --- arch/mips/math-emu/cp1emu.c 19 Jan 2004 16:25:21 -0000 1.32 +++ arch/mips/math-emu/cp1emu.c 29 Jul 2004 06:42:53 -0000 @@ -528,9 +528,8 @@ static int cop1Emulate(struct pt_regs *x if (MIPSInst_FUNC(ir) != movc_op) return SIGILL; cond = fpucondbit[MIPSInst_RT(ir) >> 2]; - if (((ctx->fcr31 & cond) != 0) != ((MIPSInst_RT(ir) & 1) != 0)) - return 0; - xcp->regs[MIPSInst_RD(ir)] = xcp->regs[MIPSInst_RS(ir)]; + if (((ctx->fcr31 & cond) != 0) == ((MIPSInst_RT(ir) & 1) != 0)) + xcp->regs[MIPSInst_RD(ir)] = xcp->regs[MIPSInst_RS(ir)]; break; #endif @@ -850,20 +849,17 @@ static int fpu_emu(struct pt_regs *xcp, #if __mips >= 4 case fmovc_op: cond = fpucondbit[MIPSInst_FT(ir) >> 2]; - if (((ctx->fcr31 & cond) != 0) != + if (((ctx->fcr31 & cond) != 0) == ((MIPSInst_FT(ir) & 1) != 0)) - return 0; - SPFROMREG(rv.s, MIPSInst_FS(ir)); + SPFROMREG(rv.s, MIPSInst_FS(ir)); break; case fmovz_op: - if (xcp->regs[MIPSInst_FT(ir)] != 0) - return 0; - SPFROMREG(rv.s, MIPSInst_FS(ir)); + if (xcp->regs[MIPSInst_FT(ir)] == 0) + SPFROMREG(rv.s, MIPSInst_FS(ir)); break; case fmovn_op: - if (xcp->regs[MIPSInst_FT(ir)] == 0) - return 0; - SPFROMREG(rv.s, MIPSInst_FS(ir)); + if (xcp->regs[MIPSInst_FT(ir)] != 0) + SPFROMREG(rv.s, MIPSInst_FS(ir)); break; #endif case fabs_op: @@ -1040,20 +1036,17 @@ static int fpu_emu(struct pt_regs *xcp, #if __mips >= 4 case fmovc_op: cond = fpucondbit[MIPSInst_FT(ir) >> 2]; - if (((ctx->fcr31 & cond) != 0) != + if (((ctx->fcr31 & cond) != 0) == ((MIPSInst_FT(ir) & 1) != 0)) - return 0; - DPFROMREG(rv.d, MIPSInst_FS(ir)); + DPFROMREG(rv.d, MIPSInst_FS(ir)); break; case fmovz_op: - if (xcp->regs[MIPSInst_FT(ir)] != 0) - return 0; - DPFROMREG(rv.d, MIPSInst_FS(ir)); + if (xcp->regs[MIPSInst_FT(ir)] == 0) + DPFROMREG(rv.d, MIPSInst_FS(ir)); break; case fmovn_op: - if (xcp->regs[MIPSInst_FT(ir)] == 0) - return 0; - DPFROMREG(rv.d, MIPSInst_FS(ir)); + if (xcp->regs[MIPSInst_FT(ir)] != 0) + DPFROMREG(rv.d, MIPSInst_FS(ir)); break; #endif case fabs_op: From rsandifo@redhat.com Thu Jul 29 08:01:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Jul 2004 08:01:31 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:9159 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Thu, 29 Jul 2004 08:01:27 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6T71Qe1016478; Thu, 29 Jul 2004 03:01:26 -0400 Received: from localhost (mail@vpnuser3.surrey.redhat.com [172.16.9.3]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6T71Pa05066; Thu, 29 Jul 2004 03:01:25 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1Bq4uq-0000Lk-00; Thu, 29 Jul 2004 08:01:24 +0100 To: greg.roelofs@philips.com Cc: Subject: Re: apparent math-emu hang on movf instruction References: <876587uwud.fsf@redhat.com> From: Richard Sandiford Date: Thu, 29 Jul 2004 08:01:24 +0100 In-Reply-To: <876587uwud.fsf@redhat.com> (Richard Sandiford's message of "Thu, 29 Jul 2004 07:54:50 +0100") Message-ID: <871xivuwjf.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: 5566 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: rsandifo@redhat.com Precedence: bulk X-list: linux-mips Richard Sandiford writes: > Does the patch below (against 2.6) fix things? Only the first hunk > is needed to fix the bug, the rest is just there for consistency. Oops! Serves me right for dabbling in new code. Only the first hunk is correct. Richard Index: arch/mips/math-emu/cp1emu.c =================================================================== RCS file: /home/cvs/linux/arch/mips/math-emu/cp1emu.c,v retrieving revision 1.32 diff -u -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.32 cp1emu.c --- arch/mips/math-emu/cp1emu.c 19 Jan 2004 16:25:21 -0000 1.32 +++ arch/mips/math-emu/cp1emu.c 29 Jul 2004 06:42:53 -0000 @@ -528,9 +528,8 @@ static int cop1Emulate(struct pt_regs *x if (MIPSInst_FUNC(ir) != movc_op) return SIGILL; cond = fpucondbit[MIPSInst_RT(ir) >> 2]; - if (((ctx->fcr31 & cond) != 0) != ((MIPSInst_RT(ir) & 1) != 0)) - return 0; - xcp->regs[MIPSInst_RD(ir)] = xcp->regs[MIPSInst_RS(ir)]; + if (((ctx->fcr31 & cond) != 0) == ((MIPSInst_RT(ir) & 1) != 0)) + xcp->regs[MIPSInst_RD(ir)] = xcp->regs[MIPSInst_RS(ir)]; break; #endif From yuasa@hh.iij4u.or.jp Thu Jul 29 17:01:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Jul 2004 17:01:23 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:51412 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Thu, 29 Jul 2004 17:01:19 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id BAA15169; Fri, 30 Jul 2004 01:01:15 +0900 (JST) Received: 4UMDO01 id i6TG1Ej13611; Fri, 30 Jul 2004 01:01:14 +0900 (JST) Received: 4UMRO00 id i6TG1CMR004861; Fri, 30 Jul 2004 01:01:13 +0900 (JST) from stratos (localhost [127.0.0.1]) (authenticated) Date: Fri, 30 Jul 2004 01:01:12 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH] vr41xx: remove obsolete flag Message-Id: <20040730010112.3b54404b.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-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: 5567 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: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, This patch removes an obsolete flag in serial driver. Please apply this patch to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c --- linux-orig/arch/mips/vr41xx/common/serial.c Thu Jul 22 00:29:06 2004 +++ linux/arch/mips/vr41xx/common/serial.c Thu Jul 29 00:49:32 2004 @@ -160,7 +160,7 @@ port.line = vr41xx_serial_ports; port.uartclk = DSIU_BASE_BAUD * 16; port.irq = DSIU_IRQ; - port.flags = UPF_RESOURCES | UPF_BOOT_AUTOCONF | UPF_SKIP_TEST; + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST; port.mapbase = DSIU_BASE; port.regshift = 0; port.iotype = UPIO_MEM; From greg.roelofs@philips.com Thu Jul 29 22:52:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Jul 2004 22:52:29 +0100 (BST) Received: from gw-nam4.philips.com ([IPv6:::ffff:161.88.253.58]:25050 "EHLO gw-nam4.philips.com") by linux-mips.org with ESMTP id ; Thu, 29 Jul 2004 22:52:25 +0100 Received: from smtpscan-nam3.philips.com (smtpscan-nam3.mail.philips.com [167.81.103.6]) by gw-nam4.philips.com (Postfix) with ESMTP id CCD419612A; Thu, 29 Jul 2004 21:52:18 +0000 (UTC) Received: from smtpscan-nam3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 9D68A62; Thu, 29 Jul 2004 21:52:18 +0000 (GMT) Received: from smtprelay-nam2.philips.com (smtprelay-nam2.philips.com [167.81.103.9]) by smtpscan-nam3.philips.com (Postfix) with ESMTP id 6508284; Thu, 29 Jul 2004 21:52:18 +0000 (GMT) Received: from anrrmh02.diamond.philips.com (anrrmh02-srv.diamond.philips.com [167.81.112.96]) by smtprelay-nam2.philips.com (8.9.3p3/8.9.3-1.2.2m-20040401) with ESMTP id VAA21415; Thu, 29 Jul 2004 21:52:18 GMT From: greg.roelofs@philips.com To: Subject: Re: apparent math-emu hang on movf instruction Cc: Date: Thu, 29 Jul 2004 14:53:46 -0700 Message-ID: X-MIMETrack: Serialize by Router on anrrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1HF681 | June 22, 2004) at 29/07/2004 17:50:52, Serialize complete at 29/07/2004 17:50:52 MIME-Version: 1.0 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: 5568 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: greg.roelofs@philips.com Precedence: bulk X-list: linux-mips Richard Sandiford wrote... >> Does the patch below (against 2.6) fix things? Only the first hunk >> is needed to fix the bug, the rest is just there for consistency. > Oops! Serves me right for dabbling in new code. Only the first > hunk is correct. Yup, that does it! Many thanks. The only thing I had to change for 2.4.x was the name of the "fcr31" soft-struct member; it's "sr" in older kernels: > + if (((ctx->fcr31 & cond) != 0) == ((MIPSInst_RT(ir) & 1) != 0)) ^^^^^ sr > + xcp->regs[MIPSInst_RD(ir)] = xcp->regs[MIPSInst_RS(ir)]; (Ralf renamed things on 20030720, according to the cvsweb.) Thanks again, -- Greg Roelofs `Name an animal that's small and fuzzy.' `Mold.' Philips Semiconductors greg.roelofs@philips.com From xuhaoz@neonetech.com Fri Jul 30 09:09:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Jul 2004 09:09:29 +0100 (BST) Received: from [IPv6:::ffff:211.155.249.251] ([IPv6:::ffff:211.155.249.251]:57804 "EHLO nnt.neonetech.com") by linux-mips.org with ESMTP id ; Fri, 30 Jul 2004 09:09:25 +0100 Received: from wbar1 ([221.219.32.2]) by nnt.neonetech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jul 2004 16:12:47 +0800 Date: Fri, 30 Jul 2004 16:09:25 +0800 From: "xuhaoz" To: "linux-mips" Subject: cflags -mips1 error X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Message-ID: X-OriginalArrivalTime: 30 Jul 2004 08:12:48.0015 (UTC) FILETIME=[000449F0:01C4760D] 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: 5569 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: xuhaoz@neonetech.com Precedence: bulk X-list: linux-mips aGVsbG8NCiAgbXkgY3B1IGlzIG1pcHMxLCBhbmQgaSB1c2UgdWNsaW51eC1kaXN0XGxpbnV4Mi40 LngNCg0Kd2hlbiBpIHJ1biBtYWtlIGluIHRoZSB1Y2xpbnV4LWRpc3RcIHdpdGggLW1pcHMxICwg dGhlcmUgaXMgYW4gZXJyb3IgbGlrZSB0aGlzOg0KDQoNCiA+DQo+cm9vdEB4dWhhb3ogdUNsaW51 eC1kaXN0XSMgbWFrZQ0KPm1ha2UgQVJDSD1taXBzIENST1NTX0NPTVBJTEU9bWlwc2VsLWxpbnV4 LSAtQyBsaW51eC0yLjQueCAgfHwgZXhpdCAxDQo+bWFrZVsxXTogRW50ZXJpbmcgZGlyZWN0b3J5 IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngnDQo+LiBzY3JpcHRzL21rdmVyc2lv biA+IC50bXB2ZXJzaW9uDQo+bWlwc2VsLWxpbnV4LWdjYyAtRF9fS0VSTkVMX18gLUkvdXNyL3Ny Yy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvaW5jbHVkZQ0KPi1XYWxsDQo+LVdzdHJpY3QtcHJv dG90eXBlcyAtV25vLXRyaWdyYXBocyAtbWlwczEgLU8yIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1m bm8tY29tbW9uDQo+LWZvbWl0LWZyYW1lLXBvaW50ZXIgLUkgL3Vzci9zcmMvdUNsaW51eC1kaXN0 L2xpbnV4LTIuNC54L2luY2x1ZGUvYXNtL2djYyAtRyAwDQo+LW1uby1hYmljYWxscyAtZm5vLXBp YyAtcGlwZSAgIC1EVVRTX01BQ0hJTkU9JyJtaXBzIicNCj4tREtCVUlMRF9CQVNFTkFNRT12ZXJz aW9uIC1jIC1vIGluaXQvdmVyc2lvbi5vIGluaXQvdmVyc2lvbi5jDQo+bWFrZSBDRkxBR1M9Ii1E X19LRVJORUxfXyAtSS91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9pbmNsdWRlIC1X YWxsDQo+LVdzdHJpY3QtcHJvdG90eXBlcyAtV25vLXRyaWdyYXBocyAtbWlwczEgLU8yIC1mbm8t c3RyaWN0LWFsaWFzaW5nIC1mbm8tY29tbW9uDQo+LWZvbWl0LWZyYW1lLXBvaW50ZXIgLUkgL3Vz ci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2luY2x1ZGUvYXNtL2djYyAtRyAwDQo+LW1u by1hYmljYWxscyAtZm5vLXBpYyAtcGlwZSAgIiAtQyAgYXJjaC9taXBzL3Rvb2xzDQo+bWFrZVsy XTogRW50ZXJpbmcgZGlyZWN0b3J5DQo+YC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQu eC9hcmNoL21pcHMvdG9vbHMnDQo+Y21wIC1zIG9mZnNldC5oIC91c3Ivc3JjL3VDbGludXgtZGlz dC9saW51eC0yLjQueC9pbmNsdWRlL2FzbS1taXBzL29mZnNldC5oIHx8DQo+KGNwIG9mZnNldC5o IC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9pbmNsdWRlL2FzbS1taXBzL29mZnNl dC5oLm5ldw0KPiYmIG12IC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9pbmNsdWRl L2FzbS1taXBzL29mZnNldC5oLm5ldw0KPi91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQu eC9pbmNsdWRlL2FzbS1taXBzL29mZnNldC5oKQ0KPm1ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5 IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvYXJjaC9taXBzL3Rvb2xzJw0KPm1h a2UgQ0ZMQUdTPSItRF9fS0VSTkVMX18gLUkvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40 LngvaW5jbHVkZSAtV2FsbA0KPi1Xc3RyaWN0LXByb3RvdHlwZXMgLVduby10cmlncmFwaHMgLW1p cHMxIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtZm5vLWNvbW1vbg0KPi1mb21pdC1mcmFtZS1w b2ludGVyIC1JIC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9pbmNsdWRlL2FzbS9n Y2MgLUcgMA0KPi1tbm8tYWJpY2FsbHMgLWZuby1waWMgLXBpcGUgICIgLUMgIGtlcm5lbA0KPm1h a2VbMl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIu NC54L2tlcm5lbCcNCj5tYWtlIGFsbF90YXJnZXRzDQo+bWFrZVszXTogRW50ZXJpbmcgZGlyZWN0 b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40Lngva2VybmVsJw0KPm1pcHNlbC1s aW51eC1nY2MgLURfX0tFUk5FTF9fIC1JL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54 L2luY2x1ZGUNCj4tV2FsbA0KPi1Xc3RyaWN0LXByb3RvdHlwZXMgLVduby10cmlncmFwaHMgLW1p cHMxIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtZm5vLWNvbW1vbg0KPi1mb21pdC1mcmFtZS1w b2ludGVyIC1JIC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9pbmNsdWRlL2FzbS9n Y2MgLUcgMA0KPi1tbm8tYWJpY2FsbHMgLWZuby1waWMgLXBpcGUgICAgLW5vc3RkaW5jIC1pd2l0 aHByZWZpeCBpbmNsdWRlDQo+LURLQlVJTERfQkFTRU5BTUU9c2NoZWQgIC1mbm8tb21pdC1mcmFt ZS1wb2ludGVyIC1jIC1vIHNjaGVkLm8gc2NoZWQuYw0KPntzdGFuZGFyZCBpbnB1dH06IEFzc2Vt YmxlciBtZXNzYWdlczoNCj57c3RhbmRhcmQgaW5wdXR9OjczMjogRXJyb3I6IG9wY29kZSBub3Qg c3VwcG9ydGVkIG9uIHRoaXMgcHJvY2Vzc29yOiBSMzAwMA0KPihNSVBTMSkgYGxsICQzLDAoJDIp Jw0KPntzdGFuZGFyZCBpbnB1dH06NzM0OiBFcnJvcjogb3Bjb2RlIG5vdCBzdXBwb3J0ZWQgb24g dGhpcyBwcm9jZXNzb3I6IFIzMDAwDQo+KE1JUFMxKSBgc2MgJDMsMCgkMiknDQo+e3N0YW5kYXJk IGlucHV0fTo4MTM6IEVycm9yOiBvcGNvZGUgbm90IHN1cHBvcnRlZCBvbiB0aGlzIHByb2Nlc3Nv cjogUjMwMDANCj4oTUlQUzEpIGBsbCAkNiwwKCQ0KScNCj57c3RhbmRhcmQgaW5wdXR9OjgxNTog RXJyb3I6IG9wY29kZSBub3Qgc3VwcG9ydGVkIG9uIHRoaXMgcHJvY2Vzc29yOiBSMzAwMA0KPihN SVBTMSkgYHNjICQ2LDAoJDQpJw0KPntzdGFuZGFyZCBpbnB1dH06ODIyOiBFcnJvcjogb3Bjb2Rl IG5vdCBzdXBwb3J0ZWQgb24gdGhpcyBwcm9jZXNzb3I6IFIzMDAwDQo+KE1JUFMxKSBgbGwgJDIs MCgkMyknDQo+e3N0YW5kYXJkIGlucHV0fTo4MjQ6IEVycm9yOiBvcGNvZGUgbm90IHN1cHBvcnRl ZCBvbiB0aGlzIHByb2Nlc3NvcjogUjMwMDANCj4oTUlQUzEpIGBzYyAkMiwwKCQzKScNCj57c3Rh bmRhcmQgaW5wdXR9Ojg0NDogRXJyb3I6IG9wY29kZSBub3Qgc3VwcG9ydGVkIG9uIHRoaXMgcHJv Y2Vzc29yOiBSMzAwMA0KPihNSVBTMSkgYGxsICQ1LDAoJDIpJw0KPntzdGFuZGFyZCBpbnB1dH06 ODQ2OiBFcnJvcjogb3Bjb2RlIG5vdCBzdXBwb3J0ZWQgb24gdGhpcyBwcm9jZXNzb3I6IFIzMDAw DQo+KE1JUFMxKSBgc2MgJDQsMCgkMiknDQo+e3N0YW5kYXJkIGlucHV0fTo4NDk6IEVycm9yOiBv cGNvZGUgbm90IHN1cHBvcnRlZCBvbiB0aGlzIHByb2Nlc3NvcjogUjMwMDANCj4oTUlQUzEpIGBz eW5jICcNCj57c3RhbmRhcmQgaW5wdXR9OjMyMzE6IEVycm9yOiBvcGNvZGUgbm90IHN1cHBvcnRl ZCBvbiB0aGlzIHByb2Nlc3NvcjogUjMwMDANCj4oTUlQUzEpIGBsbCAkMywwKCQyKScNCj57c3Rh bmRhcmQgaW5wdXR9OjMyMzM6IEVycm9yOiBvcGNvZGUgbm90IHN1cHBvcnRlZCBvbiB0aGlzIHBy b2Nlc3NvcjogUjMwMDANCj4oTUlQUzEpIGBzYyAkMywwKCQyKScNCj57c3RhbmRhcmQgaW5wdXR9 OjMyNDk6IEVycm9yOiBvcGNvZGUgbm90IHN1cHBvcnRlZCBvbiB0aGlzIHByb2Nlc3NvcjogUjMw MDANCj4oTUlQUzEpIGBsbCAkMywwKCQyKScNCj57c3RhbmRhcmQgaW5wdXR9OjMyNTE6IEVycm9y OiBvcGNvZGUgbm90IHN1cHBvcnRlZCBvbiB0aGlzIHByb2Nlc3NvcjogUjMwMDANCj4oTUlQUzEp IGBzYyAkMywwKCQyKScNCj57c3RhbmRhcmQgaW5wdXR9OjMzMzY6IEVycm9yOiBvcGNvZGUgbm90 IHN1cHBvcnRlZCBvbiB0aGlzIHByb2Nlc3NvcjogUjMwMDANCj4oTUlQUzEpIGBsbCAkNCx3YWl0 X2luaXRfaWRsZSgkMyknDQo+e3N0YW5kYXJkIGlucHV0fTozMzM4OiBFcnJvcjogb3Bjb2RlIG5v dCBzdXBwb3J0ZWQgb24gdGhpcyBwcm9jZXNzb3I6IFIzMDAwDQo+KE1JUFMxKSBgc2MgJDQsd2Fp dF9pbml0X2lkbGUoJDMpJw0KPntzdGFuZGFyZCBpbnB1dH06MzQwNzogRXJyb3I6IG9wY29kZSBu b3Qgc3VwcG9ydGVkIG9uIHRoaXMgcHJvY2Vzc29yOiBSMzAwMA0KPihNSVBTMSkgYGxsICQ0LDAo JDIpJw0KPntzdGFuZGFyZCBpbnB1dH06MzQwOTogRXJyb3I6IG9wY29kZSBub3Qgc3VwcG9ydGVk IG9uIHRoaXMgcHJvY2Vzc29yOiBSMzAwMA0KPihNSVBTMSkgYHNjICQ0LDAoJDIpJw0KPm1ha2Vb M106ICoqKiBbc2NoZWQub10gRXJyb3IgMQ0KPm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAv dXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40Lngva2VybmVsJw0KPm1ha2VbMl06ICoqKiBb Zmlyc3RfcnVsZV0gRXJyb3IgMg0KPm1ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3Ny Yy91Q2xpbnV4LWRpc3QvbGludXgtMi40Lngva2VybmVsJw0KPm1ha2VbMV06ICoqKiBbX2Rpcl9r ZXJuZWxdIEVycm9yIDINCj5tYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNs aW51eC1kaXN0L2xpbnV4LTIuNC54Jw0KPm1ha2U6ICoqKiBbbGludXhdIEVycm9yIDENCj4NCj4g ICAgIGluIHRoZSAidUNsaW51eC1kaXN0XGxpbnV4Mi40LnhcTWFrZWZpbGUiICxpIGFkZGVkICBh IGxpbmUgOiBDUk9TUy1DT01QSUxFPW1pcHNlbC1saW51eC1nY2MNCj4JCQkJCQkJCQkJCQkJCQkJ CSBBUkNIID0gbWlwcw0KPg0KPiAJDQogIGlzIHRoZXJlIGFueW9uZSBjYW4gaGVscCBtZSA/DQoN Cg0KoaGhoaGhoaGhoaGhoaGhoXh1aGFveg0KoaGhoaGhoaGhoaGhoaGhoXh1aGFvekBuZW9uZXRl Y2guY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDQtMDctMzANCg== From macro@linux-mips.org Fri Jul 30 10:48:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Jul 2004 10:48:39 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:29967 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 30 Jul 2004 10:48:35 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 1051BE1CB5; Fri, 30 Jul 2004 11:48:31 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17811-05; Fri, 30 Jul 2004 11:48:30 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id DB497E1C94; Fri, 30 Jul 2004 11:48:30 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.12.11/8.11.4) with ESMTP id i6U9mbge008500; Fri, 30 Jul 2004 11:48:37 +0200 Date: Fri, 30 Jul 2004 11:48:31 +0200 (CEST) From: "Maciej W. Rozycki" To: Richard Sandiford Cc: greg.roelofs@philips.com, linux-mips@linux-mips.org Subject: Re: apparent math-emu hang on movf instruction In-Reply-To: <871xivuwjf.fsf@redhat.com> Message-ID: References: <876587uwud.fsf@redhat.com> <871xivuwjf.fsf@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 5570 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@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 29 Jul 2004, Richard Sandiford wrote: > Oops! Serves me right for dabbling in new code. Only the first > hunk is correct. Thanks Richard for working on this. I've verified your patch on my system and as it is obviously correct, I've applied it with a trivial formatting change to our CVS, both to the head and to the 2.4 branch; with appropriate literal name changes for the latter. Maciej From xuhaoz@neonetech.com Fri Jul 30 11:11:18 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Jul 2004 11:11:24 +0100 (BST) Received: from [IPv6:::ffff:211.155.249.251] ([IPv6:::ffff:211.155.249.251]:52689 "EHLO nnt.neonetech.com") by linux-mips.org with ESMTP id ; Fri, 30 Jul 2004 11:11:18 +0100 Received: from wbar1 ([221.219.32.2]) by nnt.neonetech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jul 2004 18:14:40 +0800 Date: Fri, 30 Jul 2004 18:11:18 +0800 From: "xuhaoz" To: "linux-mips" Subject: error on make X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Message-ID: X-OriginalArrivalTime: 30 Jul 2004 10:14:40.0671 (UTC) FILETIME=[06B30AF0:01C4761E] 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: 5571 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: xuhaoz@neonetech.com Precedence: bulk X-list: linux-mips aGVsbG86DQoJCXRoZXJlIGlzIGFuIGVycm9yIGNvbWVzIG91dCB3aGVuIGkgY29tcGlsZSB1Y2xp bnV4LCB3aXRoIHIzMDAwLCBtaXBzMQ0KDQoNCg0KW3Jvb3RAeHVoYW96IHVDbGludXgtZGlzdF0j IG1ha2UNCm1ha2UgQVJDSD1taXBzIENST1NTX0NPTVBJTEU9bWlwc2VsLWxpbnV4LSAtQyBsaW51 eC0yLjQueCAgfHwgZXhpdCAxDQptYWtlWzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3Jj L3VDbGludXgtZGlzdC9saW51eC0yLjQueCcNCi4gc2NyaXB0cy9ta3ZlcnNpb24gPiAudG1wdmVy c2lvbg0KbWlwc2VsLWxpbnV4LWdjYyAtRF9fS0VSTkVMX18gLUkvdXNyL3NyYy91Q2xpbnV4LWRp c3QvbGludXgtMi40LngvaW5jbHVkZSAtV2FsbA0KLVdzdHJpY3QtcHJvdG90eXBlcyAtV25vLXRy aWdyYXBocyAtbWlwczIgLU8wIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1mbm8tY29tbW9uIC1mb21p dC1mcmFtZS1wb2ludGVyIC1JIC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9pbmNs dWRlL2FzbS9nY2MgLUcgMCAtbW5vLWFiaWNhbGxzIC1mbm8tcGljIC1waXBlICAgLURVVFNfTUFD SElORT0nIm1pcHMiJyAtREtCVUlMRF9CQVNFTkFNRT12ZXJzaW9uIC1jIC1vIGluaXQvdmVyc2lv bi5vIGluaXQvdmVyc2lvbi5jDQptYWtlIENGTEFHUz0iLURfX0tFUk5FTF9fIC1JL3Vzci9zcmMv dUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2luY2x1ZGUgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl cyAtV25vLXRyaWdyYXBocyAtbWlwczIgLU8wIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1mbm8tY29t bW9uIC1mb21pdC1mcmFtZS1wb2ludGVyIC1JIC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0y LjQueC9pbmNsdWRlL2FzbS9nY2MgLUcgMCAtbW5vLWFiaWNhbGxzIC1mbm8tcGljIC1waXBlICAi IC1DICBhcmNoL21pcHMvdG9vbHMNCm1ha2VbMl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9z cmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2FyY2gvbWlwcy90b29scycNCmNtcCAtcyBvZmZz ZXQuaCAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvaW5jbHVkZS9hc20tbWlwcy9v ZmZzZXQuaCB8fCAoY3Agb2Zmc2V0LmggL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54 L2luY2x1ZGUvYXNtLW1pcHMvb2Zmc2V0LmgubmV3ICYmIG12IC91c3Ivc3JjL3VDbGludXgtZGlz dC9saW51eC0yLjQueC9pbmNsdWRlL2FzbS1taXBzL29mZnNldC5oLm5ldyAvdXNyL3NyYy91Q2xp bnV4LWRpc3QvbGludXgtMi40LngvaW5jbHVkZS9hc20tbWlwcy9vZmZzZXQuaCkNCm1ha2VbMl06 IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvYXJj aC9taXBzL3Rvb2xzJw0KbWFrZSBDRkxBR1M9Ii1EX19LRVJORUxfXyAtSS91c3Ivc3JjL3VDbGlu dXgtZGlzdC9saW51eC0yLjQueC9pbmNsdWRlIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdu by10cmlncmFwaHMgLW1pcHMyIC1PMCAtZm5vLXN0cmljdC1hbGlhc2luZyAtZm5vLWNvbW1vbiAt Zm9taXQtZnJhbWUtcG9pbnRlciAtSSAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40Lngv aW5jbHVkZS9hc20vZ2NjIC1HIDAgLW1uby1hYmljYWxscyAtZm5vLXBpYyAtcGlwZSAgIiAtQyAg a2VybmVsDQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlz dC9saW51eC0yLjQueC9rZXJuZWwnDQptYWtlIGFsbF90YXJnZXRzDQptYWtlWzNdOiBFbnRlcmlu ZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9rZXJuZWwnDQpt YWtlWzNdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGxfdGFyZ2V0cycuDQptYWtlWzNdOiBM ZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2tlcm5l bCcNCm1ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGlu dXgtMi40Lngva2VybmVsJw0KbWFrZSBDRkxBR1M9Ii1EX19LRVJORUxfXyAtSS91c3Ivc3JjL3VD bGludXgtZGlzdC9saW51eC0yLjQueC9pbmNsdWRlIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg LVduby10cmlncmFwaHMgLW1pcHMyIC1PMCAtZm5vLXN0cmljdC1hbGlhc2luZyAtZm5vLWNvbW1v biAtZm9taXQtZnJhbWUtcG9pbnRlciAtSSAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40 LngvaW5jbHVkZS9hc20vZ2NjIC1HIDAgLW1uby1hYmljYWxscyAtZm5vLXBpYyAtcGlwZSAgIiAt QyAgZHJpdmVycw0KbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4 LWRpc3QvbGludXgtMi40LngvZHJpdmVycycNCm1ha2UgLUMgYmxvY2sNCm1ha2VbM106IEVudGVy aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMv YmxvY2snDQptYWtlIGFsbF90YXJnZXRzDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91 c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2ZXJzL2Jsb2NrJw0KbWFrZVs0XTog Tm90aGluZyB0byBiZSBkb25lIGZvciBgYWxsX3RhcmdldHMnLg0KbWFrZVs0XTogTGVhdmluZyBk aXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2ZXJzL2Jsb2Nr Jw0KbWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51 eC0yLjQueC9kcml2ZXJzL2Jsb2NrJw0KbWFrZSAtQyBjZHJvbQ0KbWFrZVszXTogRW50ZXJpbmcg ZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZHJpdmVycy9jZHJv bScNCm1ha2UgYWxsX3RhcmdldHMNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9z cmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvY2Ryb20nDQptYWtlWzRdOiBOb3Ro aW5nIHRvIGJlIGRvbmUgZm9yIGBhbGxfdGFyZ2V0cycuDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVj dG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvY2Ryb20nDQpt YWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIu NC54L2RyaXZlcnMvY2Ryb20nDQptYWtlIC1DIGNoYXINCm1ha2VbM106IEVudGVyaW5nIGRpcmVj dG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvY2hhcicNCm1h a2UgYWxsX3RhcmdldHMNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNs aW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvY2hhcicNCm1ha2VbNF06IE5vdGhpbmcgdG8g YmUgZG9uZSBmb3IgYGFsbF90YXJnZXRzJy4NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAv dXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZHJpdmVycy9jaGFyJw0KbWFrZVszXTog TGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2 ZXJzL2NoYXInDQptYWtlIC1DIGhvdHBsdWcNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBg L3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvaG90cGx1ZycNCm1ha2Ug YWxsX3RhcmdldHMNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51 eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvaG90cGx1ZycNCm1ha2VbNF06IE5vdGhpbmcgdG8g YmUgZG9uZSBmb3IgYGFsbF90YXJnZXRzJy4NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAv dXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZHJpdmVycy9ob3RwbHVnJw0KbWFrZVsz XTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9k cml2ZXJzL2hvdHBsdWcnDQptYWtlIC1DIG1lZGlhDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3Rv cnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2ZXJzL21lZGlhJw0KbWFr ZSAtQyByYWRpbw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4 LWRpc3QvbGludXgtMi40LngvZHJpdmVycy9tZWRpYS9yYWRpbycNCm1ha2UgYWxsX3RhcmdldHMN Cm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4 LTIuNC54L2RyaXZlcnMvbWVkaWEvcmFkaW8nDQptYWtlWzVdOiBOb3RoaW5nIHRvIGJlIGRvbmUg Zm9yIGBhbGxfdGFyZ2V0cycuDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMv dUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvbWVkaWEvcmFkaW8nDQptYWtlWzRdOiBM ZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZl cnMvbWVkaWEvcmFkaW8nDQptYWtlIC1DIHZpZGVvDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3Rv cnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2ZXJzL21lZGlhL3ZpZGVv Jw0KbWFrZSBhbGxfdGFyZ2V0cw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3Ny Yy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZHJpdmVycy9tZWRpYS92aWRlbycNCm1ha2VbNV06 IE5vdGhpbmcgdG8gYmUgZG9uZSBmb3IgYGFsbF90YXJnZXRzJy4NCm1ha2VbNV06IExlYXZpbmcg ZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZHJpdmVycy9tZWRp YS92aWRlbycNCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRp c3QvbGludXgtMi40LngvZHJpdmVycy9tZWRpYS92aWRlbycNCm1ha2UgYWxsX3RhcmdldHMNCm1h a2VbNF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIu NC54L2RyaXZlcnMvbWVkaWEnDQptYWtlWzRdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGxf dGFyZ2V0cycuDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1k aXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvbWVkaWEnDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9y eSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvbWVkaWEnDQptYWtl IC1DIG1pc2MNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1k aXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvbWlzYycNCm1ha2UgYWxsX3RhcmdldHMNCm1ha2VbNF06 IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2Ry aXZlcnMvbWlzYycNCm1ha2VbNF06IE5vdGhpbmcgdG8gYmUgZG9uZSBmb3IgYGFsbF90YXJnZXRz Jy4NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGlu dXgtMi40LngvZHJpdmVycy9taXNjJw0KbWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Iv c3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2ZXJzL21pc2MnDQptYWtlIC1DIG5ldA0K bWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgt Mi40LngvZHJpdmVycy9uZXQnDQptYWtlIGFsbF90YXJnZXRzDQptYWtlWzRdOiBFbnRlcmluZyBk aXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2ZXJzL25ldCcN Cm1ha2VbNF06IE5vdGhpbmcgdG8gYmUgZG9uZSBmb3IgYGFsbF90YXJnZXRzJy4NCm1ha2VbNF06 IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZHJp dmVycy9uZXQnDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1k aXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvbmV0Jw0KbWFrZSAtQyBwYXJwb3J0DQptYWtlWzNdOiBF bnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2 ZXJzL3BhcnBvcnQnDQptYWtlIGFsbF90YXJnZXRzDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3Rv cnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9kcml2ZXJzL3BhcnBvcnQnDQpt YWtlWzRdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGxfdGFyZ2V0cycuDQptYWtlWzRdOiBM ZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZl cnMvcGFycG9ydCcNCm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4 LWRpc3QvbGludXgtMi40LngvZHJpdmVycy9wYXJwb3J0Jw0KbWFrZSAtQyBzb3VuZA0KbWFrZVsz XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40Lngv ZHJpdmVycy9zb3VuZCcNCm1ha2UgYWxsX3RhcmdldHMNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVj dG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvc291bmQnDQpt YWtlWzRdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGxfdGFyZ2V0cycuDQptYWtlWzRdOiBM ZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2RyaXZl cnMvc291bmQnDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1k aXN0L2xpbnV4LTIuNC54L2RyaXZlcnMvc291bmQnDQptYWtlIGFsbF90YXJnZXRzDQptYWtlWzNd OiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9k cml2ZXJzJw0KbWFrZVszXTogTm90aGluZyB0byBiZSBkb25lIGZvciBgYWxsX3RhcmdldHMnLg0K bWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0y LjQueC9kcml2ZXJzJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGlu dXgtZGlzdC9saW51eC0yLjQueC9kcml2ZXJzJw0KbWFrZSBDRkxBR1M9Ii1EX19LRVJORUxfXyAt SS91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9pbmNsdWRlIC1XYWxsIC1Xc3RyaWN0 LXByb3RvdHlwZXMgLVduby10cmlncmFwaHMgLW1pcHMyIC1PMCAtZm5vLXN0cmljdC1hbGlhc2lu ZyAtZm5vLWNvbW1vbiAtZm9taXQtZnJhbWUtcG9pbnRlciAtSSAvdXNyL3NyYy91Q2xpbnV4LWRp c3QvbGludXgtMi40LngvaW5jbHVkZS9hc20vZ2NjIC1HIDAgLW1uby1hYmljYWxscyAtZm5vLXBp YyAtcGlwZSAgIiAtQyAgbW0NCm1ha2VbMl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMv dUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L21tJw0KbWFrZSBhbGxfdGFyZ2V0cw0KbWFrZVszXTog RW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvbW0n DQptYWtlWzNdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGxfdGFyZ2V0cycuDQptYWtlWzNd OiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L21t Jw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51 eC0yLjQueC9tbScNCm1ha2UgQ0ZMQUdTPSItRF9fS0VSTkVMX18gLUkvdXNyL3NyYy91Q2xpbnV4 LWRpc3QvbGludXgtMi40LngvaW5jbHVkZSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1Xbm8t dHJpZ3JhcGhzIC1taXBzMiAtTzAgLWZuby1zdHJpY3QtYWxpYXNpbmcgLWZuby1jb21tb24gLWZv bWl0LWZyYW1lLXBvaW50ZXIgLUkgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2lu Y2x1ZGUvYXNtL2djYyAtRyAwIC1tbm8tYWJpY2FsbHMgLWZuby1waWMgLXBpcGUgICIgLUMgIGZz DQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51 eC0yLjQueC9mcycNCm1ha2UgLUMgY3JhbWZzDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3Rvcnkg YC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9mcy9jcmFtZnMnDQptYWtlIGFsbF90 YXJnZXRzDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlz dC9saW51eC0yLjQueC9mcy9jcmFtZnMnDQptYWtlWzRdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9y IGBhbGxfdGFyZ2V0cycuDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNs aW51eC1kaXN0L2xpbnV4LTIuNC54L2ZzL2NyYW1mcycNCm1ha2VbM106IExlYXZpbmcgZGlyZWN0 b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZnMvY3JhbWZzJw0KbWFrZSAt QyBkZXZmcw0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRp c3QvbGludXgtMi40LngvZnMvZGV2ZnMnDQptYWtlIGFsbF90YXJnZXRzDQptYWtlWzRdOiBFbnRl cmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9mcy9kZXZm cycNCm1ha2VbNF06IE5vdGhpbmcgdG8gYmUgZG9uZSBmb3IgYGFsbF90YXJnZXRzJy4NCm1ha2Vb NF06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40Lngv ZnMvZGV2ZnMnDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1k aXN0L2xpbnV4LTIuNC54L2ZzL2RldmZzJw0KbWFrZSAtQyBkZXZwdHMNCm1ha2VbM106IEVudGVy aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2ZzL2RldnB0 cycNCm1ha2UgYWxsX3RhcmdldHMNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9z cmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2ZzL2RldnB0cycNCm1ha2VbNF06IE5vdGhpbmcg dG8gYmUgZG9uZSBmb3IgYGFsbF90YXJnZXRzJy4NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5 IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZnMvZGV2cHRzJw0KbWFrZVszXTog TGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9mcy9k ZXZwdHMnDQptYWtlIC1DIGV4dDINCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9z cmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2ZzL2V4dDInDQptYWtlIGFsbF90YXJnZXRzDQpt YWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0y LjQueC9mcy9leHQyJw0KbWFrZVs0XTogTm90aGluZyB0byBiZSBkb25lIGZvciBgYWxsX3Rhcmdl dHMnLg0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9s aW51eC0yLjQueC9mcy9leHQyJw0KbWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3Jj L3VDbGludXgtZGlzdC9saW51eC0yLjQueC9mcy9leHQyJw0KbWFrZSAtQyBtaW5peA0KbWFrZVsz XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40Lngv ZnMvbWluaXgnDQptYWtlIGFsbF90YXJnZXRzDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3Rvcnkg YC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9mcy9taW5peCcNCm1ha2VbNF06IE5v dGhpbmcgdG8gYmUgZG9uZSBmb3IgYGFsbF90YXJnZXRzJy4NCm1ha2VbNF06IExlYXZpbmcgZGly ZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZnMvbWluaXgnDQptYWtl WzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54 L2ZzL21pbml4Jw0KbWFrZSAtQyBwYXJ0aXRpb25zDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3Rv cnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9mcy9wYXJ0aXRpb25zJw0KbWFr ZSBhbGxfdGFyZ2V0cw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xp bnV4LWRpc3QvbGludXgtMi40LngvZnMvcGFydGl0aW9ucycNCm1ha2VbNF06IE5vdGhpbmcgdG8g YmUgZG9uZSBmb3IgYGFsbF90YXJnZXRzJy4NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAv dXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZnMvcGFydGl0aW9ucycNCm1ha2VbM106 IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZnMv cGFydGl0aW9ucycNCm1ha2UgLUMgcHJvYw0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAv dXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZnMvcHJvYycNCm1ha2UgYWxsX3Rhcmdl dHMNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xp bnV4LTIuNC54L2ZzL3Byb2MnDQptYWtlWzRdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGxf dGFyZ2V0cycuDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1k aXN0L2xpbnV4LTIuNC54L2ZzL3Byb2MnDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vz ci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2ZzL3Byb2MnDQptYWtlIC1DIHJhbWZzDQpt YWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0y LjQueC9mcy9yYW1mcycNCm1ha2UgYWxsX3RhcmdldHMNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVj dG9yeSBgL3Vzci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2ZzL3JhbWZzJw0KbWFrZVs0 XTogTm90aGluZyB0byBiZSBkb25lIGZvciBgYWxsX3RhcmdldHMnLg0KbWFrZVs0XTogTGVhdmlu ZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9mcy9yYW1mcycN Cm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgt Mi40LngvZnMvcmFtZnMnDQptYWtlIC1DIHJvbWZzDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3Rv cnkgYC91c3Ivc3JjL3VDbGludXgtZGlzdC9saW51eC0yLjQueC9mcy9yb21mcycNCm1ha2UgYWxs X3RhcmdldHMNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9zcmMvdUNsaW51eC1k aXN0L2xpbnV4LTIuNC54L2ZzL3JvbWZzJw0KbWFrZVs0XTogTm90aGluZyB0byBiZSBkb25lIGZv ciBgYWxsX3RhcmdldHMnLg0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VD bGludXgtZGlzdC9saW51eC0yLjQueC9mcy9yb21mcycNCm1ha2VbM106IExlYXZpbmcgZGlyZWN0 b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZnMvcm9tZnMnDQptYWtlIGFs bF90YXJnZXRzDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91c3Ivc3JjL3VDbGludXgt ZGlzdC9saW51eC0yLjQueC9mcycNCm1pcHNlbC1saW51eC1nY2MgLURfX0tFUk5FTF9fIC1JL3Vz ci9zcmMvdUNsaW51eC1kaXN0L2xpbnV4LTIuNC54L2luY2x1ZGUgLVdhbGwNCi1Xc3RyaWN0LXBy b3RvdHlwZXMgLVduby10cmlncmFwaHMgLW1pcHMyIC1PMCAtZm5vLXN0cmljdC1hbGlhc2luZyAt Zm5vLWNvbW1vbiAtZm9taXQtZnJhbWUtcG9pbnRlciAtSSAvdXNyL3NyYy91Q2xpbnV4LWRpc3Qv bGludXgtMi40LngvaW5jbHVkZS9hc20vZ2NjIC1HIDAgLW1uby1hYmljYWxscyAtZm5vLXBpYyAt cGlwZSAgICAtbm9zdGRpbmMgLWl3aXRocHJlZml4IGluY2x1ZGUgLURLQlVJTERfQkFTRU5BTUU9 c3RhdCAgLWMgLW8gc3RhdC5vIHN0YXQuYw0Kc3RhdC5jOjM1OiB3YXJuaW5nOiBgc3RydWN0IF9f b2xkX2tlcm5lbF9zdGF0JyBkZWNsYXJlZCBpbnNpZGUgcGFyYW1ldGVyIGxpc3QNCnN0YXQuYzoz NTogd2FybmluZzogaXRzIHNjb3BlIGlzIG9ubHkgdGhpcyBkZWZpbml0aW9uIG9yIGRlY2xhcmF0 aW9uLCB3aGljaCBpcyBwcm9iYWJseSBub3Qgd2hhdCB5b3Ugd2FudC4NCnN0YXQuYzogSW4gZnVu Y3Rpb24gYGNwX29sZF9zdGF0JzoNCnN0YXQuYzozODogc3RvcmFnZSBzaXplIG9mIGB0bXAnIGlz bid0IGtub3duDQpzdGF0LmM6NDA6IHNpemVvZiBhcHBsaWVkIHRvIGFuIGluY29tcGxldGUgdHlw ZQ0Kc3RhdC5jOjM4OiB3YXJuaW5nOiB1bnVzZWQgdmFyaWFibGUgYHRtcCcNCnN0YXQuYzogQXQg dG9wIGxldmVsOg0Kc3RhdC5jOjEzNzogd2FybmluZzogYHN0cnVjdCBfX29sZF9rZXJuZWxfc3Rh dCcgZGVjbGFyZWQgaW5zaWRlIHBhcmFtZXRlciBsaXN0DQpzdGF0LmM6IEluIGZ1bmN0aW9uIGBz eXNfc3RhdCc6DQpzdGF0LmM6MTQ2OiB3YXJuaW5nOiBwYXNzaW5nIGFyZyAyIG9mIGBjcF9vbGRf c3RhdCcgZnJvbSBpbmNvbXBhdGlibGUgcG9pbnRlciB0eXBlDQpzdGF0LmM6IEF0IHRvcCBsZXZl bDoNCnN0YXQuYzoxNzQ6IHdhcm5pbmc6IGBzdHJ1Y3QgX19vbGRfa2VybmVsX3N0YXQnIGRlY2xh cmVkIGluc2lkZSBwYXJhbWV0ZXIgbGlzdA0Kc3RhdC5jOiBJbiBmdW5jdGlvbiBgc3lzX2xzdGF0 JzoNCnN0YXQuYzoxODM6IHdhcm5pbmc6IHBhc3NpbmcgYXJnIDIgb2YgYGNwX29sZF9zdGF0JyBm cm9tIGluY29tcGF0aWJsZSBwb2ludGVyIHR5cGUNCnN0YXQuYzogQXQgdG9wIGxldmVsOg0Kc3Rh dC5jOjIxMjogd2FybmluZzogYHN0cnVjdCBfX29sZF9rZXJuZWxfc3RhdCcgZGVjbGFyZWQgaW5z aWRlIHBhcmFtZXRlciBsaXN0DQpzdGF0LmM6IEluIGZ1bmN0aW9uIGBzeXNfZnN0YXQnOg0Kc3Rh dC5jOjIyMzogd2FybmluZzogcGFzc2luZyBhcmcgMiBvZiBgY3Bfb2xkX3N0YXQnIGZyb20gaW5j b21wYXRpYmxlIHBvaW50ZXIgdHlwZQ0KbWFrZVszXTogKioqIFtzdGF0Lm9dIEVycm9yIDENCm1h a2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40 LngvZnMnDQptYWtlWzJdOiAqKiogW2ZpcnN0X3J1bGVdIEVycm9yIDINCm1ha2VbMl06IExlYXZp bmcgZGlyZWN0b3J5IGAvdXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngvZnMnDQptYWtl WzFdOiAqKiogW19kaXJfZnNdIEVycm9yIDINCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAv dXNyL3NyYy91Q2xpbnV4LWRpc3QvbGludXgtMi40LngnDQptYWtlOiAqKiogW2xpbnV4XSBFcnJv ciAxDQpbcm9vdEB4dWhhb3ogdUNsaW51eC1kaXN0XSMNCg0Kd2hvIGNhbiBoZWxwIG1lLCBhbmQg d2hlcmUgaXMgdGhlIGVycm9yIA0KDQqhoaGhoaGhoaGhoaGhoaGheHVoYW96DQqhoaGhoaGhoaGh oaGhoaGheHVoYW96QG5lb25ldGVjaC5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNC0wNy0z MA0K From delivery@hosyou-b.mine.nu Fri Jul 30 14:21:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Jul 2004 14:21:53 +0100 (BST) Received: from p3090-ipad69marunouchi.tokyo.ocn.ne.jp ([IPv6:::ffff:220.97.20.90]:20959 "EHLO hosyou-b.mine.nu") by linux-mips.org with ESMTP id ; Fri, 30 Jul 2004 14:21:48 +0100 Received: from hosyou-b.mine.nu (unknown [192.168.4.80]) by hosyou-b.mine.nu (Postfix) with ESMTP id AB52E794EC2 for ; Fri, 30 Jul 2004 22:21:46 +0900 (JST) Message-ID: <18326046.1091193706705.JavaMail.nobody@hosyou-b.mine.nu> Date: Fri, 30 Jul 2004 22:21:46 +0900 (JST) From: =?iso-2022-jp?Q?=1B=24B7P=3AQJ88K=25a=25k=25=5E=25=2CC4Ev=1B=28B?= To: linux-mips@linux-mips.org Subject: =?iso-2022-jp?Q?=1B$B"#G/<}#6@iK|1=5F0J2<$N8D=3FM=1B(B?= =?iso-2022-jp?Q?=1B$B$OL\E*#6@iK|0J>e%S%8%M%9=3DP=1B(B?= =?iso-2022-jp?Q?=1B$BMh$k"##52/#9@iK|1=5F<}F~$N=1B(B?= =?iso-2022-jp?Q?=1B$B>Z5r$G=3DPMh$k"#:=5FBp$G4JC1$K=1B(B?= =?iso-2022-jp?Q?=1B$B$G$-$k%S%C%/%S%8%M%9$NJ}=1B(B?= =?iso-2022-jp?Q?=1B$BK!"#7J5$$NGH$KJX>h$9$kJ}K!=1B(B?= =?iso-2022-jp?Q?=1B$B"##2#0:P0J>eCK=3Dw$O:=5FBp7P=1B(B?= =?iso-2022-jp?Q?=1B$B1D 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: 5572 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: delivery@hosyou-b.mine.nu Precedence: bulk X-list: linux-mips linux-mips@linux-mips.org$BMM!"(B $B!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!K\F|$N(B[$B$a!<$k$^$,$N(I@2DY(B]$B$O!]!Z=PMh$k!&$G$-$k!<#2#0:P0J>e$NCK=w$J$i=PMh$k![(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!:#$NG:$_$O!&!&!@iK|1_$G2r7h=PMh$k!*L\E*$K$b;HMQ=PMh$k!*@83h8~>e=PMh$k(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!>-Mh$NIT0B$O!&!&!@iK|1_Cy6b$G0B?4=PMh$k!*0B?48~>e$N:`NA$O;q6b$G=PMh$k!*(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=PMh$k$NJ}K!$OM-$j$^$9!Z5rM-<}F~%S%8%M%9!U7P1DeCK=w?=$79~$_=PMh$^$9!#(B $B!!!!!!I{6H!&7s6H!&EZF|7P1D2K3hMQ7P1D$NJ}!9$KBg9%I>!*(B $B!!!!!!!!(B $B!!!!!!!!#3#8G/$N\$7$/$O(B http://newjapan.orgdns.org/$B!!(B $B!!(B $B!!(B $B2?;v$bO@$h$j>Z5r!&1=$h$j>Z5r!&>u67>Z5r$h$jJ*E*>Z5r!&:[H=41$HF1$8J*E*>Z5r$N$_$G;vEPO?$G%]%8%7%g%s$r3NJ]$7$F!"$=$N$"$H$f(B $B!!$C$/$j8!F$$7$F$/$@$5$l$P7k9=$G$9!#(B $B!!>&IJ!"%7%9%F%`%W%i%s$H5.J}$K$H$C$FM-Mx$JJ*$P$+$j$G$9!#!!5^$$$G!"$43NG'2<$5$$!*$3$A$i$h$j!!(B $B!!(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(Bhttp://fortuna.love-jpn.com/index.cgi?id=world $B"!(,(,(,!N#P#R!O(,(,(,(,"(F/$/%^%^$N!*;d$K$b=PMh$k;v!*(,(,(,(,(,"(;22C\:Y$O3Z$7$$#M#L$K$F!&!&(B http://stage-one.jp/jc/myao $B"!(,(,(,!N#P#R!O(,(,(,"(!!&IJ!&7r9/?)IJ$J$I$NK-IY$J>&IJB7(B $B$$!#(B $B"#$7$+$bDc2A3J$J$N$GC/$G$b5$7Z$K%S%8%M%9$K;22C$G$-$^$9!#%/%j%C%/"M(B http://tekipaki.jp/~mk/personal/002497.html $B!z(B--$B!~(B--$B!z(B--$B"!(B--$B!z(B--$B!~(B--$B!z(B $B!y(B $B!z(B--$B!~(B--$B!z(B--$B"!(B--$B!z(B--$B!~(B--$B!z!z(B--$B!~(B--$B!z(B-$B"!(B--$B!z(B-$B!~(B-$B!z(B $B!y(B $B!z(B--$B!~(B--$B!z(B--$B"!(B--$B!z(B--$B!~(B--$B!z(B $B!!!!!!!!!!!!!}!!K\F|$bEj9F!*$"$j$,$H$&$4$6$$$^$7$?"v!}%a%k%^%,H/9TpJspJs$K4X$7$FH/9T5$/$@$5$$!#7G:\5-;v$K4X$9$k$*Ld$$9g$o$;$OD>@\Ej9Fl9g$O5$/$@$5$$!#(B $B!!!!!!!!!!!!$^$?9-9pFbMF$K$h$C$F$O!!7G:\$r95$($5$;$F$$$?$@$/>l9g$b$4$6$$$^$9!#(B $B!!!!!!!!!!!!9-9p$r?=$79~$s$G$$$?$@$$$?J}$K$O!"%a!<%k%^%,%8%s$rG[?.$5$;$F$$$?$@$-$^$9!#(B $B!!!!!!!!!!!!$4N;>5$N>e!!$*?=$79~$_$/$@$5$$!#(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(Bhttp://gogoway.orgdns.org/doc/honmousikomi.htm $B!!!!!!!!!!!!!!!!!!!!(B---------------------------------------------------------- $B!!!!!!!!!!!!!!!!!!!!!!%a!<%k%^%,%8%s!!9-9pC4EvLpBt!!!!(Bhttp://gogoway.orgdns.org/ $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $B!!!!!!!!(B ------------------------------------------- 7$B7n(B30$BF|(B17$B;~H/I=(B $B8E20(B $B1+(B $B1+(B $B?73c(B $B@2$l(B $B@2$l(B $B6bBt(B $B@2$l;~!9F^$j(B $BF^$j0l;~1+(B $BBg:e(B $BF^$j0l;~1+(B $BF^$j0l;~1+(B $B2,;3(B $B@2$l$N$A;~!9F^$j(B $B1+(B $B9-Eg(B $B@2$l;~!9F^$j(B $B1+(B $B9b>>(B $BF^$j$N$A0l;~1+(B $B1+(B $BJ!2,(B $B@2$l(B $B@2$l$N$A0l;~1+(B $B; Fri, 30 Jul 2004 22:08:46 +0100 Message-ID: <20040730210639.81429.qmail@web50801.mail.yahoo.com> Received: from [65.204.143.11] by web50801.mail.yahoo.com via HTTP; Fri, 30 Jul 2004 14:06:39 PDT Date: Fri, 30 Jul 2004 14:06:39 -0700 (PDT) From: G H Subject: Re: Strange, strange occurence To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1227787752-1091221599=:78382" 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: 5573 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: giles67@yahoo.com Precedence: bulk X-list: linux-mips --0-1227787752-1091221599=:78382 Content-Type: text/plain; charset=us-ascii Is the suggested patch below going to be added to CVS or is considered too experimental to add ? >No and yes - but here is a simpler solution. Below patch solves the >problem and adds just 32 bytes of code but removes the special case for >TX49/H2 entirely. > Ralf > arch/mips/mm/c-r4k.c | 59 >-------------------------------------------- include/asm-mips/r4kcache.h | 18 >++++++++----- > include/asm-mips/war.h | 14 ---------- > 3 files changed, 13 insertions(+), 78 deletions(-) > > >Index: arch/mips/mm/c-r4k.c >=================================================================== >RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v >retrieving revision 1.88 >diff -u -r1.88 c-r4k.c >--- arch/mips/mm/c-r4k.c 16 Jul 2004 12:06:13 -0000 1.88 >+++ arch/mips/mm/c-r4k.c 16 Jul 2004 12:17:05 -0000 >@@ -96,16 +96,6 @@ > r4k_blast_dcache = blast_dcache32; > } __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1227787752-1091221599=:78382 Content-Type: text/html; charset=us-ascii
Is the suggested patch below going to be added to CVS or is considered too experimental to add ?
 
>No and yes - but here is a simpler solution.  Below patch solves the
>problem and adds just 32 bytes of code but removes the special case for
>TX49/H2 entirely.

>  Ralf

> arch/mips/mm/c-r4k.c        |   59
>-------------------------------------------- include/asm-mips/r4kcache.h |   18
>++++++++-----
> include/asm-mips/war.h      |   14 ----------
> 3 files changed, 13 insertions(+), 78 deletions(-)
>
>
>Index: arch/mips/mm/c-r4k.c
>===================================================================
>RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
>retrieving revision 1.88
>diff -u -r1.88 c-r4k.c
>--- arch/mips/mm/c-r4k.c        16 Jul 2004 12:06:13 -0000      1.88
>+++ arch/mips/mm/c-r4k.c        16 Jul 2004 12:17:05 -0000
>@@ -96,16 +96,6 @@
>                r4k_blast_dcache = blast_dcache32;
> }

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-1227787752-1091221599=:78382-- From ralf@linux-mips.org Sat Jul 31 06:09:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 31 Jul 2004 06:09:09 +0100 (BST) Received: from p508B7951.dip.t-dialin.net ([IPv6:::ffff:80.139.121.81]:37669 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 31 Jul 2004 06:09:04 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6V593Yn014903; Sat, 31 Jul 2004 07:09:03 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6V593Pt014902; Sat, 31 Jul 2004 07:09:03 +0200 Date: Sat, 31 Jul 2004 07:09:03 +0200 From: Ralf Baechle To: G H Cc: linux-mips@linux-mips.org Subject: Re: Strange, strange occurence Message-ID: <20040731050903.GB14243@linux-mips.org> References: <20040730210639.81429.qmail@web50801.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040730210639.81429.qmail@web50801.mail.yahoo.com> User-Agent: Mutt/1.4.1i 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: 5574 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, Jul 30, 2004 at 02:06:39PM -0700, G H wrote: > Is the suggested patch below going to be added to CVS or is considered too experimental to add ? No, that patch is simply wrong. I'll implement a new one but being on a trip through the Silicon Valley right now that's a little hard to do from here. Ralf From ralf@linux-mips.org Sat Jul 31 10:25:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 31 Jul 2004 10:25:24 +0100 (BST) Received: from p508B7AA1.dip.t-dialin.net ([IPv6:::ffff:80.139.122.161]:59699 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 31 Jul 2004 10:25:20 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i6V9PEjV019812; Sat, 31 Jul 2004 11:25:14 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i6V9P5JG019810; Sat, 31 Jul 2004 11:25:05 +0200 Date: Sat, 31 Jul 2004 11:25:05 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH] vr41xx: remove obsolete flag Message-ID: <20040731092505.GA19775@linux-mips.org> References: <20040730010112.3b54404b.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040730010112.3b54404b.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.1i 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: 5575 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, Jul 30, 2004 at 01:01:12AM +0900, Yoichi Yuasa wrote: > This patch removes an obsolete flag in serial driver. > > Please apply this patch to v2.6 CVS tree. Applied, Ralf From xuhaoz@neonetech.com Sat Jul 31 14:39:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 31 Jul 2004 14:39:35 +0100 (BST) Received: from [IPv6:::ffff:211.155.249.251] ([IPv6:::ffff:211.155.249.251]:51757 "EHLO nnt.neonetech.com") by linux-mips.org with ESMTP id ; Sat, 31 Jul 2004 14:39:31 +0100 Received: from xuhaoz ([211.136.74.1]) by nnt.neonetech.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jul 2004 21:42:50 +0800 From: "xuhaoz" To: Subject: about platform Date: Sat, 31 Jul 2004 21:37:34 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 31 Jul 2004 13:42:53.0750 (UTC) FILETIME=[47915D60:01C47704] 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: 5576 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: xuhaoz@neonetech.com Precedence: bulk X-list: linux-mips hello: can uclinux run on the mipsR3000 ?, _________________________________________ zhang xuhao ICQ#: 116926669 More ways to contact me: http://wwp.icq.com/116926669 _________________________________________