-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jeff Harrell Work: (801) 619-6104 Broadband Access group/TI jharrell@ti.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

, argc=3, ubp_av=0x7ffff8d4, init=0x4000f8 <_init>, fini=0x5c6880 <_fini>, rtld_fini=0, stack_end=0x7ffff8b0) at ../sysdeps/generic/libc-start.c:111 This is a static rpm binary, so I don't understand why it tries do dynaload anything at all... Thanks in advance, -- Karel van Houten From owner-linux-mips@oss.sgi.com Sat Mar 17 07:01:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2HF17d27366 for linux-mips-outgoing; Sat, 17 Mar 2001 07:01:07 -0800 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2HF14M27362 for ; Sat, 17 Mar 2001 07:01:04 -0800 Received: from fwd03.sul.t-online.com by mailout02.sul.t-online.com with smtp id 14eICT-0002it-01; Sat, 17 Mar 2001 16:01:01 +0100 Received: from void.s.bawue.de (520095841842-0001@[62.158.213.107]) by fmrl03.sul.t-online.com with esmtp id 14eICC-1IlheSC; Sat, 17 Mar 2001 16:00:44 +0100 Received: from florian by void.s.bawue.de with local (Exim 3.16 #1 (Debian)) id 14eELB-0000RL-00; Sat, 17 Mar 2001 11:53:45 +0100 Date: Sat, 17 Mar 2001 11:53:45 +0100 To: linux-mips@oss.sgi.com Subject: Re: machines available to porters Message-ID: <20010317115345.B623@void.s.bawue.de> Mail-Followup-To: Florian Laws , linux-mips@oss.sgi.com References: <3AB21608.5030007@medicalmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AB21608.5030007@medicalmedia.com>; from mcgonigle@medicalmedia.com on Fri, Mar 16, 2001 at 08:32:56AM -0500 From: Florian Laws X-Sender: 520095841842-0001@t-dialin.net Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 451 Lines: 16 On Fri, Mar 16, 2001 at 08:32:56AM -0500, Bill McGonigle wrote: > > u5 - Indigo 2 "Impact 10000" (purple) > scsi disk 0,1 2.27 GB > scsi disk 0,2 9.15 GB > scsi disk 0,3 cdrom > Irix Audio Processor: Version A2 > 1 195 MHZ IP22 Processor ^^^^ > FPU: MIPS R10010 Floating Point Coprocessor 0.0 > CPU: MIPS R10000 Processor Chip rev. 2.5 ^^^^^^ Can this be possible? Florian From owner-linux-mips@oss.sgi.com Sat Mar 17 07:47:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2HFlUs28067 for linux-mips-outgoing; Sat, 17 Mar 2001 07:47:30 -0800 Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2HFlTM28064 for ; Sat, 17 Mar 2001 07:47:29 -0800 Received: from fest.stud.fee.vutbr.cz (fest.stud.fee.vutbr.cz [147.229.9.16]) by boco.fee.vutbr.cz (8.11.3/8.11.3) with ESMTP id f2HFlQt47888 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 17 Mar 2001 16:47:27 +0100 (CET) Received: (from xjezda00@localhost) by fest.stud.fee.vutbr.cz (8.11.2/8.11.2) id f2HFlQF86608; Sat, 17 Mar 2001 16:47:26 +0100 (CET) Date: Sat, 17 Mar 2001 16:47:26 +0100 From: David Jez To: Karel van Houten Cc: linux-mips@oss.sgi.com Subject: Re: rpm crashing on RH 7.0 indy Message-ID: <20010317164726.B86495@stud.fee.vutbr.cz> References: <200103171051.LAA04852@pandora.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103171051.LAA04852@pandora.research.kpn.com>; from K.H.C.vanHouten@kpn.com on Sat, Mar 17, 2001 at 11:51:19AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 839 Lines: 28 On Sat, Mar 17, 2001 at 11:51:19AM +0100, Karel van Houten wrote: > Hi all, > > I hope someone can help me with this problem... > > I've installed an Indy with Ralfs Redhat/test-7.0 packages. > Most things work OK, but rpm itself crashes when installing > a package. Here is a trace of what happens: > > This is a static rpm binary, so I don't understand why it tries > do dynaload anything at all... Hi, Ooops, i think: haven't you got broken rpm? Have you downloaded the rpm complete? Try checksum or md5. > > Thanks in advance, > -- > Karel van Houten Hope you will be succeded, Dave -- ------------------------------------------------------- David "Dave" Jez Brno, CZ, Europe E-mail: dave.jez@seznam.cz PGP key: finger xjezda00@fest.stud.fee.vutbr.cz ---------=[ ~EOF ]=------------------------------------ From owner-linux-mips@oss.sgi.com Sat Mar 17 09:39:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2HHdQ629530 for linux-mips-outgoing; Sat, 17 Mar 2001 09:39:26 -0800 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2HHdPM29527 for ; Sat, 17 Mar 2001 09:39:25 -0800 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id AB552109CE; Sat, 17 Mar 2001 09:39:47 -0800 (PST) Received: by galt.foobazco.org (Postfix, from userid 1014) id 1F81A1F429; Sat, 17 Mar 2001 09:39:20 -0800 (PST) Date: Sat, 17 Mar 2001 09:39:19 -0800 From: Keith M Wesolowski To: David Jez Cc: Karel van Houten , linux-mips@oss.sgi.com Subject: Re: rpm crashing on RH 7.0 indy Message-ID: <20010317093919.A19754@foobazco.org> References: <200103171051.LAA04852@pandora.research.kpn.com> <20010317164726.B86495@stud.fee.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010317164726.B86495@stud.fee.vutbr.cz>; from dave.jez@seznam.cz on Sat, Mar 17, 2001 at 04:47:26PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 889 Lines: 20 On Sat, Mar 17, 2001 at 04:47:26PM +0100, David Jez wrote: > > This is a static rpm binary, so I don't understand why it tries > > do dynaload anything at all... > Hi, > > Ooops, i think: haven't you got broken rpm? Have you downloaded the rpm > complete? Try checksum or md5. That's not the problem. The problem is that static binaries which use libdl used to be (and perhaps still are) broken. The reason it's using libdl is that the nss libraries are never truly static, unless you compile glibc with a special non-recommended option. I have indications that this may be fixed in glibc 2.2.2 using my current toolchain, but my information is not complete. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "I should have crushed his marketing-addled skull with a fucking bat." From owner-linux-mips@oss.sgi.com Sat Mar 17 12:32:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2HKW8w32500 for linux-mips-outgoing; Sat, 17 Mar 2001 12:32:08 -0800 Received: from web10507.mail.yahoo.com (web10507.mail.yahoo.com [216.136.130.157]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f2HKW7M32497 for ; Sat, 17 Mar 2001 12:32:07 -0800 Message-ID: <20010317203207.54631.qmail@web10507.mail.yahoo.com> Received: from [63.22.96.13] by web10507.mail.yahoo.com; Sat, 17 Mar 2001 12:32:07 PST Date: Sat, 17 Mar 2001 12:32:07 -0800 (PST) From: m b Subject: Linux on SGI Indigo and Indigo2 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: 269 Lines: 12 Hi, I have an Indigo and an Indigo 2 and want to run Linux. Someone told me to ask here. Can anyone help? Thanks, Marc __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Sun Mar 18 07:32:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2IFWIW14246 for linux-mips-outgoing; Sun, 18 Mar 2001 07:32:18 -0800 Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2IFWHM14243 for ; Sun, 18 Mar 2001 07:32:17 -0800 Received: from fest.stud.fee.vutbr.cz (fest.stud.fee.vutbr.cz [147.229.9.16]) by boco.fee.vutbr.cz (8.11.3/8.11.3) with ESMTP id f2IFWCt12317 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 18 Mar 2001 16:32:14 +0100 (CET) Received: (from xmichl03@localhost) by fest.stud.fee.vutbr.cz (8.11.2/8.11.2) id f2IFWB218968; Sun, 18 Mar 2001 16:32:11 +0100 (CET) From: Michl Ladislav Date: Sun, 18 Mar 2001 16:32:11 +0100 (CET) X-processed: pine.send To: Subject: arc cmdline.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1815 Lines: 67 hi all, i have some beginner questions, so please be patient with me :-) 1) quoting indy-hd-boot-micro-howto.html: O.k. we're almost there. The last thing to do is to tell the PROM which file to boot on power up: [snip] setenv OSLoader linux setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8) setenv OSLoadPartition /dev/sda1 but OSLoadPartition is ignored, so this no loger works. does it mean that i have to use setenv root /dev/sda1 instead? hmm, i really hate gotos :-( --- cmdline.c.orig Sun Mar 18 15:26:02 2001 +++ cmdline.c Sun Mar 18 15:46:22 2001 @@ -34,23 +34,18 @@ char *cp; int actr, i; - actr = 1; /* Always ignore argv[0] */ - cp = &(arcs_cmdline[0]); - while(actr < prom_argc) { - for(i = 0; i < NENTS(ignored); i++) { - int len = strlen(ignored[i]); - - if(!strncmp(prom_argv[actr], ignored[i], len)) - goto pic_cont; + + /* Always ignore argv[0] */ + for (actr = 1; actr < prom_argc; actr++) { + for (i = 0; i < NENTS(ignored); i++) { + if (strncmp(prom_argv[actr], ignored[i], strlen(ignored[i]))) { + /* Ok, we want it. */ + strcpy(cp, prom_argv[actr]); + cp += strlen(prom_argv[actr]); + *cp++ = ' '; + } } - /* Ok, we want it. */ - strcpy(cp, prom_argv[actr]); - cp += strlen(prom_argv[actr]); - *cp++ = ' '; - - pic_cont: - actr++; } if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */ --cp; 2) i also don't understand directory layout in arch/mips. i expected indy's prom cmdline in arch/mips/sgi/prom, but found it in arch/mips/arc. is there any historical (or other) reason for this? 3) what compiler are you using? compilation of glibc2.2.2 with gcc 2.95.2 took about 11 (!) hours on 100 MHz Indy, ie much more than on i486. now i'm trying build gcc 3.0 from cvs, i hope it helps. thanks for explanation, ladis From owner-linux-mips@oss.sgi.com Sun Mar 18 18:37:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2J2bTn21729 for linux-mips-outgoing; Sun, 18 Mar 2001 18:37:29 -0800 Received: from ibbserver.ibb.uu.nl (IDENT:mail@ibbserver.ibb.uu.nl [131.211.124.6]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2J2bRM21726 for ; Sun, 18 Mar 2001 18:37:27 -0800 Received: from leander.ibb.uu.nl (ibb0100.ibb.uu.nl [131.211.124.100]) by ibbserver.ibb.uu.nl (Postfix) with ESMTP id 2BB0E124B3; Mon, 19 Mar 2001 03:37:25 +0100 (CET) Message-Id: <5.0.2.1.2.20010319031124.00af61a0@pop.med.uu.nl> X-Sender: leander@131.211.124.6 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 19 Mar 2001 03:36:54 +0100 To: debian-mips@lists.debian.org, linux-mips@oss.sgi.com From: Leander Koornneef Subject: Trouble booting my indy Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2493078==_.ALT" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3676 Lines: 94 --=====================_2493078==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi there, I acquired an indy recently. I spent some time reading emails in these lists and some documentation available on the internet. So now, finally came the time to really try and install debian-mips on this machine. I booted my Mandrake linux box and setup everything according to http://staf.digibel.org/topic.php?lang=eng&top=indy Now, I fired up the indy and gave the command: 'boot -f bootp()vmlinux-2.4.0-test6-pre8.ecoff init=/bin/bash nfsroot=192.168.0.1:/indy' I got the following: 'Setting $netaddr to 192.168.0.2 ( from server)' Which is nice :-) Then, nothing happens for a minute or two after which I get the mesage: 'Unable to load bootp()vmlinux-2.4.0-test6-pre8.ecoff ''bootp()vmlinux-2.4.0-test6-pre8.ecoff'' is not a valid file to boot' As far as I can tell, the tftp daemon is running and /indy is exported In the logs it says: Mar 19 02:39:06 leander dhcpd: data: lease_time: lease ends at 0 when it is now 984965946 Mar 19 02:39:06 leander dhcpd: BOOTREQUEST from 08:00:69:09:64:09 via eth0 Mar 19 02:39:06 leander dhcpd: BOOTREPLY for 192.168.0.2 to indy (08:00:69:09:64:09) via eth0 And that's it :-( I read something about problems with tftpd running on linux >= 2.3, but my boot server is running 2.2.18. I hope someone can help me finally boot my indy.... By the way, it's an R5000pc (150MHz) Many thanks in advance, Leander Koornneef --=====================_2493078==_.ALT Content-Type: text/html; charset="us-ascii" Hi there,

I acquired an indy recently. I spent some time reading emails in these lists and some documentation available on the internet.
So now, finally came the time to really try and install debian-mips on this machine.
I booted my Mandrake linux box and setup everything according to http://staf.digibel.org/topic.php?lang=eng&top=indy
Now, I fired up the indy and gave the command:
        'boot -f bootp()vmlinux-2.4.0-test6-pre8.ecoff init=/bin/bash nfsroot=192.168.0.1:/indy'

I got the following:
        'Setting $netaddr to 192.168.0.2 ( from server)'

Which is nice :-)
Then, nothing happens for a minute or two after which I get the mesage:
        'Unable to load bootp()vmlinux-2.4.0-test6-pre8.ecoff ''bootp()vmlinux-2.4.0-test6-pre8.ecoff'' is not a valid file to boot'

As far as I can tell, the tftp daemon is running and /indy is exported
In the logs it says:

Mar 19 02:39:06 leander dhcpd: data: lease_time: lease ends at 0 when it is now 984965946
Mar 19 02:39:06 leander dhcpd: BOOTREQUEST from 08:00:69:09:64:09 via eth0
Mar 19 02:39:06 leander dhcpd: BOOTREPLY for 192.168.0.2 to indy (08:00:69:09:64:09) via eth0
And that's it :-(
I read something about problems with tftpd running on linux >= 2.3, but my boot server is running 2.2.18.
I hope someone can help me finally boot my indy....
By the way, it's an R5000pc (150MHz)

Many thanks in advance,

