From jbglaw@dvmwest.gt.owl.de Sun Feb 1 00:52:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 00:52:21 +0000 (GMT) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:58833 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 00:52:20 +0000 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 860714B4F3; Sun, 1 Feb 2004 01:52:18 +0100 (CET) Date: Sun, 1 Feb 2004 01:52:18 +0100 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Warning while building current 2.6.x CVS Message-ID: <20040201005218.GM20536@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/hP/389S7qb5BOej" Content-Disposition: inline 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.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4213 X-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 --/hP/389S7qb5BOej Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I get a warning while compiling current CVS (end of non-void function). This patch would fix it... MfG, JBG Index: arch/mips/lib-32/dump_tlb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ftp/pub/mirror/CVS/ftp.linux-mips.org/linux/arch/mips/lib-3= 2/dump_tlb.c,v retrieving revision 1.2 diff -u -r1.2 dump_tlb.c --- arch/mips/lib-32/dump_tlb.c 18 Dec 2003 21:52:33 -0000 1.2 +++ arch/mips/lib-32/dump_tlb.c 1 Feb 2004 00:46:22 -0000 @@ -31,6 +31,7 @@ case PM_64M: return "64Mb"; case PM_256M: return "256Mb"; #endif + default: return "unknown"; } } =20 --=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)); --/hP/389S7qb5BOej Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAHE3CHb1edYOZ4bsRAs7VAJ9oluiTDgbxUpIIUpP/LYcE34hY9gCfVIxh /yg/IEQO5SSlSjRaLrf10FU= =su70 -----END PGP SIGNATURE----- --/hP/389S7qb5BOej-- From ralf@linux-mips.org Sun Feb 1 04:53:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 04:53:00 +0000 (GMT) Received: from p508B577C.dip.t-dialin.net ([IPv6:::ffff:80.139.87.124]:5416 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 04:53:00 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i114qwex005567 for ; Sun, 1 Feb 2004 05:52:59 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i114qw18005566 for linux-mips@linux-mips.org; Sun, 1 Feb 2004 05:52:58 +0100 Date: Sun, 1 Feb 2004 05:52:58 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: R4600 V1.7 errata Message-ID: <20040201045258.GA4601@linux-mips.org> References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040131141027.GA11048@ballina> 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: 4214 X-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 Sat, Jan 31, 2004 at 03:10:27PM +0100, Jorik Jonker wrote: > > On Sat, Jan 31, 2004 at 04:04:35AM +0100, Ralf Baechle wrote: > > Over the past days a few fixes went into CVS, the last only a few minutes > > ago. Can you retry and let me know? > > Well, it a little 'better'. It now hangs while configurating the network > device, while in earlier versions the freeze appeared while calibrating the > delay loop, or mounting the root fs. > Is there something else I could try? > Until I know what's going on, I am going to look for a kernel with proper > VINO support which is 'old' enough to run without the freeze.. Seems I lost the R4600 V1.7 errata documents I used to have so all information that is left to me is what's documented in the Linux code. I've removed all the mentioned instructions and the kernel which otherwise is running fine on R5000 systems or R4600 V2.0 keeps crashing. I suspect I'm becoming victim of some of the other of the chip's errata; it has at least 18 ... Anybody still got errata information for the R4600 V1.7 around? Ralf From geert@linux-m68k.org Sun Feb 1 11:08:03 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 11:08:03 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:36569 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 11:08:02 +0000 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i11B7xw2001109 for ; Sun, 1 Feb 2004 12:07:59 +0100 (MET) Date: Sun, 1 Feb 2004 12:07:58 +0100 (MET) From: Geert Uytterhoeven To: Linux/MIPS Development Subject: Re: [CFP] 2nd EMBEDDED SYSTEMS and OPERATING SYSTEMS track at FOSDEM 2004 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: 4215 X-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 The full program of the Embedded Systems and Operating Systems track at fosdem 2004 is now available (Brussels, 21 - 22 Feb 2004). http://www.embedded-kernel-track.org/program-2004.txt http://fosdem.org/2004/index/dev_room_embedded Saturday 21 Feb 2004 ==================== 13:00 --> 14:00 : (invited) Tom Rini: "Lessons learned: Embedded Linux Development" 14:00 --> 15:00 : (invited) Patrick Pelgrims: "Closed and Open Source CPU's for embedded systems" 15:00 --> 16:00 : (invited) Jiri Gaisler: "leon : an open source CPU core" 16:00 --> 17:00 : Panel Debate: GPL licensing in Embedded Systems (panelists TBD) Sunday 22 Feb 2004 ================== 10:30 --> 11:15 : David Glaude: "LCDproc, ready for the embedded market ?" 11:15 --> 12:00 : Benjamin Henrion: "Hacking Consumer Electronics with Free Software" 12:00 --> 13:00 : wookey: "YAFFS : a NAND Flash file system" 13:00 --> 14:00 : lunch 14:00 --> 15:00 : Matthew Allum: "X not on the Desktop" 15:00 --> 16:00 : Philippe De Swert: "Using the Debian Tools and the Stag framework for embedded development" 16:00 --> 17:00 : Venkata Jagana: "Enabling the IBM Linux WristWatch as an embedded Mobile Node in IPv6 networks" 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 anemo@mba.ocn.ne.jp Sun Feb 1 11:24:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 11:24:28 +0000 (GMT) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:2277 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Sun, 1 Feb 2004 11:24:27 +0000 Received: from localhost (p5005-ipad32funabasi.chiba.ocn.ne.jp [221.189.137.5]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CA8926523; Sun, 1 Feb 2004 20:24:23 +0900 (JST) Date: Sun, 01 Feb 2004 20:30:05 +0900 (JST) Message-Id: <20040201.203005.74756858.anemo@mba.ocn.ne.jp> To: macro@ds2.pg.gda.pl Cc: jsun@mvista.com, linux-mips@linux-mips.org Subject: Re: [PATCH 2.6] enable genrtc for MIPS From: Atsushi Nemoto In-Reply-To: References: <20040130103913.E31937@mvista.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 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: 4216 X-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, 30 Jan 2004 20:13:38 +0100 (CET), "Maciej W. Rozycki" said: >> Of course, individual board is still free to choose the old rtc.c >> or implement some peculiar ones of its own - although I can't see >> why. :) macro> s/old/full-featured/ No, I suppose s/rtc/mips-rtc/ is what the original patch means. By the way, with this patch, individual board can not implement it's own genrtc routines. How about making gen_rtc_time, etc. pointer to functions to allow overrides? I think implementing rtc_get_time (mips specific) with get_rtc_time (genrtc) is more efficient than implementing get_rtc_time with rtc_get_time for most RTC chips. --- Atsushi Nemoto From geert@linux-m68k.org Sun Feb 1 12:04:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 12:04:02 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:35327 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 12:04:02 +0000 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i11C40w2005358; Sun, 1 Feb 2004 13:04:00 +0100 (MET) Date: Sun, 1 Feb 2004 13:04:00 +0100 (MET) From: Geert Uytterhoeven To: Atsushi Nemoto cc: "Maciej W. Rozycki" , jsun@mvista.com, Linux/MIPS Development Subject: Re: [PATCH 2.6] enable genrtc for MIPS In-Reply-To: <20040201.203005.74756858.anemo@mba.ocn.ne.jp> Message-ID: References: <20040130103913.E31937@mvista.com> <20040201.203005.74756858.anemo@mba.ocn.ne.jp> 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: 4217 X-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 Sun, 1 Feb 2004, Atsushi Nemoto wrote: > I think implementing rtc_get_time (mips specific) with get_rtc_time > (genrtc) is more efficient than implementing get_rtc_time with > rtc_get_time for most RTC chips. Indeed, that's what I noticed a while ago, too. 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 yuasa@hh.iij4u.or.jp Sun Feb 1 12:58:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 12:58:37 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:24279 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 12:58:36 +0000 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 VAA18548; Sun, 1 Feb 2004 21:58:30 +0900 (JST) Received: 4UMDO00 id i11CwU119511; Sun, 1 Feb 2004 21:58:30 +0900 (JST) Received: 4UMRO00 id i11CwSX01588; Sun, 1 Feb 2004 21:58:29 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Sun, 1 Feb 2004 21:58:08 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] Moved timer setup to common part for vr41xx Message-Id: <20040201215808.69e35cc9.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4218 X-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 Hello Ralf, I made a patch for timer of vr41xx. This patch get together setup of dispersed timer to one place. Please apply to v2.6. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c --- linux-orig/arch/mips/vr41xx/casio-e55/setup.c Sat Jan 31 23:11:48 2004 +++ linux/arch/mips/vr41xx/casio-e55/setup.c Sat Jan 31 22:53:18 2004 @@ -24,7 +24,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -46,14 +45,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/rtc.c linux/arch/mips/vr41xx/common/rtc.c --- linux-orig/arch/mips/vr41xx/common/rtc.c Tue Jan 13 08:21:05 2004 +++ linux/arch/mips/vr41xx/common/rtc.c Sat Jan 31 22:51:47 2004 @@ -259,7 +259,7 @@ epoch_time = time; } -void __init vr41xx_time_init(void) +static void __init vr41xx_time_init(void) { switch (current_cpu_data.cputype) { case CPU_VR4111: @@ -291,7 +291,7 @@ rtc_set_time = vr41xx_set_time; } -void __init vr41xx_timer_setup(struct irqaction *irq) +static void __init vr41xx_timer_setup(struct irqaction *irq) { do_gettimeoffset = vr41xx_gettimeoffset; @@ -308,4 +308,10 @@ write_rtc2(ELAPSEDTIME_INT, RTCINTREG); setup_irq(ELAPSEDTIME_IRQ, irq); +} + +void __init vr41xx_rtc_init(void) +{ + board_time_init = vr41xx_time_init; + board_timer_setup = vr41xx_timer_setup; } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c --- linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c Sat Jan 31 23:11:48 2004 +++ linux/arch/mips/vr41xx/ibm-workpad/setup.c Sat Jan 31 22:54:11 2004 @@ -24,7 +24,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -46,14 +45,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Sat Jan 31 23:11:48 2004 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Sat Jan 31 22:51:47 2004 @@ -38,7 +38,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -113,9 +112,6 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - board_irq_init = eagle_irq_init; vr41xx_bcu_init(); @@ -123,6 +119,8 @@ vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_dsiu_init(); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c Sat Jan 31 23:11:48 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c Sat Jan 31 22:55:24 2004 @@ -22,7 +22,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -92,14 +91,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c Sat Jan 31 23:11:48 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c Sat Jan 31 22:56:19 2004 @@ -28,7 +28,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -97,14 +96,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); vr41xx_siu_init(SIU_RS232C, 0); vr41xx_dsiu_init(); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c Sat Jan 31 23:11:48 2004 +++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c Sat Jan 31 22:57:09 2004 @@ -25,7 +25,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -95,14 +94,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c --- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c Sat Jan 31 23:11:49 2004 +++ linux/arch/mips/vr41xx/zao-capcella/setup.c Sat Jan 31 22:58:36 2004 @@ -25,7 +25,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -95,14 +94,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Sat Jan 31 23:11:49 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Sat Jan 31 22:51:47 2004 @@ -150,6 +150,8 @@ extern void vr41xx_set_tclock_cycle(uint32_t cycles); extern uint32_t vr41xx_read_tclock_counter(void); +extern void vr41xx_rtc_init(void); + /* * General-Purpose I/O Unit */ @@ -225,11 +227,5 @@ }; extern void vr41xx_pciu_init(struct vr41xx_pci_address_map *map); - -/* - * MISC - */ -extern void vr41xx_time_init(void); -extern void vr41xx_timer_setup(struct irqaction *irq); #endif /* __NEC_VR41XX_H */ From stuartl@longlandclan.hopto.org Sun Feb 1 14:01:24 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 14:01:25 +0000 (GMT) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:27009 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 14:01:24 +0000 Received: (qmail 14472 invoked by uid 204); 2 Feb 2004 00:01:13 +1000 Received: from stuartl@longlandclan.hopto.org by www by uid 201 with qmail-scanner-1.16 (clamscan: 0.60. spamassassin: 2.61. Clear:. Processed in 0.43109 secs); 01 Feb 2004 14:01:13 -0000 Received: from unknown (HELO longlandclan.hopto.org) (192.168.0.1) by 192.168.5.1 with SMTP; 2 Feb 2004 00:01:12 +1000 Message-ID: <401D06A6.4050905@longlandclan.hopto.org> Date: Mon, 02 Feb 2004 00:01:10 +1000 From: Stuart Longland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS Mailing list Subject: Problems with LCD panel & SCSI support with Linux 2.4.24-pre2 on Cobalt Qube II X-Enigmail-Version: 0.82.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 4219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, Just the other day, I dragged out the old Gateway Microserver I have here (a rebadged Cobalt Qube II) with the idea of setting it up as a fileserver. I opened the box and dropped in an Advansys PCI SCSI card (I don't recall the exact model) into the PCI slot, with the intent of hooking up external SCSI drives. I also replaced the HDD with a 40GB IBM Deskstar I had sitting around. On loading Debian Woody, I discover that there is no SCSI support in the kernel, so I set about building one. Managed to cross compile 2.4.18 with the media patches, etc -- All seemed to work, apart from SCSI. modprobe advansys would complain that the card was not present. I also experienced hard lockups when I tried dumping some large files to it over the LAN. Upgraded it to Linux 2.4.24-pre2 (CVS checkout from linux-mips done 6th January, 2004) -- This seems to have corrected the hard lockups I had previously, however, the SCSI card still doesn't work and now the LCD panel on the back no-longer functions. I have uploaded what information I have (including output from logfiles, lspci output, modprobe output, my toolchain versions, the kernel config used, etc) to http://www.longlandclan.hopto.org/~stuartl/mipsel-errors/. The toolchain was created on a i686-pc-linux-gnu host using the crossdev.sh script on Gentoo Linux. The kernel used was patched using patches from http://people.debian.org/~pm/mips-cobalt/kernel/ Is there anything I might have missed in trying to set this up? I'm fairly new to the MIPS architecture, this is the first time I managed to get a custom MIPS kernel to boot correctly in a usable manner. I've noticed comments that the Cobalt support is suffering some "bit rot" and hence, it has been quite shakey lately (well, for me anyway), however I'd like to help out with ironing out these problems if possible. Thanks, - -- +-------------------------------------------------------------+ | Stuart Longland stuartl at longlandclan.hopto.org | | Brisbane Mesh Node: 719 http://stuartl.cjb.net/ | | I haven't lost my mind - it's backed up on a tape somewhere | | Atomic Linux Project <---> http://atomicl.berlios.de/ | +-------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAHQamuarJ1mMmSrkRAqywAJ0UElNVynKCWy+eM0XkTHiF3+XEvwCdF0jf kisAh5RcXv53aK/ogycmPVk= =rxip -----END PGP SIGNATURE----- From karsten@excalibur.cologne.de Sun Feb 1 14:53:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 14:53:42 +0000 (GMT) Received: from natsmtp01.rzone.de ([IPv6:::ffff:81.169.145.166]:55004 "EHLO natsmtp01.rzone.de") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 14:53:41 +0000 Received: from excalibur.cologne.de (pD9E40BF7.dip.t-dialin.net [217.228.11.247]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i11EracF025330; Sun, 1 Feb 2004 15:53:36 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian)) id 1AnIzo-0000W4-00; Sun, 01 Feb 2004 15:54:48 +0100 Date: Sun, 1 Feb 2004 15:54:48 +0100 From: Karsten Merker To: Stuart Longland Cc: Linux MIPS Mailing list Subject: Re: Problems with LCD panel & SCSI support with Linux 2.4.24-pre2 on Cobalt Qube II Message-ID: <20040201145448.GA1945@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , Stuart Longland , Linux MIPS Mailing list References: <401D06A6.4050905@longlandclan.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <401D06A6.4050905@longlandclan.hopto.org> User-Agent: Mutt/1.3.28i X-No-Archive: yes Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 12:01:10AM +1000, Stuart Longland wrote: > Just the other day, I dragged out the old Gateway Microserver I have > here (a rebadged Cobalt Qube II) with the idea of setting it up as a > fileserver. [snip] > January, 2004) -- This seems to have corrected the hard lockups I had > previously, however, the SCSI card still doesn't work and now the LCD > panel on the back no-longer functions. The device id for the LCD panel has changed in newer kernel versions; the minor device id seems to be selected dynamically now: static struct miscdevice lcd_dev = { MISC_DYNAMIC_MINOR, "lcd", &lcd_fops }; HTH, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From pdh@colonel-panic.org Sun Feb 1 16:39:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 16:39:38 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:45954 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 16:39:38 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.35 #1 (Debian)) id 1AnKd9-0003aa-00 for ; Sun, 01 Feb 2004 16:39:31 +0000 Date: Sun, 1 Feb 2004 16:39:31 +0000 To: linux-mips@linux-mips.org Subject: New Cobalt patches for 2.4.24 Message-ID: <20040201163931.GA13787@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips I've set up a web page at http://www.colonel-panic.org/cobalt-mips with the current Cobalt patches for the 2.4.24 kernel (and some other stuff). If any one has any patches/fixes I'm missing, or any other Cobalt/Linux stuff, I'd be happy to put them up. P. From stuartl@longlandclan.hopto.org Sun Feb 1 19:34:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 19:34:51 +0000 (GMT) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:10881 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 19:34:51 +0000 Received: (qmail 18569 invoked by uid 204); 2 Feb 2004 05:34:31 +1000 Received: from stuartl@longlandclan.hopto.org by www by uid 201 with qmail-scanner-1.16 (clamscan: 0.60. spamassassin: 2.61. Clear:. Processed in 0.37343 secs); 01 Feb 2004 19:34:31 -0000 Received: from unknown (HELO longlandclan.hopto.org) (192.168.0.1) by 192.168.5.1 with SMTP; 2 Feb 2004 05:34:30 +1000 Message-ID: <401D54C6.40207@longlandclan.hopto.org> Date: Mon, 02 Feb 2004 05:34:30 +1000 From: Stuart Longland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karsten Merker CC: Linux MIPS Mailing list Subject: Re: Problems with LCD panel & SCSI support with Linux 2.4.24-pre2 on Cobalt Qube II References: <401D06A6.4050905@longlandclan.hopto.org> <20040201145448.GA1945@excalibur.cologne.de> In-Reply-To: <20040201145448.GA1945@excalibur.cologne.de> X-Enigmail-Version: 0.82.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 4222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karsten Merker wrote: | On Mon, Feb 02, 2004 at 12:01:10AM +1000, Stuart Longland wrote: | | |> Just the other day, I dragged out the old Gateway Microserver I have |>here (a rebadged Cobalt Qube II) with the idea of setting it up as a |>fileserver. | | [snip] | |>January, 2004) -- This seems to have corrected the hard lockups I had |>previously, however, the SCSI card still doesn't work and now the LCD |>panel on the back no-longer functions. | | | The device id for the LCD panel has changed in newer kernel versions; | the minor device id seems to be selected dynamically now: | | static struct miscdevice lcd_dev = { | MISC_DYNAMIC_MINOR, | "lcd", | &lcd_fops | }; | | HTH, | Karsten Hi, Thanks for that, this fixes the LCD problem, it's working fine now. If it's more dynamic, it looks like using devfs might be a better option -- although I'm trying to avoid enabling stuff that enlarges my kernel (I'm at 600kB now). At the moment, I'll see about putting a hack in the scripts to recreate /dev/lcd at boot. Now to nail the problem with SCSI. - -- +-------------------------------------------------------------+ | Stuart Longland stuartl at longlandclan.hopto.org | | Brisbane Mesh Node: 719 http://stuartl.cjb.net/ | | I haven't lost my mind - it's backed up on a tape somewhere | | Atomic Linux Project <---> http://atomicl.berlios.de/ | +-------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAHVTGuarJ1mMmSrkRAqNpAJ9V854J4m+gt1A7mvU07VtaxOSHhwCgjT+9 zTPOAD4j9C3uP8TffZrxBe8= =7adl -----END PGP SIGNATURE----- From ralf@linux-mips.org Sun Feb 1 22:51:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 01 Feb 2004 22:51:02 +0000 (GMT) Received: from p508B57DC.dip.t-dialin.net ([IPv6:::ffff:80.139.87.220]:12853 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 1 Feb 2004 22:51:02 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i11Mnxex011574; Sun, 1 Feb 2004 23:49:59 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i11MnwLS011573; Sun, 1 Feb 2004 23:49:58 +0100 Date: Sun, 1 Feb 2004 23:49:58 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [patch] pg-r4k.c bugs for R4k systems with a secondary cache Message-ID: <20040201224958.GA11444@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: 4223 X-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, Jan 27, 2004 at 12:09:49PM +0100, Maciej W. Rozycki wrote: > > The patch also removes references to has_scache which currently disable > > code for the S-cache line size of 128 bytes as the variable is always 0. > > Here is a somewhat better version. It's functionally equivalent. OK to > apply? Missed your mail and ran over it only now that I had just started to debug the problem myself - but still before wasting a major amount of time ... Lemme test it on my R4400 V4.0 I'll report on it later. Ralf From juszczec@hotmail.com Mon Feb 2 02:11:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 02:11:31 +0000 (GMT) Received: from law10-f96.law10.hotmail.com ([IPv6:::ffff:64.4.15.96]:51214 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 02:11:31 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 1 Feb 2004 18:11:23 -0800 Received: from 24.209.41.112 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 02 Feb 2004 02:11:22 GMT X-Originating-IP: [24.209.41.112] X-Originating-Email: [juszczec@hotmail.com] X-Sender: juszczec@hotmail.com From: "Mark and Janice Juszczec" To: linux-mips@linux-mips.org Subject: mipsel-linux-objcopy problem Date: Mon, 02 Feb 2004 02:11:22 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2004 02:11:23.0007 (UTC) FILETIME=[DACD68F0:01C3E931] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: juszczec@hotmail.com Precedence: bulk X-list: linux-mips Hi folks On one system, I've got # mipsel-linux-objcopy --version GNU objcopy 2.8.1 Copyright 1997 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. # ls -l memload-full -rwxr-xr-x 1 root root 1791550 Feb 1 20:46 memload-full # mipsel-linux-objcopy -Obinary --remove-section=.bss --remove-section=.data --remove-section=.mdebug --pad-to=0x9fe00000 memload-full tryrom [root@mjolnir hfload]# ls -l tryrom -rwxr-xr-x 1 root root 2097152 Feb 1 21:09 tryrom on another system, # mipsel-unknown-linux-gnu-objcopy --version GNU objcopy 2.13.90.0.18 20030121 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. # ls -l memload-full -rwxr-xr-x 1 root root 1791550 Feb 1 20:35 memload-full mipsel-unknown-linux-gnu-objcopy -Obinary --remove-section=.bss --remove-section=.data --remove-section=.mdebug --pad-to=0x9fe00000 memload-full tryrom # ls -l tryrom -rwxr-xr-x 1 root root 1725680 Feb 1 21:01 tryrom Any idea why tryrom made with mipsel-unknown-linux-gnu-objcopy ver 2.13.90.0.18 is smaller than the one made with mipsel-linux-objcopy ver 2.8.1 This is a step in making a rom image for an emulator. The emulator needs the file tryrom to be 2097152. I'm stuck. Help. Mark _________________________________________________________________ Learn how to choose, serve, and enjoy wine at Wine @ MSN. http://wine.msn.com/ From ralf@linux-mips.org Mon Feb 2 13:57:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 13:57:32 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:41024 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 13:57:32 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12DvUex021975; Mon, 2 Feb 2004 14:57:30 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12DvUAO021974; Mon, 2 Feb 2004 14:57:30 +0100 Date: Mon, 2 Feb 2004 14:57:30 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [patch] pg-r4k.c bugs for R4k systems with a secondary cache Message-ID: <20040202135730.GC21735@linux-mips.org> References: <20040201224958.GA11444@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040201224958.GA11444@linux-mips.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: 4225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Feb 01, 2004 at 11:49:58PM +0100, Ralf Baechle wrote: > > > The patch also removes references to has_scache which currently disable > > > code for the S-cache line size of 128 bytes as the variable is always 0. > > > > Here is a somewhat better version. It's functionally equivalent. OK to > > apply? > > Missed your mail and ran over it only now that I had just started to debug > the problem myself - but still before wasting a major amount of time ... > > Lemme test it on my R4400 V4.0 I'll report on it later. So the patch was looking good but didn't solve the problems with 128 byte S-cache lines. I've used your patch as a base and solved the remaining problems, will apply it in a minute. Ralf From ralf@linux-mips.org Mon Feb 2 14:09:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 14:09:28 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:59968 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 14:09:28 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12E9Pex024036; Mon, 2 Feb 2004 15:09:25 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12E9PSl024035; Mon, 2 Feb 2004 15:09:25 +0100 Date: Mon, 2 Feb 2004 15:09:25 +0100 From: Ralf Baechle To: kip.r2@free.fr Cc: linux-mips@linux-mips.org Subject: Re: MIPS Kernel size Message-ID: <20040202140925.GB22008@linux-mips.org> References: <1075215091.40167af364b77@imp1-a.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1075215091.40167af364b77@imp1-a.free.fr> 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: 4226 X-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, Jan 27, 2004 at 03:51:31PM +0100, kip.r2@free.fr wrote: > What will be the approximate size for a minimal MIPS kernel? Btw, the -tiny tree of 2.6 has been booted on a 2MB system. Supposedly that was an i386 system so MIPS16 should boot in an even smaller system and a normal 32-bit MIPS kernel should have enough space to wiggle in 4 megs. Does anybody on this list actually still care about that small systems? Ralf From ralf@linux-mips.org Mon Feb 2 15:08:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 15:08:09 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:48705 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 15:08:08 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12F86ex028664; Mon, 2 Feb 2004 16:08:06 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12F86Cg028663; Mon, 2 Feb 2004 16:08:06 +0100 Date: Mon, 2 Feb 2004 16:08:06 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [patch] pg-r4k.c cp0 hazards for R4000/R4400 Message-ID: <20040202150806.GA27819@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: 4227 X-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, Jan 26, 2004 at 06:12:43PM +0100, Maciej W. Rozycki wrote: > The R4000/R4400 has a coprocessor 0 hazard when a P-cache operation is > less than two non-load, non-cache instructions apart from a store to the > same line. For processors without a secondary cache, the code in pg-r4k.c > currently issues a Create Dirty Exclusive D-cache operation and then > immediately executes consecutive stores to the same line, therefore > fulfilling the conditions for the hazard. The wording is "There must be two non-load, non-CACHE instructions between a store and a CACHE instruction directed to the same primary cache line as the store." My interpretation of that is the problem only exists if a store instruction is followed by a cache instruction, not if the cache instruction is followed by the store? I've not found any hints in the manual to verify or falsify this theory. In case you're right we've violated this hazard since almost beginning of the time, see http://www.linux-mips.org/cvsweb/linux/arch/mips/mm/Attic/pg-r4k.S?rev=1.9 and I've not heared of any problems arising from this. Any DECstations using the R4[04]00PC CPU variant? > The following patch changes the problematic operations to be performed on > the cache line following the one to be written immediately. It is safe to > do so, because the cache operations are only a performance hint and are > not required for data coherency. However it is essential not to bypass > the end of the page, so the trailing area of the page is excluded from > these cache operation, similarly to what has already been done for > prefetching. > > Actually, I'd like to optimize the functions a bit further, specifically > to avoid multiple cacheops to the same line (if you don't mind), Please do so - cacheops are fairly expensive, we must use them as intelligently as possible. > but > currently I'd like to apply this change to assure correct operation. As I > have no non-SC R4000/R4400 system, this was untested, but perhaps studying > the problem covered by the -scache patch sent previously will show if the > hazard is indeed avoided. Have you actually been hit by that hazard? > The patch also increases the buffers a bit for three reasons: > > 1. copy_page_array is already too small for the 128-byte S-cache line > case. ;-) > > 2. The trail for non-SC R4000/R4400 increases buffer consumption and I was > too lazy to calculate the requirements. > > 3. The planned optimization will likely require a little bit more space as > well. > > BTW, I was unable to reproduce your instruction count calculation for the > prefetch case; other results seem OK. Yep, the patch I just checked in increased the allocation size to handle the worst case appropriately. In the end I think we really want to trade memory for performance here. > OK to apply? Most of your changes conflict with my fixes, so I guess that need redoing ... Ralf From macro@ds2.pg.gda.pl Mon Feb 2 15:13:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 15:13:32 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:54702 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 15:13:31 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 3A69146A7E; Mon, 2 Feb 2004 16:13:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 2C13D44C9D; Mon, 2 Feb 2004 16:13:28 +0100 (CET) Date: Mon, 2 Feb 2004 16:13:28 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@-mips.org: linux In-Reply-To: <20040202141939Z8225226-9616+1555@linux-mips.org> Message-ID: References: <20040202141939Z8225226-9616+1555@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Mon, 2 Feb 2004 ralf@linux-mips.org wrote: > PMC-Sierra says that the workaround for errata #18 of the R4600 V1.7 > and a similar erratum in V2.0 don't require disabling of interrupts, > so remove that code. How do we assure tails of interrupt handlers don't trigger the errata? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Mon Feb 2 15:23:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 15:23:10 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:63553 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 15:23:10 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12FN8ex028989; Mon, 2 Feb 2004 16:23:08 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12FN8Cg028988; Mon, 2 Feb 2004 16:23:08 +0100 Date: Mon, 2 Feb 2004 16:23:07 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@-mips.org: linux Message-ID: <20040202152307.GB28673@linux-mips.org> References: <20040202141939Z8225226-9616+1555@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: 4229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 04:13:28PM +0100, Maciej W. Rozycki wrote: > > PMC-Sierra says that the workaround for errata #18 of the R4600 V1.7 > > and a similar erratum in V2.0 don't require disabling of interrupts, > > so remove that code. > > How do we assure tails of interrupt handlers don't trigger the errata? The problem can only be triggered if instructions surrounding the cacheop use the dcache; exceptions such as interrupts are not relevant. Which I'm really happy about. Disabling interrupts is a problem in cases were we can't avoid page faults. Ralf From Todd.Smith@camc.org Mon Feb 2 16:12:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 16:12:30 +0000 (GMT) Received: from hnet1.camc.org ([IPv6:::ffff:206.193.127.2]:3783 "EHLO mail2.camcare.com") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 16:12:29 +0000 Received: from KES.camcare.com (hnet1.camc.org [206.193.127.2]) by mail2.camcare.com (Postfix) with ESMTP id 316B86DD5 for ; Mon, 2 Feb 2004 12:05:36 -0500 (EST) Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Feb 2004 11:12:11 -0500 Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A56955D@KES.camcare.com> From: "Smith, Todd" To: "'linux-mips@linux-mips.org '" Subject: RE: MIPS Kernel size Date: Mon, 2 Feb 2004 11:12:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Todd.Smith@camc.org Precedence: bulk X-list: linux-mips Hello Ralf, I am still interested in some older PDA usage that has limited resources. I certainly don't want to hold up or stop current kernel dev but is there a problem with keeping small kernel and/or userspace limits? Thank you for the discussion. Todd Smith -----Original Message----- From: Ralf Baechle Btw, the -tiny tree of 2.6 has been booted on a 2MB system. Supposedly that was an i386 system so MIPS16 should boot in an even smaller system and a normal 32-bit MIPS kernel should have enough space to wiggle in 4 megs. Does anybody on this list actually still care about that small systems? Ralf From karsten@excalibur.cologne.de Mon Feb 2 18:37:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 18:37:08 +0000 (GMT) Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:14522 "EHLO natsmtp00.webmailer.de") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 18:37:07 +0000 Received: from excalibur.cologne.de (pD9E408CD.dip.t-dialin.net [217.228.8.205]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i12Ianqo026784 for ; Mon, 2 Feb 2004 19:36:49 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian)) id 1AnixS-0000Ms-00 for ; Mon, 02 Feb 2004 19:38:06 +0100 Date: Mon, 2 Feb 2004 19:38:06 +0100 From: Karsten Merker To: linux-mips@linux-mips.org Subject: Re: [patch] pg-r4k.c cp0 hazards for R4000/R4400 Message-ID: <20040202183806.GD913@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@linux-mips.org References: <20040202150806.GA27819@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040202150806.GA27819@linux-mips.org> User-Agent: Mutt/1.3.28i X-No-Archive: yes Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 04:08:06PM +0100, Ralf Baechle wrote: > Any DECstations using the R4[04]00PC CPU variant? Not that I know of - only R4[04]00SC. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From karsten@excalibur.cologne.de Mon Feb 2 18:42:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 18:42:24 +0000 (GMT) Received: from natsmtp01.rzone.de ([IPv6:::ffff:81.169.145.166]:39339 "EHLO natsmtp01.rzone.de") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 18:42:23 +0000 Received: from excalibur.cologne.de (pD9E408CD.dip.t-dialin.net [217.228.8.205]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i12Ig8nf024357 for ; Mon, 2 Feb 2004 19:42:08 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian)) id 1Anj2b-0000N1-00 for ; Mon, 02 Feb 2004 19:43:25 +0100 Date: Mon, 2 Feb 2004 19:43:25 +0100 From: Karsten Merker To: linux-mips@linux-mips.org Subject: Re: MIPS Kernel size Message-ID: <20040202184325.GE913@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@linux-mips.org References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040202140925.GB22008@linux-mips.org> User-Agent: Mutt/1.3.28i X-No-Archive: yes Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 03:09:25PM +0100, Ralf Baechle wrote: > On Tue, Jan 27, 2004 at 03:51:31PM +0100, kip.r2@free.fr wrote: > > > What will be the approximate size for a minimal MIPS kernel? > > Btw, the -tiny tree of 2.6 has been booted on a 2MB system. Supposedly that > was an i386 system so MIPS16 should boot in an even smaller system and a > normal 32-bit MIPS kernel should have enough space to wiggle in 4 megs. > > Does anybody on this list actually still care about that small systems? Depends on what you consider "that small". Kernel size is a large issue for the Cobalt series due to the firmware limits (although Peter Hortons attempts at a Cobalt bootloader will hopefully help in this regard). Embedded stuff and PDAs is another field where 2.6 currently seems to pose a problem. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From ralf@linux-mips.org Mon Feb 2 18:53:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 18:53:52 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:44356 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 18:53:52 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12IrUex024033; Mon, 2 Feb 2004 19:53:30 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12IrTDl024032; Mon, 2 Feb 2004 19:53:29 +0100 Date: Mon, 2 Feb 2004 19:53:29 +0100 From: Ralf Baechle To: "Smith, Todd" Cc: "'linux-mips@linux-mips.org '" Subject: Re: MIPS Kernel size Message-ID: <20040202185329.GA23667@linux-mips.org> References: <490E0430C3C72046ACF7F18B7CD76A2A56955D@KES.camcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A56955D@KES.camcare.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: 4233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 11:12:10AM -0500, Smith, Todd wrote: > I am still interested in some older PDA usage that has limited resources. I > certainly don't want to hold up or stop current kernel dev but is there a > problem with keeping small kernel and/or userspace limits? Different tradeoffs. In general the kernel is optimized for performance, even at the cost of significant amounts of memory. As the most infamous example the kernel is using lots of fairly complex hash and radix trees. But why would a system that has just a default route need the same kind of data structures and algorithms it takes to route packets on backbone router in the default free zone? Why would you drive a moon rocket to for shopping? Linux has generally developped in the direction of larger machines and higher scalability and sometimes that's causing fairly bad itching. The -tiny tree is an attempt to correct this. It's a development tree but with the goal of merging changes back into the standard kernel and I hope much of it will be merged back into 2.6 - 2.8 is too far in the future to wait for ... Ralf From ralf@linux-mips.org Mon Feb 2 18:57:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 18:57:46 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:49220 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 18:57:46 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12IvRex024142; Mon, 2 Feb 2004 19:57:27 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12IvQGf024141; Mon, 2 Feb 2004 19:57:26 +0100 Date: Mon, 2 Feb 2004 19:57:26 +0100 From: Ralf Baechle To: Karsten Merker , linux-mips@linux-mips.org Subject: Re: MIPS Kernel size Message-ID: <20040202185726.GB23667@linux-mips.org> References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> <20040202184325.GE913@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040202184325.GE913@excalibur.cologne.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: 4234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 07:43:25PM +0100, Karsten Merker wrote: > Depends on what you consider "that small". Kernel size is a large > issue for the Cobalt series due to the firmware limits (although > Peter Hortons attempts at a Cobalt bootloader will hopefully help in > this regard). Embedded stuff and PDAs is another field where 2.6 > currently seems to pose a problem. I really hate that term "embedded" - it's very hard to define. Anyway, there's an increasing amount of so-called embedded systems with several gigabytes of memory and even for much smaller system 2.6 is already making 2.4 look pale. The Cobalt case is special; it's firmware could almost be the definition of the term crap ... Ralf From geert@linux-m68k.org Mon Feb 2 19:38:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 19:38:49 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:57841 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 19:38:48 +0000 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i12JcKw2018366; Mon, 2 Feb 2004 20:38:20 +0100 (MET) Date: Mon, 2 Feb 2004 20:38:18 +0100 (MET) From: Geert Uytterhoeven To: Ralf Baechle cc: Karsten Merker , Linux/MIPS Development Subject: Re: MIPS Kernel size In-Reply-To: <20040202185726.GB23667@linux-mips.org> Message-ID: References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> <20040202184325.GE913@excalibur.cologne.de> <20040202185726.GB23667@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: 4235 X-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 Mon, 2 Feb 2004, Ralf Baechle wrote: > On Mon, Feb 02, 2004 at 07:43:25PM +0100, Karsten Merker wrote: > > Depends on what you consider "that small". Kernel size is a large > > issue for the Cobalt series due to the firmware limits (although > > Peter Hortons attempts at a Cobalt bootloader will hopefully help in > > this regard). Embedded stuff and PDAs is another field where 2.6 > > currently seems to pose a problem. > > I really hate that term "embedded" - it's very hard to define. Anyway, > there's an increasing amount of so-called embedded systems with several > gigabytes of memory and even for much smaller system 2.6 is already > making 2.4 look pale. Indeed. Today's embedded can easily be larger than desktop/server from only a few years ago... Fortunately, system size is still important for some applications. Witness the existence of a System Size Working Group in the CE Linux Forum. So yes, some people still care. > The Cobalt case is special; it's firmware could almost be the definition > of the term crap ... Can't you use the firmware to load a second stage booter, which can load larger kernels? 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 Mon Feb 2 19:46:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 19:46:45 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:28997 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 19:46:45 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12JkNex025169; Mon, 2 Feb 2004 20:46:23 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12JkMw0025168; Mon, 2 Feb 2004 20:46:22 +0100 Date: Mon, 2 Feb 2004 20:46:22 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: Karsten Merker , Linux/MIPS Development Subject: Re: MIPS Kernel size Message-ID: <20040202194622.GA25095@linux-mips.org> References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> <20040202184325.GE913@excalibur.cologne.de> <20040202185726.GB23667@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: 4236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 08:38:18PM +0100, Geert Uytterhoeven wrote: > a few years ago... > > Fortunately, system size is still important for some applications. Witness the > existence of a System Size Working Group in the CE Linux Forum. So yes, some > people still care. All but one of the new MIPS systems I got in the past years support memory sizes in the GB range ... > > The Cobalt case is special; it's firmware could almost be the definition > > of the term crap ... > > Can't you use the firmware to load a second stage booter, which can load > larger kernels? That would be possible - but would still leave all the other limitations of the original firmware such as not supporting netboots. Peter Horten seem to have worked on something better. Ralf From geert@linux-m68k.org Mon Feb 2 19:50:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 19:50:58 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:35577 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 19:50:57 +0000 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i12Jodw2019255; Mon, 2 Feb 2004 20:50:39 +0100 (MET) Date: Mon, 2 Feb 2004 20:50:38 +0100 (MET) From: Geert Uytterhoeven To: Ralf Baechle cc: Karsten Merker , Linux/MIPS Development Subject: Re: MIPS Kernel size In-Reply-To: <20040202194622.GA25095@linux-mips.org> Message-ID: References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> <20040202184325.GE913@excalibur.cologne.de> <20040202185726.GB23667@linux-mips.org> <20040202194622.GA25095@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: 4237 X-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 Mon, 2 Feb 2004, Ralf Baechle wrote: > On Mon, Feb 02, 2004 at 08:38:18PM +0100, Geert Uytterhoeven wrote: > > > The Cobalt case is special; it's firmware could almost be the definition > > > of the term crap ... > > > > Can't you use the firmware to load a second stage booter, which can load > > larger kernels? > > That would be possible - but would still leave all the other limitations > of the original firmware such as not supporting netboots. Peter Horten > seem to have worked on something better. Unles the second stage booter supports netboots. I don't know anything about the Cobalt firmware, but just using it to load something like uBoot should be possible, right? 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 Mon Feb 2 19:59:58 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 19:59:58 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:43845 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 19:59:58 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12Jxcex025465; Mon, 2 Feb 2004 20:59:38 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12Jxbsp025464; Mon, 2 Feb 2004 20:59:37 +0100 Date: Mon, 2 Feb 2004 20:59:37 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: Karsten Merker , Linux/MIPS Development Subject: Re: MIPS Kernel size Message-ID: <20040202195937.GB24843@linux-mips.org> References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> <20040202184325.GE913@excalibur.cologne.de> <20040202185726.GB23667@linux-mips.org> <20040202194622.GA25095@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: 4238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 08:50:38PM +0100, Geert Uytterhoeven wrote: > > That would be possible - but would still leave all the other limitations > > of the original firmware such as not supporting netboots. Peter Horten > > seem to have worked on something better. > > Unles the second stage booter supports netboots. I don't know anything about > the Cobalt firmware, but just using it to load something like uBoot should be > possible, right? Oh, it boots everything as long as it's a compress ELF executable named /vmlinux.gz on a PC-style partitioned disk with an ext2 filesystem (must be revision 0!) on it's first partition or it uploaded with cu(1)'s send file command at 115200bps, 8N1. No luxury, whistles or bells at all. Ralf From ica2_ts@csv.ica.uni-stuttgart.de Mon Feb 2 20:07:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 20:07:48 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:37221 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 20:07:47 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1AnkMB-0002BE-00; Mon, 02 Feb 2004 21:07:43 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1AnkMA-0007TL-00; Mon, 02 Feb 2004 21:07:42 +0100 Date: Mon, 2 Feb 2004 21:07:42 +0100 To: Ralf Baechle Cc: Geert Uytterhoeven , Karsten Merker , Linux/MIPS Development Subject: Re: MIPS Kernel size Message-ID: <20040202200742.GG1458@rembrandt.csv.ica.uni-stuttgart.de> References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> <20040202184325.GE913@excalibur.cologne.de> <20040202185726.GB23667@linux-mips.org> <20040202194622.GA25095@linux-mips.org> <20040202195937.GB24843@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040202195937.GB24843@linux-mips.org> User-Agent: Mutt/1.5.4i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4239 X-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 Baechle wrote: > On Mon, Feb 02, 2004 at 08:50:38PM +0100, Geert Uytterhoeven wrote: > > > > That would be possible - but would still leave all the other limitations > > > of the original firmware such as not supporting netboots. Peter Horten > > > seem to have worked on something better. > > > > Unles the second stage booter supports netboots. I don't know anything about > > the Cobalt firmware, but just using it to load something like uBoot should be > > possible, right? > > Oh, it boots everything as long as it's a compress ELF executable named > /vmlinux.gz AFAIK it also boots such a kernel from a NFS(!) export. > on a PC-style partitioned disk with an ext2 filesystem > (must be revision 0!) on it's first partition or it uploaded with cu(1)'s > send file command at 115200bps, 8N1. No luxury, whistles or bells at > all. Thiemo From ralf@linux-mips.org Mon Feb 2 20:32:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 20:32:44 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:10310 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 20:32:43 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12KWbex026153; Mon, 2 Feb 2004 21:32:38 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12KWbvn026152; Mon, 2 Feb 2004 21:32:37 +0100 Date: Mon, 2 Feb 2004 21:32:37 +0100 From: Ralf Baechle To: Thiemo Seufer Cc: Geert Uytterhoeven , Karsten Merker , Linux/MIPS Development Subject: Re: MIPS Kernel size Message-ID: <20040202203237.GG24843@linux-mips.org> References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> <20040202184325.GE913@excalibur.cologne.de> <20040202185726.GB23667@linux-mips.org> <20040202194622.GA25095@linux-mips.org> <20040202195937.GB24843@linux-mips.org> <20040202200742.GG1458@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040202200742.GG1458@rembrandt.csv.ica.uni-stuttgart.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: 4240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 09:07:42PM +0100, Thiemo Seufer wrote: > > Oh, it boots everything as long as it's a compress ELF executable named > > /vmlinux.gz > > AFAIK it also boots such a kernel from a NFS(!) export. Well possible - the firmware contains a Linux kernel of approx 2.0.30 vintage, so that would have been easy to arrange. When I kernel work for Cobalt however booting from disk and over serial were the only two available options. Ralf From ralf@linux-mips.org Mon Feb 2 20:48:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 20:48:09 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:24646 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 20:48:08 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i12Km2ex027025; Mon, 2 Feb 2004 21:48:02 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i12Km1vt027022; Mon, 2 Feb 2004 21:48:01 +0100 Date: Mon, 2 Feb 2004 21:48:01 +0100 From: Ralf Baechle To: Stuart Longland Cc: Karsten Merker , Linux MIPS Mailing list Subject: Re: Problems with LCD panel & SCSI support with Linux 2.4.24-pre2 on Cobalt Qube II Message-ID: <20040202204801.GA26734@linux-mips.org> References: <401D06A6.4050905@longlandclan.hopto.org> <20040201145448.GA1945@excalibur.cologne.de> <401D54C6.40207@longlandclan.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <401D54C6.40207@longlandclan.hopto.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: 4241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 05:34:30AM +1000, Stuart Longland wrote: > Thanks for that, this fixes the LCD problem, it's working fine now. > If > it's more dynamic, it looks like using devfs might be a better option -- > although I'm trying to avoid enabling stuff that enlarges my kernel (I'm > at 600kB now). Devfs is not going to be the solution, that much is clear. It's deprecated in 2.6 and in general enjoys the positive reputation of ebola in most of the kernel community. For 2.4 /proc/misc allows you to get away without devfs, something that'll also work with 2.6. In a more general context it looks like udev is going to be the official successor of devfs. > At the moment, I'll see about putting a hack in the scripts to recreate > /dev/lcd at boot. Ralf From jsun@mvista.com Mon Feb 2 21:20:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 21:20:02 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:33776 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 21:20:02 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id i12LJoi19049; Mon, 2 Feb 2004 13:19:50 -0800 Date: Mon, 2 Feb 2004 13:19:50 -0800 From: Jun Sun To: Atsushi Nemoto Cc: macro@ds2.pg.gda.pl, linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [PATCH 2.6] enable genrtc for MIPS Message-ID: <20040202131950.I18155@mvista.com> References: <20040130103913.E31937@mvista.com> <20040201.203005.74756858.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040201.203005.74756858.anemo@mba.ocn.ne.jp>; from anemo@mba.ocn.ne.jp on Sun, Feb 01, 2004 at 08:30:05PM +0900 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4242 X-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 Sun, Feb 01, 2004 at 08:30:05PM +0900, Atsushi Nemoto wrote: > > By the way, with this patch, individual board can not implement it's > own genrtc routines. How about making gen_rtc_time, etc. pointer to > functions to allow overrides? > Is this necessary? How about letting us wait until there is a sensible need? > I think implementing rtc_get_time (mips specific) with get_rtc_time > (genrtc) is more efficient than implementing get_rtc_time with > rtc_get_time for most RTC chips. > If I understand you correctly, you like to have board rtc read routines to return a rtc structure instead of the unsigned long integer. There are actually boards which makes the current implementation more efficient. See vr4181. In general, however, this is not a bad idea, just involving a lot more board level changes. I think it deserves another patch or even debate. Jun From Todd.Smith@camc.org Mon Feb 2 21:48:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 21:48:48 +0000 (GMT) Received: from hnet1.camc.org ([IPv6:::ffff:206.193.127.2]:27596 "EHLO mail2.camcare.com") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 21:48:48 +0000 Received: from KES.camcare.com (hnet1.camc.org [206.193.127.2]) by mail2.camcare.com (Postfix) with ESMTP id 5EA806E51 for ; Mon, 2 Feb 2004 17:42:13 -0500 (EST) Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Feb 2004 16:48:44 -0500 Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> From: "Smith, Todd" To: "'linux-mips@linux-mips.org'" Subject: RE: MIPS Kernel size Date: Mon, 2 Feb 2004 16:48:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Todd.Smith@camc.org Precedence: bulk X-list: linux-mips Hello Ralf, I like the idea of the -tiny tree and I hope that these changes get merged back into the main kernel tree. One of Linux's historic advantages is that it can run on older equipment but the trend seems to be supporting only current equipment Thanks Todd Smith From pdh@colonel-panic.org Mon Feb 2 22:32:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2004 22:32:57 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:46464 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Mon, 2 Feb 2004 22:32:56 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.35 #1 (Debian)) id 1AnmZf-0000gR-00 for ; Mon, 02 Feb 2004 22:29:47 +0000 Date: Mon, 2 Feb 2004 22:29:47 +0000 To: linux-mips@linux-mips.org Subject: Re: MIPS Kernel size Message-ID: <20040202222947.GB2513@skeleton-jack> References: <1075215091.40167af364b77@imp1-a.free.fr> <20040202140925.GB22008@linux-mips.org> <20040202184325.GE913@excalibur.cologne.de> <20040202185726.GB23667@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 08:38:18PM +0100, Geert Uytterhoeven wrote: > > > The Cobalt case is special; it's firmware could almost be the definition > > of the term crap ... > > Can't you use the firmware to load a second stage booter, which can load larger > kernels? > Yes, but you still have to maintain a old style EXT2 partition just for the firmware. Besides, after a while your second stage loader starts to look like a boot loader anyway, once you've added network booting of large kernels, kernel command line support and the other things the original firmware was missing. P. From nemoto@toshiba-tops.co.jp Tue Feb 3 01:29:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 01:29:01 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:32289 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Tue, 3 Feb 2004 01:29:00 +0000 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 3 Feb 2004 01:29:54 UT Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i131TQ1x002169; Tue, 3 Feb 2004 10:29:26 +0900 (JST) (envelope-from nemoto@toshiba-tops.co.jp) Date: Tue, 03 Feb 2004 10:30:25 +0900 (JST) Message-Id: <20040203.103025.78702251.nemoto@toshiba-tops.co.jp> To: jsun@mvista.com Cc: macro@ds2.pg.gda.pl, linux-mips@linux-mips.org Subject: Re: [PATCH 2.6] enable genrtc for MIPS From: Atsushi Nemoto In-Reply-To: <20040202131950.I18155@mvista.com> References: <20040201.203005.74756858.anemo@mba.ocn.ne.jp> <20040202131950.I18155@mvista.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 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: 4245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nemoto@toshiba-tops.co.jp Precedence: bulk X-list: linux-mips >>>>> On Mon, 2 Feb 2004 13:19:50 -0800, Jun Sun said: >> By the way, with this patch, individual board can not implement >> it's own genrtc routines. How about making gen_rtc_time, >> etc. pointer to functions to allow overrides? jsun> Is this necessary? How about letting us wait until there is a jsun> sensible need? OK, we can wait. But still I suppose gen_rtc_time will become a pointer sooner or later.... Anyway, I think using genrtc instead of mips-rtc is very good idea. Thank you. jsun> If I understand you correctly, you like to have board rtc read jsun> routines to return a rtc structure instead of the unsigned long jsun> integer. jsun> There are actually boards which makes the current implementation jsun> more efficient. See vr4181. I see. jsun> In general, however, this is not a bad idea, just involving a jsun> lot more board level changes. I think it deserves another patch jsun> or even debate. Though I'm not have a real code yet, how about this idea? 1. Provide std_rtc_get_time (returns ulong) implemented with get_rtc_time (returns rtc struct) pointer. 2. Provide std_get_rtc_time (returns rtc struct) implemented with rtc_get_time returns ulong) pointer. 3. Each board implement its own rtc_get_time or get_rtc_time. 4. In generic time_init(), initialize rtc_get_time pointer or get_rtc_time pointer with std_rtc_get_time or std_get_rtc_time if they were NULL. --- Atsushi Nemoto From ralf@linux-mips.org Tue Feb 3 11:39:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 11:39:30 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:7250 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 11:39:30 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13BdSex029083 for ; Tue, 3 Feb 2004 12:39:28 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13BdS1p029082 for linux-mips@linux-mips.org; Tue, 3 Feb 2004 12:39:28 +0100 Date: Tue, 3 Feb 2004 12:39:28 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Re: R4600 V1.7 errata Message-ID: <20040203113928.GA28340@linux-mips.org> References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040201045258.GA4601@linux-mips.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: 4246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Feb 01, 2004 at 05:52:58AM +0100, Ralf Baechle wrote: > > Well, it a little 'better'. It now hangs while configurating the network > > device, while in earlier versions the freeze appeared while calibrating the > > delay loop, or mounting the root fs. > > Is there something else I could try? > > Until I know what's going on, I am going to look for a kernel with proper > > VINO support which is 'old' enough to run without the freeze.. > > Seems I lost the R4600 V1.7 errata documents I used to have so all > information that is left to me is what's documented in the Linux code. > I've removed all the mentioned instructions and the kernel which > otherwise is running fine on R5000 systems or R4600 V2.0 keeps crashing. > I suspect I'm becoming victim of some of the other of the chip's errata; > it has at least 18 ... > > Anybody still got errata information for the R4600 V1.7 around? Jorik was so friendly to track down the patch in CVS that broke the R4600 V1.7 back in time. With that as a start it was fairly easy to isolate the problem further. Seems we became victim of some erratum that affects the operation of indexed I-cache flushes only. Last night I commited a patch that provides an optimized solution for the problem. Still, knowing the errata sheet of this processor has at least 18 items on it I'd not place bets on it being totally reliable. Therefore I'm still interested, just in case somebody happens to run over a dusty errata sheet somewhere :-) Ralf From rathann@icm.edu.pl Tue Feb 3 11:43:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 11:43:02 +0000 (GMT) Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:29088 "EHLO atol.icm.edu.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 11:43:02 +0000 Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132]) by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i13Bgphp032519 for ; Tue, 3 Feb 2004 12:42:51 +0100 (CET) Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian)) id 1AnyxB-0007Ev-00 for ; Tue, 03 Feb 2004 12:42:53 +0100 Date: Tue, 3 Feb 2004 12:42:53 +0100 From: "Dominik 'Rathann' Mierzejewski" To: linux-mips@linux-mips.org Subject: Re: R4600 V1.7 errata Message-ID: <20040203114252.GA27810@icm.edu.pl> Mail-Followup-To: linux-mips@linux-mips.org References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> <20040203113928.GA28340@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040203113928.GA28340@linux-mips.org> User-Agent: Mutt/1.3.28i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rathann@icm.edu.pl Precedence: bulk X-list: linux-mips On Tue, Feb 03, 2004 at 12:39:28PM +0100, Ralf Baechle wrote: [...] > Jorik was so friendly to track down the patch in CVS that broke the R4600 > V1.7 back in time. With that as a start it was fairly easy to isolate the > problem further. Seems we became victim of some erratum that affects the > operation of indexed I-cache flushes only. Last night I commited a patch > that provides an optimized solution for the problem. I assume it's safe to test it now? I'll build it for my R4600 V2.0 and report in a while. Stay tuned. -- Dominik 'Rathann' Mierzejewski Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810 From ralf@linux-mips.org Tue Feb 3 11:52:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 11:52:38 +0000 (GMT) Received: from p508B7363.dip.t-dialin.net ([IPv6:::ffff:80.139.115.99]:20818 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 11:52:37 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13Bqaex029376 for ; Tue, 3 Feb 2004 12:52:36 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13Bqa2P029375 for linux-mips@linux-mips.org; Tue, 3 Feb 2004 12:52:36 +0100 Date: Tue, 3 Feb 2004 12:52:36 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Re: R4600 V1.7 errata Message-ID: <20040203115236.GB28340@linux-mips.org> References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> <20040203113928.GA28340@linux-mips.org> <20040203114252.GA27810@icm.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040203114252.GA27810@icm.edu.pl> 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: 4248 X-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, Feb 03, 2004 at 12:42:53PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tue, Feb 03, 2004 at 12:39:28PM +0100, Ralf Baechle wrote: > [...] > > Jorik was so friendly to track down the patch in CVS that broke the R4600 > > V1.7 back in time. With that as a start it was fairly easy to isolate the > > problem further. Seems we became victim of some erratum that affects the > > operation of indexed I-cache flushes only. Last night I commited a patch > > that provides an optimized solution for the problem. > > I assume it's safe to test it now? I'll build it for my R4600 V2.0 and > report in a while. Stay tuned. 2.0 requires different workarounds which are already in place and functional since quite some time. We still lacking a fix for one important erratum of the 2.0 but it seems pretty stable without. Chip revs later than 2.0 do identify as 2.0 so if you're lucky your processor is actually a post-2.0 and working just fine ... Ralf From macro@ds2.pg.gda.pl Tue Feb 3 14:21:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 14:21:38 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:40130 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 14:21:37 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id CAA6A4781E; Tue, 3 Feb 2004 14:21:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id B3B9A4622B; Tue, 3 Feb 2004 14:21:29 +0100 (CET) Date: Tue, 3 Feb 2004 14:21:29 +0100 (CET) From: "Maciej W. Rozycki" To: Mark and Janice Juszczec Cc: linux-mips@linux-mips.org Subject: Re: mipsel-linux-objcopy problem In-Reply-To: Message-ID: References: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Mon, 2 Feb 2004, Mark and Janice Juszczec wrote: > # ls -l memload-full > -rwxr-xr-x 1 root root 1791550 Feb 1 20:35 memload-full > > mipsel-unknown-linux-gnu-objcopy -Obinary --remove-section=.bss > --remove-section=.data --remove-section=.mdebug --pad-to=0x9fe00000 > memload-full tryrom > > # ls -l tryrom > -rwxr-xr-x 1 root root 1725680 Feb 1 21:01 tryrom > > Any idea why tryrom made with mipsel-unknown-linux-gnu-objcopy ver > 2.13.90.0.18 is smaller than the one made with mipsel-linux-objcopy ver > 2.8.1 Perhaps there's a bug in one or both of the versions. 2.8.1 is terribly old and 2.13.90 (as all binutils versions with 9x at the third position) is a CVS snapshot. You may try upgrading to 2.14 before starting further experiments. > This is a step in making a rom image for an emulator. The emulator needs > the file tryrom to be 2097152. I'm stuck. What does `readelf -e memload-full' output? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Tue Feb 3 14:38:18 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 14:38:18 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:18636 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 14:38:18 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id F3BFB4A8C7; Tue, 3 Feb 2004 14:41:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id E804E474C8; Tue, 3 Feb 2004 14:41:09 +0100 (CET) Date: Tue, 3 Feb 2004 14:41:09 +0100 (CET) From: "Maciej W. Rozycki" To: "Smith, Todd" Cc: "'linux-mips@linux-mips.org'" Subject: RE: MIPS Kernel size In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> Message-ID: References: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Mon, 2 Feb 2004, Smith, Todd wrote: > I like the idea of the -tiny tree and I hope that these changes get merged > back into the main kernel tree. One of Linux's historic advantages is that > it can run on older equipment but the trend seems to be supporting only > current equipment I beg your pardon, but isn't the DECstation old enough? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From jbglaw@dvmwest.gt.owl.de Tue Feb 3 14:50:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 14:50:17 +0000 (GMT) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:62916 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 14:50:16 +0000 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 2517A4B551; Tue, 3 Feb 2004 15:50:15 +0100 (CET) Date: Tue, 3 Feb 2004 15:50:14 +0100 From: Jan-Benedict Glaw To: "'linux-mips@linux-mips.org'" Subject: Re: MIPS Kernel size Message-ID: <20040203145014.GK28571@lug-owl.de> Mail-Followup-To: "'linux-mips@linux-mips.org'" References: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xsn3knLL3qrmRbVI" Content-Disposition: inline In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> 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.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4251 X-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 --Xsn3knLL3qrmRbVI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2004-02-02 16:48:43 -0500, Smith, Todd wrote in message <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com>: > Hello Ralf, >=20 > I like the idea of the -tiny tree and I hope that these changes get merged > back into the main kernel tree. One of Linux's historic advantages is th= at > it can run on older equipment but the trend seems to be supporting only > current equipment It's even running on VAXen. But I admit that I like having more than 8MB of RAM, though... 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)); --Xsn3knLL3qrmRbVI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAH7UlHb1edYOZ4bsRAjC3AJ0f62tQC7Gqp1a+B0gjZXN9P8T5cgCfWkvN fFBBhUDknJLE0qUu72fSluo= =xRZ4 -----END PGP SIGNATURE----- --Xsn3knLL3qrmRbVI-- From yuasa@hh.iij4u.or.jp Tue Feb 3 14:53:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 14:53:43 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:59131 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 14:53:42 +0000 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id XAA23076; Tue, 3 Feb 2004 23:53:39 +0900 (JST) Received: 4UMDO01 id i13Ercr24365; Tue, 3 Feb 2004 23:53:38 +0900 (JST) Received: 4UMRO01 id i13ErbC06684; Tue, 3 Feb 2004 23:53:38 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Tue, 3 Feb 2004 23:53:34 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] Fixed pci-vr41xx.c build Message-Id: <20040203235334.004b35b6.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4252 X-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 Hello Ralf, I made a patch for fixing pci-vr41xx.c build. Please apply this patch to v2.6. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/pci-vr41xx.c linux/arch/mips/pci/pci-vr41xx.c --- linux-orig/arch/mips/pci/pci-vr41xx.c Fri Jun 13 23:19:56 2003 +++ linux/arch/mips/pci/pci-vr41xx.c Tue Feb 3 23:00:27 2004 @@ -8,7 +8,7 @@ * Author: Yoichi Yuasa * yyuasa@mvista.com or source@mvista.com * - * Copyright 2001,2002 MontaVista Software Inc. + * Copyright 2001-2003 MontaVista Software Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -49,9 +49,7 @@ #include #include -#include "pciu.h" - -extern unsigned long vr41xx_vtclock; +#include "pci-vr41xx.h" static inline int vr41xx_pci_config_access(unsigned char bus, unsigned int devfn, int where) @@ -150,6 +148,7 @@ void __init vr41xx_pciu_init(struct vr41xx_pci_address_map *map) { struct vr41xx_pci_address_space *s; + unsigned long vtclock; u32 config; int n; @@ -169,11 +168,12 @@ udelay(1); /* Select PCI clock */ - if (vr41xx_vtclock < MAX_PCI_CLOCK) + vtclock = vr41xx_get_vtclock_frequency(); + if (vtclock < MAX_PCI_CLOCK) writel(EQUAL_VTCLOCK, PCICLKSELREG); - else if ((vr41xx_vtclock / 2) < MAX_PCI_CLOCK) + else if ((vtclock / 2) < MAX_PCI_CLOCK) writel(HALF_VTCLOCK, PCICLKSELREG); - else if ((vr41xx_vtclock / 4) < MAX_PCI_CLOCK) + else if ((vtclock / 4) < MAX_PCI_CLOCK) writel(QUARTER_VTCLOCK, PCICLKSELREG); else printk(KERN_INFO "Warning: PCI Clock is over 33MHz.\n"); From macro@ds2.pg.gda.pl Tue Feb 3 15:11:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:11:45 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:47066 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:11:44 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 4AE6A47823; Tue, 3 Feb 2004 16:11:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 3F4064781E; Tue, 3 Feb 2004 16:11:43 +0100 (CET) Date: Tue, 3 Feb 2004 16:11:43 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [patch] pg-r4k.c cp0 hazards for R4000/R4400 In-Reply-To: <20040202150806.GA27819@linux-mips.org> Message-ID: References: <20040202150806.GA27819@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Mon, 2 Feb 2004, Ralf Baechle wrote: > > The R4000/R4400 has a coprocessor 0 hazard when a P-cache operation is > > less than two non-load, non-cache instructions apart from a store to the > > same line. For processors without a secondary cache, the code in pg-r4k.c > > currently issues a Create Dirty Exclusive D-cache operation and then > > immediately executes consecutive stores to the same line, therefore > > fulfilling the conditions for the hazard. > > The wording is "There must be two non-load, non-CACHE instructions between > a store and a CACHE instruction directed to the same primary cache line as > the store." My interpretation of that is the problem only exists if a > store instruction is followed by a cache instruction, not if the > cache instruction is followed by the store? I've not found any hints in > the manual to verify or falsify this theory. In case you're right we've I'm pretty sure the hazard is in both directions -- why? Because it's marked both in the "CP0 Data Used, Stage Used" and the "CP0 Data Written, Stage Available" column. I interpret that as a requirement for the CACHE instructions to "start using data" two instructions ahead and "finish writing data" two instructions after itself. If your assumption was true, I'd put the marking only in the former column. Of course that does not mean the table is correct, but I'd assume so, for safety, if not anything else. > violated this hazard since almost beginning of the time, see > http://www.linux-mips.org/cvsweb/linux/arch/mips/mm/Attic/pg-r4k.S?rev=1.9 > and I've not heared of any problems arising from this. Perhaps it wasn't really tested. Have you ever run the code on a PC variant? Has anyone else? > Any DECstations using the R4[04]00PC CPU variant? None. That would normally be a downgrade in memory throughput as the R2k/R3k DECstations used to have 64kB of I-cache + 64kB of D-cache, typically, and sometimes (with the 33MHz variant) even 128kB of D-cache. > > but > > currently I'd like to apply this change to assure correct operation. As I > > have no non-SC R4000/R4400 system, this was untested, but perhaps studying > > the problem covered by the -scache patch sent previously will show if the > > hazard is indeed avoided. > > Have you actually been hit by that hazard? I suppose so -- without the "mips-pg-r4k-scache" patch my system is very unstable and the difference is essentially that in addition to Create_Dirty_Excl_SD there are additional Create_Dirty_Excl_D ones, that, apart from being a performance hit, shouldn't have any effect. I have to investigate it further yet. > > OK to apply? > > Most of your changes conflict with my fixes, so I guess that need redoing ... I can see you've already resolved a few problems -- I'll check if any remained. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Tue Feb 3 15:16:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:16:31 +0000 (GMT) Received: from p508B78F8.dip.t-dialin.net ([IPv6:::ffff:80.139.120.248]:58964 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:16:30 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13FGPex000789; Tue, 3 Feb 2004 16:16:25 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13FGPZV000788; Tue, 3 Feb 2004 16:16:25 +0100 Date: Tue, 3 Feb 2004 16:16:25 +0100 From: Ralf Baechle To: "Smith, Todd" Cc: "'linux-mips@linux-mips.org'" Subject: Re: MIPS Kernel size Message-ID: <20040203151625.GB27848@linux-mips.org> References: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.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: 4254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 04:48:43PM -0500, Smith, Todd wrote: > I like the idea of the -tiny tree and I hope that these changes get merged > back into the main kernel tree. One of Linux's historic advantages is that > it can run on older equipment but the trend seems to be supporting only > current equipment Remember Linux development is user driven. If you think it doesn't run well enough on your small system then it's time to heat up your C compiler :-) Ralf From ralf@linux-mips.org Tue Feb 3 15:17:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:17:45 +0000 (GMT) Received: from p508B78F8.dip.t-dialin.net ([IPv6:::ffff:80.139.120.248]:61268 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:17:44 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13FHfex000822; Tue, 3 Feb 2004 16:17:41 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13FHeXc000821; Tue, 3 Feb 2004 16:17:40 +0100 Date: Tue, 3 Feb 2004 16:17:40 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Smith, Todd" , "'linux-mips@linux-mips.org'" Subject: Re: MIPS Kernel size Message-ID: <20040203151740.GC27848@linux-mips.org> References: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.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: 4255 X-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, Feb 03, 2004 at 02:41:09PM +0100, Maciej W. Rozycki wrote: > > I like the idea of the -tiny tree and I hope that these changes get merged > > back into the main kernel tree. One of Linux's historic advantages is that > > it can run on older equipment but the trend seems to be supporting only > > current equipment > > I beg your pardon, but isn't the DECstation old enough? Somehow I'm just sitting in front of two Linux 2.6-supported desktops that are running pretty well :-) Ralf From ralf@linux-mips.org Tue Feb 3 15:18:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:18:45 +0000 (GMT) Received: from p508B78F8.dip.t-dialin.net ([IPv6:::ffff:80.139.120.248]:63060 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:18:44 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13FIhex000857 for ; Tue, 3 Feb 2004 16:18:43 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13FIhh2000856 for linux-mips@linux-mips.org; Tue, 3 Feb 2004 16:18:43 +0100 Date: Tue, 3 Feb 2004 16:18:43 +0100 From: Ralf Baechle To: "'linux-mips@linux-mips.org'" Subject: Re: MIPS Kernel size Message-ID: <20040203151843.GD27848@linux-mips.org> References: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> <20040203145014.GK28571@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040203145014.GK28571@lug-owl.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: 4256 X-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, Feb 03, 2004 at 03:50:14PM +0100, Jan-Benedict Glaw wrote: > > I like the idea of the -tiny tree and I hope that these changes get merged > > back into the main kernel tree. One of Linux's historic advantages is that > > it can run on older equipment but the trend seems to be supporting only > > current equipment > > It's even running on VAXen. But I admit that I like having more than 8MB > of RAM, though... At least that explains why you say you don't need heating :-) Ralf From Todd.Smith@camc.org Tue Feb 3 15:20:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:20:34 +0000 (GMT) Received: from hnet1.camc.org ([IPv6:::ffff:206.193.127.2]:17216 "EHLO mail2.camcare.com") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:20:33 +0000 Received: from KES.camcare.com (hnet1.camc.org [206.193.127.2]) by mail2.camcare.com (Postfix) with ESMTP id 83E356C9F for ; Tue, 3 Feb 2004 11:14:12 -0500 (EST) Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Feb 2004 10:20:29 -0500 Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A569564@KES.camcare.com> From: "Smith, Todd" To: "'linux-mips@linux-mips.org'" Subject: RE:MIPS Kernel size Date: Tue, 3 Feb 2004 10:20:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Todd.Smith@camc.org Precedence: bulk X-list: linux-mips Hello Maciej, Pardon me since I didn't clarify my last sentence very well. The trend in mainstream x86 Linux seems to be to support only newer equipment. The DECstation is certainly old enough to qualify as legacy equipment. Todd Smith From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl] >I beg your pardon, but isn't the DECstation old enough? From seo_tmi@charter.net Tue Feb 3 15:22:26 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:22:26 +0000 (GMT) Received: from mxsf16.cluster1.charter.net ([IPv6:::ffff:209.225.28.216]:40709 "EHLO mxsf16.cluster1.charter.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:22:26 +0000 Received: from tseo ([68.114.28.136]) by mxsf16.cluster1.charter.net (8.12.10/8.12.8) with SMTP id i13FI5F3049583 for ; Tue, 3 Feb 2004 10:18:07 -0500 (EST) (envelope-from seo_tmi@charter.net) From: "Toshio Seo" To: "Linux-Mips" Subject: Starter questions Date: Tue, 3 Feb 2004 10:15:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_01C3EA3E.B1B4BD70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-MS-TNEF-Correlator: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: seo_tmi@charter.net Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C3EA3E.B1B4BD70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I am a bit new to Linux MIPS but I would really appreciate a few pointers. 1. I am getting GCC 3.3.2, binutils-2.14..... and GLIB-2.3.2 off of Kernel.org. Is there a source of patches for these to make a clean MIPS64 and N32 build? 2. Are there any ioctl() examples for displaying and modifying processor registers from user programs? Thanks Toshio --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.573 / Virus Database: 363 - Release Date: 1/28/2004 ------=_NextPart_000_0009_01C3EA3E.B1B4BD70 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjAPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHAgADAAoADgAAAAIA+gAB A5AGAMgGAAAkAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAEgAAAFN0YXJ0ZXIgcXVlc3Rpb25zAAAAAgFxAAEAAAAWAAAAAcPqaHc0qN+gly8sQDS6DV1u 5W6cyQAAAgEdDAEAAAAZAAAAU01UUDpTRU9fVE1JQENIQVJURVIuTkVUAAAAAAsAAQ4AAAAAQAAG DgCsw1lo6sMBAgEKDgEAAAAYAAAAAAAAABRtoedp2XZAoUldXSIG/zTCgAAACwAfDgEAAAACAQkQ AQAAAIwCAACIAgAARQMAAExaRnXEBDODAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBj aArAc/BldDAgBxMCgwBQBFV/EMkIVQeyAoMOUBBvEXV9JQqBdgiQd2sLgGQ0HQxgYwBQCwMLtSBI aQ4sCqIKhAqASSBhbVEY4CBiaQVAbgfRdEhvIEwLgHV4BdBJslAF8GJ1BUAY0HcIYJhsZCAJcAdA bHkY4JRwcAlwYwcwdGUZEXJmB9FwbwuAHFAREC5ZGBoxLhrRGPFnETB0AQuAZyBHQ0MgM3IuH3Ay LBkxGhAe4GyAcy0yLjE0LiCyxxjgFpAfIExJQiBhH5FMIG8BICHxIEsEkWV0bC4FsGceQBrQBCB0 1mgEkBxicwhhYxxgIkH9CrB0EOAHkQIQBcAjcREgyxmyAMBrHGJjbBtwA6DJGlI2NCEDTjMh4Bqg +QMQZD8YFCBwEWElkSOEAm4bsGlvY3RsKHApIGV4GPALUCTlZPsEAAtReR7yIRIEYQaQKyO/G/Ap gAeQI/AFwAlwZwQA5x0iHJADYSB1ESAFwCxRWwnAGPBzJ/UYFFQQ8G4OaxTAGCcbQFRvc2j/KXAY FQBBGCMwJQtGFFIXsdMAAAsOMTgDMGwLgBxg1i01ADSkTxqwZxzxHxC/AMADEQQAJkAEkB7gZgiQ kRtAVmlyLeAgRgnRax1gNLNDI4BjJgAbQGKxG7BBVkchAR7gLRYwmTdic3ktMRkAKGgCQKBwOi8v dzrgLgnAkwQAIgB0LgWgbSk35QZWHTEpcG46IDYugDAuNTczIC83NTZEHEABoGERIDzAMzb9PUAt B/AisBtwJYE94T5RkDEvMjg/0DAwFrApNLMgfRgUfUFAAwAAfAUAAAALAAGACCAGAAAAAADAAAAA AAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAmgAggBgAA AAAAwAAAAAAAAEYAAAAAUoUAAHN5AQALADOACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMA NYAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA2gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUA AAAAAAADAFyACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAB4Aa4AIIAYAAAAAAMAAAAAAAABG AAAAAFSFAAABAAAABAAAADkuMAALAGyACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsAh4AI IAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAAwAGgUAJs2c1O9IRpZUAIBhki6cBAAAAIAAAAEEA VgBHACAARgBMAEEARwBTACAAKABPAFUAVAApAAAAAAAAAwIB+A8BAAAAEAAAABRtoedp2XZAoUld XSIG/zQCAfoPAQAAABAAAAAUbaHnadl2QKFJXV0iBv80AgH7DwEAAACfAAAAAAAAADihuxAF5RAa obsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRz IGFuZCBTZXR0aW5nc1xBZG1pbmlzdHJhdG9yXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERh dGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QAAAMA/g8FAAAAAwANNP03AAACAX8AAQAA ADMAAAA8SEdFQUtCRUpFSkRBSURPQkpHT05PRUxFQ0FBQS5zZW9fdG1pQGNoYXJ0ZXIubmV0PgAA AwAGEDx9jp4DAAcQngEAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISSxJQU1BQklUTkVX VE9MSU5VWE1JUFNCVVRJV09VTERSRUFMTFlBUFBSRUNJQVRFQUZFV1BPSU5URVJTMUlBTUdFVFRJ TkdHQ0MzMzIsQklOVVRJTFMtMjE0QU5ER0xJQi0yAAAAADqO ------=_NextPart_000_0009_01C3EA3E.B1B4BD70-- From macro@ds2.pg.gda.pl Tue Feb 3 15:30:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:30:40 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:11235 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:30:39 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id AC35847823; Tue, 3 Feb 2004 16:30:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id A0924474C8; Tue, 3 Feb 2004 16:30:33 +0100 (CET) Date: Tue, 3 Feb 2004 16:30:33 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@-mips.org: linux In-Reply-To: <20040202152307.GB28673@linux-mips.org> Message-ID: References: <20040202141939Z8225226-9616+1555@linux-mips.org> <20040202152307.GB28673@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Mon, 2 Feb 2004, Ralf Baechle wrote: > > How do we assure tails of interrupt handlers don't trigger the errata? > > The problem can only be triggered if instructions surrounding the > cacheop use the dcache; exceptions such as interrupts are not relevant. Why? How is an "eret" with its preceding instructions different to other instructions? There may be a data cache miss soon before an "eret" and the response buffer may contain data. And you may get an exeption right before a CACHE instruction. > Which I'm really happy about. Disabling interrupts is a problem in cases > were we can't avoid page faults. I worry this is unsafe and given the unlikeliness of getting an interrupt just between the dummy load and the CACHE instruction, this change creates a completely obscure bug that'll bite unpredictably and possibly invisibly, just corrupting data, every once and then. But the situation may be not that bad -- what does exactly happen when the erratum gets triggered? Missing a Create_Dirty_Excl_D operation should itself be a performance hit only, but given the problems reported I suppose data gets corrupted, either in the cache or in the main memory. Am I right? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From drow@crack.them.org Tue Feb 3 15:35:13 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:35:14 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:33168 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:35:13 +0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Ao2Zx-0007Qe-PZ; Tue, 03 Feb 2004 10:35:09 -0500 Date: Tue, 3 Feb 2004 10:35:09 -0500 From: Daniel Jacobowitz To: Toshio Seo Cc: Linux-Mips Subject: Re: Starter questions Message-ID: <20040203153509.GA28469@nevyn.them.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.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: 4260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Tue, Feb 03, 2004 at 10:15:48AM -0500, Toshio Seo wrote: > Hi, > > I am a bit new to Linux MIPS but I would really appreciate a few pointers. > > 1. I am getting GCC 3.3.2, binutils-2.14..... and GLIB-2.3.2 off of > Kernel.org. Is there a source of patches for these to make a clean MIPS64 > and N32 build? None of those three components supports N32 userspace applications. Binutils 2.14 is pretty close. GCC 3.3.2 won't even configure for mips64-linux. You have to use the bleeding edge tools if you want to build a mips64 userland. > 2. Are there any ioctl() examples for displaying and modifying processor > registers from user programs? > > Thanks > Toshio > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.573 / Virus Database: 363 - Release Date: 1/28/2004 > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From ralf@linux-mips.org Tue Feb 3 15:42:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:42:20 +0000 (GMT) Received: from p508B78F8.dip.t-dialin.net ([IPv6:::ffff:80.139.120.248]:21077 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:42:19 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13FgIex001381; Tue, 3 Feb 2004 16:42:18 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13FgIBn001380; Tue, 3 Feb 2004 16:42:18 +0100 Date: Tue, 3 Feb 2004 16:42:18 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [patch] pg-r4k.c cp0 hazards for R4000/R4400 Message-ID: <20040203154217.GA1018@linux-mips.org> References: <20040202150806.GA27819@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: 4261 X-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, Feb 03, 2004 at 04:11:43PM +0100, Maciej W. Rozycki wrote: > I'm pretty sure the hazard is in both directions -- why? Because it's > marked both in the "CP0 Data Used, Stage Used" and the "CP0 Data Written, > Stage Available" column. I interpret that as a requirement for the CACHE > instructions to "start using data" two instructions ahead and "finish > writing data" two instructions after itself. If your assumption was true, > I'd put the marking only in the former column. Of course that does not > mean the table is correct, but I'd assume so, for safety, if not anything > else. I was just trying to explain why the PC variants used to work fine. > > violated this hazard since almost beginning of the time, see > > http://www.linux-mips.org/cvsweb/linux/arch/mips/mm/Attic/pg-r4k.S?rev=1.9 > > and I've not heared of any problems arising from this. > > Perhaps it wasn't really tested. Have you ever run the code on a PC > variant? Has anyone else? Yes, it has. Olivetti M700-10, around 2.2 or so. The code used at that time in arch/mips/mm/r4xx0.c was not much different from what pg-r4k.c is generating now that is it violates this hazard. > > Any DECstations using the R4[04]00PC CPU variant? > > None. That would normally be a downgrade in memory throughput as the > R2k/R3k DECstations used to have 64kB of I-cache + 64kB of D-cache, > typically, and sometimes (with the 33MHz variant) even 128kB of D-cache. > I suppose so -- without the "mips-pg-r4k-scache" patch my system is very > unstable and the difference is essentially that in addition to > Create_Dirty_Excl_SD there are additional Create_Dirty_Excl_D ones, that, > apart from being a performance hit, shouldn't have any effect. I have to > investigate it further yet. Interesting, I was expecting somewhat better performance from the combination of both. Anyway, what is now in CVS is tested on R4400SC V4.0. Ralf From macro@ds2.pg.gda.pl Tue Feb 3 15:43:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:43:21 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:40938 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:43:21 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 9AE4947823; Tue, 3 Feb 2004 16:43:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 89D3B474C8; Tue, 3 Feb 2004 16:43:19 +0100 (CET) Date: Tue, 3 Feb 2004 16:43:19 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: R4600 V1.7 errata In-Reply-To: <20040203115236.GB28340@linux-mips.org> Message-ID: References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> <20040203113928.GA28340@linux-mips.org> <20040203114252.GA27810@icm.edu.pl> <20040203115236.GB28340@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Tue, 3 Feb 2004, Ralf Baechle wrote: > 2.0 requires different workarounds which are already in place and functional > since quite some time. We still lacking a fix for one important erratum of > the 2.0 but it seems pretty stable without. Well, I can actually see two problems: #4 that is fairly easy to handle and #7 which is painful and which is unfortunately present with the R4700 as well. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Tue Feb 3 15:48:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:48:22 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:35564 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:48:22 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id C97ED47828; Tue, 3 Feb 2004 16:48:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id B754D47823; Tue, 3 Feb 2004 16:48:17 +0100 (CET) Date: Tue, 3 Feb 2004 16:48:17 +0100 (CET) From: "Maciej W. Rozycki" To: "Smith, Todd" Cc: "'linux-mips@linux-mips.org'" Subject: RE:MIPS Kernel size In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A569564@KES.camcare.com> Message-ID: References: <490E0430C3C72046ACF7F18B7CD76A2A569564@KES.camcare.com> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Tue, 3 Feb 2004, Smith, Todd wrote: > Pardon me since I didn't clarify my last sentence very well. The trend in > mainstream x86 Linux seems to be to support only newer equipment. The > DECstation is certainly old enough to qualify as legacy equipment. Well, if I spotted an MP-compliant i486 system, I'd consider getting one as a compatibility testbed for APIC support code. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Tue Feb 3 15:49:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 15:49:37 +0000 (GMT) Received: from p508B78F8.dip.t-dialin.net ([IPv6:::ffff:80.139.120.248]:27989 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 15:49:36 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13FnZex001531; Tue, 3 Feb 2004 16:49:35 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13FnZX8001530; Tue, 3 Feb 2004 16:49:35 +0100 Date: Tue, 3 Feb 2004 16:49:35 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@-mips.org: linux Message-ID: <20040203154935.GB1018@linux-mips.org> References: <20040202141939Z8225226-9616+1555@linux-mips.org> <20040202152307.GB28673@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: 4264 X-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, Feb 03, 2004 at 04:30:33PM +0100, Maciej W. Rozycki wrote: > > > How do we assure tails of interrupt handlers don't trigger the errata? > > > > The problem can only be triggered if instructions surrounding the > > cacheop use the dcache; exceptions such as interrupts are not relevant. > > Why? How is an "eret" with its preceding instructions different to other > instructions? There may be a data cache miss soon before an "eret" and > the response buffer may contain data. And you may get an exeption right > before a CACHE instruction. > > > Which I'm really happy about. Disabling interrupts is a problem in cases > > were we can't avoid page faults. > > I worry this is unsafe and given the unlikeliness of getting an interrupt > just between the dummy load and the CACHE instruction, this change creates > a completely obscure bug that'll bite unpredictably and possibly > invisibly, just corrupting data, every once and then. But the situation > may be not that bad -- what does exactly happen when the erratum gets > triggered? Missing a Create_Dirty_Excl_D operation should itself be a > performance hit only, but given the problems reported I suppose data gets > corrupted, either in the cache or in the main memory. Am I right? I don't know details but since the person who answered my question was directly working on the CPU design I have to take that as authoritative information and after all, the systems seems stable. Daring a guess, the CPU restarts the pipeline following an eret therefore instructions preceeding the eret can't cause the problem. Ralf From macro@ds2.pg.gda.pl Tue Feb 3 16:03:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 16:03:35 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:55441 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 16:03:34 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 1933E47823; Tue, 3 Feb 2004 17:03:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 07B47474C8; Tue, 3 Feb 2004 17:03:30 +0100 (CET) Date: Tue, 3 Feb 2004 17:03:29 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [patch] pg-r4k.c cp0 hazards for R4000/R4400 In-Reply-To: <20040203154217.GA1018@linux-mips.org> Message-ID: References: <20040202150806.GA27819@linux-mips.org> <20040203154217.GA1018@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Tue, 3 Feb 2004, Ralf Baechle wrote: > > Perhaps it wasn't really tested. Have you ever run the code on a PC > > variant? Has anyone else? > > Yes, it has. Olivetti M700-10, around 2.2 or so. The code used at that > time in arch/mips/mm/r4xx0.c was not much different from what pg-r4k.c is > generating now that is it violates this hazard. OK then. > > I suppose so -- without the "mips-pg-r4k-scache" patch my system is very > > unstable and the difference is essentially that in addition to > > Create_Dirty_Excl_SD there are additional Create_Dirty_Excl_D ones, that, > > apart from being a performance hit, shouldn't have any effect. I have to > > investigate it further yet. > > Interesting, I was expecting somewhat better performance from the > combination of both. Anyway, what is now in CVS is tested on R4400SC V4.0. After rereading the description I agree with you, so I am going to get at the code again soon. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Tue Feb 3 16:05:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 16:05:21 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:54164 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 16:05:20 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id D7F6047828; Tue, 3 Feb 2004 17:04:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 32657474C8; Tue, 3 Feb 2004 17:04:44 +0100 (CET) Date: Tue, 3 Feb 2004 17:04:44 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@-mips.org: linux In-Reply-To: <20040203154935.GB1018@linux-mips.org> Message-ID: References: <20040202141939Z8225226-9616+1555@linux-mips.org> <20040202152307.GB28673@linux-mips.org> <20040203154935.GB1018@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Tue, 3 Feb 2004, Ralf Baechle wrote: > I don't know details but since the person who answered my question was > directly working on the CPU design I have to take that as authoritative > information and after all, the systems seems stable. OK then. > Daring a guess, the CPU restarts the pipeline following an eret therefore > instructions preceeding the eret can't cause the problem. That's possible. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Tue Feb 3 16:12:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 16:12:05 +0000 (GMT) Received: from p508B78F8.dip.t-dialin.net ([IPv6:::ffff:80.139.120.248]:49237 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 16:12:04 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13GC2ex002026; Tue, 3 Feb 2004 17:12:02 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13GC2ks002025; Tue, 3 Feb 2004 17:12:02 +0100 Date: Tue, 3 Feb 2004 17:12:02 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: R4600 V1.7 errata Message-ID: <20040203161202.GC1018@linux-mips.org> References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> <20040203113928.GA28340@linux-mips.org> <20040203114252.GA27810@icm.edu.pl> <20040203115236.GB28340@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: 4267 X-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, Feb 03, 2004 at 04:43:19PM +0100, Maciej W. Rozycki wrote: > > 2.0 requires different workarounds which are already in place and functional > > since quite some time. We still lacking a fix for one important erratum of > > the 2.0 but it seems pretty stable without. > > Well, I can actually see two problems: #4 that is fairly easy to handle > and #7 which is painful and which is unfortunately present with the R4700 > as well. If #7 would only affect the R4700 the world would peachy ... To my knowledge the dusty box here in a corner is the only R4700 that ever ran Linux ... Under a different bug number this bug also affects the R4600 V1.x; it's fixed in post-2.0 R4600 (which all identify as 2.0) and post-1.1 R4700. Since a workaround may be a bit performance sensitive I think I'll try if it can be probed for reliably. Ralf From macro@ds2.pg.gda.pl Tue Feb 3 16:20:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 16:20:20 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:50076 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 16:20:20 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 658564C39F; Tue, 3 Feb 2004 17:20:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 41DBC474C8; Tue, 3 Feb 2004 17:20:18 +0100 (CET) Date: Tue, 3 Feb 2004 17:20:18 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: R4600 V1.7 errata In-Reply-To: <20040203161202.GC1018@linux-mips.org> Message-ID: References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> <20040203113928.GA28340@linux-mips.org> <20040203114252.GA27810@icm.edu.pl> <20040203115236.GB28340@linux-mips.org> <20040203161202.GC1018@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Tue, 3 Feb 2004, Ralf Baechle wrote: > Under a different bug number this bug also affects the R4600 V1.x; it's > fixed in post-2.0 R4600 (which all identify as 2.0) and post-1.1 R4700. > Since a workaround may be a bit performance sensitive I think I'll try if > it can be probed for reliably. The conditions appear clear, so they may be quite easy to reproduce for the erratum to trigger. I guess you may take the optimization hint from the document into account as well. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From jbglaw@dvmwest.gt.owl.de Tue Feb 3 16:52:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 16:52:27 +0000 (GMT) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:45510 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 16:52:27 +0000 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 19C734B4C6; Tue, 3 Feb 2004 17:52:26 +0100 (CET) Date: Tue, 3 Feb 2004 17:52:26 +0100 From: Jan-Benedict Glaw To: "'linux-mips@linux-mips.org'" Subject: Re: MIPS Kernel size Message-ID: <20040203165225.GL28571@lug-owl.de> Mail-Followup-To: "'linux-mips@linux-mips.org'" References: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> <20040203145014.GK28571@lug-owl.de> <20040203151843.GD27848@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jtcAeju3WzRmRF+o" Content-Disposition: inline In-Reply-To: <20040203151843.GD27848@linux-mips.org> 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.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4269 X-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 --jtcAeju3WzRmRF+o Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2004-02-03 16:18:43 +0100, Ralf Baechle wrote in message <20040203151843.GD27848@linux-mips.org>: > On Tue, Feb 03, 2004 at 03:50:14PM +0100, Jan-Benedict Glaw wrote: > > > I like the idea of the -tiny tree and I hope that these changes get m= erged > > > back into the main kernel tree. One of Linux's historic advantages i= s that > > > it can run on older equipment but the trend seems to be supporting on= ly > > > current equipment > > It's even running on VAXen. But I admit that I like having more than 8MB > > of RAM, though... >=20 > At least that explains why you say you don't need heating :-) Oh, not really :) It's all desktop sized and "only" sucks off a regular V.230 line... 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)); --jtcAeju3WzRmRF+o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAH9HJHb1edYOZ4bsRAqJZAKCCwilCa038LOhqV+4sbs9QgPrWggCgijx1 9lQMzr3ZmlIW3r1h/fZAeQ0= =s398 -----END PGP SIGNATURE----- --jtcAeju3WzRmRF+o-- From ralf@linux-mips.org Tue Feb 3 17:07:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 17:07:18 +0000 (GMT) Received: from p508B78F8.dip.t-dialin.net ([IPv6:::ffff:80.139.120.248]:34390 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 17:07:17 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i13H7Gex003155 for ; Tue, 3 Feb 2004 18:07:16 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i13H7GMH003154 for linux-mips@linux-mips.org; Tue, 3 Feb 2004 18:07:16 +0100 Date: Tue, 3 Feb 2004 18:07:16 +0100 From: Ralf Baechle To: "'linux-mips@linux-mips.org'" Subject: Re: MIPS Kernel size Message-ID: <20040203170716.GA2794@linux-mips.org> References: <490E0430C3C72046ACF7F18B7CD76A2A56955E@KES.camcare.com> <20040203145014.GK28571@lug-owl.de> <20040203151843.GD27848@linux-mips.org> <20040203165225.GL28571@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040203165225.GL28571@lug-owl.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: 4270 X-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, Feb 03, 2004 at 05:52:26PM +0100, Jan-Benedict Glaw wrote: > > At least that explains why you say you don't need heating :-) > > Oh, not really :) It's all desktop sized and "only" sucks off a regular > V.230 line... CCITT V.230, "General data communications interface, layer 1" ;-) Ralf From savages@savages.net Tue Feb 3 21:32:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 21:32:52 +0000 (GMT) Received: from savages.net ([IPv6:::ffff:12.154.202.18]:56315 "EHLO savages.net") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 21:32:52 +0000 Received: from savages.net ([::ffff:192.168.4.181]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by server with esmtp; Tue, 03 Feb 2004 13:32:46 -0800 Message-ID: <4020137E.9020005@savages.net> Date: Tue, 03 Feb 2004 13:32:46 -0800 From: Shaun Savage User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: dietlibc nash pic/non-pic errors X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 4271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: savages@savages.net Precedence: bulk X-list: linux-mips Hi I am want to cross compile dietlibc and nash(mkinitrd). I can cross compile static mipsel dietlibc libs but when I try to link it with nash I get the pic and non-pic error, can't merge I have gotten QPDF, SD on linux, busybox and ulibc cross compiled and working, so I sort of know what I am doing. I am using Maciej toolchain any help? shaun From js@convergence.de Tue Feb 3 22:57:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Feb 2004 22:57:45 +0000 (GMT) Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:21223 "EHLO mail.convergence.de") by linux-mips.org with ESMTP id ; Tue, 3 Feb 2004 22:57:45 +0000 Received: from pd9e71b79.dip.t-dialin.net ([217.231.27.121] helo=abc.local) by mail.convergence.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1Ao9SW-0003v4-JV for linux-mips@linux-mips.org; Tue, 03 Feb 2004 23:55:56 +0100 Received: from js by abc.local with local (Exim 3.35 #1 (Debian)) id 1Ao9WT-00013d-00 for ; Wed, 04 Feb 2004 00:00:01 +0100 Date: Wed, 4 Feb 2004 00:00:01 +0100 From: Johannes Stezenbach To: linux-mips@linux-mips.org Subject: Re: dietlibc nash pic/non-pic errors Message-ID: <20040203230001.GB1667@convergence.de> Mail-Followup-To: Johannes Stezenbach , linux-mips@linux-mips.org References: <4020137E.9020005@savages.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4020137E.9020005@savages.net> User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@convergence.de Precedence: bulk X-list: linux-mips Shaun Savage wrote: > I am want to cross compile dietlibc and nash(mkinitrd). > > I can cross compile static mipsel dietlibc libs > but when I try to link it with nash I get > the pic and non-pic error, can't merge > > I have gotten QPDF, SD on linux, busybox and ulibc cross compiled and > working, so I sort of know what I am doing. > > I am using Maciej toolchain - check that everything is compiled with '-fno-pic -mno-abicalls -G 0' - you must have either a non-pic libgcc or make sure your programs don't need libgcc The standard configuration of gcc for mipsel-linux creates a PIC libgcc only, so if you need a non-pic libgcc you must hack the gcc configuration and rebuild your toolchain. Or alternatively you can compile dietlibc as PIC (remove '-fno-pic -mno-abicalls' from mips/Makefile.add and diet.c). HTH, Johannes From juszczec@hotmail.com Wed Feb 4 13:36:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2004 13:36:45 +0000 (GMT) Received: from law10-f113.law10.hotmail.com ([IPv6:::ffff:64.4.15.113]:29188 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Wed, 4 Feb 2004 13:36:44 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Feb 2004 05:36:37 -0800 Received: from 63.121.54.5 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 04 Feb 2004 13:36:37 GMT X-Originating-IP: [63.121.54.5] X-Originating-Email: [juszczec@hotmail.com] X-Sender: juszczec@hotmail.com From: "Mark and Janice Juszczec" To: linux-mips@linux-mips.org Subject: FW: Ecartis command results: No commands found Date: Wed, 04 Feb 2004 13:36:37 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2004 13:36:37.0773 (UTC) FILETIME=[E9F053D0:01C3EB23] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: juszczec@hotmail.com Precedence: bulk X-list: linux-mips Hi folks What does -msoft-float do on the r3912 processesor? Some programs I cross compile must have it specified, others don't. I can't figure out why. Mark _________________________________________________________________ Let the new MSN Premium Internet Software make the most of your high-speed experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 From rathann@icm.edu.pl Wed Feb 4 15:48:13 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2004 15:48:14 +0000 (GMT) Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:6200 "EHLO atol.icm.edu.pl") by linux-mips.org with ESMTP id ; Wed, 4 Feb 2004 15:48:13 +0000 Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132]) by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i14Fm2sW019777 for ; Wed, 4 Feb 2004 16:48:02 +0100 (CET) Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian)) id 1AoPFy-0000DK-00 for ; Wed, 04 Feb 2004 16:48:02 +0100 Date: Wed, 4 Feb 2004 16:48:02 +0100 From: "Dominik 'Rathann' Mierzejewski" To: linux-mips@linux-mips.org Subject: Re: R4600 V1.7 errata Message-ID: <20040204154801.GB704@icm.edu.pl> Mail-Followup-To: linux-mips@linux-mips.org References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> <20040203113928.GA28340@linux-mips.org> <20040203114252.GA27810@icm.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040203114252.GA27810@icm.edu.pl> User-Agent: Mutt/1.3.28i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rathann@icm.edu.pl Precedence: bulk X-list: linux-mips On Tue, Feb 03, 2004 at 12:42:53PM +0100, Dominik 'Rathann' Mierzejewski wrote: [...] > I assume it's safe to test it now? I'll build it for my R4600 V2.0 and > report in a while. Stay tuned. Works now. Thanks, guys. -- Dominik 'Rathann' Mierzejewski Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810 From ppopov@mvista.com Wed Feb 4 15:59:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2004 15:59:52 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:11251 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Wed, 4 Feb 2004 15:59:51 +0000 Received: from [10.2.2.20] (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id HAA24476; Wed, 4 Feb 2004 07:59:49 -0800 Subject: Re: R4600 V1.7 errata From: Pete Popov To: Ralf Baechle Cc: Linux/MIPS Development In-Reply-To: <20040204154801.GB704@icm.edu.pl> References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> <20040203113928.GA28340@linux-mips.org> <20040203114252.GA27810@icm.edu.pl> <20040204154801.GB704@icm.edu.pl> Content-Type: text/plain Organization: Message-Id: <1075910389.1170.42.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 04 Feb 2004 07:59:49 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4275 X-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 Wed, 2004-02-04 at 07:48, Dominik 'Rathann' Mierzejewski wrote: > On Tue, Feb 03, 2004 at 12:42:53PM +0100, Dominik 'Rathann' Mierzejewski wrote: > [...] > > I assume it's safe to test it now? I'll build it for my R4600 V2.0 and > > report in a while. Stay tuned. > > Works now. Thanks, guys. The latest cache updates break the Au1x kernel. I don't know yet exactly what the problem is, but I tested with a snapshot before and after the updates. Pete From ralf@linux-mips.org Wed Feb 4 20:04:49 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2004 20:04:49 +0000 (GMT) Received: from p508B6AA4.dip.t-dialin.net ([IPv6:::ffff:80.139.106.164]:42762 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 4 Feb 2004 20:04:49 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i14K4Vex020264; Wed, 4 Feb 2004 21:04:31 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i14K4N0i020263; Wed, 4 Feb 2004 21:04:23 +0100 Date: Wed, 4 Feb 2004 21:04:23 +0100 From: Ralf Baechle To: Pete Popov Cc: Linux/MIPS Development Subject: Re: R4600 V1.7 errata Message-ID: <20040204200423.GA20197@linux-mips.org> References: <20040129102215.GC17760@ballina> <4018E322.9030801@gentoo.org> <20040131030435.GA24228@linux-mips.org> <20040131141027.GA11048@ballina> <20040201045258.GA4601@linux-mips.org> <20040203113928.GA28340@linux-mips.org> <20040203114252.GA27810@icm.edu.pl> <20040204154801.GB704@icm.edu.pl> <1075910389.1170.42.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1075910389.1170.42.camel@localhost.localdomain> 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: 4276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 04, 2004 at 07:59:49AM -0800, Pete Popov wrote: > > [...] > > > I assume it's safe to test it now? I'll build it for my R4600 V2.0 and > > > report in a while. Stay tuned. > > > > Works now. Thanks, guys. > > The latest cache updates break the Au1x kernel. I don't know yet exactly > what the problem is, but I tested with a snapshot before and after the > updates. The cache updates should specifically only affects systems that explicitly enable the cache workaround in ; for any other the compiler should totally eleminate the workaround from the binary. Therefore my first guess would be pg-r4k.c. Ralf From vprashant@echelon.com Wed Feb 4 22:46:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2004 22:46:30 +0000 (GMT) Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:64776 "HELO [205.229.50.10]") by linux-mips.org with SMTP id ; Wed, 4 Feb 2004 22:46:30 +0000 Received: from miles.echelon.com by [205.229.50.10] via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 4 Feb 2004 22:46:29 UT Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 14:42:21 -0800 Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB59383A13@miles.echelon.com> From: Prashant Viswanathan To: "'linux-mips@linux-mips.org'" Subject: configuring console to use a different UART Date: Wed, 4 Feb 2004 14:42:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vprashant@echelon.com Precedence: bulk X-list: linux-mips Hi, How can I change the kernel so that it uses the UART I specify for the console instead of the first available one? I dont want to pass this on the bootline but want to compile this into vmlinux. Thanks Prashant From jsun@mvista.com Wed Feb 4 23:01:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2004 23:01:09 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:40696 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 4 Feb 2004 23:01:07 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id i14N14L04569; Wed, 4 Feb 2004 15:01:04 -0800 Date: Wed, 4 Feb 2004 15:01:04 -0800 From: Jun Sun To: Prashant Viswanathan Cc: "'linux-mips@linux-mips.org'" , jsun@mvista.com Subject: Re: configuring console to use a different UART Message-ID: <20040204150104.G26726@mvista.com> References: <5375D9FB1CC3994D9DCBC47C344EEB59383A13@miles.echelon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5375D9FB1CC3994D9DCBC47C344EEB59383A13@miles.echelon.com>; from vprashant@echelon.com on Wed, Feb 04, 2004 at 02:42:13PM -0800 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4278 X-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 Wed, Feb 04, 2004 at 02:42:13PM -0800, Prashant Viswanathan wrote: > Hi, > > How can I change the kernel so that it uses the UART I specify for the > console instead of the first available one? I dont want to pass this on the > bootline but want to compile this into vmlinux. > With 2.6, set CONFIG_CMDLINE with something like: console=ttyS1,38400 With 2.4, add (strcpy or strcat) the above string to your arcs_cmdline defined by your specific board code. Jun From jsun@mvista.com Wed Feb 4 23:08:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2004 23:08:23 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:35317 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 4 Feb 2004 23:08:22 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id i14N8KK04592; Wed, 4 Feb 2004 15:08:20 -0800 Date: Wed, 4 Feb 2004 15:08:20 -0800 From: Jun Sun To: linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree Message-ID: <20040204150820.H26726@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4279 X-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 I wrote a CVS tracking tool that tracks CVS changes in patch format and present them with a web interface. It is now set up to track linux-mips.org tree at the following place. Enjoy. http://www.linux-mips.org/xcvs/linux-mips BTW, if you use this tool for tracking other trees, please drop me a note. Of course, I also like to have more developers to participate. Please join us at http://xcvs.sf.net Jun From vprashant@echelon.com Wed Feb 4 23:42:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2004 23:42:43 +0000 (GMT) Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:25103 "HELO [205.229.50.10]") by linux-mips.org with SMTP id ; Wed, 4 Feb 2004 23:42:42 +0000 Received: from miles.echelon.com by [205.229.50.10] via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 4 Feb 2004 23:42:42 UT Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 15:38:33 -0800 Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB59383A14@miles.echelon.com> From: Prashant Viswanathan To: Prashant Viswanathan Cc: "'linux-mips@linux-mips.org'" Subject: loading kernel via EJTAG interface Date: Wed, 4 Feb 2004 15:38:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vprashant@echelon.com Precedence: bulk X-list: linux-mips Hi, I am trying to load a linux kernel through a EJTAG device. I was told that I should modify the kernel so that it doesnt attempt to use the parameters passed to it by the loader. However, I am not quite sure as to what it means and what exactly one has to do. I would really appreciate any pointers/help/suggestions. Thanks! Prashant From savages@savages.net Thu Feb 5 00:15:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 00:15:42 +0000 (GMT) Received: from savages.net ([IPv6:::ffff:12.154.202.18]:37118 "EHLO savages.net") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 00:15:41 +0000 Received: from savages.net (ws20.savages.net [::ffff:192.168.4.20]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by server with esmtp; Wed, 04 Feb 2004 16:15:37 -0800 Message-ID: <40218B29.8010803@savages.net> Date: Wed, 04 Feb 2004 16:15:37 -0800 From: Shaun Savage User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prashant Viswanathan CC: "'linux-mips@linux-mips.org'" Subject: Re: loading kernel via EJTAG interface References: <5375D9FB1CC3994D9DCBC47C344EEB59383A14@miles.echelon.com> In-Reply-To: <5375D9FB1CC3994D9DCBC47C344EEB59383A14@miles.echelon.com> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 4281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: savages@savages.net Precedence: bulk X-list: linux-mips Prashant Viswanathan wrote: > Hi, > > I am trying to load a linux kernel through a EJTAG device. I was told that I > should modify the kernel so that it doesnt attempt to use the parameters > passed to it by the loader. However, I am not quite sure as to what it means > and what exactly one has to do. I would really appreciate any > pointers/help/suggestions. > > Thanks! > Prashant > > Ouch! The best way would be to load a bootloader that knows about bootp and TFTP. Then do a network boot. If you dont't have a ethernet connection on the board then in /arch/mips/kernel/head.S is where the loader info is read into the kernel. But I am sure there is a better way. shaun From ndf@ghs.com Thu Feb 5 00:36:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 00:36:30 +0000 (GMT) Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:6637 "EHLO eta.ghs.com") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 00:36:29 +0000 Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233]) by eta.ghs.com (8.12.10/8.12.10) with ESMTP id i150aQOI022184; Wed, 4 Feb 2004 16:36:26 -0800 (PST) Received: from zcar.ghs.com (zcar.ghs.com [192.67.158.60]) by blaze.ghs.com (8.12.9/8.12.9) with ESMTP id i150aOBe029052; Wed, 4 Feb 2004 16:36:24 -0800 (PST) Date: Wed, 4 Feb 2004 16:36:24 -0800 (PST) From: Nathan Field To: Shaun Savage cc: Prashant Viswanathan , "'linux-mips@linux-mips.org'" Subject: Re: loading kernel via EJTAG interface In-Reply-To: <40218B29.8010803@savages.net> 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: 4282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ndf@ghs.com Precedence: bulk X-list: linux-mips > > I am trying to load a linux kernel through a EJTAG device. I was told > > that I should modify the kernel so that it doesnt attempt to use the > > parameters passed to it by the loader. However, I am not quite sure as > > to what it means and what exactly one has to do. I would really > > appreciate any pointers/help/suggestions. One approach is to create some sort of setup script that "emulates" the boot loader. I've done that for a Malta board (which uses a boot loader called YAMON). Basically it does something like this: reset and run the board sleep for 7 seconds to let YAMON do its normal setup halt the board do all the setup that YAMON would do when it runs a program That last step is where the magic happens. Basically I do things like setup various registers to point to memory regions, and then in those regions create arrays of pointers, which point to strings containing things like the "environment" that YAMON fills in for programs and arguments that it passes. Depending on the capabilities of your debugging environment this can either be easy or hard. My setup is really nice, downloads for small kernels take about the same time as going through tftp, but bigger kernels with a ramdisk are actually faster to push through EJTAG, which is nice :) nathan > > > > Thanks! > > Prashant > > > > > Ouch! The best way would be to load a bootloader that knows about bootp > and TFTP. Then do a network boot. > > If you dont't have a ethernet connection on the board then in > /arch/mips/kernel/head.S is where the loader info is read into the kernel. > > But I am sure there is a better way. > > shaun > > > > -- Nathan Field (ndf@ghs.com) All gone. But the trouble with analogies is that analogies are like goldfish: sometimes they have nothing to do with the topic at hand. -- Crispin (from a posting to the Bugtraq mailing list) From vprashant@echelon.com Thu Feb 5 00:48:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 00:48:35 +0000 (GMT) Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:5645 "HELO [205.229.50.10]") by linux-mips.org with SMTP id ; Thu, 5 Feb 2004 00:48:35 +0000 Received: from miles.echelon.com by [205.229.50.10] via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 5 Feb 2004 00:48:34 UT Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 16:44:25 -0800 Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB59383A16@miles.echelon.com> From: Prashant Viswanathan To: 'Nathan Field' , Shaun Savage Cc: "'linux-mips@linux-mips.org'" Subject: RE: loading kernel via EJTAG interface Date: Wed, 4 Feb 2004 16:44:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vprashant@echelon.com Precedence: bulk X-list: linux-mips > -----Original Message----- > From: Nathan Field [mailto:ndf@ghs.com] > Sent: Wednesday, February 04, 2004 4:36 PM > To: Shaun Savage > Cc: Prashant Viswanathan; 'linux-mips@linux-mips.org' > Subject: Re: loading kernel via EJTAG interface > > > > > I am trying to load a linux kernel through a EJTAG > device. I was told > > > that I should modify the kernel so that it doesnt attempt > to use the > > > parameters passed to it by the loader. However, I am not > quite sure as > > > to what it means and what exactly one has to do. I would really > > > appreciate any pointers/help/suggestions. > One approach is to create some sort of setup script that > "emulates" the boot loader. I've done that for a Malta board > (which uses a > boot loader called YAMON). Basically it does something like this: > > reset and run the board > sleep for 7 seconds to let YAMON do its normal setup > halt the board > do all the setup that YAMON would do when it runs a program > > That last step is where the magic happens. Basically I do things like > setup various registers to point to memory regions, and then in those > regions create arrays of pointers, which point to strings containing > things like the "environment" that YAMON fills in for programs and > arguments that it passes. Depending on the capabilities of > your debugging > environment this can either be easy or hard. My setup is really nice, > downloads for small kernels take about the same time as going through > tftp, but bigger kernels with a ramdisk are actually faster to push > through EJTAG, which is nice :) > > nathan Thanks for the input. I have a bootrom (different operating system) on my device and if I just boot up from the bootrom it would set up all the registers, controllers for me. Also, visionProbe (which I am using to download over the EJTAG interface) sets up all the controllers for me. So, can't I just load the kernel image and just start executing from "kernel_entry"? Prashant From ndf@ghs.com Thu Feb 5 01:24:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 01:24:17 +0000 (GMT) Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:19674 "EHLO eta.ghs.com") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 01:24:16 +0000 Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233]) by eta.ghs.com (8.12.10/8.12.10) with ESMTP id i151OEOI025416 for ; Wed, 4 Feb 2004 17:24:15 -0800 (PST) Received: from zcar.ghs.com (zcar.ghs.com [192.67.158.60]) by blaze.ghs.com (8.12.9/8.12.9) with ESMTP id i151OCBe013414 for ; Wed, 4 Feb 2004 17:24:13 -0800 (PST) Date: Wed, 4 Feb 2004 17:24:13 -0800 (PST) From: Nathan Field To: linux-mips@linux-mips.org Subject: GNU gcc ld script problem 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: 4284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ndf@ghs.com Precedence: bulk X-list: linux-mips This seems like a problem specific to the linker, but it's also so specific to linux and MIPS that I decided to send it here first. If I was wrong to do that let me know and I'll send it to bug-binutils@gnu.org instead. Anyway, I think I've found a problem in the ld scripts for MIPS. Basically the built in script don't seem to fill in a .plt section. So if I do this: mips-linux-gcc prog.c mips-linux-objdump -h a.out | grep plt I get no output, but if I use my modified linker script I get this: mips-linux-gcc -T tmp.ld prog.c mips-linux-objdump -h a.out | grep plt 10 .plt 00000030 0040052c 0040052c 0000052c 2**2 which I believe is the correct output. The change that I made was to move .stub sections into the .plt from the .text section. So this: .plt : { *(.plt) } .text : { _ftext = . ; *(.text .stub .text.* .gnu.linkonce.t.*) /* .gnu.warning sections are handled specially by elf32.em. */ *(.gnu.warning) *(.mips16.fn.*) *(.mips16.call.*) } =0 became this: .plt : { *(.plt .stub) } .text : { _ftext = . ; *(.text .text.* .gnu.linkonce.t.*) /* .gnu.warning sections are handled specially by elf32.em. */ *(.gnu.warning) *(.mips16.fn.*) *(.mips16.call.*) } =0 If anyone needs more information on this issue just let me know. It has been in the MIPS tools for a while. I have been working from a recent snapshot: 59) ./mips-linux-ld -v GNU ld version 040121 20040121 but the same issue was around way back when (MontaVista preview kit 2.1): 61) /opt/hardhat/previewkit/mips/fp_be/bin/mips_fp_be-ld -v GNU ld version 2.10.91 (with BFD 2.10.91.0.2) Does anyone here have the knowledge to confirm that my changes are correct and commit privileges to the binutils tree? nathan -- Nathan Field (ndf@ghs.com) All gone. But the trouble with analogies is that analogies are like goldfish: sometimes they have nothing to do with the topic at hand. -- Crispin (from a posting to the Bugtraq mailing list) From drow@crack.them.org Thu Feb 5 04:14:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 04:14:19 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:10688 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 04:14:19 +0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AoatB-0001Fq-W2; Wed, 04 Feb 2004 23:13:17 -0500 Date: Wed, 4 Feb 2004 23:13:17 -0500 From: Daniel Jacobowitz To: Nathan Field Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com Subject: Re: GNU gcc ld script problem Message-ID: <20040205041317.GA4767@nevyn.them.org> Mail-Followup-To: Nathan Field , linux-mips@linux-mips.org, binutils@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.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: 4285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Wed, Feb 04, 2004 at 05:24:13PM -0800, Nathan Field wrote: > This seems like a problem specific to the linker, but it's also so > specific to linux and MIPS that I decided to send it here first. If I was > wrong to do that let me know and I'll send it to bug-binutils@gnu.org > instead. binutils@sources.redhat.com is probably most appropriate. > > Anyway, I think I've found a problem in the ld scripts for MIPS. > Basically the built in script don't seem to fill in a .plt section. So if > I do this: > > mips-linux-gcc prog.c > mips-linux-objdump -h a.out | grep plt > > I get no output, but if I use my modified linker script I get this: > > mips-linux-gcc -T tmp.ld prog.c > mips-linux-objdump -h a.out | grep plt > 10 .plt 00000030 0040052c 0040052c 0000052c 2**2 > > which I believe is the correct output. The change that I made was to move > .stub sections into the .plt from the .text section. So this: Well, of course if you move a section with contents you'll suddenly get a PLT... the .stub is not a PLT in the normal sense, so why does it matter whether it's placed in the .plt or .text section in the binary? The fundamental effect of your change is that .stub sections will no longer be interleaved with .text based on the object they are attached to. Instead they will all be collated before any .text or .gnu.linkonce.t* sections. That could be a problem, I don't know for sure. > > .plt : { *(.plt) } > .text : > { > _ftext = . ; > *(.text .stub .text.* .gnu.linkonce.t.*) > /* .gnu.warning sections are handled specially by elf32.em. */ > *(.gnu.warning) > *(.mips16.fn.*) *(.mips16.call.*) > } =0 > > became this: > > .plt : { *(.plt .stub) } > .text : > { > _ftext = . ; > *(.text .text.* .gnu.linkonce.t.*) > /* .gnu.warning sections are handled specially by elf32.em. */ > *(.gnu.warning) > *(.mips16.fn.*) *(.mips16.call.*) > } =0 > > If anyone needs more information on this issue just let me know. It has > been in the MIPS tools for a while. I have been working from a recent > snapshot: > > 59) ./mips-linux-ld -v > GNU ld version 040121 20040121 > > but the same issue was around way back when (MontaVista preview kit 2.1): > > 61) /opt/hardhat/previewkit/mips/fp_be/bin/mips_fp_be-ld -v > GNU ld version 2.10.91 (with BFD 2.10.91.0.2) > > Does anyone here have the knowledge to confirm that my changes are correct > and commit privileges to the binutils tree? > > nathan > > -- > Nathan Field (ndf@ghs.com) All gone. > > But the trouble with analogies is that analogies are like goldfish: > sometimes they have nothing to do with the topic at hand. > -- Crispin (from a posting to the Bugtraq mailing list) > > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From Andre.Messerschmidt@infineon.com Thu Feb 5 07:59:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 07:59:38 +0000 (GMT) Received: from smtp2.infineon.com ([IPv6:::ffff:194.175.117.77]:14235 "EHLO smtp2.infineon.com") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 07:59:38 +0000 Received: from mucse012.eu.infineon.com (mucse012.ifx-mail1.com [172.29.27.229]) by smtp2.infineon.com (8.12.10/8.12.10) with ESMTP id i157vxx8015564; Thu, 5 Feb 2004 08:58:00 +0100 (MET) Received: by mucse012.eu.infineon.com with Internet Mail Service (5.5.2653.19) id <1CW4K35L>; Thu, 5 Feb 2004 08:59:27 +0100 Received: from dlfw003a.dus.infineon.com ([172.29.128.3]) by mucse012.eu.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1CW4K35A; Thu, 5 Feb 2004 08:59:22 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Feb 2004 08:58:44 +0100 From: Andre.Messerschmidt@infineon.com To: vprashant@echelon.com Cc: linux-mips@linux-mips.org X-Mailer: Internet Mail Service (5.5.2653.19) Message-ID: <86048F07C015D311864100902760F1DD0503F942@dlfw003a.dus.infineon.com> Subject: RE: loading kernel via EJTAG interface Date: Thu, 5 Feb 2004 08:58:43 +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: 4286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Andre.Messerschmidt@infineon.com Precedence: bulk X-list: linux-mips Hi, >So, can't I just load the kernel image and just start executing from >"kernel_entry"? For testing purposes it might be feasible to hard code a command line and environment into the kernel. I did this during test with a Lauterbach debugger. Of course you still have to setup SDRAM, clocks etc. before executing the kernel. regards Andre From geert@linux-m68k.org Thu Feb 5 11:19:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 11:19:37 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:54772 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 11:19:37 +0000 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i15BJYw2014746; Thu, 5 Feb 2004 12:19:35 +0100 (MET) Date: Thu, 5 Feb 2004 12:19:34 +0100 (MET) From: Geert Uytterhoeven To: Jun Sun cc: Linux/MIPS Development Subject: Re: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree In-Reply-To: <20040204150820.H26726@mvista.com> Message-ID: References: <20040204150820.H26726@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: 4287 X-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, 4 Feb 2004, Jun Sun wrote: > I wrote a CVS tracking tool that tracks CVS changes in patch format > and present them with a web interface. It is now set up to track > linux-mips.org tree at the following place. Enjoy. > > http://www.linux-mips.org/xcvs/linux-mips http://www.linux-mips.org/xcvs/html/select.php | Warning: Assertion failed in /var/www/www.linux-mips.org/xcvs/html/db.inc.php on line 36 | Warning: readfile("/LAST_UPDATE") - No such file or directory in /var/www/www.linux-mips.org/xcvs/html/select.inc.php on line 47 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 yuasa@hh.iij4u.or.jp Thu Feb 5 16:34:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 16:34:01 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:54776 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 16:34:00 +0000 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id BAA21557; Fri, 6 Feb 2004 01:33:56 +0900 (JST) Received: 4UMDO01 id i15GXuG21236; Fri, 6 Feb 2004 01:33:56 +0900 (JST) Received: 4UMRO00 id i15GXt416468; Fri, 6 Feb 2004 01:33:55 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Fri, 6 Feb 2004 01:33:46 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.4] Added keymap of Victor MP-C30x Message-Id: <20040206013346.15d4d82a.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4288 X-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 Hello Ralf, I made a patch for keymap of Victor MP-30x. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/config-shared.in linux/arch/mips/config-shared.in --- linux-orig/arch/mips/config-shared.in Fri Jan 16 01:18:59 2004 +++ linux/arch/mips/config-shared.in Fri Feb 6 00:59:57 2004 @@ -697,7 +697,6 @@ define_bool CONFIG_PCI y define_bool CONFIG_NEW_PCI y define_bool CONFIG_PCI_AUTO y - define_bool CONFIG_DUMMY_KEYB y define_bool CONFIG_SCSI n fi if [ "$CONFIG_ZAO_CAPCELLA" = "y" ]; then diff -urN -X dontdiff linux-orig/drivers/char/Makefile linux/drivers/char/Makefile --- linux-orig/drivers/char/Makefile Fri Jan 23 21:13:49 2004 +++ linux/drivers/char/Makefile Fri Feb 6 00:59:57 2004 @@ -51,6 +51,9 @@ ifeq ($(CONFIG_IBM_WORKPAD),y) KEYMAP = ibm_workpad_keymap.o endif + ifeq ($(CONFIG_VICTOR_MPC30X),y) + KEYMAP = victor_mpc30x_keymap.o + endif KEYBD = vr41xx_keyb.o endif endif @@ -357,4 +360,7 @@ set -e ; loadkeys --mktable $< | sed -e 's/^static *//' > $@ ibm_workpad_keymap.c: ibm_workpad_keymap.map + set -e ; loadkeys --mktable $< | sed -e 's/^static *//' > $@ + +victor_mpc30x_keymap.c: victor_mpc30x_keymap.map set -e ; loadkeys --mktable $< | sed -e 's/^static *//' > $@ diff -urN -X dontdiff linux-orig/drivers/char/victor_mpc30x_keymap.map linux/drivers/char/victor_mpc30x_keymap.map --- linux-orig/drivers/char/victor_mpc30x_keymap.map Thu Jan 1 09:00:00 1970 +++ linux/drivers/char/victor_mpc30x_keymap.map Fri Feb 6 00:59:57 2004 @@ -0,0 +1,102 @@ +# Victor Interlink MP-C303/304 keyboard keymap +# +# Copyright (C) 2003 Yoichi Yuasa +# +# This file is subject to the terms and conditions of the GNU General Public +# License. See the file "COPYING" in the main directory of this archive +# for more details. +keymaps 0-1,4-5,8-9,12 +alt_is_meta +strings as usual +compose as usual for "iso-8859-1" + +# First line +keycode 89 = Escape +keycode 9 = Delete + +# 2nd line +keycode 73 = one exclam +keycode 18 = two quotedbl +keycode 92 = three numbersign + control keycode 92 = Escape +keycode 53 = four dollar + control keycode 53 = Control_backslash +keycode 21 = five percent + control keycode 21 = Control_bracketright +keycode 50 = six ampersand + control keycode 50 = Control_underscore +keycode 48 = seven apostrophe +keycode 51 = eight parenleft +keycode 16 = nine parenright +keycode 80 = zero asciitilde + control keycode 80 = nul +keycode 49 = minus equal +keycode 30 = asciicircum asciitilde + control keycode 30 = Control_asciicircum +keycode 5 = backslash bar + control keycode 5 = Control_backslash +keycode 13 = BackSpace +# 3rd line +keycode 57 = Tab +keycode 74 = q +keycode 26 = w +keycode 81 = e +keycode 29 = r +keycode 37 = t +keycode 45 = y +keycode 72 = u +keycode 24 = i +keycode 32 = o +keycode 41 = p +keycode 1 = at grave + control keycode 1 = nul +keycode 54 = bracketleft braceleft +keycode 63 = Return + alt keycode 63 = Meta_Control_m +# 4th line +keycode 23 = Caps_Lock +keycode 34 = a +keycode 66 = s +keycode 52 = d +keycode 20 = f +keycode 84 = g +keycode 67 = h +keycode 64 = j +keycode 17 = k +keycode 83 = l +keycode 22 = semicolon plus +keycode 61 = colon asterisk + control keycode 61 = Control_g +keycode 65 = bracketright braceright + control keycode 65 = Control_bracketright +# 5th line +keycode 91 = Shift +keycode 76 = z +keycode 68 = x +keycode 28 = c +keycode 36 = v +keycode 44 = b +keycode 19 = n +keycode 27 = m +keycode 35 = comma less +keycode 3 = period greater + control keycode 3 = Compose +keycode 38 = slash question + control keycode 38 = Delete + shift control keycode 38 = Delete +keycode 6 = backslash underscore + control keycode 6 = Control_backslash +keycode 55 = Up + alt keycode 55 = PageUp +keycode 14 = Shift +# 6th line +keycode 56 = Control +keycode 42 = Alt +keycode 33 = space + control keycode 33 = nul +keycode 7 = Left + alt keycode 7 = Home +keycode 31 = Down + alt keycode 31 = PageDown +keycode 47 = Right + alt keycode 47 = End From seo_tmi@charter.net Thu Feb 5 17:00:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 17:00:40 +0000 (GMT) Received: from mxsf26.cluster1.charter.net ([IPv6:::ffff:209.225.28.226]:24595 "EHLO mxsf26.cluster1.charter.net") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 17:00:40 +0000 Received: from tseo ([68.114.28.136]) by mxsf26.cluster1.charter.net (8.12.10/8.12.8) with SMTP id i15Gw5JC081838 for ; Thu, 5 Feb 2004 11:58:06 -0500 (EST) (envelope-from seo_tmi@charter.net) From: "Toshio Seo" To: "Linux-Mips" Subject: Userland question Date: Thu, 5 Feb 2004 11:55:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01C3EBDE.F7912EE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: seo_tmi@charter.net Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C3EBDE.F7912EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I built am using a cross compiler and was able to build Linux with GCC-3.3.2 and GLIB-2.3.2 but when trying to execute programs, I get GLIB errors since the Userland on the embedded system is not up to the right version. I tried PTX but I think it is up to 3.2.3 and 2.2.5 respectively. I there any good reference to updating the Userland when crosscompiling? Toshio Seo --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.573 / Virus Database: 363 - Release Date: 1/28/2004 ------=_NextPart_000_0019_01C3EBDE.F7912EE0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IiQQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHAgAFAAsANgAAAAQAJwEB A5AGALQGAAAkAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAEgAAAFVzZXJsYW5kIHF1ZXN0aW9uAAAAAgFxAAEAAAAWAAAAAcPsCMYfGV5EUkpxRYqXUE8C EUJ1aAAAAgEdDAEAAAAZAAAAU01UUDpTRU9fVE1JQENIQVJURVIuTkVUAAAAAAsAAQ4AAAAAQAAG DgCE3qYI7MMBAgEKDgEAAAAYAAAAAAAAABRtoedp2XZAoUldXSIG/zTCgAAACwAfDgEAAAACAQkQ AQAAAHYCAAByAgAARwMAAExaRnWGXMd8AwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBj aArAc/BldDAgBxMCgwBQBFV/EMkIVQeyAoMOUBBvEXV9JQqBdgiQd2sLgGQ0HQxgYwBQCwMLtSBI aQ4sCqIKhAqASSBidcMDEAVAYW0gdQCQDyA1GUAgBQBvBBEFoG1whwMQE6EAcGQgd2EEIGMBoBqw IHRvGOMbEEwJC4B1eBsgaXRoIEBHQ0MtMy4dQDKBGuNHTElCLTIdUzMY8AVAd2gJ8BuwcnlzGaIb wWV4BZAeoBugcEcDYAnAGVBzLCAY0Ge3ETAd0x+wcgNgERAgGZGmYxuhHuAgVREgcg8B9xsQAiAi U2UG0AmAAQAbEDhzeXMgEBlgBAAgbnJvBUB1cBuyImIFEGc6aAVAdgSQAJACIC4gjyDRHyAIkBsQ UFRYHoP1JrFoC4BrJJAFQCShJRTfHWEdUBrjHjAeMDUloAeQknAFkHRpJhBseSaE1x7gCXAa4Xkg 8G8EcCnhnmYrISIjG9AlEGRhKlC/H2Iieh7TGgMaZBmhPxgaeQrzIFQaICfgG9AGYG//GBUAQRgj MAULRhRSF7EAALkLDjE4AzAvERugLTUg/TTETx6gK6AZogDAAxEkoY8iMAAgBpAm8lZpchmAVCBG CdEuNMRDHuBjimskAWIrgEFWRxrhXSpQLRYwN4IkNSgl4HSgcDovL3c7AC4JwFUEAG8BgC4aYSk4 BVZBJiQ6IDYuMCnAN3UpMC83VUQs8AGgG0BlaTzgMzYpMC0H8CqAZYc+UT3yPnExLzI4P/BMMDAW sDTTIH0YFH0BQWAAAAMAAHwFAAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOA CCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAJoAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAABz eQEACwAzgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADWACCAGAAAAAADAAAAAAAAARgAA AAARhQAAAAAAAAMANoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAwBcgAggBgAAAAAAwAAA AAAAAEYAAAAAAYUAAAAAAAAeAGuACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAA CwBsgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAIeACCAGAAAAAADAAAAAAAAARgAAAACC hQAAAQAAAAMABoFACbNnNTvSEaWVACAYZIunAQAAACAAAABBAFYARwAgAEYATABBAEcAUwAgACgA TwBVAFQAKQAAAAAAAAMCAfgPAQAAABAAAAAUbaHnadl2QKFJXV0iBv80AgH6DwEAAAAQAAAAFG2h 52nZdkChSV1dIgb/NAIB+w8BAAAAnwAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExM AAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NcQWRtaW5p c3RyYXRvclxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29r XG91dGxvb2sucHN0AAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAzAAAAPEhHRUFLQkVKRUpEQUlE T0JKR09OS0VNS0NBQUEuc2VvX3RtaUBjaGFydGVyLm5ldD4AAAMABhD63K0jAwAHELIBAAADABAQ AAAAAAMAERAAAAAAHgAIEAEAAABlAAAASEksSUJVSUxUQU1VU0lOR0FDUk9TU0NPTVBJTEVSQU5E V0FTQUJMRVRPQlVJTERMSU5VWFdJVEhHQ0MtMzMyQU5ER0xJQi0yMzJCVVRXSEVOVFJZSU5HVE9F WEVDVVRFUFJPRwAAAAAjgQ== ------=_NextPart_000_0019_01C3EBDE.F7912EE0-- From dahms@zeus.fh-brandenburg.de Thu Feb 5 17:04:43 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 17:04:44 +0000 (GMT) Received: from baldur.fh-brandenburg.de ([IPv6:::ffff:195.37.0.5]:51357 "HELO baldur.fh-brandenburg.de") by linux-mips.org with SMTP id ; Thu, 5 Feb 2004 17:04:43 +0000 Received: (1380 bytes) by baldur.fh-brandenburg.de via sendmail with P:stdio/R:match-inet-hosts/T:smtp (sender: ) id for ; Thu, 5 Feb 2004 17:59:40 +0100 (MET) (Smail-3.2.0.97 1997-Aug-19 #3 built DST-Sep-15) Received: from zeus.fh-brandenburg.de(195.37.1.35) via SMTP by baldur.fh-brandenburg.de, id smtpdNNAa001YW; Thu Feb 5 16:30:49 2004 Received: (from dahms@localhost) by zeus.fh-brandenburg.de (8.11.7p1+Sun/8.11.7) id i12G7Tt20206 for linux-mips@linux-mips.org; Mon, 2 Feb 2004 17:07:29 +0100 (MET) Date: Mon, 2 Feb 2004 17:07:29 +0100 From: Markus Dahms To: linux-mips@linux-mips.org Subject: Indy R4000PC problems Message-ID: <20040202160729.GA5966@fh-brandenburg.de> 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: 4290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dahms@fh-brandenburg.de Precedence: bulk X-list: linux-mips Hi, I had problems getting the 2.4 kernel to work on an Indy with a R4000PC (100MHz) processor (very old PROM, too). The solution I found yesterday is to change an entry in arch/mips/kernel/cpu-probe.c from CPU_R4000SC to CPU_R4000PC. Is there a reason why only the SC version is thought to be there, or is it believed to be compatible? Without this change the machine locks up after loading the kernel, linux hasn't switched to the black background, yet. I also changed the compiler flags from -m{arch,tune}=r4600 to *r4000, but this I also tried before without success. greetings, Markus Dahms -- A bug in the code is worth two in the documentation. From sjhill@realitydiluted.com Thu Feb 5 17:51:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 17:51:41 +0000 (GMT) Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:36269 "EHLO real.realitydiluted.com") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 17:51:39 +0000 Received: from localhost ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian)) id 1AoneB-0000TU-00; Thu, 05 Feb 2004 11:50:39 -0600 Message-ID: <40228235.6050403@realitydiluted.com> Date: Thu, 05 Feb 2004 12:49:41 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Markus Dahms CC: linux-mips@linux-mips.org Subject: Re: Indy R4000PC problems References: <20040202160729.GA5966@fh-brandenburg.de> In-Reply-To: <20040202160729.GA5966@fh-brandenburg.de> 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: 4291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips Markus Dahms wrote: > > I had problems getting the 2.4 kernel to work on an Indy with > a R4000PC (100MHz) processor (very old PROM, too). > The solution I found yesterday is to change an entry in > arch/mips/kernel/cpu-probe.c from CPU_R4000SC to CPU_R4000PC. > Is there a reason why only the SC version is thought to be > there, or is it believed to be compatible? > The SC stands for secondary cache. So one would expect that if your Indy only has a primary cache (PC) and you are detecting as an Indy with SC, you will crash since there is no secondary cache. -Steve From ralf@linux-mips.org Thu Feb 5 17:53:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 17:53:23 +0000 (GMT) Received: from p508B78D6.dip.t-dialin.net ([IPv6:::ffff:80.139.120.214]:61716 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 17:53:22 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i15Hptex023489; Thu, 5 Feb 2004 18:51:55 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i15HpkXf023488; Thu, 5 Feb 2004 18:51:46 +0100 Date: Thu, 5 Feb 2004 18:51:46 +0100 From: Ralf Baechle To: Markus Dahms Cc: linux-mips@linux-mips.org Subject: Re: Indy R4000PC problems Message-ID: <20040205175146.GA18162@linux-mips.org> References: <20040202160729.GA5966@fh-brandenburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040202160729.GA5966@fh-brandenburg.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: 4292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 02, 2004 at 05:07:29PM +0100, Markus Dahms wrote: > I had problems getting the 2.4 kernel to work on an Indy with > a R4000PC (100MHz) processor (very old PROM, too). > The solution I found yesterday is to change an entry in > arch/mips/kernel/cpu-probe.c from CPU_R4000SC to CPU_R4000PC. > Is there a reason why only the SC version is thought to be > there, or is it believed to be compatible? The PC and SC versions are basically identical except the second level cache which is missing in the PC version. > Without this change the machine locks up after loading the > kernel, linux hasn't switched to the black background, yet. > > I also changed the compiler flags from -m{arch,tune}=r4600 to > *r4000, but this I also tried before without success. Do you know which version of the processor this is exactly? IRIX's hinv command or the "CPU revision is: ..." line of bootup messages contain that information. The PC version have become pretty rare, didn't recall anymore it was in use in Indys at all. Anyway, please try the patch below and let me know. Ralf Index: arch/mips/mm/c-r4k.c =================================================================== RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.3.2.65 diff -u -r1.3.2.65 c-r4k.c --- arch/mips/mm/c-r4k.c 2 Feb 2004 22:24:37 -0000 1.3.2.65 +++ arch/mips/mm/c-r4k.c 5 Feb 2004 17:50:37 -0000 @@ -965,10 +965,8 @@ * Linux memory managment. */ switch (c->cputype) { - case CPU_R4000PC: case CPU_R4000SC: case CPU_R4000MC: - case CPU_R4400PC: case CPU_R4400SC: case CPU_R4400MC: probe_scache_kseg1 = (probe_func_t) (KSEG1ADDR(&probe_scache)); Index: arch/mips/kernel/cpu-probe.c =================================================================== RCS file: /home/cvs/linux/arch/mips/kernel/cpu-probe.c,v retrieving revision 1.1.2.31 diff -u -r1.1.2.31 cpu-probe.c --- arch/mips/kernel/cpu-probe.c 19 Jan 2004 18:32:05 -0000 1.1.2.31 +++ arch/mips/kernel/cpu-probe.c 5 Feb 2004 17:50:39 -0000 @@ -192,10 +192,18 @@ c->tlbsize = 64; break; case PRID_IMP_R4000: - if ((c->processor_id & 0xff) >= PRID_REV_R4400) - c->cputype = CPU_R4400SC; - else - c->cputype = CPU_R4000SC; + if (read_c0_config() & CONF_SC) { + if ((c->processor_id & 0xff) >= PRID_REV_R4400) + c->cputype = CPU_R4400SC; + else + c->cputype = CPU_R4000SC; + } else { + if ((c->processor_id & 0xff) >= PRID_REV_R4400) + c->cputype = CPU_R4400SC; + else + c->cputype = CPU_R4000SC; + } + c->isa_level = MIPS_CPU_ISA_III; c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR | MIPS_CPU_WATCH | MIPS_CPU_VCE | From jsun@mvista.com Thu Feb 5 18:05:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 18:05:30 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:34803 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 18:05:29 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id i15I5Qc10073; Thu, 5 Feb 2004 10:05:26 -0800 Date: Thu, 5 Feb 2004 10:05:25 -0800 From: Jun Sun To: Geert Uytterhoeven Cc: Linux/MIPS Development , jsun@mvista.com Subject: Re: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree Message-ID: <20040205100525.B9885@mvista.com> References: <20040204150820.H26726@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from geert@linux-m68k.org on Thu, Feb 05, 2004 at 12:19:34PM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4293 X-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 Thu, Feb 05, 2004 at 12:19:34PM +0100, Geert Uytterhoeven wrote: > On Wed, 4 Feb 2004, Jun Sun wrote: > > I wrote a CVS tracking tool that tracks CVS changes in patch format > > and present them with a web interface. It is now set up to track > > linux-mips.org tree at the following place. Enjoy. > > > > http://www.linux-mips.org/xcvs/linux-mips > > http://www.linux-mips.org/xcvs/html/select.php > | Warning: Assertion failed in /var/www/www.linux-mips.org/xcvs/html/db.inc.php on line 36 > | Warning: readfile("/LAST_UPDATE") - No such file or directory in /var/www/www.linux-mips.org/xcvs/html/select.inc.php on line 47 > It appears session somehow does not work on your web viewer. What is your web browser anyway? Immediately after you hit above link, please redirect URL to http://www.linux-mips.org/xcvs/test.php If you don't see following, that means sessions do not work. ------------------------------------------------ dbname : xcvs_linux_mips patchdir : ../linux-mips/patches branch : MAIN author : all authors starting-date : ending-date : ----------------------------------------------- Anybody else has similar problems? Jun From ralf@linux-mips.org Thu Feb 5 18:11:50 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 18:11:50 +0000 (GMT) Received: from p508B78D6.dip.t-dialin.net ([IPv6:::ffff:80.139.120.214]:5397 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 18:11:50 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i15IAkex023721; Thu, 5 Feb 2004 19:10:46 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i15IAkGQ023720; Thu, 5 Feb 2004 19:10:46 +0100 Date: Thu, 5 Feb 2004 19:10:46 +0100 From: Ralf Baechle To: Markus Dahms Cc: linux-mips@linux-mips.org Subject: Re: Indy R4000PC problems Message-ID: <20040205181046.GA23682@linux-mips.org> References: <20040202160729.GA5966@fh-brandenburg.de> <20040205175146.GA18162@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040205175146.GA18162@linux-mips.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: 4294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 05, 2004 at 06:51:46PM +0100, Ralf Baechle wrote: > The PC version have become pretty rare, didn't recall anymore it was in > use in Indys at all. Anyway, please try the patch below and let me know. Argh... Famous class of bugs when one is about to run out of the door. The CONF_SC bit is inverted so the test for it needs to be inverted. WIll post a new patch later. Ralf From js@convergence.de Thu Feb 5 18:41:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 18:41:03 +0000 (GMT) Received: from buserror-extern.convergence.de ([IPv6:::ffff:212.84.236.66]:4233 "EHLO heck") by linux-mips.org with ESMTP id ; Thu, 5 Feb 2004 18:41:02 +0000 Received: from js by heck with local (Exim 3.35 #1 (Debian)) id 1AooQ4-00046V-00; Thu, 05 Feb 2004 19:40:08 +0100 Date: Thu, 5 Feb 2004 19:40:08 +0100 From: Johannes Stezenbach To: Jun Sun Cc: linux-mips@linux-mips.org Subject: Re: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree Message-ID: <20040205184008.GC13068@convergence.de> Mail-Followup-To: Johannes Stezenbach , Jun Sun , linux-mips@linux-mips.org References: <20040204150820.H26726@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040204150820.H26726@mvista.com> User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@convergence.de Precedence: bulk X-list: linux-mips Jun Sun wrote: > > I wrote a CVS tracking tool that tracks CVS changes in patch format > and present them with a web interface. It is now set up to track > linux-mips.org tree at the following place. Enjoy. > > http://www.linux-mips.org/xcvs/linux-mips > > BTW, if you use this tool for tracking other trees, please drop me a > note. Of course, I also like to have more developers to participate. > Please join us at > > http://xcvs.sf.net Very good! I played with cvsps a few times, but didn't dare to use it on such a large tree like the Linux kernel. A few nits: - I would prefer a "latest first" sort order in the patchset listing - IMHO 'diff -up' would make the patchsets much easier to read - could you please add a tag for the query page? (For easier bookmarking.) The README from the sources mentions some constraints: ". Branching is always a complete branching of the whole tree." What happens when only a part of a tree is branched? ". Commitment only modifies the head of a given branch." I don't understand this. CVS commits will always change the head of a branch (or the trunk) only, no? How would one use xcvs on a repository with many different, but interdependent CVS modules (e.g. gnome CVS http://cvs.gnome.org/)? Johannes From raiko@niisi.msk.ru Thu Feb 5 18:48:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 18:48:42 +0000 (GMT) Received: from [IPv6:::ffff:193.232.173.111] ([IPv6:::ffff:193.232.173.111]:21096 "EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP id <S8225463AbUBESsm>; Thu, 5 Feb 2004 18:48:42 +0000 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.11.7/8.11.7) with ESMTP id i15InRs07959; Thu, 5 Feb 2004 21:49:28 +0300 Received: from t06.niisi.ras.ru (localhost.localdomain [127.0.0.1]) by t06.niisi.ras.ru (8.12.8/8.12.8) with ESMTP id i15IJLF3011050; Thu, 5 Feb 2004 21:19:21 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.12.8/8.12.8/Submit) with UUCP id i15IJL50011048; Thu, 5 Feb 2004 21:19:21 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.12.5/8.12.5) with ESMTP id i15IFbRH002037; Thu, 5 Feb 2004 21:15:37 +0300 (MSK) Message-ID: <40228833.E40ED761@niisi.msk.ru> Date: Thu, 05 Feb 2004 21:15:15 +0300 From: "Gleb O. Raiko" <raiko@niisi.msk.ru> Organization: NIISI RAN X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Jun Sun <jsun@mvista.com> CC: Geert Uytterhoeven <geert@linux-m68k.org>, Linux/MIPS Development <linux-mips@linux-mips.org> Subject: Re: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree References: <20040204150820.H26726@mvista.com> <Pine.GSO.4.58.0402051218590.11549@waterleaf.sonytel.be> <20040205100525.B9885@mvista.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Return-Path: <raiko@niisi.msk.ru> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: raiko@niisi.msk.ru Precedence: bulk X-list: linux-mips Jun Sun wrote: > > Anybody else has similar problems? Sure, IE6 w/ high security settings. Had to accept all cookies from linux-mips.org in order to fix the problem. Regards, Gleb. From jsun@mvista.com Thu Feb 5 19:39:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 19:39:55 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:51438 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id <S8225236AbUBETjz>; Thu, 5 Feb 2004 19:39:55 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id i15Jdeo11742; Thu, 5 Feb 2004 11:39:40 -0800 Date: Thu, 5 Feb 2004 11:39:40 -0800 From: Jun Sun <jsun@mvista.com> To: "Gleb O. Raiko" <raiko@niisi.msk.ru> Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Linux/MIPS Development <linux-mips@linux-mips.org>, jsun@mvista.com Subject: Re: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree Message-ID: <20040205113940.C9885@mvista.com> References: <20040204150820.H26726@mvista.com> <Pine.GSO.4.58.0402051218590.11549@waterleaf.sonytel.be> <20040205100525.B9885@mvista.com> <40228833.E40ED761@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <40228833.E40ED761@niisi.msk.ru>; from raiko@niisi.msk.ru on Thu, Feb 05, 2004 at 09:15:15PM +0300 Return-Path: <jsun@mvista.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4297 X-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 Thu, Feb 05, 2004 at 09:15:15PM +0300, Gleb O. Raiko wrote: > Jun Sun wrote: > > > > Anybody else has similar problems? > > Sure, IE6 w/ high security settings. Had to accept all cookies from > linux-mips.org in order to fix the problem. > I thought if a browser refuses to accept cookies, PHP would fall back to use explicit SID get variable in URL. Strange. Jun From jsun@mvista.com Thu Feb 5 19:43:24 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 19:43:25 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:25583 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id <S8225315AbUBETnY>; Thu, 5 Feb 2004 19:43:24 +0000 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id i15JhG411759; Thu, 5 Feb 2004 11:43:16 -0800 Date: Thu, 5 Feb 2004 11:43:16 -0800 From: Jun Sun <jsun@mvista.com> To: Johannes Stezenbach <js@convergence.de>, linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: Re: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree Message-ID: <20040205114316.D9885@mvista.com> References: <20040204150820.H26726@mvista.com> <20040205184008.GC13068@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040205184008.GC13068@convergence.de>; from js@convergence.de on Thu, Feb 05, 2004 at 07:40:08PM +0100 Return-Path: <jsun@mvista.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4298 X-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 Thu, Feb 05, 2004 at 07:40:08PM +0100, Johannes Stezenbach wrote: > Jun Sun wrote: > > > > I wrote a CVS tracking tool that tracks CVS changes in patch format > > and present them with a web interface. It is now set up to track > > linux-mips.org tree at the following place. Enjoy. > > > > http://www.linux-mips.org/xcvs/linux-mips > > > > BTW, if you use this tool for tracking other trees, please drop me a > > note. Of course, I also like to have more developers to participate. > > Please join us at > > > > http://xcvs.sf.net > > Very good! > > I played with cvsps a few times, but didn't dare to use it > on such a large tree like the Linux kernel. > > A few nits: > - I would prefer a "latest first" sort order in the patchset listing > - IMHO 'diff -up' would make the patchsets much easier to read > - could you please add a <title> tag for the query page? (For > easier bookmarking.) > Good suggestions. Patches are even more welcome. :) > The README from the sources mentions some constraints: > > ". Branching is always a complete branching of the whole tree." > > What happens when only a part of a tree is branched? > Probably does not hurt. > ". Commitment only modifies the head of a given branch." > > I don't understand this. CVS commits will always change the head > of a branch (or the trunk) only, no? > These statements are over paranoid. > > How would one use xcvs on a repository with many different, but > interdependent CVS modules (e.g. gnome CVS http://cvs.gnome.org/)? > Don't know yet. Have not given a thought. BTW, this kind of discussions probably should go to xcvs list. Pretty soon I think Ralf will revoke our posting previledges. :) Jun From geert@linux-m68k.org Thu Feb 5 20:22:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 20:22:22 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:21153 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id <S8225362AbUBEUWW>; Thu, 5 Feb 2004 20:22:22 +0000 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i15KMKw2003809; Thu, 5 Feb 2004 21:22:20 +0100 (MET) Date: Thu, 5 Feb 2004 21:22:20 +0100 (MET) From: Geert Uytterhoeven <geert@linux-m68k.org> To: Jun Sun <jsun@mvista.com> cc: Linux/MIPS Development <linux-mips@linux-mips.org> Subject: Re: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree In-Reply-To: <20040205100525.B9885@mvista.com> Message-ID: <Pine.GSO.4.58.0402052117470.20594@waterleaf.sonytel.be> References: <20040204150820.H26726@mvista.com> <Pine.GSO.4.58.0402051218590.11549@waterleaf.sonytel.be> <20040205100525.B9885@mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: <geert@linux-m68k.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4299 X-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, 5 Feb 2004, Jun Sun wrote: > On Thu, Feb 05, 2004 at 12:19:34PM +0100, Geert Uytterhoeven wrote: > > On Wed, 4 Feb 2004, Jun Sun wrote: > > > I wrote a CVS tracking tool that tracks CVS changes in patch format > > > and present them with a web interface. It is now set up to track > > > linux-mips.org tree at the following place. Enjoy. > > > > > > http://www.linux-mips.org/xcvs/linux-mips > > > > http://www.linux-mips.org/xcvs/html/select.php > > | Warning: Assertion failed in /var/www/www.linux-mips.org/xcvs/html/db.inc.php on line 36 > > | Warning: readfile("/LAST_UPDATE") - No such file or directory in /var/www/www.linux-mips.org/xcvs/html/select.inc.php on line 47 > > > > It appears session somehow does not work on your web viewer. What is > your web browser anyway? Galeon (from Debian testing or unstable on ia32). > Immediately after you hit above link, please redirect URL to OK, I'll retry (at home, with a similar Galeon but on PPC): > http://www.linux-mips.org/xcvs/test.php > > If you don't see following, that means sessions do not work. > > ------------------------------------------------ > dbname : xcvs_linux_mips > patchdir : ../linux-mips/patches > branch : MAIN > author : all authors > starting-date : > ending-date : > ----------------------------------------------- ... and all I see is the two lines with hyphens. > Anybody else has similar problems? OK, if I enable cookies, it works fine! Nice! 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 Feb 5 21:53:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2004 21:53:02 +0000 (GMT) Received: from p508B78D6.dip.t-dialin.net ([IPv6:::ffff:80.139.120.214]:36886 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id <S8225478AbUBEVxC>; Thu, 5 Feb 2004 21:53:02 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i15Lpvex026197; Thu, 5 Feb 2004 22:51:58 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i15LpQCs026196; Thu, 5 Feb 2004 22:51:26 +0100 Date: Thu, 5 Feb 2004 22:51:26 +0100 From: Ralf Baechle <ralf@linux-mips.org> To: Jun Sun <jsun@mvista.com> Cc: Johannes Stezenbach <js@convergence.de>, linux-mips@linux-mips.org Subject: Re: [ANNOUNCE] "cvs explorer" for linux-mips CVS tree Message-ID: <20040205215126.GA26097@linux-mips.org> References: <20040204150820.H26726@mvista.com> <20040205184008.GC13068@convergence.de> <20040205114316.D9885@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040205114316.D9885@mvista.com> User-Agent: Mutt/1.4.1i Return-Path: <ralf@linux-mips.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 05, 2004 at 11:43:16AM -0800, Jun Sun wrote: > Don't know yet. Have not given a thought. > > BTW, this kind of discussions probably should go to xcvs list. Pretty > soon I think Ralf will revoke our posting previledges. :) Hey, if I'd be consequent I'd then have to revoke posting priviledges for myself fi... DISCONNECT From yuasa@hh.iij4u.or.jp Fri Feb 6 00:00:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 00:00:54 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:39417 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225462AbUBFAAx>; Fri, 6 Feb 2004 00:00:53 +0000 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 JAA22429; Fri, 6 Feb 2004 09:00:49 +0900 (JST) Received: 4UMDO00 id i1600nW15555; Fri, 6 Feb 2004 09:00:49 +0900 (JST) Received: 4UMRO00 id i1600nE02271; Fri, 6 Feb 2004 09:00:49 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Fri, 6 Feb 2004 09:00:35 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Removed same processing for initrd of vr41xx Message-Id: <20040206090035.17cbf272.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4301 X-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 Hello Ralf, I made a patch for initrd of vr41xx. Both arch/mips/kernel/setup.c and following files have the same processing for initrd. One of the processing for initrd should delete. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c --- linux-orig/arch/mips/vr41xx/casio-e55/setup.c Fri Oct 31 11:28:40 2003 +++ linux/arch/mips/vr41xx/casio-e55/setup.c Fri Feb 6 08:49:49 2004 @@ -23,11 +23,6 @@ #include <asm/time.h> #include <asm/vr41xx/e55.h> -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - void __init casio_e55_setup(void) { set_io_port_base(IO_PORT_BASE); @@ -35,12 +30,6 @@ ioport_resource.end = IO_PORT_RESOURCE_END; iomem_resource.start = IO_MEM_RESOURCE_START; iomem_resource.end = IO_MEM_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif _machine_restart = vr41xx_restart; _machine_halt = vr41xx_halt; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c --- linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c Fri Oct 31 11:28:41 2003 +++ linux/arch/mips/vr41xx/ibm-workpad/setup.c Fri Feb 6 08:49:49 2004 @@ -23,11 +23,6 @@ #include <asm/time.h> #include <asm/vr41xx/workpad.h> -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - void __init ibm_workpad_setup(void) { set_io_port_base(IO_PORT_BASE); @@ -35,12 +30,6 @@ ioport_resource.end = IO_PORT_RESOURCE_END; iomem_resource.start = IO_MEM_RESOURCE_START; iomem_resource.end = IO_MEM_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif _machine_restart = vr41xx_restart; _machine_halt = vr41xx_halt; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Fri Oct 31 11:28:41 2003 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Fri Feb 6 08:49:49 2004 @@ -50,11 +50,6 @@ #include <asm/time.h> #include <asm/vr41xx/eagle.h> -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - extern void eagle_irq_init(void); #ifdef CONFIG_PCI @@ -114,12 +109,6 @@ ioport_resource.end = IO_PORT_RESOURCE_END; iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif _machine_restart = vr41xx_restart; _machine_halt = vr41xx_halt; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c Fri Oct 31 11:28:41 2003 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c Fri Feb 6 08:49:49 2004 @@ -23,11 +23,6 @@ #include <asm/time.h> #include <asm/vr41xx/tb0226.h> -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - #ifdef CONFIG_PCI static struct resource vr41xx_pci_io_resource = { "PCI I/O space", @@ -82,12 +77,6 @@ ioport_resource.end = IO_PORT_RESOURCE_END; iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif _machine_restart = vr41xx_restart; _machine_halt = vr41xx_halt; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c Fri Oct 31 11:28:41 2003 +++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c Fri Feb 6 08:49:50 2004 @@ -28,10 +28,6 @@ #include <asm/time.h> #include <asm/vr41xx/tb0229.h> -#ifdef CONFIG_BLK_DEV_INITRD -extern void * __rd_start, * __rd_end; -#endif - #ifdef CONFIG_PCI static struct resource vr41xx_pci_io_resource = { .name = "PCI I/O space", @@ -94,12 +90,6 @@ ioport_resource.end = IO_PORT_RESOURCE_END; iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif _machine_restart = tanbac_tb0229_restart; _machine_halt = vr41xx_halt; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c Fri Oct 31 11:28:41 2003 +++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c Fri Feb 6 08:49:50 2004 @@ -24,11 +24,6 @@ #include <asm/time.h> #include <asm/vr41xx/mpc30x.h> -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - #ifdef CONFIG_PCI static struct resource vr41xx_pci_io_resource = { "PCI I/O space", @@ -83,12 +78,6 @@ ioport_resource.end = IO_PORT_RESOURCE_END; iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif _machine_restart = vr41xx_restart; _machine_halt = vr41xx_halt; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c --- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c Fri Oct 31 11:28:41 2003 +++ linux/arch/mips/vr41xx/zao-capcella/setup.c Fri Feb 6 08:49:50 2004 @@ -24,11 +24,6 @@ #include <asm/time.h> #include <asm/vr41xx/capcella.h> -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - #ifdef CONFIG_PCI static struct resource vr41xx_pci_io_resource = { "PCI I/O space", @@ -83,12 +78,6 @@ ioport_resource.end = IO_PORT_RESOURCE_END; iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif _machine_restart = vr41xx_restart; _machine_halt = vr41xx_halt; From robbat2@orbis-terrarum.net Fri Feb 6 00:44:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 00:44:10 +0000 (GMT) Received: from shawidc-mo1.cg.shawcable.net ([IPv6:::ffff:24.71.223.10]:8937 "EHLO pd5mo1so.prod.shaw.ca") by linux-mips.org with ESMTP id <S8225440AbUBFAoJ>; Fri, 6 Feb 2004 00:44:09 +0000 Received: from pd2mr3so.prod.shaw.ca (pd2mr3so-ser.prod.shaw.ca [10.0.141.108]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HSN00C190NLEM@l-daemon> for linux-mips@linux-mips.org; Thu, 05 Feb 2004 17:42:57 -0700 (MST) Received: from pn2ml2so.prod.shaw.ca (pn2ml2so-qfe0.prod.shaw.ca [10.0.121.146]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HSN00FEW0NL4D@l-daemon> for linux-mips@linux-mips.org; Thu, 05 Feb 2004 17:42:57 -0700 (MST) Received: from curie.orbis-terrarum.net ([24.84.49.144]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HSN0040L0NI1L@l-daemon> for linux-mips@linux-mips.org; Thu, 05 Feb 2004 17:42:57 -0700 (MST) Received: (qmail 900 invoked by uid 10000); Thu, 05 Feb 2004 16:42:54 -0800 Date: Thu, 05 Feb 2004 16:42:54 -0800 From: "Robin H. Johnson" <robbat2@gentoo.org> Subject: SGI Octane support To: linux-mips@linux-mips.org Message-id: <20040206004254.GB32383@curie-int.orbis-terrarum.net> MIME-version: 1.0 Content-type: multipart/signed; boundary=yNb1oOkm5a9FJOVX; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.5.1i Return-Path: <robbat2@orbis-terrarum.net> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robbat2@gentoo.org Precedence: bulk X-list: linux-mips --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Just wondering about the status of SGI Octane support. I've just had a working Octane (300mhz R12k) given to me, so it's time to see about running it in Linux :-). I note that reading thru the mailing lists, there was some work on it last year, but then nothing more is mentioned. --=20 Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --yNb1oOkm5a9FJOVX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFAIuMOsnuUTjSIToURAmLAAJwIaw237qi8Y8cbstZb0z0fkEWDrQCffUo7 ehHgEENxu5msVZrogPz2KqQ= =+PLu -----END PGP SIGNATURE----- --yNb1oOkm5a9FJOVX-- From yuasa@hh.iij4u.or.jp Fri Feb 6 06:02:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 06:02:54 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:38107 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225200AbUBFGCw>; Fri, 6 Feb 2004 06:02:52 +0000 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 PAA08606; Fri, 6 Feb 2004 15:02:48 +0900 (JST) Received: 4UMDO01 id i1662lj27350; Fri, 6 Feb 2004 15:02:47 +0900 (JST) Received: 4UMRO01 id i1662ls07069; Fri, 6 Feb 2004 15:02:47 +0900 (JST) from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated) Date: Fri, 6 Feb 2004 15:02:47 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Removed no-used files for vr41xx Message-Id: <20040206150247.0beda507.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4303 X-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 Hello Ralf, I found some files which were not used. This patch removes them. Please apply this patch. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/ide-e55.c linux/arch/mips/vr41xx/casio-e55/ide-e55.c --- linux-orig/arch/mips/vr41xx/casio-e55/ide-e55.c 2002-10-04 01:58:02.000000000 +0900 +++ linux/arch/mips/vr41xx/casio-e55/ide-e55.c 1970-01-01 09:00:00.000000000 +0900 @@ -1,99 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * IDE routines for typical pc-like standard configurations - * for the CASIO CASSIOPEIA E-55/65. - * - * Copyright (C) 1998, 1999, 2001 by Ralf Baechle - */ -/* - * Changes: - * Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Sun, 24 Feb 2002 - * - Added CASIO CASSIOPEIA E-55/65 support. - */ -#include <linux/sched.h> -#include <linux/ide.h> -#include <linux/ioport.h> -#include <linux/hdreg.h> -#include <asm/ptrace.h> -#include <asm/hdreg.h> - -static int e55_ide_default_irq(ide_ioreg_t base) -{ - return 40; -} - -static ide_ioreg_t e55_ide_default_io_base(int index) -{ - switch (index) { - case 0: return 0xc1f0; - case 1: return 0xc170; - case 2: return 0xc1e8; - case 3: return 0xc168; - case 4: return 0xc1e0; - case 5: return 0xc160; - } - return 0; -} - -static void e55_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port, - ide_ioreg_t ctrl_port, int *irq) -{ - ide_ioreg_t reg = data_port; - int i; - - for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) { - hw->io_ports[i] = reg; - reg += 1; - } - if (ctrl_port) { - hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; - } else { - hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206; - } - if (irq != NULL) - *irq = 0; - hw->io_ports[IDE_IRQ_OFFSET] = 0; -} - -static int e55_ide_request_irq(unsigned int irq, - void (*handler)(int,void *, struct pt_regs *), - unsigned long flags, const char *device, - void *dev_id) -{ - return request_irq(irq, handler, flags, device, dev_id); -} - -static void e55_ide_free_irq(unsigned int irq, void *dev_id) -{ - free_irq(irq, dev_id); -} - -static int e55_ide_check_region(ide_ioreg_t from, unsigned int extent) -{ - return check_region(from, extent); -} - -static void e55_ide_request_region(ide_ioreg_t from, unsigned int extent, - const char *name) -{ - request_region(from, extent, name); -} - -static void e55_ide_release_region(ide_ioreg_t from, unsigned int extent) -{ - release_region(from, extent); -} - -struct ide_ops e55_ide_ops = { - &e55_ide_default_irq, - &e55_ide_default_io_base, - &e55_ide_init_hwif_ports, - &e55_ide_request_irq, - &e55_ide_free_irq, - &e55_ide_check_region, - &e55_ide_request_region, - &e55_ide_release_region -}; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/ide-workpad.c linux/arch/mips/vr41xx/ibm-workpad/ide-workpad.c --- linux-orig/arch/mips/vr41xx/ibm-workpad/ide-workpad.c 2002-10-04 01:58:02.000000000 +0900 +++ linux/arch/mips/vr41xx/ibm-workpad/ide-workpad.c 1970-01-01 09:00:00.000000000 +0900 @@ -1,98 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * IDE routines for typical pc-like standard configurations for the IBM WorkPad z50. - * - * Copyright (C) 1998, 1999, 2001 by Ralf Baechle - */ -/* - * Changes: - * Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Sun, 24 Feb 2002 - * - Added IBM WorkPad z50 support. - */ -#include <linux/sched.h> -#include <linux/ide.h> -#include <linux/ioport.h> -#include <linux/hdreg.h> -#include <asm/ptrace.h> -#include <asm/hdreg.h> - -static int workpad_ide_default_irq(ide_ioreg_t base) -{ - return 49; -} - -static ide_ioreg_t workpad_ide_default_io_base(int index) -{ - switch (index) { - case 0: return 0x1f0; - case 1: return 0x170; - case 2: return 0x1e8; - case 3: return 0x168; - case 4: return 0x1e0; - case 5: return 0x160; - } - return 0; -} - -static void workpad_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port, - ide_ioreg_t ctrl_port, int *irq) -{ - ide_ioreg_t reg = data_port; - int i; - - for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) { - hw->io_ports[i] = reg; - reg += 1; - } - if (ctrl_port) { - hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; - } else { - hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206; - } - if (irq != NULL) - *irq = 0; - hw->io_ports[IDE_IRQ_OFFSET] = 0; -} - -static int workpad_ide_request_irq(unsigned int irq, - void (*handler)(int,void *, struct pt_regs *), - unsigned long flags, const char *device, - void *dev_id) -{ - return request_irq(irq, handler, SA_SHIRQ, device, dev_id); -} - -static void workpad_ide_free_irq(unsigned int irq, void *dev_id) -{ - free_irq(irq, dev_id); -} - -static int workpad_ide_check_region(ide_ioreg_t from, unsigned int extent) -{ - return check_region(from, extent); -} - -static void workpad_ide_request_region(ide_ioreg_t from, unsigned int extent, - const char *name) -{ - request_region(from, extent, name); -} - -static void workpad_ide_release_region(ide_ioreg_t from, unsigned int extent) -{ - release_region(from, extent); -} - -struct ide_ops workpad_ide_ops = { - &workpad_ide_default_irq, - &workpad_ide_default_io_base, - &workpad_ide_init_hwif_ports, - &workpad_ide_request_irq, - &workpad_ide_free_irq, - &workpad_ide_check_region, - &workpad_ide_request_region, - &workpad_ide_release_region -}; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/ide-eagle.c linux/arch/mips/vr41xx/nec-eagle/ide-eagle.c --- linux-orig/arch/mips/vr41xx/nec-eagle/ide-eagle.c 2002-08-06 08:53:36.000000000 +0900 +++ linux/arch/mips/vr41xx/nec-eagle/ide-eagle.c 1970-01-01 09:00:00.000000000 +0900 @@ -1,96 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * IDE routines for typical pc-like standard configurations - * for the NEC Eagle/Hawk board. - * - * Copyright (C) 1998, 1999, 2001 by Ralf Baechle - */ -/* - * Changes: - * MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com> - * Fri, 5 Apr 2002 - * - Added support for NEC Hawk. - * - * MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com> - * Fri, 1 Mar 2002 - * - Added support for NEC Eagle. - */ -#include <linux/sched.h> -#include <linux/ide.h> -#include <linux/ioport.h> -#include <linux/hdreg.h> -#include <asm/ptrace.h> -#include <asm/hdreg.h> - -static int eagle_ide_default_irq(ide_ioreg_t base) -{ - return 0; -} - -static ide_ioreg_t eagle_ide_default_io_base(int index) -{ - return 0; -} - -static void eagle_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port, - ide_ioreg_t ctrl_port, int *irq) -{ - ide_ioreg_t reg = data_port; - int i; - - for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) { - hw->io_ports[i] = reg; - reg += 1; - } - if (ctrl_port) { - hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; - } else { - hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206; - } - if (irq != NULL) - *irq = 0; - hw->io_ports[IDE_IRQ_OFFSET] = 0; -} - -static int eagle_ide_request_irq(unsigned int irq, - void (*handler)(int,void *, struct pt_regs *), - unsigned long flags, const char *device, - void *dev_id) -{ - return request_irq(irq, handler, SA_SHIRQ, device, dev_id); -} - -static void eagle_ide_free_irq(unsigned int irq, void *dev_id) -{ - free_irq(irq, dev_id); -} - -static int eagle_ide_check_region(ide_ioreg_t from, unsigned int extent) -{ - return check_region(from, extent); -} - -static void eagle_ide_request_region(ide_ioreg_t from, unsigned int extent, - const char *name) -{ - request_region(from, extent, name); -} - -static void eagle_ide_release_region(ide_ioreg_t from, unsigned int extent) -{ - release_region(from, extent); -} - -struct ide_ops eagle_ide_ops = { - &eagle_ide_default_irq, - &eagle_ide_default_io_base, - &eagle_ide_init_hwif_ports, - &eagle_ide_request_irq, - &eagle_ide_free_irq, - &eagle_ide_check_region, - &eagle_ide_request_region, - &eagle_ide_release_region -}; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c linux/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c 2002-10-04 01:58:02.000000000 +0900 +++ linux/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c 1970-01-01 09:00:00.000000000 +0900 @@ -1,91 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * IDE routines for typical pc-like standard configurations - * for the ZAO Networks Capcella. - * - * Copyright (C) 1998, 1999, 2001 by Ralf Baechle - */ -/* - * Changes: - * Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Fri, 23 Aug 2002 - * - Added Victor MP-C303/304 support. - */ -#include <linux/sched.h> -#include <linux/ide.h> -#include <linux/ioport.h> -#include <linux/hdreg.h> -#include <asm/ptrace.h> -#include <asm/hdreg.h> - -static int mpc30x_ide_default_irq(ide_ioreg_t base) -{ - return 0; -} - -static ide_ioreg_t mpc30x_ide_default_io_base(int index) -{ - return 0; -} - -static void mpc30x_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port, - ide_ioreg_t ctrl_port, int *irq) -{ - ide_ioreg_t reg = data_port; - int i; - - for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) { - hw->io_ports[i] = reg; - reg += 1; - } - if (ctrl_port) { - hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; - } else { - hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206; - } - if (irq != NULL) - *irq = 0; - hw->io_ports[IDE_IRQ_OFFSET] = 0; -} - -static int mpc30x_ide_request_irq(unsigned int irq, - void (*handler)(int,void *, struct pt_regs *), - unsigned long flags, const char *device, - void *dev_id) -{ - return request_irq(irq, handler, flags, device, dev_id); -} - -static void mpc30x_ide_free_irq(unsigned int irq, void *dev_id) -{ - free_irq(irq, dev_id); -} - -static int mpc30x_ide_check_region(ide_ioreg_t from, unsigned int extent) -{ - return check_region(from, extent); -} - -static void mpc30x_ide_request_region(ide_ioreg_t from, unsigned int extent, - const char *name) -{ - request_region(from, extent, name); -} - -static void mpc30x_ide_release_region(ide_ioreg_t from, unsigned int extent) -{ - release_region(from, extent); -} - -struct ide_ops mpc30x_ide_ops = { - &mpc30x_ide_default_irq, - &mpc30x_ide_default_io_base, - &mpc30x_ide_init_hwif_ports, - &mpc30x_ide_request_irq, - &mpc30x_ide_free_irq, - &mpc30x_ide_check_region, - &mpc30x_ide_request_region, - &mpc30x_ide_release_region -}; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/ide-capcella.c linux/arch/mips/vr41xx/zao-capcella/ide-capcella.c --- linux-orig/arch/mips/vr41xx/zao-capcella/ide-capcella.c 2002-08-06 08:53:36.000000000 +0900 +++ linux/arch/mips/vr41xx/zao-capcella/ide-capcella.c 1970-01-01 09:00:00.000000000 +0900 @@ -1,99 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * IDE routines for typical pc-like standard configurations - * for the ZAO Networks Capcella. - * - * Copyright (C) 1998, 1999, 2001 by Ralf Baechle - */ -/* - * Changes: - * Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Sun, 24 Feb 2002 - * - Added ZAO Networks Capcella support. - */ -#include <linux/sched.h> -#include <linux/ide.h> -#include <linux/ioport.h> -#include <linux/hdreg.h> -#include <asm/ptrace.h> -#include <asm/hdreg.h> - -static int capcella_ide_default_irq(ide_ioreg_t base) -{ - switch (base) { - case 0x8300: return 42; - } - - return 0; -} - -static ide_ioreg_t capcella_ide_default_io_base(int index) -{ - switch (index) { - case 0: return 0x8300; - } - - return 0; -} - -static void capcella_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port, - ide_ioreg_t ctrl_port, int *irq) -{ - ide_ioreg_t reg = data_port; - int i; - - for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) { - hw->io_ports[i] = reg; - reg += 1; - } - if (ctrl_port) { - hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; - } else { - hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206; - } - if (irq != NULL) - *irq = 0; - hw->io_ports[IDE_IRQ_OFFSET] = 0; -} - -static int capcella_ide_request_irq(unsigned int irq, - void (*handler)(int,void *, struct pt_regs *), - unsigned long flags, const char *device, - void *dev_id) -{ - return request_irq(irq, handler, flags, device, dev_id); -} - -static void capcella_ide_free_irq(unsigned int irq, void *dev_id) -{ - free_irq(irq, dev_id); -} - -static int capcella_ide_check_region(ide_ioreg_t from, unsigned int extent) -{ - return check_region(from, extent); -} - -static void capcella_ide_request_region(ide_ioreg_t from, unsigned int extent, - const char *name) -{ - request_region(from, extent, name); -} - -static void capcella_ide_release_region(ide_ioreg_t from, unsigned int extent) -{ - release_region(from, extent); -} - -struct ide_ops capcella_ide_ops = { - &capcella_ide_default_irq, - &capcella_ide_default_io_base, - &capcella_ide_init_hwif_ports, - &capcella_ide_request_irq, - &capcella_ide_free_irq, - &capcella_ide_check_region, - &capcella_ide_request_region, - &capcella_ide_release_region -}; From sathis@pst.fujitsu.com Fri Feb 6 06:24:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 06:24:44 +0000 (GMT) Received: from fgwmail5.fujitsu.co.jp ([IPv6:::ffff:192.51.44.35]:40885 "EHLO fgwmail5.fujitsu.co.jp") by linux-mips.org with ESMTP id <S8225331AbUBFGYo>; Fri, 6 Feb 2004 06:24:44 +0000 Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail5.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i166OaDX018439 for <linux-mips@linux-mips.org>; Fri, 6 Feb 2004 15:24:36 +0900 (envelope-from sathis@pst.fujitsu.com) Received: from s2.gw.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i166OamL017485 for <linux-mips@linux-mips.org>; Fri, 6 Feb 2004 15:24:36 +0900 (envelope-from sathis@pst.fujitsu.com) Received: from classic.aoi.pst.fujitsu.com (classic.aoi.pst.fujitsu.com [10.90.149.12]) by s2.gw.fujitsu.co.jp (8.12.10) id i166OYsU005174 for <linux-mips@linux-mips.org>; Fri, 6 Feb 2004 15:24:34 +0900 (envelope-from sathis@pst.fujitsu.com) Received: from dhcp155-202.aoi.pst.fujitsu.com (dhcp155-202.aoi.pst.fujitsu.com [10.90.155.202]) by classic.aoi.pst.fujitsu.com (8.9.3/8.9.3) with ESMTP id PAA19169 for <linux-mips@linux-mips.org>; Fri, 6 Feb 2004 15:24:34 +0900 Subject: How to access from MSR? From: sathis <sathis@pst.fujitsu.com> To: linux-mips@linux-mips.org Content-Type: text/plain Organization: Message-Id: <1076113438.5027.10.camel@indo-fuji1> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 06 Feb 2004 15:23:58 -0900 Content-Transfer-Encoding: 7bit Return-Path: <sathis@pst.fujitsu.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sathis@pst.fujitsu.com Precedence: bulk X-list: linux-mips HI, I want to access Machine State Register for MIPS. is there any macro in linux kernel? Regards, Sathis From yuasa@hh.iij4u.or.jp Fri Feb 6 07:21:13 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 07:21:14 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:34002 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225331AbUBFHVN>; Fri, 6 Feb 2004 07:21:13 +0000 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id QAA16188; Fri, 6 Feb 2004 16:21:09 +0900 (JST) Received: 4UMDO01 id i167L9j28130; Fri, 6 Feb 2004 16:21:09 +0900 (JST) Received: 4UMRO00 id i167L8N00830; Fri, 6 Feb 2004 16:21:08 +0900 (JST) from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated) Date: Fri, 6 Feb 2004 16:21:09 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Merged vr41xx_pci_ops into vr41xx.h Message-Id: <20040206162109.3a9e6bad.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4305 X-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 Hello Ralf, I made a patch for vr41xx PCI. "vr41xx_pci_ops" which has more than one were merged into vr41xx.h. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c 2004-02-06 11:21:47.000000000 +0900 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c 2004-02-06 15:51:03.000000000 +0900 @@ -70,8 +70,6 @@ IORESOURCE_MEM }; -extern struct pci_ops vr41xx_pci_ops; - struct pci_channel mips_pci_channels[] = { {&vr41xx_pci_ops, &vr41xx_pci_io_resource, &vr41xx_pci_mem_resource, 0, 256}, {NULL, NULL, NULL, 0, 0} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c 2004-02-06 11:21:47.000000000 +0900 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c 2004-02-06 15:51:03.000000000 +0900 @@ -38,8 +38,6 @@ IORESOURCE_MEM }; -extern struct pci_ops vr41xx_pci_ops; - struct pci_channel mips_pci_channels[] = { {&vr41xx_pci_ops, &vr41xx_pci_io_resource, &vr41xx_pci_mem_resource, 0, 256}, {NULL, NULL, NULL, 0, 0} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c 2004-02-06 11:21:47.000000000 +0900 +++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c 2004-02-06 15:51:03.000000000 +0900 @@ -43,8 +43,6 @@ .flags = IORESOURCE_MEM, }; -extern struct pci_ops vr41xx_pci_ops; - struct pci_channel mips_pci_channels[] = { { .pci_ops = &vr41xx_pci_ops, .io_resource = &vr41xx_pci_io_resource, diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c 2004-02-06 11:21:47.000000000 +0900 +++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c 2004-02-06 15:51:03.000000000 +0900 @@ -39,8 +39,6 @@ IORESOURCE_MEM }; -extern struct pci_ops vr41xx_pci_ops; - struct pci_channel mips_pci_channels[] = { {&vr41xx_pci_ops, &vr41xx_pci_io_resource, &vr41xx_pci_mem_resource, 0, 256}, {NULL, NULL, NULL, 0, 0} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c --- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c 2004-02-06 11:21:47.000000000 +0900 +++ linux/arch/mips/vr41xx/zao-capcella/setup.c 2004-02-06 15:51:03.000000000 +0900 @@ -39,8 +39,6 @@ IORESOURCE_MEM }; -extern struct pci_ops vr41xx_pci_ops; - struct pci_channel mips_pci_channels[] = { {&vr41xx_pci_ops, &vr41xx_pci_io_resource, &vr41xx_pci_mem_resource, 0, 256}, {NULL, NULL, NULL, 0, 0} diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h 2003-12-16 05:27:37.000000000 +0900 +++ linux/include/asm-mips/vr41xx/vr41xx.h 2004-02-06 15:51:03.000000000 +0900 @@ -221,6 +221,8 @@ extern void vr41xx_pciu_init(struct vr41xx_pci_address_map *map); +extern struct pci_ops vr41xx_pci_ops; + /* * MISC */ From dahms@zeus.fh-brandenburg.de Fri Feb 6 11:06:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 11:06:56 +0000 (GMT) Received: from baldur.fh-brandenburg.de ([IPv6:::ffff:195.37.0.5]:44731 "HELO baldur.fh-brandenburg.de") by linux-mips.org with SMTP id <S8225380AbUBFLGz>; Fri, 6 Feb 2004 11:06:55 +0000 Received: (1552 bytes) by baldur.fh-brandenburg.de via sendmail with P:stdio/R:match-inet-hosts/T:smtp (sender: <dahms@zeus.fh-brandenburg.de>) id <m1Ap3n8-000pvNC@baldur.fh-brandenburg.de> for <linux-mips@linux-mips.org>; Fri, 6 Feb 2004 12:04:58 +0100 (MET) (Smail-3.2.0.97 1997-Aug-19 #3 built DST-Sep-15) Received: from zeus.fh-brandenburg.de(195.37.1.35) via SMTP by baldur.fh-brandenburg.de, id smtpdAAAa0053g; Fri Feb 6 11:21:16 2004 Received: (from dahms@localhost) by zeus.fh-brandenburg.de (8.11.7p1+Sun/8.11.7) id i16ALFr00092; Fri, 6 Feb 2004 11:21:15 +0100 (MET) Date: Fri, 6 Feb 2004 11:21:15 +0100 From: Markus Dahms <dahms@fh-brandenburg.de> To: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Subject: Re: Indy R4000PC problems Message-ID: <20040206102115.GA7490@fh-brandenburg.de> References: <20040202160729.GA5966@fh-brandenburg.de> <20040205175146.GA18162@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040205175146.GA18162@linux-mips.org> User-Agent: Mutt/1.4.1i Return-Path: <dahms@zeus.fh-brandenburg.de> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dahms@fh-brandenburg.de Precedence: bulk X-list: linux-mips Hallo Ralf Baechle, [R4000PC] > Do you know which version of the processor this is exactly? IRIX's hinv > command or the "CPU revision is: ..." line of bootup messages contain > that information. R4000 V3.0 I believe. I'll check it, when I'm at home again. > The PC version have become pretty rare, didn't recall anymore it was in > use in Indys at all. Anyway, please try the patch below and let me know. I checked the cvs version from yesterday (20040205), which contained some changes in cpu-probe.c; it worked! Greetings, Markus PS: sorry for the response times, our mail system is totally overloaded at the moment. -- Disc space -- the final frontier! From dahms@zeus.fh-brandenburg.de Fri Feb 6 14:14:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 14:14:20 +0000 (GMT) Received: from baldur.fh-brandenburg.de ([IPv6:::ffff:195.37.0.5]:20933 "HELO baldur.fh-brandenburg.de") by linux-mips.org with SMTP id <S8225467AbUBFOOU>; Fri, 6 Feb 2004 14:14:20 +0000 Received: (1386 bytes) by baldur.fh-brandenburg.de via sendmail with P:stdio/R:match-inet-hosts/T:smtp (sender: <dahms@zeus.fh-brandenburg.de>) id <m1Ap6i1-000psMC@baldur.fh-brandenburg.de> for <linux-mips@linux-mips.org>; Fri, 6 Feb 2004 15:11:53 +0100 (MET) (Smail-3.2.0.97 1997-Aug-19 #3 built DST-Sep-15) Received: from zeus.fh-brandenburg.de(195.37.1.35) via SMTP by baldur.fh-brandenburg.de, id smtpdAAAa005XJ; Fri Feb 6 14:46:56 2004 Received: (from dahms@localhost) by zeus.fh-brandenburg.de (8.11.7p1+Sun/8.11.7) id i16Dktl08880; Fri, 6 Feb 2004 14:46:55 +0100 (MET) Date: Fri, 6 Feb 2004 14:46:55 +0100 From: Markus Dahms <dahms@fh-brandenburg.de> To: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Subject: Re: Indy R4000PC problems Message-ID: <20040206134655.GA17745@fh-brandenburg.de> References: <20040202160729.GA5966@fh-brandenburg.de> <20040205175146.GA18162@linux-mips.org> <20040206102115.GA7490@fh-brandenburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040206102115.GA7490@fh-brandenburg.de> User-Agent: Mutt/1.4.1i Return-Path: <dahms@zeus.fh-brandenburg.de> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dahms@fh-brandenburg.de Precedence: bulk X-list: linux-mips > [R4000PC] >> Do you know which version of the processor this is exactly? IRIX's hinv >> command or the "CPU revision is: ..." line of bootup messages contain >> that information. > R4000 V3.0 I believe. I'll check it, when I'm at home again. checked it: [dmesg] | CPU revision is: 00000430 | FPU revision is: 00000500 [/proc/cpuinfo] | cpu model : R4000PC V3.0 FPU V0.0 Markus -- Any given program will expand to fill available memory. From ralf@linux-mips.org Fri Feb 6 14:22:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 14:22:52 +0000 (GMT) Received: from p508B7C9B.dip.t-dialin.net ([IPv6:::ffff:80.139.124.155]:54300 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id <S8225467AbUBFOWv>; Fri, 6 Feb 2004 14:22:51 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i16EMcex004348 for <linux-mips@linux-mips.org>; Fri, 6 Feb 2004 15:22:38 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i16EM1gr004344; Fri, 6 Feb 2004 15:22:01 +0100 Date: Fri, 6 Feb 2004 15:22:01 +0100 From: Ralf Baechle <ralf@linux-mips.org> To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> Cc: linux-mips@linux-mips.org Subject: R4[04]00SC Message-ID: <20040206142201.GA4275@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: <ralf@linux-mips.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4308 X-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 We still have this stuff in flush_cache_mm(): /* * Kludge alert. For obscure reasons R4000SC and R4400SC go nuts if we * only flush the primary caches but R10000 and R12000 behave sane ... */ if (current_cpu_data.cputype == CPU_R4000SC || current_cpu_data.cputype == CPU_R4000MC || current_cpu_data.cputype == CPU_R4400SC || current_cpu_data.cputype == CPU_R4400MC) r4k_blast_scache(); You have any idea what might make this necessary? This slows down SC systems quite badly but makes the compiler from eleminating the call to r4k_blast_scache() on systems that don't have one of these processors. Could be kludged a bit by also testing cpu_has_subset_pcaches() but that'd be a hack. Ralf From ralf@linux-mips.org Fri Feb 6 14:45:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Feb 2004 14:45:36 +0000 (GMT) Received: from p508B7C9B.dip.t-dialin.net ([IPv6:::ffff:80.139.124.155]:4381 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id <S8225478AbUBFOpf>; Fri, 6 Feb 2004 14:45:35 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i16Eirex004703; Fri, 6 Feb 2004 15:44:53 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i16EirYQ004702; Fri, 6 Feb 2004 15:44:53 +0100 Date: Fri, 6 Feb 2004 15:44:53 +0100 From: Ralf Baechle <ralf@linux-mips.org> To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Cc: linux-mips <linux-mips@linux-mips.org> Subject: Re: [PATCH][2.4] Removed no-used files for vr41xx Message-ID: <20040206144453.GA4600@linux-mips.org> References: <20040206150247.0beda507.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040206150247.0beda507.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.1i Return-Path: <ralf@linux-mips.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4309 X-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, Feb 06, 2004 at 03:02:47PM +0900, Yoichi Yuasa wrote: > I found some files which were not used. > This patch removes them. Applied, Ralf From yuasa@hh.iij4u.or.jp Sat Feb 7 13:33:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Feb 2004 13:33:55 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:18172 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225203AbUBGNdz>; Sat, 7 Feb 2004 13:33:55 +0000 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 WAA12633; Sat, 7 Feb 2004 22:33:50 +0900 (JST) Received: 4UMDO01 id i17DXof10950; Sat, 7 Feb 2004 22:33:50 +0900 (JST) Received: 4UMRO01 id i17DXmB17565; Sat, 7 Feb 2004 22:33:49 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Sat, 7 Feb 2004 22:33:43 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Changed NEC Eagle's IRQ routines Message-Id: <20040207223343.032161b6.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4310 X-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 Hello Ralf, I made a patch for IRQ routines of NEC Eagle. This patch changes the registration method of IRQ routines. Please apply this patch to v2.4. 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 Tue Jan 13 08:16:58 2004 +++ linux/arch/mips/vr41xx/common/giu.c Sat Feb 7 21:32:13 2004 @@ -271,8 +271,6 @@ return retval; } -void (*board_irq_init)(void) = NULL; - void __init vr41xx_giuint_init(void) { int i; @@ -300,7 +298,4 @@ if (setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade)) printk("GIUINT: Can not cascade IRQ %d.\n", GIUINT_CASCADE_IRQ); - - if (board_irq_init) - board_irq_init(); } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/irq.c linux/arch/mips/vr41xx/nec-eagle/irq.c --- linux-orig/arch/mips/vr41xx/nec-eagle/irq.c Thu Dec 12 10:10:09 2002 +++ linux/arch/mips/vr41xx/nec-eagle/irq.c Sat Feb 7 22:06:51 2004 @@ -1,64 +1,49 @@ /* - * FILE NAME - * arch/mips/vr41xx/nec-eagle/irq.c + * arch/mips/vr41xx/nec-eagle/irq.c * - * BRIEF MODULE DESCRIPTION - * Interrupt routines for the NEC Eagle/Hawk board. + * Interrupt routines for the NEC Eagle/Hawk board. * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * Author: Yoichi Yuasa <yyuasa@mvista.com, or source@mvista.com> * - * Copyright 2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * 2002-2003 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. */ /* * Changes: * MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com> - * - Added support for NEC Hawk. - * - * MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com> * - New creation, NEC Eagle is supported. + * - Added support for NEC Hawk. */ +#include <linux/config.h> #include <linux/init.h> #include <linux/interrupt.h> +#include <linux/module.h> +#include <linux/types.h> #include <asm/io.h> #include <asm/vr41xx/eagle.h> +MODULE_DESCRIPTION("SDB/PCIINT IRQ driver for NEC Eagle/Hawk"); +MODULE_AUTHOR("Yoichi Yuasa <yyuasa@mvista.com>"); +MODULE_LICENSE("GPL"); + static void enable_pciint_irq(unsigned int irq) { - u8 val; + uint8_t val; val = readb(NEC_EAGLE_PCIINTMSKREG); - val |= (u8)1 << (irq - PCIINT_IRQ_BASE); + val |= (uint8_t)1 << (irq - PCIINT_IRQ_BASE); writeb(val, NEC_EAGLE_PCIINTMSKREG); } static void disable_pciint_irq(unsigned int irq) { - u8 val; + uint8_t val; val = readb(NEC_EAGLE_PCIINTMSKREG); - val &= ~((u8)1 << (irq - PCIINT_IRQ_BASE)); + val &= ~((uint8_t)1 << (irq - PCIINT_IRQ_BASE)); writeb(val, NEC_EAGLE_PCIINTMSKREG); } @@ -78,31 +63,30 @@ } static struct hw_interrupt_type pciint_irq_type = { - "PCIINT", - startup_pciint_irq, - shutdown_pciint_irq, - enable_pciint_irq, - disable_pciint_irq, - ack_pciint_irq, - end_pciint_irq, - NULL + .typename = "PCIINT", + .startup = startup_pciint_irq, + .shutdown = shutdown_pciint_irq, + .enable = enable_pciint_irq, + .disable = disable_pciint_irq, + .ack = ack_pciint_irq, + .end = end_pciint_irq, }; static void enable_sdbint_irq(unsigned int irq) { - u8 val; + uint8_t val; val = readb(NEC_EAGLE_SDBINTMSK); - val |= (u8)1 << (irq - SDBINT_IRQ_BASE); + val |= (uint8_t)1 << (irq - SDBINT_IRQ_BASE); writeb(val, NEC_EAGLE_SDBINTMSK); } static void disable_sdbint_irq(unsigned int irq) { - u8 val; + uint8_t val; val = readb(NEC_EAGLE_SDBINTMSK); - val &= ~((u8)1 << (irq - SDBINT_IRQ_BASE)); + val &= ~((uint8_t)1 << (irq - SDBINT_IRQ_BASE)); writeb(val, NEC_EAGLE_SDBINTMSK); } @@ -122,19 +106,18 @@ } static struct hw_interrupt_type sdbint_irq_type = { - "SDBINT", - startup_sdbint_irq, - shutdown_sdbint_irq, - enable_sdbint_irq, - disable_sdbint_irq, - ack_sdbint_irq, - end_sdbint_irq, - NULL + .typename = "SDBINT", + .startup = startup_sdbint_irq, + .shutdown = shutdown_sdbint_irq, + .enable = enable_sdbint_irq, + .disable = disable_sdbint_irq, + .ack = ack_sdbint_irq, + .end = end_sdbint_irq, }; static int eagle_get_irq_number(int irq) { - u8 sdbint, pciint; + uint8_t sdbint, pciint; int i; sdbint = readb(NEC_EAGLE_SDBINT); @@ -157,9 +140,9 @@ return -EINVAL; } -void __init eagle_irq_init(void) +static int __devinit eagle_irq_init(void) { - int i; + int i, retval; writeb(0, NEC_EAGLE_SDBINTMSK); writeb(0, NEC_EAGLE_PCIINTMSKREG); @@ -179,5 +162,17 @@ for (i = PCIINT_IRQ_BASE; i <= PCIINT_IRQ_LAST; i++) irq_desc[i].handler = &pciint_irq_type; - vr41xx_cascade_irq(FPGA_CASCADE_IRQ, eagle_get_irq_number); + retval = vr41xx_cascade_irq(FPGA_CASCADE_IRQ, eagle_get_irq_number); + if (retval != 0) + printk(KERN_ERR "eagle: Cannot cascade IRQ %d\n", FPGA_CASCADE_IRQ); + + return retval; } + +static void __devexit eagle_irq_exit(void) +{ + free_irq(FPGA_CASCADE_IRQ, NULL); +} + +module_init(eagle_irq_init); +module_exit(eagle_irq_exit); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Sat Feb 7 10:32:18 2004 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Sat Feb 7 21:32:55 2004 @@ -50,8 +50,6 @@ #include <asm/time.h> #include <asm/vr41xx/eagle.h> -extern void eagle_irq_init(void); - #ifdef CONFIG_PCI extern void vrc4173_preinit(void); @@ -114,8 +112,6 @@ board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; - - board_irq_init = eagle_irq_init; #ifdef CONFIG_FB conswitchp = &dummy_con; diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Sat Feb 7 10:32:42 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Sat Feb 7 21:37:18 2004 @@ -129,7 +129,6 @@ #define GIU_IRQ_LAST GIU_IRQ(31) #define GIU_IRQ_TO_PIN(x) ((x) - GIU_IRQ_BASE) /* Pin 0-31 */ -extern void (*board_irq_init)(void); extern int vr41xx_set_intassign(unsigned int irq, unsigned char intassign); extern int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq)); From pdh@colonel-panic.org Sun Feb 8 13:16:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Feb 2004 13:16:37 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:1921 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id <S8224987AbUBHNQg>; Sun, 8 Feb 2004 13:16:36 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.35 #1 (Debian)) id 1AponV-0001u9-00 for <linux-mips@linux-mips.org>; Sun, 08 Feb 2004 13:16:29 +0000 Date: Sun, 8 Feb 2004 13:16:29 +0000 To: linux-mips@linux-mips.org Subject: PCI resources on 2.6 [Cobalt Qube] Message-ID: <20040208131629.GA7276@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Peter Horton <pdh@colonel-panic.org> Return-Path: <pdh@colonel-panic.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips Hi. I'm working to get the 2.6 kernel booting on the Qube/RaQ, but the PCI resource stuff is giving me a hard time. I/O accesses using inb() etc are adjusted by Galileo's PCI I/O base thus 00000000 - 0000ffff --> b0000000 - b000ffff The problem is that Galileo passes I/O addresses straight to PCI so that a read of the RTC translates to a PCI address of 1000007[01]. This works fine for the stuff on the VIA south bridge as it doesn't seem to decode all 32 bits of the address for I/O accesses. But this doesn't work for the Tulip's, they must have the correct addresses written into the I/O BAR. If I change the PCI I/O resource range to 10000000 - 1000ffff, then inb() etc fail because they add Galileo's PCI I/O base again 10000000 - 1000ffff --> c0000000 - c000ffff !! causing a page fault. If I set the I/O port base to 00000000 to overcome this then accesses to the peripherals on the VIA south bridge don't get Galileo's PCI I/O base added and they land up accessing RAM. I effectively have two I/O ranges that need to map to the same addresses 00000000 - 0000ffff --> b0000000 - b000ffff (for VIA) 10000000 - 1000ffff --> b0000000 - b000ffff (for PCI) I was hopefull that the 'io_offset' field in 'struct pci_controller' would do this for me, but I can't work out what it does :-| This all worked in 2.4 as it's actually the boot loader that maps the Tulip's into the I/O address space and the kernel has hardcoded resource entries to match. P. From wli@holomorphy.com Sun Feb 8 14:36:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Feb 2004 14:36:24 +0000 (GMT) Received: from holomorphy.com ([IPv6:::ffff:199.26.172.102]:24994 "EHLO holomorphy.com") by linux-mips.org with ESMTP id <S8225210AbUBHOgX>; Sun, 8 Feb 2004 14:36:23 +0000 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1Apq2j-0007Tc-00; Sun, 08 Feb 2004 06:36:17 -0800 Date: Sun, 8 Feb 2004 06:36:17 -0800 From: William Lee Irwin III <wli@holomorphy.com> To: linux-mips@linux-mips.org Cc: linux-cvs@linux-mips.org Subject: Re: CVS Update@-mips.org: linux Message-ID: <20040208143617.GC699@holomorphy.com> References: <20040208143438Z8224987-9616+1909@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040208143438Z8224987-9616+1909@linux-mips.org> Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: <wli@holomorphy.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wli@holomorphy.com Precedence: bulk X-list: linux-mips On Sun, Feb 08, 2004 at 02:34:34PM +0000, hch@linux-mips.org wrote: > CVSROOT: /home/cvs > Module name: linux > Changes by: hch@ftp.linux-mips.org 04/02/08 14:34:34 > Modified files: > include/asm-mips: mmzone.h > Log message: > Use the defintion of kern_addr_valid() from Linus tree instead of my variant. > This allows blaming wli for this POS instead of me ;) Hey! That bitmap was uninitialized (apart from being zeroed) in mainline. -- wli From hch@lst.de Sun Feb 8 14:40:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Feb 2004 14:40:55 +0000 (GMT) Received: from verein.lst.de ([IPv6:::ffff:212.34.189.10]:48521 "EHLO mail.lst.de") by linux-mips.org with ESMTP id <S8225234AbUBHOkz>; Sun, 8 Feb 2004 14:40:55 +0000 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i18EehQc001289 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 8 Feb 2004 15:40:44 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i18Eehes001287; Sun, 8 Feb 2004 15:40:43 +0100 Date: Sun, 8 Feb 2004 15:40:43 +0100 From: Christoph Hellwig <hch@lst.de> To: William Lee Irwin III <wli@holomorphy.com> Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@-mips.org: linux Message-ID: <20040208144042.GA1236@lst.de> References: <20040208143438Z8224987-9616+1909@linux-mips.org> <20040208143617.GC699@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040208143617.GC699@holomorphy.com> User-Agent: Mutt/1.3.28i X-Spam-Score: -4.901 () BAYES_00 X-Scanned-By: MIMEDefang 2.39 Return-Path: <hch@lst.de> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hch@lst.de Precedence: bulk X-list: linux-mips On Sun, Feb 08, 2004 at 06:36:17AM -0800, William Lee Irwin III wrote: > > Log message: > > Use the defintion of kern_addr_valid() from Linus tree instead of my variant. > > This allows blaming wli for this POS instead of me ;) > > Hey! That bitmap was uninitialized (apart from being zeroed) in mainline. I know. The comment was reffering to replacing a /* XXX(hch): better get rid of this thingy, it's rather fragile.. */ with an /* XXX: FIXME -- wli */ From ilya@gateway.total-knowledge.com Sun Feb 8 15:52:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Feb 2004 15:52:21 +0000 (GMT) Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:41346 "EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP id <S8225343AbUBHPwV>; Sun, 8 Feb 2004 15:52:21 +0000 Received: (qmail 28690 invoked from network); 8 Feb 2004 14:51:03 -0000 Received: from unknown (HELO gateway.total-knowledge.com) (24.6.229.199) by alpha.total-knowledge.com with DES-CBC3-SHA encrypted SMTP; 8 Feb 2004 14:51:03 -0000 Received: (qmail 3913 invoked by uid 502); 8 Feb 2004 07:52:16 -0800 Date: Sun, 8 Feb 2004 07:52:16 -0800 From: ilya@theIlya.com To: Peter Horton <pdh@colonel-panic.org> Cc: linux-mips@linux-mips.org Subject: Re: PCI resources on 2.6 [Cobalt Qube] Message-ID: <20040208155216.GA16130@gateway.total-knowledge.com> References: <20040208131629.GA7276@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040208131629.GA7276@skeleton-jack> User-Agent: Mutt/1.5.4i Return-Path: <ilya@gateway.total-knowledge.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@theIlya.com Precedence: bulk X-list: linux-mips you can do some messing with port addresses by implementing include/asm/mach-<your machine>/mangle-port.h Ilya. On Sun, Feb 08, 2004 at 01:16:29PM +0000, Peter Horton wrote: > Hi. > > I'm working to get the 2.6 kernel booting on the Qube/RaQ, but the PCI > resource stuff is giving me a hard time. > > I/O accesses using inb() etc are adjusted by Galileo's PCI I/O base > thus > > 00000000 - 0000ffff --> b0000000 - b000ffff > > The problem is that Galileo passes I/O addresses straight to PCI so that > a read of the RTC translates to a PCI address of 1000007[01]. This works > fine for the stuff on the VIA south bridge as it doesn't seem to decode > all 32 bits of the address for I/O accesses. But this doesn't work for > the Tulip's, they must have the correct addresses written into the I/O > BAR. > > If I change the PCI I/O resource range to 10000000 - 1000ffff, then > inb() etc fail because they add Galileo's PCI I/O base again > > 10000000 - 1000ffff --> c0000000 - c000ffff !! > > causing a page fault. > > If I set the I/O port base to 00000000 to overcome this then accesses to > the peripherals on the VIA south bridge don't get Galileo's PCI I/O base > added and they land up accessing RAM. > > I effectively have two I/O ranges that need to map to the same addresses > > 00000000 - 0000ffff --> b0000000 - b000ffff (for VIA) > 10000000 - 1000ffff --> b0000000 - b000ffff (for PCI) > > I was hopefull that the 'io_offset' field in 'struct pci_controller' > would do this for me, but I can't work out what it does :-| > > This all worked in 2.4 as it's actually the boot loader that maps the > Tulip's into the I/O address space and the kernel has hardcoded resource > entries to match. > > P. > From geert@linux-m68k.org Sun Feb 8 20:27:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Feb 2004 20:27:52 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:33696 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id <S8225237AbUBHU1v>; Sun, 8 Feb 2004 20:27:51 +0000 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i18KRlw2029865; Sun, 8 Feb 2004 21:27:47 +0100 (MET) Date: Sun, 8 Feb 2004 21:27:47 +0100 (MET) From: Geert Uytterhoeven <geert@linux-m68k.org> To: Ralf Baechle <ralf@linux-mips.org> cc: Linux/MIPS Development <linux-mips@linux-mips.org> Subject: [PATCH] NCR53C9x slave_{alloc,destroy}() (was: Re: [linux-mac68k] Re: Kernel 2.6.1 on 68k Macintosh (fwd)) Message-ID: <Pine.GSO.4.58.0402082122430.6076@waterleaf.sonytel.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: <geert@linux-m68k.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4315 X-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 This one affects MIPS as well (queued up for submission after 2.6.3). Subject: [PATCH] NCR53C9x slave_{alloc,destroy}() NCR53C9x: Add missing slave_{alloc,destroy}() (from Kars de Jong and Matthias Urlichs). This affects the following drivers: - Amiga Blizzard 1230, Blizzard 2060, CyberStorm, CyberStorm Mk II, Fastlane, and Oktagon SCSI - DECstation NCR53C94 SCSI - Jazz ESP 100/100a/200 SCSI - Mac 53C9x SCSI - MCA NCR 53c9x SCSI - Sun-3x SCSI (was already fixed on its own) ---------- Forwarded message ---------- Date: Thu, 05 Feb 2004 21:34:56 +0100 From: Kars de Jong <jongk@linux-m68k.org> To: Ray Knight <audilvr@speakeasy.org> Cc: Linux/m68k kernel mailing list <linux-m68k@lists.linux-m68k.org>, Mac68k Linux Mailing List <linux-mac68k@mac.linux-m68k.org> Subject: Re: [linux-mac68k] Re: Kernel 2.6.1 on 68k Macintosh On Thu, 2004-02-05 at 21:04, Kars de Jong wrote: > On Thu, 2004-02-05 at 07:10, Ray Knight wrote: > > On Wed, 2004-02-04 at 16:28, Kars de Jong wrote: > > > I finally got around to installing the 2.6 source tree (got me a new > > > harddisk, yay) and compiling a kernel and booting it on my A1200 gives > > > the same error. It also uses the NCR53C9x driver. Since I'm supposed to > > > be maintaining that driver I'll have a look at it :-P > > > > > > > > Will you be checking any changes into CVS? If not could you send me any > > patches? > > I don't have commit access, but I usually send patches to the Linux/m68k > kernel mailing list. I'll Cc: to you. > > Preliminary investigation shows that SDptr->hostdata is NULL. Some > fields which used to be in Scsi_Device are now in a driver private > structure. It looks like some changes were copied from the Sun ESP > driver but not quite enough (slave_alloc() and slave_destroy() should > probably be defined). Yes, that was it. Apparently this was already fixed by the Sun3 people, just not applied to all drivers using the NCR53C9x core... After applying the following diff my system boots and the disks seem to work OK. Keyboard works, framebuffer works (except switching screenmode with fbset looks ... odd). Have fun! Kars. Index: drivers/scsi/NCR53C9x.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/NCR53C9x.c,v retrieving revision 1.1.1.21 diff -u -r1.1.1.21 NCR53C9x.c --- drivers/scsi/NCR53C9x.c 24 Nov 2003 21:12:33 -0000 1.1.1.21 +++ drivers/scsi/NCR53C9x.c 5 Feb 2004 20:23:11 -0000 @@ -3615,6 +3615,27 @@ } #endif +int esp_slave_alloc(Scsi_Device *SDptr) +{ + struct esp_device *esp_dev = + kmalloc(sizeof(struct esp_device), GFP_ATOMIC); + + if (!esp_dev) + return -ENOMEM; + memset(esp_dev, 0, sizeof(struct esp_device)); + SDptr->hostdata = esp_dev; + return 0; +} + +void esp_slave_destroy(Scsi_Device *SDptr) +{ + struct NCR_ESP *esp = (struct NCR_ESP *) SDptr->host->hostdata; + + esp->targets_present &= ~(1 << SDptr->id); + kfree(SDptr->hostdata); + SDptr->hostdata = NULL; +} + #ifdef MODULE int init_module(void) { return 0; } void cleanup_module(void) {} Index: drivers/scsi/NCR53C9x.h =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/NCR53C9x.h,v retrieving revision 1.4 diff -u -r1.4 NCR53C9x.h --- drivers/scsi/NCR53C9x.h 30 Nov 2003 19:30:23 -0000 1.4 +++ drivers/scsi/NCR53C9x.h 5 Feb 2004 20:23:17 -0000 @@ -665,4 +665,6 @@ extern int esp_reset(Scsi_Cmnd *); extern int esp_proc_info(struct Scsi_Host *shost, char *buffer, char **start, off_t offset, int length, int inout); +extern int esp_slave_alloc(Scsi_Device *); +extern void esp_slave_destroy(Scsi_Device *); #endif /* !(NCR53C9X_H) */ Index: drivers/scsi/blz1230.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/blz1230.c,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 blz1230.c --- drivers/scsi/blz1230.c 27 Jul 2003 20:13:06 -0000 1.1.1.8 +++ drivers/scsi/blz1230.c 5 Feb 2004 20:23:17 -0000 @@ -333,6 +333,8 @@ .proc_info = esp_proc_info, .name = "Blizzard1230 SCSI IV", .detect = blz1230_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = blz1230_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, Index: drivers/scsi/blz2060.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/blz2060.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 blz2060.c --- drivers/scsi/blz2060.c 27 Jul 2003 20:13:06 -0000 1.1.1.7 +++ drivers/scsi/blz2060.c 5 Feb 2004 20:23:17 -0000 @@ -287,6 +287,8 @@ .proc_info = esp_proc_info, .name = "Blizzard2060 SCSI", .detect = blz2060_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = blz2060_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, Index: drivers/scsi/cyberstorm.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/cyberstorm.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 cyberstorm.c --- drivers/scsi/cyberstorm.c 27 Jul 2003 20:13:08 -0000 1.1.1.7 +++ drivers/scsi/cyberstorm.c 5 Feb 2004 20:23:17 -0000 @@ -358,6 +358,8 @@ .proc_info = esp_proc_info, .name = "CyberStorm SCSI", .detect = cyber_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = cyber_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, Index: drivers/scsi/cyberstormII.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/cyberstormII.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 cyberstormII.c --- drivers/scsi/cyberstormII.c 27 Jul 2003 20:13:08 -0000 1.1.1.7 +++ drivers/scsi/cyberstormII.c 5 Feb 2004 20:23:17 -0000 @@ -295,6 +295,8 @@ .proc_info = esp_proc_info, .name = "CyberStorm Mk II SCSI", .detect = cyberII_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = cyberII_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, Index: drivers/scsi/dec_esp.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/dec_esp.c,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 dec_esp.c --- drivers/scsi/dec_esp.c 27 Jul 2003 20:13:09 -0000 1.1.1.5 +++ drivers/scsi/dec_esp.c 5 Feb 2004 20:23:17 -0000 @@ -124,6 +124,8 @@ .proc_info = &esp_proc_info, .name = "NCR53C94", .detect = dec_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = dec_esp_release, .info = esp_info, .queuecommand = esp_queue, Index: drivers/scsi/fastlane.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/fastlane.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 fastlane.c --- drivers/scsi/fastlane.c 27 Jul 2003 20:13:10 -0000 1.1.1.7 +++ drivers/scsi/fastlane.c 5 Feb 2004 20:23:18 -0000 @@ -404,6 +404,8 @@ .proc_info = esp_proc_info, .name = "Fastlane SCSI", .detect = fastlane_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = fastlane_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, Index: drivers/scsi/jazz_esp.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/jazz_esp.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 jazz_esp.c --- drivers/scsi/jazz_esp.c 27 Jul 2003 20:13:15 -0000 1.1.1.7 +++ drivers/scsi/jazz_esp.c 5 Feb 2004 20:23:18 -0000 @@ -290,6 +290,8 @@ .proc_info = &esp_proc_info, .name = "ESP 100/100a/200", .detect = jazz_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = jazz_esp_release, .info = esp_info, .queuecommand = esp_queue, Index: drivers/scsi/mac_esp.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/mac_esp.c,v retrieving revision 1.11 diff -u -r1.11 mac_esp.c --- drivers/scsi/mac_esp.c 30 Nov 2003 19:30:23 -0000 1.11 +++ drivers/scsi/mac_esp.c 5 Feb 2004 20:23:20 -0000 @@ -734,6 +734,8 @@ .proc_name = "esp", .name = "Mac 53C9x SCSI", .detect = mac_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = mac_esp_release, .info = esp_info, .queuecommand = esp_queue, Index: drivers/scsi/mca_53c9x.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/mca_53c9x.c,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 mca_53c9x.c --- drivers/scsi/mca_53c9x.c 27 Jul 2003 20:13:15 -0000 1.1.1.8 +++ drivers/scsi/mca_53c9x.c 5 Feb 2004 20:23:20 -0000 @@ -448,6 +448,8 @@ .proc_name = "esp", .name = "NCR 53c9x SCSI", .detect = mca_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = mca_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, Index: drivers/scsi/oktagon_esp.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/oktagon_esp.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 oktagon_esp.c --- drivers/scsi/oktagon_esp.c 27 Jul 2003 20:13:17 -0000 1.1.1.9 +++ drivers/scsi/oktagon_esp.c 5 Feb 2004 20:23:21 -0000 @@ -595,6 +595,8 @@ .proc_info = &esp_proc_info, .name = "BSC Oktagon SCSI", .detect = oktagon_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = oktagon_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, Index: drivers/scsi/sun3x_esp.c =================================================================== RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/sun3x_esp.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 sun3x_esp.c --- drivers/scsi/sun3x_esp.c 27 Jul 2003 20:13:26 -0000 1.1.1.9 +++ drivers/scsi/sun3x_esp.c 5 Feb 2004 20:23:22 -0000 @@ -374,29 +374,6 @@ sp->SCp.ptr = (char *)((unsigned long)sp->SCp.buffer->dvma_address); } - -static int esp_slave_alloc(Scsi_Device *SDptr) -{ - struct esp_device *esp_dev = - kmalloc(sizeof(struct esp_device), GFP_ATOMIC); - - if (!esp_dev) - return -ENOMEM; - memset(esp_dev, 0, sizeof(struct esp_device)); - SDptr->hostdata = esp_dev; - return 0; -} - -static void esp_slave_destroy(Scsi_Device *SDptr) -{ - struct NCR_ESP *esp = (struct NCR_ESP *) SDptr->host->hostdata; - - esp->targets_present &= ~(1 << SDptr->id); - kfree(SDptr->hostdata); - SDptr->hostdata = NULL; -} - - static int sun3x_esp_release(struct Scsi_Host *instance) { /* this code does not support being compiled as a module */ _______________________________________________ Linux-m68k mailing list Linux-m68k@lists.linux-m68k.org http://lists.linux-m68k.org/mailman/listinfo/linux-m68k From yuasa@hh.iij4u.or.jp Mon Feb 9 09:27:01 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Feb 2004 09:27:02 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:42237 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225485AbUBIJ1B>; Mon, 9 Feb 2004 09:27:01 +0000 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 SAA12377; Mon, 9 Feb 2004 18:26:57 +0900 (JST) Received: 4UMDO00 id i199Qu322497; Mon, 9 Feb 2004 18:26:56 +0900 (JST) Received: 4UMRO01 id i199Qtj21950; Mon, 9 Feb 2004 18:26:56 +0900 (JST) from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated) Date: Mon, 9 Feb 2004 18:26:56 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Fixed mistake about hardware access for VRC4173 Message-Id: <20040209182656.4048431c.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4316 X-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 Hello Ralf, I made a patch for vrc4173 base code. This patch is included in the correction of hardware access about vrc4173. I changed the interface of clock control in relation to it. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/vrc4173.c linux/arch/mips/vr41xx/common/vrc4173.c --- linux-orig/arch/mips/vr41xx/common/vrc4173.c 2003-12-16 05:27:37.000000000 +0900 +++ linux/arch/mips/vr41xx/common/vrc4173.c 2004-02-09 17:47:27.000000000 +0900 @@ -1,34 +1,14 @@ /* - * FILE NAME - * drivers/char/vrc4173.c - * - * BRIEF MODULE DESCRIPTION - * NEC VRC4173 driver for NEC VR4122/VR4131. + * arch/mips/vr41xx/common/vrc4173.c * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * NEC VRC4173 driver for NEC VR4122/VR4131. * - * Copyright 2001,2002 MontaVista Software Inc. + * Author: Yoichi Yuasa <yyuasa@mvista.com, or source@mvista.com> * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * 2001-2003 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. */ #include <linux/config.h> #include <linux/init.h> @@ -36,6 +16,7 @@ #include <linux/interrupt.h> #include <linux/irq.h> #include <linux/pci.h> +#include <linux/spinlock.h> #include <linux/types.h> #include <asm/vr41xx/vr41xx.h> @@ -45,100 +26,292 @@ MODULE_AUTHOR("Yoichi Yuasa <yyuasa@mvista.com>"); MODULE_LICENSE("GPL"); +EXPORT_SYMBOL(vrc4173_io_offset); +EXPORT_SYMBOL(vrc4173_supply_clock); +EXPORT_SYMBOL(vrc4173_mask_clock); +EXPORT_SYMBOL(vrc4173_select_function); + #define VRC4173_CMUCLKMSK 0x040 + #define MSKPIU 0x0001 + #define MSKKIU 0x0002 + #define MSKAIU 0x0004 + #define MSKPS2CH1 0x0008 + #define MSKPS2CH2 0x0010 + #define MSKUSB 0x0020 + #define MSKCARD1 0x0040 + #define MSKCARD2 0x0080 + #define MSKAC97 0x0100 + #define MSK48MUSB 0x0400 + #define MSK48MPIN 0x0800 + #define MSK48MOSC 0x1000 #define VRC4173_CMUSRST 0x042 - -#define VRC4173_SELECTREG 0x09e + #define USBRST 0x0001 + #define CARD1RST 0x0002 + #define CARD2RST 0x0004 + #define AC97RST 0x0008 #define VRC4173_SYSINT1REG 0x060 #define VRC4173_MSYSINT1REG 0x06c +#define VRC4173_SELECTREG 0x09e + static struct pci_device_id vrc4173_table[] __devinitdata = { - {PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_VRC4173, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0, } + { .vendor = PCI_VENDOR_ID_NEC, + .device = PCI_DEVICE_ID_NEC_VRC4173, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, }, + { .vendor = 0, }, }; unsigned long vrc4173_io_offset = 0; -EXPORT_SYMBOL(vrc4173_io_offset); - -static u16 vrc4173_cmuclkmsk; static int vrc4173_initialized; +static uint16_t vrc4173_cmuclkmsk; +static uint16_t vrc4173_selectreg; +static spinlock_t vrc4173_cmu_lock; +static spinlock_t vrc4173_giu_lock; -void vrc4173_clock_supply(u16 mask) +static inline void set_cmusrst(uint16_t val) +{ + uint16_t cmusrst; + + cmusrst = vrc4173_inw(VRC4173_CMUSRST); + cmusrst |= val; + vrc4173_outw(cmusrst, VRC4173_CMUSRST); +} + +static inline void clear_cmusrst(uint16_t val) +{ + uint16_t cmusrst; + + cmusrst = vrc4173_inw(VRC4173_CMUSRST); + cmusrst &= ~val; + vrc4173_outw(cmusrst, VRC4173_CMUSRST); +} + +void vrc4173_supply_clock(unsigned int clock) { if (vrc4173_initialized) { - vrc4173_cmuclkmsk |= mask; + spin_lock_irq(&vrc4173_cmu_lock); + + switch (clock) { + case VRC4173_PIU_CLOCK: + vrc4173_cmuclkmsk |= MSKPIU; + break; + case VRC4173_KIU_CLOCK: + vrc4173_cmuclkmsk |= MSKKIU; + break; + case VRC4173_AIU_CLOCK: + vrc4173_cmuclkmsk |= MSKAIU; + break; + case VRC4173_PS2_CH1_CLOCK: + vrc4173_cmuclkmsk |= MSKPS2CH1; + break; + case VRC4173_PS2_CH2_CLOCK: + vrc4173_cmuclkmsk |= MSKPS2CH2; + break; + case VRC4173_USBU_PCI_CLOCK: + set_cmusrst(USBRST); + vrc4173_cmuclkmsk |= MSKUSB; + break; + case VRC4173_CARDU1_PCI_CLOCK: + set_cmusrst(CARD1RST); + vrc4173_cmuclkmsk |= MSKCARD1; + break; + case VRC4173_CARDU2_PCI_CLOCK: + set_cmusrst(CARD2RST); + vrc4173_cmuclkmsk |= MSKCARD2; + break; + case VRC4173_AC97U_PCI_CLOCK: + set_cmusrst(AC97RST); + vrc4173_cmuclkmsk |= MSKAC97; + break; + case VRC4173_USBU_48MHz_CLOCK: + set_cmusrst(USBRST); + vrc4173_cmuclkmsk |= MSK48MUSB; + break; + case VRC4173_EXT_48MHz_CLOCK: + if (vrc4173_cmuclkmsk & MSK48MOSC) + vrc4173_cmuclkmsk |= MSK48MPIN; + else + printk(KERN_WARNING + "vrc4173_supply_clock: " + "Please supply VRC4173_48MHz_CLOCK first " + "rather than VRC4173_EXT_48MHz_CLOCK.\n"); + break; + case VRC4173_48MHz_CLOCK: + vrc4173_cmuclkmsk |= MSK48MOSC; + break; + default: + printk(KERN_WARNING + "vrc4173_supply_clock: Invalid CLOCK value %u\n", clock); + break; + } + vrc4173_outw(vrc4173_cmuclkmsk, VRC4173_CMUCLKMSK); + + switch (clock) { + case VRC4173_USBU_PCI_CLOCK: + case VRC4173_USBU_48MHz_CLOCK: + clear_cmusrst(USBRST); + break; + case VRC4173_CARDU1_PCI_CLOCK: + clear_cmusrst(CARD1RST); + break; + case VRC4173_CARDU2_PCI_CLOCK: + clear_cmusrst(CARD2RST); + break; + case VRC4173_AC97U_PCI_CLOCK: + clear_cmusrst(AC97RST); + break; + default: + break; + } + + spin_unlock_irq(&vrc4173_cmu_lock); } } -void vrc4173_clock_mask(u16 mask) +void vrc4173_mask_clock(unsigned int clock) { if (vrc4173_initialized) { - vrc4173_cmuclkmsk &= ~mask; + spin_lock_irq(&vrc4173_cmu_lock); + + switch (clock) { + case VRC4173_PIU_CLOCK: + vrc4173_cmuclkmsk &= ~MSKPIU; + break; + case VRC4173_KIU_CLOCK: + vrc4173_cmuclkmsk &= ~MSKKIU; + break; + case VRC4173_AIU_CLOCK: + vrc4173_cmuclkmsk &= ~MSKAIU; + break; + case VRC4173_PS2_CH1_CLOCK: + vrc4173_cmuclkmsk &= ~MSKPS2CH1; + break; + case VRC4173_PS2_CH2_CLOCK: + vrc4173_cmuclkmsk &= ~MSKPS2CH2; + break; + case VRC4173_USBU_PCI_CLOCK: + set_cmusrst(USBRST); + vrc4173_cmuclkmsk &= ~MSKUSB; + break; + case VRC4173_CARDU1_PCI_CLOCK: + set_cmusrst(CARD1RST); + vrc4173_cmuclkmsk &= ~MSKCARD1; + break; + case VRC4173_CARDU2_PCI_CLOCK: + set_cmusrst(CARD2RST); + vrc4173_cmuclkmsk &= ~MSKCARD2; + break; + case VRC4173_AC97U_PCI_CLOCK: + set_cmusrst(AC97RST); + vrc4173_cmuclkmsk &= ~MSKAC97; + break; + case VRC4173_USBU_48MHz_CLOCK: + set_cmusrst(USBRST); + vrc4173_cmuclkmsk &= ~MSK48MUSB; + break; + case VRC4173_EXT_48MHz_CLOCK: + vrc4173_cmuclkmsk &= ~MSK48MPIN; + break; + case VRC4173_48MHz_CLOCK: + vrc4173_cmuclkmsk &= ~MSK48MOSC; + break; + default: + printk(KERN_WARNING "vrc4173_mask_clock: Invalid CLOCK value %u\n", clock); + break; + } + vrc4173_outw(vrc4173_cmuclkmsk, VRC4173_CMUCLKMSK); + + switch (clock) { + case VRC4173_USBU_PCI_CLOCK: + case VRC4173_USBU_48MHz_CLOCK: + clear_cmusrst(USBRST); + break; + case VRC4173_CARDU1_PCI_CLOCK: + clear_cmusrst(CARD1RST); + break; + case VRC4173_CARDU2_PCI_CLOCK: + clear_cmusrst(CARD2RST); + break; + case VRC4173_AC97U_PCI_CLOCK: + clear_cmusrst(AC97RST); + break; + default: + break; + } + + spin_unlock_irq(&vrc4173_cmu_lock); } } static inline void vrc4173_cmu_init(void) { vrc4173_cmuclkmsk = vrc4173_inw(VRC4173_CMUCLKMSK); -} -EXPORT_SYMBOL(vrc4173_clock_supply); -EXPORT_SYMBOL(vrc4173_clock_mask); + spin_lock_init(&vrc4173_cmu_lock); +} void vrc4173_select_function(int func) { - u16 val; - if (vrc4173_initialized) { - val = vrc4173_inw(VRC4173_SELECTREG); + spin_lock_irq(&vrc4173_giu_lock); + switch(func) { case PS2CH1_SELECT: - val |= 0x0004; + vrc4173_selectreg |= 0x0004; break; case PS2CH2_SELECT: - val |= 0x0002; + vrc4173_selectreg |= 0x0002; break; case TOUCHPANEL_SELECT: - val &= 0x0007; + vrc4173_selectreg &= 0x0007; break; case KIU8_SELECT: - val &= 0x000e; + vrc4173_selectreg &= 0x000e; break; case KIU10_SELECT: - val &= 0x000c; + vrc4173_selectreg &= 0x000c; break; case KIU12_SELECT: - val &= 0x0008; + vrc4173_selectreg &= 0x0008; break; case GPIO_SELECT: - val |= 0x0008; + vrc4173_selectreg |= 0x0008; break; } - vrc4173_outw(val, VRC4173_SELECTREG); + + vrc4173_outw(vrc4173_selectreg, VRC4173_SELECTREG); + + spin_unlock_irq(&vrc4173_giu_lock); } } -EXPORT_SYMBOL(vrc4173_select_function); +static inline void vrc4173_giu_init(void) +{ + vrc4173_selectreg = vrc4173_inw(VRC4173_SELECTREG); + + spin_lock_init(&vrc4173_giu_lock); +} static void enable_vrc4173_irq(unsigned int irq) { - u16 val; + uint16_t val; val = vrc4173_inw(VRC4173_MSYSINT1REG); - val |= (u16)1 << (irq - VRC4173_IRQ_BASE); + val |= (uint16_t)1 << (irq - VRC4173_IRQ_BASE); vrc4173_outw(val, VRC4173_MSYSINT1REG); } static void disable_vrc4173_irq(unsigned int irq) { - u16 val; + uint16_t val; val = vrc4173_inw(VRC4173_MSYSINT1REG); - val &= ~((u16)1 << (irq - VRC4173_IRQ_BASE)); + val &= ~((uint16_t)1 << (irq - VRC4173_IRQ_BASE)); vrc4173_outw(val, VRC4173_MSYSINT1REG); } @@ -158,19 +331,18 @@ } static struct hw_interrupt_type vrc4173_irq_type = { - "VRC4173", - startup_vrc4173_irq, - shutdown_vrc4173_irq, - enable_vrc4173_irq, - disable_vrc4173_irq, - ack_vrc4173_irq, - end_vrc4173_irq, - NULL + .typename = "VRC4173", + .startup = startup_vrc4173_irq, + .shutdown = shutdown_vrc4173_irq, + .enable = enable_vrc4173_irq, + .disable = disable_vrc4173_irq, + .ack = ack_vrc4173_irq, + .end = end_vrc4173_irq, }; static int vrc4173_get_irq_number(int irq) { - u16 status, mask; + uint16_t status, mask; int i; status = vrc4173_inw(VRC4173_SYSINT1REG); @@ -180,18 +352,18 @@ if (status) { for (i = 0; i < 16; i++) if (status & (0x0001 << i)) - return VRC4173_IRQ_BASE + i; + return VRC4173_IRQ(i); } return -EINVAL; } -static inline void vrc4173_icu_init(int cascade_irq) +static inline int vrc4173_icu_init(int cascade_irq) { int i; if (cascade_irq < GIU_IRQ(0) || cascade_irq > GIU_IRQ(15)) - return; + return -EINVAL; vrc4173_outw(0, VRC4173_MSYSINT1REG); @@ -200,33 +372,38 @@ for (i = VRC4173_IRQ_BASE; i <= VRC4173_IRQ_LAST; i++) irq_desc[i].handler = &vrc4173_irq_type; + + return 0; } -static int __devinit vrc4173_probe(struct pci_dev *pdev, - const struct pci_device_id *ent) +static int __devinit vrc4173_probe(struct pci_dev *dev, + const struct pci_device_id *id) { unsigned long start, flags; int err; - if ((err = pci_enable_device(pdev)) < 0) { - printk(KERN_ERR "vrc4173: failed to enable device -- err=%d\n", err); + err = pci_enable_device(dev); + if (err < 0) { + printk(KERN_ERR "vrc4173: Failed to enable PCI device, aborting\n"); return err; } - pci_set_master(pdev); + pci_set_master(dev); - start = pci_resource_start(pdev, 0); - if (!start) { - printk(KERN_ERR "vrc4173:No PCI I/O resources, aborting\n"); - return -ENODEV; + start = pci_resource_start(dev, 0); + if (start == 0) { + printk(KERN_ERR "vrc4173:No such PCI I/O resource, aborting\n"); + return -ENXIO; } - if (!start || (((flags = pci_resource_flags(pdev, 0)) & IORESOURCE_IO) == 0)) { - printk(KERN_ERR "vrc4173: No PCI I/O resources, aborting\n"); - return -ENODEV; + flags = pci_resource_flags(dev, 0); + if ((flags & IORESOURCE_IO) == 0) { + printk(KERN_ERR "vrc4173: No such PCI I/O resource, aborting\n"); + return -ENXIO; } - if ((err = pci_request_regions(pdev, "NEC VRC4173")) < 0) { + err = pci_request_regions(dev, "NEC VRC4173"); + if (err < 0) { printk(KERN_ERR "vrc4173: PCI resources are busy, aborting\n"); return err; } @@ -234,33 +411,46 @@ set_vrc4173_io_offset(start); vrc4173_cmu_init(); + vrc4173_giu_init(); - vrc4173_icu_init(pdev->irq); + err = vrc4173_icu_init(dev->irq); + if (err < 0) { + printk(KERN_ERR "vrc4173: Invalid IRQ %d, aborting\n", dev->irq); + return err; + } - if ((err = vr41xx_cascade_irq(pdev->irq, vrc4173_get_irq_number)) < 0) { - printk(KERN_ERR - "vrc4173: IRQ resource %d is busy, aborting\n", pdev->irq); + err = vr41xx_cascade_irq(dev->irq, vrc4173_get_irq_number); + if (err < 0) { + printk(KERN_ERR "vrc4173: IRQ resource %d is busy, aborting\n", dev->irq); return err; } printk(KERN_INFO - "NEC VRC4173 at 0x%#08lx, IRQ is cascaded to %d\n", start, pdev->irq); + "NEC VRC4173 at 0x%#08lx, IRQ is cascaded to %d\n", start, dev->irq); return 0; } +static void vrc4173_remove(struct pci_dev *dev) +{ + free_irq(dev->irq, NULL); + + pci_release_regions(dev); +} + static struct pci_driver vrc4173_driver = { - name: "NEC VRC4173", - probe: vrc4173_probe, - remove: NULL, - id_table: vrc4173_table, + .name = "NEC VRC4173", + .probe = vrc4173_probe, + .remove = vrc4173_remove, + .id_table = vrc4173_table, }; static int __devinit vrc4173_init(void) { int err; - if ((err = pci_module_init(&vrc4173_driver)) < 0) + err = pci_module_init(&vrc4173_driver); + if (err < 0) return err; vrc4173_initialized = 1; diff -urN -X dontdiff linux-orig/drivers/char/vr41xx_keyb.c linux/drivers/char/vr41xx_keyb.c --- linux-orig/drivers/char/vr41xx_keyb.c 2003-12-19 22:43:38.000000000 +0900 +++ linux/drivers/char/vr41xx_keyb.c 2004-02-09 12:44:07.000000000 +0900 @@ -308,7 +308,7 @@ if (found != 0) { kiu_base = VRC4173_KIU_OFFSET; mkiuintreg = VRC4173_MKIUINTREG_OFFSET; - vrc4173_clock_supply(VRC4173_KIU_CLOCK); + vrc4173_supply_clock(VRC4173_KIU_CLOCK); } } #endif diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vrc4173.h linux/include/asm-mips/vr41xx/vrc4173.h --- linux-orig/include/asm-mips/vr41xx/vrc4173.h 2003-12-19 21:43:40.000000000 +0900 +++ linux/include/asm-mips/vr41xx/vrc4173.h 2004-02-09 16:18:32.000000000 +0900 @@ -72,21 +72,23 @@ /* * Clock Mask Unit */ -#define VRC4173_PIU_CLOCK 0x0001 -#define VRC4173_KIU_CLOCK 0x0002 -#define VRC4173_AIU_CLOCK 0x0004 -#define VRC4173_PS2CH1_CLOCK 0x0008 -#define VRC4173_PS2CH2_CLOCK 0x0010 -#define VRC4173_USBU_PCI_CLOCK 0x0020 -#define VRC4173_CARDU1_PCI_CLOCK 0x0040 -#define VRC4173_CARDU2_PCI_CLOCK 0x0080 -#define VRC4173_AC97U_PCI_CLOCK 0x0100 -#define VRC4173_USBU_48MHz_CLOCK 0x0400 -#define VRC4173_EXT_48MHz_CLOCK 0x0800 -#define VRC4173_48MHz_CLOCK 0x1000 +enum { + VRC4173_PIU_CLOCK, + VRC4173_KIU_CLOCK, + VRC4173_AIU_CLOCK, + VRC4173_PS2_CH1_CLOCK, + VRC4173_PS2_CH2_CLOCK, + VRC4173_USBU_PCI_CLOCK, + VRC4173_CARDU1_PCI_CLOCK, + VRC4173_CARDU2_PCI_CLOCK, + VRC4173_AC97U_PCI_CLOCK, + VRC4173_USBU_48MHz_CLOCK, + VRC4173_EXT_48MHz_CLOCK, + VRC4173_48MHz_CLOCK, +}; -extern void vrc4173_clock_supply(u16 mask); -extern void vrc4173_clock_mask(u16 mask); +extern void vrc4173_supply_clock(unsigned int clock); +extern void vrc4173_mask_clock(unsigned int clock); /* * General-Purpose I/O Unit From ralf@linux-mips.org Mon Feb 9 16:23:50 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Feb 2004 16:23:51 +0000 (GMT) Received: from p508B75D8.dip.t-dialin.net ([IPv6:::ffff:80.139.117.216]:31321 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id <S8225687AbUBIQXu>; Mon, 9 Feb 2004 16:23:50 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i19GNoex001652 for <linux-mips@linux-mips.org>; Mon, 9 Feb 2004 17:23:50 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i19GNo6H001651 for linux-mips@linux-mips.org; Mon, 9 Feb 2004 17:23:50 +0100 Resent-Message-Id: <200402091623.i19GNo6H001651@fluff.linux-mips.net> Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i19GFvex001539; Mon, 9 Feb 2004 17:15:57 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i19GFhn9001538; Mon, 9 Feb 2004 17:15:43 +0100 Date: Mon, 9 Feb 2004 17:15:43 +0100 From: Ralf Baechle <ralf@linux-mips.org> To: Peter Horton <pdh@colonel-panic.org> Cc: linux-mips@linux-mips.org Subject: Re: PCI resources on 2.6 [Cobalt Qube] Message-ID: <20040209161543.GA496@linux-mips.org> References: <20040208131629.GA7276@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040208131629.GA7276@skeleton-jack> User-Agent: Mutt/1.4.1i Resent-From: ralf@linux-mips.org Resent-Date: Mon, 9 Feb 2004 17:23:50 +0100 Resent-To: linux-mips@linux-mips.org Return-Path: <ralf@linux-mips.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Feb 08, 2004 at 01:16:29PM +0000, Peter Horton wrote: > causing a page fault. > > If I set the I/O port base to 00000000 to overcome this then accesses to > the peripherals on the VIA south bridge don't get Galileo's PCI I/O base > added and they land up accessing RAM. > > I effectively have two I/O ranges that need to map to the same addresses > > 00000000 - 0000ffff --> b0000000 - b000ffff (for VIA) > 10000000 - 1000ffff --> b0000000 - b000ffff (for PCI) > > I was hopefull that the 'io_offset' field in 'struct pci_controller' > would do this for me, but I can't work out what it does :-| In general io_offset should be left 0 unless you already register ioport resources elsewhere in the kernel, which typically is needed for platforms with legacy peripherals - that is the Cobalt, too. Two examples you could take a look at: - Siemens-Nixdorf RM200 In arch/mips/sni/setup.c it statically initializes sni_controller. io_address range: static struct pci_controller sni_controller = { .pci_ops = &sni_pci_ops, .mem_resource = &sni_mem_resource, .mem_offset = 0x10000000UL, .io_resource = &sni_io_resource, .io_offset = 0x00000000UL }; A few legacy PC style I/O port resources are registered first using repeated calls to request_resource: request_resource(&ioport_resource, pcimt_io_resources + i); Note we're allocating resources from ioport_resource, the kernel's "master" I/O port resource. It means later the kernel won't try to assign PCI cards to the same place even though all legacy resources actually exist on the PCI bus or more exactly on a SuperIO chip behind the PCI-EISA bridge. - MIPS Malta The Malta board takes an exchangable processor card which also contains one of several different possible system controllers, among those the GT-64120 which is rather similar to the GT-64111 used on Cobalts. static struct resource gt64120_mem_resource = { .name = "GT64120 PCI MEM", .start = 0x10000000UL, .end = 0x1fffffffUL, .flags = IORESOURCE_MEM, }; static struct resource gt64120_io_resource = { .name = "GT64120 IO MEM", .start = 0x00002000UL, .end = 0x007fffffUL, .flags = IORESOURCE_IO, }; Aside of supporting several different system controllers this also fairly simple. The complexity here which (afair ...) you'll also have to handle on the GT64111 is that the system controller itself shows up on the PCI bus as a PCI device, so when the kernel configures the PCI bus it'll accendidentally move the system controller including all PCI devices around. I wonder if that's what you just ran into? Ralf From tahoma@nshore.com Mon Feb 9 20:41:54 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Feb 2004 20:41:56 +0000 (GMT) Received: from rrcs-sw-24-153-140-91.biz.rr.com ([IPv6:::ffff:24.153.140.91]:11136 "EHLO public.nshore.com") by linux-mips.org with ESMTP id <S8224939AbUBIUly>; Mon, 9 Feb 2004 20:41:54 +0000 Received: from nshore.com (gate.nshore.com [192.168.1.2]) by public.nshore.com (8.11.6/8.11.6) with ESMTP id i19KfAc02080 for <linux-mips@linux-mips.org>; Mon, 9 Feb 2004 14:41:10 -0600 Message-ID: <4027F08D.5030601@nshore.com> Date: Mon, 09 Feb 2004 14:41:49 -0600 From: Tahoma Toelkes <tahoma@nshore.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: difficulties with NFSROOT and DHCP Content-Type: multipart/mixed; boundary="------------040803020409020006070105" Return-Path: <tahoma@nshore.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tahoma@nshore.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------040803020409020006070105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The context is that I am in the process of bringing up a 2.4.24 kernel (pulled from linux-mips CVS using the linux_2_4_24 tag) on a DBAu1500 board (Zinfandel). I'm having trouble mounting my root filesystem over NFS. After the ethernet ports have been enumerated, the kernel attempts to contact the DHCP server to obtain its IP configuration information. At this point the boot sequence hangs, perpetually retrying the DHCP server. Here are the last several lines from the log of the boot messages, prefixed with a vertical bar to set them apart: | Sending DHCP requests .<6>eth0: link up | eth0: going to full duplex | ..... timed out! | IP-Config: Retrying forever (NFS root)... | Sending DHCP requests ...... timed out! | IP-Config: Retrying forever (NFS root)... | Sending DHCP requests .. I've verified that the exported root filesystem can be mounted by another Linux workstation. I've also verified on the DHCP server that it is seeing the board initiate a DHCP discovery and that the DHCP server is replying with offer for the correct address. Here is an excerpt from '/var/log/messages' on the DHCP server: | Feb 9 13:25:33 kapala dhcpd: DHCPDISCOVER from 00:50:c2:0c:38:8a via eth0 | Feb 9 13:25:33 kapala dhcpd: DHCPOFFER on 172.16.108.42 to 00:50:c2:0c:38:8a via eth0 For completeness sake, I've attached the full log of the boot sequence until it hangs as well as my current kernel configuration. If any of you have seen this particular problem and know how to get around it, please respond. Further, if you simply have suggestions for avenues I could explore, I would appreciate any advice you might have to offer. Humbly yours, -- Tahoma --------------040803020409020006070105 Content-Type: text/plain; name="minicom.cap" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="minicom.cap" YAMON ROM Monitor, Revision 02.15DB1500. Copyright (c) 1999-2000 MIPS Technologies, Inc. - All Rights Reserved. For a list of available commands, type 'help'. Compilation time = Nov 5 2002 11:42:43 MAC address = 00.50.c2.0c.38.8a Processor Company ID = 0x03 Processor ID/revision = 0x02 / 0x00 Endianness = Big CPU = 396 MHz Flash memory size = 32 MByte SDRAM size = 64 MByte First free SDRAM address = 0x8008a0d4 YAMON> load asc: About to load asc://tty0 Press Ctrl-C to break Start dump from terminal program YAMON> go . root=/dev/nfs nfsroot=172.16.108.11:/export/root ip=172.16.108.42:1   loaded at: 81000000 8109B000 zimage at: 810063D0 8109A3D0 Uncompressing Linux at load address 80100000 Now booting the kernel CPU revision is: 01030200 Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 bytes. Primary data cache 16kB 4-way, linesize 32 bytes. Linux version 2.4.24-pre2 (tahoma@localhost.localdomain) (gcc version 3.3.2) #2 Mon Feb 9 10:08:58 CST 2004 AMD Alchemy Au1500/Db1500 Board Determined physical RAM map: memory: 04000000 @ 00000000 (usable) On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/nfs nfsroot=172.16.108.11:/export/root ip=172.16.108.42 console=ttyS0,115200 calculating r4koff... 003c6cc0(3960000) CPU frequency 396.00 MHz Calibrating delay loop... 395.67 BogoMIPS Memory: 62188k/65536k available (1286k kernel code, 3348k reserved, 72k data, 100k init, 0k highmem) Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX Autoconfig PCI channel 0x80270d58 Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x50000000 00:0c.0 Class 0104: 1103:0007 (rev 01) I/O at 0x00000300 [size=0x8] I/O at 0x00000308 [size=0x4] I/O at 0x00000310 [size=0x8] I/O at 0x00000318 [size=0x4] I/O at 0x00000400 [size=0x100] Non-coherent PCI accesses enabled Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Serial driver version 1.01 (2001-02-08) with no serial options enabled ttyS00 at 0xb1100000 (irq = 0) is a 16550 ttyS01 at 0xb1200000 (irq = 1) is a 16550 ttyS02 at 0xb1300000 (irq = 2) is a 16550 ttyS03 at 0xb1400000 (irq = 3) is a 16550 Generic MIPS RTC Driver v1.0 au1000eth.c:1.4 ppopov@mvista.com eth0: Au1x Ethernet found at 0xb1500000, irq 28 eth0: AMD 79C874 10/100 BaseT PHY at phy address 31 eth0: Using AMD 79C874 10/100 BaseT PHY as default eth1: Au1x Ethernet found at 0xb1510000, irq 29 eth1: AMD 79C874 10/100 BaseT PHY at phy address 31 eth1: Using AMD 79C874 10/100 BaseT PHY as default NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) Sending DHCP requests .<6>eth0: link up eth0: going to full duplex ..... timed out! IP-Config: Retrying forever (NFS root)... Sending DHCP requests ...... timed out! IP-Config: Retrying forever (NFS root)... Sending DHCP requests .. --------------040803020409020006070105 Content-Type: text/plain; name=".config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=".config" # # Automatically generated make config: don't edit # CONFIG_MIPS=y CONFIG_MIPS32=y # CONFIG_MIPS64 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set # CONFIG_KMOD is not set # # Machine selection # # CONFIG_ACER_PICA_61 is not set # CONFIG_MIPS_BOSPORUS is not set # CONFIG_MIPS_MIRAGE is not set # CONFIG_MIPS_DB1000 is not set # CONFIG_MIPS_DB1100 is not set CONFIG_MIPS_DB1500=y # CONFIG_MIPS_PB1000 is not set # CONFIG_MIPS_PB1100 is not set # CONFIG_MIPS_PB1500 is not set # CONFIG_MIPS_HYDROGEN3 is not set # CONFIG_MIPS_PB1550 is not set # CONFIG_MIPS_XXS1500 is not set # CONFIG_MIPS_MTX1 is not set # CONFIG_COGENT_CSB250 is not set # CONFIG_BAGET_MIPS is not set # CONFIG_CASIO_E55 is not set # CONFIG_MIPS_COBALT is not set # CONFIG_DECSTATION is not set # CONFIG_MIPS_EV64120 is not set # CONFIG_MIPS_EV96100 is not set # CONFIG_MIPS_IVR is not set # CONFIG_HP_LASERJET is not set # CONFIG_IBM_WORKPAD is not set # CONFIG_LASAT is not set # CONFIG_MIPS_ITE8172 is not set # CONFIG_MIPS_ATLAS is not set # CONFIG_MIPS_MAGNUM_4000 is not set # CONFIG_MIPS_MALTA is not set # CONFIG_MIPS_SEAD is not set # CONFIG_MOMENCO_OCELOT is not set # CONFIG_MOMENCO_OCELOT_G is not set # CONFIG_MOMENCO_OCELOT_C is not set # CONFIG_MOMENCO_JAGUAR_ATX is not set # CONFIG_PMC_YOSEMITE is not set # CONFIG_DDB5074 is not set # CONFIG_DDB5476 is not set # CONFIG_DDB5477 is not set # CONFIG_NEC_OSPREY is not set # CONFIG_NEC_EAGLE is not set # CONFIG_OLIVETTI_M700 is not set # CONFIG_NINO is not set # CONFIG_SGI_IP22 is not set # CONFIG_SGI_IP27 is not set # CONFIG_SIBYTE_SB1xxx_SOC is not set # CONFIG_SNI_RM200_PCI is not set # CONFIG_TANBAC_TB0226 is not set # CONFIG_TANBAC_TB0229 is not set # CONFIG_TOSHIBA_JMR3927 is not set # CONFIG_TOSHIBA_RBTX4927 is not set # CONFIG_VICTOR_MPC30X is not set # CONFIG_ZAO_CAPCELLA is not set # CONFIG_HIGHMEM is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set CONFIG_SOC_AU1X00=y CONFIG_SOC_AU1500=y CONFIG_NEW_TIME_C=y CONFIG_PCI=y CONFIG_NEW_PCI=y CONFIG_PCI_AUTO=y CONFIG_NONCOHERENT_IO=y CONFIG_PC_KEYB=y # CONFIG_MIPS_AU1000 is not set # # CPU selection # CONFIG_CPU_MIPS32=y # CONFIG_CPU_MIPS64 is not set # CONFIG_CPU_R3000 is not set # CONFIG_CPU_TX39XX is not set # CONFIG_CPU_VR41XX is not set # CONFIG_CPU_R4300 is not set # CONFIG_CPU_R4X00 is not set # CONFIG_CPU_TX49XX is not set # CONFIG_CPU_R5000 is not set # CONFIG_CPU_R5432 is not set # CONFIG_CPU_R6000 is not set # CONFIG_CPU_NEVADA is not set # CONFIG_CPU_R8000 is not set # CONFIG_CPU_R10000 is not set # CONFIG_CPU_RM7000 is not set # CONFIG_CPU_RM9000 is not set # CONFIG_CPU_SB1 is not set CONFIG_PAGE_SIZE_4KB=y # CONFIG_PAGE_SIZE_16KB is not set # CONFIG_PAGE_SIZE_64KB is not set CONFIG_CPU_HAS_PREFETCH=y # CONFIG_VTAG_ICACHE is not set # CONFIG_64BIT_PHYS_ADDR is not set CONFIG_CPU_ADVANCED=y # CONFIG_CPU_HAS_LLSC is not set # CONFIG_CPU_HAS_LLDSCD is not set # CONFIG_CPU_HAS_WB is not set CONFIG_CPU_HAS_SYNC=y # # General setup # # CONFIG_CPU_LITTLE_ENDIAN is not set # CONFIG_BINFMT_IRIX is not set CONFIG_NET=y # CONFIG_PCI_NAMES is not set # CONFIG_ISA is not set # CONFIG_TC is not set # CONFIG_MCA is not set # CONFIG_SBUS is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set # CONFIG_HOTPLUG_PCI is not set # CONFIG_SYSVIPC is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_SYSCTL is not set CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_MIPS32_COMPAT is not set # CONFIG_MIPS32_O32 is not set # CONFIG_MIPS32_N32 is not set # CONFIG_BINFMT_ELF32 is not set # CONFIG_BINFMT_MISC is not set # CONFIG_OOM_KILLER is not set # CONFIG_PM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_BLK_STATS is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y # CONFIG_IP_PNP_BOOTP is not set # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DEV_APPLETALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # # CONFIG_IDE is not set # CONFIG_BLK_DEV_IDE_MODES is not set # CONFIG_BLK_DEV_HD is not set # # SCSI support # # CONFIG_SCSI is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MIPS_AU1X00_ENET=y # CONFIG_BCM5222_DUAL_PHY is not set # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set # CONFIG_NET_PCI is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Input core support # # CONFIG_INPUT is not set # CONFIG_INPUT_KEYBDEV is not set # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_UINPUT is not set # # Character devices # # CONFIG_VT is not set # CONFIG_SERIAL is not set # CONFIG_SERIAL_EXTENDED is not set CONFIG_SERIAL_NONSTANDARD=y # CONFIG_COMPUTONE is not set # CONFIG_ROCKETPORT is not set # CONFIG_CYCLADES is not set # CONFIG_DIGIEPCA is not set # CONFIG_DIGI is not set # CONFIG_ESPSERIAL is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_ISI is not set # CONFIG_SYNCLINK is not set # CONFIG_SYNCLINKMP is not set # CONFIG_N_HDLC is not set # CONFIG_RISCOM8 is not set # CONFIG_SPECIALIX is not set # CONFIG_SX is not set # CONFIG_RIO is not set # CONFIG_STALDRV is not set # CONFIG_SERIAL_TX3912 is not set # CONFIG_SERIAL_TX3912_CONSOLE is not set # CONFIG_SERIAL_TXX9 is not set # CONFIG_SERIAL_TXX9_CONSOLE is not set CONFIG_AU1X00_UART=y CONFIG_AU1X00_SERIAL_CONSOLE=y # CONFIG_AU1X00_USB_TTY is not set # CONFIG_AU1X00_USB_RAW is not set # CONFIG_TXX927_SERIAL is not set # CONFIG_UNIX98_PTYS is not set # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # # Input core support is needed for gameports # # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_IPMI_PANIC_EVENT is not set # CONFIG_IPMI_DEVICE_INTERFACE is not set # CONFIG_IPMI_KCS is not set # CONFIG_IPMI_WATCHDOG is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_SCx200_GPIO is not set # CONFIG_AMD_PM768 is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set CONFIG_MIPS_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # # Direct Rendering Manager (XFree86 DRI support) # # CONFIG_DRM is not set # CONFIG_AU1X00_GPIO is not set # CONFIG_TS_AU1X00_ADS7846 is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_QFMT_V2 is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BEFS_DEBUG is not set # CONFIG_BFS_FS is not set # CONFIG_EXT3_FS is not set # CONFIG_JBD is not set # CONFIG_JBD_DEBUG is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set # CONFIG_TMPFS is not set CONFIG_RAMFS=y # CONFIG_ISO9660_FS is not set # CONFIG_JOLIET is not set # CONFIG_ZISOFS is not set # CONFIG_JFS_FS is not set # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # CONFIG_XFS_FS is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_RT is not set # CONFIG_XFS_TRACE is not set # CONFIG_XFS_DEBUG is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_ROOT_NFS=y CONFIG_NFSD=y # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set # CONFIG_NLS is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Sound # # CONFIG_SOUND is not set # # USB support # # CONFIG_USB is not set # # Support for USB gadgets # # CONFIG_USB_GADGET is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_CROSSCOMPILE=y # CONFIG_RUNTIME_DEBUG is not set # CONFIG_KGDB is not set # CONFIG_GDB_CONSOLE is not set CONFIG_DEBUG_INFO=y # CONFIG_MAGIC_SYSRQ is not set # CONFIG_MIPS_UNCACHED is not set CONFIG_LOG_BUF_SHIFT=14 # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # # CONFIG_CRC32 is not set CONFIG_ZLIB_INFLATE=y # CONFIG_ZLIB_DEFLATE is not set --------------040803020409020006070105-- From yuasa@hh.iij4u.or.jp Mon Feb 9 21:38:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Feb 2004 21:38:57 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:21970 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225517AbUBIVi4>; Mon, 9 Feb 2004 21:38:56 +0000 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 GAA21985; Tue, 10 Feb 2004 06:38:52 +0900 (JST) Received: 4UMDO00 id i19LcqF28602; Tue, 10 Feb 2004 06:38:52 +0900 (JST) Received: 4UMRO00 id i19Lcp409316; Tue, 10 Feb 2004 06:38:52 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Tue, 10 Feb 2004 06:38:46 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Fixed configration problem for vr41xx Message-Id: <20040210063846.66ec64a9.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4319 X-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 Hello Ralf, I made a patch for configuration problem for vr41xx. This patch corrects the problem which occurs when CONFIG_SERIAL is n. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c --- linux-orig/arch/mips/vr41xx/casio-e55/setup.c 2004-02-06 11:21:47.000000000 +0900 +++ linux/arch/mips/vr41xx/casio-e55/setup.c 2004-02-09 12:11:51.000000000 +0900 @@ -50,5 +50,7 @@ vr41xx_cmu_init(); +#ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); +#endif } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c --- linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c 2004-02-06 11:21:47.000000000 +0900 +++ linux/arch/mips/vr41xx/ibm-workpad/setup.c 2004-02-09 12:11:51.000000000 +0900 @@ -50,5 +50,7 @@ vr41xx_cmu_init(); +#ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); +#endif } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c 2004-02-09 10:43:38.000000000 +0900 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c 2004-02-09 12:12:36.000000000 +0900 @@ -91,7 +91,9 @@ vr41xx_cmu_init(); +#ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); +#endif #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c 2004-02-09 10:43:38.000000000 +0900 +++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c 2004-02-09 12:11:51.000000000 +0900 @@ -104,8 +104,10 @@ vr41xx_cmu_init(); +#ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); vr41xx_dsiu_init(); +#endif #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c 2004-02-09 10:43:38.000000000 +0900 +++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c 2004-02-09 12:16:23.000000000 +0900 @@ -96,7 +96,9 @@ vr41xx_cmu_init(); +#ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); +#endif #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c --- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c 2004-02-09 10:43:38.000000000 +0900 +++ linux/arch/mips/vr41xx/zao-capcella/setup.c 2004-02-09 12:17:10.000000000 +0900 @@ -96,8 +96,10 @@ vr41xx_cmu_init(); +#ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); vr41xx_dsiu_init(); +#endif #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); From yuasa@hh.iij4u.or.jp Mon Feb 9 21:48:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Feb 2004 21:48:36 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:23020 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225515AbUBIVsf>; Mon, 9 Feb 2004 21:48:35 +0000 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 GAA28692; Tue, 10 Feb 2004 06:48:28 +0900 (JST) Received: 4UMDO01 id i19LmSX06940; Tue, 10 Feb 2004 06:48:28 +0900 (JST) Received: 4UMRO01 id i19LmQr04198; Tue, 10 Feb 2004 06:48:27 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Tue, 10 Feb 2004 06:48:21 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Tahoma Toelkes <tahoma@nshore.com> Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org Subject: Re: difficulties with NFSROOT and DHCP Message-Id: <20040210064821.7ef6a72f.yuasa@hh.iij4u.or.jp> In-Reply-To: <4027F08D.5030601@nshore.com> References: <4027F08D.5030601@nshore.com> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4320 X-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, On Mon, 09 Feb 2004 14:41:49 -0600 Tahoma Toelkes <tahoma@nshore.com> wrote: > The context is that I am in the process of bringing up a 2.4.24 kernel > (pulled from linux-mips CVS using the linux_2_4_24 tag) on a DBAu1500 > board (Zinfandel). > > I'm having trouble mounting my root filesystem over NFS. After the > ethernet ports have been enumerated, the kernel attempts to contact the > DHCP server to obtain its IP configuration information. At this point > the boot sequence hangs, perpetually retrying the DHCP server. Here are > the last several lines from the log of the boot messages, prefixed with > a vertical bar to set them apart: > > | Sending DHCP requests .<6>eth0: link up > | eth0: going to full duplex > | ..... timed out! > | IP-Config: Retrying forever (NFS root)... > | Sending DHCP requests ...... timed out! > | IP-Config: Retrying forever (NFS root)... > | Sending DHCP requests .. > > I've verified that the exported root filesystem can be mounted by > another Linux workstation. I've also verified on the DHCP server that > it is seeing the board initiate a DHCP discovery and that the DHCP > server is replying with offer for the correct address. Here is an > excerpt from '/var/log/messages' on the DHCP server: > > | Feb 9 13:25:33 kapala dhcpd: DHCPDISCOVER from 00:50:c2:0c:38:8a via eth0 > | Feb 9 13:25:33 kapala dhcpd: DHCPOFFER on 172.16.108.42 to > 00:50:c2:0c:38:8a via eth0 Please try the following option. YAMON> go . root=/dev/nfs nfsroot=172.16.108.11:/export/root ip=dhcp > For completeness sake, I've attached the full log of the boot sequence > until it hangs as well as my current kernel configuration. If any of > you have seen this particular problem and know how to get around it, > please respond. Further, if you simply have suggestions for avenues I > could explore, I would appreciate any advice you might have to offer. Yoichi From tahoma@nshore.com Mon Feb 9 23:15:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Feb 2004 23:15:05 +0000 (GMT) Received: from rrcs-sw-24-153-140-91.biz.rr.com ([IPv6:::ffff:24.153.140.91]:19072 "EHLO public.nshore.com") by linux-mips.org with ESMTP id <S8225578AbUBIXPE>; Mon, 9 Feb 2004 23:15:04 +0000 Received: from nshore.com (gate.nshore.com [192.168.1.2]) by public.nshore.com (8.11.6/8.11.6) with ESMTP id i19NEGc02948; Mon, 9 Feb 2004 17:14:17 -0600 Message-ID: <40281470.1000701@nshore.com> Date: Mon, 09 Feb 2004 17:14:56 -0600 From: Tahoma Toelkes <tahoma@nshore.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.6.0.0e X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> CC: linux-mips@linux-mips.org Subject: Re: difficulties with NFSROOT and DHCP References: <4027F08D.5030601@nshore.com> <20040210064821.7ef6a72f.yuasa@hh.iij4u.or.jp> In-Reply-To: <20040210064821.7ef6a72f.yuasa@hh.iij4u.or.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: <tahoma@nshore.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tahoma@nshore.com Precedence: bulk X-list: linux-mips Yes! That was the trick. I've now booted and am able to ping the board. Thank you, thank you, thank you. If you're ever in Austin, Yoichi, you should let me treat you to a pitcher of beer (or a bottle of wine/sake...whatever). :-) Thanks again, -- Tahoma Yoichi Yuasa wrote: >Hi, > >On Mon, 09 Feb 2004 14:41:49 -0600 >Tahoma Toelkes <tahoma@nshore.com> wrote: > > > >>The context is that I am in the process of bringing up a 2.4.24 kernel >>(pulled from linux-mips CVS using the linux_2_4_24 tag) on a DBAu1500 >>board (Zinfandel). >> >>I'm having trouble mounting my root filesystem over NFS. After the >>ethernet ports have been enumerated, the kernel attempts to contact the >>DHCP server to obtain its IP configuration information. At this point >>the boot sequence hangs, perpetually retrying the DHCP server. Here are >>the last several lines from the log of the boot messages, prefixed with >>a vertical bar to set them apart: >> >>| Sending DHCP requests .<6>eth0: link up >>| eth0: going to full duplex >>| ..... timed out! >>| IP-Config: Retrying forever (NFS root)... >>| Sending DHCP requests ...... timed out! >>| IP-Config: Retrying forever (NFS root)... >>| Sending DHCP requests .. >> >>I've verified that the exported root filesystem can be mounted by >>another Linux workstation. I've also verified on the DHCP server that >>it is seeing the board initiate a DHCP discovery and that the DHCP >>server is replying with offer for the correct address. Here is an >>excerpt from '/var/log/messages' on the DHCP server: >> >>| Feb 9 13:25:33 kapala dhcpd: DHCPDISCOVER from 00:50:c2:0c:38:8a via eth0 >>| Feb 9 13:25:33 kapala dhcpd: DHCPOFFER on 172.16.108.42 to >>00:50:c2:0c:38:8a via eth0 >> >> > >Please try the following option. > >YAMON> go . root=/dev/nfs nfsroot=172.16.108.11:/export/root ip=dhcp > > > > >>For completeness sake, I've attached the full log of the boot sequence >>until it hangs as well as my current kernel configuration. If any of >>you have seen this particular problem and know how to get around it, >>please respond. Further, if you simply have suggestions for avenues I >>could explore, I would appreciate any advice you might have to offer. >> >> > >Yoichi > > From yuasa@hh.iij4u.or.jp Tue Feb 10 08:48:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 08:48:05 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:42969 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225278AbUBJIsD>; Tue, 10 Feb 2004 08:48:03 +0000 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id RAA27280; Tue, 10 Feb 2004 17:47:59 +0900 (JST) Received: 4UMDO01 id i1A8lx912841; Tue, 10 Feb 2004 17:47:59 +0900 (JST) Received: 4UMRO00 id i1A8lwv19564; Tue, 10 Feb 2004 17:47:58 +0900 (JST) from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated) Date: Tue, 10 Feb 2004 17:47:59 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Fixed PCI config founctions for vr41xx Message-Id: <20040210174759.0772912e.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4322 X-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 Hello Ralf, I made a patch for PCI config functions for vr41xx. I found my mistake about PCI config functions of vr41xx, and also include some fixes. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/pciu.c linux/arch/mips/vr41xx/common/pciu.c --- linux-orig/arch/mips/vr41xx/common/pciu.c 2003-12-02 04:31:49.000000000 +0900 +++ linux/arch/mips/vr41xx/common/pciu.c 2004-02-10 15:52:00.000000000 +0900 @@ -1,40 +1,17 @@ /* - * FILE NAME - * arch/mips/vr41xx/common/pciu.c + * arch/mips/vr41xx/common/pciu.c * - * BRIEF MODULE DESCRIPTION - * PCI Control Unit routines for the NEC VR4100 series. + * PCI Control Unit routines for the NEC VR4100 series. * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * Author: Yoichi Yuasa <yyuasa@mvista.com, or source@mvista.com> * - * Copyright 2001,2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * 2001-2003 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. */ /* * Changes: - * Paul Mundt <lethal@chaoticdreams.org> - * - Fix deadlock-causing PCIU access race for VR4131. - * * MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com> * - New creation, NEC VR4122 and VR4131 are supported. */ @@ -42,7 +19,6 @@ #include <linux/init.h> #include <linux/pci.h> #include <linux/types.h> -#include <linux/delay.h> #include <asm/cpu.h> #include <asm/io.h> @@ -60,49 +36,48 @@ /* * Type 0 configuration */ - if (PCI_SLOT(dev_fn) < 11 || PCI_SLOT(dev_fn) > 31 || where > 255) - return -1; + if (PCI_SLOT(dev_fn) < 11 || PCI_SLOT(dev_fn) > 31 || where > 0xff) + return -EINVAL; - writel((1UL << PCI_SLOT(dev_fn))| + writel((1U << PCI_SLOT(dev_fn)) | (PCI_FUNC(dev_fn) << 8) | (where & 0xfc), PCICONFAREG); - } - else { + } else { /* * Type 1 configuration */ - if (PCI_SLOT(dev_fn) > 31 || where > 255) - return -1; + if (PCI_SLOT(dev_fn) > 31 || where > 0xff) + return -EINVAL; writel((bus << 16) | (dev_fn << 8) | (where & 0xfc) | - 1UL, + 1U, PCICONFAREG); } return 0; } -static int vr41xx_pci_read_config_byte(struct pci_dev *dev, int where, u8 *val) +static int vr41xx_pci_config_read_byte(struct pci_dev *dev, int where, uint8_t *val) { - u32 data; + uint32_t data; *val = 0xff; if (vr41xx_pci_config_access(dev, where) < 0) return PCIBIOS_DEVICE_NOT_FOUND; data = readl(PCICONFDREG); - *val = (u8)(data >> ((where & 3) << 3)); + *val = (uint8_t)(data >> ((where & 3) << 3)); return PCIBIOS_SUCCESSFUL; } -static int vr41xx_pci_read_config_word(struct pci_dev *dev, int where, u16 *val) +static int vr41xx_pci_config_read_word(struct pci_dev *dev, int where, uint16_t *val) { - u32 data; + uint32_t data; *val = 0xffff; if (where & 1) @@ -112,12 +87,12 @@ return PCIBIOS_DEVICE_NOT_FOUND; data = readl(PCICONFDREG); - *val = (u16)(data >> ((where & 2) << 3)); + *val = (uint16_t)(data >> ((where & 2) << 3)); return PCIBIOS_SUCCESSFUL; } -static int vr41xx_pci_read_config_dword(struct pci_dev *dev, int where, u32 *val) +static int vr41xx_pci_config_read_dword(struct pci_dev *dev, int where, uint32_t *val) { *val = 0xffffffff; if (where & 3) @@ -131,9 +106,9 @@ return PCIBIOS_SUCCESSFUL; } -static int vr41xx_pci_write_config_byte(struct pci_dev *dev, int where, u8 val) +static int vr41xx_pci_config_write_byte(struct pci_dev *dev, int where, uint8_t val) { - u32 data; + uint32_t data; int shift; if (vr41xx_pci_config_access(dev, where) < 0) @@ -141,17 +116,16 @@ data = readl(PCICONFDREG); shift = (where & 3) << 3; - data &= ~(0xff << shift); - data |= (((u32)val) << shift); - + data &= ~(0xffU << shift); + data |= (uint32_t)val << shift; writel(data, PCICONFDREG); return PCIBIOS_SUCCESSFUL; } -static int vr41xx_pci_write_config_word(struct pci_dev *dev, int where, u16 val) +static int vr41xx_pci_config_write_word(struct pci_dev *dev, int where, uint16_t val) { - u32 data; + uint32_t data; int shift; if (where & 1) @@ -162,14 +136,14 @@ data = readl(PCICONFDREG); shift = (where & 2) << 3; - data &= ~(0xffff << shift); - data |= (((u32)val) << shift); + data &= ~(0xffffU << shift); + data |= (uint32_t)val << shift; writel(data, PCICONFDREG); return PCIBIOS_SUCCESSFUL; } -static int vr41xx_pci_write_config_dword(struct pci_dev *dev, int where, u32 val) +static int vr41xx_pci_config_write_dword(struct pci_dev *dev, int where, uint32_t val) { if (where & 3) return PCIBIOS_BAD_REGISTER_NUMBER; @@ -183,22 +157,21 @@ } struct pci_ops vr41xx_pci_ops = { - vr41xx_pci_read_config_byte, - vr41xx_pci_read_config_word, - vr41xx_pci_read_config_dword, - vr41xx_pci_write_config_byte, - vr41xx_pci_write_config_word, - vr41xx_pci_write_config_dword + .read_byte = vr41xx_pci_config_read_byte, + .read_word = vr41xx_pci_config_read_word, + .read_dword = vr41xx_pci_config_read_dword, + .write_byte = vr41xx_pci_config_write_byte, + .write_word = vr41xx_pci_config_write_word, + .write_dword = vr41xx_pci_config_write_dword, }; void __init vr41xx_pciu_init(struct vr41xx_pci_address_map *map) { struct vr41xx_pci_address_space *s; unsigned long vtclock; - u32 config; - int n; + uint32_t config; - if (!map) + if (map == NULL) return; /* Disable PCI interrupt */ @@ -207,11 +180,9 @@ /* Supply VTClock to PCIU */ vr41xx_clock_supply(PCIU_CLOCK); - /* - * Sleep for 1us after setting MSKPPCIU bit in CMUCLKMSK - * before doing any PCIU access to avoid deadlock on VR4131. - */ - udelay(1); + /* Dummy read/write, waiting for supply of VTClock. */ + readw(MPCIINTREG); + writew(0, MPCIINTREG); /* Select PCI clock */ vtclock = vr41xx_get_vtclock_frequency(); @@ -233,48 +204,52 @@ */ if (map->mem1 != NULL) { s = map->mem1; - config = (s->internal_base & 0xff000000) | - ((s->address_mask & 0x7f000000) >> 11) | (1UL << 12) | - ((s->pci_base & 0xff000000) >> 24); + config = (s->internal_base & INTERNAL_BUS_BASE_ADDRESS) | + ((s->address_mask >> 11) & ADDRESS_MASK) | + PCI_ACCESS_ENABLE | + ((s->pci_base >> 24) & PCI_ADDRESS_SETTING); writel(config, PCIMMAW1REG); } if (map->mem2 != NULL) { s = map->mem2; - config = (s->internal_base & 0xff000000) | - ((s->address_mask & 0x7f000000) >> 11) | (1UL << 12) | - ((s->pci_base & 0xff000000) >> 24); + config = (s->internal_base & INTERNAL_BUS_BASE_ADDRESS) | + ((s->address_mask >> 11) & ADDRESS_MASK) | + PCI_ACCESS_ENABLE | + ((s->pci_base >> 24) & PCI_ADDRESS_SETTING); writel(config, PCIMMAW2REG); } if (map->io != NULL) { s = map->io; - config = (s->internal_base & 0xff000000) | - ((s->address_mask & 0x7f000000) >> 11) | (1UL << 12) | - ((s->pci_base & 0xff000000) >> 24); + config = (s->internal_base & INTERNAL_BUS_BASE_ADDRESS) | + ((s->address_mask >> 11) & ADDRESS_MASK) | + PCI_ACCESS_ENABLE | + ((s->pci_base >> 24) & PCI_ADDRESS_SETTING); writel(config, PCIMIOAWREG); } /* Set target memory windows */ - writel(0x00081000, PCITAW1REG); - writel(0UL, PCITAW2REG); - pciu_write_config_dword(PCI_BASE_ADDRESS_0, 0UL); - pciu_write_config_dword(PCI_BASE_ADDRESS_1, 0UL); + writel(0x00081000U, PCITAW1REG); + writel(0U, PCITAW2REG); + + pciu_write_config_dword(PCI_BASE_ADDRESS_0, 0U); + pciu_write_config_dword(PCI_BASE_ADDRESS_1, 0U); /* Clear bus error */ - n = readl(BUSERRADREG); + readl(BUSERRADREG); if (current_cpu_data.cputype == CPU_VR4122) { - writel(0UL, PCITRDYVREG); - pciu_write_config_dword(PCI_CACHE_LINE_SIZE, 0x0000f804); + writel(0U, PCITRDYVREG); + pciu_write_config_byte(PCI_LATENCY_TIMER, 0xf8); } else { - writel(100UL, PCITRDYVREG); - pciu_write_config_dword(PCI_CACHE_LINE_SIZE, 0x00008004); + writel(100U, PCITRDYVREG); + pciu_write_config_byte(PCI_LATENCY_TIMER, 0x80); } writel(CONFIG_DONE, PCIENREG); - pciu_write_config_dword(PCI_COMMAND, - PCI_COMMAND_IO | - PCI_COMMAND_MEMORY | - PCI_COMMAND_MASTER | - PCI_COMMAND_PARITY | - PCI_COMMAND_SERR); + pciu_write_config_word(PCI_COMMAND, + PCI_COMMAND_IO | + PCI_COMMAND_MEMORY | + PCI_COMMAND_MASTER | + PCI_COMMAND_PARITY | + PCI_COMMAND_SERR); } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/pciu.h linux/arch/mips/vr41xx/common/pciu.h --- linux-orig/arch/mips/vr41xx/common/pciu.h 2003-10-31 10:43:08.000000000 +0900 +++ linux/arch/mips/vr41xx/common/pciu.h 2004-02-10 15:53:07.000000000 +0900 @@ -1,34 +1,14 @@ /* - * FILE NAME - * arch/mips/vr41xx/common/pciu.h + * arch/mips/vr41xx/common/pciu.h * - * BRIEF MODULE DESCRIPTION - * Include file for PCI Control Unit of the NEC VR4100 series. + * Include file for PCI Control Unit of the NEC VR4100 series. * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * Author: Yoichi Yuasa <yyuasa@mvista.com, or source@mvista.com> * - * Copyright 2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * 2002-2003 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. */ /* * Changes: @@ -41,24 +21,24 @@ #include <linux/config.h> #include <asm/addrspace.h> -#define BIT(x) (1 << (x)) +#define BIT(x) (1U << (x)) #define PCIMMAW1REG KSEG1ADDR(0x0f000c00) #define PCIMMAW2REG KSEG1ADDR(0x0f000c04) #define PCITAW1REG KSEG1ADDR(0x0f000c08) #define PCITAW2REG KSEG1ADDR(0x0f000c0c) #define PCIMIOAWREG KSEG1ADDR(0x0f000c10) -#define INTERNAL_BUS_BASE_ADDRESS 0xff000000 -#define ADDRESS_MASK 0x000fe000 +#define INTERNAL_BUS_BASE_ADDRESS 0xff000000U +#define ADDRESS_MASK 0x000fe000U #define PCI_ACCESS_ENABLE BIT(12) -#define PCI_ADDRESS_SETTING 0x000000ff +#define PCI_ADDRESS_SETTING 0x000000ffU #define PCICONFDREG KSEG1ADDR(0x0f000c14) #define PCICONFAREG KSEG1ADDR(0x0f000c18) #define PCIMAILREG KSEG1ADDR(0x0f000c1c) #define BUSERRADREG KSEG1ADDR(0x0f000c24) -#define ERROR_ADDRESS 0xfffffffc +#define ERROR_ADDRESS 0xfffffffcU #define INTCNTSTAREG KSEG1ADDR(0x0f000c28) #define MABTCLR BIT(31) @@ -72,91 +52,102 @@ #define EAREQ BIT(0) #define PCIRECONTREG KSEG1ADDR(0x0f000c30) -#define RTRYCNT 0x000000ff +#define RTRYCNT 0xffU #define PCIENREG KSEG1ADDR(0x0f000c34) #define CONFIG_DONE BIT(2) #define PCICLKSELREG KSEG1ADDR(0x0f000c38) -#define EQUAL_VTCLOCK 0x00000002 -#define HALF_VTCLOCK 0x00000000 -#define QUARTER_VTCLOCK 0x00000001 +#define EQUAL_VTCLOCK 0x2U +#define HALF_VTCLOCK 0x0U +#define QUARTER_VTCLOCK 0x1U #define PCITRDYVREG KSEG1ADDR(0x0f000c3c) #define PCICLKRUNREG KSEG1ADDR(0x0f000c60) -#define PCIU_CONFIGREGS_BASE KSEG1ADDR(0x0f000d00) #define VENDORIDREG KSEG1ADDR(0x0f000d00) -#define DEVICEIDREG KSEG1ADDR(0x0f000d00) -#define COMMANDREG KSEG1ADDR(0x0f000d04) -#define STATUSREG KSEG1ADDR(0x0f000d04) -#define REVIDREG KSEG1ADDR(0x0f000d08) -#define CLASSREG KSEG1ADDR(0x0f000d08) -#define CACHELSREG KSEG1ADDR(0x0f000d0c) -#define LATTIMEREG KSEG1ADDR(0x0f000d0c) -#define MAILBAREG KSEG1ADDR(0x0f000d10) -#define PCIMBA1REG KSEG1ADDR(0x0f000d14) -#define PCIMBA2REG KSEG1ADDR(0x0f000d18) -#define INTLINEREG KSEG1ADDR(0x0f000d3c) -#define INTPINREG KSEG1ADDR(0x0f000d3c) -#define RETVALREG KSEG1ADDR(0x0f000d40) -#define PCIAPCNTREG KSEG1ADDR(0x0f000d40) #define MPCIINTREG KSEG1ADDR(0x0f0000b2) #define MAX_PCI_CLOCK 33333333 -static inline int pciu_read_config_byte(int where, u8 *val) +static inline int pciu_read_config_byte(int where, uint8_t *val) { - u32 data; + uint32_t data; - data = readl(PCIU_CONFIGREGS_BASE + where); - *val = (u8)(data >> ((where & 3) << 3)); + if (where > 0xff) + return PCIBIOS_BAD_REGISTER_NUMBER; + + data = readl(VENDORIDREG + (where & 0xfc)); + *val = (uint8_t)(data >> ((where & 3) << 3)); return PCIBIOS_SUCCESSFUL; } -static inline int pciu_read_config_word(int where, u16 *val) +static inline int pciu_read_config_word(int where, uint16_t *val) { - u32 data; + uint32_t data; - if (where & 1) + if (where > 0xff || (where & 1)) return PCIBIOS_BAD_REGISTER_NUMBER; - data = readl(PCIU_CONFIGREGS_BASE + where); - *val = (u16)(data >> ((where & 2) << 3)); + data = readl(VENDORIDREG + (where & 0xfc)); + *val = (uint16_t)(data >> ((where & 2) << 3)); return PCIBIOS_SUCCESSFUL; } -static inline int pciu_read_config_dword(int where, u32 *val) +static inline int pciu_read_config_dword(int where, uint32_t *val) { - if (where & 3) + if (where > 0xff || (where & 3)) return PCIBIOS_BAD_REGISTER_NUMBER; - *val = readl(PCIU_CONFIGREGS_BASE + where); + *val = readl(VENDORIDREG + where); return PCIBIOS_SUCCESSFUL; } -static inline int pciu_write_config_byte(int where, u8 val) +static inline int pciu_write_config_byte(int where, uint8_t val) { - writel(val, PCIU_CONFIGREGS_BASE + where); + uint32_t data; + int shift; + + if (where > 0xff) + return PCIBIOS_BAD_REGISTER_NUMBER; + + data = readl(VENDORIDREG + (where & 0xfc)); + shift = (where & 3) << 3; + data &= ~(0xffU << shift); + data |= (uint32_t)val << shift; + writel(data, VENDORIDREG + (where & 0xfc)); return 0; } -static inline int pciu_write_config_word(int where, u16 val) +static inline int pciu_write_config_word(int where, uint16_t val) { - writel(val, PCIU_CONFIGREGS_BASE + where); + uint32_t data; + int shift; + + if (where > 0xff || (where & 1)) + return PCIBIOS_BAD_REGISTER_NUMBER; + + data = readl(VENDORIDREG + (where & 0xfc)); + shift = (where & 2) << 3; + data &= ~(0xffffU << shift); + data |= (uint32_t)val << shift; + writel(data, VENDORIDREG + (where & 0xfc)); return 0; } -static inline int pciu_write_config_dword(int where, u32 val) +static inline int pciu_write_config_dword(int where, uint32_t val) { - writel(val, PCIU_CONFIGREGS_BASE + where); + if (where > 0xff || (where & 3)) + return PCIBIOS_BAD_REGISTER_NUMBER; + + writel(val, VENDORIDREG + where); return 0; } diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h 2004-02-09 10:43:52.000000000 +0900 +++ linux/include/asm-mips/vr41xx/vr41xx.h 2004-02-10 15:58:45.000000000 +0900 @@ -208,9 +208,9 @@ * PCI Control Unit */ struct vr41xx_pci_address_space { - u32 internal_base; - u32 address_mask; - u32 pci_base; + uint32_t internal_base; + uint32_t address_mask; + uint32_t pci_base; }; struct vr41xx_pci_address_map { From robbat2@orbis-terrarum.net Tue Feb 10 11:21:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 11:21:40 +0000 (GMT) Received: from shawidc-mo1.cg.shawcable.net ([IPv6:::ffff:24.71.223.10]:57180 "EHLO pd5mo1so.prod.shaw.ca") by linux-mips.org with ESMTP id <S8225278AbUBJLVk>; Tue, 10 Feb 2004 11:21:40 +0000 Received: from pd4mr3so.prod.shaw.ca (pd4mr3so-qfe3.prod.shaw.ca [10.0.141.214]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HSV00LE68W24N@l-daemon> for linux-mips@linux-mips.org; Tue, 10 Feb 2004 04:21:38 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca (pn2ml1so-qfe0.prod.shaw.ca [10.0.121.145]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HSV001558W2OF@l-daemon> for linux-mips@linux-mips.org; Tue, 10 Feb 2004 04:21:38 -0700 (MST) Received: from curie.orbis-terrarum.net (h24-84-49-144.vc.shawcable.net [24.84.49.144]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HSV00I098W1CO@l-daemon> for linux-mips@linux-mips.org; Tue, 10 Feb 2004 04:21:37 -0700 (MST) Received: (qmail 9318 invoked by uid 10000); Tue, 10 Feb 2004 03:21:37 -0800 Date: Tue, 10 Feb 2004 03:21:37 -0800 From: "Robin H. Johnson" <robbat2@gentoo.org> Subject: SGI O2 PANIC on mem=xxxM, and strange initrd behavior To: linux-mips <linux-mips@linux-mips.org> Cc: Ilya Volynets <ilya@theIlya.com> Message-id: <20040210112137.GA9213@curie-int.orbis-terrarum.net> MIME-version: 1.0 Content-type: multipart/signed; boundary=RnlQjJ0d97Da+TV1; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.5.1i Return-Path: <robbat2@orbis-terrarum.net> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robbat2@gentoo.org Precedence: bulk X-list: linux-mips --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've recently picked up an SGI O2, 300mhz R12k, 512Mb RAM. Playing with getting it working, using Ilya's minimal patches on top of the LMO CVS HEAD, I noticed that it wasn't pulling up the correct amount of RAM. I threw mem=3D512M onto the params, and found a kernel crash. Boots mostly fine: http://www.orbis-terrarum.net/~robbat2/sgio2/kernel.boot Crashes: http://www.orbis-terrarum.net/~robbat2/sgio2/kernel.crash Decoded: http://www.orbis-terrarum.net/~robbat2/sgio2/decoded.panic Kernel config: http://www.orbis-terrarum.net/~robbat2/sgio2/kernel.config I've also got one weird problem where it never gets any further than the init call to my busybox initrd. Output using an old debian netboot initrd (from debian-mips-2.4.19.img): serial console detected. Disabling virtual terminals. init started: BusyBox v0.60.3-pre (2002.01.22-06:31+0000) multi-call binary Output for using bleeding-edge Gentoo initrd that works perfectly for an Indy and an I2: init started: BusyBox v1.00-pre7 (2004.02.10-08:42+0000) multi-call binary In both cases, right after the init message, absolutely nothing happens. I've tried putting commands in the linuxrc that would cause some externally visible activity, but nothing. I am wondering if it may have to with the virtual consoles (which I had to turn off to get any serial output), but I doubt they are the problem. --=20 Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFAKL7BsnuUTjSIToURAvIFAKCpZHb3Dv9Aeic4nfOQgv7ZTfAOSwCdF7rl hfMMBPk6oLgj1ROBzhrZKSE= =yHpX -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From ralf@linux-mips.org Tue Feb 10 14:18:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 14:18:10 +0000 (GMT) Received: from p508B76C0.dip.t-dialin.net ([IPv6:::ffff:80.139.118.192]:54389 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id <S8225343AbUBJOSK>; Tue, 10 Feb 2004 14:18:10 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1AEHOex029177; Tue, 10 Feb 2004 15:17:24 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1AEHLVm029176; Tue, 10 Feb 2004 15:17:21 +0100 Date: Tue, 10 Feb 2004 15:17:21 +0100 From: Ralf Baechle <ralf@linux-mips.org> To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Cc: linux-mips <linux-mips@linux-mips.org> Subject: Re: [PATCH][2.4] Fixed configration problem for vr41xx Message-ID: <20040210141720.GA29170@linux-mips.org> References: <20040210063846.66ec64a9.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040210063846.66ec64a9.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.1i Return-Path: <ralf@linux-mips.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4324 X-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, Feb 10, 2004 at 06:38:46AM +0900, Yoichi Yuasa wrote: > I made a patch for configuration problem for vr41xx. > This patch corrects the problem which occurs when CONFIG_SERIAL is n. > > Please apply this patch to v2.4. Done, Ralf From yuasa@hh.iij4u.or.jp Tue Feb 10 15:27:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 15:27:17 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:23792 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225343AbUBJP1P>; Tue, 10 Feb 2004 15:27:15 +0000 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 AAA17425; Wed, 11 Feb 2004 00:27:11 +0900 (JST) Received: 4UMDO00 id i1AFRAP08783; Wed, 11 Feb 2004 00:27:10 +0900 (JST) Received: 4UMRO01 id i1AFR8d14236; Wed, 11 Feb 2004 00:27:09 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Wed, 11 Feb 2004 00:27:06 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Changed machine_restart/halt/power_off for vr41xx Message-Id: <20040211002706.69faafb4.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4325 X-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 Hello Ralf, I made the patch for machine_restart/halt/power_off for vr41xx. This patch updates these functions. The same patch is already apply to v2.6. I am going to add power management to pmu.c. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c --- linux-orig/arch/mips/vr41xx/casio-e55/setup.c Tue Feb 10 23:22:07 2004 +++ linux/arch/mips/vr41xx/casio-e55/setup.c Wed Feb 11 00:10:22 2004 @@ -1,25 +1,28 @@ /* - * FILE NAME - * arch/mips/vr41xx/casio-e55/setup.c + * setup.c, Setup for the CASIO CASSIOPEIA E-11/15/55/65. * - * BRIEF MODULE DESCRIPTION - * Setup for the CASIO CASSIOPEIA E-11/15/55/65. + * Copyright (C) 2002-2004 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <linux/config.h> -#include <linux/init.h> #include <linux/console.h> #include <linux/ide.h> +#include <linux/init.h> #include <linux/ioport.h> -#include <asm/reboot.h> #include <asm/time.h> #include <asm/vr41xx/e55.h> @@ -31,10 +34,6 @@ iomem_resource.start = IO_MEM_RESOURCE_START; iomem_resource.end = IO_MEM_RESOURCE_END; - _machine_restart = vr41xx_restart; - _machine_halt = vr41xx_halt; - _machine_power_off = vr41xx_power_off; - board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; @@ -47,8 +46,8 @@ #endif vr41xx_bcu_init(); - vr41xx_cmu_init(); + vr41xx_pmu_init(); #ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/Makefile linux/arch/mips/vr41xx/common/Makefile --- linux-orig/arch/mips/vr41xx/common/Makefile Fri Jan 16 01:19:00 2004 +++ linux/arch/mips/vr41xx/common/Makefile Tue Feb 10 23:45:45 2004 @@ -12,7 +12,7 @@ O_TARGET := vr41xx.o -obj-y := bcu.o cmu.o giu.o icu.o int-handler.o ksyms.o reset.o rtc.o +obj-y := bcu.o cmu.o giu.o icu.o int-handler.o ksyms.o pmu.o rtc.o export-objs := ksyms.o vrc4171.o vrc4173.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/pmu.c linux/arch/mips/vr41xx/common/pmu.c --- linux-orig/arch/mips/vr41xx/common/pmu.c Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/vr41xx/common/pmu.c Tue Feb 10 23:45:45 2004 @@ -0,0 +1,75 @@ +/* + * pmu.c, Power Management Unit routines for NEC VR4100 series. + * + * Copyright (C) 2003 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include <linux/init.h> +#include <linux/types.h> + +#include <asm/cpu.h> +#include <asm/io.h> +#include <asm/reboot.h> +#include <asm/system.h> + +#define PMUCNT2REG KSEG1ADDR(0x0f0000c6) + #define SOFTRST 0x0010 + +static inline void software_reset(void) +{ + uint16_t val; + + switch (current_cpu_data.cputype) { + case CPU_VR4122: + case CPU_VR4131: + case CPU_VR4133: + val = readw(PMUCNT2REG); + val |= SOFTRST; + writew(val, PMUCNT2REG); + break; + default: + break; + } +} + +static void vr41xx_restart(char *command) +{ + local_irq_disable(); + software_reset(); + printk(KERN_NOTICE "\nYou can reset your system\n"); + while (1) ; +} + +static void vr41xx_halt(void) +{ + local_irq_disable(); + printk(KERN_NOTICE "\nYou can turn off the power supply\n"); + while (1) ; +} + +static void vr41xx_power_off(void) +{ + local_irq_disable(); + printk(KERN_NOTICE "\nYou can turn off the power supply\n"); + while (1) ; +} + +void __init vr41xx_pmu_init(void) +{ + _machine_restart = vr41xx_restart; + _machine_halt = vr41xx_halt; + _machine_power_off = vr41xx_power_off; +} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/reset.c linux/arch/mips/vr41xx/common/reset.c --- linux-orig/arch/mips/vr41xx/common/reset.c Mon Dec 2 09:24:51 2002 +++ linux/arch/mips/vr41xx/common/reset.c Thu Jan 1 09:00:00 1970 @@ -1,37 +0,0 @@ -/* - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * Copyright (C) 1997, 2001 Ralf Baechle - * Copyright 2001 MontaVista Software Inc. - * Author: jsun@mvista.com or jsun@junsun.net - */ -#include <linux/sched.h> -#include <linux/mm.h> -#include <asm/io.h> -#include <asm/pgtable.h> -#include <asm/processor.h> -#include <asm/reboot.h> -#include <asm/system.h> - -void vr41xx_restart(char *command) -{ - change_c0_status((ST0_BEV | ST0_ERL), (ST0_BEV | ST0_ERL)); - change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); - flush_cache_all(); - write_c0_wired(0); - __asm__ __volatile__("jr\t%0"::"r"(0xbfc00000)); -} - -void vr41xx_halt(void) -{ - printk(KERN_NOTICE "\n** You can safely turn off the power\n"); - while (1); -} - -void vr41xx_power_off(void) -{ - vr41xx_halt(); -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c --- linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c Tue Feb 10 23:22:07 2004 +++ linux/arch/mips/vr41xx/ibm-workpad/setup.c Wed Feb 11 00:10:12 2004 @@ -1,25 +1,28 @@ /* - * FILE NAME - * arch/mips/vr41xx/workpad/setup.c + * setup.c, Setup for the IBM WorkPad z50. * - * BRIEF MODULE DESCRIPTION - * Setup for the IBM WorkPad z50. + * Copyright (C) 2002-2004 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <linux/config.h> -#include <linux/init.h> #include <linux/console.h> #include <linux/ide.h> +#include <linux/init.h> #include <linux/ioport.h> -#include <asm/reboot.h> #include <asm/time.h> #include <asm/vr41xx/workpad.h> @@ -31,10 +34,6 @@ iomem_resource.start = IO_MEM_RESOURCE_START; iomem_resource.end = IO_MEM_RESOURCE_END; - _machine_restart = vr41xx_restart; - _machine_halt = vr41xx_halt; - _machine_power_off = vr41xx_power_off; - board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; @@ -47,8 +46,8 @@ #endif vr41xx_bcu_init(); - vr41xx_cmu_init(); + vr41xx_pmu_init(); #ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Sat Feb 7 10:32:18 2004 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Wed Feb 11 00:10:33 2004 @@ -1,34 +1,14 @@ /* - * FILE NAME - * arch/mips/vr41xx/nec-eagle/setup.c + * arch/mips/vr41xx/nec-eagle/setup.c * - * BRIEF MODULE DESCRIPTION - * Setup for the NEC Eagle/Hawk board. + * Setup for the NEC Eagle/Hawk board. * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * Author: Yoichi Yuasa <yyuasa@mvista.com, or source@mvista.com> * - * Copyright 2001,2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * 2001-2004 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. */ /* * Changes: @@ -40,13 +20,12 @@ * - New creation, NEC Eagle is supported. */ #include <linux/config.h> -#include <linux/init.h> #include <linux/console.h> #include <linux/ide.h> +#include <linux/init.h> #include <linux/ioport.h> #include <asm/pci_channel.h> -#include <asm/reboot.h> #include <asm/time.h> #include <asm/vr41xx/eagle.h> @@ -108,10 +87,6 @@ iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - _machine_restart = vr41xx_restart; - _machine_halt = vr41xx_halt; - _machine_power_off = vr41xx_power_off; - board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; @@ -126,8 +101,8 @@ #endif vr41xx_bcu_init(); - vr41xx_cmu_init(); + vr41xx_pmu_init(); #ifdef CONFIG_SERIAL vr41xx_dsiu_init(); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c Tue Feb 10 23:22:07 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c Wed Feb 11 00:09:40 2004 @@ -1,25 +1,28 @@ /* - * FILE NAME - * arch/mips/vr41xx/tanbac-tb0226/setup.c + * setup.c, Setup for the TANBAC TB0226. * - * BRIEF MODULE DESCRIPTION - * Setup for the TANBAC TB0226. + * Copyright (C) 2002-2004 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> * - * Copyright 2002,2003 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <linux/config.h> -#include <linux/init.h> #include <linux/console.h> +#include <linux/init.h> #include <linux/ioport.h> #include <asm/pci_channel.h> -#include <asm/reboot.h> #include <asm/time.h> #include <asm/vr41xx/tb0226.h> @@ -76,10 +79,6 @@ iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - _machine_restart = vr41xx_restart; - _machine_halt = vr41xx_halt; - _machine_power_off = vr41xx_power_off; - board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; @@ -88,8 +87,8 @@ #endif vr41xx_bcu_init(); - vr41xx_cmu_init(); + vr41xx_pmu_init(); #ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile linux/arch/mips/vr41xx/tanbac-tb0229/Makefile --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile Thu May 22 06:36:53 2003 +++ linux/arch/mips/vr41xx/tanbac-tb0229/Makefile Tue Feb 10 23:45:45 2004 @@ -12,8 +12,9 @@ all: tb0229.o -obj-y := init.o setup.o reboot.o +obj-y := init.o setup.o -obj-$(CONFIG_PCI) += pci_fixup.o +obj-$(CONFIG_PCI) += pci_fixup.o +obj-$(CONFIG_TANBAC_TB0219) += reboot.o include $(TOPDIR)/Rules.make diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/reboot.c Thu May 22 06:36:53 2003 +++ linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c Tue Feb 10 23:45:45 2004 @@ -16,15 +16,11 @@ #include <asm/io.h> #include <asm/vr41xx/tb0229.h> -#define tb0229_hard_reset() writew(0, TB0219_RESET_REGS) +#define tb0219_hard_reset() writew(0, TB0219_RESET_REGS) -void tanbac_tb0229_restart(char *command) +void tanbac_tb0219_restart(char *command) { -#ifdef CONFIG_TANBAC_TB0219 local_irq_disable(); - tb0229_hard_reset(); + tb0219_hard_reset(); while (1); -#else - vr41xx_restart(command); -#endif } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c Tue Feb 10 23:22:07 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c Wed Feb 11 00:11:06 2004 @@ -1,24 +1,26 @@ /* - * FILE NAME - * arch/mips/vr41xx/tanbac-tb0229/setup.c + * setup.c, Setup for the TANBAC TB0229 (VR4131DIMM) * - * BRIEF MODULE DESCRIPTION - * Setup for the TANBAC TB0229 (VR4131DIMM) + * Copyright (C) 2002-2004 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> * - * Copyright 2002,2003 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * Modified for TANBAC TB0229: + * Copyright (C) 2003 Megasolution Inc. <matsu@megasolution.jp> * - * Modified for TANBAC TB0229: - * Copyright 2003 Megasolution Inc. - * matsu@megasolution.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <linux/config.h> -#include <linux/blk.h> #include <linux/console.h> #include <linux/init.h> #include <linux/ioport.h> @@ -89,10 +91,6 @@ iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - _machine_restart = tanbac_tb0229_restart; - _machine_halt = vr41xx_halt; - _machine_power_off = vr41xx_power_off; - board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; @@ -101,8 +99,8 @@ #endif vr41xx_bcu_init(); - vr41xx_cmu_init(); + vr41xx_pmu_init(); #ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); @@ -112,5 +110,8 @@ #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); #endif -} +#ifdef CONFIG_TANBAC_TB0219 + _machine_restart = tanbac_tb0219_restart; +#endif +} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c Tue Feb 10 23:22:07 2004 +++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c Wed Feb 11 00:13:25 2004 @@ -1,26 +1,29 @@ /* - * FILE NAME - * arch/mips/vr41xx/victor-mpc30x/setup.c + * setup.c, Setup for the Victor MP-C303/304. * - * BRIEF MODULE DESCRIPTION - * Setup for the Victor MP-C303/304. + * Copyright (C) 2002-2004 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <linux/config.h> -#include <linux/init.h> #include <linux/console.h> #include <linux/ide.h> +#include <linux/init.h> #include <linux/ioport.h> #include <asm/pci_channel.h> -#include <asm/reboot.h> #include <asm/time.h> #include <asm/vr41xx/mpc30x.h> @@ -77,10 +80,6 @@ iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - _machine_restart = vr41xx_restart; - _machine_halt = vr41xx_halt; - _machine_power_off = vr41xx_power_off; - board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; @@ -93,8 +92,8 @@ #endif vr41xx_bcu_init(); - vr41xx_cmu_init(); + vr41xx_pmu_init(); #ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c --- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c Tue Feb 10 23:22:07 2004 +++ linux/arch/mips/vr41xx/zao-capcella/setup.c Wed Feb 11 00:15:24 2004 @@ -1,26 +1,29 @@ /* - * FILE NAME - * arch/mips/vr41xx/zao-capcella/setup.c + * setup.c, Setup for the ZAO Networks Capcella. * - * BRIEF MODULE DESCRIPTION - * Setup for the ZAO Networks Capcella. + * Copyright (C) 2002-2004 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <linux/config.h> -#include <linux/init.h> #include <linux/console.h> #include <linux/ide.h> +#include <linux/init.h> #include <linux/ioport.h> #include <asm/pci_channel.h> -#include <asm/reboot.h> #include <asm/time.h> #include <asm/vr41xx/capcella.h> @@ -77,10 +80,6 @@ iomem_resource.start = IO_MEM1_RESOURCE_START; iomem_resource.end = IO_MEM2_RESOURCE_END; - _machine_restart = vr41xx_restart; - _machine_halt = vr41xx_halt; - _machine_power_off = vr41xx_power_off; - board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; @@ -93,8 +92,8 @@ #endif vr41xx_bcu_init(); - vr41xx_cmu_init(); + vr41xx_pmu_init(); #ifdef CONFIG_SERIAL vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/tb0229.h linux/include/asm-mips/vr41xx/tb0229.h --- linux-orig/include/asm-mips/vr41xx/tb0229.h Thu May 22 06:36:53 2003 +++ linux/include/asm-mips/vr41xx/tb0229.h Tue Feb 10 23:45:46 2004 @@ -68,6 +68,6 @@ #define TB0219_RESET_REGS KSEG1ADDR(0x0a00000e) -extern void tanbac_tb0229_restart(char *command); +extern void tanbac_tb0219_restart(char *command); #endif /* __TANBAC_TB0229_H */ diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Tue Feb 10 22:33:56 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Tue Feb 10 23:45:46 2004 @@ -134,6 +134,11 @@ extern int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq)); /* + * Power Management Unit + */ +extern void vr41xx_pmu_init(void); + +/* * RTC */ extern void vr41xx_set_rtclong1_cycle(uint32_t cycles); @@ -228,10 +233,6 @@ */ extern void vr41xx_time_init(void); extern void vr41xx_timer_setup(struct irqaction *irq); - -extern void vr41xx_restart(char *command); -extern void vr41xx_halt(void); -extern void vr41xx_power_off(void); #if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE) extern struct ide_ops vr41xx_ide_ops; From macro@ds2.pg.gda.pl Tue Feb 10 16:15:43 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 16:15:43 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:56767 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id <S8225343AbUBJQPm>; Tue, 10 Feb 2004 16:15:42 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id DEE8C4C3D6; Tue, 10 Feb 2004 17:15:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id CB2024C175; Tue, 10 Feb 2004 17:15:39 +0100 (CET) Date: Tue, 10 Feb 2004 17:15:39 +0100 (CET) From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> To: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Subject: [patch] dump_tlb.c clean-ups Message-ID: <Pine.LNX.4.55.0402101653290.6769@jurand.ds.pg.gda.pl> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: <macro@ds2.pg.gda.pl> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Ralf, Gcc 3.4 complains about a possibly undefined operation in dump16() in arch/mips/lib/r3k_dump_tlb.c. The following patch fixes it. I've taken the opportunity to clean up the file and its counterparts thus: 1. I've cast the pointers to "unsigned long" consistently for output formatting as the width specifier doesn't work very well with pointers. 2. I've renamed msg2str() to msk2str() in one of the variations. 3. I've reordered header inclusions in one of the variations. 4. I've fixed indentation throughout, perhaps not completely, but still the result should be somewhat closer to sanity. These changes make the three variations closer to one another where possible. OK to apply? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.24-pre2-20040116-dump_tlb-0 diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/dump_tlb.c linux-mips-2.4.24-pre2-20040116/arch/mips/lib/dump_tlb.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/dump_tlb.c 2003-04-24 02:56:38.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/lib/dump_tlb.c 2004-02-09 22:13:24.000000000 +0000 @@ -11,13 +11,13 @@ #include <linux/string.h> #include <asm/bootinfo.h> -#include <asm/cpu.h> #include <asm/cachectl.h> +#include <asm/cpu.h> #include <asm/mipsregs.h> #include <asm/page.h> #include <asm/pgtable.h> -static inline const char *msg2str(unsigned int mask) +static inline const char *msk2str(unsigned int mask) { switch (mask) { case PM_4K: return "4kb"; @@ -44,7 +44,7 @@ void dump_tlb(int first, int last) asid = read_c0_entryhi() & 0xff; printk("\n"); - for(i=first;i<=last;i++) { + for (i = first; i <= last; i++) { write_c0_index(i); __asm__ __volatile__( ".set\tmips3\n\t" @@ -65,7 +65,7 @@ void dump_tlb(int first, int last) /* * Only print entries in use */ - printk("Index: %2d pgmask=%s ", i, msg2str(pagemask)); + printk("Index: %2d pgmask=%s ", i, msk2str(pagemask)); c0 = (entrylo0 >> 3) & 7; c1 = (entrylo1 >> 3) & 7; @@ -109,8 +109,7 @@ void dump_tlb_wired(void) "nop;nop;nop;nop;nop;nop;nop\n\t" \ ".set\treorder"); -void -dump_tlb_addr(unsigned long addr) +void dump_tlb_addr(unsigned long addr) { unsigned long flags, oldpid; int index; @@ -135,14 +134,12 @@ dump_tlb_addr(unsigned long addr) dump_tlb(index, index); } -void -dump_tlb_nonwired(void) +void dump_tlb_nonwired(void) { dump_tlb(read_c0_wired(), current_cpu_data.tlbsize - 1); } -void -dump_list_process(struct task_struct *t, void *address) +void dump_list_process(struct task_struct *t, void *address) { pgd_t *page_dir, *pgd; pmd_t *pmd; @@ -194,14 +191,12 @@ dump_list_process(struct task_struct *t, printk("\n"); } -void -dump_list_current(void *address) +void dump_list_current(void *address) { dump_list_process(current, address); } -unsigned int -vtop(void *address) +unsigned int vtop(void *address) { pgd_t *pgd; pmd_t *pmd; @@ -218,14 +213,14 @@ vtop(void *address) return paddr; } -void -dump16(unsigned long *p) +void dump16(unsigned long *p) { int i; - for(i=0;i<8;i++) - { - printk("*%8p = %08lx, ", p, *p); p++; - printk("*%8p = %08lx\n", p, *p); p++; + for (i = 0; i < 8; i++) { + printk("*%08lx == %08lx, ", (unsigned long)p, *p); + p++; + printk("*%08lx == %08lx\n", (unsigned long)p, *p); + p++; } } diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/r3k_dump_tlb.c linux-mips-2.4.24-pre2-20040116/arch/mips/lib/r3k_dump_tlb.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/r3k_dump_tlb.c 2003-04-07 02:56:28.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/lib/r3k_dump_tlb.c 2004-02-09 22:13:36.000000000 +0000 @@ -19,8 +19,7 @@ extern int r3k_have_wired_reg; /* defined in tlb-r3k.c */ -void -dump_tlb(int first, int last) +void dump_tlb(int first, int last) { int i; unsigned int asid; @@ -28,8 +27,7 @@ dump_tlb(int first, int last) asid = read_c0_entryhi() & 0xfc0; - for(i=first;i<=last;i++) - { + for (i = first; i <= last; i++) { write_c0_index(i<<8); __asm__ __volatile__( ".set\tnoreorder\n\t" @@ -63,14 +61,12 @@ dump_tlb(int first, int last) write_c0_entryhi(asid); } -void -dump_tlb_all(void) +void dump_tlb_all(void) { dump_tlb(0, current_cpu_data.tlbsize - 1); } -void -dump_tlb_wired(void) +void dump_tlb_wired(void) { int wired = r3k_have_wired_reg ? read_c0_wired() : 8; @@ -78,8 +74,7 @@ dump_tlb_wired(void) dump_tlb(0, wired - 1); } -void -dump_tlb_addr(unsigned long addr) +void dump_tlb_addr(unsigned long addr) { unsigned long flags, oldpid; int index; @@ -101,15 +96,13 @@ dump_tlb_addr(unsigned long addr) dump_tlb(index, index); } -void -dump_tlb_nonwired(void) +void dump_tlb_nonwired(void) { int wired = r3k_have_wired_reg ? read_c0_wired() : 8; dump_tlb(wired, current_cpu_data.tlbsize - 1); } -void -dump_list_process(struct task_struct *t, void *address) +void dump_list_process(struct task_struct *t, void *address) { pgd_t *page_dir, *pgd; pmd_t *pmd; @@ -148,14 +141,12 @@ dump_list_process(struct task_struct *t, printk("\n"); } -void -dump_list_current(void *address) +void dump_list_current(void *address) { dump_list_process(current, address); } -unsigned int -vtop(void *address) +unsigned int vtop(void *address) { pgd_t *pgd; pmd_t *pmd; @@ -172,16 +163,14 @@ vtop(void *address) return paddr; } -void -dump16(unsigned long *p) +void dump16(unsigned long *p) { int i; - for(i=0;i<8;i++) - { - printk("*%08lx == %08lx, ", - (unsigned long)p, (unsigned long)*p++); - printk("*%08lx == %08lx\n", - (unsigned long)p, (unsigned long)*p++); + for (i = 0; i < 8; i++) { + printk("*%08lx == %08lx, ", (unsigned long)p, *p); + p++; + printk("*%08lx == %08lx\n", (unsigned long)p, *p); + p++; } } diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/dump_tlb.c linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/dump_tlb.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/dump_tlb.c 2003-04-07 02:56:31.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/dump_tlb.c 2004-02-09 22:12:48.000000000 +0000 @@ -201,12 +201,10 @@ void dump16(unsigned long *p) { int i; - for(i = 0; i < 8; i++) { - printk("*%08lx == %08lx, ", - (unsigned long)p, (unsigned long)*p); + for (i = 0; i < 8; i++) { + printk("*%08lx == %08lx, ", (unsigned long)p, *p); p++; - printk("*%08lx == %08lx\n", - (unsigned long)p, (unsigned long)*p); + printk("*%08lx == %08lx\n", (unsigned long)p, *p); p++; } } From macro@ds2.pg.gda.pl Tue Feb 10 16:19:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 16:19:35 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:12993 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id <S8225343AbUBJQTf>; Tue, 10 Feb 2004 16:19:35 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 740E74C3D6; Tue, 10 Feb 2004 17:19:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 5DDD44C175; Tue, 10 Feb 2004 17:19:33 +0100 (CET) Date: Tue, 10 Feb 2004 17:19:33 +0100 (CET) From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> To: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Subject: [patch] irq_cpu.c clean-ups Message-ID: <Pine.LNX.4.55.0402101716130.6769@jurand.ds.pg.gda.pl> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: <macro@ds2.pg.gda.pl> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Ralf, The two copies of irq_cpu.c should both in theory and in practice be the same, but for some reason they are not. Here's a patch for 2.4 to bring them to sync. The next step would be a trivial update for 2.6 to make that version the same as these two as well. OK to apply? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.24-pre2-20040116-irq_cpu-0 diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/irq_cpu.c linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/irq_cpu.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/irq_cpu.c 2003-02-05 03:56:38.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/irq_cpu.c 2004-02-09 22:33:17.000000000 +0000 @@ -2,6 +2,8 @@ * Copyright 2001 MontaVista Software Inc. * Author: Jun Sun, jsun@mvista.com or jsun@junsun.net * + * Copyright (C) 2001 Ralf Baechle + * * This file define the irq handler for MIPS CPU interrupts. * * This program is free software; you can redistribute it and/or modify it @@ -13,9 +15,12 @@ /* * Almost all MIPS CPUs define 8 interrupt sources. They are typically * level triggered (i.e., cannot be cleared from CPU; must be cleared from - * device). The first two are software interrupts. The last one is - * usually the CPU timer interrupt if counter register is present or, for - * CPUs with an external FPU, by convention it's the FPU exception interrupt. + * device). The first two are software interrupts which we don't really + * use or support. The last one is usually the CPU timer interrupt if + * counter register is present or, for CPUs with an external FPU, by + * convention it's the FPU exception interrupt. + * + * Don't even think about using this on SMP. You have been warned. * * This file exports one global function: * void mips_cpu_irq_init(int irq_base); @@ -26,18 +31,37 @@ #include <asm/irq_cpu.h> #include <asm/mipsregs.h> +#include <asm/system.h> + +static int mips_cpu_irq_base; + +static inline void unmask_mips_irq(unsigned int irq) +{ + clear_c0_cause(0x100 << (irq - mips_cpu_irq_base)); + set_c0_status(0x100 << (irq - mips_cpu_irq_base)); +} -static int mips_cpu_irq_base = -1; +static inline void mask_mips_irq(unsigned int irq) +{ + clear_c0_status(0x100 << (irq - mips_cpu_irq_base)); +} -static void mips_cpu_irq_enable(unsigned int irq) +static inline void mips_cpu_irq_enable(unsigned int irq) { - clear_c0_cause( 1 << (irq - mips_cpu_irq_base + 8)); - set_c0_status(1 << (irq - mips_cpu_irq_base + 8)); + unsigned long flags; + + local_irq_save(flags); + unmask_mips_irq(irq); + local_irq_restore(flags); } static void mips_cpu_irq_disable(unsigned int irq) { - clear_c0_status(1 << (irq - mips_cpu_irq_base + 8)); + unsigned long flags; + + local_irq_save(flags); + mask_mips_irq(irq); + local_irq_restore(flags); } static unsigned int mips_cpu_irq_startup(unsigned int irq) @@ -49,21 +73,22 @@ static unsigned int mips_cpu_irq_startup #define mips_cpu_irq_shutdown mips_cpu_irq_disable +/* + * While we ack the interrupt interrupts are disabled and thus we don't need + * to deal with concurrency issues. Same for mips_cpu_irq_end. + */ static void mips_cpu_irq_ack(unsigned int irq) { - /* although we attempt to clear the IP bit in cause register, I think - * usually it is cleared by device (irq source) - */ - clear_c0_cause(1 << (irq - mips_cpu_irq_base + 8)); + /* Only necessary for soft interrupts */ + clear_c0_cause(0x100 << (irq - mips_cpu_irq_base)); - /* disable this interrupt - so that we safe proceed to the handler */ - mips_cpu_irq_disable(irq); + mask_mips_irq(irq); } static void mips_cpu_irq_end(unsigned int irq) { if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - mips_cpu_irq_enable(irq); + unmask_mips_irq(irq); } static hw_irq_controller mips_cpu_irq_controller = { diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/irq_cpu.c linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/irq_cpu.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/irq_cpu.c 2002-12-04 03:56:39.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/irq_cpu.c 2004-02-09 22:33:36.000000000 +0000 @@ -16,18 +16,20 @@ * Almost all MIPS CPUs define 8 interrupt sources. They are typically * level triggered (i.e., cannot be cleared from CPU; must be cleared from * device). The first two are software interrupts which we don't really - * use or support. The last one is usually cpu timer interrupt if a counter - * register is present. + * use or support. The last one is usually the CPU timer interrupt if + * counter register is present or, for CPUs with an external FPU, by + * convention it's the FPU exception interrupt. * * Don't even think about using this on SMP. You have been warned. * * This file exports one global function: - * mips_cpu_irq_init(u32 irq_base); + * void mips_cpu_irq_init(int irq_base); */ +#include <linux/init.h> #include <linux/interrupt.h> -#include <linux/types.h> #include <linux/kernel.h> +#include <asm/irq_cpu.h> #include <asm/mipsregs.h> #include <asm/system.h> @@ -78,7 +80,7 @@ static unsigned int mips_cpu_irq_startup static void mips_cpu_irq_ack(unsigned int irq) { /* Only necessary for soft interrupts */ - clear_c0_cause(1 << (irq - mips_cpu_irq_base + 8)); + clear_c0_cause(0x100 << (irq - mips_cpu_irq_base)); mask_mips_irq(irq); } @@ -90,7 +92,7 @@ static void mips_cpu_irq_end(unsigned in } static hw_irq_controller mips_cpu_irq_controller = { - "CPU_irq", + "MIPS", mips_cpu_irq_startup, mips_cpu_irq_shutdown, mips_cpu_irq_enable, @@ -101,9 +103,9 @@ static hw_irq_controller mips_cpu_irq_co }; -void mips_cpu_irq_init(u32 irq_base) +void __init mips_cpu_irq_init(int irq_base) { - u32 i; + int i; for (i = irq_base; i < irq_base + 8; i++) { irq_desc[i].status = IRQ_DISABLED; From ralf@linux-mips.org Tue Feb 10 16:35:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 16:35:34 +0000 (GMT) Received: from p508B76C0.dip.t-dialin.net ([IPv6:::ffff:80.139.118.192]:6775 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id <S8225343AbUBJQfW>; Tue, 10 Feb 2004 16:35:22 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1AGYWex030653; Tue, 10 Feb 2004 17:34:32 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1AGY7jm030643; Tue, 10 Feb 2004 17:34:07 +0100 Date: Tue, 10 Feb 2004 17:34:07 +0100 From: Ralf Baechle <ralf@linux-mips.org> To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> Cc: linux-mips@linux-mips.org Subject: Re: [patch] dump_tlb.c clean-ups Message-ID: <20040210163407.GA30617@linux-mips.org> References: <Pine.LNX.4.55.0402101653290.6769@jurand.ds.pg.gda.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.LNX.4.55.0402101653290.6769@jurand.ds.pg.gda.pl> User-Agent: Mutt/1.4.1i Return-Path: <ralf@linux-mips.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4328 X-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, Feb 10, 2004 at 05:15:39PM +0100, Maciej W. Rozycki wrote: > Ralf, > > Gcc 3.4 complains about a possibly undefined operation in dump16() in > arch/mips/lib/r3k_dump_tlb.c. The following patch fixes it. I've taken > the opportunity to clean up the file and its counterparts thus: > > 1. I've cast the pointers to "unsigned long" consistently for output > formatting as the width specifier doesn't work very well with pointers. > > 2. I've renamed msg2str() to msk2str() in one of the variations. > > 3. I've reordered header inclusions in one of the variations. > > 4. I've fixed indentation throughout, perhaps not completely, but still > the result should be somewhat closer to sanity. > > These changes make the three variations closer to one another where > possible. > > OK to apply? Sure, go ahead. I guess the output format could also use some improvments for readability ... Ralf From ralf@linux-mips.org Tue Feb 10 16:40:12 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 16:40:12 +0000 (GMT) Received: from p508B76C0.dip.t-dialin.net ([IPv6:::ffff:80.139.118.192]:12407 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id <S8225512AbUBJQkM>; Tue, 10 Feb 2004 16:40:12 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1AGdXex030723; Tue, 10 Feb 2004 17:39:34 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1AGdXiY030722; Tue, 10 Feb 2004 17:39:33 +0100 Date: Tue, 10 Feb 2004 17:39:33 +0100 From: Ralf Baechle <ralf@linux-mips.org> To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> Cc: linux-mips@linux-mips.org Subject: Re: [patch] irq_cpu.c clean-ups Message-ID: <20040210163933.GB30617@linux-mips.org> References: <Pine.LNX.4.55.0402101716130.6769@jurand.ds.pg.gda.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.LNX.4.55.0402101716130.6769@jurand.ds.pg.gda.pl> User-Agent: Mutt/1.4.1i Return-Path: <ralf@linux-mips.org> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4329 X-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, Feb 10, 2004 at 05:19:33PM +0100, Maciej W. Rozycki wrote: > The two copies of irq_cpu.c should both in theory and in practice be the > same, but for some reason they are not. Here's a patch for 2.4 to bring > them to sync. The next step would be a trivial update for 2.6 to make > that version the same as these two as well. > > OK to apply? Yes, Ralf From yuasa@hh.iij4u.or.jp Tue Feb 10 16:59:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 16:59:56 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:980 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225515AbUBJQ7z>; Tue, 10 Feb 2004 16:59:55 +0000 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 BAA04998; Wed, 11 Feb 2004 01:59:51 +0900 (JST) Received: 4UMDO00 id i1AGxpP09344; Wed, 11 Feb 2004 01:59:51 +0900 (JST) Received: 4UMRO01 id i1AGxod19261; Wed, 11 Feb 2004 01:59:50 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Wed, 11 Feb 2004 01:59:47 +0900 From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> To: Ralf Baechle <ralf@linux-mips.org> Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org> Subject: [PATCH][2.4] Added IDE IRQ share support for IBM WorkPad z50 Message-Id: <20040211015947.7ae0f667.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: <yuasa@hh.iij4u.or.jp> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4330 X-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 Hello Ralf, I made a patch for IBM WorkPad z50. This patch added IDE IRQ share support for IBM WorkPad z50. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/config-shared.in linux/arch/mips/config-shared.in --- linux-orig/arch/mips/config-shared.in Fri Feb 6 08:33:13 2004 +++ linux/arch/mips/config-shared.in Wed Feb 11 01:53:08 2004 @@ -444,6 +444,7 @@ define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_ISA y define_bool CONFIG_SCSI n + define_bool CONFIG_IDEPCI_SHARE_IRQ y fi if [ "$CONFIG_LASAT" = "y" ]; then define_bool CONFIG_BOARD_SCACHE y diff -urN -X dontdiff linux-orig/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c --- linux-orig/drivers/ide/ide-probe.c Thu Nov 27 00:29:14 2003 +++ linux/drivers/ide/ide-probe.c Wed Feb 11 01:53:08 2004 @@ -1077,9 +1077,9 @@ */ if (!match || match->irq != hwif->irq) { int sa = SA_INTERRUPT; -#if defined(__mc68000__) || defined(CONFIG_APUS) +#if defined(__mc68000__) || defined(CONFIG_APUS) || defined(CONFIG_IBM_WORKPAD) sa = SA_SHIRQ; -#endif /* __mc68000__ || CONFIG_APUS */ +#endif /* __mc68000__ || CONFIG_APUS || CONFIG_IBM_WORKPAD */ if (IDE_CHIPSET_IS_PCI(hwif->chipset)) { sa = SA_SHIRQ; From ilya@theilya.com Tue Feb 10 17:18:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2004 17:18:40 +0000 (GMT) Received: from [IPv6:::ffff:66.151.148.199] ([IPv6:::ffff:66.151.148.199]:54033 "EHLO eagle.qarbon.com") by linux-mips.org with ESMTP id <S8225365AbUBJRSj>; Tue, 10 Feb 2004 17:18:39 +0000 Received: (qmail 10131 invoked from network); 10 Feb 2004 17:18:28 -0000 Received: from unknown (HELO theilya.com) (ilya@192.168.2.42) by eagle.qarbon.com with SMTP; 10 Feb 2004 17:18:28 -0000 Message-ID: <4029125F.2040603@theilya.com> Date: Tue, 10 Feb 2004 09:18:23 -0800 From: "Ilya A. Volynets-Evenbakh" <ilya@theilya.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20040121 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Robin H. Johnson" <robbat2@gentoo.org> CC: linux-mips <linux-mips@linux-mips.org> Subject: Re: SGI O2 PANIC on mem=xxxM, and strange initrd behavior References: <20040210112137.GA9213@curie-int.orbis-terrarum.net> In-Reply-To: <20040210112137.GA9213@curie-int.orbis-terrarum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: <ilya@theilya.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@theilya.com Precedence: bulk X-list: linux-mips As it is now, you are limited to 256M of RAM. pass mem=256M, or die ;-) I am working now on fixing that, but hit a brick wall in few places. We'll see by the end of next week though. Also, pass console=ttyS0 to get serial output. As for death after starting init, you may be running into problem with R1[02]K, and your init just crashes in loop, or something like that. I get it from time to time. Ilya. Robin H. Johnson wrote: >Hi, > >I've recently picked up an SGI O2, 300mhz R12k, 512Mb RAM. >Playing with getting it working, using Ilya's minimal patches on top of >the LMO CVS HEAD, I noticed that it wasn't pulling up the correct amount >of RAM. I threw mem=512M onto the params, and found a kernel crash. > >Boots mostly fine: >http://www.orbis-terrarum.net/~robbat2/sgio2/kernel.boot >Crashes: >http://www.orbis-terrarum.net/~robbat2/sgio2/kernel.crash >Decoded: >http://www.orbis-terrarum.net/~robbat2/sgio2/decoded.panic >Kernel config: >http://www.orbis-terrarum.net/~robbat2/sgio2/kernel.config > >I've also got one weird problem where it never gets any further than the >init call to my busybox initrd. > >Output using an old debian netboot initrd (from debian-mips-2.4.19.img): >serial console detected. Disabling virtual terminals. init started: >BusyBox v0.60.3-pre (2002.01.22-06:31+0000) multi-call binary > >Output for using bleeding-edge Gentoo initrd that works perfectly for >an Indy and an I2: >init started: BusyBox v1.00-pre7 (2004.02.10-08:42+0000) multi-call binary > >In both cases, right after the init message, absolutely nothing happens. >I've tried putting commands in the linuxrc that would cause some >externally visible activity, but nothing. > >I am wondering if it may have to with the virtual consoles (which I had >to turn off to get any serial output), but I doubt they are the problem. > > > From lrichardson@extremenetworks.com Wed Feb 11 22:51:14 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Feb 2004 22:51:15 +0000 (GMT) Received: from sc-f100-01.extremenetworks.com ([IPv6:::ffff:63.251.106.30]:5898 "EHLO extrgate1.extremenetworks.com") by linux-mips.org with ESMTP id <S8225265AbUBKWvO>; Wed, 11 Feb 2004 22:51:14 +0000 Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id <1V6VMAQ8>; Wed, 11 Feb 2004 14:50:42 -0800 Message-ID: <3DC3910A44FBD94B8513C8E2A3F220E1560A0B@sc-msexch-16.extremenetworks.com> From: Lance Richardson <lrichardson@extremenetworks.com> To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org> Subject: SB1250 Pass1 Cache Workaround Date: Wed, 11 Feb 2004 14:50:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Return-Path: <lrichardson@extremenetworks.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lrichardson@extremenetworks.com Precedence: bulk X-list: linux-mips A recent change to arch/mips/mm/cex-sb1.S dropped the workaround for the SB1250 pass 1 spurious cache exception problem (yes, some of us still have SWARMs with pass 1 parts...) Here's a patch to restore the workaround, tested/verified on a SWARM with pass1 SB1250. It also removes the #include <asm/processor.h> which (as pointed out recently) causes grief for the assembler. - Lance =================================================================== RCS file: /home/cvs/linux/arch/mips/mm/cex-sb1.S,v retrieving revision 1.13 diff -u -r1.13 cex-sb1.S --- cex-sb1.S 14 Jan 2004 18:46:21 -0000 1.13 +++ cex-sb1.S 10 Feb 2004 17:30:08 -0000 @@ -23,7 +23,6 @@ #include <asm/mipsregs.h> #include <asm/stackframe.h> #include <asm/cacheops.h> -#include <asm/processor.h> #include <asm/sibyte/board.h> #define C0_ERRCTL $26 /* CP0: Error info */ @@ -83,6 +82,19 @@ mtc0 $0,C0_CERR_D attempt_recovery: +#ifdef CONFIG_SB1_PASS_1_WORKAROUNDS + # look for signature of spurious CErr + lui k0, 0x4000 + bne k0, k1, 1f + mfc0 k1, C0_CERR_I, 1 + lui k0, 0xffe0 + and k1, k0, k1 + lui k0, 0x0200 + beq k0, k1, recovered + mtc0 $0,C0_CERR_D +1: +#endif + /* * k0 has C0_ERRCTL << 1, which puts 'DC' at bit 31. Any * Dcache errors we can recover from will take more extensive From jeff_lee@coventive.com Thu Feb 12 02:01:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 02:01:05 +0000 (GMT) Received: from 202-145-53-89.adsl.ttn.net ([IPv6:::ffff:202.145.53.89]:26834 "EHLO miao.coventive.com") by linux-mips.org with ESMTP id <S8225373AbUBLCBE>; Thu, 12 Feb 2004 02:01:04 +0000 Received: from pc193 (PC193.ia.kh.coventive.com [192.168.23.193] (may be forged)) by miao.coventive.com (8.11.6/8.11.6) with SMTP id i1C20s318063 for <linux-mips@linux-mips.org>; Thu, 12 Feb 2004 10:00:56 +0800 Message-ID: <01df01c3f10c$ec579450$c117a8c0@pc193> From: "jeff_lee" <jeff_lee@coventive.com> To: <linux-mips@linux-mips.org> References: <3DC3910A44FBD94B8513C8E2A3F220E1560A0B@sc-msexch-16.extremenetworks.com> Subject: About XFS file system Date: Thu, 12 Feb 2004 10:07:03 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Return-Path: <jeff_lee@coventive.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jeff_lee@coventive.com Precedence: bulk X-list: linux-mips Dear MIPS members, Does anyone try XFS file system on MIPS(VR serier) platform? Thanks and best regards, Jeff From brederlo@informatik.uni-tuebingen.de Thu Feb 12 04:22:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 04:22:28 +0000 (GMT) Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:27042 "EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP id <S8224850AbUBLEW2>; Thu, 12 Feb 2004 04:22:28 +0000 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E2D2C148; Thu, 12 Feb 2004 05:22:21 +0100 (NFT) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26612-01; Thu, 12 Feb 2004 05:22:20 +0100 (NFT) Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 19249146; Thu, 12 Feb 2004 05:22:19 +0100 (NFT) Received: from mrvn by dual with local (Exim 3.36 #1 (Debian)) id 1Ar6my-0002Bv-00; Thu, 12 Feb 2004 03:41:16 +0100 To: "jeff_lee" <jeff_lee@coventive.com> Cc: <linux-mips@linux-mips.org> Subject: Re: About XFS file system References: <3DC3910A44FBD94B8513C8E2A3F220E1560A0B@sc-msexch-16.extremenetworks.com> <01df01c3f10c$ec579450$c117a8c0@pc193> From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> Date: 12 Feb 2004 03:41:15 +0100 In-Reply-To: <01df01c3f10c$ec579450$c117a8c0@pc193> Message-ID: <87oes52f5g.fsf@mrvn.homelinux.org> Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Return-Path: <brederlo@informatik.uni-tuebingen.de> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brederlo@informatik.uni-tuebingen.de Precedence: bulk X-list: linux-mips "jeff_lee" <jeff_lee@coventive.com> writes: > Dear MIPS members, > Does anyone try XFS file system on MIPS(VR serier) platform? > > Thanks and best regards, > > Jeff xfs, xfs or xfs? MfG Goswin From knuffie@xs4all.nl Thu Feb 12 12:49:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 12:49:25 +0000 (GMT) Received: from smtp-out6.xs4all.nl ([IPv6:::ffff:194.109.24.7]:33796 "EHLO smtp-out6.xs4all.nl") by linux-mips.org with ESMTP id <S8225219AbUBLMtV>; Thu, 12 Feb 2004 12:49:21 +0000 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtp-out6.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1CCm6iV055648; Thu, 12 Feb 2004 13:48:06 +0100 (CET) Message-Id: <4.3.2.7.2.20040212134541.02e55be0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Feb 2004 13:48:04 +0100 To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>, "jeff_lee" <jeff_lee@coventive.com> From: Seth Mos <knuffie@xs4all.nl> Subject: Re: About XFS file system Cc: <linux-mips@linux-mips.org> In-Reply-To: <87oes52f5g.fsf@mrvn.homelinux.org> References: <01df01c3f10c$ec579450$c117a8c0@pc193> <3DC3910A44FBD94B8513C8E2A3F220E1560A0B@sc-msexch-16.extremenetworks.com> <01df01c3f10c$ec579450$c117a8c0@pc193> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-Path: <knuffie@xs4all.nl> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-mips At 03:41 12-2-2004 +0100, Goswin von Brederlow wrote: >"jeff_lee" <jeff_lee@coventive.com> writes: > > > Dear MIPS members, > > Does anyone try XFS file system on MIPS(VR serier) platform? > > > > Thanks and best regards, > > > > Jeff > >xfs, xfs or xfs? The filesystem not the font server. Should work, but lack of hardware prevents me from testing it. Sparc, PPC, itanium and intel and x86-64 work. Pa-risc I don't know. I believe there are still some alpha boxes running somewhere. If you have problems you can ask for XFS related questions on linux-xfs@oss.sgi.com Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From Manling.Ren@gbr.xerox.com Thu Feb 12 13:46:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 13:55:44 +0000 (GMT) Received: from [IPv6:::ffff:13.16.138.21] ([IPv6:::ffff:13.16.138.21]:25291 "EHLO apollo.eurgw.xerox.com") by linux-mips.org with ESMTP id <S8225248AbUBLNqJ>; Thu, 12 Feb 2004 13:46:09 +0000 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by apollo.eurgw.xerox.com (8.12.9-20030917/8.12.9) with ESMTP id i1CDk2rv020020 for <linux-mips@linux-mips.org>; Thu, 12 Feb 2004 13:46:02 GMT Received: from eurdubmg02.eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns4.eur.xerox.com (8.12.9/8.12.8) with ESMTP id i1CDk1ju029992 for <linux-mips@linux-mips.org>; Thu, 12 Feb 2004 13:46:01 GMT Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by eurdubmg02.eur.xerox.com (Content Technologies SMTPRS 4.2.10) with ESMTP id <T67b662ce820dca41fed0c@eurdubmg02.eur.xerox.com> for <linux-mips@linux-mips.org>; Thu, 12 Feb 2004 13:46:00 +0000 Received: from gbrwgcbh01.wgc.gbr.xerox.com ([13.200.2.175]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DY4KR9GD; Thu, 12 Feb 2004 13:45:59 -0000 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2657.72) id <V8CZZGBQ>; Thu, 12 Feb 2004 13:47:31 -0000 Message-ID: <8EAC52A94CD8D411A01000805FBB377606563AE8@gbrwgcms02.wgc.gbr.xerox.com> From: "Ren, Manling" <Manling.Ren@gbr.xerox.com> To: linux-mips@linux-mips.org Subject: RE: questions about making a script file for YAMON command Date: Thu, 12 Feb 2004 13:45:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F16E.77AE7788" Return-Path: <Manling.Ren@gbr.xerox.com> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4336 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: Manling.Ren@gbr.xerox.com Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F16E.77AE7788 Content-Type: text/plain Dear the technical support team, I am running YAMON on pb1100 board in Linux. At the YAMON prompt, I need to change some registers by using the command "edit -32 0x########" several times. I wonder if I can put all these "edit" commands into a script file then run this file without typing any more commands? How can I achieve this if it is possible. It seems that the "load" command in YAMON is only supported srec file. Could you give me some clues please. Thanks a lot. Regards, Manling ____________________________ Manling Ren :-)* ******* ***** Welwyn OPDU Software Architecture Team OPDU Xerox Limited Technical Centre DP2 Bessemer Road Welwyn Garden City AL7 1HE Hertfordshire UK % +44 (0)1707 35 2704 * 8 668 2704 (xerox intranet) * +44 (0)1707 35 3947 * Manling.Ren@gbr.xerox.com _________________________________ ------_=_NextPart_001_01C3F16E.77AE7788 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII"> <TITLE>Message

 
Dear the technical support team,
 
I am running YAMON on pb1100 board in Linux.  At the YAMON prompt, I need to change some registers by using the command "edit -32 0x########"  several times.  I wonder if I can put all these "edit" commands into a script file then run this file without typing any more commands?  How can I achieve this if it is possible.  It seems that the "load" command in YAMON is only supported srec file.  Could you give me some clues please.  Thanks a lot.
 
Regards,
Manling
 

____________________________
Manling Ren  J                              

Welwyn OPDU Software Architecture Team
OPDU                   
Xerox Limited Technical Centre
DP2        
Bessemer Road              
Welwyn Garden City  AL7 1HE        
Hertfordshire              
UK                         
%    +44 (0)1707 35 2704                 
(     8 668 2704 (xerox intranet)        
4     +44 (0)1707 35 3947        
*    Manling.Ren@gbr.xerox.com 
_________________________________          


 


 
------_=_NextPart_001_01C3F16E.77AE7788-- From jbglaw@dvmwest.gt.owl.de Thu Feb 12 14:08:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 14:08:26 +0000 (GMT) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:58842 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 14:08:22 +0000 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 90D384B520; Thu, 12 Feb 2004 15:08:21 +0100 (CET) Date: Thu, 12 Feb 2004 15:08:21 +0100 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: questions about making a script file for YAMON command Message-ID: <20040212140821.GT2725@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <8EAC52A94CD8D411A01000805FBB377606563AE8@gbrwgcms02.wgc.gbr.xerox.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rPH0Y77Oimr1cvNq" Content-Disposition: inline In-Reply-To: <8EAC52A94CD8D411A01000805FBB377606563AE8@gbrwgcms02.wgc.gbr.xerox.com> 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.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4337 X-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 --rPH0Y77Oimr1cvNq Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2004-02-12 13:45:25 -0000, Ren, Manling wrote in message <8EAC52A94CD8D411A01000805FBB377606563AE8@gbrwgcms02.wgc.g= br.xerox.com>: > Dear the technical support team, No technical support team here, just a number of hackers... > I am running YAMON on pb1100 board in Linux. At the YAMON prompt, I need= to > change some registers by using the command "edit -32 0x########" several > times. I wonder if I can put all these "edit" commands into a script file Personally, I don't know yamon since nobody offered a board using it to me, but if it uses serial console, just prepare a text file containing all the lines you need to type. Then, cut'n'paste the commands to minicom or whatever you use... 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)); --rPH0Y77Oimr1cvNq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAK4jVHb1edYOZ4bsRAiI1AJ9trM24mZhWymnAxa2BgmQ5KOAJPgCeN7SN QXjCJjbKH4PMC33EGYX1cU8= =hYUs -----END PGP SIGNATURE----- --rPH0Y77Oimr1cvNq-- From wd@denx.de Thu Feb 12 14:20:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 14:20:30 +0000 (GMT) Received: from mailout01.sul.t-online.com ([IPv6:::ffff:194.25.134.80]:37046 "EHLO mailout01.sul.t-online.com") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 14:20:30 +0000 Received: from fwd08.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1ArHhY-00084V-00; Thu, 12 Feb 2004 15:20:24 +0100 Received: from denx.de (GiZ2x+ZUreEESq8kJlOhTf8lLCS2qYGw+rJQSuZm5HAOeUdWqGC1w0@[217.235.251.238]) by fmrl08.sul.t-online.com with esmtp id 1ArHhK-10lY8W0; Thu, 12 Feb 2004 15:20:10 +0100 Received: from atlas.denx.de (atlas.denx.de [10.0.0.14]) by denx.de (Postfix) with ESMTP id 8384242B98; Thu, 12 Feb 2004 15:20:08 +0100 (MET) Received: by atlas.denx.de (Postfix, from userid 15) id B7FDBC108D; Thu, 12 Feb 2004 15:20:07 +0100 (MET) Received: from atlas.denx.de (localhost [127.0.0.1]) by atlas.denx.de (Postfix) with ESMTP id B4DA713D425; Thu, 12 Feb 2004 15:20:07 +0100 (MET) To: "Ren, Manling" Cc: linux-mips@linux-mips.org From: Wolfgang Denk Subject: Re: questions about making a script file for YAMON command 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 "Thu, 12 Feb 2004 13:45:25 GMT." <8EAC52A94CD8D411A01000805FBB377606563AE8@gbrwgcms02.wgc.gbr.xerox.com> Date: Thu, 12 Feb 2004 15:20:02 +0100 Message-Id: <20040212142007.B7FDBC108D@atlas.denx.de> X-Seen: false X-ID: GiZ2x+ZUreEESq8kJlOhTf8lLCS2qYGw+rJQSuZm5HAOeUdWqGC1w0@t-dialin.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4338 X-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 <8EAC52A94CD8D411A01000805FBB377606563AE8@gbrwgcms02.wgc.gbr.xerox.com> you wrote: > > Dear the technical support team, Did you pay a support contract? ;-) > I am running YAMON on pb1100 board in Linux. At the YAMON prompt, I need to > change some registers by using the command "edit -32 0x########" several > times. I wonder if I can put all these "edit" commands into a script file > then run this file without typing any more commands? How can I achieve this Use the standard tools you can find in your Unix environment. In this case, use expect. Best regards, Wolfgang Denk -- See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440 Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de "No matter where you go, there you are..." - Buckaroo Banzai From brederlo@informatik.uni-tuebingen.de Thu Feb 12 14:32:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 14:32:57 +0000 (GMT) Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:11432 "EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 14:32:57 +0000 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E4467144; Thu, 12 Feb 2004 15:32:48 +0100 (NFT) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 51948-04; Thu, 12 Feb 2004 15:32:47 +0100 (NFT) Received: from dual (semeai [134.2.15.66]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 69B7D134; Thu, 12 Feb 2004 15:32:46 +0100 (NFT) Received: from mrvn by dual with local (Exim 3.36 #1 (Debian)) id 1ArHtV-0003tA-00; Thu, 12 Feb 2004 15:32:45 +0100 To: Seth Mos Cc: Goswin von Brederlow , "jeff_lee" , Subject: Re: About XFS file system References: <01df01c3f10c$ec579450$c117a8c0@pc193> <3DC3910A44FBD94B8513C8E2A3F220E1560A0B@sc-msexch-16.extremenetworks.com> <01df01c3f10c$ec579450$c117a8c0@pc193> <4.3.2.7.2.20040212134541.02e55be0@pop.xs4all.nl> From: Goswin von Brederlow Date: 12 Feb 2004 15:32:45 +0100 In-Reply-To: <4.3.2.7.2.20040212134541.02e55be0@pop.xs4all.nl> Message-ID: <87u11wz7ua.fsf@mrvn.homelinux.org> Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.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: 4339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brederlo@informatik.uni-tuebingen.de Precedence: bulk X-list: linux-mips Seth Mos writes: > At 03:41 12-2-2004 +0100, Goswin von Brederlow wrote: > >"jeff_lee" writes: > > > > > Dear MIPS members, > > > Does anyone try XFS file system on MIPS(VR serier) platform? > > > > > > Thanks and best regards, > > > > > > Jeff > > > >xfs, xfs or xfs? > > The filesystem not the font server. Should work, but lack of hardware > prevents me from testing it. There is the journaling filesystem, the userspace filesystem (used by arla) and another one also called xfs. I guess you mean the kernel included one though. Nope, sorry, havent. > Sparc, PPC, itanium and intel and x86-64 work. Pa-risc I don't know. I > believe there are still some alpha boxes running somewhere. > > > If you have problems you can ask for XFS related questions on > linux-xfs@oss.sgi.com MfG Goswin From yuasa@hh.iij4u.or.jp Thu Feb 12 14:55:43 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 14:55:43 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:35547 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 14:55:43 +0000 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id XAA03624; Thu, 12 Feb 2004 23:55:00 +0900 (JST) Received: 4UMDO01 id i1CEsxV09291; Thu, 12 Feb 2004 23:54:59 +0900 (JST) Received: 4UMRO01 id i1CEss515101; Thu, 12 Feb 2004 23:54:54 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 12 Feb 2004 23:54:52 +0900 From: Yoichi Yuasa To: Goswin von Brederlow Cc: yuasa@hh.iij4u.or.jp, knuffie@xs4all.nl, brederlo@informatik.uni-tuebingen.de, jeff_lee@coventive.com, linux-mips@linux-mips.org Subject: Re: About XFS file system Message-Id: <20040212235452.43a0a5f9.yuasa@hh.iij4u.or.jp> In-Reply-To: <87u11wz7ua.fsf@mrvn.homelinux.org> References: <01df01c3f10c$ec579450$c117a8c0@pc193> <3DC3910A44FBD94B8513C8E2A3F220E1560A0B@sc-msexch-16.extremenetworks.com> <01df01c3f10c$ec579450$c117a8c0@pc193> <4.3.2.7.2.20040212134541.02e55be0@pop.xs4all.nl> <87u11wz7ua.fsf@mrvn.homelinux.org> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4340 X-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, On 12 Feb 2004 15:32:45 +0100 Goswin von Brederlow wrote: > Seth Mos writes: > > > At 03:41 12-2-2004 +0100, Goswin von Brederlow wrote: > > >"jeff_lee" writes: > > > > > > > Dear MIPS members, > > > > Does anyone try XFS file system on MIPS(VR serier) platform? > > > > > > > > Thanks and best regards, > > > > > > > > Jeff > > > > > >xfs, xfs or xfs? > > > > The filesystem not the font server. Should work, but lack of hardware > > prevents me from testing it. > > There is the journaling filesystem, the userspace filesystem (used by > arla) and another one also called xfs. > > I guess you mean the kernel included one though. > > Nope, sorry, havent. I have tested it today. It seems that it has a problem. I'll investigate details tomorrow. Yoichi From Joost@stack.nl Thu Feb 12 16:12:59 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 16:13:00 +0000 (GMT) Received: from brilsmurf.chem.tue.nl ([IPv6:::ffff:131.155.84.68]:10722 "EHLO brilsmurf.chem.tue.nl") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 16:12:59 +0000 Received: from brilsmurf.chem.tue.nl (localhost [127.0.0.1]) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CGCwvI022610 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 12 Feb 2004 17:12:59 +0100 Received: from localhost (joost@localhost) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CGCwSx006021 for ; Thu, 12 Feb 2004 17:12:58 +0100 X-Authentication-Warning: brilsmurf.chem.tue.nl: joost owned process doing -bs Date: Thu, 12 Feb 2004 17:12:58 +0100 (CET) From: Joost X-X-Sender: joost@brilsmurf.chem.tue.nl To: linux-mips@linux-mips.org Subject: indy r4000FPC kernel? Message-ID: ReplyTo: Joost@stack.nl User-Agent: 007 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: 4341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Joost@stack.nl Precedence: bulk X-list: linux-mips Hello, Is this the correct list to be asking about kernel trouble? If not, i apologize for this lengthy piece of offtopic ranting :-) I'm trying to get a working kernel on my indy, but 2.4.16 seems to be as far as it will go. The 2.4.22 that comes with debian testing gives an error while booting so i decided to try and be adventurous and downloaded the 2.6 sources via cvs. The PROM in this beast is old i gues, it won't boot elf kernels, so i used the 'ecoff' tip on linux-mips.com. Going from elf to ecoff gives out a warning: arch/mips/boot/elf2ecoff vmlinux vmlinux.ecoff wrote 20 byte file header. wrote 56 byte a.out header. wrote 120 bytes of section headers. wrote 12 byte pad. writing 3685492 bytes... Warning: 908 byte intersegment gap. writing 499845 bytes... Is this warning about the 'intersegment gap' something I can safely ignore? After booting this kernel it panics, complaining about 'unaligned instruction access in arch/mips/kernel/unaligned.c::do_ade, line 544[#1]: cpu 0' followd by lots of yukkie numbers and a call trace: [<883e558c>] mem_init+0x6c/0x1e4 [<883ef580>] start_kernel+0x114/0x238 [<883ef588>] start_kernel+0x17c/0x238 [<883ef30c>] unknown_bootoption+0x0/0x130 [<883ef08c>] no_smp+0x0/0x10 Kernel Panic! Attempted to kill the idle task! Am I doing something obvious wrong? The compiler in use is gcc-2.95.4, the machine is an indy with r4000FPC. I'm doing a native compile (yes, my time is cheap :-). Thank you for your time! Joost. -- I have spent most of my money on women and beer. The rest I just wasted... From rathann@icm.edu.pl Thu Feb 12 16:42:18 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 16:42:18 +0000 (GMT) Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:8030 "EHLO atol.icm.edu.pl") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 16:42:18 +0000 Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132]) by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i1CGg5dL026629 for ; Thu, 12 Feb 2004 17:42:05 +0100 (CET) Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian)) id 1ArJuf-00021a-00 for ; Thu, 12 Feb 2004 17:42:05 +0100 Date: Thu, 12 Feb 2004 17:42:05 +0100 From: "Dominik 'Rathann' Mierzejewski" To: linux-mips@linux-mips.org Subject: Re: indy r4000FPC kernel? Message-ID: <20040212164204.GC7586@icm.edu.pl> Mail-Followup-To: linux-mips@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.3.28i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rathann@icm.edu.pl Precedence: bulk X-list: linux-mips On Thu, Feb 12, 2004 at 05:12:58PM +0100, Joost wrote: > Hello, > > Is this the correct list to be asking about kernel trouble? > If not, i apologize for this lengthy piece of offtopic ranting :-) > > I'm trying to get a working kernel on my indy, but 2.4.16 > seems to be as far as it will go. The 2.4.22 that comes with > debian testing gives an error while booting so i decided > to try and be adventurous and downloaded the 2.6 sources > via cvs. The PROM in this beast is old i gues, it won't > boot elf kernels, so i used the 'ecoff' tip on linux-mips.com. Get a current version (branch linux_2_4) from linux-mips.org's CVS and try that one. There have been some trouble with r4k processors lately, but they seem to be resolved now. I'm running 2.4.25-pre6 at the moment. Oh, and use arcboot - it saves a lot of hassle. You don't have to upload your kernel to volume header and you can boot any ELF kernel image that is on any ext2/3 partition on your system. HTH -- Dominik 'Rathann' Mierzejewski Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810 From Joost@stack.nl Thu Feb 12 17:03:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 17:03:39 +0000 (GMT) Received: from brilsmurf.chem.tue.nl ([IPv6:::ffff:131.155.84.68]:45794 "EHLO brilsmurf.chem.tue.nl") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 17:03:39 +0000 Received: from brilsmurf.chem.tue.nl (localhost [127.0.0.1]) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CH3ZvI013836 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 12 Feb 2004 18:03:35 +0100 Received: from localhost (joost@localhost) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CH3ZIR005123 for ; Thu, 12 Feb 2004 18:03:35 +0100 X-Authentication-Warning: brilsmurf.chem.tue.nl: joost owned process doing -bs Date: Thu, 12 Feb 2004 18:03:35 +0100 (CET) From: Joost X-X-Sender: joost@brilsmurf.chem.tue.nl To: linux-mips@linux-mips.org Subject: Re: indy r4000FPC kernel? In-Reply-To: <20040212164204.GC7586@icm.edu.pl> Message-ID: References: <20040212164204.GC7586@icm.edu.pl> ReplyTo: Joost@stack.nl User-Agent: 007 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: 4343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Joost@stack.nl Precedence: bulk X-list: linux-mips On Thu, 12 Feb 2004, Dominik 'Rathann' Mierzejewski wrote: > Get a current version (branch linux_2_4) from linux-mips.org's CVS > and try that one. There have been some trouble with r4k processors > lately, but they seem to be resolved now. I'm running 2.4.25-pre6 > at the moment. Oh, and use arcboot - it saves a lot of hassle. > You don't have to upload your kernel to volume header and you can > boot any ELF kernel image that is on any ext2/3 partition on your > system. Thank you! I will give it a try right now, should be finished by dawn :-) Joost. -- When I was a child I could remember anything... Whether it happened or not. -- Mark Twain From brederlo@informatik.uni-tuebingen.de Thu Feb 12 17:21:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 17:21:56 +0000 (GMT) Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:64425 "EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 17:21:56 +0000 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id CF98D144; Thu, 12 Feb 2004 18:21:49 +0100 (NFT) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 51726-01; Thu, 12 Feb 2004 18:21:48 +0100 (NFT) Received: from dual (semeai [134.2.15.66]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4EE23134; Thu, 12 Feb 2004 18:21:47 +0100 (NFT) Received: from mrvn by dual with local (Exim 3.36 #1 (Debian)) id 1ArKX5-0004Lb-00; Thu, 12 Feb 2004 18:21:47 +0100 To: Wolfgang Denk Cc: "Ren, Manling" , linux-mips@linux-mips.org Subject: Re: questions about making a script file for YAMON command References: <20040212142007.B7FDBC108D@atlas.denx.de> From: Goswin von Brederlow Date: 12 Feb 2004 18:21:45 +0100 In-Reply-To: <20040212142007.B7FDBC108D@atlas.denx.de> Message-ID: <87znboxlg6.fsf@mrvn.homelinux.org> Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.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: 4344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brederlo@informatik.uni-tuebingen.de Precedence: bulk X-list: linux-mips Wolfgang Denk writes: > In message <8EAC52A94CD8D411A01000805FBB377606563AE8@gbrwgcms02.wgc.gbr.xerox.com> you wrote: > > > > Dear the technical support team, > > Did you pay a support contract? ;-) > > > I am running YAMON on pb1100 board in Linux. At the YAMON prompt, I need to > > change some registers by using the command "edit -32 0x########" several > > times. I wonder if I can put all these "edit" commands into a script file > > then run this file without typing any more commands? How can I achieve this > > Use the standard tools you can find in your Unix environment. In this > case, use expect. > > Best regards, > > Wolfgang Denk Or rebuild yamon to your likeing. MfG Goswin From agx@sigxcpu.org Thu Feb 12 17:51:18 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 17:51:19 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:17644 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 17:51:18 +0000 Received: from localhost (localhost [127.0.0.1]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 39DBE2BC3E; Thu, 12 Feb 2004 18:51:17 +0100 (CET) Received: from honk1.physik.uni-konstanz.de ([127.0.0.1]) by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 08132-38; Thu, 12 Feb 2004 18:50:54 +0100 (CET) Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id AF34C2BC39; Thu, 12 Feb 2004 18:50:54 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 1B9584341; Thu, 12 Feb 2004 18:48:22 +0100 (CET) Date: Thu, 12 Feb 2004 18:48:22 +0100 From: Guido Guenther To: Joost Cc: linux-mips@linux-mips.org Subject: Re: indy r4000FPC kernel? Message-ID: <20040212174822.GD1280@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , Joost , linux-mips@linux-mips.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W5WqUoFLvi1M7tJE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips --W5WqUoFLvi1M7tJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 12, 2004 at 05:12:58PM +0100, Joost wrote: > seems to be as far as it will go. The 2.4.22 that comes with > debian testing gives an error while booting so i decided What kind of error? -- Guido --W5WqUoFLvi1M7tJE 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) iD8DBQFAK7xln88szT8+ZCYRAhUOAKCA29NNoQMgjSKejz5PdTDholIcXgCePnyb TTJk/jVMaIJjz4hNpyS9JsU= =uBdo -----END PGP SIGNATURE----- --W5WqUoFLvi1M7tJE-- From Joost@stack.nl Thu Feb 12 18:46:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 18:46:37 +0000 (GMT) Received: from brilsmurf.chem.tue.nl ([IPv6:::ffff:131.155.84.68]:35811 "EHLO brilsmurf.chem.tue.nl") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 18:46:37 +0000 Received: from brilsmurf.chem.tue.nl (localhost [127.0.0.1]) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CIkavI019818 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 12 Feb 2004 19:46:36 +0100 Received: from localhost (joost@localhost) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CIka9Z007707 for ; Thu, 12 Feb 2004 19:46:36 +0100 X-Authentication-Warning: brilsmurf.chem.tue.nl: joost owned process doing -bs Date: Thu, 12 Feb 2004 19:46:36 +0100 (CET) From: Joost X-X-Sender: joost@brilsmurf.chem.tue.nl To: linux-mips@linux-mips.org Subject: Re: indy r4000FPC kernel? In-Reply-To: <20040212174822.GD1280@bogon.ms20.nix> Message-ID: References: <20040212174822.GD1280@bogon.ms20.nix> ReplyTo: Joost@stack.nl User-Agent: 007 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: 4346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Joost@stack.nl Precedence: bulk X-list: linux-mips On Thu, 12 Feb 2004, Guido Guenther wrote: > On Thu, Feb 12, 2004 at 05:12:58PM +0100, Joost wrote: > > seems to be as far as it will go. The 2.4.22 that comes with > > debian testing gives an error while booting so i decided > What kind of error? It might have been the "can't load elf" problem. I'm very new to all of this so at the time (yesterday :-) I didn't know a solution existed. If it's important to you I could check again tomorow? Joost. -- "I distrust camels, and anyone else who can go for a week without a drink." -- Joe E Lewis From agx@sigxcpu.org Thu Feb 12 20:13:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2004 20:13:40 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:60653 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 20:13:39 +0000 Received: from localhost (localhost [127.0.0.1]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 6AE432BC3E; Thu, 12 Feb 2004 21:13:38 +0100 (CET) Received: from honk1.physik.uni-konstanz.de ([127.0.0.1]) by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 10012-18; Thu, 12 Feb 2004 21:13:16 +0100 (CET) Received: from bogon.sigxcpu.org (pD9EB8C9C.dip0.t-ipconnect.de [217.235.140.156]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id EEE2F2BC39; Thu, 12 Feb 2004 21:13:15 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id E29A14341; Thu, 12 Feb 2004 21:10:20 +0100 (CET) Date: Thu, 12 Feb 2004 21:10:20 +0100 From: Guido Guenther To: Joost Cc: linux-mips@linux-mips.org Subject: Re: indy r4000FPC kernel? Message-ID: <20040212201020.GA942@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , Joost , linux-mips@linux-mips.org References: <20040212174822.GD1280@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 12, 2004 at 07:46:36PM +0100, Joost wrote: > On Thu, 12 Feb 2004, Guido Guenther wrote: > > On Thu, Feb 12, 2004 at 05:12:58PM +0100, Joost wrote: > > > seems to be as far as it will go. The 2.4.22 that comes with > > > debian testing gives an error while booting so i decided > > What kind of error? > It might have been the "can't load elf" problem. I'm very new > to all of this so at the time (yesterday :-) I didn't know a > solution existed. If it's important to you I could check again > tomorow? Yes please do. Thanks. -- Guido --2fHTh5uZTiUOsy+g 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) iD8DBQFAK92sn88szT8+ZCYRAg3BAJ4tYGopwl1o7QtM5QytqKURr696KACcCqEm 1sx0dW2WQsTr4iSXexFvAdA= =nMek -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From Joost@stack.nl Fri Feb 13 08:37:01 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 08:37:02 +0000 (GMT) Received: from brilsmurf.chem.tue.nl ([IPv6:::ffff:131.155.84.68]:21480 "EHLO brilsmurf.chem.tue.nl") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 08:37:01 +0000 Received: from brilsmurf.chem.tue.nl (localhost [127.0.0.1]) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1D8b0vI017075 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 13 Feb 2004 09:37:01 +0100 Received: from localhost (joost@localhost) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1D8b0Ku019041 for ; Fri, 13 Feb 2004 09:37:00 +0100 X-Authentication-Warning: brilsmurf.chem.tue.nl: joost owned process doing -bs Date: Fri, 13 Feb 2004 09:37:00 +0100 (CET) From: Joost X-X-Sender: joost@brilsmurf.chem.tue.nl To: linux-mips@linux-mips.org Subject: Re: indy r4000FPC kernel? In-Reply-To: <20040212201020.GA942@bogon.ms20.nix> Message-ID: References: <20040212174822.GD1280@bogon.ms20.nix> <20040212201020.GA942@bogon.ms20.nix> ReplyTo: Joost@stack.nl User-Agent: 007 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: 4348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Joost@stack.nl Precedence: bulk X-list: linux-mips On Thu, 12 Feb 2004, Guido Guenther wrote: > On Thu, Feb 12, 2004 at 07:46:36PM +0100, Joost wrote: > > On Thu, 12 Feb 2004, Guido Guenther wrote: > > > On Thu, Feb 12, 2004 at 05:12:58PM +0100, Joost wrote: > > > > seems to be as far as it will go. The 2.4.22 that comes with > > > > debian testing gives an error while booting so i decided > > > What kind of error? > > It might have been the "can't load elf" problem. I'm very new > > to all of this so at the time (yesterday :-) I didn't know a > > solution existed. If it's important to you I could check again > > tomorow? > Yes please do. Thanks. After running elf2ecoff on it, the kernel from debian testing (kernel-image-2.4.22-r4k-ip22) seems to run just fine. The linux_2_4 cvs that compiled this night also works ok. Many thanks for all your help! Joost. -- "Love is the delusion that one woman differs from another." -- HL Mencken From chrisb@mips.com Thu Feb 12 15:17:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 12:14:33 +0000 (GMT) Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:24768 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 12 Feb 2004 15:17:05 +0000 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.11/8.12.11) with ESMTP id i1CEcxhd023647; Thu, 12 Feb 2004 06:38:59 -0800 (PST) Received: from xchange.mips.com (xchange [192.168.20.31]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA04359; Thu, 12 Feb 2004 06:46:44 -0800 (PST) Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Feb 2004 06:41:02 -0800 Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A03B84D84@xchange.mips.com> From: "Berg, Christian" To: "Ren, Manling" Cc: linux-mips@linux-mips.org Subject: RE: questions about making a script file for YAMON command Date: Thu, 12 Feb 2004 06:40:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F176.378C1C70" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4349 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: chrisb@mips.com Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F176.378C1C70 Content-Type: text/plain Hi Manling, there is a variable called START in the YAMON environment. The contents of which is executed at YAMON start-up. So if you can fit your 'edit' commands in the space provided you're good to go. See page 22 of the YAMON user manual (http://www.mips.com/content/Documentation/MIPSDocumentation/Software/doclib rary ). But this is getting off topic now... Chris -----Original Message----- From: Ren, Manling [mailto:Manling.Ren@gbr.xerox.com] Sent: Thursday, February 12, 2004 2:45 PM To: linux-mips@linux-mips.org Subject: RE: questions about making a script file for YAMON command Dear the technical support team, I am running YAMON on pb1100 board in Linux. At the YAMON prompt, I need to change some registers by using the command "edit -32 0x########" several times. I wonder if I can put all these "edit" commands into a script file then run this file without typing any more commands? How can I achieve this if it is possible. It seems that the "load" command in YAMON is only supported srec file. Could you give me some clues please. Thanks a lot. Regards, Manling ____________________________ Manling Ren :-)* ******* ***** Welwyn OPDU Software Architecture Team OPDU Xerox Limited Technical Centre DP2 Bessemer Road Welwyn Garden City AL7 1HE Hertfordshire UK % +44 (0)1707 35 2704 * 8 668 2704 (xerox intranet) * +44 (0)1707 35 3947 * Manling.Ren@gbr.xerox.com _________________________________ ------_=_NextPart_001_01C3F176.378C1C70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Hi=20 Manling,
 
there=20 is a variable called START in the YAMON environment. The contents of=20 which is executed at YAMON start-up. So if you can fit your 'edit' = commands=20 in the space provided you're good to go. See page 22 of the YAMON = user=20 manual (http://www.mips.com/content/Documentation/MIPSDocumenta= tion/Software/doclibrary).=20 But this is getting off topic now...
 
Chris
-----Original Message-----
From: = Ren, Manling=20 [mailto:Manling.Ren@gbr.xerox.com]
Sent: Thursday, = February 12,=20 2004 2:45 PM
To: = linux-mips@linux-mips.org
Subject: RE:=20 questions about making a script file for YAMON = command


 
Dear the technical support=20 team,
 
I am running YAMON on pb1100 board in=20 Linux.  At the YAMON prompt, I need to change some = registers=20 by using the command "edit -32 0x########"  several = times.  I=20 wonder if I can put all these "edit" commands into a script = file then=20 run this file without typing any more commands?  How can I = achieve this=20 if it is possible.  It seems that the "load" command in YAMON = is only=20 supported srec file.  Could you give me some clues = please.  Thanks=20 a lot.
 
Regards,
Manling
 

____________________________
Manling = Ren =20 J  =         =      =20      =20         

Welwyn OPDU Software Architecture Team
OPDU     =20         =      =20
Xerox = Limited Technical=20 Centre
DP2         =
Bessemer Road  =20             =
Welwyn Garden City  AL7=20 1HE        
Hertfordshire  =20             =
UK     =20       =        =20      
%    +44 (0)1707 35 = 2704       =20          
(     8 668 2704 (xerox = intranet)         =
4     +44 (0)1707 35=20 3947        
*   =20 Manling.Ren@gbr.xerox.com 
_________________________________=20          =20


 


 
------_=_NextPart_001_01C3F176.378C1C70-- From macro@ds2.pg.gda.pl Fri Feb 13 14:20:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 14:20:37 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:8861 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 14:20:36 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 51D214C3C1; Fri, 13 Feb 2004 15:20:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 3C0BE4AD2E; Fri, 13 Feb 2004 15:20:27 +0100 (CET) Date: Fri, 13 Feb 2004 15:20:27 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle , linux-mips@linux-mips.org Subject: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Hello, Here's another set of changes needed for the kernel to work when built with gcc 3.4. The compiler is pretty serious about removing code and data it considers dead. While earlier versions would only warn about such dead bits, the current one actually throws them away. Here's my proposed fix for the problem: 1. It changes the "unused" attribute to the "used" one for compiler versions that support it, to actually mark the bits as needed, instead of masking warnings. 2. It changes inline-assembly function prologues to be embedded within the functions, which makes them a bit safer as they can now explicitly refer to the "regs" struct and assures the code won't be removed or reordered. It was successfully tested with gcc 3.4 and 2.95.4, including inspecting the generated code. I'd like to apply the MIPS-specific part, i.e. for bits under arch/mips* and include/asm-mips* to our tree (both 2.4 and the trunk). OK? The rest is to be accepted by Marcelo -- although functionally consistent, the changes do not depend on each other, but I decided to publish them here for people's convenience (this part went to the LKML yesterday). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.24-pre2-20040116-gcc3-6 diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/signal.c linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/signal.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/signal.c 2003-07-25 02:56:34.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/signal.c 2004-02-13 05:43:50.000000000 +0000 @@ -75,10 +75,10 @@ int copy_siginfo_to_user(siginfo_t *to, /* * Atomically swap in the new signal mask, and wait for a signal. */ -save_static_function(sys_sigsuspend); -static_unused int _sys_sigsuspend(struct pt_regs regs) +int sys_sigsuspend(struct pt_regs regs) { sigset_t *uset, saveset, newset; + save_static(®s); uset = (sigset_t *) regs.regs[4]; if (copy_from_user(&newset, uset, sizeof(sigset_t))) @@ -101,11 +101,11 @@ static_unused int _sys_sigsuspend(struct } } -save_static_function(sys_rt_sigsuspend); -static_unused int _sys_rt_sigsuspend(struct pt_regs regs) +int sys_rt_sigsuspend(struct pt_regs regs) { sigset_t *unewset, saveset, newset; size_t sigsetsize; + save_static(®s); /* XXX Don't preclude handling different sized sigset_t's. */ sigsetsize = regs.regs[5]; diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/syscall.c linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/syscall.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/syscall.c 2003-04-01 02:56:50.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/syscall.c 2004-02-13 05:44:04.000000000 +0000 @@ -157,22 +157,22 @@ sys_mmap2(unsigned long addr, unsigned l return do_mmap2(addr, len, prot, flags, fd, pgoff); } -save_static_function(sys_fork); -static_unused int _sys_fork(struct pt_regs regs) +int sys_fork(struct pt_regs regs) { int res; + save_static(®s); res = do_fork(SIGCHLD, regs.regs[29], ®s, 0); return res; } -save_static_function(sys_clone); -static_unused int _sys_clone(struct pt_regs regs) +int sys_clone(struct pt_regs regs) { unsigned long clone_flags; unsigned long newsp; int res; + save_static(®s); clone_flags = regs.regs[4]; newsp = regs.regs[5]; diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/signal.c linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/signal.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/signal.c 2004-01-04 03:56:41.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/signal.c 2004-02-13 05:44:14.000000000 +0000 @@ -74,11 +74,11 @@ int copy_siginfo_to_user(siginfo_t *to, /* * Atomically swap in the new signal mask, and wait for a signal. */ -save_static_function(sys_rt_sigsuspend); -static_unused int _sys_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs) +int sys_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs) { sigset_t *unewset, saveset, newset; size_t sigsetsize; + save_static(®s); /* XXX Don't preclude handling different sized sigset_t's. */ sigsetsize = regs.regs[5]; diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/signal32.c linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/signal32.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/signal32.c 2004-01-04 03:56:41.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/signal32.c 2004-02-13 05:44:26.000000000 +0000 @@ -126,11 +126,11 @@ static inline int get_sigset(sigset_t *k /* * Atomically swap in the new signal mask, and wait for a signal. */ -save_static_function(sys32_sigsuspend); -static_unused int _sys32_sigsuspend(abi64_no_regargs, struct pt_regs regs) +int sys32_sigsuspend(abi64_no_regargs, struct pt_regs regs) { sigset32_t *uset; sigset_t newset, saveset; + save_static(®s); uset = (sigset32_t *) regs.regs[4]; if (get_sigset(&newset, uset)) @@ -153,12 +153,12 @@ static_unused int _sys32_sigsuspend(abi6 } } -save_static_function(sys32_rt_sigsuspend); -static_unused int _sys32_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs) +int sys32_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs) { sigset32_t *uset; sigset_t newset, saveset; size_t sigsetsize; + save_static(®s); /* XXX Don't preclude handling different sized sigset_t's. */ sigsetsize = regs.regs[5]; diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/syscall.c linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/syscall.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/syscall.c 2004-01-04 03:56:41.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/syscall.c 2004-02-13 05:44:36.000000000 +0000 @@ -147,21 +147,21 @@ out: return error; } -save_static_function(sys_fork); -static_unused int _sys_fork(abi64_no_regargs, struct pt_regs regs) +int sys_fork(abi64_no_regargs, struct pt_regs regs) { int res; + save_static(®s); res = do_fork(SIGCHLD, regs.regs[29], ®s, 0); return res; } -save_static_function(sys_clone); -static_unused int _sys_clone(abi64_no_regargs, struct pt_regs regs) +int sys_clone(abi64_no_regargs, struct pt_regs regs) { unsigned long clone_flags; unsigned long newsp; int res; + save_static(®s); clone_flags = regs.regs[4]; newsp = regs.regs[5]; diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/ptrace.h linux-mips-2.4.24-pre2-20040116/include/asm-mips/ptrace.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/ptrace.h 2004-02-09 04:30:14.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips/ptrace.h 2004-02-13 06:19:23.000000000 +0000 @@ -44,31 +44,26 @@ struct pt_regs { unsigned long cp0_epc; }; -#define __str2(x) #x -#define __str(x) __str2(x) - -#define save_static_function(symbol) \ -__asm__ ( \ - ".globl\t" #symbol "\n\t" \ - ".align\t2\n\t" \ - ".type\t" #symbol ", @function\n\t" \ - ".ent\t" #symbol ", 0\n" \ - #symbol":\n\t" \ - ".frame\t$29, 0, $31\n\t" \ - "sw\t$16,"__str(PT_R16)"($29)\t\t\t# save_static_function\n\t" \ - "sw\t$17,"__str(PT_R17)"($29)\n\t" \ - "sw\t$18,"__str(PT_R18)"($29)\n\t" \ - "sw\t$19,"__str(PT_R19)"($29)\n\t" \ - "sw\t$20,"__str(PT_R20)"($29)\n\t" \ - "sw\t$21,"__str(PT_R21)"($29)\n\t" \ - "sw\t$22,"__str(PT_R22)"($29)\n\t" \ - "sw\t$23,"__str(PT_R23)"($29)\n\t" \ - "sw\t$30,"__str(PT_R30)"($29)\n\t" \ - ".end\t" #symbol "\n\t" \ - ".size\t" #symbol",. - " #symbol) - -/* Used in declaration of save_static functions. */ -#define static_unused static __attribute__((unused)) +#define save_static(r) \ +__asm__ __volatile__( \ + "sw $16,%0 # save_static\n\t" \ + "sw $17,%1\n\t" \ + "sw $18,%2\n\t" \ + "sw $19,%3\n\t" \ + "sw $20,%4\n\t" \ + "sw $21,%5\n\t" \ + "sw $22,%6\n\t" \ + "sw $23,%7\n\t" \ + "sw $30,%8" \ + : "=m" ((r)->regs[16]), \ + "=m" ((r)->regs[17]), \ + "=m" ((r)->regs[18]), \ + "=m" ((r)->regs[19]), \ + "=m" ((r)->regs[20]), \ + "=m" ((r)->regs[21]), \ + "=m" ((r)->regs[22]), \ + "=m" ((r)->regs[23]), \ + "=m" ((r)->regs[30])) #endif /* !__ASSEMBLY__ */ diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/ptrace.h linux-mips-2.4.24-pre2-20040116/include/asm-mips64/ptrace.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/ptrace.h 2004-01-26 03:35:56.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips64/ptrace.h 2004-02-13 06:19:42.000000000 +0000 @@ -41,31 +41,26 @@ struct pt_regs { unsigned long cp0_epc; }; -#define __str2(x) #x -#define __str(x) __str2(x) - -#define save_static_function(symbol) \ -__asm__ ( \ - ".globl\t" #symbol "\n\t" \ - ".align\t2\n\t" \ - ".type\t" #symbol ", @function\n\t" \ - ".ent\t" #symbol ", 0\n" \ - #symbol":\n\t" \ - ".frame\t$29, 0, $31\n\t" \ - "sd\t$16,"__str(PT_R16)"($29)\t\t\t# save_static_function\n\t" \ - "sd\t$17,"__str(PT_R17)"($29)\n\t" \ - "sd\t$18,"__str(PT_R18)"($29)\n\t" \ - "sd\t$19,"__str(PT_R19)"($29)\n\t" \ - "sd\t$20,"__str(PT_R20)"($29)\n\t" \ - "sd\t$21,"__str(PT_R21)"($29)\n\t" \ - "sd\t$22,"__str(PT_R22)"($29)\n\t" \ - "sd\t$23,"__str(PT_R23)"($29)\n\t" \ - "sd\t$30,"__str(PT_R30)"($29)\n\t" \ - ".end\t" #symbol "\n\t" \ - ".size\t" #symbol",. - " #symbol) - -/* Used in declaration of save_static functions. */ -#define static_unused static __attribute__((unused)) +#define save_static(r) \ +__asm__ __volatile__( \ + "sd $16,%0 # save_static\n\t" \ + "sd $17,%1\n\t" \ + "sd $18,%2\n\t" \ + "sd $19,%3\n\t" \ + "sd $20,%4\n\t" \ + "sd $21,%5\n\t" \ + "sd $22,%6\n\t" \ + "sd $23,%7\n\t" \ + "sd $30,%8" \ + : "=m" ((r)->regs[16]), \ + "=m" ((r)->regs[17]), \ + "=m" ((r)->regs[18]), \ + "=m" ((r)->regs[19]), \ + "=m" ((r)->regs[20]), \ + "=m" ((r)->regs[21]), \ + "=m" ((r)->regs[22]), \ + "=m" ((r)->regs[23]), \ + "=m" ((r)->regs[30])) #define abi64_no_regargs \ unsigned long __dummy0, \ diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/linux/compiler.h linux-mips-2.4.24-pre2-20040116/include/linux/compiler.h --- linux-mips-2.4.24-pre2-20040116.macro/include/linux/compiler.h 2001-10-19 01:25:03.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/linux/compiler.h 2004-02-12 19:54:39.000000000 +0000 @@ -13,4 +13,10 @@ #define likely(x) __builtin_expect((x),1) #define unlikely(x) __builtin_expect((x),0) +#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3) +#define __attribute_used__ __attribute__((__used__)) +#else +#define __attribute_used__ __attribute__((__unused__)) +#endif + #endif /* __LINUX_COMPILER_H */ diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/linux/init.h linux-mips-2.4.24-pre2-20040116/include/linux/init.h --- linux-mips-2.4.24-pre2-20040116.macro/include/linux/init.h 2004-02-09 04:30:16.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/linux/init.h 2004-02-12 19:54:39.000000000 +0000 @@ -2,6 +2,7 @@ #define _LINUX_INIT_H #include +#include /* These macros are used to mark some functions or * initialized data (doesn't apply to uninitialized data) @@ -67,7 +68,7 @@ extern struct kernel_param __setup_start #define __setup(str, fn) \ static char __setup_str_##fn[] __initdata = str; \ - static struct kernel_param __setup_##fn __attribute__((unused)) __initsetup = { __setup_str_##fn, fn } + static struct kernel_param __setup_##fn __attribute_used__ __initsetup = { __setup_str_##fn, fn } #endif /* __ASSEMBLY__ */ @@ -76,12 +77,12 @@ extern struct kernel_param __setup_start * or exit time. */ #define __init __attribute__ ((__section__ (".text.init"))) -#define __exit __attribute__ ((unused, __section__(".text.exit"))) +#define __exit __attribute_used__ __attribute__ ((__section__ (".text.exit"))) #define __initdata __attribute__ ((__section__ (".data.init"))) -#define __exitdata __attribute__ ((unused, __section__ (".data.exit"))) -#define __initsetup __attribute__ ((unused,__section__ (".setup.init"))) -#define __init_call __attribute__ ((unused,__section__ (".initcall.init"))) -#define __exit_call __attribute__ ((unused,__section__ (".exitcall.exit"))) +#define __exitdata __attribute_used__ __attribute__ ((__section__ (".data.exit"))) +#define __initsetup __attribute_used__ __attribute__ ((__section__ (".setup.init"))) +#define __init_call __attribute_used__ __attribute__ ((__section__ (".initcall.init"))) +#define __exit_call __attribute_used__ __attribute__ ((__section__ (".exitcall.exit"))) /* For assembly routines */ #define __INIT .section ".text.init","ax" diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/linux/module.h linux-mips-2.4.24-pre2-20040116/include/linux/module.h --- linux-mips-2.4.24-pre2-20040116.macro/include/linux/module.h 2004-02-11 23:56:32.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/linux/module.h 2004-02-12 19:54:39.000000000 +0000 @@ -8,6 +8,7 @@ #define _LINUX_MODULE_H #include +#include #include #include @@ -202,19 +203,22 @@ extern int try_inc_mod_count(struct modu /* For documentation purposes only. */ -#define MODULE_AUTHOR(name) \ -const char __module_author[] __attribute__((section(".modinfo"))) = \ -"author=" name - -#define MODULE_DESCRIPTION(desc) \ -const char __module_description[] __attribute__((section(".modinfo"))) = \ -"description=" desc +#define MODULE_AUTHOR(name) \ +const char __module_author[] \ + __attribute_used__ \ + __attribute__((section(".modinfo"))) = "author=" name + +#define MODULE_DESCRIPTION(desc) \ +const char __module_description[] \ + __attribute_used__ \ + __attribute__((section(".modinfo"))) = "description=" desc /* Could potentially be used by kmod... */ -#define MODULE_SUPPORTED_DEVICE(dev) \ -const char __module_device[] __attribute__((section(".modinfo"))) = \ -"device=" dev +#define MODULE_SUPPORTED_DEVICE(dev) \ +const char __module_device[] \ + __attribute_used__ \ + __attribute__((section(".modinfo"))) = "device=" dev /* Used to verify parameters given to the module. The TYPE arg should be a string in the following format: @@ -229,15 +233,17 @@ const char __module_device[] __attribute s string */ -#define MODULE_PARM(var,type) \ -const char __module_parm_##var[] \ -__attribute__((section(".modinfo"))) = \ -"parm_" __MODULE_STRING(var) "=" type - -#define MODULE_PARM_DESC(var,desc) \ -const char __module_parm_desc_##var[] \ -__attribute__((section(".modinfo"))) = \ -"parm_desc_" __MODULE_STRING(var) "=" desc +#define MODULE_PARM(var,type) \ +const char __module_parm_##var[] \ + __attribute_used__ \ + __attribute__((section(".modinfo"))) = \ + "parm_" __MODULE_STRING(var) "=" type + +#define MODULE_PARM_DESC(var,desc) \ +const char __module_parm_desc_##var[] \ + __attribute_used__ \ + __attribute__((section(".modinfo"))) = \ + "parm_desc_" __MODULE_STRING(var) "=" desc /* * MODULE_DEVICE_TABLE exports information about devices @@ -283,9 +289,10 @@ static const struct gtype##_id * __modul * 3. So vendors can do likewise based on their own policies */ -#define MODULE_LICENSE(license) \ -static const char __module_license[] __attribute__((section(".modinfo"))) = \ -"license=" license +#define MODULE_LICENSE(license) \ +static const char __module_license[] \ + __attribute_used__ \ + __attribute__((section(".modinfo"))) = "license=" license /* Define the module variable, and usage macros. */ extern struct module __this_module; @@ -296,11 +303,11 @@ extern struct module __this_module; #define MOD_IN_USE __MOD_IN_USE(THIS_MODULE) #include -static const char __module_kernel_version[] __attribute__((section(".modinfo"))) = -"kernel_version=" UTS_RELEASE; +static const char __module_kernel_version[] __attribute_used__ + __attribute__((section(".modinfo"))) = "kernel_version=" UTS_RELEASE; #ifdef MODVERSIONS -static const char __module_using_checksums[] __attribute__((section(".modinfo"))) = -"using_checksums=1"; +static const char __module_using_checksums[] __attribute_used__ + __attribute__((section(".modinfo"))) = "using_checksums=1"; #endif #else /* MODULE */ From agx@sigxcpu.org Fri Feb 13 14:21:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 14:21:04 +0000 (GMT) Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:57228 "EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 14:21:04 +0000 Received: from localhost (localhost [127.0.0.1]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 4F9C82BC44; Fri, 13 Feb 2004 15:21:02 +0100 (CET) Received: from honk1.physik.uni-konstanz.de ([127.0.0.1]) by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 19570-30; Fri, 13 Feb 2004 15:20:39 +0100 (CET) Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122]) by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id DF6102BC3E; Fri, 13 Feb 2004 15:20:39 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 7ECB64341; Fri, 13 Feb 2004 15:17:07 +0100 (CET) Date: Fri, 13 Feb 2004 15:17:07 +0100 From: Guido Guenther To: Joost Cc: linux-mips@linux-mips.org Subject: Re: indy r4000FPC kernel? Message-ID: <20040213141707.GB960@bogon.ms20.nix> Mail-Followup-To: Guido Guenther , Joost , linux-mips@linux-mips.org References: <20040212174822.GD1280@bogon.ms20.nix> <20040212201020.GA942@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 13, 2004 at 09:37:00AM +0100, Joost wrote: > On Thu, 12 Feb 2004, Guido Guenther wrote: > > On Thu, Feb 12, 2004 at 07:46:36PM +0100, Joost wrote: > > > On Thu, 12 Feb 2004, Guido Guenther wrote: > > > > On Thu, Feb 12, 2004 at 05:12:58PM +0100, Joost wrote: > > > > > seems to be as far as it will go. The 2.4.22 that comes with > > > > > debian testing gives an error while booting so i decided > > > > What kind of error? > > > It might have been the "can't load elf" problem. I'm very new > > > to all of this so at the time (yesterday :-) I didn't know a > > > solution existed. If it's important to you I could check again > > > tomorow? > > Yes please do. Thanks. > After running elf2ecoff on it, the kernel from debian testing > (kernel-image-2.4.22-r4k-ip22) seems to run just fine. > The linux_2_4 cvs that compiled this night also works ok. Thanks a lot for testing this. BTW you can avoid elf2ecoff by using arcboot. Cheers, -- Guido --rJwd6BRFiFCcLxzm 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) iD8DBQFALNxjn88szT8+ZCYRAu5AAJ92wT/ola9eEkuRU5hbx6S9El9jhACfTdDf EIB5oEjRay/+zR7jvbsHrs4= =j1st -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm-- From ralf@linux-mips.org Fri Feb 13 14:54:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 14:54:20 +0000 (GMT) Received: from p508B619B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.155]:64311 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 14:54:20 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1DErJex023880; Fri, 13 Feb 2004 15:53:19 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1DErGeV023879; Fri, 13 Feb 2004 15:53:16 +0100 Date: Fri, 13 Feb 2004 15:53:16 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040213145316.GA23810@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: 4352 X-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, Feb 13, 2004 at 03:20:27PM +0100, Maciej W. Rozycki wrote: > 2. It changes inline-assembly function prologues to be embedded within the > functions, which makes them a bit safer as they can now explicitly refer > to the "regs" struct and assures the code won't be removed or reordered. It is possible that gcc changes one of the registers before save_static and I can't imagine there's a reliable way to fix this in the inline version. Ralf From jsun@orion.mvista.com Fri Feb 13 17:52:24 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 17:52:24 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:22008 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 17:52:24 +0000 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i1DHpftS016862; Fri, 13 Feb 2004 09:51:41 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i1DHpfwQ016860; Fri, 13 Feb 2004 09:51:41 -0800 Date: Fri, 13 Feb 2004 09:51:41 -0800 From: Jun Sun To: Ralf Baechle Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040213175141.GB16718@mvista.com> References: <20040213145316.GA23810@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040213145316.GA23810@linux-mips.org> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4353 X-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 Fri, Feb 13, 2004 at 03:53:16PM +0100, Ralf Baechle wrote: > On Fri, Feb 13, 2004 at 03:20:27PM +0100, Maciej W. Rozycki wrote: > > > 2. It changes inline-assembly function prologues to be embedded within the > > functions, which makes them a bit safer as they can now explicitly refer > > to the "regs" struct and assures the code won't be removed or reordered. > > It is possible that gcc changes one of the registers before save_static > and I can't imagine there's a reliable way to fix this in the inline > version. > Yes. I still remember this bug vividly. It took me quite a few days to track it down. I really wish there is a more reliable and systematic way to do this, even at some expense of a few more instructions ... Jun From macro@ds2.pg.gda.pl Fri Feb 13 18:35:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 18:35:06 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:48009 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 18:35:06 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 664FB4AD51; Fri, 13 Feb 2004 19:35:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 57FD34787C; Fri, 13 Feb 2004 19:35:01 +0100 (CET) Date: Fri, 13 Feb 2004 19:35:01 +0100 (CET) From: "Maciej W. Rozycki" To: Jun Sun Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 In-Reply-To: <20040213175141.GB16718@mvista.com> Message-ID: References: <20040213145316.GA23810@linux-mips.org> <20040213175141.GB16718@mvista.com> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Fri, 13 Feb 2004, Jun Sun wrote: > > > 2. It changes inline-assembly function prologues to be embedded within the > > > functions, which makes them a bit safer as they can now explicitly refer > > > to the "regs" struct and assures the code won't be removed or reordered. > > > > It is possible that gcc changes one of the registers before save_static I think it is possible, too, but it doesn't happen now as gcc tries not to change static callee-saved registers if possible as that's expensive. Only changes to "s8" seem inevitable if the frame pointer is used, but for MIPS the kernel is always built with "-fomit-frame-pointer", so the restriction doesn't apply. > > and I can't imagine there's a reliable way to fix this in the inline > > version. > > Yes. I still remember this bug vividly. It took me quite a few days > to track it down. The patch makes the code safer than what we have now, but it would still need to be verified periodically. > I really wish there is a more reliable and systematic way to do this, > even at some expense of a few more instructions ... If we want to tolerate performance loss, then it's easily doable. That can be done with the current setup, with a jump instruction to the referred function added at the end and "__attribute__((used))" or perhaps "asm("foo")" added to the function declaration. I can choose this path if we agree on it. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Fri Feb 13 22:08:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 22:08:21 +0000 (GMT) Received: from p508B619B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.155]:21052 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 22:08:20 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1DM7mex001605; Fri, 13 Feb 2004 23:07:48 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1DM7PYa001598; Fri, 13 Feb 2004 23:07:25 +0100 Date: Fri, 13 Feb 2004 23:07:25 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jun Sun , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040213220725.GA31847@linux-mips.org> References: <20040213145316.GA23810@linux-mips.org> <20040213175141.GB16718@mvista.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: 4355 X-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, Feb 13, 2004 at 07:35:01PM +0100, Maciej W. Rozycki wrote: > If we want to tolerate performance loss, then it's easily doable. That > can be done with the current setup, with a jump instruction to the > referred function added at the end and "__attribute__((used))" or perhaps > "asm("foo")" added to the function declaration. > > I can choose this path if we agree on it. The inline version is fundemantally fragile. The outline version has problems with getting reordered by later gcc which can be solved by putting a jump to the C function at the end; the C function also needs the right __attribute__s so it won't get eleminated by gcc. Ralf From ica2_ts@csv.ica.uni-stuttgart.de Fri Feb 13 22:22:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 22:22:55 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:32367 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 22:22:55 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1Arli1-00041P-00; Fri, 13 Feb 2004 23:22:53 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1Arli1-0006tk-00; Fri, 13 Feb 2004 23:22:53 +0100 Date: Fri, 13 Feb 2004 23:22:53 +0100 To: Ralf Baechle Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> References: <20040213145316.GA23810@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040213145316.GA23810@linux-mips.org> User-Agent: Mutt/1.5.5.1i 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: 4356 X-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 Baechle wrote: > On Fri, Feb 13, 2004 at 03:20:27PM +0100, Maciej W. Rozycki wrote: > > > 2. It changes inline-assembly function prologues to be embedded within the > > functions, which makes them a bit safer as they can now explicitly refer > > to the "regs" struct and assures the code won't be removed or reordered. > > It is possible that gcc changes one of the registers before save_static > and I can't imagine there's a reliable way to fix this in the inline > version. As long as __asm__ __volatile__ works as documented, this can't happen. Thiemo From ddaney@avtrex.com Fri Feb 13 22:35:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 22:35:47 +0000 (GMT) Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:11591 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 22:35:46 +0000 Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 14:35:44 -0800 Message-ID: <402D513F.8080205@avtrex.com> Date: Fri, 13 Feb 2004 14:35:43 -0800 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: Thiemo Seufer CC: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> In-Reply-To: <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 22:35:44.0118 (UTC) FILETIME=[B794A160:01C3F281] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4357 X-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 Thiemo Seufer wrote: >Ralf Baechle wrote: > > >>On Fri, Feb 13, 2004 at 03:20:27PM +0100, Maciej W. Rozycki wrote: >> >> >> >>>2. It changes inline-assembly function prologues to be embedded within the >>>functions, which makes them a bit safer as they can now explicitly refer >>>to the "regs" struct and assures the code won't be removed or reordered. >>> >>> >>It is possible that gcc changes one of the registers before save_static >>and I can't imagine there's a reliable way to fix this in the inline >>version. >> >> > >As long as __asm__ __volatile__ works as documented, this can't happen. > > My understanding is that with gcc-3.4 that __asm__ __volatile__ does not protect against dead code removal. If the code is not dead __volatile__ works as documented, but dead code removal still happens. David Daney. From ica2_ts@csv.ica.uni-stuttgart.de Fri Feb 13 22:50:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2004 22:50:04 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:44655 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Fri, 13 Feb 2004 22:50:04 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1Arm8H-0004D5-00; Fri, 13 Feb 2004 23:50:01 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1Arm8G-00037K-00; Fri, 13 Feb 2004 23:50:00 +0100 Date: Fri, 13 Feb 2004 23:50:00 +0100 To: David Daney Cc: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402D513F.8080205@avtrex.com> User-Agent: Mutt/1.5.5.1i 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: 4358 X-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 David Daney wrote: > Thiemo Seufer wrote: > > >Ralf Baechle wrote: > > > > > >>On Fri, Feb 13, 2004 at 03:20:27PM +0100, Maciej W. Rozycki wrote: > >> > >> > >> > >>>2. It changes inline-assembly function prologues to be embedded within > >>>the > >>>functions, which makes them a bit safer as they can now explicitly refer > >>>to the "regs" struct and assures the code won't be removed or reordered. > >>> > >>> > >>It is possible that gcc changes one of the registers before save_static > >>and I can't imagine there's a reliable way to fix this in the inline > >>version. > > > >As long as __asm__ __volatile__ works as documented, this can't happen. > > > My understanding is that with gcc-3.4 that __asm__ __volatile__ does not > protect against dead code removal. If the code is not dead __volatile__ > works as documented, but dead code removal still happens. The inline version isn't dead code, and gcc isn't allowed to reschedule code around a __asm__ __volatile__, so the patch should be ok. Thiemo From ralf@linux-mips.org Sat Feb 14 01:16:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 01:16:25 +0000 (GMT) Received: from p508B619B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.155]:39742 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 14 Feb 2004 01:16:25 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1E1Fhex004631; Sat, 14 Feb 2004 02:15:43 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1E1FdYY004630; Sat, 14 Feb 2004 02:15:39 +0100 Date: Sat, 14 Feb 2004 02:15:39 +0100 From: Ralf Baechle To: Thiemo Seufer Cc: David Daney , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040214011539.GB31847@linux-mips.org> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.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: 4359 X-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, Feb 13, 2004 at 11:50:00PM +0100, Thiemo Seufer wrote: > > My understanding is that with gcc-3.4 that __asm__ __volatile__ does not > > protect against dead code removal. If the code is not dead __volatile__ > > works as documented, but dead code removal still happens. > > The inline version isn't dead code, and gcc isn't allowed to reschedule > code around a __asm__ __volatile__, so the patch should be ok. It's the gcc generated function epilogue which is the problem. There's no reliable way to work around that ... Ralf From echristo@redhat.com Sat Feb 14 01:22:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 01:22:40 +0000 (GMT) Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:19209 "EHLO mx2.redhat.com") by linux-mips.org with ESMTP id ; Sat, 14 Feb 2004 01:22:40 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i1E0wAn12068; Fri, 13 Feb 2004 19:58:10 -0500 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 i1E1MbM24028; Fri, 13 Feb 2004 20:22:37 -0500 Received: from [192.168.123.101] (vpn26-4.sfbay.redhat.com [172.16.26.4]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i1E1MaX03005; Fri, 13 Feb 2004 17:22:36 -0800 Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 From: Eric Christopher To: Ralf Baechle Cc: Thiemo Seufer , David Daney , "Maciej W. Rozycki" , linux-mips@linux-mips.org In-Reply-To: <20040214011539.GB31847@linux-mips.org> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214011539.GB31847@linux-mips.org> Content-Type: text/plain Message-Id: <1076721727.3773.0.camel@dzur.sfbay.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 13 Feb 2004 17:22:07 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: echristo@redhat.com Precedence: bulk X-list: linux-mips > It's the gcc generated function epilogue which is the problem. There's > no reliable way to work around that ... What's the problem? -eric -- Eric Christopher From ica2_ts@csv.ica.uni-stuttgart.de Sat Feb 14 01:28:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 01:28:05 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:42864 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Sat, 14 Feb 2004 01:28:04 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1ArobC-0005O0-00; Sat, 14 Feb 2004 02:28:02 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1ArobB-0004TR-00; Sat, 14 Feb 2004 02:28:01 +0100 Date: Sat, 14 Feb 2004 02:28:01 +0100 To: Ralf Baechle Cc: David Daney , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040214012801.GC20118@rembrandt.csv.ica.uni-stuttgart.de> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214011539.GB31847@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040214011539.GB31847@linux-mips.org> User-Agent: Mutt/1.5.5.1i 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: 4361 X-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 Baechle wrote: > On Fri, Feb 13, 2004 at 11:50:00PM +0100, Thiemo Seufer wrote: > > > > My understanding is that with gcc-3.4 that __asm__ __volatile__ does not > > > protect against dead code removal. If the code is not dead __volatile__ > > > works as documented, but dead code removal still happens. > > > > The inline version isn't dead code, and gcc isn't allowed to reschedule > > code around a __asm__ __volatile__, so the patch should be ok. > > It's the gcc generated function epilogue which is the problem. There's > no reliable way to work around that ... ITYM prologue. It has to follow the ABI specification, so $fp is the only possibly problematic one, and that's excluded by -fomit-frame-pointers. Thiemo From ralf@linux-mips.org Sat Feb 14 01:46:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 01:46:08 +0000 (GMT) Received: from p508B619B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.155]:64318 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 14 Feb 2004 01:46:08 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1E1jKex005142; Sat, 14 Feb 2004 02:45:20 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1E1jKlW005141; Sat, 14 Feb 2004 02:45:20 +0100 Date: Sat, 14 Feb 2004 02:45:20 +0100 From: Ralf Baechle To: Thiemo Seufer Cc: David Daney , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040214014520.GA4588@linux-mips.org> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214011539.GB31847@linux-mips.org> <20040214012801.GC20118@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040214012801.GC20118@rembrandt.csv.ica.uni-stuttgart.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: 4362 X-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 Sat, Feb 14, 2004 at 02:28:01AM +0100, Thiemo Seufer wrote: > > It's the gcc generated function epilogue which is the problem. There's > > no reliable way to work around that ... > > ITYM prologue. It has to follow the ABI specification, so $fp is the only > possibly problematic one, and that's excluded by -fomit-frame-pointers. Daniel Jacobowitz reported the problem which indeed was about $30. Since the kernel uses -fomit-frame-pointer by default (and -O1 enables it by default on MIPS anyway) I would assume his kernel was built using that option. Maybe he can elaborate ... Anyway, gcc could load next weeks lucky lottery numbers into the s-registers after saving them. That'd break save_static but not the ABI which only promises to restore the old values in s-registers on return. Ralf From ica2_ts@csv.ica.uni-stuttgart.de Sat Feb 14 02:17:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 02:17:42 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:3185 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Sat, 14 Feb 2004 02:17:41 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1ArpNF-0005mq-00; Sat, 14 Feb 2004 03:17:41 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1ArpNE-0004p5-00; Sat, 14 Feb 2004 03:17:40 +0100 Date: Sat, 14 Feb 2004 03:17:40 +0100 To: Ralf Baechle Cc: David Daney , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040214021740.GE20118@rembrandt.csv.ica.uni-stuttgart.de> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214011539.GB31847@linux-mips.org> <20040214012801.GC20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214014520.GA4588@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040214014520.GA4588@linux-mips.org> User-Agent: Mutt/1.5.5.1i 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: 4363 X-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 Baechle wrote: [snip] > Anyway, gcc could load next weeks lucky lottery numbers into the > s-registers after saving them. That'd break save_static but not the > ABI which only promises to restore the old values in s-registers on > return. Ok, it could, but adding such insns to the prologue wouldn't make sense at all, so this is unlikely to happen. Thiemo From jsun@orion.mvista.com Sat Feb 14 06:14:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 06:14:28 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:13054 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Sat, 14 Feb 2004 06:14:28 +0000 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i1E6DstS021471; Fri, 13 Feb 2004 22:13:54 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i1E6DrcP021469; Fri, 13 Feb 2004 22:13:53 -0800 Date: Fri, 13 Feb 2004 22:13:53 -0800 From: Jun Sun To: Thiemo Seufer Cc: Ralf Baechle , David Daney , "Maciej W. Rozycki" , linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040214061353.GA21449@mvista.com> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214011539.GB31847@linux-mips.org> <20040214012801.GC20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214014520.GA4588@linux-mips.org> <20040214021740.GE20118@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040214021740.GE20118@rembrandt.csv.ica.uni-stuttgart.de> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4364 X-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 Sat, Feb 14, 2004 at 03:17:40AM +0100, Thiemo Seufer wrote: > Ralf Baechle wrote: > [snip] > > Anyway, gcc could load next weeks lucky lottery numbers into the > > s-registers after saving them. That'd break save_static but not the > > ABI which only promises to restore the old values in s-registers on > > return. > > Ok, it could, but adding such insns to the prologue wouldn't make > sense at all, so this is unlikely to happen. > OS people who have been around long enough know "unlikely" things always end up happening. :) See my posting around Oct 2000 below. Granted - gcc has changed a lot and perhaps it won't do it again. But just like a Chinese saying, "Once bitten by the snake, afraid of the straw rope for three years". :) I like the safe alternative. Jun P.S., the actual fix was done by Ralf http://www.linux-mips.org/xcvs/linux-mips/patches/001282_001027_MAIN_ralf ------------------------------------------------------------------ Nasty degree - 3 days of tracking. The symptom was pthread cannot be created. In the end the caller will get a BUS error. What exactly happened has to do with how registers are saved. Below attached is the beginning part of sys_sigsuspend() function. It is easy to see that s0 is saved into stack frame AFTER its modified. Next time when process returns to userland, the s0 reg will be wrong! So the bug is either 1) that we need to save s0 register in SAVE_SOME and not save it in save_static; or that 2) we fix compiler so that it does not use s0 register in that case (it does the same thing for sys_rt_sigsuspend) I am sure Ralf will have something to say about it. :-) In any case, I attached a patch for 1) fix. Jun ------------ sys_sigsuspend(struct pt_regs regs) { 8008e280: 27bdffc0 addiu $sp,$sp,-64 8008e284: afb00030 sw $s0,48($sp) sigset_t *uset, saveset, newset; save_static(®s); 8008e288: 27b00040 addiu $s0,$sp,64 8008e28c: afbf003c sw $ra,60($sp) 8008e290: afb20038 sw $s2,56($sp) 8008e294: afb10034 sw $s1,52($sp) 8008e298: afa40040 sw $a0,64($sp) 8008e29c: afa50044 sw $a1,68($sp) 8008e2a0: afa60048 sw $a2,72($sp) 8008e2a4: afa7004c sw $a3,76($sp) 8008e2a8: ae100058 sw $s0,88($s0) 8008e2ac: ae11005c sw $s1,92($s0) ..... From ica2_ts@csv.ica.uni-stuttgart.de Sat Feb 14 06:29:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 06:29:03 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:61298 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Sat, 14 Feb 2004 06:29:02 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1ArtIH-0007dA-00; Sat, 14 Feb 2004 07:28:49 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1ArtIH-0005XU-00; Sat, 14 Feb 2004 07:28:49 +0100 Date: Sat, 14 Feb 2004 07:28:49 +0100 To: Jun Sun Cc: Ralf Baechle , David Daney , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040214062849.GA20171@rembrandt.csv.ica.uni-stuttgart.de> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214011539.GB31847@linux-mips.org> <20040214012801.GC20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214014520.GA4588@linux-mips.org> <20040214021740.GE20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214061353.GA21449@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040214061353.GA21449@mvista.com> User-Agent: Mutt/1.5.5.1i 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: 4365 X-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 Jun Sun wrote: > On Sat, Feb 14, 2004 at 03:17:40AM +0100, Thiemo Seufer wrote: > > Ralf Baechle wrote: > > [snip] > > > Anyway, gcc could load next weeks lucky lottery numbers into the > > > s-registers after saving them. That'd break save_static but not the > > > ABI which only promises to restore the old values in s-registers on > > > return. > > > > Ok, it could, but adding such insns to the prologue wouldn't make > > sense at all, so this is unlikely to happen. > > > > OS people who have been around long enough know "unlikely" things > always end up happening. :) [snip] > sys_sigsuspend(struct pt_regs regs) > { > 8008e280: 27bdffc0 addiu $sp,$sp,-64 > 8008e284: afb00030 sw $s0,48($sp) > sigset_t *uset, saveset, newset; > > save_static(®s); Which is a compiler bug, because it schedules around __asm__ __volatile__, but not a breakage caused by the prologue. There's no way to be safe from broken compilers. Thiemo From yuasa@hh.iij4u.or.jp Sat Feb 14 15:05:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 15:05:24 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:17904 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Sat, 14 Feb 2004 15:05:23 +0000 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 AAA13842; Sun, 15 Feb 2004 00:05:19 +0900 (JST) Received: 4UMDO00 id i1EF5Jx01468; Sun, 15 Feb 2004 00:05:19 +0900 (JST) Received: 4UMRO00 id i1EF5HC01030; Sun, 15 Feb 2004 00:05:18 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Sun, 15 Feb 2004 00:05:15 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.4] Changed clock function for vr41xx Message-Id: <20040215000515.66bc8839.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4366 X-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 Hello Ralf, I made a patch for vr41xx. This patch changes a clock function for a power management. This is required because of a power management. Please apply this patch to v2.4. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c --- linux-orig/arch/mips/vr41xx/common/cmu.c Tue Jan 13 08:16:58 2004 +++ linux/arch/mips/vr41xx/common/cmu.c Wed Feb 11 00:34:15 2004 @@ -40,6 +40,7 @@ * - Added support for NEC VR4133. */ #include +#include #include #include @@ -66,16 +67,19 @@ #define MSKMAC0 0x0002 #define MSKMAC1 0x0004 -static u32 vr41xx_cmu_base; -static u16 cmuclkmsk, cmuclkmsk2; +static uint32_t cmu_base; +static uint16_t cmuclkmsk, cmuclkmsk2; +static spinlock_t cmu_lock; -#define read_cmuclkmsk() readw(vr41xx_cmu_base) +#define read_cmuclkmsk() readw(cmu_base) #define read_cmuclkmsk2() readw(CMUCLKMSK2) -#define write_cmuclkmsk() writew(cmuclkmsk, vr41xx_cmu_base) +#define write_cmuclkmsk() writew(cmuclkmsk, cmu_base) #define write_cmuclkmsk2() writew(cmuclkmsk2, CMUCLKMSK2) -void vr41xx_clock_supply(unsigned int clock) +void vr41xx_supply_clock(unsigned int clock) { + spin_lock_irq(&cmu_lock); + switch (clock) { case PIU_CLOCK: cmuclkmsk |= MSKPIU; @@ -129,10 +133,14 @@ write_cmuclkmsk2(); else write_cmuclkmsk(); + + spin_unlock_irq(&cmu_lock); } -void vr41xx_clock_mask(unsigned int clock) +void vr41xx_mask_clock(unsigned int clock) { + spin_lock_irq(&cmu_lock); + switch (clock) { case PIU_CLOCK: cmuclkmsk &= ~MSKPIU; @@ -198,6 +206,8 @@ write_cmuclkmsk2(); else write_cmuclkmsk(); + + spin_unlock_irq(&cmu_lock); } void __init vr41xx_cmu_init(void) @@ -205,14 +215,14 @@ switch (current_cpu_data.cputype) { case CPU_VR4111: case CPU_VR4121: - vr41xx_cmu_base = CMUCLKMSK_TYPE1; + cmu_base = CMUCLKMSK_TYPE1; break; case CPU_VR4122: case CPU_VR4131: - vr41xx_cmu_base = CMUCLKMSK_TYPE2; + cmu_base = CMUCLKMSK_TYPE2; break; case CPU_VR4133: - vr41xx_cmu_base = CMUCLKMSK_TYPE2; + cmu_base = CMUCLKMSK_TYPE2; cmuclkmsk2 = read_cmuclkmsk2(); break; default: @@ -221,4 +231,6 @@ } cmuclkmsk = read_cmuclkmsk(); + + spin_lock_init(&cmu_lock); } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/ksyms.c linux/arch/mips/vr41xx/common/ksyms.c --- linux-orig/arch/mips/vr41xx/common/ksyms.c Thu Dec 18 00:58:12 2003 +++ linux/arch/mips/vr41xx/common/ksyms.c Wed Feb 11 00:34:15 2004 @@ -25,6 +25,9 @@ EXPORT_SYMBOL(vr41xx_get_vtclock_frequency); EXPORT_SYMBOL(vr41xx_get_tclock_frequency); +EXPORT_SYMBOL(vr41xx_supply_clock); +EXPORT_SYMBOL(vr41xx_mask_clock); + EXPORT_SYMBOL(vr41xx_set_intassign); EXPORT_SYMBOL(vr41xx_set_rtclong1_cycle); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/pciu.c linux/arch/mips/vr41xx/common/pciu.c --- linux-orig/arch/mips/vr41xx/common/pciu.c Tue Feb 10 22:33:40 2004 +++ linux/arch/mips/vr41xx/common/pciu.c Wed Feb 11 00:34:15 2004 @@ -178,7 +178,7 @@ writew(0, MPCIINTREG); /* Supply VTClock to PCIU */ - vr41xx_clock_supply(PCIU_CLOCK); + vr41xx_supply_clock(PCIU_CLOCK); /* Dummy read/write, waiting for supply of VTClock. */ readw(MPCIINTREG); @@ -196,7 +196,7 @@ printk(KERN_INFO "Warning: PCI Clock is over 33MHz.\n"); /* Supply PCI clock by PCI bus */ - vr41xx_clock_supply(PCI_CLOCK); + vr41xx_supply_clock(PCI_CLOCK); /* * Set PCI memory & I/O space address conversion registers 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 Tue Jan 13 08:16:58 2004 +++ linux/arch/mips/vr41xx/common/serial.c Wed Feb 11 00:34:15 2004 @@ -145,7 +145,7 @@ if (early_serial_setup(&s) != 0) printk(KERN_ERR "SIU setup failed!\n"); - vr41xx_clock_supply(SIU_CLOCK); + vr41xx_supply_clock(SIU_CLOCK); vr41xx_serial_ports++; } @@ -171,7 +171,7 @@ if (early_serial_setup(&s) != 0) printk(KERN_ERR "DSIU setup failed!\n"); - vr41xx_clock_supply(DSIU_CLOCK); + vr41xx_supply_clock(DSIU_CLOCK); writew(INTDSIU, MDSIUINTREG); diff -urN -X dontdiff linux-orig/drivers/char/vr41xx_keyb.c linux/drivers/char/vr41xx_keyb.c --- linux-orig/drivers/char/vr41xx_keyb.c Tue Feb 10 06:21:26 2004 +++ linux/drivers/char/vr41xx_keyb.c Wed Feb 11 00:34:15 2004 @@ -325,7 +325,7 @@ if (current_cpu_data.cputype == CPU_VR4111 || current_cpu_data.cputype == CPU_VR4121) - vr41xx_clock_supply(KIU_CLOCK); + vr41xx_supply_clock(KIU_CLOCK); kiu_writew(KIURST_KIURST, KIURST); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Tue Feb 10 22:33:56 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Wed Feb 11 00:36:44 2004 @@ -53,8 +53,6 @@ * Clock Mask Unit */ extern void vr41xx_cmu_init(void); -extern void vr41xx_clock_supply(unsigned int clock); -extern void vr41xx_clock_mask(unsigned int clock); enum { PIU_CLOCK, @@ -71,6 +69,9 @@ ETHER0_CLOCK, ETHER1_CLOCK }; + +extern void vr41xx_supply_clock(unsigned int clock); +extern void vr41xx_mask_clock(unsigned int clock); /* * Interrupt Control Unit From indigodfw@yahoo.com Sat Feb 14 15:11:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2004 15:11:56 +0000 (GMT) Received: from web9502.mail.yahoo.com ([IPv6:::ffff:216.136.129.132]:38821 "HELO web9502.mail.yahoo.com") by linux-mips.org with SMTP id ; Sat, 14 Feb 2004 15:11:55 +0000 Message-ID: <20040214151152.80368.qmail@web9502.mail.yahoo.com> Received: from [128.107.253.38] by web9502.mail.yahoo.com via HTTP; Sat, 14 Feb 2004 07:11:52 PST Date: Sat, 14 Feb 2004 07:11:52 -0800 (PST) From: Indigodfw Subject: question about memory constraint in atomic_add 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: 4367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: indigodfw@yahoo.com Precedence: bulk X-list: linux-mips Hello Gurus Question from a mips new-bie 127 extern __inline__ void atomic_add(int i, atomic_t * v) 128 { 129 unsigned long temp; 130 131 __asm__ __volatile__( 132 "1: ll %0, %1 # atomic_add\n" 133 " addu %0, %2 \n" 134 " sc %0, %1 \n" 135 " beqz %0, 1b \n" 136 : "=&r" (temp), "=m" (v->counter) 137 : "Ir" (i), "m" (v->counter)); 138 } Now I look at the input operand v->counter We want two things : 1. Hint the compiler that memory at (v->counter) is modified. 2. Result of (C expression) should go into %xyz register So v->counter goes into %1, IOW ll from an int! Does not make sense to me. Why does it work, What am I missing? I mean in general what is the expression for a m constraint ptr (because I want ptr to be in regiser) or *ptr (because I wanna tell compiler that *ptr is what gets changed) I hope you include me in reply as I am not subscribed to this list. Is there anyway to check this mailing list online Thanks and regards __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From drow@crack.them.org Sun Feb 15 01:45:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 15 Feb 2004 01:45:32 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:45029 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Sun, 15 Feb 2004 01:45:27 +0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AsBKq-00052v-Ur; Sat, 14 Feb 2004 20:44:40 -0500 Date: Sat, 14 Feb 2004 20:44:40 -0500 From: Daniel Jacobowitz To: Thiemo Seufer Cc: Jun Sun , Ralf Baechle , David Daney , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 Message-ID: <20040215014440.GA19373@nevyn.them.org> References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214011539.GB31847@linux-mips.org> <20040214012801.GC20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214014520.GA4588@linux-mips.org> <20040214021740.GE20118@rembrandt.csv.ica.uni-stuttgart.de> <20040214061353.GA21449@mvista.com> <20040214062849.GA20171@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040214062849.GA20171@rembrandt.csv.ica.uni-stuttgart.de> User-Agent: Mutt/1.5.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: 4368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Sat, Feb 14, 2004 at 07:28:49AM +0100, Thiemo Seufer wrote: > Jun Sun wrote: > > On Sat, Feb 14, 2004 at 03:17:40AM +0100, Thiemo Seufer wrote: > > > Ralf Baechle wrote: > > > [snip] > > > > Anyway, gcc could load next weeks lucky lottery numbers into the > > > > s-registers after saving them. That'd break save_static but not the > > > > ABI which only promises to restore the old values in s-registers on > > > > return. > > > > > > Ok, it could, but adding such insns to the prologue wouldn't make > > > sense at all, so this is unlikely to happen. > > > > > > > OS people who have been around long enough know "unlikely" things > > always end up happening. :) > [snip] > > sys_sigsuspend(struct pt_regs regs) > > { > > 8008e280: 27bdffc0 addiu $sp,$sp,-64 > > 8008e284: afb00030 sw $s0,48($sp) > > sigset_t *uset, saveset, newset; > > > > save_static(®s); > > Which is a compiler bug, because it schedules around __asm__ __volatile__, > but not a breakage caused by the prologue. > > There's no way to be safe from broken compilers. Not at all. It's not code being scheduled around the asm - it's _part of the prologue_ to save $s0 to the stack. Register saves are considered part of the prologue. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From kazssym@netscape.net Mon Feb 16 05:19:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Feb 2004 05:19:57 +0000 (GMT) Received: from imo-d01.mx.aol.com ([IPv6:::ffff:205.188.157.33]:8178 "EHLO imo-d01.mx.aol.com") by linux-mips.org with ESMTP id ; Mon, 16 Feb 2004 05:19:52 +0000 Received: from kazssym@netscape.net by imo-d01.mx.aol.com (mail_out_v36_r4.14.) id l.13a.ad6fac8 (22683) for ; Mon, 16 Feb 2004 00:19:33 -0500 (EST) Received: from netscape.net (mow-m10.webmail.aol.com [64.12.184.138]) by air-in04.mx.aol.com (v97.18) with ESMTP id MAILININ44-589b403052e41; Mon, 16 Feb 2004 00:19:32 -0500 Date: Mon, 16 Feb 2004 00:19:32 -0500 From: kazssym@netscape.net (Kaz Sasayama) To: linux-mips@linux-mips.org Subject: Linux 2.6 on DDB5477? MIME-Version: 1.0 Message-ID: <067BC2F8.2E443D82.001F92DE@netscape.net> X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 210.175.155.125 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kazssym@netscape.net Precedence: bulk X-list: linux-mips Is anyone working on DDB5477 config of Linux 2.6? I tried to compile it but got many errors that I could not fix completely. If there is a working patch, please let me know. Thanks in advance. __________________________________________________________________ New! Unlimited Netscape Internet Service. Only $9.95 a month -- Sign up today at http://isp.netscape.com/register Act now to get a personalized email address! Netscape. Just the Net You Need. From macro@ds2.pg.gda.pl Mon Feb 16 09:18:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Feb 2004 09:18:20 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:58506 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 16 Feb 2004 09:18:20 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id D18CC4781E; Mon, 16 Feb 2004 10:18:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id BE15143046; Mon, 16 Feb 2004 10:18:17 +0100 (CET) Date: Mon, 16 Feb 2004 10:18:17 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Jun Sun , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 In-Reply-To: <20040213220725.GA31847@linux-mips.org> Message-ID: References: <20040213145316.GA23810@linux-mips.org> <20040213175141.GB16718@mvista.com> <20040213220725.GA31847@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Fri, 13 Feb 2004, Ralf Baechle wrote: > > If we want to tolerate performance loss, then it's easily doable. That > > can be done with the current setup, with a jump instruction to the > > referred function added at the end and "__attribute__((used))" or perhaps > > "asm("foo")" added to the function declaration. > > > > I can choose this path if we agree on it. > > The inline version is fundemantally fragile. The outline version has > problems with getting reordered by later gcc which can be solved by > putting a jump to the C function at the end; the C function also needs > the right __attribute__s so it won't get eleminated by gcc. This is exactly what I'm writing of ("the current setup" == what we now have in the kernel; sorry for being ambiguous) -- except that I'd go for the "asm("foo")" variant which does not require any additional __attribute__s and should work at least since gcc 2.95 (and which I like better). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Mon Feb 16 11:11:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Feb 2004 11:11:43 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:7098 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 16 Feb 2004 11:11:41 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id A9FC3478D5; Mon, 16 Feb 2004 12:11:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 9B4EA43046; Mon, 16 Feb 2004 12:11:39 +0100 (CET) Date: Mon, 16 Feb 2004 12:11:39 +0100 (CET) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch] Ensure proper section alignment [gcc 3.4] Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Hello, The exception-related sections appear to work with gcc 2.95 by accident -- they lack appropriate alignment directives and just happen to be properly aligned, at least most of the time. With gcc 3.4, this is no longer true -- I get a quick death of the kernel because of an unaligned trap on an instruction fetch from the ".fixup" section. Here's a proposed solution that works for me. I decided to request proper alignment explicitly in all bits that refer to one of the ".fixup", "__ex_table" and "__dbe_table" sections. This way a proper alignment is set both for the main kernel binary and for modules, and also of bits get removed in the future. It should also make no doubt whether to add an alignment directive or not for one adding code making use of these sections. I've chosen ".p2align" as it has a well-defined platform-independent semantics. OK to apply? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.24-pre2-20040116-fixup-3 diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/gdb-low.S linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/gdb-low.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/gdb-low.S 2003-02-21 03:56:24.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/gdb-low.S 2004-02-15 04:28:37.000000000 +0000 @@ -336,6 +336,7 @@ LEAF(kgdb_read_byte) li v0, 0 jr ra .section __ex_table,"a" + .p2align PTRLOG PTR 4b, kgdbfault .previous END(kgdb_read_byte) @@ -345,6 +346,7 @@ LEAF(kgdb_write_byte) li v0, 0 jr ra .section __ex_table,"a" + .p2align PTRLOG PTR 5b, kgdbfault .previous END(kgdb_write_byte) diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/r2300_fpu.S linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/r2300_fpu.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/r2300_fpu.S 2001-04-12 04:25:48.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/r2300_fpu.S 2004-02-15 13:53:28.000000000 +0000 @@ -21,6 +21,7 @@ #define EX(a,b) \ 9: a,##b; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b,bad_stack; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/r4k_fpu.S linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/r4k_fpu.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/r4k_fpu.S 2001-04-12 04:25:48.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/r4k_fpu.S 2004-02-15 13:53:48.000000000 +0000 @@ -21,6 +21,7 @@ #define EX(a,b) \ 9: a,b; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, fault; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/scall_o32.S linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/scall_o32.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/scall_o32.S 2003-10-29 03:56:51.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/scall_o32.S 2004-02-15 04:14:30.000000000 +0000 @@ -189,6 +189,7 @@ stackargs: j stack_done # go back .section __ex_table,"a" + .p2align PTRLOG PTR 1b,bad_stack PTR 2b,bad_stack .previous @@ -249,6 +250,7 @@ LEAF(mips_atomic_set) beqz a0, 1b .section __ex_table,"a" + .p2align PTRLOG PTR 1b, bad_stack PTR 2b, bad_stack .previous @@ -272,6 +274,7 @@ LEAF(mips_atomic_set) 2: sw a2, (a1) .section __ex_table,"a" + .p2align PTRLOG PTR 1b, no_mem PTR 2b, no_mem .previous @@ -340,7 +343,8 @@ LEAF(sys_syscall) 2: lw t3, 20(t0) 3: lw t4, 24(t0) - .section __ex_table, "a" + .section __ex_table, "a" + .p2align PTRLOG .word 1b, efault .word 2b, efault .word 3b, efault diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/traps.c linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/traps.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/traps.c 2004-01-10 03:56:33.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/traps.c 2004-02-15 04:01:00.000000000 +0000 @@ -9,7 +9,7 @@ * Copyright (C) 1999 Silicon Graphics, Inc. * Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com * Copyright (C) 2000, 01 MIPS Technologies, Inc. - * Copyright (C) 2002, 2003 Maciej W. Rozycki + * Copyright (C) 2002, 2003, 2004 Maciej W. Rozycki */ #include #include @@ -20,6 +20,7 @@ #include #include +#include #include #include #include @@ -282,6 +283,7 @@ void __declare_dbe_table(void) { __asm__ __volatile__( ".section\t__dbe_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" ".previous" ); } diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/unaligned.c linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/unaligned.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/kernel/unaligned.c 2004-01-03 03:56:37.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/kernel/unaligned.c 2004-02-15 04:16:00.000000000 +0000 @@ -85,9 +85,6 @@ #include #include -#define STR(x) __STR(x) -#define __STR(x) #x - #ifdef CONFIG_PROC_FS unsigned long unaligned_instructions; #endif @@ -159,10 +156,12 @@ static inline int emulate_load_store_ins "li\t%1, 0\n" "3:\t.set\tat\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -189,10 +188,12 @@ static inline int emulate_load_store_ins #endif "li\t%1, 0\n" "3:\t.section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -223,10 +224,12 @@ static inline int emulate_load_store_ins "li\t%1, 0\n" "3:\t.set\tat\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -263,10 +266,12 @@ static inline int emulate_load_store_ins "dsrl\t%0, %0, 32\n\t" "li\t%1, 0\n" "3:\t.section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -305,10 +310,12 @@ static inline int emulate_load_store_ins #endif "li\t%1, 0\n" "3:\t.section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -347,10 +354,12 @@ static inline int emulate_load_store_ins "li\t%0, 0\n" "3:\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%0, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -377,10 +386,12 @@ static inline int emulate_load_store_ins "li\t%0, 0\n" "3:\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%0, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -415,10 +426,12 @@ static inline int emulate_load_store_ins "li\t%0, 0\n" "3:\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%0, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/memcpy.S linux-mips-2.4.24-pre2-20040116/arch/mips/lib/memcpy.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/memcpy.S 2003-06-28 02:56:51.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/lib/memcpy.S 2004-02-15 13:54:06.000000000 +0000 @@ -73,6 +73,7 @@ #define EXC(inst_reg,addr,handler) \ 9: inst_reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/memset.S linux-mips-2.4.24-pre2-20040116/arch/mips/lib/memset.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/memset.S 2002-08-06 02:57:18.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/lib/memset.S 2004-02-15 13:54:10.000000000 +0000 @@ -12,6 +12,7 @@ #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/strlen_user.S linux-mips-2.4.24-pre2-20040116/arch/mips/lib/strlen_user.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/strlen_user.S 2002-07-02 02:57:21.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/lib/strlen_user.S 2004-02-15 13:54:15.000000000 +0000 @@ -14,6 +14,7 @@ #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/strncpy_user.S linux-mips-2.4.24-pre2-20040116/arch/mips/lib/strncpy_user.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/strncpy_user.S 2001-09-07 04:26:28.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/lib/strncpy_user.S 2004-02-15 13:54:19.000000000 +0000 @@ -13,6 +13,7 @@ #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/strnlen_user.S linux-mips-2.4.24-pre2-20040116/arch/mips/lib/strnlen_user.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/lib/strnlen_user.S 2002-07-02 02:57:21.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips/lib/strnlen_user.S 2004-02-15 13:54:22.000000000 +0000 @@ -14,6 +14,7 @@ #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/gdb-low.S linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/gdb-low.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/gdb-low.S 2003-07-15 15:17:59.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/gdb-low.S 2004-02-15 04:21:15.000000000 +0000 @@ -336,6 +336,7 @@ LEAF(kgdb_read_byte) li v0, 0 jr ra .section __ex_table,"a" + .p2align PTRLOG PTR 4b, kgdbfault .previous END(kgdb_read_byte) @@ -345,6 +346,7 @@ LEAF(kgdb_write_byte) li v0, 0 jr ra .section __ex_table,"a" + .p2align PTRLOG PTR 5b, kgdbfault .previous END(kgdb_write_byte) diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/r4k_fpu.S linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/r4k_fpu.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/r4k_fpu.S 2003-07-16 02:56:44.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/r4k_fpu.S 2004-02-15 04:21:53.000000000 +0000 @@ -25,6 +25,7 @@ .ex\@: \insn \reg, \src .set pop .section __ex_table,"a" + .p2align PTRLOG PTR .ex\@, fault .previous .endm diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/scall_o32.S linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/scall_o32.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/scall_o32.S 2003-10-16 02:57:04.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/scall_o32.S 2004-02-15 04:22:31.000000000 +0000 @@ -176,6 +176,7 @@ stackargs: j stack_done # go back .section __ex_table,"a" + .p2align PTRLOG PTR 1b, bad_stack PTR 2b, bad_stack .previous @@ -226,6 +227,7 @@ LEAF(mips_atomic_set) beqz a0, 1b .section __ex_table,"a" + .p2align PTRLOG PTR 1b, bad_stack PTR 2b, bad_stack .previous @@ -292,6 +294,7 @@ LEAF(sys32_syscall) 3: lw t1, 24(t0) .section __ex_table,"a" + .p2align PTRLOG PTR 1b, efault PTR 2b, efault PTR 3b, efault diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/traps.c linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/traps.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/traps.c 2003-12-16 03:57:14.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/traps.c 2004-02-15 04:01:06.000000000 +0000 @@ -9,7 +9,7 @@ * Copyright (C) 1999 Silicon Graphics, Inc. * Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com * Copyright (C) 2000, 01 MIPS Technologies, Inc. - * Copyright (C) 2002, 2003 Maciej W. Rozycki + * Copyright (C) 2002, 2003, 2004 Maciej W. Rozycki */ #include #include @@ -20,6 +20,7 @@ #include #include +#include #include #include #include @@ -292,6 +293,7 @@ void __declare_dbe_table(void) { __asm__ __volatile__( ".section\t__dbe_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" ".previous" ); } diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/unaligned.c linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/unaligned.c --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/kernel/unaligned.c 2004-01-03 03:56:46.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/kernel/unaligned.c 2004-02-15 04:16:20.000000000 +0000 @@ -85,9 +85,6 @@ #include #include -#define STR(x) __STR(x) -#define __STR(x) #x - #ifdef CONFIG_PROC_FS unsigned long unaligned_instructions; #endif @@ -159,10 +156,12 @@ static inline int emulate_load_store_ins "li\t%1, 0\n" "3:\t.set\tat\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -189,10 +188,12 @@ static inline int emulate_load_store_ins #endif "li\t%1, 0\n" "3:\t.section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -223,10 +224,12 @@ static inline int emulate_load_store_ins "li\t%1, 0\n" "3:\t.set\tat\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -263,10 +266,12 @@ static inline int emulate_load_store_ins "dsrl\t%0, %0, 32\n\t" "li\t%1, 0\n" "3:\t.section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -305,10 +310,12 @@ static inline int emulate_load_store_ins #endif "li\t%1, 0\n" "3:\t.section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%1, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -347,10 +354,12 @@ static inline int emulate_load_store_ins "li\t%0, 0\n" "3:\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%0, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -377,10 +386,12 @@ static inline int emulate_load_store_ins "li\t%0, 0\n" "3:\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%0, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" @@ -415,10 +426,12 @@ static inline int emulate_load_store_ins "li\t%0, 0\n" "3:\n\t" ".section\t.fixup,\"ax\"\n\t" + ".p2align\t2\n" "4:\tli\t%0, %3\n\t" "j\t3b\n\t" ".previous\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b, 4b\n\t" STR(PTR)"\t2b, 4b\n\t" ".previous" diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/memcpy.S linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/memcpy.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/memcpy.S 2003-06-28 02:56:53.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/memcpy.S 2004-02-15 13:55:03.000000000 +0000 @@ -73,6 +73,7 @@ #define EXC(inst_reg,addr,handler) \ 9: inst_reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/memset.S linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/memset.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/memset.S 2002-08-06 02:57:38.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/memset.S 2004-02-15 13:55:09.000000000 +0000 @@ -15,6 +15,7 @@ #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/strlen_user.S linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/strlen_user.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/strlen_user.S 2002-12-11 03:56:45.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/strlen_user.S 2004-02-15 13:55:13.000000000 +0000 @@ -14,6 +14,7 @@ #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/strncpy_user.S linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/strncpy_user.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/strncpy_user.S 2002-12-11 03:56:45.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/strncpy_user.S 2004-02-15 13:55:16.000000000 +0000 @@ -13,6 +13,7 @@ #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/strnlen_user.S linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/strnlen_user.S --- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/lib/strnlen_user.S 2002-12-11 03:56:45.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/arch/mips64/lib/strnlen_user.S 2004-02-15 13:55:20.000000000 +0000 @@ -14,6 +14,7 @@ #define EX(insn,reg,addr,handler) \ 9: insn reg, addr; \ .section __ex_table,"a"; \ + .p2align PTRLOG; \ PTR 9b, handler; \ .previous diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/asm.h linux-mips-2.4.24-pre2-20040116/include/asm-mips/asm.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/asm.h 2003-12-31 03:57:05.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips/asm.h 2004-02-15 04:01:41.000000000 +0000 @@ -29,6 +29,11 @@ #define CAT(str1,str2) __CAT(str1,str2) #endif +#ifndef STR +#define STR(x) __STR(x) +#define __STR(x) #x +#endif + /* * PIC specific declarations * Not used for the kernel but here seems to be the right place. diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/paccess.h linux-mips-2.4.24-pre2-20040116/include/asm-mips/paccess.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/paccess.h 2002-07-06 23:48:37.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips/paccess.h 2004-02-15 05:18:36.000000000 +0000 @@ -14,6 +14,7 @@ #define _ASM_PACCESS_H #include +#include #define put_dbe(x,ptr) __put_dbe((x),(ptr),sizeof(*(ptr))) #define get_dbe(x,ptr) __get_dbe((x),(ptr),sizeof(*(ptr))) @@ -45,13 +46,15 @@ __asm__ __volatile__( \ "1:\tmove\t%0,$0\n" \ ".set\tpop\n\t" \ "2:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "3:\tli\t%0,%3\n\t" \ "move\t%1,$0\n\t" \ "j\t2b\n\t" \ ".previous\n\t" \ ".section\t__dbe_table,\"a\"\n\t" \ - ".word\t1b-4,3b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b-4,3b\n\t" \ ".previous" \ :"=r" (__gu_err), "=r" (__gu_val) \ :"o" (__mp(__gu_addr)), "i" (-EFAULT)); }) @@ -82,12 +85,14 @@ __asm__ __volatile__( \ "1:\tmove\t%0,$0\n" \ ".set\tpop\n\t" \ "2:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "3:\tli\t%0,%3\n\t" \ "j\t2b\n\t" \ ".previous\n\t" \ ".section\t__dbe_table,\"a\"\n\t" \ - ".word\t1b-4,3b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b-4,3b\n\t" \ ".previous" \ :"=r" (__pu_err) \ :"r" (__pu_val), "o" (__mp(__pu_addr)), "i" (-EFAULT)); }) diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/r4kcache.h linux-mips-2.4.24-pre2-20040116/include/asm-mips/r4kcache.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/r4kcache.h 2004-01-05 03:57:13.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips/r4kcache.h 2004-02-15 04:24:10.000000000 +0000 @@ -77,6 +77,7 @@ static inline void protected_flush_icach "2:\t.set mips0\n\t" ".set reorder\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b,2b\n\t" ".previous" : @@ -98,6 +99,7 @@ static inline void protected_writeback_d "2:\t.set mips0\n\t" ".set reorder\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b,2b\n\t" ".previous" : diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/uaccess.h linux-mips-2.4.24-pre2-20040116/include/asm-mips/uaccess.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/uaccess.h 2004-02-13 06:26:20.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips/uaccess.h 2004-02-15 05:19:03.000000000 +0000 @@ -13,8 +13,7 @@ #include #include -#define STR(x) __STR(x) -#define __STR(x) #x +#include /* * The fs value determines whether argument validity checking should be @@ -239,13 +238,15 @@ struct __large_struct { unsigned long bu "1:\t" insn "\t%1,%2\n\t" \ "move\t%0,$0\n" \ "2:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "3:\tli\t%0,%3\n\t" \ "move\t%1,$0\n\t" \ "j\t2b\n\t" \ ".previous\n\t" \ ".section\t__ex_table,\"a\"\n\t" \ - ".word\t1b,3b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b,3b\n\t" \ ".previous" \ :"=r" (__gu_err), "=r" (__gu_val) \ :"o" (__m(__gu_addr)), "i" (-EFAULT)); \ @@ -260,15 +261,18 @@ __asm__ __volatile__( \ "1:\tlw\t%1,%2\n" \ "2:\tlw\t%D1,%3\n\t" \ "move\t%0,$0\n" \ - "3:\t.section\t.fixup,\"ax\"\n" \ + "3:\n\t" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "4:\tli\t%0,%4\n\t" \ "move\t%1,$0\n\t" \ "move\t%D1,$0\n\t" \ "j\t3b\n\t" \ ".previous\n\t" \ ".section\t__ex_table,\"a\"\n\t" \ - ".word\t1b,4b\n\t" \ - ".word\t2b,4b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b,4b\n\t" \ + STR(PTR) "\t2b,4b\n\t" \ ".previous" \ :"=r" (__gu_err), "=&r" (__gu_val) \ :"o" (__m(__gu_addr)), "o" (__m(__gu_addr + 4)), \ @@ -331,12 +335,14 @@ extern void __get_user_unknown(void); "1:\t" insn "\t%z1, %2\t\t\t# __put_user_asm\n\t" \ "move\t%0, $0\n" \ "2:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "3:\tli\t%0, %3\n\t" \ "j\t2b\n\t" \ ".previous\n\t" \ ".section\t__ex_table,\"a\"\n\t" \ - ".word\t1b, 3b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b,3b\n\t" \ ".previous" \ :"=r" (__pu_err) \ :"Jr" (__pu_val), "o" (__m(__pu_addr)), "i" (-EFAULT)); \ @@ -349,13 +355,15 @@ __asm__ __volatile__( \ "2:\tsw\t%D1, %3\n" \ "move\t%0, $0\n" \ "3:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "4:\tli\t%0, %4\n\t" \ "j\t3b\n\t" \ ".previous\n\t" \ ".section\t__ex_table,\"a\"\n\t" \ - ".word\t1b,4b\n\t" \ - ".word\t2b,4b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b,4b\n\t" \ + STR(PTR) "\t2b,4b\n\t" \ ".previous" \ :"=r" (__pu_err) \ :"r" (__pu_val), "o" (__m(__pu_addr)), "o" (__m(__pu_addr + 4)),\ diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/asm.h linux-mips-2.4.24-pre2-20040116/include/asm-mips64/asm.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/asm.h 2003-12-31 03:57:06.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips64/asm.h 2004-02-15 04:02:27.000000000 +0000 @@ -29,6 +29,11 @@ #define CAT(str1,str2) __CAT(str1,str2) #endif +#ifndef STR +#define STR(x) __STR(x) +#define __STR(x) #x +#endif + /* * PIC specific declarations * Not used for the kernel but here seems to be the right place. diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/paccess.h linux-mips-2.4.24-pre2-20040116/include/asm-mips64/paccess.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/paccess.h 2002-07-07 10:08:24.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips64/paccess.h 2004-02-15 05:18:41.000000000 +0000 @@ -14,6 +14,7 @@ #define _ASM_PACCESS_H #include +#include #define put_dbe(x,ptr) __put_dbe((x),(ptr),sizeof(*(ptr))) #define get_dbe(x,ptr) __get_dbe((x),(ptr),sizeof(*(ptr))) @@ -42,13 +43,15 @@ __asm__ __volatile__( \ "1:\t" insn "\t%1,%2\n\t" \ "move\t%0,$0\n" \ "2:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "3:\tli\t%0,%3\n\t" \ "move\t%1,$0\n\t" \ "j\t2b\n\t" \ ".previous\n\t" \ ".section\t__dbe_table,\"a\"\n\t" \ - ".dword\t1b,3b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b,3b\n\t" \ ".previous" \ :"=r" (__gu_err), "=r" (__gu_val) \ :"o" (__mp(__gu_addr)), "i" (-EFAULT)); }) @@ -76,12 +79,14 @@ __asm__ __volatile__( \ "1:\t" insn "\t%1,%2\n\t" \ "move\t%0,$0\n" \ "2:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "3:\tli\t%0,%3\n\t" \ "j\t2b\n\t" \ ".previous\n\t" \ ".section\t__dbe_table,\"a\"\n\t" \ - ".dword\t1b,3b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b,3b\n\t" \ ".previous" \ :"=r" (__pu_err) \ :"r" (__pu_val), "o" (__mp(__pu_addr)), "i" (-EFAULT)); }) diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/r4kcache.h linux-mips-2.4.24-pre2-20040116/include/asm-mips64/r4kcache.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/r4kcache.h 2004-01-05 03:57:15.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips64/r4kcache.h 2004-02-15 04:24:26.000000000 +0000 @@ -77,6 +77,7 @@ static inline void protected_flush_icach "2:\t.set mips0\n\t" ".set reorder\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b,2b\n\t" ".previous" : @@ -98,6 +99,7 @@ static inline void protected_writeback_d "2:\t.set mips0\n\t" ".set reorder\n\t" ".section\t__ex_table,\"a\"\n\t" + ".p2align\t" STR(PTRLOG) "\n\t" STR(PTR)"\t1b,2b\n\t" ".previous" : diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/uaccess.h linux-mips-2.4.24-pre2-20040116/include/asm-mips64/uaccess.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/uaccess.h 2003-09-15 02:57:28.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips64/uaccess.h 2004-02-15 05:18:54.000000000 +0000 @@ -13,8 +13,7 @@ #include #include -#define STR(x) __STR(x) -#define __STR(x) #x +#include /* * The fs value determines whether argument validity checking should be @@ -229,13 +228,15 @@ struct __large_struct { unsigned long bu "1:\t" insn "\t%1,%2\n\t" \ "move\t%0,$0\n" \ "2:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "3:\tli\t%0,%3\n\t" \ "move\t%1,$0\n\t" \ "j\t2b\n\t" \ ".previous\n\t" \ ".section\t__ex_table,\"a\"\n\t" \ - ".dword\t1b,3b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b,3b\n\t" \ ".previous" \ :"=r" (__gu_err), "=r" (__gu_val) \ :"o" (__m(__gu_addr)), "i" (-EFAULT)); \ @@ -287,12 +288,14 @@ extern void __get_user_unknown(void); "1:\t" insn "\t%z1, %2\t\t\t# __put_user_asm\n\t" \ "move\t%0, $0\n" \ "2:\n\t" \ - ".section\t.fixup,\"ax\"\n" \ + ".section\t.fixup,\"ax\"\n\t" \ + ".p2align\t2\n" \ "3:\tli\t%0, %3\n\t" \ "j\t2b\n\t" \ ".previous\n\t" \ ".section\t__ex_table,\"a\"\n\t" \ - ".dword\t1b, 3b\n\t" \ + ".p2align\t" STR(PTRLOG) "\n\t" \ + STR(PTR) "\t1b,3b\n\t" \ ".previous" \ :"=r" (__pu_err) \ :"Jr" (__pu_val), "o" (__m(__pu_addr)), "i" (-EFAULT)); \ From jsun@orion.mvista.com Mon Feb 16 17:44:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Feb 2004 17:44:57 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:65007 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Mon, 16 Feb 2004 17:44:57 +0000 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i1GHirtS011719; Mon, 16 Feb 2004 09:44:53 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i1GHiqhe011717; Mon, 16 Feb 2004 09:44:52 -0800 Date: Mon, 16 Feb 2004 09:44:52 -0800 From: Jun Sun To: Kaz Sasayama Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: Linux 2.6 on DDB5477? Message-ID: <20040216174452.GA11711@mvista.com> References: <067BC2F8.2E443D82.001F92DE@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <067BC2F8.2E443D82.001F92DE@netscape.net> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4372 X-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 Mon, Feb 16, 2004 at 12:19:32AM -0500, Kaz Sasayama wrote: > Is anyone working on DDB5477 config of Linux 2.6? I tried to compile it > but got many errors that I could not fix completely. If there is a working > patch, please let me know. > It basically works fine here, with a couple of known issues: . sound driver is broken. Just comment it out. . if you use rockhopper baseboard, you will the following patch to access the ethernet on baseboard. [Ralf, we need to fix origin and apply this patch somehow] . under long time stress test, ether driver may go down. Jun diff -u -r1.25 pci.c --- arch/mips/pci/pci.c 19 Jan 2004 16:28:13 -0000 1.25 +++ arch/mips/pci/pci.c 16 Feb 2004 17:41:38 -0000 @@ -166,7 +166,7 @@ pci_read_config_word(dev, PCI_COMMAND, &cmd); old_cmd = cmd; - for(idx=0; idx<6; idx++) { + for(idx=0; idx< PCI_NUM_RESOURCES; idx++) { /* Only set up the requested stuff */ if (!(mask & (1<; Tue, 17 Feb 2004 12:50:44 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 092BE4C3C4; Tue, 17 Feb 2004 13:50:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id E7113477F0; Tue, 17 Feb 2004 13:50:41 +0100 (CET) Date: Tue, 17 Feb 2004 13:50:41 +0100 (CET) From: "Maciej W. Rozycki" To: Thiemo Seufer Cc: David Daney , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4 In-Reply-To: <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: References: <20040213145316.GA23810@linux-mips.org> <20040213222253.GA20118@rembrandt.csv.ica.uni-stuttgart.de> <402D513F.8080205@avtrex.com> <20040213224959.GB20118@rembrandt.csv.ica.uni-stuttgart.de> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Fri, 13 Feb 2004, Thiemo Seufer wrote: > The inline version isn't dead code, and gcc isn't allowed to reschedule > code around a __asm__ __volatile__, so the patch should be ok. Note that it's a valid point gcc can do whatever it wants in the prologue as long as it conforms to the ABI. Wrt static registers it only needs to make sure they are restored in the epilogue (and that's exactly what happens for "s8"); then after saving them in the prologue, it can use them, possibly destructibly, as we don't express (nor have a way to) the need to have them preserved from the entry point. I think we could have a gcc extension to express certain function arguments are the entry values of registers (e.g. by specifying "asm("foo")" like it can be done for variables), but currently there's no such option. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From nilanjan@genesis-microchip.com Tue Feb 17 14:56:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Feb 2004 14:56:29 +0000 (GMT) Received: from [IPv6:::ffff:209.47.22.60] ([IPv6:::ffff:209.47.22.60]:5534 "EHLO torexcl1.gmi.domain") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 17 Feb 2004 14:56:28 +0000 Received: from INDIAEXCH ([10.41.1.181]) by torexcl1.gmi.domain with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Feb 2004 09:56:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: Linux booting on malta board MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Date: Tue, 17 Feb 2004 20:26:21 +0530 Message-ID: <9A45247F1AEBB94189B16E7083981F930588A9@INDIAEXCH.gmi.domain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux booting on malta board Thread-Index: AcP1ZJMVsdo19DqpT5SmE/2jzAwMnQAAJnTAAAA++nA= From: "Nilanjan Roychowdhury" To: X-OriginalArrivalTime: 17 Feb 2004 14:56:27.0263 (UTC) FILETIME=[381140F0:01C3F566] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nilanjan@genesis-microchip.com Precedence: bulk X-list: linux-mips I have a MIPS based malta board. For this board I also have two LINUX images. One the non real time flavor obtained from MIPS technologies and other is a small footprint embedded image from monta vista. I have first booted the board with the monitor program and then tried to download the linux images from my linux host using NFS + TFTP. Now I am able to load the images but when I say go in the monitor prompt...it shows me a message like "LINUX started" in my mincom screen @ host ;also the LED on the board shows "LINUX" but after that the board just hangs. ( it does not respond to any ping ). The same problem occurs with both the non real time as well as the image from monta vista. Have you ever faced any such issues??? Any first hand comments??? Regards Nilanjan From jsun@orion.mvista.com Tue Feb 17 17:37:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Feb 2004 17:37:20 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:44532 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Tue, 17 Feb 2004 17:37:19 +0000 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i1HHbHtS015311; Tue, 17 Feb 2004 09:37:17 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i1HHbHjI015309; Tue, 17 Feb 2004 09:37:17 -0800 Date: Tue, 17 Feb 2004 09:37:17 -0800 From: Jun Sun To: Nilanjan Roychowdhury Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: Linux booting on malta board Message-ID: <20040217173717.GA15296@mvista.com> References: <9A45247F1AEBB94189B16E7083981F930588A9@INDIAEXCH.gmi.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A45247F1AEBB94189B16E7083981F930588A9@INDIAEXCH.gmi.domain> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4375 X-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, Feb 17, 2004 at 08:26:21PM +0530, Nilanjan Roychowdhury wrote: > > > > > I have a MIPS based malta board. For this board I also have two LINUX images. One the non real time flavor obtained from MIPS technologies and other is a small footprint embedded image from monta vista. > > I have first booted the board with the monitor program and then tried to download the linux images from my linux host using NFS + TFTP. > Now I am able to load the images but when I say go in the monitor prompt...it shows me a message like "LINUX started" in my mincom screen @ host ;also the LED on the board shows "LINUX" but after that the board just hangs. ( it does not respond to any ping ). > The same problem occurs with both the non real time as well as the image from monta vista. > > > Have you ever faced any such issues??? Any first hand comments??? What is your cpu and the cpu daughter board? What is the version of kernel? It is possible they might mistmatch in your case. MontaVista's image was tested against 4kc and 5kc cpu boards. Jun From flo@paradigm.rfc822.org Tue Feb 17 21:05:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Feb 2004 21:05:11 +0000 (GMT) Received: from noose.gt.owl.de ([IPv6:::ffff:62.52.19.4]:2832 "EHLO noose.gt.owl.de") by linux-mips.org with ESMTP id ; Tue, 17 Feb 2004 21:05:05 +0000 Received: by noose.gt.owl.de (Postfix, from userid 10) id 93DCD25DAE; Tue, 17 Feb 2004 22:05:04 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D129A13831C; Tue, 17 Feb 2004 22:04:31 +0100 (CET) Date: Tue, 17 Feb 2004 22:04:31 +0100 From: Florian Lohoff To: linux-mips@linux-mips.org Subject: CONFIG_MIPS_RTC for lasat Message-ID: <20040217210431.GC11511@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline Organization: rfc822 - pure communication User-Agent: Mutt/1.5.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, it makes sense to set CONFIG_MIPS_RTC in defconfig for lasat as the board specific get/set_ are implemented: retrieving revision 1.1.2.37 diff -u -r1.1.2.37 defconfig-lasat --- arch/mips/defconfig-lasat 11 Feb 2004 15:43:26 -0000 1.1.2.37 +++ arch/mips/defconfig-lasat 17 Feb 2004 21:02:47 -0000 @@ -615,7 +615,7 @@ # CONFIG_AMD_PM768 is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set -# CONFIG_MIPS_RTC is not set +CONFIG_MIPS_RTC=3Dy # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set Flo --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 Heisenberg may have been here. --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAMoHfUaz2rXW+gJcRAiqFAKCfNWlH1isfJtD0Yj74D9+LU0Xj8ACfTpHO uLfDHaCD9h8x44wrVgB4grE= =colK -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar-- From yuasa@hh.iij4u.or.jp Tue Feb 17 23:52:14 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Feb 2004 23:52:15 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:62159 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Tue, 17 Feb 2004 23:52:14 +0000 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 IAA29170; Wed, 18 Feb 2004 08:52:09 +0900 (JST) Received: 4UMDO00 id i1HNq8410747; Wed, 18 Feb 2004 08:52:08 +0900 (JST) Received: 4UMRO00 id i1HNq8511624; Wed, 18 Feb 2004 08:52:08 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Wed, 18 Feb 2004 08:51:59 +0900 From: Yoichi Yuasa To: linux-mips Cc: yuasa@hh.iij4u.or.jp, Ralf Baechle Subject: [PATCH][2.4] Changed common setups for vr41xx Message-Id: <20040218085159.6a133fdc.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4377 X-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, I made a patch for vr41xx. This patch is getting together common setups to one place for vr41xx. It is not good that the same code is in many somewhere else. http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v24/vr41xx_platform-v24.diff Thanks, Yoichi From brian@murphy.dk Wed Feb 18 00:08:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Feb 2004 00:08:30 +0000 (GMT) Received: from [IPv6:::ffff:217.157.140.228] ([IPv6:::ffff:217.157.140.228]:30510 "EHLO valis.localnet") by linux-mips.org with ESMTP id ; Wed, 18 Feb 2004 00:08:30 +0000 Received: from murphy.dk ([10.0.0.105]) by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id i1I08NRc028457; Wed, 18 Feb 2004 01:08:23 +0100 Message-ID: <4032ACF7.7060809@murphy.dk> Date: Wed, 18 Feb 2004 01:08:23 +0100 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: Florian Lohoff CC: linux-mips@linux-mips.org Subject: Re: CONFIG_MIPS_RTC for lasat References: <20040217210431.GC11511@paradigm.rfc822.org> 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: 4378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brian@murphy.dk Precedence: bulk X-list: linux-mips Florian Lohoff wrote: >Hi, >it makes sense to set CONFIG_MIPS_RTC in defconfig for lasat as the >board specific get/set_ are implemented: > >retrieving revision 1.1.2.37 >diff -u -r1.1.2.37 defconfig-lasat >--- arch/mips/defconfig-lasat 11 Feb 2004 15:43:26 -0000 1.1.2.37 >+++ arch/mips/defconfig-lasat 17 Feb 2004 21:02:47 -0000 >@@ -615,7 +615,7 @@ > # CONFIG_AMD_PM768 is not set > # CONFIG_NVRAM is not set > # CONFIG_RTC is not set >-# CONFIG_MIPS_RTC is not set >+CONFIG_MIPS_RTC=y > # CONFIG_DTLK is not set > # CONFIG_R3964 is not set > # CONFIG_APPLICOM is not set > >Flo > > Indeed it does. /Brian From ralf@linux-mips.org Wed Feb 18 13:45:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Feb 2004 13:45:57 +0000 (GMT) Received: from p508B6DA8.dip.t-dialin.net ([IPv6:::ffff:80.139.109.168]:39975 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 18 Feb 2004 13:45:56 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1IDjJex025118; Wed, 18 Feb 2004 14:45:19 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1IDj1Kg025116; Wed, 18 Feb 2004 14:45:01 +0100 Date: Wed, 18 Feb 2004 14:45:01 +0100 From: Ralf Baechle To: Indigodfw Cc: linux-mips@linux-mips.org Subject: Re: question about memory constraint in atomic_add Message-ID: <20040218134501.GA24330@linux-mips.org> References: <20040214151152.80368.qmail@web9502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040214151152.80368.qmail@web9502.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: 4379 X-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 Sat, Feb 14, 2004 at 07:11:52AM -0800, Indigodfw wrote: > 2. Result of (C expression) should go into %xyz > register > So v->counter goes into %1, IOW ll from an int! > > Does not make sense to me. > Why does it work, What am I missing? > I mean in general what is the expression for a m > constraint ptr (because I want ptr to be in regiser) > or *ptr (because I wanna tell compiler that *ptr is > what gets changed) "m" gives you *something* suitable to address a memory object; that isn't necessarily a memory address. On MIPS it can't even be just an address in a register because "m" constraints are used with loads and stores and those only accept the offset(reg) addressing mode. If you want an address use something like "r" (&v->counter), then lw reg,(%xxx). Ralf From Joost@stack.nl Wed Feb 18 15:35:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Feb 2004 15:35:39 +0000 (GMT) Received: from brilsmurf.chem.tue.nl ([IPv6:::ffff:131.155.84.68]:12974 "EHLO brilsmurf.chem.tue.nl") by linux-mips.org with ESMTP id ; Wed, 18 Feb 2004 15:35:33 +0000 Received: from brilsmurf.chem.tue.nl (localhost [127.0.0.1]) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1IFZWvI017061 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 18 Feb 2004 16:35:32 +0100 Received: from localhost (joost@localhost) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1IFZWb5020514 for ; Wed, 18 Feb 2004 16:35:32 +0100 X-Authentication-Warning: brilsmurf.chem.tue.nl: joost owned process doing -bs Date: Wed, 18 Feb 2004 16:35:31 +0100 (CET) From: Joost X-X-Sender: joost@brilsmurf.chem.tue.nl To: linux-mips@linux-mips.org Subject: fore atm card in indy? Message-ID: ReplyTo: Joost@stack.nl User-Agent: 007 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: 4380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Joost@stack.nl Precedence: bulk X-list: linux-mips Hello again, My indy seems to be equipped with a Fore ATM device (GIA-200). Would someone know if there is a way to get it back into action? Thank you for your time. Greetings, Joost -- As long as the answer is right, who cares if the question is wrong? From indigodfw@yahoo.com Thu Feb 19 00:11:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Feb 2004 00:11:40 +0000 (GMT) Received: from web9503.mail.yahoo.com ([IPv6:::ffff:216.136.129.133]:47499 "HELO web9503.mail.yahoo.com") by linux-mips.org with SMTP id ; Thu, 19 Feb 2004 00:11:39 +0000 Message-ID: <20040219001132.30180.qmail@web9503.mail.yahoo.com> Received: from [128.107.253.38] by web9503.mail.yahoo.com via HTTP; Wed, 18 Feb 2004 16:11:32 PST Date: Wed, 18 Feb 2004 16:11:32 -0800 (PST) From: Indigodfw Subject: Re: question about memory constraint in atomic_add To: Ralf Baechle Cc: linux-mips@linux-mips.org In-Reply-To: <20040218134501.GA24330@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: 4381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: indigodfw@yahoo.com Precedence: bulk X-list: linux-mips Hi Ralf Thanks for response, but I did not understand your point. Please read inline. --- Ralf Baechle wrote: > On Sat, Feb 14, 2004 at 07:11:52AM -0800, Indigodfw > wrote: > > > 2. Result of (C expression) should go into %xyz > > register > > So v->counter goes into %1, IOW ll from an int! > > > > Does not make sense to me. > > Why does it work, What am I missing? > > > I mean in general what is the expression for a m > > constraint ptr (because I want ptr to be in > regiser) > > or *ptr (because I wanna tell compiler that *ptr > is > > what gets changed) > > "m" gives you *something* suitable to address a > memory object; that isn't > necessarily a memory address. On MIPS it can't even > be just an address > in a register because "m" constraints are used with > loads and stores and > those only accept the offset(reg) addressing mode. > If you want an address > use something like "r" (&v->counter), then lw > reg,(%xxx). Well, is not that what we want? That is, we want to load (using ll) from &v->counter. Should not the code have been ll %0, 0(%1) where %1 is "=m" (&v->counter) The way I interpret it is: a) %1 will contain address of v->counter b) We would do ll (load with reservation/lock) from %1 which is &v->counter (and not from v->counter) c)We want to tell the compiler that &v->counter is output constraint and it may be modified. (Since compiler does not look inside asm). But I fear that with the syntax "=m" (&v->counter) we are informing the compiler that this ptr itself may be modified instead of its contents. Thanks __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From yuasa@hh.iij4u.or.jp Thu Feb 19 07:41:13 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Feb 2004 07:41:14 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:6358 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Thu, 19 Feb 2004 07:41:13 +0000 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id QAA00298; Thu, 19 Feb 2004 16:41:05 +0900 (JST) Received: 4UMDO01 id i1J7f5805970; Thu, 19 Feb 2004 16:41:05 +0900 (JST) Received: 4UMRO01 id i1J7f4w20964; Thu, 19 Feb 2004 16:41:05 +0900 (JST) from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated) Date: Thu, 19 Feb 2004 16:41:04 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] Fixed build error about NEC Eagle Message-Id: <20040219164104.7951605e.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4382 X-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, I made a patch for NEC Eagle. This patch fixed build error about NEC Eagle. Please apply this patch to v2.6. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-eagle.c linux/arch/mips/pci/fixup-eagle.c --- linux-orig/arch/mips/pci/fixup-eagle.c 2003-11-25 15:28:14.000000000 +0900 +++ linux/arch/mips/pci/fixup-eagle.c 2004-02-19 16:28:42.000000000 +0900 @@ -1,34 +1,14 @@ /* - * FILE NAME - * arch/mips/vr41xx/nec-eagle/pci_fixup.c + * arch/mips/vr41xx/nec-eagle/pci_fixup.c * - * BRIEF MODULE DESCRIPTION - * The NEC Eagle/Hawk Board specific PCI fixups. + * The NEC Eagle/Hawk Board specific PCI fixups. * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * Author: Yoichi Yuasa * - * Copyright 2001,2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * 2001-2002,2004 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. */ #include #include @@ -74,3 +54,7 @@ return irq_tab_eagle[slot][pin]; } + +struct pci_fixup pcibios_fixups[] __initdata = { + { .pass = 0, }, +}; diff -urN -X dontdiff linux-orig/arch/mips/pci/pci-vr41xx.c linux/arch/mips/pci/pci-vr41xx.c --- linux-orig/arch/mips/pci/pci-vr41xx.c 2003-06-13 23:19:56.000000000 +0900 +++ linux/arch/mips/pci/pci-vr41xx.c 2004-02-19 16:15:31.000000000 +0900 @@ -8,7 +8,7 @@ * Author: Yoichi Yuasa * yyuasa@mvista.com or source@mvista.com * - * Copyright 2001,2002 MontaVista Software Inc. + * Copyright 2001-2003 MontaVista Software Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -49,9 +49,7 @@ #include #include -#include "pciu.h" - -extern unsigned long vr41xx_vtclock; +#include "pci-vr41xx.h" static inline int vr41xx_pci_config_access(unsigned char bus, unsigned int devfn, int where) @@ -150,6 +148,7 @@ void __init vr41xx_pciu_init(struct vr41xx_pci_address_map *map) { struct vr41xx_pci_address_space *s; + unsigned long vtclock; u32 config; int n; @@ -169,11 +168,12 @@ udelay(1); /* Select PCI clock */ - if (vr41xx_vtclock < MAX_PCI_CLOCK) + vtclock = vr41xx_get_vtclock_frequency(); + if (vtclock < MAX_PCI_CLOCK) writel(EQUAL_VTCLOCK, PCICLKSELREG); - else if ((vr41xx_vtclock / 2) < MAX_PCI_CLOCK) + else if ((vtclock / 2) < MAX_PCI_CLOCK) writel(HALF_VTCLOCK, PCICLKSELREG); - else if ((vr41xx_vtclock / 4) < MAX_PCI_CLOCK) + else if ((vtclock / 4) < MAX_PCI_CLOCK) writel(QUARTER_VTCLOCK, PCICLKSELREG); else printk(KERN_INFO "Warning: PCI Clock is over 33MHz.\n"); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/pmu.c linux/arch/mips/vr41xx/common/pmu.c --- linux-orig/arch/mips/vr41xx/common/pmu.c 2004-02-01 01:47:09.000000000 +0900 +++ linux/arch/mips/vr41xx/common/pmu.c 2004-02-19 16:09:31.000000000 +0900 @@ -18,6 +18,7 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include +#include #include #include diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c 2004-02-02 11:24:21.000000000 +0900 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c 2004-02-19 16:13:48.000000000 +0900 @@ -1,34 +1,14 @@ /* - * FILE NAME - * arch/mips/vr41xx/nec-eagle/setup.c + * arch/mips/vr41xx/nec-eagle/setup.c * - * BRIEF MODULE DESCRIPTION - * Setup for the NEC Eagle/Hawk board. + * Setup for the NEC Eagle/Hawk board. * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * Author: Yoichi Yuasa * - * Copyright 2001,2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * 2001-2004 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. */ #include #include @@ -99,7 +79,7 @@ }; #endif -static void __init nec_eagle_setup(void) +static int nec_eagle_setup(void) { set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; @@ -134,6 +114,8 @@ vrc4173_preinit(); #endif + + return 0; } early_initcall(nec_eagle_setup); From drow@crack.them.org Thu Feb 19 18:18:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Feb 2004 18:18:22 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:21931 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Thu, 19 Feb 2004 18:18:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Atska-0006Ld-M8; Thu, 19 Feb 2004 13:18:16 -0500 Date: Thu, 19 Feb 2004 13:18:16 -0500 From: Daniel Jacobowitz To: Indigodfw Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: question about memory constraint in atomic_add Message-ID: <20040219181816.GA24189@nevyn.them.org> References: <20040218134501.GA24330@linux-mips.org> <20040219001132.30180.qmail@web9503.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040219001132.30180.qmail@web9503.mail.yahoo.com> User-Agent: Mutt/1.5.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: 4383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Wed, Feb 18, 2004 at 04:11:32PM -0800, Indigodfw wrote: > Well, is not that what we want? > That is, we want to load (using ll) from &v->counter. > > Should not the code have been > ll %0, 0(%1) > where %1 is "=m" (&v->counter) No, it would be ll %0, %1. The result of an m constraint will be a register-and-offset term like 0($13) or 256($13). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From Adam_Kiepul@pmc-sierra.com Thu Feb 19 18:22:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Feb 2004 18:22:48 +0000 (GMT) Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:63957 "HELO mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP id ; Thu, 19 Feb 2004 18:22:48 +0000 Received: (qmail 20387 invoked from network); 19 Feb 2004 18:22:40 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by mother.pmc-sierra.com with SMTP; 19 Feb 2004 18:22:40 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id i1JIMdlR003571 for ; Thu, 19 Feb 2004 10:22:39 -0800 Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id <1B2CDMC6>; Thu, 19 Feb 2004 10:22:39 -0800 Message-ID: <9DFF23E1E33391449FDC324526D1F25901D0A6AB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> From: Adam Kiepul To: "'linux-mips@linux-mips.org'" Subject: IT8172 IDE support in 2.4.24 Date: Thu, 19 Feb 2004 10:17:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Adam_Kiepul@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi, Could anyone please tell me whether the 2.4.24 source actually supports the IDE HDD in the default configuration for the ITE 8172? I have built the kernel and it boots up fine with the NFS root. However, it is unable to mount the root file system on a HDD. When I try to mount the /dev/hda1 while running with NFS root I get the "/dev/hda1 is not a valid block device" message. Am I missing something? Thanks a lot, ------------------- Adam Kiepul Sr. Applications Engineer PMC-Sierra, Microprocessor Division Mission Towers One 3975 Freedom Circle Santa Clara, CA 95054, USA Direct: 408 239 8124 Fax: 408 492 9462 http://www.pmc-sierra.com/processors From baitisj@evolution.com Fri Feb 20 01:42:44 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2004 01:42:44 +0000 (GMT) Received: from mx2.idealab.com ([IPv6:::ffff:64.208.8.4]:58373 "EHLO dirk.pas.idealab.com") by linux-mips.org with ESMTP id ; Fri, 20 Feb 2004 01:42:44 +0000 Received: (qmail 15048 invoked by uid 85); 20 Feb 2004 01:42:30 -0000 Received: from baitisj@evolution.com by dirk.idealab.com with qmail-scanner-1.01 (sweep: 2.6/3.49. . Clean. Processed in 2.682525 secs); 20 Feb 2004 01:42:30 -0000 X-Qmail-Scanner-Mail-From: baitisj@evolution.com via dirk.idealab.com X-Qmail-Scanner: 1.01 (Clean. Processed in 2.682525 secs) Received: from unknown (HELO powerpuff.evo1.pas.lab) (10.1.22.10) by 0 with SMTP; 20 Feb 2004 01:42:28 -0000 Subject: Re: IT8172 IDE support in 2.4.24 From: Jeffrey Baitis Reply-To: baitisj@evolution.com To: Adam Kiepul Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <9DFF23E1E33391449FDC324526D1F25901D0A6AB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> References: <9DFF23E1E33391449FDC324526D1F25901D0A6AB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> Content-Type: text/plain Organization: Message-Id: <1077241347.4164.16.camel@powerpuff.evo1.pas.lab> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 19 Feb 2004 17:42:28 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: baitisj@evolution.com Precedence: bulk X-list: linux-mips Hi Adam: Here's a more generic test. can you try for i in a b c d ; do echo "Trying hd$i"; dd if=/dev/hd$i count=1 of=/dev/null; done Not sure offhand if the ITE 8172 has multiple IDE channels/headers; your HDD may also have an unreadable partition table. Good luck -Jeff On Thu, 2004-02-19 at 10:17, Adam Kiepul wrote: > Hi, > > Could anyone please tell me whether the 2.4.24 source actually supports the IDE HDD in the default configuration for the ITE 8172? > I have built the kernel and it boots up fine with the NFS root. However, it is unable to mount the root file system on a HDD. When I try to mount the /dev/hda1 while running with NFS root I get the "/dev/hda1 is not a valid block device" message. Am I missing something? > > Thanks a lot, > > ------------------- > Adam Kiepul > Sr. Applications Engineer > > PMC-Sierra, Microprocessor Division > Mission Towers One > 3975 Freedom Circle > Santa Clara, CA 95054, USA > Direct: 408 239 8124 > Fax: 408 492 9462 > http://www.pmc-sierra.com/processors -- Jeffrey Baitis From ralf@linux-mips.org Fri Feb 20 12:53:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2004 12:53:18 +0000 (GMT) Received: from p508B7AF5.dip.t-dialin.net ([IPv6:::ffff:80.139.122.245]:41056 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 20 Feb 2004 12:53:17 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1KCr9ex010439 for ; Fri, 20 Feb 2004 13:53:09 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1KCr59L010438 for linux-mips@linux-mips.org; Fri, 20 Feb 2004 13:53:05 +0100 Resent-Message-Id: <200402201253.i1KCr59L010438@fluff.linux-mips.net> Received: from amsfep19-int.chello.nl ([IPv6:::ffff:213.46.243.20]:39259 "EHLO amsfep19-int.chello.nl") by linux-mips.org with ESMTP id ; Fri, 20 Feb 2004 12:48:42 +0000 Received: from callisto.of.borg ([195.162.220.94]) by amsfep19-int.chello.nl (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20040220124834.MYZQ1965.amsfep19-int.chello.nl@callisto.of.borg>; Fri, 20 Feb 2004 13:48:34 +0100 Received: from callisto.of.borg (geert@localhost [127.0.0.1]) by callisto.of.borg (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1KCmKQx004283; Fri, 20 Feb 2004 13:48:20 +0100 Received: (from geert@localhost) by callisto.of.borg (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1KCmHeA004281; Fri, 20 Feb 2004 13:48:17 +0100 Date: Fri, 20 Feb 2004 13:48:17 +0100 Message-Id: <200402201248.i1KCmHeA004281@callisto.of.borg> From: Geert Uytterhoeven To: Linus Torvalds , Andrew Morton , Ralf Baechle Cc: Linux Kernel Development , linux-scsi@vger.kernel.org, Geert Uytterhoeven Subject: [PATCH 407] NCR53C9x slave_{alloc,destroy}() Resent-From: ralf@linux-mips.org Resent-Date: Fri, 20 Feb 2004 13:53:05 +0100 Resent-To: linux-mips@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: 4386 X-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 NCR53C9x: Add missing slave_{alloc,destroy}() (from Kars de Jong and Matthias Urlichs). This affects the following drivers: - Amiga Blizzard 1230, Blizzard 2060, CyberStorm, CyberStorm Mk II, Fastlane, and Oktagon SCSI - DECstation NCR53C94 SCSI - Jazz ESP 100/100a/200 SCSI - Mac 53C9x SCSI - MCA NCR 53c9x SCSI - Sun-3x SCSI (was already fixed on its own) --- linux-2.6.3/drivers/scsi/NCR53C9x.c 2003-11-24 10:45:05.000000000 +0100 +++ linux-m68k-2.6.3/drivers/scsi/NCR53C9x.c 2004-02-06 10:38:27.000000000 +0100 @@ -3615,6 +3615,27 @@ } #endif +int esp_slave_alloc(Scsi_Device *SDptr) +{ + struct esp_device *esp_dev = + kmalloc(sizeof(struct esp_device), GFP_ATOMIC); + + if (!esp_dev) + return -ENOMEM; + memset(esp_dev, 0, sizeof(struct esp_device)); + SDptr->hostdata = esp_dev; + return 0; +} + +void esp_slave_destroy(Scsi_Device *SDptr) +{ + struct NCR_ESP *esp = (struct NCR_ESP *) SDptr->host->hostdata; + + esp->targets_present &= ~(1 << SDptr->id); + kfree(SDptr->hostdata); + SDptr->hostdata = NULL; +} + #ifdef MODULE int init_module(void) { return 0; } void cleanup_module(void) {} --- linux-2.6.3/drivers/scsi/NCR53C9x.h 2004-01-21 22:03:40.000000000 +0100 +++ linux-m68k-2.6.3/drivers/scsi/NCR53C9x.h 2004-02-06 10:38:27.000000000 +0100 @@ -665,4 +665,6 @@ extern int esp_reset(Scsi_Cmnd *); extern int esp_proc_info(struct Scsi_Host *shost, char *buffer, char **start, off_t offset, int length, int inout); +extern int esp_slave_alloc(Scsi_Device *); +extern void esp_slave_destroy(Scsi_Device *); #endif /* !(NCR53C9X_H) */ --- linux-2.6.3/drivers/scsi/blz1230.c 2003-07-29 18:19:08.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/blz1230.c 2004-02-06 10:38:27.000000000 +0100 @@ -333,6 +333,8 @@ .proc_info = esp_proc_info, .name = "Blizzard1230 SCSI IV", .detect = blz1230_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = blz1230_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, --- linux-2.6.3/drivers/scsi/blz2060.c 2003-07-29 18:19:09.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/blz2060.c 2004-02-06 10:38:27.000000000 +0100 @@ -287,6 +287,8 @@ .proc_info = esp_proc_info, .name = "Blizzard2060 SCSI", .detect = blz2060_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = blz2060_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, --- linux-2.6.3/drivers/scsi/cyberstorm.c 2003-07-29 18:19:09.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/cyberstorm.c 2004-02-06 10:38:27.000000000 +0100 @@ -358,6 +358,8 @@ .proc_info = esp_proc_info, .name = "CyberStorm SCSI", .detect = cyber_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = cyber_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, --- linux-2.6.3/drivers/scsi/cyberstormII.c 2003-07-29 18:19:09.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/cyberstormII.c 2004-02-06 10:38:27.000000000 +0100 @@ -295,6 +295,8 @@ .proc_info = esp_proc_info, .name = "CyberStorm Mk II SCSI", .detect = cyberII_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = cyberII_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, --- linux-2.6.3/drivers/scsi/dec_esp.c 2003-07-29 18:19:09.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/dec_esp.c 2004-02-06 10:38:27.000000000 +0100 @@ -124,6 +124,8 @@ .proc_info = &esp_proc_info, .name = "NCR53C94", .detect = dec_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = dec_esp_release, .info = esp_info, .queuecommand = esp_queue, --- linux-2.6.3/drivers/scsi/fastlane.c 2003-07-29 18:19:09.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/fastlane.c 2004-02-06 10:38:27.000000000 +0100 @@ -404,6 +404,8 @@ .proc_info = esp_proc_info, .name = "Fastlane SCSI", .detect = fastlane_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = fastlane_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, --- linux-2.6.3/drivers/scsi/jazz_esp.c 2003-07-29 18:19:10.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/jazz_esp.c 2004-02-06 10:38:27.000000000 +0100 @@ -290,6 +290,8 @@ .proc_info = &esp_proc_info, .name = "ESP 100/100a/200", .detect = jazz_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = jazz_esp_release, .info = esp_info, .queuecommand = esp_queue, --- linux-2.6.3/drivers/scsi/mac_esp.c 2004-01-21 22:03:41.000000000 +0100 +++ linux-m68k-2.6.3/drivers/scsi/mac_esp.c 2004-02-06 10:38:27.000000000 +0100 @@ -734,6 +734,8 @@ .proc_name = "esp", .name = "Mac 53C9x SCSI", .detect = mac_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = mac_esp_release, .info = esp_info, .queuecommand = esp_queue, --- linux-2.6.3/drivers/scsi/mca_53c9x.c 2003-07-29 18:19:10.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/mca_53c9x.c 2004-02-06 10:38:27.000000000 +0100 @@ -448,6 +448,8 @@ .proc_name = "esp", .name = "NCR 53c9x SCSI", .detect = mca_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = mca_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, --- linux-2.6.3/drivers/scsi/oktagon_esp.c 2003-07-29 18:19:10.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/oktagon_esp.c 2004-02-06 10:38:27.000000000 +0100 @@ -595,6 +595,8 @@ .proc_info = &esp_proc_info, .name = "BSC Oktagon SCSI", .detect = oktagon_esp_detect, + .slave_alloc = esp_slave_alloc, + .slave_destroy = esp_slave_destroy, .release = oktagon_esp_release, .queuecommand = esp_queue, .eh_abort_handler = esp_abort, --- linux-2.6.3/drivers/scsi/sun3x_esp.c 2003-07-29 18:19:12.000000000 +0200 +++ linux-m68k-2.6.3/drivers/scsi/sun3x_esp.c 2004-02-06 13:43:34.000000000 +0100 @@ -374,29 +374,6 @@ sp->SCp.ptr = (char *)((unsigned long)sp->SCp.buffer->dvma_address); } - -static int esp_slave_alloc(Scsi_Device *SDptr) -{ - struct esp_device *esp_dev = - kmalloc(sizeof(struct esp_device), GFP_ATOMIC); - - if (!esp_dev) - return -ENOMEM; - memset(esp_dev, 0, sizeof(struct esp_device)); - SDptr->hostdata = esp_dev; - return 0; -} - -static void esp_slave_destroy(Scsi_Device *SDptr) -{ - struct NCR_ESP *esp = (struct NCR_ESP *) SDptr->host->hostdata; - - esp->targets_present &= ~(1 << SDptr->id); - kfree(SDptr->hostdata); - SDptr->hostdata = NULL; -} - - static int sun3x_esp_release(struct Scsi_Host *instance) { /* this code does not support being compiled as a module */ 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 Feb 20 14:21:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2004 14:21:41 +0000 (GMT) Received: from p508B7AF5.dip.t-dialin.net ([IPv6:::ffff:80.139.122.245]:47203 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 20 Feb 2004 14:21:40 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1KELdex012352; Fri, 20 Feb 2004 15:21:39 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1KELcOj012351; Fri, 20 Feb 2004 15:21:38 +0100 Date: Fri, 20 Feb 2004 15:21:38 +0100 From: Ralf Baechle To: Joost Cc: linux-mips@linux-mips.org Subject: Re: fore atm card in indy? Message-ID: <20040220142138.GD23404@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: 4387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 18, 2004 at 04:35:31PM +0100, Joost wrote: > My indy seems to be equipped with a Fore ATM device (GIA-200). > Would someone know if there is a way to get it back into action? You'll not like this answer ... but write a driver :-) It seems many GIO cards are based on already Linux-supported PCI chips, so there's a certain chance this won't even be hard. Ralf From yuasa@hh.iij4u.or.jp Fri Feb 20 16:40:54 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2004 16:40:54 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:29683 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Fri, 20 Feb 2004 16:40:54 +0000 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 BAA21725; Sat, 21 Feb 2004 01:40:50 +0900 (JST) Received: 4UMDO01 id i1KGen800573; Sat, 21 Feb 2004 01:40:49 +0900 (JST) Received: 4UMRO01 id i1KGem706592; Sat, 21 Feb 2004 01:40:49 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Sat, 21 Feb 2004 01:40:34 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] Changed clock function for vr41xx Message-Id: <20040221014034.2144a075.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4388 X-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 Rlaf, I made a patch for vr41xx. This patch changes a clock function for a power management. This patch makes the same change as patch of 2.4 sent before. Please apply this patch to v2.6. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/pci-vr41xx.c linux/arch/mips/pci/pci-vr41xx.c --- linux-orig/arch/mips/pci/pci-vr41xx.c Fri Feb 20 00:49:46 2004 +++ linux/arch/mips/pci/pci-vr41xx.c Sat Feb 21 01:11:22 2004 @@ -159,7 +159,7 @@ writew(0, MPCIINTREG); /* Supply VTClock to PCIU */ - vr41xx_clock_supply(PCIU_CLOCK); + vr41xx_supply_clock(PCIU_CLOCK); /* * Sleep for 1us after setting MSKPPCIU bit in CMUCLKMSK @@ -179,7 +179,7 @@ printk(KERN_INFO "Warning: PCI Clock is over 33MHz.\n"); /* Supply PCI clock by PCI bus */ - vr41xx_clock_supply(PCI_CLOCK); + vr41xx_supply_clock(PCI_CLOCK); /* * Set PCI memory & I/O space address conversion registers diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c --- linux-orig/arch/mips/vr41xx/common/cmu.c Tue Jan 13 08:21:05 2004 +++ linux/arch/mips/vr41xx/common/cmu.c Sat Feb 21 01:07:00 2004 @@ -1,34 +1,23 @@ /* - * FILE NAME - * arch/mips/vr41xx/common/cmu.c + * cmu.c, Clock Mask Unit routines for the NEC VR4100 series. * - * BRIEF MODULE DESCRIPTION - * Clock Mask Unit routines for the NEC VR4100 series. - * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com - * - * Copyright 2001,2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * Copyright (C) 2001-2002 MontaVista Software Inc. + * Author: Yoichi Yuasa + * Copuright (C) 2003-2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* * Changes: @@ -41,6 +30,7 @@ */ #include #include +#include #include #include @@ -67,16 +57,19 @@ #define MSKMAC0 0x0002 #define MSKMAC1 0x0004 -static u32 vr41xx_cmu_base; -static u16 cmuclkmsk, cmuclkmsk2; +static uint32_t cmu_base; +static uint16_t cmuclkmsk, cmuclkmsk2; +static spinlock_t cmu_lock; -#define read_cmuclkmsk() readw(vr41xx_cmu_base) +#define read_cmuclkmsk() readw(cmu_base) #define read_cmuclkmsk2() readw(CMUCLKMSK2) -#define write_cmuclkmsk() writew(cmuclkmsk, vr41xx_cmu_base) +#define write_cmuclkmsk() writew(cmuclkmsk, cmu_base) #define write_cmuclkmsk2() writew(cmuclkmsk2, CMUCLKMSK2) -void vr41xx_clock_supply(unsigned int clock) +void vr41xx_supply_clock(vr41xx_clock_t clock) { + spin_lock_irq(&cmu_lock); + switch (clock) { case PIU_CLOCK: cmuclkmsk |= MSKPIU; @@ -130,10 +123,14 @@ write_cmuclkmsk2(); else write_cmuclkmsk(); + + spin_unlock_irq(&cmu_lock); } -void vr41xx_clock_mask(unsigned int clock) +void vr41xx_mask_clock(vr41xx_clock_t clock) { + spin_lock_irq(&cmu_lock); + switch (clock) { case PIU_CLOCK: cmuclkmsk &= ~MSKPIU; @@ -199,6 +196,8 @@ write_cmuclkmsk2(); else write_cmuclkmsk(); + + spin_unlock_irq(&cmu_lock); } void __init vr41xx_cmu_init(void) @@ -206,14 +205,14 @@ switch (current_cpu_data.cputype) { case CPU_VR4111: case CPU_VR4121: - vr41xx_cmu_base = CMUCLKMSK_TYPE1; + cmu_base = CMUCLKMSK_TYPE1; break; case CPU_VR4122: case CPU_VR4131: - vr41xx_cmu_base = CMUCLKMSK_TYPE2; + cmu_base = CMUCLKMSK_TYPE2; break; case CPU_VR4133: - vr41xx_cmu_base = CMUCLKMSK_TYPE2; + cmu_base = CMUCLKMSK_TYPE2; cmuclkmsk2 = read_cmuclkmsk2(); break; default: @@ -222,4 +221,6 @@ } cmuclkmsk = read_cmuclkmsk(); + + spin_lock_init(&cmu_lock); } 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 Tue Jan 13 08:21:05 2004 +++ linux/arch/mips/vr41xx/common/serial.c Sat Feb 21 01:09:41 2004 @@ -146,7 +146,7 @@ if (early_serial_setup(&s) != 0) printk(KERN_ERR "SIU setup failed!\n"); - vr41xx_clock_supply(SIU_CLOCK); + vr41xx_supply_clock(SIU_CLOCK); vr41xx_serial_ports++; } @@ -172,7 +172,7 @@ if (early_serial_setup(&s) != 0) printk(KERN_ERR "DSIU setup failed!\n"); - vr41xx_clock_supply(DSIU_CLOCK); + vr41xx_supply_clock(DSIU_CLOCK); writew(INTDSIU, MDSIUINTREG); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Sun Feb 1 21:41:46 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Sat Feb 21 01:08:54 2004 @@ -7,7 +7,7 @@ * Copyright (C) 2001, 2002 Paul Mundt * Copyright (C) 2002 MontaVista Software, Inc. * Copyright (C) 2002 TimeSys Corp. - * Copyright (C) 2003 Yoichi Yuasa + * Copyright (C) 2003-2004 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -53,10 +53,8 @@ * Clock Mask Unit */ extern void vr41xx_cmu_init(void); -extern void vr41xx_clock_supply(unsigned int clock); -extern void vr41xx_clock_mask(unsigned int clock); -enum { +typedef enum { PIU_CLOCK, SIU_CLOCK, AIU_CLOCK, @@ -70,7 +68,10 @@ CEU_CLOCK, ETHER0_CLOCK, ETHER1_CLOCK -}; +} vr41xx_clock_t; + +extern void vr41xx_supply_clock(vr41xx_clock_t clock); +extern void vr41xx_mask_clock(vr41xx_clock_t clock); /* * Interrupt Control Unit From kkondaka@yahoo.com Fri Feb 20 21:40:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2004 21:40:36 +0000 (GMT) Received: from web41504.mail.yahoo.com ([IPv6:::ffff:66.218.93.87]:30293 "HELO web41504.mail.yahoo.com") by linux-mips.org with SMTP id ; Fri, 20 Feb 2004 21:40:35 +0000 Message-ID: <20040220214022.71153.qmail@web41504.mail.yahoo.com> Received: from [209.172.118.142] by web41504.mail.yahoo.com via HTTP; Fri, 20 Feb 2004 13:40:22 PST Date: Fri, 20 Feb 2004 13:40:22 -0800 (PST) From: Krishna Kondaka Subject: MIPS SMP Linux 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: 4389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kkondaka@yahoo.com Precedence: bulk X-list: linux-mips Hi, I would like to know if any one is using MIPS SMP Linux in the realworld(i.e., more than just for mips SMP linux development work)? I am specifically interested in broadcom BCM12500s running SMP Linux. If yes, I would like to know their experience in terms of stability and performance. Thanks Krishna __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From yuasa@hh.iij4u.or.jp Sat Feb 21 15:29:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 21 Feb 2004 15:29:57 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:8159 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Sat, 21 Feb 2004 15:29:56 +0000 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 AAA01846; Sun, 22 Feb 2004 00:29:48 +0900 (JST) Received: 4UMDO01 id i1LFTl010580; Sun, 22 Feb 2004 00:29:48 +0900 (JST) Received: 4UMRO00 id i1LFTkD15521; Sun, 22 Feb 2004 00:29:47 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Sun, 22 Feb 2004 00:29:40 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] Update NEC VRC4171 PCMCIA driver Message-Id: <20040222002940.45584db8.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4390 X-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, I updated the patch for VRC4171 PCMCIA driver. This patch exists for v2.6 of linux-mips.org CVS. Please apply this patch. Yoichi diff -urN -X dontdiff linux-orig/drivers/pcmcia/Kconfig linux/drivers/pcmcia/Kconfig --- linux-orig/drivers/pcmcia/Kconfig Tue Feb 10 22:36:21 2004 +++ linux/drivers/pcmcia/Kconfig Sat Feb 21 16:51:46 2004 @@ -109,6 +109,10 @@ bool default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X +config PCMCIA_VRC4171 + tristate "NEC VRC4171 Card Controllers support" + depends on VRC4171 && PCMCIA + config PCMCIA_VRC4173 tristate "NEC VRC4173 CARDU support" depends on CPU_VR41XX && PCI && PCMCIA diff -urN -X dontdiff linux-orig/drivers/pcmcia/Makefile linux/drivers/pcmcia/Makefile --- linux-orig/drivers/pcmcia/Makefile Tue Feb 10 22:36:21 2004 +++ linux/drivers/pcmcia/Makefile Sat Feb 21 16:51:46 2004 @@ -11,6 +11,7 @@ obj-$(CONFIG_HD64465_PCMCIA) += hd64465_ss.o obj-$(CONFIG_PCMCIA_SA1100) += sa1100_cs.o obj-$(CONFIG_PCMCIA_SA1111) += sa1111_cs.o +obj-$(CONFIG_PCMCIA_VRC4171) += vrc4171_card.o obj-$(CONFIG_PCMCIA_VRC4173) += vrc4173_cardu.o obj-$(CONFIG_PCMCIA_AU1X00) += au1x00_ss.o diff -urN -X dontdiff linux-orig/drivers/pcmcia/vrc4171_card.c linux/drivers/pcmcia/vrc4171_card.c --- linux-orig/drivers/pcmcia/vrc4171_card.c Thu Jan 1 09:00:00 1970 +++ linux/drivers/pcmcia/vrc4171_card.c Sat Feb 21 16:51:46 2004 @@ -0,0 +1,744 @@ +/* + * vrc4171_card.c, NEC VRC4171 Card Controller driver for Socket Services. + * + * Copyright (C) 2003 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include + +#include "i82365.h" + +MODULE_DESCRIPTION("NEC VRC4171 Card Controllers driver for Socket Services"); +MODULE_AUTHOR("Yoichi Yuasa "); +MODULE_LICENSE("GPL"); + +#define CARD_MAX_SLOTS 2 +#define CARD_SLOTA 0 +#define CARD_SLOTB 1 +#define CARD_SLOTB_OFFSET 0x40 + +#define CARD_MEM_START 0x10000000 +#define CARD_MEM_END 0x13ffffff +#define CARD_MAX_MEM_OFFSET 0x3ffffff +#define CARD_MAX_MEM_SPEED 1000 + +#define CARD_CONTROLLER_INDEX 0x03e0 +#define CARD_CONTROLLER_DATA 0x03e1 +#define CARD_CONTROLLER_SIZE 2 + /* Power register */ + #define VPP_GET_VCC 0x01 + #define POWER_ENABLE 0x10 + #define CARD_VOLTAGE_SENSE 0x1f + #define VCC_3VORXV_CAPABLE 0x00 + #define VCC_XV_ONLY 0x01 + #define VCC_3V_CAPABLE 0x02 + #define VCC_5V_ONLY 0x03 + #define CARD_VOLTAGE_SELECT 0x2f + #define VCC_3V 0x01 + #define VCC_5V 0x00 + #define VCC_XV 0x02 + #define VCC_STATUS_3V 0x02 + #define VCC_STATUS_5V 0x01 + #define VCC_STATUS_XV 0x03 + #define GLOBAL_CONTROL 0x1e + #define EXWRBK 0x04 + #define IRQPM_EN 0x08 + #define CLRPMIRQ 0x10 + +#define IO_MAX_MAPS 2 +#define MEM_MAX_MAPS 5 + +enum { + SLOT_PROBE = 0, + SLOT_NOPROBE_IO, + SLOT_NOPROBE_MEM, + SLOT_NOPROBE_ALL +}; + +typedef struct vrc4171_socket { + int noprobe; + struct pcmcia_socket pcmcia_socket; + char name[24]; + int csc_irq; + int io_irq; +} vrc4171_socket_t; + +static vrc4171_socket_t vrc4171_sockets[CARD_MAX_SLOTS]; +static int vrc4171_slotb = SLOTB_IS_NONE; +static unsigned int vrc4171_irq; +static uint16_t vrc4171_irq_mask = 0xdeb8; + +static inline uint8_t exca_read_byte(int slot, uint8_t index) +{ + if (slot == CARD_SLOTB) + index += CARD_SLOTB_OFFSET; + + outb(index, CARD_CONTROLLER_INDEX); + return inb(CARD_CONTROLLER_DATA); +} + +static inline uint16_t exca_read_word(int slot, uint8_t index) +{ + uint16_t data; + + if (slot == CARD_SLOTB) + index += CARD_SLOTB_OFFSET; + + outb(index++, CARD_CONTROLLER_INDEX); + data = inb(CARD_CONTROLLER_DATA); + + outb(index, CARD_CONTROLLER_INDEX); + data |= ((uint16_t)inb(CARD_CONTROLLER_DATA)) << 8; + + return data; +} + +static inline uint8_t exca_write_byte(int slot, uint8_t index, uint8_t data) +{ + if (slot == CARD_SLOTB) + index += CARD_SLOTB_OFFSET; + + outb(index, CARD_CONTROLLER_INDEX); + outb(data, CARD_CONTROLLER_DATA); + + return data; +} + +static inline uint16_t exca_write_word(int slot, uint8_t index, uint16_t data) +{ + if (slot == CARD_SLOTB) + index += CARD_SLOTB_OFFSET; + + outb(index++, CARD_CONTROLLER_INDEX); + outb(data, CARD_CONTROLLER_DATA); + + outb(index, CARD_CONTROLLER_INDEX); + outb((uint8_t)(data >> 8), CARD_CONTROLLER_DATA); + + return data; +} + +static inline int search_nonuse_irq(void) +{ + int i; + + for (i = 0; i < 16; i++) { + if (vrc4171_irq_mask & (1 << i)) { + vrc4171_irq_mask &= ~(1 << i); + return i; + } + } + + return -1; +} + +static int pccard_init(struct pcmcia_socket *sock) +{ + vrc4171_socket_t *socket; + unsigned int slot; + + sock->features |= SS_CAP_PCCARD | SS_CAP_PAGE_REGS; + sock->irq_mask = 0; + sock->map_size = 0x1000; + sock->pci_irq = vrc4171_irq; + + slot = sock->sock; + socket = &vrc4171_sockets[slot]; + socket->csc_irq = search_nonuse_irq(); + socket->io_irq = search_nonuse_irq(); + + return 0; +} + +static int pccard_suspend(struct pcmcia_socket *sock) +{ + return -EINVAL; +} + +static int pccard_get_status(struct pcmcia_socket *sock, u_int *value) +{ + unsigned int slot; + uint8_t status, sense; + u_int val = 0; + + if (sock == NULL || sock->sock >= CARD_MAX_SLOTS || value == NULL) + return -EINVAL; + + slot = sock->sock; + + status = exca_read_byte(slot, I365_STATUS); + if (exca_read_byte(slot, I365_INTCTL) & I365_PC_IOCARD) { + if (status & I365_CS_STSCHG) + val |= SS_STSCHG; + } else { + if (!(status & I365_CS_BVD1)) + val |= SS_BATDEAD; + else if ((status & (I365_CS_BVD1 | I365_CS_BVD2)) == I365_CS_BVD1) + val |= SS_BATWARN; + } + if ((status & I365_CS_DETECT) == I365_CS_DETECT) + val |= SS_DETECT; + if (status & I365_CS_WRPROT) + val |= SS_WRPROT; + if (status & I365_CS_READY) + val |= SS_READY; + if (status & I365_CS_POWERON) + val |= SS_POWERON; + + sense = exca_read_byte(slot, CARD_VOLTAGE_SENSE); + switch (sense) { + case VCC_3VORXV_CAPABLE: + val |= SS_3VCARD | SS_XVCARD; + break; + case VCC_XV_ONLY: + val |= SS_XVCARD; + break; + case VCC_3V_CAPABLE: + val |= SS_3VCARD; + break; + default: + /* 5V only */ + break; + } + + *value = val; + + return 0; +} + +static inline u_char get_Vcc_value(uint8_t voltage) +{ + switch (voltage) { + case VCC_STATUS_3V: + return 33; + case VCC_STATUS_5V: + return 50; + default: + break; + } + + return 0; +} + +static inline u_char get_Vpp_value(uint8_t power, u_char Vcc) +{ + if ((power & 0x03) == 0x01 || (power & 0x03) == 0x02) + return Vcc; + + return 0; +} + +static int pccard_get_socket(struct pcmcia_socket *sock, socket_state_t *state) +{ + unsigned int slot; + uint8_t power, voltage, control, cscint; + + if (sock == NULL || sock->sock >= CARD_MAX_SLOTS || state == NULL) + return -EINVAL; + + slot = sock->sock; + + power = exca_read_byte(slot, I365_POWER); + voltage = exca_read_byte(slot, CARD_VOLTAGE_SELECT); + + state->Vcc = get_Vcc_value(voltage); + state->Vpp = get_Vpp_value(power, state->Vcc); + + state->flags = 0; + if (power & POWER_ENABLE) + state->flags |= SS_PWR_AUTO; + if (power & I365_PWR_OUT) + state->flags |= SS_OUTPUT_ENA; + + control = exca_read_byte(slot, I365_INTCTL); + if (control & I365_PC_IOCARD) + state->flags |= SS_IOCARD; + if (!(control & I365_PC_RESET)) + state->flags |= SS_RESET; + + cscint = exca_read_byte(slot, I365_CSCINT); + state->csc_mask = 0; + if (state->flags & SS_IOCARD) { + if (cscint & I365_CSC_STSCHG) + state->flags |= SS_STSCHG; + } else { + if (cscint & I365_CSC_BVD1) + state->csc_mask |= SS_BATDEAD; + if (cscint & I365_CSC_BVD2) + state->csc_mask |= SS_BATWARN; + } + if (cscint & I365_CSC_READY) + state->csc_mask |= SS_READY; + if (cscint & I365_CSC_DETECT) + state->csc_mask |= SS_DETECT; + + return 0; +} + +static inline uint8_t set_Vcc_value(u_char Vcc) +{ + switch (Vcc) { + case 33: + return VCC_3V; + case 50: + return VCC_5V; + } + + /* Small voltage is chosen for safety. */ + return VCC_3V; +} + +static int pccard_set_socket(struct pcmcia_socket *sock, socket_state_t *state) +{ + vrc4171_socket_t *socket; + unsigned int slot; + uint8_t voltage, power, control, cscint; + + if (sock == NULL || sock->sock >= CARD_MAX_SLOTS || + (state->Vpp != state->Vcc && state->Vpp != 0) || + (state->Vcc != 50 && state->Vcc != 33 && state->Vcc != 0)) + return -EINVAL; + + slot = sock->sock; + socket = &vrc4171_sockets[slot]; + + spin_lock_irq(&sock->lock); + + voltage = set_Vcc_value(state->Vcc); + exca_write_byte(slot, CARD_VOLTAGE_SELECT, voltage); + + power = POWER_ENABLE; + if (state->Vpp == state->Vcc) + power |= VPP_GET_VCC; + if (state->flags & SS_OUTPUT_ENA) + power |= I365_PWR_OUT; + exca_write_byte(slot, I365_POWER, power); + + control = 0; + if (state->io_irq != 0) + control |= socket->io_irq; + if (state->flags & SS_IOCARD) + control |= I365_PC_IOCARD; + if (state->flags & SS_RESET) + control &= ~I365_PC_RESET; + else + control |= I365_PC_RESET; + exca_write_byte(slot, I365_INTCTL, control); + + cscint = 0; + exca_write_byte(slot, I365_CSCINT, cscint); + exca_read_byte(slot, I365_CSC); /* clear CardStatus change */ + if (state->csc_mask != 0) + cscint |= socket->csc_irq << 8; + if (state->flags & SS_IOCARD) { + if (state->csc_mask & SS_STSCHG) + cscint |= I365_CSC_STSCHG; + } else { + if (state->csc_mask & SS_BATDEAD) + cscint |= I365_CSC_BVD1; + if (state->csc_mask & SS_BATWARN) + cscint |= I365_CSC_BVD2; + } + if (state->csc_mask & SS_READY) + cscint |= I365_CSC_READY; + if (state->csc_mask & SS_DETECT) + cscint |= I365_CSC_DETECT; + exca_write_byte(slot, I365_CSCINT, cscint); + + spin_unlock_irq(&sock->lock); + + return 0; +} + +static int pccard_set_io_map(struct pcmcia_socket *sock, struct pccard_io_map *io) +{ + unsigned int slot; + uint8_t ioctl, addrwin; + u_char map; + + if (sock == NULL || sock->sock >= CARD_MAX_SLOTS || + io == NULL || io->map >= IO_MAX_MAPS || + io->start > 0xffff || io->stop > 0xffff || io->start > io->stop) + return -EINVAL; + + slot = sock->sock; + map = io->map; + + addrwin = exca_read_byte(slot, I365_ADDRWIN); + if (addrwin & I365_ENA_IO(map)) { + addrwin &= ~I365_ENA_IO(map); + exca_write_byte(slot, I365_ADDRWIN, addrwin); + } + + exca_write_word(slot, I365_IO(map)+I365_W_START, io->start); + exca_write_word(slot, I365_IO(map)+I365_W_STOP, io->stop); + + ioctl = 0; + if (io->speed > 0) + ioctl |= I365_IOCTL_WAIT(map); + if (io->flags & MAP_16BIT) + ioctl |= I365_IOCTL_16BIT(map); + if (io->flags & MAP_AUTOSZ) + ioctl |= I365_IOCTL_IOCS16(map); + if (io->flags & MAP_0WS) + ioctl |= I365_IOCTL_0WS(map); + exca_write_byte(slot, I365_IOCTL, ioctl); + + if (io->flags & MAP_ACTIVE) { + addrwin |= I365_ENA_IO(map); + exca_write_byte(slot, I365_ADDRWIN, addrwin); + } + + return 0; +} + +static int pccard_set_mem_map(struct pcmcia_socket *sock, struct pccard_mem_map *mem) +{ + unsigned int slot; + uint16_t start, stop, offset; + uint8_t addrwin; + u_char map; + + if (sock == NULL || sock->sock >= CARD_MAX_SLOTS || + mem == NULL || mem->map >= MEM_MAX_MAPS || + mem->sys_start < CARD_MEM_START || mem->sys_start > CARD_MEM_END || + mem->sys_stop < CARD_MEM_START || mem->sys_stop > CARD_MEM_END || + mem->sys_start > mem->sys_stop || + mem->card_start > CARD_MAX_MEM_OFFSET || + mem->speed > CARD_MAX_MEM_SPEED) + return -EINVAL; + + slot = sock->sock; + map = mem->map; + + addrwin = exca_read_byte(slot, I365_ADDRWIN); + if (addrwin & I365_ENA_MEM(map)) { + addrwin &= ~I365_ENA_MEM(map); + exca_write_byte(slot, I365_ADDRWIN, addrwin); + } + + start = (mem->sys_start >> 12) & 0x3fff; + if (mem->flags & MAP_16BIT) + start |= I365_MEM_16BIT; + exca_write_word(slot, I365_MEM(map)+I365_W_START, start); + + stop = (mem->sys_stop >> 12) & 0x3fff; + switch (mem->speed) { + case 0: + break; + case 1: + stop |= I365_MEM_WS0; + break; + case 2: + stop |= I365_MEM_WS1; + break; + default: + stop |= I365_MEM_WS0 | I365_MEM_WS1; + break; + } + exca_write_word(slot, I365_MEM(map)+I365_W_STOP, stop); + + offset = (mem->card_start >> 12) & 0x3fff; + if (mem->flags & MAP_ATTRIB) + offset |= I365_MEM_REG; + if (mem->flags & MAP_WRPROT) + offset |= I365_MEM_WRPROT; + exca_write_word(slot, I365_MEM(map)+I365_W_OFF, offset); + + if (mem->flags & MAP_ACTIVE) { + addrwin |= I365_ENA_MEM(map); + exca_write_byte(slot, I365_ADDRWIN, addrwin); + } + + return 0; +} + +static struct pccard_operations vrc4171_pccard_operations = { + .init = pccard_init, + .suspend = pccard_suspend, + .get_status = pccard_get_status, + .get_socket = pccard_get_socket, + .set_socket = pccard_set_socket, + .set_io_map = pccard_set_io_map, + .set_mem_map = pccard_set_mem_map, +}; + +static inline unsigned int get_events(int slot) +{ + unsigned int events = 0; + uint8_t status, csc; + + status = exca_read_byte(slot, I365_STATUS); + csc = exca_read_byte(slot, I365_CSC); + + if (exca_read_byte(slot, I365_INTCTL) & I365_PC_IOCARD) { + if ((csc & I365_CSC_STSCHG) && (status & I365_CS_STSCHG)) + events |= SS_STSCHG; + } else { + if (csc & (I365_CSC_BVD1 | I365_CSC_BVD2)) { + if (!(status & I365_CS_BVD1)) + events |= SS_BATDEAD; + else if ((status & (I365_CS_BVD1 | I365_CS_BVD2)) == I365_CS_BVD1) + events |= SS_BATWARN; + } + } + if ((csc & I365_CSC_READY) && (status & I365_CS_READY)) + events |= SS_READY; + if ((csc & I365_CSC_DETECT) && ((status & I365_CS_DETECT) == I365_CS_DETECT)) + events |= SS_DETECT; + + return events; +} + +static irqreturn_t pccard_interrupt(int irq, void *dev_id, struct pt_regs *regs) +{ + vrc4171_socket_t *socket; + unsigned int events; + irqreturn_t retval = IRQ_NONE; + uint16_t status; + + status = vrc4171_get_irq_status(); + if (status & IRQ_A) { + socket = &vrc4171_sockets[CARD_SLOTA]; + if (socket->noprobe == SLOT_PROBE) { + if (status & (1 << socket->csc_irq)) { + events = get_events(CARD_SLOTA); + if (events != 0) { + pcmcia_parse_events(&socket->pcmcia_socket, events); + retval = IRQ_HANDLED; + } + } + } + } + + if (status & IRQ_B) { + socket = &vrc4171_sockets[CARD_SLOTB]; + if (socket->noprobe == SLOT_PROBE) { + if (status & (1 << socket->csc_irq)) { + events = get_events(CARD_SLOTB); + if (events != 0) { + pcmcia_parse_events(&socket->pcmcia_socket, events); + retval = IRQ_HANDLED; + } + } + } + } + + return retval; +} + +static inline void reserve_using_irq(int slot) +{ + unsigned int irq; + + irq = exca_read_byte(slot, I365_INTCTL); + irq &= 0x0f; + vrc4171_irq_mask &= ~(1 << irq); + + irq = exca_read_byte(slot, I365_CSCINT); + irq = (irq & 0xf0) >> 4; + vrc4171_irq_mask &= ~(1 << irq); +} + +static int __devinit vrc4171_add_socket(int slot) +{ + vrc4171_socket_t *socket; + int retval; + + if (slot >= CARD_MAX_SLOTS) + return -EINVAL; + + socket = &vrc4171_sockets[slot]; + if (socket->noprobe != SLOT_PROBE) { + uint8_t addrwin; + + switch (socket->noprobe) { + case SLOT_NOPROBE_MEM: + addrwin = exca_read_byte(slot, I365_ADDRWIN); + addrwin &= 0x1f; + exca_write_byte(slot, I365_ADDRWIN, addrwin); + break; + case SLOT_NOPROBE_IO: + addrwin = exca_read_byte(slot, I365_ADDRWIN); + addrwin &= 0xc0; + exca_write_byte(slot, I365_ADDRWIN, addrwin); + break; + default: + break; + } + + reserve_using_irq(slot); + + return 0; + } + + sprintf(socket->name, "NEC VRC4171 Card Slot %1c", 'A' + slot); + + socket->pcmcia_socket.ops = &vrc4171_pccard_operations; + + retval = pcmcia_register_socket(&socket->pcmcia_socket); + if (retval != 0) + return retval; + + exca_write_byte(slot, I365_ADDRWIN, 0); + + exca_write_byte(slot, GLOBAL_CONTROL, 0); + + return 0; +} + +static void vrc4171_remove_socket(int slot) +{ + vrc4171_socket_t *socket; + + if (slot >= CARD_MAX_SLOTS) + return; + + socket = &vrc4171_sockets[slot]; + + pcmcia_unregister_socket(&socket->pcmcia_socket); +} + +static int __devinit vrc4171_card_setup(char *options) +{ + if (options == NULL || *options == '\0') + return 0; + + if (strncmp(options, "irq:", 4) == 0) { + int irq; + options += 4; + irq = simple_strtoul(options, &options, 0); + if (irq >= 0 && irq < NR_IRQS) + vrc4171_irq = irq; + + if (*options != ',') + return 0; + options++; + } + + if (strncmp(options, "slota:", 6) == 0) { + options += 6; + if (*options != '\0') { + if (strncmp(options, "memnoprobe", 10) == 0) { + vrc4171_sockets[CARD_SLOTA].noprobe = SLOT_NOPROBE_MEM; + options += 10; + } else if (strncmp(options, "ionoprobe", 9) == 0) { + vrc4171_sockets[CARD_SLOTA].noprobe = SLOT_NOPROBE_IO; + options += 9; + } else if ( strncmp(options, "noprobe", 7) == 0) { + vrc4171_sockets[CARD_SLOTA].noprobe = SLOT_NOPROBE_ALL; + options += 7; + } + + if (*options != ',') + return 0; + options++; + } else + return 0; + + } + + if (strncmp(options, "slotb:", 6) == 0) { + options += 6; + if (*options != '\0') { + if (strncmp(options, "pccard", 6) == 0) { + vrc4171_slotb = SLOTB_IS_PCCARD; + options += 6; + } else if (strncmp(options, "cf", 2) == 0) { + vrc4171_slotb = SLOTB_IS_CF; + options += 2; + } else if (strncmp(options, "flashrom", 8) == 0) { + vrc4171_slotb = SLOTB_IS_FLASHROM; + options += 8; + } else if (strncmp(options, "none", 4) == 0) { + vrc4171_slotb = SLOTB_IS_NONE; + options += 4; + } + + if (*options != ',') + return 0; + options++; + + if (strncmp(options, "memnoprobe", 10) == 0) + vrc4171_sockets[CARD_SLOTB].noprobe = SLOT_NOPROBE_MEM; + if (strncmp(options, "ionoprobe", 9) == 0) + vrc4171_sockets[CARD_SLOTB].noprobe = SLOT_NOPROBE_IO; + if (strncmp(options, "noprobe", 7) == 0) + vrc4171_sockets[CARD_SLOTB].noprobe = SLOT_NOPROBE_ALL; + } + } + + return 0; +} + +__setup("vrc4171_card=", vrc4171_card_setup); + +static int __devinit vrc4171_card_init(void) +{ + int retval, slot; + + vrc4171_set_multifunction_pin(vrc4171_slotb); + + if (request_region(CARD_CONTROLLER_INDEX, CARD_CONTROLLER_SIZE, + "NEC VRC4171 Card Controller") == NULL) + return -EBUSY; + + for (slot = 0; slot < CARD_MAX_SLOTS; slot++) { + if (slot == CARD_SLOTB && vrc4171_slotb == SLOTB_IS_NONE) + break; + + retval = vrc4171_add_socket(slot); + if (retval != 0) + return retval; + } + + retval = request_irq(vrc4171_irq, pccard_interrupt, SA_SHIRQ, + "NEC VRC4171 Card Controller", vrc4171_sockets); + if (retval < 0) { + for (slot = 0; slot < CARD_MAX_SLOTS; slot++) + vrc4171_remove_socket(slot); + + return retval; + } + + printk(KERN_INFO "NEC VRC4171 Card Controller, connected to IRQ %d\n", vrc4171_irq); + + return 0; +} + +static void __devexit vrc4171_card_exit(void) +{ + int slot; + + for (slot = 0; slot < CARD_MAX_SLOTS; slot++) + vrc4171_remove_socket(slot); + + release_region(CARD_CONTROLLER_INDEX, CARD_CONTROLLER_SIZE); +} + +module_init(vrc4171_card_init); +module_exit(vrc4171_card_exit); diff -urN -X dontdiff linux-orig/include/pcmcia/cs_types.h linux/include/pcmcia/cs_types.h --- linux-orig/include/pcmcia/cs_types.h Sun Dec 21 10:45:59 2003 +++ linux/include/pcmcia/cs_types.h Sat Feb 21 16:51:46 2004 @@ -36,7 +36,7 @@ #include #endif -#ifdef __arm__ +#if defined(__arm__) || defined(__mips__) typedef u_int ioaddr_t; #else typedef u_short ioaddr_t; From yuasa@hh.iij4u.or.jp Sat Feb 21 15:31:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 21 Feb 2004 15:31:24 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:16095 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Sat, 21 Feb 2004 15:31:22 +0000 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 AAA01964; Sun, 22 Feb 2004 00:31:19 +0900 (JST) Received: 4UMDO01 id i1LFVJ010592; Sun, 22 Feb 2004 00:31:19 +0900 (JST) Received: 4UMRO00 id i1LFVJD15628; Sun, 22 Feb 2004 00:31:19 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Sun, 22 Feb 2004 00:31:12 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] Moved timer setup to common part for vr41xx Message-Id: <20040222003112.3b3f6173.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4391 X-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, I update a patch for timer of vr41xx. This patch get together setup of dispersed timer to one place. Please apply to v2.6. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c --- linux-orig/arch/mips/vr41xx/casio-e55/setup.c Sun Feb 1 21:41:34 2004 +++ linux/arch/mips/vr41xx/casio-e55/setup.c Sat Feb 21 17:13:54 2004 @@ -24,7 +24,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -46,14 +45,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/rtc.c linux/arch/mips/vr41xx/common/rtc.c --- linux-orig/arch/mips/vr41xx/common/rtc.c Tue Jan 13 08:21:05 2004 +++ linux/arch/mips/vr41xx/common/rtc.c Sat Feb 21 17:13:54 2004 @@ -259,7 +259,7 @@ epoch_time = time; } -void __init vr41xx_time_init(void) +static void __init vr41xx_time_init(void) { switch (current_cpu_data.cputype) { case CPU_VR4111: @@ -291,7 +291,7 @@ rtc_set_time = vr41xx_set_time; } -void __init vr41xx_timer_setup(struct irqaction *irq) +static void __init vr41xx_timer_setup(struct irqaction *irq) { do_gettimeoffset = vr41xx_gettimeoffset; @@ -308,4 +308,10 @@ write_rtc2(ELAPSEDTIME_INT, RTCINTREG); setup_irq(ELAPSEDTIME_IRQ, irq); +} + +void __init vr41xx_rtc_init(void) +{ + board_time_init = vr41xx_time_init; + board_timer_setup = vr41xx_timer_setup; } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c --- linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c Sun Feb 1 21:41:34 2004 +++ linux/arch/mips/vr41xx/ibm-workpad/setup.c Sat Feb 21 17:13:54 2004 @@ -24,7 +24,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -46,14 +45,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Fri Feb 20 00:49:46 2004 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Sat Feb 21 17:13:54 2004 @@ -18,7 +18,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -93,9 +92,6 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - board_irq_init = eagle_irq_init; vr41xx_bcu_init(); @@ -103,6 +99,8 @@ vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_dsiu_init(); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c Sun Feb 1 21:41:34 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c Sat Feb 21 17:13:54 2004 @@ -22,7 +22,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -92,14 +91,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c Sun Feb 1 21:41:34 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c Sat Feb 21 17:13:54 2004 @@ -28,7 +28,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -97,14 +96,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); vr41xx_siu_init(SIU_RS232C, 0); vr41xx_dsiu_init(); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c Sun Feb 1 21:41:34 2004 +++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c Sat Feb 21 17:13:54 2004 @@ -25,7 +25,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -95,14 +94,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c --- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c Sun Feb 1 21:41:34 2004 +++ linux/arch/mips/vr41xx/zao-capcella/setup.c Sat Feb 21 17:13:54 2004 @@ -25,7 +25,6 @@ #include #include -#include #include #ifdef CONFIG_BLK_DEV_INITRD @@ -95,14 +94,13 @@ initrd_end = (unsigned long)&__rd_end; #endif - board_time_init = vr41xx_time_init; - board_timer_setup = vr41xx_timer_setup; - vr41xx_bcu_init(); vr41xx_cmu_init(); vr41xx_pmu_init(); + + vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Sat Feb 21 17:13:46 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Sat Feb 21 17:13:54 2004 @@ -151,6 +151,8 @@ extern void vr41xx_set_tclock_cycle(uint32_t cycles); extern uint32_t vr41xx_read_tclock_counter(void); +extern void vr41xx_rtc_init(void); + /* * General-Purpose I/O Unit */ @@ -226,11 +228,5 @@ }; extern void vr41xx_pciu_init(struct vr41xx_pci_address_map *map); - -/* - * MISC - */ -extern void vr41xx_time_init(void); -extern void vr41xx_timer_setup(struct irqaction *irq); #endif /* __NEC_VR41XX_H */ From juszczec@hotmail.com Sun Feb 22 03:02:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2004 03:02:49 +0000 (GMT) Received: from law10-f39.law10.hotmail.com ([IPv6:::ffff:64.4.15.39]:42505 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Sun, 22 Feb 2004 03:02:46 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 21 Feb 2004 19:02:39 -0800 Received: from 24.209.41.112 by lw10fd.law10.hotmail.msn.com with HTTP; Sun, 22 Feb 2004 03:02:39 GMT X-Originating-IP: [24.209.41.112] X-Originating-Email: [juszczec@hotmail.com] X-Sender: juszczec@hotmail.com From: "Mark and Janice Juszczec" To: linux-mips@linux-mips.org Subject: r3000 instruction set Date: Sun, 22 Feb 2004 03:02:39 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Feb 2004 03:02:39.0476 (UTC) FILETIME=[54C85340:01C3F8F0] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: juszczec@hotmail.com Precedence: bulk X-list: linux-mips Hi folks I'm working with kaffe on a r3912 cpu. I'm getting an illegal instruction error. I disassembled the kaffe binary and thought I'd find the offending instruction. Unfortunately, I found 2 different lists of r3000 assembler instructions at: http://www.xs4all.nl/~vhouten/mipsel/r3000-isa.html http://www.xs4all.nl/~vhouten/mipsel/appB.html and comparing them against the list of disassembled kaffe instructions gives 2 different results. So, can someone recommend a definitive list of r3000 assembler instructions? Any help would be greatly appreciated. Mark _________________________________________________________________ Find and compare great deals on Broadband access at the MSN High-Speed Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/ From uhler@mips.com Sun Feb 22 03:16:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2004 03:16:12 +0000 (GMT) Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:24061 "EHLO mx.mips.com") by linux-mips.org with ESMTP id ; Sun, 22 Feb 2004 03:16:09 +0000 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.11/8.12.11) with ESMTP id i1M37swW005661; Sat, 21 Feb 2004 19:07:54 -0800 (PST) Received: from gmu-linux (gmu-linux.mips.com [172.20.8.94]) by mercury.mips.com (8.12.11/8.12.11) with ESMTP id i1M3G1J4009677; Sat, 21 Feb 2004 19:16:01 -0800 (PST) Subject: Re: r3000 instruction set From: Michael Uhler To: Mark and Janice Juszczec Cc: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 21 Feb 2004 19:15:49 -0800 Message-Id: <1077419749.27294.2.camel@gmu-linux> Mime-Version: 1.0 X-Spam-Scan: SA 2.63 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: 4393 X-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 Unfortunately, what you want isn't the r3000 instruction list but, instead the 3912 instruction list. While the original r3000 instructions were well-defined, each manufacturer tended to add or subtract certain instructions in each implementation (creating the kind of behavior and questions that you're seeing). So rather than asking for the list, why not just post the disassembly and the pc of the reserved instruction? /gmu On Sat, 2004-02-21 at 19:02, Mark and Janice Juszczec wrote: > Hi folks > > I'm working with kaffe on a r3912 cpu. I'm getting an illegal instruction > error. I disassembled the kaffe binary and thought I'd find the offending > instruction. > > Unfortunately, I found 2 different lists of r3000 assembler instructions at: > > http://www.xs4all.nl/~vhouten/mipsel/r3000-isa.html > http://www.xs4all.nl/~vhouten/mipsel/appB.html > > and comparing them against the list of disassembled kaffe instructions > gives 2 different results. > > So, can someone recommend a definitive list of r3000 assembler instructions? > > Any help would be greatly appreciated. > > Mark > > _________________________________________________________________ > Find and compare great deals on Broadband access at the MSN High-Speed > Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/ > > -- 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 From kevink@mips.com Sun Feb 22 09:31:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2004 09:31:49 +0000 (GMT) Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:3279 "EHLO mx.mips.com") by linux-mips.org with ESMTP id ; Sun, 22 Feb 2004 09:31:46 +0000 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.11/8.12.11) with ESMTP id i1M9NS3Z022289; Sun, 22 Feb 2004 01:23:28 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i1M9VTPa018795; Sun, 22 Feb 2004 01:31:29 -0800 (PST) Message-ID: <002501c3f926$de2695d0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Mark and Janice Juszczec" , References: Subject: Re: r3000 instruction set Date: Sun, 22 Feb 2004 10:32:58 +0100 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: 4396 X-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 Content-Length: 2908 Lines: 52 > I'm working with kaffe on a r3912 cpu. I'm getting an illegal instruction > error. I disassembled the kaffe binary and thought I'd find the offending > instruction. > > Unfortunately, I found 2 different lists of r3000 assembler instructions at: > > http://www.xs4all.nl/~vhouten/mipsel/r3000-isa.html > http://www.xs4all.nl/~vhouten/mipsel/appB.html > > and comparing them against the list of disassembled kaffe instructions > gives 2 different results. > > So, can someone recommend a definitive list of r3000 assembler instructions? Several things here. First,. as Mike pointed out, the 3912 is not an R3000. It's a superset of the original R3000 "MIPS I" instruction set. Interestingly, while the "Appendix B" web page you cite above describes itself as listing the MIPS I instruction, it actually lists some of the MIPS II instructions that are implemented in the R3912. There do seem to be some errors on the first page you cite. For example, it calls out a "subtract unsigned" instruction, which exists, but then gives it a non-existent opcode (subi), and incorrect semantics ("exception possible"). So I would ignore that page. You can get an accurate description of the MIPS32 instruction set from the MIPS Technologies Inc. web pages at http://www.mips.com/content/Documentation/MIPSDocumentation/ProcessorArchitecture/doclibrary though you do need to register to get access. MIPS32 is a superset of MIPS I, but it's a strict superset, so any instructions you see in your R3912 trace should be documented in the MIPS32 spec, with the exeptions of RFE, which was obsoleted by ERET in MIPS III, and the R3912 MADD/MADDU instructions, which were superset extensions which predated the MIPS32 MADD instructions, and which collide with the MIPS32 CLZ instruction decode. I spend some time working on Kaffe for MIPS a couple of years ago, and I remember that there were some hooks to try to manage the ISA level used. For example, I had to fix some stuff around the use of the MIPS IV/MIPS32 conditional move instructions where aren't available in older cores like the R3912 - but I fixed that because I saw that it was broken, not because I was testing on a true MIPS I/II platform. So someone could have screwed up something else somewhere along those lines. Note also that the JIT3 logic has always been slightly broken for MIPS. I spent a week or two trying to hunt it down, disassembling the generated code buffers, and all the errors I saw *seemed* to be due to the generated code assuming that some data structure was initialized with a pointer value that in fact was zero. That may not be what you're seeing, but since everyone who actually uses Kaffe for MIPS configures it with --set-engine=intrp, instructions could be generated by the JIT3 code which are not compatible with older MIPS designs, and people might not have noticed. Regards, Kevin K. From dom@mips.com Sun Feb 22 12:32:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2004 12:32:03 +0000 (GMT) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:14866 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Sun, 22 Feb 2004 12:32:00 +0000 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 1Ausg9-0007Qi-00; Sun, 22 Feb 2004 12:25:49 +0000 Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Auslm-0003F7-00; Sun, 22 Feb 2004 12:31:38 +0000 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16440.41255.372780.360154@doms-laptop.algor.co.uk> Date: Sun, 22 Feb 2004 12:31:35 +0000 To: "Mark and Janice Juszczec" Cc: linux-mips@linux-mips.org Subject: Re: r3000 instruction set In-Reply-To: References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.84, 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: 4397 X-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 Content-Length: 673 Lines: 19 Mark and Janice Juszczec (juszczec@hotmail.com) writes: > I'm working with kaffe on a r3912 cpu. I'm getting an illegal instruction > error. I disassembled the kaffe binary and thought I'd find the offending > instruction. Two suggestions, to make a hat-trick of responses from MIPS. "See MIPS Run" (I'm too modest to mention the author's name) has a pretty accurate list of instructions covering R3000 and 39xx derivatives. Any reasonable GNU assembler knows all the instructions there ever were - and if you look at the table in mips-opc.c, fairly accurately attributed to various instruction set definitions and extensions. -- Dominic Sweetman MIPS Technologies. From dwalton@ddtsm.com Sun Feb 22 13:12:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2004 13:12:26 +0000 (GMT) Received: from cpe-68-118-232-104.ma.charter.com ([IPv6:::ffff:68.118.232.104]:17288 "EHLO shuttle") by linux-mips.org with ESMTP id ; Sun, 22 Feb 2004 13:12:23 +0000 Received: by shuttle (Postfix, from userid 1000) id BA82F92C010; Sun, 22 Feb 2004 08:12:20 -0500 (EST) Date: Sun, 22 Feb 2004 08:12:20 -0500 From: Daniel Walton To: linux-mips@linux-mips.org Subject: Re: MIPS SMP Linux Message-ID: <20040222131219.GA28782@ddtsm.com> Reply-To: Daniel Walton References: <20040220214022.71153.qmail@web41504.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040220214022.71153.qmail@web41504.mail.yahoo.com> User-Agent: Mutt/1.5.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dwalton+mips@ddtsm.com Precedence: bulk X-list: linux-mips Content-Length: 815 Lines: 21 > I would like to know if any one is using MIPS SMP > Linux in the realworld(i.e., more than just for mips > SMP linux development work)? I am specifically > interested in broadcom BCM12500s running SMP Linux. We have been using it on commercially deployed telco grade products for 18 months or more. If you have been talking with Broadcom they can probably provide references for you. I believe a large proportion of their designs are Linux based now. > If yes, I would like to know their experience in terms > of stability and performance. It's stability is fine with SMP. You application code will (should?) crash much more than the kernel will :-) Performance is relative to a lot of factors (board space/power/thermal budget available). It's hard to beat the size/performance offered by the 1250. Daniel From echristo@redhat.com Sun Feb 22 19:14:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2004 19:14:49 +0000 (GMT) Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:39430 "EHLO mx2.redhat.com") by linux-mips.org with ESMTP id ; Sun, 22 Feb 2004 19:14:34 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i1MImgi01698; Sun, 22 Feb 2004 13:48:42 -0500 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 i1MJDUM10909; Sun, 22 Feb 2004 14:13:30 -0500 Received: from [192.168.123.101] (vpn26-9.sfbay.redhat.com [172.16.26.9]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i1MJDTX10744; Sun, 22 Feb 2004 11:13:29 -0800 Subject: Re: r3000 instruction set From: Eric Christopher To: Mark and Janice Juszczec Cc: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1077477186.3636.34.camel@dzur.sfbay.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Sun, 22 Feb 2004 11:13:06 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: echristo@redhat.com Precedence: bulk X-list: linux-mips Content-Length: 465 Lines: 15 > So, can someone recommend a definitive list of r3000 assembler instructions? Other than the responses you've already gotten, likely you'll need to compile with -march=r3900(or -mcpu=r3900 if it's an old toolchain) since the 3900 is missing a couple of r3000 instructions iirc. If it's the 3912 I remember it also doesn't have an fpu, but I could be wrong there. If it is, then you need -msoft-float as well. -eric -- Eric Christopher From kevink@mips.com Sun Feb 22 21:50:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2004 21:50:56 +0000 (GMT) Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:225 "EHLO mx.mips.com") by linux-mips.org with ESMTP id ; Sun, 22 Feb 2004 21:50:53 +0000 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.11/8.12.11) with ESMTP id i1MLgcmi024380; Sun, 22 Feb 2004 13:42:38 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i1MLoigI008025; Sun, 22 Feb 2004 13:50:45 -0800 (PST) Message-ID: <001001c3f98e$2270dcc0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Eric Christopher" , "Mark and Janice Juszczec" Cc: References: <1077477186.3636.34.camel@dzur.sfbay.redhat.com> Subject: Re: r3000 instruction set Date: Sun, 22 Feb 2004 22:52:13 +0100 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: 4401 X-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 Content-Length: 851 Lines: 16 > Other than the responses you've already gotten, likely you'll need to > compile with -march=r3900(or -mcpu=r3900 if it's an old toolchain) since > the 3900 is missing a couple of r3000 instructions iirc. The 3900 family should run MIPS I code compiled for the R3000. > If it's the 3912 I remember it also doesn't have an fpu, but I could be > wrong there. If it is, then you need -msoft-float as well. The 3912 has no FPU, but if you're running on any contemporary MIPS/Linux kernel and library system, you neither need nor want soft-float. The kernel does FP instruction emulation. Running soft-float would make for faster, if larger, code, but requires that the whole system, particularly glibc, be built for soft-float, which is rarely done (and the last time I tried it, didin't quite work with the standard glibc sources out-of-the-box). From sjhill@realitydiluted.com Mon Feb 23 03:03:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 03:03:37 +0000 (GMT) Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:37773 "EHLO real.realitydiluted.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 03:03:34 +0000 Received: from localhost ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian)) id 1Av6NM-0003ew-00; Sun, 22 Feb 2004 21:03:20 -0600 Message-ID: <40396D75.7090405@realitydiluted.com> Date: Sun, 22 Feb 2004 22:03:17 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: Eric Christopher , Mark and Janice Juszczec , linux-mips@linux-mips.org Subject: Re: r3000 instruction set References: <1077477186.3636.34.camel@dzur.sfbay.redhat.com> <001001c3f98e$2270dcc0$10eca8c0@grendel> In-Reply-To: <001001c3f98e$2270dcc0$10eca8c0@grendel> 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: 4404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips Content-Length: 1454 Lines: 33 Kevin D. Kissell wrote: > > The 3900 family should run MIPS I code compiled for the R3000. > Yep. > The 3912 has no FPU, but if you're running on any contemporary > MIPS/Linux kernel and library system, you neither need nor want > soft-float. The kernel does FP instruction emulation. Running soft-float > would make for faster, if larger, code, but requires that the whole > system, particularly glibc, be built for soft-float, which is rarely done > (and the last time I tried it, didin't quite work with the standard > glibc sources out-of-the-box). > Correct. I use the FP emulator in Linux for my TX3917/PR31700 stuff. I have had no problems. Current glibc has assembly code that assumes hardware floating point which is why building for soft-float does not work out of the box. There are probably some patches out there to rectify that. My personal choice, use uClibc (http://uclibc.org/) for your C runtime. I wrote the dynamic linker loader for MIPS and would highly recommend you try it out. I would really like to see more testing of it. Also, I have some documents for the 3912 on my FTP site: ftp://ftp.realitydiluted.com/docs/Toshiba ftp://ftp.realitydiluted.com/docs/Philips It should be noted that the Toshiba TX3912 and the Philips PR31700 are identical cores. There was definitely some cross-licensing going on there. Perhaps Kevin or Dominic would know this in more detail, but it is not really that important. -Steve From echristo@redhat.com Mon Feb 23 03:38:03 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 03:38:06 +0000 (GMT) Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:19721 "EHLO mx2.redhat.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 03:38:00 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i1N3D7i14018; Sun, 22 Feb 2004 22:13:07 -0500 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 i1N3btM24422; Sun, 22 Feb 2004 22:37:56 -0500 Received: from [192.168.123.101] (vpn26-9.sfbay.redhat.com [172.16.26.9]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i1N3btX21577; Sun, 22 Feb 2004 19:37:55 -0800 Subject: Re: r3000 instruction set From: Eric Christopher To: "Kevin D. Kissell" Cc: Mark and Janice Juszczec , linux-mips@linux-mips.org In-Reply-To: <001001c3f98e$2270dcc0$10eca8c0@grendel> References: <1077477186.3636.34.camel@dzur.sfbay.redhat.com> <001001c3f98e$2270dcc0$10eca8c0@grendel> Content-Type: text/plain Message-Id: <1077507447.3636.37.camel@dzur.sfbay.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Sun, 22 Feb 2004 19:37:29 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: echristo@redhat.com Precedence: bulk X-list: linux-mips Content-Length: 463 Lines: 15 On Sun, 2004-02-22 at 13:52, Kevin D. Kissell wrote: > > Other than the responses you've already gotten, likely you'll need to > > compile with -march=r3900(or -mcpu=r3900 if it's an old toolchain) since > > the 3900 is missing a couple of r3000 instructions iirc. > > The 3900 family should run MIPS I code compiled for the R3000. IIRC there were some standard MIPS I instructions that were not on the tx39. -eric -- Eric Christopher From kevink@mips.com Mon Feb 23 07:02:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 07:02:25 +0000 (GMT) Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:61400 "EHLO mx.mips.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 07:02:22 +0000 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.11/8.12.11) with ESMTP id i1N6s4Kt018102; Sun, 22 Feb 2004 22:54:04 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i1N726c8006594; Sun, 22 Feb 2004 23:02:07 -0800 (PST) Message-ID: <001301c3f9db$2c46d720$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Steven J. Hill" Cc: "Eric Christopher" , "Mark and Janice Juszczec" , References: <1077477186.3636.34.camel@dzur.sfbay.redhat.com> <001001c3f98e$2270dcc0$10eca8c0@grendel> <40396D75.7090405@realitydiluted.com> Subject: Re: r3000 instruction set Date: Mon, 23 Feb 2004 08:03:36 +0100 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: 4406 X-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 Content-Length: 1482 Lines: 29 > > The 3912 has no FPU, but if you're running on any contemporary > > MIPS/Linux kernel and library system, you neither need nor want > > soft-float. The kernel does FP instruction emulation. Running soft-float > > would make for faster, if larger, code, but requires that the whole > > system, particularly glibc, be built for soft-float, which is rarely done > > (and the last time I tried it, didin't quite work with the standard > > glibc sources out-of-the-box). > > > Correct. I use the FP emulator in Linux for my TX3917/PR31700 stuff. I > have had no problems. Current glibc has assembly code that assumes hardware > floating point which is why building for soft-float does not work out of > the box. There are probably some patches out there to rectify that. It's been several years, but the last time I dealt with it, it wasn't all that hard to fix if you knew what you were doing, but it was a couple of days' work just the same. > Also, I have some documents for the 3912 on my FTP site: > > ftp://ftp.realitydiluted.com/docs/Toshiba > ftp://ftp.realitydiluted.com/docs/Philips > > It should be noted that the Toshiba TX3912 and the Philips PR31700 are > identical cores. There was definitely some cross-licensing going on there. > Perhaps Kevin or Dominic would know this in more detail, but it is not > really that important. I'm not sure whether any NDAs which may or may not exist would have expired by now, so I'll stick to a "no comment". ;o) From kevink@mips.com Mon Feb 23 07:09:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 07:09:56 +0000 (GMT) Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:41178 "EHLO mx.mips.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 07:09:53 +0000 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.11/8.12.11) with ESMTP id i1N71aKS018448; Sun, 22 Feb 2004 23:01:36 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i1N79hhi007378; Sun, 22 Feb 2004 23:09:44 -0800 (PST) Message-ID: <001901c3f9dc$3a46b6a0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Eric Christopher" Cc: "Mark and Janice Juszczec" , References: <1077477186.3636.34.camel@dzur.sfbay.redhat.com> <001001c3f98e$2270dcc0$10eca8c0@grendel> <1077507447.3636.37.camel@dzur.sfbay.redhat.com> Subject: Re: r3000 instruction set Date: Mon, 23 Feb 2004 08:11:14 +0100 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: 4407 X-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 Content-Length: 714 Lines: 14 > On Sun, 2004-02-22 at 13:52, Kevin D. Kissell wrote: > > > Other than the responses you've already gotten, likely you'll need to > > > compile with -march=r3900(or -mcpu=r3900 if it's an old toolchain) since > > > the 3900 is missing a couple of r3000 instructions iirc. > > > > The 3900 family should run MIPS I code compiled for the R3000. > > IIRC there were some standard MIPS I instructions that were not on the > tx39. I think you may be confusing MIPS I and MIPS II. I'm pretty darn certain that the TX39 inplemented all of MIPS I, most of MIPS II, plus a MADD extension. I'm not going to go instruction counting this morning, but the TX39 spec declares up-front that it's a superset of the R3000A. From echristo@redhat.com Mon Feb 23 07:29:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 07:29:31 +0000 (GMT) Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:21002 "EHLO mx2.redhat.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 07:29:28 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i1N74Zi20014; Mon, 23 Feb 2004 02:04:35 -0500 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 i1N7TOM30513; Mon, 23 Feb 2004 02:29:24 -0500 Received: from [192.168.123.106] (vpn26-1.sfbay.redhat.com [172.16.26.1]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i1N7TNX26050; Sun, 22 Feb 2004 23:29:23 -0800 Subject: Re: r3000 instruction set From: Eric Christopher To: "Kevin D. Kissell" Cc: Mark and Janice Juszczec , linux-mips@linux-mips.org In-Reply-To: <001901c3f9dc$3a46b6a0$10eca8c0@grendel> References: <1077477186.3636.34.camel@dzur.sfbay.redhat.com> <001001c3f98e$2270dcc0$10eca8c0@grendel> <1077507447.3636.37.camel@dzur.sfbay.redhat.com> <001901c3f9dc$3a46b6a0$10eca8c0@grendel> Content-Type: text/plain Message-Id: <1077521360.4719.0.camel@dzur.sfbay.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Sun, 22 Feb 2004 23:29:23 -0800 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: echristo@redhat.com Precedence: bulk X-list: linux-mips Content-Length: 438 Lines: 14 > I think you may be confusing MIPS I and MIPS II. I'm pretty darn certain > that the TX39 inplemented all of MIPS I, most of MIPS II, plus a MADD > extension. I'm not going to go instruction counting this morning, but the > TX39 spec declares up-front that it's a superset of the R3000A. Me either so until I guess the guy says which instruction is at fault we'll leave it be. :) -eric -- Eric Christopher From juszczec@hotmail.com Mon Feb 23 16:56:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 16:56:41 +0000 (GMT) Received: from law10-f123.law10.hotmail.com ([IPv6:::ffff:64.4.15.123]:26128 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 16:56:38 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Feb 2004 08:56:31 -0800 Received: from 63.121.54.5 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 23 Feb 2004 16:56:30 GMT X-Originating-IP: [63.121.54.5] X-Originating-Email: [juszczec@hotmail.com] X-Sender: juszczec@hotmail.com From: "Mark and Janice Juszczec" To: linux-mips@linux-mips.org Cc: uhler@mips.com, kevink@mips.com, dom@mips.com, echristo@redhat.com Subject: RE: r3000 instruction set Date: Mon, 23 Feb 2004 16:56:30 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2004 16:56:31.0039 (UTC) FILETIME=[FC54BCF0:01C3FA2D] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: juszczec@hotmail.com Precedence: bulk X-list: linux-mips Content-Length: 1262 Lines: 58 Hello folks Thanks for all the information. Its all been very useful. Someone suggested posting the message I get. Here it is: >./kaffe-bin FirstClass [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, P0_STATUS=0000500 pid 6: killed (signal 4) >Reading command line: Try again Kernel panic: Attmpted to kill int! Someone else suggested dumping all the assembler instructions. The listing is really long, so I made a unique list of the commands themselves. If someone can tell me how to use the above error message to figure out the command causing the problem, I'd really appreciate it. If that's impossible, can someone tell me which command listed below does not belong? /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-objdump -d kaffe-bin | awk '{print $3}' | sort -u addiu addu b beq beqz blez bne bnez jalr jr lb lbu li lui lw move nop ori sb sll slt sltiu subu sw Finally, can someone tell me where I can get a copy of "See MIPS Run" Thanks again for all the help Mark _________________________________________________________________ Say “good-bye” to spam, viruses and pop-ups with MSN Premium -- free trial offer! http://click.atdmt.com/AVE/go/onm00200359ave/direct/01/ From uhler@mips.com Mon Feb 23 17:11:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 17:11:51 +0000 (GMT) Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:25565 "EHLO mx.mips.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 17:11:48 +0000 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.11/8.12.11) with ESMTP id i1NGxfVE014622; Mon, 23 Feb 2004 08:59:41 -0800 (PST) Received: from uhler-linux.mips.com (uhler-linux [192.168.65.120]) by mercury.mips.com (8.12.11/8.12.11) with ESMTP id i1NH7pwp012959; Mon, 23 Feb 2004 09:07:51 -0800 (PST) Subject: RE: r3000 instruction set From: Michael Uhler To: Mark and Janice Juszczec Cc: linux-mips@linux-mips.org, kevink@mips.com, dom@mips.com, echristo@redhat.com In-Reply-To: References: Content-Type: text/plain Organization: MIPS Technologies, Inc. Message-Id: <1077556071.23710.2.camel@uhler-linux.mips.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 23 Feb 2004 09:07:51 -0800 Content-Transfer-Encoding: 7bit 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: 4410 X-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 Content-Length: 2077 Lines: 76 On Mon, 2004-02-23 at 08:56, Mark and Janice Juszczec wrote: > Hello folks > > Thanks for all the information. Its all been very useful. > > Someone suggested posting the message I get. Here it is: > > >./kaffe-bin FirstClass > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, > P0_STATUS=0000500 > pid 6: killed (signal 4) > >Reading command line: Try again > Kernel panic: Attmpted to kill int! Under the assumption that I'm reading the message right and the instruction is 0x674696a, that is absolutely a reserved instruction (it is decoded as a RegImm format instruction with an illegal rt field. So unless the 3912 implements something at that code point, it's really illegal. I'd check the code generation to see why it's generating that encoding. > > Someone else suggested dumping all the assembler instructions. The listing > is really long, so I made a unique list of the commands themselves. If > someone can tell me how to use the above error message to figure out the > command causing the problem, I'd really appreciate it. If that's > impossible, can someone tell me which command listed below does not belong? > > /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-objdump > -d kaffe-bin | awk '{print $3}' | sort -u > > addiu > addu > b > beq > beqz > blez > bne > bnez > jalr > jr > lb > lbu > li > lui > lw > move > nop > ori > sb > sll > slt > sltiu > subu > sw > > Finally, can someone tell me where I can get a copy of "See MIPS Run" Amazon.com should have it. > > Thanks again for all the help > > Mark > > _________________________________________________________________ > Say good-bye to spam, viruses and pop-ups with MSN Premium -- free trial > offer! http://click.atdmt.com/AVE/go/onm00200359ave/direct/01/ -- Michael Uhler, Chief Technology Officer MIPS Technologies, Inc. Email: uhler@mips.com Pager:uhler_p@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 From macro@ds2.pg.gda.pl Mon Feb 23 17:14:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 17:14:05 +0000 (GMT) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:11937 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 17:14:02 +0000 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 7B84047829; Mon, 23 Feb 2004 18:13:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 67C2C42C; Mon, 23 Feb 2004 18:13:59 +0100 (CET) Date: Mon, 23 Feb 2004 18:13:59 +0100 (CET) From: "Maciej W. Rozycki" To: Mark and Janice Juszczec Cc: linux-mips@linux-mips.org, uhler@mips.com, kevink@mips.com, dom@mips.com, echristo@redhat.com Subject: RE: r3000 instruction set In-Reply-To: Message-ID: References: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Content-Length: 1903 Lines: 53 On Mon, 23 Feb 2004, Mark and Janice Juszczec wrote: > Someone suggested posting the message I get. Here it is: > > >./kaffe-bin FirstClass > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, > P0_STATUS=0000500 > pid 6: killed (signal 4) > >Reading command line: Try again > Kernel panic: Attmpted to kill int! > > Someone else suggested dumping all the assembler instructions. The listing > is really long, so I made a unique list of the commands themselves. If > someone can tell me how to use the above error message to figure out the > command causing the problem, I'd really appreciate it. If that's The causing instructions is 674696a -- depending on the endianness, it's either: 6a697406 ldl t1,29702(s3) which requires at least MIPS III or: 0674696a 0x674696a which is completely invalid. There are a few ways to track the reason down: 1. Figure out which binary or shared library 0x2abb034 belongs to and disassemble the surrounding code. 2. Enable core dumps, run the failing program and do a post-mortem analysis of the resulting dump with gdb. 3. Run the failing program under gdb and see where SIGILL happens. 4. Perhaps others. > impossible, can someone tell me which command listed below does not belong? > > /opt/crosstool/mipsel-unknown-linux-gnu/gcc-3.2.3-glibc-2.2.3/bin/mipsel-unknown-linux-gnu-objdump > -d kaffe-bin | awk '{print $3}' | sort -u You really want "-S" instead of "-d" (there's usually no point to disassemble data) and add "-m mips:isa64" or a similar, suitably high ISA selector (depending on binutils version), so that you get a disassembly of all instructions as opposed to those defined by the MIPS I ISA only. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kevink@mips.com Mon Feb 23 17:19:59 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 17:20:02 +0000 (GMT) Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:28895 "EHLO mx.mips.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 17:19:59 +0000 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.11/8.12.11) with ESMTP id i1NHBfh3015344; Mon, 23 Feb 2004 09:11:41 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i1NHJmuk014205; Mon, 23 Feb 2004 09:19:49 -0800 (PST) Message-ID: <006001c3fa31$74c07fa0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Mark and Janice Juszczec" , Cc: , , References: Subject: Re: r3000 instruction set Date: Mon, 23 Feb 2004 18:21:19 +0100 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.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: 4412 X-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 Content-Length: 793 Lines: 22 > Someone suggested posting the message I get. Here it is: > > >./kaffe-bin FirstClass > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, > P0_STATUS=0000500 > pid 6: killed (signal 4) > >Reading command line: Try again > Kernel panic: Attmpted to kill int! Let me guess. You are running little-endian. The instruction word in memory would be 0x6a697406. Do you think it's a coincidence that 0x6a6974 spells "jit" in ASCII? ;o) The reported address range looks like that where kaffe builds its JITted instruciton buffers in MIPS/Linux. And, like I say, JIT is somewhat broken for MIPS in Kaffe. Which version of the kaffe sources are you building, and have you tried configuring with --with-engine=intrp as I suggested? Regards, Kevin K. From dom@mips.com Mon Feb 23 18:00:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 18:00:38 +0000 (GMT) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:14342 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 18:00:35 +0000 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 1AvKHZ-0006pP-00; Mon, 23 Feb 2004 17:54:17 +0000 Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1AvKN8-0000eq-00; Mon, 23 Feb 2004 18:00:02 +0000 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16442.16284.723633.718662@gladsmuir.mips.com> Date: Mon, 23 Feb 2004 17:59:56 +0000 To: "Mark and Janice Juszczec" Cc: linux-mips@linux-mips.org, uhler@mips.com, kevink@mips.com, dom@mips.com, echristo@redhat.com Subject: RE: r3000 instruction set In-Reply-To: References: X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.843, 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: 4413 X-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 Content-Length: 354 Lines: 16 Mark and Janice, I think Kevin got it right. "jit"... don't you love it. > Finally, can someone tell me where I can get a copy of "See MIPS Run" amazon.com say "ships within 24 hours". But your physical location is a mystery to me, and if you're penguin hackers from Antarctica, that probably won't help... -- Dominic Sweetman MIPS Technologies From kkondaka@yahoo.com Mon Feb 23 20:11:49 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 20:11:53 +0000 (GMT) Received: from web41510.mail.yahoo.com ([IPv6:::ffff:66.218.93.93]:47964 "HELO web41510.mail.yahoo.com") by linux-mips.org with SMTP id ; Mon, 23 Feb 2004 20:11:49 +0000 Message-ID: <20040223201134.72649.qmail@web41510.mail.yahoo.com> Received: from [209.172.118.142] by web41510.mail.yahoo.com via HTTP; Mon, 23 Feb 2004 12:11:34 PST Date: Mon, 23 Feb 2004 12:11:34 -0800 (PST) From: Krishna Kondaka Subject: Re: MIPS SMP Linux To: dwalton+mips@ddtsm.com 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: 4414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kkondaka@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 1269 Lines: 49 Thanks for the reply daniel, >> I would like to know if any one is using MIPS SMP >> Linux in the realworld(i.e., more than just for mips >> SMP linux development work)? I am specifically >> interested in broadcom BCM12500s running SMP Linux. >We have been using it on commercially deployed telco >grade products >for 18 months or more. If you have been talking with >Broadcom they can >probably provide references for you. I believe a >large proportion of >their designs are Linux based now. >> If yes, I would like to know their experience in terms >> of stability and performance. >It's stability is fine with SMP. You application code >will (should?) >crash much more than the kernel will :-) Applications are crashing due to kernel bugs? or due to application bugs? Are the applications crashing more often when run on SMP than on UP kernel? I would appreciate if you could provide more details on what you mean by applications crashing. Thanks Krishna >Performance is relative to a lot of factors (board >space/power/thermal >budget available). It's hard to beat the >size/performance offered by >the 1250. Daniel __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From p2@mind.be Mon Feb 23 20:46:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 20:46:59 +0000 (GMT) Received: from NAT.office.mind.be ([IPv6:::ffff:62.166.230.82]:55940 "EHLO codecarver.intern.mind.be") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 20:46:56 +0000 Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian)) id 1AvMyY-0000Ss-00; Mon, 23 Feb 2004 21:46:50 +0100 Date: Mon, 23 Feb 2004 21:46:50 +0100 To: Ralf Baechle Cc: Joost , linux-mips@linux-mips.org Subject: Re: fore atm card in indy? Message-ID: <20040223204649.GF1046@mind.be> Mail-Followup-To: peter.de.schrijver@mind.be, Ralf Baechle , Joost , linux-mips@linux-mips.org References: <20040220142138.GD23404@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SxgehGEc6vB0cZwN" Content-Disposition: inline In-Reply-To: <20040220142138.GD23404@linux-mips.org> X-Answer: 42 X-Operating-system: Debian GNU/Linux X-Message-Flag: Get yourself a real email client. http://www.mutt.org/ X-mate: Mate, man gewoehnt sich an alles User-Agent: Mutt/1.5.5.1+cvs20040105i From: Peter 'p2' De Schrijver Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: p2@mind.be Precedence: bulk X-list: linux-mips Content-Length: 1135 Lines: 40 --SxgehGEc6vB0cZwN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 20, 2004 at 03:21:38PM +0100, Ralf Baechle wrote: > On Wed, Feb 18, 2004 at 04:35:31PM +0100, Joost wrote: >=20 > > My indy seems to be equipped with a Fore ATM device (GIA-200). > > Would someone know if there is a way to get it back into action? >=20 > You'll not like this answer ... but write a driver :-) >=20 > It seems many GIO cards are based on already Linux-supported PCI chips, > so there's a certain chance this won't even be hard. >=20 There is already a driver for the PCI and SBUS versions of this card. It lives in drivers/atm/fore200e*. You 'only' need to add code for the GIO32 specifics. Cheers, Peter. --SxgehGEc6vB0cZwN 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) iD8DBQFAOma5KLKVw/RurbsRAkpVAJwP3byUqlKkb9jxIbUT8LhwSA3dUACfeeNX Sz4h7iVf0ZpWbG5FB94lL5M= =00w0 -----END PGP SIGNATURE----- --SxgehGEc6vB0cZwN-- From juszczec@hotmail.com Mon Feb 23 20:48:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 20:48:50 +0000 (GMT) Received: from law10-f101.law10.hotmail.com ([IPv6:::ffff:64.4.15.101]:11783 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 20:48:47 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Feb 2004 12:48:39 -0800 Received: from 63.121.54.5 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 23 Feb 2004 20:48:39 GMT X-Originating-IP: [63.121.54.5] X-Originating-Email: [juszczec@hotmail.com] X-Sender: juszczec@hotmail.com From: "Mark and Janice Juszczec" To: kevink@mips.com, linux-mips@linux-mips.org Cc: uhler@mips.com, dom@mips.com, echristo@redhat.com Subject: Re: r3000 instruction set Date: Mon, 23 Feb 2004 20:48:39 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2004 20:48:39.0906 (UTC) FILETIME=[6A952C20:01C3FA4E] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: juszczec@hotmail.com Precedence: bulk X-list: linux-mips Content-Length: 1578 Lines: 48 Kevin Its been a few weeks since I built this version of kaffe. The configure output says I did specify --with-engine=intrp. I'll delete the compiled stuff, reconfigure (double checking that I give it --with-engine=intrp), recompile and retest. I'll post my results. Mark >From: "Kevin D. Kissell" >To: "Mark and Janice Juszczec" , > >CC: , , >Subject: Re: r3000 instruction set >Date: Mon, 23 Feb 2004 18:21:19 +0100 > > > Someone suggested posting the message I get. Here it is: > > > > >./kaffe-bin FirstClass > > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, > > P0_STATUS=0000500 > > pid 6: killed (signal 4) > > >Reading command line: Try again > > Kernel panic: Attmpted to kill int! > >Let me guess. You are running little-endian. The instruction word >in memory would be 0x6a697406. Do you think it's a coincidence >that 0x6a6974 spells "jit" in ASCII? ;o) > >The reported address range looks like that where kaffe builds its >JITted instruciton buffers in MIPS/Linux. And, like I say, JIT is >somewhat broken for MIPS in Kaffe. Which version of the kaffe sources >are you building, and have you tried configuring with --with-engine=intrp >as I suggested? > > Regards, > > Kevin K. _________________________________________________________________ Click, drag and drop. My MSN is the simple way to design your homepage. http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ From kevink@mips.com Mon Feb 23 22:45:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2004 22:45:35 +0000 (GMT) Received: from mx.mips.com ([IPv6:::ffff:206.31.31.226]:57769 "EHLO mx.mips.com") by linux-mips.org with ESMTP id ; Mon, 23 Feb 2004 22:45:32 +0000 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.11/8.12.11) with ESMTP id i1NMbBgs002672; Mon, 23 Feb 2004 14:37:11 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i1NMjH7q025123; Mon, 23 Feb 2004 14:45:18 -0800 (PST) Message-ID: <00a601c3fa5e$ee4fe8b0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Mark and Janice Juszczec" , Cc: , , References: Subject: Re: r3000 instruction set Date: Mon, 23 Feb 2004 23:46:49 +0100 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.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: 4419 X-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 Content-Length: 2257 Lines: 56 Kaffe's makefiles won't pick up on configuration changes, so any time you re-configure for a different engine or debug level, you need to do a make clean. At least, that's the way it was the last time I worked on it. If you had a partial build with JIT, then changed to intrp, then you could get all kinds of strange behavior. The address range of your error us a dead giveaway. It's too high to be the kaffe code segment, but too low to be a shared library. It's where I'd expect the heap to be, and where I remember the JIT buffers being allocated when I was trying to debug that stuff. > Its been a few weeks since I built this version of kaffe. The configure > output says I did specify --with-engine=intrp. I'll delete the compiled > stuff, reconfigure (double checking that I give it --with-engine=intrp), > recompile and retest. > > I'll post my results. > > Mark > > > > >From: "Kevin D. Kissell" > >To: "Mark and Janice Juszczec" , > > > >CC: , , > >Subject: Re: r3000 instruction set > >Date: Mon, 23 Feb 2004 18:21:19 +0100 > > > > > Someone suggested posting the message I get. Here it is: > > > > > > >./kaffe-bin FirstClass > > > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, > > > P0_STATUS=0000500 > > > pid 6: killed (signal 4) > > > >Reading command line: Try again > > > Kernel panic: Attmpted to kill int! > > > >Let me guess. You are running little-endian. The instruction word > >in memory would be 0x6a697406. Do you think it's a coincidence > >that 0x6a6974 spells "jit" in ASCII? ;o) > > > >The reported address range looks like that where kaffe builds its > >JITted instruciton buffers in MIPS/Linux. And, like I say, JIT is > >somewhat broken for MIPS in Kaffe. Which version of the kaffe sources > >are you building, and have you tried configuring with --with-engine=intrp > >as I suggested? > > > > Regards, > > > > Kevin K. > > _________________________________________________________________ > Click, drag and drop. My MSN is the simple way to design your homepage. > http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ > > From alanliu@trident.com.cn Tue Feb 24 05:13:12 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2004 05:13:15 +0000 (GMT) Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:48143 "EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP id ; Tue, 24 Feb 2004 05:13:12 +0000 Received: by TMTMS with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 13:09:48 +0800 Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F680219C648@TMTMS> From: "Liu Hongming (Alan)" To: linux-mips@linux-mips.org Subject: IDE driver problem Date: Tue, 24 Feb 2004 13:09:48 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FA94.6CC96E70" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alanliu@trident.com.cn Precedence: bulk X-list: linux-mips Content-Length: 9997 Lines: 255 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3FA94.6CC96E70 Content-Type: text/plain; charset="ISO-8859-1" Hi All, I am porting IDE drivers(Since my hardware has endian issue), and now it could work,however it has some abnormal problems: I could 'fdisk' /dev/hda,and partition it into several partitions. After this,I reboot my board and see all the partitions is there. Then I 'mke2fs' on /dev/hda1,after this, when using 'fdisk' again, I found all partitions gone! At this time,I could not access /dev/hda1 any more.However, I could 'mount /dev/hda /opt', it really worked,and I could create/read/write/erase files in it. I dumped the first sector of Hard disk and found that it has been zeroed.Now I dont know what the problem is,since I am not familiar with fs parts of linux kernel,and I dont know what 'mke2fs' has done. Any advice? Alan -----Original Message----- From: Kevin D. Kissell [mailto:kevink@mips.com] Sent: Tuesday, February 24, 2004 6:47 AM To: Mark and Janice Juszczec; linux-mips@linux-mips.org Cc: uhler@mips.com; dom@mips.com; echristo@redhat.com Subject: Re: r3000 instruction set Kaffe's makefiles won't pick up on configuration changes, so any time you re-configure for a different engine or debug level, you need to do a make clean. At least, that's the way it was the last time I worked on it. If you had a partial build with JIT, then changed to intrp, then you could get all kinds of strange behavior. The address range of your error us a dead giveaway. It's too high to be the kaffe code segment, but too low to be a shared library. It's where I'd expect the heap to be, and where I remember the JIT buffers being allocated when I was trying to debug that stuff. > Its been a few weeks since I built this version of kaffe. The configure > output says I did specify --with-engine=intrp. I'll delete the compiled > stuff, reconfigure (double checking that I give it --with-engine=intrp), > recompile and retest. > > I'll post my results. > > Mark > > > > >From: "Kevin D. Kissell" > >To: "Mark and Janice Juszczec" , > > > >CC: , , > >Subject: Re: r3000 instruction set > >Date: Mon, 23 Feb 2004 18:21:19 +0100 > > > > > Someone suggested posting the message I get. Here it is: > > > > > > >./kaffe-bin FirstClass > > > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, > > > P0_STATUS=0000500 > > > pid 6: killed (signal 4) > > > >Reading command line: Try again > > > Kernel panic: Attmpted to kill int! > > > >Let me guess. You are running little-endian. The instruction word > >in memory would be 0x6a697406. Do you think it's a coincidence > >that 0x6a6974 spells "jit" in ASCII? ;o) > > > >The reported address range looks like that where kaffe builds its > >JITted instruciton buffers in MIPS/Linux. And, like I say, JIT is > >somewhat broken for MIPS in Kaffe. Which version of the kaffe sources > >are you building, and have you tried configuring with --with-engine=intrp > >as I suggested? > > > > Regards, > > > > Kevin K. > > _________________________________________________________________ > Click, drag and drop. My MSN is the simple way to design your homepage. > http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ > > ------_=_NextPart_001_01C3FA94.6CC96E70 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable IDE driver problem

Hi All,

I am porting IDE drivers(Since my hardware has endian = issue),
and now it could work,however it has some abnormal = problems:

I could 'fdisk'  /dev/hda,and partition it into = several partitions.
After this,I reboot my board and see all the = partitions is there.
Then I 'mke2fs' on /dev/hda1,after this, when using = 'fdisk' again,
I found all partitions gone! At this time,I could = not access /dev/hda1
any more.However, I could 'mount /dev/hda /opt', it = really worked,and
I could create/read/write/erase files in it.

I dumped the first sector of Hard disk and found that = it has been
zeroed.Now I dont know what the problem is,since I = am not familiar
with fs parts of linux kernel,and I dont know what = 'mke2fs' has done.

Any advice?

Alan

-----Original Message-----
From: Kevin D. Kissell [mailto:kevink@mips.com]
Sent: Tuesday, February 24, 2004 6:47 AM
To: Mark and Janice Juszczec; = linux-mips@linux-mips.org
Cc: uhler@mips.com; dom@mips.com; = echristo@redhat.com
Subject: Re: r3000 instruction set


Kaffe's makefiles won't pick up on configuration = changes, so any time
you re-configure for a different engine or debug = level, you need to do
a make clean.  At least, that's the way it was = the last time I worked on it.
If you had a partial build with JIT, then changed to = intrp, then you could
get all kinds of strange behavior.  The address = range of your error us a
dead giveaway.  It's too high to be the kaffe = code segment, but too low
to be a shared library.  It's where I'd expect = the heap to be, and where
I remember the JIT buffers being allocated when I = was trying to debug
that stuff.

> Its been a few weeks since I built this version = of kaffe.  The configure
> output says I did specify = --with-engine=3Dintrp.  I'll delete the compiled
> stuff, reconfigure (double checking that I give = it --with-engine=3Dintrp),
> recompile and retest.
>
> I'll post my results.
>
> Mark
>
>
>
> >From: "Kevin D. Kissell" = <kevink@mips.com>
> >To: "Mark and Janice Juszczec" = <juszczec@hotmail.com>,        =
> ><linux-mips@linux-mips.org>
> >CC: <uhler@mips.com>, = <dom@mips.com>, <echristo@redhat.com>
> >Subject: Re: r3000 instruction set
> >Date: Mon, 23 Feb 2004 18:21:19 = +0100
> >
> > > Someone suggested posting the message = I get.  Here it is:
> > >
> > > >./kaffe-bin FirstClass
> > > [kaffe-bin:6] Illgal instruction = 674696a at 2abb034, ra=3D2adbffd0,
> > > P0_STATUS=3D0000500
> > > pid 6: killed (signal 4)
> > > >Reading command line: Try = again
> > > Kernel panic: Attmpted to kill = int!
> >
> >Let me guess.  You are running = little-endian.  The instruction word
> >in memory would be 0x6a697406.  Do you = think it's a coincidence
> >that 0x6a6974 spells "jit" in = ASCII?  ;o)
> >
> >The reported address range looks like that = where kaffe builds its
> >JITted instruciton buffers in = MIPS/Linux.  And, like I say, JIT is
> >somewhat broken for MIPS in Kaffe.  = Which version of the kaffe sources
> >are you building, and have you tried = configuring with --with-engine=3Dintrp
> >as I suggested?
> >
> = >           &n= bsp; Regards,
> >
> = >           &n= bsp; Kevin K.
>
> = _________________________________________________________________=
> Click, drag and drop. My MSN is the simple way = to design your homepage.
> http://click.atdmt.com/AVE/go/onm00200364ave/direct/01= /
>
>

------_=_NextPart_001_01C3FA94.6CC96E70-- From thomas@corelatus.se Tue Feb 24 11:55:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2004 11:55:59 +0000 (GMT) Received: from [IPv6:::ffff:62.13.60.4] ([IPv6:::ffff:62.13.60.4]:48398 "EHLO mail.swemic.net") by linux-mips.org with ESMTP id ; Tue, 24 Feb 2004 11:55:56 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.swemic.net (Postfix) with ESMTP id 1BD1D75DBB; Tue, 24 Feb 2004 12:55:52 +0100 (CET) Received: from mail.swemic.net ([127.0.0.1]) by localhost (seagle [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 08257-03; Tue, 24 Feb 2004 12:55:38 +0100 (CET) Received: from corelatus.se (skokloster.swemic.net [62.13.60.22]) by mail.swemic.net (Postfix) with ESMTP id AF33775D83; Tue, 24 Feb 2004 12:55:37 +0100 (CET) Message-ID: <403B3BB8.8090403@corelatus.se> Date: Tue, 24 Feb 2004 12:55:36 +0100 From: Thomas Lange User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liu Hongming (Alan)" Cc: linux-mips@linux-mips.org Subject: Re: IDE driver problem References: <15F9E1AE3207D6119CEA00D0B7DD5F680219C648@TMTMS> In-Reply-To: <15F9E1AE3207D6119CEA00D0B7DD5F680219C648@TMTMS> X-Enigmail-Version: 0.82.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hawk.swemic.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4423 X-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@corelatus.se Precedence: bulk X-list: linux-mips Content-Length: 3665 Lines: 97 The partition table is written to the first partition on the device, in your example hda1. Use mke2fs on hda2 and I am sure it work just great. Cheers, /Thomas Liu Hongming (Alan) wrote: > Hi All, > > I am porting IDE drivers(Since my hardware has endian issue), > and now it could work,however it has some abnormal problems: > > I could 'fdisk' /dev/hda,and partition it into several partitions. > After this,I reboot my board and see all the partitions is there. > Then I 'mke2fs' on /dev/hda1,after this, when using 'fdisk' again, > I found all partitions gone! At this time,I could not access /dev/hda1 > any more.However, I could 'mount /dev/hda /opt', it really worked,and > I could create/read/write/erase files in it. > > I dumped the first sector of Hard disk and found that it has been > zeroed.Now I dont know what the problem is,since I am not familiar > with fs parts of linux kernel,and I dont know what 'mke2fs' has done. > > Any advice? > > Alan > > -----Original Message----- > From: Kevin D. Kissell [mailto:kevink@mips.com] > Sent: Tuesday, February 24, 2004 6:47 AM > To: Mark and Janice Juszczec; linux-mips@linux-mips.org > Cc: uhler@mips.com; dom@mips.com; echristo@redhat.com > Subject: Re: r3000 instruction set > > > Kaffe's makefiles won't pick up on configuration changes, so any time > you re-configure for a different engine or debug level, you need to do > a make clean. At least, that's the way it was the last time I worked on > it. > If you had a partial build with JIT, then changed to intrp, then you could > get all kinds of strange behavior. The address range of your error us a > dead giveaway. It's too high to be the kaffe code segment, but too low > to be a shared library. It's where I'd expect the heap to be, and where > I remember the JIT buffers being allocated when I was trying to debug > that stuff. > > > Its been a few weeks since I built this version of kaffe. The configure > > output says I did specify --with-engine=intrp. I'll delete the compiled > > stuff, reconfigure (double checking that I give it --with-engine=intrp), > > recompile and retest. > > > > I'll post my results. > > > > Mark > > > > > > > > >From: "Kevin D. Kissell" > > >To: "Mark and Janice Juszczec" , > > > > > >CC: , , > > >Subject: Re: r3000 instruction set > > >Date: Mon, 23 Feb 2004 18:21:19 +0100 > > > > > > > Someone suggested posting the message I get. Here it is: > > > > > > > > >./kaffe-bin FirstClass > > > > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, > > > > P0_STATUS=0000500 > > > > pid 6: killed (signal 4) > > > > >Reading command line: Try again > > > > Kernel panic: Attmpted to kill int! > > > > > >Let me guess. You are running little-endian. The instruction word > > >in memory would be 0x6a697406. Do you think it's a coincidence > > >that 0x6a6974 spells "jit" in ASCII? ;o) > > > > > >The reported address range looks like that where kaffe builds its > > >JITted instruciton buffers in MIPS/Linux. And, like I say, JIT is > > >somewhat broken for MIPS in Kaffe. Which version of the kaffe sources > > >are you building, and have you tried configuring with > --with-engine=intrp > > >as I suggested? > > > > > > Regards, > > > > > > Kevin K. > > > > _________________________________________________________________ > > Click, drag and drop. My MSN is the simple way to design your homepage. > > http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ > > > > > From alanliu@trident.com.cn Tue Feb 24 12:13:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2004 12:13:26 +0000 (GMT) Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:19469 "EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP id ; Tue, 24 Feb 2004 12:13:23 +0000 Received: by TMTMS with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 20:09:51 +0800 Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F680219C6D8@TMTMS> From: "Liu Hongming (Alan)" To: Thomas Lange , "Liu Hongming (Alan)" Cc: linux-mips@linux-mips.org Subject: RE: IDE driver problem Date: Tue, 24 Feb 2004 20:09:50 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FACF.1A5E2E60" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alanliu@trident.com.cn Precedence: bulk X-list: linux-mips Content-Length: 18165 Lines: 349 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3FACF.1A5E2E60 Content-Type: text/plain; charset="ISO-8859-1" Hi Thomas, I agree what you said,however,my problem is that when I use 'mke2fs /dev/hda2', it will report following errors: "Device size reported to be zero. Invalid partition specified, or partition table wasn't reread after running fdisk, due to a modified partition being busy and in use. You may need to reboot to re-read your partition table". The fact is that I have created four partitions: hda1,hda2,hda3,hda4. And their cylinder is:1-1000,1001-2000,2001-3000,3001-4000.However, when kernel boots up,it only could find hda1. After rebooting,I use fdisk to find the status of the four partitions.They are all still there.I dont know why kernel could not find them. I have used tools to dump the first sector,the four partition table is: 0x00000000: 00000000 00000000 00000000 00000000 0x00000010: 00000000 00000000 00000000 00000000 0x00000020: 00000000 00000000 00000000 00000000 0x00000030: 00000000 00000000 00000000 00000000 0x00000040: 00000000 00000000 00000000 00000000 0x00000050: 00000000 00000000 00000000 00000000 0x00000060: 00000000 00000000 00000000 00000000 0x00000070: 00000000 00000000 00000000 00000000 0x00000080: 00000000 00000000 00000000 00000000 0x00000090: 00000000 00000000 00000000 00000000 0x000000a0: 00000000 00000000 00000000 00000000 0x000000b0: 00000000 00000000 00000000 00000000 0x000000c0: 00000000 00000000 00000000 00000000 0x000000d0: 00000000 00000000 00000000 00000000 0x000000e0: 00000000 00000000 00000000 00000000 0x000000f0: 00000000 00000000 00000000 00000000 0x00000100: 00000000 00000000 00000000 00000000 0x00000110: 00000000 00000000 00000000 00000000 0x00000120: 00000000 00000000 00000000 00000000 0x00000130: 00000000 00000000 00000000 00000000 0x00000140: 00000000 00000000 00000000 00000000 0x00000150: 00000000 00000000 00000000 00000000 0x00000160: 00000000 00000000 00000000 00000000 0x00000170: 00000000 00000000 00000000 00000000 0x00000180: 00000000 00000000 00000000 00000000 0x00000190: 00000000 00000000 00000000 00000000 0x000001a0: 00000000 00000000 00000000 00000000 0x000001b0: 00000000 00000000 00000000 00008001 0x000001c0: 0100830f ffe73f00 00004161 0f000000 0x000001d0: c1e8830f ffff8061 0f008061 0f00000f 0x000001e0: ffff830f ffff00c3 1e008061 0f00000f 0x000001f0: ffff830f ffff8024 2e008061 0f0055aa I think they are all right.But why kernel could not find these partitions? Best Regards, Alan -----Original Message----- From: Thomas Lange [mailto:thomas@corelatus.se] Sent: Tuesday, February 24, 2004 7:56 PM To: Liu Hongming (Alan) Cc: linux-mips@linux-mips.org Subject: Re: IDE driver problem The partition table is written to the first partition on the device, in your example hda1. Use mke2fs on hda2 and I am sure it work just great. Cheers, /Thomas Liu Hongming (Alan) wrote: > Hi All, > > I am porting IDE drivers(Since my hardware has endian issue), > and now it could work,however it has some abnormal problems: > > I could 'fdisk' /dev/hda,and partition it into several partitions. > After this,I reboot my board and see all the partitions is there. > Then I 'mke2fs' on /dev/hda1,after this, when using 'fdisk' again, > I found all partitions gone! At this time,I could not access /dev/hda1 > any more.However, I could 'mount /dev/hda /opt', it really worked,and > I could create/read/write/erase files in it. > > I dumped the first sector of Hard disk and found that it has been > zeroed.Now I dont know what the problem is,since I am not familiar > with fs parts of linux kernel,and I dont know what 'mke2fs' has done. > > Any advice? > > Alan > > -----Original Message----- > From: Kevin D. Kissell [mailto:kevink@mips.com] > Sent: Tuesday, February 24, 2004 6:47 AM > To: Mark and Janice Juszczec; linux-mips@linux-mips.org > Cc: uhler@mips.com; dom@mips.com; echristo@redhat.com > Subject: Re: r3000 instruction set > > > Kaffe's makefiles won't pick up on configuration changes, so any time > you re-configure for a different engine or debug level, you need to do > a make clean. At least, that's the way it was the last time I worked on > it. > If you had a partial build with JIT, then changed to intrp, then you could > get all kinds of strange behavior. The address range of your error us a > dead giveaway. It's too high to be the kaffe code segment, but too low > to be a shared library. It's where I'd expect the heap to be, and where > I remember the JIT buffers being allocated when I was trying to debug > that stuff. > > > Its been a few weeks since I built this version of kaffe. The configure > > output says I did specify --with-engine=intrp. I'll delete the compiled > > stuff, reconfigure (double checking that I give it --with-engine=intrp), > > recompile and retest. > > > > I'll post my results. > > > > Mark > > > > > > > > >From: "Kevin D. Kissell" > > >To: "Mark and Janice Juszczec" , > > > > > >CC: , , > > >Subject: Re: r3000 instruction set > > >Date: Mon, 23 Feb 2004 18:21:19 +0100 > > > > > > > Someone suggested posting the message I get. Here it is: > > > > > > > > >./kaffe-bin FirstClass > > > > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, > > > > P0_STATUS=0000500 > > > > pid 6: killed (signal 4) > > > > >Reading command line: Try again > > > > Kernel panic: Attmpted to kill int! > > > > > >Let me guess. You are running little-endian. The instruction word > > >in memory would be 0x6a697406. Do you think it's a coincidence > > >that 0x6a6974 spells "jit" in ASCII? ;o) > > > > > >The reported address range looks like that where kaffe builds its > > >JITted instruciton buffers in MIPS/Linux. And, like I say, JIT is > > >somewhat broken for MIPS in Kaffe. Which version of the kaffe sources > > >are you building, and have you tried configuring with > --with-engine=intrp > > >as I suggested? > > > > > > Regards, > > > > > > Kevin K. > > > > _________________________________________________________________ > > Click, drag and drop. My MSN is the simple way to design your homepage. > > http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ > > > > > ------_=_NextPart_001_01C3FACF.1A5E2E60 Content-Type: text/html; charset="ISO-8859-1" RE: IDE driver problem

Hi Thomas,

I agree what you said,however,my problem is that
when I use 'mke2fs /dev/hda2', it will report following errors:
"Device size reported to be zero.  Invalid partition specified, or
 partition table wasn't reread after running fdisk, due to
 a modified partition being busy and in use.  You may need to reboot
 to re-read your partition table".
The fact is that I have created four partitions: hda1,hda2,hda3,hda4.
And their cylinder is:1-1000,1001-2000,2001-3000,3001-4000.However,
when kernel boots up,it only could find hda1.
After rebooting,I use fdisk to find the status of the four partitions.They are
all still there.I dont know why kernel could not find them. I have used tools
to dump the first sector,the four partition table is:
0x00000000:  00000000 00000000 00000000 00000000
0x00000010:  00000000 00000000 00000000 00000000
0x00000020:  00000000 00000000 00000000 00000000
0x00000030:  00000000 00000000 00000000 00000000
0x00000040:  00000000 00000000 00000000 00000000
0x00000050:  00000000 00000000 00000000 00000000
0x00000060:  00000000 00000000 00000000 00000000
0x00000070:  00000000 00000000 00000000 00000000
0x00000080:  00000000 00000000 00000000 00000000
0x00000090:  00000000 00000000 00000000 00000000
0x000000a0:  00000000 00000000 00000000 00000000
0x000000b0:  00000000 00000000 00000000 00000000
0x000000c0:  00000000 00000000 00000000 00000000
0x000000d0:  00000000 00000000 00000000 00000000
0x000000e0:  00000000 00000000 00000000 00000000
0x000000f0:  00000000 00000000 00000000 00000000
0x00000100:  00000000 00000000 00000000 00000000
0x00000110:  00000000 00000000 00000000 00000000
0x00000120:  00000000 00000000 00000000 00000000
0x00000130:  00000000 00000000 00000000 00000000
0x00000140:  00000000 00000000 00000000 00000000
0x00000150:  00000000 00000000 00000000 00000000
0x00000160:  00000000 00000000 00000000 00000000
0x00000170:  00000000 00000000 00000000 00000000
0x00000180:  00000000 00000000 00000000 00000000
0x00000190:  00000000 00000000 00000000 00000000
0x000001a0:  00000000 00000000 00000000 00000000
0x000001b0:  00000000 00000000 00000000 00008001
0x000001c0:  0100830f  ffe73f00 00004161 0f000000
0x000001d0:  c1e8830f ffff8061 0f008061 0f00000f
0x000001e0:  ffff830f ffff00c3 1e008061 0f00000f
0x000001f0:  ffff830f ffff8024 2e008061 0f0055aa

I think they are all right.But why kernel could not find these partitions?

Best Regards,
Alan

-----Original Message-----
From: Thomas Lange [mailto:thomas@corelatus.se]
Sent: Tuesday, February 24, 2004 7:56 PM
To: Liu Hongming (Alan)
Cc: linux-mips@linux-mips.org
Subject: Re: IDE driver problem


The partition table is written to the first partition
on the device, in your example hda1.
Use mke2fs on hda2 and I am sure it work just great.

Cheers,
/Thomas

Liu Hongming (Alan) wrote:
> Hi All,
>
> I am porting IDE drivers(Since my hardware has endian issue),
> and now it could work,however it has some abnormal problems:
>
> I could 'fdisk'  /dev/hda,and partition it into several partitions.
> After this,I reboot my board and see all the partitions is there.
> Then I 'mke2fs' on /dev/hda1,after this, when using 'fdisk' again,
> I found all partitions gone! At this time,I could not access /dev/hda1
> any more.However, I could 'mount /dev/hda /opt', it really worked,and
> I could create/read/write/erase files in it.
>
> I dumped the first sector of Hard disk and found that it has been
> zeroed.Now I dont know what the problem is,since I am not familiar
> with fs parts of linux kernel,and I dont know what 'mke2fs' has done.
>
> Any advice?
>
> Alan
>
> -----Original Message-----
> From: Kevin D. Kissell [mailto:kevink@mips.com]
> Sent: Tuesday, February 24, 2004 6:47 AM
> To: Mark and Janice Juszczec; linux-mips@linux-mips.org
> Cc: uhler@mips.com; dom@mips.com; echristo@redhat.com
> Subject: Re: r3000 instruction set
>
>
> Kaffe's makefiles won't pick up on configuration changes, so any time
> you re-configure for a different engine or debug level, you need to do
> a make clean.  At least, that's the way it was the last time I worked on
> it.
> If you had a partial build with JIT, then changed to intrp, then you could
> get all kinds of strange behavior.  The address range of your error us a
> dead giveaway.  It's too high to be the kaffe code segment, but too low
> to be a shared library.  It's where I'd expect the heap to be, and where
> I remember the JIT buffers being allocated when I was trying to debug
> that stuff.
>
>  > Its been a few weeks since I built this version of kaffe.  The configure
>  > output says I did specify --with-engine=intrp.  I'll delete the compiled
>  > stuff, reconfigure (double checking that I give it --with-engine=intrp),
>  > recompile and retest.
>  >
>  > I'll post my results.
>  >
>  > Mark
>  >
>  >
>  >
>  > >From: "Kevin D. Kissell" <kevink@mips.com>
>  > >To: "Mark and Janice Juszczec" <juszczec@hotmail.com>,      
>  > ><linux-mips@linux-mips.org>
>  > >CC: <uhler@mips.com>, <dom@mips.com>, <echristo@redhat.com>
>  > >Subject: Re: r3000 instruction set
>  > >Date: Mon, 23 Feb 2004 18:21:19 +0100
>  > >
>  > > > Someone suggested posting the message I get.  Here it is:
>  > > >
>  > > > >./kaffe-bin FirstClass
>  > > > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0,
>  > > > P0_STATUS=0000500
>  > > > pid 6: killed (signal 4)
>  > > > >Reading command line: Try again
>  > > > Kernel panic: Attmpted to kill int!
>  > >
>  > >Let me guess.  You are running little-endian.  The instruction word
>  > >in memory would be 0x6a697406.  Do you think it's a coincidence
>  > >that 0x6a6974 spells "jit" in ASCII?  ;o)
>  > >
>  > >The reported address range looks like that where kaffe builds its
>  > >JITted instruciton buffers in MIPS/Linux.  And, like I say, JIT is
>  > >somewhat broken for MIPS in Kaffe.  Which version of the kaffe sources
>  > >are you building, and have you tried configuring with
> --with-engine=intrp
>  > >as I suggested?
>  > >
>  > >             Regards,
>  > >
>  > >             Kevin K.
>  >
>  > _________________________________________________________________
>  > Click, drag and drop. My MSN is the simple way to design your homepage.
>  > http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/
>  >
>  >
>

------_=_NextPart_001_01C3FACF.1A5E2E60-- From thomas@corelatus.se Tue Feb 24 13:01:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2004 13:01:49 +0000 (GMT) Received: from [IPv6:::ffff:62.13.60.4] ([IPv6:::ffff:62.13.60.4]:19731 "EHLO mail.swemic.net") by linux-mips.org with ESMTP id ; Tue, 24 Feb 2004 13:01:46 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.swemic.net (Postfix) with ESMTP id 3D3D975DC2; Tue, 24 Feb 2004 14:01:42 +0100 (CET) Received: from mail.swemic.net ([127.0.0.1]) by localhost (seagle [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 09616-09; Tue, 24 Feb 2004 14:01:37 +0100 (CET) Received: from corelatus.se (skokloster.swemic.net [62.13.60.22]) by mail.swemic.net (Postfix) with ESMTP id 01CA675D83; Tue, 24 Feb 2004 14:01:36 +0100 (CET) Message-ID: <403B4B2F.40500@corelatus.se> Date: Tue, 24 Feb 2004 14:01:35 +0100 From: Thomas Lange User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liu Hongming (Alan)" Cc: linux-mips@linux-mips.org Subject: Re: IDE driver problem ( clarification ) References: <15F9E1AE3207D6119CEA00D0B7DD5F680219C648@TMTMS> <403B3BB8.8090403@corelatus.se> In-Reply-To: <403B3BB8.8090403@corelatus.se> X-Enigmail-Version: 0.82.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------020103050101030405030705" X-Virus-Scanned: by amavisd-new at hawk.swemic.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4425 X-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@corelatus.se Precedence: bulk X-list: linux-mips Content-Length: 4650 Lines: 135 This is a multi-part message in MIME format. --------------020103050101030405030705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hmm, maybe I should have waited for my first cup of coffee before replying ;-) I work with Compact Flash in IDE mode every day where we use Mac (Apple) partitioning. My statement is true for that case ( see attach ). /Thomas Thomas Lange wrote: > The partition table is written to the first partition > on the device, in your example hda1. > Use mke2fs on hda2 and I am sure it work just great. > > Cheers, > /Thomas > > Liu Hongming (Alan) wrote: > >> Hi All, >> >> I am porting IDE drivers(Since my hardware has endian issue), >> and now it could work,however it has some abnormal problems: >> >> I could 'fdisk' /dev/hda,and partition it into several partitions. >> After this,I reboot my board and see all the partitions is there. >> Then I 'mke2fs' on /dev/hda1,after this, when using 'fdisk' again, >> I found all partitions gone! At this time,I could not access /dev/hda1 >> any more.However, I could 'mount /dev/hda /opt', it really worked,and >> I could create/read/write/erase files in it. >> >> I dumped the first sector of Hard disk and found that it has been >> zeroed.Now I dont know what the problem is,since I am not familiar >> with fs parts of linux kernel,and I dont know what 'mke2fs' has done. >> >> Any advice? >> >> Alan >> >> -----Original Message----- >> From: Kevin D. Kissell [mailto:kevink@mips.com] >> Sent: Tuesday, February 24, 2004 6:47 AM >> To: Mark and Janice Juszczec; linux-mips@linux-mips.org >> Cc: uhler@mips.com; dom@mips.com; echristo@redhat.com >> Subject: Re: r3000 instruction set >> >> >> Kaffe's makefiles won't pick up on configuration changes, so any time >> you re-configure for a different engine or debug level, you need to do >> a make clean. At least, that's the way it was the last time I worked >> on it. >> If you had a partial build with JIT, then changed to intrp, then you >> could >> get all kinds of strange behavior. The address range of your error us a >> dead giveaway. It's too high to be the kaffe code segment, but too low >> to be a shared library. It's where I'd expect the heap to be, and where >> I remember the JIT buffers being allocated when I was trying to debug >> that stuff. >> >> > Its been a few weeks since I built this version of kaffe. The >> configure >> > output says I did specify --with-engine=intrp. I'll delete the >> compiled >> > stuff, reconfigure (double checking that I give it >> --with-engine=intrp), >> > recompile and retest. >> > >> > I'll post my results. >> > >> > Mark >> > >> > >> > >> > >From: "Kevin D. Kissell" >> > >To: "Mark and Janice Juszczec" , > >> > >> > >CC: , , >> > >Subject: Re: r3000 instruction set >> > >Date: Mon, 23 Feb 2004 18:21:19 +0100 >> > > >> > > > Someone suggested posting the message I get. Here it is: >> > > > >> > > > >./kaffe-bin FirstClass >> > > > [kaffe-bin:6] Illgal instruction 674696a at 2abb034, ra=2adbffd0, >> > > > P0_STATUS=0000500 >> > > > pid 6: killed (signal 4) >> > > > >Reading command line: Try again >> > > > Kernel panic: Attmpted to kill int! >> > > >> > >Let me guess. You are running little-endian. The instruction word >> > >in memory would be 0x6a697406. Do you think it's a coincidence >> > >that 0x6a6974 spells "jit" in ASCII? ;o) >> > > >> > >The reported address range looks like that where kaffe builds its >> > >JITted instruciton buffers in MIPS/Linux. And, like I say, JIT is >> > >somewhat broken for MIPS in Kaffe. Which version of the kaffe >> sources >> > >are you building, and have you tried configuring with >> --with-engine=intrp >> > >as I suggested? >> > > >> > > Regards, >> > > >> > > Kevin K. >> > >> > _________________________________________________________________ >> > Click, drag and drop. My MSN is the simple way to design your >> homepage. >> > http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ >> > >> > >> > > > --------------020103050101030405030705 Content-Type: text/plain; name="partition.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="partition.txt" Command (? for help): p /dev/hda # type name length base ( size ) system /dev/hda1 Apple_partition_map Apple 63 @ 1 ( 31.5k) Partition map --------------020103050101030405030705-- From yuasa@hh.iij4u.or.jp Tue Feb 24 14:36:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2004 14:36:19 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:21975 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Tue, 24 Feb 2004 14:36:16 +0000 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 XAA23173; Tue, 24 Feb 2004 23:36:09 +0900 (JST) Received: 4UMDO00 id i1OEa8v08621; Tue, 24 Feb 2004 23:36:08 +0900 (JST) Received: 4UMRO01 id i1OEa7G14658; Tue, 24 Feb 2004 23:36:07 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Tue, 24 Feb 2004 23:36:06 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] VR41xx patches for v2.6 Message-Id: <20040224233606.2e2f2467.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4427 X-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 Content-Length: 36534 Lines: 1228 Hi Ralf, I made a patch that summarizes the same code for vr41xx to one file. In order to apply this patch, it is necessary to apply the patches sent before. I already sent the following patches to you. 1. [PATCH][2.6] Update NEC VRC4171 PCMCIA driver This patch adds NEC VRC4171 PCMCIA contoller support to v2.6. http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/00-vrc4171_pccard-v26.diff 2. [PATCH][2.6] Changed clock functions for vr41xx This patch changes a clock function for a power management. http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/01-cmu-v26.diff 3. [PATCH][2.6] Moved timer setup to common part for vr41xx This patch get together setup of dispersed timer to one place. http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/02-rtc-v26.diff Please apply these patches to v2.6. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/Makefile linux/arch/mips/vr41xx/casio-e55/Makefile --- linux-orig/arch/mips/vr41xx/casio-e55/Makefile Wed Jul 30 22:36:55 2003 +++ linux/arch/mips/vr41xx/casio-e55/Makefile Sat Feb 21 17:38:18 2004 @@ -2,4 +2,4 @@ # Makefile for the CASIO CASSIOPEIA E-55/65 specific parts of the kernel # -obj-y += init.o setup.o +obj-y += setup.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/init.c linux/arch/mips/vr41xx/casio-e55/init.c --- linux-orig/arch/mips/vr41xx/casio-e55/init.c Thu Jan 29 23:17:19 2004 +++ linux/arch/mips/vr41xx/casio-e55/init.c Thu Jan 1 09:00:00 1970 @@ -1,49 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/casio-e55/init.c - * - * BRIEF MODULE DESCRIPTION - * Initialisation code for the CASIO CASSIOPEIA E-55/65. - * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ -#include -#include -#include - -#include - -const char *get_system_type(void) -{ - return "CASIO CASSIOPEIA E-11/15/55/65"; -} - -void __init prom_init(void) -{ - int argc = fw_arg0; - char **argv = (char **) fw_arg1; - int i; - - /* - * collect args and prepare cmd_line - */ - for (i = 1; i < argc; i++) { - strcat(arcs_cmdline, argv[i]); - if (i < (argc - 1)) - strcat(arcs_cmdline, " "); - } - - mips_machgroup = MACH_GROUP_NEC_VR41XX; - mips_machtype = MACH_CASIO_E55; -} - -unsigned long __init prom_free_prom_memory(void) -{ - return 0; -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c --- linux-orig/arch/mips/vr41xx/casio-e55/setup.c Sat Feb 21 17:37:17 2004 +++ linux/arch/mips/vr41xx/casio-e55/setup.c Sat Feb 21 23:27:24 2004 @@ -1,7 +1,7 @@ /* * setup.c, Setup for the CASIO CASSIOPEIA E-11/15/55/65. * - * Copyright (C) 2002-2003 Yoichi Yuasa + * Copyright (C) 2002-2004 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -18,44 +18,27 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include #include -#include -#include -#include +#include #include -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif +const char *get_system_type(void) +{ + return "CASIO CASSIOPEIA E-11/15/55/65"; +} -static void __init casio_e55_setup(void) +static int casio_e55_setup(void) { set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; ioport_resource.end = IO_PORT_RESOURCE_END; - iomem_resource.start = IO_MEM_RESOURCE_START; - iomem_resource.end = IO_MEM_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = Root_RAM0; - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif - - vr41xx_bcu_init(); - - vr41xx_cmu_init(); - - vr41xx_pmu_init(); - - vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); #endif + + return 0; } early_initcall(casio_e55_setup); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/Makefile linux/arch/mips/vr41xx/common/Makefile --- linux-orig/arch/mips/vr41xx/common/Makefile Sun Feb 1 21:41:34 2004 +++ linux/arch/mips/vr41xx/common/Makefile Sat Feb 21 17:38:18 2004 @@ -2,7 +2,7 @@ # Makefile for common code of the NEC VR4100 series. # -obj-y += bcu.o cmu.o giu.o icu.o int-handler.o ksyms.o pmu.o rtc.o +obj-y += bcu.o cmu.o giu.o icu.o init.o int-handler.o ksyms.o pmu.o rtc.o obj-$(CONFIG_SERIAL_8250) += serial.o obj-$(CONFIG_VRC4171) += vrc4171.o obj-$(CONFIG_VRC4173) += vrc4173.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/init.c linux/arch/mips/vr41xx/common/init.c --- linux-orig/arch/mips/vr41xx/common/init.c Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/vr41xx/common/init.c Sat Feb 21 18:05:40 2004 @@ -0,0 +1,58 @@ +/* + * init.c, Common initialization routines for NEC VR4100 series. + * + * Copyright (C) 2003-2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include + +#include +#include + +extern void vr41xx_bcu_init(void); +extern void vr41xx_cmu_init(void); +extern void vr41xx_pmu_init(void); +extern void vr41xx_rtc_init(void); + +void __init prom_init(void) +{ + int argc, i; + char **argv; + + argc = fw_arg0; + argv = (char **)fw_arg1; + + for (i = 1; i < argc; i++) { + strcat(arcs_cmdline, argv[i]); + if (i < (argc - 1)) + strcat(arcs_cmdline, " "); + } + + iomem_resource.start = IO_MEM_RESOURCE_START; + iomem_resource.end = IO_MEM_RESOURCE_END; + + vr41xx_bcu_init(); + vr41xx_cmu_init(); + vr41xx_pmu_init(); + vr41xx_rtc_init(); +} + +unsigned long __init prom_free_prom_memory (void) +{ + return 0UL; +} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/Makefile linux/arch/mips/vr41xx/ibm-workpad/Makefile --- linux-orig/arch/mips/vr41xx/ibm-workpad/Makefile Wed Jul 30 22:36:55 2003 +++ linux/arch/mips/vr41xx/ibm-workpad/Makefile Sat Feb 21 17:38:18 2004 @@ -2,4 +2,4 @@ # Makefile for the IBM WorkPad z50 specific parts of the kernel # -obj-y += init.o setup.o +obj-y += setup.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/init.c linux/arch/mips/vr41xx/ibm-workpad/init.c --- linux-orig/arch/mips/vr41xx/ibm-workpad/init.c Thu Jan 29 23:17:19 2004 +++ linux/arch/mips/vr41xx/ibm-workpad/init.c Thu Jan 1 09:00:00 1970 @@ -1,49 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/ibm-workpad/init.c - * - * BRIEF MODULE DESCRIPTION - * Initialisation code for the IBM WorkPad z50. - * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ -#include -#include -#include - -#include - -const char *get_system_type(void) -{ - return "IBM WorkPad z50"; -} - -void __init prom_init(void) -{ - int argc = fw_arg0; - char **argv = (char **) fw_arg1; - int i; - - /* - * collect args and prepare cmd_line - */ - for (i = 1; i < argc; i++) { - strcat(arcs_cmdline, argv[i]); - if (i < (argc - 1)) - strcat(arcs_cmdline, " "); - } - - mips_machgroup = MACH_GROUP_NEC_VR41XX; - mips_machtype = MACH_IBM_WORKPAD; -} - -unsigned long __init prom_free_prom_memory(void) -{ - return 0; -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c --- linux-orig/arch/mips/vr41xx/ibm-workpad/setup.c Sat Feb 21 17:37:18 2004 +++ linux/arch/mips/vr41xx/ibm-workpad/setup.c Sat Feb 21 23:34:32 2004 @@ -1,7 +1,7 @@ /* * setup.c, Setup for the IBM WorkPad z50. * - * Copyright (C) 2002-2003 Yoichi Yuasa + * Copyright (C) 2002-2004 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -18,44 +18,27 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include #include -#include -#include -#include +#include #include -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif +const char *get_system_type(void) +{ + return "IBM WorkPad z50"; +} -static void __init ibm_workpad_setup(void) +static int ibm_workpad_setup(void) { set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; ioport_resource.end = IO_PORT_RESOURCE_END; - iomem_resource.start = IO_MEM_RESOURCE_START; - iomem_resource.end = IO_MEM_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = Root_RAM0; - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif - - vr41xx_bcu_init(); - - vr41xx_cmu_init(); - - vr41xx_pmu_init(); - - vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); #endif + + return 0; } early_initcall(ibm_workpad_setup); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/Makefile linux/arch/mips/vr41xx/nec-eagle/Makefile --- linux-orig/arch/mips/vr41xx/nec-eagle/Makefile Wed Jul 30 22:36:55 2003 +++ linux/arch/mips/vr41xx/nec-eagle/Makefile Sat Feb 21 17:38:18 2004 @@ -7,4 +7,4 @@ # Copyright 2001,2002 MontaVista Software Inc. # -obj-y += init.o irq.o setup.o +obj-y += irq.o setup.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/init.c linux/arch/mips/vr41xx/nec-eagle/init.c --- linux-orig/arch/mips/vr41xx/nec-eagle/init.c Thu Jan 29 23:17:22 2004 +++ linux/arch/mips/vr41xx/nec-eagle/init.c Thu Jan 1 09:00:00 1970 @@ -1,74 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/nec-eagle/init.c - * - * BRIEF MODULE DESCRIPTION - * Initialisation code for the NEC Eagle/Hawk board. - * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com - * - * Copyright 2001,2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ -/* - * Changes: - * MontaVista Software Inc. or - * - Added support for NEC Hawk. - * - * MontaVista Software Inc. or - * - New creation, NEC Eagle is supported. - */ -#include -#include -#include - -#include - -const char *get_system_type(void) -{ - return "NEC Eagle/Hawk"; -} - -void __init prom_init(void) -{ - int argc = fw_arg0; - char **argv = (char **) fw_arg1; - int i; - - /* - * collect args and prepare cmd_line - */ - for (i = 1; i < argc; i++) { - strcat(arcs_cmdline, argv[i]); - if (i < (argc - 1)) - strcat(arcs_cmdline, " "); - } - - mips_machgroup = MACH_GROUP_NEC_VR41XX; - mips_machtype = MACH_NEC_EAGLE; -} - -unsigned long __init prom_free_prom_memory(void) -{ - return 0; -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Sat Feb 21 17:37:18 2004 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Sat Feb 21 23:35:30 2004 @@ -11,20 +11,12 @@ * or implied. */ #include -#include #include -#include -#include -#include +#include #include #include -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - extern void eagle_irq_init(void); #ifdef CONFIG_PCI @@ -78,29 +70,18 @@ }; #endif +const char *get_system_type(void) +{ + return "NEC SDB-VR4122/VR4131(Eagle/Hawk)"; +} + static int nec_eagle_setup(void) { set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; ioport_resource.end = IO_PORT_RESOURCE_END; - iomem_resource.start = IO_MEM1_RESOURCE_START; - iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = Root_RAM0; - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif board_irq_init = eagle_irq_init; - - vr41xx_bcu_init(); - - vr41xx_cmu_init(); - - vr41xx_pmu_init(); - - vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_dsiu_init(); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/Makefile linux/arch/mips/vr41xx/tanbac-tb0226/Makefile --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/Makefile Sat Jun 14 00:32:27 2003 +++ linux/arch/mips/vr41xx/tanbac-tb0226/Makefile Sat Feb 21 17:38:18 2004 @@ -2,4 +2,4 @@ # Makefile for the TANBAC TB0226 specific parts of the kernel # -obj-y += init.o setup.o +obj-y += setup.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/init.c linux/arch/mips/vr41xx/tanbac-tb0226/init.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/init.c Thu Jan 29 23:17:22 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0226/init.c Thu Jan 1 09:00:00 1970 @@ -1,53 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/tanbac-tb0226/init.c - * - * BRIEF MODULE DESCRIPTION - * Initialisation code for the TANBAC TB0226. - * - * Copyright 2002,2003 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ -#include -#include -#include -#include - -#include -#include -#include -#include - -const char *get_system_type(void) -{ - return "TANBAC TB0226"; -} - -void __init prom_init(void) -{ - int argc = fw_arg0; - char **argv = (char **) fw_arg1; - int i; - - /* - * collect args and prepare cmd_line - */ - for (i = 1; i < argc; i++) { - strcat(arcs_cmdline, argv[i]); - if (i < (argc - 1)) - strcat(arcs_cmdline, " "); - } - - mips_machgroup = MACH_GROUP_NEC_VR41XX; - mips_machtype = MACH_TANBAC_TB0226; -} - -unsigned long __init prom_free_prom_memory(void) -{ - return 0; -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c Sat Feb 21 17:37:18 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c Sat Feb 21 23:35:53 2004 @@ -1,7 +1,7 @@ /* * setup.c, Setup for the TANBAC TB0226. * - * Copyright (C) 2002-2003 Yoichi Yuasa + * Copyright (C) 2002-2004 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -18,17 +18,12 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include #include +#include #include #include -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - #ifdef CONFIG_PCI static struct resource vr41xx_pci_io_resource = { .name = "PCI I/O space", @@ -77,33 +72,24 @@ }; #endif -void __init tanbac_tb0226_setup(void) +const char *get_system_type(void) +{ + return "TANBAC TB0226"; +} + +static int tanbac_tb0226_setup(void) { set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; ioport_resource.end = IO_PORT_RESOURCE_END; - iomem_resource.start = IO_MEM1_RESOURCE_START; - iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif - - vr41xx_bcu_init(); - - vr41xx_cmu_init(); - - vr41xx_pmu_init(); - - vr41xx_rtc_init(); vr41xx_siu_init(SIU_RS232C, 0); #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); #endif + + return 0; } early_initcall(tanbac_tb0226_setup); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile linux/arch/mips/vr41xx/tanbac-tb0229/Makefile --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/Makefile Sun Feb 1 21:41:34 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0229/Makefile Sat Feb 21 17:38:18 2004 @@ -2,6 +2,6 @@ # Makefile for the TANBAC TB0229(VR4131DIMM) specific parts of the kernel # -obj-y := init.o setup.o +obj-y := setup.o obj-$(CONFIG_TANBAC_TB0219) += reboot.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/init.c linux/arch/mips/vr41xx/tanbac-tb0229/init.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/init.c Thu Jan 29 23:17:22 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0229/init.c Thu Jan 1 09:00:00 1970 @@ -1,58 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/tanbac-tb0229/init.c - * - * BRIEF MODULE DESCRIPTION - * Initialisation code for the TANBAC TB0229(VR4131DIMM) - * - * Copyright 2002,2003 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp - * - * Modified for TANBAC TB0229: - * Copyright 2003 Megasolution Inc. - * matsu@megasolution.jp - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ -#include -#include -#include -#include -#include - -#include -#include -#include -#include - -const char *get_system_type(void) -{ - return "TANBAC TB0229"; -} - -void __init prom_init(void) -{ - int argc = fw_arg0; - char **argv = (char **) fw_arg1; - int i; - - /* - * collect args and prepare cmd_line - */ - for (i = 1; i < argc; i++) { - strcat(arcs_cmdline, argv[i]); - if (i < (argc - 1)) - strcat(arcs_cmdline, " "); - } - - mips_machgroup = MACH_GROUP_NEC_VR41XX; - mips_machtype = MACH_TANBAC_TB0229; -} - -unsigned long __init prom_free_prom_memory(void) -{ - return 0; -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c Sat Feb 21 17:37:18 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c Sat Feb 21 23:36:13 2004 @@ -1,7 +1,7 @@ /* * setup.c, Setup for the TANBAC TB0229 (VR4131DIMM) * - * Copyright (C) 2002-2003 Yoichi Yuasa + * Copyright (C) 2002-2004 Yoichi Yuasa * * Modified for TANBAC TB0229: * Copyright (C) 2003 Megasolution Inc. @@ -21,19 +21,13 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include -#include #include -#include +#include #include #include #include -#ifdef CONFIG_BLK_DEV_INITRD -extern void * __rd_start, * __rd_end; -#endif - #ifdef CONFIG_PCI static struct resource vr41xx_pci_io_resource = { .name = "PCI I/O space", @@ -82,27 +76,16 @@ }; #endif -static void __init tanbac_tb0229_setup(void) +const char *get_system_type(void) +{ + return "TANBAC TB0229"; +} + +static int tanbac_tb0229_setup(void) { set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; ioport_resource.end = IO_PORT_RESOURCE_END; - iomem_resource.start = IO_MEM1_RESOURCE_START; - iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif - - vr41xx_bcu_init(); - - vr41xx_cmu_init(); - - vr41xx_pmu_init(); - - vr41xx_rtc_init(); vr41xx_siu_init(SIU_RS232C, 0); vr41xx_dsiu_init(); @@ -114,6 +97,8 @@ #ifdef CONFIG_TANBAC_TB0219 _machine_restart = tanbac_tb0229_restart; #endif + + return 0; } early_initcall(tanbac_tb0229_setup); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/Makefile linux/arch/mips/vr41xx/victor-mpc30x/Makefile --- linux-orig/arch/mips/vr41xx/victor-mpc30x/Makefile Wed Jul 30 22:36:55 2003 +++ linux/arch/mips/vr41xx/victor-mpc30x/Makefile Sat Feb 21 17:38:18 2004 @@ -2,4 +2,4 @@ # Makefile for the Victor MP-C303/304 specific parts of the kernel # -obj-y += init.o setup.o +obj-y += setup.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/init.c linux/arch/mips/vr41xx/victor-mpc30x/init.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/init.c Thu Jan 29 23:17:23 2004 +++ linux/arch/mips/vr41xx/victor-mpc30x/init.c Thu Jan 1 09:00:00 1970 @@ -1,54 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/victor-mpc30x/init.c - * - * BRIEF MODULE DESCRIPTION - * Initialisation code for the Victor MP-C303/304. - * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ -#include -#include -#include - -#include -#include -#include -#include - -const char *get_system_type(void) -{ - return "Victor MP-C303/304"; -} - -void __init prom_init(void) -{ - int argc = fw_arg0; - char **argv = (char **) fw_arg1; - int i; - - /* - * collect args and prepare cmd_line - */ - for (i = 1; i < argc; i++) { - strcat(arcs_cmdline, argv[i]); - if (i < (argc - 1)) - strcat(arcs_cmdline, " "); - } - - mips_machgroup = MACH_GROUP_NEC_VR41XX; - mips_machtype = MACH_VICTOR_MPC30X; - - add_memory_region(0, 32 << 20, BOOT_MEM_RAM); -} - -unsigned long __init prom_free_prom_memory(void) -{ - return 0; -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c Sat Feb 21 17:37:18 2004 +++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c Sat Feb 21 23:36:44 2004 @@ -1,7 +1,7 @@ /* * setup.c, Setup for the Victor MP-C303/304. * - * Copyright (C) 2002-2003 Yoichi Yuasa + * Copyright (C) 2002-2004 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -18,20 +18,12 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include #include -#include -#include -#include +#include #include #include -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - #ifdef CONFIG_PCI static struct resource vr41xx_pci_io_resource = { "PCI I/O space", @@ -80,27 +72,16 @@ }; #endif -static void __init victor_mpc30x_setup(void) +const char *get_system_type(void) +{ + return "Victor MP-C303/304"; +} + +static int victor_mpc30x_setup(void) { set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; ioport_resource.end = IO_PORT_RESOURCE_END; - iomem_resource.start = IO_MEM1_RESOURCE_START; - iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = Root_RAM0; - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif - - vr41xx_bcu_init(); - - vr41xx_cmu_init(); - - vr41xx_pmu_init(); - - vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); @@ -109,6 +90,8 @@ #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); #endif + + return 0; } early_initcall(victor_mpc30x_setup); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/Makefile linux/arch/mips/vr41xx/zao-capcella/Makefile --- linux-orig/arch/mips/vr41xx/zao-capcella/Makefile Wed Jul 30 22:36:55 2003 +++ linux/arch/mips/vr41xx/zao-capcella/Makefile Sat Feb 21 17:38:18 2004 @@ -2,4 +2,4 @@ # Makefile for the ZAO Networks Capcella specific parts of the kernel # -obj-y += init.o setup.o +obj-y += setup.o diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/init.c linux/arch/mips/vr41xx/zao-capcella/init.c --- linux-orig/arch/mips/vr41xx/zao-capcella/init.c Thu Jan 29 23:17:23 2004 +++ linux/arch/mips/vr41xx/zao-capcella/init.c Thu Jan 1 09:00:00 1970 @@ -1,53 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/zao-capcella/init.c - * - * BRIEF MODULE DESCRIPTION - * Initialisation code for the ZAO Networks Capcella. - * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ -#include -#include -#include -#include - -#include -#include -#include -#include - -const char *get_system_type(void) -{ - return "ZAO Networks Capcella"; -} - -void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec) -{ - int argc = fw_arg0; - char **argv = (char **) fw_arg1; - int i; - - /* - * collect args and prepare cmd_line - */ - for (i = 1; i < argc; i++) { - strcat(arcs_cmdline, argv[i]); - if (i < (argc - 1)) - strcat(arcs_cmdline, " "); - } - - mips_machgroup = MACH_GROUP_NEC_VR41XX; - mips_machtype = MACH_ZAO_CAPCELLA; -} - -unsigned long __init prom_free_prom_memory(void) -{ - return 0; -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c --- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c Sat Feb 21 17:37:18 2004 +++ linux/arch/mips/vr41xx/zao-capcella/setup.c Sat Feb 21 23:37:17 2004 @@ -1,7 +1,7 @@ /* * setup.c, Setup for the ZAO Networks Capcella. * - * Copyright (C) 2002-2003 Yoichi Yuasa + * Copyright (C) 2002-2004 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -18,20 +18,12 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include #include -#include -#include -#include +#include #include #include -#ifdef CONFIG_BLK_DEV_INITRD -extern unsigned long initrd_start, initrd_end; -extern void * __rd_start, * __rd_end; -#endif - #ifdef CONFIG_PCI static struct resource vr41xx_pci_io_resource = { "PCI I/O space", @@ -80,27 +72,16 @@ }; #endif -static void __init zao_capcella_setup(void) +const char *get_system_type(void) +{ + return "ZAO Networks Capcella"; +} + +static int zao_capcella_setup(void) { set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; ioport_resource.end = IO_PORT_RESOURCE_END; - iomem_resource.start = IO_MEM1_RESOURCE_START; - iomem_resource.end = IO_MEM2_RESOURCE_END; - -#ifdef CONFIG_BLK_DEV_INITRD - ROOT_DEV = Root_RAM0; - initrd_start = (unsigned long)&__rd_start; - initrd_end = (unsigned long)&__rd_end; -#endif - - vr41xx_bcu_init(); - - vr41xx_cmu_init(); - - vr41xx_pmu_init(); - - vr41xx_rtc_init(); #ifdef CONFIG_SERIAL_8250 vr41xx_siu_init(SIU_RS232C, 0); @@ -110,6 +91,8 @@ #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); #endif + + return 0; } early_initcall(zao_capcella_setup); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/e55.h linux/include/asm-mips/vr41xx/e55.h --- linux-orig/include/asm-mips/vr41xx/e55.h Fri Oct 4 01:57:50 2002 +++ linux/include/asm-mips/vr41xx/e55.h Sat Feb 21 23:25:47 2004 @@ -1,17 +1,21 @@ /* - * FILE NAME - * include/asm-mips/vr41xx/e55.h + * e55.h, Include file for CASIO CASSIOPEIA E-10/15/55/65. * - * BRIEF MODULE DESCRIPTION - * Include file for CASIO CASSIOPEIA E-10/15/55/65. + * Copyright (C) 2002-2004 Yoichi Yuasa * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __CASIO_E55_H #define __CASIO_E55_H @@ -25,13 +29,15 @@ #define VR41XX_ISA_MEM_BASE 0x10000000 #define VR41XX_ISA_MEM_SIZE 0x04000000 -#define VR41XX_ISA_IO_BASE 0x14000000 -#define VR41XX_ISA_IO_SIZE 0x04000000 +/* VR41XX_ISA_IO_BASE includes offset from real base. */ +#define VR41XX_ISA_IO_BASE 0x1400c000 +#define VR41XX_ISA_IO_SIZE 0x03ff4000 + +#define ISA_BUS_IO_BASE 0 +#define ISA_BUS_IO_SIZE VR41XX_ISA_IO_SIZE #define IO_PORT_BASE KSEG1ADDR(VR41XX_ISA_IO_BASE) -#define IO_PORT_RESOURCE_START 0 -#define IO_PORT_RESOURCE_END VR41XX_ISA_IO_SIZE -#define IO_MEM_RESOURCE_START VR41XX_ISA_MEM_BASE -#define IO_MEM_RESOURCE_END (VR41XX_ISA_MEM_BASE + VR41XX_ISA_MEM_SIZE) +#define IO_PORT_RESOURCE_START ISA_BUS_IO_BASE +#define IO_PORT_RESOURCE_END (ISA_BUS_IO_BASE + ISA_BUS_IO_SIZE - 1) #endif /* __CASIO_E55_H */ diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Sat Feb 21 17:37:18 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Sat Feb 21 17:54:56 2004 @@ -43,17 +43,20 @@ #define PRID_VR4133 0x00000c84 /* + * Memory resource + */ +#define IO_MEM_RESOURCE_START 0UL +#define IO_MEM_RESOURCE_END 0x1fffffffUL + +/* * Bus Control Uint */ -extern void vr41xx_bcu_init(void); extern unsigned long vr41xx_get_vtclock_frequency(void); extern unsigned long vr41xx_get_tclock_frequency(void); /* * Clock Mask Unit */ -extern void vr41xx_cmu_init(void); - typedef enum { PIU_CLOCK, SIU_CLOCK, @@ -137,7 +140,6 @@ /* * Power Management Unit */ -extern void vr41xx_pmu_init(void); /* * RTC @@ -150,8 +152,6 @@ extern void vr41xx_set_tclock_cycle(uint32_t cycles); extern uint32_t vr41xx_read_tclock_counter(void); - -extern void vr41xx_rtc_init(void); /* * General-Purpose I/O Unit diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/workpad.h linux/include/asm-mips/vr41xx/workpad.h --- linux-orig/include/asm-mips/vr41xx/workpad.h Wed Jul 30 22:36:56 2003 +++ linux/include/asm-mips/vr41xx/workpad.h Sat Feb 21 20:50:35 2004 @@ -1,17 +1,21 @@ /* - * FILE NAME - * include/asm-mips/vr41xx/workpad.h + * workpad.h, Include file for IBM WorkPad z50. * - * BRIEF MODULE DESCRIPTION - * Include file for IBM WorkPad z50. + * Copyright (C) 2002-2004 Yoichi Yuasa * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __IBM_WORKPAD_H #define __IBM_WORKPAD_H @@ -29,10 +33,11 @@ #define VR41XX_ISA_IO_BASE 0x15000000 #define VR41XX_ISA_IO_SIZE 0x03000000 +#define ISA_BUS_IO_BASE 0 +#define ISA_BUS_IO_SIZE VR41XX_ISA_IO_SIZE + #define IO_PORT_BASE KSEG1ADDR(VR41XX_ISA_IO_BASE) -#define IO_PORT_RESOURCE_START 0 -#define IO_PORT_RESOURCE_END VR41XX_ISA_IO_SIZE -#define IO_MEM_RESOURCE_START VR41XX_ISA_MEM_BASE -#define IO_MEM_RESOURCE_END (VR41XX_ISA_MEM_BASE + VR41XX_ISA_MEM_SIZE) +#define IO_PORT_RESOURCE_START ISA_BUS_IO_BASE +#define IO_PORT_RESOURCE_END (ISA_BUS_IO_BASE + ISA_BUS_IO_SIZE - 1) #endif /* __IBM_WORKPAD_H */ From Joost@stack.nl Tue Feb 24 16:03:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2004 16:03:32 +0000 (GMT) Received: from brilsmurf.chem.tue.nl ([IPv6:::ffff:131.155.84.68]:15530 "EHLO brilsmurf.chem.tue.nl") by linux-mips.org with ESMTP id ; Tue, 24 Feb 2004 16:03:20 +0000 Received: from brilsmurf.chem.tue.nl (localhost [127.0.0.1]) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1OG3JvI030497 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 24 Feb 2004 17:03:20 +0100 Received: from localhost (joost@localhost) by brilsmurf.chem.tue.nl (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1OG3JSA030959 for ; Tue, 24 Feb 2004 17:03:19 +0100 X-Authentication-Warning: brilsmurf.chem.tue.nl: joost owned process doing -bs Date: Tue, 24 Feb 2004 17:03:19 +0100 (CET) From: Joost X-X-Sender: joost@brilsmurf.chem.tue.nl To: linux-mips@linux-mips.org Subject: Re: fore atm card in indy? In-Reply-To: <20040223204649.GF1046@mind.be> Message-ID: References: <20040220142138.GD23404@linux-mips.org> <20040223204649.GF1046@mind.be> ReplyTo: Joost@stack.nl User-Agent: 007 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: 4429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Joost@stack.nl Precedence: bulk X-list: linux-mips Content-Length: 523 Lines: 12 > > You'll not like this answer ... but write a driver :-) > > It seems many GIO cards are based on already Linux-supported PCI chips, > > so there's a certain chance this won't even be hard. > There is already a driver for the PCI and SBUS versions of this card. It > lives in drivers/atm/fore200e*. You 'only' need to add code for the > GIO32 specifics. Thank you both for your answer. I've only taken a quick peek, and got rather scared :-) Maybe I'll try again when I have more time (exams coming up). Thanks again! From alan@lxorguk.ukuu.org.uk Tue Feb 24 22:13:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2004 22:13:28 +0000 (GMT) Received: from cpc1-cwma1-5-0-cust4.swan.cable.ntl.com ([IPv6:::ffff:80.5.120.4]:17315 "EHLO dhcp23.swansea.linux.org.uk") by linux-mips.org with ESMTP id ; Tue, 24 Feb 2004 22:13:25 +0000 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10) with ESMTP id i1OM9s0r023025; Tue, 24 Feb 2004 22:09:54 GMT Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10/Submit) id i1OM9qXU023023; Tue, 24 Feb 2004 22:09:52 GMT X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: IDE driver problem From: Alan Cox To: "Liu Hongming (Alan)" Cc: linux-mips@linux-mips.org In-Reply-To: <15F9E1AE3207D6119CEA00D0B7DD5F680219C648@TMTMS> References: <15F9E1AE3207D6119CEA00D0B7DD5F680219C648@TMTMS> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1077660589.22906.7.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 24 Feb 2004 22:09:50 +0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips Content-Length: 313 Lines: 9 On Maw, 2004-02-24 at 05:09, Liu Hongming (Alan) wrote: > Hi All, > > I am porting IDE drivers(Since my hardware has endian issue), > and now it could work,however it has some abnormal problems: Sounds like your partition data reading is wrong. Print out the partition table bases and see if they are all zero From yuasa@hh.iij4u.or.jp Tue Feb 24 23:38:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2004 23:38:32 +0000 (GMT) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:41166 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Tue, 24 Feb 2004 23:38:29 +0000 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 IAA17606; Wed, 25 Feb 2004 08:38:24 +0900 (JST) Received: 4UMDO00 id i1ONcOF12044; Wed, 25 Feb 2004 08:38:24 +0900 (JST) Received: 4UMRO00 id i1ONcN326773; Wed, 25 Feb 2004 08:38:23 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Wed, 25 Feb 2004 08:38:13 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] Fixed argument of early_serial_setup for vr41xx Message-Id: <20040225083813.34c98707.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4436 X-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 Content-Length: 5558 Lines: 163 Hello Ralf, I made a patch for serial setup about vr41xx. This patch corrects the argument of early_serial_setup correctly. In order to apply this patch, it is necessary to apply the patche sent before. I already sent the following patch to you. 1. [PATCH][2.6] Changed clock functions for vr41xx This patch changes a clock function for a power management. http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v26/01-cmu-v26.diff Please apply these patches to v2.6. 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 Sat Feb 21 17:13:46 2004 +++ linux/arch/mips/vr41xx/common/serial.c Sun Feb 22 00:59:38 2004 @@ -1,34 +1,23 @@ /* - * FILE NAME - * arch/mips/vr41xx/common/serial.c + * serial.c, Serial Interface Unit routines for NEC VR4100 series. * - * BRIEF MODULE DESCRIPTION - * Serial Interface Unit routines for NEC VR4100 series. - * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com - * - * Copyright 2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * Copyright (C) 2002 MontaVista Software Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2003-2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* * Changes: @@ -41,7 +30,9 @@ */ #include #include +#include #include +#include #include #include @@ -117,33 +108,33 @@ void __init vr41xx_siu_init(int interface, int module) { - struct serial_struct s; + struct uart_port port; vr41xx_siu_ifselect(interface, module); - memset(&s, 0, sizeof(s)); + memset(&port, 0, sizeof(port)); - s.line = vr41xx_serial_ports; - s.baud_base = SIU_BASE_BAUD; - s.irq = SIU_IRQ; - s.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST; + port.line = vr41xx_serial_ports; + port.uartclk = SIU_BASE_BAUD; + port.irq = SIU_IRQ; + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST; switch (current_cpu_data.cputype) { case CPU_VR4111: case CPU_VR4121: - s.iomem_base = (unsigned char *)SIURB_TYPE1; + port.membase = (char *)SIURB_TYPE1; break; case CPU_VR4122: case CPU_VR4131: case CPU_VR4133: - s.iomem_base = (unsigned char *)SIURB_TYPE2; + port.membase = (char *)SIURB_TYPE2; break; default: panic("Unexpected CPU of NEC VR4100 series"); break; } - s.iomem_reg_shift = 0; - s.io_type = SERIAL_IO_MEM; - if (early_serial_setup(&s) != 0) + port.regshift = 0; + port.iotype = UPIO_MEM; + if (early_serial_setup(&port) != 0) printk(KERN_ERR "SIU setup failed!\n"); vr41xx_supply_clock(SIU_CLOCK); @@ -153,23 +144,23 @@ void __init vr41xx_dsiu_init(void) { - struct serial_struct s; + struct uart_port port; if (current_cpu_data.cputype != CPU_VR4122 && current_cpu_data.cputype != CPU_VR4131 && current_cpu_data.cputype != CPU_VR4133) return; - memset(&s, 0, sizeof(s)); + memset(&port, 0, sizeof(port)); - s.line = vr41xx_serial_ports; - s.baud_base = DSIU_BASE_BAUD; - s.irq = DSIU_IRQ; - s.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST; - s.iomem_base = (unsigned char *)DSIURB; - s.iomem_reg_shift = 0; - s.io_type = SERIAL_IO_MEM; - if (early_serial_setup(&s) != 0) + port.line = vr41xx_serial_ports; + port.uartclk = DSIU_BASE_BAUD; + port.irq = DSIU_IRQ; + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST; + port.membase = (char *)DSIURB; + port.regshift = 0; + port.iotype = UPIO_MEM; + if (early_serial_setup(&port) != 0) printk(KERN_ERR "DSIU setup failed!\n"); vr41xx_supply_clock(DSIU_CLOCK); From alanliu@trident.com.cn Wed Feb 25 12:15:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 12:15:31 +0000 (GMT) Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:49926 "EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 12:15:30 +0000 Received: by TMTMS with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Feb 2004 20:11:58 +0800 Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F680219C882@TMTMS> From: "Liu Hongming (Alan)" To: Alan Cox , "Liu Hongming (Alan)" Cc: linux-mips@linux-mips.org Subject: RE: IDE driver problem Date: Wed, 25 Feb 2004 20:11:54 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FB98.8EBCBB40" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alanliu@trident.com.cn Precedence: bulk X-list: linux-mips Content-Length: 2688 Lines: 80 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3FB98.8EBCBB40 Content-Type: text/plain; charset="ISO-8859-1" Thanks for your tips. I have found out where the problem is. Since my hardware has endian issue, fs/partition/msdos.c could not handle partition table correctly. I have changed a little(still having much to change),and it really works now. -----Original Message----- From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] Sent: Wednesday, February 25, 2004 6:10 AM To: Liu Hongming (Alan) Cc: linux-mips@linux-mips.org Subject: Re: IDE driver problem On Maw, 2004-02-24 at 05:09, Liu Hongming (Alan) wrote: > Hi All, > > I am porting IDE drivers(Since my hardware has endian issue), > and now it could work,however it has some abnormal problems: Sounds like your partition data reading is wrong. Print out the partition table bases and see if they are all zero ------_=_NextPart_001_01C3FB98.8EBCBB40 Content-Type: text/html; charset="ISO-8859-1" RE: IDE driver problem

Thanks for your tips.

I have found out where the problem is. Since my hardware has
endian issue, fs/partition/msdos.c could not handle partition table
correctly. I have changed a little(still having much to change),and it
really works now.


-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Wednesday, February 25, 2004 6:10 AM
To: Liu Hongming (Alan)
Cc: linux-mips@linux-mips.org
Subject: Re: IDE driver problem


On Maw, 2004-02-24 at 05:09, Liu Hongming (Alan) wrote:
> Hi All,
>
> I am porting IDE drivers(Since my hardware has endian issue),
> and now it could work,however it has some abnormal problems:

Sounds like your partition data reading is wrong. Print out the
partition table bases and see if they are all zero

------_=_NextPart_001_01C3FB98.8EBCBB40-- From ralf@linux-mips.org Wed Feb 25 14:30:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 14:30:58 +0000 (GMT) Received: from p508B5CC5.dip.t-dialin.net ([IPv6:::ffff:80.139.92.197]:62811 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 14:30:57 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1PEUuex015552; Wed, 25 Feb 2004 15:30:56 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1PEUrQ8015551; Wed, 25 Feb 2004 15:30:53 +0100 Date: Wed, 25 Feb 2004 15:30:53 +0100 From: Ralf Baechle To: Joost Cc: linux-mips@linux-mips.org Subject: Re: fore atm card in indy? Message-ID: <20040225143053.GC19555@linux-mips.org> References: <20040220142138.GD23404@linux-mips.org> <20040223204649.GF1046@mind.be> 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: 4438 X-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, Feb 24, 2004 at 05:03:19PM +0100, Joost wrote: > > There is already a driver for the PCI and SBUS versions of this card. It > > lives in drivers/atm/fore200e*. You 'only' need to add code for the > > GIO32 specifics. > > Thank you both for your answer. I've only taken a quick > peek, and got rather scared :-) Maybe I'll try again > when I have more time (exams coming up). One of the running gags on ATM is it actually stands for A Terrible Mess ;-) Ralf From yuasa@hh.iij4u.or.jp Wed Feb 25 16:22:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 16:22:21 +0000 (GMT) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:35056 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 16:22:20 +0000 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id BAA24561; Thu, 26 Feb 2004 01:22:16 +0900 (JST) Received: 4UMDO01 id i1PGMFt00640; Thu, 26 Feb 2004 01:22:15 +0900 (JST) Received: 4UMRO00 id i1PGME712977; Thu, 26 Feb 2004 01:22:15 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 26 Feb 2004 01:22:13 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2.6] Removed board_irq_init for vr41xx Message-Id: <20040226012213.458ad64f.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4439 X-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, I made a patch for vr41xx platforms. This patch removes the board_irq_init function for vr41xx. The board_irq_init isn't needed for us. I rewrote the IRQ function of NEC Eagle without using board_irq_init. Please apply this patch to v2.6. 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 Tue Jan 13 08:21:05 2004 +++ linux/arch/mips/vr41xx/common/giu.c Thu Feb 26 00:52:52 2004 @@ -1,34 +1,23 @@ /* - * FILE NAME - * arch/mips/vr41xx/common/giu.c + * giu.c, General-purpose I/O Unit Interrupt routines for NEC VR4100 series. * - * BRIEF MODULE DESCRIPTION - * General-purpose I/O Unit Interrupt routines for NEC VR4100 series. + * Copyright (C) 2002 MontaVista Software Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2003-2004 Yoichi Yuasa * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * Copyright 2002 MontaVista Software Inc. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* * Changes: @@ -37,6 +26,7 @@ * * Yoichi Yuasa * - Added support for NEC VR4133. + * - Removed board_irq_init. */ #include #include @@ -272,8 +262,6 @@ return retval; } -void (*board_irq_init)(void) = NULL; - void __init vr41xx_giuint_init(void) { int i; @@ -301,7 +289,4 @@ if (setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade)) printk("GIUINT: Can not cascade IRQ %d.\n", GIUINT_CASCADE_IRQ); - - if (board_irq_init) - board_irq_init(); } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/irq.c linux/arch/mips/vr41xx/nec-eagle/irq.c --- linux-orig/arch/mips/vr41xx/nec-eagle/irq.c Sun Dec 29 23:50:56 2002 +++ linux/arch/mips/vr41xx/nec-eagle/irq.c Thu Feb 26 00:49:14 2004 @@ -1,64 +1,61 @@ /* - * FILE NAME - * arch/mips/vr41xx/nec-eagle/irq.c + * irq.c, Interrupt routines for the NEC Eagle/Hawk board. * - * BRIEF MODULE DESCRIPTION - * Interrupt routines for the NEC Eagle/Hawk board. - * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com - * - * Copyright 2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * Copyright (C) 2002 MontaVista Software, Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* * Changes: * MontaVista Software Inc. or + * - New creation, NEC Eagle is supported. * - Added support for NEC Hawk. * - * MontaVista Software Inc. or - * - New creation, NEC Eagle is supported. + * Yoichi Yuasa + * - Changed from board_irq_init to driver module. */ +#include #include #include +#include +#include #include #include +MODULE_DESCRIPTION("IRQ module driver for NEC Eagle/Hawk"); +MODULE_AUTHOR("Yoichi Yuasa "); +MODULE_LICENSE("GPL"); + static void enable_pciint_irq(unsigned int irq) { - u8 val; + uint8_t val; val = readb(NEC_EAGLE_PCIINTMSKREG); - val |= (u8)1 << (irq - PCIINT_IRQ_BASE); + val |= (uint8_t)1 << (irq - PCIINT_IRQ_BASE); writeb(val, NEC_EAGLE_PCIINTMSKREG); } static void disable_pciint_irq(unsigned int irq) { - u8 val; + uint8_t val; val = readb(NEC_EAGLE_PCIINTMSKREG); - val &= ~((u8)1 << (irq - PCIINT_IRQ_BASE)); + val &= ~((uint8_t)1 << (irq - PCIINT_IRQ_BASE)); writeb(val, NEC_EAGLE_PCIINTMSKREG); } @@ -78,31 +75,30 @@ } static struct hw_interrupt_type pciint_irq_type = { - "PCIINT", - startup_pciint_irq, - shutdown_pciint_irq, - enable_pciint_irq, - disable_pciint_irq, - ack_pciint_irq, - end_pciint_irq, - NULL + .typename = "PCIINT", + .startup = startup_pciint_irq, + .shutdown = shutdown_pciint_irq, + .enable = enable_pciint_irq, + .disable = disable_pciint_irq, + .ack = ack_pciint_irq, + .end = end_pciint_irq, }; static void enable_sdbint_irq(unsigned int irq) { - u8 val; + uint8_t val; val = readb(NEC_EAGLE_SDBINTMSK); - val |= (u8)1 << (irq - SDBINT_IRQ_BASE); + val |= (uint8_t)1 << (irq - SDBINT_IRQ_BASE); writeb(val, NEC_EAGLE_SDBINTMSK); } static void disable_sdbint_irq(unsigned int irq) { - u8 val; + uint8_t val; val = readb(NEC_EAGLE_SDBINTMSK); - val &= ~((u8)1 << (irq - SDBINT_IRQ_BASE)); + val &= ~((uint8_t)1 << (irq - SDBINT_IRQ_BASE)); writeb(val, NEC_EAGLE_SDBINTMSK); } @@ -122,19 +118,18 @@ } static struct hw_interrupt_type sdbint_irq_type = { - "SDBINT", - startup_sdbint_irq, - shutdown_sdbint_irq, - enable_sdbint_irq, - disable_sdbint_irq, - ack_sdbint_irq, - end_sdbint_irq, - NULL + .typename = "SDBINT", + .startup = startup_sdbint_irq, + .shutdown = shutdown_sdbint_irq, + .enable = enable_sdbint_irq, + .disable = disable_sdbint_irq, + .ack = ack_sdbint_irq, + .end = end_sdbint_irq, }; static int eagle_get_irq_number(int irq) { - u8 sdbint, pciint; + uint8_t sdbint, pciint; int i; sdbint = readb(NEC_EAGLE_SDBINT); @@ -157,9 +152,9 @@ return -EINVAL; } -void __init eagle_irq_init(void) +static int __devinit eagle_irq_init(void) { - int i; + int i, retval; writeb(0, NEC_EAGLE_SDBINTMSK); writeb(0, NEC_EAGLE_PCIINTMSKREG); @@ -179,5 +174,17 @@ for (i = PCIINT_IRQ_BASE; i <= PCIINT_IRQ_LAST; i++) irq_desc[i].handler = &pciint_irq_type; - vr41xx_cascade_irq(FPGA_CASCADE_IRQ, eagle_get_irq_number); + retval = vr41xx_cascade_irq(FPGA_CASCADE_IRQ, eagle_get_irq_number); + if (retval != 0) + printk(KERN_ERR "eagle: Cannot cascade IRQ %d\n", FPGA_CASCADE_IRQ); + + return retval; } + +static void __devexit eagle_irq_exit(void) +{ + free_irq(FPGA_CASCADE_IRQ, NULL); +} + +module_init(eagle_irq_init); +module_exit(eagle_irq_exit); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Thu Feb 26 00:23:50 2004 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Thu Feb 26 00:49:14 2004 @@ -17,8 +17,6 @@ #include #include -extern void eagle_irq_init(void); - #ifdef CONFIG_PCI extern void vrc4173_preinit(void); @@ -80,8 +78,6 @@ set_io_port_base(IO_PORT_BASE); ioport_resource.start = IO_PORT_RESOURCE_START; ioport_resource.end = IO_PORT_RESOURCE_END; - - board_irq_init = eagle_irq_init; #ifdef CONFIG_SERIAL_8250 vr41xx_dsiu_init(); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Thu Feb 26 00:24:02 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Thu Feb 26 00:49:14 2004 @@ -133,7 +133,6 @@ #define GIU_IRQ_LAST GIU_IRQ(31) #define GIU_IRQ_TO_PIN(x) ((x) - GIU_IRQ_BASE) /* Pin 0-31 */ -extern void (*board_irq_init)(void); extern int vr41xx_set_intassign(unsigned int irq, unsigned char intassign); extern int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq)); From ralf@linux-mips.org Wed Feb 25 17:13:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 17:13:24 +0000 (GMT) Received: from p508B5CC5.dip.t-dialin.net ([IPv6:::ffff:80.139.92.197]:18014 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 17:13:23 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1PHDLex018869; Wed, 25 Feb 2004 18:13:21 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1PHDFRb018868; Wed, 25 Feb 2004 18:13:15 +0100 Date: Wed, 25 Feb 2004 18:13:15 +0100 From: Ralf Baechle To: "Liu Hongming (Alan)" Cc: Alan Cox , linux-mips@linux-mips.org Subject: Re: IDE driver problem Message-ID: <20040225171315.GB17217@linux-mips.org> References: <15F9E1AE3207D6119CEA00D0B7DD5F680219C882@TMTMS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15F9E1AE3207D6119CEA00D0B7DD5F680219C882@TMTMS> 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: 4440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 25, 2004 at 08:11:54PM +0800, Liu Hongming (Alan) wrote: > I have found out where the problem is. Since my hardware has > endian issue, fs/partition/msdos.c could not handle partition table > correctly. I have changed a little(still having much to change),and it > really works now. I'm not sure what you call endian issue here. The PC style partition table code we've used for years on big endian systems without problems. Ralf From geert@linux-m68k.org Wed Feb 25 17:38:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 17:38:23 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:42907 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 17:38:21 +0000 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i1PHcHD2018351; Wed, 25 Feb 2004 18:38:17 +0100 (MET) Date: Wed, 25 Feb 2004 18:38:17 +0100 (MET) From: Geert Uytterhoeven To: Ralf Baechle cc: "Liu Hongming (Alan)" , Alan Cox , Linux/MIPS Development Subject: Re: IDE driver problem In-Reply-To: <20040225171315.GB17217@linux-mips.org> Message-ID: References: <15F9E1AE3207D6119CEA00D0B7DD5F680219C882@TMTMS> <20040225171315.GB17217@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: 4441 X-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, 25 Feb 2004, Ralf Baechle wrote: > On Wed, Feb 25, 2004 at 08:11:54PM +0800, Liu Hongming (Alan) wrote: > > I have found out where the problem is. Since my hardware has > > endian issue, fs/partition/msdos.c could not handle partition table > > correctly. I have changed a little(still having much to change),and it > > really works now. > > I'm not sure what you call endian issue here. The PC style partition > table code we've used for years on big endian systems without problems. I guess his hardware has a byteswapped IDE bus, like on Atari, Q40/Q60 and Tivo. 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 wlacey@goldenhindresearch.com Wed Feb 25 17:49:26 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 17:49:27 +0000 (GMT) Received: from server212.com ([IPv6:::ffff:203.194.159.163]:21737 "HELO server212.com") by linux-mips.org with SMTP id ; Wed, 25 Feb 2004 17:49:26 +0000 Received: (qmail 10839 invoked by uid 501); 25 Feb 2004 17:50:56 -0000 Message-ID: <20040225175056.17002.qmail@server212.com> Reply-To: "wlacey" From: "wlacey" To: linux-mips@linux-mips.org Subject: dead RTL8139D eth Date: Wed, 25 Feb 2004 17:50:56 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_bc36cd5b2aab80bfed7a4852a2de6c422" X-Mailer: WebMail 2.3 X-Originating-IP: 65.60.194.102 X-Originating-Email: wlacey@goldenhindresearch.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: 4442 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wlacey@goldenhindresearch.com Precedence: bulk X-list: linux-mips --_bc36cd5b2aab80bfed7a4852a2de6c422 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I'm currently bringing up a 2.4.28 based kernel on a tx4925 equipped board attempting to use an NFS'ed root filesystem. The problem is I never see the initial RPC requests from the target to the host machine. The target knows via boot options it's ip address and the address of the nfs host. The attempt at transfer fails, I never see reception of _any_ message on the host and the interface statistics never reflect that any packet has even been attempted to be sent. i.e. tx bytes/packes are always zero. Some output follows... RPC: rpc_execute flgs 0 start_xmit() max(len:42 ETH_ZLEN:60) 60 Post xmit stats tx_bytes:0 tx_packets:0 tx_dropped:0 Post xmit stats rx_bytes:0 rx_packets:0 rx_dropped:0 start_xmit() max(len:42 ETH_ZLEN:60) 60 Post xmit stats tx_bytes:0 tx_packets:0 tx_dropped:0 Post xmit stats rx_bytes:0 rx_packets:0 rx_dropped:0 start_xmit() max(len:42 ETH_ZLEN:60) 60 Post xmit stats tx_bytes:0 tx_packets:0 tx_dropped:0 Post xmit stats rx_bytes:0 rx_packets:0 rx_dropped:0 start_xmit() max(len:42 ETH_ZLEN:60) 60 Post xmit stats tx_bytes:0 tx_packets:0 tx_dropped:0 Post xmit stats rx_bytes:0 rx_packets:0 rx_dropped:0 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 0d 0040 media 10. io address:00001000 inl:8014baac eth0: Tx queue start entry 4 dirty entry 0. eth0: Tx descriptor 0 is 00002000. (queue head) eth0: Tx descriptor 1 is 00002000. eth0: Tx descriptor 2 is 00002000. eth0: Tx descriptor 3 is 00002000. eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1. What am I doing wrong? Warrick Lacey --_bc36cd5b2aab80bfed7a4852a2de6c422 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
I'm currently bringing up a 2.4.28 based kernel on a tx4925 equipped board attempting to use an NFS'ed root filesystem.

The problem is I never see the initial RPC requests from the target to the host machine. The target knows via boot options it's ip address and the address of the nfs host.

The attempt at transfer fails, I never see reception of _any_ message on the host and the interface statistics never reflect that any packet has even been attempted to be sent. i.e. tx bytes/packes are always zero.

Some output follows...

RPC: rpc_execute flgs 0
start_xmit() max(len:42 ETH_ZLEN:60) 60
Post xmit stats tx_bytes:0 tx_packets:0 tx_dropped:0
Post xmit stats rx_bytes:0 rx_packets:0 rx_dropped:0
start_xmit() max(len:42 ETH_ZLEN:60) 60
Post xmit stats tx_bytes:0 tx_packets:0 tx_dropped:0
Post xmit stats rx_bytes:0 rx_packets:0 rx_dropped:0
start_xmit() max(len:42 ETH_ZLEN:60) 60
Post xmit stats tx_bytes:0 tx_packets:0 tx_dropped:0
Post xmit stats rx_bytes:0 rx_packets:0 rx_dropped:0
start_xmit() max(len:42 ETH_ZLEN:60) 60
Post xmit stats tx_bytes:0 tx_packets:0 tx_dropped:0
Post xmit stats rx_bytes:0 rx_packets:0 rx_dropped:0
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0040 media 10.
io address:00001000 inl:8014baac
eth0: Tx queue start entry 4 dirty entry 0.
eth0: Tx descriptor 0 is 00002000. (queue head)
eth0: Tx descriptor 1 is 00002000.
eth0: Tx descriptor 2 is 00002000.
eth0: Tx descriptor 3 is 00002000.
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.

What am I doing wrong?

Warrick Lacey




--_bc36cd5b2aab80bfed7a4852a2de6c422-- From ralf@linux-mips.org Wed Feb 25 18:16:50 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 18:16:50 +0000 (GMT) Received: from p508B5CC5.dip.t-dialin.net ([IPv6:::ffff:80.139.92.197]:14431 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 18:16:50 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1PIGlex010801; Wed, 25 Feb 2004 19:16:47 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1PIGjFE010800; Wed, 25 Feb 2004 19:16:45 +0100 Date: Wed, 25 Feb 2004 19:16:45 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: "Liu Hongming (Alan)" , Alan Cox , Linux/MIPS Development Subject: Re: IDE driver problem Message-ID: <20040225181645.GA10742@linux-mips.org> References: <15F9E1AE3207D6119CEA00D0B7DD5F680219C882@TMTMS> <20040225171315.GB17217@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: 4443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 25, 2004 at 06:38:17PM +0100, Geert Uytterhoeven wrote: > > I'm not sure what you call endian issue here. The PC style partition > > table code we've used for years on big endian systems without problems. > > I guess his hardware has a byteswapped IDE bus, like on Atari, Q40/Q60 and > Tivo. Oh, those. I fear every possible way to hookup the IDE bus in a more or particularly less intelligent way to a system has already been found out there ... Ralf From jbglaw@dvmwest.gt.owl.de Wed Feb 25 19:12:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 19:12:10 +0000 (GMT) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:10702 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 19:12:07 +0000 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 5C2914B54A; Wed, 25 Feb 2004 20:11:57 +0100 (CET) Date: Wed, 25 Feb 2004 20:11:57 +0100 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: [PATCH] VSXXX-AA mouse and LK[24]01 keyboard Message-ID: <20040225191157.GD5838@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="brEuL7wsLY8+TuWz" Content-Disposition: inline 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.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4444 X-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 --brEuL7wsLY8+TuWz Content-Type: multipart/mixed; boundary="sgneBHv3152wZ8jf" Content-Disposition: inline --sgneBHv3152wZ8jf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! This is my current patchset adding in-kernel drivers (based on serio and Input API). I'm currently using the keyboard driver to write this email (with an adaptor on my PeeCee). I've not yet build an adaptor for the mouse, but it emits bytes off the generic PS2 mouse interface on a VAX so it can't be all that wrong :) While this is the first Input API driver for the VSXXX-AA mouse, there already exists a LK driver. Please choose which one you like better. Of course, comments are highly welcome! 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)); --sgneBHv3152wZ8jf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="DEC-Input.diff" Content-Transfer-Encoding: quoted-printable Index: include/linux/serio.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ftp/pub/mirror/CVS/ftp.linux-mips.org/linux/include/linux/s= erio.h,v retrieving revision 1.14 diff -u -r1.14 serio.h --- a/include/linux/serio.h 10 Jan 2004 04:59:57 -0000 1.14 +++ b/include/linux/serio.h 25 Feb 2004 19:02:19 -0000 @@ -117,6 +117,7 @@ #define SERIO_MZ 0x05 #define SERIO_MZP 0x06 #define SERIO_MZPP 0x07 +#define SERIO_VSXXXAA 0x08 #define SERIO_SUNKBD 0x10 #define SERIO_WARRIOR 0x18 #define SERIO_SPACEORB 0x19 @@ -134,6 +135,7 @@ #define SERIO_HIL 0x25 #define SERIO_SNES232 0x26 #define SERIO_SEMTECH 0x27 +#define SERIO_LKKBD 0x28 =20 #define SERIO_ID 0xff00UL #define SERIO_EXTRA 0xff0000UL Index: drivers/input/keyboard/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ftp/pub/mirror/CVS/ftp.linux-mips.org/linux/drivers/input/k= eyboard/Makefile,v retrieving revision 1.5 diff -u -r1.5 Makefile --- a/drivers/input/keyboard/Makefile 5 Jun 2003 10:06:38 -0000 1.5 +++ b/drivers/input/keyboard/Makefile 25 Feb 2004 19:02:19 -0000 @@ -7,6 +7,7 @@ obj-$(CONFIG_KEYBOARD_ATKBD) +=3D atkbd.o obj-$(CONFIG_KEYBOARD_MAPLE) +=3D maple_keyb.o obj-$(CONFIG_KEYBOARD_SUNKBD) +=3D sunkbd.o +obj-$(CONFIG_KEYBOARD_LKKBD) +=3D lkkbd.o obj-$(CONFIG_KEYBOARD_XTKBD) +=3D xtkbd.o obj-$(CONFIG_KEYBOARD_AMIGA) +=3D amikbd.o obj-$(CONFIG_KEYBOARD_NEWTON) +=3D newtonkbd.o Index: drivers/input/keyboard/Kconfig =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ftp/pub/mirror/CVS/ftp.linux-mips.org/linux/drivers/input/k= eyboard/Kconfig,v retrieving revision 1.7 diff -u -r1.7 Kconfig --- a/drivers/input/keyboard/Kconfig 9 Oct 2003 13:09:30 -0000 1.7 +++ b/drivers/input/keyboard/Kconfig 25 Feb 2004 19:02:19 -0000 @@ -40,6 +40,18 @@ To compile this driver as a module, choose M here: the module will be called sunkbd. =20 +config KEYBOARD_LKKBD + tristate "DECstation / VAXstation LK keyboard support" + depends on INPUT && INPUT_KEYBOARD + select SERIO + help + Say Y here if you want to use a LK201 or LK401 style serial + keyboard. This keyboard is also useable on PCs if you attach + it with the inputattach program. + + To compile this driver as a module, choose M here: the + module will be called lkkbd. + config KEYBOARD_XTKBD tristate "XT Keyboard support" depends on INPUT && INPUT_KEYBOARD Index: drivers/input/mouse/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ftp/pub/mirror/CVS/ftp.linux-mips.org/linux/drivers/input/m= ouse/Makefile,v retrieving revision 1.6 diff -u -r1.6 Makefile --- a/drivers/input/mouse/Makefile 23 Jun 2003 01:23:05 -0000 1.6 +++ b/drivers/input/mouse/Makefile 25 Feb 2004 19:02:19 -0000 @@ -13,5 +13,6 @@ obj-$(CONFIG_MOUSE_PC9800) +=3D 98busmouse.o obj-$(CONFIG_MOUSE_PS2) +=3D psmouse.o obj-$(CONFIG_MOUSE_SERIAL) +=3D sermouse.o +obj-$(CONFIG_MOUSE_VSXXXAA) +=3D vsxxxaa.o =20 psmouse-objs :=3D psmouse-base.o logips2pp.o synaptics.o Index: drivers/input/mouse/Kconfig =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ftp/pub/mirror/CVS/ftp.linux-mips.org/linux/drivers/input/m= ouse/Kconfig,v retrieving revision 1.12 diff -u -r1.12 Kconfig --- a/drivers/input/mouse/Kconfig 5 Feb 2004 02:40:00 -0000 1.12 +++ b/drivers/input/mouse/Kconfig 25 Feb 2004 19:02:19 -0000 @@ -117,6 +117,18 @@ To compile this driver as a module, choose M here: the module will be called rpcmouse. =20 +config MOUSE_VSXXXAA + tristate "DEC VSXXX-AA/GA mouse and tablet" + depends on INPUT && INPUT_MOUSE + select SERIO + help + Say Y (or M) if you want to use a DEC VSXXX-AA (hockey + puck) or a VSXXX-GA (rectangular) mouse. Theses mice are + typically used on DECstations or VAXstations, but can also + be used on any box capable of RS232 (with some adaptor + described in the source file). This driver should, in theory, + also work with the tablet DEC produced... + config MOUSE_PC9800 tristate "NEC PC-9800 busmouse" depends on X86_PC9800 && INPUT && INPUT_MOUSE && ISA --- /dev/null 2004-02-01 01:00:40.000000000 +0100 +++ b/drivers/input/keyboard/lkkbd.c 2004-02-25 20:00:56.000000000 +0100 @@ -0,0 +1,532 @@ +/* + * Copyright (C) 2004 by Jan-Benedict Glaw + */ + +/* + * LK keyboard driver for Linux, based on sunkbd.c (C) by Vojtech Pavlik + */ + +/* + * DEC LK201 and LK401 keyboard driver for Linux (primary for DECstations + * and VAXstations, but can also be used on any standard RS232 with an + * adaptor). + * + * DISCLAUNER: This works for _me_. If you break anything by using the + * information given below, I will _not_ be lieable! + * + * RJ11 pinout: To DB9: Or DB25: + * 1 - RxD <----> Pin 3 (TxD) <-> Pin 2 (TxD) + * 2 - GND <----> Pin 5 (GND) <-> Pin 7 (GND) + * 4 - TxD <----> Pin 2 (RxD) <-> Pin 3 (RxD) + * 3 - +12V (from HDD drive connector), DON'T connect to DB9 or DB25!!! + * + * Pin numbers for DB9 and DB25 are noted on the plug (quite small:). For + * RJ11, it's like this: + * + * __=3D__ Hold the plug in front of you, cable downwards, + * /___/| nose is hidden behind the plug. Now, pin 1 is at + * |1234|| the left side, pin 4 at the right and 2 and 3 are + * |IIII|| in between, of course:) + * | || + * |____|/ + * || So the adaptor consists of three connected cables + * || for data transmission (RxD and TxD) and signal ground. + * Additionally, you have to get +12V from somewhere. + * Most easily, you'll get that from a floppy or HDD power connector. + * It's the yellow cable there (black is ground and red is +5V). + */ + +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or=20 + * (at your option) any later version. + *=20 + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + *=20 + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + *=20 + * Should you need to contact me, the author, you can do so either by + * email or by paper mail: + * Jan-Benedict Glaw, Lilienstra=DFe 16, 33790 H=F6rste (near Halle/Westf.= ), + * Germany. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +MODULE_AUTHOR ("Jan-Benedict Glaw "); +MODULE_DESCRIPTION ("LK keyboard driver"); +MODULE_LICENSE ("GPL"); + +#undef LKKBD_DEBUG +#ifdef LKKBD_DEBUG +#define DBG(x...) printk (x) +#else +#define DBG(x...) do {} while (0) +#endif + +static unsigned char lkkbd_keycode[256] =3D { + [0x56] =3D KEY_F1, + [0x57] =3D KEY_F2, + [0x58] =3D KEY_F3, + [0x59] =3D KEY_F4, + [0x5a] =3D KEY_F5, + [0x64] =3D KEY_F6, + [0x65] =3D KEY_F7, + [0x66] =3D KEY_F8, + [0x67] =3D KEY_F9, + [0x68] =3D KEY_F10, + [0x71] =3D KEY_F11, + [0x72] =3D KEY_F12, + [0x73] =3D KEY_F13, + [0x74] =3D KEY_F14, + [0x7c] =3D KEY_F15, + [0x7d] =3D KEY_F16, + [0x80] =3D KEY_F17, + [0x81] =3D KEY_F18, + [0x82] =3D KEY_F19, + [0x83] =3D KEY_F20, + [0x8a] =3D KEY_FIND, + [0x8b] =3D KEY_INSERT, + [0x8c] =3D KEY_DELETE, + [0x8d] =3D KEY_RESERVED, /* KEY_SELECT */ + [0x8e] =3D KEY_PAGEUP, + [0x8f] =3D KEY_PAGEDOWN, + [0x92] =3D KEY_KP0, + [0x94] =3D KEY_KPDOT, + [0x95] =3D KEY_KPENTER, + [0x96] =3D KEY_KP1, + [0x97] =3D KEY_KP2, + [0x98] =3D KEY_KP3, + [0x99] =3D KEY_KP4, + [0x9a] =3D KEY_KP5, + [0x9b] =3D KEY_KP6, + [0x9c] =3D KEY_KPCOMMA, + [0x9d] =3D KEY_KP7, + [0x9e] =3D KEY_KP8, + [0x9f] =3D KEY_KP9, + [0xa0] =3D KEY_KPMINUS, + [0xa1] =3D KEY_RESERVED, /* KP_PF1 */ + [0xa2] =3D KEY_RESERVED, /* KP_PF2 */ + [0xa3] =3D KEY_RESERVED, /* KP_PF3 */ + [0xa4] =3D KEY_RESERVED, /* KP_PF3 */ + [0xa7] =3D KEY_LEFT, + [0xa8] =3D KEY_RIGHT, + [0xa9] =3D KEY_DOWN, + [0xaa] =3D KEY_UP, + [0xab] =3D KEY_RIGHTSHIFT, + [0xac] =3D KEY_LEFTALT, + [0xad] =3D KEY_COMPOSE, /* Right Compose, that is. */ + [0xae] =3D KEY_LEFTSHIFT, /* Same as KEY_RIGHTSHIFT on LK201 */ + [0xaf] =3D KEY_LEFTCTRL, + [0xb0] =3D KEY_CAPSLOCK, + [0xb1] =3D KEY_COMPOSE, /* Left Compose, that is. */ + [0xb2] =3D KEY_RIGHTALT, + [0xbc] =3D KEY_BACKSPACE, + [0xbd] =3D KEY_ENTER, + [0xbe] =3D KEY_TAB, + [0xbf] =3D KEY_ESC, + [0xc0] =3D KEY_1, + [0xc1] =3D KEY_Q, + [0xc2] =3D KEY_A, + [0xc3] =3D KEY_Z, + [0xc5] =3D KEY_2, + [0xc6] =3D KEY_W, + [0xc7] =3D KEY_S, + [0xc8] =3D KEY_X, + [0xc9] =3D KEY_102ND, + [0xcb] =3D KEY_3, + [0xcc] =3D KEY_E, + [0xcd] =3D KEY_D, + [0xce] =3D KEY_C, + [0xd0] =3D KEY_4, + [0xd1] =3D KEY_R, + [0xd2] =3D KEY_F, + [0xd3] =3D KEY_V, + [0xd4] =3D KEY_SPACE, + [0xd6] =3D KEY_5, + [0xd7] =3D KEY_T, + [0xd8] =3D KEY_G, + [0xd9] =3D KEY_B, + [0xdb] =3D KEY_6, + [0xdc] =3D KEY_Y, + [0xdd] =3D KEY_H, + [0xde] =3D KEY_N, + [0xe0] =3D KEY_7, + [0xe1] =3D KEY_U, + [0xe2] =3D KEY_J, + [0xe3] =3D KEY_M, + [0xe5] =3D KEY_8, + [0xe6] =3D KEY_I, + [0xe7] =3D KEY_K, + [0xe8] =3D KEY_COMMA, + [0xea] =3D KEY_9, + [0xeb] =3D KEY_O, + [0xec] =3D KEY_L, + [0xed] =3D KEY_DOT, + [0xef] =3D KEY_0, + [0xf0] =3D KEY_P, + [0xf2] =3D KEY_SEMICOLON, + [0xf3] =3D KEY_SLASH, + [0xf5] =3D KEY_EQUAL, + [0xf6] =3D KEY_RIGHTBRACE, + [0xf7] =3D KEY_BACKSLASH, + [0xf9] =3D KEY_MINUS, + [0xfa] =3D KEY_LEFTBRACE, + [0xfb] =3D KEY_APOSTROPHE, +}; + +/* LED control */ +#define LK_LED_WAIT 0x81 +#define LK_LED_COMPOSE 0x82 +#define LK_LED_SHIFTLOCK 0x84 +#define LK_LED_SCROLLLOCK 0x88 +#define LK_CMD_LED_ON 0x13 +#define LK_CMD_LED_OFF 0x11 + +/* Mode control */ +#define LK_MODE_DOWN 0x80 +#define LK_MODE_AUTODOWN 0x82 +#define LK_MODE_UPDOWN 0x86 +#define LK_CMD_SET_MODE(mode,div) ((mode) | ((div) << 3)) + +/* Misc commands */ +#define LK_CMD_SOUND_BELL 0xa7 +#define LK_CMD_SET_DEFAULTS 0xd3 +#define LK_CMD_POWERCYCLE_RESET 0xfd +#define LK_CMD_ENABLE_LK401 0xe9 + +/* Misc responses from keyboard */ +#define LK_ALL_KEYS_UP 0xb3 +#define LK_METRONOME 0xb4 +#define LK_OUTPUT_ERROR 0xb5 +#define LK_INPUT_ERROR 0xb6 +#define LK_KBD_LOCKED 0xb7 +#define LK_KBD_TEST_MODE_ACK 0xb8 +#define LK_PREFIX_KEY_DOWN 0xb9 +#define LK_MODE_CHANGE_ACK 0xba +#define LK_RESPONSE_RESERVED 0xbb + +#define CHECK_LED(LED, BITS) do { \ + if (test_bit (LED, lk->dev.led)) \ + leds_on |=3D BITS; \ + else \ + leds_off |=3D BITS; \ + } while (0) + +/* + * Per-keyboard data + */ +struct lkkbd { + unsigned char keycode[256]; + int ignore_bytes; + struct input_dev dev; + struct serio *serio; + struct work_struct tq; + char name[64]; + char phys[32]; + char type; +}; + +/* + * lkkbd_interrupt() is called by the low level driver when a character + * is received. + */ +static irqreturn_t +lkkbd_interrupt (struct serio *serio, unsigned char data, unsigned int fla= gs, + struct pt_regs *regs) +{ + struct lkkbd *lk =3D serio->private; + int i; + + DBG (KERN_INFO "Got byte 0x%02x\n", data); + + if (lk->ignore_bytes > 0) { + DBG (KERN_INFO "Ignoring a byte on %s\n", + lk->name); + lk->ignore_bytes--; + return IRQ_HANDLED; + } + + switch (data) { + case LK_ALL_KEYS_UP: + input_regs (&lk->dev, regs); + for (i =3D 0; i < ARRAY_SIZE (lkkbd_keycode); i++) + if (lk->keycode[i] !=3D KEY_RESERVED) + input_report_key (&lk->dev, lk->keycode[i], 0); + input_sync (&lk->dev); + break; + case LK_METRONOME: + DBG (KERN_INFO "Got LK_METRONOME and don't " + "know how to handle...\n"); + break; + case LK_OUTPUT_ERROR: + DBG (KERN_INFO "Got LK_OUTPUT_ERROR and don't " + "know how to handle...\n"); + break; + case LK_INPUT_ERROR: + DBG (KERN_INFO "Got LK_INPUT_ERROR and don't " + "know how to handle...\n"); + break; + case LK_KBD_LOCKED: + DBG (KERN_INFO "Got LK_KBD_LOCKED and don't " + "know how to handle...\n"); + break; + case LK_KBD_TEST_MODE_ACK: + DBG (KERN_INFO "Got LK_KBD_TEST_MODE_ACK and don't " + "know how to handle...\n"); + break; + case LK_PREFIX_KEY_DOWN: + DBG (KERN_INFO "Got LK_PREFIX_KEY_DOWN and don't " + "know how to handle...\n"); + break; + case LK_MODE_CHANGE_ACK: + DBG (KERN_INFO "Got LK_MODE_CHANGE_ACK and ignored " + "it properly...\n"); + break; + case LK_RESPONSE_RESERVED: + DBG (KERN_INFO "Got LK_RESPONSE_RESERVED and don't " + "know how to handle...\n"); + break; + case 0x01: + DBG (KERN_INFO "Got 0x01, scheduling re-initialization\n"); + lk->ignore_bytes =3D 3; + schedule_work (&lk->tq); + break; + + default: + if (lk->keycode[data] !=3D KEY_RESERVED) { + input_regs (&lk->dev, regs); + if (!test_bit (lk->keycode[data], lk->dev.key)) + input_report_key (&lk->dev, lk->keycode[data], 1); + else + input_report_key (&lk->dev, lk->keycode[data], 0); + input_sync (&lk->dev); + } else + printk (KERN_WARNING "%s: Unknown key with= " + "scancode %02x on %s.\n", + __FILE__, data, lk->name); + } + + return IRQ_HANDLED; +} + +/* + * lkkbd_event() handles events from the input module. + */ +static int +lkkbd_event (struct input_dev *dev, unsigned int type, unsigned int code, + int value) +{ + struct lkkbd *lk =3D dev->private; + unsigned char leds_on =3D 0; + unsigned char leds_off =3D 0; + + switch (type) { + case EV_LED: + CHECK_LED (LED_CAPSL, LK_LED_SHIFTLOCK); + CHECK_LED (LED_COMPOSE, LK_LED_COMPOSE); + CHECK_LED (LED_SCROLLL, LK_LED_SCROLLLOCK); + CHECK_LED (LED_SLEEP, LK_LED_WAIT); + if (leds_on !=3D 0) { + lk->serio->write (lk->serio, LK_CMD_LED_ON); + lk->serio->write (lk->serio, leds_on); + } + if (leds_off !=3D 0) { + lk->serio->write (lk->serio, LK_CMD_LED_OFF); + lk->serio->write (lk->serio, leds_off); + } + return 0; + + case EV_SND: + switch (code) { + case SND_CLICK: + /* + * Mostly, I don't know if I need + * to once sound a key click or I'm + * ment to enable it for all + * upcoming key presses... + */ + printk (KERN_ERR "EV_SND/SND_CLICK: Don't know how to handle...\n"); + return -1; +=09 + case SND_BELL: + if (value !=3D 0) + lk->serio->write (lk->serio, LK_CMD_SOUND_BELL); + return 0; + } + break; + + default: + printk (KERN_ERR "%s(): Got unknown type %d, code %d, value %d\n", + __FUNCTION__, type, code, value); + } + + return -1; +} + +/* + * lkkbd_reinit() sets leds and beeps to a state the computer remembers th= ey + * were in. + */ +static void +lkkbd_reinit (void *data) +{ + struct lkkbd *lk =3D data; + int division; + unsigned char leds_on =3D 0; + unsigned char leds_off =3D 0; + + /* Reset parameters */ + lk->serio->write (lk->serio, LK_CMD_SET_DEFAULTS); + + /* Set LEDs */ + CHECK_LED (LED_CAPSL, LK_LED_SHIFTLOCK); + CHECK_LED (LED_COMPOSE, LK_LED_COMPOSE); + CHECK_LED (LED_SCROLLL, LK_LED_SCROLLLOCK); + CHECK_LED (LED_SLEEP, LK_LED_WAIT); + if (leds_on !=3D 0) { + lk->serio->write (lk->serio, LK_CMD_LED_ON); + lk->serio->write (lk->serio, leds_on); + } + if (leds_off !=3D 0) { + lk->serio->write (lk->serio, LK_CMD_LED_OFF); + lk->serio->write (lk->serio, leds_off); + } + + /* + * Try to activate extended LK401 mode. This command will + * only work with a LK401 keyboard and grants access to + * LAlt, RAlt, RCompose and RShift. + */ + lk->serio->write (lk->serio, LK_CMD_ENABLE_LK401); + + /* Set all keys to UPDOWN mode */ + for (division =3D 1; division <=3D 14; division++) + lk->serio->write (lk->serio, LK_CMD_SET_MODE (LK_MODE_UPDOWN, + division)); + +#warning Need to set click / bell + /* Need to click? */ +#if 0 + lk->serio->write (lk->serio, SUNKBD_CMD_NOCLICK - !!test_bit(SND_CLICK, s= unkbd->dev.snd)); + lk->serio->write (lk->serio, SUNKBD_CMD_BELLOFF - !!test_bit(SND_BELL, su= nkbd->dev.snd)); +#endif +} + +/* + * lkkbd_connect() probes for a LK keyboard and fills the necessary struct= ures. + */ +static void +lkkbd_connect (struct serio *serio, struct serio_dev *dev) +{ + struct lkkbd *lk; + int i; + + if ((serio->type & SERIO_TYPE) !=3D SERIO_RS232) + return; + if (!(serio->type & SERIO_PROTO)) + return; + if ((serio->type & SERIO_PROTO) && (serio->type & SERIO_PROTO) !=3D SERIO= _LKKBD) + return; + + if (!(lk =3D kmalloc (sizeof (struct lkkbd), GFP_KERNEL))) + return; + memset (lk, 0, sizeof (struct lkkbd)); + + init_input_dev (&lk->dev); + + lk->dev.evbit[0] =3D BIT (EV_KEY) | BIT (EV_LED) | BIT (EV_SND) | BIT (EV= _REP); + lk->dev.ledbit[0] =3D BIT (LED_CAPSL) | BIT (LED_COMPOSE) | BIT (LED_SCRO= LLL) | BIT (LED_SLEEP); + lk->dev.sndbit[0] =3D BIT (SND_CLICK) | BIT (SND_BELL); + + lk->serio =3D serio; + + INIT_WORK (&lk->tq, lkkbd_reinit, lk); + + lk->dev.keycode =3D lk->keycode; + lk->dev.keycodesize =3D sizeof (unsigned char); + lk->dev.keycodemax =3D ARRAY_SIZE (lkkbd_keycode); + + lk->dev.event =3D lkkbd_event; + lk->dev.private =3D lk; + + serio->private =3D lk; + + if (serio_open (serio, dev)) { + kfree (lk); + return; + } + + sprintf (lk->name, "LK keyboard"); + + memcpy (lk->keycode, lkkbd_keycode, sizeof (lk->keycode)); + for (i =3D 0; i < ARRAY_SIZE (lkkbd_keycode); i++) + set_bit (lk->keycode[i], lk->dev.keybit); + clear_bit (0, lk->dev.keybit); + + sprintf (lk->name, "%s/input0", serio->phys); + + lk->dev.name =3D lk->name; + lk->dev.phys =3D lk->phys; + lk->dev.id.bustype =3D BUS_RS232; + lk->dev.id.vendor =3D SERIO_LKKBD; + lk->dev.id.product =3D 0; + lk->dev.id.version =3D 0x0100; + + input_register_device (&lk->dev); + + printk (KERN_INFO "input: %s on %s, initiating reset\n", lk->name, serio-= >phys); + lk->serio->write (lk->serio, LK_CMD_POWERCYCLE_RESET); +} + +/* + * lkkbd_disconnect() unregisters and closes behind us. + */ +static void +lkkbd_disconnect (struct serio *serio) +{ + struct lkkbd *lk =3D serio->private; + + input_unregister_device (&lk->dev); + serio_close (serio); + kfree (lk); +} + +static struct serio_dev lkkbd_dev =3D { + .interrupt =3D lkkbd_interrupt, + .connect =3D lkkbd_connect, + .disconnect =3D lkkbd_disconnect, +}; + +/* + * The functions for insering/removing us as a module. + */ +int __init +lkkbd_init (void) +{ + serio_register_device (&lkkbd_dev); + return 0; +} + +void __exit +lkkbd_exit (void) +{ + serio_unregister_device (&lkkbd_dev); +} + +module_init (lkkbd_init); +module_exit (lkkbd_exit); + --- /dev/null 2004-02-01 01:00:40.000000000 +0100 +++ b/drivers/input/mouse/vsxxxaa.c 2004-02-25 19:57:03.000000000 +0100 @@ -0,0 +1,550 @@ +/* + * DEC VSXXX-AA and VSXXX-GA mouse driver. + * + * Copyright (C) 2003-2004 by Jan-Benedict Glaw + * + * The packet format was taken from a patch to GPM which is (C) 2001 + * by Karsten Merker + * and Maciej W. Rozycki + */ + +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or=20 + * (at your option) any later version. + *=20 + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + *=20 + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/* + * Building an adaptor to DB9 / DB25 RS232 + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + * + * DISCLAIMER: Use this description AT YOUR OWN RISK! I'll not pay for + * anything if you break your mouse, your computer or whatever! + * + * In theory, this mouse is a simple RS232 device. In practice, it has got + * a quite uncommon plug and the requirement to additionally get a power + * supply at +5V and -12V. + * + * If you look at the socket/jack (_not_ at the plug), we use this pin + * numbering: + * _______ + * / 7 6 5 \ + * | 4 --- 3 | + * \ 2 1 / + * ------- + *=20 + * DEC socket DB9 DB25 Note + * 1 (GND) 5 7 - + * 2 (RxD) 3 3 - + * 3 (TxD) 2 2 - + * 4 (-12V) - - Somewhere from the PSU. At ATX, it's + * the blue wire at pin 12 of the ATX + * power connector. Please note that the + * docs say this should be +12V! However, + * I measured -12V... + * 5 (+5V) - - PSU (red wire of ATX power connector + * on pin 4, 6, 19 or 20) or HDD power + * connector (also red wire) + * 6 (not conn.) - - - + * 7 (dev. avail.) - - The mouse shorts this one to pin 1. + * This way, the host computer can detect + * the mouse. To use it with the adaptor, + * simply don't connect this pin. + * + * So to get a working adaptor, you need to connect the mouse with three + * wires to a RS232 port and two additional wires for +5V and -12V to the + * PSU. + * + * Flow specification for the link is 4800, 8o1. + */ + +/* + * TODO list: + * - Automatically attach to a given serial port (no need for inputattach). + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +MODULE_AUTHOR ("Jan-Benedict Glaw "); +MODULE_DESCRIPTION ("Serial DEC VSXXX-AA/GA mouse / DEC tablet driver"); +MODULE_LICENSE ("GPL"); + +#undef VSXXXAA_DEBUG +#ifdef VSXXXAA_DEBUG +#define DBG(x...) printk (x) +#else +#define DBG(x...) do {} while (0) +#endif + +#define VSXXXAA_INTRO_MASK 0x80 +#define VSXXXAA_INTRO_HEAD 0x80 +#define IS_HDR_BYTE(x) (((x) & VSXXXAA_INTRO_MASK) \ + =3D=3D VSXXXAA_INTRO_HEAD) + +#define VSXXXAA_PACKET_MASK 0xe0 +#define VSXXXAA_PACKET_REL 0x80 +#define VSXXXAA_PACKET_ABS 0xc0 +#define VSXXXAA_PACKET_POR 0xa0 +#define MATCH_PACKET_TYPE(data, type) (((data) & VSXXXAA_PACKET_MASK) =3D= =3D type) + + + +struct vsxxxaa { + struct input_dev dev; + struct serio *serio; +#define BUFLEN 15 /* At least 5 is needed for a full tablet packet */ + unsigned char buf[BUFLEN]; + unsigned char count; + unsigned char version; + unsigned char country; + unsigned char type; + char phys[32]; +}; + +static void +vsxxxaa_drop_bytes (struct vsxxxaa *mouse, int num) +{ + if (num >=3D mouse->count) + mouse->count =3D 0; + else { + memmove (mouse->buf, mouse->buf + num - 1, BUFLEN - num); + mouse->count -=3D num; + } +} + +static void +vsxxxaa_queue_byte (struct vsxxxaa *mouse, unsigned char byte) +{ + if (mouse->count =3D=3D BUFLEN) { + printk (KERN_ERR "%s on %s: Dropping a byte of full buffer.\n", + mouse->dev.name, mouse->dev.phys); + vsxxxaa_drop_bytes (mouse, 1); + } + + mouse->buf[mouse->count++] =3D byte; +} + +static void +vsxxxaa_report_mouse (struct vsxxxaa *mouse) +{ + char *devtype; + + switch (mouse->type) { + case 0x02: devtype =3D "DEC mouse"; break; + case 0x04: devtype =3D "DEC tablet"; break; + default: devtype =3D "unknown DEC device"; break; + } + + printk (KERN_INFO "Found %s version 0x%x from country 0x%x " + "on port %s\n", devtype, mouse->version, + mouse->country, mouse->dev.phys); +} + +/* + * Returns number of bytes to be dropped, 0 if packet is okay. + */ +static int +vsxxxaa_check_packet (struct vsxxxaa *mouse, int packet_len) +{ + int i; + + /* First byte must be a header byte */ + if (!IS_HDR_BYTE (mouse->buf[0])) { + DBG ("vsck: len=3D%d, 1st=3D0x%02x\n", packet_len, mouse->buf[0]); + return 1; + } + + /* Check all following bytes */ + if (packet_len > 1) { + for (i =3D 1; i < packet_len; i++) { + if (IS_HDR_BYTE (mouse->buf[i])) { + printk (KERN_ERR "Need to drop %d bytes " + "of a broken packet.\n", + i - 1); + DBG (KERN_INFO "check: len=3D%d, b[%d]=3D0x%02x\n", + packet_len, i, mouse->buf[i]); + return i - 1; + } + } + } + + return 0; +} + +static __inline__ int +vsxxxaa_smells_like_packet (struct vsxxxaa *mouse, unsigned char type, siz= e_t len) +{ + return (mouse->count >=3D len) && MATCH_PACKET_TYPE (mouse->buf[0], type); +} + +static void +vsxxxaa_handle_REL_packet (struct vsxxxaa *mouse, struct pt_regs *regs) +{ + struct input_dev *dev =3D &mouse->dev; + unsigned char *buf =3D mouse->buf; + int left, middle, right; + int dx, dy; + + /* + * Check for normal stream packets. This is three bytes, + * with the first byte's 3 MSB set to 100. + * + * [0]: 1 0 0 SignX SignY Left Middle Right + * [1]: 0 dx dx dx dx dx dx dx + * [2]: 0 dy dy dy dy dy dy dy + */ + + /* + * Low 7 bit of byte 1 are abs(dx), bit 7 is + * 0, bit 4 of byte 0 is direction. + */ + dx =3D buf[1] & 0x7f; + dx *=3D ((buf[0] >> 4) & 0x01)? -1: 1; + + /* + * Low 7 bit of byte 2 are abs(dy), bit 7 is + * 0, bit 3 of byte 0 is direction. + */ + dy =3D buf[2] & 0x7f; + dy *=3D ((buf[0] >> 3) & 0x01)? -1: 1; + + /* + * Get button state. It's the low three bits + * (for three buttons) of byte 0. + */ + left =3D (buf[0] & 0x04)? 1: 0; + middle =3D (buf[0] & 0x02)? 1: 0; + right =3D (buf[0] & 0x01)? 1: 0; + + vsxxxaa_drop_bytes (mouse, 3); + + DBG (KERN_INFO "%s on %s: dx=3D%d, dy=3D%d, buttons=3D%s%s%s\n", + mouse->dev.name, mouse->dev.phys, dx, dy, + left? "L": "l", middle? "M": "m", right? "R": "r"); + + /* + * Report what we've found so far... + */ + input_regs (dev, regs); + input_report_key (dev, BTN_LEFT, left); + input_report_key (dev, BTN_MIDDLE, middle); + input_report_key (dev, BTN_RIGHT, right); + input_report_rel (dev, REL_X, dx); + input_report_rel (dev, REL_Y, dy); + input_sync (dev); +} + +static void +vsxxxaa_handle_ABS_packet (struct vsxxxaa *mouse, struct pt_regs *regs) +{ + struct input_dev *dev =3D &mouse->dev; + unsigned char *buf =3D mouse->buf; + int left, middle, right, extra; + int x, y; + + /* + * Tablet position / button packet + * + * [0]: 1 1 0 B4 B3 B2 B1 Pr + * [1]: 0 0 X5 X4 X3 X2 X1 X0 + * [2]: 0 0 X11 X10 X9 X8 X7 X6 + * [3]: 0 0 Y5 Y4 Y3 Y2 Y1 Y0 + * [4]: 0 0 Y11 Y10 Y9 Y8 Y7 Y6 + */ + + /* + * Get X/Y position + */ + x =3D ((buf[2] & 0x3f) << 6) | (buf[1] & 0x3f); + y =3D ((buf[4] & 0x3f) << 6) | (buf[3] & 0x3f); + + /* + * Get button state. It's bits <4..1> of byte 0. + */ + left =3D (buf[0] & 0x02)? 1: 0; + middle =3D (buf[0] & 0x04)? 1: 0; + right =3D (buf[0] & 0x08)? 1: 0; + extra =3D (buf[0] & 0x10)? 1: 0; + + vsxxxaa_drop_bytes (mouse, 5); + + DBG (KERN_INFO "%s on %s: x=3D%d, y=3D%d, buttons=3D%s%s%s%s\n", + mouse->dev.name, mouse->dev.phys, x, y, + left? "L": "l", middle? "M": "m", + right? "R": "r", extra? "E": "e"); + + /* + * Report what we've found so far... + */ + input_regs (dev, regs); + input_report_key (dev, BTN_LEFT, left); + input_report_key (dev, BTN_MIDDLE, middle); + input_report_key (dev, BTN_RIGHT, right); + input_report_key (dev, BTN_EXTRA, extra); + input_report_abs (dev, ABS_X, x); + input_report_abs (dev, ABS_Y, y); + input_sync (dev); +} + +static void +vsxxxaa_handle_POR_packet (struct vsxxxaa *mouse, struct pt_regs *regs) +{ + struct input_dev *dev =3D &mouse->dev; + unsigned char *buf =3D mouse->buf; + int left, middle, right; + unsigned char error; + + /* + * Check for Power-On-Reset packets. These are sent out + * after plugging the mouse in, or when explicitely + * requested by sending 'T'. + * + * [0]: 1 0 1 0 R3 R2 R1 R0 + * [1]: 0 M2 M1 M0 D3 D2 D1 D0 + * [2]: 0 E6 E5 E4 E3 E2 E1 E0 + * [3]: 0 0 0 0 0 Left Middle Right + * + * M: manufacturer location code + * R: revision code + * E: Error code. I'm not sure about these, but gpm's sources, + * which support this mouse, too, tell about them: + * E =3D [0x00 .. 0x1f]: no error, byte #3 is button state + * E =3D 0x3d: button error, byte #3 tells which one. + * E =3D : other error + * D: <0010> =3D=3D mouse, <0100> =3D=3D tablet + * + */ + + mouse->version =3D buf[0] & 0x0f; + mouse->country =3D (buf[1] >> 4) & 0x07; + mouse->type =3D buf[1] & 0x07; + error =3D buf[2] & 0x7f; + + /* + * Get button state. It's the low three bits + * (for three buttons) of byte 0. Maybe even the bit <3> + * has some meaning if a tablet is attached. + */ + left =3D (buf[0] & 0x04)? 1: 0; + middle =3D (buf[0] & 0x02)? 1: 0; + right =3D (buf[0] & 0x01)? 1: 0; + + vsxxxaa_drop_bytes (mouse, 4); + vsxxxaa_report_mouse (mouse); + + if (error <=3D 0x1f) { + /* No error. Report buttons */ + input_regs (dev, regs); + input_report_key (dev, BTN_LEFT, left); + input_report_key (dev, BTN_MIDDLE, middle); + input_report_key (dev, BTN_RIGHT, right); + input_sync (dev); + } else { + printk (KERN_ERR "Your %s on %s reports an undefined error, " + "please check it...\n", mouse->dev.name, + mouse->dev.phys); + } + + /* + * If the mouse was hot-plugged, we need to + * force differential mode now... + */ + printk (KERN_NOTICE "%s on %s: Forceing standard packet format and " + "streaming mode\n", mouse->dev.name, mouse->dev.phys); + mouse->serio->write (mouse->serio, 'S'); + mouse->serio->write (mouse->serio, 'R'); +} + +static void +vsxxxaa_parse_buffer (struct vsxxxaa *mouse, struct pt_regs *regs) +{ + unsigned char *buf =3D mouse->buf; + int stray_bytes; + + /* + * Parse buffer to death... + */ + do { + /* + * Out of sync? Throw away what we don't understand. Each + * packet starts with a byte whose bit 7 is set. Unhandled + * packets (ie. which we don't know about or simply b0rk3d + * data...) will get shifted out of the buffer after some + * activity on the mouse. + */ + while (mouse->count > 0 && !IS_HDR_BYTE(buf[0])) { + printk (KERN_ERR "%s on %s: Dropping a byte to regain " + "sync with mouse data stream...\n", + mouse->dev.name, mouse->dev.phys); + vsxxxaa_drop_bytes (mouse, 1); + } + + /* + * Check for packets we know about. + */ + + if (vsxxxaa_smells_like_packet (mouse, VSXXXAA_PACKET_REL, 3)) { + /* Check for broken packet */ + stray_bytes =3D vsxxxaa_check_packet (mouse, 3); + if (stray_bytes > 0) { + printk (KERN_ERR "Dropping %d bytes now...\n", + stray_bytes); + vsxxxaa_drop_bytes (mouse, stray_bytes); + continue; + } + + vsxxxaa_handle_REL_packet (mouse, regs); + continue; /* More to parse? */ + } + + if (vsxxxaa_smells_like_packet (mouse, VSXXXAA_PACKET_ABS, 5)) { + /* Check for broken packet */ + stray_bytes =3D vsxxxaa_check_packet (mouse, 5); + if (stray_bytes > 0) { + printk (KERN_ERR "Dropping %d bytes now...\n", + stray_bytes); + vsxxxaa_drop_bytes (mouse, stray_bytes); + continue; + } + + vsxxxaa_handle_ABS_packet (mouse, regs); + continue; /* More to parse? */ + } + + if (vsxxxaa_smells_like_packet (mouse, VSXXXAA_PACKET_POR, 4)) { + /* Check for broken packet */ + stray_bytes =3D vsxxxaa_check_packet (mouse, 4); + if (stray_bytes > 0) { + printk (KERN_ERR "Dropping %d bytes now...\n", + stray_bytes); + vsxxxaa_drop_bytes (mouse, stray_bytes); + continue; + } + + vsxxxaa_handle_POR_packet (mouse, regs); + continue; /* More to parse? */ + } + + break; /* No REL, ABS or POR packet found */ + } while (1); +} + +static irqreturn_t +vsxxxaa_interrupt (struct serio *serio, unsigned char data, unsigned int f= lags, + struct pt_regs *regs) +{ + struct vsxxxaa *mouse =3D serio->private; + + vsxxxaa_queue_byte (mouse, data); + vsxxxaa_parse_buffer (mouse, regs); + + return IRQ_HANDLED; +} + +static void +vsxxxaa_disconnect (struct serio *serio) +{ + struct vsxxxaa *mouse =3D serio->private; + + input_unregister_device (&mouse->dev); + serio_close (serio); + kfree (mouse); +} + +static void +vsxxxaa_connect (struct serio *serio, struct serio_dev *dev) +{ + struct vsxxxaa *mouse; + + if ((serio->type & SERIO_TYPE) !=3D SERIO_RS232) + return; + + if ((serio->type & SERIO_PROTO) !=3D SERIO_VSXXXAA) + return; + + if (!(mouse =3D kmalloc (sizeof (struct vsxxxaa), GFP_KERNEL))) + return; + + memset (mouse, 0, sizeof (struct vsxxxaa)); + + init_input_dev (&mouse->dev); + set_bit (EV_KEY, mouse->dev.evbit); /* We have buttons */ + set_bit (EV_REL, mouse->dev.evbit); /* We can move */ + set_bit (BTN_LEFT, mouse->dev.keybit); /* We have 3 buttons */ + set_bit (BTN_MIDDLE, mouse->dev.keybit); + set_bit (BTN_RIGHT, mouse->dev.keybit); + set_bit (BTN_EXTRA, mouse->dev.keybit); /* ...and Tablet */ + set_bit (REL_X, mouse->dev.relbit); /* We can move in */ + set_bit (REL_Y, mouse->dev.relbit); /* two dimensions */ + set_bit (ABS_X, mouse->dev.absbit); /* DEC tablet support */ + set_bit (ABS_Y, mouse->dev.absbit); + + mouse->dev.absmin[ABS_X] =3D 0; + mouse->dev.absmax[ABS_X] =3D 1023; + mouse->dev.absmin[ABS_Y] =3D 0; + mouse->dev.absmax[ABS_Y] =3D 1023; + + mouse->dev.private =3D mouse; + serio->private =3D mouse; + + sprintf (mouse->phys, "%s/input0", serio->phys); + mouse->dev.phys =3D mouse->phys; + mouse->dev.name =3D "DEC VSXXX-AA/GA mouse or DEC tablet"; + mouse->dev.id.bustype =3D BUS_RS232; + mouse->serio =3D serio; + + if (serio_open (serio, dev)) { + kfree (mouse); + return; + } + + /* + * Request selftest and differential stream mode. + */ + mouse->serio->write (mouse->serio, 'T'); /* Test */ + mouse->serio->write (mouse->serio, 'R'); /* Differential stream */ + + input_register_device (&mouse->dev); + + printk (KERN_INFO "input: %s on %s\n", mouse->dev.name, serio->phys); +} + +static struct serio_dev vsxxxaa_dev =3D { + .interrupt =3D vsxxxaa_interrupt, + .connect =3D vsxxxaa_connect, + .disconnect =3D vsxxxaa_disconnect +}; + +int __init +vsxxxaa_init (void) +{ + serio_register_device (&vsxxxaa_dev); + return 0; +} + +void __exit +vsxxxaa_exit (void) +{ + serio_unregister_device (&vsxxxaa_dev); +} + +module_init (vsxxxaa_init); +module_exit (vsxxxaa_exit); + --sgneBHv3152wZ8jf-- --brEuL7wsLY8+TuWz 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) iD8DBQFAPPN9Hb1edYOZ4bsRArjTAJ4/m2COtzrlR8++Q38AwxQ49h0s9gCggHP3 FuMvnGzjeUDfJUG849xp5VA= =unrZ -----END PGP SIGNATURE----- --brEuL7wsLY8+TuWz-- From flo@paradigm.rfc822.org Wed Feb 25 21:20:12 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 21:20:13 +0000 (GMT) Received: from noose.gt.owl.de ([IPv6:::ffff:62.52.19.4]:6661 "EHLO noose.gt.owl.de") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 21:20:12 +0000 Received: by noose.gt.owl.de (Postfix, from userid 10) id 3708C26029; Wed, 25 Feb 2004 22:20:05 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 38E1325C039; Wed, 25 Feb 2004 22:19:18 +0100 (CET) Date: Wed, 25 Feb 2004 22:19:18 +0100 From: Florian Lohoff To: Ralf Baechle Cc: Joost , linux-mips@linux-mips.org Subject: Re: fore atm card in indy? Message-ID: <20040225211917.GC15992@paradigm.rfc822.org> References: <20040220142138.GD23404@linux-mips.org> <20040223204649.GF1046@mind.be> <20040225143053.GC19555@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline In-Reply-To: <20040225143053.GC19555@linux-mips.org> Organization: rfc822 - pure communication User-Agent: Mutt/1.5.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2004 at 03:30:53PM +0100, Ralf Baechle wrote: > On Tue, Feb 24, 2004 at 05:03:19PM +0100, Joost wrote: >=20 > One of the running gags on ATM is it actually stands for A Terrible Mess = ;-) >=20 Another Technology Mistake Flo --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 Heisenberg may have been here. --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAPRFVUaz2rXW+gJcRAm4RAKCD5GXmTICvSCvDEkLDdpTFTs7I/gCfSbvd PdIco1tD0pn9HnggZzcTbio= =/5IR -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- From alan@lxorguk.ukuu.org.uk Wed Feb 25 21:51:12 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 21:51:13 +0000 (GMT) Received: from cpc1-cwma1-5-0-cust4.swan.cable.ntl.com ([IPv6:::ffff:80.5.120.4]:54439 "EHLO dhcp23.swansea.linux.org.uk") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 21:51:12 +0000 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10) with ESMTP id i1PLle0r026293; Wed, 25 Feb 2004 21:47:40 GMT Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10/Submit) id i1PLlcDC026291; Wed, 25 Feb 2004 21:47:38 GMT X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: IDE driver problem From: Alan Cox To: Ralf Baechle Cc: Geert Uytterhoeven , "Liu Hongming (Alan)" , Linux/MIPS Development In-Reply-To: <20040225181645.GA10742@linux-mips.org> References: <15F9E1AE3207D6119CEA00D0B7DD5F680219C882@TMTMS> <20040225171315.GB17217@linux-mips.org> <20040225181645.GA10742@linux-mips.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1077745654.26288.0.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 25 Feb 2004 21:47:35 +0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips On Mer, 2004-02-25 at 18:16, Ralf Baechle wrote: > Oh, those. I fear every possible way to hookup the IDE bus in a more or > particularly less intelligent way to a system has already been found out > there ... You would be suprised. You can do PIO IDE on just about anything. I think the most grotesque I've seen is bitbanged IDE PIO on GPIO ports From ralf@linux-mips.org Wed Feb 25 21:53:14 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2004 21:53:14 +0000 (GMT) Received: from p508B5CC5.dip.t-dialin.net ([IPv6:::ffff:80.139.92.197]:21858 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 25 Feb 2004 21:53:14 +0000 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i1PLrBex024782; Wed, 25 Feb 2004 22:53:11 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i1PLrABH024781; Wed, 25 Feb 2004 22:53:10 +0100 Date: Wed, 25 Feb 2004 22:53:10 +0100 From: Ralf Baechle To: Alan Cox Cc: Geert Uytterhoeven , "Liu Hongming (Alan)" , Linux/MIPS Development Subject: Re: IDE driver problem Message-ID: <20040225215310.GB24298@linux-mips.org> References: <15F9E1AE3207D6119CEA00D0B7DD5F680219C882@TMTMS> <20040225171315.GB17217@linux-mips.org> <20040225181645.GA10742@linux-mips.org> <1077745654.26288.0.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1077745654.26288.0.camel@dhcp23.swansea.linux.org.uk> 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: 4447 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 25, 2004 at 09:47:35PM +0000, Alan Cox wrote: > On Mer, 2004-02-25 at 18:16, Ralf Baechle wrote: > > Oh, those. I fear every possible way to hookup the IDE bus in a more or > > particularly less intelligent way to a system has already been found out > > there ... > > You would be suprised. You can do PIO IDE on just about anything. I > think the most grotesque I've seen is bitbanged IDE PIO on GPIO ports And I thought the ISA bus accessible only through an address / data register pair was gross ;-) Ralf From anemo@mba.ocn.ne.jp Thu Feb 26 02:06:03 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2004 02:06:04 +0000 (GMT) Received: from [IPv6:::ffff:202.230.225.5] ([IPv6:::ffff:202.230.225.5]:7968 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Thu, 26 Feb 2004 02:06:03 +0000 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 26 Feb 2004 02:06:05 UT Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i1Q25k1x068762; Thu, 26 Feb 2004 11:05:47 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 26 Feb 2004 11:08:08 +0900 (JST) Message-Id: <20040226.110808.74756119.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: geert@linux-m68k.org, alanliu@trident.com.cn, alan@lxorguk.ukuu.org.uk, linux-mips@linux-mips.org Subject: Re: IDE driver problem From: Atsushi Nemoto In-Reply-To: <20040225181645.GA10742@linux-mips.org> References: <20040225171315.GB17217@linux-mips.org> <20040225181645.GA10742@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 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: 4448 X-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, 25 Feb 2004 19:16:45 +0100, Ralf Baechle said: >>> I'm not sure what you call endian issue here. The PC style >>> partition table code we've used for years on big endian systems >>> without problems. >> >> I guess his hardware has a byteswapped IDE bus, like on Atari, >> Q40/Q60 and Tivo. ralf> Oh, those. I fear every possible way to hookup the IDE bus in a ralf> more or particularly less intelligent way to a system has ralf> already been found out there ... Since 2.4.21, I need following changes in asm-mips/ide.h to work generic PCI IDE on my big-endian platform (which uses CONFIG_SWAP_IO_SPACE) again. This is a same hack used until 2.4.20. CONFIG_IDE_USE_RAW_IO is a flag in my local configuration. The 2.4.21 IDE subsystem introduced hwif->OUTW, hwif->OUTSW, etc. but I could not found a way to override them for generic PCI IDE controllers. So I still need the hack. #if defined(CONFIG_IDE_USE_RAW_IO) && defined(__MIPSEB__) /* get rid of defs from io.h - ide has its private and conflicting versions */ #ifdef insw #undef insw #endif #ifdef outsw #undef outsw #endif #ifdef insl #undef insl #endif #ifdef outsl #undef outsl #endif #define insw(port, addr, count) raw_insw(port, addr, count) #define insl(port, addr, count) raw_insl(port, addr, count) #define outsw(port, addr, count) raw_outsw(port, addr, count) #define outsl(port, addr, count) raw_outsl(port, addr, count) static inline void raw_insw(unsigned long port, void *addr, unsigned int count) { while (count--) { *(u16 *)addr = *(volatile u16 *)(mips_io_port_base + port); addr += 2; } } static inline void raw_outsw(unsigned long port, void *addr, unsigned int count) { while (count--) { *(volatile u16 *)(mips_io_port_base + (port)) = *(u16 *)addr; addr += 2; } } static inline void raw_insl(unsigned long port, void *addr, unsigned int count) { while (count--) { *(u32 *)addr = *(volatile u32 *)(mips_io_port_base + port); addr += 4; } } static inline void raw_outsl(unsigned long port, void *addr, unsigned int count) { while (count--) { *(volatile u32 *)(mips_io_port_base + (port)) = *(u32 *)addr; addr += 4; } } #endif From alanliu@trident.com.cn Thu Feb 26 02:46:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2004 02:46:17 +0000 (GMT) Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:21513 "EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP id ; Thu, 26 Feb 2004 02:46:16 +0000 Received: by TMTMS with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Feb 2004 10:42:48 +0800 Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F680219C8F0@TMTMS> From: "Liu Hongming (Alan)" To: Ralf Baechle , "Liu Hongming (Alan)" Cc: Alan Cox , linux-mips@linux-mips.org Subject: RE: IDE driver problem Date: Thu, 26 Feb 2004 10:42:42 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC12.35155FF0" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alanliu@trident.com.cn Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3FC12.35155FF0 Content-Type: text/plain; charset="ISO-8859-1" Hi, Very glad to see you here. Alan Cox,many friends of mine ADMIRE you very much! Ralf Baechle,I learn a lot from your codes when porting my mips! The ENDIAN issue in my board is: My mips is little endian(not pure,dont care it here),and my memory is little endian(it should be same as cpu,however,it is not always in my SOC,that's why ENDIAN issue comes out).When reading/writing words from/to memory,it is always OK,little endian. However,the wierd situation is that when writing string such as "ABCDEFGH" into memory,such as address 0,in memory it will be stored as: addr 0:1:2:3:4:5:6:7 DC B A HG F E that means,when using byte access to memory,it will byteswap.You want to access address 0,however,it will access address 3,vice versa. You want to access address 1,it will access address 2,vice versa. This is byte access situation. When using half word accessing,it will swap too: if I want to write 0x1234 into memory at address 0,it will write into memory address 2; if I want to write 0x1234 into memory at address 2,it will write into memory address 0; So,in my board, we could not use type-casting to access data in memory. I dont know if I have clarified the situation. -----Original Message----- From: Ralf Baechle [mailto:ralf@linux-mips.org] Sent: Thursday, February 26, 2004 1:13 AM To: Liu Hongming (Alan) Cc: Alan Cox; linux-mips@linux-mips.org Subject: Re: IDE driver problem On Wed, Feb 25, 2004 at 08:11:54PM +0800, Liu Hongming (Alan) wrote: > I have found out where the problem is. Since my hardware has > endian issue, fs/partition/msdos.c could not handle partition table > correctly. I have changed a little(still having much to change),and it > really works now. I'm not sure what you call endian issue here. The PC style partition table code we've used for years on big endian systems without problems. Ralf ------_=_NextPart_001_01C3FC12.35155FF0 Content-Type: text/html; charset="ISO-8859-1" RE: IDE driver problem

Hi,

Very glad to see you here.

Alan Cox,many friends of mine ADMIRE you very much!
Ralf Baechle,I learn a lot from your codes when porting my mips!

The ENDIAN issue in my board is:
My mips is little endian(not pure,dont care it here),and my memory
is little endian(it should be same as cpu,however,it is not always in my
SOC,that's why ENDIAN issue comes out).When reading/writing words
from/to memory,it is always OK,little endian. However,the wierd situation is that
when writing string such as "ABCDEFGH" into memory,such as address
0,in memory it will be stored as:
addr 0:1:2:3:4:5:6:7
        DC B A HG F E
that means,when using byte access to memory,it will byteswap.You want
to access address 0,however,it will access address 3,vice versa.
You want to access address 1,it will access address 2,vice versa.
This is byte access situation.
When using half word accessing,it will swap too:
if I want to write 0x1234 into memory at address 0,it will write into memory address 2;
if I want to write 0x1234 into memory at address 2,it will write into memory address 0;

So,in my board, we could not use type-casting to access data in memory.
I dont know if I have clarified the situation.


-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, February 26, 2004 1:13 AM
To: Liu Hongming (Alan)
Cc: Alan Cox; linux-mips@linux-mips.org
Subject: Re: IDE driver problem


On Wed, Feb 25, 2004 at 08:11:54PM +0800, Liu Hongming (Alan) wrote:

> I have found out where the problem is. Since my hardware has
> endian issue, fs/partition/msdos.c could not handle partition table
> correctly. I have changed a little(still having much to change),and it
> really works now.

I'm not sure what you call endian issue here.  The PC style partition
table code we've used for years on big endian systems without problems.

  Ralf

------_=_NextPart_001_01C3FC12.35155FF0-- From karthik_96cse@yahoo.com Thu Feb 26 10:49:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2004 10:49:35 +0000 (GMT) Received: from web10102.mail.yahoo.com ([IPv6:::ffff:216.136.130.52]:45873 "HELO web10102.mail.yahoo.com") by linux-mips.org with SMTP id ; Thu, 26 Feb 2004 10:49:34 +0000 Message-ID: <20040226104929.3711.qmail@web10102.mail.yahoo.com> Received: from [128.107.253.43] by web10102.mail.yahoo.com via HTTP; Thu, 26 Feb 2004 10:49:29 GMT Date: Thu, 26 Feb 2004 10:49:29 +0000 (GMT) From: =?iso-8859-1?q?karthikeyan=20natarajan?= Subject: Doubt in updating the cache.. To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karthik_96cse@yahoo.com Precedence: bulk X-list: linux-mips Hi All, When the Instruction/data is read from memory, it's copy will be put into the cache. Question: How does the R4k processor determines whether the value read from memory is Instruction or Data so that the value will be put into the appropriate primary cache? Thanks much, -karthi ===== The expert at anything was once a beginner ______________________________ / \ O / Karthikeyan.N \ O | Chennai, India. | `\|||/' \ Mobile: +919884104346 / (o o) \ / _ ooO (_) Ooo____________________________________ _____|_____|_____|_____|_____|_____|_____|_____|_ __|_____|_____|_____|_____|_____|_____|_____|____ _____|_____|_____|_____|_____|_____|_____|_____|_ ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html From dom@mips.com Thu Feb 26 12:00:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2004 12:00:42 +0000 (GMT) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:39694 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Thu, 26 Feb 2004 12:00:41 +0000 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 1AwK5n-0002ah-00; Thu, 26 Feb 2004 11:54:15 +0000 Received: from arsenal.mips.com ([192.168.192.197]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1AwKBa-0004TO-00; Thu, 26 Feb 2004 12:00:14 +0000 Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian)) id 1AwKBa-0001Uf-00; Thu, 26 Feb 2004 12:00:14 +0000 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16445.57293.864473.100987@arsenal.mips.com> Date: Thu, 26 Feb 2004 12:00:13 +0000 To: =?iso-8859-1?q?karthikeyan=20natarajan?= Cc: linux-mips@linux-mips.org Subject: Re: Doubt in updating the cache.. In-Reply-To: <20040226104929.3711.qmail@web10102.mail.yahoo.com> References: <20040226104929.3711.qmail@web10102.mail.yahoo.com> 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.85, 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: 4451 X-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 Karthi, > When the Instruction/data is read from memory, > it's copy will be put into the cache. > > Question: > > How does the R4k processor determines whether the > value read from memory is Instruction or Data so that > the value will be put into the appropriate primary > cache? The caches are not prescient... Data is only ever put into the cache when the CPU *uses* it (and it isn't there already). If the CPU was do ingan instruction fetch, the copy of the memory data goes in the I-cache; if the CPU was trying to do a load it goes in the D-cache. -- Dominic