From ravdberg@inter.NL.net Tue Sep  2 22:09:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Sep 2003 22:10:13 +0100 (BST)
Received: from altrade.nijmegen.internl.net ([IPv6:::ffff:217.149.192.18]:62949
	"EHLO altrade.nijmegen.internl.net") by linux-mips.org with ESMTP
	id <S8225193AbTIBVJl>; Tue, 2 Sep 2003 22:09:41 +0100
Received: from whale.dutch.mountain by altrade.nijmegen.internl.net
	via 1Cust209.tnt41.rtm1.nld.da.uu.net [213.117.0.209] with ESMTP for <linux-mips@linux-mips.org>
	id h82L9dFC027626 (8.12.9/2.04); Tue, 2 Sep 2003 23:09:39 +0200 (MET DST)
Received: from (locally authorised broken client using invalid hostname!) localhost (really [127.0.0.1]) by whale.dutch.mountain
	via in.smtpd with esmtp (ident ravdberg using rfc1413)
	id <m19uIGa-000HHJC@whale.dutch.mountain> (Debian Smail3.2.0.114)
	Tue, 2 Sep 2003 23:00:44 +0200 (CEST) 
Date: Tue, 2 Sep 2003 23:00:44 +0200 (CEST)
From: Richard van den Berg <ravdberg@inter.NL.net>
X-Sender: ravdberg@whale.dutch.mountain
To: linux-mips@linux-mips.org
Subject: hwclock error on DECstation 5000/133 with 2.4.22
Message-ID: <Pine.LNX.4.21.0309022258540.17245-100000@whale.dutch.mountain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ravdberg@inter.NL.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3119
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ravdberg@inter.NL.net
Precedence: bulk
X-list: linux-mips

Hello,

Kernel 2.4.17 (Debian kernel-source package) didn't give following error: 
fortuna:~# hwclock
hwclock: ioctl() to /dev/rtc to turn on update interrupts failed unexpectedly, errno=25: Inappropriate ioctl for device.
fortuna:~# hwclock -v
hwclock 2.4c/util-linux-2.11n
fortuna:~# uname -a
Linux fortuna 2.4.22 #1 Thu Aug 28 06:51:00 CEST 2003 mips unknown

2.4.22 checked out august 27th, system time gets set, don't know if above
message has other effects. With this kernel recognizes the LK401 keyboard,
2.4.17 gave id 186.

Regards,
Richard


From ralf@linux-mips.org Wed Sep  3 13:57:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Sep 2003 13:57:39 +0100 (BST)
Received: from p508B5EF1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.241]:9180
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225310AbTICM5h>; Wed, 3 Sep 2003 13:57:37 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h83CvZHE010878;
	Wed, 3 Sep 2003 14:57:36 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h83CvZbS010877;
	Wed, 3 Sep 2003 14:57:35 +0200
Date: Wed, 3 Sep 2003 14:57:34 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org,
	GNU libc hackers <libc-hacker@sources.redhat.com>,
	libc-alpha@sources.redhat.com
Subject: More sigevent ...
Message-ID: <20030903125734.GA9260@linux-mips.org>
References: <20030831145854.GB23189@linux-mips.org> <20030831161217.GA10286@linux-mips.org> <20030831164812.GB766@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030831164812.GB766@bogon.ms20.nix>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3120
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

Looking into the problem a bit deeper here's my analysis of the whole
missmatch of struct sigevent and the associated constants, including the
entire history.

 - Linux 2.1.72 introduces sigevent.  The definition used is the one taken
   from IRIX and different from what is used in other Linux ports.  But
   that doesn't matter because there are no in-kernel users.

   I don't know why the structure was defined at all in kernel headers at
   all by that time.  Maybe for the sake of libc 5?

 - Some of the >= libc 2.1 version circulating use the kernel definitions

 - Andreas Jaeger contributes sysdeps/unix/sysv/linux/mips/bits/siginfo.h
   for the FSF version of glibc 2.1.  Markedrd as "XXX This one might need
   to change!!!" this header file uses the same structure as other Linux
   architectures but uses the same SIGEV_* constants as the kernel.

 - Linux 2.5.63 introduces the POSIX.1b timer API which uses the kernel's
   definition of sigevent.  The userspace part of the POSIX.1b timer patch
   uses glibc's definition.  But the code assumes both definitions are
   identical ...

Time to resolve the mess.  I see the following options:

 - Yet another syscall wrapper that does argument conversion.  Imho the
   most icky solution.

 - Change the kernel to use the same definition as glibc.  Not really an
   option, SIGEV_CALLBACK has to go.

 - Two part solution:
   - Change the kernel definition to what other architectures use (Done,
     may have to be undone depending on the outcome of this discussion).

   - Remove SIGEV_CALLBACK from glibc which would result in SIGEV_THREAD
     getting renumbered to the same value as in the kernel.
     (This is in my withdrawn libc patch from the weekend.)

   Grepping around in plenty of Linux code I've not found any users of
   SIGEV_THREAD so this would be my prefered solution.

   SIGEV_CALLBACK would have to be removed in any case; it's a dead
   definition with no functionality.  Is it supposed to do what
   SIGEV_THREAD_ID does?  I've been digging around in parts of the Redhat 9
   source code and haven't found any users of SIGEV_THREAD, so it seems
   this is a very rarely used feature and we can change without any major
   compatibility issues.

Comments?

  Ralf

From yuasa@hh.iij4u.or.jp Wed Sep  3 17:10:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Sep 2003 17:10:57 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:28396 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225310AbTICQKZ>;
	Wed, 3 Sep 2003 17:10:25 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id BAA10883;
	Thu, 4 Sep 2003 01:10:21 +0900 (JST)
Received: 4UMDO01 id h83GALQ22510; Thu, 4 Sep 2003 01:10:21 +0900 (JST)
Received: 4UMRO01 id h83GAKH05760; Thu, 4 Sep 2003 01:10:21 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Thu, 4 Sep 2003 01:10:19 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: [patch] NEC VRC4173 CARDU
Message-Id: <20030904011019.5c6fe5a0.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Thu__4_Sep_2003_01:10:19_+0900_08623c98"
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3121
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Thu__4_Sep_2003_01:10:19_+0900_08623c98
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I made a patch for NEC VRC4173 CARDU(PCMCIA Controller).
This patch can be prevented from probing the already used slot.

Please apply this patch.

Yoichi

--Multipart_Thu__4_Sep_2003_01:10:19_+0900_08623c98
Content-Type: text/plain;
 name="vrc4173_cardu-v24.diff"
Content-Disposition: attachment;
 filename="vrc4173_cardu-v24.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/pcmcia/vrc4173_cardu.c linux/drivers/pcmcia/vrc4173_cardu.c
--- linux.orig/drivers/pcmcia/vrc4173_cardu.c	Fri Apr 11 11:08:50 2003
+++ linux/drivers/pcmcia/vrc4173_cardu.c	Wed Sep  3 19:47:00 2003
@@ -6,7 +6,7 @@
  * 	NEC VRC4173 CARDU driver for Socket Services
  *	(This device doesn't support CardBus. it is supporting only 16bit PC Card.)
  *
- * Copyright 2002 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ * Copyright 2002,2003 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify it
  *  under the terms of the GNU General Public License as published by the
@@ -520,6 +520,9 @@
 
 	slot = vrc4173_cardu_slots++;
 	socket = &cardu_sockets[slot];
+	if (socket->noprobe != 0)
+		return -EBUSY;
+
 	sprintf(socket->name, "NEC VRC4173 CARDU%1d", slot+1);
 
 	if ((err = pci_enable_device(dev)) < 0)
@@ -564,6 +567,36 @@
 
 	return 0;
 }
+
+static int __devinit vrc4173_cardu_setup(char *options)
+{
+	if (options == NULL || *options == '\0')
+		return 0;
+
+	if (strncmp(options, "cardu1:", 7) == 0) {
+		options += 7;
+		if (*options != '\0') {
+			if (strncmp(options, "noprobe", 7) == 0) {
+				cardu_sockets[CARDU1].noprobe = 1;
+				options += 7;
+			}
+
+			if (*options != ',')
+				return 0;
+		} else
+			return 0;
+	}
+
+	if (strncmp(options, "cardu2:", 7) == 0) {
+		options += 7;
+		if ((*options != '\0') && (strncmp(options, "noprobe", 7) == 0))
+			cardu_sockets[CARDU2].noprobe = 1;
+	}
+
+	return 0;
+}
+
+__setup("vrc4173_cardu=", vrc4173_cardu_setup);
 
 static struct pci_device_id vrc4173_cardu_id_table[] __devinitdata = {
 	{	.vendor		= PCI_VENDOR_ID_NEC,
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/pcmcia/vrc4173_cardu.h linux/drivers/pcmcia/vrc4173_cardu.h
--- linux.orig/drivers/pcmcia/vrc4173_cardu.h	Fri Apr 11 11:08:50 2003
+++ linux/drivers/pcmcia/vrc4173_cardu.h	Wed Sep  3 19:47:05 2003
@@ -35,6 +35,8 @@
 #include <pcmcia/ss.h>
 
 #define CARDU_MAX_SOCKETS	2
+#define CARDU1			0
+#define CARDU2			1
 
 /*
  * PCI Configuration Registers
@@ -229,6 +231,7 @@
  #define VPP_CNT_0V		0x00000000
 
 typedef struct vrc4173_socket {
+	int noprobe;
 	struct pci_dev *dev;
 	void *base;
 	void (*handler)(void *, unsigned int);

--Multipart_Thu__4_Sep_2003_01:10:19_+0900_08623c98
Content-Type: text/plain;
 name="vrc4173_cardu-v26.diff"
Content-Disposition: attachment;
 filename="vrc4173_cardu-v26.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/pcmcia/vrc4173_cardu.c linux/drivers/pcmcia/vrc4173_cardu.c
--- linux.orig/drivers/pcmcia/vrc4173_cardu.c	Fri Apr 11 11:09:21 2003
+++ linux/drivers/pcmcia/vrc4173_cardu.c	Thu Sep  4 00:51:29 2003
@@ -6,7 +6,7 @@
  * 	NEC VRC4173 CARDU driver for Socket Services
  *	(This device doesn't support CardBus. it is supporting only 16bit PC Card.)
  *
- * Copyright 2002 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ * Copyright 2002,2003 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify it
  *  under the terms of the GNU General Public License as published by the
@@ -519,6 +519,9 @@
 
 	slot = vrc4173_cardu_slots++;
 	socket = &cardu_sockets[slot];
+	if (socket->noprobe != 0)
+		return -EBUSY;
+
 	sprintf(socket->name, "NEC VRC4173 CARDU%1d", slot+1);
 
 	if ((err = pci_enable_device(dev)) < 0)
@@ -563,6 +566,36 @@
 
 	return 0;
 }
+
+static int __devinit vrc4173_cardu_setup(char *options)
+{
+	if (options == NULL || *options == '\0')
+		return 0;
+
+	if (strncmp(options, "cardu1:", 7) == 0) {
+		options += 7;
+		if (*options != '\0') {
+			if (strncmp(options, "noprobe", 7) == 0) {
+				cardu_sockets[CARDU1].noprobe = 1;
+				options += 7;
+			}
+
+			if (*options != ',')
+				return 0;
+		} else
+			return 0;
+	}
+
+	if (strncmp(options, "cardu2:", 7) == 0) {
+		options += 7;
+		if ((*options != '\0') && (strncmp(options, "noprobe", 7) == 0))
+			cardu_sockets[CARDU2].noprobe = 1;
+	}
+
+	return 0;
+}
+
+__setup("vrc4173_cardu=", vrc4173_cardu_setup);
 
 static struct pci_device_id vrc4173_cardu_id_table[] __devinitdata = {
 	{	.vendor		= PCI_VENDOR_ID_NEC,
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/pcmcia/vrc4173_cardu.h linux/drivers/pcmcia/vrc4173_cardu.h
--- linux.orig/drivers/pcmcia/vrc4173_cardu.h	Fri Apr 11 11:09:21 2003
+++ linux/drivers/pcmcia/vrc4173_cardu.h	Thu Sep  4 00:51:29 2003
@@ -35,6 +35,8 @@
 #include <pcmcia/ss.h>
 
 #define CARDU_MAX_SOCKETS	2
+#define CARDU1			0
+#define CARDU2			1
 
 /*
  * PCI Configuration Registers
@@ -229,6 +231,7 @@
  #define VPP_CNT_0V		0x00000000
 
 typedef struct vrc4173_socket {
+	int noprobe;
 	struct pci_dev *dev;
 	void *base;
 	void (*handler)(void *, unsigned int);

--Multipart_Thu__4_Sep_2003_01:10:19_+0900_08623c98--

From kwalker@broadcom.com Thu Sep  4 00:46:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Sep 2003 00:46:31 +0100 (BST)
Received: from mms2.broadcom.com ([IPv6:::ffff:63.70.210.59]:13828 "EHLO
	mms2.broadcom.com") by linux-mips.org with ESMTP
	id <S8225351AbTICXq3>; Thu, 4 Sep 2003 00:46:29 +0100
Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.3)); Wed, 03 Sep 2003 16:42:43 -0700
Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com
 [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id QAA08319 for <linux-mips@linux-mips.org>; Wed, 3 Sep 2003 16:45:52
 -0700 (PDT)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id
 h83NkIov013686 for <linux-mips@linux-mips.org>; Wed, 3 Sep 2003 16:46:
 19 -0700 (PDT)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id QAA17707 for
 <linux-mips@linux-mips.org>; Wed, 3 Sep 2003 16:46:18 -0700
Message-ID: <3F567D4A.BA3FD396@broadcom.com>
Date: Wed, 03 Sep 2003 16:46:18 -0700
From: "Kip Walker" <kwalker@broadcom.com>
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@linux-mips.org
Subject: [PATCH] sibyte patch for 2.6 ide.h
X-WSS-ID: 1348A3F9646265-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <kwalker@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3122
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kwalker@broadcom.com
Precedence: bulk
X-list: linux-mips

Folks,

Any objection to the following patch, which lets IDE work on 2.6 for
SiByte platforms?  Before getting it checked in, I'm willing to hear
style comments.  I need extra work to happen in ide_init_default_hwifs,
but that code doesn't fit well in <asm/ide.h> because most of the useful
declarations in <linux/ide.h> haven't been made yet.  With this patch, I
hoist the code into a C file, but can call back into the existing code
(avoiding maintaining a duplicate).

Kip

Index: include/asm-mips/ide.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/ide.h,v
retrieving revision 1.22
diff -u -r1.22 ide.h
--- include/asm-mips/ide.h      21 Jun 2003 14:08:28 -0000      1.22
+++ include/asm-mips/ide.h      3 Sep 2003 23:42:16 -0000
@@ -50,7 +50,12 @@
        ide_ops->ide_init_hwif_ports(hw, data_port, ctrl_port, irq);
 }
 
+#ifdef CONFIG_SIBYTE_SB1xxx_SOC
+extern void ide_init_default_hwifs(void);
+static __inline__ void mips_ide_init_default_hwifs(void)
+#else
 static __inline__ void ide_init_default_hwifs(void)
+#endif
 {
 #ifndef CONFIG_PCI
        hw_regs_t hw;


From jinum@esntechnologies.co.in Thu Sep  4 10:24:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Sep 2003 10:24:14 +0100 (BST)
Received: from [IPv6:::ffff:202.125.80.34] ([IPv6:::ffff:202.125.80.34]:56583
	"EHLO mail.esn.activedirectory") by linux-mips.org with ESMTP
	id <S8225200AbTIDJX6>; Thu, 4 Sep 2003 10:23:58 +0100
Received: by mail.esn.activedirectory with Internet Mail Service (5.5.2650.10)
	id <RQAMMVKC>; Thu, 4 Sep 2003 14:38:17 +0530
Message-ID: <AF572D578398634881E52418B28925671EA5FC@mail.esn.activedirectory>
From: JinuM <jinum@esntechnologies.co.in>
To: linux-mips@linux-mips.org
Subject: PCI driver problem
Date: Thu, 4 Sep 2003 14:38:12 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <jinum@esntechnologies.co.in>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3123
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jinum@esntechnologies.co.in
Precedence: bulk
X-list: linux-mips

Hi All,

I am moving onto MIPS from x86. I am facing a few problems using the base
address register of my PCI device on my MIPS.

i have a PCI card and i have written a simple driver for it on my x86
system. I dont follow the "pci_register_driver()" routine, instead i do a
"register_chrdrv()" in my "init_module()". 

In the my "open" call back routine, i do a 
****dev=pci_find_device(MY_VEN_ID,MY_DEV_ID,NULL);
then follow it by 
****mystruct->ioaddr=pci_resource_start(dev,0);
i do a ioremap n get my remapped address 
****mystruct->reioaddr = ioremap(mystruct->ioaddr,someLen);

ofcourse i do all the error checks after the function calls.

now in my open callback routine for testing i do a 

outl(0x42, mystruct->reioaddr+LED_OFFSET)

this puts OFF the LED on my card.

The above steps work well with my x86 system and the LED does go OFF. But
the same code doesnot work on my MIPS. Is there a difference in the way i
should use my base address register or do my IO(out(s) and in(s)). I guess
MIPS doesnot support I/O mapped devices, but i think in and out on MIPS take
care of converting the access.

Its to be noted that my PCI configuration space also differs. I get 0x0006
from my PCI command register in G4 where as on x86 i have 0x0107. Is this
because IO based accessing is not enabled on MIPS?

do i need to do a pci_enable_device(dev) after my pci_find_device()????? I
tried this but it dint work. 

can anyone please help me figure out the problem? 

thanx for your time!
-Jinu


From ashish_ibm@rediffmail.com Thu Sep  4 14:57:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Sep 2003 14:58:30 +0100 (BST)
Received: from webmail10.rediffmail.com ([IPv6:::ffff:202.54.124.179]:35806
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225364AbTIDN56>; Thu, 4 Sep 2003 14:57:58 +0100
Received: (qmail 28349 invoked by uid 510); 4 Sep 2003 12:52:58 -0000
Date: 4 Sep 2003 12:52:58 -0000
Message-ID: <20030904125258.28348.qmail@webmail10.rediffmail.com>
Received: from unknown (210.210.7.195) by rediffmail.com via HTTP; 04 sep 2003 12:52:58 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: configuring edge or level triggered interrupt..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ashish_ibm@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3124
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashish_ibm@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello,
I have a problem of interfacing an ISDN SLAC device which raise
interrupts as edge triggered only .

while board is configured for Level triggered interrupts.
ocassionally i get spurious interrupts as edge is lost.
I tried to got a new edge by writing FFh in mask register and 
again
restoring oldmask but somehow it didn't help.

my question is that how I can configure edge triggered interrupt 
on my
linux host side on mips Lexra architecture...
I see no mention of that on my mips linux source tree..while on 
other architectures say PPC I used to explicitly configure the 
lines
of interrupt controller as edge or level triggered and active high 
or low polarity .

Best Regards,
Ashish Anand

___________________________________________________
Meet your old school or college friends from
1 Million + database...
Click here to reunite www.batchmates.com/rediff.asp



From macro@ds2.pg.gda.pl Thu Sep  4 15:13:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Sep 2003 15:13:19 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:32905 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225364AbTIDONH>; Thu, 4 Sep 2003 15:13:07 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA14505;
	Thu, 4 Sep 2003 16:12:55 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 4 Sep 2003 16:12:54 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Richard van den Berg <ravdberg@inter.NL.net>
cc: linux-mips@linux-mips.org
Subject: Re: hwclock error on DECstation 5000/133 with 2.4.22
In-Reply-To: <Pine.LNX.4.21.0309022258540.17245-100000@whale.dutch.mountain>
Message-ID: <Pine.GSO.3.96.1030904161032.12210F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3125
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 2 Sep 2003, Richard van den Berg wrote:

> Kernel 2.4.17 (Debian kernel-source package) didn't give following error: 
> fortuna:~# hwclock
> hwclock: ioctl() to /dev/rtc to turn on update interrupts failed unexpectedly, errno=25: Inappropriate ioctl for device.
> fortuna:~# hwclock -v
> hwclock 2.4c/util-linux-2.11n

 Please upgrade util-linux -- this has been fixed long time ago.

> 2.4.22 checked out august 27th, system time gets set, don't know if above
> message has other effects. With this kernel recognizes the LK401 keyboard,
> 2.4.17 gave id 186.

 Well, ID 186 looks bogus -- DEC assigned these IDs starting from 1 and
finished at 4, apparently.  I wouldn't recommend running a kernel as old
as 2.4.17. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From dkesselr@mmc.atmel.com Fri Sep  5 15:04:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Sep 2003 15:04:19 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:27705
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225375AbTIEOER>; Fri, 5 Sep 2003 15:04:17 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA03679
	for <linux-mips@linux-mips.org>; Fri, 5 Sep 2003 10:04:12 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA03531
	for <linux-mips@linux-mips.org>; Fri, 5 Sep 2003 10:04:02 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Fri, 5 Sep 2003 10:04:01 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: 64 bit compile problems
Message-ID: <Pine.GSO.4.44.0309050955460.26490-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3127
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1545
Lines: 38

I'm trying to build u-boot bootloader for a 5kc core in 64 bit mode. I'm
having problems with the compiler/linker. If anyone has any ideas, please
let me know.

When I use the toolchain that installs in
"/usr/cygnus/mips3264-020217/H-i686-pc-linux-gnulibc2.1/bin", I get a link
problem where all opcodes are not aligned on a 64 bit boundry. I get an
extra 32bit word of 0x0 between two 64bit opcodes in the binary file.
The cpp options I use are:-mips64 -EL -mlong64 -mcpu=r5k

When I use a toolchain which I think I ftp'd from linux-mips.org
(mips64el-linux), I get the following error. The cpp options I use are:-EL
-mabi=64 -mips4 -mlong64


/usr/bin/mips64el-linux-gcc  -O   -D__KERNEL__ -DTEXT_BASE=0x00000
-I/home/dkesselr/uboot/u-boot-0.4.5-atmel/include
-I/home/dkesselr/uboot/u-boot-0.4.5-atmel/include/asm -fno-builtin
-ffreestanding -nostdinc -isystem
/usr/lib/gcc-lib/mips64el-linux/2.95.4/include -pipe  -DCONFIG_MIPS
-D__MIPS__ -EL -mabi=64 -mips4
-mlong64 -Wall -Wstrict-prototypes -c -o atmel352.o atmel352.c
atmel352.c: In function `sdram_timing_init':
atmel352.c:82: warning: cast to pointer from integer of different size
atmel352.c:90: warning: cast to pointer from integer of different size
atmel352.c: In function `copydwords':
atmel352.c:186: Internal compiler error in `rtx_equal_for_memref_p', at
alias.c:682
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
cpp0: output pipe has been closed


Thanks,
David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com 919-462-6587


From macro@ds2.pg.gda.pl Fri Sep  5 17:44:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Sep 2003 17:44:55 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:23223 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225377AbTIEQox>; Fri, 5 Sep 2003 17:44:53 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA06957;
	Fri, 5 Sep 2003 18:44:41 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 5 Sep 2003 18:44:40 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Kesselring <dkesselr@mmc.atmel.com>
cc: linux-mips@linux-mips.org
Subject: Re: 64 bit compile problems
In-Reply-To: <Pine.GSO.4.44.0309050955460.26490-100000@ares.mmc.atmel.com>
Message-ID: <Pine.GSO.3.96.1030905182856.1692F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3128
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 2938
Lines: 62

On Fri, 5 Sep 2003, David Kesselring wrote:

> I'm trying to build u-boot bootloader for a 5kc core in 64 bit mode. I'm
> having problems with the compiler/linker. If anyone has any ideas, please
> let me know.
> 
> When I use the toolchain that installs in
> "/usr/cygnus/mips3264-020217/H-i686-pc-linux-gnulibc2.1/bin", I get a link
> problem where all opcodes are not aligned on a 64 bit boundry. I get an
> extra 32bit word of 0x0 between two 64bit opcodes in the binary file.
> The cpp options I use are:-mips64 -EL -mlong64 -mcpu=r5k

 I don't really understand -- MIPS regular opcodes (i.e. not in the MIPS16
mode) have to be aligned to 32-bit boundaries.  What do you mean by
"64-bit opcodes"?  If there is a null word (a "nop") between each pair of
emitted opcodes, then the resulting binary should still work, although
suboptimally.  It may be a bug in gcc or gas.  Does the output from gcc
contains the padding?  What are the versions of gcc and binutils? 

> When I use a toolchain which I think I ftp'd from linux-mips.org
> (mips64el-linux), I get the following error. The cpp options I use
> are:-EL -mabi=64 -mips4 -mlong64
> 
> 
> /usr/bin/mips64el-linux-gcc  -O   -D__KERNEL__ -DTEXT_BASE=0x00000
> -I/home/dkesselr/uboot/u-boot-0.4.5-atmel/include
> -I/home/dkesselr/uboot/u-boot-0.4.5-atmel/include/asm -fno-builtin
> -ffreestanding -nostdinc -isystem
> /usr/lib/gcc-lib/mips64el-linux/2.95.4/include -pipe  -DCONFIG_MIPS
> -D__MIPS__ -EL -mabi=64 -mips4
> -mlong64 -Wall -Wstrict-prototypes -c -o atmel352.o atmel352.c
> atmel352.c: In function `sdram_timing_init':
> atmel352.c:82: warning: cast to pointer from integer of different size
> atmel352.c:90: warning: cast to pointer from integer of different size
> atmel352.c: In function `copydwords':
> atmel352.c:186: Internal compiler error in `rtx_equal_for_memref_p', at
> alias.c:682
> Please submit a full bug report.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> cpp0: output pipe has been closed

 That's interesting -- it's almost surely a bug in the RTL.  I may try to
reproduce it with my toolchain -- can you send me a preprocessed version
of this file?  If so, please run the following command and send me the
resulting atmel352.i file -- use `bzip2 -9' or `gzip -9' and send it
attached directly to me only to save net resources:

$ /usr/bin/mips64el-linux-gcc  -O   -D__KERNEL__ -DTEXT_BASE=0x00000
-I/home/dkesselr/uboot/u-boot-0.4.5-atmel/include
-I/home/dkesselr/uboot/u-boot-0.4.5-atmel/include/asm -fno-builtin
-ffreestanding -nostdinc -isystem
/usr/lib/gcc-lib/mips64el-linux/2.95.4/include -pipe  -DCONFIG_MIPS
-D__MIPS__ -EL -mabi=64 -mips4
-mlong64 -Wall -Wstrict-prototypes -E -o atmel352.i atmel352.c

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From macro@ds2.pg.gda.pl Fri Sep  5 17:57:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Sep 2003 17:57:30 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:51639 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225377AbTIEQ52>; Fri, 5 Sep 2003 17:57:28 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA07161;
	Fri, 5 Sep 2003 18:57:23 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 5 Sep 2003 18:57:23 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Kip Walker <kwalker@broadcom.com>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] sibyte patch for 2.6 ide.h
In-Reply-To: <3F567D4A.BA3FD396@broadcom.com>
Message-ID: <Pine.GSO.3.96.1030905185304.1692G-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3129
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 871
Lines: 19

On Wed, 3 Sep 2003, Kip Walker wrote:

> Any objection to the following patch, which lets IDE work on 2.6 for
> SiByte platforms?  Before getting it checked in, I'm willing to hear
> style comments.  I need extra work to happen in ide_init_default_hwifs,
> but that code doesn't fit well in <asm/ide.h> because most of the useful
> declarations in <linux/ide.h> haven't been made yet.  With this patch, I
> hoist the code into a C file, but can call back into the existing code
> (avoiding maintaining a duplicate).

 Hmm, dumb question -- can't your extra work be done in code specific to
the host-adapter?  The ide_init_default_hwifs() function looks like ISA
legacy.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From kwalker@broadcom.com Fri Sep  5 18:08:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Sep 2003 18:08:53 +0100 (BST)
Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:24335 "EHLO
	mms1.broadcom.com") by linux-mips.org with ESMTP
	id <S8225377AbTIERIu>; Fri, 5 Sep 2003 18:08:50 +0100
Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.3)); Fri, 05 Sep 2003 10:08:47 -0700
Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com
 [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id KAA02557; Fri, 5 Sep 2003 10:08:17 -0700 (PDT)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id
 h85H8eov003600; Fri, 5 Sep 2003 10:08:42 -0700 (PDT)
Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by
 dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id KAA20141; Fri, 5
 Sep 2003 10:08:40 -0700
Message-ID: <3F58C318.1CCAB218@broadcom.com>
Date: Fri, 05 Sep 2003 10:08:40 -0700
From: "Kip Walker" <kwalker@broadcom.com>
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: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] sibyte patch for 2.6 ide.h
References: <Pine.GSO.3.96.1030905185304.1692G-100000@delta.ds2.pg.gda.pl>
X-WSS-ID: 13461C95864132-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <kwalker@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3130
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kwalker@broadcom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1461
Lines: 33

"Maciej W. Rozycki" wrote:
> 
> On Wed, 3 Sep 2003, Kip Walker wrote:
> 
> > Any objection to the following patch, which lets IDE work on 2.6 for
> > SiByte platforms?  Before getting it checked in, I'm willing to hear
> > style comments.  I need extra work to happen in ide_init_default_hwifs,
> > but that code doesn't fit well in <asm/ide.h> because most of the useful
> > declarations in <linux/ide.h> haven't been made yet.  With this patch, I
> > hoist the code into a C file, but can call back into the existing code
> > (avoiding maintaining a duplicate).
> 
>  Hmm, dumb question -- can't your extra work be done in code specific to
> the host-adapter?  The ide_init_default_hwifs() function looks like ISA
> legacy.

Well, I'm not sure.  First, the only "special" host adaptor is the
so-called Generic Bus IDE, which is probed in drivers/ide/mips/swarm.c. 
And I used to simply setup the ops in there.  But on my platform,
PCI-IDE adaptors need my special non-swapping ops too.  If I wait until
my host adaptor is setup, it's too late because in 2.6 the pci-ide code
has already tried to identify the drive using the swapping ops (my
experiments indicated that this was NOT the case in 2.4).

This routine is conveniently called AFTER default ops are setup for all
hwifs and before the PCI probing is done.  It seemed like a nice place
fix things up.

I'm happy to hear any alternatives that I can make work.  All that IDE
code gives me chills.

Kip


From prabhakark@contechsoftware.com Sat Sep  6 06:59:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 Sep 2003 07:00:08 +0100 (BST)
Received: from [IPv6:::ffff:203.129.212.34] ([IPv6:::ffff:203.129.212.34]:29453
	"HELO contech.contechsoftware.com") by linux-mips.org with SMTP
	id <S8225390AbTIFF7g>; Sat, 6 Sep 2003 06:59:36 +0100
Received: (from prabhakar [200.1.1.48])
 by contech.contechsoftware.com (NAVGW 2.5.1.18) with SMTP id M2003090611365106009
 for <linux-mips@linux-mips.org>; Sat, 06 Sep 2003 11:36:52 +0530
Received: by localhost with Microsoft MAPI; Sat, 6 Sep 2003 11:35:44 -0000
Message-ID: <01C3746B.02106F20.prabhakark@contechsoftware.com>
From: Prabhakar Kalasani <prabhakark@contechsoftware.com>
Reply-To: "prabhakark@contechsoftware.com" <prabhakark@contechsoftware.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: New to MIPS Linux
Date: Sat, 6 Sep 2003 11:35:42 -0000
Organization: Contech Software Limited
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Encoding: 6 TEXT
Return-Path: <prabhakark@contechsoftware.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3133
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: prabhakark@contechsoftware.com
Precedence: bulk
X-list: linux-mips
Content-Length: 269
Lines: 7

Hi all,
I'm new to MIPS Linux , I got to port Linux on pb1500 evalution board,
I got 2.4.22 kernel from http://www.kernel.org/ and toolchain from http://www.linux-mips.org/
anybody can help me out how to compile and port the kernel.
Thnks in advance
Prabhkar Kalasani


From yuasa@hh.iij4u.or.jp Sat Sep  6 08:59:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 Sep 2003 09:00:16 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:17877 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225349AbTIFH7n>;
	Sat, 6 Sep 2003 08:59:43 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id QAA01893;
	Sat, 6 Sep 2003 16:59:39 +0900 (JST)
Received: 4UMDO00 id h867xdF14423; Sat, 6 Sep 2003 16:59:39 +0900 (JST)
Received: 4UMRO01 id h867xb711452; Sat, 6 Sep 2003 16:59:38 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Sat, 6 Sep 2003 16:59:37 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: [patch] NEC VRC4173 CARDU
Message-Id: <20030906165937.06a08c0a.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20030904011019.5c6fe5a0.yuasa@hh.iij4u.or.jp>
References: <20030904011019.5c6fe5a0.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3134
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 324
Lines: 20

Hello Ralf,

Do these patches have any problem?

Yoichi

On Thu, 4 Sep 2003 01:10:19 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf,
> 
> I made a patch for NEC VRC4173 CARDU(PCMCIA Controller).
> This patch can be prevented from probing the already used slot.
> 
> Please apply this patch.
> 
> Yoichi
> 



From ravdberg@inter.NL.net Sat Sep  6 15:21:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 Sep 2003 15:22:13 +0100 (BST)
Received: from altrade.nijmegen.internl.net ([IPv6:::ffff:217.149.192.18]:62404
	"EHLO altrade.nijmegen.internl.net") by linux-mips.org with ESMTP
	id <S8225392AbTIFOVl>; Sat, 6 Sep 2003 15:21:41 +0100
Received: from whale.dutch.mountain by altrade.nijmegen.internl.net
	via 1Cust128.tnt37.rtm1.nld.da.uu.net [213.116.168.128] with ESMTP for <linux-mips@linux-mips.org>
	id h86ELdFC003549 (8.12.9/2.04); Sat, 6 Sep 2003 16:21:39 +0200 (MET DST)
Received: from (locally authorised broken client using invalid hostname!) localhost (really [127.0.0.1]) by whale.dutch.mountain
	via in.smtpd with esmtp (ident ravdberg using rfc1413)
	id <m19vbd1-000HFgC@whale.dutch.mountain> (Debian Smail3.2.0.114)
	Sat, 6 Sep 2003 13:53:19 +0200 (CEST) 
Date: Sat, 6 Sep 2003 13:53:19 +0200 (CEST)
From: Richard van den Berg <ravdberg@inter.NL.net>
X-Sender: ravdberg@whale.dutch.mountain
To: linux-mips@linux-mips.org
Subject: Re: hwclock error on DECstation 5000/133 with 2.4.22
In-Reply-To: <Pine.GSO.3.96.1030904161032.12210F-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.LNX.4.21.0309061336580.9097-100000@whale.dutch.mountain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ravdberg@inter.NL.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3135
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ravdberg@inter.NL.net
Precedence: bulk
X-list: linux-mips
Content-Length: 473
Lines: 15

On Thu, 4 Sep 2003, Maciej W. Rozycki wrote:

> > Kernel 2.4.17 (Debian kernel-source package) didn't give following error: 
> > fortuna:~# hwclock
> > hwclock: ioctl() to /dev/rtc to turn on update interrupts failed unexpectedly, errno=25: Inappropriate ioctl for device.
> > fortuna:~# hwclock -v
> > hwclock 2.4c/util-linux-2.11n
> 
>  Please upgrade util-linux -- this has been fixed long time ago.

Thanks, hwclock from util-linux-2.11z works fine.

Regards,
Richard


From ppopov@mvista.com Sun Sep  7 07:37:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 07 Sep 2003 07:37:45 +0100 (BST)
Received: from mtaw6.prodigy.net ([IPv6:::ffff:64.164.98.56]:57812 "EHLO
	mtaw6.prodigy.net") by linux-mips.org with ESMTP
	id <S8225217AbTIGGhN>; Sun, 7 Sep 2003 07:37:13 +0100
Received: from [10.2.2.60] (adsl-63-194-214-47.dsl.snfc21.pacbell.net [63.194.214.47])
	by mtaw6.prodigy.net (8.12.9/8.12.3) with ESMTP id h876auZi004939;
	Sat, 6 Sep 2003 23:36:56 -0700 (PDT)
Subject: Re: New to MIPS Linux
From: Pete Popov <ppopov@mvista.com>
To: "prabhakark@contechsoftware.com" <prabhakark@contechsoftware.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <01C3746B.02106F20.prabhakark@contechsoftware.com>
References: <01C3746B.02106F20.prabhakark@contechsoftware.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 06 Sep 2003 23:38:22 -0700
Message-Id: <1062916704.1237.1.camel@localhost.localdomain>
Mime-Version: 1.0
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3136
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 497
Lines: 12

On Sat, 2003-09-06 at 04:35, Prabhakar Kalasani wrote:
> Hi all,
> I'm new to MIPS Linux , I got to port Linux on pb1500 evalution board,
> I got 2.4.22 kernel from http://www.kernel.org/ and toolchain from http://www.linux-mips.org/
> anybody can help me out how to compile and port the kernel.

The latest stable mips kernels are on linux-mips.org, not kernel.org.
The Pb1500 is fully supported and stable in linux-mips.org, so use that
source tree and you won't have to "port" anything.

Pete


From zhufeng@koretide.com.cn Mon Sep  8 13:46:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Sep 2003 13:46:38 +0100 (BST)
Received: from [IPv6:::ffff:210.22.155.234] ([IPv6:::ffff:210.22.155.234]:41662
	"EHLO mail.koretide.com.cn") by linux-mips.org with ESMTP
	id <S8225193AbTIHMqg>; Mon, 8 Sep 2003 13:46:36 +0100
Received: from zhufeng ([192.168.1.12])
	(authenticated)
	by mail.koretide.com.cn (8.11.6/8.11.6) with ESMTP id h88Chfx10734
	for <linux-mips@linux-mips.org>; Mon, 8 Sep 2003 20:43:43 +0800
From: "??\(zhufeng\)" <zhufeng@koretide.com.cn>
To: <linux-mips@linux-mips.org>
Subject: about dlltool.exe
Date: Mon, 8 Sep 2003 20:46:14 +0800
Message-ID: <MGEELAPMEFMLFBMDBLKLEEGBCFAA.zhufeng@koretide.com.cn>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <Pine.GSO.3.96.1030905182856.1692F-100000@delta.ds2.pg.gda.pl>
Return-Path: <zhufeng@koretide.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3137
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhufeng@koretide.com.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 125
Lines: 3

how can I get dlltoo.exe for mips ? I cross compiled gcc-mips but found
there is no dlltool.exe . How can I get it? Thanks.


From joey@infodrom.org Mon Sep  8 18:17:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Sep 2003 18:17:28 +0100 (BST)
Received: from luonnotar.infodrom.org ([IPv6:::ffff:195.124.48.78]:24590 "EHLO
	luonnotar.infodrom.org") by linux-mips.org with ESMTP
	id <S8225357AbTIHRRY>; Mon, 8 Sep 2003 18:17:24 +0100
Received: by luonnotar.infodrom.org (Postfix, from userid 10)
	id BFA4B366B74; Mon,  8 Sep 2003 19:17:23 +0200 (CEST)
Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2)
	from infodrom.org by finlandia.Infodrom.North.DE
	via smail from stdin
	id <m19wPZr-000orUC@finlandia.Infodrom.North.DE>
	for linux-mips@linux-mips.org; Mon, 8 Sep 2003 19:13:23 +0200 (CEST) 
Date: Mon, 8 Sep 2003 19:13:23 +0200
From: Martin Schulze <joey@infodrom.org>
To: Linux for m68k <linux-m68k@phil.uni-sb.de>,
	Linux for MIPS <linux-mips@linux-mips.org>,
	Linux for PA-RISC <parisc-linux@lists.parisc-linux.org>,
	Debian Boot Development <debian-boot@lists.debian.org>,
	Debian M68k Development <debian-68k@lists.debian.org>,
	Debian MIPS Development <debian-mips@lists.debian.org>,
	Debian PA-RISC Development <debian-hppa@lists.debian.org>,
	Debian ARM Development <debian-arm@lists.debian.org>
Subject: Invitation to the 8th Oldenburg Linux Developers Meeting
Message-ID: <20030908171323.GD783@finlandia.infodrom.north.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="FN+gV9K+162wdwwF"
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <joey@infodrom.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3138
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joey@infodrom.org
Precedence: bulk
X-list: linux-mips
Content-Length: 4049
Lines: 111


--FN+gV9K+162wdwwF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello everybody,

as always, it has taken quite some time to get the required
confirmation from our University that we can hold the Oldenburg Linux
Developers Meeting again.

       Invitation to the 8th Oldenburg Linux Developers Meeting
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

A short overview:

URL:   http://oldenburger.linuxtage.de/Oldenburg2003/
What:  Oldenburg Linux Developers Meeting 2003 #8
Who:   Every developer interested in Linux on non-i386 platforms
       Every developer interested in developing the debian-installer
When:  September, 25th to 28th (Thursday noon to Sunday afternoon)
Where: University of Oldenburg, science building in Oldenburg Wechloy,
       northern Germany (roughly west of Bremen)

The meeting is organised by ffis e.V.  Its goal is to provide
developers a means to work in common on the non-i386 Linux ports and
related topics and to further the exchange of ideas and discussion
about the several ports.  This year there will also be a group of
people who will work on the new installer system for Debian.  So one
of the targets is to get a working debian-installer running on all
platforms supported by Debian GNU/Linux.

If you have not attended any previous meeting, you might like to take a=20
look at the meetings' website at <http://oldenburger.linuxtage.de/devel.htm=
l>.
There are links to pictures from former meetings as well.

Attendance is free of cost including food and beverage in the working
rooms (although we are always thankful for donations).  We will have
dinner in some restaurants in Oldenburg (not yet decided which ones, though=
) if you
like.

You don't have to attend from Thursday.  This is just an offer for
those of you who would like to and who can afford to come early.  If
you can't make it that early, simply join when you can afford it.

We will use several rooms, one for hacking on Linux, one for hacking
on the debian-installer, and the others for sleeping. =20

Please bring a sleeping bag, camping mat or cot, towels, shower stuff,
clothes and so on with you.  There is a sports building of the
univesity next to the one we stay in, which has showers we can use.

Besides this, of course you need to bring all the technical stuff with
you: computers, monitors, technical documentation, network cabling,
multiple-power-sockets for your systems and hubs or switches.  The
computing center of the university kindly provides us with network
connectivity to the main rooms, but we need to build the LAN within
the room ourselves.

A description on how to get to the science building in Oldenburg Wechloy
is available at <http://oldenburger.linuxtage.de/Oldenburg2003/routing.html=
>.

If you would like to attend the meeting, please send back the following=20
form, so that we can calculate space, power and food.

Name ................:

Date of arrival .....: ( ) Thursday, Sept. 25th
                       ( ) Friday, Sept. 26th
                       ( ) Saturday, Sept. 27th=20

Date of departure ...: ( ) Friday, Sept. 26th
                       ( ) Saturday, Sept. 27th
                       ( ) Sunday, Sept. 28th

Name may be listed on the website: [ ] yes
                                   [ ] no

Special requirements for food:

If you have any further questions, please don't hesitate to ask me.

Regards,

	Joey

--=20
The good thing about standards is that there are so many to choose from.
		-- Andrew S. Tanenbaum

Please always Cc to me when replying to me on the lists.

--FN+gV9K+162wdwwF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD4DBQE/XLizW5ql+IAeqTIRAsEiAJ9t4yArpWROSe++3bmkI88k6wShKQCY8OPI
ysBnw5Ka59stwxwK1Ke3Sg==
=brHJ
-----END PGP SIGNATURE-----

--FN+gV9K+162wdwwF--

From root@linux-mips.org Mon Sep  8 20:45:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Sep 2003 20:45:53 +0100 (BST)
Received: (root@3ffe:8260:2028:fffe::1) by linux-mips.org
	id <S8225375AbTIHTpU>; Mon, 8 Sep 2003 20:45:20 +0100
Received: from webmail8.rediffmail.com ([IPv6:::ffff:202.54.124.153]:40386
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225200AbTIDIEE>; Thu, 4 Sep 2003 09:04:04 +0100
Received: (qmail 26760 invoked by uid 510); 4 Sep 2003 08:03:15 -0000
Date: 4 Sep 2003 08:03:15 -0000
Message-ID: <20030904080315.26759.qmail@webmail8.rediffmail.com>
Received: from unknown (210.210.7.195) by rediffmail.com via HTTP; 04 sep 2003 08:03:15 -0000
MIME-Version: 1.0
From: "ashish  anand" <ashish_ibm@rediffmail.com>
Reply-To: "ashish  anand" <ashish_ibm@rediffmail.com>
To: inux-mips@linux-mips.org
Subject: why irq -1 is being passed to do_IRQ..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Resent-From: root@ftp.linux-mips.org
Resent-Date: Mon, 8 Sep 2003 20:45:20 +0100
Resent-To: linux-mips@linux-mips.org
Return-Path: <root@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3139
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: root@ftp.linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1741
Lines: 56

Hello,

I am writing to this list after a long back.

I have spurious interrupt problem in do_IRQ() in otherwise 
stable
linux port on mips lexra board .problem happens if I use ISDN 
phones.
but it doesn't happen essentially before or after ISDN card 
interrupt.
we have tried writing FFh in ISDN card mask register then again 
restoring old mask in end of ISDN ISR as indicated in ISDN manual 
for interfacing with some interrupt controllers , but it didn't 
help much.
so might be some minute problem in BSP.but i have a more 
fundamental question for now.

actually do_IRQ calls mask_irq and unmask_irq and there it 
prints
".......wrong irq number -1 pased.........."
if i see the code for file int-handler.S

In the first level interrupt handling code  we jump to do_IRQ only 
when irq is >= 0 otherwise we just  return as per the code piece 
below.

as per the code below do_IRQ() should always be passed a valid irq 
number.

                 lw      
a0,%lo(cpu_irq_nr-cpu_mask_tbl-PTRSIZE)(t1)
                  nop
                 bgez    a0, handle_it           # irq_nr >= 0?
                                                # irq_nr < 0: just 
exit
                  nop
                  j       return_
                  nop                            # delay slot

handle_it:      jal     do_IRQ
                  move   a1,sp
return_:        j       ret_from_irq
                  nop

                 END(lx_handle_int)
#endif
I am litle confused why irq -1 is being passed to do_IRQ at all.
pls. cc the reply to me as well.

Best Regards,
Ashish
___________________________________________________
Meet your old school or college friends from
1 Million + database...
Click here to reunite www.batchmates.com/rediff.asp


From ddaney@avtrex.com Tue Sep  9 01:39:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Sep 2003 01:39:53 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:59438 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225384AbTIIAjv>;
	Tue, 9 Sep 2003 01:39:51 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 8 Sep 2003 17:39:29 -0700
Message-ID: <3F5D2141.4050002@avtrex.com>
Date: Mon, 08 Sep 2003 17:39:29 -0700
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: FYI: Patch: MIPS support for (gcc/gcj) libjava. 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Sep 2003 00:39:29.0237 (UTC) FILETIME=[D4076050:01C3766A]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3140
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

http://gcc.gnu.org/ml/java-patches/2003-q3/msg00540.html




From zhufeng@koretide.com.cn Tue Sep  9 02:07:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Sep 2003 02:07:02 +0100 (BST)
Received: from [IPv6:::ffff:210.22.155.234] ([IPv6:::ffff:210.22.155.234]:12994
	"EHLO mail.koretide.com.cn") by linux-mips.org with ESMTP
	id <S8225388AbTIIBHA>; Tue, 9 Sep 2003 02:07:00 +0100
Received: from zhufeng ([192.168.1.12])
	(authenticated)
	by mail.koretide.com.cn (8.11.6/8.11.6) with ESMTP id h8914Ax18996
	for <linux-mips@linux-mips.org>; Tue, 9 Sep 2003 09:04:10 +0800
From: "??\(zhufeng\)" <zhufeng@koretide.com.cn>
To: <linux-mips@linux-mips.org>
Subject: Can gcc support mips-pe now?
Date: Tue, 9 Sep 2003 09:06:44 +0800
Message-ID: <MGEELAPMEFMLFBMDBLKLEEGFCFAA.zhufeng@koretide.com.cn>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <3F5D2141.4050002@avtrex.com>
Return-Path: <zhufeng@koretide.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3141
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zhufeng@koretide.com.cn
Precedence: bulk
X-list: linux-mips

thanks.


From ralf@linux-mips.org Tue Sep  9 12:30:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Sep 2003 12:31:00 +0100 (BST)
Received: from p508B5D2A.dip.t-dialin.net ([IPv6:::ffff:80.139.93.42]:18122
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225348AbTIILa6>; Tue, 9 Sep 2003 12:30:58 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h89BUnLT006799;
	Tue, 9 Sep 2003 13:30:49 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h89BUmqN006798;
	Tue, 9 Sep 2003 13:30:48 +0200
Date: Tue, 9 Sep 2003 13:30:48 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Keith M Wesolowski <wesolows@foobazco.org>
Cc: linux-mips@linux-mips.org
Subject: Re: PATCH: avoid glibc conflict
Message-ID: <20030909113048.GD6715@linux-mips.org>
References: <20030828043112.GA11094@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030828043112.GA11094@foobazco.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3142
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Aug 27, 2003 at 09:31:12PM -0700, Keith M Wesolowski wrote:

> This is needed to avoid a conflict with glibc on bigendian platforms
> when -O or higher is specified.  It's already in 2.6, and I'm not sure
> why it hasn't been seen in 2.4.  The symptom is that this program will
> not compile with -O2:
> 
> #include <asm/byteorder.h>
> #include <netinet/in.h>
> int main () { }
> 
> Here's the patch.

I sent one to Marcelo.

  Ralf

From macro@ds2.pg.gda.pl Tue Sep  9 14:40:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Sep 2003 14:40:51 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:30683 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225358AbTIINks>; Tue, 9 Sep 2003 14:40:48 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA18431;
	Tue, 9 Sep 2003 15:40:45 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 9 Sep 2003 15:40:44 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: ralf@linux-mips.org
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20030909113150Z8225348-1272+5180@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030909153721.18373A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3143
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 9 Sep 2003 ralf@linux-mips.org wrote:

> 	Avoid conflict with glibc on bigendian platforms when -O or higher
> 	is specified.  It's already in 2.6, and I'm not sure why it hasn't
> 	been seen in 2.4.  The symptom is that this program will not compile
> 	with -O2:
> 	
> 	#include <asm/byteorder.h>
> 	#include <netinet/in.h>
> 	int main () { }

 Is <asm/byteorder.h> ever included by glibc headers?  I hope not and user
programs *must* not include kernel headers.  Your program is buggy.


From AdeelM@avaznet.com Tue Sep  9 16:43:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Sep 2003 16:43:44 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:11141
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225391AbTIIPnm>; Tue, 9 Sep 2003 16:43:42 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <SBLGY745>; Tue, 9 Sep 2003 20:36:57 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38262742D@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Cc: Dan Aizenstros <daizenstros@quicklogic.com>
Subject: NFS Server and Client Setup on MIPS Platform
Date: Tue, 9 Sep 2003 20:36:56 +0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C376E8.33AB5C70"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3144
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C376E8.33AB5C70
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
 
         I am using Buildroot-QuickMIPS environment for porting Linux-2.4 to
MIPS Target Platform. I need to Netwrok-Mount the root filesystem and for
this I need to configure the NFS Server on the Host and NFS Client on the
Target.
 
Can someone tell me that what are the steps needed to compile the Buildroot
MIPS kernel for NFS Mounting of MIPS root filesystem ?.
 
I mean what are the configuration settings that need to be made during the
make menuconfig process of MIPS kernel source and then how to make the
zImage with NFS support that could be downloaded on the target system
memory.
 
Regards,
Adeel

------_=_NextPart_001_01C376E8.33AB5C70
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=156471715-09092003><FONT size=2>Hi All,</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=156471715-09092003><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am using 
Buildroot-QuickMIPS environment for porting Linux-2.4 to MIPS Target Platform. I 
need to Netwrok-Mount the root filesystem and for this I need to configure the 
NFS Server on the Host and NFS Client on the Target.</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2>Can someone tell me that what 
are the steps needed to compile the Buildroot MIPS kernel for NFS Mounting of 
MIPS root filesystem ?.</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2>I mean what are the 
configuration settings that need to be made during the make menuconfig process 
of MIPS kernel source and then how to make the zImage with NFS support that 
could be downloaded on the target system memory.</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT 
size=2>Adeel</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C376E8.33AB5C70--

From michael_pruznick@mvista.com Tue Sep  9 17:53:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Sep 2003 17:53:04 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:45559 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225393AbTIIQxB>;
	Tue, 9 Sep 2003 17:53:01 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA15723
	for <linux-mips@linux-mips.org>; Tue, 9 Sep 2003 09:52:54 -0700
Message-ID: <3F5E0566.4E0DD26C@mvista.com>
Date: Tue, 09 Sep 2003 10:52:54 -0600
From: Michael Pruznick <michael_pruznick@mvista.com>
Reply-To: michael_pruznick@mvista.com
Organization: MontaVista
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: PATCH:2.4:tx4927 updates (mostly minor)
Content-Type: multipart/mixed;
 boundary="------------D759BFACE4A59D5E54858F16"
Return-Path: <michael_pruznick@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3145
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael_pruznick@mvista.com
Precedence: bulk
X-list: linux-mips


This is a multi-part message in MIME format.
--------------D759BFACE4A59D5E54858F16
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Please apply the attached patch.  I'll be making a 2.6
version as soon as I can get to it.  

Summary:

Index: arch/mips/config-shared.in
dummy keyboard needed for some .configs

Index: arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c
Index: arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
added prom_getcmdline() and changed the default command line setup

Index: drivers/char/Config.in
put the tx stuff together and in sort order

Index: drivers/char/serial_txx9.c
fixed compile problem when CONFIG_SERIAL_TXX9_CONSOLE=n,
fixed up some devfs issues, and changed the raw output
routine a bit.
--------------D759BFACE4A59D5E54858F16
Content-Type: text/plain; charset=us-ascii;
 name="cvsd"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="cvsd"

Index: arch/mips/config-shared.in
===================================================================
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
retrieving revision 1.1.2.85
diff -u -r1.1.2.85 config-shared.in
--- arch/mips/config-shared.in	8 Sep 2003 00:05:42 -0000	1.1.2.85
+++ arch/mips/config-shared.in	9 Sep 2003 16:22:48 -0000
@@ -647,6 +647,7 @@
    define_bool CONFIG_SWAP_IO_SPACE_L y
    define_bool CONFIG_ISA y
    define_bool CONFIG_NONCOHERENT_IO y
+   define_bool CONFIG_DUMMY_KEYB y
 fi
 if [ "$CONFIG_VICTOR_MPC30X" = "y" ]; then
    define_bool CONFIG_IRQ_CPU y
Index: arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 toshiba_rbtx4927_prom.c
--- arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c	16 Jul 2003 01:08:24 -0000	1.1.2.2
+++ arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c	9 Sep 2003 16:22:48 -0000
@@ -36,11 +36,7 @@
 #include <asm/cpu.h>
 #include <asm/tx4927/tx4927.h>
 
-#ifndef COMMAND_LINE_SIZE
-#define COMMAND_LINE_SIZE CL_SIZE
-#endif
-
-char arcs_cmdline[COMMAND_LINE_SIZE] = "console=ttyS0,38400 ip=any root=nfs rw";
+char arcs_cmdline[CL_SIZE] = "";
 
 void __init prom_init_cmdline(int argc, char **argv)
 {
@@ -63,7 +59,7 @@
 {
 	extern int tx4927_get_mem_size(void);
 	int msize;
-        char* toshiba_name_list[] = GROUP_TOSHIBA_NAMES;
+        const char* toshiba_name_list[] = GROUP_TOSHIBA_NAMES;
         extern char* toshiba_name;
 
 	prom_init_cmdline(argc, argv);
@@ -79,6 +75,11 @@
 
 	msize = tx4927_get_mem_size();
 	add_memory_region(0, msize << 20, BOOT_MEM_RAM);
+}
+
+char * __init prom_getcmdline(void)
+{
+	return &(arcs_cmdline[0]);
 }
 
 void __init prom_free_prom_memory(void)
Index: arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 toshiba_rbtx4927_setup.c
--- arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	25 Aug 2003 16:14:53 -0000	1.1.2.5
+++ arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	9 Sep 2003 16:22:48 -0000
@@ -141,6 +141,8 @@
 
 extern void gt64120_time_init(void);
 extern void toshiba_rbtx4927_irq_setup(void);
+extern char *prom_getcmdline(void);
+
 
 #ifdef CONFIG_PCI
 #define CONFIG_TX4927BUG_WORKAROUND
@@ -257,7 +259,7 @@
 #endif /* CONFIG_PCI */
 
 #ifdef CONFIG_PCI
-#ifdef  TX4927_SUPPORT_PCI_66
+#ifdef TX4927_SUPPORT_PCI_66
 void tx4927_pci66_setup(void)
 {
 	int pciclk, pciclkin = 1;
@@ -866,7 +868,6 @@
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_PCI2, "+\n");
 }
-
 #endif /* CONFIG_PCI */
 
 void toshiba_rbtx4927_restart(char *command)
@@ -910,6 +911,8 @@
 void __init toshiba_rbtx4927_setup(void)
 {
 	vu32 cp0_config;
+	char *argptr;
+	u32 backplane_id = 0;
 
 	printk("CPU is %s\n", toshiba_name);
 
@@ -997,7 +1000,6 @@
 
 
 #ifdef CONFIG_PCI
-
 	/* PCIC */
 	/*
 	   * ASSUMPTION: PCIDIVMODE is configured for PCI 33MHz or 66MHz.
@@ -1059,16 +1061,13 @@
 	tx4927_pci_setup();
 
 
-	{
-		u32 id = 0;
-		early_read_config_dword(&mips_pci_channels[0], 0, 0, 0x90,
-					PCI_VENDOR_ID, &id);
-		if (id == 0x94601055) {
-			tx4927_using_backplane = 1;
-			printk("backplane board IS installed\n");
-		} else {
-			printk("backplane board NOT installed\n");
-		}
+	early_read_config_dword(&mips_pci_channels[0], 0, 0, 0x90,
+			PCI_VENDOR_ID, &backplane_id);
+	if (backplane_id == 0x94601055) {
+		tx4927_using_backplane = 1;
+		printk("backplane board IS installed\n");
+	} else {
+		printk("backplane board NOT installed\n");
 	}
 #endif
 
@@ -1141,6 +1140,38 @@
 	}
 #endif
 
+#ifdef CONFIG_SERIAL_TXX9_CONSOLE
+	argptr = prom_getcmdline();
+	if (strstr(argptr, "console=") == NULL) {
+#ifdef CONFIG_DEVFS_FS
+		strcat(argptr, " console=tts/0,38400");
+#else
+		strcat(argptr, " console=ttyS0,38400");
+#endif
+	}
+#endif
+
+#ifdef CONFIG_NE2000
+	/* with the ne_eth= patch to ne.c this enables built-in 8019 */
+	argptr = prom_getcmdline();
+	if (strstr(argptr, "ne_eth=") == NULL) {
+		strcat(argptr, " ne_eth=0x6020280,29");
+	}
+#endif
+
+#ifdef CONFIG_IP_PNP
+	argptr = prom_getcmdline();
+	if (strstr(argptr, "ip=") == NULL) {
+		strcat(argptr, " ip=any");
+	}
+#endif
+
+#ifdef CONFIG_ROOT_NFS
+	argptr = prom_getcmdline();
+	if (strstr(argptr, "root=") == NULL) {
+		strcat(argptr, " root=/dev/nfs rw");
+	}
+#endif
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_SETUP,
 				       "+\n");
Index: drivers/char/Config.in
===================================================================
RCS file: /home/cvs/linux/drivers/char/Attic/Config.in,v
retrieving revision 1.72.2.34
diff -u -r1.72.2.34 Config.in
--- drivers/char/Config.in	13 Aug 2003 17:19:16 -0000	1.72.2.34
+++ drivers/char/Config.in	9 Sep 2003 16:22:49 -0000
@@ -82,10 +82,12 @@
      fi
    fi
    if [ "$CONFIG_MIPS" = "y" ]; then
-      bool '  TX3912/PR31700 serial port support' CONFIG_SERIAL_TX3912
-      dep_bool '     Console on TX3912/PR31700 serial port' CONFIG_SERIAL_TX3912_CONSOLE $CONFIG_SERIAL_TX3912
       bool '  TMPTX39XX/49XX serial port support' CONFIG_SERIAL_TXX9
       dep_bool '     Console on TMPTX39XX/49XX serial port' CONFIG_SERIAL_TXX9_CONSOLE $CONFIG_SERIAL_TXX9
+      bool '  TX3912/PR31700 serial port support' CONFIG_SERIAL_TX3912
+      dep_bool '     Console on TX3912/PR31700 serial port' CONFIG_SERIAL_TX3912_CONSOLE $CONFIG_SERIAL_TX3912
+      bool '  TXx927 SIO support' CONFIG_TXX927_SERIAL 
+      dep_bool '    TXx927 SIO Console support' CONFIG_TXX927_SERIAL_CONSOLE $CONFIG_TXX927_SERIAL
       if [ "$CONFIG_SOC_AU1X00" = "y" ]; then
 	 bool '  Enable Au1x00 UART Support' CONFIG_AU1X00_UART
 	 if [ "$CONFIG_AU1X00_UART" = "y" ]; then
@@ -100,10 +102,6 @@
 		 define_bool CONFIG_AU1X00_USB_DEVICE y
 	    fi
       fi
-      bool '  TXx927 SIO support' CONFIG_TXX927_SERIAL 
-      if [ "$CONFIG_TXX927_SERIAL" = "y" ]; then
-         bool '    TXx927 SIO Console support' CONFIG_TXX927_SERIAL_CONSOLE  
-      fi                             
       if [ "$CONFIG_SIBYTE_SB1xxx_SOC" = "y" ]; then
          bool '  Support for BCM1xxx onchip DUART' CONFIG_SIBYTE_SB1250_DUART
          if [ "$CONFIG_SIBYTE_SB1250_DUART" = "y" ]; then
Index: drivers/char/serial_txx9.c
===================================================================
RCS file: /home/cvs/linux/drivers/char/serial_txx9.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 serial_txx9.c
--- drivers/char/serial_txx9.c	11 Apr 2003 17:26:21 -0000	1.1.2.1
+++ drivers/char/serial_txx9.c	9 Sep 2003 16:22:49 -0000
@@ -52,6 +52,7 @@
 #ifdef CONFIG_SERIAL
 /* "ttyS","cua" is used for standard serial driver */
 #define TXX9_TTY_NAME "ttyTX"
+#define TXX9_TTY_DEVFS_NAME_SHORT "tts/TX"
 #define TXX9_TTY_DEVFS_NAME "tts/TX%d"
 #define TXX9_TTY_MINOR_START	(64 + 64)	/* ttyTX0(128), ttyTX1(129) */
 #define TXX9_CU_NAME "cuatx"
@@ -59,6 +60,7 @@
 #else
 /* acts like standard serial driver */
 #define TXX9_TTY_NAME "ttyS"
+#define TXX9_TTY_DEVFS_NAME_SHORT "tts/"
 #define TXX9_TTY_DEVFS_NAME "tts/%d"
 #define TXX9_TTY_MINOR_START	64
 #define TXX9_CU_NAME "cua"
@@ -1248,7 +1250,12 @@
 {
 	unsigned long flags;
 
-	if (port - &rs_ports[0] != sercons.index) {
+#ifdef CONFIG_SERIAL_TXX9_CONSOLE
+#define EXPR_1 port - &rs_ports[0] != sercons.index
+#else
+#define EXPR_1 1
+#endif
+	if (EXPR_1) {
 		local_irq_save(flags);
 		/*
 		 * Reset the UART.
@@ -1311,9 +1318,15 @@
 
 	txx9_config(port);
 
+#if defined(CONFIG_DEVFS_FS)
+	printk(KERN_INFO
+		"%s%d at 0x%08lx (irq = %d) is a TX39/49 SIO\n",
+		TXX9_TTY_DEVFS_NAME_SHORT, i, port->base, port->irq);
+#else
 	printk(KERN_INFO
 		"%s%d at 0x%08lx (irq = %d) is a TX39/49 SIO\n",
 		TXX9_TTY_NAME, i, port->base, port->irq);
+#endif
 	return 0;
 }
 
@@ -1395,9 +1408,15 @@
 				continue;
 		}
 		txx9_config(port);
+#if defined(CONFIG_DEVFS_FS)
+		printk(KERN_INFO
+		       "%s%d at 0x%08lx (irq = %d) is a TX39/49 SIO\n",
+		       TXX9_TTY_DEVFS_NAME_SHORT, i, port->base, port->irq);
+#else
 		printk(KERN_INFO
 		       "%s%d at 0x%08lx (irq = %d) is a TX39/49 SIO\n",
 		       TXX9_TTY_NAME, i, port->base, port->irq);
+#endif
 	}
 
 	/* Note: I didn't do anything to enable the second UART */
@@ -1637,7 +1656,11 @@
 }
 
 static struct console sercons = {
+#if defined(CONFIG_DEVFS_FS)
+	name:		TXX9_TTY_DEVFS_NAME_SHORT,
+#else
 	name:		TXX9_TTY_NAME,
+#endif
 	write:		serial_console_write,
 	device:		serial_console_device,
 	setup:		serial_console_setup,
@@ -1754,7 +1777,8 @@
 /* END: KDBG Routines                                                         */
 /******************************************************************************/
 
-void txx9_raw_output(char c)
+#if defined(CONFIG_RAW_PRINTK_OUTPUT) && defined(CONFIG_SERIAL_TXX9_CONSOLE)
+void emit_log_char(char c)
 {
 	struct rs_port *port = &rs_ports[0];
 	if ( c == '\n' )
@@ -1766,3 +1790,4 @@
 	wait_for_xmitr(port);
 	return;
 }
+#endif

--------------D759BFACE4A59D5E54858F16--


From sjhill@realitydiluted.com Wed Sep 10 03:01:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 03:01:09 +0100 (BST)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:26768
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225348AbTIJCBG>; Wed, 10 Sep 2003 03:01:06 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 19wuI4-0003H6-00; Tue, 09 Sep 2003 21:01:04 -0500
Message-ID: <3F5E85DD.1010700@realitydiluted.com>
Date: Tue, 09 Sep 2003 22:01:01 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030908 Debian/1.4-4
X-Accept-Language: en
MIME-Version: 1.0
To: michael_pruznick@mvista.com
CC: linux-mips@linux-mips.org
Subject: Re: PATCH:2.4:tx4927 updates (mostly minor)
References: <3F5E0566.4E0DD26C@mvista.com>
In-Reply-To: <3F5E0566.4E0DD26C@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3146
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips

Hi Michael.

May I ask why you are using 38400 for the baud rate and not
the maximum 57600?

-Steve


From ralf@linux-mips.org Wed Sep 10 09:51:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 09:51:14 +0100 (BST)
Received: from p508B5748.dip.t-dialin.net ([IPv6:::ffff:80.139.87.72]:9131
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225348AbTIJIvM>; Wed, 10 Sep 2003 09:51:12 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8A8p6LT010441;
	Wed, 10 Sep 2003 10:51:06 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8A8p5fS010440;
	Wed, 10 Sep 2003 10:51:05 +0200
Date: Wed, 10 Sep 2003 10:51:04 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030910085104.GA10393@linux-mips.org>
References: <20030909113150Z8225348-1272+5180@linux-mips.org> <Pine.GSO.3.96.1030909153721.18373A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030909153721.18373A-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3147
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Sep 09, 2003 at 03:40:44PM +0200, Maciej W. Rozycki wrote:

> > 	Avoid conflict with glibc on bigendian platforms when -O or higher
> > 	is specified.  It's already in 2.6, and I'm not sure why it hasn't
> > 	been seen in 2.4.  The symptom is that this program will not compile
> > 	with -O2:
> > 	
> > 	#include <asm/byteorder.h>
> > 	#include <netinet/in.h>
> > 	int main () { }
> 
>  Is <asm/byteorder.h> ever included by glibc headers?  I hope not and user
> programs *must* not include kernel headers.  Your program is buggy.

I'd not have accepted such a patch for exactly that reason if it wasn't
already in 2.6.

  Ralf

From ralf@linux-mips.org Wed Sep 10 10:07:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 10:07:54 +0100 (BST)
Received: from p508B5748.dip.t-dialin.net ([IPv6:::ffff:80.139.87.72]:18604
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225348AbTIJJHw>; Wed, 10 Sep 2003 10:07:52 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8A97ZLT010842;
	Wed, 10 Sep 2003 11:07:35 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8A97WR1010832;
	Wed, 10 Sep 2003 11:07:32 +0200
Date: Wed, 10 Sep 2003 11:07:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "??(zhufeng)" <zhufeng@koretide.com.cn>
Cc: linux-mips@linux-mips.org
Subject: Re: about dlltool.exe
Message-ID: <20030910090731.GB10393@linux-mips.org>
References: <Pine.GSO.3.96.1030905182856.1692F-100000@delta.ds2.pg.gda.pl> <MGEELAPMEFMLFBMDBLKLEEGBCFAA.zhufeng@koretide.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MGEELAPMEFMLFBMDBLKLEEGBCFAA.zhufeng@koretide.com.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3148
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Sep 08, 2003 at 08:46:14PM +0800, ??(zhufeng) wrote:

> how can I get dlltoo.exe for mips ? I cross compiled gcc-mips but found
> there is no dlltool.exe . How can I get it? Thanks.

Well, there simply is no dlltool.exe.  This isn't windows.

  Ralf

From ralf@linux-mips.org Wed Sep 10 10:24:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 10:24:28 +0100 (BST)
Received: from p508B5748.dip.t-dialin.net ([IPv6:::ffff:80.139.87.72]:18861
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225348AbTIJJY0>; Wed, 10 Sep 2003 10:24:26 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8A9OJLT011168;
	Wed, 10 Sep 2003 11:24:19 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8A9OJcH011167;
	Wed, 10 Sep 2003 11:24:19 +0200
Date: Wed, 10 Sep 2003 11:24:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "??(zhufeng)" <zhufeng@koretide.com.cn>
Cc: linux-mips@linux-mips.org
Subject: Re: Can gcc support mips-pe now?
Message-ID: <20030910092419.GC10393@linux-mips.org>
References: <3F5D2141.4050002@avtrex.com> <MGEELAPMEFMLFBMDBLKLEEGFCFAA.zhufeng@koretide.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MGEELAPMEFMLFBMDBLKLEEGFCFAA.zhufeng@koretide.com.cn>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3149
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Sep 09, 2003 at 09:06:44AM +0800, ??(zhufeng) wrote:

That's a binutils problem, if at all.  Again, Linux isn't Windows, we
don't need PECOFF.

  Ralf

From AdeelM@avaznet.com Wed Sep 10 10:26:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 10:26:11 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:31906
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225348AbTIJJ0J>; Wed, 10 Sep 2003 10:26:09 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <SBLGY7VL>; Wed, 10 Sep 2003 14:19:25 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38262745C@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: NFS Server and Client Setup on MIPS Platform
Date: Wed, 10 Sep 2003 14:19:24 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3777C.A053F640"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3150
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3777C.A053F640
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
 
         I am using Buildroot-QuickMIPS environment for porting Linux-2.4 to
MIPS Target Platform. I need to Netwrok-Mount the root filesystem and for
this I need to configure the NFS Server on the Host and NFS Client on the
Target.
 
Can someone tell me that what are the steps needed to compile the Buildroot
MIPS kernel for NFS Mounting of MIPS root filesystem ?.
 
I mean what are the configuration settings that need to be made during the
make menuconfig process of MIPS kernel source and then how to make the
zImage with NFS support that could be downloaded on the target system
memory.
 
Regards,
Adeel


------_=_NextPart_001_01C3777C.A053F640
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial" hb_focus_attach="true">
<DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2>Hi All,</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=156471715-09092003><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am using 
Buildroot-QuickMIPS environment for porting Linux-2.4 to MIPS Target Platform. I 
need to Netwrok-Mount the root filesystem and for this I need to configure the 
NFS Server on the Host and NFS Client on the Target.</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2>Can someone tell me that what 
are the steps needed to compile the Buildroot MIPS kernel for NFS Mounting of 
MIPS root filesystem ?.</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2>I mean what are the 
configuration settings that need to be made during the make menuconfig process 
of MIPS kernel source and then how to make the zImage with NFS support that 
could be downloaded on the target system memory.</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=156471715-09092003><FONT size=2>Adeel</FONT></SPAN></DIV></DIV>
<P></P></BODY></HTML>

------_=_NextPart_001_01C3777C.A053F640--

From yuasa@hh.iij4u.or.jp Wed Sep 10 10:38:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 10:39:30 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:56556 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225348AbTIJJi5>;
	Wed, 10 Sep 2003 10:38:57 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id SAA05578;
	Wed, 10 Sep 2003 18:38:54 +0900 (JST)
Received: 4UMDO00 id h8A9cs729393; Wed, 10 Sep 2003 18:38:54 +0900 (JST)
Received: 4UMRO00 id h8A9cqa14352; Wed, 10 Sep 2003 18:38:53 +0900 (JST)
	from pudding.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Wed, 10 Sep 2003 18:38:52 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: [patch] simulate_llsc in v2.4
Message-Id: <20030910183852.2e8248d5.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Wed__10_Sep_2003_18:38:52_+0900_0ab12bc8"
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3151
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Wed__10_Sep_2003_18:38:52_+0900_0ab12bc8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I found a differece between v2.4 and v2.6 in simulate_llsc().

Please apply this patch to v2.4 tree.

Yoichi

--Multipart_Wed__10_Sep_2003_18:38:52_+0900_0ab12bc8
Content-Type: text/plain;
 name="simulate_llsc.diff"
Content-Disposition: attachment;
 filename="simulate_llsc.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c
--- linux.orig/arch/mips/kernel/traps.c	Fri Jul 18 23:16:06 2003
+++ linux/arch/mips/kernel/traps.c	Wed Sep 10 18:34:40 2003
@@ -523,6 +523,8 @@
 		simulate_sc(regs, opcode);
 		return 0;
 	}
+
+	return -EFAULT;			/* Strange things going on ... */
 }
 
 asmlinkage void do_ov(struct pt_regs *regs)

--Multipart_Wed__10_Sep_2003_18:38:52_+0900_0ab12bc8--

From ralf@linux-mips.org Wed Sep 10 11:10:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 11:10:45 +0100 (BST)
Received: from p508B5748.dip.t-dialin.net ([IPv6:::ffff:80.139.87.72]:6832
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225379AbTIJKKn>; Wed, 10 Sep 2003 11:10:43 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8AAAaLT012151;
	Wed, 10 Sep 2003 12:10:36 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8AAAZ0I012150;
	Wed, 10 Sep 2003 12:10:35 +0200
Date: Wed, 10 Sep 2003 12:10:35 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] simulate_llsc in v2.4
Message-ID: <20030910101035.GA11844@linux-mips.org>
References: <20030910183852.2e8248d5.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030910183852.2e8248d5.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3152
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Sep 10, 2003 at 06:38:52PM +0900, Yoichi Yuasa wrote:

> I found a differece between v2.4 and v2.6 in simulate_llsc().
> 
> Please apply this patch to v2.4 tree.

Okay - you missed the same thing also needs to be applied to the 64-bit
kernel.

  Ralf

From ralf@linux-mips.org Wed Sep 10 11:20:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 11:21:01 +0100 (BST)
Received: from p508B5748.dip.t-dialin.net ([IPv6:::ffff:80.139.87.72]:24753
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225348AbTIJKU7>; Wed, 10 Sep 2003 11:20:59 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8AAKwLT012376;
	Wed, 10 Sep 2003 12:20:58 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8AAKviF012375;
	Wed, 10 Sep 2003 12:20:57 +0200
Date: Wed, 10 Sep 2003 12:20:57 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: michael_pruznick@mvista.com, linux-mips@linux-mips.org
Subject: Re: PATCH:2.4:tx4927 updates (mostly minor)
Message-ID: <20030910102057.GB1627@linux-mips.org>
References: <3F5E0566.4E0DD26C@mvista.com> <3F5E85DD.1010700@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F5E85DD.1010700@realitydiluted.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3153
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Sep 09, 2003 at 10:01:01PM -0400, Steven J. Hill wrote:

> Hi Michael.
> 
> May I ask why you are using 38400 for the baud rate and not
> the maximum 57600?

His patch removes the hardwired options - good thing - but anyway, I
still think shipping anything but 9600 8N1 as default is wrong in most
cases - there are still plenty of terminal servers and ancient hardware
terminals in use that just don't support anything else or anything faster.

  Ralf

From yuasa@hh.iij4u.or.jp Wed Sep 10 15:35:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 15:35:57 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:1986 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225360AbTIJOfZ>;
	Wed, 10 Sep 2003 15:35:25 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id XAA10525;
	Wed, 10 Sep 2003 23:35:20 +0900 (JST)
Received: 4UMDO01 id h8AEZKP10333; Wed, 10 Sep 2003 23:35:20 +0900 (JST)
Received: 4UMRO00 id h8AEZIj03413; Wed, 10 Sep 2003 23:35:19 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Wed, 10 Sep 2003 23:35:18 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, yuasa@hh.iij4u.or.jp
Subject: Re: [patch] simulate_llsc in v2.4
Message-Id: <20030910233518.6b945c81.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20030910101035.GA11844@linux-mips.org>
References: <20030910183852.2e8248d5.yuasa@hh.iij4u.or.jp>
	<20030910101035.GA11844@linux-mips.org>
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3154
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

On Wed, 10 Sep 2003 12:10:35 +0200
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Wed, Sep 10, 2003 at 06:38:52PM +0900, Yoichi Yuasa wrote:
> 
> > I found a differece between v2.4 and v2.6 in simulate_llsc().
> > 
> > Please apply this patch to v2.4 tree.
> 
> Okay - you missed the same thing also needs to be applied to the 64-bit
> kernel.

Oh, that's right.

Thanks,

Yoichi

From michael_pruznick@mvista.com Wed Sep 10 17:29:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 17:29:25 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57853 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225360AbTIJQ3X>;
	Wed, 10 Sep 2003 17:29:23 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA21054;
	Wed, 10 Sep 2003 09:29:07 -0700
Message-ID: <3F5F5152.2E8B52C9@mvista.com>
Date: Wed, 10 Sep 2003 10:29:06 -0600
From: Michael Pruznick <michael_pruznick@mvista.com>
Reply-To: michael_pruznick@mvista.com
Organization: MontaVista
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Steven J. Hill" <sjhill@realitydiluted.com>
CC: linux-mips@linux-mips.org
Subject: Re: PATCH:2.4:tx4927 updates (mostly minor)
References: <3F5E0566.4E0DD26C@mvista.com> <3F5E85DD.1010700@realitydiluted.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <michael_pruznick@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3155
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael_pruznick@mvista.com
Precedence: bulk
X-list: linux-mips

> May I ask why you are using 38400 for the baud rate and not
> the maximum 57600?
The PMON f/w I use on my boards defaults to 38400.  Makes my
life easier if the kernel and firmware default to the same
baud rate.  Especially, since I need to reload the f/w often 
to switch between LE and BE.  NOTE: without the console= override,
the driver defaults to 9600.

From michael_pruznick@mvista.com Wed Sep 10 17:49:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Sep 2003 17:49:16 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:42999 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225376AbTIJQtO>;
	Wed, 10 Sep 2003 17:49:14 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA22465;
	Wed, 10 Sep 2003 09:49:12 -0700
Message-ID: <3F5F5607.A094779E@mvista.com>
Date: Wed, 10 Sep 2003 10:49:11 -0600
From: Michael Pruznick <michael_pruznick@mvista.com>
Reply-To: michael_pruznick@mvista.com
Organization: MontaVista
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: "Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org
Subject: Re: PATCH:2.4:tx4927 updates (mostly minor)
References: <3F5E0566.4E0DD26C@mvista.com> <3F5E85DD.1010700@realitydiluted.com> <20030910102057.GB1627@linux-mips.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <michael_pruznick@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3156
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael_pruznick@mvista.com
Precedence: bulk
X-list: linux-mips

> His patch removes the hardwired options - good thing - but anyway, I
> still think shipping anything but 9600 8N1 as default is wrong in most
> cases - there are still plenty of terminal servers and ancient hardware
> terminals in use that just don't support anything else or anything faster.
Since the board's f/w defaults to 38400, you'll need a termal faster than
9600 anyway.  I think this is one of the cases were the 9600 default makes
sense for the driver, but it also makes sense for the board to override it.

From anemo@mba.ocn.ne.jp Thu Sep 11 04:41:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 04:42:20 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:51744
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225316AbTIKDls>; Thu, 11 Sep 2003 04:41:48 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 11 Sep 2003 03:41:45 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h8B3fagc058161
	for <linux-mips@linux-mips.org>; Thu, 11 Sep 2003 12:41:37 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 11 Sep 2003 12:43:50 +0900 (JST)
Message-Id: <20030911.124350.41627177.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Subject: mips64 _access_ok fix
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3157
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

The mips64 _access_ok macro in 2.4 tree returns 0 if 'addr' + 'size'
== TASK_SIZE.

Also, __ua_size macro returus 0 if 'size' is negative constant.  I
think we must not skip checking negative constant.

Here is a fix.  For 2.6 tree, only _access_ok fix will be needed
(__ua_size is already fixed).

diff -u linux-mips-cvs/include/asm-mips64/uaccess.h linux.new/include/asm-mips64/uaccess.h
--- linux-mips-cvs/include/asm-mips64/uaccess.h	Tue Jul 15 20:21:59 2003
+++ linux.new/include/asm-mips64/uaccess.h	Thu Sep 11 12:29:08 2003
@@ -46,10 +46,10 @@
  *  - OR we are in kernel mode.
  */
 #define __ua_size(size)							\
-	((__builtin_constant_p(size) && (size)) > 0 ? 0 : (size))
+	(__builtin_constant_p(size) && (signed long) (size) > 0 ? 0 : (size))
 
 #define __access_ok(addr, size, mask)					\
-	(((mask) & ((addr) | ((addr) + (size)) | __ua_size(size))) == 0)
+	(((mask) & ((addr) | ((addr) + (size) - 1) | __ua_size(size))) == 0)
 
 #define __access_mask get_fs().seg
 
---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Thu Sep 11 05:41:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 05:41:51 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:35109
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225316AbTIKElS>; Thu, 11 Sep 2003 05:41:18 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 11 Sep 2003 04:41:16 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h8B4f9gc058283
	for <linux-mips@linux-mips.org>; Thu, 11 Sep 2003 13:41:10 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 11 Sep 2003 13:43:23 +0900 (JST)
Message-Id: <20030911.134323.03974731.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org
Subject: Re: mips64 _access_ok fix
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030911.124350.41627177.nemoto@toshiba-tops.co.jp>
References: <20030911.124350.41627177.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3158
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Thu, 11 Sep 2003 12:43:50 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> The mips64 _access_ok macro in 2.4 tree returns 0 if 'addr' +
anemo> 'size' == TASK_SIZE.

anemo> Also, __ua_size macro returus 0 if 'size' is negative constant.
anemo> I think we must not skip checking negative constant.

anemo> Here is a fix.  For 2.6 tree, only _access_ok fix will be
anemo> needed (__ua_size is already fixed).

I know this fix is not complete.  __access_ok(0, 0, __access_mask)
will return 0.

I could not find out good expression (i.e. no conditional branch) to
handle this case.

I suppose nobody do take care of this since addr 0 is invalid pointer
anyway.

---
Atsushi Nemoto

From junkio@twinsun.com Thu Sep 11 06:34:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 06:34:52 +0100 (BST)
Received: from alcor.twinsun.com ([IPv6:::ffff:198.147.65.9]:44623 "EHLO
	alcor.twinsun.com") by linux-mips.org with ESMTP
	id <S8225370AbTIKFeU>; Thu, 11 Sep 2003 06:34:20 +0100
Received: from green.twinsun.com ([192.54.239.71])
	by alcor.twinsun.com (8.12.6/8.12.6) with ESMTP id h8B5YFgr031213
	for <linux-mips@linux-mips.org>; Wed, 10 Sep 2003 22:34:16 -0700 (PDT)
Received: from shade.twinsun.com (shade.twinsun.com [192.54.239.27])
	by green.twinsun.com (8.11.7+Sun/8.11.7) with SMTP id h8B5YEW02195
	for <linux-mips@linux-mips.org>; Wed, 10 Sep 2003 22:34:14 -0700 (PDT)
Received: from green.twinsun.com ([192.54.239.71])
 by shade.twinsun.com (SAVSMTP 3.1.0.29) with SMTP id M2003091022341402511
 for <linux-mips@linux-mips.org>; Wed, 10 Sep 2003 22:34:14 -0700
Received: from mae.twinsun.com (mae.twinsun.com [192.207.224.40])
	by green.twinsun.com (8.11.7+Sun/8.11.7) with SMTP id h8B5YEW02192
	for <linux-mips@linux-mips.org>; Wed, 10 Sep 2003 22:34:14 -0700 (PDT)
Received: by mae.twinsun.com (sSMTP sendmail emulation); Wed, 10 Sep 2003 22:34:14 -0700
To: linux-mips@linux-mips.org
Subject: TX49 NAND supported?
From: Junio C Hamano <junkio@twinsun.com>
Date: Wed, 10 Sep 2003 22:34:14 -0700
Message-ID: <7vllsvj3c9.fsf@mae.twinsun.com>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <junkio@twinsun.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3159
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: junkio@twinsun.com
Precedence: bulk
X-list: linux-mips

Does anybody have a working tx4925 NAND driver that can be used
with the latest mtd from infradead CVS?  I have located a copy
of tx4925ndfmc.c with 2002 timestamp by Toshiba Corporation
(GPLv2) but it appears to use an API incompatible with the
current one.  Among other things, it seems to think that struct
nand_chip has fields like IO_ADDR, CTRL_ADDR, CLE, ALE, NCE,
ioread, iowrite, etc, and appears to predate the following
change in include/linux/mtd/nand.h:

 *   10-29-2001 TG	changed nand_chip structure to support 
 *			hardwarespecific function for accessing control lines


From narendrasankar@yahoo.com Thu Sep 11 06:42:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 06:42:45 +0100 (BST)
Received: from smtp803.mail.sc5.yahoo.com ([IPv6:::ffff:66.163.168.182]:55376
	"HELO smtp803.mail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8225370AbTIKFmm>; Thu, 11 Sep 2003 06:42:42 +0100
Received: from adsl-67-122-220-86.dsl.snfc21.pacbell.net (HELO localhost) (narendrasankar@67.122.220.86 with login)
  by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 11 Sep 2003 05:42:38 -0000
Date: Wed, 10 Sep 2003 22:42:37 -0700
From: Narendra Sankar <narendrasankar@yahoo.com>
To: linux-mips@linux-mips.org
Subject: Porting Question - new board. Need some help.
Message-Id: <20030910224237.6bedc0bc.narendrasankar@yahoo.com>
X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <narendrasankar@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3160
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: narendrasankar@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi everyone
I am helping a friend port the kernel to a new board that he has built
with a PMC R5231A cpu. The system controller is a custom design (it has
a standard 16550A uart and the interrupts are directly routed to the
cpu). I am currently working off linux_2_4_21 checked out from CVS.
Following the instructions from Jun Sun
(http://linux.junsun.net/porting-howto/) I get to the following point
where things seem to break -

-----------------------------------------------------------
CPU revision is: 00002831
FPU revision is: 00002830
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32
bytes. 
Primary data cache 32kB 2-way, linesize 32 bytes.
Linux version 2.4.21 (naren@laptop) (gcc version 2.95.4 20010319
(prerelease)) 3 
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
Initial ramdisk at: 0x80276000 (1765376 bytes)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,115200 kgdb=ttyS0,115200
ramdisk_size=8192 root=/dev/ram*
Calibrating delay loop... 748.74 BogoMIPS 
Memory: 61092k/65536k available (705k kernel code, 4444k reserved, 1848k
data, ) 
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes) 
Mount cache hash table entries: 512 (order: 0, 4096 bytes) 
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) 
Page-cache hash table entries: 16384 (order: 4, 65536 bytes) 
Checking for 'wait' instruction... available. 
POSIX conformance testing by UNIFIX 
Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer
Society NET3.039 
Starting kswapd 
pty: 256 Unix98 ptys configured 
Serial driver version 5.05c(2001-07-08) with no serial options enabled
Generic MIPS RTC Driver v1.0 
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices) 
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1724k freed 
VFS: Mounted root (ext2 filesystem) readonly. 
Freeing unused kernel memory: 48k freed 
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
-------------------------------------------------------

I am using the big-endian ramdisk from the debian mips distribution for
test purposes. However I do not get to any sort of console prompt. The
system just seems to hang at that point. (Using the QED ITE board, I get
to the point where the debian setup starts.)

The toolchain used to build the kernel is the mips-linux toolchain from
ftp.linux-mips.org-

Reading specs from /usr/lib/gcc-lib/mips-linux/2.95.4/specs
gcc version 2.95.4 20010319 (prerelease)

Trying to debug using kgdb, I can break right before the execve of
/sbin/init. However I cannot step or debug beyond that point. (Using gdb
5.3 built with target=mips-linux). So I know that I get to the exec of
init. However beyond that I do not know what is happening. Using printks
I determined that the system at least enters load_elf_binary.

Anyone have any ideas where I can look for what is going wrong? Also I
am wondering why I cannot use gdb to step into execve? I followed the
porting guide instructions in order to set up kgdb. I can break and step
before the call to init but nothing after that.


Thanks a lot for any help

Naren Sankar




From durai@isofttech.com Thu Sep 11 07:06:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 07:06:22 +0100 (BST)
Received: from [IPv6:::ffff:203.199.202.17] ([IPv6:::ffff:203.199.202.17]:17169
	"EHLO pub.isofttechindia.com") by linux-mips.org with ESMTP
	id <S8225370AbTIKGGT>; Thu, 11 Sep 2003 07:06:19 +0100
Received: from ghgp8w6dvrof4f ([192.168.0.107])
	by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id h8B637t03755
	for <linux-mips@linux-mips.org>; Thu, 11 Sep 2003 11:33:07 +0530
From: "durai" <durai@isofttech.com>
To: <linux-mips@linux-mips.org>
Subject: unresolved symbol dptoli
Date: Thu, 11 Sep 2003 11:33:07 +0530
Message-ID: <BLEMJDCPNEFOILECKALMMEDICAAA.durai@isofttech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <durai@isofttech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3161
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: durai@isofttech.com
Precedence: bulk
X-list: linux-mips


hi,
i compiled a wireless lan driver using the mips-linux-gcc compiler 2.95.3.
When i try to insmod the driver i got the following errors. any ideas?

insmod: unresolved symbol dptoli
insmod: unresolved symbol dpmul
insmod: unresolved symbol litodp

Note that, i havent used any of these above functions in my code. It appears
only in the .o files


Durairaj P
Senior Software Engineer
Integrated SoftTech Solutiond Pvt. Ltd
Chennai 600 018
India
Tel : +91(44)2436 4915 Ext 88
www.isofttech.com


From guangxing@ict.ac.cn Thu Sep 11 03:13:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 12:23:29 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:42174 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225363AbTIKCNi>;
	Thu, 11 Sep 2003 03:13:38 +0100
Received: (qmail 17527 invoked from network); 11 Sep 2003 02:00:42 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 11 Sep 2003 02:00:42 -0000
From: "=?GB2312?Q?=B9=E3=D0=C7?=" <guangxing@ict.ac.cn>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
CC: angela <jhyang@ict.ac.cn>,
	=?GB2312?Q?=D0=BB=B2=A9=CA=BF?= <xie@ict.ac.cn>
Subject: Some  Question about the kernel module on MIPS64
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: multipart/related;
      boundary="=====001_Dragon736316147414_=====";
      type="multipart/alternative"
Date: Thu, 11 Sep 2003 10:13:58 +0800
Message-Id: <20030911021338Z8225363-1272+5279@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3162
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--=====001_Dragon736316147414_=====
Content-Type: multipart/alternative;
      boundary="=====002_Dragon736316147414_====="


--=====002_Dragon736316147414_=====
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: quoted-printable


 
   Hi, everyone!
   I am a newbie on doing some development on MIPS(of course it=
 is the linux make me can touch it without any  hesitation).There=
 are two questions  as follow hoping your enthusiastic answers.
   1) I want to know if the linux for mips64 support the=
 customer's kernel module .if yes, is there any modutils i can=
 use?And how can i get it.
   2) I have written a simplest simplest kernel module for linux=
 for mips64 (only the init()and cleanup() we can see,and we do=
 nothing.) and with the crossing compiling tool it is ok.One=
 thing confused me is that it can be "insmod" in the linux for=
 mips32, but when we try to "insmod" in the linux for mips64, we=
 get the following error:
[root@(none) root]# insmod try.o
init_module: Invalid module header size.
A new version of the modutils is likely needed.
try.o: init_module: Invalid argument
Hint: insmod errors can be caused by incorrect module parameters,=
 including invalid IO or IRQ parameters
Of course we do the above works in the same hardware platform .
Is there any thing I should pay attention to when I compile the=
 Kernel Module or the linux for mips64? Eagering your help!!
Thank you  you in advance!
    

=A1=A1=A1=A1
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D7=A3
  =BF=AA=D0=C4!
     Far and away the best prize that life offers is the chance=
 to work hard at work worth doing. =B9=E3=D0=C7
guangxing@ict.ac.cn
2003-09-11
           \\\|///
          \\ - - //
           ( @ @ )
--------oOOo-(_)-oOOo---------

       =B9=E3=D0=C7=D7=A3=C4=FA=D3=E4=BF=EC=BD=A1=BF=B5
               0ooo
-------- oooO--(   )----------
        (   )   ) /
         \ (   (_/
          \_)
=A1=A1



 

--=====002_Dragon736316147414_=====
Content-Type: text/html;
      charset="GB2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>=B5=AD=D1=C5=D6=AE=C2=CC</TITLE>
<META content=3D"text/html; charset=3Dgb2312"=
 http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3806.1700" name=3DGENERATOR>
<STYLE type=3Dtext/css>
<!--
td {  font-family: "=CB=CE=CC=E5"; font-size: 14px; color: #000000;=
 font-weight: normal}
-->
</STYLE>
</HEAD>
<BODY bgColor=3D#79bb87 leftMargin=3D0 text=3D#000000 topMargin=3D0>
<DIV align=3Dcenter>
<TABLE background=3Dcid:__0@Foxmail.net border=3D0 cellPadding=3D0=
 cellSpacing=3D0 
height=3D90 width=3D640>
  <TBODY>
  <TR>
    <TD>
      <TABLE align=3Dcenter border=3D0 cellPadding=3D0 cellSpacing=3D0=
 width=3D"90%">
        <TBODY>
        <TR>
          <TD>
            <DIV>&nbsp;</DIV>
            <DIV></DIV></TD></TR>
        <TR>
          <TD>&nbsp;</TD></TR>
        <TR>
          <TD>
            <P><FONT size=3D2>&nbsp;&nbsp; Hi,=
 everyone!</FONT></P>
            <P><FONT size=3D2>&nbsp;&nbsp; I am a newbie&nbsp;on=
 doing some 
            development on MIPS(of course&nbsp;it is the linux 
            make&nbsp;me&nbsp;can touch it without any=
 &nbsp;hesitation).There 
            are two questions&nbsp; as follow hoping your=
 enthusiastic 
            answers.</FONT></P>
            <P><FONT size=3D2>&nbsp;&nbsp; 1) I want to know if the=
 linux&nbsp;for 
            mips64 support the customer's&nbsp;kernel=
 module&nbsp;.</FONT><FONT 
            size=3D2>if yes,&nbsp;is there any modutils i can=
 use?And how can i 
            get it.</FONT></P>
            <P><FONT size=3D2>&nbsp;&nbsp; </FONT>2) I have written=
 a simplest 
            simplest&nbsp;kernel module for linux for mips64=
 (only the init()and 
            cleanup() we can see,and we do nothing.) and with the=
 crossing 
            compiling tool it is ok.One thing confused me is that=
 it can be 
            "insmod" in the linux for mips32, but when we try to=
 "insmod" in the 
            linux for mips64, we get the following error:</P>
            <P><STRONG>[root@(none) root]# insmod=
 try.o<BR>init_module: Invalid 
            module header size.<BR>A new version of the modutils=
 is likely 
            needed.<BR>try.o: init_module: Invalid=
 argument<BR>Hint: insmod 
            errors can be caused by incorrect module parameters,=
 including 
            invalid IO or IRQ parameters</STRONG></P>
            <P>Of course we do the above works in the=
 same&nbsp;hardware 
            platform .</P>
            <P>Is there any thing I should pay attention to when=
 I compile the 
            Kernel Module or the linux for mips64? Eagering your=
 help!!</P>
            <P>Thank you  you in advance!</P>
            <P><STRONG>&nbsp;&nbsp;&nbsp; 
 =
 </STRONG></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE=
>
<TABLE background=3Dcid:__1@Foxmail.net border=3D0 cellPadding=3D0=
 cellSpacing=3D0 
width=3D640>
  <TBODY>
  <TR>
    <TD>
      <TABLE align=3Dcenter border=3D0 cellPadding=3D0 cellSpacing=3D0=
 width=3D"90%">
        <TBODY>
        <TR>
          <TD>
            <DIV><FONT size=3D2>=A1=A1=A1=A1</FONT></DIV>
            <DIV>
            <DIV>
            <DIV></DIV>
            <DIV>
            <DIV><FONT size=3D2>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D7=A3<BR>&nbsp;=
 =BF=AA=D0=C4!</FONT></DIV></DIV></DIV>
            <DIV></DIV></DIV>
            <DIV></DIV>
            <TABLE align=3Dcenter border=3D0 cellPadding=3D0=
 cellSpacing=3D0 height=3D86 
            width=3D"80%">
              <TBODY>
              <TR>
                <TD rowSpan=3D3 width=3D"50%">
                  <DIV><FONT=
 size=3D3>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Far and away 
                  the best prize that life offers is the chance=
 to work hard at 
                  work worth doing. </FONT></DIV></TD>
                <TD>
                  <DIV><FONT size=3D2>=B9=E3=D0=C7</FONT></DIV></TD></TR>
              <TR>
                <TD>
                  <P><FONT size=3D2><A 
                 =
 href=3D"mailto:guangxing@ict.ac.cn">guangxing@ict.ac.cn</A></FONT>=
</P>
                  <P>2003-09-11</P></TD></TR>
              <TR>
                <TD>
                 =
 <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 
                 =
 \\\|///<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 
                  \\ - - 
                 =
 //<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 
                  ( @ @ 
                 =
 )<BR>--------oOOo-(_)-oOOo---------<BR><BR>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 
                  &nbsp;<A 
                 =
 href=3D"http://www.foxmail.com.cn/">=B9=E3=D0=C7=D7=A3=C4=FA=D3=E4=BF=EC=BD=A1=BF=B5</A><BR>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 
                  0ooo<BR>-------- oooO--(&nbsp;&nbsp; 
                 =
 )----------<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
                  (&nbsp;&nbsp; )&nbsp;&nbsp; ) 
                 =
 /<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \ 
                  (&nbsp;&nbsp; 
                 =
 (_/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
                  \_)<BR>=A1=A1</P>
                  <P 
     =
 align=3Dleft>&nbsp;</P></TD></TR></TBODY></TABLE></TD></TR></TBODY=
></TABLE></TD></TR></TBODY></TABLE>
<TABLE background=3Dcid:__2@Foxmail.net border=3D0 cellPadding=3D0=
 cellSpacing=3D0 
height=3D40 width=3D640>
  <TBODY>
  <TR>
    <TD>&nbsp;</TD></TR></TBODY></TABLE></DIV></BODY></HTML>

--=====002_Dragon736316147414_=====--

--=====001_Dragon736316147414_=====
Content-Type: image/gif;
      name="greenmail01.gif"
Content-Transfer-Encoding: base64
Content-ID: <__0@Foxmail.net>

R0lGODlhgAJkALMAAMveuWumeHm7h97o1dbjyKrVoc7kyc/gv1F9Wrvbs5WzjbLYqsHeu7XKp5rE
lKLNmiH5BAAAAAAALAAAAACAAmQAAAT/UMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt33iu73zv
/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/
gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp1gBqqusra6vsLGys7S1tre4
ubq7vL2+v8DBwsPExcbHyMm/RasIzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3irECq
zqoODg8F+Pn6+/z9/v8AAwocSLCgwYMIEypcyLChw4cQI0qcSLGixYsFHzxQEOCZqh4d/xE0AECy
pEmTBU6qXAkgJcuXLWG+dClTJc2aKHHa1HnyJk+fOoHiFFqTqEyjMJHO5JmTKUmlLKGulLrTaUyr
VHtaveo0a9OuW72WVHrgQIN5OzoqOPAzrFusb8HCnSu3LlOxT+Pe1duW7l6/fe0G/is4KF/DgBHL
PEBAAYIAOdSyHUxZMeHLlYce1pyYc2HPmC1nLrqZdGfTn1GHBj36aGnXPB1DtrHqNOzUt1erbp30
dW/bv3EH152b91Lgx4UnJz7ceFTfy52bPPD4RseRyp8j1559KnTuzKOLHs+a/G7zxdE3Vy++vPvz
79PHXz9/5dnZNDqWLkug/4D//xHAAP8BZYUHnnRVdZeggd5t16CCWjm4IIIRQvgVgxOyd6CGD2JY
oYckUYffDB1NhhljAKaoogEpEmhie/DFKJ+M9NEI44w41pjjjTr2yOOPG9YXpI1D7likj0cCqdIq
+T32FooqRgkgi1ESiGSHFF6Y5VjfYclhhkJ6GSaYRIpZJplGmpkmmleyqaSbSa7kWA0dORAWlFLm
SaWUVqrZ5odb5iUhoF8SOqahZyK6pqJ/almoo4dCmqiki1LaKJdOOVAdDQjYaVUCeYb63555EuDn
m4yiaqmqmFrYKoivBsoVrIK6Wiuts8qKV66PxtrrrVuatakMHT3g1AEDkFplf2U1S0D/AgSI+t+L
vEbqq7XA/lrtpNdymy2221barbjfehvupeWSey6r6aK77koJDBtDR15Fmyyf1EaIJ5+rxnmqv3D+
K3DABKcKsMEDI1xwvwkzvPC47u4qcZcPt/uSvDDQy5O99wLYH2v7tggxu+82PPLBDiuscsosn2yy
xSi7XHHJM088aMswv0zzyiVh/ILGNe27p6nkhRxgzjVTzDPSS++Ms9MyN22zrVAz/fTUuGKtq9JP
++wC0DJxPOoARLeGbJVVp621tmuD27a5b6sbd8RcR3113VbbrXfeJHndAtgsGV2gcEYTMDfJh8fM
t9p4M37z3o5TnbjOkyf9+OK7+s0C/+AriQ3gAtAZDfrlkWfdeOVSn6466ajfzfrqkjeu+Qqcn+T5
f6UH7rkB+cINu+mvBx+78MAPb3zxyG9t1ewq1F7S2SqyBVWz1EsF/ahlK3+89smz/Tv34HtPfPhu
f68T8ynQ+w8DBrTv/gICLZAAAwe43/4BDMAfv/3t64/R/wAMoAAHSMACGvCACEygAguCPhQ4DwC3
K5tQjJYiFmXvemQjCccsuD3xdbB84/Ng90D4Qd+FkIQjrEkDT+A8DGbQV7eLEpXK5jkTTWlaKZSb
+VBIPhOWUIcn9GEO6RZEmazQBM673Yt8EkMZeowkUZrO2F4owh4C8YdExCLidihEK/9mcYhbXN6I
MoYAoLgwe1yhoJRIVRYVXXCKAwCj4nJXxTry0I5dxOMV5Ug5LqrriCWonRIr1ESP2UtZnkNjtPbU
uzm2DnKPxJwfv+jFMGrRkZO0JB9VAkgSCNKNVSlknwBQPxdG7yTIGlolMVlESurRlXeMZR5lucdV
9lGMTfKJC/OVkiaO0iQLKGQcUdkxKs7ymLV8pSZtablL3tKZzdxk6nBJojLaLoo2MaUxe6LNbWpQ
lcpkJTSnOU7XlROSmRSnNM25zp6N8WfWNEkip1Kq3jSxdwQAJy1hiUx+JnOfywznM9spyVYGFCed
HAHgdgkvfv0mTyzJ5xMFGk1mkpP/oHQEqDotyk6OotOgLEmoCBYapd6d0TQRjKg++3lQlm6Uohf1
aEHPOVOMRjKjKnzn1+KpQWzaTlkDaGRTUtq5lf7TpQOVKU6PylR/OrWlTYXqU0Oq07/xFIKgVIlE
RYbSkqp0ohpNKkw7OtaP0nSpUxVrWCta1r5VdXNXnScxlSXUoWa1qGBFKlvXGtO2olWqgH0pX8k6
WLMyRaQhABzarkkqNB5Hrng9ml9vStl0qlWvfS1sTZVaWZCuBLEgUOxdS7LIFNXVrqZ9yVa9GdjL
RlWwmCVsbA3LWcvudbaLA+0HRMtVk8AxqIgZ7Vzz+lrXpvW2xUXucTOL27/CNrnM/zXiW2kXV+Ge
jVRtwaBjn1fM08oWut9dbnhbq1zyRle8tJ2s7KbbvOr2NkRw3O5zaqjaYtrUtuc173ifi97Nqtez
5eXvxdibvjLqg332S8A+FsA/AyjYIPWzn//4EeH2MWCBGM6whjfM4Q57+MMgXohuPQA4yMK3mPKd
iomJ2THv7te4+k2vZp0LYwHbuMY4DnCOTzLiDpTYuvH9yYrlObYU31jHSM7vkZW84xcn2clMfrKM
c5pLKZ6SuyjmCaiurNUbuhjKYJ4yeMXcXxpL2b8z7uxZM0dgB14VAF7FslFfUj+fqqSCRl5ymNHc
XDXfF8BRDvSezSxod1aZyO+9bv9qa7JayXZ5Sl8etJ9rC2hJ49fSlSZzjPks3UOTVri/zTNWEdk5
FSXg0prWc6qbvOozExrTa0Y1p2HSYw5wjqGfpitMDsllLHts0v+NdaZnvelXt7rQxFZ1sj/bZha+
GauJLiaATFrBXkM7RcZetquBnWZZZ/vb3O6zt9ns6U/3utGGdNbu7mo0bSMb3OOO97DhPe9wj9nd
Jqn1Bpy32BABVVq/DZB/3DgZe5fZ4MVGuLLpLeyG/9kp+tZAEuNMki0D3LT/xtexYf3wjlPa4R/3
eLBxFfEMPLDfLREmwQHAgIujUeGsxvfGZy7zmjNc5N2u91ZKjoEHEjUmKg/QZCz/XipeyhvkIw+5
0pPO9JyflecXeOC1py0oNZJtib58EfRaLup3w3zbR8e5uHVOdqQjtNlIfLavU3sTxtirP7/My8Dh
Tq3rsSjSNv+618O+dKeL/d43lxXULSB1UkrpAEYRqi5XgkHelf3vB+d708dudspjdPAVKPzUAXTq
7biw85UHvN453nfLl170kj97uSMqw66nKoKjp3ngJ4/6x58+8rbXFuYpoPmeVjvuOCrc7P1++4Sn
3vS0x33oaY32QBp4IAhucP4YsoDo2+/CIc6+9rfP/e57//sh3v0Eem9uaV99N2qU4PFrv3zj5574
yXf/05vvSbXTOeAeUzwprW7M/9jnff3KB3nyJ4AL539pI34SQH7TgW58Andw13LSEncGOIEAOIDF
V4AViIHzhoACoIAnQXQXh3/C9X/vh3zwd4ImmILsR4DMtnqGEXQrEirAR4Ltp4E1GHPDp4IBeIE6
w4Ee+BX8V21uNIOyR4EluII8CHZHuIPxR1UuCDIDFyqN5WJGeINKaIV7t4QW2IQ46IP2F3xu54D9
AS2Dw4VXyIJnmIRZiIWkZ4Y8Rn8K9YVMiIJI6IZtSIdzqINbOGNeWIVouIZ/eId6aIOBWITe1ocZ
iIN+qIaCWId4uIeD2IVwOFJyCImOGIlpaIeGqIWEyIiyh4icqIiJmImP2ImaSHCDhWhzoMiGm8iK
qOiJr3iKOXiJgLeKqTiLeUiLubiLlsiLpsiHk5hYlfiLmAiIsIiLvZiMxKiLxWaLx7iIsgiNpSiK
oUiKxZhvwRhaw0iNroiMy+iL3HiL0niNkOOM0TiKxniO1ZiO02iNzOiEIRABADs=

--=====001_Dragon736316147414_=====
Content-Type: image/gif;
      name="greenmail02.gif"
Content-Transfer-Encoding: base64
Content-ID: <__1@Foxmail.net>

R0lGODlhgAIUAKIAAMveuarVoXm7h2ymeFF9WgAAAAAAAAAAACH5BAAAAAAALAAAAACAAhQAAAP/
KLrcOyTISau9OOvNu/9gKI5kaZ5oqq5s675wLFfE4Nx47kAB4P/AILAnLAaJxiQyWVwyj0+jM+qb
Uq1R7FPL5CqpQq8UDCX/xE3zWV1lA9BhN7ysng/leLZ9za7p/oAPEXl1hGZ7bXqGZIhvi2CNkY9X
k1mVW5ddmV+KnYWeh5tGfoGlODyiaaCMqXGrkK10oa+UtJa2mLiaupyfvrO/rLxjw0WkpsiCksWu
wbDMssLOtdO31bnXu9m9wN3S3s/bxOKq5M1mx8nIqNB37Xzm0eHg1PTW9tj42vrc3/7z/+oFvDcw
X8F9B5OkU1eKXTx3D+HxGzexXMVzCSlmtLgR/yPAjwJBEhRpkCRCk/1QagSzkCEghxflhZw5kmZJ
mydxptS5kidHlT99ehQqs6bRm0dzJt25dJQNl6ZgdiyKtKpSq0yx9mwalOtQr1Svis06dqvWrme/
pg1Ltq1ZJi2h5pAKVG1ZtHftusW7V+/bvmz/CuY72C/hw4YTB0a8WDHEmI/JxJV7gy7RyHUba8Z8
WeJUzmBBrxWdd7PnzKQBpy5sOlFE15BPd/YxmXIDy6Fl54b9Wfdo36VXMxbuGLhq46yJt3b0jjdq
5MOhF3c+G0Bt28piKd8uffmy18zBf49NfXd48ud7l/+9Pnh37u2Px0/+4zp2AbjZp38+P3r/6bz7
VTeeegGaNyB/Bep3oIDavefgf965YR92+bkHIXwJWpihfBvSd+GDHfoXIoALGtjghyiOGGFzKmLY
yIS2VchhiQqe2CKINGqY44w27ujhjSn6KKKQJNoII2Uy/kjkiuL16CSLS7r4ZJNQTolelDhK+NR9
pwxS5ZdUhnmllQRiGSSZCJoJ5Jpqtqkll3N5KWaZaDII5ph30plnmnWauKed4B0pV5JD9lnjn37O
ySeihyoKKJ6OJoqeoAskAAA7

--=====001_Dragon736316147414_=====
Content-Type: image/gif;
      name="greenmail03.gif"
Content-Transfer-Encoding: base64
Content-ID: <__2@Foxmail.net>

R0lGODlhgAIoALMAAHm7h2eTblF9WmumeFmKY5SujHSzgnCtfW2pelSCXmmidcveuarVobfMqMHV
sajDnSH5BAAAAAAALAAAAACAAigAAAT/EMhJ6zyB6c27/2AojmRpnmiqrmzrvnAsz3Rt33iud8Fh
/cCgBZFgLI7IpDJpXDqVzac0KnVSq1Ds86o9crtfbRg7rpan3eV5m862kWvrGz731hdx9T3vnvOZ
e4F1f3R1CQhCiYoTAwKEdoOCfpJvj3iUbZaamGmbkZ+ToJWcYKRipmSoZqpodQIDi7FBjZ6htqOi
maxsuZ27cr2lwafDqcWrx623usm8y77NTq+y1BW0v3rR2c/C3MTexuDI4sq45M7m6cznwOzb6tDu
ffBd09X319rz6/Tf/eH/xgUsx69gvIHoDHZD2I7hO4X+IAKUKJCiFHv3qOWTB0hfR46F/0BCEnnJ
Y0iH+w5aTKiy5cKVDWE+dBmR5kSbVTBmjLUR5UefJ2WmfImTYFGWRJPWVHqTacWjMaHOdGqUKtKl
WJtq0blTEQJH2IZmfWo1atmpY6umvaq1Ldm1ZuGidauWLtu3duPmnYtXioNDXWUReRD2p1DDUsXu
Vdy3buO7jiNDnqz3cWXJlynzxbxZM2POn500ABx40QECBQoHTYz4bOjMsDvHfi27Nu3breXiXu06
92Lflm0DBz3cM5IHBHyUVnQageqRQKEf5q27+Gzrwqn/1h58t3TW3ImHNz7+evns33ufT1Ig+XJF
BgIEeF6SZK3o9fHfn56++nrs3uXHn/+A4PW3nYHdAajgfwwi+IR8BryniAIC0LdfgQSq5yB5G5rX
IXoZ+vdhgBdqGOKBJybYYIrijbigi0ckoICEXhHQgEkw5sgihzt62COIJYr4I4kWFonjkC8iuWKQ
KDL5RAMEIEKjEPHNZ5+RVx7pZItK6rglj1/6GCaQWOpX5nQQTpkIAqhl6aaZWp6J4ZhExmnnmwPS
maSeS77RnpRqBmGAAgmklqecJvLpJaJCKtrlo45GymiTk6o4YgEyRhgolQoQEMCNiVbKpaR3wonn
nKKCmaqYq5IZTQMBEKCApptSiUCsAgRQwAMNOKBqqYcCi6qwoRLbaKt1nlqssks50MD/AwUEkICn
CNBaayIGIKBArAQkkIAA4IYr7rjklmvuueimq+667Lbr7rvwxivvvPTWa++9+Oar77789uvvv+16
S4CnClR77T0GHHAAAggM4PDDEEcs8cQUV2zxxRhnrPHGHHfs8ccghyzyyCSXbPLJKKes8sost7wx
wwpbe/DMNNds880456zzzjz37PPPQAct9NBEF2300UgnrfTSTDft9NNQRy311FRXbfXVWGet9dZc
d+3112CHLfbYZJdt9tlop6322my37fbbcMct99x012333XjnrffefPft99+ABy744IQXbvjhiCeu
+OKMN+7445BHLvnklFdu+eWYZ675GOacd+7556CHLvropJdu+umop6766rFEAAA7

--=====001_Dragon736316147414_=====--



From bruno.randolf@4g-systems.biz Thu Sep 11 15:05:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 15:05:16 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.171]:39141
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225370AbTIKOFQ> convert rfc822-to-8bit; Thu, 11 Sep 2003 15:05:16 +0100
Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 19xS4Q-0001to-00
	for linux-mips@linux-mips.org; Thu, 11 Sep 2003 16:05:14 +0200
Received: from [80.129.137.45] (helo=192.168.1.21)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 19xS4Q-0000SI-00
	for linux-mips@linux-mips.org; Thu, 11 Sep 2003 16:05:14 +0200
From:	Bruno Randolf <bruno.randolf@4g-systems.biz>
Organization: 4G Mobile Systeme
To:	linux-mips@linux-mips.org
Subject: cache coherent io on au1500
Date:	Thu, 11 Sep 2003 16:05:12 +0200
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <200309111605.13050.bruno.randolf@4g-systems.biz>
Return-Path: <bruno.randolf@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3163
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello!

i have an Au1500, silicon stepping AD (mtx-1 board) which as far as i 
understand should be able to do cache coherent io. but if i change 
CONFIG_NONCOHERENT_IO to "n" compilation of 2.4.21 fails with 

mipsel-linux-gcc -D__KERNEL__ -I/data/kernel/mtx-2.4.21/include -Wall 
- -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
- -fomit-frame-pointer -I /data/kernel/mtx-2.4.21/include/asm/gcc -G 0 
- -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap   -nostdinc 
- -iwithprefix include -DKBUILD_BASENAME=fork  -c -o fork.o fork.c
In file included from fork.c:20:
/data/kernel/mtx-2.4.21/include/linux/vmalloc.h: In function `vmalloc':
/data/kernel/mtx-2.4.21/include/linux/vmalloc.h:36: `_CACHE_CACHABLE_COW' 
undeclared (first use in this function)
/data/kernel/mtx-2.4.21/include/linux/vmalloc.h:36: (Each undeclared 
identifier is reported only once
/data/kernel/mtx-2.4.21/include/linux/vmalloc.h:36: for each function it 
appears in.)
/data/kernel/mtx-2.4.21/include/linux/vmalloc.h: In function `vmalloc_dma':
/data/kernel/mtx-2.4.21/include/linux/vmalloc.h:45: `_CACHE_CACHABLE_COW' 
undeclared (first use in this function)
/data/kernel/mtx-2.4.21/include/linux/vmalloc.h: In function `vmalloc_32':
/data/kernel/mtx-2.4.21/include/linux/vmalloc.h:54: `_CACHE_CACHABLE_COW' 
undeclared (first use in this function)
make[2]: *** [fork.o] Error 1

how could i fix that?

thanks,
bruno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/YIEZfg2jtUL97G4RAm0pAJ47FLT9fJaNWIqE0gHJ5zsPlZhPngCfY+AY
ZOEDI2hvDJ/zbdk98TzCm9k=
=FcHD
-----END PGP SIGNATURE-----


From ralf@linux-mips.org Thu Sep 11 15:06:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 15:06:25 +0100 (BST)
Received: from p508B58B4.dip.t-dialin.net ([IPv6:::ffff:80.139.88.180]:22446
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225370AbTIKOGZ>; Thu, 11 Sep 2003 15:06:25 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8BE6BLT015678;
	Thu, 11 Sep 2003 16:06:11 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8BE69Ad015677;
	Thu, 11 Sep 2003 16:06:09 +0200
Date:	Thu, 11 Sep 2003 16:06:08 +0200
From:	Ralf Baechle <ralf@linux-mips.org>
To:	durai <durai@isofttech.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: unresolved symbol dptoli
Message-ID: <20030911140608.GA15365@linux-mips.org>
References: <BLEMJDCPNEFOILECKALMMEDICAAA.durai@isofttech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BLEMJDCPNEFOILECKALMMEDICAAA.durai@isofttech.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3164
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Sep 11, 2003 at 11:33:07AM +0530, durai wrote:

> i compiled a wireless lan driver using the mips-linux-gcc compiler 2.95.3.
> When i try to insmod the driver i got the following errors. any ideas?
> 
> insmod: unresolved symbol dptoli
> insmod: unresolved symbol dpmul
> insmod: unresolved symbol litodp
> 
> Note that, i havent used any of these above functions in my code. It appears
> only in the .o files

These are symbols used by gcc's software fp code.  Don't use floating
point in kernel code.

  Ralf

From ralf@linux-mips.org Thu Sep 11 15:16:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 15:16:33 +0100 (BST)
Received: from p508B58B4.dip.t-dialin.net ([IPv6:::ffff:80.139.88.180]:64430
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225370AbTIKOQd>; Thu, 11 Sep 2003 15:16:33 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8BEGVLT015881;
	Thu, 11 Sep 2003 16:16:31 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8BEGTxF015880;
	Thu, 11 Sep 2003 16:16:29 +0200
Date:	Thu, 11 Sep 2003 16:16:29 +0200
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: mips64 _access_ok fix
Message-ID: <20030911141629.GB15365@linux-mips.org>
References: <20030911.124350.41627177.nemoto@toshiba-tops.co.jp> <20030911.134323.03974731.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030911.134323.03974731.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3165
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Sep 11, 2003 at 01:43:23PM +0900, Atsushi Nemoto wrote:

> I know this fix is not complete.  __access_ok(0, 0, __access_mask)
> will return 0.
> 
> I could not find out good expression (i.e. no conditional branch) to
> handle this case.
> 
> I suppose nobody do take care of this since addr 0 is invalid pointer
> anyway.

That behaviour of __access_ok() is actually ok;  __access_ok only needs
to return non-zero only for addresses >= TASK_SIZE.  For two reason
the case you're mentioning is not a problem.  As you say 0 is (usually)
a bad pointer value so if the kernel tries to dereference it, an
TLB exception is going to happen and the exception handling code will
deal with the case.  Second the size argument is zero and after all
that means the kernel won't touch the address range anyway because
hey, it's zero-length!

  Ralf

From ralf@linux-mips.org Thu Sep 11 15:26:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 15:26:16 +0100 (BST)
Received: from p508B58B4.dip.t-dialin.net ([IPv6:::ffff:80.139.88.180]:36015
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225389AbTIKO0Q>; Thu, 11 Sep 2003 15:26:16 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8BEQDLT016090;
	Thu, 11 Sep 2003 16:26:13 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8BEQBWO016083;
	Thu, 11 Sep 2003 16:26:11 +0200
Date:	Thu, 11 Sep 2003 16:26:11 +0200
From:	Ralf Baechle <ralf@linux-mips.org>
To:	???? <guangxing@ict.ac.cn>
Cc:	linux-mips@linux-mips.org, angela <jhyang@ict.ac.cn>, xie@ict.ac.cn
Subject: Re: Some  Question about the kernel module on MIPS64
Message-ID: <20030911142611.GC15365@linux-mips.org>
References: <20030911021338Z8225363-1272+5279@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030911021338Z8225363-1272+5279@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3166
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Sep 11, 2003 at 10:13:58AM +0800, ???? wrote:

>    1) I want to know if the linux for mips64 support the customer's
>       kernel module .if yes, is there any modutils i can use?And how
>       can i get it.

There is currently no module support for mips64.

>    2) I have written a simplest simplest kernel module for linux for
>       mips64 (only the init()and cleanup() we can see,and we do nothing.)
>       and with the crossing compiling tool it is ok.One thing confused
>       me is that it can be "insmod" in the linux for mips32, but when we
>       try to "insmod" in the linux for mips64, we get the following error:
> [root@(none) root]# insmod try.o
> init_module: Invalid module header size.
> A new version of the modutils is likely needed.

True.

> try.o: init_module: Invalid argument
> Hint: insmod errors can be caused by incorrect module parameters,
> including invalid IO or IRQ parameters
> Of course we do the above works in the same hardware platform .
> Is there any thing I should pay attention to when I compile the Kernel
> Module or the linux for mips64? Eagering your help!!

The problem isn't the kernel but modutils which don't support kernel
modules for 64-bit kernels.

  Ralf

From kaos@ocs.com.au Thu Sep 11 15:36:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 15:36:46 +0100 (BST)
Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:40202 "HELO
	mail.ocs.com.au") by linux-mips.org with SMTP id <S8225389AbTIKOgq>;
	Thu, 11 Sep 2003 15:36:46 +0100
Received: (qmail 29807 invoked from network); 11 Sep 2003 14:36:37 -0000
Received: from ocs3.intra.ocs.com.au (192.168.255.3)
  by mail.ocs.com.au with SMTP; 11 Sep 2003 14:36:36 -0000
Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331)
	id 354D7C00A9; Fri, 12 Sep 2003 00:36:36 +1000 (EST)
Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1])
	by ocs3.intra.ocs.com.au (Postfix) with ESMTP
	id 31D4C14010C; Fri, 12 Sep 2003 00:36:36 +1000 (EST)
X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4
From:	Keith Owens <kaos@ocs.com.au>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: Some Question about the kernel module on MIPS64 
In-reply-to: Your message of "Thu, 11 Sep 2003 16:26:11 +0200."
             <20030911142611.GC15365@linux-mips.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:	Fri, 12 Sep 2003 00:36:35 +1000
Message-ID: <6668.1063290995@ocs3.intra.ocs.com.au>
Return-Path: <kaos@ocs.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3167
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@ocs.com.au
Precedence: bulk
X-list: linux-mips

On Thu, 11 Sep 2003 16:26:11 +0200, 
Ralf Baechle <ralf@linux-mips.org> wrote:
>On Thu, Sep 11, 2003 at 10:13:58AM +0800, ???? wrote:
>> try.o: init_module: Invalid argument
>> Hint: insmod errors can be caused by incorrect module parameters,
>> including invalid IO or IRQ parameters
>> Of course we do the above works in the same hardware platform .
>> Is there any thing I should pay attention to when I compile the Kernel
>> Module or the linux for mips64? Eagering your help!!
>
>The problem isn't the kernel but modutils which don't support kernel
>modules for 64-bit kernels.

Nobody has sent me patches for mips64 (hint, hint).


From yuasa@hh.iij4u.or.jp Thu Sep 11 16:44:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 16:44:30 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:59374 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225389AbTIKPoa>;
	Thu, 11 Sep 2003 16:44:30 +0100
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA22242;
	Fri, 12 Sep 2003 00:44:24 +0900 (JST)
Received: 4UMDO01 id h8BFiOg00519; Fri, 12 Sep 2003 00:44:24 +0900 (JST)
Received: 4UMRO01 id h8BFiMF03393; Fri, 12 Sep 2003 00:44:23 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date:	Fri, 12 Sep 2003 00:44:20 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	ralf@linux-mips.org
Cc:	yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: [patch] NEC VR4100 KIU support
Message-Id: <20030912004420.4d7e0091.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Fri__12_Sep_2003_00:44:20_+0900_0822dc80"
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3168
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Fri__12_Sep_2003_00:44:20_+0900_0822dc80
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I rewrote NEC VR4100 KIU driver for v2.4.
This driver adds keyboard support to IBM WorkPad z50 and Victor MP-C303/304.

Please apply this patch to v2.4 tree.

Yoichi

--Multipart_Fri__12_Sep_2003_00:44:20_+0900_0822dc80
Content-Type: text/plain;
 name="vr41xx_keyb-v24.diff"
Content-Disposition: attachment;
 filename="vr41xx_keyb-v24.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/Makefile linux/arch/mips/Makefile
--- linux.orig/arch/mips/Makefile	Thu Sep 11 23:28:55 2003
+++ linux/arch/mips/Makefile	Thu Sep 11 23:26:53 2003
@@ -651,6 +651,8 @@
 	$(MAKE) -C arch/$(ARCH)/tools clean
 	$(MAKE) -C arch/mips/baget clean
 	$(MAKE) -C arch/mips/lasat clean
+	$(MAKE) -C arch/mips/vr41xx/ibm-workpad clean
+	$(MAKE) -C arch/mips/vr41xx/victor-mpc30x clean
 
 archmrproper:
 	@$(MAKEBOOT) mrproper
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/config-shared.in linux/arch/mips/config-shared.in
--- linux.orig/arch/mips/config-shared.in	Mon Sep  8 19:53:59 2003
+++ linux/arch/mips/config-shared.in	Thu Sep 11 23:19:28 2003
@@ -413,7 +413,6 @@
    define_bool CONFIG_VR41XX_TIME_C y
    define_bool CONFIG_NONCOHERENT_IO y
    define_bool CONFIG_ISA y
-   define_bool CONFIG_DUMMY_KEYB y
    define_bool CONFIG_SCSI n
 fi
 if [ "$CONFIG_LASAT" = "y" ]; then
@@ -657,7 +656,6 @@
    define_bool CONFIG_PCI y
    define_bool CONFIG_NEW_PCI y
    define_bool CONFIG_PCI_AUTO y
-   define_bool CONFIG_DUMMY_KEYB y
    define_bool CONFIG_SCSI n
 fi
 if [ "$CONFIG_ZAO_CAPCELLA" = "y" ]; then
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/defconfig-mpc30x linux/arch/mips/defconfig-mpc30x
--- linux.orig/arch/mips/defconfig-mpc30x	Mon Aug 25 00:36:51 2003
+++ linux/arch/mips/defconfig-mpc30x	Thu Sep 11 23:22:54 2003
@@ -14,7 +14,7 @@
 # Loadable module support
 #
 CONFIG_MODULES=y
-# CONFIG_MODVERSIONS is not set
+CONFIG_MODVERSIONS=y
 CONFIG_KMOD=y
 
 #
@@ -31,6 +31,7 @@
 # CONFIG_MIPS_PB1500 is not set
 # CONFIG_MIPS_XXS1500 is not set
 # CONFIG_MIPS_MTX1 is not set
+# CONFIG_COGENT_CSB250 is not set
 # CONFIG_BAGET_MIPS is not set
 # CONFIG_CASIO_E55 is not set
 # CONFIG_MIPS_COBALT is not set
@@ -78,7 +79,6 @@
 CONFIG_PCI=y
 CONFIG_NEW_PCI=y
 CONFIG_PCI_AUTO=y
-CONFIG_DUMMY_KEYB=y
 # CONFIG_SCSI is not set
 # CONFIG_MIPS_AU1000 is not set
 
@@ -118,9 +118,24 @@
 # CONFIG_TC is not set
 # CONFIG_MCA is not set
 # CONFIG_SBUS is not set
-# CONFIG_HOTPLUG is not set
-# CONFIG_PCMCIA is not set
+CONFIG_HOTPLUG=y
+
+#
+# PCMCIA/CardBus support
+#
+CONFIG_PCMCIA=y
+# CONFIG_CARDBUS is not set
+# CONFIG_TCIC is not set
+# CONFIG_I82092 is not set
+# CONFIG_I82365 is not set
+CONFIG_PCMCIA_VRC4173=y
+
+#
+# PCI Hotplug Support
+#
 # CONFIG_HOTPLUG_PCI is not set
+# CONFIG_HOTPLUG_PCI_COMPAQ is not set
+# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
 CONFIG_SYSVIPC=y
 # CONFIG_BSD_PROCESS_ACCT is not set
 CONFIG_SYSCTL=y
@@ -191,10 +206,7 @@
 CONFIG_INET=y
 CONFIG_IP_MULTICAST=y
 # CONFIG_IP_ADVANCED_ROUTER is not set
-CONFIG_IP_PNP=y
-# CONFIG_IP_PNP_DHCP is not set
-CONFIG_IP_PNP_BOOTP=y
-# CONFIG_IP_PNP_RARP 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
@@ -247,9 +259,79 @@
 #
 # ATA/IDE/MFM/RLL support
 #
-# CONFIG_IDE is not set
-# CONFIG_BLK_DEV_IDE_MODES is not set
+CONFIG_IDE=y
+
+#
+# IDE, ATA and ATAPI Block devices
+#
+CONFIG_BLK_DEV_IDE=y
+
+#
+# Please see Documentation/ide.txt for help/info on IDE drives
+#
+# CONFIG_BLK_DEV_HD_IDE is not set
 # CONFIG_BLK_DEV_HD is not set
+CONFIG_BLK_DEV_IDEDISK=y
+# CONFIG_IDEDISK_MULTI_MODE is not set
+# CONFIG_IDEDISK_STROKE is not set
+# CONFIG_BLK_DEV_IDECS is not set
+# CONFIG_BLK_DEV_IDECD is not set
+# CONFIG_BLK_DEV_IDETAPE is not set
+# CONFIG_BLK_DEV_IDEFLOPPY is not set
+# CONFIG_BLK_DEV_IDESCSI is not set
+# CONFIG_IDE_TASK_IOCTL is not set
+
+#
+# IDE chipset support/bugfixes
+#
+# CONFIG_BLK_DEV_CMD640 is not set
+# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
+# CONFIG_BLK_DEV_ISAPNP is not set
+CONFIG_BLK_DEV_IDEPCI=y
+CONFIG_BLK_DEV_GENERIC=y
+CONFIG_IDEPCI_SHARE_IRQ=y
+# CONFIG_BLK_DEV_IDEDMA_PCI is not set
+# CONFIG_BLK_DEV_OFFBOARD is not set
+# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
+# CONFIG_IDEDMA_PCI_AUTO is not set
+# CONFIG_IDEDMA_ONLYDISK is not set
+# CONFIG_BLK_DEV_IDEDMA is not set
+# CONFIG_IDEDMA_PCI_WIP is not set
+# CONFIG_BLK_DEV_ADMA100 is not set
+# CONFIG_BLK_DEV_AEC62XX is not set
+# CONFIG_BLK_DEV_ALI15X3 is not set
+# CONFIG_WDC_ALI15X3 is not set
+# CONFIG_BLK_DEV_AMD74XX is not set
+# CONFIG_AMD74XX_OVERRIDE is not set
+# CONFIG_BLK_DEV_CMD64X is not set
+# CONFIG_BLK_DEV_TRIFLEX is not set
+# CONFIG_BLK_DEV_CY82C693 is not set
+# CONFIG_BLK_DEV_CS5530 is not set
+# CONFIG_BLK_DEV_HPT34X is not set
+# CONFIG_HPT34X_AUTODMA is not set
+# CONFIG_BLK_DEV_HPT366 is not set
+# CONFIG_BLK_DEV_PIIX is not set
+# CONFIG_BLK_DEV_NS87415 is not set
+# CONFIG_BLK_DEV_OPTI621 is not set
+# CONFIG_BLK_DEV_PDC202XX_OLD is not set
+# CONFIG_PDC202XX_BURST is not set
+# CONFIG_BLK_DEV_PDC202XX_NEW is not set
+# CONFIG_BLK_DEV_RZ1000 is not set
+# CONFIG_BLK_DEV_SC1200 is not set
+# CONFIG_BLK_DEV_SVWKS is not set
+# CONFIG_BLK_DEV_SIIMAGE is not set
+# CONFIG_BLK_DEV_SIS5513 is not set
+# CONFIG_BLK_DEV_SLC90E66 is not set
+# CONFIG_BLK_DEV_TRM290 is not set
+# CONFIG_BLK_DEV_VIA82CXXX is not set
+# CONFIG_IDE_CHIPSETS is not set
+# CONFIG_IDEDMA_AUTO is not set
+# CONFIG_DMA_NONPCI is not set
+CONFIG_BLK_DEV_IDE_MODES=y
+# CONFIG_BLK_DEV_ATARAID is not set
+# CONFIG_BLK_DEV_ATARAID_PDC is not set
+# CONFIG_BLK_DEV_ATARAID_HPT is not set
+# CONFIG_BLK_DEV_ATARAID_SII is not set
 
 #
 # SCSI support
@@ -337,6 +419,22 @@
 # CONFIG_WAN is not set
 
 #
+# PCMCIA network device support
+#
+CONFIG_NET_PCMCIA=y
+# CONFIG_PCMCIA_3C589 is not set
+# CONFIG_PCMCIA_3C574 is not set
+CONFIG_PCMCIA_FMVJ18X=y
+CONFIG_PCMCIA_PCNET=y
+# CONFIG_PCMCIA_AXNET is not set
+# CONFIG_PCMCIA_NMCLAN is not set
+# CONFIG_PCMCIA_SMC91C92 is not set
+# CONFIG_PCMCIA_XIRC2PS is not set
+# CONFIG_ARCNET_COM20020_CS is not set
+# CONFIG_PCMCIA_IBMTR is not set
+# CONFIG_NET_PCMCIA_RADIO is not set
+
+#
 # Amateur Radio support
 #
 # CONFIG_HAMRADIO is not set
@@ -364,11 +462,12 @@
 # Character devices
 #
 CONFIG_VT=y
-# CONFIG_VT_CONSOLE is not set
+CONFIG_VT_CONSOLE=y
 CONFIG_SERIAL=y
 CONFIG_SERIAL_CONSOLE=y
 # CONFIG_SERIAL_EXTENDED is not set
 # CONFIG_SERIAL_NONSTANDARD is not set
+CONFIG_VR41XX_KIU=y
 CONFIG_UNIX98_PTYS=y
 CONFIG_UNIX98_PTY_COUNT=256
 
@@ -423,6 +522,12 @@
 # CONFIG_DRM is not set
 
 #
+# PCMCIA character devices
+#
+# CONFIG_PCMCIA_SERIAL_CS is not set
+# CONFIG_SYNCLINK_CS is not set
+
+#
 # File systems
 #
 # CONFIG_QUOTA is not set
@@ -487,7 +592,7 @@
 CONFIG_NFS_FS=y
 # CONFIG_NFS_V3 is not set
 # CONFIG_NFS_DIRECTIO is not set
-CONFIG_ROOT_NFS=y
+# CONFIG_ROOT_NFS is not set
 # CONFIG_NFSD is not set
 # CONFIG_NFSD_V3 is not set
 # CONFIG_NFSD_TCP is not set
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/defconfig-workpad linux/arch/mips/defconfig-workpad
--- linux.orig/arch/mips/defconfig-workpad	Mon Aug 25 00:36:57 2003
+++ linux/arch/mips/defconfig-workpad	Thu Sep 11 23:45:09 2003
@@ -31,6 +31,7 @@
 # CONFIG_MIPS_PB1500 is not set
 # CONFIG_MIPS_XXS1500 is not set
 # CONFIG_MIPS_MTX1 is not set
+# CONFIG_COGENT_CSB250 is not set
 # CONFIG_BAGET_MIPS is not set
 # CONFIG_CASIO_E55 is not set
 # CONFIG_MIPS_COBALT is not set
@@ -74,7 +75,6 @@
 CONFIG_VR41XX_TIME_C=y
 CONFIG_NONCOHERENT_IO=y
 CONFIG_ISA=y
-CONFIG_DUMMY_KEYB=y
 # CONFIG_SCSI is not set
 # CONFIG_MIPS_AU1000 is not set
 
@@ -395,6 +395,7 @@
 # CONFIG_SERIAL_MULTIPORT is not set
 # CONFIG_HUB6 is not set
 # CONFIG_SERIAL_NONSTANDARD is not set
+CONFIG_VR41XX_KIU=y
 CONFIG_UNIX98_PTYS=y
 CONFIG_UNIX98_PTY_COUNT=256
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/Makefile linux/arch/mips/vr41xx/ibm-workpad/Makefile
--- linux.orig/arch/mips/vr41xx/ibm-workpad/Makefile	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/Makefile	Thu Sep 11 23:19:29 2003
@@ -14,4 +14,12 @@
 
 obj-y	:= init.o setup.o
 
+obj-$(CONFIG_VR41XX_KIU)	+= keymap.o
+
+keymap.c: keymap.map
+	set -e ; loadkeys --mktable $< | sed -e 's/^static *//' > $@
+
+clean:
+	rm -f keymap.c
+
 include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/keymap.map linux/arch/mips/vr41xx/ibm-workpad/keymap.map
--- linux.orig/arch/mips/vr41xx/ibm-workpad/keymap.map	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/ibm-workpad/keymap.map	Thu Sep 11 23:19:29 2003
@@ -0,0 +1,344 @@
+# Keymap for IBM Workpad z50
+# US Mapping
+#
+# by Michael Klar <wyldfier@iname.com>
+#
+# This is a great big mess on account of how the Caps Lock key is handled as
+# LeftShift-RightShift.  Right shift key had to be broken out, so don't use
+# use this map file as a basis for other keyboards that don't do the same
+# thing with Caps Lock.
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License.  See the file "COPYING" in the main directory of this archive
+# for more details.
+
+keymaps 0-2,4-5,8,12,32-33,36-37
+strings as usual
+
+keycode 0 = F1 F11 Console_13
+	shiftr keycode 0 = F11
+	shift shiftr keycode 0 = F11
+	control keycode 0 = F1
+	alt keycode 0 = Console_1
+	control alt keycode 0 = Console_1
+keycode 1 = F3 F13 Console_15
+	shiftr keycode 1 = F13
+	shift shiftr keycode 1 = F13
+	control keycode 1 = F3
+	alt keycode 1 = Console_3
+	control alt keycode 1 = Console_3
+keycode 2 = F5 F15 Console_17
+	shiftr keycode 2 = F15
+	shift shiftr keycode 2 = F15
+	control keycode 2 = F5
+	alt keycode 2 = Console_5
+	control alt keycode 2 = Console_5
+keycode 3 = F7 F17 Console_19
+	shiftr keycode 3 = F17
+	shift shiftr keycode 3 = F17
+	control keycode 3 = F7
+	alt keycode 3 = Console_7
+	control alt keycode 3 = Console_7
+keycode 4 = F9 F19 Console_21
+	shiftr keycode 4 = F19
+	shift shiftr keycode 4 = F19
+	control keycode 4 = F9
+	alt keycode 4 = Console_9
+	control alt keycode 4 = Console_9
+#keycode 5 is contrast down
+#keycode 6 is contrast up
+keycode 7 = F11 F11 Console_23
+	shiftr keycode 7 = F11
+	shift shiftr keycode 7 = F11
+	control keycode 7 = F11
+	alt keycode 7 = Console_11
+	control alt keycode 7 = Console_11
+keycode 8 = F2 F12 Console_14
+	shiftr keycode 8 = F12
+	shift shiftr keycode 8 = F12
+	control keycode 8 = F2
+	alt keycode 8 = Console_2
+	control alt keycode 8 = Console_2
+keycode 9 = F4 F14 Console_16
+	shiftr keycode 9 = F14
+	shift shiftr keycode 9 = F14
+	control keycode 9 = F4
+	alt keycode 9 = Console_4
+	control alt keycode 9 = Console_4
+keycode 10 = F6 F16 Console_18
+	shiftr keycode 10 = F16
+	shift shiftr keycode 10 = F16
+	control keycode 10 = F6
+	alt keycode 10 = Console_6
+	control alt keycode 10 = Console_6
+keycode 11 = F8 F18 Console_20
+	shiftr keycode 11 = F18
+	shift shiftr keycode 11 = F18
+	control keycode 11 = F8
+	alt keycode 11 = Console_8
+	control alt keycode 11 = Console_8
+keycode 12 = F10 F20 Console_22
+	shiftr keycode 12 = F20
+	shift shiftr keycode 12 = F20
+	control keycode 12 = F10
+	alt keycode 12 = Console_10
+	control alt keycode 12 = Console_10
+#keycode 13 is brightness down
+#keycode 14 is brightness up
+keycode 15 = F12 F12 Console_24
+	shiftr keycode 15 = F12
+	shift shiftr keycode 15 = F12
+	control keycode 15 = F12
+	alt keycode 15 = Console_12
+	control alt keycode 15 = Console_12
+keycode 16 = apostrophe quotedbl
+	shiftr keycode 16 = quotedbl
+	shift shiftr keycode 16 = quotedbl
+	control keycode 16 = Control_g
+	alt keycode 16 = Meta_apostrophe
+keycode 17 = bracketleft braceleft
+	shiftr keycode 17 = braceleft
+	shift shiftr keycode 17 = braceleft
+	control keycode 17 = Escape
+	alt keycode 17 = Meta_bracketleft
+keycode 18 = minus underscore backslash       
+	shiftr keycode 18 = underscore
+	shift shiftr keycode 18 = underscore
+	control keycode 18 = Control_underscore
+	shift control keycode 18 = Control_underscore
+	shiftr control keycode 18 = Control_underscore
+	shift shiftr control keycode 18 = Control_underscore
+	alt keycode 18 = Meta_minus
+keycode 19 = zero parenright braceright
+	shiftr keycode 19 = parenright
+	shift shiftr keycode 19 = parenright
+	alt keycode 19 = Meta_zero
+keycode 20 = p
+	shiftr keycode 20 = +P
+	shift shiftr keycode 20 = +p
+keycode 21 = semicolon colon
+	shiftr keycode 21 = colon
+	shift shiftr keycode 21 = colon
+	alt keycode 21 = Meta_semicolon
+keycode 22 = Up Scroll_Backward
+	shiftr keycode 22 = Scroll_Backward
+	shift shiftr keycode 22 = Scroll_Backward
+	alt keycode 22 = Prior
+keycode 23 = slash question
+	shiftr keycode 23 = question
+	shift shiftr keycode 23 = question
+	control keycode 23 = Delete
+	alt keycode 23 = Meta_slash
+
+keycode 27 = nine parenleft bracketright
+	shiftr keycode 27 = parenleft
+	shift shiftr keycode 27 = parenleft
+	alt keycode 27 = Meta_nine
+keycode 28 = o
+	shiftr keycode 28 = +O
+	shift shiftr keycode 28 = +o
+keycode 29 = l
+	shiftr keycode 29 = +L
+	shift shiftr keycode 29 = +l
+keycode 30 = period greater
+	shiftr keycode 30 = greater
+	shift shiftr keycode 30 = greater
+	control keycode 30 = Compose
+	alt keycode 30 = Meta_period
+
+keycode 32 = Left Decr_Console
+	shiftr keycode 32 = Decr_Console
+	shift shiftr keycode 32 = Decr_Console
+	alt keycode 32 = Home
+keycode 33 = bracketright braceright asciitilde      
+	shiftr keycode 33 = braceright
+	shift shiftr keycode 33 = braceright
+	control keycode 33 = Control_bracketright
+	alt keycode 33 = Meta_bracketright
+keycode 34 = equal plus
+	shiftr keycode 34 = plus
+	shift shiftr keycode 34 = plus
+	alt keycode 34 = Meta_equal
+keycode 35 = eight asterisk bracketleft
+	shiftr keycode 35 = asterisk
+	shift shiftr keycode 35 = asterisk
+	control keycode 35 = Delete
+	alt keycode 35 = Meta_eight
+keycode 36 = i
+	shiftr keycode 36 = +I
+	shift shiftr keycode 36 = +i
+keycode 37 = k
+	shiftr keycode 37 = +K
+	shift shiftr keycode 37 = +k
+keycode 38 = comma less
+	shiftr keycode 38 = less
+	shift shiftr keycode 38 = less
+	alt keycode 38 = Meta_comma
+
+keycode 40 = h
+	shiftr keycode 40 = +H
+	shift shiftr keycode 40 = +h
+keycode 41 = y
+	shiftr keycode 41 = +Y
+	shift shiftr keycode 41 = +y
+keycode 42 = six asciicircum
+	shiftr keycode 42 = asciicircum
+	shift shiftr keycode 42 = asciicircum
+	control keycode 42 = Control_asciicircum
+	alt keycode 42 = Meta_six
+keycode 43 = seven ampersand braceleft
+	shiftr keycode 43 = ampersand
+	shift shiftr keycode 43 = ampersand
+	control keycode 43 = Control_underscore
+	alt keycode 43 = Meta_seven
+keycode 44 = u
+	shiftr keycode 44 = +U
+	shift shiftr keycode 44 = +u
+keycode 45 = j
+	shiftr keycode 45 = +J
+	shift shiftr keycode 45 = +j
+keycode 46 = m
+	shiftr keycode 46 = +M
+	shift shiftr keycode 46 = +m
+keycode 47 = n
+	shiftr keycode 47 = +N
+	shift shiftr keycode 47 = +n
+
+# This is the "Backspace" key:
+keycode 49 = Delete Delete
+	shiftr keycode 49 = Delete
+	shift shiftr keycode 49 = Delete
+	control keycode 49 = BackSpace
+	alt keycode 49 = Meta_Delete
+keycode 50 = Num_Lock
+	shift keycode 50 = Bare_Num_Lock
+	shiftr keycode 50 = Bare_Num_Lock
+	shift shiftr keycode 50 = Bare_Num_Lock
+# This is the "Delete" key:
+keycode 51 = Remove
+	control alt keycode 51 = Boot
+
+keycode 53 = backslash bar
+	shiftr keycode 53 = bar
+	shift shiftr keycode 53 = bar
+	control keycode 53 = Control_backslash
+	alt keycode 53 = Meta_backslash
+keycode 54 = Return
+	alt keycode 54 = Meta_Control_m
+keycode 55 = space space           
+	shiftr keycode 55 = space
+	shift shiftr keycode 55 = space
+	control keycode 55 = nul
+	alt keycode 55 = Meta_space
+keycode 56 = g
+	shiftr keycode 56 = +G
+	shift shiftr keycode 56 = +g
+keycode 57 = t
+	shiftr keycode 57 = +T
+	shift shiftr keycode 57 = +t
+keycode 58 = five percent
+	shiftr keycode 58 = percent
+	shift shiftr keycode 58 = percent
+	control keycode 58 = Control_bracketright
+	alt keycode 58 = Meta_five
+keycode 59 = four dollar dollar
+	shiftr keycode 59 = dollar
+	shift shiftr keycode 59 = dollar
+	control keycode 59 = Control_backslash
+	alt keycode 59 = Meta_four
+keycode 60 = r
+	shiftr keycode 60 = +R
+	shift shiftr keycode 60 = +r
+keycode 61 = f
+	shiftr keycode 61 = +F
+	shift shiftr keycode 61 = +f
+	altgr keycode 61 = Hex_F
+keycode 62 = v
+	shiftr keycode 62 = +V
+	shift shiftr keycode 62 = +v
+keycode 63 = b
+	shiftr keycode 63 = +B
+	shift shiftr keycode 63 = +b
+	altgr keycode 63 = Hex_B
+
+keycode 67 = three numbersign
+	shiftr keycode 67 = numbersign
+	shift shiftr keycode 67 = numbersign
+	control keycode 67 = Escape
+	alt keycode 67 = Meta_three
+keycode 68 = e
+	shiftr keycode 68 = +E
+	shift shiftr keycode 68 = +e
+	altgr keycode 68 = Hex_E
+keycode 69 = d
+	shiftr keycode 69 = +D
+	shift shiftr keycode 69 = +d
+	altgr keycode 69 = Hex_D
+keycode 70 = c
+	shiftr keycode 70 = +C
+	shift shiftr keycode 70 = +c
+	altgr keycode 70 = Hex_C
+keycode 71 = Right Incr_Console
+	shiftr keycode 71 = Incr_Console
+	shift shiftr keycode 71 = Incr_Console
+	alt keycode 71 = End
+
+keycode 75 = two at at
+	shiftr keycode 75 = at
+	shift shiftr keycode 75 = at
+	control keycode 75 = nul
+	shift control keycode 75 = nul
+	shiftr control keycode 75 = nul
+	shift shiftr control keycode 75 = nul
+	alt keycode 75 = Meta_two
+keycode 76 = w
+	shiftr keycode 76 = +W
+	shift shiftr keycode 76 = +w
+keycode 77 = s
+	shiftr keycode 77 = +S
+	shift shiftr keycode 77 = +s
+keycode 78 = x
+	shiftr keycode 78 = +X
+	shift shiftr keycode 78 = +x
+keycode 79 = Down Scroll_Forward
+	shiftr keycode 79 = Scroll_Forward
+	shift shiftr keycode 79 = Scroll_Forward
+	alt keycode 79 = Next
+keycode 80 = Escape Escape
+	shiftr keycode 80 = Escape
+	shift shiftr keycode 80 = Escape
+	alt keycode 80 = Meta_Escape
+keycode 81 = Tab Tab             
+	shiftr keycode 81 = Tab
+	shift shiftr keycode 81 = Tab
+	alt keycode 81 = Meta_Tab
+keycode 82 = grave asciitilde
+	shiftr keycode 82 = asciitilde
+	shift shiftr keycode 82 = asciitilde
+	control keycode 82 = nul
+	alt keycode 82 = Meta_grave
+keycode 83 = one exclam
+	shiftr keycode 83 = exclam
+	shift shiftr keycode 83 = exclam
+	alt keycode 83 = Meta_one
+keycode 84 = q
+	shiftr keycode 84 = +Q
+	shift shiftr keycode 84 = +q
+keycode 85 = a
+	shiftr keycode 85 = +A
+	shift shiftr keycode 85 = +a
+	altgr keycode 85 = Hex_A
+keycode 86 = z
+	shiftr keycode 86 = +Z
+	shift shiftr keycode 86 = +z
+
+# This is the windows key:
+keycode 88 = Decr_Console
+keycode 89 = Shift
+keycode 90 = Control
+keycode 91 = Control
+keycode 92 = Alt
+keycode 93 = AltGr
+keycode 94 = ShiftR
+	shift keycode 94 = Caps_Lock
+
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/Makefile linux/arch/mips/vr41xx/victor-mpc30x/Makefile
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/Makefile	Wed Jul 30 09:35:38 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/Makefile	Thu Sep 11 23:19:29 2003
@@ -14,6 +14,13 @@
 
 obj-y	:= init.o setup.o
 
-obj-$(CONFIG_PCI)	+= pci_fixup.o
+obj-$(CONFIG_PCI)		+= pci_fixup.o
+obj-$(CONFIG_VR41XX_KIU)	+= keymap.o
+
+keymap.c: keymap.map
+	set -e ; loadkeys --mktable $< | sed -e 's/^static *//' > $@
+
+clean:
+	rm -f keymap.c
 
 include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/keymap.map linux/arch/mips/vr41xx/victor-mpc30x/keymap.map
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/keymap.map	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/victor-mpc30x/keymap.map	Fri Sep 12 00:21:42 2003
@@ -0,0 +1,102 @@
+# Victor Interlink MP-C303/304 keyboard keymap
+#
+# Copyright 2003 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License.  See the file "COPYING" in the main directory of this archive
+# for more details.
+keymaps 0-1,4-5,8-9,12
+alt_is_meta
+strings as usual
+compose as usual for "iso-8859-1"
+
+# First line
+keycode 89 = Escape
+keycode  9 = Delete
+
+# 2nd line
+keycode 73 = one              exclam
+keycode 18 = two              quotedbl
+keycode 92 = three            numbersign
+	control	keycode 92 = Escape
+keycode 53 = four             dollar
+	control	keycode 53 = Control_backslash
+keycode 21 = five             percent
+	control	keycode 21 = Control_bracketright
+keycode 50 = six              ampersand
+	control	keycode 50 = Control_underscore
+keycode 48 = seven            apostrophe
+keycode 51 = eight            parenleft
+keycode 16 = nine             parenright
+keycode 80 = zero             asciitilde
+	control	keycode 80 = nul
+keycode 49 = minus            equal
+keycode 30 = asciicircum      asciitilde
+	control	keycode 30 = Control_asciicircum
+keycode  5 = backslash        bar
+	control	keycode  5 = Control_backslash
+keycode 13 = BackSpace
+# 3rd line
+keycode 57 = Tab
+keycode 74 = q
+keycode 26 = w
+keycode 81 = e
+keycode 29 = r
+keycode 37 = t
+keycode 45 = y
+keycode 72 = u
+keycode 24 = i
+keycode 32 = o
+keycode 41 = p
+keycode  1 = at               grave
+	control	keycode  1 = nul
+keycode 54 = bracketleft      braceleft
+keycode 63 = Return
+	alt	keycode 63 = Meta_Control_m
+# 4th line
+keycode 23 = Caps_Lock
+keycode 34 = a
+keycode 66 = s
+keycode 52 = d
+keycode 20 = f
+keycode 84 = g
+keycode 67 = h
+keycode 64 = j
+keycode 17 = k
+keycode 83 = l
+keycode 22 = semicolon        plus
+keycode 61 = colon            asterisk
+	control keycode 61 = Control_g
+keycode 65 = bracketright     braceright
+	control	keycode 65 = Control_bracketright
+# 5th line
+keycode 91 = Shift
+keycode 76 = z
+keycode 68 = x
+keycode 28 = c
+keycode 36 = v
+keycode 44 = b
+keycode 19 = n
+keycode 27 = m
+keycode 35 = comma            less
+keycode  3 = period           greater
+	control	keycode  3 = Compose
+keycode 38 = slash            question
+	control	keycode 38 = Delete
+	shift	control	keycode 38 = Delete
+keycode  6 = backslash        underscore
+	control	keycode  6 = Control_backslash
+keycode 55 = Up
+	alt keycode 55 = PageUp
+keycode 14 = Shift
+# 6th line
+keycode 56 = Control
+keycode 42 = Alt
+keycode 33 = space
+	control	keycode 33 = nul
+keycode  7 = Left
+	alt keycode  7 = Home
+keycode 31 = Down
+	alt keycode 31 = PageDown
+keycode 47 = Right
+	alt keycode 47 = End
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/char/Config.in linux/drivers/char/Config.in
--- linux.orig/drivers/char/Config.in	Thu Aug 14 02:19:16 2003
+++ linux/drivers/char/Config.in	Thu Sep 11 23:19:29 2003
@@ -157,6 +157,9 @@
    fi
    bool 'Enable Smart Card Reader 0 Support ' CONFIG_IT8172_SCR0
 fi
+if [ "$CONFIG_CPU_VR41XX" = "y" ]; then
+   bool 'NEC VR4100 series Keyboard Interface Unit Support ' CONFIG_VR41XX_KIU
+fi
 bool 'Unix98 PTY support' CONFIG_UNIX98_PTYS
 if [ "$CONFIG_UNIX98_PTYS" = "y" ]; then
    int 'Maximum number of Unix98 PTYs in use (0-2048)' CONFIG_UNIX98_PTY_COUNT 256
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/char/Makefile linux/drivers/char/Makefile
--- linux.orig/drivers/char/Makefile	Thu Aug 14 02:19:16 2003
+++ linux/drivers/char/Makefile	Thu Sep 11 23:22:32 2003
@@ -46,6 +46,10 @@
   ifneq ($(CONFIG_PC_KEYB),y)
     KEYBD    =
   endif
+  ifeq ($(CONFIG_VR41XX_KIU),y)
+    KEYMAP   =
+    KEYBD    = vr41xx_keyb.o
+  endif
 endif
 
 ifeq ($(ARCH),s390x)
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/char/vr41xx_keyb.c linux/drivers/char/vr41xx_keyb.c
--- linux.orig/drivers/char/vr41xx_keyb.c	Thu Jan  1 09:00:00 1970
+++ linux/drivers/char/vr41xx_keyb.c	Thu Sep 11 23:40:26 2003
@@ -0,0 +1,410 @@
+/*
+ * FILE NAME
+ *	drivers/char/vr41xx_keyb.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Keyboard driver for NEC VR4100 series Keyboard Interface Unit.
+ *
+ * Copyright (C) 1999 Bradley D. LaRonde
+ * Copyright (C) 1999 Hiroshi Kawashima <kawashima@iname.com>
+ * Copyright (C) 2000 Michael Klar <wyldfier@iname.com>
+ * Copyright (C) 2002,2003 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+/*
+ * Changes:
+ *  version 1.0
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Mon, 25 Mar 2002
+ *  -  Rewrote extensively because of 2.4.18.
+ *
+ *  version 1.1
+ *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Wed,  9 Sep 200
+ *  -  Added NEC VRC4173 KIU support.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/kbd_ll.h>
+#ifdef CONFIG_PCI
+#include <linux/pci.h>
+#endif
+#include <linux/pm.h>
+
+#include <asm/addrspace.h>
+#include <asm/cpu.h>
+#include <asm/io.h>
+#include <asm/param.h>
+#include <asm/vr41xx/vr41xx.h>
+#ifdef CONFIG_VRC4173
+#include <asm/vr41xx/vrc4173.h>
+#endif
+
+#define KIU_BASE			KSEG1ADDR(0x0b000180)
+#define MKIUINTREG			KSEG1ADDR(0x0b000092)
+
+#define VRC4173_KIU_OFFSET		0x100
+#define VRC4173_MKIUINTREG_OFFSET	0x072
+
+#define KIUDAT0				0x00
+#define KIUDAT1				0x02
+#define KIUDAT2				0x04
+#define KIUDAT3				0x06
+#define KIUDAT4				0x08
+#define KIUDAT5				0x0a
+#define KIUDAT6				0x0c
+#define KIUDAT7				0x0e
+#define KIUSCANREP			0x10
+ #define KIUSCANREP_KEYEN		0x8000
+ #define KIUSCANREP_STPREP(x)		((x) << 4)
+ #define KIUSCANREP_SCANSTP		0x0008
+ #define KIUSCANREP_SCANSTART		0x0004
+ #define KIUSCANREP_ATSTP		0x0002
+ #define KIUSCANREP_ATSCAN		0x0001
+#define KIUSCANS			0x12
+ #define KIUSCANS_SCANNING		0x0003
+ #define KIUSCANS_INTERVAL		0x0002
+ #define KIUSCANS_WAITKEYIN		0x0001
+ #define KIUSCANS_STOPPED		0x0000
+#define KIUWKS				0x14
+ #define KIUWKS_T3CNT			0x7c00
+ #define KIUWKS_T3CNT_SHIFT		10
+ #define KIUWKS_T2CNT			0x03e0
+ #define KIUWKS_T2CNT_SHIFT		5
+ #define KIUWKS_T1CNT			0x001f
+ #define KIUWKS_T1CNT_SHIFT		0
+ #define KIUWKS_CNT_USEC(x)		(((x) / 30) - 1)
+#define KIUWKI				0x16
+ #define KIUWKI_INTERVAL_USEC(x)	((x) / 30)
+#define KIUINT				0x18
+ #define KIUINT_KDATLOST		0x0004
+ #define KIUINT_KDATRDY			0x0002
+ #define KIUINT_SCANINT			0x0001
+#define KIURST				0x1a
+ #define KIURST_KIURST			0x0001
+#define KIUGPEN				0x1c
+ #define KIUGPEN_KGPEN(x)		((uint16_t)1 << (x))
+#define SCANLINE			0x1e
+ #define SCANLINE_DONTUSE		0x0003
+ #define SCANLINE_8LINES		0x0002
+ #define SCANLINE_10LINES		0x0001
+ #define SCANLINE_12LINES		0x0000
+
+static unsigned long kiu_base;
+static unsigned long mkiuintreg;
+
+#ifdef CONFIG_VRC4173
+#define kiu_readw(offset)		vrc4173_inw(kiu_base + (offset))
+#define kiu_writew(val, offset)		vrc4173_outw(val, kiu_base + (offset))
+#define mkiuintreg_writew(val)		vrc4173_outw((val), mkiuintreg)
+#else
+#define kiu_readw(offset)		readw(kiu_base + (offset))
+#define kiu_writew(val, offset)		writew(val, kiu_base + (offset))
+#define mkiuintreg_writew(val)		writew((val), mkiuintreg)
+#endif
+
+#define KIU_CLOCK			0x0008
+
+#ifdef CONFIG_VRC4173
+#define KIU_IRQ				VRC4173_KIU_IRQ
+#else
+#define KIU_IRQ				SYSINT1_IRQ(7)
+#endif
+
+#define KEY_UP				0
+#define KEY_DOWN			1
+
+#define DEFAULT_KIUDAT_REGS		6
+#define DEFAULT_DATA_NOT_REVERSED	0
+#define DEFAULT_T3CNT			KIUWKS_CNT_USEC(200)
+#define DEFAULT_T2CNT			KIUWKS_CNT_USEC(200)
+#define DEFAULT_T1CNT			KIUWKS_CNT_USEC(200)
+#define DEFAULT_SCAN_INTERVAL		KIUWKI_INTERVAL_USEC(30000)
+#define DEFAULT_REPEAT_DELAY		HZ/4
+#define DEFAULT_REPEAT_RATE		HZ/25
+
+static char *kiu_driver_name = "Keyboard driver";
+static char *kiu_driver_version = "1.1";
+static char *kiu_driver_revdate = "2003-09-09";
+static char *kiu_driver_device_name = "NEC VR4100 series KIU";
+
+static unsigned char kiudat_regs = DEFAULT_KIUDAT_REGS;
+static unsigned char data_reverse = DEFAULT_DATA_NOT_REVERSED;
+static uint16_t scanlines = SCANLINE_12LINES;
+static uint16_t t3cnt = DEFAULT_T3CNT;
+static uint16_t t2cnt = DEFAULT_T2CNT;
+static uint16_t t1cnt = DEFAULT_T1CNT;
+static uint16_t scan_interval = DEFAULT_SCAN_INTERVAL;
+
+static unsigned long repeat_delay = DEFAULT_REPEAT_DELAY;
+static unsigned long repeat_rate = DEFAULT_REPEAT_RATE;
+
+static int repeat_scancode = -1;
+static unsigned long next_handle_time;
+
+struct kiudat_t {
+	uint32_t reg;
+	uint16_t data;
+};
+
+static struct kiudat_t kiudat [8] = {
+	{KIUDAT0, 0}, {KIUDAT1, 0},
+	{KIUDAT2, 0}, {KIUDAT3, 0},
+	{KIUDAT4, 0}, {KIUDAT5, 0},
+	{KIUDAT6, 0}, {KIUDAT7, 0},
+};
+
+int kbd_setkeycode(unsigned int scancode, unsigned int keycode)
+{
+	return (scancode == keycode) ? 0 : -EINVAL;
+}
+
+int kbd_getkeycode(unsigned int scancode)
+{
+	return scancode;
+}
+
+int kbd_translate(unsigned char scancode, unsigned char *keycode, char raw_mode)
+{
+	*keycode = scancode;
+	return 1;
+}
+
+char kbd_unexpected_up(unsigned char keycode)
+{
+	printk(KERN_WARNING "vr41xx_keyb: unexpected up, keycode 0x%02x\n", keycode);
+	return 0x80;
+}
+
+void kbd_leds(unsigned char leds)
+{
+	return;
+}
+
+static inline void handle_kiudat(uint16_t data, uint16_t cmp_data, int scancode)
+{
+	uint16_t mask;
+	int down, candidate_scancode = 0;
+
+	for (mask = 0x0001; mask ; mask <<= 1) {
+		if (cmp_data & mask) {
+			down = data & mask ? KEY_DOWN : KEY_UP;
+			if (down == KEY_DOWN) {
+				repeat_scancode = scancode;
+				next_handle_time = jiffies + repeat_delay;
+			}
+			else {
+				if (repeat_scancode == scancode)
+					repeat_scancode = -1;
+			}
+			handle_scancode(scancode, down);
+		}
+		if (data & mask) {
+			candidate_scancode = scancode;
+		}
+		scancode++;
+	}
+
+	if ((repeat_scancode < 0) && (candidate_scancode > 0)) {
+			repeat_scancode = candidate_scancode;
+			next_handle_time = jiffies + repeat_delay;
+	}
+}
+
+static inline void handle_kiu_event(void)
+{
+	struct kiudat_t *kiu = kiudat;
+	uint16_t data, last_data, cmp_data;
+	int i;
+
+	for (i = 0; i < kiudat_regs; i++) {
+		last_data = kiu->data;
+		data = kiu_readw(kiu->reg);
+		if (data_reverse)
+			data = ~data;
+		kiu->data = data;
+		cmp_data = data ^ last_data;
+		handle_kiudat(data, cmp_data, i * 16);
+		kiu++;
+	}
+
+	if ((repeat_scancode >= 0) &&
+	    (time_after_eq(jiffies, next_handle_time))) {
+		handle_scancode(repeat_scancode, KEY_DOWN);
+		next_handle_time = jiffies + repeat_rate;
+	}
+}
+
+static void kiu_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	uint16_t status;
+
+	mkiuintreg_writew(0);
+
+	status = kiu_readw(KIUINT);
+	kiu_writew(KIUINT_KDATLOST | KIUINT_KDATRDY | KIUINT_SCANINT, KIUINT);
+
+	if (status & KIUINT_KDATRDY)
+		handle_kiu_event();
+
+	mkiuintreg_writew(KIUINT_KDATLOST | KIUINT_KDATRDY);
+}
+
+#ifdef CONFIG_PM
+
+static int pm_kiu_request(struct pm_dev *dev, pm_request_t rqst, void *data)
+{
+	switch (rqst) {
+	case PM_SUSPEND:
+		mkiuintreg_writew(KIUINT_SCANINT);
+		break;
+	case PM_RESUME:
+		kiu_writew(KIUINT_KDATLOST | KIUINT_KDATRDY | KIUINT_SCANINT, KIUINT);
+		mkiuintreg_writew(KIUINT_KDATLOST | KIUINT_KDATRDY, MKIUINTREG);
+		break;
+	}
+
+	return 0;
+}
+
+#endif
+
+void __devinit kbd_init_hw(void)
+{
+	uint16_t kiugpen = 0;
+	int i;
+
+	if (current_cpu_data.cputype == CPU_VR4111 ||
+	    current_cpu_data.cputype == CPU_VR4121) {
+		kiu_base = KIU_BASE;
+		mkiuintreg = MKIUINTREG;
+#if defined(CONFIG_PCI) && defined(CONFIG_VRC4173)
+	} else if (current_cpu_data.cputype == CPU_VR4122 ||
+	           current_cpu_data.cputype == CPU_VR4131) {
+		struct pci_dev *dev;
+		int found = 0;
+		dev = pci_find_device(PCI_VENDOR_ID_NEC,
+		                      PCI_DEVICE_ID_NEC_VRC4173, NULL);
+		if (dev != NULL) {
+			switch (scanlines) {
+			case SCANLINE_8LINES:
+				vrc4173_select_function(KIU8_SELECT);
+				found = 1;
+				break;
+			case SCANLINE_10LINES:
+				vrc4173_select_function(KIU10_SELECT);
+				found = 1;
+				break;
+			case SCANLINE_12LINES:
+				vrc4173_select_function(KIU12_SELECT);
+				found = 1;
+				break;
+			default:
+				break;
+			}
+
+			if (found != 0) {
+				kiu_base = VRC4173_KIU_OFFSET;
+				mkiuintreg = VRC4173_MKIUINTREG_OFFSET;
+				vrc4173_clock_supply(VRC4173_KIU_CLOCK);
+			}
+		}
+#endif
+	}
+
+	if (kiu_base == 0 || mkiuintreg == 0)
+		return;
+
+	printk(KERN_INFO "%s version %s (%s) for %s\n",
+	       kiu_driver_name, kiu_driver_version,
+	       kiu_driver_revdate, kiu_driver_device_name);
+
+	mkiuintreg_writew(0);
+
+	if (current_cpu_data.cputype == CPU_VR4111 ||
+	    current_cpu_data.cputype == CPU_VR4121)
+		vr41xx_clock_supply(KIU_CLOCK);
+
+	kiu_writew(KIURST_KIURST, KIURST);
+
+	for (i = 0; i < scanlines; i++)
+		kiugpen &= ~(0x0001 << i);
+
+	kiu_writew(kiugpen, KIUGPEN);
+	kiu_writew(scanlines, SCANLINE);
+	kiu_writew((t3cnt << KIUWKS_T3CNT_SHIFT) |
+	           (t2cnt << KIUWKS_T2CNT_SHIFT) |
+	           (t1cnt << KIUWKS_T1CNT_SHIFT), KIUWKS);
+	kiu_writew(scan_interval, KIUWKI);
+	kiu_writew(KIUINT_KDATLOST | KIUINT_KDATRDY | KIUINT_SCANINT, KIUINT);
+
+
+	request_irq(KIU_IRQ, kiu_interrupt, 0, "keyboard", NULL);
+
+	mkiuintreg_writew(KIUINT_KDATLOST | KIUINT_KDATRDY);
+	kiu_writew(KIUSCANREP_KEYEN | KIUSCANREP_STPREP(1) |
+	       KIUSCANREP_ATSTP | KIUSCANREP_ATSCAN, KIUSCANREP);
+
+#ifdef CONFIG_PM
+	pm_register(PM_SYS_DEV, PM_SYS_KBC, pm_kiu_request);
+#endif
+}
+
+static int __devinit vr41xx_kbd_setup(char *options)
+{
+	char *this_opt;
+	int num;
+
+	if (!options || !*options)
+		return 1;
+
+	for (this_opt = strtok(options, ","); this_opt; this_opt = strtok(NULL, ",")) {
+		if (!strncmp(this_opt, "regs:", 5)) {
+			num = simple_strtoul(this_opt+5, NULL, 0);
+			if (num == 6 || num == 8)
+				kiudat_regs = num;
+		} else if (!strncmp(this_opt, "lines:", 6)) {
+			num = simple_strtoul(this_opt+6, NULL, 0);
+			if (num == 8)
+				scanlines = SCANLINE_8LINES;
+			else if (num == 10)
+				scanlines = SCANLINE_10LINES;
+			else if (num == 12)
+				scanlines = SCANLINE_12LINES;
+		} else if (!strncmp(this_opt, "reverse:", 8)) {
+			num = simple_strtoul(this_opt+8, NULL, 0);
+			if (num == 0 || num == 1)
+				data_reverse = num;
+		} else if (!strncmp(this_opt, "t3cnt:", 6)) {
+			num = simple_strtoul(this_opt+6, NULL, 0);
+			if (num >= 60 && num <= 960)
+				t3cnt = KIUWKS_CNT_USEC(num);
+		} else if (!strncmp(this_opt, "t2cnt:", 6)) {
+			num = simple_strtoul(this_opt+6, NULL, 0);
+			if (num >= 60 && num <= 960)
+				t2cnt = KIUWKS_CNT_USEC(num);
+		} else if (!strncmp(this_opt, "t1cnt:", 6)) {
+			num = simple_strtoul(this_opt+6, NULL, 0);
+			if (num >= 60 && num <= 960)
+				t1cnt = KIUWKS_CNT_USEC(num);
+		} else if (!strncmp(this_opt, "interval:", 9)) {
+			num = simple_strtoul(this_opt+9, NULL, 0);
+			if (num >= 30 && num <= 30690)
+				scan_interval = KIUWKI_INTERVAL_USEC(num);
+		} else if (!strncmp(this_opt, "delay:", 6)) {
+			num = simple_strtoul(this_opt+6, NULL, 0);
+			if (num > 0 && num <= HZ)
+				repeat_delay = num;
+		} else if (!strncmp(this_opt, "rate:", 5)) {
+			num = simple_strtoul(this_opt+5, NULL, 0);
+			if (num > 0 && num <= HZ)
+				repeat_rate = num;
+		}
+	}
+
+	return 1;
+}
+
+__setup("vr41xx_kbd=", vr41xx_kbd_setup);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vrc4173.h linux/include/asm-mips/vr41xx/vrc4173.h
--- linux.orig/include/asm-mips/vr41xx/vrc4173.h	Thu Mar 20 03:15:16 2003
+++ linux/include/asm-mips/vr41xx/vrc4173.h	Thu Sep 11 23:47:58 2003
@@ -75,6 +75,12 @@
 extern void vrc4173_clock_supply(u16 mask);
 extern void vrc4173_clock_mask(u16 mask);
 
+#define VRC4173_PIU_CLOCK	0x0001
+#define VRC4173_KIU_CLOCK	0x0002
+#define VRC4173_AIU_CLOCK	0x0004
+#define VRC4173_PS2CH1_CLOCK	0x0008
+#define VRC4173_PS2CH2_CLOCK	0x0010
+
 /*
  * General-Purpose I/O Unit
  */

--Multipart_Fri__12_Sep_2003_00:44:20_+0900_0822dc80--

From ppopov@mvista.com Thu Sep 11 17:57:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Sep 2003 17:57:08 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27124 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225366AbTIKQ5I>;
	Thu, 11 Sep 2003 17:57:08 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA25688;
	Thu, 11 Sep 2003 09:57:03 -0700
Subject: Re: cache coherent io on au1500
From:	Pete Popov <ppopov@mvista.com>
To:	Bruno Randolf <bruno.randolf@4g-systems.biz>
Cc:	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <200309111605.13050.bruno.randolf@4g-systems.biz>
References: <200309111605.13050.bruno.randolf@4g-systems.biz>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1063299520.23653.3.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date:	11 Sep 2003 09:58:40 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3169
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips


Take a look at ftp.linux-mips.org:/pub/linux/mips/people/ppopov.
There's a README there that describes patches that are not in the tree.
One of them is a tiny patch called coherent_cow.patch that fixes the
compilation problem below. Ralf was looking for a more permanent fix, so
he hasn't applied this patch.

Pete

On Thu, 2003-09-11 at 07:05, Bruno Randolf wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> hello!
> 
> i have an Au1500, silicon stepping AD (mtx-1 board) which as far as i 
> understand should be able to do cache coherent io. but if i change 
> CONFIG_NONCOHERENT_IO to "n" compilation of 2.4.21 fails with 
> 
> mipsel-linux-gcc -D__KERNEL__ -I/data/kernel/mtx-2.4.21/include -Wall 
> - -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
> - -fomit-frame-pointer -I /data/kernel/mtx-2.4.21/include/asm/gcc -G 0 
> - -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap   -nostdinc 
> - -iwithprefix include -DKBUILD_BASENAME=fork  -c -o fork.o fork.c
> In file included from fork.c:20:
> /data/kernel/mtx-2.4.21/include/linux/vmalloc.h: In function `vmalloc':
> /data/kernel/mtx-2.4.21/include/linux/vmalloc.h:36: `_CACHE_CACHABLE_COW' 
> undeclared (first use in this function)
> /data/kernel/mtx-2.4.21/include/linux/vmalloc.h:36: (Each undeclared 
> identifier is reported only once
> /data/kernel/mtx-2.4.21/include/linux/vmalloc.h:36: for each function it 
> appears in.)
> /data/kernel/mtx-2.4.21/include/linux/vmalloc.h: In function `vmalloc_dma':
> /data/kernel/mtx-2.4.21/include/linux/vmalloc.h:45: `_CACHE_CACHABLE_COW' 
> undeclared (first use in this function)
> /data/kernel/mtx-2.4.21/include/linux/vmalloc.h: In function `vmalloc_32':
> /data/kernel/mtx-2.4.21/include/linux/vmalloc.h:54: `_CACHE_CACHABLE_COW' 
> undeclared (first use in this function)
> make[2]: *** [fork.o] Error 1
> 
> how could i fix that?
> 
> thanks,
> bruno
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQE/YIEZfg2jtUL97G4RAm0pAJ47FLT9fJaNWIqE0gHJ5zsPlZhPngCfY+AY
> ZOEDI2hvDJ/zbdk98TzCm9k=
> =FcHD
> -----END PGP SIGNATURE-----
> 
> 
> 


From anemo@mba.ocn.ne.jp Fri Sep 12 01:32:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 Sep 2003 01:32:01 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:53528
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225384AbTILAcA>; Fri, 12 Sep 2003 01:32:00 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 12 Sep 2003 00:31:58 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h8C0Vogc060491;
	Fri, 12 Sep 2003 09:31:51 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Fri, 12 Sep 2003 09:34:06 +0900 (JST)
Message-Id: <20030912.093406.78702272.nemoto@toshiba-tops.co.jp>
To:	ralf@linux-mips.org
Cc:	linux-mips@linux-mips.org
Subject: Re: mips64 _access_ok fix
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030911141629.GB15365@linux-mips.org>
References: <20030911.124350.41627177.nemoto@toshiba-tops.co.jp>
	<20030911.134323.03974731.nemoto@toshiba-tops.co.jp>
	<20030911141629.GB15365@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3173
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 407
Lines: 11

>>>>> On Thu, 11 Sep 2003 16:16:29 +0200, Ralf Baechle <ralf@linux-mips.org> said:
>> I know this fix is not complete.  __access_ok(0, 0, __access_mask)
>> will return 0.

ralf> That behaviour of __access_ok() is actually ok;

Then could you apply the patch?  I think the fix is needed for 64bit
native mount syscall (which try to read variable length string
parameters from user stack).
---
Atsushi Nemoto

From jsimmons@infradead.org Fri Sep 12 18:27:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 Sep 2003 18:27:47 +0100 (BST)
Received: from pub234.cambridge.redhat.com ([IPv6:::ffff:213.86.99.234]:25611
	"EHLO phoenix.infradead.org") by linux-mips.org with ESMTP
	id <S8225351AbTILR1p>; Fri, 12 Sep 2003 18:27:45 +0100
Received: from localhost.localdomain ([127.0.0.1] helo=localhost)
	by phoenix.infradead.org with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.22)
	id 19xrhv-0001ah-JF; Fri, 12 Sep 2003 18:27:43 +0100
Date: Fri, 12 Sep 2003 18:27:38 +0100 (BST)
From: James Simmons <jsimmons@infradead.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
cc: ralf@linux-mips.org, <linux-mips@linux-mips.org>
Subject: Re: [patch] NEC VR4100 KIU support
In-Reply-To: <20030912004420.4d7e0091.yuasa@hh.iij4u.or.jp>
Message-ID: <Pine.LNX.4.44.0309121827180.5017-100000@phoenix.infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <jsimmons@infradead.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3174
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsimmons@infradead.org
Precedence: bulk
X-list: linux-mips
Content-Length: 311
Lines: 17


Nice. Would you consider porting that to the input api for 2.6.X?



On Fri, 12 Sep 2003, Yoichi Yuasa wrote:

> Hello Ralf,
> 
> I rewrote NEC VR4100 KIU driver for v2.4.
> This driver adds keyboard support to IBM WorkPad z50 and Victor MP-C303/304.
> 
> Please apply this patch to v2.4 tree.
> 
> Yoichi
> 


From yuasa@hh.iij4u.or.jp Fri Sep 12 18:34:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 Sep 2003 18:34:48 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:23495 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225351AbTILRep>;
	Fri, 12 Sep 2003 18:34:45 +0100
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id CAA11289;
	Sat, 13 Sep 2003 02:34:31 +0900 (JST)
Received: 4UMDO00 id h8CHYVu04706; Sat, 13 Sep 2003 02:34:31 +0900 (JST)
Received: 4UMRO00 id h8CHYTa21466; Sat, 13 Sep 2003 02:34:29 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Sat, 13 Sep 2003 02:34:28 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: James Simmons <jsimmons@infradead.org>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org,
	yuasa@hh.iij4u.or.jp
Subject: Re: [patch] NEC VR4100 KIU support
Message-Id: <20030913023428.7fa72ac3.yuasa@hh.iij4u.or.jp>
In-Reply-To: <Pine.LNX.4.44.0309121827180.5017-100000@phoenix.infradead.org>
References: <20030912004420.4d7e0091.yuasa@hh.iij4u.or.jp>
	<Pine.LNX.4.44.0309121827180.5017-100000@phoenix.infradead.org>
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3175
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 458
Lines: 26

On Fri, 12 Sep 2003 18:27:38 +0100 (BST)
James Simmons <jsimmons@infradead.org> wrote:

> 
> Nice. Would you consider porting that to the input api for 2.6.X?

Yes, of course.

Yoichi

> 
> On Fri, 12 Sep 2003, Yoichi Yuasa wrote:
> 
> > Hello Ralf,
> > 
> > I rewrote NEC VR4100 KIU driver for v2.4.
> > This driver adds keyboard support to IBM WorkPad z50 and Victor MP-C303/304.
> > 
> > Please apply this patch to v2.4 tree.
> > 
> > Yoichi
> > 
> 
> 



From craig.mautner@alumni.ucsd.edu Fri Sep 12 19:05:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 Sep 2003 19:05:18 +0100 (BST)
Received: from orngca-mls01.socal.rr.com ([IPv6:::ffff:66.75.160.16]:22210
	"EHLO orngca-mls01.socal.rr.com") by linux-mips.org with ESMTP
	id <S8225392AbTILSFQ>; Fri, 12 Sep 2003 19:05:16 +0100
Received: from PEPELEPEW (66-75-23-214.san.rr.com [66.75.23.214])
	by orngca-mls01.socal.rr.com (8.11.4/8.11.3) with SMTP id h8CI1b406738
	for <linux-mips@linux-mips.org>; Fri, 12 Sep 2003 11:01:37 -0700 (PDT)
From: "Craig Mautner" <craig.mautner@alumni.ucsd.edu>
To: <linux-mips@linux-mips.org>
Subject: schedule() BUG
Date: Fri, 12 Sep 2003 11:04:16 -0700
Message-ID: <JKEMLDJFFLGLICKLLEFJMEEOCOAA.craig.mautner@alumni.ucsd.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Return-Path: <craig.mautner@alumni.ucsd.edu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3176
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: craig.mautner@alumni.ucsd.edu
Precedence: bulk
X-list: linux-mips
Content-Length: 2201
Lines: 70

We are using mips-linux 2.4.17, gcc 3.2.1 (MontaVista) and crashing in
schedule():

kernel BUG at sched.c:784!
Unable to handle kernel paging request at virtual address 00000000, epc ==
800153c0, ra == 800153c0
$0 : 00000000 9001f800 0000001b 00000000 0000001a 83f56000 8298f4a0 0000001f
$8 : 00000001 ffffe2e0 000022e0 00000000 fffffff9 ffffffff 0000000a 00000002
$16: 00000000 00000000 82af0000 8298f4a0 83f56000 00000000 80008000 00000000
$24: 82af1dc2 00000002                   82af0000 82af1ef8 82af1ef8 800153c0
epc  : 800153c0    Not tainted

The code is:

    {
      struct mm_struct *mm = next->mm;
      struct mm_struct *oldmm = prev->active_mm;
      if (!mm) {
           if (next->active_mm) BUG();   <- this is where we crash
           next->active_mm = oldmm;
           atomic_inc(&oldmm->mm_count);
           enter_lazy_tlb(oldmm, next, this_cpu);
      }
        .
        .
        .

This seems to happen in our case when 'next' points to 'kswapd' although we
think it could happen when switching to any kernel task (i.e. those tasks
with mm==NULL).

We think the culprit is that we are taking an interrupt and rescheduling
while at a vulnerable point in 'schedule()'. Interrupts are enabled in line
743. If we get an interrupt any time after line 785:

           next->active_mm = oldmm;

but before line 806

	__schedule_tail()

completes the swap, the interrupt can force 'schedule()' to be reentered via
'ret_from_intr()'.

If so, 'kswapd's 'active_mm' field will be left non-zero, but 'current' will
not have been set to point to 'kswapd'. The next time 'schedule()' tries to
switch to 'kswapd', 'next' points to 'kswapd', and

        next->mm == NULL
        next->active_mm != NULL

which is detected as an invalid state, so we hit the BUG.

Some questions:
	Are we looking at this correctly?
	Has anyone ever seen this before?
	Is there a published fix?

Thanks,

-Craig

-.     .-.     .-_     Craig Mautner
  \   /   \   / / `    Coastal Sr. Consulting, Inc.
   `-'     `-'  `---   (858)361-2683
                       (858)581-0542 (fax)
5580 La Jolla Blvd. #308 La Jolla, CA 92037
mailto:craig.mautner@alumni.ucsd.edu
http://home.san.rr.com/cmautner/csc/craig/


From rwhron@earthlink.net Sun Sep 14 01:12:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 Sep 2003 01:12:06 +0100 (BST)
Received: from harrier.mail.pas.earthlink.net ([IPv6:::ffff:207.217.120.12]:39678
	"EHLO harrier.mail.pas.earthlink.net") by linux-mips.org with ESMTP
	id <S8225396AbTINAMD>; Sun, 14 Sep 2003 01:12:03 +0100
Received: from user-38ld2mo.dsl.mindspring.com ([209.86.138.216] helo=earthlink.net)
	by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1)
	id 19yKUe-0003EI-00
	for linux-mips@linux-mips.org; Sat, 13 Sep 2003 17:11:57 -0700
Date: Sat, 13 Sep 2003 20:14:53 -0400
To: linux-mips@linux-mips.org
Subject: [PATCH] version.h cleanup of arch/mips
Message-ID: <20030914001453.GA27609@rushmore>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
From: rwhron@earthlink.net
Return-Path: <rwhron@earthlink.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3177
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rwhron@earthlink.net
Precedence: bulk
X-list: linux-mips
Content-Length: 6589
Lines: 155

version.h is included in some files that don't need it.
Removing the unnessary includes prevents extra compiles when
version.h changes.  Patch against 2.6.0-test5-bk3.



diff -Nur linux-2.6.0-test5-bk3/arch/mips/galileo-boards/ev64120/setup.c linux/arch/mips/galileo-boards/ev64120/setup.c
--- linux-2.6.0-test5-bk3/arch/mips/galileo-boards/ev64120/setup.c	2003-07-02 18:42:32.000000000 -0400
+++ linux/arch/mips/galileo-boards/ev64120/setup.c	2003-09-13 20:08:52.000000000 -0400
@@ -39,7 +39,6 @@
 #include <linux/interrupt.h>
 #include <linux/pci.h>
 #include <linux/timex.h>
-#include <linux/version.h>
 
 #include <asm/bootinfo.h>
 #include <asm/page.h>
diff -Nur linux-2.6.0-test5-bk3/arch/mips/gt64120/momenco_ocelot/setup.c linux/arch/mips/gt64120/momenco_ocelot/setup.c
--- linux-2.6.0-test5-bk3/arch/mips/gt64120/momenco_ocelot/setup.c	2003-08-09 06:09:57.000000000 -0400
+++ linux/arch/mips/gt64120/momenco_ocelot/setup.c	2003-09-13 20:08:50.000000000 -0400
@@ -60,7 +60,6 @@
 #include <asm/reboot.h>
 #include <asm/mc146818rtc.h>
 #include <asm/traps.h>
-#include <linux/version.h>
 #include <linux/bootmem.h>
 #include <linux/initrd.h>
 #include <asm/gt64120/gt64120.h>
diff -Nur linux-2.6.0-test5-bk3/arch/mips/momentum/ocelot_c/pci-irq.c linux/arch/mips/momentum/ocelot_c/pci-irq.c
--- linux-2.6.0-test5-bk3/arch/mips/momentum/ocelot_c/pci-irq.c	2003-07-02 18:42:32.000000000 -0400
+++ linux/arch/mips/momentum/ocelot_c/pci-irq.c	2003-09-13 20:08:55.000000000 -0400
@@ -17,7 +17,6 @@
 #include <linux/types.h>
 #include <linux/pci.h>
 #include <linux/kernel.h>
-#include <linux/version.h>
 #include <linux/init.h>
 #include <asm/pci.h>
 
diff -Nur linux-2.6.0-test5-bk3/arch/mips/momentum/ocelot_c/setup.c linux/arch/mips/momentum/ocelot_c/setup.c
--- linux-2.6.0-test5-bk3/arch/mips/momentum/ocelot_c/setup.c	2003-07-27 14:39:59.000000000 -0400
+++ linux/arch/mips/momentum/ocelot_c/setup.c	2003-09-13 20:08:58.000000000 -0400
@@ -61,7 +61,6 @@
 #include <asm/ptrace.h>
 #include <asm/reboot.h>
 #include <asm/mc146818rtc.h>
-#include <linux/version.h>
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
 #include <asm/mv64340.h>
diff -Nur linux-2.6.0-test5-bk3/arch/mips/momentum/ocelot_g/pci-irq.c linux/arch/mips/momentum/ocelot_g/pci-irq.c
--- linux-2.6.0-test5-bk3/arch/mips/momentum/ocelot_g/pci-irq.c	2003-07-02 18:42:32.000000000 -0400
+++ linux/arch/mips/momentum/ocelot_g/pci-irq.c	2003-09-13 20:09:00.000000000 -0400
@@ -17,7 +17,6 @@
 #include <linux/types.h>
 #include <linux/pci.h>
 #include <linux/kernel.h>
-#include <linux/version.h>
 #include <linux/init.h>
 #include <asm/pci.h>
 
diff -Nur linux-2.6.0-test5-bk3/arch/mips/momentum/ocelot_g/setup.c linux/arch/mips/momentum/ocelot_g/setup.c
--- linux-2.6.0-test5-bk3/arch/mips/momentum/ocelot_g/setup.c	2003-07-27 14:39:59.000000000 -0400
+++ linux/arch/mips/momentum/ocelot_g/setup.c	2003-09-13 20:09:04.000000000 -0400
@@ -62,7 +62,6 @@
 #include <asm/ptrace.h>
 #include <asm/reboot.h>
 #include <asm/mc146818rtc.h>
-#include <linux/version.h>
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
 #include "gt64240.h"
diff -Nur linux-2.6.0-test5-bk3/arch/mips/pci/fixup-ocelot.c linux/arch/mips/pci/fixup-ocelot.c
--- linux-2.6.0-test5-bk3/arch/mips/pci/fixup-ocelot.c	2003-07-02 18:42:32.000000000 -0400
+++ linux/arch/mips/pci/fixup-ocelot.c	2003-09-13 20:09:07.000000000 -0400
@@ -13,7 +13,6 @@
 #include <linux/types.h>
 #include <linux/pci.h>
 #include <linux/kernel.h>
-#include <linux/version.h>
 #include <linux/init.h>
 #include <asm/pci.h>
 
diff -Nur linux-2.6.0-test5-bk3/arch/mips/pci/ops-ev64120.c linux/arch/mips/pci/ops-ev64120.c
--- linux-2.6.0-test5-bk3/arch/mips/pci/ops-ev64120.c	2003-08-09 06:09:58.000000000 -0400
+++ linux/arch/mips/pci/ops-ev64120.c	2003-09-13 20:09:11.000000000 -0400
@@ -36,7 +36,6 @@
 #include <linux/pci.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
-#include <linux/version.h>
 #include <asm/pci.h>
 #include <asm/io.h>
 #include <asm/galileo-boards/ev64120.h>
diff -Nur linux-2.6.0-test5-bk3/arch/mips/pci/ops-ocelot.c linux/arch/mips/pci/ops-ocelot.c
--- linux-2.6.0-test5-bk3/arch/mips/pci/ops-ocelot.c	2003-08-09 06:09:58.000000000 -0400
+++ linux/arch/mips/pci/ops-ocelot.c	2003-09-13 20:09:13.000000000 -0400
@@ -39,7 +39,6 @@
 #include <linux/pci.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
-#include <linux/version.h>
 #include <linux/cache.h>
 #include <asm/pci.h>
 #include <asm/io.h>
diff -Nur linux-2.6.0-test5-bk3/arch/mips/pci/pci-ocelot-c.c linux/arch/mips/pci/pci-ocelot-c.c
--- linux-2.6.0-test5-bk3/arch/mips/pci/pci-ocelot-c.c	2003-08-09 06:09:58.000000000 -0400
+++ linux/arch/mips/pci/pci-ocelot-c.c	2003-09-13 20:09:16.000000000 -0400
@@ -26,7 +26,6 @@
 #include <linux/pci.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
-#include <linux/version.h>
 #include <asm/pci.h>
 #include <asm/io.h>
 #include <asm/mv64340.h>
diff -Nur linux-2.6.0-test5-bk3/arch/mips/pci/pci-ocelot-g.c linux/arch/mips/pci/pci-ocelot-g.c
--- linux-2.6.0-test5-bk3/arch/mips/pci/pci-ocelot-g.c	2003-08-09 06:09:58.000000000 -0400
+++ linux/arch/mips/pci/pci-ocelot-g.c	2003-09-13 20:09:19.000000000 -0400
@@ -26,7 +26,6 @@
 #include <linux/pci.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
-#include <linux/version.h>
 #include <asm/pci.h>
 #include <asm/io.h>
 #include "gt64240.h"
diff -Nur linux-2.6.0-test5-bk3/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
--- linux-2.6.0-test5-bk3/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c	2003-09-08 20:00:37.000000000 -0400
+++ linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c	2003-09-13 20:09:27.000000000 -0400
@@ -132,7 +132,6 @@
 #include <asm/ptrace.h>
 #include <asm/reboot.h>
 #include <asm/time.h>
-#include <linux/version.h>
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
 #ifdef CONFIG_RTC_DS1742
diff -Nur linux-2.6.0-test5-bk3/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
--- linux-2.6.0-test5-bk3/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	2003-07-27 14:39:59.000000000 -0400
+++ linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c	2003-09-13 20:09:23.000000000 -0400
@@ -60,7 +60,6 @@
 #include <asm/ptrace.h>
 #include <asm/reboot.h>
 #include <asm/time.h>
-#include <linux/version.h>
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
 #include <linux/console.h>


-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html


From Yasushi.SHOJI@atmark-techno.com Sun Sep 14 15:36:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 Sep 2003 15:36:19 +0100 (BST)
Received: from dns1.atmark-techno.com ([IPv6:::ffff:61.199.192.114]:27409 "EHLO
	dns1.atmark-techno.com") by linux-mips.org with ESMTP
	id <S8225208AbTINOgR>; Sun, 14 Sep 2003 15:36:17 +0100
Received: from wat.atmark-techno.com (unknown [192.168.10.81])
	by dns1.atmark-techno.com (Postfix) with ESMTP
	id 4AA443E614; Sun, 14 Sep 2003 23:36:13 +0900 (JST)
Date: Sun, 14 Sep 2003 23:36:13 +0900
From: Yasushi SHOJI <yashi@atmark-techno.com>
To: Pete Popov <ppopov@mvista.com>
Cc: Dan Malek <dan@embeddededge.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: SD/MMC with db1100
In-Reply-To: <1061828175.7493.1.camel@zeus.mvista.com>
References: <20030823232326.2B9AF3E614@dns1.atmark-techno.com>	<3F495FDD.5070407@embeddededge.com>	<1061828175.7493.1.camel@zeus.mvista.com>
User-Agent: User-Agent: Wanderlust/2.10.1
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20030914143613.4AA443E614@dns1.atmark-techno.com>
Return-Path: <Yasushi.SHOJI@atmark-techno.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3178
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yashi@atmark-techno.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1020
Lines: 34

At 25 Aug 2003 09:16:15 -0700,
Pete Popov wrote:
> 
> On Sun, 2003-08-24 at 18:01, Dan Malek wrote:
> > Yasushi SHOJI wrote:
> > 
> > > Could someone enlighten me what's wrong with my code? or does anyone
> > > successfully used sd/mmc on au1?
> > 
> > There is a patch in Ralf's hands for the sd/mmc on this board.  If
> > it doesn't show up soon, we'll find a way to get it to you.
> 
> It's been there for a little while now -- a couple of weeks or so I
> think.
> 
> ftp.linux-mips.org:/pub/linux/mips/people/ppopov/au1x_mmc.patch

Thanks for the patch, Dan and Pete.

I just got back from vacation and tried the patch. The result was same
as what I tested with my code. My card doesn't respond to Command 1,
MMC_SEND_OP_COND.

The controller _seems_ sending the command on the data line; I checked
with logic analyzer.

I've been using Panasonic's SD card, RP-SD064B; and Hagiwara syscom's
MMC card, HB28D032MM2.

is there anything that I need to do use SD other than the patch?

thanks in advance,
--
       yashi

From ralf@linux-mips.org Sun Sep 14 22:21:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 Sep 2003 22:21:52 +0100 (BST)
Received: from p508B7344.dip.t-dialin.net ([IPv6:::ffff:80.139.115.68]:37774
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225374AbTINVVu>; Sun, 14 Sep 2003 22:21:50 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8ELLkLT021588;
	Sun, 14 Sep 2003 23:21:46 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8ELLkhQ021587;
	Sun, 14 Sep 2003 23:21:46 +0200
Date: Sun, 14 Sep 2003 23:21:46 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: rwhron@earthlink.net
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] version.h cleanup of arch/mips
Message-ID: <20030914212146.GB21051@linux-mips.org>
References: <20030914001453.GA27609@rushmore>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030914001453.GA27609@rushmore>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3179
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 271
Lines: 9

On Sat, Sep 13, 2003 at 08:14:53PM -0400, rwhron@earthlink.net wrote:

> version.h is included in some files that don't need it.
> Removing the unnessary includes prevents extra compiles when
> version.h changes.  Patch against 2.6.0-test5-bk3.

Thanks, applied.

  Ralf

From guangxing@ict.ac.cn Mon Sep 15 03:27:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 Sep 2003 03:27:28 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:63211 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225387AbTIOC10> convert rfc822-to-8bit;
	Mon, 15 Sep 2003 03:27:26 +0100
Received: (qmail 13555 invoked from network); 15 Sep 2003 02:13:36 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 15 Sep 2003 02:13:36 -0000
From: "=?GB2312?Q?=B9=E3=D0=C7?=" <guangxing@ict.ac.cn>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: How to implement the combination of signal and alarm in the Kenel Module?
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Mon, 15 Sep 2003 10:27:46 +0800
Message-Id: <20030915022726Z8225387-1272+5432@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3180
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 680
Lines: 21

Hi,everyone!
   As my experience, in the application level we can use  the combination of signal() and alarm() to  
implement some simple works ,such as doing some scheduled task at a certain time, invoke some routine 
after a certain time...Now one thing confused me.I thing in the kernel module we can implement the same works.
And I have tried to use the  queue_task(&Task, &tq_timer),but when i try to "insmod", the LINUX will broken.
Who can tell why?And hoew to implement the combination of signal and alarm in the Kenel Module?
   Thank you in advance!


	

¡¡  ×£
½¡¿µ Óä¿ì
 				

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¹ãÐÇ
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-15




From guangxing@ict.ac.cn Mon Sep 15 12:02:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 Sep 2003 12:02:57 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:11672 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225390AbTIOLCz> convert rfc822-to-8bit;
	Mon, 15 Sep 2003 12:02:55 +0100
Received: (qmail 1806 invoked from network); 15 Sep 2003 10:49:05 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 15 Sep 2003 10:49:05 -0000
From: "=?GB2312?Q?=B9=E3=D0=C7?=" <guangxing@ict.ac.cn>
To: =?GB2312?Q?=D0=BB=B2=A9=CA=BF?= <xie@ict.ac.cn>
CC: angela <jhyang@ict.ac.cn>,
 linux-mips@linux-mips.org <linux-mips@linux-mips.org>,
 =?GB2312?Q?=B2=CC=C0=F6?= <raon@ict.ac.cn>,
 =?GB2312?Q?=B3=C2=C8=D9?= <chenrong@ict.ac.cn>,
 =?GB2312?Q?=B7=B6=B3=AC?= <fanchao@ict.ac.cn>,
 =?GB2312?Q?=C0=E8=CE=C4=CE=B0?= <liww@ict.ac.cn>,
 =?GB2312?Q?=C2=ED=CE=AC=95F?= <mawm@ict.ac.cn>,
 =?GB2312?Q?=CC=EF=D2=B0?= <jack_ty@ict.ac.cn>,
 =?GB2312?Q?=CD=F5=BF=A1=B7=E5?= <wangjf@ict.ac.cn>,
 =?GB2312?Q?=CD=F5=C8=CE=B6=B0?= <wrdong@ict.ac.cn>,
 =?GB2312?Q?=D0=BB=F6=EF?= <xiekun@ict.ac.cn>
Subject: =?GB2312?Q?(13810545536)=B9=E3=D0=C7=B5=C4=D0=C2=B5=C4=CA=D6=BB=FA=BA=C5=C2=EB?=
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Mon, 15 Sep 2003 19:3:18 +0800
Message-Id: <20030915110255Z8225390-1272+5444@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3181
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 192
Lines: 16

´ó¼ÒºÃ,ÏÂÃæÄã¿´µ½µÄÊǹãÐǵÄеÄÊÖ»úºÅÂë!
13810545536.
¶à¶àÁªÂç,¶à¶àÁ¬Âç!

	

¡¡  ×£
½¡¿µ Óä¿ì
 				

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¹ãÐÇ
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-15




From tovbin@niisi.msk.ru Mon Sep 15 14:56:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 Sep 2003 14:56:27 +0100 (BST)
Received: from [IPv6:::ffff:193.232.173.35] ([IPv6:::ffff:193.232.173.35]:42996
	"EHLO tux.NIISI") by linux-mips.org with ESMTP id <S8225404AbTION4X>;
	Mon, 15 Sep 2003 14:56:23 +0100
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tux.NIISI (8.11.6/8.11.6) with ESMTP id h8FDtfd08089
	for <linux-mips@linux-mips.org>; Mon, 15 Sep 2003 17:55:41 +0400
Date: Mon, 15 Sep 2003 17:55:41 +0400 (MSD)
From: Tommy Tovbin <tovbin@niisi.msk.ru>
X-X-Sender: tovbin@tux.NIISI
To: linux-mips@linux-mips.org
Subject: Problem with passwd&cracklib
Message-ID: <Pine.LNX.4.44.0309151751430.8078-100000@tux.NIISI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <tovbin@niisi.msk.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3182
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tovbin@niisi.msk.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 286
Lines: 12

Hi All! 

I cross-compiled the passwd-0.67-1 and cracklib,2.7, and then I try to 
execute passwd, i get error:
usr/lib/cracklib_dict: magic mismatch
PWOpen: Success

My filesystem is not writeable. Can somebody help me?

-- 
With regards, Tommy Tovbin. tovbin at niisi dot msk dot ru.


From craig.mautner@pioneer-pdt.com Mon Sep 15 20:01:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 Sep 2003 20:01:03 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:62442
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225408AbTIOTBB>; Mon, 15 Sep 2003 20:01:01 +0100
Received: from PEPELEPEW ([172.30.1.10]) by ns.pioneer-pdt.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68491U100L2S100V35)
          with SMTP id com for <linux-mips@linux-mips.org>;
          Mon, 15 Sep 2003 12:03:36 -0700
From: craig.mautner@pioneer-pdt.com (Craig Mautner)
To: <linux-mips@linux-mips.org>
Subject: RE: schedule() BUG
Date: Mon, 15 Sep 2003 11:59:50 -0700
Message-ID: <JKEMLDJFFLGLICKLLEFJKEFNCOAA.craig.mautner@pioneer-pdt.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-reply-to: <JKEMLDJFFLGLICKLLEFJMEEOCOAA.craig.mautner@alumni.ucsd.edu>
Return-Path: <craig.mautner@pioneer-pdt.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3183
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: craig.mautner@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips
Content-Length: 574
Lines: 17

Regarding my previous posting, we had made the assumption that schedule()
could be called from an interrupt that occured within schedule(). However,
because schedule() is in the kernel, ret_from_irq will skip over the call to
schedule() and simply restore the context.

-Craig

-.     .-.     .-_     Craig Mautner
  \   /   \   / / `    Coastal Sr. Consulting, Inc.
   `-'     `-'  `---   (858)361-2683
                       (858)581-0542 (fax)
5580 La Jolla Blvd. #308 La Jolla, CA 92037
mailto:craig.mautner@alumni.ucsd.edu
http://home.san.rr.com/cmautner/csc/craig/




From craig.mautner@alumni.ucsd.edu Mon Sep 15 20:10:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 Sep 2003 20:10:13 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:62163
	"HELO 127.0.0.1") by linux-mips.org with SMTP id <S8225408AbTIOTKL>;
	Mon, 15 Sep 2003 20:10:11 +0100
From: "Craig Mautner" <craig.mautner@alumni.ucsd.edu>
To: <linux-mips@linux-mips.org>
Subject: RE: schedule() BUG
Date: Sat, 13 Sep 2003 09:30:29 -0700
Message-ID: <JKEMLDJFFLGLICKLLEFJGEFECOAA.craig.mautner@alumni.ucsd.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-reply-to: <JKEMLDJFFLGLICKLLEFJMEEOCOAA.craig.mautner@alumni.ucsd.edu>
Return-Path: <craig.mautner@alumni.ucsd.edu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3184
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: craig.mautner@alumni.ucsd.edu
Precedence: bulk
X-list: linux-mips
Content-Length: 574
Lines: 17

Regarding my previous posting, we had made the assumption that schedule()
could be called from an interrupt that occured within schedule(). However,
because schedule() is in the kernel, ret_from_irq will skip over the call to
schedule() and simply restore the context.

-Craig

-.     .-.     .-_     Craig Mautner
  \   /   \   / / `    Coastal Sr. Consulting, Inc.
   `-'     `-'  `---   (858)361-2683
                       (858)581-0542 (fax)
5580 La Jolla Blvd. #308 La Jolla, CA 92037
mailto:craig.mautner@alumni.ucsd.edu
http://home.san.rr.com/cmautner/csc/craig/




From guangxing@ict.ac.cn Tue Sep 16 02:28:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 02:28:31 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:38846 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225408AbTIPB23>;
	Tue, 16 Sep 2003 02:28:29 +0100
Received: (qmail 4688 invoked from network); 16 Sep 2003 01:14:29 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 16 Sep 2003 01:14:29 -0000
From: "=?GB2312?Q?=B9=E3=D0=C7?=" <guangxing@ict.ac.cn>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Sorry for my ignorance
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: multipart/mixed;
      boundary="=====000_Dragon337632027063_====="
Date: Tue, 16 Sep 2003 9:28:51 +0800
Message-Id: <20030916012829Z8225408-1272+5461@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3185
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 2455
Lines: 56

This is a multi-part message in MIME format.

--=====000_Dragon337632027063_=====
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: quoted-printable

Hi,everybody
    I must say sorry to everyone for my ignorance and=
 carelessness of my yesterday's mail.
As you can be aware of ,I am a newbie to here!I do not know the=
 rules clearly.
    An enthusiastic friend told me that my mail will made all=
 anti-spam systems ring alarm,
Now I have changed the format of my mail to simple text instead=
 of HTML format.
    Allow me to say  SORRY, SORRY,SORRY!~ 
=09

=A1=A1  =D7=A3
=BD=A1=BF=B5 =D3=E4=BF=EC
 =09=09=09=09

=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=B9=E3=D0=C7
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1guangxing@ict.ac.cn
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12003-09-16


--=====000_Dragon337632027063_=====
Content-Type: image/gif;
      name="LittleBoy.GIF"
Content-Transfer-Encoding: base64
Content-Disposition: FoxmailIcon;
      filename="LittleBoy.GIF"

R0lGODlhIAAgANQAAGCXzwCAgGBnYP/IkPzJmpFjPBsNA2Q8HxQDACIGAk4HADYDAA0AAP///wAA
ANPT05KSkm5ubmVlZUZGRiUlJRgYGBEREQ8PDwcHBwMDAwAAAAAAAAAAAAAAAAAAAAAAACH/C05F
VFNDQVBFMi4wAwEAAAAh/sJodHRwOi8vd3d3LnJ0bHNvZnQuY29tL2FuaW1hZ2ljLwoKQ3JlYXRl
ZCB3aXRoIEFuaW1hZ2ljIEdJRiBWIDEuMjJhCmJ5IFJpZ2h0IHRvIExlZnQgU29mdHdhcmUgSW5j
LgoKVG8gc3VwcHJlc3MgdGhpcyBtZXNzYWdlIGluIHRoZSByZWdpc3RlcmVkIHZlcnNpb24KdW5j
aGVjayAiT3B0aW9ucyB8IEFuaW1hZ2ljIGNvbW1lbnQgZnJhbWUiCgAh+QQJGQABACwAAAAAIAAg
AAAF1mAgjmRpnmiqrqrjvjCLugNsO3LpDPz91rgcggf07XqyYa/nI9ZWytqy6HQGT1HrtEq8mhjc
45b7NImB5DTSrP6py6UoLfweLEwGpuBcJ95LYEANYm5vfyQOeQ4Ng12LfFyHIw5gi41AApdqkiIO
CUxdjJppnAGBYYyQBQUERAoleW2QRAWuJFmOfbW1rySnfVy7A70jsV3ARAc8xCO/RXNkC8rDWGGz
ZAgpzsgD2Srbfd4rCZ/ALjki5OXWXjKWoz2D6AEvooM2ojEtAADvqfz+BgE0EQIAIfkECRkAAQAs
AAAAACAAIAAABc5gII5kaZ5oqq6q474wi7oDbDty6Qz8/da4HIIH9O16smGv5yPWVsrasuh0Bk9R
67RKvJoY3OOW+zSJgeQ00qz+qculKC38HixMhum5TryXwFKBVHV+JA55R2KJhGZgMFt7XIUjDglM
XZhvkyKAYW5OBQUERAoleW2RRAWkJFldqVWrq6UknXxcsgO0I6eZtwMHPLsjtkVzZAvBulievwgp
xb8DzyrRfNQrCZa3Ljki2tueXjIODeaR5eMrL+bnNu0xLQAA5e0NDvP18PkmIQAh+QQJGQABACwA
AAAAIAAgAAAF02AgjmRpnmiqrqrjvjCLug9sO3LpPPz91rgchgf07XqyYa/nI9ZWytqy6HQGT1Hr
tEq8mjLc45b7NImB5DTSrP6py6UoLfx+VEwWpuRcJ95LYEANYm5vfyQOeQ4Ng12LfFyHIw5gi41A
EpdqkiIOF0xdjJppnAGBYYyQERFOFCV5bZBErDyuI1mOfaystiOnfVy7D70isF3ARBO1X1U2m8rD
WGGyZBgpv8g81irYwNsrF5/ALjki4eLTXjKWoz2D5QEvooM2ojEtEBDsqfn7g/0mQgAAOw==

--=====000_Dragon337632027063_=====--


From guangxing@ict.ac.cn Tue Sep 16 02:53:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 02:53:33 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:51903 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225412AbTIPBxb> convert rfc822-to-8bit;
	Tue, 16 Sep 2003 02:53:31 +0100
Received: (qmail 15449 invoked from network); 16 Sep 2003 01:39:34 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 16 Sep 2003 01:39:34 -0000
From: "=?GB2312?Q?=B9=E3=D0=C7?=" <guangxing@ict.ac.cn>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Question about the tq_timer or sleep_on() !
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Tue, 16 Sep 2003 9:53:57 +0800
Message-Id: <20030916015331Z8225412-1272+5464@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3186
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 3899
Lines: 138

Hi,everyone!
	
    I have written a simple kernel module following the example in "Chapter 11. 
Scheduling Tasks" of <<The Linux Kernel Module Programming Guide>> 
(http://www.faqs.org/docs/kernel/x1145.html#AEN1201).
    Because I only want to scheduale a function to be called on every timer 
interrupt,I have simplified the example in the following as you can see.
    It can be compiled ok, and it can be "insmod" correctly.But when I try
 to "rmmod" ,sometimes my LINUX freeze and somtimes it will reboot automatically.
    My linux version is 2.4.18-3.
    And I have read the  "Chapter 11.Scheduling Tasks" of <<The Linux Kernel Module
 Programming Guide>> ,I think it the combination of tq_timer and sleep_on() arose the
 fatal error. But I do not know why and how to conquer it.
    
    Anyone can tell why? And are there any good others methods to implement schedualing
 a function to be called on every timer interrupt or on every second?
    
     Eagering your help and thank you in advance!
	


 /*  sched.c - scheduale a function to be called on every timer interrupt.
 *
 *  Copyright (C) 2001 by Peter Jay Salzman
 */

/* The necessary header files */

/* Standard in kernel modules */
#include <linux/kernel.h>                   /* We're doing kernel work */
#include <linux/module.h>                   /* Specifically, a module */

/* Deal with CONFIG_MODVERSIONS */
/*
#if CONFIG_MODVERSIONS==1
#define MODVERSIONS
#include <linux/modversions.h>
#endif        
*/
/* Necessary because we use the proc fs */
#include <linux/proc_fs.h>
#include <linux/interrupt.h>

/* We scheduale tasks here */
#include <linux/tqueue.h>

/* We also need the ability to put ourselves to sleep and wake up later */
#include <linux/sched.h>

/* In 2.2.3 /usr/include/linux/version.h includes a macro for this, but
 * 2.0.35 doesn't - so I add it here if necessary.
 */
#ifndef KERNEL_VERSION
#define KERNEL_VERSION(a,b,c) (((a)<<16)+((b)<<8)+(c))
#endif

/*Basic Info. of this module
*/
MODULE_LICENSE("GPL");           // Get rid of taint message by declaring code as GPL
MODULE_DESCRIPTION("Just to test!"); // What does this module do?

/* The number of times the timer interrupt has been called so far */
static int TimerIntrpt = 0;

/* This is used by cleanup, to prevent the module from being unloaded while
 * intrpt_routine is still in the task queue
 */
static struct wait_queue *WaitQ = NULL;

static void intrpt_routine(void *);

/* The task queue structure for this task, from tqueue.h */
static struct tq_struct Task = {
   {NULL,NULL},   /* Next item in list - queue_task will do this for us */
   0,             /* A flag meaning we haven't been inserted into a task
                   * queue yet 
                   */
   intrpt_routine, /* The function to run */
   NULL,           /* The void* parameter for that function */
};

/* This function will be called on every timer interrupt. Notice the void*
 * pointer - task functions can be used for more than one purpose, each time 
 * getting a different parameter.
 */
static void intrpt_routine(void *irrelevant)
{
   	/* Increment the counter */
   	TimerIntrpt++;
   	//printk("<1>Ok,It is the time to do something!\n");
   	if (WaitQ != NULL){
   		wake_up(&WaitQ);
   		return;
   	}
   	else {	
      		if ((TimerIntrpt%1000)==0){
			printk("<1>It is the time to do something!\n");
       		}
      		queue_task(&Task, &tq_timer);
       	}
 
}



/* Initialize the module - register the proc file */
int init_module()
{
   /* Put the task in the tq_timer task queue, so it will be executed at
    * next timer interrupt
    */
 	queue_task(&Task, &tq_timer);
  	printk("<1>Insert It Ok\n");
   	return 0;
  
}

/* Cleanup */
void cleanup_module()
{
   printk("<1>Say 886\n");
   sleep_on(&WaitQ);
}  

¡¡



  ×£
½¡¿µ Óä¿ì
 				

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¹ãÐÇ
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-16




From guangxing@ict.ac.cn Tue Sep 16 04:50:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 04:50:34 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:51396 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225210AbTIPDub> convert rfc822-to-8bit;
	Tue, 16 Sep 2003 04:50:31 +0100
Received: (qmail 31828 invoked from network); 16 Sep 2003 03:36:29 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 16 Sep 2003 03:36:29 -0000
From: "Guangxing Zhang" <guangxing@ict.ac.cn>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Re: Re: Question about the tq_timer or sleep_on() !
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Tue, 16 Sep 2003 11:50:51 +0800
Message-Id: <20030916035031Z8225210-1272+5473@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3187
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 6153
Lines: 191

Hi, Fuxin Zhang

======= 2003-09-16 11:22:00 WROTE£º=======

>I am not sure why you send a generic kernel problem to linux/mips list.   
    Oh~~~Sorry ,Sorry ,I have to say sorry sorry agian and again!
    My purpose is to port my kernel module to mips-linux and I have the
crosse-compile environment.So generally, if it (kernle module) can be ok
in my linux(nor mips),it also do not have any troubles when I port it to 
the mips-linux.I have test it before.(Of course ,only with  some simple
kernle modules) . 
>As to your problem, probably it is caused by some incompatible changes
>between different kernel versions. Many kernel related codes are highly
>version depended. Check the datastructs, add -Wall to compile and check
    "-Wall" exsits before and following is part of my original Makefile:
    -------------------------------------------------------------- 
    WARN    := -W -Wall -Wstrict-prototypes -Wmissing-prototypes
    INCLUDE := -isystem /lib/modules/`uname -r`/build/include
    CFLAGS  := -O2 -DMODULE -D__KERNEL__ ${WARN} ${INCLUDE}
    CC      := gcc
    OBJS    := ${patsubst %.c, %.o, ${wildcard *.c}}
    all: ${OBJS} 
    --------------------------------------------------------------
>for any warnings. BTW, I don't the method you used to cleanup is safe,
>there maybe a task queued but not executed at the time you 
>'rmmod',doesn't it?
Yes ,in http://www.faqs.org/docs/kernel/x1145.html#AEN1201 , it mentions the 
situation as you said.And just to overcoming it ,it use the sleep_on().But as you 
see, now it can not "rmmod" correctly and my linux will broke.

As a newbie to kernel module ,I am not sure why and not know how to scheduale a 
function to be called on every timer interrupt or every seconds in kernle module.
Eagering your help!
>>interrupt
>
>¹ãÐÇ wrote:
>
>>Hi,everyone!
>>	
>>    I have written a simple kernel module following the example in "Chapter 11. 
>>Scheduling Tasks" of <<The Linux Kernel Module Programming Guide>> 
>>(http://www.faqs.org/docs/kernel/x1145.html#AEN1201).
>>    Because I only want to scheduale a function to be called on every timer 
>>interrupt,I have simplified the example in the following as you can see.
>>    It can be compiled ok, and it can be "insmod" correctly.But when I try
>> to "rmmod" ,sometimes my LINUX freeze and somtimes it will reboot automatically.
>>    My linux version is 2.4.18-3.
>>    And I have read the  "Chapter 11.Scheduling Tasks" of <<The Linux Kernel Module
>> Programming Guide>> ,I think it the combination of tq_timer and sleep_on() arose the
>> fatal error. But I do not know why and how to conquer it.
>>    
>>    Anyone can tell why? And are there any good others methods to implement schedualing
>> a function to be called on every timer interrupt or on every second?
>>    
>>     Eagering your help and thank you in advance!
>>	
>>
>>
>> /*  sched.c - scheduale a function to be called on every timer interrupt.
>> *
>> *  Copyright (C) 2001 by Peter Jay Salzman
>> */
>>
>>/* The necessary header files */
>>
>>/* Standard in kernel modules */
>>#include <linux/kernel.h>                   /* We're doing kernel work */
>>#include <linux/module.h>                   /* Specifically, a module */
>>
>>/* Deal with CONFIG_MODVERSIONS */
>>/*
>>#if CONFIG_MODVERSIONS==1
>>#define MODVERSIONS
>>#include <linux/modversions.h>
>>#endif        
>>*/
>>/* Necessary because we use the proc fs */
>>#include <linux/proc_fs.h>
>>#include <linux/interrupt.h>
>>
>>/* We scheduale tasks here */
>>#include <linux/tqueue.h>
>>
>>/* We also need the ability to put ourselves to sleep and wake up later */
>>#include <linux/sched.h>
>>
>>/* In 2.2.3 /usr/include/linux/version.h includes a macro for this, but
>> * 2.0.35 doesn't - so I add it here if necessary.
>> */
>>#ifndef KERNEL_VERSION
>>#define KERNEL_VERSION(a,b,c) (((a)<<16)+((b)<<8)+(c))
>>#endif
>>
>>/*Basic Info. of this module
>>*/
>>MODULE_LICENSE("GPL");           // Get rid of taint message by declaring code as GPL
>>MODULE_DESCRIPTION("Just to test!"); // What does this module do?
>>
>>/* The number of times the timer interrupt has been called so far */
>>static int TimerIntrpt = 0;
>>
>>/* This is used by cleanup, to prevent the module from being unloaded while
>> * intrpt_routine is still in the task queue
>> */
>>static struct wait_queue *WaitQ = NULL;
>>
>>static void intrpt_routine(void *);
>>
>>/* The task queue structure for this task, from tqueue.h */
>>static struct tq_struct Task = {
>>   {NULL,NULL},   /* Next item in list - queue_task will do this for us */
>>   0,             /* A flag meaning we haven't been inserted into a task
>>                   * queue yet 
>>                   */
>>   intrpt_routine, /* The function to run */
>>   NULL,           /* The void* parameter for that function */
>>};
>>
>>/* This function will be called on every timer interrupt. Notice the void*
>> * pointer - task functions can be used for more than one purpose, each time 
>> * getting a different parameter.
>> */
>>static void intrpt_routine(void *irrelevant)
>>{
>>   	/* Increment the counter */
>>   	TimerIntrpt++;
>>   	//printk("<1>Ok,It is the time to do something!\n");
>>   	if (WaitQ != NULL){
>>   		wake_up(&WaitQ);
>>   		return;
>>   	}
>>   	else {	
>>      		if ((TimerIntrpt1000)==0){
>>			printk("<1>It is the time to do something!\n");
>>       		}
>>      		queue_task(&Task, &tq_timer);
>>       	}
>> 
>>}
>>
>>
>>
>>/* Initialize the module - register the proc file */
>>int init_module()
>>{
>>   /* Put the task in the tq_timer task queue, so it will be executed at
>>    * next timer interrupt
>>    */
>> 	queue_task(&Task, &tq_timer);
>>  	printk("<1>Insert It Ok\n");
>>   	return 0;
>>  
>>}
>>
>>/* Cleanup */
>>void cleanup_module()
>>{
>>   printk("<1>Say 886\n");
>>   sleep_on(&WaitQ);
>>}  
>>
>>¡¡
>>
>>
>>
>>  ×£
>>½¡¿µ Óä¿ì
>> 				
>>
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¹ãÐÇ
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-16
>>
>>
>>
>>
>>
>>
>>  
>>

= = = = = = = = = = = = = = = = = = = =
			
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-16




From guangxing@ict.ac.cn Tue Sep 16 10:15:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 10:15:38 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:14039 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225352AbTIPJPe> convert rfc822-to-8bit;
	Tue, 16 Sep 2003 10:15:34 +0100
Received: (qmail 1540 invoked from network); 16 Sep 2003 09:01:33 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 16 Sep 2003 09:01:33 -0000
From: "Guangxing Zhang" <guangxing@ict.ac.cn>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: kernel module problems with tq_timer on mips_linux
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Tue, 16 Sep 2003 17:16:0 +0800
Message-Id: <20030916091534Z8225352-1272+5481@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3188
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 5251
Lines: 154

Hi, Everyone ,
    I have written a simple kernle module for the mips_linux (2.4.20-pre6-sb20021114-1).
It can work well in my linux(2.4.18-3 ,not for mips),but when I port it to mips_linux some
error occur(when i try to "insmod" , there is the error report!).
    In my kernle module , I use the tq_timer and queue_task() to implement scheduale a
function to be called on every timer interrupt.In the bottom , there is my source codes.
Of course it is a simplified verison of the example of "Chapter 11.Scheduling Tasks" of 
<<The Linux Kernel Module Programming Guide>>. 
    The error it reports is as follow and use "lsmod" I can see my kernle module is here .
    Anyone can tell why ? Eagering your helps!~ 
    Thank you in advance!
-----------------------------------------------------------------------------------
[root@(none) root]# insmod sch_example.o 
Unhandled kernel unaligned access in unaligned.c::emulate_load_store_insn, line:
$0 : 00000000 30001f00 00000001 00000040 c11291d0 00000002 c112946c 81000020
$8 : 00000000 b00200c8 00000000 00000000 00000000 2acf114c 00000000 00000000
$16: ffffffea c1129000 0000000b 00000060 8fe02ea0 0000000b 8d427000 1000ab40
$24: 00000000 2ac4d2a0                   80714000 80715e78 1000ae70 8011714c
Hi : 0877c629
Lo : 4672619f
epc  : c11291e4    Not tainted
Status: 30001f03
Cause : 00808010
Process insmod (pid: 104, stackpage=80714000)
Stack:    c1129000 c1129480 ffffffea c1129000 8011714c 80133e1c 8034d500
 00030002 00000000 80139158 00000060 c1124000 c1129060 00000480 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 8d426000 80b67f60 1000a628 10008ad8 1000aae0
 00000000 ...
Call Trace:   [<c1129480>] [<8011714c>] [<80133e1c>] [<80139158>] [<c1129060>]
 [<8010aef4>]

Code: 3c06c113  24c6946c  24020001 <d0c40008> 00821825  f0c30008  1060fffc  008
Segmentation fault
------------------------------------------------------------------------------------
------------------------------------------------------------------------------------
[root@(none) root]# lsmod
Module                  Size  Used by    Not tainted
sch_example             1152   1  (initializing)
-------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
/*  sched.c - scheduale a function to be called on every timer interrupt.
 *
 *  Copyright (C) 2001 by Peter Jay Salzman
 */

/* The necessary header files */

/* Standard in kernel modules */
#include <linux/kernel.h>                   /* We're doing kernel work */
#include <linux/module.h>                   /* Specifically, a module */

#include <linux/interrupt.h>

/* We scheduale tasks here */
#include <linux/tqueue.h>

/* We also need the ability to put ourselves to sleep and wake up later */
#include <linux/sched.h>

/* In 2.2.3 /usr/include/linux/version.h includes a macro for this, but
 * 2.0.35 doesn't - so I add it here if necessary.
 */
#ifndef KERNEL_VERSION
#define KERNEL_VERSION(a,b,c) (((a)<<16)+((b)<<8)+(c))
#endif

/*Basic Info. of this module
*/
MODULE_LICENSE("GPL");           // Get rid of taint message by declaring code as GPL
MODULE_DESCRIPTION("Just to test!"); // What does this module do?

/* The number of times the timer interrupt has been called so far */
static int TimerIntrpt = 0;

/* This is used by cleanup, to prevent the module from being unloaded while
 * intrpt_routine is still in the task queue
 */
static volatile int my_ctl = 0;

static void intrpt_routine(void *);

/* The task queue structure for this task, from tqueue.h */
static struct tq_struct Task = {
   {NULL,NULL},   /* Next item in list - queue_task will do this for us */
   0,             /* A flag meaning we haven't been inserted into a task
                   * queue yet 
                   */
   intrpt_routine, /* The function to run */
   NULL,           /* The void* parameter for that function */
};

/* This function will be called on every timer interrupt. Notice the void*
 * pointer - task functions can be used for more than one purpose, each time 
 * getting a different parameter.
 */
static void intrpt_routine(void *irrelevant)
{
   	/* Increment the counter */
   	TimerIntrpt++;
   	//printk("<1>Ok,It is the time to do something!\n");
   	//if (WaitQ != NULL){
   	if (my_ctl==1){
   		//wake_up(&WaitQ);
   		my_ctl = 0;
   		return;
   	}
   	else {	
      		if ((TimerIntrpt%1000)==0){
			printk("<1>It is the time to do something!\n");
       		}
      		queue_task(&Task, &tq_timer);
       	}
 
}



/* Initialize the module */
int init_module()
{
   /* Put the task in the tq_timer task queue, so it will be executed at
    * next timer interrupt
    */
 	queue_task(&Task, &tq_timer);
  	printk("<1>Insert It Ok\n");
   	return 0;
  
}

/* Cleanup */
void cleanup_module()
{
   printk("<1>Say 886\n");
   my_ctl = 1;
   while (my_ctl);
   //sleep_on(&WaitQ);
}  

--------------------------------------------------------------------------------------

    

	

¡¡	

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-16




From guangxing@ict.ac.cn Tue Sep 16 10:33:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 10:33:44 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:49368 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225414AbTIPJd1> convert rfc822-to-8bit;
	Tue, 16 Sep 2003 10:33:27 +0100
Received: (qmail 8231 invoked from network); 16 Sep 2003 09:17:00 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 16 Sep 2003 09:17:00 -0000
From: "Guangxing Zhang" <guangxing@ict.ac.cn>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: It is ok on linux ,but not ok on mips_linux as my expection!
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Tue, 16 Sep 2003 17:31:24 +0800
Message-Id: <20030916093341Z8225414-1272+5484@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3189
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 1734
Lines: 57

Hi, 

	    Inspired by your advice , I have changed the method of preventing the module 
from being unloaded while "intrpt_routine" is still in the task queue.Now it can freely 
"insmod" and "rmmod" in my linux(2.4.18-3,not on mips) at  any time.But unfortunatlly,
When I port it to mips_linux, it get some errors as you can see in my mail to 
linux-mips@linux-mips.org . It confuses me .Why? And what should I MUST pay attention to
or what should I MUST learn if I I want to implement schedualing a function to be called
on every timer interrupt.

        Thank you again and eagering your enthusiastic again! 
 

======= 2003-09-16 13:17:00 WROTE£º=======

>Guangxing Zhang wrote:
>
>>Hi, Fuxin Zhang
>>
>>  
>>
>>>for any warnings. BTW, I don't the method you used to cleanup is safe,
>>>there maybe a task queued but not executed at the time you 
>>>'rmmod',doesn't it?
>>>    
>>>
>>Yes ,in http://www.faqs.org/docs/kernel/x1145.html#AEN1201 , it mentions the 
>>situation as you said.And just to overcoming it ,it use the sleep_on().But as you 
>>see, now it can not "rmmod" correctly and my linux will broke.
>>
>>As a newbie to kernel module ,I am not sure why and not know how to scheduale a 
>>function to be called on every timer interrupt or every seconds in kernle module.
>>Eagering your help!
>>  
>>
>>>>interrupt
>>>>      
>>>>
>
>Most ethernet adapter driver(e.g. drivers/net/eepro100.c) use timer,you 
>can check them for examples.
>
>
>Have you check the sleep_on and wakeup routine's argument type? They 
>should be wait_queue_head_t *
>for recent kernels?

= = = = = = = = = = = = = = = = = = = =
			
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-16




From dafastidio@libero.it Tue Sep 16 10:34:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 10:34:07 +0100 (BST)
Received: from smtp3.libero.it ([IPv6:::ffff:193.70.192.127]:29079 "EHLO
	smtp3.libero.it") by linux-mips.org with ESMTP id <S8225415AbTIPJdk>;
	Tue, 16 Sep 2003 10:33:40 +0100
Received: from libero.it (151.26.176.202) by smtp3.libero.it (7.0.020-DD01)
        id 3F603558001415EB for linux-mips@linux-mips.org; Tue, 16 Sep 2003 11:33:32 +0200
Message-ID: <3F66D796.2030403@libero.it>
Date: Tue, 16 Sep 2003 11:27:50 +0200
From: Massimo Piccioni <dafastidio@libero.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: linux & O2 R5000
References: <20030916091534Z8225352-1272+5481@linux-mips.org>
In-Reply-To: <20030916091534Z8225352-1272+5481@linux-mips.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <dafastidio@libero.it>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3190
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dafastidio@libero.it
Precedence: bulk
X-list: linux-mips
Content-Length: 96
Lines: 9

Hello all,

I'd like to try to install Linux on my O2 R5000.
Is it possible?

Thanks,
Massimo



From guangxing@ict.ac.cn Tue Sep 16 10:49:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 10:49:38 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:42201 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225415AbTIPJtg> convert rfc822-to-8bit;
	Tue, 16 Sep 2003 10:49:36 +0100
Received: (qmail 15791 invoked from network); 16 Sep 2003 09:35:34 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 16 Sep 2003 09:35:34 -0000
From: "Guangxing Zhang" <guangxing@ict.ac.cn>
To: Massimo Piccioni <dafastidio@libero.it>
CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Re: linux & O2 R5000
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Tue, 16 Sep 2003 17:50:1 +0800
Message-Id: <20030916094936Z8225415-1272+5488@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3191
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 513
Lines: 26

Hi, Massimo Piccioni

	As I know it can ,but i do not do that before. But I think you should reference
the http://www.kernel.org/ first to verify the version and the special configuration
fit your architectures.

======= 2003-09-16 11:27:00 WROTE£º=======

>Hello all,
>
>I'd like to try to install Linux on my O2 R5000.
>Is it possible?
>
>Thanks,
>Massimo

= = = = = = = = = = = = = = = = = = = =
			
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-16




From agx@sigxcpu.org Tue Sep 16 10:59:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 10:59:06 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:61676
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225419AbTIPJ7E>; Tue, 16 Sep 2003 10:59:04 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 56ABA2BC3F
	for <linux-mips@linux-mips.org>; Tue, 16 Sep 2003 11:59:02 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 27798-09
 for <linux-mips@linux-mips.org>; Tue, 16 Sep 2003 11:59:00 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 1259F2BC3E
	for <linux-mips@linux-mips.org>; Tue, 16 Sep 2003 11:59:00 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 56FBA4078; Tue, 16 Sep 2003 12:02:20 +0200 (CEST)
Date: Tue, 16 Sep 2003 12:02:20 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: linux & O2 R5000
Message-ID: <20030916100220.GC984@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030916094936Z8225415-1272+5488@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030916094936Z8225415-1272+5488@linux-mips.org>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian)
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3192
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips
Content-Length: 321
Lines: 8

On Tue, Sep 16, 2003 at 05:50:01PM +0800, Guangxing Zhang wrote:
> 	As I know it can ,but i do not do that before. But I think you should reference
> the http://www.kernel.org/ first to verify the version and the special configuration
> fit your architectures.
See
 http://www.linux-mips.org/~glaurung/
Cheers,
 -- Guido

From ladis@linux-mips.org Tue Sep 16 10:59:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 10:59:48 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8225419AbTIPJ7q>; Tue, 16 Sep 2003 10:59:46 +0100
Date: Tue, 16 Sep 2003 10:59:46 +0100
From: Ladislav Michl <ladis@ftp.linux-mips.org>
To: Guangxing Zhang <guangxing@ict.ac.cn>
Cc: Massimo Piccioni <dafastidio@libero.it>,
	"linux-mips @ linux-mips. org" <linux-mips@linux-mips.org>
Subject: Re: linux & O2 R5000
Message-ID: <20030916105946.A13890@ftp.linux-mips.org>
References: <20030916094936Z8225415-1272+5488@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030916094936Z8225415-1272+5488@linux-mips.org>; from guangxing@ict.ac.cn on Tue, Sep 16, 2003 at 05:50:01PM +0800
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3193
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@ftp.linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 523
Lines: 14

On Tue, Sep 16, 2003 at 05:50:01PM +0800, Guangxing Zhang wrote:
> Hi, Massimo Piccioni
> 
> As I know it can ,but i do not do that before. But I think you should
> reference the http://www.kernel.org/ first to verify the version and
> the special configuration fit your architectures.

kernel.org is not the best place to look for such informations.
try following:
http://www.linux-mips.org/~glaurung/
http://www.total-knowledge.com/progs/mips/o2-howto.shtml
and generaly try google before asking such question :)

	ladis

From fxzhang@ict.ac.cn Tue Sep 16 11:16:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Sep 2003 11:16:26 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:43482 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225419AbTIPKQQ>;
	Tue, 16 Sep 2003 11:16:16 +0100
Received: (qmail 25948 invoked from network); 16 Sep 2003 10:02:13 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.187)
  by mail.ict.ac.cn with SMTP; 16 Sep 2003 10:02:13 -0000
Message-ID: <3F66E2DC.8030007@ict.ac.cn>
Date: Tue, 16 Sep 2003 18:15:56 +0800
From: Fuxin Zhang <fxzhang@ict.ac.cn>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: zh-cn, en-us, en
MIME-Version: 1.0
To: Guangxing Zhang <guangxing@ict.ac.cn>
CC: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: It is ok on linux ,but not ok on mips_linux as my expection!
Content-Type: text/plain; charset=gb18030; format=flowed
Content-Transfer-Encoding: 8bit
Return-Path: <fxzhang@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3194
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fxzhang@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 2680
Lines: 96

To compile a module on mips,some compiler flags are required. An example:
  CFLAGS=
     "-I /usr/local/src/linux-mips/include/asm/gcc -D__KERNEL__ 
-I/usr/local/src/linux-mips/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
-fno-strict-aliasing -fno-common
 -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -Wa,--trap -pipe 
-DMODULE -mlong-calls"

And you may have know that there are 2 different world of mips: big 
endian and little endian. When
using cross compiler,you should choose the correct toolchain(often 
mipsel-xxx vs. mips-xxx).

But these normally lead to other errors, so again check for your kernel 
version about task queue data
structures. (Does your toolchain's kernel headers consistent with the 
one running on mips?)

Guangxing Zhang wrote:

>Hi, 
>
>	    Inspired by your advice , I have changed the method of preventing the module 
>from being unloaded while "intrpt_routine" is still in the task queue.Now it can freely 
>"insmod" and "rmmod" in my linux(2.4.18-3,not on mips) at  any time.But unfortunatlly,
>When I port it to mips_linux, it get some errors as you can see in my mail to 
>linux-mips@linux-mips.org . It confuses me .Why? And what should I MUST pay attention to
>or what should I MUST learn if I I want to implement schedualing a function to be called
>on every timer interrupt.
>
>        Thank you again and eagering your enthusiastic again! 
> 
>
>======= 2003-09-16 13:17:00 WROTE£º=======
>
>  
>
>>Guangxing Zhang wrote:
>>
>>    
>>
>>>Hi, Fuxin Zhang
>>>
>>> 
>>>
>>>      
>>>
>>>>for any warnings. BTW, I don't the method you used to cleanup is safe,
>>>>there maybe a task queued but not executed at the time you 
>>>>'rmmod',doesn't it?
>>>>   
>>>>
>>>>        
>>>>
>>>Yes ,in http://www.faqs.org/docs/kernel/x1145.html#AEN1201 , it mentions the 
>>>situation as you said.And just to overcoming it ,it use the sleep_on().But as you 
>>>see, now it can not "rmmod" correctly and my linux will broke.
>>>
>>>As a newbie to kernel module ,I am not sure why and not know how to scheduale a 
>>>function to be called on every timer interrupt or every seconds in kernle module.
>>>Eagering your help!
>>> 
>>>
>>>      
>>>
>>>>>interrupt
>>>>>     
>>>>>
>>>>>          
>>>>>
>>Most ethernet adapter driver(e.g. drivers/net/eepro100.c) use timer,you 
>>can check them for examples.
>>
>>
>>Have you check the sleep_on and wakeup routine's argument type? They 
>>should be wait_queue_head_t *
>>for recent kernels?
>>    
>>
>
>= = = = = = = = = = = = = = = = = = = =
>			
> 
>				 
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-16
>
>
>
>
>
>  
>


From guangxing@ict.ac.cn Wed Sep 17 02:51:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 17 Sep 2003 02:51:38 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:16775 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225362AbTIQBvg> convert rfc822-to-8bit;
	Wed, 17 Sep 2003 02:51:36 +0100
Received: (qmail 13309 invoked from network); 17 Sep 2003 01:37:23 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 17 Sep 2003 01:37:23 -0000
From: "Guangxing Zhang" <guangxing@ict.ac.cn>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Re: Re: It is ok on linux ,but not ok on mips_linux as my expection!
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Wed, 17 Sep 2003 9:51:59 +0800
Message-Id: <20030917015136Z8225362-1272+5527@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3195
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 5055
Lines: 138

Hi, Fuxin Zhang
======= 2003-09-16 18:15:00 WROTE£º=======

>To compile a module on mips,some compiler flags are required. An example:
>  CFLAGS=
>     "-I /usr/local/src/linux-mips/include/asm/gcc -D__KERNEL__ 
>-I/usr/local/src/linux-mips/include
>-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
>-fno-strict-aliasing -fno-common
> -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -Wa,--trap -pipe 
>-DMODULE -mlong-calls"
I have tried to change the compiler flags before.And I am not sure the 
exact meaning of the "-mips2".I think it is related to our mips.When I 
compile my mips-linux kernel,I used "-mcpu=sb1 " and our mips is
mips64 , but the kernel we use is linux for mips32, because I know linux 
for mips64 doest not support kernel module yet(It is a trouble to me too). 
One thing confused me is that with the flag "-mips2" or "-mips32", or 
"-mips64", when I compiled my kernel module,it will get the following error  :
______________________________________________________________________________________________
sch_example.c:80: warning: function declaration isn't a prototype
sch_example.c:92: warning: function declaration isn't a prototype
/tmp/ccxxm0Sw.s: Assembler messages:
/tmp/ccxxm0Sw.s:152: Error: opcode not supported on this processor: R6000 (MIPS2) `lld $3,8($6)'
/tmp/ccxxm0Sw.s:154: Error: opcode not supported on this processor: R6000 (MIPS2) `scd $2,8($6)'
/tmp/ccxxm0Sw.s:245: Error: opcode not supported on this processor: R6000 (MIPS2) `lld $4,8($6)'
/tmp/ccxxm0Sw.s:247: Error: opcode not supported on this processor: R6000 (MIPS2) `scd $3,8($6)'
________________________________________________________________________________________________
But when i removed that flags it will be compiled ok, of course it is still can not work ok when i
try to "insmod".:)~
Any advice for me ?
>And you may have know that there are 2 different world of mips: big 
>endian and little endian. When
>using cross compiler,you should choose the correct toolchain(often 
>mipsel-xxx vs. mips-xxx).
>
Yes, I have noticed this before and my others simple kernel module can be
compiled  and "insmod" ok. So i think it is the tq_timer or the queue_task
that arose the trouble as you said follow.
>But these normally lead to other errors, so again check for your kernel 
>version about task queue data
>structures. (Does your toolchain's kernel headers consistent with the 
>one running on mips?)
I have notice the change of the "struct tq_struct" .
But I am not sure  whether the task queue is the best choice to be used here.
Because I know the evolution of "task queque-->tasklet-->softirq" . It seems 
"task queque" is a obsolete way.Ha~, maybe I should try to learn how to use
tasklet or softirq.
Is it a right think ? What is your advice?  And what should I do ?
As a newbie to the kernle module ,I am so so so confused.
Thank you again. You are an excellent Linux Man.
>
>Guangxing Zhang wrote:
>
>>Hi, 
>>
>>	    Inspired by your advice , I have changed the method of preventing the module 
>>from being unloaded while "intrpt_routine" is still in the task queue.Now it can freely 
>>"insmod" and "rmmod" in my linux(2.4.18-3,not on mips) at  any time.But unfortunatlly,
>>When I port it to mips_linux, it get some errors as you can see in my mail to 
>>linux-mips@linux-mips.org . It confuses me .Why? And what should I MUST pay attention to
>>or what should I MUST learn if I I want to implement schedualing a function to be called
>>on every timer interrupt.
>>
>>        Thank you again and eagering your enthusiastic again! 
>> 
>>
>>======= 2003-09-16 13:17:00 WROTE£º=======
>>
>>  
>>
>>>Guangxing Zhang wrote:
>>>
>>>    
>>>
>>>>Hi, Fuxin Zhang
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>>>for any warnings. BTW, I don't the method you used to cleanup is safe,
>>>>>there maybe a task queued but not executed at the time you 
>>>>>'rmmod',doesn't it?
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>Yes ,in http://www.faqs.org/docs/kernel/x1145.html#AEN1201 , it mentions the 
>>>>situation as you said.And just to overcoming it ,it use the sleep_on().But as you 
>>>>see, now it can not "rmmod" correctly and my linux will broke.
>>>>
>>>>As a newbie to kernel module ,I am not sure why and not know how to scheduale a 
>>>>function to be called on every timer interrupt or every seconds in kernle module.
>>>>Eagering your help!
>>>> 
>>>>
>>>>      
>>>>
>>>>>>interrupt
>>>>>>     
>>>>>>
>>>>>>          
>>>>>>
>>>Most ethernet adapter driver(e.g. drivers/net/eepro100.c) use timer,you 
>>>can check them for examples.
>>>
>>>
>>>Have you check the sleep_on and wakeup routine's argument type? They 
>>>should be wait_queue_head_t *
>>>for recent kernels?
>>>    
>>>
>>
>>= = = = = = = = = = = = = = = = = = = =
>>			
>> 
>>				 
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-16
>>
>>
>>
>>
>>
>>  
>>

= = = = = = = = = = = = = = = = = = = =
			
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-17




From marketing@businesstechnologymanagement.com Wed Sep 17 11:46:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 17 Sep 2003 11:46:38 +0100 (BST)
Received: from einsteinium.btinternet.com ([IPv6:::ffff:194.73.73.147]:25985
	"EHLO einsteinium.btinternet.com") by linux-mips.org with ESMTP
	id <S8225193AbTIQKqf>; Wed, 17 Sep 2003 11:46:35 +0100
Received: from host81-128-243-121.in-addr.btopenworld.com ([81.128.243.121] helo=CPQ26657574373)
	by einsteinium.btinternet.com with esmtp (Exim 3.22 #23)
	id 19zZpP-0003eZ-00
	for linux-mips@linux-mips.org; Wed, 17 Sep 2003 11:46:31 +0100
To: linux-mips@linux-mips.org
From: "BTM" <marketing@businesstechnologymanagement.com>
Subject: FREE service - register your lists or find mailing lists on new database
Date: Wed, 17 Sep 2003 11:46:30 +0100
Reply-To: marketing@businesstechnologymanagement.com
MIME-Version: 1.0 
Content-Type: multipart/alternative; boundary="Boundary.generator.IPWorks.v5.MIME.200309317104630.2583299132"
Message-Id: <E19zZpP-0003eZ-00@einsteinium.btinternet.com>
Return-Path: <marketing@businesstechnologymanagement.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3196
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: marketing@businesstechnologymanagement.com
Precedence: bulk
X-list: linux-mips
Content-Length: 4539
Lines: 102

--Boundary.generator.IPWorks.v5.MIME.200309317104630.2583299132
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

findmealist news letter 

" FIND ME A LIST " 

The internet data service for all your marketing campaigns 

Dear Marketing Professional 

We have now launched our new FREE on-line independent internet database of mailing lists. You can now search for specific mailing lists and email lists from the world's leading suppliers. 

If you have a list you wish to promote - then register with us by adding your list details to our database. All list enquiries from Marketing Managers are emailed directly to you from the database instantly. 

All new lists added to the database will now appear on our NEWS page for one week, with a direct page link to that database entry, so that interested parties can see your latest list offerings without having to search through the entire database. 

Mark Brown
Director
Business & Technology Management Ltd, owners of www.findmealist.com 

If you wish to opt-out or opt-in to from future communications from us regarding this service, click here. 
--Boundary.generator.IPWorks.v5.MIME.200309317104630.2583299132
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<HTML>

<head>
<meta http-equiv="Content-Language" content="en-gb">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>findmealist news letter</title>
</head>

<body bgcolor="#008080" link="#FFFFFF" vlink="#C0C0C0" alink="#800000">

<table border="2" cellpadding="2" width="100%">
  <tr>
    <td width="20%">
    <a href="http://www.findmealist.com/">
    <img border="0" src="http://www.businesstechnologymanagement.com/images/findmealist.jpg" 
width="133" height="100"></a></td>
    <td class='h1' width="60%">
      <p align="center"><font color="#FFFFFF" face="Tahoma">&quot; FIND ME A 
LIST &quot;</font></p>
      <p align="center"><font color="#FFFFFF" face="Tahoma">The internet data 
service for all your marketing 
      campaigns</font></p>
    </td>
    <td width="20%">
    <img border="0" src="http://www.businesstechnologymanagement.com/images/ComputerKeyboard1.jpg" 
width="148" height="100" align="right"></td>
  </tr>
</table>

<p align="left" class="h1">
<font face="Tahoma" color="#FFFFFF">
<b>Dear Marketing Professional</b></font></p>
<p class="Body"><font face="Tahoma" size="2"><font color="#FFFFFF">We have now 
launched our new 
</font> <u><b>
<a href="http://www.findmealist.com/">FREE</a></b></u><font color="#FFFFFF"> 
on-line independent 
internet database of mailing lists. You can now search for specific mailing 
lists and email lists from the world's leading suppliers.</font></font></p>
<p class="Body"><font face="Tahoma" color="#FFFFFF" size="2">If you have a list 
you wish to promote - then register with us 
by adding your list details to our database. All list enquiries from Marketing 

Managers are emailed directly to you from the database instantly.</font></p>
<p class="Body"><font face="Tahoma" color="#FFFFFF" size="2">All new lists added 
to the database will now appear on our NEWS 
page for one week, with a direct page link to that database entry, so that 
interested parties can see your latest list offerings without having to search 

through the entire database.</font></p>
<p class="Body"><font face="Tahoma" color="#FFFFFF" size="2">Mark Brown<br>
</font>
<font SIZE="2">
<font face="Tahoma" color="#FFFFFF">Director</font><br>
<font face="Tahoma"><a href="http://www.businesstechnologymanagement.com">Business 
&amp; 
Technology Management Ltd</a><font color="#FFFFFF">, owners of </font> <a href="http://www.findmealist.com">
www.findmealist.com</a></font></p>
</font>
<p class="Body"><font face="Tahoma" size="1"><font color="#FFFFFF">If you wish 
to opt-out or opt-in to from future communications 
from us regarding this service, </font>
<a href="http://www.businesstechnologymanagement.com/applications/findmealist/MailingFlag.php">
click here</a><font color="#FFFFFF">.</font></font></p>

<a href="http://click.linksynergy.com/fs-bin/click?id=sYZ52468d34&offerid=49575.10000104&type=4&subid=0"><IMG 
 width="125" height="125" alt="VirusAlert_125x125" border="0" src="http://ads.mcafee.com/mcafee_banners/mcafeecom/linkshare/VirusAlert_125x125.gif"></a><IMG 
border="0" width="1" height="1" src="http://ad.linksynergy.com/fs-bin/show?id=sYZ52468d34&bids=49575.10000104&type=4&subid=0">

</body>


</HTML>
--Boundary.generator.IPWorks.v5.MIME.200309317104630.2583299132--


From embedlf@citiz.net Thu Sep 18 02:15:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 02:15:33 +0100 (BST)
Received: from [IPv6:::ffff:218.1.66.81] ([IPv6:::ffff:218.1.66.81]:13014 "HELO
	mail.citiz.net") by linux-mips.org with SMTP id <S8225346AbTIRBPO> convert rfc822-to-8bit;
	Thu, 18 Sep 2003 02:15:14 +0100
Received: (umta 20066 invoked by uid 1820); 18 Sep 2003 01:14:59 -0000
X-Lasthop: 202.120.8.28
Received: from unknown (HELO hdtv) (unknown@202.120.8.28)
  by localhost with SMTP; 18 Sep 2003 01:14:59 -0000
From: "embedlf" <embedlf@citiz.net>
To: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: the problem about open file on ramdisk
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Thu, 18 Sep 2003 9:22:23 +0800
Message-Id: <20030918011514Z8225346-1272+5558@linux-mips.org>
Return-Path: <embedlf@citiz.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3197
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: embedlf@citiz.net
Precedence: bulk
X-list: linux-mips
Content-Length: 3469
Lines: 110

linux-mips:
	 I use initrd ramdisk as rootfs on my mips cpu board.But after compiling kernel and download it to the board,that print the error message.Following is the message.

CPU revision is: 00001800

Primary instruction cache 64kb, linesize 16 bytes.

Primary data cache 16kb, linesize 16 bytes.

Linux version 2.4.18-MIPS-01.01 (l@l) (gcc version 2.96) #147 Èý 9ÔÂ 17 15:21:28 CST 2003

Determined physical RAM map:

 memory: 04000000 @ 00000000 (usable)

Initial ramdisk at: 0x80270000 (1917091 bytes)

On node 0 totalpages: 16384

zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: 
Calibrating delay loop... 299.00 BogoMIPS
Memory: 59992k/65536k available (1281k kernel code, 5544k reserved, 1976k data, 72k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  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
Journalled Block Device driver loaded
Dummy keyboard driver installed.
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
block: 128 slots per queue, batch=32
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

RAMDISK: Compressed image found at block 0

Freeing initrd memory: 1872k freed

VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 72k freed
kernel BUG at traps.c:627!

Unable to handle kernel paging request at virtual address 00000000, epc == 80105088, ra == 80105088

Oops in fault.c:do_page_fault, line 205:

$0 : 00000000 10018000 0000001b 00000000 80262d10 00000001 00000001 00000000

$8 : 00001289 00001289 80450000 80448139 00000000 00000000 fffffff9 0000000a

$16: 80251000 8113bca8 00000440 8110e320 8116f660 00000000 00000000 00000000

$24: ffffffff 8113bb4a                   8113a000 8113bc88 80458538 80105088

Hi : 00000000

Lo : 00000200

epc  : 80105088    Not tainted

Status: 10018003

Cause : 0000000c

Process swapper (pid: 1, stackpage=8113a000)

Stack: 80229740 80229738 00000273 10018001 80251000 8116d000 00000440 80103f4c

       83a202a0 8013147c 83a20660 00000000 83a20660 80263dec 00000000 80252000

       80440000 8010a480 80251000 00000000 00000250 10018001 00000000 80225ad8

       00ff0000 000003e8 00000001 80232700 80254000 8116f260 80251000 8116d000

       00000440 8110e320 8116f660 00000000 00000000 00000000 00000400 81169000

       8046a8c0 ...

Call Trace:

Code: 24a59738  0c045adb  24060273 <ac000000> 8e2200ac  04410002  8e2400a0  24840004  24820004 

Kernel panic: Attempted to kill init!

 <0>Rebooting in 180 seconds..


At the address 80105088, there is the function do_ri() in traps.c. I found that this fault
was caused by "if (open("/dev/console", O_RDWR, 0) < 0)".Why?
	please help me to analyse this fault.How to conquer it?


¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡embedlf
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡embedlf@citiz.net
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-18



From anemo@mba.ocn.ne.jp Thu Sep 18 10:03:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 10:03:28 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:4636
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225409AbTIRJDZ>; Thu, 18 Sep 2003 10:03:25 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 18 Sep 2003 09:03:23 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h8I93Cgc076416;
	Thu, 18 Sep 2003 18:03:14 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 18 Sep 2003 18:05:36 +0900 (JST)
Message-Id: <20030918.180536.08320519.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, macro@linux-mips.org
Subject: mips64 cpu-probe.c compile failure
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030916151302Z8225419-1272+5508@linux-mips.org>
References: <20030916151302Z8225419-1272+5508@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3198
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 964
Lines: 36

>>>>> On Tue, 16 Sep 2003 16:12:57 +0100, macro@linux-mips.org said:
macro> Modified files:
macro> 	arch/mips64/kernel: Tag: linux_2_4 cpu-probe.c 

macro> Log message:
macro> 	Fix indeterminism in the multiply/shift erratum detection leading
macro> 	to false negatives.  Plus a few minor comment updates for clarity.

gcc 3.3.1 can not compile current (2.4) arch/mips64/kernel/cpu-probe.c.

cpu-probe.c:118: warning: asm operand 0 probably doesn't match constraints
cpu-probe.c:118: warning: asm operand 1 probably doesn't match constraints
...
cpu-probe.c: In function `check_mult_sh':
cpu-probe.c:118: error: impossible constraint in `asm'

The code is:

static inline void align_mod(int align, int mod)
{
	asm volatile(
		".set	push\n\t"
		".set	noreorder\n\t"
		".balign %0\n\t"
		".rept	%1\n\t"
		"nop\n\t"
		".endr\n\t"
		".set	pop"
		:
		: "i" (align), "i" (mod));
}

The align_mod() and mult_sh_align_mod() should be written as macro?

---
Atsushi Nemoto

From prabhakark@contechsoftware.com Thu Sep 18 11:09:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 11:09:17 +0100 (BST)
Received: from [IPv6:::ffff:203.129.212.34] ([IPv6:::ffff:203.129.212.34]:521
	"HELO contech.contechsoftware.com") by linux-mips.org with SMTP
	id <S8225409AbTIRKJO>; Thu, 18 Sep 2003 11:09:14 +0100
Received: (from prabhakar [200.1.1.48])
 by contech.contechsoftware.com (NAVGW 2.5.1.18) with SMTP id M2003091815464200042
 for <linux-mips@linux-mips.org>; Thu, 18 Sep 2003 15:46:42 +0530
Received: by localhost with Microsoft MAPI; Thu, 18 Sep 2003 15:46:35 -0000
Message-ID: <01C37DFC.0A2C6CA0.prabhakark@contechsoftware.com>
From: Prabhakar Kalasani <prabhakark@contechsoftware.com>
Reply-To: "prabhakark@contechsoftware.com" <prabhakark@contechsoftware.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: How disable CONFIG_PCI 
Date: Thu, 18 Sep 2003 15:46:34 -0000
Organization: Contech Software Limited
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Encoding: 9 TEXT
Return-Path: <prabhakark@contechsoftware.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3199
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: prabhakark@contechsoftware.com
Precedence: bulk
X-list: linux-mips
Content-Length: 344
Lines: 10

Hi all,
I'm compiling Linux-2.4.21 kernel for CSB250 board downloaded from mips-linux,
I've configured CONFIG_PCI n , but when i go for xconfig, the value to CONFIG_PCI y
where it's getting over write ? 
Because of CONFIG_PCI y, I'm unable to get my Framebuffer device active
How to solve this problem...

Thanks in advence
Prabhakar Kalasani


From alanliu@trident.com.cn Thu Sep 18 11:11:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 11:11:28 +0100 (BST)
Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:37903
	"EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP
	id <S8225421AbTIRKL0>; Thu, 18 Sep 2003 11:11:26 +0100
Received: by TMTMS with Internet Mail Service (5.5.2653.19)
	id <SK19GYC3>; Thu, 18 Sep 2003 18:07:10 +0800
Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F68019BF846@TMTMS>
From: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
To: embedlf <embedlf@citiz.net>
Cc: linux-mips@linux-mips.org
Subject: RE: the problem about open file on ramdisk
Date: Thu, 18 Sep 2003 18:06:59 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C37DCC.996F1460"
Return-Path: <alanliu@trident.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3200
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alanliu@trident.com.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 12587
Lines: 422

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C37DCC.996F1460
Content-Type: text/plain;
	charset="GB2312"
Content-Transfer-Encoding: quoted-printable


you cpu: 00001800

	RC32334 ??? I dont know it.

epc  : 80105088    Not tainted
	It is the exception VICTIM.Could you offer the instruction at
0x80105088?

Status: 10018003
	you can analysis this register for information,I dont know the cpu
type,so Status...
=09
Cause : 0000000c
	in my cpu(r3000 similar) means ExcCode 3,TLB miss

It seems to me that NULL pointer has been refered in kernel,at =
0x80105088.
you could change the kernel,or try to find out where the NULL pointer =
is
generated.

Just FYI.

-----Original Message-----
From: embedlf [mailto:embedlf@citiz.net]
Sent: Thursday, September 18, 2003 9:22 AM
To: linux-mips@linux-mips.org
Subject: the problem about open file on ramdisk


linux-mips:
	 I use initrd ramdisk as rootfs on my mips cpu board.But after
compiling kernel and download it to the board,that print the error
message.Following is the message.

CPU revision is: 00001800

Primary instruction cache 64kb, linesize 16 bytes.

Primary data cache 16kb, linesize 16 bytes.

Linux version 2.4.18-MIPS-01.01 (l@l) (gcc version 2.96) #147 =C8=FD =
9=D4=C2 17
15:21:28 CST 2003

Determined physical RAM map:

 memory: 04000000 @ 00000000 (usable)

Initial ramdisk at: 0x80270000 (1917091 bytes)

On node 0 totalpages: 16384

zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line:=20
Calibrating delay loop... 299.00 BogoMIPS
Memory: 59992k/65536k available (1281k kernel code, 5544k reserved, =
1976k
data, 72k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  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
Journalled Block Device driver loaded
Dummy keyboard driver installed.
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
block: 128 slots per queue, batch=3D32
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

RAMDISK: Compressed image found at block 0

Freeing initrd memory: 1872k freed

VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 72k freed
kernel BUG at traps.c:627!

Unable to handle kernel paging request at virtual address 00000000, epc =
=3D=3D
80105088, ra =3D=3D 80105088

Oops in fault.c:do_page_fault, line 205:

$0 : 00000000 10018000 0000001b 00000000 80262d10 00000001 00000001 =
00000000

$8 : 00001289 00001289 80450000 80448139 00000000 00000000 fffffff9 =
0000000a

$16: 80251000 8113bca8 00000440 8110e320 8116f660 00000000 00000000 =
00000000

$24: ffffffff 8113bb4a                   8113a000 8113bc88 80458538 =
80105088

Hi : 00000000

Lo : 00000200

epc  : 80105088    Not tainted

Status: 10018003

Cause : 0000000c

Process swapper (pid: 1, stackpage=3D8113a000)

Stack: 80229740 80229738 00000273 10018001 80251000 8116d000 00000440
80103f4c

       83a202a0 8013147c 83a20660 00000000 83a20660 80263dec 00000000
80252000

       80440000 8010a480 80251000 00000000 00000250 10018001 00000000
80225ad8

       00ff0000 000003e8 00000001 80232700 80254000 8116f260 80251000
8116d000

       00000440 8110e320 8116f660 00000000 00000000 00000000 00000400
81169000

       8046a8c0 ...

Call Trace:

Code: 24a59738  0c045adb  24060273 <ac000000> 8e2200ac  04410002  =
8e2400a0
24840004  24820004=20

Kernel panic: Attempted to kill init!

 <0>Rebooting in 180 seconds..


At the address 80105088, there is the function do_ri() in traps.c. I =
found
that this fault
was caused by "if (open("/dev/console", O_RDWR, 0) < 0)".Why?
	please help me to analyse this fault.How to conquer it?


=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1embedlf
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1embedlf@citiz.net
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12003-09-18



------_=_NextPart_001_01C37DCC.996F1460
Content-Type: text/html;
	charset="GB2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DGB2312">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: the problem about open file on ramdisk</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>you cpu: 00001800</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>RC32334 =
??? I dont know it.</FONT>
</P>

<P><FONT SIZE=3D2>epc&nbsp; : 80105088&nbsp;&nbsp;&nbsp; Not =
tainted</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>It is the =
exception VICTIM.Could you offer the instruction at 0x80105088?</FONT>
</P>

<P><FONT SIZE=3D2>Status: 10018003</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>you can =
analysis this register for information,I dont know the cpu type,so =
Status...</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>Cause : 0000000c</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>in my =
cpu(r3000 similar) means ExcCode 3,TLB miss</FONT>
</P>

<P><FONT SIZE=3D2>It seems to me that NULL pointer has been refered in =
kernel,at 0x80105088.</FONT>
<BR><FONT SIZE=3D2>you could change the kernel,or try to find out where =
the NULL pointer is generated.</FONT>
</P>

<P><FONT SIZE=3D2>Just FYI.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: embedlf [<A =
HREF=3D"mailto:embedlf@citiz.net">mailto:embedlf@citiz.net</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, September 18, 2003 9:22 AM</FONT>
<BR><FONT SIZE=3D2>To: linux-mips@linux-mips.org</FONT>
<BR><FONT SIZE=3D2>Subject: the problem about open file on =
ramdisk</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>linux-mips:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT SIZE=3D2> I =
use initrd ramdisk as rootfs on my mips cpu board.But after compiling =
kernel and download it to the board,that print the error =
message.Following is the message.</FONT></P>

<P><FONT SIZE=3D2>CPU revision is: 00001800</FONT>
</P>

<P><FONT SIZE=3D2>Primary instruction cache 64kb, linesize 16 =
bytes.</FONT>
</P>

<P><FONT SIZE=3D2>Primary data cache 16kb, linesize 16 bytes.</FONT>
</P>

<P><FONT SIZE=3D2>Linux version 2.4.18-MIPS-01.01 (l@l) (gcc version =
2.96) #147 =C8=FD 9=D4=C2 17 15:21:28 CST 2003</FONT>
</P>

<P><FONT SIZE=3D2>Determined physical RAM map:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;memory: 04000000 @ 00000000 (usable)</FONT>
</P>

<P><FONT SIZE=3D2>Initial ramdisk at: 0x80270000 (1917091 bytes)</FONT>
</P>

<P><FONT SIZE=3D2>On node 0 totalpages: 16384</FONT>
</P>

<P><FONT SIZE=3D2>zone(0): 16384 pages.</FONT>
<BR><FONT SIZE=3D2>zone(1): 0 pages.</FONT>
<BR><FONT SIZE=3D2>zone(2): 0 pages.</FONT>
<BR><FONT SIZE=3D2>Kernel command line: </FONT>
<BR><FONT SIZE=3D2>Calibrating delay loop... 299.00 BogoMIPS</FONT>
<BR><FONT SIZE=3D2>Memory: 59992k/65536k available (1281k kernel code, =
5544k reserved, 1976k data, 72k init, 0k highmem)</FONT>
<BR><FONT SIZE=3D2>Dentry-cache hash table entries: 8192 (order: 4, =
65536 bytes)</FONT>
<BR><FONT SIZE=3D2>Inode-cache hash table entries: 4096 (order: 3, =
32768 bytes)</FONT>
<BR><FONT SIZE=3D2>Mount-cache hash table entries: 1024 (order: 1, 8192 =
bytes)</FONT>
<BR><FONT SIZE=3D2>Buffer-cache hash table entries: 4096 (order: 2, =
16384 bytes)</FONT>
<BR><FONT SIZE=3D2>Page-cache hash table entries: 16384 (order: 4, =
65536 bytes)</FONT>
<BR><FONT SIZE=3D2>Checking for 'wait' instruction...&nbsp; =
available.</FONT>
<BR><FONT SIZE=3D2>POSIX conformance testing by UNIFIX</FONT>
<BR><FONT SIZE=3D2>Linux NET4.0 for Linux 2.4</FONT>
<BR><FONT SIZE=3D2>Based upon Swansea University Computer Society =
NET3.039</FONT>
<BR><FONT SIZE=3D2>Initializing RT netlink socket</FONT>
<BR><FONT SIZE=3D2>Starting kswapd</FONT>
<BR><FONT SIZE=3D2>Journalled Block Device driver loaded</FONT>
<BR><FONT SIZE=3D2>Dummy keyboard driver installed.</FONT>
<BR><FONT SIZE=3D2>Serial driver version 5.05c (2001-07-08) with =
MANY_PORTS SHARE_IRQ SERIAL_PCI enabled</FONT>
<BR><FONT SIZE=3D2>block: 128 slots per queue, batch=3D32</FONT>
<BR><FONT SIZE=3D2>RAMDISK driver initialized: 16 RAM disks of 16384K =
size 1024 blocksize</FONT>
<BR><FONT SIZE=3D2>NET4: Linux TCP/IP 1.0 for NET4.0</FONT>
<BR><FONT SIZE=3D2>IP Protocols: ICMP, UDP, TCP, IGMP</FONT>
<BR><FONT SIZE=3D2>IP: routing cache hash table of 512 buckets, =
4Kbytes</FONT>
<BR><FONT SIZE=3D2>TCP: Hash tables configured (established 4096 bind =
4096)</FONT>
<BR><FONT SIZE=3D2>NET4: Unix domain sockets 1.0/SMP for Linux =
NET4.0.</FONT>
</P>

<P><FONT SIZE=3D2>RAMDISK: Compressed image found at block 0</FONT>
</P>

<P><FONT SIZE=3D2>Freeing initrd memory: 1872k freed</FONT>
</P>

<P><FONT SIZE=3D2>VFS: Mounted root (ext2 filesystem).</FONT>
<BR><FONT SIZE=3D2>Freeing unused kernel memory: 72k freed</FONT>
<BR><FONT SIZE=3D2>kernel BUG at traps.c:627!</FONT>
</P>

<P><FONT SIZE=3D2>Unable to handle kernel paging request at virtual =
address 00000000, epc =3D=3D 80105088, ra =3D=3D 80105088</FONT>
</P>

<P><FONT SIZE=3D2>Oops in fault.c:do_page_fault, line 205:</FONT>
</P>

<P><FONT SIZE=3D2>$0 : 00000000 10018000 0000001b 00000000 80262d10 =
00000001 00000001 00000000</FONT>
</P>

<P><FONT SIZE=3D2>$8 : 00001289 00001289 80450000 80448139 00000000 =
00000000 fffffff9 0000000a</FONT>
</P>

<P><FONT SIZE=3D2>$16: 80251000 8113bca8 00000440 8110e320 8116f660 =
00000000 00000000 00000000</FONT>
</P>

<P><FONT SIZE=3D2>$24: ffffffff =
8113bb4a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8113a000 8113bc88 80458538 =
80105088</FONT>
</P>

<P><FONT SIZE=3D2>Hi : 00000000</FONT>
</P>

<P><FONT SIZE=3D2>Lo : 00000200</FONT>
</P>

<P><FONT SIZE=3D2>epc&nbsp; : 80105088&nbsp;&nbsp;&nbsp; Not =
tainted</FONT>
</P>

<P><FONT SIZE=3D2>Status: 10018003</FONT>
</P>

<P><FONT SIZE=3D2>Cause : 0000000c</FONT>
</P>

<P><FONT SIZE=3D2>Process swapper (pid: 1, stackpage=3D8113a000)</FONT>
</P>

<P><FONT SIZE=3D2>Stack: 80229740 80229738 00000273 10018001 80251000 =
8116d000 00000440 80103f4c</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 83a202a0 =
8013147c 83a20660 00000000 83a20660 80263dec 00000000 80252000</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 80440000 =
8010a480 80251000 00000000 00000250 10018001 00000000 80225ad8</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00ff0000 =
000003e8 00000001 80232700 80254000 8116f260 80251000 8116d000</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00000440 =
8110e320 8116f660 00000000 00000000 00000000 00000400 81169000</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8046a8c0 =
...</FONT>
</P>

<P><FONT SIZE=3D2>Call Trace:</FONT>
</P>

<P><FONT SIZE=3D2>Code: 24a59738&nbsp; 0c045adb&nbsp; 24060273 =
&lt;ac000000&gt; 8e2200ac&nbsp; 04410002&nbsp; 8e2400a0&nbsp; =
24840004&nbsp; 24820004 </FONT>
</P>

<P><FONT SIZE=3D2>Kernel panic: Attempted to kill init!</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&lt;0&gt;Rebooting in 180 seconds..</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At the address 80105088, there is the function =
do_ri() in traps.c. I found that this fault</FONT>
<BR><FONT SIZE=3D2>was caused by &quot;if =
(open(&quot;/dev/console&quot;, O_RDWR, 0) &lt; 0)&quot;.Why?</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>please =
help me to analyse this fault.How to conquer it?</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1embedlf</FONT>
<BR><FONT =
SIZE=3D2>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1embedlf@citiz.n=
et</FONT>
<BR><FONT =
SIZE=3D2>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1200=
3-09-18</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C37DCC.996F1460--

From alanliu@trident.com.cn Thu Sep 18 11:16:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 11:16:22 +0100 (BST)
Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:61455
	"EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP
	id <S8225421AbTIRKQU>; Thu, 18 Sep 2003 11:16:20 +0100
Received: by TMTMS with Internet Mail Service (5.5.2653.19)
	id <SK19GYC6>; Thu, 18 Sep 2003 18:12:09 +0800
Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F68019BF848@TMTMS>
From: "Liu Hongming (Alan)" <alanliu@trident.com.cn>
To: prabhakark@contechsoftware.com,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: RE: How disable CONFIG_PCI 
Date: Thu, 18 Sep 2003 18:12:01 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C37DCD.4D886D20"
Return-Path: <alanliu@trident.com.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3201
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alanliu@trident.com.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 2655
Lines: 98

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C37DCD.4D886D20
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi,

In arch/mips/config.in, find the specific line relating to your CSB250(what
is it???):

 define_bool CONFIG_PCI y

just delete it.

Alan

-----Original Message-----
From: Prabhakar Kalasani [mailto:prabhakark@contechsoftware.com]
Sent: Thursday, September 18, 2003 11:47 PM
To: 'linux-mips@linux-mips.org'
Subject: How disable CONFIG_PCI 


Hi all,
I'm compiling Linux-2.4.21 kernel for CSB250 board downloaded from
mips-linux,
I've configured CONFIG_PCI n , but when i go for xconfig, the value to
CONFIG_PCI y
where it's getting over write ? 
Because of CONFIG_PCI y, I'm unable to get my Framebuffer device active
How to solve this problem...

Thanks in advence
Prabhakar Kalasani


------_=_NextPart_001_01C37DCD.4D886D20
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: How disable CONFIG_PCI </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>In arch/mips/config.in, find the specific line =
relating to your CSB250(what is it???):</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;define_bool CONFIG_PCI y</FONT>
</P>

<P><FONT SIZE=3D2>just delete it.</FONT>
</P>

<P><FONT SIZE=3D2>Alan</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Prabhakar Kalasani [<A =
HREF=3D"mailto:prabhakark@contechsoftware.com">mailto:prabhakark@contech=
software.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, September 18, 2003 11:47 PM</FONT>
<BR><FONT SIZE=3D2>To: 'linux-mips@linux-mips.org'</FONT>
<BR><FONT SIZE=3D2>Subject: How disable CONFIG_PCI </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi all,</FONT>
<BR><FONT SIZE=3D2>I'm compiling Linux-2.4.21 kernel for CSB250 board =
downloaded from mips-linux,</FONT>
<BR><FONT SIZE=3D2>I've configured CONFIG_PCI n , but when i go for =
xconfig, the value to CONFIG_PCI y</FONT>
<BR><FONT SIZE=3D2>where it's getting over write ? </FONT>
<BR><FONT SIZE=3D2>Because of CONFIG_PCI y, I'm unable to get my =
Framebuffer device active</FONT>
<BR><FONT SIZE=3D2>How to solve this problem...</FONT>
</P>

<P><FONT SIZE=3D2>Thanks in advence</FONT>
<BR><FONT SIZE=3D2>Prabhakar Kalasani</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C37DCD.4D886D20--

From macro@ds2.pg.gda.pl Thu Sep 18 11:18:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 11:18:03 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:56517 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225421AbTIRKSB>; Thu, 18 Sep 2003 11:18:01 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA15981;
	Thu, 18 Sep 2003 12:17:54 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 18 Sep 2003 12:17:54 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
cc: linux-mips@linux-mips.org
Subject: Re: mips64 cpu-probe.c compile failure
In-Reply-To: <20030918.180536.08320519.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.GSO.3.96.1030918121138.15508B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3202
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1385
Lines: 45

On Thu, 18 Sep 2003, Atsushi Nemoto wrote:

> macro> Log message:
> macro> 	Fix indeterminism in the multiply/shift erratum detection leading
> macro> 	to false negatives.  Plus a few minor comment updates for clarity.
> 
> gcc 3.3.1 can not compile current (2.4) arch/mips64/kernel/cpu-probe.c.
> 
> cpu-probe.c:118: warning: asm operand 0 probably doesn't match constraints
> cpu-probe.c:118: warning: asm operand 1 probably doesn't match constraints
> ...
> cpu-probe.c: In function `check_mult_sh':
> cpu-probe.c:118: error: impossible constraint in `asm'

 Hmm, perhaps 3.3.1 fails to inline the functions...  It works just fine
with 2.95.4.

> The code is:
> 
> static inline void align_mod(int align, int mod)
> {
> 	asm volatile(
> 		".set	push\n\t"
> 		".set	noreorder\n\t"
> 		".balign %0\n\t"
> 		".rept	%1\n\t"
> 		"nop\n\t"
> 		".endr\n\t"
> 		".set	pop"
> 		:
> 		: "i" (align), "i" (mod));
> }
> 
> The align_mod() and mult_sh_align_mod() should be written as macro?

 I wanted to avoid that as the resulting code would be ugly.  I guess
there is no other choice, although I think that's a bug in gcc.

 Can you quote the exact command line used for building the file?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From vhouten@telecom.tno.nl Thu Sep 18 11:31:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 11:31:28 +0100 (BST)
Received: from pandora.research.kpn.com ([IPv6:::ffff:139.63.192.11]:17374
	"EHLO pandora.research.kpn.com") by linux-mips.org with ESMTP
	id <S8225421AbTIRKb0>; Thu, 18 Sep 2003 11:31:26 +0100
Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6])
	by pandora.research.kpn.com (Postfix) with ESMTP id 34689FA9B
	for <linux-mips@linux-mips.org>; Thu, 18 Sep 2003 12:31:24 +0200 (MEST)
Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6])
	by sparta.research.kpn.com (8.11.7+Sun/8.11.7) with ESMTP id h8IAVNG12948
	for <linux-mips@linux-mips.org>; Thu, 18 Sep 2003 12:31:23 +0200 (MEST)
Message-Id: <200309181031.h8IAVNG12948@sparta.research.kpn.com>
X-Mailer: exmh version 1.6.5 12/11/95
To: linux-mips@linux-mips.org
Reply-To: vhouten@telecom.tno.nl
Subject: DECStation hardware looking for a new home...
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: Thu, 18 Sep 2003 12:31:23 +0200
From: "Houten K.H.C. van (Karel)" <vhouten@telecom.tno.nl>
Return-Path: <vhouten@telecom.tno.nl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3203
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vhouten@telecom.tno.nl
Precedence: bulk
X-list: linux-mips
Content-Length: 529
Lines: 22



Hi,

We'll have to dump some decstation hardware before our office will move
to a new building in november. 
DS3100, DS500/150, DS500/240. All with some storage. 

They must be collected in Leidschendam, the netherlands.
Please contact me if you are interested.

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 anemo@mba.ocn.ne.jp Thu Sep 18 15:06:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 15:06:48 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:10699 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225425AbTIROGq>; Thu, 18 Sep 2003 15:06:46 +0100
Received: from localhost (p0341-ip01funabasi.chiba.ocn.ne.jp [211.130.235.87])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 3170B3FBC; Thu, 18 Sep 2003 23:06:37 +0900 (JST)
Date: Thu, 18 Sep 2003 23:22:02 +0900 (JST)
Message-Id: <20030918.232202.07646481.anemo@mba.ocn.ne.jp>
To: macro@ds2.pg.gda.pl
Cc: linux-mips@linux-mips.org
Subject: Re: mips64 cpu-probe.c compile failure
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.GSO.3.96.1030918121138.15508B-100000@delta.ds2.pg.gda.pl>
References: <20030918.180536.08320519.nemoto@toshiba-tops.co.jp>
	<Pine.GSO.3.96.1030918121138.15508B-100000@delta.ds2.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3204
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 962
Lines: 21

>>>>> On Thu, 18 Sep 2003 12:17:54 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:

macro>  I wanted to avoid that as the resulting code would be ugly.  I
macro> guess there is no other choice, although I think that's a bug
macro> in gcc.

I have no idea that is a gcc bug, but I think align_mod() inline
function is not so beautiful because it can not be compiled anyway if
non-constant value was passed.

macro>  Can you quote the exact command line used for building the
macro> file?

mips64el-linux-gcc -D__KERNEL__ -I/home/anemo/work/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /home/anemo/work/linux/include/asm/gcc -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe  -march=r4600   -nostdinc -iwithprefix include -DKBUILD_BASENAME=cpu_probe  -c -o cpu-probe.o cpu-probe.c

I also tried with -finline-limit=100000 but no luck.

Does this help?

---
Atsushi Nemoto

From bruno.randolf@4g-systems.biz Thu Sep 18 15:45:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 15:45:06 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:41419
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225425AbTIROpD> convert rfc822-to-8bit; Thu, 18 Sep 2003 15:45:03 +0100
Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1A001m-0006KJ-00
	for linux-mips@linux-mips.org; Thu, 18 Sep 2003 16:45:02 +0200
Received: from [80.129.140.189] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1A001l-00053J-00
	for linux-mips@linux-mips.org; Thu, 18 Sep 2003 16:45:01 +0200
From: Bruno Randolf <bruno.randolf@4g-systems.biz>
Organization: 4G Mobile Systeme
To: linux-mips@linux-mips.org
Subject: 2.4.22 pci on au1500
Date: Thu, 18 Sep 2003 16:45:00 +0200
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <200309181645.00676.bruno.randolf@4g-systems.biz>
Return-Path: <bruno.randolf@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3205
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips
Content-Length: 3198
Lines: 71

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello!

i just tried 2.4.22 on my au1500 (mtx-1) board and it seems like pci is 
broken. is there anything that has changed for the board initialization, 
which i might have missed?

it woked fine with 2.4.21, there i got:

Autoconfig PCI channel 0x802eaf28
Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
00:00.0 Class 0280: 1260:3873 (rev 01)
        Mem at 0x40000000 [size=0x1000]

with 2.4.22 and debugging output enabled, i get:

Autoconfig PCI channel 0x802f0e88
Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x50000000
config_access: 0 bus 0 device 0 at 0 *data 18000057, conf 0
config_access: 0 bus 0 device 1 at 0 *data 18000057, conf 0
config_access: 0 bus 0 device 2 at 0 *data 180000d7, conf 0
config_access: 0 bus 0 device 3 at 0 *data 18000157, conf 0
config_access: 0 bus 0 device 4 at 0 *data 18000257, conf 0
config_access: 0 bus 0 device 5 at 0 *data 18000457, conf 0
config_access: 0 bus 0 device 6 at 0 *data 18000857, conf 0
config_access: 0 bus 0 device 7 at 0 *data 18001057, conf 0
config_access: 0 bus 0 device 8 at 0 *data 18002057, conf 0
config_access: 0 bus 0 device 9 at 0 *data 18004057, conf 0
config_access: 0 bus 0 device 10 at 0 *data 18008057, conf 0
config_access: 0 bus 0 device 11 at 0 *data 18010057, conf 0
config_access: 0 bus 0 device 12 at 0 *data 18020057, conf 0
config_access: 0 bus 0 device 13 at 0 *data 18040057, conf 0
config_access: 0 bus 0 device 14 at 0 *data 18080057, conf 0
config_access: 0 bus 0 device 15 at 0 *data 18100057, conf 0
config_access: 0 bus 0 device 16 at 0 *data 18200057, conf 0
config_access: 0 bus 0 device 17 at 0 *data 18400057, conf 0
config_access: 0 bus 0 device 18 at 0 *data 18800057, conf 0
config_access: 0 bus 0 device 0 at e *data 18000057, conf c
config_access: 0 bus 0 device 1 at e *data 18000057, conf c
config_access: 0 bus 0 device 2 at e *data 180000d7, conf c
config_access: 0 bus 0 device 3 at e *data 18000157, conf c
config_access: 0 bus 0 device 4 at e *data 18000257, conf c
config_access: 0 bus 0 device 5 at e *data 18000457, conf c
config_access: 0 bus 0 device 6 at e *data 18000857, conf c
config_access: 0 bus 0 device 7 at e *data 18001057, conf c
config_access: 0 bus 0 device 8 at e *data 18002057, conf c
config_access: 0 bus 0 device 9 at e *data 18004057, conf c
config_access: 0 bus 0 device 10 at e *data 18008057, conf c
config_access: 0 bus 0 device 11 at e *data 18010057, conf c
config_access: 0 bus 0 device 12 at e *data 18020057, conf c
config_access: 0 bus 0 device 13 at e *data 18040057, conf c
config_access: 0 bus 0 device 14 at e *data 18080057, conf c
config_access: 0 bus 0 device 15 at e *data 18100057, conf c
config_access: 0 bus 0 device 16 at e *data 18200057, conf c
config_access: 0 bus 0 device 17 at e *data 18400057, conf c
config_access: 0 bus 0 device 18 at e *data 18800057, conf c
config_access: 0 bus 0 device 19 at e *data 19000057, conf c

thanks for your help - again :)

bruno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/acTsfg2jtUL97G4RAv22AJ4ir4H2D0mTLN157b1c23B65hRDSgCbB41e
mazx3zPs6Pgpwn5H5B1gmSU=
=N4jq
-----END PGP SIGNATURE-----


From yaelgilad@myrealbox.com Thu Sep 18 17:02:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 17:02:14 +0100 (BST)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:182 "EHLO
	smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225425AbTIRQCM> convert rfc822-to-8bit; Thu, 18 Sep 2003 17:02:12 +0100
Received: from yaelgilad [81.218.80.94] by myrealbox.com
	with NetMail ModWeb Module; Thu, 18 Sep 2003 16:02:10 +0000
Subject: High mem and static memory
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: linux-mips@linux-mips.org
Date: Thu, 18 Sep 2003 16:02:11 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1063900931.725cf2a0yaelgilad@myrealbox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Return-Path: <yaelgilad@myrealbox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3206
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yaelgilad@myrealbox.com
Precedence: bulk
X-list: linux-mips
Content-Length: 371
Lines: 13

Hi,
We have already implemented the following scheme:
In our firmware, we define an area of memory as
un-usable.
In the kernel, we access this memory based on fixed
addresses.
This area of memory is approximately around 200-200Mb
at the bottom of the memory.

Is there anything preventing me from moving this
region to high-mem, around 500Mb (my total memory is 512) ?



From drow@crack.them.org Thu Sep 18 17:33:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 17:33:52 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:40370 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225425AbTIRQdt>;
	Thu, 18 Sep 2003 17:33:49 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A01iy-0005kn-EQ; Thu, 18 Sep 2003 12:33:44 -0400
Date: Thu, 18 Sep 2003 12:33:44 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
Subject: ddb5477 fixes for 2.6
Message-ID: <20030918163344.GA22013@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3207
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 13409
Lines: 389

Here's just enough to make the ddb5477 compile and boot.  The defconfig has
lost the onboard network card, and you also need to turn on CONFIG_EMBEDDED
to turn off CONFIG_VT.  Otherwise, conswitchp is uninitialized, causing a
crash.  If I initialize it to &dummy_con, serial consoles stop working
(???).

Userspace doesn't work - lots of scripts segfault, portmap times out, there
are a number of other glitches.  init=/bin/bash hangs.  But at least it's
progress.

I update CFLAGS for gcc 3.3/binutils 2.14.  I think asking people to use
vaguely modern tools for 2.6 is reasonable.  And the old flags don't work
any more.  This should work with 3.2 too.

The PCI and ac97 changes are pretty mindless merge work.

Ralf, this re-adds CONFIG_PCI_AUTO.  Do you know where it went? :)  Probably
a lot of other boards are sad about its disappearance also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Index: arch/mips/Kconfig
===================================================================
RCS file: /home/cvs/linux/arch/mips/Kconfig,v
retrieving revision 1.12
diff -u -p -r1.12 Kconfig
--- arch/mips/Kconfig	10 Sep 2003 16:45:49 -0000	1.12
+++ arch/mips/Kconfig	18 Sep 2003 16:25:07 -0000
@@ -726,6 +726,11 @@ config NEW_PCI
 	depends on ZAO_CAPCELLA || VICTOR_MPC30X || TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || NEC_EAGLE || DDB5477 || DDB5476 || DDB5074 || MIPS_ITE8172 || HP_LASERJET || MIPS_IVR || MIPS_EV96100 || MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000 || TANBAC_TB0226 || TANBAC_TB0229
 	default y
 
+config PCI_AUTO
+	bool
+	depends on DDB5477 || DDB5476
+	default y
+
 config SWAP_IO_SPACE
 	bool
 	depends on TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 || SIBYTE_SB1xxx_SOC || SGI_IP22 || MOMENCO_OCELOT_C || MOMENCO_OCELOT_G || MOMENCO_OCELOT || MIPS_MALTA || MIPS_ATLAS || MIPS_EV96100 || MIPS_PB1100 || MIPS_PB1000
Index: arch/mips/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/Makefile,v
retrieving revision 1.138
diff -u -p -r1.138 Makefile
--- arch/mips/Makefile	3 Sep 2003 15:10:33 -0000	1.138
+++ arch/mips/Makefile	18 Sep 2003 16:25:07 -0000
@@ -104,8 +104,8 @@ cflags-$(CONFIG_CPU_MIPS64)	+= 
 cflags-$(CONFIG_CPU_R5000)	+= -mcpu=r8000
 32bit-isa-$(CONFIG_CPU_R5000)	+= -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R5000)	+= -mips4 -Wa,--trap
-cflags-$(CONFIG_CPU_R5432)	+= -mcpu=r5000
-32bit-isa-$(CONFIG_CPU_R5432)	+= -mips1 -Wa,--trap
+cflags-$(CONFIG_CPU_R5432)	+= -mtune=r5000
+32bit-isa-$(CONFIG_CPU_R5432)	+= -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R5432)	+= -mips3 -Wa,--trap
 cflags-$(CONFIG_CPU_NEVADA)	+= -mcpu=r8000 -mmad
 32bit-isa-$(CONFIG_CPU_NEVADA)	+= -mips2 -Wa,--trap
Index: arch/mips/ddb5xxx/ddb5477/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/ddb5xxx/ddb5477/setup.c,v
retrieving revision 1.17
diff -u -p -r1.17 setup.c
--- arch/mips/ddb5xxx/ddb5477/setup.c	25 Aug 2003 16:15:25 -0000	1.17
+++ arch/mips/ddb5xxx/ddb5477/setup.c	18 Sep 2003 16:25:07 -0000
@@ -142,7 +142,7 @@ static void __init ddb_time_init(void)
 	}
 
 	/* mips_hpt_frequency is 1/2 of the cpu core freq */
-	i =  (read_32bit_cp0_register(CP0_CONFIG) >> 28 ) & 7;
+	i =  (read_c0_config() >> 28 ) & 7;
 	if ((current_cpu_data.cputype == CPU_R5432) && (i == 3)) 
 		i = 4;
 	mips_hpt_frequency = bus_frequency*(i+4)/4;
Index: arch/mips/pci/ops-ddb5477.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/pci/ops-ddb5477.c,v
retrieving revision 1.2
diff -u -p -r1.2 ops-ddb5477.c
--- arch/mips/pci/ops-ddb5477.c	13 Jun 2003 14:19:56 -0000	1.2
+++ arch/mips/pci/ops-ddb5477.c	18 Sep 2003 16:25:08 -0000
@@ -127,39 +127,41 @@ static inline void ddb_close_config_base
 }
 
 static int read_config_dword(struct pci_config_swap *swap,
-			     struct pci_bus *bus, u32 where, u32 * val)
+			     struct pci_bus *bus, unsigned int devfn,
+			     u32 where, u32 * val)
 {
-	u32 bus, slot_num, func_num;
+	u32 busno, 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);
+	if (bus->parent != NULL) {
+		busno = bus->number;
+		db_assert(busno != 0);
 	} else {
-		bus = 0;
+		busno = 0;
 	}
 
-	slot_num = PCI_SLOT(dev->devfn);
-	func_num = PCI_FUNC(dev->devfn);
-	base = ddb_access_config_base(swap, bus, slot_num);
+	slot_num = PCI_SLOT(devfn);
+	func_num = PCI_FUNC(devfn);
+	base = ddb_access_config_base(swap, busno, 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_bus *bus, u32 where, u16 * val)
+			    struct pci_bus *bus, unsigned int devfn,
+			    u32 where, u16 * val)
 {
 	int status;
 	u32 result;
 
 	db_assert((where & 1) == 0);
 
-	status = read_config_dword(swap, bus, where & ~3, &result);
+	status = read_config_dword(swap, bus, devfn, where & ~3, &result);
 	if (where & 2)
 		result >>= 16;
 	*val = result & 0xffff;
@@ -168,12 +170,12 @@ static int read_config_word(struct pci_c
 
 static int read_config_byte(struct pci_config_swap *swap,
 			    struct pci_bus *bus, unsigned int devfn,
-			    u8 * val)
+			    unsigned int where, u8 * val)
 {
 	int status;
 	u32 result;
 
-	status = read_config_dword(swap, bus, where & ~3, &result);
+	status = read_config_dword(swap, bus, devfn, where & ~3, &result);
 	if (where & 1)
 		result >>= 8;
 	if (where & 2)
@@ -185,7 +187,7 @@ static int read_config_byte(struct pci_c
 
 static int write_config_dword(struct pci_config_swap *swap,
 			      struct pci_bus *bus, unsigned int devfn,
-			      u32 val)
+			      unsigned int where, u32 val)
 {
 	u32 busno, slot_num, func_num;
 	u32 base;
@@ -218,7 +220,7 @@ static int write_config_word(struct pci_
 
 	db_assert((where & 1) == 0);
 
-	status = read_config_dword(swap, dev, where & ~3, &result);
+	status = read_config_dword(swap, bus, devfn, where & ~3, &result);
 	if (status != PCIBIOS_SUCCESSFUL)
 		return status;
 
@@ -226,7 +228,7 @@ static int write_config_word(struct pci_
 		shift += 16;
 	result &= ~(0xffff << shift);
 	result |= val << shift;
-	return write_config_dword(swap, dev, where & ~3, result);
+	return write_config_dword(swap, bus, devfn, where & ~3, result);
 }
 
 static int write_config_byte(struct pci_config_swap *swap,
@@ -236,7 +238,7 @@ static int write_config_byte(struct pci_
 	int status, shift = 0;
 	u32 result;
 
-	status = read_config_dword(swap, dev, where & ~3, &result);
+	status = read_config_dword(swap, bus, devfn, where & ~3, &result);
 	if (status != PCIBIOS_SUCCESSFUL)
 		return status;
 
@@ -246,28 +248,28 @@ static int write_config_byte(struct pci_
 		shift += 8;
 	result &= ~(0xff << shift);
 	result |= val << shift;
-	return write_config_dword(swap, dev, where & ~3, result);
+	return write_config_dword(swap, bus, devfn, where & ~3, result);
 }
 
 /*
  * Dump solution for now so I don't break hw I can't test on ...
  */
-#define	MAKE_PCI_OPS(prefix, rw, unitname, unittype, pciswap) \
-static int prefix##_##rw##_config(struct pci_bus *bus, int where, int size, unittype val) \
+#define	MAKE_PCI_OPS(prefix, rw, pciswap, star) \
+static int prefix##_##rw##_config(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 star val) \
 { \
 	if (size == 1) \
-     		return rw##_config_byte(pciswap, bus, where, val); \
+     		return rw##_config_byte(pciswap, bus, devfn, where, (u8 star)val); \
 	else if (size == 2) \
-     		return rw##_config_word(pciswap, bus, where, val); \
+     		return rw##_config_word(pciswap, bus, devfn, where, (u16 star)val); \
 	/* Size must be 4 */ \
-     	return rw##_config_dword(pciswap, bus, where, val); \
+     	return rw##_config_dword(pciswap, bus, devfn, where, val); \
 }
 
-MAKE_PCI_OPS(extpci, read, &ext_pci_swap)
-    MAKE_PCI_OPS(extpci, write, &ext_pci_swap)
+MAKE_PCI_OPS(extpci, read, &ext_pci_swap, *)
+MAKE_PCI_OPS(extpci, write, &ext_pci_swap,)
 
-    MAKE_PCI_OPS(iopci, read, &io_pci_swap)
-    MAKE_PCI_OPS(iopci, write, &io_pci_swap)
+MAKE_PCI_OPS(iopci, read, &io_pci_swap, *)
+MAKE_PCI_OPS(iopci, write, &io_pci_swap,)
 
 struct pci_ops ddb5477_ext_pci_ops = {
 	.read = extpci_read_config,
Index: arch/mips/pci/pci.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/pci/pci.c,v
retrieving revision 1.3
diff -u -p -r1.3 pci.c
--- arch/mips/pci/pci.c	22 Jun 2003 23:09:48 -0000	1.3
+++ arch/mips/pci/pci.c	18 Sep 2003 16:25:08 -0000
@@ -66,6 +66,8 @@
 extern void pcibios_fixup(void);
 extern void pcibios_fixup_irqs(void);
 
+#if 0
+
 void __init pcibios_fixup_irqs(void)
 {
 	struct pci_dev *dev = NULL;
@@ -126,6 +128,8 @@ void __init pcibios_fixup_resources(stru
 	}
 
 }
+
+#endif
 
 struct pci_fixup pcibios_fixups[] = {
 	{PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID,
Index: include/asm-mips/addrspace.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/addrspace.h,v
retrieving revision 1.11
diff -u -p -r1.11 addrspace.h
--- include/asm-mips/addrspace.h	9 Aug 2003 21:16:38 -0000	1.11
+++ include/asm-mips/addrspace.h	18 Sep 2003 16:25:13 -0000
@@ -75,14 +75,14 @@
  * The compatibility segments use the full 64-bit sign extended value.  Note
  * the R8000 doesn't have them so don't reference these in generic MIPS code.
  */
-#define XKUSEG			0x0000000000000000
-#define XKSSEG			0x4000000000000000
-#define XKPHYS			0x8000000000000000
-#define XKSEG			0xc000000000000000
-#define CKSEG0			0xffffffff80000000
-#define CKSEG1			0xffffffffa0000000
-#define CKSSEG			0xffffffffc0000000
-#define CKSEG3			0xffffffffe0000000
+#define XKUSEG			0x0000000000000000ULL
+#define XKSSEG			0x4000000000000000ULL
+#define XKPHYS			0x8000000000000000ULL
+#define XKSEG			0xc000000000000000ULL
+#define CKSEG0			0xffffffff80000000ULL
+#define CKSEG1			0xffffffffa0000000ULL
+#define CKSSEG			0xffffffffc0000000ULL
+#define CKSEG3			0xffffffffe0000000ULL
 
 /*
  * Cache modes for XKPHYS address conversion macros
Index: include/asm-mips/timex.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/timex.h,v
retrieving revision 1.12
diff -u -p -r1.12 timex.h
--- include/asm-mips/timex.h	20 Aug 2003 16:18:54 -0000	1.12
+++ include/asm-mips/timex.h	18 Sep 2003 16:25:13 -0000
@@ -38,6 +38,8 @@
 #define CLOCK_TICK_RATE		1193182
 #elif defined(CONFIG_SOC_AU1X00)
 #define CLOCK_TICK_RATE         ((HZ * 100000UL) / 2)
+#elif defined(CONFIG_DDB5477)
+#define CLOCK_TICK_RATE		1000000
 #endif
 
 /*
Index: sound/oss/nec_vrc5477.c
===================================================================
RCS file: /home/cvs/linux/sound/oss/nec_vrc5477.c,v
retrieving revision 1.13
diff -u -p -r1.13 nec_vrc5477.c
--- sound/oss/nec_vrc5477.c	9 Sep 2003 16:41:09 -0000	1.13
+++ sound/oss/nec_vrc5477.c	18 Sep 2003 16:25:16 -0000
@@ -8,8 +8,6 @@
  *
  * VRA support Copyright 2001 Bradley D. LaRonde <brad@ltc.com>
  *
- * VRA support Copyright 2001 Bradley D. LaRonde <brad@ltc.com>
- *
  * This program is free software; you can redistribute  it and/or modify it
  * under  the terms of  the GNU General  Public License as published by the
  * Free Software Foundation;  either version 2 of the  License, or (at your
@@ -80,6 +78,7 @@
 #include <linux/spinlock.h>
 #include <linux/smp_lock.h>
 #include <linux/ac97_codec.h>
+#include <linux/interrupt.h>
 #include <asm/io.h>
 #include <asm/dma.h>
 #include <asm/uaccess.h>
@@ -399,44 +398,6 @@ static void set_dac_rate(struct vrc5477_
 	}
 }
 
-static int ac97_codec_not_present(struct ac97_codec *codec)
-{
-	struct vrc5477_ac97_state *s = 
-		(struct vrc5477_ac97_state *)codec->private_data;
-	unsigned long flags;
-	unsigned short count  = 0xffff; 
-
-	spin_lock_irqsave(&s->lock, flags);
-
-	/* wait until we can access codec registers */
-	do {
-	       if (!(inl(s->io + VRC5477_CODEC_WR) & 0x80000000))
-		       break;
-	} while (--count);
-
-	if (count == 0) {
-		spin_unlock_irqrestore(&s->lock, flags);
-		return -1;
-	}
-
-	/* write 0 to reset */
-	outl((AC97_RESET << 16) | 0, s->io + VRC5477_CODEC_WR);
-
-	/* test whether we get a response from ac97 chip */
-	count  = 0xffff; 
-	do { 
-	       if (!(inl(s->io + VRC5477_CODEC_WR) & 0x80000000))
-		       break;
-	} while (--count);
-
-	if (count == 0) {
-		spin_unlock_irqrestore(&s->lock, flags);
-		return -1;
-	}
-	spin_unlock_irqrestore(&s->lock, flags);
-	return 0;
-}
-
 /* --------------------------------------------------------------------- */
 
 extern inline void 
@@ -1901,13 +1862,6 @@ static int __devinit vrc5477_ac97_probe(
 
         }
 
-	/* test if get response from ac97, if not return */
-        if (ac97_codec_not_present(&(s->codec))) {
-		printk(KERN_ERR PFX "no ac97 codec\n");
-		goto err_region;
-
-        }
-
 	if (!request_region(s->io, pci_resource_len(pcidev,0),
 			    VRC5477_AC97_MODULE_NAME)) {
 		printk(KERN_ERR PFX "io ports %#lx->%#lx in use\n",
@@ -2005,7 +1959,7 @@ static int __devinit vrc5477_ac97_probe(
  err_irq:
 	release_region(s->io, pci_resource_len(pcidev,0));
  err_region:
- 	ac97_release_codec(codec);
+ 	ac97_release_codec(s->codec);
 	kfree(s);
 	return -1;
 }

From macro@ds2.pg.gda.pl Thu Sep 18 18:04:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 18:04:54 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:44752 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225425AbTIRREv>; Thu, 18 Sep 2003 18:04:51 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA21405;
	Thu, 18 Sep 2003 19:04:44 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 18 Sep 2003 19:04:43 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Daniel Jacobowitz <dan@debian.org>
cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: ddb5477 fixes for 2.6
In-Reply-To: <20030918163344.GA22013@nevyn.them.org>
Message-ID: <Pine.GSO.3.96.1030918185742.20533A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3208
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1870
Lines: 58

On Thu, 18 Sep 2003, Daniel Jacobowitz wrote:

> --- arch/mips/pci/pci.c	22 Jun 2003 23:09:48 -0000	1.3
> +++ arch/mips/pci/pci.c	18 Sep 2003 16:25:08 -0000
> @@ -66,6 +66,8 @@
>  extern void pcibios_fixup(void);
>  extern void pcibios_fixup_irqs(void);
>  
> +#if 0
> +
>  void __init pcibios_fixup_irqs(void)
>  {
>  	struct pci_dev *dev = NULL;
> @@ -126,6 +128,8 @@ void __init pcibios_fixup_resources(stru
>  	}
>  
>  }
> +
> +#endif
>  
>  struct pci_fixup pcibios_fixups[] = {
>  	{PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID,

 Is it OK for other PCI systems?

> --- include/asm-mips/addrspace.h	9 Aug 2003 21:16:38 -0000	1.11
> +++ include/asm-mips/addrspace.h	18 Sep 2003 16:25:13 -0000
> @@ -75,14 +75,14 @@
>   * The compatibility segments use the full 64-bit sign extended value.  Note
>   * the R8000 doesn't have them so don't reference these in generic MIPS code.
>   */
> -#define XKUSEG			0x0000000000000000
> -#define XKSSEG			0x4000000000000000
> -#define XKPHYS			0x8000000000000000
> -#define XKSEG			0xc000000000000000
> -#define CKSEG0			0xffffffff80000000
> -#define CKSEG1			0xffffffffa0000000
> -#define CKSSEG			0xffffffffc0000000
> -#define CKSEG3			0xffffffffe0000000
> +#define XKUSEG			0x0000000000000000ULL
> +#define XKSSEG			0x4000000000000000ULL
> +#define XKPHYS			0x8000000000000000ULL
> +#define XKSEG			0xc000000000000000ULL
> +#define CKSEG0			0xffffffff80000000ULL
> +#define CKSEG1			0xffffffffa0000000ULL
> +#define CKSSEG			0xffffffffc0000000ULL
> +#define CKSEG3			0xffffffffe0000000ULL
>  
>  /*
>   * Cache modes for XKPHYS address conversion macros

 Why do you want these suffixes?  They don't work for assembly sources.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From drow@crack.them.org Thu Sep 18 18:06:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 18:06:49 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:53938 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225425AbTIRRGq>;
	Thu, 18 Sep 2003 18:06:46 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A02Es-0005vc-OA; Thu, 18 Sep 2003 13:06:42 -0400
Date: Thu, 18 Sep 2003 13:06:42 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: ddb5477 fixes for 2.6
Message-ID: <20030918170642.GA22753@nevyn.them.org>
References: <20030918163344.GA22013@nevyn.them.org> <Pine.GSO.3.96.1030918185742.20533A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030918185742.20533A-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3209
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2250
Lines: 65

On Thu, Sep 18, 2003 at 07:04:43PM +0200, Maciej W. Rozycki wrote:
> On Thu, 18 Sep 2003, Daniel Jacobowitz wrote:
> 
> > --- arch/mips/pci/pci.c	22 Jun 2003 23:09:48 -0000	1.3
> > +++ arch/mips/pci/pci.c	18 Sep 2003 16:25:08 -0000
> > @@ -66,6 +66,8 @@
> >  extern void pcibios_fixup(void);
> >  extern void pcibios_fixup_irqs(void);
> >  
> > +#if 0
> > +
> >  void __init pcibios_fixup_irqs(void)
> >  {
> >  	struct pci_dev *dev = NULL;
> > @@ -126,6 +128,8 @@ void __init pcibios_fixup_resources(stru
> >  	}
> >  
> >  }
> > +
> > +#endif
> >  
> >  struct pci_fixup pcibios_fixups[] = {
> >  	{PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID,
> 
>  Is it OK for other PCI systems?

Yes, I think so.  Those two functions seem to have migrated in from
pci-hplj.c; they can't possibly compile, since they use constants only
defined in that file.

> > --- include/asm-mips/addrspace.h	9 Aug 2003 21:16:38 -0000	1.11
> > +++ include/asm-mips/addrspace.h	18 Sep 2003 16:25:13 -0000
> > @@ -75,14 +75,14 @@
> >   * The compatibility segments use the full 64-bit sign extended value.  Note
> >   * the R8000 doesn't have them so don't reference these in generic MIPS code.
> >   */
> > -#define XKUSEG			0x0000000000000000
> > -#define XKSSEG			0x4000000000000000
> > -#define XKPHYS			0x8000000000000000
> > -#define XKSEG			0xc000000000000000
> > -#define CKSEG0			0xffffffff80000000
> > -#define CKSEG1			0xffffffffa0000000
> > -#define CKSSEG			0xffffffffc0000000
> > -#define CKSEG3			0xffffffffe0000000
> > +#define XKUSEG			0x0000000000000000ULL
> > +#define XKSSEG			0x4000000000000000ULL
> > +#define XKPHYS			0x8000000000000000ULL
> > +#define XKSEG			0xc000000000000000ULL
> > +#define CKSEG0			0xffffffff80000000ULL
> > +#define CKSEG1			0xffffffffa0000000ULL
> > +#define CKSSEG			0xffffffffc0000000ULL
> > +#define CKSEG3			0xffffffffe0000000ULL
> >  
> >  /*
> >   * Cache modes for XKPHYS address conversion macros
> 
>  Why do you want these suffixes?  They don't work for assembly sources.

Because otherwise uses of XKPHYS in a 32-bit kernel generate noisy
warnings.  I don't remember where it was offhand.  Wrap it in
__ASSEMBLY__ if you like.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From macro@ds2.pg.gda.pl Thu Sep 18 18:19:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 18:19:30 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:19409 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225425AbTIRRT2>; Thu, 18 Sep 2003 18:19:28 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA21725;
	Thu, 18 Sep 2003 19:19:22 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 18 Sep 2003 19:19:21 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Daniel Jacobowitz <dan@debian.org>
cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: ddb5477 fixes for 2.6
In-Reply-To: <20030918170642.GA22753@nevyn.them.org>
Message-ID: <Pine.GSO.3.96.1030918191604.20533C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3210
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 876
Lines: 24

On Thu, 18 Sep 2003, Daniel Jacobowitz wrote:

> >  Is it OK for other PCI systems?
> 
> Yes, I think so.  Those two functions seem to have migrated in from
> pci-hplj.c; they can't possibly compile, since they use constants only
> defined in that file.

 Then the snippet should probably get removed altogether.

> >  Why do you want these suffixes?  They don't work for assembly sources.
> 
> Because otherwise uses of XKPHYS in a 32-bit kernel generate noisy
> warnings.  I don't remember where it was offhand.  Wrap it in
> __ASSEMBLY__ if you like.

 Hmm, but is there any use for XKPHYS, etc. in a 32-bit kernel at all? 
The address cannot effectively be used anyway. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From drow@crack.them.org Thu Sep 18 18:22:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 18:22:08 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:60850 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225425AbTIRRWE>;
	Thu, 18 Sep 2003 18:22:04 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A02Tj-00062f-ME; Thu, 18 Sep 2003 13:22:03 -0400
Date: Thu, 18 Sep 2003 13:22:03 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: ddb5477 fixes for 2.6
Message-ID: <20030918172203.GA23194@nevyn.them.org>
References: <20030918170642.GA22753@nevyn.them.org> <Pine.GSO.3.96.1030918191604.20533C-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030918191604.20533C-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3211
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1131
Lines: 30

On Thu, Sep 18, 2003 at 07:19:21PM +0200, Maciej W. Rozycki wrote:
> On Thu, 18 Sep 2003, Daniel Jacobowitz wrote:
> 
> > >  Is it OK for other PCI systems?
> > 
> > Yes, I think so.  Those two functions seem to have migrated in from
> > pci-hplj.c; they can't possibly compile, since they use constants only
> > defined in that file.
> 
>  Then the snippet should probably get removed altogether.
> 
> > >  Why do you want these suffixes?  They don't work for assembly sources.
> > 
> > Because otherwise uses of XKPHYS in a 32-bit kernel generate noisy
> > warnings.  I don't remember where it was offhand.  Wrap it in
> > __ASSEMBLY__ if you like.
> 
>  Hmm, but is there any use for XKPHYS, etc. in a 32-bit kernel at all? 
> The address cannot effectively be used anyway. 

That patch is a total hack/slash job.  You're probably right on both
counts.

Take a look at __ioremap_mode which probably needs some #ifdefs for
32-bit kernels.  It uses cpu_has_64bit_addresses, which means at
runtime it's OK, but we get a lot of warnings.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ppopov@mvista.com Thu Sep 18 22:22:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 22:22:26 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:50933 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225425AbTIRVWY>;
	Thu, 18 Sep 2003 22:22:24 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA12994;
	Thu, 18 Sep 2003 14:22:18 -0700
Message-ID: <3F6A21FD.9040508@mvista.com>
Date: Thu, 18 Sep 2003 14:22:05 -0700
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bruno Randolf <bruno.randolf@4g-systems.biz>
CC: linux-mips@linux-mips.org
Subject: Re: 2.4.22 pci on au1500
References: <200309181645.00676.bruno.randolf@4g-systems.biz>
In-Reply-To: <200309181645.00676.bruno.randolf@4g-systems.biz>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3214
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3462
Lines: 71

Hi Bruno,

>i just tried 2.4.22 on my au1500 (mtx-1) board and it seems like pci is 
>broken. is there anything that has changed for the board initialization, 
>which i might have missed?
>
Yes, I changed 2.4.22 because we were calling ioremap inside the 
pci_config routine, and this is a problem for drivers that call pci 
config routines from interrupt context -- like the ide driver. I tested 
the new approach on the db1500...

>it woked fine with 2.4.21, there i got:
>
>Autoconfig PCI channel 0x802eaf28
>Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
>00:00.0 Class 0280: 1260:3873 (rev 01)
>        Mem at 0x40000000 [size=0x1000]
>
>with 2.4.22 and debugging output enabled, i get:
>
>Autoconfig PCI channel 0x802f0e88
>Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x50000000
>config_access: 0 bus 0 device 0 at 0 *data 18000057, conf 0
>config_access: 0 bus 0 device 1 at 0 *data 18000057, conf 0
>config_access: 0 bus 0 device 2 at 0 *data 180000d7, conf 0
>config_access: 0 bus 0 device 3 at 0 *data 18000157, conf 0
>config_access: 0 bus 0 device 4 at 0 *data 18000257, conf 0
>config_access: 0 bus 0 device 5 at 0 *data 18000457, conf 0
>config_access: 0 bus 0 device 6 at 0 *data 18000857, conf 0
>config_access: 0 bus 0 device 7 at 0 *data 18001057, conf 0
>config_access: 0 bus 0 device 8 at 0 *data 18002057, conf 0
>config_access: 0 bus 0 device 9 at 0 *data 18004057, conf 0
>config_access: 0 bus 0 device 10 at 0 *data 18008057, conf 0
>config_access: 0 bus 0 device 11 at 0 *data 18010057, conf 0
>config_access: 0 bus 0 device 12 at 0 *data 18020057, conf 0
>config_access: 0 bus 0 device 13 at 0 *data 18040057, conf 0
>config_access: 0 bus 0 device 14 at 0 *data 18080057, conf 0
>config_access: 0 bus 0 device 15 at 0 *data 18100057, conf 0
>config_access: 0 bus 0 device 16 at 0 *data 18200057, conf 0
>config_access: 0 bus 0 device 17 at 0 *data 18400057, conf 0
>config_access: 0 bus 0 device 18 at 0 *data 18800057, conf 0
>config_access: 0 bus 0 device 0 at e *data 18000057, conf c
>config_access: 0 bus 0 device 1 at e *data 18000057, conf c
>config_access: 0 bus 0 device 2 at e *data 180000d7, conf c
>config_access: 0 bus 0 device 3 at e *data 18000157, conf c
>config_access: 0 bus 0 device 4 at e *data 18000257, conf c
>config_access: 0 bus 0 device 5 at e *data 18000457, conf c
>config_access: 0 bus 0 device 6 at e *data 18000857, conf c
>config_access: 0 bus 0 device 7 at e *data 18001057, conf c
>config_access: 0 bus 0 device 8 at e *data 18002057, conf c
>config_access: 0 bus 0 device 9 at e *data 18004057, conf c
>config_access: 0 bus 0 device 10 at e *data 18008057, conf c
>config_access: 0 bus 0 device 11 at e *data 18010057, conf c
>config_access: 0 bus 0 device 12 at e *data 18020057, conf c
>config_access: 0 bus 0 device 13 at e *data 18040057, conf c
>config_access: 0 bus 0 device 14 at e *data 18080057, conf c
>config_access: 0 bus 0 device 15 at e *data 18100057, conf c
>config_access: 0 bus 0 device 16 at e *data 18200057, conf c
>config_access: 0 bus 0 device 17 at e *data 18400057, conf c
>config_access: 0 bus 0 device 18 at e *data 18800057, conf c
>config_access: 0 bus 0 device 19 at e *data 19000057, conf c
>
>thanks for your help - again :)
>  
>
Let me test it one more time on the db1500 to make sure something didn't 
get broken after I pushed the patch. I'll get back to you in a couple of 
days since I just got back from a long trip.

Pete


From drow@crack.them.org Thu Sep 18 22:27:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Sep 2003 22:27:30 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:49844 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225425AbTIRV12>;
	Thu, 18 Sep 2003 22:27:28 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A06JD-0006Qv-1U; Thu, 18 Sep 2003 17:27:27 -0400
Date: Thu, 18 Sep 2003 17:27:27 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: linux-mips@linux-mips.org
Cc: binutils@sources.redhat.com
Subject: recent binutils and mips64-linux
Message-ID: <20030918212727.GA24686@nevyn.them.org>
Mail-Followup-To: linux-mips@linux-mips.org, binutils@sources.redhat.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3215
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 452
Lines: 12

I'm sure this has been discussed already...

The Linux kernel currently uses among other things, -Wa,-32,-mgp64.  The
point is to use 32-bit ELF and 64-bit instructions.  But nowadays binutils
requires that the ABI explicitly match the width of GP registers.

Can gas still do ELF32 in with 64-bit registers?  If so, what the heck is
the command-line magic?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ddaney@avtrex.com Fri Sep 19 01:31:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 01:31:05 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:1426 "EHLO avtrex.com")
	by linux-mips.org with ESMTP id <S8225442AbTISAbD>;
	Fri, 19 Sep 2003 01:31:03 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 18 Sep 2003 17:30:58 -0700
Message-ID: <3F6A4E41.1090100@avtrex.com>
Date: Thu, 18 Sep 2003 17:30:57 -0700
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Will ll/sc work from user space?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Sep 2003 00:30:58.0148 (UTC) FILETIME=[4B86E240:01C37E45]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3217
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 287
Lines: 13

Q:  Will ll/sc instructions work from a linux user process ?

If so What happens if there is a context switch between the two?

What happens if the memory location is paged out and then back into a 
different physical page?

Thanks in advance for any insight into this.

David Daney.




From echristo@redhat.com Fri Sep 19 03:58:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 03:58:15 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:43274 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225446AbTISC6L>;
	Fri, 19 Sep 2003 03:58:11 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h8J2fHO03501;
	Thu, 18 Sep 2003 22:41:17 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h8J2w4L04575;
	Thu, 18 Sep 2003 22:58:04 -0400
Received: from unused (vpn26-7.sfbay.redhat.com [172.16.26.7])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h8J2w1w21860;
	Thu, 18 Sep 2003 19:58:03 -0700
Subject: Re: recent binutils and mips64-linux
From: Eric Christopher <echristo@redhat.com>
To: Daniel Jacobowitz <dan@debian.org>
Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com
In-Reply-To: <20030918212727.GA24686@nevyn.them.org>
References: <20030918212727.GA24686@nevyn.them.org>
Content-Type: text/plain
Message-Id: <1063940280.2423.13.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Thu, 18 Sep 2003 19:58:00 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3218
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 620
Lines: 21

On Thu, 2003-09-18 at 14:27, Daniel Jacobowitz wrote:
> I'm sure this has been discussed already...
> 
> The Linux kernel currently uses among other things, -Wa,-32,-mgp64.  The
> point is to use 32-bit ELF and 64-bit instructions.  But nowadays binutils
> requires that the ABI explicitly match the width of GP registers.
> 
> Can gas still do ELF32 in with 64-bit registers?  If so, what the heck is
> the command-line magic?

Discussed on irc :)

mips-linux-gcc -mabi=32 -march=64bitarch is my suggestion.

otherwise, -mabi=o64 is o32 extended to 64-bit registers.

-eric

-- 
Eric Christopher <echristo@redhat.com>


From nemoto@toshiba-tops.co.jp Fri Sep 19 04:27:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 04:27:33 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:12558
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225348AbTISD1b>; Fri, 19 Sep 2003 04:27:31 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 19 Sep 2003 03:27:29 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h8J3REgc078367;
	Fri, 19 Sep 2003 12:27:15 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Fri, 19 Sep 2003 12:29:40 +0900 (JST)
Message-Id: <20030919.122940.45519247.nemoto@toshiba-tops.co.jp>
To: echristo@redhat.com
Cc: dan@debian.org, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <1063940280.2423.13.camel@ghostwheel.sfbay.redhat.com>
References: <20030918212727.GA24686@nevyn.them.org>
	<1063940280.2423.13.camel@ghostwheel.sfbay.redhat.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3219
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 332
Lines: 9

>>>>> On Thu, 18 Sep 2003 19:58:00 -0700, Eric Christopher <echristo@redhat.com> said:
echristo> mips-linux-gcc -mabi=32 -march=64bitarch is my suggestion.

But mips64 kernel assumes that the kernel itself is compiled with
"-mabi=64".  For example, some asm routines pass more than 4 arguments
via aN registers.

---
Atsushi Nemoto

From drow@crack.them.org Fri Sep 19 04:28:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 04:28:12 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:64950 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225348AbTISD2J>;
	Fri, 19 Sep 2003 04:28:09 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A0Bw9-00037v-Ky; Thu, 18 Sep 2003 23:28:01 -0400
Date: Thu, 18 Sep 2003 23:28:01 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Cc: echristo@redhat.com, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030919032801.GA11998@nevyn.them.org>
Mail-Followup-To: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	echristo@redhat.com, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
References: <20030918212727.GA24686@nevyn.them.org> <1063940280.2423.13.camel@ghostwheel.sfbay.redhat.com> <20030919.122940.45519247.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030919.122940.45519247.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3220
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 603
Lines: 14

On Fri, Sep 19, 2003 at 12:29:40PM +0900, Atsushi Nemoto wrote:
> >>>>> On Thu, 18 Sep 2003 19:58:00 -0700, Eric Christopher <echristo@redhat.com> said:
> echristo> mips-linux-gcc -mabi=32 -march=64bitarch is my suggestion.
> 
> But mips64 kernel assumes that the kernel itself is compiled with
> "-mabi=64".  For example, some asm routines pass more than 4 arguments
> via aN registers.

I was able to build using -mabi=64 -Wa,-mabi=o64.  There are... some
issues... but I think that's just this board port.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From echristo@redhat.com Fri Sep 19 06:39:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 06:39:59 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:64012 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225348AbTISFj5>;
	Fri, 19 Sep 2003 06:39:57 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h8J5N1O10698;
	Fri, 19 Sep 2003 01:23:01 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h8J5dlL14550;
	Fri, 19 Sep 2003 01:39:47 -0400
Received: from ghostwheel.sfbay.redhat.com (vpn26-2.sfbay.redhat.com [172.16.26.2])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h8J5dkw26945;
	Thu, 18 Sep 2003 22:39:46 -0700
Subject: Re: recent binutils and mips64-linux
From: Eric Christopher <echristo@redhat.com>
To: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Cc: Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
In-Reply-To: <20030919.122940.45519247.nemoto@toshiba-tops.co.jp>
References: <20030918212727.GA24686@nevyn.them.org>
	 <1063940280.2423.13.camel@ghostwheel.sfbay.redhat.com>
	 <20030919.122940.45519247.nemoto@toshiba-tops.co.jp>
Content-Type: text/plain
Message-Id: <1063949984.2537.0.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Thu, 18 Sep 2003 22:39:45 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3221
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 565
Lines: 16

On Thu, 2003-09-18 at 20:29, Atsushi Nemoto wrote:
> >>>>> On Thu, 18 Sep 2003 19:58:00 -0700, Eric Christopher <echristo@redhat.com> said:
> echristo> mips-linux-gcc -mabi=32 -march=64bitarch is my suggestion.
> 
> But mips64 kernel assumes that the kernel itself is compiled with
> "-mabi=64".  For example, some asm routines pass more than 4 arguments
> via aN registers.

Yes, but then you aren't abi compliant are you? If you want n64 then say
n64. If you want o32 extended to 64-bit registers then use o64.

-eric

-- 
Eric Christopher <echristo@redhat.com>


From nemoto@toshiba-tops.co.jp Fri Sep 19 08:20:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 08:20:53 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:53026
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225348AbTISHUv>; Fri, 19 Sep 2003 08:20:51 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 19 Sep 2003 07:20:49 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h8J7KZgc079191;
	Fri, 19 Sep 2003 16:20:36 +0900 (JST)
	(envelope-from nemoto@toshiba-tops.co.jp)
Date: Fri, 19 Sep 2003 16:23:01 +0900 (JST)
Message-Id: <20030919.162301.48536245.nemoto@toshiba-tops.co.jp>
To: dan@debian.org
Cc: echristo@redhat.com, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <20030919032801.GA11998@nevyn.them.org>
References: <1063940280.2423.13.camel@ghostwheel.sfbay.redhat.com>
	<20030919.122940.45519247.nemoto@toshiba-tops.co.jp>
	<20030919032801.GA11998@nevyn.them.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3222
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 427
Lines: 10

>>>>> On Thu, 18 Sep 2003 23:28:01 -0400, Daniel Jacobowitz <dan@debian.org> said:
dan> I was able to build using -mabi=64 -Wa,-mabi=o64.  There
dan> are... some issues... but I think that's just this board port.

The "-Wa,-mabi=o64" works good for me.  Without this option, I had to
use ld.script.elf64 and convert vmlinux to elf32-tradlittlemips using
objcopy if I wanted to use newer binutils.  Thanks!!

---
Atsushi Nemoto

From macro@ds2.pg.gda.pl Fri Sep 19 12:17:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 12:18:01 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:17908 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225450AbTISLR6>; Fri, 19 Sep 2003 12:17:58 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA09504;
	Fri, 19 Sep 2003 13:17:50 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 19 Sep 2003 13:17:49 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Daney <ddaney@avtrex.com>
cc: linux-mips@linux-mips.org
Subject: Re: Will ll/sc work from user space?
In-Reply-To: <3F6A4E41.1090100@avtrex.com>
Message-ID: <Pine.GSO.3.96.1030919130424.9134A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3223
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 504
Lines: 18

On Thu, 18 Sep 2003, David Daney wrote:

> Q:  Will ll/sc instructions work from a linux user process ?

 Yep.

> If so What happens if there is a context switch between the two?
> 
> What happens if the memory location is paged out and then back into a 
> different physical page?

 Then sc will fail.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From macro@ds2.pg.gda.pl Fri Sep 19 12:55:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 12:55:53 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:37109 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225453AbTISLzv>; Fri, 19 Sep 2003 12:55:51 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA10155;
	Fri, 19 Sep 2003 13:55:46 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 19 Sep 2003 13:55:45 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
cc: linux-mips@linux-mips.org
Subject: Re: mips64 cpu-probe.c compile failure
In-Reply-To: <20030918.232202.07646481.anemo@mba.ocn.ne.jp>
Message-ID: <Pine.GSO.3.96.1030919132308.9134B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3224
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 2453
Lines: 61

On Thu, 18 Sep 2003, Atsushi Nemoto wrote:

> macro>  I wanted to avoid that as the resulting code would be ugly.  I
> macro> guess there is no other choice, although I think that's a bug
> macro> in gcc.
> 
> I have no idea that is a gcc bug, but I think align_mod() inline
> function is not so beautiful because it can not be compiled anyway if
> non-constant value was passed.

 Well, the asm statement requires immediates, so if macros are used
variables won't work anyway, but the the code will look more obscurely.

> macro>  Can you quote the exact command line used for building the
> macro> file?
> 
> mips64el-linux-gcc -D__KERNEL__ -I/home/anemo/work/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /home/anemo/work/linux/include/asm/gcc -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe  -march=r4600   -nostdinc -iwithprefix include -DKBUILD_BASENAME=cpu_probe  -c -o cpu-probe.o cpu-probe.c
> 
> I also tried with -finline-limit=100000 but no luck.

 It looks like gcc insists on forcing the constants into registers.  The
following patch should work for gcc 3.x.  A few warnings will still be
emitted, but the code will get build properly.

 I'm applying the change to the CVS as it's good anyway.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

patch-mips-2.4.22-20030916-mips-bugs-gcc3-0
diff -up --recursive --new-file linux-mips-2.4.22-20030916.macro/arch/mips64/kernel/cpu-probe.c linux-mips-2.4.22-20030916/arch/mips64/kernel/cpu-probe.c
--- linux-mips-2.4.22-20030916.macro/arch/mips64/kernel/cpu-probe.c	2003-09-12 01:18:01.000000000 +0000
+++ linux-mips-2.4.22-20030916/arch/mips64/kernel/cpu-probe.c	2003-09-18 22:14:19.000000000 +0000
@@ -113,7 +113,7 @@ static inline void check_wait(void)
 	}
 }
 
-static inline void align_mod(int align, int mod)
+static inline void align_mod(const int align, const int mod)
 {
 	asm volatile(
 		".set	push\n\t"
@@ -124,11 +124,11 @@ static inline void align_mod(int align, 
 		".endr\n\t"
 		".set	pop"
 		:
-		: "i" (align), "i" (mod));
+		: "n" (align), "n" (mod));
 }
 
 static inline void mult_sh_align_mod(long *v1, long *v2, long *w,
-				     int align, int mod)
+				     const int align, const int mod)
 {
 	unsigned long flags;
 	int m1, m2;


From macro@ds2.pg.gda.pl Fri Sep 19 13:52:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 13:52:56 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:29431 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225456AbTISMwx>; Fri, 19 Sep 2003 13:52:53 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA11097;
	Fri, 19 Sep 2003 14:52:35 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 19 Sep 2003 14:52:35 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Eric Christopher <echristo@redhat.com>
cc: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
In-Reply-To: <1063949984.2537.0.camel@ghostwheel.sfbay.redhat.com>
Message-ID: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3225
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 917
Lines: 20

On Thu, 18 Sep 2003, Eric Christopher wrote:

> > But mips64 kernel assumes that the kernel itself is compiled with
> > "-mabi=64".  For example, some asm routines pass more than 4 arguments
> > via aN registers.
> 
> Yes, but then you aren't abi compliant are you? If you want n64 then say
> n64. If you want o32 extended to 64-bit registers then use o64.

 I think "-mabi=64" is OK (I use it for over a year now) and for those
worried of every byte of precious memory, "-mabi=n32 -mlong64" might be
the right long-term answer (although it might require verifying if tools
handle it right).  Given the experimental state of the 64-bit kernel it
should be OK to be less forgiving on a requirement for recent tools. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From rathann@icm.edu.pl Fri Sep 19 14:17:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 14:17:45 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:54192 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225459AbTISNRm>;
	Fri, 19 Sep 2003 14:17:42 +0100
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.4/icm) with ESMTP id h8JDHXEp007548
	for <linux-mips@linux-mips.org>; Fri, 19 Sep 2003 15:17:33 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1A0L8b-0006wP-00
	for <linux-mips@linux-mips.org>; Fri, 19 Sep 2003 15:17:29 +0200
Date: Fri, 19 Sep 2003 15:17:24 +0200
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: list archive
Message-ID: <20030919131724.GA26606@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3226
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 346
Lines: 12

Hello, list.

I've just got my first Indy box running Linux. And so, to avoid annoying
you by asking stupid newbie questions I'll ask only one: where can I
find this list's archives? Searching google for
"linux-mips@linux-mips.org archive" doesn't yield anything of interest.

Regards,
R.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

From macro@ds2.pg.gda.pl Fri Sep 19 14:38:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 14:38:27 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:6393 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225462AbTISNiZ>; Fri, 19 Sep 2003 14:38:25 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA11915;
	Fri, 19 Sep 2003 15:37:13 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 19 Sep 2003 15:37:12 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
cc: linux-mips@linux-mips.org
Subject: Re: list archive
In-Reply-To: <20030919131724.GA26606@icm.edu.pl>
Message-ID: <Pine.GSO.3.96.1030919153437.9134E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3227
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 617
Lines: 15

On Fri, 19 Sep 2003, Dominik 'Rathann' Mierzejewski wrote:

> I've just got my first Indy box running Linux. And so, to avoid annoying
> you by asking stupid newbie questions I'll ask only one: where can I
> find this list's archives? Searching google for
> "linux-mips@linux-mips.org archive" doesn't yield anything of interest.

 See "http://www.linux-mips.org/mail.html" (the first page reported by
Google ;-) ).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From rathann@icm.edu.pl Fri Sep 19 15:02:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 15:02:02 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:38917 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225466AbTISOCA>;
	Fri, 19 Sep 2003 15:02:00 +0100
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.4/icm) with ESMTP id h8JE1pEp008436
	for <linux-mips@linux-mips.org>; Fri, 19 Sep 2003 16:01:51 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1A0LpT-0007JI-00
	for <linux-mips@linux-mips.org>; Fri, 19 Sep 2003 16:01:47 +0200
Date: Fri, 19 Sep 2003 16:01:42 +0200
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: list archive
Message-ID: <20030919140142.GA28087@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030919131724.GA26606@icm.edu.pl> <Pine.GSO.3.96.1030919153437.9134E-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030919153437.9134E-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3228
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 642
Lines: 16

On Fri, Sep 19, 2003 at 03:37:12PM +0200, Maciej W. Rozycki wrote:
> On Fri, 19 Sep 2003, Dominik 'Rathann' Mierzejewski wrote:
> 
> > I've just got my first Indy box running Linux. And so, to avoid annoying
> > you by asking stupid newbie questions I'll ask only one: where can I
> > find this list's archives? Searching google for
> > "linux-mips@linux-mips.org archive" doesn't yield anything of interest.
> 
>  See "http://www.linux-mips.org/mail.html" (the first page reported by
> Google ;-) ).

Yes, I see it now, thanks. But I was counting on an online and searchable
archive.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

From anemo@mba.ocn.ne.jp Fri Sep 19 15:19:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 15:19:30 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:34567
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225464AbTISOTS>; Fri, 19 Sep 2003 15:19:18 +0100
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 19 Sep 2003 14:19:16 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h8JEIvgc080101;
	Fri, 19 Sep 2003 23:18:57 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 19 Sep 2003 23:21:23 +0900 (JST)
Message-Id: <20030919.232123.38717932.nemoto@toshiba-tops.co.jp>
To: macro@ds2.pg.gda.pl
Cc: linux-mips@linux-mips.org
Subject: Re: mips64 cpu-probe.c compile failure
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.GSO.3.96.1030919132308.9134B-100000@delta.ds2.pg.gda.pl>
References: <20030918.232202.07646481.anemo@mba.ocn.ne.jp>
	<Pine.GSO.3.96.1030919132308.9134B-100000@delta.ds2.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3229
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 692
Lines: 17

>>>>> On Fri, 19 Sep 2003 13:55:45 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
macro>  Well, the asm statement requires immediates, so if macros are
macro> used variables won't work anyway, but the the code will look
macro> more obscurely.

Yes, though variables won't work anyway, the inline function looks
like it can accept variables (for careless reader).  But that's just
my impression.

macro>  It looks like gcc insists on forcing the constants into
macro> registers.  The following patch should work for gcc 3.x.  A few
macro> warnings will still be emitted, but the code will get build
macro> properly.

Thanks.  It works fine with gcc 3.3.1.
---
Atsushi Nemoto

From echristo@redhat.com Fri Sep 19 17:20:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 17:20:59 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:40209 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225466AbTISQUx>;
	Fri, 19 Sep 2003 17:20:53 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h8JG3qO04466;
	Fri, 19 Sep 2003 12:03:52 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h8JGKTL20853;
	Fri, 19 Sep 2003 12:20:29 -0400
Received: from ghostwheel.sfbay.redhat.com (vpn26-2.sfbay.redhat.com [172.16.26.2])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h8JGKMw20758;
	Fri, 19 Sep 2003 09:20:22 -0700
Subject: Re: recent binutils and mips64-linux
From: Eric Christopher <echristo@redhat.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
In-Reply-To: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain
Message-Id: <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Fri, 19 Sep 2003 09:20:20 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3230
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1128
Lines: 26

On Fri, 2003-09-19 at 05:52, Maciej W. Rozycki wrote:
> On Thu, 18 Sep 2003, Eric Christopher wrote:
> 
> > > But mips64 kernel assumes that the kernel itself is compiled with
> > > "-mabi=64".  For example, some asm routines pass more than 4 arguments
> > > via aN registers.
> > 
> > Yes, but then you aren't abi compliant are you? If you want n64 then say
> > n64. If you want o32 extended to 64-bit registers then use o64.
> 
>  I think "-mabi=64" is OK (I use it for over a year now) and for those
> worried of every byte of precious memory, "-mabi=n32 -mlong64" might be
> the right long-term answer (although it might require verifying if tools
> handle it right).  Given the experimental state of the 64-bit kernel it
> should be OK to be less forgiving on a requirement for recent tools. 

OK as in "it works for me", and OK as in "this is the correct usage" are
two different things. I believe that for a 64-bit kernel either -mabi=64
or -mabi=n32 (-mlong64) are the right long term answer, part of Daniel's
problem was that his bootloader couldn't deal with ELF64.

-eric

-- 
Eric Christopher <echristo@redhat.com>


From ica2_ts@csv.ica.uni-stuttgart.de Fri Sep 19 17:41:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 17:41:33 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:11310
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225469AbTISQla>; Fri, 19 Sep 2003 17:41:30 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A0OJs-00036g-00; Fri, 19 Sep 2003 18:41:20 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A0OJr-0003ca-00; Fri, 19 Sep 2003 18:41:19 +0200
Date: Fri, 19 Sep 2003 18:41:19 +0200
To: Eric Christopher <echristo@redhat.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl> <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3231
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1356
Lines: 31

Eric Christopher wrote:
> On Fri, 2003-09-19 at 05:52, Maciej W. Rozycki wrote:
> > On Thu, 18 Sep 2003, Eric Christopher wrote:
> > 
> > > > But mips64 kernel assumes that the kernel itself is compiled with
> > > > "-mabi=64".  For example, some asm routines pass more than 4 arguments
> > > > via aN registers.
> > > 
> > > Yes, but then you aren't abi compliant are you? If you want n64 then say
> > > n64. If you want o32 extended to 64-bit registers then use o64.
> > 
> >  I think "-mabi=64" is OK (I use it for over a year now) and for those
> > worried of every byte of precious memory, "-mabi=n32 -mlong64" might be
> > the right long-term answer (although it might require verifying if tools
> > handle it right).  Given the experimental state of the 64-bit kernel it
> > should be OK to be less forgiving on a requirement for recent tools. 
> 
> OK as in "it works for me", and OK as in "this is the correct usage" are
> two different things. I believe that for a 64-bit kernel either -mabi=64
> or -mabi=n32 (-mlong64) are the right long term answer,

A third answer is to add a -msign-extend-addresses switch in the assembler.
Together with -mabi=64 this would produce optimized ELF64 output.

> part of Daniel's
> problem was that his bootloader couldn't deal with ELF64.

Well, implementing an ELF64 bootloader ins't that hard. :-)


Thiemo

From macro@ds2.pg.gda.pl Fri Sep 19 17:42:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 17:42:25 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:15745 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225469AbTISQmX>; Fri, 19 Sep 2003 17:42:23 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA15739;
	Fri, 19 Sep 2003 18:42:12 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 19 Sep 2003 18:42:11 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Eric Christopher <echristo@redhat.com>
cc: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
In-Reply-To: <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
Message-ID: <Pine.GSO.3.96.1030919182314.9134K-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3232
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1415
Lines: 29

On Fri, 19 Sep 2003, Eric Christopher wrote:

> >  I think "-mabi=64" is OK (I use it for over a year now) and for those
> > worried of every byte of precious memory, "-mabi=n32 -mlong64" might be
> > the right long-term answer (although it might require verifying if tools
> > handle it right).  Given the experimental state of the 64-bit kernel it
> > should be OK to be less forgiving on a requirement for recent tools. 
> 
> OK as in "it works for me", and OK as in "this is the correct usage" are

 Well, my "OK" is of both kinds. 8-) 

> two different things. I believe that for a 64-bit kernel either -mabi=64
> or -mabi=n32 (-mlong64) are the right long term answer, part of Daniel's
> problem was that his bootloader couldn't deal with ELF64.

 I've successfully converted ELF64 Linux images to o32 ELF32, with
`objcopy' and then to COFF even, with `elf2ecoff' (provided with the Linux
sources).  The resulting COFF image used to work with the DECstation's
firmware.  I suppose the intermediate ELF32 one would work with
ELF-capable firmware, too.  Of course I had to make sure the addresses
seen by the firmware in the file headers fit the 32-bit address space
(KSEG0, actually; KSEG1 might work, too). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From macro@ds2.pg.gda.pl Fri Sep 19 17:46:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 17:47:04 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:32897 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225472AbTISQqw>; Fri, 19 Sep 2003 17:46:52 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA15879;
	Fri, 19 Sep 2003 18:46:31 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 19 Sep 2003 18:46:31 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: Eric Christopher <echristo@redhat.com>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
In-Reply-To: <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030919184248.9134L-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3233
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 946
Lines: 24

On Fri, 19 Sep 2003, Thiemo Seufer wrote:

> > OK as in "it works for me", and OK as in "this is the correct usage" are
> > two different things. I believe that for a 64-bit kernel either -mabi=64
> > or -mabi=n32 (-mlong64) are the right long term answer,
> 
> A third answer is to add a -msign-extend-addresses switch in the assembler.
> Together with -mabi=64 this would produce optimized ELF64 output.

 Hmm, what do you exactly mean -- is that what I am worrying about?

> > part of Daniel's
> > problem was that his bootloader couldn't deal with ELF64.
> 
> Well, implementing an ELF64 bootloader ins't that hard. :-)

 That depends on how hard it's to replace some firmware.  Using a
secondary boot loader is not always feasible, either.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From ica2_ts@csv.ica.uni-stuttgart.de Fri Sep 19 17:57:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 17:58:01 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:26158
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225472AbTISQ54>; Fri, 19 Sep 2003 17:57:56 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A0OZo-0003IA-00; Fri, 19 Sep 2003 18:57:48 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A0OZn-0003e6-00; Fri, 19 Sep 2003 18:57:47 +0200
Date: Fri, 19 Sep 2003 18:57:47 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Eric Christopher <echristo@redhat.com>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030919165747.GI13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com> <Pine.GSO.3.96.1030919182314.9134K-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030919182314.9134K-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3234
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 637
Lines: 16

Maciej W. Rozycki wrote:
[snip]
> > two different things. I believe that for a 64-bit kernel either -mabi=64
> > or -mabi=n32 (-mlong64) are the right long term answer, part of Daniel's
> > problem was that his bootloader couldn't deal with ELF64.
> 
>  I've successfully converted ELF64 Linux images to o32 ELF32, with
> `objcopy' and then to COFF even, with `elf2ecoff' (provided with the Linux
> sources). The resulting COFF image used to work with the DECstation's
> firmware.  I suppose the intermediate ELF32 one would work with
> ELF-capable firmware, too.

I booted the ELF32 file via the delo bootloader and it worked.


Thiemo

From ica2_ts@csv.ica.uni-stuttgart.de Fri Sep 19 18:08:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 18:08:38 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:32558
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225472AbTISRIc>; Fri, 19 Sep 2003 18:08:32 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A0Ok5-0003O6-00; Fri, 19 Sep 2003 19:08:25 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A0Ok5-0003lM-00; Fri, 19 Sep 2003 19:08:25 +0200
Date: Fri, 19 Sep 2003 19:08:25 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Eric Christopher <echristo@redhat.com>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030919170825.GJ13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030919184248.9134L-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030919184248.9134L-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3235
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 705
Lines: 18

Maciej W. Rozycki wrote:
> On Fri, 19 Sep 2003, Thiemo Seufer wrote:
> 
> > > OK as in "it works for me", and OK as in "this is the correct usage" are
> > > two different things. I believe that for a 64-bit kernel either -mabi=64
> > > or -mabi=n32 (-mlong64) are the right long term answer,
> > 
> > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > Together with -mabi=64 this would produce optimized ELF64 output.
> 
>  Hmm, what do you exactly mean -- is that what I am worrying about?

The idea is to use the assembler's 32bit macro expansions for addresses.
This reduces the .text size of a n64 kernel and improves the performance,
without tricks like -Wa,32.


Thiemo

From macro@ds2.pg.gda.pl Fri Sep 19 18:20:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 18:20:18 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:8835 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225472AbTISRUL>; Fri, 19 Sep 2003 18:20:11 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA16658;
	Fri, 19 Sep 2003 19:19:39 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 19 Sep 2003 19:19:38 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: Eric Christopher <echristo@redhat.com>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
In-Reply-To: <20030919170825.GJ13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030919190901.9134M-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3236
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 974
Lines: 26

On Fri, 19 Sep 2003, Thiemo Seufer wrote:

> > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > > Together with -mabi=64 this would produce optimized ELF64 output.
> > 
> >  Hmm, what do you exactly mean -- is that what I am worrying about?
> 
> The idea is to use the assembler's 32bit macro expansions for addresses.

 So it is...

> This reduces the .text size of a n64 kernel and improves the performance,
> without tricks like -Wa,32.

 What if the final link leads to segments being mapped outside the 32-bit
address range?  We won't know about it when assembling.

 If the idea were to be implemented, there should be a flag added to the
header of object files that would forbid the linker to map addresses
outside the 32-bit range.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From ica2_ts@csv.ica.uni-stuttgart.de Fri Sep 19 18:40:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 18:40:50 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:48686
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225472AbTISRkr>; Fri, 19 Sep 2003 18:40:47 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A0PFH-0003eu-00; Fri, 19 Sep 2003 19:40:39 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A0PFH-0001ZG-00; Fri, 19 Sep 2003 19:40:39 +0200
Date: Fri, 19 Sep 2003 19:40:39 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Eric Christopher <echristo@redhat.com>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030919174039.GK13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030919170825.GJ13578@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030919190901.9134M-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030919190901.9134M-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3237
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1161
Lines: 31

Maciej W. Rozycki wrote:
> On Fri, 19 Sep 2003, Thiemo Seufer wrote:
> 
> > > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > > > Together with -mabi=64 this would produce optimized ELF64 output.
> > > 
> > >  Hmm, what do you exactly mean -- is that what I am worrying about?
> > 
> > The idea is to use the assembler's 32bit macro expansions for addresses.
> 
>  So it is...
> 
> > This reduces the .text size of a n64 kernel and improves the performance,
> > without tricks like -Wa,32.
> 
>  What if the final link leads to segments being mapped outside the 32-bit
> address range?  We won't know about it when assembling.

Then the resulting code is broken. It's the programmers responsibility
to care about it. IMHO that's not a problem, this feature is only
useful for kernels, and the tricks currently done there are worse.

>  If the idea were to be implemented, there should be a flag added to the
> header of object files that would forbid the linker to map addresses
> outside the 32-bit range.

Please don't add any header flag. An additional (.note?) section would
be nice, but is not a priority for me.


Thiemo

From macro@ds2.pg.gda.pl Fri Sep 19 19:15:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 19:15:05 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:40837 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225472AbTISSPC>; Fri, 19 Sep 2003 19:15:02 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA17729;
	Fri, 19 Sep 2003 20:14:46 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Fri, 19 Sep 2003 20:14:45 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: Eric Christopher <echristo@redhat.com>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
In-Reply-To: <20030919174039.GK13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030919200133.9134N-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3238
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1413
Lines: 34

On Fri, 19 Sep 2003, Thiemo Seufer wrote:

> >  What if the final link leads to segments being mapped outside the 32-bit
> > address range?  We won't know about it when assembling.
> 
> Then the resulting code is broken. It's the programmers responsibility
> to care about it. IMHO that's not a problem, this feature is only

 Sure, but some kind of aid, perhaps conditional, from tools would be
good.  The linker is already unconditionally picky about certain
properties of object files, e.g. it won't link a PIC and a PDC object
together, even if there are no relocations in them.  One could say it's a
programmer's responsibility, too. 

> useful for kernels, and the tricks currently done there are worse.

 No doubt.

> >  If the idea were to be implemented, there should be a flag added to the
> > header of object files that would forbid the linker to map addresses
> > outside the 32-bit range.
> 
> Please don't add any header flag. An additional (.note?) section would
> be nice, but is not a priority for me.

 Well, I might not really care of something I'm not going to use, but we
should try to assure some level of engineering quality whenever possible.
A flag vs a special section is alike to me.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From dkesselr@mmc.atmel.com Fri Sep 19 19:28:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 19:28:59 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:56215
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225472AbTISS25>; Fri, 19 Sep 2003 19:28:57 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA06782
	for <linux-mips@linux-mips.org>; Fri, 19 Sep 2003 14:28:50 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA00927
	for <linux-mips@linux-mips.org>; Fri, 19 Sep 2003 14:28:50 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Fri, 19 Sep 2003 14:28:49 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: Re: recent binutils and mips64-linux
In-Reply-To: <20030919174039.GK13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.4.44.0309191423200.773-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3239
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1679
Lines: 49

I've been trying to follow this discussion but I don't see the consensus.
Probably from my inexperience. Can someone summarize what works now, as
opposed to what should be done? Is
the solution the same for the 2.4kernel/gcc2.95 and the 2.6kernel/gcc3+?
Also are all of these comments appicable to little and big endian systems?
Thanks,
David Kesselring

On Fri, 19 Sep 2003, Thiemo Seufer wrote:

> Maciej W. Rozycki wrote:
> > On Fri, 19 Sep 2003, Thiemo Seufer wrote:
> >
> > > > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > > > > Together with -mabi=64 this would produce optimized ELF64 output.
> > > >
> > > >  Hmm, what do you exactly mean -- is that what I am worrying about?
> > >
> > > The idea is to use the assembler's 32bit macro expansions for addresses.
> >
> >  So it is...
> >
> > > This reduces the .text size of a n64 kernel and improves the performance,
> > > without tricks like -Wa,32.
> >
> >  What if the final link leads to segments being mapped outside the 32-bit
> > address range?  We won't know about it when assembling.
>
> Then the resulting code is broken. It's the programmers responsibility
> to care about it. IMHO that's not a problem, this feature is only
> useful for kernels, and the tricks currently done there are worse.
>
> >  If the idea were to be implemented, there should be a flag added to the
> > header of object files that would forbid the linker to map addresses
> > outside the 32-bit range.
>
> Please don't add any header flag. An additional (.note?) section would
> be nice, but is not a priority for me.
>
>
> Thiemo
>
>

David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com
919-462-6587


From dom@mips.com Fri Sep 19 21:11:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 19 Sep 2003 21:11:59 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:45328 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225472AbTISUL5>;
	Fri, 19 Sep 2003 21:11:57 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1A0RbB-0002CY-00; Fri, 19 Sep 2003 21:11:25 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1A0RbI-00021m-00; Fri, 19 Sep 2003 21:11:32 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16235.25337.917444.302915@doms-laptop.algor.co.uk>
Date: Fri, 19 Sep 2003 22:11:37 +0200
To: David Daney <ddaney@avtrex.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Will ll/sc work from user space?
In-Reply-To: <3F6A4E41.1090100@avtrex.com>
References: <3F6A4E41.1090100@avtrex.com>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-2.6, required 4, AWL,
	BAYES_20, QUOTED_EMAIL_TEXT, REFERENCES)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3240
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 535
Lines: 24


David,

> Q:  Will ll/sc instructions work from a linux user process ?

As Maciej says, yes.

> If so What happens if there is a context switch between the two?

The sc fails.

It fails whenever any interrupt or other exception (perhaps a VM
event, for example) happens after the ll but before the sc.

> What happens if the memory location is paged out and then back into a 
> different physical page?

If that happens between the ll and the sc, then you must certainly
have got an interrupt.

--
Dominic Sweetman
MIPS Technologies


From drow@crack.them.org Sat Sep 20 16:20:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 20 Sep 2003 16:20:45 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:27328 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225492AbTITPUm>;
	Sat, 20 Sep 2003 16:20:42 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A0jXI-0003Mo-U3
	for <linux-mips@linux-mips.org>; Sat, 20 Sep 2003 11:20:36 -0400
Date: Sat, 20 Sep 2003 11:20:36 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: linux-mips@linux-mips.org
Subject: Impossible fixup in do_ade
Message-ID: <20030920152036.GA12905@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3241
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1995
Lines: 49

Here's a snippet from emulate_load_store_insn.  See the way the sdl and sdr
are wrapped in fixups?  Well, the fixups can't trigger: we get to
emulate_load_store_insn a second time, and we hit the fact that sdl_op has a
"goto sigbus" before we hit the fixup_exception call.

It doesn't much matter, the bug I'm working on is whatever caused the first
call.  But we get a SIGBUS when arguably we ought to get a SIGSEGV.

        case sd_op:
#ifdef CONFIG_MIPS64
                /*
                 * A 32-bit kernel might be running on a 64-bit processor.  But
                 * if we're on a 32-bit processor and an i-cache incoherency
                 * or race makes us see a 64-bit instruction here the sdl/sdr
                 * would blow up, so for now we don't handle unaligned 64-bit
                 * instructions on 32-bit kernels.
                 */
                if (verify_area(VERIFY_WRITE, addr, 8))
                        goto sigbus;

                value = regs->regs[insn.i_format.rt];
                __asm__ __volatile__ (
#ifdef __BIG_ENDIAN
                        "1:\tsdl\t%1,(%2)\n"
                        "2:\tsdr\t%1, 7(%2)\n\t"
#endif
#ifdef __LITTLE_ENDIAN
                        "1:\tsdl\t%1, 7(%2)\n"
                        "2:\tsdr\t%1, (%2)\n\t"
#endif
                        "li\t%0, 0\n"
                        "3:\n\t"
                        ".section\t.fixup,\"ax\"\n\t"
                        "4:\tli\t%0, %3\n\t"
                        "j\t3b\n\t"
                        ".previous\n\t"
                        ".section\t__ex_table,\"a\"\n\t"
                        STR(PTR)"\t1b, 4b\n\t"
                        STR(PTR)"\t2b, 4b\n\t"
                        ".previous"
                : "=r" (res)
                : "r" (value), "r" (addr), "i" (-EFAULT));
                if (res)
                        goto fault;
                break;

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ica2_ts@csv.ica.uni-stuttgart.de Sun Sep 21 22:23:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 21 Sep 2003 22:23:23 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:47677
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225508AbTIUVXT>; Sun, 21 Sep 2003 22:23:19 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1Bfl-0007V8-00; Sun, 21 Sep 2003 23:23:13 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1Bfl-0006sY-00; Sun, 21 Sep 2003 23:23:13 +0200
Date: Sun, 21 Sep 2003 23:23:13 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: [PATCH] PMAG-AA Hardware cursor support
Message-ID: <20030921212313.GN13578@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3244
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 19031
Lines: 667

Hello Maciej,

the appended patch adds hardware cursor support for the PMAG-AA.


Thiemo


diff -abdpruNPX /bigdisk/src/dontdiff linux-orig/drivers/video/bt431.h linux/drivers/video/bt431.h
--- linux-orig/drivers/video/bt431.h	Tue Sep 16 17:05:14 2003
+++ linux/drivers/video/bt431.h	Sun Sep 21 22:39:12 2003
@@ -73,22 +73,42 @@ static inline u8 bt431_get_value(u16 val
 
 static inline void bt431_select_reg(struct bt431_regs *regs, int ir)
 {
+	/*
+	 * The compiler splits the write in two bytes without these
+	 * helper variables.
+	 */
+	volatile u16 *lo = &(regs->addr_lo);
+	volatile u16 *hi = &(regs->addr_hi);
+
 	mb();
-	regs->addr_lo = bt431_set_value(ir & 0xff);
-	regs->addr_hi = bt431_set_value((ir >> 8) & 0xff);
+	*lo = bt431_set_value(ir & 0xff);
+	wmb();
+	*hi = bt431_set_value((ir >> 8) & 0xff);
 }
 
 /* Autoincrement read/write. */
 static inline u8 bt431_read_reg_inc(struct bt431_regs *regs)
 {
+	/*
+	 * The compiler splits the write in two bytes without the
+	 * helper variable.
+	 */
+	volatile u16 *r = &(regs->addr_reg);
+
 	mb();
-	return bt431_get_value(regs->addr_reg);
+	return bt431_get_value(*r);
 }
 
 static inline void bt431_write_reg_inc(struct bt431_regs *regs, u8 value)
 {
+	/*
+	 * The compiler splits the write in two bytes without the
+	 * helper variable.
+	 */
+	volatile u16 *r = &(regs->addr_reg);
+
 	mb();
-	regs->addr_reg = bt431_set_value(value);
+	*r = bt431_set_value(value);
 }
 
 static inline u8 bt431_read_reg(struct bt431_regs *regs, int ir)
@@ -97,23 +117,35 @@ static inline u8 bt431_read_reg(struct b
 	return bt431_read_reg_inc(regs);
 }
 
-static inline void bt431_write_reg(struct bt431_regs *regs, int ir, u16 value)
+static inline void bt431_write_reg(struct bt431_regs *regs, int ir, u8 value)
 {
 	bt431_select_reg(regs, ir);
 	bt431_write_reg_inc(regs, value);
 }
 
-/* Autoincremented read/write for the cursor map */
+/* Autoincremented read/write for the cursor map. */
 static inline u16 bt431_read_cmap_inc(struct bt431_regs *regs)
 {
+	/*
+	 * The compiler splits the write in two bytes without the
+	 * helper variable.
+	 */
+	volatile u16 *r = &(regs->addr_cmap);
+
 	mb();
-	return regs->addr_cmap;
+	return *r;
 }
 
 static inline void bt431_write_cmap_inc(struct bt431_regs *regs, u16 value)
 {
+	/*
+	 * The compiler splits the write in two bytes without the
+	 * helper variable.
+	 */
+	volatile u16 *r = &(regs->addr_cmap);
+
 	mb();
-	regs->addr_cmap = value;
+	*r = value;
 }
 
 static inline u16 bt431_read_cmap(struct bt431_regs *regs, int cr)
@@ -130,10 +162,9 @@ static inline void bt431_write_cmap(stru
 
 static inline void bt431_enable_cursor(struct bt431_regs *regs)
 {
-/*	bt431_write_reg(regs, BT431_REG_CMD,
+	bt431_write_reg(regs, BT431_REG_CMD,
 			BT431_CMD_CURS_ENABLE | BT431_CMD_OR_CURSORS
 			| BT431_CMD_4_1_MUX | BT431_CMD_THICK_1);
-*/	bt431_write_reg(regs, BT431_REG_CMD, BT431_CMD_CURS_ENABLE);
 }
 
 static inline void bt431_erase_cursor(struct bt431_regs *regs)
@@ -166,64 +197,40 @@ static inline void bt431_position_cursor
 	bt431_write_reg_inc(regs, (y >> 8) & 0x0f); /* BT431_REG_CYHI */
 }
 
-/*u16 _bt431_default_cursor[64 * 8] = {
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0,
-};
-*/
-static inline void bt431_load_cursor_sprite(struct bt431_regs *regs)
+static inline void bt431_set_font(struct bt431_regs *regs, u8 fgc,
+				  u16 width, u16 height)
 {
 	int i;
+	u16 fgp = fgc ? 0xffff : 0x0000;
+	u16 bgp = fgc ? 0x0000 : 0xffff;
 
 	bt431_select_reg(regs, BT431_REG_CRAM_BASE);
-	for (i = 0; i < 64 * 8; i++)
-		bt431_write_cmap_inc(regs, ((i < 16 * 8) && (i % 8)) ? 0xffff : 0);
+	for (i = BT431_REG_CRAM_BASE; i <= BT431_REG_CRAM_END; i++) {
+		u16 value;
+
+		if (height << 6 <= i << 3)
+			value = bgp;
+		else if (width <= i % 8 << 3)
+			value = bgp;
+		else if (((width >> 3) & 0xffff) > i % 8)
+			value = fgp;
+		else
+			value = fgp & ~(bgp << (width % 8 << 1));
+
+		bt431_write_cmap_inc(regs, value);
+	}
 }
 
 static inline void bt431_init_cursor(struct bt431_regs *regs)
 {
-	bt431_write_reg(regs, BT431_REG_CMD,
-			BT431_CMD_CURS_ENABLE | BT431_CMD_OR_CURSORS
-			| BT431_CMD_4_1_MUX | BT431_CMD_THICK_1);
-
-	/* home cursor */
-#if 0
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CXLO */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CXHI */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CYLO */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CYHI */
-#endif
-	bt431_write_reg_inc(regs, 0x80); /* BT431_REG_CXLO */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CXHI */
-	bt431_write_reg_inc(regs, 0x80); /* BT431_REG_CYLO */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CYHI */
-
 	/* no crosshair window */
+	bt431_select_reg(regs, BT431_REG_WXLO);
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WXLO */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WXHI */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WYLO */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WYHI */
-//	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WWLO */
-	bt431_write_reg_inc(regs, 0x01); /* BT431_REG_WWLO */
+	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WWLO */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WWHI */
-//	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WHLO */
-	bt431_write_reg_inc(regs, 0x01); /* BT431_REG_WHLO */
+	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WHLO */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WHHI */
-
-	bt431_load_cursor_sprite(regs);
 }
diff -abdpruNPX /bigdisk/src/dontdiff linux-orig/drivers/video/bt455.h linux/drivers/video/bt455.h
--- linux-orig/drivers/video/bt455.h	Tue Sep 16 17:05:14 2003
+++ linux/drivers/video/bt455.h	Sun Sep 21 22:39:12 2003
@@ -37,8 +37,7 @@ static inline void bt455_read_cmap_entry
 					 u8* red, u8* green, u8* blue)
 {
 	bt455_select_reg(regs, cr);
-	
-	mb();
+	rmb();
 	*red = regs->addr_cmap_data & 0x0f;
 	rmb();
 	*green = regs->addr_cmap_data & 0x0f;
@@ -50,7 +49,6 @@ static inline void bt455_write_cmap_entr
 					  u8 red, u8 green, u8 blue)
 {
 	bt455_select_reg(regs, cr);
-
 	wmb();
 	regs->addr_cmap_data = red & 0x0f;
 	wmb();
@@ -59,10 +57,11 @@ static inline void bt455_write_cmap_entr
 	regs->addr_cmap_data = blue & 0x0f;
 }
 
-static inline void bt455_write_ovly_entry(struct bt455_regs *regs,
+static inline void bt455_write_ovly_entry(struct bt455_regs *regs, int cr,
 					  u8 red, u8 green, u8 blue)
 {
-	mb();
+	bt455_select_reg(regs, cr);
+	wmb();
 	regs->addr_ovly = red & 0x0f;
 	wmb();
 	regs->addr_ovly = green & 0x0f;
@@ -82,10 +81,15 @@ static inline void bt455_set_cursor(stru
 
 static inline void bt455_erase_cursor(struct bt455_regs *regs)
 {
-//	bt455_write_cmap_entry(regs, 8, 0x00, 0x00, 0x00);
-//	bt455_write_cmap_entry(regs, 9, 0x00, 0x00, 0x00);
-	bt455_write_cmap_entry(regs, 8, 0x03, 0x03, 0x03);
-	bt455_write_cmap_entry(regs, 9, 0x07, 0x07, 0x07);
+	/* bt455_write_cmap_entry(regs, 8, 0x00, 0x00, 0x00); */
+	/* bt455_write_cmap_entry(regs, 9, 0x00, 0x00, 0x00); */
+	bt455_write_ovly_entry(regs, 8, 0x03, 0x03, 0x03);
+	bt455_write_ovly_entry(regs, 9, 0x07, 0x07, 0x07);
 
-	bt455_write_ovly_entry(regs, 0x09, 0x09, 0x09);
+	wmb();
+	regs->addr_ovly = 0x09;
+	wmb();
+	regs->addr_ovly = 0x09;
+	wmb();
+	regs->addr_ovly = 0x09;
 }
diff -abdpruNPX /bigdisk/src/dontdiff linux-orig/drivers/video/pmag-aa-fb.c linux/drivers/video/pmag-aa-fb.c
--- linux-orig/drivers/video/pmag-aa-fb.c	Tue Sep 16 17:05:14 2003
+++ linux/drivers/video/pmag-aa-fb.c	Sun Sep 21 22:39:12 2003
@@ -13,10 +13,14 @@
  *	Public License.  See the file COPYING in the main directory of this
  *	archive for more details.
  *
- *	Version 0.01 2002/09/28 first try to get a PMAG-AA running
+ *	2002-09-28  Karsten Merker <merker@linuxtag.org>
+ *		Version 0.01: First try to get a PMAG-AA running.
  * 
- *	2003/02/24  Thiemo Seufer  <seufer@csv.ica.uni-stuttgart.de>
- *		Code cleanup.
+ *	2003-02-24  Thiemo Seufer  <seufer@csv.ica.uni-stuttgart.de>
+ *		Version 0.02: Major code cleanup.
+ *
+ *	2003-09-21  Thiemo Seufer  <seufer@csv.ica.uni-stuttgart.de>
+ *		Hardware cursor support.
  */
 #include <linux/module.h>
 #include <linux/kernel.h>
@@ -30,22 +34,26 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/fb.h>
+#include <linux/console.h>
 
 #include <asm/bootinfo.h>
 #include <asm/dec/machtype.h>
 #include <asm/dec/tc.h>
 
 #include <video/fbcon.h>
-#include <video/fbcon-mfb.h>
 #include <video/fbcon-cfb8.h>
 
 #include "bt455.h"
 #include "bt431.h"
 
 /* Version information */
-#define DRIVER_VERSION "v0.02"
+#define DRIVER_VERSION "0.02"
 #define DRIVER_AUTHOR "Karsten Merker <merker@linuxtag.org>"
-#define DRIVER_DESC "PMAG-AA Framebuffer Driver"
+#define DRIVER_DESCRIPTION "PMAG-AA Framebuffer Driver"
+
+/* Prototypes */
+static int aafb_set_var(struct fb_var_screeninfo *var, int con,
+			struct fb_info *info);
 
 /*
  * Bt455 RAM DAC register base offset (rel. to TC slot base address).
@@ -63,9 +71,23 @@
  */
 #define PMAG_AA_ONBOARD_FBMEM_OFFSET	0x200000
 
+struct aafb_cursor {
+	struct timer_list timer;
+	int enable;
+	int on;
+	int vbl_cnt;
+	int blink_rate;
+	u16 x, y, width, height;
+};
+
+#define CURSOR_TIMER_FREQ	(HZ / 50)
+#define CURSOR_BLINK_RATE	(20)
+#define CURSOR_DRAW_DELAY	(2)
+
 struct aafb_info {
 	struct fb_info info;
 	struct display disp;
+	struct aafb_cursor cursor;
 	struct bt455_regs *bt455;
 	struct bt431_regs *bt431;
 	unsigned long fb_start;
@@ -81,57 +103,174 @@ static struct aafb_info my_fb_info[3];
 static struct aafb_par {
 } current_par;
 
-static int currcon = 0;
+static int currcon = -1;
 
-static void aafb_get_par(struct aafb_par *par)
+static void aafb_set_cursor(struct aafb_info *info, int on)
 {
-	*par = current_par;
+	struct aafb_cursor *c = &info->cursor;
+
+	if (on) {
+		bt431_position_cursor(info->bt431, c->x, c->y);
+		bt431_enable_cursor(info->bt431);
+	} else
+		bt431_erase_cursor(info->bt431);
 }
 
-static void aafb_encode_fix(struct fb_fix_screeninfo *fix,
-			    struct aafb_par *par, struct aafb_info *info)
+static void aafbcon_cursor(struct display *disp, int mode, int x, int y)
 {
-	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
-	strcpy(fix->id, "PMAG-AA");
+	struct aafb_info *info = (struct aafb_info *)disp->fb_info;
+	struct aafb_cursor *c = &info->cursor;
 
-	fix->smem_start = info->fb_start;
-	fix->smem_len = info->fb_size;
-	fix->type = FB_TYPE_PACKED_PIXELS;
-	fix->visual = FB_VISUAL_MONO10;
-	fix->line_length = info->fb_line_length;
-	fix->accel = FB_ACCEL_NONE;
+	x *= fontwidth(disp);
+	y *= fontheight(disp);
+
+	if (c->x == x && c->y == y && (mode == CM_ERASE) == !c->enable)
+		return;
+
+	c->enable = 0;
+	if (c->on)
+		aafb_set_cursor(info, 0);
+	c->x = x - disp->var.xoffset;
+	c->y = y - disp->var.yoffset;
+
+	switch (mode) {
+		case CM_ERASE:
+			c->on = 0;
+			break;
+		case CM_DRAW:
+		case CM_MOVE:
+			if (c->on)
+				aafb_set_cursor(info, c->on);
+			else
+				c->vbl_cnt = CURSOR_DRAW_DELAY;
+			c->enable = 1;
+			break;
+	}
+}
+
+static int aafbcon_set_font(struct display *disp, int width, int height)
+{
+	struct aafb_info *info = (struct aafb_info *)disp->fb_info;
+	struct aafb_cursor *c = &info->cursor;
+	u8 fgc = ~attr_bgcol_ec(disp, disp->conp);
+
+	if (width > 64 || height > 64 || width < 0 || height < 0)
+		return -EINVAL;
+
+	c->height = height;
+	c->width = width;
+
+	bt431_set_font(info->bt431, fgc, width, height);
+
+	return 1;
+}
+
+static void aafb_cursor_timer_handler(unsigned long data)
+{
+	struct aafb_info *info = (struct aafb_info *)data;
+	struct aafb_cursor *c = &info->cursor;
+
+	if (!c->enable)
+		goto out;
+
+	if (c->vbl_cnt && --c->vbl_cnt == 0) {
+		c->on ^= 1;
+		aafb_set_cursor(info, c->on);
+		c->vbl_cnt = c->blink_rate;
+	}
+
+out:
+	c->timer.expires = jiffies + CURSOR_TIMER_FREQ;
+	add_timer(&c->timer);
+}
+
+static void __init aafb_cursor_init(struct aafb_info *info)
+{
+	struct aafb_cursor *c = &info->cursor;
+
+	c->enable = 1;
+	c->on = 1;
+	c->x = c->y = 0;
+	c->width = c->height = 0;
+	c->vbl_cnt = CURSOR_DRAW_DELAY;
+	c->blink_rate = CURSOR_BLINK_RATE;
+
+	init_timer(&c->timer);
+	c->timer.data = (unsigned long)info;
+	c->timer.function = aafb_cursor_timer_handler;
+	mod_timer(&c->timer, jiffies + CURSOR_TIMER_FREQ);
+}
+
+static void __exit aafb_cursor_exit(struct aafb_info *info)
+{
+	struct aafb_cursor *c = &info->cursor;
+
+	del_timer_sync(&c->timer);
+}
+
+static struct display_switch aafb_switch8 = {
+	setup:		fbcon_cfb8_setup,
+	bmove:		fbcon_cfb8_bmove,
+	clear:		fbcon_cfb8_clear,
+	putc:		fbcon_cfb8_putc,
+	putcs:		fbcon_cfb8_putcs,
+	revc:		fbcon_cfb8_revc,
+	cursor:		aafbcon_cursor,
+	set_font:	aafbcon_set_font,
+	clear_margins:	fbcon_cfb8_clear_margins,
+	fontwidthmask:	FONTWIDTH(4)|FONTWIDTH(8)|FONTWIDTH(12)|FONTWIDTH(16)
+};
+
+static void aafb_get_par(struct aafb_par *par)
+{
+	*par = current_par;
 }
 
 static int aafb_get_fix(struct fb_fix_screeninfo *fix, int con,
 			struct fb_info *info)
 {
-	struct aafb_par par;
+	struct aafb_info *ip = (struct aafb_info *)info;
 
-	aafb_get_par(&par);
-	aafb_encode_fix(fix, &par, (struct aafb_info *) info);
+	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
+	strcpy(fix->id, "PMAG-AA");
+	fix->smem_start = ip->fb_start;
+	fix->smem_len = ip->fb_size;
+	fix->type = FB_TYPE_PACKED_PIXELS;
+	fix->ypanstep = 1;
+	fix->ywrapstep = 1;
+	fix->visual = FB_VISUAL_MONO10;
+	fix->line_length = 1280;
+	fix->accel = FB_ACCEL_NONE;
 
 	return 0;
 }
 
-static void aafb_set_disp(int con, struct fb_info *info)
+static void aafb_set_disp(struct display *disp, int con,
+			  struct aafb_info *info)
 {
 	struct fb_fix_screeninfo fix;
-	struct display *disp = (con < 0) ? info->disp : (fb_display + con);
 
-	aafb_get_fix(&fix, con, info);
+	disp->fb_info = &info->info;
+	aafb_set_var(&disp->var, con, &info->info);
+	if (disp->conp && disp->conp->vc_sw && disp->conp->vc_sw->con_cursor)
+		disp->conp->vc_sw->con_cursor(disp->conp, CM_ERASE);
+	disp->dispsw = &aafb_switch8;
+	disp->dispsw_data = 0;
 
-	disp->screen_base = (char *) fix.smem_start;
+	aafb_get_fix(&fix, con, &info->info);
+	disp->screen_base = (u8 *) fix.smem_start;
 	disp->visual = fix.visual;
 	disp->type = fix.type;
 	disp->type_aux = fix.type_aux;
 	disp->ypanstep = fix.ypanstep;
 	disp->ywrapstep = fix.ywrapstep;
-//	disp->line_length = fix.line_length;
-	disp->next_line = fix.line_length;
+	disp->line_length = fix.line_length;
+	disp->next_line = 2048;
 	disp->can_soft_blank = 1;
 	disp->inverse = 0;
-//	disp->scrollmode = SCROLL_YREDRAW;
-	disp->dispsw = &fbcon_cfb8;
+	disp->scrollmode = SCROLL_YREDRAW;
+
+	aafbcon_set_font(disp, fontwidth(disp), fontheight(disp));
 }
 
 static int aafb_get_cmap(struct fb_cmap *cmap, int kspc, int con,
@@ -147,14 +286,38 @@ static int aafb_get_cmap(struct fb_cmap 
 static int aafb_set_cmap(struct fb_cmap *cmap, int kspc, int con,
 			 struct fb_info *info)
 {
+	u16 color[2] = {0x0000, 0x000f};
+
+	if (cmap->start == 0
+	    && cmap->len == 2
+	    && memcmp(cmap->red, color, sizeof(color)) == 0
+	    && memcmp(cmap->green, color, sizeof(color)) == 0
+	    && memcmp(cmap->blue, color, sizeof(color)) == 0
+	    && cmap->transp == NULL)
+		return 0;
+	else
 	return -EINVAL;
 }
 
+static int aafb_ioctl(struct inode *inode, struct file *file, u32 cmd,
+		      unsigned long arg, int con, struct fb_info *info)
+{
+	/* TODO: Not yet implemented */
+	return -ENOIOCTLCMD;
+}
+
 static int aafb_switch(int con, struct fb_info *info)
 {
+	struct aafb_info *ip = (struct aafb_info *)info;
+	struct display *old = (currcon < 0) ? &ip->disp : (fb_display + currcon);
+	struct display *new = (con < 0) ? &ip->disp : (fb_display + con);
+
+	if (old->conp && old->conp->vc_sw && old->conp->vc_sw->con_cursor)
+		old->conp->vc_sw->con_cursor(old->conp, CM_ERASE);
+
 	/* Set the current console. */
 	currcon = con;
-	aafb_set_disp(con, info);
+	aafb_set_disp(new, con, ip);
 
 	return 0;
 }
@@ -218,6 +381,12 @@ static int aafb_set_var(struct fb_var_sc
 
 static int aafb_update_var(int con, struct fb_info *info)
 {
+	struct aafb_info *ip = (struct aafb_info *)info;
+	struct display *disp = (con < 0) ? &ip->disp : (fb_display + con);
+
+	if (con == currcon)
+		aafbcon_cursor(disp, CM_ERASE, ip->cursor.x, ip->cursor.y);
+
 	return 0;
 }
 
@@ -229,15 +398,17 @@ static void aafb_blank(int blank, struct
 	u8 val = blank ? 0x00 : 0x0f;
 
 	bt455_write_cmap_entry(ip->bt455, 1, val, val, val);
+	aafbcon_cursor(&ip->disp, CM_ERASE, ip->cursor.x, ip->cursor.y);
 }
 
 static struct fb_ops aafb_ops = {
-	owner:THIS_MODULE,
-	fb_get_fix:aafb_get_fix,
-	fb_get_var:aafb_get_var,
-	fb_set_var:aafb_set_var,
-	fb_get_cmap:aafb_get_cmap,
-	fb_set_cmap:aafb_set_cmap
+	owner:		THIS_MODULE,
+	fb_get_fix:	aafb_get_fix,
+	fb_get_var:	aafb_get_var,
+	fb_set_var:	aafb_set_var,
+	fb_get_cmap:	aafb_get_cmap,
+	fb_set_cmap:	aafb_set_cmap,
+	fb_ioctl:	aafb_ioctl
 };
 
 static int __init init_one(int slot)
@@ -258,20 +429,6 @@ static int __init init_one(int slot)
 	ip->fb_line_length = 2048;
 
 	/*
-	 * Configure the RAM DACs.
-	 */
-// TODO
-//	bt455_erase_cursor(ip->bt455);
-//	bt455_set_cursor(ip->bt455);
-//	bt431_erase_cursor(ip->bt431);
-//	bt431_init_cursor(ip->bt431);
-//	bt431_position_cursor(ip->bt431, 16, 16);
-
-	/* Init colormap. */
-	bt455_write_cmap_entry(ip->bt455, 0, 0x00, 0x00, 0x00);
-	bt455_write_cmap_entry(ip->bt455, 1, 0x0f, 0x0f, 0x0f);
-
-	/*
 	 * Let there be consoles..
 	 */
 	strcpy(ip->info.modename, "PMAG-AA");
@@ -284,8 +441,20 @@ static int __init init_one(int slot)
 	ip->info.updatevar = &aafb_update_var;
 	ip->info.blank = &aafb_blank;
 
-	aafb_set_disp(-1, &ip->info);
-	aafb_set_var(&ip->disp.var, -1, &ip->info);
+	aafb_set_disp(&ip->disp, currcon, ip);
+
+	/*
+	 * Configure the RAM DACs.
+	 */
+	bt455_erase_cursor(ip->bt455);
+
+	/* Init colormap. */
+	bt455_write_cmap_entry(ip->bt455, 0, 0x00, 0x00, 0x00);
+	bt455_write_cmap_entry(ip->bt455, 1, 0x0f, 0x0f, 0x0f);
+
+	/* Init hardware cursor. */
+	bt431_init_cursor(ip->bt431);
+	aafb_cursor_init(ip);
 
 	/* Clear the screen. */
 	memset ((void *)ip->fb_start, 0, ip->fb_size);
@@ -293,7 +462,7 @@ static int __init init_one(int slot)
 	if (register_framebuffer(&ip->info) < 0)
 		return -EINVAL;
 
-	printk(KERN_INFO "fb%d: %s frame buffer device in TC slot %d\n",
+	printk(KERN_INFO "fb%d: %s frame buffer in TC slot %d\n",
 	       GET_FB_IDX(ip->info.node), ip->info.modename, slot);
 
 	return 0;
@@ -336,4 +505,10 @@ static void __exit pmagaafb_exit(void)
 	}
 }
 
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
 MODULE_LICENSE("GPL");
+#ifdef MODULE
+module_init(pmagaafb_init);
+module_exit(pmagaafb_exit);
+#endif

From ica2_ts@csv.ica.uni-stuttgart.de Sun Sep 21 22:31:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 21 Sep 2003 22:31:07 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:50749
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225508AbTIUVbF>; Sun, 21 Sep 2003 22:31:05 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1BnM-0007Y7-00; Sun, 21 Sep 2003 23:31:04 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1BnM-0006t0-00; Sun, 21 Sep 2003 23:31:04 +0200
Date: Sun, 21 Sep 2003 23:31:04 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: [PATCH] Fix character loss in drivers/tc/zs.c
Message-ID: <20030921213104.GO13578@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3245
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 497
Lines: 20

Hello Maciej,

this patch reduces the zs driver's character lossage.


Thiemo


diff -abdpruNPX /bigdisk/src/dontdiff linux-orig/drivers/tc/zs.c linux/drivers/tc/zs.c
--- linux-orig/drivers/tc/zs.c	Tue Aug 12 04:11:58 2003
+++ linux/drivers/tc/zs.c	Sun Sep 21 22:28:40 2003
@@ -456,7 +456,7 @@ static _INLINE_ void receive_chars(struc
 
 		if (info->hook && info->hook->rx_char) {
 			(*info->hook->rx_char)(ch, flag);
-			return;
+			break;
   		}
 
 		if (tty->flip.count >= TTY_FLIPBUF_SIZE) {

From ica2_ts@csv.ica.uni-stuttgart.de Sun Sep 21 22:35:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 21 Sep 2003 22:35:51 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:53309
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225508AbTIUVft>; Sun, 21 Sep 2003 22:35:49 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1Brv-0007aK-00; Sun, 21 Sep 2003 23:35:47 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1Brv-0006tH-00; Sun, 21 Sep 2003 23:35:47 +0200
Date: Sun, 21 Sep 2003 23:35:47 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: [PATCH] Fix unused variable warning in drivers/char/dz.c
Message-ID: <20030921213547.GP13578@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3246
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 559
Lines: 25

Hello Maciej,

this fixes an unused variable warning.


Thiemo


diff -abdpruNPX /bigdisk/src/dontdiff linux-orig/drivers/char/dz.c linux/drivers/char/dz.c
--- linux-orig/drivers/char/dz.c	Wed Apr 23 19:17:01 2003
+++ linux/drivers/char/dz.c	Sun Sep 21 22:28:40 2003
@@ -1299,9 +1299,12 @@ static void show_serial_version(void)
 
 int __init dz_init(void)
 {
-	int i, tmp;
+	int i;
 	long flags;
 	struct dz_serial *info;
+#ifndef CONFIG_SERIAL_DEC_CONSOLE
+	int tmp;
+#endif
 
 	/* Setup base handler, and timer table. */
 	init_bh(SERIAL_BH, do_serial_bh);

From chris@mips.com Mon Sep 22 10:25:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 10:25:23 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:52743 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225401AbTIVJZV>;
	Mon, 22 Sep 2003 10:25:21 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1A1MvT-0008RN-00; Mon, 22 Sep 2003 10:24:11 +0100
Received: from holborn.algor.co.uk ([192.168.192.237] helo=mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1A1Mvk-0000Yz-00; Mon, 22 Sep 2003 10:24:28 +0100
Message-ID: <3F6EBFCC.6090203@mips.com>
Date: Mon, 22 Sep 2003 10:24:28 +0100
From: Chris Dearman <chris@mips.com>
Organization: MIPS Technologies (UK) Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en
MIME-Version: 1.0
To: Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>
CC: linux-mips@linux-mips.org
Subject: Re: list archive
References: <20030919131724.GA26606@icm.edu.pl> <Pine.GSO.3.96.1030919153437.9134E-100000@delta.ds2.pg.gda.pl> <20030919140142.GA28087@icm.edu.pl>
In-Reply-To: <20030919140142.GA28087@icm.edu.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.5, required 4, AWL,
	BAYES_10, EMAIL_ATTRIBUTION, REFERENCES, USER_AGENT_MOZILLA_UA)
Return-Path: <chris@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3247
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chris@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 540
Lines: 15

Dominik 'Rathann' Mierzejewski wrote:
> Yes, I see it now, thanks. But I was counting on an online and searchable
> archive.
> 
   There's the "Mailing List Archives" 
http://marc.theaimsgroup.com/?l=linux-mips but it is missing Aug02-June03.
   I think Ralf has been working on a web interface to the mail 
archives, but I'm not sure if it's ready for the big time yet. Ralf...?

	Chris

-- 
Chris Dearman          The Fruit Farm, Ely Road    voice +44 1223 706206
MIPS Technologies (UK) Chittering, Cambs, CB5 9PH  fax   +44 1223 706250


From macro@ds2.pg.gda.pl Mon Sep 22 11:32:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 11:32:57 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:34432 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225420AbTIVKcp>; Mon, 22 Sep 2003 11:32:45 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA18890;
	Mon, 22 Sep 2003 12:32:17 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 22 Sep 2003 12:32:17 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Chris Dearman <chris@mips.com>
cc: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>,
	linux-mips@linux-mips.org
Subject: Re: list archive
In-Reply-To: <3F6EBFCC.6090203@mips.com>
Message-ID: <Pine.GSO.3.96.1030922122541.17538C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3248
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 454
Lines: 13

On Mon, 22 Sep 2003, Chris Dearman wrote:

>    There's the "Mailing List Archives" 
> http://marc.theaimsgroup.com/?l=linux-mips but it is missing Aug02-June03.

 I'm pretty sure up till July 2003 it used to be an archive for the old
list at fnet.fr. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From ralf@linux-mips.org Mon Sep 22 16:28:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 16:28:44 +0100 (BST)
Received: from ftp.linux-mips.org ([IPv6:::ffff:62.254.210.162]:1951 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225512AbTIVP2m>; Mon, 22 Sep 2003 16:28:42 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8MFSZXP007276
	for <linux-mips@linux-mips.org>; Mon, 22 Sep 2003 08:28:35 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8LG0XWB032559;
	Sun, 21 Sep 2003 09:00:33 -0700
Date: Sun, 21 Sep 2003 09:00:33 -0700
From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Impossible fixup in do_ade
Message-ID: <20030921160033.GA31814@linux-mips.org>
References: <20030920152036.GA12905@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030920152036.GA12905@nevyn.them.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3250
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1101
Lines: 22

On Sat, Sep 20, 2003 at 11:20:36AM -0400, Daniel Jacobowitz wrote:

> Here's a snippet from emulate_load_store_insn.  See the way the sdl and sdr
> are wrapped in fixups?  Well, the fixups can't trigger: we get to
> emulate_load_store_insn a second time, and we hit the fact that sdl_op has a
> "goto sigbus" before we hit the fixup_exception call.
> 
> It doesn't much matter, the bug I'm working on is whatever caused the first
> call.  But we get a SIGBUS when arguably we ought to get a SIGSEGV.

The fixup can be triggered - think of an missaligned load or store
inside the kernel itself.  If there's no fixup we'll simply assume the
instruction was in userspace and send a signal which is true unless there's
a kernel bug.

In case we deliver a signal at fault: I think it's arguable what signal is
the most appropriate one but for simplicity I decieded to consider the
address error exception as the cause so SIGBUS is the right signal.  We
simply don't gather sufficient information to deciede what the right
signal to send is and it's a very rare case anyway so nobody noticed yet :)

  Ralf

From ralf@linux-mips.org Mon Sep 22 16:29:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 16:29:07 +0100 (BST)
Received: from ftp.linux-mips.org ([IPv6:::ffff:62.254.210.162]:2719 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225513AbTIVP2m>; Mon, 22 Sep 2003 16:28:42 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8MFSZXR007276
	for <linux-mips@linux-mips.org>; Mon, 22 Sep 2003 08:28:35 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8L9LmIS001730;
	Sun, 21 Sep 2003 02:21:48 -0700
Date: Sun, 21 Sep 2003 02:21:48 -0700
From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: linux-mips@linux-mips.org
Subject: Re: ddb5477 fixes for 2.6
Message-ID: <20030921092148.GD1578@linux-mips.org>
References: <20030918163344.GA22013@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030918163344.GA22013@nevyn.them.org>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3251
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1456
Lines: 34

On Thu, Sep 18, 2003 at 12:33:44PM -0400, Daniel Jacobowitz wrote:

> Here's just enough to make the ddb5477 compile and boot.  The defconfig has
> lost the onboard network card, and you also need to turn on CONFIG_EMBEDDED
> to turn off CONFIG_VT.  Otherwise, conswitchp is uninitialized, causing a
> crash.  If I initialize it to &dummy_con, serial consoles stop working
> (???).

I'm not exactly happy about the way various unrelated options are lumped
together behind CONFIG_EMBEDDED; it seems worse than the problem it's
meant to solve ...

> Userspace doesn't work - lots of scripts segfault, portmap times out, there
> are a number of other glitches.  init=/bin/bash hangs.  But at least it's
> progress.
> 
> I update CFLAGS for gcc 3.3/binutils 2.14.  I think asking people to use
> vaguely modern tools for 2.6 is reasonable.  And the old flags don't work
> any more.  This should work with 3.2 too.

As long as current gcc stays as slow as it is I'm going to stick to
something old.  And I'm not alone.

> The PCI and ac97 changes are pretty mindless merge work.
> 
> Ralf, this re-adds CONFIG_PCI_AUTO.  Do you know where it went? :)  Probably
> a lot of other boards are sad about its disappearance also.

CONFIG_PCI_AUTO went the way to /dev/zero; it not only made the PCI
maintainers make funny sounds it simply seemed superfluous - the PCI
code is supposed to be able to fully configure a PCI bus itself if only
it's used properly.

  Ralf

From macro@ds2.pg.gda.pl Mon Sep 22 18:38:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 18:38:11 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:24468 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225518AbTIVRiJ>; Mon, 22 Sep 2003 18:38:09 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA28470;
	Mon, 22 Sep 2003 19:38:05 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 22 Sep 2003 19:38:04 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix character loss in drivers/tc/zs.c
In-Reply-To: <20030921213104.GO13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030922193409.25762B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3252
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 516
Lines: 15

On Sun, 21 Sep 2003, Thiemo Seufer wrote:

> this patch reduces the zs driver's character lossage.

 Can you please elaborate?  tty is expected to be NULL if info->hook is
not, so the code after the change should not differ effectively -- only a
useless check is added at the end.  Am I missing anything?

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From macro@ds2.pg.gda.pl Mon Sep 22 18:53:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 18:53:53 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:62868 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225518AbTIVRxu>; Mon, 22 Sep 2003 18:53:50 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA28761;
	Mon, 22 Sep 2003 19:53:46 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 22 Sep 2003 19:53:46 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] PMAG-AA Hardware cursor support
In-Reply-To: <20030921212313.GN13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030922194304.25762C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3253
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 855
Lines: 28

On Sun, 21 Sep 2003, Thiemo Seufer wrote:

> @@ -37,8 +37,7 @@ static inline void bt455_read_cmap_entry
>  					 u8* red, u8* green, u8* blue)
>  {
>  	bt455_select_reg(regs, cr);
> -	
> -	mb();
> +	rmb();
>  	*red = regs->addr_cmap_data & 0x0f;
>  	rmb();
>  	*green = regs->addr_cmap_data & 0x0f;

 I do think it has to be an mb() as the first access is a write and the
second one is a read. 

 You may also consider using ISO C initializers for struct members -- I
can do the conversion myself, but since you are actively working on the
code right now, I guess it might give you an unnecessary burden of chasing
the changing master sources.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From macro@ds2.pg.gda.pl Mon Sep 22 19:00:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 19:00:15 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:11157 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225526AbTIVSAN>; Mon, 22 Sep 2003 19:00:13 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA28873;
	Mon, 22 Sep 2003 20:00:09 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 22 Sep 2003 20:00:09 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix unused variable warning in drivers/char/dz.c
In-Reply-To: <20030921213547.GP13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030922195924.25762D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3254
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 386
Lines: 12

On Sun, 21 Sep 2003, Thiemo Seufer wrote:

> this fixes an unused variable warning.

 Thanks for the report.  Since the variable isn't really needed at all,
I've removed it altogether.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From Steve.Finney@SpirentCom.COM Mon Sep 22 21:19:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 21:19:58 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:52435 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225530AbTIVUTz> convert rfc822-to-8bit; Mon, 22 Sep 2003 21:19:55 +0100
content-class: urn:content-classes:message
Subject: User-mode drivers and TLB
Date: Mon, 22 Sep 2003 10:19:47 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB750@iris.adtech-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: User-mode drivers and TLB
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcOBRuDKdEBlxua2SZqQUES1OY/Qig==
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3255
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 1185
Lines: 25

I am working on an app where I want to give one or more 
user processes access to a largish range of physical 
address space (specifically, this is a Broadcom 1125 
running a 32 bit kernel, and for now the region is 
accessible via KSEG0/1 (physical address < 512 MB)). 
mmap() on /dev/mem does this just fine, and setting 
(or not setting) O_SYNC on open seems to control caching. 
But I just realized a disadvantage to doing this in user 
space: the user process accesses have to be mapped (since a
user process can't, I believe, use KSEG0 or KSEG1 addresses),
so you have to go through the (64 entry) TLB, and if 
you had signficant non-locality of reference, you'd
possibly risk thrashing the TLB (which doesn't happen
in kernel space, since the region can be directly 
accessed). One approach would be to wire a TLB entry 
to handle the large region so you never get a TLB miss, 
but this might not work well for multi-process access,
since (normally) you can't guarantee that the multiple
processes doing mmap's will get the same virtual address.

Is this  correct? Is there some other clever approach I
haven't thought of? Should I even be worrying about TLB usage?

Thanks,
sf

From aoliva@redhat.com Mon Sep 22 22:27:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 22:27:03 +0100 (BST)
Received: from pix-525-pool.redhat.com ([IPv6:::ffff:66.187.233.200]:8693 "EHLO
	lacrosse.corp.redhat.com") by linux-mips.org with ESMTP
	id <S8225526AbTIVV1A>; Mon, 22 Sep 2003 22:27:00 +0100
Received: from free.redhat.lsd.ic.unicamp.br (aoliva.cipe.redhat.com [10.0.1.10])
	by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8MLQok00846;
	Mon, 22 Sep 2003 17:26:50 -0400
Received: from free.redhat.lsd.ic.unicamp.br (free.redhat.lsd.ic.unicamp.br [127.0.0.1])
	by free.redhat.lsd.ic.unicamp.br (8.12.10/8.12.10) with ESMTP id h8MLQmkB030745;
	Mon, 22 Sep 2003 18:26:48 -0300
Received: (from aoliva@localhost)
	by free.redhat.lsd.ic.unicamp.br (8.12.10/8.12.10/Submit) id h8MLQeeU030741;
	Mon, 22 Sep 2003 18:26:40 -0300
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Eric Christopher <echristo@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
	<1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
	<20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
From: Alexandre Oliva <aoliva@redhat.com>
Organization: GCC Team, Red Hat
Date: 22 Sep 2003 18:26:40 -0300
In-Reply-To: <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <aoliva@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3256
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aoliva@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 495
Lines: 11

On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:

> A third answer is to add a -msign-extend-addresses switch in the assembler.

In what sense is this different from -Wa,-mabi=n32 ?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

From drow@crack.them.org Mon Sep 22 22:31:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 22:31:48 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:19665 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225526AbTIVVbp>;
	Mon, 22 Sep 2003 22:31:45 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A1YHN-0002gr-NH; Mon, 22 Sep 2003 17:31:33 -0400
Date: Mon, 22 Sep 2003 17:31:33 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Eric Christopher <echristo@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030922213133.GA10288@nevyn.them.org>
Mail-Followup-To: Alexandre Oliva <aoliva@redhat.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Eric Christopher <echristo@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl> <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com> <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de> <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3257
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 516
Lines: 13

On Mon, Sep 22, 2003 at 06:26:40PM -0300, Alexandre Oliva wrote:
> On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> 
> > A third answer is to add a -msign-extend-addresses switch in the assembler.
> 
> In what sense is this different from -Wa,-mabi=n32 ?

GDB gets the idea that you've got n64 code instead of o32 or n32 or
whatever code.  It transfers 64-bit data to the remote stub, et cetera.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From bapper@piratehaven.org Mon Sep 22 23:55:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 22 Sep 2003 23:55:50 +0100 (BST)
Received: from www.piratehaven.org ([IPv6:::ffff:204.253.162.40]:9395 "EHLO
	skull.piratehaven.org") by linux-mips.org with ESMTP
	id <S8225545AbTIVWzs>; Mon, 22 Sep 2003 23:55:48 +0100
Received: by skull.piratehaven.org (Postfix, from userid 512)
	id DED4D101DF; Mon, 22 Sep 2003 22:55:42 +0000 (US/East)
Date: Mon, 22 Sep 2003 15:55:41 -0700
From: Brian Pomerantz <bapper@piratehaven.org>
To: linux-mips@linux-mips.org
Subject: virt_to_phys bug?
Message-ID: <20030922225541.GA10469@skull.piratehaven.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-homepage: http://www.piratehaven.org/~bapper/
Return-Path: <bapper@piratehaven.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3258
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bapper@piratehaven.org
Precedence: bulk
X-list: linux-mips
Content-Length: 957
Lines: 20

Maybe the wrong function is being used here, I'm not sure.  I ran into
a problem with using virt_to_phys.  The acacia driver for the IDT
rc32438 chip uses virt_to_phys to convert from a KSEG1 address to a
physical address.  Somehow this works on their 2.4.18 kernel but does
not in the 2.4.22 tree.  After changing virt_to_phys to this:

	return (unsigned long)address - KSEGX(address);

everything worked just fine.  I guess what I'm wondering is, is this
the correct way to get a physical address for use with DMA?  The note
in io.h above the function says no but fails to tell me what should be
used.  My guess is virt_to_bus is correct but they are identical
functions.  Since I didn't write this driver, I can only assume that
address for the rung descriptors are accessed via KSEG1 so that they
are uncached and don't require flushing after each access.  I had a
lot of dropped packets when I failed to access the ring descriptors
via KSEG1.


BAPper

From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 23 00:40:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 00:40:11 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:14854
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225547AbTIVXkJ>; Tue, 23 Sep 2003 00:40:09 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1aHY-0002iy-00; Tue, 23 Sep 2003 01:39:52 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1aHY-0002Ir-00; Tue, 23 Sep 2003 01:39:52 +0200
Date: Tue, 23 Sep 2003 01:39:52 +0200
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Eric Christopher <echristo@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl> <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com> <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de> <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3259
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 273
Lines: 11

Alexandre Oliva wrote:
> On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> 
> > A third answer is to add a -msign-extend-addresses switch in the assembler.
> 
> In what sense is this different from -Wa,-mabi=n32 ?

ELF64 instead of ELF32.


Thiemo

From echristo@redhat.com Tue Sep 23 02:22:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 02:22:18 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:15891 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225551AbTIWBWQ>;
	Tue, 23 Sep 2003 02:22:16 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h8N151O12181;
	Mon, 22 Sep 2003 21:05:01 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h8N1LpD25001;
	Mon, 22 Sep 2003 21:21:51 -0400
Received: from ghostwheel.sfbay.redhat.com (vpn26-5.sfbay.redhat.com [172.16.26.5])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h8N1Lnw06879;
	Mon, 22 Sep 2003 18:21:49 -0700
Subject: Re: recent binutils and mips64-linux
From: Eric Christopher <echristo@redhat.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
In-Reply-To: <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
	 <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
	 <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
	 <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
	 <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain
Message-Id: <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Mon, 22 Sep 2003 18:21:46 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3260
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 392
Lines: 17

On Mon, 2003-09-22 at 16:39, Thiemo Seufer wrote:
> Alexandre Oliva wrote:
> > On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> > 
> > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > 
> > In what sense is this different from -Wa,-mabi=n32 ?
> 
> ELF64 instead of ELF32.

objcopy?

-eric

-- 
Eric Christopher <echristo@redhat.com>


From baitisj@evolution.com Tue Sep 23 02:46:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 02:46:37 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:53650 "EHLO
	powerpuff.pas.lab") by linux-mips.org with ESMTP
	id <S8225550AbTIWBqf>; Tue, 23 Sep 2003 02:46:35 +0100
Received: from powerpuff.pas.lab (localhost.localdomain [127.0.0.1])
	by powerpuff.pas.lab (8.12.8/8.12.8) with ESMTP id h8N1kWB4009945
	for <linux-mips@linux-mips.org>; Mon, 22 Sep 2003 18:46:33 -0700
Received: (from baitisj@localhost)
	by powerpuff.pas.lab (8.12.8/8.12.8/Submit) id h8N1kWJB009941
	for linux-mips@linux-mips.org; Mon, 22 Sep 2003 18:46:32 -0700
X-Authentication-Warning: powerpuff.pas.lab: baitisj set sender to baitisj@evolution.com using -f
Subject: Toshiba TX4925 experiences wanted
From: Jeffrey Baitis <baitisj@evolution.com>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1064281591.25782.255.camel@powerpuff.pas.lab>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 22 Sep 2003 18:46:32 -0700
Return-Path: <baitisj@evolution.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3261
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: baitisj@evolution.com
Precedence: bulk
X-list: linux-mips
Content-Length: 237
Lines: 11

I understand that the Linux MIPS kernel has support for the TX4927. Has
anyone tried the TX4925 as well? Does Monta Vista's BSP for the 27 work
for the 25?

Experiences?

Thanks a bunch!

-Jeff
-- 
Jeffrey Baitis <baitisj@evolution.com>

From ravdberg@inter.NL.net Tue Sep 23 04:20:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 04:20:24 +0100 (BST)
Received: from altrade.nijmegen.internl.net ([IPv6:::ffff:217.149.192.18]:1946
	"EHLO altrade.nijmegen.internl.net") by linux-mips.org with ESMTP
	id <S8225205AbTIWDUV>; Tue, 23 Sep 2003 04:20:21 +0100
Received: from whale.dutch.mountain by altrade.nijmegen.internl.net
	via 1Cust74.tnt27.rtm1.nld.da.uu.net [213.116.148.74] with ESMTP for <linux-mips@linux-mips.org>
	id h8N3KKop029911 (8.12.10/2.04); Tue, 23 Sep 2003 05:20:20 +0200 (MET DST)
Received: from (locally authorised broken client using invalid hostname!) localhost (really [127.0.0.1]) by whale.dutch.mountain
	via in.smtpd with esmtp (ident ravdberg using rfc1413)
	id <m1A1Siw-000HGrC@whale.dutch.mountain> (Debian Smail3.2.0.114)
	Mon, 22 Sep 2003 17:35:38 +0200 (CEST) 
Date: Mon, 22 Sep 2003 17:35:38 +0200 (CEST)
From: Richard van den Berg <ravdberg@inter.NL.net>
X-Sender: ravdberg@whale.dutch.mountain
To: linux-mips@linux-mips.org
Subject: Re: list archive
In-Reply-To: <20030919140142.GA28087@icm.edu.pl>
Message-ID: <Pine.LNX.4.21.0309221728370.23229-100000@whale.dutch.mountain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ravdberg@inter.NL.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3262
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ravdberg@inter.NL.net
Precedence: bulk
X-list: linux-mips
Content-Length: 926
Lines: 24

On Fri, 19 Sep 2003, Dominik 'Rathann' Mierzejewski wrote:

> On Fri, Sep 19, 2003 at 03:37:12PM +0200, Maciej W. Rozycki wrote:
> > On Fri, 19 Sep 2003, Dominik 'Rathann' Mierzejewski wrote:
> > 
> > > I've just got my first Indy box running Linux. And so, to avoid annoying
> > > you by asking stupid newbie questions I'll ask only one: where can I
> > > find this list's archives? Searching google for
> > > "linux-mips@linux-mips.org archive" doesn't yield anything of interest.
> > 
> >  See "http://www.linux-mips.org/mail.html" (the first page reported by
> > Google ;-) ).
> 
> Yes, I see it now, thanks. But I was counting on an online and searchable
> archive.

There was an online, but not searchable archive, however I discovered that
the plug has been pulled. Anyone with 20 MB space for the fnet archive
in html format I collected since june 1998 until the list ended august 
2002 is welcome.

Regards,
Richard


From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 23 09:15:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 09:15:02 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:5129
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225387AbTIWIPA>; Tue, 23 Sep 2003 09:15:00 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1iJr-0006Rr-00; Tue, 23 Sep 2003 10:14:47 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1iJr-0003kn-00; Tue, 23 Sep 2003 10:14:47 +0200
Date: Tue, 23 Sep 2003 10:14:47 +0200
To: Eric Christopher <echristo@redhat.com>
Cc: Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl> <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com> <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de> <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br> <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de> <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3263
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 713
Lines: 23

Eric Christopher wrote:
> On Mon, 2003-09-22 at 16:39, Thiemo Seufer wrote:
> > Alexandre Oliva wrote:
> > > On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> > > 
> > > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > > 
> > > In what sense is this different from -Wa,-mabi=n32 ?
> > 
> > ELF64 instead of ELF32.
> 
> objcopy?

You mean, let gcc generate n64 code, stuff it in n32 objects, and
objcopy it back to n64? Well, it may work, but it looks more like
a test of binutils sign-extension handling than a straightforward
way of creating kernels to me.

Besides, as soon as gcc handles 64bit expansions itself we need
such an option anyway.


Thiemo

From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 23 09:30:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 09:31:00 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:15113
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225557AbTIWIat>; Tue, 23 Sep 2003 09:30:49 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1iZL-0006bm-00; Tue, 23 Sep 2003 10:30:47 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1iZL-0003ly-00; Tue, 23 Sep 2003 10:30:47 +0200
Date: Tue, 23 Sep 2003 10:30:47 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] PMAG-AA Hardware cursor support
Message-ID: <20030923083047.GT13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030921212313.GN13578@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030922194304.25762C-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030922194304.25762C-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3264
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 19668
Lines: 685

Maciej W. Rozycki wrote:
> On Sun, 21 Sep 2003, Thiemo Seufer wrote:
> 
> > @@ -37,8 +37,7 @@ static inline void bt455_read_cmap_entry
> >  					 u8* red, u8* green, u8* blue)
> >  {
> >  	bt455_select_reg(regs, cr);
> > -	
> > -	mb();
> > +	rmb();
> >  	*red = regs->addr_cmap_data & 0x0f;
> >  	rmb();
> >  	*green = regs->addr_cmap_data & 0x0f;
> 
>  I do think it has to be an mb() as the first access is a write and the
> second one is a read. 
> 
>  You may also consider using ISO C initializers for struct members -- I
> can do the conversion myself, but since you are actively working on the
> code right now, I guess it might give you an unnecessary burden of chasing
> the changing master sources.

An updated patch is appended.


Thiemo


diff -abdpruNPX /bigdisk/src/dontdiff linux-orig/drivers/video/bt431.h linux/drivers/video/bt431.h
--- linux-orig/drivers/video/bt431.h	Tue Sep 16 17:05:14 2003
+++ linux/drivers/video/bt431.h	Sun Sep 21 22:39:12 2003
@@ -73,22 +73,42 @@ static inline u8 bt431_get_value(u16 val
 
 static inline void bt431_select_reg(struct bt431_regs *regs, int ir)
 {
+	/*
+	 * The compiler splits the write in two bytes without these
+	 * helper variables.
+	 */
+	volatile u16 *lo = &(regs->addr_lo);
+	volatile u16 *hi = &(regs->addr_hi);
+
 	mb();
-	regs->addr_lo = bt431_set_value(ir & 0xff);
-	regs->addr_hi = bt431_set_value((ir >> 8) & 0xff);
+	*lo = bt431_set_value(ir & 0xff);
+	wmb();
+	*hi = bt431_set_value((ir >> 8) & 0xff);
 }
 
 /* Autoincrement read/write. */
 static inline u8 bt431_read_reg_inc(struct bt431_regs *regs)
 {
+	/*
+	 * The compiler splits the write in two bytes without the
+	 * helper variable.
+	 */
+	volatile u16 *r = &(regs->addr_reg);
+
 	mb();
-	return bt431_get_value(regs->addr_reg);
+	return bt431_get_value(*r);
 }
 
 static inline void bt431_write_reg_inc(struct bt431_regs *regs, u8 value)
 {
+	/*
+	 * The compiler splits the write in two bytes without the
+	 * helper variable.
+	 */
+	volatile u16 *r = &(regs->addr_reg);
+
 	mb();
-	regs->addr_reg = bt431_set_value(value);
+	*r = bt431_set_value(value);
 }
 
 static inline u8 bt431_read_reg(struct bt431_regs *regs, int ir)
@@ -97,23 +117,35 @@ static inline u8 bt431_read_reg(struct b
 	return bt431_read_reg_inc(regs);
 }
 
-static inline void bt431_write_reg(struct bt431_regs *regs, int ir, u16 value)
+static inline void bt431_write_reg(struct bt431_regs *regs, int ir, u8 value)
 {
 	bt431_select_reg(regs, ir);
 	bt431_write_reg_inc(regs, value);
 }
 
-/* Autoincremented read/write for the cursor map */
+/* Autoincremented read/write for the cursor map. */
 static inline u16 bt431_read_cmap_inc(struct bt431_regs *regs)
 {
+	/*
+	 * The compiler splits the write in two bytes without the
+	 * helper variable.
+	 */
+	volatile u16 *r = &(regs->addr_cmap);
+
 	mb();
-	return regs->addr_cmap;
+	return *r;
 }
 
 static inline void bt431_write_cmap_inc(struct bt431_regs *regs, u16 value)
 {
+	/*
+	 * The compiler splits the write in two bytes without the
+	 * helper variable.
+	 */
+	volatile u16 *r = &(regs->addr_cmap);
+
 	mb();
-	regs->addr_cmap = value;
+	*r = value;
 }
 
 static inline u16 bt431_read_cmap(struct bt431_regs *regs, int cr)
@@ -130,10 +162,9 @@ static inline void bt431_write_cmap(stru
 
 static inline void bt431_enable_cursor(struct bt431_regs *regs)
 {
-/*	bt431_write_reg(regs, BT431_REG_CMD,
+	bt431_write_reg(regs, BT431_REG_CMD,
 			BT431_CMD_CURS_ENABLE | BT431_CMD_OR_CURSORS
 			| BT431_CMD_4_1_MUX | BT431_CMD_THICK_1);
-*/	bt431_write_reg(regs, BT431_REG_CMD, BT431_CMD_CURS_ENABLE);
 }
 
 static inline void bt431_erase_cursor(struct bt431_regs *regs)
@@ -166,64 +197,40 @@ static inline void bt431_position_cursor
 	bt431_write_reg_inc(regs, (y >> 8) & 0x0f); /* BT431_REG_CYHI */
 }
 
-/*u16 _bt431_default_cursor[64 * 8] = {
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0xffff, 0, 0, 0, 0, 0, 0, 0,
-	0,
-};
-*/
-static inline void bt431_load_cursor_sprite(struct bt431_regs *regs)
+static inline void bt431_set_font(struct bt431_regs *regs, u8 fgc,
+				  u16 width, u16 height)
 {
 	int i;
+	u16 fgp = fgc ? 0xffff : 0x0000;
+	u16 bgp = fgc ? 0x0000 : 0xffff;
 
 	bt431_select_reg(regs, BT431_REG_CRAM_BASE);
-	for (i = 0; i < 64 * 8; i++)
-		bt431_write_cmap_inc(regs, ((i < 16 * 8) && (i % 8)) ? 0xffff : 0);
+	for (i = BT431_REG_CRAM_BASE; i <= BT431_REG_CRAM_END; i++) {
+		u16 value;
+
+		if (height << 6 <= i << 3)
+			value = bgp;
+		else if (width <= i % 8 << 3)
+			value = bgp;
+		else if (((width >> 3) & 0xffff) > i % 8)
+			value = fgp;
+		else
+			value = fgp & ~(bgp << (width % 8 << 1));
+
+		bt431_write_cmap_inc(regs, value);
+	}
 }
 
 static inline void bt431_init_cursor(struct bt431_regs *regs)
 {
-	bt431_write_reg(regs, BT431_REG_CMD,
-			BT431_CMD_CURS_ENABLE | BT431_CMD_OR_CURSORS
-			| BT431_CMD_4_1_MUX | BT431_CMD_THICK_1);
-
-	/* home cursor */
-#if 0
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CXLO */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CXHI */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CYLO */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CYHI */
-#endif
-	bt431_write_reg_inc(regs, 0x80); /* BT431_REG_CXLO */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CXHI */
-	bt431_write_reg_inc(regs, 0x80); /* BT431_REG_CYLO */
-	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_CYHI */
-
 	/* no crosshair window */
+	bt431_select_reg(regs, BT431_REG_WXLO);
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WXLO */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WXHI */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WYLO */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WYHI */
-//	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WWLO */
-	bt431_write_reg_inc(regs, 0x01); /* BT431_REG_WWLO */
+	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WWLO */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WWHI */
-//	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WHLO */
-	bt431_write_reg_inc(regs, 0x01); /* BT431_REG_WHLO */
+	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WHLO */
 	bt431_write_reg_inc(regs, 0x00); /* BT431_REG_WHHI */
-
-	bt431_load_cursor_sprite(regs);
 }
diff -abdpruNPX /bigdisk/src/dontdiff linux-orig/drivers/video/bt455.h linux/drivers/video/bt455.h
--- linux-orig/drivers/video/bt455.h	Tue Sep 16 17:05:14 2003
+++ linux/drivers/video/bt455.h	Tue Sep 23 10:26:53 2003
@@ -37,7 +37,6 @@ static inline void bt455_read_cmap_entry
 					 u8* red, u8* green, u8* blue)
 {
 	bt455_select_reg(regs, cr);
-	
 	mb();
 	*red = regs->addr_cmap_data & 0x0f;
 	rmb();
@@ -50,7 +49,6 @@ static inline void bt455_write_cmap_entr
 					  u8 red, u8 green, u8 blue)
 {
 	bt455_select_reg(regs, cr);
-
 	wmb();
 	regs->addr_cmap_data = red & 0x0f;
 	wmb();
@@ -59,10 +57,11 @@ static inline void bt455_write_cmap_entr
 	regs->addr_cmap_data = blue & 0x0f;
 }
 
-static inline void bt455_write_ovly_entry(struct bt455_regs *regs,
+static inline void bt455_write_ovly_entry(struct bt455_regs *regs, int cr,
 					  u8 red, u8 green, u8 blue)
 {
-	mb();
+	bt455_select_reg(regs, cr);
+	wmb();
 	regs->addr_ovly = red & 0x0f;
 	wmb();
 	regs->addr_ovly = green & 0x0f;
@@ -82,10 +81,15 @@ static inline void bt455_set_cursor(stru
 
 static inline void bt455_erase_cursor(struct bt455_regs *regs)
 {
-//	bt455_write_cmap_entry(regs, 8, 0x00, 0x00, 0x00);
-//	bt455_write_cmap_entry(regs, 9, 0x00, 0x00, 0x00);
-	bt455_write_cmap_entry(regs, 8, 0x03, 0x03, 0x03);
-	bt455_write_cmap_entry(regs, 9, 0x07, 0x07, 0x07);
+	/* bt455_write_cmap_entry(regs, 8, 0x00, 0x00, 0x00); */
+	/* bt455_write_cmap_entry(regs, 9, 0x00, 0x00, 0x00); */
+	bt455_write_ovly_entry(regs, 8, 0x03, 0x03, 0x03);
+	bt455_write_ovly_entry(regs, 9, 0x07, 0x07, 0x07);
 
-	bt455_write_ovly_entry(regs, 0x09, 0x09, 0x09);
+	wmb();
+	regs->addr_ovly = 0x09;
+	wmb();
+	regs->addr_ovly = 0x09;
+	wmb();
+	regs->addr_ovly = 0x09;
 }
diff -abdpruNPX /bigdisk/src/dontdiff linux-orig/drivers/video/pmag-aa-fb.c linux/drivers/video/pmag-aa-fb.c
--- linux-orig/drivers/video/pmag-aa-fb.c	Tue Sep 16 17:05:14 2003
+++ linux/drivers/video/pmag-aa-fb.c	Tue Sep 23 10:26:52 2003
@@ -13,10 +13,14 @@
  *	Public License.  See the file COPYING in the main directory of this
  *	archive for more details.
  *
- *	Version 0.01 2002/09/28 first try to get a PMAG-AA running
+ *	2002-09-28  Karsten Merker <merker@linuxtag.org>
+ *		Version 0.01: First try to get a PMAG-AA running.
  * 
- *	2003/02/24  Thiemo Seufer  <seufer@csv.ica.uni-stuttgart.de>
- *		Code cleanup.
+ *	2003-02-24  Thiemo Seufer  <seufer@csv.ica.uni-stuttgart.de>
+ *		Version 0.02: Major code cleanup.
+ *
+ *	2003-09-21  Thiemo Seufer  <seufer@csv.ica.uni-stuttgart.de>
+ *		Hardware cursor support.
  */
 #include <linux/module.h>
 #include <linux/kernel.h>
@@ -30,22 +34,26 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/fb.h>
+#include <linux/console.h>
 
 #include <asm/bootinfo.h>
 #include <asm/dec/machtype.h>
 #include <asm/dec/tc.h>
 
 #include <video/fbcon.h>
-#include <video/fbcon-mfb.h>
 #include <video/fbcon-cfb8.h>
 
 #include "bt455.h"
 #include "bt431.h"
 
 /* Version information */
-#define DRIVER_VERSION "v0.02"
+#define DRIVER_VERSION "0.02"
 #define DRIVER_AUTHOR "Karsten Merker <merker@linuxtag.org>"
-#define DRIVER_DESC "PMAG-AA Framebuffer Driver"
+#define DRIVER_DESCRIPTION "PMAG-AA Framebuffer Driver"
+
+/* Prototypes */
+static int aafb_set_var(struct fb_var_screeninfo *var, int con,
+			struct fb_info *info);
 
 /*
  * Bt455 RAM DAC register base offset (rel. to TC slot base address).
@@ -63,9 +71,23 @@
  */
 #define PMAG_AA_ONBOARD_FBMEM_OFFSET	0x200000
 
+struct aafb_cursor {
+	struct timer_list timer;
+	int enable;
+	int on;
+	int vbl_cnt;
+	int blink_rate;
+	u16 x, y, width, height;
+};
+
+#define CURSOR_TIMER_FREQ	(HZ / 50)
+#define CURSOR_BLINK_RATE	(20)
+#define CURSOR_DRAW_DELAY	(2)
+
 struct aafb_info {
 	struct fb_info info;
 	struct display disp;
+	struct aafb_cursor cursor;
 	struct bt455_regs *bt455;
 	struct bt431_regs *bt431;
 	unsigned long fb_start;
@@ -81,57 +103,174 @@ static struct aafb_info my_fb_info[3];
 static struct aafb_par {
 } current_par;
 
-static int currcon = 0;
+static int currcon = -1;
 
-static void aafb_get_par(struct aafb_par *par)
+static void aafb_set_cursor(struct aafb_info *info, int on)
 {
-	*par = current_par;
+	struct aafb_cursor *c = &info->cursor;
+
+	if (on) {
+		bt431_position_cursor(info->bt431, c->x, c->y);
+		bt431_enable_cursor(info->bt431);
+	} else
+		bt431_erase_cursor(info->bt431);
 }
 
-static void aafb_encode_fix(struct fb_fix_screeninfo *fix,
-			    struct aafb_par *par, struct aafb_info *info)
+static void aafbcon_cursor(struct display *disp, int mode, int x, int y)
 {
-	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
-	strcpy(fix->id, "PMAG-AA");
+	struct aafb_info *info = (struct aafb_info *)disp->fb_info;
+	struct aafb_cursor *c = &info->cursor;
 
-	fix->smem_start = info->fb_start;
-	fix->smem_len = info->fb_size;
-	fix->type = FB_TYPE_PACKED_PIXELS;
-	fix->visual = FB_VISUAL_MONO10;
-	fix->line_length = info->fb_line_length;
-	fix->accel = FB_ACCEL_NONE;
+	x *= fontwidth(disp);
+	y *= fontheight(disp);
+
+	if (c->x == x && c->y == y && (mode == CM_ERASE) == !c->enable)
+		return;
+
+	c->enable = 0;
+	if (c->on)
+		aafb_set_cursor(info, 0);
+	c->x = x - disp->var.xoffset;
+	c->y = y - disp->var.yoffset;
+
+	switch (mode) {
+		case CM_ERASE:
+			c->on = 0;
+			break;
+		case CM_DRAW:
+		case CM_MOVE:
+			if (c->on)
+				aafb_set_cursor(info, c->on);
+			else
+				c->vbl_cnt = CURSOR_DRAW_DELAY;
+			c->enable = 1;
+			break;
+	}
+}
+
+static int aafbcon_set_font(struct display *disp, int width, int height)
+{
+	struct aafb_info *info = (struct aafb_info *)disp->fb_info;
+	struct aafb_cursor *c = &info->cursor;
+	u8 fgc = ~attr_bgcol_ec(disp, disp->conp);
+
+	if (width > 64 || height > 64 || width < 0 || height < 0)
+		return -EINVAL;
+
+	c->height = height;
+	c->width = width;
+
+	bt431_set_font(info->bt431, fgc, width, height);
+
+	return 1;
+}
+
+static void aafb_cursor_timer_handler(unsigned long data)
+{
+	struct aafb_info *info = (struct aafb_info *)data;
+	struct aafb_cursor *c = &info->cursor;
+
+	if (!c->enable)
+		goto out;
+
+	if (c->vbl_cnt && --c->vbl_cnt == 0) {
+		c->on ^= 1;
+		aafb_set_cursor(info, c->on);
+		c->vbl_cnt = c->blink_rate;
+	}
+
+out:
+	c->timer.expires = jiffies + CURSOR_TIMER_FREQ;
+	add_timer(&c->timer);
+}
+
+static void __init aafb_cursor_init(struct aafb_info *info)
+{
+	struct aafb_cursor *c = &info->cursor;
+
+	c->enable = 1;
+	c->on = 1;
+	c->x = c->y = 0;
+	c->width = c->height = 0;
+	c->vbl_cnt = CURSOR_DRAW_DELAY;
+	c->blink_rate = CURSOR_BLINK_RATE;
+
+	init_timer(&c->timer);
+	c->timer.data = (unsigned long)info;
+	c->timer.function = aafb_cursor_timer_handler;
+	mod_timer(&c->timer, jiffies + CURSOR_TIMER_FREQ);
+}
+
+static void __exit aafb_cursor_exit(struct aafb_info *info)
+{
+	struct aafb_cursor *c = &info->cursor;
+
+	del_timer_sync(&c->timer);
+}
+
+static struct display_switch aafb_switch8 = {
+	.setup = fbcon_cfb8_setup,
+	.bmove = fbcon_cfb8_bmove,
+	.clear = fbcon_cfb8_clear,
+	.putc = fbcon_cfb8_putc,
+	.putcs = fbcon_cfb8_putcs,
+	.revc = fbcon_cfb8_revc,
+	.cursor = aafbcon_cursor,
+	.set_font = aafbcon_set_font,
+	.clear_margins = fbcon_cfb8_clear_margins,
+	.fontwidthmask = FONTWIDTH(4)|FONTWIDTH(8)|FONTWIDTH(12)|FONTWIDTH(16)
+};
+
+static void aafb_get_par(struct aafb_par *par)
+{
+	*par = current_par;
 }
 
 static int aafb_get_fix(struct fb_fix_screeninfo *fix, int con,
 			struct fb_info *info)
 {
-	struct aafb_par par;
+	struct aafb_info *ip = (struct aafb_info *)info;
 
-	aafb_get_par(&par);
-	aafb_encode_fix(fix, &par, (struct aafb_info *) info);
+	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
+	strcpy(fix->id, "PMAG-AA");
+	fix->smem_start = ip->fb_start;
+	fix->smem_len = ip->fb_size;
+	fix->type = FB_TYPE_PACKED_PIXELS;
+	fix->ypanstep = 1;
+	fix->ywrapstep = 1;
+	fix->visual = FB_VISUAL_MONO10;
+	fix->line_length = 1280;
+	fix->accel = FB_ACCEL_NONE;
 
 	return 0;
 }
 
-static void aafb_set_disp(int con, struct fb_info *info)
+static void aafb_set_disp(struct display *disp, int con,
+			  struct aafb_info *info)
 {
 	struct fb_fix_screeninfo fix;
-	struct display *disp = (con < 0) ? info->disp : (fb_display + con);
 
-	aafb_get_fix(&fix, con, info);
+	disp->fb_info = &info->info;
+	aafb_set_var(&disp->var, con, &info->info);
+	if (disp->conp && disp->conp->vc_sw && disp->conp->vc_sw->con_cursor)
+		disp->conp->vc_sw->con_cursor(disp->conp, CM_ERASE);
+	disp->dispsw = &aafb_switch8;
+	disp->dispsw_data = 0;
 
-	disp->screen_base = (char *) fix.smem_start;
+	aafb_get_fix(&fix, con, &info->info);
+	disp->screen_base = (u8 *) fix.smem_start;
 	disp->visual = fix.visual;
 	disp->type = fix.type;
 	disp->type_aux = fix.type_aux;
 	disp->ypanstep = fix.ypanstep;
 	disp->ywrapstep = fix.ywrapstep;
-//	disp->line_length = fix.line_length;
-	disp->next_line = fix.line_length;
+	disp->line_length = fix.line_length;
+	disp->next_line = 2048;
 	disp->can_soft_blank = 1;
 	disp->inverse = 0;
-//	disp->scrollmode = SCROLL_YREDRAW;
-	disp->dispsw = &fbcon_cfb8;
+	disp->scrollmode = SCROLL_YREDRAW;
+
+	aafbcon_set_font(disp, fontwidth(disp), fontheight(disp));
 }
 
 static int aafb_get_cmap(struct fb_cmap *cmap, int kspc, int con,
@@ -147,14 +286,38 @@ static int aafb_get_cmap(struct fb_cmap 
 static int aafb_set_cmap(struct fb_cmap *cmap, int kspc, int con,
 			 struct fb_info *info)
 {
+	u16 color[2] = {0x0000, 0x000f};
+
+	if (cmap->start == 0
+	    && cmap->len == 2
+	    && memcmp(cmap->red, color, sizeof(color)) == 0
+	    && memcmp(cmap->green, color, sizeof(color)) == 0
+	    && memcmp(cmap->blue, color, sizeof(color)) == 0
+	    && cmap->transp == NULL)
+		return 0;
+	else
 	return -EINVAL;
 }
 
+static int aafb_ioctl(struct inode *inode, struct file *file, u32 cmd,
+		      unsigned long arg, int con, struct fb_info *info)
+{
+	/* TODO: Not yet implemented */
+	return -ENOIOCTLCMD;
+}
+
 static int aafb_switch(int con, struct fb_info *info)
 {
+	struct aafb_info *ip = (struct aafb_info *)info;
+	struct display *old = (currcon < 0) ? &ip->disp : (fb_display + currcon);
+	struct display *new = (con < 0) ? &ip->disp : (fb_display + con);
+
+	if (old->conp && old->conp->vc_sw && old->conp->vc_sw->con_cursor)
+		old->conp->vc_sw->con_cursor(old->conp, CM_ERASE);
+
 	/* Set the current console. */
 	currcon = con;
-	aafb_set_disp(con, info);
+	aafb_set_disp(new, con, ip);
 
 	return 0;
 }
@@ -218,6 +381,12 @@ static int aafb_set_var(struct fb_var_sc
 
 static int aafb_update_var(int con, struct fb_info *info)
 {
+	struct aafb_info *ip = (struct aafb_info *)info;
+	struct display *disp = (con < 0) ? &ip->disp : (fb_display + con);
+
+	if (con == currcon)
+		aafbcon_cursor(disp, CM_ERASE, ip->cursor.x, ip->cursor.y);
+
 	return 0;
 }
 
@@ -229,15 +398,17 @@ static void aafb_blank(int blank, struct
 	u8 val = blank ? 0x00 : 0x0f;
 
 	bt455_write_cmap_entry(ip->bt455, 1, val, val, val);
+	aafbcon_cursor(&ip->disp, CM_ERASE, ip->cursor.x, ip->cursor.y);
 }
 
 static struct fb_ops aafb_ops = {
-	owner:THIS_MODULE,
-	fb_get_fix:aafb_get_fix,
-	fb_get_var:aafb_get_var,
-	fb_set_var:aafb_set_var,
-	fb_get_cmap:aafb_get_cmap,
-	fb_set_cmap:aafb_set_cmap
+	.owner = THIS_MODULE,
+	.fb_get_fix = aafb_get_fix,
+	.fb_get_var = aafb_get_var,
+	.fb_set_var = aafb_set_var,
+	.fb_get_cmap = aafb_get_cmap,
+	.fb_set_cmap = aafb_set_cmap,
+	.fb_ioctl = aafb_ioctl
 };
 
 static int __init init_one(int slot)
@@ -258,20 +429,6 @@ static int __init init_one(int slot)
 	ip->fb_line_length = 2048;
 
 	/*
-	 * Configure the RAM DACs.
-	 */
-// TODO
-//	bt455_erase_cursor(ip->bt455);
-//	bt455_set_cursor(ip->bt455);
-//	bt431_erase_cursor(ip->bt431);
-//	bt431_init_cursor(ip->bt431);
-//	bt431_position_cursor(ip->bt431, 16, 16);
-
-	/* Init colormap. */
-	bt455_write_cmap_entry(ip->bt455, 0, 0x00, 0x00, 0x00);
-	bt455_write_cmap_entry(ip->bt455, 1, 0x0f, 0x0f, 0x0f);
-
-	/*
 	 * Let there be consoles..
 	 */
 	strcpy(ip->info.modename, "PMAG-AA");
@@ -284,8 +441,20 @@ static int __init init_one(int slot)
 	ip->info.updatevar = &aafb_update_var;
 	ip->info.blank = &aafb_blank;
 
-	aafb_set_disp(-1, &ip->info);
-	aafb_set_var(&ip->disp.var, -1, &ip->info);
+	aafb_set_disp(&ip->disp, currcon, ip);
+
+	/*
+	 * Configure the RAM DACs.
+	 */
+	bt455_erase_cursor(ip->bt455);
+
+	/* Init colormap. */
+	bt455_write_cmap_entry(ip->bt455, 0, 0x00, 0x00, 0x00);
+	bt455_write_cmap_entry(ip->bt455, 1, 0x0f, 0x0f, 0x0f);
+
+	/* Init hardware cursor. */
+	bt431_init_cursor(ip->bt431);
+	aafb_cursor_init(ip);
 
 	/* Clear the screen. */
 	memset ((void *)ip->fb_start, 0, ip->fb_size);
@@ -293,7 +462,7 @@ static int __init init_one(int slot)
 	if (register_framebuffer(&ip->info) < 0)
 		return -EINVAL;
 
-	printk(KERN_INFO "fb%d: %s frame buffer device in TC slot %d\n",
+	printk(KERN_INFO "fb%d: %s frame buffer in TC slot %d\n",
 	       GET_FB_IDX(ip->info.node), ip->info.modename, slot);
 
 	return 0;
@@ -336,4 +505,10 @@ static void __exit pmagaafb_exit(void)
 	}
 }
 
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
 MODULE_LICENSE("GPL");
+#ifdef MODULE
+module_init(pmagaafb_init);
+module_exit(pmagaafb_exit);
+#endif

From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 23 09:40:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 09:40:39 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:17673
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225387AbTIWIkG>; Tue, 23 Sep 2003 09:40:06 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1iiL-0006fK-00; Tue, 23 Sep 2003 10:40:05 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1iiL-0003mi-00; Tue, 23 Sep 2003 10:40:05 +0200
Date: Tue, 23 Sep 2003 10:40:05 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix character loss in drivers/tc/zs.c
Message-ID: <20030923084005.GU13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030921213104.GO13578@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030922193409.25762B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030922193409.25762B-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3265
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 598
Lines: 19

Maciej W. Rozycki wrote:
> On Sun, 21 Sep 2003, Thiemo Seufer wrote:
> 
> > this patch reduces the zs driver's character lossage.
> 
>  Can you please elaborate?  tty is expected to be NULL if info->hook is
> not, so the code after the change should not differ effectively -- only a
> useless check is added at the end.  Am I missing anything?

AFAICS the

        while ((read_zsreg(info->zs_channel, R0) & Rx_CH_AV) != 0) {

loops over the FIFO contents and 'return' discards the remaining
part. The patch made a visible difference for me with some noisy
debug printk()'s in the kernel.


Thiemo

From macro@ds2.pg.gda.pl Tue Sep 23 12:31:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 12:31:55 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:38084 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225565AbTIWLbw>; Tue, 23 Sep 2003 12:31:52 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA22790;
	Tue, 23 Sep 2003 13:31:43 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 23 Sep 2003 13:31:43 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix character loss in drivers/tc/zs.c
In-Reply-To: <20030923084005.GU13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030923132357.22133B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3266
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1200
Lines: 45

On Tue, 23 Sep 2003, Thiemo Seufer wrote:

> >  Can you please elaborate?  tty is expected to be NULL if info->hook is
> > not, so the code after the change should not differ effectively -- only a
> > useless check is added at the end.  Am I missing anything?
> 
> AFAICS the
> 
>         while ((read_zsreg(info->zs_channel, R0) & Rx_CH_AV) != 0) {
> 
> loops over the FIFO contents and 'return' discards the remaining
> part. The patch made a visible difference for me with some noisy
> debug printk()'s in the kernel.

 Hmm, a coincidence?  Without your patch the execution goes as follows:

receive_chars()
{
	...
	(*info->hook->rx_char)(ch, flag);
	return;
}

And after the change it is as follows:

receive_chars()
{
	...
	(*info->hook->rx_char)(ch, flag);
	if (tty)
		tty_flip_buffer_push(tty);
	return;
}

and tty is NULL.  And I fail to see how it can it make any difference for
printk() output -- the code in question is only ever executed for input
from an LK201-type keyboard.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From dom@mips.com Tue Sep 23 12:38:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 12:38:38 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:63752 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225565AbTIWLif>;
	Tue, 23 Sep 2003 12:38:35 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1A1lUR-0002Hg-00; Tue, 23 Sep 2003 12:37:55 +0100
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1A1lSO-0001xo-00; Tue, 23 Sep 2003 12:35:48 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16240.12304.556561.464629@gladsmuir.mips.com>
Date: Tue, 23 Sep 2003 12:35:44 +0100
To: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
Cc: <linux-mips@linux-mips.org>
Subject: Re: User-mode drivers and TLB
In-Reply-To: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB750@iris.adtech-inc.com>
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB750@iris.adtech-inc.com>
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-3.5, required 4, AWL,
	BAYES_10, QUOTED_EMAIL_TEXT, REFERENCES)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3267
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1410
Lines: 33


Steve,

> I am working on an app where I want to give one or more user
> processes access to a largish range of physical address space
> (specifically, this is a Broadcom 1125 running a 32 bit kernel, and
> for now the region is accessible via KSEG0/1 (physical address < 512
> MB)). mmap() on /dev/mem does this just fine, and setting (or not
> setting) O_SYNC on open seems to control caching. But I just
> realized a disadvantage to doing this in user space: the user
> process accesses have to be mapped (since a user process can't, I
> believe, use KSEG0 or KSEG1 addresses), so you have to go through
> the (64 entry) TLB, and if you had signficant non-locality of
> reference, you'd possibly risk thrashing the TLB (which doesn't
> happen in kernel space, since the region can be directly accessed).

As usual, I guess the first thing is to try doing it the standard way
and then try to measure how much time is being spent in extra TLB misses
generated by your application.  Some MIPS CPUs have "performance
counters" which might be able to count TLB misses, but you'll more
likely have to instrument the TLB miss code.

If it does turn out that TLB replacement is a big drain:

Most MIPS CPU hardware allows you to map large chunks of memory with a
single TLB entry: often up to 16Mbytes at a time.  But I don't know
how you'd persuade Linux how to do that.

--
Dominic Sweetman
MIPS Technologies.



From macro@ds2.pg.gda.pl Tue Sep 23 13:12:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 13:12:31 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:15302 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225569AbTIWMM2>; Tue, 23 Sep 2003 13:12:28 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA23571;
	Tue, 23 Sep 2003 14:12:25 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 23 Sep 2003 14:12:24 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] PMAG-AA Hardware cursor support
In-Reply-To: <20030923083047.GT13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030923141151.22133D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3268
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 302
Lines: 11

On Tue, 23 Sep 2003, Thiemo Seufer wrote:

> An updated patch is appended.

 Thanks, this is now in.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 23 13:14:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 13:14:16 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:32266
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225569AbTIWMON>; Tue, 23 Sep 2003 13:14:13 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1m3X-0006X3-00; Tue, 23 Sep 2003 14:14:11 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1m3W-000676-00; Tue, 23 Sep 2003 14:14:10 +0200
Date: Tue, 23 Sep 2003 14:14:10 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix character loss in drivers/tc/zs.c
Message-ID: <20030923121410.GW13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030923084005.GU13578@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1030923132357.22133B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030923132357.22133B-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3269
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1347
Lines: 42

Maciej W. Rozycki wrote:
> On Tue, 23 Sep 2003, Thiemo Seufer wrote:
> 
> > >  Can you please elaborate?  tty is expected to be NULL if info->hook is
> > > not, so the code after the change should not differ effectively -- only a
> > > useless check is added at the end.  Am I missing anything?
> > 
> > AFAICS the
> > 
> >         while ((read_zsreg(info->zs_channel, R0) & Rx_CH_AV) != 0) {
> > 
> > loops over the FIFO contents and 'return' discards the remaining
> > part. The patch made a visible difference for me with some noisy
> > debug printk()'s in the kernel.
> 
>  Hmm, a coincidence?  Without your patch the execution goes as follows:

Well, the code suggests so. But thinking about it again, it should
probably read (untested):


--- linux-orig/drivers/tc/zs.c	Tue Aug 12 04:11:58 2003
+++ linux/drivers/tc/zs.c	Tue Sep 23 14:09:34 2003
@@ -456,7 +456,7 @@ static _INLINE_ void receive_chars(struc
 
 		if (info->hook && info->hook->rx_char) {
 			(*info->hook->rx_char)(ch, flag);
-			return;
+			continue;
   		}
 
 		if (tty->flip.count >= TTY_FLIPBUF_SIZE) {

[snip]
> and tty is NULL.  And I fail to see how it can it make any difference for
> printk() output -- the code in question is only ever executed for input
> from an LK201-type keyboard.

I found this on Karsten's 5000/150. We can try it out again soon. :-)


Thiemo

From macro@ds2.pg.gda.pl Tue Sep 23 13:36:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 13:36:46 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:13255 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225572AbTIWMgg>; Tue, 23 Sep 2003 13:36:36 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA24054;
	Tue, 23 Sep 2003 14:36:26 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 23 Sep 2003 14:36:25 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix character loss in drivers/tc/zs.c
In-Reply-To: <20030923121410.GW13578@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.3.96.1030923142023.22133F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3270
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1294
Lines: 37

On Tue, 23 Sep 2003, Thiemo Seufer wrote:

> Well, the code suggests so. But thinking about it again, it should
> probably read (untested):
> 
> 
> --- linux-orig/drivers/tc/zs.c	Tue Aug 12 04:11:58 2003
> +++ linux/drivers/tc/zs.c	Tue Sep 23 14:09:34 2003
> @@ -456,7 +456,7 @@ static _INLINE_ void receive_chars(struc
>  
>  		if (info->hook && info->hook->rx_char) {
>  			(*info->hook->rx_char)(ch, flag);
> -			return;
> +			continue;
>    		}
>  
>  		if (tty->flip.count >= TTY_FLIPBUF_SIZE) {

 That might make some sense performance-wise, but it still doesn't make a
big difference -- continuing with the loop will let following pending
codes from the keyboard to be fetched immediately, while returning defers
that to the next SCC interrupt.

 Actually, I'm not that keen on making revolutionary changes to
drivers/tc/zs, just fixing bugs (of course, this might be one).  The
driver should be rewritten to become a front-end to
drivers/net/wan/z85230.c (the path seems unfortunate).  Then more
interesting stuff, like DMA and synchronous operation, will become
available. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From dkesselr@mmc.atmel.com Tue Sep 23 18:01:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 18:01:52 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:21983
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225576AbTIWRBt>; Tue, 23 Sep 2003 18:01:49 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id NAA17794
	for <linux-mips@linux-mips.org>; Tue, 23 Sep 2003 13:01:41 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id NAA09486
	for <linux-mips@linux-mips.org>; Tue, 23 Sep 2003 13:01:41 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Tue, 23 Sep 2003 13:01:41 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: Malta build 2.4
Message-ID: <Pine.GSO.4.44.0309231259110.2816-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3271
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips
Content-Length: 426
Lines: 14

I've just checked out the 2.4 tree from linux-mips cvs and used the Malta
config file, defconfig-malta. I get the following error. Does anyone know
if it a Makefile bug or a config file problem?

drivers/char/char.o: In function `console_init':
drivers/char/char.o(.text.init+0x178): undefined reference to
`arc_console_init'make: *** [vmlinux] Error 1

Thanks,
David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com
919-462-6587


From echristo@redhat.com Tue Sep 23 19:02:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 19:02:06 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:1033 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225579AbTIWSCD>;
	Tue, 23 Sep 2003 19:02:03 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h8NHiKO21371;
	Tue, 23 Sep 2003 13:44:20 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h8NI1ED21083;
	Tue, 23 Sep 2003 14:01:14 -0400
Received: from ghostwheel.sfbay.redhat.com (vpn26-5.sfbay.redhat.com [172.16.26.5])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h8NI1Cw19264;
	Tue, 23 Sep 2003 11:01:12 -0700
Subject: Re: recent binutils and mips64-linux
From: Eric Christopher <echristo@redhat.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
In-Reply-To: <20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
	 <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
	 <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
	 <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
	 <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de>
	 <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com>
	 <20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain
Message-Id: <1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Tue, 23 Sep 2003 11:01:11 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3272
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 650
Lines: 22


> > 
> > objcopy?
> 
> You mean, let gcc generate n64 code, stuff it in n32 objects, and
> objcopy it back to n64? Well, it may work, but it looks more like
> a test of binutils sign-extension handling than a straightforward
> way of creating kernels to me.
> 
> Besides, as soon as gcc handles 64bit expansions itself we need
> such an option anyway.

I'm still trying to figure out why you are going through such weird
contortions at all. I understand not having an elf64 loader. That's what
the objcopy comment was for, everything else I don't understand. Why not
compile for the abi you want?

-eric

-- 
Eric Christopher <echristo@redhat.com>


From drow@crack.them.org Tue Sep 23 19:17:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 19:17:13 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:56284 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225581AbTIWSRL>;
	Tue, 23 Sep 2003 19:17:11 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A1rid-0007uu-U2; Tue, 23 Sep 2003 14:16:59 -0400
Date: Tue, 23 Sep 2003 14:16:59 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Eric Christopher <echristo@redhat.com>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030923181659.GA30037@nevyn.them.org>
Mail-Followup-To: Eric Christopher <echristo@redhat.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl> <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com> <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de> <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br> <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de> <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com> <20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de> <1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3273
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 982
Lines: 25

On Tue, Sep 23, 2003 at 11:01:11AM -0700, Eric Christopher wrote:
> 
> > > 
> > > objcopy?
> > 
> > You mean, let gcc generate n64 code, stuff it in n32 objects, and
> > objcopy it back to n64? Well, it may work, but it looks more like
> > a test of binutils sign-extension handling than a straightforward
> > way of creating kernels to me.
> > 
> > Besides, as soon as gcc handles 64bit expansions itself we need
> > such an option anyway.
> 
> I'm still trying to figure out why you are going through such weird
> contortions at all. I understand not having an elf64 loader. That's what
> the objcopy comment was for, everything else I don't understand. Why not
> compile for the abi you want?

Compare the optimal way to load an address into a register when you
have a full 64-bit address space and when you know that addresses are
sign extended.  I'm told it saves over 100K of code.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From dkesselr@mmc.atmel.com Tue Sep 23 20:07:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 20:07:06 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:65273
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225376AbTIWTHD>; Tue, 23 Sep 2003 20:07:03 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id PAA20107
	for <linux-mips@linux-mips.org>; Tue, 23 Sep 2003 15:06:57 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id PAA09823
	for <linux-mips@linux-mips.org>; Tue, 23 Sep 2003 15:06:56 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Tue, 23 Sep 2003 15:06:56 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: Malta build 2.4 (fwd)
Message-ID: <Pine.GSO.4.44.0309231505310.2816-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3275
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips
Content-Length: 803
Lines: 29

The problem is somehow related to "make menuconfig" setting CONFIG_ARC=y.
When I configured with xconfig the build was ok.

David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com
919-462-6587

---------- Forwarded message ----------
Date: Tue, 23 Sep 2003 13:01:41 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: Malta build 2.4

I've just checked out the 2.4 tree from linux-mips cvs and used the Malta
config file, defconfig-malta. I get the following error. Does anyone know
if it a Makefile bug or a config file problem?

drivers/char/char.o: In function `console_init':
drivers/char/char.o(.text.init+0x178): undefined reference to
`arc_console_init'make: *** [vmlinux] Error 1

Thanks,
David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com
919-462-6587



From Steve.Finney@SpirentCom.COM Tue Sep 23 20:41:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 20:41:35 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:18600 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225435AbTIWTld> convert rfc822-to-8bit; Tue, 23 Sep 2003 20:41:33 +0100
content-class: urn:content-classes:message
Subject: RE: User-mode drivers and TLB
Date: Tue, 23 Sep 2003 09:41:24 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB753@iris.adtech-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: User-mode drivers and TLB
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcOBxzv9D3K9HersR8CGkd2fLs28hwAQrWZw
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: "Dominic Sweetman" <dom@mips.com>
Cc: <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3276
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 555
Lines: 12

> 
> Most MIPS CPU hardware allows you to map large chunks of memory with a
> single TLB entry: often up to 16Mbytes at a time.  But I don't know
> how you'd persuade Linux how to do that.
> 
> --
> Dominic Sweetman
> MIPS Technologies.

Thanks: for what it's worth, the Broadcom/Sibyte apparently allows a TLB entry to map 128 MB (the max mapped size is 64 MB, but the TLB entries are paired). And supposedly the MIPS kernel tree was recently updated with some support for Linux to use wired TLB entries on the Broadcom, though I haven't tried this.

sf

From zack@codesourcery.com Tue Sep 23 20:49:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 20:49:03 +0100 (BST)
Received: from voldemort.codesourcery.com ([IPv6:::ffff:65.73.237.138]:36582
	"EHLO mail.codesourcery.com") by linux-mips.org with ESMTP
	id <S8225376AbTIWTtB>; Tue, 23 Sep 2003 20:49:01 +0100
Received: (qmail 21400 invoked from network); 23 Sep 2003 19:42:03 -0000
Received: from dhcp119.icir.org (HELO taltos.codesourcery.com) (zack@192.150.187.119)
  by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 23 Sep 2003 19:42:03 -0000
Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Tue, 23 Sep 2003 12:45:36 -0700
From: "Zack Weinberg" <zack@codesourcery.com>
To: Eric Christopher <echristo@redhat.com>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
	<1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
	<20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
	<ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
	<20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de>
	<1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com>
	<20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de>
	<1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com>
	<20030923181659.GA30037@nevyn.them.org>
Date: Tue, 23 Sep 2003 12:45:36 -0700
In-Reply-To: <20030923181659.GA30037@nevyn.them.org> (Daniel Jacobowitz's
 message of "Tue, 23 Sep 2003 14:16:59 -0400")
Message-ID: <87eky7b867.fsf@codesourcery.com>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <zack@codesourcery.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3277
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zack@codesourcery.com
Precedence: bulk
X-list: linux-mips
Content-Length: 717
Lines: 18

Daniel Jacobowitz <dan@debian.org> writes:

> On Tue, Sep 23, 2003 at 11:01:11AM -0700, Eric Christopher wrote:
>> 
>> I'm still trying to figure out why you are going through such weird
>> contortions at all. I understand not having an elf64 loader. That's what
>> the objcopy comment was for, everything else I don't understand. Why not
>> compile for the abi you want?
>
> Compare the optimal way to load an address into a register when you
> have a full 64-bit address space and when you know that addresses are
> sign extended.  I'm told it saves over 100K of code.

Maybe what you really want is an -mdata-model=kernel switch (or some
such spelling) that tells gcc to do the right thing in the first
place?

zw

From drow@crack.them.org Tue Sep 23 20:56:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 20:56:52 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:19934 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225376AbTIWT4t>;
	Tue, 23 Sep 2003 20:56:49 +0100
Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian))
	id 1A1tH5-0002Qc-9m; Tue, 23 Sep 2003 15:56:39 -0400
Date: Tue, 23 Sep 2003 15:56:39 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Eric Christopher <echristo@redhat.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030923195638.GA9318@nevyn.them.org>
Mail-Followup-To: Zack Weinberg <zack@codesourcery.com>,
	Eric Christopher <echristo@redhat.com>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl> <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com> <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de> <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br> <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de> <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com> <20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de> <1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com> <20030923181659.GA30037@nevyn.them.org> <87eky7b867.fsf@codesourcery.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87eky7b867.fsf@codesourcery.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3278
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1042
Lines: 25

On Tue, Sep 23, 2003 at 12:45:36PM -0700, Zack Weinberg wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
> 
> > On Tue, Sep 23, 2003 at 11:01:11AM -0700, Eric Christopher wrote:
> >> 
> >> I'm still trying to figure out why you are going through such weird
> >> contortions at all. I understand not having an elf64 loader. That's what
> >> the objcopy comment was for, everything else I don't understand. Why not
> >> compile for the abi you want?
> >
> > Compare the optimal way to load an address into a register when you
> > have a full 64-bit address space and when you know that addresses are
> > sign extended.  I'm told it saves over 100K of code.
> 
> Maybe what you really want is an -mdata-model=kernel switch (or some
> such spelling) that tells gcc to do the right thing in the first
> place?

GCC should get a switch to do this.  But GCC doesn't (does 3.4 yet?)
emit these itself anyway.  Binutils expands them from the dla macro.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 23 21:04:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 21:04:25 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:56078
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225376AbTIWUEW>; Tue, 23 Sep 2003 21:04:22 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1tNq-0003dB-00; Tue, 23 Sep 2003 22:03:38 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1tNp-00068S-00; Tue, 23 Sep 2003 22:03:37 +0200
Date: Tue, 23 Sep 2003 22:03:37 +0200
To: Zack Weinberg <zack@codesourcery.com>
Cc: Eric Christopher <echristo@redhat.com>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030923200337.GE18698@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl> <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com> <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de> <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br> <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de> <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com> <20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de> <1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com> <20030923181659.GA30037@nevyn.them.org> <87eky7b867.fsf@codesourcery.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87eky7b867.fsf@codesourcery.com>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3279
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1161
Lines: 29

Zack Weinberg wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
> 
> > On Tue, Sep 23, 2003 at 11:01:11AM -0700, Eric Christopher wrote:
> >> 
> >> I'm still trying to figure out why you are going through such weird
> >> contortions at all. I understand not having an elf64 loader. That's what
> >> the objcopy comment was for, everything else I don't understand. Why not
> >> compile for the abi you want?
> >
> > Compare the optimal way to load an address into a register when you
> > have a full 64-bit address space and when you know that addresses are
> > sign extended.  I'm told it saves over 100K of code.
> 
> Maybe what you really want is an -mdata-model=kernel switch (or some
> such spelling)

Well, an ELF64 kernel loaded in the 64bit address space is also legal,
and desireable on some (bigger) hardware. Btw, it would have to be
-mtext-model=kernel, the data is the same. :-)

> that tells gcc to do the right thing in the first place?

Gcc still generates MIPS assembler macros, so such a switch would
do nothing yet. Gcc should be changed to do the expansion itself
(and improve code quality by that), but that's a much larger task.


Thiemo

From zack@codesourcery.com Tue Sep 23 21:09:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 21:09:35 +0100 (BST)
Received: from voldemort.codesourcery.com ([IPv6:::ffff:65.73.237.138]:60135
	"EHLO mail.codesourcery.com") by linux-mips.org with ESMTP
	id <S8225376AbTIWUJ1>; Tue, 23 Sep 2003 21:09:27 +0100
Received: (qmail 22380 invoked from network); 23 Sep 2003 20:02:31 -0000
Received: from dhcp119.icir.org (HELO taltos.codesourcery.com) (zack@192.150.187.119)
  by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 23 Sep 2003 20:02:31 -0000
Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Tue, 23 Sep 2003 13:06:03 -0700
From: "Zack Weinberg" <zack@codesourcery.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Eric Christopher <echristo@redhat.com>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
	<1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
	<20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
	<ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
	<20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de>
	<1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com>
	<20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de>
	<1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com>
	<20030923181659.GA30037@nevyn.them.org>
	<87eky7b867.fsf@codesourcery.com>
	<20030923200337.GE18698@rembrandt.csv.ica.uni-stuttgart.de>
Date: Tue, 23 Sep 2003 13:06:03 -0700
In-Reply-To: <20030923200337.GE18698@rembrandt.csv.ica.uni-stuttgart.de> (Thiemo
 Seufer's message of "Tue, 23 Sep 2003 22:03:37 +0200")
Message-ID: <87ad8vb784.fsf@codesourcery.com>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <zack@codesourcery.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3280
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: zack@codesourcery.com
Precedence: bulk
X-list: linux-mips
Content-Length: 934
Lines: 25

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:

> Zack Weinberg wrote:
>> 
>> Maybe what you really want is an -mdata-model=kernel switch (or some
>> such spelling)
>
> Well, an ELF64 kernel loaded in the 64bit address space is also legal,
> and desireable on some (bigger) hardware. Btw, it would have to be
> -mtext-model=kernel, the data is the same. :-)

Well, you wouldn't compile such a kernel with that switch.  Maybe
spelling it -mtext-model=kseg0 would be more descriptive.

>> that tells gcc to do the right thing in the first place?
>
> Gcc still generates MIPS assembler macros, so such a switch would
> do nothing yet. Gcc should be changed to do the expansion itself
> (and improve code quality by that), but that's a much larger task.

Gcc can at least pass the setting along to the assembler (which would
have to grow such an option as well, either as a command line switch
or (preferred) a .directive).

zw

From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 23 21:19:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 21:19:36 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:65038
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225376AbTIWUTe>; Tue, 23 Sep 2003 21:19:34 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1A1tce-0003lC-00; Tue, 23 Sep 2003 22:18:56 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1A1tcd-0007Tf-00; Tue, 23 Sep 2003 22:18:55 +0200
Date: Tue, 23 Sep 2003 22:18:55 +0200
To: Zack Weinberg <zack@codesourcery.com>
Cc: Eric Christopher <echristo@redhat.com>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: recent binutils and mips64-linux
Message-ID: <20030923201855.GF18698@rembrandt.csv.ica.uni-stuttgart.de>
References: <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de> <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br> <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de> <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com> <20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de> <1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com> <20030923181659.GA30037@nevyn.them.org> <87eky7b867.fsf@codesourcery.com> <20030923200337.GE18698@rembrandt.csv.ica.uni-stuttgart.de> <87ad8vb784.fsf@codesourcery.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ad8vb784.fsf@codesourcery.com>
User-Agent: Mutt/1.5.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3281
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips
Content-Length: 326
Lines: 11

Zack Weinberg wrote:
[snip]
> Gcc can at least pass the setting along to the assembler (which would
> have to grow such an option as well, either as a command line switch
> or (preferred) a .directive).

Hand-coded assembly will need the command line switch, as the same
file should work for both models if possible.


Thiemo

From echristo@redhat.com Tue Sep 23 21:29:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 23 Sep 2003 21:29:02 +0100 (BST)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:28426 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225376AbTIWU3A>;
	Tue, 23 Sep 2003 21:29:00 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h8NKBLO27433;
	Tue, 23 Sep 2003 16:11:21 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h8NKSFD29503;
	Tue, 23 Sep 2003 16:28:16 -0400
Received: from ghostwheel.sfbay.redhat.com (vpn26-5.sfbay.redhat.com [172.16.26.5])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h8NKS4w27385;
	Tue, 23 Sep 2003 13:28:04 -0700
Subject: Re: recent binutils and mips64-linux
From: Eric Christopher <echristo@redhat.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Zack Weinberg <zack@codesourcery.com>,
	Alexandre Oliva <aoliva@redhat.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Atsushi Nemoto <nemoto@toshiba-tops.co.jp>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
In-Reply-To: <20030923200337.GE18698@rembrandt.csv.ica.uni-stuttgart.de>
References: <Pine.GSO.3.96.1030919144141.9134C-100000@delta.ds2.pg.gda.pl>
	 <1063988420.2537.5.camel@ghostwheel.sfbay.redhat.com>
	 <20030919164119.GH13578@rembrandt.csv.ica.uni-stuttgart.de>
	 <ord6ds346n.fsf@free.redhat.lsd.ic.unicamp.br>
	 <20030922233952.GR13578@rembrandt.csv.ica.uni-stuttgart.de>
	 <1064280106.21720.0.camel@ghostwheel.sfbay.redhat.com>
	 <20030923081447.GS13578@rembrandt.csv.ica.uni-stuttgart.de>
	 <1064340070.21720.14.camel@ghostwheel.sfbay.redhat.com>
	 <20030923181659.GA30037@nevyn.them.org> <87eky7b867.fsf@codesourcery.com>
	 <20030923200337.GE18698@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain
Message-Id: <1064348883.21720.16.camel@ghostwheel.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Tue, 23 Sep 2003 13:28:03 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3282
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 446
Lines: 17


> > that tells gcc to do the right thing in the first place?
> 
> Gcc still generates MIPS assembler macros, so such a switch would
> do nothing yet. Gcc should be changed to do the expansion itself
> (and improve code quality by that), but that's a much larger task.

And is done in mainline.

.set nomacro, .set noreorder provided you have a gas that can deal with
it on the function level.

-eric

-- 
Eric Christopher <echristo@redhat.com>


From ralf@linux-mips.org Wed Sep 24 04:31:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 04:31:07 +0100 (BST)
Received: from ftp.linux-mips.org ([IPv6:::ffff:62.254.210.162]:10446 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225390AbTIXDbE>; Wed, 24 Sep 2003 04:31:04 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8O3UXXP023870;
	Tue, 23 Sep 2003 20:30:33 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8O3UWFZ023869;
	Tue, 23 Sep 2003 20:30:32 -0700
Date: Tue, 23 Sep 2003 20:30:31 -0700
From: Ralf Baechle <ralf@linux-mips.org>
To: Jeffrey Baitis <baitisj@evolution.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Toshiba TX4925 experiences wanted
Message-ID: <20030924033031.GA23795@linux-mips.org>
References: <1064281591.25782.255.camel@powerpuff.pas.lab>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1064281591.25782.255.camel@powerpuff.pas.lab>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3283
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 374
Lines: 10

On Mon, Sep 22, 2003 at 06:46:32PM -0700, Jeffrey Baitis wrote:

> I understand that the Linux MIPS kernel has support for the TX4927. Has
> anyone tried the TX4925 as well? Does Monta Vista's BSP for the 27 work
> for the 25?

At least in theory the entire TX49 series members are so similar that
getting them to work should be easy if they're not already working.

  Ralf

From mips4700@yahoo.co.jp Wed Sep 24 07:05:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 07:05:11 +0100 (BST)
Received: from web2307.mail.yahoo.co.jp ([IPv6:::ffff:211.14.15.227]:19814
	"HELO web2307.mail.yahoo.co.jp") by linux-mips.org with SMTP
	id <S8225406AbTIXGFJ>; Wed, 24 Sep 2003 07:05:09 +0100
Message-ID: <20030924060456.11903.qmail@web2307.mail.yahoo.co.jp>
Received: from [150.87.248.20] by web2307.mail.yahoo.co.jp via HTTP; Wed, 24 Sep 2003 15:04:56 JST
Date: Wed, 24 Sep 2003 15:04:56 +0900 (JST)
From: =?ISO-2022-JP?B?GyRCOXVERRsoQiAbJEI0cExvGyhC?= 
	<mips4700@yahoo.co.jp>
Subject: mips inline asm question
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Return-Path: <mips4700@yahoo.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3284
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mips4700@yahoo.co.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 680
Lines: 29

Hi, all;

The following code is from
linux-2.4.20/include/asm-mips/mipsregs.h.
Could anyone tell how the difference between %z0 ("Jr")
and %0 ("r") is?
I compiled this code and deassemble the object, but I
can't find any 
difference with my toolchains(gcc-2.95.3, binutils-2.11).

static inline void set_context(unsigned long val)
{
        __asm__ __volatile__(
                ".set push\n\t"
                ".set reorder\n\t"
                "mtc0 %z0, $4\n\t"
                ".set pop"
                : : "Jr" (val));
}

Thanks in advance
mips4700


__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/


From ralf@linux-mips.org Wed Sep 24 07:22:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 07:22:44 +0100 (BST)
Received: from ftp.linux-mips.org ([IPv6:::ffff:62.254.210.162]:10715 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225406AbTIXGWm>; Wed, 24 Sep 2003 07:22:42 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8O6MBXP025207;
	Tue, 23 Sep 2003 23:22:11 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8O6MAA9025206;
	Tue, 23 Sep 2003 23:22:10 -0700
Date: Tue, 23 Sep 2003 23:22:09 -0700
From: Ralf Baechle <ralf@linux-mips.org>
To: ?$B9uDE ?$B4pLo <mips4700@yahoo.co.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: mips inline asm question
Message-ID: <20030924062209.GA24923@linux-mips.org>
References: <20030924060456.11903.qmail@web2307.mail.yahoo.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030924060456.11903.qmail@web2307.mail.yahoo.co.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3285
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 867
Lines: 26

On Wed, Sep 24, 2003 at 03:04:56PM +0900, ?$B9uDE ?$B4pLo wrote:

> The following code is from
> linux-2.4.20/include/asm-mips/mipsregs.h.
> Could anyone tell how the difference between %z0 ("Jr")
> and %0 ("r") is?
> I compiled this code and deassemble the object, but I
> can't find any 
> difference with my toolchains(gcc-2.95.3, binutils-2.11).
> 
> static inline void set_context(unsigned long val)
> {
>         __asm__ __volatile__(
>                 ".set push\n\t"
>                 ".set reorder\n\t"
>                 "mtc0 %z0, $4\n\t"
>                 ".set pop"
>                 : : "Jr" (val));
> }

%z0 is just like %0 except if %0 has the value of 0 the compiler will insert
register $0.  "Jr" mean the compiler can either use a register or the
constant zero.  Both combined mean the compiler will not waste a real
register but use $zero.

  Ralf

From ralf@linux-mips.org Wed Sep 24 07:29:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 07:29:46 +0100 (BST)
Received: from ftp.linux-mips.org ([IPv6:::ffff:62.254.210.162]:13789 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225406AbTIXG3n>; Wed, 24 Sep 2003 07:29:43 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8O6TDXP025255;
	Tue, 23 Sep 2003 23:29:13 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8O6TBtR025254;
	Tue, 23 Sep 2003 23:29:11 -0700
Date: Tue, 23 Sep 2003 23:29:11 -0700
From: Ralf Baechle <ralf@linux-mips.org>
To: Chris Dearman <chris@mips.com>
Cc: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>,
	linux-mips@linux-mips.org
Subject: Re: list archive
Message-ID: <20030924062911.GB24923@linux-mips.org>
References: <20030919131724.GA26606@icm.edu.pl> <Pine.GSO.3.96.1030919153437.9134E-100000@delta.ds2.pg.gda.pl> <20030919140142.GA28087@icm.edu.pl> <3F6EBFCC.6090203@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F6EBFCC.6090203@mips.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3286
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 792
Lines: 18

On Mon, Sep 22, 2003 at 10:24:28AM +0100, Chris Dearman wrote:

> Dominik 'Rathann' Mierzejewski wrote:
> >Yes, I see it now, thanks. But I was counting on an online and searchable
> >archive.
> >
>   There's the "Mailing List Archives" 
> http://marc.theaimsgroup.com/?l=linux-mips but it is missing Aug02-June03.
>   I think Ralf has been working on a web interface to the mail 
> archives, but I'm not sure if it's ready for the big time yet. Ralf...?

There's still a few small kinks.  We still have the traditional mbox
archives on the ftp server but now also on www.linux-mips.org/archives
html archives which are fully searchable.  There are still a few bugs
but certainly that archives is very usable; it's updated every few hours
only may lag a bit behind the mbox archives.

  Ralf

From ralf@linux-mips.org Wed Sep 24 07:37:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 07:37:18 +0100 (BST)
Received: from ftp.linux-mips.org ([IPv6:::ffff:62.254.210.162]:25055 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225406AbTIXGhQ>; Wed, 24 Sep 2003 07:37:16 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8O6WpXP025293;
	Tue, 23 Sep 2003 23:32:51 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8O6WoSU025292;
	Tue, 23 Sep 2003 23:32:50 -0700
Date: Tue, 23 Sep 2003 23:32:50 -0700
From: Ralf Baechle <ralf@linux-mips.org>
To: Richard van den Berg <ravdberg@inter.NL.net>
Cc: linux-mips@linux-mips.org
Subject: Re: list archive
Message-ID: <20030924063250.GC24923@linux-mips.org>
References: <20030919140142.GA28087@icm.edu.pl> <Pine.LNX.4.21.0309221728370.23229-100000@whale.dutch.mountain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0309221728370.23229-100000@whale.dutch.mountain>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3287
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 955
Lines: 22

On Mon, Sep 22, 2003 at 05:35:38PM +0200, Richard van den Berg wrote:

> > > > I've just got my first Indy box running Linux. And so, to avoid annoying
> > > > you by asking stupid newbie questions I'll ask only one: where can I
> > > > find this list's archives? Searching google for
> > > > "linux-mips@linux-mips.org archive" doesn't yield anything of interest.
> > > 
> > >  See "http://www.linux-mips.org/mail.html" (the first page reported by
> > > Google ;-) ).
> > 
> > Yes, I see it now, thanks. But I was counting on an online and searchable
> > archive.
> 
> There was an online, but not searchable archive, however I discovered that
> the plug has been pulled. Anyone with 20 MB space for the fnet archive
> in html format I collected since june 1998 until the list ended august 
> 2002 is welcome.

I've cleaned the entire FNet list from spam, duplicates, stupid test mails
and put them online into the same place as the other lists.

  Ralf

From ralf@linux-mips.org Wed Sep 24 07:48:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 07:48:06 +0100 (BST)
Received: from ftp.linux-mips.org ([IPv6:::ffff:62.254.210.162]:31969 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225406AbTIXGsE>; Wed, 24 Sep 2003 07:48:04 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8O6lrXP025405;
	Tue, 23 Sep 2003 23:47:54 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8O6lrVX025404;
	Tue, 23 Sep 2003 23:47:53 -0700
Date: Tue, 23 Sep 2003 23:47:53 -0700
From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: "Finney, Steve" <Steve.Finney@SpirentCom.COM>,
	linux-mips@linux-mips.org
Subject: Re: User-mode drivers and TLB
Message-ID: <20030924064753.GA8974@linux-mips.org>
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB750@iris.adtech-inc.com> <16240.12304.556561.464629@gladsmuir.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16240.12304.556561.464629@gladsmuir.mips.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3288
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Sep 23, 2003 at 12:35:44PM +0100, Dominic Sweetman wrote:

> As usual, I guess the first thing is to try doing it the standard way
> and then try to measure how much time is being spent in extra TLB misses
> generated by your application.  Some MIPS CPUs have "performance
> counters" which might be able to count TLB misses, but you'll more
> likely have to instrument the TLB miss code.
> 
> If it does turn out that TLB replacement is a big drain:
>
> Most MIPS CPU hardware allows you to map large chunks of memory with a
> single TLB entry: often up to 16Mbytes at a time.  But I don't know
> how you'd persuade Linux how to do that.

As an indication at how effective large pagesize support can be for
applications, take a look at the two USENIX 98 papers titled "General
Purpose Operating System Support for Multiple Page Sizes" by SGI about
IRIX and the "Implementation of Multiple Page Size support in HP-UX"
presented on the same.  Given that we have what QED once called the
slowest TLB reload handler they've even seen the impact could be even
stronger than demonstrated in these two papers.  The implementation
described has been condemened by Linus as stupid and unacceptable.  I
expect a conceptually different optmization on MIPS late this year.

In any case the paper show how costly TLB exception handlers can be;
the reason why I yell at about everybody who's mentioning the phrase
"wired tlb entries".

For the time being Linux has large page support for the kernel - read
KSEG0 / KSEGX.  Another optimization is also the use of the global bit
for all kernel mappings and for 2.6 support for hugetlbfs on MIPS should
also be fairly easy.

Btw, again and again the MIPS r4k-style TLBs are a bit of a pain because
each entry maps a pair of pages which share some of their attributes ...

  Ralf

From gill.robles@exterity.co.uk Wed Sep 24 08:31:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 08:31:28 +0100 (BST)
Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:193.195.124.4]:31986 "EHLO
	exterity-serv1.exterity.co.uk") by linux-mips.org with ESMTP
	id <S8225406AbTIXHbZ>; Wed, 24 Sep 2003 08:31:25 +0100
Received: from gillpc ([194.168.0.67]) by exterity-serv1.exterity.co.uk with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 24 Sep 2003 08:31:33 +0100
From: "Gill" <gill.robles@exterity.co.uk>
To: <linux-mips@linux-mips.org>
Subject: Page fault question
Date: Wed, 24 Sep 2003 08:36:38 +0100
Organization: Exterity
Message-ID: <000901c3826e$9703adc0$4300a8c2@gillpc>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000A_01C38276.F8C815C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 24 Sep 2003 07:31:33.0718 (UTC) FILETIME=[E12A0760:01C3826D]
Return-Path: <gill.robles@exterity.co.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3289
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gill.robles@exterity.co.uk
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C38276.F8C815C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello -

=20

I'm currently porting vmlinux from NEC's EMMA2L platform to EMMA2.  The
problem I'm having is that linux hangs when it attempts to do its first =
page
fault: the page fault handler is successfully called, the call to
handle_mm_fault returns 2 (major fault).but then code execution appears =
to
just stop.  Linux is not completely dead, however - it still responds to =
a
timer interrupt.

=20

As the code for handling page faults is standard code, and TLB hardware
should be the same on EMMA2 as on EMMA2L (where it works!), I don't
understand what's gone wrong!  Does anyone have any ideas?

=20

Thanks for your help,

=20

=20

Gill


------=_NextPart_000_000A_01C38276.F8C815C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello &#8211;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I&#8217;m currently porting vmlinux from NEC&#8217;s =
EMMA2L
platform to EMMA2.&nbsp; The problem I&#8217;m having is that linux =
hangs when
it attempts to do its first page fault: the page fault handler is =
successfully
called, the call to handle_mm_fault returns 2 (major fault)&#8230;but =
then code
execution appears to just stop.&nbsp; Linux is not completely dead, =
however &#8211;
it still responds to a timer interrupt.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As the code for handling page faults is standard =
code, and
TLB hardware should be the same on EMMA2 as on EMMA2L (where it works!), =
I don&#8217;t
understand what&#8217;s gone wrong!&nbsp; Does anyone have any =
ideas?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks for your help,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Gill</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000A_01C38276.F8C815C0--


From rathann@icm.edu.pl Wed Sep 24 09:28:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 09:28:41 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:52834 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225460AbTIXI2g>;
	Wed, 24 Sep 2003 09:28:36 +0100
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.5/icm) with ESMTP id h8O8SRpU023322
	for <linux-mips@linux-mips.org>; Wed, 24 Sep 2003 10:28:28 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1A250a-0005bg-00
	for <linux-mips@linux-mips.org>; Wed, 24 Sep 2003 10:28:24 +0200
Date: Wed, 24 Sep 2003 10:28:19 +0200
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: list archive
Message-ID: <20030924082818.GA21504@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030919131724.GA26606@icm.edu.pl> <Pine.GSO.3.96.1030919153437.9134E-100000@delta.ds2.pg.gda.pl> <20030919140142.GA28087@icm.edu.pl> <3F6EBFCC.6090203@mips.com> <20030924062911.GB24923@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030924062911.GB24923@linux-mips.org>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3290
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips

On Tue, Sep 23, 2003 at 11:29:11PM -0700, Ralf Baechle wrote:
[...]
> now also on www.linux-mips.org/archives
> html archives which are fully searchable.

Excellent! Thank you.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

From guangxing@ict.ac.cn Wed Sep 24 09:29:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 09:29:16 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:26244 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225460AbTIXI3L> convert rfc822-to-8bit;
	Wed, 24 Sep 2003 09:29:11 +0100
Received: (qmail 16026 invoked from network); 24 Sep 2003 08:13:21 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 24 Sep 2003 08:13:21 -0000
From: "Guangxing Zhang" <guangxing@ict.ac.cn>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>,
 angela <jhyang@ict.ac.cn>
Subject: help, question on pci communication!
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Wed, 24 Sep 2003 16:29:32 +0800
Message-Id: <20030924082911Z8225460-1272+6248@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3291
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips

Hi, Fuxin and everyone see this mail,
    In linux world ,newbies always like to ask and the veterans will always be enthusiastic.:)~~
    Now there is a "ask", of course i am a newbie. 
    Follow is the  architecture  which we are working on.
    Now i want to transfer the data from the "sb1250" to mcp750 through the PCI bus with the help of 21555 bridge.
I want to implement it in kernel module.Although knowing "use the force ,read source",but i really do not know
how and where to begin.
    Is there any advice on it ? How to implement the communication through PCI (or PCI-to-PCI bridge) in kernel 
moudle?
    Any help will be appreciated!Thank in advance!
  
                      -------------
	                  |  MCP 750  |  (Power PC)
                      -------------
                            |
¡¡	    -------------------------------------------CPCI
                         |
             ---------------|--------------------------------    
             |      --------|-----                         |
             |      |Intel 21555 |(PCI-TO-PCI Bridge)      |
             |      --------------                         |
             |        |                					   |	
             |      --------(PCI bus)					   |
			 |          |                                  |
			 |       --------                              |
			 |		 |SB1250|(CPU)                         |
			 |       --------                              |
             ----------------------------------------------           
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
			    2003-09-24 16:03:04
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡




From rathann@icm.edu.pl Wed Sep 24 10:28:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 10:28:54 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:14875 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225473AbTIXJ2t>;
	Wed, 24 Sep 2003 10:28:49 +0100
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.5/icm) with ESMTP id h8O9SbpU028103
	for <linux-mips@linux-mips.org>; Wed, 24 Sep 2003 11:28:39 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1A25wn-0006Ek-00
	for <linux-mips@linux-mips.org>; Wed, 24 Sep 2003 11:28:33 +0200
Date: Wed, 24 Sep 2003 11:28:28 +0200
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: [BUG?][linux_2_4] Oops in ip22-berr.c
Message-ID: <20030924092828.GB21504@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC"
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3292
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips


--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello.

I've succesfully compiled the 2.4 kernel from linux-mips CVS,
but it oopses at boot time. I'll try to copy and paste by hand
from the console:
[...]
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 Sep 19 2003 at 15:37:47
scsi0: SGI WD93
  sending SDTR 010301410csync_xfer=3c<3>MC Bus Error
GIO Error 0x400:<TIME > @ 0x08292e3000
Instruction bus error, epc == 880d1184, ra == 880d1168
Oops in ip22-berr.c::ip22_be_interrupt, line 98:
$0 : 00000000 1000cc00 00000000 00000002 00000008 bfbc4007 00000100 88155cc8
$8 : 09219e98 892c8200 8921ac7c 89219d98 00000100 00000000 881a7e58 89212480
$16: 1000cc01 00000001 00000019 88155ea8 881788a4 887fe5b4 00000031 9fc4b080
$24: ffffffff 00000000                   88154000 88155e28 00000001 880d1168
Hi : 00000000
Lo : 00000100
epc  : 880d1184    Not tainted
Status: 1000cc03
Cause : 00004000
Process swapper (pid:0, stackpage: 88154000)
Stack:    00000100 00000000 88003048 8880e554 881ad480 88003060 00000001
 881690a0 fffffffe 1000cc00 88168320 00000019 881ad480 fffffffb 88155ea8
 88003334 00000031 9fc4b080 881788a4 8880e554 00000400 8880e554 887fe5b4
 00000000 887fe8bc 880a3e0c 00010f00 00000000 88155f40 1000cc01 880a4014
 880a3ffc 00000000 00000622 00000001 88154000 00010f00 00000000 00000000
 881b0000 ...
Call Trace:   [<88003048>] [<88003060>] [<88003334>] [<880a3e0c>] [<880a4014>]
 [<880a3ffc>] [<88002db0>] [<88003f2c>] [<88002db4>] [<8812972c>] [<8800278c>]
 [<88129708>]

Code: 02018025  40906000  00000040 <00000040> 00000040  8fbf0014  8fb00010  03e00008  27bd0018
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

That's about it. The hardware is SGI Indy IP22 R4600@133MHz 64MB RAM
with the standard built-in graphics and sound. Kernel compiled with
Debian 3.0's gcc-2.95.4. I've since then upgraded Woody to
testing/Sarge. Debian distro kernel-2.4.19 from Sarge boots fine.
If there's any more info you need, let me know.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=".config"

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_MIPS=y
CONFIG_MIPS32=y
# CONFIG_MIPS64 is not set

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Machine selection
#
# CONFIG_ACER_PICA_61 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_MIPS_MTX1 is not set
# CONFIG_COGENT_CSB250 is not set
# CONFIG_BAGET_MIPS is not set
# CONFIG_CASIO_E55 is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_HP_LASERJET is not set
# CONFIG_IBM_WORKPAD is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MAGNUM_4000 is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_NEC_OSPREY is not set
# CONFIG_NEC_EAGLE is not set
# CONFIG_OLIVETTI_M700 is not set
# CONFIG_NINO is not set
CONFIG_SGI_IP22=y
# CONFIG_SGI_IP27 is not set
# CONFIG_SIBYTE_SB1xxx_SOC is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TANBAC_TB0226 is not set
# CONFIG_TANBAC_TB0229 is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
# CONFIG_VICTOR_MPC30X is not set
# CONFIG_ZAO_CAPCELLA is not set
# CONFIG_HIGHMEM is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARC32=y
CONFIG_ARC_PROMLIB=y
CONFIG_BOARD_SCACHE=y
CONFIG_BOOT_ELF32=y
# CONFIG_SWAP_IO_SPACE_W is not set
CONFIG_SWAP_IO_SPACE_L=y
CONFIG_IRQ_CPU=y
CONFIG_L1_CACHE_SHIFT=5
CONFIG_NEW_TIME_C=y
CONFIG_NONCOHERENT_IO=y
CONFIG_PC_KEYB=y
# CONFIG_MIPS_AU1000 is not set

#
# CPU selection
#
# CONFIG_CPU_MIPS32 is not set
# CONFIG_CPU_MIPS64 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
CONFIG_CPU_R4X00=y
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_SB1 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
CONFIG_CPU_HAS_SYNC=y

#
# General setup
#
# CONFIG_CPU_LITTLE_ENDIAN is not set
CONFIG_BINFMT_IRIX=y
CONFIG_ARC_CONSOLE=y
# CONFIG_IP22_EISA is not set
CONFIG_NET=y
# CONFIG_PCI is not set
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_TC is not set
# CONFIG_MCA is not set
# CONFIG_SBUS is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
# CONFIG_HOTPLUG_PCI is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_MIPS32_COMPAT is not set
# CONFIG_MIPS32_O32 is not set
# CONFIG_MIPS32_N32 is not set
# CONFIG_BINFMT_ELF32 is not set
CONFIG_BINFMT_MISC=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_BLK_STATS=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# 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

#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set

#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_IDE_MODES is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
# CONFIG_CHR_DEV_ST is not set
# 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
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
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_AIC79XX 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_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_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=m

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set

#
# 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=m
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_PHILIPSPAR is not set
# CONFIG_I2C_ELV is not set
# CONFIG_I2C_VELLEMAN is not set
# CONFIG_SCx200_I2C is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_ALGOPCF is not set
CONFIG_I2C_ALGO_SGI=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m

#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set
# CONFIG_MK712_MOUSE is not set

#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
# CONFIG_IPMI_KCS is not set
# CONFIG_IPMI_WATCHDOG is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_PCWATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I810_TCO is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_SCx200_WDT is not set
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_WDT is not set
# CONFIG_WDTPCI is not set
# CONFIG_MACHZ_WDT is not set
CONFIG_INDYDOG=m
# CONFIG_AMD7XX_TCO is not set
# CONFIG_SCx200_GPIO is not set
# CONFIG_AMD_PM768 is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_MIPS_RTC is not set
CONFIG_SGI_DS1286=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set

#
# File systems
#
CONFIG_QUOTA=y
# CONFIG_QFMT_V2 is not set
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=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 is not set
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# 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_NFS_DIRECTIO is not set
# CONFIG_ROOT_NFS is not set
# CONFIG_NFSD is not set
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=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_EFI_PARTITION is not set
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
# 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=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
# 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=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y
# CONFIG_I2C_PARPORT is not set
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
CONFIG_VIDEO_VINO=m
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_ZORAN_BUZ is not set
# CONFIG_VIDEO_ZORAN_DC10 is not set
# CONFIG_VIDEO_ZORAN_LML33 is not set
# CONFIG_VIDEO_ZR36120 is not set
# CONFIG_VIDEO_MEYE is not set

#
# Radio Adapters
#
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_MIROPCM20 is not set

#
# Console drivers
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_SGI_NEWPORT_CONSOLE=y
CONFIG_FONT_8x16=y
CONFIG_DUMMY_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set

#
# Frame-buffer support
#
# CONFIG_FB is not set

#
# Sound
#
CONFIG_SOUND=m
# CONFIG_SOUND_ALI5455 is not set
# 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_FORTE 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

#
# USB support
#
# CONFIG_USB is not set

#
# Bluetooth support
#
# CONFIG_BLUEZ is not set

#
# Kernel hacking
#
# CONFIG_CROSSCOMPILE is not set
# CONFIG_RUNTIME_DEBUG is not set
# CONFIG_KGDB is not set
# CONFIG_GDB_CONSOLE is not set
# CONFIG_DEBUG_INFO is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_MIPS_UNCACHED is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m

--wRRV7LY7NUeQGEoC--

From ladis@linux-mips.org Wed Sep 24 10:36:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 10:36:56 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@3ffe:8260:2028:fffe::1)) by linux-mips.org
	id <S8225473AbTIXJgy>; Wed, 24 Sep 2003 10:36:54 +0100
Date: Wed, 24 Sep 2003 10:36:54 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: linux-mips@linux-mips.org
Cc: Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>
Subject: Re: [BUG?][linux_2_4] Oops in ip22-berr.c
Message-ID: <20030924103654.A15492@linux-mips.org>
References: <20030924092828.GB21504@icm.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030924092828.GB21504@icm.edu.pl>; from rathann@icm.edu.pl on Wed, Sep 24, 2003 at 11:28:28AM +0200
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3293
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Sep 24, 2003 at 11:28:28AM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Hello.
> 
> I've succesfully compiled the 2.4 kernel from linux-mips CVS,
> but it oopses at boot time. I'll try to copy and paste by hand
> from the console:
> [...]
> 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 Sep 19 2003 at 15:37:47
> scsi0: SGI WD93
>   sending SDTR 010301410csync_xfer=3c<3>MC Bus Error
> GIO Error 0x400:<TIME > @ 0x08292e3000
> Instruction bus error, epc == 880d1184, ra == 880d1168
> Oops in ip22-berr.c::ip22_be_interrupt, line 98:
> $0 : 00000000 1000cc00 00000000 00000002 00000008 bfbc4007 00000100 88155cc8
> $8 : 09219e98 892c8200 8921ac7c 89219d98 00000100 00000000 881a7e58 89212480
> $16: 1000cc01 00000001 00000019 88155ea8 881788a4 887fe5b4 00000031 9fc4b080
> $24: ffffffff 00000000                   88154000 88155e28 00000001 880d1168
> Hi : 00000000
> Lo : 00000100
> epc  : 880d1184    Not tainted
> Status: 1000cc03
> Cause : 00004000
> Process swapper (pid:0, stackpage: 88154000)
> Stack:    00000100 00000000 88003048 8880e554 881ad480 88003060 00000001
>  881690a0 fffffffe 1000cc00 88168320 00000019 881ad480 fffffffb 88155ea8
>  88003334 00000031 9fc4b080 881788a4 8880e554 00000400 8880e554 887fe5b4
>  00000000 887fe8bc 880a3e0c 00010f00 00000000 88155f40 1000cc01 880a4014
>  880a3ffc 00000000 00000622 00000001 88154000 00010f00 00000000 00000000
>  881b0000 ...
> Call Trace:   [<88003048>] [<88003060>] [<88003334>] [<880a3e0c>] [<880a4014>]
>  [<880a3ffc>] [<88002db0>] [<88003f2c>] [<88002db4>] [<8812972c>] [<8800278c>]
>  [<88129708>]
> 
> Code: 02018025  40906000  00000040 <00000040> 00000040  8fbf0014  8fb00010  03e00008  27bd0018
> Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing
> 
> That's about it. The hardware is SGI Indy IP22 R4600@133MHz 64MB RAM
> with the standard built-in graphics and sound. Kernel compiled with
> Debian 3.0's gcc-2.95.4. I've since then upgraded Woody to
> testing/Sarge. Debian distro kernel-2.4.19 from Sarge boots fine.
> If there's any more info you need, let me know.

nice to see bus error handler working :-)
please apply following patch:
ftp://ftp.linux-mips.org/pub/linux/mips/people/ladis/sgiwd93.diff

	ladis

From prabhakark@contechsoftware.com Wed Sep 24 10:37:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 10:37:22 +0100 (BST)
Received: from [IPv6:::ffff:203.129.212.34] ([IPv6:::ffff:203.129.212.34]:13838
	"HELO contech.contechsoftware.com") by linux-mips.org with SMTP
	id <S8225476AbTIXJhS>; Wed, 24 Sep 2003 10:37:18 +0100
Received: (from prabhakar [200.1.1.48])
 by contech.contechsoftware.com (SAVSMTP 3.0.0.44) with SMTP id M2003092415145319978
 for <linux-mips@linux-mips.org>; Wed, 24 Sep 2003 15:14:57 +0530
Received: by localhost with Microsoft MAPI; Wed, 24 Sep 2003 15:15:12 -0000
Message-ID: <01C382AE.A6330DF0.prabhakark@contechsoftware.com>
From: Prabhakar Kalasani <prabhakark@contechsoftware.com>
Reply-To: "prabhakark@contechsoftware.com" <prabhakark@contechsoftware.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: How to translate Little to Big endian ?
Date: Wed, 24 Sep 2003 15:15:11 -0000
Organization: Contech Software Limited
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Encoding: 9 TEXT
Return-Path: <prabhakark@contechsoftware.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3294
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: prabhakark@contechsoftware.com
Precedence: bulk
X-list: linux-mips

Hi all,
I'm trying to port linux-2.4.21 on CSB250 , which is Au1500 processor based board,
the processor is a Big endian, I have taken PB1500 board as my prototype, but it's used Au1500 Little endian.
anybody could help me out, what are the changes do i need to change to make a Little endian souce into Big endian source.

Is anybody worked on Cogent's CSB250 board till.

Thanks in advance
Prabhakar


From kevink@mips.com Wed Sep 24 11:03:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 11:03:15 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:45473 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225478AbTIXKDN>;
	Wed, 24 Sep 2003 11:03:13 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h8OA0EYY025999;
	Wed, 24 Sep 2003 03:00:14 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA16863;
	Wed, 24 Sep 2003 03:03:24 -0700 (PDT)
Message-ID: <00d301c38283$67145be0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Gill" <gill.robles@exterity.co.uk>, <linux-mips@linux-mips.org>
References: <000901c3826e$9703adc0$4300a8c2@gillpc>
Subject: Re: Page fault question
Date: Wed, 24 Sep 2003 12:05:31 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00CE_01C38294.271C4280"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3295
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_00CE_01C38294.271C4280
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The EMMA2 (uPD61130) uses the NEC Vr4130 core, wheras the EMMA2L =
(uPD61120)
uses a MIPS 4Kc core.  The 4Kc is a MIPS32-compliant core, but the =
Vr41xx family
predates the MIPS32 spec for the MMU interface, and has some significant =
incompatibilities,
mostly due to the fact that the Vr4100's assume a 1K page granularity, =
versus 4K for the 4Kc
and almost all other MIPS processors.  You can't use the same MMU code =
for both chips.
One kernel needs to be configured for a "MIPS32" CPU, the other for =
"R41xx".
  ----- Original Message -----=20
  From: Gill=20
  To: linux-mips@linux-mips.org=20
  Sent: Wednesday, September 24, 2003 9:36 AM
  Subject: Page fault question


  Hello -



  I'm currently porting vmlinux from NEC's EMMA2L platform to EMMA2.  =
The problem I'm having is that linux hangs when it attempts to do its =
first page fault: the page fault handler is successfully called, the =
call to handle_mm_fault returns 2 (major fault).but then code execution =
appears to just stop.  Linux is not completely dead, however - it still =
responds to a timer interrupt.



  As the code for handling page faults is standard code, and TLB =
hardware should be the same on EMMA2 as on EMMA2L (where it works!), I =
don't understand what's gone wrong!  Does anyone have any ideas?



  Thanks for your help,





  Gill

------=_NextPart_000_00CE_01C38294.271C4280
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4919.2200" name=3DGENERATOR>
<STYLE>@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-GB vLink=3Dpurple link=3Dblue bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>The EMMA2 (uPD61130) uses the NEC =
Vr4130 core,=20
wheras the EMMA2L (uPD61120)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>uses a MIPS 4Kc core.&nbsp; The 4Kc is =
a=20
MIPS32-compliant core, but the Vr41xx family</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>predates the MIPS32 spec for the MMU =
interface, and=20
has some significant incompatibilities,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>mostly due to the fact that the =
Vr4100's assume a=20
1K page granularity, versus 4K for the 4Kc</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and almost all other MIPS =
processors.&nbsp; You=20
can't use the same MMU code for both chips.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>One kernel needs to be configured for a =
"MIPS32"=20
CPU, the other for "R41xx".</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dgill.robles@exterity.co.uk=20
  href=3D"mailto:gill.robles@exterity.co.uk">Gill</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dlinux-mips@linux-mips.org=20
  =
href=3D"mailto:linux-mips@linux-mips.org">linux-mips@linux-mips.org</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, September 24, =
2003 9:36=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Page fault =
question</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hello =
=96</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I=92m currently porting =
vmlinux from=20
  NEC=92s EMMA2L platform to EMMA2.&nbsp; The problem I=92m having is =
that linux=20
  hangs when it attempts to do its first page fault: the page fault =
handler is=20
  successfully called, the call to handle_mm_fault returns 2 (major =
fault)=85but=20
  then code execution appears to just stop.&nbsp; Linux is not =
completely dead,=20
  however =96 it still responds to a timer interrupt.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">As the code for handling =
page=20
  faults is standard code, and TLB hardware should be the same on EMMA2 =
as on=20
  EMMA2L (where it works!), I don=92t understand what=92s gone =
wrong!&nbsp; Does=20
  anyone have any ideas?</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks for your=20
  help,</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Gill</SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00CE_01C38294.271C4280--


From rjs@stimpy.fdy2.net Wed Sep 24 15:53:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 15:53:53 +0100 (BST)
Received: from fdy2.demon.co.uk ([IPv6:::ffff:80.177.11.33]:5131 "EHLO
	stimpy.fdy2.net") by linux-mips.org with ESMTP id <S8225519AbTIXOxv>;
	Wed, 24 Sep 2003 15:53:51 +0100
Received: by stimpy.fdy2.net (Postfix, from userid 100)
	id 69C24107; Wed, 24 Sep 2003 15:51:09 +0100 (BST)
From: Robert Swindells <rjs@fdy2.demon.co.uk>
To: linux-mips@linux-mips.org
Subject: Alchemy serial port patch
Message-Id: <20030924145109.69C24107@stimpy.fdy2.net>
Date: Wed, 24 Sep 2003 15:51:09 +0100 (BST)
Return-Path: <rjs@stimpy.fdy2.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3296
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rjs@fdy2.demon.co.uk
Precedence: bulk
X-list: linux-mips


This seems to be needed to build drivers/serial/core.c for Alchemy
CPUs.

Robert Swindells

Index: Kconfig
===================================================================
RCS file: /home/cvs/linux/drivers/serial/Kconfig,v
retrieving revision 1.17
diff -u -r1.17 Kconfig
--- Kconfig     9 Sep 2003 16:41:03 -0000       1.17
+++ Kconfig     24 Sep 2003 14:50:36 -0000
@@ -459,7 +459,7 @@
 
 config SERIAL_CORE
        tristate
-       default m if SERIAL_AMBA!=y && SERIAL_CLPS711X!=y && SERIAL_21285!=y && 
!SERIAL_SA1100 && !SERIAL_ANAKIN && !SERIAL_UART00 && SERIAL_8250!=y && SERIAL_M
UX!=y && !SERIAL_ROCKETPORT && !SERIAL_SUNCORE && !V850E_UART && SERIAL_PMACZILO
G!=y && SERIAL_DZ!=y && SERIAL_IP22_ZILOG!=y || SERIAL_AU1X00!=y && (SERIAL_AMBA
=m || SERIAL_CLPS711X=m || SERIAL_21285=m || SERIAL_8250=m || SERIAL_MUX=m || SE
RIAL98=m || SERIAL_PMACZILOG=m || SERIAL_IP22_ZILOG=m)
+       default m if SERIAL_AMBA!=y && SERIAL_CLPS711X!=y && SERIAL_21285!=y && 
!SERIAL_SA1100 && !SERIAL_ANAKIN && !SERIAL_UART00 && SERIAL_8250!=y && SERIAL_M
UX!=y && !SERIAL_ROCKETPORT && !SERIAL_SUNCORE && !V850E_UART && SERIAL_PMACZILO
G!=y && SERIAL_DZ!=y && SERIAL_IP22_ZILOG!=y && SERIAL_AU1X00!=y && (SERIAL_AMBA
=m || SERIAL_CLPS711X=m || SERIAL_21285=m || SERIAL_8250=m || SERIAL_MUX=m || SE
RIAL98=m || SERIAL_PMACZILOG=m || SERIAL_IP22_ZILOG=m)
        default y if SERIAL_AMBA=y || SERIAL_CLPS711X=y || SERIAL_21285=y || SER
IAL_SA1100 || SERIAL_ANAKIN || SERIAL_UART00 || SERIAL_8250=y || SERIAL_MUX=y ||
 SERIAL_ROCKETPORT || SERIAL_SUNCORE || V850E_UART || SERIAL98=y || SERIAL_PMACZ
ILOG=y || SERIAL_DZ=y || SERIAL_IP22_ZILOG=y || SERIAL_AU1X00=y
 
 config SERIAL_CORE_CONSOLE

From karthik_96cse@yahoo.com Wed Sep 24 16:15:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 16:15:55 +0100 (BST)
Received: from web10106.mail.yahoo.com ([IPv6:::ffff:216.136.130.56]:20389
	"HELO web10106.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225541AbTIXPPx>; Wed, 24 Sep 2003 16:15:53 +0100
Message-ID: <20030924151549.47132.qmail@web10106.mail.yahoo.com>
Received: from [128.107.253.43] by web10106.mail.yahoo.com via HTTP; Wed, 24 Sep 2003 16:15:49 BST
Date: Wed, 24 Sep 2003 16:15:49 +0100 (BST)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: Re: How to translate Little to Big endian ?
To: "prabhakark@contechsoftware.com" <prabhakark@contechsoftware.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <01C382AE.A6330DF0.prabhakark@contechsoftware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3297
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi Prabhakar,

> I'm trying to port linux-2.4.21 on CSB250 , which is
> Au1500 processor based board,
> the processor is a Big endian, I have taken PB1500
> board as my prototype, but it's used Au1500 Little
> endian.
> anybody could help me out, what are the changes do i
> need to change to make a Little endian souce into
> Big endian source.

   Guess you are looking for a library call to do
this.
If i am correct, then htonl function will serve the
purpose.

My $0.02

Thanks,
-karthi
 
> Is anybody worked on Cogent's CSB250 board till.
> 
> Thanks in advance
> Prabhakar
> 
>  

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk

From michael_pruznick@mvista.com Wed Sep 24 16:39:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 16:40:03 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:2806 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225554AbTIXPj4>;
	Wed, 24 Sep 2003 16:39:56 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id IAA09183;
	Wed, 24 Sep 2003 08:39:53 -0700
Message-ID: <3F71BAC8.2B4DCC50@mvista.com>
Date: Wed, 24 Sep 2003 09:39:52 -0600
From: Michael Pruznick <michael_pruznick@mvista.com>
Reply-To: michael_pruznick@mvista.com
Organization: MontaVista
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeffrey Baitis <baitisj@evolution.com>
CC: linux-mips@linux-mips.org
Subject: Re: Toshiba TX4925 experiences wanted
References: <1064281591.25782.255.camel@powerpuff.pas.lab>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <michael_pruznick@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3298
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michael_pruznick@mvista.com
Precedence: bulk
X-list: linux-mips

 > I understand that the Linux MIPS kernel has support for the TX4927. Has
> anyone tried the TX4925 as well? Does Monta Vista's BSP for the 27 work
> for the 25?
The 4927 code will not run on the 4925.  We do have support for the 4925
and one of my many todo items is to get the 4925 stuff into linux-mips
soon.

From lyle@zevion.com Wed Sep 24 17:12:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 17:12:25 +0100 (BST)
Received: from rrcs-central-24-123-115-44.biz.rr.com ([IPv6:::ffff:24.123.115.44]:5760
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225541AbTIXQMW>; Wed, 24 Sep 2003 17:12:22 +0100
Received: from radium ([192.168.0.20])
	by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h8OLJIDW013823;
	Wed, 24 Sep 2003 16:19:19 -0500
From: "Lyle Bainbridge" <lyle@zevion.com>
To: <prabhakark@contechsoftware.com>, <linux-mips@linux-mips.org>
Subject: RE: How to translate Little to Big endian ?
Date: Wed, 24 Sep 2003 11:12:12 -0500
Message-ID: <000001c382b6$9e3b6fe0$1400a8c0@radium>
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.2616
Importance: Normal
In-Reply-To: <01C382AE.A6330DF0.prabhakark@contechsoftware.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <lyle@zevion.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3299
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lyle@zevion.com
Precedence: bulk
X-list: linux-mips

Hi,

I believe that the CSB250 port will support big or small endian. Check
out the latest mips-linux kernel code first (2.4.22 I beleive). Then you
need to use a big endian toolchain.  Mips not Mipsel (ie,
mips-linux-gcc). Then open the arch/mips/defconfig-csb250 file and
modify the CONFIG_CPU_LITTLE_ENDIAN option.  It should be:

CONFIG_CPU_LITTLE_ENDIAN=y

Then continue to build the kernel as you would for little endian. I
think that's all from the kernel standpoint. But, are you using Micromon
to boot the kernel?  By default I think the CSB250 and it's monitor are
built little endian, and you won't be able to use this if you want a BE
kernel.  You need the boot loader to put the Au1500 into BE mode.

Email if you need more details.

Lyle



> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of 
> Prabhakar Kalasani
> Sent: Wednesday, September 24, 2003 10:15 AM
> To: 'linux-mips@linux-mips.org'
> Subject: How to translate Little to Big endian ?
> 
> 
> Hi all,
> I'm trying to port linux-2.4.21 on CSB250 , which is Au1500 
> processor based board, the processor is a Big endian, I have 
> taken PB1500 board as my prototype, but it's used Au1500 
> Little endian. anybody could help me out, what are the 
> changes do i need to change to make a Little endian souce 
> into Big endian source.
> 
> Is anybody worked on Cogent's CSB250 board till.
> 
> Thanks in advance
> Prabhakar
> 


From ppopov@mvista.com Wed Sep 24 18:13:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 18:13:17 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8433 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225567AbTIXRNG>;
	Wed, 24 Sep 2003 18:13:06 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA13905;
	Wed, 24 Sep 2003 10:12:41 -0700
Subject: RE: How to translate Little to Big endian ?
From: Pete Popov <ppopov@mvista.com>
To: Lyle Bainbridge <lyle@zevion.com>, prabhakark@contechsoftware.com
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <000001c382b6$9e3b6fe0$1400a8c0@radium>
References: <000001c382b6$9e3b6fe0$1400a8c0@radium>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1064423814.13802.15.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 24 Sep 2003 10:16:54 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3300
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

Prabhakar,

I recently checked-in a patch for CSB250 support, courtesy of Embedded
Edge.  The port is big endian. I assume you haven't seen the bits
because you haven't pulled the latest bits from the linux-mips tree and
that's why you're trying to port it yourself?

Pete

On Wed, 2003-09-24 at 09:12, Lyle Bainbridge wrote:
> Hi,
> 
> I believe that the CSB250 port will support big or small endian. Check
> out the latest mips-linux kernel code first (2.4.22 I beleive). Then you
> need to use a big endian toolchain.  Mips not Mipsel (ie,
> mips-linux-gcc). Then open the arch/mips/defconfig-csb250 file and
> modify the CONFIG_CPU_LITTLE_ENDIAN option.  It should be:
> 
> CONFIG_CPU_LITTLE_ENDIAN=y
> 
> Then continue to build the kernel as you would for little endian. I
> think that's all from the kernel standpoint. But, are you using Micromon
> to boot the kernel?  By default I think the CSB250 and it's monitor are
> built little endian, and you won't be able to use this if you want a BE
> kernel.  You need the boot loader to put the Au1500 into BE mode.
> 
> Email if you need more details.
> 
> Lyle
> 
> 
> 
> > -----Original Message-----
> > From: linux-mips-bounce@linux-mips.org 
> > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of 
> > Prabhakar Kalasani
> > Sent: Wednesday, September 24, 2003 10:15 AM
> > To: 'linux-mips@linux-mips.org'
> > Subject: How to translate Little to Big endian ?
> > 
> > 
> > Hi all,
> > I'm trying to port linux-2.4.21 on CSB250 , which is Au1500 
> > processor based board, the processor is a Big endian, I have 
> > taken PB1500 board as my prototype, but it's used Au1500 
> > Little endian. anybody could help me out, what are the 
> > changes do i need to change to make a Little endian souce 
> > into Big endian source.
> > 
> > Is anybody worked on Cogent's CSB250 board till.
> > 
> > Thanks in advance
> > Prabhakar
> > 
> 
> 
> 


From invictus_rm@hotmail.com Wed Sep 24 18:45:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 18:45:32 +0100 (BST)
Received: from bay7-f117.bay7.hotmail.com ([IPv6:::ffff:64.4.11.117]:25872
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225567AbTIXRp2>; Wed, 24 Sep 2003 18:45:28 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 24 Sep 2003 10:45:19 -0700
Received: from 203.195.196.66 by by7fd.bay7.hotmail.msn.com with HTTP;
	Wed, 24 Sep 2003 17:45:18 GMT
X-Originating-IP: [203.195.196.66]
X-Originating-Email: [invictus_rm@hotmail.com]
From: "invictus rm" <invictus_rm@hotmail.com>
To: guangxing@ict.ac.cn
Cc: linux-mips@linux-mips.org
Subject: Re: help, question on pci communication!
Date: Wed, 24 Sep 2003 23:15:18 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY7-F117FH0ulWwcRI00008269@hotmail.com>
X-OriginalArrivalTime: 24 Sep 2003 17:45:19.0197 (UTC) FILETIME=[9EDC30D0:01C382C3]
Return-Path: <invictus_rm@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3301
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: invictus_rm@hotmail.com
Precedence: bulk
X-list: linux-mips

hi,

  If the BCM1250 is operating in the device mode in the peripheral slot of 
the CPCI chassis, u need t get the enumeration of the PCI being done from 
MCP 750 right.
  The code for MCP750 alread exists in the linux kernel ( if i remember 
correctly).

U can proceed in the following directions-->
(a) Get the PCI enumeration working properly on the MCP750 ( look at the 
ouput of lspci -vvv to decide whether resource allocation is proper or not) 
. The powerpc provides a fairly comprehensive PCI enumeration code( 
including scanning beyond the bridge).

(b) Once u are able to see ur device in the lspci output on the MCP board , 
u can load the driver ( ur custom driver ) to do the transfer from the 
BCM1250 to MCP and vice versa.

(v) Look at the few PCI based drivers about the way the data transfers is 
handled specially pci_alloc_* / pci_map_*/pci_resource_*.........

Hope this helps




>From: "Guangxing Zhang" <guangxing@ict.ac.cn>
>To: Fuxin Zhang <fxzhang@ict.ac.cn>
>CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>, angela 
><jhyang@ict.ac.cn>
>Subject: help, question on pci communication!
>Date: Wed, 24 Sep 2003 16:29:32 +0800
>
>Hi, Fuxin and everyone see this mail,
>     In linux world ,newbies always like to ask and the veterans will 
>always be enthusiastic.:)~~
>     Now there is a "ask", of course i am a newbie.
>     Follow is the  architecture  which we are working on.
>     Now i want to transfer the data from the "sb1250" to mcp750 through 
>the PCI bus with the help of 21555 bridge.
>I want to implement it in kernel module.Although knowing "use the force 
>,read source",but i really do not know
>how and where to begin.
>     Is there any advice on it ? How to implement the communication through 
>PCI (or PCI-to-PCI bridge) in kernel
>moudle?
>     Any help will be appreciated!Thank in advance!
>
>                       -------------
>	                  |  MCP 750  |  (Power PC)
>                       -------------
>                             |
>¡¡	    -------------------------------------------CPCI
>                          |
>              ---------------|--------------------------------
>              |      --------|-----                         |
>              |      |Intel 21555 |(PCI-TO-PCI Bridge)      |
>              |      --------------                         |
>              |        |                					   |
>              |      --------(PCI bus)					   |
>			 |          |                                  |
>			 |       --------                              |
>			 |		 |SB1250|(CPU)                         |
>			 |       --------                              |
>              ----------------------------------------------
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
>			    2003-09-24 16:03:04
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
>
>
>
>

_________________________________________________________________
Talk to Karthikeyan. Watch his stunning feats. 
http://server1.msn.co.in/sp03/tataracing/index.asp Download images.


From ppopov@mvista.com Wed Sep 24 19:11:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 24 Sep 2003 19:11:21 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:33017 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225577AbTIXSLS>;
	Wed, 24 Sep 2003 19:11:18 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA17265
	for <linux-mips@linux-mips.org>; Wed, 24 Sep 2003 11:11:16 -0700
Subject: Au1k MMC driver
From: Pete Popov <ppopov@mvista.com>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1064427330.13802.32.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 24 Sep 2003 11:15:30 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3302
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips


There were are few people asking for an MMC driver for the Au1k SOC, so
FYI: I uploaded Embedded Edge's new patch that added DMA support to
ftp.linux-mips.org:/pub/linux/mips/people/ppopov. The mips tree does not
have the generic mmc code, which is why I haven't applied the patch to
the tree.

Ralf, any reason why we can't integrated the mmc bits in the tree?

Pete


From guangxing@ict.ac.cn Thu Sep 25 02:41:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 25 Sep 2003 02:41:22 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:30383 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225589AbTIYBlU> convert rfc822-to-8bit;
	Thu, 25 Sep 2003 02:41:20 +0100
Received: (qmail 19816 invoked from network); 25 Sep 2003 01:25:14 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 25 Sep 2003 01:25:14 -0000
From: "Guangxing Zhang" <guangxing@ict.ac.cn>
To: invictus rm <invictus_rm@hotmail.com>
CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>,
 angela <jhyang@ict.ac.cn>,
 Fuxin Zhang <fxzhang@ict.ac.cn>
Subject: Re: Re: help, question on pci communication!
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Thu, 25 Sep 2003 9:41:35 +0800
Message-Id: <20030925014120Z8225589-1272+6410@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3303
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips

Hi, invictus rm
      Thank you very much for your enthusiastic help.
      I think it will be BIG help to me.Thank you.
      There is some thing i want to see your advise and help again. 
      In BCM1250 we run the mips-linux which is customer compiled by us,
and in the  MCP750 there is linux too.What i want to implement is 
transfering  data from BCM1250 to MCP750 through PCI.And using "dmesg" 
i found the following info:(In BCM1250 ,MIPS-LINUX)
---------------------------------------------------------------------------------------------------------------------
	.............
    Jan  1 00:00:11 (none) kernel: Determined physical RAM map: 
    Jan  1 00:00:11 (none) kernel:  memory: 003a7000 @ 00000000 (usable) 
	Jan  1 00:00:11 (none) kernel:  memory: 0f711000 @ 0075c000 (usable) 
	Jan  1 00:00:11 (none) kernel:  memory: 1ffffe00 @ 80000000 (usable) 
	Jan  1 00:00:11 (none) kernel:  memory: 0ffffe00 @ c0000000 (usable) 
	Jan  1 00:00:11 (none) kernel:  memory: 003b5000 @ 003a7000 (reserved) 
	Jan  1 00:00:11 (none) kernel: 2815MB HIGHMEM available. 
	Jan  1 00:00:11 (none) kernel: Initial ramdisk at: 0x803a7000 (3887104 bytes) 
	Jan  1 00:00:11 (none) kernel: On node 0 totalpages: 851967 
	Jan  1 00:00:11 (none) kernel: zone(0): 131072 pages. 
	Jan  1 00:00:11 (none) kernel: zone(1): 0 pages. 
	Jan  1 00:00:11 (none) kernel: zone(2): 720895 pages. 
@	Jan  1 00:00:11 (none) kernel: Kernel command line: root=/dev/ram0 rw bigphysarea=8192 pcisharesize=16 
@	Jan  1 00:00:11 (none) kernel: pcisharemem allocated @ 85800000 
	...................
---------------------------------------------------------------------------------------------------------------------
    In the above lines tagged with @ i notice that there is "bigphysarea=8192 pcisharesize=16",
I have read "kernel/include/linux/mm/bigphysarea.h" ,and known that bigphysarea can be used 
to reserve some amount of physical memory at boot-time for PCI communication.A friend told me
using it is simple ,but he did not tell me kow :-)~(Of course i think he knows it from others).
And i think in my kernel module i can implement it.Without any knowledge on it ,I am swamped now.
Can you give me some info on how to do that ,such as how to use the "bigphysarea"?How the MCP750 
see the "bigphysarea" in BCM1250 and access it (read it)?
    I think i am so avaricious , but i really thirst for the help and advice.
    Thank you again and in advance again.:-)~  


======= invictus_rm@hotmail.com 2003-09-24 23:15:00 WROTE£º=======

>hi,
>
>  If the BCM1250 is operating in the device mode in the peripheral slot of 
>the CPCI chassis, u need t get the enumeration of the PCI being done from 
>MCP 750 right.
>  The code for MCP750 alread exists in the linux kernel ( if i remember 
>correctly).
>
>U can proceed in the following directions-->
>(a) Get the PCI enumeration working properly on the MCP750 ( look at the 
>ouput of lspci -vvv to decide whether resource allocation is proper or not) 
>.. The powerpc provides a fairly comprehensive PCI enumeration code( 
>including scanning beyond the bridge).
>
>(b) Once u are able to see ur device in the lspci output on the MCP board , 
>u can load the driver ( ur custom driver ) to do the transfer from the 
>BCM1250 to MCP and vice versa.
>
>(v) Look at the few PCI based drivers about the way the data transfers is 
>handled specially pci_alloc_* / pci_map_*/pci_resource_*.........
>
>Hope this helps
>
>
>
>
>>From: "Guangxing Zhang" <guangxing@ict.ac.cn>
>>To: Fuxin Zhang <fxzhang@ict.ac.cn>
>>CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>, angela 
>><jhyang@ict.ac.cn>
>>Subject: help, question on pci communication!
>>Date: Wed, 24 Sep 2003 16:29:32 +0800
>>
>>Hi, Fuxin and everyone see this mail,
>>     In linux world ,newbies always like to ask and the veterans will 
>>always be enthusiastic.:)~~
>>     Now there is a "ask", of course i am a newbie.
>>     Follow is the  architecture  which we are working on.
>>     Now i want to transfer the data from the "sb1250" to mcp750 through 
>>the PCI bus with the help of 21555 bridge.
>>I want to implement it in kernel module.Although knowing "use the force 
>>,read source",but i really do not know
>>how and where to begin.
>>     Is there any advice on it ? How to implement the communication through 
>>PCI (or PCI-to-PCI bridge) in kernel
>>moudle?
>>     Any help will be appreciated!Thank in advance!
>>
>>                       -------------
>>	                  |  MCP 750  |  (Power PC)
>>                       -------------
>>                             |
>>¡¡	    -------------------------------------------CPCI
>>                          |
>>              ---------------|--------------------------------
>>              |      --------|-----                         |
>>              |      |Intel 21555 |(PCI-TO-PCI Bridge)      |
>>              |      --------------                         |
>>              |        |                					   |
>>              |      --------(PCI bus)					   |
>>			 |          |                                  |
>>			 |       --------                              |
>>			 |		 |SB1250|(CPU)                         |
>>			 |       --------                              |
>>              ----------------------------------------------
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
>>			    2003-09-24 16:03:04
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
>>
>>
>>
>>
>
>_________________________________________________________________
>Talk to Karthikeyan. Watch his stunning feats. 
>http://server1.msn.co.in/sp03/tataracing/index.asp Download images.

= = = = = = = = = = = = = = = = = = = =
			
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-25 08:43:44



From ravdberg@inter.NL.net Thu Sep 25 04:20:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 25 Sep 2003 04:20:47 +0100 (BST)
Received: from altrade.nijmegen.internl.net ([IPv6:::ffff:217.149.192.18]:57316
	"EHLO altrade.nijmegen.internl.net") by linux-mips.org with ESMTP
	id <S8225296AbTIYDUh>; Thu, 25 Sep 2003 04:20:37 +0100
Received: from whale.dutch.mountain by altrade.nijmegen.internl.net
	via 1Cust186.tnt29.rtm1.nld.da.uu.net [213.116.152.186] with ESMTP for <linux-mips@linux-mips.org>
	id h8P3KZE8002173 (8.12.10/2.04); Thu, 25 Sep 2003 05:20:35 +0200 (MET DST)
Received: from (locally authorised broken client using invalid hostname!) localhost (really [127.0.0.1]) by whale.dutch.mountain
	via in.smtpd with esmtp (ident ravdberg using rfc1413)
	id <m1A2FP4-000HEpC@whale.dutch.mountain> (Debian Smail3.2.0.114)
	Wed, 24 Sep 2003 21:34:22 +0200 (CEST) 
Date: Wed, 24 Sep 2003 21:34:22 +0200 (CEST)
From: Richard van den Berg <ravdberg@inter.NL.net>
X-Sender: ravdberg@whale.dutch.mountain
To: linux-mips@linux-mips.org
Subject: Re: list archive
In-Reply-To: <20030924063250.GC24923@linux-mips.org>
Message-ID: <Pine.LNX.4.21.0309242132430.9676-100000@whale.dutch.mountain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ravdberg@inter.NL.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3304
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ravdberg@inter.NL.net
Precedence: bulk
X-list: linux-mips

On Wed, 24 Sep 2003, Ralf Baechle wrote:

> I've cleaned the entire FNet list from spam, duplicates, stupid test mails
> and put them online into the same place as the other lists.

Thanks! Mail archive link on my website points to that location.

Richard


From invictus_rm@hotmail.com Thu Sep 25 15:31:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 25 Sep 2003 15:31:46 +0100 (BST)
Received: from bay7-f20.bay7.hotmail.com ([IPv6:::ffff:64.4.11.20]:62731 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225379AbTIYObl>;
	Thu, 25 Sep 2003 15:31:41 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 25 Sep 2003 07:31:33 -0700
Received: from 67.89.219.146 by by7fd.bay7.hotmail.msn.com with HTTP;
	Thu, 25 Sep 2003 14:31:33 GMT
X-Originating-IP: [67.89.219.146]
X-Originating-Email: [invictus_rm@hotmail.com]
From: "invictus rm" <invictus_rm@hotmail.com>
To: guangxing@ict.ac.cn
Cc: linux-mips@linux-mips.org
Subject: Re: Re: help, question on pci communication!
Date: Thu, 25 Sep 2003 20:01:33 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY7-F204nyQ7AjUbnd0001abab@hotmail.com>
X-OriginalArrivalTime: 25 Sep 2003 14:31:33.0475 (UTC) FILETIME=[B7CD8B30:01C38371]
Return-Path: <invictus_rm@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3305
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: invictus_rm@hotmail.com
Precedence: bulk
X-list: linux-mips

http://www.xml.com/ldd/chapter/book/ch13.html
search for ioermap in this web page

hope this helps

rm


>From: "Guangxing Zhang" <guangxing@ict.ac.cn>
>To: invictus rm <invictus_rm@hotmail.com>
>CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>, angela 
><jhyang@ict.ac.cn>, Fuxin Zhang <fxzhang@ict.ac.cn>
>Subject: Re: Re: help, question on pci communication!
>Date: Thu, 25 Sep 2003 9:41:35 +0800
>
>Hi, invictus rm
>       Thank you very much for your enthusiastic help.
>       I think it will be BIG help to me.Thank you.
>       There is some thing i want to see your advise and help again.
>       In BCM1250 we run the mips-linux which is customer compiled by us,
>and in the  MCP750 there is linux too.What i want to implement is
>transfering  data from BCM1250 to MCP750 through PCI.And using "dmesg"
>i found the following info:(In BCM1250 ,MIPS-LINUX)
>---------------------------------------------------------------------------------------------------------------------
>.............
>     Jan  1 00:00:11 (none) kernel: Determined physical RAM map:
>     Jan  1 00:00:11 (none) kernel:  memory: 003a7000 @ 00000000 (usable)
>Jan  1 00:00:11 (none) kernel:  memory: 0f711000 @ 0075c000 (usable)
>Jan  1 00:00:11 (none) kernel:  memory: 1ffffe00 @ 80000000 (usable)
>Jan  1 00:00:11 (none) kernel:  memory: 0ffffe00 @ c0000000 (usable)
>Jan  1 00:00:11 (none) kernel:  memory: 003b5000 @ 003a7000 (reserved)
>Jan  1 00:00:11 (none) kernel: 2815MB HIGHMEM available.
>Jan  1 00:00:11 (none) kernel: Initial ramdisk at: 0x803a7000 (3887104 
>bytes)
>Jan  1 00:00:11 (none) kernel: On node 0 totalpages: 851967
>Jan  1 00:00:11 (none) kernel: zone(0): 131072 pages.
>Jan  1 00:00:11 (none) kernel: zone(1): 0 pages.
>Jan  1 00:00:11 (none) kernel: zone(2): 720895 pages.
>@ Jan  1 00:00:11 (none) kernel: Kernel command line: root=/dev/ram0 rw 
>bigphysarea=8192 pcisharesize=16
>@ Jan  1 00:00:11 (none) kernel: pcisharemem allocated @ 85800000
>...................
>---------------------------------------------------------------------------------------------------------------------
>     In the above lines tagged with @ i notice that there is 
>"bigphysarea=8192 pcisharesize=16",
>I have read "kernel/include/linux/mm/bigphysarea.h" ,and known that 
>bigphysarea can be used
>to reserve some amount of physical memory at boot-time for PCI 
>communication.A friend told me
>using it is simple ,but he did not tell me kow :-)~(Of course i think he 
>knows it from others).
>And i think in my kernel module i can implement it.Without any knowledge on 
>it ,I am swamped now.
>Can you give me some info on how to do that ,such as how to use the 
>"bigphysarea"?How the MCP750
>see the "bigphysarea" in BCM1250 and access it (read it)?
>     I think i am so avaricious , but i really thirst for the help and 
>advice.
>     Thank you again and in advance again.:-)~
>
>
>======= invictus_rm@hotmail.com 2003-09-24 23:15:00 WROTE£º=======
>
> >hi,
> >
> >  If the BCM1250 is operating in the device mode in the peripheral slot 
>of
> >the CPCI chassis, u need t get the enumeration of the PCI being done from
> >MCP 750 right.
> >  The code for MCP750 alread exists in the linux kernel ( if i remember
> >correctly).
> >
> >U can proceed in the following directions-->
> >(a) Get the PCI enumeration working properly on the MCP750 ( look at the
> >ouput of lspci -vvv to decide whether resource allocation is proper or 
>not)
> >.. The powerpc provides a fairly comprehensive PCI enumeration code(
> >including scanning beyond the bridge).
> >
> >(b) Once u are able to see ur device in the lspci output on the MCP board 
>,
> >u can load the driver ( ur custom driver ) to do the transfer from the
> >BCM1250 to MCP and vice versa.
> >
> >(v) Look at the few PCI based drivers about the way the data transfers is
> >handled specially pci_alloc_* / pci_map_*/pci_resource_*.........
> >
> >Hope this helps
> >
> >
> >
> >
> >>From: "Guangxing Zhang" <guangxing@ict.ac.cn>
> >>To: Fuxin Zhang <fxzhang@ict.ac.cn>
> >>CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>, angela
> >><jhyang@ict.ac.cn>
> >>Subject: help, question on pci communication!
> >>Date: Wed, 24 Sep 2003 16:29:32 +0800
> >>
> >>Hi, Fuxin and everyone see this mail,
> >>     In linux world ,newbies always like to ask and the veterans will
> >>always be enthusiastic.:)~~
> >>     Now there is a "ask", of course i am a newbie.
> >>     Follow is the  architecture  which we are working on.
> >>     Now i want to transfer the data from the "sb1250" to mcp750 through
> >>the PCI bus with the help of 21555 bridge.
> >>I want to implement it in kernel module.Although knowing "use the force
> >>,read source",but i really do not know
> >>how and where to begin.
> >>     Is there any advice on it ? How to implement the communication 
>through
> >>PCI (or PCI-to-PCI bridge) in kernel
> >>moudle?
> >>     Any help will be appreciated!Thank in advance!
> >>
> >>                       -------------
> >>                   |  MCP 750  |  (Power PC)
> >>                       -------------
> >>                             |
> >>¡¡     -------------------------------------------CPCI
> >>                          |
> >>              ---------------|--------------------------------
> >>              |      --------|-----                         |
> >>              |      |Intel 21555 |(PCI-TO-PCI Bridge)      |
> >>              |      --------------                         |
> >>              |        |                        |
> >>              |      --------(PCI bus)        |
> >>    |          |                                  |
> >>    |       --------                              |
> >>    |   |SB1250|(CPU)                         |
> >>    |       --------                              |
> >>              ----------------------------------------------
> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
> >>       2003-09-24 16:03:04
> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
> >>
> >>
> >>
> >>
> >
> >_________________________________________________________________
> >Talk to Karthikeyan. Watch his stunning feats.
> >http://server1.msn.co.in/sp03/tataracing/index.asp Download images.
>
>= = = = = = = = = = = = = = = = = = = =
>
>
>
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-25 08:43:44
>
>
>

_________________________________________________________________
MSN Hotmail now on your Mobile phone. 
http://server1.msn.co.in/sp03/mobilesms/ Click here.


From rathann@icm.edu.pl Fri Sep 26 15:05:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Sep 2003 15:05:51 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:3695 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225617AbTIZOFq>;
	Fri, 26 Sep 2003 15:05:46 +0100
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.5/icm) with ESMTP id h8QE5Wqk014762
	for <linux-mips@linux-mips.org>; Fri, 26 Sep 2003 16:05:37 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1A2r4z-0005C9-00
	for <linux-mips@linux-mips.org>; Fri, 26 Sep 2003 13:48:09 +0200
Date: Fri, 26 Sep 2003 13:48:09 +0200
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: [BUG?][linux_2_4] Oops in ip22-berr.c
Message-ID: <20030926114809.GB19876@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030924092828.GB21504@icm.edu.pl> <20030924103654.A15492@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030924103654.A15492@linux-mips.org>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3306
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips

Hi,

On Wed, Sep 24, 2003 at 10:36:54AM +0100, Ladislav Michl wrote:
[...] 
> nice to see bus error handler working :-)
> please apply following patch:
> ftp://ftp.linux-mips.org/pub/linux/mips/people/ladis/sgiwd93.diff

Sorry it took me so long to test it and reply. I have good news:
it works now. Thanks a lot.
I had to change the CFLAGS, however, to be able to compile with
gcc-3.3.1. Replacing -mcpu with -mtune in arch/mips/Makefile solved
the problem.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

From rathann@icm.edu.pl Fri Sep 26 15:15:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Sep 2003 15:15:42 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:61546 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225622AbTIZOPh>;
	Fri, 26 Sep 2003 15:15:37 +0100
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.5/icm) with ESMTP id h8QEFTqk031191
	for <linux-mips@linux-mips.org>; Fri, 26 Sep 2003 16:15:29 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1A2ra0-0005Sl-00
	for <linux-mips@linux-mips.org>; Fri, 26 Sep 2003 14:20:12 +0200
Date: Fri, 26 Sep 2003 14:20:12 +0200
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: [Indy] text console
Message-ID: <20030926122012.GC19876@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3307
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips

Hi.

Is there any way to change the size and refresh rate for the
text console? I've searched in the mail-list archives and on
google and came up with nothing.

Regards,

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

From AdeelM@avaznet.com Fri Sep 26 16:39:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Sep 2003 16:40:01 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:7388
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225624AbTIZPjz>; Fri, 26 Sep 2003 16:39:55 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <TPC4VWCJ>; Fri, 26 Sep 2003 20:32:55 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264ED5E@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: How to increase download speed for UART 
Date: Fri, 26 Sep 2003 20:32:50 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38443.749AFBD0"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3308
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C38443.749AFBD0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
         I am porting Linux to a MIPS based development platform. The UART
on the board provides a maximum baud rate of 115 kbps. But the download time
for the kernel Image of about 4.3 MB is about 4 hours !!!!!. 
 
Can someone help me address this problem ?. 
 
(I can't download the kernel image via tftp server using ethernet, as the
CPU doesn't have the MAC interface).
 
Regards,
ADEEL MALIK,
 


------_=_NextPart_001_01C38443.749AFBD0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial" hb_focus_attach="true">
<DIV><SPAN class=054482515-26092003><FONT size=2>Hi All,</FONT></SPAN></DIV>
<DIV><SPAN class=054482515-26092003><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am porting Linux to a 
MIPS based development platform. The UART on the board provides a maximum baud 
rate of 115&nbsp;kbps. But the download time for the kernel Image of about 4.3 
MB is about 4 hours !!!!!. </FONT></SPAN></DIV>
<DIV><SPAN class=054482515-26092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=054482515-26092003><FONT size=2>Can&nbsp;someone help me 
address this problem ?. </FONT></SPAN></DIV>
<DIV><SPAN class=054482515-26092003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=054482515-26092003><FONT size=2>(I can't download the 
kernel&nbsp;image via tftp server using ethernet, as the CPU doesn't have the 
MAC interface).</FONT></SPAN></DIV>
<DIV><SPAN class=054482515-26092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=054482515-26092003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL MALIK,</EM></FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<P></P></BODY></HTML>

------_=_NextPart_001_01C38443.749AFBD0--

From ppopov@mvista.com Fri Sep 26 16:45:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Sep 2003 16:45:34 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:35573 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225624AbTIZPpc>;
	Fri, 26 Sep 2003 16:45:32 +0100
Received: from [10.2.2.20] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id IAA26179;
	Fri, 26 Sep 2003 08:45:28 -0700
Subject: Re: How to increase download speed for UART
From: Pete Popov <ppopov@mvista.com>
To: Adeel Malik <AdeelM@avaznet.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264ED5E@1aurora.enabtech>
References: <10C6C1971DA00C4BB87AC0206E3CA38264ED5E@1aurora.enabtech>
Content-Type: text/plain
Organization: 
Message-Id: <1064591128.8219.25.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 26 Sep 2003 08:45:28 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3309
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, 2003-09-26 at 08:32, Adeel Malik wrote:
> Hi All,
>          I am porting Linux to a MIPS based development platform. The
> UART on the board provides a maximum baud rate of 115 kbps. But the
> download time for the kernel Image of about 4.3 MB is about 4 hours
> !!!!!. 

4.3MB? Is this an SREC file? I've downloaded images over the serial port
(srec files) and it takes no more than 10 minutes.

Pete

> Can someone help me address this problem ?. 
>  
> (I can't download the kernel image via tftp server using ethernet, as
> the CPU doesn't have the MAC interface).
>  
> Regards,
> ADEEL MALIK,
>  
> 


From AdeelM@avaznet.com Fri Sep 26 16:48:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Sep 2003 16:49:10 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:43484
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225624AbTIZPs6>; Fri, 26 Sep 2003 16:48:58 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <TPC4VWCK>; Fri, 26 Sep 2003 20:42:05 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264ED5F@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: RE: How to increase download speed for UART
Date: Fri, 26 Sep 2003 20:41:58 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3310
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

Yes this is an Motorola's S-Record File. Do you think that I am missing
something?. I am using YAMON to configure the UART's settings on the board
and HyperTerminal on the Host the transfer this file.

ADEEL 


-----Original Message-----
From: Pete Popov [mailto:ppopov@mvista.com]
Sent: Friday, September 26, 2003 8:45 PM
To: Adeel Malik
Cc: linux-mips@linux-mips.org
Subject: Re: How to increase download speed for UART


On Fri, 2003-09-26 at 08:32, Adeel Malik wrote:
> Hi All,
>          I am porting Linux to a MIPS based development platform. The
> UART on the board provides a maximum baud rate of 115 kbps. But the
> download time for the kernel Image of about 4.3 MB is about 4 hours
> !!!!!. 

4.3MB? Is this an SREC file? I've downloaded images over the serial port
(srec files) and it takes no more than 10 minutes.

Pete

> Can someone help me address this problem ?. 
>  
> (I can't download the kernel image via tftp server using ethernet, as
> the CPU doesn't have the MAC interface).
>  
> Regards,
> ADEEL MALIK,
>  
> 


From ppopov@mvista.com Fri Sep 26 17:09:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Sep 2003 17:09:42 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:35569 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225630AbTIZQJa>;
	Fri, 26 Sep 2003 17:09:30 +0100
Received: from [10.2.2.20] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA27200;
	Fri, 26 Sep 2003 09:09:28 -0700
Subject: RE: How to increase download speed for UART
From: Pete Popov <ppopov@mvista.com>
To: Adeel Malik <AdeelM@avaznet.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264ED5F@1aurora.enabtech>
References: <10C6C1971DA00C4BB87AC0206E3CA38264ED5F@1aurora.enabtech>
Content-Type: text/plain
Organization: 
Message-Id: <1064592568.8219.30.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 26 Sep 2003 09:09:28 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3311
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, 2003-09-26 at 08:41, Adeel Malik wrote:
> Yes this is an Motorola's S-Record File. Do you think that I am missing
> something?. I am using YAMON to configure the UART's settings on the board
> and HyperTerminal on the Host the transfer this file.

Yes, I think there's something definitely wrong. I wonder if the
download is even in progress... You're using windows and hyperterm? Try
it on linux but just doing "cat <srec file name>  > /dev/ttyS0",
assuming you're using the first serial port to connect to the target.
Yamon gives you feedback of the download progress by printing dots, when
downloading over ethernet. I imagine it does the same when downloading
over serial port, so if you are not seeing any progress feedback, then
perhaps that's another indication that your download is not working.

Pete

> ADEEL 
> 
> 
> -----Original Message-----
> From: Pete Popov [mailto:ppopov@mvista.com]
> Sent: Friday, September 26, 2003 8:45 PM
> To: Adeel Malik
> Cc: linux-mips@linux-mips.org
> Subject: Re: How to increase download speed for UART
> 
> 
> On Fri, 2003-09-26 at 08:32, Adeel Malik wrote:
> > Hi All,
> >          I am porting Linux to a MIPS based development platform. The
> > UART on the board provides a maximum baud rate of 115 kbps. But the
> > download time for the kernel Image of about 4.3 MB is about 4 hours
> > !!!!!. 
> 
> 4.3MB? Is this an SREC file? I've downloaded images over the serial port
> (srec files) and it takes no more than 10 minutes.
> 
> Pete
> 
> > Can someone help me address this problem ?. 
> >  
> > (I can't download the kernel image via tftp server using ethernet, as
> > the CPU doesn't have the MAC interface).
> >  
> > Regards,
> > ADEEL MALIK,
> >  
> > 
> 
> 


From earlm@mips.com Fri Sep 26 19:07:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Sep 2003 19:07:28 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:64736 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225633AbTIZSHX>;
	Fri, 26 Sep 2003 19:07:23 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h8QI4sYY029310;
	Fri, 26 Sep 2003 11:04:55 -0700 (PDT)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA08475;
	Fri, 26 Sep 2003 11:08:16 -0700 (PDT)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <TVNB9CDH>; Fri, 26 Sep 2003 11:04:29 -0700
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A02264DBF@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'Pete Popov'" <ppopov@mvista.com>,
	Adeel Malik <AdeelM@avaznet.com>
Cc: linux-mips@linux-mips.org
Subject: RE: How to increase download speed for UART
Date: Fri, 26 Sep 2003 11:04:29 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3312
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips


YAMON only prints '.' feedback for 
ethernet download, unless you modified it.
Download a copy of TeraTerm and use that
instead of Hyperterminal. Then you can use
the "Send File" command under File pulldown.
This gives you feedback showing how many
bytes have been transferred. 

I was able to load a 6.4MB linux srec
image in 27 minutes on my Malta 4Kc board
with baud rate set to 38.4K. Using TFTP 
over ethernet it takes 17 seconds. Another
alternative is to consider buying an EJTAG probe 
and loading thru that. The probes will probably load
something this size within 1-4 minutes. This
is assuming you have EJTAG interface available.
But I wouldn't buy a probe just to download
code. ;-) 

-earlm

-----Original Message-----
From: Pete Popov [mailto:ppopov@mvista.com]
Sent: Friday, September 26, 2003 9:09 AM
To: Adeel Malik
Cc: linux-mips@linux-mips.org
Subject: RE: How to increase download speed for UART


On Fri, 2003-09-26 at 08:41, Adeel Malik wrote:
> Yes this is an Motorola's S-Record File. Do you think that I am missing
> something?. I am using YAMON to configure the UART's settings on the board
> and HyperTerminal on the Host the transfer this file.

Yes, I think there's something definitely wrong. I wonder if the
download is even in progress... You're using windows and hyperterm? Try
it on linux but just doing "cat <srec file name>  > /dev/ttyS0",
assuming you're using the first serial port to connect to the target.
Yamon gives you feedback of the download progress by printing dots, when
downloading over ethernet. I imagine it does the same when downloading
over serial port, so if you are not seeing any progress feedback, then
perhaps that's another indication that your download is not working.

Pete

> ADEEL 
> 
> 
> -----Original Message-----
> From: Pete Popov [mailto:ppopov@mvista.com]
> Sent: Friday, September 26, 2003 8:45 PM
> To: Adeel Malik
> Cc: linux-mips@linux-mips.org
> Subject: Re: How to increase download speed for UART
> 
> 
> On Fri, 2003-09-26 at 08:32, Adeel Malik wrote:
> > Hi All,
> >          I am porting Linux to a MIPS based development platform. The
> > UART on the board provides a maximum baud rate of 115 kbps. But the
> > download time for the kernel Image of about 4.3 MB is about 4 hours
> > !!!!!. 
> 
> 4.3MB? Is this an SREC file? I've downloaded images over the serial port
> (srec files) and it takes no more than 10 minutes.
> 
> Pete
> 
> > Can someone help me address this problem ?. 
> >  
> > (I can't download the kernel image via tftp server using ethernet, as
> > the CPU doesn't have the MAC interface).
> >  
> > Regards,
> > ADEEL MALIK,
> >  
> > 
> 
> 


From earlm@mips.com Fri Sep 26 19:15:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 26 Sep 2003 19:16:03 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:13281 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225633AbTIZSP6>;
	Fri, 26 Sep 2003 19:15:58 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h8QIDUYY029420;
	Fri, 26 Sep 2003 11:13:30 -0700 (PDT)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA08662;
	Fri, 26 Sep 2003 11:16:52 -0700 (PDT)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <TVNB9C1L>; Fri, 26 Sep 2003 11:13:06 -0700
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A02264DC1@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'Pete Popov'" <ppopov@mvista.com>,
	Adeel Malik <AdeelM@avaznet.com>
Cc: linux-mips@linux-mips.org
Subject: RE: How to increase download speed for UART
Date: Fri, 26 Sep 2003 11:13:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3313
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips

You can also get a probe with
ethernet support and do it that
way. 

-earlm

-----Original Message-----
From: Mitchell, Earl [mailto:earlm@mips.com]
Sent: Friday, September 26, 2003 11:04 AM
To: 'Pete Popov'; Adeel Malik
Cc: linux-mips@linux-mips.org
Subject: RE: How to increase download speed for UART



YAMON only prints '.' feedback for 
ethernet download, unless you modified it.
Download a copy of TeraTerm and use that
instead of Hyperterminal. Then you can use
the "Send File" command under File pulldown.
This gives you feedback showing how many
bytes have been transferred. 

I was able to load a 6.4MB linux srec
image in 27 minutes on my Malta 4Kc board
with baud rate set to 38.4K. Using TFTP 
over ethernet it takes 17 seconds. Another
alternative is to consider buying an EJTAG probe 
and loading thru that. The probes will probably load
something this size within 1-4 minutes. This
is assuming you have EJTAG interface available.
But I wouldn't buy a probe just to download
code. ;-) 

-earlm

-----Original Message-----
From: Pete Popov [mailto:ppopov@mvista.com]
Sent: Friday, September 26, 2003 9:09 AM
To: Adeel Malik
Cc: linux-mips@linux-mips.org
Subject: RE: How to increase download speed for UART


On Fri, 2003-09-26 at 08:41, Adeel Malik wrote:
> Yes this is an Motorola's S-Record File. Do you think that I am missing
> something?. I am using YAMON to configure the UART's settings on the board
> and HyperTerminal on the Host the transfer this file.

Yes, I think there's something definitely wrong. I wonder if the
download is even in progress... You're using windows and hyperterm? Try
it on linux but just doing "cat <srec file name>  > /dev/ttyS0",
assuming you're using the first serial port to connect to the target.
Yamon gives you feedback of the download progress by printing dots, when
downloading over ethernet. I imagine it does the same when downloading
over serial port, so if you are not seeing any progress feedback, then
perhaps that's another indication that your download is not working.

Pete

> ADEEL 
> 
> 
> -----Original Message-----
> From: Pete Popov [mailto:ppopov@mvista.com]
> Sent: Friday, September 26, 2003 8:45 PM
> To: Adeel Malik
> Cc: linux-mips@linux-mips.org
> Subject: Re: How to increase download speed for UART
> 
> 
> On Fri, 2003-09-26 at 08:32, Adeel Malik wrote:
> > Hi All,
> >          I am porting Linux to a MIPS based development platform. The
> > UART on the board provides a maximum baud rate of 115 kbps. But the
> > download time for the kernel Image of about 4.3 MB is about 4 hours
> > !!!!!. 
> 
> 4.3MB? Is this an SREC file? I've downloaded images over the serial port
> (srec files) and it takes no more than 10 minutes.
> 
> Pete
> 
> > Can someone help me address this problem ?. 
> >  
> > (I can't download the kernel image via tftp server using ethernet, as
> > the CPU doesn't have the MAC interface).
> >  
> > Regards,
> > ADEEL MALIK,
> >  
> > 
> 
> 


From guangxing@ict.ac.cn Mon Sep 29 02:27:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 Sep 2003 02:28:01 +0100 (BST)
Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:2460 "HELO
	mail.ict.ac.cn") by linux-mips.org with SMTP id <S8225408AbTI2B17> convert rfc822-to-8bit;
	Mon, 29 Sep 2003 02:27:59 +0100
Received: (qmail 8497 invoked from network); 29 Sep 2003 01:11:05 -0000
Received: from unknown (HELO xing) (159.226.39.104)
  by mail.ict.ac.cn with SMTP; 29 Sep 2003 01:11:05 -0000
From: "Guangxing Zhang" <guangxing@ict.ac.cn>
To: invictus rm <invictus_rm@hotmail.com>
CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>
Subject: Re: Re: Re: help, question on pci communication!
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 8BIT
Date: Mon, 29 Sep 2003 9:28:20 +0800
Message-Id: <20030929012759Z8225408-1272+6746@linux-mips.org>
Return-Path: <guangxing@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3314
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: guangxing@ict.ac.cn
Precedence: bulk
X-list: linux-mips

Hi,

	Thank your for your help.
    Other troublesome things to me ,so long time to see my mail.
    I will try to read it and find to know how , the result will be mailed to 
you if i have any tried.
    Thank you again for your enthusiastic advice. 

======= invictus_rm@hotmail.com 2003-09-25 20:01:00 WROTE£º=======

>http://www.xml.com/ldd/chapter/book/ch13.html
>search for ioermap in this web page
>
>hope this helps
>
>rm
>
>
>>From: "Guangxing Zhang" <guangxing@ict.ac.cn>
>>To: invictus rm <invictus_rm@hotmail.com>
>>CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>, angela 
>><jhyang@ict.ac.cn>, Fuxin Zhang <fxzhang@ict.ac.cn>
>>Subject: Re: Re: help, question on pci communication!
>>Date: Thu, 25 Sep 2003 9:41:35 +0800
>>
>>Hi, invictus rm
>>       Thank you very much for your enthusiastic help.
>>       I think it will be BIG help to me.Thank you.
>>       There is some thing i want to see your advise and help again.
>>       In BCM1250 we run the mips-linux which is customer compiled by us,
>>and in the  MCP750 there is linux too.What i want to implement is
>>transfering  data from BCM1250 to MCP750 through PCI.And using "dmesg"
>>i found the following info:(In BCM1250 ,MIPS-LINUX)
>>---------------------------------------------------------------------------------------------------------------------
>>.............
>>     Jan  1 00:00:11 (none) kernel: Determined physical RAM map:
>>     Jan  1 00:00:11 (none) kernel:  memory: 003a7000 @ 00000000 (usable)
>>Jan  1 00:00:11 (none) kernel:  memory: 0f711000 @ 0075c000 (usable)
>>Jan  1 00:00:11 (none) kernel:  memory: 1ffffe00 @ 80000000 (usable)
>>Jan  1 00:00:11 (none) kernel:  memory: 0ffffe00 @ c0000000 (usable)
>>Jan  1 00:00:11 (none) kernel:  memory: 003b5000 @ 003a7000 (reserved)
>>Jan  1 00:00:11 (none) kernel: 2815MB HIGHMEM available.
>>Jan  1 00:00:11 (none) kernel: Initial ramdisk at: 0x803a7000 (3887104 
>>bytes)
>>Jan  1 00:00:11 (none) kernel: On node 0 totalpages: 851967
>>Jan  1 00:00:11 (none) kernel: zone(0): 131072 pages.
>>Jan  1 00:00:11 (none) kernel: zone(1): 0 pages.
>>Jan  1 00:00:11 (none) kernel: zone(2): 720895 pages.
>>@ Jan  1 00:00:11 (none) kernel: Kernel command line: root=/dev/ram0 rw 
>>bigphysarea=8192 pcisharesize=16
>>@ Jan  1 00:00:11 (none) kernel: pcisharemem allocated @ 85800000
>>...................
>>---------------------------------------------------------------------------------------------------------------------
>>     In the above lines tagged with @ i notice that there is 
>>"bigphysarea=8192 pcisharesize=16",
>>I have read "kernel/include/linux/mm/bigphysarea.h" ,and known that 
>>bigphysarea can be used
>>to reserve some amount of physical memory at boot-time for PCI 
>>communication.A friend told me
>>using it is simple ,but he did not tell me kow :-)~(Of course i think he 
>>knows it from others).
>>And i think in my kernel module i can implement it.Without any knowledge on 
>>it ,I am swamped now.
>>Can you give me some info on how to do that ,such as how to use the 
>>"bigphysarea"?How the MCP750
>>see the "bigphysarea" in BCM1250 and access it (read it)?
>>     I think i am so avaricious , but i really thirst for the help and 
>>advice.
>>     Thank you again and in advance again.:-)~
>>
>>
>>======= invictus_rm@hotmail.com 2003-09-24 23:15:00 WROTE£º=======
>>
>> >hi,
>> >
>> >  If the BCM1250 is operating in the device mode in the peripheral slot 
>>of
>> >the CPCI chassis, u need t get the enumeration of the PCI being done from
>> >MCP 750 right.
>> >  The code for MCP750 alread exists in the linux kernel ( if i remember
>> >correctly).
>> >
>> >U can proceed in the following directions-->
>> >(a) Get the PCI enumeration working properly on the MCP750 ( look at the
>> >ouput of lspci -vvv to decide whether resource allocation is proper or 
>>not)
>> >.. The powerpc provides a fairly comprehensive PCI enumeration code(
>> >including scanning beyond the bridge).
>> >
>> >(b) Once u are able to see ur device in the lspci output on the MCP board 
>>,
>> >u can load the driver ( ur custom driver ) to do the transfer from the
>> >BCM1250 to MCP and vice versa.
>> >
>> >(v) Look at the few PCI based drivers about the way the data transfers is
>> >handled specially pci_alloc_* / pci_map_*/pci_resource_*.........
>> >
>> >Hope this helps
>> >
>> >
>> >
>> >
>> >>From: "Guangxing Zhang" <guangxing@ict.ac.cn>
>> >>To: Fuxin Zhang <fxzhang@ict.ac.cn>
>> >>CC: linux-mips@linux-mips.org <linux-mips@linux-mips.org>, angela
>> >><jhyang@ict.ac.cn>
>> >>Subject: help, question on pci communication!
>> >>Date: Wed, 24 Sep 2003 16:29:32 +0800
>> >>
>> >>Hi, Fuxin and everyone see this mail,
>> >>     In linux world ,newbies always like to ask and the veterans will
>> >>always be enthusiastic.:)~~
>> >>     Now there is a "ask", of course i am a newbie.
>> >>     Follow is the  architecture  which we are working on.
>> >>     Now i want to transfer the data from the "sb1250" to mcp750 through
>> >>the PCI bus with the help of 21555 bridge.
>> >>I want to implement it in kernel module.Although knowing "use the force
>> >>,read source",but i really do not know
>> >>how and where to begin.
>> >>     Is there any advice on it ? How to implement the communication 
>>through
>> >>PCI (or PCI-to-PCI bridge) in kernel
>> >>moudle?
>> >>     Any help will be appreciated!Thank in advance!
>> >>
>> >>                       -------------
>> >>                   |  MCP 750  |  (Power PC)
>> >>                       -------------
>> >>                             |
>> >>¡¡     -------------------------------------------CPCI
>> >>                          |
>> >>              ---------------|--------------------------------
>> >>              |      --------|-----                         |
>> >>              |      |Intel 21555 |(PCI-TO-PCI Bridge)      |
>> >>              |      --------------                         |
>> >>              |        |                        |
>> >>              |      --------(PCI bus)        |
>> >>    |          |                                  |
>> >>    |       --------                              |
>> >>    |   |SB1250|(CPU)                         |
>> >>    |       --------                              |
>> >>              ----------------------------------------------
>> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
>> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
>> >>       2003-09-24 16:03:04
>> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
>> >>
>> >>
>> >>
>> >>
>> >
>> >_________________________________________________________________
>> >Talk to Karthikeyan. Watch his stunning feats.
>> >http://server1.msn.co.in/sp03/tataracing/index.asp Download images.
>>
>>= = = = = = = = = = = = = = = = = = = =
>>
>>
>>
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
>>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-25 08:43:44
>>
>>
>>
>
>_________________________________________________________________
>MSN Hotmail now on your Mobile phone. 
>http://server1.msn.co.in/sp03/mobilesms/ Click here

= = = = = = = = = = = = = = = = = = = =
			
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guangxing Zhang
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guangxing@ict.ac.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-09-29 09:24:33




From smm@futarque.com Mon Sep 29 07:14:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 Sep 2003 07:14:32 +0100 (BST)
Received: from futarque.com ([IPv6:::ffff:212.242.80.58]:39698 "HELO
	mail.futarque.com") by linux-mips.org with SMTP id <S8225373AbTI2GO3>;
	Mon, 29 Sep 2003 07:14:29 +0100
Received: (qmail 4505 invoked by uid 64014); 29 Sep 2003 06:14:20 -0000
Received: from smm@futarque.com by mail by uid 64011 with qmail-scanner-1.16 
 (uvscan: v4.1.60/v4278. spamassassin: 2.55.  Clear:. 
 Processed in 1.037044 secs); 29 Sep 2003 06:14:20 -0000
Received: from excalibur.futarque.com (192.168.2.15)
  by mail.futarque.com with SMTP; 29 Sep 2003 06:14:18 -0000
Subject: RE: How to increase download speed for UART
From: Steffen Malmgaard Mortensen <smm@futarque.com>
To: linux-mips@linux-mips.org
In-Reply-To: <0C5F4C7A1E3ED51194E200508B2CE32A02264DC1@xchange.mips.com>
References: <0C5F4C7A1E3ED51194E200508B2CE32A02264DC1@xchange.mips.com>
Content-Type: text/plain
Message-Id: <1064816058.3675.4.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Mon, 29 Sep 2003 08:14:18 +0200
Content-Transfer-Encoding: 7bit
Return-Path: <smm@futarque.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3315
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: smm@futarque.com
Precedence: bulk
X-list: linux-mips

Hi
I have experienced the same problem with HyperTerminal on Win2000. There
are a number of freeware terminal emulators for Win2000 (eg.
http://home.planet.nl/~ruurdb/IVT.HTM), so you could try one of those if
you can't use linux.
Good luck
/Steffen

On Fri, 2003-09-26 at 20:13, Mitchell, Earl wrote:
> You can also get a probe with
> ethernet support and do it that
> way. 
> 
> -earlm
> 
> -----Original Message-----
> From: Mitchell, Earl [mailto:earlm@mips.com]
> Sent: Friday, September 26, 2003 11:04 AM
> To: 'Pete Popov'; Adeel Malik
> Cc: linux-mips@linux-mips.org
> Subject: RE: How to increase download speed for UART
> 
> 
> 
> YAMON only prints '.' feedback for 
> ethernet download, unless you modified it.
> Download a copy of TeraTerm and use that
> instead of Hyperterminal. Then you can use
> the "Send File" command under File pulldown.
> This gives you feedback showing how many
> bytes have been transferred. 
> 
> I was able to load a 6.4MB linux srec
> image in 27 minutes on my Malta 4Kc board
> with baud rate set to 38.4K. Using TFTP 
> over ethernet it takes 17 seconds. Another
> alternative is to consider buying an EJTAG probe 
> and loading thru that. The probes will probably load
> something this size within 1-4 minutes. This
> is assuming you have EJTAG interface available.
> But I wouldn't buy a probe just to download
> code. ;-) 
> 
> -earlm
> 
> -----Original Message-----
> From: Pete Popov [mailto:ppopov@mvista.com]
> Sent: Friday, September 26, 2003 9:09 AM
> To: Adeel Malik
> Cc: linux-mips@linux-mips.org
> Subject: RE: How to increase download speed for UART
> 
> 
> On Fri, 2003-09-26 at 08:41, Adeel Malik wrote:
> > Yes this is an Motorola's S-Record File. Do you think that I am missing
> > something?. I am using YAMON to configure the UART's settings on the board
> > and HyperTerminal on the Host the transfer this file.
> 
> Yes, I think there's something definitely wrong. I wonder if the
> download is even in progress... You're using windows and hyperterm? Try
> it on linux but just doing "cat <srec file name>  > /dev/ttyS0",
> assuming you're using the first serial port to connect to the target.
> Yamon gives you feedback of the download progress by printing dots, when
> downloading over ethernet. I imagine it does the same when downloading
> over serial port, so if you are not seeing any progress feedback, then
> perhaps that's another indication that your download is not working.
> 
> Pete
> 
> > ADEEL 
> > 
> > 
> > -----Original Message-----
> > From: Pete Popov [mailto:ppopov@mvista.com]
> > Sent: Friday, September 26, 2003 8:45 PM
> > To: Adeel Malik
> > Cc: linux-mips@linux-mips.org
> > Subject: Re: How to increase download speed for UART
> > 
> > 
> > On Fri, 2003-09-26 at 08:32, Adeel Malik wrote:
> > > Hi All,
> > >          I am porting Linux to a MIPS based development platform. The
> > > UART on the board provides a maximum baud rate of 115 kbps. But the
> > > download time for the kernel Image of about 4.3 MB is about 4 hours
> > > !!!!!. 
> > 
> > 4.3MB? Is this an SREC file? I've downloaded images over the serial port
> > (srec files) and it takes no more than 10 minutes.
> > 
> > Pete
> > 
> > > Can someone help me address this problem ?. 
> > >  
> > > (I can't download the kernel image via tftp server using ethernet, as
> > > the CPU doesn't have the MAC interface).
> > >  
> > > Regards,
> > > ADEEL MALIK,
> > >  
> > > 
> > 
> > 
> 
> 


From AdeelM@avaznet.com Mon Sep 29 08:48:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 Sep 2003 08:48:08 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:49843
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225388AbTI2HsF>; Mon, 29 Sep 2003 08:48:05 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <TPC4VWCP>; Mon, 29 Sep 2003 12:41:06 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264ED84@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: Steffen Malmgaard Mortensen <smm@futarque.com>
Cc: linux-mips@linux-mips.org
Subject: RE: How to increase download speed for UART
Date: Mon, 29 Sep 2003 12:41:02 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3316
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips

Hi,
    The terminal emulator that you specified supports the max. baud rate of
115.2 kbps. And it is taking about 7 minutes to download the Kernel Image of
4.3 MB. Do you know some other Terminal Emulator that can support a higher
baud rate ?.

The UART of the target processor supports the max. baud rate of 406 kbps. So
I can use the terminal emulator that supports for example, 406kbps, then my
download time may be further reduced.

Regards,

ADEEL MALIK,


-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Steffen Malmgaard
Mortensen
Sent: Monday, September 29, 2003 11:14 AM
To: linux-mips@linux-mips.org
Subject: RE: How to increase download speed for UART


Hi
I have experienced the same problem with HyperTerminal on Win2000. There
are a number of freeware terminal emulators for Win2000 (eg.
http://home.planet.nl/~ruurdb/IVT.HTM), so you could try one of those if
you can't use linux.
Good luck
/Steffen

On Fri, 2003-09-26 at 20:13, Mitchell, Earl wrote:
> You can also get a probe with
> ethernet support and do it that
> way. 
> 
> -earlm
> 
> -----Original Message-----
> From: Mitchell, Earl [mailto:earlm@mips.com]
> Sent: Friday, September 26, 2003 11:04 AM
> To: 'Pete Popov'; Adeel Malik
> Cc: linux-mips@linux-mips.org
> Subject: RE: How to increase download speed for UART
> 
> 
> 
> YAMON only prints '.' feedback for 
> ethernet download, unless you modified it.
> Download a copy of TeraTerm and use that
> instead of Hyperterminal. Then you can use
> the "Send File" command under File pulldown.
> This gives you feedback showing how many
> bytes have been transferred. 
> 
> I was able to load a 6.4MB linux srec
> image in 27 minutes on my Malta 4Kc board
> with baud rate set to 38.4K. Using TFTP 
> over ethernet it takes 17 seconds. Another
> alternative is to consider buying an EJTAG probe 
> and loading thru that. The probes will probably load
> something this size within 1-4 minutes. This
> is assuming you have EJTAG interface available.
> But I wouldn't buy a probe just to download
> code. ;-) 
> 
> -earlm
> 
> -----Original Message-----
> From: Pete Popov [mailto:ppopov@mvista.com]
> Sent: Friday, September 26, 2003 9:09 AM
> To: Adeel Malik
> Cc: linux-mips@linux-mips.org
> Subject: RE: How to increase download speed for UART
> 
> 
> On Fri, 2003-09-26 at 08:41, Adeel Malik wrote:
> > Yes this is an Motorola's S-Record File. Do you think that I am missing
> > something?. I am using YAMON to configure the UART's settings on the
board
> > and HyperTerminal on the Host the transfer this file.
> 
> Yes, I think there's something definitely wrong. I wonder if the
> download is even in progress... You're using windows and hyperterm? Try
> it on linux but just doing "cat <srec file name>  > /dev/ttyS0",
> assuming you're using the first serial port to connect to the target.
> Yamon gives you feedback of the download progress by printing dots, when
> downloading over ethernet. I imagine it does the same when downloading
> over serial port, so if you are not seeing any progress feedback, then
> perhaps that's another indication that your download is not working.
> 
> Pete
> 
> > ADEEL 
> > 
> > 
> > -----Original Message-----
> > From: Pete Popov [mailto:ppopov@mvista.com]
> > Sent: Friday, September 26, 2003 8:45 PM
> > To: Adeel Malik
> > Cc: linux-mips@linux-mips.org
> > Subject: Re: How to increase download speed for UART
> > 
> > 
> > On Fri, 2003-09-26 at 08:32, Adeel Malik wrote:
> > > Hi All,
> > >          I am porting Linux to a MIPS based development platform. The
> > > UART on the board provides a maximum baud rate of 115 kbps. But the
> > > download time for the kernel Image of about 4.3 MB is about 4 hours
> > > !!!!!. 
> > 
> > 4.3MB? Is this an SREC file? I've downloaded images over the serial port
> > (srec files) and it takes no more than 10 minutes.
> > 
> > Pete
> > 
> > > Can someone help me address this problem ?. 
> > >  
> > > (I can't download the kernel image via tftp server using ethernet, as
> > > the CPU doesn't have the MAC interface).
> > >  
> > > Regards,
> > > ADEEL MALIK,
> > >  
> > > 
> > 
> > 
> 
> 



From agx@sigxcpu.org Mon Sep 29 17:35:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 Sep 2003 17:36:21 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:48617
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225437AbTI2Qfm>; Mon, 29 Sep 2003 17:35:42 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 653902BC42; Mon, 29 Sep 2003 18:35:28 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 30330-06;
 Mon, 29 Sep 2003 18:34:57 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 884FC2BC39; Mon, 29 Sep 2003 18:34:57 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id AEBFA40CC; Mon, 29 Sep 2003 18:35:28 +0200 (CEST)
Date: Mon, 29 Sep 2003 18:35:28 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Cc: ralf@gnu.org
Subject: [patch] kmap_types.h for mips64
Message-ID: <20030929163528.GB6983@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org, ralf@gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gMR3gsNFwZpnI/Ts"
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian)
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3317
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips


--gMR3gsNFwZpnI/Ts
Content-Type: multipart/mixed; boundary="xB0nW4MQa6jZONgY"
Content-Disposition: inline


--xB0nW4MQa6jZONgY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,
linux_2_4's mips64 doesn't have kmap_types.h which is needed for the
crypto code.

--- /dev/null	2003-08-29 16:55:43.000000000 +0200
+++ include/asm-mips64/kmap_types.h	2003-09-29 17:44:16.000000000 +0200
@@ -0,0 +1,16 @@
+#ifndef _ASM_KMAP_TYPES_H
+#define _ASM_KMAP_TYPES_H
+
+enum km_type {
+	KM_BOUNCE_READ,
+	KM_SKB_SUNRPC_DATA,
+	KM_SKB_DATA_SOFTIRQ,
+	KM_USER0,
+	KM_USER1,
+	KM_BH_IRQ,
+	KM_SOFTIRQ0,
+	KM_SOFTIRQ1,
+	KM_TYPE_NR
+};
+
+#endif

Please apply,
 -- Guido

--xB0nW4MQa6jZONgY
Content-Type: text/x-chdr; charset=us-ascii
Content-Disposition: attachment; filename="kmap_types-mips64.h"

--- /dev/null	2003-08-29 16:55:43.000000000 +0200
+++ include/asm-mips64/kmap_types.h	2003-09-29 17:44:16.000000000 +0200
@@ -0,0 +1,16 @@
+#ifndef _ASM_KMAP_TYPES_H
+#define _ASM_KMAP_TYPES_H
+
+enum km_type {
+	KM_BOUNCE_READ,
+	KM_SKB_SUNRPC_DATA,
+	KM_SKB_DATA_SOFTIRQ,
+	KM_USER0,
+	KM_USER1,
+	KM_BH_IRQ,
+	KM_SOFTIRQ0,
+	KM_SOFTIRQ1,
+	KM_TYPE_NR
+};
+
+#endif

--xB0nW4MQa6jZONgY--

--gMR3gsNFwZpnI/Ts
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/eF9Qn88szT8+ZCYRAts+AJwNj5VE01yeOeWDF/NUVSHPzjAC6wCfXPKr
PwOS9kRXrmx9rYa3m+WOBDQ=
=B7Zs
-----END PGP SIGNATURE-----

--gMR3gsNFwZpnI/Ts--

From Steve.Finney@SpirentCom.COM Mon Sep 29 18:32:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 Sep 2003 18:32:11 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:6910 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225436AbTI2RcI> convert rfc822-to-8bit; Mon, 29 Sep 2003 18:32:08 +0100
content-class: urn:content-classes:message
Subject: 64 bit operations w/32 bit kernel
Date: Mon, 29 Sep 2003 07:31:57 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75C@iris.adtech-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: 64 bit operations w/32 bit kernel
Thread-Index: AcOGr5RuaH2Cp/S8QqaiUMNpsQeklA==
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3318
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips

What would be the downside to enabling 64 bit operations in user space on a 32 bit kernel (setting the PX bit in the status register?). The particular issue is that I want to access 64 bit-memory mapped registers, and I really need to do it as an atomic operation. I tried borrowing sibyte/64bit.h from the kernel, but I get an illegal instruction on the double ops.

Also, assuming this isn't a horrible idea, is there any obvious single place where "default" values in the CP0 status register get set?

Thanks,
sf

From dkesselr@mmc.atmel.com Mon Sep 29 18:45:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 Sep 2003 18:45:39 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:39578
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225436AbTI2RpZ>; Mon, 29 Sep 2003 18:45:25 +0100
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id NAA07416
	for <linux-mips@linux-mips.org>; Mon, 29 Sep 2003 13:45:18 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id NAA04465
	for <linux-mips@linux-mips.org>; Mon, 29 Sep 2003 13:45:18 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 29 Sep 2003 13:45:18 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: failed build of Mips for 2.4.22
Message-ID: <Pine.GSO.4.44.0309291339570.4225-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3319
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

When I tried to build 2.4.22 (including patch-2.4.22-ac4) for Malta, the
build failed when compiling offset.c. It looks like several things changed
in the base code that caused the failure. Does anyone have a patch for the
MIPS build on 2.4.22. I need to use this because a required driver is
already built for 2.4.22. The crux of the problem is the new DFU
stuff(whatever that is).
Thanks for any input.

David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com
919-462-6587


From uhler@mips.com Mon Sep 29 20:00:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 Sep 2003 20:01:27 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:48820 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225468AbTI2TAz>;
	Mon, 29 Sep 2003 20:00:55 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h8TIwLYY009021;
	Mon, 29 Sep 2003 11:58:22 -0700 (PDT)
Received: from uhler-linux.mips.com (uhler-linux [192.168.65.120])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA25600;
	Mon, 29 Sep 2003 12:01:53 -0700 (PDT)
Subject: Re: 64 bit operations w/32 bit kernel
From: Michael Uhler <uhler@mips.com>
To: "Finney, Steve" <Steve.Finney@spirentcom.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75C@iris.adtech-inc.com>
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75C@iris.adtech-inc.com>
Content-Type: text/plain
Organization: MIPS Technologies, Inc.
Message-Id: <1064862114.11818.21.camel@uhler-linux.mips.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.0 
Date: 29 Sep 2003 12:01:54 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3320
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips

On Mon, 2003-09-29 at 10:31, Finney, Steve wrote:
> What would be the downside to enabling 64 bit operations in user space on a 32 bit kernel (setting the PX bit in the status register?). The particular issue is that I want to access 64 bit-memory mapped registers, and I really need to do it as an atomic operation. I tried borrowing sibyte/64bit.h from the kernel, but I get an illegal instruction on the double ops.
> 
The most glaring problem is you violate the rule that the 64-bit GPRs
are sign-extended when running a 32-bit binary.  There are all kinds
of assumptions in the hardware and software that depend on the
GPRs being sign-extended, and to violate this will risk some
serious instability of the software.

> Also, assuming this isn't a horrible idea, is there any obvious single place where "default" values in the CP0 status register get set?
> 
> Thanks,
> sf
-- 

Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.  Email: uhler@mips.com  Pager:uhler_p@mips.com
1225 Charleston Road     Voice:  (650)567-5025  FAX:   (650)567-5225
Mountain View, CA 94043  Mobile: (650)868-6870  Admin: (650)567-5085



From ralf@linux-mips.org Mon Sep 29 22:05:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 Sep 2003 22:05:22 +0100 (BST)
Received: from p508B7C78.dip.t-dialin.net ([IPv6:::ffff:80.139.124.120]:57282
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225437AbTI2VFR>; Mon, 29 Sep 2003 22:05:17 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8TL53NK026325;
	Mon, 29 Sep 2003 23:05:04 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8TL51lg026324;
	Mon, 29 Sep 2003 23:05:01 +0200
Date: Mon, 29 Sep 2003 23:05:01 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Adeel Malik <AdeelM@avaznet.com>
Cc: Steffen Malmgaard Mortensen <smm@futarque.com>,
	linux-mips@linux-mips.org
Subject: Re: How to increase download speed for UART
Message-ID: <20030929210501.GA4231@linux-mips.org>
References: <10C6C1971DA00C4BB87AC0206E3CA38264ED84@1aurora.enabtech>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264ED84@1aurora.enabtech>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3321
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Sep 29, 2003 at 12:41:02PM +0500, Adeel Malik wrote:

>     The terminal emulator that you specified supports the max. baud rate of
> 115.2 kbps. And it is taking about 7 minutes to download the Kernel Image of
> 4.3 MB. Do you know some other Terminal Emulator that can support a higher
> baud rate ?.
> 
> The UART of the target processor supports the max. baud rate of 406 kbps. So
> I can use the terminal emulator that supports for example, 406kbps, then my
> download time may be further reduced.

115,200 bps is frequently the maximum supported rate of serial interfaces,
so it may be time to find some faster medium.  You may also want to
experiment with compressed kernels.

  Ralf

From narendrasankar@yahoo.com Tue Sep 30 06:44:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 06:45:08 +0100 (BST)
Received: from smtp800.mail.sc5.yahoo.com ([IPv6:::ffff:66.163.168.179]:940
	"HELO smtp800.mail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8225204AbTI3Fo5>; Tue, 30 Sep 2003 06:44:57 +0100
Received: from adsl-67-122-221-97.dsl.snfc21.pacbell.net (HELO 192.168.0.100) (narendrasankar@67.122.221.97 with plain)
  by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 30 Sep 2003 05:44:50 -0000
From: Narendra Sankar <narendrasankar@yahoo.com>
To: Adeel Malik <AdeelM@avaznet.com>
Subject: Re: How to increase download speed for UART
Date: Mon, 29 Sep 2003 22:44:38 -0700
User-Agent: KMail/1.5.9
Cc: linux-mips@linux-mips.org
References: <10C6C1971DA00C4BB87AC0206E3CA38264ED84@1aurora.enabtech>
In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264ED84@1aurora.enabtech>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200309292244.38657.narendrasankar@yahoo.com>
Return-Path: <narendrasankar@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3323
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: narendrasankar@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 5223
Lines: 139

The limitation on download speeds would be determined by the UART on the PC 
you are using. PCs are typically limited to 115200 because of the clock 
generator they use for the UART. However you can buy add-on cards that can 
support up to the 1.5MBaud rate of the 16550. Your local computer store 
should carry one of these. They typically plugin to a PCI slot and you should 
be able to blast down the kernel image to your board.  That is the best way 
to get the 406kbps your board supports.
Also instead of an SREC image, you can tryout the LSI fast-load format. It is 
a base64 encoded image, that some firmware supports (pmon for example). A 
fast-load kernel image is around 1/2 the size of a SREC. I can get a kernel 
image of around 5MB to download in 3 minutes or so via 115200.

Hope that helps
Naren
On Monday 29 September 2003 12:41 am, Adeel Malik wrote:
> Hi,
>     The terminal emulator that you specified supports the max. baud rate of
> 115.2 kbps. And it is taking about 7 minutes to download the Kernel Image
> of 4.3 MB. Do you know some other Terminal Emulator that can support a
> higher baud rate ?.
>
> The UART of the target processor supports the max. baud rate of 406 kbps.
> So I can use the terminal emulator that supports for example, 406kbps, then
> my download time may be further reduced.
>
> Regards,
>
> ADEEL MALIK,
>
>
> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Steffen Malmgaard
> Mortensen
> Sent: Monday, September 29, 2003 11:14 AM
> To: linux-mips@linux-mips.org
> Subject: RE: How to increase download speed for UART
>
>
> Hi
> I have experienced the same problem with HyperTerminal on Win2000. There
> are a number of freeware terminal emulators for Win2000 (eg.
> http://home.planet.nl/~ruurdb/IVT.HTM), so you could try one of those if
> you can't use linux.
> Good luck
> /Steffen
>
> On Fri, 2003-09-26 at 20:13, Mitchell, Earl wrote:
> > You can also get a probe with
> > ethernet support and do it that
> > way.
> >
> > -earlm
> >
> > -----Original Message-----
> > From: Mitchell, Earl [mailto:earlm@mips.com]
> > Sent: Friday, September 26, 2003 11:04 AM
> > To: 'Pete Popov'; Adeel Malik
> > Cc: linux-mips@linux-mips.org
> > Subject: RE: How to increase download speed for UART
> >
> >
> >
> > YAMON only prints '.' feedback for
> > ethernet download, unless you modified it.
> > Download a copy of TeraTerm and use that
> > instead of Hyperterminal. Then you can use
> > the "Send File" command under File pulldown.
> > This gives you feedback showing how many
> > bytes have been transferred.
> >
> > I was able to load a 6.4MB linux srec
> > image in 27 minutes on my Malta 4Kc board
> > with baud rate set to 38.4K. Using TFTP
> > over ethernet it takes 17 seconds. Another
> > alternative is to consider buying an EJTAG probe
> > and loading thru that. The probes will probably load
> > something this size within 1-4 minutes. This
> > is assuming you have EJTAG interface available.
> > But I wouldn't buy a probe just to download
> > code. ;-)
> >
> > -earlm
> >
> > -----Original Message-----
> > From: Pete Popov [mailto:ppopov@mvista.com]
> > Sent: Friday, September 26, 2003 9:09 AM
> > To: Adeel Malik
> > Cc: linux-mips@linux-mips.org
> > Subject: RE: How to increase download speed for UART
> >
> > On Fri, 2003-09-26 at 08:41, Adeel Malik wrote:
> > > Yes this is an Motorola's S-Record File. Do you think that I am missing
> > > something?. I am using YAMON to configure the UART's settings on the
>
> board
>
> > > and HyperTerminal on the Host the transfer this file.
> >
> > Yes, I think there's something definitely wrong. I wonder if the
> > download is even in progress... You're using windows and hyperterm? Try
> > it on linux but just doing "cat <srec file name>  > /dev/ttyS0",
> > assuming you're using the first serial port to connect to the target.
> > Yamon gives you feedback of the download progress by printing dots, when
> > downloading over ethernet. I imagine it does the same when downloading
> > over serial port, so if you are not seeing any progress feedback, then
> > perhaps that's another indication that your download is not working.
> >
> > Pete
> >
> > > ADEEL
> > >
> > >
> > > -----Original Message-----
> > > From: Pete Popov [mailto:ppopov@mvista.com]
> > > Sent: Friday, September 26, 2003 8:45 PM
> > > To: Adeel Malik
> > > Cc: linux-mips@linux-mips.org
> > > Subject: Re: How to increase download speed for UART
> > >
> > > On Fri, 2003-09-26 at 08:32, Adeel Malik wrote:
> > > > Hi All,
> > > >          I am porting Linux to a MIPS based development platform. The
> > > > UART on the board provides a maximum baud rate of 115 kbps. But the
> > > > download time for the kernel Image of about 4.3 MB is about 4 hours
> > > > !!!!!.
> > >
> > > 4.3MB? Is this an SREC file? I've downloaded images over the serial
> > > port (srec files) and it takes no more than 10 minutes.
> > >
> > > Pete
> > >
> > > > Can someone help me address this problem ?.
> > > >
> > > > (I can't download the kernel image via tftp server using ethernet, as
> > > > the CPU doesn't have the MAC interface).
> > > >
> > > > Regards,
> > > > ADEEL MALIK,

From AdeelM@avaznet.com Tue Sep 30 10:12:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 10:12:25 +0100 (BST)
Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:47034
	"EHLO 1aurora.enabtech") by linux-mips.org with ESMTP
	id <S8225391AbTI3JMU>; Tue, 30 Sep 2003 10:12:20 +0100
Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21)
	id <TPC4VWDF>; Tue, 30 Sep 2003 14:05:20 +0500
Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264EDDC@1aurora.enabtech>
From: Adeel Malik <AdeelM@avaznet.com>
To: linux-mips@linux-mips.org
Subject: How to generate the kernel image binary file for a specific memor
	y area
Date: Tue, 30 Sep 2003 14:05:17 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38731.F7D48ED0"
Return-Path: <AdeelM@avaznet.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3324
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: AdeelM@avaznet.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3638
Lines: 72

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C38731.F7D48ED0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
        I am using Buildroot-QuickMIPS development environment for porting
linux-based applications to a development board. When I run the 'make'
command in the Top level Buildroot folder, the Kernel Image file generated
in srec format defaults to the address where the SDRAM is mapped. In this
way I am able to boot the kernel form SDRAM. I want to load the image to
flash (mapped to some other address) and boot the kernel from it. Can
someone having worked on Buildroot tell me where to locate the linker
directive file and make the necessary change so that I can generate the
Image for a specific memory area.
 
Presently I use the Boot Monitor's load command that stores the Image file
from some server configured as boot server to Target SDRAM and kernel is
executed by issuing the go command. I want to know whether the download
mechanism would remain the same for booting the kernel from Flash as from
SDRAM or I may need to use some ROM directive in the Linker directive file
so that on reset the code is moved from flash to SDRAM and executed from
there.
 
Regards,
 
ADEEL MALIK,
 


------_=_NextPart_001_01C38731.F7D48ED0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY style="COLOR: #000000; FONT-FAMILY: Arial" hb_focus_attach="true">
<DIV><SPAN class=102094808-30092003><FONT size=2>Hi All,</FONT></SPAN></DIV>
<DIV><SPAN class=102094808-30092003><FONT 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am using 
<STRONG>Buildroot-QuickMIPS </STRONG>development environment for porting 
linux-based applications to a development board. When I run the 'make' command 
in the&nbsp;Top level&nbsp;Buildroot&nbsp;folder, the Kernel Image file 
generated in <STRONG>srec format</STRONG> defaults to the address where the 
SDRAM is mapped. In this way I am able to&nbsp;boot the kernel form 
SDRAM.&nbsp;I want to load the image to flash (mapped to some other address) and 
boot the kernel from it. Can someone having worked on Buildroot tell me where to 
locate the linker directive file and make the necessary change so that I can 
generate the Image for a specific memory area.</FONT></SPAN></DIV>
<DIV><SPAN class=102094808-30092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=102094808-30092003><FONT size=2>Presently I use the Boot 
Monitor's load command that stores the Image file from some server configured as 
boot server to Target SDRAM and kernel is executed by issuing the go command. 
</FONT></SPAN><SPAN class=102094808-30092003><FONT size=2>I want to know whether 
the download mechanism would remain the same for booting the kernel from Flash 
as from SDRAM or I may need to use some ROM directive&nbsp;in the Linker 
directive file so that on reset the code is moved from flash to SDRAM and 
executed from there.</FONT></SPAN></DIV>
<DIV><SPAN class=102094808-30092003><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=102094808-30092003><FONT size=2>Regards,</FONT></SPAN></DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM></EM></FONT>&nbsp;</DIV>
<DIV><FONT face=Georgia color=#0000ff size=2><EM>ADEEL MALIK,</EM></FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<P></P></BODY></HTML>

------_=_NextPart_001_01C38731.F7D48ED0--

From rathann@icm.edu.pl Tue Sep 30 12:25:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 12:26:02 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:45749 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225469AbTI3LZu>;
	Tue, 30 Sep 2003 12:25:50 +0100
Received: from rekin.icm.edu.pl (mail@rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.5/icm) with ESMTP id h8UBPdq6027152
	for <linux-mips@linux-mips.org>; Tue, 30 Sep 2003 13:25:40 +0200 (CEST)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1A4IdS-0007Cw-00
	for <linux-mips@linux-mips.org>; Tue, 30 Sep 2003 13:25:42 +0200
Date: Tue, 30 Sep 2003 13:25:42 +0200
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: [Indy] text console
Message-ID: <20030930112541.GE26507@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030926122012.GC19876@icm.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030926122012.GC19876@icm.edu.pl>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3325
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 435
Lines: 13

On Fri, Sep 26, 2003 at 02:20:12PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Hi.
> 
> Is there any way to change the size and refresh rate for the
> text console? I've searched in the mail-list archives and on
> google and came up with nothing.

Doesn't anyone know? Please help or say it's impossible. I'm
stuck with 1280x1024@60Hz which is very uncomfortable to my
eyes.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>

From ladis@linux-mips.org Tue Sep 30 12:41:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 12:41:40 +0100 (BST)
Received: (from localhost user: 'ladis' uid#10009 fake: STDIN
	(ladis@sirjeppe-pt.tunnel.tserv1.fmt.ipv6.he.net)) by linux-mips.org
	id <S8225475AbTI3Lli>; Tue, 30 Sep 2003 12:41:38 +0100
Date: Tue, 30 Sep 2003 12:41:38 +0100
From: Ladislav Michl <ladis@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: [Indy] text console
Message-ID: <20030930124138.B5928@linux-mips.org>
References: <20030926122012.GC19876@icm.edu.pl> <20030930112541.GE26507@icm.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030930112541.GE26507@icm.edu.pl>; from rathann@icm.edu.pl on Tue, Sep 30, 2003 at 01:25:42PM +0200
Return-Path: <ladis@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3326
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 638
Lines: 17

On Tue, Sep 30, 2003 at 01:25:42PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Fri, Sep 26, 2003 at 02:20:12PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > Hi.
> > 
> > Is there any way to change the size and refresh rate for the
> > text console? I've searched in the mail-list archives and on
> > google and came up with nothing.
> 
> Doesn't anyone know? Please help or say it's impossible. I'm
> stuck with 1280x1024@60Hz which is very uncomfortable to my
> eyes.

newport_con nor newport xfree86 driver doesn't perform any VC2
programing. that means that there is currently no way to setup
refresh rate from linux.

	ladis

From agx@sigxcpu.org Tue Sep 30 14:52:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 14:53:16 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:42145
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225474AbTI3Nwo>; Tue, 30 Sep 2003 14:52:44 +0100
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 4A4D42BC41
	for <linux-mips@linux-mips.org>; Tue, 30 Sep 2003 15:52:31 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 09513-10
 for <linux-mips@linux-mips.org>; Tue, 30 Sep 2003 15:51:58 +0200 (CEST)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id A4E222BC39
	for <linux-mips@linux-mips.org>; Tue, 30 Sep 2003 15:51:58 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 1339E4256; Tue, 30 Sep 2003 15:58:46 +0200 (CEST)
Date: Tue, 30 Sep 2003 15:58:46 +0200
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: [Indy] text console
Message-ID: <20030930135846.GB761@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030926122012.GC19876@icm.edu.pl> <20030930112541.GE26507@icm.edu.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6"
Content-Disposition: inline
In-Reply-To: <20030930112541.GE26507@icm.edu.pl>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian)
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3327
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips
Content-Length: 851
Lines: 28


--v9Ux+11Zm5mwPlX6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Sep 30, 2003 at 01:25:42PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Doesn't anyone know? Please help or say it's impossible. I'm
> stuck with 1280x1024@60Hz which is very uncomfortable to my
> eyes.
Try the "monitor" PROM variable to switch to 1024x768. See:
 http://www.parallab.uib.no/SGI_bookshelves/SGI_Admin/books/IA_ConfigOps/sgi_html/ch09.html#LE63851-PARENT
Cheers,
 -- Guido

--v9Ux+11Zm5mwPlX6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/eYwWn88szT8+ZCYRAs2JAJ9vblHl8JwPdQNtbabWku5pxHANgACeJ5mq
vNz3C1J+YuHgL4z7Zx+LK4s=
=YSfz
-----END PGP SIGNATURE-----

--v9Ux+11Zm5mwPlX6--

From durai@isofttech.com Tue Sep 30 15:04:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 15:04:29 +0100 (BST)
Received: from [IPv6:::ffff:203.199.202.17] ([IPv6:::ffff:203.199.202.17]:49677
	"EHLO pub.isofttechindia.com") by linux-mips.org with ESMTP
	id <S8225474AbTI3OEV>; Tue, 30 Sep 2003 15:04:21 +0100
Received: from DURAI ([192.168.0.180])
	by pub.isofttechindia.com (8.11.0/8.11.0) with SMTP id h8UDxxY29096
	for <linux-mips@linux-mips.org>; Tue, 30 Sep 2003 19:29:59 +0530
Message-ID: <005601c3875b$b2badbf0$b400a8c0@DURAI>
From: "durai" <durai@isofttech.com>
To: "mips" <linux-mips@linux-mips.org>
Subject: Anybody ported ISL3890 driver to Mips platform?
Date: Tue, 30 Sep 2003 19:34:00 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0053_01C38789.CC673110"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-MailScanner: Found to be clean
Return-Path: <durai@isofttech.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3328
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: durai@isofttech.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3962
Lines: 92

This is a multi-part message in MIME format.

------=_NextPart_000_0053_01C38789.CC673110
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


   =20
Hello,
Have anybody tried porting ISL3890 (Intersil PRISM GT minipci wireless =
lan)  driver to uclinux. Actually I am porting it to MIPS platform, and =
facing some problems.
If somebody is working on it or already finished it, please send me some =
guidance,
regards
durai

-------------------------------------------------------------------------=
-------------------------------------------------
Durai Raj P
Senior Software Engineer,                                   Tel    : +91 =
(44) 2436 4915=20
Integrated Softtech Solutions Pvt Ltd,                   Fax  : +91 (44) =
2436 4914=20
Third Floor,                                                         =
www.isofttech.com
TPL  House,                                                       =
durai@isofttech.com
#3, Cenotaph Road,
Chennai 600 018, INDIA
-------------------------------------------------------------------------=
-------------------------------------------------

------=_NextPart_000_0053_01C38789.CC673110
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">&nbsp;&nbsp;&nbsp; </DIV>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Have anybody tried porting ISL3890 =
(Intersil PRISM=20
GT minipci wireless lan)&nbsp; driver to uclinux. Actually I am porting =
it to=20
MIPS platform, and facing some problems.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If somebody is working on it or already =
finished=20
it, please send me some guidance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>durai</FONT></DIV><FONT face=3DArial =
size=3D2>
<DIV><BR>----------------------------------------------------------------=
----------------------------------------------------------<BR>Durai=20
Raj P<BR>Senior Software=20
Engineer,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
Tel&nbsp;&nbsp;&nbsp;=20
: +91 (44) 2436 4915 <BR>Integrated Softtech Solutions Pvt=20
Ltd,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Fax&nbsp;=20
: +91 (44) 2436 4914 <BR>Third=20
Floor,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A=20
href=3D"http://www.isofttech.com">www.isofttech.com</A><BR>TPL&nbsp;=20
House,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A=20
href=3D"mailto:durai@isofttech.com">durai@isofttech.com</A><BR>#3, =
Cenotaph=20
Road,<BR>Chennai 600 018,=20
INDIA<BR>----------------------------------------------------------------=
----------------------------------------------------------</DIV>
<DIV>&nbsp;</DIV></FONT></BODY></HTML>

------=_NextPart_000_0053_01C38789.CC673110--


From kwalker@broadcom.com Tue Sep 30 15:49:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 15:49:50 +0100 (BST)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:59652 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225479AbTI3Otp>; Tue, 30 Sep 2003 15:49:45 +0100
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.3)); Tue, 30 Sep 2003 07:49:43 -0700
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 HAA07119; Tue, 30 Sep 2003 07:49:03 -0700 (PDT)
Received: from broadcom.com (ldt-sj3-158 [10.21.64.158]) by
 mail-sj1-1.sj.broadcom.com (8.12.9/8.12.4/SSM) with ESMTP id
 h8UEnVKX021119; Tue, 30 Sep 2003 07:49:31 -0700 (PDT)
Message-ID: <3F7997FB.7159F7A@broadcom.com>
Date: Tue, 30 Sep 2003 07:49:31 -0700
From: "Kip Walker" <kwalker@broadcom.com>
Organization: Broadcom Corp. BPBU
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.20-18.7 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Finney, Steve" <Steve.Finney@spirentcom.com>
cc: "Michael Uhler" <uhler@mips.com>, linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75C@iris.adtech-inc.com>
 <1064862114.11818.21.camel@uhler-linux.mips.com>
X-WSS-ID: 1367478D1895670-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <kwalker@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3329
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kwalker@broadcom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 945
Lines: 17

Michael Uhler wrote:
> 
> On Mon, 2003-09-29 at 10:31, Finney, Steve wrote:
> > What would be the downside to enabling 64 bit operations in user space on a 32 bit kernel (setting the PX bit in the status register?). The particular issue is that I want to access 64 bit-memory mapped registers, and I really need to do it as an atomic operation. I tried borrowing sibyte/64bit.h from the kernel, but I get an illegal instruction on the double ops.
> >
> The most glaring problem is you violate the rule that the 64-bit GPRs
> are sign-extended when running a 32-bit binary.  There are all kinds
> of assumptions in the hardware and software that depend on the
> GPRs being sign-extended, and to violate this will risk some
> serious instability of the software.

Not to mention that the kernel won't preserve the upper 32 bits across
interrupts and system calls, if you even manage to get 64-bit values in
the registers in the first place.

Kip


From ralf@linux-mips.org Tue Sep 30 17:00:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 17:00:29 +0100 (BST)
Received: from p508B5F50.dip.t-dialin.net ([IPv6:::ffff:80.139.95.80]:41371
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225474AbTI3QAZ>; Tue, 30 Sep 2003 17:00:25 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8UG0NNK009848;
	Tue, 30 Sep 2003 18:00:23 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8UG0NUI009847;
	Tue, 30 Sep 2003 18:00:23 +0200
Date: Tue, 30 Sep 2003 18:00:23 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
Cc: linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
Message-ID: <20030930160023.GB4231@linux-mips.org>
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75C@iris.adtech-inc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75C@iris.adtech-inc.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3330
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1119
Lines: 25

On Mon, Sep 29, 2003 at 07:31:57AM -1000, Finney, Steve wrote:

> What would be the downside to enabling 64 bit operations in user space
> on a 32 bit kernel (setting the PX bit in the status register?). The
> particular issue is that I want to access 64 bit-memory mapped registers,
> and I really need to do it as an atomic operation. I tried borrowing
> sibyte/64bit.h from the kernel, but I get an illegal instruction on the
> double ops.

Common design bug in hardware, imho ...

> Also, assuming this isn't a horrible idea, is there any obvious single
> place where "default" values in the CP0 status register get set?

There isn't.

What you want really is a 64-bit kernel.  On a 64-bit kernel even for
processes running in 32-bit address spaces (o32, N32) the processor
will run with the UX bit enabled.  o32 userspace still lives in the
assumption that registers are 32-bit so only those bits will be restored
in function calls etc.  N32 (where userspace isn't ready for prime time
yet) does guarantee that.  And N64 (userspace similarly not ready for
prime time) obviously is fully 64-bit everything.

  Ralf

From macro@ds2.pg.gda.pl Tue Sep 30 19:04:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 19:04:48 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:56773 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225474AbTI3SEq>; Tue, 30 Sep 2003 19:04:46 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA13163;
	Tue, 30 Sep 2003 20:04:43 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 30 Sep 2003 20:04:42 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Finney, Steve" <Steve.Finney@SpirentCom.COM>,
	linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
In-Reply-To: <20030930160023.GB4231@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030930195415.11368C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3331
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 789
Lines: 19

On Tue, 30 Sep 2003, Ralf Baechle wrote:

> > What would be the downside to enabling 64 bit operations in user space
> > on a 32 bit kernel (setting the PX bit in the status register?). The
> > particular issue is that I want to access 64 bit-memory mapped registers,
> > and I really need to do it as an atomic operation. I tried borrowing
> > sibyte/64bit.h from the kernel, but I get an illegal instruction on the
> > double ops.
> 
> Common design bug in hardware, imho ...

 Well, ioremap() can be used to get at these areas (as well as any
others), whether we call it a bug or not.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From uhler@mips.com Tue Sep 30 19:28:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 19:29:04 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:41167 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225474AbTI3S2b>;
	Tue, 30 Sep 2003 19:28:31 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h8UIPqYY022467;
	Tue, 30 Sep 2003 11:25:52 -0700 (PDT)
Received: from uhler-linux.mips.com (uhler-linux [192.168.65.120])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA12735;
	Tue, 30 Sep 2003 11:29:28 -0700 (PDT)
Subject: Re: 64 bit operations w/32 bit kernel
From: Michael Uhler <uhler@mips.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Finney, Steve" <Steve.Finney@spirentcom.com>,
	linux-mips@linux-mips.org
In-Reply-To: <20030930160023.GB4231@linux-mips.org>
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75C@iris.adtech-inc.com>
	 <20030930160023.GB4231@linux-mips.org>
Content-Type: text/plain
Organization: MIPS Technologies, Inc.
Message-Id: <1064946568.13742.51.camel@uhler-linux.mips.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.0 
Date: 30 Sep 2003 11:29:28 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3332
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1855
Lines: 45

On Tue, 2003-09-30 at 09:00, Ralf Baechle wrote:
> On Mon, Sep 29, 2003 at 07:31:57AM -1000, Finney, Steve wrote:
> 
> > What would be the downside to enabling 64 bit operations in user space
> > on a 32 bit kernel (setting the PX bit in the status register?). The
> > particular issue is that I want to access 64 bit-memory mapped registers,
> > and I really need to do it as an atomic operation. I tried borrowing
> > sibyte/64bit.h from the kernel, but I get an illegal instruction on the
> > double ops.
> 
> Common design bug in hardware, imho ...
> 
> > Also, assuming this isn't a horrible idea, is there any obvious single
> > place where "default" values in the CP0 status register get set?
> 
> There isn't.
> 
> What you want really is a 64-bit kernel.  On a 64-bit kernel even for
> processes running in 32-bit address spaces (o32, N32) the processor
> will run with the UX bit enabled.  o32 userspace still lives in the
> assumption that registers are 32-bit so only those bits will be restored
> in function calls etc.  N32 (where userspace isn't ready for prime time
> yet) does guarantee that.  And N64 (userspace similarly not ready for
> prime time) obviously is fully 64-bit everything.

I don't think you want to run o32 processes with the UX bit set.  UX not
only enables 64-bit addressing (which you can, in software, make look
like 32-bit addressing), it also enables access to the 64-bit opcodes.
This means that you are going to get unexpected and potentially
unreproducible results.

N32 is a 64-bit data model with 32-bit addresses, so you're OK there.

/gmu

> 
>   Ralf
-- 

Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.  Email: uhler@mips.com  Pager:uhler_p@mips.com
1225 Charleston Road     Voice:  (650)567-5025  FAX:   (650)567-5225
Mountain View, CA 94043  Mobile: (650)868-6870  Admin: (650)567-5085



From skottilingal@kinetowireless.com Tue Sep 30 19:38:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 19:38:13 +0100 (BST)
Received: from 66-126-253-28.ded.pacbell.net ([IPv6:::ffff:66.126.253.28]:29705
	"EHLO blunote.bluzona.com") by linux-mips.org with ESMTP
	id <S8225474AbTI3SiB>; Tue, 30 Sep 2003 19:38:01 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C38781.F17AA991"
Subject: Backtrace capability
Date: Tue, 30 Sep 2003 11:37:46 -0700
Message-ID: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E117960E@blunote.bluzona.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Backtrace capability
Thread-Index: AcOHgfFyYmJVB4rfRLq7BbQIOJuDaw==
From: "Sudeep Kottilingal" <skottilingal@kinetowireless.com>
To: <linux-mips@linux-mips.org>
Cc: "Joe Baranowski" <jbaranowski@kinetowireless.com>
Return-Path: <skottilingal@kinetowireless.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3333
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: skottilingal@kinetowireless.com
Precedence: bulk
X-list: linux-mips
Content-Length: 8167
Lines: 267

This is a multi-part message in MIME format.

------_=_NextPart_001_01C38781.F17AA991
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
=20
I am trying to debug some SIGSEGV when I leave my system ON for a few
days. At the time of the
Crash I am not able to get a nice back-trace/stack trace yet. (I do not
see the execinfo.h file on my uclibc toolchain
Which implies its not supported yet on my toolchain release).
=20
=20
Has anyone had success in incorporating backtrace capability into a
uclibc binary yet ...?
If your answer is yes, could u give me some pointers on how to do it and
set it up ..?
=20
=20
If your answer is no is there any other alternative set up to get more
information.
I do not run an ICD or ICE on my board. Neither do I have a serial
console. My console is redirected via Telnet.
=20
=20
Currently I am running the application which crashes on the linux PC
through totalview debugger.
Waiting for it to crash.
=20
sudeep

------_=_NextPart_001_01C38781.F17AA991
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C38747.45109BD0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi all,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I am trying to debug some SIGSEGV when I leave my =
system ON
for a few days. At the time of the<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Crash I am not able to get a nice back-trace/stack =
trace yet.
(I do not see the <span class=3DSpellE>execinfo.h</span> file on my =
<span
class=3DSpellE>uclibc</span> <span =
class=3DSpellE>toolchain</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Which implies <span class=3DGramE>its</span> not =
supported yet
on my <span class=3DSpellE>toolchain</span> =
release).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b style=3D'mso-bidi-font-weight:normal'><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold;
mso-bidi-font-weight:normal'>Has anyone had success in incorporating =
<span
class=3DSpellE>backtrace</span> capability into <span =
class=3DGramE>a</span> <span
class=3DSpellE>uclibc</span> binary yet =
&#8230;?<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b style=3D'mso-bidi-font-weight:normal'><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold;
mso-bidi-font-weight:normal'>If your answer is yes, could u give me some
pointers on how to do it and set it <span class=3DGramE>up =
..?</span><o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b style=3D'mso-bidi-font-weight:normal'><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold;
mso-bidi-font-weight:normal'>If your answer is no is there any other
alternative set up to get more =
information.<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I do not run an ICD or ICE on my board. Neither do I =
have a
serial console. My console is redirected via =
Telnet.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Currently I am running the application which crashes =
on the <span
class=3DSpellE>linux</span> PC through <span =
class=3DSpellE>totalview</span>
debugger.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Waiting for it to =
crash.</span></font></span><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><span class=3DSpellE><span class=3DGramE><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>sudeep</span></font></span><=
/span><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C38781.F17AA991--

From ralf@linux-mips.org Tue Sep 30 19:49:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 19:49:51 +0100 (BST)
Received: from p508B5F50.dip.t-dialin.net ([IPv6:::ffff:80.139.95.80]:46757
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225474AbTI3Stt>; Tue, 30 Sep 2003 19:49:49 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8UIm1NK013678;
	Tue, 30 Sep 2003 20:48:01 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8UIluaY013677;
	Tue, 30 Sep 2003 20:47:56 +0200
Date: Tue, 30 Sep 2003 20:47:55 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Finney, Steve" <Steve.Finney@SpirentCom.COM>,
	linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
Message-ID: <20030930184755.GA12599@linux-mips.org>
References: <20030930160023.GB4231@linux-mips.org> <Pine.GSO.3.96.1030930195415.11368C-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030930195415.11368C-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3334
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1043
Lines: 23

On Tue, Sep 30, 2003 at 08:04:42PM +0200, Maciej W. Rozycki wrote:

> > > What would be the downside to enabling 64 bit operations in user space
> > > on a 32 bit kernel (setting the PX bit in the status register?). The
> > > particular issue is that I want to access 64 bit-memory mapped registers,
> > > and I really need to do it as an atomic operation. I tried borrowing
> > > sibyte/64bit.h from the kernel, but I get an illegal instruction on the
> > > double ops.
> > 
> > Common design bug in hardware, imho ...
> 
>  Well, ioremap() can be used to get at these areas (as well as any
> others), whether we call it a bug or not.

What I called a bug is the necessity to access hardware registers with
64-bit loads and stores in some systems as opposed to of 32-bit
instructions - that simply doesn't work from 32-bit universes.

To clarify, it was my understanding of Steve's problem he needs 64-bit
loads and stores, not something in the 64-bit physical address space.
The later problem obviously would get a different answer.

  Ralf

From macro@ds2.pg.gda.pl Tue Sep 30 20:10:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 20:10:36 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:38855 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225474AbTI3TKe>; Tue, 30 Sep 2003 20:10:34 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA13711;
	Tue, 30 Sep 2003 21:10:28 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 30 Sep 2003 21:10:28 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Michael Uhler <uhler@mips.com>
cc: Ralf Baechle <ralf@linux-mips.org>,
	"Finney, Steve" <Steve.Finney@spirentcom.com>,
	linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
In-Reply-To: <1064946568.13742.51.camel@uhler-linux.mips.com>
Message-ID: <Pine.GSO.3.96.1030930205322.11368E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3335
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1559
Lines: 33

On 30 Sep 2003, Michael Uhler wrote:

> > What you want really is a 64-bit kernel.  On a 64-bit kernel even for
> > processes running in 32-bit address spaces (o32, N32) the processor
> > will run with the UX bit enabled.  o32 userspace still lives in the
> > assumption that registers are 32-bit so only those bits will be restored
> > in function calls etc.  N32 (where userspace isn't ready for prime time
> > yet) does guarantee that.  And N64 (userspace similarly not ready for
> > prime time) obviously is fully 64-bit everything.
> 
> I don't think you want to run o32 processes with the UX bit set.  UX not
> only enables 64-bit addressing (which you can, in software, make look
> like 32-bit addressing), it also enables access to the 64-bit opcodes.
> This means that you are going to get unexpected and potentially
> unreproducible results.

 Well, I think this is OK -- 64-bit opcodes are generally useless for
software built for the o32 ABI, so they should not normally happen in
regular code.  Perhaps some fancy hand-coded assembly might try to use
them to get unusual results, including an invalid opcode trap handler for
the processors that do not support them at all.  But I don't think we
should try to work hard to prevent broken software from shooting into its
foot.

 And the advantage is we have a single TLB refill handler.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From ddaney@avtrex.com Tue Sep 30 20:15:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 20:15:02 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:49067 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225483AbTI3TPA>;
	Tue, 30 Sep 2003 20:15:00 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 30 Sep 2003 12:14:55 -0700
Message-ID: <3F79D62F.5070901@avtrex.com>
Date: Tue, 30 Sep 2003 12:14:55 -0700
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sudeep Kottilingal <skottilingal@kinetowireless.com>
CC: linux-mips@linux-mips.org,
	Joe Baranowski <jbaranowski@kinetowireless.com>
Subject: Re: Backtrace capability
References: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E117960E@blunote.bluzona.com>
In-Reply-To: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E117960E@blunote.bluzona.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 30 Sep 2003 19:14:55.0675 (UTC) FILETIME=[21F820B0:01C38787]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3336
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1321
Lines: 50

Sudeep Kottilingal wrote:

> Hi all,
>
> I am trying to debug some SIGSEGV when I leave my system ON for a few 
> days. At the time of the
>
> Crash I am not able to get a nice back-trace/stack trace yet. (I do 
> not see the execinfo.h file on my uclibc toolchain
>
> Which implies its not supported yet on my toolchain release).
>
> *Has anyone had success in incorporating backtrace capability into a 
> uclibc binary yet …?*
>
> *If your answer is yes, could u give me some pointers on how to do it 
> and set it up ..?*
>
> *If your answer is no is there any other alternative set up to get 
> more information.*
>
> I do not run an ICD or ICE on my board. Neither do I have a serial 
> console. My console is redirected via Telnet.
>
> Currently I am running the application which crashes on the linux PC 
> through totalview debugger.
>
> Waiting for it to crash.
>
> sudeep
>
I hacked together a backtrace that you may be able to adapt. It was 
originally for gcj, but we use several variations for other things as 
well. It kind of relies on an o32 ABI calling convention.

The code is in this mail message:

http://gcc.gnu.org/ml/java-patches/2003-q3/msg00584.html

Look at:

libjava/sysdep/mips/mipsel-backtracer.c
libjava/sysdep/mips/mipsel-backtracer.h
libjava/sysdep/mips/mipsel-bthelper.S

David Daney





From Steve.Finney@SpirentCom.COM Tue Sep 30 20:23:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 20:23:24 +0100 (BST)
Received: from Iris.Adtech-Inc.COM ([IPv6:::ffff:63.165.80.18]:16103 "EHLO
	iris.Adtech-Inc.COM") by linux-mips.org with ESMTP
	id <S8225481AbTI3TXM> convert rfc822-to-8bit; Tue, 30 Sep 2003 20:23:12 +0100
content-class: urn:content-classes:message
Subject: RE: 64 bit operations w/32 bit kernel
Date: Tue, 30 Sep 2003 09:23:05 -1000
Message-ID: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75F@iris.adtech-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 64 bit operations w/32 bit kernel
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcOHa/iHA4w76B2aTZ2Vd+J8J8pAgQAG5J6Q
From: "Finney, Steve" <Steve.Finney@SpirentCom.COM>
To: "Ralf Baechle" <ralf@linux-mips.org>,
	"Finney, Steve" <Steve.Finney@SpirentCom.COM>
Cc: <linux-mips@linux-mips.org>
Return-Path: <Steve.Finney@SpirentCom.COM>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3337
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Steve.Finney@SpirentCom.COM
Precedence: bulk
X-list: linux-mips
Content-Length: 858
Lines: 15

> 
> What you want really is a 64-bit kernel.  On a 64-bit kernel even for
> processes running in 32-bit address spaces (o32, N32) the processor
> will run with the UX bit enabled.  o32 userspace still lives in the
> assumption that registers are 32-bit so only those bits will 
> be restored
> in function calls etc.  N32 (where userspace isn't ready for 
> prime time
> yet) does guarantee that.  And N64 (userspace similarly not ready for
> prime time) obviously is fully 64-bit everything.

What is the page table space impact of a 64 bit kernel on an architecture like the Sibyte with discontiguous physical address spaces?  Do you still waste 36 MB of page table space on the "hole", or does it even double because the page table entries are bigger for the wider addresses? Or do the issues become irrelevant with the larger address space?

Thanks,
sf

From uhler@mips.com Tue Sep 30 20:29:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 20:29:33 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:2513 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225488AbTI3T3B>;
	Tue, 30 Sep 2003 20:29:01 +0100
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h8UJNxYY023178;
	Tue, 30 Sep 2003 12:23:59 -0700 (PDT)
Received: from uhler-linux.mips.com (uhler-linux [192.168.65.120])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA13818;
	Tue, 30 Sep 2003 12:27:36 -0700 (PDT)
Subject: Re: 64 bit operations w/32 bit kernel
From: Michael Uhler <uhler@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	"Finney, Steve" <Steve.Finney@spirentcom.com>,
	linux-mips@linux-mips.org
In-Reply-To: <Pine.GSO.3.96.1030930205322.11368E-100000@delta.ds2.pg.gda.pl>
References: <Pine.GSO.3.96.1030930205322.11368E-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain
Organization: MIPS Technologies, Inc.
Message-Id: <1064950055.12992.99.camel@uhler-linux.mips.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.0 
Date: 30 Sep 2003 12:27:36 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3338
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2621
Lines: 56

On Tue, 2003-09-30 at 12:10, Maciej W. Rozycki wrote:
> On 30 Sep 2003, Michael Uhler wrote:
> 
> > > What you want really is a 64-bit kernel.  On a 64-bit kernel even for
> > > processes running in 32-bit address spaces (o32, N32) the processor
> > > will run with the UX bit enabled.  o32 userspace still lives in the
> > > assumption that registers are 32-bit so only those bits will be restored
> > > in function calls etc.  N32 (where userspace isn't ready for prime time
> > > yet) does guarantee that.  And N64 (userspace similarly not ready for
> > > prime time) obviously is fully 64-bit everything.
> > 
> > I don't think you want to run o32 processes with the UX bit set.  UX not
> > only enables 64-bit addressing (which you can, in software, make look
> > like 32-bit addressing), it also enables access to the 64-bit opcodes.
> > This means that you are going to get unexpected and potentially
> > unreproducible results.
> 
>  Well, I think this is OK -- 64-bit opcodes are generally useless for
> software built for the o32 ABI, so they should not normally happen in
> regular code.  Perhaps some fancy hand-coded assembly might try to use
> them to get unusual results, including an invalid opcode trap handler for
> the processors that do not support them at all.  But I don't think we
> should try to work hard to prevent broken software from shooting into its
> foot.

I'm not a real fan of architecting software to dismiss broken (or rogue)
programs since it tends to open up a whole lot of holes that cause
O/S crashes.  For instance, an o32 program should never be able to pass
a non-sign-extended value thru a GPR to the O/S in a system call.  How
many places in the O/S implicitly assume this is true?  The architecture
was never intended to run real 32-bit programs with 64-bit ops enabled,
and I would strongly urge you not to do this now.

> 
>  And the advantage is we have a single TLB refill handler.

This hardly seems compelling given how short the handlers are.  Further,
since N64 needs the 64-bit address support anyway, setting UX and PX
correctly will allow you to run the N32 code with the TLB handler
instead of the XTLB handler.  That way the XTLB handler is only
invoked when a real extended address reference happens.  That seems
cleaner to me, but I admit I'm not the one that has to write the
code.

/gmu

> 
>   Maciej
-- 

Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.  Email: uhler@mips.com  Pager:uhler_p@mips.com
1225 Charleston Road     Voice:  (650)567-5025  FAX:   (650)567-5225
Mountain View, CA 94043  Mobile: (650)868-6870  Admin: (650)567-5085



From ralf@linux-mips.org Tue Sep 30 20:48:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 30 Sep 2003 20:48:49 +0100 (BST)
Received: from p508B5F50.dip.t-dialin.net ([IPv6:::ffff:80.139.95.80]:18601
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225477AbTI3Tsp>; Tue, 30 Sep 2003 20:48:45 +0100
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id h8UJmiNK014944;
	Tue, 30 Sep 2003 21:48:44 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h8UJmhqr014943;
	Tue, 30 Sep 2003 21:48:43 +0200
Date: Tue, 30 Sep 2003 21:48:43 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Michael Uhler <uhler@mips.com>
Cc: "Finney, Steve" <Steve.Finney@spirentcom.com>,
	linux-mips@linux-mips.org
Subject: Re: 64 bit operations w/32 bit kernel
Message-ID: <20030930194843.GB12599@linux-mips.org>
References: <DC1BF43A8FAE654DA6B3FB7836DD3A56DEB75C@iris.adtech-inc.com> <20030930160023.GB4231@linux-mips.org> <1064946568.13742.51.camel@uhler-linux.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1064946568.13742.51.camel@uhler-linux.mips.com>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 3339
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1305
Lines: 27

On Tue, Sep 30, 2003 at 11:29:28AM -0700, Michael Uhler wrote:

> > There isn't.
> > 
> > What you want really is a 64-bit kernel.  On a 64-bit kernel even for
> > processes running in 32-bit address spaces (o32, N32) the processor
> > will run with the UX bit enabled.  o32 userspace still lives in the
> > assumption that registers are 32-bit so only those bits will be restored
> > in function calls etc.  N32 (where userspace isn't ready for prime time
> > yet) does guarantee that.  And N64 (userspace similarly not ready for
> > prime time) obviously is fully 64-bit everything.
> 
> I don't think you want to run o32 processes with the UX bit set.  UX not
> only enables 64-bit addressing (which you can, in software, make look
> like 32-bit addressing), it also enables access to the 64-bit opcodes.
> This means that you are going to get unexpected and potentially
> unreproducible results.

Currently the 64-bit kernel is running everything in userspace with UX
enabled, in part that's lazyness, in part it was also made in the hope
optimized libraries for o32 would take advantage of 64-bit computing.

Linux btw. doesn't use the MIPS64 PX flag.  It's only supported on MIPS64
and it we simply didn't consider it's use much of a benefit so far -
something that probably is arguable ...

  Ralf