Leander Koornneef
--=====================_2493078==_.ALT-- From owner-linux-mips@oss.sgi.com Mon Mar 19 06:07:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2JE7nH31733 for linux-mips-outgoing; Mon, 19 Mar 2001 06:07:49 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2JE7mM31730 for ; Mon, 19 Mar 2001 06:07:48 -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 GAA05551 for ; Mon, 19 Mar 2001 06:07:48 -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 GAA00622 for ; Mon, 19 Mar 2001 06:07:46 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id PAA02100 for ; Mon, 19 Mar 2001 15:07:15 +0100 (MET) Message-ID: <3AB61293.5652407C@mips.com> Date: Mon, 19 Mar 2001 15:07:15 +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: linux-mips@oss.sgi.com Subject: Bug in the _save_fp_context. Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1142 Lines: 35 I think there is a bug in the _save_fp_context function in arch/mips/kernel/r4k_fpu.S The problem is the following piece of code: jr ra .set nomacro EX(sw t0,SC_FPC_EIR(a0)) nop .set macro First of all what should the ".set nomacro" do? If it means that the EX macro shouldn't be used then this entry wouldn't get into __ex_table, which would be wrong. But it look like it uses the macro anyway, regardless of the ".set nomacro", at least with the compiler I use. Never the less we do not handle entries in the __ex_table which is located in a branch delay. So we need to handle the situation where we take a page fault on an instruction which is located in a brach delay slot, or we don't put the "potential" faulting instruction in a delay slot. Any ideas, how we should handle this in a nice and clean way? /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Mar 19 07:39:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2JFdKL01110 for linux-mips-outgoing; Mon, 19 Mar 2001 07:39:20 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2JFdKM01107 for ; Mon, 19 Mar 2001 07:39:20 -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 HAA06334 for ; Mon, 19 Mar 2001 07:39:19 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA02840; Mon, 19 Mar 2001 07:39:15 -0800 (PST) Message-ID: <00e901c0b08b$50bed400$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Carsten Langgaard" , References: <3AB61293.5652407C@mips.com> Subject: Re: Bug in the _save_fp_context. Date: Mon, 19 Mar 2001 16:43:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" 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: 2190 Lines: 57 > I think there is a bug in the _save_fp_context function in > arch/mips/kernel/r4k_fpu.S > > The problem is the following piece of code: > > jr ra > .set nomacro > EX(sw t0,SC_FPC_EIR(a0)) > nop > .set macro > > First of all what should the ".set nomacro" do? > If it means that the EX macro shouldn't be used then this entry wouldn't > get into __ex_table, which would be wrong. > But it look like it uses the macro anyway, regardless of the ".set > nomacro", at least with the compiler I use. Not surprising, really. "EX" is presumably a cpp macro that gets expanded by gcc from the .S file, based on some include file. .set directives affect only the assembler, and would inhibit assembler-level macros only. I'm not sure just what the definition of an assembler macro would be - it may or may not include pseudo-instructions like "la" or "li 32_bit_constant". I *think* that what the author was trying to do here was to ensure that the "sw" instruction in the EX expansion was really and truly a single instruction. > Never the less we do not handle entries in the __ex_table which is > located in a branch delay. > So we need to handle the situation where we take a page fault on an > instruction which is located in a brach delay slot, or we don't put the > "potential" faulting instruction in a delay slot. > > Any ideas, how we should handle this in a nice and clean way? Is the __ex_table really ending up in the delay slot? Just looking at the source, I have the impression that the "sw t0,..." instruction should be in the delay slot, followed by the __ex_table. On another topic, now that I've patched the kernel to turn off the stupid stuck interrupt on my Malta board, I've realized that I can't just connect my old Atlas SCSI disk. I'm torn between ordering a Tekram 390 PCI SCSI card, which should be able to use our "MIPS safe" NCR driver as-is (I hope) and buying an IDE disk and going through the network install ritual. Which do you recommend? One thing I really never knew was just what kernel config options I need to select to build a kernel that can do the NFS-root bootstrap. Can you help me there? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Mar 19 07:59:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2JFxro01724 for linux-mips-outgoing; Mon, 19 Mar 2001 07:59:53 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2JFxqM01721 for ; Mon, 19 Mar 2001 07:59:52 -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 HAA06507 for ; Mon, 19 Mar 2001 07:59:52 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA03322 for ; Mon, 19 Mar 2001 07:59:50 -0800 (PST) Message-ID: <00f901c0b08e$3099bc00$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: References: <3AB61293.5652407C@mips.com> <00e901c0b08b$50bed400$0deca8c0@Ulysses> Subject: Re: Bug in the _save_fp_context. Date: Mon, 19 Mar 2001 17:03:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" 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: 2723 Lines: 72 Oops! I hadn't noticed that Carsten had copied the Linux-MIPS mailing list on this, so I treated it as a point-to-point communication. The rest of you can ignore my last paragraph! Kevin K. ----- Original Message ----- From: "Kevin D. Kissell" To: "Carsten Langgaard" ; Sent: Monday, March 19, 2001 4:43 PM Subject: Re: Bug in the _save_fp_context. > > I think there is a bug in the _save_fp_context function in > > arch/mips/kernel/r4k_fpu.S > > > > The problem is the following piece of code: > > > > jr ra > > .set nomacro > > EX(sw t0,SC_FPC_EIR(a0)) > > nop > > .set macro > > > > First of all what should the ".set nomacro" do? > > If it means that the EX macro shouldn't be used then this entry wouldn't > > get into __ex_table, which would be wrong. > > But it look like it uses the macro anyway, regardless of the ".set > > nomacro", at least with the compiler I use. > > Not surprising, really. "EX" is presumably a cpp macro > that gets expanded by gcc from the .S file, based on > some include file. .set directives affect only the assembler, > and would inhibit assembler-level macros only. I'm not > sure just what the definition of an assembler macro > would be - it may or may not include pseudo-instructions > like "la" or "li 32_bit_constant". I *think* that what the > author was trying to do here was to ensure that the > "sw" instruction in the EX expansion was really and > truly a single instruction. > > > Never the less we do not handle entries in the __ex_table which is > > located in a branch delay. > > So we need to handle the situation where we take a page fault on an > > instruction which is located in a brach delay slot, or we don't put the > > "potential" faulting instruction in a delay slot. > > > > Any ideas, how we should handle this in a nice and clean way? > > Is the __ex_table really ending up in the delay slot? > Just looking at the source, I have the impression > that the "sw t0,..." instruction should be in the delay > slot, followed by the __ex_table. > > On another topic, now that I've patched the kernel to > turn off the stupid stuck interrupt on my Malta board, > I've realized that I can't just connect my old Atlas SCSI > disk. I'm torn between ordering a Tekram 390 PCI > SCSI card, which should be able to use our "MIPS > safe" NCR driver as-is (I hope) and buying an IDE > disk and going through the network install ritual. > Which do you recommend? One thing I really never > knew was just what kernel config options I need to > select to build a kernel that can do the NFS-root > bootstrap. Can you help me there? > > Regards, > > Kevin K. > From owner-linux-mips@oss.sgi.com Mon Mar 19 08:13:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2JGDfo02086 for linux-mips-outgoing; Mon, 19 Mar 2001 08:13:41 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2JGDeM02083 for ; Mon, 19 Mar 2001 08:13:40 -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 IAA06666 for ; Mon, 19 Mar 2001 08:13:40 -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 IAA03736; Mon, 19 Mar 2001 08:13:38 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id RAA09554; Mon, 19 Mar 2001 17:13:07 +0100 (MET) Message-ID: <3AB63012.B2DF9CD6@mips.com> Date: Mon, 19 Mar 2001 17:13:06 +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: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: Bug in the _save_fp_context. References: <3AB61293.5652407C@mips.com> <00e901c0b08b$50bed400$0deca8c0@Ulysses> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3045 Lines: 81 "Kevin D. Kissell" wrote: > > I think there is a bug in the _save_fp_context function in > > arch/mips/kernel/r4k_fpu.S > > > > The problem is the following piece of code: > > > > jr ra > > .set nomacro > > EX(sw t0,SC_FPC_EIR(a0)) > > nop > > .set macro > > > > First of all what should the ".set nomacro" do? > > If it means that the EX macro shouldn't be used then this entry wouldn't > > get into __ex_table, which would be wrong. > > But it look like it uses the macro anyway, regardless of the ".set > > nomacro", at least with the compiler I use. > > Not surprising, really. "EX" is presumably a cpp macro > that gets expanded by gcc from the .S file, based on > some include file. .set directives affect only the assembler, > and would inhibit assembler-level macros only. I'm not > sure just what the definition of an assembler macro > would be - it may or may not include pseudo-instructions > like "la" or "li 32_bit_constant". I *think* that what the > author was trying to do here was to ensure that the > "sw" instruction in the EX expansion was really and > truly a single instruction. > > > Never the less we do not handle entries in the __ex_table which is > > located in a branch delay. > > So we need to handle the situation where we take a page fault on an > > instruction which is located in a brach delay slot, or we don't put the > > "potential" faulting instruction in a delay slot. > > > > Any ideas, how we should handle this in a nice and clean way? > > Is the __ex_table really ending up in the delay slot? > Just looking at the source, I have the impression > that the "sw t0,..." instruction should be in the delay > slot, followed by the __ex_table. The problem is that the address of the delay slot is put in the __ex_table and then we take a page fault EPC is pointing at the jr instruction and not the delay slot. This result in a miss match when we try to lookup in __ex_table, resulting in a kernel crash. The faulting situation look like this: EPC = address of delay slot entry in __ex_table = address of delay slot - 4 Hopes that clarify it a bit more. > > On another topic, now that I've patched the kernel to > turn off the stupid stuck interrupt on my Malta board, > I've realized that I can't just connect my old Atlas SCSI > disk. I'm torn between ordering a Tekram 390 PCI > SCSI card, which should be able to use our "MIPS > safe" NCR driver as-is (I hope) and buying an IDE > disk and going through the network install ritual. > Which do you recommend? One thing I really never > knew was just what kernel config options I need to > select to build a kernel that can do the NFS-root > bootstrap. Can you help me there? > > Regards, > > Kevin K. -- _ _ ____ ___ 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 Mar 19 10:14:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2JIE1705220 for linux-mips-outgoing; Mon, 19 Mar 2001 10:14:01 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2JIE1M05217 for ; Mon, 19 Mar 2001 10:14:01 -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 f2JI8u303447; Mon, 19 Mar 2001 10:08:56 -0800 Message-ID: <3AB64B83.B645CCB@mvista.com> Date: Mon, 19 Mar 2001 10:10:11 -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: "Kevin D. Kissell" CC: Carsten Langgaard , linux-mips@oss.sgi.com Subject: SCSI card [Re: Bug in the _save_fp_context.] References: <3AB61293.5652407C@mips.com> <00e901c0b08b$50bed400$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1236 Lines: 33 "Kevin D. Kissell" wrote: > On another topic, now that I've patched the kernel to > turn off the stupid stuck interrupt on my Malta board, > I've realized that I can't just connect my old Atlas SCSI > disk. I'm torn between ordering a Tekram 390 PCI > SCSI card, which should be able to use our "MIPS > safe" NCR driver as-is (I hope) and buying an IDE > disk and going through the network install ritual. > Which do you recommend? One thing I really never > knew was just what kernel config options I need to > select to build a kernel that can do the NFS-root > bootstrap. Can you help me there? > Kevin, If you store your kernel image on flash and boots from there, using a local hard disk is not a bad idea. I recently used a SCSI card based on NCR 53C895A. I have to turn off some optimization in the driver in order to get it work. See some related configs below. CONFIG_SCSI_NCR53C8XX=y # CONFIG_SCSI_SYM53C8XX is not set CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=0 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=0 In general NFS root is always easier to get kernel going. Many defconfigs under arch/mips/ already have NFS root fs configured as default, at least in the two I put in, DDB5476 and ocelot. Jun From owner-linux-mips@oss.sgi.com Mon Mar 19 10:18:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2JIIit05592 for linux-mips-outgoing; Mon, 19 Mar 2001 10:18:44 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2JIIiM05589 for ; Mon, 19 Mar 2001 10:18:44 -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 f2JIDe303864; Mon, 19 Mar 2001 10:13:40 -0800 Message-ID: <3AB64C9F.E11521DC@mvista.com> Date: Mon, 19 Mar 2001 10:14:55 -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: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: Bug in the _save_fp_context. References: <3AB61293.5652407C@mips.com> <00e901c0b08b$50bed400$0deca8c0@Ulysses> <00f901c0b08e$3099bc00$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 303 Lines: 13 "Kevin D. Kissell" wrote: > > Oops! I hadn't noticed that Carsten had copied the > Linux-MIPS mailing list on this, so I treated it as a > point-to-point communication. The rest of you can > ignore my last paragraph! > > Kevin K. > Oops! Please ignore my previous reply too. :-) Jun From owner-linux-mips@oss.sgi.com Mon Mar 19 14:53:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2JMrMv11724 for linux-mips-outgoing; Mon, 19 Mar 2001 14:53:22 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2JMrMM11721 for ; Mon, 19 Mar 2001 14:53:22 -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 f2JMmI326581; Mon, 19 Mar 2001 14:48:18 -0800 Message-ID: <3AB68CFC.A2840808@mvista.com> Date: Mon, 19 Mar 2001 14:49:32 -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: linux-mips@oss.sgi.com Subject: gdb 5.0 display arguments problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1246 Lines: 33 I am using gdb 5.0 client to debug kernel, and found a bug in gdb 5.0 when it trys to display an function argument. The following is the relavent code segment where breakpoint is set to the first instruction of serial_console_write(). 00000000801270ac : 801270ac: 3c04801d lui $a0,0x801d 801270b0: 8c84bc1c lw $a0,-17380($a0) 801270b4: 27bdffc0 addiu $sp,$sp,-64 801270b8: afb40028 sw $s4,40($sp) 801270bc: 00a0a021 move $s4,$a1 801270c0: 24050001 li $a1,1 For whatever reason gdb client on the host side apparently thinks the second arg is stored in register s4. When the breakpoint is hit, gdb tries to display the value of s4 (which is 0x4 in this case). Since the type of this argument is char *, gdb further tries to read the content at 0x4 which causes kernel panic. I believe I have seen this problem before (and in most case the symptom is wrong argument values instead of kernel panic). Does someone have an idea how to fix it or work around it? Does this problem exist in native debugging? I assume we can disable gdb to display char strings by default. Does someone know how to do it? Thanks. Jun From owner-linux-mips@oss.sgi.com Mon Mar 19 16:14:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2K0EFQ13333 for linux-mips-outgoing; Mon, 19 Mar 2001 16:14:15 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2K0EEM13330 for ; Mon, 19 Mar 2001 16:14:14 -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 QAA12375; Mon, 19 Mar 2001 16:14:14 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA21348; Mon, 19 Mar 2001 16:14:11 -0800 (PST) Message-ID: <01e701c0b0d3$3fca8980$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" , References: <3AB68CFC.A2840808@mvista.com> Subject: Re: gdb 5.0 display arguments problem Date: Tue, 20 Mar 2001 01:18:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2613 Lines: 59 > I am using gdb 5.0 client to debug kernel, and found a bug in gdb 5.0 when it > trys to display an function argument. ... > For whatever reason gdb client on the host side apparently thinks the second > arg is stored in register s4. When the breakpoint is hit, gdb tries to > display the value of s4 (which is 0x4 in this case). Since the type of this > argument is char *, gdb further tries to read the content at 0x4 which causes > kernel panic. > > I believe I have seen this problem before (and in most case the symptom is > wrong argument values instead of kernel panic). Does someone have an idea how > to fix it or work around it? I had exactly the same problem with earlier versions of gdb (4.18 if I recall), though for me the problem was invariably provoked by my asking "where" on a deeply nested set of stack frames. I had always believed that the problem stemmed from the fact that the compiler, when invoked with the options used to build the Linux kernel in any case, is under no obligation to preserve the values of its incoming arguments past their useful life within the called function. If the arguments are consumed before the next use of the register, they are never saved. So sooner or later, the back trace comes to a function for which the argument storage on the stack frame is uninitialized garbage. That problem should, in theory, be fixable by compiling with a set of options that force the arguments to be stored in the stack frame. Yours may well be slightly different, but fatal for the same reason. > Does this problem exist in native debugging? Yes, but in that case all you get is a bogus reported argument. The problem is that the kgdb "agent" in the kernel is being passed a bogus pointer, and is dereferencing it mindlessly (and fatally). > I assume we can disable gdb to display char strings by default. Does someone > know how to do it? I tried fixing it with a hack to the exception handling code, inspired by the old Cobalt MIPS kernel code, such that the kgdb agent's proxy references could fail in a non-fatal manner. I never did get it to work. It probably would be easy to cripple gdb to not automatically dereference pointer arguments, perhaps only in remote mode and perhaps only if some magic flag is set. But it *is* nice to see the string arguments when they are sane. A cleaner approach might be to have the proxy use a high level VM routine to check the validity of each address before dereferencing, but it's not clear that it's actually safe to invoke such routines from the level at which the kgdb proxy is executing. Kevin K. From owner-linux-mips@oss.sgi.com Mon Mar 19 18:57:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2K2vkM16425 for linux-mips-outgoing; Mon, 19 Mar 2001 18:57:46 -0800 Received: from surfers.oz.agile.tv (agile-50.OntheNet.com.au [203.144.13.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2K2vhM16421 for ; Mon, 19 Mar 2001 18:57:44 -0800 Received: from oz.agile.tv (IDENT:simong@pacific.oz.agile.tv [192.168.16.16]) by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f2K2vgw29946 for ; Tue, 20 Mar 2001 12:57:42 +1000 Message-ID: <3AB6C948.7F8EE4B7@oz.agile.tv> Date: Tue, 20 Mar 2001 13:06:48 +1000 From: Simon Gee X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Recommended toolchain Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 444 Lines: 13 Hello, Recently I've been working with various version mixes of the gnu tool chain for a mipsel-linux target and settled on a patchy binutils 2.8.1/egcs 1.1.2/glibc 2.0.6 setup. However this lacks the functionality that I would get from a newer toolchain for use with the linux 2.4 kernel. As a result, I was wondering if someone could recommend the latest "stable"/recommended toolchain for a mipsel-linux target. Thanks in advance, Simon From owner-linux-mips@oss.sgi.com Tue Mar 20 01:05:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2K95s221919 for linux-mips-outgoing; Tue, 20 Mar 2001 01:05:54 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2K95rM21916 for ; Tue, 20 Mar 2001 01:05:53 -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 BAA15851; Tue, 20 Mar 2001 01:05:53 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA03412; Tue, 20 Mar 2001 01:05:50 -0800 (PST) Message-ID: <004601c0b11d$86340d20$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Kevin D. Kissell" , "Jun Sun" , References: <3AB68CFC.A2840808@mvista.com> <01e701c0b0d3$3fca8980$0deca8c0@Ulysses> Subject: Re: gdb 5.0 display arguments problem Date: Tue, 20 Mar 2001 10:09:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3315 Lines: 71 Followups on my own message of last night. > I had exactly the same problem with earlier versions of gdb (4.18 > if I recall), though for me the problem was invariably provoked by my > asking "where" on a deeply nested set of stack frames. I had always > believed that the problem stemmed from the fact that the compiler, > when invoked with the options used to build the Linux kernel in any > case, is under no obligation to preserve the values of its incoming > arguments past their useful life within the called function. If the > arguments are consumed before the next use of the register, > they are never saved. So sooner or later, the back trace comes to > a function for which the argument storage on the stack frame is > uninitialized garbage. > > That problem should, in theory, be fixable by compiling with > a set of options that force the arguments to be stored in the > stack frame. I've experimented around a bit, and so far, the only way I can find that ensures that the argument values are preserved all the way back down a calling chain is to use no "-O" optimisation whatsoever. The code us huge and grotesque, but arguments are systematically saved in the stack frame in their allotted, caller-allocated slots. Even then I also need to compile with -g if I want gdb (native 4.17) to be able to do a correct backtrace even of user-mode code. > Yours may well be slightly different, but fatal for the same reason. Indeed, I wonder if your gdb isn't looking on the stack frame for an argument that isn't there - and which may never be there - and finding the value that also happens to be in s4. > > Does this problem exist in native debugging? > > Yes, but in most cases all you get is a bogus reported argument. Or a truncated back trace. In the worst case, you do get a gdb crash/core dump. > The problem is that the kgdb "agent" in the kernel is being passed > a bogus pointer, and is dereferencing it mindlessly (and fatally). > > > I assume we can disable gdb to display char strings by default. > > Does someone know how to do it? > > I tried fixing it with a hack to the exception handling code, > inspired by the old Cobalt MIPS kernel code, such that the > kgdb agent's proxy references could fail in a non-fatal manner. > I never did get it to work. It probably would be easy to cripple > gdb to not automatically dereference pointer arguments, perhaps > only in remote mode and perhaps only if some magic flag is set. > But it *is* nice to see the string arguments when they are sane. > A cleaner approach might be to have the proxy use a high level > VM routine to check the validity of each address before > dereferencing, but it's not clear that it's actually safe to invoke > such routines from the level at which the kgdb proxy is executing. Another reason to fix things in the gdb proxy/exception code rather than cripple gdb backtrace is that, even with the backtrace fixed, the current kgdb situation is such that the slightest typo at the debugger operator interface can generate a bad address and blow the system sky high. It's happened to me on more than one occasion. Fortunately, what I was debugging at the time was readily reproduceable (if not, I would have fixed the kgdb problem then and there!). Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Mar 20 11:30:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2KJUi300884 for linux-mips-outgoing; Tue, 20 Mar 2001 11:30:44 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2KJUhM00881 for ; Tue, 20 Mar 2001 11:30:43 -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 f2KJRT023125; Tue, 20 Mar 2001 11:27:30 -0800 Message-ID: <3AB7AEFD.5B773122@mvista.com> Date: Tue, 20 Mar 2001 11:26:53 -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: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: gdb 5.0 display arguments problem References: <3AB68CFC.A2840808@mvista.com> <01e701c0b0d3$3fca8980$0deca8c0@Ulysses> <004601c0b11d$86340d20$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1790 Lines: 39 "Kevin D. Kissell" wrote: > > > Yours may well be slightly different, but fatal for the same reason. > > Indeed, I wonder if your gdb isn't looking on the stack frame > for an argument that isn't there - and which may never be > there - and finding the value that also happens to be in s4. > I think I figured out the reason. If you take a look of the code segment I attached in my first posting, you will see that s4 register indeed holds the value of a1, and presummably remains so for the rest of the function. However, the actual assignment of a1 to s4 does not happen until a couple of instructions later into the function. So if the breakpoint is set at the first instruction of the function, gdb would still think (wrongly) s4 holds the 2nd argument and, even worse, try to dereference it if it is a char* pointer. > > Another reason to fix things in the gdb proxy/exception code > rather than cripple gdb backtrace is that, even with the backtrace > fixed, the current kgdb situation is such that the slightest typo > at the debugger operator interface can generate a bad address > and blow the system sky high. It's happened to me on more than > one occasion. Fortunately, what I was debugging at the time > was readily reproduceable (if not, I would have fixed the kgdb > problem then and there!). > This sounds pretty cool, but I don't see a clean algorithm. So in the exception code you would decide not to crash if 1)kgdb is configured, and 2) the exception is caused by kgdb code (how?). Also if you decide not to crash, what should be reasonable return values? Disable automatic char * dereferencing is not that bad. You always have the option to manually dereference it. However, I could not find such an option. Maybe gdb does not provide that yet. Jun From owner-linux-mips@oss.sgi.com Tue Mar 20 12:12:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2KKC7o01771 for linux-mips-outgoing; Tue, 20 Mar 2001 12:12:07 -0800 Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2KKC6M01768 for ; Tue, 20 Mar 2001 12:12:06 -0800 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01K1FMPIY3EA000MBZ@research.kpn.com> for linux-mips@oss.sgi.com; Tue, 20 Mar 2001 21:12:04 +0100 Received: (from karel@localhost) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) id VAA07412; Tue, 20 Mar 2001 21:12:03 +0100 (MET) X-URL: http://www-lsdm.research.kpn.com/~karel Date: Tue, 20 Mar 2001 21:12:02 +0100 (MET) From: Karel van Houten Subject: Re: Recommended toolchain In-reply-to: <3AB6C948.7F8EE4B7@oz.agile.tv> To: simong@oz.agile.tv (Simon Gee) Cc: linux-mips@oss.sgi.com Message-id: <200103202012.VAA07412@sparta.research.kpn.com> MIME-version: 1.0 X-Mailer: ELM [version 2.5 PL2] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 989 Lines: 25 Hi Simon, You wrote: > Recently I've been working with various version mixes of the gnu tool > chain for a mipsel-linux target and settled on a patchy binutils > 2.8.1/egcs 1.1.2/glibc 2.0.6 setup. However this lacks the functionality > that I would get from a newer toolchain for use with the linux 2.4 > kernel. As a result, I was wondering if someone could recommend the > latest "stable"/recommended toolchain for a mipsel-linux target. Well, I'm currently using: binutils 2.10.1 gcc 2.95.3 (with Maciej's patches) glibc 2.2.2 (compiled with above toolchain). This toolchain works for native compiles on my mipsel box. One drawback: I can't compile any kernels with this setup, For kernel compiles I use 2.8.1/egcs-2.90.27/glibc-2.0.6. -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Tue Mar 20 12:46:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2KKkDQ02522 for linux-mips-outgoing; Tue, 20 Mar 2001 12:46:13 -0800 Received: from dea.waldorf-gmbh.de (u-194-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2KKiYM02507 for ; Tue, 20 Mar 2001 12:44:55 -0800 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f2KKbFa04011; Tue, 20 Mar 2001 21:37:15 +0100 Date: Tue, 20 Mar 2001 21:37:15 +0100 From: Ralf Baechle To: Karel van Houten Cc: simong@oz.agile.tv (Simon Gee), linux-mips@oss.sgi.com Subject: Re: Recommended toolchain Message-ID: <20010320213715.C3763@bacchus.dhis.org> References: <3AB6C948.7F8EE4B7@oz.agile.tv> <200103202012.VAA07412@sparta.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103202012.VAA07412@sparta.research.kpn.com>; from K.H.C.vanHouten@research.kpn.com on Tue, Mar 20, 2001 at 09:12:02PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 925 Lines: 23 On Tue, Mar 20, 2001 at 09:12:02PM +0100, Karel van Houten wrote: > You wrote: > > Recently I've been working with various version mixes of the gnu tool > > chain for a mipsel-linux target and settled on a patchy binutils > > 2.8.1/egcs 1.1.2/glibc 2.0.6 setup. However this lacks the functionality > > that I would get from a newer toolchain for use with the linux 2.4 > > kernel. As a result, I was wondering if someone could recommend the > > latest "stable"/recommended toolchain for a mipsel-linux target. > > Well, I'm currently using: > binutils 2.10.1 > gcc 2.95.3 (with Maciej's patches) > glibc 2.2.2 (compiled with above toolchain). > > This toolchain works for native compiles on my mipsel box. > One drawback: I can't compile any kernels with this setup, > For kernel compiles I use 2.8.1/egcs-2.90.27/glibc-2.0.6. You MUST use minimum egcs-2.91.66 (1.1.2); older compilers WILL misscompile kernels. Ralf From owner-linux-mips@oss.sgi.com Tue Mar 20 14:12:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2KMCDU04120 for linux-mips-outgoing; Tue, 20 Mar 2001 14:12:13 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2KMCCM04117 for ; Tue, 20 Mar 2001 14:12:12 -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 OAA23304; Tue, 20 Mar 2001 14:12:12 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA28544; Tue, 20 Mar 2001 14:12:09 -0800 (PST) Message-ID: <002d01c0b18b$5f512da0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: References: <3AB68CFC.A2840808@mvista.com> <01e701c0b0d3$3fca8980$0deca8c0@Ulysses> <004601c0b11d$86340d20$0deca8c0@Ulysses> <3AB7AEFD.5B773122@mvista.com> Subject: Re: gdb 5.0 display arguments problem Date: Tue, 20 Mar 2001 23:16:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2890 Lines: 67 > "Kevin D. Kissell" wrote: > > > > > Yours may well be slightly different, but fatal for the same reason. > > > > Indeed, I wonder if your gdb isn't looking on the stack frame > > for an argument that isn't there - and which may never be > > there - and finding the value that also happens to be in s4. > > > > I think I figured out the reason. If you take a look of the code segment I > attached in my first posting, you will see that s4 register indeed holds the > value of a1, and presummably remains so for the rest of the function. > However, the actual assignment of a1 to s4 does not happen until a couple of > instructions later into the function. So if the breakpoint is set at the > first instruction of the function, gdb would still think (wrongly) s4 holds > the 2nd argument and, even worse, try to dereference it if it is a char* > pointer. It's not unusual to need to step one line to "see" arguments correctly. A pity about the pointer dereference. ;-) > > Another reason to fix things in the gdb proxy/exception code > > rather than cripple gdb backtrace is that, even with the backtrace > > fixed, the current kgdb situation is such that the slightest typo > > at the debugger operator interface can generate a bad address > > and blow the system sky high. It's happened to me on more than > > one occasion. Fortunately, what I was debugging at the time > > was readily reproduceable (if not, I would have fixed the kgdb > > problem then and there!). > > > > This sounds pretty cool, but I don't see a clean algorithm. So in the > exception code you would decide not to crash if 1)kgdb is configured, and 2) > the exception is caused by kgdb code (how?). Also if you decide not to crash, > what should be reasonable return values? There are a number of possible ways of going about it. One is to set some kind of flag during the kgdb proxy access, which is tested by the page fault code. That's the stuff that's derived from Cobalt code and that is partly in place in some existing kernel gdb support ("debugmem_got_flt", etc.). I have not seen it work correcly, and isn't SMP safe. Another scheme, which is actually a bit cleaner, would be to check explicitly for the faulting address to be that of the kgdb proxy load. In any case, once the case has been identified, one tweaks the EPC value to return to something other than a repeat of the bad dereference, and returns zero or an error value to gdb - the protocol and message formats are described in comments in gdb-stub.c. > Disable automatic char * dereferencing is not that bad. You always have the > option to manually dereference it. However, I could not find such an option. > Maybe gdb does not provide that yet. And even if it did, accidentally trying to dump "0x8021f34" would blow you out of the water. It's the kernel proxy code that really needs to be fixed. Kevin K. From owner-linux-mips@oss.sgi.com Tue Mar 20 15:59:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2KNxxS06175 for linux-mips-outgoing; Tue, 20 Mar 2001 15:59:59 -0800 Received: from tower.ti.com (tower.ti.com [192.94.94.5]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2KNxwM06172 for ; Tue, 20 Mar 2001 15:59:58 -0800 Received: from dlep6.itg.ti.com ([157.170.188.9]) by tower.ti.com (8.11.1/8.11.1) with ESMTP id f2KNxqr06585 for ; Tue, 20 Mar 2001 17:59:52 -0600 (CST) Received: from dlep6.itg.ti.com (localhost [127.0.0.1]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA28454 for ; Tue, 20 Mar 2001 17:59:52 -0600 (CST) Received: from dlep3.itg.ti.com (dlep3-maint.itg.ti.com [157.170.133.16]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA28449 for ; Tue, 20 Mar 2001 17:59:51 -0600 (CST) Received: from ti.com (IDENT:bbrown@bbrowndt.sc.ti.com [158.218.100.126]) by dlep3.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA08478 for ; Tue, 20 Mar 2001 17:59:51 -0600 (CST) Message-ID: <3AB7EFF7.A20E4FF3@ti.com> Date: Tue, 20 Mar 2001 17:04:07 -0700 From: Brady Brown Organization: Texas Instruments X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: SGI news group Subject: Sign extended 64bit address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 432 Lines: 11 I have run into the earlier mentioned problem of objcopy not correctly dealing with the sign extended 64 bit address generated by the new tools. Is there an update on this issue? Any good work-arounds or short time solutions? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brady Brown (bbrown@ti.com) Work:(801)619-6103 Texas Instruments: Broadband Access Group ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-linux-mips@oss.sgi.com Tue Mar 20 19:10:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2L3AOW09803 for linux-mips-outgoing; Tue, 20 Mar 2001 19:10:24 -0800 Received: from vms1.rit.edu (vms1.isc.rit.edu [129.21.3.8]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2L3AMM09800 for ; Tue, 20 Mar 2001 19:10:22 -0800 Received: from nerd-box.rit.edu ([129.21.134.39]) by ritvax.isc.rit.edu (PMDF V5.2-32 #41784) with ESMTPA id <01K1FOQDF368Y8EOAF@ritvax.isc.rit.edu> for linux-mips@oss.sgi.com; Tue, 20 Mar 2001 22:10:10 EST Date: Tue, 20 Mar 2001 22:12:07 -0800 From: jsc6233@ritvax.isc.rit.edu Subject: indy R5000 with irix 6.5 X-Sender: jsc6233@vmspop.isc.rit.edu To: linux-mips@oss.sgi.com Message-id: <5.0.0.25.0.20010320221021.00a47cc0@vmspop.isc.rit.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 140 Lines: 6 Hey, Has anyone been able to compile the kernel on an indy R5000 running IRIX 6.5?? I have been working with Linux 2.3.12. Thanks, James From owner-linux-mips@oss.sgi.com Tue Mar 20 20:06:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2L46a310877 for linux-mips-outgoing; Tue, 20 Mar 2001 20:06:36 -0800 Received: from dea.waldorf-gmbh.de (u-251-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.251]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2L46XM10874 for ; Tue, 20 Mar 2001 20:06:34 -0800 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f2L447j03282; Wed, 21 Mar 2001 05:04:07 +0100 Date: Wed, 21 Mar 2001 05:04:07 +0100 From: Ralf Baechle To: Brady Brown Cc: SGI news group Subject: Re: Sign extended 64bit address Message-ID: <20010321050407.A3261@bacchus.dhis.org> References: <3AB7EFF7.A20E4FF3@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AB7EFF7.A20E4FF3@ti.com>; from bbrown@ti.com on Tue, Mar 20, 2001 at 05:04:07PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 496 Lines: 12 On Tue, Mar 20, 2001 at 05:04:07PM -0700, Brady Brown wrote: > I have run into the earlier mentioned problem of objcopy not correctly > dealing with the sign extended 64 bit address generated by the new > tools. Is there an update on this issue? Any good work-arounds or short > time solutions? I don't have your old report at hand but somewhen during the past year binutils received a number of fixes related to signed/unsigned addresses, so you should try a recent copy of binutils. Ralf From owner-linux-mips@oss.sgi.com Tue Mar 20 20:39:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2L4dJV11550 for linux-mips-outgoing; Tue, 20 Mar 2001 20:39:19 -0800 Received: from dea.waldorf-gmbh.de (u-251-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.251]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2L4dGM11547 for ; Tue, 20 Mar 2001 20:39:16 -0800 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f2L4d2U03572; Wed, 21 Mar 2001 05:39:02 +0100 Date: Wed, 21 Mar 2001 05:39:02 +0100 From: Ralf Baechle To: jsc6233@ritvax.isc.rit.edu Cc: linux-mips@oss.sgi.com Subject: Re: indy R5000 with irix 6.5 Message-ID: <20010321053901.B3261@bacchus.dhis.org> References: <5.0.0.25.0.20010320221021.00a47cc0@vmspop.isc.rit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20010320221021.00a47cc0@vmspop.isc.rit.edu>; from jsc6233@ritvax.isc.rit.edu on Tue, Mar 20, 2001 at 10:12:07PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 312 Lines: 12 On Tue, Mar 20, 2001 at 10:12:07PM -0800, jsc6233@ritvax.isc.rit.edu wrote: > Hey, > Has anyone been able to compile the kernel on an indy R5000 running IRIX > 6.5?? I have been working with Linux 2.3.12. Yes. (This answer will hardly satisfy you but it's the accurate answer to your question ...) Ralf From owner-linux-mips@oss.sgi.com Tue Mar 20 22:14:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2L6Ep013527 for linux-mips-outgoing; Tue, 20 Mar 2001 22:14:51 -0800 Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2L6ElM13524 for ; Tue, 20 Mar 2001 22:14:48 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id LAA20400 for ; Wed, 21 Mar 2001 11:54:28 GMT Received: from ecvwall1.wipro.com ([192.168.181.23]) by ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GAJANH00.BUR for ; Wed, 21 Mar 2001 11:44:05 +0530 Received: from wipro.com ([192.168.225.15]) by helium.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA5E8C for ; Wed, 21 Mar 2001 11:42:31 +0530 Message-ID: <3AB84780.1027AE90@wipro.com> Date: Wed, 21 Mar 2001 11:47:36 +0530 From: "chandra shekhar" Reply-To: chandra.shekhar@wipro.com Organization: Wipro X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: kernel-header RPM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 148 Lines: 9 Hello I am searching for kenel-header RPM for Big Endian MIPS. Could you please tell me the location from where I can download. Regards, Chandra From owner-linux-mips@oss.sgi.com Tue Mar 20 23:58:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2L7wDk17636 for linux-mips-outgoing; Tue, 20 Mar 2001 23:58:13 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2L7wCM17633 for ; Tue, 20 Mar 2001 23:58:13 -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 XAA27934 for ; Tue, 20 Mar 2001 23:58:13 -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 XAA14201 for ; Tue, 20 Mar 2001 23:58:10 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id IAA07615 for ; Wed, 21 Mar 2001 08:57:40 +0100 (MET) Message-ID: <3AB85EF4.B9ED386B@mips.com> Date: Wed, 21 Mar 2001 08:57:40 +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: linux-mips@oss.sgi.com Subject: [Fwd: Re: Bug in the _save_fp_context.] Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3530 Lines: 98 No one seem to answer on my previous mail, regarding the problem in the _save_fp_context function in arch/mips/kernel/r4k_fpu.S. What about you Ralf, any comments ? /Carsten -------- Original Message -------- Subject: Re: Bug in the _save_fp_context. Date: Mon, 19 Mar 2001 17:13:06 +0100 From: Carsten Langgaard To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com References: <3AB61293.5652407C@mips.com> <00e901c0b08b$50bed400$0deca8c0@Ulysses> "Kevin D. Kissell" wrote: > > I think there is a bug in the _save_fp_context function in > > arch/mips/kernel/r4k_fpu.S > > > > The problem is the following piece of code: > > > > jr ra > > .set nomacro > > EX(sw t0,SC_FPC_EIR(a0)) > > nop > > .set macro > > > > First of all what should the ".set nomacro" do? > > If it means that the EX macro shouldn't be used then this entry wouldn't > > get into __ex_table, which would be wrong. > > But it look like it uses the macro anyway, regardless of the ".set > > nomacro", at least with the compiler I use. > > Not surprising, really. "EX" is presumably a cpp macro > that gets expanded by gcc from the .S file, based on > some include file. .set directives affect only the assembler, > and would inhibit assembler-level macros only. I'm not > sure just what the definition of an assembler macro > would be - it may or may not include pseudo-instructions > like "la" or "li 32_bit_constant". I *think* that what the > author was trying to do here was to ensure that the > "sw" instruction in the EX expansion was really and > truly a single instruction. > > > Never the less we do not handle entries in the __ex_table which is > > located in a branch delay. > > So we need to handle the situation where we take a page fault on an > > instruction which is located in a brach delay slot, or we don't put the > > "potential" faulting instruction in a delay slot. > > > > Any ideas, how we should handle this in a nice and clean way? > > Is the __ex_table really ending up in the delay slot? > Just looking at the source, I have the impression > that the "sw t0,..." instruction should be in the delay > slot, followed by the __ex_table. The problem is that the address of the delay slot is put in the __ex_table and then we take a page fault EPC is pointing at the jr instruction and not the delay slot. This result in a miss match when we try to lookup in __ex_table, resulting in a kernel crash. The faulting situation look like this: EPC = address of delay slot entry in __ex_table = address of delay slot - 4 Hopes that clarify it a bit more. > > On another topic, now that I've patched the kernel to > turn off the stupid stuck interrupt on my Malta board, > I've realized that I can't just connect my old Atlas SCSI > disk. I'm torn between ordering a Tekram 390 PCI > SCSI card, which should be able to use our "MIPS > safe" NCR driver as-is (I hope) and buying an IDE > disk and going through the network install ritual. > Which do you recommend? One thing I really never > knew was just what kernel config options I need to > select to build a kernel that can do the NFS-root > bootstrap. Can you help me there? > > Regards, > > Kevin K. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Mar 21 06:01:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LE1UC26497 for linux-mips-outgoing; Wed, 21 Mar 2001 06:01:30 -0800 Received: from exchange1.cam.pace.co.uk (host-131-80.pace.co.uk [136.170.131.80]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2LE1SM26494 for ; Wed, 21 Mar 2001 06:01:29 -0800 Received: by exchange1 with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Mar 2001 14:00:24 -0000 Message-ID: <1402C4C025C4D311B50D00508B8B74E281B14D@exchange1> From: Phil Thompson To: "'linux-mips@oss.sgi.com'" Subject: RE: Recommended toolchain Date: Wed, 21 Mar 2001 14:00:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1431 Lines: 41 So, going back to the original question, what are the recommended versions - particularly if you are building 2.4.x kernels? Are the recomendations in the HOWTO out of date? I had to patch va-mips.h from the egcs RPM and more fixes seem to be needed before I get a kernel that compiles. Thanks, Phil -----Original Message----- From: Ralf Baechle [mailto:ralf@oss.sgi.com] Sent: 20 March 2001 20:37 To: Karel van Houten Cc: simong@oz.agile.tv; linux-mips@oss.sgi.com Subject: Re: Recommended toolchain On Tue, Mar 20, 2001 at 09:12:02PM +0100, Karel van Houten wrote: > You wrote: > > Recently I've been working with various version mixes of the gnu tool > > chain for a mipsel-linux target and settled on a patchy binutils > > 2.8.1/egcs 1.1.2/glibc 2.0.6 setup. However this lacks the functionality > > that I would get from a newer toolchain for use with the linux 2.4 > > kernel. As a result, I was wondering if someone could recommend the > > latest "stable"/recommended toolchain for a mipsel-linux target. > > Well, I'm currently using: > binutils 2.10.1 > gcc 2.95.3 (with Maciej's patches) > glibc 2.2.2 (compiled with above toolchain). > > This toolchain works for native compiles on my mipsel box. > One drawback: I can't compile any kernels with this setup, > For kernel compiles I use 2.8.1/egcs-2.90.27/glibc-2.0.6. You MUST use minimum egcs-2.91.66 (1.1.2); older compilers WILL misscompile kernels. Ralf From owner-linux-mips@oss.sgi.com Wed Mar 21 07:09:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LF9k929394 for linux-mips-outgoing; Wed, 21 Mar 2001 07:09:46 -0800 Received: from mta5.snfc21.pbi.net ([206.13.28.241]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2LF9jM29391 for ; Wed, 21 Mar 2001 07:09:45 -0800 Received: from shaft ([209.233.126.43]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0GAJ005WTZBZ1J@mta5.snfc21.pbi.net> for linux-mips@oss.sgi.com; Wed, 21 Mar 2001 07:07:11 -0800 (PST) Date: Wed, 21 Mar 2001 07:11:46 -0500 From: Erik Mullinix Subject: Re: Recommended toolchain To: Phil Thompson , linux-mips@oss.sgi.com Message-id: <001a01c0b200$1c13d5e0$0500a8c0@shaft> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 References: <1402C4C025C4D311B50D00508B8B74E281B14D@exchange1> X-Priority: 3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1725 Lines: 55 What Error's are you getting? Hesp ----- Original Message ----- From: "Phil Thompson" To: Sent: Wednesday, March 21, 2001 9:00 AM Subject: RE: Recommended toolchain > So, going back to the original question, what are the recommended versions - > particularly if you are building 2.4.x kernels? > > Are the recomendations in the HOWTO out of date? I had to patch va-mips.h > from the egcs RPM and more fixes seem to be needed before I get a kernel > that compiles. > > Thanks, > Phil > > -----Original Message----- > From: Ralf Baechle [mailto:ralf@oss.sgi.com] > Sent: 20 March 2001 20:37 > To: Karel van Houten > Cc: simong@oz.agile.tv; linux-mips@oss.sgi.com > Subject: Re: Recommended toolchain > > > On Tue, Mar 20, 2001 at 09:12:02PM +0100, Karel van Houten wrote: > > > You wrote: > > > Recently I've been working with various version mixes of the gnu tool > > > chain for a mipsel-linux target and settled on a patchy binutils > > > 2.8.1/egcs 1.1.2/glibc 2.0.6 setup. However this lacks the functionality > > > that I would get from a newer toolchain for use with the linux 2.4 > > > kernel. As a result, I was wondering if someone could recommend the > > > latest "stable"/recommended toolchain for a mipsel-linux target. > > > > Well, I'm currently using: > > binutils 2.10.1 > > gcc 2.95.3 (with Maciej's patches) > > glibc 2.2.2 (compiled with above toolchain). > > > > This toolchain works for native compiles on my mipsel box. > > One drawback: I can't compile any kernels with this setup, > > For kernel compiles I use 2.8.1/egcs-2.90.27/glibc-2.0.6. > > You MUST use minimum egcs-2.91.66 (1.1.2); older compilers WILL misscompile > kernels. > > Ralf > From owner-linux-mips@oss.sgi.com Wed Mar 21 08:06:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LG6pu31576 for linux-mips-outgoing; Wed, 21 Mar 2001 08:06:51 -0800 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2LG6oM31573 for ; Wed, 21 Mar 2001 08:06:50 -0800 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id A3C24109CE; Wed, 21 Mar 2001 08:07:15 -0800 (PST) Received: by galt.foobazco.org (Postfix, from userid 1014) id E00901F429; Wed, 21 Mar 2001 08:06:47 -0800 (PST) Date: Wed, 21 Mar 2001 08:06:47 -0800 From: Keith M Wesolowski To: Phil Thompson Cc: linux-mips@oss.sgi.com Subject: Re: Recommended toolchain Message-ID: <20010321080647.A4223@foobazco.org> References: <1402C4C025C4D311B50D00508B8B74E281B14D@exchange1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1402C4C025C4D311B50D00508B8B74E281B14D@exchange1>; from Phil.Thompson@pace.co.uk on Wed, Mar 21, 2001 at 02:00:22PM -0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 824 Lines: 18 On Wed, Mar 21, 2001 at 02:00:22PM -0000, Phil Thompson wrote: > So, going back to the original question, what are the recommended versions - > particularly if you are building 2.4.x kernels? I don't really know that there is one. I am using the gcc 3.0 branch and binutils from CVS (2.11.90). You can find the same toolchain that's building my kernels on ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev at all times, including patches. No binaries, source and patches only. This linker has a bug in it regarding section placement, but the current cvs kernel has a workaround for it. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "I should have crushed his marketing-addled skull with a fucking bat." From owner-linux-mips@oss.sgi.com Wed Mar 21 08:54:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LGssX00697 for linux-mips-outgoing; Wed, 21 Mar 2001 08:54:54 -0800 Received: from tower.ti.com (tower.ti.com [192.94.94.5]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2LGsiM00689; Wed, 21 Mar 2001 08:54:45 -0800 Received: from dlep8.itg.ti.com ([157.170.134.88]) by tower.ti.com (8.11.1/8.11.1) with ESMTP id f2LGscr26808; Wed, 21 Mar 2001 10:54:38 -0600 (CST) Received: from dlep8.itg.ti.com (localhost [127.0.0.1]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA13329; Wed, 21 Mar 2001 10:54:37 -0600 (CST) Received: from dlep3.itg.ti.com (dlep3-maint.itg.ti.com [157.170.133.16]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA13325; Wed, 21 Mar 2001 10:54:37 -0600 (CST) Received: from ti.com (IDENT:bbrown@bbrowndt.sc.ti.com [158.218.100.126]) by dlep3.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA16934; Wed, 21 Mar 2001 10:54:37 -0600 (CST) Message-ID: <3AB8DDCE.CA0F16BC@ti.com> Date: Wed, 21 Mar 2001 09:58:54 -0700 From: Brady Brown Organization: Texas Instruments X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: SGI news group Subject: Re: Sign extended 64bit address References: <3AB7EFF7.A20E4FF3@ti.com> <20010321050407.A3261@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 644 Lines: 19 Ralf Baechle wrote: > On Tue, Mar 20, 2001 at 05:04:07PM -0700, Brady Brown wrote: > > > I have run into the earlier mentioned problem of objcopy not correctly > > dealing with the sign extended 64 bit address generated by the new > > tools. Is there an update on this issue? Any good work-arounds or short > > time solutions? > > I don't have your old report at hand but somewhen during the past year > binutils received a number of fixes related to signed/unsigned addresses, > so you should try a recent copy of binutils. > > Ralf I'm currently using binutils-2.10.91-2 from Maciej's site. Is there a later rev that I should look at? From owner-linux-mips@oss.sgi.com Wed Mar 21 09:10:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LHAw101454 for linux-mips-outgoing; Wed, 21 Mar 2001 09:10:58 -0800 Received: from dea.waldorf-gmbh.de (u-136-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.136]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2LHAsM01451 for ; Wed, 21 Mar 2001 09:10:55 -0800 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f2LHAIN07291; Wed, 21 Mar 2001 18:10:18 +0100 Date: Wed, 21 Mar 2001 18:10:18 +0100 From: Ralf Baechle To: Brady Brown Cc: SGI news group Subject: Re: Sign extended 64bit address Message-ID: <20010321181017.A7274@bacchus.dhis.org> References: <3AB7EFF7.A20E4FF3@ti.com> <20010321050407.A3261@bacchus.dhis.org> <3AB8DDCE.CA0F16BC@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AB8DDCE.CA0F16BC@ti.com>; from bbrown@ti.com on Wed, Mar 21, 2001 at 09:58:54AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 749 Lines: 18 On Wed, Mar 21, 2001 at 09:58:54AM -0700, Brady Brown wrote: > > > I have run into the earlier mentioned problem of objcopy not correctly > > > dealing with the sign extended 64 bit address generated by the new > > > tools. Is there an update on this issue? Any good work-arounds or short > > > time solutions? > > > > I don't have your old report at hand but somewhen during the past year > > binutils received a number of fixes related to signed/unsigned addresses, > > so you should try a recent copy of binutils. > > I'm currently using binutils-2.10.91-2 from Maciej's site. Is there a later > rev that I should look at? I was believing that that one is good; can you resend your bugreport about the sign extension problem? Thanks. Ralf From owner-linux-mips@oss.sgi.com Wed Mar 21 09:39:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LHdnA02642 for linux-mips-outgoing; Wed, 21 Mar 2001 09:39:49 -0800 Received: from nilpferd.fachschaften.tu-muenchen.de (nilpferd.fachschaften.tu-muenchen.de [129.187.176.79]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f2LHdmM02639 for ; Wed, 21 Mar 2001 09:39:48 -0800 Received: (qmail 8747 invoked from network); 21 Mar 2001 17:39:46 -0000 Received: from gaia.fachschaften.tu-muenchen.de (129.187.176.73) by nilpferd.fachschaften.tu-muenchen.de with SMTP; 21 Mar 2001 17:39:46 -0000 Date: Wed, 21 Mar 2001 18:39:48 +0100 (CET) From: Adrian Bunk X-X-Sender: To: Subject: Re: Compile error with current CVS kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 707 Lines: 30 Hi Ralf, the latest CVS kernel still doesn't build, but the error message has changed: <-- snip --> ... mipsel-linux-nm vmlinux | grep -v '$compiled$\|$\.o$$\|$ [aUw] $\|$\.\.ng$$\|$LASH[RL]DI$' | sort > System.map make[1]: Entering directory `/home/bunk/Ringo/linux/arch/mips/boot' gcc -o elf2ecoff elf2ecoff.c ./elf2ecoff /home/bunk/Ringo/linux/vmlinux vmlinux.ecoff -a Sections ordering prevents a.out conversion. make[1]: *** [vmlinux.ecoff] Error 1 make[1]: Leaving directory `/home/bunk/Ringo/linux/arch/mips/boot' make: *** [boot] Error 2 <-- snip --> cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig. From owner-linux-mips@oss.sgi.com Wed Mar 21 10:47:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LIlA704335 for linux-mips-outgoing; Wed, 21 Mar 2001 10:47:10 -0800 Received: from exchange1.cam.pace.co.uk (host-131-80.pace.co.uk [136.170.131.80]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2LIl8M04332 for ; Wed, 21 Mar 2001 10:47:08 -0800 Received: by exchange1 with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Mar 2001 18:46:08 -0000 Message-ID: <1402C4C025C4D311B50D00508B8B74E281B151@exchange1> From: Phil Thompson To: "'Erik Mullinix'" , linux-mips@oss.sgi.com Subject: RE: Recommended toolchain Date: Wed, 21 Mar 2001 18:46:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2469 Lines: 80 I had to patch va-mips.h to #include rather than . The current errors are: - warnings about struct flock64 not being declared (it's defined in asm-mips64/fcntl.h but not asm-mips/fcntl.h) - compilation stops because loops_per_sec is undeclared as far as asm-mips/delay.h is concerned (although it seems fine in asm-mips64/delay.h). This seems to imply that the mips architecture (as opposed to mips64) isn't being maintained. Is this the case? Should I be using mips64 - but what would be the point on an embedded CPU? Thanks, Phil -----Original Message----- From: Erik Mullinix [mailto:Hesp@rainworks.org] Sent: 21 March 2001 12:12 To: Phil Thompson; linux-mips@oss.sgi.com Subject: Re: Recommended toolchain What Error's are you getting? Hesp ----- Original Message ----- From: "Phil Thompson" To: Sent: Wednesday, March 21, 2001 9:00 AM Subject: RE: Recommended toolchain > So, going back to the original question, what are the recommended versions - > particularly if you are building 2.4.x kernels? > > Are the recomendations in the HOWTO out of date? I had to patch va-mips.h > from the egcs RPM and more fixes seem to be needed before I get a kernel > that compiles. > > Thanks, > Phil > > -----Original Message----- > From: Ralf Baechle [mailto:ralf@oss.sgi.com] > Sent: 20 March 2001 20:37 > To: Karel van Houten > Cc: simong@oz.agile.tv; linux-mips@oss.sgi.com > Subject: Re: Recommended toolchain > > > On Tue, Mar 20, 2001 at 09:12:02PM +0100, Karel van Houten wrote: > > > You wrote: > > > Recently I've been working with various version mixes of the gnu tool > > > chain for a mipsel-linux target and settled on a patchy binutils > > > 2.8.1/egcs 1.1.2/glibc 2.0.6 setup. However this lacks the functionality > > > that I would get from a newer toolchain for use with the linux 2.4 > > > kernel. As a result, I was wondering if someone could recommend the > > > latest "stable"/recommended toolchain for a mipsel-linux target. > > > > Well, I'm currently using: > > binutils 2.10.1 > > gcc 2.95.3 (with Maciej's patches) > > glibc 2.2.2 (compiled with above toolchain). > > > > This toolchain works for native compiles on my mipsel box. > > One drawback: I can't compile any kernels with this setup, > > For kernel compiles I use 2.8.1/egcs-2.90.27/glibc-2.0.6. > > You MUST use minimum egcs-2.91.66 (1.1.2); older compilers WILL misscompile > kernels. > > Ralf > From owner-linux-mips@oss.sgi.com Wed Mar 21 11:11:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LJBql05086 for linux-mips-outgoing; Wed, 21 Mar 2001 11:11:52 -0800 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2LJBnM05078; Wed, 21 Mar 2001 11:11:49 -0800 Received: from dlep7.itg.ti.com ([157.170.134.103]) by jester.ti.com (8.11.1/8.11.1) with ESMTP id f2LJBhD03358; Wed, 21 Mar 2001 13:11:43 -0600 (CST) Received: from dlep7.itg.ti.com (localhost [127.0.0.1]) by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id NAA00595; Wed, 21 Mar 2001 13:11:42 -0600 (CST) Received: from dlep3.itg.ti.com (dlep3-maint.itg.ti.com [157.170.133.16]) by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id NAA00585; Wed, 21 Mar 2001 13:11:42 -0600 (CST) Received: from ti.com (IDENT:bbrown@bbrowndt.sc.ti.com [158.218.100.126]) by dlep3.itg.ti.com (8.9.3/8.9.3) with ESMTP id NAA22269; Wed, 21 Mar 2001 13:11:41 -0600 (CST) Message-ID: <3AB8FDEE.95A74D61@ti.com> Date: Wed, 21 Mar 2001 12:15:58 -0700 From: Brady Brown Organization: Texas Instruments X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: SGI news group Subject: Re: Sign extended 64bit address References: <3AB7EFF7.A20E4FF3@ti.com> <20010321050407.A3261@bacchus.dhis.org> <3AB8DDCE.CA0F16BC@ti.com> <20010321181017.A7274@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1778 Lines: 42 Ralf Baechle wrote: > On Wed, Mar 21, 2001 at 09:58:54AM -0700, Brady Brown wrote: > > > > > I have run into the earlier mentioned problem of objcopy not correctly > > > > dealing with the sign extended 64 bit address generated by the new > > > > tools. Is there an update on this issue? Any good work-arounds or short > > > > time solutions? > > > > > > I don't have your old report at hand but somewhen during the past year > > > binutils received a number of fixes related to signed/unsigned addresses, > > > so you should try a recent copy of binutils. > > > > I'm currently using binutils-2.10.91-2 from Maciej's site. Is there a later > > rev that I should look at? > > I was believing that that one is good; can you resend your bugreport > about the sign extension problem? Thanks. > > Ralf Problem solved. Sorry, my oversight. The binutils are correctly handling the addresses. What happened was that the new tools created a couple of new code sections "__ex_table and __dbe_table" that were not handled by the linker script in my kernel (2.4.0-test9), hence ended up a strange low addresses. I interpreted the warnings and the 'wrong' address in the final srec as a address translation problem. Once I added these sections to the linker script the warnings and 'bad' address's went away. A second issue: The kernel built by these new tools will not boot. Complains about illegal instructions as soon as init is launched. The first address that traps is a sw inside the __bzero routine. I'll have to dig a bit here I guess. Any leads would be appreciated. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brady Brown (bbrown@ti.com) Work:(801)619-6103 Texas Instruments: Broadband Access Group ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-linux-mips@oss.sgi.com Wed Mar 21 14:05:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2LM5rv09243 for linux-mips-outgoing; Wed, 21 Mar 2001 14:05:53 -0800 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2LM5qM09240 for ; Wed, 21 Mar 2001 14:05:52 -0800 Received: by mail.foobazco.org (Postfix, from userid 1014) id 66A56109CE; Wed, 21 Mar 2001 14:06:17 -0800 (PST) Date: Wed, 21 Mar 2001 14:06:16 -0800 From: Keith M Wesolowski To: Phil Thompson Cc: "'Erik Mullinix'" , linux-mips@oss.sgi.com Subject: Re: Recommended toolchain Message-ID: <20010321140616.A3956@foobazco.org> References: <1402C4C025C4D311B50D00508B8B74E281B151@exchange1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1402C4C025C4D311B50D00508B8B74E281B151@exchange1>; from Phil.Thompson@pace.co.uk on Wed, Mar 21, 2001 at 06:46:07PM -0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 898 Lines: 21 On Wed, Mar 21, 2001 at 06:46:07PM -0000, Phil Thompson wrote: > - compilation stops because loops_per_sec is undeclared as far as > asm-mips/delay.h is concerned (although it seems fine in > asm-mips64/delay.h). > > This seems to imply that the mips architecture (as opposed to mips64) isn't > being maintained. Is this the case? Should I be using mips64 - but what > would be the point on an embedded CPU? mips(32) is in fact being actively maintained. It sounds like your kernel sources may be out of date; I specifically remember removing all references to loops_per_sec in favour of loops_per_jiffy in both mips and mips64. Ask again about fcntl.h after updating... -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "I should have crushed his marketing-addled skull with a fucking bat." From owner-linux-mips@oss.sgi.com Wed Mar 21 23:50:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2M7oGb21456 for linux-mips-outgoing; Wed, 21 Mar 2001 23:50:16 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2M7oEM21453 for ; Wed, 21 Mar 2001 23:50:14 -0800 Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id IAA26967; Thu, 22 Mar 2001 08:49:32 +0100 (MET) Date: Thu, 22 Mar 2001 08:49:31 +0100 (MET) From: Geert Uytterhoeven To: Phil Thompson cc: "'Erik Mullinix'" , linux-mips@oss.sgi.com Subject: RE: Recommended toolchain In-Reply-To: <1402C4C025C4D311B50D00508B8B74E281B151@exchange1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1007 Lines: 29 On Wed, 21 Mar 2001, Phil Thompson wrote: > I had to patch va-mips.h to #include rather than > . > > The current errors are: > > - warnings about struct flock64 not being declared (it's defined in > asm-mips64/fcntl.h but not asm-mips/fcntl.h) > > - compilation stops because loops_per_sec is undeclared as far as > asm-mips/delay.h is concerned (although it seems fine in > asm-mips64/delay.h). > > This seems to imply that the mips architecture (as opposed to mips64) isn't > being maintained. Is this the case? Should I be using mips64 - but what > would be the point on an embedded CPU? You're definitely not using the Linux/MIPS CVS tree, since these things were fixed there some months ago. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Thu Mar 22 00:41:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2M8faI23310 for linux-mips-outgoing; Thu, 22 Mar 2001 00:41:36 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2M8fZM23307 for ; Thu, 22 Mar 2001 00:41:35 -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 AAA09756; Thu, 22 Mar 2001 00:41:32 -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 AAA24984; Thu, 22 Mar 2001 00:41:29 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id JAA15345; Thu, 22 Mar 2001 09:40:57 +0100 (MET) Message-ID: <3AB9BA99.2599673C@mips.com> Date: Thu, 22 Mar 2001 09:40:57 +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: Karel van Houten CC: linux-mips@oss.sgi.com Subject: Re: rpm crashing on RH 7.0 indy References: <200103171051.LAA04852@pandora.research.kpn.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3889 Lines: 84 Thanks Karel for the RH 7.0 tarball. I have install it and it seems to work fine, except for the RPM stuff. Have you or anyone else managed to get rpm to work ? We really need it to get going. /Carsten Karel van Houten wrote: > Hi all, > > I hope someone can help me with this problem... > > I've installed an Indy with Ralfs Redhat/test-7.0 packages. > Most things work OK, but rpm itself crashes when installing > a package. Here is a trace of what happens: > > (gdb) run > Starting program: /usr/src/redhat/BUILD/rpm-4.0/rpm -ihv /cdrom/mips/XFree86-dev > el-4.0.1-1lm.mips.rpm > > Program received signal SIGSEGV, Segmentation fault. > _dl_lookup_versioned_symbol (undef_name=0x2affa6af "strcpy", > undef_map=0x10075330, ref=0x7fff9818, symbol_scope=0x1007554c, > version=0x100756b0, reloc_type=3, explicit=0) at do-lookup.h:52 > 52 do-lookup.h: No such file or directory. > (gdb) bt > #0 _dl_lookup_versioned_symbol (undef_name=0x2affa6af "strcpy", > undef_map=0x10075330, ref=0x7fff9818, symbol_scope=0x1007554c, > version=0x100756b0, reloc_type=3, explicit=0) at do-lookup.h:52 > #1 0x5c30e4 in _dl_relocate_object () at ../sysdeps/mips/dl-machine.h:684 > #2 0x5b6a40 in dl_open_worker (a=0x1007554c) at dl-open.c:316 > #3 0x5b4a18 in _dl_catch_error (objname=0x7fff9a38, errstring=0x7fff9a3c, > operate=0x5b6470 , args=0x7fff9a28) at dl-error.c:149 > #4 0x5b6ca0 in _dl_open (file=0x7fff9c10 "libnss_nisplus.so.2", mode=1, > caller=0x0) at dl-open.c:380 > #5 0x58882c in do_dlopen (ptr=0x7fff9bf0) at dl-libc.c:78 > #6 0x5b4a18 in _dl_catch_error (objname=0x7fff9bc0, errstring=0x7fff9bc4, > operate=0x5887ec , args=0x7fff9bf0) at dl-error.c:149 > #7 0x5887a4 in dlerror_run (operate=0x1007554c, args=0x0) at dl-libc.c:42 > #8 0x58893c in __libc_dlopen (__name=0x1007554c "\020\b\023\230\020\b\031 ") > at dl-libc.c:104 > #9 0x57d1d0 in __nss_lookup_function (ni=0x10080b80, > fct_name=0x5e3be0 "getpwnam_r") at nsswitch.c:333 > #10 0x57c560 in __nss_lookup (ni=0x7ffff2b0, fct_name=0x5e3be0 "getpwnam_r", > fctp=0x7ffff2b4) at nsswitch.c:148 > #11 0x57e544 in __nss_passwd_lookup (ni=0x7ffff2b0, > fct_name=0x5e3be0 "getpwnam_r", fctp=0x7ffff2b4) at XXX-lookup.c:68 > #12 0x56d7d0 in __getpwnam_r (name=0x5cc34c "root", resbuf=0x10018c08, > buffer=0x10080520 "\020", buflen=1024, result=0x7ffff308) > at ../nss/getXXbyYY_r.c:159 > #13 0x56c9bc in getpwnam (name=0x5cc34c "root") at ../nss/getXXbyYY.c:127 > #14 0x42753c in installBinaryPackage (rootdir=0x1004de50 "/", db=0x1004a688, > fd=0x100a2bb8, h=0x10088890, flags=0, notify=0x438fa0 , > notifyData=0x12, pkgKey=0x7ffff9f6, actions=0x1006edb8, sharedList=0x0, > scriptFd=0x0) at install.c:941 > #15 0x449c20 in rpmRunTransactions (ts=0x1004dde8, > notify=0x438fa0 , notifyData=0x12, okProbs=0x0, > newProbs=0x7ffff6c4, transFlags=0, ignoreSet=0) at transaction.c:1701 > #16 0x439c4c in rpmInstall (rootdir=0x5c917c "/", fileArgv=0x1001faf8, > transFlags=0, interfaceFlags=2, probFilter=0, relocations=0x0) > at rpminstall.c:370 > #17 0x406a2c in main (argc=3, argv=0xffffffff) at rpm.c:1133 > #18 0x53599c in __libc_start_main (main=0x404090

