From owner-linux-mips@oss.sgi.com Mon Oct 1 02:39:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f919dkG12818 for linux-mips-outgoing; Mon, 1 Oct 2001 02:39:46 -0700 Received: from coplin19.mips.com (host-3.mips.com [206.31.31.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f919dXD12811 for ; Mon, 1 Oct 2001 02:39:33 -0700 Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id f919cGr16879; Mon, 1 Oct 2001 11:38:16 +0200 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Mon, 1 Oct 2001 11:38:16 +0200 (CEST) From: Kjeld Borch Egevang To: "H . J . Lu" cc: GNU C Library , linux-mips mailing list Subject: Re: PATCH: Update sysdeps/mips/fpu/libm-test-ulps In-Reply-To: <20010914111751.A17316@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I discovered a problem in glibc-2.2.4-11.2.src.rpm concerning QNaN and SNaN (quiet not-a-number and signalling not-a-number). It seems that NaN's are always interpreted the Intel-way. In glibc-2.2.4/soft-fp/quad.h it says: #define _FP_QNANBIT_Q \ ((_FP_W_TYPE)1 << (_FP_FRACBITS_Q-2) % _FP_W_TYPE_SIZE) But this is not correct on MIPS processors, where SNaNs has the bit set and QNaNs has the bit cleared. Changing the definition above to 0 doesn't seem to solve the problem (I probably haven't found the root of the problem). The following piece of code gives the wrong result on a MIPS processor: -------------------- cut here -------------- #include typedef union { long long ll; double d; } t_number; int main() { t_number x, z; x.ll = 0x7ff7ffffffffffff; /* QNaN */ z.d = sqrt(x.d); printf("%e %016llx\n", z.d, z.ll); } -------------------- cut here -------------- The result is a signalling NaN: nan 7ff8000000000000 (I expected 0x7ff7ffffffffffff) /Kjeld On Fri, 14 Sep 2001, H . J . Lu wrote: > Here is a patch for sysdeps/mips/fpu/libm-test-ulps. BTW, I got many > math failures on Linux/mipsel. Has anyone else seen them? > > > H.J. > ---- > 2001-09-14 H.J. Lu > > * sysdeps/mips/fpu/libm-test-ulps: Updated. > > --- sysdeps/mips/fpu/libm-test-ulps.mips Fri Apr 27 21:25:17 2001 > +++ sysdeps/mips/fpu/libm-test-ulps Fri Sep 14 11:01:52 2001 > @@ -7,7 +7,7 @@ ifloat: 2 > Test "asin (0.5) == pi/6": > float: 2 > ifloat: 2 > -Test "asin (0.7) == 0.7753974966107530637": > +Test "asin (0.7) == 0.77539749661075306374035335271498708": > double: 1 > float: 2 > idouble: 1 > @@ -175,12 +175,12 @@ idouble: 1 > Test "Imaginary part of: cexp (-2.0 - 3.0 i) == -0.13398091492954261346140525546115575 - 0.019098516261135196432576240858800925 i": > float: 1 > ifloat: 1 > -Test "Real part of: cexp (0.7 + 1.2 i) == 0.7296989091503236012 + 1.8768962328348102821 i": > +Test "Real part of: cexp (0.7 + 1.2 i) == 0.72969890915032360123451688642930727 + 1.8768962328348102821139467908203072 i": > double: 1 > float: 1 > idouble: 1 > ifloat: 1 > -Test "Imaginary part of: cexp (0.7 + 1.2 i) == 0.7296989091503236012 + 1.8768962328348102821 i": > +Test "Imaginary part of: cexp (0.7 + 1.2 i) == 0.72969890915032360123451688642930727 + 1.8768962328348102821139467908203072 i": > float: 1 > ifloat: 1 > > @@ -249,7 +249,7 @@ float: 1 > ifloat: 1 > > # cos > -Test "cos (0.7) == 0.7648421872844884262": > +Test "cos (0.7) == 0.76484218728448842625585999019186495": > double: 1 > float: 1 > idouble: 1 > @@ -374,7 +374,7 @@ double: 2 > float: 1 > idouble: 2 > ifloat: 1 > -Test "exp10 (0.7) == 5.0118723362727228500": > +Test "exp10 (0.7) == 5.0118723362727228500155418688494574": > float: 1 > ifloat: 1 > Test "exp10 (3) == 1000": > @@ -451,6 +451,21 @@ ifloat: 2 > Test "j0 (8.0) == 0.17165080713755390609": > float: 1 > ifloat: 1 > +Test "j0 (4.0) == -3.9714980986384737228659076845169804197562E-1": > +double: 1 > +float: 1 > +idouble: 1 > +ifloat: 1 > +ildouble: 1 > +ldouble: 1 > +Test "j0 (-4.0) == -3.9714980986384737228659076845169804197562E-1": > +double: 1 > +float: 1 > +idouble: 1 > +ifloat: 1 > +ildouble: 1 > +ldouble: 1 > + > > # j1 > Test "j1 (10.0) == 0.043472746168861436670": > @@ -563,7 +578,7 @@ idouble: 1 > ifloat: 1 > > # sincos > -Test "sincos (0.7, &sin_res, &cos_res) puts 0.76484218728448842626 in cos_res": > +Test "sincos (0.7, &sin_res, &cos_res) puts 0.76484218728448842625585999019186495 in cos_res": > double: 1 > float: 1 > idouble: 1 > @@ -573,7 +588,7 @@ double: 1 > float: 0.5 > idouble: 1 > ifloat: 0.5 > -Test "sincos (M_PI_6l*2.0, &sin_res, &cos_res) puts 0.866025403784438646764 in sin_res": > +Test "sincos (M_PI_6l*2.0, &sin_res, &cos_res) puts 0.86602540378443864676372317075293616 in sin_res": > double: 1 > float: 1 > idouble: 1 > @@ -583,7 +598,7 @@ double: 0.2758 > float: 0.3667 > idouble: 0.2758 > ifloat: 0.3667 > -Test "sincos (pi/6, &sin_res, &cos_res) puts 0.866025403784438646764 in cos_res": > +Test "sincos (pi/6, &sin_res, &cos_res) puts 0.86602540378443864676372317075293616 in cos_res": > float: 1 > ifloat: 1 > > @@ -605,6 +620,13 @@ double: 1 > float: 1 > idouble: 1 > ifloat: 1 > +Test "tanh (-0.7) == -0.60436777711716349631": > +double: 1 > +float: 1 > +idouble: 1 > +ifloat: 1 > +ildouble: 1 > +ldouble: 1 > > # tgamma > Test "tgamma (-0.5) == -2 sqrt (pi)": > -- _ _ ____ ___ Mailto:kjelde@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 | \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 Denmark http://www.mips.com/ From owner-linux-mips@oss.sgi.com Mon Oct 1 03:07:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91A7np13340 for linux-mips-outgoing; Mon, 1 Oct 2001 03:07:49 -0700 Received: from sunsite.ms.mff.cuni.cz (sunsite.ms.mff.cuni.cz [195.113.19.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91A7iD13336 for ; Mon, 1 Oct 2001 03:07:44 -0700 Received: (from jj@localhost) by sunsite.ms.mff.cuni.cz (8.9.3/8.9.3) id MAA20642; Mon, 1 Oct 2001 12:10:53 +0200 Date: Mon, 1 Oct 2001 12:10:53 +0200 From: Jakub Jelinek To: Kjeld Borch Egevang Cc: "H . J . Lu" , GNU C Library , linux-mips mailing list Subject: Re: PATCH: Update sysdeps/mips/fpu/libm-test-ulps Message-ID: <20011001121053.F3251@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <20010914111751.A17316@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Kjeld Borch Egevang on Mon, Oct 01, 2001 at 11:38:16AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Oct 01, 2001 at 11:38:16AM +0200, Kjeld Borch Egevang wrote: > I discovered a problem in glibc-2.2.4-11.2.src.rpm concerning QNaN and > SNaN (quiet not-a-number and signalling not-a-number). It seems that > NaN's are always interpreted the Intel-way. > > In glibc-2.2.4/soft-fp/quad.h it says: > > #define _FP_QNANBIT_Q \ > ((_FP_W_TYPE)1 << (_FP_FRACBITS_Q-2) % _FP_W_TYPE_SIZE) > > But this is not correct on MIPS processors, where SNaNs has the bit set > and QNaNs has the bit cleared. Changing the definition above to 0 doesn't > seem to solve the problem (I probably haven't found the root of the > problem). If you're changing _FP_QNANBIT_Q definition and testing it on double NaNs, then certainly nothing should change. The way soft-fp interprets Quiet NaNs is not just Intel-way, e.g. SPARC, Alpha work the same way. E.g. on SPARC, signalling NaN is exp=max, f=.0xxxxxxxxxx...xxx where at least one of the x bits is set, quiet NaN is exp=max, f=.1xxxxxxxxxx...xxxxxx. If MIPS has it backwards, then the solution definitely is not to set _FP_QNANBIT_* there to 0, but instead define some boolean macro in sfp-machine.h (_FP_QNAN_SET?, _FP_QNAN_SET == 1 iff Quiet Nan has _FP_QNANBIT set, 0 otherwise) and use it in the soft-fp/* macros, particularly in op-comon.h: - if (!(_FP_FRAC_HIGH_RAW_##fs(X) & _FP_QNANBIT_##fs)) \ + if (!(_FP_FRAC_HIGH_RAW_##fs(X) & _FP_QNANBIT_##fs) == !_FP_QNAN_SET) \ - _FP_FRAC_HIGH_RAW_##fs(X) |= _FP_QNANBIT_##fs; \ + if (_FP_QNAN_SET) \ + _FP_FRAC_HIGH_RAW_##fs(X) |= _FP_QNANBIT_##fs; \ + else + _FP_FRAC_HIGH_RAW_##fs(X) &= ~_FP_QNANBIT_##fs; \ - && !(_FP_FRAC_HIGH_RAW_##fs(X) & _FP_QNANBIT_##fs)) \ + && !(_FP_FRAC_HIGH_RAW_##fs(X) & _FP_QNANBIT_##fs) == !_FP_QNAN_SET) \ and sed 's/_FP_QNANBIT_D/(_FP_QNAN_SET ? _FP_QNANBIT_D : 0)/g' soft-fp/testit.c > The following piece of code gives the wrong result on a MIPS processor: > > -------------------- cut here -------------- > #include > > typedef union { > long long ll; > double d; > } t_number; > > int main() > { > t_number x, z; > > x.ll = 0x7ff7ffffffffffff; /* QNaN */ > z.d = sqrt(x.d); > printf("%e %016llx\n", z.d, z.ll); > } > -------------------- cut here -------------- > > > The result is a signalling NaN: > > nan 7ff8000000000000 > > (I expected 0x7ff7ffffffffffff) Jakub From owner-linux-mips@oss.sgi.com Mon Oct 1 12:59:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91Jxu828487 for linux-mips-outgoing; Mon, 1 Oct 2001 12:59:56 -0700 Received: from mail.mediatrix.com (mail.mediatrix.com [66.129.134.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91JxsD28482 for ; Mon, 1 Oct 2001 12:59:54 -0700 Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Oct 2001 15:59:52 -0400 Message-ID: From: Frederic Giasson To: "Linux-Mips mailing list (E-mail)" Subject: Beggining new MIPS linux port Date: Mon, 1 Oct 2001 15:59:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f91JxtD28483 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all, I will begin the port of Linux on a new MIPS processor pretty soon. I was wondering if anyone can tell me if there is any generic books on porting linux out there, I made quite intensive searches and I did not find anything relevant. Thanks in advance! Frédéric Giasson From owner-linux-mips@oss.sgi.com Mon Oct 1 16:52:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f91Nqd900993 for linux-mips-outgoing; Mon, 1 Oct 2001 16:52:39 -0700 Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f91NqQD00989 for ; Mon, 1 Oct 2001 16:52:27 -0700 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 4EF8D1F839 for ; Mon, 1 Oct 2001 19:52:17 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id E56F91F521 for ; Mon, 1 Oct 2001 19:52:16 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 19:52:16 -0400 Message-ID: From: "TWEDE,ROGER (HP-Boise,ex1)" To: "'linux-mips@oss.sgi.com'" Subject: Bug in pthread glibc 7.0 & 7.1 Date: Mon, 1 Oct 2001 19:52:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The following code reveals a bug in the MIPS Gnu C Libraries available via ftp on oss.sgi.com (ftp.linux.sgi.com). The bug is posix thread related and occurs when using the libc and libpthread versions available at: /pub/linux/mips/redhat/7.1/RPMS/mipsel/glibc* The bug also appears to exist in: /pub/linux/mips/mipsel-linux/RedHat-7.0/RPMS/mipsel/glibc* The bug does not exist in earlier versions of the pthread library, or on the non-MIPS (non-SGI) distributions. (ie. RedHat 7.0 for ix86 does not exhibit a failure with this code, but RedHat 7.0/7.1 on mips does) Upon failure the following code sequence will core dump (SEGV) instead of exiting normally. Thanks, Roger Twede Engineer/Scientist Hewlett Packard Company // CODE STARTS BELOW #include #include #include #include #include #include #include struct ThreadStartInfo { pthread_mutex_t InitCompleteMutex; pthread_cond_t InitCompleteCond; void * (*Func)(void *); void * Arg; int Priority; char * ThreadName; unsigned char InitCompleteCount; }; static void * StartFunction(void * Arg) { struct ThreadStartInfo * StartInfo = (struct ThreadStartInfo *) Arg; int result; void * retVal = 0; assert(Arg != NULL); result = pthread_mutex_lock(&(StartInfo->InitCompleteMutex)); assert(result == 0); printf("pid=%d thread mutex locked at x%x\n", getpid(), &(StartInfo->InitCompleteMutex)); StartInfo->InitCompleteCount = 1; result = pthread_cond_signal(&(StartInfo->InitCompleteCond)); assert(result == 0); printf("pid=%d thread cond signal sent, unlocking at 0x%x\n", getpid(), &(StartInfo->InitCompleteMutex)); result = pthread_mutex_unlock(&(StartInfo->InitCompleteMutex)); assert(result == 0); printf("pid=%d thread unlocked\n", getpid()); sched_yield(); printf("pid=%d yielded and back again\n", getpid()); return(retVal); } int main(void) { pthread_t ThreadObject; struct ThreadStartInfo StartInfo; pthread_mutexattr_t mutexAttr; pthread_attr_t threadAttr; pthread_condattr_t condAttr; int result = 0; StartInfo.ThreadName = "mythread"; result = pthread_mutexattr_init(&mutexAttr); assert(result == 0); printf("pid=%d Init mutex\n", getpid()); result = pthread_mutex_init(&(StartInfo.InitCompleteMutex), &mutexAttr); assert(result == 0); result = pthread_condattr_init(&condAttr); assert(result == 0); result = pthread_cond_init(&(StartInfo.InitCompleteCond), &condAttr); assert(result == 0); StartInfo.InitCompleteCount = 0; pthread_mutex_lock(&(StartInfo.InitCompleteMutex)); printf("pid=%d About to create thread: %s\n", getpid(), StartInfo.ThreadName); result = pthread_attr_init(&threadAttr); assert(result == 0); result = pthread_create(&ThreadObject, &threadAttr, &StartFunction, (void *)&StartInfo); assert(result == 0); while ((result == 0) && (StartInfo.InitCompleteCount == 0)) { do { printf("pid=%d about to cond_wait for %s init 1.\n", getpid(), StartInfo.ThreadName); result = pthread_cond_wait(&(StartInfo.InitCompleteCond), &(StartInfo.InitCompleteMutex)); printf("pid=%d back from cond_wait for %s init 1. result=%d\n", getpid(), StartInfo.ThreadName, result); } while (result == EINTR); } result = pthread_mutex_unlock(&(StartInfo.InitCompleteMutex)); assert(result == 0); getchar(); return 0; } // CODE ABOVE From owner-linux-mips@oss.sgi.com Mon Oct 1 17:10:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f920A8D01391 for linux-mips-outgoing; Mon, 1 Oct 2001 17:10:08 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f920A4D01380 for ; Mon, 1 Oct 2001 17:10:04 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9A30F125C8; Mon, 1 Oct 2001 17:10:03 -0700 (PDT) Date: Mon, 1 Oct 2001 17:10:03 -0700 From: "H . J . Lu" To: "TWEDE,ROGER (HP-Boise,ex1)" Cc: "'linux-mips@oss.sgi.com'" Subject: Re: Bug in pthread glibc 7.0 & 7.1 Message-ID: <20011001171003.A18883@lucon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from roger_twede@hp.com on Mon, Oct 01, 2001 at 07:52:15PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Oct 01, 2001 at 07:52:15PM -0400, TWEDE,ROGER (HP-Boise,ex1) wrote: > > > The following code reveals a bug in the MIPS Gnu C Libraries available via > ftp on oss.sgi.com (ftp.linux.sgi.com). > > The bug is posix thread related and occurs when using the libc and > libpthread versions available at: > /pub/linux/mips/redhat/7.1/RPMS/mipsel/glibc* > > The bug also appears to exist in: > /pub/linux/mips/mipsel-linux/RedHat-7.0/RPMS/mipsel/glibc* > > The bug does not exist in earlier versions of the pthread library, or on the > non-MIPS (non-SGI) distributions. (ie. RedHat 7.0 for ix86 does not exhibit > a failure with this code, but RedHat 7.0/7.1 on mips does) > > Upon failure the following code sequence will core dump (SEGV) instead of > exiting normally. > > On RedHat 7.1/mips: # gcc pthread.c -o mips -lpthread -Wall pthread.c: In function `StartFunction': pthread.c:64: warning: unsigned int format, pointer arg (arg 3) pthread.c:69: warning: unsigned int format, pointer arg (arg 3) # ./mips pid=21905 Init mutex pid=21905 About to create thread: mythread pid=21905 about to cond_wait for mythread init 1. pid=21907 thread mutex locked at x7fff79c8 pid=21907 thread cond signal sent, unlocking at 0x7fff79c8 pid=21907 thread unlocked pid=21905 back from cond_wait for mythread init 1. result=0 pid=21907 yielded and back again # rpm -q glibc glibc-2.2.4-11.2 H.J. From owner-linux-mips@oss.sgi.com Tue Oct 2 05:09:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92C9XK13500 for linux-mips-outgoing; Tue, 2 Oct 2001 05:09:33 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92C9SD13496 for ; Tue, 2 Oct 2001 05:09:28 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id MAA23706; Tue, 2 Oct 2001 12:09:25 GMT From: Robin Humble Message-Id: <200110021209.MAA23706@groucho.maths.monash.edu.au> Subject: Re: Bug in pthread glibc 7.0 & 7.1 To: linux-mips@oss.sgi.com Date: Tue, 2 Oct 2001 22:09:25 +1000 (EST) Cc: roger_twede@hp.com In-Reply-To: <20011001171003.A18883@lucon.org> from "H . J . Lu" at Oct 01, 2001 05:10:03 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk H.J. wrote: >On Mon, Oct 01, 2001 at 07:52:15PM -0400, TWEDE,ROGER (HP-Boise,ex1) wrote: >> The following code reveals a bug in the MIPS Gnu C Libraries available via >> ftp on oss.sgi.com (ftp.linux.sgi.com). >> ... >On RedHat 7.1/mips: > ># gcc pthread.c -o mips -lpthread -Wall >pthread.c: In function `StartFunction': >pthread.c:64: warning: unsigned int format, pointer arg (arg 3) >pthread.c:69: warning: unsigned int format, pointer arg (arg 3) ># ./mips >pid=21905 Init mutex >pid=21905 About to create thread: mythread >pid=21905 about to cond_wait for mythread init 1. >pid=21907 thread mutex locked at x7fff79c8 >pid=21907 thread cond signal sent, unlocking at 0x7fff79c8 >pid=21907 thread unlocked >pid=21905 back from cond_wait for mythread init 1. result=0 >pid=21907 yielded and back again ># rpm -q glibc >glibc-2.2.4-11.2 On my R4600SC Indy running 7.1 (mips) I get: % gcc blah.c -o blah -lpthread -Wall blah.c: In function `StartFunction': blah.c:37: warning: unsigned int format, pointer arg (arg 3) blah.c:42: warning: unsigned int format, pointer arg (arg 3) % ./blah [blah:5286] Illegal instruction 0100017c at 2ad1a910 ra=2ab78ed0 Illegal instruction (core dumped) % uname -a Linux elan 2.4.3 #1 Sun Apr 22 23:46:19 PDT 2001 mips unknown % rpm -q glibc gcc glibc-2.2.4-11.2 gcc-2.96-97.2 % This happens whether it's a native build of glibc or the one from oss.sgi.com. The kernel is from the simple dir on oss. With a 3rd Sept CVS 2.4.8 kernel under no load the pthreads program runs ok, but under load (a big rm -rf over NFS for instance), it fails like above, or fails like: % ./blah pid=681 Init mutex pid=681 About to create thread: mythread pid=681 about to cond_wait for mythread init 1. Segmentation fault (core dumped) % Also I found I could only build X natively on the Indy by disabling the pthreads parts; and maybe it's a similar 'Illegal Instruction' error in the 'conftest' program that seems to be stopping mozilla from building?? (at least under kernel 2.4.3 which otherwise seems more stable than 2.4.8) cheers, robin From owner-linux-mips@oss.sgi.com Tue Oct 2 06:24:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92DOEh15254 for linux-mips-outgoing; Tue, 2 Oct 2001 06:24:14 -0700 Received: from dark-past (h117n1fls20o53.telia.com [213.64.214.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92DOBD15251 for ; Tue, 2 Oct 2001 06:24:11 -0700 Received: from yog-sothoth.dark-past.mine.nu (yog-sothoth [192.168.1.7]) by dark-past (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02711 for ; Tue, 2 Oct 2001 15:24:41 -0700 Message-Id: <5.1.0.14.0.20011002165702.00a512a0@192.168.1.5> X-Sender: peter@192.168.1.5 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Oct 2001 17:00:50 +0200 To: linux-mips@oss.sgi.com From: Peter Andersson Subject: Installation/booting of Mips Linux from local harddrive... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am running an sgi Indy with Irix 6.2 installed (hopefully not for long) and have been looking at linux for sgi for a while now. I even installed hardhat linux on it about a year and a half ago but had no experience of linux/unix what so ever at that time, so i gave it up due to the booting causing me some trouble. Anyway to get to the point, i thought that i read somewhere a while ago that you had managed to get linux to boot locally at the machines now and just thought that i would ask you if its true. If so where do i locate the kernel, you have quite a few on your ftp... Sorry about these stupid questions and keep up the good work!!! Regards Peter From owner-linux-mips@oss.sgi.com Tue Oct 2 09:14:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92GENo19311 for linux-mips-outgoing; Tue, 2 Oct 2001 09:14:23 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92GELD19308 for ; Tue, 2 Oct 2001 09:14:21 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4BBF1125C8; Tue, 2 Oct 2001 09:14:20 -0700 (PDT) Date: Tue, 2 Oct 2001 09:14:19 -0700 From: "H . J . Lu" To: Robin Humble Cc: linux-mips@oss.sgi.com, roger_twede@hp.com Subject: Re: Bug in pthread glibc 7.0 & 7.1 Message-ID: <20011002091419.B32338@lucon.org> References: <20011001171003.A18883@lucon.org> <200110021209.MAA23706@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110021209.MAA23706@groucho.maths.monash.edu.au>; from rjh@groucho.maths.monash.edu.au on Tue, Oct 02, 2001 at 10:09:25PM +1000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Oct 02, 2001 at 10:09:25PM +1000, Robin Humble wrote: > Also I found I could only build X natively on the Indy by disabling the > pthreads parts; and maybe it's a similar 'Illegal Instruction' error in > the 'conftest' program that seems to be stopping mozilla from building?? > (at least under kernel 2.4.3 which otherwise seems more stable than 2.4.8) > My impression is 2.4.3 is more stable than 2.4.5. I haven't tried 2.4.8 yet. H.J. From owner-linux-mips@oss.sgi.com Wed Oct 3 07:31:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93EVj015538 for linux-mips-outgoing; Wed, 3 Oct 2001 07:31:45 -0700 Received: from its.it-academy.bg ([194.12.242.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93EVeD15530 for ; Wed, 3 Oct 2001 07:31:42 -0700 Received: from prometric3.it-academy.bg ([192.168.32.8]) by its.it-academy.bg with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Oct 2001 17:28:57 +0300 Message-Id: <5.1.0.14.2.20011003172659.00a6c4a8@mail.it-academy.bg> X-Sender: mkafadarov@mail.it-academy.bg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Oct 2001 17:28:15 +0300 To: linux-mips@oss.sgi.com From: Marian Kafadarov Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Oct 2001 14:28:57.0686 (UTC) FILETIME=[BCB28760:01C14C17] Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, We have DEC station 5000 / 240 From were we can download Linux distribution and documentation for it and what we can do on it. Best regards: Marian Kafadarov Technical university of Plovdiv From owner-linux-mips@oss.sgi.com Wed Oct 3 07:48:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93EmNp15964 for linux-mips-outgoing; Wed, 3 Oct 2001 07:48:23 -0700 Received: from mercury.shreve.net (IDENT:root@mercury.shreve.net [208.206.76.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93EmLD15961 for ; Wed, 3 Oct 2001 07:48:21 -0700 Received: from mercury.shreve.net (IDENT:signal@mercury.shreve.net [208.206.76.23]) by mercury.shreve.net (8.11.6/8.11.6) with ESMTP id f93EmKB17956 for ; Wed, 3 Oct 2001 09:48:20 -0500 Date: Wed, 3 Oct 2001 09:48:20 -0500 (CDT) From: Brian To: Subject: How do I console into Origin 200? In-Reply-To: <5.1.0.14.2.20011003172659.00a6c4a8@mail.it-academy.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am trying to boot an Origin 200 (which I believe currently has IRIX on it, I will be installing linux-mips). It has 2 9 pin serial connectors on the back. I have hooked my Wyse terminal up to it with a serial cable with and without a null connector @ 9600bps. Is this correct? I get nothing on the screen. I have never consoled into an Origin, and am not sure if I am doing this right. Brian ----------------------------------------------- Brian Feeny, CCIE #8036 email:signal@shreve.net Network Engineer phone:318.222.2638x109 ShreveNet Inc. fax: 318.221.6612 From owner-linux-mips@oss.sgi.com Wed Oct 3 08:53:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93Fr5l17314 for linux-mips-outgoing; Wed, 3 Oct 2001 08:53:05 -0700 Received: from kuolema.infodrom.north.de (kuolema.infodrom.north.de [217.89.86.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93Fr0D17311 for ; Wed, 3 Oct 2001 08:53:01 -0700 Received: from finlandia.infodrom.north.de (finlandia.Infodrom.North.DE [217.89.86.34]) by kuolema.infodrom.north.de (Postfix) with ESMTP id 051894D73C; Wed, 3 Oct 2001 17:52:45 +0200 (CEST) Received: by finlandia.infodrom.north.de (Postfix, from userid 501) id C509310977; Wed, 3 Oct 2001 17:52:43 +0200 (CEST) Date: Wed, 3 Oct 2001 17:52:43 +0200 From: Martin Schulze To: Marian Kafadarov Cc: linux-mips@oss.sgi.com Subject: Re: your mail Message-ID: <20011003175243.A18353@finlandia.infodrom.north.de> Reply-To: Martin Schulze References: <5.1.0.14.2.20011003172659.00a6c4a8@mail.it-academy.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20011003172659.00a6c4a8@mail.it-academy.bg> User-Agent: Mutt/1.3.20i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Marian Kafadarov wrote: > Hello, > We have DEC station 5000 / 240 > From were we can download Linux distribution and documentation for it and > what we can do on it. You could wait until we have finished boot-floppies for this machine (1-3 weeks) or bootstrap from scratch by using a kernel and a Debian base system. Both is available, Karsten can also provide a correct 2.4.x kernel. I'd rather like to ask you to wait a couple of days/weeks until boot-floppies are available for this machine and you can use the regular Debian installation process which will be less painful than the other. If you do so, please come back to us in some days/weeks to find out if things are ready already. Regards, Joey -- All language designers are arrogant. Goes with the territory... -- Larry Wall From owner-linux-mips@oss.sgi.com Wed Oct 3 10:52:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93Hqtc20158 for linux-mips-outgoing; Wed, 3 Oct 2001 10:52:55 -0700 Received: from dea.linux-mips.net (a1as01-p32.stg.tli.de [195.252.185.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93HqoD20155 for ; Wed, 3 Oct 2001 10:52:51 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f93Hoxv28341; Wed, 3 Oct 2001 19:50:59 +0200 Date: Wed, 3 Oct 2001 19:50:59 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20011003195059.A28205@dea.linux-mips.net> References: <200109300029.f8U0TZv12410@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Oct 03, 2001 at 01:02:56PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Oct 03, 2001 at 01:02:56PM +0200, Maciej W. Rozycki wrote: > > Modified files: > > arch/mips/kernel: scall_o32.S sysmips.c > > > > Log message: > > Barf. > > The new mips_atomic_set() doesn't mask interrupts in the non-ll/sc case. > Thus it may fail to keep coherency. Is it intentional? Yes. Assuming do_page_fault did it's job successfully the address which has been passed as argument to sysmips() is now writable and thus we won't take any pagefaults. There are two remaining failure scenarios which probably are't very interesting for practical usage. It's when an interrupt is accessing the same address. This could be fixed by disabling interrupts. The other case is missaligned words. > Also the bad_stack exit point for the ll/sc case looks suspicient to me. Indeed, the symbol deserves a better name. Cut'n'paste happens ;-) Ralf From owner-linux-mips@oss.sgi.com Wed Oct 3 11:05:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93I5C920509 for linux-mips-outgoing; Wed, 3 Oct 2001 11:05:12 -0700 Received: from dea.linux-mips.net (a1as01-p32.stg.tli.de [195.252.185.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93I57D20506 for ; Wed, 3 Oct 2001 11:05:07 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f93I4us28398; Wed, 3 Oct 2001 20:04:56 +0200 Date: Wed, 3 Oct 2001 20:04:56 +0200 From: Ralf Baechle To: Brian Cc: linux-mips@oss.sgi.com Subject: Re: How do I console into Origin 200? Message-ID: <20011003200456.B28205@dea.linux-mips.net> References: <5.1.0.14.2.20011003172659.00a6c4a8@mail.it-academy.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from signal@shreve.net on Wed, Oct 03, 2001 at 09:48:20AM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Oct 03, 2001 at 09:48:20AM -0500, Brian wrote: > I am trying to boot an Origin 200 (which I believe currently has IRIX on > it, I will be installing linux-mips). It has 2 9 pin serial connectors on > the back. I have hooked my Wyse terminal up to it with a serial cable > with and without a null connector @ 9600bps. Is this correct? I get > nothing on the screen. I have never consoled into an Origin, and am not > sure if I am doing this right. Yes, that's correct and by default IRIX also runs a getty on the console. So you probably want to doublecheck cables. Also disable handshaking. Ralf PS: Replying when you actually want to start a new thread is a bad idea. From owner-linux-mips@oss.sgi.com Wed Oct 3 12:09:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93J94921745 for linux-mips-outgoing; Wed, 3 Oct 2001 12:09:04 -0700 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93J8xD21741 for ; Wed, 3 Oct 2001 12:08:59 -0700 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 3 Oct 2001 19:10:19 UT Received: from bud.austin.esstech.com ([193.5.206.3]) by mail.esstech.com (8.8.8+Sun/8.8.8) with SMTP id MAA16037 for ; Wed, 3 Oct 2001 12:07:35 -0700 (PDT) Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id OAA18628; Wed, 3 Oct 2001 14:07:25 -0500 Message-ID: <3BBB62DE.3040003@esstech.com> Date: Wed, 03 Oct 2001 14:11:26 -0500 From: Gerald Champagne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Remove ifdefs from setup_arch() Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have been modifying the linux kernel to support a custom hardware board of ours, and I'm trying to minimize additional changes and ifdefs in the kernel. I noticed that the setup_arch function in arch/mips/kernel/setup.c has a new ifdef for each board type that is supported, and it looks like this could be simplified. The code looks something like this: ----------------- void __init setup_arch(char **cmdline_p) { void boardname1_setup(void); void boardname1_setup(void); void boardname1_setup(void); ... switch (mips_machgroup) { #ifdef CONFIG_BOARDNAME1 case: MACH_GROUP_WHATEVER1: boardname1_setup(); break; #endif #ifdef CONFIG_BOARDNAME2 case: MACH_GROUP_WHATEVER2: boardname2_setup(); break; #endif #ifdef CONFIG_BOARDNAME3 case: MACH_GROUP_WHATEVER3: boardname3_setup(); break; #endif default: panic("Unsupported architecture"); } ... ----------------- For each configuration, only one case is compiled in. Wouldn't it be simpler to just give the board-specific setup function a common name and consider it part of the board-specific api like all the other board-specific functions. Can this be changed to just this: ----------------- void __init setup_arch(char **cmdline_p) { void foo_setup(void); ... foo_setup(); /* someone pick a name for this */ ... ----------------- I'm trying to document an api for supporting an arbitrary board, and little things like this make it more difficult to define something along the lines of a bsp interface. Any suggestions? Any objections? Thanks. Gerald From owner-linux-mips@oss.sgi.com Wed Oct 3 12:29:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93JThF22112 for linux-mips-outgoing; Wed, 3 Oct 2001 12:29:43 -0700 Received: from dea.linux-mips.net (a1as01-p32.stg.tli.de [195.252.185.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93JTcD22106 for ; Wed, 3 Oct 2001 12:29:38 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f93JTO528867; Wed, 3 Oct 2001 21:29:24 +0200 Date: Wed, 3 Oct 2001 21:29:24 +0200 From: Ralf Baechle To: Gerald Champagne Cc: "linux-mips@oss.sgi.com" Subject: Re: Remove ifdefs from setup_arch() Message-ID: <20011003212924.A28810@dea.linux-mips.net> References: <3BBB62DE.3040003@esstech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BBB62DE.3040003@esstech.com>; from gerald.champagne@esstech.com on Wed, Oct 03, 2001 at 02:11:26PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Oct 03, 2001 at 02:11:26PM -0500, Gerald Champagne wrote: > For each configuration, only one case is compiled in. Wouldn't it > be simpler to just give the board-specific setup function a common name > and consider it part of the board-specific api like all the other > board-specific functions. Can this be changed to just this: > > ----------------- > void __init setup_arch(char **cmdline_p) > { > void foo_setup(void); > > ... > > foo_setup(); /* someone pick a name for this */ > ... > ----------------- > > I'm trying to document an api for supporting an arbitrary board, and little > things like this make it more difficult to define something along the lines > of a bsp interface. Any suggestions? Any objections? We used to allow support for multiple boards in one kernel binary though that usually doesn't work for MIPS due to the large number of very different systems. People have asked to resurrect this option, so I'd like to go for an option that only removes all those awful #ifdefs. Something based on ELF sections looks like a way to do this. Ralf From owner-linux-mips@oss.sgi.com Wed Oct 3 14:20:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93LKcM25107 for linux-mips-outgoing; Wed, 3 Oct 2001 14:20:38 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93LKUD25104; Wed, 3 Oct 2001 14:20:30 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f93LNLB32003; Wed, 3 Oct 2001 14:23:21 -0700 Message-ID: <3BBB7F14.C864736A@mvista.com> Date: Wed, 03 Oct 2001 14:11:48 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Gerald Champagne , "linux-mips@oss.sgi.com" Subject: Re: Remove ifdefs from setup_arch() References: <3BBB62DE.3040003@esstech.com> <20011003212924.A28810@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Gereald, The following is copied from one of my previous posts in linux-mips mailing list. I think this is a reasonable idea. BTW, do_initcalls() scheme is the same thing as Ralf is referring to as ELF section. Jun ..... I talked about machine detection a while back. My idea is following: 0. all machines that are *configured* into the image will supply _detect() and _setup() functions. 1. at MIPS start up, we loop through all _detect(), which returns three values, a) run-time detection negative, b) run-time detection positive, and c) no run-time detection code, but I return positive because I am configured in. 2. the startup code resolves conflicts (which sometimes may panic); and decide on one machine. 3. then the startup code calls the right _setup() code which will set up the mach_type and other stuff. BTW, a side benenfit of doing this is that we can remove all the machine specific code in common files such as bootinfo.h, setup.c, etc, which are getting harder and harder to maintain as we are adding more and more embedded boards to the tree. If we push it to an extreme by using mechnism like do_initcalls(), we can achieve zero common source file modification when adding a new a machine. This will greatly facilitate embedded development as it allows more parallel development and allow people to maintain their own board code much easier before the code is submitted to the tree. Jun Ralf Baechle wrote: > > On Wed, Oct 03, 2001 at 02:11:26PM -0500, Gerald Champagne wrote: > > > For each configuration, only one case is compiled in. Wouldn't it > > be simpler to just give the board-specific setup function a common name > > and consider it part of the board-specific api like all the other > > board-specific functions. Can this be changed to just this: > > > > ----------------- > > void __init setup_arch(char **cmdline_p) > > { > > void foo_setup(void); > > > > ... > > > > foo_setup(); /* someone pick a name for this */ > > ... > > ----------------- > > > > I'm trying to document an api for supporting an arbitrary board, and little > > things like this make it more difficult to define something along the lines > > of a bsp interface. Any suggestions? Any objections? > > We used to allow support for multiple boards in one kernel binary though > that usually doesn't work for MIPS due to the large number of very different > systems. People have asked to resurrect this option, so I'd like to go > for an option that only removes all those awful #ifdefs. Something based > on ELF sections looks like a way to do this. > > Ralf From owner-linux-mips@oss.sgi.com Wed Oct 3 14:22:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93LMLQ25201 for linux-mips-outgoing; Wed, 3 Oct 2001 14:22:21 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93LMHD25190; Wed, 3 Oct 2001 14:22:17 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f93LP3B32108; Wed, 3 Oct 2001 14:25:03 -0700 Message-ID: <3BBB7F7A.7AB0411@mvista.com> Date: Wed, 03 Oct 2001 14:13:30 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux References: <200109300029.f8U0TZv12410@oss.sgi.com> <20011003195059.A28205@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Wed, Oct 03, 2001 at 01:02:56PM +0200, Maciej W. Rozycki wrote: > > > > Modified files: > > > arch/mips/kernel: scall_o32.S sysmips.c > > > > > > Log message: > > > Barf. > > > > The new mips_atomic_set() doesn't mask interrupts in the non-ll/sc case. > > Thus it may fail to keep coherency. Is it intentional? > > Yes. Assuming do_page_fault did it's job successfully the address which > has been passed as argument to sysmips() is now writable and thus we > won't take any pagefaults. > > There are two remaining failure scenarios which probably are't very > interesting for practical usage. It's when an interrupt is accessing > the same address. This could be fixed by disabling interrupts. > The other case is missaligned words. > And a third one - when you enable kernel preemption with the preemptable kernel patch. :-) Jun From owner-linux-mips@oss.sgi.com Wed Oct 3 14:28:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93LSJZ25385 for linux-mips-outgoing; Wed, 3 Oct 2001 14:28:19 -0700 Received: from dea.linux-mips.net (a1as01-p32.stg.tli.de [195.252.185.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93LSFD25381 for ; Wed, 3 Oct 2001 14:28:16 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f93LRjw26452; Wed, 3 Oct 2001 23:27:45 +0200 Date: Wed, 3 Oct 2001 23:27:45 +0200 From: Ralf Baechle To: Jun Sun Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20011003232745.A28943@dea.linux-mips.net> References: <200109300029.f8U0TZv12410@oss.sgi.com> <20011003195059.A28205@dea.linux-mips.net> <3BBB7F7A.7AB0411@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: <3BBB7F7A.7AB0411@mvista.com>; from jsun@mvista.com on Wed, Oct 03, 2001 at 02:13:30PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Oct 03, 2001 at 02:13:30PM -0700, Jun Sun wrote: > And a third one - when you enable kernel preemption with the preemptable > kernel patch. :-) Other people's problem. Ralf From owner-linux-mips@oss.sgi.com Wed Oct 3 16:08:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93N8EQ27496 for linux-mips-outgoing; Wed, 3 Oct 2001 16:08:14 -0700 Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93N88D27490 for ; Wed, 3 Oct 2001 16:08:09 -0700 Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id BAA11531 for ; Thu, 4 Oct 2001 01:08:06 +0200 (MEST) (envelope-from balaji.ramalingam@philips.com) From: balaji.ramalingam@philips.com Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-nl4.philips.com via mwrap (4.0a) id xma011529; Thu, 4 Oct 01 01:08:06 +0200 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id BAA19405 for ; Thu, 4 Oct 2001 01:08:05 +0200 (MET DST) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA16708 for ; Wed, 3 Oct 2001 18:08:04 -0500 (CDT) Subject: mipsel-linux cross compiler issue while installing To: linux-mips@oss.sgi.com Date: Wed, 3 Oct 2001 16:08:35 -0700 Message-ID: X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 03/10/2001 18:11:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello Support, I 'm working in Philips Semiconductors, Sunnyvale, CA in the MIPS core group. I'm planning to boot the linux kernel on our latest 4kc mips32 core. I thought of installing the compiler source available for mips2 ISA and and later edit them for mips32 ISA. I tried downloading the compiler source for linux mips from the following link. ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev I edited the make-cross.sh to change the base path and target and when I ran the script I got the following errors while installing the glibc. Can you please help me in fixing this error? Is there a patch or something which I'm missing here? regards, Balaji Ramalingam 408 991 2941 work phone ----------------------------------------------------------------------------------------------------- make[2]: Entering directory `/home/ramaling/crossdev-build/src/glibc-2.2.3-20010 421/setjmp' mipsel-linux-gcc ../sysdeps/mips/setjmp.S -c -I../include -I. -I/home/ramaling/ crossdev-build/mipsel-linux/glibc-2.2.3-20010421-obj/setjmp -I.. -I../libio -I/ home/ramaling/crossdev-build/mipsel-linux/glibc-2.2.3-20010421-obj -I../sysdeps/ mips/elf -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pth read -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../lin uxthreads/sysdeps/mips -I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/ linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysd eps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips -I../sysdeps/unix -I ../sysdeps/posix -I../sysdeps/mips/mipsel -I../sysdeps/mips/fpu -I../sysdeps/mip s -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl- 64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/gnu-kalra/pc-linux/lib/gcc-lib/mipsel-linux/2.95.1/include -isyst em /home/ramaling/crossdev/mipsel-linux/mipsel-linux/include -D_LIBC_REENTRANT - include ../include/libc-symbols.h -DASSEMBLER -o /home/ramaling/crossdev-b uild/mipsel-linux/glibc-2.2.3-20010421-obj/setjmp/setjmp.o ../sysdeps/mips/setjmp.S: Assembler messages: ../sysdeps/mips/setjmp.S:43: Error: Can not represent BFD_RELOC_16_PCREL_S2 relo cation in this object file format make[2]: *** [/home/ramaling/crossdev-build/mipsel-linux/glibc-2.2.3-20010421-ob j/setjmp/setjmp.o] Error 1 make[2]: Leaving directory `/home/ramaling/crossdev-build/src/glibc-2.2.3-200104 21/setjmp' make[1]: *** [setjmp/subdir_lib] Error 2 make[1]: Leaving directory `/home/ramaling/crossdev-build/src/glibc-2.2.3-200104 21' make: *** [all] Error 2 [ramaling@svlhp106 crossdev-build]$ ----------------------------------------------------------------------------------------------------- From owner-linux-mips@oss.sgi.com Wed Oct 3 16:17:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f93NHSh27707 for linux-mips-outgoing; Wed, 3 Oct 2001 16:17:28 -0700 Received: from dea.linux-mips.net (a1as01-p32.stg.tli.de [195.252.185.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f93NHOD27704 for ; Wed, 3 Oct 2001 16:17:24 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f93NHAm00679; Thu, 4 Oct 2001 01:17:10 +0200 Date: Thu, 4 Oct 2001 01:17:10 +0200 From: Ralf Baechle To: balaji.ramalingam@philips.com Cc: linux-mips@oss.sgi.com Subject: Re: mipsel-linux cross compiler issue while installing Message-ID: <20011004011710.A483@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from balaji.ramalingam@philips.com on Wed, Oct 03, 2001 at 04:08:35PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Oct 03, 2001 at 04:08:35PM -0700, balaji.ramalingam@philips.com wrote: > ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev > > I edited the make-cross.sh to change the base path and target and when I ran the script > I got the following errors while installing the glibc. > > Can you please help me in fixing this error? > Is there a patch or something which I'm missing here? That's a compiler bug. It should always define __PIC__. Ralf From owner-linux-mips@oss.sgi.com Wed Oct 3 22:16:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f945GcO01378 for linux-mips-outgoing; Wed, 3 Oct 2001 22:16:38 -0700 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f945GaD01375 for ; Wed, 3 Oct 2001 22:16:36 -0700 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id f945GW319479; Thu, 4 Oct 2001 01:16:32 -0400 Date: Thu, 4 Oct 2001 01:16:32 -0400 From: Jim Paris To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: test machines; illegal instructions Message-ID: <20011004011632.A19472@neurosis.mit.edu> Reply-To: jim@jtan.com References: <20010926221223.A17628@neurosis.mit.edu> <20010926202610.B7962@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010926202610.B7962@lucon.org>; from hjl@lucon.org on Wed, Sep 26, 2001 at 08:26:10PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > seen anything similar? It's quite possibly a buggy cross compiler > > I won't recommend gcc 3.0.1 for mips. My RedHat 7.1 port has everyting > you need for cross/native compiling. Even with the glibc and fileutils binaries from your port, 'rm' still either segfaults or gives an illegal instruction, so it's pretty certain that this is a kernel or CPU issue somehow. Have you seen anything like this? 'rm' does work if I compile fileutils with -O0, but there still seems to be a larger problem at hand. -jim From owner-linux-mips@oss.sgi.com Thu Oct 4 03:23:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94AN4N07149 for linux-mips-outgoing; Thu, 4 Oct 2001 03:23:04 -0700 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94AMwD07145 for ; Thu, 4 Oct 2001 03:22:58 -0700 Received: from [192.168.1.233] (192.168.1.233 [192.168.1.233]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNP89; Thu, 4 Oct 2001 06:22:52 -0400 Subject: Re: mipsel-linux cross compiler issue while installing From: Marc Karasek To: balaji.ramalingam@philips.com Cc: linux-mips@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14.99+cvs.2001.09.22.08.08 (Preview Release) Date: 04 Oct 2001 06:23:08 -0400 Message-Id: <1002190997.1402.14.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk As long as you just want to do LE, I would recommend the package from Monta Vista. It is there journeyman distrobution. It has both a cross-compiler for LE along with there released 2.4.2 kernel. They went thru a long process to validate this kernel, and have incorporated/fixed many bugs that were outstanding. This delayed the release of this port by about 3 months. Just my 2 cents...... On Wed, 2001-10-03 at 19:08, balaji.ramalingam@philips.com wrote: > > Hello Support, > > I 'm working in Philips Semiconductors, Sunnyvale, CA in the MIPS core group. > I'm planning to boot the linux kernel on our latest 4kc mips32 core. > I thought of installing the compiler source available for mips2 ISA and and later edit > them for mips32 ISA. > > I tried downloading the compiler source for linux mips from the following link. > > ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev > > I edited the make-cross.sh to change the base path and target and when I ran the script > I got the following errors while installing the glibc. > > Can you please help me in fixing this error? > Is there a patch or something which I'm missing here? > > > regards, > Balaji Ramalingam > 408 991 2941 work phone > ----------------------------------------------------------------------------------------------------- > > make[2]: Entering directory `/home/ramaling/crossdev-build/src/glibc-2.2.3-20010 > 421/setjmp' > mipsel-linux-gcc ../sysdeps/mips/setjmp.S -c -I../include -I. -I/home/ramaling/ > crossdev-build/mipsel-linux/glibc-2.2.3-20010421-obj/setjmp -I.. -I../libio -I/ > home/ramaling/crossdev-build/mipsel-linux/glibc-2.2.3-20010421-obj -I../sysdeps/ > mips/elf -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pth > read -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../lin > uxthreads/sysdeps/mips -I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/ > linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysd > eps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips -I../sysdeps/unix -I > ../sysdeps/posix -I../sysdeps/mips/mipsel -I../sysdeps/mips/fpu -I../sysdeps/mip > s -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl- > 64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc > -isystem /usr/gnu-kalra/pc-linux/lib/gcc-lib/mipsel-linux/2.95.1/include -isyst > em /home/ramaling/crossdev/mipsel-linux/mipsel-linux/include -D_LIBC_REENTRANT - > include ../include/libc-symbols.h -DASSEMBLER -o /home/ramaling/crossdev-b > uild/mipsel-linux/glibc-2.2.3-20010421-obj/setjmp/setjmp.o > ../sysdeps/mips/setjmp.S: Assembler messages: > ../sysdeps/mips/setjmp.S:43: Error: Can not represent BFD_RELOC_16_PCREL_S2 relo > cation in this object file format > make[2]: *** [/home/ramaling/crossdev-build/mipsel-linux/glibc-2.2.3-20010421-ob > j/setjmp/setjmp.o] Error 1 > make[2]: Leaving directory `/home/ramaling/crossdev-build/src/glibc-2.2.3-200104 > 21/setjmp' > make[1]: *** [setjmp/subdir_lib] Error 2 > make[1]: Leaving directory `/home/ramaling/crossdev-build/src/glibc-2.2.3-200104 > 21' > make: *** [all] Error 2 > [ramaling@svlhp106 crossdev-build]$ > > ----------------------------------------------------------------------------------------------------- > > -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Thu Oct 4 08:10:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94FAFv13453 for linux-mips-outgoing; Thu, 4 Oct 2001 08:10:15 -0700 Received: from firewall.i-data.com (firewall.i-data.com [195.24.22.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94FA8D13447 for ; Thu, 4 Oct 2001 08:10:10 -0700 From: tommy.christensen@eicon.com Received: (qmail 3425 invoked from network); 4 Oct 2001 15:10:06 -0000 Received: from idahub2000.i-data.com (HELO idanshub.i-data.com) (172.16.1.8) by firewall.i-data.com with SMTP; 4 Oct 2001 15:10:06 -0000 Received: from eicon.com ([172.17.159.1]) by idanshub.i-data.com (Lotus Domino Release 5.0.8) with ESMTP id 2001100417122646:6498 ; Thu, 4 Oct 2001 17:12:26 +0200 Message-ID: <3BBC7C31.A452AD03@eicon.com> Date: Thu, 4 Oct 2001 17:11:45 +0200 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) MIME-Version: 1.0 To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Register allocation in copy_to_user References: <3BB0D217.80E313F5@eicon.com> X-MIMETrack: Itemize by SMTP Server on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 04-10-2001 17:12:26, MIME-CD by Notes Server on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 04-10-2001 17:12:26, MIME-CD complete at 04-10-2001 17:12:26, Serialize by Router on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 04-10-2001 17:12:27 Content-type: multipart/mixed; Boundary="0__=C1256ADB0053896B8f9e8a93df938690918cC1256ADB0053896B" Content-Disposition: inline Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --0__=C1256ADB0053896B8f9e8a93df938690918cC1256ADB0053896B Content-type: text/plain; charset=us-ascii tommy.christensen@eicon.com wrote: > > Anyway, the attached patch solves this by explicitly building the arguments > to __copy_user in the argument registers ;-) instead of moving them around. This idea totally breaks, when the arguments (to copy_to_user) contain a function call. We force the compiler to use a caller-saved register (like a0) across the function call. One place this happens is in net/ipv4/netfilter/ ip_tables.c/copy_entries_to_user(). The patch below fixes this, while preserving the original fix (for the tty corruption). Although this is getting a little messy, the patch is not as bad as it might seem. gcc will discard the extra temporary variables (cu_to, cu_from and cu_len) in far the most cases, and use them where necessary to handle function calls. Sorry, if this has caused any trouble. -Tommy (See attached file: uaccess.patch.gz) --0__=C1256ADB0053896B8f9e8a93df938690918cC1256ADB0053896B Content-type: application/octet-stream; name="uaccess.patch.gz" Content-Disposition: attachment; filename="uaccess.patch.gz" Content-transfer-encoding: base64 H4sICDBjvDsAA3VhY2Nlc3MucGF0Y2gA7ZVda9swFIav419x8HZhz3Zqy2maugxSaAodHYWsWxkE RLCVVMyRgiyXfbD/PlmyGydNXXbvK8lH5z3nPeJBDoIAKEvzMiMny2ITbOi2OCmXaUqKYvg45IKu Bw8kgy9kC2gM4SSJUYLOAYVhZHme1yEe3D+WcJdKgBFEUYImCUJGN51CgM5CP4rB0+sYplMLyE9J BIOC/iZYAsYp3/7CZUGE88RpBh8wltyHlLNCQhNZCb7xdxLmXlhgwbuMrCgjTQ3JTRkl1/nMBecP LKxgIMiaFqrrc720VNlKp8bBGBz7/ch2L/ZT9w0oQVWzLTl9Ick5W4POzQlrp45NqndoRNvwuwx5 xw3Vdvxua96BNWPM77IIg2qixs9HUJdZT7lrpKLV2o5XxVSY1W0P1TryQqujB8pdZ722grW83rUO TAWzMSM0Y2H8xPOlpDnB2NEn6ujz3dXX2xn+dHnrtNhz9XECtidscGoXrt/+1r73IqphpdOcT8aG 88l5w/lf9wijVZGe0p7SbkrtYUHkQjIuCBcZEQu2kPbbAFcgxuGZBjGO4uMg9k9lD+EOQroCx/zJ Mf/hfJvNb66/44f5zf2snr269OfHzm0YfJXct/lEp4bPeNTBZ/9M9oR2ETqfXV7Vo5ur+x9EX3td /wGM8rEbJQsAAA== --0__=C1256ADB0053896B8f9e8a93df938690918cC1256ADB0053896B-- From owner-linux-mips@oss.sgi.com Thu Oct 4 08:47:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94Flxd14728 for linux-mips-outgoing; Thu, 4 Oct 2001 08:47:59 -0700 Received: from linpro.no (qmailr@mail.linpro.no [213.203.57.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94FluD14725 for ; Thu, 4 Oct 2001 08:47:57 -0700 Received: (qmail 5024 invoked from network); 4 Oct 2001 15:47:54 -0000 Received: from false.linpro.no (213.203.57.201) by mail.linpro.no with SMTP; 4 Oct 2001 15:47:54 -0000 Received: from toffer by false.linpro.no with local (Exim 3.22 #1 (Debian)) id 15pAiy-0007iJ-00; Thu, 04 Oct 2001 17:47:48 +0200 To: Guido Guenther Cc: debian-mips@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: Need an account on a Linux/Mips box References: <1f05gge.7bt3xkxllentM@[10.0.12.137]> <20010924173723.A2203@bunny.shuttle.de> <20010929122045.A12811@galadriel.physik.uni-konstanz.de> From: Kristoffer Gleditsch Organization: Millennium Hand And Shrimp Society Date: Thu, 04 Oct 2001 17:47:48 +0200 Message-ID: Lines: 17 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk [ Guido Guenther ] > Toolchain update problem - recompiling fixes this. I've put recompiled > debs at: > > http://honk.physik.uni-konstanz.de/linux-mips/debian/ssl-tmp/ Thanks, they seem to work fine. Concerning the other R4600 issues: Our R4600 Indy has 11 days of uptime now, and Bind 9 is still running fine. When I switched back to ssh from ssh-nonfree just now, the calls to update-alternatives in the prerm-file segfaulted repeatedly. I'm trying to gather the patience to debug it now. :) -- Kristoffer. From owner-linux-mips@oss.sgi.com Thu Oct 4 09:00:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94G00Y15097 for linux-mips-outgoing; Thu, 4 Oct 2001 09:00:00 -0700 Received: from perjantai.hit.fi (root@perjantai.hit.fi [193.167.196.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94FxvD15094 for ; Thu, 4 Oct 2001 08:59:58 -0700 Received: from maanantai.hit.fi (pkoistin@maanantai.hit.fi [193.167.196.11]) by perjantai.hit.fi (8.9.1/8.9.1/EPIPE-1.9) with ESMTP id SAA09528; Thu, 4 Oct 2001 18:59:52 +0300 (EEST) Date: Thu, 4 Oct 2001 18:59:52 +0300 From: Petri Tapio Koistinen To: debian-mips@lists.debian.org cc: linux-mips@oss.sgi.com Subject: Installation instructions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi! I have seven Indys for Linux and NetBSD use. Is there somewhere installation instruction from point zero. Is there CD-ROMs available where Debian/mips can installed. Thanks! Petri From owner-linux-mips@oss.sgi.com Thu Oct 4 09:17:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94GHia15570 for linux-mips-outgoing; Thu, 4 Oct 2001 09:17:44 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94GHfD15567 for ; Thu, 4 Oct 2001 09:17:41 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id QAA12885 for linux-mips@oss.sgi.com; Thu, 4 Oct 2001 16:17:39 GMT From: Robin Humble Message-Id: <200110041617.QAA12885@groucho.maths.monash.edu.au> Subject: Some native mips/Indy rpms To: linux-mips@oss.sgi.com Date: Fri, 5 Oct 2001 02:17:39 +1000 (EST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I spent a while compiling up native mips/Indy rpms to add onto H.J.'s RedHat 7.1 distro. It took a while to build these (eg. 17hrs per compile for X) so to save people some time and effort I thought I'd put them up for download. Mostly they came from a recent 'rawhide' so they're somewhere between RH7.1 and RH7.2. The exceptions are XFree4 and glibc which are from H.J.'s SRPMs. For at least the next few weeks they're at: http://www.cita.utoronto.ca/~rjh/mips/ The main ones are XFree4, perl, tcsh, gtk+, glibc and gdm. But there are lots of other rpms in there too. As far as I can tell they all work fine. I'm sure I did some dodgy things to a couple of them whilst making patches and altering spec files, so don't expect those few to be elegant or particularly portable. Those packages that I had to tweak are available in the SRPMS dir. openjade isn't there either (as I failed to get it to build) but AFAICT it's not really needed. I'm away from my Indy 'til Xmas so can't do any more unfortunately :-/ Hope it's useful to someone! :) cheers, robin From owner-linux-mips@oss.sgi.com Thu Oct 4 10:24:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94HOEa17725 for linux-mips-outgoing; Thu, 4 Oct 2001 10:24:14 -0700 Received: from are.twiddle.net (are.twiddle.net [64.81.246.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94HOCD17722 for ; Thu, 4 Oct 2001 10:24:12 -0700 Received: (from rth@localhost) by are.twiddle.net (8.11.6/8.11.6) id f94HO8O11435; Thu, 4 Oct 2001 10:24:08 -0700 Date: Thu, 4 Oct 2001 10:24:08 -0700 From: Richard Henderson To: Jakub Jelinek Cc: Kjeld Borch Egevang , "H . J . Lu" , GNU C Library , linux-mips mailing list Subject: Re: PATCH: Update sysdeps/mips/fpu/libm-test-ulps Message-ID: <20011004102408.A11412@twiddle.net> References: <20010914111751.A17316@lucon.org> <20011001121053.F3251@sunsite.ms.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011001121053.F3251@sunsite.ms.mff.cuni.cz>; from jakub@redhat.com on Mon, Oct 01, 2001 at 12:10:53PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Oct 01, 2001 at 12:10:53PM +0200, Jakub Jelinek wrote: > The way soft-fp interprets Quiet NaNs is not just Intel-way, e.g. SPARC, > Alpha work the same way. E.g. on SPARC, signalling NaN is exp=max, > f=.0xxxxxxxxxx...xxx where at least one of the x bits is set, quiet NaN is > exp=max, f=.1xxxxxxxxxx...xxxxxx. > If MIPS has it backwards, Yes indeed. From the Mips32 spec I have handy: Unbiased E f s b1 Value V Typical Single Bit Pattern E_max+1 != 0 x 1 SNaN 16#7fffffff E_max+1 != 0 x 0 QNaN 16#7fbfffff r~ From owner-linux-mips@oss.sgi.com Thu Oct 4 11:12:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94ICje19134 for linux-mips-outgoing; Thu, 4 Oct 2001 11:12:45 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94ICiD19131 for ; Thu, 4 Oct 2001 11:12:44 -0700 Received: from mvista.com (IDENT:ahennessy@penelope.mvista.com [10.0.0.122]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f94IFXB11923; Thu, 4 Oct 2001 11:15:33 -0700 Message-ID: <3BBCA8A8.23CA468F@mvista.com> Date: Thu, 04 Oct 2001 11:21:28 -0700 From: Alice Hennessy X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com CC: ahennessy@mvista.com Subject: BOOTP problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, Just grabbed the latest code and BOOTP doesn't work with the latest net/ipv4/ipconfig.c (it does work with the ipconfig.c from a 6/11 snapshot). Anyone else having problems? Alice From owner-linux-mips@oss.sgi.com Thu Oct 4 11:26:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94IQ0x19414 for linux-mips-outgoing; Thu, 4 Oct 2001 11:26:00 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94IPoD19409 for ; Thu, 4 Oct 2001 11:25:50 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 16CA8125C8; Thu, 4 Oct 2001 11:25:48 -0700 (PDT) Date: Thu, 4 Oct 2001 11:25:48 -0700 From: "H . J . Lu" To: Alice Hennessy Cc: linux-mips@oss.sgi.com Subject: Re: BOOTP problem Message-ID: <20011004112548.A15124@lucon.org> References: <3BBCA8A8.23CA468F@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: <3BBCA8A8.23CA468F@mvista.com>; from ahennessy@mvista.com on Thu, Oct 04, 2001 at 11:21:28AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Oct 04, 2001 at 11:21:28AM -0700, Alice Hennessy wrote: > Hello, > > Just grabbed the latest code and BOOTP doesn't work with the latest > net/ipv4/ipconfig.c > (it does work with the ipconfig.c from a 6/11 snapshot). Anyone else > having problems? > There was a problem. Try this patch. BTW, I was told it was fixed in the current kernel. H.J. ---- --- linux-2.4.5-ac3-ext3/net/ipv4/ipconfig.c.dhcp Tue May 1 20:59:24 2001 +++ linux-2.4.5-ac3-ext3/net/ipv4/ipconfig.c Tue May 29 09:30:16 2001 @@ -816,61 +816,63 @@ static int __init ic_bootp_recv(struct s u8 *ext; #ifdef IPCONFIG_DHCP + if (ic_proto_enabled & IC_USE_DHCP) { - u32 server_id = INADDR_NONE; - int mt = 0; + u32 server_id = INADDR_NONE; + int mt = 0; - ext = &b->exten[4]; - while (ext < end && *ext != 0xff) { - u8 *opt = ext++; - if (*opt == 0) /* Padding */ - continue; - ext += *ext + 1; - if (ext >= end) - break; - switch (*opt) { - case 53: /* Message type */ - if (opt[1]) - mt = opt[2]; - break; - case 54: /* Server ID (IP address) */ - if (opt[1] >= 4) - memcpy(&server_id, opt + 2, 4); - break; + ext = &b->exten[4]; + while (ext < end && *ext != 0xff) { + u8 *opt = ext++; + if (*opt == 0) /* Padding */ + continue; + ext += *ext + 1; + if (ext >= end) + break; + switch (*opt) { + case 53: /* Message type */ + if (opt[1]) + mt = opt[2]; + break; + case 54: /* Server ID (IP address) */ + if (opt[1] >= 4) + memcpy(&server_id, opt + 2, 4); + break; + } } - } #ifdef IPCONFIG_DEBUG - printk("DHCP: Got message type %d\n", mt); + printk("DHCP: Got message type %d\n", mt); #endif - switch (mt) { - case DHCPOFFER: - /* While in the process of accepting one offer, - ignore all others. */ - if (ic_myaddr != INADDR_NONE) - goto drop; - /* Let's accept that offer. */ - ic_myaddr = b->your_ip; - ic_servaddr = server_id; + switch (mt) { + case DHCPOFFER: + /* While in the process of accepting one offer, + ignore all others. */ + if (ic_myaddr != INADDR_NONE) + goto drop; + /* Let's accept that offer. */ + ic_myaddr = b->your_ip; + ic_servaddr = server_id; #ifdef IPCONFIG_DEBUG - printk("DHCP: Offered address %u.%u.%u.%u", NIPQUAD(ic_myaddr)); - printk(" by server %u.%u.%u.%u\n", NIPQUAD(ic_servaddr)); + printk("DHCP: Offered address %u.%u.%u.%u", NIPQUAD(ic_myaddr)); + printk(" by server %u.%u.%u.%u\n", NIPQUAD(ic_servaddr)); #endif - break; + break; - case DHCPACK: - /* Yeah! */ - break; - - default: - /* Urque. Forget it*/ - ic_myaddr = INADDR_NONE; - ic_servaddr = INADDR_NONE; - goto drop; - } + case DHCPACK: + /* Yeah! */ + break; + + default: + /* Urque. Forget it*/ + ic_myaddr = INADDR_NONE; + ic_servaddr = INADDR_NONE; + goto drop; + } - ic_dhcp_msgtype = mt; + ic_dhcp_msgtype = mt; + } #endif /* IPCONFIG_DHCP */ From owner-linux-mips@oss.sgi.com Thu Oct 4 11:42:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94IgWp19940 for linux-mips-outgoing; Thu, 4 Oct 2001 11:42:32 -0700 Received: from kuolema.infodrom.north.de (postfix@kuolema.infodrom.north.de [217.89.86.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94IgTD19931 for ; Thu, 4 Oct 2001 11:42:29 -0700 Received: from finlandia.infodrom.north.de (finlandia.Infodrom.North.DE [217.89.86.34]) by kuolema.infodrom.north.de (Postfix) with ESMTP id CC3674D74F; Thu, 4 Oct 2001 20:42:23 +0200 (CEST) Received: by finlandia.infodrom.north.de (Postfix, from userid 501) id EE944FE47; Thu, 4 Oct 2001 20:42:22 +0200 (CEST) Date: Thu, 4 Oct 2001 20:42:22 +0200 From: Martin Schulze To: Alice Hennessy Cc: linux-mips@oss.sgi.com Subject: Re: BOOTP problem Message-ID: <20011004204222.Z18353@finlandia.infodrom.north.de> Reply-To: Martin Schulze References: <3BBCA8A8.23CA468F@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <3BBCA8A8.23CA468F@mvista.com> User-Agent: Mutt/1.3.20i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Alice Hennessy wrote: > Hello, > > Just grabbed the latest code and BOOTP doesn't work with the latest > net/ipv4/ipconfig.c > (it does work with the ipconfig.c from a 6/11 snapshot). Anyone else > having problems? Did you add 'ip=auto' to the kernel commandline? If not, try that. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror. From owner-linux-mips@oss.sgi.com Thu Oct 4 11:56:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94IuVY20261 for linux-mips-outgoing; Thu, 4 Oct 2001 11:56:31 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94IuSD20254 for ; Thu, 4 Oct 2001 11:56:28 -0700 Received: from mvista.com (IDENT:ahennessy@penelope.mvista.com [10.0.0.122]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f94IwrB14224; Thu, 4 Oct 2001 11:58:53 -0700 Message-ID: <3BBCB2D1.C160949B@mvista.com> Date: Thu, 04 Oct 2001 12:04:49 -0700 From: Alice Hennessy X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: Martin Schulze CC: linux-mips@oss.sgi.com Subject: Re: BOOTP problem References: <3BBCA8A8.23CA468F@mvista.com> <20011004204222.Z18353@finlandia.infodrom.north.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Martin Schulze wrote: > Alice Hennessy wrote: > > Hello, > > > > Just grabbed the latest code and BOOTP doesn't work with the latest > > net/ipv4/ipconfig.c > > (it does work with the ipconfig.c from a 6/11 snapshot). Anyone else > > having problems? > > Did you add 'ip=auto' to the kernel commandline? If not, try that. > > Regards, > > Joey > > -- > Whenever you meet yourself you're in a time loop or in front of a mirror. Thanks - that did it. Alice From owner-linux-mips@oss.sgi.com Thu Oct 4 12:39:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94JdBZ21222 for linux-mips-outgoing; Thu, 4 Oct 2001 12:39:11 -0700 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94Jd8D21219 for ; Thu, 4 Oct 2001 12:39:08 -0700 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 4 Oct 2001 19:40:29 UT Received: from bud.austin.esstech.com ([193.5.206.3]) by mail.esstech.com (8.8.8+Sun/8.8.8) with SMTP id MAA00203 for ; Thu, 4 Oct 2001 12:37:45 -0700 (PDT) Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id OAA00565; Thu, 4 Oct 2001 14:37:31 -0500 Message-ID: <3BBCBB6B.6080809@esstech.com> Date: Thu, 04 Oct 2001 14:41:31 -0500 From: Gerald Champagne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Debugging symbols from gcc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm trying to use a Wind River VisionProbe debugger with the Linux kernel, but I can't get the compiler to generate the symbols in the proper format. The debugger works with an old compiler that places the symbols in sections called ".stab" and ".stabstr". It doesn't work with the newer compiler that places the symbols in a section called ".mdebug" (which I think is specific to sgi). The version that creates .stab/.stabstr sections is: $ /usr/local/sde4/bin/gcc --version egcs-2.90.23 980102 (egcs-1.0.1 release) The version that creates .mdebug sections is: $ /usr/bin/mips-linux-gcc --version egcs-2.91.66 Is there a way to specify the output format of the debug symbols? I've seen documentation that references a -gstabs option, but that doesn't seem to work. Should I be using a different version of the compiler? I'm just using the rpm's that were on the sgi site. Thanks. Gerald From owner-linux-mips@oss.sgi.com Thu Oct 4 12:41:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94JfpU21444 for linux-mips-outgoing; Thu, 4 Oct 2001 12:41:51 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94JfnD21440 for ; Thu, 4 Oct 2001 12:41:49 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 5D83F125C8; Thu, 4 Oct 2001 12:41:48 -0700 (PDT) Date: Thu, 4 Oct 2001 12:41:47 -0700 From: "H . J . Lu" To: Gerald Champagne Cc: "linux-mips@oss.sgi.com" Subject: Re: Debugging symbols from gcc Message-ID: <20011004124147.A16407@lucon.org> References: <3BBCBB6B.6080809@esstech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BBCBB6B.6080809@esstech.com>; from gerald.champagne@esstech.com on Thu, Oct 04, 2001 at 02:41:31PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Oct 04, 2001 at 02:41:31PM -0500, Gerald Champagne wrote: > I'm trying to use a Wind River VisionProbe debugger with the > Linux kernel, but I can't get the compiler to generate the symbols > in the proper format. The debugger works with an old compiler > that places the symbols in sections called ".stab" and ".stabstr". > It doesn't work with the newer compiler that places the symbols > in a section called ".mdebug" (which I think is specific to sgi). > > The version that creates .stab/.stabstr sections is: > $ /usr/local/sde4/bin/gcc --version egcs-2.90.23 980102 (egcs-1.0.1 release) > > The version that creates .mdebug sections is: > $ /usr/bin/mips-linux-gcc --version egcs-2.91.66 > > Is there a way to specify the output format of the debug symbols? I've > seen documentation that references a -gstabs option, but that doesn't > seem to work. Should I be using a different version of the compiler? > I'm just using the rpm's that were on the sgi site. > I have fixed it in the current binutils and gcc. Those in RedHat 7.1 for mips should be ok. At least, I can use gdb 5.1 on the Linux kernel. H.J. From owner-linux-mips@oss.sgi.com Thu Oct 4 16:07:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94N7Up24517 for linux-mips-outgoing; Thu, 4 Oct 2001 16:07:30 -0700 Received: from dea.linux-mips.net (a1as10-p168.stg.tli.de [195.252.189.168]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94N7ID24513 for ; Thu, 4 Oct 2001 16:07:19 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f94LLNG13713 for linux-mips@oss.sgi.com; Thu, 4 Oct 2001 23:21:23 +0200 Received: from linpro.no (qmailr@mail.linpro.no [213.203.57.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94FlID14718 for ; Thu, 4 Oct 2001 08:47:18 -0700 Received: (qmail 4059 invoked from network); 4 Oct 2001 15:27:15 -0000 Received: from false.linpro.no (213.203.57.201) by mail.linpro.no with SMTP; 4 Oct 2001 15:27:15 -0000 Received: from toffer by false.linpro.no with local (Exim 3.22 #1 (Debian)) id 15pAP5-0007S6-00; Thu, 04 Oct 2001 17:27:15 +0200 To: Peter Andersson Cc: linux-mips@oss.sgi.com Subject: Re: Installation/booting of Mips Linux from local harddrive... References: <5.1.0.14.0.20011002165702.00a512a0@192.168.1.5> From: Kristoffer Gleditsch Organization: Millennium Hand And Shrimp Society Date: Thu, 04 Oct 2001 17:27:15 +0200 In-Reply-To: <5.1.0.14.0.20011002165702.00a512a0@192.168.1.5> (Peter Andersson's message of "Tue, 02 Oct 2001 17:00:50 +0200") Message-ID: Lines: 15 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk [ Peter Andersson ] > Anyway to get to the point, i thought that i read somewhere a while > ago that you had managed to get linux to boot locally at the > machines now and just thought that i would ask you if its true. If by "boot locally" you mean booting the Linux kernel directly from local hard disk, then yes, it is true (at least for Indys.) There are several installation howtos out there, two of them are http://www.stafwag.f2s.com/indy/?lang=eng and http://www.ping.uio.no/~toffer/indy-sid.txt . They both contain URLs to kernels you can use. -- Kristoffer. From owner-linux-mips@oss.sgi.com Fri Oct 5 03:33:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95AX9200613 for linux-mips-outgoing; Fri, 5 Oct 2001 03:33:09 -0700 Received: from mind.be (open.your.mind.be [195.162.205.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95AX3D00600 for ; Fri, 5 Oct 2001 03:33:04 -0700 Received: (qmail 24982 invoked by uid 500); 5 Oct 2001 10:33:00 -0000 Date: Fri, 5 Oct 2001 12:33:00 +0200 From: Ulrik De Bie To: Kristoffer Gleditsch Cc: Guido Guenther , debian-mips@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: Need an account on a Linux/Mips box Message-ID: <20011005123300.C23786@mind.be> References: <1f05gge.7bt3xkxllentM@[10.0.12.137]> <20010924173723.A2203@bunny.shuttle.de> <20010929122045.A12811@galadriel.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from toffer@ping.uio.no on Thu, Oct 04, 2001 at 05:47:48PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 787 Lines: 22 On Thu, Oct 04, 2001 at 05:47:48PM +0200, Kristoffer Gleditsch wrote: > [ Guido Guenther ] > > > Toolchain update problem - recompiling fixes this. I've put recompiled > > debs at: > > > > http://honk.physik.uni-konstanz.de/linux-mips/debian/ssl-tmp/ > > Thanks, they seem to work fine. > > Concerning the other R4600 issues: Our R4600 Indy has 11 days of > uptime now, and Bind 9 is still running fine. When I switched back to > ssh from ssh-nonfree just now, the calls to update-alternatives in the > prerm-file segfaulted repeatedly. I'm trying to gather the patience > to debug it now. :) Quick and dirty hack that might work (I had quite a number of segfaults during installation and this trick did work): change the /bin/sh between bash and ash. Kind regards, Ulrik De Bie From owner-linux-mips@oss.sgi.com Fri Oct 5 08:12:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95FCco07644 for linux-mips-outgoing; Fri, 5 Oct 2001 08:12:38 -0700 Received: from dea.linux-mips.net (a1as14-p143.stg.tli.de [195.252.191.143]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95FCZD07640 for ; Fri, 5 Oct 2001 08:12:36 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f95FCVU11550; Fri, 5 Oct 2001 17:12:31 +0200 Date: Fri, 5 Oct 2001 17:12:31 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: DDB5074 Message-ID: <20011005171230.A11415@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 129 Lines: 4 Is there still somebody who takes care of the DDB 5074 board or has any interest in keeping up support for it otherwise? Ralf From owner-linux-mips@oss.sgi.com Fri Oct 5 10:57:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95HvGc12002 for linux-mips-outgoing; Fri, 5 Oct 2001 10:57:16 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95HvED11999 for ; Fri, 5 Oct 2001 10:57:14 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f95HxpB32123; Fri, 5 Oct 2001 10:59:51 -0700 Message-ID: <3BBDF25F.1A0F2283@mvista.com> Date: Fri, 05 Oct 2001 10:48:15 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: jim@jtan.com CC: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: test machines; illegal instructions References: <20010926221223.A17628@neurosis.mit.edu> <20010926202610.B7962@lucon.org> <20011004011632.A19472@neurosis.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 826 Lines: 21 Jim Paris wrote: > > > > seen anything similar? It's quite possibly a buggy cross compiler > > > > I won't recommend gcc 3.0.1 for mips. My RedHat 7.1 port has everyting > > you need for cross/native compiling. > > Even with the glibc and fileutils binaries from your port, 'rm' still > either segfaults or gives an illegal instruction, so it's pretty > certain that this is a kernel or CPU issue somehow. Have you seen > anything like this? 'rm' does work if I compile fileutils with -O0, > but there still seems to be a larger problem at hand. > If your cpu does not have ll/sc instruction, you might be suffering the famous sysmips() problem. The latest kernel should get you going. There is also FPU emulation bug which may cause this problem, but that only happens on heavy context switches and FPU usages. Jun From owner-linux-mips@oss.sgi.com Fri Oct 5 11:28:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95ISFL12986 for linux-mips-outgoing; Fri, 5 Oct 2001 11:28:15 -0700 Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95ISAD12980 for ; Fri, 5 Oct 2001 11:28:10 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA40034; Fri, 5 Oct 2001 14:25:46 -0400 Received: from localhost.localdomain (dyn9-47-18-112.des.beaverton.ibm.com [9.47.18.112]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f95IQrG147206; Fri, 5 Oct 2001 12:26:53 -0600 Received: (from dave@localhost) by localhost.localdomain (8.11.2/8.11.2) id f95IQpb02486; Fri, 5 Oct 2001 11:26:51 -0700 Date: Fri, 5 Oct 2001 11:26:51 -0700 From: "David C. Hansen" Message-Id: <200110051826.f95IQpb02486@localhost.localdomain> To: linux-mips@oss.sgi.com, ralf@gnu.org Subject: [PATCH] to fix locking in ip27-rtc.c open() and release() Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1314 Lines: 47 This patch fixes a potential race condition in ip27-rtc.c. The rtc_status variable is not sufficient to ensure exclusive write access to the file in the open() function. This patch adds locking around the necessary critical areas in open() and replaces the big kernel lock in release(). --- linux-2.4.10-clean/arch/mips64/sgi-ip27/ip27-rtc.c Tue Nov 28 21:42:04 2000 +++ linux/arch/mips64/sgi-ip27/ip27-rtc.c Tue Oct 2 13:23:09 2001 @@ -61,6 +61,7 @@ #define RTC_TIMER_ON 0x02 /* missed irq timer active */ static unsigned char rtc_status; /* bitmapped status byte. */ +static spinlock_t rtc_status_lock = SPIN_LOCK_UNLOCKED; static unsigned long rtc_freq; /* Current periodic IRQ rate */ static struct m48t35_rtc *rtc; @@ -166,10 +167,15 @@ static int rtc_open(struct inode *inode, struct file *file) { + spin_lock( rtc_status_lock ); if(rtc_status & RTC_IS_OPEN) + { + spin_unlock( rtc_status_lock ); return -EBUSY; + } rtc_status |= RTC_IS_OPEN; + spin_unlock( rtc_status_lock ); return 0; } @@ -180,9 +186,9 @@ * in use, and clear the data. */ - lock_kernel(); + spin_lock( rtc_status_lock ); rtc_status &= ~RTC_IS_OPEN; - unlock_kernel(); + spin_unlock( rtc_status_lock ); return 0; } -- David C. Hansen haveblue@us.ibm.com IBM LTC Base/OS Group (503)578-4080 From owner-linux-mips@oss.sgi.com Fri Oct 5 11:50:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95IoSH13744 for linux-mips-outgoing; Fri, 5 Oct 2001 11:50:28 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95IoOD13741; Fri, 5 Oct 2001 11:50:24 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f95InwE0005405; Fri, 5 Oct 2001 11:49:58 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f95Invk7005395; Fri, 5 Oct 2001 11:49:58 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 5 Oct 2001 11:49:57 -0700 (PDT) From: James Simmons To: Ralf Baechle cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: DDB5074 In-Reply-To: <20011005171230.A11415@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 182 Lines: 8 > Is there still somebody who takes care of the DDB 5074 board or has any > interest in keeping up support for it otherwise? I believe Brad LaRonde was working on those boards. From owner-linux-mips@oss.sgi.com Fri Oct 5 13:57:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KvJH20099 for linux-mips-outgoing; Fri, 5 Oct 2001 13:57:19 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95KvFD20095; Fri, 5 Oct 2001 13:57:15 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f95L01B09682; Fri, 5 Oct 2001 14:00:01 -0700 Message-ID: <3BBE1C99.8DFA3611@mvista.com> Date: Fri, 05 Oct 2001 13:48:25 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: James Simmons CC: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: DDB5074 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 428 Lines: 14 James Simmons wrote: > > > Is there still somebody who takes care of the DDB 5074 board or has any > > interest in keeping up support for it otherwise? > > I believe Brad LaRonde was working on those boards. AFAIK, Brad is only working on rockhopper, a variant of DDB5477. We will keep DDB5476 and DDB5477(and rockhopper). If nobody is interested in DDB5074, it might be a good time to get rid of it. Brad, speak up! Jun From owner-linux-mips@oss.sgi.com Fri Oct 5 13:58:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f95KwCI20245 for linux-mips-outgoing; Fri, 5 Oct 2001 13:58:12 -0700 Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f95Kw6D20236 for ; Fri, 5 Oct 2001 13:58:07 -0700 Received: (qmail 1804 invoked by uid 0); 5 Oct 2001 20:58:00 -0000 Received: from pd953ac6c.dip.t-dialin.net (HELO bogon.ms20.nix) (217.83.172.108) by mail.gmx.net (mp004-rz3) with SMTP; 5 Oct 2001 20:58:00 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id 8B906B815; Fri, 5 Oct 2001 22:59:21 +0200 (CEST) Date: Fri, 5 Oct 2001 22:59:20 +0200 From: Guido Guenther To: ralf@gnu.org Cc: linux-mips@oss.sgi.com Subject: dvhtool's calculates free space in vh incorrectly Message-ID: <20011005225920.A13026@bogon.ms20.nix> Mail-Followup-To: ralf@gnu.org, linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline User-Agent: Mutt/1.3.22i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1683 Lines: 61 --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The way dvhtool calculates the free space in the vh is bogus. Since this number is too small dvhtool may write past the end of the vh. Attached patch fixes this. Can I get the dvhtool cvs commit messages from somewhere? -- Guido --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dvhtool-2001-10-05.diff" --- dvhtool-1.0.1.orig/dvhlib.c +++ dvhtool-1.0.1/dvhlib.c @@ -325,8 +327,10 @@ if (res == -1) die("Couldn't stat source file"); - /* XXX pad to blocksize? */ - size = vh->vh_pt[8].pt_nblks * blksize - istat.st_size; + /* calculate free blocks in vh */ + size = vh->vh_pt[8].pt_nblks /* total vh size */ + - ( vh->vh_pt[8].pt_firstlbn + 4 ) /* reserved area */ + - (( istat.st_size + blksize - 1 ) / blksize ); /* pad to blocksize */ /* * Are we replacing an existing file, check for enough space and free * entry in volume header @@ -336,16 +340,15 @@ /* It's an existing file, delete it. */ memset(vd->vd_name, 0, VDNAMESIZE); vd->vd_nbytes = 0; - break; } if ( vd->vd_nbytes ) { - size -= vd->vd_nbytes; + size -= (vd->vd_nbytes + blksize - 1 ) / blksize; /* pad to blocksize */ num++; } vd++; } - if ( num == NVDIR ) + if ( num == NVDIR ) die("No more free entries in volume header"); if ( size <= 0 ) die("Not enough space left in volume header"); @@ -403,7 +406,7 @@ die("Short write"); } } - dest += (vd->vd_nbytes + 511) / 512; /* XXX Blocksize */ + dest += (vd->vd_nbytes + blksize - 1) / blksize; vd++; } --xgyAXRrhYN0wYx8y-- From owner-linux-mips@oss.sgi.com Fri Oct 5 20:12:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f963C0B29567 for linux-mips-outgoing; Fri, 5 Oct 2001 20:12:00 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f963BuD29564 for ; Fri, 5 Oct 2001 20:11:56 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 6B2E8590AF; Fri, 5 Oct 2001 19:10:13 -0400 (EDT) Message-ID: <021601c14e14$b6bd8270$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Jun Sun" , "James Simmons" Cc: , References: <3BBE1C99.8DFA3611@mvista.com> Subject: Re: DDB5074 Date: Fri, 5 Oct 2001 23:12:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 794 Lines: 33 I don't anticipate needing 5074 support. I do need 5477 though. Regards, Brad ----- Original Message ----- From: "Jun Sun" To: "James Simmons" Cc: "Ralf Baechle" ; ; Sent: Friday, October 05, 2001 4:48 PM Subject: Re: DDB5074 > James Simmons wrote: > > > > > Is there still somebody who takes care of the DDB 5074 board or has any > > > interest in keeping up support for it otherwise? > > > > I believe Brad LaRonde was working on those boards. > > AFAIK, Brad is only working on rockhopper, a variant of DDB5477. We will keep > DDB5476 and DDB5477(and rockhopper). If nobody is interested in DDB5074, it > might be a good time to get rid of it. > > Brad, speak up! > > Jun > From owner-linux-mips@oss.sgi.com Sat Oct 6 10:31:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96HVtT19738 for linux-mips-outgoing; Sat, 6 Oct 2001 10:31:55 -0700 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96HVsD19735 for ; Sat, 6 Oct 2001 10:31:54 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id KAA03510; Sat, 6 Oct 2001 10:23:02 -0700 Date: Sat, 6 Oct 2001 10:23:02 -0700 From: Jun Sun To: linux-mips@oss.sgi.com Subject: MIPS PC - anyone? Message-ID: <20011006102302.B3492@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 367 Lines: 10 Does anybody know if there is such a "MIPS PC" machine? Essentially I am looking for a machine with MIPS CPU and PC peripherals (such as SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). It would be really nice to have such a box. If it is massively produced, the price should be cheaper than i386 PCs because MIPS CPU price is much cheaper. Jun From owner-linux-mips@oss.sgi.com Sat Oct 6 10:36:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96Hav819862 for linux-mips-outgoing; Sat, 6 Oct 2001 10:36:57 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96HatD19856 for ; Sat, 6 Oct 2001 10:36:56 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 2BDB0125CB; Sat, 6 Oct 2001 10:36:54 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 7D643EBA5; Sat, 6 Oct 2001 10:36:54 -0700 (PDT) Date: Sat, 6 Oct 2001 10:36:54 -0700 From: "H . J . Lu" To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? Message-ID: <20011006103654.B2195@lucon.org> References: <20011006102302.B3492@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: <20011006102302.B3492@mvista.com>; from jsun@mvista.com on Sat, Oct 06, 2001 at 10:23:02AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 648 Lines: 17 On Sat, Oct 06, 2001 at 10:23:02AM -0700, Jun Sun wrote: > > Does anybody know if there is such a "MIPS PC" machine? Essentially > I am looking for a machine with MIPS CPU and PC peripherals (such as > SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). > > It would be really nice to have such a box. If it is massively produced, > the price should be cheaper than i386 PCs because MIPS CPU price is > much cheaper. I doubt that. Can you tell me how much 1GHz MIPS CPU might be cost? My guess is it will be more expensive than x86. On the other hand, 100MHz MIPS may be much cheaper than similar x86, if it is still made. H.J. From owner-linux-mips@oss.sgi.com Sat Oct 6 10:46:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96HkE320132 for linux-mips-outgoing; Sat, 6 Oct 2001 10:46:14 -0700 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96HkCD20129 for ; Sat, 6 Oct 2001 10:46:12 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id KAA03521; Sat, 6 Oct 2001 10:37:18 -0700 Date: Sat, 6 Oct 2001 10:37:18 -0700 From: Jun Sun To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? Message-ID: <20011006103718.C3492@mvista.com> References: <20011006102302.B3492@mvista.com> <20011006103654.B2195@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011006103654.B2195@lucon.org>; from hjl@lucon.org on Sat, Oct 06, 2001 at 10:36:54AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 959 Lines: 26 On Sat, Oct 06, 2001 at 10:36:54AM -0700, H . J . Lu wrote: > On Sat, Oct 06, 2001 at 10:23:02AM -0700, Jun Sun wrote: > > > > Does anybody know if there is such a "MIPS PC" machine? Essentially > > I am looking for a machine with MIPS CPU and PC peripherals (such as > > SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). > > > > It would be really nice to have such a box. If it is massively produced, > > the price should be cheaper than i386 PCs because MIPS CPU price is > > much cheaper. > > I doubt that. By basic premises of RISC CPU over CISC CPU... > Can you tell me how much 1GHz MIPS CPU might be cost? > My guess is it will be more expensive than x86. On the other hand, > 100MHz MIPS may be much cheaper than similar x86, if it is still > made. > Don't know about 1Ghz MIPS CPUs. I know some 200-300 MHz ones are selling less than $20. Imagine how much it would be if you are sell them in the volumn of i386 PCs. Jun From owner-linux-mips@oss.sgi.com Sat Oct 6 11:01:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f96I1Qt20774 for linux-mips-outgoing; Sat, 6 Oct 2001 11:01:26 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f96I1ND20771 for ; Sat, 6 Oct 2001 11:01:23 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (SGI-8.9.3/8.9.3) with ESMTP id UAA23794 for ; Sat, 6 Oct 2001 20:01:16 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.32 #1 (Debian)) id 15pvlE-0007IQ-00 for ; Sat, 06 Oct 2001 20:01:16 +0200 Date: Sat, 6 Oct 2001 20:01:16 +0200 To: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? Message-ID: <20011006200116.A30443@rembrandt.csv.ica.uni-stuttgart.de> References: <20011006102302.B3492@mvista.com> <20011006103654.B2195@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011006103654.B2195@lucon.org> User-Agent: Mutt/1.3.20i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 911 Lines: 25 H . J . Lu wrote: > On Sat, Oct 06, 2001 at 10:23:02AM -0700, Jun Sun wrote: > > > > Does anybody know if there is such a "MIPS PC" machine? Essentially > > I am looking for a machine with MIPS CPU and PC peripherals (such as > > SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). I don't know, but I doubt it exists. Main problem would be developing an appropriate chipset (different processor bus, maybe big endian, maybe 64bit). > > It would be really nice to have such a box. If it is massively produced, > > the price should be cheaper than i386 PCs because MIPS CPU price is > > much cheaper. Nearly every CPU other than x86 would be cheaper in mass production. Unfortunately, mass production seems not to happen. > I doubt that. Can you tell me how much 1GHz MIPS CPU might be cost? > My guess is it will be more expensive than x86. You might ask e.g. Sibyte about it. :-) Thiemo From owner-linux-mips@oss.sgi.com Sat Oct 6 18:32:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f971WXk03221 for linux-mips-outgoing; Sat, 6 Oct 2001 18:32:33 -0700 Received: from dea.linux-mips.net (a1as06-p182.stg.tli.de [195.252.187.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f971WTD03217 for ; Sat, 6 Oct 2001 18:32:30 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f971WJ711081; Sun, 7 Oct 2001 03:32:19 +0200 Date: Sun, 7 Oct 2001 03:32:19 +0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? Message-ID: <20011007033219.A4228@dea.linux-mips.net> References: <20011006102302.B3492@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: <20011006102302.B3492@mvista.com>; from jsun@mvista.com on Sat, Oct 06, 2001 at 10:23:02AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 641 Lines: 17 On Sat, Oct 06, 2001 at 10:23:02AM -0700, Jun Sun wrote: > Does anybody know if there is such a "MIPS PC" machine? Essentially > I am looking for a machine with MIPS CPU and PC peripherals (such as > SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). SNI RM200C. Just a bit older ... > It would be really nice to have such a box. If it is massively produced, > the price should be cheaper than i386 PCs because MIPS CPU price is > much cheaper. The CPU may be cheaper but at least in the past when we last looked at such issues the chipset more than compensated for the CPU price. This may have changed, dunno. Ralf From owner-linux-mips@oss.sgi.com Sat Oct 6 18:35:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f971ZRT03321 for linux-mips-outgoing; Sat, 6 Oct 2001 18:35:27 -0700 Received: from dea.linux-mips.net (a1as06-p182.stg.tli.de [195.252.187.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f971ZND03317 for ; Sat, 6 Oct 2001 18:35:24 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f971ZDH11095; Sun, 7 Oct 2001 03:35:13 +0200 Date: Sun, 7 Oct 2001 03:35:13 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? Message-ID: <20011007033513.B4228@dea.linux-mips.net> References: <20011006102302.B3492@mvista.com> <20011006103654.B2195@lucon.org> <20011006200116.A30443@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011006200116.A30443@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Sat, Oct 06, 2001 at 08:01:16PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 708 Lines: 19 On Sat, Oct 06, 2001 at 08:01:16PM +0200, Thiemo Seufer wrote: > > > It would be really nice to have such a box. If it is massively produced, > > > the price should be cheaper than i386 PCs because MIPS CPU price is > > > much cheaper. > > Nearly every CPU other than x86 would be cheaper in mass production. > Unfortunately, mass production seems not to happen. > > > I doubt that. Can you tell me how much 1GHz MIPS CPU might be cost? > > My guess is it will be more expensive than x86. > > You might ask e.g. Sibyte about it. :-) Well, Sibyte doesn't give you one but two CPUs on the die of thei SOC. Details see the various online resources. Btw, not yet shipping but Linux supported :-) Ralf From owner-linux-mips@oss.sgi.com Sat Oct 6 18:39:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f971deQ03445 for linux-mips-outgoing; Sat, 6 Oct 2001 18:39:40 -0700 Received: from dea.linux-mips.net (a1as06-p182.stg.tli.de [195.252.187.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f971dbD03442 for ; Sat, 6 Oct 2001 18:39:37 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f971dAc11109; Sun, 7 Oct 2001 03:39:10 +0200 Date: Sun, 7 Oct 2001 03:39:10 +0200 From: Ralf Baechle To: Jun Sun Cc: jim@jtan.com, "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: test machines; illegal instructions Message-ID: <20011007033910.C4228@dea.linux-mips.net> References: <20010926221223.A17628@neurosis.mit.edu> <20010926202610.B7962@lucon.org> <20011004011632.A19472@neurosis.mit.edu> <3BBDF25F.1A0F2283@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: <3BBDF25F.1A0F2283@mvista.com>; from jsun@mvista.com on Fri, Oct 05, 2001 at 10:48:15AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 640 Lines: 16 On Fri, Oct 05, 2001 at 10:48:15AM -0700, Jun Sun wrote: > If your cpu does not have ll/sc instruction, you might be suffering the famous > sysmips() problem. The latest kernel should get you going. > > There is also FPU emulation bug which may cause this problem, but that only > happens on heavy context switches and FPU usages. I've checked in a major bundle of FPU emu fixes last week. The kernel fp code should now produce accurate results and handle exceptions and the Flush to Zero bit as per spec. I have a load more fp fixes pending which I'll checking as soon as I'm absolutely convinced they'll do the right thing. Ralf From owner-linux-mips@oss.sgi.com Sat Oct 6 19:35:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f972Zw704525 for linux-mips-outgoing; Sat, 6 Oct 2001 19:35:58 -0700 Received: from straylight.cyberhqz.com (root@h24-76-98-250.vc.shawcable.net [24.76.98.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f972ZqD04520 for ; Sat, 6 Oct 2001 19:35:52 -0700 Received: (from rmurray@localhost) by straylight.cyberhqz.com (8.9.3/8.9.3/Debian 8.9.3-21) id TAA18389 for linux-mips@oss.sgi.com; Sat, 6 Oct 2001 19:35:51 -0700 From: Ryan Murray Date: Sat, 6 Oct 2001 19:35:51 -0700 To: linux-mips@oss.sgi.com Subject: bug in binutils 2.11.90.0.31 strip ? Message-ID: <20011006193551.A17821@cyberhqz.com> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2037 Lines: 60 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm running into a problem while building gcc 3.0 from 010922. The built libobjc.so.1.0.0 is fine until stripped: before strip: libobjc.so.1.0.0: file format elf32-tradlittlemips Program Header: 0x70000000 off 0x000000b4 vaddr 0x000000b4 paddr 0x000000b4 align 2**2 filesz 0x00000018 memsz 0x00000018 flags r-- LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x0001a440 memsz 0x0001a440 flags r-x LOAD off 0x0001a440 vaddr 0x0005a440 paddr 0x0005a440 align 2**12 filesz 0x00000b30 memsz 0x00000b90 flags rw- DYNAMIC off 0x000000cc vaddr 0x000000cc paddr 0x000000cc align 2**2 filesz 0x00003621 memsz 0x00003621 flags rwx after strip: libobjc.so.1.0.0: file format elf32-tradlittlemips Program Header: 0x70000000 off 0x000000b4 vaddr 0x000000b4 paddr 0x000000b4 align 2**2 filesz 0x00000018 memsz 0x00000018 flags r-- LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4 filesz 0x0001a440 memsz 0x0001a440 flags r-x LOAD off 0x0001a440 vaddr 0x0005a440 paddr 0x0005a440 align 2**4 filesz 0x00000b30 memsz 0x00000b90 flags rw- DYNAMIC off 0x000000cc vaddr 0x000000cc paddr 0x000000cc align 2**2 filesz 0x00003621 memsz 0x00003621 flags rwx The change in alignment in the newly-stripped library makes it unusable. This happens on both big endian and little endian targets. --=20 Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own. --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7v7+GN2Dbz/1mRasRArVgAKDvkVf3VEp50QenmPYeIRWijK38jgCePoUK lkRJqrswQEp/PhiqFgrnzV4= =ikjl -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-linux-mips@oss.sgi.com Sun Oct 7 06:15:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97DF3e18856 for linux-mips-outgoing; Sun, 7 Oct 2001 06:15:03 -0700 Received: from dea.linux-mips.net (a1as11-p49.stg.tli.de [195.252.190.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97DExD18838 for ; Sun, 7 Oct 2001 06:14:59 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f97DE9a01804; Sun, 7 Oct 2001 15:14:09 +0200 Date: Sun, 7 Oct 2001 15:14:09 +0200 From: Ralf Baechle To: "Bradley D. LaRonde" Cc: Jun Sun , James Simmons , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: DDB5074 Message-ID: <20011007151409.A1797@dea.linux-mips.net> References: <3BBE1C99.8DFA3611@mvista.com> <021601c14e14$b6bd8270$3501010a@ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <021601c14e14$b6bd8270$3501010a@ltc.com>; from brad@ltc.com on Fri, Oct 05, 2001 at 11:12:21PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 344 Lines: 9 On Fri, Oct 05, 2001 at 11:12:21PM -0400, Bradley D. LaRonde wrote: > I don't anticipate needing 5074 support. I do need 5477 though. Ok, so I'll considered 5074 a candidate for removel in 2.5. It's just an evaluation board, so I don't expect anybody to care about it any longer thus no point in any long time effort to support it. Ralf From owner-linux-mips@oss.sgi.com Sun Oct 7 09:20:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97GKat21467 for linux-mips-outgoing; Sun, 7 Oct 2001 09:20:36 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97GKYD21463 for ; Sun, 7 Oct 2001 09:20:34 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA27028; Sun, 7 Oct 2001 09:20:24 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id JAA12728; Sun, 7 Oct 2001 09:20:24 -0700 (PDT) Received: from mips.com (coppccl [172.17.27.2]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f97GKNa06701; Sun, 7 Oct 2001 18:20:24 +0200 (MEST) Message-ID: <3BC08164.D7332834@mips.com> Date: Sun, 07 Oct 2001 18:23:00 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? References: <20011006102302.B3492@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 824 Lines: 22 What about a Malta board, it got a PC like structure with ATX form factor, a Intel PIIX4E South Bridge (containing interrupt controller, RTC and USB), a Super IO devices (with support for keyboard, 2 UARTs, floppy disk, parallel port and mouse), AMD ethernet controller, Audio controller, Primary and Secondary IDE, 4 PCI slots. I probably forgot something, but the board is more or less designed to be a "MIPS PC". /Carsten Jun Sun wrote: > Does anybody know if there is such a "MIPS PC" machine? Essentially > I am looking for a machine with MIPS CPU and PC peripherals (such as > SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). > > It would be really nice to have such a box. If it is massively produced, > the price should be cheaper than i386 PCs because MIPS CPU price is > much cheaper. > > Jun From owner-linux-mips@oss.sgi.com Sun Oct 7 09:39:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97Gd9Q21765 for linux-mips-outgoing; Sun, 7 Oct 2001 09:39:09 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97Gd6D21761 for ; Sun, 7 Oct 2001 09:39:06 -0700 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15qGx9-0007jq-00; Sun, 7 Oct 2001 18:38:59 +0200 Received: from pd9590fea.dip.t-dialin.net ([217.89.15.234] helo=thalreit.de) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 15qGx9-0004Yb-00; Sun, 7 Oct 2001 18:38:59 +0200 Message-ID: <3BC08523.4A23F7E8@thalreit.de> Date: Sun, 07 Oct 2001 18:38:59 +0200 From: Volker Jahns Organization: Thalreit/DE X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? References: <20011006102302.B3492@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 621 Lines: 17 Jun Sun wrote: > > Does anybody know if there is such a "MIPS PC" machine? Essentially > I am looking for a machine with MIPS CPU and PC peripherals (such as > SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). > > It would be really nice to have such a box. If it is massively produced, > the price should be cheaper than i386 PCs because MIPS CPU price is > much cheaper. > > Jun Why don't you use the SONY playstation 2 w/ its LINUX kit? The costs are less and the graphics performance is greater than any Intel based PC I am aware of. -- Volker Jahns, Volker.Jahns@thalreit.de, http://thalreit.de From owner-linux-mips@oss.sgi.com Sun Oct 7 10:06:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97H6Sf22242 for linux-mips-outgoing; Sun, 7 Oct 2001 10:06:28 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97H6QD22239 for ; Sun, 7 Oct 2001 10:06:26 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f97H6LE0004312; Sun, 7 Oct 2001 10:06:21 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f97H6Lp0004308; Sun, 7 Oct 2001 10:06:21 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Sun, 7 Oct 2001 10:06:20 -0700 (PDT) From: James Simmons To: Jun Sun cc: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? In-Reply-To: <20011006102302.B3492@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 428 Lines: 12 > Does anybody know if there is such a "MIPS PC" machine? Essentially > I am looking for a machine with MIPS CPU and PC peripherals (such as > SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). > > It would be really nice to have such a box. If it is massively produced, > the price should be cheaper than i386 PCs because MIPS CPU price is > much cheaper. I have IT 8172G board. It basically is a MIPS PC. From owner-linux-mips@oss.sgi.com Sun Oct 7 10:12:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97HCqF22369 for linux-mips-outgoing; Sun, 7 Oct 2001 10:12:52 -0700 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97HCiD22365; Sun, 7 Oct 2001 10:12:44 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id KAA11810; Sun, 7 Oct 2001 10:03:47 -0700 Date: Sun, 7 Oct 2001 10:03:47 -0700 From: Jun Sun To: Ralf Baechle Cc: jim@jtan.com, "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: test machines; illegal instructions Message-ID: <20011007100347.A11796@mvista.com> References: <20010926221223.A17628@neurosis.mit.edu> <20010926202610.B7962@lucon.org> <20011004011632.A19472@neurosis.mit.edu> <3BBDF25F.1A0F2283@mvista.com> <20011007033910.C4228@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011007033910.C4228@dea.linux-mips.net>; from ralf@oss.sgi.com on Sun, Oct 07, 2001 at 03:39:10AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1840 Lines: 81 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Oct 07, 2001 at 03:39:10AM +0200, Ralf Baechle wrote: > On Fri, Oct 05, 2001 at 10:48:15AM -0700, Jun Sun wrote: > > > If your cpu does not have ll/sc instruction, you might be suffering the famous > > sysmips() problem. The latest kernel should get you going. > > > > There is also FPU emulation bug which may cause this problem, but that only > > happens on heavy context switches and FPU usages. > > I've checked in a major bundle of FPU emu fixes last week. The kernel > fp code should now produce accurate results and handle exceptions and > the Flush to Zero bit as per spec. > This particular problem seems still there. Anybody can try the following test program on a CPU *without* fpu. Jun --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kfpe_chk3.c" /* mipel-linux-gcc -O -o kfpe_chk3 kfpe_chk3.c */ #include #include #include #include double count; int dummy; struct itimerval ival; int icnt=0; static void alarm_sig_handler(int signum) { int i,j; double d; if( icnt++ > 500 ){ icnt = 0; /* printf("count = %f\n", count);*/ } for( i = 0, d = 0.0; d < 1.0; i++, d+=0.1 ){ count = d; } setitimer(ITIMER_REAL, &ival, NULL); // alarm(1); } int main() { int i,j; double d; signal(SIGALRM, alarm_sig_handler); ival.it_interval.tv_sec = 0; ival.it_interval.tv_usec = 0; ival.it_value.tv_sec = 0; ival.it_value.tv_usec = 10000; setitimer(ITIMER_REAL, &ival, NULL); // alarm(1); for(;;){ for( i = 0, d = 0.0; d < 10000.0; i++, d+=0.1 ){ count = d; } signal(SIGALRM, alarm_sig_handler); } return 0; } --0F1p//8PRICkK4MW-- From owner-linux-mips@oss.sgi.com Sun Oct 7 10:13:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97HDqN22440 for linux-mips-outgoing; Sun, 7 Oct 2001 10:13:52 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97HDpD22437 for ; Sun, 7 Oct 2001 10:13:51 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f97HDkE0004565; Sun, 7 Oct 2001 10:13:46 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f97HDkn8004561; Sun, 7 Oct 2001 10:13:46 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Sun, 7 Oct 2001 10:13:46 -0700 (PDT) From: James Simmons To: Volker Jahns cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? In-Reply-To: <3BC08523.4A23F7E8@thalreit.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 274 Lines: 8 > Why don't you use the SONY playstation 2 w/ its LINUX kit? The costs are > less and the graphics performance is greater than any Intel based PC I > am aware of. The SONY stuff is 2.2.X based. Their is work going on for 2.4.X support but it is not stable at the moment. From owner-linux-mips@oss.sgi.com Sun Oct 7 10:16:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97HGlE22544 for linux-mips-outgoing; Sun, 7 Oct 2001 10:16:47 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97HGjD22541 for ; Sun, 7 Oct 2001 10:16:46 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id KAA27273; Sun, 7 Oct 2001 10:16:34 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA13145; Sun, 7 Oct 2001 10:16:32 -0700 (PDT) Message-ID: <000f01c14f54$7b1e1220$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "James Simmons" , "Volker Jahns" Cc: "Jun Sun" , References: Subject: Re: MIPS PC - anyone? Date: Sun, 7 Oct 2001 19:21:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 488 Lines: 14 > > Why don't you use the SONY playstation 2 w/ its LINUX kit? The costs are > > less and the graphics performance is greater than any Intel based PC I > > am aware of. > > The SONY stuff is 2.2.X based. Their is work going on for 2.4.X support > but it is not stable at the moment. 2.2 or 2.4, is the necessary configuration in fact generally available? Last I heard, which was some months ago, it required a PS2 configuration that was only available in Japan. Kevin K. From owner-linux-mips@oss.sgi.com Sun Oct 7 10:20:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97HKeI22641 for linux-mips-outgoing; Sun, 7 Oct 2001 10:20:40 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97HKcD22637 for ; Sun, 7 Oct 2001 10:20:38 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f97HKXE0004849; Sun, 7 Oct 2001 10:20:33 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f97HKXhR004845; Sun, 7 Oct 2001 10:20:33 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Sun, 7 Oct 2001 10:20:33 -0700 (PDT) From: James Simmons To: "Kevin D. Kissell" cc: Volker Jahns , Jun Sun , linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? In-Reply-To: <000f01c14f54$7b1e1220$0deca8c0@Ulysses> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 352 Lines: 10 > 2.2 or 2.4, is the necessary configuration in fact generally > available? Last I heard, which was some months ago, > it required a PS2 configuration that was only available > in Japan. This is true. Well this month they made available another PS2 configuration in germany. Luckly the company I work for has people going back and forth to Japan. From owner-linux-mips@oss.sgi.com Sun Oct 7 11:20:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97IKIP23658 for linux-mips-outgoing; Sun, 7 Oct 2001 11:20:18 -0700 Received: from serio.al.rim.or.jp (serio.al.rim.or.jp [202.247.191.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97IKGD23655 for ; Sun, 7 Oct 2001 11:20:16 -0700 Received: from mail2.rim.or.jp by serio.al.rim.or.jp (3.7W/HMX-13) id DAA00320 for ; Mon, 8 Oct 2001 03:20:14 +0900 (JST) Received: from speedwin (speed.galaxies.jp [211.8.151.62]) by mail2.rim.or.jp (8.9.3/3.7W) id DAA12233 for ; Mon, 8 Oct 2001 03:20:13 +0900 (JST) From: "Yoshi-K" To: Subject: RE: MIPS PC - anyone? Date: Mon, 8 Oct 2001 03:20:13 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2505.0000 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 151 Lines: 11 Hello. My Internet server is PS2. --> http://galaxies.jp/ ------------------------- Yoshikatsu Kida E-Mail: yoshi@galaxies.jp http://galaxies.jp/ From owner-linux-mips@oss.sgi.com Sun Oct 7 11:56:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f97Iunw24496 for linux-mips-outgoing; Sun, 7 Oct 2001 11:56:49 -0700 Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f97IukD24487 for ; Sun, 7 Oct 2001 11:56:47 -0700 Received: from smtp.web.de (smtp01.dlan.cinetic.de [172.20.0.189]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id f97Iuau24499; Sun, 7 Oct 2001 20:56:36 +0200 Received: from intel by smtp.web.de with smtp (freemail 4.2.2.3 #20) id m15qJ6J-007qBCC; Sun, 7 Oct 2001 20:56 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Harald Koerfgen Organization: none to speak of To: Carsten Langgaard Subject: Re: MIPS PC - anyone? Date: Sun, 7 Oct 2001 20:57:38 +0200 X-Mailer: KMail [version 1.2] Cc: linux-mips@oss.sgi.com References: <20011006102302.B3492@mvista.com> <3BC08164.D7332834@mips.com> In-Reply-To: <3BC08164.D7332834@mips.com> MIME-Version: 1.0 Message-Id: <01100720573800.00458@intel> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 272 Lines: 10 On Sunday 07 October 2001 18:23, Carsten Langgaard wrote: > What about a Malta board, it got a PC like structure with ATX form factor, [...] > I probably forgot something, but the board is more or less designed to be a > "MIPS PC". Fine, but how much? Greetings, Harald From owner-linux-mips@oss.sgi.com Sun Oct 7 21:53:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f984rWI04398 for linux-mips-outgoing; Sun, 7 Oct 2001 21:53:32 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f984rTD04394 for ; Sun, 7 Oct 2001 21:53:29 -0700 Message-Id: <200110080453.f984rTD04394@oss.sgi.com> Received: (qmail 18755 invoked from network); 8 Oct 2001 04:47:37 -0000 Received: from unknown (HELO heart1) (159.226.39.162) by 159.226.39.4 with SMTP; 8 Oct 2001 04:47:37 -0000 Date: Mon, 8 Oct 2001 12:52:18 +0800 From: Zhang Fuxin To: Carsten Langgaard CC: "linux-mips@oss.sgi.com" Subject: Re: Re: MIPS PC - anyone? X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f984rTD04395 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1047 Lines: 31 hi,Carsten LanggaardŁŹ Algor P6032 board has similiar configuration,but it costs more than $3,000:(. ÔÚ 2001-10-07 18:23:00 you wroteŁş >What about a Malta board, it got a PC like structure with ATX form factor, a >Intel PIIX4E South Bridge (containing interrupt controller, RTC and USB), a >Super IO devices (with support for keyboard, 2 UARTs, floppy disk, parallel >port and mouse), AMD ethernet controller, Audio controller, Primary and >Secondary IDE, 4 PCI slots. >I probably forgot something, but the board is more or less designed to be a >"MIPS PC". > >/Carsten > >Jun Sun wrote: > >> Does anybody know if there is such a "MIPS PC" machine? Essentially >> I am looking for a machine with MIPS CPU and PC peripherals (such as >> SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). >> >> It would be really nice to have such a box. If it is massively produced, >> the price should be cheaper than i386 PCs because MIPS CPU price is >> much cheaper. >> >> Jun Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Oct 8 00:51:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f987p6v08289 for linux-mips-outgoing; Mon, 8 Oct 2001 00:51:06 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f987p4D08286 for ; Mon, 8 Oct 2001 00:51:04 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA01036; Mon, 8 Oct 2001 00:50:54 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA20012; Mon, 8 Oct 2001 00:50:53 -0700 (PDT) Message-ID: <016801c14fce$a10e22c0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "James Simmons" Cc: "Volker Jahns" , "Jun Sun" , References: Subject: Re: MIPS PC - anyone? Date: Mon, 8 Oct 2001 09:55:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 736 Lines: 19 > > 2.2 or 2.4, is the necessary configuration in fact generally > > available? Last I heard, which was some months ago, > > it required a PS2 configuration that was only available > > in Japan. > > This is true. Well this month they made available another PS2 > configuration in germany. Luckly the company I work for has people going > back and forth to Japan. I'm based in France, but should be in Germany this week for a conference. If there's a PS2 available there that is capable of running the Linux port (and capable of booting up in something other than German and Japanese!), could someone please let me know the specific PS2 model to look for, and how I could get my hands on the Linux release??? Kevin K. From owner-linux-mips@oss.sgi.com Mon Oct 8 01:04:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9884u608627 for linux-mips-outgoing; Mon, 8 Oct 2001 01:04:56 -0700 Received: from shogun.webninja.com (root@[64.209.141.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9884sD08623 for ; Mon, 8 Oct 2001 01:04:54 -0700 Received: from webninja.com (we-24-160-44-161.we.mediaone.net [24.160.44.161]) (authenticated (0 bits)) by shogun.webninja.com (8.11.3/8.11.2/Debian 8.11.2-1) with ESMTP id f988pAA24832 for ; Mon, 8 Oct 2001 01:51:10 -0700 Message-ID: <3BC15DD8.10002@webninja.com> Date: Mon, 08 Oct 2001 01:03:36 -0700 From: Caleb Shay User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us, gd MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? References: <016801c14fce$a10e22c0$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 692 Lines: 23 I actually have the Japanese model that works with the Linux release for the PS2. Unfortunately, I won't be in Japan again for another year and they won't ship overseas. If anyone knows of a way to get the PS2 Linux release in the US, please let me know. Caleb Shay caleb@webninja.com Kevin D. Kissell wrote: >>>2.2 or 2.4, is the necessary configuration in fact generally >>>available? Last I heard, which was some months ago, >>>it required a PS2 configuration that was only available >>>in Japan. >>> >>This is true. Well this month they made available another PS2 >>configuration in germany. Luckly the company I work for has people going >>back and forth to Japan. >> > From owner-linux-mips@oss.sgi.com Mon Oct 8 01:22:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f988MZB08891 for linux-mips-outgoing; Mon, 8 Oct 2001 01:22:35 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f988MWD08888 for ; Mon, 8 Oct 2001 01:22:32 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA01230; Mon, 8 Oct 2001 01:22:22 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA20306; Mon, 8 Oct 2001 01:22:21 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f988MKa21165; Mon, 8 Oct 2001 10:22:22 +0200 (MEST) Message-ID: <3BC1623C.ADAE211@mips.com> Date: Mon, 08 Oct 2001 10:22:20 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Harald Koerfgen CC: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? References: <20011006102302.B3492@mvista.com> <3BC08164.D7332834@mips.com> <01100720573800.00458@intel> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 712 Lines: 26 Harald Koerfgen wrote: > On Sunday 07 October 2001 18:23, Carsten Langgaard wrote: > > What about a Malta board, it got a PC like structure with ATX form factor, > [...] > > I probably forgot something, but the board is more or less designed to be a > > "MIPS PC". > > Fine, but how much? I'm afraid we are not in the business of selling PCs, so the price is about $3000. > > Greetings, > Harald -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Oct 8 05:06:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98C6it12840 for linux-mips-outgoing; Mon, 8 Oct 2001 05:06:44 -0700 Received: from mout04.kundenserver.de (mout04.kundenserver.de [195.20.224.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98C6eD12834 for ; Mon, 8 Oct 2001 05:06:41 -0700 Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by mout04.kundenserver.de with esmtp (Exim 2.12 #2) id 15qZB7-0005NQ-00; Mon, 8 Oct 2001 14:06:37 +0200 Received: from pd9590fea.dip.t-dialin.net ([217.89.15.234] helo=pegasus.thalreit) by mrvdom00.schlund.de with esmtp (Exim 2.12 #2) id 15qZB7-0005IN-00; Mon, 8 Oct 2001 14:06:37 +0200 Received: from thalreit.de (localhost.thalreit [127.0.0.1]) by pegasus.thalreit (8.11.3/8.11.3) with SMTP id f98C6ZH38300; Mon, 8 Oct 2001 14:06:35 +0200 (CEST) (envelope-from volker@thalreit.de) Received: from 194.59.120.11 (proxying for 194.59.113.24, 194.59.120.104) (SquirrelMail authenticated user volker) by thalreit.dyndns.org with HTTP; Mon, 8 Oct 2001 14:06:36 +0200 (CEST) Message-ID: <62824.194.59.120.11.1002542796.squirrel@thalreit.dyndns.org> Date: Mon, 8 Oct 2001 14:06:36 +0200 (CEST) Subject: Re: MIPS PC - anyone? From: To: caleb@webninja.com In-Reply-To: <3BC15DD8.10002@webninja.com> References: <3BC15DD8.10002@webninja.com> Cc: linux-mips@oss.sgi.com X-Mailer: SquirrelMail (version 1.0.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 934 Lines: 27 > I actually have the Japanese model that works with the Linux release > for > the PS2. Unfortunately, I won't be in Japan again for another year > and they won't ship overseas. If anyone knows of a way to get the PS2 > Linux release in the US, please let me know. It seems SONY will release the LINUX kit in Germany soon (they claim it is going to happen this autumn). They say it will be available at SONY's online shop only. Source of information is http://www.golem.de . > > Caleb Shay > caleb@webninja.com > > Kevin D. Kissell wrote: > >>>>2.2 or 2.4, is the necessary configuration in fact generally >>>>available? Last I heard, which was some months ago, >>>>it required a PS2 configuration that was only available >>>>in Japan. >>>> >>>This is true. Well this month they made available another PS2 >>>configuration in germany. Luckly the company I work for has people >>>going back and forth to Japan. >>> >> From owner-linux-mips@oss.sgi.com Mon Oct 8 07:09:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98E9jQ15270 for linux-mips-outgoing; Mon, 8 Oct 2001 07:09:45 -0700 Received: from mercury.shreve.net (IDENT:root@mercury.shreve.net [208.206.76.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98E9hD15267 for ; Mon, 8 Oct 2001 07:09:43 -0700 Received: from mercury.shreve.net (IDENT:signal@mercury.shreve.net [208.206.76.23]) by mercury.shreve.net (8.11.6/8.11.6) with ESMTP id f98E9gs10661 for ; Mon, 8 Oct 2001 09:09:42 -0500 Date: Mon, 8 Oct 2001 09:09:42 -0500 (CDT) From: Brian To: Subject: Password recovery on IRIX box Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 469 Lines: 15 I have an origin 200 I have been wanting to run linux on, its been sitting up for a while. Before I wipe out and install linux, I need to get in there to get some stuff of the drives. But I do not know the root password. Can anyone direct me to password recovery procedures for IRIX? Brian ----------------------------------------------- Brian Feeny, CCIE #8036 e: signal@shreve.net Network Engineer p: 318.222.2638x109 ShreveNet Inc. f: 318.221.6612 From owner-linux-mips@oss.sgi.com Mon Oct 8 07:23:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98ENZj16060 for linux-mips-outgoing; Mon, 8 Oct 2001 07:23:35 -0700 Received: from fenris.scrooge.dk (213.237.12.36.adsl.ynoe.worldonline.dk [213.237.12.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98ENWD16057 for ; Mon, 8 Oct 2001 07:23:32 -0700 Received: from athlon-800 (athlon-pc [10.0.0.2]) by fenris.scrooge.dk (8.11.5/8.8.7) with ESMTP id f98ENRX32088; Mon, 8 Oct 2001 16:23:27 +0200 From: "Soeren Laursen" To: , Brian Date: Mon, 8 Oct 2001 16:24:51 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Password recovery on IRIX box Reply-to: soeren.laursen@scrooge.dk Message-ID: <3BC1D353.1525.17E2AC7@localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 556 Lines: 20 As I remember you have to boot it in single mode. Soeren > I have an origin 200 I have been wanting to run linux on, its been sitting > up for a while. Before I wipe out and install linux, I need to get in > there to get some stuff of the drives. But I do not know the root > password. Can anyone direct me to password recovery procedures for IRIX? > > Brian > > > ----------------------------------------------- > Brian Feeny, CCIE #8036 e: signal@shreve.net > Network Engineer p: 318.222.2638x109 > ShreveNet Inc. f: 318.221.6612 > From owner-linux-mips@oss.sgi.com Mon Oct 8 07:57:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98EvBQ17462 for linux-mips-outgoing; Mon, 8 Oct 2001 07:57:11 -0700 Received: from oxygen.ima.umn.edu (mail.ima.umn.edu [128.101.10.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98Ev7D17459 for ; Mon, 8 Oct 2001 07:57:08 -0700 Received: from pc1.ima.umn.edu (IDENT:root@pc1.ima.umn.edu [128.101.10.80]) by oxygen.ima.umn.edu (8.9.3/8.9.3) with ESMTP id JAA843950; Mon, 8 Oct 2001 09:57:07 -0500 (CDT) From: Kumsup Lee Received: (from klee@localhost) by pc1.ima.umn.edu (8.9.3/8.8.8) id JAA17609; Mon, 8 Oct 2001 09:57:06 -0500 Message-Id: <200110081457.JAA17609@pc1.ima.umn.edu> Subject: Re: Password recovery on IRIX box To: soeren.laursen@scrooge.dk Date: Mon, 8 Oct 2001 09:57:06 -0500 (CDT) Cc: linux-mips@oss.sgi.com In-Reply-To: <3BC1D353.1525.17E2AC7@localhost> from "Soeren Laursen" at Oct 08, 2001 04:24:51 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by oxygen.ima.umn.edu id JAA843950 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f98Ev8D17460 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1149 Lines: 37 You still need a root password to get in single user mode. Best way to go around is this. * Mount your root Hard Disk to other SGI or XFS capable linux machine. > > As I remember you have to boot it in single mode. > > Soeren > > > > I have an origin 200 I have been wanting to run linux on, its been sitting > > up for a while. Before I wipe out and install linux, I need to get in > > there to get some stuff of the drives. But I do not know the root > > password. Can anyone direct me to password recovery procedures for IRIX? > > > > Brian > > > > > > ----------------------------------------------- > > Brian Feeny, CCIE #8036 e: signal@shreve.net > > Network Engineer p: 318.222.2638x109 > > ShreveNet Inc. f: 318.221.6612 > > > > > -- ============================================================================= Kumsup Lee (Ŕ̹ݟˇ) System/Network Manager Institute for Mathematics and its Applications, University of Minnesota 400 Lind Hall, 207 Church Street S.E., Minneapolis, MN 55455 USA Tel : 612-624-4353 FAX : 612-626-7370 PAGE : 952-608-0112 klee@ima.umn.edu www.ima.umn.edu/~klee From owner-linux-mips@oss.sgi.com Mon Oct 8 08:03:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98F3YK17808 for linux-mips-outgoing; Mon, 8 Oct 2001 08:03:34 -0700 Received: from thor ([207.246.91.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98F3UD17804 for ; Mon, 8 Oct 2001 08:03:30 -0700 Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12486; Mon, 8 Oct 2001 11:01:33 -0400 Date: Mon, 8 Oct 2001 11:01:33 -0400 From: "J. Scott Kasten" To: Brian cc: Subject: Re: Password recovery on IRIX box In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1314 Lines: 40 I'm saying this from memory, but here is a procedure that would work if you have the Irix install CDs. One of them is bootable. You boot the miniroot from the CD and instead of invoking the installation, you opt to go to a shell prompt. From there you can manually mount the partitions, and have some minimal capability to do things like overwrite the password file, archive a disk to tape, or up a network interface and rcp stuff off if you don't have any other means. I've used this before to manipulate things on a marginally functional system. Other's here may have better short cuts, but this will do it. -- J. Scott Kasten Email: jsk AT tetracon-eng DOT net "Nearly all men can stand adversity, but if you want to test a man's charater, give him power. - A Lincoln" On Mon, 8 Oct 2001, Brian wrote: > > I have an origin 200 I have been wanting to run linux on, its been sitting > up for a while. Before I wipe out and install linux, I need to get in > there to get some stuff of the drives. But I do not know the root > password. Can anyone direct me to password recovery procedures for IRIX? > > Brian > > > ----------------------------------------------- > Brian Feeny, CCIE #8036 e: signal@shreve.net > Network Engineer p: 318.222.2638x109 > ShreveNet Inc. f: 318.221.6612 > > > From owner-linux-mips@oss.sgi.com Mon Oct 8 08:10:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98FABf18256 for linux-mips-outgoing; Mon, 8 Oct 2001 08:10:11 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98FAAD18253 for ; Mon, 8 Oct 2001 08:10:10 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15qc2i-00025t-00; Mon, 08 Oct 2001 17:10:08 +0200 Date: Mon, 8 Oct 2001 17:10:08 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: Password recovery on IRIX box Message-ID: <20011008171008.A733@gandalf.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsk@tetracon-eng.net on Mon, Oct 08, 2001 at 11:01:33AM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 81 Lines: 3 It's in the FAQ: http://www-viz.tamu.edu/~sgi-faq/faq/html/security/ -- Guido From owner-linux-mips@oss.sgi.com Mon Oct 8 10:02:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98H23K21168 for linux-mips-outgoing; Mon, 8 Oct 2001 10:02:03 -0700 Received: from mercury.shreve.net (IDENT:root@mercury.shreve.net [208.206.76.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98H20D21165 for ; Mon, 8 Oct 2001 10:02:00 -0700 Received: from mercury.shreve.net (IDENT:signal@mercury.shreve.net [208.206.76.23]) by mercury.shreve.net (8.11.6/8.11.6) with ESMTP id f98H1oP32205; Mon, 8 Oct 2001 12:01:50 -0500 Date: Mon, 8 Oct 2001 12:01:50 -0500 (CDT) From: Brian To: Soeren Laursen cc: Subject: Re: Password recovery on IRIX box In-Reply-To: <3BC1D353.1525.17E2AC7@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 951 Lines: 36 Thanks loren. Yes I know how to boot single user in some other UNIX varients, but I do not know how to boot into single user on IRIX :/. Brian On Mon, 8 Oct 2001, Soeren Laursen wrote: > As I remember you have to boot it in single mode. > > Soeren > > > > I have an origin 200 I have been wanting to run linux on, its been sitting > > up for a while. Before I wipe out and install linux, I need to get in > > there to get some stuff of the drives. But I do not know the root > > password. Can anyone direct me to password recovery procedures for IRIX? > > > > Brian > > > > > > ----------------------------------------------- > > Brian Feeny, CCIE #8036 e: signal@shreve.net > > Network Engineer p: 318.222.2638x109 > > ShreveNet Inc. f: 318.221.6612 > > > > ----------------------------------------------- Brian Feeny, CCIE #8036 e: signal@shreve.net Network Engineer p: 318.222.2638x109 ShreveNet Inc. f: 318.221.6612 From owner-linux-mips@oss.sgi.com Mon Oct 8 10:07:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98H74m21293 for linux-mips-outgoing; Mon, 8 Oct 2001 10:07:04 -0700 Received: from mercury.shreve.net (IDENT:root@mercury.shreve.net [208.206.76.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98H6xD21288 for ; Mon, 8 Oct 2001 10:06:59 -0700 Received: from mercury.shreve.net (IDENT:signal@mercury.shreve.net [208.206.76.23]) by mercury.shreve.net (8.11.6/8.11.6) with ESMTP id f98H6vP03183; Mon, 8 Oct 2001 12:06:57 -0500 Date: Mon, 8 Oct 2001 12:06:57 -0500 (CDT) From: Brian To: "J. Scott Kasten" cc: Subject: Re: Password recovery on IRIX box In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1704 Lines: 53 that sounds like a good way...........the root partition is usually what? /dev/sda1? /dev/c0d0t0? On Mon, 8 Oct 2001, J. Scott Kasten wrote: > > I'm saying this from memory, but here is a procedure that would work if > you have the Irix install CDs. One of them is bootable. You boot the > miniroot from the CD and instead of invoking the installation, you opt to > go to a shell prompt. From there you can manually mount the partitions, > and have some minimal capability to do things like overwrite the password > file, archive a disk to tape, or up a network interface and rcp stuff off > if you don't have any other means. I've used this before to manipulate > things on a marginally functional system. > > Other's here may have better short cuts, but this will do it. > > -- > > J. Scott Kasten > Email: jsk AT tetracon-eng DOT net > > "Nearly all men can stand adversity, > but if you want to test a man's > charater, give him power. - A Lincoln" > > On Mon, 8 Oct 2001, Brian wrote: > > > > > I have an origin 200 I have been wanting to run linux on, its been sitting > > up for a while. Before I wipe out and install linux, I need to get in > > there to get some stuff of the drives. But I do not know the root > > password. Can anyone direct me to password recovery procedures for IRIX? > > > > Brian > > > > > > ----------------------------------------------- > > Brian Feeny, CCIE #8036 e: signal@shreve.net > > Network Engineer p: 318.222.2638x109 > > ShreveNet Inc. f: 318.221.6612 > > > > > > > ----------------------------------------------- Brian Feeny, CCIE #8036 e: signal@shreve.net Network Engineer p: 318.222.2638x109 ShreveNet Inc. f: 318.221.6612 From owner-linux-mips@oss.sgi.com Mon Oct 8 11:27:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98IRVD23186 for linux-mips-outgoing; Mon, 8 Oct 2001 11:27:31 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98IRSD23182 for ; Mon, 8 Oct 2001 11:27:28 -0700 Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15qf7X-0005LI-00; Mon, 8 Oct 2001 20:27:19 +0200 Received: from pd95901a8.dip.t-dialin.net ([217.89.1.168] helo=thalreit.de) by mrvdom00.schlund.de with esmtp (Exim 2.12 #2) id 15qf7W-0002pN-00; Mon, 8 Oct 2001 20:27:19 +0200 Message-ID: <3BC1F004.75494A32@thalreit.de> Date: Mon, 08 Oct 2001 20:27:16 +0200 From: Volker Jahns Organization: Thalreit/DE X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: Brian CC: linux-mips@oss.sgi.com Subject: Re: Password recovery on IRIX box References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 702 Lines: 18 Brian wrote: > > I have an origin 200 I have been wanting to run linux on, its been sitting > up for a while. Before I wipe out and install linux, I need to get in > there to get some stuff of the drives. But I do not know the root > password. Can anyone direct me to password recovery procedures for IRIX? > > Brian > > ----------------------------------------------- > Brian Feeny, CCIE #8036 e: signal@shreve.net > Network Engineer p: 318.222.2638x109 > ShreveNet Inc. f: 318.221.6612 OK, a good and fast way is to boot into IRIX w/ its installation cd. Then mount the root partition and fix /etc/passwd. -- Volker Jahns, Volker.Jahns@thalreit.de, http://thalreit.de From owner-linux-mips@oss.sgi.com Mon Oct 8 12:40:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f98JeOq24527 for linux-mips-outgoing; Mon, 8 Oct 2001 12:40:24 -0700 Received: from dark-past (h117n1fls20o53.telia.com [213.64.214.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98JeLD24524 for ; Mon, 8 Oct 2001 12:40:21 -0700 Received: from yog-sothoth.dark-past.mine.nu (yog-sothoth [192.168.1.7]) by dark-past (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA03217 for ; Mon, 8 Oct 2001 22:52:11 -0700 Message-Id: <5.1.0.14.0.20011008225207.00a60b40@192.168.1.5> X-Sender: peter@192.168.1.5 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Oct 2001 23:17:17 +0200 To: linux-mips@oss.sgi.com From: Peter Andersson Subject: Trouble starting xserver/with tcpip. Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f98JeMD24525 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 878 Lines: 18 I have recently installed mips-linux 7.0 on an sgi indy machine and installed the included XF86 rpms. When i execute the command startx i get the message "waiting for X server to begin accepting connections". After that nothing happens. I suppose this has to do with the network not working as it should because i can´t ping "localhost" or "hostname" on the mips-linux machine. The mips-linux machine can´t ping the other computers on the network (except for another sgi running irix) either but it can access them via ftp, nfs and telnet. All the other machines can ping and reach the sgi via telnet. I am quite stuck here and all out of ideas, if you have any clue what i have done wrong please let me know. By the way do anyone know about a kernel with support for indys that doesnt have the newport graphics board (i have one indy with a GR2 XZ)? Thanks Peter From owner-linux-mips@oss.sgi.com Mon Oct 8 18:18:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f991IFr32127 for linux-mips-outgoing; Mon, 8 Oct 2001 18:18:15 -0700 Received: from dea.linux-mips.net (a1as04-p164.stg.tli.de [195.252.186.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f991ICD32124 for ; Mon, 8 Oct 2001 18:18:13 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f991Hh716125 for linux-mips@oss.sgi.com; Tue, 9 Oct 2001 03:17:43 +0200 Received: from mail.to11.net ([64.173.206.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f98EmpD16894 for ; Mon, 8 Oct 2001 07:48:52 -0700 Received: from hmpiii2 (hmpiii2.trinity200.org [10.0.0.9]) by mail.to11.net (Postfix) with SMTP id 7DBEF16782 for ; Mon, 8 Oct 2001 07:48:33 -0700 (PDT) Date: Mon, 8 Oct 2001 07:48:35 -0700 From: Tim Moss To: linux-mips@oss.sgi.com Subject: Re: Password recovery on IRIX box Message-Id: <20011008074835.4994f40f.mips@to11.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 533 Lines: 15 On Mon, 8 Oct 2001 09:09:42 -0500 (CDT) "Brian" wrote: > > I have an origin 200 I have been wanting to run linux on, its been > sitting > up for a while. Before I wipe out and install linux, I need to get in > there to get some stuff of the drives. But I do not know the root > password. Can anyone direct me to password recovery procedures for > IRIX? > > Brian This might help. I don't know if it applies to Origin 200 or not though. http://www.geocities.com/SiliconValley/Pines/2258/4dfaq.html#clearpass From owner-linux-mips@oss.sgi.com Mon Oct 8 22:47:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f995lhu05019 for linux-mips-outgoing; Mon, 8 Oct 2001 22:47:43 -0700 Received: from ikura.fe.dis.titech.ac.jp (ikura.fe.dis.titech.ac.jp [131.112.171.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f995lfD05016 for ; Mon, 8 Oct 2001 22:47:41 -0700 Received: (qmail 6010 invoked from network); 9 Oct 2001 05:47:39 -0000 Received: from unknown (HELO megaela.fe.dis.titech.ac.jp) (131.112.171.110) by 131.112.171.65 with SMTP; 9 Oct 2001 05:47:39 -0000 Date: Tue, 09 Oct 2001 14:47:39 +0900 Message-ID: From: GOTO Masanori To: jsimmons@transvirtual.com Cc: Volker.Jahns@thalreit.de, jsun@mvista.com, linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? In-Reply-To: In your message of "Sun, 7 Oct 2001 10:13:46 -0700 (PDT)" References: <3BC08523.4A23F7E8@thalreit.de> User-Agent: Wanderlust/2.2.15 (More Than Words) EMIKO/1.13.9 (Euglena tripteris) FLIM/1.13.2 (Kasanui) APEL/10.2 MULE XEmacs/21.1 (patch 10) (Capitol Reef) (i386-debian-linux) MIME-Version: 1.0 (generated by EMIKO 1.13.9 - "Euglena tripteris") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 566 Lines: 14 At Sun, 7 Oct 2001 10:13:46 -0700 (PDT), James Simmons wrote: > > Why don't you use the SONY playstation 2 w/ its LINUX kit? The costs are > > less and the graphics performance is greater than any Intel based PC I > > am aware of. > > The SONY stuff is 2.2.X based. Their is work going on for 2.4.X support > but it is not stable at the moment. FYI, but if you want to run kernel 2.4 on PS2, please check at http://sourceforge.net/projects/ps2hacking/ . Current 2.4 support is very early phase and unstable, but working. -- gotom From owner-linux-mips@oss.sgi.com Tue Oct 9 07:48:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99EmPE17309 for linux-mips-outgoing; Tue, 9 Oct 2001 07:48:25 -0700 Received: from dea.linux-mips.net (a1as12-p246.stg.tli.de [195.252.190.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99Em4D17302 for ; Tue, 9 Oct 2001 07:48:05 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f99CLrJ18633; Tue, 9 Oct 2001 14:21:53 +0200 Date: Tue, 9 Oct 2001 14:21:53 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Inline assembler fixes Message-ID: <20011009142153.A18620@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 266 Lines: 6 Following the recent reports about copy_from_user / copy_to_user getting misscompiled I changed these functions and a few others that also were suspect to suffer from the same problems. I consider these fixes quite important and thus I recommend upgrading. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 9 09:31:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99GV1c19343 for linux-mips-outgoing; Tue, 9 Oct 2001 09:31:01 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99GUID19331 for ; Tue, 9 Oct 2001 09:30:18 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id A8C8A125C0; Tue, 9 Oct 2001 09:30:14 -0700 (PDT) Date: Tue, 9 Oct 2001 09:30:14 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , gcc@gcc.gnu.org, GNU C Library Subject: The Linux binutils 2.11.92.0.5 is released. Message-ID: <20011009093014.A30900@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f99GUJD19333 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 13737 Lines: 496 This is the beta release of binutils 2.11.92.0.5 for Linux, which is based on binutils 2001 1005 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.92.0.5 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.92.0.5.tar.gz. Source code. 2. binutils-2.11.90.0.31-2.11.92.0.5.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.92.0.5-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.92.0.5.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 10/09/2001 From owner-linux-mips@oss.sgi.com Tue Oct 9 10:46:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99HkNL20243 for linux-mips-outgoing; Tue, 9 Oct 2001 10:46:23 -0700 Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99HkHD20240; Tue, 9 Oct 2001 10:46:17 -0700 Received: from zip.com.au (root@zipperii.zip.com.au [61.8.0.87]) by vasquez.zip.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id DAA13349; Wed, 10 Oct 2001 03:46:14 +1000 X-Authentication-Warning: vasquez.zip.com.au: Host root@zipperii.zip.com.au [61.8.0.87] claimed to be zip.com.au Message-ID: <3BC337DE.58DC36B1@zip.com.au> Date: Tue, 09 Oct 2001 10:46:06 -0700 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-ac7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: Inline assembler fixes References: <20011009142153.A18620@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 350 Lines: 9 Ralf Baechle wrote: > > Following the recent reports about copy_from_user / copy_to_user getting > misscompiled I changed these functions and a few others that also were > suspect to suffer from the same problems. I consider these fixes quite > important and thus I recommend upgrading. > What symptoms would one expect to see from this problem? From owner-linux-mips@oss.sgi.com Tue Oct 9 13:21:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99KLAm22997 for linux-mips-outgoing; Tue, 9 Oct 2001 13:21:10 -0700 Received: from newsmtp2.atmel.com (newsmtp2.atmel.org [12.146.133.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99KL5D22994 for ; Tue, 9 Oct 2001 13:21:05 -0700 Received: from hermes.sjo.atmel.com (newhermes [10.64.0.105]) by newsmtp2.atmel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA27884 for ; Tue, 9 Oct 2001 13:12:20 -0700 (PDT) Received: from mmc.atmel.com (mail [10.127.240.34]) by hermes.sjo.atmel.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA14640 for ; Tue, 9 Oct 2001 13:12:42 -0700 (PDT) Received: from mmc.atmel.com (IDENT:swang@pc-33.mmc.atmel.com [10.127.240.163]) by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id QAA23468 for ; Tue, 9 Oct 2001 16:20:50 -0400 (EDT) Message-ID: <3BC36AE4.4D1EE63E@mmc.atmel.com> Date: Tue, 09 Oct 2001 16:23:49 -0500 From: Shuanglin Wang Reply-To: swang@mmc.atmel.com Organization: ATMEL MMC X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-8smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: MIPS and pci_alloc_consistent()? Content-Type: multipart/alternative; boundary="------------6F0868FCCD2EF1871F9797F2" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2157 Lines: 60 --------------6F0868FCCD2EF1871F9797F2 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit I tried to use the pci_alloc_consistent() to allocate one-page DMA'able memory for my device driver. But, when booting up the system, it was always failed to execute the pci_alloc_consistent() by showing some memory errors. I traced the code to the function __alloc_page() in the file mm/page_alloc.c, and found the system called "wakeup_kswapd()". But at that time, the kswapd process pointer is a NULL pointer and the wakeup-related codes don't check the pointer is NULL or not, so the system was stopped because of dereferencing the null pointer. I'm working on a MIPS SEAD-2 board using Linux kernel 2.4.3 MIPS distrinution. Anybody has some ideas about the problem? Or are there other convenient methods to allocate DMA'able memory? Thanks, -- Shuanglin Wang Atmel Multimedia & Communications 3800 Gateway Centre, Suite 311 Morrisville, NC 27560 --------------6F0868FCCD2EF1871F9797F2 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 7bit I tried to use the pci_alloc_consistent() to allocate one-page  DMA'able memory for my device driver.  But, when booting up the system, it was always  failed to execute the pci_alloc_consistent() by showing some memory errors.

I traced the code to the function __alloc_page() in the file mm/page_alloc.c, and found the system called  "wakeup_kswapd()".  But at that time,  the kswapd process pointer is a NULL pointer and the wakeup-related codes don't check the pointer is NULL or not,  so the system was stopped because of dereferencing the null pointer.

I'm working on a MIPS SEAD-2 board using Linux kernel 2.4.3 MIPS distrinution.
Anybody has some ideas about the problem?  Or are there other convenient methods to allocate DMA'able memory?

Thanks, 

-- 
Shuanglin Wang
Atmel Multimedia & Communications
3800 Gateway Centre, Suite 311
Morrisville, NC 27560
  --------------6F0868FCCD2EF1871F9797F2-- From owner-linux-mips@oss.sgi.com Tue Oct 9 14:03:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99L37723898 for linux-mips-outgoing; Tue, 9 Oct 2001 14:03:07 -0700 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99L35D23895 for ; Tue, 9 Oct 2001 14:03:05 -0700 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 9 Oct 2001 21:04:31 UT Received: from bud.austin.esstech.com ([193.5.206.3]) by mail.esstech.com (8.8.8+Sun/8.8.8) with SMTP id OAA16648 for ; Tue, 9 Oct 2001 14:01:41 -0700 (PDT) Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id QAA13848; Tue, 9 Oct 2001 16:01:14 -0500 Message-ID: <3BC36684.6020609@esstech.com> Date: Tue, 09 Oct 2001 16:05:08 -0500 From: Gerald Champagne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: VisionClick debugger with Linux kernel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 705 Lines: 21 Has anyone used the Wind River VisionClick debugger with the Linux kernel? I'm using this debugger and works great except it thinks that the symbols for some files start at address zero instead of the proper offset. Has anyone else seen this and were you able to get it to work? I'm using the latest tools from: ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/RPMS/i386/toolchain-mips-20010830-1.i386.rpm I can't find any differences between the files that work and the files that don't work and the symbols look correct in the System.map file. Yeah, I'm working with Wind River, but I haven't gotten a solution yet. You know how that 8-5 centralized corporate support is though. :) Thanks! Gerald From owner-linux-mips@oss.sgi.com Tue Oct 9 14:08:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99L8Sd24251 for linux-mips-outgoing; Tue, 9 Oct 2001 14:08:28 -0700 Received: from clrsrv.clearcore.com (@www.clearcore.com [208.141.182.168]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99L8PD24248 for ; Tue, 9 Oct 2001 14:08:25 -0700 Received: from clearcore.net (nephi.clearcore.com [192.168.3.3]) by clrsrv.clearcore.com (8.10.1/8.10.1) with ESMTP id f99L8Lk25884; Tue, 9 Oct 2001 15:08:21 -0600 Message-ID: <3BC3673F.3030808@clearcore.net> Date: Tue, 09 Oct 2001 15:08:15 -0600 From: Joe George Organization: ClearCore User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: MIPS PC - anyone? References: <20011006102302.B3492@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1248 Lines: 33 I have been working on the design of such a machine for a few months now as a background project. The mainboard features are: PMC RM7000A 400MHz CPU, 2MB tertiary cache, GT64120A system controller, 512K byte boot prom, DS1501 RTC, 512MB SDRAM, two serial ports (ST16C2552), OPTI 82C862 USB controller, 4 32-bit 33MHz PCI slots, 2 32-bit 66MHz PCI slots, ATX form factor. Prices for the processor and system controller are significantly higher than the equivilent i386 components in low volume. High enough volume to get it to parity with i386 prices is probably not realistic. From what I've heard some people still don't use Linux. :) Price for the system will probably be in the US$1200 range. Send me an email off the list if you are interested or have suggestions. The more I hear from the faster it will probably get done. Joe Jun Sun wrote: > Does anybody know if there is such a "MIPS PC" machine? Essentially > I am looking for a machine with MIPS CPU and PC peripherals (such as > SIMM RAM, PCI bus, EIDE HD, VGA graphics, PS/2 mouse/kbd, etc). > > It would be really nice to have such a box. If it is massively produced, > the price should be cheaper than i386 PCs because MIPS CPU price is > much cheaper. > > Jun > From owner-linux-mips@oss.sgi.com Wed Oct 10 04:39:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ABdEo15635 for linux-mips-outgoing; Wed, 10 Oct 2001 04:39:14 -0700 Received: from dea.linux-mips.net (a1as04-p174.stg.tli.de [195.252.186.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ABd8D15632 for ; Wed, 10 Oct 2001 04:39:09 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9ABcWT13778; Wed, 10 Oct 2001 13:38:32 +0200 Date: Wed, 10 Oct 2001 13:38:32 +0200 From: Ralf Baechle To: Shuanglin Wang Cc: linux-mips@oss.sgi.com Subject: Re: MIPS and pci_alloc_consistent()? Message-ID: <20011010133832.B13349@dea.linux-mips.net> References: <3BC36AE4.4D1EE63E@mmc.atmel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BC36AE4.4D1EE63E@mmc.atmel.com>; from swang@mmc.atmel.com on Tue, Oct 09, 2001 at 04:23:49PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 994 Lines: 23 On Tue, Oct 09, 2001 at 04:23:49PM -0500, Shuanglin Wang wrote: > I tried to use the pci_alloc_consistent() to allocate one-page DMA'able > memory for my device driver. But, when booting up the system, it was > always failed to execute the pci_alloc_consistent() by showing some > memory errors. > > I traced the code to the function __alloc_page() in the file > mm/page_alloc.c, and found the system called "wakeup_kswapd()". But at > that time, the kswapd process pointer is a NULL pointer and the > wakeup-related codes don't check the pointer is NULL or not, so the > system was stopped because of dereferencing the null pointer. This sounds like either memory corruption has overwritten the kernel pointer or you're trying to use pci_alloc_consistent before the memory managment is initialized. > Anybody has some ideas about the problem? Or are there other convenient > methods to allocate DMA'able memory? Anything else than the pci_alloc_* functions isn't portable. Ralf From owner-linux-mips@oss.sgi.com Wed Oct 10 04:41:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ABff115725 for linux-mips-outgoing; Wed, 10 Oct 2001 04:41:41 -0700 Received: from dea.linux-mips.net (a1as04-p174.stg.tli.de [195.252.186.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ABfcD15721 for ; Wed, 10 Oct 2001 04:41:38 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9ABf9M13816; Wed, 10 Oct 2001 13:41:09 +0200 Date: Wed, 10 Oct 2001 13:41:09 +0200 From: Ralf Baechle To: Volker Jahns Cc: Brian , linux-mips@oss.sgi.com Subject: Re: Password recovery on IRIX box Message-ID: <20011010134109.C13349@dea.linux-mips.net> References: <3BC1F004.75494A32@thalreit.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BC1F004.75494A32@thalreit.de>; from Volker.Jahns@thalreit.de on Mon, Oct 08, 2001 at 08:27:16PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 117 Lines: 4 The question has been asked pretty often. So I'd appreciate if somebody could write an entry for our howto. Ralf From owner-linux-mips@oss.sgi.com Wed Oct 10 04:54:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ABsI615995 for linux-mips-outgoing; Wed, 10 Oct 2001 04:54:18 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ABsGD15992 for ; Wed, 10 Oct 2001 04:54:16 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15rHwB-0006We-00; Wed, 10 Oct 2001 13:54:11 +0200 Date: Wed, 10 Oct 2001 13:54:11 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: Password recovery on IRIX box Message-ID: <20011010135411.C23173@gandalf.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <3BC1F004.75494A32@thalreit.de> <20011010134109.C13349@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011010134109.C13349@dea.linux-mips.net>; from ralf@oss.sgi.com on Wed, Oct 10, 2001 at 01:41:09PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 367 Lines: 8 Ralf, On Wed, Oct 10, 2001 at 01:41:09PM +0200, Ralf Baechle wrote: > The question has been asked pretty often. So I'd appreciate if somebody > could write an entry for our howto. As I mentioned before it's in the "SGI Frequently Asked Questions" at: http://www-viz.tamu.edu/~sgi-faq/ so I'd prefer a link to that one since it's not linux related at all. -- Guido From owner-linux-mips@oss.sgi.com Wed Oct 10 05:22:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ACMhI16809 for linux-mips-outgoing; Wed, 10 Oct 2001 05:22:43 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ACMfD16806 for ; Wed, 10 Oct 2001 05:22:41 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15rINk-0006gW-00; Wed, 10 Oct 2001 14:22:40 +0200 Date: Wed, 10 Oct 2001 14:22:40 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Indy hd boot micro howto on black.hole.org Message-ID: <20011010142240.G23173@gandalf.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 240 Lines: 5 Could the administrator of the above site please either remove or update the "Indy HD boot micro howto" since it's way outdated, see: http://honk.physik.uni-konstanz.de/linux-mips/indy-boot/indy-hd-boot-micro-howto.html Regards, -- Guido From owner-linux-mips@oss.sgi.com Wed Oct 10 08:15:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9AFFsQ22237 for linux-mips-outgoing; Wed, 10 Oct 2001 08:15:54 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9AFFqD22234 for ; Wed, 10 Oct 2001 08:15:52 -0700 Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5]) by mcp.csh.rit.edu (Postfix) with ESMTP id 7B77718C for ; Wed, 10 Oct 2001 11:15:50 -0400 (EDT) Date: Wed, 10 Oct 2001 11:15:43 -0400 (EDT) From: George Gensure To: Subject: xserver package Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 565 Lines: 14 Does anyone know who built the xserver-xfree86 package for mips? In particular, I need to have the options used to build it. Any time I use a custom built version, the coloring is extremely different than what it's supposed to be, but when I install the packaged version, the coloring comes out right. I have my reasons for working with a build-only version and they definitely outweigh the package install. George -- George R. Gensure Computer Science House Member werkt@csh.rit.edu Sophomore, Rochester Institute of Technology Computer Science From owner-linux-mips@oss.sgi.com Thu Oct 11 09:58:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9BGwGP26680 for linux-mips-outgoing; Thu, 11 Oct 2001 09:58:16 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9BGwBD26677 for ; Thu, 11 Oct 2001 09:58:11 -0700 Received: from multimania.com (dyn-213-36-109-51.ppp.libertysurf.fr [213.36.109.51]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id JAA20874 for ; Thu, 11 Oct 2001 09:58:04 -0700 (PDT) mail_from (mithec@multimania.com) Message-Id: <200110111658.JAA20874@deliverator.sgi.com> From: "MITHEC" To: Subject: La Quatričme Guerre Mondiale a commencé! Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Thu, 11 Oct 2001 19:01:22 +0200 Reply-To: "MITHEC" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by deliverator.sgi.com id JAA20874 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2039 Lines: 58 La Quatri=E8me Guerre Mondiale a commenc=E9!

Le 11 septembre 2001, le monde a chang=E9 pour toujours : La Quat= ri=E8me guerre mondiale a commenc=E9. Quel sera le r=F4le de la Russie dans= cette guerre ? Et celui d=92Europe? Quelles seront les armes de= cette guerre? La Russie entrera-t-elle dans l=92OTAN? On se pose beaucoup= de questions. La G=E9opolitique est du retour. =AB La Russie apr=E8= s l=92an 2000 =BB en tant que livre g=E9opolitique majeur tr=E8s r=E9ce= nt nous aidera de trouver des r=E9ponses.

Cet e-mail non-sollicit=E9 n'est pas un S.P.A.M. parce qu'il est confor= me au d=E9cret 1618 Titre III du 105e Congr=E8s des =C9tats-Unis qui stipule que le e-mail doit contenir l'adresse d'exp=E9diteur et avo= ir une facilit=E9 d'annulation pour l'adress=E9.
From owner-linux-mips@oss.sgi.com Fri Oct 12 04:39:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CBdY518425 for linux-mips-outgoing; Fri, 12 Oct 2001 04:39:34 -0700 Received: from tnint06.telogy.com (mail.telogy.com [209.116.120.7] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CBdPD18421 for ; Fri, 12 Oct 2001 04:39:25 -0700 Received: by tnint06.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id <4QAKX893>; Fri, 12 Oct 2001 07:38:32 -0400 Received: from telogy.com (reddwarf.telogy.design.ti.com [158.218.105.148]) by tnint06.telogy.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4QAKX89N; Fri, 12 Oct 2001 07:38:27 -0400 From: Jeff Harrell To: Gerald Champagne Cc: linux-mips@oss.sgi.com Message-ID: <3BC6F26B.E386F412@telogy.com> Date: Fri, 12 Oct 2001 07:38:51 -0600 Organization: Telogy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: VisionClick debugger with Linux kernel References: <3BC36684.6020609@esstech.com> Content-Type: multipart/alternative; boundary="------------705C5FDFF000B036A3817AAD" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4674 Lines: 114 --------------705C5FDFF000B036A3817AAD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gerald Champagne wrote: Has anyone used the Wind River VisionClick debugger with the Linux kernel? I'm using this debugger and works great except it thinks that the symbols for some files start at address zero instead of the proper offset. Has anyone else seen this and were you able to get it to work? I'm using the latest tools from: ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/RPMS/i386/toolchain-mips-200 10830-1.i386.rpm I can't find any differences between the files that work and the files that don't work and the symbols look correct in the System.map file. Yeah, I'm working with Wind River, but I haven't gotten a solution yet. You know how that 8-5 centralized corporate support is though. :) Thanks! Gerald We are using a VisionIce debugger from the linux-mips kernel, although I am using the MontaVista Hardhat 2.0 tools. I am able to load the symbols after they have been generated from the Convert utility. It seems to work fine except for modules...haven't had much luck with that. Had to get a patch to view TLB mapped memory properly though. Jeff -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \ Jeff Harrell (jharrell@telogy.com) \ \ Telogy Networks \ \ Broadband Access Group \ \ \ \ Work: (301) 515-6537 \ \ Fax: (301) 515-6637 \ \~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------705C5FDFF000B036A3817AAD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Gerald Champagne wrote:
Has anyone used the Wind River VisionClick debugger with the Linux kernel?
I'm using this debugger and works great except it thinks that the symbols
for some files start at address zero instead of the proper offset.  Has anyone
else seen this and were you able to get it to work?  I'm using the latest tools
from:

ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/RPMS/i386/toolchain-mips-20010830-1.i386.rpm

I can't find any differences between the files that work and the files that
don't work and the symbols look correct in the System.map file.

Yeah, I'm working with Wind River, but I haven't gotten a solution yet.
You know how that 8-5 centralized corporate support is though. :)

Thanks!

Gerald

We are using a VisionIce debugger from the linux-mips kernel, although I am using the
MontaVista Hardhat 2.0 tools.   I am able to load the symbols after they have been
generated from the Convert utility.  It seems to work fine except for modules...haven't
had much luck with that.  Had to get a patch to view TLB mapped memory properly
though.

Jeff 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\ Jeff Harrell  (jharrell@telogy.com)               \
\ Telogy Networks                                   \
\ Broadband Access Group                            \
\                                                   \
\ Work: (301) 515-6537                              \
\ Fax:  (301) 515-6637                              \
\~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  --------------705C5FDFF000B036A3817AAD-- From owner-linux-mips@oss.sgi.com Fri Oct 12 04:58:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CBwLw18756 for linux-mips-outgoing; Fri, 12 Oct 2001 04:58:21 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CBw7D18737; Fri, 12 Oct 2001 04:58:07 -0700 Received: from mail.sonytel.be (admin.sonytel.be [195.0.45.167] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA02636; Fri, 12 Oct 2001 04:57:55 -0700 (PDT) mail_from (Geert.Uytterhoeven@sonycom.com) Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA28424; Fri, 12 Oct 2001 13:52:25 +0200 (MET DST) Date: Fri, 12 Oct 2001 13:52:19 +0200 (MEST) From: Geert Uytterhoeven To: Jun Sun cc: Ralf Baechle , Gerald Champagne , "linux-mips@oss.sgi.com" Subject: Re: Remove ifdefs from setup_arch() In-Reply-To: <3BBB7F14.C864736A@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1145 Lines: 32 On Wed, 3 Oct 2001, Jun Sun wrote: > I talked about machine detection a while back. My idea is following: > > 0. all machines that are *configured* into the image will supply _detect() > and _setup() functions. > > 1. at MIPS start up, we loop through all _detect(), which returns three > values, a) run-time detection negative, b) run-time detection positive, and c) > no run-time detection code, but I return positive because I am configured in. > > 2. the startup code resolves conflicts (which sometimes may panic); and decide > on one machine. > > 3. then the startup code calls the right _setup() code which will set up > the mach_type and other stuff. Nice! I suppose you want to have struct containing pointers to both the detect() and setup() functions, so you know which setup() function you have to call? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Fri Oct 12 09:25:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CGPBA24680 for linux-mips-outgoing; Fri, 12 Oct 2001 09:25:11 -0700 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CGP4D24677 for ; Fri, 12 Oct 2001 09:25:04 -0700 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 12 Oct 2001 16:26:32 UT Received: from bud.austin.esstech.com ([193.5.206.3]) by mail.esstech.com (8.8.8+Sun/8.8.8) with SMTP id JAA20790; Fri, 12 Oct 2001 09:23:36 -0700 (PDT) Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id LAA18851; Fri, 12 Oct 2001 11:23:03 -0500 Message-ID: <3BC719CD.8060303@esstech.com> Date: Fri, 12 Oct 2001 11:26:53 -0500 From: Gerald Champagne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Jeff Harrell CC: linux-mips@oss.sgi.com Subject: Re: VisionClick debugger with Linux kernel References: <3BC36684.6020609@esstech.com> <3BC6F26B.E386F412@telogy.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2048 Lines: 62 Thanks for the response. I just found the problem last night. Their convert utility was screwing up on files that had module_init and module_exit routines in them, even though it wasn't compiled as a module. I fixed it by replacing the __init and __exit macros with nothing so the code is placed in a normal .text segment. Gerald Jeff Harrell wrote: > Gerald Champagne wrote: > > Has anyone used the Wind River VisionClick debugger with the Linux > kernel? > I'm using this debugger and works great except it thinks that the > symbols > for some files start at address zero instead of the proper offset. > Has anyone > else seen this and were you able to get it to work? I'm using the > latest tools > from: > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/RPMS/i386/toolchain-mips-20010830-1.i386.rpm > > > I can't find any differences between the files that work and the > files that > don't work and the symbols look correct in the System.map file. > > Yeah, I'm working with Wind River, but I haven't gotten a solution yet. > You know how that 8-5 centralized corporate support is though. :) > > Thanks! > > Gerald > > We are using a VisionIce debugger from the linux-mips kernel, although I > am using the > MontaVista Hardhat 2.0 tools. I am able to load the symbols after they > have been > generated from the Convert utility. It seems to work fine except for > modules...haven't > had much luck with that. Had to get a patch to view TLB mapped memory > properly > though. > > Jeff > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > \ Jeff Harrell (jharrell@telogy.com) \ > \ Telogy Networks \ > \ Broadband Access Group \ > \ \ > \ Work: (301) 515-6537 \ > \ Fax: (301) 515-6637 \ > \~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > From owner-linux-mips@oss.sgi.com Fri Oct 12 09:26:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CGQYo24774 for linux-mips-outgoing; Fri, 12 Oct 2001 09:26:34 -0700 Received: from quicklogic.com (quick1.quicklogic.com [206.184.225.224]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CGQGD24767 for ; Fri, 12 Oct 2001 09:26:16 -0700 Received: from enghanks ([207.81.96.51]) by quicklogic.com; Fri, 12 Oct 2001 09:26:03 -0700 From: "Hanks Li" To: Subject: Big endian problem Date: Fri, 12 Oct 2001 12:26:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3866 Lines: 222 Hi, Has anyone tried to compile in Big Endian mode? When I compile the code in big endian, I got the following message. Does anybody know how to solve this problem? The assembler I'm using is "GNU assembler 2.11.90.0.27". I have no problem compiling the code in little endian at all. Thanks Hanshi Li ---------------------------------------------------------------------------- ------------------------------------ mips-linux-gcc -I /home/hli/linux/include/asm/gcc -D__KERNEL__ -I/home/hli/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-ali asing -fno-common -G 0 -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe -DEXPORT_SYMTAB -c time.c Assembler messages: Warning: The -mcpu option is deprecated. Please use -march and -mtune instead. time.c: In function `calibrate_div32_gettimeoffset': time.c:225: Unrecognizable insn: (insn 60 144 66 (parallel[ (set (reg:SI 8 t0) (asm_operands (".set push .set noat .set noreorder b 1f li %4,0x21 0: sll $1,%0,0x1 srl %3,%0,0x1f or %0,$1,$2 sll %1,%1,0x1 sll %2,%2,0x1 1: bnez %3,2f sltu $2,%0,%z5 bnez $2,3f 2: addiu %4,%4,-1 subu %0,%0,%z5 addiu %2,%2,1 3: bnez %4,0b srl $2,%1,0x1f .set pop") ("=&r") 0[ (reg/v:SI 4 a0) (reg:SI 8 t0) (reg:DI 6 a2) (reg/v:SI 5 a1) (reg:SI 9 t1) ] [ (asm_input:SI ("Jr")) (asm_input:SI ("0")) (asm_input:DI ("1")) (asm_input:SI ("2")) (asm_input:SI ("3")) ] ("time.c") 201)) (set (reg:SI 6 a2) (asm_operands (".set push .set noat .set noreorder b 1f li %4,0x21 0: sll $1,%0,0x1 srl %3,%0,0x1f or %0,$1,$2 sll %1,%1,0x1 sll %2,%2,0x1 1: bnez %3,2f sltu $2,%0,%z5 bnez $2,3f 2: addiu %4,%4,-1 subu %0,%0,%z5 addiu %2,%2,1 3: bnez %4,0b srl $2,%1,0x1f .set pop") ("=&r") 1[ (reg/v:SI 4 a0) (reg:SI 8 t0) (reg:DI 6 a2) (reg/v:SI 5 a1) (reg:SI 9 t1) ] [ (asm_input:SI ("Jr")) (asm_input:SI ("0")) (asm_input:DI ("1")) (asm_input:SI ("2")) (asm_input:SI ("3")) ] ("time.c") 201)) (set (reg/v:SI 5 a1) (asm_operands (".set push .set noat .set noreorder b 1f li %4,0x21 0: sll $1,%0,0x1 srl %3,%0,0x1f or %0,$1,$2 sll %1,%1,0x1 sll %2,%2,0x1 1: bnez %3,2f sltu $2,%0,%z5 bnez $2,3f 2: addiu %4,%4,-1 subu %0,%0,%z5 addiu %2,%2,1 3: bnez %4,0b srl $2,%1,0x1f .set pop") ("=&r") 2[ (reg/v:SI 4 a0) (reg:SI 8 t0) (reg:DI 6 a2) (reg/v:SI 5 a1) (reg:SI 9 t1) ] [ (asm_input:SI ("Jr")) (asm_input:SI ("0")) (asm_input:DI ("1")) (asm_input:SI ("2")) (asm_input:SI ("3")) ] ("time.c") 201)) (set (reg:SI 9 t1) (asm_operands (".set push .set noat .set noreorder b 1f li %4,0x21 0: sll $1,%0,0x1 srl %3,%0,0x1f or %0,$1,$2 sll %1,%1,0x1 sll %2,%2,0x1 1: bnez %3,2f sltu $2,%0,%z5 bnez $2,3f 2: addiu %4,%4,-1 subu %0,%0,%z5 addiu %2,%2,1 3: bnez %4,0b srl $2,%1,0x1f .set pop") ("=&r") 3[ (reg/v:SI 4 a0) (reg:SI 8 t0) (reg:DI 6 a2) (reg/v:SI 5 a1) (reg:SI 9 t1) ] [ (asm_input:SI ("Jr")) (asm_input:SI ("0")) (asm_input:DI ("1")) (asm_input:SI ("2")) (asm_input:SI ("3")) ] ("time.c") 201)) (set (reg:SI 14 t6) (asm_operands (".set push .set noat .set noreorder b 1f li %4,0x21 0: sll $1,%0,0x1 srl %3,%0,0x1f or %0,$1,$2 sll %1,%1,0x1 sll %2,%2,0x1 1: bnez %3,2f sltu $2,%0,%z5 bnez $2,3f 2: addiu %4,%4,-1 subu %0,%0,%z5 addiu %2,%2,1 3: bnez %4,0b srl $2,%1,0x1f .set pop") ("=&r") 4[ (reg/v:SI 4 a0) (reg:SI 8 t0) (reg:DI 6 a2) (reg/v:SI 5 a1) (reg:SI 9 t1) ] [ (asm_input:SI ("Jr")) (asm_input:SI ("0")) (asm_input:DI ("1")) (asm_input:SI ("2")) (asm_input:SI ("3")) ] ("time.c") 201)) (clobber (reg:QI 2 v0)) (clobber (reg:QI 1 at)) ] ) -1 (insn_list:REG_DEP_OUTPUT 13 (insn_list 38 (insn_list 53 (insn_list 51 (insn_list 41 (nil)))))) (nil)) time.c:225: confused by earlier errors, bailing out make[1]: *** [time.o] Error 1 make[1]: Leaving directory `/home/hli/linux/arch/mips/kernel' make: *** [_dir_arch/mips/kernel] Error 2 ---------------------------------------------------------------------------- --------------------------------- From owner-linux-mips@oss.sgi.com Fri Oct 12 10:44:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CHiPx26337 for linux-mips-outgoing; Fri, 12 Oct 2001 10:44:25 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CHiHD26331; Fri, 12 Oct 2001 10:44:17 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9CHkiB05140; Fri, 12 Oct 2001 10:46:44 -0700 Message-ID: <3BC72BE8.F50C2001@mvista.com> Date: Fri, 12 Oct 2001 10:44:08 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Geert Uytterhoeven CC: Ralf Baechle , Gerald Champagne , "linux-mips@oss.sgi.com" Subject: Re: Remove ifdefs from setup_arch() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1576 Lines: 41 Geert Uytterhoeven wrote: > > On Wed, 3 Oct 2001, Jun Sun wrote: > > I talked about machine detection a while back. My idea is following: > > > > 0. all machines that are *configured* into the image will supply _detect() > > and _setup() functions. > > > > 1. at MIPS start up, we loop through all _detect(), which returns three > > values, a) run-time detection negative, b) run-time detection positive, and c) > > no run-time detection code, but I return positive because I am configured in. > > > > 2. the startup code resolves conflicts (which sometimes may panic); and decide > > on one machine. > > > > 3. then the startup code calls the right _setup() code which will set up > > the mach_type and other stuff. > > Nice! > > I suppose you want to have struct containing pointers to both the detect() and > setup() functions, so you know which setup() function you have to call? > The actual mechanism can vary and be flexible, but here is more detail what I had in mind: 1. _detect is placed in a special ELF section (mips_mach_detect), using similar mechanism as .initcall.init section and __setup() macro. 2. in addition to the 3 possible return value, _detect also returns a function pointer to _setup. Once a final candidate is chosen, the machine detection code will issue the right _setup call. There are probably some other related changes which need to be made, (e.g., prom_init() may be eliminated, etc). It seems like I get more and more positive feedbacks on this idea. We should try to implement this in 2.5. Jun From owner-linux-mips@oss.sgi.com Fri Oct 12 10:46:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CHk9j26418 for linux-mips-outgoing; Fri, 12 Oct 2001 10:46:09 -0700 Received: from dea.linux-mips.net (a1as05-p89.stg.tli.de [195.252.187.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CHk6D26415 for ; Fri, 12 Oct 2001 10:46:06 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9CHjNm00748; Fri, 12 Oct 2001 19:45:23 +0200 Date: Fri, 12 Oct 2001 19:45:23 +0200 From: Ralf Baechle To: Hanks Li Cc: linux-mips@oss.sgi.com Subject: Re: Big endian problem Message-ID: <20011012194523.A691@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hli@quicklogic.com on Fri, Oct 12, 2001 at 12:26:07PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 379 Lines: 10 On Fri, Oct 12, 2001 at 12:26:07PM -0400, Hanks Li wrote: > Has anyone tried to compile in Big Endian mode? When I compile the code in > big endian, I got the following message. Does anybody know how to solve this > problem? The assembler I'm using is "GNU assembler 2.11.90.0.27". I have no > problem compiling the code in little endian at all. What compiler is this? Ralf From owner-linux-mips@oss.sgi.com Fri Oct 12 10:48:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CHmLI26511 for linux-mips-outgoing; Fri, 12 Oct 2001 10:48:21 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CHm2D26505 for ; Fri, 12 Oct 2001 10:48:02 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9CHoWB05316; Fri, 12 Oct 2001 10:50:32 -0700 Message-ID: <3BC72CCC.3604FEC8@mvista.com> Date: Fri, 12 Oct 2001 10:47:56 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Hanks Li CC: linux-mips@oss.sgi.com Subject: Re: Big endian problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4582 Lines: 232 Which time.c is this? I have seen this problem caused by mis-defined USECS_PER_JIFFY_FRAC macro. Look at other time.c files for the right one. Or better yet, upgrade your port to use the common time.c. See Documantation/mips/time.README file. Jun Hanks Li wrote: > > Hi, > > Has anyone tried to compile in Big Endian mode? When I compile the code in > big endian, I got the following message. Does anybody know how to solve this > problem? The assembler I'm using is "GNU assembler 2.11.90.0.27". I have no > problem compiling the code in little endian at all. > > Thanks > > Hanshi Li > > ---------------------------------------------------------------------------- > ------------------------------------ > mips-linux-gcc -I > /home/hli/linux/include/asm/gcc -D__KERNEL__ -I/home/hli/linux/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-ali > asing -fno-common -G > 0 -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe -DEXPORT_SYMTAB > -c time.c > Assembler messages: > Warning: The -mcpu option is deprecated. Please use -march and -mtune > instead. > time.c: In function `calibrate_div32_gettimeoffset': > time.c:225: Unrecognizable insn: > (insn 60 144 66 (parallel[ > (set (reg:SI 8 t0) > (asm_operands (".set push > .set noat > .set noreorder > b 1f > li %4,0x21 > 0: > sll $1,%0,0x1 > srl %3,%0,0x1f > or %0,$1,$2 > sll %1,%1,0x1 > sll %2,%2,0x1 > 1: > bnez %3,2f > sltu $2,%0,%z5 > bnez $2,3f > 2: > addiu %4,%4,-1 > subu %0,%0,%z5 > addiu %2,%2,1 > 3: > bnez %4,0b > srl $2,%1,0x1f > .set pop") ("=&r") 0[ > (reg/v:SI 4 a0) > (reg:SI 8 t0) > (reg:DI 6 a2) > (reg/v:SI 5 a1) > (reg:SI 9 t1) > ] > [ > (asm_input:SI ("Jr")) > (asm_input:SI ("0")) > (asm_input:DI ("1")) > (asm_input:SI ("2")) > (asm_input:SI ("3")) > ] ("time.c") 201)) > (set (reg:SI 6 a2) > (asm_operands (".set push > .set noat > .set noreorder > b 1f > li %4,0x21 > 0: > sll $1,%0,0x1 > srl %3,%0,0x1f > or %0,$1,$2 > sll %1,%1,0x1 > sll %2,%2,0x1 > 1: > bnez %3,2f > sltu $2,%0,%z5 > bnez $2,3f > 2: > addiu %4,%4,-1 > subu %0,%0,%z5 > addiu %2,%2,1 > 3: > bnez %4,0b > srl $2,%1,0x1f > .set pop") ("=&r") 1[ > (reg/v:SI 4 a0) > (reg:SI 8 t0) > (reg:DI 6 a2) > (reg/v:SI 5 a1) > (reg:SI 9 t1) > ] > [ > (asm_input:SI ("Jr")) > (asm_input:SI ("0")) > (asm_input:DI ("1")) > (asm_input:SI ("2")) > (asm_input:SI ("3")) > ] ("time.c") 201)) > (set (reg/v:SI 5 a1) > (asm_operands (".set push > .set noat > .set noreorder > b 1f > li %4,0x21 > 0: > sll $1,%0,0x1 > srl %3,%0,0x1f > or %0,$1,$2 > sll %1,%1,0x1 > sll %2,%2,0x1 > 1: > bnez %3,2f > sltu $2,%0,%z5 > bnez $2,3f > 2: > addiu %4,%4,-1 > subu %0,%0,%z5 > addiu %2,%2,1 > 3: > bnez %4,0b > srl $2,%1,0x1f > .set pop") ("=&r") 2[ > (reg/v:SI 4 a0) > (reg:SI 8 t0) > (reg:DI 6 a2) > (reg/v:SI 5 a1) > (reg:SI 9 t1) > ] > [ > (asm_input:SI ("Jr")) > (asm_input:SI ("0")) > (asm_input:DI ("1")) > (asm_input:SI ("2")) > (asm_input:SI ("3")) > ] ("time.c") 201)) > (set (reg:SI 9 t1) > (asm_operands (".set push > .set noat > .set noreorder > b 1f > li %4,0x21 > 0: > sll $1,%0,0x1 > srl %3,%0,0x1f > or %0,$1,$2 > sll %1,%1,0x1 > sll %2,%2,0x1 > 1: > bnez %3,2f > sltu $2,%0,%z5 > bnez $2,3f > 2: > addiu %4,%4,-1 > subu %0,%0,%z5 > addiu %2,%2,1 > 3: > bnez %4,0b > srl $2,%1,0x1f > .set pop") ("=&r") 3[ > (reg/v:SI 4 a0) > (reg:SI 8 t0) > (reg:DI 6 a2) > (reg/v:SI 5 a1) > (reg:SI 9 t1) > ] > [ > (asm_input:SI ("Jr")) > (asm_input:SI ("0")) > (asm_input:DI ("1")) > (asm_input:SI ("2")) > (asm_input:SI ("3")) > ] ("time.c") 201)) > (set (reg:SI 14 t6) > (asm_operands (".set push > .set noat > .set noreorder > b 1f > li %4,0x21 > 0: > sll $1,%0,0x1 > srl %3,%0,0x1f > or %0,$1,$2 > sll %1,%1,0x1 > sll %2,%2,0x1 > 1: > bnez %3,2f > sltu $2,%0,%z5 > bnez $2,3f > 2: > addiu %4,%4,-1 > subu %0,%0,%z5 > addiu %2,%2,1 > 3: > bnez %4,0b > srl $2,%1,0x1f > .set pop") ("=&r") 4[ > (reg/v:SI 4 a0) > (reg:SI 8 t0) > (reg:DI 6 a2) > (reg/v:SI 5 a1) > (reg:SI 9 t1) > ] > [ > (asm_input:SI ("Jr")) > (asm_input:SI ("0")) > (asm_input:DI ("1")) > (asm_input:SI ("2")) > (asm_input:SI ("3")) > ] ("time.c") 201)) > (clobber (reg:QI 2 v0)) > (clobber (reg:QI 1 at)) > ] ) -1 (insn_list:REG_DEP_OUTPUT 13 (insn_list 38 (insn_list 53 (insn_list > 51 (insn_list 41 (nil)))))) > (nil)) > time.c:225: confused by earlier errors, bailing out > make[1]: *** [time.o] Error 1 > make[1]: Leaving directory `/home/hli/linux/arch/mips/kernel' > make: *** [_dir_arch/mips/kernel] Error 2 > ---------------------------------------------------------------------------- > --------------------------------- From owner-linux-mips@oss.sgi.com Fri Oct 12 11:11:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CIBmp27260 for linux-mips-outgoing; Fri, 12 Oct 2001 11:11:48 -0700 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CIBeD27250; Fri, 12 Oct 2001 11:11:40 -0700 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 12 Oct 2001 18:13:08 UT Received: from bud.austin.esstech.com ([193.5.206.3]) by mail.esstech.com (8.8.8+Sun/8.8.8) with SMTP id LAA22291; Fri, 12 Oct 2001 11:10:13 -0700 (PDT) Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id NAA19852; Fri, 12 Oct 2001 13:09:39 -0500 Message-ID: <3BC732C9.9080508@esstech.com> Date: Fri, 12 Oct 2001 13:13:29 -0500 From: Gerald Champagne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Jun Sun CC: Geert Uytterhoeven , Ralf Baechle , "linux-mips@oss.sgi.com" Subject: Re: Remove ifdefs from setup_arch() References: <3BC72BE8.F50C2001@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1466 Lines: 40 Can you wrap this code into small functions like machine_detect() and board_setup() and put it all in one place? That way those of us who just want a simple system supporting only one board can just replace those two functions with defines that alias the proper machine_detect and board_setup fuctions. Then all of the special elf sections and function pointers go away. If it's all in one place like this, then maybe it could be configured in the config.in file. I can ifdef it out for boards like mine or other boards that can't possibly support more than one system in a given binary image. config.in could ifdef it in for configurations that could possibly support more than one configuration in a given binary image. Gerald Jun Sun wrote: > The actual mechanism can vary and be flexible, but here is more detail what I > had in mind: > > 1. _detect is placed in a special ELF section (mips_mach_detect), using > similar mechanism as .initcall.init section and __setup() macro. > > 2. in addition to the 3 possible return value, _detect also returns a > function pointer to _setup. Once a final candidate is chosen, the machine > detection code will issue the right _setup call. > > There are probably some other related changes which need to be made, (e.g., > prom_init() may be eliminated, etc). > > It seems like I get more and more positive feedbacks on this idea. We should > try to implement this in 2.5. > > Jun > > > From owner-linux-mips@oss.sgi.com Fri Oct 12 13:12:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CKCLu29707 for linux-mips-outgoing; Fri, 12 Oct 2001 13:12:21 -0700 Received: from mail.vcubed.com ([207.81.96.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CKC1D29698 for ; Fri, 12 Oct 2001 13:12:01 -0700 Received: from quicklogic.com ([207.81.96.153]) by mail.vcubed.com (8.9.3/8.9.3) with ESMTP id QAA28419; Fri, 12 Oct 2001 16:47:38 -0400 Message-ID: <3BC74EFE.9020109@quicklogic.com> Date: Fri, 12 Oct 2001 16:13:50 -0400 From: Dan Aizenstros Organization: QuickLogic Canada User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jun Sun CC: Hanks Li , linux-mips@oss.sgi.com Subject: Re: Big endian problem References: <3BC72CCC.3604FEC8@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5035 Lines: 249 Hello Jun, The file is the common time.c from linux/arch/mips/kernel as you can see from the third to last line of Hanshi's email. The tools he is using are from H. J. Lu's RedHat 7.1 RPMs on the oss.sgi.com ftp site. The file compiles just fine with the little endian version of the same tools from the same place. Hanshi and I will look at the USECS_PER_JIFFY_FRAC macro. Thanks for the pointer. -- Dan A. Jun Sun wrote: > Which time.c is this? I have seen this problem caused by mis-defined > USECS_PER_JIFFY_FRAC macro. Look at other time.c files for the right one. > > Or better yet, upgrade your port to use the common time.c. See > Documantation/mips/time.README file. > > Jun > > Hanks Li wrote: > >>Hi, >> >>Has anyone tried to compile in Big Endian mode? When I compile the code in >>big endian, I got the following message. Does anybody know how to solve this >>problem? The assembler I'm using is "GNU assembler 2.11.90.0.27". I have no >>problem compiling the code in little endian at all. >> >>Thanks >> >>Hanshi Li >> >>---------------------------------------------------------------------------- >>------------------------------------ >>mips-linux-gcc -I >>/home/hli/linux/include/asm/gcc -D__KERNEL__ -I/home/hli/linux/include -Wall >> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-ali >>asing -fno-common -G >>0 -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe -DEXPORT_SYMTAB >> -c time.c >>Assembler messages: >>Warning: The -mcpu option is deprecated. Please use -march and -mtune >>instead. >>time.c: In function `calibrate_div32_gettimeoffset': >>time.c:225: Unrecognizable insn: >>(insn 60 144 66 (parallel[ >>(set (reg:SI 8 t0) >>(asm_operands (".set push >>.set noat >>.set noreorder >>b 1f >>li %4,0x21 >>0: >>sll $1,%0,0x1 >>srl %3,%0,0x1f >>or %0,$1,$2 >>sll %1,%1,0x1 >>sll %2,%2,0x1 >>1: >>bnez %3,2f >>sltu $2,%0,%z5 >>bnez $2,3f >>2: >>addiu %4,%4,-1 >>subu %0,%0,%z5 >>addiu %2,%2,1 >>3: >>bnez %4,0b >>srl $2,%1,0x1f >>.set pop") ("=&r") 0[ >>(reg/v:SI 4 a0) >>(reg:SI 8 t0) >>(reg:DI 6 a2) >>(reg/v:SI 5 a1) >>(reg:SI 9 t1) >>] >>[ >>(asm_input:SI ("Jr")) >>(asm_input:SI ("0")) >>(asm_input:DI ("1")) >>(asm_input:SI ("2")) >>(asm_input:SI ("3")) >>] ("time.c") 201)) >>(set (reg:SI 6 a2) >>(asm_operands (".set push >>.set noat >>.set noreorder >>b 1f >>li %4,0x21 >>0: >>sll $1,%0,0x1 >>srl %3,%0,0x1f >>or %0,$1,$2 >>sll %1,%1,0x1 >>sll %2,%2,0x1 >>1: >>bnez %3,2f >>sltu $2,%0,%z5 >>bnez $2,3f >>2: >>addiu %4,%4,-1 >>subu %0,%0,%z5 >>addiu %2,%2,1 >>3: >>bnez %4,0b >>srl $2,%1,0x1f >>.set pop") ("=&r") 1[ >>(reg/v:SI 4 a0) >>(reg:SI 8 t0) >>(reg:DI 6 a2) >>(reg/v:SI 5 a1) >>(reg:SI 9 t1) >>] >>[ >>(asm_input:SI ("Jr")) >>(asm_input:SI ("0")) >>(asm_input:DI ("1")) >>(asm_input:SI ("2")) >>(asm_input:SI ("3")) >>] ("time.c") 201)) >>(set (reg/v:SI 5 a1) >>(asm_operands (".set push >>.set noat >>.set noreorder >>b 1f >>li %4,0x21 >>0: >>sll $1,%0,0x1 >>srl %3,%0,0x1f >>or %0,$1,$2 >>sll %1,%1,0x1 >>sll %2,%2,0x1 >>1: >>bnez %3,2f >>sltu $2,%0,%z5 >>bnez $2,3f >>2: >>addiu %4,%4,-1 >>subu %0,%0,%z5 >>addiu %2,%2,1 >>3: >>bnez %4,0b >>srl $2,%1,0x1f >>.set pop") ("=&r") 2[ >>(reg/v:SI 4 a0) >>(reg:SI 8 t0) >>(reg:DI 6 a2) >>(reg/v:SI 5 a1) >>(reg:SI 9 t1) >>] >>[ >>(asm_input:SI ("Jr")) >>(asm_input:SI ("0")) >>(asm_input:DI ("1")) >>(asm_input:SI ("2")) >>(asm_input:SI ("3")) >>] ("time.c") 201)) >>(set (reg:SI 9 t1) >>(asm_operands (".set push >>.set noat >>.set noreorder >>b 1f >>li %4,0x21 >>0: >>sll $1,%0,0x1 >>srl %3,%0,0x1f >>or %0,$1,$2 >>sll %1,%1,0x1 >>sll %2,%2,0x1 >>1: >>bnez %3,2f >>sltu $2,%0,%z5 >>bnez $2,3f >>2: >>addiu %4,%4,-1 >>subu %0,%0,%z5 >>addiu %2,%2,1 >>3: >>bnez %4,0b >>srl $2,%1,0x1f >>.set pop") ("=&r") 3[ >>(reg/v:SI 4 a0) >>(reg:SI 8 t0) >>(reg:DI 6 a2) >>(reg/v:SI 5 a1) >>(reg:SI 9 t1) >>] >>[ >>(asm_input:SI ("Jr")) >>(asm_input:SI ("0")) >>(asm_input:DI ("1")) >>(asm_input:SI ("2")) >>(asm_input:SI ("3")) >>] ("time.c") 201)) >>(set (reg:SI 14 t6) >>(asm_operands (".set push >>.set noat >>.set noreorder >>b 1f >>li %4,0x21 >>0: >>sll $1,%0,0x1 >>srl %3,%0,0x1f >>or %0,$1,$2 >>sll %1,%1,0x1 >>sll %2,%2,0x1 >>1: >>bnez %3,2f >>sltu $2,%0,%z5 >>bnez $2,3f >>2: >>addiu %4,%4,-1 >>subu %0,%0,%z5 >>addiu %2,%2,1 >>3: >>bnez %4,0b >>srl $2,%1,0x1f >>.set pop") ("=&r") 4[ >>(reg/v:SI 4 a0) >>(reg:SI 8 t0) >>(reg:DI 6 a2) >>(reg/v:SI 5 a1) >>(reg:SI 9 t1) >>] >>[ >>(asm_input:SI ("Jr")) >>(asm_input:SI ("0")) >>(asm_input:DI ("1")) >>(asm_input:SI ("2")) >>(asm_input:SI ("3")) >>] ("time.c") 201)) >>(clobber (reg:QI 2 v0)) >>(clobber (reg:QI 1 at)) >>] ) -1 (insn_list:REG_DEP_OUTPUT 13 (insn_list 38 (insn_list 53 (insn_list >>51 (insn_list 41 (nil)))))) >>(nil)) >>time.c:225: confused by earlier errors, bailing out >>make[1]: *** [time.o] Error 1 >>make[1]: Leaving directory `/home/hli/linux/arch/mips/kernel' >>make: *** [_dir_arch/mips/kernel] Error 2 >>---------------------------------------------------------------------------- >>--------------------------------- >> From owner-linux-mips@oss.sgi.com Fri Oct 12 14:37:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9CLb2531149 for linux-mips-outgoing; Fri, 12 Oct 2001 14:37:02 -0700 Received: from dea.linux-mips.net (a1as05-p89.stg.tli.de [195.252.187.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9CLavD31146 for ; Fri, 12 Oct 2001 14:36:58 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9CLZxq02064; Fri, 12 Oct 2001 23:35:59 +0200 Date: Fri, 12 Oct 2001 23:35:59 +0200 From: Ralf Baechle To: Gerald Champagne Cc: Jun Sun , Geert Uytterhoeven , "linux-mips@oss.sgi.com" Subject: Re: Remove ifdefs from setup_arch() Message-ID: <20011012233559.A1799@dea.linux-mips.net> References: <3BC72BE8.F50C2001@mvista.com> <3BC732C9.9080508@esstech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BC732C9.9080508@esstech.com>; from gerald.champagne@esstech.com on Fri, Oct 12, 2001 at 01:13:29PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 890 Lines: 18 On Fri, Oct 12, 2001 at 01:13:29PM -0500, Gerald Champagne wrote: > Can you wrap this code into small functions like machine_detect() and > board_setup() and put it all in one place? That way those of us who > just want a simple system supporting only one board can just replace > those two functions with defines that alias the proper machine_detect > and board_setup fuctions. Then all of the special elf sections and > function pointers go away. > > If it's all in one place like this, then maybe it could be configured > in the config.in file. I can ifdef it out for boards like mine or other > boards that can't possibly support more than one system in a given binary > image. config.in could ifdef it in for configurations that could possibly > support more than one configuration in a given binary image. That would all be initcode / initdata so effective bloat zero. Ralf From owner-linux-mips@oss.sgi.com Fri Oct 12 17:36:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D0a4G01390 for linux-mips-outgoing; Fri, 12 Oct 2001 17:36:04 -0700 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D0ZwD01387 for ; Fri, 12 Oct 2001 17:35:58 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id RAA03766; Fri, 12 Oct 2001 17:35:52 -0700 Date: Fri, 12 Oct 2001 17:35:52 -0700 From: Jun Sun To: Dan Aizenstros Cc: Hanks Li , linux-mips@oss.sgi.com Subject: Re: Big endian problem Message-ID: <20011012173552.B3689@mvista.com> References: <3BC72CCC.3604FEC8@mvista.com> <3BC74EFE.9020109@quicklogic.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BC74EFE.9020109@quicklogic.com>; from dan@quicklogic.com on Fri, Oct 12, 2001 at 04:13:50PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2080 Lines: 66 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 12, 2001 at 04:13:50PM -0400, Dan Aizenstros wrote: > Hello Jun, > > The file is the common time.c from linux/arch/mips/kernel as you > can see from the third to last line of Hanshi's email. The tools > he is using are from H. J. Lu's RedHat 7.1 RPMs on the oss.sgi.com > ftp site. The file compiles just fine with the little endian version > of the same tools from the same place. > > Hanshi and I will look at the USECS_PER_JIFFY_FRAC macro. Thanks for > the pointer. > > -- Dan A. > It is indeed a strange problem as it only shows up in BE tools. Some tool gurus want to look into it? Meanwhile the following patch seems to fix it (and a couple of other time.c files) Jun --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="time_JIFFY_FRAC.patch" diff -Nru linux/arch/mips/dec/time.c.orig linux/arch/mips/dec/time.c --- linux/arch/mips/dec/time.c.orig Thu Aug 23 15:24:23 2001 +++ linux/arch/mips/dec/time.c Fri Oct 12 17:35:51 2001 @@ -8,6 +8,7 @@ * found in some MIPS systems. * */ +#include #include #include #include @@ -44,7 +45,7 @@ /* This is for machines which generate the exact clock. */ #define USECS_PER_JIFFY (1000000/HZ) -#define USECS_PER_JIFFY_FRAC ((1000000ULL << 32) / HZ & 0xffffffff) +#define USECS_PER_JIFFY_FRAC ((u32)((1000000ULL << 32) / HZ)) /* Cycle counter value at the previous timer interrupt.. */ diff -Nru linux/arch/mips/kernel/time.c.orig linux/arch/mips/kernel/time.c --- linux/arch/mips/kernel/time.c.orig Sat Oct 6 22:04:40 2001 +++ linux/arch/mips/kernel/time.c Fri Oct 12 17:35:17 2001 @@ -30,7 +30,7 @@ /* This is for machines which generate the exact clock. */ #define USECS_PER_JIFFY (1000000/HZ) -#define USECS_PER_JIFFY_FRAC ((1000000ULL << 32) / HZ & 0xffffffff) +#define USECS_PER_JIFFY_FRAC ((u32)((1000000ULL << 32) / HZ)) /* * forward reference --EeQfGwPcQSOJBaQU-- From owner-linux-mips@oss.sgi.com Fri Oct 12 17:56:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D0u1I01756 for linux-mips-outgoing; Fri, 12 Oct 2001 17:56:01 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D0txD01753 for ; Fri, 12 Oct 2001 17:55:59 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (SGI-8.9.3/8.9.3) with ESMTP id CAA47444 for ; Sat, 13 Oct 2001 02:55:50 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.32 #1 (Debian)) id 15sD5i-000717-00 for ; Sat, 13 Oct 2001 02:55:50 +0200 Date: Sat, 13 Oct 2001 02:55:50 +0200 To: linux-mips@oss.sgi.com Subject: Re: Big endian problem Message-ID: <20011013025550.B2413@rembrandt.csv.ica.uni-stuttgart.de> References: <3BC72CCC.3604FEC8@mvista.com> <3BC74EFE.9020109@quicklogic.com> <20011012173552.B3689@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011012173552.B3689@mvista.com> User-Agent: Mutt/1.3.22i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 345 Lines: 16 Jun Sun wrote: [snip] > > Hanshi and I will look at the USECS_PER_JIFFY_FRAC macro. Thanks for > > the pointer. > > > > -- Dan A. > > > > It is indeed a strange problem as it only shows up in BE tools. > Some tool gurus want to look into it? I use the BE CVS tools and haven't seen this. How does the preprocessed code look like? Thiemo From owner-linux-mips@oss.sgi.com Fri Oct 12 22:54:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9D5slc06448 for linux-mips-outgoing; Fri, 12 Oct 2001 22:54:47 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9D5seD06445 for ; Fri, 12 Oct 2001 22:54:40 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 14936125C0; Fri, 12 Oct 2001 22:54:33 -0700 (PDT) Date: Fri, 12 Oct 2001 22:54:33 -0700 From: "H . J . Lu" To: Jun Sun Cc: Dan Aizenstros , Hanks Li , linux-mips@oss.sgi.com Subject: Re: Big endian problem Message-ID: <20011012225433.A10523@lucon.org> References: <3BC72CCC.3604FEC8@mvista.com> <3BC74EFE.9020109@quicklogic.com> <20011012173552.B3689@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: <20011012173552.B3689@mvista.com>; from jsun@mvista.com on Fri, Oct 12, 2001 at 05:35:52PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 845 Lines: 28 On Fri, Oct 12, 2001 at 05:35:52PM -0700, Jun Sun wrote: > On Fri, Oct 12, 2001 at 04:13:50PM -0400, Dan Aizenstros wrote: > > Hello Jun, > > > > The file is the common time.c from linux/arch/mips/kernel as you > > can see from the third to last line of Hanshi's email. The tools > > he is using are from H. J. Lu's RedHat 7.1 RPMs on the oss.sgi.com > > ftp site. The file compiles just fine with the little endian version > > of the same tools from the same place. > > > > Hanshi and I will look at the USECS_PER_JIFFY_FRAC macro. Thanks for > > the pointer. > > > > -- Dan A. > > > > It is indeed a strange problem as it only shows up in BE tools. > Some tool gurus want to look into it? > > Meanwhile the following patch seems to fix it (and a couple of other > time.c files) > > Jun This is what I sent out in July. H.J. ---- From hjl@lucon.org Tue Jul 24 13:25:34 2001 Date: Tue, 24 Jul 2001 13:25:34 -0700 From: "H . J . Lu" To: Marc Karasek Cc: linux-mips@oss.sgi.com Subject: Re: GCC and Modules Message-ID: <20010724132534.A25416@lucon.org> References: <25369470B6F0D41194820002B328BDD27D2E@ATLOPS> <20010724085544.A20610@lucon.org> <995995907.1331.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <995995907.1331.5.camel@localhost.localdomain>; from marc_karasek@ivivity.com on Tue, Jul 24, 2001 at 01:31:41PM -0400 Status: RO Content-Length: 954 Lines: 29 On Tue, Jul 24, 2001 at 01:31:41PM -0400, Marc Karasek wrote: > The way to see this bug is just try to compile the MIPS kernel (either > 2.4.1 or 2.4.3) as follows: > > 1) make distclean > 2) copy linux/arch/mips/defconfig-malta linux/.config > 3) make oldconfig > 4) make menuconfig > 5) change the endianess from little to big > 6) make dep > 7) make zImage > That is a kernel bug. The code only works on littl endian by accident Here is a patch. H.J. --- arch/mips/mips-boards/generic/time.c.int64 Tue Jul 24 13:21:21 2001 +++ arch/mips/mips-boards/generic/time.c Tue Jul 24 13:22:02 2001 @@ -275,7 +275,7 @@ void __init time_init(void) /* This is for machines which generate the exact clock. */ #define USECS_PER_JIFFY (1000000/HZ) -#define USECS_PER_JIFFY_FRAC (0x100000000*1000000/HZ&0xffffffff) +#define USECS_PER_JIFFY_FRAC ((long) (0x100000000*1000000/HZ&0xffffffff)) /* Cycle counter value at the previous timer interrupt.. */ From owner-linux-mips@oss.sgi.com Sat Oct 13 14:02:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DL2gI19574 for linux-mips-outgoing; Sat, 13 Oct 2001 14:02:42 -0700 Received: from serio.al.rim.or.jp (serio.al.rim.or.jp [202.247.191.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DL2bD19570 for ; Sat, 13 Oct 2001 14:02:38 -0700 Received: from mail2.rim.or.jp by serio.al.rim.or.jp (3.7W/HMX-13) id GAA09639 for ; Sun, 14 Oct 2001 06:02:36 +0900 (JST) Received: from speedwin (speed.galaxies.jp [211.8.151.62]) by mail2.rim.or.jp (8.9.3/3.7W) id GAA14605 for ; Sun, 14 Oct 2001 06:02:35 +0900 (JST) From: "Yoshi-K" To: Subject: MySQL Date: Sun, 14 Oct 2001 06:02:35 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011012225433.A10523@lucon.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1539 Lines: 45 hello. As for everybody, does MySQL operate without trouble? OS: PS2 Linux. CPU: R5900 gcc 2.95.2 glibc 2.2.2 $ uname -a Linux speed-ps 2.2.1 #94 Thu Apr 19 12:13:01 JST 2001 mips unknown # cd mysql-3.23.42 # ./configure --with-charset=ujis --with-mysqld-user=mysql # make;make install # chown -R mysql.mysql /usr/local/var # /usr/local/bin/mysql_install_db --user=mysql Preparing db table Preparing host table Preparing user table Preparing func table Preparing tables_priv table Preparing columns_priv table Installing all prepared tables ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' ERROR: 1033 Incorrect information in file: './mysql/db.frm' 011006 21:20:23 /usr/local/libexec/mysqld: Shutdown Complete ------------------------- Yoshikatsu Kida E-Mail: yoshi@galaxies.jp http://galaxies.jp/ From owner-linux-mips@oss.sgi.com Sat Oct 13 19:00:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E20m424723 for linux-mips-outgoing; Sat, 13 Oct 2001 19:00:48 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E20cD24718 for ; Sat, 13 Oct 2001 19:00:39 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id E1499125C0; Sat, 13 Oct 2001 19:00:34 -0700 (PDT) Date: Sat, 13 Oct 2001 19:00:34 -0700 From: "H . J . Lu" To: "Leonard N. Zubkoff" Cc: binutils@sourceware.cygnus.com, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , linux-gcc@vger.kernel.org, amodra@bigpond.net.au Subject: binutils 2.11.92.0.5 is broke (Re: Binutils Bug) Message-ID: <20011013190034.A27019@lucon.org> References: <200110131452.f9DEq7Q0032358@dandelion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110131452.f9DEq7Q0032358@dandelion.com>; from lnz@dandelion.com on Sat, Oct 13, 2001 at 07:52:07AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 886 Lines: 36 On Sat, Oct 13, 2001 at 07:52:07AM -0700, Leonard Zubkoff wrote: > HJ, > > In recompiling my whole system with your latest binutils-2.11.92.0.5, I > received the following error while linking telnetd from the netkit-telnet-0.17 > package: > > gcc telnetd.o state.o termstat.o slc.o sys_term.o utility.o global.o setproctitle.o -lutil -lutil -o telnetd > /usr/bin/ld: BFD internal error, aborting at elf32-i386.c line 646 in elf_i386_copy_indirect_symbol > > /usr/bin/ld: Please report this bug. > > collect2: ld returned 1 exit status > > Thought you'd want to know... > Hi Alan, This patch http://sources.redhat.com/ml/binutils/2001-10/msg00035.html is incomplete. You cannot do any backend processing when if (dir == ind->weakdef) I will double check all backend xxx_hash_copy_indirect. I am planning to make binutils 2.11.92.0.6 within a week. Sorry for that. H.J. From owner-linux-mips@oss.sgi.com Sat Oct 13 23:56:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E6utx29067 for linux-mips-outgoing; Sat, 13 Oct 2001 23:56:55 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E6uUD29061 for ; Sat, 13 Oct 2001 23:56:30 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 0EAAA125C0; Sat, 13 Oct 2001 23:56:24 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 3C6A4EBA5; Sat, 13 Oct 2001 23:56:21 -0700 (PDT) Date: Sat, 13 Oct 2001 23:56:21 -0700 From: "H . J . Lu" To: "Leonard N. Zubkoff" Cc: binutils@sourceware.cygnus.com, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , "Steven J. Hill" , linux-gcc@vger.kernel.org, amodra@bigpond.net.au Subject: binutils 2.11.92.0.6 (Re: binutils 2.11.92.0.5 is broken) Message-ID: <20011013235621.A15807@lucon.org> References: <200110131452.f9DEq7Q0032358@dandelion.com> <20011013190034.A27019@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011013190034.A27019@lucon.org>; from hjl@lucon.org on Sat, Oct 13, 2001 at 07:00:34PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9209 Lines: 268 On Sat, Oct 13, 2001 at 07:00:34PM -0700, H . J . Lu wrote: > On Sat, Oct 13, 2001 at 07:52:07AM -0700, Leonard Zubkoff wrote: > > HJ, > > > > In recompiling my whole system with your latest binutils-2.11.92.0.5, I > > received the following error while linking telnetd from the netkit-telnet-0.17 > > package: > > > > gcc telnetd.o state.o termstat.o slc.o sys_term.o utility.o global.o setproctitle.o -lutil -lutil -o telnetd > > /usr/bin/ld: BFD internal error, aborting at elf32-i386.c line 646 in elf_i386_copy_indirect_symbol > > > > /usr/bin/ld: Please report this bug. > > > > collect2: ld returned 1 exit status > > > > Thought you'd want to know... > > > > Hi Alan, > > This patch > > http://sources.redhat.com/ml/binutils/2001-10/msg00035.html > > is incomplete. You cannot do any backend processing when > > if (dir == ind->weakdef) > > I will double check all backend xxx_hash_copy_indirect. > > I am planning to make binutils 2.11.92.0.6 within a week. > > Sorry for that. > > Here is a proposed patch for binutils 2.11.92.0.6. I will run more tests before releasing it. Please test it as much as you can. Thanks. H.J. --- 2001-10-13 H.J. Lu * elf32-hppa.c (elf32_hppa_copy_indirect_symbol): Don't abort if this is a weakdef. * elf32-i386.c (elf_i386_copy_indirect_symbol): Likewise. * elf64-ppc.c (ppc64_elf_copy_indirect_symbol): Likewise. * elf32-ppc.c (ppc_elf_adjust_dynamic_symbol): Set plt.offset to -1 and clear the ELF_LINK_HASH_NEEDS_PLT bit if the symbol is not a function. * elf32-hppa.c (elf32_hppa_adjust_dynamic_symbol): Likewise. * elf32-s390.c (elf_s390_adjust_dynamic_symbol): Likewise. * elf64-s390.c (elf_s390_adjust_dynamic_symbol): Likewise. * elf64-x86-64.c (elf64_x86_64_adjust_dynamic_symbol): Likewise. Index: elf32-hppa.c =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elf32-hppa.c,v retrieving revision 1.41 diff -u -p -r1.41 elf32-hppa.c --- elf32-hppa.c 2001/10/03 15:55:57 1.41 +++ elf32-hppa.c 2001/10/14 06:43:23 @@ -1147,7 +1147,7 @@ elf32_hppa_copy_indirect_symbol (dir, in edir->dyn_relocs = eind->dyn_relocs; eind->dyn_relocs = NULL; } - else if (eind->dyn_relocs != NULL) + else if (dir != ind->weakdef && eind->dyn_relocs != NULL) abort (); _bfd_elf_link_hash_copy_indirect (dir, ind); @@ -1843,6 +1843,11 @@ elf32_hppa_adjust_dynamic_symbol (info, } return true; + } + else + { + h->plt.offset = (bfd_vma) -1; + h->elf_link_hash_flags &= ~ELF_LINK_HASH_NEEDS_PLT; } /* If this is a weak symbol, and there is a real definition, the Index: elf32-i386.c =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elf32-i386.c,v retrieving revision 1.42 diff -u -p -r1.42 elf32-i386.c --- elf32-i386.c 2001/10/03 15:55:57 1.42 +++ elf32-i386.c 2001/10/14 06:36:15 @@ -642,7 +642,7 @@ elf_i386_copy_indirect_symbol (dir, ind) edir->dyn_relocs = eind->dyn_relocs; eind->dyn_relocs = NULL; } - else if (eind->dyn_relocs != NULL) + else if (dir != ind->weakdef && eind->dyn_relocs != NULL) abort (); _bfd_elf_link_hash_copy_indirect (dir, ind); Index: elf32-mips.c =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elf32-mips.c,v retrieving revision 1.46 retrieving revision 1.47 diff -u -p -r1.46 -r1.47 --- elf32-mips.c 2001/10/05 20:31:11 1.46 +++ elf32-mips.c 2001/10/11 18:15:44 1.47 @@ -6319,8 +6319,10 @@ mips_elf_calculate_relocation (abfd, if ((info->shared || (elf_hash_table (info)->dynamic_sections_created && h != NULL - && ((h->root.elf_link_hash_flags & ELF_LINK_HASH_DEF_DYNAMIC) - != 0))) + && ((h->root.elf_link_hash_flags + & ELF_LINK_HASH_DEF_DYNAMIC) != 0) + && ((h->root.elf_link_hash_flags + & ELF_LINK_HASH_DEF_REGULAR) == 0))) && (input_section->flags & SEC_ALLOC) != 0) { /* If we're creating a shared library, or this relocation is Index: elf32-ppc.c =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elf32-ppc.c,v retrieving revision 1.23 diff -u -p -r1.23 elf32-ppc.c --- elf32-ppc.c 2001/10/07 23:29:41 1.23 +++ elf32-ppc.c 2001/10/14 05:58:40 @@ -1797,6 +1797,11 @@ ppc_elf_adjust_dynamic_symbol (info, h) return true; } + else + { + h->plt.offset = (bfd_vma) -1; + h->elf_link_hash_flags &= ~ELF_LINK_HASH_NEEDS_PLT; + } /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: elf32-s390.c =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elf32-s390.c,v retrieving revision 1.1.1.8 diff -u -p -r1.1.1.8 elf32-s390.c --- elf32-s390.c 2001/09/29 16:26:18 1.1.1.8 +++ elf32-s390.c 2001/10/14 06:09:42 @@ -998,6 +998,11 @@ elf_s390_adjust_dynamic_symbol (info, h) return true; } + else + { + h->plt.offset = (bfd_vma) -1; + h->elf_link_hash_flags &= ~ELF_LINK_HASH_NEEDS_PLT; + } /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: elf64-ppc.c =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elf64-ppc.c,v retrieving revision 1.1.1.5 diff -u -p -r1.1.1.5 elf64-ppc.c --- elf64-ppc.c 2001/10/03 15:30:41 1.1.1.5 +++ elf64-ppc.c 2001/10/14 06:36:37 @@ -1799,7 +1799,7 @@ ppc64_elf_copy_indirect_symbol (dir, ind edir->dyn_relocs = eind->dyn_relocs; eind->dyn_relocs = NULL; } - else if (eind->dyn_relocs != NULL) + else if (dir != ind->weakdef && eind->dyn_relocs != NULL) abort (); _bfd_elf_link_hash_copy_indirect (dir, ind); Index: elf64-s390.c =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elf64-s390.c,v retrieving revision 1.1.1.8 diff -u -p -r1.1.1.8 elf64-s390.c --- elf64-s390.c 2001/09/29 16:26:20 1.1.1.8 +++ elf64-s390.c 2001/10/14 06:10:26 @@ -976,6 +976,11 @@ elf_s390_adjust_dynamic_symbol (info, h) return true; } + else + { + h->plt.offset = (bfd_vma) -1; + h->elf_link_hash_flags &= ~ELF_LINK_HASH_NEEDS_PLT; + } /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: elf64-x86-64.c =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elf64-x86-64.c,v retrieving revision 1.1.1.22 diff -u -p -r1.1.1.22 elf64-x86-64.c --- elf64-x86-64.c 2001/09/29 16:26:21 1.1.1.22 +++ elf64-x86-64.c 2001/10/14 06:10:46 @@ -854,6 +854,11 @@ elf64_x86_64_adjust_dynamic_symbol (info return true; } + else + { + h->plt.offset = (bfd_vma) -1; + h->elf_link_hash_flags &= ~ELF_LINK_HASH_NEEDS_PLT; + } /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: elflink.h =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v retrieving revision 1.82 retrieving revision 1.83 diff -u -p -r1.82 -r1.83 --- elflink.h 2001/10/05 20:32:13 1.82 +++ elflink.h 2001/10/11 18:15:44 1.83 @@ -909,8 +909,11 @@ elf_merge_symbol (abfd, info, name, sym, As above, we again permit a common symbol in a regular object to override a definition in a shared object if the shared object - symbol is a function or is weak. */ + symbol is a function or is weak. + As above, we permit a non-weak definition in a shared object to + override a weak definition in a regular object. */ + if (! newdyn && (newdef || (bfd_is_com_section (sec) @@ -919,7 +922,8 @@ elf_merge_symbol (abfd, info, name, sym, && olddyn && olddef && (h->elf_link_hash_flags & ELF_LINK_HASH_DEF_DYNAMIC) != 0 - && bind != STB_WEAK) + && (bind != STB_WEAK + || h->root.type == bfd_link_hash_defweak)) { /* Change the hash table entry to undefined, and let _bfd_generic_link_add_one_symbol do the right thing with the @@ -1022,13 +1026,14 @@ elf_merge_symbol (abfd, info, name, sym, *sym_hash = h; } - /* Handle the special case of a definition in a shared object - followed by a weak definition in a regular object. In this case - we prefer to definition in the shared object. To make this work - we have to tell the caller to not treat the new symbol as a - definition. */ + /* Handle the special case of a non-weak definition in a shared + object followed by a weak definition in a regular object. In + this case we prefer to definition in the shared object. To make + this work we have to tell the caller to not treat the new symbol + as a definition. */ if (olddef && olddyn + && h->root.type != bfd_link_hash_defweak && newdef && ! newdyn && bind == STB_WEAK) From owner-linux-mips@oss.sgi.com Sat Oct 13 23:59:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9E6xZX29153 for linux-mips-outgoing; Sat, 13 Oct 2001 23:59:35 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9E6xRD29149 for ; Sat, 13 Oct 2001 23:59:28 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 91DEF125C0; Sat, 13 Oct 2001 23:59:24 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 826B6EBA5; Sat, 13 Oct 2001 23:59:24 -0700 (PDT) Date: Sat, 13 Oct 2001 23:59:24 -0700 From: "H . J . Lu" To: "Leonard N. Zubkoff" Cc: binutils@sourceware.cygnus.com, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , "Steven J. Hill" , linux-gcc@vger.kernel.org, amodra@bigpond.net.au Subject: Re: binutils 2.11.92.0.6 (Re: binutils 2.11.92.0.5 is broken) Message-ID: <20011013235924.C15807@lucon.org> References: <200110131452.f9DEq7Q0032358@dandelion.com> <20011013190034.A27019@lucon.org> <20011013235621.A15807@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011013235621.A15807@lucon.org>; from hjl@lucon.org on Sat, Oct 13, 2001 at 11:56:21PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2309 Lines: 78 On Sat, Oct 13, 2001 at 11:56:21PM -0700, H . J . Lu wrote: > On Sat, Oct 13, 2001 at 07:00:34PM -0700, H . J . Lu wrote: > > On Sat, Oct 13, 2001 at 07:52:07AM -0700, Leonard Zubkoff wrote: > > > HJ, > > > > > > In recompiling my whole system with your latest binutils-2.11.92.0.5, I > > > received the following error while linking telnetd from the netkit-telnet-0.17 > > > package: > > > > > > gcc telnetd.o state.o termstat.o slc.o sys_term.o utility.o global.o setproctitle.o -lutil -lutil -o telnetd > > > /usr/bin/ld: BFD internal error, aborting at elf32-i386.c line 646 in elf_i386_copy_indirect_symbol > > > > > > /usr/bin/ld: Please report this bug. > > > > > > collect2: ld returned 1 exit status > > > > > > Thought you'd want to know... > > > > > > > Hi Alan, > > > > This patch > > > > http://sources.redhat.com/ml/binutils/2001-10/msg00035.html > > > > is incomplete. You cannot do any backend processing when > > > > if (dir == ind->weakdef) > > > > I will double check all backend xxx_hash_copy_indirect. > > > > I am planning to make binutils 2.11.92.0.6 within a week. > > > > Sorry for that. > > > > > > Here is a proposed patch for binutils 2.11.92.0.6. I will run more > tests before releasing it. Please test it as much as you can. > > Thanks. > > > H.J. > --- Ooops. Here is the complete changelog against 2.11.92.0.5. H.J. ---- 2001-10-13 H.J. Lu * elf32-hppa.c (elf32_hppa_copy_indirect_symbol): Don't abort if this is a weakdef. * elf32-i386.c (elf_i386_copy_indirect_symbol): Likewise. * elf64-ppc.c (ppc64_elf_copy_indirect_symbol): Likewise. * elf32-ppc.c (ppc_elf_adjust_dynamic_symbol): Set plt.offset to -1 and clear the ELF_LINK_HASH_NEEDS_PLT bit if the symbol is not a function. * elf32-hppa.c (elf32_hppa_adjust_dynamic_symbol): Likewise. * elf32-s390.c (elf_s390_adjust_dynamic_symbol): Likewise. * elf64-s390.c (elf_s390_adjust_dynamic_symbol): Likewise. * elf64-x86-64.c (elf64_x86_64_adjust_dynamic_symbol): Likewise. 2001-10-11 H.J. Lu * elf32-mips.c (mips_elf_calculate_relocation): Don't create dynamic relocation for symbols defined in regular objects when creating executables. 2001-10-11 H.J. Lu * elflink.h (elf_merge_symbol): Revert the change made on 2001-10-03. From owner-linux-mips@oss.sgi.com Sun Oct 14 09:30:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EGUw311879 for linux-mips-outgoing; Sun, 14 Oct 2001 09:30:58 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EGUtD11876 for ; Sun, 14 Oct 2001 09:30:56 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id D1558125C3; Sun, 14 Oct 2001 09:30:54 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 0B7B0EBA6; Sun, 14 Oct 2001 09:30:52 -0700 (PDT) Date: Sun, 14 Oct 2001 09:30:52 -0700 From: "H . J . Lu" To: Yoshi-K Cc: linux-mips@oss.sgi.com Subject: Re: MySQL Message-ID: <20011014093052.B2374@lucon.org> References: <20011012225433.A10523@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ykida@yk.rim.or.jp on Sun, Oct 14, 2001 at 06:02:35AM +0900 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 349 Lines: 17 On Sun, Oct 14, 2001 at 06:02:35AM +0900, Yoshi-K wrote: > hello. > As for everybody, does MySQL operate without trouble? > > OS: PS2 Linux. > CPU: R5900 > gcc 2.95.2 > glibc 2.2.2 > $ uname -a > Linux speed-ps 2.2.1 #94 Thu Apr 19 12:13:01 JST 2001 mips unknown > I ported mysql 3.23.36 to mips II and above in my RedHat 7.1 for mips. H.J. From owner-linux-mips@oss.sgi.com Sun Oct 14 14:01:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EL1qi16722 for linux-mips-outgoing; Sun, 14 Oct 2001 14:01:52 -0700 Received: from dea.linux-mips.net (a1as17-p71.stg.tli.de [195.252.193.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EL1mD16718 for ; Sun, 14 Oct 2001 14:01:48 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9EL1UT03711; Sun, 14 Oct 2001 23:01:30 +0200 Date: Sun, 14 Oct 2001 23:01:30 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: Yoshi-K , linux-mips@oss.sgi.com Subject: Re: MySQL Message-ID: <20011014230130.A3614@dea.linux-mips.net> References: <20011012225433.A10523@lucon.org> <20011014093052.B2374@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011014093052.B2374@lucon.org>; from hjl@lucon.org on Sun, Oct 14, 2001 at 09:30:52AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 558 Lines: 21 On Sun, Oct 14, 2001 at 09:30:52AM -0700, H . J . Lu wrote: > > hello. > > As for everybody, does MySQL operate without trouble? > > > > OS: PS2 Linux. > > CPU: R5900 > > gcc 2.95.2 > > glibc 2.2.2 > > $ uname -a > > Linux speed-ps 2.2.1 #94 Thu Apr 19 12:13:01 JST 2001 mips unknown > > > > I ported mysql 3.23.36 to mips II and above in my RedHat 7.1 for > mips. I assume MIPS II means you're using ll/sc in the locking code in the MySQL. Now that the ll/sc emulation is finally fixed these instructions will also work for ll/sc-less CPUs. Ralf From owner-linux-mips@oss.sgi.com Sun Oct 14 17:03:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F03fe19946 for linux-mips-outgoing; Sun, 14 Oct 2001 17:03:41 -0700 Received: from mailin5.bigpond.com (mailin5.bigpond.com [139.134.6.78] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F03YD19943 for ; Sun, 14 Oct 2001 17:03:34 -0700 Received: from bubble.local ([144.135.24.75]) by mailin5.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GL80GF00.9KO for ; Mon, 15 Oct 2001 10:09:51 +1000 Received: from 144.136.192.57 ([144.136.192.57]) by bwmam03.mailsvc.email.bigpond.com(MailRouter V2.9k 8323/2994302); 15 Oct 2001 10:09:45 Received: (qmail 11758 invoked by uid 179); 15 Oct 2001 00:03:17 -0000 Date: Mon, 15 Oct 2001 09:33:17 +0930 From: Alan Modra To: "H . J . Lu" Cc: "Leonard N. Zubkoff" , binutils@sourceware.cygnus.com, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , "Steven J. Hill" , linux-gcc@vger.kernel.org Subject: Re: binutils 2.11.92.0.6 (Re: binutils 2.11.92.0.5 is broken) Message-ID: <20011015093317.B1015@bubble.sa.bigpond.net.au> Mail-Followup-To: "H . J . Lu" , "Leonard N. Zubkoff" , binutils@sourceware.cygnus.com, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , "Steven J. Hill" , linux-gcc@vger.kernel.org References: <200110131452.f9DEq7Q0032358@dandelion.com> <20011013190034.A27019@lucon.org> <20011013235621.A15807@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20011013235621.A15807@lucon.org>; from hjl@lucon.org on Sat, Oct 13, 2001 at 11:56:21PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2342 Lines: 76 On Sat, Oct 13, 2001 at 11:56:21PM -0700, H . J . Lu wrote: > > Hi Alan, > > > > This patch > > > > http://sources.redhat.com/ml/binutils/2001-10/msg00035.html > > > > is incomplete. You cannot do any backend processing when Err, yes. Thanks for looking into it, HJ. I've been away this weekend, which is why it appears that I've been ignoring the problem. > Index: elf32-hppa.c > =================================================================== > RCS file: /work/cvs/gnu/binutils/bfd/elf32-hppa.c,v > retrieving revision 1.41 > diff -u -p -r1.41 elf32-hppa.c > --- elf32-hppa.c 2001/10/03 15:55:57 1.41 > +++ elf32-hppa.c 2001/10/14 06:43:23 > @@ -1147,7 +1147,7 @@ elf32_hppa_copy_indirect_symbol (dir, in > edir->dyn_relocs = eind->dyn_relocs; > eind->dyn_relocs = NULL; > } > - else if (eind->dyn_relocs != NULL) > + else if (dir != ind->weakdef && eind->dyn_relocs != NULL) I suspect this is not the correct fix. dyn_relocs is being used to count relocs, and probably what should happen is something like else if (eind->dyn_relocs != NULL) { struct elf32_hppa_dyn_reloc_entry *p; if (edir != eind->elf.weakdef) abort (); /* Add reloc counts against the weak sym to the strong sym list. Entries on the eind list should have a different p->sec from any on the dir list, so we don't need to merge entries. */ for (p = eind->dyn_relocs; p->next != NULL; p = p->next) ; p->next = edir->dyn_relocs; edir->dyn_relocs = eind->dyn_relocs; eind->dyn_relocs = NULL; } Untested as yet, because I don't have a testcase. I'll see if I can dream one up. > abort (); > > _bfd_elf_link_hash_copy_indirect (dir, ind); > @@ -1843,6 +1843,11 @@ elf32_hppa_adjust_dynamic_symbol (info, > } > > return true; > + } > + else > + { > + h->plt.offset = (bfd_vma) -1; > + h->elf_link_hash_flags &= ~ELF_LINK_HASH_NEEDS_PLT; > } This part is corrent, and similarly for the other architectures. > --- elflink.h 2001/10/05 20:32:13 1.82 > +++ elflink.h 2001/10/11 18:15:44 1.83 > + As above, we permit a non-weak definition in a shared object to > + override a weak definition in a regular object. */ I don't disagree with this change, but has this been discussed sufficiently here and on the glibc list? Alan From owner-linux-mips@oss.sgi.com Sun Oct 14 21:17:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F4H9B25711 for linux-mips-outgoing; Sun, 14 Oct 2001 21:17:09 -0700 Received: from [211.161.16.48] (sj18-176.dialup.seed.net.tw [211.74.18.176]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F4GiD25706 for ; Sun, 14 Oct 2001 21:16:45 -0700 Date: Sun, 14 Oct 2001 21:16:45 -0700 Received: from 91scn by [211.161.141.48] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 15 Oct 2001 00:58:02 +0800 Received: from login_0246.mailservice.net (mx.service.net[206.212.231.77] (may be forged)) by [212.201.122.247] (8.8.5/8.7.3) with SMTP id XAA05637 for ; ŹP´Á¤@, 15 ¤Q¤ë 2001 01:26:47 -0700 (EDT) To: From: Subject: ŻuŞşĄIľLąřĽó°eąz¤âž÷ťPŞů¸š Reply-To: sample@mailservice.net X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.262 Comments: Authenticated Sender is Message-Id: <94684699_88790458> X-MDaemon-Deliver-To: linux-mips@oss.sgi.com X-Return-Path: e82_2vgkalf3lycv@misys.co.uk Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2131 Lines: 126 §Ú­ĚĂŘ°eąz¤âž÷+Şů¸šĄIĄIĄIĄIĄI ¨SżůĄIĄI§Ú­ĚĂŘ°eąz¤âž÷+Şů¸šĄIĄIĄIĄIĄI łoľ´šďŹOŻušęŞşĄI ˝Đ¤Ł­nŚAĂhşĂ¤FĄIĄI §Ú­ĚŠMąz¤@źËŹOľ˝¨}ĄBĽżŞ˝ŞşŚŃŚĘŠmĄIĄI Ťô°UĄIĄI Ťô°UĄIĄI˝Đ¤Ł­nŚAĂhşĂ§Ú­ĚĄIĄIĄIĄI ¤]˝Đ¤Ł­nŚAĽ´šq¸Ü¸ß°ÝŠMŤHšq°T¤FĄA ło­ÓĂŘ°e¤čŽ×ťPŠMŤHšq°T¨SŚłĂöŤYĄI §Ú­ĚŹOąś°\Ľřˇ~şŢ˛zĹU°ÝŚł­­¤˝ĽqĄA ŹO§Ú­ĚĂŘ°eąz¤âž÷+Şů¸šĄA¤ŁŹOŠMŤHšq°TĄC ŠŇĂŘ°e¤§§KśO¤čŽ×Śp¤UĄG Şů¸šĄG ŠMŤHŞů¸š łq¸ÜśO­pśO¤čŽ×ĄG ŠMŤHşëşâ188 ĂŘ°e¤âž÷ĄG MOTOROLA T2288Ą]­^¤ĺž÷Ą^ şëşâ188¤ëŻ˛śOĄG 188¤¸ §KśOłq¸ÜĄG Šč188¤¸¤ëŻ˛śO ¤@ŻëŽÉŹqĄG 0.16¤¸/ŹíĄAśg¤@ŚÜśg¤éĽţ¤é ´îťůŽÉŹqĄG ŚP¤@ŻëŽÉŹqŚŹśO Ľťşô¤ŹĽ´ĄG 0.08¤¸/ŹíĄ]ĽbťůĄ^ Ą]şëşâ188­pśO¤čŚĄšďĽôŚóŠMŤH¨ĎĽÎŞĚŹŇŹŰŚPĄ^ ĽtŚłŚXşâĽIśO¤čŽ×Śp¤UĄG Şů¸šĄG ŠMŤHŞů¸š łq¸ÜśO­pśO¤čŽ×ĄG ŠMŤHŤ˘ŠÔ900 ¤âž÷ĄG Nokia 3310Ą]¤¤¤ĺž÷Ą^ ĽÓ˝ĐŚš´Ú¤âž÷ťÝĽIśO888¤¸ĄA ¤ńŚb¤@Żëłq°TŚćĽÓ˝ĐĄAŤKŠy1000¤¸ĽH¤W Ť˘ŠÔ900¤ëŻ˛śOĄG 900¤¸ ¨C¤ë§KśOłq¸Ü¤ŔÄÁĄG 200¤ŔÄÁ ¤@ŻëŽÉŹq 0.11¤¸/Źí ´îťůŽÉŹq 0.11¤¸/Źí şô¤ş¤Źźˇ ¨CłqŤe5¤ŔÄÁ¤ş§KśOĄF śWšLłĄĽ÷ĄG1¤¸/¤ŔĄA ĽźşĄ1¤ŔÄÁĽH1¤ŔÄÁ­p Ą]Ť˘ŠÔ900­pśO¤čŚĄšďĽôŚóŠMŤH¨ĎĽÎŞĚŹŇŹŰŚPĄ^ ˝ĐŞ`ˇNĄGŤ˘°Ő900¨C¤ë§KśOłq¸Ü¤ŔÄÁźĆĄAˇí¤ëĽźĽÎ§šŞşĄA ¤ŁąoťźŠľ¨ě¤U­Ó¤ë¨ĎĽÎĄC Ť˘°Ő900¤§¨C¤ë§KśOłq¸Ü¤§200¤ŔÄÁ¤Ł§tşô¤ş¤ŹźˇĄC Ť˘°Ő900ŠMŤHşô¤ş¤ŹźˇŚł§KśOłWŠwĄA şëşâ188şô¤ş¤ŹźˇŚłĽbťůłWŠwĄA łĚžAŚXą`ą`ŹŰ¤ŹÁpľ¸ŞşŞB¤Í­Ě¤@°_ĽÓ˝ĐĄC şëşâ188ťPŤ˘°Ő900¤§Şů¸š¨ĎĽÎ´Á­­łWŠwŹ°ŚÜ¤Ö¨âŚ~ĄA ťPŚb¤@Żëłq°TŚćĽÓ˝ĐŹŰŚPĄC ¤éŤáŞşłq¸ÜśOĄAązĽiŚbŠMŤHŞůĽŤĄB7-11ĄBś×´ÚĄBšşźˇ..ľĽľĽĂşŻÇĄA ˇíľM¤]ĽiĽŃŠMŤHšq°TąÄťČŚćąb¸šŚŰ°ĘŚŠ´Ú¤čŚĄĄC Ą]¨C¤ëłq¸ÜśOĽIśO¤čŚĄšďĽôŚóŠMŤH¨ĎĽÎŞĚŹŇŹŰŚPĄ^ ĽÓ˝ĐŞů¸šŠŇťÝĂŇĽó 1.ązťÝˇÇłĆ¨­Ľ÷ĂŇźvĽťĄ]Ľż¤Ď­ąĄ^ 2.ťČŚćŚsşPŤĘ­ąźvĽťĄ]ťP¨­Ľ÷ĂŇŹŰŚPŚWŚrĄ^ 3.ŤKłš¤@ÁűĄ]ťP¨­Ľ÷ĂŇźvĽťŚWŚrŹŰŚPĄA¤ŁťÝ­nŚLŲĂŇŠúšĎłšĄ^ Ą]Şů¸šĽÓ˝Đ¤čŚĄšďĽôŚóŠMŤH¨ĎĽÎŞĚŹŇŹŰŚPĄ^ ĽÓ˝ĐŹů¤@ŹP´ÁŤáĄAŤKĽi¨ĎĽÎĄC ŚP¤@­ÓŚWŚrĄAłĚŚhĽÓ˝Đ3­ÓŞů¸š+3­Ó¤âž÷ ŹOŻuŞş˝ĐŹŰŤHĄI ľLąřĽó°eąz¤âž÷ťPŠMŤHšq°TŞů¸šĄI ŚpżďžÜ§KśO¤čŽ×ĄAąz¤ŁĽ˛ĽXĽôŚóĽb¤ňżúĄA§YĽižÖŚł¤âž÷ĄĎŞů¸šĄI ŚpżďžÜŚXşâĽIśO¤čŽ×ĄAązĽu­nĽI888¤¸ĄA§YĽižÖŚł¤âž÷ĄĎŞů¸šĄI ŚłˇNÄ@ĽÓ˝ĐŞĚĄA˝Đ¨ÓĽť¤˝Ľqżě˛zĄI ĹwŞď¨Óšq¸ß°ÝĄG 02-27039827 0925851019 ąś°\Ľřˇ~şŢ˛zĹU°ÝŚł­­¤˝Ľq ˇq¤W ˛Î¤@˝s¸šĄG97225510 From owner-linux-mips@oss.sgi.com Sun Oct 14 22:47:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F5l2S27132 for linux-mips-outgoing; Sun, 14 Oct 2001 22:47:02 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F5ktD27129; Sun, 14 Oct 2001 22:46:55 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 1DDF8125C3; Sun, 14 Oct 2001 22:46:54 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 972D6EBA6; Sun, 14 Oct 2001 22:46:54 -0700 (PDT) Date: Sun, 14 Oct 2001 22:46:54 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: Yoshi-K , linux-mips@oss.sgi.com Subject: Re: MySQL Message-ID: <20011014224654.B1658@lucon.org> References: <20011012225433.A10523@lucon.org> <20011014093052.B2374@lucon.org> <20011014230130.A3614@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011014230130.A3614@dea.linux-mips.net>; from ralf@oss.sgi.com on Sun, Oct 14, 2001 at 11:01:30PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 819 Lines: 27 On Sun, Oct 14, 2001 at 11:01:30PM +0200, Ralf Baechle wrote: > On Sun, Oct 14, 2001 at 09:30:52AM -0700, H . J . Lu wrote: > > > > hello. > > > As for everybody, does MySQL operate without trouble? > > > > > > OS: PS2 Linux. > > > CPU: R5900 > > > gcc 2.95.2 > > > glibc 2.2.2 > > > $ uname -a > > > Linux speed-ps 2.2.1 #94 Thu Apr 19 12:13:01 JST 2001 mips unknown > > > > > > > I ported mysql 3.23.36 to mips II and above in my RedHat 7.1 for > > mips. > > I assume MIPS II means you're using ll/sc in the locking code in the MySQL. > Now that the ll/sc emulation is finally fixed these instructions will > also work for ll/sc-less CPUs. Yes. It has some Linux/mips patch. I can only guess Linux/mips looks different than other Linux targets because of IRIX :-). See my RedHat 7.1 port for details. H.J. From owner-linux-mips@oss.sgi.com Mon Oct 15 00:16:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9F7GQq30033 for linux-mips-outgoing; Mon, 15 Oct 2001 00:16:26 -0700 Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9F7G0D30020 for ; Mon, 15 Oct 2001 00:16:00 -0700 Received: from bubble.local ([144.135.25.72]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GL8KH000.A2A for ; Mon, 15 Oct 2001 17:22:12 +1000 Received: from 144.136.192.57 ([144.136.192.57]) by PSMAM02.mailsvc.email.bigpond.com(MailRouter V2.9k 8383/2813303); 15 Oct 2001 17:22:07 Received: (qmail 9481 invoked by uid 179); 15 Oct 2001 07:15:39 -0000 Date: Mon, 15 Oct 2001 16:45:39 +0930 From: Alan Modra To: "H . J . Lu" , "Leonard N. Zubkoff" , binutils@sourceware.cygnus.com, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , "Steven J. Hill" , linux-gcc@vger.kernel.org Subject: Re: binutils 2.11.92.0.6 (Re: binutils 2.11.92.0.5 is broken) Message-ID: <20011015164539.I1015@bubble.sa.bigpond.net.au> Mail-Followup-To: "H . J . Lu" , "Leonard N. Zubkoff" , binutils@sourceware.cygnus.com, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , "Steven J. Hill" , linux-gcc@vger.kernel.org References: <200110131452.f9DEq7Q0032358@dandelion.com> <20011013190034.A27019@lucon.org> <20011013235621.A15807@lucon.org> <20011015093317.B1015@bubble.sa.bigpond.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20011015093317.B1015@bubble.sa.bigpond.net.au>; from amodra@bigpond.net.au on Mon, Oct 15, 2001 at 09:33:17AM +0930 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8643 Lines: 276 I'm about to commit this to fix the problems introduced by the new reference counting scheme. 2001-10-15 Alan Modra H.J. Lu * elf32-hppa.c (elf32_hppa_copy_indirect_symbol): Merge dyn_reloc counts for aliases instead of aborting. * elf32-i386.c (elf_i386_copy_indirect_symbol): Likewise. * elf64-ppc.c (ppc64_elf_copy_indirect_symbol): Likewise. * elf32-hppa.c (elf32_hppa_adjust_dynamic_symbol): Set plt.offset to -1 for non-function symbols. * elf32-ppc.c (ppc_elf_adjust_dynamic_symbol): Likewise. * elf32-s390.c (elf_s390_adjust_dynamic_symbol): Likewise. * elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Likewise. * elf64-s390.c (elf_s390_adjust_dynamic_symbol): Likewise. * elf64-x86-64.c (elf64_x86_64_adjust_dynamic_symbol): Likewise. * elf32-i386.c (elf_i386_adjust_dynamic_symbol): Refer to plt.offset instead of plt.refcount when setting to -1. -- Alan Modra Index: bfd/elf32-hppa.c =================================================================== RCS file: /cvs/src/src/bfd/elf32-hppa.c,v retrieving revision 1.52 diff -u -p -r1.52 elf32-hppa.c --- elf32-hppa.c 2001/10/03 08:33:18 1.52 +++ elf32-hppa.c 2001/10/15 05:12:07 @@ -1142,13 +1142,41 @@ elf32_hppa_copy_indirect_symbol (dir, in edir = (struct elf32_hppa_link_hash_entry *) dir; eind = (struct elf32_hppa_link_hash_entry *) ind; - if (edir->dyn_relocs == NULL) + if (eind->dyn_relocs != NULL) { + if (edir->dyn_relocs != NULL) + { + struct elf32_hppa_dyn_reloc_entry **pp; + struct elf32_hppa_dyn_reloc_entry *p; + + if (dir != ind->weakdef) + abort (); + + /* Add reloc counts against the weak sym to the strong sym + list. Merge any entries against the same section. */ + for (pp = &eind->dyn_relocs; (p = *pp) != NULL; ) + { + struct elf32_hppa_dyn_reloc_entry *q; + + for (q = edir->dyn_relocs; q != NULL; q = q->next) + if (q->sec == p->sec) + { +#if RELATIVE_DYNRELOCS + q->relative_count += p->relative_count; +#endif + q->count += p->count; + *pp = p->next; + break; + } + if (q == NULL) + pp = &p->next; + } + *pp = edir->dyn_relocs; + } + edir->dyn_relocs = eind->dyn_relocs; eind->dyn_relocs = NULL; } - else if (eind->dyn_relocs != NULL) - abort (); _bfd_elf_link_hash_copy_indirect (dir, ind); } @@ -1844,6 +1872,8 @@ elf32_hppa_adjust_dynamic_symbol (info, return true; } + else + h->plt.offset = (bfd_vma) -1; /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: bfd/elf32-i386.c =================================================================== RCS file: /cvs/src/src/bfd/elf32-i386.c,v retrieving revision 1.54 diff -u -p -r1.54 elf32-i386.c --- elf32-i386.c 2001/10/03 15:11:46 1.54 +++ elf32-i386.c 2001/10/15 05:12:07 @@ -637,13 +637,39 @@ elf_i386_copy_indirect_symbol (dir, ind) edir = (struct elf_i386_link_hash_entry *) dir; eind = (struct elf_i386_link_hash_entry *) ind; - if (edir->dyn_relocs == NULL) + if (eind->dyn_relocs != NULL) { + if (edir->dyn_relocs != NULL) + { + struct elf_i386_dyn_relocs **pp; + struct elf_i386_dyn_relocs *p; + + if (dir != ind->weakdef) + abort (); + + /* Add reloc counts against the weak sym to the strong sym + list. Merge any entries against the same section. */ + for (pp = &eind->dyn_relocs; (p = *pp) != NULL; ) + { + struct elf_i386_dyn_relocs *q; + + for (q = edir->dyn_relocs; q != NULL; q = q->next) + if (q->sec == p->sec) + { + q->pc_count += p->pc_count; + q->count += p->count; + *pp = p->next; + break; + } + if (q == NULL) + pp = &p->next; + } + *pp = edir->dyn_relocs; + } + edir->dyn_relocs = eind->dyn_relocs; eind->dyn_relocs = NULL; } - else if (eind->dyn_relocs != NULL) - abort (); _bfd_elf_link_hash_copy_indirect (dir, ind); } @@ -1086,7 +1112,7 @@ elf_i386_adjust_dynamic_symbol (info, h) object, or if all references were garbage collected. In such a case, we don't actually need to build a procedure linkage table, and we can just do a PC32 reloc instead. */ - h->plt.refcount = -1; + h->plt.offset = (bfd_vma) -1; h->elf_link_hash_flags &= ~ELF_LINK_HASH_NEEDS_PLT; } @@ -1098,7 +1124,7 @@ elf_i386_adjust_dynamic_symbol (info, h) check_relocs. We can't decide accurately between function and non-function syms in check-relocs; Objects loaded later in the link may change h->type. So fix it now. */ - h->plt.refcount = -1; + h->plt.offset = (bfd_vma) -1; /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: bfd/elf32-ppc.c =================================================================== RCS file: /cvs/src/src/bfd/elf32-ppc.c,v retrieving revision 1.32 diff -u -p -r1.32 elf32-ppc.c --- elf32-ppc.c 2001/09/29 06:21:59 1.32 +++ elf32-ppc.c 2001/10/15 05:12:09 @@ -1797,6 +1797,8 @@ ppc_elf_adjust_dynamic_symbol (info, h) return true; } + else + h->plt.offset = (bfd_vma) -1; /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: bfd/elf32-s390.c =================================================================== RCS file: /cvs/src/src/bfd/elf32-s390.c,v retrieving revision 1.9 diff -u -p -r1.9 elf32-s390.c --- elf32-s390.c 2001/09/29 06:21:59 1.9 +++ elf32-s390.c 2001/10/15 05:12:11 @@ -998,6 +998,8 @@ elf_s390_adjust_dynamic_symbol (info, h) return true; } + else + h->plt.offset = (bfd_vma) -1; /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: bfd/elf64-ppc.c =================================================================== RCS file: /cvs/src/src/bfd/elf64-ppc.c,v retrieving revision 1.7 diff -u -p -r1.7 elf64-ppc.c --- elf64-ppc.c 2001/10/03 08:33:18 1.7 +++ elf64-ppc.c 2001/10/15 05:12:13 @@ -1794,13 +1794,39 @@ ppc64_elf_copy_indirect_symbol (dir, ind edir = (struct ppc_link_hash_entry *) dir; eind = (struct ppc_link_hash_entry *) ind; - if (edir->dyn_relocs == NULL) + if (eind->dyn_relocs != NULL) { + if (edir->dyn_relocs != NULL) + { + struct ppc_dyn_relocs **pp; + struct ppc_dyn_relocs *p; + + if (dir != ind->weakdef) + abort (); + + /* Add reloc counts against the weak sym to the strong sym + list. Merge any entries against the same section. */ + for (pp = &eind->dyn_relocs; (p = *pp) != NULL; ) + { + struct ppc_dyn_relocs *q; + + for (q = edir->dyn_relocs; q != NULL; q = q->next) + if (q->sec == p->sec) + { + q->pc_count += p->pc_count; + q->count += p->count; + *pp = p->next; + break; + } + if (q == NULL) + pp = &p->next; + } + *pp = edir->dyn_relocs; + } + edir->dyn_relocs = eind->dyn_relocs; eind->dyn_relocs = NULL; } - else if (eind->dyn_relocs != NULL) - abort (); _bfd_elf_link_hash_copy_indirect (dir, ind); } @@ -2366,6 +2392,8 @@ ppc64_elf_adjust_dynamic_symbol (info, h } return true; } + else + h->plt.offset = (bfd_vma) -1; /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: bfd/elf64-s390.c =================================================================== RCS file: /cvs/src/src/bfd/elf64-s390.c,v retrieving revision 1.9 diff -u -p -r1.9 elf64-s390.c --- elf64-s390.c 2001/09/29 06:21:59 1.9 +++ elf64-s390.c 2001/10/15 05:12:15 @@ -976,6 +976,8 @@ elf_s390_adjust_dynamic_symbol (info, h) return true; } + else + h->plt.offset = (bfd_vma) -1; /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the Index: bfd/elf64-x86-64.c =================================================================== RCS file: /cvs/src/src/bfd/elf64-x86-64.c,v retrieving revision 1.29 diff -u -p -r1.29 elf64-x86-64.c --- elf64-x86-64.c 2001/09/29 06:21:59 1.29 +++ elf64-x86-64.c 2001/10/15 05:12:17 @@ -854,6 +854,8 @@ elf64_x86_64_adjust_dynamic_symbol (info return true; } + else + h->plt.offset = (bfd_vma) -1; /* If this is a weak symbol, and there is a real definition, the processor independent code will have arranged for us to see the From owner-linux-mips@oss.sgi.com Mon Oct 15 08:16:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FFGc008064 for linux-mips-outgoing; Mon, 15 Oct 2001 08:16:38 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FFGRD08061 for ; Mon, 15 Oct 2001 08:16:29 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA22376; Mon, 15 Oct 2001 17:15:14 +0200 (MET DST) Date: Mon, 15 Oct 2001 17:15:14 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: linux 2.4.9: A SysRQ fix for non-PC_KEYB configurations Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2033 Lines: 62 Ralf, The DECstation setup doesn't compile if MAGIC_SYSRQ is enabled. That's because SYSRQ_KEY is undefined. The following patch fixes the generic configuration as well as the LK201 keyboard handler. If any other MIPS machine uses a non-PC keyboard, it needs to define kbd_sysrq_key as well, to a real value, if possible. A compilation error will reveal the need to interested parties. Please apply. Thanks. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.9-20011009-dec-sysrq-0 diff -up --recursive --new-file linux-mips-2.4.9-20011009.macro/drivers/tc/lk201.c linux-mips-2.4.9-20011009/drivers/tc/lk201.c --- linux-mips-2.4.9-20011009.macro/drivers/tc/lk201.c Sat Sep 29 04:26:52 2001 +++ linux-mips-2.4.9-20011009/drivers/tc/lk201.c Mon Oct 15 01:34:56 2001 @@ -5,12 +5,16 @@ * for more details. * */ +#include + #include #include #include #include #include #include + +#include #include #include #include @@ -27,6 +31,8 @@ */ unsigned char lk201_sysrq_xlate[128]; unsigned char *kbd_sysrq_xlate = lk201_sysrq_xlate; + +unsigned char kbd_sysrq_key = -1; #endif #define KEYB_LINE 3 diff -up --recursive --new-file linux-mips-2.4.9-20011009.macro/include/asm-mips/keyboard.h linux-mips-2.4.9-20011009/include/asm-mips/keyboard.h --- linux-mips-2.4.9-20011009.macro/include/asm-mips/keyboard.h Sat Sep 29 04:26:55 2001 +++ linux-mips-2.4.9-20011009/include/asm-mips/keyboard.h Mon Oct 15 01:29:25 2001 @@ -88,6 +88,9 @@ extern int kbd_rate(struct kbd_repeat *r extern void kbd_init_hw(void); extern unsigned char *kbd_sysrq_xlate; +extern unsigned char kbd_sysrq_key; +#define SYSRQ_KEY kbd_sysrq_key + #endif #endif /* __KERNEL */ From owner-linux-mips@oss.sgi.com Tue Oct 16 07:29:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GETTw00458 for linux-mips-outgoing; Tue, 16 Oct 2001 07:29:29 -0700 Received: from quicklogic.com (quick1.quicklogic.com [206.184.225.224]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GETOD00453 for ; Tue, 16 Oct 2001 07:29:24 -0700 Received: from enghanks ([207.81.96.51]) by quicklogic.com; Tue, 16 Oct 2001 07:28:35 -0700 From: "Hanks Li" To: Subject: IDE DMA mode in Big endian for mips Date: Tue, 16 Oct 2001 10:28:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20011012225433.A10523@lucon.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1817 Lines: 49 Hi, We are working on the IDE/ATAPI for mips. When I changed to Big endian mode, the following information appared, and the program hang. ------------------------------------- Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PDC20262: IDE controller on PCI bus 00 dev 30 PDC20262: chipset revision 1 PDC20262: not 100% native mode: will probe irqs later PDC20262: ROM enabled at 0x06fb0000 PDC20262: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode. ide0: BM-DMA at 0xf800-0xf807, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf808-0xf80f, BIOS settings: hdc:pio, hdd:pio hda: QUANTUM FIREBALL EX10.2A, ATA DISK drive ide0 at 0xec00-0xec07,0xe802 on irq 7 hda: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63, (U)DMA Partition check: hda:hda: dma_timer_expiry: status=0x58 { DriveReady SeekComplete DataRequest } hda: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 ------------------------------------- When I turned off "IDE,ATA and ATAPI Block Devices->Generic PCI bus-master DMA support", there was no problem at all. The following information appared: ------------------------------------ Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PDC20262: IDE controller on PCI bus 00 dev 30 PDC20262: chipset revision 1 PDC20262: not 100% native mode: will probe irqs later hda: QUANTUM FIREBALL EX10.2A, ATA DISK drive ide0 at 0xec00-0xec07,0xe802 on irq 7 hda: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63 Partition check: hda: [PTBL] [1247/255/63] hda1 hda2 hda3 ------------------------------------ What could be the cause of this problem? Regards, Hanshi Li From owner-linux-mips@oss.sgi.com Tue Oct 16 09:05:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GG5A602243 for linux-mips-outgoing; Tue, 16 Oct 2001 09:05:10 -0700 Received: from dark-past (h117n1fls20o53.telia.com [213.64.214.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GG56D02240 for ; Tue, 16 Oct 2001 09:05:07 -0700 Received: from yog-sothoth.dark-past.mine.nu (yog-sothoth [192.168.1.7]) by dark-past (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA17897 for ; Tue, 16 Oct 2001 20:17:01 -0700 Message-Id: <5.1.0.14.0.20011016193856.00a518e0@192.168.1.5> X-Sender: peter@192.168.1.5 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Oct 2001 19:42:38 +0200 To: linux-mips@oss.sgi.com From: Peter Andersson Subject: Linux 2.4 kernel with sound support Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 189 Lines: 8 Does anyone know where i can find a mips linux 2.4 kernel with audio support? I am running an sgi indy with a R5000 processor, but kernels compiled for R4400 works great. Thanks Peter From owner-linux-mips@oss.sgi.com Tue Oct 16 10:16:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GHG3j03336 for linux-mips-outgoing; Tue, 16 Oct 2001 10:16:03 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GHFmD03330 for ; Tue, 16 Oct 2001 10:15:49 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA29556; Tue, 16 Oct 2001 19:06:41 +0200 (MET DST) Date: Tue, 16 Oct 2001 19:06:40 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.9: Bad code in xchg_u32() Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3277 Lines: 90 Ralf, There is a problem with the xchg_u32() function when compiled for CPU_HAS_LLSC. The constraints are broken and do not prevent gcc from expanding ll and sc into multiple instructions, clobbering $at additionally. See a dump below (from free_dma() in kernel/dma.o): 108: 00602021 move a0,v1 10c: 3c030000 lui v1,0x0 10c: R_MIPS_HI16 .data 110: 00621821 addu v1,v1,v0 114: c0630004 ll v1,4(v1) 114: R_MIPS_LO16 .data 118: 00800821 move at,a0 11c: 3c010000 lui at,0x0 11c: R_MIPS_HI16 .data 120: 00220821 addu at,at,v0 124: e0210004 sc at,4(at) 124: R_MIPS_LO16 .data 128: 5020fffb beqzl at,118 12c: 3c030000 lui v1,0x0 12c: R_MIPS_HI16 .data 130: 00621821 addu v1,v1,v0 134: c0630004 ll v1,4(v1) 134: R_MIPS_LO16 .data Following is a fix that works for me. The code now looks: 104: 3c010000 lui at,0x0 104: R_MIPS_HI16 .data 108: 24210004 addiu at,at,4 108: R_MIPS_LO16 .data 10c: 00221021 addu v0,at,v0 110: 00001821 move v1,zero 114: c0460000 ll a2,0(v0) 118: 00602021 move a0,v1 11c: e0440000 sc a0,0(v0) 120: 5080fffd beqzl a0,118 124: c0460000 ll a2,0(v0) Excellent -- it got shortened as well. Unfortunately, gcc 2.95.3 doesn't want to accept a "=R" output constraint here so I had to use "=m". It looks like a bug in gcc. Until it is fixed the "R" input constraint here is sufficient for gcc to know it has m already available in one of registers. I added ".set nomacro" to make sure the second ll fits in the BDS as well. Ralf, I think this should get applied. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.9-20011009-xchg-1 diff -up --recursive --new-file linux-mips-2.4.9-20011009.macro/include/asm-mips/system.h linux-mips-2.4.9-20011009/include/asm-mips/system.h --- linux-mips-2.4.9-20011009.macro/include/asm-mips/system.h Sun Oct 7 04:26:15 2001 +++ linux-mips-2.4.9-20011009/include/asm-mips/system.h Tue Oct 16 01:11:27 2001 @@ -234,18 +234,17 @@ extern __inline__ unsigned long xchg_u32 unsigned long dummy; __asm__ __volatile__( - ".set\tnoreorder\t\t\t# xchg_u32\n\t" - ".set\tnoat\n\t" + ".set\tpush\t\t\t\t# xchg_u32\n\t" + ".set\tnoreorder\n\t" + ".set\tnomacro\n\t" "ll\t%0, %3\n" - "1:\tmove\t$1, %2\n\t" - "sc\t$1, %1\n\t" - "beqzl\t$1, 1b\n\t" + "1:\tmove\t%2, %z4\n\t" + "sc\t%2, %1\n\t" + "beqzl\t%2, 1b\n\t" " ll\t%0, %3\n\t" - ".set\tat\n\t" - ".set\treorder" - : "=r" (val), "=o" (*m), "=r" (dummy) - : "o" (*m), "2" (val) - : "memory"); + ".set\tpop" + : "=&r" (val), "=m" (*m), "=&r" (dummy) + : "R" (*m), "Jr" (val)); return val; #else From owner-linux-mips@oss.sgi.com Tue Oct 16 10:30:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GHUQr03579 for linux-mips-outgoing; Tue, 16 Oct 2001 10:30:26 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GHUKD03575 for ; Tue, 16 Oct 2001 10:30:20 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9GHWcB24799; Tue, 16 Oct 2001 10:32:38 -0700 Message-ID: <3BCC6EA3.A1A3BA3A@mvista.com> Date: Tue, 16 Oct 2001 10:30:11 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Hanks Li CC: linux-mips@oss.sgi.com Subject: Re: IDE DMA mode in Big endian for mips References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2280 Lines: 60 Some host-PCI bridge controller may have smart endian conversion features. Make sure you set it up correctly. The fact that DMA does not work but polling works might also indicate the smart conversion only happens from PCI to memory, not in the patch PCI -> CPU. Perhaps your memory is still in LE mode even when your CPU runs in BE mode? Jun Hanks Li wrote: > > Hi, > > We are working on the IDE/ATAPI for mips. When I changed to Big endian mode, > the following information appared, and the program hang. > > ------------------------------------- > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > PDC20262: IDE controller on PCI bus 00 dev 30 > PDC20262: chipset revision 1 > PDC20262: not 100% native mode: will probe irqs later > PDC20262: ROM enabled at 0x06fb0000 > PDC20262: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode. > ide0: BM-DMA at 0xf800-0xf807, BIOS settings: hda:pio, hdb:pio > ide1: BM-DMA at 0xf808-0xf80f, BIOS settings: hdc:pio, hdd:pio > hda: QUANTUM FIREBALL EX10.2A, ATA DISK drive > ide0 at 0xec00-0xec07,0xe802 on irq 7 > hda: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63, (U)DMA > Partition check: > hda:hda: dma_timer_expiry: status=0x58 { DriveReady SeekComplete > DataRequest } > hda: timeout waiting for DMA > ide_dmaproc: chipset supported ide_dma_timeout func only: 14 > ------------------------------------- > > When I turned off "IDE,ATA and ATAPI Block Devices->Generic PCI bus-master > DMA support", there was no problem at all. The following information > appared: > > ------------------------------------ > > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > PDC20262: IDE controller on PCI bus 00 dev 30 > PDC20262: chipset revision 1 > PDC20262: not 100% native mode: will probe irqs later > hda: QUANTUM FIREBALL EX10.2A, ATA DISK drive > ide0 at 0xec00-0xec07,0xe802 on irq 7 > hda: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63 > Partition check: > hda: [PTBL] [1247/255/63] hda1 hda2 hda3 > ------------------------------------ > > What could be the cause of this problem? > > Regards, > > Hanshi Li From owner-linux-mips@oss.sgi.com Tue Oct 16 10:41:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GHfjZ03982 for linux-mips-outgoing; Tue, 16 Oct 2001 10:41:45 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GHfhD03979 for ; Tue, 16 Oct 2001 10:41:43 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9GHi2B25377; Tue, 16 Oct 2001 10:44:02 -0700 Message-ID: <3BCC714F.B04C6D2B@mvista.com> Date: Tue, 16 Oct 2001 10:41:35 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Peter Andersson CC: linux-mips@oss.sgi.com Subject: Re: Linux 2.4 kernel with sound support References: <5.1.0.14.0.20011016193856.00a518e0@192.168.1.5> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 337 Lines: 17 Peter Andersson wrote: > > Does anyone know where i can find a mips linux 2.4 kernel with audio > support? I am running an sgi indy with a R5000 processor, but kernels > compiled for R4400 works great. > > Thanks > > Peter AFAIK, the following boards/sound drivers work it8172 ite8172.c pb1000 au1000.c ddb5477 nec_vrc5477.c Jun From owner-linux-mips@oss.sgi.com Tue Oct 16 11:51:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GIp3v05779 for linux-mips-outgoing; Tue, 16 Oct 2001 11:51:03 -0700 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GIp1D05776 for ; Tue, 16 Oct 2001 11:51:01 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id LAA36984; Tue, 16 Oct 2001 11:50:59 -0700 (PDT) Date: Tue, 16 Oct 2001 11:50:59 -0700 From: Geoffrey Espin To: Pete Popov Cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: [Linux-mips-kernel]PATCH Message-ID: <20011016115059.A29701@idiom.com> References: <3BC24525.8030201@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <3BC24525.8030201@mvista.com>; from Pete Popov on Mon, Oct 08, 2001 at 05:30:29PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 627 Lines: 15 Pete, > I've attached a patch which adds zImage support for the Alchemy pb1000 board. > The image is burned in flash and yamon can be used to just jump to that location >... > Feedback would be appreciated, including whether or not arch/mips/zboot is the > most appropriate place to put the zImage support. It ain't a pretty patch. I do want to do this for the Korva-Markham board... either arch/arm/boot/compressed or arch/ppc/boot scheme would be nice to follow. I think arch/ppc/boot/mbx/Makefile does some of the magic offset stuff you need with quick `sh ` scripts and also includes piggyback initrd stuff! Geoff From owner-linux-mips@oss.sgi.com Tue Oct 16 13:06:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GK6Oh07305 for linux-mips-outgoing; Tue, 16 Oct 2001 13:06:24 -0700 Received: from ex2k ([209.125.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GK6ND07302 for ; Tue, 16 Oct 2001 13:06:23 -0700 Subject: system call fork in init. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 16 Oct 2001 13:02:06 -0700 Message-ID: <84CE342693F11946B9F54B18C1AB837B14A7CE@ex2k.pcs.psdc.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: system call fork in init. Thread-Index: AcFWfW3Gu3EC1zgvQpWWM40gVJmllw== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9GK6ND07303 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 248 Lines: 11 Hi, All: Currently, I am porting Linux 2.2.12 to mips a r3000 CPU. When the init program forked a child process and the the scheduler try to run it, the child's stack are all zeros. Any one help will be greatly appreciated. Thanks, Steven Liu From owner-linux-mips@oss.sgi.com Tue Oct 16 15:37:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GMbdf10248 for linux-mips-outgoing; Tue, 16 Oct 2001 15:37:39 -0700 Received: from dea.linux-mips.net (a1as11-p81.stg.tli.de [195.252.190.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GMb4D10243 for ; Tue, 16 Oct 2001 15:37:11 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9GMTlx21841; Wed, 17 Oct 2001 00:29:47 +0200 Date: Wed, 17 Oct 2001 00:29:47 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.9: Bad code in xchg_u32() Message-ID: <20011017002947.A19789@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Tue, Oct 16, 2001 at 07:06:40PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 703 Lines: 17 On Tue, Oct 16, 2001 at 07:06:40PM +0200, Maciej W. Rozycki wrote: > > Unfortunately, gcc 2.95.3 doesn't want to accept a "=R" output constraint > here so I had to use "=m". It looks like a bug in gcc. Until it is fixed > the "R" input constraint here is sufficient for gcc to know it has m > already available in one of registers. I added ".set nomacro" to make > sure the second ll fits in the BDS as well. I've added the "memory" clobber back; xchg() is expected to imply a memory barrier. "R" indeed seems to be fishy; I can't compile the kernel if I remove the volatile from the first argument of xchg_u32(). I'd feel safer if we could use "m" until we can be sure "R" works fine. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 16 15:49:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9GMnaQ10988 for linux-mips-outgoing; Tue, 16 Oct 2001 15:49:36 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9GMnYD10984; Tue, 16 Oct 2001 15:49:34 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9GMptB16440; Tue, 16 Oct 2001 15:51:55 -0700 Message-ID: <3BCCB979.FFBFE85B@mvista.com> Date: Tue, 16 Oct 2001 15:49:29 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.9: Bad code in xchg_u32() References: <20011017002947.A19789@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 815 Lines: 21 Ralf Baechle wrote: > > On Tue, Oct 16, 2001 at 07:06:40PM +0200, Maciej W. Rozycki wrote: > > > > > Unfortunately, gcc 2.95.3 doesn't want to accept a "=R" output constraint > > here so I had to use "=m". It looks like a bug in gcc. Until it is fixed > > the "R" input constraint here is sufficient for gcc to know it has m > > already available in one of registers. I added ".set nomacro" to make > > sure the second ll fits in the BDS as well. > > I've added the "memory" clobber back; xchg() is expected to imply a memory > barrier. > > "R" indeed seems to be fishy; I can't compile the kernel if I remove > the volatile from the first argument of xchg_u32(). I'd feel safer if > we could use "m" until we can be sure "R" works fine. Is there any reason to think "R" *should* be better than "m"? Jun From owner-linux-mips@oss.sgi.com Tue Oct 16 18:04:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H142W14016 for linux-mips-outgoing; Tue, 16 Oct 2001 18:04:02 -0700 Received: from dea.linux-mips.net (a1as11-p81.stg.tli.de [195.252.190.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H13vD14013 for ; Tue, 16 Oct 2001 18:03:58 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9H0vLI15140; Wed, 17 Oct 2001 02:57:21 +0200 Date: Wed, 17 Oct 2001 02:57:21 +0200 From: Ralf Baechle To: Jun Sun Cc: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.9: Bad code in xchg_u32() Message-ID: <20011017025721.A15129@dea.linux-mips.net> References: <20011017002947.A19789@dea.linux-mips.net> <3BCCB979.FFBFE85B@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: <3BCCB979.FFBFE85B@mvista.com>; from jsun@mvista.com on Tue, Oct 16, 2001 at 03:49:29PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 850 Lines: 20 On Tue, Oct 16, 2001 at 03:49:29PM -0700, Jun Sun wrote: > > > Unfortunately, gcc 2.95.3 doesn't want to accept a "=R" output constraint > > > here so I had to use "=m". It looks like a bug in gcc. Until it is fixed > > > the "R" input constraint here is sufficient for gcc to know it has m > > > already available in one of registers. I added ".set nomacro" to make > > > sure the second ll fits in the BDS as well. > > > > I've added the "memory" clobber back; xchg() is expected to imply a memory > > barrier. > > > > "R" indeed seems to be fishy; I can't compile the kernel if I remove > > the volatile from the first argument of xchg_u32(). I'd feel safer if > > we could use "m" until we can be sure "R" works fine. > > Is there any reason to think "R" *should* be better than "m"? Single instruction loads that is no macros. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 16 19:15:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H2FQZ15550 for linux-mips-outgoing; Tue, 16 Oct 2001 19:15:26 -0700 Received: from dea.linux-mips.net (a1as11-p81.stg.tli.de [195.252.190.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H2FND15547 for ; Tue, 16 Oct 2001 19:15:24 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9H2FLv15557; Wed, 17 Oct 2001 04:15:21 +0200 Date: Wed, 17 Oct 2001 04:15:20 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Worm bombardment. Message-ID: <20011017041520.A15518@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 255 Lines: 6 I'm currently getting bombarded by the Sircam worm which already has resulted in mail getting dropped without error messages getting bounced back. If you sent anything of importance which I haven't answered yet during the last 24h please resend. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 16 19:33:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H2XvL15863 for linux-mips-outgoing; Tue, 16 Oct 2001 19:33:57 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H2XrD15860 for ; Tue, 16 Oct 2001 19:33:53 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 17 Oct 2001 02:33:53 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 13732B46D; Wed, 17 Oct 2001 11:33:50 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA23995; Wed, 17 Oct 2001 11:33:50 +0900 (JST) Date: Wed, 17 Oct 2001 11:38:42 +0900 (JST) Message-Id: <20011017.113842.41627007.nemoto@toshiba-tops.co.jp> To: hli@quicklogic.com Cc: linux-mips@oss.sgi.com Subject: Re: IDE DMA mode in Big endian for mips From: Atsushi Nemoto In-Reply-To: References: <20011012225433.A10523@lucon.org> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 985 Lines: 24 >>>>> On Tue, 16 Oct 2001 10:28:56 -0400, "Hanks Li" said: hli> We are working on the IDE/ATAPI for mips. When I changed to Big hli> endian mode, the following information appared, and the program hli> hang. When I tried PCI-IDE in BigEndian (with 2.4.6 kernel), this patch solved my problem. --- linux/drivers/ide/ide-dma.c:1.1.1.1 Fri Jul 6 11:24:54 2001 +++ linux/drivers/ide/ide-dma.c Fri Aug 17 20:17:30 2001 @@ -492,7 +492,11 @@ SELECT_READ_WRITE(hwif,drive,func); if (!(count = ide_build_dmatable(drive, func))) return 1; /* try PIO instead of DMA */ +#if defined(__mips__) && defined(__BIG_ENDIAN) /* XXX mips only? */ + outl(cpu_to_le32(hwif->dmatable_dma), dma_base + 4); /* PRD table */ +#else outl(hwif->dmatable_dma, dma_base + 4); /* PRD table */ +#endif outb(reading, dma_base); /* specify r/w */ outb(inb(dma_base+2)|6, dma_base+2); /* clear INTR & ERROR flags */ drive->waiting_for_dma = 1; --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue Oct 16 20:14:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H3Ea816446 for linux-mips-outgoing; Tue, 16 Oct 2001 20:14:36 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H3DhD16438 for ; Tue, 16 Oct 2001 20:13:44 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B6099125C3; Tue, 16 Oct 2001 20:13:34 -0700 (PDT) Date: Tue, 16 Oct 2001 20:13:34 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , GNU C Library , gcc@gcc.gnu.org Subject: The Linux binutils 2.11.92.0.7 is released. Message-ID: <20011016201334.A31989@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 13943 Lines: 508 Please test it as much as you can and report all the regressions. Thanks. H.J. ---- This is the beta release of binutils 2.11.92.0.7 for Linux, which is based on binutils 2001 1016 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.92.0.7 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.5. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.92.0.7.tar.gz. Source code. 2. binutils-2.11.92.0.5-2.11.92.0.7.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.92.0.7-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.92.0.7.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 10/16/2001 From owner-linux-mips@oss.sgi.com Tue Oct 16 22:49:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H5nFE18652 for linux-mips-outgoing; Tue, 16 Oct 2001 22:49:15 -0700 Received: from mail.sonytel.be (main.sonytel.be [195.0.45.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H5nAD18639 for ; Tue, 16 Oct 2001 22:49:10 -0700 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id HAA18408; Wed, 17 Oct 2001 07:48:40 +0200 (MET DST) Date: Wed, 17 Oct 2001 07:48:27 +0200 (MEST) From: Geert Uytterhoeven To: Atsushi Nemoto cc: hli@quicklogic.com, Linux/MIPS Development Subject: Re: IDE DMA mode in Big endian for mips In-Reply-To: <20011017.113842.41627007.nemoto@toshiba-tops.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1482 Lines: 40 On Wed, 17 Oct 2001, Atsushi Nemoto wrote: > >>>>> On Tue, 16 Oct 2001 10:28:56 -0400, "Hanks Li" said: > hli> We are working on the IDE/ATAPI for mips. When I changed to Big > hli> endian mode, the following information appared, and the program > hli> hang. > > When I tried PCI-IDE in BigEndian (with 2.4.6 kernel), this patch > solved my problem. > > --- linux/drivers/ide/ide-dma.c:1.1.1.1 Fri Jul 6 11:24:54 2001 > +++ linux/drivers/ide/ide-dma.c Fri Aug 17 20:17:30 2001 > @@ -492,7 +492,11 @@ > SELECT_READ_WRITE(hwif,drive,func); > if (!(count = ide_build_dmatable(drive, func))) > return 1; /* try PIO instead of DMA */ > +#if defined(__mips__) && defined(__BIG_ENDIAN) /* XXX mips only? */ > + outl(cpu_to_le32(hwif->dmatable_dma), dma_base + 4); /* PRD table */ > +#else > outl(hwif->dmatable_dma, dma_base + 4); /* PRD table */ > +#endif Since cpu_to_le32() does nothing on little endian, you can rewrite it like #if defined(__mips__) /* XXX mips only? */ outl(cpu_to_le32(hwif->dmatable_dma), dma_base + 4); /* PRD table */ #else outl(hwif->dmatable_dma, dma_base + 4); /* PRD table */ #endif Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Wed Oct 17 02:37:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H9bdu22530 for linux-mips-outgoing; Wed, 17 Oct 2001 02:37:39 -0700 Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H9bRD22521 for ; Wed, 17 Oct 2001 02:37:30 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA32647; Wed, 17 Oct 2001 13:37:25 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA05416; Wed, 17 Oct 2001 13:32:32 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA16320; Wed, 17 Oct 2001 12:32:24 +0300 (MSK) Message-ID: <3BCD506F.9683F0E8@niisi.msk.ru> Date: Wed, 17 Oct 2001 13:33:35 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Atsushi Nemoto CC: hli@quicklogic.com, linux-mips@oss.sgi.com Subject: Re: IDE DMA mode in Big endian for mips References: <20011012225433.A10523@lucon.org> <20011017.113842.41627007.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 271 Lines: 10 Atsushi Nemoto wrote: > When I tried PCI-IDE in BigEndian (with 2.4.6 kernel), this patch > solved my problem. > It seems you need either own version of outl and outw with byte swapping or instruct your hw to do that itself (if your hw can, of course). Regards, Gleb. From owner-linux-mips@oss.sgi.com Wed Oct 17 02:37:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H9bru22575 for linux-mips-outgoing; Wed, 17 Oct 2001 02:37:53 -0700 Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H9bkD22556 for ; Wed, 17 Oct 2001 02:37:47 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA32644; Wed, 17 Oct 2001 13:37:14 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA05405; Wed, 17 Oct 2001 13:30:42 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA16246; Wed, 17 Oct 2001 12:29:14 +0300 (MSK) Message-ID: <3BCD4FB2.D472C033@niisi.msk.ru> Date: Wed, 17 Oct 2001 13:30:26 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Steven Liu CC: linux-mips@oss.sgi.com Subject: Re: system call fork in init. References: <84CE342693F11946B9F54B18C1AB837B14A7CE@ex2k.pcs.psdc.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 302 Lines: 12 Steven Liu wrote: > Currently, I am porting Linux 2.2.12 to mips a r3000 CPU. When the init > program forked a child process and the the scheduler try to run it, the > child's stack are all zeros. > > Any one help will be greatly appreciated. > Choose 2.4, 2.2 is too buggy for r3k. Regards, Gleb. From owner-linux-mips@oss.sgi.com Wed Oct 17 04:08:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HB8Tf25528 for linux-mips-outgoing; Wed, 17 Oct 2001 04:08:29 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HB8HD25523; Wed, 17 Oct 2001 04:08:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA06978; Wed, 17 Oct 2001 13:07:23 +0200 (MET DST) Date: Wed, 17 Oct 2001 13:07:23 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.9: Bad code in xchg_u32() In-Reply-To: <20011017002947.A19789@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 940 Lines: 23 On Wed, 17 Oct 2001, Ralf Baechle wrote: > I've added the "memory" clobber back; xchg() is expected to imply a memory > barrier. I'm not sure what you mean. The "memory" clobber only means random memory can get modified so gcc must dispose of all variables cached in registers and reload them from memory. Is xchg() meant to do so? What for? > "R" indeed seems to be fishy; I can't compile the kernel if I remove > the volatile from the first argument of xchg_u32(). I'd feel safer if > we could use "m" until we can be sure "R" works fine. Sure we can, at the expense of obfuscating the code and wasting a register -- we may use la explicitly. But I hate workarounds -- they tend to live forever and keep the real bug unfixed. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed Oct 17 04:39:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HBdB726901 for linux-mips-outgoing; Wed, 17 Oct 2001 04:39:11 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HBd9D26898 for ; Wed, 17 Oct 2001 04:39:09 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [216.32.174.27]) with SMTP; 17 Oct 2001 11:39:09 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id E626CB46A; Wed, 17 Oct 2001 20:39:06 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id UAA25195; Wed, 17 Oct 2001 20:39:06 +0900 (JST) Date: Wed, 17 Oct 2001 20:43:58 +0900 (JST) Message-Id: <20011017.204358.39150084.nemoto@toshiba-tops.co.jp> To: raiko@niisi.msk.ru Cc: hli@quicklogic.com, linux-mips@oss.sgi.com Subject: Re: IDE DMA mode in Big endian for mips From: Atsushi Nemoto In-Reply-To: <3BCD506F.9683F0E8@niisi.msk.ru> References: <20011017.113842.41627007.nemoto@toshiba-tops.co.jp> <3BCD506F.9683F0E8@niisi.msk.ru> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 380 Lines: 10 >>>>> On Wed, 17 Oct 2001 13:33:35 +0400, "Gleb O. Raiko" said: raiko> It seems you need either own version of outl and outw with byte raiko> swapping or instruct your hw to do that itself (if your hw can, raiko> of course). Yes, I depend on hardware swapping on word/dword access. It seems many pci drivers depend on this swapping too. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Oct 17 08:06:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HF6w401373 for linux-mips-outgoing; Wed, 17 Oct 2001 08:06:58 -0700 Received: from dandelion.com (IDENT:JTZouzhSpgU/SL1t3lB0l+ud8YVrPkXU@dandelion.com [198.186.200.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HF6uD01370 for ; Wed, 17 Oct 2001 08:06:56 -0700 Received: (from lnz@localhost) by dandelion.com (8.12.1/8.12.1) id f9HF66GW013534; Wed, 17 Oct 2001 08:06:06 -0700 Date: Wed, 17 Oct 2001 08:06:06 -0700 Message-Id: <200110171506.f9HF66GW013534@dandelion.com> From: "Leonard N. Zubkoff" To: hjl@lucon.org CC: linux-gcc@vger.kernel.org, kjahds@kjahds.com, mat@lcs.mit.edu, doughera@lafcol.lafayette.edu, imp@village.org, linux-mips@oss.sgi.com, rfg@monkeys.com, linux-binutils-in@polstra.com, galenh@micron.net, ralf@mailhost.uni-koblenz.de, linas@linas.org, aries@hal2000.terra.vein.hu, sjhill@cotw.com, libc-alpha@sourceware.cygnus.com, gcc@gcc.gnu.org In-reply-to: <20011016201334.A31989@lucon.org> (hjl@lucon.org) Subject: Re: The Linux binutils 2.11.92.0.7 is released. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 289 Lines: 11 Date: Tue, 16 Oct 2001 20:13:34 -0700 From: "H . J . Lu" Please test it as much as you can and report all the regressions. H.J., I've recompiled my entire system with the new binutils installed and there were no errors during the compilation this time. Leonard From owner-linux-mips@oss.sgi.com Wed Oct 17 10:52:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HHquM05421 for linux-mips-outgoing; Wed, 17 Oct 2001 10:52:56 -0700 Received: from quicklogic.com (quick1.quicklogic.com [206.184.225.224]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HHqqD05415 for ; Wed, 17 Oct 2001 10:52:52 -0700 Received: from enghanks ([207.81.96.51]) by quicklogic.com; Wed, 17 Oct 2001 10:51:56 -0700 From: "Hanks Li" To: "Atsushi Nemoto" Cc: Subject: RE: IDE DMA mode in Big endian for mips Date: Wed, 17 Oct 2001 13:52:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20011017.113842.41627007.nemoto@toshiba-tops.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1473 Lines: 46 Thanks Atsushi San, the patch did help. The partition check can pass now. But my boot (such as: usb, ethernet, etc.) could not continue after solving the IDE problem. Could anybody give me a hint? Thanks Hanks Li -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Atsushi Nemoto Sent: Tuesday, October 16, 2001 10:39 PM To: hli@quicklogic.com Cc: linux-mips@oss.sgi.com Subject: Re: IDE DMA mode in Big endian for mips >>>>> On Tue, 16 Oct 2001 10:28:56 -0400, "Hanks Li" said: hli> We are working on the IDE/ATAPI for mips. When I changed to Big hli> endian mode, the following information appared, and the program hli> hang. When I tried PCI-IDE in BigEndian (with 2.4.6 kernel), this patch solved my problem. --- linux/drivers/ide/ide-dma.c:1.1.1.1 Fri Jul 6 11:24:54 2001 +++ linux/drivers/ide/ide-dma.c Fri Aug 17 20:17:30 2001 @@ -492,7 +492,11 @@ SELECT_READ_WRITE(hwif,drive,func); if (!(count = ide_build_dmatable(drive, func))) return 1; /* try PIO instead of DMA */ +#if defined(__mips__) && defined(__BIG_ENDIAN) /* XXX mips only? */ + outl(cpu_to_le32(hwif->dmatable_dma), dma_base + 4); /* PRD table */ +#else outl(hwif->dmatable_dma, dma_base + 4); /* PRD table */ +#endif outb(reading, dma_base); /* specify r/w */ outb(inb(dma_base+2)|6, dma_base+2); /* clear INTR & ERROR flags */ drive->waiting_for_dma = 1; --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Oct 17 19:14:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I2E1m14069 for linux-mips-outgoing; Wed, 17 Oct 2001 19:14:01 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I2DwD14066 for ; Wed, 17 Oct 2001 19:13:59 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [216.32.174.27]) with SMTP; 18 Oct 2001 02:13:58 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 84800B46E; Thu, 18 Oct 2001 11:13:51 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA00511; Thu, 18 Oct 2001 11:14:23 +0900 (JST) Date: Thu, 18 Oct 2001 11:18:43 +0900 (JST) Message-Id: <20011018.111843.41626947.nemoto@toshiba-tops.co.jp> To: raiko@niisi.msk.ru Cc: hli@quicklogic.com, linux-mips@oss.sgi.com Subject: Re: IDE DMA mode in Big endian for mips From: Atsushi Nemoto In-Reply-To: <20011017.204358.39150084.nemoto@toshiba-tops.co.jp> References: <20011017.113842.41627007.nemoto@toshiba-tops.co.jp> <3BCD506F.9683F0E8@niisi.msk.ru> <20011017.204358.39150084.nemoto@toshiba-tops.co.jp> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 512 Lines: 14 >>>>> On Wed, 17 Oct 2001 20:43:58 +0900 (JST), Atsushi Nemoto said: nemoto> Yes, I depend on hardware swapping on word/dword access. It nemoto> seems many pci drivers depend on this swapping too. Sorry, last sentence might be wrong. I doubt I have been misunderstanding long time... Can anybody explain me a PCI driver's policy of endianness? Should we use cpu_to_le32 with outl/writel? Should we use cpu_to_le32 to write 32bit data to DMA area? Thank you. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Oct 17 22:55:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I5tu117769 for linux-mips-outgoing; Wed, 17 Oct 2001 22:55:56 -0700 Received: from mail.sonytel.be (main.sonytel.be [195.0.45.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I5toD17765 for ; Wed, 17 Oct 2001 22:55:50 -0700 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id HAA26208; Thu, 18 Oct 2001 07:54:34 +0200 (MET DST) Date: Thu, 18 Oct 2001 07:54:18 +0200 (MEST) From: Geert Uytterhoeven To: Atsushi Nemoto cc: raiko@niisi.msk.ru, hli@quicklogic.com, Linux/MIPS Development Subject: Re: IDE DMA mode in Big endian for mips In-Reply-To: <20011018.111843.41626947.nemoto@toshiba-tops.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1109 Lines: 31 On Thu, 18 Oct 2001, Atsushi Nemoto wrote: > >>>>> On Wed, 17 Oct 2001 20:43:58 +0900 (JST), Atsushi Nemoto said: > nemoto> Yes, I depend on hardware swapping on word/dword access. It > nemoto> seems many pci drivers depend on this swapping too. > > Sorry, last sentence might be wrong. I doubt I have been > misunderstanding long time... > > Can anybody explain me a PCI driver's policy of endianness? Should we > use cpu_to_le32 with outl/writel? Should we use cpu_to_le32 to write > 32bit data to DMA area? The PCI bus is little-endian. All accesses should be done using one of - {read,write}[bwlq]: PCI memory space - {in,out}[bwl]: PCI (and ISA) I/O space - isa_{read,write}[bwl]: ISA memory space The functions above should take care of endian conversion. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Thu Oct 18 03:37:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IAbCX24458 for linux-mips-outgoing; Thu, 18 Oct 2001 03:37:12 -0700 Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IAb8D24448 for ; Thu, 18 Oct 2001 03:37:08 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id OAA11970; Thu, 18 Oct 2001 14:36:53 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA10851; Thu, 18 Oct 2001 14:32:52 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA23636; Thu, 18 Oct 2001 13:32:07 +0300 (MSK) Message-ID: <3BCEAFFD.3EDDBE29@niisi.msk.ru> Date: Thu, 18 Oct 2001 14:33:33 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Atsushi Nemoto CC: hli@quicklogic.com, linux-mips@oss.sgi.com Subject: Re: IDE DMA mode in Big endian for mips References: <20011017.113842.41627007.nemoto@toshiba-tops.co.jp> <3BCD506F.9683F0E8@niisi.msk.ru> <20011017.204358.39150084.nemoto@toshiba-tops.co.jp> <20011018.111843.41626947.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 908 Lines: 24 Atsushi Nemoto wrote: > Can anybody explain me a PCI driver's policy of endianness? It depens on device and board. Most drivers assume PCI is little-endian, but rely on outl implementation in byte swapping policy. > Should we use cpu_to_le32 with outl/writel? If you can't instruct hw to perform byte-swapping for PCI IO, you have to add cpu_to_le32, it's clear. For writel, i.e. PCI MEM the situation is a bit subtle. The problem is your videocard, that may or may not support byte swapping. So, in order to suport videocards that aren't able to swap bytes, you have to setup PCI MEM in big-endian mode. Look, for example, at the tulip driver, it swaps bytes for DMA and doesn't do it for register access. > Should we use cpu_to_le32 to write 32bit data to DMA area? DMA data is stream of bytes. I would treat a device/board as broken, if it would need byte swapping for DMA data. Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Oct 18 07:33:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IEXPv29258 for linux-mips-outgoing; Thu, 18 Oct 2001 07:33:25 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IEXGD29248 for ; Thu, 18 Oct 2001 07:33:17 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.2/8.11.2) id f9IEa6S29906 for linux-mips@oss.sgi.com; Thu, 18 Oct 2001 16:36:06 +0200 Date: Thu, 18 Oct 2001 16:36:05 +0200 From: Lukas Hejtmanek To: linux-mips@oss.sgi.com Subject: Origin 200 Message-ID: <20011018163605.F1089@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9IEa6S29906 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9IEXHD29249 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3472 Lines: 83 I've finally got our origin to load linux kernel via bootp/tftp (Btw, it _must_ be the same server for bootp and tftp?) I have my cross cimpiled kernel 2.4.9. Kernel options are: root=/dev/nfs ip=... nfsroot=... init=/bin/bash However it never boots up. At random place it freezes. Sometimes without any oops genereated sometimes with. I've also tried kernel from ftp site - kernel/test/origin - linux-2.4.2. same behaviour. Is there something I could do? Is that ok that cpu clock is 65535MHz? kernel messages: 1457776 +451040 5448 entry: 0xa800000000184000 ARCH: SGI-IP27 PROMLIB: ARC firmware Version 64 Revision 0 Discovered 1 cpus on 1 nodes Total memory probed : 0x4000 pages Linux version 2.4.2 (ralf@cashcow) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #4 SMP Tue Mar 20 00:33:52 MET 2001 Loading R10000 MMU routines. CPU revision is: 00000926 Primary instruction cache 32kb, linesize 64 bytes Primary data cache 32kb, linesize 32 bytes Secondary cache sized at 1024K, linesize 128 IP27: Running on node 0. Node 0 has a primary CPU, CPU is running. Node 0 has no secondary CPU. Machine is in M mode. Cpu 0, Nasid 0x0, pcibr_setup(): found partnum= 0xc002...is bridge CPU 0 clock is 65535MHz. On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/nfs ip=147.251.48.209:147.251.48.208:147.251.48.14:255.255.255.0 nfsr Entering 64-bit mode. Calibrating delay loop... 179.81 BogoMIPS Memory: 60824k/65536k available (1423k kernel code, 4712k reserved, 184k data, 220k init) Dentry-cache hash table entries: 8192 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 3, 32768 bytes) Page-cache hash table entries: 16384 (order: 5, 131072 bytes) Inode-cache hash table entries: 4096 (order: 4, 65536 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX REPLICATION: ON nasid 0, ktext from nasid 0, kdata from nasid 0 PCI: Probing PCI hardware hts. PCI: Fixing isp1020 in [bus:lot.fn] 00:00.0 PCI: Fixing isp1020 in [bus:slot.fn] 00:01.0 PCI: Fixing base addresses for IOC3 device 00:02.0 PCI: Fixing isp1020 in [bus:slot.fn] 00:05.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 40114kB/13371kB, 128 slots per queue Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0x9200000008620178 (irq = 0) is a 16550A Got dbe at 0xffffffff80142fc8 Cpu 0 $0 : 0000000000000000 0000000014201ce0 9200000001000108 000000000022b6b8 $4 : 9200000001030100 9200000001000108 ffffffff802117e0 0000000000000000 $8 : 0000000000000001 0000000000000000 ffffffff802117e0 0000000000000008 $12 : 0000000014201ce0 000000001000001f 0000000000000008 ffffffff80177aa0 $16 : 0000000000000000 0000000000000790 a8000000012fbcc0 ffffffff801cfda8 $20 : ffffffff8020d498 a8000000012c0220 a8000000012c0000 a500000000000000 $24 : 0000000000000020 0000000000000000 $28 : a8000000012f8000 a8000000012fbc90 000000ffffffffff ffffffff801418e0 Hi : 0000000000000000 Lo : 0000000000000008 epc : ffffffff80142fc8 badvaddr: ffffffff800ee714 badvaddr: ffffffff800ee714 Status : 14201ce2 Cause : 0000901c Cause : 0000901c Index: 0 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] ..... -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Thu Oct 18 16:03:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9IN36l08564 for linux-mips-outgoing; Thu, 18 Oct 2001 16:03:06 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9IN30D08561 for ; Thu, 18 Oct 2001 16:03:00 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.2/8.11.2) id f9IN5er01625; Fri, 19 Oct 2001 01:05:40 +0200 Date: Fri, 19 Oct 2001 01:05:40 +0200 From: Lukas Hejtmanek To: Wilbern Cobb Cc: linux-mips@oss.sgi.com Subject: Re: Origin 200[B Message-ID: <20011019010540.I1089@mail.muni.cz> References: <20011018163605.F1089@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from vedge@csoft.org on Thu, Oct 18, 2001 at 07:50:14PM -0300 X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9IN5er01625 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9IN31D08562 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1715 Lines: 48 On Thu, Oct 18, 2001 at 07:50:14PM -0300, Wilbern Cobb wrote: > > I've finally got our origin to load linux kernel via bootp/tftp (Btw, it > > _must_ be the same server for bootp and tftp?) > > I'm using different bootp and tftp/nfs servers without problems. My router > serves bootp, bootparam, rarp, and my development box serves NFS and tftp. However, my origin only boots if tftp server runs on the same server as bootp if 'sa' option in bootptab is present origin does not boot. > Interesting. Just a guess, have you tried disabling the serial driver? The > faulty address is a kernel one, that's all I can deduce from that panic. > I need to get one of these boxes some day.. I can try, but origin have only serial console so will I see output if I disable the serial driver? 2 times the last message seen from kernel was: Memory: 60824k/65536k available (1423k kernel code, 4712k reserved, 184k data, 220k init) And nothing more, no oops. once the last message was about serial ports (two detected) and nothing more. [ cut ] Initializing RT netlink socket Starting kswapd v1.8 pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at iomem 0x9200000008620178 (irq = 0) is a 16550A ttyS01 at iomem 0x9200000008620170 (irq = 0) is a 16550A Ass well nothing more just stoped. for fourth time it writed: .... [ cut ]... Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Unhandled kernel unaligned access: 0000 Cpu 0 $0 : 0000000000000000 ffffffffc11f0000 0000000000000003 a80000000025be6 So it did oops before kswapd started. fifth time message I've already posted. -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Thu Oct 18 17:57:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J0vaZ10382 for linux-mips-outgoing; Thu, 18 Oct 2001 17:57:36 -0700 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J0vXD10379 for ; Thu, 18 Oct 2001 17:57:33 -0700 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 19 Oct 2001 00:59:07 UT Received: from bud.austin.esstech.com ([193.5.206.3]) by mail.esstech.com (8.8.8+Sun/8.8.8) with SMTP id RAA24872 for ; Thu, 18 Oct 2001 17:56:05 -0700 (PDT) Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id TAA24559; Thu, 18 Oct 2001 19:55:18 -0500 Message-ID: <3BCF7AD2.2000000@esstech.com> Date: Thu, 18 Oct 2001 19:58:58 -0500 From: Gerald Champagne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Moving kernel_entry to LOADADDR Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1028 Lines: 23 I'm planning to work with a very minimal boot loader, and I'd like to hard-code a jump to kernel_entry in my boot loader. I got tired of having kernel_entry moving around, so I just moved it to the top of head.S, just afte the ".fill 0x280". That places kernel_entry at the same place every time. It's always at LOADADDR+0x280. But wait a minute... the 0x280 is there to leave room for the exception vectors. Doesn't that only make sense if LOADADDR=0x80000000? Isn't this allocating the space for the exception vectors twice? Why not remove the .fill, then the kernel entry point will always be exactly LOADADDR? This would break any configuration that has LOADADDR=0x80000000, but the only configuration like that is CONFIG_ALGOR_P4032, and that could easily be modified to LOADADDR=0x80000280 to get the same effect. I also removed the .fill, and now kernel_entry is always exactly LOADADDR, and that makes my bootloader easier to maintain. Is this worth changing in cvs, or did I miss something? Thanks. Gerald From owner-linux-mips@oss.sgi.com Thu Oct 18 18:13:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J1DRd10693 for linux-mips-outgoing; Thu, 18 Oct 2001 18:13:27 -0700 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J1DPD10689 for ; Thu, 18 Oct 2001 18:13:25 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id SAA64191; Thu, 18 Oct 2001 18:13:22 -0700 (PDT) Date: Thu, 18 Oct 2001 18:13:22 -0700 From: Geoffrey Espin To: Gerald Champagne Cc: "linux-mips@oss.sgi.com" Subject: Re: Moving kernel_entry to LOADADDR Message-ID: <20011018181322.B56244@idiom.com> References: <3BCF7AD2.2000000@esstech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <3BCF7AD2.2000000@esstech.com>; from Gerald Champagne on Thu, Oct 18, 2001 at 07:58:58PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 648 Lines: 20 Gerald, > to hard-code a jump to kernel_entry in my boot loader. I got tired > of having kernel_entry moving around, so I just moved it to the top > of head.S, just afte the ".fill 0x280". That places kernel_entry at > the same place every time. It's always at LOADADDR+0x280. Don't know about all .fill & exception vecs... the trick I use in my (vr)boot loader... KERNEL_ENTRY=$(shell awk '/kernel_entry/{print "0x" $$1}' $(LINUX_SRC)/System.map) CFLAGS+=-DKERNEL_ENTRY=$(KERNEL_ENTRY) And compile boot.S or whatever your bootloader is. But a fixed, well-known offset can't be a bad thing either. Geoff -- Geoffrey Espin espin@idiom.com From owner-linux-mips@oss.sgi.com Thu Oct 18 18:57:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J1vKo12187 for linux-mips-outgoing; Thu, 18 Oct 2001 18:57:20 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J1vID12184 for ; Thu, 18 Oct 2001 18:57:19 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 3BBF8125C3; Thu, 18 Oct 2001 18:57:17 -0700 (PDT) Date: Thu, 18 Oct 2001 18:57:17 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: Strange behavior of serial console under 2.4.9 Message-ID: <20011018185717.A8135@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 129 Lines: 5 The serial console under 2.4.9 is very strange. It is very slow. I have no such problem with 2.4.3/2.4.5. Telnet is fine. H.J. From owner-linux-mips@oss.sgi.com Thu Oct 18 19:11:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J2BEi12473 for linux-mips-outgoing; Thu, 18 Oct 2001 19:11:14 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J2BBD12470 for ; Thu, 18 Oct 2001 19:11:12 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 58C9E590A9; Thu, 18 Oct 2001 18:09:14 -0400 (EDT) Message-ID: <007201c15843$57067a60$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "H . J . Lu" , References: <20011018185717.A8135@lucon.org> Subject: Re: Strange behavior of serial console under 2.4.9 Date: Thu, 18 Oct 2001 22:11:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 432 Lines: 16 I haven't noticed that. I just ran top with 0 delay at 115200 and it seems normally fast to me. Regards, Brad ----- Original Message ----- From: "H . J . Lu" To: Sent: Thursday, October 18, 2001 9:57 PM Subject: Strange behavior of serial console under 2.4.9 > The serial console under 2.4.9 is very strange. It is very slow. I have > no such problem with 2.4.3/2.4.5. Telnet is fine. From owner-linux-mips@oss.sgi.com Thu Oct 18 19:40:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J2eH113208 for linux-mips-outgoing; Thu, 18 Oct 2001 19:40:17 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J2eGD13205 for ; Thu, 18 Oct 2001 19:40:16 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id E247E125C3; Thu, 18 Oct 2001 19:40:14 -0700 (PDT) Date: Thu, 18 Oct 2001 19:40:14 -0700 From: "H . J . Lu" To: "Bradley D. LaRonde" Cc: linux-mips@oss.sgi.com Subject: Re: Strange behavior of serial console under 2.4.9 Message-ID: <20011018194014.A8744@lucon.org> References: <20011018185717.A8135@lucon.org> <007201c15843$57067a60$3501010a@ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <007201c15843$57067a60$3501010a@ltc.com>; from brad@ltc.com on Thu, Oct 18, 2001 at 10:11:18PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 326 Lines: 11 On Thu, Oct 18, 2001 at 10:11:18PM -0400, Bradley D. LaRonde wrote: > I haven't noticed that. I just ran top with 0 delay at 115200 and it seems > normally fast to me. > I am using 9600 buad. It used to be ok under 2.4.3/2.4.5. But under 2.4.9, the first 10 minutes after boot is very slow. After that, it seems ok. H.J. From owner-linux-mips@oss.sgi.com Thu Oct 18 23:13:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J6DWP17189 for linux-mips-outgoing; Thu, 18 Oct 2001 23:13:32 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J6DUD17186 for ; Thu, 18 Oct 2001 23:13:30 -0700 Received: from adsl.pacbell.net ([10.2.2.20]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9J6FBB18238; Thu, 18 Oct 2001 23:15:11 -0700 Subject: Re: [Linux-mips-kernel]PATCH From: Pete Popov To: Geoffrey Espin Cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com X-Sieve: cmu-sieve 2.0 References: <3BC24525.8030201@mvista.com> X-Mailer: Mutt 0.95.1i In-Reply-To: <3BC24525.8030201@mvista.com>; from Pete Popov on Mon, Oct 08, 2001 at 05:30:29PM -0700 In-Reply-To: <20011016115059.A29701@idiom.com> References: <3BC24525.8030201@mvista.com> <20011016115059.A29701@idiom.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15.99+cvs.2001.10.09.08.08 (Preview Release) Date: 18 Oct 2001 23:12:01 -0700 Message-Id: <1003471921.1184.4.camel@adsl.pacbell.net> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1074 Lines: 28 On Tue, 2001-10-16 at 11:50, Geoffrey Espin wrote: > Pete, > > > I've attached a patch which adds zImage support for the Alchemy pb1000 board. > > The image is burned in flash and yamon can be used to just jump to that location > >... > > Feedback would be appreciated, including whether or not arch/mips/zboot is the > > most appropriate place to put the zImage support. > > It ain't a pretty patch. I do want to do this for the Korva-Markham > board... either arch/arm/boot/compressed or arch/ppc/boot scheme > would be nice to follow. I ported the code from arch/ppc/boot, so if you like that scheme, what is it that you don't like about the patch I sent? The directory structure is the same as arch/ppc/boot, and the generic code is the same as well. > I think arch/ppc/boot/mbx/Makefile does > some of the magic offset stuff you need with quick `sh ` scripts > and also includes piggyback initrd stuff! I picked arch/ppc/boot/sandpoint, which does the offset stuff with standard compiler tools, like objdump. The initrd stuff can be added easily. Pete From owner-linux-mips@oss.sgi.com Thu Oct 18 23:37:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J6brn17747 for linux-mips-outgoing; Thu, 18 Oct 2001 23:37:53 -0700 Received: from dea.linux-mips.net (a1as03-p59.stg.tli.de [195.252.186.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J6boD17744 for ; Thu, 18 Oct 2001 23:37:51 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9J6bd327148; Fri, 19 Oct 2001 08:37:39 +0200 Date: Fri, 19 Oct 2001 08:37:39 +0200 From: Ralf Baechle To: Peter Andersson Cc: linux-mips@oss.sgi.com Subject: Re: Linux 2.4 kernel with sound support Message-ID: <20011019083739.A26998@dea.linux-mips.net> References: <5.1.0.14.0.20011016193856.00a518e0@192.168.1.5> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20011016193856.00a518e0@192.168.1.5>; from peter@dark-past.mine.nu on Tue, Oct 16, 2001 at 07:42:38PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 448 Lines: 11 On Tue, Oct 16, 2001 at 07:42:38PM +0200, Peter Andersson wrote: > Does anyone know where i can find a mips linux 2.4 kernel with audio > support? I am running an sgi indy with a R5000 processor, but kernels > compiled for R4400 works great. R4x00 / R5000 difference are very minor. A sound driver only exists in ALSA but that one is for a pretty dated kernel; somebody is currently trying himself on updating it for a current kernel. Ralf From owner-linux-mips@oss.sgi.com Fri Oct 19 02:18:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J9ID021532 for linux-mips-outgoing; Fri, 19 Oct 2001 02:18:13 -0700 Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J9I9D21526 for ; Fri, 19 Oct 2001 02:18:10 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA31634; Fri, 19 Oct 2001 13:18:12 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA15576; Fri, 19 Oct 2001 13:16:35 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id KAA26371; Fri, 19 Oct 2001 10:29:02 +0300 (MSK) Message-ID: <3BCFD6C0.6035210C@niisi.msk.ru> Date: Fri, 19 Oct 2001 11:31:12 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Gerald Champagne CC: "linux-mips@oss.sgi.com" Subject: Re: Moving kernel_entry to LOADADDR References: <3BCF7AD2.2000000@esstech.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 378 Lines: 10 Gerald Champagne wrote: > Is this worth changing in cvs, or did I miss something? Embed your kernel in your own bootloader, load the bootloader from fixed addr. In the bootloader move the kernel at any location you want and jump to the kernel entry. The kernel entry is known at compile time, so you can teach the bootloader. This way you won't disturb others. Regards, Gleb. From owner-linux-mips@oss.sgi.com Fri Oct 19 02:49:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9J9nMb22401 for linux-mips-outgoing; Fri, 19 Oct 2001 02:49:22 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9J9nJD22397 for ; Fri, 19 Oct 2001 02:49:19 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 19 Oct 2001 09:49:19 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 701DBB46D; Fri, 19 Oct 2001 18:49:17 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id SAA03896; Fri, 19 Oct 2001 18:49:44 +0900 (JST) Date: Fri, 19 Oct 2001 18:54:07 +0900 (JST) Message-Id: <20011019.185407.71082409.nemoto@toshiba-tops.co.jp> To: geert@linux-m68k.org Cc: raiko@niisi.msk.ru, hli@quicklogic.com, linux-mips@oss.sgi.com Subject: Re: IDE DMA mode in Big endian for mips From: Atsushi Nemoto In-Reply-To: References: <20011018.111843.41626947.nemoto@toshiba-tops.co.jp> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 760 Lines: 20 >>>>> On Thu, 18 Oct 2001 07:54:18 +0200 (MEST), Geert Uytterhoeven said: geert> The functions above should take care of endian conversion. This is what I wanted to know. Thank you. >>>>> On Wed, 17 Oct 2001 13:52:20 -0400, "Hanks Li" said: hli> Thanks Atsushi San, the patch did help. The partition check can hli> pass now. Sorry, my patch is not correct. You can configure your PCI controller to swap dword (if your hw have this function), or you can use CONFIG_SWAP_IO_SPACE. If your hardware have not this function AND you want to swap entire I/O access (for example, do swap for PCI, not for other area), you may have to create your own version of outl/outw etc. (This is my case...) --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Fri Oct 19 06:21:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JDLTA26769 for linux-mips-outgoing; Fri, 19 Oct 2001 06:21:29 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JDLED26763 for ; Fri, 19 Oct 2001 06:21:15 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA07780; Fri, 19 Oct 2001 15:20:35 +0200 (MET DST) Date: Fri, 19 Oct 2001 15:20:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: Gerald Champagne cc: "linux-mips@oss.sgi.com" Subject: Re: Moving kernel_entry to LOADADDR In-Reply-To: <3BCF7AD2.2000000@esstech.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 500 Lines: 14 On Thu, 18 Oct 2001, Gerald Champagne wrote: > I also removed the .fill, and now kernel_entry is always exactly LOADADDR, > and that makes my bootloader easier to maintain. > > Is this worth changing in cvs, or did I miss something? How about just getting it from the ELF header? It's trivial. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Oct 19 06:27:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JDRYj26889 for linux-mips-outgoing; Fri, 19 Oct 2001 06:27:34 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JDRRD26885 for ; Fri, 19 Oct 2001 06:27:27 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA07912; Fri, 19 Oct 2001 15:26:12 +0200 (MET DST) Date: Fri, 19 Oct 2001 15:26:10 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: Strange behavior of serial console under 2.4.9 In-Reply-To: <20011018194014.A8744@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 486 Lines: 14 On Thu, 18 Oct 2001, H . J . Lu wrote: > I am using 9600 buad. It used to be ok under 2.4.3/2.4.5. But under > 2.4.9, the first 10 minutes after boot is very slow. After that, it > seems ok. That might be driver-specific. I'm using drivers/tc/zs.c and it works fine at 115200 bps. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Oct 19 06:54:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JDsRv27744 for linux-mips-outgoing; Fri, 19 Oct 2001 06:54:27 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JDsOD27740 for ; Fri, 19 Oct 2001 06:54:24 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id CCD9C590A9; Fri, 19 Oct 2001 05:52:25 -0400 (EDT) Message-ID: <005f01c158a5$960c9660$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "H . J . Lu" Cc: , "Maciej W. Rozycki" References: Subject: Re: Strange behavior of serial console under 2.4.9 Date: Fri, 19 Oct 2001 09:54:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 813 Lines: 28 H.J., which serial driver are you using? Regards, Brad ----- Original Message ----- From: "Maciej W. Rozycki" To: "H . J . Lu" Cc: Sent: Friday, October 19, 2001 9:26 AM Subject: Re: Strange behavior of serial console under 2.4.9 > On Thu, 18 Oct 2001, H . J . Lu wrote: > > > I am using 9600 buad. It used to be ok under 2.4.3/2.4.5. But under > > 2.4.9, the first 10 minutes after boot is very slow. After that, it > > seems ok. > > That might be driver-specific. I'm using drivers/tc/zs.c and it works > fine at 115200 bps. > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > From owner-linux-mips@oss.sgi.com Fri Oct 19 07:59:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JExTU29623 for linux-mips-outgoing; Fri, 19 Oct 2001 07:59:29 -0700 Received: from mail.terraempresas.com.br (mail.terraempresas.com.br [200.177.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JExRD29620 for ; Fri, 19 Oct 2001 07:59:28 -0700 Received: from ricardo (200-207-153-182.dsl.telesp.net.br [200.207.153.182]) by mail.terraempresas.com.br (8.11.6/8.11.2) with SMTP id f9JExKW32635 for ; Fri, 19 Oct 2001 12:59:20 -0200 Reply-To: From: "Ricardo SOuza" To: Subject: Linux for Silicon Graphics Date: Fri, 19 Oct 2001 15:00:59 -0300 Message-ID: <000201c158c8$0319a3c0$0b00a8c0@sci> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <200110191244.f9JCiPN25998@oss.sgi.com> X-MIME-Autoconverted: from 8bit to quoted-printable by mail.terraempresas.com.br id f9JExKW32635 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9JExSD29621 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 84 Lines: 5 I´d like to know what LINUX support SG and If someone can tell their URL! thanks From owner-linux-mips@oss.sgi.com Fri Oct 19 08:04:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JF44b29819 for linux-mips-outgoing; Fri, 19 Oct 2001 08:04:04 -0700 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JF41D29815 for ; Fri, 19 Oct 2001 08:04:01 -0700 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id IAA27477; Fri, 19 Oct 2001 08:11:40 -0700 Message-Id: <200110191511.IAA27477@saturn.mikemac.com> To: "Maciej W. Rozycki" cc: Gerald Champagne , "linux-mips@oss.sgi.com" Subject: Re: Moving kernel_entry to LOADADDR In-Reply-To: Your message of "Fri, 19 Oct 2001 15:20:33 +0200." Date: Fri, 19 Oct 2001 08:11:40 -0700 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 899 Lines: 24 >Date: Fri, 19 Oct 2001 15:20:33 +0200 (MET DST) >From: "Maciej W. Rozycki" >To: Gerald Champagne >Subject: Re: Moving kernel_entry to LOADADDR > >On Thu, 18 Oct 2001, Gerald Champagne wrote: > >> I also removed the .fill, and now kernel_entry is always exactly LOADADDR, >> and that makes my bootloader easier to maintain. >> >> Is this worth changing in cvs, or did I miss something? > > How about just getting it from the ELF header? It's trivial. Because a bare bones bootloader may not know anything about ELF. The simplest solution is to just stick a "jmp start_kernel" at LOADADDR right before the fill. Then the load address and the entry point are the same. Once the exception vectors get loaded, they'll overwrite the jmp, so no space is wasted and none of the LOADADDRs have to be changed. Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Fri Oct 19 08:17:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFHUj30342 for linux-mips-outgoing; Fri, 19 Oct 2001 08:17:30 -0700 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFHQD30339 for ; Fri, 19 Oct 2001 08:17:26 -0700 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 19 Oct 2001 15:19:01 UT Received: from bud.austin.esstech.com ([193.5.206.3]) by mail.esstech.com (8.8.8+Sun/8.8.8) with SMTP id IAA00558; Fri, 19 Oct 2001 08:15:59 -0700 (PDT) Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id KAA00051; Fri, 19 Oct 2001 10:15:08 -0500 Message-ID: <3BD04458.8050200@esstech.com> Date: Fri, 19 Oct 2001 10:18:48 -0500 From: Gerald Champagne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: Mike McDonald , "linux-mips@oss.sgi.com" Subject: Re: Moving kernel_entry to LOADADDR References: <200110191511.IAA27477@saturn.mikemac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1438 Lines: 41 >>How about just getting it from the ELF header? It's trivial. >> > > Because a bare bones bootloader may not know anything about ELF. The > simplest solution is to just stick a "jmp start_kernel" at LOADADDR > right before the fill. Then the load address and the entry point are > the same. Once the exception vectors get loaded, they'll overwrite the > jmp, so no space is wasted and none of the LOADADDRs have to be > changed. That was my thinking. Except the fill has nothing to do with exception vectors any more. It looks like at one time LOADADDR was always 0x8000_0000. Now that it's set to something else, the fill just leaves a hole for no reason. That's why I recommend removing it regardless of whether there's a use for my idea. With the fill is gone, and since the kernel is not normally placed at 0x8000_0000, I suggest just moving kernel_entry to the top of head.S instead of putting a jump at the top of the file. Also, compile tricks won't work (at least in my case). Normally the bootloader and the kernel are in two memories, often programmed in different ways. For example, a system normally has rom at the boot address at 0x1fc0_0000, ram at 0x8000_0000, and some other memory (flash, hard disk, whatever) storing a kernel (or kernels) somewhere else. Any compile time tricks require the boot rom to be reprogrammed when the kernel changes. That's part of what I wanted to avoid. Gerald From owner-linux-mips@oss.sgi.com Fri Oct 19 08:22:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFMa530546 for linux-mips-outgoing; Fri, 19 Oct 2001 08:22:36 -0700 Received: from ux3.sp.cs.cmu.edu (UX3.SP.CS.CMU.EDU [128.2.198.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFMYD30543 for ; Fri, 19 Oct 2001 08:22:34 -0700 Received: from GS256.SP.CS.CMU.EDU by ux3.sp.cs.cmu.edu id aa04924; 19 Oct 2001 11:21 EDT Subject: Re: Moving kernel_entry to LOADADDR From: Justin Carlson To: linux-mips@oss.sgi.com In-Reply-To: <200110191511.IAA27477@saturn.mikemac.com> References: <200110191511.IAA27477@saturn.mikemac.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 19 Oct 2001 11:21:41 -0400 Message-Id: <1003504901.29529.54.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 633 Lines: 16 On Fri, 2001-10-19 at 11:11, Mike McDonald wrote: > Because a bare bones bootloader may not know anything about ELF. The > simplest solution is to just stick a "jmp start_kernel" at LOADADDR > right before the fill. Then the load address and the entry point are > the same. Once the exception vectors get loaded, they'll overwrite the > jmp, so no space is wasted and none of the LOADADDRs have to be > changed. This may be true, but grokking ELF far enough to find e_entry just a matter of looking at a fixed offset into the kernel image. Problems that require bootloaders to be simpler than that are pretty rare... -Justin From owner-linux-mips@oss.sgi.com Fri Oct 19 08:46:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFkXT31301 for linux-mips-outgoing; Fri, 19 Oct 2001 08:46:33 -0700 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFkTD31297 for ; Fri, 19 Oct 2001 08:46:29 -0700 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id IAA27669; Fri, 19 Oct 2001 08:56:04 -0700 Message-Id: <200110191556.IAA27669@saturn.mikemac.com> To: Justin Carlson cc: linux-mips@oss.sgi.com Subject: Re: Moving kernel_entry to LOADADDR In-Reply-To: Your message of "19 Oct 2001 11:21:41 EDT." <1003504901.29529.54.camel@gs256.sp.cs.cmu.edu> Date: Fri, 19 Oct 2001 08:56:04 -0700 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1245 Lines: 31 >Subject: Re: Moving kernel_entry to LOADADDR >From: Justin Carlson >To: linux-mips@oss.sgi.com >Date: 19 Oct 2001 11:21:41 -0400 > >On Fri, 2001-10-19 at 11:11, Mike McDonald wrote: > >> Because a bare bones bootloader may not know anything about ELF. The >> simplest solution is to just stick a "jmp start_kernel" at LOADADDR >> right before the fill. Then the load address and the entry point are >> the same. Once the exception vectors get loaded, they'll overwrite the >> jmp, so no space is wasted and none of the LOADADDRs have to be >> changed. > > >This may be true, but grokking ELF far enough to find e_entry just a >matter of looking at a fixed offset into the kernel image. Problems >that require bootloaders to be simpler than that are pretty rare... > >-Justin But they do exist, especially in the embedded world. For instance, I've run linux with boot loader out of a 1MB flash into 8MB of RAM. (VR4121 based system.) The kernel image stored in the flash had to be a compressed raw memory image inorder to fit in the flash. (The flash also had to have room to the initrd.) Adding ELF headers to the image would probably have pushed the size over the limit. Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Fri Oct 19 08:51:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFpw631576 for linux-mips-outgoing; Fri, 19 Oct 2001 08:51:58 -0700 Received: from dea.linux-mips.net (a1as03-p40.stg.tli.de [195.252.186.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFprD31573 for ; Fri, 19 Oct 2001 08:51:53 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9JFlOp27413; Fri, 19 Oct 2001 17:47:24 +0200 Date: Fri, 19 Oct 2001 17:47:24 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: Strange behavior of serial console under 2.4.9 Message-ID: <20011019174724.A27300@dea.linux-mips.net> References: <20011018194014.A8744@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Oct 19, 2001 at 03:26:10PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 418 Lines: 13 On Fri, Oct 19, 2001 at 03:26:10PM +0200, Maciej W. Rozycki wrote: > > I am using 9600 buad. It used to be ok under 2.4.3/2.4.5. But under > > 2.4.9, the first 10 minutes after boot is very slow. After that, it > > seems ok. > > That might be driver-specific. I'm using drivers/tc/zs.c and it works > fine at 115200 bps. I haven't noticed this problem ever on Origins which use the standard 16550 driver. Ralf From owner-linux-mips@oss.sgi.com Fri Oct 19 08:55:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFtMo31739 for linux-mips-outgoing; Fri, 19 Oct 2001 08:55:22 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFtKD31736 for ; Fri, 19 Oct 2001 08:55:20 -0700 Received: from preferredlease.com ([208.144.232.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA18896 for ; Fri, 19 Oct 2001 08:55:15 -0700 (PDT) mail_from (rclarke2@preferredlease.com) Date: Fri, 19 Oct 2001 08:55:15 -0700 (PDT) From: rclarke2@preferredlease.com Message-Id: <200110191555.IAA18896@deliverator.sgi.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=200110190759=" To: linux-mips@oss.sgi.com X-Mailer: 32E56E9A.7DD4A151.58b6c3aba7825091358b7c94e2a8dfa5 Subject: Quick Question Organization: Preferred Lease, A CapitalWerks Company Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1101 Lines: 18 --=200110190759= Content-Type: text/plain;charset=US-ASCII TO: linux-mips@oss.sgi.com I hope I'm contacting the right person here. My name is Randell Clarke and I wanted to ask if you were looking for any equipment, new or used, for either yourself or for your customers that I might help finance. My company, Preferred Lease, does anything from company vehicles, to printing and industrial equipment, to construction equipment and heavy machinery, to computers, software and furniture-- basically anything you can use for your business, and work with the "tough credits" that a lot of banks and financial companies do not want to spend time on, in addition to the "A" credits. Please give me a call or e-mail me if there's anything on the agenda/wishlist in the next couple months or if you had any questions or just wanted a quick quote. I thank you for your time. Best Regards, Randell Clarke Sales Manager Preferred Lease, A CapitalWerks Company Direct Line- (949) 270-2170 Direct Fax - (949) 270-2171 rclarke2@preferredlease.com www.preferredlease.com www.capitalwerks.com --=200110190759=-- From owner-linux-mips@oss.sgi.com Fri Oct 19 09:53:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JGrvo00705 for linux-mips-outgoing; Fri, 19 Oct 2001 09:53:57 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JGrtD00702 for ; Fri, 19 Oct 2001 09:53:55 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9JGu5B09897; Fri, 19 Oct 2001 09:56:05 -0700 Message-ID: <3BD05A9A.BD06491C@mvista.com> Date: Fri, 19 Oct 2001 09:53:46 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: Strange behavior of serial console under 2.4.9 References: <20011018185717.A8135@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 240 Lines: 10 "H . J . Lu" wrote: > > The serial console under 2.4.9 is very strange. It is very slow. I have > no such problem with 2.4.3/2.4.5. Telnet is fine. > That is usually a symptom when the serial interrupts are not correctly delivered. Jun From owner-linux-mips@oss.sgi.com Fri Oct 19 10:07:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JH7IL01164 for linux-mips-outgoing; Fri, 19 Oct 2001 10:07:18 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JH7HD01161 for ; Fri, 19 Oct 2001 10:07:17 -0700 Received: from galadriel.physik.uni-konstanz.de [134.34.144.79] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 15ud76-0001ut-00; Fri, 19 Oct 2001 19:07:16 +0200 Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15ud75-0000Bu-00; Fri, 19 Oct 2001 19:07:15 +0200 Date: Fri, 19 Oct 2001 19:07:15 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: Linux for Silicon Graphics Message-ID: <20011019190715.B717@galadriel.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <200110191244.f9JCiPN25998@oss.sgi.com> <000201c158c8$0319a3c0$0b00a8c0@sci> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <000201c158c8$0319a3c0$0b00a8c0@sci>; from ricardo@infom.com.br on Fri, Oct 19, 2001 at 03:00:59PM -0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 193 Lines: 5 On Fri, Oct 19, 2001 at 03:00:59PM -0300, Ricardo SOuza wrote: > > I´d like to know what LINUX support SG and If someone can tell their URL! http://oss.sgi.com/mips/mips-howto.html -- Guido From owner-linux-mips@oss.sgi.com Fri Oct 19 10:10:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JHAXK01431 for linux-mips-outgoing; Fri, 19 Oct 2001 10:10:33 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JHAUD01410 for ; Fri, 19 Oct 2001 10:10:30 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 1EED6590A9; Fri, 19 Oct 2001 09:08:29 -0400 (EDT) Message-ID: <015a01c158c0$fa562800$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Jun Sun" , "H . J . Lu" Cc: References: <20011018185717.A8135@lucon.org> <3BD05A9A.BD06491C@mvista.com> Subject: Re: Strange behavior of serial console under 2.4.9 Date: Fri, 19 Oct 2001 13:10:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 663 Lines: 25 Let's try that again... Agreed - I've seen it once where it spit 16 chars, long pause, 16 more chars, etc. This was due to the serial driver not getting interrupts. Regards, Brad ----- Original Message ----- From: "Jun Sun" To: "H . J . Lu" Cc: Sent: Friday, October 19, 2001 12:53 PM Subject: Re: Strange behavior of serial console under 2.4.9 > "H . J . Lu" wrote: > > > > The serial console under 2.4.9 is very strange. It is very slow. I have > > no such problem with 2.4.3/2.4.5. Telnet is fine. > > > > That is usually a symptom when the serial interrupts are not correctly > delivered. From owner-linux-mips@oss.sgi.com Fri Oct 19 10:27:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JHRsT01799 for linux-mips-outgoing; Fri, 19 Oct 2001 10:27:54 -0700 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JHRqD01793 for ; Fri, 19 Oct 2001 10:27:52 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id KAA50547; Fri, 19 Oct 2001 10:27:49 -0700 (PDT) Date: Fri, 19 Oct 2001 10:27:49 -0700 From: Geoffrey Espin To: Pete Popov Cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: [Linux-mips-kernel]PATCH Message-ID: <20011019102749.B36916@idiom.com> References: <3BC24525.8030201@mvista.com> <20011016115059.A29701@idiom.com> <1003471921.1184.4.camel@adsl.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <1003471921.1184.4.camel@adsl.pacbell.net>; from Pete Popov on Thu, Oct 18, 2001 at 11:12:01PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1044 Lines: 26 Pete, > I ported the code from arch/ppc/boot, so if you like that scheme, what > is it that you don't like about the patch I sent? The directory > structure is the same as arch/ppc/boot, and the generic code is the same > as well. I see that PPC now has some of the silly utils where $(shell objdump ...) in the Makefile would be a lot tighter. Other superficial but better ways like subdir-$(CONFIG_) are not used (instead ifdef CONFIG_NEC_PB100 $MAKE -- ugh!). Not sure why using CFLAGS/LOADADDR/.. from arch/mips/Makefile is not done either... dup'ing this is bad. Use "override CFLAGS" if it needs to be re-constructed from GCCFLAGS,CPPFLAGS... Apologies for playing "armchair coder". I'll try to create Korva version... but mine does it without benefit of a separate loader (standalone vrboot style)... which might be a useful standard build option. Seems to me this is way more important than vrxx stuff... which is already done and over... compression/initrd is in its infancy. Geoff -- Geoffrey Espin espin@idiom.com From owner-linux-mips@oss.sgi.com Fri Oct 19 11:11:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JIBeB03322 for linux-mips-outgoing; Fri, 19 Oct 2001 11:11:40 -0700 Received: from thor ([207.246.91.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JIBbD03319 for ; Fri, 19 Oct 2001 11:11:38 -0700 Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA02826; Fri, 19 Oct 2001 14:09:38 -0400 Date: Fri, 19 Oct 2001 14:09:38 -0400 From: "J. Scott Kasten" To: Ricardo SOuza cc: Subject: Re: Linux for Silicon Graphics In-Reply-To: <000201c158c8$0319a3c0$0b00a8c0@sci> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f9JIBdD03320 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 164 Lines: 12 http://oss.sgi.com/mips/ On Fri, 19 Oct 2001, Ricardo SOuza wrote: > > I´d like to know what LINUX support SG and If someone can tell their URL! > > thanks > > From owner-linux-mips@oss.sgi.com Fri Oct 19 11:15:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JIFLF03454 for linux-mips-outgoing; Fri, 19 Oct 2001 11:15:21 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JIFHD03451 for ; Fri, 19 Oct 2001 11:15:17 -0700 Received: from adsl.pacbell.net ([10.2.2.20]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9JIGwB14771; Fri, 19 Oct 2001 11:16:58 -0700 Subject: Re: [Linux-mips-kernel]PATCH From: Pete Popov To: Geoffrey Espin Cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com In-reply-to: <1003471921.1184.4.camel@adsl.pacbell.net>; from Pete Popov on Thu, Oct 18, 2001 at 11:12:01PM -0700 X-Mailer: Mutt 0.95.1i References: <3BC24525.8030201@mvista.com> <20011016115059.A29701@idiom.com> <1003471921.1184.4.camel@adsl.pacbell.net> X-Authentication-warning: oss.sgi.com: mail owned process doing -bs In-Reply-To: <20011019102749.B36916@idiom.com> References: <3BC24525.8030201@mvista.com> <20011016115059.A29701@idiom.com> <1003471921.1184.4.camel@adsl.pacbell.net> <20011019102749.B36916@idiom.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15.99+cvs.2001.10.09.08.08 (Preview Release) Date: 19 Oct 2001 11:13:49 -0700 Message-Id: <1003515229.1184.27.camel@adsl.pacbell.net> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1670 Lines: 43 On Fri, 2001-10-19 at 10:27, Geoffrey Espin wrote: > Pete, > > > I ported the code from arch/ppc/boot, so if you like that scheme, what > > is it that you don't like about the patch I sent? The directory > > structure is the same as arch/ppc/boot, and the generic code is the same > > as well. > > I see that PPC now has some of the silly utils where $(shell > objdump ...) in the Makefile would be a lot tighter. Are you talking about the utils in boot/utils? I suppose you can get rid of those and put everything in the makefile, but I'm not sure it would be cleaner. > Other > superficial but better ways like subdir-$(CONFIG_) are > not used (instead ifdef CONFIG_NEC_PB100 $MAKE -- ugh!). Not > sure why using CFLAGS/LOADADDR/.. from arch/mips/Makefile is not > done either... dup'ing this is bad. Yes, it is. I tried inheriting LOADADDR from arch/mips/Makefile, but it didn't work and I didn't want to spend more time on it. I figured we can clean that up later. > Use "override CFLAGS" if it > needs to be re-constructed from GCCFLAGS,CPPFLAGS... > > Apologies for playing "armchair coder". I'll try to create Korva > version... but mine does it without benefit of a separate loader > (standalone vrboot style)... which might be a useful standard > build option. > > Seems to me this is way more important than vrxx stuff... which > is already done and over... compression/initrd is in its infancy. Certainly on embedded mips boards it is. It seems like every other arch already has compression and initrd support. What I was shooting for with that ppc patch is a reasonable start at having compression / kernel loader support. Pete From owner-linux-mips@oss.sgi.com Fri Oct 19 14:37:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JLbJl08130 for linux-mips-outgoing; Fri, 19 Oct 2001 14:37:19 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JLbED08127 for ; Fri, 19 Oct 2001 14:37:14 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9JLb2E0017450; Fri, 19 Oct 2001 14:37:02 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9JLb1Sq017441; Fri, 19 Oct 2001 14:37:02 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 19 Oct 2001 14:37:00 -0700 (PDT) From: James Simmons To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] various Config.in fixes In-Reply-To: <20011019225745.B28818@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1854 Lines: 48 Both of these are repeated twice in the config options. Please apply these patches to remove this. --- linux-sgi/drivers/i2c/Config.in Fri Oct 19 11:47:49 2001 +++ linux-mips/drivers/i2c/Config.in Thu Jun 21 19:29:32 2001 @@ -27,13 +27,6 @@ fi fi - if [ "$CONFIG_MIPS_ITE8172" = "y" ]; then - dep_tristate 'ITE I2C Algorithm' CONFIG_ITE_I2C_ALGO $CONFIG_I2C - if [ "$CONFIG_ITE_I2C_ALGO" != "n" ]; then - dep_tristate ' ITE I2C Adapter' CONFIG_ITE_I2C_ADAP $CONFIG_ITE_I2C_ALGO - fi - fi - # This is needed for automatic patch generation: sensors code starts here # This is needed for automatic patch generation: sensors code ends here --- linux-sgi/drivers/char/Config.in Fri Oct 19 11:12:40 2001 +++ linux-mips/drivers/char/Config.in Fri Oct 19 11:26:32 2001 @@ -82,24 +82,6 @@ fi bool ' Console on DC21285 serial port' CONFIG_SERIAL_21285_CONSOLE fi - if [ "$CONFIG_MIPS" = "y" ]; then - bool ' TMPTX3912/PR31700 serial port support' CONFIG_SERIAL_TX3912 - dep_bool ' Console on TMPTX3912/PR31700 serial port' CONFIG_SERIAL_TX3912_CONSOLE $CONFIG_SERIAL_TX3912 - bool ' Enable Au1000 UART Support' CONFIG_AU1000_UART - if [ "$CONFIG_AU1000_UART" = "y" ]; then - bool ' Enable Au1000 serial console' CONFIG_AU1000_SERIAL_CONSOLE - fi - fi -fi -if [ "$CONFIG_IT8712" = "y" ]; then - bool 'Enable Qtronix 990P Keyboard Support' CONFIG_QTRONIX_KEYBOARD - if [ "$CONFIG_QTRONIX_KEYBOARD" = "y" ]; then - define_bool CONFIG_IT8172_CIR y - else - bool ' Enable PS2 Keyboard Support' CONFIG_PC_KEYB - fi - bool 'Enable Smart Card Reader 0 Support ' CONFIG_IT8172_SCR0 - bool 'Enable Smart Card Reader 1 Support ' CONFIG_IT8172_SCR1 fi bool 'Unix98 PTY support' CONFIG_UNIX98_PTYS if [ "$CONFIG_UNIX98_PTYS" = "y" ]; then From owner-linux-mips@oss.sgi.com Fri Oct 19 16:58:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JNwvO11145 for linux-mips-outgoing; Fri, 19 Oct 2001 16:58:57 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JNwrD11139 for ; Fri, 19 Oct 2001 16:58:54 -0700 Received: (qmail 17444 invoked from network); 19 Oct 2001 23:58:50 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Oct 2001 23:58:50 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 6F994300095; Sat, 20 Oct 2001 09:58:47 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 54BDE98; Sat, 20 Oct 2001 09:58:47 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: [Linux-mips-kernel]PATCH In-reply-to: Your message of "19 Oct 2001 11:13:49 MST." <1003515229.1184.27.camel@adsl.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Oct 2001 09:58:42 +1000 Message-ID: <26894.1003535922@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 760 Lines: 19 On 19 Oct 2001 11:13:49 -0700, Pete Popov wrote: >On Fri, 2001-10-19 at 10:27, Geoffrey Espin wrote: >> I see that PPC now has some of the silly utils where $(shell >> objdump ...) in the Makefile would be a lot tighter. > >Are you talking about the utils in boot/utils? I suppose you can get >rid of those and put everything in the makefile, but I'm not sure it >would be cleaner. FWIW, the entire kernel build system is being redesigned from scratch for 2.5. In particular all the boot loader stuff is being cleaned up and standardized across architectures (as much as possible). http://sourceforge.net/projects/kbuild Keith Owens, kbuild maintainer (who will soon be bugging this list to test MIPS specific kbuild 2.5 changes). From owner-linux-mips@oss.sgi.com Sun Oct 21 09:11:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9LGBcW16106 for linux-mips-outgoing; Sun, 21 Oct 2001 09:11:38 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9LGBYD16103 for ; Sun, 21 Oct 2001 09:11:34 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 25EA1125C8; Sun, 21 Oct 2001 09:11:27 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id C445CEBA6; Sun, 21 Oct 2001 09:11:25 -0700 (PDT) Date: Sun, 21 Oct 2001 09:11:25 -0700 From: "H . J . Lu" To: Klaus Naumann Cc: linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: The Linux binutils 2.11.92.0.7 is released. Message-ID: <20011021091125.A1774@lucon.org> References: <20011016201334.A31989@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spock@mgnet.de on Sun, Oct 21, 2001 at 04:48:42PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1538 Lines: 34 On Sun, Oct 21, 2001 at 04:48:42PM +0200, Klaus Naumann wrote: > > Hi, > > also with these binutils I still have a problem when compiling mozilla. > Maybe you know what the issue is ... > > make[2]: Entering directory `/mnt/build/mozilla/mozilla/content/build' > rm -f libgkcontent.so > c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion > -Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual > -Wsynth -pedantic -Wno-long-long -pthread -DNDEBUG -DTRIMMED -Wa,-xgot > -shared -Wl,-h -Wl,libgkcontent.so -o libgkcontent.so nsContentDLF.o > nsContentModule.o nsContentHTTPStartup.o -Wl,--whole-archive > ../../dist/lib/libgkconevents_s.a ../../dist/lib/libgkconhtmlcon_s.a > ../../dist/lib/libgkconhtmldoc_s.a ../../dist/lib/libgkconhtmlstyle_s.a > ../../dist/lib/libgkconxmlcon_s.a ../../dist/lib/libgkconxmldoc_s.a > ../../dist/lib/libgkconxsldoc_s.a ../../dist/lib/libgkconxulcon_s.a > ../../dist/lib/libgkconxuldoc_s.a ../../dist/lib/libgkconxultmpl_s.a > ../../dist/lib/libgkconxbl_s.a ../../dist/lib/libgkconbase_s.a > ../../dist/lib/libgkconshared_s.a -Wl,--no-whole-archive -L../../dist/bin > -lgkgfx -L../../dist/bin -lxpcom -L../../dist/bin > -L/mnt/build/mozilla/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread > -ldl -lc -L../../dist/bin -lmozjs > -Wl,--version-script,../../build/unix/gnu-ld-scripts/components-version-script > -ldl -lm -lc It is a known problem if 1. You don't compile shared libraries with -fpic/-fPIC. 2. Even if you do, you may overflow GOT table. H.J. From owner-linux-mips@oss.sgi.com Sun Oct 21 09:43:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9LGhtf16379 for linux-mips-outgoing; Sun, 21 Oct 2001 09:43:55 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9LGhqD16376 for ; Sun, 21 Oct 2001 09:43:52 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15vLnU-0007CG-00; Sun, 21 Oct 2001 17:50:00 +0100 Subject: Re: IDE DMA mode in Big endian for mips To: nemoto@toshiba-tops.co.jp (Atsushi Nemoto) Date: Sun, 21 Oct 2001 17:50:00 +0100 (BST) Cc: hli@quicklogic.com, linux-mips@oss.sgi.com In-Reply-To: <20011017.113842.41627007.nemoto@toshiba-tops.co.jp> from "Atsushi Nemoto" at Oct 17, 2001 11:38:42 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 384 Lines: 10 > return 1; /* try PIO instead of DMA */ > +#if defined(__mips__) && defined(__BIG_ENDIAN) /* XXX mips only? */ > + outl(cpu_to_le32(hwif->dmatable_dma), dma_base + 4); /* PRD table */ > +#else > outl(hwif->dmatable_dma, dma_base + 4); /* PRD table */ > +#endif You should actually just be able to delete the #if stuff. On an LE machine cpu_to_le32() is a null operation From owner-linux-mips@oss.sgi.com Sun Oct 21 23:16:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9M6GFB26973 for linux-mips-outgoing; Sun, 21 Oct 2001 23:16:15 -0700 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9M6GBD26970 for ; Sun, 21 Oct 2001 23:16:12 -0700 Received: from mail2.sony.co.jp (GateKeeper8.Sony.CO.JP [146.215.0.71]) by ns5.sony.co.jp (R8/Sony) with ESMTP id f9M6GAL29936; Mon, 22 Oct 2001 15:16:10 +0900 (JST) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id f9M6G9H02620; Mon, 22 Oct 2001 15:16:09 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail2.sony.co.jp (R8) with ESMTP id f9M6G8A02569; Mon, 22 Oct 2001 15:16:08 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id PAA15409; Mon, 22 Oct 2001 15:20:28 +0900 (JST) Received: from mach0.sm.sony.co.jp (mach0.sm.sony.co.jp [43.2.226.27]) by imail.sm.sony.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA05995; Mon, 22 Oct 2001 15:16:06 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id f9M6G6e11799; Mon, 22 Oct 2001 15:16:06 +0900 (JST) To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: csum_ipv6_magic() X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011022151606V.machida@sm.sony.co.jp> Date: Mon, 22 Oct 2001 15:16:06 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 560 Lines: 20 I guess that csum_ipv6_magic() in include/asm-mips/checksum.h needs "addu %0, $1" at the next of "sltu $1, %0, $1". Without this, you cannot add a carry of the last addtion. --- checksum.h.ORG Mon Oct 22 15:09:32 2001 +++ checksum.h Mon Oct 22 15:09:51 2001 @@ -249,6 +249,7 @@ static __inline__ unsigned short int csu "addu\t%0, $1\n\t" "addu\t%0, %1\n\t" "sltu\t$1, %0, $1\n\t" + "addu\t%0, $1\n\t" ".set\tnoat\n\t" ".set\tnoreorder" : "=r" (sum), "=r" (proto) --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Mon Oct 22 00:49:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9M7nvh27907 for linux-mips-outgoing; Mon, 22 Oct 2001 00:49:57 -0700 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9M7nsD27903 for ; Mon, 22 Oct 2001 00:49:55 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15vZvr-000138-00; Mon, 22 Oct 2001 08:55:35 +0100 Subject: Re: csum_ipv6_magic() To: machida@sm.sony.co.jp (Machida Hiroyuki) Date: Mon, 22 Oct 2001 08:55:35 +0100 (BST) Cc: ralf@uni-koblenz.de (Ralf Baechle), linux-mips@oss.sgi.com In-Reply-To: <20011022151606V.machida@sm.sony.co.jp> from "Machida Hiroyuki" at Oct 22, 2001 03:16:06 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 270 Lines: 6 > I guess that csum_ipv6_magic() in include/asm-mips/checksum.h > needs "addu %0, $1" at the next of "sltu $1, %0, $1". > Without this, you cannot add a carry of the last addtion. Is that actually needed. The final end around carry cannot itself cause a second carry. From owner-linux-mips@oss.sgi.com Mon Oct 22 03:56:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MAuZF31127 for linux-mips-outgoing; Mon, 22 Oct 2001 03:56:35 -0700 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MAuWD31124 for ; Mon, 22 Oct 2001 03:56:32 -0700 Received: from mail3.sony.co.jp (GateKeeper8.Sony.CO.JP [146.215.0.71]) by ns5.sony.co.jp (R8/Sony) with ESMTP id f9MAuLL92717; Mon, 22 Oct 2001 19:56:21 +0900 (JST) Received: from mail3.sony.co.jp (localhost [127.0.0.1]) by mail3.sony.co.jp (R8) with ESMTP id f9MAuL102961; Mon, 22 Oct 2001 19:56:21 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail3.sony.co.jp (R8) with ESMTP id f9MAuK202941; Mon, 22 Oct 2001 19:56:20 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id UAA29581; Mon, 22 Oct 2001 20:00:40 +0900 (JST) Received: from mach0.sm.sony.co.jp (mach0.sm.sony.co.jp [43.2.226.27]) by imail.sm.sony.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA17366; Mon, 22 Oct 2001 19:56:19 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id f9MAuJe12238; Mon, 22 Oct 2001 19:56:19 +0900 (JST) To: alan@lxorguk.ukuu.org.uk Cc: ralf@uni-koblenz.de, linux-mips@oss.sgi.com Subject: Re: csum_ipv6_magic() In-Reply-To: References: <20011022151606V.machida@sm.sony.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011022195619A.machida@sm.sony.co.jp> Date: Mon, 22 Oct 2001 19:56:19 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 653 Lines: 20 From: Alan Cox Subject: Re: csum_ipv6_magic() Date: Mon, 22 Oct 2001 08:55:35 +0100 (BST) > > I guess that csum_ipv6_magic() in include/asm-mips/checksum.h > > needs "addu %0, $1" at the next of "sltu $1, %0, $1". > > Without this, you cannot add a carry of the last addtion. > > Is that actually needed. The final end around carry cannot itself cause > a second carry. I don't know csum_ipv6_magic() in include/asm-mips/checksum.h works fine or not. But if csum_ipv6_magic() doesn't need "addu %0, $1" at next of the final "sltu $1, %0, $1", you can remove the final "sltu $1, %0, $1". --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Mon Oct 22 04:33:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MBXck31768 for linux-mips-outgoing; Mon, 22 Oct 2001 04:33:38 -0700 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MBXRD31764 for ; Mon, 22 Oct 2001 04:33:28 -0700 Received: from mail2.sony.co.jp (GateKeeper8.Sony.CO.JP [146.215.0.71]) by ns5.sony.co.jp (R8/Sony) with ESMTP id f9MBXQL34769; Mon, 22 Oct 2001 20:33:26 +0900 (JST) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id f9MBXQH11745; Mon, 22 Oct 2001 20:33:26 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail2.sony.co.jp (R8) with ESMTP id f9MBXPA11735; Mon, 22 Oct 2001 20:33:25 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id UAA00769; Mon, 22 Oct 2001 20:37:45 +0900 (JST) Received: from mach0.sm.sony.co.jp (mach0.sm.sony.co.jp [43.2.226.27]) by imail.sm.sony.co.jp (8.9.3+3.2W/3.7W) with ESMTP id UAA18717; Mon, 22 Oct 2001 20:33:24 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id f9MBXOe12286; Mon, 22 Oct 2001 20:33:24 +0900 (JST) To: alan@lxorguk.ukuu.org.uk, ralf@uni-koblenz.de Cc: linux-mips@oss.sgi.com Subject: Re: csum_ipv6_magic() In-Reply-To: <20011022195619A.machida@sm.sony.co.jp> References: <20011022151606V.machida@sm.sony.co.jp> <20011022195619A.machida@sm.sony.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011022203324G.machida@sm.sony.co.jp> Date: Mon, 22 Oct 2001 20:33:24 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2504 Lines: 103 I found bugs in checksum.h. A sample fix is attached below. I perfer to use generic csum_ipv6_magic() in net/checksum.h than this fix. Please someone show me improvements for this asm version of csum_ipv6_magic(). --- Hiroyuki Machida Sony Corp. ChangLog entry: * (csum_ipv6_magic): Have same paramter types as net/checksum.h. Correct carry computation. Add a final carry. Index: checksum.h =================================================================== RCS file: /cvs/linux/include/asm-mips/checksum.h,v retrieving revision 1.12 diff -u -p -r1.12 checksum.h --- checksum.h 2001/10/06 19:29:25 1.12 +++ checksum.h 2001/10/22 11:16:05 @@ -197,7 +197,7 @@ static inline unsigned short ip_compute_ #define _HAVE_ARCH_IPV6_CSUM static __inline__ unsigned short int csum_ipv6_magic(struct in6_addr *saddr, struct in6_addr *daddr, - __u32 len, + unsigned short len, unsigned short proto, unsigned int sum) { @@ -211,49 +211,51 @@ static __inline__ unsigned short int csu "addu\t%0, %6\t\t\t# csum\n\t" "sltu\t$1, %0, %6\n\t" "lw\t%1, 0(%2)\t\t\t# four words source address\n\t" - "addu\t%0, $1\n\t" + " addu\t%0, $1\n\t" "addu\t%0, %1\n\t" - "sltu\t$1, %0, $1\n\t" + "sltu\t$1, %0, %1\n\t" "lw\t%1, 4(%2)\n\t" - "addu\t%0, $1\n\t" + " addu\t%0, $1\n\t" "addu\t%0, %1\n\t" - "sltu\t$1, %0, $1\n\t" + "sltu\t$1, %0, %1\n\t" "lw\t%1, 8(%2)\n\t" - "addu\t%0, $1\n\t" + " addu\t%0, $1\n\t" "addu\t%0, %1\n\t" - "sltu\t$1, %0, $1\n\t" + "sltu\t$1, %0, %1\n\t" "lw\t%1, 12(%2)\n\t" - "addu\t%0, $1\n\t" + " addu\t%0, $1\n\t" "addu\t%0, %1\n\t" - "sltu\t$1, %0, $1\n\t" + "sltu\t$1, %0, %1\n\t" "lw\t%1, 0(%3)\n\t" - "addu\t%0, $1\n\t" + " addu\t%0, $1\n\t" "addu\t%0, %1\n\t" - "sltu\t$1, %0, $1\n\t" + "sltu\t$1, %0, %1\n\t" "lw\t%1, 4(%3)\n\t" - "addu\t%0, $1\n\t" + " addu\t%0, $1\n\t" "addu\t%0, %1\n\t" - "sltu\t$1, %0, $1\n\t" + "sltu\t$1, %0, %1\n\t" "lw\t%1, 8(%3)\n\t" - "addu\t%0, $1\n\t" + " addu\t%0, $1\n\t" "addu\t%0, %1\n\t" - "sltu\t$1, %0, $1\n\t" + "sltu\t$1, %0, %1\n\t" "lw\t%1, 12(%3)\n\t" - "addu\t%0, $1\n\t" + " addu\t%0, $1\n\t" "addu\t%0, %1\n\t" - "sltu\t$1, %0, $1\n\t" + "sltu\t$1, %0, %1\n\t" + " addu\t%0, $1\n\t" + ".set\tnoat\n\t" ".set\tnoreorder" : "=r" (sum), "=r" (proto) : "r" (saddr), "r" (daddr), - "0" (htonl(len)), "1" (htonl(proto)), "r" (sum)); + "0" (htonl((__u32)len)), "1" (htonl(proto)), "r" (sum)); return csum_fold(sum); } From owner-linux-mips@oss.sgi.com Mon Oct 22 05:07:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MC76832386 for linux-mips-outgoing; Mon, 22 Oct 2001 05:07:06 -0700 Received: from mail.minus-9.com (IDENT:postfix@minus-9.com [195.26.32.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MC72D32382 for ; Mon, 22 Oct 2001 05:07:02 -0700 Received: by mail.minus-9.com (Postfix, from userid 500) id 822B9FB4A; Mon, 22 Oct 2001 13:06:59 +0100 (BST) Date: Mon, 22 Oct 2001 13:06:59 +0100 From: Mat Withers To: linux-mips@oss.sgi.com Subject: First attempt to install Linux on my Indigo 2 Message-ID: <20011022130659.B20721@minus-9.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1090 Lines: 23 Hi I've been subscribed to the list for quite a while but am just about to try installing Linux on my Indigo2 (R4400SC / 128Mb RAM) for the first time. I want to try H J Lu's port of Radhat 7.1. I've read the the howto at http://oss.sgi.com/mips/mips-howto.html, have set up a tftp server a bootp server an nfs server and have made up a working serial cable. Now having browsed ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ I am unsure what to do next. I assume I will need a kernel image and a root filing system to nfs mount but can't see anything resembling them on the ftp site. I have a spare 4Gb scsi disk that I want to attempt the install on. I assume that once I have got the machine booted using an nfs root I can partion the hard disk - somehow install the RPMS on it and then use dvhtool to get my SGI to boot from the hard disk. Is this all feasible ? has anyone got any hints or gottcha's ? Thanks in advance for any help Cheers Mat -- Mat Withers mat@minus-9.com http://minus-9.com phone/fax: +44 07092 375299 "a sarcasm detector, *that's* a real useful invention." From owner-linux-mips@oss.sgi.com Mon Oct 22 12:30:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MJU4m13735 for linux-mips-outgoing; Mon, 22 Oct 2001 12:30:04 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MJU1D13723 for ; Mon, 22 Oct 2001 12:30:01 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7703F125C8; Mon, 22 Oct 2001 12:19:19 -0700 (PDT) Date: Mon, 22 Oct 2001 12:19:19 -0700 From: "H . J . Lu" To: Mat Withers Cc: linux-mips@oss.sgi.com Subject: Re: First attempt to install Linux on my Indigo 2 Message-ID: <20011022121919.A27925@lucon.org> References: <20011022130659.B20721@minus-9.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011022130659.B20721@minus-9.com>; from mat@minus-9.com on Mon, Oct 22, 2001 at 01:06:59PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1228 Lines: 26 On Mon, Oct 22, 2001 at 01:06:59PM +0100, Mat Withers wrote: > Hi > > I've been subscribed to the list for quite a while but am just about to try installing Linux on my Indigo2 (R4400SC / 128Mb RAM) for the first time. > > I want to try H J Lu's port of Radhat 7.1. I've read the the howto at http://oss.sgi.com/mips/mips-howto.html, have set up a tftp server a bootp server an nfs server and have made up a working serial cable. Now having browsed ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ I am unsure what to do next. I assume I will need a kernel image and a root filing system to nfs mount but can't see anything resembling them on the ftp site. 1. You need to find a working kernel for your machine. I don't have one. 2. In README: 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. > > I have a spare 4Gb scsi disk that I want to attempt the install on. I assume that once I have got the machine booted using an nfs root I can partion the hard disk - somehow install the RPMS on it and then use dvhtool to get my SGI to boot from the hard disk. > >From README: 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. H.J. From owner-linux-mips@oss.sgi.com Mon Oct 22 13:43:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MKh9I15909 for linux-mips-outgoing; Mon, 22 Oct 2001 13:43:09 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MKh4D15905 for ; Mon, 22 Oct 2001 13:43:04 -0700 Received: from scotty.mgnet.de (pD9024741.dip.t-dialin.net [217.2.71.65]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id WAA09121 for ; Mon, 22 Oct 2001 22:43:02 +0200 (MET DST) Received: (qmail 32254 invoked from network); 22 Oct 2001 20:43:01 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 22 Oct 2001 20:43:01 -0000 Date: Mon, 22 Oct 2001 22:43:00 +0200 (CEST) From: Klaus Naumann To: "H . J . Lu" cc: linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: The Linux binutils 2.11.92.0.7 is released. In-Reply-To: <20011021091125.A1774@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2001 Lines: 48 On Sun, 21 Oct 2001, H . J . Lu wrote: > On Sun, Oct 21, 2001 at 04:48:42PM +0200, Klaus Naumann wrote: > > > > Hi, > > > > also with these binutils I still have a problem when compiling mozilla. > > Maybe you know what the issue is ... > > > > make[2]: Entering directory `/mnt/build/mozilla/mozilla/content/build' > > rm -f libgkcontent.so > > c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion > > -Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual > > -Wsynth -pedantic -Wno-long-long -pthread -DNDEBUG -DTRIMMED -Wa,-xgot > > -shared -Wl,-h -Wl,libgkcontent.so -o libgkcontent.so nsContentDLF.o > > nsContentModule.o nsContentHTTPStartup.o -Wl,--whole-archive > > ../../dist/lib/libgkconevents_s.a ../../dist/lib/libgkconhtmlcon_s.a > > ../../dist/lib/libgkconhtmldoc_s.a ../../dist/lib/libgkconhtmlstyle_s.a > > ../../dist/lib/libgkconxmlcon_s.a ../../dist/lib/libgkconxmldoc_s.a > > ../../dist/lib/libgkconxsldoc_s.a ../../dist/lib/libgkconxulcon_s.a > > ../../dist/lib/libgkconxuldoc_s.a ../../dist/lib/libgkconxultmpl_s.a > > ../../dist/lib/libgkconxbl_s.a ../../dist/lib/libgkconbase_s.a > > ../../dist/lib/libgkconshared_s.a -Wl,--no-whole-archive -L../../dist/bin > > -lgkgfx -L../../dist/bin -lxpcom -L../../dist/bin > > -L/mnt/build/mozilla/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread > > -ldl -lc -L../../dist/bin -lmozjs > > -Wl,--version-script,../../build/unix/gnu-ld-scripts/components-version-script > > -ldl -lm -lc > > It is a known problem if > > 1. You don't compile shared libraries with -fpic/-fPIC. > 2. Even if you do, you may overflow GOT table. Well, even adding -fpic doesn't help a whole lot. What is a GOT table ? And do you see any fix for the problem ? Thanks, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Mon Oct 22 13:49:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MKn4Z16052 for linux-mips-outgoing; Mon, 22 Oct 2001 13:49:04 -0700 Received: from dea.linux-mips.net (a1as02-p219.stg.tli.de [195.252.185.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MKn0D16049 for ; Mon, 22 Oct 2001 13:49:00 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9MKmSH23032; Mon, 22 Oct 2001 22:48:28 +0200 Date: Mon, 22 Oct 2001 22:48:28 +0200 From: Ralf Baechle To: Machida Hiroyuki Cc: alan@lxorguk.ukuu.org.uk, linux-mips@oss.sgi.com Subject: Re: csum_ipv6_magic() Message-ID: <20011022224828.A20032@dea.linux-mips.net> References: <20011022151606V.machida@sm.sony.co.jp> <20011022195619A.machida@sm.sony.co.jp> <20011022203324G.machida@sm.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011022203324G.machida@sm.sony.co.jp>; from machida@sm.sony.co.jp on Mon, Oct 22, 2001 at 08:33:24PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 633 Lines: 18 On Mon, Oct 22, 2001 at 08:33:24PM +0900, Machida Hiroyuki wrote: > I found bugs in checksum.h. A sample fix is attached below. > > I perfer to use generic csum_ipv6_magic() in net/checksum.h > than this fix. Please someone show me improvements for this asm > version of csum_ipv6_magic(). The C version should produce code that performs identically on MIPS. As such we have no good reason to keep the assembler version. > * (csum_ipv6_magic): Have same paramter types as net/checksum.h. > Correct carry computation. Add a final carry. The len argument of that prototype should be __u32 because of IPv6 jumbograms. Ralf From owner-linux-mips@oss.sgi.com Mon Oct 22 15:12:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9MMCfP17270 for linux-mips-outgoing; Mon, 22 Oct 2001 15:12:41 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9MMCdD17267 for ; Mon, 22 Oct 2001 15:12:39 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id A406F125C8; Mon, 22 Oct 2001 15:12:38 -0700 (PDT) Date: Mon, 22 Oct 2001 15:12:38 -0700 From: "H . J . Lu" To: Klaus Naumann Cc: linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: The Linux binutils 2.11.92.0.7 is released. Message-ID: <20011022151238.A30586@lucon.org> References: <20011021091125.A1774@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spock@mgnet.de on Mon, Oct 22, 2001 at 10:43:00PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 308 Lines: 13 On Mon, Oct 22, 2001 at 10:43:00PM +0200, Klaus Naumann wrote: > > 2. Even if you do, you may overflow GOT table. > > Well, even adding -fpic doesn't help a whole lot. > What is a GOT table ? And do you see any fix for the problem ? See http://sources.redhat.com/ml/binutils/2001-09/msg00299.html H.J. From owner-linux-mips@oss.sgi.com Mon Oct 22 18:00:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N10oA20313 for linux-mips-outgoing; Mon, 22 Oct 2001 18:00:50 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N102D20292 for ; Mon, 22 Oct 2001 18:00:02 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id AD8A5125C8; Mon, 22 Oct 2001 17:59:56 -0700 (PDT) Date: Mon, 22 Oct 2001 17:59:56 -0700 From: "H . J . Lu" To: Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org Subject: The Linux binutils 2.11.92.0.10 is released. Message-ID: <20011022175956.A794@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 14007 Lines: 508 This is the beta release of binutils 2.11.92.0.10 for Linux, which is based on binutils 2001 1021 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.92.0.10 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.92.0.7: 1. Update from binutils 2001 1021. 2. Fix the ELF/PPC linker. 3. Fix the ELF/cris linker. 4. Fix ELF strip. Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.7. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.92.0.10.tar.gz. Source code. 2. binutils-2.11.92.0.7-2.11.92.0.10.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.92.0.10-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.92.0.10.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 10/22/2001 From owner-linux-mips@oss.sgi.com Mon Oct 22 22:07:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9N57Ve25455 for linux-mips-outgoing; Mon, 22 Oct 2001 22:07:31 -0700 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9N57PD25451; Mon, 22 Oct 2001 22:07:25 -0700 Received: from mail1.sony.co.jp (GateKeeper8.Sony.CO.JP [146.215.0.71]) by ns5.sony.co.jp (R8/Sony) with ESMTP id f9N57OL21478; Tue, 23 Oct 2001 14:07:24 +0900 (JST) Received: from mail1.sony.co.jp (localhost [127.0.0.1]) by mail1.sony.co.jp (R8) with ESMTP id f9N57NZ06680; Tue, 23 Oct 2001 14:07:23 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail1.sony.co.jp (R8) with ESMTP id f9N57Na06666; Tue, 23 Oct 2001 14:07:23 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id OAA29559; Tue, 23 Oct 2001 14:11:42 +0900 (JST) Received: from mach0.sm.sony.co.jp (mach0.sm.sony.co.jp [43.2.226.27]) by imail.sm.sony.co.jp (8.9.3+3.2W/3.7W) with ESMTP id OAA19052; Tue, 23 Oct 2001 14:07:22 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id f9N57Me14080; Tue, 23 Oct 2001 14:07:22 +0900 (JST) To: ralf@oss.sgi.com Cc: alan@lxorguk.ukuu.org.uk, linux-mips@oss.sgi.com Subject: Re: csum_ipv6_magic() In-Reply-To: <20011022224828.A20032@dea.linux-mips.net> References: <20011022195619A.machida@sm.sony.co.jp> <20011022203324G.machida@sm.sony.co.jp> <20011022224828.A20032@dea.linux-mips.net> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011023140722J.machida@sm.sony.co.jp> Date: Tue, 23 Oct 2001 14:07:22 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 494 Lines: 19 From: Ralf Baechle Subject: Re: csum_ipv6_magic() Date: Mon, 22 Oct 2001 22:48:28 +0200 > > * (csum_ipv6_magic): Have same paramter types as net/checksum.h. > > Correct carry computation. Add a final carry. > > The len argument of that prototype should be __u32 because of IPv6 > jumbograms. I suppose csum_ipv6_magic() in include/net/checksum.h should have __u32 len. Please update include/net/checksum.h to avoid confusion. Thanks. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Tue Oct 23 04:17:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NBHxA01645 for linux-mips-outgoing; Tue, 23 Oct 2001 04:17:59 -0700 Received: from dea.linux-mips.net (a1as16-p134.stg.tli.de [195.252.192.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NBHpD01642 for ; Tue, 23 Oct 2001 04:17:52 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9NBHLY12870; Tue, 23 Oct 2001 13:17:21 +0200 Date: Tue, 23 Oct 2001 13:17:21 +0200 From: Ralf Baechle To: Klaus Naumann Cc: "H . J . Lu" , linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: The Linux binutils 2.11.92.0.7 is released. Message-ID: <20011023131721.A12848@dea.linux-mips.net> References: <20011021091125.A1774@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spock@mgnet.de on Mon, Oct 22, 2001 at 10:43:00PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 389 Lines: 12 On Mon, Oct 22, 2001 at 10:43:00PM +0200, Klaus Naumann wrote: > > 1. You don't compile shared libraries with -fpic/-fPIC. > > 2. Even if you do, you may overflow GOT table. > > Well, even adding -fpic doesn't help a whole lot. > What is a GOT table ? And do you see any fix for the problem ? -fpic is default on Linux/MIPS and as such adding that option won't have any effect. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 23 04:19:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NBJDQ01718 for linux-mips-outgoing; Tue, 23 Oct 2001 04:19:13 -0700 Received: from dea.linux-mips.net (a1as16-p134.stg.tli.de [195.252.192.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NBJ9D01714 for ; Tue, 23 Oct 2001 04:19:09 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9NBIno12898; Tue, 23 Oct 2001 13:18:49 +0200 Date: Tue, 23 Oct 2001 13:18:49 +0200 From: Ralf Baechle To: Machida Hiroyuki Cc: alan@lxorguk.ukuu.org.uk, linux-mips@oss.sgi.com Subject: Re: csum_ipv6_magic() Message-ID: <20011023131849.B12848@dea.linux-mips.net> References: <20011022195619A.machida@sm.sony.co.jp> <20011022203324G.machida@sm.sony.co.jp> <20011022224828.A20032@dea.linux-mips.net> <20011023140722J.machida@sm.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011023140722J.machida@sm.sony.co.jp>; from machida@sm.sony.co.jp on Tue, Oct 23, 2001 at 02:07:22PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 444 Lines: 14 On Tue, Oct 23, 2001 at 02:07:22PM +0900, Machida Hiroyuki wrote: > > > * (csum_ipv6_magic): Have same paramter types as net/checksum.h. > > > Correct carry computation. Add a final carry. > > > > The len argument of that prototype should be __u32 because of IPv6 > > jumbograms. > > I suppose csum_ipv6_magic() in include/net/checksum.h should have __u32 > len. Please update include/net/checksum.h to avoid confusion. Will do. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 23 05:41:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NCfd303366 for linux-mips-outgoing; Tue, 23 Oct 2001 05:41:39 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NCfaD03360 for ; Tue, 23 Oct 2001 05:41:36 -0700 Received: from scotty.mgnet.de (pD9024776.dip.t-dialin.net [217.2.71.118]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id OAA04901 for ; Tue, 23 Oct 2001 14:41:33 +0200 (MET DST) Received: (qmail 5509 invoked from network); 23 Oct 2001 12:41:32 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 23 Oct 2001 12:41:32 -0000 Date: Tue, 23 Oct 2001 14:41:33 +0200 (CEST) From: Klaus Naumann To: Ralf Baechle cc: "H . J . Lu" , linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: The Linux binutils 2.11.92.0.7 is released. In-Reply-To: <20011023131721.A12848@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 798 Lines: 25 On Tue, 23 Oct 2001, Ralf Baechle wrote: > On Mon, Oct 22, 2001 at 10:43:00PM +0200, Klaus Naumann wrote: > > > > 1. You don't compile shared libraries with -fpic/-fPIC. > > > 2. Even if you do, you may overflow GOT table. > > > > Well, even adding -fpic doesn't help a whole lot. > > What is a GOT table ? And do you see any fix for the problem ? > > -fpic is default on Linux/MIPS and as such adding that option won't have any > effect. I also tried -fPIC . -Wa,-xgot is also the default. -G X doesn't change anything ... Other solutions ? Thanks, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Tue Oct 23 08:18:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NFIdk06875 for linux-mips-outgoing; Tue, 23 Oct 2001 08:18:39 -0700 Received: from dea.linux-mips.net (a1as15-p28.stg.tli.de [195.252.192.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NFIXD06871 for ; Tue, 23 Oct 2001 08:18:33 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9NFINw03674; Tue, 23 Oct 2001 17:18:23 +0200 Date: Tue, 23 Oct 2001 17:18:23 +0200 From: Ralf Baechle To: Klaus Naumann Cc: "H . J . Lu" , linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: The Linux binutils 2.11.92.0.7 is released. Message-ID: <20011023171823.B3644@dea.linux-mips.net> References: <20011023131721.A12848@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spock@mgnet.de on Tue, Oct 23, 2001 at 02:41:33PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 742 Lines: 20 On Tue, Oct 23, 2001 at 02:41:33PM +0200, Klaus Naumann wrote: > > > > 1. You don't compile shared libraries with -fpic/-fPIC. > > > > 2. Even if you do, you may overflow GOT table. > > > > > > Well, even adding -fpic doesn't help a whole lot. > > > What is a GOT table ? And do you see any fix for the problem ? > > > > -fpic is default on Linux/MIPS and as such adding that option won't have any > > effect. > > I also tried -fPIC . -Wa,-xgot is also the default. -G X doesn't > change anything ... -G is not supported with PIC and unless somebody really had his crack bucketwise or otherwise hates performance -Wa,-xgot isn't default. ATM -fPIC is the same as -fpic but this might be changes to imply a large GOT code model. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 23 13:48:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NKmCQ14635 for linux-mips-outgoing; Tue, 23 Oct 2001 13:48:12 -0700 Received: from dea.linux-mips.net (a1as16-p191.stg.tli.de [195.252.192.191]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NKm8D14631 for ; Tue, 23 Oct 2001 13:48:09 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9NKlIT06310; Tue, 23 Oct 2001 22:47:18 +0200 Date: Tue, 23 Oct 2001 22:47:18 +0200 From: Ralf Baechle To: Petko Manolov Cc: linux-mips@oss.sgi.com Subject: Malta probs Message-ID: <20011023224718.A6283@dea.linux-mips.net> References: <200110230102.f9N12kb20443@oss.sgi.com> <3BD5D236.8D0CE33C@lnxw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD5D236.8D0CE33C@lnxw.com>; from pmanolov@Lnxw.COM on Tue, Oct 23, 2001 at 01:25:26PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 348 Lines: 10 On Tue, Oct 23, 2001 at 01:25:26PM -0700, Petko Manolov wrote: > The theory looks good, but in reality latest kernel crashes > with machine check exception in local_flush_tlb_all on malta > board. I tried both egcs-1.1.2 and gcc-3.0.1 and both are > crashing at the same place. What CPU are you using; can you send me your .config file? Ralf From owner-linux-mips@oss.sgi.com Tue Oct 23 14:35:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NLZ8U16238 for linux-mips-outgoing; Tue, 23 Oct 2001 14:35:08 -0700 Received: from smtp.lynuxworks.com ([207.21.185.24]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NLYOD16230; Tue, 23 Oct 2001 14:34:24 -0700 Received: from lnxw.com (mastika.Lynx.com [172.17.127.85]) by smtp.lynuxworks.com (8.11.2/8.9.3) with ESMTP id f9NLYN506172; Tue, 23 Oct 2001 14:34:23 -0700 Message-ID: <3BD5E193.BB41A907@lnxw.com> Date: Tue, 23 Oct 2001 14:30:59 -0700 From: Petko Manolov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12 i686) X-Accept-Language: en, bg MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: Malta probs References: <200110230102.f9N12kb20443@oss.sgi.com> <3BD5D236.8D0CE33C@lnxw.com> <20011023224718.A6283@dea.linux-mips.net> Content-Type: multipart/mixed; boundary="------------FA0F1006D5711D5141DC93BA" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10407 Lines: 501 This is a multi-part message in MIME format. --------------FA0F1006D5711D5141DC93BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ralf Baechle wrote: > > What CPU are you using; can you send me your .config file? I am using R4Kc core on Malta board; here is the .config file. BTW the kernel silently hang after executing execve("/sbin/init") in init/main.c file. I suspect some of the tlb handling code which was recently changed is causing the crash. Not having any register dump also increase the entropy :-) Petko --------------FA0F1006D5711D5141DC93BA Content-Type: text/plain; charset=us-ascii; name="config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config" # # Automatically generated make config: don't edit # CONFIG_MIPS=y # CONFIG_SMP is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Machine selection # # CONFIG_ACER_PICA_61 is not set # CONFIG_ALGOR_P4032 is not set # CONFIG_BAGET_MIPS is not set # CONFIG_DECSTATION is not set # CONFIG_DDB5074 is not set # CONFIG_MIPS_EV96100 is not set # CONFIG_MIPS_EV64120 is not set # CONFIG_MIPS_ATLAS is not set CONFIG_MIPS_MALTA=y # CONFIG_NINO is not set # CONFIG_MIPS_MAGNUM_4000 is not set # CONFIG_MOMENCO_OCELOT is not set # CONFIG_DDB5476 is not set # CONFIG_DDB5477 is not set # CONFIG_NEC_OSPREY is not set # CONFIG_OLIVETTI_M700 is not set # CONFIG_SGI_IP22 is not set # CONFIG_SNI_RM200_PCI is not set # CONFIG_MIPS_ITE8172 is not set # CONFIG_MIPS_IVR is not set # CONFIG_MIPS_PB1000 is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_MCA is not set # CONFIG_SBUS is not set CONFIG_I8259=y CONFIG_PCI=y CONFIG_HAVE_STD_PC_SERIAL_PORT=y CONFIG_NEW_IRQ=y CONFIG_SWAP_IO_SPACE=y # CONFIG_ISA is not set # CONFIG_EISA is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set # CONFIG_KMOD is not set # # CPU selection # # CONFIG_CPU_R3000 is not set # CONFIG_CPU_R6000 is not set # CONFIG_CPU_VR41XX is not set # CONFIG_CPU_R4300 is not set # CONFIG_CPU_R4X00 is not set # CONFIG_CPU_R5000 is not set # CONFIG_CPU_R5432 is not set # CONFIG_CPU_RM7000 is not set # CONFIG_CPU_NEVADA is not set # CONFIG_CPU_R10000 is not set # CONFIG_CPU_SB1 is not set CONFIG_CPU_MIPS32=y # CONFIG_CPU_MIPS64 is not set # CONFIG_CPU_ADVANCED is not set CONFIG_CPU_HAS_LLSC=y # CONFIG_CPU_HAS_LLDSCD is not set # CONFIG_CPU_HAS_WB is not set # # General setup # CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_KCORE_ELF=y CONFIG_ELF_KERNEL=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_NET=y # CONFIG_PCI_NAMES is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT 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_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_INITRD=y # # 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 is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK 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 # # 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 # # 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 # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNLANCE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y CONFIG_PCNET32=y # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_LAN_SAA9730 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_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 # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Character devices # # CONFIG_VT is not set CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_UNIX98_PTYS 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 # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA 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_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_BFS_FS 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_CRAMFS is not set # CONFIG_TMPFS is not set # CONFIG_RAMFS is not set # CONFIG_ISO9660_FS is not set # CONFIG_JOLIET 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 # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_NFS_FS is not set # CONFIG_NFS_V3 is not set # CONFIG_ROOT_NFS is not set # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set # CONFIG_SUNRPC is not set # CONFIG_LOCKD is not set # 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 # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set # CONFIG_NLS is not set # # Sound # # CONFIG_SOUND is not set # # USB support # # CONFIG_USB 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 # # Kernel hacking # CONFIG_CROSSCOMPILE=y # CONFIG_REMOTE_DEBUG is not set # CONFIG_GDB_CONSOLE is not set # CONFIG_DEBUG is not set # CONFIG_MAGIC_SYSRQ is not set # CONFIG_MIPS_UNCACHED is not set --------------FA0F1006D5711D5141DC93BA-- From owner-linux-mips@oss.sgi.com Tue Oct 23 17:44:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O0i0Z20365 for linux-mips-outgoing; Tue, 23 Oct 2001 17:44:00 -0700 Received: from dea.linux-mips.net (a1as04-p137.stg.tli.de [195.252.186.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O0huD20358 for ; Tue, 23 Oct 2001 17:43:57 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9O0h9421492; Wed, 24 Oct 2001 02:43:09 +0200 Date: Wed, 24 Oct 2001 02:43:08 +0200 From: Ralf Baechle To: Petko Manolov Cc: linux-mips@oss.sgi.com Subject: Re: Malta probs Message-ID: <20011024024308.A21460@dea.linux-mips.net> References: <200110230102.f9N12kb20443@oss.sgi.com> <3BD5D236.8D0CE33C@lnxw.com> <20011023224718.A6283@dea.linux-mips.net> <3BD5E193.BB41A907@lnxw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD5E193.BB41A907@lnxw.com>; from pmanolov@Lnxw.COM on Tue, Oct 23, 2001 at 02:30:59PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 895 Lines: 20 On Tue, Oct 23, 2001 at 02:30:59PM -0700, Petko Manolov wrote: > > What CPU are you using; can you send me your .config file? > > I am using R4Kc core on Malta board; here is the .config file. > > BTW the kernel silently hang after executing execve("/sbin/init") > in init/main.c file. I suspect some of the tlb handling code > which was recently changed is causing the crash. Not having any > register dump also increase the entropy :-) It wasn't really changed, the whole lump of arch/mips/mm/ was just restructured in a way that allows adding of new CPU types and - even more important - get the code maintainable again. As it is right now we had a bunch of almost identical copies of the TLB flushing code, some even buggy. Now way I'd continue to deal with that. So now let's fix the breakage asap. As there were no functional changes any bugs are of rather trivial nature. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 23 23:43:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O6hgP28869 for linux-mips-outgoing; Tue, 23 Oct 2001 23:43:42 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O6hbD28864 for ; Tue, 23 Oct 2001 23:43:37 -0700 Received: from scotty.mgnet.de (pD90247CB.dip.t-dialin.net [217.2.71.203]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id IAA14898 for ; Wed, 24 Oct 2001 08:43:35 +0200 (MET DST) Received: (qmail 11718 invoked from network); 24 Oct 2001 06:43:34 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 24 Oct 2001 06:43:34 -0000 Date: Wed, 24 Oct 2001 08:43:35 +0200 (CEST) From: Klaus Naumann To: Ralf Baechle cc: "H . J . Lu" , linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: The Linux binutils 2.11.92.0.7 is released. In-Reply-To: <20011023171823.B3644@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1187 Lines: 37 On Tue, 23 Oct 2001, Ralf Baechle wrote: > On Tue, Oct 23, 2001 at 02:41:33PM +0200, Klaus Naumann wrote: > > > > > > 1. You don't compile shared libraries with -fpic/-fPIC. > > > > > 2. Even if you do, you may overflow GOT table. > > > > > > > > Well, even adding -fpic doesn't help a whole lot. > > > > What is a GOT table ? And do you see any fix for the problem ? > > > > > > -fpic is default on Linux/MIPS and as such adding that option won't have any > > > effect. > > > > I also tried -fPIC . -Wa,-xgot is also the default. -G X doesn't > > change anything ... > > -G is not supported with PIC and unless somebody really had his crack > bucketwise or otherwise hates performance -Wa,-xgot isn't default. ATM No, I meant it's default in the mozilla Makefile. Not really default in binutils. So to ask again, there is no other solution than -xgot ? And if that's the only solution, what are the issues ? Only bigger code ? Thx, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Wed Oct 24 02:27:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9O9RwL01850 for linux-mips-outgoing; Wed, 24 Oct 2001 02:27:58 -0700 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9O9RpD01838 for ; Wed, 24 Oct 2001 02:27:52 -0700 Received: from mail1.sony.co.jp (GateKeeper8.Sony.CO.JP [146.215.0.71]) by ns5.sony.co.jp (R8/Sony) with ESMTP id f9O9RoL01628 for ; Wed, 24 Oct 2001 18:27:50 +0900 (JST) Received: from mail1.sony.co.jp (localhost [127.0.0.1]) by mail1.sony.co.jp (R8) with ESMTP id f9O9RnZ18892 for ; Wed, 24 Oct 2001 18:27:49 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail1.sony.co.jp (R8) with ESMTP id f9O9Rma18838 for ; Wed, 24 Oct 2001 18:27:48 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id SAA02262 for ; Wed, 24 Oct 2001 18:32:05 +0900 (JST) Received: from mach0.sm.sony.co.jp (mach0.sm.sony.co.jp [43.2.226.27]) by imail.sm.sony.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA13712; Wed, 24 Oct 2001 18:27:44 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id f9O9Rie16670; Wed, 24 Oct 2001 18:27:44 +0900 (JST) To: linux-mips@oss.sgi.com Cc: takemura@sm.sony.co.jp, shin@sm.sony.co.jp Subject: bug in memscan() X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011024182744T.machida@sm.sony.co.jp> Date: Wed, 24 Oct 2001 18:27:44 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1518 Lines: 55 Hi, all. We found a bug of memscan() in include/asm-mips/string.h. Memscan() must compare a given 2nd parameter with memory by using unsinged char, as memchr() do. But, memscan() in include/asm-mips/string.h and lib/string.c don't so. Please refer memchr() in sysdeps/generic/memchr.c of glic and lib/string.c. I attached sample fixes. Index: include/asm-mips/string.h =================================================================== RCS file: /cvs/linux/include/asm-mips/string.h,v retrieving revision 1.18 diff -u -p -r1.18 string.h --- include/asm-mips/string.h 2001/10/06 19:29:25 1.18 +++ include/asm-mips/string.h 2001/10/24 09:17:05 @@ -142,11 +142,11 @@ extern __inline__ void *memscan(void *__ ".set\treorder\n\t" "1:\tbeq\t%0,%1,2f\n\t" "addiu\t%0,1\n\t" - "lb\t$1,-1(%0)\n\t" + "lbu\t$1,-1(%0)\n\t" "bne\t$1,%z4,1b\n" "2:\t.set\tpop" : "=r" (__addr), "=r" (__end) - : "0" (__addr), "1" (__end), "Jr" (__c)); + : "0" (__addr), "1" (__end), "Jr" ((unsigned char)__c)); return __addr; } Index: lib/string.c =================================================================== RCS file: /cvs/linux/lib/string.c,v retrieving revision 1.13 diff -u -p -r1.13 string.c --- lib/string.c 2001/06/13 17:28:17 1.13 +++ lib/string.c 2001/10/24 09:17:05 @@ -477,7 +477,7 @@ void * memscan(void * addr, int c, size_ unsigned char * e = p + size; while (p != e) { - if (*p == c) + if (*p == (unsigned char)c) return (void *) p; p++; } --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Wed Oct 24 04:19:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OBJB206306 for linux-mips-outgoing; Wed, 24 Oct 2001 04:19:11 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OBJ4D06296 for ; Wed, 24 Oct 2001 04:19:04 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id A973E80F; Wed, 24 Oct 2001 13:19:02 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 17D10472E; Wed, 24 Oct 2001 13:16:12 +0200 (CEST) Date: Wed, 24 Oct 2001 13:16:11 +0200 From: Florian Lohoff To: Gerald Champagne Cc: "linux-mips@oss.sgi.com" Subject: Re: Moving kernel_entry to LOADADDR Message-ID: <20011024131611.C19143@paradigm.rfc822.org> References: <3BCF7AD2.2000000@esstech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline In-Reply-To: <3BCF7AD2.2000000@esstech.com> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1937 Lines: 67 --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 18, 2001 at 07:58:58PM -0500, Gerald Champagne wrote: > I'm planning to work with a very minimal boot loader, and I'd like > to hard-code a jump to kernel_entry in my boot loader. I got tired > of having kernel_entry moving around, so I just moved it to the top > of head.S, just afte the ".fill 0x280". That places kernel_entry at > the same place every time. It's always at LOADADDR+0x280. Dont do this - Its easy to decode the elf stuff: Basically this is the code needed to relocate the elf chunks and return the entry point. I might have corrupted it a bit due to stripping unneeded bits but you will get the point. This code even clears bss chunk which the kernel will do itself again. Elf32_Ehdr *fhdr =3D fb; Elf32_Shdr *shdr;=09 int i; if (fhdr->e_machine !=3D EM_MIPS) { printf("No Mips ELF\n"); return(0);=09 } fhdr=3D(void *) KSEG1ADDR(fb); shdr=3Dfb + fhdr->e_shoff; for(i=3D0;ie_shnum;i++,shdr++) { if (shdr->sh_size <=3D 0)=20 continue; if (shdr->sh_type =3D=3D SHT_PROGBITS) { memcpy((void *) KSEG1ADDR(shdr->sh_addr), KSEG1ADDR(fb + shdr->sh_offset), shdr->sh_size); } else if (shdr->sh_type =3D=3D SHT_NOBITS) { memset((void *) KSEG1ADDR(shdr->sh_addr), 0x0, shdr->sh_size); } } return((void *) fhdr->e_entry); --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE71qL7Uaz2rXW+gJcRAt2VAJ4i2L8QBekR+xJwBViSE2uswKCVygCeLLgC 74R1ya5zrWR1Wf/2AUp0ApA= =zby9 -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- From owner-linux-mips@oss.sgi.com Wed Oct 24 06:02:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OD2mT09102 for linux-mips-outgoing; Wed, 24 Oct 2001 06:02:48 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OD2gD09097; Wed, 24 Oct 2001 06:02:42 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 24 Oct 2001 13:02:42 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 45B0DB46B; Wed, 24 Oct 2001 22:02:40 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id WAA18541; Wed, 24 Oct 2001 22:02:40 +0900 (JST) Date: Wed, 24 Oct 2001 22:07:29 +0900 (JST) Message-Id: <20011024.220729.39150004.nemoto@toshiba-tops.co.jp> To: ralf@oss.sgi.com Cc: pmanolov@Lnxw.COM, linux-mips@oss.sgi.com Subject: Re: Malta probs From: Atsushi Nemoto In-Reply-To: <20011024024308.A21460@dea.linux-mips.net> References: <20011023224718.A6283@dea.linux-mips.net> <3BD5E193.BB41A907@lnxw.com> <20011024024308.A21460@dea.linux-mips.net> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 889 Lines: 24 >>>>> On Wed, 24 Oct 2001 02:43:08 +0200, Ralf Baechle said: ralf> It wasn't really changed, the whole lump of arch/mips/mm/ was ralf> just restructured in a way that allows adding of new CPU types ralf> and - even more important - get the code maintainable again. As ralf> it is right now In current CVS, All handle_xxx exception handler seems to be complied with ".set mips3". Here is a patch. I think this patch solves the problem reported by Petko. diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/kernel/entry.S linux.new/arch/mips/kernel/entry.S --- linux-sgi-cvs/arch/mips/kernel/entry.S Mon Oct 22 10:29:56 2001 +++ linux.new/arch/mips/kernel/entry.S Wed Oct 24 21:55:16 2001 @@ -180,6 +180,7 @@ END(except_vec3_r4000) __FINIT + .set mips0 /* * Build a default exception handler for the exceptions that don't need --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Oct 24 06:35:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ODZkd09973 for linux-mips-outgoing; Wed, 24 Oct 2001 06:35:46 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ODXnD09916; Wed, 24 Oct 2001 06:33:49 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 24 Oct 2001 13:33:49 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id D2D4BB46B; Wed, 24 Oct 2001 22:33:47 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id WAA18573; Wed, 24 Oct 2001 22:33:47 +0900 (JST) Date: Wed, 24 Oct 2001 22:38:37 +0900 (JST) Message-Id: <20011024.223837.59648049.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: TX39/TX49 CPU support From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Oct_24_22:38:37_2001_909)--" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 38832 Lines: 1354 ----Next_Part(Wed_Oct_24_22:38:37_2001_909)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I cleaned up TOSHIBA TX39/TX49 CPU support code and create a patch against current CVS. Recent changes in CVS makes this patch smaller then ever. This patch supports TX4955, TX4927, TX3927. TX49XX CPUs have 4 way set associative cache with 32 byte cacheline. TX3927 have 2 way set associative cache with 16 byte cacheline. This patch also contains some fix for TX4300 (Vr4300). There are already some TX39 codes in arch/mips/mm/, it seems just for TX39H CPUs. This patch includes codes for TX39H2 CPUs. I newly defined CONFIG_CPU_TX39XX (and CONFIG_CPU_TX49XX) but did not removed TX39 codes from CONFIG_CPU_R3000 section. If nobody wants to link TX39 codes and R3000 codes into a single kernel image, TX39 codes in CONFIG_CPU_R3000 section can be removed. I think this patch does not break anything in existing code. Please apply to CVS. Thank you. --- Atsushi Nemoto ----Next_Part(Wed_Oct_24_22:38:37_2001_909)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tx.patch" diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/Makefile linux.new/arch/mips/Makefile --- linux-sgi-cvs/arch/mips/Makefile Mon Oct 22 10:29:55 2001 +++ linux.new/arch/mips/Makefile Wed Oct 24 21:26:39 2001 @@ -50,6 +50,9 @@ ifdef CONFIG_CPU_R3000 GCCFLAGS += -mcpu=r3000 -mips1 endif +ifdef CONFIG_CPU_TX39XX +GCCFLAGS += -mcpu=r3000 -mips1 +endif ifdef CONFIG_CPU_R6000 GCCFLAGS += -mcpu=r6000 -mips2 -Wa,--trap endif @@ -60,6 +63,9 @@ GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap endif ifdef CONFIG_CPU_R4X00 +GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap +endif +ifdef CONFIG_CPU_TX49XX GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap endif ifdef CONFIG_CPU_MIPS32 diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/config.in linux.new/arch/mips/config.in --- linux-sgi-cvs/arch/mips/config.in Mon Oct 22 10:29:55 2001 +++ linux.new/arch/mips/config.in Wed Oct 24 21:31:15 2001 @@ -246,10 +246,12 @@ choice 'CPU type' \ "R3000 CONFIG_CPU_R3000 \ + R39XX CONFIG_CPU_TX39XX \ R6000 CONFIG_CPU_R6000 \ R41xx CONFIG_CPU_VR41XX \ R4300 CONFIG_CPU_R4300 \ R4x00 CONFIG_CPU_R4X00 \ + R49XX CONFIG_CPU_TX49XX \ R5000 CONFIG_CPU_R5000 \ R5432 CONFIG_CPU_R5432 \ RM7000 CONFIG_CPU_RM7000 \ diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/kernel/gdb-low.S linux.new/arch/mips/kernel/gdb-low.S --- linux-sgi-cvs/arch/mips/kernel/gdb-low.S Mon Sep 10 02:43:01 2001 +++ linux.new/arch/mips/kernel/gdb-low.S Wed Oct 24 21:33:11 2001 @@ -304,7 +304,7 @@ lw v1,GDB_FR_REG3(sp) lw v0,GDB_FR_REG2(sp) lw $1,GDB_FR_REG1(sp) -#ifdef CONFIG_CPU_R3000 +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) lw k0, GDB_FR_EPC(sp) lw sp, GDB_FR_REG29(sp) /* Deallocate stack */ jr k0 diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/kernel/setup.c linux.new/arch/mips/kernel/setup.c --- linux-sgi-cvs/arch/mips/kernel/setup.c Mon Oct 22 10:29:56 2001 +++ linux.new/arch/mips/kernel/setup.c Wed Oct 24 21:42:22 2001 @@ -199,6 +199,12 @@ mips_cpu.options = R4K_OPTS; mips_cpu.tlbsize = 32; break; + case PRID_IMP_R4300: + mips_cpu.cputype = CPU_R4300; + mips_cpu.isa_level = MIPS_CPU_ISA_III; + mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR; + mips_cpu.tlbsize = 32; + break; case PRID_IMP_R4600: mips_cpu.cputype = CPU_R4600; mips_cpu.isa_level = MIPS_CPU_ISA_III; @@ -233,8 +239,22 @@ mips_cpu.tlbsize = 64; break; case PRID_REV_TX3927: - mips_cpu.cputype = CPU_TX3927; + case PRID_REV_TX3927B: + /* check core-mode */ + if ((*(volatile u32 *)0xfffee004 >> 16) == 0x3927) + mips_cpu.cputype = CPU_TX3927; + else + mips_cpu.cputype = CPU_TX39XX; mips_cpu.tlbsize = 64; + mips_cpu.icache.ways = 2; + mips_cpu.dcache.ways = 2; + break; + case PRID_REV_TX39H3TEG: + /* support core-mode only */ + mips_cpu.cputype = CPU_TX39XX; + mips_cpu.tlbsize = 32; + mips_cpu.icache.ways = 2; + mips_cpu.dcache.ways = 2; break; default: mips_cpu.cputype = CPU_UNKNOWN; @@ -248,6 +268,15 @@ MIPS_CPU_32FPR; mips_cpu.tlbsize = 48; break; + case PRID_IMP_TX49: + mips_cpu.cputype = CPU_TX49XX; + mips_cpu.isa_level = MIPS_CPU_ISA_III; + mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | + MIPS_CPU_32FPR; + mips_cpu.tlbsize = 48; + mips_cpu.icache.ways = 4; + mips_cpu.dcache.ways = 4; + break; case PRID_IMP_R5000: mips_cpu.cputype = CPU_R5000; mips_cpu.isa_level = MIPS_CPU_ISA_IV; @@ -835,6 +864,12 @@ { unsigned long cfg = read_32bit_cp0_register(CP0_CONF); write_32bit_cp0_register(CP0_CONF, cfg|CONF_HALT); +} + +void r39xx_wait(void) +{ + unsigned long cfg = read_32bit_cp0_register(CP0_CONF); + write_32bit_cp0_register(CP0_CONF, cfg|TX39_CONF_HALT); } void r4k_wait(void) diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/kernel/traps.c linux.new/arch/mips/kernel/traps.c --- linux-sgi-cvs/arch/mips/kernel/traps.c Wed Oct 24 13:27:29 2001 +++ linux.new/arch/mips/kernel/traps.c Wed Oct 24 21:50:07 2001 @@ -695,6 +695,14 @@ return; bad_cid: +#ifndef CONFIG_CPU_HAS_LLSC + switch (mips_cpu.cputype) { + case CPU_TX3927: + case CPU_TX39XX: + do_ri(regs); + return; + } +#endif compute_return_epc(regs); force_sig(SIGILL, current); } @@ -956,6 +964,7 @@ case CPU_TX3912: case CPU_TX3922: case CPU_TX3927: + case CPU_TX39XX: save_fp_context = _save_fp_context; restore_fp_context = _restore_fp_context; memcpy((void *)(KSEG0 + 0x80), &except_vec3_generic, 0x80); @@ -964,6 +973,10 @@ case CPU_UNKNOWN: default: panic("Unknown CPU type"); + } + if (!(mips_cpu.options & MIPS_CPU_FPU)) { + save_fp_context = fpu_emulator_save_context; + restore_fp_context = fpu_emulator_restore_context; } flush_icache_range(KSEG0, KSEG0 + 0x200); diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/mm/c-tx39.c linux.new/arch/mips/mm/c-tx39.c --- linux-sgi-cvs/arch/mips/mm/c-tx39.c Wed Oct 24 13:27:29 2001 +++ linux.new/arch/mips/mm/c-tx39.c Wed Oct 24 21:20:52 2001 @@ -28,31 +28,27 @@ static unsigned long icache_size, dcache_size; /* Size in bytes */ extern long scache_size; -#define icache_lsize 16 /* for all current cpu variants */ -#define dcache_lsize 4 /* for all current cpu variants */ +#define icache_lsize mips_cpu.icache.linesz +#define dcache_lsize mips_cpu.dcache.linesz #include -static void tx39_flush_page_to_ram(struct page * page) +extern int r3k_have_wired_reg; /* in r3k-tlb.c */ + +static void tx39h_flush_page_to_ram(struct page * page) { } -static void tx39_flush_icache_all(void) +/* TX39H-style cache flush routines. */ +static void tx39h_flush_icache_all(void) { unsigned long start = KSEG0; unsigned long end = (start + icache_size); - unsigned long dummy = 0; + unsigned long flags, config; - /* disable icache and stop streaming */ - __asm__ __volatile__( - ".set\tnoreorder\n\t" - "mfc0\t%0, $3\n\t" - "xori\t%0, 32\n\t" - "mtc0\t%0, $3\n\t" - "j\t1f\n\t" - "nop\n\t" - "1:\t.set\treorder\n\t" - : "+r"(dummy)); + /* disable icache (set ICE#) */ + __save_and_cli(flags); + config = read_32bit_cp0_register(CP0_CONF); /* invalidate icache */ while (start < end) { @@ -60,14 +56,194 @@ start += 0x200; } - /* enable icache */ - __asm__ __volatile__( - ".set\tnoreorder\n\t" - "mfc0\t%0, $3\n\t" - "xori\t%0, 32\n\t" - "mtc0\t%0, $3\n\t" - ".set\treorder\n\t" - : "+r"(dummy)); + write_32bit_cp0_register(CP0_CONF, config); + __restore_flags(flags); +} + +static void tx39h_dma_cache_wback_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + wbflush(); + + a = addr & ~(dcache_lsize - 1); + end = (addr + size) & ~(dcache_lsize - 1); + while (1) { + invalidate_dcache_line(a); /* Hit_Invalidate_D */ + if (a == end) break; + a += dcache_lsize; + } +} + + +/* TX39H2,TX39H3 */ +static inline void tx39_flush_cache_all(void) +{ + unsigned long flags, config; + + __save_and_cli(flags); + blast_dcache16_wayLSB(); + /* disable icache (set ICE#) */ + config = read_32bit_cp0_register(CP0_CONF); + write_32bit_cp0_register(CP0_CONF, config&~TX39_CONF_ICE); + blast_icache16_wayLSB(); + write_32bit_cp0_register(CP0_CONF, config); + __restore_flags(flags); +} + +static void tx39_flush_cache_mm(struct mm_struct *mm) +{ + if(mm->context != 0) { +#ifdef DEBUG_CACHE + printk("cmm[%d]", (int)mm->context); +#endif + tx39_flush_cache_all(); + } +} + +static void tx39_flush_cache_range(struct mm_struct *mm, + unsigned long start, + unsigned long end) +{ + if(mm->context != 0) { + unsigned long flags, config; + +#ifdef DEBUG_CACHE + printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); +#endif + __save_and_cli(flags); + blast_dcache16_wayLSB(); + /* disable icache (set ICE#) */ + config = read_32bit_cp0_register(CP0_CONF); + write_32bit_cp0_register(CP0_CONF, config&~TX39_CONF_ICE); + blast_icache16_wayLSB(); + write_32bit_cp0_register(CP0_CONF, config); + __restore_flags(flags); + } +} + +static void tx39_flush_cache_page(struct vm_area_struct *vma, + unsigned long page) +{ + struct mm_struct *mm = vma->vm_mm; + unsigned long flags; + pgd_t *pgdp; + pmd_t *pmdp; + pte_t *ptep; + + /* + * If ownes no valid ASID yet, cannot possibly have gotten + * this page into the cache. + */ + if(mm->context == 0) + return; + +#ifdef DEBUG_CACHE + printk("cpage[%d,%08lx]", (int)mm->context, page); +#endif + __save_and_cli(flags); + page &= PAGE_MASK; + pgdp = pgd_offset(mm, page); + pmdp = pmd_offset(pgdp, page); + ptep = pte_offset(pmdp, page); + + /* + * If the page isn't marked valid, the page cannot possibly be + * in the cache. + */ + if(!(pte_val(*ptep) & _PAGE_PRESENT)) + goto out; + + /* + * Doing flushes for another ASID than the current one is + * too difficult since stupid R4k caches do a TLB translation + * for every cache flush operation. So we do indexed flushes + * in that case, which doesn't overly flush the cache too much. + */ + if((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) { + blast_dcache16_page(page); + } else { + /* + * Do indexed flush, too much work to get the (possible) + * tlb refills to work correctly. + */ + page = (KSEG0 + (page & (dcache_size - 1))); + blast_dcache16_page_indexed_wayLSB(page); + } +out: + __restore_flags(flags); +} + +static void tx39_flush_page_to_ram(struct page * page) +{ + blast_dcache16_page((unsigned long)page_address(page)); +} + +static void tx39_flush_icache_range(unsigned long start, unsigned long end) +{ + flush_cache_all(); +} + +static void tx39_flush_icache_page(struct vm_area_struct *vma, struct page *page) +{ + if (!(vma->vm_flags & VM_EXEC)) + return; + + flush_cache_all(); +} + +static void tx39_dma_cache_wback_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= dcache_size) { + flush_cache_all(); + } else { + a = addr & ~(dcache_lsize - 1); + end = (addr + size) & ~(dcache_lsize - 1); + while (1) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + if (a == end) break; + a += dcache_lsize; + } + } +} + +static void tx39_dma_cache_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= dcache_size) { + flush_cache_all(); + } else { + a = addr & ~(dcache_lsize - 1); + end = (addr + size) & ~(dcache_lsize - 1); + while (1) { + invalidate_dcache_line(a); /* Hit_Invalidate_D */ + if (a == end) break; + a += dcache_lsize; + } + } +} + +static void tx39_dma_cache_wback(unsigned long addr, unsigned long size) +{ + panic("tx39_dma_cache called - should not happen.\n"); +} + +static void tx39_flush_cache_sigtramp(unsigned long addr) +{ + unsigned long config; + unsigned int flags; + + __save_and_cli(flags); + protected_writeback_dcache_line(addr & ~(dcache_lsize - 1)); + + /* disable icache (set ICE#) */ + config = read_32bit_cp0_register(CP0_CONF); + write_32bit_cp0_register(CP0_CONF, config&~TX39_CONF_ICE); + protected_flush_icache_line(addr & ~(icache_lsize - 1)); + write_32bit_cp0_register(CP0_CONF, config); + __restore_flags(flags); } static __init void tx39_probe_cache(void) @@ -78,6 +254,19 @@ icache_size = 1 << (10 + ((config >> 19) & 3)); dcache_size = 1 << (10 + ((config >> 16) & 3)); + + icache_lsize = 16; + switch (mips_cpu.cputype) { + case CPU_TX3912: + dcache_lsize = 4; + break; + case CPU_TX3922: + case CPU_TX3927: + case CPU_TX39XX: + default: + dcache_lsize = 16; + break; + } } void __init ld_mmu_tx39(void) @@ -95,18 +284,55 @@ tx39_probe_cache(); - _flush_cache_all = tx39_flush_icache_all; - ___flush_cache_all = tx39_flush_icache_all; - _flush_cache_mm = (void *) tx39_flush_icache_all; - _flush_cache_range = (void *) tx39_flush_icache_all; - _flush_cache_page = (void *) tx39_flush_icache_all; - _flush_cache_sigtramp = (void *) tx39_flush_icache_all; - _flush_page_to_ram = tx39_flush_page_to_ram; - _flush_icache_page = (void *) tx39_flush_icache_all; - _flush_icache_range = (void *) tx39_flush_icache_all; + switch (mips_cpu.cputype) { + case CPU_TX3912: + /* TX39/H core (writethru direct-map cache) */ + _flush_cache_all = tx39h_flush_icache_all; + ___flush_cache_all = tx39h_flush_icache_all; + _flush_cache_mm = (void *) tx39h_flush_icache_all; + _flush_cache_range = (void *) tx39h_flush_icache_all; + _flush_cache_page = (void *) tx39h_flush_icache_all; + _flush_cache_sigtramp = (void *) tx39h_flush_icache_all; + _flush_page_to_ram = tx39h_flush_page_to_ram; + _flush_icache_page = (void *) tx39h_flush_icache_all; + _flush_icache_range = (void *) tx39h_flush_icache_all; + + _dma_cache_wback_inv = tx39h_dma_cache_wback_inv; + break; + + case CPU_TX3922: + case CPU_TX3927: + default: + /* TX39/H2,H3 core (writeback 2way-set-associative cache) */ + r3k_have_wired_reg = 1; + set_wired (0); /* set 8 on reset... */ + /* board-dependent init code may set WBON */ + + _flush_cache_all = tx39_flush_cache_all; + ___flush_cache_all = tx39_flush_cache_all; + _flush_cache_mm = tx39_flush_cache_mm; + _flush_cache_range = tx39_flush_cache_range; + _flush_cache_page = tx39_flush_cache_page; + _flush_cache_sigtramp = tx39_flush_cache_sigtramp; + _flush_page_to_ram = tx39_flush_page_to_ram; + _flush_icache_page = tx39_flush_icache_page; + _flush_icache_range = tx39_flush_icache_range; + + _dma_cache_wback_inv = tx39_dma_cache_wback_inv; + _dma_cache_wback = tx39_dma_cache_wback; + _dma_cache_inv = tx39_dma_cache_inv; + + break; + } - /* This seems to be wrong for a R4k-style caches -- Ralf */ - // _dma_cache_wback_inv = r3k_dma_cache_wback_inv; + if (mips_cpu.icache.ways == 0) + mips_cpu.icache.ways = 1; + if (mips_cpu.dcache.ways == 0) + mips_cpu.dcache.ways = 1; + mips_cpu.icache.sets = + icache_size / mips_cpu.icache.ways / mips_cpu.icache.linesz; + mips_cpu.dcache.sets = + dcache_size / mips_cpu.dcache.ways / mips_cpu.dcache.linesz; printk("Primary instruction cache %dkb, linesize %d bytes\n", (int) (icache_size >> 10), (int) icache_lsize); diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/mm/c-tx49.c linux.new/arch/mips/mm/c-tx49.c --- linux-sgi-cvs/arch/mips/mm/c-tx49.c Thu Jan 1 09:00:00 1970 +++ linux.new/arch/mips/mm/c-tx49.c Wed Oct 24 21:20:52 2001 @@ -0,0 +1,440 @@ +/* + * 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. + * + * r49xx.c: TX49 processor variant specific MMU/Cache routines. + * + * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) + * Copyright (C) 1997, 1998, 1999, 2000 Ralf Baechle ralf@gnu.org + * + * Modified for R4300/TX49xx (Jun/2001) + * Copyright (C) 1999-2001 Toshiba Corporation + * + * To do: + * + * - this code is a overbloated pig + * - many of the bug workarounds are not efficient at all, but at + * least they are functional ... + */ +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* Primary cache parameters. */ +static int icache_size, dcache_size; /* Size in bytes */ +#define ic_lsize mips_cpu.icache.linesz +#define dc_lsize mips_cpu.dcache.linesz +static unsigned long scache_size; + +#include +#include + +#undef DEBUG_CACHE + +/* TX49 does can not flush the line contains the CACHE insn itself... */ +/* r4k_xxx routines are completely same as those in r4xx0.c */ + +/* + * If you think for one second that this stuff coming up is a lot + * of bulky code eating too many kernel cache lines. Think _again_. + * + * Consider: + * 1) Taken branches have a 3 cycle penalty on R4k + * 2) The branch itself is a real dead cycle on even R4600/R5000. + * 3) Only one of the following variants of each type is even used by + * the kernel based upon the cache parameters we detect at boot time. + * + * QED. + */ + +static inline void r49_flush_cache_all_d16i32(void) +{ + unsigned long flags, config; + + __save_and_cli(flags); + blast_dcache16_wayLSB(); + /* disable icache (set ICE#) */ + config = read_32bit_cp0_register(CP0_CONFIG); + write_32bit_cp0_register(CP0_CONFIG, config|TX49_CONF_IC); + blast_icache32_wayLSB(); + write_32bit_cp0_register(CP0_CONFIG, config); + __restore_flags(flags); +} + +static inline void r49_flush_cache_all_d32i32(void) +{ + unsigned long flags, config; + + __save_and_cli(flags); + blast_dcache32_wayLSB(); + /* disable icache (set ICE#) */ + config = read_32bit_cp0_register(CP0_CONFIG); + write_32bit_cp0_register(CP0_CONFIG, config|TX49_CONF_IC); + blast_icache32_wayLSB(); + write_32bit_cp0_register(CP0_CONFIG, config); + __restore_flags(flags); +} + +static void r49_flush_cache_range_d16i32(struct mm_struct *mm, + unsigned long start, + unsigned long end) +{ + if (mm->context != 0) { + unsigned long flags, config; + +#ifdef DEBUG_CACHE + printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); +#endif + __save_and_cli(flags); + blast_dcache16_wayLSB(); + /* disable icache (set ICE#) */ + config = read_32bit_cp0_register(CP0_CONFIG); + write_32bit_cp0_register(CP0_CONFIG, config|TX49_CONF_IC); + blast_icache32_wayLSB(); + write_32bit_cp0_register(CP0_CONFIG, config); + __restore_flags(flags); + } +} + +static void r49_flush_cache_range_d32i32(struct mm_struct *mm, + unsigned long start, + unsigned long end) +{ + if (mm->context != 0) { + unsigned long flags, config; + +#ifdef DEBUG_CACHE + printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); +#endif + __save_and_cli(flags); + blast_dcache32_wayLSB(); + /* disable icache (set ICE#) */ + config = read_32bit_cp0_register(CP0_CONFIG); + write_32bit_cp0_register(CP0_CONFIG, config|TX49_CONF_IC); + blast_icache32_wayLSB(); + write_32bit_cp0_register(CP0_CONFIG, config); + __restore_flags(flags); + } +} + +/* + * On architectures like the Sparc, we could get rid of lines in + * the cache created only by a certain context, but on the MIPS + * (and actually certain Sparc's) we cannot. + */ +static void r49_flush_cache_mm_d16i32(struct mm_struct *mm) +{ + if (mm->context != 0) { +#ifdef DEBUG_CACHE + printk("cmm[%d]", (int)mm->context); +#endif + r49_flush_cache_all_d16i32(); + } +} + +static void r49_flush_cache_mm_d32i32(struct mm_struct *mm) +{ + if (mm->context != 0) { +#ifdef DEBUG_CACHE + printk("cmm[%d]", (int)mm->context); +#endif + r49_flush_cache_all_d32i32(); + } +} + +static void r49_flush_cache_page_d16i32(struct vm_area_struct *vma, + unsigned long page) +{ + struct mm_struct *mm = vma->vm_mm; + unsigned long flags; + pgd_t *pgdp; + pmd_t *pmdp; + pte_t *ptep; + + /* + * If ownes no valid ASID yet, cannot possibly have gotten + * this page into the cache. + */ + if (mm->context == 0) + return; + +#ifdef DEBUG_CACHE + printk("cpage[%d,%08lx]", (int)mm->context, page); +#endif + __save_and_cli(flags); + page &= PAGE_MASK; + pgdp = pgd_offset(mm, page); + pmdp = pmd_offset(pgdp, page); + ptep = pte_offset(pmdp, page); + + /* + * If the page isn't marked valid, the page cannot possibly be + * in the cache. + */ + if (!(pte_val(*ptep) & _PAGE_PRESENT)) + goto out; + + /* + * Doing flushes for another ASID than the current one is + * too difficult since stupid R4k caches do a TLB translation + * for every cache flush operation. So we do indexed flushes + * in that case, which doesn't overly flush the cache too much. + */ + if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) { + blast_dcache16_page(page); + } else { + /* + * Do indexed flush, too much work to get the (possible) + * tlb refills to work correctly. + */ + page = (KSEG0 + (page & (dcache_size - 1))); + blast_dcache16_page_indexed_wayLSB(page); + } +out: + __restore_flags(flags); +} + +static void r49_flush_cache_page_d32i32(struct vm_area_struct *vma, + unsigned long page) +{ + struct mm_struct *mm = vma->vm_mm; + unsigned long flags; + pgd_t *pgdp; + pmd_t *pmdp; + pte_t *ptep; + + /* + * If ownes no valid ASID yet, cannot possibly have gotten + * this page into the cache. + */ + if (mm->context == 0) + return; + +#ifdef DEBUG_CACHE + printk("cpage[%d,%08lx]", (int)mm->context, page); +#endif + __save_and_cli(flags); + page &= PAGE_MASK; + pgdp = pgd_offset(mm, page); + pmdp = pmd_offset(pgdp, page); + ptep = pte_offset(pmdp, page); + + /* + * If the page isn't marked valid, the page cannot possibly be + * in the cache. + */ + if (!(pte_val(*ptep) & _PAGE_PRESENT)) + goto out; + + /* + * Doing flushes for another ASID than the current one is + * too difficult since stupid R4k caches do a TLB translation + * for every cache flush operation. So we do indexed flushes + * in that case, which doesn't overly flush the cache too much. + */ + if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) { + blast_dcache32_page(page); + } else { + /* + * Do indexed flush, too much work to get the (possible) + * tlb refills to work correctly. + */ + page = (KSEG0 + (page & (dcache_size - 1))); + blast_dcache32_page_indexed_wayLSB(page); + } +out: + __restore_flags(flags); +} + +/* If the addresses passed to these routines are valid, they are + * either: + * + * 1) In KSEG0, so we can do a direct flush of the page. + * 2) In KSEG2, and since every process can translate those + * addresses all the time in kernel mode we can do a direct + * flush. + * 3) In KSEG1, no flush necessary. + */ +static void r4k_flush_page_to_ram_d16(struct page *page) +{ + blast_dcache16_page((unsigned long)page_address(page)); +} + +static void r4k_flush_page_to_ram_d32(struct page *page) +{ + blast_dcache32_page((unsigned long)page_address(page)); +} + +static void +r4k_flush_icache_range(unsigned long start, unsigned long end) +{ + flush_cache_all(); +} + +/* + * Ok, this seriously sucks. We use them to flush a user page but don't + * know the virtual address, so we have to blast away the whole icache + * which is significantly more expensive than the real thing. + */ +static void +r4k_flush_icache_page(struct vm_area_struct *vma, struct page *page) +{ + if (!(vma->vm_flags & VM_EXEC)) + return; + + flush_cache_all(); +} + +/* + * Writeback and invalidate the primary cache dcache before DMA. + */ +static void +r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + unsigned int flags; + + if (size >= dcache_size) { + flush_cache_all(); + } else { + __save_and_cli(flags); + + a = addr & ~(dc_lsize - 1); + end = (addr + size) & ~(dc_lsize - 1); + while (1) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + if (a == end) break; + a += dc_lsize; + } + __restore_flags(flags); + } +} + +static void +r4k_dma_cache_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + unsigned int flags; + + if (size >= dcache_size) { + flush_cache_all(); + } else { + __save_and_cli(flags); + + a = addr & ~(dc_lsize - 1); + end = (addr + size) & ~(dc_lsize - 1); + while (1) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + if (a == end) break; + a += dc_lsize; + } + __restore_flags(flags); + } +} + +static void +r4k_dma_cache_wback(unsigned long addr, unsigned long size) +{ + panic("r4k_dma_cache called - should not happen.\n"); +} + +/* + * While we're protected against bad userland addresses we don't care + * very much about what happens in that case. Usually a segmentation + * fault will dump the process later on anyway ... + */ +static void r4k_flush_cache_sigtramp(unsigned long addr) +{ + protected_writeback_dcache_line(addr & ~(dc_lsize - 1)); + protected_flush_icache_line(addr & ~(ic_lsize - 1)); +} + +/* Detect and size the various r4k caches. */ +static void __init probe_icache(unsigned long config) +{ + icache_size = 1 << (12 + ((config >> 9) & 7)); + ic_lsize = 16 << ((config >> 5) & 1); + + printk("Primary instruction cache %dkb, linesize %d bytes.\n", + icache_size >> 10, ic_lsize); +} + +static void __init probe_dcache(unsigned long config) +{ + dcache_size = 1 << (12 + ((config >> 6) & 7)); + dc_lsize = 16 << ((config >> 4) & 1); + + printk("Primary data cache %dkb, linesize %d bytes.\n", + dcache_size >> 10, dc_lsize); +} + +int mips_configk0 = -1; /* board-specific setup routine can override this */ +void __init ld_mmu_tx49(void) +{ + unsigned long config = read_32bit_cp0_register(CP0_CONFIG); + + printk("CPU revision is: %08x\n", read_32bit_cp0_register(CP0_PRID)); + + if (mips_configk0 != -1) + change_cp0_config(CONF_CM_CMASK, mips_configk0); + else +#ifdef CONFIG_MIPS_UNCACHED + change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); +#else + change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_NONCOHERENT); +#endif + + probe_icache(config); + probe_dcache(config); + if (mips_cpu.icache.ways == 0) + mips_cpu.icache.ways = 1; + if (mips_cpu.dcache.ways == 0) + mips_cpu.dcache.ways = 1; + mips_cpu.icache.sets = + icache_size / mips_cpu.icache.ways / mips_cpu.icache.linesz; + mips_cpu.dcache.sets = + dcache_size / mips_cpu.dcache.ways / mips_cpu.dcache.linesz; + + switch(dc_lsize) { + case 16: + _clear_page = r4k_clear_page_d16; + _copy_page = r4k_copy_page_d16; + _flush_page_to_ram = r4k_flush_page_to_ram_d16; + _flush_cache_all = r49_flush_cache_all_d16i32; + _flush_cache_mm = r49_flush_cache_mm_d16i32; + _flush_cache_range = r49_flush_cache_range_d16i32; + _flush_cache_page = r49_flush_cache_page_d16i32; + break; + case 32: + _clear_page = r4k_clear_page_d32; + _copy_page = r4k_copy_page_d32; + _flush_page_to_ram = r4k_flush_page_to_ram_d32; + _flush_cache_all = r49_flush_cache_all_d32i32; + _flush_cache_mm = r49_flush_cache_mm_d32i32; + _flush_cache_range = r49_flush_cache_range_d32i32; + _flush_cache_page = r49_flush_cache_page_d32i32; + break; + } + ___flush_cache_all = _flush_cache_all; + + _flush_icache_page = r4k_flush_icache_page; + + _dma_cache_wback_inv = r4k_dma_cache_wback_inv; + _dma_cache_wback = r4k_dma_cache_wback; + _dma_cache_inv = r4k_dma_cache_inv; + + _flush_cache_sigtramp = r4k_flush_cache_sigtramp; + _flush_icache_range = r4k_flush_icache_range; /* Ouch */ + + __flush_cache_all(); +} diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/mm/loadmmu.c linux.new/arch/mips/mm/loadmmu.c --- linux-sgi-cvs/arch/mips/mm/loadmmu.c Wed Oct 24 13:27:29 2001 +++ linux.new/arch/mips/mm/loadmmu.c Wed Oct 24 21:20:52 2001 @@ -40,6 +40,8 @@ extern void ld_mmu_r23000(void); extern void ld_mmu_r4xx0(void); +extern void ld_mmu_tx39(void); +extern void ld_mmu_tx49(void); extern void ld_mmu_r5432(void); extern void ld_mmu_r6000(void); extern void ld_mmu_rm7k(void); @@ -67,6 +69,10 @@ ld_mmu_r5432(); r4k_tlb_init(); #endif +#if defined(CONFIG_CPU_TX49XX) + ld_mmu_tx49(); + r4k_tlb_init(); +#endif #if defined(CONFIG_CPU_MIPS32) || defined(CONFIG_CPU_MIPS64) ld_mmu_mips32(); @@ -80,10 +86,20 @@ case CPU_R3081E: ld_mmu_r23000(); r3k_tlb_init(); - + break; + case CPU_TX3912: + case CPU_TX3922: + case CPU_TX3927: + case CPU_TX39XX: + ld_mmu_tx39(); + r3k_tlb_init(); + break; +#endif +#ifdef CONFIG_CPU_TX39XX case CPU_TX3912: case CPU_TX3922: case CPU_TX3927: + case CPU_TX39XX: ld_mmu_tx39(); r3k_tlb_init(); break; diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/mm/tlb-r3k.c linux.new/arch/mips/mm/tlb-r3k.c --- linux-sgi-cvs/arch/mips/mm/tlb-r3k.c Wed Oct 24 13:27:29 2001 +++ linux.new/arch/mips/mm/tlb-r3k.c Wed Oct 24 21:20:53 2001 @@ -27,6 +27,10 @@ #undef DEBUG_TLB +#ifdef CONFIG_CPU_TX39XX +int r3k_have_wired_reg = 0; /* should be in mips_cpu? */ +#endif + /* TLB operations. */ void local_flush_tlb_all(void) { @@ -41,7 +45,12 @@ save_and_cli(flags); old_ctx = (get_entryhi() & 0xfc0); write_32bit_cp0_register(CP0_ENTRYLO0, 0); - for (entry = 8; entry < mips_cpu.tlbsize; entry++) { +#ifdef CONFIG_CPU_TX39XX + entry = r3k_have_wired_reg ? get_wired() : 8; +#else + entry = 8; +#endif + for (; entry < mips_cpu.tlbsize; entry++) { write_32bit_cp0_register(CP0_INDEX, entry << 8); write_32bit_cp0_register(CP0_ENTRYHI, ((entry | 0x80000) << 12)); __asm__ __volatile__("tlbwi"); @@ -193,6 +202,40 @@ unsigned long old_ctx; static unsigned long wired = 0; +#ifdef CONFIG_CPU_TX39XX + if (r3k_have_wired_reg) { + unsigned long old_pagemask; + unsigned long w; + +#ifdef DEBUG_TLB + printk("[tlbwired]"); + printk("ently lo0 %8x, hi %8x\n, pagemask %8x\n", + entrylo0, entryhi, pagemask); +#endif + save_and_cli(flags); + /* Save old context and create impossible VPN2 value */ + old_ctx = (get_entryhi() & 0xff); + old_pagemask = get_pagemask(); + w = get_wired(); + set_wired (w + 1); + if (get_wired() != w + 1) { + printk("[tlbwired] No WIRED reg?\n"); + return; + } + set_index (w << 8); + set_pagemask (pagemask); + set_entryhi(entryhi); + set_entrylo0(entrylo0); + tlb_write_indexed(); + + set_entryhi(old_ctx); + set_pagemask (old_pagemask); + local_flush_tlb_all(); + restore_flags(flags); + return; + } +#endif + if (wired < 8) { __save_and_cli(flags); old_ctx = get_entryhi() & 0xfc0; diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/bootinfo.h linux.new/include/asm-mips/bootinfo.h --- linux-sgi-cvs/include/asm-mips/bootinfo.h Mon Oct 22 10:30:09 2001 +++ linux.new/include/asm-mips/bootinfo.h Wed Oct 24 21:47:40 2001 @@ -249,7 +249,9 @@ #define CPU_4KSC 39 #define CPU_VR41XX 40 #define CPU_R5500 41 -#define CPU_LAST 41 +#define CPU_TX49XX 42 +#define CPU_TX39XX 43 +#define CPU_LAST 43 #define CPU_NAMES { "unknown", "R2000", "R3000", "R3000A", "R3041", "R3051", \ @@ -258,7 +260,7 @@ "R6000A", "R8000", "R10000", "R4300", "R4650", "R4700", "R5000", \ "R5000A", "R4640", "Nevada", "RM7000", "R5432", "MIPS 4Kc", \ "MIPS 5Kc", "R4310", "SiByte SB1", "TX3912", "TX3922", "TX3927", \ - "Au1000", "MIPS 4KEc", "MIPS 4KSc", "NEC Vr41xx", "R5500" } + "Au1000", "MIPS 4KEc", "MIPS 4KSc", "NEC Vr41xx", "R5500", "TX49xx", "TX39xx" } #define COMMAND_LINE_SIZE 256 diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/bugs.h linux.new/include/asm-mips/bugs.h --- linux-sgi-cvs/include/asm-mips/bugs.h Tue Jul 3 05:56:40 2001 +++ linux.new/include/asm-mips/bugs.h Wed Oct 24 21:47:49 2001 @@ -22,8 +22,13 @@ cpu_wait = r3081_wait; printk(" available.\n"); break; + case CPU_TX3927: + case CPU_TX39XX: + cpu_wait = r39xx_wait; + printk(" available.\n"); + break; case CPU_R4200: - case CPU_R4300: +/* case CPU_R4300: */ case CPU_R4600: case CPU_R4640: case CPU_R4650: @@ -31,6 +36,7 @@ case CPU_R5000: case CPU_NEVADA: case CPU_RM7000: + case CPU_TX49XX: cpu_wait = r4k_wait; printk(" available.\n"); break; diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/cache.h linux.new/include/asm-mips/cache.h --- linux-sgi-cvs/include/asm-mips/cache.h Tue Jul 3 05:56:40 2001 +++ linux.new/include/asm-mips/cache.h Wed Oct 24 21:01:29 2001 @@ -28,7 +28,7 @@ */ #define MIPS_CACHE_NOT_PRESENT 0x00000001 -#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_R6000) +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_R6000) || defined(CONFIG_CPU_TX39XX) #define L1_CACHE_BYTES 16 #else #define L1_CACHE_BYTES 32 /* A guess */ diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/isadep.h linux.new/include/asm-mips/isadep.h --- linux-sgi-cvs/include/asm-mips/isadep.h Mon Sep 10 02:43:01 2001 +++ linux.new/include/asm-mips/isadep.h Wed Oct 24 21:01:36 2001 @@ -10,7 +10,7 @@ #ifndef __ASM_ISADEP_H #define __ASM_ISADEP_H -#if defined(CONFIG_CPU_R3000) +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) /* * R2000 or R3000 */ diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/mipsregs.h linux.new/include/asm-mips/mipsregs.h --- linux-sgi-cvs/include/asm-mips/mipsregs.h Mon Sep 10 02:43:01 2001 +++ linux.new/include/asm-mips/mipsregs.h Wed Oct 24 21:48:28 2001 @@ -79,6 +79,12 @@ #define CP0_S1_DERRADDR0 $26 #define CP0_S1_DERRADDR1 $27 #define CP0_S1_INTCONTROL $20 + +/* + * TX39 Series + */ +#define CP0_TX39_CACHE $7 + /* * Coprocessor 1 (FPU) register names */ @@ -478,6 +484,14 @@ #define CONF_SC (1 << 17) #define CONF_AC (1 << 23) #define CONF_HALT (1 << 25) + +/* + * Bits in the TX49 coprozessor 0 config register. + */ +#define TX49_CONF_DC (1 << 16) +#define TX49_CONF_IC (1 << 17) /* conflict with CONF_SC */ +#define TX49_CONF_HALT (1 << 18) +#define TX49_CONF_CWFON (1 << 27) /* * R10000 performance counter definitions. diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/mmu_context.h linux.new/include/asm-mips/mmu_context.h --- linux-sgi-cvs/include/asm-mips/mmu_context.h Mon Oct 22 10:30:10 2001 +++ linux.new/include/asm-mips/mmu_context.h Wed Oct 24 21:01:48 2001 @@ -37,7 +37,7 @@ #endif #define ASID_CACHE(cpu) cpu_data[cpu].asid_cache -#if defined(CONFIG_CPU_R3000) +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) #define ASID_INC 0x40 #define ASID_MASK 0xfc0 diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/pgtable.h linux.new/include/asm-mips/pgtable.h --- linux-sgi-cvs/include/asm-mips/pgtable.h Mon Sep 10 02:43:01 2001 +++ linux.new/include/asm-mips/pgtable.h Wed Oct 24 21:48:39 2001 @@ -128,7 +128,7 @@ #define _PAGE_ACCESSED (1<<3) /* implemented in software */ #define _PAGE_MODIFIED (1<<4) /* implemented in software */ -#if defined(CONFIG_CPU_R3000) +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) #define _PAGE_GLOBAL (1<<8) #define _PAGE_VALID (1<<9) diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/r4kcache.h linux.new/include/asm-mips/r4kcache.h --- linux-sgi-cvs/include/asm-mips/r4kcache.h Mon Oct 22 10:30:10 2001 +++ linux.new/include/asm-mips/r4kcache.h Wed Oct 24 21:48:49 2001 @@ -187,6 +187,20 @@ } } +extern inline void blast_dcache16_wayLSB(void) +{ + unsigned long start = KSEG0; + unsigned long end = (start + mips_cpu.dcache.sets * mips_cpu.dcache.linesz); + int way; + + while(start < end) { + /* LSB of VA select the way */ + for (way = 0; way < mips_cpu.dcache.ways; way++) + cache16_unroll32(start|way,Index_Writeback_Inv_D); + start += 0x200; + } +} + extern inline void blast_dcache16_page(unsigned long page) { unsigned long start = page; @@ -209,6 +223,20 @@ } } +extern inline void blast_dcache16_page_indexed_wayLSB(unsigned long page) +{ + unsigned long start = page; + unsigned long end = (start + PAGE_SIZE); + int way; + + while(start < end) { + /* LSB of VA select the way */ + for (way = 0; way < mips_cpu.dcache.ways; way++) + cache16_unroll32(start|way,Index_Writeback_Inv_D); + start += 0x200; + } +} + extern inline void blast_icache16(void) { unsigned long start = KSEG0; @@ -220,6 +248,20 @@ } } +extern inline void blast_icache16_wayLSB(void) +{ + unsigned long start = KSEG0; + unsigned long end = (start + mips_cpu.icache.sets * mips_cpu.icache.linesz); + int way; + + while(start < end) { + /* LSB of VA select the way */ + for (way = 0; way < mips_cpu.icache.ways; way++) + cache16_unroll32(start|way,Index_Invalidate_I); + start += 0x200; + } +} + extern inline void blast_icache16_page(unsigned long page) { unsigned long start = page; @@ -312,6 +354,20 @@ } } +extern inline void blast_dcache32_wayLSB(void) +{ + unsigned long start = KSEG0; + unsigned long end = (start + mips_cpu.dcache.sets * mips_cpu.dcache.linesz); + int way; + + while(start < end) { + /* LSB of VA select the way */ + for (way = 0; way < mips_cpu.dcache.ways; way++) + cache32_unroll32(start|way,Index_Writeback_Inv_D); + start += 0x400; + } +} + /* * Call this function only with interrupts disabled or R4600 V2.0 may blow * up on you. @@ -352,6 +408,20 @@ } } +extern inline void blast_dcache32_page_indexed_wayLSB(unsigned long page) +{ + unsigned long start = page; + unsigned long end = (start + PAGE_SIZE); + int way; + + while(start < end) { + /* LSB of VA select the way */ + for (way = 0; way < mips_cpu.dcache.ways; way++) + cache32_unroll32(start|way,Index_Writeback_Inv_D); + start += 0x400; + } +} + extern inline void blast_icache32(void) { unsigned long start = KSEG0; @@ -359,6 +429,20 @@ while(start < end) { cache32_unroll32(start,Index_Invalidate_I); + start += 0x400; + } +} + +extern inline void blast_icache32_wayLSB(void) +{ + unsigned long start = KSEG0; + unsigned long end = (start + mips_cpu.icache.sets * mips_cpu.icache.linesz); + int way; + + while(start < end) { + /* LSB of VA select the way */ + for (way = 0; way < mips_cpu.icache.ways; way++) + cache32_unroll32(start|way,Index_Invalidate_I); start += 0x400; } } diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/stackframe.h linux.new/include/asm-mips/stackframe.h --- linux-sgi-cvs/include/asm-mips/stackframe.h Tue Jul 3 05:56:40 2001 +++ linux.new/include/asm-mips/stackframe.h Wed Oct 24 21:02:06 2001 @@ -163,7 +163,7 @@ lw $23, PT_R23(sp); \ lw $30, PT_R30(sp) -#if defined(CONFIG_CPU_R3000) +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) #define RESTORE_SOME \ .set push; \ ----Next_Part(Wed_Oct_24_22:38:37_2001_909)---- From owner-linux-mips@oss.sgi.com Wed Oct 24 08:04:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OF40X12542 for linux-mips-outgoing; Wed, 24 Oct 2001 08:04:00 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OF3vD12538 for ; Wed, 24 Oct 2001 08:03:57 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 80CBE125C9; Wed, 24 Oct 2001 08:03:56 -0700 (PDT) Date: Wed, 24 Oct 2001 08:03:56 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: I am looking for a mips machine Message-ID: <20011024080356.A2440@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 453 Lines: 29 Hi, I am looking for a mips machine to continue working on my mips port of RedHat. My requirements are 1. It has the stable, up to date kernel support. That means I can do # ./configure # make bootstrap # make check for gcc 3.1 without a kernel oops. 2. It has decent CPU. I hate to wait a day for # make bootstrap 3. Inexpensive. 4. Support serial console. 5. Little endian is preferred. Does anyone have any recommendations? Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Oct 24 09:47:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OGlAJ16934 for linux-mips-outgoing; Wed, 24 Oct 2001 09:47:10 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OGkuD16922; Wed, 24 Oct 2001 09:46:56 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA12462; Wed, 24 Oct 2001 09:46:49 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA14356; Wed, 24 Oct 2001 09:46:46 -0700 (PDT) Message-ID: <004501c15cab$88055b60$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Petko Manolov" Cc: References: <200110230102.f9N12kb20443@oss.sgi.com> <3BD5D236.8D0CE33C@lnxw.com> <20011023224718.A6283@dea.linux-mips.net> Subject: Re: Malta probs Date: Wed, 24 Oct 2001 18:47:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1219 Lines: 39 A clue - a machine check exception results when there are two identical values in the TLB, which is unhealthy for associative RAM arrays (never mind that synthesized MIPS 4K and 5K cores may or may not actually have associative RAM for the TLB). In the 4K cores, this condition results even if the two identical values are non-Valid, which was not true in the R4000 and R5000 CPUs, and which necessitated a tweak to the TLB flush and invaldate routines to ensure that each entry is written with a unique invalid value (a function of the index). Please double-check that the TLB flush code that you are using does this. Kevin K. ----- Original Message ----- From: "Ralf Baechle" To: "Petko Manolov" Cc: Sent: Tuesday, October 23, 2001 10:47 PM Subject: Malta probs > On Tue, Oct 23, 2001 at 01:25:26PM -0700, Petko Manolov wrote: > > > The theory looks good, but in reality latest kernel crashes > > with machine check exception in local_flush_tlb_all on malta > > board. I tried both egcs-1.1.2 and gcc-3.0.1 and both are > > crashing at the same place. > > What CPU are you using; can you send me your .config file? > > Ralf > From owner-linux-mips@oss.sgi.com Wed Oct 24 09:57:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OGv2J17303 for linux-mips-outgoing; Wed, 24 Oct 2001 09:57:02 -0700 Received: from dea.linux-mips.net (a1as11-p81.stg.tli.de [195.252.190.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OGuuD17298 for ; Wed, 24 Oct 2001 09:56:56 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9OGuiY03049; Wed, 24 Oct 2001 18:56:44 +0200 Date: Wed, 24 Oct 2001 18:56:44 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Petko Manolov , linux-mips@oss.sgi.com Subject: Re: Malta probs Message-ID: <20011024185644.A3025@dea.linux-mips.net> References: <200110230102.f9N12kb20443@oss.sgi.com> <3BD5D236.8D0CE33C@lnxw.com> <20011023224718.A6283@dea.linux-mips.net> <004501c15cab$88055b60$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004501c15cab$88055b60$0deca8c0@Ulysses>; from kevink@mips.com on Wed, Oct 24, 2001 at 06:47:10PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 770 Lines: 22 On Wed, Oct 24, 2001 at 06:47:10PM +0200, Kevin D. Kissell wrote: > A clue - a machine check exception results > when there are two identical values in the > TLB, which is unhealthy for associative RAM > arrays (never mind that synthesized MIPS > 4K and 5K cores may or may not actually > have associative RAM for the TLB). In the > 4K cores, this condition results even if the > two identical values are non-Valid, which was > not true in the R4000 and R5000 CPUs, and > which necessitated a tweak to the TLB flush > and invaldate routines to ensure that each entry > is written with a unique invalid value (a function > of the index). > > Please double-check that the TLB flush > code that you are using does this. I fixed this problem already last night. Ralf From owner-linux-mips@oss.sgi.com Wed Oct 24 11:19:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OIJaY23176 for linux-mips-outgoing; Wed, 24 Oct 2001 11:19:36 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OIJXD23172 for ; Wed, 24 Oct 2001 11:19:33 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9OIJSE0014546; Wed, 24 Oct 2001 11:19:28 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9OIJRHI014540; Wed, 24 Oct 2001 11:19:27 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 24 Oct 2001 11:19:27 -0700 (PDT) From: James Simmons To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: I am looking for a mips machine In-Reply-To: <20011024080356.A2440@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 617 Lines: 27 > I am looking for a mips machine to continue working on my mips port > of RedHat. My requirements are > > 1. It has the stable, up to date kernel support. That means I can do > > # ./configure > # make bootstrap > # make check > > for gcc 3.1 without a kernel oops. > > 2. It has decent CPU. I hate to wait a day for > > # make bootstrap > > 3. Inexpensive. > > 4. Support serial console. > > 5. Little endian is preferred. > > Does anyone have any recommendations? I use a Cobalt Qube for alot of my developement. It works fine. I know it is not in Ralph's tree yet but I plan to send him my work soon. From owner-linux-mips@oss.sgi.com Wed Oct 24 12:16:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OJGqg32283 for linux-mips-outgoing; Wed, 24 Oct 2001 12:16:52 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OJGlD32278 for ; Wed, 24 Oct 2001 12:16:47 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id CFE4A125C9; Wed, 24 Oct 2001 12:16:46 -0700 (PDT) Date: Wed, 24 Oct 2001 12:16:46 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: RedHat 7.1/mips update Message-ID: <20011024121646.A6520@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1124 Lines: 38 I updated my RedHat 7.1/mips port. There are quite a few changes. Check it out. H.J. ----- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. You may need glibc 2.2.3-11 or above to use those rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. 4. baseline.tar.bz2 contains the cross build tree. 5. Since everything is cross compiled from x86, which is little endian, many data files for mips, which is big endian, are either missing or wrong. To get those data files for mips, you have to rebuild/install the folowing rpms: cracklib glibc natively on Linux/mips. Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Oct 24 12:19:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OJJl432449 for linux-mips-outgoing; Wed, 24 Oct 2001 12:19:47 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OJJiD32446 for ; Wed, 24 Oct 2001 12:19:45 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 77344125C9; Wed, 24 Oct 2001 12:19:44 -0700 (PDT) Date: Wed, 24 Oct 2001 12:19:44 -0700 From: "H . J . Lu" To: James Simmons Cc: linux-mips@oss.sgi.com Subject: Re: I am looking for a mips machine Message-ID: <20011024121944.B6520@lucon.org> References: <20011024080356.A2440@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsimmons@transvirtual.com on Wed, Oct 24, 2001 at 11:19:27AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 354 Lines: 10 On Wed, Oct 24, 2001 at 11:19:27AM -0700, James Simmons wrote: > > I use a Cobalt Qube for alot of my developement. It works fine. I know it > is not in Ralph's tree yet but I plan to send him my work soon. I think Cobalt Qube is slow and is hard to expand the memory. I need at least 128MB RAM. Also the current mips kernel doesn't support it. H.J. From owner-linux-mips@oss.sgi.com Wed Oct 24 12:49:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OJnf701277 for linux-mips-outgoing; Wed, 24 Oct 2001 12:49:41 -0700 Received: from smtp.lynuxworks.com ([207.21.185.24]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OJnYD01274; Wed, 24 Oct 2001 12:49:34 -0700 Received: from lnxw.com (mastika.Lynx.com [172.17.127.85]) by smtp.lynuxworks.com (8.11.2/8.9.3) with ESMTP id f9OJn8518872; Wed, 24 Oct 2001 12:49:08 -0700 Message-ID: <3BD71A69.99A23D18@lnxw.com> Date: Wed, 24 Oct 2001 12:45:45 -0700 From: Petko Manolov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12 i686) X-Accept-Language: en, bg MIME-Version: 1.0 To: Atsushi Nemoto CC: ralf@oss.sgi.com, linux-mips@oss.sgi.com, kevink@mips.com Subject: Re: Malta probs References: <20011023224718.A6283@dea.linux-mips.net> <3BD5E193.BB41A907@lnxw.com> <20011024024308.A21460@dea.linux-mips.net> <20011024.220729.39150004.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 851 Lines: 28 Atsushi Nemoto wrote: > > In current CVS, All handle_xxx exception handler seems to be complied > with ".set mips3". Here is a patch. I think this patch solves the > problem reported by Petko. Yes, Atsushi is right. Adding .set mips0 solved the problem, but after applying Ralf's patch to tlb-r4k.c Ralf, i think the patch worth applying to the CVS tree. Petko > diff -urP -x CVS -x .cvsignore linux-sgi-cvs/arch/mips/kernel/entry.S linux.new/arch/mips/kernel/entry.S > --- linux-sgi-cvs/arch/mips/kernel/entry.S Mon Oct 22 10:29:56 2001 > +++ linux.new/arch/mips/kernel/entry.S Wed Oct 24 21:55:16 2001 > @@ -180,6 +180,7 @@ > END(except_vec3_r4000) > > __FINIT > + .set mips0 > > /* > * Build a default exception handler for the exceptions that don't need > --- > Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Oct 24 13:16:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKGFw02292 for linux-mips-outgoing; Wed, 24 Oct 2001 13:16:15 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKGED02289 for ; Wed, 24 Oct 2001 13:16:14 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9OKG8E0021285; Wed, 24 Oct 2001 13:16:08 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9OKG82h021281; Wed, 24 Oct 2001 13:16:08 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 24 Oct 2001 13:16:07 -0700 (PDT) From: James Simmons To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: I am looking for a mips machine In-Reply-To: <20011024121944.B6520@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 449 Lines: 13 > > I use a Cobalt Qube for alot of my developement. It works fine. I know it > > is not in Ralph's tree yet but I plan to send him my work soon. > > I think Cobalt Qube is slow and is hard to expand the memory. Slow that it is. As for memory it has two banks for 72 pin memory. I want to add memory to the Qube I have. > Also the current mips kernel doesn't support it. In the CVS tree I have it works and this tree is against Ralph's tree. From owner-linux-mips@oss.sgi.com Wed Oct 24 13:24:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKOc602627 for linux-mips-outgoing; Wed, 24 Oct 2001 13:24:38 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKOaD02624 for ; Wed, 24 Oct 2001 13:24:36 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 2A5CE125C9; Wed, 24 Oct 2001 13:24:35 -0700 (PDT) Date: Wed, 24 Oct 2001 13:24:35 -0700 From: "H . J . Lu" To: James Simmons Cc: linux-mips@oss.sgi.com Subject: Re: I am looking for a mips machine Message-ID: <20011024132435.A7669@lucon.org> References: <20011024121944.B6520@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsimmons@transvirtual.com on Wed, Oct 24, 2001 at 01:16:07PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 518 Lines: 15 On Wed, Oct 24, 2001 at 01:16:07PM -0700, James Simmons wrote: > > > > I use a Cobalt Qube for alot of my developement. It works fine. I know it > > > is not in Ralph's tree yet but I plan to send him my work soon. > > > > I think Cobalt Qube is slow and is hard to expand the memory. > > Slow that it is. As for memory it has two banks for 72 pin memory. I want > to add memory to the Qube I have. I have access to a Raq 2. But it won't take my old EDO SIMMs :-). Besides, it only supports an 2.2 kernel. H.J. From owner-linux-mips@oss.sgi.com Wed Oct 24 13:28:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKSxa03076 for linux-mips-outgoing; Wed, 24 Oct 2001 13:28:59 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKSuD03064 for ; Wed, 24 Oct 2001 13:28:56 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9OKSpE0022119; Wed, 24 Oct 2001 13:28:51 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9OKSpZD022113; Wed, 24 Oct 2001 13:28:51 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 24 Oct 2001 13:28:50 -0700 (PDT) From: James Simmons To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: I am looking for a mips machine In-Reply-To: <20011024132435.A7669@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 830 Lines: 29 > I have access to a Raq 2. But it won't take my old EDO SIMMs :-). That sucks. Have you have any luck with any memory chips? > Besides, it only supports an 2.2 kernel. jsimmons@borgcube:~$ cat /proc/cpuinfo cpu : MIPS cpu model : Nevada V10.0 system type : Cobalt Microserver 27 BogoMIPS : 249.85 byteorder : little endian unaligned accesses : 0 wait instruction : yes microsecond timers : yes extra interrupt vector : yes hardware watchpoint : no VCED exceptions : not available VCEI exceptions : not available jsimmons@borgcube:~$ uname -nr borgcube 2.4.10-mips jsimmons@borgcube:~$ Actually I need to migrate the code to the new time and pci code. I will be sending a diff to Ralph in the next few days. From owner-linux-mips@oss.sgi.com Wed Oct 24 13:30:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKUs403264 for linux-mips-outgoing; Wed, 24 Oct 2001 13:30:54 -0700 Received: from wep10a-3.wep.tudelft.nl (wep10a-3.wep.tudelft.nl [130.161.65.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKUnD03261 for ; Wed, 24 Oct 2001 13:30:50 -0700 Received: from banaan.taco.dhs.org (taco@wep10a-3.wep.tudelft.nl [130.161.65.38]) by wep10a-3.wep.tudelft.nl (8.12.1/8.12.1/Debian -2) with ESMTP id f9OKUgZS015448; Wed, 24 Oct 2001 22:30:42 +0200 Date: Wed, 24 Oct 2001 22:30:36 +0200 (CEST) From: Taco IJsselmuiden X-Sender: taco@banaan.taco.dhs.org Reply-To: Taco IJsselmuiden To: "H . J . Lu" cc: James Simmons , linux-mips@oss.sgi.com Subject: Re: I am looking for a mips machine In-Reply-To: <20011024132435.A7669@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1050 Lines: 38 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I have access to a Raq 2. But it won't take my old EDO SIMMs :-). Besides, > it only supports an 2.2 kernel. well, nog exactly: I've got a Raq 2 running 2.4.7-pre6 + pty-support here, running for 79 days now... don't know exacty which patches i used, but i think i can figure it out, if you like... at least one of the patches is named 'linux-2.4.7-pre6-mips-cobalt-v1.patch' ;)) it's currently used as a simpel web-server for development/test stuff. i could supply more info if you like that.... Cheers, Taco. - --- "One World, one Web, one Program" - Microsoft promo ad "Ein Volk, ein Reich, ein Fuhrer" - Adolf Hitler - --- GPG KeyID=0x9DD13814 GPG Fingerprint=7DF2 0E97 C5B9 6945 BD0B 3C9F E969 7018 9DD1 3814 GPG Key: http://www.taco.dhs.org/~taco/gpg.public.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE71yTx6WlwGJ3ROBQRAso7AJ9Ej0XVEl5hwWX020xuJk9Iw1NGFACbBeYN 2OXKbTbAM2NbfEiSEgdbg04= =gJlP -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Wed Oct 24 13:37:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKbOs03418 for linux-mips-outgoing; Wed, 24 Oct 2001 13:37:24 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKbKD03412 for ; Wed, 24 Oct 2001 13:37:20 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.2/8.11.2) id f9OKe8w03227 for linux-mips@oss.sgi.com; Wed, 24 Oct 2001 22:40:08 +0200 Date: Wed, 24 Oct 2001 22:40:08 +0200 From: Lukas Hejtmanek To: linux-mips@oss.sgi.com Subject: Origin 200 Message-ID: <20011024224008.A2045@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9OKe8w03227 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9OKbLD03413 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 446 Lines: 11 Is someone here who succesfully booted up an 1 processor Origin 200? I've tried to boot some kernels -- result freeze without oops or oops result. Kernel 2.4.10 is configured with defconfig-ip27, with or without SMP support. Everything seems to get the same result. Is there any remote gdb howto? Especially for origin where serial port is used as serial console. (I think gdb must connect to kernel before oops or freeze) -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Wed Oct 24 13:44:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKieE03890 for linux-mips-outgoing; Wed, 24 Oct 2001 13:44:40 -0700 Received: from thor ([207.246.91.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKibD03886 for ; Wed, 24 Oct 2001 13:44:37 -0700 Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA12018; Wed, 24 Oct 2001 16:42:06 -0400 Date: Wed, 24 Oct 2001 16:42:06 -0400 From: "J. Scott Kasten" To: "H . J . Lu" cc: Subject: Re: I am looking for a mips machine In-Reply-To: <20011024121944.B6520@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1045 Lines: 25 My general impression is that your looking for a "FAST" board, and a little endian board make for mutually exclusive requirements. Not that little endian couldn't be fast, but just about every piece of hardware I've seen running little endian has used one of the lesser mips chips in it where they've cut corners multiplexing address and data over the same pins and so forth. Someone correct me if I'm wrong, but of all the ones I've looked at, the little endian boards had the less capable hardware to boot. I think that's because the market was being driven by these little Win CE things, and CE only supports little endian. On Wed, 24 Oct 2001, H . J . Lu wrote: > On Wed, Oct 24, 2001 at 11:19:27AM -0700, James Simmons wrote: > > > > I use a Cobalt Qube for alot of my developement. It works fine. I know it > > is not in Ralph's tree yet but I plan to send him my work soon. > > I think Cobalt Qube is slow and is hard to expand the memory. I need at > least 128MB RAM. Also the current mips kernel doesn't support it. > > > H.J. > From owner-linux-mips@oss.sgi.com Wed Oct 24 13:48:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKmW704210 for linux-mips-outgoing; Wed, 24 Oct 2001 13:48:32 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKmTD04203 for ; Wed, 24 Oct 2001 13:48:29 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA26555; Wed, 24 Oct 2001 16:48:13 -0400 Date: Wed, 24 Oct 2001 16:48:13 -0400 (EDT) From: X-Sender: nick@ns To: Lukas Hejtmanek cc: linux-mips@oss.sgi.com Subject: Re: Origin 200 In-Reply-To: <20011024224008.A2045@mail.muni.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f9OKmUD04205 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 656 Lines: 19 I had very similar problems, where does it oops? I lost access to the origin that was haveing problems before tracking it down :(. Nick On Wed, 24 Oct 2001, Lukas Hejtmanek wrote: > > Is someone here who succesfully booted up an 1 processor Origin 200? I've tried > to boot some kernels -- result freeze without oops or oops result. Kernel 2.4.10 > is configured with defconfig-ip27, with or without SMP support. Everything seems > to get the same result. > > Is there any remote gdb howto? Especially for origin where serial port is used > as serial console. (I think gdb must connect to kernel before oops or freeze) > > -- > Lukáš Hejtmánek > From owner-linux-mips@oss.sgi.com Wed Oct 24 13:58:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKwg904689 for linux-mips-outgoing; Wed, 24 Oct 2001 13:58:42 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKwcD04685 for ; Wed, 24 Oct 2001 13:58:38 -0700 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9OL0YB13623; Wed, 24 Oct 2001 14:00:34 -0700 Subject: Re: I am looking for a mips machine From: Pete Popov To: "J. Scott Kasten" Cc: "H . J . Lu" , linux-mips@oss.sgi.com In-reply-to: <20011024121944.B6520@lucon.org> X-Authentication-warning: oss.sgi.com: mail owned process doing -bs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15.99+cvs.2001.10.09.08.08 (Preview Release) Date: 24 Oct 2001 14:00:15 -0700 Message-Id: <1003957215.26240.29.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1620 Lines: 41 On Wed, 2001-10-24 at 13:42, J. Scott Kasten wrote: > > My general impression is that your looking for a "FAST" board, and a > little endian board make for mutually exclusive requirements. Not that > little endian couldn't be fast, but just about every piece of hardware > I've seen running little endian has used one of the lesser mips chips in > it where they've cut corners multiplexing address and data over the same > pins and so forth. Someone correct me if I'm wrong, but of all the ones > I've looked at, the little endian boards had the less capable hardware to > boot. I think that's because the market was being driven by these little > Win CE things, and CE only supports little endian. Well, not quite. Linux supports LE too but the choice of LE mips desktop systems is limited. The fastest LE cpu/board I've worked with is the Alchemy Au1000 part running at 396MHz. The board doesn't have and IDE or SCSI controller though. However, it has pcmcia and we've added support for their pcmcia controller, so I was able to use a Hitachi 2GB pcmcia ata card (looks like the IBM Microdrive). That might be one option for reasonably fast native compiles. Pete > > On Wed, 24 Oct 2001, H . J . Lu wrote: > > > On Wed, Oct 24, 2001 at 11:19:27AM -0700, James Simmons wrote: > > > > > > I use a Cobalt Qube for alot of my developement. It works fine. I know it > > > is not in Ralph's tree yet but I plan to send him my work soon. > > > > I think Cobalt Qube is slow and is hard to expand the memory. I need at > > least 128MB RAM. Also the current mips kernel doesn't support it. > > > > > > H.J. > > > From owner-linux-mips@oss.sgi.com Wed Oct 24 14:03:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OL3LP04920 for linux-mips-outgoing; Wed, 24 Oct 2001 14:03:21 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OL3ID04916 for ; Wed, 24 Oct 2001 14:03:19 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.2/8.11.2) id f9OL61R03550; Wed, 24 Oct 2001 23:06:01 +0200 Date: Wed, 24 Oct 2001 23:06:01 +0200 From: Lukas Hejtmanek To: nick@snowman.net Cc: linux-mips@oss.sgi.com Subject: Re: Origin 200 Message-ID: <20011024230601.B2045@mail.muni.cz> References: <20011024224008.A2045@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@snowman.net on Wed, Oct 24, 2001 at 04:48:13PM -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9OL61R03550 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9OL3JD04917 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 655 Lines: 14 On Wed, Oct 24, 2001 at 04:48:13PM -0400, nick@snowman.net wrote: > I had very similar problems, where does it oops? I lost access to the origin > that was haveing problems before tracking it down :(. Nick It seems to be at random place. I don't know what correct boot mesages look like. Few times it freezed after amount memmory message, few times after message about RT Link socket (or somewhat), sometimes after serial driver initialized. Once it freezed after scsi driver loaded. I think it has nothing to do with any driver because the same kernel freez or oops at different place. Do you have any idea how to track it down? -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Wed Oct 24 14:24:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OLOll06020 for linux-mips-outgoing; Wed, 24 Oct 2001 14:24:47 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OLOiD06017 for ; Wed, 24 Oct 2001 14:24:44 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9OLQjB14950; Wed, 24 Oct 2001 14:26:45 -0700 Message-ID: <3BD73196.CA3DFF9@mvista.com> Date: Wed, 24 Oct 2001 14:24:38 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: I am looking for a mips machine References: <20011024080356.A2440@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 652 Lines: 32 "H . J . Lu" wrote: > > Hi, > > I am looking for a mips machine to continue working on my mips port > of RedHat. My requirements are > > 1. It has the stable, up to date kernel support. That means I can do > > # ./configure > # make bootstrap > # make check > > for gcc 3.1 without a kernel oops. > > 2. It has decent CPU. I hate to wait a day for > > # make bootstrap > > 3. Inexpensive. > > 4. Support serial console. > > 5. Little endian is preferred. > > Does anyone have any recommendations? > It appears Malta from MIPS and Ocelot Dev box from Momentum should fit your need. I think both would cost about $3000 a piece though. Jun From owner-linux-mips@oss.sgi.com Wed Oct 24 15:49:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OMnXI08327 for linux-mips-outgoing; Wed, 24 Oct 2001 15:49:33 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OMnVD08323 for ; Wed, 24 Oct 2001 15:49:31 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA29896; Wed, 24 Oct 2001 18:49:17 -0400 Date: Wed, 24 Oct 2001 18:49:17 -0400 (EDT) From: X-Sender: nick@ns To: Lukas Hejtmanek cc: linux-mips@oss.sgi.com Subject: Re: Origin 200 In-Reply-To: <20011024230601.B2045@mail.muni.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f9OMnVD08325 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 830 Lines: 22 That's exactly the issues I was running into. Talk to Ralf. Erm, is it a company system? Nick On Wed, 24 Oct 2001, Lukas Hejtmanek wrote: > On Wed, Oct 24, 2001 at 04:48:13PM -0400, nick@snowman.net wrote: > > I had very similar problems, where does it oops? I lost access to the origin > > that was haveing problems before tracking it down :(. Nick > > It seems to be at random place. I don't know what correct boot mesages look > like. Few times it freezed after amount memmory message, few times after message > about RT Link socket (or somewhat), sometimes after serial driver initialized. > Once it freezed after scsi driver loaded. I think it has nothing to do with any > driver because the same kernel freez or oops at different place. > > Do you have any idea how to track it down? > > -- > Lukáš Hejtmánek > From owner-linux-mips@oss.sgi.com Wed Oct 24 16:01:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ON1ha09301 for linux-mips-outgoing; Wed, 24 Oct 2001 16:01:43 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ON1eD09288 for ; Wed, 24 Oct 2001 16:01:40 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.2/8.11.2) id f9ON4Pc04035; Thu, 25 Oct 2001 01:04:25 +0200 Date: Thu, 25 Oct 2001 01:04:25 +0200 From: Lukas Hejtmanek To: nick@snowman.net Cc: linux-mips@oss.sgi.com Subject: Re: Origin 200 Message-ID: <20011025010425.C2045@mail.muni.cz> References: <20011024230601.B2045@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@snowman.net on Wed, Oct 24, 2001 at 06:49:17PM -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9ON4Pc04035 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9ON1fD09298 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 351 Lines: 11 On Wed, Oct 24, 2001 at 06:49:17PM -0400, nick@snowman.net wrote: > That's exactly the issues I was running into. Talk to Ralf. Erm, is it > a company system? No, we have that box at school. Why? IRIX is normally running there but we have forgotten root password ;-) Also it is my diploma work to make it run in 64bit mode. -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Wed Oct 24 16:14:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ONEHR12051 for linux-mips-outgoing; Wed, 24 Oct 2001 16:14:17 -0700 Received: from dea.linux-mips.net (a1as08-p163.stg.tli.de [195.252.188.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ONECD12046 for ; Wed, 24 Oct 2001 16:14:13 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9ONDHv30842; Thu, 25 Oct 2001 01:13:17 +0200 Date: Thu, 25 Oct 2001 01:13:17 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: pmanolov@Lnxw.COM, linux-mips@oss.sgi.com Subject: Re: Malta probs Message-ID: <20011025011317.B30792@dea.linux-mips.net> References: <20011023224718.A6283@dea.linux-mips.net> <3BD5E193.BB41A907@lnxw.com> <20011024024308.A21460@dea.linux-mips.net> <20011024.220729.39150004.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011024.220729.39150004.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Oct 24, 2001 at 10:07:29PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 550 Lines: 14 On Wed, Oct 24, 2001 at 10:07:29PM +0900, Atsushi Nemoto wrote: > ralf> just restructured in a way that allows adding of new CPU types > ralf> and - even more important - get the code maintainable again. As > ralf> it is right now > > In current CVS, All handle_xxx exception handler seems to be complied > with ".set mips3". Here is a patch. I think this patch solves the > problem reported by Petko. Correct. In addition there were also assembler options hardwired in arch/mips/kernel/Makefile which never should have made it there. Ralf From owner-linux-mips@oss.sgi.com Wed Oct 24 16:19:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ONJav12225 for linux-mips-outgoing; Wed, 24 Oct 2001 16:19:36 -0700 Received: from dea.linux-mips.net (a1as08-p163.stg.tli.de [195.252.188.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ONJWD12222 for ; Wed, 24 Oct 2001 16:19:33 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9ONJJ230904; Thu, 25 Oct 2001 01:19:19 +0200 Date: Thu, 25 Oct 2001 01:19:19 +0200 From: Ralf Baechle To: Klaus Naumann Cc: "H . J . Lu" , linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: The Linux binutils 2.11.92.0.7 is released. Message-ID: <20011025011919.A30889@dea.linux-mips.net> References: <20011023171823.B3644@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spock@mgnet.de on Wed, Oct 24, 2001 at 08:43:35AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 274 Lines: 8 On Wed, Oct 24, 2001 at 08:43:35AM +0200, Klaus Naumann wrote: > So to ask again, there is no other solution than -xgot ? > And if that's the only solution, what are the issues ? Only bigger code ? Alternative solutions would require significant work on binutils. Ralf From owner-linux-mips@oss.sgi.com Wed Oct 24 17:23:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P0NG815285 for linux-mips-outgoing; Wed, 24 Oct 2001 17:23:16 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P0NDD15280 for ; Wed, 24 Oct 2001 17:23:14 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id UAA31991; Wed, 24 Oct 2001 20:23:00 -0400 Date: Wed, 24 Oct 2001 20:23:00 -0400 (EDT) From: X-Sender: nick@ns To: Lukas Hejtmanek cc: linux-mips@oss.sgi.com Subject: Re: Origin 200 In-Reply-To: <20011025010425.C2045@mail.muni.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f9P0NED15281 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 809 Lines: 24 Getting it running 64bit shouldn't be *too* bad, however there are some revs of some chips on the MB which linux currently can't deal with, and noone is quite sure 1. what revs, 2. why, or 3. anything usefull. . Could you send a hinv -v from the prom? Boot logs would also be usefull (so I can tell if we are haveing the exact same problem, or just similar ones) Thanks Nick On Thu, 25 Oct 2001, Lukas Hejtmanek wrote: > On Wed, Oct 24, 2001 at 06:49:17PM -0400, nick@snowman.net wrote: > > That's exactly the issues I was running into. Talk to Ralf. Erm, is it > > a company system? > > No, we have that box at school. Why? IRIX is normally running there but we have > forgotten root password ;-) > > Also it is my diploma work to make it run in 64bit mode. > > -- > Lukáš Hejtmánek > From owner-linux-mips@oss.sgi.com Wed Oct 24 20:25:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P3PKQ30361 for linux-mips-outgoing; Wed, 24 Oct 2001 20:25:20 -0700 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P3P8D30355; Wed, 24 Oct 2001 20:25:08 -0700 Received: from mail3.sony.co.jp (GateKeeper8.Sony.CO.JP [146.215.0.71]) by ns5.sony.co.jp (R8/Sony) with ESMTP id f9P3P6L50258; Thu, 25 Oct 2001 12:25:06 +0900 (JST) Received: from mail3.sony.co.jp (localhost [127.0.0.1]) by mail3.sony.co.jp (R8) with ESMTP id f9P3P6123597; Thu, 25 Oct 2001 12:25:06 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail3.sony.co.jp (R8) with ESMTP id f9P3P5223584; Thu, 25 Oct 2001 12:25:05 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id MAA01256; Thu, 25 Oct 2001 12:29:24 +0900 (JST) Received: from mach0.sm.sony.co.jp (mach0.sm.sony.co.jp [43.2.226.27]) by imail.sm.sony.co.jp (8.9.3+3.2W/3.7W) with ESMTP id MAA14553; Thu, 25 Oct 2001 12:25:04 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id f9P3P4e18658; Thu, 25 Oct 2001 12:25:04 +0900 (JST) To: ralf@oss.sgi.com CC: linux-mips@oss.sgi.com Cc: takemura@sm.sony.co.jp, shin@sm.sony.co.jp Subject: Re: bug in memscan() In-Reply-To: <20011024182744T.machida@sm.sony.co.jp> References: <20011024182744T.machida@sm.sony.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011025122504L.machida@sm.sony.co.jp> Date: Thu, 25 Oct 2001 12:25:04 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1872 Lines: 63 Actually, we have a problem with japanese usb keyboard caused by this bug. Japanese usb keyboard generates scan codes which have MSB-on. From: Machida Hiroyuki Subject: bug in memscan() Date: Wed, 24 Oct 2001 18:27:44 +0900 > Memscan() must compare a given 2nd parameter with memory by using > unsinged char, as memchr() do. But, memscan() in > include/asm-mips/string.h and lib/string.c don't so. > > Please refer memchr() in sysdeps/generic/memchr.c of glic and > lib/string.c. Previous my patch for include/asm/string.h is not good. Please try this. Index: string.h =================================================================== RCS file: /cvs/linux/include/asm-mips/string.h,v retrieving revision 1.18 diff -u -p -r1.18 string.h --- string.h 2001/10/06 19:29:25 1.18 +++ string.h 2001/10/25 03:14:19 @@ -136,17 +136,18 @@ extern void *memmove(void *__dest, __con extern __inline__ void *memscan(void *__addr, int __c, size_t __size) { char *__end = (char *)__addr + __size; + unsigned char * __uc = (unsigned char) __c; __asm__(".set\tpush\n\t" ".set\tnoat\n\t" ".set\treorder\n\t" "1:\tbeq\t%0,%1,2f\n\t" "addiu\t%0,1\n\t" - "lb\t$1,-1(%0)\n\t" + "lbu\t$1,-1(%0)\n\t" "bne\t$1,%z4,1b\n" "2:\t.set\tpop" : "=r" (__addr), "=r" (__end) - : "0" (__addr), "1" (__end), "Jr" (__c)); + : "0" (__addr), "1" (__end), "Jr" (__uc)); return __addr; } Index: lib/string.c =================================================================== RCS file: /cvs/linux/lib/string.c,v retrieving revision 1.13 diff -u -p -r1.13 string.c --- lib/string.c 2001/06/13 17:28:17 1.13 +++ lib/string.c 2001/10/24 09:17:05 @@ -477,7 +477,7 @@ void * memscan(void * addr, int c, size_ unsigned char * e = p + size; while (p != e) { - if (*p == c) + if (*p == (unsigned char)c) return (void *) p; p++; } From owner-linux-mips@oss.sgi.com Thu Oct 25 00:11:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P7Bgl17194 for linux-mips-outgoing; Thu, 25 Oct 2001 00:11:42 -0700 Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P7BaD17184 for ; Thu, 25 Oct 2001 00:11:36 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id LAA13162; Thu, 25 Oct 2001 11:11:19 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id LAA06107; Thu, 25 Oct 2001 11:02:20 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id KAA11408; Thu, 25 Oct 2001 10:05:37 +0300 (MSK) Message-ID: <3BD7BA1B.AC8DF096@niisi.msk.ru> Date: Thu, 25 Oct 2001 11:07:07 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: RedHat 7.1/mips update References: <20011024121646.A6520@lucon.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 156 Lines: 9 "H . J . Lu" wrote: > > I updated my RedHat 7.1/mips port. There are quite a few changes. Check it > out. Could you provide a changelog ? Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Oct 25 00:14:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P7E3K17297 for linux-mips-outgoing; Thu, 25 Oct 2001 00:14:03 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P7E0D17293 for ; Thu, 25 Oct 2001 00:14:00 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B9F45125CA; Thu, 25 Oct 2001 00:13:59 -0700 (PDT) Date: Thu, 25 Oct 2001 00:13:59 -0700 From: "H . J . Lu" To: "Gleb O. Raiko" Cc: linux-mips@oss.sgi.com Subject: Re: RedHat 7.1/mips update Message-ID: <20011025001359.A17582@lucon.org> References: <20011024121646.A6520@lucon.org> <3BD7BA1B.AC8DF096@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: <3BD7BA1B.AC8DF096@niisi.msk.ru>; from raiko@niisi.msk.ru on Thu, Oct 25, 2001 at 11:07:07AM +0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 374 Lines: 14 On Thu, Oct 25, 2001 at 11:07:07AM +0400, Gleb O. Raiko wrote: > "H . J . Lu" wrote: > > > > I updated my RedHat 7.1/mips port. There are quite a few changes. Check it > > out. > > Could you provide a changelog ? I don't have the time for it. Just do ls and compare it against what you have. I updated quite a few rpms, most of them taken from RedHat 7.1 updates. H.J. From owner-linux-mips@oss.sgi.com Thu Oct 25 00:59:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P7xCF18980 for linux-mips-outgoing; Thu, 25 Oct 2001 00:59:12 -0700 Received: from mail.sonytel.be (main.sonytel.be [195.0.45.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P7x8D18977 for ; Thu, 25 Oct 2001 00:59:08 -0700 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA24990; Thu, 25 Oct 2001 09:58:11 +0200 (MET DST) Date: Thu, 25 Oct 2001 09:57:46 +0200 (MEST) From: Geert Uytterhoeven To: "J. Scott Kasten" cc: "H . J . Lu" , Linux/MIPS Development Subject: Re: I am looking for a mips machine In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1552 Lines: 33 On Wed, 24 Oct 2001, J. Scott Kasten wrote: > My general impression is that your looking for a "FAST" board, and a > little endian board make for mutually exclusive requirements. Not that > little endian couldn't be fast, but just about every piece of hardware > I've seen running little endian has used one of the lesser mips chips in > it where they've cut corners multiplexing address and data over the same > pins and so forth. Someone correct me if I'm wrong, but of all the ones > I've looked at, the little endian boards had the less capable hardware to > boot. I think that's because the market was being driven by these little > Win CE things, and CE only supports little endian. You can try a NEC DDBxxxx evaluation board with VR5000. They have jumpers to select endianness, but I never got them to work in big-endian mode. > On Wed, 24 Oct 2001, H . J . Lu wrote: > > On Wed, Oct 24, 2001 at 11:19:27AM -0700, James Simmons wrote: > > > I use a Cobalt Qube for alot of my developement. It works fine. I know it > > > is not in Ralph's tree yet but I plan to send him my work soon. > > > > I think Cobalt Qube is slow and is hard to expand the memory. I need at > > least 128MB RAM. Also the current mips kernel doesn't support it. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Thu Oct 25 01:29:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P8Tlv27207 for linux-mips-outgoing; Thu, 25 Oct 2001 01:29:47 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P8TgD27202 for ; Thu, 25 Oct 2001 01:29:42 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA22794; Thu, 25 Oct 2001 01:28:20 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA03252; Thu, 25 Oct 2001 01:28:18 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f9P8SIa29367; Thu, 25 Oct 2001 10:28:19 +0200 (MEST) Message-ID: <3BD7CD22.A9FEBC3@mips.com> Date: Thu, 25 Oct 2001 10:28:18 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: I am looking for a mips machine References: <20011024080356.A2440@lucon.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1192 Lines: 53 Hi, I promised you a Malta some time ago, but we have been short on the boards. We should get some in the very near future, so I hope to be able to send you a board. You can run the board in both endianness. I can probably not give you a very fast system at the moment, but hopefully when we have some faster CPUs, I can ship a faster daughter card. /Carsten "H . J . Lu" wrote: > Hi, > > I am looking for a mips machine to continue working on my mips port > of RedHat. My requirements are > > 1. It has the stable, up to date kernel support. That means I can do > > # ./configure > # make bootstrap > # make check > > for gcc 3.1 without a kernel oops. > > 2. It has decent CPU. I hate to wait a day for > > # make bootstrap > > 3. Inexpensive. > > 4. Support serial console. > > 5. Little endian is preferred. > > Does anyone have any recommendations? > > Thanks. > > H.J. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Oct 25 01:30:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9P8UpM27319 for linux-mips-outgoing; Thu, 25 Oct 2001 01:30:51 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9P8UlD27316 for ; Thu, 25 Oct 2001 01:30:48 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.2/8.11.2) id f9P8XXG04778; Thu, 25 Oct 2001 10:33:33 +0200 Date: Thu, 25 Oct 2001 10:33:33 +0200 From: Lukas Hejtmanek To: nick@snowman.net Cc: linux-mips@oss.sgi.com Subject: Re: Origin 200 Message-ID: <20011025103333.E2045@mail.muni.cz> References: <20011025010425.C2045@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@snowman.net on Wed, Oct 24, 2001 at 08:23:00PM -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9P8XXG04778 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9P8UmD27317 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1200 Lines: 29 On Wed, Oct 24, 2001 at 08:23:00PM -0400, nick@snowman.net wrote: > Getting it running 64bit shouldn't be *too* bad, however there are some > revs of some chips on the MB which linux currently can't deal with, and > noone is quite sure 1. what revs, 2. why, or 3. anything > usefull. . Could you send a hinv -v from the prom? Boot logs would > also be usefull (so I can tell if we are haveing the exact same problem, > or just similar ones) >> hinv -v IP27 Node Board, Module 1, Slot MotherBoard ASIC HUB Rev 3, 90 MHz, (nasid 0) Processor A: 180 MHz R10000, Rev 2.6, 1M 120MHz secondary cache, (cpu 0) R10000FPC Rev 0 Memory on board, 64 MBytes (Standard) Bank 0, 64 MBytes (Standard) <-- (Physical Bank 0) BASEIO Origin 200 IO Board, Module 1, Slot MotherBoard ASIC BRIDGE Rev 3, (widget 8) adapter PCI-SCSI Rev 4, (pci id 0) peripheral SCSI DISK, ID 1, SGI IBM DORS-32160W adapter PCI-SCSI Rev 4, (pci id 1) peripheral SCSI CDROM, ID 6, TOSHIBA CD-ROM XM-5401TA adapter IOC3 Rev 1, (pci id 2) controller multi function SuperIO controller Ethernet Rev 1 adapter PCI-SCSI Rev 5, (pci id 5) -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Thu Oct 25 03:15:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PAFeP31501 for linux-mips-outgoing; Thu, 25 Oct 2001 03:15:40 -0700 Received: from dea.linux-mips.net (a1as16-p224.stg.tli.de [195.252.192.224]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PAFVD31498 for ; Thu, 25 Oct 2001 03:15:31 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9PAEok01686; Thu, 25 Oct 2001 12:14:50 +0200 Date: Thu, 25 Oct 2001 12:14:50 +0200 From: Ralf Baechle To: Lukas Hejtmanek Cc: nick@snowman.net, linux-mips@oss.sgi.com Subject: Re: Origin 200 Message-ID: <20011025121450.A1644@dea.linux-mips.net> References: <20011025010425.C2045@mail.muni.cz> <20011025103333.E2045@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025103333.E2045@mail.muni.cz>; from xhejtman@mail.muni.cz on Thu, Oct 25, 2001 at 10:33:33AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1071 Lines: 26 On Thu, Oct 25, 2001 at 10:33:33AM +0200, Lukas Hejtmanek wrote: > On Wed, Oct 24, 2001 at 08:23:00PM -0400, nick@snowman.net wrote: > > Getting it running 64bit shouldn't be *too* bad, however there are some > > revs of some chips on the MB which linux currently can't deal with, and > > noone is quite sure 1. what revs, 2. why, or 3. anything > > usefull. . Could you send a hinv -v from the prom? Boot logs would > > also be usefull (so I can tell if we are haveing the exact same problem, > > or just similar ones) > > >> hinv -v > IP27 Node Board, Module 1, Slot MotherBoard > ASIC HUB Rev 3, 90 MHz, (nasid 0) [...] Pretty much a standard Origin. I suspect the problem might be related to machines which only have a single physical CPU, that was the only common thing between all the Origins on which Linux fails. And indeed I don't think we ever used such a small configuration for testing at SGI ... Nick, did you observe any interesting differences to your failing Origin configuration? Btw, Origin UP kernel is definately broken ... Ralf From owner-linux-mips@oss.sgi.com Thu Oct 25 10:30:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PHUil20451 for linux-mips-outgoing; Thu, 25 Oct 2001 10:30:44 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PHUVD20445; Thu, 25 Oct 2001 10:30:31 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9PHUSE0011566; Thu, 25 Oct 2001 10:30:28 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9PHUSkM011562; Thu, 25 Oct 2001 10:30:28 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 25 Oct 2001 10:30:28 -0700 (PDT) From: James Simmons To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] Various diffs that fix things. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3153 Lines: 88 Some of these patches are need to make the mips tree compile again. Please apply. Thank you. --- /tmp/linux-sgi/include/asm-mips/bugs.h Wed Oct 24 16:25:45 2001 +++ bugs.h Thu Oct 25 10:15:24 2001 @@ -3,6 +3,7 @@ * Copyright (C) 1997, 1999 Ralf Baechle */ #include +#include #include /* --- /tmp/linux-sgi/include/asm-mips/processor.h Fri Oct 19 13:51:06 2001 +++ processor.h Thu Oct 25 10:15:24 2001 @@ -40,6 +40,7 @@ * System setup and hardware flags.. */ extern void (*cpu_wait)(void); /* only available on R4[26]00 and R3081 */ +extern void r39xx_wait(void); extern void r3081_wait(void); extern void r4k_wait(void); extern char cyclecounter_available; /* only available from R4000 upwards. */ --- linux-sgi/drivers/i2c/Config.in Fri Oct 19 11:47:49 2001 +++ linux-mips/drivers/i2c/Config.in Thu Jun 21 19:29:32 2001 @@ -27,13 +27,6 @@ fi fi - if [ "$CONFIG_MIPS_ITE8172" = "y" ]; then - dep_tristate 'ITE I2C Algorithm' CONFIG_ITE_I2C_ALGO $CONFIG_I2C - if [ "$CONFIG_ITE_I2C_ALGO" != "n" ]; then - dep_tristate ' ITE I2C Adapter' CONFIG_ITE_I2C_ADAP $CONFIG_ITE_I2C_ALGO - fi - fi - # This is needed for automatic patch generation: sensors code starts here # This is needed for automatic patch generation: sensors code ends here --- /tmp/linux-sgi/drivers/char/Config.in Fri Oct 19 11:12:40 2001 +++ Config.in Thu Oct 25 10:25:19 2001 @@ -68,6 +68,11 @@ fi if [ "$CONFIG_MIPS_ITE8172" = "y" -o "$CONFIG_MIPS_IVR" = "y" ]; then bool 'Enable Qtronix 990P Keyboard Support' CONFIG_QTRONIX_KEYBOARD + if [ "$CONFIG_QTRONIX_KEYBOARD" = "y" ]; then + define_bool CONFIG_IT8172_CIR y + else + bool ' Enable PS2 Keyboard Support' CONFIG_PC_KEYB + fi bool 'Enable Smart Card Reader 0 Support ' CONFIG_IT8172_SCR0 bool 'Enable Smart Card Reader 1 Support ' CONFIG_IT8172_SCR1 fi @@ -82,24 +87,6 @@ fi bool ' Console on DC21285 serial port' CONFIG_SERIAL_21285_CONSOLE fi - if [ "$CONFIG_MIPS" = "y" ]; then - bool ' TMPTX3912/PR31700 serial port support' CONFIG_SERIAL_TX3912 - dep_bool ' Console on TMPTX3912/PR31700 serial port' CONFIG_SERIAL_TX3912_CONSOLE $CONFIG_SERIAL_TX3912 - bool ' Enable Au1000 UART Support' CONFIG_AU1000_UART - if [ "$CONFIG_AU1000_UART" = "y" ]; then - bool ' Enable Au1000 serial console' CONFIG_AU1000_SERIAL_CONSOLE - fi - fi -fi -if [ "$CONFIG_IT8712" = "y" ]; then - bool 'Enable Qtronix 990P Keyboard Support' CONFIG_QTRONIX_KEYBOARD - if [ "$CONFIG_QTRONIX_KEYBOARD" = "y" ]; then - define_bool CONFIG_IT8172_CIR y - else - bool ' Enable PS2 Keyboard Support' CONFIG_PC_KEYB - fi - bool 'Enable Smart Card Reader 0 Support ' CONFIG_IT8172_SCR0 - bool 'Enable Smart Card Reader 1 Support ' CONFIG_IT8172_SCR1 fi bool 'Unix98 PTY support' CONFIG_UNIX98_PTYS if [ "$CONFIG_UNIX98_PTYS" = "y" ]; then @@ -177,6 +164,7 @@ fi fi tristate ' ZF MachZ Watchdog' CONFIG_MACHZ_WDT + dep_tristate ' NEC VR41xx Watchdog (DSU)' CONFIG_VR41XX_WDT $CONFIG_CPU_VR41XX fi endmenu From owner-linux-mips@oss.sgi.com Thu Oct 25 10:39:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PHdPV20727 for linux-mips-outgoing; Thu, 25 Oct 2001 10:39:25 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PHdKD20719; Thu, 25 Oct 2001 10:39:20 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9PHdHE0012136; Thu, 25 Oct 2001 10:39:17 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9PHdHNG012132; Thu, 25 Oct 2001 10:39:17 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 25 Oct 2001 10:39:17 -0700 (PDT) From: James Simmons To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Compile issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 520 Lines: 13 I get the following errors when compiling. It barfs at mips/kernel/setup.c. I would send you a patch but I don't know what values you want to set these to. setup.c: In function `cpu_probe': setup.c:246: `PRID_REV_TX3927B' undeclared (first use in this function) setup.c:246: (Each undeclared identifier is reported only once setup.c:246: for each function it appears in.) setup.c:256: `PRID_REV_TX39H3TEG' undeclared (first use in this function) setup.c:275: `PRID_IMP_TX49' undeclared (first use in this function) From owner-linux-mips@oss.sgi.com Thu Oct 25 11:59:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PIxui27903 for linux-mips-outgoing; Thu, 25 Oct 2001 11:59:56 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PIxlD27899; Thu, 25 Oct 2001 11:59:47 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA18616; Thu, 25 Oct 2001 14:59:41 -0400 Date: Thu, 25 Oct 2001 14:59:41 -0400 (EDT) From: X-Sender: nick@ns To: Ralf Baechle cc: Lukas Hejtmanek , linux-mips@oss.sgi.com Subject: Re: Origin 200 In-Reply-To: <20011025121450.A1644@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1391 Lines: 36 I didn't notice any huge differences. My ASIC HUB ran at a different speed, 120mhz IIRC. I will try to aquire a single proc module for my o200. Lukas: Can I get a copy of your boot messages under linux? Thanks Nick On Thu, 25 Oct 2001, Ralf Baechle wrote: > On Thu, Oct 25, 2001 at 10:33:33AM +0200, Lukas Hejtmanek wrote: > > > On Wed, Oct 24, 2001 at 08:23:00PM -0400, nick@snowman.net wrote: > > > Getting it running 64bit shouldn't be *too* bad, however there are some > > > revs of some chips on the MB which linux currently can't deal with, and > > > noone is quite sure 1. what revs, 2. why, or 3. anything > > > usefull. . Could you send a hinv -v from the prom? Boot logs would > > > also be usefull (so I can tell if we are haveing the exact same problem, > > > or just similar ones) > > > > >> hinv -v > > IP27 Node Board, Module 1, Slot MotherBoard > > ASIC HUB Rev 3, 90 MHz, (nasid 0) > [...] > > Pretty much a standard Origin. I suspect the problem might be related to > machines which only have a single physical CPU, that was the only common > thing between all the Origins on which Linux fails. And indeed I don't > think we ever used such a small configuration for testing at SGI ... > > Nick, did you observe any interesting differences to your failing Origin > configuration? > > Btw, Origin UP kernel is definately broken ... > > Ralf > From owner-linux-mips@oss.sgi.com Thu Oct 25 15:15:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PMFDb06679 for linux-mips-outgoing; Thu, 25 Oct 2001 15:15:13 -0700 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PMFB006675 for ; Thu, 25 Oct 2001 15:15:11 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id PAA16365; Thu, 25 Oct 2001 15:15:06 -0700 (PDT) Date: Thu, 25 Oct 2001 15:15:06 -0700 From: Geoffrey Espin To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: RedHat 7.1/mips update Message-ID: <20011025151506.A13071@idiom.com> References: <20011024121646.A6520@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20011024121646.A6520@lucon.org>; from H . J . Lu on Wed, Oct 24, 2001 at 12:16:46PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 469 Lines: 19 H.J. > I updated my RedHat 7.1/mips port. There are quite a few changes. Check it > out. Thanks... works great, as did the last one, as far as I could tell. Sadly, the only fix I wanted didn't make it in: mipsel-linux-gcc ... Assembler messages: Warning: The -mcpu option is deprecated. Please use -march and -mtune instead. Warning: The -march option is incompatible to -mipsN and therefore ignored. Oh, well. :-) Geoff -- Geoffrey Espin espin@idiom.com From owner-linux-mips@oss.sgi.com Thu Oct 25 15:25:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PMPdY07006 for linux-mips-outgoing; Thu, 25 Oct 2001 15:25:39 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PMPc007003 for ; Thu, 25 Oct 2001 15:25:38 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B6F65125CD; Thu, 25 Oct 2001 15:25:32 -0700 (PDT) Date: Thu, 25 Oct 2001 15:25:32 -0700 From: "H . J . Lu" To: Geoffrey Espin Cc: linux-mips@oss.sgi.com Subject: Re: RedHat 7.1/mips update Message-ID: <20011025152532.A32043@lucon.org> References: <20011024121646.A6520@lucon.org> <20011025151506.A13071@idiom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025151506.A13071@idiom.com>; from espin@idiom.com on Thu, Oct 25, 2001 at 03:15:06PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 404 Lines: 12 On Thu, Oct 25, 2001 at 03:15:06PM -0700, Geoffrey Espin wrote: > > mipsel-linux-gcc ... > Assembler messages: > Warning: The -mcpu option is deprecated. Please use -march and -mtune instead. > Warning: The -march option is incompatible to -mipsN and therefore ignored. It is intentional. Do what the message says. I only have to check my arch/mips/Makefile from -mcpu=xxx to -mtune=xxx. H.J. From owner-linux-mips@oss.sgi.com Thu Oct 25 18:33:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q1X6L25286 for linux-mips-outgoing; Thu, 25 Oct 2001 18:33:06 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q1Ws025275; Thu, 25 Oct 2001 18:32:54 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 26 Oct 2001 01:32:54 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 7AC3FB46B; Fri, 26 Oct 2001 10:32:52 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id KAA22743; Fri, 26 Oct 2001 10:32:52 +0900 (JST) Date: Fri, 26 Oct 2001 10:37:41 +0900 (JST) Message-Id: <20011026.103741.41627158.nemoto@toshiba-tops.co.jp> To: jsimmons@transvirtual.com Cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: [PATCH] Various diffs that fix things. From: Atsushi Nemoto In-Reply-To: References: X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1493 Lines: 39 >>>>> On Thu, 25 Oct 2001 10:30:28 -0700 (PDT), James Simmons said: jsimmons> --- /tmp/linux-sgi/include/asm-mips/processor.h Fri Oct 19 13:51:06 2001 jsimmons> +++ processor.h Thu Oct 25 10:15:24 2001 Sorry, this is my fault. Your patch is correct. >>>>> On Thu, 25 Oct 2001 10:39:17 -0700 (PDT), James Simmons said: jsimmons> I get the following errors when compiling. It barfs at jsimmons> mips/kernel/setup.c. I would send you a patch but I don't jsimmons> know what values you want to set these to. This is my fault too. Please apply this patch. Thank you. diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/cpu.h linux.new/include/asm-mips/cpu.h --- linux-sgi-cvs/include/asm-mips/cpu.h Mon Oct 22 10:30:09 2001 +++ linux.new/include/asm-mips/cpu.h Fri Oct 26 10:31:19 2001 @@ -55,6 +55,7 @@ #define PRID_IMP_R4640 0x2200 #define PRID_IMP_R4650 0x2200 /* Same as R4640 */ #define PRID_IMP_R5000 0x2300 +#define PRID_IMP_TX49 0x2d00 #define PRID_IMP_SONIC 0x2400 #define PRID_IMP_MAGIC 0x2500 #define PRID_IMP_RM7000 0x2700 @@ -87,6 +88,12 @@ #define PRID_REV_TX3912 0x0010 #define PRID_REV_TX3922 0x0030 #define PRID_REV_TX3927 0x0040 +#define PRID_REV_TX3927B 0x0041 +#define PRID_REV_TX39H3TEG 0x0050 +#define PRID_REV_TX4955 0x0011 +#define PRID_REV_TX4955A 0x0020 +#define PRID_REV_TX4927 0x0021 +#define PRID_REV_TX4927R2 0x0022 #ifndef _LANGUAGE_ASSEMBLY /* --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Fri Oct 26 02:53:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9Q9rRj22096 for linux-mips-outgoing; Fri, 26 Oct 2001 02:53:27 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9Q9rG022092 for ; Fri, 26 Oct 2001 02:53:16 -0700 Received: from 21cn.com ([61.140.60.248]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id CAA06744 for ; Fri, 26 Oct 2001 02:53:05 -0700 (PDT) mail_from (ajob4me@21cn.com) Message-Id: <200110260953.CAA06744@sgi.com> Received: from cc([210.5.16.43]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm1b3bd9649b; Fri, 26 Oct 2001 17:51:07 +0800 Date: Fri, 26 Oct 2001 17:49:26 +0800 From: 8route To: "nemoto@toshiba-tops.co.jp" CC: "linux-mips@oss.sgi.com" Subject: Toshiba TX3927 board boot problem. X-mailer: FoxMail 3.0 beta 1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="US_ASCII" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4380 Lines: 116 Dear all: Hi! I'm working on Toshiba TX3927 RISC Processor Reference board.During development I met a problem.Can someone give me some good suggestions? Let me describe the problem in details: TX3927 board cann't boot up via NFS.It will halt at ================================== VFS: Mounted root (NFS filesystem). Freeing unused kernel memory: 44k freed ======================================== and the reset switch on the TX3927 board cann't work anymore. The kernel is linux-2.2.13-20000211.tar.bz2 with Toshiba TX3927 patch, the NFS root file system is declinuxroot-990611.tgz. I've checked /var/log/messages and find sentence like this: authenticated mount request from 192.168.255.202... so I think NFS file system works well.Can someone give me some good suggestions to solve this problem? These are serial port output: ============================= Toshiba Bootloader for TX RISC Reference Kit Ver 000.10 Copyright (c) 1999, 2000 TOSHIBA Corporation TX3927JMR/JMI TX3927 Rev ( 0) CPU Clk 133Mhz, BUS Clk 66Mhz Slot [0] : MEM Base = 0x80040000, MEM Size = 0x00fc0000 FlashROM BFC00000 - BFFFFFFF Find Toshiba TX3927 PCI Controller. Find Toshiba TC35815 100Mbps Ethernet Controller. MON> info TX3927JMR/JMI TX3927 Rev ( 0) CPU Clk 133Mhz, BUS Clk 66Mhz Slot [0] : MEM Base = 0x80040000, MEM Size = 0x00fc0000 Chip Config TX3927 [ccfg] = 0004303b Pin Config TX3927 [pcfg] = 0ffc7101 SDCCR0 Reg TX3927 [sdccr0] = 000300e8 SDCCR1 Reg TX3927 [sdccr1] = 00000000 SDCCR2 Reg TX3927 [sdccr2] = 00000000 SDCCR3 Reg TX3927 [sdccr3] = 00000000 SDCCR4 Reg TX3927 [sdccr4] = 00000000 SDCCR5 Reg TX3927 [sdccr5] = 00000000 SDCCR6 Reg TX3927 [sdccr6] = 00000000 SDCCR7 Reg TX3927 [sdccr7] = 00000000 SDCTR1 Reg TX3927 [sdctr1] = 08010400 SDCTR2 Reg TX3927 [sdctr2] = 000000ff SDCTR3 Reg TX3927 [sdctr3] = 02020000 SDCCMD Reg TX3927 [sdccmd] = 20100031 RCCR 0 Reg TX3927 [rccr0] = 1fc35208 RCCR 1 Reg TX3927 [rccr1] = 00000000 RCCR 2 Reg TX3927 [rccr2] = 140064c8 RCCR 3 Reg TX3927 [rccr3] = 1003f698 RCCR 4 Reg TX3927 [rccr4] = 00000000 RCCR 5 Reg TX3927 [rccr5] = 00000000 RCCR 6 Reg TX3927 [rccr6] = 00000000 RCCR 7 Reg TX3927 [rccr7] = 00000000 Port 0. dbg 1.onbrd [serp] = 0 Baud Rate [baud] = 38400 Init exec cmd 1 [icmd1] = Init exec cmd 2 [icmd2] = Init exec cmd 3 [icmd3] = Init exec cmd 4 [icmd4] = cmdline [cmdl] = root=/dev/nfs rw ip=::::::rarp console=ttyS0 nfsroot=192.168.255.8:/work/nfsroot MON> br initialize TC35815 [100Mbps Ethernet]. tc35815 base address (0xa4000000) Link Speed : 100Mbps initialize TC35815 completion. Booting...: Using Reverse ARP. Ethernet address 00:00:39:04:F8:14 IP address 192.168.255.202 = C0A8FFCA Booting TFTP server from 192.168.255.8 = C0A8FF08 kernel file : C0A8FFCA ... Downloaded 1126720 ( 113140) bytes at a0080000 from TFTP server. Default:root=/dev/nfs rw ip=::::::rarp console=ttyS0 nfsroot=192.168.255.8:/work/nfsroot boot: Loading R[23]00 MMU routines. CPU revision is: 00002240 config reg = 001a0030 Instruction cache 8kb, linesize 16byte Data cache 4kb, linesize 16byte Linux version 2.2.13 (root@desktop) (gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)) #1 Tue Oct 23 09:45:59 HKT 2001 Toshiba Reference System Setup TX3927 133Mhz Initialize TX3927 PCI Controller. Calibrating delay loop... 105.68 BogoMIPS Memory: 14476k/16380k available (980k kernel code, 408k data) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP Starting kswapd v 1.5 setup_machine_info:Cpu typtx39_initialize: cflags set to 77 TX39 UART driver version 0.04 loop: registered device at major 7 initialize TC35815 [100Mbps Ethernet]. TC35815 : at 0xa4000000 IRQ:3 Link Speed : 100Mbps ADDR: 00:00:39:04:f8:14 initialize TC35815 completion. Sending RARP requests..... OK IP-Config: Got RARP answer from 192.168.255.8, my address is 192.168.255.202 IP-Config: Guessing netmask 255.255.255.0 Looking up port of RPC 100003/2 on 192.168.255.8 Looking up port of RPC 100005/1 on 192.168.255.8 VFS: Mounted root (NFS filesystem). Freeing unused kernel memory: 44k freed ======================================== Regards, 8route From owner-linux-mips@oss.sgi.com Fri Oct 26 03:59:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QAxgv24667 for linux-mips-outgoing; Fri, 26 Oct 2001 03:59:42 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QAxd024664 for ; Fri, 26 Oct 2001 03:59:39 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.6/8.11.6) id f9QB2Cg18173; Fri, 26 Oct 2001 13:02:12 +0200 Date: Fri, 26 Oct 2001 13:02:12 +0200 From: Lukas Hejtmanek To: nick@snowman.net Cc: linux-mips@oss.sgi.com Subject: Re: Origin 200 Message-ID: <20011026130212.C16290@mail.muni.cz> References: <20011025121450.A1644@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@snowman.net on Thu, Oct 25, 2001 at 02:59:41PM -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9QB2Cg18173 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9QAxe024665 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 621 Lines: 14 On Thu, Oct 25, 2001 at 02:59:41PM -0400, nick@snowman.net wrote: > I didn't notice any huge differences. My ASIC HUB ran at a different > speed, 120mhz IIRC. I will try to aquire a single proc module for my > o200. Lukas: Can I get a copy of your boot messages under linux? Copy of boot messages are at www.fi.muni.cz/~xhejtman/mips I've tried compile as small kernel as possible config is also at that web page messages also. It seems it booted ok to the last message kernel panic no root (that's ok nfsroot was not compiled in) But I tested it only once so mayby it is just random behaviour. -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Fri Oct 26 04:34:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QBY5526265 for linux-mips-outgoing; Fri, 26 Oct 2001 04:34:05 -0700 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QBY0026261 for ; Fri, 26 Oct 2001 04:34:00 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id f9QBXw427293 for ; Fri, 26 Oct 2001 13:33:58 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V44V813R; Fri, 26 Oct 2001 13:33:42 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Fri, 26 Oct 2001 13:33:42 +0200 (W. Europe Daylight Time) Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id <4YC1M56F>; Fri, 26 Oct 2001 13:36:32 +0200 Message-ID: <86048F07C015D311864100902760F1DD01B5E29B@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: Kernel 2.4.3 compile problem Date: Fri, 26 Oct 2001 13:36:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2545 Lines: 56 Hi. I tried to compile the kernel 2.4.3 but the process stops directly with the following error: saeanme@sae139c:/mipseb/usr/src/linux> make vmlinux mips-linux-gcc -I /mipseb/usr/src/linux-2.4.3/include/asm/gcc -D__KERNEL__ -I/mipseb/usr/src/linux-2.4.3/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -g -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -Wa,--trap -pipe -c -o init/main.o init/main.c In file included from /usr/lib/gcc-lib/mips-linux/egcs-2.91.66/include/stdarg.h:27, from /mipseb/usr/src/linux-2.4.3/include/linux/kernel.h:10, from /mipseb/usr/src/linux-2.4.3/include/linux/wait.h:13, from /mipseb/usr/src/linux-2.4.3/include/linux/fs.h:12, from /mipseb/usr/src/linux-2.4.3/include/linux/capability.h:17, from /mipseb/usr/src/linux-2.4.3/include/linux/binfmts.h:5, from /mipseb/usr/src/linux-2.4.3/include/linux/sched.h:9, from /mipseb/usr/src/linux-2.4.3/include/linux/mm.h:4, from /mipseb/usr/src/linux-2.4.3/include/linux/slab.h:14, from /mipseb/usr/src/linux-2.4.3/include/linux/proc_fs.h:5, from init/main.c:15: /usr/lib/gcc-lib/mips-linux/egcs-2.91.66/include/va-mips.h:278: parse error at null character In file included from /mipseb/usr/src/linux-2.4.3/include/linux/wait.h:13, from /mipseb/usr/src/linux-2.4.3/include/linux/fs.h:12, from /mipseb/usr/src/linux-2.4.3/include/linux/capability.h:17, from /mipseb/usr/src/linux-2.4.3/include/linux/binfmts.h:5, from /mipseb/usr/src/linux-2.4.3/include/linux/sched.h:9, from /mipseb/usr/src/linux-2.4.3/include/linux/mm.h:4, from /mipseb/usr/src/linux-2.4.3/include/linux/slab.h:14, from /mipseb/usr/src/linux-2.4.3/include/linux/proc_fs.h:5, from init/main.c:15: /mipseb/usr/src/linux-2.4.3/include/linux/kernel.h:62: parse error before `va_list' /mipseb/usr/src/linux-2.4.3/include/linux/kernel.h:62: warning: function declaration isn't a prototype make: *** [init/main.o] Error 1 saeanme@sae139c:/mipseb/usr/src/linux> I downloaded the kernel from ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/src/ and the compiler is the current from ftp://oss.sgi.com/pub/linux/mips/ Is this a combination that cannot work? Any help would be appreciated. best regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Fri Oct 26 07:28:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QESYK15717 for linux-mips-outgoing; Fri, 26 Oct 2001 07:28:34 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QESR015706; Fri, 26 Oct 2001 07:28:28 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.6/8.11.6) id f9QEVHg23815; Fri, 26 Oct 2001 16:31:17 +0200 Date: Fri, 26 Oct 2001 16:31:17 +0200 From: Lukas Hejtmanek To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Origin 200 Message-ID: <20011026163117.B27258@mail.muni.cz> References: <20011025010425.C2045@mail.muni.cz> <20011025103333.E2045@mail.muni.cz> <20011025121450.A1644@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025121450.A1644@dea.linux-mips.net>; from ralf@oss.sgi.com on Thu, Oct 25, 2001 at 12:14:50PM +0200 X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9QEVHg23815 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9QEST015707 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 571 Lines: 14 On Thu, Oct 25, 2001 at 12:14:50PM +0200, Ralf Baechle wrote: > Btw, Origin UP kernel is definately broken ... I think I've tracked down what makes freeze. If I use default config but network card driver and scsi driver (seems to be generic PCI device) kernel boots up to message I have no root (any time and not freezes I've changed little bit sources to print '... waiting ...' every 2 seconds in infinite loop before it does panic -- no root). So I think there is some deadlock after some PCI device driver init that does not occur in SMP mode. -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Fri Oct 26 09:13:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QGD2x23292 for linux-mips-outgoing; Fri, 26 Oct 2001 09:13:02 -0700 Received: from web11908.mail.yahoo.com (web11908.mail.yahoo.com [216.136.172.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QGCx023288 for ; Fri, 26 Oct 2001 09:12:59 -0700 Message-ID: <20011026161259.54925.qmail@web11908.mail.yahoo.com> Received: from [209.243.184.191] by web11908.mail.yahoo.com via HTTP; Fri, 26 Oct 2001 09:12:59 PDT Date: Fri, 26 Oct 2001 09:12:59 -0700 (PDT) From: Wayne Gowcher Subject: Backspace on Virtual Console causes oops To: linux-mips@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 899 Lines: 30 Dear All, I am having a problem with the backspace key on a virtual terminal on a 2.4.2 kernel. If I hit backspace when there is input at the command line - no problem it deletes the character before the cursor. But if I press backspace when there are no characters at the command prompt, the kernel throws an oops. The process causing the oops is Bash. Note, on the Serial console, backspace works fine all the time. Has anyone ever seen anything like this ? If you have how did you solve it ? Does anyone know the program flow / program details of what happens when backspace is pressed eg : Key In > Key passed to Routine X > Routine X passes it to Routine Y etc > Bash receives key. Or could someone point me to a doc that may explain this ? Thx __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-linux-mips@oss.sgi.com Fri Oct 26 09:39:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QGd5823884 for linux-mips-outgoing; Fri, 26 Oct 2001 09:39:05 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QGd0023881; Fri, 26 Oct 2001 09:39:00 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9QGcqE0004503; Fri, 26 Oct 2001 09:38:52 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9QGcopD004499; Fri, 26 Oct 2001 09:38:51 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 26 Oct 2001 09:38:50 -0700 (PDT) From: James Simmons To: Atsushi Nemoto cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: [PATCH] Various diffs that fix things. In-Reply-To: <20011026.103741.41627158.nemoto@toshiba-tops.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 969 Lines: 31 Thank you for the below patch. Applied :-) > diff -urP -x CVS -x .cvsignore linux-sgi-cvs/include/asm-mips/cpu.h linux.new/include/asm-mips/cpu.h > --- linux-sgi-cvs/include/asm-mips/cpu.h Mon Oct 22 10:30:09 2001 > +++ linux.new/include/asm-mips/cpu.h Fri Oct 26 10:31:19 2001 > @@ -55,6 +55,7 @@ > #define PRID_IMP_R4640 0x2200 > #define PRID_IMP_R4650 0x2200 /* Same as R4640 */ > #define PRID_IMP_R5000 0x2300 > +#define PRID_IMP_TX49 0x2d00 > #define PRID_IMP_SONIC 0x2400 > #define PRID_IMP_MAGIC 0x2500 > #define PRID_IMP_RM7000 0x2700 > @@ -87,6 +88,12 @@ > #define PRID_REV_TX3912 0x0010 > #define PRID_REV_TX3922 0x0030 > #define PRID_REV_TX3927 0x0040 > +#define PRID_REV_TX3927B 0x0041 > +#define PRID_REV_TX39H3TEG 0x0050 > +#define PRID_REV_TX4955 0x0011 > +#define PRID_REV_TX4955A 0x0020 > +#define PRID_REV_TX4927 0x0021 > +#define PRID_REV_TX4927R2 0x0022 > > #ifndef _LANGUAGE_ASSEMBLY > /* > --- > Atsushi Nemoto > From owner-linux-mips@oss.sgi.com Fri Oct 26 10:30:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QHU7e29668 for linux-mips-outgoing; Fri, 26 Oct 2001 10:30:07 -0700 Received: from web10802.mail.yahoo.com (web10802.mail.yahoo.com [216.136.130.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QHU4029665 for ; Fri, 26 Oct 2001 10:30:04 -0700 Message-ID: <20011026173004.78642.qmail@web10802.mail.yahoo.com> Received: from [12.146.133.130] by web10802.mail.yahoo.com via HTTP; Fri, 26 Oct 2001 10:30:04 PDT Date: Fri, 26 Oct 2001 10:30:04 -0700 (PDT) From: han han Subject: MIPS 32bit and 64bit mode To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 453 Lines: 18 Hi all, Does Anybody help me to clear some concepts about MIPS 5kc? How to detect and set a MIPS 5kc chip working in 32bit or 64bit mode? or the chip can automatically enter proper mode when it fetchs an MIPS 32/64 instruction? Also, does MIPS 5kc have some 64bit instructions? Thanks a lot in advance, --Han __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-linux-mips@oss.sgi.com Fri Oct 26 10:34:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QHYNJ29805 for linux-mips-outgoing; Fri, 26 Oct 2001 10:34:23 -0700 Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QHYJ029802 for ; Fri, 26 Oct 2001 10:34:20 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id UAA00972; Fri, 26 Oct 2001 20:34:08 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id VAA00854; Fri, 26 Oct 2001 21:23:29 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id UAA09739; Fri, 26 Oct 2001 20:29:08 +0300 (MSK) Message-ID: <3BD99DAC.EB762713@niisi.msk.ru> Date: Fri, 26 Oct 2001 21:30:20 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Wayne Gowcher CC: linux-mips@oss.sgi.com Subject: Re: Backspace on Virtual Console causes oops References: <20011026161259.54925.qmail@web11908.mail.yahoo.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 734 Lines: 25 Wayne Gowcher wrote: > > Dear All, > > I am having a problem with the backspace key on a > virtual terminal on a 2.4.2 kernel. If I hit backspace > when there is input at the command line - no problem > it deletes the character before the cursor. > But if I press backspace when there are no characters > at the command prompt, the kernel throws an oops. The > process causing the oops is Bash. > Note, on the Serial console, backspace works fine all > the time. > > Has anyone ever seen anything like this ? If you have > how did you solve it ? > Guess 1: You've got PC UARTs and drivers/char/serial.c Guess 2: TAB TAB in bash causes the oops too. Guess 3: You didn't change famous beep function in the driver. Regards, Gleb. From owner-linux-mips@oss.sgi.com Fri Oct 26 10:54:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QHse630324 for linux-mips-outgoing; Fri, 26 Oct 2001 10:54:40 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QHsb030318 for ; Fri, 26 Oct 2001 10:54:37 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id KAA12163; Fri, 26 Oct 2001 10:54:25 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA14156; Fri, 26 Oct 2001 10:54:26 -0700 (PDT) Message-ID: <038401c15e47$50331ae0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "han han" , References: <20011026173004.78642.qmail@web10802.mail.yahoo.com> Subject: Re: MIPS 32bit and 64bit mode Date: Fri, 26 Oct 2001 19:54:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1363 Lines: 37 > Does Anybody help me to clear some concepts about MIPS > 5kc? > How to detect and set a MIPS 5kc chip working in 32bit > or 64bit mode? or the chip can automatically enter > proper mode when it fetchs an MIPS 32/64 instruction? > > Also, does MIPS 5kc have some 64bit instructions? I guess somebody (probably me) need to write a MIPS32/MIPS64 FAQ one of these days. To answer your last question first, yes, the MIPS5Kc has the full compliment of 64-bit integer instructions. It does not have the integrated FPU of the 5Kf, however, so you have neither 32-bit nor 64-bit FP instructions. There are two kinds of "64-bit-ness" to consider: 64-bit data types and 64-bit addresses. In kernel mode, a MIPS64 CPU always has access to 64-bit data types, but to have 64-bit instructions in user mode, one needs to explicitly enable them in the CP0.Status register. In pre-MIPS64 64-bit MIPS CPUs such as the R4000 and R5000, user mode access to 64-bit data types was only possible if 64-bit addressing was also enabled for user mode by setting the CP0.Status.UX bit. Kernel mode 64-bit addressing is independently enabled by setting the CP0.Status.KX bit. In MIPS64 (e.g. the 5Kc), it is also possible to enable 64-bit data types in user mode *without* 64-bit addressing by setting the CP0.Status.PX bit (bit 23). Regards, Kevin K. From owner-linux-mips@oss.sgi.com Fri Oct 26 10:55:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QHt6130386 for linux-mips-outgoing; Fri, 26 Oct 2001 10:55:06 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QHt3030382 for ; Fri, 26 Oct 2001 10:55:03 -0700 Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5]) by mcp.csh.rit.edu (Postfix) with ESMTP id CF104D4E; Fri, 26 Oct 2001 13:55:01 -0400 (EDT) Date: Fri, 26 Oct 2001 13:54:59 -0400 (EDT) From: George Gensure To: han han Cc: Subject: Re: MIPS 32bit and 64bit mode In-Reply-To: <20011026173004.78642.qmail@web10802.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 719 Lines: 31 is the 5kc the same processor as the r5k? George On Fri, 26 Oct 2001, han han wrote: > Hi all, > > Does Anybody help me to clear some concepts about MIPS > 5kc? > How to detect and set a MIPS 5kc chip working in 32bit > or 64bit mode? or the chip can automatically enter > proper mode when it fetchs an MIPS 32/64 instruction? > > Also, does MIPS 5kc have some 64bit instructions? > > Thanks a lot in advance, > > --Han > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > -- George R. Gensure Computer Science House Member werkt@csh.rit.edu Sophomore, Rochester Institute of Technology Computer Science From owner-linux-mips@oss.sgi.com Fri Oct 26 11:05:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QI5Sb32192 for linux-mips-outgoing; Fri, 26 Oct 2001 11:05:28 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QI5R032189 for ; Fri, 26 Oct 2001 11:05:27 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA12305; Fri, 26 Oct 2001 11:05:17 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA14561; Fri, 26 Oct 2001 11:05:17 -0700 (PDT) Message-ID: <039901c15e48$d45856e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "George Gensure" , "han han" Cc: References: Subject: Re: MIPS 32bit and 64bit mode Date: Fri, 26 Oct 2001 20:05:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 205 Lines: 9 > is the 5kc the same processor as the r5k? If by "r5k" you mean the R5000(tm), no it isn't. The MIPS 5Kc(tm) is a newer syntesizable 64-bit MIPS CPU core from MIPS Technologies. Kevin K. From owner-linux-mips@oss.sgi.com Fri Oct 26 11:07:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QI77g32274 for linux-mips-outgoing; Fri, 26 Oct 2001 11:07:07 -0700 Received: from pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QI73032271 for ; Fri, 26 Oct 2001 11:07:03 -0700 Received: from adsl.pacbell.net ([63.194.214.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GLT003MSRN6KC@mta7.pltn13.pbi.net> for linux-mips@oss.sgi.com; Fri, 26 Oct 2001 11:07:01 -0700 (PDT) Date: Fri, 26 Oct 2001 11:05:42 -0700 From: Pete Popov Subject: Re: Backspace on Virtual Console causes oops In-reply-to: <20011026161259.54925.qmail@web11908.mail.yahoo.com> To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Message-id: <1004119562.14540.3.camel@adsl.pacbell.net> MIME-version: 1.0 X-Mailer: Evolution/0.16.99+cvs.2001.10.22.19.12 (Preview Release) Content-type: text/plain Content-transfer-encoding: 7bit References: <20011026161259.54925.qmail@web11908.mail.yahoo.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1263 Lines: 41 On Fri, 2001-10-26 at 09:12, Wayne Gowcher wrote: > Dear All, > > I am having a problem with the backspace key on a > virtual terminal on a 2.4.2 kernel. If I hit backspace > when there is input at the command line - no problem > it deletes the character before the cursor. > But if I press backspace when there are no characters > at the command prompt, the kernel throws an oops. The > process causing the oops is Bash. > Note, on the Serial console, backspace works fine all > the time. I'll make a guess. With no input at the line, when you hit backspace, the shell is probably generating a beep. Your kernel is not handling that. I don't remember exactly where the "beep code" was but you can probably find it pretty quickly. Pete > > Has anyone ever seen anything like this ? If you have > how did you solve it ? > > Does anyone know the program flow / program details of > what happens when backspace is pressed eg : > > Key In > Key passed to Routine X > Routine X > passes it to Routine Y etc > Bash receives key. > > Or could someone point me to a doc that may explain > this ? > > Thx > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com From owner-linux-mips@oss.sgi.com Fri Oct 26 11:12:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QIC0b01302 for linux-mips-outgoing; Fri, 26 Oct 2001 11:12:00 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QIBx001299 for ; Fri, 26 Oct 2001 11:11:59 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9QIBJE0008908; Fri, 26 Oct 2001 11:11:19 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9QIBGFL008904; Fri, 26 Oct 2001 11:11:19 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 26 Oct 2001 11:11:16 -0700 (PDT) From: James Simmons To: Pete Popov cc: Wayne Gowcher , linux-mips@oss.sgi.com Subject: Re: Backspace on Virtual Console causes oops In-Reply-To: <1004119562.14540.3.camel@adsl.pacbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 330 Lines: 11 > I'll make a guess. With no input at the line, when you hit backspace, > the shell is probably generating a beep. Your kernel is not handling > that. I don't remember exactly where the "beep code" was but you can > probably find it pretty quickly. linux/drivers/char/vt.c. It is the functions kd_nosound and _kd_mksound. From owner-linux-mips@oss.sgi.com Fri Oct 26 11:37:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QIbsv02302 for linux-mips-outgoing; Fri, 26 Oct 2001 11:37:54 -0700 Received: from web11906.mail.yahoo.com (web11906.mail.yahoo.com [216.136.172.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QIbp002299 for ; Fri, 26 Oct 2001 11:37:51 -0700 Message-ID: <20011026183751.15156.qmail@web11906.mail.yahoo.com> Received: from [209.243.184.191] by web11906.mail.yahoo.com via HTTP; Fri, 26 Oct 2001 11:37:51 PDT Date: Fri, 26 Oct 2001 11:37:51 -0700 (PDT) From: Wayne Gowcher Subject: Re: Backspace on Virtual Console causes oops To: "Gleb O. Raiko" Cc: linux-mips@oss.sgi.com In-Reply-To: <3BD99DAC.EB762713@niisi.msk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 989 Lines: 34 Gleb, > Guess 1: You've got PC UARTs and > drivers/char/serial.c > Guess 2: TAB TAB in bash causes the oops too. > Guess 3: You didn't change famous beep function in > the driver. Correct on all 3 counts. Thanks for pointing the way. Also thanks to Pete Popov and James Simmons. In particular to James for telling me to look at vt.c, functions kd_nosound and _kd_mksound. I changed the ifdef to be aware of my board and now the problem is solved. To All, I am grateful that my problem was solved quickly. But before I posted to the list I did a search on "Backspace oops linux", "Backspace crash linux" and a few other combinations to see if this was possibly a known problem. But turned nothing up. Is there any other list / repository I should be looking at to pick up on bugs like this ? Any tips / info would be greatly appreciated. Wayne __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-linux-mips@oss.sgi.com Fri Oct 26 11:54:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QIswS03351 for linux-mips-outgoing; Fri, 26 Oct 2001 11:54:58 -0700 Received: from web10804.mail.yahoo.com (web10804.mail.yahoo.com [216.136.130.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QIsr003347 for ; Fri, 26 Oct 2001 11:54:53 -0700 Message-ID: <20011026185452.88972.qmail@web10804.mail.yahoo.com> Received: from [12.146.133.130] by web10804.mail.yahoo.com via HTTP; Fri, 26 Oct 2001 11:54:52 PDT Date: Fri, 26 Oct 2001 11:54:52 -0700 (PDT) From: han han Subject: Re: MIPS 32bit and 64bit mode To: "Kevin D. Kissell" , linux-mips@oss.sgi.com In-Reply-To: <038401c15e47$50331ae0$0deca8c0@Ulysses> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1801 Lines: 59 --- "Kevin D. Kissell" wrote: > > Does Anybody help me to clear some concepts about > MIPS > > 5kc? > > How to detect and set a MIPS 5kc chip working in > 32bit > > or 64bit mode? or the chip can automatically enter > > proper mode when it fetchs an MIPS 32/64 > instruction? > > > > Also, does MIPS 5kc have some 64bit instructions? > > I guess somebody (probably me) need to write a > MIPS32/MIPS64 FAQ one of these days. > > To answer your last question first, yes, the MIPS5Kc > has the full compliment of 64-bit integer > instructions. > It does not have the integrated FPU of the 5Kf, > however, > so you have neither 32-bit nor 64-bit FP > instructions. > > There are two kinds of "64-bit-ness" to consider: > 64-bit data types and 64-bit addresses. In kernel > mode, a MIPS64 CPU always has access to 64-bit > data types, but to have 64-bit instructions in user > mode, one needs to explicitly enable them in the > CP0.Status register. But, how does MIPS 5kc work with 32bit Linux kernel? Do you means there is no difference between 32 bit mode and 64 bit mode for MIPS 5kc in kernel mode? > > In pre-MIPS64 64-bit MIPS CPUs such as the > R4000 and R5000, user mode access to 64-bit > data types was only possible if 64-bit addressing > was also enabled for user mode by setting the > CP0.Status.UX bit. Kernel mode 64-bit addressing > is independently enabled by setting the > CP0.Status.KX > bit. In MIPS64 (e.g. the 5Kc), it is also possible > to enable > 64-bit data types in user mode *without* 64-bit > addressing > by setting the CP0.Status.PX bit (bit 23). > > Regards, > > Kevin K. > __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-linux-mips@oss.sgi.com Fri Oct 26 12:43:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QJhF905795 for linux-mips-outgoing; Fri, 26 Oct 2001 12:43:15 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QJhC005789 for ; Fri, 26 Oct 2001 12:43:12 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id MAA13429; Fri, 26 Oct 2001 12:43:02 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id MAA16769; Fri, 26 Oct 2001 12:43:03 -0700 (PDT) Message-ID: <03d201c15e56$7c26cac0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "han han" , References: <20011026185452.88972.qmail@web10804.mail.yahoo.com> Subject: Re: MIPS 32bit and 64bit mode Date: Fri, 26 Oct 2001 21:42:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1079 Lines: 26 > But, how does MIPS 5kc work with 32bit Linux kernel? If the KX, UX, and PX bits of the CP0 Status register are all zero, a MIPS5Kc is essentaillly functioning as a 32-bit CPU. The registers are still 64 bits, and arithmetic operations will cause all 64 bits of the destination to be written, but this is outside of the "event horizon" of the program so long as 64-bit data and addressing is not enabled. The 64-bit 5Kc can, and does, boot the same Linux kernel as the 32-bit 4Kc. MIPS64 is a strict superset of MIPS32. > Do you means there is no difference between 32 bit > mode and 64 bit mode for MIPS 5kc in kernel mode? There is no such thing as "32-bit mode" and "64-bit mode", not really. There are 64-bit data-type instructions (e.g. "LD", "DADD") and, logically independently, there is 64-bit addressing for loads and stores - which includes LW and LB as well as LD. 64-bit data is always enabled in kernel mode on a MIPS64 part. For 64-bit data in User mode, and for 64-bit addressing in *either* mode, there are explicit enables. Kevin K. From owner-linux-mips@oss.sgi.com Fri Oct 26 13:13:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QKDmd07273 for linux-mips-outgoing; Fri, 26 Oct 2001 13:13:48 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QKDb007270; Fri, 26 Oct 2001 13:13:37 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9QKDWE0015352; Fri, 26 Oct 2001 13:13:32 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9QKDWFg015348; Fri, 26 Oct 2001 13:13:32 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 26 Oct 2001 13:13:32 -0700 (PDT) From: James Simmons To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] exporting PCI dma functions. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 978 Lines: 33 Several drivers that can be modularcall the functions in pci-dma.c in arch/mips/kernel. The following patch exports these functions so the modules don't fail. --- Makefile.orig Fri Oct 26 13:08:58 2001 +++ Makefile Fri Oct 26 13:09:24 2001 @@ -57,6 +57,7 @@ obj-$(CONFIG_BINFMT_IRIX) += irixelf.o irixioctl.o irixsig.o sysirix.o \ irixinv.o obj-$(CONFIG_REMOTE_DEBUG) += gdb-low.o gdb-stub.o +export-objs += pci-dma.o obj-$(CONFIG_PCI) += pci-dma.o obj-$(CONFIG_PROC_FS) += proc.o --- pci-dma.c Mon Jun 25 12:09:29 2001 +++ /tmp/linux-mips/arch/mips/kernel/pci-dma.c Fri Oct 26 12:57:32 2001 @@ -8,6 +8,7 @@ * swiped from i386, and cloned for MIPS by Geert, polished by Ralf. */ #include +#include #include #include #include @@ -47,3 +48,6 @@ #endif free_pages(addr, get_order(size)); } + +EXPORT_SYMBOL(pci_alloc_consistent); +EXPORT_SYMBOL(pci_free_consistent); From owner-linux-mips@oss.sgi.com Fri Oct 26 14:58:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QLwlr11659 for linux-mips-outgoing; Fri, 26 Oct 2001 14:58:47 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QLwj011654 for ; Fri, 26 Oct 2001 14:58:45 -0700 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9QM0gB22265 for ; Fri, 26 Oct 2001 15:00:42 -0700 Subject: rm7k From: Pete Popov To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15.99+cvs.2001.10.09.08.08 (Preview Release) Date: 26 Oct 2001 15:00:53 -0700 Message-Id: <1004133653.7556.11.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 531 Lines: 20 Ralf, tlb-r4k.c is used for the rm7k, but this piece in probe_tlb() fails: if (!(config & (1 << 31))) /* * Not a MIPS32 complianant CPU. Config 1 register not * supported, we assume R4k style. Cpu probing already figured * out the number of tlb entries. */ return; Bit 31 on the rm7k indicates whether or not scache is present. If scache is not present (disabled), the above test passes and we end up reading config1, which doesn't exist, so we setup the tlbsize to a bogus value. Pete From owner-linux-mips@oss.sgi.com Fri Oct 26 15:14:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QME5U12281 for linux-mips-outgoing; Fri, 26 Oct 2001 15:14:05 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QMDq012275; Fri, 26 Oct 2001 15:13:53 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA18068; Fri, 26 Oct 2001 18:13:24 -0400 Date: Fri, 26 Oct 2001 18:13:24 -0400 (EDT) From: X-Sender: nick@ns To: Lukas Hejtmanek cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Origin 200 In-Reply-To: <20011026163117.B27258@mail.muni.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f9QMDu012277 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 726 Lines: 21 That was the same "fix" I came across. I'm still not sure why though. Nick On Fri, 26 Oct 2001, Lukas Hejtmanek wrote: > On Thu, Oct 25, 2001 at 12:14:50PM +0200, Ralf Baechle wrote: > > Btw, Origin UP kernel is definately broken ... > > I think I've tracked down what makes freeze. If I use default config but > network card driver and scsi driver (seems to be generic PCI device) kernel > boots up to message I have no root (any time and not freezes I've changed little > bit sources to print '... waiting ...' every 2 seconds in infinite loop before > it does panic -- no root). > > So I think there is some deadlock after some PCI device driver init that does > not occur in SMP mode. > > -- > Lukáš Hejtmánek > From owner-linux-mips@oss.sgi.com Fri Oct 26 16:07:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QN7Mk15906 for linux-mips-outgoing; Fri, 26 Oct 2001 16:07:22 -0700 Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QN7F015902; Fri, 26 Oct 2001 16:07:15 -0700 Received: (from xhejtman@localhost) by hell.ascs.muni.cz (8.11.6/8.11.6) id f9QN9w906252; Sat, 27 Oct 2001 01:09:58 +0200 Date: Sat, 27 Oct 2001 01:09:58 +0200 From: Lukas Hejtmanek To: nick@snowman.net Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Origin 200 Message-ID: <20011027010958.B24376@mail.muni.cz> References: <20011026163117.B27258@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@snowman.net on Fri, Oct 26, 2001 at 06:13:24PM -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by hell.ascs.muni.cz id f9QN9w906252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f9QN7G015903 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 325 Lines: 9 On Fri, Oct 26, 2001 at 06:13:24PM -0400, nick@snowman.net wrote: > That was the same "fix" I came across. I'm still not sure why though. However it should be found with gdb but I don't know how to setup remote debugging, gdb always writes that it is unable to connect. Is there any remote gdb how-to? -- Lukáš Hejtmánek From owner-linux-mips@oss.sgi.com Fri Oct 26 17:34:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9R0Y7G18984 for linux-mips-outgoing; Fri, 26 Oct 2001 17:34:07 -0700 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9R0Y3018981 for ; Fri, 26 Oct 2001 17:34:04 -0700 Received: (qmail 11674 invoked from network); 27 Oct 2001 00:34:01 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 27 Oct 2001 00:34:01 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id ECD68300095; Sat, 27 Oct 2001 10:34:00 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D83D398 for ; Sat, 27 Oct 2001 10:34:00 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-mips@oss.sgi.com Subject: Re: [PATCH] exporting PCI dma functions. In-reply-to: Your message of "Fri, 26 Oct 2001 13:13:32 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Oct 2001 10:33:55 +1000 Message-ID: <12047.1004142835@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 543 Lines: 15 On Fri, 26 Oct 2001 13:13:32 -0700 (PDT), James Simmons wrote: >--- Makefile.orig Fri Oct 26 13:08:58 2001 >+++ Makefile Fri Oct 26 13:09:24 2001 >@@ -57,6 +57,7 @@ > obj-$(CONFIG_BINFMT_IRIX) += irixelf.o irixioctl.o irixsig.o sysirix.o \ > irixinv.o > obj-$(CONFIG_REMOTE_DEBUG) += gdb-low.o gdb-stub.o >+export-objs += pci-dma.o > obj-$(CONFIG_PCI) += pci-dma.o > obj-$(CONFIG_PROC_FS) += proc.o export-objs should go at the start of the Makefile, that is the standard coding style for Makefiles. From owner-linux-mips@oss.sgi.com Fri Oct 26 18:08:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9R18fx19515 for linux-mips-outgoing; Fri, 26 Oct 2001 18:08:41 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9R183019503 for ; Fri, 26 Oct 2001 18:08:04 -0700 Received: from dev1 (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with ESMTP id 2A587590A9; Fri, 26 Oct 2001 17:05:11 -0400 (EDT) Received: from brad by dev1 with local (Exim 3.32 #1 (Debian)) id 15xHww-0005J1-00; Fri, 26 Oct 2001 21:07:46 -0400 Date: Fri, 26 Oct 2001 21:07:46 -0400 To: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: PATCH: pci_auto bridge support Message-ID: <20011026210746.A20395@dev1.ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i From: "Bradley D. LaRonde" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 14963 Lines: 437 2001-10-26 Bradley D. LaRonde * PCI bridge support. See change log entry below. --- arch/mips/kernel/pci_auto.c 2001/08/18 06:21:53 1.1 +++ arch/mips/kernel/pci_auto.c 2001/10/27 01:01:21 @@ -4,6 +4,7 @@ * Author: Matt Porter * * Copyright 2000, 2001 MontaVista Software Inc. + * Copyright 2001 Bradley D. LaRonde * * 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 @@ -19,6 +20,15 @@ * . change most int to u32. * * Further modified to include it as mips generic code, ppopov@mvista.com. + * + * 2001-10-26 Bradley D. LaRonde + * - Add a top_bus argument to the "early config" functions so that + * they can set a fake parent bus pointer to convince the underlying + * pci ops to use type 1 configuration for sub busses. + * - Set bridge base and limit registers correctly. + * - Align io and memory base properly before and after bridge setup. + * - Don't fall through to pci_setup_bars for bridge. + * - Reformat the debug output to look more like lspci's output. */ #include @@ -34,14 +44,47 @@ #else #define DBG(x...) #endif + +/* + * These functions are used early on before PCI scanning is done + * and all of the pci_dev and pci_bus structures have been created. + */ +static struct pci_dev *fake_pci_dev(struct pci_channel *hose, + int top_bus, int busnr, int devfn) +{ + static struct pci_dev dev; + static struct pci_bus bus; + + dev.bus = &bus; + dev.sysdata = hose; + dev.devfn = devfn; + bus.number = busnr; + bus.ops = hose->pci_ops; + + if(busnr != top_bus) + /* Fake a parent bus structure. */ + bus.parent = &bus; + else + bus.parent = NULL; + + return &dev; +} + +#define EARLY_PCI_OP(rw, size, type) \ +int early_##rw##_config_##size(struct pci_channel *hose, \ + int top_bus, int bus, int devfn, int offset, type value) \ +{ \ + return pci_##rw##_config_##size( \ + fake_pci_dev(hose, top_bus, bus, devfn), \ + offset, value); \ +} -/* These are used for config access before all the PCI probing has been done. */ -int early_read_config_byte(struct pci_channel *hose, int bus, int dev_fn, int where, u8 *val); -int early_read_config_word(struct pci_channel *hose, int bus, int dev_fn, int where, u16 *val); -int early_read_config_dword(struct pci_channel *hose, int bus, int dev_fn, int where, u32 *val); -int early_write_config_byte(struct pci_channel *hose, int bus, int dev_fn, int where, u8 val); -int early_write_config_word(struct pci_channel *hose, int bus, int dev_fn, int where, u16 val); -int early_write_config_dword(struct pci_channel *hose, int bus, int dev_fn, int where, u32 val); +EARLY_PCI_OP(read, byte, u8 *) +EARLY_PCI_OP(read, word, u16 *) +EARLY_PCI_OP(read, dword, u32 *) +EARLY_PCI_OP(write, byte, u8) +EARLY_PCI_OP(write, word, u16) +EARLY_PCI_OP(write, dword, u32) static u32 pciauto_lower_iospc; static u32 pciauto_upper_iospc; @@ -51,6 +94,7 @@ void __init pciauto_setup_bars(struct pci_channel *hose, + int top_bus, int current_bus, int pci_devfn) { @@ -60,17 +104,14 @@ u32 * lower_limit; int found_mem64 = 0; - DBG("PCI Autoconfig: Found Bus %d, Device %d, Function %d\n", - current_bus, PCI_SLOT(pci_devfn), PCI_FUNC(pci_devfn) ); - for (bar = PCI_BASE_ADDRESS_0; bar <= PCI_BASE_ADDRESS_5; bar+=4) { /* Tickle the BAR and get the response */ - early_write_config_dword(hose, + early_write_config_dword(hose, top_bus, current_bus, pci_devfn, bar, 0xffffffff); - early_read_config_dword(hose, + early_read_config_dword(hose, top_bus, current_bus, pci_devfn, bar, @@ -80,12 +121,20 @@ if (!bar_response) continue; + /* + * Workaround for a BAR that doesn't use its upper word, + * like the ALi 1535D+ PCI DC-97 Controller Modem (M5457). + * bdl + */ + if (!(bar_response & 0xffff0000)) + bar_response |= 0xffff0000; + /* Check the BAR type and set our address mask */ if (bar_response & PCI_BASE_ADDRESS_SPACE) { addr_mask = PCI_BASE_ADDRESS_IO_MASK; upper_limit = &pciauto_upper_iospc; lower_limit = &pciauto_lower_iospc; - DBG("PCI Autoconfig: BAR %d, I/O, ", bar_nr); + DBG(" I/O"); } else { if ((bar_response & PCI_BASE_ADDRESS_MEM_TYPE_MASK) == PCI_BASE_ADDRESS_MEM_TYPE_64) @@ -94,7 +143,7 @@ addr_mask = PCI_BASE_ADDRESS_MEM_MASK; upper_limit = &pciauto_upper_memspc; lower_limit = &pciauto_lower_memspc; - DBG("PCI Autoconfig: BAR %d, Mem, ", bar_nr); + DBG(" Mem"); } /* Calculate requested size */ @@ -104,7 +153,7 @@ bar_value = ((*lower_limit - 1) & ~(bar_size - 1)) + bar_size; /* Write it out and update our limit */ - early_write_config_dword(hose, current_bus, pci_devfn, + early_write_config_dword(hose, top_bus, current_bus, pci_devfn, bar, bar_value); *lower_limit = bar_value + bar_size; @@ -116,97 +165,99 @@ */ if (found_mem64) { bar += 4; - early_write_config_dword(hose, + early_write_config_dword(hose, top_bus, current_bus, pci_devfn, bar, 0x00000000); } - bar_nr++; + DBG(" at 0x%.8x [size=0x%x]\n", bar_value, bar_size); - DBG("size=0x%x, address=0x%x\n", - bar_size, bar_value); + bar_nr++; } } void __init pciauto_prescan_setup_bridge(struct pci_channel *hose, + int top_bus, int current_bus, int pci_devfn, int sub_bus) { - int cmdstat; - /* Configure bus number registers */ - early_write_config_byte(hose, current_bus, pci_devfn, + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, PCI_PRIMARY_BUS, current_bus); - early_write_config_byte(hose, current_bus, pci_devfn, + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, PCI_SECONDARY_BUS, sub_bus + 1); - early_write_config_byte(hose, current_bus, pci_devfn, + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, PCI_SUBORDINATE_BUS, 0xff); - - /* Round memory allocator to 1MB boundary */ - pciauto_upper_memspc &= ~(0x100000 - 1); - /* Round I/O allocator to 4KB boundary */ - pciauto_upper_iospc &= ~(0x1000 - 1); + /* Align memory and I/O to 1MB and 4KB boundaries. */ + pciauto_lower_memspc = (pciauto_lower_memspc + (0x100000 - 1)) + & ~(0x100000 - 1); + pciauto_lower_iospc = (pciauto_lower_iospc + (0x1000 - 1)) + & ~(0x1000 - 1); + + /* Set base (lower limit) of address range behind bridge. */ + early_write_config_word(hose, top_bus, current_bus, pci_devfn, + PCI_MEMORY_BASE, pciauto_lower_memspc >> 16); + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, + PCI_IO_BASE, (pciauto_lower_iospc & 0x0000f000) >> 8); + early_write_config_word(hose, top_bus, current_bus, pci_devfn, + PCI_IO_BASE_UPPER16, pciauto_lower_iospc >> 16); - /* Set up memory and I/O filter limits, assume 32-bit I/O space */ - early_write_config_word(hose, current_bus, pci_devfn, PCI_MEMORY_LIMIT, - ((pciauto_upper_memspc - 1) & 0xfff00000) >> 16); - early_write_config_byte(hose, current_bus, pci_devfn, PCI_IO_LIMIT, - ((pciauto_upper_iospc - 1) & 0x0000f000) >> 8); - early_write_config_word(hose, current_bus, pci_devfn, - PCI_IO_LIMIT_UPPER16, - ((pciauto_upper_iospc - 1) & 0xffff0000) >> 16); - /* We don't support prefetchable memory for now, so disable */ - early_write_config_word(hose, current_bus, pci_devfn, - PCI_PREF_MEMORY_BASE, 0x1000); - early_write_config_word(hose, current_bus, pci_devfn, - PCI_PREF_MEMORY_LIMIT, 0x1000); - - /* Enable memory and I/O accesses, enable bus master */ - early_read_config_dword(hose, current_bus, pci_devfn, PCI_COMMAND, - &cmdstat); - early_write_config_dword(hose, current_bus, pci_devfn, PCI_COMMAND, - cmdstat | PCI_COMMAND_IO | PCI_COMMAND_MEMORY | - PCI_COMMAND_MASTER); + early_write_config_word(hose, top_bus, current_bus, pci_devfn, + PCI_PREF_MEMORY_BASE, 0); + early_write_config_word(hose, top_bus, current_bus, pci_devfn, + PCI_PREF_MEMORY_LIMIT, 0); } void __init pciauto_postscan_setup_bridge(struct pci_channel *hose, + int top_bus, int current_bus, int pci_devfn, int sub_bus) { + u32 temp; + /* Configure bus number registers */ - early_write_config_byte(hose, current_bus, pci_devfn, + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, PCI_SUBORDINATE_BUS, sub_bus); - /* Round memory allocator to 1MB boundary */ - pciauto_upper_memspc &= ~(0x100000 - 1); - early_write_config_word(hose, current_bus, pci_devfn, PCI_MEMORY_BASE, - pciauto_upper_memspc >> 16); - - /* Round I/O allocator to 4KB boundary */ - pciauto_upper_iospc &= ~(0x1000 - 1); - early_write_config_byte(hose, current_bus, pci_devfn, PCI_IO_BASE, - (pciauto_upper_iospc & 0x0000f000) >> 8); - early_write_config_word(hose, current_bus, pci_devfn, - PCI_IO_BASE_UPPER16, pciauto_upper_iospc >> 16); + /* Set upper limit of address range behind bridge. */ + early_write_config_word(hose, top_bus, current_bus, pci_devfn, + PCI_MEMORY_LIMIT, pciauto_lower_memspc >> 16); + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, + PCI_IO_LIMIT, (pciauto_lower_iospc & 0x0000f000) >> 8); + early_write_config_word(hose, top_bus, current_bus, pci_devfn, + PCI_IO_LIMIT_UPPER16, pciauto_lower_iospc >> 16); + + /* Align memory and I/O to 1MB and 4KB boundaries. */ + pciauto_lower_memspc = (pciauto_lower_memspc + (0x100000 - 1)) + & ~(0x100000 - 1); + pciauto_lower_iospc = (pciauto_lower_iospc + (0x1000 - 1)) + & ~(0x1000 - 1); + + /* Enable memory and I/O accesses, enable bus master */ + early_read_config_dword(hose, top_bus, current_bus, pci_devfn, + PCI_COMMAND, &temp); + early_write_config_dword(hose, top_bus, current_bus, pci_devfn, + PCI_COMMAND, temp | PCI_COMMAND_IO | PCI_COMMAND_MEMORY + | PCI_COMMAND_MASTER); } #define PCIAUTO_IDE_MODE_MASK 0x05 int __init -pciauto_bus_scan(struct pci_channel *hose, int current_bus) +pciauto_bus_scan(struct pci_channel *hose, int top_bus, int current_bus) { int sub_bus; u32 pci_devfn, pci_class, cmdstat, found_multi=0; - unsigned short vid; + unsigned short vid, did; unsigned char header_type; int devfn_start = 0; int devfn_stop = 0xff; @@ -223,54 +274,70 @@ if (PCI_FUNC(pci_devfn) && !found_multi) continue; - early_read_config_byte(hose, current_bus, pci_devfn, + early_read_config_word(hose, top_bus, current_bus, pci_devfn, + PCI_VENDOR_ID, &vid); + + if (vid == 0xffff) continue; + + early_read_config_byte(hose, top_bus, current_bus, pci_devfn, PCI_HEADER_TYPE, &header_type); if (!PCI_FUNC(pci_devfn)) found_multi = header_type & 0x80; - early_read_config_word(hose, current_bus, pci_devfn, - PCI_VENDOR_ID, &vid); + early_read_config_word(hose, top_bus, current_bus, pci_devfn, + PCI_DEVICE_ID, &did); - if (vid == 0xffff) continue; - - early_read_config_dword(hose, current_bus, pci_devfn, + early_read_config_dword(hose, top_bus, current_bus, pci_devfn, PCI_CLASS_REVISION, &pci_class); + + DBG("%.2x:%.2x.%x Class %.4x: %.4x:%.4x", + current_bus, PCI_SLOT(pci_devfn), PCI_FUNC(pci_devfn), + pci_class >> 16, vid, did); + if (pci_class & 0xff) + DBG(" (rev %.2x)", pci_class & 0xff); + DBG("\n"); + if ((pci_class >> 16) == PCI_CLASS_BRIDGE_PCI) { - DBG("PCI Autoconfig: Found P2P bridge, device %d\n", PCI_SLOT(pci_devfn)); - pciauto_prescan_setup_bridge(hose, current_bus, + DBG(" Bridge: primary=%.2x, secondary=%.2x\n", + current_bus, sub_bus + 1); + pciauto_prescan_setup_bridge(hose, top_bus, current_bus, pci_devfn, sub_bus); - sub_bus = pciauto_bus_scan(hose, sub_bus+1); - pciauto_postscan_setup_bridge(hose, current_bus, + DBG("Scanning sub bus %.2x, I/O 0x%.8x, Mem 0x%.8x\n", + sub_bus + 1, + pciauto_lower_iospc, pciauto_lower_memspc); + sub_bus = pciauto_bus_scan(hose, top_bus, sub_bus+1); + DBG("Back to bus %.2x\n", current_bus); + pciauto_postscan_setup_bridge(hose, top_bus, current_bus, pci_devfn, sub_bus); - + continue; } else if ((pci_class >> 16) == PCI_CLASS_STORAGE_IDE) { unsigned char prg_iface; - early_read_config_byte(hose, current_bus, pci_devfn, - PCI_CLASS_PROG, &prg_iface); + early_read_config_byte(hose, top_bus, current_bus, + pci_devfn, PCI_CLASS_PROG, &prg_iface); if (!(prg_iface & PCIAUTO_IDE_MODE_MASK)) { - DBG("PCI Autoconfig: Skipping legacy mode IDE controller\n"); + DBG("Skipping legacy mode IDE controller\n"); continue; } } - /* + /* * Found a peripheral, enable some standard * settings */ - early_read_config_dword(hose, current_bus, pci_devfn, + early_read_config_dword(hose, top_bus, current_bus, pci_devfn, PCI_COMMAND, &cmdstat); - early_write_config_dword(hose, current_bus, pci_devfn, + early_write_config_dword(hose, top_bus, current_bus, pci_devfn, PCI_COMMAND, cmdstat | PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - early_write_config_byte(hose, current_bus, pci_devfn, + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, PCI_LATENCY_TIMER, 0x80); /* Allocate PCI I/O and/or memory space */ - pciauto_setup_bars(hose, current_bus, pci_devfn); + pciauto_setup_bars(hose, top_bus, current_bus, pci_devfn); } return sub_bus; } @@ -283,41 +350,9 @@ pciauto_upper_iospc = hose->io_resource->end + 1; pciauto_lower_memspc = hose->mem_resource->start; pciauto_upper_memspc = hose->mem_resource->end + 1; + DBG("Autoconfig PCI channel 0x%p\n", hose); + DBG("Scanning bus %.2x, I/O 0x%.8x, Mem 0x%.8x\n", + busno, pciauto_lower_iospc, pciauto_lower_memspc); - return pciauto_bus_scan(hose, busno); + return pciauto_bus_scan(hose, busno, busno); } - - -/* - * These functions are used early on before PCI scanning is done - * and all of the pci_dev and pci_bus structures have been created. - */ -static struct pci_dev *fake_pci_dev(struct pci_channel *hose, int busnr, - int devfn) -{ - static struct pci_dev dev; - static struct pci_bus bus; - - dev.bus = &bus; - dev.sysdata = hose; - dev.devfn = devfn; - bus.number = busnr; - bus.ops = hose->pci_ops; - - return &dev; -} - -#define EARLY_PCI_OP(rw, size, type) \ -int early_##rw##_config_##size(struct pci_channel *hose, int bus, \ - int devfn, int offset, type value) \ -{ \ - return pci_##rw##_config_##size(fake_pci_dev(hose, bus, devfn), \ - offset, value); \ -} - -EARLY_PCI_OP(read, byte, u8 *) -EARLY_PCI_OP(read, word, u16 *) -EARLY_PCI_OP(read, dword, u32 *) -EARLY_PCI_OP(write, byte, u8) -EARLY_PCI_OP(write, word, u16) -EARLY_PCI_OP(write, dword, u32) From owner-linux-mips@oss.sgi.com Fri Oct 26 21:10:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9R4A7o26382 for linux-mips-outgoing; Fri, 26 Oct 2001 21:10:07 -0700 Received: from dea.linux-mips.net (a1as06-p216.stg.tli.de [195.252.187.216]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9R49x026365 for ; Fri, 26 Oct 2001 21:10:00 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9R49tI24164 for linux-mips@oss.sgi.com; Sat, 27 Oct 2001 06:09:55 +0200 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QDrJ007192 for ; Fri, 26 Oct 2001 06:53:20 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 26 Oct 2001 13:53:19 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id E5681B485; Fri, 26 Oct 2001 22:53:17 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id WAA24731; Fri, 26 Oct 2001 22:53:17 +0900 (JST) Date: Fri, 26 Oct 2001 22:58:06 +0900 (JST) Message-Id: <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> To: ajob4me@21cn.com Cc: linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. From: Atsushi Nemoto In-Reply-To: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 458 Lines: 12 >>>>> On Fri, 26 Oct 2001 17:49:26 +0800, 8route said: ajob4me> I'm working on Toshiba TX3927 RISC Processor Reference ajob4me> board.During development I met a problem.Can someone give me ajob4me> some good suggestions? ... ajob4me> and the reset switch on the TX3927 board cann't work anymore. I have seen TX39 dead on "cfc1" insturuction if STATUS.CU1 bit enabled. Such codes were in arch/mips/kernel/process.c. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Sat Oct 27 14:17:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9RLHvj09193 for linux-mips-outgoing; Sat, 27 Oct 2001 14:17:57 -0700 Received: from dea.linux-mips.net (a1as08-p205.stg.tli.de [195.252.188.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9RLHr009190 for ; Sat, 27 Oct 2001 14:17:54 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9RIjSd28039; Sat, 27 Oct 2001 20:45:28 +0200 Date: Sat, 27 Oct 2001 20:45:28 +0200 From: Ralf Baechle To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Kernel 2.4.3 compile problem Message-ID: <20011027204528.C26218@dea.linux-mips.net> References: <86048F07C015D311864100902760F1DD01B5E29B@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DD01B5E29B@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Fri, Oct 26, 2001 at 01:36:25PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 338 Lines: 10 On Fri, Oct 26, 2001 at 01:36:25PM +0200, Andre.Messerschmidt@infineon.com wrote: > /usr/lib/gcc-lib/mips-linux/egcs-2.91.66/include/va-mips.h:278: parse error > at null character If this file contains a NUL character your compiler installation got corrupted somehow. Say might also be memory corruption of your compiler host. Ralf From owner-linux-mips@oss.sgi.com Sat Oct 27 16:34:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9RNYPB10919 for linux-mips-outgoing; Sat, 27 Oct 2001 16:34:25 -0700 Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9RNXw010915 for ; Sat, 27 Oct 2001 16:33:58 -0700 Received: (qmail 26326 invoked from network); 27 Oct 2001 23:33:56 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by crack-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 27 Oct 2001 23:33:56 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 15xcxX-0007LK-00 for ; Sat, 27 Oct 2001 17:33:47 -0600 Date: Sat, 27 Oct 2001 17:33:47 -0600 (MDT) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com Reply-To: Jason Gunthorpe To: linux-mips@oss.sgi.com Subject: [PATCH] RM7k cache initialization Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10115 Lines: 315 Hi, I've been fiddling around with getting Linux from SGI CVS booting on my RM7000 box, with lots of good luck! I did find one notable bug, the code in c-rm7k.c to initialize the caches isn't correct. My board boots in a manner that tends to expose cache flushing bugs so I actually hit this.. The patch below fixes it up. The notable changes are: - Cache sizes are #defined and verifed against the CPU registers. This is to help ensure that gcc doesn't start touching memory it shouldn't - There is a single cache init function that does the ICache, DCache, SCache and TCache all in one go. - The code to fix up the ICache was corrected to run with caches turned on and to load data that is definately 0 (required according to PMC) - TCache initialization is done if the cache is marked enabled when ld_mmu_rm7k is called. I expect prom_init functions to enable any HW support, disable KSEG0 caching and enable the tcache bit. The size of the cache is assumed to be the max the chip can support. I've only tested this on a custom RM7000A board with a wack of tertiary cache, but I don't see any reason it shouldn't work generally.. Thanks, Jason Index: c-rm7k.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-rm7k.c,v retrieving revision 1.2 diff -u -r1.2 c-rm7k.c --- c-rm7k.c 2001/10/26 22:33:14 1.2 +++ c-rm7k.c 2001/10/27 22:47:10 @@ -33,7 +33,9 @@ ".set reorder\n\t") /* Primary cache parameters. */ -static int icache_size, dcache_size; /* Size in bytes */ +#define icache_size (16*1024) /* Fixed to 16KiB on RM7000 */ +#define dcache_size (16*1024) /* Fixed to 16KiB on RM7000 */ +#define tcache_size (8*1024*1024) /* 8 Meg max on RM7000 */ #define ic_lsize 32 /* Fixed to 32 byte on RM7000 */ #define dc_lsize 32 /* Fixed to 32 byte on RM7000 */ @@ -52,7 +54,8 @@ * Not added to asm/r4kcache.h because it seems to be RM7000-specific. */ #define Page_Invalidate_T 0x16 - +#define Index_Store_Tag_S 0x0B +#define Index_Store_Tag_T 0x0A static inline void invalidate_tcache_page(unsigned long addr) { __asm__ __volatile__( @@ -195,76 +198,139 @@ protected_flush_icache_line(addr & ~(ic_lsize - 1)); } -/* Detect and size the caches. */ -static inline void probe_icache(unsigned long config) -{ - icache_size = 1 << (12 + ((config >> 9) & 7)); - - printk(KERN_INFO "Primary instruction cache %dKiB.\n", icache_size >> 10); -} - -static inline void probe_dcache(unsigned long config) -{ - dcache_size = 1 << (12 + ((config >> 6) & 7)); - - printk(KERN_INFO "Primary data cache %dKiB.\n", dcache_size >> 10); -} - - /* * This function is executed in the uncached segment KSEG1. * It must not touch the stack, because the stack pointer still points - * into KSEG0. + * into KSEG0. * - * Three options: + * Two options: * - Write it in assembly and guarantee that we don't use the stack. - * - Disable caching for KSEG0 before calling it. * - Pray that GCC doesn't randomly start using the stack. * * This being Linux, we obviously take the least sane of those options - * following DaveM's lead in r4xx0.c * + * Some MIPS proms actually do all of this work for us, so this is harmless + * but redundent. If Linux is booting from flash directly then this code + * is required. All cache initing must be done with the cache enabled or + * it doesn't work right. + * * It seems we get our kicks from relying on unguaranteed behaviour in GCC + * */ -static __init void setup_scache(void) +#define CACHE_OP(op,size,lsize) \ + for (i=0; i> 31) & 1) == 0) + { + // Enable and invalidate + set_cp0_config(1<<3 /* CONF_SE */); + BARRIER; + CACHE_OP(Index_Store_Tag_S,scache_size,sc_lsize); + } + + /* Tertiary cache.. + If the board supports L3 cache then the prom should enable it + but leave caching turned off. When we get here we detect it was + turned on and then do the initialization. Speed isn't important + so we don't worry about flash invalidate */ + if (((config >> 17) & 1) == 0 && + ((config >> 12) & 1) != 0) + { + /* It doesn't actually matter how big the tcache actually is, + this code initializes the largest possible */ + set_cp0_config(1<<12 /* CONF_TE*/); + BARRIER; + CACHE_OP(Page_Invalidate_T,tcache_size,tc_pagesize); + } + + BARRIER; } -static inline void probe_scache(unsigned long config) + +/* Check the Caches are as we expect them to be. The RM7K has a fixed cache + size and we want the cache sizes to be constant for the above evil + routine. These guys print some nice messages to make the user feel warm + and fuzzy */ +static inline void probe_icache(unsigned long config) { - void (*func)(void) = KSEG1ADDR(&setup_scache); + if (icache_size != 1 << (12 + ((config >> 9) & 7))) + panic("RM7000 ICache size mismatch!\n"); + + printk(KERN_INFO "Primary instruction cache %dKiB.\n", icache_size >> 10); +} +static inline void probe_dcache(unsigned long config) +{ + if (dcache_size != 1 << (12 + ((config >> 6) & 7))) + panic("RM7000 DCache size mismatch!\n"); + + printk(KERN_INFO "Primary data cache %dKiB.\n", dcache_size >> 10); +} + +static inline void probe_scache(unsigned long config) +{ if ((config >> 31) & 1) return; printk(KERN_INFO "Secondary cache %dKiB, linesize %d bytes.\n", (scache_size >> 10), sc_lsize); - - if ((config >> 3) & 1) - return; - - printk(KERN_INFO "Enabling secondary cache..."); - func(); - printk("Done\n"); } static inline void probe_tcache(unsigned long config) @@ -274,15 +340,15 @@ /* We can't enable the L3 cache yet. There may be board-specific * magic necessary to turn it on, and blindly asking the CPU to - * start using it would may give cache errors. + * start using it may give cache errors. * * Also, board-specific knowledge may allow us to use the * CACHE Flash_Invalidate_T instruction if the tag RAM supports * it, and may specify the size of the L3 cache so we don't have * to probe it. */ - printk(KERN_INFO "Tertiary cache present, %s enabled\n", - config&(1<<12) ? "already" : "not (yet)"); + printk(KERN_INFO "Tertiary cache present %s\n", + config&(1<<12) ? "- will be used." : " - might be enabled later.."); if ((config >> 12) & 1) rm7k_tcache_enabled = 1; @@ -291,45 +357,26 @@ void __init ld_mmu_rm7k(void) { unsigned long config = read_32bit_cp0_register(CP0_CONFIG); - unsigned long addr; + void (*func)(unsigned long config) = KSEG1ADDR(&clear_enable_caches); printk("CPU revision is: %08x\n", read_32bit_cp0_register(CP0_PRID)); change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); - /* RM7000 erratum #31. The icache is screwed at startup. */ - set_taglo(0); - set_taghi(0); - for (addr = KSEG0; addr <= KSEG0 + 4096; addr += ic_lsize) { - __asm__ __volatile__ ( - ".set noreorder\n\t" - ".set mips3\n\t" - "cache\t%1, 0(%0)\n\t" - "cache\t%1, 0x1000(%0)\n\t" - "cache\t%1, 0x2000(%0)\n\t" - "cache\t%1, 0x3000(%0)\n\t" - "cache\t%2, 0(%0)\n\t" - "cache\t%2, 0x1000(%0)\n\t" - "cache\t%2, 0x2000(%0)\n\t" - "cache\t%2, 0x3000(%0)\n\t" - "cache\t%1, 0(%0)\n\t" - "cache\t%1, 0x1000(%0)\n\t" - "cache\t%1, 0x2000(%0)\n\t" - "cache\t%1, 0x3000(%0)\n\t" - ".set\tmips0\n\t" - ".set\treorder\n\t" - : - : "r" (addr), "i" (Index_Store_Tag_I), "i" (Fill)); - } - -#ifndef CONFIG_MIPS_UNCACHED - change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_NONCOHERENT); -#endif - + // Print out all the status messages and do sanity checks probe_icache(config); probe_dcache(config); probe_scache(config); probe_tcache(config); + + // Call clear_enable_caches in uncached memory + printk(KERN_INFO "Clearing and enabling all caches..."); + func(config); + printk("Done\n"); + +#ifdef CONFIG_MIPS_UNCACHED + change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); +#endif _clear_page = rm7k_clear_page; _copy_page = rm7k_copy_page; From owner-linux-mips@oss.sgi.com Sun Oct 28 12:48:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SKmOa05631 for linux-mips-outgoing; Sun, 28 Oct 2001 12:48:24 -0800 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SKmI005628; Sun, 28 Oct 2001 12:48:18 -0800 Received: from dev1 (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with ESMTP id 15636590B4; Sun, 28 Oct 2001 11:45:15 -0500 (EST) Received: from brad by dev1 with local (Exim 3.32 #1 (Debian)) id 15xwqQ-0002ne-00; Sun, 28 Oct 2001 15:47:46 -0500 Date: Sun, 28 Oct 2001 15:47:46 -0500 To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: PATCH: require dev_id for shared irq Message-ID: <20011028154746.A10762@dev1.ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i From: "Bradley D. LaRonde" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 843 Lines: 29 2001-10-28 Bradley D. LaRonde - Require a dev_id for shared interrupts. --- arch/mips/kernel/irq.c 2001/10/12 01:41:17 1.36 +++ arch/mips/kernel/irq.c 2001/10/28 20:43:19 @@ -350,18 +350,12 @@ int retval; struct irqaction * action; -#if 1 /* - * Sanity-check: shared interrupts should REALLY pass in - * a real dev-ID, otherwise we'll have trouble later trying - * to figure out which interrupt is which (messes up the - * interrupt freeing logic etc). + * Shared interrupts require a dev_id, otherwise we can't + * later figure out which interrupt to free. */ - if (irqflags & SA_SHIRQ) { - if (!dev_id) - printk("Bad boy: %s (at 0x%x) called us without a dev_id!\n", devname, (&irq)[-1]); - } -#endif + if ((irqflags & SA_SHIRQ) && !dev_id) + return -EINVAL; if (irq >= NR_IRQS) return -EINVAL; From owner-linux-mips@oss.sgi.com Sun Oct 28 13:21:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9SLLFg06240 for linux-mips-outgoing; Sun, 28 Oct 2001 13:21:15 -0800 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9SLL5006237; Sun, 28 Oct 2001 13:21:06 -0800 Received: from dev1 (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with ESMTP id D65FB590B4; Sun, 28 Oct 2001 12:18:02 -0500 (EST) Received: from brad by dev1 with local (Exim 3.32 #1 (Debian)) id 15xxMA-00030D-00; Sun, 28 Oct 2001 16:20:34 -0500 Date: Sun, 28 Oct 2001 16:20:34 -0500 To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: PATCH: keyboard share irqs Message-ID: <20011028162034.A11542@dev1.ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i From: "Bradley D. LaRonde" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1362 Lines: 51 2001-10-28 Bradley D. LaRonde - Allow sharing of keyboard/aux irqs. - Add Rockhopper BB 2.0 keyboard suport. --- arch/mips/lib/kbd-std.c 2001/09/06 13:12:02 1.5 +++ arch/mips/lib/kbd-std.c 2001/10/28 21:16:53 @@ -7,14 +7,20 @@ * * Copyright (C) 1998, 1999 by Ralf Baechle */ +#include #include #include #include #include #include -#define KEYBOARD_IRQ 1 -#define AUX_IRQ 12 +#ifdef CONFIG_DDB5477 +#define KEYBOARD_IRQ 18 +#define AUX_IRQ KEYBOARD_IRQ +#else +#define KEYBOARD_IRQ 1 +#define AUX_IRQ 12 +#endif static void std_kbd_request_region(void) { @@ -27,17 +33,17 @@ static int std_kbd_request_irq(void (*handler)(int, void *, struct pt_regs *)) { - return request_irq(KEYBOARD_IRQ, handler, 0, "keyboard", NULL); + return request_irq(KEYBOARD_IRQ, handler, SA_SHIRQ, "keyboard", &std_kbd_request_irq); } static int std_aux_request_irq(void (*handler)(int, void *, struct pt_regs *)) { - return request_irq(AUX_IRQ, handler, 0, "PS/2 Mouse", NULL); + return request_irq(AUX_IRQ, handler, SA_SHIRQ, "PS/2 Mouse", &std_aux_request_irq); } static void std_aux_free_irq(void) { - free_irq(AUX_IRQ, NULL); + free_irq(AUX_IRQ, &std_aux_request_irq); } static unsigned char std_kbd_read_input(void) From owner-linux-mips@oss.sgi.com Sun Oct 28 22:57:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T6vq424656 for linux-mips-outgoing; Sun, 28 Oct 2001 22:57:52 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T6vf024652; Sun, 28 Oct 2001 22:57:41 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [216.32.174.27]) with SMTP; 29 Oct 2001 06:57:41 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 7D737B478; Mon, 29 Oct 2001 15:57:36 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id PAA33211; Mon, 29 Oct 2001 15:57:36 +0900 (JST) Date: Mon, 29 Oct 2001 16:02:25 +0900 (JST) Message-Id: <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> To: ralf@oss.sgi.com Cc: ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. From: Atsushi Nemoto In-Reply-To: <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1300 Lines: 42 >>>>> On Fri, 26 Oct 2001 22:58:06 +0900 (JST), Atsushi Nemoto said: nemoto> I have seen TX39 dead on "cfc1" insturuction if STATUS.CU1 bit nemoto> enabled. Such codes were in arch/mips/kernel/process.c. So, please apply this patch to CVS for TX39XX support. I use CONFIG_CPU_TX39XX in this patch, but I suppose other FPU-less CPUs may need this also. Does anybody know how about on other CPUs? diff -u linux-sgi-cvs/arch/mips/kernel/process.c linux.new/arch/mips/kernel/ --- linux-sgi-cvs/arch/mips/kernel/process.c Mon Oct 22 10:29:56 2001 +++ linux.new/arch/mips/kernel/process.c Mon Oct 29 15:49:37 2001 @@ -57,6 +57,12 @@ { /* Forget lazy fpu state */ if (last_task_used_math == current) { +#ifdef CONFIG_CPU_TX39XX + if (!(mips_cpu.options & MIPS_CPU_FPU)) { + last_task_used_math = NULL; + return; + } +#endif set_cp0_status(ST0_CU1); __asm__ __volatile__("cfc1\t$0,$31"); last_task_used_math = NULL; @@ -67,6 +73,12 @@ { /* Forget lazy fpu state */ if (last_task_used_math == current) { +#ifdef CONFIG_CPU_TX39XX + if (!(mips_cpu.options & MIPS_CPU_FPU)) { + last_task_used_math = NULL; + return; + } +#endif set_cp0_status(ST0_CU1); __asm__ __volatile__("cfc1\t$0,$31"); last_task_used_math = NULL; --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Mon Oct 29 00:32:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T8Wgt26479 for linux-mips-outgoing; Mon, 29 Oct 2001 00:32:42 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T8WW026472; Mon, 29 Oct 2001 00:32:32 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA02467; Mon, 29 Oct 2001 00:32:20 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA02278; Mon, 29 Oct 2001 00:32:16 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f9T8WEa13888; Mon, 29 Oct 2001 09:32:16 +0100 (MET) Message-ID: <3BDD140E.432D795B@mips.com> Date: Mon, 29 Oct 2001 09:32:14 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Atsushi Nemoto CC: ralf@oss.sgi.com, ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2703 Lines: 67 This doesn't look right, you still need to enable the CU1 bit in the status register to let the FP emulator kick-in. FPU-less CPUs should take a coprocessor unusable exception on any floating-point instructions. I have been running this on several FPU-less CPUs, and it works fine for me. Actually there is a problem with this code on CPUs, which have a FPU. The problem is that a lot of CPUs have a CP0 hazard of 4 nops, between setting the CU1 bit in the status register and executing the first floating point instruction thereafter. It probably only a performance issue, because if the setting of CU1 hasn't taken effect yet, then we get a coprocessor unusable exception and the the exception handler will also set the CU1 bit. /Carsten Atsushi Nemoto wrote: > >>>>> On Fri, 26 Oct 2001 22:58:06 +0900 (JST), Atsushi Nemoto said: > nemoto> I have seen TX39 dead on "cfc1" insturuction if STATUS.CU1 bit > nemoto> enabled. Such codes were in arch/mips/kernel/process.c. > > So, please apply this patch to CVS for TX39XX support. > > I use CONFIG_CPU_TX39XX in this patch, but I suppose other FPU-less > CPUs may need this also. > > Does anybody know how about on other CPUs? > > diff -u linux-sgi-cvs/arch/mips/kernel/process.c linux.new/arch/mips/kernel/ > --- linux-sgi-cvs/arch/mips/kernel/process.c Mon Oct 22 10:29:56 2001 > +++ linux.new/arch/mips/kernel/process.c Mon Oct 29 15:49:37 2001 > @@ -57,6 +57,12 @@ > { > /* Forget lazy fpu state */ > if (last_task_used_math == current) { > +#ifdef CONFIG_CPU_TX39XX > + if (!(mips_cpu.options & MIPS_CPU_FPU)) { > + last_task_used_math = NULL; > + return; > + } > +#endif > set_cp0_status(ST0_CU1); > __asm__ __volatile__("cfc1\t$0,$31"); > last_task_used_math = NULL; > @@ -67,6 +73,12 @@ > { > /* Forget lazy fpu state */ > if (last_task_used_math == current) { > +#ifdef CONFIG_CPU_TX39XX > + if (!(mips_cpu.options & MIPS_CPU_FPU)) { > + last_task_used_math = NULL; > + return; > + } > +#endif > set_cp0_status(ST0_CU1); > __asm__ __volatile__("cfc1\t$0,$31"); > last_task_used_math = NULL; > --- > Atsushi Nemoto -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Oct 29 00:39:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T8dXG26630 for linux-mips-outgoing; Mon, 29 Oct 2001 00:39:33 -0800 Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T8dV026626 for ; Mon, 29 Oct 2001 00:39:31 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id f9T8dT217529 for ; Mon, 29 Oct 2001 09:39:30 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW6NWMJG; Mon, 29 Oct 2001 09:39:12 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Mon, 29 Oct 2001 09:39:12 +0100 (W. Europe Standard Time) Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id <4YC1M6QN>; Mon, 29 Oct 2001 09:42:01 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E2B0@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: AW: Kernel 2.4.3 compile problem Date: Mon, 29 Oct 2001 09:41:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 375 Lines: 12 > If this file contains a NUL character your compiler installation got > corrupted somehow. Say might also be memory corruption of your compiler > host. > Oh. Sometimes it can be simple. I removed the NULL character at the end of the file and it compiled flawlessly. (Don't know where this thing came from...) Sorry for bothering with such a non-problem. regards Andre From owner-linux-mips@oss.sgi.com Mon Oct 29 00:51:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9T8prR27021 for linux-mips-outgoing; Mon, 29 Oct 2001 00:51:53 -0800 Received: from t111.niisi.ras.ru ([193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T8pj027018 for ; Mon, 29 Oct 2001 00:51:45 -0800 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id LAA29839; Mon, 29 Oct 2001 11:50:47 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA07482; Mon, 29 Oct 2001 12:41:31 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id LAA09240; Mon, 29 Oct 2001 11:25:26 +0300 (MSK) Message-ID: <3BDD12C8.A8D62ACB@niisi.msk.ru> Date: Mon, 29 Oct 2001 11:26:48 +0300 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Wayne Gowcher CC: linux-mips@oss.sgi.com Subject: Re: Backspace on Virtual Console causes oops References: <20011026183751.15156.qmail@web11906.mail.yahoo.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1119 Lines: 34 Wayne Gowcher wrote: > > Gleb, > > > Guess 1: You've got PC UARTs and > > drivers/char/serial.c > > Guess 2: TAB TAB in bash causes the oops too. > > Guess 3: You didn't change famous beep function in > > the driver. > > Correct on all 3 counts. Thanks for pointing the way. In fact, guess 1 is irrelevant. :-) > > I am grateful that my problem was solved quickly. But > before I posted to the list I did a search on > "Backspace oops linux", "Backspace crash linux" and a > few other combinations to see if this was possibly a > known problem. But turned nothing up. > Is there any other list / repository I should be > looking at to pick up on bugs like this ? > > Any tips / info would be greatly appreciated. This is a famous problem, just look at vt.c, you'll see a lot of ifdefs around sound routines. Just every porting engineer who encounter this problem solved it himself (and added own ifdef to vt.c). In my case, I just got fault epc, found the address in objdump -D output and look at the sources. For me it seems easier, than posting a message to a list. Regards, Gleb. From owner-linux-mips@oss.sgi.com Mon Oct 29 03:05:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TB5PY30192 for linux-mips-outgoing; Mon, 29 Oct 2001 03:05:25 -0800 Received: from dea.linux-mips.net (a1as18-p202.stg.tli.de [195.252.193.202]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TB5H030181 for ; Mon, 29 Oct 2001 03:05:17 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9TB5D203027 for linux-mips@oss.sgi.com; Mon, 29 Oct 2001 12:05:13 +0100 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9T9uc028676 for ; Mon, 29 Oct 2001 01:56:38 -0800 Message-Id: <200110290956.f9T9uc028676@oss.sgi.com> Received: from cc([210.5.16.17]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm223bdd6680; Mon, 29 Oct 2001 18:02:22 +0800 Date: Mon, 29 Oct 2001 17:54:15 +0800 From: 8route To: Atsushi Nemoto CC: "linux-mips@oss.sgi.com" , "carstenl@mips.com" Subject: other info about Toshiba TX3927 board boot problem. X-mailer: FoxMail 3.0 beta 1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="US_ASCII" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1193 Lines: 35 Dear Atsushi: Hi! I found the reset switch on the TX3927 board can work if you switch it against the PCI interface when ================================== VFS: Mounted root (NFS filesystem). Freeing unused kernel memory: 44k freed ======================================== ,usually I switch it towards the PCI interface. And I have fixed the source code of process.c as you said. >For TX3927, you must skip those two lines in exit_thread() and >flush_thread(). > > set_cp0_status(ST0_CU1, ST0_CU1); > __asm__ __volatile__("cfc1\t$0,$31"); > > But the problem still exists.The serial console output will stop at ================================== VFS: Mounted root (NFS filesystem). Freeing unused kernel memory: 44k freed ======================================== I think that maybe the Linux system has booted up OK,but there is something wrong with the serial console because serial ports are integrated with TX3927.Do you agree?Please consider it in your latest patch. >By the way, now I'm planning to send patches for TX CPU boards >(including JMR3927) to oss.sgi.com. If you can wait a while, you can >try it. Thank you very much. 8route ajob4me@21cn.com 10/29/2001 From owner-linux-mips@oss.sgi.com Mon Oct 29 05:34:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TDYCs03122 for linux-mips-outgoing; Mon, 29 Oct 2001 05:34:12 -0800 Received: from firewall.i-data.com (firewall.i-data.com [195.24.22.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TDY5003115 for ; Mon, 29 Oct 2001 05:34:05 -0800 From: tommy.christensen@eicon.com Received: (qmail 3009 invoked from network); 29 Oct 2001 13:34:02 -0000 Received: from idahub2000.i-data.com (HELO idanshub.i-data.com) (172.16.1.8) by firewall.i-data.com with SMTP; 29 Oct 2001 13:34:02 -0000 Received: from eicon.com ([172.17.159.1]) by idanshub.i-data.com (Lotus Domino Release 5.0.8) with ESMTP id 2001102914361998:11913 ; Mon, 29 Oct 2001 14:36:19 +0100 Message-ID: <3BDD5B31.E12DE812@eicon.com> Date: Mon, 29 Oct 2001 14:35:45 +0100 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) MIME-Version: 1.0 To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Fixup in unaligned.c X-MIMETrack: Itemize by SMTP Server on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 29-10-2001 14:36:20, MIME-CD by Notes Server on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 29-10-2001 14:36:20, MIME-CD complete at 29-10-2001 14:36:20, Serialize by Router on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 29-10-2001 14:36:20 Content-type: multipart/mixed; Boundary="0__=C1256AF4004ABCDC8f9e8a93df938690918cC1256AF4004ABCDC" Content-Disposition: inline Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2876 Lines: 66 --0__=C1256AF4004ABCDC8f9e8a93df938690918cC1256AF4004ABCDC Content-type: text/plain; charset=us-ascii It seems we don't always handle bad user-mode pointers correctly. If put_user is called with an unmapped AND unaligned address it kills the current process instead of returning EFAULT. The reason for this is that we do compute_return_epc() in do_ade() before the exception table is searched, so we never get a match. Below is a simple patch to fix it (attached as well). The second part is not related, but it makes sense to only consult the MF_FIXADE flag on exceptions originating from user-mode, right? -Tommy --- arch/mips/kernel/unaligned.c 2001/10/05 15:13:25 1.14 +++ arch/mips/kernel/unaligned.c 2001/10/29 12:39:56 @@ -353,12 +353,12 @@ fault: /* Did we have an exception handler installed? */ - fixup = search_exception_table(regs->cp0_epc); + fixup = search_exception_table(pc); if (fixup) { long new_epc; - new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); + new_epc = fixup_exception(dpf_reg, fixup, pc); printk(KERN_DEBUG "%s: Forwarding exception at [<%lx>] (%lx)\n", - current->comm, regs->cp0_epc, new_epc); + current->comm, pc, new_epc); regs->cp0_epc = new_epc; return; } @@ -408,7 +408,7 @@ pc = regs->cp0_epc + ((regs->cp0_cause & CAUSEF_BD) ? 4 : 0); if (compute_return_epc(regs)) return; - if ((current->thread.mflags & MF_FIXADE) == 0) + if (user_mode(regs) && (current->thread.mflags & MF_FIXADE) == 0) goto sigbus; emulate_load_store_insn(regs, regs->cp0_badvaddr, pc); (See attached file: unaligned.c.patch.gz) --0__=C1256AF4004ABCDC8f9e8a93df938690918cC1256AF4004ABCDC Content-type: application/octet-stream; name="unaligned.c.patch.gz" Content-Disposition: attachment; filename="unaligned.c.patch.gz" Content-transfer-encoding: base64 H4sICJBO3TsAA3VuYWxpZ25lZC5jLnBhdGNoAKVSW2/TMBR+Tn7F0aRVyZI0SS/AUrp1W1s0IXjY NAkJUOTGJ6k114kcp62E+O84SelaQIMJvxxbPt/lXG4FxW0ERCZLf8WK0n9EKZD7lSCcZQJpNzHH /3/Mu5t7SBnHCPxkXfqciWrrP6fqrk2JSjJcM5GB1KFkuYCwGw5MytIUvAo8WT/h0Kvnec8WY/SC IPTDwA+GEA6jsB/1hkZD6jjOvyF75xD2ov55NHxlTibg9Yd9N+yBs4uTiQkmpKTiKjLB8M9gyihs EJZkjUAE4DbBQtXFLImgHCUwUSrCOdJLOPNNz0jZtipgDCXWhuI9IFZkwdGSmJXeRVIEMRaJPTKd vwGaLDBYClaTacM3/TR4rjsrcFPTjLSssbtroibticeiRRprWbf9cOF3Cy8A7+wYhWRCPVrvZ3cf 4+ns+uEdnJyWEcxzuSGS1mN/ahVR8PntKd9efAVLB/uLOHFry9CepJIShdKW8tXqF3vuzxpbn39G HKdpc0cUuqh9n5o/VUlRX783GzAI3rivwWlDPX+jgRxTOGAdTC4hVYnQgZurh/vZPL6e2nAJA4gg 2I9KGysqhXGrVnM0eNs+tOA1qda+GrWUSGh3lXKSlZr/wzye3366ms5sGI81ue5ADdDiMl7ltF0m GzodeAGH1s9ylUPJskVVjup9N3BVcaLd8pzQuFS5xFivtWj4DweyIHRNKJW7NfgBiEKUKoAEAAA= --0__=C1256AF4004ABCDC8f9e8a93df938690918cC1256AF4004ABCDC-- From owner-linux-mips@oss.sgi.com Mon Oct 29 07:50:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TFoID20907 for linux-mips-outgoing; Mon, 29 Oct 2001 07:50:18 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TFnf020852 for ; Mon, 29 Oct 2001 07:49:42 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA10688; Mon, 29 Oct 2001 16:47:50 +0100 (MET) Date: Mon, 29 Oct 2001 16:47:50 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] 2.4.10: DEC LK201 keyboard updates Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 11970 Lines: 383 Hi, The lk201.c driver doesn't compile due to a duplicate kbd_rate() definition. The following patch fixes it by defining a private lk201kbd_rate() function like other keyboard drivers do. While I was at it I decided to update the driver a bit. I've added LED handling (the "Lock" and "Hold Screen" LEDs for now), a console beep handler and a typematic rate selector. I've applied a few minor fixes to the existing code. Finally I've corrected and updated macros and documentation bits in lk201.h. The changes look sane and testing shows they are working. The typematic rate selector doesn't seem to have any effect, but it might be a measurement error -- I don't have a real vt device and I do all the testing with its output directed to a serial console. If anyone can verify it has an effect on his system, it would be great. It doesn't harm anyway. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.10-20011026-lk201-7 diff -up --recursive --new-file linux-mips-2.4.10-20011026.macro/drivers/tc/lk201.c linux-mips-2.4.10-20011026/drivers/tc/lk201.c --- linux-mips-2.4.10-20011026.macro/drivers/tc/lk201.c Thu Oct 18 04:27:14 2001 +++ linux-mips-2.4.10-20011026/drivers/tc/lk201.c Mon Oct 29 03:08:15 2001 @@ -4,15 +4,20 @@ * License. See the file "COPYING" in the main directory of this archive * for more details. * + * Copyright (C) 2001 Maciej W. Rozycki */ + #include #include +#include #include #include #include #include #include +#include +#include #include #include @@ -77,6 +82,8 @@ static unsigned char lk201_reset_string[ LK_CMD_LEDS_OFF, LK_PARAM_LED_MASK(0xf) }; +static struct dec_serial* lk201kbd_info; + static int __init lk201_reset(struct dec_serial *info) { int i; @@ -89,16 +96,115 @@ static int __init lk201_reset(struct dec return 0; } -int kbd_rate(struct kbd_repeat *rep) +#define DEFAULT_KEYB_REP_DELAY (250/5) /* [5ms] */ +#define DEFAULT_KEYB_REP_RATE 30 /* [cps] */ + +static struct kbd_repeat kbdrate = { + DEFAULT_KEYB_REP_DELAY, + DEFAULT_KEYB_REP_RATE +}; + +static void parse_kbd_rate(struct kbd_repeat *r) { - return 0; + if (r->delay <= 0) + r->delay = kbdrate.delay; + if (r->rate <= 0) + r->rate = kbdrate.rate; + + if (r->delay < 5) + r->delay = 5; + if (r->delay > 630) + r->delay = 630; + if (r->rate < 12) + r->rate = 12; + if (r->rate > 127) + r->rate = 127; + if (r->rate == 125) + r->rate = 124; } +static int write_kbd_rate(struct kbd_repeat *rep) +{ + struct dec_serial* info = lk201kbd_info; + int delay, rate; + int i; + delay = rep->delay / 5; + rate = rep->rate; + for (i = 0; i < 4; i++) { + if (info->hook->poll_tx_char(info, LK_CMD_RPT_RATE(i))) + return 1; + if (info->hook->poll_tx_char(info, LK_PARAM_DELAY(delay))) + return 1; + if (info->hook->poll_tx_char(info, LK_PARAM_RATE(rate))) + return 1; + } + return 0; +} + +static int lk201kbd_rate(struct kbd_repeat *rep) +{ + if (rep == NULL) + return -EINVAL; + + parse_kbd_rate(rep); + + if (write_kbd_rate(rep)) { + memcpy(rep, &kbdrate, sizeof(struct kbd_repeat)); + return -EIO; + } + + memcpy(&kbdrate, rep, sizeof(struct kbd_repeat)); + + return 0; +} + +static void lk201kd_mksound(unsigned int hz, unsigned int ticks) +{ + struct dec_serial* info = lk201kbd_info; + + if (!ticks) + return; + + /* + * Can't set frequency and we "approximate" + * duration by volume. ;-) + */ + ticks /= HZ / 32; + if (ticks > 7) + ticks = 7; + ticks = 7 - ticks; + + if (info->hook->poll_tx_char(info, LK_CMD_ENB_BELL)) + return; + if (info->hook->poll_tx_char(info, LK_PARAM_VOLUME(ticks))) + return; + if (info->hook->poll_tx_char(info, LK_CMD_BELL)) + return; +} void kbd_leds(unsigned char leds) { - return; + struct dec_serial* info = lk201kbd_info; + unsigned char l = 0; + + if (!info) /* FIXME */ + return; + + /* FIXME -- Only Hold and Lock LEDs for now. --macro */ + if (leds & LED_SCR) + l |= LK_LED_HOLD; + if (leds & LED_CAP) + l |= LK_LED_LOCK; + + if (info->hook->poll_tx_char(info, LK_CMD_LEDS_ON)) + return; + if (info->hook->poll_tx_char(info, LK_PARAM_LED_MASK(l))) + return; + if (info->hook->poll_tx_char(info, LK_CMD_LEDS_OFF)) + return; + if (info->hook->poll_tx_char(info, LK_PARAM_LED_MASK(~l))) + return; } int kbd_setkeycode(unsigned int scancode, unsigned int keycode) @@ -131,7 +237,12 @@ static void lk201_kbd_rx_char(unsigned c if (!stat || stat == 4) { switch (ch) { - case LK_KEY_ACK: + case LK_STAT_RESUME_ERR: + case LK_STAT_ERROR: + case LK_STAT_INHIBIT_ACK: + case LK_STAT_TEST_ACK: + case LK_STAT_MODE_KEYDOWN: + case LK_STAT_MODE_ACK: break; case LK_KEY_LOCK: shift_state ^= LK_LOCK; @@ -170,6 +281,7 @@ static void lk201_kbd_rx_char(unsigned c } } else printk("Error reading LKx01 keyboard: 0x%02x\n", stat); + tasklet_schedule(&keyboard_tasklet); } static void __init lk201_info(struct dec_serial *info) @@ -213,6 +325,10 @@ static int __init lk201_init(struct dec_ */ info->hook->rx_char = lk201_kbd_rx_char; + lk201kbd_info = info; + kbd_rate = lk201kbd_rate; + kd_mksound = lk201kd_mksound; + return 0; } @@ -244,7 +360,3 @@ void __init kbd_init_hw(void) printk("LK201 Support for DS3100 not yet ready ...\n"); } } - - - - diff -up --recursive --new-file linux-mips-2.4.10-20011026.macro/drivers/tc/lk201.h linux-mips-2.4.10-20011026/drivers/tc/lk201.h --- linux-mips-2.4.10-20011026.macro/drivers/tc/lk201.h Sat Dec 30 15:55:57 2000 +++ linux-mips-2.4.10-20011026/drivers/tc/lk201.h Mon Oct 29 03:14:21 2001 @@ -2,52 +2,121 @@ * Commands to the keyboard processor */ -#define LK_PARAM 0x80 /* start/end parameter list */ +#define LK_PARAM 0x80 /* start/end parameter list */ -#define LK_CMD_RESUME 0x8b -#define LK_CMD_INHIBIT 0xb9 -#define LK_CMD_LEDS_ON 0x13 /* 1 param: led bitmask */ -#define LK_CMD_LEDS_OFF 0x11 /* 1 param: led bitmask */ -#define LK_CMD_DIS_KEYCLK 0x99 -#define LK_CMD_ENB_KEYCLK 0x1b /* 1 param: volume */ -#define LK_CMD_DIS_CTLCLK 0xb9 -#define LK_CMD_ENB_CTLCLK 0xbb -#define LK_CMD_SOUND_CLK 0x9f -#define LK_CMD_DIS_BELL 0xa1 -#define LK_CMD_ENB_BELL 0x23 /* 1 param: volume */ -#define LK_CMD_BELL 0xa7 -#define LK_CMD_TMP_NORPT 0xc1 -#define LK_CMD_ENB_RPT 0xe3 -#define LK_CMD_DIS_RPT 0xe1 -#define LK_CMD_RPT_TO_DOWN 0xd9 -#define LK_CMD_REQ_ID 0xab -#define LK_CMD_POWER_UP 0xfd -#define LK_CMD_TEST_MODE 0xcb -#define LK_CMD_SET_DEFAULTS 0xd3 +#define LK_CMD_RESUME 0x8b /* resume transmission to the host */ +#define LK_CMD_INHIBIT 0x89 /* stop transmission to the host */ +#define LK_CMD_LEDS_ON 0x13 /* light LEDs */ + /* 1st param: led bitmask */ +#define LK_CMD_LEDS_OFF 0x11 /* turn off LEDs */ + /* 1st param: led bitmask */ +#define LK_CMD_DIS_KEYCLK 0x99 /* disable the keyclick */ +#define LK_CMD_ENB_KEYCLK 0x1b /* enable the keyclick */ + /* 1st param: volume */ +#define LK_CMD_DIS_CTLCLK 0xb9 /* disable the Ctrl keyclick */ +#define LK_CMD_ENB_CTLCLK 0xbb /* enable the Ctrl keyclick */ +#define LK_CMD_SOUND_CLK 0x9f /* emit a keyclick */ +#define LK_CMD_DIS_BELL 0xa1 /* disable the bell */ +#define LK_CMD_ENB_BELL 0x23 /* enable the bell */ + /* 1st param: volume */ +#define LK_CMD_BELL 0xa7 /* emit a bell */ +#define LK_CMD_TMP_NORPT 0xc1 /* disable typematic */ + /* for the currently pressed key */ +#define LK_CMD_ENB_RPT 0xe3 /* enable typematic */ + /* for RPT_DOWN groups */ +#define LK_CMD_DIS_RPT 0xe1 /* disable typematic */ + /* for RPT_DOWN groups */ +#define LK_CMD_RPT_TO_DOWN 0xd9 /* set RPT_DOWN groups to DOWN */ +#define LK_CMD_REQ_ID 0xab /* request the keyboard ID */ +#define LK_CMD_POWER_UP 0xfd /* init power-up sequence */ +#define LK_CMD_TEST_MODE 0xcb /* enter the factory test mode */ +#define LK_CMD_TEST_EXIT 0x80 /* exit the factory test mode */ +#define LK_CMD_SET_DEFAULTS 0xd3 /* set power-up defaults */ + +#define LK_CMD_MODE(m,div) (LK_PARAM|(((div)&0xf)<<3)|m) + /* select the repeat mode */ + /* for the selected key group */ +#define LK_CMD_MODE_AR(m,div) ((((div)&0xf)<<3)|m) + /* select the repeat mode */ + /* and the repeat register */ + /* for the selected key group */ + /* 1st param: register number */ +#define LK_CMD_RPT_RATE(r) (0x04|((((r)&0x3)<<1))) + /* set the delay and repeat rate */ + /* for the selected repeat register */ + /* 1st param: initial delay */ + /* 2nd param: repeat rate */ /* there are 4 leds, represent them in the low 4 bits of a byte */ -#define LK_PARAM_LED_MASK(ledbmap) (LK_PARAM|(ledbmap)) +#define LK_PARAM_LED_MASK(ledbmap) (LK_PARAM|((ledbmap)&0xf)) +#define LK_LED_WAIT 0x1 /* Wait LED */ +#define LK_LED_COMP 0x2 /* Compose LED */ +#define LK_LED_LOCK 0x4 /* Lock LED */ +#define LK_LED_HOLD 0x8 /* Hold Screen LED */ /* max volume is 0, lowest is 0x7 */ -#define LK_PARAM_VOLUME(v) (LK_PARAM|((v)&0x7)) +#define LK_PARAM_VOLUME(v) (LK_PARAM|((v)&0x7)) -/* mode set command(s) details */ -#define LK_MODE_DOWN 0x0 -#define LK_MODE_RPT_DOWN 0x2 -#define LK_MODE_DOWN_UP 0x6 -#define LK_CMD_MODE(m,div) (LK_PARAM|(div<<3)|m) +/* mode set command details, div is a key group number */ +#define LK_MODE_DOWN 0x0 /* make only */ +#define LK_MODE_RPT_DOWN 0x2 /* make and typematic */ +#define LK_MODE_DOWN_UP 0x6 /* make and release */ + +/* there are 4 repeat registers */ +#define LK_PARAM_AR(r) (LK_PARAM|((v)&0x3)) + +/* + * Mappings between key groups and keycodes are as follows: + * + * 1: 0xbf - 0xfb -- alphanumeric, + * 2: 0x92 - 0xa4 -- numeric keypad, + * 3: 0xbc -- Backspace, + * 4: 0xbd - 0xbe -- Tab, Return, + * 5: 0xb0 - 0xb1 -- Lock, Compose Character, + * 6: 0xae - 0xaf -- Ctrl, Shift, + * 7: 0xa7 - 0xa8 -- Left Arrow, Right Arrow, + * 8: 0xa9 - 0xab -- Up Arrow, Down Arrow, Right Shift, + * 9: 0x8a - 0x8f -- editor keypad, + * 10: 0x56 - 0x5a -- F1 - F5, + * 11: 0x64 - 0x68 -- F6 - F10, + * 12: 0x71 - 0x74 -- F11 - F14, + * 13: 0x7c - 0x7d -- Help, Do, + * 14: 0x80 - 0x83 -- F17 - F20. + * + * Others, i.e. 0x55, 0xac, 0xad, 0xb2, are undiscovered. + */ + +/* delay is 5 - 630 ms; 0x00 and 0x7f are reserved */ +#define LK_PARAM_DELAY(t) ((t)&0x7f) + +/* rate is 12 - 127 Hz; 0x00 - 0x0b and 0x7d (power-up!) are reserved */ +#define LK_PARAM_RATE(r) (LK_PARAM|((r)&0x7f)) #define LK_SHIFT 1<<0 #define LK_CTRL 1<<1 #define LK_LOCK 1<<2 #define LK_COMP 1<<3 -#define LK_KEY_SHIFT 174 -#define LK_KEY_CTRL 175 -#define LK_KEY_LOCK 176 -#define LK_KEY_COMP 177 -#define LK_KEY_RELEASE 179 -#define LK_KEY_REPEAT 180 -#define LK_KEY_ACK 186 +#define LK_KEY_SHIFT 0xae +#define LK_KEY_CTRL 0xaf +#define LK_KEY_LOCK 0xb0 +#define LK_KEY_COMP 0xb1 + +#define LK_KEY_RELEASE 0xb3 /* all keys released */ +#define LK_KEY_REPEAT 0xb4 /* repeat the last key */ + +/* status responses */ +#define LK_STAT_RESUME_ERR 0xb5 /* keystrokes lost while inhibited */ +#define LK_STAT_ERROR 0xb6 /* an invalid command received */ +#define LK_STAT_INHIBIT_ACK 0xb7 /* transmission inhibited */ +#define LK_STAT_TEST_ACK 0xb8 /* the factory test mode entered */ +#define LK_STAT_MODE_KEYDOWN 0xb9 /* a key is down on a change */ + /* to the DOWN_UP mode; */ + /* the keycode follows */ +#define LK_STAT_MODE_ACK 0xba /* the mode command succeeded */ + +#define LK_STAT_PWRUP_OK 0x00 /* the power-up self test OK */ +#define LK_STAT_PWRUP_KDOWN 0x3d /* a key was down during the test */ +#define LK_STAT_PWRUP_ERROR 0x3e /* keyboard self test failure */ -extern unsigned char scancodeRemap[256]; \ No newline at end of file +extern unsigned char scancodeRemap[256]; From owner-linux-mips@oss.sgi.com Mon Oct 29 09:05:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TH5vj22511 for linux-mips-outgoing; Mon, 29 Oct 2001 09:05:57 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TH5l022502 for ; Mon, 29 Oct 2001 09:05:47 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA12748; Mon, 29 Oct 2001 18:05:24 +0100 (MET) Date: Mon, 29 Oct 2001 18:05:23 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: linux-mips@oss.sgi.com To: linux-mips@fnet.fr, linux-mips@oss.sgi.com cc: linux-vax@mithra.physics.montana.edu Subject: FYI: Mopd ELF support Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1474 Lines: 31 Hi, I've made a preliminary version of mopd with ELF support available. It's Mats O. Jansson's mopd 2.5.3 with several fixes, updates and enhancements. The work is definitely not finished, but basic functionality is already implemented. I'm making it available due to the amount of PITA maintenance of traditional mopd image formats incurs, in hope someone will find it useful. Libelf is required for this version of mopd. It should build and run on any Linux system, regardless of endianness. It might work on other systems as well. I've made RPM packages available at the usual place (i.e. 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'). Beside source packages there are i386 and mipsel binary ones available. Grab the latest version; olders are for a reference only. To aid people with no RPM support in their systems I've unpacked the source package into the "mopd" directory. Still you need to study the .spec file to figure how to build binaries. Any feedback will be appreciated; I'm especially interested in reports from VAX users, as I've only been able to verify the operation booting Linux on a DECstation 5000 (i.e. MIPS) system. Note: this version of mopd does not require switching devices into the PROMISC or ALLMULTI modes of operation. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Oct 29 10:21:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TILTe31651 for linux-mips-outgoing; Mon, 29 Oct 2001 10:21:29 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TILR031648 for ; Mon, 29 Oct 2001 10:21:27 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9TILNE0031477; Mon, 29 Oct 2001 10:21:23 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f9TILMfw031473; Mon, 29 Oct 2001 10:21:23 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 29 Oct 2001 10:21:22 -0800 (PST) From: James Simmons To: "Gleb O. Raiko" cc: Wayne Gowcher , linux-mips@oss.sgi.com Subject: Re: Backspace on Virtual Console causes oops In-Reply-To: <3BDD12C8.A8D62ACB@niisi.msk.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 500 Lines: 12 > This is a famous problem, just look at vt.c, you'll see a lot of ifdefs > around sound routines. Just every porting engineer who encounter this > problem solved it himself (and added own ifdef to vt.c). In my case, I > just got fault epc, found the address in objdump -D output and look at > the sources. For me it seems easier, than posting a message to a list. > I plan to have this problem removed in 2.5.X when the console system is migrated to the input api :-) From owner-linux-mips@oss.sgi.com Mon Oct 29 10:29:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TITcv32076 for linux-mips-outgoing; Mon, 29 Oct 2001 10:29:38 -0800 Received: from dark-past (h117n1fls20o53.telia.com [213.64.214.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TITa032073 for ; Mon, 29 Oct 2001 10:29:36 -0800 Received: from yog-sothoth.dark-past.mine.nu (yog-sothoth [192.168.1.7]) by dark-past (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA21653 for ; Mon, 29 Oct 2001 21:41:12 -0800 Message-Id: <5.1.0.14.0.20011029204836.00a63170@192.168.1.5> X-Sender: peter@192.168.1.5 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Oct 2001 21:08:10 +0100 To: linux-mips@oss.sgi.com From: Peter Andersson Subject: "relocation truncated to fit" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 281 Lines: 9 Hi, i am trying to compile mozilla 0.9.5 on my indy running mips/redhat linux 7.0 and get hundreds of messages telling me "relocation truncated to fit: R_MIPS_GOT16". Does anyone know how to get around this? I tried to add the ld flags -G O but without success. Thanks Peter From owner-linux-mips@oss.sgi.com Mon Oct 29 10:42:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TIgBY00996 for linux-mips-outgoing; Mon, 29 Oct 2001 10:42:11 -0800 Received: from straylight.cyberhqz.com (root@h24-76-98-250.vc.shawcable.net [24.76.98.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TIg7000993 for ; Mon, 29 Oct 2001 10:42:07 -0800 Received: (from rmurray@localhost) by straylight.cyberhqz.com (8.9.3/8.9.3/Debian 8.9.3-21) id KAA15694 for linux-mips@oss.sgi.com; Mon, 29 Oct 2001 10:42:06 -0800 From: Ryan Murray Date: Mon, 29 Oct 2001 10:42:05 -0800 To: linux-mips@oss.sgi.com Subject: Re: "relocation truncated to fit" Message-ID: <20011029104205.J18529@cyberhqz.com> Mail-Followup-To: linux-mips@oss.sgi.com References: <5.1.0.14.0.20011029204836.00a63170@192.168.1.5> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5xSkJheCpeK0RUEJ" Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20011029204836.00a63170@192.168.1.5> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1192 Lines: 39 --5xSkJheCpeK0RUEJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 29, 2001 at 09:08:10PM +0100, Peter Andersson wrote: > Hi, i am trying to compile mozilla 0.9.5 on my indy running mips/redhat= =20 > linux 7.0 and get hundreds of messages telling me "relocation truncated t= o=20 > fit: R_MIPS_GOT16". Does anyone know how to get around this? I tried to a= dd=20 > the ld flags -G O but without success. 0.9.5 should have a -Wa,-xgot section in the makefile for linux/mips, like netbsd/mips has. If it doesn't, you'll need to pull that change from cvs. You'll also need to ensure that libgcc.a and libc_noshared.a are also built with -Wa,-xgot --=20 Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own. --5xSkJheCpeK0RUEJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE73aL9N2Dbz/1mRasRAiI3AJ9seU/aWLVPJ5APF7iGN83HsLzU6QCdGro3 ultlllMudJMn9ePPFHIlAS8= =XHJM -----END PGP SIGNATURE----- --5xSkJheCpeK0RUEJ-- From owner-linux-mips@oss.sgi.com Mon Oct 29 11:29:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TJTsX04041 for linux-mips-outgoing; Mon, 29 Oct 2001 11:29:54 -0800 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TJTm004036 for ; Mon, 29 Oct 2001 11:29:48 -0800 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 59C09590AC; Mon, 29 Oct 2001 10:26:36 -0500 (EST) Message-ID: <04c801c160b0$1d62f660$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Jun Sun" Cc: , References: <20011026210746.A20395@dev1.ltc.com> <3BDDACD2.7121F905@mvista.com> Subject: Re: PATCH: pci_auto bridge support Date: Mon, 29 Oct 2001 14:30:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1872 Lines: 56 I considered that, but since only this small chuck of run-once surrogate bios autoconfig code needs to know, I figured better keep it separate. Regards, Brad ----- Original Message ----- From: "Jun Sun" To: "Bradley D. LaRonde" Cc: ; Sent: Monday, October 29, 2001 2:24 PM Subject: Re: PATCH: pci_auto bridge support > > Brad, > > Have you considered embedding "topbus" argument into hose structure? That > sounds like potentially better solution. > > > > "Bradley D. LaRonde" wrote: > > > > 2001-10-26 Bradley D. LaRonde > > > > * PCI bridge support. See change log entry below. > > > > --- arch/mips/kernel/pci_auto.c 2001/08/18 06:21:53 1.1 > > +++ arch/mips/kernel/pci_auto.c 2001/10/27 01:01:21 > > @@ -4,6 +4,7 @@ > > * Author: Matt Porter > > * > > * Copyright 2000, 2001 MontaVista Software Inc. > > + * Copyright 2001 Bradley D. LaRonde > > * > > * 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 > > @@ -19,6 +20,15 @@ > > * . change most int to u32. > > * > > * Further modified to include it as mips generic code, ppopov@mvista.com. > > + * > > + * 2001-10-26 Bradley D. LaRonde > > + * - Add a top_bus argument to the "early config" functions so that > > + * they can set a fake parent bus pointer to convince the underlying > > + * pci ops to use type 1 configuration for sub busses. > > + * - Set bridge base and limit registers correctly. > > + * - Align io and memory base properly before and after bridge setup. > > + * - Don't fall through to pci_setup_bars for bridge. > > + * - Reformat the debug output to look more like lspci's output. > > */ From owner-linux-mips@oss.sgi.com Mon Oct 29 11:40:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TJeJw04225 for linux-mips-outgoing; Mon, 29 Oct 2001 11:40:19 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TJdf004217 for ; Mon, 29 Oct 2001 11:39:41 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02626 for ; Mon, 29 Oct 2001 11:39:36 -0800 (PST) mail_from (jsun@mvista.com) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9TJPwB27118; Mon, 29 Oct 2001 11:25:58 -0800 Message-ID: <3BDDACD2.7121F905@mvista.com> Date: Mon, 29 Oct 2001 11:24:02 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Bradley D. LaRonde" CC: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: PATCH: pci_auto bridge support References: <20011026210746.A20395@dev1.ltc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 20371 Lines: 447 Brad, Have you considered embedding "topbus" argument into hose structure? That sounds like potentially better solution. "Bradley D. LaRonde" wrote: > > 2001-10-26 Bradley D. LaRonde > > * PCI bridge support. See change log entry below. > > --- arch/mips/kernel/pci_auto.c 2001/08/18 06:21:53 1.1 > +++ arch/mips/kernel/pci_auto.c 2001/10/27 01:01:21 > @@ -4,6 +4,7 @@ > * Author: Matt Porter > * > * Copyright 2000, 2001 MontaVista Software Inc. > + * Copyright 2001 Bradley D. LaRonde > * > * 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 > @@ -19,6 +20,15 @@ > * . change most int to u32. > * > * Further modified to include it as mips generic code, ppopov@mvista.com. > + * > + * 2001-10-26 Bradley D. LaRonde > + * - Add a top_bus argument to the "early config" functions so that > + * they can set a fake parent bus pointer to convince the underlying > + * pci ops to use type 1 configuration for sub busses. > + * - Set bridge base and limit registers correctly. > + * - Align io and memory base properly before and after bridge setup. > + * - Don't fall through to pci_setup_bars for bridge. > + * - Reformat the debug output to look more like lspci's output. > */ > > #include > @@ -34,14 +44,47 @@ > #else > #define DBG(x...) > #endif > + > +/* > + * These functions are used early on before PCI scanning is done > + * and all of the pci_dev and pci_bus structures have been created. > + */ > +static struct pci_dev *fake_pci_dev(struct pci_channel *hose, > + int top_bus, int busnr, int devfn) > +{ > + static struct pci_dev dev; > + static struct pci_bus bus; > + > + dev.bus = &bus; > + dev.sysdata = hose; > + dev.devfn = devfn; > + bus.number = busnr; > + bus.ops = hose->pci_ops; > + > + if(busnr != top_bus) > + /* Fake a parent bus structure. */ > + bus.parent = &bus; > + else > + bus.parent = NULL; > + > + return &dev; > +} > + > +#define EARLY_PCI_OP(rw, size, type) \ > +int early_##rw##_config_##size(struct pci_channel *hose, \ > + int top_bus, int bus, int devfn, int offset, type value) \ > +{ \ > + return pci_##rw##_config_##size( \ > + fake_pci_dev(hose, top_bus, bus, devfn), \ > + offset, value); \ > +} > > -/* These are used for config access before all the PCI probing has been done. */ > -int early_read_config_byte(struct pci_channel *hose, int bus, int dev_fn, int where, u8 *val); > -int early_read_config_word(struct pci_channel *hose, int bus, int dev_fn, int where, u16 *val); > -int early_read_config_dword(struct pci_channel *hose, int bus, int dev_fn, int where, u32 *val); > -int early_write_config_byte(struct pci_channel *hose, int bus, int dev_fn, int where, u8 val); > -int early_write_config_word(struct pci_channel *hose, int bus, int dev_fn, int where, u16 val); > -int early_write_config_dword(struct pci_channel *hose, int bus, int dev_fn, int where, u32 val); > +EARLY_PCI_OP(read, byte, u8 *) > +EARLY_PCI_OP(read, word, u16 *) > +EARLY_PCI_OP(read, dword, u32 *) > +EARLY_PCI_OP(write, byte, u8) > +EARLY_PCI_OP(write, word, u16) > +EARLY_PCI_OP(write, dword, u32) > > static u32 pciauto_lower_iospc; > static u32 pciauto_upper_iospc; > @@ -51,6 +94,7 @@ > > void __init > pciauto_setup_bars(struct pci_channel *hose, > + int top_bus, > int current_bus, > int pci_devfn) > { > @@ -60,17 +104,14 @@ > u32 * lower_limit; > int found_mem64 = 0; > > - DBG("PCI Autoconfig: Found Bus %d, Device %d, Function %d\n", > - current_bus, PCI_SLOT(pci_devfn), PCI_FUNC(pci_devfn) ); > - > for (bar = PCI_BASE_ADDRESS_0; bar <= PCI_BASE_ADDRESS_5; bar+=4) { > /* Tickle the BAR and get the response */ > - early_write_config_dword(hose, > + early_write_config_dword(hose, top_bus, > current_bus, > pci_devfn, > bar, > 0xffffffff); > - early_read_config_dword(hose, > + early_read_config_dword(hose, top_bus, > current_bus, > pci_devfn, > bar, > @@ -80,12 +121,20 @@ > if (!bar_response) > continue; > > + /* > + * Workaround for a BAR that doesn't use its upper word, > + * like the ALi 1535D+ PCI DC-97 Controller Modem (M5457). > + * bdl > + */ > + if (!(bar_response & 0xffff0000)) > + bar_response |= 0xffff0000; > + > /* Check the BAR type and set our address mask */ > if (bar_response & PCI_BASE_ADDRESS_SPACE) { > addr_mask = PCI_BASE_ADDRESS_IO_MASK; > upper_limit = &pciauto_upper_iospc; > lower_limit = &pciauto_lower_iospc; > - DBG("PCI Autoconfig: BAR %d, I/O, ", bar_nr); > + DBG(" I/O"); > } else { > if ((bar_response & PCI_BASE_ADDRESS_MEM_TYPE_MASK) == > PCI_BASE_ADDRESS_MEM_TYPE_64) > @@ -94,7 +143,7 @@ > addr_mask = PCI_BASE_ADDRESS_MEM_MASK; > upper_limit = &pciauto_upper_memspc; > lower_limit = &pciauto_lower_memspc; > - DBG("PCI Autoconfig: BAR %d, Mem, ", bar_nr); > + DBG(" Mem"); > } > > /* Calculate requested size */ > @@ -104,7 +153,7 @@ > bar_value = ((*lower_limit - 1) & ~(bar_size - 1)) + bar_size; > > /* Write it out and update our limit */ > - early_write_config_dword(hose, current_bus, pci_devfn, > + early_write_config_dword(hose, top_bus, current_bus, pci_devfn, > bar, bar_value); > > *lower_limit = bar_value + bar_size; > @@ -116,97 +165,99 @@ > */ > if (found_mem64) { > bar += 4; > - early_write_config_dword(hose, > + early_write_config_dword(hose, top_bus, > current_bus, > pci_devfn, > bar, > 0x00000000); > } > > - bar_nr++; > + DBG(" at 0x%.8x [size=0x%x]\n", bar_value, bar_size); > > - DBG("size=0x%x, address=0x%x\n", > - bar_size, bar_value); > + bar_nr++; > } > > } > > void __init > pciauto_prescan_setup_bridge(struct pci_channel *hose, > + int top_bus, > int current_bus, > int pci_devfn, > int sub_bus) > { > - int cmdstat; > - > /* Configure bus number registers */ > - early_write_config_byte(hose, current_bus, pci_devfn, > + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, > PCI_PRIMARY_BUS, current_bus); > - early_write_config_byte(hose, current_bus, pci_devfn, > + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, > PCI_SECONDARY_BUS, sub_bus + 1); > - early_write_config_byte(hose, current_bus, pci_devfn, > + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, > PCI_SUBORDINATE_BUS, 0xff); > - > - /* Round memory allocator to 1MB boundary */ > - pciauto_upper_memspc &= ~(0x100000 - 1); > > - /* Round I/O allocator to 4KB boundary */ > - pciauto_upper_iospc &= ~(0x1000 - 1); > + /* Align memory and I/O to 1MB and 4KB boundaries. */ > + pciauto_lower_memspc = (pciauto_lower_memspc + (0x100000 - 1)) > + & ~(0x100000 - 1); > + pciauto_lower_iospc = (pciauto_lower_iospc + (0x1000 - 1)) > + & ~(0x1000 - 1); > + > + /* Set base (lower limit) of address range behind bridge. */ > + early_write_config_word(hose, top_bus, current_bus, pci_devfn, > + PCI_MEMORY_BASE, pciauto_lower_memspc >> 16); > + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, > + PCI_IO_BASE, (pciauto_lower_iospc & 0x0000f000) >> 8); > + early_write_config_word(hose, top_bus, current_bus, pci_devfn, > + PCI_IO_BASE_UPPER16, pciauto_lower_iospc >> 16); > > - /* Set up memory and I/O filter limits, assume 32-bit I/O space */ > - early_write_config_word(hose, current_bus, pci_devfn, PCI_MEMORY_LIMIT, > - ((pciauto_upper_memspc - 1) & 0xfff00000) >> 16); > - early_write_config_byte(hose, current_bus, pci_devfn, PCI_IO_LIMIT, > - ((pciauto_upper_iospc - 1) & 0x0000f000) >> 8); > - early_write_config_word(hose, current_bus, pci_devfn, > - PCI_IO_LIMIT_UPPER16, > - ((pciauto_upper_iospc - 1) & 0xffff0000) >> 16); > - > /* We don't support prefetchable memory for now, so disable */ > - early_write_config_word(hose, current_bus, pci_devfn, > - PCI_PREF_MEMORY_BASE, 0x1000); > - early_write_config_word(hose, current_bus, pci_devfn, > - PCI_PREF_MEMORY_LIMIT, 0x1000); > - > - /* Enable memory and I/O accesses, enable bus master */ > - early_read_config_dword(hose, current_bus, pci_devfn, PCI_COMMAND, > - &cmdstat); > - early_write_config_dword(hose, current_bus, pci_devfn, PCI_COMMAND, > - cmdstat | PCI_COMMAND_IO | PCI_COMMAND_MEMORY | > - PCI_COMMAND_MASTER); > + early_write_config_word(hose, top_bus, current_bus, pci_devfn, > + PCI_PREF_MEMORY_BASE, 0); > + early_write_config_word(hose, top_bus, current_bus, pci_devfn, > + PCI_PREF_MEMORY_LIMIT, 0); > } > > void __init > pciauto_postscan_setup_bridge(struct pci_channel *hose, > + int top_bus, > int current_bus, > int pci_devfn, > int sub_bus) > { > + u32 temp; > + > /* Configure bus number registers */ > - early_write_config_byte(hose, current_bus, pci_devfn, > + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, > PCI_SUBORDINATE_BUS, sub_bus); > > - /* Round memory allocator to 1MB boundary */ > - pciauto_upper_memspc &= ~(0x100000 - 1); > - early_write_config_word(hose, current_bus, pci_devfn, PCI_MEMORY_BASE, > - pciauto_upper_memspc >> 16); > - > - /* Round I/O allocator to 4KB boundary */ > - pciauto_upper_iospc &= ~(0x1000 - 1); > - early_write_config_byte(hose, current_bus, pci_devfn, PCI_IO_BASE, > - (pciauto_upper_iospc & 0x0000f000) >> 8); > - early_write_config_word(hose, current_bus, pci_devfn, > - PCI_IO_BASE_UPPER16, pciauto_upper_iospc >> 16); > + /* Set upper limit of address range behind bridge. */ > + early_write_config_word(hose, top_bus, current_bus, pci_devfn, > + PCI_MEMORY_LIMIT, pciauto_lower_memspc >> 16); > + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, > + PCI_IO_LIMIT, (pciauto_lower_iospc & 0x0000f000) >> 8); > + early_write_config_word(hose, top_bus, current_bus, pci_devfn, > + PCI_IO_LIMIT_UPPER16, pciauto_lower_iospc >> 16); > + > + /* Align memory and I/O to 1MB and 4KB boundaries. */ > + pciauto_lower_memspc = (pciauto_lower_memspc + (0x100000 - 1)) > + & ~(0x100000 - 1); > + pciauto_lower_iospc = (pciauto_lower_iospc + (0x1000 - 1)) > + & ~(0x1000 - 1); > + > + /* Enable memory and I/O accesses, enable bus master */ > + early_read_config_dword(hose, top_bus, current_bus, pci_devfn, > + PCI_COMMAND, &temp); > + early_write_config_dword(hose, top_bus, current_bus, pci_devfn, > + PCI_COMMAND, temp | PCI_COMMAND_IO | PCI_COMMAND_MEMORY > + | PCI_COMMAND_MASTER); > } > > #define PCIAUTO_IDE_MODE_MASK 0x05 > > int __init > -pciauto_bus_scan(struct pci_channel *hose, int current_bus) > +pciauto_bus_scan(struct pci_channel *hose, int top_bus, int current_bus) > { > int sub_bus; > u32 pci_devfn, pci_class, cmdstat, found_multi=0; > - unsigned short vid; > + unsigned short vid, did; > unsigned char header_type; > int devfn_start = 0; > int devfn_stop = 0xff; > @@ -223,54 +274,70 @@ > if (PCI_FUNC(pci_devfn) && !found_multi) > continue; > > - early_read_config_byte(hose, current_bus, pci_devfn, > + early_read_config_word(hose, top_bus, current_bus, pci_devfn, > + PCI_VENDOR_ID, &vid); > + > + if (vid == 0xffff) continue; > + > + early_read_config_byte(hose, top_bus, current_bus, pci_devfn, > PCI_HEADER_TYPE, &header_type); > > if (!PCI_FUNC(pci_devfn)) > found_multi = header_type & 0x80; > > - early_read_config_word(hose, current_bus, pci_devfn, > - PCI_VENDOR_ID, &vid); > + early_read_config_word(hose, top_bus, current_bus, pci_devfn, > + PCI_DEVICE_ID, &did); > > - if (vid == 0xffff) continue; > - > - early_read_config_dword(hose, current_bus, pci_devfn, > + early_read_config_dword(hose, top_bus, current_bus, pci_devfn, > PCI_CLASS_REVISION, &pci_class); > + > + DBG("%.2x:%.2x.%x Class %.4x: %.4x:%.4x", > + current_bus, PCI_SLOT(pci_devfn), PCI_FUNC(pci_devfn), > + pci_class >> 16, vid, did); > + if (pci_class & 0xff) > + DBG(" (rev %.2x)", pci_class & 0xff); > + DBG("\n"); > + > if ((pci_class >> 16) == PCI_CLASS_BRIDGE_PCI) { > - DBG("PCI Autoconfig: Found P2P bridge, device %d\n", PCI_SLOT(pci_devfn)); > - pciauto_prescan_setup_bridge(hose, current_bus, > + DBG(" Bridge: primary=%.2x, secondary=%.2x\n", > + current_bus, sub_bus + 1); > + pciauto_prescan_setup_bridge(hose, top_bus, current_bus, > pci_devfn, sub_bus); > - sub_bus = pciauto_bus_scan(hose, sub_bus+1); > - pciauto_postscan_setup_bridge(hose, current_bus, > + DBG("Scanning sub bus %.2x, I/O 0x%.8x, Mem 0x%.8x\n", > + sub_bus + 1, > + pciauto_lower_iospc, pciauto_lower_memspc); > + sub_bus = pciauto_bus_scan(hose, top_bus, sub_bus+1); > + DBG("Back to bus %.2x\n", current_bus); > + pciauto_postscan_setup_bridge(hose, top_bus, current_bus, > pci_devfn, sub_bus); > - > + continue; > } else if ((pci_class >> 16) == PCI_CLASS_STORAGE_IDE) { > > unsigned char prg_iface; > > - early_read_config_byte(hose, current_bus, pci_devfn, > - PCI_CLASS_PROG, &prg_iface); > + early_read_config_byte(hose, top_bus, current_bus, > + pci_devfn, PCI_CLASS_PROG, &prg_iface); > if (!(prg_iface & PCIAUTO_IDE_MODE_MASK)) { > - DBG("PCI Autoconfig: Skipping legacy mode IDE controller\n"); > + DBG("Skipping legacy mode IDE controller\n"); > continue; > } > } > > - /* > + /* > * Found a peripheral, enable some standard > * settings > */ > - early_read_config_dword(hose, current_bus, pci_devfn, > + early_read_config_dword(hose, top_bus, current_bus, pci_devfn, > PCI_COMMAND, &cmdstat); > - early_write_config_dword(hose, current_bus, pci_devfn, > + early_write_config_dword(hose, top_bus, current_bus, pci_devfn, > PCI_COMMAND, cmdstat | PCI_COMMAND_IO | > PCI_COMMAND_MEMORY | > PCI_COMMAND_MASTER); > - early_write_config_byte(hose, current_bus, pci_devfn, > + early_write_config_byte(hose, top_bus, current_bus, pci_devfn, > PCI_LATENCY_TIMER, 0x80); > > /* Allocate PCI I/O and/or memory space */ > - pciauto_setup_bars(hose, current_bus, pci_devfn); > + pciauto_setup_bars(hose, top_bus, current_bus, pci_devfn); > } > return sub_bus; > } > @@ -283,41 +350,9 @@ > pciauto_upper_iospc = hose->io_resource->end + 1; > pciauto_lower_memspc = hose->mem_resource->start; > pciauto_upper_memspc = hose->mem_resource->end + 1; > + DBG("Autoconfig PCI channel 0x%p\n", hose); > + DBG("Scanning bus %.2x, I/O 0x%.8x, Mem 0x%.8x\n", > + busno, pciauto_lower_iospc, pciauto_lower_memspc); > > - return pciauto_bus_scan(hose, busno); > + return pciauto_bus_scan(hose, busno, busno); > } > - > - > -/* > - * These functions are used early on before PCI scanning is done > - * and all of the pci_dev and pci_bus structures have been created. > - */ > -static struct pci_dev *fake_pci_dev(struct pci_channel *hose, int busnr, > - int devfn) > -{ > - static struct pci_dev dev; > - static struct pci_bus bus; > - > - dev.bus = &bus; > - dev.sysdata = hose; > - dev.devfn = devfn; > - bus.number = busnr; > - bus.ops = hose->pci_ops; > - > - return &dev; > -} > - > -#define EARLY_PCI_OP(rw, size, type) \ > -int early_##rw##_config_##size(struct pci_channel *hose, int bus, \ > - int devfn, int offset, type value) \ > -{ \ > - return pci_##rw##_config_##size(fake_pci_dev(hose, bus, devfn), \ > - offset, value); \ > -} > - > -EARLY_PCI_OP(read, byte, u8 *) > -EARLY_PCI_OP(read, word, u16 *) > -EARLY_PCI_OP(read, dword, u32 *) > -EARLY_PCI_OP(write, byte, u8) > -EARLY_PCI_OP(write, word, u16) > -EARLY_PCI_OP(write, dword, u32) From owner-linux-mips@oss.sgi.com Mon Oct 29 14:39:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9TMd4u21620 for linux-mips-outgoing; Mon, 29 Oct 2001 14:39:04 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9TMcv021617 for ; Mon, 29 Oct 2001 14:38:57 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9TMejB05842; Mon, 29 Oct 2001 14:40:45 -0800 Message-ID: <3BDDDA7A.329F827D@mvista.com> Date: Mon, 29 Oct 2001 14:38:50 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Bradley D. LaRonde" CC: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: PATCH: pci_auto bridge support References: <20011026210746.A20395@dev1.ltc.com> <3BDDACD2.7121F905@mvista.com> <04c801c160b0$1d62f660$3501010a@ltc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2670 Lines: 72 "Bradley D. LaRonde" wrote: > > I considered that, but since only this small chuck of run-once surrogate > bios autoconfig code needs to know, I figured better keep it separate. > I would vote to put it inside the hose structure: . It makes a workaround look like a real fix. :-) . In other implementations of pci_auto, hose is the private sys data of a pci dev. Having a bus number inside is very useful (e.g., pci_ops can tell whether it is type0 of type1 configuration based on the bus number rather than a shaky NULL parent bus pointer). In the future, all pci_auto should be combined into the pci driver. So that is probably the right direction to go. I think hose may evolve to be the data structure that represents the topology of PCI buses. It should have more uses in the future (e.g., the standard IRQ routing across PCI-PCI bridges). Jun > > ----- Original Message ----- > From: "Jun Sun" > To: "Bradley D. LaRonde" > Cc: ; > Sent: Monday, October 29, 2001 2:24 PM > Subject: Re: PATCH: pci_auto bridge support > > > > > Brad, > > > > Have you considered embedding "topbus" argument into hose structure? That > > sounds like potentially better solution. > > > > > > > > "Bradley D. LaRonde" wrote: > > > > > > 2001-10-26 Bradley D. LaRonde > > > > > > * PCI bridge support. See change log entry below. > > > > > > --- arch/mips/kernel/pci_auto.c 2001/08/18 06:21:53 1.1 > > > +++ arch/mips/kernel/pci_auto.c 2001/10/27 01:01:21 > > > @@ -4,6 +4,7 @@ > > > * Author: Matt Porter > > > * > > > * Copyright 2000, 2001 MontaVista Software Inc. > > > + * Copyright 2001 Bradley D. LaRonde > > > * > > > * 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 > > > @@ -19,6 +20,15 @@ > > > * . change most int to u32. > > > * > > > * Further modified to include it as mips generic code, > ppopov@mvista.com. > > > + * > > > + * 2001-10-26 Bradley D. LaRonde > > > + * - Add a top_bus argument to the "early config" functions so that > > > + * they can set a fake parent bus pointer to convince the underlying > > > + * pci ops to use type 1 configuration for sub busses. > > > + * - Set bridge base and limit registers correctly. > > > + * - Align io and memory base properly before and after bridge setup. > > > + * - Don't fall through to pci_setup_bars for bridge. > > > + * - Reformat the debug output to look more like lspci's output. > > > */ From owner-linux-mips@oss.sgi.com Mon Oct 29 16:00:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U00Re27689 for linux-mips-outgoing; Mon, 29 Oct 2001 16:00:27 -0800 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U00L027686 for ; Mon, 29 Oct 2001 16:00:22 -0800 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 5559E590AC; Mon, 29 Oct 2001 14:57:11 -0500 (EST) Message-ID: <066201c160d5$eb51ed40$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Jun Sun" Cc: , References: <20011026210746.A20395@dev1.ltc.com> <3BDDACD2.7121F905@mvista.com> <04c801c160b0$1d62f660$3501010a@ltc.com> <3BDDDA7A.329F827D@mvista.com> Subject: Re: [Linux-mips-kernel]Re: PATCH: pci_auto bridge support Date: Mon, 29 Oct 2001 19:00:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1656 Lines: 48 ----- Original Message ----- From: "Jun Sun" To: "Bradley D. LaRonde" Cc: ; Sent: Monday, October 29, 2001 5:38 PM Subject: [Linux-mips-kernel]Re: PATCH: pci_auto bridge support > "Bradley D. LaRonde" wrote: > > > > I considered that, but since only this small chuck of run-once surrogate > > bios autoconfig code needs to know, I figured better keep it separate. > > > > I would vote to put it inside the hose structure: > > . It makes a workaround look like a real fix. :-) > > . In other implementations of pci_auto, hose is the private sys data of a pci > dev. Having a bus number inside is very useful (e.g., pci_ops can tell whether > it is type0 of type1 configuration based on the bus number rather than a shaky > NULL parent bus pointer). In the future, all pci_auto should be combined into > the pci driver. So that is probably the right direction to go. > > I think hose may evolve to be the data structure that represents the topology > of PCI buses. It should have more uses in the future (e.g., the standard IRQ > routing across PCI-PCI bridges). Isn't the bus topology already adequately represented in the pci_dev and pci_channel structures? I look at the pci autoconfig stuff as a bios replacement. The fact that we can use some of the same structures and functions to help us implement it is a bonus, but not a mandate to mess with the existing model. Isn't Linux already handling PCI-PCI bridges and multiple PCI channles fine already, or has our autoconfig code exposed some existing non-arch-specific weakness? Regards, Brad From owner-linux-mips@oss.sgi.com Mon Oct 29 16:17:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U0HlE28005 for linux-mips-outgoing; Mon, 29 Oct 2001 16:17:47 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U0HZ027994; Mon, 29 Oct 2001 16:17:35 -0800 Received: from mvista.com (IDENT:ahennessy@penelope.mvista.com [10.0.0.122]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9U0JLB12067; Mon, 29 Oct 2001 16:19:21 -0800 Message-ID: <3BDDF193.B6405A7F@mvista.com> Date: Mon, 29 Oct 2001 16:17:23 -0800 From: Alice Hennessy X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: Carsten Langgaard CC: Atsushi Nemoto , ralf@oss.sgi.com, ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3201 Lines: 78 Carsten Langgaard wrote: > This doesn't look right, you still need to enable the CU1 bit in the status register to let the FP > emulator kick-in. > FPU-less CPUs should take a coprocessor unusable exception on any floating-point instructions. > I have been running this on several FPU-less CPUs, and it works fine for me. Maybe the FPU-less CPUs you have been using define the CU1 bit as reserved or is unused (ignore on write, zero on read)? The TX3927 actually allows the setting of the CU1 bit. Have you seen a case where you need to set the CU1 bit for the emulation to kick-in? I would think that the CU1 bit should never be set to one for FPU-less CPUs. Alice > > > Actually there is a problem with this code on CPUs, which have a FPU. The problem is that a lot of > CPUs have a CP0 hazard of 4 nops, between setting the CU1 bit in the status register and executing > the first floating point instruction thereafter. It probably only a performance issue, because if > the setting of CU1 hasn't taken effect yet, then we get a coprocessor unusable exception and the > the exception handler will also set the CU1 bit. > > /Carsten > > Atsushi Nemoto wrote: > > > >>>>> On Fri, 26 Oct 2001 22:58:06 +0900 (JST), Atsushi Nemoto said: > > nemoto> I have seen TX39 dead on "cfc1" insturuction if STATUS.CU1 bit > > nemoto> enabled. Such codes were in arch/mips/kernel/process.c. > > > > So, please apply this patch to CVS for TX39XX support. > > > > I use CONFIG_CPU_TX39XX in this patch, but I suppose other FPU-less > > CPUs may need this also. > > > > Does anybody know how about on other CPUs? > > > > diff -u linux-sgi-cvs/arch/mips/kernel/process.c linux.new/arch/mips/kernel/ > > --- linux-sgi-cvs/arch/mips/kernel/process.c Mon Oct 22 10:29:56 2001 > > +++ linux.new/arch/mips/kernel/process.c Mon Oct 29 15:49:37 2001 > > @@ -57,6 +57,12 @@ > > { > > /* Forget lazy fpu state */ > > if (last_task_used_math == current) { > > +#ifdef CONFIG_CPU_TX39XX > > + if (!(mips_cpu.options & MIPS_CPU_FPU)) { > > + last_task_used_math = NULL; > > + return; > > + } > > +#endif > > set_cp0_status(ST0_CU1); > > __asm__ __volatile__("cfc1\t$0,$31"); > > last_task_used_math = NULL; > > @@ -67,6 +73,12 @@ > > { > > /* Forget lazy fpu state */ > > if (last_task_used_math == current) { > > +#ifdef CONFIG_CPU_TX39XX > > + if (!(mips_cpu.options & MIPS_CPU_FPU)) { > > + last_task_used_math = NULL; > > + return; > > + } > > +#endif > > set_cp0_status(ST0_CU1); > > __asm__ __volatile__("cfc1\t$0,$31"); > > last_task_used_math = NULL; > > --- > > Atsushi Nemoto > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Oct 29 16:19:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U0JxO28093 for linux-mips-outgoing; Mon, 29 Oct 2001 16:19:59 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U0Jr028089 for ; Mon, 29 Oct 2001 16:19:53 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9U0LfB12216; Mon, 29 Oct 2001 16:21:41 -0800 Message-ID: <3BDDF222.56105220@mvista.com> Date: Mon, 29 Oct 2001 16:19:46 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Bradley D. LaRonde" CC: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: PATCH: pci_auto bridge support References: <20011026210746.A20395@dev1.ltc.com> <3BDDACD2.7121F905@mvista.com> <04c801c160b0$1d62f660$3501010a@ltc.com> <3BDDDA7A.329F827D@mvista.com> <066201c160d5$eb51ed40$3501010a@ltc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2276 Lines: 63 "Bradley D. LaRonde" wrote: > > ----- Original Message ----- > From: "Jun Sun" > To: "Bradley D. LaRonde" > Cc: ; > Sent: Monday, October 29, 2001 5:38 PM > Subject: [Linux-mips-kernel]Re: PATCH: pci_auto bridge support > > > "Bradley D. LaRonde" wrote: > > > > > > I considered that, but since only this small chuck of run-once surrogate > > > bios autoconfig code needs to know, I figured better keep it separate. > > > > > > > I would vote to put it inside the hose structure: > > > > . It makes a workaround look like a real fix. :-) > > > > . In other implementations of pci_auto, hose is the private sys data of a > pci > > dev. Having a bus number inside is very useful (e.g., pci_ops can tell > whether > > it is type0 of type1 configuration based on the bus number rather than a > shaky > > NULL parent bus pointer). In the future, all pci_auto should be combined > into > > the pci driver. So that is probably the right direction to go. > > > > I think hose may evolve to be the data structure that represents the > topology > > of PCI buses. It should have more uses in the future (e.g., the standard > IRQ > > routing across PCI-PCI bridges). > > Isn't the bus topology already adequately represented in the pci_dev and > pci_channel structures? > Not really. For example, we don't know which bus is the sub-bus of which, directly, and how their address space translate into each other. Those data structures are needed when we start to support dynamically mapped and/or arbitrarily mapped PCI memory spaces. > I look at the pci autoconfig stuff as a bios replacement. The fact that we > can use some of the same structures and functions to help us implement it is > a bonus, but not a mandate to mess with the existing model. > That is a right point. I might be too far ahead of myself. :-) > Isn't Linux already handling PCI-PCI bridges and multiple PCI channles fine > already, or has our autoconfig code exposed some existing non-arch-specific > weakness? > I think on PCs, P2P still largely depends on BIOS. (Correct me if I am wrong). There are some post-scan_bus() mechanism to setup P2P bridges. I have not looked into it closely. Jun From owner-linux-mips@oss.sgi.com Mon Oct 29 16:33:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U0XEo28392 for linux-mips-outgoing; Mon, 29 Oct 2001 16:33:14 -0800 Received: from dea.linux-mips.net (a1as03-p77.stg.tli.de [195.252.186.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U0X7028389 for ; Mon, 29 Oct 2001 16:33:10 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9U0WNU06841; Tue, 30 Oct 2001 01:32:23 +0100 Date: Tue, 30 Oct 2001 01:32:23 +0100 From: Ralf Baechle To: Alice Hennessy Cc: Carsten Langgaard , Atsushi Nemoto , ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. Message-ID: <20011030013223.B6614@dea.linux-mips.net> References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> <3BDDF193.B6405A7F@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: <3BDDF193.B6405A7F@mvista.com>; from ahennessy@mvista.com on Mon, Oct 29, 2001 at 04:17:23PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1202 Lines: 23 On Mon, Oct 29, 2001 at 04:17:23PM -0800, Alice Hennessy wrote: > > This doesn't look right, you still need to enable the CU1 bit in the > > status register to let the FP emulator kick-in. FPU-less CPUs should > > take a coprocessor unusable exception on any floating-point instructions. > > I have been running this on several FPU-less CPUs, and it works fine for > me. > > Maybe the FPU-less CPUs you have been using define the CU1 bit as reserved > or is unused (ignore on write, zero on read)? The TX3927 actually allows > the setting of the CU1 bit. Have you seen a case where you need to set > the CU1 bit for the emulation to kick-in? I would think that the CU1 > bit should never be set to one for FPU-less CPUs. There are subtle differences in how CUx bits for unimplemented coprocessors are handled in the various processors. MIPS32 and MIPS64 specifies the behaviour as 0 on read, writes ignored; previous processors such as the R4000 handled this differently and as a consequence a fp instruction on a fpu-less r4000 class cpu may either throw a CU or a reserved instruction exception. To make things easier for everybody this is documented in the R10000 user's manual ... Ralf From owner-linux-mips@oss.sgi.com Mon Oct 29 18:26:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U2Q5T30428 for linux-mips-outgoing; Mon, 29 Oct 2001 18:26:05 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U2Pv030425; Mon, 29 Oct 2001 18:25:57 -0800 Received: from mvista.com (IDENT:ahennessy@penelope.mvista.com [10.0.0.122]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9U2RkB18788; Mon, 29 Oct 2001 18:27:46 -0800 Message-ID: <3BDE0FAF.1E3556A9@mvista.com> Date: Mon, 29 Oct 2001 18:25:51 -0800 From: Alice Hennessy X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Carsten Langgaard , Atsushi Nemoto , ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> <3BDDF193.B6405A7F@mvista.com> <20011030013223.B6614@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1514 Lines: 36 Ralf Baechle wrote: > On Mon, Oct 29, 2001 at 04:17:23PM -0800, Alice Hennessy wrote: > > > > This doesn't look right, you still need to enable the CU1 bit in the > > > status register to let the FP emulator kick-in. FPU-less CPUs should > > > take a coprocessor unusable exception on any floating-point instructions. > > > I have been running this on several FPU-less CPUs, and it works fine for > > me. > > > > Maybe the FPU-less CPUs you have been using define the CU1 bit as reserved > > or is unused (ignore on write, zero on read)? The TX3927 actually allows > > the setting of the CU1 bit. Have you seen a case where you need to set > > the CU1 bit for the emulation to kick-in? I would think that the CU1 > > bit should never be set to one for FPU-less CPUs. > > There are subtle differences in how CUx bits for unimplemented coprocessors > are handled in the various processors. MIPS32 and MIPS64 specifies the > behaviour as 0 on read, writes ignored; previous processors such as the > R4000 handled this differently and as a consequence a fp instruction on > a fpu-less r4000 class cpu may either throw a CU or a reserved instruction > exception. To make things easier for everybody this is documented in the > R10000 user's manual ... > > Ralf So, we should not set CU1 generically for FPU-less CPUs especially since a known problem exists for the tx3927? Ie, qualify all setting of CU1 as follows: if (mips_cpu.options & MIPS_CPU_FPU) set_cp0_status(ST0_CU1); Alice From owner-linux-mips@oss.sgi.com Mon Oct 29 18:28:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U2SLJ30528 for linux-mips-outgoing; Mon, 29 Oct 2001 18:28:21 -0800 Received: from dea.linux-mips.net (a1as03-p77.stg.tli.de [195.252.186.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U2SG030524 for ; Mon, 29 Oct 2001 18:28:17 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9U2SDA07769 for linux-mips@oss.sgi.com; Tue, 30 Oct 2001 03:28:13 +0100 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U1kb029778 for ; Mon, 29 Oct 2001 17:46:37 -0800 Received: from mvista.com (IDENT:ahennessy@penelope.mvista.com [10.0.0.122]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9U1mNB16946; Mon, 29 Oct 2001 17:48:24 -0800 Message-ID: <3BDE0673.20F5C29D@mvista.com> Date: Mon, 29 Oct 2001 17:46:27 -0800 From: Alice Hennessy X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: Atsushi Nemoto CC: "linux-mips@oss.sgi.com" , "carstenl@mips.com" , ahennessy@mvista.com, ajob4me@21cn.com Subject: Re: other info about Toshiba TX3927 board boot problem. References: <200110290956.f9T9uc028676@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1459 Lines: 43 8route wrote: > Dear Atsushi: > Hi! > I found the reset switch on the TX3927 board can work if you switch it > against the PCI interface when > ================================== > VFS: Mounted root (NFS filesystem). > Freeing unused kernel memory: 44k freed > ======================================== > ,usually I switch it towards the PCI interface. > > And I have fixed the source code of process.c as you said. > >For TX3927, you must skip those two lines in exit_thread() and > >flush_thread(). > > > > set_cp0_status(ST0_CU1, ST0_CU1); > > __asm__ __volatile__("cfc1\t$0,$31"); > > > > > But the problem still exists.The serial console output will stop at > ================================== > VFS: Mounted root (NFS filesystem). > Freeing unused kernel memory: 44k freed > ======================================== > > I think that maybe the Linux system has booted up OK,but there is > something wrong with the serial console because serial ports are integrated > with TX3927.Do you agree?Please consider it in your latest patch. > >By the way, now I'm planning to send patches for TX CPU boards > >(including JMR3927) to oss.sgi.com. If you can wait a while, you can > >try it. > Thank you very much. > > 8route > ajob4me@21cn.com > 10/29/2001 I have already submitted a patch to Ralf for the JMR3927 and am waiting for his reply. We should coordinate to make sure we don't overwrite each other. Alice From owner-linux-mips@oss.sgi.com Mon Oct 29 19:09:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U39Nn31160 for linux-mips-outgoing; Mon, 29 Oct 2001 19:09:23 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U39G031157; Mon, 29 Oct 2001 19:09:16 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 30 Oct 2001 03:09:16 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 1ED97B46D; Tue, 30 Oct 2001 12:09:15 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id MAA35555; Tue, 30 Oct 2001 12:09:14 +0900 (JST) Date: Tue, 30 Oct 2001 12:14:03 +0900 (JST) Message-Id: <20011030.121403.41626778.nemoto@toshiba-tops.co.jp> To: ahennessy@mvista.com Cc: carstenl@mips.com, ralf@oss.sgi.com, ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. From: Atsushi Nemoto In-Reply-To: <3BDDF193.B6405A7F@mvista.com> References: <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> <3BDDF193.B6405A7F@mvista.com> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 406 Lines: 12 >>>>> On Mon, 29 Oct 2001 16:17:23 -0800, Alice Hennessy said: ahennessy> I would think that the CU1 bit should never be set to one ahennessy> for FPU-less CPUs. I think so too. Talking about TX3927, When I tried, TX3927 did NOT raise any exception on cp1 instruction if CU1 bit enabled. The CPU just locked there. So some workaround is necessary for TX3927. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue Oct 30 00:20:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U8KbG04752 for linux-mips-outgoing; Tue, 30 Oct 2001 00:20:37 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U8KP004746; Tue, 30 Oct 2001 00:20:25 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA19420; Tue, 30 Oct 2001 00:20:09 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA02581; Tue, 30 Oct 2001 00:20:08 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f9U8K4a27880; Tue, 30 Oct 2001 09:20:06 +0100 (MET) Message-ID: <3BDE62B4.BE7A1885@mips.com> Date: Tue, 30 Oct 2001 09:20:04 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alice Hennessy CC: Atsushi Nemoto , ralf@oss.sgi.com, ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> <3BDDF193.B6405A7F@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3969 Lines: 95 Alice Hennessy wrote: > Carsten Langgaard wrote: > > > This doesn't look right, you still need to enable the CU1 bit in the status register to let the FP > > emulator kick-in. > > FPU-less CPUs should take a coprocessor unusable exception on any floating-point instructions. > > I have been running this on several FPU-less CPUs, and it works fine for me. > > Maybe the FPU-less CPUs you have been using define the CU1 bit as reserved > or is unused (ignore on write, zero on read)? The TX3927 actually allows the setting of the CU1 bit. > Have you seen > a case where you need to set the CU1 bit for the emulation to kick-in? I would think that the CU1 > bit should > never be set to one for FPU-less CPUs. You are right, you don't need to set the CU1 bit for the emulator to kick-in (you just need a coprocessor unusable exception), sorry my mistake. So generally I think we should use the check against a FPU present (mips_cpu.options & MIPS_CPU_FPU), instead of the TX39XX specific fix. > > Alice > > > > > > > Actually there is a problem with this code on CPUs, which have a FPU. The problem is that a lot of > > CPUs have a CP0 hazard of 4 nops, between setting the CU1 bit in the status register and executing > > the first floating point instruction thereafter. It probably only a performance issue, because if > > the setting of CU1 hasn't taken effect yet, then we get a coprocessor unusable exception and the > > the exception handler will also set the CU1 bit. > > > > /Carsten > > > > Atsushi Nemoto wrote: > > > > > >>>>> On Fri, 26 Oct 2001 22:58:06 +0900 (JST), Atsushi Nemoto said: > > > nemoto> I have seen TX39 dead on "cfc1" insturuction if STATUS.CU1 bit > > > nemoto> enabled. Such codes were in arch/mips/kernel/process.c. > > > > > > So, please apply this patch to CVS for TX39XX support. > > > > > > I use CONFIG_CPU_TX39XX in this patch, but I suppose other FPU-less > > > CPUs may need this also. > > > > > > Does anybody know how about on other CPUs? > > > > > > diff -u linux-sgi-cvs/arch/mips/kernel/process.c linux.new/arch/mips/kernel/ > > > --- linux-sgi-cvs/arch/mips/kernel/process.c Mon Oct 22 10:29:56 2001 > > > +++ linux.new/arch/mips/kernel/process.c Mon Oct 29 15:49:37 2001 > > > @@ -57,6 +57,12 @@ > > > { > > > /* Forget lazy fpu state */ > > > if (last_task_used_math == current) { > > > +#ifdef CONFIG_CPU_TX39XX > > > + if (!(mips_cpu.options & MIPS_CPU_FPU)) { > > > + last_task_used_math = NULL; > > > + return; > > > + } > > > +#endif > > > set_cp0_status(ST0_CU1); > > > __asm__ __volatile__("cfc1\t$0,$31"); > > > last_task_used_math = NULL; > > > @@ -67,6 +73,12 @@ > > > { > > > /* Forget lazy fpu state */ > > > if (last_task_used_math == current) { > > > +#ifdef CONFIG_CPU_TX39XX > > > + if (!(mips_cpu.options & MIPS_CPU_FPU)) { > > > + last_task_used_math = NULL; > > > + return; > > > + } > > > +#endif > > > set_cp0_status(ST0_CU1); > > > __asm__ __volatile__("cfc1\t$0,$31"); > > > last_task_used_math = NULL; > > > --- > > > Atsushi Nemoto > > > > -- > > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > > Denmark http://www.mips.com -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Oct 30 00:36:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U8aZJ05123 for linux-mips-outgoing; Tue, 30 Oct 2001 00:36:35 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U8aS005118; Tue, 30 Oct 2001 00:36:28 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA19555; Tue, 30 Oct 2001 00:36:18 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA02764; Tue, 30 Oct 2001 00:36:18 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f9U8a2a28619; Tue, 30 Oct 2001 09:36:17 +0100 (MET) Message-ID: <3BDE6671.7776CB4B@mips.com> Date: Tue, 30 Oct 2001 09:36:01 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alice Hennessy CC: Ralf Baechle , Atsushi Nemoto , ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> <3BDDF193.B6405A7F@mvista.com> <20011030013223.B6614@dea.linux-mips.net> <3BDE0FAF.1E3556A9@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2109 Lines: 52 Alice Hennessy wrote: > Ralf Baechle wrote: > > > On Mon, Oct 29, 2001 at 04:17:23PM -0800, Alice Hennessy wrote: > > > > > > This doesn't look right, you still need to enable the CU1 bit in the > > > > status register to let the FP emulator kick-in. FPU-less CPUs should > > > > take a coprocessor unusable exception on any floating-point instructions. > > > > I have been running this on several FPU-less CPUs, and it works fine for > > > me. > > > > > > Maybe the FPU-less CPUs you have been using define the CU1 bit as reserved > > > or is unused (ignore on write, zero on read)? The TX3927 actually allows > > > the setting of the CU1 bit. Have you seen a case where you need to set > > > the CU1 bit for the emulation to kick-in? I would think that the CU1 > > > bit should never be set to one for FPU-less CPUs. > > > > There are subtle differences in how CUx bits for unimplemented coprocessors > > are handled in the various processors. MIPS32 and MIPS64 specifies the > > behaviour as 0 on read, writes ignored; previous processors such as the > > R4000 handled this differently and as a consequence a fp instruction on > > a fpu-less r4000 class cpu may either throw a CU or a reserved instruction > > exception. To make things easier for everybody this is documented in the > > R10000 user's manual ... > > > > Ralf > > So, we should not set CU1 generically for FPU-less CPUs especially since a > known problem exists > for the tx3927? Ie, qualify all setting of CU1 as follows: > > if (mips_cpu.options & MIPS_CPU_FPU) > set_cp0_status(ST0_CU1); And while we are at it, could we handle the CP0 hazard of 4 nops, between setting the CU1 bit in the status register and executing the first floating point instruction, on CPU which got a FPU. > > > Alice -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Oct 30 01:17:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9U9HVJ14283 for linux-mips-outgoing; Tue, 30 Oct 2001 01:17:31 -0800 Received: from dea.linux-mips.net (a1as08-p129.stg.tli.de [195.252.188.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9U9HQ014280 for ; Tue, 30 Oct 2001 01:17:27 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9U9H9E09362; Tue, 30 Oct 2001 10:17:09 +0100 Date: Tue, 30 Oct 2001 10:17:09 +0100 From: Ralf Baechle To: tommy.christensen@eicon.com Cc: linux-mips@oss.sgi.com Subject: Re: Fixup in unaligned.c Message-ID: <20011030101709.A3816@dea.linux-mips.net> References: <3BDD5B31.E12DE812@eicon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BDD5B31.E12DE812@eicon.com>; from tommy.christensen@eicon.com on Mon, Oct 29, 2001 at 02:35:45PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1031 Lines: 22 On Mon, Oct 29, 2001 at 02:35:45PM +0100, tommy.christensen@eicon.com wrote: > It seems we don't always handle bad user-mode pointers correctly. > If put_user is called with an unmapped AND unaligned address it > kills the current process instead of returning EFAULT. > > The reason for this is that we do compute_return_epc() in do_ade() > before the exception table is searched, so we never get a match. The missplaced branch emulation is a known problem in basically all of our execption handers that have to emulate branches in software. It also effects ptrace; it is possible that a debugger already observes the new epc after the branch has been executed but the instruction in the delay slow wasn't due to some problem like a page fault. > Below is a simple patch to fix it (attached as well). > The second part is not related, but it makes sense to only consult > the MF_FIXADE flag on exceptions originating from user-mode, right? That's actually an evil one from which local DoS attacks can be constructed. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 30 02:55:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UAtNs16303 for linux-mips-outgoing; Tue, 30 Oct 2001 02:55:23 -0800 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UAtH016300 for ; Tue, 30 Oct 2001 02:55:18 -0800 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 9563A2B489; Tue, 30 Oct 2001 10:55:11 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id B73D3C8CA; Tue, 30 Oct 2001 10:55:10 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id B57F7E826; Tue, 30 Oct 2001 10:55:10 +0000 (GMT) Date: Tue, 30 Oct 2001 10:55:10 +0000 (GMT) From: Dave Airlie X-X-Sender: To: Cc: , Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1600 Lines: 43 Hi, I'll try and get it some VAX time at home over the next couple of days... Dave. On Mon, 29 Oct 2001, Maciej W. Rozycki wrote: > Hi, > > I've made a preliminary version of mopd with ELF support available. It's > Mats O. Jansson's mopd 2.5.3 with several fixes, updates and enhancements. > The work is definitely not finished, but basic functionality is already > implemented. I'm making it available due to the amount of PITA > maintenance of traditional mopd image formats incurs, in hope someone will > find it useful. Libelf is required for this version of mopd. It should > build and run on any Linux system, regardless of endianness. It might > work on other systems as well. > > I've made RPM packages available at the usual place (i.e. > 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'). Beside source packages there are > i386 and mipsel binary ones available. Grab the latest version; olders > are for a reference only. To aid people with no RPM support in their > systems I've unpacked the source package into the "mopd" directory. Still > you need to study the .spec file to figure how to build binaries. > > Any feedback will be appreciated; I'm especially interested in reports > from VAX users, as I've only been able to verify the operation booting > Linux on a DECstation 5000 (i.e. MIPS) system. Note: this version of mopd > does not require switching devices into the PROMISC or ALLMULTI modes of > operation. > > Maciej > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Tue Oct 30 06:14:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UEE1422888 for linux-mips-outgoing; Tue, 30 Oct 2001 06:14:01 -0800 Received: from dea.linux-mips.net (a1as06-p248.stg.tli.de [195.252.187.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UEDu022885 for ; Tue, 30 Oct 2001 06:13:56 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9UED8624335; Tue, 30 Oct 2001 15:13:08 +0100 Date: Tue, 30 Oct 2001 15:13:08 +0100 From: Ralf Baechle To: Carsten Langgaard Cc: Alice Hennessy , Atsushi Nemoto , ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. Message-ID: <20011030151308.B10165@dea.linux-mips.net> References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> <3BDDF193.B6405A7F@mvista.com> <20011030013223.B6614@dea.linux-mips.net> <3BDE0FAF.1E3556A9@mvista.com> <3BDE6671.7776CB4B@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BDE6671.7776CB4B@mips.com>; from carstenl@mips.com on Tue, Oct 30, 2001 at 09:36:01AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 670 Lines: 19 On Tue, Oct 30, 2001 at 09:36:01AM +0100, Carsten Langgaard wrote: > > So, we should not set CU1 generically for FPU-less CPUs especially since a > > known problem exists > > for the tx3927? Ie, qualify all setting of CU1 as follows: > > > > if (mips_cpu.options & MIPS_CPU_FPU) > > set_cp0_status(ST0_CU1); > > And while we are at it, could we handle the CP0 hazard of 4 nops, between > setting the CU1 bit in the status register and executing > the first floating point instruction, on CPU which got a FPU. Which CPUs actually need four nops? Just working on a patch; I found a bunch more place where we were playing with the CU1 bit. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 30 06:17:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UEHWG23053 for linux-mips-outgoing; Tue, 30 Oct 2001 06:17:32 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UEHR023046; Tue, 30 Oct 2001 06:17:27 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA22586; Tue, 30 Oct 2001 06:17:20 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA06825; Tue, 30 Oct 2001 06:17:18 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f9UEHIa22110; Tue, 30 Oct 2001 15:17:18 +0100 (MET) Message-ID: <3BDEB66E.AFD71BBA@mips.com> Date: Tue, 30 Oct 2001 15:17:18 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Alice Hennessy , Atsushi Nemoto , ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> <3BDDF193.B6405A7F@mvista.com> <20011030013223.B6614@dea.linux-mips.net> <3BDE0FAF.1E3556A9@mvista.com> <3BDE6671.7776CB4B@mips.com> <20011030151308.B10165@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1071 Lines: 34 Ralf Baechle wrote: > On Tue, Oct 30, 2001 at 09:36:01AM +0100, Carsten Langgaard wrote: > > > > So, we should not set CU1 generically for FPU-less CPUs especially since a > > > known problem exists > > > for the tx3927? Ie, qualify all setting of CU1 as follows: > > > > > > if (mips_cpu.options & MIPS_CPU_FPU) > > > set_cp0_status(ST0_CU1); > > > > And while we are at it, could we handle the CP0 hazard of 4 nops, between > > setting the CU1 bit in the status register and executing > > the first floating point instruction, on CPU which got a FPU. > > Which CPUs actually need four nops? > > Just working on a patch; I found a bunch more place where we were playing > with the CU1 bit. The MIPS32 spec specify 4 nops. > > Ralf -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Oct 30 06:21:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UELD723177 for linux-mips-outgoing; Tue, 30 Oct 2001 06:21:13 -0800 Received: from hood.tvd.be (hood.tvd.be [195.162.196.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UELA023174 for ; Tue, 30 Oct 2001 06:21:10 -0800 Received: from Chickadee (cable-213-132-155-161.upc.chello.be [213.132.155.161]) by hood.tvd.be (8.9.3/8.9.3/RELAY-1.1) with ESMTP id PAA24475 for ; Tue, 30 Oct 2001 15:20:39 +0100 (MET) Received: from kristof by Chickadee with local (Exim 3.12 #1 (Debian)) id 15yZjt-0000a0-00 for ; Tue, 30 Oct 2001 15:19:37 +0100 Date: Tue, 30 Oct 2001 15:19:37 +0100 From: Kristof Vanbecelaere To: linux-mips@oss.sgi.com Subject: cross development tools Message-ID: <20011030151936.B1603@Chickadee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1095 Lines: 27 Hi, A while ago H.J. Lu adviced to use -march/-mtune instead of -mcpu options. But I wonder which front-end you need to use? It looks like gcc-3.0.2 lists the option as a target-specific one but does not accept it when you pass it. I then decided to track down the port H.J. made and found it on the ftp server but only in rpm form. I run a debian host for development. I assume/hope the binaries will probably run on my host if only I could get to their content. I know about alien but the version of rpm (3.0.3) on my host does not accept the rpm packages from the ftp site: only packages with major numbers <= 3 are supported by this version of RPM And a newer version of rpm is available but in rpm form. A bit of a problem. Why this bias towards Red Hat? Why not just tar files? Also, I notice the compiler in H.J.'s port is something like gcc-2.96.something. Assuming this is also the version of the cross-compiler, how come I don't see this release on the official gcc web page? How do his tools relate to the gcc releases? I may be missing some historical background here, Kristof From owner-linux-mips@oss.sgi.com Tue Oct 30 06:36:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UEaec23675 for linux-mips-outgoing; Tue, 30 Oct 2001 06:36:40 -0800 Received: from web13406.mail.yahoo.com (web13406.mail.yahoo.com [216.136.175.64]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UEad023672 for ; Tue, 30 Oct 2001 06:36:39 -0800 Message-ID: <20011030143639.59808.qmail@web13406.mail.yahoo.com> Received: from [194.201.166.113] by web13406.mail.yahoo.com via HTTP; Tue, 30 Oct 2001 14:36:39 GMT Date: Tue, 30 Oct 2001 14:36:39 +0000 (GMT) From: =?iso-8859-1?q?Zoon?= Subject: info - subscribe To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 186 Lines: 7 ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd. From owner-linux-mips@oss.sgi.com Tue Oct 30 07:57:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UFvNd28881 for linux-mips-outgoing; Tue, 30 Oct 2001 07:57:23 -0800 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UFvJ028878 for ; Tue, 30 Oct 2001 07:57:19 -0800 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id f9UFvFW11756; Tue, 30 Oct 2001 10:57:15 -0500 Date: Tue, 30 Oct 2001 10:57:14 -0500 From: Jim Paris To: Kristof Vanbecelaere Cc: linux-mips@oss.sgi.com Subject: Re: cross development tools Message-ID: <20011030105714.A11683@neurosis.mit.edu> Reply-To: jim@jtan.com References: <20011030151936.B1603@Chickadee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011030151936.B1603@Chickadee>; from kristof.vanbecelaere@sonycom.com on Tue, Oct 30, 2001 at 03:19:37PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1680 Lines: 38 > A while ago H.J. Lu adviced to use -march/-mtune instead of -mcpu > options. But I wonder which front-end you need to use? It looks like > gcc-3.0.2 lists the option as a target-specific one but does not > accept it when you pass it. I use gcc-3.0.2, which as you say does not support -march, but I found that with the latest binutils + the new -march/-mipsN patch at http://sources.redhat.com/ml/binutils/2001-10/msg00526.html a GCCFLAGS of -mips2 -wa,-m4100,--trap does a good job of letting the compiler generate mips2 while still letting me use 4100-specific instructions in inline assembly (for example). > Also, I notice the compiler in H.J.'s port is something like > gcc-2.96.something. Assuming this is also the version of the > cross-compiler, how come I don't see this release on the official gcc > web page? How do his tools relate to the gcc releases? I think the general background is something like this: - GCC released gcc-2.95, so their CVS incremented to 2.96 - RedHat distributed the CVS version of GCC, and called it gcc-2.96 - GCC incremented their CVS version again to 2.97 to attempt to clear up the confusion - RedHat's version maybe incremented to 2.97 at some point? RedHat always throws on a ton of patches on top of released stuff, and H.J. added lots more MIPS-related patches, so his port is basically a CVS snapshot + tons of general and MIPS-specific patches. I once went through the trouble of extracting the RPM and building a .tar.gz that included all of the patches, but it didn't seem to behave any differently from my point of view than gcc-3.0.2, so I'm using that instead. I can send you this .tar.gz if you'd like. -jim From owner-linux-mips@oss.sgi.com Tue Oct 30 09:03:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UH3Yh30857 for linux-mips-outgoing; Tue, 30 Oct 2001 09:03:34 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UGx7030715 for ; Tue, 30 Oct 2001 08:59:07 -0800 Received: from dea.linux-mips.net (a1as02-p234.stg.tli.de [195.252.185.234]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA00162 for ; Tue, 30 Oct 2001 08:58:36 -0800 (PST) mail_from (ralf@linux-mips.net) Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9UEtXZ32020; Tue, 30 Oct 2001 15:55:33 +0100 Date: Tue, 30 Oct 2001 15:55:33 +0100 From: Ralf Baechle To: Carsten Langgaard Cc: Alice Hennessy , Atsushi Nemoto , ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. Message-ID: <20011030155533.A28550@dea.linux-mips.net> References: <20011026095319.1C4BBB474@topsms.toshiba-tops.co.jp> <20011026.225806.63990588.nemoto@toshiba-tops.co.jp> <20011029.160225.59648095.nemoto@toshiba-tops.co.jp> <3BDD140E.432D795B@mips.com> <3BDDF193.B6405A7F@mvista.com> <3BDE62B4.BE7A1885@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BDE62B4.BE7A1885@mips.com>; from carstenl@mips.com on Tue, Oct 30, 2001 at 09:20:04AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 27263 Lines: 1116 On Tue, Oct 30, 2001 at 09:20:04AM +0100, Carsten Langgaard wrote: > You are right, you don't need to set the CU1 bit for the emulator to kick-in > (you just need a coprocessor unusable exception), sorry my mistake. > So generally I think we should use the check against a FPU present > (mips_cpu.options & MIPS_CPU_FPU), instead of the TX39XX specific fix. So here is a preliminiary version of my patch. Still untested and needs to be applied to mips64 also. Ralf Index: arch/mips/kernel/process.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips/kernel/process.c,v retrieving revision 1.31 diff -u -r1.31 process.c --- arch/mips/kernel/process.c 2001/10/19 01:23:37 1.31 +++ arch/mips/kernel/process.c 2001/10/30 14:46:30 @@ -56,8 +56,8 @@ void exit_thread(void) { /* Forget lazy fpu state */ - if (last_task_used_math == current) { - set_cp0_status(ST0_CU1); + if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) { + __enable_fpu(); __asm__ __volatile__("cfc1\t$0,$31"); last_task_used_math = NULL; } @@ -66,8 +66,8 @@ void flush_thread(void) { /* Forget lazy fpu state */ - if (last_task_used_math == current) { - set_cp0_status(ST0_CU1); + if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) { + __enable_fpu(); __asm__ __volatile__("cfc1\t$0,$31"); last_task_used_math = NULL; } @@ -85,7 +85,7 @@ if (last_task_used_math == current) if (mips_cpu.options & MIPS_CPU_FPU) { - set_cp0_status(ST0_CU1); + __enable_fpu(); save_fp(p); } /* set up new TSS. */ Index: arch/mips/kernel/ptrace.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips/kernel/ptrace.c,v retrieving revision 1.32 diff -u -r1.32 ptrace.c --- arch/mips/kernel/ptrace.c 2001/10/19 01:23:37 1.32 +++ arch/mips/kernel/ptrace.c 2001/10/30 14:46:30 @@ -20,7 +20,6 @@ #include #include -#include #include #include #include @@ -126,9 +125,9 @@ child->thread.fpu.soft.regs; } else if (last_task_used_math == child) { - enable_cp1(); + __enable_fpu(); save_fp(child); - disable_cp1(); + __disable_fpu(); last_task_used_math = NULL; regs->cp0_status &= ~ST0_CU1; } @@ -174,8 +173,13 @@ case FPC_EIR: { /* implementation / version register */ unsigned int flags; + if (!(mips_cpu.options & MIPS_CPU_FPU)) { + res = -EIO; + goto out; + } + __save_flags(flags); - enable_cp1(); + __enable_fpu(); __asm__ __volatile__("cfc1\t%0,$0": "=r" (tmp)); __restore_flags(flags); break; @@ -217,9 +221,9 @@ fregs = (unsigned long long *) child->thread.fpu.soft.regs; } else { - enable_cp1(); + __enable_fpu(); save_fp(child); - disable_cp1(); + __disable_fpu(); last_task_used_math = NULL; regs->cp0_status &= ~ST0_CU1; } Index: arch/mips/kernel/signal.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips/kernel/signal.c,v retrieving revision 1.37 diff -u -r1.37 signal.c --- arch/mips/kernel/signal.c 2001/10/19 01:23:37 1.37 +++ arch/mips/kernel/signal.c 2001/10/30 14:46:30 @@ -22,6 +22,7 @@ #include #include +#include #include #include #include @@ -355,7 +356,7 @@ err |= __put_user(owned_fp, &sc->sc_ownedfp); if (current->used_math) { /* fp is active. */ - set_cp0_status(ST0_CU1); + enable_fpu(); err |= save_fp_context(sc); last_task_used_math = NULL; regs->cp0_status &= ~ST0_CU1; Index: arch/mips64/kernel/ptrace.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips64/kernel/ptrace.c,v retrieving revision 1.12 diff -u -r1.12 ptrace.c --- arch/mips64/kernel/ptrace.c 2001/10/27 00:49:55 1.12 +++ arch/mips64/kernel/ptrace.c 2001/10/30 14:46:33 @@ -119,9 +119,9 @@ #ifndef CONFIG_SMP if (last_task_used_math == child) { - set_cp0_status(ST0_CU1); + __enable_fpu(); save_fp(child); - clear_cp0_status(ST0_CU1, 0); + __disable_fpu(); last_task_used_math = NULL; } #endif @@ -197,9 +197,9 @@ if (child->used_math) { #ifndef CONFIG_SMP if (last_task_used_math == child) { - set_cp0_status(ST0_CU1); + __enable_fpu(); save_fp(child); - clear_cp0_status(ST0_CU1); + __disable_fpu(ST0_CU1); last_task_used_math = NULL; regs->cp0_status &= ~ST0_CU1; } Index: include/asm-mips/bootinfo.h =================================================================== RCS file: /home/pub/cvs/linux/include/asm-mips/bootinfo.h,v retrieving revision 1.37 diff -u -r1.37 bootinfo.h --- include/asm-mips/bootinfo.h 2001/10/24 23:00:44 1.37 +++ include/asm-mips/bootinfo.h 2001/10/30 14:46:46 @@ -298,7 +298,6 @@ * values in setup.c (or whereever suitable) so they are in * .data section */ -extern struct mips_cpu mips_cpu; extern unsigned long mips_machtype; extern unsigned long mips_machgroup; extern unsigned long mips_tlb_entries; Index: include/asm-mips/cpu.h =================================================================== RCS file: /home/pub/cvs/linux/include/asm-mips/cpu.h,v retrieving revision 1.16 diff -u -r1.16 cpu.h --- include/asm-mips/cpu.h 2001/10/26 21:28:47 1.16 +++ include/asm-mips/cpu.h 2001/10/30 14:46:46 @@ -111,6 +111,8 @@ struct cache_desc tcache; /* Tertiary/split secondary cache */ }; +extern struct mips_cpu mips_cpu; + #endif /* Index: include/asm-mips/fp.h =================================================================== RCS file: fp.h diff -N fp.h --- include/asm-mips/fp.h Tue Oct 30 15:48:07 2001 +++ include/asm-mips/fp.h Tue May 5 22:32:27 1998 @@ -1,33 +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. - * - * Copyright (C) 1998 by Ralf Baechle - */ - -/* - * Activate and deactive the floatingpoint accelerator. - */ -#define enable_cp1() \ - __asm__ __volatile__( \ - ".set\tpush\n\t" \ - ".set\tnoat\n\t" \ - ".set\treorder\n\t" \ - "mfc0\t$1,$12\n\t" \ - "or\t$1,%0\n\t" \ - "mtc0\t$1,$12\n\t" \ - ".set\tpop" \ - : : "r" (ST0_CU1)); - -#define disable_cp1() \ - __asm__ __volatile__( \ - ".set\tpush\n\t" \ - ".set\tnoat\n\t" \ - ".set\treorder\n\t" \ - "mfc0\t$1,$12\n\t" \ - "or\t$1,%0\n\t" \ - "xor\t$1,%0\n\t" \ - "mtc0\t$1,$12\n\t" \ - ".set\tpop" \ - : : "r" (ST0_CU1)); Index: include/asm-mips/mipsregs.h =================================================================== RCS file: /home/pub/cvs/linux/include/asm-mips/mipsregs.h,v retrieving revision 1.26 diff -u -r1.26 mipsregs.h --- include/asm-mips/mipsregs.h 2001/10/27 00:49:55 1.26 +++ include/asm-mips/mipsregs.h 2001/10/30 14:46:46 @@ -148,12 +148,15 @@ */ #include #ifdef CONFIG_CPU_VR41XX + #define PM_1K 0x00000000 #define PM_4K 0x00001800 #define PM_16K 0x00007800 #define PM_64K 0x0001f800 #define PM_256K 0x0007f800 + #else + #define PM_4K 0x00000000 #define PM_16K 0x00006000 #define PM_64K 0x0001e000 @@ -161,6 +164,7 @@ #define PM_1M 0x001fe000 #define PM_4M 0x007fe000 #define PM_16M 0x01ffe000 + #endif /* @@ -175,75 +179,6 @@ #define PL_16M 24 /* - * Macros to access the system control coprocessor - */ -#define read_32bit_cp0_register(source) \ -({ int __res; \ - __asm__ __volatile__( \ - ".set\tpush\n\t" \ - ".set\treorder\n\t" \ - "mfc0\t%0,"STR(source)"\n\t" \ - ".set\tpop" \ - : "=r" (__res)); \ - __res;}) - -#define read_32bit_cp0_set1_register(source) \ -({ int __res; \ - __asm__ __volatile__( \ - ".set\tpush\n\t" \ - ".set\treorder\n\t" \ - "cfc0\t%0,"STR(source)"\n\t" \ - ".set\tpop" \ - : "=r" (__res)); \ - __res;}) - -/* - * For now use this only with interrupts disabled! - */ -#define read_64bit_cp0_register(source) \ -({ int __res; \ - __asm__ __volatile__( \ - ".set\tmips3\n\t" \ - "dmfc0\t%0,"STR(source)"\n\t" \ - ".set\tmips0" \ - : "=r" (__res)); \ - __res;}) - -#define write_32bit_cp0_register(register,value) \ - __asm__ __volatile__( \ - "mtc0\t%0,"STR(register)"\n\t" \ - "nop" \ - : : "r" (value)); - -#define write_32bit_cp0_set1_register(register,value) \ - __asm__ __volatile__( \ - "ctc0\t%0,"STR(register)"\n\t" \ - "nop" \ - : : "r" (value)); - -#define write_64bit_cp0_register(register,value) \ - __asm__ __volatile__( \ - ".set\tmips3\n\t" \ - "dmtc0\t%0,"STR(register)"\n\t" \ - ".set\tmips0" \ - : : "r" (value)) - -/* - * This should be changed when we get a compiler that support the MIPS32 ISA. - */ -#define read_mips32_cp0_config1() \ -({ int __res; \ - __asm__ __volatile__( \ - ".set\tnoreorder\n\t" \ - ".set\tnoat\n\t" \ - ".word\t0x40018001\n\t" \ - "move\t%0,$1\n\t" \ - ".set\tat\n\t" \ - ".set\treorder" \ - :"=r" (__res)); \ - __res;}) - -/* * R4x00 interrupt enable / cause bits */ #define IE_SW0 (1<< 8) @@ -267,55 +202,6 @@ #define C_IRQ4 (1<<14) #define C_IRQ5 (1<<15) -#ifndef _LANGUAGE_ASSEMBLY -/* - * Manipulate the status register. - * Mostly used to access the interrupt bits. - */ -#define __BUILD_SET_CP0(name,register) \ -extern inline unsigned int \ -set_cp0_##name(unsigned int set) \ -{ \ - unsigned int res; \ - \ - res = read_32bit_cp0_register(register); \ - res |= set; \ - write_32bit_cp0_register(register, res); \ - \ - return res; \ -} \ - \ -extern inline unsigned int \ -clear_cp0_##name(unsigned int clear) \ -{ \ - unsigned int res; \ - \ - res = read_32bit_cp0_register(register); \ - res &= ~clear; \ - write_32bit_cp0_register(register, res); \ - \ - return res; \ -} \ - \ -extern inline unsigned int \ -change_cp0_##name(unsigned int change, unsigned int new) \ -{ \ - unsigned int res; \ - \ - res = read_32bit_cp0_register(register); \ - res &= ~change; \ - res |= (new & change); \ - write_32bit_cp0_register(register, res); \ - \ - return res; \ -} - -__BUILD_SET_CP0(status,CP0_STATUS) -__BUILD_SET_CP0(cause,CP0_CAUSE) -__BUILD_SET_CP0(config,CP0_CONFIG) - -#endif /* defined (_LANGUAGE_ASSEMBLY) */ - /* * Bitfields in the R4xx0 cp0 status register */ @@ -547,5 +433,440 @@ #define CEB_SUPERVISOR 4 /* Count events in supvervisor mode EXL = ERL = 0 */ #define CEB_KERNEL 2 /* Count events in kernel mode EXL = ERL = 0 */ #define CEB_EXL 1 /* Count events with EXL = 1, ERL = 0 */ + +#ifndef _LANGUAGE_ASSEMBLY + +/* + * Macros to access the system control coprocessor + */ +#define read_32bit_cp0_register(source) \ +({ int __res; \ + __asm__ __volatile__( \ + ".set\tpush\n\t" \ + ".set\treorder\n\t" \ + "mfc0\t%0,"STR(source)"\n\t" \ + ".set\tpop" \ + : "=r" (__res)); \ + __res;}) + +#define read_32bit_cp0_set1_register(source) \ +({ int __res; \ + __asm__ __volatile__( \ + ".set\tpush\n\t" \ + ".set\treorder\n\t" \ + "cfc0\t%0,"STR(source)"\n\t" \ + ".set\tpop" \ + : "=r" (__res)); \ + __res;}) + +/* + * For now use this only with interrupts disabled! + */ +#define read_64bit_cp0_register(source) \ +({ int __res; \ + __asm__ __volatile__( \ + ".set\tmips3\n\t" \ + "dmfc0\t%0,"STR(source)"\n\t" \ + ".set\tmips0" \ + : "=r" (__res)); \ + __res;}) + +#define write_32bit_cp0_register(register,value) \ + __asm__ __volatile__( \ + "mtc0\t%0,"STR(register)"\n\t" \ + "nop" \ + : : "r" (value)); + +#define write_32bit_cp0_set1_register(register,value) \ + __asm__ __volatile__( \ + "ctc0\t%0,"STR(register)"\n\t" \ + "nop" \ + : : "r" (value)); + +#define write_64bit_cp0_register(register,value) \ + __asm__ __volatile__( \ + ".set\tmips3\n\t" \ + "dmtc0\t%0,"STR(register)"\n\t" \ + ".set\tmips0" \ + : : "r" (value)) + +/* + * This should be changed when we get a compiler that support the MIPS32 ISA. + */ +#define read_mips32_cp0_config1() \ +({ int __res; \ + __asm__ __volatile__( \ + ".set\tnoreorder\n\t" \ + ".set\tnoat\n\t" \ + ".word\t0x40018001\n\t" \ + "move\t%0,$1\n\t" \ + ".set\tat\n\t" \ + ".set\treorder" \ + :"=r" (__res)); \ + __res;}) + +/* TLB operations. */ +static inline void tlb_probe(void) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "tlbp\n\t" + ".set pop"); +} + +static inline void tlb_read(void) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "tlbr\n\t" + ".set pop"); +} + +static inline void tlb_write_indexed(void) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "tlbwi\n\t" + ".set pop"); +} + +static inline void tlb_write_random(void) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "tlbwr\n\t" + ".set pop"); +} + +/* Dealing with various CP0 mmu/cache related registers. */ + + +static inline unsigned long get_pagemask(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $5\n\t" + ".set pop" + : "=r" (val)); + return val; +} + +static inline void set_pagemask(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $5\n\t" + ".set pop" + : : "Jr" (val)); +} + +/* CP0_ENTRYLO0 and CP0_ENTRYLO1 registers */ +static inline unsigned long get_entrylo0(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $2\n\t" + ".set pop" + : "=r" (val)); + return val; +} + +static inline void set_entrylo0(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $2\n\t" + ".set pop" + : : "Jr" (val)); +} + +static inline unsigned long get_entrylo1(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $3\n\t" + ".set pop" : "=r" (val)); + + return val; +} + +static inline void set_entrylo1(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $3\n\t" + ".set pop" + : : "Jr" (val)); +} + +/* CP0_ENTRYHI register */ +static inline unsigned long get_entryhi(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $10\n\t" + ".set pop" + : "=r" (val)); + + return val; +} + +static inline void set_entryhi(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $10\n\t" + ".set pop" + : : "Jr" (val)); +} + +/* CP0_INDEX register */ +static inline unsigned long get_index(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $0\n\t" + ".set pop" + : "=r" (val)); + return val; +} + +static inline void set_index(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $0\n\t" + ".set pop" + : : "Jr" (val)); +} + +/* CP0_WIRED register */ +static inline unsigned long get_wired(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $6\n\t" + ".set pop" + : "=r" (val)); + return val; +} + +static inline void set_wired(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $6\n\t" + ".set pop" + : : "Jr" (val)); +} + +/* CP0_STATUS register */ +static inline unsigned int get_status(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $12\n\t" + ".set pop" + : "=r" (val)); + return val; +} + +static inline void set_status(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $12\n\t" + ".set pop" + : : "Jr" (val)); +} + +static inline unsigned long get_info(void) +{ + unsigned long val; + + __asm__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $7\n\t" + ".set pop" + : "=r" (val)); + return val; +} + +/* CP0_TAGLO and CP0_TAGHI registers */ +static inline unsigned long get_taglo(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $28\n\t" + ".set pop" + : "=r" (val)); + return val; +} + +static inline void set_taglo(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $28\n\t" + ".set pop" + : : "Jr" (val)); +} + +static inline unsigned long get_taghi(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $29\n\t" + ".set pop" + : "=r" (val)); + return val; +} + +static inline void set_taghi(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $29\n\t" + ".set pop" + : : "Jr" (val)); +} + +/* CP0_CONTEXT register */ +static inline unsigned long get_context(void) +{ + unsigned long val; + + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mfc0 %0, $4\n\t" + ".set pop" + : "=r" (val)); + + return val; +} + +static inline void set_context(unsigned long val) +{ + __asm__ __volatile__( + ".set push\n\t" + ".set reorder\n\t" + "mtc0 %z0, $4\n\t" + ".set pop" + : : "Jr" (val)); +} + +/* + * Manipulate the status register. + * Mostly used to access the interrupt bits. + */ +#define __BUILD_SET_CP0(name,register) \ +static inline unsigned int \ +set_cp0_##name(unsigned int set) \ +{ \ + unsigned int res; \ + \ + res = read_32bit_cp0_register(register); \ + res |= set; \ + write_32bit_cp0_register(register, res); \ + \ + return res; \ +} \ + \ +static inline unsigned int \ +clear_cp0_##name(unsigned int clear) \ +{ \ + unsigned int res; \ + \ + res = read_32bit_cp0_register(register); \ + res &= ~clear; \ + write_32bit_cp0_register(register, res); \ + \ + return res; \ +} \ + \ +static inline unsigned int \ +change_cp0_##name(unsigned int change, unsigned int new) \ +{ \ + unsigned int res; \ + \ + res = read_32bit_cp0_register(register); \ + res &= ~change; \ + res |= (new & change); \ + write_32bit_cp0_register(register, res); \ + \ + return res; \ +} + +__BUILD_SET_CP0(status,CP0_STATUS) +__BUILD_SET_CP0(cause,CP0_CAUSE) +__BUILD_SET_CP0(config,CP0_CONFIG) + +#define __enable_fpu() \ +do { \ + set_cp0_status(ST0_CU1); \ + asm("nop;nop;nop;nop"); /* max. hazard */ \ +} while (0) + +#define __disable_fpu() \ +do { \ + clear_cp0_status(ST0_CU1); \ + /* We don't care about the cp0 hazard here */ \ +} while (0) + +#define enable_fpu() \ +do { \ + if (mips_cpu.options & MIPS_CPU_FPU) \ + __enable_fpu(); \ +} while (0) + +#define disable_fpu() \ +do { \ + if (mips_cpu.options & MIPS_CPU_FPU) \ + __disable_fpu(); \ +} while (0) + +#endif /* !defined (_LANGUAGE_ASSEMBLY) */ #endif /* _ASM_MIPSREGS_H */ Index: include/asm-mips/pgtable.h =================================================================== RCS file: /home/pub/cvs/linux/include/asm-mips/pgtable.h,v retrieving revision 1.60 diff -u -r1.60 pgtable.h --- include/asm-mips/pgtable.h 2001/10/24 23:00:44 1.60 +++ include/asm-mips/pgtable.h 2001/10/30 14:46:46 @@ -507,274 +507,6 @@ #define PageSkip(page) (0) #define kern_addr_valid(addr) (1) -/* TLB operations. */ -extern inline void tlb_probe(void) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "tlbp\n\t" - ".set pop"); -} - -extern inline void tlb_read(void) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "tlbr\n\t" - ".set pop"); -} - -extern inline void tlb_write_indexed(void) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "tlbwi\n\t" - ".set pop"); -} - -extern inline void tlb_write_random(void) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "tlbwr\n\t" - ".set pop"); -} - -/* Dealing with various CP0 mmu/cache related registers. */ - -/* CP0_PAGEMASK register */ -extern inline unsigned long get_pagemask(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $5\n\t" - ".set pop" - : "=r" (val)); - return val; -} - -extern inline void set_pagemask(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $5\n\t" - ".set pop" - : : "Jr" (val)); -} - -/* CP0_ENTRYLO0 and CP0_ENTRYLO1 registers */ -extern inline unsigned long get_entrylo0(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $2\n\t" - ".set pop" - : "=r" (val)); - return val; -} - -extern inline void set_entrylo0(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $2\n\t" - ".set pop" - : : "Jr" (val)); -} - -extern inline unsigned long get_entrylo1(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $3\n\t" - ".set pop" : "=r" (val)); - - return val; -} - -extern inline void set_entrylo1(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $3\n\t" - ".set pop" - : : "Jr" (val)); -} - -/* CP0_ENTRYHI register */ -extern inline unsigned long get_entryhi(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $10\n\t" - ".set pop" - : "=r" (val)); - - return val; -} - -extern inline void set_entryhi(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $10\n\t" - ".set pop" - : : "Jr" (val)); -} - -/* CP0_INDEX register */ -extern inline unsigned long get_index(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $0\n\t" - ".set pop" - : "=r" (val)); - return val; -} - -extern inline void set_index(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $0\n\t" - ".set pop" - : : "Jr" (val)); -} - -/* CP0_WIRED register */ -extern inline unsigned long get_wired(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $6\n\t" - ".set pop" - : "=r" (val)); - return val; -} - -extern inline void set_wired(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $6\n\t" - ".set pop" - : : "Jr" (val)); -} - -extern inline unsigned long get_info(void) -{ - unsigned long val; - - __asm__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $7\n\t" - ".set pop" - : "=r" (val)); - return val; -} - -/* CP0_TAGLO and CP0_TAGHI registers */ -extern inline unsigned long get_taglo(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $28\n\t" - ".set pop" - : "=r" (val)); - return val; -} - -extern inline void set_taglo(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $28\n\t" - ".set pop" - : : "Jr" (val)); -} - -extern inline unsigned long get_taghi(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $29\n\t" - ".set pop" - : "=r" (val)); - return val; -} - -extern inline void set_taghi(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $29\n\t" - ".set pop" - : : "Jr" (val)); -} - -/* CP0_CONTEXT register */ -extern inline unsigned long get_context(void) -{ - unsigned long val; - - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mfc0 %0, $4\n\t" - ".set pop" - : "=r" (val)); - - return val; -} - -extern inline void set_context(unsigned long val) -{ - __asm__ __volatile__( - ".set push\n\t" - ".set reorder\n\t" - "mtc0 %z0, $4\n\t" - ".set pop" - : : "Jr" (val)); -} - #include #endif /* !defined (_LANGUAGE_ASSEMBLY) */ From owner-linux-mips@oss.sgi.com Tue Oct 30 13:47:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ULlrQ11211 for linux-mips-outgoing; Tue, 30 Oct 2001 13:47:53 -0800 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ULlk011207 for ; Tue, 30 Oct 2001 13:47:46 -0800 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 003132B6FE; Tue, 30 Oct 2001 21:47:39 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 845A1C8CA; Tue, 30 Oct 2001 21:46:19 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 6EB58E826; Tue, 30 Oct 2001 21:46:19 +0000 (GMT) Date: Tue, 30 Oct 2001 21:46:19 +0000 (GMT) From: Dave Airlie X-X-Sender: To: "Maciej W. Rozycki" Cc: , , Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1889 Lines: 53 Okay it didn't go so well.. my VAX couldn't boot the file I normally use with this mopd (I had to rebuild it for a static libelf)... I've put a tgz up at http://www.skynet.ie/~airlied/vax/mopd_on_the_vax.tgz it contains the file I was trying to boot and the tcpdumps of this mopd and the one I normally use ... if you need any more info give me a shout .. Regards, Dave. On Mon, 29 Oct 2001, Maciej W. Rozycki wrote: > Hi, > > I've made a preliminary version of mopd with ELF support available. It's > Mats O. Jansson's mopd 2.5.3 with several fixes, updates and enhancements. > The work is definitely not finished, but basic functionality is already > implemented. I'm making it available due to the amount of PITA > maintenance of traditional mopd image formats incurs, in hope someone will > find it useful. Libelf is required for this version of mopd. It should > build and run on any Linux system, regardless of endianness. It might > work on other systems as well. > > I've made RPM packages available at the usual place (i.e. > 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'). Beside source packages there are > i386 and mipsel binary ones available. Grab the latest version; olders > are for a reference only. To aid people with no RPM support in their > systems I've unpacked the source package into the "mopd" directory. Still > you need to study the .spec file to figure how to build binaries. > > Any feedback will be appreciated; I'm especially interested in reports > from VAX users, as I've only been able to verify the operation booting > Linux on a DECstation 5000 (i.e. MIPS) system. Note: this version of mopd > does not require switching devices into the PROMISC or ALLMULTI modes of > operation. > > Maciej > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Tue Oct 30 18:54:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V2sHB18801 for linux-mips-outgoing; Tue, 30 Oct 2001 18:54:17 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V2sA018798; Tue, 30 Oct 2001 18:54:10 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 31 Oct 2001 02:54:10 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 7FF18B46D; Wed, 31 Oct 2001 11:54:08 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA38696; Wed, 31 Oct 2001 11:54:08 +0900 (JST) Date: Wed, 31 Oct 2001 11:58:56 +0900 (JST) Message-Id: <20011031.115856.41626992.nemoto@toshiba-tops.co.jp> To: ralf@oss.sgi.com Cc: carstenl@mips.com, ahennessy@mvista.com, ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. From: Atsushi Nemoto In-Reply-To: <20011030155533.A28550@dea.linux-mips.net> References: <3BDDF193.B6405A7F@mvista.com> <3BDE62B4.BE7A1885@mips.com> <20011030155533.A28550@dea.linux-mips.net> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 682 Lines: 24 >>>>> On Tue, 30 Oct 2001 15:55:33 +0100, Ralf Baechle said: ralf> So here is a preliminiary version of my patch. Still untested ralf> and needs to be applied to mips64 also. Thank you. This patch works fine for me. One request: with this patch, a ptrace call for FPC_EIR returns error on FPU-less CPUs. The call can be handled without error (as for other FP registers). --- /tmp/ptrace.c Wed Oct 31 11:44:16 2001 +++ arch/mips/kernel/ptrace.c Wed Oct 31 11:46:10 2001 @@ -174,8 +174,7 @@ unsigned int flags; if (!(mips_cpu.options & MIPS_CPU_FPU)) { - res = -EIO; - goto out; + break; } __save_flags(flags); --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue Oct 30 20:07:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V47Qo20148 for linux-mips-outgoing; Tue, 30 Oct 2001 20:07:26 -0800 Received: from dea.linux-mips.net (a1as08-p246.stg.tli.de [195.252.188.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V47L020145 for ; Tue, 30 Oct 2001 20:07:21 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9V46bB08579; Wed, 31 Oct 2001 05:06:37 +0100 Date: Wed, 31 Oct 2001 05:06:37 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: carstenl@mips.com, ahennessy@mvista.com, ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. Message-ID: <20011031050637.B8456@dea.linux-mips.net> References: <3BDDF193.B6405A7F@mvista.com> <3BDE62B4.BE7A1885@mips.com> <20011030155533.A28550@dea.linux-mips.net> <20011031.115856.41626992.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011031.115856.41626992.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Oct 31, 2001 at 11:58:56AM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 636 Lines: 17 On Wed, Oct 31, 2001 at 11:58:56AM +0900, Atsushi Nemoto wrote: > ralf> So here is a preliminiary version of my patch. Still untested > ralf> and needs to be applied to mips64 also. > > Thank you. This patch works fine for me. > > One request: with this patch, a ptrace call for FPC_EIR returns error > on FPU-less CPUs. The call can be handled without error (as for other > FP registers). I don't think there is much point in returning a version number if there is nothing we could return a version number of. Well, maybe the fp emulation sw version or kernel version. What would you consider a sensible return value? Ralf From owner-linux-mips@oss.sgi.com Tue Oct 30 20:25:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V4PSN20502 for linux-mips-outgoing; Tue, 30 Oct 2001 20:25:28 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V4PO020499; Tue, 30 Oct 2001 20:25:24 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 31 Oct 2001 04:25:24 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 31F13B46D; Wed, 31 Oct 2001 13:25:23 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id NAA38941; Wed, 31 Oct 2001 13:25:22 +0900 (JST) Date: Wed, 31 Oct 2001 13:30:11 +0900 (JST) Message-Id: <20011031.133011.11593683.nemoto@toshiba-tops.co.jp> To: ralf@oss.sgi.com Cc: carstenl@mips.com, ahennessy@mvista.com, ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. From: Atsushi Nemoto In-Reply-To: <20011031050637.B8456@dea.linux-mips.net> References: <20011030155533.A28550@dea.linux-mips.net> <20011031.115856.41626992.nemoto@toshiba-tops.co.jp> <20011031050637.B8456@dea.linux-mips.net> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 557 Lines: 14 >>>>> On Wed, 31 Oct 2001 05:06:37 +0100, Ralf Baechle said: ralf> I don't think there is much point in returning a version number ralf> if there is nothing we could return a version number of. Well, ralf> maybe the fp emulation sw version or kernel version. What would ralf> you consider a sensible return value? The reason of my request is that user-mode gdb reports error on "info reg" command. "info reg" command shows fsr and fir. So, I don't care the return value. I think "0" is enough for FPU-less CPUs. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue Oct 30 20:32:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V4WBD20722 for linux-mips-outgoing; Tue, 30 Oct 2001 20:32:11 -0800 Received: from dea.linux-mips.net (a1as08-p246.stg.tli.de [195.252.188.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V4W7020719 for ; Tue, 30 Oct 2001 20:32:07 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f9V4Vh917943; Wed, 31 Oct 2001 05:31:43 +0100 Date: Wed, 31 Oct 2001 05:31:42 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: carstenl@mips.com, ahennessy@mvista.com, ajob4me@21cn.com, linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. Message-ID: <20011031053142.A17909@dea.linux-mips.net> References: <20011030155533.A28550@dea.linux-mips.net> <20011031.115856.41626992.nemoto@toshiba-tops.co.jp> <20011031050637.B8456@dea.linux-mips.net> <20011031.133011.11593683.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011031.133011.11593683.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Oct 31, 2001 at 01:30:11PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 646 Lines: 17 On Wed, Oct 31, 2001 at 01:30:11PM +0900, Atsushi Nemoto wrote: > >>>>> On Wed, 31 Oct 2001 05:06:37 +0100, Ralf Baechle said: > ralf> I don't think there is much point in returning a version number > ralf> if there is nothing we could return a version number of. Well, > ralf> maybe the fp emulation sw version or kernel version. What would > ralf> you consider a sensible return value? > > The reason of my request is that user-mode gdb reports error on "info > reg" command. "info reg" command shows fsr and fir. > > So, I don't care the return value. I think "0" is enough for FPU-less > CPUs. Ok, applied. Ralf From owner-linux-mips@oss.sgi.com Tue Oct 30 20:50:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V4o7M21163 for linux-mips-outgoing; Tue, 30 Oct 2001 20:50:07 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V4o2021157; Tue, 30 Oct 2001 20:50:02 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 31 Oct 2001 04:50:02 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 7516AB46D; Wed, 31 Oct 2001 13:50:01 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id NAA39000; Wed, 31 Oct 2001 13:50:01 +0900 (JST) Date: Wed, 31 Oct 2001 13:54:49 +0900 (JST) Message-Id: <20011031.135449.21587564.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: small fix for gdb From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 442 Lines: 19 in gdb-low.S, "mfc1" (not "cfc1") is used to get CP1 status/revision. Here is a patch. --- linux-sgi-cvs/arch/mips/kernel/gdb-low.S Fri Oct 26 10:39:13 2001 +++ linux.new/arch/mips/kernel/gdb-low.S Wed Oct 31 13:44:52 2001 @@ -145,9 +145,9 @@ * FPU control registers */ - mfc1 v0,CP1_STATUS + cfc1 v0,CP1_STATUS sw v0,GDB_FR_FSR(sp) - mfc1 v0,CP1_REVISION + cfc1 v0,CP1_REVISION sw v0,GDB_FR_FIR(sp) /* --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue Oct 30 21:07:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9V57bs21601 for linux-mips-outgoing; Tue, 30 Oct 2001 21:07:37 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9V57Y021598 for ; Tue, 30 Oct 2001 21:07:34 -0800 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15ynbY-0004gr-00; Wed, 31 Oct 2001 00:07:56 -0500 Date: Wed, 31 Oct 2001 00:07:56 -0500 From: Daniel Jacobowitz To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Toshiba TX3927 board boot problem. Message-ID: <20011031000756.A18018@nevyn.them.org> References: <20011030155533.A28550@dea.linux-mips.net> <20011031.115856.41626992.nemoto@toshiba-tops.co.jp> <20011031050637.B8456@dea.linux-mips.net> <20011031.133011.11593683.nemoto@toshiba-tops.co.jp> <20011031053142.A17909@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011031053142.A17909@dea.linux-mips.net> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 931 Lines: 22 On Wed, Oct 31, 2001 at 05:31:42AM +0100, Ralf Baechle wrote: > On Wed, Oct 31, 2001 at 01:30:11PM +0900, Atsushi Nemoto wrote: > > > >>>>> On Wed, 31 Oct 2001 05:06:37 +0100, Ralf Baechle said: > > ralf> I don't think there is much point in returning a version number > > ralf> if there is nothing we could return a version number of. Well, > > ralf> maybe the fp emulation sw version or kernel version. What would > > ralf> you consider a sensible return value? > > > > The reason of my request is that user-mode gdb reports error on "info > > reg" command. "info reg" command shows fsr and fir. > > > > So, I don't care the return value. I think "0" is enough for FPU-less > > CPUs. > > Ok, applied. Thanks; returning 0 is the best GDB can expect here. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Oct 31 02:26:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VAQHA06822 for linux-mips-outgoing; Wed, 31 Oct 2001 02:26:17 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VAQ9006816; Wed, 31 Oct 2001 02:26:10 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 31 Oct 2001 10:26:09 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id CA37BB471; Wed, 31 Oct 2001 19:26:07 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id TAA40015; Wed, 31 Oct 2001 19:26:07 +0900 (JST) Date: Wed, 31 Oct 2001 19:30:55 +0900 (JST) Message-Id: <20011031.193055.18309028.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: fix typo in fault.c From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 537 Lines: 20 bust_spinlock() does not exist. Also, this code does NOT cause link error. It seems the codes after die() are discarded at compile time because die() has "noreturn" attribute. --- /work3/sgi/linux-sgi-cvs/arch/mips/mm/fault.c Mon Oct 29 15:26:57 2001 +++ arch/mips/mm/fault.c Wed Oct 31 13:44:16 2001 @@ -202,7 +202,7 @@ "address %08lx, epc == %08lx, ra == %08lx\n", address, regs->cp0_epc, regs->regs[31]); die("Oops", regs); - bust_spinlock(0); + bust_spinlocks(0); do_exit(SIGKILL); /* --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Oct 31 04:18:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VCIiD11604 for linux-mips-outgoing; Wed, 31 Oct 2001 04:18:44 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VCIZ011599 for ; Wed, 31 Oct 2001 04:18:35 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA12094; Wed, 31 Oct 2001 13:16:51 +0100 (MET) Date: Wed, 31 Oct 2001 13:16:50 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Dave Airlie cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, linux-vax@mithra.physics.montana.edu Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1267 Lines: 42 On Tue, 30 Oct 2001, Dave Airlie wrote: > Okay it didn't go so well.. my VAX couldn't boot the file I normally use > with this mopd (I had to rebuild it for a static libelf)... > > I've put a tgz up at > > http://www.skynet.ie/~airlied/vax/mopd_on_the_vax.tgz > > it contains the file I was trying to boot and the tcpdumps of this mopd > and the one I normally use ... Thanks for the report. This is what mopchk says about the image: Checking: vmlinux.SYS RSX Image Header Block Count: 0 Image Size: 00000000 Load Address: 00000000 Transfer Address: 00000000 No wonder it cannot be booted -- the header states the file's size is zero. > if you need any more info give me a shout .. That's enough, thanks. It seems I was a bit too optimistic in the assumption a traditional MOP image header contains a correct image size -- I'll implement a fallback to the file's size if the header contains null size. Since I'll be away till Tuesday, expect an update in the middle of the next week. I'm assuming ELF loading works, right? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed Oct 31 08:09:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VG9qJ02671 for linux-mips-outgoing; Wed, 31 Oct 2001 08:09:52 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VG9c002666 for ; Wed, 31 Oct 2001 08:09:38 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15yxvl-0002hg-00; Wed, 31 Oct 2001 10:09:29 -0600 Message-ID: <3BE02E31.3B2CA5FC@cotw.com> Date: Wed, 31 Oct 2001 11:00:33 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: gdb@sources.redhat.com CC: binutils@sources.redhat.com, linux-mips@oss.sgi.com Subject: Old bug with 'gdb/dbxread.c' and screwed up MIPS symbolic debugging... References: <3BDF7F79.6050205@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6162 Lines: 162 I have attempted to do as much research and testing as I possibly can before posting this. I remember reading a thread associated with this problem in the past, but things are still not working properly. I have also taken the liberty of CC'ing the binutils and linux-mips list just in case. GOAL ---- To use my KGDB stub with GDB and/or Insight to debug my embedded MIPS kernel over the serial link utilizing symbolic debugging. TOOLCHAIN --------- binutils-2.11.92.0.10 (stock) gcc-3.0.2 (stock) glibc-2.2.3 (minor patches to ld-scripts and a small fixes for ipc/shm) gdb-10312001 (fresh out of cvs this morning w/patch applied, see bottom) CONFIGURATION LINES FOR TOOLS ----------------------------- ../binutils-2.11.92.0.10/configure --prefix=/opt/toolchains/mips --target=mipsel-linux AR=mipsel-linux-ar RANLIB=mipsel-linux-ranlib ../gcc-3.0.2/configure --prefix=/opt/toolchains/mips --target=mipsel-linux i686-pc-linux-gnu --with-newlib --disable-shared --enable-languages=c BUILD_CC=gcc CC=mipsel-linux-gcc AR=mipsel-linux-ar AS=mipsel-linux-as RANLIB=mipsel-linux-ranlib ../glibc-2.2.3/configure --prefix=/opt/toolchains/mips/mipsel-linux mipsel-linux --build=i686-pc-linux-gnu --enable-add-ons --with-elf --disable-profile --with-headers=/opt/toolchains/mips/mipsel-linux/include --mandir=/opt/toolchains/mips/man --infodir=/opt/toolchains/mips/info AR=mipsel-linux-ar RANLIB=mipsel-linux-ranlib ../gcc-3.0.2/configure --prefix=/opt/toolchains/mips --target=mipsel-linux i686-pc-linux-gnu --with-gxx-include-dir=/opt/toolchains/mips/mipsel-linux/include --mandir=/opt/toolchains/mips/man --infodir=/opt/toolchains/mips/info --enable-languages=c,c++ --enable-threads ../gdb-10312001/configure --prefix=/opt/toolchains/mips --target=mips-linux-elf KERNEL ------ Last 2.4.5 release from oss.sgi.com CVS TYPICAl KERNEL COMPILE LINE --------------------------- mipsel-linux-gcc -I /opt/mips/settop/include/asm/gcc -D__KERNEL__ -I/opt/mips/settop/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -g -G 0 -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe -I .. -I /opt/mips/settop/fs -funsigned-char -c -o xfs_griostubs.o xfs_griostubs.c Assembler messages: Warning: The -mcpu option is deprecated. Please use -march and -mtune instead. Warning: The -march option is incompatible to -mipsN and therefore ignored. PROBLEM REPORT -------------- I am using a NEC MIPS VR5432 in little endian and 32-bit mode. If I run 'mipsel-linux-objdump -d vmlinux', I get addresses starting with 0x8000XXXX. With older toolchains I remember getting 0xffffffff8000XXXX. My kernel boots fine and patiently waits for GDB to connect. If I use GDB stock from CVS without applying any patches, the following output occurs: This GDB was configured as "--host=i686-pc-linux-gnu --target=mips-linux-elf"... (gdb) target remote /dev/ttyS1 Remote debugging using /dev/ttyS1 0x80012c88 in breakinst () at 1879 1879 sock_unregister(PF_PACKET); (gdb) bt #0 0x80012c88 in breakinst () at af_packet.c:1879 #1 0x8020aabc in brcm_irq_setup () at irq.c:421 #2 0x8020aaf0 in init_IRQ () at irq.c:434 #3 0x801fc83c in start_kernel () at init/main.c:524 #4 0x801fd6f8 in init_arch (argc=160, argv=0xb3000000, envp=0x2, prom_vec=0xbf) at setup.c:425 (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x80012c88 in breakinst () at af_packet.c:1879 1879 sock_unregister(PF_PACKET); (gdb) bt #0 0x80012c88 in breakinst () at af_packet.c:1879 #1 0x8001a554 in sys_create_module (name_user=0x10001dc8 "brcmdrv", size=713264) at module.c:305 (gdb) c Continuing. Which is clearly wrong. 'breakinst' is clearly not in that file, but all the other symbolics in the backtrace are correct. Then if I go to insert a module, 'breakinst' again is decoded at the wrong place, but it gets 'sys_create_module' module symbol decoded right. I will point out that 'breakinst' is defined in 'arch/mips/kernel/gdb-stub.c' and FWIW, looks like: __asm__ __volatile__(" .globl breakinst .set noreorder nop breakinst: break nop .set reorder "); "SOLUTION" ---------- On August 15, H.J. Lu applied a patch to 'gdb/dbxread.c' shown here: diff -urN -x CVS work/gdb/dbxread.c gdb-5.0-08162001/gdb/dbxread.c --- work/gdb/dbxread.c Tue Oct 30 16:33:33 2001 +++ gdb-5.0-08162001/gdb/dbxread.c Wed Aug 15 00:02:28 2001 @@ -951,7 +951,10 @@ (intern).n_type = bfd_h_get_8 (abfd, (extern)->e_type); \ (intern).n_strx = bfd_h_get_32 (abfd, (extern)->e_strx); \ (intern).n_desc = bfd_h_get_16 (abfd, (extern)->e_desc); \ - (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \ + if (bfd_get_sign_extend_vma (abfd)) \ + (intern).n_value = bfd_h_get_signed_32 (abfd, (extern)->e_value); \ + else \ + (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \ } /* Invariant: The symbol pointed to by symbuf_idx is the first one If I back out this change, my debug output is "correct", but I no longer have the nice line numbers and files decoded for me: (gdb) target remote /dev/ttyS1 Remote debugging using /dev/ttyS1 0x80012c88 in breakinst () (gdb) bt #0 0x80012c88 in breakinst () #1 0x8020aabc in brcm_irq_setup () #2 0x8020aaf0 in init_IRQ () #3 0x801fc83c in start_kernel () #4 0x801fd6f8 in init_arch () (gdb) c Continuing. Also, if I attempt to back out this patch from the latest insight CVS code, it has not affect. Insight would still decode 'breakinst' at 'af_packet.c'. CONCLUSION ---------- Conclusion? Uhh, things don't work. I greatly appreciate input from people on this issue and hope I have supplied enough detail. I don't want to start digging into the gdb source too deep without hearing other people's opinions. Thanks. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Wed Oct 31 08:32:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VGWIf04606 for linux-mips-outgoing; Wed, 31 Oct 2001 08:32:18 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VGW8004602 for ; Wed, 31 Oct 2001 08:32:08 -0800 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15yyHg-0000jn-00; Wed, 31 Oct 2001 11:32:08 -0500 Date: Wed, 31 Oct 2001 11:32:08 -0500 From: Daniel Jacobowitz To: "Steven J. Hill" Cc: gdb@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: Old bug with 'gdb/dbxread.c' and screwed up MIPS symbolic debugging... Message-ID: <20011031113208.A1882@nevyn.them.org> Mail-Followup-To: "Steven J. Hill" , gdb@sources.redhat.com, linux-mips@oss.sgi.com References: <3BDF7F79.6050205@cygnus.com> <3BE02E31.3B2CA5FC@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BE02E31.3B2CA5FC@cotw.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3996 Lines: 95 On Wed, Oct 31, 2001 at 11:00:33AM -0600, Steven J. Hill wrote: > PROBLEM REPORT > -------------- > I am using a NEC MIPS VR5432 in little endian and 32-bit mode. If I run > 'mipsel-linux-objdump -d vmlinux', I get addresses starting with 0x8000XXXX. > With older toolchains I remember getting 0xffffffff8000XXXX. My kernel boots Well, the change in objdump output is purely cosmetic. For 32bit object formats we just truncate the display now. > fine and patiently waits for GDB to connect. If I use GDB stock from CVS > without applying any patches, the following output occurs: > > This GDB was configured as "--host=i686-pc-linux-gnu --target=mips-linux-elf"... > (gdb) target remote /dev/ttyS1 > Remote debugging using /dev/ttyS1 > 0x80012c88 in breakinst () at 1879 > 1879 sock_unregister(PF_PACKET); > (gdb) bt > #0 0x80012c88 in breakinst () at af_packet.c:1879 > #1 0x8020aabc in brcm_irq_setup () at irq.c:421 > #2 0x8020aaf0 in init_IRQ () at irq.c:434 > #3 0x801fc83c in start_kernel () at init/main.c:524 > #4 0x801fd6f8 in init_arch (argc=160, argv=0xb3000000, envp=0x2, > prom_vec=0xbf) at setup.c:425 > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x80012c88 in breakinst () at af_packet.c:1879 > 1879 sock_unregister(PF_PACKET); > (gdb) bt > #0 0x80012c88 in breakinst () at af_packet.c:1879 > #1 0x8001a554 in sys_create_module (name_user=0x10001dc8 "brcmdrv", > size=713264) at module.c:305 > (gdb) c > Continuing. > > Which is clearly wrong. 'breakinst' is clearly not in that file, but all the > other symbolics in the backtrace are correct. Then if I go to insert a module, > 'breakinst' again is decoded at the wrong place, but it gets 'sys_create_module' > module symbol decoded right. I will point out that 'breakinst' is defined in > 'arch/mips/kernel/gdb-stub.c' and FWIW, looks like: > > __asm__ __volatile__(" > .globl breakinst > .set noreorder > nop > breakinst: break > nop > .set reorder > "); > Does this happen for any other symbol than breakinst? Breakinst is effectively a function with no debugging info. That case historically causes us problems, so we probably missed another need for sign extension. > > "SOLUTION" > ---------- > On August 15, H.J. Lu applied a patch to 'gdb/dbxread.c' shown here: > > diff -urN -x CVS work/gdb/dbxread.c gdb-5.0-08162001/gdb/dbxread.c > --- work/gdb/dbxread.c Tue Oct 30 16:33:33 2001 > +++ gdb-5.0-08162001/gdb/dbxread.c Wed Aug 15 00:02:28 2001 > @@ -951,7 +951,10 @@ > (intern).n_type = bfd_h_get_8 (abfd, (extern)->e_type); \ > (intern).n_strx = bfd_h_get_32 (abfd, (extern)->e_strx); \ > (intern).n_desc = bfd_h_get_16 (abfd, (extern)->e_desc); \ > - (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \ > + if (bfd_get_sign_extend_vma > (abfd)) \ > + (intern).n_value = bfd_h_get_signed_32 (abfd, > (extern)->e_value); \ > + else \ > + (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \ > } > > /* Invariant: The symbol pointed to by symbuf_idx is the first one > > If I back out this change, my debug output is "correct", but I no longer > have the nice line numbers and files decoded for me: If you back it out, I believe we just give up in confusion :) This is int the reading of stabs info. breakinst has no stabs info, so it's getting its line info somewhere else. Please point me at a copy of your kernel binary with debug info, and I'll look into it. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Oct 31 11:12:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VJC3t10311 for linux-mips-outgoing; Wed, 31 Oct 2001 11:12:03 -0800 Received: from localhost.cygnus.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VJBw010302 for ; Wed, 31 Oct 2001 11:11:58 -0800 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 029903D47; Wed, 31 Oct 2001 13:11:25 -0500 (EST) Message-ID: <3BE03ECD.5060904@cygnus.com> Date: Wed, 31 Oct 2001 13:11:25 -0500 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz Cc: "Steven J. Hill" , gdb@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: Old bug with 'gdb/dbxread.c' and screwed up MIPS symbolic debugging... References: <3BDF7F79.6050205@cygnus.com> <3BE02E31.3B2CA5FC@cotw.com> <20011031113208.A1882@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1897 Lines: 51 > > Well, the change in objdump output is purely cosmetic. For 32bit > object formats we just truncate the display now. As an aside, is there an option to turn this truncation off? The vr5432 as and ld will still pass around 64 bit addresses. >> >> "SOLUTION" >> ---------- >> On August 15, H.J. Lu applied a patch to 'gdb/dbxread.c' shown here: >> >> diff -urN -x CVS work/gdb/dbxread.c gdb-5.0-08162001/gdb/dbxread.c >> --- work/gdb/dbxread.c Tue Oct 30 16:33:33 2001 >> +++ gdb-5.0-08162001/gdb/dbxread.c Wed Aug 15 00:02:28 2001 >> @@ -951,7 +951,10 @@ >> (intern).n_type = bfd_h_get_8 (abfd, (extern)->e_type); \ >> (intern).n_strx = bfd_h_get_32 (abfd, (extern)->e_strx); \ >> (intern).n_desc = bfd_h_get_16 (abfd, (extern)->e_desc); \ >> - (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \ >> + if (bfd_get_sign_extend_vma >> (abfd)) \ >> + (intern).n_value = bfd_h_get_signed_32 (abfd, >> (extern)->e_value); \ >> + else \ >> + (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \ >> } >> > /* Invariant: The symbol pointed to by symbuf_idx is the first one >> >> If I back out this change, my debug output is "correct", but I no longer >> have the nice line numbers and files decoded for me: > > > If you back it out, I believe we just give up in confusion [:)] This is > int the reading of stabs info. breakinst has no stabs info, so it's > getting its line info somewhere else. It might - assembler debugging ... > Please point me at a copy of your kernel binary with debug info, and > I'll look into it. Yes, you want to look for a version of breakinst that isn't sign extended. Since pulling the above patch helped it won't be in .stabs so the symbol table? Andrew From owner-linux-mips@oss.sgi.com Wed Oct 31 11:21:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VJLqu10703 for linux-mips-outgoing; Wed, 31 Oct 2001 11:21:52 -0800 Received: from emma.patton.com (emma.patton.com [209.49.110.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VJLe010699 for ; Wed, 31 Oct 2001 11:21:41 -0800 Received: from patton.com (decpc.patton.com [209.49.110.83]) by emma.patton.com (8.9.0/8.9.0) with ESMTP id OAA01440; Wed, 31 Oct 2001 14:21:50 -0500 (EST) Message-ID: <3BE04EF6.2B3766E4@patton.com> Date: Wed, 31 Oct 2001 14:20:22 -0500 From: Paul Kasper Reply-To: paul@patton.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: RedHat 7.1/mips update References: <20011024121646.A6520@lucon.org> Content-Type: multipart/mixed; boundary="------------D34713B4C6E5904AC80D9E42" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2660 Lines: 98 This is a multi-part message in MIME format. --------------D34713B4C6E5904AC80D9E42 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "H . J . Lu" wrote: > > I updated my RedHat 7.1/mips port. There are quite a few changes. Check it > out. > > H.J. > ----- > My mini-port of RedHat 7.1 is at > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > ..... > > > H.J. I am trying to install from a SuSE 7.2 workstation. In an effort to get findrpm to work, I updated my RPMs with 2 of yours and 2 from RedHat: ------------------------------ scooby:/opt/rh71_oss/install # rpm -Uhv ../RPMS/i386/rpm-python-4.0.2-8.6.i386.rpm ../RPMS/i386/rpm-4.0.2-8.6.i386.rpm /opt/download/RPMS/db1-1.85-7.i386.rpm /opt/download/RPMS/patch-2.5.4-9.i386.rpm Preparing... ########################################### [100%] package rpm-python-4.0.2-8.6 is already installed package rpm-4.0.2-8.6 is already installed package db1-1.85-7 is already installed package patch-2.5.4-9 is already installed scooby:/opt/rh71_oss/install # rpm -qa |grep python python-imaging-1.1-68 python-tk-2.0-90 python-2.0-90 python-doc-2.0-90 python-devel-2.0-90 python-nothreads-2.0-90 python-demo-2.0-90 rpm-python-4.0.2-8.6 scooby:/opt/rh71_oss/install # rpm -qa |grep rpm rpm2html-1.5-16 rpmfind-1.6-62 autorpm-1.9.9-14 xrpm-2.2-333 rpm-4.0.2-8.6 rpm-python-4.0.2-8.6 scooby:/opt/rh71_oss/install # ./findrpm gcc Traceback (most recent call last): File "./findrpm", line 5, in ? import rpm ImportError: No module named rpm <----- ??? ----- scooby:/opt/rh71_oss/install # ------------------------------ Not being much of a python person, does anybody have any suggestions? Should I upgrade more of the python packages even though there are no complaints regarding depenencies? Any suggestions welcomed. -- Paul Kasper -- /"\ . . . . . . . . . . . . . . . /"\ \ / ASCII Ribbon Campaign \ / Paul R. Kasper X - NO HTML/RTF in e-mail X Patton Electronics Co. / \ - NO MSWord docs in e-mail / \ 301-975-1000 x173 --------------D34713B4C6E5904AC80D9E42 Content-Type: text/x-vcard; charset=us-ascii; name="paul.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Paul Kasper Content-Disposition: attachment; filename="paul.vcf" begin:vcard n:Kasper;Paul tel;fax:301-869-9293 tel;work:301-975-1000 x173 x-mozilla-html:FALSE url:www.patton.com org:Patton Electronics Co.;Central Office Products adr:;;7622 Rickenbacker Drive;Gaithersburg;MD;20879;USA version:2.1 email;internet:paul@patton.com x-mozilla-cpt:;10912 fn:Paul Kasper end:vcard --------------D34713B4C6E5904AC80D9E42-- From owner-linux-mips@oss.sgi.com Wed Oct 31 11:29:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VJTff10847 for linux-mips-outgoing; Wed, 31 Oct 2001 11:29:41 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VJTd010844 for ; Wed, 31 Oct 2001 11:29:39 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8DC0B125C9; Wed, 31 Oct 2001 11:29:38 -0800 (PST) Date: Wed, 31 Oct 2001 11:29:38 -0800 From: "H . J . Lu" To: Paul Kasper Cc: linux-mips@oss.sgi.com Subject: Re: RedHat 7.1/mips update Message-ID: <20011031112938.B407@lucon.org> References: <20011024121646.A6520@lucon.org> <3BE04EF6.2B3766E4@patton.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE04EF6.2B3766E4@patton.com>; from paul@patton.com on Wed, Oct 31, 2001 at 02:20:22PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 509 Lines: 24 On Wed, Oct 31, 2001 at 02:20:22PM -0500, Paul Kasper wrote: > "H . J . Lu" wrote: > > > > I updated my RedHat 7.1/mips port. There are quite a few changes. Check it > > out. > > > > H.J. > > ----- > > My mini-port of RedHat 7.1 is at > > > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > > > ..... > > > > > > H.J. > > I am trying to install from a SuSE 7.2 workstation. In an effort to get > findrpm to work, I updated my RPMs with 2 of yours and 2 from RedHat: Only RedHat 7.1 is supported. H.J. From owner-linux-mips@oss.sgi.com Wed Oct 31 12:51:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VKp4q15816 for linux-mips-outgoing; Wed, 31 Oct 2001 12:51:04 -0800 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VKp1015813 for ; Wed, 31 Oct 2001 12:51:01 -0800 Received: from [192.168.1.170] (192.168.1.170 [192.168.1.170]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNXG6; Wed, 31 Oct 2001 15:50:54 -0500 Subject: Cross-Compiler From: Marc Karasek To: linux-mips@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.18.15.19 (Preview Release) Date: 31 Oct 2001 15:51:39 -0500 Message-Id: <1004561523.1863.11.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 394 Lines: 18 Does anyone know of any instructions/binaries for a cross-compiler toolchain that are not based on egcs. I am looking for one that is as close to the current x86 as possible. (i.e. gcc 3.x.x, binutils 2.10.x, etc.) Thanks, -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Wed Oct 31 12:53:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VKrV815914 for linux-mips-outgoing; Wed, 31 Oct 2001 12:53:31 -0800 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VKrT015910 for ; Wed, 31 Oct 2001 12:53:29 -0800 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id f9VKrQG26872; Wed, 31 Oct 2001 15:53:26 -0500 Date: Wed, 31 Oct 2001 15:53:26 -0500 From: Jim Paris To: Marc Karasek Cc: linux-mips@oss.sgi.com Subject: Re: Cross-Compiler Message-ID: <20011031155326.A26865@neurosis.mit.edu> Reply-To: jim@jtan.com References: <1004561523.1863.11.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1004561523.1863.11.camel@localhost.localdomain>; from marc_karasek@ivivity.com on Wed, Oct 31, 2001 at 03:51:39PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 304 Lines: 8 > Does anyone know of any instructions/binaries for a cross-compiler > toolchain that are not based on egcs. I am looking for one that is as > close to the current x86 as possible. (i.e. gcc 3.x.x, binutils 2.10.x, > etc.) http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt -jim From owner-linux-mips@oss.sgi.com Wed Oct 31 14:35:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VMZeC22840 for linux-mips-outgoing; Wed, 31 Oct 2001 14:35:40 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VMZd022835 for ; Wed, 31 Oct 2001 14:35:39 -0800 Received: from dsl73.cedar-rapids.net ([208.242.241.39] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15z3xN-0003CR-00 for ; Wed, 31 Oct 2001 16:35:33 -0600 Message-ID: <3BE07787.5FF7DB8A@cotw.com> Date: Wed, 31 Oct 2001 17:13:27 -0500 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Kernel panic: Caught reserved exception - should not happen. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 185 Lines: 7 I have been getting a fair amount of the above type of errors when compiling on a mipsel box. 2.4.5 kernel on a NEC VR5432 box. Anyone aware of known problems? -- Scott A. McConnell From owner-linux-mips@oss.sgi.com Wed Oct 31 14:48:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VMm4u23056 for linux-mips-outgoing; Wed, 31 Oct 2001 14:48:04 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VMlq023052 for ; Wed, 31 Oct 2001 14:47:52 -0800 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15z49F-0000Oh-00; Wed, 31 Oct 2001 17:47:49 -0500 Date: Wed, 31 Oct 2001 17:47:49 -0500 From: Daniel Jacobowitz To: Andrew Cagney Cc: "Steven J. Hill" , gdb@sources.redhat.com, linux-mips@oss.sgi.com Subject: Stabs and discarded functions (was Re: Old bug with 'gdb/dbxread.c' and screwed up MIPS symbolic debugging...) Message-ID: <20011031174749.A28985@nevyn.them.org> Mail-Followup-To: Andrew Cagney , "Steven J. Hill" , gdb@sources.redhat.com, linux-mips@oss.sgi.com References: <3BDF7F79.6050205@cygnus.com> <3BE02E31.3B2CA5FC@cotw.com> <20011031113208.A1882@nevyn.them.org> <3BE03ECD.5060904@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BE03ECD.5060904@cygnus.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4274 Lines: 118 On Wed, Oct 31, 2001 at 01:11:25PM -0500, Andrew Cagney wrote: > > > >Well, the change in objdump output is purely cosmetic. For 32bit > >object formats we just truncate the display now. > > As an aside, is there an option to turn this truncation off? The vr5432 > as and ld will still pass around 64 bit addresses. It shouldn't happen in that case, I think. The vr5432 is configured as a mips64 target, isn't it? > >If you back it out, I believe we just give up in confusion [:)] This is > >int the reading of stabs info. breakinst has no stabs info, so it's > >getting its line info somewhere else. > > It might - assembler debugging ... I don't think it does, at least... > >Please point me at a copy of your kernel binary with debug info, and > >I'll look into it. > > Yes, you want to look for a version of breakinst that isn't sign > extended. Since pulling the above patch helped it won't be in .stabs so > the symbol table? It's not that breakinst isn't sign extended. This is very much like the address ranges issue that came up with -ffunction-sections or linkonce sections. I'm writing this as I debug. Excuse the flow of consciousness (or skip down to the end!). Here's our bug: (top-gdb) p/x *b $21 = {startaddr = 0x34, endaddr = 0xffffffff80215314, function = 0x0, superblock = 0x0, gcc_compile_flag = 0x2, nsyms = 0x6, sym = {0x8755bbc}} The startaddr is obviously wrong. This is the first symtab listed for kernel. So where does that startaddr come from? (By the way, our debugging of long longs is abysmal. I already filed a PR about this I think. It makes tracking 64bit CORE_ADDRs a real pain; they're printed with the upper half garbage.) The answer is that the startaddr comes from the psymtab. During psymbol reading: Hardware watchpoint 24: *$139 Old value = 18446744069414584372 New value = 52 at: 630 && (CUR_SYMBOL_VALUE 631 != ANOFFSET (objfile->section_offsets, 632 SECT_OFF_TEXT (objfile)))))) 633 { 634 TEXTLOW (pst) = CUR_SYMBOL_VALUE; 635 textlow_not_set = 0; 636 } 637 #endif /* DBXREAD_ONLY */ 638 add_psymbol_to_list (namestring, p - namestring, 639 VAR_NAMESPACE, LOC_BLOCK, Here's the offending stabs entry: 317176 FUN 0 1870 0000000000000034 1689303 packet_exit:f(0,20) i.e. it has value 0x34 (52). That's bad. Now, there's two things wrong here. One of them is the bad value. I think that I've already seen this problem, and that it has something to do with the way stabs are and used to be emitted. packet_exit is presumably in the .text.exit section, which is presumably the problem. Before linking, the stab looked like: 2971 FUN 0 1870 0000000000000000 159366 packet_exit:f(0,20) and had a relocation: 0000000000008b58 R_MIPS_32 .text.exit unless I miss my guess. So it looks like binutils did not relocate the stabs for .text.exit properly. Why? It's pretty simple; there was nothing to relocate it to. From the kernel's linker script: /* Sections to be discarded */ /DISCARD/ : { *(.text.exit) *(.data.exit) *(.exitcall.exit) } So instead of the subtle error we get in objfiles containing multiple sections, which we'll still need to deal with for the kernel for .text.init, we have a completely bogus result. We need to discard the stabs records for discarded symbols. Of course, we're just reading the psymtab in when we get here. We don't have symbols yet. We could do this by a second pass after reading, instead of the hack with textlow, but that's gross. This makes it impossible to debug at least MIPS kernels with stabs and gdb, so I very much want to fix it. I'm not sure how this works on x86, but I'd guess it had to do with differences in relocation types. Anyone have an example handy? Meanwhile, Steven, as a quick hack - try removing the /DISCARD/ bit from your linker script and relinking. What happens? Does everything else seem to work? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Oct 31 14:56:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9VMuVe23260 for linux-mips-outgoing; Wed, 31 Oct 2001 14:56:31 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9VMuU023257 for ; Wed, 31 Oct 2001 14:56:30 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f9VMwBB10287; Wed, 31 Oct 2001 14:58:11 -0800 Message-ID: <3BE08194.35FBCB82@mvista.com> Date: Wed, 31 Oct 2001 14:56:20 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Scott A McConnell CC: linux-mips@oss.sgi.com Subject: Re: Kernel panic: Caught reserved exception - should not happen. References: <3BE07787.5FF7DB8A@cotw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 267 Lines: 11 Scott A McConnell wrote: > > I have been getting a fair amount of the above type of errors when > compiling on a mipsel box. > > 2.4.5 kernel on a NEC VR5432 box. Anyone aware of known problems? > What is the exception vector? Is it the "watch exception"? Jun From owner-linux-mips@oss.sgi.com Wed Oct 31 17:05:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA115Hh25884 for linux-mips-outgoing; Wed, 31 Oct 2001 17:05:17 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1157025874; Wed, 31 Oct 2001 17:05:08 -0800 Received: from hcdong11752a ([10.105.30.0]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GM3K8M00.E62; Thu, 1 Nov 2001 09:02:46 +0800 Message-ID: <000f01c16271$8013eae0$001e690a@huawei.com> From: "machael" To: Cc: "Ralf Baechle" Subject: KSEG0 and KSEG2 ... Date: Thu, 1 Nov 2001 09:06:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1406 Lines: 40 Hello,ralf: I use linux-2.4.5 and have some questions to need your help. I try to replace some kernel functions with my own implementations.I will explain it in the following: Let's say: void (*my_func)(void)=func1; where "my_func" is a function pointer defined in kernel, and "func1" is a function(void func1(void)) implemented in kernel.And "my_func" is an EXPORTED SYMBOL in mips_ksyms.c. Now I want to replace "func1" with my own "func2" in a module my_module.o: extern void (*my_func)(void); my_func = func2; where "func2" is a function (void fun2(void)) implemented in "my_module.o". If I do "insmod my_module.o", the kernel should run OK. In fact, it is often met an "unhandled kernel unaligned access" or "do_page_fault" exception and then panics. We know "func1" should be in KSEG0(unmapped , cached) since it is implemented in kernel space.So it's address should be 0x8XXXXXXX.And "my_func" should also pointed to this same address before inserting my_module.o. And "func2" should be in KSEG2(mapped, cached) since it is implemented in module, So it's address should be 0xCXXXXXXX.After inserting my_module.o, "my_func" should be changed to pointed to this new address in KSEG2. My question is : When "my_func" changes from KSEG0 from KSEG2, Can it cause some problems? Thank you very much. machael From owner-linux-mips@oss.sgi.com Wed Oct 31 17:10:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA11AhT26063 for linux-mips-outgoing; Wed, 31 Oct 2001 17:10:43 -0800 Received: from dea.linux-mips.net (a1as05-p109.stg.tli.de [195.252.187.109]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA11Aa026057 for ; Wed, 31 Oct 2001 17:10:37 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA116WH05633; Thu, 1 Nov 2001 02:06:32 +0100 Date: Thu, 1 Nov 2001 02:06:32 +0100 From: Ralf Baechle To: Green Cc: LinuxEmbeddedMailList , LinuxKernelMailList , MipsMailList , linux-mips@oss.sgi.com Subject: Re: Discontinuous memory!! Message-ID: <20011101020632.A5076@dea.linux-mips.net> References: <00c701c1612b$4c133620$4c0c5c8c@trd.iii.org.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00c701c1612b$4c133620$4c0c5c8c@trd.iii.org.tw>; from greeen@iii.org.tw on Tue, Oct 30, 2001 at 06:11:43PM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1180 Lines: 34 On Tue, Oct 30, 2001 at 06:11:43PM +0800, Green wrote: > I am porting Linux to R3912. > > There are two memory block on my target board. > > One is 16MB from 0x8000 0000 to 0x8100 0000. > > The other one is 16MB from 0x8200 0000 to 0x8300 0000. > > But I found kernel just managed the first memory block. > > How could I modify the kernel to support 32MB discontinuous memory? > > Now I am trying to add entries to page table. > It will halt at decompressing ramdisk. > > Has anyone resolve this kind of problem before? The kernel support this type of memory architecture if you enable CONFIG_DISCONTIGMEM. One machine which uses this feature is the Origin, grep in arch/mips64 for CONFIG_DISCONTIGMEM. There are also several ARM system using it. As support for CONFIG_DISCONTIGMEM is less than perfect you should check if your system allows for reconfiguration of memory as a single physically contiguous chunk. Don't use add_memory_region() in this case; that code only works well for small holes in memory address space. Your holes are fairly large so memory management would waste about 2mb if you would not use CONFIG_DISCONTIGMEM. Ralf