From owner-linux-mips@oss.sgi.com Fri Mar 1 06:47:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21ElvU24203 for linux-mips-outgoing; Fri, 1 Mar 2002 06:47:57 -0800 Received: from oemcomputer (host187.host.nigol.net.ng [212.96.29.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21Ell924199 for ; Fri, 1 Mar 2002 06:47:49 -0800 Message-Id: <200203011447.g21Ell924199@oss.sgi.com> From: "Thomas Aghedo" To: Subject: BUSINESS OFFER Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 1 Mar 2002 14:49:28 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, I have been instructed by my colleagues to look for partners who can assist us execute an urgent business transaction involving huge profits and international cooperation. We are interested in the importation of Solar Panels, Agricultural equipment and computer accessories. We need a foreign partner who can assist us with the transaction involving US$27 350 000.00 which has been set-aside in an escrow account. We have resolved that a negotiable percentage will be your commission for participating in this transaction on our behalf and any other assistance you may give in this deal. A percentage will also be set aside from the entire sum to settle any expenses we may incure in the cause on these transactions.Do not be worried about bills that we know we might incur as we have already made arrangements with our creditors to offset these bills. My colleagues and I are civil servants and as such, it is not possible for any of us to operate a foreign account directly; hence we are soliciting your support. We propose to finalize the transaction in ten working days. If this proposal is accepted please respond to us via e-mail to enable us provide you with the detailed modalities for the successful completion of the project. I would also suppose you'd prefer a voice contact which requires sending your telephone and fax numbers to facilitate the various processes.There is no risk involved we just need an international contact.Moreso,it will be of great importance you provide me with your telephone/fax details,so we can have a more detailed conversation regarding the whole project.Please remember as against misconceptions emanating from bad publicity that my country has received we have made arrangements with our creditors to take care of the bills. Finally, if you are not interested in this proposal, I apologize on behalf of myself and my colleagues for any inconvenience. Yours Sincerely, Engr:Thomas Aghedo Ps: Please kindly respond via my private and confidential e- mail address:thomasaghedo5003@yahoo.com From owner-linux-mips@oss.sgi.com Fri Mar 1 19:25:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g223PvI15375 for linux-mips-outgoing; Fri, 1 Mar 2002 19:25:57 -0800 Received: from paul.rutgers.edu (paul.rutgers.edu [128.6.5.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g223Pp915367 for ; Fri, 1 Mar 2002 19:25:51 -0800 Received: (from muthur@localhost) by paul.rutgers.edu (8.10.2+Sun/8.8.8) id g222PnF06013; Fri, 1 Mar 2002 21:25:49 -0500 (EST) Date: Fri, 1 Mar 2002 21:25:49 -0500 (EST) From: Muthukumar Ratty To: linux-mips@oss.sgi.com Subject: Cross toolchain problem?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, My toolchain information Host : redhat linux 7.1 in a i386 PC Tool chains built as per Brad LaRonde's writeup. (Building a Modern MIPS Cross-Toolchain for Linux) gcc: version 3.0.3 binutils : version 2.11.92.0.7 20011016 glibc: version 2.2.3 with linux threads patch and mips-base-addr patch from Brad. I was able to build kernel 2.4.3, I got from oss.sgi.com and it works fine (thanks to everyone). So I assumed my toolchain is working fine. Next I modified the yamon startup code (just used reset.S, gt64120.S, link.xn and did some cleaning to get it compiled). When I tried to run srecconv.pl util, I got error message "Out of memory!" (I wanto convert it into flash format to download. The strange thing is, I have an Algorithmics toolchain version egcs-2.90.23 980102, GNU ld 2.9.1/sde-4.0.3, and the srec I got from it doesnt havethis problem) I tried to trace down and found that the srec generated has load address 0x80001000 for data and 0xbfc00000 for the startup code (this is because the link.xn is defined this way). So when an associative array is used in perl script srecconv.pl, it runs out of memory. I dont know perl and I am stuck here. Can somebody point me how to proceed? thanks a lot. (i really want to have the data loaded at 0x80001000 but it should be initially in flash). So I changed the data load address to 0xbfc01000 and now the srecconv works fine and I got a .fl image. But my "jal gt64120_init" is assembled to use _gp and I dont think I set the _gp properly ( I am still in the process of reading Dominics book:). so the code is not at all entering in to the gt64120_init function. but when I change it to "j gt64120_init" it works fine. (Cant I use "jal" here?) Any help would be appreciated and sorry for this long mail, Thanks, Muthu From owner-linux-mips@oss.sgi.com Fri Mar 1 21:23:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g225NIO17600 for linux-mips-outgoing; Fri, 1 Mar 2002 21:23:18 -0800 Received: from paul.rutgers.edu (paul.rutgers.edu [128.6.5.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g225NB917597 for ; Fri, 1 Mar 2002 21:23:11 -0800 Received: (from muthur@localhost) by paul.rutgers.edu (8.10.2+Sun/8.8.8) id g224MaI12437; Fri, 1 Mar 2002 23:22:36 -0500 (EST) Date: Fri, 1 Mar 2002 23:22:36 -0500 (EST) From: Muthukumar Ratty To: linux-mips@oss.sgi.com Subject: Re: Cross toolchain problem?? 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 To add to my previous mail: The same code when I build with Algorithmics tool chain builds "jal gt64120" properly, I mean it doesnt use _gp. But I cannot stick with Algorithmics tool chain because when I build the kernel 2.4.3 it complains that "my Algorithmics toolchain is old and it builds buggy kernel." I am really stuck here for a while and any help would be appreciated. Thanks a lot, Muthu On Fri, 1 Mar 2002, Muthukumar Ratty wrote: > > Hi, > > My toolchain information > Host : redhat linux 7.1 in a i386 PC > > Tool chains built as per Brad LaRonde's writeup. > (Building a Modern MIPS Cross-Toolchain for Linux) > gcc: version 3.0.3 > binutils : version 2.11.92.0.7 20011016 > glibc: version 2.2.3 with linux threads patch and mips-base-addr patch > from Brad. > > I was able to build kernel 2.4.3, I got from oss.sgi.com and it works fine > (thanks to everyone). So I assumed my toolchain is working fine. Next I > modified the yamon startup code (just used reset.S, gt64120.S, link.xn and > did some cleaning to get it compiled). When I tried to run srecconv.pl > util, I got error message "Out of memory!" (I wanto convert it into flash > format to download. The strange thing is, I have an Algorithmics toolchain > version egcs-2.90.23 980102, GNU ld 2.9.1/sde-4.0.3, and the srec I got > from it doesnt havethis problem) > > I tried to trace down and found that the srec generated has load > address 0x80001000 for data and 0xbfc00000 for the startup code (this is > because the link.xn is defined this way). So when an associative array is > used in perl script srecconv.pl, it runs out of memory. I dont know perl > and I am stuck here. Can somebody point me how to proceed? thanks a lot. > (i really want to have the data loaded at 0x80001000 but it should be > initially in flash). > > So I changed the data load address to 0xbfc01000 and now the srecconv > works fine and I got a .fl image. But my "jal gt64120_init" is assembled > to use _gp and I dont think I set the _gp properly ( I am still in the > process of reading Dominics book:). so the code is not at all entering in > to the gt64120_init function. but when I change it to "j gt64120_init" > it works fine. (Cant I use "jal" here?) > > Any help would be appreciated and sorry for this long mail, > Thanks, > Muthu > > > From owner-linux-mips@oss.sgi.com Sat Mar 2 01:37:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g229bCF21666 for linux-mips-outgoing; Sat, 2 Mar 2002 01:37:12 -0800 Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g229b5921660 for ; Sat, 2 Mar 2002 01:37:05 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id AAA24009; Sat, 2 Mar 2002 00:36:51 -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 AAA28165; Sat, 2 Mar 2002 00:36:54 -0800 (PST) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g228aJA17572; Sat, 2 Mar 2002 09:36:20 +0100 (MET) Message-ID: <3C808F91.D9B5DC6D@mips.com> Date: Sat, 02 Mar 2002 09:38:41 +0100 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Muthukumar Ratty CC: linux-mips@oss.sgi.com Subject: Re: Cross toolchain problem?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Muthukumar Ratty wrote: > To add to my previous mail: > The same code when I build with Algorithmics tool chain builds "jal > gt64120" properly, I mean it doesnt use _gp. > > But I cannot stick with Algorithmics tool chain because when I build the > kernel 2.4.3 it complains that "my Algorithmics toolchain is old and it > builds buggy kernel." Just remove the check from the kernel. > > I am really stuck here for a while and any help would be appreciated. > Thanks a lot, > Muthu > > On Fri, 1 Mar 2002, Muthukumar Ratty wrote: > > > > > Hi, > > > > My toolchain information > > Host : redhat linux 7.1 in a i386 PC > > > > Tool chains built as per Brad LaRonde's writeup. > > (Building a Modern MIPS Cross-Toolchain for Linux) > > gcc: version 3.0.3 > > binutils : version 2.11.92.0.7 20011016 > > glibc: version 2.2.3 with linux threads patch and mips-base-addr patch > > from Brad. > > > > I was able to build kernel 2.4.3, I got from oss.sgi.com and it works fine > > (thanks to everyone). So I assumed my toolchain is working fine. Next I > > modified the yamon startup code (just used reset.S, gt64120.S, link.xn and > > did some cleaning to get it compiled). When I tried to run srecconv.pl > > util, I got error message "Out of memory!" (I wanto convert it into flash > > format to download. The strange thing is, I have an Algorithmics toolchain > > version egcs-2.90.23 980102, GNU ld 2.9.1/sde-4.0.3, and the srec I got > > from it doesnt havethis problem) > > > > I tried to trace down and found that the srec generated has load > > address 0x80001000 for data and 0xbfc00000 for the startup code (this is > > because the link.xn is defined this way). So when an associative array is > > used in perl script srecconv.pl, it runs out of memory. I dont know perl > > and I am stuck here. Can somebody point me how to proceed? thanks a lot. > > (i really want to have the data loaded at 0x80001000 but it should be > > initially in flash). > > > > So I changed the data load address to 0xbfc01000 and now the srecconv > > works fine and I got a .fl image. But my "jal gt64120_init" is assembled > > to use _gp and I dont think I set the _gp properly ( I am still in the > > process of reading Dominics book:). so the code is not at all entering in > > to the gt64120_init function. but when I change it to "j gt64120_init" > > it works fine. (Cant I use "jal" here?) > > > > Any help would be appreciated and sorry for this long mail, > > Thanks, > > Muthu > > > > > > From owner-linux-mips@oss.sgi.com Sat Mar 2 07:59:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g22FxYP29485 for linux-mips-outgoing; Sat, 2 Mar 2002 07:59:34 -0800 Received: from paul.rutgers.edu (paul.rutgers.edu [128.6.5.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g22FxW929482 for ; Sat, 2 Mar 2002 07:59:32 -0800 Received: (from muthur@localhost) by paul.rutgers.edu (8.10.2+Sun/8.8.8) id g22ExUs27141; Sat, 2 Mar 2002 09:59:30 -0500 (EST) Date: Sat, 2 Mar 2002 09:59:30 -0500 (EST) From: Muthukumar Ratty To: Carsten Langgaard cc: linux-mips@oss.sgi.com Subject: Re: Cross toolchain problem?? In-Reply-To: <3C808F91.D9B5DC6D@mips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks Carsten, But wont it produce any buggy kernel as the warning says? Muthu From owner-linux-mips@oss.sgi.com Sun Mar 3 01:02:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2392FG11202 for linux-mips-outgoing; Sun, 3 Mar 2002 01:02:15 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23922911198 for ; Sun, 3 Mar 2002 01:02:03 -0800 Message-Id: <200203030902.g23922911198@oss.sgi.com> Received: (qmail 11729 invoked from network); 3 Mar 2002 08:06:50 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 3 Mar 2002 08:06:50 -0000 Date: Sun, 3 Mar 2002 15:58:50 +0800 From: Zhang Fuxin To: "linux-mips@oss.sgi.com" Subject: [PATCH] Re: Re: Re: Re: used_math not cleared for new processes? X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g23924911200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, ÔÚ 2002-03-01 11:11:00 you wrote£º >hi, > sorry,it seems this patch bring other problem,please don't use. >i am investigating it. With this patch, there may be more than one processes having CP0_CU1 enabled, thus fp context may be corrupted silently. The fix is to deprive fpu from last_task_used_math(if not null) in init_fpu See the modified patch below. BTW,when debugging for this problem,i found that every process will use fpu at least once. in a statically linked executable of this program: main() {} there are two cfc1, one in __setfpucw,the other in __sigsetjmp_aux and many fpu ops in __mktime_internal. the first fpu usage is caused by __setfpucw. >>> >>>I think it make sense to clear used_math in do_exec(). It also improvies the >>> performance slightly by not loading the parent's FPU context when it uses the >>>FPU for the first time. it will need init_fpu then,but anyway register access is faster than memory access. >>> >>>Do you have a patch for this? >>Yes. Here it is. >> >>--- processor.h.ori Thu Feb 28 15:02:20 2002 >>+++ processor.h Thu Feb 28 15:00:10 2002 >>@@ -215,6 +215,7 @@ >> regs->cp0_epc = new_pc; \ >> regs->regs[29] = new_sp; \ >> current->thread.current_ds = USER_DS; \ >>+ current->used_math = 0; \ >> } while (0) >> >> unsigned long get_wchan(struct task_struct *p); >> >> >>--- traps.c.ori Thu Feb 28 15:04:48 2002 >>+++ traps.c Thu Feb 28 15:05:23 2002 >>@@ -668,8 +668,12 @@ >> if (current->used_math) { /* Using the FPU again. */ >> lazy_fpu_switch(last_task_used_math); >> } else { /* First time FPU user. */ >>- if (last_task_used_math != NULL) >>+ if (last_task_used_math != NULL) { >>+ int status = read_32bit_cp0_register(CP0_STATUS); >>+ write_32bit_cp0_register(CP0_STATUS,status|ST0_CU1); >>+ >> save_fp(last_task_used_math); >>+ } This should be changed to: + if (last_task_used_math != NULL) { + __enable_fpu(); save_fp(last_task_used_math); + /* last_task_used_math loose fpu */ + ((struct pt_regs *)(__KSTK_TOS(last_task_used_math) - sizeof(struct pt_regs)))->cp0_status &= ~ST0_CU1; + } >> init_fpu(); >> current->used_math = 1; >> } >> >> >>> >>>Jun >> >>Regards >> Zhang Fuxin >> fxzhang@ict.ac.cn > >Regards > Zhang Fuxin > fxzhang@ict.ac.cn Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Sun Mar 3 04:13:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23CD6m13348 for linux-mips-outgoing; Sun, 3 Mar 2002 04:13:06 -0800 Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23CD4913345 for ; Sun, 3 Mar 2002 04:13:04 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id DAA25617; Sun, 3 Mar 2002 03:12:55 -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 DAA18679; Sun, 3 Mar 2002 03:12:54 -0800 (PST) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g23BCEA05678; Sun, 3 Mar 2002 12:12:19 +0100 (MET) Message-ID: <3C82059D.A8DF389E@mips.com> Date: Sun, 03 Mar 2002 12:14:37 +0100 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Muthukumar Ratty CC: linux-mips@oss.sgi.com Subject: Re: Cross toolchain problem?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hopefully not with the Algorithmics toolchain, otherwise we will like to know. /Carsten Muthukumar Ratty wrote: > Thanks Carsten, > But wont it produce any buggy kernel as the warning says? > Muthu From owner-linux-mips@oss.sgi.com Sun Mar 3 06:23:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23ENE919517 for linux-mips-outgoing; Sun, 3 Mar 2002 06:23:14 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23EN7919513 for ; Sun, 3 Mar 2002 06:23:07 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g23DN0403097; Sun, 3 Mar 2002 13:23:01 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15490.9137.106468.837502@gladsmuir.algor.co.uk> Date: Sun, 3 Mar 2002 13:22:57 +0000 To: Carsten Langgaard Cc: Muthukumar Ratty , linux-mips@oss.sgi.com Subject: Re: Cross toolchain problem?? In-Reply-To: <3C82059D.A8DF389E@mips.com> References: <3C82059D.A8DF389E@mips.com> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Carsten Langgaard (carstenl@mips.com) writes: > Hopefully not with the Algorithmics toolchain, otherwise we will like to > know. Speaking for Algorithmics: I suspect there may be problems building a 2.4+ kernel with SDE-MIPS v4.0c. The people who made 2.4 were very enthusiastic about the latest and greatest language extensions in GCC, and SDE-MIPS v4.0c is based on quite an old compiler. 2.2 should be fine with SDE-MIPS v4.0c; 2.4+ is known to work with SDE-MIPS v5.0, which is only in beta so far. With some makefile tweaks that should build kernels with no trouble. Soon there should be a compiler distribution from Algorithmics which is based on the v5.0 sources, but configured for Linux. That should be best. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Sun Mar 3 10:50:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23IouD22252 for linux-mips-outgoing; Sun, 3 Mar 2002 10:50:56 -0800 Received: from darth.paname.org (root@ns0.paname.org [212.27.32.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23Ioq922249 for ; Sun, 3 Mar 2002 10:50:52 -0800 Received: from darth.paname.org (localhost [127.0.0.1]) by darth.paname.org (8.12.1/8.12.1/Debian -2) with ESMTP id g23HooZB001860 for ; Sun, 3 Mar 2002 18:50:50 +0100 Received: (from rani@localhost) by darth.paname.org (8.12.1/8.12.1/Debian -2) id g23HonFN001859 for linux-mips@oss.sgi.com; Sun, 3 Mar 2002 18:50:49 +0100 From: Rani Assaf Date: Sun, 3 Mar 2002 18:50:49 +0100 To: linux-mips@oss.sgi.com Subject: Changes to head.S Message-ID: <20020303185049.A1788@paname.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux darth 2.4.17-pre8 X-NCC-RegID: fr.proxad Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I'm working on support for IDT RC32355 CPU on a board we're developping and when trying to port my code to a recent snapshot of the cvs tree (up to now, I was using a snapshot dated of dec 15, 2001), the kernel crashed at boot while starting the init thread (unaligned access). Looking at the diffs, I noticed that putting back the following lines at the end of head.S (they've been removed in revision 1.29.2.4) resolves the problem: /* * Align to 8kb boundary for init_task_union which follows in the * .text segment. */ .text .align 13 Any idea why they have been removed? BTW, print_memory_map() (in kernel.c) now uses long long format without casting (which obviously gives wrong numbers on 32bits archs). Regards, Rani From owner-linux-mips@oss.sgi.com Sun Mar 3 14:56:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23Mux324715 for linux-mips-outgoing; Sun, 3 Mar 2002 14:56:59 -0800 Received: from dea.linux-mips.net (a1as07-p52.stg.tli.de [195.252.188.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23Mus924712 for ; Sun, 3 Mar 2002 14:56:54 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g23LuVh17022; Sun, 3 Mar 2002 22:56:31 +0100 Date: Sun, 3 Mar 2002 22:56:31 +0100 From: Ralf Baechle To: Rani Assaf Cc: linux-mips@oss.sgi.com Subject: Re: Changes to head.S Message-ID: <20020303225630.A16898@dea.linux-mips.net> References: <20020303185049.A1788@paname.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020303185049.A1788@paname.org>; from rani@paname.org on Sun, Mar 03, 2002 at 06:50:49PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 03, 2002 at 06:50:49PM +0100, Rani Assaf wrote: > /* > * Align to 8kb boundary for init_task_union which follows in the > * .text segment. > */ > .text > .align 13 > > Any idea why they have been removed? init_task_union lives in it's own section which has 8kB alignment. So if you're observing an alignment problem I suspect you're using a too old egcs 1.1.2 variant. > BTW, print_memory_map() (in kernel.c) now uses long long format > without casting (which obviously gives wrong numbers on 32bits archs). Yes and we preferably want to get rid of long long anyway. Ralf From owner-linux-mips@oss.sgi.com Sun Mar 3 15:04:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23N4va24949 for linux-mips-outgoing; Sun, 3 Mar 2002 15:04:57 -0800 Received: from darth.paname.org (root@ns0.paname.org [212.27.32.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23N4p924946; Sun, 3 Mar 2002 15:04:51 -0800 Received: from darth.paname.org (localhost [127.0.0.1]) by darth.paname.org (8.12.1/8.12.1/Debian -2) with ESMTP id g23M4nZB003147; Sun, 3 Mar 2002 23:04:49 +0100 Received: (from rani@localhost) by darth.paname.org (8.12.1/8.12.1/Debian -2) id g23M4nEB003146; Sun, 3 Mar 2002 23:04:49 +0100 From: Rani Assaf Date: Sun, 3 Mar 2002 23:04:49 +0100 To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Changes to head.S Message-ID: <20020303230449.K1788@paname.org> References: <20020303185049.A1788@paname.org> <20020303225630.A16898@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020303225630.A16898@dea.linux-mips.net> User-Agent: Mutt/1.3.23i X-Operating-System: Linux darth 2.4.17-pre8 X-NCC-RegID: fr.proxad Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 03, 2002 at 10:56:31PM +0100, Ralf Baechle wrote: > you're observing an alignment problem I suspect you're using a too old > egcs 1.1.2 variant. Hmm.. It's the redhat one on ftp://oss.sgi.com/pub/linux/mips/: Reading specs from /opt/Mipsel/bin/../lib/gcc-lib/mipsel-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) Is there anything newer/better (I thought that this is the place were H.J. Lu binutils/gcc is stored)? BTW, is there any interest in integrating the RC32355 support into the main tree? (I can provide the code that runs on IDT eval boards though we're not using them anymore). Regards, Rani From owner-linux-mips@oss.sgi.com Sun Mar 3 15:19:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23NJHi25154 for linux-mips-outgoing; Sun, 3 Mar 2002 15:19:17 -0800 Received: from dea.linux-mips.net (a1as07-p52.stg.tli.de [195.252.188.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23NJB925150 for ; Sun, 3 Mar 2002 15:19:11 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g23MJ6w17252; Sun, 3 Mar 2002 23:19:06 +0100 Date: Sun, 3 Mar 2002 23:19:06 +0100 From: Ralf Baechle To: Rani Assaf Cc: linux-mips@oss.sgi.com Subject: Re: Changes to head.S Message-ID: <20020303231906.A17147@dea.linux-mips.net> References: <20020303185049.A1788@paname.org> <20020303225630.A16898@dea.linux-mips.net> <20020303230449.K1788@paname.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020303230449.K1788@paname.org>; from rani@paname.org on Sun, Mar 03, 2002 at 11:04:49PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 03, 2002 at 11:04:49PM +0100, Rani Assaf wrote: > On Sun, Mar 03, 2002 at 10:56:31PM +0100, Ralf Baechle wrote: > > you're observing an alignment problem I suspect you're using a too old > > egcs 1.1.2 variant. > > Hmm.. It's the redhat one on ftp://oss.sgi.com/pub/linux/mips/: > > Reading specs from > /opt/Mipsel/bin/../lib/gcc-lib/mipsel-linux/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) Just doublechecked it. The way the alignment guarantee works is through these two lines in the linker script arch/mips/ld.script.in: . = ALIGN(8192); .data.init_task : { *(.data.init_task) } > Is there anything newer/better (I thought that this is the place were > H.J. Lu binutils/gcc is stored)? > > BTW, is there any interest in integrating the RC32355 support into the > main tree? Sure, send patches to me. > (I can provide the code that runs on IDT eval boards though > we're not using them anymore). I certainly would appreciate somebody to take care of maintaining support for such eval boards. By now the number of supported platforms means that the code for platforms otherwise soon would start to bitrot. Ralf From owner-linux-mips@oss.sgi.com Sun Mar 3 15:54:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23NsOl30378 for linux-mips-outgoing; Sun, 3 Mar 2002 15:54:24 -0800 Received: from darth.paname.org (root@ns0.paname.org [212.27.32.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23NsI930372; Sun, 3 Mar 2002 15:54:18 -0800 Received: from darth.paname.org (localhost [127.0.0.1]) by darth.paname.org (8.12.1/8.12.1/Debian -2) with ESMTP id g23MsGZB003387; Sun, 3 Mar 2002 23:54:16 +0100 Received: (from rani@localhost) by darth.paname.org (8.12.1/8.12.1/Debian -2) id g23MsGxi003386; Sun, 3 Mar 2002 23:54:16 +0100 From: Rani Assaf Date: Sun, 3 Mar 2002 23:54:16 +0100 To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Changes to head.S Message-ID: <20020303235416.D3190@paname.org> References: <20020303185049.A1788@paname.org> <20020303225630.A16898@dea.linux-mips.net> <20020303230449.K1788@paname.org> <20020303231906.A17147@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020303231906.A17147@dea.linux-mips.net> User-Agent: Mutt/1.3.23i X-Operating-System: Linux darth 2.4.17-pre8 X-NCC-RegID: fr.proxad Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 03, 2002 at 11:19:06PM +0100, Ralf Baechle wrote: > these two lines in the linker script arch/mips/ld.script.in: > > . = ALIGN(8192); > .data.init_task : { *(.data.init_task) } Yep, I was just looking at it. So the problem is in init_task.c. The following line should be changed from: __attribute__((__section__(".text"))) = to: __attribute__((__section__(".data.init_task"))) = Right? Regards, Rani From owner-linux-mips@oss.sgi.com Sun Mar 3 16:10:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g240AAD30704 for linux-mips-outgoing; Sun, 3 Mar 2002 16:10:10 -0800 Received: from darth.paname.org (root@ns0.paname.org [212.27.32.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g240A8930701 for ; Sun, 3 Mar 2002 16:10:09 -0800 Received: from darth.paname.org (localhost [127.0.0.1]) by darth.paname.org (8.12.1/8.12.1/Debian -2) with ESMTP id g23NA7ZB006471 for ; Mon, 4 Mar 2002 00:10:07 +0100 Received: (from news@localhost) by darth.paname.org (8.12.1/8.12.1/Debian -2) id g23N0O0I003466 for linux-mips@paname.org; Mon, 4 Mar 2002 00:00:24 +0100 Date: Mon, 4 Mar 2002 00:00:24 +0100 From: linux-mips-local@paname.org Message-Id: <200203032300.g23N0O0I003466@darth.paname.org> X-Authentication-Warning: darth.paname.org: news set sender to linux-mips-local@paname.org using -f To: undisclosed-recipients:; Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From owner-linux-mips@oss.sgi.com Sun Mar 3 16:32:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g240Wjp30916 for linux-mips-outgoing; Sun, 3 Mar 2002 16:32:45 -0800 Received: from dea.linux-mips.net (a1as07-p52.stg.tli.de [195.252.188.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g240Wb930913 for ; Sun, 3 Mar 2002 16:32:39 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g23NWSe17853; Mon, 4 Mar 2002 00:32:28 +0100 Date: Mon, 4 Mar 2002 00:32:28 +0100 From: Ralf Baechle To: Rani Assaf Cc: linux-mips@oss.sgi.com Subject: Re: Changes to head.S Message-ID: <20020304003228.A17827@dea.linux-mips.net> References: <20020303185049.A1788@paname.org> <20020303225630.A16898@dea.linux-mips.net> <20020303230449.K1788@paname.org> <20020303231906.A17147@dea.linux-mips.net> <20020303235416.D3190@paname.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020303235416.D3190@paname.org>; from rani@paname.org on Sun, Mar 03, 2002 at 11:54:16PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 03, 2002 at 11:54:16PM +0100, Rani Assaf wrote: > On Sun, Mar 03, 2002 at 11:19:06PM +0100, Ralf Baechle wrote: > > these two lines in the linker script arch/mips/ld.script.in: > > > > . = ALIGN(8192); > > .data.init_task : { *(.data.init_task) } > > Yep, I was just looking at it. So the problem is in init_task.c. The > following line should be changed from: > > __attribute__((__section__(".text"))) = > > to: > __attribute__((__section__(".data.init_task"))) = > > Right? Yes, just as it already is in CVS for kernel 2.4. Ralf From owner-linux-mips@oss.sgi.com Mon Mar 4 12:19:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24KJll24843 for linux-mips-outgoing; Mon, 4 Mar 2002 12:19:47 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24KJa924838 for ; Mon, 4 Mar 2002 12:19:36 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA02475; Mon, 4 Mar 2002 20:19:28 +0100 (MET) Date: Mon, 4 Mar 2002 20:19:28 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle , Jan-Benedict Glaw cc: Linux-MIPS Subject: [patch] Critical swapping problems In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, After studying dependencies I concluded the Flo's patch for R3k swapping is OK -- it correctly zeroes the valid and global bits of swapped-out PTEs. Additionally the R4k+ version didn't zero the global bit. Here is a patch I successfully tested using an NVRAM and a RAM-disk as swap devices on my R3k system. I took quite some time, but weird Oopses and init crashes were distracting me. It turned out these were signal delivery bugs (or at least that's what I suspect) that were not directly related to the patch but to the test environment I created (the bugs are still a mystery and are under investigation) -- without the patch they happen as well, usually under conditions near OOM. The patch consists mostly of the Flo's changes with R4k+ bits as well as comment updates added by me. Given enough virtual memory the patch works very well -- I've run `tar -jxf glibc-2.2.5.tar.bz2; rm -rf glibc-2.2.5' for a few hours in a loop which with RAM clipped to 16MB and 32MB of swap gives a considerable swap activity, with no problems noticed. Ralf, the patch is *CRITICAL* for R3k -- please apply it as soon as possible. The R4k+ update is not so important as MAX_SWAPFILES protects us, but it should go in anyway for correctness. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.17-20020129-swap-2 diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/include/asm-mips/pgtable.h linux-mips-2.4.17-20020129/include/asm-mips/pgtable.h --- linux-mips-2.4.17-20020129.macro/include/asm-mips/pgtable.h Fri Jan 25 05:27:42 2002 +++ linux-mips-2.4.17-20020129/include/asm-mips/pgtable.h Wed Feb 27 00:55:35 2002 @@ -165,7 +165,7 @@ extern int add_temporary_entry(unsigned #define _PAGE_SILENT_READ (1<<9) /* synonym */ #define _PAGE_DIRTY (1<<10) /* The MIPS dirty bit */ #define _PAGE_SILENT_WRITE (1<<10) -#define _CACHE_UNCACHED (1<<11) /* R4[0246]00 */ +#define _CACHE_UNCACHED (1<<11) #define _CACHE_MASK (1<<11) #define _CACHE_CACHABLE_NONCOHERENT 0 @@ -518,9 +518,19 @@ extern void paging_init(void); extern void update_mmu_cache(struct vm_area_struct *vma, unsigned long address, pte_t pte); -#define SWP_TYPE(x) (((x).val >> 1) & 0x3f) +/* Swap entries must have VALID and GLOBAL bits cleared. */ +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) + +#define SWP_TYPE(x) (((x).val >> 1) & 0x7f) +#define SWP_OFFSET(x) ((x).val >> 10) +#define SWP_ENTRY(type,offset) ((swp_entry_t) { ((type) << 1) | ((offset) << 10) }) +#else + +#define SWP_TYPE(x) (((x).val >> 1) & 0x1f) #define SWP_OFFSET(x) ((x).val >> 8) #define SWP_ENTRY(type,offset) ((swp_entry_t) { ((type) << 1) | ((offset) << 8) }) +#endif + #define pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) }) #define swp_entry_to_pte(x) ((pte_t) { (x).val }) From owner-linux-mips@oss.sgi.com Mon Mar 4 12:56:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24KuMI25623 for linux-mips-outgoing; Mon, 4 Mar 2002 12:56:22 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24KuD925620 for ; Mon, 4 Mar 2002 12:56:13 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA05230 for ; Mon, 4 Mar 2002 11:56:13 -0800 (PST) mail_from (jsun@mvista.com) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g24JlvB32229; Mon, 4 Mar 2002 11:47:57 -0800 Message-ID: <3C83D029.2080402@mvista.com> Date: Mon, 04 Mar 2002 11:51:05 -0800 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: experimental FPU context switch patch Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I implemented a new FPU context saving/restoring patch, as previously suggested by Kevin and Ralf. The major change is that we will save the FPU context when we switch out a process, if necessary. The goal is to gurrantee an off-line process always has its FPU context saved in memory and thus free to move aother CPU in a SMP system. The initial experimental patch can be found at the following URL. It is a quick hack to study the performance impact. It should be further optimized. It also needs to be extended so that it works for all CPUs (including the ones without FPU) and becomes true SMP-safe (getting rid of global variable last_task_used_math). http://linux.junsun.net/patches/oss.sgi.com/experiemental/020304-new-fpu-context-switch/patch Here is the pseudo code version of the patch: do_cpu() { if (current->used_math) { /* Using the FPU again. */ - lazy_fpu_switch(last_task_used_math); + restore_fp(current); /* we don't need to save for the current proc */ } else { /* First time FPU user. */ r4xx0_resume() save non_scratch registers + if (current proc owns FPU) { /* t used FPU in the curr run */ + make it turn off FPU for next run + save FPU context to current proc + (note we leave last_task_used_math alone) .... lmbench is run to compare the performance difference on a UP system (NEC VR5500). See the output at the following URL. orig are the unpatched kernel. http://linux.junsun.net/patches/oss.sgi.com/experiemental/020304-new-fpu-context-switch/performance It is obvious there is not much performance difference. And this is not a surprise. A couple of attributes of the patch: 1) it does not save FPU if the proc did not use FPU in the current run 2) when proc uses FPU again in next run, we don't have to restore FPU context if the hardware context has not been used by another proc yet (i.e., last_task_used_math == current) So 1) if no processes are actively using FPU, we don't see much overhead other than a couple of load/branch instructions in resume 2) if most processes are actively using FPU, then we see the same overhead. The saving of FPU context is necessary in this scenario, whether it is done resume() (as in the patch) or a little later in lazy_fpu_swotch() as in the current kernel. 3) The only pathological case which would make the patch bad is when you have a process that actively uses FPU and it frequently switches context with non-FPU-using processes. In this case, the saving of FPU context each time fpu-using proc is switched off is an overhead. If each time the fpu-using process runs through a full time slice, the overhead is very small percentage wise. It is the frequent context switching in this case would make a kill. I am interested in testing any benchmarks that would create case 3). Please let me know if you know any. So much for rambling. Jun From owner-linux-mips@oss.sgi.com Mon Mar 4 13:08:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24L8Bc26174 for linux-mips-outgoing; Mon, 4 Mar 2002 13:08:11 -0800 Received: from ayrnetworks.com (64-166-72-137.ayrnetworks.com [64.166.72.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24L89926171 for ; Mon, 4 Mar 2002 13:08:09 -0800 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g24K83S03332 for linux-mips@oss.sgi.com; Mon, 4 Mar 2002 12:08:03 -0800 Date: Mon, 4 Mar 2002 12:08:03 -0800 From: William Jhun To: linux-mips@oss.sgi.com Subject: Compressed images? Message-ID: <20020304120803.A1247@ayrnetworks.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 I've been looking through the recent linux-mips archives and it seems there isn't a concensus about where to build compressed ((b)zImage) images. We have been placing our code under arch/mips/boot/compressed, though it seems that the latest oss tree doesn't have such a directory, and the only reference I can find to building a compressed image is in galileo-boards/ev64120/compressed/. Should we be placing our boot image compression stuff in our platform-specific directory? Are most MIPS-based Linux platforms not using compressed images? Thanks, Will From owner-linux-mips@oss.sgi.com Mon Mar 4 14:33:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24MXkQ00892 for linux-mips-outgoing; Mon, 4 Mar 2002 14:33:46 -0800 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24MXh900889 for ; Mon, 4 Mar 2002 14:33:43 -0800 Received: from excalibur.cologne.de (pD9E40956.dip.t-dialin.net [217.228.9.86]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id WAA15181 for ; Mon, 4 Mar 2002 22:33:40 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 16i03B-00005J-00 for ; Mon, 04 Mar 2002 22:31:17 +0100 Date: Mon, 4 Mar 2002 22:31:17 +0100 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: Compressed images? Message-ID: <20020304223117.B254@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com References: <20020304120803.A1247@ayrnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020304120803.A1247@ayrnetworks.com>; from wjhun@ayrnetworks.com on Mon, Mar 04, 2002 at 12:08:03PM -0800 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Mar 04, 2002 at 12:08:03PM -0800, William Jhun wrote: > Should we be placing our boot image compression stuff in our > platform-specific directory? Are most MIPS-based Linux platforms not > using compressed images? I cannot speak for "most" platforms, but at least the DECstations and the SGI IP22 (Indy and Indigo2) can only boot uncompressed images currently, so it does not make sense to build compressed images for them. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Mon Mar 4 14:57:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24MvC101476 for linux-mips-outgoing; Mon, 4 Mar 2002 14:57:12 -0800 Received: (from ralf@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24Mv9V01472; Mon, 4 Mar 2002 14:57:09 -0800 Date: Mon, 4 Mar 2002 14:57:09 -0800 From: Ralf Baechle To: William Jhun Cc: linux-mips@oss.sgi.com Subject: Re: Compressed images? Message-ID: <20020304145709.A1332@oss.sgi.com> References: <20020304120803.A1247@ayrnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020304120803.A1247@ayrnetworks.com>; from wjhun@ayrnetworks.com on Mon, Mar 04, 2002 at 12:08:03PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Mar 04, 2002 at 12:08:03PM -0800, William Jhun wrote: > I've been looking through the recent linux-mips archives and it seems > there isn't a concensus about where to build compressed ((b)zImage) > images. We have been placing our code under arch/mips/boot/compressed, > though it seems that the latest oss tree doesn't have such a directory, > and the only reference I can find to building a compressed image is in > galileo-boards/ev64120/compressed/. > > Should we be placing our boot image compression stuff in our > platform-specific directory? Are most MIPS-based Linux platforms not > using compressed images? General rant, not directed to you personally. Right now we've got more than half a dozen variations of code to support compressed images throughout the kernel. So I'm not going to accept any new patches for compressed images before this mess has been cleaned. Volunteers :-) Ralf From owner-linux-mips@oss.sgi.com Mon Mar 4 15:50:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24Norf03248 for linux-mips-outgoing; Mon, 4 Mar 2002 15:50:53 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24Non903239; Mon, 4 Mar 2002 15:50:49 -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 g24MlZB10348; Mon, 4 Mar 2002 14:47:35 -0800 Message-ID: <3C83FA43.4090407@mvista.com> Date: Mon, 04 Mar 2002 14:50:43 -0800 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Ralf Baechle CC: William Jhun , linux-mips@oss.sgi.com Subject: Re: Compressed images? References: <20020304120803.A1247@ayrnetworks.com> <20020304145709.A1332@oss.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Mon, Mar 04, 2002 at 12:08:03PM -0800, William Jhun wrote: > > >>I've been looking through the recent linux-mips archives and it seems >>there isn't a concensus about where to build compressed ((b)zImage) >>images. We have been placing our code under arch/mips/boot/compressed, >>though it seems that the latest oss tree doesn't have such a directory, >>and the only reference I can find to building a compressed image is in >>galileo-boards/ev64120/compressed/. >> >>Should we be placing our boot image compression stuff in our >>platform-specific directory? Are most MIPS-based Linux platforms not >>using compressed images? >> > > General rant, not directed to you personally. Right now we've got more > than half a dozen variations of code to support compressed images throughout > the kernel. So I'm not going to accept any new patches for compressed > images before this mess has been cleaned. Volunteers :-) > I think I am leaning towards leaving compressed image outside kernel itself. I don't see any technical reason why it must be inside kernel. Then it must be the code sharing argument. However, it seem MIPS boards are so much more diversified than x86 machines. Any sharing, if there are any, is limited. Also there are other way of sharing code than stacking it into kernle tree, I suppose. Another aimless general rant .... :-) Jun From owner-linux-mips@oss.sgi.com Mon Mar 4 16:03:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2503i104017 for linux-mips-outgoing; Mon, 4 Mar 2002 16:03:44 -0800 Received: from ayrnetworks.com (64-166-72-137.ayrnetworks.com [64.166.72.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2503f904013; Mon, 4 Mar 2002 16:03:41 -0800 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g24N3Yl17733; Mon, 4 Mar 2002 15:03:34 -0800 Date: Mon, 4 Mar 2002 15:03:34 -0800 From: William Jhun To: Jun Sun Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Compressed images? Message-ID: <20020304150334.D1247@ayrnetworks.com> References: <20020304120803.A1247@ayrnetworks.com> <20020304145709.A1332@oss.sgi.com> <3C83FA43.4090407@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C83FA43.4090407@mvista.com>; from jsun@mvista.com on Mon, Mar 04, 2002 at 02:50:43PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Mar 04, 2002 at 02:50:43PM -0800, Jun Sun wrote: > > I think I am leaning towards leaving compressed image outside kernel itself. > > I don't see any technical reason why it must be inside kernel. > > Then it must be the code sharing argument. However, it seem MIPS boards are > so much more diversified than x86 machines. Any sharing, if there are any, is > limited. Also there are other way of sharing code than stacking it into > kernle tree, I suppose. > > Another aimless general rant .... :-) > > Jun But this is a good point. Our own compressed/ build requires building several elf-header-mangling tools just to get our bootstrap (which we can't change) to even recognize the finished image. Though, I'm not sure how much the different decompression (misc.c) routines vary; could there be some way to do this in a platform-independent way? Hmm! Will From owner-linux-mips@oss.sgi.com Mon Mar 4 16:19:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g250JZN04520 for linux-mips-outgoing; Mon, 4 Mar 2002 16:19:35 -0800 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g250JW904516; Mon, 4 Mar 2002 16:19:32 -0800 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id PAA30416; Mon, 4 Mar 2002 15:19:32 -0800 (PST) Date: Mon, 4 Mar 2002 15:19:31 -0800 From: Geoffrey Espin To: Ralf Baechle Cc: William Jhun , linux-mips@oss.sgi.com Subject: Re: Compressed images? Message-ID: <20020304151931.B9117@idiom.com> References: <20020304120803.A1247@ayrnetworks.com> <20020304145709.A1332@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20020304145709.A1332@oss.sgi.com>; from Ralf Baechle on Mon, Mar 04, 2002 at 02:57:09PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Mar 04, 2002 at 02:57:09PM -0800, Ralf Baechle wrote: > Right now we've got more > than half a dozen variations of code to support compressed images throughout > the kernel. So I'm not going to accept any new patches for compressed > images before this mess has been cleaned. Volunteers :-) Do you mean just the 'ad hoc' MIPS schemes, or across the whole gamut of Linux architectures? The problem isn't so much the compression mechanics, but the BSP/LSP. It would be helpful if there was one architecture that was considered the 'ideal'. Though I haven't actually used it: arch/ppc/boot appears very flexible, and adheres to a strict layout and naming convention. Geoff -- Geoffrey Espin espin@idiom.com From owner-linux-mips@oss.sgi.com Mon Mar 4 16:35:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g250Zl604988 for linux-mips-outgoing; Mon, 4 Mar 2002 16:35:47 -0800 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g250Zh904982; Mon, 4 Mar 2002 16:35:44 -0800 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id PAA40038; Mon, 4 Mar 2002 15:35:42 -0800 (PST) Date: Mon, 4 Mar 2002 15:35:42 -0800 From: Geoffrey Espin To: William Jhun Cc: Jun Sun , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Compressed images? Message-ID: <20020304153542.B31050@idiom.com> References: <20020304120803.A1247@ayrnetworks.com> <20020304145709.A1332@oss.sgi.com> <3C83FA43.4090407@mvista.com> <20020304150334.D1247@ayrnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20020304150334.D1247@ayrnetworks.com>; from William Jhun on Mon, Mar 04, 2002 at 03:03:34PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > But this is a good point. Our own compressed/ build requires building > several elf-header-mangling tools just to get our bootstrap (which we > can't change) to even recognize the finished image. > Though, I'm not sure how much the different decompression (misc.c) > routines vary; could there be some way to do this in a > platform-independent way? Pete Popov's mips/zboot is probably the most generic for MIPS, though, it only was done for Alchemy's. See: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linux-mips/linux/arch/mips/zboot/ [I re-ported it to Korva and reduced much of the extraneous fluff (both extra misc- source files and unneeded utils/), but its never been checked into CVS.] Geoff -- Geoffrey Espin espin@idiom.com -- From owner-linux-mips@oss.sgi.com Tue Mar 5 02:16:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25AG4t18961 for linux-mips-outgoing; Tue, 5 Mar 2002 02:16:04 -0800 Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25AFx918956 for ; Tue, 5 Mar 2002 02:15:59 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id g259Fuc11232 for ; Tue, 5 Mar 2002 10:15:57 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4K6LB0A; Tue, 5 Mar 2002 10:15:55 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Tue, 05 Mar 2002 10:15:55 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 10:18:42 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E74B@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: Console problem Date: Tue, 5 Mar 2002 10:18:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g25AG0918958 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi. I wrote my own console driver based on the ARC console driver (to keep it simple). When I am booting my modified 2.4.3 kernel, I get an "unable to open initial console" error (code: No such device). I have tracked it down to the point where the kernel searches for a valid TTY device with major and minor ID 4:64. All devices that are present at this time are: 3:0-3:256 2:0-2:256 5:0 5:1. Obviously there is no 4:64 device. I mount root via NFS and my devices are as follows:. crw------- 1 root tty 5, 1 Mär 4 17:49 console crw------- 1 root tty 4, 0 Mär 4 17:49 tty0 crw-rw-rw- 1 root tty 4, 1 Mär 4 17:49 tty1 ... crw-r--r-- 1 root root 4, 64 Mär 5 08:26 ttyS0 crw-r--r-- 1 root root 4, 65 Mär 5 08:26 ttyS1 I also add a "console=ttyS0,9600" to the kernel command line. Am I missing anything? Why is there no device 4:64? (My console driver identifies itself as 4,64) Any help would be appreciated. best regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Tue Mar 5 05:12:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25DCE524376 for linux-mips-outgoing; Tue, 5 Mar 2002 05:12:14 -0800 Received: from arianna.cineca.it (dns.cineca.it [130.186.1.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25DC7924373 for ; Tue, 5 Mar 2002 05:12:08 -0800 Received: from cineca.it (andrea@nb-venturi.cineca.it [193.204.122.87]) by arianna.cineca.it (8.12.1/8.12.1/CINECA 5.0-MILTER) with ESMTP id g25CBttv019279 for ; Tue, 5 Mar 2002 13:11:56 +0100 (MET) Message-ID: <3C84B611.5050103@cineca.it> Date: Tue, 05 Mar 2002 13:12:01 +0100 From: Andrea Venturi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: device support on indy WS !? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, i just put my hands on a couple of old indy r4000 (quite old) i installed so far a debian woody linux distro! amazing.. i'm wondering about the bunch of special features available on the indy, how much are supported? 1. audio hal2: i saw in the cvs.sgi.com kernel the OSS hal2.* files; what about the guenther alsa0.9 port? is it finished? what about iec958 spdif support? 2. isdn: there is a siemens isac-s chip (BTW i didn't see the hscx twin): is it supported now? it should be not to difficult to leverage the ia32-isdn hisax (passive) isac driver _if_ the hpc3 delivers the irq? what do you think about it? bye andrea venturi From owner-linux-mips@oss.sgi.com Tue Mar 5 06:01:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25E1GP25451 for linux-mips-outgoing; Tue, 5 Mar 2002 06:01:16 -0800 Received: from web13002.mail.yahoo.com (web13002.mail.yahoo.com [216.136.174.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25E1C925447 for ; Tue, 5 Mar 2002 06:01:12 -0800 Message-ID: <20020305130111.99294.qmail@web13002.mail.yahoo.com> Received: from [193.251.90.77] by web13002.mail.yahoo.com via HTTP; Tue, 05 Mar 2002 14:01:11 CET Date: Tue, 5 Mar 2002 14:01:11 +0100 (CET) From: =?iso-8859-1?q?Nicolas=20Sauzede?= Reply-To: nsauzede@yahoo.com Subject: Re: device support on indy WS !? To: linux-mips@oss.sgi.com In-Reply-To: <3C84B611.5050103@cineca.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Sorry, Andrea, I can't answer your question, but I've got one for you.. --- Andrea Venturi a écrit : > hi, > > i just put my hands on a couple of old indy r4000 (quite old) > > i installed so far a debian woody linux distro! amazing.. > I have an old Indy too (R4K) and I would like to test the debian you told about.. I couldn't find it (the mips port) on the debian site. Do someone know where I could find the bin distro, ready to boot to from the Indy ?? For now, I could just boot the kernel of the old Hard Hat (nfs root doesn't work for me) from the local SCSI disk containing an Irix. Thanks, Nicolas Sauzede. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From owner-linux-mips@oss.sgi.com Tue Mar 5 06:07:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25E7hh25685 for linux-mips-outgoing; Tue, 5 Mar 2002 06:07:43 -0800 Received: from hlubocky.del.cz (hlubocky.del.cz [212.27.221.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25E7W925681 for ; Tue, 5 Mar 2002 06:07:32 -0800 Received: from ladis (helo=localhost) by hlubocky.del.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 16iEep-0006ZY-00; Tue, 05 Mar 2002 14:07:07 +0100 Date: Tue, 5 Mar 2002 14:07:07 +0100 (CET) From: Ladislav Michl To: Andrea Venturi cc: linux-mips@oss.sgi.com Subject: Re: device support on indy WS !? In-Reply-To: <3C84B611.5050103@cineca.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 5 Mar 2002, Andrea Venturi wrote: [snip] > 1. audio hal2: i saw in the cvs.sgi.com kernel the OSS hal2.* files; > what about the guenther alsa0.9 port? is it finished? what about iec958 > spdif support? I can't say anything about ALSA 0.9 port. I decided for OSS driver, because I wanded to listen music and there was no driver. OSS is much better documented interface than ALSA. Sometimes you get HAL2 timeout when closing /dev/dsp. It is my fault and I'm sorry for it. Following patch solves it. Index: linux/drivers/sound/hal2.c =================================================================== RCS file: /cvs/linux/drivers/sound/hal2.c,v retrieving revision 1.3.2.5 diff -u -r1.3.2.5 hal2.c --- linux/drivers/sound/hal2.c 2002/02/15 02:14:40 1.3.2.5 +++ linux/drivers/sound/hal2.c 2002/03/04 12:33:53 @@ -691,32 +691,25 @@ DECLARE_WAITQUEUE(wait, current); hal2_codec_t *dac = &hal2->dac; int ret = 0; - signed long timeout = 1 + 1000 * H2_BUFFER_SIZE * 2 * dac->voices * + signed long timeout = 1000 * H2_BUFFER_SIZE * 2 * dac->voices * HZ / dac->sample_rate / 900; down(&dac->sem); - while (dac->tail->info.cnt > 0 && ret == 0) { + while (dac->pbus.pbus->pbdma_ctrl & HPC3_PDMACTRL_ISACT) { add_wait_queue(&dac->dma_wait, &wait); - set_current_state(TASK_INTERRUPTIBLE); + set_current_state(TASK_UNINTERRUPTIBLE); if (!schedule_timeout(timeout)) /* We may get bogus timeout when system is * heavily loaded */ if (dac->tail->info.cnt) { printk("HAL2: timeout...\n"); - ret = -ETIME; + hal2_stop_dac(hal2); + hal2_reset_dac_pointer(hal2); } - if (signal_pending(current)) - ret = -ERESTARTSYS; remove_wait_queue(&dac->dma_wait, &wait); } - /* Make sure that DMA is stopped */ - if (dac->pbus.pbus->pbdma_ctrl & HPC3_PDMACTRL_ISACT) { - hal2_stop_dac(hal2); - hal2_reset_dac_pointer(hal2); - } - up(&dac->sem); return ret; @@ -1108,7 +1101,7 @@ } else { do { /* ~10% longer */ - signed long timeout = 1 + 1000 * H2_BUFFER_SIZE * + signed long timeout = 1000 * H2_BUFFER_SIZE * 2 * adc->voices * HZ / adc->sample_rate / 900; DECLARE_WAITQUEUE(wait, current); ssize_t cnt = 0; @@ -1169,7 +1162,7 @@ } else { do { /* ~10% longer */ - signed long timeout = 1 + 1000 * H2_BUFFER_SIZE * + signed long timeout = 1000 * H2_BUFFER_SIZE * 2 * dac->voices * HZ / dac->sample_rate / 900; DECLARE_WAITQUEUE(wait, current); ssize_t cnt = 0; recording doesn't work and will not work until someone provide better documentation. btw, what is iec958 spdig? > 2. isdn: there is a siemens isac-s chip (BTW i didn't see the hscx > twin): is it supported now? it should be not to difficult to leverage > the ia32-isdn hisax (passive) isac driver _if_ the hpc3 delivers the > irq? what do you think about it? there is currenty no support. any documentation available? From owner-linux-mips@oss.sgi.com Tue Mar 5 06:11:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25EBqH25839 for linux-mips-outgoing; Tue, 5 Mar 2002 06:11:52 -0800 Received: from fenris.scrooge.dk (213.237.12.36.adsl.ynoe.worldonline.dk [213.237.12.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25EBo925836 for ; Tue, 5 Mar 2002 06:11:50 -0800 Received: from athlon-800 (athlon-pc [10.0.0.2]) by fenris.scrooge.dk (8.12.1/8.8.7) with ESMTP id g25DBvAT025850; Tue, 5 Mar 2002 14:11:57 +0100 From: "Soeren Laursen" To: nsauzede@yahoo.com Date: Tue, 5 Mar 2002 14:11:08 +0100 MIME-Version: 1.0 Subject: Re: device support on indy WS !? Reply-to: soeren.laursen@scrooge.dk CC: linux-mips@oss.sgi.com Message-ID: <3C84D1FC.2273.520DA2@localhost> In-reply-to: <20020305130111.99294.qmail@web13002.mail.yahoo.com> References: <3C84B611.5050103@cineca.it> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-linux-mips@oss.sgi.com Precedence: bulk http://www.linux-debian.de/howto/debian-mips-woody-install.html From owner-linux-mips@oss.sgi.com Tue Mar 5 06:51:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25Ep4t27148 for linux-mips-outgoing; Tue, 5 Mar 2002 06:51:04 -0800 Received: from arianna.cineca.it (dns.cineca.it [130.186.1.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25Eot927145 for ; Tue, 5 Mar 2002 06:50:55 -0800 Received: from cineca.it (andrea@nb-venturi.cineca.it [193.204.122.87]) by arianna.cineca.it (8.12.1/8.12.1/CINECA 5.0-MILTER) with ESMTP id g25DoStv008622; Tue, 5 Mar 2002 14:50:28 +0100 (MET) Message-ID: <3C84CD2A.6070901@cineca.it> Date: Tue, 05 Mar 2002 14:50:34 +0100 From: Andrea Venturi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Ladislav Michl CC: Andrea Venturi , linux-mips@oss.sgi.com Subject: Re: device support on indy WS !? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ladislav Michl wrote: > On Tue, 5 Mar 2002, Andrea Venturi wrote: > > [snip] > >>1. audio hal2: i saw in the cvs.sgi.com kernel the OSS hal2.* files; >>what about the guenther alsa0.9 port? is it finished? what about iec958 >>spdif support? >> > > I can't say anything about ALSA 0.9 port. I decided for OSS driver, > because I wanded to listen music and there was no driver. OSS is much > better documented interface than ALSA. .................. > > recording doesn't work and will not work until someone provide better > documentation. > > btw, what is iec958 spdig? > it's a digital audio interface, for some info, see here: http://www.epanorama.net/documents/audio/spdif.html in the indy there is a consumer mini-jack connector; you should be able to link a dolby surround digital amplifier or a dat or similar digital audio device.. see here: http://www.futuretech.vuurwerk.nl/i2sec3.html BTW, on the mainboard, i can see the cs-8411, and there is the 8411.pdf inside the audio.zip doc package > >>2. isdn: there is a siemens isac-s chip (BTW i didn't see the hscx >>twin): is it supported now? it should be not to difficult to leverage >>the ia32-isdn hisax (passive) isac driver _if_ the hpc3 delivers the >>irq? what do you think about it? >> > > there is currenty no support. any documentation available? > apart from the hpc3.ps on: ftp://oss.sgi.com/pub/linux/mips/doc/indy/ you should find the isac-s (peb2086) specs here: http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=13633&cat_oid=-9183 but i don't know if it's enough.. i mean, if we should know something more on the way the isac-s chip is linked thru the pbus to the hpc3 chip. bye andrea venturi From owner-linux-mips@oss.sgi.com Tue Mar 5 07:00:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25F0x727447 for linux-mips-outgoing; Tue, 5 Mar 2002 07:00:59 -0800 Received: from arianna.cineca.it (dns.cineca.it [130.186.1.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25F0r927437 for ; Tue, 5 Mar 2002 07:00:54 -0800 Received: from tin.it (andrea@nb-venturi.cineca.it [193.204.122.87]) by arianna.cineca.it (8.12.1/8.12.1/CINECA 5.0-MILTER) with ESMTP id g25E0dtv011112; Tue, 5 Mar 2002 15:00:39 +0100 (MET) Message-ID: <3C84CF8D.2050303@tin.it> Date: Tue, 05 Mar 2002 15:00:45 +0100 From: "Andrea Venturi (personale)" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: nsauzede@yahoo.com CC: linux-mips@oss.sgi.com Subject: Re: device support on indy WS !? References: <3C84B611.5050103@cineca.it> <3C84D1FC.2273.520DA2@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Soeren Laursen wrote: > http://www.linux-debian.de/howto/debian-mips-woody-install.html > > two things, i believe should be useful to add to this woody-install: 1- i had some problem with the tftp "port over 32768" issue to make tftpboot.img downloadable to my indy, so had to type this on my linux tftp server: echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range 2- fdisking my new 2GB scsi disk (the indy came with an unuseful 600MB disk, good only for irix..), i scratch my head against the "SGI disklabel" thing[*].. so remember to use the e(x)pert option in fdisk to find how to create a SGI-compatable partition scheme.. i just put up some notes about my beginnings on the indy here: http://marge.cineca.it/aventuri/public/indy.html bye [*] coming from just ia32-linux eXPerience, i was used to a PeCee mentality.. From owner-linux-mips@oss.sgi.com Tue Mar 5 07:13:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25FDLA27851 for linux-mips-outgoing; Tue, 5 Mar 2002 07:13:21 -0800 Received: from hlubocky.del.cz (hlubocky.del.cz [212.27.221.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25FDD927847 for ; Tue, 5 Mar 2002 07:13:14 -0800 Received: from ladis (helo=localhost) by hlubocky.del.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 16iFgM-0006oX-00; Tue, 05 Mar 2002 15:12:46 +0100 Date: Tue, 5 Mar 2002 15:12:46 +0100 (CET) From: Ladislav Michl To: Andrea Venturi cc: linux-mips@oss.sgi.com Subject: Re: device support on indy WS !? In-Reply-To: <3C84CD2A.6070901@cineca.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 5 Mar 2002, Andrea Venturi wrote: > it's a digital audio interface, for some info, see here: > > http://www.epanorama.net/documents/audio/spdif.html ah. it is known as AES in SGI world... > in the indy there is a consumer mini-jack connector; you should be able > to link a dolby surround digital amplifier or a dat or similar digital > audio device.. > > see here: > > http://www.futuretech.vuurwerk.nl/i2sec3.html > > BTW, on the mainboard, i can see the cs-8411, and there is the 8411.pdf > inside the audio.zip doc package basically, it should be easy to support it (but there is no support, because i have no such device and therefore don't need it). HAL2 binding to CS8411 is the same as to CS4216. HAL2 hides all hardware details of Crystal chips and provides you indirect PIO access. > >>2. isdn: there is a siemens isac-s chip (BTW i didn't see the hscx > >>twin): is it supported now? it should be not to difficult to leverage > >>the ia32-isdn hisax (passive) isac driver _if_ the hpc3 delivers the > >>irq? what do you think about it? > >> > > > > there is currenty no support. any documentation available? > > > > apart from the hpc3.ps on: > > ftp://oss.sgi.com/pub/linux/mips/doc/indy/ ISDN glue is connected to IOC chip, but implementation details are missing :-( see section 4.6 of ioc.ps > you should find the isac-s (peb2086) specs here: > http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=13633&cat_oid=-9183 > > but i don't know if it's enough.. i mean, if we should know something > more on the way the isac-s chip is linked thru the pbus to the hpc3 chip. that is exactly what i'm not able to figure out... ladis From owner-linux-mips@oss.sgi.com Tue Mar 5 07:14:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25FEVC27929 for linux-mips-outgoing; Tue, 5 Mar 2002 07:14:31 -0800 Received: from arianna.cineca.it (arianna.cineca.it [130.186.1.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25FES927926 for ; Tue, 5 Mar 2002 07:14:29 -0800 Received: from cineca.it (andrea@nb-venturi.cineca.it [193.204.122.87]) by arianna.cineca.it (8.12.1/8.12.1/CINECA 5.0-MILTER) with ESMTP id g25EEHtv014147 for ; Tue, 5 Mar 2002 15:14:17 +0100 (MET) Message-ID: <3C84D2BF.6030100@cineca.it> Date: Tue, 05 Mar 2002 15:14:23 +0100 From: Andrea Venturi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: boot different kernels on the indy ?! Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk i would like to compile and install a kernel from the cvs.sgi.com tree. i would like not to loose my previous one (the one i get from the woody install) as a failsafe option.. i don't understand well i can have multiple kernel booting on the indy.. i believe i should change, in PROM mode, some environment variables.. am i wrong? could someone point me to the right doc? bye andrea From owner-linux-mips@oss.sgi.com Tue Mar 5 12:29:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25KTo017019 for linux-mips-outgoing; Tue, 5 Mar 2002 12:29:50 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25KTn917016 for ; Tue, 5 Mar 2002 12:29:49 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g25JTWn4002206; Tue, 5 Mar 2002 11:29:32 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g25JTWpL002202; Tue, 5 Mar 2002 11:29:32 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 5 Mar 2002 11:29:32 -0800 (PST) From: James Simmons To: Andre.Messerschmidt@infineon.com cc: linux-mips@oss.sgi.com Subject: Re: Console problem In-Reply-To: <86048F07C015D311864100902760F1DD01B5E74B@dlfw003a.dus.infineon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I wrote my own console driver based on the ARC console driver (to keep it > simple). When I am booting my modified 2.4.3 kernel, I get an "unable to > open initial console" error (code: No such device). I have tracked it down > to the point where the kernel searches for a valid TTY device with major and > minor ID 4:64. > All devices that are present at this time are: 3:0-3:256 2:0-2:256 5:0 5:1. > Obviously there is no 4:64 device. Did you call register_console ? From owner-linux-mips@oss.sgi.com Tue Mar 5 12:55:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25KtTw18329 for linux-mips-outgoing; Tue, 5 Mar 2002 12:55:29 -0800 Received: from fenris.scrooge.dk (213.237.12.36.adsl.ynoe.worldonline.dk [213.237.12.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25KtL918307 for ; Tue, 5 Mar 2002 12:55:22 -0800 Received: from athlon-800 (athlon-pc [10.0.0.2]) by fenris.scrooge.dk (8.12.1/8.8.7) with ESMTP id g25JtSAT016316; Tue, 5 Mar 2002 20:55:28 +0100 From: "Soeren Laursen" To: nsauzede@yahoo.com Date: Tue, 5 Mar 2002 20:54:39 +0100 MIME-Version: 1.0 Subject: Re: device support on indy WS !? Reply-to: soeren.laursen@scrooge.dk CC: linux-mips@oss.sgi.com Message-ID: <3C85308F.32143.32967F@localhost> In-reply-to: <20020305132731.81589.qmail@web13006.mail.yahoo.com> References: <3C84D1FC.2273.520DA2@localhost> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > BTW, in this page, the author chose to install packages from the > internet, but I would rather prefer download all the install distro (is > there some big tarball containing every packages) in the afternoon, and > put it on some HD I can mount as nfs from some linux server ?? There are some root.tar.gz that I used in the "old days". Where they are now - no clue! > To conclude : do you know if it is possible to get the whole > debian-mips bin distro in one file ?? You should also be able to download the debian-mips packages and place it on you own ftp/http server. Soeren, From owner-linux-mips@oss.sgi.com Tue Mar 5 12:58:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25KwVW18442 for linux-mips-outgoing; Tue, 5 Mar 2002 12:58:31 -0800 Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25KwP918439 for ; Tue, 5 Mar 2002 12:58:25 -0800 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Tue, 05 Mar 2002 11:57:03 -0800 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA26956 for ; Tue, 5 Mar 2002 11:58:23 -0800 (PST) Received: from broadcom.com (kwalker@dt-sj3-158 [10.21.64.158]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with ESMTP id LAA29738 for ; Tue, 5 Mar 2002 11:58:23 -0800 (PST) Message-ID: <3C85235F.B59286EA@broadcom.com> Date: Tue, 05 Mar 2002 11:58:23 -0800 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: init_idle reaped before final call X-WSS-ID: 109BFC851680709-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk [cross-posted to linux-kernel in a separate mail (oops)] I'm working with a (approximately) 2.4.17 kernel from the mips-linux tree (oss.sgi.com). I'd like to propose removing the "__init" designation from init_idle in kernel/sched.c, since this is called from rest_init via cpu_idle. Notice that rest_init isn't in an init section, and explicitly mentions that it's avoiding a race with free_initmem. In my kernel (an SMP kernel running on a system with only 1 available CPU), cpu_idle isn't getting called until after free_initmem(). My CPU is MIPS, but it looks like x86 could experience the same problem. Kip Index: kernel/sched.c =================================================================== RCS file: /projects/bbp/cvsroot/systemsw/linux/src/kernel/kernel/sched.c,v retrieving revision 1.10 diff -u -r1.10 sched.c --- kernel/sched.c 2002/01/15 04:13:43 1.10 +++ kernel/sched.c 2002/03/05 19:40:14 @@ -1304,7 +1304,7 @@ extern unsigned long wait_init_idle; -void __init init_idle(void) +void init_idle(void) { struct schedule_data * sched_data; sched_data = &aligned_data[smp_processor_id()].schedule_data; From owner-linux-mips@oss.sgi.com Tue Mar 5 15:15:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25NFxQ20522 for linux-mips-outgoing; Tue, 5 Mar 2002 15:15:59 -0800 Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25NFt920518 for ; Tue, 5 Mar 2002 15:15:55 -0800 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Tue, 05 Mar 2002 14:15:33 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA16283; Tue, 5 Mar 2002 14:15:53 -0800 (PST) Received: from broadcom.com (kwalker@dt-sj3-158 [10.21.64.158]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with ESMTP id OAA20458; Tue, 5 Mar 2002 14:15:54 -0800 (PST) Message-ID: <3C854399.2BE48DF2@broadcom.com> Date: Tue, 05 Mar 2002 14:15:53 -0800 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Martin J. Bligh" cc: linux-kernel@vger.kernel.org, linux-mips@oss.sgi.com Subject: Re: init_idle reaped before final call References: <3C8522EA.2A00E880@broadcom.com> <292270000.1015365429@flay> X-WSS-ID: 109B9C0F2713232-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Martin J. Bligh" wrote: > > > I'm working with a (approximately) 2.4.17 kernel from the mips-linux > > tree (oss.sgi.com). > > > > I'd like to propose removing the "__init" designation from init_idle in > > kernel/sched.c, since this is called from rest_init via cpu_idle. > > Notice that rest_init isn't in an init section, and explicitly mentions > > that it's avoiding a race with free_initmem. In my kernel (an SMP > > kernel running on a system with only 1 available CPU), cpu_idle isn't > > getting called until after free_initmem(). > > > > My CPU is MIPS, but it looks like x86 could experience the same problem. > > I fixed something in this area for x86, looks like the same code path > for MIPS unless I'm misreading. > > smp_init spins waiting on wait_init_idle until every cpu has done > init_idle. rest_init() isn't called until smp_init returns, so I'm not sure > how you could hit this (possibly there's a minute window after init_idle > clears the bit, but before it returns?). This synchronization doesn't help: cpu0 (even in the multi-cpu case) calls init_idle twice -- once from smp_init (through smp_boot_cpus), and then again from cpu_idle. In my failing case (CONFIG_SMP=y, but only 1 cpu in the system) the second call, the one from cpu_idle, doesn't happen until long after the init kernel thread has been running and has freed the initmem. Maybe a better fix is to avoid this double calling of init_idle for the "master" CPU? From my reading the code, x86 seems to behave the same. Kip From owner-linux-mips@oss.sgi.com Tue Mar 5 16:34:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g260YIZ27744 for linux-mips-outgoing; Tue, 5 Mar 2002 16:34:18 -0800 Received: from ux3.sp.cs.cmu.edu (UX3.SP.CS.CMU.EDU [128.2.198.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g260YD927739 for ; Tue, 5 Mar 2002 16:34:13 -0800 Received: from GS256.SP.CS.CMU.EDU ([128.2.199.27]) by ux3.sp.cs.cmu.edu id aa23333; 5 Mar 2002 18:33 EST Subject: Re: init_idle reaped before final call From: Justin Carlson To: Kip Walker Cc: "Martin J. Bligh" , linux-kernel@vger.kernel.org, linux-mips@oss.sgi.com In-Reply-To: <3C854399.2BE48DF2@broadcom.com> References: <3C8522EA.2A00E880@broadcom.com> <292270000.1015365429@flay> <3C854399.2BE48DF2@broadcom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3TVi76KKpsSwqmdDCj49" X-Mailer: Evolution/1.0.2 Date: 05 Mar 2002 18:33:08 -0500 Message-Id: <1015371192.11989.30.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-3TVi76KKpsSwqmdDCj49 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-03-05 at 17:15, Kip Walker wrote: >=20 > Maybe a better fix is to avoid this double calling of init_idle for the > "master" CPU? From my reading the code, x86 seems to behave the same. >=20 Looks to me like the clean fix would be to call init_idle() from rest_init() before the init() thread is spawned, and remove it from cpu_idle(). It looks like a pretty straightforward race condition that no one else has happened to trigger in a bad way. I'm no scheduler pro, but I don't see any problems with calling init_idle() earlier. That fix assumes that bringup of non-primary cpus on other architectures call init_idle() explicitly before allowing smp_init() to return; this is true of mips, but I can't vouch for any other arch's. I'd submit a patch, but I'm sadly lacking in SMP machines for testing.=20 Anyone who wants to rectify that, I'm open to charity. :) -Justin --=-3TVi76KKpsSwqmdDCj49 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8hVW047Lg4cGgb74RAjL/AKCaC/5lAa3QQRZJFACqiKGP0YSRGQCfZHS+ 4ihj5Ye/eFN+1FC0rLo+g7Q= =fibh -----END PGP SIGNATURE----- --=-3TVi76KKpsSwqmdDCj49-- From owner-linux-mips@oss.sgi.com Tue Mar 5 19:35:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g263Zi303709 for linux-mips-outgoing; Tue, 5 Mar 2002 19:35:44 -0800 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g263Za903703 for ; Tue, 5 Mar 2002 19:35:37 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 20609845; Wed, 6 Mar 2002 03:35:35 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id A2BA9370C3; Wed, 6 Mar 2002 00:25:21 +0100 (CET) Date: Wed, 6 Mar 2002 00:25:21 +0100 From: Florian Lohoff To: Andrea Venturi Cc: linux-mips@oss.sgi.com Subject: Re: boot different kernels on the indy ?! Message-ID: <20020305232521.GA31908@paradigm.rfc822.org> References: <3C84D2BF.6030100@cineca.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <3C84D2BF.6030100@cineca.it> User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 05, 2002 at 03:14:23PM +0100, Andrea Venturi wrote: > i would like to compile and install a kernel from the cvs.sgi.com tree. >=20 > i would like not to loose my previous one (the one i get from the woody= =20 > install) as a failsafe option.. >=20 > i don't understand well i can have multiple kernel booting on the indy.. >=20 > i believe i should change, in PROM mode, some environment variables.. am= =20 > i wrong? >=20 > could someone point me to the right doc? There is no doc yet - We have been working on a bootloader which makes this easier=20 Currently you have to put the ecoff kernel image into the volume header. If you have a large enough volume header just compile your kernel and put the new one into the volume header under a different name. The tool to use is "dvhtool" Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8hVPhUaz2rXW+gJcRAteIAJ9C/afXK1VW76y89M3BWNK5h5HqAwCfZl8G wetSyzLR04Kbvq2HaaPOWTg= =pKxF -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-linux-mips@oss.sgi.com Tue Mar 5 22:30:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g266Uco06439 for linux-mips-outgoing; Tue, 5 Mar 2002 22:30:38 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g266UZ906431 for ; Tue, 5 Mar 2002 22:30:35 -0800 Received: from hlubocky.del.cz (hlubocky.del.cz [212.27.221.67]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA05002 for ; Tue, 5 Mar 2002 21:30:18 -0800 (PST) mail_from (ladislav.michl@hlubocky.del.cz) Received: from ladis (helo=localhost) by hlubocky.del.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 16iTus-0000iR-00; Wed, 06 Mar 2002 06:24:42 +0100 Date: Wed, 6 Mar 2002 06:24:41 +0100 (CET) From: Ladislav Michl To: a.venturi@cineca.it cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: boot different kernels on the indy ?! In-Reply-To: <20020305232521.GA31908@paradigm.rfc822.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 6 Mar 2002, Florian Lohoff wrote: > There is no doc yet - We have been working on a bootloader which makes > this easier > > Currently you have to put the ecoff kernel image into the volume header. > If you have a large enough volume header just compile your kernel > and put the new one into the volume header under a different name. > The tool to use is "dvhtool" boot loader is called arcboot and is well documented - arcboot(8) atleast unstable contains arcboot-0.3 package. ladis From owner-linux-mips@oss.sgi.com Wed Mar 6 02:44:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26AiLR12880 for linux-mips-outgoing; Wed, 6 Mar 2002 02:44:21 -0800 Received: from dea.linux-mips.net (a1as07-p103.stg.tli.de [195.252.188.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26AiB912877 for ; Wed, 6 Mar 2002 02:44:17 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g269hg911517; Wed, 6 Mar 2002 10:43:42 +0100 Date: Wed, 6 Mar 2002 10:43:42 +0100 From: Ralf Baechle To: Ladislav Michl Cc: Andrea Venturi , linux-mips@oss.sgi.com, Thomas Bogendoerfer Subject: Re: device support on indy WS !? Message-ID: <20020306104342.A11475@dea.linux-mips.net> References: <3C84CD2A.6070901@cineca.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ladislav.michl@hlubocky.del.cz on Tue, Mar 05, 2002 at 03:12:46PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Mar 05, 2002 at 03:12:46PM +0100, Ladislav Michl wrote: > > you should find the isac-s (peb2086) specs here: > > http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=13633&cat_oid=-9183 > > > > but i don't know if it's enough.. i mean, if we should know something > > more on the way the isac-s chip is linked thru the pbus to the hpc3 chip. > > that is exactly what i'm not able to figure out... Long time ago Thomas Bogendoerfer claimed to have ISDN working but he then became too busy and stopped working on MIPS stuff. Ralf From owner-linux-mips@oss.sgi.com Wed Mar 6 02:51:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26ApVj13038 for linux-mips-outgoing; Wed, 6 Mar 2002 02:51:31 -0800 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26ApQ913035 for ; Wed, 6 Mar 2002 02:51:26 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id A935784F; Wed, 6 Mar 2002 10:51:24 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id C485B370C4; Wed, 6 Mar 2002 10:47:57 +0100 (CET) Date: Wed, 6 Mar 2002 10:47:57 +0100 From: Florian Lohoff To: Ladislav Michl Cc: a.venturi@cineca.it, linux-mips@oss.sgi.com Subject: Re: boot different kernels on the indy ?! Message-ID: <20020306094757.GB3255@paradigm.rfc822.org> References: <20020305232521.GA31908@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2002 at 06:24:41AM +0100, Ladislav Michl wrote: >=20 > boot loader is called arcboot and is well documented - arcboot(8) > atleast unstable contains arcboot-0.3 package. >=20 Which means to switch from kernel-in-vh to arcboot :) Are there kernel images with ELF kernels already in the archive ? Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --rJwd6BRFiFCcLxzm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8heXNUaz2rXW+gJcRAiTjAJ0eBLG9BdTIkKa26ShKbNGjVMmhTQCfamOy Z4OcLwOeEzqWpY2OYQag56A= =m2N3 -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm-- From owner-linux-mips@oss.sgi.com Wed Mar 6 10:26:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26IQCB26559 for linux-mips-outgoing; Wed, 6 Mar 2002 10:26:12 -0800 Received: from mail.ivivity.com ([64.238.111.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26IQ8926556 for ; Wed, 6 Mar 2002 10:26:08 -0800 Received: from [192.168.1.161] (192.168.1.161 [192.168.1.161]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 107NP3GZ; Wed, 6 Mar 2002 12:26:07 -0500 Subject: Questions? From: Marc Karasek To: Linux MIPS Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 06 Mar 2002 12:25:11 -0500 Message-Id: <1015435541.3714.33.camel@MCK_Linux> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have some general questions for all: How many of you are involved with embedded linux development using a MIPS processor? What endianess have you chosen for your project and why? If you have not guessed it, I am involved with a MIPS/Linux embedded project and we are trying to determine if there are any pros or cons in one endianess over the other. -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com 678.990.1550 x238 678.990.1551 Fax *************************/ From owner-linux-mips@oss.sgi.com Wed Mar 6 11:21:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26JLQt27459 for linux-mips-outgoing; Wed, 6 Mar 2002 11:21:26 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26JLN927456 for ; Wed, 6 Mar 2002 11:21:23 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16ig2G-0002i1-00; Wed, 06 Mar 2002 12:21:08 -0600 Message-ID: <3C865DF6.FFBE3AB@cotw.com> Date: Wed, 06 Mar 2002 12:20:38 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Marc Karasek CC: Linux MIPS Subject: Re: Questions? References: <1015435541.3714.33.camel@MCK_Linux> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Marc Karasek wrote: > > How many of you are involved with embedded linux development using a > MIPS processor? > A fair number of us. Over a hundred easily. > What endianess have you chosen for your project and why? > You don't really want to start this holy war, do you? That aside, usually big endian is more useful in applications moving networking type traffic or a fair amount of graphics processing. Little endian is handy if you are porting applications from Windows or a lot of your software is written in little endian. That's my $.02. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Wed Mar 6 11:44:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26JiQ627919 for linux-mips-outgoing; Wed, 6 Mar 2002 11:44:26 -0800 Received: from mail.ivivity.com ([64.238.111.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26JiL927916 for ; Wed, 6 Mar 2002 11:44:21 -0800 Received: from [192.168.1.161] (192.168.1.161 [192.168.1.161]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 107NP32Q; Wed, 6 Mar 2002 13:44:20 -0500 Subject: Re: Questions? From: Marc Karasek To: sjhill@cotw.com Cc: Linux MIPS In-Reply-To: <3C865DF6.FFBE3AB@cotw.com> References: <1015435541.3714.33.camel@MCK_Linux> <3C865DF6.FFBE3AB@cotw.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 06 Mar 2002 13:43:25 -0500 Message-Id: <1015440234.19618.37.camel@MCK_Linux> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk No, I have been involved with too many sorties in the war already. I was just asking if there was any issues with one side or the other from a purely technical aspect. On Wed, 2002-03-06 at 13:20, Steven J. Hill wrote: > Marc Karasek wrote: > > > > How many of you are involved with embedded linux development using a > > MIPS processor? > > > A fair number of us. Over a hundred easily. > > > What endianess have you chosen for your project and why? > > > You don't really want to start this holy war, do you? That aside, > usually big endian is more useful in applications moving networking > type traffic or a fair amount of graphics processing. Little endian > is handy if you are porting applications from Windows or a lot of > your software is written in little endian. > > That's my $.02. > > -Steve > > -- > Steven J. Hill - Embedded SW Engineer -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com 678.990.1550 x238 678.990.1551 Fax *************************/ From owner-linux-mips@oss.sgi.com Wed Mar 6 11:56:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26JuLN28428 for linux-mips-outgoing; Wed, 6 Mar 2002 11:56:21 -0800 Received: from coplin09.mips.com ([80.63.7.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26JuE928424 for ; Wed, 6 Mar 2002 11:56:14 -0800 Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g26IspK06935; Wed, 6 Mar 2002 19:54:51 +0100 From: Hartvig Ekner Message-Id: <200203061854.g26IspK06935@coplin09.mips.com> Subject: Re: Questions? To: marc_karasek@ivivity.com (Marc Karasek) Date: Wed, 6 Mar 2002 19:54:51 +0100 (CET) Cc: sjhill@cotw.com, linux-mips@oss.sgi.com (Linux MIPS) In-Reply-To: <1015440234.19618.37.camel@MCK_Linux> from "Marc Karasek" at Mar 06, 2002 01:43:25 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk It also depends on which new drivers you expect to use and thus need to port from the x86 world. I can certainly tell you that we always start off with LE for driver porting, for obvious reasons (x86, PCI), and then go BE after that. /Hartvig Marc Karasek writes: > > No, I have been involved with too many sorties in the war already. I > was just asking if there was any issues with one side or the other from > a purely technical aspect. > > On Wed, 2002-03-06 at 13:20, Steven J. Hill wrote: > > Marc Karasek wrote: > > > > > > How many of you are involved with embedded linux development using a > > > MIPS processor? > > > > > A fair number of us. Over a hundred easily. > > > > > What endianess have you chosen for your project and why? > > > > > You don't really want to start this holy war, do you? That aside, > > usually big endian is more useful in applications moving networking > > type traffic or a fair amount of graphics processing. Little endian > > is handy if you are porting applications from Windows or a lot of > > your software is written in little endian. > > > > That's my $.02. > > > > -Steve > > > > -- > > Steven J. Hill - Embedded SW Engineer > -- > /************************* > Marc Karasek > Sr. Firmware Engineer > iVivity Inc. > marc_karasek@ivivity.com > 678.990.1550 x238 > 678.990.1551 Fax > *************************/ From owner-linux-mips@oss.sgi.com Wed Mar 6 12:12:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26KCSq28992 for linux-mips-outgoing; Wed, 6 Mar 2002 12:12:28 -0800 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26KCQ928989 for ; Wed, 6 Mar 2002 12:12:26 -0800 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id LAA30668; Wed, 6 Mar 2002 11:06:36 -0800 Message-Id: <200203061906.LAA30668@saturn.mikemac.com> To: Marc Karasek cc: Linux MIPS Subject: Re: Questions? In-Reply-To: Your message of "06 Mar 2002 12:25:11 EST." <1015435541.3714.33.camel@MCK_Linux> Date: Wed, 06 Mar 2002 11:06:36 -0800 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >Subject: Questions? >From: Marc Karasek >To: Linux MIPS >Date: 06 Mar 2002 12:25:11 -0500 >What endianess have you chosen for your project and why? LE. That's all the NEC VR41XX support so I had no choice. Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Wed Mar 6 12:27:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26KRIX29448 for linux-mips-outgoing; Wed, 6 Mar 2002 12:27:18 -0800 Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26KRC929444 for ; Wed, 6 Mar 2002 12:27:12 -0800 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id g26JR7u11327 for ; Wed, 6 Mar 2002 11:27:07 -0800 Received: from SJAINW2K (dhcp-pc-5-71.sanera.net [172.16.5.71]) by icarus.sanera.net (8.11.6/8.11.6) with SMTP id g26JR1D20190 for ; Wed, 6 Mar 2002 11:27:01 -0800 From: "Sanjay Jain" To: Subject: unhandled kernel unaligned access Date: Wed, 6 Mar 2002 11:26:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi all, I am running a kernel test program which makes following call. getpeername(s, tdat[testno].sockaddr,tdat[testno].salen)); In one particular case tdat[testno].salen is set to 1 which is a unaligned and invalid addr. It results in following oops. Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, line 373: $0 : 00000000 10000024 00000000 00000005 $4 : 10000d20 00000000 10000d20 00000001 $8 : ffffffff 8b179e98 801c6da0 00000003 $12: 00000000 00000002 8b179ecc 8f9875bc $16: 8b1954c0 00000001 10000d20 00000001 $20: 004014e0 10002e08 00000000 0000000d $24: 00000001 2ac2db50 $28: 8b178000 8b179e70 7fff7c70 801c6e2c epc : 00000000801c58d4 Status : 10009f03 Cause : 00800010 BadAddr: 0000000000000001Process getpeername01 (pid: 9673, stackpage=8b178000) Stack: 8b179ec8 8eedf5a0 8b1954c0 00000001 801c6e2c 801c6dc4 8022370c 8020c788 8b179ec8 8eedf5a0 00010060 8eedf5a0 00000005 801c5b08 802c2048 8023a65c 000001d7 00000400 8b179ec8 00000005 000001d7 8eeb7780 5b343731 5d00d538 8fd2cd80 ffffffea 8eeb7780 00000000 00000000 00000001 00000003 00000003 7fff7c58 00000002 801c69b8 00406950 00401190 00000001 7fff7d24 00406950 8b1954c0 ... Call Trace: [<801c6e2c>] [<801c6dc4>] [<8022370c>] [<8020c788>] [<801c5b08>] [< 8023a65c>] [<801c69b8>] [<8010dce8>] Code: 04600003 00402821 8ce20000 <00002821> 00403021 10a00004 00a01021 8fb f0010 03e00008 Is this the expected behavior if an unaligned address is passed in a system call? From owner-linux-mips@oss.sgi.com Wed Mar 6 12:38:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26Kc4X29866 for linux-mips-outgoing; Wed, 6 Mar 2002 12:38:04 -0800 Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Kbv929862 for ; Wed, 6 Mar 2002 12:37:57 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id LAA10148; Wed, 6 Mar 2002 11:37:42 -0800 (PST) Received: from richt.mips.com (richt [192.168.65.186]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA29556; Wed, 6 Mar 2002 11:37:44 -0800 (PST) Received: from mips.com (localhost [127.0.0.1]) by richt.mips.com (8.9.3/8.9.0) with ESMTP id LAA18469; Wed, 6 Mar 2002 11:37:44 -0800 (PST) Message-ID: <3C867007.FB94B0D@mips.com> Date: Wed, 06 Mar 2002 11:37:44 -0800 From: "Kevin D. Kissell" Organization: MIPS Technologies Inc. X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sanjay Jain CC: linux-mips@oss.sgi.com Subject: Re: unhandled kernel unaligned access References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Which sources are you using? Up until pretty recently, there was a bug in unaligned.c which could cause this. I don't know when it was fixed at SGI, but the fix is in the 2.4.19-pre2 sources at kernel.org. The problem was that the epc value in the exception context was being advanced to the next instruction prior to the invocation of search_exception_table(regs->cp0_epc). The 2.4.19-pre2 code solves the problem by re-ordering the operations and delaying the advancement of epc. My own quick-and-dirty hack was simply to use the unmutilated value which is also available to emulate_load_store_insn(), changing that one line to be "fixup = search_exception_table(pc)". That seems to work. Kevin K. Sanjay Jain wrote: > > hi all, > > I am running a kernel test program which makes following call. > > getpeername(s, tdat[testno].sockaddr,tdat[testno].salen)); > > In one particular case tdat[testno].salen is set to 1 which is a unaligned > and invalid addr. It results in following oops. > > Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, > line > 373: > $0 : 00000000 10000024 00000000 00000005 > $4 : 10000d20 00000000 10000d20 00000001 > $8 : ffffffff 8b179e98 801c6da0 00000003 > $12: 00000000 00000002 8b179ecc 8f9875bc > $16: 8b1954c0 00000001 10000d20 00000001 > $20: 004014e0 10002e08 00000000 0000000d > $24: 00000001 2ac2db50 > $28: 8b178000 8b179e70 7fff7c70 801c6e2c > epc : 00000000801c58d4 > Status : 10009f03 > Cause : 00800010 > > BadAddr: 0000000000000001Process getpeername01 (pid: 9673, > stackpage=8b178000) > Stack: 8b179ec8 8eedf5a0 8b1954c0 00000001 801c6e2c 801c6dc4 8022370c > 8020c788 > 8b179ec8 8eedf5a0 00010060 8eedf5a0 00000005 801c5b08 802c2048 > 8023a65c > 000001d7 00000400 8b179ec8 00000005 000001d7 8eeb7780 5b343731 > 5d00d538 > 8fd2cd80 ffffffea 8eeb7780 00000000 00000000 00000001 00000003 > 00000003 > 7fff7c58 00000002 801c69b8 00406950 00401190 00000001 7fff7d24 > 00406950 > 8b1954c0 ... > Call Trace: [<801c6e2c>] [<801c6dc4>] [<8022370c>] [<8020c788>] [<801c5b08>] > [< > 8023a65c>] > [<801c69b8>] [<8010dce8>] > > Code: 04600003 00402821 8ce20000 <00002821> 00403021 10a00004 00a01021 > 8fb > f0010 03e00008 > > Is this the expected behavior if an unaligned address is passed in a system > call? From owner-linux-mips@oss.sgi.com Wed Mar 6 12:44:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26Kiqs30188 for linux-mips-outgoing; Wed, 6 Mar 2002 12:44:52 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Kil930182 for ; Wed, 6 Mar 2002 12:44:47 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g26JijR04565; Wed, 6 Mar 2002 11:44:45 -0800 From: "Matthew Dharm" To: "Marc Karasek" , "Linux MIPS" Subject: RE: Questions? Date: Wed, 6 Mar 2002 11:44:45 -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: <1015435541.3714.33.camel@MCK_Linux> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk My company develops embedded MIPS systems, and Linux is one of our supported operating systems. We chose big-endian, mostly because it seemed the right choice given the state of the tree. Some customers have recompiled our code to run little-endian with little problem, tho. 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: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Marc Karasek > Sent: Wednesday, March 06, 2002 9:25 AM > To: Linux MIPS > Subject: Questions? > > > I have some general questions for all: > > How many of you are involved with embedded linux development using a > MIPS processor? > > What endianess have you chosen for your project and why? > > If you have not guessed it, I am involved with a MIPS/Linux embedded > project and we are trying to determine if there are any > pros or cons in > one endianess over the other. > > -- > /************************* > Marc Karasek > Sr. Firmware Engineer > iVivity Inc. > marc_karasek@ivivity.com > 678.990.1550 x238 > 678.990.1551 Fax > *************************/ > From owner-linux-mips@oss.sgi.com Wed Mar 6 13:31:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26LVau32428 for linux-mips-outgoing; Wed, 6 Mar 2002 13:31:36 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26LVR932411 for ; Wed, 6 Mar 2002 13:31:29 -0800 Received: from prefect (prefect.local [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id 55140590B2; Wed, 6 Mar 2002 15:27:59 -0500 (EST) Message-ID: <00f401c1c54e$16bef9a0$5601010a@prefect> From: "Bradley D. LaRonde" To: "Marc Karasek" , "Linux MIPS" References: <1015435541.3714.33.camel@MCK_Linux> Subject: Re: Questions? Date: Wed, 6 Mar 2002 15:32:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Marc Karasek" To: "Linux MIPS" Sent: Wednesday, March 06, 2002 12:25 PM Subject: Questions? > What endianess have you chosen for your project little > and why? 1. to match endianness with my x86 cross-dev build system 2. hardware quirks Regards, Brad From owner-linux-mips@oss.sgi.com Wed Mar 6 13:40:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26LeWm32733 for linux-mips-outgoing; Wed, 6 Mar 2002 13:40:32 -0800 Received: from mail.ivivity.com ([64.238.111.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26LeP932730 for ; Wed, 6 Mar 2002 13:40:25 -0800 Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NP3KT>; Wed, 6 Mar 2002 15:40:25 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2195BB2@ATLOPS> From: Marc Karasek To: "'Matthew Dharm'" , Linux MIPS Subject: RE: Questions? Date: Wed, 6 Mar 2002 15:40:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk What kernel/tools do you provide? -----Original Message----- From: Matthew Dharm [mailto:mdharm@momenco.com] Sent: Wednesday, March 06, 2002 2:45 PM To: Marc Karasek; Linux MIPS Subject: RE: Questions? My company develops embedded MIPS systems, and Linux is one of our supported operating systems. We chose big-endian, mostly because it seemed the right choice given the state of the tree. Some customers have recompiled our code to run little-endian with little problem, tho. 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: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Marc Karasek > Sent: Wednesday, March 06, 2002 9:25 AM > To: Linux MIPS > Subject: Questions? > > > I have some general questions for all: > > How many of you are involved with embedded linux development using a > MIPS processor? > > What endianess have you chosen for your project and why? > > If you have not guessed it, I am involved with a MIPS/Linux embedded > project and we are trying to determine if there are any > pros or cons in > one endianess over the other. > > -- > /************************* > Marc Karasek > Sr. Firmware Engineer > iVivity Inc. > marc_karasek@ivivity.com > 678.990.1550 x238 > 678.990.1551 Fax > *************************/ > From owner-linux-mips@oss.sgi.com Wed Mar 6 13:41:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26Lffk00343 for linux-mips-outgoing; Wed, 6 Mar 2002 13:41:41 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26LfW900329 for ; Wed, 6 Mar 2002 13:41:32 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g26KfVR04852; Wed, 6 Mar 2002 12:41:31 -0800 From: "Matthew Dharm" To: "Marc Karasek" , "Linux MIPS" Subject: RE: Questions? Date: Wed, 6 Mar 2002 12:41:31 -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: <25369470B6F0D41194820002B328BDD2195BB2@ATLOPS> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk We use kernel 2.4.17 right now (upgrade to 2.4.18 is planned), and we use the toolchain that H.J. Liu put together (and is located on oss.sgi.com). 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: Marc Karasek [mailto:marc_karasek@ivivity.com] > Sent: Wednesday, March 06, 2002 12:40 PM > To: 'Matthew Dharm'; Linux MIPS > Subject: RE: Questions? > > > What kernel/tools do you provide? > > -----Original Message----- > From: Matthew Dharm [mailto:mdharm@momenco.com] > Sent: Wednesday, March 06, 2002 2:45 PM > To: Marc Karasek; Linux MIPS > Subject: RE: Questions? > > > My company develops embedded MIPS systems, and Linux is one of our > supported operating systems. > > We chose big-endian, mostly because it seemed the right choice given > the state of the tree. Some customers have recompiled our > code to run > little-endian with little problem, tho. > > 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: owner-linux-mips@oss.sgi.com > > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Marc Karasek > > Sent: Wednesday, March 06, 2002 9:25 AM > > To: Linux MIPS > > Subject: Questions? > > > > > > I have some general questions for all: > > > > How many of you are involved with embedded linux > development using a > > MIPS processor? > > > > What endianess have you chosen for your project and why? > > > > If you have not guessed it, I am involved with a > MIPS/Linux embedded > > project and we are trying to determine if there are any > > pros or cons in > > one endianess over the other. > > > > -- > > /************************* > > Marc Karasek > > Sr. Firmware Engineer > > iVivity Inc. > > marc_karasek@ivivity.com > > 678.990.1550 x238 > > 678.990.1551 Fax > > *************************/ > > > From owner-linux-mips@oss.sgi.com Wed Mar 6 14:17:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MHKa01709 for linux-mips-outgoing; Wed, 6 Mar 2002 14:17:20 -0800 Received: from dea.linux-mips.net (a1as01-p11.stg.tli.de [195.252.185.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26MHG901705 for ; Wed, 6 Mar 2002 14:17:16 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g26LGm017260; Wed, 6 Mar 2002 22:16:48 +0100 Date: Wed, 6 Mar 2002 22:16:48 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Sanjay Jain , linux-mips@oss.sgi.com Subject: Re: unhandled kernel unaligned access Message-ID: <20020306221648.A17128@dea.linux-mips.net> References: <3C867007.FB94B0D@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C867007.FB94B0D@mips.com>; from kevink@mips.com on Wed, Mar 06, 2002 at 11:37:44AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Mar 06, 2002 at 11:37:44AM -0800, Kevin D. Kissell wrote: > Which sources are you using? Up until pretty recently, > there was a bug in unaligned.c which could cause this. > I don't know when it was fixed at SGI, but the fix > is in the 2.4.19-pre2 sources at kernel.org. 2.4.19-pre2 has most of the oss.sgi.com code as of about a week ago. Ralf From owner-linux-mips@oss.sgi.com Thu Mar 7 03:59:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27BxXD23189 for linux-mips-outgoing; Thu, 7 Mar 2002 03:59:33 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27BxT923185 for ; Thu, 7 Mar 2002 03:59:30 -0800 Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g27AxO208314; Thu, 7 Mar 2002 10:59:24 GMT Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id KAA21103; Thu, 7 Mar 2002 10:59:23 GMT Date: Thu, 7 Mar 2002 10:59:23 GMT Message-Id: <200203071059.KAA21103@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Marc Karasek Cc: Linux MIPS Subject: Re: Questions? In-Reply-To: <1015435541.3714.33.camel@MCK_Linux> References: <1015435541.3714.33.camel@MCK_Linux> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Marc Karasek (marc_karasek@ivivity.com) writes: > What endianess have you chosen for your project and why? The MIPS world is irredemiably split, and the pull between SGI (always big-endian, M68000 heritage and Sun compatibility) and Linux' tendency to see the x86 as the universe has left Linux/MIPS split too. As software tool and prototyping board supplier, we just know that everything we do has to work either way. If you can change that, it would be great! :-) -- Dominic Sweetman, Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Thu Mar 7 06:08:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27E8JI28449 for linux-mips-outgoing; Thu, 7 Mar 2002 06:08:19 -0800 Received: from dea.linux-mips.net (a1as01-p99.stg.tli.de [195.252.185.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27E88928445 for ; Thu, 7 Mar 2002 06:08:09 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g27D7sv02940; Thu, 7 Mar 2002 14:07:54 +0100 Date: Thu, 7 Mar 2002 14:07:54 +0100 From: Ralf Baechle To: Marc Karasek Cc: Linux MIPS Subject: Re: Questions? Message-ID: <20020307140754.A1817@dea.linux-mips.net> References: <1015435541.3714.33.camel@MCK_Linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1015435541.3714.33.camel@MCK_Linux>; from marc_karasek@ivivity.com on Wed, Mar 06, 2002 at 12:25:11PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Mar 06, 2002 at 12:25:11PM -0500, Marc Karasek wrote: > > How many of you are involved with embedded linux development using a > MIPS processor? > > What endianess have you chosen for your project and why? > > If you have not guessed it, I am involved with a MIPS/Linux embedded > project and we are trying to determine if there are any pros or cons in > one endianess over the other. The MIPS ABI only covers big endian systems - every "real" MIPS UNIX system is big endian. Everything else is a GNU extension. There is hardly any reason to choose a particular byteorder as usually endianess swapping takes so little CPU time that it isn't even meassurable but so I'm told there are exceptions. If portability of software you're going to write wrt. external data representation (disk or network) is of any importance then I suggest you use a system of the opposite endianess which trip problems much faster. Ralf From owner-linux-mips@oss.sgi.com Thu Mar 7 06:12:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27EC5q28612 for linux-mips-outgoing; Thu, 7 Mar 2002 06:12:05 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27EBw928609; Thu, 7 Mar 2002 06:11:58 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id OAA19271; Thu, 7 Mar 2002 14:11:50 +0100 (MET) Date: Thu, 7 Mar 2002 14:11:50 +0100 (MET) From: Geert Uytterhoeven To: Ralf Baechle cc: Marc Karasek , Linux MIPS Subject: Re: Questions? In-Reply-To: <20020307140754.A1817@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 7 Mar 2002, Ralf Baechle wrote: > On Wed, Mar 06, 2002 at 12:25:11PM -0500, Marc Karasek wrote: > > How many of you are involved with embedded linux development using a > > MIPS processor? > > > > What endianess have you chosen for your project and why? > > > > If you have not guessed it, I am involved with a MIPS/Linux embedded > > project and we are trying to determine if there are any pros or cons in > > one endianess over the other. > > The MIPS ABI only covers big endian systems - every "real" MIPS UNIX > system is big endian. Everything else is a GNU extension. There is > hardly any reason to choose a particular byteorder as usually endianess > swapping takes so little CPU time that it isn't even meassurable but so > I'm told there are exceptions. If portability of software you're > going to write wrt. external data representation (disk or network) is > of any importance then I suggest you use a system of the opposite > endianess which trip problems much faster. I really like the last part! ;-) BTW, you forgot to mention to go for a full 64-bit port, to trip even more problems faster :-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Thu Mar 7 06:18:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27EIQu28898 for linux-mips-outgoing; Thu, 7 Mar 2002 06:18:26 -0800 Received: from dea.linux-mips.net (a1as01-p99.stg.tli.de [195.252.185.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27EIM928893 for ; Thu, 7 Mar 2002 06:18:22 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g27DIBF03066; Thu, 7 Mar 2002 14:18:11 +0100 Date: Thu, 7 Mar 2002 14:18:11 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: Marc Karasek , Linux MIPS Subject: Re: Questions? Message-ID: <20020307141811.A3041@dea.linux-mips.net> References: <20020307140754.A1817@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from geert@linux-m68k.org on Thu, Mar 07, 2002 at 02:11:50PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Mar 07, 2002 at 02:11:50PM +0100, Geert Uytterhoeven wrote: > > The MIPS ABI only covers big endian systems - every "real" MIPS UNIX > > system is big endian. Everything else is a GNU extension. There is > > hardly any reason to choose a particular byteorder as usually endianess > > swapping takes so little CPU time that it isn't even meassurable but so > > I'm told there are exceptions. If portability of software you're > > going to write wrt. external data representation (disk or network) is > > of any importance then I suggest you use a system of the opposite > > endianess which trip problems much faster. > > I really like the last part! ;-) > > BTW, you forgot to mention to go for a full 64-bit port, to trip even more > problems faster :-) Fortunately in practice that hasn't been a minefield as big as you'd imagine. Ralf From owner-linux-mips@oss.sgi.com Thu Mar 7 06:28:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27ESdl29146 for linux-mips-outgoing; Thu, 7 Mar 2002 06:28:39 -0800 Received: from mail.e-linotype.com (mail.e-linotype.com [212.109.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27ESU929139 for ; Thu, 7 Mar 2002 06:28:31 -0800 Received: by mail.e-linotype.com (Postfix, from userid 501) id 2348A133676; Thu, 7 Mar 2002 14:28:23 +0100 (CET) Received: from www.fonts.de (www.fonts.de [212.109.160.102]) by mail.e-linotype.com (Postfix) with ESMTP id CF437133666 for ; Thu, 7 Mar 2002 14:28:22 +0100 (CET) Received: from mail.fonts.de (mail.fonts.de [193.103.125.252]) by www.fonts.de (Postfix) with ESMTP id 5EB26AC17D for ; Thu, 7 Mar 2002 14:28:20 +0100 (CET) Received: from bhopc40002 [10.53.102.114] by mail.fonts.de (SMTPD32-6.06) id AABD75280226; Thu, 07 Mar 2002 14:27:25 +0100 From: Jay Konrad To: linux-mips@oss.sgi.com Date: Thu, 07 Mar 2002 14:30:39 +0100 X-Priority: 3 (Normal) Reply-To: jkonrad@fonts.de Message-Id: Subject: Fwd: [e-users] software patents in Europe MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Mailer: Opera 6.01 build 1041 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I think this is serious! Yours Jay ------- Start of forwarded message ------- From: Grégoire Hubert To: enlightenment-users@lists.sourceforge.net Subject: Fwd: [e-users] software patents in Europe Date: 7.3.2002 11:36:38 Hello all, Excuse me for this spam but this is important that all the free software developpers know what is happening now. The European Commission proposes to legalise the granting of computer programs as such in Europe. This text disregards the opinions of most if not all respected software developpers and economists, instead relies on dogmatic statements about patents in general as well as some unsubstantiatable claims and even some outright lies, citing as its only source of information about the real world of software a study from BSA (anti-piracy alliance dominated by Microsoft and a few other US vendors) about the importance of copyright enforcement. Associations like Eurolinux and french governement do not agree with such text. European comission is apparently trying to understand (hope this is true) what is the free software/open source community and if this is a good thing to preserve free innovation rights in Europe. They put a questionnaire on line dedicated to developpers that are involved in free software/open source projects. Even if you are not European citizen, please help us. You will find questionnaire here : http://floss1.infonomics.nl/ Eurolinux : http://eurolinux.org/ I know this is not the right place to discuss about that but I do everything I can to help community. Thank you for attention, Greg. ----------------------------------------------------- "My religion is to live and to die without regrets" Milarepa Rinpoche. _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -------- End of forwarded message -------- From owner-linux-mips@oss.sgi.com Thu Mar 7 10:31:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27IVgR12221 for linux-mips-outgoing; Thu, 7 Mar 2002 10:31:42 -0800 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27IVd912218 for ; Thu, 7 Mar 2002 10:31:40 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 11:31:28 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B75EB@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: lockup Date: Thu, 7 Mar 2002 11:29:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have a userland application which runs at fairly high priority. If I run the application from either a terminal or telnet shell I can successfully kill it with ctrl-c. However, if I simply close the shell window (terminal or telnet) by clicking X button, the entire system locks up. If I go to another system and telnet into the locked box, I get that telnet is connected but no login prompt is ever displayed. Any ideas where I should begin looking, approaches to take, things to try?? Any helpful pointers appreciated. Keith Siders Toshiba America Consumer Products Advanced Television Technology Center From owner-linux-mips@oss.sgi.com Thu Mar 7 10:57:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27IvB212952 for linux-mips-outgoing; Thu, 7 Mar 2002 10:57:11 -0800 Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Iux912944; Thu, 7 Mar 2002 10:56:59 -0800 Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id JAA00578; Thu, 7 Mar 2002 09:56:58 -0800 (PST) (envelope-from rh@matriplex.com) Date: Thu, 7 Mar 2002 09:56:58 -0800 (PST) From: Richard Hodges To: Ralf Baechle cc: Linux MIPS Subject: Re: Questions? In-Reply-To: <20020307140754.A1817@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 7 Mar 2002, Ralf Baechle wrote: > The MIPS ABI only covers big endian systems - every "real" MIPS UNIX > system is big endian. Everything else is a GNU extension. There is > hardly any reason to choose a particular byteorder as usually endianess > swapping takes so little CPU time that it isn't even meassurable but so > I'm told there are exceptions. To me, byte swapping on MIPS actually seems rather expensive. The code for htonl (linux/byteorder/swab.h) ends up something like this: srl $5,$4,8 andi $5,$5,0xff00 srl $2,$4,24 andi $3,$4,0xff00 or $2,$2,$5 sll $3,$3,8 or $2,$2,$3 sll $4,$4,24 This may not be an issue if it is only needed a few times per packet, but my system must byte-swap (LE to BE) about 500KB (or 4mb) per second. Actually, I save a bit of work by combining the byte swapping with the memory move, just after copy_from_user, and looks something like: unsigned char a, b, c, d, *mptr; a = mptr[0]; b = mptr[1]; c = mptr[2]; d = mptr[3]; mptr[0] = d; mptr[1] = c; mptr[2] = b; mptr[3] = a; This method works, but it is still 8 instructions per word. Yuck! Does anyone know of a _decent_ way to handle this on MIPS? All the best, -Richard From owner-linux-mips@oss.sgi.com Thu Mar 7 12:21:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27KLvk15643 for linux-mips-outgoing; Thu, 7 Mar 2002 12:21:57 -0800 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27KLn915637 for ; Thu, 7 Mar 2002 12:21:49 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 13:21:43 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B75EC@ATVX> From: "Siders, Keith" To: Linux MIPS Subject: RE: Questions? Date: Thu, 7 Mar 2002 13:19:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk You can get that down to 5 instructions. You could either use a typecast, or for portability, use a union definition. For that matter you could even typecast *mptr as a pointer to the union and extract the data from the string however you choose. But it still takes 5 instructions, unless you're pulling the data into another buffer, in which case you're down to 4. Keith -> -----Original Message----- -> From: Richard Hodges [mailto:rh@matriplex.com] -> Sent: Thursday, March 07, 2002 11:57 AM -> To: Ralf Baechle -> Cc: Linux MIPS -> Subject: Re: Questions? -> -> -> On Thu, 7 Mar 2002, Ralf Baechle wrote: -> -> > The MIPS ABI only covers big endian systems - every "real" -> MIPS UNIX -> > system is big endian. Everything else is a GNU extension. -> There is -> > hardly any reason to choose a particular byteorder as -> usually endianess -> > swapping takes so little CPU time that it isn't even -> meassurable but so -> > I'm told there are exceptions. -> -> To me, byte swapping on MIPS actually seems rather -> expensive. The code -> for htonl (linux/byteorder/swab.h) ends up something like this: -> -> srl $5,$4,8 -> andi $5,$5,0xff00 -> srl $2,$4,24 -> andi $3,$4,0xff00 -> or $2,$2,$5 -> sll $3,$3,8 -> or $2,$2,$3 -> sll $4,$4,24 -> -> This may not be an issue if it is only needed a few times -> per packet, but -> my system must byte-swap (LE to BE) about 500KB (or 4mb) per second. -> Actually, I save a bit of work by combining the byte -> swapping with the -> memory move, just after copy_from_user, and looks something like: -> -> unsigned char a, b, c, d, *mptr; -> a = mptr[0]; -> b = mptr[1]; -> c = mptr[2]; -> d = mptr[3]; -> mptr[0] = d; -> mptr[1] = c; -> mptr[2] = b; -> mptr[3] = a; -> -> This method works, but it is still 8 instructions per word. -> Yuck! Does -> anyone know of a _decent_ way to handle this on MIPS? -> -> All the best, -> -> -Richard -> From owner-linux-mips@oss.sgi.com Thu Mar 7 12:59:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Kxv016994 for linux-mips-outgoing; Thu, 7 Mar 2002 12:59:57 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Kxo916989 for ; Thu, 7 Mar 2002 12:59:51 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id A6318A0F1; Thu, 7 Mar 2002 20:59:48 +0100 (CET) Date: Thu, 7 Mar 2002 20:59:48 +0100 From: Jan-Benedict Glaw To: Linux MIPS Subject: Warning: persistent break condition on serial port 0. Message-ID: <20020307195948.GE25044@lug-owl.de> Mail-Followup-To: Linux MIPS Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lCAWRPmW1mITcIfM" Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --lCAWRPmW1mITcIfM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I've got an Indy R4k6 some time ago (I managed to run Linux on it using nfsroot) and now I attempted to really install it. However, I've now got some problem with the serial port: I can read the boot-up messages, but I cannot intercept the bootstrap (as I could do it some weeks ago): Running power-on diagnostics... Warning: persistent break condition on serial port 0. Warning: persistent break condition on serial port 0. Starting up the system... To perform system maintenance instead, press So I get warnings about a "persistent break condition", but that's not caused by the cable I use (I've used it weeks ago and it worked). Did I manage to kill the serial port? Any other hint on this? MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --lCAWRPmW1mITcIfM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyHxrMACgkQHb1edYOZ4bsVqACghPUT08Y0kIQsWm/ABdxjfTXk wFoAn1AGepIBBR35U1y4cwLrteMaX/zA =pp2f -----END PGP SIGNATURE----- --lCAWRPmW1mITcIfM-- From owner-linux-mips@oss.sgi.com Thu Mar 7 13:40:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27LeRB18474 for linux-mips-outgoing; Thu, 7 Mar 2002 13:40:27 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27LeM918471 for ; Thu, 7 Mar 2002 13:40:22 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id AF2D0A15D; Thu, 7 Mar 2002 21:40:20 +0100 (CET) Date: Thu, 7 Mar 2002 21:40:20 +0100 From: Jan-Benedict Glaw To: Linux MIPS Subject: Re: Warning: persistent break condition on serial port 0. Message-ID: <20020307204020.GF25044@lug-owl.de> Mail-Followup-To: Linux MIPS References: <20020307195948.GE25044@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FFoLq8A0u+X9iRU8" Content-Disposition: inline In-Reply-To: <20020307195948.GE25044@lug-owl.de> User-Agent: Mutt/1.3.27i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --FFoLq8A0u+X9iRU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2002-03-07 20:59:48 +0100, Jan-Benedict Glaw wrote in message <20020307195948.GE25044@lug-owl.de>: > Running power-on diagnostics... > Warning: persistent break condition on serial port 0. > Warning: persistent break condition on serial port 0. > Starting up the system... > To perform system maintenance instead, press I've now modified the cable: it's only signal ground and the receiving wire, so I really can only receive the Indy's messages. I cannot send anything anymore, but I still get those messages. I think this means that the box is now a paperweight: no way to access it, because I cannot even set console to ttyS1... MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --FFoLq8A0u+X9iRU8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyH0DMACgkQHb1edYOZ4bs30QCeJ0OGqbeOhP/ps+V6BNDFw8NT F3cAn2YBsQ9LgjP1fxHp4r0PUtg7DB0M =3TS9 -----END PGP SIGNATURE----- --FFoLq8A0u+X9iRU8-- From owner-linux-mips@oss.sgi.com Thu Mar 7 14:00:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27M0Q019168 for linux-mips-outgoing; Thu, 7 Mar 2002 14:00:26 -0800 Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27M0L919163 for ; Thu, 7 Mar 2002 14:00:21 -0800 Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id NAA01186; Thu, 7 Mar 2002 13:00:17 -0800 (PST) (envelope-from rh@matriplex.com) Date: Thu, 7 Mar 2002 13:00:17 -0800 (PST) From: Richard Hodges To: "Siders, Keith" cc: Linux MIPS Subject: RE: Questions? In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA1B75EC@ATVX> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 7 Mar 2002, Siders, Keith wrote: > You can get that down to 5 instructions. You could either use a typecast, or > for portability, use a union definition. For that matter you could even > typecast *mptr as a pointer to the union and extract the data from the > string however you choose. But it still takes 5 instructions, unless you're > pulling the data into another buffer, in which case you're down to 4. Which 5 instructions are those? For htonl from memory, the only sequence I can think of is the "obvious" one of lbu/shift (7 instructions). And for swapping BE-LE in memory (an important thing for me), I do not see any method better than the "obvious" one I mentioned earlier: 90c50000 lbu a1,0(a2) 90c40001 lbu a0,1(a2) 90c30002 lbu v1,2(a2) 90c20003 lbu v0,3(a2) a0c20000 sb v0,0(a2) a0c30001 sb v1,1(a2) a0c40002 sb a0,2(a2) a0c50003 sb a1,3(a2) Thanks, -Richard > -> From: Richard Hodges [mailto:rh@matriplex.com] > -> To me, byte swapping on MIPS actually seems rather > -> expensive. The code > -> for htonl (linux/byteorder/swab.h) ends up something like this: > -> > -> srl $5,$4,8 > -> andi $5,$5,0xff00 > -> srl $2,$4,24 > -> andi $3,$4,0xff00 > -> or $2,$2,$5 > -> sll $3,$3,8 > -> or $2,$2,$3 > -> sll $4,$4,24 From owner-linux-mips@oss.sgi.com Thu Mar 7 14:06:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27M6He19529 for linux-mips-outgoing; Thu, 7 Mar 2002 14:06:17 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27M6B919523 for ; Thu, 7 Mar 2002 14:06:11 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id AB7A89F6C; Thu, 7 Mar 2002 22:06:09 +0100 (CET) Date: Thu, 7 Mar 2002 22:06:09 +0100 From: Jan-Benedict Glaw To: Linux MIPS Subject: Re: Warning: persistent break condition on serial port 0. Message-ID: <20020307210609.GG25044@lug-owl.de> Mail-Followup-To: Linux MIPS References: <20020307195948.GE25044@lug-owl.de> <20020307204020.GF25044@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0QFb0wBpEddLcDHQ" Content-Disposition: inline In-Reply-To: <20020307204020.GF25044@lug-owl.de> User-Agent: Mutt/1.3.27i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --0QFb0wBpEddLcDHQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2002-03-07 21:40:20 +0100, Jan-Benedict Glaw wrote in message <20020307204020.GF25044@lug-owl.de>: > On Thu, 2002-03-07 20:59:48 +0100, Jan-Benedict Glaw > wrote in message <20020307195948.GE25044@lug-owl.de>: > > Running power-on diagnostics... > > Warning: persistent break condition on serial port 0. > > Warning: persistent break condition on serial port 0. > > Starting up the system... > > To perform system maintenance instead, press >=20 > I've now modified the cable: it's only signal ground and the receiving > wire, so I really can only receive the Indy's messages. I cannot > send anything anymore, but I still get those messages. I think this > means that the box is now a paperweight: no way to access it, because > I cannot even set console to ttyS1... Things are getting better: I am root on that machine through a telnet login (Irix 6.2 is running). Is there a way to set the console device to ttyd1? Maybe that could work... MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --0QFb0wBpEddLcDHQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyH1kAACgkQHb1edYOZ4bt0yACeILFRTEZiwizs5kc+BsEHZWEq M6oAn2hIC8TurD0m07vDbE9vmoXitpRp =9L5Q -----END PGP SIGNATURE----- --0QFb0wBpEddLcDHQ-- From owner-linux-mips@oss.sgi.com Thu Mar 7 14:47:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Ml3321252 for linux-mips-outgoing; Thu, 7 Mar 2002 14:47:03 -0800 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Mkp921248 for ; Thu, 7 Mar 2002 14:46:51 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 15:46:44 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B75EE@ATVX> From: "Siders, Keith" To: "'Richard Hodges'" Cc: Linux MIPS Subject: RE: Questions? Date: Thu, 7 Mar 2002 15:44:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hmm, assembly or C? Your original message had examples in both. In C the large part is the definitions in the union. If you define struct le_bitfield { unsigned long low:8; unsigned long lmid:8; unsigned long hmid:8; unsigned long high:8; }; struct be_bitfield { unsigned long high:8; unsigned long hmid:8; unsigned long lmid:8; unsigned long low:8; }; union byte_swap { unsigned long original; struct le_bitfield le; struct be_bitfield be; }swapper; Now you can use your previous char pointer swapper.original = *((unsigned long *)mptr); mptr[0] = swapper.le.low; mptr[1] = swapper.le.lmid; mptr[2] = swapper.le.hmid; mptr[3] = swapper.le.high; 5 instructions in C. To swap the other way, just use swapper.be.xxxx. If this still translates to 8 assembly instructions (or worse), oh well... just trying to help. ;) -> -----Original Message----- -> From: Richard Hodges [mailto:rh@matriplex.com] -> Sent: Thursday, March 07, 2002 3:00 PM -> To: Siders, Keith -> Cc: Linux MIPS -> Subject: RE: Questions? -> -> -> On Thu, 7 Mar 2002, Siders, Keith wrote: -> -> > You can get that down to 5 instructions. You could either -> use a typecast, or -> > for portability, use a union definition. For that matter -> you could even -> > typecast *mptr as a pointer to the union and extract the -> data from the -> > string however you choose. But it still takes 5 -> instructions, unless you're -> > pulling the data into another buffer, in which case you're -> down to 4. -> -> Which 5 instructions are those? For htonl from memory, the -> only sequence -> I can think of is the "obvious" one of lbu/shift (7 -> instructions). And -> for swapping BE-LE in memory (an important thing for me), I -> do not see any -> method better than the "obvious" one I mentioned earlier: -> -> 90c50000 lbu a1,0(a2) -> 90c40001 lbu a0,1(a2) -> 90c30002 lbu v1,2(a2) -> 90c20003 lbu v0,3(a2) -> a0c20000 sb v0,0(a2) -> a0c30001 sb v1,1(a2) -> a0c40002 sb a0,2(a2) -> a0c50003 sb a1,3(a2) -> -> Thanks, -> -> -Richard -> -> > -> From: Richard Hodges [mailto:rh@matriplex.com] -> -> > -> To me, byte swapping on MIPS actually seems rather -> > -> expensive. The code -> > -> for htonl (linux/byteorder/swab.h) ends up something like this: -> > -> -> > -> srl $5,$4,8 -> > -> andi $5,$5,0xff00 -> > -> srl $2,$4,24 -> > -> andi $3,$4,0xff00 -> > -> or $2,$2,$5 -> > -> sll $3,$3,8 -> > -> or $2,$2,$3 -> > -> sll $4,$4,24 -> -> From owner-linux-mips@oss.sgi.com Fri Mar 8 00:46:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g288kLd13126 for linux-mips-outgoing; Fri, 8 Mar 2002 00:46:21 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g288kJ913123 for ; Fri, 8 Mar 2002 00:46:19 -0800 Received: from gda-server ([202.88.152.146]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA09575 for ; Thu, 7 Mar 2002 23:46:20 -0800 (PST) mail_from (ps.santhosh@gdatech.co.in) Received: from [192.168.0.186] by gda-server (ArGoSoft Mail Server, Version 1.5 (1.5.0.8)); Fri, 8 Mar 2002 13:07:34 Message-ID: <3C8911D0.49ABC832@gdatech.co.in> Date: Sat, 09 Mar 2002 01:02:32 +0530 From: santhosh <ps.santhosh@gdatech.co.in> Organization: gdatech X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: ISP2300- Qlogic-MIPS-Driver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hai I want to add a driver "Qlogic ISP2300 " in one MIPS Board(BCM1250,Broadcom) shall I get it ?? I downloaded from Qlogic web site but it is not suite for MIPS.. what shall I do?? with regards santhosh From owner-linux-mips@oss.sgi.com Fri Mar 8 02:59:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28AxKT22791 for linux-mips-outgoing; Fri, 8 Mar 2002 02:59:20 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28Ax8922779; Fri, 8 Mar 2002 02:59:09 -0800 Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g289wp211314; Fri, 8 Mar 2002 09:58:51 GMT Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id JAA27320; Fri, 8 Mar 2002 09:58:47 GMT Date: Fri, 8 Mar 2002 09:58:47 GMT Message-Id: <200203080958.JAA27320@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ralf Baechle Cc: Marc Karasek , Linux MIPS Subject: Re: Questions? In-Reply-To: <20020307140754.A1817@dea.linux-mips.net> References: <1015435541.3714.33.camel@MCK_Linux> <20020307140754.A1817@dea.linux-mips.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle (ralf@oss.sgi.com) writes: > The MIPS ABI only covers big endian systems - every "real" MIPS UNIX > system is big endian. Except Decstations. And Sony NeWS (remember that one). And anything running on those NEC Vr41xx systems which were designed for WinCE and don't run big-endian at all. There never was a consensus... Mapping the MIPS ABI to little-endian presents no problems, as far as I know: obviously since it's a binary compatibility standard it has to make a choice... > There is hardly any reason to choose a particular byteorder as > usually endianess swapping takes so little CPU time that it isn't > even meassurable but so I'm told there are exceptions. I think it's often done for software-portability reasons; sometimes because some hardware works both ways but has some irritating flaw in its less-favoured organisation. System software (kernels, libraries) tends to work both ways, because it's written by people who thought about it. Huge applications which have only ever run on x86 and friends often don't work. Finding the problems faster is a counsel of perfection: in practice, a lot of us just want something that works, tomorrow. Swapping probably is an unmeasurable load: even if it takes 8-10 instructions per word on a 500MHz CPU that's 200Mbytes/s. But it is ugly, particularly when it's required to restore correct byte sequence because of a naive hardware interface (one, for example, which connects the MIPS CPU data lines to the same-numbered PCI ones...) So there are arguments on both sides, and players in both camps. I believe it's too late to corral all MIPS/Linux activity into one endianness or the other. Embrace bi-endianness! -- Dominic Sweetman, Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Fri Mar 8 08:16:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28GG5600861 for linux-mips-outgoing; Fri, 8 Mar 2002 08:16:05 -0800 Received: from dtwse201.detewe.de ([195.50.171.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28GFw900858 for ; Fri, 8 Mar 2002 08:15:59 -0800 Received: from zinse043.detewe.de (unverified) by dtwse201.detewe.de (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 8 Mar 2002 16:13:35 +0100 Received: from detewe.de ([172.30.204.40]) by zinse043.detewe.de (Netscape Messaging Server 3.6) with ESMTP id AAA1443; Fri, 8 Mar 2002 16:12:48 +0100 Message-ID: <3C88D523.5BFE88AC@detewe.de> Date: Fri, 08 Mar 2002 16:13:39 +0100 From: Carsten Lange X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux MIPS CC: Robert =?iso-8859-1?Q?Fr=E4nkel?= , Carsten Lange Subject: Linux for TI-Chip Content-Type: multipart/mixed; boundary="------------3D671E59AD65DFD91A0D031F" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------3D671E59AD65DFD91A0D031F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I have a problem running linux on a TI-chip. The board and the linux is quite similar to the MIPS-Malta-Board / Malta Linux port. The chip sees physical RAM of 16 MB at 0x14000000. The kernel is loaded at address 0x14020000. The pagetable created is incredably large (about 7MB). In free_area_init_core() totalpages and realtotalpages are calculated. In our case totalpages is approx. 86000 and realtotalpages is 1400. But allocation for the table is done with totalpages, not with realtotalpages. How do I reduce the pagetable to its really needed size? Any hints, ideas or solutions ;-) are welcome Carsten --------------3D671E59AD65DFD91A0D031F Content-Type: text/x-vcard; charset=us-ascii; name="Carsten.Lange.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Carsten Lange Content-Disposition: attachment; filename="Carsten.Lange.vcf" begin:vcard n:Lange;Carsten tel;fax:+49 6104 4234 tel;work:+49 30 6104 4228 x-mozilla-html:FALSE url:http://www.detewe.de org:Cordless Technology A/S Berlin adr:;;Koepenicker Str. 180;10997 Berlin;;; version:2.1 email;internet:Carsten.Lange@detewe.de x-mozilla-cpt:;0 fn:Carsten Lange end:vcard --------------3D671E59AD65DFD91A0D031F-- From owner-linux-mips@oss.sgi.com Fri Mar 8 10:24:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28IOv104289 for linux-mips-outgoing; Fri, 8 Mar 2002 10:24:57 -0800 Received: from web13008.mail.yahoo.com (web13008.mail.yahoo.com [216.136.174.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28IOs904286 for ; Fri, 8 Mar 2002 10:24:55 -0800 Message-ID: <20020308172453.53229.qmail@web13008.mail.yahoo.com> Received: from [193.251.90.77] by web13008.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 18:24:53 CET Date: Fri, 8 Mar 2002 18:24:53 +0100 (CET) From: =?iso-8859-1?q?Nicolas=20Sauzede?= Reply-To: nsauzede@yahoo.com Subject: XL8 => XL24 To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Sorry this is not related to linux, but does anyone know if it's possible to (in hardware) modify an Indy shipped with XL8 graphics to XL24 ?? (I mean, does one just have to replace one chip by another) thanks, Nicolas Sauzede. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From owner-linux-mips@oss.sgi.com Fri Mar 8 11:20:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28JKP408183 for linux-mips-outgoing; Fri, 8 Mar 2002 11:20:25 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28JKN908179 for ; Fri, 8 Mar 2002 11:20:24 -0800 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA17078 for ; Fri, 8 Mar 2002 18:32:34 -0800 Subject: xfs From: Pete Popov To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 Mar 2002 10:22:07 -0800 Message-Id: <1015611727.12994.441.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I see on SGI's web site that XFS is supported only on x86 and IA64. Has anyone tried it on mips? Pete From owner-linux-mips@oss.sgi.com Fri Mar 8 11:42:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28JgIb08537 for linux-mips-outgoing; Fri, 8 Mar 2002 11:42:18 -0800 Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28JgE908533 for ; Fri, 8 Mar 2002 11:42:14 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g28Ig93o005239; Fri, 8 Mar 2002 19:42:10 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA21256; Fri, 8 Mar 2002 19:42:09 +0100 (CET) Date: Fri, 8 Mar 2002 19:42:09 +0100 (CET) From: Seth Mos To: Pete Popov cc: linux-mips Subject: Re: xfs In-Reply-To: <1015611727.12994.441.camel@zeus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On 8 Mar 2002, Pete Popov wrote: > I see on SGI's web site that XFS is supported only on x86 and IA64. Has > anyone tried it on mips? > > Pete > Not that I know off. People have allready tested XFS on Sparc sparc64 alpha PPC and S390. So far there is positive feedback about the sparc alpha PP and sparc64 ports. You will have to try it. AFAIK the SGI people don't test XFS on the mips boxes. The kernel source is mostly compatible with the newer compilers out there like 2.95.3 and u. I think you will need to merge the mips and XFS CVS tree and edit some arch specific files like the syscalls. If you also want to use ACLs make sure you have the latest xfsprogs tools. Cheers Seth From owner-linux-mips@oss.sgi.com Fri Mar 8 12:22:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28KMme10205 for linux-mips-outgoing; Fri, 8 Mar 2002 12:22:48 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28KMj910201 for ; Fri, 8 Mar 2002 12:22:45 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16jPwy-0005h9-00; Fri, 08 Mar 2002 14:22:44 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g28JMhS02073; Fri, 8 Mar 2002 14:22:43 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Pete Popov Cc: linux-mips Subject: Re: xfs From: "Martin K. Petersen" Organization: SunSITE Denmark Staff References: <1015611727.12994.441.camel@zeus> Date: 08 Mar 2002 14:22:43 -0500 In-Reply-To: <1015611727.12994.441.camel@zeus> Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> "Pete" == Pete Popov writes: Pete> I see on SGI's web site that XFS is supported only on x86 and Pete> IA64. Has anyone tried it on mips? We did some Linux/XFS testing on an Origin 2000 about a year ago. Don't think anyone has tried it since then. But it should Just Work. Let us know if it doesn't. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-mips@oss.sgi.com Fri Mar 8 17:07:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2917UE15166 for linux-mips-outgoing; Fri, 8 Mar 2002 17:07:30 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2917Q915161 for ; Fri, 8 Mar 2002 17:07:26 -0800 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id AAA25981; Sat, 9 Mar 2002 00:18:07 -0800 Subject: Re: xfs From: Pete Popov To: "Martin K. Petersen" Cc: linux-mips In-Reply-To: References: <1015611727.12994.441.camel@zeus> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 Mar 2002 16:07:48 -0800 Message-Id: <1015632468.6456.24.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2002-03-08 at 11:22, Martin K. Petersen wrote: > >>>>> "Pete" == Pete Popov writes: > > Pete> I see on SGI's web site that XFS is supported only on x86 and > Pete> IA64. Has anyone tried it on mips? > > We did some Linux/XFS testing on an Origin 2000 about a year ago. > Don't think anyone has tried it since then. > > But it should Just Work. Let us know if it doesn't. I took 1.0.2 patch and applied it against the latest linux_2_4 oss kernel. Actually, it's the latest oss plus additional patches I've sent to Ralf, but I think those are stable. The patch did not apply cleanly but the problems were easy to fix. I didn't port the additional x86 syscalls because they appear to be attribute/acl related only. I cross compiled the kernel with 2.95.3 based tools (I know the older toolchain is recommended but ...). xfsprogs I compiled natively with the same version tools. The kernel boots and I was able to create an XFS file system on one of the partitions. Mounting works. Unmounting consistently results in a crash, illegal access to location 0x00000018. It's probably easy to fix since it's 100% reproducible. Back to mounting the fs -- I ran bonnie++ on it. It ran for quite a while until it got to the "sequential" write test and then the kernel froze. If I get to play with it some more, I'll send you any useful info I might have. Pete From owner-linux-mips@oss.sgi.com Sat Mar 9 02:17:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29AHHF25471 for linux-mips-outgoing; Sat, 9 Mar 2002 02:17:17 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29AHC925465 for ; Sat, 9 Mar 2002 02:17:13 -0800 Received: (qmail 17999 invoked from network); 9 Mar 2002 09:17:09 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 9 Mar 2002 09:17:08 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 0349F3000B8; Sat, 9 Mar 2002 19:17:05 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id CBEFFBA; Sat, 9 Mar 2002 20:17:05 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Pete Popov Cc: linux-mips Subject: Re: xfs In-reply-to: Your message of "08 Mar 2002 10:22:07 -0800." <1015611727.12994.441.camel@zeus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Mar 2002 20:17:00 +1100 Message-ID: <7338.1015665420@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On 08 Mar 2002 10:22:07 -0800, Pete Popov wrote: >I see on SGI's web site that XFS is supported only on x86 and IA64. Has >anyone tried it on mips? Anybody wanting to port XFS to new architectures should start with ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18 I split the XFS patches up so people can pick and choose which components they use, it makes it easier to exclude code like kdb, kbuild 2.5 or ia64 from the port. Note the ia64 patch, you will need a MIPS equivalent. When you get it working, send us the changes from the split patches. From owner-linux-mips@oss.sgi.com Sat Mar 9 11:16:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29JGKB04530 for linux-mips-outgoing; Sat, 9 Mar 2002 11:16:20 -0800 Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29JGH904524 for ; Sat, 9 Mar 2002 11:16:17 -0800 Received: from localhost ([63.194.214.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSP00KR4XF4FY@mta7.pltn13.pbi.net> for linux-mips@oss.sgi.com; Sat, 09 Mar 2002 10:16:17 -0800 (PST) Date: Sat, 09 Mar 2002 10:12:42 -0800 From: Pete Popov Subject: Re: xfs In-reply-to: <7338.1015665420@ocs3.intra.ocs.com.au> To: Keith Owens Cc: linux-mips Message-id: <1015697562.1199.1.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution/1.0.2 Content-type: text/plain Content-transfer-encoding: 7bit References: <7338.1015665420@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, 2002-03-09 at 01:17, Keith Owens wrote: > On 08 Mar 2002 10:22:07 -0800, > Pete Popov wrote: > >I see on SGI's web site that XFS is supported only on x86 and IA64. Has > >anyone tried it on mips? > > Anybody wanting to port XFS to new architectures should start with > ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18 > I split the XFS patches up so people can pick and choose which > components they use, it makes it easier to exclude code like kdb, > kbuild 2.5 or ia64 from the port. Note the ia64 patch, you will need a > MIPS equivalent. Great, thank you. > When you get it working, send us the changes from the split patches. I will, if I get to work on it. Pete From owner-linux-mips@oss.sgi.com Sat Mar 9 13:55:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29LtnM07401 for linux-mips-outgoing; Sat, 9 Mar 2002 13:55:49 -0800 Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29Lso907332 for ; Sat, 9 Mar 2002 13:54:50 -0800 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020309205443.DTYB1214.rwcrmhc54.attbi.com@ocean.lucon.org>; Sat, 9 Mar 2002 20:54:43 +0000 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 7370C125C3; Sat, 9 Mar 2002 12:54:42 -0800 (PST) Received: by lucon.org (Postfix, from userid 1000) id D6BDFEBC2; Sat, 9 Mar 2002 12:54:34 -0800 (PST) Date: Sat, 9 Mar 2002 12:54:34 -0800 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.12.90.0.1 is released. Message-ID: <20020309125434.A9967@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is the beta release of binutils 2.12.90.0.1 for Linux, which is based on binutils 2002 0307 in CVS on sourecs.redhat.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.12.90.0.1 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.93.0.2: 1. Update from binutils 2002 0307. 2. Add the .preinit_array/.init_array/.fini_array support. 3. Fix eh_frame. 4. Turn on combreloc by default. 5. Enable gprof for Linux/mips. Changes from binutils 2.11.92.0.12.3: 1. Update from binutils 2002 0207. 2. Fix a weak symbol alpha linker bug for glibc. 3. More support for gcc 3.1. Changes from binutils 2.11.92.0.12: 1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object files. Changes from binutils 2.11.92.0.10: 1. Update from binutils 2001 1121. 2. Fix a linker symbol version bug for common symbols. 3. Update handling relocations against the discarded sections. You may need to apply the kernel patch enclosed here to your kernel source. If you still see things like drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit' in the final kernel link, that means you have compiled a driver into the kernel which has a reference to the symbol in a discarded section. Kernel 2.4.17 or above should work fine. 4. Support "-march=xxx -mipsN" for mips gas if they are compatible. Changes from binutils 2.11.92.0.7: 1. Update from binutils 2001 1021. 2. Fix the ELF/PPC linker. 3. Fix the ELF/cris linker. 4. Fix ELF strip. Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.12. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.12.90.0.1.tar.gz. Source code. 2. binutils-2.11.93.0.2-2.12.90.0.1.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.1-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.12.90.0.1.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 03/08/2002 From owner-linux-mips@oss.sgi.com Sat Mar 9 17:51:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A1pCh13072 for linux-mips-outgoing; Sat, 9 Mar 2002 17:51:12 -0800 Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A1p9913069 for ; Sat, 9 Mar 2002 17:51:10 -0800 Received: from girishvg (AUTH login) at g053040.ppp.asahi-net.or.jp (HELO nazneen) (girishvg@211.132.53.40) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Mar 2002 00:51:09 -0000 Message-ID: <001301c1c7cd$ef03a0a0$283584d3@gol.com> From: "Girish Gulawani" To: "MIPS/Linux List \(SGI\)" Subject: SMP : How can I tell if it worked? Date: Sun, 10 Mar 2002 09:53:00 +0900 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 hello. i have a board with dual LSI EZ4021. the kernel version 2.4.3 is configured as SMP & its running. what i'd like to know is, how to confirm? its just a simple system that is single user & a serial console. for such system where can i get FREE multithreaded application w/ source code? would you recommend any particular applications for benchmarking? many thanks in advance. girish. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Sat Mar 9 21:07:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A57ZL17345 for linux-mips-outgoing; Sat, 9 Mar 2002 21:07:35 -0800 Received: from portablue.intern.mind.be (NAT.office.mind.be [62.166.230.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A57U917339 for ; Sat, 9 Mar 2002 21:07:30 -0800 Received: by portablue.intern.mind.be (Postfix, from userid 505) id 8C9ABB2CEB; Sun, 10 Mar 2002 05:07:22 +0100 (CET) Date: Sun, 10 Mar 2002 05:07:20 +0100 To: linux-mips@oss.sgi.com, geert@linux-m68k.org, wim@sonycom.com, lionel@sonycom.com, thomasv@sonycom.com, Nico.DeRanter@sonycom.com, tea@sonycom.com, joel@sonycom.com, michiels@CoWare.com, gds@denayer.wenk.be, p2@mind.be Subject: DDB-5074 patch Message-ID: <20020310040720.GA4336@mind.be> Mail-Followup-To: p2@mind.be, linux-mips@oss.sgi.com, geert@linux-m68k.org, wim@sonycom.com, lionel@sonycom.com, thomasv@sonycom.com, Nico.DeRanter@sonycom.com, tea@sonycom.com, joel@sonycom.com, michiels@CoWare.com, gds@denayer.wenk.be Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Answer: 42 X-Operating-system: Debian GNU/Linux X-Message-Flag: Get yourself a real email client. http://www.mutt.org/ From: p2@mind.be (Peter De Schrijver) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Attached you will find a patch against the latest CVS kernel from oss.sgi.com to fix the support for the NEC DDB-5074 evaluation board. Onboard ethernet works now, as well as ps/2 keyboard support. PS/2 mouse support might work as well. I didn't try it yet. Matrox Millenium II framebuffer also works now. I didn't try other graphics boards, but it seems most of them need some magic to work which only the (IA32-only) firmware knows of. Changes since last version : + Changes ddb_sync into NOP. This at last makes the system stable under high IRQ load. + Some tweaks to the IRQ handler + Changed PCI BAR0 to 0, so main memory resides at address 0 in PCI address space. TODO : Add support for the NILE 4 watchdog timer Add MTD support Test other PCI cards (eg. SCSI or IDE cards) Find a way to use the NILE 4 UART Have Fun, Peter. From owner-linux-mips@oss.sgi.com Sat Mar 9 22:31:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A6VfP18982 for linux-mips-outgoing; Sat, 9 Mar 2002 22:31:41 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A6Vc918979 for ; Sat, 9 Mar 2002 22:31:38 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16jvve-0005Fd-00; Sat, 09 Mar 2002 23:31:30 -0600 Message-ID: <3C8AEF8F.21DB96B9@cotw.com> Date: Sat, 09 Mar 2002 23:30:55 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Pete Popov CC: linux-mips Subject: Re: xfs References: <1015611727.12994.441.camel@zeus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Pete Popov wrote: > > I see on SGI's web site that XFS is supported only on x86 and IA64. Has > anyone tried it on mips? > Oh most definitely. I've been using it on my NEC 5432 platform for almost a year now, little endian. Works great. I've compiled the Linux/MIPS 2.4.x kernel with toolchains based on latest binutils, gcc-3.0.x, gcc-3.1 and glibc-2.2.3 and glibc-2.2.5 combinations. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Sun Mar 10 04:16:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ACGZB25701 for linux-mips-outgoing; Sun, 10 Mar 2002 04:16:35 -0800 Received: from hlubocky.del.cz (hlubocky.del.cz [212.27.221.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ACGV925696 for ; Sun, 10 Mar 2002 04:16:32 -0800 Received: from ladis (helo=localhost) by hlubocky.del.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 16k1JL-0002KT-00; Sun, 10 Mar 2002 12:16:19 +0100 Date: Sun, 10 Mar 2002 12:16:19 +0100 (CET) From: Ladislav Michl To: =?iso-8859-1?q?Nicolas=20Sauzede?= cc: linux-mips@oss.sgi.com Subject: Re: XL8 => XL24 In-Reply-To: <20020308172453.53229.qmail@web13008.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 8 Mar 2002, Nicolas Sauzede wrote: > Sorry this is not related to linux, but does anyone know if it's > possible to (in hardware) modify an Indy shipped with XL8 graphics to > XL24 ?? Newport graphics is sloted GIO device, so it is easy to replace it. > (I mean, does one just have to replace one chip by another) one card by another... in fact 8bit version of newport differs only in amount of memory. printed circuit board is the same, so in theory adding memory should be all you have to do. (is anyone able to lend me 24bit version of Newport to do juxtaposition?) ladis From owner-linux-mips@oss.sgi.com Sun Mar 10 16:10:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2B0A9Y13194 for linux-mips-outgoing; Sun, 10 Mar 2002 16:10:09 -0800 Received: from surfers.oz.agile.tv (fw.oz.agile.tv [210.9.52.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2B0A2913190 for ; Sun, 10 Mar 2002 16:10:03 -0800 Received: from liamlaptop (surfers.oz.agile.tv [192.168.16.1]) by surfers.oz.agile.tv (8.11.6/8.11.2) with SMTP id g2AN8qE29918; Mon, 11 Mar 2002 09:08:52 +1000 Message-ID: <002301c1c887$e3815a50$0f1fa8c0@liamlaptop> Reply-To: "Liam Davies" From: "Liam Davies" To: "Pete Popov" , "Martin K. Petersen" Cc: "linux-mips" References: <1015611727.12994.441.camel@zeus> <1015632468.6456.24.camel@zeus> Subject: Re: xfs Date: Mon, 11 Mar 2002 09:04:09 +1000 Organization: AgileTV Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Pete, > > I took 1.0.2 patch and applied it against the latest linux_2_4 oss > kernel. I tried the same against 2.4.14, but had the same problems you described below. I then tried the split-only and split-kernel patches from the 2.4.14 XFS cvs snapshot, taken just before or after 1.0.2 release - no changes required. Everything seems to be working dandy. > > I cross compiled the kernel with 2.95.3 based tools (I know the older > toolchain is recommended but ...). xfsprogs I compiled natively with > the same version tools. I haven't tried any compilers earlier that gcc 3.0, but 3.0.1 and 3.0.3 have both worked for me. > The kernel boots and I was able to create an > XFS file system on one of the partitions. Mounting works. Unmounting > consistently results in a crash, illegal access to location 0x00000018. > It's probably easy to fix since it's 100% reproducible. Back to > mounting the fs -- I ran bonnie++ on it. It ran for quite a while until > it got to the "sequential" write test and then the kernel froze. I had both of these symptoms after applying the 1.0.2 patch in its entirety. After switching to split-kernel and split-only patches only these things went away. I didn't delve any deeper. Liam ------ Agile Tv From owner-linux-mips@oss.sgi.com Sun Mar 10 23:48:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2B7mJE23560 for linux-mips-outgoing; Sun, 10 Mar 2002 23:48:19 -0800 Received: from gda-server ([202.88.152.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2B7mB923556 for ; Sun, 10 Mar 2002 23:48:11 -0800 Received: from [192.168.0.186] by gda-server (ArGoSoft Mail Server, Version 1.5 (1.5.0.8)); Mon, 11 Mar 2002 12:20:28 Message-ID: <3C8CFB45.9E749117@gdatech.co.in> Date: Tue, 12 Mar 2002 00:15:25 +0530 From: santhosh <ps.santhosh@gdatech.co.in> Organization: gdatech X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, gmo , mhuang , mpl , jtardo , ttruong , kwalker , "nitin.borle" Subject: Linux-mips porting issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi All ... Subj: Linux-Porting issue Here I ported Linux -mips on BCM1250 board(Broadcom) had occurred some error which showed below CFE>Boot -z -elf 192.168.200.150:zimage andkishore_rane: Loader:elf Filesys:tftp Dev:eth0 File:192.168.200.150:zimage Optionsnull) Loading: 0x80100000/1342312 0x80248000/2297856 0x80479000/343232 Entry at 0x8010 047c *** command status = 0 nandkishore_rane: CFE> go Closing network. Starting program at 0x8010047c RUN! CPU revision is: 01040101 Linux version 2.4.17sb20020206 (root@gda_Santhosh) (gcc version 3.0.1 with SiByt e modifications) #1 SMP Fri Mar 8 11:26:50 IST 2002 This kernel optimized for board runs with CFE Determined physical RAM map: memory: 0026e000 @ 00000000 (usable) memory: 01987748 @ 004788b8 (usable) memory: 00000000 @ 01f04000 (usable) memory: 0020a8b8 @ 0026e000 (reserved) Initial ramdisk at: 0x8026e000 (2140344 bytes) On node 0 totalpages: 7680 zone(0): 7680 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram0 CPU revision is: 01040101 Linux version 2.4.17sb20020206 (root@gda_Santhosh) (gcc version 3.0.1 with SiByt e modifications) #1 SMP Fri Mar 8 11:26:50 IST 2002 Then hung ........... with regards santhosh From owner-linux-mips@oss.sgi.com Mon Mar 11 08:46:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BGkdj06275 for linux-mips-outgoing; Mon, 11 Mar 2002 08:46:39 -0800 Received: from ux3.sp.cs.cmu.edu (UX3.SP.CS.CMU.EDU [128.2.198.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BGkU906272 for ; Mon, 11 Mar 2002 08:46:31 -0800 Received: from GS256.SP.CS.CMU.EDU ([128.2.199.27]) by ux3.sp.cs.cmu.edu id aa11401; 11 Mar 2002 10:45 EST Subject: Re: Linux-mips porting issues From: Justin Carlson To: santhosh Cc: linux-mips@oss.sgi.com In-Reply-To: <3C8CFB45.9E749117@gdatech.co.in> References: <3C8CFB45.9E749117@gdatech.co.in> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mDyH/s9vLYj37utn03SB" X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 10:45:21 -0500 Message-Id: <1015861530.28663.38.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-mDyH/s9vLYj37utn03SB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-03-11 at 13:45, santhosh=03 wrote: >=20 > Hi All ... >=20 > Subj: Linux-Porting issue > Here I ported Linux -mips on BCM1250 board(Broadcom) had occurred > some error which showed below >=20 >=20 > CFE>Boot -z -elf 192.168.200.150:zimage > andkishore_rane: Loader:elf Filesys:tftp Dev:eth0 > File:192.168.200.150:zimage Optionsnull) > Loading: 0x80100000/1342312 0x80248000/2297856 0x80479000/343232 Entry > at 0x8010 > 047c You're trying to boot the kernel image directly from CFE? I hope you've embedded a ramdisk for your root filesystem...that or there must be some spiffy new features in CFE that weren't there last I looked at it. > Kernel command line: root=3D/dev/ram0 That looks good... Does it work fine with CONFIG_SMP=3Dn? Or have you not tried that? -Justin --=-mDyH/s9vLYj37utn03SB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8jNER47Lg4cGgb74RAk6FAKDDurYRGrseI03cEQNDQrMJykl3kQCcCE7J HamoH/PRVM2rdB3LjsBXKlg= =MlFF -----END PGP SIGNATURE----- --=-mDyH/s9vLYj37utn03SB-- From owner-linux-mips@oss.sgi.com Mon Mar 11 14:45:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BMju015077 for linux-mips-outgoing; Mon, 11 Mar 2002 14:45:56 -0800 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BMjr915074 for ; Mon, 11 Mar 2002 14:45:53 -0800 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 11 Mar 2002 21:49:44 UT Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.11.6/8.11.6) with SMTP id g2BLha515617 for ; Mon, 11 Mar 2002 13:43:36 -0800 (PST) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id NAA23491; Mon, 11 Mar 2002 13:45:09 -0800 Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id PAA24779; Mon, 11 Mar 2002 15:37:01 -0600 Message-ID: <3C8D26C8.2060903@esstech.com> Date: Mon, 11 Mar 2002 15:51:04 -0600 From: Gerald Champagne User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: pci config cycles on VRC-5477 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm studying the VRC-5477 code and I'm trying to understand how pci config cycles can work reliably with the current code. It looks like the pci config code must execute with interrupts disabled, but I can't find code that disables interrupts. Can someone offer a few pointers? Here's why I ask... All pci io, memory, and config accesses on the 5477 are performed through two windows in the cpu address space. Normally these two windows are configured to perform pci memory and io accesses, and any driver can access pci io and memory at any time. In order to perform a pci config access, one of the two windows must be remapped to perform pci config cycles. The code in read_config_dword() looks something like this: - Call ddb_access_config_base() to reconfigure the window into pci memory space to access pci config space instead. - Read from pci config space by reading from an offset into the window. - Call ddb_close_config_base to restore the registers to the original values. It looks like anything can interrupt this an try to perform a pci memory access while the window is programmed to perfom config cycles. Did I miss something, or is this a bug? Thanks. Gerald From owner-linux-mips@oss.sgi.com Mon Mar 11 15:29:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BNTMB16742 for linux-mips-outgoing; Mon, 11 Mar 2002 15:29:22 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BNTH916739 for ; Mon, 11 Mar 2002 15:29:17 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05703 for ; Mon, 11 Mar 2002 14:29:18 -0800 (PST) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id WAA05296; Mon, 11 Mar 2002 22:36:12 -0800 Message-ID: <3C8D2E89.10001@mvista.com> Date: Mon, 11 Mar 2002 14:24:09 -0800 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Gerald Champagne CC: linux-mips@oss.sgi.com Subject: Re: pci config cycles on VRC-5477 References: <3C8D26C8.2060903@esstech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Gerald Champagne wrote: > > I'm studying the VRC-5477 code and I'm trying to understand how pci config > cycles can work reliably with the current code. It looks like the pci > config code must execute with interrupts disabled, but I can't find code > that disables interrupts. Can someone offer a few pointers? Here's why > I ask... > > All pci io, memory, and config accesses on the 5477 are performed through > two windows in the cpu address space. Normally these two windows are > configured > to perform pci memory and io accesses, and any driver can access pci io and > memory at any time. In order to perform a pci config access, one of the > two > windows must be remapped to perform pci config cycles. The code in > read_config_dword() looks something like this: > > - Call ddb_access_config_base() to reconfigure the window into pci > memory space > to access pci config space instead. > > - Read from pci config space by reading from an offset into the window. > > - Call ddb_close_config_base to restore the registers to the original > values. > > It looks like anything can interrupt this an try to perform a pci memory > access while the window is programmed to perfom config cycles. > > Did I miss something, or is this a bug? > Your understanding is correct. I think this is a bug. Do you actually see the bug happening? So far it has never hit me, but maybe due to the drivers that are loaded on my configuration. Jun From owner-linux-mips@oss.sgi.com Mon Mar 11 15:40:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BNeQr16948 for linux-mips-outgoing; Mon, 11 Mar 2002 15:40:26 -0800 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BNeN916944 for ; Mon, 11 Mar 2002 15:40:23 -0800 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 11 Mar 2002 22:44:15 UT Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.11.6/8.11.6) with SMTP id g2BMc6516257; Mon, 11 Mar 2002 14:38:06 -0800 (PST) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id OAA23613; Mon, 11 Mar 2002 14:39:39 -0800 Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id QAA25162; Mon, 11 Mar 2002 16:31:30 -0600 Message-ID: <3C8D338E.6050805@esstech.com> Date: Mon, 11 Mar 2002 16:45:34 -0600 From: Gerald Champagne User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: pci config cycles on VRC-5477 References: <3C8D26C8.2060903@esstech.com> <3C8D2E89.10001@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Your understanding is correct. I think this is a bug. > > Do you actually see the bug happening? So far it has never hit me, but > maybe due to the drivers that are loaded on my configuration. > > Jun No, I don't actually see it. It's not a big window, and pci config cycles don't occur very often. I found it while learning the device. I checked the ddb5476 and ddb5074 dirctories, and it looks like they have the same problem. It's a shame that the devices have only two windows into pci space when having three windows would be much simpler... Thanks for the response. Gerald From owner-linux-mips@oss.sgi.com Mon Mar 11 19:33:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C3XXQ22082 for linux-mips-outgoing; Mon, 11 Mar 2002 19:33:33 -0800 Received: from i01sv4138.ids1.intelonline.com (i01sv4138-p.ids1.intelonline.com [147.208.166.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C3XU922077 for ; Mon, 11 Mar 2002 19:33:31 -0800 Received: from i01sv0637 (unverified [10.81.26.22]) by i01sv4138.ids1.intelonline.com (Rockliffe SMTPRA 4.5.4) with SMTP id for ; Tue, 12 Mar 2002 02:33:23 +0000 Message-ID: From: Guo-Rong Koh To: "linux-mips@oss.sgi.com" X-Originating-IP: [203.14.96.10] Date: Tue, 12 Mar 2002 12:33:22 +1030 X-MSMail-Priority: Normal X-mailer: AspMail 4.0 4.02 (SMT4DD4B4F) Subject: boot fails on decstation 5000/25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all, My cross-compiled kernel (latest off CVS), kernel panics when allocating root vfsmount. I've traced it back to the init_mount_tree call in fs/super.c where it fails the check for CAP_SYS_ADMIN capability. Anyone know of this problem? Personally it seems a bit weird, could it be related to the fact that I'm using the NetBSD boot loader?? Thanks in advance, Guo-Rong __________________________________________________________________ Get your free Australian email account at http://www.start.com.au From owner-linux-mips@oss.sgi.com Tue Mar 12 02:18:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CAI6g06339 for linux-mips-outgoing; Tue, 12 Mar 2002 02:18:06 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CAI0906336 for ; Tue, 12 Mar 2002 02:18:00 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA10928; Tue, 12 Mar 2002 10:17:39 +0100 (MET) Date: Tue, 12 Mar 2002 10:17:38 +0100 (MET) From: Geert Uytterhoeven To: Jun Sun cc: Gerald Champagne , Linux/MIPS Development Subject: Re: pci config cycles on VRC-5477 In-Reply-To: <3C8D2E89.10001@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 11 Mar 2002, Jun Sun wrote: > Gerald Champagne wrote: > > I'm studying the VRC-5477 code and I'm trying to understand how pci config > > cycles can work reliably with the current code. It looks like the pci > > config code must execute with interrupts disabled, but I can't find code > > that disables interrupts. Can someone offer a few pointers? Here's why > > I ask... > > > > All pci io, memory, and config accesses on the 5477 are performed through > > two windows in the cpu address space. Normally these two windows are > > configured > > to perform pci memory and io accesses, and any driver can access pci io and > > memory at any time. In order to perform a pci config access, one of the > > two > > windows must be remapped to perform pci config cycles. The code in > > read_config_dword() looks something like this: > > > > - Call ddb_access_config_base() to reconfigure the window into pci > > memory space > > to access pci config space instead. > > > > - Read from pci config space by reading from an offset into the window. > > > > - Call ddb_close_config_base to restore the registers to the original > > values. > > > > It looks like anything can interrupt this an try to perform a pci memory > > access while the window is programmed to perfom config cycles. > > > > Did I miss something, or is this a bug? > > Your understanding is correct. I think this is a bug. > > Do you actually see the bug happening? So far it has never hit me, but maybe > due to the drivers that are loaded on my configuration. (IIRC) When I wrote the Vrc-5074 support, I thought about this as well. But then I noticed that this was already done by the upper PCI layer. Is this still true? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Tue Mar 12 10:21:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CILxD15547 for linux-mips-outgoing; Tue, 12 Mar 2002 10:21:59 -0800 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CILs915544 for ; Tue, 12 Mar 2002 10:21:54 -0800 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 12 Mar 2002 17:25:46 UT Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.11.6/8.11.6) with SMTP id g2CHJU524860; Tue, 12 Mar 2002 09:19:30 -0800 (PST) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id JAA24507; Tue, 12 Mar 2002 09:21:03 -0800 Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id LAA29504; Tue, 12 Mar 2002 11:12:51 -0600 Message-ID: <3C8E3A5E.6020709@esstech.com> Date: Tue, 12 Mar 2002 11:26:54 -0600 From: Gerald Champagne User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Geert Uytterhoeven CC: Jun Sun , Linux/MIPS Development Subject: Re: pci config cycles on VRC-5477 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>> >>>Did I miss something, or is this a bug? >>> >>Your understanding is correct. I think this is a bug. >> >>Do you actually see the bug happening? So far it has never hit me, but maybe >>due to the drivers that are loaded on my configuration. >> > > (IIRC) When I wrote the Vrc-5074 support, I thought about this as well. > But then I noticed that this was already done by the upper PCI layer. Is this > still true? > > Gr{oetje,eeting}s, > > Geert You're right. It's not a problem. The code that disables interrupts right here in drivers/pci/pci.c: #define PCI_OP(rw,size,type) \ int pci_##rw##_config_##size (struct pci_dev *dev, int pos, type value) \ { \ int res; \ unsigned long flags; \ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \ spin_lock_irqsave(&pci_lock, flags); \ res = dev->bus->ops->rw##_##size(dev, pos, value); \ spin_unlock_irqrestore(&pci_lock, flags); \ return res; \ } I don't know why I missed that... Thanks for the reply! Gerald From owner-linux-mips@oss.sgi.com Tue Mar 12 12:23:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CKNFh23875 for linux-mips-outgoing; Tue, 12 Mar 2002 12:23:15 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CKNC923872 for ; Tue, 12 Mar 2002 12:23:12 -0800 Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g2CJLlr18832 for ; Tue, 12 Mar 2002 14:21:47 -0500 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g2CJNBm15710 for ; Tue, 12 Mar 2002 14:23:11 -0500 Received: from redhat.com (dhcp-166.hsv.redhat.com [172.16.17.166]) by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id g2CJNEN05317 for ; Tue, 12 Mar 2002 13:23:14 -0600 Message-ID: <3C8E5560.2090907@redhat.com> Date: Tue, 12 Mar 2002 13:22:08 -0600 From: Lanny DeVaney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: gdbserver Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I've looked back through the archives and find some references to problems configuring and/or building gdbserver for mips-linux. I'm attempting to build gdb/gdbserver with --target=mips-linux as well, using gdb-5.1.1. Have the earlier issues (they looked to be 1-2 years old) been resolved or am I still looking at a "manual build" process? I'm getting lots of errors with the build, although the configure seems to go OK. x86 host, linux-mips target. Thanks for any help you can provide, Lanny DeVaney Red Hat, Inc. From owner-linux-mips@oss.sgi.com Tue Mar 12 13:45:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CLjZL24940 for linux-mips-outgoing; Tue, 12 Mar 2002 13:45:35 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CLjW924937 for ; Tue, 12 Mar 2002 13:45:32 -0800 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16kt94-0002F8-00; Tue, 12 Mar 2002 21:45:18 +0100 Date: Tue, 12 Mar 2002 21:45:18 +0100 From: Johannes Stezenbach To: Lanny DeVaney Cc: linux-mips@oss.sgi.com Subject: Re: gdbserver Message-ID: <20020312204518.GA8593@convergence.de> Mail-Followup-To: Johannes Stezenbach , Lanny DeVaney , linux-mips@oss.sgi.com References: <3C8E5560.2090907@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C8E5560.2090907@redhat.com> User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Mar 12, 2002 at 01:22:08PM -0600, Lanny DeVaney wrote: > I've looked back through the archives and find some references to > problems configuring and/or building gdbserver for mips-linux. > > I'm attempting to build gdb/gdbserver with --target=mips-linux as well, > using gdb-5.1.1. Have the earlier issues (they looked to be 1-2 years > old) been resolved or am I still looking at a "manual build" process? > I'm getting lots of errors with the build, although the configure seems > to go OK. x86 host, linux-mips target. I tried the gdb+dejagnu-20020305 snapshot recently and both gdb and gdbserver built without problems. IIRC gdbserver was still broken in gdb-5.1.1. I haven't used the newly built gdbserver yet, though. Regards, Johannes From owner-linux-mips@oss.sgi.com Tue Mar 12 14:47:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CMlWR26273 for linux-mips-outgoing; Tue, 12 Mar 2002 14:47:32 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CMlS926270 for ; Tue, 12 Mar 2002 14:47:28 -0800 Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g2CLk0r05392; Tue, 12 Mar 2002 16:46:00 -0500 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g2CLlPm21188; Tue, 12 Mar 2002 16:47:25 -0500 Received: from redhat.com (dhcp-166.hsv.redhat.com [172.16.17.166]) by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id g2CLlSN08779; Tue, 12 Mar 2002 15:47:28 -0600 Message-ID: <3C8E772E.2030301@redhat.com> Date: Tue, 12 Mar 2002 15:46:22 -0600 From: Lanny DeVaney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: Johannes Stezenbach CC: linux-mips@oss.sgi.com Subject: Re: gdbserver References: <3C8E5560.2090907@redhat.com> <20020312204518.GA8593@convergence.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks. I used the 20020311 snapshot and it built like a champ. Thanks, Lanny DeVaney Red Hat, Inc. Johannes Stezenbach wrote: >On Tue, Mar 12, 2002 at 01:22:08PM -0600, Lanny DeVaney wrote: > >>I've looked back through the archives and find some references to >>problems configuring and/or building gdbserver for mips-linux. >> >>I'm attempting to build gdb/gdbserver with --target=mips-linux as well, >>using gdb-5.1.1. Have the earlier issues (they looked to be 1-2 years >>old) been resolved or am I still looking at a "manual build" process? >>I'm getting lots of errors with the build, although the configure seems >>to go OK. x86 host, linux-mips target. >> > >I tried the gdb+dejagnu-20020305 snapshot recently and >both gdb and gdbserver built without problems. IIRC >gdbserver was still broken in gdb-5.1.1. >I haven't used the newly built gdbserver yet, though. > >Regards, >Johannes > From owner-linux-mips@oss.sgi.com Tue Mar 12 15:10:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CNAfl26711 for linux-mips-outgoing; Tue, 12 Mar 2002 15:10:41 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CNAc926708 for ; Tue, 12 Mar 2002 15:10:39 -0800 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16kuTk-0002MD-00; Tue, 12 Mar 2002 17:10:44 -0500 Date: Tue, 12 Mar 2002 17:10:44 -0500 From: Daniel Jacobowitz To: Lanny DeVaney Cc: linux-mips@oss.sgi.com Subject: Re: gdbserver Message-ID: <20020312171044.A8889@nevyn.them.org> References: <3C8E5560.2090907@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C8E5560.2090907@redhat.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Mar 12, 2002 at 01:22:08PM -0600, Lanny DeVaney wrote: > I've looked back through the archives and find some references to > problems configuring and/or building gdbserver for mips-linux. > > I'm attempting to build gdb/gdbserver with --target=mips-linux as well, > using gdb-5.1.1. Have the earlier issues (they looked to be 1-2 years > old) been resolved or am I still looking at a "manual build" process? > I'm getting lots of errors with the build, although the configure seems > to go OK. x86 host, linux-mips target. > > Thanks for any help you can provide, As Johannes said, use the current CVS snapshot. MIPS/Linux support for gdbserver was only contributed about a month ago. I'd appreciate bug reports if it does not work for you, especially as I only tested little-endian. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Mar 12 15:17:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CNHLg26845 for linux-mips-outgoing; Tue, 12 Mar 2002 15:17:21 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CNHH926841 for ; Tue, 12 Mar 2002 15:17:17 -0800 Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g2CMFor10159; Tue, 12 Mar 2002 17:15:50 -0500 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g2CMHFm28698; Tue, 12 Mar 2002 17:17:15 -0500 Received: from redhat.com (dhcp-166.hsv.redhat.com [172.16.17.166]) by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id g2CMHIN09463; Tue, 12 Mar 2002 16:17:18 -0600 Message-ID: <3C8E7E2C.1060608@redhat.com> Date: Tue, 12 Mar 2002 16:16:12 -0600 From: Lanny DeVaney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@oss.sgi.com Subject: Re: gdbserver References: <3C8E5560.2090907@redhat.com> <20020312171044.A8889@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk OK, I'll keep up with it. I'm doing big-endian. Lanny DeVaney Red Hat, Inc. Daniel Jacobowitz wrote: >On Tue, Mar 12, 2002 at 01:22:08PM -0600, Lanny DeVaney wrote: > >>I've looked back through the archives and find some references to >>problems configuring and/or building gdbserver for mips-linux. >> >>I'm attempting to build gdb/gdbserver with --target=mips-linux as well, >>using gdb-5.1.1. Have the earlier issues (they looked to be 1-2 years >>old) been resolved or am I still looking at a "manual build" process? >>I'm getting lots of errors with the build, although the configure seems >>to go OK. x86 host, linux-mips target. >> >>Thanks for any help you can provide, >> > >As Johannes said, use the current CVS snapshot. MIPS/Linux support for >gdbserver was only contributed about a month ago. I'd appreciate bug >reports if it does not work for you, especially as I only tested >little-endian. > From owner-linux-mips@oss.sgi.com Tue Mar 12 18:26:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2D2QXX28969 for linux-mips-outgoing; Tue, 12 Mar 2002 18:26:33 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2D2QV928966 for ; Tue, 12 Mar 2002 18:26:31 -0800 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id BAA28719 for ; Wed, 13 Mar 2002 01:38:24 -0800 Subject: XFS From: Pete Popov To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Mar 2002 17:29:11 -0800 Message-Id: <1015982952.5196.62.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks to everyone who sent me suggestions and help on how they got xfs working on mips. I tried the split patches on a 2.4.18 kernel, compiled with a 2.95.3 compiler, and the kernel crashes consistently when running bonnie++. The same kernel compiled with a 3.0.1 based compiler seems to work fine. I've ran bonnie++ a few times, as well as other conventional tests. I need to do a lot more testing before I'm convinced that xfs is rock solid on mips, but it appears that the compiler problems described on the web site are for real. Pete From owner-linux-mips@oss.sgi.com Wed Mar 13 02:05:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DA5ia03811 for linux-mips-outgoing; Wed, 13 Mar 2002 02:05:44 -0800 Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2DA5f903808 for ; Wed, 13 Mar 2002 02:05:41 -0800 Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto4.wanadoo.fr; 13 Mar 2002 10:05:34 +0100 Received: from nicolass (193.251.90.77) by mel-rta8.wanadoo.fr; 13 Mar 2002 10:05:07 +0100 Message-ID: <000701c1ca6e$40741fd0$fa4d3254@T2M.lan> From: "Nicolas Sauzede" To: Subject: fetched 2.4.16 source tree Date: Wed, 13 Mar 2002 10:05:41 +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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi ! I've got a working debian linux on my Indy, and I fetched the [kernel-source-2.4.16_2.4.16-1_all.deb] package but I couldn't recompile it ! There are lots of warning and errors, both for kernel/modules I began patching (succesfully) ones concerning scsi, but there still remains keyboard and other part failing to compile.. Do I have to apply some special patch ?? I just D/L [kernel-patch-2.4.16-mips_2.4.16-0.011212.1_all.deb] => is it it ? Is it the best patch, for compiling sources on my Indy ? Thanks, Nicolas Sauzede. From owner-linux-mips@oss.sgi.com Wed Mar 13 02:18:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DAIMa04819 for linux-mips-outgoing; Wed, 13 Mar 2002 02:18:22 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2DAII904816 for ; Wed, 13 Mar 2002 02:18:18 -0800 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 1B7A4B4EC; Wed, 13 Mar 2002 10:18:17 +0100 (CET) Date: Wed, 13 Mar 2002 10:18:17 +0100 From: Guido Guenther To: Nicolas Sauzede Cc: linux-mips@oss.sgi.com Subject: Re: fetched 2.4.16 source tree Message-ID: <20020313101816.A5310@gandalf.physik.uni-konstanz.de> Reply-To: debian-mips@lists.debian.org Mail-Followup-To: Nicolas Sauzede , linux-mips@oss.sgi.com References: <000701c1ca6e$40741fd0$fa4d3254@T2M.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000701c1ca6e$40741fd0$fa4d3254@T2M.lan>; from nicolas.sauzede@t2m.fr on Wed, Mar 13, 2002 at 10:05:41AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Nicolas, On Wed, Mar 13, 2002 at 10:05:41AM +0100, Nicolas Sauzede wrote: > I've got a working debian linux on my Indy, and I fetched the > [kernel-source-2.4.16_2.4.16-1_all.deb] package > but I couldn't recompile it ! > There are lots of warning and errors, both for kernel/modules > I began patching (succesfully) ones concerning scsi, but there still remains > keyboard and other part failing to compile.. > > Do I have to apply some special patch ?? The diff between mainline and the oss mips kernel is about 4MB so yes, you need additional patches. > I just D/L [kernel-patch-2.4.16-mips_2.4.16-0.011212.1_all.deb] => is it it > ? Is it the best patch, for compiling sources on my Indy ? kernel-patch-2.4.17 is latest. The manpage of make-kpkg describes how to apply these patches automagically during build. This is somewhat debian specific, let's move this over to the debian-mips list. -- Guido From owner-linux-mips@oss.sgi.com Wed Mar 13 02:19:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DAJ7q04906 for linux-mips-outgoing; Wed, 13 Mar 2002 02:19:07 -0800 Received: from erebor.lep.brno.cas.cz (erebor.lep.brno.cas.cz [195.178.65.162]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2DAJ4904897 for ; Wed, 13 Mar 2002 02:19:04 -0800 Received: from ladis (helo=localhost) by erebor.lep.brno.cas.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 16l4wm-0005vW-00; Wed, 13 Mar 2002 10:21:24 +0100 Date: Wed, 13 Mar 2002 10:21:24 +0100 (CET) From: Ladislav Michl X-Sender: ladis@erebor.lep.brno.cas.cz To: Nicolas Sauzede cc: linux-mips@oss.sgi.com Subject: Re: fetched 2.4.16 source tree In-Reply-To: <000701c1ca6e$40741fd0$fa4d3254@T2M.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 13 Mar 2002, Nicolas Sauzede wrote: > Hi ! hi Nikolas! > I've got a working debian linux on my Indy, and I fetched the > [kernel-source-2.4.16_2.4.16-1_all.deb] package > but I couldn't recompile it ! that is not big surprise :-) 2.4.19-pre2 (or cvs) is kernel of your choice. ladis From owner-linux-mips@oss.sgi.com Wed Mar 13 02:46:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DAkBC05383 for linux-mips-outgoing; Wed, 13 Mar 2002 02:46:11 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2DAk7905380 for ; Wed, 13 Mar 2002 02:46:08 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id g2D9k0n14424 for ; Wed, 13 Mar 2002 10:46:00 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GQZL44VP; Wed, 13 Mar 2002 10:45:59 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Wed, 13 Mar 2002 10:45:59 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 10:45:55 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E7A1@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: TTY/Serial-Console Problem Date: Wed, 13 Mar 2002 10:45:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi. I have a problem with my serial console driver for kernel 2.4.3. The system boots fine up to the first shell script that is executed (here: rcS). Then when the first "echo" ist executed the message is displayed on the console, but the system is stuck in the cpu_idle function. I still can ping the board but the execution of the script won't continue. If I use "echo -n" everything is fine. I reckon that the tty layer is waiting for some kind of confimation from the serial driver to continue execution. But I don't what that might be. Can anybody please clarify me? regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Wed Mar 13 16:00:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E00FX06759 for linux-mips-outgoing; Wed, 13 Mar 2002 16:00:15 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2E00A906755 for ; Wed, 13 Mar 2002 16:00:11 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2DN08k25896 for linux-mips@oss.sgi.com; Wed, 13 Mar 2002 15:00:09 -0800 Received: from portablue.intern.mind.be (NAT.office.mind.be [62.166.230.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A59x917411 for ; Sat, 9 Mar 2002 21:10:00 -0800 Received: by portablue.intern.mind.be (Postfix, from userid 505) id AAB8DB2D15; Sun, 10 Mar 2002 05:09:56 +0100 (CET) Date: Sun, 10 Mar 2002 05:09:55 +0100 To: linux-mips@oss.sgi.com, geert@linux-m68k.org, wim@sonycom.com, lionel@sonycom.com, thomasv@sonycom.com, Nico.DeRanter@sonycom.com, tea@sonycom.com, joel@sonycom.com, michiels@CoWare.com, gds@denayer.wenk.be, p2@mind.be Subject: and now the real patch Message-ID: <20020310040955.GB4336@mind.be> Mail-Followup-To: p2@mind.be, linux-mips@oss.sgi.com, geert@linux-m68k.org, wim@sonycom.com, lionel@sonycom.com, thomasv@sonycom.com, Nico.DeRanter@sonycom.com, tea@sonycom.com, joel@sonycom.com, michiels@CoWare.com, gds@denayer.wenk.be Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Answer: 42 X-Operating-system: Debian GNU/Linux X-Message-Flag: Get yourself a real email client. http://www.mutt.org/ From: p2@mind.be (Peter De Schrijver) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline And of course I forgot to attach the code... Have fun, Peter. --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diffje diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/Makefile linux/arch/mips/Makefile --- linux.orig/linux/arch/mips/Makefile Sat Feb 16 03:02:44 2002 +++ linux/arch/mips/Makefile Tue Feb 26 20:10:48 2002 @@ -195,8 +195,8 @@ # NEC DDB Vrc-5074 # ifdef CONFIG_DDB5074 -SUBDIRS += arch/mips/ddb5074 -LIBS += arch/mips/ddb5074/ddb5074.a +SUBDIRS += arch/mips/ddb5xxx/common arch/mips/ddb5xxx/ddb5074 +LIBS += arch/mips/ddb5xxx/common/ddb5xxx.o arch/mips/ddb5xxx/ddb5074/ddb5074.o LOADADDR += 0x80080000 endif diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/config.in linux/arch/mips/config.in --- linux.orig/linux/arch/mips/config.in Sat Mar 9 17:48:51 2002 +++ linux/arch/mips/config.in Thu Mar 7 23:33:05 2002 @@ -186,9 +186,12 @@ define_bool CONFIG_I8259 y define_bool CONFIG_ISA y define_bool CONFIG_NONCOHERENT_IO y + define_bool CONFIG_IRQ_CPU y define_bool CONFIG_PCI y + define_bool CONFIG_NEW_PCI y + define_bool CONFIG_PCI_AUTO y define_bool CONFIG_PC_KEYB y - define_bool CONFIG_OLD_TIME_C y + define_bool CONFIG_NEW_TIME_C y fi if [ "$CONFIG_DDB5476" = "y" ]; then define_bool CONFIG_ISA y diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/ddb5xxx/ddb5074/Makefile linux/arch/mips/ddb5xxx/ddb5074/Makefile --- linux.orig/linux/arch/mips/ddb5xxx/ddb5074/Makefile Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/ddb5xxx/ddb5074/Makefile Mon Jan 14 14:10:26 2002 @@ -0,0 +1,21 @@ +# +# Makefile for the NEC DDB Vrc-5074 specific kernel interface routines +# under Linux. +# +# Note! Dependencies are done automagically by 'make dep', which also +# removes any old dependencies. DON'T put your own dependencies here +# unless it's something special (ie not a .c file). +# +# Note 2! The CFLAGS definitions are now in the main makefile... +# + +.S.s: + $(CPP) $(CFLAGS) $< -o $*.s +.S.o: + $(CC) $(CFLAGS) -c $< -o $*.o + +O_TARGET = ddb5074.o + +obj-y += setup.o irq.o int-handler.o pci.o pci_ops.o nile4_pic.o + +include $(TOPDIR)/Rules.make diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/ddb5xxx/ddb5074/int-handler.S linux/arch/mips/ddb5xxx/ddb5074/int-handler.S --- linux.orig/linux/arch/mips/ddb5xxx/ddb5074/int-handler.S Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/ddb5xxx/ddb5074/int-handler.S Mon Jan 14 14:10:26 2002 @@ -0,0 +1,120 @@ +/* + * arch/mips/ddb5074/int-handler.S -- NEC DDB Vrc-5074 interrupt handler + * + * Based on arch/mips/sgi/kernel/indyIRQ.S + * + * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + */ +#include +#include +#include +#include + +/* A lot of complication here is taken away because: + * + * 1) We handle one interrupt and return, sitting in a loop and moving across + * all the pending IRQ bits in the cause register is _NOT_ the answer, the + * common case is one pending IRQ so optimize in that direction. + * + * 2) We need not check against bits in the status register IRQ mask, that + * would make this routine slow as hell. + * + * 3) Linux only thinks in terms of all IRQs on or all IRQs off, nothing in + * between like BSD spl() brain-damage. + * + * Furthermore, the IRQs on the INDY look basically (barring software IRQs + * which we don't use at all) like: + * + * MIPS IRQ Source + * -------- ------ + * 0 Software (ignored) + * 1 Software (ignored) + * 2 Local IRQ level zero + * 3 Local IRQ level one + * 4 8254 Timer zero + * 5 8254 Timer one + * 6 Bus Error + * 7 R4k timer (what we use) + * + * We handle the IRQ according to _our_ priority which is: + * + * Highest ---- R4k Timer + * Local IRQ zero + * Local IRQ one + * Bus Error + * 8254 Timer zero + * Lowest ---- 8254 Timer one + * + * then we just return, if multiple IRQs are pending then we will just take + * another exception, big deal. + */ + + .text + .set noreorder + .set noat + .align 5 + NESTED(ddbIRQ, PT_SIZE, sp) + SAVE_ALL + CLI + .set at + mfc0 s0, CP0_CAUSE # get irq mask + +#if 1 + mfc0 t2,CP0_STATUS # get enabled interrupts + and s0,t2 # isolate allowed ones +#endif + /* First we check for r4k counter/timer IRQ. */ + andi a0, s0, CAUSEF_IP2 # delay slot, check local level zero + beq a0, zero, 1f + andi a0, s0, CAUSEF_IP3 # delay slot, check local level one + + /* Wheee, local level zero interrupt. */ + jal ddb_local0_irqdispatch + move a0, sp # delay slot + + j ret_from_irq + nop # delay slot + +1: + beq a0, zero, 1f + andi a0, s0, CAUSEF_IP6 # delay slot, check bus error + + /* Wheee, local level one interrupt. */ + move a0, sp + jal ddb_local1_irqdispatch + nop + + j ret_from_irq + nop + +1: + beq a0, zero, 1f + nop + + /* Wheee, an asynchronous bus error... */ + move a0, sp + jal ddb_buserror_irq + nop + + j ret_from_irq + nop + +1: + /* Here by mistake? This is possible, what can happen + * is that by the time we take the exception the IRQ + * pin goes low, so just leave if this is the case. + */ + andi a0, s0, (CAUSEF_IP4 | CAUSEF_IP5) + beq a0, zero, 1f + + /* Must be one of the 8254 timers... */ + move a0, sp + jal ddb_8254timer_irq + nop +1: + j ret_from_irq + nop + END(ddbIRQ) diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/ddb5xxx/ddb5074/irq.c linux/arch/mips/ddb5xxx/ddb5074/irq.c --- linux.orig/linux/arch/mips/ddb5xxx/ddb5074/irq.c Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/ddb5xxx/ddb5074/irq.c Sun Mar 10 03:20:26 2002 @@ -0,0 +1,165 @@ +/* + * arch/mips/ddb5074/irq.c -- NEC DDB Vrc-5074 interrupt routines + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + */ +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + + +extern void __init i8259_init(void); +extern void i8259_disable_irq(unsigned int irq_nr); +extern void i8259_enable_irq(unsigned int irq_nr); + +extern asmlinkage void ddbIRQ(void); +extern asmlinkage void i8259_do_irq(int irq, struct pt_regs *regs); +extern asmlinkage void do_IRQ(int irq, struct pt_regs *regs); + +static struct irqaction irq_cascade = { no_action, 0, 0, "cascade", NULL, NULL }; + +#define M1543_PNP_CONFIG 0x03f0 /* PnP Config Port */ +#define M1543_PNP_INDEX 0x03f0 /* PnP Index Port */ +#define M1543_PNP_DATA 0x03f1 /* PnP Data Port */ + +#define M1543_PNP_ALT_CONFIG 0x0370 /* Alternative PnP Config Port */ +#define M1543_PNP_ALT_INDEX 0x0370 /* Alternative PnP Index Port */ +#define M1543_PNP_ALT_DATA 0x0371 /* Alternative PnP Data Port */ + +#define M1543_INT1_MASTER_CTRL 0x0020 /* INT_1 (master) Control Register */ +#define M1543_INT1_MASTER_MASK 0x0021 /* INT_1 (master) Mask Register */ + +#define M1543_INT1_SLAVE_CTRL 0x00a0 /* INT_1 (slave) Control Register */ +#define M1543_INT1_SLAVE_MASK 0x00a1 /* INT_1 (slave) Mask Register */ + +#define M1543_INT1_MASTER_ELCR 0x04d0 /* INT_1 (master) Edge/Level Control */ +#define M1543_INT1_SLAVE_ELCR 0x04d1 /* INT_1 (slave) Edge/Level Control */ + + +static void m1543_irq_setup(void) +{ + /* + * The ALI M1543 has 13 interrupt inputs, IRQ1..IRQ13. Not all + * the possible IO sources in the M1543 are in use by us. We will + * use the following mapping: + * + * IRQ1 - keyboard (default set by M1543) + * IRQ3 - reserved for UART B (default set by M1543) (note that + * the schematics for the DDB Vrc-5074 board seem to + * indicate that IRQ3 is connected to the DS1386 + * watchdog timer interrupt output so we might have + * a conflict) + * IRQ4 - reserved for UART A (default set by M1543) + * IRQ5 - parallel (default set by M1543) + * IRQ8 - DS1386 time of day (RTC) interrupt + * IRQ12 - mouse + */ + + /* + * Assing mouse interrupt to IRQ12 + */ + + /* Enter configuration mode */ + outb(0x51, M1543_PNP_CONFIG); + outb(0x23, M1543_PNP_CONFIG); + + /* Select logical device 7 (Keyboard) */ + outb(0x07, M1543_PNP_INDEX); + outb(0x07, M1543_PNP_DATA); + + /* Select IRQ12 */ + outb(0x72, M1543_PNP_INDEX); + outb(0x0c, M1543_PNP_DATA); + + outb(0x30, M1543_PNP_INDEX); + + outb(0x70, M1543_PNP_INDEX); + + /* Leave configration mode */ + outb(0xbb, M1543_PNP_CONFIG); + + +} + +void ddb_local0_irqdispatch(struct pt_regs *regs) +{ + u32 mask; + int nile4_irq; + + mask = nile4_get_irq_stat(0); + + /* Handle the timer interrupt first */ +#if 0 + if (mask & (1 << NILE4_INT_GPT)) { + do_IRQ(nile4_to_irq(NILE4_INT_GPT), regs); + mask &= ~(1 << NILE4_INT_GPT); + } +#endif + for (nile4_irq = 0; mask; nile4_irq++, mask >>= 1) + if (mask & 1) { + if (nile4_irq == NILE4_INT_INTE) { + int i8259_irq; + + nile4_clear_irq(NILE4_INT_INTE); + i8259_irq = nile4_i8259_iack(); + do_IRQ(i8259_irq, regs); + } else + do_IRQ(nile4_to_irq(nile4_irq), regs); + + } +} + +void ddb_local1_irqdispatch(void) +{ + printk("ddb_local1_irqdispatch called\n"); +} + +void ddb_buserror_irq(void) +{ + printk("ddb_buserror_irq called\n"); +} + +void ddb_8254timer_irq(void) +{ + printk("ddb_8254timer_irq called\n"); +} + +void __init ddb_irq_setup(void) +{ +#ifdef CONFIG_REMOTE_DEBUG + if (remote_debug) + set_debug_traps(); + breakpoint(); /* you may move this line to whereever you want :-) */ +#endif + + /* setup cascade interrupts */ + setup_irq(NILE4_IRQ_BASE + NILE4_INT_INTE, &irq_cascade); + setup_irq(CPU_IRQ_BASE + CPU_NILE4_CASCADE, &irq_cascade); + + set_except_vector(0, ddbIRQ); + + nile4_irq_setup(NILE4_IRQ_BASE); + m1543_irq_setup(); + init_i8259_irqs(); + + mips_cpu_irq_init(CPU_IRQ_BASE); + + ddb5074_led_hex(0); + + /* Enable the interrupt cascade */ + nile4_enable_irq(NILE4_IRQ_BASE+IRQ_I8259_CASCADE); + + +} diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/ddb5xxx/ddb5074/nile4_pic.c linux/arch/mips/ddb5xxx/ddb5074/nile4_pic.c --- linux.orig/linux/arch/mips/ddb5xxx/ddb5074/nile4_pic.c Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/ddb5xxx/ddb5074/nile4_pic.c Tue Feb 26 10:54:06 2002 @@ -0,0 +1,288 @@ +/* + * arch/mips/ddb5476/nile4.c -- + * low-level PIC code for NEC Vrc-5476 (Nile 4) + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + * + * Copyright 2001 MontaVista Software Inc. + * Author: jsun@mvista.com or jsun@junsun.net + * + */ +#include +#include +#include +#include + +#include + +#include + +static int irq_base; + +/* + * Interrupt Programming + */ +void nile4_map_irq(int nile4_irq, int cpu_irq) +{ + u32 offset, t; + + offset = DDB_INTCTRL; + if (nile4_irq >= 8) { + offset += 4; + nile4_irq -= 8; + } + t = ddb_in32(offset); + t &= ~(7 << (nile4_irq * 4)); + t |= cpu_irq << (nile4_irq * 4); + ddb_out32(offset, t); +} + +void nile4_map_irq_all(int cpu_irq) +{ + u32 all, t; + + all = cpu_irq; + all |= all << 4; + all |= all << 8; + all |= all << 16; + t = ddb_in32(DDB_INTCTRL); + t &= 0x88888888; + t |= all; + ddb_out32(DDB_INTCTRL, t); + t = ddb_in32(DDB_INTCTRL + 4); + t &= 0x88888888; + t |= all; + ddb_out32(DDB_INTCTRL + 4, t); +} + +void nile4_enable_irq(int nile4_irq) +{ + u32 offset, t; + + nile4_irq-=irq_base; + + ddb5074_led_hex(8); + + offset = DDB_INTCTRL; + if (nile4_irq >= 8) { + offset += 4; + nile4_irq -= 8; + } + ddb5074_led_hex(9); + t = ddb_in32(offset); + ddb5074_led_hex(0xa); + t |= 8 << (nile4_irq * 4); + ddb_out32(offset, t); + ddb5074_led_hex(0xb); +} + +void nile4_disable_irq(int nile4_irq) +{ + u32 offset, t; + + nile4_irq-=irq_base; + + offset = DDB_INTCTRL; + if (nile4_irq >= 8) { + offset += 4; + nile4_irq -= 8; + } + t = ddb_in32(offset); + t &= ~(8 << (nile4_irq * 4)); + ddb_out32(offset, t); +} + +void nile4_disable_irq_all(void) +{ + ddb_out32(DDB_INTCTRL, 0); + ddb_out32(DDB_INTCTRL + 4, 0); +} + +u16 nile4_get_irq_stat(int cpu_irq) +{ + return ddb_in16(DDB_INTSTAT0 + cpu_irq * 2); +} + +void nile4_enable_irq_output(int cpu_irq) +{ + u32 t; + + t = ddb_in32(DDB_INTSTAT1 + 4); + t |= 1 << (16 + cpu_irq); + ddb_out32(DDB_INTSTAT1, t); +} + +void nile4_disable_irq_output(int cpu_irq) +{ + u32 t; + + t = ddb_in32(DDB_INTSTAT1 + 4); + t &= ~(1 << (16 + cpu_irq)); + ddb_out32(DDB_INTSTAT1, t); +} + +void nile4_set_pci_irq_polarity(int pci_irq, int high) +{ + u32 t; + + t = ddb_in32(DDB_INTPPES); + if (high) + t &= ~(1 << (pci_irq * 2)); + else + t |= 1 << (pci_irq * 2); + ddb_out32(DDB_INTPPES, t); +} + +void nile4_set_pci_irq_level_or_edge(int pci_irq, int level) +{ + u32 t; + + t = ddb_in32(DDB_INTPPES); + if (level) + t |= 2 << (pci_irq * 2); + else + t &= ~(2 << (pci_irq * 2)); + ddb_out32(DDB_INTPPES, t); +} + +void nile4_clear_irq(int nile4_irq) +{ + nile4_irq-=irq_base; + ddb_out32(DDB_INTCLR, 1 << nile4_irq); +} + +void nile4_clear_irq_mask(u32 mask) +{ + ddb_out32(DDB_INTCLR, mask); +} + +u8 nile4_i8259_iack(void) +{ + u8 irq; + u32 reg; + + /* Set window 0 for interrupt acknowledge */ + reg = ddb_in32(DDB_PCIINIT0); + + ddb_set_pmr(DDB_PCIINIT0, DDB_PCICMD_IACK, 0, DDB_PCI_ACCESS_32); + irq = *(volatile u8 *) KSEG1ADDR(DDB_PCI_IACK_BASE); + /* restore window 0 for PCI I/O space */ + // ddb_set_pmr(DDB_PCIINIT0, DDB_PCICMD_IO, 0, DDB_PCI_ACCESS_32); + ddb_out32(DDB_PCIINIT0, reg); + + /* i8269.c set the base vector to be 0x0 */ + return irq ; +} + +static int nile4_irq_startup(int irq) { + + nile4_enable_irq(irq); + return 0; + +} + +static void nile4_ack_irq(int irq) { + + ddb5074_led_hex(4); + + nile4_clear_irq(irq); + ddb5074_led_hex(2); + nile4_disable_irq(irq); + + ddb5074_led_hex(0); +} + +static void nile4_irq_end(int irq) { + + ddb5074_led_hex(3); + if(!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { + ddb5074_led_hex(5); + nile4_enable_irq(irq); + ddb5074_led_hex(7); + } + + ddb5074_led_hex(1); +} + +#define nile4_irq_shutdown nile4_disable_irq + +static hw_irq_controller nile4_irq_controller = { + "nile4", + nile4_irq_startup, + nile4_irq_shutdown, + nile4_enable_irq, + nile4_disable_irq, + nile4_ack_irq, + nile4_irq_end, + NULL +}; + +void nile4_irq_setup(u32 base) { + + int i; + extern irq_desc_t irq_desc[]; + + irq_base=base; + + /* Map all interrupts to CPU int #0 */ + nile4_map_irq_all(0); + + /* PCI INTA#-E# must be level triggered */ + nile4_set_pci_irq_level_or_edge(0, 1); + nile4_set_pci_irq_level_or_edge(1, 1); + nile4_set_pci_irq_level_or_edge(2, 1); + nile4_set_pci_irq_level_or_edge(3, 1); + nile4_set_pci_irq_level_or_edge(4, 1); + + /* PCI INTA#-D# must be active low, INTE# must be active high */ + nile4_set_pci_irq_polarity(0, 0); + nile4_set_pci_irq_polarity(1, 0); + nile4_set_pci_irq_polarity(2, 0); + nile4_set_pci_irq_polarity(3, 0); + nile4_set_pci_irq_polarity(4, 1); + + + for (i = 0; i < 16; i++) { + nile4_clear_irq(i); + nile4_disable_irq(i); + } + + /* Enable CPU int #0 */ + nile4_enable_irq_output(0); + + for (i= base; i< base + NUM_NILE4_INTERRUPTS; i++) { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = NULL; + irq_desc[i].depth = 1; + irq_desc[i].handler = &nile4_irq_controller; + } + +} + +#if defined(CONFIG_LL_DEBUG) +void nile4_dump_irq_status(void) +{ + printk(KERN_DEBUG " + CPUSTAT = %p:%p\n", (void *) ddb_in32(DDB_CPUSTAT + 4), + (void *) ddb_in32(DDB_CPUSTAT)); + printk(KERN_DEBUG " + INTCTRL = %p:%p\n", (void *) ddb_in32(DDB_INTCTRL + 4), + (void *) ddb_in32(DDB_INTCTRL)); + printk(KERN_DEBUG + "INTSTAT0 = %p:%p\n", + (void *) ddb_in32(DDB_INTSTAT0 + 4), + (void *) ddb_in32(DDB_INTSTAT0)); + printk(KERN_DEBUG + "INTSTAT1 = %p:%p\n", + (void *) ddb_in32(DDB_INTSTAT1 + 4), + (void *) ddb_in32(DDB_INTSTAT1)); + printk(KERN_DEBUG + "INTCLR = %p:%p\n", (void *) ddb_in32(DDB_INTCLR + 4), + (void *) ddb_in32(DDB_INTCLR)); + printk(KERN_DEBUG + "INTPPES = %p:%p\n", (void *) ddb_in32(DDB_INTPPES + 4), + (void *) ddb_in32(DDB_INTPPES)); +} + +#endif diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/ddb5xxx/ddb5074/pci.c linux/arch/mips/ddb5xxx/ddb5074/pci.c --- linux.orig/linux/arch/mips/ddb5xxx/ddb5074/pci.c Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/ddb5xxx/ddb5074/pci.c Sun Mar 10 03:20:55 2002 @@ -0,0 +1,129 @@ +#include +#include +#include +#include + +#include +#include + +#include + +static struct resource extpci_io_resource = { + "pci IO space", + 0x1000, /* leave some room for ISA bus */ + DDB_PCI_IO_SIZE -1, + IORESOURCE_IO}; + +static struct resource extpci_mem_resource = { + "pci memory space", + DDB_PCI_MEM_BASE + 0x00100000, /* leave 1 MB for RTC */ + DDB_PCI_MEM_BASE + DDB_PCI_MEM_SIZE -1, + IORESOURCE_MEM}; + +extern struct pci_ops ddb5476_ext_pci_ops; + +struct pci_channel mips_pci_channels[] = { + { &ddb5476_ext_pci_ops, &extpci_io_resource, &extpci_mem_resource }, + { NULL, NULL, NULL} +}; + +#define PCI_EXT_INTA 8 +#define PCI_EXT_INTB 9 +#define PCI_EXT_INTC 10 +#define PCI_EXT_INTD 11 +#define PCI_EXT_INTE 12 + +#define MAX_SLOT_NUM 14 + +static unsigned char irq_map[MAX_SLOT_NUM] = { + /* SLOT: 0 */ nile4_to_irq(PCI_EXT_INTE), + /* SLOT: 1 */ nile4_to_irq(PCI_EXT_INTA), + /* SLOT: 2 */ nile4_to_irq(PCI_EXT_INTA), + /* SLOT: 3 */ nile4_to_irq(PCI_EXT_INTB), + /* SLOT: 4 */ nile4_to_irq(PCI_EXT_INTC), + /* SLOT: 5 */ nile4_to_irq(NILE4_INT_UART), + /* SLOT: 6 */ 0xff, + /* SLOT: 7 */ 0xff, + /* SLOT: 8 */ 0xff, + /* SLOT: 9 */ 0xff, + /* SLOT: 10 */ nile4_to_irq(PCI_EXT_INTE), + /* SLOT: 11 */ 0xff, + /* SLOT: 12 */ 0xff, + /* SLOT: 13 */ nile4_to_irq(PCI_EXT_INTE), +}; + +void __init pcibios_fixup_irqs(void) { + + struct pci_dev *dev; + int slot_num; + + pci_for_each_dev(dev) { + slot_num = PCI_SLOT(dev->devfn); + db_assert(slot_num < MAX_SLOT_NUM); + db_assert(irq_map[slot_num] != 0xff); + + pci_write_config_byte(dev, + PCI_INTERRUPT_LINE, + irq_map[slot_num]); + + dev->irq = irq_map[slot_num]; + } +} + +void __init ddb_pci_reset_bus(void) +{ + u32 temp; + + /* + * I am not sure about the "official" procedure, the following + * steps work as far as I know: + * We first set PCI cold reset bit (bit 31) in PCICTRL-H. + * Then we clear the PCI warm reset bit (bit 30) to 0 in PCICTRL-H. + * The same is true for both PCI channels. + */ + temp = ddb_in32(DDB_PCICTRL+4); + temp |= 0x80000000; + ddb_out32(DDB_PCICTRL+4, temp); + temp &= ~0xc0000000; + ddb_out32(DDB_PCICTRL+4, temp); + +} + +unsigned __init int pcibios_assign_all_busses(void) +{ + /* we hope pci_auto has assigned the bus numbers to all buses */ + return 1; +} + +void __init pcibios_fixup_resources(struct pci_dev *dev) +{ +} + +void __init pcibios_fixup(void) +{ + struct pci_dev *dev; + + pci_for_each_dev(dev) { + if (dev->vendor == PCI_VENDOR_ID_AL && + dev->device == PCI_DEVICE_ID_AL_M7101) { + /* + * It's nice to have the LEDs on the GPIO pins + * available for debugging + */ + extern struct pci_dev *pci_pmu; + u8 t8; + + pci_pmu = dev; /* for LEDs D2 and D3 */ + /* Program the lines for LEDs D2 and D3 to output */ + pci_read_config_byte(dev, 0x7d, &t8); + t8 |= 0xc0; + pci_write_config_byte(dev, 0x7d, t8); + /* Turn LEDs D2 and D3 off */ + pci_read_config_byte(dev, 0x7e, &t8); + t8 |= 0xc0; + pci_write_config_byte(dev, 0x7e, t8); + + } + } +} + diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/ddb5xxx/ddb5074/pci_ops.c linux/arch/mips/ddb5xxx/ddb5074/pci_ops.c --- linux.orig/linux/arch/mips/ddb5xxx/ddb5074/pci_ops.c Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/ddb5xxx/ddb5074/pci_ops.c Mon Feb 25 19:12:48 2002 @@ -0,0 +1,342 @@ +/* + * Copyright 2001 MontaVista Software Inc. + * Author: Jun Sun, jsun@mvista.com or jsun@junsun.net + * + * arch/mips/ddb5xxx/ddb5476/pci_ops.c + * Define the pci_ops for DB5477. + * + * Much of the code is derived from the original DDB5074 port by + * Geert Uytterhoeven + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#include +#include +#include +#include + +#include +#include + +#include + +/* + * config_swap structure records what set of pdar/pmr are used + * to access pci config space. It also provides a place hold the + * original values for future restoring. + */ +struct pci_config_swap { + u32 pdar; + u32 pmr; + u32 config_base; + u32 config_size; + u32 pdar_backup; + u32 pmr_backup; +}; + +/* + * On DDB5476, we have one set of swap registers + */ +struct pci_config_swap ext_pci_swap = { + DDB_PCIW0, + DDB_PCIINIT0, + DDB_PCI_CONFIG_BASE, + DDB_PCI_CONFIG_SIZE +}; + +static int pci_config_workaround=1; + +/* + * access config space + */ +static inline u32 ddb_access_config_base(struct pci_config_swap *swap, + u32 bus,/* 0 means top level bus */ + u32 slot_num) +{ + u32 pci_addr = 0; + u32 pciinit_offset = 0; + u32 virt_addr = swap->config_base; + u32 option; + + if (pci_config_workaround) { + if (slot_num == 5) slot_num = 14; + } + else { + if (slot_num == 5) return DDB_BASE + DDB_PCI_BASE; + } + + /* minimum pdar (window) size is 2MB */ + db_assert(swap->config_size >= (2 << 20)); + + db_assert(slot_num < (1 << 5)); + db_assert(bus < (1 << 8)); + + /* backup registers */ + swap->pdar_backup = ddb_in32(swap->pdar); + swap->pmr_backup = ddb_in32(swap->pmr); + + /* set the pdar (pci window) register */ + ddb_set_pdar(swap->pdar, + swap->config_base, + swap->config_size, + 32, /* 32 bit wide */ + 0, /* not on local memory bus */ + 0); /* not visible from PCI bus (N/A) */ + + /* + * calcuate the absolute pci config addr; + * according to the spec, we start scanning from adr:11 (0x800) + */ + if (bus == 0) { + /* type 0 config */ + pci_addr = 0x00040000 << slot_num; + } else { + /* type 1 config */ + pci_addr = 0x00040000 << slot_num; + panic("ddb_access_config_base: we don't support type 1 config Yet"); + } + + /* + * if pci_addr is less than pci config window size, we set + * pciinit_offset to 0 and adjust the virt_address. + * Otherwise we will try to adjust pciinit_offset. + */ + if (pci_addr < swap->config_size) { + virt_addr = KSEG1ADDR(swap->config_base + pci_addr); + pciinit_offset = 0; + } else { + db_assert( (pci_addr & (swap->config_size - 1)) == 0); + virt_addr = KSEG1ADDR(swap->config_base); + pciinit_offset = pci_addr; + } + + /* set the pmr register */ + option = DDB_PCI_ACCESS_32; + if (bus != 0) option |= DDB_PCI_CFGTYPE1; + ddb_set_pmr(swap->pmr, DDB_PCICMD_CFG, pciinit_offset, option); + + return virt_addr; +} + +static inline void ddb_close_config_base(struct pci_config_swap *swap) +{ + ddb_out32(swap->pdar, swap->pdar_backup); + ddb_out32(swap->pmr, swap->pmr_backup); +} + +static int read_config_dword(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u32 *val) +{ + u32 bus, slot_num, func_num; + u32 base; + + db_assert((where & 3) == 0); + db_assert(where < (1 << 8)); + + /* check if the bus is top-level */ + if (dev->bus->parent != NULL) { + bus = dev->bus->number; + db_assert(bus != 0); + } else { + bus = 0; + } + + slot_num = PCI_SLOT(dev->devfn); + func_num = PCI_FUNC(dev->devfn); + base = ddb_access_config_base(swap, bus, slot_num); + *val = *(volatile u32*) (base + (func_num << 8) + where); + ddb_close_config_base(swap); + return PCIBIOS_SUCCESSFUL; +} + +static int read_config_word(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u16 *val) +{ + int status; + u32 result; + + db_assert((where & 1) == 0); + + status = read_config_dword(swap, dev, where & ~3, &result); + if (where & 2) result >>= 16; + *val = result & 0xffff; + return status; +} + +static int read_config_byte(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u8 *val) +{ + int status; + u32 result; + + status = read_config_dword(swap, dev, where & ~3, &result); + if (where & 1) result >>= 8; + if (where & 2) result >>= 16; + *val = result & 0xff; + return status; +} + +static int write_config_dword(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u32 val) +{ + u32 bus, slot_num, func_num; + u32 base; + + db_assert((where & 3) == 0); + db_assert(where < (1 << 8)); + + /* check if the bus is top-level */ + if (dev->bus->parent != NULL) { + bus = dev->bus->number; + db_assert(bus != 0); + } else { + bus = 0; + } + + slot_num = PCI_SLOT(dev->devfn); + func_num = PCI_FUNC(dev->devfn); + base = ddb_access_config_base(swap, bus, slot_num); + *(volatile u32*) (base + (func_num << 8) + where) = val; + ddb_close_config_base(swap); + return PCIBIOS_SUCCESSFUL; +} + +static int write_config_word(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u16 val) +{ + int status, shift=0; + u32 result; + + db_assert((where & 1) == 0); + + status = read_config_dword(swap, dev, where & ~3, &result); + if (status != PCIBIOS_SUCCESSFUL) return status; + + if (where & 2) + shift += 16; + result &= ~(0xffff << shift); + result |= val << shift; + return write_config_dword(swap, dev, where & ~3, result); +} + +static int write_config_byte(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u8 val) +{ + int status, shift=0; + u32 result; + + status = read_config_dword(swap, dev, where & ~3, &result); + if (status != PCIBIOS_SUCCESSFUL) return status; + + if (where & 2) + shift += 16; + if (where & 1) + shift += 8; + result &= ~(0xff << shift); + result |= val << shift; + return write_config_dword(swap, dev, where & ~3, result); +} + +#define MAKE_PCI_OPS(prefix, rw, unitname, unittype, pciswap) \ +static int prefix##_##rw##_config_##unitname(struct pci_dev *dev, int where, unittype val) \ +{ \ + return rw##_config_##unitname(pciswap, \ + dev, \ + where, \ + val); \ +} + +MAKE_PCI_OPS(extpci, read, byte, u8 *, &ext_pci_swap) +MAKE_PCI_OPS(extpci, read, word, u16 *, &ext_pci_swap) +MAKE_PCI_OPS(extpci, read, dword, u32 *, &ext_pci_swap) + +MAKE_PCI_OPS(extpci, write, byte, u8, &ext_pci_swap) +MAKE_PCI_OPS(extpci, write, word, u16, &ext_pci_swap) +MAKE_PCI_OPS(extpci, write, dword, u32, &ext_pci_swap) + +struct pci_ops ddb5476_ext_pci_ops ={ + extpci_read_config_byte, + extpci_read_config_word, + extpci_read_config_dword, + extpci_write_config_byte, + extpci_write_config_word, + extpci_write_config_dword +}; + + +#if defined(CONFIG_DEBUG) +void jsun_scan_pci_bus(void) +{ + struct pci_bus bus; + struct pci_dev dev; + unsigned int devfn; + int j; + + pci_config_workaround = 0; + + bus.parent = NULL; /* we scan the top level only */ + dev.bus = &bus; + dev.sysdata = NULL; + + /* scan ext pci bus and io pci bus*/ + for (j=0; j< 1; j++) { + printk(KERN_INFO "scan ddb5476 external PCI bus:\n"); + bus.ops = &ddb5476_ext_pci_ops; + + for (devfn = 0; devfn < 0x100; devfn += 8) { + u32 temp; + u16 temp16; + u8 temp8; + int i; + + dev.devfn = devfn; + db_verify(pci_read_config_dword(&dev, 0, &temp), + == PCIBIOS_SUCCESSFUL); + if (temp == 0xffffffff) continue; + + printk(KERN_INFO "slot %d: (addr %d) \n", devfn/8, + 11+devfn/8); + + /* verify read word and byte */ + db_verify(pci_read_config_word(&dev, 2, &temp16), + == PCIBIOS_SUCCESSFUL); + db_assert(temp16 == (temp >> 16)); + db_verify(pci_read_config_byte(&dev, 3, &temp8), + == PCIBIOS_SUCCESSFUL); + db_assert(temp8 == (temp >> 24)); + db_verify(pci_read_config_byte(&dev, 1, &temp8), + == PCIBIOS_SUCCESSFUL); + db_assert(temp8 == ((temp >> 8) & 0xff)); + + for (i=0; i < 16; i++) { + if ((i%4) == 0) + printk(KERN_INFO); + db_verify(pci_read_config_dword(&dev, i*4, &temp), + == PCIBIOS_SUCCESSFUL); + printk("\t%08X", temp); + if ((i%4) == 3) + printk("\n"); + } + } + } + + pci_config_workaround = 1; +} +#endif diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/ddb5xxx/ddb5074/setup.c linux/arch/mips/ddb5xxx/ddb5074/setup.c --- linux.orig/linux/arch/mips/ddb5xxx/ddb5074/setup.c Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/ddb5xxx/ddb5074/setup.c Tue Feb 26 10:52:45 2002 @@ -0,0 +1,258 @@ +/* + * arch/mips/ddb5074/setup.c -- NEC DDB Vrc-5074 setup routines + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#ifdef CONFIG_REMOTE_DEBUG +extern void rs_kgdb_hook(int); +extern void breakpoint(void); +#endif + +#if defined(CONFIG_SERIAL_CONSOLE) +extern void console_setup(char *); +#endif + +extern struct ide_ops std_ide_ops; +extern struct kbd_ops std_kbd_ops; + +static void (*back_to_prom) (void) = (void (*)(void)) 0xbfc00000; + +static void ddb_machine_restart(char *command) +{ + u32 t; + + /* PCI cold reset */ + t = nile4_in32(NILE4_PCICTRL + 4); + t |= 0x40000000; + nile4_out32(NILE4_PCICTRL + 4, t); + /* CPU cold reset */ + t = nile4_in32(NILE4_CPUSTAT); + t |= 1; + nile4_out32(NILE4_CPUSTAT, t); + /* Call the PROM */ + back_to_prom(); +} + +static void ddb_machine_halt(void) +{ + printk("DDB Vrc-5074 halted.\n"); + do { + } while (1); +} + +static void ddb_machine_power_off(void) +{ + printk("DDB Vrc-5074 halted. Please turn off the power.\n"); + do { + } while (1); +} + +extern void ddb_irq_setup(void); + +extern void (*board_timer_setup) (struct irqaction * irq); + +void __init bus_error_init(void) +{ +} + +static void __init ddb_time_init(struct irqaction *irq) +{ + /* set the clock to 1 Hz */ + nile4_out32(NILE4_T2CTRL, 1000000); + /* enable the General-Purpose Timer */ + nile4_out32(NILE4_T2CTRL + 4, 0x00000001); + /* reset timer */ + nile4_out32(NILE4_T2CNTR, 0); + /* enable interrupt */ + setup_irq(nile4_to_irq(NILE4_INT_GPT), irq); + nile4_enable_irq(nile4_to_irq(NILE4_INT_GPT)); + change_cp0_status(ST0_IM, + IE_IRQ0 | IE_IRQ1 | IE_IRQ2 | IE_IRQ3 | IE_IRQ4); +} + +void __init ddb_setup(void) +{ + extern int panic_timeout; + + irq_setup = ddb_irq_setup; + set_io_port_base(NILE4_PCI_IO_BASE); + isa_slot_offset = NILE4_PCI_MEM_BASE; + board_timer_setup = ddb_time_init; + + _machine_restart = ddb_machine_restart; + _machine_halt = ddb_machine_halt; + _machine_power_off = ddb_machine_power_off; + +#ifdef CONFIG_BLK_DEV_IDE + ide_ops = &std_ide_ops; +#endif + +#ifdef CONFIG_PC_KEYB + kbd_ops = &std_kbd_ops; +#endif + + ddb_out32(DDB_BAR0, 0); + + ddb_set_pmr(DDB_PCIINIT0, DDB_PCICMD_IO, 0, 0x10); + ddb_set_pmr(DDB_PCIINIT1, DDB_PCICMD_MEM, DDB_PCI_MEM_BASE , 0x10); + +#ifdef CONFIG_FB + conswitchp = &dummy_con; +#endif + + /* Reboot on panic */ + panic_timeout = 180; +} + + +#define USE_NILE4_SERIAL 0 + +#if USE_NILE4_SERIAL +#define ns16550_in(reg) nile4_in8((reg)*8) +#define ns16550_out(reg, val) nile4_out8((reg)*8, (val)) +#else +#define NS16550_BASE (NILE4_PCI_IO_BASE+0x03f8) +static inline u8 ns16550_in(u32 reg) +{ + return *(volatile u8 *) (NS16550_BASE + reg); +} + +static inline void ns16550_out(u32 reg, u8 val) +{ + *(volatile u8 *) (NS16550_BASE + reg) = val; +} +#endif + +#define NS16550_RBR 0 +#define NS16550_THR 0 +#define NS16550_DLL 0 +#define NS16550_IER 1 +#define NS16550_DLM 1 +#define NS16550_FCR 2 +#define NS16550_IIR 2 +#define NS16550_LCR 3 +#define NS16550_MCR 4 +#define NS16550_LSR 5 +#define NS16550_MSR 6 +#define NS16550_SCR 7 + +#define NS16550_LSR_DR 0x01 /* Data ready */ +#define NS16550_LSR_OE 0x02 /* Overrun */ +#define NS16550_LSR_PE 0x04 /* Parity error */ +#define NS16550_LSR_FE 0x08 /* Framing error */ +#define NS16550_LSR_BI 0x10 /* Break */ +#define NS16550_LSR_THRE 0x20 /* Xmit holding register empty */ +#define NS16550_LSR_TEMT 0x40 /* Xmitter empty */ +#define NS16550_LSR_ERR 0x80 /* Error */ + + +void _serinit(void) +{ +#if USE_NILE4_SERIAL + ns16550_out(NS16550_LCR, 0x80); + ns16550_out(NS16550_DLM, 0x00); + ns16550_out(NS16550_DLL, 0x36); /* 9600 baud */ + ns16550_out(NS16550_LCR, 0x00); + ns16550_out(NS16550_LCR, 0x03); + ns16550_out(NS16550_FCR, 0x47); +#else + /* done by PMON */ +#endif +} + +void _putc(char c) +{ + while (!(ns16550_in(NS16550_LSR) & NS16550_LSR_THRE)); + ns16550_out(NS16550_THR, c); + if (c == '\n') { + while (!(ns16550_in(NS16550_LSR) & NS16550_LSR_THRE)); + ns16550_out(NS16550_THR, '\r'); + } +} + +void _puts(const char *s) +{ + char c; + while ((c = *s++)) + _putc(c); +} + +char _getc(void) +{ + while (!(ns16550_in(NS16550_LSR) & NS16550_LSR_DR)); + return ns16550_in(NS16550_RBR); +} + +int _testc(void) +{ + return (ns16550_in(NS16550_LSR) & NS16550_LSR_DR) != 0; +} + + +/* + * Hexadecimal 7-segment LED + */ +void ddb5074_led_hex(int hex) +{ + outb(hex, 0x80); +} + + +/* + * LEDs D2 and D3, connected to the GPIO pins of the PMU in the ALi M1543 + */ +struct pci_dev *pci_pmu = NULL; + +void ddb5074_led_d2(int on) +{ + u8 t; + + if (pci_pmu) { + pci_read_config_byte(pci_pmu, 0x7e, &t); + if (on) + t &= 0x7f; + else + t |= 0x80; + pci_write_config_byte(pci_pmu, 0x7e, t); + } +} + +void ddb5074_led_d3(int on) +{ + u8 t; + + if (pci_pmu) { + pci_read_config_byte(pci_pmu, 0x7e, &t); + if (on) + t &= 0xbf; + else + t |= 0x40; + pci_write_config_byte(pci_pmu, 0x7e, t); + } +} diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/arch/mips/kernel/i8259.c linux/arch/mips/kernel/i8259.c --- linux.orig/linux/arch/mips/kernel/i8259.c Sat Dec 29 07:07:11 2001 +++ linux/arch/mips/kernel/i8259.c Sun Mar 10 03:45:32 2002 @@ -176,12 +176,16 @@ handle_real_irq: if (irq & 8) { +#if 0 inb(0xA1); /* DUMMY - (do we need this?) */ +#endif outb(cached_A1,0xA1); outb(0x60+(irq&7),0xA0);/* 'Specific EOI' to slave */ outb(0x62,0x20); /* 'Specific EOI' to master-IRQ2 */ } else { +#if 0 inb(0x21); /* DUMMY - (do we need this?) */ +#endif outb(cached_21,0x21); outb(0x60+irq,0x20); /* 'Specific EOI' to master */ } diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/drivers/char/serial.c linux/drivers/char/serial.c --- linux.orig/linux/drivers/char/serial.c Wed Dec 19 01:03:10 2001 +++ linux/drivers/char/serial.c Mon Feb 25 16:45:27 2002 @@ -4393,6 +4393,7 @@ 8<<2, 2, pci_inteli960ni_fn, 0x10000}, { SPCI_FL_BASE0 | SPCI_FL_IRQRESOURCE, /* pbn_sgi_ioc3 */ 1, 458333, 0, 0, 0, 0x20178 }, +#if 0 #ifdef CONFIG_DDB5074 /* * NEC Vrc-5074 (Nile 4) builtin UART. @@ -4400,6 +4401,7 @@ */ { SPCI_FL_BASE0, 1, 520833, /* pbn_nec_nile4 */ 64, 3, NULL, 0x300 }, +#endif #endif #if 0 /* PCI_DEVICE_ID_DCI_PCCOM8 ? */ /* pbn_dci_pccom8 */ { SPCI_FL_BASE3, 8, 115200, 8 }, diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/drivers/net/tulip/interrupt.c linux/drivers/net/tulip/interrupt.c --- linux.orig/linux/drivers/net/tulip/interrupt.c Sun Dec 2 12:34:45 2001 +++ linux/drivers/net/tulip/interrupt.c Sun Mar 10 04:01:58 2002 @@ -186,6 +186,9 @@ tp->rx_buffers[entry].skb->tail, pkt_len); #endif +#if defined(__mips__) + dma_cache_inv((unsigned long)bus_to_virt(tp->rx_ring[entry].buffer1),pkt_len); +#endif } else { /* Pass up the skb already on the Rx ring. */ char *temp = skb_put(skb = tp->rx_buffers[entry].skb, pkt_len); diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/drivers/net/tulip/tulip_core.c linux/drivers/net/tulip/tulip_core.c --- linux.orig/linux/drivers/net/tulip/tulip_core.c Wed Jan 16 11:32:15 2002 +++ linux/drivers/net/tulip/tulip_core.c Sun Mar 10 04:03:46 2002 @@ -94,7 +94,7 @@ #elif defined(__arm__) || defined(__sh__) static int csr0 = 0x01A00000 | 0x4800; #elif defined(__mips__) -static int csr0 = 0x00200000 | 0x4000; +static int csr0 = 0x4000; #else #warning Processor architecture undefined! static int csr0 = 0x00A00000 | 0x4800; @@ -317,6 +317,11 @@ tp->tx_buffers[tp->cur_tx].skb = NULL; tp->tx_buffers[tp->cur_tx].mapping = mapping; +#if defined(__mips__) + dma_cache_wback_inv((unsigned long)tp->setup_frame, + sizeof(tp->setup_frame)); +#endif + /* Put the setup frame on the Tx list. */ tp->tx_ring[tp->cur_tx].length = cpu_to_le32(0x08000000 | 192); tp->tx_ring[tp->cur_tx].buffer1 = cpu_to_le32(mapping); @@ -620,6 +625,10 @@ PKT_BUF_SZ, PCI_DMA_FROMDEVICE); tp->rx_buffers[i].mapping = mapping; skb->dev = dev; /* Mark as being used by this device. */ +#if defined(__mips__) + /* Kick out any matching lines in the cache. */ + dma_cache_inv((unsigned long)skb->tail, PKT_BUF_SZ); +#endif tp->rx_ring[i].status = cpu_to_le32(DescOwned); /* Owned by Tulip chip */ tp->rx_ring[i].buffer1 = cpu_to_le32(mapping); } @@ -672,6 +681,9 @@ /* if we were using Transmit Automatic Polling, we would need a * wmb() here. */ tp->tx_ring[entry].status = cpu_to_le32(DescOwned); +#if defined(__mips__) + dma_cache_wback_inv((unsigned long)skb->data, skb->len); +#endif wmb(); tp->cur_tx++; @@ -1517,6 +1529,15 @@ /* No media table either */ tp->flags &= ~HAS_MEDIA_TABLE; } +#endif +#ifdef CONFIG_DDB5074 + if ((pdev->bus->number == 0) && (PCI_SLOT(pdev->devfn) == 1)) { + /* DDB5477 MAC address in first EEPROM locations. */ + sa_offset = 0; + /* No media table either */ + tp->flags &= ~HAS_MEDIA_TABLE; + } + #endif #ifdef CONFIG_MIPS_COBALT if ((pdev->bus->number == 0) && diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/include/asm-mips/ddb5xxx/ddb5074.h linux/include/asm-mips/ddb5xxx/ddb5074.h --- linux.orig/linux/include/asm-mips/ddb5xxx/ddb5074.h Thu Jan 1 01:00:00 1970 +++ linux/include/asm-mips/ddb5xxx/ddb5074.h Thu Feb 21 22:42:04 2002 @@ -0,0 +1,38 @@ +/* + * include/asm-mips/ddb5074.h -- NEC DDB Vrc-5074 definitions + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + */ + +#ifndef _ASM_DDB5XXX_DDB5074_H +#define _ASM_DDB5XXX_DDB5074_H + +#include + +#define DDB_SDRAM_SIZE 0x04000000 /* 64MB */ + +#define DDB_PCI_IO_BASE 0x06000000 +#define DDB_PCI_IO_SIZE 0x02000000 /* 32 MB */ + +#define DDB_PCI_MEM_BASE 0x08000000 +#define DDB_PCI_MEM_SIZE 0x08000000 /* 128 MB */ + +#define DDB_PCI_CONFIG_BASE DDB_PCI_MEM_BASE +#define DDB_PCI_CONFIG_SIZE DDB_PCI_MEM_SIZE + +#define NILE4_PCI_IO_BASE 0xa6000000 +#define NILE4_PCI_MEM_BASE 0xa8000000 +#define NILE4_PCI_CFG_BASE NILE4_PCI_MEM_BASE +#define DDB_PCI_IACK_BASE NILE4_PCI_IO_BASE + +#define NILE4_IRQ_BASE NUM_I8259_INTERRUPTS +#define CPU_IRQ_BASE (NUM_NILE4_INTERRUPTS + NILE4_IRQ_BASE) +#define CPU_NILE4_CASCADE 2 + +extern void ddb5074_led_hex(int hex); +extern void ddb5074_led_d2(int on); +extern void ddb5074_led_d3(int on); + +extern void nile4_irq_setup(u32 base); +#endif diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/include/asm-mips/ddb5xxx/ddb5xxx.h linux/include/asm-mips/ddb5xxx/ddb5xxx.h --- linux.orig/linux/include/asm-mips/ddb5xxx/ddb5xxx.h Thu Oct 11 00:41:52 2001 +++ linux/include/asm-mips/ddb5xxx/ddb5xxx.h Fri Mar 1 00:57:24 2002 @@ -174,8 +174,10 @@ static inline void ddb_sync(void) { +#if 0 volatile u32 *p = (volatile u32 *)0xbfc00000; (void)(*p); +#endif } static inline void ddb_out32(u32 offset, u32 val) diff -u -r -N -b -x *.o -x CVS -x .depend -x .config* -x .version -x .hdepend -x System.map -x .* linux.orig/linux/include/asm-mips/nile4.h linux/include/asm-mips/nile4.h --- linux.orig/linux/include/asm-mips/nile4.h Thu Sep 6 15:12:02 2001 +++ linux/include/asm-mips/nile4.h Mon Jan 14 14:10:26 2002 @@ -9,6 +9,9 @@ * NEC Vrc 5074 System Controller Data Sheet, June 1998 */ +#ifndef _ASM_NILE4_H +#define _ASM_NILE4_H + #define NILE4_BASE 0xbfa00000 #define NILE4_SIZE 0x00200000 /* 2 MB */ @@ -303,3 +306,4 @@ extern u8 nile4_i8259_iack(void); extern void nile4_dump_irq_status(void); /* Debug */ +#endif --82I3+IH0IqGh5yIs-- From owner-linux-mips@oss.sgi.com Wed Mar 13 21:27:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E5RDt25537 for linux-mips-outgoing; Wed, 13 Mar 2002 21:27:13 -0800 Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2E5R9925533 for ; Wed, 13 Mar 2002 21:27:09 -0800 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 13 Mar 2002 21:28:16 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id VAA06989 for ; Wed, 13 Mar 2002 21:28:37 -0800 (PST) Received: from broadcom.com (kwalker@dt-sj3-158 [10.21.64.158]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with ESMTP id VAA00169 for ; Wed, 13 Mar 2002 21:28:37 -0800 (PST) Message-ID: <3C903505.36BE8BCC@broadcom.com> Date: Wed, 13 Mar 2002 21:28:37 -0800 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: HIGHMEM bug X-WSS-ID: 108EEB7A4083630-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk After several days of hunting, I found a bug in the MIPS highmem code. A comparison of arch/mips/mm/init.c to arch/i386/mm/init.c supports my claim. The PGD entry for the fixed mapping virtual addresses is never allocated. So what happens is that the fixed mapping pte's get stuffed into the invalid_pte_table! Then, subsequent accesses that ought to fault might alias into these PTE's and get satisfied with somebody else's physical page. The following patch seems to help a great deal: Index: arch/mips/mm/init.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/init.c,v retrieving revision 1.38.2.4 diff -u -r1.38.2.4 init.c --- arch/mips/mm/init.c 2002/02/06 18:29:15 1.38.2.4 +++ arch/mips/mm/init.c 2002/03/14 05:25:12 @@ -206,6 +206,12 @@ #ifdef CONFIG_HIGHMEM /* + * Fixed mappings: + */ + vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK; + fixrange_init(vaddr, 0, pgd_base); + + /* * Permanent kmaps: */ vaddr = PKMAP_BASE; From owner-linux-mips@oss.sgi.com Thu Mar 14 02:22:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EAMxi32269 for linux-mips-outgoing; Thu, 14 Mar 2002 02:22:59 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EAMu932266 for ; Thu, 14 Mar 2002 02:22:56 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id g2EAONn07762 for ; Thu, 14 Mar 2002 11:24:23 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6LN4G2K; Thu, 14 Mar 2002 11:24:22 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Thu, 14 Mar 2002 11:24:22 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 11:24:18 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E7BA@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: More on serial console problem Date: Thu, 14 Mar 2002 11:24:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi. I have digged through my problem with the serial console and it seems that the TTY layer is calling the tty_driver.write function with parameter count=0x00 although the buffer contains a 0x0a. If I check for this 0x0a, send it to the serial port and return 1 (for on char sent) it works. But I don't why count is 0x00. It does not make sense and I have not found such a special check in any other driver. Does anybody have an idea what might go wrong here? best regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Thu Mar 14 05:51:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EDpem04259 for linux-mips-outgoing; Thu, 14 Mar 2002 05:51:40 -0800 Received: from coplin19.mips.com ([80.63.7.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EDpX904255 for ; Thu, 14 Mar 2002 05:51:33 -0800 Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g2EDqFO22168 for ; Thu, 14 Mar 2002 14:52:15 +0100 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Thu, 14 Mar 2002 14:52:15 +0100 (CET) From: Kjeld Borch Egevang To: linux-mips mailing list Subject: FPU inexact flag always set for dynamic programs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all. I've discovered that the inexact bit is always set at startup for a program. My test program fenvtest.c: #include #include int main() { int retval; retval = fetestexcept(FE_ALL_EXCEPT); printf("%d\n", retval); return 0; } And when I run: cc -o fenvtest fenvtest.c -lm ./fenvtest I get: 4 and: cc -o fenvtest fenvtest.c -lm -static ./fenvtest I get: 0 Is there something in /lib/ld.so.1 that invalidates the FP csr? /Kjeld -- _ _ ____ ___ Mailto:kjelde@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 | \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 Denmark http://www.mips.com/ From owner-linux-mips@oss.sgi.com Thu Mar 14 07:50:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EFoMY07799 for linux-mips-outgoing; Thu, 14 Mar 2002 07:50:22 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EFoF907788 for ; Thu, 14 Mar 2002 07:50:15 -0800 Message-Id: <200203141550.g2EFoF907788@oss.sgi.com> Received: (qmail 27112 invoked from network); 14 Mar 2002 15:58:28 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 14 Mar 2002 15:58:28 -0000 Date: Thu, 14 Mar 2002 23:52:54 +0800 From: Zhang Fuxin To: Kjeld Borch Egevang CC: "linux-mips@oss.sgi.com" Subject: Re: FPU inexact flag always set for dynamic programs X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2EFoF907789 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, >Is there something in /lib/ld.so.1 that invalidates the FP csr? maybe, I believe the root of problem is we don't clear used_math for new execed processes so they inherit fpu contents from their parent. Several days ago i posted a little patch to correct it,so your problem doesn't occurs here any more. but it seems Ralf doesn't accept it.Maybe you can try it. ÔÚ 2002-03-14 14:52:00 you wrote£º >Hi all. > >I've discovered that the inexact bit is always set at startup for a >program. My test program fenvtest.c: > >#include >#include > >int main() >{ > int retval; > > retval = fetestexcept(FE_ALL_EXCEPT); > printf("%d\n", retval); > return 0; >} > >And when I run: > >cc -o fenvtest fenvtest.c -lm >../fenvtest > >I get: > >4 > >and: > >cc -o fenvtest fenvtest.c -lm -static >../fenvtest > >I get: > >0 > >Is there something in /lib/ld.so.1 that invalidates the FP csr? > > >/Kjeld > >-- >_ _ ____ ___ Mailto:kjelde@mips.com >|\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 >| \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 > TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 > Denmark http://www.mips.com/ Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Thu Mar 14 09:23:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EHNkv15117 for linux-mips-outgoing; Thu, 14 Mar 2002 09:23:46 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EHNe915114 for ; Thu, 14 Mar 2002 09:23:40 -0800 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16lYyM-0001Py-00 for ; Thu, 14 Mar 2002 18:25:02 +0100 Date: Thu, 14 Mar 2002 18:25:02 +0100 From: Johannes Stezenbach To: linux-mips@oss.sgi.com Subject: Q: -mcpu= vs. -march= for VR41xx specific instructions Message-ID: <20020314172502.GA5365@convergence.de> Mail-Followup-To: Johannes Stezenbach , linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am trying to implement power management for an embedded device using a NEC VR4120 CPU core, which has the special instructions "standby", "suspend" and "hibernate". I use a toolchain based on binutils 2.12.90.0.1 and gcc 2.95.4-debian. To use that instructions I have to pass -march=vr4100 to the assembler. Unfortunately, -march and -mcpu cannot be used together, so first I changed arch/mips/Makefile from GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap to GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap This works, but I am unshure what the effects of the missing -mcpu switch are wrt the code generated by gcc. AFAICS the kernel still works, but is the generated code slower or subtly incorrect? Then I the tried to compile the kernel with the standard GCCFLAGS, setting -march=vr4100 only for the one file which contains the standby/suspend/hibernate instructions. This fails a link time with: mips-linux-ld: power.o: uses different e_flags (0x1100) fields than previous modules (0x1000) Bad value: failed to merge target specific data of file power.o I looked at an old arch/mips/Makefile from http://sourceforge.net/projects/linux-vr/, which has: CFLAGS += -mcpu=r4600 -mips2 -Wa,-m4100,--trap This does not work with my toolchain. So I think I need either: - make gas accept -march=vr4100 along with -mcpu=r4600 (or -mcpu=r4100?) - or have a ".set vr4100" directive to enable the vr41xx specific instructions where needed, without changing the flags in the ELF header - or make the linker link modules with different (but compatible) e_flags - or is "GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap" perfect? Please, does anybody have suggestions how to solve this issue? Regards, Johannes From owner-linux-mips@oss.sgi.com Thu Mar 14 09:46:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EHk7e15460 for linux-mips-outgoing; Thu, 14 Mar 2002 09:46:07 -0800 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EHk3915457 for ; Thu, 14 Mar 2002 09:46:03 -0800 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id g2EHlUp29506; Thu, 14 Mar 2002 12:47:30 -0500 Date: Thu, 14 Mar 2002 12:47:30 -0500 From: Jim Paris To: Johannes Stezenbach Cc: linux-mips@oss.sgi.com Subject: Re: Q: -mcpu= vs. -march= for VR41xx specific instructions Message-ID: <20020314124730.A29381@neurosis.mit.edu> Reply-To: jim@jtan.com References: <20020314172502.GA5365@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020314172502.GA5365@convergence.de>; from js@convergence.de on Thu, Mar 14, 2002 at 06:25:02PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I am trying to implement power management for an embedded > device using a NEC VR4120 CPU core, which has the special > instructions "standby", "suspend" and "hibernate". > So I think I need either: > - make gas accept -march=vr4100 along with -mcpu=r4600 (or -mcpu=r4100?) > - or have a ".set vr4100" directive to enable the vr41xx specific > instructions where needed, without changing the flags in the > ELF header > - or make the linker link modules with different (but compatible) e_flags > - or is "GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap" perfect? For lots of discussion of this, see http://sources.redhat.com/ml/binutils/2001-10/threads.html#00504 then http://sources.redhat.com/ml/binutils/2001-11/threads.html#00001 I don't remember where things currently stand. -jim From owner-linux-mips@oss.sgi.com Thu Mar 14 10:09:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EI9GV16127 for linux-mips-outgoing; Thu, 14 Mar 2002 10:09:16 -0800 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EI99916122 for ; Thu, 14 Mar 2002 10:09:09 -0800 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (SGI-8.9.3/8.9.3) with ESMTP id TAA24263 for ; Thu, 14 Mar 2002 19:10:31 +0100 (MET) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.34 #1 (Debian)) id 16lZgN-0001jg-00 for ; Thu, 14 Mar 2002 19:10:31 +0100 Date: Thu, 14 Mar 2002 19:10:31 +0100 To: linux-mips@oss.sgi.com Subject: Re: Q: -mcpu= vs. -march= for VR41xx specific instructions Message-ID: <20020314181031.GC398@rembrandt.csv.ica.uni-stuttgart.de> References: <20020314172502.GA5365@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020314172502.GA5365@convergence.de> User-Agent: Mutt/1.3.27i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Johannes Stezenbach wrote: [snip] > I use a toolchain based on binutils 2.12.90.0.1 and > gcc 2.95.4-debian. > > To use that instructions I have to pass -march=vr4100 > to the assembler. Unfortunately, -march and -mcpu cannot > be used together, so first I changed arch/mips/Makefile > from > GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap If this gcc already supports vr4100 you could use GCCFLAGS += -mcpu=vr4100 -mips2 -Wa,--trap > to > GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap > > This works, but I am unshure what the effects of the > missing -mcpu switch are wrt the code generated by gcc. > AFAICS the kernel still works, but is the generated > code slower or subtly incorrect? I don't know what the compiler does then. I assume it defaults to r3000 scheduling/opcodes. The assembler will emit vr4100 code scheduled for vr4100. If you still want r4600 scheduling (I doubt so), you could add -Wa,-mtune=r4600 to the GCCFLAGS line. [snip] > So I think I need either: > - make gas accept -march=vr4100 along with -mcpu=r4600 (or -mcpu=r4100?) -mcpu is deprecated and remains for backward compatibility to gcc < 3.0. it should be replaced by -march/-mtune. > - or have a ".set vr4100" directive to enable the vr41xx specific > instructions where needed, without changing the flags in the > ELF header I would suggest the syntax .set march=vr4100 This is in my TODO list for gas, but don't hold your breath. > - or make the linker link modules with different (but compatible) e_flags > - or is "GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap" perfect? > > > Please, does anybody have suggestions how to solve this issue? The real fix is to use a newer compiler (gcc >= 3). :-) Thiemo From owner-linux-mips@oss.sgi.com Thu Mar 14 10:33:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EIXjA16481 for linux-mips-outgoing; Thu, 14 Mar 2002 10:33:45 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EIXe916478 for ; Thu, 14 Mar 2002 10:33:40 -0800 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16la3c-0001XZ-00; Thu, 14 Mar 2002 19:34:32 +0100 Date: Thu, 14 Mar 2002 19:34:32 +0100 From: Johannes Stezenbach To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: Q: -mcpu= vs. -march= for VR41xx specific instructions Message-ID: <20020314183432.GA5802@convergence.de> Mail-Followup-To: Johannes Stezenbach , Thiemo Seufer , linux-mips@oss.sgi.com References: <20020314172502.GA5365@convergence.de> <20020314181031.GC398@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020314181031.GC398@rembrandt.csv.ica.uni-stuttgart.de> User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Mar 14, 2002 at 07:10:31PM +0100, Thiemo Seufer wrote: > Johannes Stezenbach wrote: > > GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap > > > > This works, but I am unshure what the effects of the > > missing -mcpu switch are wrt the code generated by gcc. > > AFAICS the kernel still works, but is the generated > > code slower or subtly incorrect? > > I don't know what the compiler does then. I assume it defaults to > r3000 scheduling/opcodes. How bad is that compared to -mcpu=vr4100? > I would suggest the syntax > > .set march=vr4100 > > This is in my TODO list for gas, but don't hold your breath. OK. > The real fix is to use a newer compiler (gcc >= 3). :-) Not too long ago people here told me that gcc 3.x is still not ready for production use. Or is gcc-3.1-pre from CVS ready for prime time? Thanks, Johannes From owner-linux-mips@oss.sgi.com Fri Mar 15 04:14:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FCEqa25623 for linux-mips-outgoing; Fri, 15 Mar 2002 04:14:52 -0800 Received: from i01sv4138.ids1.intelonline.com (i01sv4138-p.ids1.intelonline.com [147.208.166.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FCEk925619 for ; Fri, 15 Mar 2002 04:14:46 -0800 Received: from i01sv0649 (unverified [10.81.26.33]) by i01sv4138.ids1.intelonline.com (Rockliffe SMTPRA 4.5.4) with SMTP id for ; Fri, 15 Mar 2002 12:16:08 +0000 Message-ID: From: Guo-Rong Koh To: "linux-mips@oss.sgi.com" X-Originating-IP: [63.12.14.168] Date: Fri, 15 Mar 2002 22:16:08 +1030 X-MSMail-Priority: Normal X-mailer: AspMail 4.0 4.02 (SMT4DD4B4F) Subject: DECStation kernel boot failure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all, Still trying to get Linux on my DECStation 5000/25. I have attached the boot (fail) log in case anyone can tell me what's going (not) on. Thanks, Guo-Rong --kernel boot dump starts here-- KN02-CA V2.0m >>boot 3/rz0/vmlinux - root=/dev/nfs nfsroot=192.168.2.145:/mips ip=bootp NetBSD/pmax 1.5.1 FFS Primary Bootstrap NetBSD/pmax 1.5.2 Secondary Bootstrap, Revision 1.3 (root@medusa.thistledown.com.au, Aug 23 10:47:54 EST 2001) Boot: 3/rz0/vmlinux 2224128+172576 [186+159728+155633]=0x296614 Starting at 0x80040464 This DECstation is a Personal DS5000/xx CPU revision is: 00000230 FPU revision is: 00000340 Primary instruction cache 64kb, linesize 4 bytes Primary data cache 64kb, linesize 4 bytes Linux version 2.4.16 (root@elrond) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-96.1)) #7 Sun Dec 23 14:57:24 MET 2001 Determined physical RAM map: memory: 01000000 @ 00000000 (usable) On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/nfs nfsroot=192.168.2.145:/mips ip=bootp Calibrating delay loop... 24.87 BogoMIPS Memory: 13520k/16384k available (2007k kernel code, 2864k reserved, 87k data, 76k init) Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Kernel panic: can't allocate root vfsmount In idle task - not syncing --kernel boot dump finishes here-- __________________________________________________________________ Get your free Australian email account at http://www.start.com.au From owner-linux-mips@oss.sgi.com Fri Mar 15 04:46:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FCk5T26784 for linux-mips-outgoing; Fri, 15 Mar 2002 04:46:05 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FCju926780 for ; Fri, 15 Mar 2002 04:45:56 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id B0A029EFE; Fri, 15 Mar 2002 13:47:23 +0100 (CET) Date: Fri, 15 Mar 2002 13:47:23 +0100 From: Jan-Benedict Glaw To: "linux-mips@oss.sgi.com" Subject: Re: DECStation kernel boot failure Message-ID: <20020315124723.GZ25044@lug-owl.de> Mail-Followup-To: "linux-mips@oss.sgi.com" References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JVVqWhpkAs5raV7A" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --JVVqWhpkAs5raV7A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2002-03-15 22:16:08 +1030, Guo-Rong Koh wrote in message : > --kernel boot dump starts here-- > KN02-CA V2.0m =20 > >>boot 3/rz0/vmlinux - root=3D/dev/nfs nfsroot=3D192.168.2.145:/mips > ip=3Dbootp >=20 > NetBSD/pmax 1.5.1 FFS Primary Bootstrap >=20 > NetBSD/pmax 1.5.2 Secondary Bootstrap, Revision 1.3 > (root@medusa.thistledown.com.au, Aug 23 10:47:54 EST 2001) >=20 > Boot: 3/rz0/vmlinux > 2224128+172576 [186+159728+155633]=3D0x296614 > Starting at 0x80040464 >=20 > This DECstation is a Personal DS5000/xx > CPU revision is: 00000230 > FPU revision is: 00000340 > Primary instruction cache 64kb, linesize 4 bytes > Primary data cache 64kb, linesize 4 bytes > Linux version 2.4.16 (root@elrond) (gcc version 2.96 20000731 (Red Hat > Linux 7.1 2.96-96.1)) #7 Sun Dec 23 14:57:24 MET 2001 > Determined physical RAM map: > memory: 01000000 @ 00000000 (usable) > On node 0 totalpages: 4096 > zone(0): 4096 pages. > zone(1): 0 pages. > zone(2): 0 pages. > Kernel command line: root=3D/dev/nfs nfsroot=3D192.168.2.145:/mips > ip=3Dbootp Command line looks good to me. > Calibrating delay loop... 24.87 BogoMIPS > Memory: 13520k/16384k available (2007k kernel code, 2864k reserved, > 87k data, 76k init) > Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) > Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > Kernel panic: can't allocate root vfsmount > In idle task - not syncing > --kernel boot dump finishes here-- You attempt to do nfsroot, but I can't see that your network card has been detected. Are you sure you've included it into kernel compile? If not, do so... MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --JVVqWhpkAs5raV7A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyR7VoACgkQHb1edYOZ4bsRvgCfUwvGZeHgB+EFhxwN7m0mp9pA D1cAn3Yo8JsQJraE1PvVV52zefeKR0KU =oAEn -----END PGP SIGNATURE----- --JVVqWhpkAs5raV7A-- From owner-linux-mips@oss.sgi.com Fri Mar 15 05:23:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FDNK128170 for linux-mips-outgoing; Fri, 15 Mar 2002 05:23:20 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FDND928167 for ; Fri, 15 Mar 2002 05:23:14 -0800 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.9.3) with ESMTP id g2FDOUg00607; Fri, 15 Mar 2002 14:24:30 +0100 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id OAA18816; Fri, 15 Mar 2002 14:24:30 +0100 (MET) Message-Id: <200203151324.OAA18816@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Jan-Benedict Glaw cc: linux-mips@oss.sgi.com Subject: Re: DECStation kernel boot failure In-reply-to: Your message of "Fri, 15 Mar 2002 13:47:23 +0100." <20020315124723.GZ25044@lug-owl.de> Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Mar 2002 14:24:30 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jan-Benedict Glaw wrote: > On Fri, 2002-03-15 22:16:08 +1030, Guo-Rong Koh > wrote in message : > > .... > > This DECstation is a Personal DS5000/xx > > CPU revision is: 00000230 > > FPU revision is: 00000340 > > Primary instruction cache 64kb, linesize 4 bytes > > Primary data cache 64kb, linesize 4 bytes > > Linux version 2.4.16 (root@elrond) (gcc version 2.96 20000731 (Red Hat > > Linux 7.1 2.96-96.1)) #7 Sun Dec 23 14:57:24 MET 2001 > > Determined physical RAM map: > > memory: 01000000 @ 00000000 (usable) > > On node 0 totalpages: 4096 > > zone(0): 4096 pages. > > zone(1): 0 pages. > > zone(2): 0 pages. > > Kernel command line: root=/dev/nfs nfsroot=192.168.2.145:/mips > > ip=bootp > > Command line looks good to me. > > > Calibrating delay loop... 24.87 BogoMIPS > > Memory: 13520k/16384k available (2007k kernel code, 2864k reserved, > > 87k data, 76k init) > > Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) > > Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) > > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > > Kernel panic: can't allocate root vfsmount > > In idle task - not syncing > > --kernel boot dump finishes here-- > > You attempt to do nfsroot, but I can't see that your network card > has been detected. Are you sure you've included it into kernel > compile? If not, do so... He uses my kernel image. I'm sure I've included the DECStation 5000 ethernet card, because the same image works OK on other DECStations. I don't have access to a 5000/25 however. Regards, Karel. -- 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 Fri Mar 15 05:48:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FDma528967 for linux-mips-outgoing; Fri, 15 Mar 2002 05:48:36 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FDmQ928964 for ; Fri, 15 Mar 2002 05:48:26 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 4B2B49EFE; Fri, 15 Mar 2002 14:49:54 +0100 (CET) Date: Fri, 15 Mar 2002 14:49:54 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: DECStation kernel boot failure Message-ID: <20020315134953.GB25044@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020315124723.GZ25044@lug-owl.de> <200203151324.OAA18816@sparta.research.kpn.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="309evMHi/619oHyA" Content-Disposition: inline In-Reply-To: <200203151324.OAA18816@sparta.research.kpn.com> User-Agent: Mutt/1.3.27i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --309evMHi/619oHyA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2002-03-15 14:24:30 +0100, Houten K.H.C. van (Karel) wrote in message <200203151324.OAA18816@sparta.research.kpn.com>: > Jan-Benedict Glaw wrote: > > On Fri, 2002-03-15 22:16:08 +1030, Guo-Rong Koh > > wrote in message : > > > .... > > > This DECstation is a Personal DS5000/xx > > > CPU revision is: 00000230 > > > FPU revision is: 00000340 > > > Primary instruction cache 64kb, linesize 4 bytes > > > Primary data cache 64kb, linesize 4 bytes > > > Linux version 2.4.16 (root@elrond) (gcc version 2.96 20000731 (Red Hat > > > Linux 7.1 2.96-96.1)) #7 Sun Dec 23 14:57:24 MET 2001 > > > Determined physical RAM map: > > > memory: 01000000 @ 00000000 (usable) > > > On node 0 totalpages: 4096 > > > zone(0): 4096 pages. > > > zone(1): 0 pages. > > > zone(2): 0 pages. > > > Kernel command line: root=3D/dev/nfs nfsroot=3D192.168.2.145:/mips > > > ip=3Dbootp > >=20 > > Command line looks good to me. > >=20 > > > Calibrating delay loop... 24.87 BogoMIPS > > > Memory: 13520k/16384k available (2007k kernel code, 2864k reserved, > > > 87k data, 76k init) > > > Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) > > > Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) > > > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > > > Kernel panic: can't allocate root vfsmount > > > In idle task - not syncing > > > --kernel boot dump finishes here-- > >=20 > > You attempt to do nfsroot, but I can't see that your network card > > has been detected. Are you sure you've included it into kernel > > compile? If not, do so... >=20 > He uses my kernel image. I'm sure I've included the DECStation 5000 > ethernet card, because the same image works OK on other DECStations. > I don't have access to a 5000/25 however. =2E..but Linux doesn't recognize the NIC on this box. Karel, digging unto deep layers of my bad memory I can remember that some DECstations had a different NIC or different way to access it or so. I've got some different DECstations, but there's one which I cannot really use because of lacking support for the nic. The box was supported at some time (there at least exists some old hacked network driver for 2.1.53 or so), but I do no longer have access to the file (my laptop was stolen this week and the driver was in my TODO directory, not backup'ed:-( MfG, JBG PS: However, the NIC isn't found, so the kernel cannot boot off nfsroot. --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --309evMHi/619oHyA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyR/AEACgkQHb1edYOZ4buAxACeJzLarV/FFKkHSXfiZIBBoB3i fcsAni0fjN+t2wzykcyoCks5iGDF1nwi =83Jf -----END PGP SIGNATURE----- --309evMHi/619oHyA-- From owner-linux-mips@oss.sgi.com Fri Mar 15 14:37:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FMbEe16223 for linux-mips-outgoing; Fri, 15 Mar 2002 14:37:14 -0800 Received: from imo-m01.mx.aol.com (imo-m01.mx.aol.com [64.12.136.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FMb4916203; Fri, 15 Mar 2002 14:37:05 -0800 Received: from rep2hon@netscape.net by imo-m01.mx.aol.com (mail_out_v32.5.) id c.2c.34545c0 (22682) for ; Fri, 15 Mar 2002 17:22:33 -0500 (EST) Received: from netscape.com (mow-d01.webmail.aol.com [205.188.138.65]) by air-in04.mx.aol.com (v83.45) with ESMTP id MAILININ43-0315172231; Fri, 15 Mar 2002 17:22:31 -0500 Date: Fri, 15 Mar 2002 17:22:31 -0500 From: rep2hon@netscape.net To: sed@qa.nl Subject: URGENT: CO-OPERATION AND PARTNERSHIP Message-ID: <3832F0BB.259A5EC0.00213586@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk DEAR SIR, URGENT: CO-OPERATION AND PARTNERSHIP I URGENTLY NEED YOUR CO-OPERATION AND URGENT PARTNERSHIP. IT MIGHT SOUND STRANGE THAT DESPITE THE FACT THAT I AM SEEKING YOUR ASSISTANCE AND PATRTNERSHIP YET I AM A LITTLE BIT JITTERY DISCLOSSING MY IDENTITY. PLEASE BEAR WITH ME BECAUSE I AM DOING THIS TO PROTECT MY PERSONALITY AND POSITION AND WOULD DISCLOSE EVERY BIT OF DETAIL TO YOU WHEN I AM WELL ASSURED THAT YOU ARE MY FRIEND AND PARTNER. I AM A LAWMAKER (A MEMBER OF THE NATIONAL ASSEMBLY) AND URGENTLY NEED YOUR TIMELY ASSISTANCE TO JOIN ME EXECUTE THIS DEAL. WHILE CARRYING OUT VERIFICATION EXERCISES AS MANDATED BY THE COMMITTEE ON CONTRACT PAYMENT VERIFICATION, WHICH I AM PRESIDING OVER, I DISCOVERED VARIOUS FUNDS RANGING FROM $68,000,000 TO OVER $290,000,000 WHICH WERE NOT LINKED TO SPECIFIC CONTRACTORS. HOWEVER, AFTER INVESTIGATIONS A STAFF AND CLOSE ASSOCIATE TO THE LATE HEAD OF STATE CONFIDED IN ME AND DISCLOSED TO ME THAT THIS FUNDS WERE SECURED BY THE LATE HEAD OF STATE AND PURPORTED TO HAVE BEEN DUE CONTRATORS AND HE WAS TO MOVE THIS FUNDS TO HIS FOREGN ACCOUNTS. BUT DUE TO THE DEMISE OF THE LATE OF HEAD OF STATE NO ONE COULD FINISH THE JOB DUE TO LACK OF KNOWLEDGE OF THIS FUND UNTIL NOW. HAVING DISCOVERED THIS AND HAVING GOT HOLD OF CRUCIAL DOCUMENTS WE HAVE DECIDED TO DESTROY ANY LEAD TO THE REAL SOURCE OF THE FUND AND IMPLANT INFORMATION THAT WOULD ENABLE US TRANSFER THIS FUND WITH YOUR AID FOR OUR PRIVATE USE. THEREFORE, I AM CALLING ON YOU TO GIVE YOUR SINCERE CONSENT AND COOPERATION SO THAT WE WOULD ALL BENEFIT FROM THIS REAR DISCOVERY. PLEASE NOTE THAT I WOULD LET YOU KNOW WHO I AM AFTER I AM VERY WELL ASSURED THAT I AM SAFE DEALING WITH YOU. FOR FURTHER NEGOTIATION AND DISCUSSIONS PLEASE REACH ME VIA THIS EMAIL ADDRESS (I.E THE SAME EMAIL ADDRESS I WROTE YOU THROUGH) YOURS TRULY, HON. -- __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From owner-linux-mips@oss.sgi.com Fri Mar 15 22:43:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G6hVj25265 for linux-mips-outgoing; Fri, 15 Mar 2002 22:43:31 -0800 Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2G6hQ925258 for ; Fri, 15 Mar 2002 22:43:27 -0800 Received: from hermes.excalibur.cologne.de (pec-41-158.tnt4.f.uunet.de [149.225.41.158]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id HAA29645 for ; Sat, 16 Mar 2002 07:43:29 +0100 (MET) Received: from karsten by hermes.excalibur.cologne.de with local (Exim 3.34 #1 (Debian)) id 16lxrf-0000nE-00 for ; Fri, 15 Mar 2002 20:59:47 +0100 Date: Fri, 15 Mar 2002 20:59:46 +0100 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: DECStation kernel boot failure Message-ID: <20020315195946.GA3020@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com References: <20020315124723.GZ25044@lug-owl.de> <200203151324.OAA18816@sparta.research.kpn.com> <20020315134953.GB25044@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020315134953.GB25044@lug-owl.de> User-Agent: Mutt/1.3.27i X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Mar 15, 2002 at 02:49:54PM +0100, Jan-Benedict Glaw wrote: > On Fri, 2002-03-15 14:24:30 +0100, Houten K.H.C. van (Karel) > wrote in message <200203151324.OAA18816@sparta.research.kpn.com>: [SNIP] > > He uses my kernel image. I'm sure I've included the DECStation 5000 > > ethernet card, because the same image works OK on other DECStations. > > I don't have access to a 5000/25 however. > > ...but Linux doesn't recognize the NIC on this box. Karel, digging > unto deep layers of my bad memory I can remember that some DECstations > had a different NIC or different way to access it or so. I've got > some different DECstations, but there's one which I cannot really > use because of lacking support for the nic. The box was supported > at some time (there at least exists some old hacked network driver > for 2.1.53 or so), but I do no longer have access to the file (my > laptop was stolen this week and the driver was in my TODO directory, > not backup'ed:-( That was the LANCE driver for the 5000/200, which is different from the driver for all the 5000/xx, /1xx, /240 and /260. The Maxine should work with the default declance.c from the CVS. Regards, Karsten -- Gemaess Par. 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung und der Weitergabe meiner Daten zum Zwecke der Werbung sowie der Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Sat Mar 16 03:30:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GBU1j29129 for linux-mips-outgoing; Sat, 16 Mar 2002 03:30:01 -0800 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2GBTu929124 for ; Sat, 16 Mar 2002 03:29:56 -0800 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 777A72B31C; Sat, 16 Mar 2002 11:31:19 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id D9413E953; Sat, 16 Mar 2002 11:31:18 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id BBE247243; Sat, 16 Mar 2002 11:31:18 +0000 (GMT) Date: Sat, 16 Mar 2002 11:31:18 +0000 (GMT) From: Dave Airlie X-X-Sender: To: Karsten Merker Cc: Subject: Re: DECStation kernel boot failure In-Reply-To: <20020315195946.GA3020@excalibur.cologne.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > That was the LANCE driver for the 5000/200, which is different from > the driver for all the 5000/xx, /1xx, /240 and /260. The Maxine > should work with the default declance.c from the CVS. Does the copy on my website still work ? http://www.skynet.ie/~airlied/mips/declance_2_3_48.c It was never merged as to do it properly required a re-write of the driver, which I never got around to, and I only had a DS5000/200, I still have one, but no build system at the moment ... Dave. > > Regards, > Karsten > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Sat Mar 16 14:12:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GMCQE13753 for linux-mips-outgoing; Sat, 16 Mar 2002 14:12:26 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2GMCK913750 for ; Sat, 16 Mar 2002 14:12:20 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 0125D9EDF; Sat, 16 Mar 2002 23:13:46 +0100 (CET) Date: Sat, 16 Mar 2002 23:13:46 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: DECStation kernel boot failure Message-ID: <20020316221346.GE25044@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020315195946.GA3020@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sxUMTo9WXJrtNoGr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --sxUMTo9WXJrtNoGr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2002-03-16 11:31:18 +0000, Dave Airlie wrote in message : > > That was the LANCE driver for the 5000/200, which is different from >=20 > Does the copy on my website still work ? >=20 > http://www.skynet.ie/~airlied/mips/declance_2_3_48.c >=20 > It was never merged as to do it properly required a re-write of the > driver, which I never got around to, and I only had a DS5000/200, I still > have one, but no build system at the moment ... When I looked at that driver, the diff was quite small and only included changes to in-driver code parts. So I _think_ it could even run these days. I started to work on it some year ago, but my changes are lost now - my laptop was stolen this week. However, I think it could run. I can try to compile a kernel with this driver, there's a running toolchain here:-) MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --sxUMTo9WXJrtNoGr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyTw5kACgkQHb1edYOZ4bubvACfdg0OiCPd3z2XvgimQLLGAkyp fxAAn0DCAIrUvHemiwM9WS2FkRmv2ZLx =SgTO -----END PGP SIGNATURE----- --sxUMTo9WXJrtNoGr-- From owner-linux-mips@oss.sgi.com Sat Mar 16 17:29:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2H1T2P16970 for linux-mips-outgoing; Sat, 16 Mar 2002 17:29:02 -0800 Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2H1Sx916967 for ; Sat, 16 Mar 2002 17:28:59 -0800 Received: from girishvg (AUTH login) at g054140.ppp.asahi-net.or.jp (HELO nazneen) (girishvg@211.132.54.140) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Mar 2002 01:30:27 -0000 Message-ID: <00f601c1cd53$9c862060$8c3684d3@gol.com> From: "Girish Gulawani" To: "MIPS/Linux List \(SGI\)" Subject: Error loading shared libraries. Date: Sun, 17 Mar 2002 10:32:30 +0900 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 Hello, all. I know this is kind of weird problem at this point of time. I have a MIPS board booted up with Linux 2.4.3 kernel. But it fails on the "init". I get an error in the init process: init: error in loading shared libraries libutil.so.1: cannot map file data: Bad file descriptor ... The compiler used is EGCS 2.91.66, downloaded from the net. Such error is seen while loading any executable. I have a statically linked shell running. Basically I dont know where the problem is. Please help me. Many thanks in advance. Girish. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Sat Mar 16 17:36:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2H1aD317103 for linux-mips-outgoing; Sat, 16 Mar 2002 17:36:13 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2H1a2917099 for ; Sat, 16 Mar 2002 17:36:03 -0800 Received: from prefect (prefect.local [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id 47025590B2; Sat, 16 Mar 2002 20:32:59 -0500 (EST) Message-ID: <01dc01c1cd54$73281c40$5601010a@prefect> From: "Bradley D. LaRonde" To: "Girish Gulawani" , "MIPS/Linux List (SGI)" References: <00f601c1cd53$9c862060$8c3684d3@gol.com> Subject: Re: Error loading shared libraries. Date: Sat, 16 Mar 2002 20:38:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Girish Gulawani" To: "MIPS/Linux List (SGI)" Sent: Saturday, March 16, 2002 8:32 PM Subject: Error loading shared libraries. > > Hello, all. > I know this is kind of weird problem at this point of time. I have a MIPS > board booted up with Linux 2.4.3 kernel. But it fails on the "init". I get > an error in the init process: > > init: error in loading shared libraries > libutil.so.1: cannot map file data: Bad file descriptor ... > > The compiler used is EGCS 2.91.66, downloaded from the net. What glibc? Could this be the MIPS base address bug? Maybe this patch by H. J. Lu. (updated by me) will help: http://www.ltc.com/~brad/mips/glibc-2.2.3-mips-base-addr-got.diff Regards, Brad From owner-linux-mips@oss.sgi.com Sat Mar 16 19:25:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2H3PrM19180 for linux-mips-outgoing; Sat, 16 Mar 2002 19:25:53 -0800 Received: from smtp.livedoor.com (13.131.104.203.livedoor.com [203.104.131.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2H3Po919174 for ; Sat, 16 Mar 2002 19:25:51 -0800 Received: (qmail 19120 invoked from network); 17 Mar 2002 12:27:07 +0900 Received: from unknown (HELO jobin.livedoor.com) (61.198.8.90) by prx6.livedoor.com with SMTP; 17 Mar 2002 12:27:07 +0900 Message-Id: <5.0.2.5.2.20020317113440.00c74650@pop3.livedoor.com> X-Sender: job21@pop3.livedoor.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Sun, 17 Mar 2002 11:34:51 +0900 To: (Recipient list suppressed) From: info Subject: =?ISO-2022-JP?B?GyRCISo5LTlwISpFPj8mJTUhPCVTJTkhSkw1TkEbKEI=?= =?ISO-2022-JP?B?GyRCIUsbKEI=?= Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk $B!J9-9p!K(B $BA49q$N?M:`%P%s%/$XE>?&$N(B $B0l3g%(%s%H%j!&; Sun, 17 Mar 2002 01:02:17 -0800 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.9.3) with ESMTP id g2H93ip21618; Sun, 17 Mar 2002 10:03:44 +0100 Received: (from karel@localhost) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) id KAA13373; Sun, 17 Mar 2002 10:03:44 +0100 (MET) From: Karel van Houten Message-Id: <200203170903.KAA13373@sparta.research.kpn.com> Subject: Re: DECStation kernel boot failure To: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Sun, 17 Mar 2002 10:03:44 +0100 (MET) Cc: linux-mips@oss.sgi.com In-Reply-To: <20020316221346.GE25044@lug-owl.de> from "Jan-Benedict Glaw" at Mar 16, 2002 11:13:46 PM X-Url: http://www-lsdm.research.kpn.com/~karel X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > Does the copy on my website still work ? > > > > http://www.skynet.ie/~airlied/mips/declance_2_3_48.c > > > > It was never merged as to do it properly required a re-write of the > > driver, which I never got around to, and I only had a DS5000/200, I still > > have one, but no build system at the moment ... > > When I looked at that driver, the diff was quite small and only > included changes to in-driver code parts. So I _think_ it could > even run these days. I started to work on it some year ago, but > my changes are lost now - my laptop was stolen this week. It does still work with 2.4.16 / 2.4.17. It's included in my precompiled DS5000/200 kernels at my website. -- 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 Sun Mar 17 02:51:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HApjo26388 for linux-mips-outgoing; Sun, 17 Mar 2002 02:51:45 -0800 Received: from coplin09.mips.com ([80.63.7.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2HApY926383 for ; Sun, 17 Mar 2002 02:51:34 -0800 Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g2HAqGb27844 for linux-mips@oss.sgi.com; Sun, 17 Mar 2002 11:52:16 +0100 From: Hartvig Ekner Message-Id: <200203171052.g2HAqGb27844@coplin09.mips.com> Subject: Compiler problem in glibc To: linux-mips@oss.sgi.com (user alias) Date: Sun, 17 Mar 2002 11:52:15 +0100 (CET) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have found a problem in glibc caused by the gcc-2.96-99.1 compiler from H.J's miniport. in the exp() function (file w_expf.c), there is code like: #ifdef __STDC__ float __expf(float x) /* wrapper expf */ #else float __expf(x) /* wrapper expf */ float x; #endif { #ifdef _IEEE_LIBM return __ieee754_expf(x); #else float z; z = __ieee754_expf(x); if(_LIB_VERSION == _IEEE_) return z; if(__finitef(x)) { if(x>o_threshold) (IEEE_LIBM is not set). Note that there are two function calls (ieee754_expf and finitef()) followed by a FP if-statement (x>o_threshold). This translates into: 00400570 <__expf>: 400570: 3c1c0fc1 lui gp,0xfc1 400574: 279cc090 addiu gp,gp,-16240 400578: 0399e021 addu gp,gp,t9 40057c: 27bdffc8 addiu sp,sp,-56 400580: afbc0018 sw gp,24(sp) 400584: e7b60030 swc1 $f22,48(sp) 400588: e7b70034 swc1 $f23,52(sp) 40058c: e7b40028 swc1 $f20,40(sp) 400590: e7b5002c swc1 $f21,44(sp) 400594: afbf0024 sw ra,36(sp) 400598: 46006506 mov.s $f20,$f12 40059c: afbc0020 sw gp,32(sp) 4005a0: 8f998630 lw t9,-31184(gp) 4005a4: 00000000 nop 4005a8: 0320f809 jalr t9 __ieee754_expf 4005ac: 00000000 nop 4005b0: 8fbc0018 lw gp,24(sp) 4005b4: 00000000 nop 4005b8: 8f8388f4 lw v1,-30476(gp) 4005bc: 00000000 nop 4005c0: 8c630000 lw v1,0(v1) 4005c4: 2402ffff li v0,-1 4005c8: 46000586 mov.s $f22,$f0 4005cc: 1062002d beq v1,v0,400684 <__expf+0x114> 4005d0: 4600a306 mov.s $f12,$f20 4005d4: 8f9986d0 lw t9,-31024(gp) 4005d8: 00000000 nop 4005dc: 0320f809 jalr t9 finitef() 4005e0: 00000000 nop 4005e4: 8fbc0018 lw gp,24(sp) 4005e8: 00000000 nop 4005ec: 3c0142b1 lui at,0x42b1 4005f0: 34217180 ori at,at,0x7180 4005f4: 44810000 mtc1 at,$f0 4005f8: 00000000 nop 4005fc: 4614003c c.lt.s $f0,$f20 Wow!!!! ... 400608: 1040001e beqz v0,400684 <__expf+0x114> 40060c: 4600b006 mov.s $f0,$f22 400610: 4500000b bc1f 400640 <__expf+0xd0> Note that the c.lt.s (from the FP compare) is done before the finitef() value has been checked (beqz in 400608). This particular issue causes the wrong setting of bits in the FPU SR in some cases (with exp(nan)), and "make check" in glibc to fail. BTW, the "make check" in glibc has so far turned up a few other items in glibc as well as in the kernel (FPU emulator), which are being fixed. /Hartvig -- _ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com |\ /| | |____)(____ Direct: +45 4486 5503 | \/ | | | _____) MIPS Denmark Switch: +45 4486 5555 T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556 From owner-linux-mips@oss.sgi.com Sun Mar 17 10:31:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HIV6j04989 for linux-mips-outgoing; Sun, 17 Mar 2002 10:31:06 -0800 Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2HIUk904985 for ; Sun, 17 Mar 2002 10:30:46 -0800 Received: from hanishkvc (AUTH plain) at unknown (HELO yahoo.com) (hanishkvc@202.71.151.48) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Mar 2002 18:32:02 -0000 Message-ID: <3C94E20C.9080405@yahoo.com> Date: Mon, 18 Mar 2002 00:05:56 +0530 From: C Hanish Menon Reply-To: hanishkvc@yahoo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips kernel , linux-mips-kernel@lists.sourceforge.net CC: hanishkvc@fedtec.com Subject: Bug in (binutils-mipsel-linux-2.9.5-3 + egcs-mipsel-linux-1.1.2-4) - Also any suggestion for binutils/gcc versions to use for mips. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Sometime back I had ported Linux to LSI's SC2005 (TinyMips core with Mips1 and some Mips2 instructions) based board as part of my work. We wanted to release the code to opensource. However we found a bug in the code that it was corrupting the softirq's pending, which I wanted to fix before releaseing to opensource. At that time I temporarily fixed the problem by checking that the softirq is pointing to a proper logic rather than 0 before calling it. Recently I found time to look into the problem, and found the code generated by the compiler is wrong, in that instead of setting the ksoftirqd_task element of the irq_stat structure its setting the pending element, thus causing the system to crash. As mentioned in the subject I was using binutils-mipsel-linux-2.95.3 and egcs-mipsel-linux-1.1.2-4 binary packages from oss.sgi.com on a Redhat 7.2 system. To show the problem I added some test code into the kernel/softirq.c file, as can be noted from the code below the compiler generates proper code in certain places, but wrong code at other instances: ----------------------------------------------------------------------------- binutils-mipsel-linux-2.9.5-3 egcs-mipsel-linux-1.1.2-4 ******************************* ISSUE 1 **************************** Location of irq_stat[] ---------------------- 00000000800f5d38 g F .text 00000000000000d8 __tcp_mem_reclaim 00000000801614d0 g O .data 0000000000000020 irq_stat 00000000800820dc g F .text 0000000000000034 show_buffers ************************************************ In ksoftirqd function /** The actual code - wrong code generated **/ --------------------- ksoftirqd_task(cpu) = current; /* added by me */ debugkvc_softirq_pending("ksoftirqd: before for"); for (;;) { if (!softirq_pending(cpu)) 0000000080059b38 : 80059bf0: 3c108016 lui $s0,0x8016 80059bf4: 261014d0 addiu $s0,$s0,5328 80059bf8: 0c01667e jal 800599f8 80059bfc: ae1c0000 sw $gp,0($s0) /** NOTE ksoftirqd_task offset is wrong **/ 80059c00: 2610fff0 addiu $s0,$s0,-16 /** Nice way to calculate the pending element offset but its wrong has the ksoftirqd_task element offset itself is wrong **/ 80059c04: 8e020000 lw $v0,0($s0) /** as mentioned above the pending element offset wrong **/ 80059c08: 00000000 nop 80059c0c: 14400003 bnez $v0,80059c1c ************************************************ void debugkvc_show_gcc_bug_1(void) /* Test case 1 - Proper code generated */ { int cpu = smp_processor_id(); int pending; /* TEMPORARY TO SHOW THE CROSS GCC bUg */ pending = softirq_pending(cpu); pending += 1; softirq_pending(cpu) = pending; ksoftirqd_task(cpu) = current; /* END */ } 0000000080059994 : 80059994: 3c038016 lui $v1,0x8016 80059998: 246314d0 addiu $v1,$v1,5328 8005999c: 8c620000 lw $v0,0($v1) 800599a0: ac7c0010 sw $gp,16($v1) /** Proper offset for ksoftirqd_task element **/ 800599a4: 24420001 addiu $v0,$v0,1 800599a8: 03e00008 jr $ra 800599ac: ac620000 sw $v0,0($v1) ************************************************ void debugkvc_show_gcc_bug_3(void) /* Test case 2 - WRONG code generated */ { int cpu = smp_processor_id(); /* TEMPORARY TO SHOW THE CROSS GCC bUg */ ksoftirqd_task(cpu) = current; /* END */ } 00000000800599cc : 800599cc: 3c018016 lui $at,0x8016 800599d0: ac3c14d0 sw $gp,5328($at) /** wrong offset **/ 800599d4: 03e00008 jr $ra 800599d8: 00000000 nop ************************************************ void debugkvc_show_gcc_bug_4(void) /* Test case 3 - WRONG code generated */ { int cpu = smp_processor_id(); volatile void * task; /* TEMPORARY TO SHOW THE CROSS GCC bUg */ task = ksoftirqd_task(cpu); ksoftirqd_task(cpu) = current; ksoftirqd_task(cpu) = task+1; /* END */ } 00000000800599dc : 800599dc: 3c038016 lui $v1,0x8016 800599e0: 246314d0 addiu $v1,$v1,5328 800599e4: 8c620000 lw $v0,0($v1) /** wrong offset **/ 800599e8: 00000000 nop 800599ec: 24420001 addiu $v0,$v0,1 800599f0: 03e00008 jr $ra 800599f4: ac620000 sw $v0,0($v1) 00000000800599f8 : ******************************* ISSUE 2 **************************** mipsel-linux-ld doesn't seem to understand elf32-littlemips even thou mipsel-linux-objdump -i gives elf32-littlemips has part of its output This issue affects the logic used in arch/mips/ramdisk/Makefile to convert the ramdisk.gz file to ramdisk.o Had to force elf32-little for the logic to work. ----------------------------------------------------------------------------- *************** Current status ***************** Because of this, I download the sources for binutils 2.12 and gcc 3.0.4 and created cross compilers for mipsel-linux. Now the compiler is generating proper code for the above case. But linux is failing in the gzips inflate logic (Compressed ramdisk) in some cases, have to verify it properly and identify the issue. It again seems like a compiler problem, but haven't verified it yet. Also I have currently used 2.4.16 with code from linux-mips-kernel on sourceforge as the base on which I have done my porting. Once I find the issue with the gzip logic and also move it to 2.4.18 (or 2.4.19 if it gets released by then), we will release the port to the opensource. **************** Any suggestions **************** In the mean time what do you people think is the best binutils/gcc combination for working with latest Linux kernels for Mips. Keep :-) HanishKVC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Sun Mar 17 10:40:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HIe6E05151 for linux-mips-outgoing; Sun, 17 Mar 2002 10:40:06 -0800 Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2HIe2905148 for ; Sun, 17 Mar 2002 10:40:02 -0800 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020317184126.JUYU2626.rwcrmhc51.attbi.com@ocean.lucon.org>; Sun, 17 Mar 2002 18:41:26 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4B83C125C7; Sun, 17 Mar 2002 10:41:25 -0800 (PST) Date: Sun, 17 Mar 2002 10:41:24 -0800 From: "H . J . Lu" To: Hartvig Ekner Cc: user alias Subject: Re: Compiler problem in glibc Message-ID: <20020317104124.A4002@lucon.org> References: <200203171052.g2HAqGb27844@coplin09.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203171052.g2HAqGb27844@coplin09.mips.com>; from hartvige@mips.com on Sun, Mar 17, 2002 at 11:52:15AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 17, 2002 at 11:52:15AM +0100, Hartvig Ekner wrote: > I have found a problem in glibc caused by the gcc-2.96-99.1 compiler > from H.J's miniport. > > in the exp() function (file w_expf.c), there is code like: > > #ifdef __STDC__ > float __expf(float x) /* wrapper expf */ > #else > float __expf(x) /* wrapper expf */ > float x; > #endif > { > #ifdef _IEEE_LIBM > return __ieee754_expf(x); > #else > float z; > z = __ieee754_expf(x); > if(_LIB_VERSION == _IEEE_) return z; > > if(__finitef(x)) { > if(x>o_threshold) > > > (IEEE_LIBM is not set). Note that there are two function calls (ieee754_expf > and finitef()) followed by a FP if-statement (x>o_threshold). This > translates into: > I believe it has been reported before and is fixed in gcc 3.1 at the time. H.J. From owner-linux-mips@oss.sgi.com Sun Mar 17 12:32:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HKWkq07920 for linux-mips-outgoing; Sun, 17 Mar 2002 12:32:46 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2HKWf907916 for ; Sun, 17 Mar 2002 12:32:41 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 723AF9F03; Sun, 17 Mar 2002 21:34:07 +0100 (CET) Date: Sun, 17 Mar 2002 21:34:06 +0100 From: Jan-Benedict Glaw To: SGI MIPS list Subject: Toolchain question Message-ID: <20020317203406.GG25044@lug-owl.de> Mail-Followup-To: SGI MIPS list Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fhv9pqL4KIX+q4y7" Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --Fhv9pqL4KIX+q4y7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Which cross compiler and binutils are currently known to be good for kernel compilation? I'm (for both LE and BE) currently still using this gcc-3.0 snapshot from the simple/crossdev "package". It's a bit old, but working quite good. What compiler/binutils are currently advisable? Current CVS from binutils, current gcc 3.0 branch from CVS? MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --Fhv9pqL4KIX+q4y7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyU/b0ACgkQHb1edYOZ4buVowCfVOfhWCYQHNk6bp1hTDINYc5g X4AAnjfBR0EFB93hxKvKbYR3RDLbn9Vp =vI/3 -----END PGP SIGNATURE----- --Fhv9pqL4KIX+q4y7-- From owner-linux-mips@oss.sgi.com Sun Mar 17 16:53:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2I0ruM11364 for linux-mips-outgoing; Sun, 17 Mar 2002 16:53:56 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2I0ri911360 for ; Sun, 17 Mar 2002 16:53:45 -0800 Message-Id: <200203180053.g2I0ri911360@oss.sgi.com> Received: (qmail 31152 invoked from network); 18 Mar 2002 01:02:25 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 18 Mar 2002 01:02:25 -0000 Date: Mon, 18 Mar 2002 8:55:47 +0800 From: Zhang Fuxin To: Hartvig Ekner CC: "linux-mips@oss.sgi.com" Subject: Re: Compiler problem in glibc X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2I0rk911361 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, good news to hear they are being fixed. I reported this problem about one month ago,it was fixed in gcc3.1. But i have no time to investigate other math test problems,wish you good luck:) ÔÚ 2002-03-17 11:52:00 you wrote£º >I have found a problem in glibc caused by the gcc-2.96-99.1 compiler >from H.J's miniport. > >in the exp() function (file w_expf.c), there is code like: > >#ifdef __STDC__ > float __expf(float x) /* wrapper expf */ >#else > float __expf(x) /* wrapper expf */ > float x; >#endif >{ >#ifdef _IEEE_LIBM > return __ieee754_expf(x); >#else > float z; > z = __ieee754_expf(x); > if(_LIB_VERSION == _IEEE_) return z; > > if(__finitef(x)) { > if(x>o_threshold) > > >(IEEE_LIBM is not set). Note that there are two function calls (ieee754_expf >and finitef()) followed by a FP if-statement (x>o_threshold). This >translates into: > >00400570 <__expf>: > 400570: 3c1c0fc1 lui gp,0xfc1 > 400574: 279cc090 addiu gp,gp,-16240 > 400578: 0399e021 addu gp,gp,t9 > 40057c: 27bdffc8 addiu sp,sp,-56 > 400580: afbc0018 sw gp,24(sp) > 400584: e7b60030 swc1 $f22,48(sp) > 400588: e7b70034 swc1 $f23,52(sp) > 40058c: e7b40028 swc1 $f20,40(sp) > 400590: e7b5002c swc1 $f21,44(sp) > 400594: afbf0024 sw ra,36(sp) > 400598: 46006506 mov.s $f20,$f12 > 40059c: afbc0020 sw gp,32(sp) > 4005a0: 8f998630 lw t9,-31184(gp) > 4005a4: 00000000 nop > 4005a8: 0320f809 jalr t9 __ieee754_expf > 4005ac: 00000000 nop > 4005b0: 8fbc0018 lw gp,24(sp) > 4005b4: 00000000 nop > 4005b8: 8f8388f4 lw v1,-30476(gp) > 4005bc: 00000000 nop > 4005c0: 8c630000 lw v1,0(v1) > 4005c4: 2402ffff li v0,-1 > 4005c8: 46000586 mov.s $f22,$f0 > 4005cc: 1062002d beq v1,v0,400684 <__expf+0x114> > 4005d0: 4600a306 mov.s $f12,$f20 > 4005d4: 8f9986d0 lw t9,-31024(gp) > 4005d8: 00000000 nop > 4005dc: 0320f809 jalr t9 finitef() > 4005e0: 00000000 nop > 4005e4: 8fbc0018 lw gp,24(sp) > 4005e8: 00000000 nop > 4005ec: 3c0142b1 lui at,0x42b1 > 4005f0: 34217180 ori at,at,0x7180 > 4005f4: 44810000 mtc1 at,$f0 > 4005f8: 00000000 nop > 4005fc: 4614003c c.lt.s $f0,$f20 Wow!!!! > ... > 400608: 1040001e beqz v0,400684 <__expf+0x114> > 40060c: 4600b006 mov.s $f0,$f22 > 400610: 4500000b bc1f 400640 <__expf+0xd0> > > >Note that the c.lt.s (from the FP compare) is done before the finitef() >value has been checked (beqz in 400608). This particular issue causes >the wrong setting of bits in the FPU SR in some cases (with exp(nan)), >and "make check" in glibc to fail. > >BTW, the "make check" in glibc has so far turned up a few other items in >glibc as well as in the kernel (FPU emulator), which are being fixed. > >/Hartvig > >-- > _ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com > |\ /| | |____)(____ Direct: +45 4486 5503 > | \/ | | | _____) MIPS Denmark Switch: +45 4486 5555 >T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556 Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Sun Mar 17 18:16:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2I2GQB12627 for linux-mips-outgoing; Sun, 17 Mar 2002 18:16:26 -0800 Received: from cool2.coventive.com ([202.145.60.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2I2GI912624 for ; Sun, 17 Mar 2002 18:16:23 -0800 Received: from jefflee ([202.145.53.89]) by cool2.coventive.com (8.11.2/8.11.2) with SMTP id g2I2Iaf09249 for ; Mon, 18 Mar 2002 10:18:36 +0800 From: "jeff" To: Subject: Linux VR-41xx Linux kernel support Date: Mon, 18 Mar 2002 10:22:17 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g2I2GO912625 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dear all, I found in mips VR serial (vr4121,vr4131,etc...), the kernel source just maintains up to 2.4.0-test9. Is there any one get the higher kernel version ? Like 2.4.2 something...... Thanks and best regs, Jeff From owner-linux-mips@oss.sgi.com Sun Mar 17 18:27:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2I2RZc12829 for linux-mips-outgoing; Sun, 17 Mar 2002 18:27:35 -0800 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2I2RV912825 for ; Sun, 17 Mar 2002 18:27:31 -0800 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id g2I2Skt06558; Sun, 17 Mar 2002 21:28:46 -0500 Date: Sun, 17 Mar 2002 21:28:46 -0500 From: Jim Paris To: jeff Cc: linux-mips@oss.sgi.com Subject: Re: Linux VR-41xx Linux kernel support Message-ID: <20020317212846.A6528@neurosis.mit.edu> Reply-To: jim@jtan.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jeff_lee@coventive.com on Mon, Mar 18, 2002 at 10:22:17AM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I found in mips VR serial (vr4121,vr4131,etc...), the kernel > source just maintains up to 2.4.0-test9. Is there any one get the > higher kernel version ? Like 2.4.2 something...... The SourceForge linux-mips tree (http://linux-mips.sourceforge.net/) has VR41xx support (among other things) added. It's still a ways from the old Linux-VR tree, unfortunately, but it's slowly getting better. -jim From owner-linux-mips@oss.sgi.com Mon Mar 18 07:12:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IFCZv31067 for linux-mips-outgoing; Mon, 18 Mar 2002 07:12:35 -0800 Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IFCW931064 for ; Mon, 18 Mar 2002 07:12:32 -0800 Received: from girishvg (AUTH login) at g054124.ppp.asahi-net.or.jp (HELO nazneen) (girishvg@211.132.54.124) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Mar 2002 15:13:58 -0000 Message-ID: <033401c1ce8f$cbec7100$ebcc7d3d@gol.com> From: "Girish Gulawani" To: "MIPS/Linux List \(SGI\)" Subject: PCI VGA Card Initilization (SIS6326 / PT80) Date: Tue, 19 Mar 2002 00:15:51 +0900 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 hello, all. i have a PCI/VGA card PT80 with SIS6326 chipset. i am using MILO BIOS source code. but i am not able to access the internal buffer which is typically at 0xA0000. even the BIOS ROM (0xC0000) read fails to show default value 0xA5A5. the expansion ROM is enabled in PCI by setting D0 bit to 1. however IO seems okay because the monitor actually switches from power down mode to normal mode. i have tried using both vgaraw1.c and vgaraw2.c files, but no success. could anybody help me to solve this problem. many thanks. girish. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Mon Mar 18 07:18:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IFIaK31226 for linux-mips-outgoing; Mon, 18 Mar 2002 07:18:36 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IFIW931221 for ; Mon, 18 Mar 2002 07:18:32 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA00074; Mon, 18 Mar 2002 16:19:01 +0100 (MET) Date: Mon, 18 Mar 2002 16:19:00 +0100 (MET) From: Geert Uytterhoeven To: Girish Gulawani cc: "MIPS/Linux List (SGI)" Subject: Re: PCI VGA Card Initilization (SIS6326 / PT80) In-Reply-To: <033401c1ce8f$cbec7100$ebcc7d3d@gol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 19 Mar 2002, Girish Gulawani wrote: > i have a PCI/VGA card PT80 with SIS6326 chipset. i am using MILO BIOS source > code. but i am not able to access the internal buffer which is typically at > 0xA0000. even the BIOS ROM (0xC0000) read fails to show default value > 0xA5A5. the expansion ROM is enabled in PCI by setting D0 bit to 1. however > IO seems okay because the monitor actually switches from power down mode to > normal mode. i have tried using both vgaraw1.c and vgaraw2.c files, but no > success. could anybody help me to solve this problem. > many thanks. Are you using isa_readb() and friends to access ISA memory space? Did you set up isa_slot_offset correctly with the start address of ISA memory space on your MIPS box? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Mon Mar 18 07:40:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IFeln31661 for linux-mips-outgoing; Mon, 18 Mar 2002 07:40:47 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IFei931658 for ; Mon, 18 Mar 2002 07:40:45 -0800 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16mzGs-0000oY-00; Mon, 18 Mar 2002 16:42:02 +0100 Date: Mon, 18 Mar 2002 16:42:02 +0100 From: Johannes Stezenbach To: Jan-Benedict Glaw Cc: SGI MIPS list Subject: Re: Toolchain question Message-ID: <20020318154202.GA3092@convergence.de> Mail-Followup-To: Johannes Stezenbach , Jan-Benedict Glaw , SGI MIPS list References: <20020317203406.GG25044@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020317203406.GG25044@lug-owl.de> User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 17, 2002 at 09:34:06PM +0100, Jan-Benedict Glaw wrote: > > Which cross compiler and binutils are currently known to be good for > kernel compilation? I'm (for both LE and BE) currently still using > this gcc-3.0 snapshot from the simple/crossdev "package". It's a > bit old, but working quite good. > > What compiler/binutils are currently advisable? Current CVS from > binutils, current gcc 3.0 branch from CVS? I'm using binutils-2.12.90.0.1 and gcc-2.95.4-debian, which was recommended here. Read the the thread on "gcc include strangeness" around Feb. 11 for details. Regards, Johannes From owner-linux-mips@oss.sgi.com Mon Mar 18 07:48:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IFmiV31847 for linux-mips-outgoing; Mon, 18 Mar 2002 07:48:44 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IFmO931844 for ; Mon, 18 Mar 2002 07:48:25 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA02365; Mon, 18 Mar 2002 16:47:14 +0100 (MET) Date: Mon, 18 Mar 2002 16:47:13 +0100 (MET) From: Geert Uytterhoeven To: Johannes Stezenbach cc: Jan-Benedict Glaw , SGI MIPS list Subject: Re: Toolchain question In-Reply-To: <20020318154202.GA3092@convergence.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 18 Mar 2002, Johannes Stezenbach wrote: > On Sun, Mar 17, 2002 at 09:34:06PM +0100, Jan-Benedict Glaw wrote: > > Which cross compiler and binutils are currently known to be good for > > kernel compilation? I'm (for both LE and BE) currently still using > > this gcc-3.0 snapshot from the simple/crossdev "package". It's a > > bit old, but working quite good. > > > > What compiler/binutils are currently advisable? Current CVS from > > binutils, current gcc 3.0 branch from CVS? > > I'm using binutils-2.12.90.0.1 and gcc-2.95.4-debian, which > was recommended here. Read the the thread on "gcc include strangeness" > around Feb. 11 for details. Are you compiling natively, or did you create a cross-compiler using the gcc-2.95.4-debian sources? In the latter case, I'm interested in the magic you used to build the cross-compiler, since I can't seem to build a cross-compiler for any arch using those sources (2.95.2 was fine). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Mon Mar 18 08:01:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IG1Vh01561 for linux-mips-outgoing; Mon, 18 Mar 2002 08:01:31 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IG1R901558 for ; Mon, 18 Mar 2002 08:01:28 -0800 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16mzae-0000qO-00; Mon, 18 Mar 2002 17:02:28 +0100 Date: Mon, 18 Mar 2002 17:02:28 +0100 From: Johannes Stezenbach To: Geert Uytterhoeven Cc: Jan-Benedict Glaw , SGI MIPS list Subject: Re: Toolchain question Message-ID: <20020318160228.GA3214@convergence.de> Mail-Followup-To: Johannes Stezenbach , Geert Uytterhoeven , Jan-Benedict Glaw , SGI MIPS list References: <20020318154202.GA3092@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Mar 18, 2002 at 04:47:13PM +0100, Geert Uytterhoeven wrote: > On Mon, 18 Mar 2002, Johannes Stezenbach wrote: > > I'm using binutils-2.12.90.0.1 and gcc-2.95.4-debian, which > > was recommended here. Read the the thread on "gcc include strangeness" > > around Feb. 11 for details. > > Are you compiling natively, or did you create a cross-compiler using the > gcc-2.95.4-debian sources? > > In the latter case, I'm interested in the magic you used to build the > cross-compiler, since I can't seem to build a cross-compiler for any arch using > those sources (2.95.2 was fine). I built a cross compiler. After 'apt-get source gcc-2.95' I did: (The instructions in debian/README.cross did not work for me.) - edit debian/rules.def so that TARGETS=mips (README.cross mentions you have to do this) - run $ debian/rules patch - now you have a patched source tree for mips in src-mips, which configures and builds fine. HTH, Johannes From owner-linux-mips@oss.sgi.com Mon Mar 18 15:43:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2INh6813351 for linux-mips-outgoing; Mon, 18 Mar 2002 15:43:06 -0800 Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2INh2913348 for ; Mon, 18 Mar 2002 15:43:02 -0800 Received: from girishvg (AUTH login) at e144184.ppp.asahi-net.or.jp (HELO nazneen) (girishvg@211.13.144.184) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Mar 2002 23:44:30 -0000 Message-ID: <005101c1ced7$262a9560$b8900dd3@gol.com> From: "Girish Gulawani" To: "Geert Uytterhoeven" Cc: "MIPS/Linux List \(SGI\)" References: Subject: Re: PCI VGA Card Initilization (SIS6326 / PT80) Date: Tue, 19 Mar 2002 08:46:36 +0900 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 > > i have a PCI/VGA card PT80 with SIS6326 chipset. i am using MILO BIOS source > > code. but i am not able to access the internal buffer which is typically at > > 0xA0000. even the BIOS ROM (0xC0000) read fails to show default value > > 0xA5A5. the expansion ROM is enabled in PCI by setting D0 bit to 1. however > > IO seems okay because the monitor actually switches from power down mode to > > normal mode. i have tried using both vgaraw1.c and vgaraw2.c files, but no > > success. could anybody help me to solve this problem. > > many thanks. > > Are you using isa_readb() and friends to access ISA memory space? > Did you set up isa_slot_offset correctly with the start address of ISA memory > space on your MIPS box? no i am not using isa_readb() etc. infact i am accessing this area 0xA_0000 as Memory/IO in memory mode. i have seen the pci bus transactions, its generating memory read and memory write commands. but due to some reason that is still *unknown* to me generates master abort. i always get master received master abort. could you tell me what could be the reason? _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Mon Mar 18 15:55:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2INt3913764 for linux-mips-outgoing; Mon, 18 Mar 2002 15:55:03 -0800 Received: from granite.he.net (granite.he.net [216.218.226.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2INsx913744 for ; Mon, 18 Mar 2002 15:55:00 -0800 Received: from w2k30g (209-142-39-228.stk.inreach.net [209.142.39.228]) by granite.he.net (8.8.6/8.8.2) with SMTP id PAA05596 for ; Mon, 18 Mar 2002 15:56:29 -0800 Delivered-To: Message-ID: <00f601c1ced8$63586600$0b01a8c0@w2k30g> From: "David Christensen" To: Subject: hello Date: Mon, 18 Mar 2002 15:55:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com: Hello! I have the opportunity to work on MIPS Linux using a MIPS Atlas (4Kc) board. 1. Is there a reason why SourceForge isn't being used for the MIPS Linux project? 2. What is the preferred host OS for MIPS Linux kernel and application cross development (especially the MIPS Altas)? 3. What is the preferred toolchain for MIPS Linux kernel and application cross development (especially the MIPS Altas)? 4. Is MIPS Linux self-hosted? 5. Can you do native development on MIPS Linux? 6. Does MIPS Linux support sound (oss or alsa) on any platform? Does it support sound on MIPS Atlas? TIA, David From owner-linux-mips@oss.sgi.com Mon Mar 18 18:01:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J21u915615 for linux-mips-outgoing; Mon, 18 Mar 2002 18:01:56 -0800 Received: from granite.he.net (granite.he.net [216.218.226.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J21r915612 for ; Mon, 18 Mar 2002 18:01:53 -0800 Received: from w2k30g (209-142-39-228.stk.inreach.net [209.142.39.228]) by granite.he.net (8.8.6/8.8.2) with SMTP id SAA15124; Mon, 18 Mar 2002 18:03:18 -0800 Delivered-To: linux-mips@oss.sgi.com Message-ID: <015201c1ceea$1af02760$0b01a8c0@w2k30g> From: "David Christensen" To: "LEO" Cc: References: <00f601c1ced8$63586600$0b01a8c0@w2k30g> <200203182235.g2IMZiM01720@localhost.localdomain> Subject: Re: hello Date: Mon, 18 Mar 2002 18:01:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Leo: > http://linux-mips.sourceforge.net/ > > Fully equipped with toolchain howto and all. OK thanks for the pointer. I searched SourceForge for "MIPS Linux" before posting to linux-mips@oss.sgi.com, and came up with "MIPS Linux" and "Linux MIPS". Neither project had released files, so I thought they were dead. Should I continue to use the linux-mips@oss.sgi.com mailing list, or switch to linux-mips on SourceForge? David From owner-linux-mips@oss.sgi.com Tue Mar 19 02:09:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JA9iY23056 for linux-mips-outgoing; Tue, 19 Mar 2002 02:09:44 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JA9c923053 for ; Tue, 19 Mar 2002 02:09:38 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA29924; Tue, 19 Mar 2002 11:10:16 +0100 (MET) Date: Tue, 19 Mar 2002 11:10:16 +0100 (MET) From: Geert Uytterhoeven To: Girish Gulawani cc: "MIPS/Linux List (SGI)" Subject: Re: PCI VGA Card Initilization (SIS6326 / PT80) In-Reply-To: <005101c1ced7$262a9560$b8900dd3@gol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 19 Mar 2002, Girish Gulawani wrote: > > > i have a PCI/VGA card PT80 with SIS6326 chipset. i am using MILO BIOS > source > > > code. but i am not able to access the internal buffer which is typically > at > > > 0xA0000. even the BIOS ROM (0xC0000) read fails to show default value > > > 0xA5A5. the expansion ROM is enabled in PCI by setting D0 bit to 1. > however > > > IO seems okay because the monitor actually switches from power down mode > to > > > normal mode. i have tried using both vgaraw1.c and vgaraw2.c files, but > no > > > success. could anybody help me to solve this problem. > > > many thanks. > > > > Are you using isa_readb() and friends to access ISA memory space? > > Did you set up isa_slot_offset correctly with the start address of ISA > memory > > space on your MIPS box? > no i am not using isa_readb() etc. infact i am accessing this area 0xA_0000 > as Memory/IO in memory mode. i have seen the pci bus transactions, its > generating memory read and memory write commands. but due to some reason > that is still *unknown* to me generates master abort. i always get master > received master abort. could you tell me what could be the reason? Plain memory I/O can work, but is not portable. You should use isa_readb() and friends, though, after setting up isa_slot_offset. It looks like you have access to some PCI bus analyzer? Do you see memory read and write commands for the correct PCI bus addresses (e.g. 0xa0000)? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Tue Mar 19 04:10:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JCAF927109 for linux-mips-outgoing; Tue, 19 Mar 2002 04:10:15 -0800 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JCA7927106 for ; Tue, 19 Mar 2002 04:10:08 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 2415B849; Tue, 19 Mar 2002 13:11:34 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5A72D37047; Tue, 19 Mar 2002 13:11:14 +0100 (CET) Date: Tue, 19 Mar 2002 13:11:14 +0100 From: Florian Lohoff To: David Christensen Cc: linux-mips@oss.sgi.com Subject: Re: hello Message-ID: <20020319121114.GB18733@paradigm.rfc822.org> References: <00f601c1ced8$63586600$0b01a8c0@w2k30g> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <00f601c1ced8$63586600$0b01a8c0@w2k30g> User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 18, 2002 at 03:55:00PM -0800, David Christensen wrote: > linux-mips@oss.sgi.com: >=20 > Hello! I have the opportunity to work on MIPS Linux using a MIPS Atlas > (4Kc) board. >=20 > 1. Is there a reason why SourceForge isn't being used for the MIPS > Linux project? The Linux-mips project is much older than sourceforge and looking at the history of hyped venture capital companys does not really give a good feeling about using sourceforge. Personally spoken i dont like sourceforge - For most cases its just too bloated and working for ISPs its not a problem to get some public accesible ftp/web/cvs space. > 4. Is MIPS Linux self-hosted? Definitly > 5. Can you do native development on MIPS Linux? Yep - The Debian autobuilder run native on little and big endian. > 6. Does MIPS Linux support sound (oss or alsa) on any platform? Does > it support sound on MIPS Atlas? Some rumors about Indy/Indigo2 HAL support have been heard. The problem with some sourceforge trees and thesplit up information is=20 that like you already experienced is a real problem for Linux-mips as there is no "source of the only wisdom". I dont like that tree-forking etc. Either build your stuff clean - ready for inclusion -=20 or just drop the tree under the table as a big bad ugly hack. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8lyriUaz2rXW+gJcRAk6JAJ9VOE/CYT4FKczzBjhH6JYLH8wqkQCg3u2G swXJvWI65kvpzL949cYdShw= =L10y -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-linux-mips@oss.sgi.com Tue Mar 19 04:13:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JCD4L27184 for linux-mips-outgoing; Tue, 19 Mar 2002 04:13:04 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JCD0927181 for ; Tue, 19 Mar 2002 04:13:01 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 806FC1EB20; Tue, 19 Mar 2002 13:14:20 +0100 (MET) Date: Tue, 19 Mar 2002 13:14:18 +0100 (CET) From: Adrian Schroeter Reply-To: Adrian Schroeter To: Florian Lohoff Cc: David Christensen , Subject: Re: hello In-Reply-To: <20020319121114.GB18733@paradigm.rfc822.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 19 Mar 2002, Florian Lohoff wrote: > On Mon, Mar 18, 2002 at 03:55:00PM -0800, David Christensen wrote: > > 6. Does MIPS Linux support sound (oss or alsa) on any platform? Does > > it support sound on MIPS Atlas? > > Some rumors about Indy/Indigo2 HAL support have been heard. oss works for me here on Indy/Indigo2. The arts drivers seems to be too outdated atm. bye adrian ********************************************************************** Adrian Schroeter SuSE AG, Deutschherrnstr. 15-19, 90429 Nuernberg, Germany email: adrian@suse.de (495 mails already received today.) From owner-linux-mips@oss.sgi.com Tue Mar 19 12:12:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JKCeq05731 for linux-mips-outgoing; Tue, 19 Mar 2002 12:12:40 -0800 Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JKCa905728 for ; Tue, 19 Mar 2002 12:12:36 -0800 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id g2JKE0u24088 for ; Tue, 19 Mar 2002 12:14:00 -0800 Received: from exceed2.sanera.net (exceed2.sanera.net [172.16.2.39]) by icarus.sanera.net (8.11.6/8.11.6) with SMTP id g2JKDsD02409 for ; Tue, 19 Mar 2002 12:13:54 -0800 Message-Id: <200203192013.g2JKDsD02409@icarus.sanera.net> Date: Tue, 19 Mar 2002 12:13:54 -0800 (PST) From: Krishna Kondaka Reply-To: Krishna Kondaka Subject: Application stack trace facility To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NeM/JmlDGwX0VzgiIr57eA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I would like to know if there is a system call/library function available in linux which prints the current stack trace of the application. For ex., If main() calls a() which calls b() which in turn calls c() and if c() is defined as c() { .... if (condition) dump_stack_trac(); .... } the dump_stack_trace() should print if the "condition" is true - c(...) b(...) a(...) main(..) Is there such "dump_stack_trace" library function/system call available? I know that if I make the program dump core in the dump_stack_trace function then I can get the stack trace from the core dump but I would like to know if I can do this without forcing the core dump. TIA Krishna Kondaka Sanera Systems From owner-linux-mips@oss.sgi.com Tue Mar 19 14:58:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JMwj609584 for linux-mips-outgoing; Tue, 19 Mar 2002 14:58:45 -0800 Received: from granite.he.net (granite.he.net [216.218.226.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JMwS909535 for ; Tue, 19 Mar 2002 14:58:28 -0800 Received: from w2k30g (209-142-39-228.stk.inreach.net [209.142.39.228]) by granite.he.net (8.8.6/8.8.2) with SMTP id OAA10270 for ; Tue, 19 Mar 2002 14:59:56 -0800 Delivered-To: Message-ID: <017701c1cf99$a7d9a890$0b01a8c0@w2k30g> From: "David Christensen" To: Subject: Fw: hello Date: Tue, 19 Mar 2002 14:55:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com: Thank you all for your replies. :-) Hartvig Ekner wrote: >> 2. What is the preferred host OS... > We use Linux/x86 for kernel compiles, Which Linux distribution does MIPS use? Since I'm going to be working on an Atlas board using software from MIPS, I would like to match things up exactly. As an aside, is anybody using a VMware virtual machine for their development host? > and native compile for apps. OK that sounds like a safe bet. >> 3. What is the preferred toolchain... > This is what we use for cross Kernel compiles (toolchain from oss): > > /home/hartvige> gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85) Hmmm. That looks like a native i386 compiler. I'm surprised its not something like "mips-elf-gcc". I'll assume the cross-compile toolchain was built per http://oss.sgi.com/mips/mips-howto.html section 10. >> 4. Is MIPS Linux self-hosted? > Yes. Even without workstations, you could use MIPS or Algo development > boards for self-hosted development (which is what we do - primarily > Malta boards). Good. :-) >> 5. Can you do native development on MIPS Linux? > Yes. Good. :-) >> 6. Does MIPS Linux support sound (oss or alsa) on any platform? >> Does it support sound on MIPS Atlas? > Yes. Plug in a Creative SB card, based on the Ensoniq chip and > enable the es1371.c in the kernel compile. Works both LE & BE, and > with apps like madplay (mp3) and mplayer (mpeg4). Great! :-) Florian Lohoff wrote: >> 1. Is there a reason why SourceForge isn't being used for the MIPS >> Linux project? > The Linux-mips project is much older than sourceforge and looking at > the history of hyped venture capital companys does not really give a > good feeling about using sourceforge. Personally spoken i dont like > sourceforge - For most cases its just too bloated and working for ISPs > its not a problem to get some public accesible ftp/web/cvs space. OK I've used SourceForge as a software consumer and liked it. I just received their approval for an GPL'd Perl utility I wrote ("dirdiff"). >> 4. Is MIPS Linux self-hosted? > Definitly Good. :-) >> 5. Can you do native development on MIPS Linux? > Yep - The Debian autobuilder run native on little and big endian. Hmmm. Do you mean GNU autoconf running natively on MIPS, or something running on a Debian x86 host, or something else? >> 6. Does MIPS Linux support sound (oss or alsa) on any platform? Does >> it support sound on MIPS Atlas? > Somme rumors about Indy/Indigo2 HAL support have been heard. OK > The problem with some sourceforge trees and the split up information > is that like you already experienced is a real problem for Linux-mips > as there is no "source of the only wisdom". I dont like that tree- > forking etc. Either build your stuff clean - ready for inclusion - > or just drop the tree under the table as a big bad ugly hack. OK Adrian Schroeter wrote: >>> 6. Does MIPS Linux support sound (oss or alsa) on any platform? >>> Does it support sound on MIPS Atlas? >> Some rumors about Indy/Indigo2 HAL support have been heard. > oss works for me here on Indy/Indigo2. The arts drivers seems to be > too outdated atm. OK Leo Przybylski wrote: > Well, all Linux/MIPS stuff on on oss.sgi.com is maintained largely by > Ralf Baechle who is also contributor to numerous Linux/MIPS projects > on sourceforge. As far as I know he is also a huge part of the > sourceforge Linux/MIPS. You may have noticed that Bradley D. LaRonde > is also a huge contributor. > > You have probably guessed that all the projects on sourceforge > regarding linux mips are related by the maintainers and contributors. > Most of the code is being contributed to sourceforge, oss.sgi.com, > debian, redhat and so on. When everyone has their own toolchains, > roots and kernels it's hard to keep them in their own repositories. > oss.sgi.com has tried largely to do this though which is why it is a > good place to start. The ftp site carries debian and redhat binaries, > patches, etc... There's also the linux-mips kernel located in the > oss.sgi.com CVS repository. > > As for why it is working to keep most of the resources in oss.sgi.com > contrary to sourceforge, I don't really have an answer to that. Hope > this helps. Thanks for the background. Clearly, linux-mips has much history behind it. David From owner-linux-mips@oss.sgi.com Tue Mar 19 22:29:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K6Tfa20919 for linux-mips-outgoing; Tue, 19 Mar 2002 22:29:41 -0800 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2K6TX920916 for ; Tue, 19 Mar 2002 22:29:34 -0800 Received: from excalibur.cologne.de (pD951145C.dip.t-dialin.net [217.81.20.92]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id HAA08176; Wed, 20 Mar 2002 07:30:57 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 16nZkt-0000C7-00; Wed, 20 Mar 2002 07:39:27 +0100 Date: Wed, 20 Mar 2002 07:39:27 +0100 From: Karsten Merker To: David Christensen Cc: linux-mips@oss.sgi.com Subject: Re: Fw: hello Message-ID: <20020320073927.A471@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , David Christensen , linux-mips@oss.sgi.com References: <017701c1cf99$a7d9a890$0b01a8c0@w2k30g> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <017701c1cf99$a7d9a890$0b01a8c0@w2k30g>; from dpchrist@holgerdanske.com on Tue, Mar 19, 2002 at 02:55:22PM -0800 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Mar 19, 2002 at 02:55:22PM -0800, David Christensen wrote: > Which Linux distribution does MIPS use? Since I'm going to be working > on an Atlas board using software from MIPS, I would like to match things > up exactly. Several different - there is a Debian port (big and little endian), H.J. Lu's RedHat mini-port (big endian AFAIK), Karel van Houten's RedHat-based rootfs (little endian), Keith M. Wesolwski's Simple Linux (big-endian). I think the most complete of all is Debian. > As an aside, is anybody using a VMware virtual machine for their > development host? Why should we? VMware emulates i386 on i386, so it would be of no help for mips development. > >> 3. What is the preferred toolchain... I always build natively: gcc version 2.95.4 20011002 (Debian prerelease) GNU ld version 2.11.93.0.2 20020207 Debian/GNU Linux > > Yep - The Debian autobuilder run native on little and big endian. > > Hmmm. Do you mean GNU autoconf running natively on MIPS, or something > running on a Debian x86 host, or something else? The autobuilder is a system that checks for new Debian packages which are not yet built for mips/mipsel and automatically builds and uploads them into the Debian archive. It runs natively (in our case on a Lasat Masquerade Pro for little endian and on an SGI Indigo2 for big endian). Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Wed Mar 20 00:58:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K8wU024023 for linux-mips-outgoing; Wed, 20 Mar 2002 00:58:30 -0800 Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2K8wL924018 for ; Wed, 20 Mar 2002 00:58:22 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id AAA29328; Wed, 20 Mar 2002 00:59:39 -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 AAA14442; Wed, 20 Mar 2002 00:59:42 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g2K8x3A05082; Wed, 20 Mar 2002 09:59:04 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id JAA10886; Wed, 20 Mar 2002 09:59:40 +0100 (MET) Message-Id: <200203200859.JAA10886@copsun18.mips.com> Subject: Re: Fw: hello To: dpchrist@holgerdanske.com (David Christensen) Date: Wed, 20 Mar 2002 09:59:40 +0100 (MET) Cc: linux-mips@oss.sgi.com In-Reply-To: <017701c1cf99$a7d9a890$0b01a8c0@w2k30g> from "David Christensen" at Mar 19, 2002 02:55:22 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi David, David Christensen writes: > > linux-mips@oss.sgi.com: > > Thank you all for your replies. :-) > > > Hartvig Ekner wrote: > >> 2. What is the preferred host OS... > > We use Linux/x86 for kernel compiles, > > Which Linux distribution does MIPS use? Since I'm going to be working > on an Atlas board using software from MIPS, I would like to match things > up exactly. Internally for development we use H.J's RedHat 7.1/MIPS miniport. Ready-to-go kernel images and installation instructions (via NFS or CDROM) for Atlas and Malta boards can be found on ftp.mips.com. > As an aside, is anybody using a VMware virtual machine for their > development host? > > > and native compile for apps. > > OK that sounds like a safe bet. > > >> 3. What is the preferred toolchain... > > This is what we use for cross Kernel compiles (toolchain from oss): > > > > /home/hartvige> gcc -v > > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85) > > Hmmm. That looks like a native i386 compiler. I'm surprised its not > something like "mips-elf-gcc". Sorry - I ran the command in the wrong window :-) For kernel cross compilation we use the following binary RPM's (LE shown only): binutils-mipsel-linux-2.9.5-3 egcs-mipsel-linux-1.1.2-4 They can be found on: ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/ > I'll assume the cross-compile toolchain was built per > http://oss.sgi.com/mips/mips-howto.html section 10. > > >> 4. Is MIPS Linux self-hosted? > > Yes. Even without workstations, you could use MIPS or Algo development > > boards for self-hosted development (which is what we do - primarily > > Malta boards). > > Good. :-) > > >> 5. Can you do native development on MIPS Linux? > > Yes. > > Good. :-) > > >> 6. Does MIPS Linux support sound (oss or alsa) on any platform? > >> Does it support sound on MIPS Atlas? > > Yes. Plug in a Creative SB card, based on the Ensoniq chip and > > enable the es1371.c in the kernel compile. Works both LE & BE, and > > with apps like madplay (mp3) and mplayer (mpeg4). > > Great! :-) > > From owner-linux-mips@oss.sgi.com Wed Mar 20 05:00:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KD0BU27681 for linux-mips-outgoing; Wed, 20 Mar 2002 05:00:11 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KD08927678 for ; Wed, 20 Mar 2002 05:00:09 -0800 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16nfiS-0002ib-00; Wed, 20 Mar 2002 14:01:20 +0100 Date: Wed, 20 Mar 2002 14:01:20 +0100 From: Johannes Stezenbach To: Krishna Kondaka Cc: linux-mips@oss.sgi.com Subject: Re: Application stack trace facility Message-ID: <20020320130120.GA9983@convergence.de> Mail-Followup-To: Johannes Stezenbach , Krishna Kondaka , linux-mips@oss.sgi.com References: <200203192013.g2JKDsD02409@icarus.sanera.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203192013.g2JKDsD02409@icarus.sanera.net> User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Mar 19, 2002 at 12:13:54PM -0800, Krishna Kondaka wrote: > I would like to know if there is a system call/library function > available in linux which prints the current stack trace of the > application. The Glib has a function g_on_error_stack_trace() which does this in a slightly hackish way by attaching gdb to the crashed program (to be called from a SIGSEGV handler). Look at gbacktrace.c there: http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=glib/glib&module=. HTH, Johannes From owner-linux-mips@oss.sgi.com Wed Mar 20 06:12:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KEC2A29426 for linux-mips-outgoing; Wed, 20 Mar 2002 06:12:02 -0800 Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KEBq929423 for ; Wed, 20 Mar 2002 06:11:52 -0800 Received: from girishvg (AUTH login) at e145176.ppp.asahi-net.or.jp (HELO nazneen) (girishvg@211.13.145.176) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Mar 2002 14:13:20 -0000 Message-ID: <006f01c1d019$aa3bf360$b0910dd3@gol.com> From: "Girish Gulawani" To: "MIPS/Linux List \(SGI\)" Subject: Re: PCI VGA Card Initilization (SIS6326 / PT80) Date: Wed, 20 Mar 2002 23:15:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit 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 hello again. with regards to previous replies to my post -- the isa_readb() i am not using as i am still inside the linux loader program & not inside the linux kernel. now it seems what Zhang says is right. that some cards cannot be fired up without their BIOS. meantime today i could access VGA ROM BIOS at 0xC_0000 for no use as its x86 code. i tried free-bios source code, which has VGA bios code for SiS300. its able to bring up monitor to normal mode out of powerdown mode. screen even displays "Out of Scan Range" message. but nothing after that. in order to compare initialization steps between SiS300 & my target SiS6326, i tried to get the data sheet from www.sis.com website but the data sheets are not available. could any body point me where the data sheets for SiS300 and PT-80 VGA card are available? btw, i wonder what card you people are using for VGA monitors? and what about their initialization on the MIPS board? is there ANYBODY who has used "AOpen's PT80" or ANY VGA card based on SiS6326 chipset on MIPS board & how? if somebody has done this exercise could you please explain, because i am sure this will be of general interest. [to summarize my problem with PCI/VGA card -- currently i am using MILO bios source code. the card has 3 BARs. BAR0 = PCI Memory Area. BAR1 = 0xA_0000 (VGA MemIO Buff) BAR2 = 0x0380 (IO). with these settings the IO access from CPU is ok. but any access to A0000 fails. my PCI is not PCI-to-PCI bridge, hence no question of VGA Enable. also the PCI bus analyzer does show memory read & memory writes commands being generated when accessed A0000 address. to add to this - i guess my options to choose the card are also limited as i have 3.3v PCI slot.] please help me. many thanks in advance. regards, girish. ----- Original Message ----- From: "Zhang Fuxin" To: "Girish Gulawani" Sent: Tuesday, March 19, 2002 12:00 AM Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) hi, could that be the famouse vga bios initialization problem? That is, without executing the vgabios code,video card often refuse to work. And unfortunately vgabios code is often for x86. ?¨² 2002-03-19 08:46:00 you wrote¡êo >> > i have a PCI/VGA card PT80 with SIS6326 chipset. i am using MILO BIOS >source >> > code. but i am not able to access the internal buffer which is typically >at >> > 0xA0000. even the BIOS ROM (0xC0000) read fails to show default value >> > 0xA5A5. the expansion ROM is enabled in PCI by setting D0 bit to 1. >however >> > IO seems okay because the monitor actually switches from power down mode >to >> > normal mode. i have tried using both vgaraw1.c and vgaraw2.c files, but >no >> > success. could anybody help me to solve this problem. >> > many thanks. >> >> Are you using isa_readb() and friends to access ISA memory space? >> Did you set up isa_slot_offset correctly with the start address of ISA >memory >> space on your MIPS box? >no i am not using isa_readb() etc. infact i am accessing this area 0xA_0000 >as Memory/IO in memory mode. i have seen the pci bus transactions, its >generating memory read and memory write commands. but due to some reason >that is still *unknown* to me generates master abort. i always get master >received master abort. could you tell me what could be the reason? > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com Regards Zhang Fuxin fxzhang@ict.ac.cn _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Wed Mar 20 06:44:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KEiJj29839 for linux-mips-outgoing; Wed, 20 Mar 2002 06:44:19 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KEi6929835 for ; Wed, 20 Mar 2002 06:44:06 -0800 Message-Id: <200203201444.g2KEi6929835@oss.sgi.com> Received: (qmail 6381 invoked from network); 20 Mar 2002 14:16:37 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 20 Mar 2002 14:16:37 -0000 Date: Wed, 20 Mar 2002 22:46:14 +0800 From: Zhang Fuxin To: Girish Gulawani CC: "linux-mips@oss.sgi.com" Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2KEi7929836 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, ÔÚ 2002-03-20 23:15:00 you wrote£º >hello again. >with regards to previous replies to my post -- the isa_readb() i am not >using as i am still inside the linux loader program & not inside the linux >kernel. now it seems what Zhang says is right. that some cards cannot be >fired up without their BIOS. >meantime today i could access VGA ROM BIOS at 0xC_0000 for no use as its x86 >code. i tried free-bios source code, which has VGA bios code for SiS300. its >able to bring up monitor to normal mode out of powerdown mode. screen even >displays "Out of Scan Range" message. but nothing after that. in order to >compare initialization steps between SiS300 & my target SiS6326, i tried to >get the data sheet from www.sis.com website but the data sheets are not >available. could any body point me where the data sheets for SiS300 and >PT-80 VGA card are available? > >btw, i wonder what card you people are using for VGA monitors? and what >about their initialization on the MIPS board? is there ANYBODY who has used >"AOpen's PT80" or ANY VGA card based on SiS6326 chipset on MIPS board & how? >if somebody has done this exercise could you please explain, because i am >sure this will be of general interest. We have tried several cards on Algor P6032 board,but only matrox Gxxx cards (G450 needs the latest code) can be used by linux kernel without vga bios executed. With a x86 emulator we are able to use Riva TNT2,and probably more can work. Unfortunately that emulator is an executable from Algor, as a kindly help. We can't get more control on it and finally give up. Recently we decide to develop our own emulator to execute vga bios code. If everything goes smoothly,it should be available in several weeks. > >[to summarize my problem with PCI/VGA card -- currently i am using MILO bios >source code. the card has 3 BARs. >BAR0 = PCI Memory Area. BAR1 = 0xA_0000 (VGA MemIO Buff) BAR2 = 0x0380 (IO). >with these settings the IO access from CPU is ok. but any access to A0000 >fails. my PCI is not PCI-to-PCI bridge, hence no question of VGA Enable. >also the PCI bus analyzer does show memory read & memory writes commands >being generated when accessed A0000 address. to add to this - i guess my >options to choose the card are also limited as i have 3.3v PCI slot.] > >please help me. >many thanks in advance. >regards, >girish. > > >----- Original Message ----- >From: "Zhang Fuxin" >To: "Girish Gulawani" >Sent: Tuesday, March 19, 2002 12:00 AM >Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) > > >hi, > > could that be the famouse vga bios initialization problem? That is, >without executing the vgabios code,video card often refuse to work. >And unfortunately vgabios code is often for x86. > >?¨² 2002-03-19 08:46:00 you wrote¡êo >>> > i have a PCI/VGA card PT80 with SIS6326 chipset. i am using MILO BIOS >>source >>> > code. but i am not able to access the internal buffer which is >typically >>at >>> > 0xA0000. even the BIOS ROM (0xC0000) read fails to show default value >>> > 0xA5A5. the expansion ROM is enabled in PCI by setting D0 bit to 1. >>however >>> > IO seems okay because the monitor actually switches from power down >mode >>to >>> > normal mode. i have tried using both vgaraw1.c and vgaraw2.c files, but >>no >>> > success. could anybody help me to solve this problem. >>> > many thanks. >>> >>> Are you using isa_readb() and friends to access ISA memory space? >>> Did you set up isa_slot_offset correctly with the start address of ISA >>memory >>> space on your MIPS box? >>no i am not using isa_readb() etc. infact i am accessing this area 0xA_0000 >>as Memory/IO in memory mode. i have seen the pci bus transactions, its >>generating memory read and memory write commands. but due to some reason >>that is still *unknown* to me generates master abort. i always get master >>received master abort. could you tell me what could be the reason? >> >> >>_________________________________________________________ >>Do You Yahoo!? >>Get your free @yahoo.com address at http://mail.yahoo.com > >Regards > Zhang Fuxin > fxzhang@ict.ac.cn > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Wed Mar 20 06:53:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KErEI30046 for linux-mips-outgoing; Wed, 20 Mar 2002 06:53:14 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KErA930043 for ; Wed, 20 Mar 2002 06:53:11 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16nhjK-0002VT-00; Wed, 20 Mar 2002 15:10:22 +0000 Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) To: fxzhang@ict.ac.cn (Zhang Fuxin) Date: Wed, 20 Mar 2002 15:10:22 +0000 (GMT) Cc: girishvg@yahoo.com (Girish Gulawani), linux-mips@oss.sgi.com (linux-mips@oss.sgi.com) In-Reply-To: <200203201444.g2KEi6929835@oss.sgi.com> from "Zhang Fuxin" at Mar 20, 2002 10:46:14 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > executed. With a x86 emulator we are able to use Riva TNT2,and probably > more can work. Unfortunately that emulator is an executable from Algor, > as a kindly help. We can't get more control on it and finally give up. There is a BIOS emulator for booting video cards included (full source) in the XFree86 4.x distribution. It seems to work with a fair range of cards Alan From owner-linux-mips@oss.sgi.com Wed Mar 20 09:37:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KHbJU04340 for linux-mips-outgoing; Wed, 20 Mar 2002 09:37:19 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2KHbE904337 for ; Wed, 20 Mar 2002 09:37:14 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2KHcgf07579; Wed, 20 Mar 2002 09:38:42 -0800 Date: Wed, 20 Mar 2002 09:38:42 -0800 From: Ralf Baechle To: David Christensen Cc: linux-mips@oss.sgi.com Subject: Re: Fw: hello Message-ID: <20020320093842.B7190@dea.linux-mips.net> References: <017701c1cf99$a7d9a890$0b01a8c0@w2k30g> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <017701c1cf99$a7d9a890$0b01a8c0@w2k30g>; from dpchrist@holgerdanske.com on Tue, Mar 19, 2002 at 02:55:22PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Mar 19, 2002 at 02:55:22PM -0800, David Christensen wrote: > As an aside, is anybody using a VMware virtual machine for their > development host? While it can be done there is not much point in doing so unless you hate performance ;) > > and native compile for apps. > > OK that sounds like a safe bet. Which is the primary reason for native compiles. > >> 3. What is the preferred toolchain... > > This is what we use for cross Kernel compiles (toolchain from oss): > > > > /home/hartvige> gcc -v > > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85) > > Hmmm. That looks like a native i386 compiler. I'm surprised its not > something like "mips-elf-gcc". Yes, that's his native compiler. mips-elf-gcc however should not be used, there are subtle differences between the various ELF/MIPS targets that would turn your life into hell ... > I'll assume the cross-compile toolchain was built per > http://oss.sgi.com/mips/mips-howto.html section 10. That's roughly the procedure, though the procedure described is not 100% suitable for the recommended compiler version. So I recommend downloading the binary rpms. > > Leo Przybylski wrote: > > Well, all Linux/MIPS stuff on on oss.sgi.com is maintained largely by > > Ralf Baechle who is also contributor to numerous Linux/MIPS projects > > on sourceforge. As far as I know he is also a huge part of the > > sourceforge Linux/MIPS. You may have noticed that Bradley D. LaRonde > > is also a huge contributor. No. I don't touch or follow the Sourceforge project at all. Ralf From owner-linux-mips@oss.sgi.com Wed Mar 20 15:05:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KN51k13375 for linux-mips-outgoing; Wed, 20 Mar 2002 15:05:01 -0800 Received: from granite.he.net (granite.he.net [216.218.226.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KN4n913367 for ; Wed, 20 Mar 2002 15:04:49 -0800 Received: from w2k30g (209-142-39-228.stk.inreach.net [209.142.39.228]) by granite.he.net (8.8.6/8.8.2) with SMTP id PAA26908 for ; Wed, 20 Mar 2002 15:06:17 -0800 Delivered-To: Message-ID: <029001c1d063$b5886880$0b01a8c0@w2k30g> From: "David Christensen" To: Subject: Fw: Fw: hello Date: Wed, 20 Mar 2002 15:04:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com: Thank you all for your replies. :-) Ralf Baechle wrote: >> As an aside, is anybody using a VMware virtual machine for their >> development host? > While it can be done there is not much point in doing so unless you > hate performance ;) I have three boxes (RH7.1 firewall, SuSE 7.3 server, and W2k workstation) and a shelf of OS's. My needs seem to be constantly changing. VMware allows me to build a virtual machine that is configured specifically for one purpose (such as linux-mips development) without having to sacrifice any hardware (and associated functionality). I am willing to trade a large gain in flexibility for a small loss in performance. For those of you who haven't tried VMware, they offer a 30-day evaluation: http://www.vmware.com/ > mips-elf-gcc however should not be used, there are subtle differences > between the various ELF/MIPS targets that would turn your life into > hell ... OK It appears that people are pulling in source and/or binary pieces from various places -- MIPS (cross) compiler, linux-mips kernel, linux-mips root filesystem, linux userland filesystem, etc.. Mismatches between tools are definitely going to cause grief. It would be nice if a person could start with a blank host, install the host OS, download the MIPS cross compiler source, build the MIPS (cross) compiler, download the linux-mips kernel, rootfs, userland, etc., sources, and build those using their (cross) compiler. Can this be one an x86 host using a commercial Linux distribution (my situation)? Is there one HOWTO or README that describes such? Hartvig Ekner wrote: >>>> 2. What is the preferred host OS... >>> We use Linux/x86 for kernel compiles, >> Which Linux distribution does MIPS use? Since I'm going to be >> working on an Atlas board using software from MIPS, I would like to >> match things up exactly. > Internally for development we use H.J's RedHat 7.1/MIPS miniport. > Ready-to-go kernel images and installation instructions (via NFS or > CDROM) for Atlas and Malta boards can be found on ftp.mips.com. Hmmm. I guess I was assuming that you were doing MIPS Linux cross development on x86 hosts using a commercial Linux distribution such as Red Hat 7.1. So, let me be more specific. What host hardware platform(s) and host operating system(s) does MIPS use to build their MIPS Linux distribution as found on ftp://ftp.mips.com/pub/linux/mips/? > For kernel cross compilation we use the following binary RPM's (LE > shown only): > > binutils-mipsel-linux-2.9.5-3 > egcs-mipsel-linux-1.1.2-4 > > They can be found on: > > ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/ OK Thanks for the link! Karsten Merker wrote: >> Which Linux distribution does MIPS use? Since I'm going to be >> working on an Atlas board using software from MIPS, I would like to >> match things up exactly. > Several different - there is a Debian port (big and little endian), > H.J. Lu's RedHat mini-port (big endian AFAIK), Karel van Houten's > RedHat-based rootfs (little endian), Keith M. Wesolwski's Simple > Linux (big-endian). I think the most complete of all is Debian. Please see my comment to Hartvig (above). >> As an aside, is anybody using a VMware virtual machine for their >> development host? > Why should we? VMware emulates i386 on i386, so it would be of no > help for mips development. Please see my comment to Ralf (above). >> 3. What is the preferred toolchain... > I always build natively: > gcc version 2.95.4 20011002 (Debian prerelease) > GNU ld version 2.11.93.0.2 20020207 Debian/GNU Linux >>> Yep - The Debian autobuilder run native on little and big endian. >> Hmmm. Do you mean GNU autoconf running natively on MIPS, or >> something running on a Debian x86 host, or something else? > The autobuilder is a system that checks for new Debian packages which > are not yet built for mips/mipsel and automatically builds and uploads > them into the Debian archive. It runs natively (in our case on a > Lasat Masquerade Pro for little endian and on an SGI Indigo2 for big > endian). OK It looks like you've got a build farm with MIPS/Debian boxes -- nice. David From owner-linux-mips@oss.sgi.com Wed Mar 20 19:55:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L3t7317305 for linux-mips-outgoing; Wed, 20 Mar 2002 19:55:07 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L3t6917302 for ; Wed, 20 Mar 2002 19:55:06 -0800 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id EAA01602 for ; Thu, 21 Mar 2002 04:07:55 -0800 Subject: pci-pcmcia bridges/adapters From: Pete Popov To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 20:00:54 -0800 Message-Id: <1016683254.4951.168.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Has anyone gotten a pci-pcmcia adapter card to work with any 16 bit pcmcia card in it on mips linux? Pete From owner-linux-mips@oss.sgi.com Thu Mar 21 09:25:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHPsi01824 for linux-mips-outgoing; Thu, 21 Mar 2002 09:25:54 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LHPjq01820 for ; Thu, 21 Mar 2002 09:25:46 -0800 Received: from oval.algor.co.uk (oval.algor.co.uk [62.254.210.250]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA02334 for ; Thu, 21 Mar 2002 07:50:13 -0800 (PST) mail_from (dom@algor.co.uk) Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g2LFmR214652; Thu, 21 Mar 2002 15:48:28 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15514.199.637146.13116@gladsmuir.algor.co.uk> Date: Thu, 21 Mar 2002 15:48:23 +0000 To: "Dan Aizenstros" Cc: , , , Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) In-Reply-To: References: X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dan, > Is Algorithmics BIOS emulator not the x86emu code > that can be found in the Alpha MILO and the XFree86 > code base as Alan Cox mentioned? It's an entirely indepedent invention of the same idea. I've no idea whether it's any better/worse, but it sounded like our binary was working for Zhang better than the MILO he'd built. Dominic Algorithmics Ltd From owner-linux-mips@oss.sgi.com Thu Mar 21 09:28:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHSVH01947 for linux-mips-outgoing; Thu, 21 Mar 2002 09:28:31 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LHSOq01939 for ; Thu, 21 Mar 2002 09:28:24 -0800 Received: from quicklogic.com (quick1.quicklogic.com [206.184.225.224]) 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 HAA06077 for ; Thu, 21 Mar 2002 07:50:11 -0800 (PST) mail_from (daizenstros@quicklogic.com) Received: from qldomain-Message_Server by quicklogic.com with Novell_GroupWise; Thu, 21 Mar 2002 07:22:36 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 21 Mar 2002 07:22:02 -0800 From: "Dan Aizenstros" To: , , , Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2LHSOq01940 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello Dominic, Is Algorithmics BIOS emulator not the x86emu code that can be found in the Alpha MILO and the XFree86 code base as Alan Cox mentioned? That code was originally under GPL but was changed to a BSD style license when Kendall Bennett took over the project. The code is available at the SciTech ftp site ftp.scitechsoft.com/devel/x86emu/x86emu-0.8.tar.gz Dan Aizenstros Software Project Manager QuickLogic Canada >>> Dominic Sweetman 03/21/02 02:39 AM >>> Zhang Fuxin (fxzhang@ict.ac.cn) writes: > We have tried several cards on Algor P6032 board,but only matrox > Gxxx cards (G450 needs the latest code) can be used by linux kernel > without vga bios executed. With a x86 emulator we are able to use > Riva TNT2,and probably more can work. Unfortunately that emulator is > an executable from Algor, as a kindly help. We can't get more > control on it and finally give up... Just a note: Zhang, if you want source code of the Algorithmics simulator, we've no problem at all supplying it on our standard license. Whether that source is useful to you is another question: the BIOS emulator was created out of pieces of a complete x86 emulator, and it's a fairly complicated bit of software. One of my colleagues saw Zhang's request and said he'd consult, and then the message got lost - sorry. Our standard license is not GPL and it does have one restriction - if you build our software into something you sell, we ask you to get a further license from us before you take the money from your customers. We can be persuaded to put software out on GPL instead (as we did with the floting-point emulation code). But generally some commercial organisation - the difference only matters then, right? - has to ask nicely... -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Thu Mar 21 09:43:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHhrJ02615 for linux-mips-outgoing; Thu, 21 Mar 2002 09:43:53 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LHhkq02610 for ; Thu, 21 Mar 2002 09:43:46 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) 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 GAA07008 for ; Thu, 21 Mar 2002 06:03:27 -0800 (PST) mail_from (fxzhang@ict.ac.cn) Message-Id: <200203211403.GAA07008@sgi.com> Received: (qmail 26791 invoked from network); 21 Mar 2002 12:01:54 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 21 Mar 2002 12:01:54 -0000 Date: Thu, 21 Mar 2002 20:31:48 +0800 From: Zhang Fuxin To: Dominic Sweetman CC: "linux-mips@oss.sgi.com" Subject: Re: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2LHhlq02611 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, ÔÚ 2002-03-21 10:37:00 you wrote£º >Zhang Fuxin (fxzhang@ict.ac.cn) writes: > >> We have tried several cards on Algor P6032 board,but only matrox >> Gxxx cards (G450 needs the latest code) can be used by linux kernel >> without vga bios executed. With a x86 emulator we are able to use >> Riva TNT2,and probably more can work. Unfortunately that emulator is >> an executable from Algor, as a kindly help. We can't get more >> control on it and finally give up... > >Just a note: Zhang, if you want source code of the Algorithmics >simulator, we've no problem at all supplying it on our standard >license. Thank you for your information. We may request for it again if we could not make one. I always deem the executable as 'a kindly help' and appreciate all your contribution to mips world. > >Whether that source is useful to you is another question: the BIOS >emulator was created out of pieces of a complete x86 emulator, and >it's a fairly complicated bit of software. In fact I am interesting in this task itself,no one ask me to do it. Anyway we are a reseaching institute:).But it is a pity that mips platform can't get its own display easily,and cheaply. Just too many things to do.. Our plan is to port X86 bios emulation code(as Alan pointed out) into pmon. bochs has been considered too. > >One of my colleagues saw Zhang's request and said he'd consult, and >then the message got lost - sorry. > >Our standard license is not GPL and it does have one restriction - if >you build our software into something you sell, we ask you to get a >further license from us before you take the money from your customers. > >We can be persuaded to put software out on GPL instead (as we did with >the floating-point emulation code). But generally some commercial >organisation - the difference only matters then, right? - has to ask >nicely... Yes,i understand. > >-- >Dominic Sweetman >Algorithmics Ltd >The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND >phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 >http://www.algor.co.uk Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Thu Mar 21 10:17:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LIHq605451 for linux-mips-outgoing; Thu, 21 Mar 2002 10:17:52 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LIHoq05448 for ; Thu, 21 Mar 2002 10:17:50 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16o6Bz-0007Fu-00; Thu, 21 Mar 2002 11:17:36 -0600 Message-ID: <3C9A15AA.304AE304@cotw.com> Date: Thu, 21 Mar 2002 11:17:30 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Pete Popov CC: linux-mips Subject: Re: pci-pcmcia bridges/adapters References: <1016683254.4951.168.camel@zeus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Pete Popov wrote: > > Has anyone gotten a pci-pcmcia adapter card to work with any 16 bit > pcmcia card in it on mips linux? > Your first priority should be to look at the main PCMCIA page for Linux and find a PCI adapter that has a supported chipset, otherwise you are wasting your time. I bought a PCI->PCMCIA adapter from LinkSys for one of my wireless cards and the driver never worked, so my experience has not been good. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Thu Mar 21 11:04:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJ4JO08187 for linux-mips-outgoing; Thu, 21 Mar 2002 11:04:19 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJ49q08184 for ; Thu, 21 Mar 2002 11:04:09 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA26129; Thu, 21 Mar 2002 19:04:11 +0100 (MET) Date: Thu, 21 Mar 2002 19:04:10 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: declance multicast filter fixes 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 Hello, Following are a few trivial fixes for the DECstation's LANCE driver needed for the chip's multicast filter to be set up correctly. The patch is needed for multicast reception to work, in particular for the IPv6's neighbor discovery. The CRC generation was verified using the AMD's reference code and it was checked at the run time for selected multicast addresses as well. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.17-20020129-declance-mcast-11 diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/drivers/net/declance.c linux-mips-2.4.17-20020129/drivers/net/declance.c --- linux-mips-2.4.17-20020129.macro/drivers/net/declance.c Wed Aug 22 04:27:03 2001 +++ linux-mips-2.4.17-20020129/drivers/net/declance.c Tue Mar 19 19:42:20 2002 @@ -793,6 +793,8 @@ static int lance_open(struct net_device ib->mode = 0; ib->filter [0] = 0; ib->filter [2] = 0; + ib->filter [4] = 0; + ib->filter [6] = 0; lance_init_ring(dev); load_csrs(lp); @@ -920,7 +922,7 @@ static void lance_load_multicast(struct struct dev_mc_list *dmi = dev->mc_list; char *addrs; int i, j, bit, byte; - u32 crc, poly = CRC_POLYNOMIAL_BE; + u32 crc, poly = CRC_POLYNOMIAL_LE; /* set all multicast bits */ if (dev->flags & IFF_ALLMULTI) { @@ -959,7 +961,7 @@ static void lance_load_multicast(struct } crc = crc >> 26; - mcast_table[crc >> 3] |= 1 << (crc & 0xf); + mcast_table[2 * (crc >> 4)] |= 1 << (crc & 0xf); } return; } From owner-linux-mips@oss.sgi.com Thu Mar 21 11:18:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJIPG08639 for linux-mips-outgoing; Thu, 21 Mar 2002 11:18:25 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJILq08635 for ; Thu, 21 Mar 2002 11:18:21 -0800 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA16066; Thu, 21 Mar 2002 18:29:34 -0800 Subject: Re: pci-pcmcia bridges/adapters From: Pete Popov To: sjhill@cotw.com Cc: linux-mips In-Reply-To: <3C9A15AA.304AE304@cotw.com> References: <1016683254.4951.168.camel@zeus> <3C9A15AA.304AE304@cotw.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Mar 2002 10:22:43 -0800 Message-Id: <1016734963.24217.31.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2002-03-21 at 09:17, Steven J. Hill wrote: > Pete Popov wrote: > > > > Has anyone gotten a pci-pcmcia adapter card to work with any 16 bit > > pcmcia card in it on mips linux? > > > Your first priority should be to look at the main PCMCIA page for > Linux and find a PCI adapter that has a supported chipset, otherwise > you are wasting your time. I bought a PCI->PCMCIA adapter from LinkSys > for one of my wireless cards and the driver never worked, so my > experience has not been good. I don't really have a choice in adapters, but the one that I'm working with, Ricoh R5C478 is supported just fine by the yenta driver. The card I'm trying to get to work is a 16 bit wireless card based on the prismII chipset. The card by itself works fine in another mips board for which I wrote a socket driver. But I'm having a hell of a time with the pci-pcmcia bridge _and_ the card behind it. Attribute memory accesses do work -- they get passed to the card by the bridge and the card is recognized. But the ExCA register definition, which the bridge must support, allows for this "Optional memory window x upper byte of start address". It is this optional register that allows me to setup the 32 bit pci memory address. The IO windows registers, on the other hand, allow you to setup 16 bit addresses only. So I can't figure out how I can put a 32 bit pci address on the bus, and have the bridge forward that address to the 16 bit pcmcia card. If there's any experts in this field, I would appreciate some input. Pete From owner-linux-mips@oss.sgi.com Thu Mar 21 11:36:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJaBq09175 for linux-mips-outgoing; Thu, 21 Mar 2002 11:36:11 -0800 Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJa8q09172 for ; Thu, 21 Mar 2002 11:36:08 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id g2LIa4c00134 for ; Thu, 21 Mar 2002 19:36:05 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HJ082VZQ; Thu, 21 Mar 2002 19:36:03 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Thu, 21 Mar 2002 19:36:03 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 19:36:07 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E828@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: Kernel compile with -O0 Date: Thu, 21 Mar 2002 19:36:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi. When I try to compile my 2.4.3 Kernel with -O0 I get a lot of undefined references to functions like __cli, clear_bit etc. during linking. With -O1 it works. Do I have to provide some special compile option to make this work? best regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Thu Mar 21 11:09:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJ9DU10294 for linux-mips-outgoing; Thu, 21 Mar 2002 11:09:13 -0800 Received: from quicklogic.com (quick1.quicklogic.com [206.184.225.224]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJ9Aq10290 for ; Thu, 21 Mar 2002 11:09:10 -0800 Received: from qldomain-Message_Server by quicklogic.com with Novell_GroupWise; Thu, 21 Mar 2002 11:11:32 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 21 Mar 2002 11:10:56 -0800 From: "Dan Aizenstros" To: , , , Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2LJ9Aq10291 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello Dominic, Actually it was Girish Gulawani who said he used the MILO bios not Zhang. He said he was using the files vgaraw1.c and vgaraw2.c from MILO. Those files do not use the x86emu BIOS emulator but try to directly initialize the VGA adapter. Dan Aizenstros Software Project Manager QuickLogic Canada >>> Dominic Sweetman 03/21/02 08:28 AM >>> Dan, > Is Algorithmics BIOS emulator not the x86emu code > that can be found in the Alpha MILO and the XFree86 > code base as Alan Cox mentioned? It's an entirely indepedent invention of the same idea. I've no idea whether it's any better/worse, but it sounded like our binary was working for Zhang better than the MILO he'd built. Dominic Algorithmics Ltd From owner-linux-mips@oss.sgi.com Thu Mar 21 11:19:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJJDO10737 for linux-mips-outgoing; Thu, 21 Mar 2002 11:19:13 -0800 Received: from tibook.netx4.com ([209.113.146.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJJAq10734 for ; Thu, 21 Mar 2002 11:19:10 -0800 Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1]) by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id g2LJLW100683; Thu, 21 Mar 2002 14:21:32 -0500 Message-ID: <3C9A32B9.7000307@embeddededge.com> Date: Thu, 21 Mar 2002 14:21:29 -0500 From: Dan Malek Organization: Embedded Edge, LLC. User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.11-pre6-ben0 ppc; en-US; 0.8) Gecko/20010419 X-Accept-Language: en MIME-Version: 1.0 To: sjhill@cotw.com CC: Pete Popov , linux-mips Subject: Re: pci-pcmcia bridges/adapters References: <1016683254.4951.168.camel@zeus> <3C9A15AA.304AE304@cotw.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Steven J. Hill wrote: > ....of my wireless cards and the driver never worked, so my > experience has not been good. I have been working with quite a few wireless cards in embedded systems and have discovered they are quite sensitive to reset after power up. The power-on, reset, first access to the card seems to have some timing considerations that some socket drivers can handle better than others. Before you assume the bridge and its related software are at fault, try a variety of cards not sensitive to this, like a CF in a PCMCIA adapter. I got burned by this again yesterday :-). -- Dan From owner-linux-mips@oss.sgi.com Thu Mar 21 12:05:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LK5Tf20660 for linux-mips-outgoing; Thu, 21 Mar 2002 12:05:29 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LK5Mq20652 for ; Thu, 21 Mar 2002 12:05:23 -0800 Received: from prefect (prefect.local [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id 02026590B2; Thu, 21 Mar 2002 15:02:05 -0500 (EST) Message-ID: <017701c1d114$2a1bca60$5601010a@prefect> From: "Bradley D. LaRonde" To: , References: <86048F07C015D311864100902760F1DD01B5E828@dlfw003a.dus.infineon.com> Subject: Re: Kernel compile with -O0 Date: Thu, 21 Mar 2002 15:06:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk That turns off inlining, which the kernel *requires*. Regards, Brad ----- Original Message ----- From: To: Sent: Thursday, March 21, 2002 1:36 PM Subject: Kernel compile with -O0 > Hi. > > When I try to compile my 2.4.3 Kernel with -O0 I get a lot of undefined > references to functions like __cli, clear_bit etc. during linking. With -O1 > it works. > > Do I have to provide some special compile option to make this work? > > best regards > -- > Andre Messerschmidt > > Application Engineer > Infineon Technologies AG > From owner-linux-mips@oss.sgi.com Thu Mar 21 17:22:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M1MbM28660 for linux-mips-outgoing; Thu, 21 Mar 2002 17:22:37 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2M1MYq28657 for ; Thu, 21 Mar 2002 17:22:35 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2M1OwV15459; Thu, 21 Mar 2002 17:24:58 -0800 Date: Thu, 21 Mar 2002 17:24:58 -0800 From: Ralf Baechle To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Kernel compile with -O0 Message-ID: <20020321172457.A15031@dea.linux-mips.net> References: <86048F07C015D311864100902760F1DD01B5E828@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DD01B5E828@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Thu, Mar 21, 2002 at 07:36:06PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Mar 21, 2002 at 07:36:06PM +0100, Andre.Messerschmidt@infineon.com wrote: > When I try to compile my 2.4.3 Kernel with -O0 I get a lot of undefined > references to functions like __cli, clear_bit etc. during linking. With -O1 > it works. > > Do I have to provide some special compile option to make this work? Stupid answer: Yes, -O. Less stupid answer - -O1 and higher imply function inlining which is required to build the kernel. Ralf From owner-linux-mips@oss.sgi.com Thu Mar 21 21:23:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M5NjA07184 for linux-mips-outgoing; Thu, 21 Mar 2002 21:23:45 -0800 Received: from granite.he.net (granite.he.net [216.218.226.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M5Ngq07181 for ; Thu, 21 Mar 2002 21:23:42 -0800 Received: from w2k30g (209-142-39-228.stk.inreach.net [209.142.39.228]) by granite.he.net (8.8.6/8.8.2) with SMTP id VAA08085 for ; Thu, 21 Mar 2002 21:26:05 -0800 Delivered-To: Message-ID: <001401c1d161$eef48640$0b01a8c0@w2k30g> From: "David Christensen" To: Subject: Fw: Fw: Fw: hello Date: Thu, 21 Mar 2002 21:24:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com: Hartvig Ekner wrote: >> What host hardware platform(s) and host operating system(s) does MIPS >> use to build their MIPS Linux distribution as found on >> ftp://ftp.mips.com/pub/linux/mips/? > > We use commercial Redhat x86/Linux hosts with the cross compiler link > I sent for kernel compiles. All the binary RPM's are directly from > H.J.s miniport (which I believe is mostly crosscompiled), and then we > added some of the nfs/cdrom installation scripts around all this. We > only rebuild parts of userland (most often native) from the SRPMS when > necessary for internal debug etc, but this is purely for debug, not > re-distribution. > > All of H.J's binary RPMs for the userland and the corresponding source > RPMs we used can be found at: > > ftp://oss.sgi.com/pub/linux/mips/redhat/7 Great! Thanks for all the help. :-) David From owner-linux-mips@oss.sgi.com Thu Mar 21 21:44:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M5iIL07473 for linux-mips-outgoing; Thu, 21 Mar 2002 21:44:18 -0800 Received: from mgate1.ntust.edu.tw (mgate1.ntust.edu.tw [140.118.31.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M5iEq07470 for ; Thu, 21 Mar 2002 21:44:16 -0800 Received: (from root@localhost) by mgate1.ntust.edu.tw (8.11.6/8.11.3) id g2M5kSv54155 for linux-mips@oss.sgi.com.AVP; Fri, 22 Mar 2002 13:46:28 +0800 (CST) Received: from smtp.ntust.edu.tw (smtp.ntust.edu.tw [140.118.31.67]) by mgate1.ntust.edu.tw (8.11.6/8.11.3) with ESMTP id g2M5hvr52292 for ; Fri, 22 Mar 2002 13:43:58 +0800 (CST) Received: from totoro.ee.ntust.edu.tw (totoro.ee.ntust.edu.tw [140.118.7.13]) by smtp.ntust.edu.tw (8.12.2/8.12.2) with ESMTP id g2M5hpqD013435 for ; Fri, 22 Mar 2002 13:43:51 +0800 (CST) Received: from localhost (chang@localhost) by totoro.ee.ntust.edu.tw (8.11.6/8.8.7) with ESMTP id g2M5hmG01505 for ; Fri, 22 Mar 2002 13:43:48 +0800 Date: Fri, 22 Mar 2002 13:43:48 +0800 (CST) From: Aladdin Chang To: Subject: Kernel space .. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Does mips-linux can handle more than 512M(0x80000000 ~ 0x9fffffff) kernel memory? From owner-linux-mips@oss.sgi.com Fri Mar 22 00:18:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M8IPe10915 for linux-mips-outgoing; Fri, 22 Mar 2002 00:18:25 -0800 Received: from ms45.hinet.net (root@ms45.hinet.net [168.95.4.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M8IMq10912 for ; Fri, 22 Mar 2002 00:18:22 -0800 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by ms45.hinet.net (8.8.8/8.8.8) with SMTP id QAA13645 for ; Fri, 22 Mar 2002 16:20:43 +0800 (CST) From: "Y.H. Ku" To: Subject: BootLoader on MIPS Date: Fri, 22 Mar 2002 16:16:28 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g2M8INq10913 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello there, I am trying to porting Prom monitor code to appropriate MIPS bootloader for loading Linux kernel I ever make a test sucessfully with ppcboot's to load MBXloader for transfering control to linux kernel (hardhat). But I can not find the entry, and make decision what kind of BOOT LOADER to use on MIPS platform. I have the ddb5476 board type linux from montavista, Could anybody give me some suggestion? --Sam From owner-linux-mips@oss.sgi.com Fri Mar 22 03:06:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MB6IA16202 for linux-mips-outgoing; Fri, 22 Mar 2002 03:06:18 -0800 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MB6Eq16199 for ; Fri, 22 Mar 2002 03:06:14 -0800 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id A0F6D2B303; Fri, 22 Mar 2002 11:08:27 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 6F5FEE95F; Fri, 22 Mar 2002 11:08:27 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 6DFD97243; Fri, 22 Mar 2002 11:08:27 +0000 (GMT) Date: Fri, 22 Mar 2002 11:08:27 +0000 (GMT) From: Dave Airlie X-X-Sender: To: "Maciej W. Rozycki" Cc: Ralf Baechle , , Subject: Re: [patch] linux: declance multicast filter fixes 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 I've created declance_2_4.c on http://www.csn.ul.ie/~airlied/mips for the DS5000/200 series of DecStations.. it only required the BE -> LE and the additional zeroing of the filter, it already did the mcast_table access correctly... (by luck rather than design :-) un-compiled and untested but it should work .. Dave. On Thu, 21 Mar 2002, Maciej W. Rozycki wrote: > Hello, > > Following are a few trivial fixes for the DECstation's LANCE driver > needed for the chip's multicast filter to be set up correctly. The patch > is needed for multicast reception to work, in particular for the IPv6's > neighbor discovery. The CRC generation was verified using the AMD's > reference code and it was checked at the run time for selected multicast > addresses as well. Please apply. > > Maciej > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Fri Mar 22 03:42:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MBgqk17164 for linux-mips-outgoing; Fri, 22 Mar 2002 03:42:52 -0800 Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MBgjq17161 for ; Fri, 22 Mar 2002 03:42:45 -0800 Received: from girishvg (AUTH login) at i205206.ppp.asahi-net.or.jp (HELO nazneen) (girishvg@61.125.205.206) by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Mar 2002 11:45:08 -0000 Message-ID: <00c001c1d197$4a5c14a0$cecd7d3d@gol.com> From: "Girish Gulawani" To: "Dan Aizenstros" , , , References: Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) Date: Fri, 22 Mar 2002 20:47:02 +0900 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 hello, all thank you very much for all these reply mails. my saga of VGA initialization continues. it occurs to me that the x86 emulation for the VGA bios is a long process. SiS6326 chipset has support inside XFree86 & digging out the BIOS code from here is also a big story. hence i was looking for a rather quickish solution. currently i'm trying to use sis_*.c files from XFree86 source. dont know how but my monitor displays 2 red & 1 green vertical lines. the sis_bios source code searched for the mode, memory references inside the BIOS at 0x20A offset & it failed to find the mode & other info. AOpen BIOS version is 2.25. could anybody of you please share your success story of VGA initialization on MIPS board with me?? many thanks in advance. regards, girish. ----- Original Message ----- From: "Dan Aizenstros" To: ; ; ; Sent: Friday, March 22, 2002 4:10 AM Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) Hello Dominic, Actually it was Girish Gulawani who said he used the MILO bios not Zhang. He said he was using the files vgaraw1.c and vgaraw2.c from MILO. Those files do not use the x86emu BIOS emulator but try to directly initialize the VGA adapter. Dan Aizenstros Software Project Manager QuickLogic Canada >>> Dominic Sweetman 03/21/02 08:28 AM >>> Dan, > Is Algorithmics BIOS emulator not the x86emu code > that can be found in the Alpha MILO and the XFree86 > code base as Alan Cox mentioned? It's an entirely indepedent invention of the same idea. I've no idea whether it's any better/worse, but it sounded like our binary was working for Zhang better than the MILO he'd built. Dominic Algorithmics Ltd _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Fri Mar 22 05:19:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MDJbD20965 for linux-mips-outgoing; Fri, 22 Mar 2002 05:19:37 -0800 Received: from mail.ivivity.com ([64.238.111.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MDJTq20959 for ; Fri, 22 Mar 2002 05:19:29 -0800 Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 08:21:52 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2195BD9@ATLOPS> From: Marc Karasek To: "'Y.H. Ku'" , linux-mips@oss.sgi.com Subject: RE: BootLoader on MIPS Date: Fri, 22 Mar 2002 08:20:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D1A4.62EAC7C0" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D1A4.62EAC7C0 Content-Type: text/plain; charset="big5" YAMON is prob the default right now. It has support for loading a kernel over tftp. I do not think it is OS though. I maybe wrong, I will have to check the source I have to see if it is or not. I am currently adding BOOTP support to it, along with some other options. If it is OS, then I will be providing these back to the community. /******************************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. Ph: 678-990-1550 x238 Fax: 678-990-1551 email: marc_karasek@ivivity.com /******************************************* -----Original Message----- From: Y.H. Ku [mailto:iskoo@ms45.hinet.net] Sent: Friday, March 22, 2002 3:16 AM To: linux-mips@oss.sgi.com Subject: BootLoader on MIPS Hello there, I am trying to porting Prom monitor code to appropriate MIPS bootloader for loading Linux kernel I ever make a test sucessfully with ppcboot's to load MBXloader for transfering control to linux kernel (hardhat). But I can not find the entry, and make decision what kind of BOOT LOADER to use on MIPS platform. I have the ddb5476 board type linux from montavista, Could anybody give me some suggestion? --Sam ------_=_NextPart_000_01C1D1A4.62EAC7C0 Content-Type: application/octet-stream; name="Marc Karasek.vcf" Content-Disposition: attachment; filename="Marc Karasek.vcf" BEGIN:VCARD VERSION:2.1 N:Karasek;Marc FN:Marc Karasek ORG:Ivivity TITLE:Senior Software Engineer NOTE:Senior Software Engineer TEL;WORK;VOICE:210 ADR;WORK:;Atlanta LABEL;WORK:Atlanta EMAIL;PREF;INTERNET:marc_karasek@ivivity.com REV:20011130T233616Z END:VCARD ------_=_NextPart_000_01C1D1A4.62EAC7C0-- From owner-linux-mips@oss.sgi.com Fri Mar 22 07:12:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MFC4E23338 for linux-mips-outgoing; Fri, 22 Mar 2002 07:12:04 -0800 Received: from quicklogic.com (quick1.quicklogic.com [206.184.225.224]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MFBtq23333 for ; Fri, 22 Mar 2002 07:11:55 -0800 Received: from qldomain-Message_Server by quicklogic.com with Novell_GroupWise; Fri, 22 Mar 2002 07:14:09 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 22 Mar 2002 07:13:40 -0800 From: "Dan Aizenstros" To: , Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2MFBtq23334 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello Girish, I have used the x86emu code to run the BIOS code on an ATI Rage IIC PCI adapter. I added the code to the PMON that I build for my company's Hurricane board. The code for the emulator does not require a lot of work because it is seperated between portable code that is not board or system specific and glue code that is. In the x86emu-0.8.tar.gz archive you will find the portable code in the directory scitech/src/x86emu. The code in scitech/src/biosemu can be used as a starting point for creating the glue code. Dan Aizenstros Software Project Manager QuickLogic Canada >>> "Girish Gulawani" 03/22/02 03:45 AM >>> hello, all thank you very much for all these reply mails. my saga of VGA initialization continues. it occurs to me that the x86 emulation for the VGA bios is a long process. SiS6326 chipset has support inside XFree86 & digging out the BIOS code from here is also a big story. hence i was looking for a rather quickish solution. currently i'm trying to use sis_*.c files from XFree86 source. dont know how but my monitor displays 2 red & 1 green vertical lines. the sis_bios source code searched for the mode, memory references inside the BIOS at 0x20A offset & it failed to find the mode & other info. AOpen BIOS version is 2.25. could anybody of you please share your success story of VGA initialization on MIPS board with me?? many thanks in advance. regards, girish. ----- Original Message ----- From: "Dan Aizenstros" To: ; ; ; Sent: Friday, March 22, 2002 4:10 AM Subject: Re: Re: PCI VGA Card Initilization (SI6326 / PT80) Hello Dominic, Actually it was Girish Gulawani who said he used the MILO bios not Zhang. He said he was using the files vgaraw1.c and vgaraw2.c from MILO. Those files do not use the x86emu BIOS emulator but try to directly initialize the VGA adapter. Dan Aizenstros Software Project Manager QuickLogic Canada >>> Dominic Sweetman 03/21/02 08:28 AM >>> Dan, > Is Algorithmics BIOS emulator not the x86emu code > that can be found in the Alpha MILO and the XFree86 > code base as Alan Cox mentioned? It's an entirely indepedent invention of the same idea. I've no idea whether it's any better/worse, but it sounded like our binary was working for Zhang better than the MILO he'd built. Dominic Algorithmics Ltd _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Fri Mar 22 08:47:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MGlbf25426 for linux-mips-outgoing; Fri, 22 Mar 2002 08:47:37 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MGlLq25408; Fri, 22 Mar 2002 08:47:22 -0800 Received: from dev1 (unknown [10.1.1.85]) by ns1.ltc.com (Postfix) with ESMTP id 09A13590B2; Fri, 22 Mar 2002 11:44:17 -0500 (EST) Received: from brad by dev1 with local (Exim 3.34 #1 (Debian)) id 16oSDZ-0004x8-00; Fri, 22 Mar 2002 11:48:41 -0500 Date: Fri, 22 Mar 2002 11:48:37 -0500 To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: [PATCH] Clear BEV in init_traps Message-ID: <20020322114837.A19038@dev1.ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i From: "Bradley D. LaRonde" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This used to happen in head.S, then got moved to per_cpu_trap_init, but that only covers secondary cpus. This takes care of the boot cpu. Regards, Brad diff -urNbB -X ../diff-linux-exclude ../oss/linux-oss-2.4-2002-03-19/arch/mips/kernel/traps.c linux-encore-oss-merge/arch/mips/kernel/traps.c --- ../oss/linux-oss-2.4-2002-03-19/arch/mips/kernel/traps.c Tue Mar 19 20:18:36 2002 +++ linux-encore-oss-merge/arch/mips/kernel/traps.c Fri Mar 22 09:58:36 2002 @@ -852,6 +852,9 @@ extern char except_vec_ejtag_debug; unsigned long i; + /* Some firmware leaves the BEV flag set, clear it. */ + clear_cp0_status(ST0_BEV); + /* Copy the generic exception handler code to it's final destination. */ memcpy((void *)(KSEG0 + 0x80), &except_vec1_generic, 0x80); memcpy((void *)(KSEG0 + 0x100), &except_vec2_generic, 0x80); From owner-linux-mips@oss.sgi.com Fri Mar 22 13:32:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MLWoL31212 for linux-mips-outgoing; Fri, 22 Mar 2002 13:32:50 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MLWlq31209 for ; Fri, 22 Mar 2002 13:32:47 -0800 Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g2MLX4923602 for ; Fri, 22 Mar 2002 16:33:04 -0500 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g2MLZAm02254 for ; Fri, 22 Mar 2002 16:35:10 -0500 Received: from redhat.com (dhcp-166.hsv.redhat.com [172.16.17.166]) by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id g2MLZGN08930 for ; Fri, 22 Mar 2002 15:35:16 -0600 Message-ID: <3C9BA339.5030709@redhat.com> Date: Fri, 22 Mar 2002 15:33:45 -0600 From: Lanny DeVaney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: RTC setup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm having trouble figuring out how to setup the RTC for my Linux port. My board has a Dallas DS1501WE chip, and I can't figure out the rhyme or reason for the addr values passed to my rtc_write_data callback from the kernel. I know my RTC base address, and can in fact go in and look and see the date/time values at that location. It appears for the mips boards that have rtc support in the kernel (some do not), the actual code inside these callbacks differs, but I noted that the DEC references a Dallas chip, others appear to use other rtc chips. I would have assumed that the addr value passed to my rtc_write_data callback would have been sequential in nature and I would simply return the value at the (rtc_base_addr + offset passed in as addr), but the addr values I see coming in are really sporadic. Can anybody offer any suggestions, or does anybody know what the addr values pased into the callback refer to? Thanks, Lanny DeVaney Red Hat, Inc. From owner-linux-mips@oss.sgi.com Fri Mar 22 14:12:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MMCmu32236 for linux-mips-outgoing; Fri, 22 Mar 2002 14:12:48 -0800 Received: from gda-server ([202.88.152.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MMCeq32232 for ; Fri, 22 Mar 2002 14:12:40 -0800 Received: from [192.168.0.157] by gda-server (ArGoSoft Mail Server, Version 1.5 (1.5.0.8)); Sat, 23 Mar 2002 03:47:18 Message-ID: <007201c1d1ee$83bb33f0$9d00a8c0@sathya> From: "Sathya.N" To: "gcc" , Cc: Subject: Bug in Assertion failure in macro_build_lui ....tc-mips.c Date: Sat, 23 Mar 2002 03:41:25 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I am building the qla2x00.c driver (Fibre channel driver from Qlogic) as loadable module for our IP under Red Hat Linux 7.2(kernel version is 2.4.x) We are using the Broadcom's BCM12500 Processor (MIPS Core).When I compiled the code , I am getting the output as given below. After the warnings ,you could see {standard input} Assembler messages: etc., Could you please help me in sorting out this bug? Here Qlogic is my Fibre Channel source code directory. [root@localhost Qlogic]# make SMP=1 /usr/local/sbtools/x86-linux-rh7.1/mips-linux-2.1.1/bin/mips-linux-gcc -D__K ERNEL__ -DMODULE -Wall -O2 -DISP2200 -DMODVERSIONS -include /home/sathya/linux/src/linux/include/linux/modsetver.h -I/home/sathya/linux/ src/linux/include -I/home/sathya/linux/src/linux/include/../drivers/scsi -Wa ll -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -pipe -fno- strict-aliasing -mcpu=sb1 -mips2 -mgp32 -mlong32 -mips16 -EB -D__SMP__ -CON FIG_SMP -c -o qla2x00.o qla2x00.c In file included from qla2x00.c:384: /home/sathya/linux/src/linux/include/linux/malloc.h:4:2: warning: #warning linux/malloc.h is deprecated, use linux/slab.h instead. qla2x00.c: In function `qla2100_proc_info': qla2x00.c:1146: warning: long int format, int arg (arg 4) qla2x00.c:1146: warning: unsigned int format, long int arg (arg 5) qla2x00.c:1146: warning: unsigned int format, pointer arg (arg 8) {standard input}: Assembler messages: {standard input}:119338: Internal error! Assertion failure in macro_build_lui at /home/cgd/proj/sb/systemsw-2.1.1/lin.x/systemsw/tools/src/binutils/gas/confi g/tc-mips.c line 3101. Please report this bug. make: [qla2x00.o] Error 2* Regards & Thanks, N.Sathyanarayana Member Technical Staff GDA Technologies Ltd., Chennai India www.gdatech.com catch me at : n.sathya@gdatech.co.in From owner-linux-mips@oss.sgi.com Fri Mar 22 14:51:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MMpF400338 for linux-mips-outgoing; Fri, 22 Mar 2002 14:51:15 -0800 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MMpBq00335 for ; Fri, 22 Mar 2002 14:51:11 -0800 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (SGI-8.9.3/8.9.3) with ESMTP id XAA28295 for ; Fri, 22 Mar 2002 23:53:33 +0100 (MET) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.34 #1 (Debian)) id 16oXuf-0001f6-00 for ; Fri, 22 Mar 2002 23:53:33 +0100 Date: Fri, 22 Mar 2002 23:53:33 +0100 To: linux-mips@oss.sgi.com Subject: Re: Bug in Assertion failure in macro_build_lui ....tc-mips.c Message-ID: <20020322225332.GA13314@rembrandt.csv.ica.uni-stuttgart.de> References: <007201c1d1ee$83bb33f0$9d00a8c0@sathya> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007201c1d1ee$83bb33f0$9d00a8c0@sathya> User-Agent: Mutt/1.3.27i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Sathya.N wrote: > > Hi, > > I am building the qla2x00.c driver (Fibre channel driver from Qlogic) as > loadable module for our IP under Red Hat Linux 7.2(kernel version is 2.4.x) > We are using the Broadcom's BCM12500 Processor (MIPS Core).When I compiled > the code , I am getting the output as given below. After the warnings ,you > could see {standard input} Assembler messages: etc., Which binutils (gas) version are you using? > /home/sathya/linux/src/linux/include/linux/modsetver.h -I/home/sathya/linux/ > src/linux/include -I/home/sathya/linux/src/linux/include/../drivers/scsi -Wa > ll -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -pipe -fno- > strict-aliasing -mcpu=sb1 -mips2 -mgp32 -mlong32 -mips16 -EB -D__SMP__ -CON > FIG_SMP -c -o qla2x00.o qla2x00.c Could you add "-v --save-temps" to this command to find out how the assembler is invoked and what the assembly in qla2x00.s looks like? Thiemo From owner-linux-mips@oss.sgi.com Fri Mar 22 17:51:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2N1pVX03288 for linux-mips-outgoing; Fri, 22 Mar 2002 17:51:31 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2N1pPq03278 for ; Fri, 22 Mar 2002 17:51:26 -0800 Received: from prefect (prefect.local [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id 5FA56590B2; Fri, 22 Mar 2002 20:48:29 -0500 (EST) Message-ID: <04c901c1d20d$bfb061e0$5601010a@prefect> From: "Bradley D. LaRonde" To: "Pete Popov" , References: <1016845916.24217.298.camel@zeus> Subject: Re: [Linux-mips-kernel]io.h patch Date: Fri, 22 Mar 2002 20:55:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Pete Popov" To: "sforge" Sent: Friday, March 22, 2002 8:11 PM Subject: [Linux-mips-kernel]io.h patch > Some of the macros in io.h cause compile problems in some of the drivers > because of the do while syntax. I don't see any good reason why we > can't make those macros inline functions. Any objections to this patch? I pester Ralf about this from time to time. The standing objection is that some older gccs don't do inline well. Regards, Brad From owner-linux-mips@oss.sgi.com Fri Mar 22 17:55:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2N1t9L03398 for linux-mips-outgoing; Fri, 22 Mar 2002 17:55:09 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2N1t6q03395 for ; Fri, 22 Mar 2002 17:55:06 -0800 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id CAA23331; Sat, 23 Mar 2002 02:08:41 -0800 Subject: Re: [Linux-mips-kernel]io.h patch From: Pete Popov To: "Bradley D. LaRonde" Cc: linux-mips In-Reply-To: <04c901c1d20d$bfb061e0$5601010a@prefect> References: <1016845916.24217.298.camel@zeus> <04c901c1d20d$bfb061e0$5601010a@prefect> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Mar 2002 18:02:12 -0800 Message-Id: <1016848932.24387.317.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2002-03-22 at 17:55, Bradley D. LaRonde wrote: > > ----- Original Message ----- > From: "Pete Popov" > To: "sforge" > Sent: Friday, March 22, 2002 8:11 PM > Subject: [Linux-mips-kernel]io.h patch > > > > Some of the macros in io.h cause compile problems in some of the drivers > > because of the do while syntax. I don't see any good reason why we > > can't make those macros inline functions. Any objections to this patch? > > I pester Ralf about this from time to time. The standing objection is that > some older gccs don't do inline well. That's all true and, in fact, I had run into a compiler problem some time ago. However, even then I was able to simply rearrange my C routine a bit and then the compiler was happy. Having pci-cardbus support on mips is kind of cool. Running wireless cards off of it is even better. Not being able to compile the drivers because of io.h isn't. Pete From owner-linux-mips@oss.sgi.com Fri Mar 22 20:46:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2N4k4204938 for linux-mips-outgoing; Fri, 22 Mar 2002 20:46:04 -0800 Received: from paul.rutgers.edu (paul.rutgers.edu [128.6.5.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2N4jtq04935 for ; Fri, 22 Mar 2002 20:45:55 -0800 Received: (from muthur@localhost) by paul.rutgers.edu (8.10.2+Sun/8.8.8) id g2N4mIg06476; Fri, 22 Mar 2002 23:48:18 -0500 (EST) Date: Fri, 22 Mar 2002 23:48:18 -0500 (EST) From: Muthukumar Ratty To: linux-mips@oss.sgi.com Subject: Lost when execve-ing the init. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I was trying a kernel I made and found that I got lost after it goes to execve("/sbin/init") in init/main.c. I can ping the board which means the board is alive. I tried to trace it down but got stuck with the following code in "include/asm-mips/unistd.h" [ I believe it implements the execve function since in the same file I have ..... static inline _syscall3(int,execve,const char *,file,char **,argv,char **,envp)] ------------------------------------------------------------------------------ #define _syscall3(type,name,atype,a,btype,b,ctype,c) \ type name (atype a, btype b, ctype c) \ { \ long __res, __err; \ __asm__ volatile ("move\t$4,%3\n\t" \ "move\t$5,%4\n\t" \ "move\t$6,%5\n\t" \ "li\t$2,%2\n\t" \ "syscall\n\t" \ "move\t%0, $2\n\t" \ "move\t%1, $7" \ : "=r" (__res), "=r" (__err) \ : "i" (__NR_##name),"r" ((long)(a)), \ "r" ((long)(b)), \ "r" ((long)(c)) \ : "$2","$4","$5","$6","$7","$8","$9","$10","$11","$12", \ "$13","$14","$15","$24"); \ if (__err == 0) \ return (type) __res; \ errno = __res; \ return -1; \ } --------------------------------------------------------------------------- I guess... After setting up the arguments its referencing (#defined ???) syscall. I couldnt find the definition for "syscall". Could someone point me to the right place (and help me get some sleep please ;). Also any idea about how to debug this. (Can I set breakpoint in syscall3??). (Any idea why its not going.. error in my irq setup??...) Thanks a lot, Muthu. PS : what does this funny thing mean??? : "=r" (__res), "=r" (__err) \ : "i" (__NR_##name),"r" ((long)(a)), \ "r" ((long)(b)), \ "r" ((long)(c)) \ : "$2","$4","$5","$6","$7","$8","$9","$10","$11","$12", \ "$13","$14","$15","$24"); \ if (__err == 0) \ From owner-linux-mips@oss.sgi.com Sat Mar 23 00:45:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2N8j4207222 for linux-mips-outgoing; Sat, 23 Mar 2002 00:45:04 -0800 Received: from ms45.hinet.net (root@ms45.hinet.net [168.95.4.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2N8isq07219 for ; Sat, 23 Mar 2002 00:44:55 -0800 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by ms45.hinet.net (8.8.8/8.8.8) with SMTP id QAA04899; Sat, 23 Mar 2002 16:47:06 +0800 (CST) From: "Y.H. Ku" To: "Marc Karasek" , Subject: RE: BootLoader on MIPS Date: Sat, 23 Mar 2002 16:42:41 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <25369470B6F0D41194820002B328BDD2195BD9@ATLOPS> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g2N8iuq07220 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi everybody, I trace PMON into mips.S, and find the entry "_go". the entry transfer control to client prog. I am confused of what information PMON transfer to MIPS's BOOTLOADER and transfer to which entry point of BOOTLOADER. I found the bd_t struct of PPCBOOT.h for PPCBOOT package on POWERPC platform. It is corresponding POWERPC-LINUX data structure bd_info in ~/include/asm/mbx.h (register r3~r7) I just can not find the entry for MIPS's one. (can not find corresponding baget.h's one) Could anybody tell me what is the information (register inforation) PMON transfer to bootloader? Or anybody can disscuss with me, best regards, --sam -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Marc Karasek Sent: Friday, March 22, 2002 9:21 PM To: 'Y.H. Ku'; linux-mips@oss.sgi.com Subject: RE: BootLoader on MIPS YAMON is prob the default right now. It has support for loading a kernel over tftp. I do not think it is OS though. I maybe wrong, I will have to check the source I have to see if it is or not. I am currently adding BOOTP support to it, along with some other options. If it is OS, then I will be providing these back to the community. /******************************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. Ph: 678-990-1550 x238 Fax: 678-990-1551 email: marc_karasek@ivivity.com /******************************************* -----Original Message----- From: Y.H. Ku [mailto:iskoo@ms45.hinet.net] Sent: Friday, March 22, 2002 3:16 AM To: linux-mips@oss.sgi.com Subject: BootLoader on MIPS Hello there, I am trying to porting Prom monitor code to appropriate MIPS bootloader for loading Linux kernel I ever make a test sucessfully with ppcboot's to load MBXloader for transfering control to linux kernel (hardhat). But I can not find the entry, and make decision what kind of BOOT LOADER to use on MIPS platform. I have the ddb5476 board type linux from montavista, Could anybody give me some suggestion? --Sam From owner-linux-mips@oss.sgi.com Sat Mar 23 05:59:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NDxJV10735 for linux-mips-outgoing; Sat, 23 Mar 2002 05:59:19 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2NDxFq10732 for ; Sat, 23 Mar 2002 05:59:15 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA16944; Sat, 23 Mar 2002 15:01:49 +0100 (MET) Date: Sat, 23 Mar 2002 15:01:48 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Dave Airlie cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: declance multicast filter fixes In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 22 Mar 2002, Dave Airlie wrote: > I've created declance_2_4.c on http://www.csn.ul.ie/~airlied/mips > > for the DS5000/200 series of DecStations.. Thanks for the reference -- I definitely want to look how to merge the drivers one day (well, actually the LANCE core should be common to all drivers eventually). There is certainly no point in keeping your code separately. I suppose your driver should work for the PMAD card as well. > it only required the BE -> LE and the additional zeroing of the filter, it > already did the mcast_table access correctly... (by luck rather than > design :-) Well, the I/O ASIC wiring of LANCE is weird. -- + 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 Sat Mar 23 14:05:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NM5RC19269 for linux-mips-outgoing; Sat, 23 Mar 2002 14:05:27 -0800 Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2NM5Gq19263 for ; Sat, 23 Mar 2002 14:05:16 -0800 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020323220734.UTED1147.rwcrmhc52.attbi.com@ocean.lucon.org>; Sat, 23 Mar 2002 22:07:34 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id B3A21125C7; Sat, 23 Mar 2002 14:07:28 -0800 (PST) Date: Sat, 23 Mar 2002 14:07:28 -0800 From: "H . J . Lu" To: Andrew Morton Cc: tytso@thunk.org, linux-mips@oss.sgi.com Subject: Does e2fsprogs-1.26 work on mips? Message-ID: <20020323140728.A4306@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I got [root@localhost e2fsprogs-1.26]# ./e2fsck/e2fsck -f /dev/hda1 e2fsck 1.26 (3-Feb-2002) Pass 1: Checking inodes, blocks, and sizes File size limit exceeded on Linux/mipsel. /dev/hda1 is a 7GB ext3 partition. e2fsprogs-1.23 works fine. Strace open("/dev/hda1", O_RDWR|O_LARGEFILE) = 4 fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 1), ...}) = 0 setrlimit(RLIMIT_FSIZE, {rlim_cur=-1, rlim_max=-1}) = 0 getrlimit(RLIMIT_FSIZE, {rlim_cur=-1, rlim_max=-1}) = 0 lseek(4, 1024, SEEK_SET) = 1024 read(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = 102 4 lseek(4, 4096, SEEK_SET) = 4096 read(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 40 96 time(NULL) = 1016919001 lseek(4, 1072, SEEK_SET) = 1072 write(4, "\331\363", 2) = 2 lseek(4, 1120, SEEK_SET) = 1120 write(4, "\2\0", 2) = 2 lseek(4, 4096, SEEK_SET) = 4096 write(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4 096 lseek(4, 134217728, SEEK_SET) = 134217728 write(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = 10 24 lseek(4, 134221824, SEEK_SET) = 134221824 write(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4 096 lseek(4, 402653184, SEEK_SET) = 402653184 write(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = 10 24 lseek(4, 402657280, SEEK_SET) = 402657280 write(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4 096 lseek(4, 671088640, SEEK_SET) = 671088640 write(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = 10 24 lseek(4, 671092736, SEEK_SET) = 671092736 write(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4 096 lseek(4, 939524096, SEEK_SET) = 939524096 write(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = 10 24 lseek(4, 939528192, SEEK_SET) = 939528192 write(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4 096 lseek(4, 1207959552, SEEK_SET) = 1207959552 write(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = 10 24 lseek(4, 1207963648, SEEK_SET) = 1207963648 write(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4 096 _llseek(4, 18446744072770027520, [3355443200], SEEK_SET) = 0 write(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = 10 24 _llseek(4, 18446744072770031616, [3355447296], SEEK_SET) = 0 write(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4 096 _llseek(4, 18446744073038462976, [3623878656], SEEK_SET) = 0 write(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = 10 24 _llseek(4, 18446744073038467072, [3623882752], SEEK_SET) = 0 write(4, "\2\0\0\0\3\0\0\0\4\0\0\0\0\0\365?\2\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4 096 _llseek(4, 18446744071696285696, [6576668672], SEEK_SET) = 0 write(4, "\0\200\22\0b\357$\0\304\330\1\0\230\211\36\0\35\322\21"..., 1024) = -1 EFBIG (File too large) --- SIGXFSZ (File size limit exceeded) --- +++ killed by SIGXFSZ +++ Any ideas? H.J. From owner-linux-mips@oss.sgi.com Sat Mar 23 16:22:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2O0MsJ21783 for linux-mips-outgoing; Sat, 23 Mar 2002 16:22:54 -0800 Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2O0Mnq21779 for ; Sat, 23 Mar 2002 16:22:49 -0800 Received: from zip.com.au (root@zipperii.zip.com.au [61.8.0.87]) by vasquez.zip.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA16327; Sun, 24 Mar 2002 11:23:17 +1100 X-Authentication-Warning: vasquez.zip.com.au: Host root@zipperii.zip.com.au [61.8.0.87] claimed to be zip.com.au Message-ID: <3C9D1C1D.E30B9B4B@zip.com.au> Date: Sat, 23 Mar 2002 16:21:50 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: tytso@thunk.org, linux-mips@oss.sgi.com Subject: Re: Does e2fsprogs-1.26 work on mips? References: <20020323140728.A4306@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" wrote: > > I got > > [root@localhost e2fsprogs-1.26]# ./e2fsck/e2fsck -f /dev/hda1 > e2fsck 1.26 (3-Feb-2002) > Pass 1: Checking inodes, blocks, and sizes > File size limit exceeded > > on Linux/mipsel. /dev/hda1 is a 7GB ext3 partition. e2fsprogs-1.23 > works fine. Strace > > Common problem - it's due to internal API changes in resource limits. You need to ensure that your maximum file size is set to `unlimited'. Kernel is currently applying file size limits to block devices (which is broken) and I think e2fsprogs' attempt to set sile size limits to RLIM_INFINITY gets broken by a consipiracy between the kernel change and glibc headers. From owner-linux-mips@oss.sgi.com Sun Mar 24 01:26:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2O9QEf29490 for linux-mips-outgoing; Sun, 24 Mar 2002 01:26:14 -0800 Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2O9Q5q29486 for ; Sun, 24 Mar 2002 01:26:05 -0800 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020324092824.YWIZ1214.rwcrmhc54.attbi.com@ocean.lucon.org>; Sun, 24 Mar 2002 09:28:24 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id B5721125C7; Sun, 24 Mar 2002 01:28:19 -0800 (PST) Date: Sun, 24 Mar 2002 01:28:19 -0800 From: "H . J . Lu" To: Andrew Morton Cc: tytso@thunk.org, linux-mips@oss.sgi.com, linux kernel , GNU C Library Subject: Re: Does e2fsprogs-1.26 work on mips? Message-ID: <20020324012819.A13155@lucon.org> References: <20020323140728.A4306@lucon.org> <3C9D1C1D.E30B9B4B@zip.com.au> <20020323221627.A10953@lucon.org> <3C9D7A42.B106C62D@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C9D7A42.B106C62D@zip.com.au>; from akpm@zip.com.au on Sat, Mar 23, 2002 at 11:03:30PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Mar 23, 2002 at 11:03:30PM -0800, Andrew Morton wrote: > "H . J . Lu" wrote: > > > > ... > > RLIM_INFINITY is not ((unsigned long)(~0UL)). Also you can't assume > > the type of rlim.rlim_cur. > > > > Here is a patch. > > > > I suspect it's not right. > > I don't pretend to understand the details, but they're > messy. See Ted's recent words at > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.2/0846.html > I look at the glibc code. It uses a constant RLIM_INFINITY for a given arch. The user always passes (~0UL) to glibc on x86. glibc will check if the kernel supports the new getrlimit at the run time. If it doesn't, glibc will adjust the RLIM_INFINITY for setrlimit. I don't see how glibc 2.2.5 compiled under kernel 2.2 will fail under 2.4 due to this unless glibc is misconfigureed or miscompiled. > (Sorry - I should have dug that message out earlier). The problem is not all arches use (~0UL) for RLIM_INFINITY. # cd linux/include # grep RLIM_INFINITY asm-*/resource.h | grep define asm-alpha/resource.h:#define RLIM_INFINITY 0x7ffffffffffffffful asm-arm/resource.h:#define RLIM_INFINITY (~0UL) asm-cris/resource.h:#define RLIM_INFINITY (~0UL) asm-i386/resource.h:#define RLIM_INFINITY (~0UL) asm-ia64/resource.h:#define RLIM_INFINITY (~0UL) asm-m68k/resource.h:#define RLIM_INFINITY (~0UL) asm-mips64/resource.h:#define RLIM_INFINITY (~0UL) asm-mips/resource.h:#define RLIM_INFINITY 0x7fffffffUL asm-parisc/resource.h:#define RLIM_INFINITY (~0UL) asm-ppc/resource.h:#define RLIM_INFINITY (~0UL) asm-s390/resource.h:#define RLIM_INFINITY (~0UL) asm-s390x/resource.h:#define RLIM_INFINITY (~0UL) asm-sh/resource.h:#define RLIM_INFINITY (~0UL) asm-sparc64/resource.h:#define RLIM_INFINITY (~0UL) asm-sparc/resource.h:#define RLIM_INFINITY 0x7fffffff What should we do about it? I know e2fsprogs-1.26 doesn't work on mips nor alpha because of this. I don't think it works on sparc. BTW, mips has /* * SuS says limits have to be unsigned. * Which makes a ton more sense anyway. */ #define RLIM_INFINITY 0x7fffffffUL It doesn't make any senes. H.J. From owner-linux-mips@oss.sgi.com Sun Mar 24 05:49:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ODnIi06702 for linux-mips-outgoing; Sun, 24 Mar 2002 05:49:18 -0800 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ODnBq06699 for ; Sun, 24 Mar 2002 05:49:11 -0800 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 08AC82B6B5; Sun, 24 Mar 2002 13:51:28 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 9550AE960; Sun, 24 Mar 2002 13:51:22 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 5CFB87243; Sun, 24 Mar 2002 13:51:22 +0000 (GMT) Date: Sun, 24 Mar 2002 13:51:22 +0000 (GMT) From: Dave Airlie X-X-Sender: To: "Maciej W. Rozycki" Cc: Ralf Baechle , , Subject: Re: [patch] linux: declance multicast filter fixes 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 > > I've created declance_2_4.c on http://www.csn.ul.ie/~airlied/mips > > > > for the DS5000/200 series of DecStations.. > > Thanks for the reference -- I definitely want to look how to merge the > drivers one day (well, actually the LANCE core should be common to all > drivers eventually). There is certainly no point in keeping your code > separately. I suppose your driver should work for the PMAD card as well. > well it should work for the PMAD and I've got a version for the VAX that splits off from my one, the VAX uses a similiar wiring as the DS5000/200, I've been waiting for the LANCE core to be separated out a lot of people have talked about it and I hear for 2.5 maybe someone is actually going to do it ... Dave -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Sun Mar 24 20:13:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P4Dfl17418 for linux-mips-outgoing; Sun, 24 Mar 2002 20:13:41 -0800 Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2P4Atq17400 for ; Sun, 24 Mar 2002 20:10:55 -0800 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020325041311.YDJE2626.rwcrmhc51.attbi.com@ocean.lucon.org>; Mon, 25 Mar 2002 04:13:11 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4129C125C1; Sun, 24 Mar 2002 20:12:21 -0800 (PST) Date: Sun, 24 Mar 2002 20:12:20 -0800 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , gcc@gcc.gnu.org, GNU C Library Subject: The Linux binutils 2.12.90.0.3 is released Message-ID: <20020324201220.A2696@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is the beta release of binutils 2.12.90.0.3 for Linux, which is based on binutils 2002 0323 in CVS on sourecs.redhat.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.12.90.0.3 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.12.90.0.1: 1. Update from binutils 2002 0323. 2. Fix linking a.out relocatable files with ELF. 3. Fix a PPC altivec assembler bug. Changes from binutils 2.11.93.0.2: 1. Update from binutils 2002 0307. 2. Add the .preinit_array/.init_array/.fini_array support. 3. Fix eh_frame. 4. Turn on combreloc by default. 5. Enable gprof for Linux/mips. Changes from binutils 2.11.92.0.12.3: 1. Update from binutils 2002 0207. 2. Fix a weak symbol alpha linker bug for glibc. 3. More support for gcc 3.1. Changes from binutils 2.11.92.0.12: 1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object files. Changes from binutils 2.11.92.0.10: 1. Update from binutils 2001 1121. 2. Fix a linker symbol version bug for common symbols. 3. Update handling relocations against the discarded sections. You may need to apply the kernel patch enclosed here to your kernel source. If you still see things like drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit' in the final kernel link, that means you have compiled a driver into the kernel which has a reference to the symbol in a discarded section. Kernel 2.4.17 or above should work fine. 4. Support "-march=xxx -mipsN" for mips gas if they are compatible. Changes from binutils 2.11.92.0.7: 1. Update from binutils 2001 1021. 2. Fix the ELF/PPC linker. 3. Fix the ELF/cris linker. 4. Fix ELF strip. Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.12. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.12.90.0.3.tar.gz. Source code. 2. binutils-2.12.90.0.1-2.12.90.0.3.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.3-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.12.90.0.3.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 03/24/2002 From owner-linux-mips@oss.sgi.com Sun Mar 24 21:29:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P5Tvq18356 for linux-mips-outgoing; Sun, 24 Mar 2002 21:29:57 -0800 Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2P5Toq18353 for ; Sun, 24 Mar 2002 21:29:50 -0800 Received: from tytso by thunk.org with local (Exim 3.34 #1 (Debian)) id 16pN5L-0000hR-00; Mon, 25 Mar 2002 00:31:59 -0500 Date: Mon, 25 Mar 2002 00:31:59 -0500 From: Theodore Tso To: "H . J . Lu" Cc: Andrew Morton , linux-mips@oss.sgi.com, linux kernel , GNU C Library Subject: Re: Does e2fsprogs-1.26 work on mips? Message-ID: <20020325003159.A2340@thunk.org> Mail-Followup-To: Theodore Tso , "H . J . Lu" , Andrew Morton , linux-mips@oss.sgi.com, linux kernel , GNU C Library References: <20020323140728.A4306@lucon.org> <3C9D1C1D.E30B9B4B@zip.com.au> <20020323221627.A10953@lucon.org> <3C9D7A42.B106C62D@zip.com.au> <20020324012819.A13155@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20020324012819.A13155@lucon.org>; from hjl@lucon.org on Sun, Mar 24, 2002 at 01:28:19AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 24, 2002 at 01:28:19AM -0800, H . J . Lu wrote: > > The problem is not all arches use (~0UL) for RLIM_INFINITY. > > What should we do about it? I know e2fsprogs-1.26 doesn't work on mips > nor alpha because of this. I don't think it works on sparc. Yeah, I forced the release of e2fsprogs 1.27 because of this, back on March 8th. That was my fault, and I fixed it as soon as I discovered it. (1.26 was released on Feb 3, and I released 1.27 on March 8th). In e2fsprogs 1.27, I do the following: #ifdef __linux__ #undef RLIM_INFINITY #if (defined(__alpha__) || ((defined(__sparc__) || defined(__mips__)) && (SIZEOF_LONG == 4))) #define RLIM_INFINITY ((unsigned long)(~0UL>>1)) #else #define RLIM_INFINITY (~0UL) #endif Basically because I can't depend on the RLIM_INFINITY being "right". (Remember, I'm trying to make sure that e2fsprogs can compile on any arbitrary glibc, and then run on any other-not-necessarily-the-same glibc, which gets "challenging".) The problem now is that some older glibcs are capping RLIM_INFINITY with the older value, and so a combination of a new kernel, new e2fsprogs, and old glibc results in problems. My current feeling about how to fix this is to bypass glibc altogether, and simply call the setrlimit system call directly. This is ugly-ugly-ugly, but I can't see another way around this. And just to be clear ---- although in the past I've been really annoyed when glibc has made what I've considered to be arbitrary changes which have screwed ABI, compile-time, or link-time compatibility, and have spoken out against it --- in this particular case, I consider the fault to be purely the fault of the kernel developers, so there's no need having the glibc folks get all defensive.... - Ted From owner-linux-mips@oss.sgi.com Sun Mar 24 21:42:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P5gVK18486 for linux-mips-outgoing; Sun, 24 Mar 2002 21:42:31 -0800 Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2P5gSq18483 for ; Sun, 24 Mar 2002 21:42:28 -0800 Received: from zip.com.au (root@zipperii.zip.com.au [61.8.0.87]) by vasquez.zip.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA30542; Mon, 25 Mar 2002 16:44:42 +1100 X-Authentication-Warning: vasquez.zip.com.au: Host root@zipperii.zip.com.au [61.8.0.87] claimed to be zip.com.au Message-ID: <3C9EB8F6.247C7C3B@zip.com.au> Date: Sun, 24 Mar 2002 21:43:18 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Theodore Tso CC: "H . J . Lu" , linux-mips@oss.sgi.com, linux kernel , GNU C Library Subject: Re: Does e2fsprogs-1.26 work on mips? References: <20020323140728.A4306@lucon.org> <3C9D1C1D.E30B9B4B@zip.com.au> <20020323221627.A10953@lucon.org> <3C9D7A42.B106C62D@zip.com.au> <20020324012819.A13155@lucon.org> <20020325003159.A2340@thunk.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Theodore Tso wrote: > > And just to be clear ---- although in the past I've been really > annoyed when glibc has made what I've considered to be arbitrary > changes which have screwed ABI, compile-time, or link-time > compatibility, and have spoken out against it --- in this particular > case, I consider the fault to be purely the fault of the kernel > developers, so there's no need having the glibc folks get all > defensive.... So... Does the kernel need fixing? If so, what would you recommend? - From owner-linux-mips@oss.sgi.com Mon Mar 25 02:48:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PAmDe10731 for linux-mips-outgoing; Mon, 25 Mar 2002 02:48:13 -0800 Received: from mail-gw.sonicblue.com (mail-gw.sonicblue.com [209.10.223.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PAm7q10728 for ; Mon, 25 Mar 2002 02:48:07 -0800 Received: from relay.sonicblue.com (timbale [10.6.1.10]) by mail-gw.sonicblue.com (8.11.6/8.11.6) with ESMTP id g2PAoP908502 for ; Mon, 25 Mar 2002 03:50:25 -0700 (MST) Received: from corpvirus1.sc.sonicblue.com (corpvirus1.sonicblue.com [10.6.2.49]) by relay.sonicblue.com (8.11.5/8.11.5) with SMTP id g2PAoP603072 for ; Mon, 25 Mar 2002 02:50:25 -0800 (PST) Received: FROM corpmailmx.sonicblue.com BY corpvirus1.sc.sonicblue.com ; Mon Mar 25 02:57:40 2002 -0800 Received: by CORPMAILMX with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 02:51:06 -0800 Message-ID: <37D1208A1C9BD511855B00D0B772242C011C7F13@corpmail1.sc.sonicblue.com> From: Peter Hartley To: "'H . J . Lu'" , Andrew Morton Cc: tytso@thunk.org, linux-mips@oss.sgi.com, linux kernel , GNU C Library Subject: RE: Does e2fsprogs-1.26 work on mips? Date: Mon, 25 Mar 2002 02:52:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk H J Lu wrote: > I look at the glibc code. It uses a constant RLIM_INFINITY for a given > arch. The user always passes (~0UL) to glibc on x86. glibc will check > if the kernel supports the new getrlimit at the run time. If it > doesn't, glibc will adjust the RLIM_INFINITY for setrlimit. I > don't see > how glibc 2.2.5 compiled under kernel 2.2 will fail under 2.4 due to > this unless glibc is misconfigureed or miscompiled. It's not a question of which kernel glibc is compiled under, it's a question of which version of the kernel headers (/usr/include/{linux,asm}) glibc is compiled against. A glibc, even the newest glibc, *compiled against 2.2 headers* cannot know about the new getrlimit, so the run-time test cannot be compiled and is not used. Such a glibc subsequently breaks fsck if run under a 2.4 kernel. Recompile your glibc against 2.4 headers and you should get a glibc and fsck that work if run under either a 2.2 or 2.4 kernel. The necessary kernel patch to fix this mess is in the latest -pre-ac (thanks Alan). Peter From owner-linux-mips@oss.sgi.com Mon Mar 25 03:38:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PBchx11417 for linux-mips-outgoing; Mon, 25 Mar 2002 03:38:43 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PBcdq11414 for ; Mon, 25 Mar 2002 03:38:39 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA05215; Mon, 25 Mar 2002 12:40:09 +0100 (MET) Date: Mon, 25 Mar 2002 12:40:09 +0100 (MET) From: "Maciej W. Rozycki" To: Dave Airlie cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: declance multicast filter fixes In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, 24 Mar 2002, Dave Airlie wrote: > well it should work for the PMAD and I've got a version for the VAX that > splits off from my one, the VAX uses a similiar wiring as the DS5000/200, > I've been waiting for the LANCE core to be separated out a lot of people > have talked about it and I hear for 2.5 maybe someone is actually going to > do it ... Well, the core seems to be already separated -- see drivers/net/7990.c. I haven't yet checked how suitable it is and many front-end drivers use it already. For the I/O ASIC front-end I'm going to check if the ASIC is capable of mapping the LANCE more sensibly before starting any further work. The current configuration is a major loss, doubling the CPU's work and I can't see any reasonable explanation for such a setup. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Mar 25 05:17:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PDHLk13595 for linux-mips-outgoing; Mon, 25 Mar 2002 05:17:21 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PDGHq13580 for ; Mon, 25 Mar 2002 05:16:17 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA07290; Mon, 25 Mar 2002 14:05:47 +0100 (MET) Date: Mon, 25 Mar 2002 14:05:46 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: LK201 hot-plug updates and associated zs.c fixes 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 Hello, Here is the long-promised LK201 update. It allows booting without a keyboard attached and plugging it and unplugging at any time. Additional status is provided upon a keyboard initialization -- a self-test result is printed as well as the model name. Since the new code requires serial interrupts to be already initialized and enabled at the time the zs.c hook is executed, a few minor changes were made to the zs.c driver. There are also a few obvious bug fixes. A few receive errors may happen and be reported upon a keyboard being plugged in during system's operation. The reason is probably bouncing of contacts and it appears harmless -- I plugged and unplugged my keyboards many times and there was never a character loss in the initial transmission from a keyboard to the host, thus the driver didn't get out of sync. I'm told both the LK201 keyboard and the VSXXX mouse are designed for hot-plugging (the host side being as well, due to EIA-232 requirements), so there should be no electrical problems. The code was tested with an LK201-AA and an LK401-AG successfully. The remaining to-do list: 1. Pass raw scancodes up, only doing a remap for the medium-raw mode (requires changes to the generic code). 2. Use handshaking for mode commands. 3. Add typematic rate and LED state restoration after a replug. I'm going to address these issues gradually, probably in the order listed. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.18-20020323-lk201-23 diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/tc/lk201.c linux-mips-2.4.18-20020323/drivers/tc/lk201.c --- linux-mips-2.4.18-20020323.macro/drivers/tc/lk201.c Sat Mar 23 04:58:18 2002 +++ linux-mips-2.4.18-20020323/drivers/tc/lk201.c Sun Mar 24 21:12:46 2002 @@ -5,7 +5,7 @@ * for more details. * * Copyright (C) 1999-2002 Harald Koerfgen - * Copyright (C) 2001 Maciej W. Rozycki + * Copyright (C) 2001, 2002 Maciej W. Rozycki */ #include @@ -21,7 +21,6 @@ #include #include -#include #include #include @@ -48,19 +47,18 @@ static void __init lk201_info(struct dec static void lk201_kbd_rx_char(unsigned char, unsigned char); struct zs_hook lk201_kbdhook = { - init_channel: lk201_init, - init_info: lk201_info, - rx_char: NULL, - poll_rx_char: NULL, - poll_tx_char: NULL, - cflags: B4800 | CS8 | CSTOPB | CLOCAL + init_channel: lk201_init, + init_info: lk201_info, + rx_char: NULL, + poll_rx_char: NULL, + poll_tx_char: NULL, + cflags: B4800 | CS8 | CSTOPB | CLOCAL }; /* * This is used during keyboard initialisation */ static unsigned char lk201_reset_string[] = { - LK_CMD_LEDS_ON, LK_PARAM_LED_MASK(0xf), /* show we are resetting */ LK_CMD_SET_DEFAULTS, LK_CMD_MODE(LK_MODE_RPT_DOWN, 1), LK_CMD_MODE(LK_MODE_RPT_DOWN, 2), @@ -76,28 +74,85 @@ static unsigned char lk201_reset_string[ LK_CMD_MODE(LK_MODE_RPT_DOWN, 12), LK_CMD_MODE(LK_MODE_DOWN, 13), LK_CMD_MODE(LK_MODE_RPT_DOWN, 14), - LK_CMD_ENB_RPT, LK_CMD_DIS_KEYCLK, - LK_CMD_RESUME, LK_CMD_ENB_BELL, LK_PARAM_VOLUME(4), - LK_CMD_LEDS_OFF, LK_PARAM_LED_MASK(0xf) }; static struct dec_serial* lk201kbd_info; -static int __init lk201_reset(struct dec_serial *info) +static int lk201_send(struct dec_serial *info, unsigned char ch) { - int i; + if (info->hook->poll_tx_char(info, ch)) { + printk(KERN_ERR "lk201: transmit timeout\n"); + return -EIO; + } + return 0; +} + +static inline int lk201_get_id(struct dec_serial *info) +{ + return lk201_send(info, LK_CMD_REQ_ID); +} + +static int lk201_reset(struct dec_serial *info) +{ + int i, r; for (i = 0; i < sizeof(lk201_reset_string); i++) { - if (info->hook->poll_tx_char(info, lk201_reset_string[i]) < 0) { - return -EIO; - } + r = lk201_send(info, lk201_reset_string[i]); + if (r < 0) + return r; } - return 0; } +static void lk201_report(unsigned char id[6]) +{ + char *report = "lk201: keyboard attached, "; + + switch (id[2]) { + case LK_STAT_PWRUP_OK: + printk(KERN_INFO "%sself-test OK\n", report); + break; + case LK_STAT_PWRUP_KDOWN: + /* The keyboard will resend the power-up ID + after all keys are released, so we don't + bother handling the error specially. Still + there may be a short-circuit inside. + */ + printk(KERN_ERR "%skey down (stuck?), code: 0x%02x\n", + report, id[3]); + break; + case LK_STAT_PWRUP_ERROR: + printk(KERN_ERR "%sself-test failure\n", report); + break; + default: + printk(KERN_ERR "%sunknown error: 0x%02x\n", + report, id[2]); + } +} + +static void lk201_id(unsigned char id[6]) +{ + /* + * Report whether there is an LK201 or an LK401 + * The LK401 has ALT keys... + */ + switch (id[4]) { + case 1: + printk(KERN_INFO "lk201: LK201 detected\n"); + break; + case 2: + printk(KERN_INFO "lk201: LK401 detected\n"); + break; + default: + printk(KERN_WARNING + "lk201: unknown keyboard detected, ID %d\n", id[4]); + printk(KERN_WARNING "lk201: ... please report to " + "\n"); + } +} + #define DEFAULT_KEYB_REP_DELAY (250/5) /* [5ms] */ #define DEFAULT_KEYB_REP_RATE 30 /* [cps] */ @@ -233,118 +288,111 @@ char kbd_unexpected_up(unsigned char key static void lk201_kbd_rx_char(unsigned char ch, unsigned char stat) { + static unsigned char id[6]; + static int id_i; + static int shift_state = 0; static int prev_scancode; unsigned char c = scancodeRemap[ch]; - if (!stat || stat == 4) { - switch (ch) { - case LK_STAT_RESUME_ERR: - case LK_STAT_ERROR: - case LK_STAT_INHIBIT_ACK: - case LK_STAT_TEST_ACK: - case LK_STAT_MODE_KEYDOWN: - case LK_STAT_MODE_ACK: - break; - case LK_KEY_LOCK: - shift_state ^= LK_LOCK; - handle_scancode(c, shift_state && LK_LOCK ? 1 : 0); - break; - case LK_KEY_SHIFT: - shift_state ^= LK_SHIFT; - handle_scancode(c, shift_state && LK_SHIFT ? 1 : 0); - break; - case LK_KEY_CTRL: - shift_state ^= LK_CTRL; - handle_scancode(c, shift_state && LK_CTRL ? 1 : 0); - break; - case LK_KEY_COMP: - shift_state ^= LK_COMP; - handle_scancode(c, shift_state && LK_COMP ? 1 : 0); - break; - case LK_KEY_RELEASE: - if (shift_state & LK_SHIFT) - handle_scancode(scancodeRemap[LK_KEY_SHIFT], 0); - if (shift_state & LK_CTRL) - handle_scancode(scancodeRemap[LK_KEY_CTRL], 0); - if (shift_state & LK_COMP) - handle_scancode(scancodeRemap[LK_KEY_COMP], 0); - if (shift_state & LK_LOCK) - handle_scancode(scancodeRemap[LK_KEY_LOCK], 0); - shift_state = 0; - break; - case LK_KEY_REPEAT: - handle_scancode(prev_scancode, 1); - break; - default: - prev_scancode = c; - handle_scancode(c, 1); - break; - } - } else - printk("Error reading LKx01 keyboard: 0x%02x\n", stat); - tasklet_schedule(&keyboard_tasklet); -} - -static void __init lk201_info(struct dec_serial *info) -{ -} - -static int __init lk201_init(struct dec_serial *info) -{ - int ch, id = 0; - - printk("DECstation LK keyboard driver v0.04... "); - - - if (lk201_reset(info) < 0) { - printk("reset failed!\n"); - return -ENODEV; + if (stat && stat != 4) { + printk(KERN_ERR "lk201: keyboard receive error: 0x%02x\n", + stat); + return; } - mdelay(10); - - /* - * Detect whether there is an LK201 or an LK401 - * The LK401 has ALT keys... - */ - if (info->hook->poll_tx_char(info, LK_CMD_REQ_ID) < 0) { - printk("tx request ID timeout!\n"); - return -ENODEV; + /* Assume this is a power-up ID. */ + if (ch == LK_STAT_PWRUP_ID && !id_i) { + id[id_i++] = ch; + return; } - mdelay(10); - - while ((ch = info->hook->poll_rx_char(info)) > 0) - id = ch; - - if (ch < 0) { - printk("rx request ID timeout!\n"); - return -ENODEV; + /* Handle the power-up sequence. */ + if (id_i) { + id[id_i++] = ch; + if (id_i == 4) { + /* OK, the power-up concluded. */ + lk201_report(id); + if (id[2] == LK_STAT_PWRUP_OK) + lk201_get_id(lk201kbd_info); + else { + id_i = 0; + printk(KERN_ERR "lk201: keyboard power-up " + "error, skipping initialization\n"); + } + } else if (id_i == 6) { + /* We got the ID; report it and start an operation. */ + id_i = 0; + lk201_id(id); + lk201_reset(lk201kbd_info); + } + return; } - switch (id) { - case 1: - printk("LK201 detected\n"); + /* Everything else is a scancode/status response. */ + id_i = 0; + switch (ch) { + case LK_STAT_RESUME_ERR: + case LK_STAT_ERROR: + case LK_STAT_INHIBIT_ACK: + case LK_STAT_TEST_ACK: + case LK_STAT_MODE_KEYDOWN: + case LK_STAT_MODE_ACK: break; - case 2: - printk("LK401 detected\n"); + case LK_KEY_LOCK: + shift_state ^= LK_LOCK; + handle_scancode(c, shift_state && LK_LOCK ? 1 : 0); + break; + case LK_KEY_SHIFT: + shift_state ^= LK_SHIFT; + handle_scancode(c, shift_state && LK_SHIFT ? 1 : 0); + break; + case LK_KEY_CTRL: + shift_state ^= LK_CTRL; + handle_scancode(c, shift_state && LK_CTRL ? 1 : 0); + break; + case LK_KEY_COMP: + shift_state ^= LK_COMP; + handle_scancode(c, shift_state && LK_COMP ? 1 : 0); + break; + case LK_KEY_RELEASE: + if (shift_state & LK_SHIFT) + handle_scancode(scancodeRemap[LK_KEY_SHIFT], 0); + if (shift_state & LK_CTRL) + handle_scancode(scancodeRemap[LK_KEY_CTRL], 0); + if (shift_state & LK_COMP) + handle_scancode(scancodeRemap[LK_KEY_COMP], 0); + if (shift_state & LK_LOCK) + handle_scancode(scancodeRemap[LK_KEY_LOCK], 0); + shift_state = 0; + break; + case LK_KEY_REPEAT: + handle_scancode(prev_scancode, 1); break; default: - printk("unknown keyboard, ID %d,\n", id); - printk("... please report to \n"); + prev_scancode = c; + handle_scancode(c, 1); break; } + tasklet_schedule(&keyboard_tasklet); +} - /* - * now we're ready - */ - info->hook->rx_char = lk201_kbd_rx_char; +static void __init lk201_info(struct dec_serial *info) +{ +} +static int __init lk201_init(struct dec_serial *info) +{ + /* First install handlers. */ lk201kbd_info = info; kbd_rate = lk201kbd_rate; kd_mksound = lk201kd_mksound; + info->hook->rx_char = lk201_kbd_rx_char; + + /* Then just issue a reset -- the handlers will do the rest. */ + lk201_send(info, LK_CMD_POWER_UP); + return 0; } @@ -353,26 +401,29 @@ void __init kbd_init_hw(void) extern int register_zs_hook(unsigned int, struct zs_hook *); extern int unregister_zs_hook(unsigned int); + /* Maxine uses LK501 at the Access.Bus. */ + if (mips_machtype == MACH_DS5000_XX) + return; + + printk(KERN_INFO "lk201: DECstation LK keyboard driver v0.05.\n"); + if (TURBOCHANNEL) { - if (mips_machtype != MACH_DS5000_XX) { - /* - * This is not a MAXINE, so: - * - * kbd_init_hw() is being called before - * rs_init() so just register the kbd hook - * and let zs_init do the rest :-) - */ - if (mips_machtype == MACH_DS5000_200) - printk("LK201 Support for DS5000/200 not yet ready ...\n"); - else - if(!register_zs_hook(KEYB_LINE, &lk201_kbdhook)) - unregister_zs_hook(KEYB_LINE); - } + /* + * kbd_init_hw() is being called before + * rs_init() so just register the kbd hook + * and let zs_init do the rest :-) + */ + if (mips_machtype == MACH_DS5000_200) + printk(KERN_ERR "lk201: support for DS5000/200 " + "not yet ready.\n"); + else + if(!register_zs_hook(KEYB_LINE, &lk201_kbdhook)) + unregister_zs_hook(KEYB_LINE); } else { /* * TODO: modify dz.c to allow similar hooks * for LK201 handling on DS2100, DS3100, and DS5000/200 */ - printk("LK201 Support for DS3100 not yet ready ...\n"); + printk(KERN_ERR "lk201: support for DS3100 not yet ready.\n"); } } diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/tc/lk201.h linux-mips-2.4.18-20020323/drivers/tc/lk201.h --- linux-mips-2.4.18-20020323.macro/drivers/tc/lk201.h Wed Oct 31 05:26:17 2001 +++ linux-mips-2.4.18-20020323/drivers/tc/lk201.h Sun Mar 24 14:31:12 2002 @@ -115,6 +115,7 @@ /* the keycode follows */ #define LK_STAT_MODE_ACK 0xba /* the mode command succeeded */ +#define LK_STAT_PWRUP_ID 0x01 /* the power-up response start mark */ #define LK_STAT_PWRUP_OK 0x00 /* the power-up self test OK */ #define LK_STAT_PWRUP_KDOWN 0x3d /* a key was down during the test */ #define LK_STAT_PWRUP_ERROR 0x3e /* keyboard self test failure */ diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/tc/zs.c linux-mips-2.4.18-20020323/drivers/tc/zs.c --- linux-mips-2.4.18-20020323.macro/drivers/tc/zs.c Sat Mar 23 04:58:18 2002 +++ linux-mips-2.4.18-20020323/drivers/tc/zs.c Sun Mar 24 20:51:10 2002 @@ -5,8 +5,8 @@ * Derived from drivers/macintosh/macserial.c by Harald Koerfgen. * * DECstation changes - * Copyright (C) 1998-2002 Harald Koerfgen - * Copyright (C) 2000,2001 Maciej W. Rozycki + * Copyright (C) 1998-2000 Harald Koerfgen + * Copyright (C) 2000, 2001, 2002 Maciej W. Rozycki * * For the rest of the code the original Copyright applies: * Copyright (C) 1996 Paul Mackerras (Paul.Mackerras@cs.anu.edu.au) @@ -409,7 +409,7 @@ static _INLINE_ void receive_chars(struc stat = read_zsreg(info->zs_channel, R1); ch = read_zsdata(info->zs_channel); - if (!tty && !info->hook && !info->hook->rx_char) + if (!tty && (!info->hook || !info->hook->rx_char)) continue; if (tty_break) { @@ -524,9 +524,9 @@ static _INLINE_ void status_handle(struc if (info->zs_channel != info->zs_chan_a) { - /* FIXEM: Check for DCD transitions */ - if (((stat ^ info->read_reg_zero) & DCD) != 0 - && info->tty && !C_CLOCAL(info->tty)) { + /* Check for DCD transitions */ + if (info->tty && !C_CLOCAL(info->tty) && + ((stat ^ info->read_reg_zero) & DCD) != 0 ) { if (stat & DCD) { wake_up_interruptible(&info->open_wait); } else if (!(info->flags & ZILOG_CALLOUT_ACTIVE)) { @@ -1721,7 +1721,7 @@ int rs_open(struct tty_struct *tty, stru static void __init show_serial_version(void) { - printk("DECstation Z8530 serial driver version 0.06\n"); + printk("DECstation Z8530 serial driver version 0.07\n"); } /* Initialize Z8530s zs_channels @@ -1934,34 +1934,30 @@ int __init zs_init(void) save_flags(flags); cli(); for (channel = 0; channel < zs_channels_found; ++channel) { - if (zs_soft[channel].hook && - zs_soft[channel].hook->init_channel) - (*zs_soft[channel].hook->init_channel) - (&zs_soft[channel]); - - zs_soft[channel].clk_divisor = 16; - zs_soft[channel].zs_baud = get_zsbaud(&zs_soft[channel]); - if (request_irq(zs_parms->irq, rs_interrupt, SA_SHIRQ, "SCC", &zs_soft[channel])) printk(KERN_ERR "decserial: can't get irq %d\n", zs_parms->irq); + + zs_soft[channel].clk_divisor = 16; + zs_soft[channel].zs_baud = get_zsbaud(&zs_soft[channel]); } - for (info = zs_chain, i = 0; info; info = info->zs_next, i++) - { - if (info->hook && info->hook->init_info) { - (*info->hook->init_info)(info); + for (info = zs_chain, i = 0; info; info = info->zs_next, i++) { + + /* Needed before interrupts are enabled. */ + info->tty = 0; + info->x_char = 0; + + if (info->hook && info->hook->init_info) continue; - } + info->magic = SERIAL_MAGIC; info->port = (int) info->zs_channel->control; info->line = i; - info->tty = 0; info->custom_divisor = 16; info->close_delay = 50; info->closing_wait = 3000; - info->x_char = 0; info->event = 0; info->count = 0; info->blocked_open = 0; @@ -1983,6 +1979,18 @@ int __init zs_init(void) restore_flags(flags); + for (channel = 0; channel < zs_channels_found; ++channel) { + if (zs_soft[channel].hook && + zs_soft[channel].hook->init_channel) + (*zs_soft[channel].hook->init_channel) + (&zs_soft[channel]); + } + + for (info = zs_chain, i = 0; info; info = info->zs_next, i++) { + if (info->hook && info->hook->init_info) + (*info->hook->init_info)(info); + } + return 0; } @@ -2013,21 +2021,13 @@ zs_poll_tx_char(struct dec_serial *info, if(chan) { int loops = 10000; - RECOVERY_DELAY; - wbflush(); - RECOVERY_DELAY; - - while (loops && !(*(chan->control) & Tx_BUF_EMP)) { + while (loops && !(read_zsreg(chan, 0) & Tx_BUF_EMP)) loops--; - RECOVERY_DELAY; - } if (loops) { - *(chan->data) = ch; - wbflush(); - RECOVERY_DELAY; + write_zsdata(chan, ch); ret = 0; - } else + } else ret = -EAGAIN; return ret; @@ -2044,9 +2044,8 @@ zs_poll_rx_char(struct dec_serial *info) if(chan) { int loops = 10000; - while(loops && ((read_zsreg(chan, 0) & Rx_CH_AV) == 0)) { + while (loops && !(read_zsreg(chan, 0) & Rx_CH_AV)) loops--; - } if (loops) ret = read_zsdata(chan); @@ -2054,8 +2053,8 @@ zs_poll_rx_char(struct dec_serial *info) ret = -EAGAIN; return ret; - } else - return -ENODEV; + } else + return -ENODEV; } unsigned int register_zs_hook(unsigned int channel, struct zs_hook *hook) From owner-linux-mips@oss.sgi.com Mon Mar 25 05:56:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PDuO014314 for linux-mips-outgoing; Mon, 25 Mar 2002 05:56:24 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PDuHq14311 for ; Mon, 25 Mar 2002 05:56:17 -0800 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16pUza-0000Sm-00 for ; Mon, 25 Mar 2002 14:58:34 +0100 Date: Mon, 25 Mar 2002 14:58:34 +0100 From: Johannes Stezenbach To: linux-mips@oss.sgi.com Subject: Mips16 toolchain? Message-ID: <20020325135834.GA1736@convergence.de> Mail-Followup-To: Johannes Stezenbach , linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all, I'm currently using a toolchain based on binutils 2.12.90.0.1 and gcc-2.95.4-debian for my Linux kernel work. Since I'm developing for an embedded target, I wanted to check out mips16 code generation for the userspace apps. Unfortunately my gcc aborts with an internal error on even the simplest test program: $ cat t16.c extern int write(int fd, const char *buf, unsigned int size); int main(int argc, char *argv[]) { write(0, "xy", 2); return 0; } $ mips-linux-gcc -mips16 -Wall -S t16.c t16.c: In function `main': t16.c:8: Internal compiler error: t16.c:8: Unable to generate reloads for: (call_insn 18 16 21 (parallel[ (set (reg:SI 2 v0) (call (mem:SI (symbol_ref:SI ("write")) 0) (const_int 16 [0x10]))) (clobber (reg:SI 31 ra)) ] ) 469 {call_value_internal2} (nil) (nil) (expr_list (use (reg:SI 6 a2)) (expr_list (use (reg:SI 5 a1)) (expr_list (use (reg:SI 4 a0)) (nil))))) I saw that the algorithmics toolchain (which Dominic Sweetman offered to the Linux/MIPS community here a month ago) claims to have full support for the mips16 instruction set. My questions: Does anyone here have experiences with mips16 and/or with the algorithmics toolchain? Is there working support for mips16 in any other gcc-version? How about gcc-3.x from CVS? Any other comments or recommendations regarding mips16? glibc support wrt mips16 is not an issue for us, since we plan to use the dietlibc (http://www.fefe.de/dietlibc/). MIPS support for the dietlibc is still bit rough, though. Regards, Johannes From owner-linux-mips@oss.sgi.com Mon Mar 25 06:55:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PEtiE16690 for linux-mips-outgoing; Mon, 25 Mar 2002 06:55:44 -0800 Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PEtcq16669 for ; Mon, 25 Mar 2002 06:55:38 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id GAA18384; Mon, 25 Mar 2002 06:57:54 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA00048; Mon, 25 Mar 2002 06:57:51 -0800 (PST) Message-ID: <00e901c1d40d$a257a200$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Johannes Stezenbach" , References: <20020325135834.GA1736@convergence.de> Subject: Re: Mips16 toolchain? Date: Mon, 25 Mar 2002 15:59:13 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I saw that the algorithmics toolchain (which Dominic Sweetman > offered to the Linux/MIPS community here a month ago) claims > to have full support for the mips16 instruction set. > > My questions: > Does anyone here have experiences with mips16 and/or with the > algorithmics toolchain? Yes. Both Algorithmics and Green Hills embedded tool chains support it reasonably well. GHS has no Linux target, though. Algorithmics has been working on one, but I'm not sure what it's current status is. > Is there working support for mips16 in any other gcc-version? Cygnus (now part of Red Hat) did the very first MIPS16 support for gcc, most of which found its way into the main development/maintence stream. But apparently not enough of it, based on your experience. > How about gcc-3.x from CVS? No data there. > Any other comments or recommendations regarding mips16? MIPS16 requires more than just gcc support. One needs a binutils that can distinguish a MIPS16 binary module (or function if you want to be fancy and mix/match within modules) from a MIPS32/64 module and perform fixups so that the right selections are made between JAL and JALX on function invocations. If you've got that, you should not need a seperate MIPS16 libc. To correctly support MIPS16, the Linux kernel does need to be tweaked in those cases where user-mode instructions are decoded and interpreted, as in arch/mips/kernel/branch.c and unaligned.c. I believe that code has been prototyped somewhere, but it's not yet in any commonly used repository to the best of my knowledge. If you avoid throwing executing non-instructions, performing unaligned accesses, etc, you should be able to tiptoe around that deficiency. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Mar 25 07:19:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PFJL417232 for linux-mips-outgoing; Mon, 25 Mar 2002 07:19:21 -0800 Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PFJGq17229 for ; Mon, 25 Mar 2002 07:19:16 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id HAA18439 for ; Mon, 25 Mar 2002 07:21:33 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA01275 for ; Mon, 25 Mar 2002 07:21:31 -0800 (PST) Message-ID: <00f201c1d410$f05bd540$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "MIPS/Linux List \(SGI\)" Subject: EJTAG Debug Exceptions and LL/SC Date: Mon, 25 Mar 2002 16:19:44 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk In the course of hacking around in the 2.4.18 kernel on a new MIPS CPU, I came across something that urgently needs to be fixed in any repositories that propose MIPS EJTAG support. EJTAG exceptions do *not* affect the LL/SC flipflop. That means that they are non-invasive if injected into a LL/SC sequence. It also means that one cannot use LL/SC within a Debug exception handler. The Linux mini Debug exception handler has for some time performed printk()'s to let the world know that something "unusual" has happened. Somewhere between 2.4.3 and 2.4.18, someone cleverly fixed printk() to not munge simultaneous output lines on SMP systems, which on MIPS means using LL/SC. Result: the kernel will go into an infinite loop in Debug mode (no further interrupts taken, etc.) if ever an Debug exception is taken after an LL sets the flop. So those calls to printk() need to go away, and a big narly comment needs to go at the top of ejtag_exception_handler() warning people not to call any function that might involve a kernel semaphore, cause a TLB fault, or depend on an interrupt beind delivered. In general, code executed in the kernel in Debug mode needs to be carefully quarantined. Any invocation of kernel services needs to be done either by passing a message to be sampled at some later point by the kernel, or by setting up a software interrupt to be taken after the DERET from the Debug exception. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Mar 25 09:05:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PH57L21462 for linux-mips-outgoing; Mon, 25 Mar 2002 09:05:07 -0800 Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PH54q21456 for ; Mon, 25 Mar 2002 09:05:04 -0800 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020325170719.JYKU1214.rwcrmhc54.attbi.com@ocean.lucon.org>; Mon, 25 Mar 2002 17:07:19 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id D1778125C1; Mon, 25 Mar 2002 09:07:17 -0800 (PST) Date: Mon, 25 Mar 2002 09:07:17 -0800 From: "H . J . Lu" To: Peter Hartley Cc: Andrew Morton , tytso@thunk.org, linux-mips@oss.sgi.com, linux kernel , GNU C Library Subject: Re: Does e2fsprogs-1.26 work on mips? Message-ID: <20020325090717.A13707@lucon.org> References: <37D1208A1C9BD511855B00D0B772242C011C7F13@corpmail1.sc.sonicblue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <37D1208A1C9BD511855B00D0B772242C011C7F13@corpmail1.sc.sonicblue.com>; from PDHartley@sonicblue.com on Mon, Mar 25, 2002 at 02:52:24AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Mar 25, 2002 at 02:52:24AM -0800, Peter Hartley wrote: > H J Lu wrote: > > I look at the glibc code. It uses a constant RLIM_INFINITY for a given > > arch. The user always passes (~0UL) to glibc on x86. glibc will check > > if the kernel supports the new getrlimit at the run time. If it > > doesn't, glibc will adjust the RLIM_INFINITY for setrlimit. I > > don't see > > how glibc 2.2.5 compiled under kernel 2.2 will fail under 2.4 due to > > this unless glibc is misconfigureed or miscompiled. > > It's not a question of which kernel glibc is compiled under, it's a question > of which version of the kernel headers (/usr/include/{linux,asm}) glibc is > compiled against. > What are you talking about? It doesn't matter which kernel header is used. glibc doesn't even use /usr/include/asm/resource.h nor should any user space applications. H.J. From owner-linux-mips@oss.sgi.com Mon Mar 25 09:49:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PHnBV23210 for linux-mips-outgoing; Mon, 25 Mar 2002 09:49:11 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2PHnAq23207 for ; Mon, 25 Mar 2002 09:49:10 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2PHpS901979 for linux-mips@oss.sgi.com; Mon, 25 Mar 2002 09:51:28 -0800 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MFZRq23957 for ; Fri, 22 Mar 2002 07:35:27 -0800 Received: from cbin3-mira-01.cisco.com (cbin3-mira-01.cisco.com [64.104.129.145]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2MFbiY22397 for ; Fri, 22 Mar 2002 07:37:45 -0800 (PST) Received: from localhost ([64.104.137.146]) by cbin3-mira-01.cisco.com (Mirapoint) with SMTP id ABC53775; Fri, 22 Mar 2002 21:05:18 +0530 (IST) Content-Type: text/plain; charset="iso-8859-1" From: "Gopakumar.C.E" Reply-To: gopkumar@cisco.com Organization: Cisco Systems To: linux-mips@oss.sgi.com Subject: Documentation Date: Fri, 22 Mar 2002 21:02:03 +0530 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <0203222102032M.00789@localhost> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Is there any good documentation on how the Linux/Unix code is designed for the MIPS processors ? (like how they handle paging, protection etc?) Thanks Gopakumar.C.E -- "Vidhya dadathi vinayam" - Education leads to humility (in sanskrit). -------------------------------- http://www.geocities.com/gopakumar_ce/ http://wwwin-people.cisco.com/gopkumar/ -------------------------------- From owner-linux-mips@oss.sgi.com Mon Mar 25 10:11:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PIBCx23669 for linux-mips-outgoing; Mon, 25 Mar 2002 10:11:12 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PIB6q23666 for ; Mon, 25 Mar 2002 10:11:07 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g2PIDL200387; Mon, 25 Mar 2002 18:13:25 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15519.26814.797026.923001@gladsmuir.algor.co.uk> Date: Mon, 25 Mar 2002 18:13:18 +0000 To: Johannes Stezenbach Cc: linux-mips@oss.sgi.com Subject: Re: Mips16 toolchain? In-Reply-To: <20020325135834.GA1736@convergence.de> References: <20020325135834.GA1736@convergence.de> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Johannes Stezenbach (js@convergence.de) writes: > Since I'm developing for an embedded target, I wanted to > check out mips16 code generation for the userspace apps. > Unfortunately my gcc aborts with an internal error > on even the simplest test program: No surprise, really. > I saw that the algorithmics toolchain (which Dominic Sweetman > offered to the Linux/MIPS community here a month ago) claims > to have full support for the mips16 instruction set. It does. If you want an 'embedded' toolchain (to generate software to run standalone or in general without position-independent shared libraries) then it's a mature product. We are also developing a compiler from the same source tree, but configured for Linux. That was the compiler we'll be looking for beta-testers for in the next couple of months. If you want to be able to build MIPS16 applications and then run them on Linux, this is more challenging. You have to build everything static: then it works mostly, and some people at MIPS have built and run some programs. It seems likely we'll be doing some development work over the spring/summer to make this more robust and less painful. > How about gcc-3.x from CVS? We believe not. We'd like to converge our compiler (currently 2.96+ based) back to gcc 3.x so we can get most of our MIPS changes into the mainstream tree, but it's not going to be easy. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Mon Mar 25 10:16:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PIGHD23811 for linux-mips-outgoing; Mon, 25 Mar 2002 10:16:17 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PIGDq23808 for ; Mon, 25 Mar 2002 10:16:14 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g2PIIR200621; Mon, 25 Mar 2002 18:18:28 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15519.27120.100625.818807@gladsmuir.algor.co.uk> Date: Mon, 25 Mar 2002 18:18:24 +0000 To: "Girish Gulawani" Cc: "Dan Aizenstros" , , , Subject: Re: Re: PCI VGA Card Initilization (SIS6326 / PT80) In-Reply-To: <00c001c1d197$4a5c14a0$cecd7d3d@gol.com> References: <00c001c1d197$4a5c14a0$cecd7d3d@gol.com> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Girish, > it occurs to me that the x86 emulation for the VGA bios is a long > process. It is. But I believe that video chip companies have the chip designer and the BIOS/Windows driver developer working at adjacent desks. If you knew everything they'd ever said to each other, then there would be no need for an x86 emulator. We thought the x86 emulator was simpler; and evidently so did the MILO people... -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Mon Mar 25 10:55:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PItjU25078 for linux-mips-outgoing; Mon, 25 Mar 2002 10:55:45 -0800 Received: from mail-gw.sonicblue.com (mail-gw.sonicblue.com [209.10.223.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PIthq25075 for ; Mon, 25 Mar 2002 10:55:43 -0800 Received: from relay.sonicblue.com (timbale [10.6.1.10]) by mail-gw.sonicblue.com (8.11.6/8.11.6) with ESMTP id g2PIw1904316 for ; Mon, 25 Mar 2002 11:58:01 -0700 (MST) Received: from corpvirus1.sc.sonicblue.com (corpvirus1.sonicblue.com [10.6.2.49]) by relay.sonicblue.com (8.11.5/8.11.5) with SMTP id g2PIw1600910 for ; Mon, 25 Mar 2002 10:58:01 -0800 (PST) Received: FROM corpmailmx.sonicblue.com BY corpvirus1.sc.sonicblue.com ; Mon Mar 25 11:05:20 2002 -0800 Received: by CORPMAILMX with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 10:58:46 -0800 Message-ID: <37D1208A1C9BD511855B00D0B772242C011C7F15@corpmail1.sc.sonicblue.com> From: Peter Hartley To: linux-mips@oss.sgi.com, linux kernel , GNU C Library Subject: RE: Does e2fsprogs-1.26 work on mips? Date: Mon, 25 Mar 2002 11:00:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk H J Lu wrote: > What are you talking about? It doesn't matter which kernel header > is used. glibc doesn't even use /usr/include/asm/resource.h nor > should any user space applications. It's not about /usr/include/asm/resource.h, it's about /usr/include/asm/unistd.h, where the syscall numbers are defined. This is presumably what the "#ifdef __NR_ugetrlimit" in sysdeps/unix/sysv/linux/i386/getrlimit.c is meant to be testing against -- nothing in the glibc-2.2.5 distribution itself defines that symbol. Surely a Linux glibc doesn't compile without the target system's linux/* and asm/* headers? 2.4's /usr/include/asm/unistd.h defines __NR_ugetrlimit but 2.2's doesn't. Peter From owner-linux-mips@oss.sgi.com Mon Mar 25 12:36:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PKa1027796 for linux-mips-outgoing; Mon, 25 Mar 2002 12:36:01 -0800 Received: from coplin09.mips.com ([80.63.7.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PKZvq27792 for ; Mon, 25 Mar 2002 12:35:57 -0800 Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g2PKbTQ28092 for linux-mips@oss.sgi.com; Mon, 25 Mar 2002 21:37:29 +0100 From: Hartvig Ekner Message-Id: <200203252037.g2PKbTQ28092@coplin09.mips.com> Subject: Re: Mips16 toolchain? To: linux-mips@oss.sgi.com Date: Mon, 25 Mar 2002 21:37:29 +0100 (CET) In-Reply-To: from "Dominic Sweetman" at Mar 25, 2002 06:13:18 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dominic Sweetman writes: > > We are also developing a compiler from the same source tree, but > configured for Linux. That was the compiler we'll be looking for > beta-testers for in the next couple of months. > > If you want to be able to build MIPS16 applications and then run them > on Linux, this is more challenging. You have to build everything > static: then it works mostly, and some people at MIPS have built and > run some programs. I have built glibc in a static and non-PIC version to allow linking against M16 user apps (non-PIC required because current Linux compilers cannot generate M16 PIC code). It worked fine using the Algo 5.0 Beta for Linux. I successfully built a few applications (ones which only required libc). It won't be really useful until somebody builds a complete library set which is static and non-PIC, or PIC support gets included in the M16 code generator. /Hartvig From owner-linux-mips@oss.sgi.com Mon Mar 25 13:31:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PLVdF29170 for linux-mips-outgoing; Mon, 25 Mar 2002 13:31:39 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PLVbq29167 for ; Mon, 25 Mar 2002 13:31:37 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g2PLX1YC003481; Mon, 25 Mar 2002 13:33:01 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g2PLWxht003474; Mon, 25 Mar 2002 13:33:00 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 25 Mar 2002 13:32:59 -0800 (PST) From: James Simmons To: "Maciej W. Rozycki" cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: LK201 hot-plug updates and associated zs.c fixes 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 For 2.5.X I and Vojtech are in the process of moving every keyboard over to the input api. I like to work with you on porting it over to that api. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ From owner-linux-mips@oss.sgi.com Mon Mar 25 15:09:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PN9dK01332 for linux-mips-outgoing; Mon, 25 Mar 2002 15:09:39 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PN9aq01329 for ; Mon, 25 Mar 2002 15:09:36 -0800 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id XAA01793; Mon, 25 Mar 2002 23:22:55 -0800 Message-ID: <3C9FAEB5.2070201@mvista.com> Date: Mon, 25 Mar 2002 15:11:49 -0800 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Y.H. Ku" CC: Marc Karasek , linux-mips@oss.sgi.com Subject: Re: BootLoader on MIPS References: Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Y.H. Ku wrote: > Hi everybody, > > I trace PMON into mips.S, and find the entry "_go". > the entry transfer control to client prog. > > I am confused of what information PMON transfer to MIPS's BOOTLOADER > and transfer to which entry point of BOOTLOADER. > > I found the bd_t struct of PPCBOOT.h for PPCBOOT package on POWERPC platform. > It is corresponding POWERPC-LINUX data structure bd_info in ~/include/asm/mbx.h > (register r3~r7) > > I just can not find the entry for MIPS's one. (can not find corresponding baget.h's one) > > Could anybody tell me what is the information (register inforation) PMON transfer > to bootloader? > > Or anybody can disscuss with me, > NEC provides PMON for DDB5476. You should be able to get it if it is not already on the board. Jun From owner-linux-mips@oss.sgi.com Mon Mar 25 22:52:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q6qZY08388 for linux-mips-outgoing; Mon, 25 Mar 2002 22:52:35 -0800 Received: from snap.thunk.org (SNAP.THUNK.ORG [216.175.175.173]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2Q6qVq08382 for ; Mon, 25 Mar 2002 22:52:31 -0800 Received: from 77.chicago-06-07rs.il.dial-access.att.net ([12.84.2.77] helo=think.thunk.org) by snap.thunk.org with asmtp (Exim 3.33 #1 (Debian)) id 16pkqw-0007HE-00; Tue, 26 Mar 2002 01:54:43 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16pkqu-0003R6-00; Tue, 26 Mar 2002 01:54:40 -0500 Date: Tue, 26 Mar 2002 01:54:40 -0500 From: Theodore Tso To: Andrew Morton Cc: Theodore Tso , "H . J . Lu" , linux-mips@oss.sgi.com, linux kernel , GNU C Library Subject: Re: Does e2fsprogs-1.26 work on mips? Message-ID: <20020326015440.A12162@thunk.org> Mail-Followup-To: Theodore Tso , Andrew Morton , "H . J . Lu" , linux-mips@oss.sgi.com, linux kernel , GNU C Library References: <20020323140728.A4306@lucon.org> <3C9D1C1D.E30B9B4B@zip.com.au> <20020323221627.A10953@lucon.org> <3C9D7A42.B106C62D@zip.com.au> <20020324012819.A13155@lucon.org> <20020325003159.A2340@thunk.org> <3C9EB8F6.247C7C3B@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3C9EB8F6.247C7C3B@zip.com.au>; from akpm@zip.com.au on Sun, Mar 24, 2002 at 09:43:18PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 24, 2002 at 09:43:18PM -0800, Andrew Morton wrote: > Theodore Tso wrote: > > > > And just to be clear ---- although in the past I've been really > > annoyed when glibc has made what I've considered to be arbitrary > > changes which have screwed ABI, compile-time, or link-time > > compatibility, and have spoken out against it --- in this particular > > case, I consider the fault to be purely the fault of the kernel > > developers, so there's no need having the glibc folks get all > > defensive.... > > So... Does the kernel need fixing? If so, what would you > recommend? 1) Created a new syscall for the unsinged setrlimit, not just for getrlimit. This should have been done from the very beginning, IMHO. 2) If the old value of RLIM_INFINITY is passed to the old setrlimit, translate it to the new value of RLIM_INFINITY. (This would not have been strictly necessary of glibc wasn't playing RLIM_INIFITY capping games; as it turns out, if you pass the "new" version of RLIM_INIFITY to an "old" 2.2 kernel, the right thing happens. So there really is no need for glibc to cap the limit of RLIM_INFINITY to the old value.) 3) RLIMIT_FILESIZE should not apply to block devices!!! - Ted From owner-linux-mips@oss.sgi.com Tue Mar 26 00:10:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q8A4v10025 for linux-mips-outgoing; Tue, 26 Mar 2002 00:10:04 -0800 Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2Q89uq10017 for ; Tue, 26 Mar 2002 00:09:56 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id AAA22183; Tue, 26 Mar 2002 00:11:38 -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 AAA07969; Tue, 26 Mar 2002 00:11:38 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g2Q8AwA06389; Tue, 26 Mar 2002 09:10:58 +0100 (MET) Message-ID: <3CA02D11.B011962@mips.com> Date: Tue, 26 Mar 2002 09:10:57 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: Johannes Stezenbach , linux-mips@oss.sgi.com Subject: Re: Mips16 toolchain? References: <20020325135834.GA1736@convergence.de> <00e901c1d40d$a257a200$0deca8c0@Ulysses> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Kevin D. Kissell" wrote: > > I saw that the algorithmics toolchain (which Dominic Sweetman > > offered to the Linux/MIPS community here a month ago) claims > > to have full support for the mips16 instruction set. > > > > My questions: > > Does anyone here have experiences with mips16 and/or with the > > algorithmics toolchain? > > Yes. Both Algorithmics and Green Hills embedded > tool chains support it reasonably well. GHS has no > Linux target, though. Algorithmics has been working > on one, but I'm not sure what it's current status is. > > > Is there working support for mips16 in any other gcc-version? > > Cygnus (now part of Red Hat) did the very first MIPS16 > support for gcc, most of which found its way into the > main development/maintence stream. But apparently > not enough of it, based on your experience. > > > How about gcc-3.x from CVS? > > No data there. > > > Any other comments or recommendations regarding mips16? > > MIPS16 requires more than just gcc support. > One needs a binutils that can distinguish a MIPS16 > binary module (or function if you want to be fancy and > mix/match within modules) from a MIPS32/64 module > and perform fixups so that the right selections are made > between JAL and JALX on function invocations. > If you've got that, you should not need a seperate > MIPS16 libc. > > To correctly support MIPS16, the Linux kernel does > need to be tweaked in those cases where user-mode > instructions are decoded and interpreted, as in > arch/mips/kernel/branch.c and unaligned.c. > I believe that code has been prototyped somewhere, > but it's not yet in any commonly used repository to > the best of my knowledge. If you avoid throwing > executing non-instructions, performing unaligned > accesses, etc, you should be able to tiptoe around > that deficiency. I don't think you need to tiptoe to get it working :-; It should be easy to avoid non-instructions, unaligned accesses and co. We have a few MIPS16 applications running using Algorithmics compiler and a static non-PIC libc. > > 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 Tue Mar 26 02:12:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QACLx12918 for linux-mips-outgoing; Tue, 26 Mar 2002 02:12:21 -0800 Received: from ms45.hinet.net (root@ms45.hinet.net [168.95.4.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QACDq12912 for ; Tue, 26 Mar 2002 02:12:13 -0800 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by ms45.hinet.net (8.8.8/8.8.8) with SMTP id SAA06600; Tue, 26 Mar 2002 18:13:42 +0800 (CST) From: "Y.H. Ku" To: "Jun Sun" Cc: "Marc Karasek" , Subject: RE: BootLoader on MIPS Date: Tue, 26 Mar 2002 18:09:13 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C9FAEB5.2070201@mvista.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g2QACEq12913 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ya, I have traced the PMON code (www.carmel.com/pmon/) with NEC DDB5476 board (linux package from Montavista), (LSI Logic' Software Support Package for MIPS processors version 5.3.33) However, though it seem clear that function "_go" of pmon/head.S transfer control to client program by "j k0" (a exception) BUT I do not understand what information tha PMON transfer to LINUX-MIPS KERNEL I found the KERNEL's entry is "kernel_entry" of ~arch/mips/kernel/head.S. But, I can not find any information just like "board information" be transferred well. where is it!? using sp register with "j k0" command? where is the memory setting be transferred? What MIPS LINUX needed!? (PPCBOOT to PPC-LINUX is clear with a board_info struct, initrd_start and initrd_end ... and work well... REALLY thanks for help, --Ku -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Jun Sun Sent: Tuesday, March 26, 2002 7:12 AM To: Y.H. Ku Cc: Marc Karasek; linux-mips@oss.sgi.com Subject: Re: BootLoader on MIPS Y.H. Ku wrote: > Hi everybody, > > I trace PMON into mips.S, and find the entry "_go". > the entry transfer control to client prog. > > I am confused of what information PMON transfer to MIPS's BOOTLOADER > and transfer to which entry point of BOOTLOADER. > > I found the bd_t struct of PPCBOOT.h for PPCBOOT package on POWERPC platform. > It is corresponding POWERPC-LINUX data structure bd_info in ~/include/asm/mbx.h > (register r3~r7) > > I just can not find the entry for MIPS's one. (can not find corresponding baget.h's one) > > Could anybody tell me what is the information (register inforation) PMON transfer > to bootloader? > > Or anybody can disscuss with me, > NEC provides PMON for DDB5476. You should be able to get it if it is not already on the board. Jun From owner-linux-mips@oss.sgi.com Tue Mar 26 03:03:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QB3sB14271 for linux-mips-outgoing; Tue, 26 Mar 2002 03:03:54 -0800 Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QB3nq14268 for ; Tue, 26 Mar 2002 03:03:49 -0800 Received: by lists.samba.org (Postfix, from userid 1020) id CCFE0467B; Tue, 26 Mar 2002 02:53:12 -0800 (PST) From: Paul Mackerras MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15520.21196.511499.316840@argo.ozlabs.ibm.com> Date: Tue, 26 Mar 2002 21:51:56 +1100 (EST) To: Theodore Tso Cc: Andrew Morton , "H . J . Lu" , linux-mips@oss.sgi.com, linux kernel , GNU C Library Subject: Re: Does e2fsprogs-1.26 work on mips? In-Reply-To: <20020326015440.A12162@thunk.org> References: <20020323140728.A4306@lucon.org> <3C9D1C1D.E30B9B4B@zip.com.au> <20020323221627.A10953@lucon.org> <3C9D7A42.B106C62D@zip.com.au> <20020324012819.A13155@lucon.org> <20020325003159.A2340@thunk.org> <3C9EB8F6.247C7C3B@zip.com.au> <20020326015440.A12162@thunk.org> X-Mailer: VM 6.75 under Emacs 20.7.2 Reply-To: paulus@samba.org Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Theodore Tso writes: > 3) RLIMIT_FILESIZE should not apply to block devices!!! Absolutely. I would go further and say that it should only apply to writes to a regular file that would extend the file past the filesize limit. At the moment the check in generic_file_write is simply whether the file offset is greater than the limit, or would be greater than the limit after the write. This doesn't seem right to me. If, for example, my RLIMIT_FILESIZE is 1MB, and I have write access to an existing 100MB file, I think I should be able to write anywhere in that file as long as I don't try to extend it. If we did that then the block device case would fall out, since you can't extend block devices (not by writing past the end of them anyway). Paul. From owner-linux-mips@oss.sgi.com Tue Mar 26 10:06:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QI6Xk02543 for linux-mips-outgoing; Tue, 26 Mar 2002 10:06:33 -0800 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QI6Rq02532 for ; Tue, 26 Mar 2002 10:06:27 -0800 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA21426; Tue, 26 Mar 2002 18:19:38 -0800 Message-ID: <3CA0B924.2030003@mvista.com> Date: Tue, 26 Mar 2002 10:08:36 -0800 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Y.H. Ku" CC: Marc Karasek , linux-mips@oss.sgi.com Subject: Re: BootLoader on MIPS References: Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Y.H. Ku wrote: > Ya, > I have traced the PMON code (www.carmel.com/pmon/) with NEC DDB5476 board (linux package from Montavista), > (LSI Logic' Software Support Package for MIPS processors version 5.3.33) > > However, though it seem clear that function "_go" of pmon/head.S transfer control to client program > by "j k0" (a exception) > BUT I do not understand what information tha PMON transfer to LINUX-MIPS KERNEL > I found the KERNEL's entry is "kernel_entry" of ~arch/mips/kernel/head.S. > But, I can not find any information just like "board information" be transferred well. > where is it!? "board information" is not transferred to kernel. However, parameters you pass (as in "go ") are passed in as standard C main argument style. These are processed in arch/mips/ddb5xxx/common/prom.c file, i.e., held in a0, a1 registers. > using sp register with "j k0" command? No. sp is not meaningful when kernel starts. > where is the memory setting be transferred? system ram size? It is hardcode in ddb5476 code. See include/asm/ddb5xxx/ddb5476.h file. > What MIPS LINUX needed!? I thought you have montavista linux (probably hardhat 2.0?). > (PPCBOOT to PPC-LINUX is clear with a board_info struct, initrd_start and initrd_end ... and work well... > PPC booting is more regular than MIPS in general. So they have a more uniform bootup process and structure. MIPS have a lot of vendors who are usually very creative. Jun From owner-linux-mips@oss.sgi.com Tue Mar 26 10:51:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QIpOZ03550 for linux-mips-outgoing; Tue, 26 Mar 2002 10:51:24 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QIpKq03546 for ; Tue, 26 Mar 2002 10:51:20 -0800 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16pw4e-0003Bd-00 for ; Tue, 26 Mar 2002 19:53:36 +0100 Date: Tue, 26 Mar 2002 19:53:36 +0100 From: Johannes Stezenbach To: linux-mips@oss.sgi.com Subject: Re: Mips16 toolchain? Message-ID: <20020326185336.GA6017@convergence.de> Mail-Followup-To: Johannes Stezenbach , linux-mips@oss.sgi.com References: <20020325135834.GA1736@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020325135834.GA1736@convergence.de> User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk First of all, many thanks for your help! I wrote: > $ mips-linux-gcc -mips16 -Wall -S t16.c > t16.c: In function `main': > t16.c:8: Internal compiler error: Non-PIC mips16 compilation seems to work with gcc-2.95.4-debian: $ mips-linux-gcc -fno-pic -mno-abicalls -mips16 -Wall -c t16.c yields a t16.o, which looks good when disassembled with mips-linux-objdump. Now I need a non-PIC version of libgcc to link against, since mips-linux-ld cannot link PIC with non-PIC code. I had built a non-PIC libgcc for earlier dietlibc experiments, but discarded it in favor of a less experimental development environment... I feel I have to learn more about the Linux kernel's role when executing mips16 code (unaligned.c etc.), and experiment more with my toolchain, until I know what I'm really doing ;-) I will post here when I have any meaningful results. Regards, Johannes From owner-linux-mips@oss.sgi.com Tue Mar 26 15:36:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QNa2k12524 for linux-mips-outgoing; Tue, 26 Mar 2002 15:36:02 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QNa0q12521 for ; Tue, 26 Mar 2002 15:36:00 -0800 Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g2QNZvY08414 for ; Tue, 26 Mar 2002 18:35:57 -0500 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g2QNcNm03653 for ; Tue, 26 Mar 2002 18:38:23 -0500 Received: from redhat.com (dhcp-105.hsv.redhat.com [172.16.17.105]) by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id g2QNcUN29120; Tue, 26 Mar 2002 17:38:30 -0600 Message-ID: <3CA10449.F0088B95@redhat.com> Date: Tue, 26 Mar 2002 17:29:13 -0600 From: David Milburn Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: PCI ethernet cards Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, Can anyone recommend some PCI 100 Mbit ethernet cards/drivers that work well with the 2.4 linux-mips kernel? Thanks, David From owner-linux-mips@oss.sgi.com Tue Mar 26 18:54:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R2sas16996 for linux-mips-outgoing; Tue, 26 Mar 2002 18:54:36 -0800 Received: from zoetrope (mail@h24-77-117-155.vc.shawcable.net [24.77.117.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R2sVq16993 for ; Tue, 26 Mar 2002 18:54:31 -0800 Received: from lattice (helo=localhost) by zoetrope with local-esmtp (Exim 3.34 #1 (Debian)) id 16q3cM-0002FV-00 for ; Tue, 26 Mar 2002 18:56:54 -0800 Date: Tue, 26 Mar 2002 18:56:54 -0800 (PST) From: blaine X-X-Sender: lattice@zoetrope To: linux-mips@oss.sgi.com Subject: Parallel Port support on Indy? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi there; I've recently acquired an Indy, and I'd like to use it as my closet firewall/webserver/printer box. I've been able to install debian/woody without event, and the linux_2_4 tag from sgi's cvs compiles fine, giving me OSS sound support with the HAL2 and enabling the Vino video system. X came working out of the box... The only thing I *can't* do with the Indy is use the parallel port, which, in my case, is the most important thing... As far as I can tell from reading around, the Indy supports a standard SPP parallel port (plus a bunch of extra modes that haven't been implemented in linux, afaict), but has a different base i/o address in addition to having the data and control addresses at different offsets. I tried playing around with the constants in [header file that controls that stuff in include/linux], and managed to get the parport_pc module to stop causing a [non-fatal] kernel oops. Now it just says something is wrong. ;-) I would like to pursue fixing this, but being a student and not having any experience playing with low-level hardware or kernel hacking are conspiring against me. Is getting parport support on the Indy a major undertaking, or are there just a few tweaks that need to be made to existing drivers? Any help on this would be most appreciated. Thanks, blaine cook. _ . ( o> - INDEED. .o. ///\ \/ ___`\V_/__http://www.yellow5.com/pokey/__/____ From owner-linux-mips@oss.sgi.com Tue Mar 26 23:41:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R7fGS29829 for linux-mips-outgoing; Tue, 26 Mar 2002 23:41:16 -0800 Received: from indy (hlubocky.del.cz [212.27.221.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R7fAq29823 for ; Tue, 26 Mar 2002 23:41:11 -0800 Received: from ladis by indy with local (Exim 3.35 #1 (Debian)) id 16q85d-0000CB-00; Wed, 27 Mar 2002 08:43:25 +0100 Date: Wed, 27 Mar 2002 08:43:24 +0100 To: blaine Cc: linux-mips@oss.sgi.com Subject: Re: Parallel Port support on Indy? Message-ID: <20020327074324.GB645@indy> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i From: Ladislav Michl Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Mar 26, 2002 at 06:56:54PM -0800, blaine wrote: > Hi there; hi, > I've recently acquired an Indy, and I'd like to use it as my closet > firewall/webserver/printer box. I've been able to install debian/woody > without event, and the linux_2_4 tag from sgi's cvs compiles fine, > giving me OSS sound support with the HAL2 and enabling the Vino video enabling the Vino video does currently nothing. > system. X came working out of the box... > > The only thing I *can't* do with the Indy is use the parallel port, no support for it. > which, in my case, is the most important thing... As far as I can tell > from reading around, the Indy supports a standard SPP parallel port SPP, SGIPP (SGI parallel port), HPBPP (HP BOISE high speed parallel port) and Ricoh scanner mode. there are two modes of operation - register and DMA. > (plus a bunch of extra modes that haven't been implemented in linux, > afaict), but has a different base i/o address in addition to having the all IP22 peripherals are memory maped. > data and control addresses at different offsets. I tried playing around > with the constants in [header file that controls that stuff in > include/linux], and managed to get the parport_pc module to stop causing > a [non-fatal] kernel oops. Now it just says something is wrong. ;-) aieee :-) Indy's PP is based on PI1 chip developed by SGI, so the only way to get it work is write something like parport_sgi... patches welcome :-) > I would like to pursue fixing this, but being a student and not having > any experience playing with low-level hardware or kernel hacking are > conspiring against me. when i bring Indy to home i was in the same situation :-) > Is getting parport support on the Indy a major undertaking, or are > there just a few tweaks that need to be made to existing drivers? unfortunately you have to write your own driver. ladis From owner-linux-mips@oss.sgi.com Tue Mar 26 23:40:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R7eEC29716 for linux-mips-outgoing; Tue, 26 Mar 2002 23:40:14 -0800 Received: from ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R7eBq29708 for ; Tue, 26 Mar 2002 23:40:11 -0800 Received: from [192.168.2.2] (IDENT:root@earth.ayrnetworks.com [10.1.1.24]) by ayrnetworks.com (8.11.6/8.11.2) with ESMTP id g2R7df824249; Tue, 26 Mar 2002 23:39:42 -0800 Mime-Version: 1.0 X-Sender: kph@192.168.2.1 Message-Id: In-Reply-To: <3CA10449.F0088B95@redhat.com> References: <3CA10449.F0088B95@redhat.com> Date: Tue, 26 Mar 2002 23:42:13 -0800 To: David Milburn , linux-mips@oss.sgi.com From: Kevin Paul Herbert Subject: Re: PCI ethernet cards Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk At 5:29 PM -0600 3/26/02, David Milburn wrote: >Hello, > >Can anyone recommend some PCI 100 Mbit ethernet cards/drivers >that work well with the 2.4 linux-mips kernel? > >Thanks, >David I've used the tulip driver and a DEC21140-based ethernet adapter (proprietary) on rm7000/big endian. There are a few endian bugs (at least in 2.4.2) dealing with some debugging messages, but besides that the driver works just fine. Note that the 2.4.2 tulip driver uses PCI I/O space. If you don't support PCI I/O space on your platform, this may be a problem. Later kernels have an option for using memory mapped PCI space, but I haven't tried that driver option yet. I've also successfully used an i82543-based PCI adapter using the driver available on intel's website. This is a 10/100/1000 adapter. Again, the only changes that I needed were because of the proprietary nature of my platform's I/O interfaces; if you are using intel's adapter the driver should work for you out of the box. Kevin -- From owner-linux-mips@oss.sgi.com Wed Mar 27 00:24:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R8OGG31164 for linux-mips-outgoing; Wed, 27 Mar 2002 00:24:16 -0800 Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R8ODq31161 for ; Wed, 27 Mar 2002 00:24:14 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id AAA27201; Wed, 27 Mar 2002 00:26:26 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA20681; Wed, 27 Mar 2002 00:26:28 -0800 (PST) Message-ID: <002301c1d569$4af46ea0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "David Milburn" , References: <3CA10449.F0088B95@redhat.com> Subject: Re: PCI ethernet cards Date: Wed, 27 Mar 2002 09:26: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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Can anyone recommend some PCI 100 Mbit ethernet cards/drivers > that work well with the 2.4 linux-mips kernel? At MIPS, we use AMD PCnet32 cards pretty exclusively, and with good success under both 2.2 and 2.4. For 2.2, we did a pretty thorough reworking of the driver to deal with MIPS endianness and (especially) cache issues, but I believe we use the 2.4 driver "out of the box". YMMV, of course. Kevin K. From owner-linux-mips@oss.sgi.com Wed Mar 27 04:16:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RCGq603570 for linux-mips-outgoing; Wed, 27 Mar 2002 04:16:52 -0800 Received: from ms45.hinet.net (root@ms45.hinet.net [168.95.4.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RCGmq03567 for ; Wed, 27 Mar 2002 04:16:49 -0800 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by ms45.hinet.net (8.8.8/8.8.8) with SMTP id UAA04657 for ; Wed, 27 Mar 2002 20:19:06 +0800 (CST) From: "Y.H. Ku" To: Subject: RE: BootLoader on MIPS Date: Wed, 27 Mar 2002 20:14:38 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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.00.2919.6600 In-Reply-To: <3CA0B924.2030003@mvista.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g2RCGoq03568 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks All!!!! What I want to know is how PMON jump to linux kernel image, when mips.S function "_go" execute "j k0" command, (k0 is assigned by LREG(k0,R_EPC,gp) /* EPC */) k0 will be 40*(DBGREG)=40* (0x7ff00bad), the address is kuseg's domain. is it really work to turnin linux kernel image?? (In common case, linux kernl image always start from 0x100000) any suggestion? I just want to know MORE about the LINK method between PMON and MIPS-Linux? best regards, --Ku From owner-linux-mips@oss.sgi.com Wed Mar 27 04:22:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RCM1Q03665 for linux-mips-outgoing; Wed, 27 Mar 2002 04:22:01 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RCLuq03661 for ; Wed, 27 Mar 2002 04:21:56 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA06294; Wed, 27 Mar 2002 13:23:28 +0100 (MET) Date: Wed, 27 Mar 2002 13:23:27 +0100 (MET) From: Geert Uytterhoeven To: "Y.H. Ku" cc: Linux/MIPS Development Subject: RE: BootLoader on MIPS 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 On Wed, 27 Mar 2002, Y.H. Ku wrote: > What I want to know is how PMON jump to linux kernel image, > > when mips.S function "_go" execute "j k0" command, > (k0 is assigned by LREG(k0,R_EPC,gp) /* EPC */) > k0 will be 40*(DBGREG)=40* (0x7ff00bad), > > the address is kuseg's domain. is it really work to turnin linux kernel image?? > (In common case, linux kernl image always start from 0x100000) > > any suggestion? > I just want to know MORE about the LINK method between PMON and MIPS-Linux? On NEC DDB Vrc-5074, I always used something like call kernel_entry -s 'console=ttyS4' Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Wed Mar 27 13:01:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RL1fV17907 for linux-mips-outgoing; Wed, 27 Mar 2002 13:01:41 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RL1Zq17903 for ; Wed, 27 Mar 2002 13:01:36 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16qKaE-00023w-00; Wed, 27 Mar 2002 15:03:51 -0600 Message-ID: <3CA233B6.58DB8B08@cotw.com> Date: Wed, 27 Mar 2002 15:03:50 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: binutils@sources.redhat.com, linux-mips@oss.sgi.com, uclibc@uclibc.org Subject: Linux/MIPS and ELF dynamic linker/loader questions... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Greetings. I am working on a MIPS dynamic linker/loader for uClibc and would appreciate some clarification on the finer points of ELF and the Linux kernel interface. Forgive the cross post. The first problem I have discovered is that the value of argc passed back to the userspace process from the Linux kernel is always zero. The argv, environment and auxillary vectors come through just fine. I have to loop through the stack manually to count the number of argument vectors in order to get argc: #if defined(__mips__) argc = 0; aux_dat = sp + 1; while (*aux_dat++) argc++; #endif This code snippet is the first code to execute in the dynamic linker, so no trashing of argc should have had a chance to happen. Any insight? The second question has to do with printing string constants to stderr like so: static inline _syscall3(unsigned long, _dl_write, int, fd, const void *, buf, unsigned long, count); #define SEND_STDERR(X) _dl_write(2, X, _dl_strlen(X)); SEND_STDERR("ELF header ="); The problem as I understand it is that string constants for MIPS are accessed using the GOT (since the dynamic linker is all PIC code). Since I haven't bootstrapped and relocated the dynamic linker yet, the above SEND_STDERR call causes a SEGFAULT as the address is invalid. Also, it appears that the constants are stored in the .rodata section. Is there a quick hack to get a hold of the string constants? Flames, help, etc. appreciated. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Wed Mar 27 13:06:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RL6tl18013 for linux-mips-outgoing; Wed, 27 Mar 2002 13:06:55 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RL6nq18009 for ; Wed, 27 Mar 2002 13:06:49 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 833D01EA91; Wed, 27 Mar 2002 22:09:07 +0100 (MET) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f To: sjhill@cotw.com Cc: binutils@sources.redhat.com, linux-mips@oss.sgi.com, uclibc@uclibc.org Subject: Re: Linux/MIPS and ELF dynamic linker/loader questions... References: <3CA233B6.58DB8B08@cotw.com> From: Andreas Jaeger Date: Wed, 27 Mar 2002 22:09:00 +0100 In-Reply-To: <3CA233B6.58DB8B08@cotw.com> ("Steven J. Hill"'s message of "Wed, 27 Mar 2002 15:03:50 -0600") Message-ID: Lines: 47 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Steven J. Hill" writes: > Greetings. > > I am working on a MIPS dynamic linker/loader for uClibc and > would appreciate some clarification on the finer points of > ELF and the Linux kernel interface. Forgive the cross post. > > The first problem I have discovered is that the value of > argc passed back to the userspace process from the Linux > kernel is always zero. The argv, environment and auxillary > vectors come through just fine. I have to loop through the > stack manually to count the number of argument vectors in > order to get argc: In glibc I had no problems finding argc, check sysdeps/mips/elf/start.S: /* This is the canonical entry point, usually the first thing in the text segment. The SVR4/Mips ABI (pages 3-31, 3-32) says that when the entry point runs, most registers' values are unspecified, except for: v0 ($2) Contains a function pointer to be registered with `atexit'. This is how the dynamic linker arranges to have DT_FINI functions called for shared libraries that have been loaded before this code runs. sp ($29) The stack contains the arguments and environment: 0(%esp) argc 4(%esp) argv[0] ... (4*argc)(%esp) NULL (4*(argc+1))(%esp) envp[0] ... NULL ra ($31) The return address register is set to zero so that programs that search backword through stack frames recognize the last stack frame. */ Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Wed Mar 27 13:19:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RLJHD18176 for linux-mips-outgoing; Wed, 27 Mar 2002 13:19:17 -0800 Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RLJDq18173 for ; Wed, 27 Mar 2002 13:19:14 -0800 Received: from [80.141.91.231] (helo=there) by smtp.web.de with smtp (WEB.DE(Exim) 4.43 #48) id 16qKqX-00062M-00; Wed, 27 Mar 2002 22:20:41 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Harald Koerfgen Organization: none to speak of To: "Maciej W. Rozycki" , Dave Airlie Subject: Re: [patch] linux: declance multicast filter fixes Date: Wed, 27 Mar 2002 22:20:46 +0100 X-Mailer: KMail [version 1.3.2] Cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, On Monday 25 March 2002 12:40, Maciej W. Rozycki wrote: > Well, the core seems to be already separated -- see drivers/net/7990.c. > I haven't yet checked how suitable it is and many front-end drivers use it > already. > > For the I/O ASIC front-end I'm going to check if the ASIC is capable of > mapping the LANCE more sensibly before starting any further work. The > current configuration is a major loss, doubling the CPU's work and I can't > see any reasonable explanation for such a setup. It's been quite some time since I have hacked the declance driver and I don't remember all the details, so take the following with a grain of salt. The 7990 is basically a 16-bit chip in a 32-bit environment, and, AFAIR, uses two different DMA modes to access host memory. One is a 16-bit word-by-word access for the ring descriptors and the other is 8 16-bit-words-bursts for accessing the ring buffers themselves, where the LANCE only generates one target address per burst. The IOASIC is, just as the CPU, only capable of doing 32-bit transfers to/from memory. So 16-bit LANCE accesses are translated into 32-bit IOASIC accesses but a part of the DMA target addresses are generated by the LANCE. This leads to a 16-bit -> 32-bit mapping for the ring descriptors and a 8*16-bit -> 8*32-bit mapping for ring buffers. Very efficient :-(. Greetings, Harald From owner-linux-mips@oss.sgi.com Thu Mar 28 04:59:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SCxPN09336 for linux-mips-outgoing; Thu, 28 Mar 2002 04:59:25 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2SCxKq09332 for ; Thu, 28 Mar 2002 04:59:20 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA11915; Thu, 28 Mar 2002 14:01:51 +0100 (MET) Date: Thu, 28 Mar 2002 14:01:51 +0100 (MET) From: "Maciej W. Rozycki" To: Harald Koerfgen cc: Dave Airlie , Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: declance multicast filter fixes In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 27 Mar 2002, Harald Koerfgen wrote: > The 7990 is basically a 16-bit chip in a 32-bit environment, and, AFAIR, uses > two different DMA modes to access host memory. One is a 16-bit word-by-word > access for the ring descriptors and the other is 8 16-bit-words-bursts for > accessing the ring buffers themselves, where the LANCE only generates one > target address per burst. > > The IOASIC is, just as the CPU, only capable of doing 32-bit transfers > to/from memory. So 16-bit LANCE accesses are translated into 32-bit IOASIC > accesses but a part of the DMA target addresses are generated by the LANCE. But the I/O ASIC chip is smart enough to merge data from the 8-bit ROM device without problems and present four consecutive bytes as 32-bit quantities to the host CPU. Why couldn't it do the same for the LANCE? Host memory addresses are generated on behalf of the LANCE by the I/O ASIC anyway. Of course not all designers have a clue, sigh... A brief study of available documentation suggests no merging mode was implemented for the LANCE and bit 0 of addresses generated is simply hardwired to 0. :-( -- + 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 Thu Mar 28 05:25:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SDPFl09673 for linux-mips-outgoing; Thu, 28 Mar 2002 05:25:15 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2SDOSq09669 for ; Thu, 28 Mar 2002 05:24:28 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA12347; Thu, 28 Mar 2002 14:26:56 +0100 (MET) Date: Thu, 28 Mar 2002 14:26:55 +0100 (MET) From: "Maciej W. Rozycki" To: David Woodhouse , Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4: DEC MS02-NV NVRAM module support Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, The patch adds support for the DEC MS02-type lithium battery backed-up NVRAM board. The board provides 1MB (architecturally up to 4MB) of fast SRAM originally meant as a PrestoServe NFS accelerator for the MIPS-based DECstations. The code works fine for me since its creation back in August. It was not tested by anyone else -- after announcing the code at the "linux-mips" list last year I've read from two volunteers but they did not come back with results ever. I believe it's suitable for inclusion in the official kernel. The patch applies both to 2.4.19-pre4 and to the current CVS tree at oss.sgi.com. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.18-20020327-ms02-nv-69 diff -up --recursive --new-file linux-mips-2.4.18-20020327.macro/Documentation/Configure.help linux-mips-2.4.18-20020327/Documentation/Configure.help --- linux-mips-2.4.18-20020327.macro/Documentation/Configure.help 2002-02-27 05:27:43.000000000 +0000 +++ linux-mips-2.4.18-20020327/Documentation/Configure.help 2002-03-28 09:30:03.000000000 +0000 @@ -12495,6 +12495,18 @@ CONFIG_MTD_SLRAM you can still use it for storage or swap by using this driver to present it to the system as a Memory Technology Device. +DEC MS02-NV NVRAM module support +CONFIG_MTD_MS02NV + This is a MTD driver for the DEC's MS02-type battery backed-up NVRAM + module. The module was originally meant as an NFS accelerator. Say Y + here if you have a DECstation 5000/2x0 or a DECsystem 5900 equipped + with such a module. + + If you want to compile this driver as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read Documentation/modules.txt. The module will be + called ms02-nv.o. + Debugging RAM test driver CONFIG_MTD_MTDRAM This enables a test MTD device driver which uses vmalloc() to diff -up --recursive --new-file linux-mips-2.4.18-20020327.macro/drivers/mtd/devices/Config.in linux-mips-2.4.18-20020327/drivers/mtd/devices/Config.in --- linux-mips-2.4.18-20020327.macro/drivers/mtd/devices/Config.in 2001-11-06 05:27:13.000000000 +0000 +++ linux-mips-2.4.18-20020327/drivers/mtd/devices/Config.in 2002-03-28 09:29:07.000000000 +0000 @@ -10,6 +10,7 @@ if [ "$CONFIG_MTD_PMC551" = "y" -o "$CO bool ' PMC551 256M DRAM Bugfix' CONFIG_MTD_PMC551_BUGFIX bool ' PMC551 Debugging' CONFIG_MTD_PMC551_DEBUG fi +dep_tristate ' DEC MS02-NV NVRAM module support' CONFIG_MTD_MS02NV $CONFIG_MTD $CONFIG_DECSTATION dep_tristate ' Uncached system RAM' CONFIG_MTD_SLRAM $CONFIG_MTD if [ "$CONFIG_SA1100_LART" = "y" ]; then dep_tristate ' 28F160xx flash driver for LART' CONFIG_MTD_LART $CONFIG_MTD diff -up --recursive --new-file linux-mips-2.4.18-20020327.macro/drivers/mtd/devices/Makefile linux-mips-2.4.18-20020327/drivers/mtd/devices/Makefile --- linux-mips-2.4.18-20020327.macro/drivers/mtd/devices/Makefile 2001-11-06 05:27:13.000000000 +0000 +++ linux-mips-2.4.18-20020327/drivers/mtd/devices/Makefile 2002-03-28 09:29:07.000000000 +0000 @@ -18,6 +18,7 @@ obj-$(CONFIG_MTD_DOC2001) += doc2001.o obj-$(CONFIG_MTD_DOCPROBE) += docprobe.o docecc.o obj-$(CONFIG_MTD_SLRAM) += slram.o obj-$(CONFIG_MTD_PMC551) += pmc551.o +obj-$(CONFIG_MTD_MS02NV) += ms02-nv.o obj-$(CONFIG_MTD_MTDRAM) += mtdram.o obj-$(CONFIG_MTD_LART) += lart.o obj-$(CONFIG_MTD_BLKMTD) += blkmtd.o diff -up --recursive --new-file linux-mips-2.4.18-20020327.macro/drivers/mtd/devices/ms02-nv.c linux-mips-2.4.18-20020327/drivers/mtd/devices/ms02-nv.c --- linux-mips-2.4.18-20020327.macro/drivers/mtd/devices/ms02-nv.c 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips-2.4.18-20020327/drivers/mtd/devices/ms02-nv.c 2002-03-28 09:35:33.000000000 +0000 @@ -0,0 +1,323 @@ +/* + * Copyright (c) 2001 Maciej W. Rozycki + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "ms02-nv.h" + + +static char version[] __initdata = + "ms02-nv.c: v.1.0.0 13 Aug 2001 Maciej W. Rozycki.\n"; + +MODULE_AUTHOR("Maciej W. Rozycki "); +MODULE_DESCRIPTION("DEC MS02-NV NVRAM module driver"); +MODULE_LICENSE("GPL"); + + +/* + * Addresses we probe for an MS02-NV at. Modules may be located + * at any 8MB boundary within a 0MB up to 112MB range or at any 32MB + * boundary within a 0MB up to 448MB range. We don't support a module + * at 0MB, though. + */ +static ulong ms02nv_addrs[] __initdata = { + 0x07000000, 0x06800000, 0x06000000, 0x05800000, 0x05000000, + 0x04800000, 0x04000000, 0x03800000, 0x03000000, 0x02800000, + 0x02000000, 0x01800000, 0x01000000, 0x00800000 +}; + +static const char ms02nv_name[] = "DEC MS02-NV NVRAM"; +static const char ms02nv_res_diag_ram[] = "Diagnostic RAM"; +static const char ms02nv_res_user_ram[] = "General-purpose RAM"; +static const char ms02nv_res_csr[] = "Control and status register"; + +static struct mtd_info *root_ms02nv_mtd; + + +static int ms02nv_read(struct mtd_info *mtd, loff_t from, + size_t len, size_t *retlen, u_char *buf) +{ + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + if (from + len > mtd->size) + return -EINVAL; + + memcpy(buf, mp->uaddr + from, len); + *retlen = len; + + return 0; +} + +static int ms02nv_write(struct mtd_info *mtd, loff_t to, + size_t len, size_t *retlen, const u_char *buf) +{ + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + if (to + len > mtd->size) + return -EINVAL; + + memcpy(mp->uaddr + to, buf, len); + *retlen = len; + + return 0; +} + + +static inline uint ms02nv_probe_one(ulong addr) +{ + ms02nv_uint *ms02nv_diagp; + ms02nv_uint *ms02nv_magicp; + uint ms02nv_diag; + uint ms02nv_magic; + size_t size; + + int err; + + /* + * The firmware writes MS02NV_ID at MS02NV_MAGIC and also + * a diagnostic status at MS02NV_DIAG. + */ + ms02nv_diagp = (ms02nv_uint *)(KSEG1ADDR(addr + MS02NV_DIAG)); + ms02nv_magicp = (ms02nv_uint *)(KSEG1ADDR(addr + MS02NV_MAGIC)); + err = get_dbe(ms02nv_magic, ms02nv_magicp); + if (err) + return 0; + if (ms02nv_magic != MS02NV_ID) + return 0; + + ms02nv_diag = *ms02nv_diagp; + size = (ms02nv_diag & MS02NV_DIAG_SIZE_MASK) << MS02NV_DIAG_SIZE_SHIFT; + if (size > MS02NV_CSR) + size = MS02NV_CSR; + + return size; +} + +static int __init ms02nv_init_one(ulong addr) +{ + struct mtd_info *mtd; + struct ms02nv_private *mp; + struct resource *mod_res; + struct resource *diag_res; + struct resource *user_res; + struct resource *csr_res; + ulong fixaddr; + size_t size, fixsize; + + static int version_printed; + + int ret = -ENODEV; + + /* The module decodes 8MB of address space. */ + mod_res = kmalloc(sizeof(*mod_res), GFP_KERNEL); + if (!mod_res) + return -ENOMEM; + + memset(mod_res, 0, sizeof(*mod_res)); + mod_res->name = ms02nv_name; + mod_res->start = addr; + mod_res->end = addr + MS02NV_SLOT_SIZE - 1; + mod_res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; + if (request_resource(&iomem_resource, mod_res) < 0) + goto err_out_mod_res; + + size = ms02nv_probe_one(addr); + if (!size) + goto err_out_mod_res_rel; + + if (!version_printed) { + printk(KERN_INFO "%s", version); + version_printed = 1; + } + + ret = -ENOMEM; + mtd = kmalloc(sizeof(*mtd), GFP_KERNEL); + if (!mtd) + goto err_out_mod_res_rel; + memset(mtd, 0, sizeof(*mtd)); + mp = kmalloc(sizeof(*mp), GFP_KERNEL); + if (!mp) + goto err_out_mtd; + memset(mp, 0, sizeof(*mp)); + + mtd->priv = mp; + mp->resource.module = mod_res; + + /* Firmware's diagnostic NVRAM area. */ + diag_res = kmalloc(sizeof(*diag_res), GFP_KERNEL); + if (!diag_res) + goto err_out_mp; + + memset(diag_res, 0, sizeof(*diag_res)); + diag_res->name = ms02nv_res_diag_ram; + diag_res->start = addr; + diag_res->end = addr + MS02NV_RAM - 1; + diag_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, diag_res); + + mp->resource.diag_ram = diag_res; + + /* User-available general-purpose NVRAM area. */ + user_res = kmalloc(sizeof(*user_res), GFP_KERNEL); + if (!user_res) + goto err_out_diag_res; + + memset(user_res, 0, sizeof(*user_res)); + user_res->name = ms02nv_res_user_ram; + user_res->start = addr + MS02NV_RAM; + user_res->end = addr + size - 1; + user_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, user_res); + + mp->resource.user_ram = user_res; + + /* Control and status register. */ + csr_res = kmalloc(sizeof(*csr_res), GFP_KERNEL); + if (!csr_res) + goto err_out_user_res; + + memset(csr_res, 0, sizeof(*csr_res)); + csr_res->name = ms02nv_res_csr; + csr_res->start = addr + MS02NV_CSR; + csr_res->end = addr + MS02NV_CSR + 3; + csr_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, csr_res); + + mp->resource.csr = csr_res; + + mp->addr = phys_to_virt(addr); + mp->size = size; + + /* + * Hide the firmware's diagnostic area. It may get destroyed + * upon a reboot. Take paging into account for mapping support. + */ + fixaddr = (addr + MS02NV_RAM + PAGE_SIZE - 1) & ~(PAGE_SIZE - 1); + fixsize = (size - (fixaddr - addr)) & ~(PAGE_SIZE - 1); + mp->uaddr = phys_to_virt(fixaddr); + + mtd->type = MTD_RAM; + mtd->flags = MTD_CAP_RAM | MTD_XIP; + mtd->size = fixsize; + mtd->name = (char *)ms02nv_name; + mtd->module = THIS_MODULE; + mtd->read = ms02nv_read; + mtd->write = ms02nv_write; + + ret = -EIO; + if (add_mtd_device(mtd)) { + printk(KERN_ERR + "ms02-nv: Unable to register MTD device, aborting!\n"); + goto err_out_csr_res; + } + + printk(KERN_INFO "mtd%d: %s at 0x%08lx, size %uMB.\n", + mtd->index, ms02nv_name, addr, size >> 20); + + mp->next = root_ms02nv_mtd; + root_ms02nv_mtd = mtd; + + return 0; + + +err_out_csr_res: + release_resource(csr_res); + kfree(csr_res); +err_out_user_res: + release_resource(user_res); + kfree(user_res); +err_out_diag_res: + release_resource(diag_res); + kfree(diag_res); +err_out_mp: + kfree(mp); +err_out_mtd: + kfree(mtd); +err_out_mod_res_rel: + release_resource(mod_res); +err_out_mod_res: + kfree(mod_res); + return ret; +} + +static void __exit ms02nv_remove_one(void) +{ + struct mtd_info *mtd = root_ms02nv_mtd; + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + root_ms02nv_mtd = mp->next; + + del_mtd_device(mtd); + + release_resource(mp->resource.csr); + kfree(mp->resource.csr); + release_resource(mp->resource.user_ram); + kfree(mp->resource.user_ram); + release_resource(mp->resource.diag_ram); + kfree(mp->resource.diag_ram); + release_resource(mp->resource.module); + kfree(mp->resource.module); + kfree(mp); + kfree(mtd); +} + + +static int __init ms02nv_init(void) +{ + volatile u32 *csr; + uint stride = 0; + int count = 0; + int i; + + switch (mips_machtype) { + case MACH_DS5000_200: + csr = (volatile u32 *)KN02_CSR_ADDR; + if (*csr & KN02_CSR_BNK32M) + stride = 2; + break; + case MACH_DS5000_2X0: + csr = (volatile u32 *)KN03_MCR_BASE; + if (*csr & KN03_MCR_BNK32M) + stride = 2; + break; + default: + return -ENODEV; + break; + } + + for (i = 0; i < (sizeof(ms02nv_addrs) / sizeof(*ms02nv_addrs)); i++) + if (!ms02nv_init_one(ms02nv_addrs[i] << stride)) + count++; + + return (count > 0) ? 0 : -ENODEV; +} + +static void __exit ms02nv_cleanup(void) +{ + while (root_ms02nv_mtd) + ms02nv_remove_one(); +} + + +module_init(ms02nv_init); +module_exit(ms02nv_cleanup); diff -up --recursive --new-file linux-mips-2.4.18-20020327.macro/drivers/mtd/devices/ms02-nv.h linux-mips-2.4.18-20020327/drivers/mtd/devices/ms02-nv.h --- linux-mips-2.4.18-20020327.macro/drivers/mtd/devices/ms02-nv.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips-2.4.18-20020327/drivers/mtd/devices/ms02-nv.h 2001-08-12 20:10:10.000000000 +0000 @@ -0,0 +1,43 @@ +/* + * Copyright (c) 2001 Maciej W. Rozycki + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include + +/* MS02-NV iomem register offsets. */ +#define MS02NV_CSR 0x400000 /* control & status register */ + +/* MS02-NV memory offsets. */ +#define MS02NV_DIAG 0x0003f8 /* diagnostic status */ +#define MS02NV_MAGIC 0x0003fc /* MS02-NV magic ID */ +#define MS02NV_RAM 0x000400 /* general-purpose RAM start */ + +/* MS02-NV diagnostic status constants. */ +#define MS02NV_DIAG_SIZE_MASK 0xf0 /* RAM size mask */ +#define MS02NV_DIAG_SIZE_SHIFT 0x10 /* RAM size shift (left) */ + +/* MS02-NV general constants. */ +#define MS02NV_ID 0x03021966 /* MS02-NV magic ID value */ +#define MS02NV_SLOT_SIZE 0x800000 /* size of the address space + decoded by the module */ + +typedef volatile u32 ms02nv_uint; + +struct ms02nv_private { + struct mtd_info *next; + struct { + struct resource *module; + struct resource *diag_ram; + struct resource *user_ram; + struct resource *csr; + } resource; + u_char *addr; + size_t size; + u_char *uaddr; +}; From owner-linux-mips@oss.sgi.com Thu Mar 28 13:18:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SLIdO20960 for linux-mips-outgoing; Thu, 28 Mar 2002 13:18:39 -0800 Received: from oemcomputer ([218.66.143.210]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2SLHdq20945; Thu, 28 Mar 2002 13:17:40 -0800 Message-Id: <200203282117.g2SLHdq20945@oss.sgi.com> From: =?gb2312?q?=B3=C2=B9=FA=C7=BF_?= Reply-To: hungmin@21cn.com Subject: =?gb2312?q?=C5=E4=BC=FE=C5=FA=B7=A2=C9=CC?= Date: Fri, 29 Mar 2002 05:22:37 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8c6125db-31fa-427a-9d97-9c1fa326cda5" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format --8c6125db-31fa-427a-9d97-9c1fa326cda5 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable =CE=D2=CB=BE=F4=E9=CC=A8=CD=E5=F6=CE=B4=EF=C3=B3=D2=D7=B9=AB=CB=BE=D7=A4=CF=C3= =C3=C5=B0=EC=CA=C2=B4=A6=A3=AC=B3=A4=C6=DA=B4=D3=CA=C2=CF=C3=C3=C5=D3=EB=B8=DF= =D0=DB=B8=DB=D6=AE=BC=E4=B5=C4=D2=B5=CE=F1=CD=F9=C0=B4=A3=AC=C0=FB=D3=C3 =CE=D2=C3=C7=B5=C4=C7=FE=B5=C0=BA=CD=D4=AD=B3=A7=BD=F8=BB=F5=B5=C4=BC=DB=B8=F1= =D3=C5=CA=C6=A3=AC=D7=DF=CB=BD=D2=BB=D0=A9=B0=B2=B7=C0=A3=BA=C8=E7=C9=E3=CF=F1= =BB=FA=A3=BB=D3=B2=C5=CC=C2=BC=CF=F3=BB=FA=B5=C8=BA=CD=B5=E7=C4=D4=B2=FA=C6=B7= =BC=B0=CF=E0=B9=D8=C5=E4=BC=FE=A3=AC=BD=F1=C4=EA=CE=D2=C3=C7=D2=AA=D4=DA=B9=F3= =B5=D8=C0=A9=D5=B9 =D2=B5 =CE=F1=A3=AC=D1=B0=D5=D2=D2=BB=BC=D2=D3=D0=CA=B5=C1=A6=B5=C4=BE=AD=CF=FA=B5=E3= =A3=AC=BE=DF=CC=E5=B2=D9=D7=F7=B7=BD=B0=B8=C8=E7=CF=C2=A3=BA1=C2=F2=B6=CF=A3= =AC=CE=D2=B7=BD=B0=B4=B9=F3=B7=BD=CB=F9=CC=E1=B9=A9=C7=E5=B5=A5=B9=A9=D3=A6=C9= =CC=C6=B7 =A3=AC=B2=A2=B8=BA=D4=F0=D6=CA=B1=A3=D2=BB=C4=EA=A3=AC=B9=F3=B7=BD=B1=D8=D0=EB= =D6=A7=B8=B6=CF=E0=D3=A6=B5=C4=D7=CA=BD=F0=A3=AC=CA=D7=B4=CE=BF=C9=C1=F410%=CE= =AA=D6=CA=B1=A3=BD=F0=A3=AC=B2=A2=D0=E8=B5=BD=CE=D2=CB=BE=C7=A9=B6=A9=D3=D0=B9= =D8 =B5=C4=CF=FA=CA=DB=BA=CF=CD=AC=A1=A32=A3=AC=C8=E7=D0=E8=D1=F9=C6=B7=A3=AC=D4= =DA=B9=F3=B7=BD=B2=BB=C4=DC=C5=C9=C8=CB=C7=B0=C0=B4=B5=C4=C7=E9=BF=F6=CF=C2=A3= =AC=B8=F9=BE=DD=BF=CD=BB=A7=D2=AA=C7=F3=A3=AC=BF=C9=CA=D3=C7=E9 =BF=F6=A3=AC=CF=C8=B8=B640%=A1=AA80%=B5=C4=B6=A8=BD=F0=A3=AC=CE=D2=B7=BD=B2=C9= =D3=C3=BA=BD=BF=D5=BF=EC=B5=DD=B5=C4=B7=BD=B7=A8=D3=CA=BC=C4=A3=AC=D3=CA=BC=C4= =D1=F9=C6=B7=BD=F0=B6=EE=D7=EE=B8=DF5=CD=F2=D4=AA=D2=D4=C4=DA=A1=A3 3=A3=AC=B4=FA=C0=ED=A3=BA=B3=FD=C1=CB=D2=AA=B5=BD=CE=D2=CB=BE=C7=A9=B6=A9=B4= =FA=C0=ED=BA=CF=D4=BC=A3=AC=C3=BF=D4=C2=D7=EE=B5=CD=CF=FA=CA=DB=BD=F0=B6=EE=B2= =BB=C4=DC=B5=CD=D3=DA50=CD=F2=D4=AA=A3=AC=C9=CF=B2=BB=B7=E2=B6=A5=A3=AC=B2=A2= =CC=E1 =B9=A930%=D7=F7=CE=AA=B1=A3=D6=A4=BD=F0=A3=AC=C8=F4=B4=FA=C0=ED=B2=FA=C6=B7=B3= =AC=B3=F650=CD=F2=D4=AA=A3=AC=D4=F2=B0=B4=CA=B5=BC=CA=BD=F0=B6=EE=B5=C430%=D7= =F7=CE=AA=B1=A3=D6=A4=BD=F0=A3=AC=BB=F5=BF=EE=C3=BF=D4=C2=BD=E1=CB=E3 =D2=BB =B4=CE=A3=AC=B1=A3=D6=A4=BD=F0=B3=A4=C6=DA=D1=BA=D4=DA=CE=D2=CB=BE=A3=AC=C8=E7= =B4=FA=C0=ED=BA=CF=CD=AC=C6=DA=C2=FA=A3=AC=B1=A3=D6=A4=BD=F0=D3=EB=CE=B4=BD=E1= =CB=E3=BB=F5=BF=EE=CF=E0=BF=DB=A3=AC=B6=E0=CD=CB=C9=D9=B2=B9=A1=A3=BA=CD=CE=D2= =CB=BE =BA=CF =D7=F7=C0=FB=C8=F3=B9=B2=CF=ED=A3=AC=B7=E7=CF=D5=B9=B2=B5=A3=A3=AC=C8=E7=D3=D0= =D2=E2=BA=CF=D7=F7=A3=AC=BE=DF=CC=E5=B2=D9=D7=F7=B7=BD=B0=B8=C7=EB=BA=CD=CE=D2= =CB=BE=B3=C2=B9=FA=C7=BF=BE=AD=C0=ED =C1=AA=CF=B5=A3=AC=B5=E7=BB=B0=A3=BA05953117594=A3=AC013850735096 =C1=ED=B8=BD=D2=BB=B7=DD=BC=DB=B8=F1=B1=ED=B9=A9=B2=CE=D4=C4=A3=A825=CC=EC=CE= =AA=D2=BB=B1=A8=BC=DB=A3=A9 =F6=CE=B4=EF=B9=AB=CB=BE=D0=C5=CF=A2=BF=C6 =CD=B6 =D3=B0 =BB=FA =B1=A8 =BC=DB =B1=ED=A3=A8=C8=FD=C1=E2=A3=A9 =D0=F2=BA=C5 =D0=CD =BA=C5 =C3=FB =B3=C6 =BC=B0 =B9=E6 =B8=F1 =B5=A5 =BC=DB 1 LVP-SA51U 1200ANSI 800=A1=C1600 =CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3 9700.00=D4=AA 2 LVP-S50UX 1200ANSI 800=A1=C1600 =CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3 10000.00=D4=AA 3 LVP-XD200U 2000ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 21500.00=D4=AA 4 LVP-SL1U 1200ANSI 800=A1=C1600 =CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 12000.00=D4=AA 5 LVP-XL1U 1200ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 14000.00=D4=AA 6 LVP-S290U 1800ANSI 800=A1=C1600 =CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 12500.00=D4=AA 7 LVP-X70BU 1300ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 12000.00=D4=AA 8 LVP-X80U 1800ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 15000.00=D4=AA 9 LVP-X400BU 3200ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 27000.00=D4=AA 10 LVP-S490U 2600ANSI 800=A1=C1600=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 19000.00=D4=AA 11 LVP-X490U 2600ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 22000.00=D4=AA 12 LVP-X500BU 3700ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 38000.00=D4=AA =C3=C0=B9=FA =B2=A8=CC=D8=A3=A8BOTER=A3=A9=B2=FA=C6=B7=B1=A8=BC=DB=B5=A5 =D0=F2=BA=C5 =D0=CD=BA=C5 =B9=E6 =B8=F1 =B5=A5=BC=DB =B2=CA=C9=AB=C9=E3=CF=F1=BB=FA 1 BTC-220 1/3=A1=E5420=CF=DF0.3LuxF1.2=B3=AC=B1=B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA= =C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC DC12V/AC24V 1100.00=D4=AA 2 BTC-222 1/3=A1=E5480=CF=DF0.3LuxF1.2=B3=AC=B1=B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA= =C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC DC12V/AC24V 1700.00=D4=AA 3 BTC-230 1/3=A1=E5420=CF=DF0.1LuxF1.2=B3=AC=B1=B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA= =C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=ACY/C=D0=C5=BA=C5=CA=E4=B3=F6 = 85~265VAC DC12V/AC24V 1280.00=D4=AA 4 BTC-232 1/3=A1=E5480=CF=DF0.1LuxF1.2=B3=AC=B1=B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA= =C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=ACY/C=D0=C5=BA=C5=CA=E4=B3=F6 = 85~265VAC DC12V/AC24V 2050.00=D4=AA 5 BTC-250 1/3=A1=E5420=CF=DF0.05LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9=E2= =B2=B9=B3=A5=B9=A6=C4=DC=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=ACY/C=D0= =C5=BA=C5=CA=E4=B3=F6 =B4=F8VD=CD=E2=CD=AC=B2=BD=BD=D3=BF=DA 85~265VAC = DC12V/AC24V 1640.00=D4=AA 6 BTC-252 1/3=A1=E5480=CF=DF0.05LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9=E2= =B2=B9=B3=A5=B9=A6=C4=DC=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=ACY/C=D0= =C5=BA=C5=CA=E4=B3=F6 =B4=F8VD=CD=E2=CD=AC=B2=BD=BD=D3=BF=DA 85~265VAC = DC12V/AC24V 1960.00=D4=AA 7 BTC-270/IR 1/3=A1=E5420=CF=DF0~0.01LuxF1.2=B3=AC=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1= =B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6= =ACY/C=D0=C5=BA=C5=CA=E4=B3=F6 =B4=F8VD=CD=E2=CD=AC=B2=BD=BD=D3=BF=DA = 85~265VAC DC12V/AC24V 3000.00=D4=AA 8 BTC-272/IR 1/3=A1=E5480=CF=DF0~0.01LuxF1.2=B3=AC=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1= =B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6= =ACY/C=D0=C5=BA=C5=CA=E4=B3=F6 =B4=F8VD=CD=E2=CD=AC=B2=BD=BD=D3=BF=DA = 85~265VAC DC12V/AC24V 3100.00=D4=AA =BA=DA=B0=D7=C9=E3=CF=F1=BB=FA 1 BTC-130 1/3=A1=E5420=CF=DF0~0.01LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9= =E2=B2=B9=B3=A5=BA=DA=B0=D7=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC = DC12V/AC24V 700.00=D4=AA 2 BTC-132 1/3=A1=E5570=CF=DF0~0.01LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9= =E2=B2=B9=B3=A5=BA=DA=B0=D7=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC = DC12V/AC24V 1020.00=D4=AA 3 BTC-150 1/3=A1=E5420=CF=DF0~0.001LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9= =E2=B2=B9=B3=A5=BA=DA=B0=D7=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC = DC12V/AC24V 1050.00=D4=AA 4 BTC-152 1/3=A1=E5570=CF=DF0~0.001LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9= =E2=B2=B9=B3=A5=BA=DA=B0=D7=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC = DC12V/AC24V 1800.00=D4=AA =B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA 1 BTD-420CP 1/3=A1=E5420=CF=DF0.3LuxF1.2=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA SONY=D0= =BE=C6=ACDC12V/AC24V 800.00=D4=AA 2 BTD-422CP 1/3=A1=E5480=CF=DF0.3LuxF1.2=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA SONY=D0= =BE=C6=ACDC12V/AC24V 1200.00=D4=AA 3 BTD-440CP 1/3=A1=E5420=CF=DF0.05LuxF1.2=B5=CD=D5=D5=B6=C8=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3= =CF=F1=BB=FA SONY=D0=BE=C6=ACDC12V/AC24V 1000.00=D4=AA 4 BTD-442CP 1/3=A1=E5480=CF=DF0.05LuxF1.2=B5=CD=D5=D5=B6=C8=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3= =CF=F1=BB=FA SONY=D0=BE=C6=ACDC12V/AC24V 1570.00=D4=AA =BA=DA=B0=D7=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA 1 BTD-410BP 1/3=A1=E5420=CF=DF0.1LuxF1.2=BA=DA=B0=D7=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA SONY=D0= =BE=C6=ACDC12V/AC24V 500.00=D4=AA 2 BTD-412BP 1/3=A1=E5570=CF=DF0.1LuxF1.2=BA=DA=B0=D7=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA SONY=D0= =BE=C6=ACDC12V/AC24V 700.00=D4=AA 3 BTD-430BP 1/3=A1=E5420=CF=DF0.05LuxF1.2=BA=DA=B0=D7=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1= =BB=FA SONY=D0=BE=C6=ACDC12V/AC24V 598.00=D4=AA 4 BTD-432BP 1/3=A1=E5570=CF=DF0.05LuxF1.2=BA=DA=B0=D7=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1= =BB=FA SONY=D0=BE=C6=ACDC12V/AC24V 1090.00=D4=AA =B2=CA=C9=AB=BC=E0=CA=D3=C6=F7 1 BTM-140A 14=A1=E5450=CF=DF=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3=C6=F7 1700.00=D4=AA 2 BTM-142A 14=A1=E5600=CF=DF4=C2=B7=D2=F4=CA=D3=C6=B5=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3= =C6=F7 2200.00=D4=AA 3 BTM-142B 14=A1=E5720=CF=DF=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3=C6=F7 S-Video=D0=C5=BA= =C5=CA=E4=C8=EB 3000.00=D4=AA 4 BTM-210A 21=A1=E5450=CF=DF=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3=C6=F7 3400.00=D4=AA 5 BTM-212A 21=A1=E5600=CF=DF=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3=C6=F7 S-Video=D0=C5=BA= =C5=CA=E4=C8=EB 4100.00=D4=AA =C7=B6=C8=EB=CA=BD=D3=B2=C5=CC=C2=BC=CF=F1=BB=FA 1 BTV-410 4=C2=B7=D2=F4=CA=D3=C6=B5=CD=AC=B2=BD=C7=B6=C8=EB=CA=BD=D3=B2=C5=CC=C2=BC=CF= =F1=BB=FA =D3=A2=CE=C4=B2=CB=B5=A5=C4=DA=D6=C340GB=D3=B2=C5=CC =B4=F8=D2=A3=BF= =D8=C6=F7 36000.00=D4=AA 2 BTV-420 4=C2=B7=CA=D3=C6=B5=CA=E4=C8=EB=C7=B6=C8=EB=CA=BD=D3=B2=C5=CC=C2=BC=CF=F1=BB= =FA =D3=A2=CE=C4=B2=CB=B5=A5=C4=DA=D6=C330GB=D3=B2=C5=CC 20000.00=D4=AA 3 BTV-1600 16=C2=B7=CA=D3=C6=B5=CA=E4=C8=EB=C7=B6=C8=EB=CA=BD=D3=B2=C5=CC=C2=BC=CF=F1=BB= =FA =D3=A2=CE=C4=B2=CB=B5=A5=C4=DA=D6=C345GB=D3=B2=C5=CC 41000.00=D4=AA =CD=BC=CF=F1=CD=F8=C2=E7=B7=FE=CE=F1=C6=F7 1 BTN-4100 4=C2=B7=CA=D3=C6=B5=CA=E4=C8=EB =B4=AB=CA=E4=CB=D9=C2=CA=BF=C9=B4=EF25=D6=A1= /=C3=EB =D4=B6=B3=CC=BF=D8=D6=C6=D4=C6=CC=A8=BE=B5=CD=B7 8000.00=D4=AA =B3=A4=CA=B1=BC=E4=C2=BC=CF=F1=BB=FA 1 AG-TL350 24=D0=A1=CA=B1=B3=A4=CA=B1=BC=E4=C2=BC=CF=F1=BB=FA 3500.00=D4=AA 2 HS-1024E(H) 24=D0=A1=CA=B1=B3=A4=CA=B1=BC=E4=C2=BC=CF=F1=BB=FA 3300.00=D4=AA =D6=B8=CE=C6=BF=BC=C7=DA=BB=FA 1 FDA-01 =B5=A5=BB=FA=D0=CD=D6=B8=CE=C6=BF=BC=C7=DA=BB=FA(720=C3=B6/=CC=A8) 7000.00=D4=AA =BB=AD=C3=E6=B7=D6=B8=EE=C6=F7 1 SLT-401 =CB=C4=C2=B7=B2=CA=C9=AB=BB=AD=D6=D0=BB=AD=B7=D6=B8=EE=C6=F7 =B4=F8=B6=FE=A1= =A2=C8=FD=A1=A2=CB=C4=B7=D6=B8=EE =B4=F8=BB=D8=B7=C5(=CB=AB=B9=A6) 2200.00=D4=AA 2 SLT-4D =CB=C4=C2=B7=BA=DA=B0=D7=BB=AD=D6=D0=BB=AD=B7=D6=B8=EE=C6=F7 =B4=F8=BB=D8=B7= =C5(=CB=AB=B9=A6) 700.00=D4=AA 3 MV-96e 16=C2=B7=BB=AD=C3=E6=B4=A6=C0=ED=C6=F7(ROBOT) 2400.00=D4=AA =BA=AB=B9=FA=C8=FD=D0=C7=BA=BD=BF=D5=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA=A3=BA SDZ-160R/L 1/4=A1=B1=BF=ED=B6=AF=CC=AC=BA=CD=B3=AC=BC=B6=B1=B3=B9=E2=B2=B9=B3= =A516XCCD=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA 1500=D4=AA SDC-250PA 1/3=A1=B1=A3=A8=CD=AC=C9=CF=A3=A9 = 1050=D4=AA SDC-450PA1/3=A1=B1=A3=A8=CD=AC=C9=CF=A3=A9 = 1450=D4=AA SPD-16001/4=A1=B1=B4=F8=D4=C6=CC=A8=B5=C4=BF=ED=B6=AF=CC=AC=BA=CD=B3=AC=BC=B6= =B1=B3=B9=E2=B2=B9=B3=A5=B2=CA=C9=AB=C7=F2=D0=CE=C9=E3=CF=F1=BB=FA 6500=D4=AA= =BA=AB=B9=FA=CA=FD=D7=D6=D3=B2=C5=CC=B2=CA=C9=AB=C2=BC=CF=F3=CF=B5=CD=B3 SVR-400 4=C2=B7=C2=BC=CF=F3=BB=FA=A3=A8=B4=F845G=D3=B2=C5=CC=A3=A9 = 10500=D4=AA SVR-1600 16=C2=B7=C2=BC=CF=F3=BB=FA=A3=A8=B4=F8=CD=B745G=D3=B2=C5=CC=A3=A9 = 19500=D4=AA =B5=E7=C4=D4=C5=E4=BC=FE=A3=BA=BB=AA=CB=B6=A3=A8=D6=F7=B0=E5=A3=A9 TUSL2-C/WOA 815EP-B=D0=BE=C6=AC/ATA100/AGP4X/=D6=A7=B3=D6.13P=A2=F3(Tualatin) = 400 =D4=AA TUSL2-M/SWA(=D0=A1=B0=E5) 815EP-B=D0=BE=C6=AC/ATA100/AGP4X/=BA=ACI752=CF=D4=BF= =A8/AC97=C9=F9=BF=A8/=D6=A7=B3=D6(Tualatin)470 =D4=AA TUEP2-M/SWA 815EP=D0=BE=C6=AC/ATA100/AGP4X/=CE=DE=CF=D4=BF=A8/AC97=C9=F9=BF=A8= 350 =D4=AA P4T-F/PA Intel 850=D0=BE=C6=AC/Socket423/AGP4X/4=CC=F5RDRAM/AC97=C9=F9=BF=A8 = 700 =D4=AA P4T-F Intel 850=D0=BE=C6=AC/Socket423 P4/AGP4X/4=CC=F5RDRAM/=CE=DE=C9=F9=BF=A8= 550 =D4=AA A7V266 VIA KT266=D0=BE=C6=AC=D7=E9/=D6=A7=B3=D6UDMA100=A3=ACAGP 4X/=D6=A7=B3= =D6200.266FSB=C0=D7=C4=F1=D7=EA=C1=FASOCKET 462/ATX=BD=E1=B9=B9 460 =D4=AA A7VL-VM KL133=D0=BE=C6=AC/ATA100/SVAGAE4=CF=D4=BF=A8/AC97=C9=F9=BF=A8 240 =D4= =AA TUV4X/PA VIA 694T=D0=BE=C6=AC/ATA100/AGP4X/=BA=AC8738=D3=B2=C9=F9=BF=A8/=D6=A7= =B3=D6Tualatin 300 =D4=AA TUV4X/WOA VIA 694T=D0=BE=C6=AC/ATA100/AGP4X/=D6=A7=B3=D6Tualatin/=CE=DE=C9=F9= =BF=A8 360 =D4=AA CUVL-VM PL133=D0=BE=C6=AC/ATA100/SAVAGAE4=CF=D4=BF=A8/AC97=C9=F9=BF=A8 300 =D4= =AA CUSI-M/LAN SIS 630E=D0=BE=C6=AC/ATA66/=B4=F8SIS300=CF=D4=BF=A8/SIS900=CD=F8=BF= =A8/8378=D3=B2=C9=F9=BF=A8 330 =D4=AA P4S333 SIS645/DDR/CMI8738 6-CH S4700 =D4=AA P4B266-M/SWALAN 845D/DDR/S478/AC97630 =D4=AA =CE=A2=D0=C7 MS-6532 Intel850/400MHz=D7=DC=CF=DF/423=BD=E1=B9=B9/=D6=A7=B3=D6P4 2G=CB=AB=CD= =A8=B5=C0/4=CC=F5RAMBUS=C4=DA=B4=E6/AC97=C9=F9=BF=A8/4=CC=F5PCI/1=CC=F5= AGP/4=B8=F6USB=BD=D3=BF=DA/1=B8=F6CNR 500 =D4=AA 850 Pro5 Intel850/400MHz=D7=DC=CF=DF/P4 478=BD=E1=B9=B9/4=CC=F5RAMBUS=C4=DA=B4= =E6/8378=C9=F9=BF=A8/AGP4X/2X 600 =D4=AA MS-6529 Intel845/400MHz=D7=DC=CF=DF/P4 423=BD=E1=B9=B9/3=CC=F5SDRAM=C4=DA=B4= =E6/AC97=C9=F9=BF=A8/5=CC=F5PCI/1=CC=F5AGP/4=B8=F6USB=BD=D3=BF=DA/1=B8=F6CNR = 420 =D4=AA MS-6528 Intel845/P4 478=BD=E1=B9=B9/SDRAM=C4=DA=B4=E6/8738=C9=F9=BF=A8/6=CC=F5= PCI/1=CC=F5AGP/4=B8=F6USB=BD=D3=BF=DA/1=B8=F6CNR 600 =D4=AA Pro266 Plus VIA266/100/133/Socket 370/3=CC=F5DDR=C4=DA=B4=E6/=D6=A7=B3=D6= PCT2PC/AC97=C9=F9=BF=A8/ATA100/6=CC=F5PCI/1=CC=F5AGP 260 =D4=AA MS-6337-50B Intel 815EP/=D6=A7=B3=D6P=A2=F3=A1=A2=C8=FC=D1=EF=CF=B5=C1=D0/=D6= =A7=B3=D6133MHzCPU/PC133=C4=DA=B4=E6/Socket 370/ATA100/AC97=C9=F9=BF=A8/6=CC= =F5PCI/1=CC=F5AGP/ATX=BD=E1=B9=B9 300 =D4=AA MS-6337-50B-Raid Intel 815EP/ATX=BD=E1=B9=B9/Socket 370=BD=D3=BF=DA/133CPU=CD= =E2=C6=B5/ATA100/AC97=C9=F9=BF=A8/=D6=A7=B3=D6PC2PC=CD=F8=C2=E7=B9=A6=C4=DC= /6=CC=F5PCI/1=CC=F5AGP/=B4=F8=B4=C5=C5=CC=D5=F3=C1=D0 400 =D4=AA MS-6315EP Intel 815EP/ATX=BD=E1=B9=B9/Socket 370/AC97=C9=F9=BF=A8/3=CC=F5= PCI/1=CC=F5AGP 290 =D4=AA MS-6315E Intel 815/ATX=BD=E1=B9=B9/Socket 370/AC97=C9=F9=BF=A8/3=CC=F5PCI/1=CC= =F5AGP/1=CC=F5CNR 370 =D4=AA MS-6337 Intel 815E B-Step/ATX=BD=E1=B9=B9/Socket 370/ATA100/AC97=C9=F9=BF=A8= /=D6=A7=B3=D6PC2PC=CD=F8=C2=E7=B9=A6=C4=DC/6=CC=F5PCI/1=CC=F5AGP/4=CC=F5=C4=DA= =B4=E6=B2=DB 400 =D4=AA 6368 VIA PLE133/ATX=BD=E1=B9=B9/Socket 370/ATA100/AC97=C9=F9=BF=A8/=B4=F8= 9880=CF=D4=BF=A8 180 =D4=AA 6368 VIA PLE133/ATX=BD=E1=B9=B9/Socket 370/ATA100/AC97=C9=F9=BF=A8/=B4=F8= 9880=CF=D4=BF=A8/=B4=F88139C=CD=F8=BF=A8 200 =D4=AA 694T Pro VIA 694T/686B/ATX=BD=E1=B9=B9/Socket370/=D6=A7=B3=D6P=A2=F3=BC=B0=C8= =FC=D1=EFCPU/AC97=C9=F9=BF=A8/1=CC=F5AGP/5=CC=F5PCI/1=CC=F5AMR 300 =D4=AA 6330 VIA KT133/ATX 200MHz=D7=DC=CF=DF/=D5=EC=B4=ED=B5=C6/=CB=CD=D7=D4=B6=AF=B3= =AC=C6=B5=C8=ED=BC=FE/1=CC=F5AGP/6=CC=F5PCI/=B2=BB=D6=A7=B3=D6Athlon XP 200 = =D4=AA K7T Turbo-NL VIA KT133A/266MHz=D7=DC=CF=DF/AC97=C9=F9=BF=A8/=D7=D4=B6=AF=C9=CF= =CD=F8=CB=A2=D0=C2BIOS/1=CC=F5AGP/5=CC=F5PCI/1=CC=F5CNR/ATX/=B2=BB=D6=A7=B3=D6= Athlon XP 290 =D4=AA K7T Turbo-R Limited VIA KT133A/266MHz=D7=DC=CF=DF/AC97=C9=F9=BF=A8/=D7=D4=B6= =AF=C9=CF=CD=F8=CB=A2=D0=C2BIOS/1=CC=F5AGP/6=CC=F5PCI/1=CC=F5CNR/ATX/=B2=BB=D6= =A7=B3=D6Athlon XP/=CF=DE=C1=BF=B7=A2=D0=D0=BA=EC=C4=A7=B0=E5/=D6=A7=B3=D6= PC2PC=CD=F8=C2=E7=B9=A6=C4=DC/=B4=F8=B4=C5=C5=CC=D5=F3=C1=D0 300=D4=AA Intel =A3=A8=D6=D0=D1=EB=B4=A6=C0=ED=C6=F7=A3=A9 =B1=BC=CC=DA4 2.2G Socket 478/512KB/400MHz /=BA=D0=D7=B0 3500 =D4=AA =B1=BC=CC=DA4 2.0A Socket 478/512KB/400MHz /=BA=D0=D7=B0 2000 =D4=AA =B1=BC=CC=DA4 2.0G Socket 478/256KB/400MHz /=BA=D0=D7=B0 2000 =D4=AA =B1=BC=CC=DA4 1.9G Socket 478/256KB/400MHz /=BA=D0=D7=B0 1050 =D4=AA =B1=BC=CC=DA4 1.8A Socket 478/512KB/400MHz /=BA=D0=D7=B0 900 =D4=AA =B1=BC=CC=DA4 1.7G Socket 478/256KB/400MHz /=BA=D0=D7=B0 750 =D4=AA =B1=BC=CC=DA4 1.6A Socket 478/512KB/400MHz /=BA=D0=D7=B0 700 =D4=AA =B1=BC=CC=DA4 1.5G Socket 478/256KB/400MHz /=BA=D0=D7=B0 590 =D4=AA =B1=BC=CC=DA=A2=F3 1G Socket 370/256K/133=D5=D7/=BA=D0=D7=B0 570=D4=AA =B1=BC=CC=DA=A2=F3 933 Socket 370/256K/133=D5=D7/=BA=D0=D7=B0 520 =D4=AA =C8=FC=D1=EF=A2=F3 1.3G Socket 370/256KB/100MHz/=BA=D0=D7=B0 700 =D4=AA =C8=FC=D1=EF=A2=F3 1.2G Socket 370/256k/100=D5=D7/0.13=A6=CCm/=BA=D0=D7=B0 = 650=D4=AA =C8=FC=D1=EF=A2=F31000A Socket370/.13um/256K/100=D5=D7/=BA=D0=D7=B0 400 =D4=AA= =C8=FC=D1=EF=A2=F31000A Socket370/.13um/256K/100=D5=D7/=C9=A2=D7=B0 330 =D4=AA= =C8=FC=D1=EF=A2=F21000 Socket370/128K/100=D5=D7/=C9=A2=D7=B0 345 =D4=AA =C8=FC=D1=EF=A2=F2950 Socket370/128K/100=D5=D7/=C9=A2=D7=B0 300 =D4=AA =C8=FC=D1=EF=A2=F2900 Socket 370/128k/100=D5=D7/=BA=D0=D7=B0 240 =D4=AA =C8=FC=D1=EF=A2=F2 850 Socket 370/128k/100=D5=D7/=C9=A2=D7=B0250=D4=AA =C8=FC=D1=EF=A2=F2800 Socket370/128K/100=D5=D7/=C9=A2=D7=B0 270 =D4=AA =C8=FC=D1=EF=A2=F2 733 Socket 370/128K/66=D5=D7/=C9=A2=D7=B0 220 =D4=AA =C8=FC=D1=EF=A2=F2 667 Socket 370/128K/66=D5=D7/=C9=A2=D7=B0 200=D4=AA =C8=FC=D1=EF=A2=F2 633 Socket 370/128k/66=D5=D7/=C9=A2=D7=B0180=D4=AA =C8=FC=D1=EF=A2=F2 566 Socket 370/128K/66=D5=D7/=C9=A2=D7=B0 170=D4=AA =C4=DA=B4=E6=CC=F5 Hy 128M T-H/168PIN SDRAM/PC133(=CB=AB=C3=E6) 150 =D4=AA 128M T-H/168PIN SDRAM/PC133(=B5=A5=C3=E6) 150 =D4=AA 256M T-H/168PIN SDRAM/PC133 330 =D4=AA 128M DDR 184PIN DDR RAM/=D4=AD=B3=A7=C4=DA=B4=E6 160 =D4=AA 256M DDR 184PIN DDR RAM/=D4=AD=B3=A7=C4=DA=B4=E6 350 =D4=AA 512M T-S/168PIN SDRAM/PC133 520 =D4=AA Kingmax 128M 6ns/168PIN SDRAM/PC150 150 =D4=AA 256M 6ns/168PIN SDRAM/PC-150 340 =D4=AA 256M 6ns/168PIN SDRAM/PC150(2.0=B0=E6) 345=D4=AA 128MB 128MB DDR RAM/PC2700 190 =D4=AA 256MB 256MB DDR RAM/PC2700 380 =D4=AA IBM(=D3=B2=C5=CC=A3=A9 =CC=DA=C1=FA=C8=FD=B4=FA60GXP/40AV 40GB/ATA/100/2MB/7200rpm/IDE 430 =D4=AA =CC=DA=C1=FA=C8=FD=B4=FA60GXP/60AV 60GB/ATA/100/2MB/7200rpm/IDE 570 =D4=AA =CC=DA=C1=FA=CB=C4=B4=FA120GXP/40AVV 40GB/ATA/100/2MB/7200rpm/IDE 500 =D4=AA =CC=DA=C1=FA=CB=C4=B4=FA120GXP/80AVV 80GB/ATA/100/2MB/7200rpm/IDE 700 =D4=AA DMDM-10340 340M/128K/3600rpm/IBM =D0=A1=D3=B2=C5=CC/=CA=CA=D3=C3=D3=DA=BF=A8= =CE=F7=C5=B7=A1=A2=BF=C2=B4=EF=B5=C8=CA=FD=C2=EB=CF=E0=BB=FA/=BF=C9=D3=EB=B1= =CA=BC=C7=B1=BE=B5=E7=C4=D4=C1=AC=BD=D3 800 =D4=AA DMDM-11000 1G/128K/3600rpm/IBM =D0=A1=D3=B2=C5=CC/=CA=CA=D3=C3=D3=DA=BF=A8=CE= =F7=C5=B7=A1=A2=BF=C2=B4=EF=B5=C8=CA=FD=C2=EB=CF=E0=BB=FA/=BF=C9=D3=EB=B1=CA= =BC=C7=B1=BE=B5=E7=C4=D4=C1=AC=BD=D3 1500 =D4=AA =D7=EA=CA=AF =C3=C0=D7=EA=B6=FE=B4=FA/2B020H1 20GB/UDMA 100/5400rpm/2M/IDE 300 =D4=AA =D0=C7=D7=EA=B6=FE=B4=FA/4W060H4 60GB/UDMA 100/5400rpm/2M/IDE/=B5=A5=B5=FA= 30GB/ 600 =D4=AA =D0=C7=D7=EA=B6=FE=B4=FA/4W080H4 80GB/UDMA 100/5400rpm/2M/IDE/=B5=A5=B5=FA= 30GB/ 700=D4=AA =D0=C7=D7=EA=C8=FD=B4=FA/4D040H2 40GB/UDMA 100/5400rpm/2M/IDE/=B5=A5=B5=FA= 40GB 300 =D4=AA =BD=F0=D7=EA=C1=F9=B4=FA/AS20 20G/UDMA 100/2MB/7200rpm/IDE/3.5=B4=E7 310=D4=AA= =BD=F0=D7=EA=C1=F9=B4=FA/AS30 30G/UDMA 100/2MB/7200rpm/IDE/3.5=B4=E7 390=D4=AA= =BD=F0=D7=EA=C6=DF=B4=FA/6L020J/L1 20GB/UDMA 133/7200rpm/2M/IDE/=B5=A5=B5=FA= 40GB420=D4=AA =BD=F0=D7=EA=C6=DF=B4=FA/6L040J/L2 40GB/UDMA 133/7200rpm/2M/IDE/=B5=A5=B5=FA= 40GB 510=D4=AA =BD=F0=D7=EA=C6=DF=B4=FA/6L060J/L3 60GB/UDMA 133/7200rpm/2M/IDE/=B5=A5=B5=FA= 40GB600=D4=AA =B4=BF=C6=BD=CF=D4=CA=BE=C6=F7 =C8=FD=D0=C7 755DF 17=A1=B1800 450B 14=A1=B1500 550B 15=A1=B1620 750S 17=A1=B1 900 950P 19=A1=B1 1400 =B7=C9=C0=FB=C6=D1 105S 15=A1=B1320 105B 15=A1=B1 500 105G 15=A1=B1 580 107E 17=A1=B1 700 107T 17=A1=B1 900 107P 17=A1=B1 105 0 --8c6125db-31fa-427a-9d97-9c1fa326cda5-- From owner-linux-mips@oss.sgi.com Thu Mar 28 23:59:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2T7xIA03963 for linux-mips-outgoing; Thu, 28 Mar 2002 23:59:18 -0800 Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2T7xFq03960 for ; Thu, 28 Mar 2002 23:59:15 -0800 Received: from [80.141.104.82] (helo=there) by smtp.web.de with smtp (WEB.DE(Exim) 4.43 #48) id 16qrGh-0004Vu-00; Fri, 29 Mar 2002 08:57:51 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Harald Koerfgen Organization: none to speak of To: "Maciej W. Rozycki" Subject: Re: [patch] linux: declance multicast filter fixes Date: Fri, 29 Mar 2002 08:57:50 +0100 X-Mailer: KMail [version 1.3.2] Cc: Dave Airlie , Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thursday 28 March 2002 14:01, Maciej W. Rozycki wrote: > But the I/O ASIC chip is smart enough to merge data from the 8-bit ROM > device without problems and present four consecutive bytes as 32-bit > quantities to the host CPU. A simple 4 to 1 mapping is easy, even for the average hardware developer :-) > Why couldn't it do the same for the LANCE? > Host memory addresses are generated on behalf of the LANCE by the I/O ASIC > anyway. Probably because this would have made the IOASIC 0.0034 cents more expensive? > Of course not all designers have a clue, sigh... A brief study of > available documentation suggests no merging mode was implemented for the > LANCE and bit 0 of addresses generated is simply hardwired to 0. :-( That's my interpretation as well. Greetings, Harald From owner-linux-mips@oss.sgi.com Fri Mar 29 02:30:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TAUqv06280 for linux-mips-outgoing; Fri, 29 Mar 2002 02:30:52 -0800 Received: from bunny.shuttle.de (bunny.shuttle.de [193.174.247.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TAUOq06257; Fri, 29 Mar 2002 02:30:24 -0800 Received: by bunny.shuttle.de (Postfix, from userid 112) id 59B2E4E567; Fri, 29 Mar 2002 11:32:44 +0100 (CET) Date: Fri, 29 Mar 2002 11:32:44 +0100 To: linux-mips@oss.sgi.com Cc: devfs@oss.sgi.com Subject: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020329103244.GA15765@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.3.28i From: raoul@shuttle.de (Raoul Borenius) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'm not sure if this is a devfs or mips problem so I'm sending it to both lists. I just compiled my own mips-kernel from oss.sgi.com:/cvs to get devfs-support. Unfortunately there seems to be a problem with the serial-driver at least in the linux_2_4 branch: SGI Zilog8530 serial driver version 1.00 devfs_register(ttyS): could not append to parent, err: -17 devfs_register(cua): could not append to parent, err: -17 tty00 at 0xbfbd9830 (irq = 29) is a Zilog8530 tty01 at 0xbfbd9838 (irq = 29) is a Zilog8530 The result is that the directories /dev/tts and /dev/cua are missing. There are only the files /dev/ttS and /dev/cua which can be used to get access to the first serial port. I have attached the full dmesg output at the end. Regards Raoul --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dmesg ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R4600 FPU ICACHE DCACHE CPU revision is: 00002020 FPU revision is: 00002020 Primary instruction cache 16kb, linesize 32 bytes. Primary data cache 16kb, linesize 32 bytes. Linux version 2.4.18-cvs-mips-20020328 (root@testserv) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Thu Mar 28 21:59:35 CET 2002 MC: SGI memory controller Revision 3 Determined physical RAM map: memory: 00001000 @ 00000000 (reserved) memory: 00001000 @ 00001000 (reserved) memory: 0020d000 @ 08002000 (usable) memory: 0000d000 @ 0820f000 (reserved) memory: 00524000 @ 0821c000 (usable) memory: 000c0000 @ 08740000 (ROM data) memory: 09800000 @ 08800000 (usable) On node 0 totalpages: 73728 zone(0): 73728 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sda1 console=/dev/ttyS0 ro auto Calibrating system timer... 665000 [133.00 MHz CPU] NG1: Revision 6, 8 bitplanes, REX3 revision B, VC2 revision A, xmap9 revision A, cmap revision D, bt445 revision D NG1: Screensize 1024x768 Console: colour SGI Newport 128x48 zs0: console input Console: ttyS0 (Zilog8530), 9600 baud Calibrating delay loop... 132.71 BogoMIPS Memory: 156664k/163012k available (1370k kernel code, 6348k reserved, 164k data, 68k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) Checking for 'wait' instruction... available. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd VFS: Diskquotas version dquot_6.4.0 initialized Journalled Block Device driver loaded devfs: v1.10 (20020120) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 initialize_kbd: Keyboard reset failed, no ACK keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4) pty: 256 Unix98 ptys configured DS1286 Real Time Clock Driver v1.0 streamable misc devices registered (keyb:150, gfx:148) block: 128 slots per queue, batch=32 sgiseeq.c: David S. Miller (dm@engr.sgi.com) eth0: SGI Seeq8003 08:00:69:0b:17:50 SCSI subsystem driver Revision: 1.00 wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.25 - 09/Jul/1997, Compiled Mar 28 2002 at 22:18:11 scsi0 : SGI WD93 sending SDTR 0103013f0csync_xfer=2c Vendor: IBM Model: DORS-32160 Rev: WA6A Type: Direct-Access ANSI SCSI revision: 02 sending SDTR 0103013f0csync_xfer=2c Vendor: SGI Model: SEAGATE ST51080N Rev: 0950 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi disk sda at scsi0, channel 0, id 1, lun 0 Attached scsi disk sdb at scsi0, channel 0, id 2, lun 0 SCSI device sda: 4226725 512-byte hdwr sectors (2164 MB) Partition check: /dev/scsi/host0/bus0/target1/lun0: p1 p2 p3 p4 p5 SCSI device sdb: 2070235 512-byte hdwr sectors (1060 MB) /dev/scsi/host0/bus0/target2/lun0: p1 p2 p3 p4 SGI Zilog8530 serial driver version 1.00 devfs_register(ttyS): could not append to parent, err: -17 devfs_register(cua): could not append to parent, err: -17 tty00 at 0xbfbd9830 (irq = 29) is a Zilog8530 tty01 at 0xbfbd9838 (irq = 29) is a Zilog8530 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 32768 bind 32768) VFS: Mounted root (ext2 filesystem) readonly. Mounted devfs on /dev Freeing prom memory: 768kb freed Freeing unused kernel memory: 68k freed NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Adding Swap: 262176k swap-space (priority -1) --mYCpIKhGyMATD0i+-- From owner-linux-mips@oss.sgi.com Fri Mar 29 02:59:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TAxmL07131 for linux-mips-outgoing; Fri, 29 Mar 2002 02:59:48 -0800 Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TAxdq07117; Fri, 29 Mar 2002 02:59:39 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g2TB20X25723; Fri, 29 Mar 2002 12:02:00 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g2TB1wC17247; Fri, 29 Mar 2002 12:01:58 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 14:06:55 +0300 Received: from MW1G17C ([163.242.193.31]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H6D31HL1; Fri, 29 Mar 2002 14:06:53 +0300 From: Borsenkow Andrej To: "'Raoul Borenius'" , linux-mips@oss.sgi.com Cc: devfs@oss.sgi.com Subject: RE: broken devfs-support in SGI Zilog8530 serial driver Date: Fri, 29 Mar 2002 14:01:54 +0300 Message-ID: <000001c1d711$2492f070$1fc1f2a3@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20020329103244.GA15765@bunny.shuttle.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I'm not sure if this is a devfs or mips problem so I'm sending it > to both lists. > > I just compiled my own mips-kernel from oss.sgi.com:/cvs to get > devfs-support. Unfortunately there seems to be a problem with the > serial-driver at least in the linux_2_4 branch: > > SGI Zilog8530 serial driver version 1.00 > devfs_register(ttyS): could not append to parent, err: -17 This means that somebody else registered ttyS (and cua) before Zilog8530 driver attempted to do it. The possible reason could be that driver calls tty_register_devfs itself in this case it must set TTY_DRIVER_NO_DEVFS flag to prevent the same nodes registered by tty_register_driver. -andrej > devfs_register(cua): could not append to parent, err: -17 > tty00 at 0xbfbd9830 (irq = 29) is a Zilog8530 > tty01 at 0xbfbd9838 (irq = 29) is a Zilog8530 > > The result is that the directories /dev/tts and /dev/cua are missing. > > There are only the files /dev/ttS and /dev/cua which can be used to get > access to the first serial port. > > I have attached the full dmesg output at the end. > > Regards > > Raoul From owner-linux-mips@oss.sgi.com Fri Mar 29 05:27:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TDRL415944 for linux-mips-outgoing; Fri, 29 Mar 2002 05:27:21 -0800 Received: from bunny.shuttle.de (bunny.shuttle.de [193.174.247.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TDOSq15886; Fri, 29 Mar 2002 05:24:28 -0800 Received: by bunny.shuttle.de (Postfix, from userid 112) id 4C6264E567; Fri, 29 Mar 2002 14:26:50 +0100 (CET) Date: Fri, 29 Mar 2002 14:26:50 +0100 To: Borsenkow Andrej Cc: "'Raoul Borenius'" , linux-mips@oss.sgi.com, devfs@oss.sgi.com Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020329132650.GA16905@bunny.shuttle.de> References: <20020329103244.GA15765@bunny.shuttle.de> <000001c1d711$2492f070$1fc1f2a3@mow.siemens.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <000001c1d711$2492f070$1fc1f2a3@mow.siemens.ru> User-Agent: Mutt/1.3.28i From: raoul@shuttle.de (Raoul Borenius) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Andrej, On Fri, Mar 29, 2002 at 02:01:54PM +0300, Borsenkow Andrej wrote: > > I'm not sure if this is a devfs or mips problem so I'm sending it > > to both lists. > > > > I just compiled my own mips-kernel from oss.sgi.com:/cvs to get > > devfs-support. Unfortunately there seems to be a problem with the > > serial-driver at least in the linux_2_4 branch: > > > > SGI Zilog8530 serial driver version 1.00 > > devfs_register(ttyS): could not append to parent, err: -17 > > This means that somebody else registered ttyS (and cua) before Zilog8530 > driver attempted to do it. The possible reason could be that driver > calls tty_register_devfs itself in this case it must set > TTY_DRIVER_NO_DEVFS flag to prevent the same nodes registered by > tty_register_driver. Yeah, but I think the serial ports should be placed under /dev/tts/* and /dev/cua/*, shouldn't they? Which driver could have registered /dev/ttyS? if I search the kernel-sources under arch/mips I get testserv (raoul) ~/linux_2_4/linux/arch/mips> find . -name \*.c | xargs grep ttyS ./arc/arc_con.c: "ttyS", ./au1000/common/serial.c: printk("Testing ttyS%d (0x%04lx, 0x%04x)...\n", state->line, ./au1000/common/serial.c: serial_driver.name = "ttyS"; ./au1000/common/serial.c: printk(KERN_INFO "ttyS%02d%s at 0x%04lx (irq = %d) is a %s\n", ./au1000/common/serial.c: printk(KERN_INFO "ttyS%02d at %s 0x%04lx (irq = %d) is a %s\n", ./au1000/common/serial.c: name: "ttyS", ./au1000/pb1000/setup.c: strcat(argptr, " console=ttyS0,115200"); ./au1000/pb1500/setup.c: strcat(argptr, " console=ttyS0,115200"); ./baget/vacserial.c: serial_driver.name = "ttyS"; ./baget/vacserial.c: printk(KERN_INFO "ttyS%02d%s at 0x%04x (irq = %d) is a %s\n", ./baget/vacserial.c: name: "ttyS", ./baget/vacserial.c: autoconfig(info); /* autoconfigure ttyS0, whatever that is */ ./cobalt/setup.c:char arcs_cmdline[CL_SIZE] = { "console=ttyS0,115200 root=/dev/hda1" }; ./dec/promcon.c: name: "ttyS", ./galileo-boards/ev64120/promcon.c: "ttyS", ./galileo-boards/ev64120/setup.c:char arcs_cmdline[CL_SIZE] = { "console=ttyS0,115200 " ./galileo-boards/ev96100/setup.c: strcat(argptr, " console=ttyS0,115200"); ./ite-boards/generic/it8172_setup.c: strcat(argptr, " console=ttyS0,115200"); ./jmr3927/rbhma3100/setup.c: strcat(argptr, " console=ttyS1,115200"); ./kernel/gdb-stub.c: * (gdb) target remote /dev/ttyS1 ./mips-boards/atlas/atlas_setup.c: if ((argptr = strstr(argptr, "console=ttyS0")) == NULL) { ./mips-boards/atlas/atlas_setup.c: strcpy(serial_console, "ttyS0,"); ./mips-boards/atlas/atlas_setup.c: if ((argptr = strstr(argptr, "kgdb=ttyS")) != NULL) { ./mips-boards/atlas/atlas_setup.c: argptr += strlen("kgdb=ttyS"); ./mips-boards/atlas/atlas_setup.c: printk("KGDB: Uknown serial line /dev/ttyS%c, " ./mips-boards/atlas/atlas_setup.c: "falling back to /dev/ttyS1\n", *argptr); ./mips-boards/atlas/atlas_setup.c: printk("KGDB: Using serial line /dev/ttyS%d for session\n", ./mips-boards/atlas/atlas_setup.c: prom_printf("KGDB: Using serial line /dev/ttyS%d for session, " ./mips-boards/malta/malta_setup.c: strcat(argptr, " console=ttyS0,38400"); ./mips-boards/malta/malta_setup.c: if ((argptr = strstr(argptr, "kgdb=ttyS")) != NULL) { ./mips-boards/malta/malta_setup.c: argptr += strlen("kgdb=ttyS"); ./mips-boards/malta/malta_setup.c: printk("KGDB: Uknown serial line /dev/ttyS%c, " ./mips-boards/malta/malta_setup.c: "falling back to /dev/ttyS1\n", *argptr); ./mips-boards/malta/malta_setup.c: printk("KGDB: Using serial line /dev/ttyS%d for session\n", ./mips-boards/malta/malta_setup.c: prom_printf("KGDB: Using serial line /dev/ttyS%d for session, " ./philips/nino/prom.c: strcpy(arcs_cmdline, "console=tty0 console=ttyS0,115200"); ./sgi-ip22/ip22-setup.c: console_setup ("ttyS1"); ./sgi-ip22/ip22-setup.c: console_setup ("ttyS0"); ./sgi-ip22/ip22-setup.c: console_setup("ttyS0"); testserv (raoul) ~/linux_2_4/linux/arch/mips> but I have not compiled support for arc console (when do you need that btw?) and all other drivers do not apply to IP22 AFAIK. My .config is attached below. Regards Raoul --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="config-2.4.18-cvs-mips-20020328" # # Automatically generated make config: don't edit # CONFIG_MIPS=y CONFIG_MIPS32=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Machine selection # # CONFIG_ACER_PICA_61 is not set # CONFIG_ALGOR_P4032 is not set # CONFIG_BAGET_MIPS is not set # CONFIG_MIPS_COBALT is not set # CONFIG_DECSTATION is not set # CONFIG_DDB5074 is not set # CONFIG_MIPS_EV64120 is not set # CONFIG_MIPS_EV96100 is not set # CONFIG_MIPS_ATLAS is not set # CONFIG_MIPS_MALTA is not set # CONFIG_NINO is not set # CONFIG_SIBYTE_SB1250 is not set # CONFIG_MIPS_MAGNUM_4000 is not set # CONFIG_MOMENCO_OCELOT is not set # CONFIG_DDB5476 is not set # CONFIG_DDB5477 is not set # CONFIG_NEC_OSPREY is not set # CONFIG_OLIVETTI_M700 is not set CONFIG_SGI_IP22=y # CONFIG_SNI_RM200_PCI is not set # CONFIG_MIPS_ITE8172 is not set # CONFIG_MIPS_IVR is not set # CONFIG_MIPS_PB1000 is not set # CONFIG_MIPS_PB1500 is not set # CONFIG_TOSHIBA_JMR3927 is not set # CONFIG_HP_LASERJET is not set # CONFIG_HIGHMEM is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_MCA is not set # CONFIG_SBUS is not set CONFIG_ARC32=y CONFIG_BOARD_SCACHE=y CONFIG_IRQ_CPU=y CONFIG_PC_KEYB=y CONFIG_SGI=y CONFIG_NEW_IRQ=y CONFIG_NEW_TIME_C=y CONFIG_NONCOHERENT_IO=y # CONFIG_ISA is not set # CONFIG_EISA is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # CPU selection # # CONFIG_CPU_R3000 is not set # CONFIG_CPU_TX39XX is not set # CONFIG_CPU_R6000 is not set # CONFIG_CPU_VR41XX is not set # CONFIG_CPU_R4300 is not set CONFIG_CPU_R4X00=y # CONFIG_CPU_TX49XX is not set # CONFIG_CPU_R5000 is not set # CONFIG_CPU_R5432 is not set # CONFIG_CPU_RM7000 is not set # CONFIG_CPU_NEVADA is not set # CONFIG_CPU_R10000 is not set # CONFIG_CPU_SB1 is not set # CONFIG_CPU_MIPS32 is not set # CONFIG_CPU_MIPS64 is not set # CONFIG_64BIT_PHYS_ADDR is not set # CONFIG_CPU_ADVANCED is not set CONFIG_CPU_HAS_LLSC=y CONFIG_CPU_HAS_LLDSCD=y # CONFIG_CPU_HAS_WB is not set # # General setup # # CONFIG_CPU_LITTLE_ENDIAN is not set CONFIG_KCORE_ELF=y CONFIG_ELF_KERNEL=y # CONFIG_BINFMT_IRIX is not set CONFIG_FORWARD_KEYBOARD=y # CONFIG_ARC_CONSOLE is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_NET=y # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set # CONFIG_HOTPLUG_PCI is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m CONFIG_MD_MULTIPATH=m CONFIG_BLK_DEV_LVM=m # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=m # CONFIG_NETFILTER is not set CONFIG_FILTER=y CONFIG_UNIX=m CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y CONFIG_IPV6=m # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # SCSI support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=m # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_DEBUG_QUEUES is not set CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # CONFIG_SGIWD93_SCSI=y # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_DEBUG is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_NET_ISA is not set # CONFIG_NET_PCI is not set # CONFIG_NET_POCKET is not set CONFIG_SGISEEQ=y # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y # CONFIG_SERIAL is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # # Input core support is needed for gameports # # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # CONFIG_SOFT_WATCHDOG is not set # CONFIG_WDT is not set # CONFIG_WDTPCI is not set # CONFIG_PCWATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_I810_TCO is not set # CONFIG_MIXCOMWD is not set # CONFIG_60XX_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_MACHZ_WDT is not set CONFIG_INDYDOG=m # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # SGI Character devices # CONFIG_SGI_NEWPORT_CONSOLE=y CONFIG_FONT_8x16=y # # File systems # CONFIG_QUOTA=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set CONFIG_ZISOFS_FS=m CONFIG_ZLIB_FS_INFLATE=m # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # # CONFIG_VGA_CONSOLE is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # CONFIG_SOUND=m # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_MIDI_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_SONICVIBES is not set CONFIG_SOUND_HAL2=m # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_MIDI_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set # # SGI devices # CONFIG_SGI_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_SGI_DS1286=y # CONFIG_SGI_NEWPORT_GFX is not set # # USB support # # CONFIG_USB is not set # # USB Controllers # # CONFIG_USB_UHCI is not set # CONFIG_USB_UHCI_ALT is not set # CONFIG_USB_OHCI is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # USB Human Interface Devices (HID) # # # Input core support is needed for USB HID # # # USB Imaging devices # # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # # CONFIG_USB_PEGASUS is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_RIO500 is not set # # Input core support # # CONFIG_INPUT is not set # CONFIG_INPUT_KEYBDEV is not set # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # # Kernel hacking # # CONFIG_CROSSCOMPILE is not set # CONFIG_DEBUG is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_MIPS_UNCACHED is not set --envbJBWh7q8WU6mo-- From owner-linux-mips@oss.sgi.com Fri Mar 29 05:36:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TDaV216101 for linux-mips-outgoing; Fri, 29 Mar 2002 05:36:31 -0800 Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TDaPq16086; Fri, 29 Mar 2002 05:36:25 -0800 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id B187B92452; Sat, 30 Mar 2002 00:38:45 +1100 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 377B1237BB; Fri, 29 Mar 2002 14:38:36 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: raoul@shuttle.de (Raoul Borenius), Borsenkow Andrej Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Date: Fri, 29 Mar 2002 14:38:35 +0100 X-Mailer: KMail [version 1.3.2] Cc: "'Raoul Borenius'" , linux-mips@oss.sgi.com, devfs@oss.sgi.com References: <20020329103244.GA15765@bunny.shuttle.de> <000001c1d711$2492f070$1fc1f2a3@mow.siemens.ru> <20020329132650.GA16905@bunny.shuttle.de> In-Reply-To: <20020329132650.GA16905@bunny.shuttle.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020329133836.377B1237BB@lyta.coker.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk You need some code similar to the following in the serial driver: #ifdef CONFIG_DEVFS_FS serial_driver.name = "tts/%d"; #else serial_driver.name = "ttyS"; #endif Of course if the original device nodes were named /dev/ttyZ0 etc then you want "tts/Z%d". Look at the Cyclades and Stallion drivers for examples of it being done correctly. Or tell me exactly the details of what you want and I'll send you a patch. -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-linux-mips@oss.sgi.com Fri Mar 29 23:36:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2U7ajL08214 for linux-mips-outgoing; Fri, 29 Mar 2002 23:36:45 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2U7acv08202; Fri, 29 Mar 2002 23:36:38 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2U7Zx131264; Fri, 29 Mar 2002 23:35:59 -0800 Date: Fri, 29 Mar 2002 23:35:59 -0800 From: Ralf Baechle To: Raoul Borenius Cc: linux-mips@oss.sgi.com, devfs@oss.sgi.com Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020329233559.A31160@dea.linux-mips.net> References: <20020329103244.GA15765@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020329103244.GA15765@bunny.shuttle.de>; from raoul@shuttle.de on Fri, Mar 29, 2002 at 11:32:44AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Mar 29, 2002 at 11:32:44AM +0100, Raoul Borenius wrote: > I'm not sure if this is a devfs or mips problem so I'm sending it > to both lists. > > I just compiled my own mips-kernel from oss.sgi.com:/cvs to get > devfs-support. Unfortunately there seems to be a problem with the > serial-driver at least in the linux_2_4 branch: > > SGI Zilog8530 serial driver version 1.00 > devfs_register(ttyS): could not append to parent, err: -17 > devfs_register(cua): could not append to parent, err: -17 At this time we don't even claim to have proper devfs support in the Indy serial drivers ... Ralf From owner-linux-mips@oss.sgi.com Fri Mar 29 23:42:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2U7gfZ08342 for linux-mips-outgoing; Fri, 29 Mar 2002 23:42:41 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2U7gdv08339 for ; Fri, 29 Mar 2002 23:42:39 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2U7g0J31332; Fri, 29 Mar 2002 23:42:00 -0800 Date: Fri, 29 Mar 2002 23:42:00 -0800 From: Ralf Baechle To: "Gopakumar.C.E" Cc: linux-mips@oss.sgi.com Subject: Re: Documentation Message-ID: <20020329234200.B31160@dea.linux-mips.net> References: <0203222102032M.00789@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0203222102032M.00789@localhost>; from gopkumar@cisco.com on Fri, Mar 22, 2002 at 09:02:03PM +0530 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Mar 22, 2002 at 09:02:03PM +0530, Gopakumar.C.E wrote: > Is there any good documentation on how the Linux/Unix code is designed for > the MIPS processors ? (like how they handle paging, protection etc?) The whole VM code is largely generic code sprinkled with a few architecture specific bits all over include/asm-mips and arch/mips. The MIPS specific bits primarily deal with very low level details of memory managment (TLB, caches) which the actual paging stuff is in the mm/ directory. I've not document the MIPS-specific parts of memory managment very well (standard reason - so much work to do, so little time to do it ...) so feel free to ask me. The generic Linux memory managment is fairly well documented in various online resources or a variety of technical books from your favorite CS bookstore ... Ralf From owner-linux-mips@oss.sgi.com Fri Mar 29 23:54:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2U7s6h08503 for linux-mips-outgoing; Fri, 29 Mar 2002 23:54:06 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2U7s0v08499 for ; Fri, 29 Mar 2002 23:54:00 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2U7rL431434; Fri, 29 Mar 2002 23:53:21 -0800 Date: Fri, 29 Mar 2002 23:53:21 -0800 From: Ralf Baechle To: Muthukumar Ratty Cc: linux-mips@oss.sgi.com Subject: Re: Lost when execve-ing the init. Message-ID: <20020329235321.C31160@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from muthur@paul.rutgers.edu on Fri, Mar 22, 2002 at 11:48:18PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Mar 22, 2002 at 11:48:18PM -0500, Muthukumar Ratty wrote: (Mail answering day ...) > I was trying a kernel I made and found that I got lost after it goes to > execve("/sbin/init") in init/main.c. I can ping the board which means the > board is alive. This almost sounds like you don't get any output from the console? If so, check you configured your /dev/console right. It should be a char device, major device id 5, minor 1. I tried to trace it down but got stuck with the following > code in "include/asm-mips/unistd.h" [ I believe it implements > the execve function since in the same file I have ..... > static inline _syscall3(int,execve,const char *,file,char **,argv,char > **,envp)] Not really. The execve macro there does a syscall just like a user process would do it. > I guess... > After setting up the arguments its referencing (#defined ???) syscall. I > couldnt find the definition for "syscall". Could someone point me to the > right place (and help me get some sleep please ;). Also any idea about how > to debug this. (Can I set breakpoint in syscall3??). (Any idea why its not > going.. error in my irq setup??...) > PS : what does this funny thing mean??? > > : "=r" (__res), "=r" (__err) \ > : "i" (__NR_##name),"r" ((long)(a)), \ > "r" ((long)(b)), \ > "r" ((long)(c)) \ > : "$2","$4","$5","$6","$7","$8","$9","$10","$11","$12", > \ > "$13","$14","$15","$24"); \ > if (__err == 0) \ Don't ask :-) Since your did anyway - it means that this piece of inline assembler receives a integer constant argument as (__NR_#name) and three variables casted into longs (a, b, c) as arguments. The results will be returned into the variables __res and __err. Finally the "$2" etc. are the registers that will be destroyed by the inline code. That was just the quick version. The basic stuff about inline assembler is documented in the gcc info pages. All the nasty details are hidden somewhere in a a few million lines of gcc code ... Ralf From owner-linux-mips@oss.sgi.com Sat Mar 30 00:20:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2U8K7o08991 for linux-mips-outgoing; Sat, 30 Mar 2002 00:20:07 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g2U8K4v08988 for ; Sat, 30 Mar 2002 00:20:04 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2U8J1331741; Sat, 30 Mar 2002 00:19:01 -0800 Date: Sat, 30 Mar 2002 00:19:01 -0800 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: David Woodhouse , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4: DEC MS02-NV NVRAM module support Message-ID: <20020330001901.A31717@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Mar 28, 2002 at 02:26:55PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Mar 28, 2002 at 02:26:55PM +0100, Maciej W. Rozycki wrote: > The patch adds support for the DEC MS02-type lithium battery backed-up > NVRAM board. The board provides 1MB (architecturally up to 4MB) of fast > SRAM originally meant as a PrestoServe NFS accelerator for the MIPS-based > DECstations. > > The code works fine for me since its creation back in August. It was not > tested by anyone else -- after announcing the code at the "linux-mips" > list last year I've read from two volunteers but they did not come back > with results ever. > > I believe it's suitable for inclusion in the official kernel. The patch > applies both to 2.4.19-pre4 and to the current CVS tree at oss.sgi.com. Looks good, applied to 2.4 and 2.5. If you would have submitted this patch without prior testing in August I certainly would have approved it as well as it had not potencial to break things for other machines. Thanks, Ralf From owner-linux-mips@oss.sgi.com Sat Mar 30 05:30:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2UDU2V16155 for linux-mips-outgoing; Sat, 30 Mar 2002 05:30:02 -0800 Received: from bunny.shuttle.de (bunny.shuttle.de [193.174.247.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2UDTav16138; Sat, 30 Mar 2002 05:29:36 -0800 Received: by bunny.shuttle.de (Postfix, from userid 112) id 436994E567; Sat, 30 Mar 2002 14:28:56 +0100 (CET) Date: Sat, 30 Mar 2002 14:28:56 +0100 To: Ralf Baechle Cc: Raoul Borenius , linux-mips@oss.sgi.com, devfs@oss.sgi.com Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020330132856.GA24305@bunny.shuttle.de> References: <20020329103244.GA15765@bunny.shuttle.de> <20020329233559.A31160@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020329233559.A31160@dea.linux-mips.net> User-Agent: Mutt/1.3.28i From: raoul@shuttle.de (Raoul Borenius) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Ralf, On Fri, Mar 29, 2002 at 11:35:59PM -0800, Ralf Baechle wrote: > On Fri, Mar 29, 2002 at 11:32:44AM +0100, Raoul Borenius wrote: > > > I'm not sure if this is a devfs or mips problem so I'm sending it > > to both lists. > > > > I just compiled my own mips-kernel from oss.sgi.com:/cvs to get > > devfs-support. Unfortunately there seems to be a problem with the > > serial-driver at least in the linux_2_4 branch: > > > > SGI Zilog8530 serial driver version 1.00 > > devfs_register(ttyS): could not append to parent, err: -17 > > devfs_register(cua): could not append to parent, err: -17 > > At this time we don't even claim to have proper devfs support in the > Indy serial drivers ... But it would be nice to have ;-) Especially because you only need the small change pointed out by Russell Coker: --- sgiserial.c.orig Sat Mar 30 10:51:03 2002 +++ sgiserial.c Sat Mar 30 10:54:28 2002 @@ -1875,7 +1875,11 @@ memset(&serial_driver, 0, sizeof(struct tty_driver)); serial_driver.magic = TTY_DRIVER_MAGIC; +#ifdef CONFIG_DEVFS_FS + serial_driver.name = "tts/%d"; +#else serial_driver.name = "ttyS"; +#endif serial_driver.major = TTY_MAJOR; serial_driver.minor_start = 64; serial_driver.num = NUM_CHANNELS; @@ -1911,7 +1915,11 @@ * major number and the subtype code. */ callout_driver = serial_driver; +#ifdef CONFIG_DEVFS_FS + callout_driver.name = "cua/%d"; +#else callout_driver.name = "cua"; +#endif callout_driver.major = TTYAUX_MAJOR; callout_driver.subtype = SERIAL_TYPE_CALLOUT; It works for my Indy and I just love devfs. All other drivers used on my box also work fine with devfs (sound, watchdog, rtc etc.). Regards Raoul From owner-linux-mips@oss.sgi.com Sun Mar 31 07:01:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2VF1Ia03263 for linux-mips-outgoing; Sun, 31 Mar 2002 07:01:18 -0800 Received: from bunny.shuttle.de (bunny.shuttle.de [193.174.247.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2VF14v03238; Sun, 31 Mar 2002 07:01:04 -0800 Received: by bunny.shuttle.de (Postfix, from userid 112) id B90384E567; Sun, 31 Mar 2002 17:00:23 +0200 (CEST) Date: Sun, 31 Mar 2002 17:00:23 +0200 To: Ralf Baechle Cc: linux-mips@oss.sgi.com, devfs@oss.sgi.com Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020331150023.GA30224@bunny.shuttle.de> References: <20020329103244.GA15765@bunny.shuttle.de> <20020329233559.A31160@dea.linux-mips.net> <20020330132856.GA24305@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020330132856.GA24305@bunny.shuttle.de> User-Agent: Mutt/1.3.28i From: raoul@shuttle.de (Raoul Borenius) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Ralf, On Sat, Mar 30, 2002 at 02:28:56PM +0100, raoul wrote: > Especially because you only need the small change pointed out by > Russell Coker: > > --- sgiserial.c.orig Sat Mar 30 10:51:03 2002 > +++ sgiserial.c Sat Mar 30 10:54:28 2002 > @@ -1875,7 +1875,11 @@ > > memset(&serial_driver, 0, sizeof(struct tty_driver)); > serial_driver.magic = TTY_DRIVER_MAGIC; > +#ifdef CONFIG_DEVFS_FS > + serial_driver.name = "tts/%d"; > +#else > serial_driver.name = "ttyS"; > +#endif > serial_driver.major = TTY_MAJOR; > serial_driver.minor_start = 64; > serial_driver.num = NUM_CHANNELS; Thanks for including the changes fr the ttyS's. But it seems you forgot the callout-devices: > @@ -1911,7 +1915,11 @@ > * major number and the subtype code. > */ > callout_driver = serial_driver; > +#ifdef CONFIG_DEVFS_FS > + callout_driver.name = "cua/%d"; > +#else > callout_driver.name = "cua"; > +#endif > callout_driver.major = TTYAUX_MAJOR; > callout_driver.subtype = SERIAL_TYPE_CALLOUT; > Could you commit that too? Thanx Raoul From owner-linux-mips@oss.sgi.com Sun Mar 31 13:54:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2VLsxH11911 for linux-mips-outgoing; Sun, 31 Mar 2002 13:54:59 -0800 Received: from mailhost.uni-koblenz.de (root@mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2VLsqv11891; Sun, 31 Mar 2002 13:54:52 -0800 Received: from eddie (eddie.uni-koblenz.de [141.26.64.59]) by mailhost.uni-koblenz.de (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g2VLsBt03917; Sun, 31 Mar 2002 23:54:11 +0200 Received: from dea.linux-mips.net by eddie (SMI-8.6/KO-2.0) id XAA20174; Sun, 31 Mar 2002 23:54:10 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2UKIBt02122; Sat, 30 Mar 2002 12:18:11 -0800 Date: Sat, 30 Mar 2002 12:18:11 -0800 From: Ralf Baechle To: Raoul Borenius Cc: linux-mips@oss.sgi.com, devfs@oss.sgi.com Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020330121811.A2049@dea.linux-mips.net> References: <20020329103244.GA15765@bunny.shuttle.de> <20020329233559.A31160@dea.linux-mips.net> <20020330132856.GA24305@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020330132856.GA24305@bunny.shuttle.de>; from raoul@shuttle.de on Sat, Mar 30, 2002 at 02:28:56PM +0100 X-Accept-Language: de,en,fr X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Mar 30, 2002 at 02:28:56PM +0100, Raoul Borenius wrote: > > > I just compiled my own mips-kernel from oss.sgi.com:/cvs to get > > > devfs-support. Unfortunately there seems to be a problem with the > > > serial-driver at least in the linux_2_4 branch: > > > > > > SGI Zilog8530 serial driver version 1.00 > > > devfs_register(ttyS): could not append to parent, err: -17 > > > devfs_register(cua): could not append to parent, err: -17 > > > > At this time we don't even claim to have proper devfs support in the > > Indy serial drivers ... > > But it would be nice to have ;-) > > Especially because you only need the small change pointed out by > Russell Coker: Ok :-) Applied to 2.4 and 2.5. Ralf From owner-linux-mips@oss.sgi.com Sun Mar 31 14:16:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2VMGcE14773 for linux-mips-outgoing; Sun, 31 Mar 2002 14:16:38 -0800 Received: from mailhost.uni-koblenz.de (root@mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2VMGUv14743; Sun, 31 Mar 2002 14:16:30 -0800 Received: from eddie (eddie.uni-koblenz.de [141.26.64.59]) by mailhost.uni-koblenz.de (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g2VMFnt05948; Mon, 1 Apr 2002 00:15:49 +0200 Received: from dea.linux-mips.net by eddie (SMI-8.6/KO-2.0) id AAA20250; Mon, 1 Apr 2002 00:15:48 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g2VMFkK12765; Sun, 31 Mar 2002 14:15:46 -0800 Date: Sun, 31 Mar 2002 14:15:45 -0800 From: Ralf Baechle To: Raoul Borenius Cc: linux-mips@oss.sgi.com, devfs@oss.sgi.com Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020331141545.A12756@dea.linux-mips.net> References: <20020329103244.GA15765@bunny.shuttle.de> <20020329233559.A31160@dea.linux-mips.net> <20020330132856.GA24305@bunny.shuttle.de> <20020331150023.GA30224@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020331150023.GA30224@bunny.shuttle.de>; from raoul@shuttle.de on Sun, Mar 31, 2002 at 05:00:23PM +0200 X-Accept-Language: de,en,fr X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Mar 31, 2002 at 05:00:23PM +0200, Raoul Borenius wrote: > Thanks for including the changes fr the ttyS's. But it seems you forgot the > callout-devices: That's what you get for submitting patches that don't apply ;) Did you do cut'n'paste or similiar cruelties to that poor little patch? > > @@ -1911,7 +1915,11 @@ > > * major number and the subtype code. > > */ > > callout_driver = serial_driver; > > +#ifdef CONFIG_DEVFS_FS > > + callout_driver.name = "cua/%d"; > > +#else > > callout_driver.name = "cua"; > > +#endif > > callout_driver.major = TTYAUX_MAJOR; > > callout_driver.subtype = SERIAL_TYPE_CALLOUT; > > > > Could you commit that too? Sure. Ralf