, argc=3, > ubp_av=0x7ffff8d4, init=0x4000f8 <_init>, fini=0x5c6880 <_fini>, > rtld_fini=0, stack_end=0x7ffff8b0) at ../sysdeps/generic/libc-start.c:111 > > This is a static rpm binary, so I don't understand why it tries > do dynaload anything at all... > > Thanks in advance, > -- > Karel van Houten -- _ _ ____ ___ 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 Mar 22 01:40:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2M9eGa24881 for linux-mips-outgoing; Thu, 22 Mar 2001 01:40:16 -0800 Received: from exchange1.cam.pace.co.uk (host-131-80.pace.co.uk [136.170.131.80]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2M9eEM24878 for ; Thu, 22 Mar 2001 01:40:14 -0800 Received: by exchange1 with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Mar 2001 09:39:12 -0000 Message-ID: <1402C4C025C4D311B50D00508B8B74E281B152@exchange1> From: Phil Thompson To: "'Geert Uytterhoeven'" Cc: linux-mips@oss.sgi.com Subject: RE: Recommended toolchain Date: Thu, 22 Mar 2001 09:39:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1603 Lines: 51 Correct - I am using the standard 2.4.2 sources. I had (obviously incorrectly) assumed that the standard sources would be up to date and not "some months" out of date. How are the differences in the two trees managed? At what point are the latest non-MIPS changes applied to the MIPS tree? At what point are the MIPS specific changes applied to the standard tree? Thanks, Phil -----Original Message----- From: Geert Uytterhoeven [mailto:Geert.Uytterhoeven@sonycom.com] Sent: 22 March 2001 07:50 To: Phil Thompson Cc: 'Erik Mullinix'; linux-mips@oss.sgi.com Subject: RE: Recommended toolchain On Wed, 21 Mar 2001, Phil Thompson wrote: > I had to patch va-mips.h to #include rather than > . > > The current errors are: > > - warnings about struct flock64 not being declared (it's defined in > asm-mips64/fcntl.h but not asm-mips/fcntl.h) > > - compilation stops because loops_per_sec is undeclared as far as > asm-mips/delay.h is concerned (although it seems fine in > asm-mips64/delay.h). > > This seems to imply that the mips architecture (as opposed to mips64) isn't > being maintained. Is this the case? Should I be using mips64 - but what > would be the point on an embedded CPU? You're definitely not using the Linux/MIPS CVS tree, since these things were fixed there some months ago. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Thu Mar 22 01:43:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2M9hVZ25157 for linux-mips-outgoing; Thu, 22 Mar 2001 01:43:31 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2M9hSM25152 for ; Thu, 22 Mar 2001 01:43:29 -0800 Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA01858; Thu, 22 Mar 2001 10:43:05 +0100 (MET) Date: Thu, 22 Mar 2001 10:43:05 +0100 (MET) From: Geert Uytterhoeven To: Phil Thompson cc: linux-mips@oss.sgi.com Subject: RE: Recommended toolchain In-Reply-To: <1402C4C025C4D311B50D00508B8B74E281B152@exchange1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 787 Lines: 25 On Thu, 22 Mar 2001, Phil Thompson wrote: > Correct - I am using the standard 2.4.2 sources. I had (obviously > incorrectly) assumed that the standard sources would be up to date and not > "some months" out of date. :-) > How are the differences in the two trees managed? At what point are the > latest non-MIPS changes applied to the MIPS tree? At what point are the MIPS When Ralf finds some time? > specific changes applied to the standard tree? When Ralf finds some time and Linus is in a good mood? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Thu Mar 22 03:44:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MBiV827854 for linux-mips-outgoing; Thu, 22 Mar 2001 03:44:31 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MBiUM27851 for ; Thu, 22 Mar 2001 03:44:30 -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 DAA10839 for ; Thu, 22 Mar 2001 03:44:30 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA28589 for ; Thu, 22 Mar 2001 03:44:28 -0800 (PST) Message-ID: <00eb01c0b2c6$02c7ef60$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: Subject: Embedded MIPS/Linux Needs Date: Thu, 22 Mar 2001 12:48:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1022 Lines: 28 Here at MIPS Technologies, we use Linux internally for design verification, experiments, benchmarking, etc., and as a consequence Carsten Langgaard and myself have both been active in this forum, and have tried to help the general Linux/MIPS community as best we can with the limited time that we can dedicate to the problem, in terms of suggested patches, bug fixes, cleanups, integration of needed components like the FPU emulator, etc. I have a question for those of you who are doing Linux work for *new* platforms (as opposed to the SGI/DEC legacy box support people). IF, and I emphasize the word *if*, MIPS Technologies were make a bigger investment in MIPS/Linux technology, be it kernel enhancements, cross/native tools, userland ports, libraries, or whatever, what would be your prioritized "wish list"? Feel free to respond by point-to-point email, though responses that are also copied to the mailing list might provoke some interesting and enlightening debate. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Mar 22 04:29:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MCT8s29081 for linux-mips-outgoing; Thu, 22 Mar 2001 04:29:08 -0800 Received: from exchange1.cam.pace.co.uk (host-131-80.pace.co.uk [136.170.131.80]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MCT6M29078 for ; Thu, 22 Mar 2001 04:29:06 -0800 Received: by exchange1 with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Mar 2001 12:27:59 -0000 Message-ID: <1402C4C025C4D311B50D00508B8B74E281B153@exchange1> From: Phil Thompson To: linux-mips@oss.sgi.com Subject: RE: Embedded MIPS/Linux Needs Date: Thu, 22 Mar 2001 12:27:59 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2272 Lines: 58 I'm just starting out on this path, so my priorities might be off... 1. Packaging of a "stable" cross-development kit, including kernel, toolchain and any other useful utilities. Saves me the time of assembling the pieces myself and saves me asking questions about problems that were fixed months ago. I know other companies provide this but I have yet to evaluate them. 2. Provision of a framework (which may already be in place - I haven't got that far yet) that provides me with a tick-list of hardware blocks that I may need to provide code for to support my particular board, and to be structured so that (as far as possible) I am adding files to the tree rather than modifying them. The framework to be arranged so that I can do it incrementally. 3. Support - not just for the development kit, but also as a source of experience and suggestions for porting to new boards. 4. Work with chip manufacturers who are slow to provide Linux drivers. Reference (rather than production quality) drivers would be better than nothing. This is obviously not a MIPS specific issue. Phil -----Original Message----- From: Kevin D. Kissell [mailto:kevink@mips.com] Sent: 22 March 2001 11:48 To: linux-mips@oss.sgi.com Subject: Embedded MIPS/Linux Needs Here at MIPS Technologies, we use Linux internally for design verification, experiments, benchmarking, etc., and as a consequence Carsten Langgaard and myself have both been active in this forum, and have tried to help the general Linux/MIPS community as best we can with the limited time that we can dedicate to the problem, in terms of suggested patches, bug fixes, cleanups, integration of needed components like the FPU emulator, etc. I have a question for those of you who are doing Linux work for *new* platforms (as opposed to the SGI/DEC legacy box support people). IF, and I emphasize the word *if*, MIPS Technologies were make a bigger investment in MIPS/Linux technology, be it kernel enhancements, cross/native tools, userland ports, libraries, or whatever, what would be your prioritized "wish list"? Feel free to respond by point-to-point email, though responses that are also copied to the mailing list might provoke some interesting and enlightening debate. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Mar 22 05:23:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MDNNd30584 for linux-mips-outgoing; Thu, 22 Mar 2001 05:23:23 -0800 Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MDNJM30581 for ; Thu, 22 Mar 2001 05:23:19 -0800 Received: from decoy (h00a0cc39f081.ne.mediaone.net [24.218.248.129]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f2MDNAk23663; Thu, 22 Mar 2001 08:23:14 -0500 (EST) From: "Jay Carlson" To: , Subject: snow, a statically linked shared library MIPS ABI Date: Thu, 22 Mar 2001 08:23:13 -0500 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3921 Lines: 84 OK, I've been sitting on this for a while and I haven't been pushing hard on a release lately, so I think it's time for me to point you folks at the back-to-the-stone-age library system I've been working on. Warning: if you don't build distros from scratch, you won't find this interesting. If your devices-of-interest have big cache with wide, fast memory, you won't see >From the README: ---- This is snow, a collection of hacks to build absolute-linked shared libraries for mipsel-linux systems. It's inspired (if that's the word) by the way Linux built shared libraries back in the libc2-4 era. Motivation For various reasons, position-independent code produced by the GNU toolchain for MIPS targets is not very dense. On desktop systems, this is acceptable; on embedded systems, notably handheld Linux devices, it's a real problem. Unfortunately, PIC is an all-or-nothing proposition, given the current MIPS toolchain: all parts of a program, including the main executable, must be built as PIC for intercall to work. Therefore, in order to use non-PIC code anywhere, we need to rebuild shared libraries, startup code, and main programs. Without position-independent code, the ELF shared library strategy doesn't work. Plan Instead, we can build shared library images located at fixed locations in memory, with the location configured at library creation time. Stub libraries are generated that hold the absolute addresses of functions and data within the library image; programs (and other libraries) link with the stubs. [...] ---- Typical code density improvement is in the 20-40% range; file sizes are reduced slightly more. For example, bash 1.x went from 800k to 400k. Although I haven't benchmarked it, executable startup seems dramatically faster on the embedded devices I play with. There can be significant execution speed boosts too. It's been a while since I did time trials, but I think I remember that dhrystone and squeak are like 50-90% faster. These numbers are from the TX3912 and Vr4181; on a cobalt, dhrystone was only like 15% faster. And the nature of the code is important: the native Byte benchmark showed only minimal improvements. Source at ftp://ftp.place.org/pub/nop/linuxce/snow-1.0.1.tar.gz ; a toolchain builder is at ftp://ftp.place.org/pub/nop/linuxce/pyramid-builder-1.0.3.tar.gz . Shane Nay at Agenda Computing ( www.agendacomputing.com ) has done some extensive work on distro building based on snow. ftp://ftp.agendacomputing.com/pub/dev/ contains snapshots of the work he's been doing; it includes source for much of the Agenda VR3 distribution adapted to snow. Agenda released a test rom image that demonstrates that libc, X, fltk, bash, etc are functional (and fast!); for non-Agenda users, this is interesting because it proves snow is a viable distro base. The biggest item on the snow to-do list is the implementation of jump tables and fixed data positioning to allow forward binary compatibility of library versions. (As with the old a.out libraries, this compatibility will require work on the part of the library builder.) Jump tables themselves are easy to build; fixed data positioning seems easiest to implement with -fdata-sections from gcc 2.9x. Choice of library address ranges is an open problem. If all code lives below the 256M mark (as it does now) calls use direct addressing with jal and j. But that 256M gets sucked up real fast if it can only be allocated aligned on 256k boundaries (because of the ABI mmap requirements, right?) and we try to enforce global uniqueness of library space allocation. Allowing library code anywhere in the address space requires either per-callpoint 4-instruction "la $at,printf; jalr $at" or yet another layer of stubs linked into each client space. I'm looking for use/testing/contributions from embedded Linux people. If you'd like to take the code off my hands, that'd be cool too. Jay From owner-linux-mips@oss.sgi.com Thu Mar 22 06:01:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2ME1kB31733 for linux-mips-outgoing; Thu, 22 Mar 2001 06:01:46 -0800 Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2ME1jM31730 for ; Thu, 22 Mar 2001 06:01:45 -0800 Received: from decoy (h00a0cc39f081.ne.mediaone.net [24.218.248.129]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f2ME1hk24137; Thu, 22 Mar 2001 09:01:43 -0500 (EST) From: "Jay Carlson" To: "Kevin D. Kissell" , Subject: RE: Embedded MIPS/Linux Needs Date: Thu, 22 Mar 2001 09:01:47 -0500 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.2911.0) In-Reply-To: <00eb01c0b2c6$02c7ef60$0deca8c0@Ulysses> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2258 Lines: 51 Disclaimer: I'm just a hobbyist. Kevin D. Kissell writes: > Here at MIPS Technologies, we use Linux internally > for design verification, experiments, benchmarking, > etc., and as a consequence Carsten Langgaard and > myself have both been active in this forum, and have > tried to help the general Linux/MIPS community as > best we can with the limited time that we can dedicate > to the problem, in terms of suggested patches, bug > fixes, cleanups, integration of needed components > like the FPU emulator, etc. Yes, and this is quite useful! > I have a question for those of you who are doing > Linux work for *new* platforms (as opposed to the > SGI/DEC legacy box support people). IF, and I > emphasize the word *if*, MIPS Technologies were > make a bigger investment in MIPS/Linux technology, > be it kernel enhancements, cross/native tools, > userland ports, libraries, or whatever, what would > be your prioritized "wish list"? Some of these things can reasonably be done by third parties. For instance, mvista's in the business of nailing down particular toolchain versions and doing relevant ports. These days I'm mostly userland, so I get to assume that working kernels are and will continue to be emitted from the smart people on this list too :-) My pet issue is code density and compiler quality. I think it's in MIPS's best interest to provide a really good compiler for their products, and I think gcc does a good job for traditional embedded MIPS systems. But the gcc/gas-generated code for the SVR4 ABI is pretty bad, especially for the low-end devices. snow (see previous message) shows how much room for improvement there is. Individual embedded Linux companies don't have much motivation to attack this problem alone, as it looks like it could involve extensive gcc hacking. If a particular customer looks like they have code density issues, it'd be easier for embedded linux companies to just recommend, say, ARM. MIPS Technologies on the other hand carries the banner for all devices licensing their architecture, and any toolchain work may result in greater demand for their own cores and licensee products. ARM and Cygnus recently contributed a gcc ARM backend rewrite. That's what got me thinking about this. Jay From owner-linux-mips@oss.sgi.com Thu Mar 22 06:17:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MEHaS32314 for linux-mips-outgoing; Thu, 22 Mar 2001 06:17:36 -0800 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MEHZM32311 for ; Thu, 22 Mar 2001 06:17:35 -0800 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id GAA20495; Thu, 22 Mar 2001 06:17:28 -0800 Message-Id: <200103221417.GAA20495@saturn.mikemac.com> To: "Kevin D. Kissell" cc: linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs In-Reply-To: Your message of "Thu, 22 Mar 2001 12:48:19 +0100." <00eb01c0b2c6$02c7ef60$0deca8c0@Ulysses> Date: Thu, 22 Mar 2001 06:17:28 -0800 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 617 Lines: 19 >From: "Kevin D. Kissell" >To: >Subject: Embedded MIPS/Linux Needs >Date: Thu, 22 Mar 2001 12:48:19 +0100 >I have a question for those of you who are doing >Linux work for *new* platforms (as opposed to the >SGI/DEC legacy box support people). IF, and I >emphasize the word *if*, MIPS Technologies were >make a bigger investment in MIPS/Linux technology, >be it kernel enhancements, cross/native tools, >userland ports, libraries, or whatever, what would >be your prioritized "wish list"? A bootloader that runs under WinCE 3.0! Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Thu Mar 22 06:18:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MEIAg32472 for linux-mips-outgoing; Thu, 22 Mar 2001 06:18:10 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MEIAM32469 for ; Thu, 22 Mar 2001 06:18:10 -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 GAA11734; Thu, 22 Mar 2001 06:18:00 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA02264; Thu, 22 Mar 2001 06:17:58 -0800 (PST) Message-ID: <013a01c0b2db$749249a0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jay Carlson" , , References: Subject: Re: snow, a statically linked shared library MIPS ABI Date: Thu, 22 Mar 2001 15:21:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 442 Lines: 12 > Instead, we can build shared library images located at fixed locations > in memory, with the location configured at library creation time. > Stub libraries are generated that hold the absolute addresses of > functions and data within the library image; programs (and other > libraries) link with the stubs. In fact, this is exactly how shared libraries worked under UNIX System V. It is inelegant, but economical. Kevin K. From owner-linux-mips@oss.sgi.com Thu Mar 22 07:28:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MFSgB02031 for linux-mips-outgoing; Thu, 22 Mar 2001 07:28:42 -0800 Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MFSfM02027 for ; Thu, 22 Mar 2001 07:28:41 -0800 Received: from decoy (h00a0cc39f081.ne.mediaone.net [24.218.248.129]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f2MFSbk14939; Thu, 22 Mar 2001 10:28:37 -0500 (EST) From: "Jay Carlson" To: "Kevin D. Kissell" , "Jay Carlson" , , Subject: RE: snow, a statically linked shared library MIPS ABI Date: Thu, 22 Mar 2001 10:28:41 -0500 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.2911.0) In-Reply-To: <013a01c0b2db$749249a0$0deca8c0@Ulysses> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 694 Lines: 17 Kevin D. Kissell [mailto:kevink@mips.com] writes: > > Instead, we can build shared library images located at fixed locations > > in memory, with the location configured at library creation time. > > Stub libraries are generated that hold the absolute addresses of > > functions and data within the library image; programs (and other > > libraries) link with the stubs. > > In fact, this is exactly how shared libraries worked under > UNIX System V. It is inelegant, but economical. Yeah. I bet there are precedents back in the mainframe world too. But my first encounter with it was Linux a.out libraries, so it's a sign that I'm truly a Linux Weenie that I think of it that way :-) Jay From owner-linux-mips@oss.sgi.com Thu Mar 22 09:55:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MHtoc05245 for linux-mips-outgoing; Thu, 22 Mar 2001 09:55:50 -0800 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MHtoM05242 for ; Thu, 22 Mar 2001 09:55:50 -0800 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA19642 for ; Thu, 22 Mar 2001 12:55:45 -0500 Date: Thu, 22 Mar 2001 12:55:45 -0500 (EST) From: X-Sender: nick@ns cc: linux-mips@oss.sgi.com Subject: Information about non-cache-coherent r10k In-Reply-To: <1402C4C025C4D311B50D00508B8B74E281B152@exchange1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 156 Lines: 6 http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html I was forwarded this link by a very helpfull fellow working on the Netbsd mips port. Nick From owner-linux-mips@oss.sgi.com Thu Mar 22 10:21:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MILwd05906 for linux-mips-outgoing; Thu, 22 Mar 2001 10:21:58 -0800 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MILvM05903 for ; Thu, 22 Mar 2001 10:21:57 -0800 Received: from dlep8.itg.ti.com ([157.170.134.88]) by jester.ti.com (8.11.1/8.11.1) with ESMTP id f2MILpD17605; Thu, 22 Mar 2001 12:21:51 -0600 (CST) Received: from dlep8.itg.ti.com (localhost [127.0.0.1]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id MAA00109; Thu, 22 Mar 2001 12:21:51 -0600 (CST) Received: from dlep4.itg.ti.com (dlep4-maint.itg.ti.com [157.170.133.17]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id MAA00099; Thu, 22 Mar 2001 12:21:50 -0600 (CST) Received: from ti.com (reddwarf.sc.ti.com [158.218.100.143]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id MAA07794; Thu, 22 Mar 2001 12:21:50 -0600 (CST) Message-ID: <3ABA430E.BDC095E@ti.com> Date: Thu, 22 Mar 2001 11:23:10 -0700 From: Jeff Harrell X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs References: <00eb01c0b2c6$02c7ef60$0deca8c0@Ulysses> Content-Type: multipart/mixed; boundary="------------067786785BCB493D506E86D4" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6549 Lines: 178 This is a multi-part message in MIME format. --------------067786785BCB493D506E86D4 Content-Type: multipart/alternative; boundary="------------9A7CE958C2C774B590AC4627" --------------9A7CE958C2C774B590AC4627 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Kevin D. Kissell" wrote: > Here at MIPS Technologies, we use Linux internally > for design verification, experiments, benchmarking, > etc., and as a consequence Carsten Langgaard and > myself have both been active in this forum, and have > tried to help the general Linux/MIPS community as > best we can with the limited time that we can dedicate > to the problem, in terms of suggested patches, bug > fixes, cleanups, integration of needed components > like the FPU emulator, etc. > I think that one of the larger hurdles that we have had to overcome is a common set of tools that can build a current kernel and userland application set from a cross-developed environment. There seems to have been a divergence between kernel tools and userland tools specifically in the area of recent kernel 2.4.x and GLIBC 2.2.x that is a major headache for delivering a toolchain that is on par with the intel equivalent designs. It is tough to offer a linux design that requires multiple toolchains one to build the kernel, one to build userland apps. > > I have a question for those of you who are doing > Linux work for *new* platforms (as opposed to the > SGI/DEC legacy box support people). IF, and I > emphasize the word *if*, MIPS Technologies were > make a bigger investment in MIPS/Linux technology, > be it kernel enhancements, cross/native tools, > userland ports, libraries, or whatever, what would > be your prioritized "wish list"? > 1. A toolchain that will build 2.4.x version of the kernel as well as GLIBC 2.2 dependent applications. Preferrably this would be a cross-development environment. (This would require GLIBC 2.2 accessable as a cross-compiled environment 2. Userland app ports > > Feel free to respond by point-to-point email, though > responses that are also copied to the mailing list > might provoke some interesting and enlightening > debate. > > Regards, > > Kevin K. >From past experience it's easy to see that without a solid set of development tools, it is hard to justify using a particular CPU or hardware. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jeff Harrell Work: (801) 619-6104 Broadband Access group/TI jharrell@ti.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------9A7CE958C2C774B590AC4627 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit "Kevin D. Kissell" wrote:

Here at MIPS Technologies, we use Linux internally
for design verification, experiments, benchmarking,
etc., and as a consequence Carsten Langgaard and
myself have both been active in this forum, and have
tried to help the general Linux/MIPS community as
best we can with the limited time that we can dedicate
to the problem, in terms of suggested patches, bug
fixes, cleanups, integration of needed components
like the FPU emulator, etc.

I think that one of the larger hurdles that we have had
to overcome is a common set of tools that can build a current
kernel and userland application set from a cross-developed
environment. There seems to have been a
divergence between kernel tools and userland tools specifically in
the area of recent kernel 2.4.x and GLIBC 2.2.x that is a major
headache for delivering a toolchain that is on par with the
intel equivalent designs. It is tough to offer a linux design that
requires multiple toolchains one to build the kernel, one to build
userland apps.

I have a question for those of you who are doing
Linux work for *new* platforms (as opposed to the
SGI/DEC legacy box support people). IF, and I
emphasize the word *if*, MIPS Technologies were
make a bigger investment in MIPS/Linux technology,
be it kernel enhancements, cross/native tools,
userland ports, libraries, or whatever, what would
be your prioritized "wish list"?

    1. A toolchain that will build 2.4.x version of the kernel as well
        as GLIBC 2.2 dependent applications. Preferrably this would
        be a cross-development environment. (This would require
         GLIBC 2.2 accessable as a cross-compiled environment

2. Userland app ports

Feel free to respond by point-to-point email, though
responses that are also copied to the mailing list
might provoke some interesting and enlightening
debate.
Regards,
Kevin K.

From past experience it's easy to see that without a
solid set of development tools, it is hard to justify using
a particular CPU or hardware.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeff Harrell                    Work:  (801) 619-6104 
Broadband Access group/TI       
jharrell@ti.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--------------9A7CE958C2C774B590AC4627-- --------------067786785BCB493D506E86D4 Content-Type: text/x-vcard; charset=us-ascii; name="jharrell.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jeff Harrell Content-Disposition: attachment; filename="jharrell.vcf" begin:vcard n:Harrell;Jeff tel;cell:(801) 597-6268 tel;fax:(801) 619-6150 tel;work:(801) 619-6104 x-mozilla-html:TRUE url:http://www.ti.com org:Broadband Access Group version:2.1 email;internet:jharrell@ti.com title:Texas Instruments adr;quoted-printable:;;170 West Election Rd. Suite 100 =0D=0AMS 4106 ;Draper;Utah;84020-6410;USA x-mozilla-cpt:;0 fn:Jeff Harrell end:vcard --------------067786785BCB493D506E86D4-- From owner-linux-mips@oss.sgi.com Thu Mar 22 10:36:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MIaYK06491 for linux-mips-outgoing; Thu, 22 Mar 2001 10:36:34 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MIaXM06488 for ; Thu, 22 Mar 2001 10:36:33 -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 f2MIX4020006; Thu, 22 Mar 2001 10:33:04 -0800 Message-ID: <3ABA4539.C3E780B6@mvista.com> Date: Thu, 22 Mar 2001 10:32:25 -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: Jay Carlson CC: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1517 Lines: 35 Jay Carlson wrote: > > Disclaimer: I'm just a hobbyist. > Disclaimer: I am an MontaVista employee, but as always, this email only represents my own opinion. :-) > Kevin D. Kissell writes: > > > Individual embedded Linux companies don't have much motivation to attack > this problem alone, as it looks like it could involve extensive gcc hacking. > If a particular customer looks like they have code density issues, it'd be > easier for embedded linux companies to just recommend, say, ARM. MIPS > Technologies on the other hand carries the banner for all devices licensing > their architecture, and any toolchain work may result in greater demand for > their own cores and licensee products. > I agree. Toolchain is the first step in the food chain. It makes most sense for MTI to invest in it and to make it better. All companies that I heard of switching from MIPS to PPC are due to toolchain (including debuggers). Sometimes it even has nothing to do with Linux. I think kernel also needs improvement in terms of board/machine support. I wrote an email long time ago talking about introducing a board support structure. I predicted we would see 20 new MIPS boards added this year and 100 more down the road. Apparently a better structure needs to be in place to accomdate the growth. It will certainly make future porting much easier too. While some of the improvement can be done incrementally (like time.c mess clean-up), some (like irq, PCI?) is probably best to be done just in one shot. Jun From owner-linux-mips@oss.sgi.com Thu Mar 22 11:00:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MJ0U407232 for linux-mips-outgoing; Thu, 22 Mar 2001 11:00:30 -0800 Received: from pobox.sibyte.com (pobox.sibyte.com [208.12.96.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MJ0TM07229 for ; Thu, 22 Mar 2001 11:00:29 -0800 Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21]) by pobox.sibyte.com (Postfix) with SMTP id 53DF8205FF for ; Thu, 22 Mar 2001 11:00:24 -0800 (PST) Received: from SMTP agent by mail gateway Thu, 22 Mar 2001 10:53:21 -0800 Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 5481B1595F for ; Thu, 22 Mar 2001 11:00:24 -0800 (PST) Received: by plugh.sibyte.com (Postfix, from userid 61017) id 65F1F686D; Thu, 22 Mar 2001 11:02:52 -0800 (PST) From: Justin Carlson Reply-To: carlson@sibyte.com Organization: Sibyte To: linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs Date: Thu, 22 Mar 2001 11:02:20 -0800 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01032211025209.20180@plugh.sibyte.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 595 Lines: 18 On Thu, 22 Mar 2001, you wrote: > I have a question for those of you who are doing > Linux work for *new* platforms (as opposed to the > SGI/DEC legacy box support people). IF, and I > emphasize the word *if*, MIPS Technologies were > make a bigger investment in MIPS/Linux technology, > be it kernel enhancements, cross/native tools, > userland ports, libraries, or whatever, what would > be your prioritized "wish list"? 1) n64 support in the full current gnu toolchain 2) n64 support in the full current gnu toolchain. 3) n64... I, of course, hold no biases whatsoever. ;) -Justin From owner-linux-mips@oss.sgi.com Thu Mar 22 11:03:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MJ3oI07492 for linux-mips-outgoing; Thu, 22 Mar 2001 11:03:50 -0800 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MJ3nM07489 for ; Thu, 22 Mar 2001 11:03:49 -0800 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA21425; Thu, 22 Mar 2001 14:03:43 -0500 Date: Thu, 22 Mar 2001 14:03:43 -0500 (EST) From: X-Sender: nick@ns To: Justin Carlson cc: linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs In-Reply-To: <01032211025209.20180@plugh.sibyte.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: 887 Lines: 33 I'd like to modify a couple of those requests... 1) Working 64bit support in the current gnu toolchain . . . Nick (It sorta produces useable code... usually..... on tuesdays... if it's a blue moon) On Thu, 22 Mar 2001, Justin Carlson wrote: > On Thu, 22 Mar 2001, you wrote: > > > I have a question for those of you who are doing > > Linux work for *new* platforms (as opposed to the > > SGI/DEC legacy box support people). IF, and I > > emphasize the word *if*, MIPS Technologies were > > make a bigger investment in MIPS/Linux technology, > > be it kernel enhancements, cross/native tools, > > userland ports, libraries, or whatever, what would > > be your prioritized "wish list"? > > 1) n64 support in the full current gnu toolchain > 2) n64 support in the full current gnu toolchain. > 3) n64... > > I, of course, hold no biases whatsoever. ;) > > -Justin > From owner-linux-mips@oss.sgi.com Thu Mar 22 11:22:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MJM5U08105 for linux-mips-outgoing; Thu, 22 Mar 2001 11:22:05 -0800 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MJM4M08102 for ; Thu, 22 Mar 2001 11:22:05 -0800 Received: by mail.foobazco.org (Postfix, from userid 1014) id 178F8109CE; Thu, 22 Mar 2001 11:22:29 -0800 (PST) Date: Thu, 22 Mar 2001 11:22:29 -0800 From: Keith M Wesolowski To: nick@snowman.net Cc: Justin Carlson , linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs Message-ID: <20010322112229.A5617@foobazco.org> References: <01032211025209.20180@plugh.sibyte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@snowman.net on Thu, Mar 22, 2001 at 02:03:43PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 901 Lines: 27 On Thu, Mar 22, 2001 at 02:03:43PM -0500, nick@snowman.net wrote: > (It sorta produces useable code... usually..... on tuesdays... if it's a > blue moon) gcc 3.0 for mips64 requires hacks to even accept the arguments the kernel compile wants to give, and even then it reliably produces extremely incorrect code. For example: int i = 0; prom_printf ("%d", i); Might yield something like -14777223 - basically, anything but 0. The code that causes this is horribly wrong that it wasn't even worth looking at. There are all sorts of similar, related, and dissimilar problems. On the other hand, the same compiler for mips (not 64) reliably produces working 2.4 kernels... -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "I should have crushed his marketing-addled skull with a fucking bat." From owner-linux-mips@oss.sgi.com Thu Mar 22 15:44:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2MNi3e14366 for linux-mips-outgoing; Thu, 22 Mar 2001 15:44:03 -0800 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2MNi1M14358 for ; Thu, 22 Mar 2001 15:44:02 -0800 Received: from dlep8.itg.ti.com ([157.170.134.88]) by gatekeep.ti.com (8.11.1/8.11.1) with ESMTP id f2MNhtr17992 for ; Thu, 22 Mar 2001 17:43:56 -0600 (CST) Received: from dlep8.itg.ti.com (localhost [127.0.0.1]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA25822 for ; Thu, 22 Mar 2001 17:43:55 -0600 (CST) Received: from dlep3.itg.ti.com (dlep3-maint.itg.ti.com [157.170.133.16]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA25816 for ; Thu, 22 Mar 2001 17:43:55 -0600 (CST) Received: from ti.com (IDENT:bbrown@bbrowndt.sc.ti.com [158.218.100.126]) by dlep3.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA12164 for ; Thu, 22 Mar 2001 17:43:54 -0600 (CST) Message-ID: <3ABA8F3D.E24DF122@ti.com> Date: Thu, 22 Mar 2001 16:48:13 -0700 From: Brady Brown Organization: Texas Instruments X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: SGI news group Subject: Tools miss-compile old kernel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3365 Lines: 72 I recently upgraded to a newer Cross-compiler tool chain to try to get up to glibc2.2. I'm now at gcc-2.95.3-14 and binutils-2.10.91-2 (both from Maciej's site). I have built 2.4.0-test9 with this tool-chain, but is will not boot. It spews illegal instruction errors when init is launched. Is this supposed to work, or are the new tools incompatible with older kernels? I dumped out the disassembly of a newly compiled kernel and found some bad instructions in many of the routines. First one is from head.S SNIP>> of bad disassembly 0000000080100280 : except_vec0_r4000(): 80100280: 401a4000 mfc0 $k0,$8 80100284: 001ad582 srl $k0,$k0,0x16 80100288: 3c1b0000 lui $k1,0x0 8010028c: 677b0001 0x677b0001 80100290: 001bdc38 0x1bdc38 80100294: 677b8023 0x677b8023 80100298: 001bdc38 0x1bdc38 8010029c: 8f7bb250 lw $k1,-19888($k1) 801002a0: 001ad080 sll $k0,$k0,0x2 801002a4: 037ad821 addu $k1,$k1,$k0 801002a8: 401a2000 mfc0 $k0,$4 801002ac: 8f7b0000 lw $k1,0($k1) 801002b0: 001ad042 srl $k0,$k0,0x1 801002b4: 335a0ff8 andi $k0,$k0,0xff8 801002b8: 037ad821 addu $k1,$k1,$k0 801002bc: 8f7a0000 lw $k0,0($k1) 801002c0: 8f7b0004 lw $k1,4($k1) 801002c4: 001ad182 srl $k0,$k0,0x6 801002c8: 409a1000 mtc0 $k0,$2 801002cc: 001bd982 srl $k1,$k1,0x6 801002d0: 409b1800 mtc0 $k1,$3 801002d4: 10000001 b ffffffff801002dc 801002d8: 42000006 tlbwr 801002dc: 00000000 nop 801002e0: 42000018 c0 0x18 <>SNIP of good assembly from old tools 0000000080100280 : except_vec0_r4000(): 80100280: 401a4000 mfc0 $k0,$8 80100284: 001ad582 srl $k0,$k0,0x16 80100288: 3c1b8023 lui $k1,0x8023 8010028c: 8f7bd210 lw $k1,-11760($k1) 80100290: 001ad080 sll $k0,$k0,0x2 80100294: 037ad821 addu $k1,$k1,$k0 80100298: 401a2000 mfc0 $k0,$4 8010029c: 8f7b0000 lw $k1,0($k1) 801002a0: 001ad042 srl $k0,$k0,0x1 801002a4: 335a0ff8 andi $k0,$k0,0xff8 801002a8: 037ad821 addu $k1,$k1,$k0 801002ac: 8f7a0000 lw $k0,0($k1) 801002b0: 8f7b0004 lw $k1,4($k1) 801002b4: 001ad182 srl $k0,$k0,0x6 801002b8: 409a1000 mtc0 $k0,$2 801002bc: 001bd982 srl $k1,$k1,0x6 801002c0: 409b1800 mtc0 $k1,$3 801002c4: 10000001 b 801002cc 801002c8: 42000006 tlbwr 801002cc: 00000000 nop 801002d0: 42000018 eret <; Thu, 22 Mar 2001 16:46:35 -0800 Received: by mail.foobazco.org (Postfix, from userid 1014) id B3068109CE; Thu, 22 Mar 2001 16:47:00 -0800 (PST) Date: Thu, 22 Mar 2001 16:47:00 -0800 From: Keith M Wesolowski To: Brady Brown Cc: SGI news group Subject: Re: Tools miss-compile old kernel Message-ID: <20010322164659.A6068@foobazco.org> References: <3ABA8F3D.E24DF122@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ABA8F3D.E24DF122@ti.com>; from bbrown@ti.com on Thu, Mar 22, 2001 at 04:48:13PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 984 Lines: 22 On Thu, Mar 22, 2001 at 04:48:13PM -0700, Brady Brown wrote: > Is this supposed to work, or are the new tools incompatible with > older kernels? That particular assembler is incompatible with sanity, older kernels, newer kernels, and anything you expect to actually function properly. > Looks like here the tools blow the lui/lw combination and also the eret. Any > suggestions? Upgrade to CVS binutils. The one Maciej has on his site is apparently broken. If you want a toolchain that is known to work at least in some cases, you can pull it from ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev/. That is the toolchain I use to build kernels -and- userland (yes, I know, everyone says it can't be done, but...) and thus it Works For Me (TM). -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "I should have crushed his marketing-addled skull with a fucking bat." From owner-linux-mips@oss.sgi.com Fri Mar 23 14:54:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2NMs1X11861 for linux-mips-outgoing; Fri, 23 Mar 2001 14:54:01 -0800 Received: from sprint02.rtmx.net (IDENT:qmailr@sprint02.RTMX.NET [208.31.160.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f2NMs1M11858 for ; Fri, 23 Mar 2001 14:54:01 -0800 Received: (qmail 12007 invoked by uid 102); 23 Mar 2001 22:53:59 -0000 Received: from host098.momenco.com (HELO beagle) (64.169.228.98) by 208.31.160.29 with SMTP; 23 Mar 2001 22:53:59 -0000 From: "Matthew Dharm" To: "Linux-MIPS" Subject: Multiple processor support? Date: Fri, 23 Mar 2001 14:53:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 355 Lines: 10 Does the MIPS port of linux support multiple-processor architectures? Matt Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From owner-linux-mips@oss.sgi.com Fri Mar 23 14:56:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2NMu5512107 for linux-mips-outgoing; Fri, 23 Mar 2001 14:56:05 -0800 Received: from pobox.sibyte.com (pobox.sibyte.com [208.12.96.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2NMu4M12104 for ; Fri, 23 Mar 2001 14:56:04 -0800 Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21]) by pobox.sibyte.com (Postfix) with SMTP id 52EAB205FC; Fri, 23 Mar 2001 14:55:59 -0800 (PST) Received: from SMTP agent by mail gateway Fri, 23 Mar 2001 14:48:54 -0800 Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 530B21595F; Fri, 23 Mar 2001 14:55:59 -0800 (PST) Received: by plugh.sibyte.com (Postfix, from userid 61017) id B19D6686D; Fri, 23 Mar 2001 14:58:35 -0800 (PST) From: Justin Carlson Reply-To: carlson@sibyte.com Organization: Sibyte To: "Matthew Dharm" Subject: Re: Multiple processor support? Date: Fri, 23 Mar 2001 14:58:20 -0800 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain References: In-Reply-To: Cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Message-Id: <01032314583505.00779@plugh.sibyte.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 133 Lines: 7 On Fri, 23 Mar 2001, you wrote: > Does the MIPS port of linux support multiple-processor architectures? > MIPS or MIPS64? -Justin From owner-linux-mips@oss.sgi.com Fri Mar 23 16:01:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2O01Su13428 for linux-mips-outgoing; Fri, 23 Mar 2001 16:01:28 -0800 Received: from sprint02.rtmx.net (IDENT:qmailr@sprint02.RTMX.NET [208.31.160.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f2O01RM13425 for ; Fri, 23 Mar 2001 16:01:27 -0800 Received: (qmail 19379 invoked by uid 102); 24 Mar 2001 00:01:26 -0000 Received: from host098.momenco.com (HELO beagle) (64.169.228.98) by 208.31.160.29 with SMTP; 24 Mar 2001 00:01:26 -0000 From: "Matthew Dharm" To: Cc: Subject: RE: Multiple processor support? Date: Fri, 23 Mar 2001 16:01:26 -0800 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) In-reply-to: <01032314583505.00779@plugh.sibyte.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 775 Lines: 30 Well, I'd like to know about both, frankly. Tho I'm more interested in whichever is designed to run on RM7000 series processors. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: Justin Carlson [mailto:carlson@sibyte.com] > Sent: Friday, March 23, 2001 2:58 PM > To: Matthew Dharm > Cc: linux-mips@oss.sgi.com > Subject: Re: Multiple processor support? > > > On Fri, 23 Mar 2001, you wrote: > > Does the MIPS port of linux support multiple-processor > architectures? > > > > MIPS or MIPS64? > > -Justin > > From owner-linux-mips@oss.sgi.com Fri Mar 23 16:12:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2O0C1g13770 for linux-mips-outgoing; Fri, 23 Mar 2001 16:12:01 -0800 Received: from pobox.sibyte.com (pobox.sibyte.com [208.12.96.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2O0C1M13767 for ; Fri, 23 Mar 2001 16:12:01 -0800 Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21]) by pobox.sibyte.com (Postfix) with SMTP id 6AC51205FA; Fri, 23 Mar 2001 16:11:55 -0800 (PST) Received: from SMTP agent by mail gateway Fri, 23 Mar 2001 16:04:51 -0800 Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id CD31315961; Fri, 23 Mar 2001 16:11:55 -0800 (PST) Received: by plugh.sibyte.com (Postfix, from userid 61017) id 7D288686D; Fri, 23 Mar 2001 16:14:36 -0800 (PST) From: Justin Carlson Reply-To: carlson@sibyte.com Organization: Sibyte To: "Matthew Dharm" Subject: RE: Multiple processor support? Date: Fri, 23 Mar 2001 16:08:13 -0800 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain Cc: References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01032316143609.00779@plugh.sibyte.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 717 Lines: 14 On Fri, 23 Mar 2001, Matthew Dharm wrote: > Well, I'd like to know about both, frankly. Tho I'm more interested > in whichever is designed to run on RM7000 series processors. To the best of my knowledge, the mips64 tree only works in SMP on the ip-27 which is r10K based. There would be a bit of work to get an RM7K based multiprocessor system to run. A fair amount of the "generic" code in that tree is also pretty ip-27 specific, and so would need to be cleaned up. I'm working on mips32 SMP support at the moment; there are no existing ports of this tree to an SMP platform. The mips64 stuff is certainly much, much more mature. I don't know of any reasons not to use the mips64 side for an RM7K. -Justin From owner-linux-mips@oss.sgi.com Fri Mar 23 16:16:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2O0GCq14047 for linux-mips-outgoing; Fri, 23 Mar 2001 16:16:12 -0800 Received: from clrsrv1.clearcore.com (@www.clearcore.com [208.141.182.168]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2O0GBM14044 for ; Fri, 23 Mar 2001 16:16:11 -0800 Received: from clearcore.net (nephi.clearcore.com [192.168.3.3]) by clrsrv1.clearcore.com (8.10.1/8.10.1) with ESMTP id f2O0Fjd26311; Fri, 23 Mar 2001 17:15:45 -0700 Message-ID: <3ABBE6BC.1040005@clearcore.net> Date: Fri, 23 Mar 2001 17:13:48 -0700 From: Joe George Organization: ClearCore User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8.1) Gecko/20010321 X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dharm CC: carlson@sibyte.com, linux-mips@oss.sgi.com Subject: Re: Multiple processor support? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 935 Lines: 40 Unfortunately the RM7000 does not have hardware cache coherency support. Joe George Matthew Dharm wrote: > Well, I'd like to know about both, frankly. Tho I'm more interested > in whichever is designed to run on RM7000 series processors. > > Matt > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > > >> -----Original Message----- >> From: Justin Carlson [mailto:carlson@sibyte.com] >> Sent: Friday, March 23, 2001 2:58 PM >> To: Matthew Dharm >> Cc: linux-mips@oss.sgi.com >> Subject: Re: Multiple processor support? >> >> >> On Fri, 23 Mar 2001, you wrote: >> >>> Does the MIPS port of linux support multiple-processor >> >> architectures? >> >> MIPS or MIPS64? >> >> -Justin >> >> From owner-linux-mips@oss.sgi.com Fri Mar 23 16:28:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2O0SfQ14514 for linux-mips-outgoing; Fri, 23 Mar 2001 16:28:41 -0800 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2O0SfM14510 for ; Fri, 23 Mar 2001 16:28:41 -0800 Received: by mail.foobazco.org (Postfix, from userid 1014) id 9C77E109CE; Fri, 23 Mar 2001 16:29:05 -0800 (PST) Date: Fri, 23 Mar 2001 16:29:05 -0800 From: Keith M Wesolowski To: Justin Carlson Cc: Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: Multiple processor support? Message-ID: <20010323162904.A10387@foobazco.org> References: <01032316143609.00779@plugh.sibyte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01032316143609.00779@plugh.sibyte.com>; from carlson@sibyte.com on Fri, Mar 23, 2001 at 04:08:13PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 905 Lines: 17 On Fri, Mar 23, 2001 at 04:08:13PM -0800, Justin Carlson wrote: > To the best of my knowledge, the mips64 tree only works in SMP on the ip-27 > which is r10K based. There would be a bit of work to get an RM7K based > multiprocessor system to run. A fair amount of the "generic" code in > that tree is also pretty ip-27 specific, and so would need to be cleaned up. In the particular case of SMP, this is probably still true. However, as of last weekend this tree compiles properly and boots part way on Indy; I have more to do but the separation of the obviously ip27-dependent stuff is done; you should at least be able to compile other machines in mips64...if there were any. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "I should have crushed his marketing-addled skull with a fucking bat." From owner-linux-mips@oss.sgi.com Fri Mar 23 16:37:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2O0b1214828 for linux-mips-outgoing; Fri, 23 Mar 2001 16:37:01 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2O0b0M14825 for ; Fri, 23 Mar 2001 16:37:00 -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 QAA29948; Fri, 23 Mar 2001 16:37:01 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA29978; Fri, 23 Mar 2001 16:36:57 -0800 (PST) Message-ID: <01b801c0b3fb$1770b740$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "Matthew Dharm" Cc: References: <01032316143609.00779@plugh.sibyte.com> Subject: Re: Multiple processor support? Date: Sat, 24 Mar 2001 01:40:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1517 Lines: 37 > > Well, I'd like to know about both, frankly. Tho I'm more interested > > in whichever is designed to run on RM7000 series processors. None are "designed" as such for the RM7000. I don't have a full RM7000 manual in the shop, but the short-form advance manual that I do have, while it goes into a fair amount of detail about the cache operations and external interface protocols, makes no mention of any support for hardware coherence of the sort provided by the R10000/R12000 (and the R4000/R4400 for that matter). If there is no support for cached/coherent memory attributes and cache interventions from the system side, an SMP kernel design for an MP SGI box might not be useful for an MP RM7K configuration. It is possible, but tricky, and at times unavoidably inefficient to build a software-coherent SMP system. I have not heard of anyone doing so with MIPS/Linux. > To the best of my knowledge, the mips64 tree only works in SMP on the ip-27 > which is r10K based. There would be a bit of work to get an RM7K based > multiprocessor system to run. A fair amount of the "generic" code in > that tree is also pretty ip-27 specific, and so would need to be cleaned up. > > I'm working on mips32 SMP support at the moment; there are no existing ports of > this tree to an SMP platform. The mips64 stuff is certainly much, much more > mature. I don't know of any reasons not to use the mips64 side for an RM7K. Well, one reason might be memory footprint... Regards, Kevin K. From owner-linux-mips@oss.sgi.com Fri Mar 23 17:24:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2O1ONL15856 for linux-mips-outgoing; Fri, 23 Mar 2001 17:24:23 -0800 Received: from dea.waldorf-gmbh.de (u-77-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.77]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2O1OKM15850 for ; Fri, 23 Mar 2001 17:24:20 -0800 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f2O1N7515101; Sat, 24 Mar 2001 02:23:07 +0100 Date: Sat, 24 Mar 2001 02:23:07 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: , "Matthew Dharm" , Subject: Re: Multiple processor support? Message-ID: <20010324022307.B15044@bacchus.dhis.org> References: <01032316143609.00779@plugh.sibyte.com> <01b801c0b3fb$1770b740$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: <01b801c0b3fb$1770b740$0deca8c0@Ulysses>; from kevink@mips.com on Sat, Mar 24, 2001 at 01:40:47AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 351 Lines: 10 On Sat, Mar 24, 2001 at 01:40:47AM +0100, Kevin D. Kissell wrote: > Well, one reason might be memory footprint... As of now the memory footprint of the kernel is large but userspace which is all 32-bit software has unchanged footprint. I've got plans for 2.5 to reduce the memory footprint of the kernel by introducing a 2-level pagetable. Ralf From owner-linux-mips@oss.sgi.com Sat Mar 24 13:18:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2OLI6o02735 for linux-mips-outgoing; Sat, 24 Mar 2001 13:18:06 -0800 Received: from air.lug-owl.de (air.lug-owl.de [62.52.24.190]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2OLI5M02732 for ; Sat, 24 Mar 2001 13:18:05 -0800 Received: by air.lug-owl.de (Postfix, from userid 1000) id 67DFF7C63; Sat, 24 Mar 2001 22:17:59 +0100 (CET) Date: Sat, 24 Mar 2001 22:17:58 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: elf2ecoff problem Message-ID: <20010324221757.B9810@lug-owl.de> Reply-To: jbglaw@lug-owl.de Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline User-Agent: Mutt/1.3.15i X-Operating-System: Linux air 2.4.2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4043 Lines: 113 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I'm trying to get a bootable kernel from fridays CVS sources for a R3k DECstation. The elf kernel compiles fine, but elf2ecoff fails: make[1]: Entering directory `/home/jbglaw/kernel_src/work/mips_linux/linux/= arch/mips/boot' gcc -o elf2ecoff elf2ecoff.c =2E/elf2ecoff /home/jbglaw/kernel_src/work/mips_linux/linux/vmlinux vmlinux= .ecoff -a Non-contiguous data can't be converted. make[1]: *** [vmlinux.ecoff] Error 1 make[1]: Leaving directory `/home/jbglaw/kernel_src/work/mips_linux/linux/a= rch/mips/boot' make: *** [boot] Error 2 Any hints? I'm using binutils and gcc from simple/crossdev, but that doesn't seem to be the problem here... jbglaw@schaufenster:~/kernel_src/work/mips_linux/linux$ mipsel-linux-objdum= p -h vmlinux vmlinux: file format elf32-littlemips Sections: Idx Name Size VMA LMA File off A= lgn 0 .text 00144590 ffffffff80040000 ffffffff80040000 00001000 2= **13 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .fixup 000010f0 ffffffff80184590 ffffffff80184590 00145590 2= **0 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .kstrtab 000031d4 ffffffff80185680 ffffffff80185680 00146680 2= **2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 __ex_table 00001fc0 ffffffff80188860 ffffffff80188860 00149860 2= **2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 __dbe_table 00000000 ffffffff8018a820 ffffffff8018a820 0014b820 2= **0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 __ksymtab 00001888 ffffffff8018a820 ffffffff8018a820 0014b820 2= **2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .text.init 0000dd78 ffffffff8018e000 ffffffff8018e000 0014e000 2= **2 CONTENTS, ALLOC, LOAD, READONLY, CODE 7 .data.init 0000049c ffffffff8019bd78 ffffffff8019bd78 0015bd78 2= **2 CONTENTS, ALLOC, LOAD, DATA 8 .setup.init 00000088 ffffffff8019c220 ffffffff8019c220 0015c220 2= **2 CONTENTS, ALLOC, LOAD, DATA 9 .initcall.init 00000058 ffffffff8019c2a8 ffffffff8019c2a8 0015c2a8 = 2**2 CONTENTS, ALLOC, LOAD, DATA 10 .data.cacheline_aligned 00000200 ffffffff8019d000 ffffffff8019d000 0= 015d000 2**4 CONTENTS, ALLOC, LOAD, DATA 11 .reginfo 00000018 ffffffff8019d200 ffffffff8019d200 0015d200 2= **2 CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE 12 .data 00012890 ffffffff8019d220 ffffffff8019d220 0015d220 2= **4 CONTENTS, ALLOC, LOAD, DATA 13 .sbss 000002b8 ffffffff801afab0 ffffffff801afab0 0016fab0 2= **3 ALLOC 14 .bss 000259f0 ffffffff801afd70 ffffffff801afd70 0016fab8 2= **4 ALLOC 15 .mdebug 00084158 ffffffff801d5760 ffffffff801d5760 001700b8 2= **2 CONTENTS, READONLY, DEBUGGING 16 .note 00001720 ffffffff80271978 ffffffff80271978 001f4210 2= **0 CONTENTS, READONLY 17 .modinfo 00000018 ffffffff802730a0 ffffffff802730a0 001700a0 2= **2 CONTENTS, ALLOC, LOAD, READONLY, DATA MfG, JBG --=20 Fehler eingestehen, Gr=F6=DFe zeigen: Nehmt die Rechtschreibreform zur=FCck= !!! /* Jan-Benedict Glaw -- +49-177-5601720 */ keyID=3D0x8399E1BB fingerprint=3D250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 83= 99 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjq9DwUACgkQHb1edYOZ4bvWpQCfYMvCVvSnOAcn6z1Fs04HpvNB Ns8An3X2UcS6ZLnuDHEQrdcVCCutf3ge =UN4S -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-linux-mips@oss.sgi.com Sat Mar 24 15:22:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2ONM3t04641 for linux-mips-outgoing; Sat, 24 Mar 2001 15:22:03 -0800 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f2ONM1M04638 for ; Sat, 24 Mar 2001 15:22:01 -0800 Received: (qmail 18652 invoked from network); 24 Mar 2001 23:21:57 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 24 Mar 2001 23:21:57 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: jbglaw@lug-owl.de cc: linux-mips@oss.sgi.com Subject: Re: elf2ecoff problem In-reply-to: Your message of "Sat, 24 Mar 2001 22:17:58 +0100." <20010324221757.B9810@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Mar 2001 09:21:56 +1000 Message-ID: <32583.985476116@ocs3.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 837 Lines: 17 On Sat, 24 Mar 2001 22:17:58 +0100, Jan-Benedict Glaw wrote: >./elf2ecoff /home/jbglaw/kernel_src/work/mips_linux/linux/vmlinux vmlinux.ecoff -a >Non-contiguous data can't be converted. > 17 .modinfo 00000018 ffffffff802730a0 ffffffff802730a0 001700a0 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA This may not be relevant but vmlinux should not have a .modinfo section. .modinfo is only created when code is compiled with -DMODULE so why is it in vmlinux? There was a recent change to the attributes of .modinfo, from CONTENTS, READONLY to CONTENTS, ALLOC, LOAD, READONLY, DATA, this change was to remove gcc warning messages. insmod treats sections .modinfo and .modstring as special cases and turns off the SHF_ALLOC flag, elf2ecoff might need special processing for these sections. From owner-linux-mips@oss.sgi.com Sun Mar 25 13:06:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2PL6Bg24349 for linux-mips-outgoing; Sun, 25 Mar 2001 13:06:11 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2PL6AM24346 for ; Sun, 25 Mar 2001 13:06:10 -0800 Received: from bilbo.physik.uni-konstanz.de [134.34.144.81] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 14hHiD-0005SM-00; Sun, 25 Mar 2001 23:06:09 +0200 Received: from agx by bilbo.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 14hHiC-0000sw-00; Sun, 25 Mar 2001 23:06:08 +0200 Date: Sun, 25 Mar 2001 23:06:08 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: current cvs kernel doesn't work with egcs 1.1.2/binutils 2.8.1 Message-ID: <20010325230608.A2867@bilbo.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: 270 Lines: 6 it fails with an unaligned access in emulate_load_store_insn (368) on an Indy/R4600 while doing: kmem_cache_create -> down -> __down -> add_wait_queue -> __add_wait_queue -> list_add -> __list_add it works with the gcc 3.0/binutils 2.11.90 from oss though. -- Guido From owner-linux-mips@oss.sgi.com Sun Mar 25 18:57:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2Q2vNn32561 for linux-mips-outgoing; Sun, 25 Mar 2001 18:57:23 -0800 Received: from lacrosse.corp.redhat.com (host154.207-175-42.redhat.com [207.175.42.154]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2Q2vMM32558 for ; Sun, 25 Mar 2001 18:57:22 -0800 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id VAA19802; Sun, 25 Mar 2001 21:57:11 -0500 Received: from redhat.com (IDENT:joe@dhcp-242.hsv.redhat.com [172.16.17.242] (may be forged)) by mx.hsv.redhat.com (8.11.0/8.11.0) with ESMTP id f2Q2xLx21091; Sun, 25 Mar 2001 20:59:22 -0600 Message-ID: <3ABEB120.8020609@redhat.com> Date: Sun, 25 Mar 2001 21:01:52 -0600 From: Joe deBlaquiere User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; 0.8) Gecko/20010217 X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs References: <00eb01c0b2c6$02c7ef60$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: 2890 Lines: 51 Hi Kevin, It's Sunday night, and I always have screwy suggestions for the world at the end of the weekend, so bear with me... And as another worthy collegue noted, these opinions are mine and do not necesarily represent the stance of my company. Kevin D. Kissell wrote: > Here at MIPS Technologies, we use Linux internally > for design verification, experiments, benchmarking, > etc., and as a consequence Carsten Langgaard and > myself have both been active in this forum, and have > tried to help the general Linux/MIPS community as > best we can with the limited time that we can dedicate > to the problem, in terms of suggested patches, bug > fixes, cleanups, integration of needed components > like the FPU emulator, etc. > I have to say that the answers I've gotten on MIPS issues on this list has been exceptionally good, both from the MIPS team and the various other individuals. > I have a question for those of you who are doing > Linux work for *new* platforms (as opposed to the > SGI/DEC legacy box support people). IF, and I > emphasize the word *if*, MIPS Technologies were > make a bigger investment in MIPS/Linux technology, > be it kernel enhancements, cross/native tools, > userland ports, libraries, or whatever, what would > be your prioritized "wish list"? > Just some unsorted random ideas: 1. Would it be possible to lump some of the different MIPS variants together more closely? In my dream world I could build one kernel that would boot on every mips architecture. This way the work can be more general. As it stands now, if you want Tx39 or Vr41 variants you're working out of a different tree. With the number of SoC core products coming out at present, this predicament is only likely to get more serious. I know at one point in time you could boot a single ARM kernel on several different systems and it would adapt it's processor specifics at runtime. Such a design might help to bring the MIPS world together a bit. 2. Tools are always an issue, but as long as new cores keep coming along that have exceptions and additions to the ISA(s), it's going to be good business for gcc engineers... 3. Using glibc in a cross development environment is slightly painful at this time for all architectures. MIPS is no different. Some general work on glibc would be good for the whole world. There has also been some work on other libraries (newlib and uClibc) for especially constrained environments. No MIPS/Linux support is available for either. 4. uClinux support for the systems without MMUs. There is considerable interest in this effort, but I think many people underestimate the magnitude of effort that will be required to have a truly solid port. This effort might be daunting for any one vendor, but could benefit all. -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9257 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Sun Mar 25 19:24:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2Q3Ocm00726 for linux-mips-outgoing; Sun, 25 Mar 2001 19:24:38 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2Q3ObM00723 for ; Sun, 25 Mar 2001 19:24:37 -0800 Received: from sydney.sydney.sgi.com ([134.14.48.2]) 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 TAA02488 for ; Sun, 25 Mar 2001 19:24:36 -0800 (PST) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id NAA17034; Mon, 26 Mar 2001 13:23:15 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Joe deBlaquiere cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs In-reply-to: Your message of "Sun, 25 Mar 2001 21:01:52 CST." <3ABEB120.8020609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Mar 2001 13:23:15 +1000 Message-ID: <19957.985576995@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1295 Lines: 27 You like long lines, don't you ;) Reflowed for readability. On Sun, 25 Mar 2001 21:01:52 -0600, Joe deBlaquiere wrote: >1. Would it be possible to lump some of the different MIPS variants >together more closely? In my dream world I could build one kernel that >would boot on every mips architecture. This way the work can be more >general. As it stands now, if you want Tx39 or Vr41 variants you're >working out of a different tree. FWIW I am working on a Makefile rewrite for 2.5 which will help with this problem. Instead of one 120Mb kernel source tree for each architecture, 2.5 will support logical kernel source trees and separate source and object directories. The logical source is built up from base kernel code (Linus's tarball) plus zero or more layers that contain additional or different code. So you compile 2.4.x -> ix86 object directory 2.4.x + common mips -> common mips object directory 2.4.x + common mips + Tx39 -> Tx39 object directory 2.4.x + common mips + Vr41 -> Vr41 object directory All use the same untouched 2.4.x tarball as the base. You can compile multiple targets from the same source at the same time, using different object directories. A change to base 2.4.x or to common mips is automatically seen by all the object directories. From owner-linux-mips@oss.sgi.com Sun Mar 25 19:28:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2Q3SAa01053 for linux-mips-outgoing; Sun, 25 Mar 2001 19:28:10 -0800 Received: from dea.waldorf-gmbh.de (u-188-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.188]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2Q3S8M01047 for ; Sun, 25 Mar 2001 19:28:08 -0800 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f2P3aUv18623; Sun, 25 Mar 2001 05:36:30 +0200 Date: Sun, 25 Mar 2001 05:35:54 +0200 From: Ralf Baechle To: Keith Owens Cc: jbglaw@lug-owl.de, linux-mips@oss.sgi.com, Harald Koerfgen Subject: Re: elf2ecoff problem Message-ID: <20010325053554.A18589@bacchus.dhis.org> References: <20010324221757.B9810@lug-owl.de> <32583.985476116@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <32583.985476116@ocs3.ocs-net>; from kaos@ocs.com.au on Sun, Mar 25, 2001 at 09:21:56AM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1211 Lines: 25 On Sun, Mar 25, 2001 at 09:21:56AM +1000, Keith Owens wrote: > On Sat, 24 Mar 2001 22:17:58 +0100, > Jan-Benedict Glaw wrote: > >./elf2ecoff /home/jbglaw/kernel_src/work/mips_linux/linux/vmlinux vmlinux.ecoff -a > >Non-contiguous data can't be converted. > > 17 .modinfo 00000018 ffffffff802730a0 ffffffff802730a0 001700a0 2**2 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > This may not be relevant but vmlinux should not have a .modinfo > section. .modinfo is only created when code is compiled with -DMODULE > so why is it in vmlinux? > > There was a recent change to the attributes of .modinfo, from CONTENTS, > READONLY to CONTENTS, ALLOC, LOAD, READONLY, DATA, this change was to > remove gcc warning messages. insmod treats sections .modinfo and > .modstring as special cases and turns off the SHF_ALLOC flag, elf2ecoff > might need special processing for these sections. The .modinfo section gets into vmlinux through drivers/tc/tc.o where it gets created because include/asm-mips/dec/tcmodule.h defines the cpp symbol MODULE; gets included after that and believing this is a module compilation puts some stuff into .modinfo. Ralf From owner-linux-mips@oss.sgi.com Sun Mar 25 19:40:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2Q3eJk01698 for linux-mips-outgoing; Sun, 25 Mar 2001 19:40:19 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2Q3eGM01691; Sun, 25 Mar 2001 19:40:16 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA02549; Sun, 25 Mar 2001 19:39:01 -0800 (PST) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id NAA17825; Mon, 26 Mar 2001 13:38:55 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Ralf Baechle cc: jbglaw@lug-owl.de, linux-mips@oss.sgi.com, Harald Koerfgen Subject: Re: elf2ecoff problem In-reply-to: Your message of "Sun, 25 Mar 2001 05:35:54 +0200." <20010325053554.A18589@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Mar 2001 13:38:56 +1000 Message-ID: <20271.985577936@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 415 Lines: 9 On Sun, 25 Mar 2001 05:35:54 +0200, Ralf Baechle wrote: >The .modinfo section gets into vmlinux through drivers/tc/tc.o where it >gets created because include/asm-mips/dec/tcmodule.h defines the cpp >symbol MODULE; gets included after that and believing >this is a module compilation puts some stuff into .modinfo. tc will have to use a name other than MODULE, say TC_MODULE. From owner-linux-mips@oss.sgi.com Sun Mar 25 20:06:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2Q46jg02397 for linux-mips-outgoing; Sun, 25 Mar 2001 20:06:45 -0800 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2Q46iM02394 for ; Sun, 25 Mar 2001 20:06:44 -0800 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 50E63109CE; Sun, 25 Mar 2001 20:07:08 -0800 (PST) Received: by galt.foobazco.org (Postfix, from userid 1014) id B47741F429; Sun, 25 Mar 2001 20:06:42 -0800 (PST) Date: Sun, 25 Mar 2001 20:06:42 -0800 From: Keith M Wesolowski To: Joe deBlaquiere Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs Message-ID: <20010325200642.C25362@foobazco.org> References: <00eb01c0b2c6$02c7ef60$0deca8c0@Ulysses> <3ABEB120.8020609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ABEB120.8020609@redhat.com>; from jadb@redhat.com on Sun, Mar 25, 2001 at 09:01:52PM -0600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1365 Lines: 26 On Sun, Mar 25, 2001 at 09:01:52PM -0600, Joe deBlaquiere wrote: > 1. Would it be possible to lump some of the different MIPS variants > together more closely? In my dream world I could build one kernel > that would boot on every mips architecture. This way the work can be > more general. As it stands now, if you want Tx39 or Vr41 variants > you're working out of a different tree. With the number of SoC core > products coming out at present, this predicament is only likely to > get more serious. I know at one point in time you could boot a > single ARM kernel on several different systems and it would adapt > it's processor specifics at runtime. Such a design might help to > bring the MIPS world together a bit. I'm about 2/3 of the way through writing a patch that will bring boot-time machine detection and parameters to mips - this is similar to a scheme that was suggested some time ago by Jun and is also based on a short discussion I had with Ralf about cleaning up proc.c. This is only the first step, though, as there are a lot of ifdefs in headers and such. I will release this patch for review sometime in the next week. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "I should have crushed his marketing-addled skull with a fucking bat." From owner-linux-mips@oss.sgi.com Sun Mar 25 22:13:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2Q6DSa04453 for linux-mips-outgoing; Sun, 25 Mar 2001 22:13:28 -0800 Received: from arianne.in.ishoni.com ([164.164.83.132]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2Q6DNM04450 for ; Sun, 25 Mar 2001 22:13:24 -0800 Received: from deepak ([192.168.1.240]) by arianne.in.ishoni.com (8.11.2/8.11.2) with SMTP id f2Q6Ev925866 for ; Mon, 26 Mar 2001 11:44:59 +0530 Reply-To: From: "Deepak Shenoy" To: Subject: how do i build gcc cross compiler for mips, on host i386 Date: Mon, 26 Mar 2001 11:44:42 +0530 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 328 Lines: 14 I am trying to build Gcc mips cross compiler. I want to use this for compiling 2.4.0 linux. I also want to build libraries. Which are the tar files i would need to download? What is the sequence i should follow when building gcc cross compiler? Information on this would be very helpful for me. Thanks and Regards, deepak From owner-linux-mips@oss.sgi.com Mon Mar 26 08:46:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2QGkG926308 for linux-mips-outgoing; Mon, 26 Mar 2001 08:46:16 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2QGkFM26301 for ; Mon, 26 Mar 2001 08:46:15 -0800 Received: from bilbo.physik.uni-konstanz.de [134.34.144.81] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 14ha8E-0002LM-00; Mon, 26 Mar 2001 18:46:14 +0200 Received: from agx by bilbo.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 14ha8D-0005Lx-00; Mon, 26 Mar 2001 18:46:13 +0200 Date: Mon, 26 Mar 2001 18:46:13 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: indy's hardware watchdog Message-ID: <20010326184613.A20198@bilbo.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: 170 Lines: 5 I've written a small module to support the Indy's hardware watchdog. It can be found at: http://honk.physik.uni-konstanz.de/linux-mips/indy-watchdog/ Regards, -- Guido From owner-linux-mips@oss.sgi.com Mon Mar 26 09:19:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2QHJWJ27832 for linux-mips-outgoing; Mon, 26 Mar 2001 09:19:32 -0800 Received: from dea.waldorf-gmbh.de (u-200-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2QHJSM27822 for ; Mon, 26 Mar 2001 09:19:29 -0800 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f2QHJ4Y08014; Mon, 26 Mar 2001 19:19:04 +0200 Date: Mon, 26 Mar 2001 19:19:04 +0200 From: Ralf Baechle To: Keith Owens Cc: jbglaw@lug-owl.de, linux-mips@oss.sgi.com, Harald Koerfgen Subject: Re: elf2ecoff problem Message-ID: <20010326191904.A7989@bacchus.dhis.org> References: <20010325053554.A18589@bacchus.dhis.org> <20271.985577936@kao2.melbourne.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: <20271.985577936@kao2.melbourne.sgi.com>; from kaos@ocs.com.au on Mon, Mar 26, 2001 at 01:38:56PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 494 Lines: 13 On Mon, Mar 26, 2001 at 01:38:56PM +1000, Keith Owens wrote: > Ralf Baechle wrote: > >The .modinfo section gets into vmlinux through drivers/tc/tc.o where it > >gets created because include/asm-mips/dec/tcmodule.h defines the cpp > >symbol MODULE; gets included after that and believing > >this is a module compilation puts some stuff into .modinfo. > > tc will have to use a name other than MODULE, say TC_MODULE. I've now commited a fix to CVS. Ralf From owner-linux-mips@oss.sgi.com Mon Mar 26 09:49:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2QHnGI28853 for linux-mips-outgoing; Mon, 26 Mar 2001 09:49:16 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2QHnFM28850 for ; Mon, 26 Mar 2001 09:49:15 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 546CF7F3; Mon, 26 Mar 2001 19:49:13 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 0C120F014; Mon, 26 Mar 2001 19:25:59 +0200 (CEST) Date: Mon, 26 Mar 2001 19:25:59 +0200 From: Florian Lohoff To: Joe deBlaquiere Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs Message-ID: <20010326192559.A8385@paradigm.rfc822.org> References: <00eb01c0b2c6$02c7ef60$0deca8c0@Ulysses> <3ABEB120.8020609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3ABEB120.8020609@redhat.com>; from jadb@redhat.com on Sun, Mar 25, 2001 at 09:01:52PM -0600 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1373 Lines: 28 On Sun, Mar 25, 2001 at 09:01:52PM -0600, Joe deBlaquiere wrote: > Just some unsorted random ideas: > > 1. Would it be possible to lump some of the different MIPS variants > together more closely? In my dream world I could build one kernel that > would boot on every mips architecture. This way the work can be more > general. As it stands now, if you want Tx39 or Vr41 variants you're > working out of a different tree. With the number of SoC core products > coming out at present, this predicament is only likely to get more > serious. I know at one point in time you could boot a single ARM kernel on > several different systems and it would adapt it's processor specifics at > runtime. Such a design might help to bring the MIPS world together a bit. There is at least a problem with endianess - I dont think there can be a little and big endian kernel coexist in the same object or at least not with major rework. Why would you suggest having vr41 and TX39 in a seperat tree ? I had a look in the linux-vr tree and i dont like some of their #ifdef spaghetti stuff so i am currently working on TX39 stuff on top of the oss tree which could be made cleanly. (Dont integrate all TX39 archs into one subarch *grrr*) Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Mon Mar 26 10:42:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2QIgwx30213 for linux-mips-outgoing; Mon, 26 Mar 2001 10:42:58 -0800 Received: from lacrosse.corp.redhat.com (host154.207-175-42.redhat.com [207.175.42.154]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2QIgwM30210 for ; Mon, 26 Mar 2001 10:42:58 -0800 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id NAA04790; Mon, 26 Mar 2001 13:42:51 -0500 Received: from redhat.com (IDENT:joe@uberdog.hsv.redhat.com [172.16.16.108]) by mx.hsv.redhat.com (8.11.0/8.11.0) with ESMTP id f2QIj7x31555; Mon, 26 Mar 2001 12:45:07 -0600 Message-ID: <3ABF8ED5.2050007@redhat.com> Date: Mon, 26 Mar 2001 12:47:49 -0600 From: Joe deBlaquiere User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; 0.8) Gecko/20010217 X-Accept-Language: en MIME-Version: 1.0 To: Florian Lohoff CC: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs References: <00eb01c0b2c6$02c7ef60$0deca8c0@Ulysses> <3ABEB120.8020609@redhat.com> <20010326192559.A8385@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1806 Lines: 46 Florian Lohoff wrote: > On Sun, Mar 25, 2001 at 09:01:52PM -0600, Joe deBlaquiere wrote: > >> Just some unsorted random ideas: >> >> 1. Would it be possible to lump some of the different MIPS variants >> together more closely? In my dream world I could build one kernel that >> would boot on every mips architecture. This way the work can be more >> general. As it stands now, if you want Tx39 or Vr41 variants you're >> working out of a different tree. With the number of SoC core products >> coming out at present, this predicament is only likely to get more >> serious. I know at one point in time you could boot a single ARM kernel on >> several different systems and it would adapt it's processor specifics at >> runtime. Such a design might help to bring the MIPS world together a bit. > > > There is at least a problem with endianess - I dont think there can be > a little and big endian kernel coexist in the same object or at least > not with major rework. > Well, yes that would be a problem, but at least within endianess, there's no reason why the processor specific stuff can't be abstracted and attached at runtime. > Why would you suggest having vr41 and TX39 in a seperat tree ? I had a > look in the linux-vr tree and i dont like some of their #ifdef spaghetti > stuff so i am currently working on TX39 stuff on top of the oss tree > which could be made cleanly. (Dont integrate all TX39 archs into one > subarch *grrr*) > It's kinda ugly, but some of that is that the original architecture didn't scale to having many different target platforms. I think a little sane multi-platform infrastructure would make things cleaner and better in the future. > Flo -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Mon Mar 26 11:25:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2QJPfG00583 for linux-mips-outgoing; Mon, 26 Mar 2001 11:25:41 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2QJPfM00578 for ; Mon, 26 Mar 2001 11:25:41 -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 f2QJLK015199; Mon, 26 Mar 2001 11:21:20 -0800 Message-ID: <3ABF9683.1D08617B@mvista.com> Date: Mon, 26 Mar 2001 11:20:35 -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: "Kevin D. Kissell" CC: carlson@sibyte.com, Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: Multiple processor support? References: <01032316143609.00779@plugh.sibyte.com> <01b801c0b3fb$1770b740$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 545 Lines: 17 "Kevin D. Kissell" wrote: > > (Software cache coherency) It is possible, > but tricky, and at times unavoidably inefficient to build a > software-coherent SMP system. I have not heard of anyone > doing so with MIPS/Linux. > How would it be possible? Any reference to the previous implementations? I imagine you would need at least some kind of atomic operation (like ll/sc) working reliably (which itself may require cache coherency). Also, any such scheme should not require massive change in the programming. I am very curious.... Jun From owner-linux-mips@oss.sgi.com Mon Mar 26 15:28:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2QNSSC08693 for linux-mips-outgoing; Mon, 26 Mar 2001 15:28:28 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2QNSSM08690 for ; Mon, 26 Mar 2001 15:28:28 -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 f2QNOu031012; Mon, 26 Mar 2001 15:24:56 -0800 Message-ID: <3ABFCF9B.FA35FF9B@mvista.com> Date: Mon, 26 Mar 2001 15:24:11 -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: Joe deBlaquiere CC: Florian Lohoff , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Embedded MIPS/Linux Needs References: <00eb01c0b2c6$02c7ef60$0deca8c0@Ulysses> <3ABEB120.8020609@redhat.com> <20010326192559.A8385@paradigm.rfc822.org> <3ABF8ED5.2050007@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1207 Lines: 24 Joe deBlaquiere wrote: > > Why would you suggest having vr41 and TX39 in a seperat tree ? I had a > > look in the linux-vr tree and i dont like some of their #ifdef spaghetti > > stuff so i am currently working on TX39 stuff on top of the oss tree > > which could be made cleanly. (Dont integrate all TX39 archs into one > > subarch *grrr*) > > > > It's kinda ugly, but some of that is that the original architecture didn't scale to having many different target platforms. I think a little sane multi-platform infrastructure would make things cleaner and better in the future. > I was trying to move Vr41xx from linux-vr to oss tree and found a couple of problems. The most serious one that is that NEC Vr41xx TLB entry format is slightly different from all other R4K-compatible CPUs. Fixing this requires either an ugly #ifdef in some common header files, or massively code re-writing for all TLB related stuff. Neither one is good. I actually worked out a patch based on #ifdef approach, but a little too "shameful" to submit it. My feeling is that we need to separate TLB code from cache code and introduce some way to plug in different TLB codes. Then we can get V41xx integrated nicely. Jun From owner-linux-mips@oss.sgi.com Mon Mar 26 21:38:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2R5cRb16629 for linux-mips-outgoing; Mon, 26 Mar 2001 21:38:27 -0800 Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2R5cMM16624 for ; Mon, 26 Mar 2001 21:38:22 -0800 Received: from fest.stud.fee.vutbr.cz (fest.stud.fee.vutbr.cz [147.229.9.16]) by boco.fee.vutbr.cz (8.11.3/8.11.3) with ESMTP id f2R5cAt77271 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 27 Mar 2001 07:38:10 +0200 (CEST) Received: (from xjezda00@localhost) by fest.stud.fee.vutbr.cz (8.11.2/8.11.2) id f2R5c9455687; Tue, 27 Mar 2001 07:38:09 +0200 (CEST) Date: Tue, 27 Mar 2001 07:38:09 +0200 From: David Jez To: Guido Guenther Cc: linux-mips@oss.sgi.com Subject: Re: indy's hardware watchdog Message-ID: <20010327073809.B55390@stud.fee.vutbr.cz> References: <20010326184613.A20198@bilbo.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010326184613.A20198@bilbo.physik.uni-konstanz.de>; from guido.guenther@gmx.net on Mon, Mar 26, 2001 at 06:46:13PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 478 Lines: 11 > I've written a small module to support the Indy's hardware watchdog. > It can be found at: > http://honk.physik.uni-konstanz.de/linux-mips/indy-watchdog/ Great. Thanks Guido. Btw. do you know if video input on indy is supported? -- ------------------------------------------------------- David "Dave" Jez Brno, CZ, Europe E-mail: dave.jez@seznam.cz PGP key: finger xjezda00@fest.stud.fee.vutbr.cz ---------=[ ~EOF ]=------------------------------------ From owner-linux-mips@oss.sgi.com Tue Mar 27 09:55:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RHtZB03701 for linux-mips-outgoing; Tue, 27 Mar 2001 09:55:35 -0800 Received: from woody.ichilton.co.uk (woody.ichilton.co.uk [216.29.174.40]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RHtZM03697 for ; Tue, 27 Mar 2001 09:55:35 -0800 Received: by woody.ichilton.co.uk (Postfix, from userid 1000) id D26DA8030; Tue, 27 Mar 2001 18:55:34 +0100 (BST) Date: Tue, 27 Mar 2001 18:55:34 +0100 From: Ian Chilton To: linux-mips@oss.sgi.com Subject: Re: indy's hardware watchdog Message-ID: <20010327185534.C3617@woody.ichilton.co.uk> Reply-To: Ian Chilton References: <20010326184613.A20198@bilbo.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: <20010326184613.A20198@bilbo.physik.uni-konstanz.de>; from guido.guenther@gmx.net on Mon, Mar 26, 2001 at 06:46:13PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 259 Lines: 17 Hello, > I've written a small module to support the Indy's hardware watchdog. Great, well done Guido! I'll put a link to this on the Linux/MIPS site. Shame it doesn't help when kernel debugging and the machine hangs at the PROM :-( Bye for Now, Ian From owner-linux-mips@oss.sgi.com Tue Mar 27 09:54:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RHsUP03589 for linux-mips-outgoing; Tue, 27 Mar 2001 09:54:30 -0800 Received: from woody.ichilton.co.uk (woody.ichilton.co.uk [216.29.174.40]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RHsPM03584 for ; Tue, 27 Mar 2001 09:54:25 -0800 Received: by woody.ichilton.co.uk (Postfix, from userid 1000) id DDDFF8030; Tue, 27 Mar 2001 18:54:23 +0100 (BST) Date: Tue, 27 Mar 2001 18:54:23 +0100 From: Ian Chilton To: David Jez Cc: linux-mips@oss.sgi.com, guido.guenther@gmx.net Subject: Re: indy's hardware watchdog Message-ID: <20010327185423.B3617@woody.ichilton.co.uk> Reply-To: Ian Chilton References: <20010326184613.A20198@bilbo.physik.uni-konstanz.de> <20010327073809.B55390@stud.fee.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: <20010327073809.B55390@stud.fee.vutbr.cz>; from dave.jez@seznam.cz on Tue, Mar 27, 2001 at 07:38:09AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 300 Lines: 21 Hello, > Btw. do you know if video input on indy is supported? No, it isn't. But, Ulf (grimsy) did start writing a driver for it, but never finished. If you look in any kernel tree, under drivers/char/ you will find vino.c and vino.h We just need someone to finish it :) Bye for Now, Ian From owner-linux-mips@oss.sgi.com Tue Mar 27 10:02:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RI2Qa04160 for linux-mips-outgoing; Tue, 27 Mar 2001 10:02:26 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RI2PM04154 for ; Tue, 27 Mar 2001 10:02:26 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 4D8C17FA; Tue, 27 Mar 2001 20:02:24 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id C120AF014; Tue, 27 Mar 2001 20:02:19 +0200 (CEST) Date: Tue, 27 Mar 2001 20:02:19 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: loop stuff Message-ID: <20010327200219.B32706@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 438 Lines: 12 Hi, does anyone know if the 2.4.2 kernel does support loop devices - I mean in the sense of - "It works" - I do have problems with processes like mke2fs getting hung while accessing the loop without any error message. I am not running 2.4.x on any other platform so i cant verify ... Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Tue Mar 27 10:02:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RI2QA04159 for linux-mips-outgoing; Tue, 27 Mar 2001 10:02:26 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RI2PM04153 for ; Tue, 27 Mar 2001 10:02:26 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 2449B7F8; Tue, 27 Mar 2001 20:02:24 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 19796F014; Tue, 27 Mar 2001 20:01:05 +0200 (CEST) Date: Tue, 27 Mar 2001 20:01:05 +0200 From: Florian Lohoff To: David Jez Cc: Guido Guenther , linux-mips@oss.sgi.com Subject: Re: indy's hardware watchdog Message-ID: <20010327200105.A32706@paradigm.rfc822.org> References: <20010326184613.A20198@bilbo.physik.uni-konstanz.de> <20010327073809.B55390@stud.fee.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010327073809.B55390@stud.fee.vutbr.cz>; from dave.jez@seznam.cz on Tue, Mar 27, 2001 at 07:38:09AM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 464 Lines: 13 On Tue, Mar 27, 2001 at 07:38:09AM +0200, David Jez wrote: > > I've written a small module to support the Indy's hardware watchdog. > > It can be found at: > > http://honk.physik.uni-konstanz.de/linux-mips/indy-watchdog/ > Great. Thanks Guido. Btw. do you know if video input on indy is supported? It isnt. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Tue Mar 27 10:06:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RI6j804661 for linux-mips-outgoing; Tue, 27 Mar 2001 10:06:45 -0800 Received: from pobox.sibyte.com (pobox.sibyte.com [208.12.96.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RI6jM04658 for ; Tue, 27 Mar 2001 10:06:45 -0800 Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21]) by pobox.sibyte.com (Postfix) with SMTP id 60402205FE; Tue, 27 Mar 2001 10:06:39 -0800 (PST) Received: from SMTP agent by mail gateway Tue, 27 Mar 2001 09:59:29 -0800 Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id AFA6F1595F; Tue, 27 Mar 2001 10:06:39 -0800 (PST) Received: by plugh.sibyte.com (Postfix, from userid 61017) id 087A5686D; Tue, 27 Mar 2001 10:09:00 -0800 (PST) From: Justin Carlson Reply-To: carlson@sibyte.com Organization: Sibyte To: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: loop stuff Date: Tue, 27 Mar 2001 10:06:46 -0800 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain References: <20010327200219.B32706@paradigm.rfc822.org> In-Reply-To: <20010327200219.B32706@paradigm.rfc822.org> MIME-Version: 1.0 Message-Id: <0103271008591B.00779@plugh.sibyte.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 594 Lines: 15 On Tue, 27 Mar 2001, Florian Lohoff wrote: > Hi, > does anyone know if the 2.4.2 kernel does support loop devices - I mean > in the sense of - "It works" - I do have problems with processes like > mke2fs getting hung while accessing the loop without any error message. > > I am not running 2.4.x on any other platform so i cant verify ... > This probably isn't a MIPS specific problem. It's supposed to be fixed by some of Jens Axboe's latest stuff, as well as in the 2.4.2ac series on kernel.org; I'd guess it will be fixed when 2.4.3 is released and imported to cvs@oss.sgi.com. -Justin From owner-linux-mips@oss.sgi.com Tue Mar 27 10:22:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RIMXi05279 for linux-mips-outgoing; Tue, 27 Mar 2001 10:22:33 -0800 Received: from appliedmicro.ns.ca (dragon.appliedmicro.ns.ca [24.222.12.66]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RIMWM05275 for ; Tue, 27 Mar 2001 10:22:32 -0800 Received: by dragon.appliedmicro.ns.ca id <7308>; Tue, 27 Mar 2001 14:14:32 -0400 Date: Tue, 27 Mar 2001 14:21:16 -0400 To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: loop stuff Message-Id: <01Mar27.141432ast.7308@dragon.appliedmicro.ns.ca> References: <20010327200219.B32706@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010327200219.B32706@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Mar 27, 2001 at 02:02:19PM -0400 From: fifield@amirix.com (Jamie Fifield) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 992 Lines: 30 I think Jens' latest loop patches made it into 2.4.3-pre3 (or pre4). Anyway, they're working fine for me on my IA32 workstation. jamie:~$ uname -a Linux jamie 2.4.3-pre8 #1 Mon Mar 26 11:37:58 AST 2001 i686 unknown On Tue, Mar 27, 2001 at 02:02:19PM -0400, Florian Lohoff wrote: > Hi, > does anyone know if the 2.4.2 kernel does support loop devices - I mean > in the sense of - "It works" - I do have problems with processes like > mke2fs getting hung while accessing the loop without any error message. > > I am not running 2.4.x on any other platform so i cant verify ... > > Flo > -- > Florian Lohoff flo@rfc822.org +49-5201-669912 > Why is it called "common sense" when nobody seems to have any? > -- Jamie Fifield Software Designer Jamie.Fifield@amirix.com AMIRIX Systems Inc. http://www.amirix.com/ Embedded Debian Project http://www.emdebian.org/ 77 Chain Lake Drive 902-450-1700 x247 (Phone) Halifax, N.S. B3S 1E1 902-450-1704 (FAX) From owner-linux-mips@oss.sgi.com Tue Mar 27 10:24:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RIOGx05559 for linux-mips-outgoing; Tue, 27 Mar 2001 10:24:16 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RIOBM05551 for ; Tue, 27 Mar 2001 10:24:14 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA22261; Tue, 27 Mar 2001 20:24:13 +0200 (MET DST) Date: Tue, 27 Mar 2001 20:24:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: Keith M Wesolowski cc: David Jez , Karel van Houten , linux-mips@oss.sgi.com Subject: Re: rpm crashing on RH 7.0 indy In-Reply-To: <20010317093919.A19754@foobazco.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: 1086 Lines: 23 On Sat, 17 Mar 2001, Keith M Wesolowski wrote: > That's not the problem. The problem is that static binaries which use > libdl used to be (and perhaps still are) broken. The reason it's > using libdl is that the nss libraries are never truly static, unless > you compile glibc with a special non-recommended option. I have > indications that this may be fixed in glibc 2.2.2 using my current > toolchain, but my information is not complete. Glibc is fine; it's the kernel that needs a fix (I've sent it here already once or twice). We might possibly consider putting a workaround into glibc as well. The problem is mmap() fails if a non-zero preferred address is given but the space is already occupied and no space *above* is available (space below is not taken into account). A glibc workaround might be to call mmap() again with no preferred address specified this time. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Mar 27 11:03:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RJ3Av06686 for linux-mips-outgoing; Tue, 27 Mar 2001 11:03:10 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RJ38M06683 for ; Tue, 27 Mar 2001 11:03:08 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA23797; Tue, 27 Mar 2001 21:02:36 +0200 (MET DST) Date: Tue, 27 Mar 2001 21:02:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: Karel van Houten cc: Simon Gee , linux-mips@oss.sgi.com Subject: Re: Recommended toolchain In-Reply-To: <200103202012.VAA07412@sparta.research.kpn.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: 813 Lines: 21 On Tue, 20 Mar 2001, Karel van Houten wrote: > Well, I'm currently using: > binutils 2.10.1 > gcc 2.95.3 (with Maciej's patches) > glibc 2.2.2 (compiled with above toolchain). > > This toolchain works for native compiles on my mipsel box. > One drawback: I can't compile any kernels with this setup, > For kernel compiles I use 2.8.1/egcs-2.90.27/glibc-2.0.6. What's wrong with the toolchain wrt the kernel now? I've been compiling 2.4 kernels successfully till the end of January -- it's just a lack of time and a nasty bug I want to track down that stop me from trying to compile a new kernel these days. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Mar 27 14:04:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2RM4Oh11930 for linux-mips-outgoing; Tue, 27 Mar 2001 14:04:24 -0800 Received: from woody.ichilton.co.uk (woody.ichilton.co.uk [216.29.174.40]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2RM4NM11927 for ; Tue, 27 Mar 2001 14:04:24 -0800 Received: by woody.ichilton.co.uk (Postfix, from userid 1000) id 1A756802F; Tue, 27 Mar 2001 23:04:23 +0100 (BST) Date: Tue, 27 Mar 2001 23:04:22 +0100 From: Ian Chilton To: Michl Ladislav Cc: linux-mips@oss.sgi.com Subject: Vino Video / Indycam (was Re: indy's hardware watchdog) Message-ID: <20010327230422.A4071@woody.ichilton.co.uk> Reply-To: Ian Chilton References: <20010327185423.B3617@woody.ichilton.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: ; from xmichl03@stud.fee.vutbr.cz on Tue, Mar 27, 2001 at 09:57:25PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 508 Lines: 33 Hello, > > If you look in any kernel tree, under drivers/char/ you will find > > vino.c and vino.h > well, i found them under drivers/media/video/ Seems they have been moved in 2.4. In 2.2.18: [ian@buzz:/usr/src/linux/drivers/char]$ ls vino* vino.c vino.h In 2.4.2: [ian@dipsy:/usr/src/linux/drivers/media/video]$ ls vino* vino.c [ian@dipsy:/usr/src/linux/drivers/char]$ ls vino* vino.h > but haven't any hw docs. Yes, they are in: ftp://oss.sgi.com/pub/linux/mips/doc/indy/ Bye for Now, Ian From owner-linux-mips@oss.sgi.com Tue Mar 27 23:12:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f2S7Cnv28089 for linux-mips-outgoing; Tue, 27 Mar 2001 23:12:49 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f2S7CmM28086 for ; Tue, 27 Mar 2001 23:12:48 -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 XAA06430; Tue, 27 Mar 2001 23:07:34 -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 XAA15408; Tue, 27 Mar 2001 23:07:31 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id JAA27891; Wed, 28 Mar 2001 09:06:49 +0200 (MEST) Message-ID: <3AC18D89.A2A4386A@mips.com> Date: Wed, 28 Mar 2001 09:06:49 +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: "Maciej W. Rozycki" CC: Keith M Wesolowski , David Jez , Karel van Houten