From ilya@gateway.total-knowledge.com Tue Jul  1 00:35:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 00:35:03 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:35970
	"HELO alpha.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225212AbTF3XfA>; Tue, 1 Jul 2003 00:35:00 +0100
Received: (qmail 31335 invoked from network); 30 Jun 2003 16:27:45 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 30 Jun 2003 16:27:45 -0000
Received: (qmail 16941 invoked by uid 502); 30 Jun 2003 23:34:58 -0000
Date: Mon, 30 Jun 2003 16:34:58 -0700
From: ilya@theIlya.com
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: CRIME memory error reporting rewrite
Message-ID: <20030630233458.GT13617@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="aH/0uqREc1VzwMkO"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2735
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


--aH/0uqREc1VzwMkO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

This is Keith's rewrite of CRIME memory error interrupt.
Works perfectly here, and makes life lot easier sometimes.
Plus it converts yet another irq handler to return irqreturn_t.


--aH/0uqREc1VzwMkO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="crime.diff"

Index: arch/mips/sgi-ip32/crime.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip32/crime.c,v
retrieving revision 1.2
diff -u -r1.2 crime.c
--- arch/mips/sgi-ip32/crime.c	6 Aug 2002 00:08:57 -0000	1.2
+++ arch/mips/sgi-ip32/crime.c	30 Jun 2003 23:26:54 -0000
@@ -3,13 +3,17 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 2001 Keith M Wesolowski
+ * Copyright (C) 2001, 2003 Keith M Wesolowski
  */
+#include <asm/ip32/crime.h>
+#include <asm/ptrace.h>
+#include <asm/bootinfo.h>
+#include <asm/page.h>
+#include <asm/mipsregs.h>
 #include <linux/types.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
-#include <asm/ip32/crime.h>
-#include <asm/ptrace.h>
+#include <linux/interrupt.h>
 
 void __init crime_init (void)
 {
@@ -18,32 +22,75 @@
 
 	id = (id & CRIME_ID_IDBITS) >> 4;
 
-	printk ("CRIME id %1lx rev %ld detected at %016lx\n", id, rev,
+	printk ("CRIME id %1lx rev %ld detected at 0x%016lx\n", id, rev,
 		(unsigned long) CRIME_BASE);
 }
 
-/* XXX Like on Sun, these give us various useful information to printk. */
-void crime_memerr_intr (unsigned int irq, void *dev_id, struct pt_regs *regs)
+irqreturn_t crime_memerr_intr (unsigned int irq, void *dev_id, struct pt_regs *regs)
 {
 	u64 memerr = crime_read_64 (CRIME_MEM_ERROR_STAT);
 	u64 addr = crime_read_64 (CRIME_MEM_ERROR_ADDR);
+	int fatal = 0;
+
 	memerr &= CRIME_MEM_ERROR_STAT_MASK;
+	addr &= CRIME_MEM_ERROR_ADDR_MASK;
+
+	printk("CRIME memory error at 0x%08lx ST 0x%08lx<", addr, memerr);
 
-	printk ("CRIME memory error at physaddr 0x%08lx status %08lx\n",
-		addr << 2, memerr);
+	if (memerr & CRIME_MEM_ERROR_INV)
+		printk("INV,");
+	if (memerr & CRIME_MEM_ERROR_ECC) {
+		u64 ecc_syn = crime_read_64(CRIME_MEM_ERROR_ECC_SYN);
+		u64 ecc_gen = crime_read_64(CRIME_MEM_ERROR_ECC_CHK);
+
+		ecc_syn &= CRIME_MEM_ERROR_ECC_SYN_MASK;
+		ecc_gen &= CRIME_MEM_ERROR_ECC_CHK_MASK;
+
+		printk("ECC,SYN=0x%08lx,GEN=0x%08lx,", ecc_syn, ecc_gen);
+	}
+	if (memerr & CRIME_MEM_ERROR_MULTIPLE) {
+		fatal = 1;
+		printk("MULTIPLE,");
+	}
+	if (memerr & CRIME_MEM_ERROR_HARD_ERR) {
+		fatal = 1;
+		printk("HARD,");
+	}
+	if (memerr & CRIME_MEM_ERROR_SOFT_ERR)
+		printk("SOFT,");
+	if (memerr & CRIME_MEM_ERROR_CPU_ACCESS)
+		printk("CPU,");
+	if (memerr & CRIME_MEM_ERROR_VICE_ACCESS)
+		printk("VICE,");
+	if (memerr & CRIME_MEM_ERROR_GBE_ACCESS)
+		printk("GBE,");
+	if (memerr & CRIME_MEM_ERROR_RE_ACCESS)
+		printk("RE,REID=0x%02lx,", (memerr & CRIME_MEM_ERROR_RE_ID)>>8);
+	if (memerr & CRIME_MEM_ERROR_MACE_ACCESS)
+		printk("MACE,MACEID=0x%02lx,", memerr & CRIME_MEM_ERROR_MACE_ID);
 
 	crime_write_64 (CRIME_MEM_ERROR_STAT, 0);
+
+	if (fatal) {
+		printk("FATAL>\n");
+		panic("Fatal memory error detected, halting\n");
+	} else {
+		printk("NONFATAL>\n");
+	}
+
+	return IRQ_HANDLED;
 }
 
-void crime_cpuerr_intr (unsigned int irq, void *dev_id, struct pt_regs *regs)
+irqreturn_t crime_cpuerr_intr (unsigned int irq, void *dev_id, struct pt_regs *regs)
 {
 	u64 cpuerr = crime_read_64 (CRIME_CPU_ERROR_STAT);
 	u64 addr = crime_read_64 (CRIME_CPU_ERROR_ADDR);
 	cpuerr &= CRIME_CPU_ERROR_MASK;
 	addr <<= 2UL;
 
-	printk ("CRIME CPU interface error detected at %09lx status %08lx\n",
+	printk ("CRIME CPU error detected at 0x%09lx status 0x%08lx\n",
 		addr, cpuerr);
 
 	crime_write_64 (CRIME_CPU_ERROR_STAT, 0);
+	return IRQ_HANDLED;
 }
Index: include/asm-mips64/ip32/crime.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/ip32/crime.h,v
retrieving revision 1.3
diff -u -r1.3 crime.h
--- include/asm-mips64/ip32/crime.h	27 Jun 2002 14:27:11 -0000	1.3
+++ include/asm-mips64/ip32/crime.h	30 Jun 2003 23:27:12 -0000
@@ -11,6 +11,7 @@
 #ifndef __ASM_CRIME_H__
 #define __ASM_CRIME_H__
 
+#include <asm/types.h>
 #include <asm/addrspace.h>
 
 /*
@@ -179,11 +180,9 @@
  * macros for CRIME memory bank control registers.
  */
 #define CRIME_MEM_BANK_CONTROL(__bank)		(0x00000208 + ((__bank) << 3))
-#define CRIME_MEM_BANK_CONTROL_MSK		0x11f /* 9 bits 7:5 reserved */
+#define CRIME_MEM_BANK_CONTROL_MASK		0x11f /* 9 bits 7:5 reserved */
 #define CRIME_MEM_BANK_CONTROL_ADDR		0x01f
 #define CRIME_MEM_BANK_CONTROL_SDRAM_SIZE	0x100
-#define CRIME_MEM_BANK_CONTROL_BANK_TO_ADDR(__bank) \
-	(((__bank) & CRIME_MEM_BANK_CONTROL_ADDR) << 25)
 
 #define CRIME_MEM_REFRESH_COUNTER	(0x00000248)
 #define CRIME_MEM_REFRESH_COUNTER_MASK	0x7ff	/* 11-bit register */
@@ -206,8 +205,10 @@
 #define CRIME_MEM_ERROR_SOFT_ERR	0x00100000
 #define CRIME_MEM_ERROR_HARD_ERR	0x00200000
 #define CRIME_MEM_ERROR_MULTIPLE	0x00400000
+#define CRIME_MEM_ERROR_ECC		0x01800000
 #define CRIME_MEM_ERROR_MEM_ECC_RD	0x00800000
 #define CRIME_MEM_ERROR_MEM_ECC_RMW	0x01000000
+#define CRIME_MEM_ERROR_INV		0x0e000000
 #define CRIME_MEM_ERROR_INV_MEM_ADDR_RD	0x02000000
 #define CRIME_MEM_ERROR_INV_MEM_ADDR_WR	0x04000000
 #define CRIME_MEM_ERROR_INV_MEM_ADDR_RMW	0x08000000

--aH/0uqREc1VzwMkO--

From ralf@linux-mips.org Tue Jul  1 11:33:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 11:33:02 +0100 (BST)
Received: from p508B6FF8.dip.t-dialin.net ([IPv6:::ffff:80.139.111.248]:43173
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225205AbTGAKdA>; Tue, 1 Jul 2003 11:33:00 +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 h61AWvDB011409;
	Tue, 1 Jul 2003 12:32:57 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h61AWuA7011408;
	Tue, 1 Jul 2003 12:32:56 +0200
Date: Tue, 1 Jul 2003 12:32:56 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: ilya@theIlya.com
Cc: linux-mips@linux-mips.org
Subject: Re: CRIME memory error reporting rewrite
Message-ID: <20030701103256.GA11366@linux-mips.org>
References: <20030630233458.GT13617@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030630233458.GT13617@gateway.total-knowledge.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: 2736
X-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, Jun 30, 2003 at 04:34:58PM -0700, ilya@theIlya.com wrote:

> This is Keith's rewrite of CRIME memory error interrupt.
> Works perfectly here, and makes life lot easier sometimes.
> Plus it converts yet another irq handler to return irqreturn_t.

Applied,

  Ralf

From ik@grex.cyberspace.org Tue Jul  1 13:39:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 13:39:16 +0100 (BST)
Received: from grex.cyberspace.org ([IPv6:::ffff:216.93.104.34]:52753 "HELO
	grex.cyberspace.org") by linux-mips.org with SMTP
	id <S8224861AbTGAMjM>; Tue, 1 Jul 2003 13:39:12 +0100
Received: from localhost (ik@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id IAA01150; Tue, 1 Jul 2003 08:39:03 -0400
Date: Tue, 1 Jul 2003 08:39:02 -0400 (EDT)
From: <ik@cyberspace.org>
To: <ralf@linux-mips.org>
cc: <linux-mips@linux-mips.org>
Subject: Re: is there any docs/manuals for linker scripts symbols
In-Reply-To: <20030625121801.GA11496@linux-mips.org>
Message-ID: <Pine.SUN.3.96.1030701083213.315A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ik@grex.cyberspace.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: 2737
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ik@cyberspace.org
Precedence: bulk
X-list: linux-mips

Hi Ralf,

On Wed, 25 Jun 2003 ralf@linux-mips.org wrote:

> On Wed, Jun 25, 2003 at 08:01:24AM -0400, ik@cyberspace.org wrote:
> 
> > My board has a boot loader (rom) that enforce/restricts the sections in
> > the elf header, hence I cannot use the default linker script that comes
> > wit the kernel(arch/mips/). 
> 
> Are you sure the loader actually looks at the sections?  That seems plain
> wrong.  Normally a loader should only look at all the PT_LOAD entries in
> the ELF program header table for loading.

I use the device available in my company (which is proprietary), 
I know my point here would be abstract for u...sorry abt that !

Thanks for the reply !
Indu
> 
> > I think your reply could be put as a howto/faqs in
> > http://www.linux-mips.org (for the global symbols
> > used in linux kernel).
> 
> So many things that deserve some well written documentation - yet so little
> exists ...
> 
>   Ralf
> 


From MAILER-DAEMON Tue Jul  1 15:47:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 15:47:21 +0100 (BST)
Received: from machine77.Level3.com ([IPv6:::ffff:209.244.4.106]:30556 "EHLO
	f1ee40-19.idc1.level3.com") by linux-mips.org with ESMTP
	id <S8224861AbTGAOrO>; Tue, 1 Jul 2003 15:47:14 +0100
Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8p2+Sun/8.8.8) with SMTP id OAA17126
	for <linux-mips@linux-mips.org>; Tue, 1 Jul 2003 14:47:07 GMT
From: postmaster@Level3.com
To: linux-mips@linux-mips.org
Date: Tue, 1 Jul 2003 08:47:06 -0600
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
	boundary="9B095B5ADSN=_01C32A1F9875BBE600088D38idc1exc0001.corp"
X-DSNContext: 335a7efd - 4457 - 00000001 - 80040546
Message-ID: <AwQDsaoBd0009f2a1@idc1exc0001.corp.global.level3.com>
Subject: Delivery Status Notification (Failure)
Return-Path: <>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2738
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: postmaster@Level3.com
Precedence: bulk
X-list: linux-mips

This is a MIME-formatted message.  
Portions of this message may be unreadable without a MIME-capable mail program.

--9B095B5ADSN=_01C32A1F9875BBE600088D38idc1exc0001.corp
Content-Type: text/plain; charset=unicode-1-1-utf-7

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.

       17208881000@level3.com




--9B095B5ADSN=_01C32A1F9875BBE600088D38idc1exc0001.corp
Content-Type: message/delivery-status

Reporting-MTA: dns;idc1exc0001.corp.global.level3.com
Received-From-MTA: dns;f1ee40-20.idc1.level3.com
Arrival-Date: Tue, 1 Jul 2003 08:47:06 -0600

Final-Recipient: rfc822;17208881000@level3.com
Action: failed
Status: 5.1.1

--9B095B5ADSN=_01C32A1F9875BBE600088D38idc1exc0001.corp
Content-Type: message/rfc822

Received: from f1ee40-20.idc1.level3.com ([10.1.144.207]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 1 Jul 2003 08:47:06 -0600
Received: from july.Broomfield1.level3.net (localhost [127.0.0.1])
	by f1ee40-20.idc1.level3.com (8.9.3/8.9.3) with ESMTP id OAA16661
	for <17208881000@level3.com>; Tue, 1 Jul 2003 14:47:05 GMT
From: linux-mips@linux-mips.org
X-Authentication-Warning: f1ee40-20.idc1.level3.com: iscan owned process doing -bs
Received: from MIAOYK ([211.101.191.202])
	by july.Broomfield1.level3.net (8.12.9/8.12.9) with ESMTP id h61Eks8V005961
	for <17208881000@level3.com>; Tue, 1 Jul 2003 14:46:59 GMT
Message-Id: <200307011446.h61Eks8V005961@july.Broomfield1.level3.net>
To: <17208881000@level3.com>
Subject: Re: Application
Date: Tue, 1 Jul 2003 22:48:00 -0000
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="CSmtpMsgPart123X456_000_08091901"
Return-Path: linux-mips@linux-mips.org
X-OriginalArrivalTime: 01 Jul 2003 14:47:06.0571 (UTC) FILETIME=[A47231B0:01C33FDF]

This is a multipart message in MIME format

--CSmtpMsgPart123X456_000_08091901
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

------------------  Virus / Macro Warning Message (on f1ee40-20.idc1.level3.com)

Found virus WORM_SOBIG.E in file details.pif (in your_details.zip)
The uncleanable file your_details.zip is moved to /etc/iscan/virus/virEEDGPaq1q.

Appropriate action has been taken to clean, strip off , quarantine, or delete the virus or macro.  No further action is required at this time.

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

--CSmtpMsgPart123X456_000_08091901
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Please see the attached zip file for details.
--CSmtpMsgPart123X456_000_08091901--



--9B095B5ADSN=_01C32A1F9875BBE600088D38idc1exc0001.corp--

From jb@jblache.org Tue Jul  1 16:34:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 16:34:57 +0100 (BST)
Received: from frigate.technologeek.org ([IPv6:::ffff:62.4.21.148]:55938 "EHLO
	frigate.technologeek.org") by linux-mips.org with ESMTP
	id <S8224861AbTGAPev>; Tue, 1 Jul 2003 16:34:51 +0100
Received: by frigate.technologeek.org (Postfix, from userid 1000)
	id 54F241C9140B; Tue,  1 Jul 2003 17:34:42 +0200 (CEST)
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: [PATCH] Fix broken wd33c93.c
From: Julien BLACHE <jb@jblache.org>
Date: Tue, 01 Jul 2003 17:34:42 +0200
Message-ID: <87he66xnu5.fsf@frigate.technologeek.org>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Return-Path: <jb@jblache.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: 2739
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jb@jblache.org
Precedence: bulk
X-list: linux-mips

--=-=-=

Hi,

The attached patch fixes the compilation of drivers/scsi/wd33c93.c
that is currently broken. Seems like the last merge removed the wrong
line.

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb@jblache.org> 


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=wd33c93.c.patch
Content-Description: Fix wd33c93.c

--- wd33c93.c.orig	2003-07-01 15:31:23.000000000 +0000
+++ wd33c93.c	2003-07-01 15:30:44.000000000 +0000
@@ -1920,7 +1920,7 @@
 
 	char *bp;
 	char tbuf[128];
-	struct Scsi_Host *instance;
+	struct WD33C93_hostdata *hd;
 	Scsi_Cmnd *cmd;
 	int x, i;
 	static int stop = 0;

--=-=-=--

From jb@jblache.org Tue Jul  1 17:09:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 17:09:14 +0100 (BST)
Received: from frigate.technologeek.org ([IPv6:::ffff:62.4.21.148]:64898 "EHLO
	frigate.technologeek.org") by linux-mips.org with ESMTP
	id <S8224861AbTGAQJH>; Tue, 1 Jul 2003 17:09:07 +0100
Received: by frigate.technologeek.org (Postfix, from userid 1000)
	id 2861F1C9140B; Tue,  1 Jul 2003 18:09:00 +0200 (CEST)
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: [PATCH] Fix include/asm-mips/io.h
From: Julien BLACHE <jb@jblache.org>
Date: Tue, 01 Jul 2003 18:08:59 +0200
Message-ID: <87d6guxm90.fsf@frigate.technologeek.org>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Return-Path: <jb@jblache.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: 2740
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jb@jblache.org
Precedence: bulk
X-list: linux-mips

--=-=-=

Hi,

Another small fix. In the latest change, writeb() and friends got
changed to use __ioswa*p*X(), and this is not defined
anywhere. Changed back to __ioswa*b*X().

Now let's see if I can boot this kernel :)

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb@jblache.org> 


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=io.h.patch
Content-Description: include/asm-mips/io.h fix

--- io.h.orig	2003-07-01 16:05:46.000000000 +0000
+++ io.h	2003-07-01 16:05:09.000000000 +0000
@@ -295,10 +295,10 @@
 	local_irq_restore(flags);					\
 })
 
-#define writeb(b,addr)		__raw_writeb(__ioswap8(b),(addr))
-#define writew(w,addr)		__raw_writew(__ioswap16(w),(addr))
-#define writel(l,addr)		__raw_writel(__ioswap32(l),(addr))
-#define writeq(q,addr)		__raw_writeq(__ioswap64(q),(addr))
+#define writeb(b,addr)		__raw_writeb(__ioswab8(b),(addr))
+#define writew(w,addr)		__raw_writew(__ioswab16(w),(addr))
+#define writel(l,addr)		__raw_writel(__ioswab32(l),(addr))
+#define writeq(q,addr)		__raw_writeq(__ioswab64(q),(addr))
 
 #define memset_io(a,b,c)	memset((void *)(a),(b),(c))
 #define memcpy_fromio(a,b,c)	memcpy((a),(void *)(b),(c))

--=-=-=--

From brm@murphy.dk Tue Jul  1 18:49:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 18:49:38 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:11050
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225226AbTGARtg>; Tue, 1 Jul 2003 18:49:36 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19XPFw-0000p2-00; Tue, 01 Jul 2003 19:49:28 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.5] lasat mtd device fixup
Cc: linux-mips@linux-mips.org
Message-Id: <E19XPFw-0000p2-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Tue, 01 Jul 2003 19:49:28 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2741
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
	this fixes (in as far as I can test at the moment)
the mtd devices for 2.5.

There seems to be a spurious log message in the mtd code here:
drivers/mtd/mtd_blkdevs.c:blktrans_notify_add 331: count 0

/Brian

Index: drivers/mtd/maps/Kconfig
===================================================================
RCS file: /cvs/linux/drivers/mtd/maps/Kconfig,v
retrieving revision 1.5
diff -u -r1.5 Kconfig
--- drivers/mtd/maps/Kconfig	22 Jun 2003 23:09:53 -0000	1.5
+++ drivers/mtd/maps/Kconfig	1 Jul 2003 17:15:44 -0000
@@ -175,12 +175,6 @@
 	help
 	  Support for the flash chip on Tsunami TIG bus.
 
-config MTD_LASAT
-	tristate "Flash chips on LASAT board"
-	depends on LASAT && MTD_CFI
-	help
-	  Support for the flash chips on the Lasat 100 and 200 boards.
-
 config MTD_NETtel
 	tristate "CFI flash device on SnapGear/SecureEdge"
 	depends on X86 && MTD_PARTITIONS && MTD_JEDECPROBE
Index: drivers/mtd/maps/lasat.c
===================================================================
RCS file: /cvs/linux/drivers/mtd/maps/lasat.c,v
retrieving revision 1.3
diff -u -r1.3 lasat.c
--- drivers/mtd/maps/lasat.c	25 Feb 2003 22:39:02 -0000	1.3
+++ drivers/mtd/maps/lasat.c	1 Jul 2003 17:44:17 -0000
@@ -12,63 +12,13 @@
 #include <linux/mtd/partitions.h>
 #include <linux/config.h>
 #include <asm/lasat/lasat.h>
+#include <linux/init.h>
 
-static struct mtd_info *mymtd;
+static struct mtd_info *lasat_mtd;
 
-static __u8 sp_read8(struct map_info *map, unsigned long ofs)
-{
-	return __raw_readb(map->map_priv_1 + ofs);
-}
-
-static __u16 sp_read16(struct map_info *map, unsigned long ofs)
-{
-	return __raw_readw(map->map_priv_1 + ofs);
-}
-
-static __u32 sp_read32(struct map_info *map, unsigned long ofs)
-{
-	return __raw_readl(map->map_priv_1 + ofs);
-}
-
-static void sp_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
-{
-	memcpy_fromio(to, map->map_priv_1 + from, len);
-}
-
-static void sp_write8(struct map_info *map, __u8 d, unsigned long adr)
-{
-	__raw_writeb(d, map->map_priv_1 + adr);
-	mb();
-}
-
-static void sp_write16(struct map_info *map, __u16 d, unsigned long adr)
-{
-	__raw_writew(d, map->map_priv_1 + adr);
-	mb();
-}
-
-static void sp_write32(struct map_info *map, __u32 d, unsigned long adr)
-{
-	__raw_writel(d, map->map_priv_1 + adr);
-	mb();
-}
-
-static void sp_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len)
-{
-	memcpy_toio(map->map_priv_1 + to, from, len);
-}
-
-static struct map_info sp_map = {
-	name: "SP flash",
+static struct map_info lasat_map = {
+	name: "LASAT flash",
 	buswidth: 4,
-	read8: sp_read8,
-	read16: sp_read16,
-	read32: sp_read32,
-	copy_from: sp_copy_from,
-	write8: sp_write8,
-	write16: sp_write16,
-	write32: sp_write32,
-	copy_to: sp_copy_to
 };
 
 static struct mtd_partition partition_info[LASAT_MTD_LAST];
@@ -83,20 +33,22 @@
        	printk(KERN_NOTICE "Unprotecting flash\n");
 	*lasat_misc->flash_wp_reg |= 1 << lasat_misc->flash_wp_bit;
 
-	sp_map.map_priv_1 = lasat_flash_partition_start(LASAT_MTD_BOOTLOADER);
-	sp_map.size = lasat_board_info.li_flash_size;
+	lasat_map.phys = lasat_flash_partition_start(LASAT_MTD_BOOTLOADER);
+	lasat_map.virt = (unsigned long)ioremap_nocache(
+			lasat_map.phys, lasat_board_info.li_flash_size);
+	lasat_map.size = lasat_board_info.li_flash_size;
 
        	printk(KERN_NOTICE "sp flash device: %lx at %lx\n", 
-			sp_map.size, sp_map.map_priv_1);
+			lasat_map.size, lasat_map.phys);
 
 	for (i=0; i < LASAT_MTD_LAST; i++)
 		partition_info[i].name = lasat_mtd_partnames[i];
 
-	mymtd = do_map_probe("cfi_probe", &sp_map);
-	if (mymtd) {
+	lasat_mtd = do_map_probe("cfi_probe", &lasat_map);
+	if (lasat_mtd) {
 		u32 size, offset = 0;
 
-		mymtd->module = THIS_MODULE;
+		lasat_mtd->owner = THIS_MODULE;
 
 		for (i=0; i < LASAT_MTD_LAST; i++) {
 			size = lasat_flash_partition_size(i);
@@ -108,7 +60,7 @@
 			}
 		}
 
-		add_mtd_partitions( mymtd, partition_info, nparts );
+		add_mtd_partitions( lasat_mtd, partition_info, nparts );
 		return 0;
 	}
 
@@ -117,12 +69,9 @@
 
 static void __exit cleanup_sp(void)
 {
-	if (mymtd) {
-	  del_mtd_partitions(mymtd);
-	  map_destroy(mymtd);
-	}
-	if (sp_map.map_priv_1) {
-	  sp_map.map_priv_1 = 0;
+	if (lasat_mtd) {
+	  del_mtd_partitions(lasat_mtd);
+	  map_destroy(lasat_mtd);
 	}
 }
 
Index: arch/mips/lasat/lasat_board.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/lasat_board.c,v
retrieving revision 1.4
diff -u -r1.4 lasat_board.c
--- arch/mips/lasat/lasat_board.c	22 Jun 2003 02:19:24 -0000	1.4
+++ arch/mips/lasat/lasat_board.c	1 Jul 2003 17:39:17 -0000
@@ -71,19 +71,19 @@
 	ls[LASAT_MTD_NORMAL] = 0x100000;
 
 	if (mips_machtype == MACH_LASAT_100) {
-		lasat_board_info.li_flash_base = KSEG1ADDR(0x1e000000);
+		lasat_board_info.li_flash_base = 0x1e000000;
 		
-		lb[LASAT_MTD_BOOTLOADER] = KSEG1ADDR(0x1e400000);
+		lb[LASAT_MTD_BOOTLOADER] = 0x1e400000;
 
 		if (lasat_board_info.li_flash_size > 0x200000) {
 			ls[LASAT_MTD_CONFIG] = 0x100000;
 			ls[LASAT_MTD_FS] = 0x500000;
 		}
 	} else {
-		lasat_board_info.li_flash_base = KSEG1ADDR(0x10000000);
+		lasat_board_info.li_flash_base = 0x10000000;
 
 		if (lasat_board_info.li_flash_size < 0x1000000) {
-			lb[LASAT_MTD_BOOTLOADER] = KSEG1ADDR(0x10000000);
+			lb[LASAT_MTD_BOOTLOADER] = 0x10000000;
 			ls[LASAT_MTD_CONFIG] = 0x100000;
 			if (lasat_board_info.li_flash_size >= 0x400000) {
 				ls[LASAT_MTD_FS] = lasat_board_info.li_flash_size - 0x300000;

From brian@murphy.dk Tue Jul  1 18:56:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 18:56:47 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:11818
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8225226AbTGAR4p>; Tue, 1 Jul 2003 18:56:45 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h61Hud9g005049
	for <linux-mips@linux-mips.org>; Tue, 1 Jul 2003 19:56:39 +0200
Message-ID: <3F01CB57.7090408@murphy.dk>
Date: Tue, 01 Jul 2003 19:56:39 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: 2.5 crash on boot
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2742
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi,

I get this now when my system (working well with 2.4) attempts to
read from the disk on my system:

Freeing unused kernel memory: 88k freed      
Unable to handle kernel paging request at virtual address 07cac000, epc 
== 8005c
Oops in arch/mips/mm/fault.c::do_page_fault, line 
205[#1]:                     
Cpu 0                                                     
$ 0 : 00000000 b0008400 00000000 fffffff4
$ 4 : 07cac000 00000000 00011000 000007df
$ 8 : 07cac000 801e4ab8 811375e0 00000001
$12 : 00000001 00100100 ffffffff 87fff284
$16 : 00000000 07cac000 00000000 87ce5e98
$20 : 00011000 ffffffbf 000007df 00008075
$24 : 87fff28c 00000001                  
$28 : 87ce4000 87ce5de8 87f1c720 80059e2c
Hi      : 00000000                       
Lo      : 00000000
epc   : 80059cb0    Not tainted
Status: b0008403               
Cause : 00001008
KERNEL EXL IE Process swapon (pid: 19, stackpage=87d22ac0)
Stack:  8004ee28 80106b68 811377e8 00000000 00000000 801d7c00 00011000 
ffc000000
        8006a2d8 87ce5e98 00000201 c0000000 801d7c00 c0011000 ffc00000 
87ce5e988
        87f0a120 00000044 87f0a120 87f0b4e0 00000011 000000d2 00000020 
000007df.
Call 
Trace:                                                                    
 [<8004ee28>] pte_alloc_kernel+0x74/0x158
 [<80106b68>] blk_remove_plug+0x78/0x98  
 [<80059e2c>] map_area_pmd+0x84/0xd0   
 [<8006a2d8>] blkdev_readpage+0x0/0x28
 [<80059f98>] map_vm_area+0x74/0xe0   
 [<8005a4f8>] __vmalloc+0x140/0x178
 [<800228c0>] autoremove_wake_function+0x0/0x44
 [<8006a150>] blkdev_get_block+0x0/0x74        
 [<8005a544>] vmalloc+0x14/0x20        
 [<8005e1bc>] sys_swapon+0x6ec/0x84c
 [<8005dee4>] sys_swapon+0x414/0x84c
 [<8021b000>] pci_scan_device+0xf0/0x1a8
 [<8000cc20>] stack_done+0x18/0x34      
 [<80008413>] handle_ades_int+0x27/0x34
                                       

Code: 8fb30040  3c140040  2415ffbf <8e220000> 8e630000  3c04801b  
2484cb6c  005
                                                                               


Any pointers? I'm running in 32 bit mode.

/Brian


From kwalker@broadcom.com Tue Jul  1 19:05:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 19:05:21 +0100 (BST)
Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:55309 "EHLO
	mms1.broadcom.com") by linux-mips.org with ESMTP
	id <S8225226AbTGASFS>; Tue, 1 Jul 2003 19:05:18 +0100
Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.2)); Tue, 01 Jul 2003 11:05:02 -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 LAA15174; Tue, 1 Jul 2003 11:04:43 -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
 h61I54ov024225; Tue, 1 Jul 2003 11:05:04 -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 LAA10302; Tue, 1
 Jul 2003 11:05:04 -0700
Message-ID: <3F01CD50.49F34BAC@broadcom.com>
Date: Tue, 01 Jul 2003 11:05:04 -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: "Brian Murphy" <brian@murphy.dk>
cc: linux-mips@linux-mips.org
Subject: Re: 2.5 crash on boot
References: <3F01CB57.7090408@murphy.dk>
X-WSS-ID: 131F12C4156742-01-01
Content-Type: multipart/mixed;
 boundary=------------DDEB6D38E0F6408056BC7A3D
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: 2743
X-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

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


This may be related to something I just found -- in pmd_populate_kernel,
a physical address is installed in the pmd instead of a virtual
address.  The patch I sent Ralf 30 minutes ago is attached :-)

Kip

Brian Murphy wrote:
> 
> Hi,
> 
> I get this now when my system (working well with 2.4) attempts to
> read from the disk on my system:
> 
> Freeing unused kernel memory: 88k freed
> Unable to handle kernel paging request at virtual address 07cac000, epc
> == 8005c
> Oops in arch/mips/mm/fault.c::do_page_fault, line
> 205[#1]:
> Cpu 0
> $ 0 : 00000000 b0008400 00000000 fffffff4
> $ 4 : 07cac000 00000000 00011000 000007df
> $ 8 : 07cac000 801e4ab8 811375e0 00000001
> $12 : 00000001 00100100 ffffffff 87fff284
> $16 : 00000000 07cac000 00000000 87ce5e98
> $20 : 00011000 ffffffbf 000007df 00008075
> $24 : 87fff28c 00000001
> $28 : 87ce4000 87ce5de8 87f1c720 80059e2c
> Hi      : 00000000
> Lo      : 00000000
> epc   : 80059cb0    Not tainted
> Status: b0008403
> Cause : 00001008
> KERNEL EXL IE Process swapon (pid: 19, stackpage=87d22ac0)
> Stack:  8004ee28 80106b68 811377e8 00000000 00000000 801d7c00 00011000
> ffc000000
>         8006a2d8 87ce5e98 00000201 c0000000 801d7c00 c0011000 ffc00000
> 87ce5e988
>         87f0a120 00000044 87f0a120 87f0b4e0 00000011 000000d2 00000020
> 000007df.
> Call
> Trace:
>  [<8004ee28>] pte_alloc_kernel+0x74/0x158
>  [<80106b68>] blk_remove_plug+0x78/0x98
>  [<80059e2c>] map_area_pmd+0x84/0xd0
>  [<8006a2d8>] blkdev_readpage+0x0/0x28
>  [<80059f98>] map_vm_area+0x74/0xe0
>  [<8005a4f8>] __vmalloc+0x140/0x178
>  [<800228c0>] autoremove_wake_function+0x0/0x44
>  [<8006a150>] blkdev_get_block+0x0/0x74
>  [<8005a544>] vmalloc+0x14/0x20
>  [<8005e1bc>] sys_swapon+0x6ec/0x84c
>  [<8005dee4>] sys_swapon+0x414/0x84c
>  [<8021b000>] pci_scan_device+0xf0/0x1a8
>  [<8000cc20>] stack_done+0x18/0x34
>  [<80008413>] handle_ades_int+0x27/0x34
> 
> 
> Code: 8fb30040  3c140040  2415ffbf <8e220000> 8e630000  3c04801b
> 2484cb6c  005
> 
> 
> Any pointers? I'm running in 32 bit mode.
> 
> /Brian
--------------DDEB6D38E0F6408056BC7A3D
Content-Type: text/plain;
 charset=us-ascii;
 name=pgalloc.diff
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename=pgalloc.diff

Index: include/asm-mips/pgalloc.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/pgalloc.h,v
retrieving revision 1.27
diff -u -r1.27 pgalloc.h
--- include/asm-mips/pgalloc.h	26 Jun 2003 20:19:44 -0000	1.27
+++ include/asm-mips/pgalloc.h	1 Jul 2003 17:26:05 -0000
@@ -17,7 +17,7 @@
 static inline void pmd_populate_kernel(struct mm_struct *mm, pmd_t *pmd,
 	pte_t *pte)
 {
-	set_pmd(pmd, __pmd(__pa(pte)));
+	set_pmd(pmd, __pmd((unsigned long)pte));
 }
 
 static inline void pmd_populate(struct mm_struct *mm, pmd_t *pmd,
Index: include/asm-mips64/pgalloc.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/pgalloc.h,v
retrieving revision 1.29
diff -u -r1.29 pgalloc.h
--- include/asm-mips64/pgalloc.h	26 Jun 2003 20:19:44 -0000	1.29
+++ include/asm-mips64/pgalloc.h	1 Jul 2003 17:26:05 -0000
@@ -19,7 +19,7 @@
 static inline void pmd_populate_kernel(struct mm_struct *mm, pmd_t *pmd,
 	pte_t *pte)
 {
-	set_pmd(pmd, __pmd(__pa(pte)));
+	set_pmd(pmd, __pmd((unsigned long)pte));
 }
 
 static inline void pmd_populate(struct mm_struct *mm, pmd_t *pmd,

--------------DDEB6D38E0F6408056BC7A3D--


From ica2_ts@csv.ica.uni-stuttgart.de Tue Jul  1 19:38:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 19:38:08 +0100 (BST)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:1028
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225235AbTGASiF>; Tue, 1 Jul 2003 19:38:05 +0100
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.35 #1)
	id 19XQ0w-00005Y-00; Tue, 01 Jul 2003 20:38:02 +0200
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 19XNsv-0001UG-00; Tue, 01 Jul 2003 18:21:37 +0200
Date: Tue, 1 Jul 2003 18:21:22 +0200
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: [PATCH] Fix r4k cache handling
Message-ID: <20030701162122.GA5698@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: 2744
X-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

Hello Ralf,

I need the appended patch for my 5000/50, which has a R4000SC.


Thiemo


diff -BurpNX /home/ths/dontdiff linux-orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux-orig/arch/mips/mm/c-r4k.c	Tue May 13 23:32:50 2003
+++ linux/arch/mips/mm/c-r4k.c	Tue Jul  1 18:01:44 2003
@@ -27,7 +27,6 @@
 /* Primary cache parameters. */
 static unsigned long icache_size, dcache_size, scache_size;
 unsigned long icache_way_size, dcache_way_size, scache_way_size;
-static unsigned long scache_size;
 
 #include <asm/cacheops.h>
 #include <asm/r4kcache.h>
@@ -1084,6 +1083,11 @@ static void __init setup_scache(void)
 	     current_cpu_data.isa_level == MIPS_CPU_ISA_M64) &&
 	    !(current_cpu_data.scache.flags & MIPS_CACHE_NOT_PRESENT))
 		panic("Dunno how to handle MIPS32 / MIPS64 second level cache");
+
+	/* compute a couple of other cache variables */
+	scache_way_size = scache_size / c->scache.ways;
+
+	c->scache.sets = scache_size / (c->scache.linesz * c->scache.ways);
 
 	printk("Unified secondary cache %ldkB %s, linesize %d bytes.\n",
 	       scache_size >> 10, way_string[c->scache.ways], c->scache.linesz);
diff -BurpNX /home/ths/dontdiff linux-orig/include/asm-mips/r4kcache.h linux/include/asm-mips/r4kcache.h
--- linux-orig/include/asm-mips/r4kcache.h	Wed Apr 23 17:17:05 2003
+++ linux/include/asm-mips/r4kcache.h	Tue Jul  1 17:45:00 2003
@@ -111,6 +111,8 @@ static inline void invalidate_tcache_pag
 	cache_op(Page_Invalidate_T, addr);
 }
 
+extern unsigned long icache_way_size, dcache_way_size, scache_way_size;
+
 #define cache16_unroll32(base,op)				\
 	__asm__ __volatile__("					\
 		.set noreorder;					\

From brian@murphy.dk Tue Jul  1 21:36:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 21:36:18 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:19754
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8225223AbTGAUgQ>; Tue, 1 Jul 2003 21:36:16 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h61Ka89g007992;
	Tue, 1 Jul 2003 22:36:09 +0200
Message-ID: <3F01F0B8.90002@murphy.dk>
Date: Tue, 01 Jul 2003 22:36:08 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en
MIME-Version: 1.0
To: "J. Alexander Jacocks" <jjacocks@mac.com>
CC: linux-mips@linux-mips.org
Subject: Re: 2.5 crash on boot
References: <3F01CB57.7090408@murphy.dk> <3F01CCAA.9050307@mac.com>
In-Reply-To: <3F01CCAA.9050307@mac.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2745
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

J. Alexander Jacocks wrote:

> Brian Murphy wrote:
>
> <snip>
>
>> Any pointers? I'm running in 32 bit mode.
>>
>> /Brian
>>
>
>
> On what platform?
>
>
>
LASAT - VR5000 / 1M chip controlled second level cache.

/Brian


From brian@murphy.dk Tue Jul  1 21:55:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 21:55:10 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:25386
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8225235AbTGAUzI>; Tue, 1 Jul 2003 21:55:08 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h61Kt09g008199;
	Tue, 1 Jul 2003 22:55:01 +0200
Message-ID: <3F01F524.8050608@murphy.dk>
Date: Tue, 01 Jul 2003 22:55:00 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en
MIME-Version: 1.0
To: Kip Walker <kwalker@broadcom.com>
CC: linux-mips@linux-mips.org
Subject: Re: 2.5 crash on boot
References: <3F01CB57.7090408@murphy.dk> <3F01CD50.49F34BAC@broadcom.com>
In-Reply-To: <3F01CD50.49F34BAC@broadcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2746
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

Kip Walker wrote:

>This may be related to something I just found -- in pmd_populate_kernel,
>a physical address is installed in the pmd instead of a virtual
>address.  The patch I sent Ralf 30 minutes ago is attached :-)
>
>Kip
>  
>
>
With your patch I get a hang instead of a short hang and then the crash.
On the other hand it manages to enable the swap partition before hanging:

EXT3-fs: mounted filesystem with ordered data 
mode.                            
VFS: Mounted root (ext3 filesystem) 
readonly.                                  
Freeing unused kernel memory: 88k 
freed                                        
Adding 131532k swap on /dev/hda1.  Priority:-1 extents:1

Has anyone booted 32 bit 2.5 fully into userspace?

/Brian


From brian@murphy.dk Tue Jul  1 22:32:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 22:32:43 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:29994
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8224861AbTGAVcl>; Tue, 1 Jul 2003 22:32:41 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h61LWZ9g009024
	for <linux-mips@linux-mips.org>; Tue, 1 Jul 2003 23:32:35 +0200
Message-ID: <3F01FDF3.1090105@murphy.dk>
Date: Tue, 01 Jul 2003 23:32:35 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-mips@linux-mips.org
Subject: Re: 2.5 crash on boot
References: <3F01CB57.7090408@murphy.dk> <3F01CD50.49F34BAC@broadcom.com>
In-Reply-To: <3F01CD50.49F34BAC@broadcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
To: unlisted-recipients:; (no To-header on input)
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2747
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

Kip Walker wrote:

>This may be related to something I just found -- in pmd_populate_kernel,
>a physical address is installed in the pmd instead of a virtual
>address.  The patch I sent Ralf 30 minutes ago is attached :-)
>
>Kip
>
>  
>
Now (with the latest source) I get:

kjournald starting.  Commit interval 5 
seconds                                 
EXT3-fs: mounted filesystem with ordered data 
mode.                            
VFS: Mounted root (ext3 filesystem) 
readonly.                                  
Freeing unused kernel memory: 88k 
freed                                        
Adding 131532k swap on /dev/hda1.  Priority:-1 
extents:1                       
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on hda2, internal 
journal                      
mount: Exception at [<800e5650>] 
(800e5830)                                    
mount: Exception at [<800e5650>] 
(800e5830)                                    
mount: Exception at [<800e5650>] 
(800e5830)                                    
 
The error is in __copy_user (both_aligned), closer and closer...

/Brian


From brian@murphy.dk Tue Jul  1 22:35:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jul 2003 22:35:58 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:30762
	"EHLO valis.localnet") by linux-mips.org with ESMTP
	id <S8224861AbTGAVf4>; Tue, 1 Jul 2003 22:35:56 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.localnet (8.12.7/8.12.7/Debian-2) with ESMTP id h61LZo9g009051
	for <linux-mips@linux-mips.org>; Tue, 1 Jul 2003 23:35:50 +0200
Message-ID: <3F01FEB6.5010407@murphy.dk>
Date: Tue, 01 Jul 2003 23:35:50 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: My god! 2.5 is big
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2748
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

My gzip'ped 2.4 kernel is 250k smaller than 2.5 and it works.
Perhaps I just need to remove some code... ;-)

/Brian


From ralf@linux-mips.org Wed Jul  2 01:36:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 01:36:21 +0100 (BST)
Received: from p508B6FF8.dip.t-dialin.net ([IPv6:::ffff:80.139.111.248]:45527
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225243AbTGBAgS>; Wed, 2 Jul 2003 01:36:18 +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 h620aHDB003821;
	Wed, 2 Jul 2003 02:36:17 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h620aCXE003820;
	Wed, 2 Jul 2003 02:36:12 +0200
Date: Wed, 2 Jul 2003 02:36:12 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brian@murphy.dk>
Cc: linux-mips@linux-mips.org
Subject: Re: My god! 2.5 is big
Message-ID: <20030702003612.GD3210@linux-mips.org>
References: <3F01FEB6.5010407@murphy.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F01FEB6.5010407@murphy.dk>
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: 2749
X-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, Jul 01, 2003 at 11:35:50PM +0200, Brian Murphy wrote:

> My gzip'ped 2.4 kernel is 250k smaller than 2.5 and it works.
> Perhaps I just need to remove some code... ;-)

Old saying - "software is like gas, it fills all available space" ;-)

The MIPS 2.5 is still in it's quite early stages; I suspect we can still
regain part of the extra size.  More important than the pure kernel size
(users booting from flash throw your rotten vegies now ;-) is the in
memory size.  The greatly reduced size of struct page for example will
result in a net gain of memory available for applications for systems of
more than about 48MB.

  Ralf

From ralf@linux-mips.org Wed Jul  2 01:47:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 01:47:05 +0100 (BST)
Received: from p508B6FF8.dip.t-dialin.net ([IPv6:::ffff:80.139.111.248]:25048
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225245AbTGBArD>; Wed, 2 Jul 2003 01:47:03 +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 h620kxDB004084;
	Wed, 2 Jul 2003 02:47:00 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h620kxn1004083;
	Wed, 2 Jul 2003 02:46:59 +0200
Date: Wed, 2 Jul 2003 02:46:59 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brian@murphy.dk>
Cc: Kip Walker <kwalker@broadcom.com>, linux-mips@linux-mips.org
Subject: Re: 2.5 crash on boot
Message-ID: <20030702004659.GA3824@linux-mips.org>
References: <3F01CB57.7090408@murphy.dk> <3F01CD50.49F34BAC@broadcom.com> <3F01F524.8050608@murphy.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F01F524.8050608@murphy.dk>
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: 2750
X-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, Jul 01, 2003 at 10:55:00PM +0200, Brian Murphy wrote:

> Has anyone booted 32 bit 2.5 fully into userspace?

People have done it - but degree off success greatly varies.  I'm
optimistic to have 2.5 stable enough for basic use pretty soon.

  Ralf

From ralf@linux-mips.org Wed Jul  2 02:21:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 02:21:57 +0100 (BST)
Received: from p508B6FF8.dip.t-dialin.net ([IPv6:::ffff:80.139.111.248]:62938
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225239AbTGBBVz>; Wed, 2 Jul 2003 02:21:55 +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 h621LsDB010683;
	Wed, 2 Jul 2003 03:21:54 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h621LsUn010682;
	Wed, 2 Jul 2003 03:21:54 +0200
Date: Wed, 2 Jul 2003 03:21:54 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Vince Bridgers <vince_bridgers@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Au1500 Event and Performance Counters
Message-ID: <20030702012154.GA8530@linux-mips.org>
References: <20030630214641.36770.qmail@web41412.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030630214641.36770.qmail@web41412.mail.yahoo.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: 2751
X-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, Jun 30, 2003 at 02:46:41PM -0700, Vince Bridgers wrote:

> Has anyone used the Au1x00 performance event counter
> register in CP0 (Register 25 - where it says AMD will
> provide a list of the valid units and events when you
> ask them) ? 
> 
> Are they the same as some other MIPS processor that
> defines the events in their databook?

The MIPS32 spec to which the Au1x00 complies defines the structure and
interface of performance counters.  It does not define which events
the counters count.  Some non-MIPS32/64 processors also have slightly
different performance counter implementations.  The R10000 and R12000
performance counters values are pretty similar.

  Ralf

From demiurg@ti.com Wed Jul  2 16:17:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 16:17:23 +0100 (BST)
Received: from news.ti.com ([IPv6:::ffff:192.94.94.33]:10955 "EHLO
	dragon.ti.com") by linux-mips.org with ESMTP id <S8225238AbTGBPRV>;
	Wed, 2 Jul 2003 16:17:21 +0100
Received: from dlep51.itg.ti.com ([157.170.141.75])
	by dragon.ti.com (8.12.9/8.12.9) with ESMTP id h62FHE1p016123
	for <linux-mips@linux-mips.org>; Wed, 2 Jul 2003 10:17:15 -0500 (CDT)
Received: from dlep98.itg.ti.com (localhost [127.0.0.1])
	by dlep51.itg.ti.com (8.12.9/8.12.9) with ESMTP id h62FHEBO029472
	for <linux-mips@linux-mips.org>; Wed, 2 Jul 2003 10:17:14 -0500 (CDT)
Received: from dlee70.itg.ti.com (dlee70.itg.ti.com [157.170.135.145])
	by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA08595
	for <linux-mips@linux-mips.org>; Wed, 2 Jul 2003 10:17:14 -0500 (CDT)
Received: by dlee70.itg.ti.com with Internet Mail Service (5.5.2653.19)
	id <NZW1N230>; Wed, 2 Jul 2003 10:17:13 -0500
Received: from ti.com (cbc0794930.isr.asp.ti.com [137.167.176.14]) by dile70.itg.ti.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NN6XFQKZ; Wed, 2 Jul 2003 18:16:30 +0300
From: "Sirotkin, Alexander" <demiurg@ti.com>
To: linux-mips@linux-mips.org
Message-ID: <3F02F74F.5050300@ti.com>
Date: Wed, 02 Jul 2003 18:16:31 +0300
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: do_ri
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <demiurg@ti.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: 2752
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: demiurg@ti.com
Precedence: bulk
X-list: linux-mips

Hello dearest all,

Can anyone please enlighten me about the do_ri function ? I could not
find any reference to what it does and when it's  called anywhere.

The real reason I'm asking is because I get BUG() somewhere
in that function and I can not figure when it's getting called.

10x.

-- 
Alexander Sirotkin
SW Engineer

Texas Instruments
Broadband Communications Israel (BCIL)
Tel:  +972-9-9706587
________________________________________________________________________
"Those who do not understand Unix are condemned to reinvent it, poorly."
      -- Henry Spencer 


From macro@ds2.pg.gda.pl Wed Jul  2 16:28:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 16:28:27 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:63145 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225238AbTGBP2Z>; Wed, 2 Jul 2003 16:28:25 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA23192;
	Wed, 2 Jul 2003 17:28:17 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 2 Jul 2003 17:28:16 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Sirotkin, Alexander" <demiurg@ti.com>
cc: linux-mips@linux-mips.org
Subject: Re: do_ri
In-Reply-To: <3F02F74F.5050300@ti.com>
Message-ID: <Pine.GSO.3.96.1030702172634.21225B-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: 2753
X-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 Wed, 2 Jul 2003, Sirotkin, Alexander wrote:

> Can anyone please enlighten me about the do_ri function ? I could not
> find any reference to what it does and when it's  called anywhere.

 It's called from arch/mips/kernel/entry.S or
arch/mips64/kernel/r4k_genex.S to handle the Reserved Instruction
exception. 

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


From demiurg@ti.com Wed Jul  2 16:36:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 16:39:21 +0100 (BST)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:50389 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8225238AbTGBPgV>;
	Wed, 2 Jul 2003 16:36:21 +0100
Received: from dlep51.itg.ti.com ([157.170.141.75])
	by go4.ext.ti.com (8.12.9/8.12.9) with ESMTP id h62FaCwD010146;
	Wed, 2 Jul 2003 10:36:12 -0500 (CDT)
Received: from dlep98.itg.ti.com (localhost [127.0.0.1])
	by dlep51.itg.ti.com (8.12.9/8.12.9) with ESMTP id h62FaBBO015247;
	Wed, 2 Jul 2003 10:36:11 -0500 (CDT)
Received: from dlee70.itg.ti.com (dlee70.itg.ti.com [157.170.135.145])
	by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA21445;
	Wed, 2 Jul 2003 10:36:11 -0500 (CDT)
Received: by dlee70.itg.ti.com with Internet Mail Service (5.5.2653.19)
	id <NZW1NKCA>; Wed, 2 Jul 2003 10:36:11 -0500
Received: from ti.com (cbc0794930.isr.asp.ti.com [137.167.176.14]) by dile70.itg.ti.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NN6XFQ3P; Wed, 2 Jul 2003 18:36:01 +0300
From: "Sirotkin, Alexander" <demiurg@ti.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Message-ID: <3F02FBE1.7070107@ti.com>
Date: Wed, 02 Jul 2003 18:36:01 +0300
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: Re: do_ri
References: <Pine.GSO.3.96.1030702172634.21225B-100000@delta.ds2.pg.gda.pl>
In-Reply-To: <Pine.GSO.3.96.1030702172634.21225B-100000@delta.ds2.pg.gda.pl>
Content-Type: multipart/alternative;
 boundary="------------060800000009070604090303"
Return-Path: <demiurg@ti.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: 2754
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: demiurg@ti.com
Precedence: bulk
X-list: linux-mips

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

Are you sure ?

Because "grep -r" shows only 

./arch/mips/kernel/traps.c:asmlinkage void do_ri(struct pt_regs *regs)
./arch/mips/kernel/traps.c:             do_ri(regs);
./arch/mips/lx/lxRi.c:  do_ri(regp);

On my linux-2.4.17_mvl21 kernel. And I'm quite sure that when my kernel 
crashes it's not being called from any of these places.

But then again, may be in may case it's getting called only because some

memory get overwritten.

Maciej W. Rozycki wrote:


On Wed, 2 Jul 2003, Sirotkin, Alexander wrote:



  

Can anyone please enlighten me about the do_ri function ? I could not

find any reference to what it does and when it's  called anywhere.

    



 It's called from arch/mips/kernel/entry.S or

arch/mips64/kernel/r4k_genex.S to handle the Reserved Instruction

exception. 



  


-- 

Alexander Sirotkin

SW Engineer



Texas Instruments

Broadband Communications Israel (BCIL)

Tel:  +972-9-9706587

________________________________________________________________________

"Those who do not understand Unix are condemned to reinvent it, poorly."

      -- Henry Spencer 

--------------060800000009070604090303
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Are you sure ?<br>
<br>
Because "grep -r" shows only <br>
<br>
./arch/mips/kernel/traps.c:asmlinkage void do_ri(struct pt_regs *regs)<br>
./arch/mips/kernel/traps.c:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do_ri(regs);<br>
./arch/mips/lx/lxRi.c:&nbsp; do_ri(regp);<br>
<br>
On my linux-2.4.17_mvl21 kernel. And I'm quite sure that when my kernel
<br>
crashes it's not being called from any of these places.<br>
<br>
But then again, may be in may case it's getting called only because
some <br>
memory get overwritten.<br>
<br>
Maciej W. Rozycki wrote:<br>
<blockquote type="cite"
 cite="midPine.GSO.3.96.1030702172634.21225B-100000@delta.ds2.pg.gda.pl">
  <pre wrap="">On Wed, 2 Jul 2003, Sirotkin, Alexander wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Can anyone please enlighten me about the do_ri function ? I could not
find any reference to what it does and when it's  called anywhere.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
 It's called from arch/mips/kernel/entry.S or
arch/mips64/kernel/r4k_genex.S to handle the Reserved Instruction
exception. 

  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Alexander Sirotkin
SW Engineer

Texas Instruments
Broadband Communications Israel (BCIL)
Tel:  +972-9-9706587
________________________________________________________________________
"Those who do not understand Unix are condemned to reinvent it, poorly."
      -- Henry Spencer 
</pre>
</body>
</html>

--------------060800000009070604090303--

From Geert.Uytterhoeven@sonycom.com Wed Jul  2 16:51:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 16:51:48 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:33772 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225256AbTGBPvq>;
	Wed, 2 Jul 2003 16:51:46 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h62FpbRd005470;
	Wed, 2 Jul 2003 17:51:37 +0200 (MEST)
Date: Wed, 2 Jul 2003 17:51:37 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Sirotkin, Alexander" <demiurg@ti.com>
cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: do_ri
In-Reply-To: <3F02FBE1.7070107@ti.com>
Message-ID: <Pine.GSO.4.21.0307021750091.15047-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2755
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Wed, 2 Jul 2003, Sirotkin, Alexander wrote:
> Are you sure ?
> 
> Because "grep -r" shows only 
> 
> ./arch/mips/kernel/traps.c:asmlinkage void do_ri(struct pt_regs *regs)
> ./arch/mips/kernel/traps.c:             do_ri(regs);
> ./arch/mips/lx/lxRi.c:  do_ri(regp);
> 
> On my linux-2.4.17_mvl21 kernel. And I'm quite sure that when my kernel 
> crashes it's not being called from any of these places.

I remember getting bitten by that one, too...

Check out BUILD_HANDLER(ri,ri,sti,silent) in arch/mips/kernel/entry.S.

Grep isn't always your friend, `nm -g' is, in this case :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From ralf@linux-mips.org Wed Jul  2 16:57:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 16:57:20 +0100 (BST)
Received: from p508B6205.dip.t-dialin.net ([IPv6:::ffff:80.139.98.5]:4766 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225256AbTGBP5R>; Wed, 2 Jul 2003 16:57: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 h62Fv8DB008518;
	Wed, 2 Jul 2003 17:57:08 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h62Fv7sJ008517;
	Wed, 2 Jul 2003 17:57:07 +0200
Date: Wed, 2 Jul 2003 17:57:07 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Sirotkin, Alexander" <demiurg@ti.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: do_ri
Message-ID: <20030702155707.GA6158@linux-mips.org>
References: <3F02FBE1.7070107@ti.com> <Pine.GSO.4.21.0307021750091.15047-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0307021750091.15047-100000@vervain.sonytel.be>
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: 2756
X-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, Jul 02, 2003 at 05:51:37PM +0200, Geert Uytterhoeven wrote:

> > 
> > ./arch/mips/kernel/traps.c:asmlinkage void do_ri(struct pt_regs *regs)
> > ./arch/mips/kernel/traps.c:             do_ri(regs);
> > ./arch/mips/lx/lxRi.c:  do_ri(regp);
> > 
> > On my linux-2.4.17_mvl21 kernel. And I'm quite sure that when my kernel 
> > crashes it's not being called from any of these places.
> 
> I remember getting bitten by that one, too...
> 
> Check out BUILD_HANDLER(ri,ri,sti,silent) in arch/mips/kernel/entry.S.
> 
> Grep isn't always your friend, `nm -g' is, in this case :-)

I guess people not finding the callers of the do_* functions is one of the
most common questions on this list :-)

  Ralf

PS: Ever heared of Intercal? ;-)

From demiurg@ti.com Wed Jul  2 17:09:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 17:11:34 +0100 (BST)
Received: from news.ti.com ([IPv6:::ffff:192.94.94.33]:1182 "EHLO
	dragon.ti.com") by linux-mips.org with ESMTP id <S8225260AbTGBQJq>;
	Wed, 2 Jul 2003 17:09:46 +0100
Received: from dlep50.itg.ti.com ([157.170.141.74])
	by dragon.ti.com (8.12.9/8.12.9) with ESMTP id h62G9Z1p007277;
	Wed, 2 Jul 2003 11:09:35 -0500 (CDT)
Received: from dlep98.itg.ti.com (localhost [127.0.0.1])
	by dlep50.itg.ti.com (8.12.9/8.12.9) with ESMTP id h62G9Y20000355;
	Wed, 2 Jul 2003 11:09:35 -0500 (CDT)
Received: from dlee70.itg.ti.com (dlee70.itg.ti.com [157.170.135.145])
	by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA13646;
	Wed, 2 Jul 2003 11:09:34 -0500 (CDT)
Received: by dlee70.itg.ti.com with Internet Mail Service (5.5.2653.19)
	id <NZW1NMYX>; Wed, 2 Jul 2003 11:09:34 -0500
Received: from ti.com (cbc0794930.isr.asp.ti.com [137.167.176.14]) by dile70.itg.ti.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NN6XFQTF; Wed, 2 Jul 2003 19:08:56 +0300
From: "Sirotkin, Alexander" <demiurg@ti.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Message-ID: <3F030399.8070801@ti.com>
Date: Wed, 02 Jul 2003 19:08:57 +0300
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: Re: do_ri
References: <Pine.GSO.4.21.0307021750091.15047-100000@vervain.sonytel.be>
In-Reply-To: <Pine.GSO.4.21.0307021750091.15047-100000@vervain.sonytel.be>
Content-Type: multipart/alternative;
 boundary="------------030706030201000708080205"
Return-Path: <demiurg@ti.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: 2757
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: demiurg@ti.com
Precedence: bulk
X-list: linux-mips

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

Got it. 10x.

Geert,
You save me for second time in a row today, I feel like I owe you a beer
:)

Geert Uytterhoeven wrote:


On Wed, 2 Jul 2003, Sirotkin, Alexander wrote:

  

Are you sure ?



Because "grep -r" shows only 



./arch/mips/kernel/traps.c:asmlinkage void do_ri(struct pt_regs *regs)

./arch/mips/kernel/traps.c:             do_ri(regs);

./arch/mips/lx/lxRi.c:  do_ri(regp);



On my linux-2.4.17_mvl21 kernel. And I'm quite sure that when my kernel 

crashes it's not being called from any of these places.

    



I remember getting bitten by that one, too...



Check out BUILD_HANDLER(ri,ri,sti,silent) in arch/mips/kernel/entry.S.



Grep isn't always your friend, `nm -g' is, in this case :-)



Gr{oetje,eeting}s,



						Geert



--

Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
geert@linux-m68k.org <mailto:geert@linux-m68k.org> 



In personal conversations with technical people, I call myself a hacker.
But

when I'm talking to journalists I just say "programmer" or something
like that.

							    -- Linus
Torvalds

  


-- 

Alexander Sirotkin

SW Engineer



Texas Instruments

Broadband Communications Israel (BCIL)

Tel:  +972-9-9706587

________________________________________________________________________

"Those who do not understand Unix are condemned to reinvent it, poorly."

      -- Henry Spencer 

--------------030706030201000708080205
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Got it. 10x.<br>
<br>
Geert,<br>
You save me for second time in a row today, I feel like I owe you a
beer :)<br>
<br>
Geert Uytterhoeven wrote:<br>
<blockquote type="cite"
 cite="midPine.GSO.4.21.0307021750091.15047-100000@vervain.sonytel.be">
  <pre wrap="">On Wed, 2 Jul 2003, Sirotkin, Alexander wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Are you sure ?

Because "grep -r" shows only 

./arch/mips/kernel/traps.c:asmlinkage void do_ri(struct pt_regs *regs)
./arch/mips/kernel/traps.c:             do_ri(regs);
./arch/mips/lx/lxRi.c:  do_ri(regp);

On my linux-2.4.17_mvl21 kernel. And I'm quite sure that when my kernel 
crashes it's not being called from any of these places.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I remember getting bitten by that one, too...

Check out BUILD_HANDLER(ri,ri,sti,silent) in arch/mips/kernel/entry.S.

Grep isn't always your friend, `nm -g' is, in this case :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- <a class="moz-txt-link-abbreviated" href="mailto:geert@linux-m68k.org">geert@linux-m68k.org</a>

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Alexander Sirotkin
SW Engineer

Texas Instruments
Broadband Communications Israel (BCIL)
Tel:  +972-9-9706587
________________________________________________________________________
"Those who do not understand Unix are condemned to reinvent it, poorly."
      -- Henry Spencer 
</pre>
</body>
</html>

--------------030706030201000708080205--

From patrick.hilt@pioneer-pdt.com Wed Jul  2 19:35:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jul 2003 19:35:06 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:36343
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225238AbTGBSfE>; Wed, 2 Jul 2003 19:35:04 +0100
Received: from philt.mrp.pioneer-pdt.com ([172.30.2.110])
          by ns.pioneer-pdt.com (Post.Office MTA v3.5.3 release 223
          ID# 0-68491U100L2S100V35) with ESMTP id com;
          Wed, 2 Jul 2003 11:37:29 -0700
From: patrick.hilt@pioneer-pdt.com (Patrick Hilt)
Organization: Pioneer
To: sseeger@stellartec.com
Subject: Re: rtai part 2
Date: Wed, 2 Jul 2003 11:34:21 -0400
User-Agent: KMail/1.5
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200307021134.21355.philt@pioneer-pdt.com>
Return-Path: <patrick.hilt@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: 2758
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: patrick.hilt@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips

Hi Steven!
I saw your RTAI related posts to the linux-mips mailing list and was wondering 
if you could maybe help me with this: I would like to use rtai with a 2.4.18 
kernel on a MIPS32 box. From the available documentation it's difficult to 
see what version of rtai should/could work with my configuration.
Thanks a lot in advance for any suggestions you might be able to give me!

Take care,

Patrick


From michael_pruznick@mvista.com Fri Jul  4 00:50:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jul 2003 00:50:47 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:60922 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225202AbTGCXun>;
	Fri, 4 Jul 2003 00:50:43 +0100
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA00589
	for <linux-mips@linux-mips.org>; Thu, 3 Jul 2003 16:50:20 -0700
Message-ID: <3F04C13B.F1B92A1B@mvista.com>
Date: Thu, 03 Jul 2003 17:50:19 -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.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: AU1500 BE USB problem
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: 2759
X-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

My db1500 usb works in LE mode.  In BE mode it does not.  Below is
the first problem I've seen (may not be the first/only problem).  
This is a 2.4.18 kernel.

This problem shows up in sohci_submit_urb(), but looks like it is caused
by FILL_CONTROL_URB().  Since FILL_CONTROL_URB() is depreciated I've
also tried its replacement usb_fill_control_urb() with no difference.

This is generic usb/ohci code.  Isn't this code already le/be safe?
Shouldn't this just work?

The au1500 hardware has a bit that will "swap usb data but not ohci
control structs".  I see this same problem with that bit set or clear.

Not sure if hcca->frame_no is considered an ohci control struct or
usb data, but since it doesn't seam to be swapped when I change the
bit, I'm guessing it is probably considered a control struct.

Any thoughts on what I might be missing here?


Here is the le/be diff:
< hcc[32]:0xa02bd080=0x00000a1d
---
> hcc[32]:0xa02bd080=0x00000a1c
...
< frame_no = (x1=0x0d57,x2=0x0d57,x3=0x0d57)
< frame_no = (y1=0x00000d57,y2=0x00000d57,y3=0x00000d57)
< ...URB:[ d92] dev: 0,ep: 0-O,type:CTRL,flags:   0,len:0/0,stat:0(0)
---
> frame_no = (x1=0x0000,x2=0x0000,x3=0x0000)
> frame_no = (y1=0x00000000,y2=0x00000000,y3=0x00000d56)
> #...URB:[   0] dev: 0,ep: 0-O,type:CTRL,flags:   0,len:0/0,stat:0(0)


The above output comes from this patch to sohci_get_current_frame_number():
< 
<       return le16_to_cpu (ohci->hcca->frame_no);
---
>       u16 x1, x2, x3;
>       u32 y1, y2, y3;
> 
>       {
>               u32 i, l;
>               u32* p;
>               l = sizeof(struct ohci_hcca)/4;
>               p = ohci->hcca;
>               for ( i = 0; i < l; i++ )
>               {
>                       printk( "hcc[%02d]:0x%08x=0x%08x\n", 
>                               i, p, *p );
>                       p++;
>               }
>       }
> 
>       x1 = ohci->hcca->frame_no;
>       x2 = le16_to_cpu(x1);
>       x3 = ((u16*)ohci->hcca)[64];
> 
>       y1 = ohci->hcca->frame_no;
>       y2 = le32_to_cpu(y1);
>       y3 = ((u32*)ohci->hcca)[32];
> 
> printk( "frame_no = (x1=0x%04x,x2=0x%04x,x3=0x%04x)\n",x1,x2,x3 );
> printk( "frame_no = (y1=0x%08x,y2=0x%08x,y3=0x%08x)\n",y1,y2,y3 );
> 
>       return le16_to_cpu(ohci->hcca->frame_no);

From smills_ho@coventive.com Fri Jul  4 08:42:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jul 2003 08:42:56 +0100 (BST)
Received: from 202-145-53-89.adsl.ttn.net ([IPv6:::ffff:202.145.53.89]:21723
	"EHLO miao.coventive.com") by linux-mips.org with ESMTP
	id <S8225204AbTGDHmx>; Fri, 4 Jul 2003 08:42:53 +0100
Received: from pc208 (PC208.ia.kh.coventive.com [192.168.23.208] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id h647gDx28614;
	Fri, 4 Jul 2003 15:42:15 +0800
Message-ID: <002401c34200$0323fff0$d017a8c0@pc208>
From: "smills_ho" <smills_ho@coventive.com>
To: "Julian Scheel" <julian@jusst.de>, <linux-mips@linux-mips.org>
References: <200306031428.48675.julian@jusst.de>
Subject: Re: rootfs for vr4181a
Date: Fri, 4 Jul 2003 15:43:48 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Return-Path: <smills_ho@coventive.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2760
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: smills_ho@coventive.com
Precedence: bulk
X-list: linux-mips

Hi Julian,
    What kernel version do you use? 2.4.2 or higher ?
Can it work about ramdisk ?

Regards,

Jeff
----- Original Message -----
From: "Julian Scheel" <julian@jusst.de>
To: <linux-mips@linux-mips.org>
Sent: Tuesday, June 03, 2003 8:28 PM
Subject: rootfs for vr4181a


> Hey all,
>
> I am searching for a rootfs which can be used with a NEC VR4181A and can
be
> mounted over NFS (shouldn't need any special things, should it?)
> Has someone such a rootfs - or can give me a link where to find it - or a
link
> to a description how to do it myself?
>
> --
> Grüße,
> Julian
>


From rahul.pande@wipro.com Fri Jul  4 14:43:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jul 2003 14:44:23 +0100 (BST)
Received: from wiprom2mx1.wipro.com ([IPv6:::ffff:203.197.164.41]:44789 "EHLO
	wiprom2mx1.wipro.com") by linux-mips.org with ESMTP
	id <S8224821AbTGDNnu>; Fri, 4 Jul 2003 14:43:50 +0100
Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236])
	by wiprom2mx1.wipro.com (8.12.9/8.12.9) with SMTP id h64DhFRO021981
	for <linux-mips@linux-mips.org>; Fri, 4 Jul 2003 19:13:20 +0530 (IST)
Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 4 Jul 2003 19:13:15 +0530
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_01C34232.37DED859"
Subject: gdbserver on mips
Date: Fri, 4 Jul 2003 19:13:14 +0530
Message-ID: <52C85426D39B314381D76DDD480EEE0CDA556C@blr-m3-msg.wipro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: gdbserver on mips
Thread-Index: AcNCMjdrDP+3TmhMRCyyeWHdvisioQ==
From: "Rahul Pande" <rahul.pande@wipro.com>
To: <linux-mips@linux-mips.org>
X-OriginalArrivalTime: 04 Jul 2003 13:43:15.0256 (UTC) FILETIME=[380B2B80:01C34232]
Return-Path: <rahul.pande@wipro.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: 2761
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rahul.pande@wipro.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C34232.37DED859
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
=20
 I am working on a AMD Au1500 based board and want some information. I
am using the Linux 2.4.21pre. The problem happens when i run an
application under "gdbserver" on the board, it does not allow me to
single step into functions/code. The following error is displayed :
                "ptrace : Input/Output error".=20
=20
The  "ptrace.c" file under arch/mips/kernel/ does not have support for
PTRACE_SINGLESTEP because of which the above error is occuring. I would
like to know why single stepping support is not there for mips
architecture under linux, whereas it is there for others like i386,
alpha, arm etc ?
=20
Thanks and Regards,
          rahul
=20

**************************Disclaimer************************************

Information contained in this E-MAIL being proprietary to Wipro Limited is=
=20
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying=
=20
or dissemination of the information contained in the E-MAIL in any manner=20
whatsoever is strictly prohibited.

***************************************************************************

------_=_NextPart_001_01C34232.37DED859
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=
=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D720301808-04072003>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D720301808-04072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN class=
=3D720301808-04072003>&nbsp;I=20
am&nbsp;<SPAN class=3D646113813-04072003>working on</SPAN>&nbsp;<SPAN=20
class=3D646113813-04072003>a AMD Au1500&nbsp;based board</SPAN>&nbsp;and=
 want some=20
information. I am using the Linux <SPAN=20
class=3D646113813-04072003>2.4.21pre</SPAN>. The problem happens when i run=
 an=20
application&nbsp;under "gdbserver" on the </SPAN><SPAN=20
class=3D720301808-04072003>board, it does not allow me to single step into=
=20
functions/code. The&nbsp;following error is displayed=20
:</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=
=3D720301808-04072003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
"ptrace : Input/Output error". </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D720301808-04072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D720301808-04072003>The=
 &nbsp;"ptrace.c"=20
file under arch/mips/kernel/ does not have support for PTRACE_SINGLESTEP=
 because=20
of which the above error is occuring. I would like to know why&nbsp;single=
=20
stepping support&nbsp;is not there for mips architecture under linux,=
 whereas it=20
is there for others like i386, alpha, arm etc ?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D720301808-04072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D720301808-04072003>Thanks=
 and=20
Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=
=3D720301808-04072003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
rahul</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D720301808-04072003></SPAN></FONT>&nbsp;</DIV></DIV></BODY></HTML>
<table><tr><td bgcolor=3D#ffffff><font color=
=3D#000000><pre>**************************Disclaimer***********************=
*************

Information contained in this E-MAIL being proprietary to Wipro Limited is=
=20
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying=
=20
or dissemination of the information contained in the E-MAIL in any manner=20
whatsoever is strictly prohibited.

***************************************************************************
</pre></font></td></tr></table>
------_=_NextPart_001_01C34232.37DED859--

From ralf@linux-mips.org Fri Jul  4 16:28:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jul 2003 16:28:14 +0100 (BST)
Received: from p508B626F.dip.t-dialin.net ([IPv6:::ffff:80.139.98.111]:22227
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTGDP2M>; Fri, 4 Jul 2003 16:28: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 h64FRoDB017382;
	Fri, 4 Jul 2003 17:27:50 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h64FRmoY017381;
	Fri, 4 Jul 2003 17:27:48 +0200
Date: Fri, 4 Jul 2003 17:27:48 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Rahul Pande <rahul.pande@wipro.com>
Cc: linux-mips@linux-mips.org
Subject: Re: gdbserver on mips
Message-ID: <20030704152748.GB17222@linux-mips.org>
References: <52C85426D39B314381D76DDD480EEE0CDA556C@blr-m3-msg.wipro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52C85426D39B314381D76DDD480EEE0CDA556C@blr-m3-msg.wipro.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: 2762
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jul 04, 2003 at 07:13:14PM +0530, Rahul Pande wrote:

> **************************Disclaimer************************************
> 
> Information contained in this E-MAIL being proprietary to Wipro Limited is 
> 'privileged' and 'confidential' and intended for use only by the individual
>  or entity to which it is addressed. You are notified that any use, copying 
> or dissemination of the information contained in the E-MAIL in any manner 
> whatsoever is strictly prohibited.
> 
> ***************************************************************************

I'm sure this posting to a public mailing list with such an disclaimer
was just an accident and therefore it's ok if everybody ignores your
mail?

;-)

  Ralf

From ralf@linux-mips.org Fri Jul  4 16:36:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jul 2003 16:36:12 +0100 (BST)
Received: from p508B626F.dip.t-dialin.net ([IPv6:::ffff:80.139.98.111]:54227
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTGDPgK>; Fri, 4 Jul 2003 16:36:10 +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 h64FZYDB017542;
	Fri, 4 Jul 2003 17:35:34 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h64FZUNs017541;
	Fri, 4 Jul 2003 17:35:30 +0200
Date: Fri, 4 Jul 2003 17:35:30 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: smills_ho <smills_ho@coventive.com>
Cc: Julian Scheel <julian@jusst.de>, linux-mips@linux-mips.org
Subject: Re: rootfs for vr4181a
Message-ID: <20030704153530.GD17222@linux-mips.org>
References: <200306031428.48675.julian@jusst.de> <002401c34200$0323fff0$d017a8c0@pc208>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002401c34200$0323fff0$d017a8c0@pc208>
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: 2763
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jul 04, 2003 at 03:43:48PM +0800, smills_ho wrote:

> Hi Julian,
>     What kernel version do you use? 2.4.2 or higher ?
> Can it work about ramdisk ?

I really hope nobody is using 2.4.2 anymore.  This kernel is by now quite
a bit over 2 years old and the number of bug fixes in the generic and
MIPS-specific code is so large that I refuse to enumerate them ...

  Ralf

From Geert.Uytterhoeven@sonycom.com Fri Jul  4 16:39:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jul 2003 16:39:15 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:60140 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224821AbTGDPjL>;
	Fri, 4 Jul 2003 16:39:11 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h64Fbq1W019513;
	Fri, 4 Jul 2003 17:37:52 +0200 (MEST)
Date: Fri, 4 Jul 2003 17:37:52 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: smills_ho <smills_ho@coventive.com>,
	Julian Scheel <julian@jusst.de>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: rootfs for vr4181a
In-Reply-To: <20030704153530.GD17222@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0307041736590.9830-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2764
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 4 Jul 2003, Ralf Baechle wrote:
> On Fri, Jul 04, 2003 at 03:43:48PM +0800, smills_ho wrote:
> >     What kernel version do you use? 2.4.2 or higher ?
> > Can it work about ramdisk ?
> 
> I really hope nobody is using 2.4.2 anymore.  This kernel is by now quite
> a bit over 2 years old and the number of bug fixes in the generic and
> MIPS-specific code is so large that I refuse to enumerate them ...

So any plans to upgrade Linux/MIPS CVS to 2.4.21 (and beyond)? ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From ralf@linux-mips.org Fri Jul  4 16:58:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jul 2003 16:58:31 +0100 (BST)
Received: from p508B626F.dip.t-dialin.net ([IPv6:::ffff:80.139.98.111]:10965
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTGDP63>; Fri, 4 Jul 2003 16:58:29 +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 h64FvtDB018017;
	Fri, 4 Jul 2003 17:57:55 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h64FvrND018016;
	Fri, 4 Jul 2003 17:57:53 +0200
Date: Fri, 4 Jul 2003 17:57:53 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: smills_ho <smills_ho@coventive.com>,
	Julian Scheel <julian@jusst.de>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: rootfs for vr4181a
Message-ID: <20030704155753.GA32098@linux-mips.org>
References: <20030704153530.GD17222@linux-mips.org> <Pine.GSO.4.21.0307041736590.9830-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0307041736590.9830-100000@vervain.sonytel.be>
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: 2765
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jul 04, 2003 at 05:37:52PM +0200, Geert Uytterhoeven wrote:

> On Fri, 4 Jul 2003, Ralf Baechle wrote:
> > On Fri, Jul 04, 2003 at 03:43:48PM +0800, smills_ho wrote:
> > >     What kernel version do you use? 2.4.2 or higher ?
> > > Can it work about ramdisk ?
> > 
> > I really hope nobody is using 2.4.2 anymore.  This kernel is by now quite
> > a bit over 2 years old and the number of bug fixes in the generic and
> > MIPS-specific code is so large that I refuse to enumerate them ...
> 
> So any plans to upgrade Linux/MIPS CVS to 2.4.21 (and beyond)? ;-)

Sure :-)

  Ralf

From ralf@linux-mips.org Sat Jul  5 04:32:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 04:32:42 +0100 (BST)
Received: from p508B5C15.dip.t-dialin.net ([IPv6:::ffff:80.139.92.21]:13456
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224802AbTGEDck>; Sat, 5 Jul 2003 04:32:40 +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 h653W5DB027595;
	Sat, 5 Jul 2003 05:32:06 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h653W3K6027594;
	Sat, 5 Jul 2003 05:32:03 +0200
Date: Sat, 5 Jul 2003 05:32:03 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: smills_ho <smills_ho@coventive.com>,
	Julian Scheel <julian@jusst.de>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: rootfs for vr4181a
Message-ID: <20030705033203.GA27588@linux-mips.org>
References: <20030704153530.GD17222@linux-mips.org> <Pine.GSO.4.21.0307041736590.9830-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0307041736590.9830-100000@vervain.sonytel.be>
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: 2766
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jul 04, 2003 at 05:37:52PM +0200, Geert Uytterhoeven wrote:

> > I really hope nobody is using 2.4.2 anymore.  This kernel is by now quite
> > a bit over 2 years old and the number of bug fixes in the generic and
> > MIPS-specific code is so large that I refuse to enumerate them ...
> 
> So any plans to upgrade Linux/MIPS CVS to 2.4.21 (and beyond)? ;-)

Question answered?  :-)

  Ralf

From Geert.Uytterhoeven@sonycom.com Sat Jul  5 10:51:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 10:51:43 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:27902 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225209AbTGEJvl>;
	Sat, 5 Jul 2003 10:51:41 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h659oa1W011601;
	Sat, 5 Jul 2003 11:50:36 +0200 (MEST)
Date: Sat, 5 Jul 2003 11:50:36 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: smills_ho <smills_ho@coventive.com>,
	Julian Scheel <julian@jusst.de>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: rootfs for vr4181a
In-Reply-To: <20030705033203.GA27588@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0307051150160.23765-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2767
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Sat, 5 Jul 2003, Ralf Baechle wrote:
> On Fri, Jul 04, 2003 at 05:37:52PM +0200, Geert Uytterhoeven wrote:
> > > I really hope nobody is using 2.4.2 anymore.  This kernel is by now quite
> > > a bit over 2 years old and the number of bug fixes in the generic and
> > > MIPS-specific code is so large that I refuse to enumerate them ...
> > 
> > So any plans to upgrade Linux/MIPS CVS to 2.4.21 (and beyond)? ;-)
> 
> Question answered?  :-)

Yes, thanks a lot!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From ralf@linux-mips.org Sat Jul  5 12:24:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 12:24:32 +0100 (BST)
Received: from p508B5C15.dip.t-dialin.net ([IPv6:::ffff:80.139.92.21]:57002
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225209AbTGELYa>; Sat, 5 Jul 2003 12:24:30 +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 h65BNrDB004506;
	Sat, 5 Jul 2003 13:23:53 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h65BNpDu004505;
	Sat, 5 Jul 2003 13:23:51 +0200
Date: Sat, 5 Jul 2003 13:23:51 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: smills_ho <smills_ho@coventive.com>,
	Julian Scheel <julian@jusst.de>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: rootfs for vr4181a
Message-ID: <20030705112351.GA4455@linux-mips.org>
References: <20030705033203.GA27588@linux-mips.org> <Pine.GSO.4.21.0307051150160.23765-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0307051150160.23765-100000@vervain.sonytel.be>
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: 2768
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Jul 05, 2003 at 11:50:36AM +0200, Geert Uytterhoeven wrote:

> > > So any plans to upgrade Linux/MIPS CVS to 2.4.21 (and beyond)? ;-)
> > 
> > Question answered?  :-)
> 
> Yes, thanks a lot!

For those who aren't subscribed to linux-cvs - I've commited the update
to the 2.4.21 release version last night.

  Ralf

From brm@murphy.dk Sat Jul  5 14:22:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 14:22:52 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:8494
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225215AbTGENWu>; Sat, 5 Jul 2003 14:22:50 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19Ymze-0000xZ-00; Sat, 05 Jul 2003 15:22:22 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.4] ndelay typo?
Cc: linux-mips@linux-mips.org
Message-Id: <E19Ymze-0000xZ-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Sat, 05 Jul 2003 15:22:22 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2769
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
	I presume you meant this?

/Brian

Index: include/asm/delay.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/delay.h,v
retrieving revision 1.10.2.4
diff -u -r1.10.2.4 delay.h
--- include/asm/delay.h	5 Jul 2003 03:23:46 -0000	1.10.2.4
+++ include/asm/delay.h	5 Jul 2003 13:18:24 -0000
@@ -73,6 +73,6 @@
 #endif
 
 #define udelay(usecs) __udelay((usecs),__udelay_val)
-#define ndelay(usecs) __udelay((usecs),__udelay_val)
+#define ndelay(usecs) __ndelay((usecs),__udelay_val)
 
 #endif /* _ASM_DELAY_H */

From ralf@linux-mips.org Sat Jul  5 14:34:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 14:34:51 +0100 (BST)
Received: from p508B5C15.dip.t-dialin.net ([IPv6:::ffff:80.139.92.21]:31666
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224802AbTGENet>; Sat, 5 Jul 2003 14:34: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 h65DYSDB004163;
	Sat, 5 Jul 2003 15:34:28 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h65DYRLB004162;
	Sat, 5 Jul 2003 15:34:27 +0200
Date: Sat, 5 Jul 2003 15:34:27 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brm@murphy.dk>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.4] ndelay typo?
Message-ID: <20030705133426.GA3750@linux-mips.org>
References: <E19Ymze-0000xZ-00@brian.localnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E19Ymze-0000xZ-00@brian.localnet>
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: 2770
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Jul 05, 2003 at 03:22:22PM +0200, Brian Murphy wrote:

> 	I presume you meant this?

Yes, thanks, will fix.

> Index: include/asm/delay.h
> ===================================================================
> RCS file: /cvs/linux/include/asm-mips/delay.h,v
> retrieving revision 1.10.2.4
> diff -u -r1.10.2.4 delay.h
> --- include/asm/delay.h	5 Jul 2003 03:23:46 -0000	1.10.2.4

Btw, don't diff anything in include/asm/.  That's a symlink ...

Btw, sorry if I toasted the Lasat support with the Galileo cleanup.  There
was just so much code duplication, it was insane to maintain.

I'm wondering about the Nile4 support btw.   Vrc5074 == NILE4, right?

   Ralf

From brm@murphy.dk Sat Jul  5 15:41:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 15:41:02 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:16430
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8224802AbTGEOlA>; Sat, 5 Jul 2003 15:41:00 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19YoDK-0002jK-00; Sat, 05 Jul 2003 16:40:34 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.4] nile4 pci typo
Cc: linux-mips@linux-mips.org
Message-Id: <E19YoDK-0002jK-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Sat, 05 Jul 2003 16:40:34 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2771
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
	another typo for you...

/Brian

Index: arch/mips/pci/ops-nile4.c
===================================================================
RCS file: /cvs/linux/arch/mips/pci/Attic/ops-nile4.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 ops-nile4.c
--- arch/mips/pci/ops-nile4.c	5 Jul 2003 13:17:03 -0000	1.1.2.1
+++ arch/mips/pci/ops-nile4.c	5 Jul 2003 14:10:53 -0000
@@ -5,7 +5,7 @@
 #include <linux/spinlock.h>
 #include <asm/bootinfo.h>
 
-#include <asm/nile4_.h>
+#include <asm/nile4.h>
 #include <asm/lasat/lasat.h>
 
 #define PCI_ACCESS_READ  0

From brm@murphy.dk Sat Jul  5 15:41:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 15:41:47 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:16686
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8224802AbTGEOlo>; Sat, 5 Jul 2003 15:41:44 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19YoE3-0002jQ-00; Sat, 05 Jul 2003 16:41:19 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.4] lasat ndelay bug
Cc: linux-mips@linux-mips.org
Message-Id: <E19YoE3-0002jQ-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Sat, 05 Jul 2003 16:41:19 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2772
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
	this fixes a bug in my internal ndelay function. It is 
needed to because the clock speed is not available until the 
eeprom (at93c) is read and the clock tick is calibrated.

/Brian

Index: arch/mips/lasat/at93c.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/at93c.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 at93c.c
--- arch/mips/lasat/at93c.c	13 Dec 2002 19:45:36 -0000	1.1.2.1
+++ arch/mips/lasat/at93c.c	5 Jul 2003 13:17:26 -0000
@@ -41,9 +41,9 @@
 static void at93c_cycle_clk(u32 data)
 {
 	at93c_reg_write(data | at93c->clk);
-	ndelay(250);
+	lasat_ndelay(250);
 	at93c_reg_write(data & ~at93c->clk);
-	ndelay(250);
+	lasat_ndelay(250);
 }
 
 static void at93c_write_databit(u8 bit)
@@ -55,7 +55,7 @@
 		data &= ~(1 << at93c->wdata_shift);
 
 	at93c_reg_write(data);
-	ndelay(100);
+	lasat_ndelay(100);
 	at93c_cycle_clk(data);
 }
 
@@ -95,13 +95,13 @@
 static void at93c_init_op(void)
 {
 	at93c_reg_write((at93c_reg_read() | at93c->cs) & ~at93c->clk & ~(1 << at93c->rdata_shift));
-	ndelay(50);
+	lasat_ndelay(50);
 }
 
 static void at93c_end_op(void)
 {
 	at93c_reg_write(at93c_reg_read() & ~at93c->cs);
-	ndelay(250);
+	lasat_ndelay(250);
 }
 
 static void at93c_wait(void) 
Index: arch/mips/lasat/prom.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/prom.c,v
retrieving revision 1.1.2.4
diff -u -r1.1.2.4 prom.c
--- arch/mips/lasat/prom.c	7 Apr 2003 00:17:06 -0000	1.1.2.4
+++ arch/mips/lasat/prom.c	5 Jul 2003 14:23:12 -0000
@@ -47,6 +47,8 @@
 		null_prom_display;
 void (* prom_monitor)(void) = null_prom_monitor;
 
+unsigned int lasat_ndelay_divider;
+
 #define PROM_PRINTFBUF_SIZE 256
 static char prom_printfbuf[PROM_PRINTFBUF_SIZE];
 
@@ -98,10 +100,13 @@
 {
 	setup_prom_vectors();
 
-	if (current_cpu_data.cputype == CPU_R5000)
+	if (current_cpu_data.cputype == CPU_R5000) {
 		mips_machtype = MACH_LASAT_200;
-	else
+		lasat_ndelay_divider = 8;
+	} else {
 		mips_machtype = MACH_LASAT_100;
+		lasat_ndelay_divider = 20;
+	}
 
 	at93c = &at93c_defs[mips_machtype];
 
Index: include/asm-mips/lasat/lasat.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/lasat/lasat.h,v
retrieving revision 1.1.2.4
diff -u -r1.1.2.4 lasat.h
--- include/asm-mips/lasat/lasat.h	5 Jul 2003 13:17:04 -0000	1.1.2.4
+++ include/asm-mips/lasat/lasat.h	5 Jul 2003 14:21:59 -0000
@@ -226,10 +226,16 @@
 /* for calibration of delays */
 
 #include <asm/delay.h>
-#define NANOTH 1000000000L
-extern inline void ndelay(unsigned int ns) {
-	if (ns != 0)
-		__delay(lasat_board_info.li_cpu_hz / 2 / (NANOTH / ns) + 1);
+#include <asm/bootinfo.h>
+/* calculating with the slowest board with 100 MHz clock */
+#define LASAT_100_DIVIDER 20
+/* All 200's run at 250 MHz clock */
+#define LASAT_200_DIVIDER 8
+
+extern unsigned int lasat_ndelay_divider;
+
+extern inline void lasat_ndelay(unsigned int ns) {
+	__delay(ns / lasat_ndelay_divider);
 }
 
 extern void (* prom_printf)(const char *fmt, ...);

From Geert.Uytterhoeven@sonycom.com Sat Jul  5 22:17:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 22:17:25 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:64246 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224802AbTGEVRX>;
	Sat, 5 Jul 2003 22:17:23 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h65LGn1W013410;
	Sat, 5 Jul 2003 23:16:49 +0200 (MEST)
Date: Sat, 5 Jul 2003 23:16:49 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Brian Murphy <brm@murphy.dk>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.4] ndelay typo?
In-Reply-To: <20030705133426.GA3750@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0307052305180.23796-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2773
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Sat, 5 Jul 2003, Ralf Baechle wrote:
> On Sat, Jul 05, 2003 at 03:22:22PM +0200, Brian Murphy wrote:
> > 	I presume you meant this?
> 
> Yes, thanks, will fix.

And don't you want to rename the `usecs' parameter of ndelay() to `nsecs'?

> I'm wondering about the Nile4 support btw.   Vrc5074 == NILE4, right?

Yep.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From ralf@linux-mips.org Sat Jul  5 23:55:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jul 2003 23:55:16 +0100 (BST)
Received: from p508B5C15.dip.t-dialin.net ([IPv6:::ffff:80.139.92.21]:15571
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224802AbTGEWzN>; Sat, 5 Jul 2003 23:55:13 +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 h65MsoDB029046;
	Sun, 6 Jul 2003 00:54:50 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h65MsjVP029042;
	Sun, 6 Jul 2003 00:54:45 +0200
Date: Sun, 6 Jul 2003 00:54:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Brian Murphy <brm@murphy.dk>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.4] ndelay typo?
Message-ID: <20030705225445.GA26533@linux-mips.org>
References: <20030705133426.GA3750@linux-mips.org> <Pine.GSO.4.21.0307052305180.23796-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0307052305180.23796-100000@vervain.sonytel.be>
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: 2774
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Jul 05, 2003 at 11:16:49PM +0200, Geert Uytterhoeven wrote:

> And don't you want to rename the `usecs' parameter of ndelay() to `nsecs'?

You've not looked at what I actually checked in, I renamed the argument.

> > I'm wondering about the Nile4 support btw.   Vrc5074 == NILE4, right?
> 
> Yep.

Well, I was wondering because the code in arch/mips/pci/ops-nile4.c which
was extraced from the lasat code is completly different from
ddb5xxx/ddb5074/pci_ops.c, so it's hard to extract the commonc code into
a shared file.

  Ralf

From drow@false.org Mon Jul  7 03:54:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Jul 2003 03:55:12 +0100 (BST)
Received: from crack.them.org ([IPv6:::ffff:146.82.138.56]:22157 "EHLO
	crack.them.org") by linux-mips.org with ESMTP id <S8225072AbTGGCyj>;
	Mon, 7 Jul 2003 03:54:39 +0100
Received: from dsl093-172-017.pit1.dsl.speakeasy.net
	([66.93.172.17] helo=nevyn.them.org ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 19ZM9l-00055B-00; Sun, 06 Jul 2003 21:55:09 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19ZM8T-00042y-00; Sun, 06 Jul 2003 22:53:49 -0400
Date: Sun, 6 Jul 2003 22:53:43 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: Rahul Pande <rahul.pande@wipro.com>
Cc: linux-mips@linux-mips.org
Subject: Re: gdbserver on mips
Message-ID: <20030707025343.GA15510@nevyn.them.org>
References: <52C85426D39B314381D76DDD480EEE0CDA556C@blr-m3-msg.wipro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52C85426D39B314381D76DDD480EEE0CDA556C@blr-m3-msg.wipro.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@false.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: 2775
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Fri, Jul 04, 2003 at 07:13:14PM +0530, Rahul Pande wrote:
> 
> Hi,
>  
>  I am working on a AMD Au1500 based board and want some information. I
> am using the Linux 2.4.21pre. The problem happens when i run an
> application under "gdbserver" on the board, it does not allow me to
> single step into functions/code. The following error is displayed :
>                 "ptrace : Input/Output error". 
>  
> The  "ptrace.c" file under arch/mips/kernel/ does not have support for
> PTRACE_SINGLESTEP because of which the above error is occuring. I would
> like to know why single stepping support is not there for mips
> architecture under linux, whereas it is there for others like i386,
> alpha, arm etc ?

You're using too old of a GDB then.  It should not attempt to
single-step.

> **************************Disclaimer************************************
> 
> Information contained in this E-MAIL being proprietary to Wipro Limited is 
> 'privileged' and 'confidential' and intended for use only by the individual
>  or entity to which it is addressed. You are notified that any use, copying 
> or dissemination of the information contained in the E-MAIL in any manner 
> whatsoever is strictly prohibited.
> 
> ***************************************************************************

Don't do that again.  Period.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From renwei@huawei.com Tue Jul  8 09:03:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jul 2003 09:03:14 +0100 (BST)
Received: from huawei.com ([IPv6:::ffff:61.144.161.2]:62234 "EHLO
	mta0.huawei.com") by linux-mips.org with ESMTP id <S8225201AbTGHIDM>;
	Tue, 8 Jul 2003 09:03:12 +0100
Received: from r19223b (mta0.huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HHP00HRJ4YDVV@mta0.huawei.com> for
 linux-mips@linux-mips.org; Tue, 08 Jul 2003 16:01:25 +0800 (CST)
Date: Tue, 08 Jul 2003 16:00:08 +0800
From: renwei <renwei@huawei.com>
Subject: gdb/insight 5.3 buggy   in kernel module debug
To: linux-mips@linux-mips.org
Message-id: <003501c34526$f5adfcc0$6efc0b0a@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Return-Path: <renwei@huawei.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: 2776
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: renwei@huawei.com
Precedence: bulk
X-list: linux-mips

Is there anyone else find the same problem?


I download the gdb/insight 5.3 , want to use 
it to debug my mipsel idt334 board.
configure as --target=mipsel-linux.

when connect to the target , it always give me
some wrong addr:

new thead xxxxxx
   0xffffffff83f28040 in ??()
something like that.
and the backtrace command can't work, also.
but my gdb5.0 for mipsel is ok.


I think that's the gdb get the pc as 64bit, but my 
board's cpu is 32bit, so it can't get the correct pc ...
The kernel addr is up to 0x80000000, so it's negative.

I trace the gdb5.3 , and find the place in 
mips-tdep.c, so I just fix the read_pc , make it 
as 32bit , now it can work, and the backtrace command 
can display the call trace .

But I'm not sure if my fix is a full one ? 
Anyone have full patch please tell me ...

                                      renc


From Geert.Uytterhoeven@sonycom.com Wed Jul  9 08:58:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jul 2003 08:58:38 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:46823 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225210AbTGIH6g>;
	Wed, 9 Jul 2003 08:58:36 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h697w81W013669;
	Wed, 9 Jul 2003 09:58:09 +0200 (MEST)
Date: Wed, 9 Jul 2003 09:58:08 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Brian Murphy <brm@murphy.dk>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Nile 4 (was: Re: [PATCH 2.4] ndelay typo?)
In-Reply-To: <20030705225445.GA26533@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0307090953320.18825-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2777
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Sun, 6 Jul 2003, Ralf Baechle wrote:
> On Sat, Jul 05, 2003 at 11:16:49PM +0200, Geert Uytterhoeven wrote:
> > > I'm wondering about the Nile4 support btw.   Vrc5074 == NILE4, right?
> > 
> > Yep.
> 
> Well, I was wondering because the code in arch/mips/pci/ops-nile4.c which
> was extraced from the lasat code is completly different from
> ddb5xxx/ddb5074/pci_ops.c, so it's hard to extract the commonc code into
> a shared file.

If you know the chip, they are actually quite similar :-)

The differences between the Lasat and the DDB code are these:
  - The Lasat code checks the PCI error registers to detect the presence of PCI
    devices, while the DDB code doesn't,
  - The Lasat code is limited to 8 PCI devices on bus 0, while the DDB code
    uses a different access scheme to access the extra devices,
  - The DDB code uses abstraction functions to access the Nile 4 registers,
    while the Lasat code accesses the registers directly.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From ralf@linux-mips.org Wed Jul  9 13:37:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jul 2003 13:37:52 +0100 (BST)
Received: from p508B5A26.dip.t-dialin.net ([IPv6:::ffff:80.139.90.38]:18354
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225210AbTGIMhu>; Wed, 9 Jul 2003 13:37: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 h69Cb2DB030382;
	Wed, 9 Jul 2003 14:37:02 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h69CavDZ030381;
	Wed, 9 Jul 2003 14:36:57 +0200
Date: Wed, 9 Jul 2003 14:36:57 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: renwei <renwei@huawei.com>
Cc: linux-mips@linux-mips.org
Subject: Re: gdb/insight 5.3 buggy   in kernel module debug
Message-ID: <20030709123657.GA30305@linux-mips.org>
References: <003501c34526$f5adfcc0$6efc0b0a@huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003501c34526$f5adfcc0$6efc0b0a@huawei.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: 2778
X-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, Jul 08, 2003 at 04:00:08PM +0800, renwei wrote:

> new thead xxxxxx
>    0xffffffff83f28040 in ??()
> something like that.
> and the backtrace command can't work, also.
> but my gdb5.0 for mipsel is ok.
> 
> 
> I think that's the gdb get the pc as 64bit, but my 
> board's cpu is 32bit, so it can't get the correct pc ...
> The kernel addr is up to 0x80000000, so it's negative.

On 64-bit processors running 32-bit code the actual values in the
registers are sign-extended to 64-bit, so that behaviour of your gdb
seems right.  Fix whatever places do return a zero-extended values.

  Ralf

From ralf@linux-mips.org Wed Jul  9 23:46:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jul 2003 23:46:18 +0100 (BST)
Received: from p508B5A26.dip.t-dialin.net ([IPv6:::ffff:80.139.90.38]:15318
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225212AbTGIWqQ>; Wed, 9 Jul 2003 23:46: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 h69MjrDB029305;
	Thu, 10 Jul 2003 00:45:53 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h69MjoMT029304;
	Thu, 10 Jul 2003 00:45:50 +0200
Date: Thu, 10 Jul 2003 00:45:50 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Brian Murphy <brm@murphy.dk>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Nile 4
Message-ID: <20030709224550.GA30793@linux-mips.org>
References: <20030705225445.GA26533@linux-mips.org> <Pine.GSO.4.21.0307090953320.18825-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0307090953320.18825-100000@vervain.sonytel.be>
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: 2779
X-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, Jul 09, 2003 at 09:58:08AM +0200, Geert Uytterhoeven wrote:

> > Well, I was wondering because the code in arch/mips/pci/ops-nile4.c which
> > was extraced from the lasat code is completly different from
> > ddb5xxx/ddb5074/pci_ops.c, so it's hard to extract the commonc code into
> > a shared file.
> 
> If you know the chip, they are actually quite similar :-)
> 
> The differences between the Lasat and the DDB code are these:
>   - The Lasat code checks the PCI error registers to detect the presence of PCI
>     devices, while the DDB code doesn't,
>   - The Lasat code is limited to 8 PCI devices on bus 0, while the DDB code
>     uses a different access scheme to access the extra devices,
>   - The DDB code uses abstraction functions to access the Nile 4 registers,
>     while the Lasat code accesses the registers directly.

Time to cleanup that mess also then.

Does anybody still care about the DDB5074?  I was just told somebody tried
it and it didn't boot into userspace ...

  Ralf

From jsun@mvista.com Wed Jul  9 23:57:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jul 2003 23:57:18 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:63988 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225212AbTGIW5Q>;
	Wed, 9 Jul 2003 23:57:16 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h69Musm32613;
	Wed, 9 Jul 2003 15:56:54 -0700
Date: Wed, 9 Jul 2003 15:56:54 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] _syscall macros
Message-ID: <20030709155654.L27926@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2780
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


In testing some new syscalls, I found that the current 
_syscall macros do not return the right errno.  A little
further probing shows that errno now is a function call,
and on returning from the call original __v0 from syscall
is corrupted.

Here is a patch to fix this.  Looks good?

Jun

--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030709.a-errno-messed-up-in-syscall-macros.patch"

diff -Nru link/include/asm-mips/unistd.h.orig link/include/asm-mips/unistd.h
--- link/include/asm-mips/unistd.h.orig	Thu Nov  7 14:05:44 2002
+++ link/include/asm-mips/unistd.h	Wed Jul  9 15:42:32 2003
@@ -276,7 +276,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -302,7 +302,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -325,7 +325,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -349,7 +349,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -373,7 +373,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -406,7 +406,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -437,7 +437,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -471,7 +471,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
diff -Nru link/include/asm-mips64/unistd.h.orig link/include/asm-mips64/unistd.h
--- link/include/asm-mips64/unistd.h.orig	Wed Apr  9 14:40:24 2003
+++ link/include/asm-mips64/unistd.h	Wed Jul  9 15:43:11 2003
@@ -729,7 +729,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -755,7 +755,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -778,7 +778,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -802,7 +802,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -826,7 +826,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -853,7 +853,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -884,7 +884,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -916,7 +916,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -951,7 +951,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -982,7 +982,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 
@@ -1016,7 +1016,7 @@
 	\
 	if (__a3 == 0) \
 		return (type) __v0; \
-	errno = __v0; \
+	{ int ret = __v0; errno = ret; } \
 	return -1; \
 }
 

--wac7ysb48OaltWcw--

From Geert.Uytterhoeven@sonycom.com Thu Jul 10 08:30:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jul 2003 08:30:03 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:20352 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224861AbTGJHaA>;
	Thu, 10 Jul 2003 08:30:00 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h6A7TT1W017871;
	Thu, 10 Jul 2003 09:29:30 +0200 (MEST)
Date: Thu, 10 Jul 2003 09:29:29 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Brian Murphy <brm@murphy.dk>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Nile 4
In-Reply-To: <20030709224550.GA30793@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0307100927340.3972-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2781
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Thu, 10 Jul 2003, Ralf Baechle wrote:
> Does anybody still care about the DDB5074?  I was just told somebody tried
> it and it didn't boot into userspace ...

A few weeks ago I gave it a try (2.4.21-pre4), but I didn't bother to set up a
Debian root on NFS to check userspace. At least the kernel booted until IP
autoconfig.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From brm@murphy.dk Thu Jul 10 19:38:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jul 2003 19:38:24 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:297
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8225217AbTGJSiV>; Thu, 10 Jul 2003 19:38:21 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19agIk-0000yu-00; Thu, 10 Jul 2003 20:37:54 +0200
To: ralf@linux-mips.org
Subject: [PATCH 2.5] LASAT updates - now it boots- whoohoo
Cc: linux-mips@linux-mips.org
Message-Id: <E19agIk-0000yu-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Thu, 10 Jul 2003 20:37:54 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2782
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi Ralf,
	this patch gets the code into the shape where I get up into
userspace - on the boards with flash I can login and the system 
mostly works. On the boards with disks I cant login and I get a 
lot of exceptions on startup but it looks close to working.
The pcnet32 patch is necessary for LASAT and I have not been able
to get a response from anyone with network code responsibility to
even comment the patch. Surely this patch which is necessary for
a platform can be accepted via linux-mips (you) when you merge with
Linus?

/Brian

Index: arch/mips/Kconfig-shared
===================================================================
RCS file: /cvs/linux/arch/mips/Kconfig-shared,v
retrieving revision 1.55
diff -u -r1.55 Kconfig-shared
--- arch/mips/Kconfig-shared	9 Jul 2003 18:13:02 -0000	1.55
+++ arch/mips/Kconfig-shared	10 Jul 2003 18:21:41 -0000
@@ -107,14 +107,6 @@
 config LASAT
 	bool "Support for LASAT Networks platforms"
 
-config LASAT_100
-	bool "Support for LASAT Networks 100 series"
-	depends on LASAT
-
-config LASAT_200
-	bool "Support for LASAT Networks 200 series"
-	depends on LASAT
-
 config PICVUE
 	tristate "PICVUE LCD display driver"
 	depends on LASAT
Index: arch/mips/lasat/prom.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/prom.c,v
retrieving revision 1.4
diff -u -r1.4 prom.c
--- arch/mips/lasat/prom.c	7 Apr 2003 00:17:52 -0000	1.4
+++ arch/mips/lasat/prom.c	8 Jul 2003 18:54:58 -0000
@@ -76,7 +76,7 @@
 {
 	u32 version = *(u32 *)(RESET_VECTOR + 0x90);
 
-	if (version == 306) {
+	if (version >= 307) {
 		prom_display = (void *)PROM_DISPLAY_ADDR;
 		prom_putc = (void *)PROM_PUTC_ADDR;
 		prom_printf = real_prom_printf;
Index: arch/mips/lasat/setup.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/setup.c,v
retrieving revision 1.7
diff -u -r1.7 setup.c
--- arch/mips/lasat/setup.c	5 Jun 2003 18:23:59 -0000	1.7
+++ arch/mips/lasat/setup.c	10 Jul 2003 18:04:46 -0000
@@ -36,7 +36,9 @@
 #include <asm/irq.h>
 #include <asm/lasat/lasat.h>
 
+#include <linux/tty.h>
 #include <linux/serial.h>
+#include <linux/serial_core.h>
 #include <asm/serial.h>
 #include <asm/lasat/serial.h>
 
@@ -150,28 +152,28 @@
 	ll_timer_interrupt(MIPS_CPU_TIMER_IRQ, regs);
 }
 
-//#define DYNAMIC_SERIAL_INIT
+#define DYNAMIC_SERIAL_INIT
 #ifdef DYNAMIC_SERIAL_INIT
 void __init serial_init(void)
 {
-#ifdef CONFIG_SERIAL
-	struct serial_struct s;
+#ifdef CONFIG_SERIAL_8250
+	struct uart_port s;
 
 	memset(&s, 0, sizeof(s));
 
-	s.flags = STD_COM_FLAGS;
-	s.io_type = SERIAL_IO_MEM;
+	s.flags = STD_COM_FLAGS|UPF_RESOURCES;
+	s.iotype = SERIAL_IO_MEM;
 
 	if (mips_machtype == MACH_LASAT_100) {
-		s.baud_base = LASAT_BASE_BAUD_100;
+		s.uartclk = LASAT_BASE_BAUD_100 * 16;
 		s.irq = LASATINT_UART_100;
-		s.iomem_reg_shift = LASAT_UART_REGS_SHIFT_100;
-		s.iomem_base = (u8 *)KSEG1ADDR(LASAT_UART_REGS_BASE_100);
+		s.regshift = LASAT_UART_REGS_SHIFT_100;
+		s.membase = (char *)KSEG1ADDR(LASAT_UART_REGS_BASE_100);
 	} else {
-		s.baud_base = LASAT_BASE_BAUD_200;
+		s.uartclk = LASAT_BASE_BAUD_200 * 16;
 		s.irq = LASATINT_UART_200;
-		s.iomem_reg_shift = LASAT_UART_REGS_SHIFT_200;
-		s.iomem_base = (u8 *)KSEG1ADDR(LASAT_UART_REGS_BASE_200);
+		s.regshift = LASAT_UART_REGS_SHIFT_200;
+		s.membase = (char *)KSEG1ADDR(LASAT_UART_REGS_BASE_200);
 	}
 
 	if (early_serial_setup(&s) != 0)
Index: arch/mips/pci/Makefile
===================================================================
RCS file: /cvs/linux/arch/mips/pci/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- arch/mips/pci/Makefile	13 Jun 2003 13:58:31 -0000	1.1
+++ arch/mips/pci/Makefile	22 Jun 2003 11:14:46 -0000
@@ -12,7 +12,7 @@
 obj-$(CONFIG_DDB5477)		+= pci-ddb5477.o ops-ddb5477.o
 obj-$(CONFIG_HP_LASERJET)	+= pci-hplj.o
 obj-$(CONFIG_ITE_BOARD_GEN)	+= ops-it8172.o
-obj-$(CONFIG_LASAT)		+= pci-lasat.o
+obj-$(CONFIG_LASAT)		+= pci-lasat.o common.o
 obj-$(CONFIG_MIPS_BOARDS_GEN)	+= pci-mips.o
 obj-$(CONFIG_MIPS_COBALT)	+= pci-cobalt.o
 obj-$(CONFIG_MIPS_EV64120)	+= ops-ev64120.o
Index: arch/mips/pci/common.c
===================================================================
RCS file: /cvs/linux/arch/mips/pci/common.c,v
retrieving revision 1.2
diff -u -r1.2 common.c
--- arch/mips/pci/common.c	13 Jun 2003 14:19:56 -0000	1.2
+++ arch/mips/pci/common.c	22 Jun 2003 11:18:07 -0000
@@ -1,6 +1,9 @@
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+
 void __init pcibios_fixup_bus(struct pci_bus *b)
 {
-	Dprintk("pcibios_fixup_bus()\n");
 }
 
 static int pcibios_enable_resources(struct pci_dev *dev, int mask)
Index: arch/mips/pci/pci-lasat.c
===================================================================
RCS file: /cvs/linux/arch/mips/pci/pci-lasat.c,v
retrieving revision 1.3
diff -u -r1.3 pci-lasat.c
--- arch/mips/pci/pci-lasat.c	22 Jun 2003 02:19:24 -0000	1.3
+++ arch/mips/pci/pci-lasat.c	22 Jun 2003 11:20:18 -0000
@@ -239,7 +239,4 @@
 	return 0;
 }
 
-unsigned __init int pcibios_assign_all_busses(void)
-{
-	return 1;
-}
+subsys_initcall(pcibios_init);
Index: drivers/net/pcnet32.c
===================================================================
RCS file: /cvs/linux/drivers/net/pcnet32.c,v
retrieving revision 1.51
diff -u -r1.51 pcnet32.c
--- drivers/net/pcnet32.c	23 Jun 2003 01:23:05 -0000	1.51
+++ drivers/net/pcnet32.c	23 Jun 2003 19:18:33 -0000
@@ -769,9 +769,12 @@
     if (irq_line) {
 	dev->irq = irq_line;
     }
-    
+
+#ifndef CONFIG_LASAT
     if (dev->irq >= 2)
+#endif
 	printk(" assigned IRQ %d.\n", dev->irq);
+#ifndef CONFIG_LASAT
     else {
 	unsigned long irq_mask = probe_irq_on();
 	
@@ -794,6 +797,7 @@
 	    return -ENODEV;
 	}
     }
+#endif
 
     /* Set the mii phy_id so that we can query the link state */
     if (lp->mii)
Index: include/asm-mips/serial.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/serial.h,v
retrieving revision 1.39
diff -u -r1.39 serial.h
--- include/asm-mips/serial.h	15 Jun 2003 23:42:07 -0000	1.39
+++ include/asm-mips/serial.h	10 Jul 2003 18:21:22 -0000
@@ -156,13 +156,11 @@
 #endif
 
 #ifdef CONFIG_LASAT
-#include <asm/lasat/serial.h>
-#define LASAT_SERIAL_PORT_DEFNS						\
-	{ .baud_base = LASAT_BASE_BAUD, .irq = LASATINT_UART,		\
-	  .flags = STD_COM_FLAGS,						\
-	  .port = LASAT_UART_REGS_BASE, /* Only for display */		\
-	  .iomem_base = (u8 *)KSEG1ADDR(LASAT_UART_REGS_BASE),		\
-	  .iomem_reg_shift = LASAT_UART_REGS_SHIFT, .io_type = SERIAL_IO_MEM },
+/* This dummy definition allocates one element in the SERIAL_PORT_DFNS
+ * list below. This element is filled out by the the code in serial_init() 
+ * in arch/mips/lasat/setup.c which autoselects the configuration based 
+ * on machine type. */
+#define LASAT_SERIAL_PORT_DEFNS { },
 #else
 #define LASAT_SERIAL_PORT_DEFNS
 #endif
Index: include/asm-mips/lasat/serial.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/lasat/serial.h,v
retrieving revision 1.2
diff -u -r1.2 serial.h
--- include/asm-mips/lasat/serial.h	25 Feb 2003 22:39:02 -0000	1.2
+++ include/asm-mips/lasat/serial.h	10 Jul 2003 18:08:18 -0000
@@ -11,18 +11,3 @@
 #define LASAT_UART_REGS_BASE_200	(Vrc5074_PHYS_BASE + 0x0300)
 #define LASAT_UART_REGS_SHIFT_200	3
 #define LASATINT_UART_200		13
-
-#if defined(CONFIG_LASAT_100)
-#define LASAT_BASE_BAUD		LASAT_BASE_BAUD_200
-#define LASAT_UART_REGS_BASE	LASAT_UART_REGS_BASE_200
-#define LASAT_UART_REGS_SHIFT	LASAT_UART_REGS_SHIFT_200
-#define LASATINT_UART		LASAT_UART_REGS_SHIFT_200
-#elif defined(CONFIG_LASAT_200)
-#define LASAT_BASE_BAUD		LASAT_BASE_BAUD_200
-#define LASAT_UART_REGS_BASE	LASAT_UART_REGS_BASE_200
-#define LASAT_UART_REGS_SHIFT	LASAT_UART_REGS_SHIFT_200
-#define LASATINT_UART		LASAT_UART_REGS_SHIFT_200
-#else
-#error Select a Lasat board in the configuration menu
-#endif
-

From renwei@huawei.com Fri Jul 11 03:17:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jul 2003 03:17:48 +0100 (BST)
Received: from huawei.com ([IPv6:::ffff:61.144.161.2]:20116 "EHLO
	mta0.huawei.com") by linux-mips.org with ESMTP id <S8225217AbTGKCRq>;
	Fri, 11 Jul 2003 03:17:46 +0100
Received: from r19223b (mta0.huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HHU000FW8YO5W@mta0.huawei.com>; Fri,
 11 Jul 2003 10:16:01 +0800 (CST)
Date: Fri, 11 Jul 2003 10:14:44 +0800
From: renwei <renwei@huawei.com>
Subject: [patch]: gdb/insight 5.3 buggy   in kernel module debug
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Message-id: <000701c34752$3263d680$6efc0b0a@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <003501c34526$f5adfcc0$6efc0b0a@huawei.com>
 <20030709123657.GA30305@linux-mips.org>
Return-Path: <renwei@huawei.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: 2783
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: renwei@huawei.com
Precedence: bulk
X-list: linux-mips

Here's my patch to this problem, change the read pc on mips32 cpu.

Maybe someone want it.
change mips-tdep.c
///////////////////////////////////////////////////////////////////////////////////////
766c766,772
<   return read_signed_register_pid (PC_REGNUM, ptid);
---
>   /*add by renwei , if mips 32, the pc should be some positive number,
>    or the gdb can't lookup the backtrace in kernel*/
>   LONGEST lpc = read_signed_register_pid (PC_REGNUM, ptid);
>   if(REGISTER_RAW_SIZE(PC_REGNUM) < (int)sizeof(LONGEST))
>     lpc &= 0x00000000ffffffffLL;
>   
>   return lpc;
1703c1709,1714
< 
---
>   
>   /*add by renwei , if mips 32, the pc should be some positive number,
>    or the gdb can't lookup the backtrace in kernel*/
>   if(REGISTER_RAW_SIZE(PC_REGNUM) < (int)sizeof(LONGEST))
>     saved_pc &= 0x00000000ffffffffLL;
>   
/////////////////////////////////////////////////////////////////////////////////////////////




Another problem:   insight 5.3 compile error on cygwin.
fix  tclWin32Dll.c
/////////////////////////////////////////////////////////////////////////////////
121c121,122
< static Tcl_Encoding tclWinTCharEncoding;
---
> /*change this to global*/
> Tcl_Encoding tclWinTCharEncoding;
///////////////////////////////////////////////////////////////////////////////////


                                                          renc 

From ralf@linux-mips.org Fri Jul 11 03:31:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jul 2003 03:31:27 +0100 (BST)
Received: from p508B62D9.dip.t-dialin.net ([IPv6:::ffff:80.139.98.217]:22728
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224861AbTGKCbZ>; Fri, 11 Jul 2003 03:31: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 h6B2V7DB010905;
	Fri, 11 Jul 2003 04:31:08 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6B2V1Rt010904;
	Fri, 11 Jul 2003 04:31:01 +0200
Date: Fri, 11 Jul 2003 04:31:01 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: renwei <renwei@huawei.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch]: gdb/insight 5.3 buggy   in kernel module debug
Message-ID: <20030711023101.GA10643@linux-mips.org>
References: <003501c34526$f5adfcc0$6efc0b0a@huawei.com> <20030709123657.GA30305@linux-mips.org> <000701c34752$3263d680$6efc0b0a@huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000701c34752$3263d680$6efc0b0a@huawei.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: 2784
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jul 11, 2003 at 10:14:44AM +0800, renwei wrote:

> Here's my patch to this problem, change the read pc on mips32 cpu.

Don't send GDB patches to me, I'm not maintaining GDB; drow@mvista.com is
probably a better address.

Also a standard rant - never ever send ed-style patches; any maintainer
will probably just drop them.

  Ralf

From drow@crack.them.org Fri Jul 11 03:43:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jul 2003 03:43:27 +0100 (BST)
Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([IPv6:::ffff:66.93.172.17]:38540
	"EHLO nevyn.them.org") by linux-mips.org with ESMTP
	id <S8224861AbTGKCnZ>; Fri, 11 Jul 2003 03:43:25 +0100
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19ansH-0004lf-00; Thu, 10 Jul 2003 22:43:05 -0400
Date: Thu, 10 Jul 2003 22:43:05 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: renwei <renwei@huawei.com>, linux-mips@linux-mips.org
Subject: Re: [patch]: gdb/insight 5.3 buggy   in kernel module debug
Message-ID: <20030711024305.GA18249@nevyn.them.org>
References: <003501c34526$f5adfcc0$6efc0b0a@huawei.com> <20030709123657.GA30305@linux-mips.org> <000701c34752$3263d680$6efc0b0a@huawei.com> <20030711023101.GA10643@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030711023101.GA10643@linux-mips.org>
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: 2785
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Fri, Jul 11, 2003 at 04:31:01AM +0200, Ralf Baechle wrote:
> On Fri, Jul 11, 2003 at 10:14:44AM +0800, renwei wrote:
> 
> > Here's my patch to this problem, change the read pc on mips32 cpu.
> 
> Don't send GDB patches to me, I'm not maintaining GDB; drow@mvista.com is
> probably a better address.
> 
> Also a standard rant - never ever send ed-style patches; any maintainer
> will probably just drop them.

Please don't send them to me either - send them to
gdb-patches@sources.redhat.com, where they belong.

Andrew will tell you that the 64-bit signed PC is correct.  The bug is
in whatever code is not sign extending, probably in the symbol reader. 
If you're using stabs try dwarf-2 instead.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From kwalker@broadcom.com Mon Jul 14 17:59:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Jul 2003 17:59:49 +0100 (BST)
Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:19977 "EHLO
	mms1.broadcom.com") by linux-mips.org with ESMTP
	id <S8225226AbTGNQ7r>; Mon, 14 Jul 2003 17:59:47 +0100
Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.2)); Mon, 14 Jul 2003 09:59:15 -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 JAA12570 for <linux-mips@linux-mips.org>; Mon, 14 Jul 2003 09:48:35
 -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
 h6EGmwov019430 for <linux-mips@linux-mips.org>; Mon, 14 Jul 2003 09:48:
 59 -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 JAA00965 for
 <linux-mips@linux-mips.org>; Mon, 14 Jul 2003 09:48:58 -0700
Message-ID: <3F12DEFA.5668FC4@broadcom.com>
Date: Mon, 14 Jul 2003 09:48:58 -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] o32 sigcontext fixes for mips64
X-WSS-ID: 130C3E852077323-262-01
Content-Type: multipart/mixed;
 boundary=------------920406A1B4583B8D856B46BD
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: 2786
X-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

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


This 2.4 patch fixes some issues with the signal context save and
restore for o32 binaries running on the mips64 kernel.

Any comments?

Kip
--------------920406A1B4583B8D856B46BD
Content-Type: text/plain;
 charset=us-ascii;
 name=o32_sigcontext.diff
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename=o32_sigcontext.diff

Index: include/asm-mips64/fpu.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/fpu.h,v
retrieving revision 1.1.2.4
diff -u -r1.1.2.4 fpu.h
--- include/asm-mips64/fpu.h	9 Apr 2003 00:46:24 -0000	1.1.2.4
+++ include/asm-mips64/fpu.h	14 Jul 2003 16:45:05 -0000
@@ -21,9 +21,13 @@
 #include <asm/current.h>
 
 struct sigcontext;
+struct sigcontext32;
 
 extern asmlinkage int (*save_fp_context)(struct sigcontext *sc);
 extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
+
+extern asmlinkage int (*save_fp_context32)(struct sigcontext32 *sc);
+extern asmlinkage int (*restore_fp_context32)(struct sigcontext32 *sc);
 
 extern void fpu_emulator_init_fpu(void);
 extern void _init_fpu(void);
Index: include/asm-mips64/sigcontext.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/sigcontext.h,v
retrieving revision 1.3.2.2
diff -u -r1.3.2.2 sigcontext.h
--- include/asm-mips64/sigcontext.h	4 Nov 2002 19:39:56 -0000	1.3.2.2
+++ include/asm-mips64/sigcontext.h	14 Jul 2003 16:45:05 -0000
@@ -27,4 +27,24 @@
 	unsigned int       sc_badvaddr;
 };
 
+struct sigcontext32 {
+	u32 sc_regmask;		/* Unused */
+	u32 sc_status;
+	u64 sc_pc;
+	u64 sc_regs[32];
+	u64 sc_fpregs[32];
+	u32 sc_ownedfp;		/* Unused */
+	u32 sc_fpc_csr;
+	u32 sc_fpc_eir;		/* Unused */
+	u32 sc_used_math;
+	u32 sc_ssflags;		/* Unused */
+	u64 sc_mdhi;
+	u64 sc_mdlo;
+
+	u32 sc_cause;		/* Unused */
+	u32 sc_badvaddr;	/* Unused */
+
+	u32 sc_sigset[4];	/* kernel's sigset_t */
+};
+
 #endif /* _ASM_SIGCONTEXT_H */
Index: arch/mips/tools/offset.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/tools/Attic/offset.c,v
retrieving revision 1.16.4.6
diff -u -r1.16.4.6 offset.c
--- arch/mips/tools/offset.c	4 Nov 2002 19:39:56 -0000	1.16.4.6
+++ arch/mips/tools/offset.c	14 Jul 2003 16:45:05 -0000
@@ -8,6 +8,7 @@
  * Kevin Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com
  * Copyright (C) 2000 MIPS Technologies, Inc.
  */
+#include <linux/config.h>
 #include <linux/types.h>
 #include <linux/sched.h>
 #include <linux/mm.h>
@@ -156,6 +157,14 @@
 	offset("#define SC_CAUSE      ", struct sigcontext, sc_cause);
 	offset("#define SC_BADVADDR   ", struct sigcontext, sc_badvaddr);
 	linefeed;
+
+#ifdef CONFIG_MIPS64
+	text("/* Linux 32-bit sigcontext offsets. */");
+	offset("#define SC32_FPREGS     ", struct sigcontext32, sc_fpregs);
+	offset("#define SC32_FPC_CSR    ", struct sigcontext32, sc_fpc_csr);
+	offset("#define SC32_FPC_EIR    ", struct sigcontext32, sc_fpc_eir);
+	linefeed;
+#endif
 }
 
 void output_signal_defined(void)
Index: arch/mips64/kernel/signal32.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/signal32.c,v
retrieving revision 1.20.2.12
diff -u -r1.20.2.12 signal32.c
--- arch/mips64/kernel/signal32.c	12 Mar 2003 15:44:06 -0000	1.20.2.12
+++ arch/mips64/kernel/signal32.c	14 Jul 2003 16:45:06 -0000
@@ -60,6 +60,14 @@
 	int ss_flags;
 } stack32_t;
 
+struct ucontext32 {
+	u32                 uc_flags;
+	s32                 uc_link;
+	stack32_t           uc_stack;
+	struct sigcontext32 uc_mcontext;
+	sigset_t32          uc_sigmask;   /* mask last for extensibility */
+};
+
 extern void __put_sigset_unknown_nsig(void);
 extern void __get_sigset_unknown_nsig(void);
 
@@ -250,8 +258,8 @@
 	return ret;
 }
 
-static asmlinkage int restore_sigcontext(struct pt_regs *regs,
-					 struct sigcontext *sc)
+static asmlinkage int restore_sigcontext32(struct pt_regs *regs,
+					   struct sigcontext32 *sc)
 {
 	int err = 0;
 
@@ -280,7 +288,7 @@
 	if (current->used_math) {
 		/* restore fpu context if we have used it before */
 		own_fpu();
-		err |= restore_fp_context(sc);
+		err |= restore_fp_context32(sc);
 	} else {
 		/* signal handler may have used FPU.  Give it up. */
 		loose_fpu();
@@ -292,7 +300,7 @@
 struct sigframe {
 	u32 sf_ass[4];			/* argument save space for o32 */
 	u32 sf_code[2];			/* signal trampoline */
-	struct sigcontext sf_sc;
+	struct sigcontext32 sf_sc;
 	sigset_t sf_mask;
 };
 
@@ -300,7 +308,7 @@
 	u32 rs_ass[4];			/* argument save space for o32 */
 	u32 rs_code[2];			/* signal trampoline */
 	struct siginfo32 rs_info;
-	struct ucontext rs_uc;
+	struct ucontext32 rs_uc;
 };
 
 static int copy_siginfo_to_user32(siginfo_t32 *to, siginfo_t *from)
@@ -362,7 +370,7 @@
 	recalc_sigpending(current);
 	spin_unlock_irq(&current->sigmask_lock);
 
-	if (restore_sigcontext(&regs, &frame->sf_sc))
+	if (restore_sigcontext32(&regs, &frame->sf_sc))
 		goto badframe;
 
 	/*
@@ -386,6 +394,7 @@
 	struct rt_sigframe32 *frame;
 	sigset_t set;
 	stack_t st;
+	s32 sp;
 
 	frame = (struct rt_sigframe32 *) regs.regs[29];
 	if (!access_ok(VERIFY_READ, frame, sizeof(*frame)))
@@ -399,11 +408,18 @@
 	recalc_sigpending(current);
 	spin_unlock_irq(&current->sigmask_lock);
 
-	if (restore_sigcontext(&regs, &frame->rs_uc.uc_mcontext))
+	if (restore_sigcontext32(&regs, &frame->rs_uc.uc_mcontext))
 		goto badframe;
 
-	if (__copy_from_user(&st, &frame->rs_uc.uc_stack, sizeof(st)))
+	/* The ucontext contains a stack32_t, so we must convert!  */
+	if (__get_user(sp, &frame->rs_uc.uc_stack.ss_sp))
+		goto badframe;
+	st.ss_size = (long) sp;
+	if (__get_user(st.ss_size, &frame->rs_uc.uc_stack.ss_size))
 		goto badframe;
+	if (__get_user(st.ss_flags, &frame->rs_uc.uc_stack.ss_flags))
+		goto badframe;
+
 	/* It is more difficult to avoid calling this function than to
 	   call it and ignore errors.  */
 	do_sigaltstack(&st, NULL, regs.regs[29]);
@@ -422,8 +438,8 @@
 	force_sig(SIGSEGV, current);
 }
 
-static int inline setup_sigcontext(struct pt_regs *regs,
-				   struct sigcontext *sc)
+static int inline setup_sigcontext32(struct pt_regs *regs,
+				     struct sigcontext32 *sc)
 {
 	int err = 0;
 
@@ -462,7 +478,7 @@
 		own_fpu();
 		restore_fp(current);
 	}
-	err |= save_fp_context(sc);
+	err |= save_fp_context32(sc);
 
 out:
 	return err;
@@ -513,7 +529,7 @@
 	err |= __put_user(0x0000000c                     , frame->sf_code + 1);
 	flush_cache_sigtramp((unsigned long) frame->sf_code);
 
-	err |= setup_sigcontext(regs, &frame->sf_sc);
+	err |= setup_sigcontext32(regs, &frame->sf_sc);
 	err |= __copy_to_user(&frame->sf_mask, set, sizeof(*set));
 	if (err)
 		goto give_sigsegv;
@@ -554,6 +570,7 @@
 {
 	struct rt_sigframe32 *frame;
 	int err = 0;
+	s32 sp;
 
 	frame = get_sigframe(ka, regs, sizeof(*frame));
 	if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame)))
@@ -577,13 +594,14 @@
 	/* Create the ucontext.  */
 	err |= __put_user(0, &frame->rs_uc.uc_flags);
 	err |= __put_user(0, &frame->rs_uc.uc_link);
-	err |= __put_user((void *)current->sas_ss_sp,
+	sp = (int) (long) current->sas_ss_sp;
+	err |= __put_user(sp,
 	                  &frame->rs_uc.uc_stack.ss_sp);
 	err |= __put_user(sas_ss_flags(regs->regs[29]),
 	                  &frame->rs_uc.uc_stack.ss_flags);
 	err |= __put_user(current->sas_ss_size,
 	                  &frame->rs_uc.uc_stack.ss_size);
-	err |= setup_sigcontext(regs, &frame->rs_uc.uc_mcontext);
+	err |= setup_sigcontext32(regs, &frame->rs_uc.uc_mcontext);
 	err |= __copy_to_user(&frame->rs_uc.uc_sigmask, set, sizeof(*set));
 
 	if (err)
Index: arch/mips64/kernel/traps.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/traps.c,v
retrieving revision 1.30.2.54
diff -u -r1.30.2.54 traps.c
--- arch/mips64/kernel/traps.c	6 Jun 2003 04:36:37 -0000	1.30.2.54
+++ arch/mips64/kernel/traps.c	14 Jul 2003 16:45:06 -0000
@@ -781,12 +781,21 @@
 asmlinkage int (*save_fp_context)(struct sigcontext *sc);
 asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
 
+asmlinkage int (*save_fp_context32)(struct sigcontext32 *sc);
+asmlinkage int (*restore_fp_context32)(struct sigcontext32 *sc);
+
 extern asmlinkage int _save_fp_context(struct sigcontext *sc);
 extern asmlinkage int _restore_fp_context(struct sigcontext *sc);
 
+extern asmlinkage int _save_fp_context32(struct sigcontext32 *sc);
+extern asmlinkage int _restore_fp_context32(struct sigcontext32 *sc);
+
 extern asmlinkage int fpu_emulator_save_context(struct sigcontext *sc);
 extern asmlinkage int fpu_emulator_restore_context(struct sigcontext *sc);
 
+extern asmlinkage int fpu_emulator_save_context32(struct sigcontext32 *sc);
+extern asmlinkage int fpu_emulator_restore_context32(struct sigcontext32 *sc);
+
 void __init per_cpu_trap_init(void)
 {
 	unsigned int cpu = smp_processor_id();
@@ -904,9 +913,13 @@
 	if (cpu_has_fpu) {
 	        save_fp_context = _save_fp_context;
 		restore_fp_context = _restore_fp_context;
+	        save_fp_context32 = _save_fp_context32;
+		restore_fp_context32 = _restore_fp_context32;
 	} else {
 		save_fp_context = fpu_emulator_save_context;
 		restore_fp_context = fpu_emulator_restore_context;
+		save_fp_context32 = fpu_emulator_save_context32;
+		restore_fp_context32 = fpu_emulator_restore_context32;
 	}
 
 	flush_icache_range(KSEG0, KSEG0 + 0x400);
Index: arch/mips64/kernel/r4k_fpu.S
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/r4k_fpu.S,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 r4k_fpu.S
--- arch/mips64/kernel/r4k_fpu.S	31 Jul 2002 02:41:21 -0000	1.3.2.1
+++ arch/mips64/kernel/r4k_fpu.S	14 Jul 2003 16:45:06 -0000
@@ -5,6 +5,8 @@
  *
  * Save/restore floating point context for signal handlers.
  *
+ * Copyright (C) 2003 Broadcom Corporation
+ *
  * Copyright (C) 1996, 1998, 1999, 2001 by Ralf Baechle
  *
  * Multi-arch abstraction and asm macros for easier reading:
@@ -32,11 +34,8 @@
 	.set	noreorder
 	/* Save floating point context */
 LEAF(_save_fp_context)
-	mfc0	t1, CP0_STATUS
-	sll	t2, t1,5
+	cfc1	t1, fcr31
 
-	bgez	t2, 1f
-	 cfc1	t1, fcr31
 	/* Store the 16 odd double precision registers */
 	EX	sdc1 $f1, SC_FPREGS+8(a0)
 	EX	sdc1 $f3, SC_FPREGS+24(a0)
@@ -56,7 +55,6 @@
 	EX	sdc1 $f31, SC_FPREGS+248(a0)
 
 	/* Store the 16 even double precision registers */
-1:
 	EX	sdc1 $f0, SC_FPREGS+0(a0)
 	EX	sdc1 $f2, SC_FPREGS+16(a0)
 	EX	sdc1 $f4, SC_FPREGS+32(a0)
@@ -81,24 +79,42 @@
 	 li	v0, 0					# success
 	END(_save_fp_context)
 
+	/* Save 32-bit process floating point context */
+LEAF(_save_fp_context32)
+	cfc1	t1, fcr31
+
+	EX	sdc1 $f0, SC32_FPREGS+0(a0)
+	EX	sdc1 $f2, SC32_FPREGS+16(a0)
+	EX	sdc1 $f4, SC32_FPREGS+32(a0)
+	EX	sdc1 $f6, SC32_FPREGS+48(a0)
+	EX	sdc1 $f8, SC32_FPREGS+64(a0)
+	EX	sdc1 $f10, SC32_FPREGS+80(a0)
+	EX	sdc1 $f12, SC32_FPREGS+96(a0)
+	EX	sdc1 $f14, SC32_FPREGS+112(a0)
+	EX	sdc1 $f16, SC32_FPREGS+128(a0)
+	EX	sdc1 $f18, SC32_FPREGS+144(a0)
+	EX	sdc1 $f20, SC32_FPREGS+160(a0)
+	EX	sdc1 $f22, SC32_FPREGS+176(a0)
+	EX	sdc1 $f24, SC32_FPREGS+192(a0)
+	EX	sdc1 $f26, SC32_FPREGS+208(a0)
+	EX	sdc1 $f28, SC32_FPREGS+224(a0)
+	EX	sdc1 $f30, SC32_FPREGS+240(a0)
+	EX	sw t1, SC32_FPC_CSR(a0)
+	cfc1	t0, $0				# implementation/version
+	EX	sw t0, SC32_FPC_EIR(a0)
+
+	jr	ra
+	 li	v0, 0					# success
+	END(_save_fp_context32)
+
 /*
  * Restore FPU state:
  *  - fp gp registers
  *  - cp1 status/control register
- *
- * We base the decision which registers to restore from the signal stack
- * frame on the current content of c0_status, not on the content of the
- * stack frame which might have been changed by the user.
  */
 LEAF(_restore_fp_context)
-	mfc0	t1, CP0_STATUS
-	sll	t0, t1,5
-	bgez	t0, 1f
-	 EX	lw t0, SC_FPC_CSR(a0)
-
-	/* Restore the 16 odd double precision registers only
-	 * when enabled in the cp0 status register.
-	 */
+	/* Restore an o32/64 sigcontext. */
+	EX	lw t0, SC_FPC_CSR(a0)
 	EX	ldc1 $f1, SC_FPREGS+8(a0)
 	EX	ldc1 $f3, SC_FPREGS+24(a0)
 	EX	ldc1 $f5, SC_FPREGS+40(a0)
@@ -116,11 +132,7 @@
 	EX	ldc1 $f29, SC_FPREGS+232(a0)
 	EX	ldc1 $f31, SC_FPREGS+248(a0)
 
-	/*
-	 * Restore the 16 even double precision registers
-	 * when cp1 was enabled in the cp0 status register.
-	 */
-1:	EX	ldc1 $f0, SC_FPREGS+0(a0)
+	EX	ldc1 $f0, SC_FPREGS+0(a0)
 	EX	ldc1 $f2, SC_FPREGS+16(a0)
 	EX	ldc1 $f4, SC_FPREGS+32(a0)
 	EX	ldc1 $f6, SC_FPREGS+48(a0)
@@ -140,6 +152,30 @@
 	jr	ra
 	 li	v0, 0					# success
 	END(_restore_fp_context)
+
+LEAF(_restore_fp_context32)
+	/* Restore an o32 sigcontext.  */
+	EX	lw t0, SC32_FPC_CSR(a0)
+	EX	ldc1 $f0, SC32_FPREGS+0(a0)
+	EX	ldc1 $f2, SC32_FPREGS+16(a0)
+	EX	ldc1 $f4, SC32_FPREGS+32(a0)
+	EX	ldc1 $f6, SC32_FPREGS+48(a0)
+	EX	ldc1 $f8, SC32_FPREGS+64(a0)
+	EX	ldc1 $f10, SC32_FPREGS+80(a0)
+	EX	ldc1 $f12, SC32_FPREGS+96(a0)
+	EX	ldc1 $f14, SC32_FPREGS+112(a0)
+	EX	ldc1 $f16, SC32_FPREGS+128(a0)
+	EX	ldc1 $f18, SC32_FPREGS+144(a0)
+	EX	ldc1 $f20, SC32_FPREGS+160(a0)
+	EX	ldc1 $f22, SC32_FPREGS+176(a0)
+	EX	ldc1 $f24, SC32_FPREGS+192(a0)
+	EX	ldc1 $f26, SC32_FPREGS+208(a0)
+	EX	ldc1 $f28, SC32_FPREGS+224(a0)
+	EX	ldc1 $f30, SC32_FPREGS+240(a0)
+	ctc1	t0, fcr31
+	jr	ra
+	 li	v0, 0					# success
+	END(_restore_fp_context32)
 
 	.type	fault@function
 	.ent	fault
Index: arch/mips/math-emu/kernel_linkage.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/math-emu/kernel_linkage.c,v
retrieving revision 1.5.2.1
diff -u -r1.5.2.1 kernel_linkage.c
--- arch/mips/math-emu/kernel_linkage.c	5 Aug 2002 23:53:34 -0000	1.5.2.1
+++ arch/mips/math-emu/kernel_linkage.c	14 Jul 2003 16:45:06 -0000
@@ -90,3 +90,40 @@
 	return err;
 }
 
+#ifdef CONFIG_MIPS64
+/*
+ * This is the o32 version
+ */
+
+int fpu_emulator_save_context32(struct sigcontext32 *sc)
+{
+	int i;
+	int err = 0;
+
+	for (i = 0; i < 32; i+=2) {
+		err |=
+		    __put_user(current->thread.fpu.soft.regs[i],
+			       &sc->sc_fpregs[i]);
+	}
+	err |= __put_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
+	err |= __put_user(fpuemuprivate.eir, &sc->sc_fpc_eir);
+
+	return err;
+}
+
+int fpu_emulator_restore_context32(struct sigcontext32 *sc)
+{
+	int i;
+	int err = 0;
+
+	for (i = 0; i < 32; i+=2) {
+		err |=
+		    __get_user(current->thread.fpu.soft.regs[i],
+			       &sc->sc_fpregs[i]);
+	}
+	err |= __get_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
+	err |= __get_user(fpuemuprivate.eir, &sc->sc_fpc_eir);
+
+	return err;
+}
+#endif

--------------920406A1B4583B8D856B46BD--


From brm@murphy.dk Tue Jul 15 20:37:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jul 2003 20:37:57 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:24875
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8224802AbTGOThp>; Tue, 15 Jul 2003 20:37:45 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19cVcH-0003Lr-00; Tue, 15 Jul 2003 21:37:37 +0200
To: linux-mips@linux-mips.org
Subject: [PATCH 2.5] kbuild error for mips (and possibly others)
Cc: ralf@linux-mips.org
Message-Id: <E19cVcH-0003Lr-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Tue, 15 Jul 2003 21:37:37 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2787
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi,
	there is a very annoying error in the 2.5 kbuild process
where the generation of the elfconfig.h file depends on the proper
configuration of the kernel being available (for mips at least) 
but configuring the kernel disallows the inclusion of the .config file
and thus the configuration and specifically CROSS_COMPILE is not set. 
This causes empty.o to fail to build because CC is now gcc and not 
mips(el)-linux-gcc and the -G option to gcc is invalid for my cross
compiler.

This patch fixes the problem. It also makes the *config targets 
not dependant on having the helper programs in scripts/ compiled
which they shouldn't be. They are not necessary.

/Brian

Index: scripts/Makefile
===================================================================
RCS file: /cvs/linux/scripts/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- scripts/Makefile	5 Jun 2003 10:06:44 -0000	1.20
+++ scripts/Makefile	15 Jul 2003 19:28:29 -0000
@@ -7,6 +7,7 @@
 #                include/config/...
 # docproc: 	 Preprocess .tmpl file in order to generate .sgml docs
 # conmakehash:	 Create arrays for initializing the kernel console tables
+ifdef include_config
 
 host-progs	:= fixdep split-include conmakehash docproc kallsyms modpost \
 		   mk_elfconfig pnmtologo
@@ -33,3 +34,5 @@
 	$(call if_changed,elfconfig)
 
 targets += elfconfig.h
+
+endif

From brm@murphy.dk Tue Jul 15 20:42:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jul 2003 20:42:48 +0100 (BST)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([IPv6:::ffff:212.242.58.113]:26155
	"EHLO brian.localnet") by linux-mips.org with ESMTP
	id <S8224802AbTGOTmq>; Tue, 15 Jul 2003 20:42:46 +0100
Received: from brm by brian.localnet with local (Exim 3.36 #1 (Debian))
	id 19cVhA-0003M6-00
	for <linux-mips@linux-mips.org>; Tue, 15 Jul 2003 21:42:40 +0200
To: linux-mips@linux-mips.org
Subject: [PATCH 2.5] kbuild error for mips (and possibly others)
Message-Id: <E19cVhA-0003M6-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Tue, 15 Jul 2003 21:42:40 +0200
Return-Path: <brm@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2788
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi,
	there is a very annoying error in the 2.5 kbuild process
where the generation of the elfconfig.h file depends on the proper
configuration of the kernel being available (for mips at least) 
but configuring the kernel disallows the inclusion of the .config file
and thus the configuration and specifically CROSS_COMPILE is not set. 
This causes empty.o to fail to build because CC is now gcc and not 
mips(el)-linux-gcc and the -G option to gcc is invalid for my cross
compiler.

This patch fixes the problem. It also makes the *config targets 
not dependant on having the helper programs in scripts/ compiled
which they shouldn't be. They are not necessary.

/Brian

Index: scripts/Makefile
===================================================================
RCS file: /cvs/linux/scripts/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- scripts/Makefile	5 Jun 2003 10:06:44 -0000	1.20
+++ scripts/Makefile	15 Jul 2003 19:28:29 -0000
@@ -7,6 +7,7 @@
 #                include/config/...
 # docproc: 	 Preprocess .tmpl file in order to generate .sgml docs
 # conmakehash:	 Create arrays for initializing the kernel console tables
+ifdef include_config
 
 host-progs	:= fixdep split-include conmakehash docproc kallsyms modpost \
 		   mk_elfconfig pnmtologo
@@ -33,3 +34,5 @@
 	$(call if_changed,elfconfig)
 
 targets += elfconfig.h
+
+endif

From sseeger@stellartec.com Tue Jul 15 23:40:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jul 2003 23:41:01 +0100 (BST)
Received: from mail.stellartec.com ([IPv6:::ffff:65.107.16.99]:35344 "EHLO
	nt_server.stellartec.com") by linux-mips.org with ESMTP
	id <S8224802AbTGOWk7>; Tue, 15 Jul 2003 23:40:59 +0100
Received: from WSSTEVELAPTOP ([192.168.1.62]) by nt_server.stellartec.com
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 568-43562U100L2S100) with SMTP id AAA469;
          Tue, 15 Jul 2003 15:40:34 -0700
Reply-To: <sseeger@stellartec.com>
From: sseeger@stellartec.com (Steven Seeger)
To: "'Brian Murphy'" <brm@murphy.dk>, <linux-mips@linux-mips.org>
Subject: cvs update 2_4 branch breaks userland
Date: Tue, 15 Jul 2003 15:40:23 -0700
Message-ID: <007c01c34b22$14b98660$4383a8c0@WSSTEVELAPTOP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <E19cVhA-0003M6-00@brian.localnet>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Return-Path: <sseeger@stellartec.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: 2789
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sseeger@stellartec.com
Precedence: bulk
X-list: linux-mips

My board runs userland apps that makes use of SIGUSR1. When I did a cvs
update today and recompiled the kernel, when I run my app it quits with
"User defined signal 1" and bails. The signal is delivered a pthread_kill
command. The app runs about 8 or 9 threads all blocking on various IO with
various priority levels. I boot the old kernel back up and it runs fine.

Board is running an NECVR4181
Toolchain is a uclibc something.19 (building 20 now) with gcc 3.3 and the
latest binutils

I have the 2.4.21 kernel and I did a cvs update on it today.

If anyone has any ideas I'd appreciate knowing.

Thanks!

Steve


From ddaney@avtrex.com Wed Jul 16 01:24:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 01:24:47 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:64791 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8224802AbTGPAYp>;
	Wed, 16 Jul 2003 01:24:45 +0100
Received: from avtrex.com ([192.168.0.111]) by avtrex.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 15 Jul 2003 17:24:41 -0700
Message-ID: <3F149B49.9010303@avtrex.com>
Date: Tue, 15 Jul 2003 17:24:41 -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: Help wanted WRT multigot...
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jul 2003 00:24:41.0655 (UTC) FILETIME=[A644DC70:01C34B30]
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: 2790
X-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

We are using gcj/gcc-3.3 to run java programs on a mipsel-linux 
platform, and were able to work around GOT overflow error by hacking the 
  build to pass -xgot to gas.

After searching the web, it appeared that using binutils 2.14 or 
binutils-2.14.90.0.4 might enable multigot objects.  However it not 
clear to me if there is multigot support in these versions of binutils, 
or how to turn it on if there is.

Is there a multigot assembler/linker that can be used with gcc-3.3?

Or are we stuck with -xgot?

Thanks in advance,

David Daney


From ralf@linux-mips.org Wed Jul 16 02:17:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 02:17:39 +0100 (BST)
Received: from p508B5D71.dip.t-dialin.net ([IPv6:::ffff:80.139.93.113]:5063
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225233AbTGPBRh>; Wed, 16 Jul 2003 02:17: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 h6G1HZDB009486
	for <linux-mips@linux-mips.org>; Wed, 16 Jul 2003 03:17:35 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6G1HZFF009485
	for linux-mips@linux-mips.org; Wed, 16 Jul 2003 03:17:35 +0200
Date: Wed, 16 Jul 2003 03:17:35 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030716011734.GA9275@linux-mips.org>
References: <20030716010829Z8224802-1272+3435@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030716010829Z8224802-1272+3435@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: 2791
X-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

You forgot to patch mips64 / 2.6 also.  *grrr*

  Ralf

On Wed, Jul 16, 2003 at 02:08:24AM +0100, sjhill@linux-mips.org wrote:
> From:	sjhill@linux-mips.org
> To:	linux-cvs@linux-mips.org
> Subject: CVS Update@-mips.org: linux 
> Date:	Wed, 16 Jul 2003 02:08:24 +0100
> 
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	sjhill@ftp.linux-mips.org	03/07/16 02:08:24
> 
> Modified files:
> 	arch/mips/kernel: Tag: linux_2_4 setup.c time.c 
> 	arch/mips/mm   : Tag: linux_2_4 tlb-r4k.c 
> 	arch/mips/tx4927/common: Tag: linux_2_4 tx4927_irq.c 
> 	arch/mips/tx4927/toshiba_rbtx4927: Tag: linux_2_4 
> 	                                   toshiba_rbtx4927_irq.c 
> 	                                   toshiba_rbtx4927_prom.c 
> 	                                   toshiba_rbtx4927_setup.c 
> 	include/asm-mips: Tag: linux_2_4 au1000.h pci.h 
> 
> Log message:
> 	A bunch of small clean ups to remove compile warning messages.
> 

  Ralf

From drow@crack.them.org Wed Jul 16 02:43:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 02:43:59 +0100 (BST)
Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([IPv6:::ffff:66.93.172.17]:24203
	"EHLO nevyn.them.org") by linux-mips.org with ESMTP
	id <S8224802AbTGPBn5>; Wed, 16 Jul 2003 02:43:57 +0100
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 19cbKX-0003Ey-00; Tue, 15 Jul 2003 21:43:41 -0400
Date: Tue, 15 Jul 2003 21:43:41 -0400
From: Daniel Jacobowitz <dan@debian.org>
To: David Daney <ddaney@avtrex.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Help wanted WRT multigot...
Message-ID: <20030716014340.GA12436@nevyn.them.org>
References: <3F149B49.9010303@avtrex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F149B49.9010303@avtrex.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: 2792
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Tue, Jul 15, 2003 at 05:24:41PM -0700, David Daney wrote:
> We are using gcj/gcc-3.3 to run java programs on a mipsel-linux 
> platform, and were able to work around GOT overflow error by hacking the 
>  build to pass -xgot to gas.
> 
> After searching the web, it appeared that using binutils 2.14 or 
> binutils-2.14.90.0.4 might enable multigot objects.  However it not 
> clear to me if there is multigot support in these versions of binutils, 
> or how to turn it on if there is.
> 
> Is there a multigot assembler/linker that can be used with gcc-3.3?
> 
> Or are we stuck with -xgot?

If you just try using 2.14, it should work.  No extra flags, no
anything special.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ilya@gateway.total-knowledge.com Wed Jul 16 06:55:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 06:55:19 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:25228
	"HELO alpha.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225072AbTGPFzQ>; Wed, 16 Jul 2003 06:55:16 +0100
Received: (qmail 10876 invoked from network); 16 Jul 2003 05:55:08 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 16 Jul 2003 05:55:08 -0000
Received: (qmail 24344 invoked by uid 502); 16 Jul 2003 05:55:08 -0000
Date: Tue, 15 Jul 2003 22:55:08 -0700
From: ilya@theIlya.com
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: latest meth driver update
Message-ID: <20030716055508.GA24113@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2793
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips

Here is my latest experiments with meth. Quite a few changes have been made.
 - use spin_lock_irq variants instead of spin_lock - thus locking
   is actually doing something now
 - main interrupt routine was rewritten to loop untill evertything that
   can possibly can be handled, is in fact handled. This eliminates
   overhead of taking extra interrupts.
 - Changed Rx handler to preallocate sk_buff's, and DMA data to them
   directly. This has two advantages: No data copying, and no use of
   "coherent" - uncached memory areas.
 - Some other minor cleanups.

The end result is definite improvement - lot fewer Rx ring underruns, higher
speed. However, I still see strange things, which may ore may not be related
to meth. Biggest one is hang during startup: approximately one out of four
times kernel successfully gets IP configuration from DHCP server, mounts NFS
root, and then hangs happily for indefinite period of time trying to start
init. It is not completely dead - if I type something, I see it echoed back
to me on console. Also, if O2 is flooded with bad network packets, I see
messages from meth complaining about them, yet, init never starts.

Anyways, here is the patch, and if you see anything obviously (or not
obviously) stupid, please let me know.

	Ilya
Index: drivers/net/meth.c
===================================================================
RCS file: /home/cvs/linux/drivers/net/meth.c,v
retrieving revision 1.8
diff -u -r1.8 meth.c
--- drivers/net/meth.c	6 Jul 2003 14:16:24 -0000	1.8
+++ drivers/net/meth.c	16 Jul 2003 05:26:29 -0000
@@ -1,7 +1,7 @@
 /*
  * meth.c -- O2 Builtin 10/100 Ethernet driver
  *
- * Copyright (C) 2001 Ilya Volynets
+ * Copyright (C) 2001-2003 Ilya Volynets
  *
  *	This program is free software; you can redistribute it and/or
  *	modify it under the terms of the GNU General Public License
@@ -47,7 +47,7 @@
 #endif
 
 #if MFE_DEBUG>=1
-#define DPRINTK(str,args...) printk (KERN_DEBUG "meth(%ld): %s: " str, jiffies, __FUNCTION__ , ## args)
+#define DPRINTK(str,args...) printk (KERN_DEBUG "meth: %s: " str, __FUNCTION__ , ## args)
 #define MFE_RX_DEBUG 2
 #else
 #define DPRINTK(str,args...)
@@ -77,6 +77,7 @@
 	struct net_device_stats stats;
 	volatile struct meth_regs *regs;
 	u64 mode; /* in-memory copy of MAC control register */
+	u64 dma_ctrl; /* dma control */
 	int  phy_addr; /* address of phy, used by mdio_* functions, initialized in mdio_probe*/
 	tx_packet *tx_ring;
 	dma_addr_t tx_ring_dma;
@@ -88,6 +89,7 @@
 
 	rx_packet *rx_ring[RX_RING_ENTRIES];
 	dma_addr_t rx_ring_dmas[RX_RING_ENTRIES];
+	struct sk_buff *rx_skbs[RX_RING_ENTRIES];
 	int rx_write;
 
 	spinlock_t meth_lock;
@@ -111,7 +113,7 @@
 	regs->mac_addr=(*(u64*)o2meth_eaddr)>>16;
 }
 
-/*
+ /*
  *Waits for BUSY status of mdio bus to clear
  */
 #define WAIT_FOR_PHY(___regs, ___rval)			\
@@ -135,16 +137,16 @@
 static int mdio_probe(meth_private *priv)
 {
 	int i, p2, p3;
-	DPRINTK("Detecting PHY kind\n");
+	unsigned long flags;
 	/* check if phy is detected already */
 	if(priv->phy_addr>=0&&priv->phy_addr<32)
 		return 0;
-	spin_lock(&priv->meth_lock);
+	spin_lock_irqsave(&priv->meth_lock,flags);
 	for (i=0;i<32;++i){
 		priv->phy_addr=(char)i;
 		p2=mdio_read(priv,2);
-#ifdef MFE_DEBUG
 		p3=mdio_read(priv,3);
+#if MFE_DEBUG>=2
 		switch ((p2<<12)|(p3>>4)){
 		case PHY_QS6612X:
 			DPRINTK("PHY is QS6612X\n");
@@ -165,7 +167,7 @@
 			break;
 		}
 	}
-	spin_unlock(&priv->meth_lock);
+	spin_unlock_irqrestore(&priv->meth_lock,flags);
 	if(priv->phy_addr<32) {
 		return 0;
 	}
@@ -213,7 +215,6 @@
 static int meth_init_tx_ring(meth_private *priv)
 {
 	/* Init TX ring */
-	DPRINTK("Initializing TX ring\n");
 	priv->tx_ring = dma_alloc_coherent(NULL, TX_RING_BUFFER_SIZE,
 	                                   &priv->tx_ring_dma, GFP_ATOMIC);
 	if (!priv->tx_ring)
@@ -225,7 +226,6 @@
 	/* Now init skb save area */
 	memset(priv->tx_skbs,0,sizeof(priv->tx_skbs));
 	memset(priv->tx_skb_dmas,0,sizeof(priv->tx_skb_dmas));
-	DPRINTK("Done with TX ring init\n");
 	return 0;
 }
 
@@ -233,13 +233,17 @@
 {
 	int i;
 	for(i=0;i<RX_RING_ENTRIES;i++){
-		priv->rx_ring[i] = dma_alloc_coherent(NULL, METH_RX_BUFF_SIZE,
-		                                      &priv->rx_ring_dmas[i],0);
+		priv->rx_skbs[i]=alloc_skb(METH_RX_BUFF_SIZE,0);
+		/* 8byte status vector+3quad padding + 2byte padding,
+		   to put data on 64bit aligned boundary */
+		skb_reserve(priv->rx_skbs[i],METH_RX_HEAD);
+		priv->rx_ring[i]=(rx_packet*)(priv->rx_skbs[i]->head);
 		/* I'll need to re-sync it after each RX */
+		priv->rx_ring_dmas[i]=dma_map_single(NULL,priv->rx_ring[i],
+						     METH_RX_BUFF_SIZE,DMA_FROM_DEVICE);
 		priv->regs->rx_fifo=priv->rx_ring_dmas[i];
 	}
-	priv->rx_write = 0;
-	DPRINTK("Done with RX ring\n");
+        priv->rx_write = 0;
 	return 0;
 }
 static void meth_free_tx_ring(meth_private *priv)
@@ -255,13 +259,18 @@
 	dma_free_coherent(NULL, TX_RING_BUFFER_SIZE, priv->tx_ring,
 	                  priv->tx_ring_dma);
 }
+
+/* Presumes RX DMA engine is stopped, and RX fifo ring is reset */
 static void meth_free_rx_ring(meth_private *priv)
 {
 	int i;
 
-	for(i=0;i<RX_RING_ENTRIES;i++)
-		dma_free_coherent(NULL, METH_RX_BUFF_SIZE, priv->rx_ring[i],
-		                  priv->rx_ring_dmas[i]);
+	for(i=0;i<RX_RING_ENTRIES;i++) {
+		dma_unmap_single(NULL,priv->rx_ring_dmas[i],METH_RX_BUFF_SIZE,DMA_FROM_DEVICE);
+		priv->rx_ring[i]=0;
+		priv->rx_ring_dmas[i]=0;
+		kfree_skb(priv->rx_skbs[i]);
+	}
 }
 
 int meth_reset(struct net_device *dev)
@@ -289,12 +298,13 @@
 		priv->mode |= METH_PROMISC;
 	priv->regs->mac_ctrl = priv->mode;
 
-	/* Autonegociate speed and duplex mode */
+	/* Autonegotiate speed and duplex mode */
 	meth_check_link(dev);
 
 	/* Now set dma control, but don't enable DMA, yet */
-	priv->regs->dma_ctrl= (4 << METH_RX_OFFSET_SHIFT) |
+	priv->dma_ctrl= (4 << METH_RX_OFFSET_SHIFT) |
 		(RX_RING_ENTRIES << METH_RX_DEPTH_SHIFT);
+	priv->regs->dma_ctrl=priv->dma_ctrl;
 
 	return(0);
 }
@@ -322,30 +332,32 @@
 		return ret;
 	}
 
-	DPRINTK("Will set dma_ctl now\n");
-	/* Start DMA */
-	regs->dma_ctrl|=
-	        METH_DMA_TX_EN|/*METH_DMA_TX_INT_EN|*/
-		METH_DMA_RX_EN|METH_DMA_RX_INT_EN;
-
 	if(request_irq(dev->irq,meth_interrupt,SA_SHIRQ,meth_str,dev)){
 		printk(KERN_ERR "%s: Can't get irq %d\n", dev->name, dev->irq);
 		return -EAGAIN;
 	}
+
+	/* Start DMA */
+	priv->dma_ctrl|=
+	        METH_DMA_TX_EN|/*METH_DMA_TX_INT_EN|*/
+		METH_DMA_RX_EN|METH_DMA_RX_INT_EN;
+	regs->dma_ctrl=priv->dma_ctrl;
+
 	DPRINTK("About to start queue\n");
 	netif_start_queue(dev);
-	DPRINTK("Opened... DMA control=0x%08lx\n", regs->dma_ctrl);
 	return 0;
 }
 
 int meth_release(struct net_device *dev)
 {
 	meth_private *priv=dev->priv;
+	DPRINTK("Stopping queue\n");
 	netif_stop_queue(dev); /* can't transmit any more */
 	/* shut down dma */
-	((meth_private*)(dev->priv))->regs->dma_ctrl&=
+	priv->dma_ctrl&=
 		~(METH_DMA_TX_EN|METH_DMA_TX_INT_EN|
 		  METH_DMA_RX_EN|METH_DMA_RX_INT_EN);
+	priv->regs->dma_ctrl=priv->dma_ctrl;
 	free_irq(dev->irq, dev);
 	meth_free_tx_ring(priv);
 	meth_free_rx_ring(priv);
@@ -380,42 +392,67 @@
 /*
  * Receive a packet: retrieve, encapsulate and pass over to upper levels
  */
-void meth_rx(struct net_device* dev)
+void meth_rx(struct net_device* dev,u64 int_status)
 {
 	struct sk_buff *skb;
 	struct meth_private *priv = (struct meth_private *) dev->priv;
-	rx_packet *rxb;
-	int twptr=priv->rx_write;
-	u64 status;
-	spin_lock(&(priv->meth_lock));
-	while ((status=(rxb=priv->rx_ring[priv->rx_write])->status.raw)&0x8000000000000000)
-	{
-		int len=(status&0xFFFF) - 4; /* omit CRC */
-		/* length sanity check */
-		if(len < 60 || len > 1518) {
-			printk(KERN_DEBUG "%s: bogus packet size: %d, status=%#2lx.\n",
-			       dev->name, priv->rx_write, rxb->status.raw);
-			priv->stats.rx_errors++;
-			priv->stats.rx_length_errors++;
+	unsigned int fifo_rptr=(int_status&METH_INT_RX_RPTR_MASK)>>8;
+	unsigned int flags;
+	spin_lock_irqsave(&priv->meth_lock,flags);
+	priv->dma_ctrl&=~METH_DMA_RX_INT_EN;
+	priv->regs->dma_ctrl=priv->dma_ctrl;
+	spin_unlock_irqrestore(&priv->meth_lock,flags);
+
+	if (int_status & METH_INT_RX_UNDERFLOW){
+		fifo_rptr=(fifo_rptr-1)&(0xF);
+	}
+	while(priv->rx_write != fifo_rptr) {
+		u64 status;
+		dma_unmap_single(NULL,priv->rx_ring_dmas[priv->rx_write],
+				 METH_RX_BUFF_SIZE,DMA_FROM_DEVICE);
+		status=priv->rx_ring[priv->rx_write]->status.raw;
+#if MFE_DEBUG
+		if(!(status&METH_RX_ST_VALID)) {
+			DPRINTK("Not received? status=%016lx\n",status);
 		}
-		if(!(status&METH_RX_STATUS_ERRORS)){
-			skb=alloc_skb(len+2,GFP_ATOMIC);/* Should be atomic -- we are in interrupt */
-			if(!skb){
-				/* Ouch! No memory! Drop packet on the floor */
-				priv->stats.rx_dropped++;
+#endif
+		if((!(status&METH_RX_STATUS_ERRORS))&&(status&METH_RX_ST_VALID)){
+			int len=(status&0xFFFF) - 4; /* omit CRC */
+			/* length sanity check */
+			if(len < 60 || len > 1518) {
+				printk(KERN_DEBUG "%s: bogus packet size: %d, status=%#2lx.\n",
+				       dev->name, priv->rx_write,
+				       priv->rx_ring[priv->rx_write]->status.raw);
+				priv->stats.rx_errors++;
+				priv->stats.rx_length_errors++;
+				skb=priv->rx_skbs[priv->rx_write];
 			} else {
-				skb_reserve(skb, 2); /* align IP on 16B boundary */  
-				memcpy(skb_put(skb, len), rxb->buf, len);
-				/* Write metadata, and then pass to the receive level */
-				skb->dev = dev;
-				skb->protocol = eth_type_trans(skb, dev);
-				
-				dev->last_rx = jiffies;
-				priv->stats.rx_packets++;
-				priv->stats.rx_bytes+=len;
-				netif_rx(skb);
+				skb=alloc_skb(METH_RX_BUFF_SIZE,GFP_ATOMIC|GFP_DMA);
+				if(!skb){
+					/* Ouch! No memory! Drop packet on the floor */
+					DPRINTK("No mem: dropping packet\n");
+					priv->stats.rx_dropped++;
+					skb=priv->rx_skbs[priv->rx_write];
+				} else {
+					struct sk_buff *skb_c=priv->rx_skbs[priv->rx_write];
+					/* 8byte status vector+3quad padding + 2byte padding,
+					   to put data on 64bit aligned boundary */
+					skb_reserve(skb,METH_RX_HEAD);
+					/* Write metadata, and then pass to the receive level */
+					skb_put(skb_c,len);
+					priv->rx_skbs[priv->rx_write]=skb;
+					skb_c->dev = dev;
+					skb_c->protocol = eth_type_trans(skb_c, dev);
+					dev->last_rx = jiffies;
+					priv->stats.rx_packets++;
+					priv->stats.rx_bytes+=len;
+					netif_rx(skb_c);
+				}
 			}
 		} else {
+			priv->stats.rx_errors++;
+			skb=priv->rx_skbs[priv->rx_write];
+#if MFE_DEBUG>0
 			printk(KERN_WARNING "meth: RX error: status=0x%016lx\n",status);
 			if(status&METH_RX_ST_RCV_CODE_VIOLATION)
 				printk(KERN_WARNING "Receive Code Violation\n");
@@ -429,15 +466,21 @@
 				printk(KERN_WARNING "Bad Packet\n");
 			if(status&METH_RX_ST_CARRIER_EVT_SEEN)
 				printk(KERN_WARNING "Carrier Event Seen\n");
+#endif
 		}
-		rxb->status.raw=0;
+		priv->rx_ring[priv->rx_write]=(rx_packet*)skb->head;
+		priv->rx_ring[priv->rx_write]->status.raw=0;
+		priv->rx_ring_dmas[priv->rx_write]=dma_map_single(NULL,priv->rx_ring[priv->rx_write],
+								  METH_RX_BUFF_SIZE,DMA_FROM_DEVICE);
 		priv->regs->rx_fifo=priv->rx_ring_dmas[priv->rx_write];
-		priv->rx_write=(priv->rx_write+1)&(RX_RING_ENTRIES-1);
-		if(priv->rx_write==twptr) {
-			DPRINTK("going rounds\n");
-		}
+		ADVANCE_RX_PTR(priv->rx_write);
 	}
-	spin_unlock(&(priv->meth_lock));
+	spin_lock_irqsave(&priv->meth_lock,flags);
+	/* In case there was underflow, and Rx DMA was disabled */
+	priv->dma_ctrl|=METH_DMA_RX_INT_EN|METH_DMA_RX_EN;
+	priv->regs->dma_ctrl=priv->dma_ctrl;
+	priv->regs->int_flags=METH_INT_RX_THRESHOLD;
+	spin_unlock_irqrestore(&priv->meth_lock,flags);
 }
 
 static int meth_tx_full(struct net_device *dev)
@@ -447,16 +490,19 @@
 	return(priv->tx_count >= TX_RING_ENTRIES-1);
 }
 
-void meth_tx_cleanup(struct net_device* dev, int rptr)
+void meth_tx_cleanup(struct net_device* dev, int int_status)
 {
 	meth_private *priv=dev->priv;
 	tx_packet* status;
 	struct sk_buff *skb;
+	unsigned long flags;
+	int rptr=(int_status&TX_INFO_RPTR)>>16;
 
-	spin_lock(&priv->meth_lock);
+	spin_lock_irqsave(&priv->meth_lock,flags);
 
-	/* Stop DMA */
-	priv->regs->dma_ctrl &= ~(METH_DMA_TX_INT_EN);
+	/* Stop DMA notification */
+	priv->dma_ctrl &= ~(METH_DMA_TX_INT_EN);
+	priv->regs->dma_ctrl=priv->dma_ctrl;
 
 	while(priv->tx_read != rptr){
 		skb = priv->tx_skbs[priv->tx_read];
@@ -479,7 +525,41 @@
 		netif_wake_queue(dev);
 	}
 
-	spin_unlock(priv->meth_lock);
+	priv->regs->int_flags=METH_INT_TX_EMPTY|METH_INT_TX_PKT;
+	spin_unlock_irqrestore(&priv->meth_lock,flags);
+}
+
+static void meth_error(struct net_device* dev, u32 status)
+{
+	struct meth_private *priv;
+	priv = (struct meth_private *) dev->priv;
+
+	printk(KERN_WARNING "meth: error status: 0x%08x\n",status);
+	/* check for errors too... */
+	if (status & (METH_INT_TX_LINK_FAIL))
+		printk(KERN_WARNING "meth: link failure\n");
+	/* Should I do full reset in this case? */
+	if (status & (METH_INT_MEM_ERROR))
+		printk(KERN_WARNING "meth: memory error\n");
+	if (status & (METH_INT_TX_ABORT))
+		printk(KERN_WARNING "meth: aborted\n");
+	if (status & (METH_INT_RX_OVERFLOW))
+		printk(KERN_WARNING "meth: Rx overflow\n");
+	if (status & (METH_INT_RX_UNDERFLOW)) {
+		unsigned long flags;
+		printk(KERN_WARNING "meth: Rx underflow\n");
+		spin_lock_irqsave(&priv->meth_lock,flags);
+		priv->regs->int_flags=METH_INT_RX_UNDERFLOW;
+		/* more underflow interrupts will be delivered, 
+		   effectively throwing us into an infinite loop.
+		   Thus I stop processing Rx in this case.
+		*/
+		priv->dma_ctrl&=~METH_DMA_RX_EN;
+		priv->regs->dma_ctrl=priv->dma_ctrl;
+		DPRINTK("Disabled meth Rx DMA temporarily\n");
+		spin_unlock_irqrestore(&priv->meth_lock,flags);
+	}
+	priv->regs->int_flags=METH_INT_ERROR;
 }
 
 /*
@@ -489,50 +569,37 @@
 {
 	struct meth_private *priv;
 	u32 status;
+
 	/*
 	 * As usual, check the "device" pointer for shared handlers.
 	 * Then assign "struct device *dev"
 	 */
 	struct net_device *dev = (struct net_device *)dev_id;
-	/* ... and check with hw if it's really ours */
-
-	if (!dev /*paranoid*/ ) return IRQ_HANDLED;
 
 	priv = (struct meth_private *) dev->priv;
 
 	status = priv->regs->int_flags;
-    
-	if (status & (METH_INT_RX_THRESHOLD|METH_INT_RX_UNDERFLOW)) {
-		/* send it to meth_rx for handling */
-		meth_rx(dev);
+	while (status&0xFF) {
+		/* First handle errors - if we get Rx underflow,
+		   Rx DMA will be disabled, and Rx handler will reenable
+		   it. I don't think it's possible to get Rx underflow,
+		   without getting Rx interrupt */
+		if( status & METH_INT_ERROR) {
+			meth_error(dev,status);
+		}
+		if (status & (METH_INT_TX_EMPTY|METH_INT_TX_PKT)) {
+			/* a transmission is over: free the skb */
+			meth_tx_cleanup(dev, status);
+		}
+		if (status & METH_INT_RX_THRESHOLD) {
+			if(!(priv->dma_ctrl&METH_DMA_RX_INT_EN))
+				break;
+			/* send it to meth_rx for handling */
+			meth_rx(dev,status);
+		}
+ 		status = priv->regs->int_flags;
 	}
 
-	if (status & (METH_INT_TX_EMPTY|METH_INT_TX_PKT)) {
-		/* a transmission is over: free the skb */
-		meth_tx_cleanup(dev, (priv->regs->tx_info&TX_INFO_RPTR)>>16);
-	}
-	/* check for errors too... */
-	if (status & (METH_INT_TX_LINK_FAIL))
-		printk(KERN_WARNING "meth: link failure\n");
-	if (status & (METH_INT_MEM_ERROR))
-		printk(KERN_WARNING "meth: memory error\n");
-	if (status & (METH_INT_TX_ABORT))
-		printk(KERN_WARNING "meth: aborted\n");
-	if (status & (METH_INT_RX_OVERFLOW))
-		printk(KERN_WARNING "meth: RX overflow\n");
-	if (status & (METH_INT_RX_UNDERFLOW))
-		printk(KERN_WARNING "meth: RX underflow\n");
-
-#define METH_INT_ERROR	(METH_INT_TX_LINK_FAIL| \
-			METH_INT_MEM_ERROR| \
-			METH_INT_TX_ABORT| \
-			METH_INT_RX_OVERFLOW| \
-			METH_INT_RX_UNDERFLOW)
-	if( status & METH_INT_ERROR) {
-		printk(KERN_WARNING "meth: error status: 0x%08x\n",status);
-		netif_wake_queue(dev);
-	}
-	priv->regs->int_flags=status&0xff; /* clear interrupts */
 	return IRQ_HANDLED;
 }
 
@@ -624,8 +691,6 @@
 	priv->tx_write = (priv->tx_write+1) & (TX_RING_ENTRIES-1);
 	priv->regs->tx_info = priv->tx_write;
 	priv->tx_count ++;
-	/* Enable DMA transfer */
-	priv->regs->dma_ctrl |= METH_DMA_TX_INT_EN;
 }
 
 /*
@@ -634,19 +699,28 @@
 int meth_tx(struct sk_buff *skb, struct net_device *dev)
 {
 	struct meth_private *priv = (struct meth_private *) dev->priv;
+	unsigned long flags;
+
+	spin_lock_irqsave(&priv->meth_lock,flags);
+	/* Stop DMA notification */
+	priv->dma_ctrl &= ~(METH_DMA_TX_INT_EN);
+	priv->regs->dma_ctrl=priv->dma_ctrl;
 
-	spin_lock(&priv->meth_lock);
 
 	meth_add_to_tx_ring(priv, skb);
 	dev->trans_start = jiffies; /* save the timestamp */
 
 	/* If TX ring is full, tell the upper layer to stop sending packets */
 	if (meth_tx_full(dev)) {
-	        printk("TX full: stopping\n");
+	        printk(KERN_DEBUG "TX full: stopping\n");
 		netif_stop_queue(dev);
 	}
 
-	spin_unlock(&priv->meth_lock);
+	/* Restart DMA notification */
+	priv->dma_ctrl |= METH_DMA_TX_INT_EN;
+	  priv->regs->dma_ctrl=priv->dma_ctrl;
+
+	spin_unlock_irqrestore(&priv->meth_lock,flags);
 
 	return 0;
 }
@@ -658,11 +732,12 @@
 void meth_tx_timeout (struct net_device *dev)
 {
 	struct meth_private *priv = (struct meth_private *) dev->priv;
-	
+	unsigned long flags;
+
 	printk(KERN_WARNING "%s: transmit timed out\n", dev->name);
 
 	/* Protect against concurrent rx interrupts */
-	spin_lock(&priv->meth_lock);
+	spin_lock_irqsave(&priv->meth_lock,flags);
 
 	/* Try to reset the interface. */
 	meth_reset(dev);
@@ -676,10 +751,11 @@
 	meth_init_rx_ring(priv);
 
 	/* Restart dma */
-	priv->regs->dma_ctrl|=METH_DMA_TX_EN|METH_DMA_RX_EN|METH_DMA_RX_INT_EN;
+	priv->dma_ctrl|=METH_DMA_TX_EN|METH_DMA_RX_EN|METH_DMA_RX_INT_EN;
+	priv->regs->dma_ctrl=priv->dma_ctrl;
 
 	/* Enable interrupt */
-	spin_unlock(&priv->meth_lock);
+	spin_unlock_irqrestore(&priv->meth_lock,flags);
 
 	dev->trans_start = jiffies;
 	netif_wake_queue(dev);
Index: drivers/net/meth.h
===================================================================
RCS file: /home/cvs/linux/drivers/net/meth.h,v
retrieving revision 1.3
diff -u -r1.3 meth.h
--- drivers/net/meth.h	30 Jun 2003 04:09:29 -0000	1.3
+++ drivers/net/meth.h	16 Jul 2003 05:26:30 -0000
@@ -27,6 +27,7 @@
 #define TX_RING_BUFFER_SIZE	(TX_RING_ENTRIES*sizeof(tx_packet))
 #define RX_BUFFER_SIZE 1546 /* ethenet packet size */
 #define METH_RX_BUFF_SIZE 4096
+#define METH_RX_HEAD 34 /* status + 3 quad garbage-fill + 2 byte zero-pad */
 #define RX_BUFFER_OFFSET (sizeof(rx_status_vector)+2) /* staus vector + 2 bytes of padding */
 #define RX_BUCKET_SIZE 256
 
@@ -124,13 +125,7 @@
 	u64		int_rx;			/*0x28,wo,9:4*/
 	u64             tx_info;		/*0x30,rw,31:0*/
 	u64		tx_info_al;		/*0x38,rw,31:0*/
-	struct {
-		u32	rx_buff_pad1;
-		u32	rx_buff_pad2:8,
-			wptr:8,
-			rptr:8,
-			depth:8;
-	}		rx_buff;		/*0x40,ro,23:0*/
+	u64             rx_buff;		/*0x40,ro,23:0*/
 	u64		rx_buff_al1;	/*0x48,ro,23:0*/
 	u64		rx_buff_al2;	/*0x50,ro,23:0*/
 	u64		int_update;		/*0x58,wo,31:0*/
@@ -202,9 +197,14 @@
 #define METH_DMA_RX_EN BIT(15) /* Enable RX */
 #define METH_DMA_RX_INT_EN BIT(9) /* Enable interrupt on RX packet */
 
+/* RX FIFO MCL Info bits */
+#define METH_RX_FIFO_WPTR(x)   ((x>>16)&0xF)
+#define METH_RX_FIFO_RPTR(x)   ((x>>8)&0xF)
+#define METH_RX_FIFO_DEPTH(x)  (x&0x1F)
 
 /* RX status bits */
 
+#define METH_RX_ST_VALID BIT(63)
 #define METH_RX_ST_RCV_CODE_VIOLATION BIT(16)
 #define METH_RX_ST_DRBL_NBL BIT(17)
 #define METH_RX_ST_CRC_ERR BIT(18)
@@ -239,7 +239,8 @@
 #define METH_INT_RX_UNDERFLOW	BIT(6)	/* 0: No interrupt pending, 1: FIFO was empty, packet could not be queued */
 #define METH_INT_RX_OVERFLOW		BIT(7)	/* 0: No interrupt pending, 1: DMA FIFO Overflow, DMA stopped, FATAL */
 
-#define METH_INT_RX_RPTR_MASK 0x0001F00		/* Bits 8 through 12 alias of RX read-pointer */
+/*#define METH_INT_RX_RPTR_MASK 0x0001F00*/		/* Bits 8 through 12 alias of RX read-pointer */
+#define METH_INT_RX_RPTR_MASK 0x0000F00		/* Bits 8 through 11 alias of RX read-pointer - so, is Rx FIFO 16 or 32 entry?*/
 
 						/* Bits 13 through 15 are always 0. */
 
@@ -248,11 +249,11 @@
 #define METH_INT_SEQ_MASK    0x2E000000	        /* Bits 25 through 29 are the starting seq number for the message at the */
 						/* top of the queue */
 
-#define METH_ERRORS ( \
-	METH_INT_RX_OVERFLOW|	\
-	METH_INT_RX_UNDERFLOW|	\
-	METH_INT_MEM_ERROR|			\
-	METH_INT_TX_ABORT)
+#define METH_INT_ERROR	(METH_INT_TX_LINK_FAIL| \
+			METH_INT_MEM_ERROR| \
+			METH_INT_TX_ABORT| \
+			METH_INT_RX_OVERFLOW| \
+			METH_INT_RX_UNDERFLOW)
 
 #define METH_INT_MCAST_HASH		BIT(30) /* If RX DMA is enabled the hash select logic output is latched here */
 
@@ -270,3 +271,5 @@
 #define PHY_ICS1889    0x0015F41    /* ICS FX */
 #define PHY_ICS1890    0x0015F42    /* ICS TX */
 #define PHY_DP83840    0x20005C0    /* National TX */
+
+#define ADVANCE_RX_PTR(x)  x=(x+1)&(RX_RING_ENTRIES-1)


From liam.girdwood@wolfsonmicro.com Wed Jul 16 10:38:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 10:38:29 +0100 (BST)
Received: from [IPv6:::ffff:194.217.161.2] ([IPv6:::ffff:194.217.161.2]:48280
	"EHLO wolfsonmicro.com") by linux-mips.org with ESMTP
	id <S8225072AbTGPJiX>; Wed, 16 Jul 2003 10:38:23 +0100
Received: from campbeltown.wolfson.co.uk (campbeltown [192.168.0.166])
	by wolfsonmicro.com (8.11.3/8.11.3) with ESMTP id h6G9c9e23423
	for <linux-mips@linux-mips.org>; Wed, 16 Jul 2003 10:38:10 +0100 (BST)
Received: from caernarfon (unverified) by campbeltown.wolfson.co.uk
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T63771a1cfbc0a800a6414@campbeltown.wolfson.co.uk> for <linux-mips@linux-mips.org>;
 Wed, 16 Jul 2003 10:39:22 +0100
Subject: [PATCH] [2.6.0-test1] Alchemy Pb1500 - Power management
From: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
To: linux-mips <linux-mips@linux-mips.org>
Content-Type: text/plain
Message-Id: <1058348289.10765.1527.camel@caernarfon>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3 
Date: 16 Jul 2003 10:38:09 +0100
Content-Transfer-Encoding: 7bit
Return-Path: <liam.girdwood@wolfsonmicro.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: 2794
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: liam.girdwood@wolfsonmicro.com
Precedence: bulk
X-list: linux-mips

Hi,

I'm working my way through building the latest CVS for my Pb1500 and
I've run into a couple of build problems.

This patch fixes some function naming problems and removes duplicate
symbol au1k_wait() (defined in kernel/cpu-probe.c) in the Pb1500 power
management code.

Index: arch/mips/au1000/common/power.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/common/power.c,v
retrieving revision 1.10
diff -r1.10 power.c
36a37
> #include <linux/jiffies.h>
54,55c55,56
< extern void set_au1000_speed(unsigned int new_freq);
< extern unsigned int get_au1000_speed(void);
---
> extern void set_au1x00_speed(unsigned int new_freq);
> extern unsigned int get_au1x00_speed(void);
190,191c191,192
< 		old_baud_base = get_au1000_uart_baud_base();
< 		old_cpu_freq = get_au1000_speed();
---
> 		old_baud_base = get_au1x00_uart_baud_base();
> 		old_cpu_freq = get_au1x00_speed();
195,196c196,197
< 		set_au1000_speed(new_cpu_freq);
< 		set_au1000_uart_baud_base(new_baud_base);
---
> 		set_au1x00_speed(new_cpu_freq);
> 		set_au1x00_uart_baud_base(new_baud_base);
325,329d325
< }
< 
< void au1k_wait(void)
< {
< 	__asm__("nop\n\t" "nop\n\t");


Liam

-- 
Liam Girdwood <liam.girdwood@wolfsonmicro.com>



Wolfson Microelectronics plc
http://www.wolfsonmicro.com
t: +44 131 272-7000
f: +44 131 272-7001
Registered in Scotland 89839

This message may contain confidential or proprietary information. If you receive this message in error, please
immediately delete it, destroy all copies of it and notify the sender. Any views expressed in this message are those of the individual sender,
except where the message states otherwise. We take reasonable precautions to ensure our Emails are virus free.
However, we cannot accept responsibility for any virus transmitted by us
and recommend that you subject any incoming Email to your own virus
checking procedures.


From anemo@mba.ocn.ne.jp Wed Jul 16 11:54:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 11:54:30 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:45579
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225072AbTGPKy2>; Wed, 16 Jul 2003 11:54:28 +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; 16 Jul 2003 10:54:26 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h6GAsGDV034908;
	Wed, 16 Jul 2003 19:54:17 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 16 Jul 2003 19:55:14 +0900 (JST)
Message-Id: <20030716.195514.71083728.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: cache code fix for c-tx39.c (Re: CVS Update@-mips.org: linux)
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030709124821Z8225210-1272+3285@linux-mips.org>
References: <20030709124821Z8225210-1272+3285@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: 2795
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Wed,  9 Jul 2003 13:48:16 +0100, ralf@linux-mips.org said:
> Changes by:	ralf@ftp.linux-mips.org	03/07/09 13:48:16
> 
> Modified files:
> 	arch/mips/mm   : Tag: linux_2_4 c-r4k.c 
> 	arch/mips64/mm : Tag: linux_2_4 c-r4k.c 
> 	include/asm-mips: Tag: linux_2_4 processor.h r4kcache.h 
> 	include/asm-mips64: Tag: linux_2_4 processor.h 
> 
> Log message:
> 	Cache code fixes.

Please fix c-tx39.c also.  This is a patch for 2.4 branch.

diff -ur linux-mips-cvs/arch/mips/mm/c-tx39.c linux.new/arch/mips/mm/c-tx39.c
--- linux-mips-cvs/arch/mips/mm/c-tx39.c	Tue May  6 09:40:58 2003
+++ linux.new/arch/mips/mm/c-tx39.c	Wed Jul 16 19:39:55 2003
@@ -25,9 +25,6 @@
 
 /* For R3000 cores with R4000 style caches */
 static unsigned long icache_size, dcache_size;		/* Size in bytes */
-static unsigned long icache_way_size, dcache_way_size;	/* Size divided by ways */
-#define scache_size 0
-#define scache_way_size 0
 
 #include <asm/r4kcache.h>
 
@@ -473,15 +470,15 @@
 		break;
 	}
 
-	icache_way_size = icache_size / current_cpu_data.icache.ways;
-	dcache_way_size = dcache_size / current_cpu_data.dcache.ways;
+	current_cpu_data.icache.waysize = icache_size / current_cpu_data.icache.ways;
+	current_cpu_data.dcache.waysize = dcache_size / current_cpu_data.dcache.ways;
 
 	current_cpu_data.icache.sets =
-		icache_way_size / current_cpu_data.icache.linesz;
+		current_cpu_data.icache.waysize / current_cpu_data.icache.linesz;
 	current_cpu_data.dcache.sets =
-		dcache_way_size / current_cpu_data.dcache.linesz;
+		current_cpu_data.dcache.waysize / current_cpu_data.dcache.linesz;
 
-	if (dcache_way_size > PAGE_SIZE)
+	if (current_cpu_data.dcache.waysize > PAGE_SIZE)
 		current_cpu_data.dcache.flags |= MIPS_CACHE_ALIASES;
 
 	current_cpu_data.icache.waybit = 0;
---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Wed Jul 16 11:57:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 11:57:27 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:42512
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225072AbTGPK5Z>; Wed, 16 Jul 2003 11:57: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; 16 Jul 2003 10:57: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 h6GAvGDV034916;
	Wed, 16 Jul 2003 19:57:16 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Wed, 16 Jul 2003 19:58:13 +0900 (JST)
Message-Id: <20030716.195813.104027327.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: cache code fix for c-tx39.c
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20030716.195514.71083728.nemoto@toshiba-tops.co.jp>
References: <20030709124821Z8225210-1272+3285@linux-mips.org>
	<20030716.195514.71083728.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: 2796
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Wed, 16 Jul 2003 19:55:14 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
>> Log message: Cache code fixes.

anemo> Please fix c-tx39.c also.  This is a patch for 2.4 branch.

And this is one for trunk (2.6).

diff -ur linux-mips-cvs-2.6/arch/mips/mm/c-tx39.c linux.new-2.6/arch/mips/mm/c-tx39.c
--- linux-mips-cvs-2.6/arch/mips/mm/c-tx39.c	Wed Jul 16 19:49:27 2003
+++ linux.new-2.6/arch/mips/mm/c-tx39.c	Wed Jul 16 19:52:42 2003
@@ -25,9 +25,6 @@
 
 /* For R3000 cores with R4000 style caches */
 static unsigned long icache_size, dcache_size;		/* Size in bytes */
-static unsigned long icache_way_size, dcache_way_size;	/* Size divided by ways */
-#define scache_size 0
-#define scache_way_size 0
 
 #include <asm/r4kcache.h>
 
@@ -474,15 +471,15 @@
 		break;
 	}
 
-	icache_way_size = icache_size / current_cpu_data.icache.ways;
-	dcache_way_size = dcache_size / current_cpu_data.dcache.ways;
+	current_cpu_data.icache.waysize = icache_size / current_cpu_data.icache.ways;
+	current_cpu_data.dcache.waysize = dcache_size / current_cpu_data.dcache.ways;
 
 	current_cpu_data.icache.sets =
-		icache_way_size / current_cpu_data.icache.linesz;
+		current_cpu_data.icache.waysize / current_cpu_data.icache.linesz;
 	current_cpu_data.dcache.sets =
-		dcache_way_size / current_cpu_data.dcache.linesz;
+		current_cpu_data.dcache.waysize / current_cpu_data.dcache.linesz;
 
-	if (dcache_way_size > PAGE_SIZE)
+	if (current_cpu_data.dcache.waysize > PAGE_SIZE)
 		current_cpu_data.dcache.flags |= MIPS_CACHE_ALIASES;
 
 	current_cpu_data.icache.waybit = 0;
---
Atsushi Nemoto

From flo@paradigm.rfc822.org Wed Jul 16 12:07:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 12:07:42 +0100 (BST)
Received: from noose.gt.owl.de ([IPv6:::ffff:62.52.19.4]:58379 "EHLO
	noose.gt.owl.de") by linux-mips.org with ESMTP id <S8225072AbTGPLHk>;
	Wed, 16 Jul 2003 12:07:40 +0100
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 9031F25E14; Wed, 16 Jul 2003 13:07:38 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 2ADA0138002; Wed, 16 Jul 2003 13:07:35 +0200 (CEST)
Date: Wed, 16 Jul 2003 13:07:35 +0200
From: Florian Lohoff <flo@rfc822.org>
To: linux-mips@linux-mips.org
Subject: sudo oops on mips64 linux_2_4
Message-ID: <20030716110735.GA10511@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD"
Content-Disposition: inline
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@paradigm.rfc822.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: 2797
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips


--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,
i am getting this oops running anything with "sudo" on a mips64 sgi indy.
This is -r linux_2_4 of yesterday. Module support is not compiled in

strace output up to the oops is this:

[...]
old_mmap(NULL, 321040, PROT_READ|PROT_EXEC, MAP_PRIVATE, 0, 0) =3D 0x2adc80=
00
mprotect(0x2add7000, 259600, PROT_NONE) =3D 0
old_mmap(0x2ae16000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, =
0) =3D
0x2ae16000
close(3)                                =3D 0
open("/lib/libnsl.so.1", O_RDONLY)      =3D 3
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) =
=3D 1024
fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D100028, ...}) =3D 0
old_mmap(NULL, 363472, PROT_READ|PROT_EXEC, MAP_PRIVATE, 0, 0) =3D 0x2ae180=
00
mprotect(0x2ae2f000, 269264, PROT_NONE) =3D 0
old_mmap(0x2ae6e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, =
0x16000) =3D 0x2ae6e000
old_mmap(0x2ae6f000, 7120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_=
ANONYMOUS, 3, 0x16000) =3D 0x2ae6f000
close(3)                                =3D 0
munmap(0x2aac4000, 9572)                =3D 0
uname({sys=3D"Linux", node=3D"debian", ...}) =3D 0
open("/etc/passwd", O_RDONLY)           =3D 3
fcntl64(3, F_GETFD)                     =3D 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         =3D 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) =3D 4
ioctl(4, 0x8912Oops in fault.c::do_page_fault, line 231:
Cpu 0

debian:~# sudo ls
Cpu 0 Unable to handle kernel paging request at address 0000000000000000, e=
pc =3D=3D ffffffff88171104, ra =3D=3D ffffffff880159f0

These are by the System.map
	ffffffff88171104 l_exc
	ffffffff880159f0 dev_ifconf

Oops in fault.c::do_page_fault, line 231:
Cpu 0
$0      : 0000000000000000 ffffffff881e0000 0000000000000020 00000000000000=
00
$4      : 0000000000000000 ffffffff881dffff ffffffff881e0000 00000000000000=
20
$8      : 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
$12     : 0000000000000000 0000000000000001 0000000000000028 00000000000000=
03
$16     : ffffffffffffffff 000000007fff7a20 0000000000000000 000000007fff7a=
28
$20     : 0000000000000004 000000007fff7aa0 000000007fff7b60 000000007fff7b=
f0
$24     : 0000000000000000 000000002ad0d6f0
$28     : ffffffff8a188000 ffffffff8a18be30 000000007fff7c80 ffffffff880159=
f0
Hi      : 0000000000000040
Lo      : 0000000000000010
epc     : ffffffff88171104    Not tainted
badvaddr: 0000000000000000
Status  : b000cce3  [ KX SX UX KERNEL EXL IE ]
Cause   : 0000000c
Process sudo (pid: 225, stackpage=3Dffffffff8a188000)
Stack: 0000004000000000 000000050000013a 000000505d00f61c 0000000000000000
       ffffffff881cdd08 0000000000008912 ffffffff8a231a80 000000007fff7a20
       ffffffff880157dc 0000000000000002 000000007fff7e34 0000000000000004
       0000000000000004 000000007fff7a64 000000007fff7a60 ffffffff8801aeec
       0000000000000000 00000000100006c0 0000000000000fd6 0000000000000000
       0000000000000004 0000000000008912 000000007fff7a20 0000000000000000
       0000000000000000 0000000000000000 0000000010003ec0 0000000000000010
       000000002adc3f44 000000002adc3f44 0000000020666f72 0000000020256820
       000000007fff7e34 0000000000000001 0000000000000001 0000000000000002
       0000000000000000 000000007fff7aa0 000000007fff7b60 000000007fff7bf0
       0000000000000006 ...
Call Trace: [<ffffffff880157dc>] [<ffffffff8801aeec>]

Code: 0085202f  10c0fff2  64c5ffff <a0800000> 64840001  14a0fffd  64a5ffff =
 03e00008  00000000
Segmentation fault

--=20
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

--HlL+5n6rz5pIUxbD
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/FTH3Uaz2rXW+gJcRAg3vAJ9Sh+yPwcEIumXuMgV75+sg9ADx/ACfaP5O
nPI3eArRIJC/11oAmZQkmnI=
=JIyt
-----END PGP SIGNATURE-----

--HlL+5n6rz5pIUxbD--

From liam.girdwood@wolfsonmicro.com Wed Jul 16 13:39:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 13:39:49 +0100 (BST)
Received: from [IPv6:::ffff:194.217.161.2] ([IPv6:::ffff:194.217.161.2]:33723
	"EHLO wolfsonmicro.com") by linux-mips.org with ESMTP
	id <S8225072AbTGPMjr>; Wed, 16 Jul 2003 13:39:47 +0100
Received: from campbeltown.wolfson.co.uk (campbeltown [192.168.0.166])
	by wolfsonmicro.com (8.11.3/8.11.3) with ESMTP id h6GCdae07651
	for <linux-mips@linux-mips.org>; Wed, 16 Jul 2003 13:39:36 +0100 (BST)
Received: from caernarfon (unverified) by campbeltown.wolfson.co.uk
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6377c04222c0a800a6414@campbeltown.wolfson.co.uk> for <linux-mips@linux-mips.org>;
 Wed, 16 Jul 2003 13:40:50 +0100
Subject: [PATCH] [2.60-test1] Alchemy UART build problems
From: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
To: linux-mips <linux-mips@linux-mips.org>
Content-Type: text/plain
Message-Id: <1058359177.10765.1568.camel@caernarfon>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3 
Date: 16 Jul 2003 13:39:37 +0100
Content-Transfer-Encoding: 7bit
Return-Path: <liam.girdwood@wolfsonmicro.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: 2798
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: liam.girdwood@wolfsonmicro.com
Precedence: bulk
X-list: linux-mips

Hi,

I've found some function/type naming errors within the Alchemy serial
driver. Patch below.


Index: drivers/serial/au1x00_uart.c
===================================================================
RCS file: /home/cvs/linux/drivers/serial/au1x00_uart.c,v
retrieving revision 1.1
diff -r1.1 au1x00_uart.c
1079c1079
< 		up->port.irq      = irq_cannonicalize(old_serial_port[i].irq);
---
> 		up->port.irq      = irq_canonicalize(old_serial_port[i].irq);
1307c1307
< int __init early_serial_setup(struct serial_struct *req)
---
> int __init early_serial_setup(struct uart_port *req)


There is also a reference to a non existant member called change_speed
of struct uart_ops on line 1055 i.e. 

	.change_speed	= serial_au1x00_change_speed,

This builds if it is commented out, however serial_au1x00_change_speed()
is not called anywhere in the driver and the change_speed member is not
used anywhere else in the kernel!

It looks like this file is still in transition between 2.4 and 2.6 as
the 2.4 driver works fine. Does anyone have a working 2.5/2.6 Alchemy
uart driver ?

Thanks

Liam 

-- 
Liam Girdwood <liam.girdwood@wolfsonmicro.com>



Wolfson Microelectronics plc
http://www.wolfsonmicro.com
t: +44 131 272-7000
f: +44 131 272-7001
Registered in Scotland 89839

This message may contain confidential or proprietary information. If you receive this message in error, please
immediately delete it, destroy all copies of it and notify the sender. Any views expressed in this message are those of the individual sender,
except where the message states otherwise. We take reasonable precautions to ensure our Emails are virus free.
However, we cannot accept responsibility for any virus transmitted by us
and recommend that you subject any incoming Email to your own virus
checking procedures.


From liam.girdwood@wolfsonmicro.com Wed Jul 16 13:55:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 13:55:35 +0100 (BST)
Received: from [IPv6:::ffff:194.217.161.2] ([IPv6:::ffff:194.217.161.2]:446
	"EHLO wolfsonmicro.com") by linux-mips.org with ESMTP
	id <S8225072AbTGPMzd>; Wed, 16 Jul 2003 13:55:33 +0100
Received: from campbeltown.wolfson.co.uk (campbeltown [192.168.0.166])
	by wolfsonmicro.com (8.11.3/8.11.3) with ESMTP id h6GCtOe08872
	for <linux-mips@linux-mips.org>; Wed, 16 Jul 2003 13:55:25 +0100 (BST)
Received: from caernarfon (unverified) by campbeltown.wolfson.co.uk
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6377cebba8c0a800a6414@campbeltown.wolfson.co.uk> for <linux-mips@linux-mips.org>;
 Wed, 16 Jul 2003 13:56:39 +0100
Subject: [2.6.0-test1] arch/mips/pci/pci.c Pb1500 build errors
From: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
To: linux-mips <linux-mips@linux-mips.org>
Content-Type: text/plain
Message-Id: <1058360126.10765.1584.camel@caernarfon>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3 
Date: 16 Jul 2003 13:55:26 +0100
Content-Transfer-Encoding: 7bit
Return-Path: <liam.girdwood@wolfsonmicro.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: 2799
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: liam.girdwood@wolfsonmicro.com
Precedence: bulk
X-list: linux-mips

Hi,

I've found a few undeclared values (that should be #define'ed somewhere)
in arch/mips/pci/pci.c when I'm building for the Pb1500. i.e.

arch/mips/pci/pci.c: In function `pcibios_fixup_resources':
arch/mips/pci/pci.c:98: structure has no member named `name'
arch/mips/pci/pci.c:116: `IO_MEM_LOGICAL_START' undeclared (first use in
this function)
arch/mips/pci/pci.c:116: (Each undeclared identifier is reported only
once
arch/mips/pci/pci.c:116: for each function it appears in.)
arch/mips/pci/pci.c:117: `IO_MEM_LOGICAL_END' undeclared (first use in
this function)
arch/mips/pci/pci.c:118: `IO_MEM_VIRTUAL_OFFSET' undeclared (first use
in this function)
arch/mips/pci/pci.c:121: `IO_PORT_LOGICAL_START' undeclared (first use
in this function)
arch/mips/pci/pci.c:122: `IO_PORT_LOGICAL_END' undeclared (first use in
this function)
arch/mips/pci/pci.c:123: `IO_PORT_VIRTUAL_OFFSET' undeclared (first use
in this function)
make[1]: *** [arch/mips/pci/pci.o] Error 1
make: *** [arch/mips/pci] Error 2


However, if I add the following:-

#define IO_PORT_LOGICAL_START    (Au1500_PCI_IO_START + 0x300)
#define IO_PORT_LOGICAL_END      (Au1500_PCI_IO_END)
#define IO_MEM_LOGICAL_START   (Au1500_PCI_MEM_START)
#define IO_MEM_LOGICAL_END     (Au1500_PCI_MEM_END)

I'm just left with the `IO_PORT_VIRTUAL_OFFSET' and
`IO_MEM_VIRTUAL_OFFSET' errors. I can't find anything familiar to them
from the Alchemy headers and noticed from 2.4 that both values used to
be set by ioremap().

Does anyone know what they should be ? 
I don't mind creating a patch for this.

Thanks

Liam

-- 
Liam Girdwood <liam.girdwood@wolfsonmicro.com>



Wolfson Microelectronics plc
http://www.wolfsonmicro.com
t: +44 131 272-7000
f: +44 131 272-7001
Registered in Scotland 89839

This message may contain confidential or proprietary information. If you receive this message in error, please
immediately delete it, destroy all copies of it and notify the sender. Any views expressed in this message are those of the individual sender,
except where the message states otherwise. We take reasonable precautions to ensure our Emails are virus free.
However, we cannot accept responsibility for any virus transmitted by us
and recommend that you subject any incoming Email to your own virus
checking procedures.


From macro@ds2.pg.gda.pl Wed Jul 16 14:05:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 14:05:13 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:59132 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225072AbTGPNFK>; Wed, 16 Jul 2003 14:05:10 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA26695;
	Wed, 16 Jul 2003 15:05:06 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 16 Jul 2003 15:05:05 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Florian Lohoff <flo@rfc822.org>
cc: linux-mips@linux-mips.org
Subject: Re: sudo oops on mips64 linux_2_4
In-Reply-To: <20030716110735.GA10511@paradigm.rfc822.org>
Message-ID: <Pine.GSO.3.96.1030716150225.25959B-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: 2800
X-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 Wed, 16 Jul 2003, Florian Lohoff wrote:

> debian:~# sudo ls
> Cpu 0 Unable to handle kernel paging request at address 0000000000000000, epc == ffffffff88171104, ra == ffffffff880159f0
> 
> These are by the System.map
> 	ffffffff88171104 l_exc
> 	ffffffff880159f0 dev_ifconf
> 
> Oops in fault.c::do_page_fault, line 231:
> Cpu 0
> $0      : 0000000000000000 ffffffff881e0000 0000000000000020 0000000000000000
> $4      : 0000000000000000 ffffffff881dffff ffffffff881e0000 0000000000000020
> $8      : 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> $12     : 0000000000000000 0000000000000001 0000000000000028 0000000000000003
> $16     : ffffffffffffffff 000000007fff7a20 0000000000000000 000000007fff7a28
> $20     : 0000000000000004 000000007fff7aa0 000000007fff7b60 000000007fff7bf0
> $24     : 0000000000000000 000000002ad0d6f0
> $28     : ffffffff8a188000 ffffffff8a18be30 000000007fff7c80 ffffffff880159f0
> Hi      : 0000000000000040
> Lo      : 0000000000000010
> epc     : ffffffff88171104    Not tainted
> badvaddr: 0000000000000000
> Status  : b000cce3  [ KX SX UX KERNEL EXL IE ]
> Cause   : 0000000c
> Process sudo (pid: 225, stackpage=ffffffff8a188000)
> Stack: 0000004000000000 000000050000013a 000000505d00f61c 0000000000000000
>        ffffffff881cdd08 0000000000008912 ffffffff8a231a80 000000007fff7a20
>        ffffffff880157dc 0000000000000002 000000007fff7e34 0000000000000004
>        0000000000000004 000000007fff7a64 000000007fff7a60 ffffffff8801aeec
>        0000000000000000 00000000100006c0 0000000000000fd6 0000000000000000
>        0000000000000004 0000000000008912 000000007fff7a20 0000000000000000
>        0000000000000000 0000000000000000 0000000010003ec0 0000000000000010
>        000000002adc3f44 000000002adc3f44 0000000020666f72 0000000020256820
>        000000007fff7e34 0000000000000001 0000000000000001 0000000000000002
>        0000000000000000 000000007fff7aa0 000000007fff7b60 000000007fff7bf0
>        0000000000000006 ...
> Call Trace: [<ffffffff880157dc>] [<ffffffff8801aeec>]
> 
> Code: 0085202f  10c0fff2  64c5ffff <a0800000> 64840001  14a0fffd  64a5ffff  03e00008  00000000
> Segmentation fault

 Please pass it through ksymoops for more details.  Version 2.4.9 should
work just fine for mips64.

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


From ChrisF@scc-inc.com Wed Jul 16 14:10:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 14:10:57 +0100 (BST)
Received: from [IPv6:::ffff:199.3.224.121] ([IPv6:::ffff:199.3.224.121]:57099
	"EHLO mailsweeper.scc-inc.com") by linux-mips.org with ESMTP
	id <S8225072AbTGPNKy>; Wed, 16 Jul 2003 14:10:54 +0100
Received: from Mailserver.scc-inc.com (mailserver.scc-inc.com) by mailsweeper.scc-inc.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6376c820320a0101456f0@mailsweeper.scc-inc.com> for <linux-mips@linux-mips.org>;
 Wed, 16 Jul 2003 09:09:49 -0400
Received: by Mailserver.scc-inc.com with Internet Mail Service (5.5.2653.19)
	id <N9DWDHMA>; Wed, 16 Jul 2003 09:11:23 -0400
Message-ID: <4019CBE63D5A174F8F55FE25BC82D04102B46815@Mailserver.scc-inc.com>
From: Chris Fouts <ChrisF@SCC-INC.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Co-Proc. 0
Date: Wed, 16 Jul 2003 09:11:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <ChrisF@scc-inc.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: 2801
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ChrisF@SCC-INC.com
Precedence: bulk
X-list: linux-mips

What options do I use for the compiler to recoginze the C0 specific
op-codes,
e.g., mfc0, mtc0, etc? I tried -mips1, -mips2, -mips3 and arch=RM7000 to no
avail.

-chris

From sseeger@stellartec.com Wed Jul 16 15:02:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 15:02:07 +0100 (BST)
Received: from mail.stellartec.com ([IPv6:::ffff:65.107.16.99]:33553 "EHLO
	nt_server.stellartec.com") by linux-mips.org with ESMTP
	id <S8225238AbTGPOCD>; Wed, 16 Jul 2003 15:02:03 +0100
Received: from WSSTEVELAPTOP ([192.168.1.60]) by nt_server.stellartec.com
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 568-43562U100L2S100) with SMTP id AAA455
          for <linux-mips@linux-mips.org>; Wed, 16 Jul 2003 07:01:43 -0700
Reply-To: <sseeger@stellartec.com>
From: sseeger@stellartec.com (Steven Seeger)
To: <linux-mips@linux-mips.org>
Subject: mmap broken on cvs update 2_4
Date: Wed, 16 Jul 2003 07:01:33 -0700
Message-ID: <004c01c34ba2$c499ba20$4383a8c0@WSSTEVELAPTOP>
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 CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20030716014340.GA12436@nevyn.them.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Return-Path: <sseeger@stellartec.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: 2802
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sseeger@stellartec.com
Precedence: bulk
X-list: linux-mips

The signal defined 1 problem is really a Bus error. uClibc is broken for
signals and got them from the x86 asm/signal.h file to build its default
string messages.

I'm using mmap. It maps successfully and has the proper ranges in
/proc/pid/maps.

When I try to access the memory I get a bus error. This did not happen
before I did a cvs update. I had even rebuilt a kernel prior to the cvs
update that didn't do that.

If someone can tell me where to look I'd appreciate it.

Steve


From flo@paradigm.rfc822.org Wed Jul 16 15:48:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 15:48:05 +0100 (BST)
Received: from noose.gt.owl.de ([IPv6:::ffff:62.52.19.4]:5137 "EHLO
	noose.gt.owl.de") by linux-mips.org with ESMTP id <S8225072AbTGPOsC>;
	Wed, 16 Jul 2003 15:48:02 +0100
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 148A225DCC; Wed, 16 Jul 2003 16:48:01 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id B2571138002; Wed, 16 Jul 2003 16:21:36 +0200 (CEST)
Date: Wed, 16 Jul 2003 16:21:36 +0200
From: Florian Lohoff <flo@rfc822.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: sudo oops on mips64 linux_2_4
Message-ID: <20030716142136.GA13810@paradigm.rfc822.org>
References: <20030716110735.GA10511@paradigm.rfc822.org> <Pine.GSO.3.96.1030716150225.25959B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030716150225.25959B-100000@delta.ds2.pg.gda.pl>
Organization: rfc822 - pure communication
User-Agent: Mutt/1.5.4i
Return-Path: <flo@paradigm.rfc822.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: 2803
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips


--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 16, 2003 at 03:05:05PM +0200, Maciej W. Rozycki wrote:
>  Please pass it through ksymoops for more details.  Version 2.4.9 should
> work just fine for mips64.

This looks still broken - Giving the vmlinux file to ksymoops makes it
even worse - tons or errors.

ksymoops 2.4.8 on mips 2.4.19-r5k-ip22.  Options used
     -v /dev/null (specified)
     -k /dev/null (specified)
     -l /dev/null (specified)
     -o /dev/null (specified)
     -m /home/flo/System.map (specified)

Error (regular_file): read_nm_symbols /dev/null is not a regular file, igno=
red
Warning (read_vmlinux): no kernel symbols in vmlinux, is /dev/null a valid =
vmlinux file?
Error (regular_file): read_ksyms /dev/null is not a regular file, ignored
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Cpu 0 Unable to handle kernel paging request at address 0000000000000000, e=
pc =3D=3D ffffffff88171104, ra =3D=3D ffffffff880159f0
Cpu 0
$0      : 0000000000000000 ffffffff881e0000 0000000000000020 00000000000000=
00
$4      : 0000000000000000 ffffffff881dffff ffffffff881e0000 00000000000000=
20
$8      : 0000000000000000 0000000000000000 0000000000000000 00000000000000=
00
$12     : 0000000000000000 0000000000000001 0000000000000028 00000000000000=
03
$16     : ffffffffffffffff 000000007fff7a20 0000000000000000 000000007fff7a=
28
$20     : 0000000000000004 000000007fff7aa0 000000007fff7b60 000000007fff7b=
f0
$24     : 0000000000000000 000000002ad0d6f0
$28     : ffffffff8a188000 ffffffff8a18be30 000000007fff7c80 ffffffff880159=
f0
epc     : ffffffff88171104    Not tainted
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
Process sudo (pid: 225, stackpage=3Dffffffff8a188000)
Stack: 0000004000000000 000000050000013a 000000505d00f61c 0000000000000000
       ffffffff881cdd08 0000000000008912 ffffffff8a231a80 000000007fff7a20
       ffffffff880157dc 0000000000000002 000000007fff7e34 0000000000000004
       0000000000000004 000000007fff7a64 000000007fff7a60 ffffffff8801aeec
       0000000000000000 00000000100006c0 0000000000000fd6 0000000000000000
       0000000000000004 0000000000008912 000000007fff7a20 0000000000000000
       0000000000000000 0000000000000000 0000000010003ec0 0000000000000010
       000000002adc3f44 000000002adc3f44 0000000020666f72 0000000020256820
       000000007fff7e34 0000000000000001 0000000000000001 0000000000000002
       0000000000000000 000000007fff7aa0 000000007fff7b60 000000007fff7bf0
       0000000000000006 ...
Call Trace: [<ffffffff880157dc>] [<ffffffff8801aeec>]
Code: 0085202f  10c0fff2  64c5ffff <a0800000> 64840001  14a0fffd  64a5ffff =
 03e00008  00000000


>>PC;  ffffffff88171104 <END_OF_CODE+fffffffeffe868fc/????>   <=3D=3D=3D=3D=
=3D

Trace; ffffffff880157dc <END_OF_CODE+fffffffeffd2afd4/????>
Trace; ffffffff8801aeec <END_OF_CODE+fffffffeffd306e4/????>

Code;  881710f8 <fbmem_read_proc+d8/100>
00000000 <_PC>:
Code;  881710f8 <fbmem_read_proc+d8/100>
   0:   0085202f  0x85202f
Code;  881710fc <fbmem_read_proc+dc/100>
   4:   10c0fff2  beqz    a2,ffffffd0 <_PC+0xffffffd0>
Code;  88171100 <fbmem_read_proc+e0/100>
   8:   64c5ffff  0x64c5ffff
Code;  88171104 <fbmem_read_proc+e4/100>
   c:   a0800000  sb      zero,0(a0)
Code;  88171108 <fbmem_read_proc+e8/100>
  10:   64840001  0x64840001
Code;  8817110c <fbmem_read_proc+ec/100>
  14:   14a0fffd  bnez    a1,c <_PC+0xc>
Code;  88171110 <fbmem_read_proc+f0/100>
  18:   64a5ffff  0x64a5ffff
Code;  88171114 <fbmem_read_proc+f4/100>
  1c:   03e00008  jr      ra
Code;  88171118 <fbmem_read_proc+f8/100>
  20:   00000000  nop


1 warning and 2 errors issued.  Results may not be reliable.

Flo
--=20
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/FV9wUaz2rXW+gJcRAq7IAKCIA2BRJuWgV3eWKO2Muhqlvswl/ACeJE+g
tj8Y1eNk+wTNqfQtePmPcL8=
=IVk1
-----END PGP SIGNATURE-----

--AhhlLboLdkugWU4S--

From ChrisF@scc-inc.com Wed Jul 16 16:04:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 16:04:50 +0100 (BST)
Received: from [IPv6:::ffff:199.3.224.121] ([IPv6:::ffff:199.3.224.121]:44047
	"EHLO mailsweeper.scc-inc.com") by linux-mips.org with ESMTP
	id <S8225072AbTGPPEs>; Wed, 16 Jul 2003 16:04:48 +0100
Received: from Mailserver.scc-inc.com (mailserver.scc-inc.com) by mailsweeper.scc-inc.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6377305fd10a0101456f0@mailsweeper.scc-inc.com>;
 Wed, 16 Jul 2003 11:03:41 -0400
Received: by Mailserver.scc-inc.com with Internet Mail Service (5.5.2653.19)
	id <N9DWDH6A>; Wed, 16 Jul 2003 11:05:15 -0400
Message-ID: <4019CBE63D5A174F8F55FE25BC82D04102B46818@Mailserver.scc-inc.com>
From: Chris Fouts <ChrisF@SCC-INC.com>
To: "'Maciej W. Rozycki'" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: RE: sudo oops on mips64 linux_2_4
Date: Wed, 16 Jul 2003 11:05:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <ChrisF@scc-inc.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: 2804
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ChrisF@SCC-INC.com
Precedence: bulk
X-list: linux-mips

I'm just getting started with MIPS in Linux so please bear with me.

What options do I use for the compiler to recoginze the C0 specific
op-codes, e.g., mfc0, mtc0, etc? I tried -mips1, -mips2, -mips3 and 
arch=RM7000 to no avail.

-chris

From macro@ds2.pg.gda.pl Wed Jul 16 16:21:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 16:21:26 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:55427 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225072AbTGPPVY>; Wed, 16 Jul 2003 16:21:24 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA28437;
	Wed, 16 Jul 2003 17:21:20 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 16 Jul 2003 17:21:20 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Florian Lohoff <flo@rfc822.org>
cc: linux-mips@linux-mips.org
Subject: Re: sudo oops on mips64 linux_2_4
In-Reply-To: <20030716142136.GA13810@paradigm.rfc822.org>
Message-ID: <Pine.GSO.3.96.1030716165657.25959C-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: 2805
X-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 Wed, 16 Jul 2003, Florian Lohoff wrote:

> >  Please pass it through ksymoops for more details.  Version 2.4.9 should
> > work just fine for mips64.
> 
> This looks still broken - Giving the vmlinux file to ksymoops makes it
> even worse - tons or errors.
> 
> ksymoops 2.4.8 on mips 2.4.19-r5k-ip22.  Options used
>      -v /dev/null (specified)
>      -k /dev/null (specified)
>      -l /dev/null (specified)
>      -o /dev/null (specified)
>      -m /home/flo/System.map (specified)

 Hmm, I would use "-V -K -L -O -m /home/flo/System.map" instead. ;-)  And
also "-t elf64-tradbigmips -a mips:5000" as you really want 64-bit
addresses and opcodes beyond R3k (and your ksymoops isn't configured to
use a 64-bit target by default).  Using vmlinux might give additional
information beyond what System.map can provide and it should work just
fine once right options are passed to ksymoops -- I used to get correct
output with no warnings at all. 

 At least we know the error is in drivers/video/fbmem.c:fbmem_read_proc() 
because of buf being null.  But please retry with the above options to get
some addresses decoded. 

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


From ppopov@mvista.com Wed Jul 16 17:06:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 17:06:52 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57072 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225072AbTGPQGu>;
	Wed, 16 Jul 2003 17:06:50 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA14303;
	Wed, 16 Jul 2003 09:06:46 -0700
Subject: Re: [PATCH] [2.6.0-test1] Alchemy Pb1500 - Power management
From: Pete Popov <ppopov@mvista.com>
To: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1058348289.10765.1527.camel@caernarfon>
References: <1058348289.10765.1527.camel@caernarfon>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1058371630.27085.4.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 16 Jul 2003 09:07:10 -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: 2806
X-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

Thanks.

BTW, I'm waiting for some PM patches from Embedded Edge that will
cleanup and Au1x PM support.

Pete

On Wed, 2003-07-16 at 02:38, Liam Girdwood wrote:
> Hi,
> 
> I'm working my way through building the latest CVS for my Pb1500 and
> I've run into a couple of build problems.
> 
> This patch fixes some function naming problems and removes duplicate
> symbol au1k_wait() (defined in kernel/cpu-probe.c) in the Pb1500 power
> management code.
> 
> Index: arch/mips/au1000/common/power.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/common/power.c,v
> retrieving revision 1.10
> diff -r1.10 power.c
> 36a37
> > #include <linux/jiffies.h>
> 54,55c55,56
> < extern void set_au1000_speed(unsigned int new_freq);
> < extern unsigned int get_au1000_speed(void);
> ---
> > extern void set_au1x00_speed(unsigned int new_freq);
> > extern unsigned int get_au1x00_speed(void);
> 190,191c191,192
> < 		old_baud_base = get_au1000_uart_baud_base();
> < 		old_cpu_freq = get_au1000_speed();
> ---
> > 		old_baud_base = get_au1x00_uart_baud_base();
> > 		old_cpu_freq = get_au1x00_speed();
> 195,196c196,197
> < 		set_au1000_speed(new_cpu_freq);
> < 		set_au1000_uart_baud_base(new_baud_base);
> ---
> > 		set_au1x00_speed(new_cpu_freq);
> > 		set_au1x00_uart_baud_base(new_baud_base);
> 325,329d325
> < }
> < 
> < void au1k_wait(void)
> < {
> < 	__asm__("nop\n\t" "nop\n\t");
> 
> 
> Liam


From ppopov@mvista.com Wed Jul 16 17:19:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 17:19:22 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:25334 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225072AbTGPQTT>;
	Wed, 16 Jul 2003 17:19:19 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA14794;
	Wed, 16 Jul 2003 09:19:16 -0700
Subject: Re: [PATCH] [2.60-test1] Alchemy UART build problems
From: Pete Popov <ppopov@mvista.com>
To: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1058359177.10765.1568.camel@caernarfon>
References: <1058359177.10765.1568.camel@caernarfon>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1058372380.27085.12.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 16 Jul 2003 09:19: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: 2807
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, 2003-07-16 at 05:39, Liam Girdwood wrote:
> Hi,
> 
> I've found some function/type naming errors within the Alchemy serial
> driver. Patch below.
> 
> 
> Index: drivers/serial/au1x00_uart.c
> ===================================================================
> RCS file: /home/cvs/linux/drivers/serial/au1x00_uart.c,v
> retrieving revision 1.1
> diff -r1.1 au1x00_uart.c
> 1079c1079
> < 		up->port.irq      = irq_cannonicalize(old_serial_port[i].irq);
> ---
> > 		up->port.irq      = irq_canonicalize(old_serial_port[i].irq);
> 1307c1307
> < int __init early_serial_setup(struct serial_struct *req)
> ---
> > int __init early_serial_setup(struct uart_port *req)
> 
> 
> There is also a reference to a non existant member called change_speed
> of struct uart_ops on line 1055 i.e. 
> 
> 	.change_speed	= serial_au1x00_change_speed,
> 
> This builds if it is commented out, however serial_au1x00_change_speed()
> is not called anywhere in the driver and the change_speed member is not
> used anywhere else in the kernel!
> 
> It looks like this file is still in transition between 2.4 and 2.6 as
> the 2.4 driver works fine. Does anyone have a working 2.5/2.6 Alchemy
> uart driver ?

The serial driver worked fine for me about a month or more ago. Then
there was a large update with the latest 2.5.x bits and it's very
possible that the driver got broken. There are other Au1x problems in
2.5 as well. The 36 bit address patch is not there yet. The last time I
played with 2.5 the kernel mounted the root fs and then hung trying to
start a userland process ... and I haven't had any time since then.  I
think you're in new territory here but, hey, someone needs to clean up
everything :)

Pete


From liam.girdwood@wolfsonmicro.com Wed Jul 16 17:21:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 17:21:46 +0100 (BST)
Received: from [IPv6:::ffff:194.217.161.2] ([IPv6:::ffff:194.217.161.2]:36577
	"EHLO wolfsonmicro.com") by linux-mips.org with ESMTP
	id <S8225072AbTGPQVo>; Wed, 16 Jul 2003 17:21:44 +0100
Received: from campbeltown.wolfson.co.uk (campbeltown [192.168.0.166])
	by wolfsonmicro.com (8.11.3/8.11.3) with ESMTP id h6GGLWe24010
	for <linux-mips@linux-mips.org>; Wed, 16 Jul 2003 17:21:32 +0100 (BST)
Received: from caernarfon (unverified) by campbeltown.wolfson.co.uk
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T63788b7491c0a800a6414@campbeltown.wolfson.co.uk> for <linux-mips@linux-mips.org>;
 Wed, 16 Jul 2003 17:22:47 +0100
Subject: [PATCH][2.6.0-test1] Pb1500 PCI - Makefile rule typo
From: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
To: linux-mips <linux-mips@linux-mips.org>
Content-Type: text/plain
Message-Id: <1058372493.10765.1600.camel@caernarfon>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3 
Date: 16 Jul 2003 17:21:33 +0100
Content-Transfer-Encoding: 7bit
Return-Path: <liam.girdwood@wolfsonmicro.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: 2808
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: liam.girdwood@wolfsonmicro.com
Precedence: bulk
X-list: linux-mips

Hi,

Please find attached a small patch that fixes a typo in the PCI makefile
for mips PCI.

Index: arch/mips/pci/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/pci/Makefile,v
retrieving revision 1.2
diff -r1.2 Makefile
22c22
< obj-$(CONFIG_MIPS_PB1500)	+= fixups-au1000.o ops-au1000.o
---
> obj-$(CONFIG_MIPS_PB1500)	+= fixup-au1000.o ops-au1000.o


Liam

-- 
Liam Girdwood <liam.girdwood@wolfsonmicro.com>



Wolfson Microelectronics plc
http://www.wolfsonmicro.com
t: +44 131 272-7000
f: +44 131 272-7001
Registered in Scotland 89839

This message may contain confidential or proprietary information. If you receive this message in error, please
immediately delete it, destroy all copies of it and notify the sender. Any views expressed in this message are those of the individual sender,
except where the message states otherwise. We take reasonable precautions to ensure our Emails are virus free.
However, we cannot accept responsibility for any virus transmitted by us
and recommend that you subject any incoming Email to your own virus
checking procedures.


From ladis@linux-mips.org Wed Jul 16 19:49:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 19:49:45 +0100 (BST)
Received: from p0064.as-l042.contactel.cz ([IPv6:::ffff:194.108.237.64]:64004
	"EHLO kopretinka") by linux-mips.org with ESMTP id <S8225072AbTGPStn>;
	Wed, 16 Jul 2003 19:49:43 +0100
Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian))
	id 19crHU-0001jU-00; Wed, 16 Jul 2003 20:45:36 +0200
Date: Wed, 16 Jul 2003 20:45:15 +0200
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Florian Lohoff <flo@rfc822.org>, linux-mips@linux-mips.org
Subject: Re: sudo oops on mips64 linux_2_4
Message-ID: <20030716184515.GA971@kopretinka>
References: <20030716142136.GA13810@paradigm.rfc822.org> <Pine.GSO.3.96.1030716165657.25959C-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.1030716165657.25959C-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.3.28i
From: Ladislav Michl <ladis@linux-mips.org>
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: 2809
X-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, Jul 16, 2003 at 05:21:20PM +0200, Maciej W. Rozycki wrote:
> On Wed, 16 Jul 2003, Florian Lohoff wrote:
> 
> > >  Please pass it through ksymoops for more details.  Version 2.4.9 should
> > > work just fine for mips64.
> > 
> > This looks still broken - Giving the vmlinux file to ksymoops makes it
> > even worse - tons or errors.
> > 
> > ksymoops 2.4.8 on mips 2.4.19-r5k-ip22.  Options used
> >      -v /dev/null (specified)
> >      -k /dev/null (specified)
> >      -l /dev/null (specified)
> >      -o /dev/null (specified)
> >      -m /home/flo/System.map (specified)
> 
>  Hmm, I would use "-V -K -L -O -m /home/flo/System.map" instead. ;-)  And
> also "-t elf64-tradbigmips -a mips:5000" as you really want 64-bit
> addresses and opcodes beyond R3k (and your ksymoops isn't configured to
> use a 64-bit target by default).  Using vmlinux might give additional
> information beyond what System.map can provide and it should work just
> fine once right options are passed to ksymoops -- I used to get correct
> output with no warnings at all. 
> 
>  At least we know the error is in drivers/video/fbmem.c:fbmem_read_proc() 

and at least we know there is something wrong. why is fbmem compiled in
at all?

> because of buf being null.  But please retry with the above options to get
> some addresses decoded.

	ladis

From macro@ds2.pg.gda.pl Wed Jul 16 20:01:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 20:01:43 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:33166 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225072AbTGPTBl>; Wed, 16 Jul 2003 20:01:41 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA00767;
	Wed, 16 Jul 2003 21:01:38 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 16 Jul 2003 21:01:37 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@linux-mips.org>
cc: Florian Lohoff <flo@rfc822.org>, linux-mips@linux-mips.org
Subject: Re: sudo oops on mips64 linux_2_4
In-Reply-To: <20030716184515.GA971@kopretinka>
Message-ID: <Pine.GSO.3.96.1030716205804.25959K-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: 2810
X-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 Wed, 16 Jul 2003, Ladislav Michl wrote:

> >  At least we know the error is in drivers/video/fbmem.c:fbmem_read_proc() 
> 
> and at least we know there is something wrong. why is fbmem compiled in
> at all?

 Well, that's not wrong per se and is actually valid at least for
CONFIG_FB_VIRTUAL.  And the code should fail gracefully if there nothing
useful to do.

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


From Geert.Uytterhoeven@sonycom.com Wed Jul 16 20:05:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 20:05:31 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:60354 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225072AbTGPTF3>;
	Wed, 16 Jul 2003 20:05:29 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h6GJ5J1W010390;
	Wed, 16 Jul 2003 21:05:19 +0200 (MEST)
Date: Wed, 16 Jul 2003 21:05:19 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ladislav Michl <ladis@linux-mips.org>,
	Florian Lohoff <flo@rfc822.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: sudo oops on mips64 linux_2_4
In-Reply-To: <Pine.GSO.3.96.1030716205804.25959K-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0307162104450.10176-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2811
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Wed, 16 Jul 2003, Maciej W. Rozycki wrote:
> On Wed, 16 Jul 2003, Ladislav Michl wrote:
> > >  At least we know the error is in drivers/video/fbmem.c:fbmem_read_proc() 
> > 
> > and at least we know there is something wrong. why is fbmem compiled in
> > at all?
> 
>  Well, that's not wrong per se and is actually valid at least for
> CONFIG_FB_VIRTUAL.  And the code should fail gracefully if there nothing
> useful to do.

You do not want to set CONFIG_FB_VIRTUAL=y, since the virtual frame buffer
device is meant for testing only.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From macro@ds2.pg.gda.pl Wed Jul 16 20:54:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 20:54:37 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:657 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225072AbTGPTyf>; Wed, 16 Jul 2003 20:54:35 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA01453;
	Wed, 16 Jul 2003 21:54:30 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 16 Jul 2003 21:54:30 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ladislav Michl <ladis@linux-mips.org>,
	Florian Lohoff <flo@rfc822.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: sudo oops on mips64 linux_2_4
In-Reply-To: <Pine.GSO.4.21.0307162104450.10176-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030716215248.25959N-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: 2812
X-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 Wed, 16 Jul 2003, Geert Uytterhoeven wrote:

> >  Well, that's not wrong per se and is actually valid at least for
> > CONFIG_FB_VIRTUAL.  And the code should fail gracefully if there nothing
> > useful to do.
> 
> You do not want to set CONFIG_FB_VIRTUAL=y, since the virtual frame buffer
> device is meant for testing only.

 Sure -- and I should expect random crashes if I happen to enable it,
right? 

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


From Geert.Uytterhoeven@sonycom.com Wed Jul 16 20:57:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jul 2003 20:57:45 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:19688 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225072AbTGPT5n>;
	Wed, 16 Jul 2003 20:57:43 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h6GJva1W015295;
	Wed, 16 Jul 2003 21:57:36 +0200 (MEST)
Date: Wed, 16 Jul 2003 21:57:36 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ladislav Michl <ladis@linux-mips.org>,
	Florian Lohoff <flo@rfc822.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: sudo oops on mips64 linux_2_4
In-Reply-To: <Pine.GSO.3.96.1030716215248.25959N-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0307162156160.10187-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2813
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Wed, 16 Jul 2003, Maciej W. Rozycki wrote:
> On Wed, 16 Jul 2003, Geert Uytterhoeven wrote:
> > >  Well, that's not wrong per se and is actually valid at least for
> > > CONFIG_FB_VIRTUAL.  And the code should fail gracefully if there nothing
> > > useful to do.
> > 
> > You do not want to set CONFIG_FB_VIRTUAL=y, since the virtual frame buffer
> > device is meant for testing only.
> 
>  Sure -- and I should expect random crashes if I happen to enable it,
> right? 

I don't think so. Even if you set CONFIG_FB_VIRTUAL=y, you have to explicitly
enable it by passing `video=vfb' on the kernel command line. And it shouldn't
cause random crashes (but you never know ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From ralf@linux-mips.org Thu Jul 17 03:31:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jul 2003 03:31:58 +0100 (BST)
Received: from p508B60B5.dip.t-dialin.net ([IPv6:::ffff:80.139.96.181]:5043
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225246AbTGQCb4>; Thu, 17 Jul 2003 03:31:56 +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 h6H2UXDB006109;
	Thu, 17 Jul 2003 04:30:33 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6H2UVpP006108;
	Thu, 17 Jul 2003 04:30:31 +0200
Date: Thu, 17 Jul 2003 04:30:30 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Chris Fouts <ChrisF@SCC-INC.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Co-Proc. 0
Message-ID: <20030717023030.GA2378@linux-mips.org>
References: <4019CBE63D5A174F8F55FE25BC82D04102B46815@Mailserver.scc-inc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4019CBE63D5A174F8F55FE25BC82D04102B46815@Mailserver.scc-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: 2814
X-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, Jul 16, 2003 at 09:11:22AM -0400, Chris Fouts wrote:

> What options do I use for the compiler to recoginze the C0 specific
> op-codes,
> e.g., mfc0, mtc0, etc? I tried -mips1, -mips2, -mips3 and arch=RM7000 to no
> avail.

No options needed at all.

  Ralf

From liam.girdwood@wolfsonmicro.com Thu Jul 17 11:58:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jul 2003 11:58:10 +0100 (BST)
Received: from [IPv6:::ffff:194.217.161.2] ([IPv6:::ffff:194.217.161.2]:12493
	"EHLO wolfsonmicro.com") by linux-mips.org with ESMTP
	id <S8225201AbTGQK6I>; Thu, 17 Jul 2003 11:58:08 +0100
Received: from campbeltown.wolfson.co.uk (campbeltown [192.168.0.166])
	by wolfsonmicro.com (8.11.3/8.11.3) with ESMTP id h6HAw0e22621
	for <linux-mips@linux-mips.org>; Thu, 17 Jul 2003 11:58:00 +0100 (BST)
Received: from caernarfon (unverified) by campbeltown.wolfson.co.uk
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T637c89a5ecc0a800a6414@campbeltown.wolfson.co.uk> for <linux-mips@linux-mips.org>;
 Thu, 17 Jul 2003 11:59:17 +0100
Subject: [PATCH] 2.4 Alchemy Power management.
From: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
To: linux-mips <linux-mips@linux-mips.org>
Content-Type: text/plain
Message-Id: <1058439479.10765.1661.camel@caernarfon>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3 
Date: 17 Jul 2003 11:58:00 +0100
Content-Transfer-Encoding: 7bit
Return-Path: <liam.girdwood@wolfsonmicro.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: 2815
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: liam.girdwood@wolfsonmicro.com
Precedence: bulk
X-list: linux-mips

Hi,

This patch fixes some link errors with alchemy power management.

Index: arch/mips/au1000/common/power.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/common/power.c,v
retrieving revision 1.2.2.7
diff -r1.2.2.7 power.c
55,58c55,58
< extern void set_au1000_speed(unsigned int new_freq);
< extern unsigned int get_au1000_speed(void);
< extern unsigned long get_au1000_uart_baud_base(void);
< extern void set_au1000_uart_baud_base(unsigned long new_baud_base);
---
> extern void set_au1x00_speed(unsigned int new_freq);
> extern unsigned int get_au1x00_speed(void);
> extern unsigned long get_au1x00_uart_baud_base(void);
> extern void set_au1x00_uart_baud_base(unsigned long new_baud_base);
191,192c191,192
<               old_baud_base = get_au1000_uart_baud_base();
<               old_cpu_freq = get_au1000_speed();
---
>               old_baud_base = get_au1x00_uart_baud_base();
>               old_cpu_freq = get_au1x00_speed();
196,197c196,197
<               set_au1000_speed(new_cpu_freq);
<               set_au1000_uart_baud_base(new_baud_base);
---
>               set_au1x00_speed(new_cpu_freq);
>               set_au1x00_uart_baud_base(new_baud_base);
326,330d325
< }
<
< void au1k_wait(void)
< {
<       __asm__("nop\n\t" "nop\n\t");

Liam

-- 
Liam Girdwood <liam.girdwood@wolfsonmicro.com>



Wolfson Microelectronics plc
http://www.wolfsonmicro.com
t: +44 131 272-7000
f: +44 131 272-7001
Registered in Scotland 89839

This message may contain confidential or proprietary information. If you receive this message in error, please
immediately delete it, destroy all copies of it and notify the sender. Any views expressed in this message are those of the individual sender,
except where the message states otherwise. We take reasonable precautions to ensure our Emails are virus free.
However, we cannot accept responsibility for any virus transmitted by us
and recommend that you subject any incoming Email to your own virus
checking procedures.


From Geert.Uytterhoeven@sonycom.com Thu Jul 17 12:17:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jul 2003 12:17:06 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:19658 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225201AbTGQLRD>;
	Thu, 17 Jul 2003 12:17:03 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h6HBGv1W026447;
	Thu, 17 Jul 2003 13:16:57 +0200 (MEST)
Date: Thu, 17 Jul 2003 13:16:57 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH] 2.4 Alchemy Power management.
In-Reply-To: <1058439479.10765.1661.camel@caernarfon>
Message-ID: <Pine.GSO.4.21.0307171316420.10372-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2816
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On 17 Jul 2003, Liam Girdwood wrote:
> This patch fixes some link errors with alchemy power management.

Can you please use `diff -u' in the future? Thx!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From js@convergence.de Thu Jul 17 13:03:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jul 2003 13:03:29 +0100 (BST)
Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:62907 "EHLO
	mail.convergence.de") by linux-mips.org with ESMTP
	id <S8225201AbTGQMD1>; Thu, 17 Jul 2003 13:03:27 +0100
Received: from [10.1.1.146] (helo=heck)
	by mail.convergence.de with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.14)
	id 19d7Tq-0001Vu-8p
	for linux-mips@linux-mips.org; Thu, 17 Jul 2003 14:03:26 +0200
Received: from js by heck with local (Exim 3.35 #1 (Debian))
	id 19d7Tn-0001qV-00
	for <linux-mips@linux-mips.org>; Thu, 17 Jul 2003 14:03:23 +0200
Date: Thu, 17 Jul 2003 14:03:22 +0200
From: Johannes Stezenbach <js@convergence.de>
To: linux-mips@linux-mips.org
Subject: 2.4: typo in system.h / __save_and_sti
Message-ID: <20030717120322.GA6113@convergence.de>
Mail-Followup-To: Johannes Stezenbach <js@convergence.de>,
	linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <js@convergence.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: 2817
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: js@convergence.de
Precedence: bulk
X-list: linux-mips

Hi,

I noticed a typo in the (apparently unused) __save_and_sti() macro:

include/asm/system.h (both mips and mips64, linux_2_4 branch):

#define __save_and_sti(x)                                               \
__asm__ __volatile__(                                                   \
        "__save_and_cli\t%0"                                            \
                    ^^^
        : "=r" (x)                                                      \
        : /* no inputs */                                               \
        : "memory")

Johannes

From ralf@linux-mips.org Fri Jul 18 04:21:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 04:21:41 +0100 (BST)
Received: from p508B56D0.dip.t-dialin.net ([IPv6:::ffff:80.139.86.208]:43162
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225211AbTGRDVj>; Fri, 18 Jul 2003 04:21:39 +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 h6I3LKDB007038;
	Fri, 18 Jul 2003 05:21:20 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6I3LJff007037;
	Fri, 18 Jul 2003 05:21:19 +0200
Date: Fri, 18 Jul 2003 05:21:19 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Johannes Stezenbach <js@convergence.de>, linux-mips@linux-mips.org
Subject: Re: 2.4: typo in system.h / __save_and_sti
Message-ID: <20030718032119.GA6974@linux-mips.org>
References: <20030717120322.GA6113@convergence.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030717120322.GA6113@convergence.de>
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: 2818
X-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, Jul 17, 2003 at 02:03:22PM +0200, Johannes Stezenbach wrote:

> I noticed a typo in the (apparently unused) __save_and_sti() macro:

Thanks for noticing this one.  Yes, __save_and_sti() seems unused
except by local_irq_set() which itself is unused.  The operation it
performs seems to be of little use but anyway, as a pointless exercise
appropriate for 5:20am hacking I fixed it in CVS.

  Ralf

From jack.miller@pioneer-pdt.com Fri Jul 18 17:57:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 17:57:18 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:31731
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225201AbTGRQ5N>; Fri, 18 Jul 2003 17:57:13 +0100
Received: from LEDA ([172.30.2.15]) 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>;
          Fri, 18 Jul 2003 09:59:54 -0700
From: jack.miller@pioneer-pdt.com (Jack Miller)
To: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: kernel BUG at sched.c:784!
Date: Fri, 18 Jul 2003 09:57:01 -0700
Message-ID: <JCELLCFDJLFKPOBFKGFNGEKJCFAA.jack.miller@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.4522.1200
Return-Path: <jack.miller@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: 2819
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jack.miller@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips

  We are developing a system based around a NEC VR5432 CPU and Broadcom
BCM703X System Controller. When the system is running with the intended
application and drivers we intermittently experience a kernel OOPS in the
scheduler.  Would someone please provide some insight to the following OOPS
?  It appears (with my limited understanding of the scheduler) that the
scheduler is trying to schedule the 'idle' task.  What condition prevails to
cause this to happen ?

  Using a J-TAG Debugger, I "walked" the task list (in both directions) and
everthing appears to be in order.

  Thanks in advance for your help.

  Regards,
    Jack


Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 20030322 (Pioneer
Voyager)) #1 Fri May 30 14:55:32 PDT 2003
ksymoops 2.4.6 on mips 2.4.17.  Options used
     -v vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.17/ (default)
     -m System.map (specified)
     -T 32

root@stb2073:~# kernel BUG at sched.c:784!
Unable to handle kernel paging request at virtual address 00000000, epc ==
8001524c, ra == 8001524c
$0 : 00000000 b001f800 0000001b 00000000 ffffff9d 80008000 0000001f 828f4a20
$8 : 00000001 ffffd890 00001890 801cb119 00000000 00000000 fffffff9 ffffffff
$16: 00000000 00000000 809ae000 828f4a20 80008000 00000000 80008000 1001ccf8
$24: 0000000a 00000002                   809ae000 809afe90 809afe90 8001524c
epc  : 8001524c    Tainted: P
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
Status: b001f803
Cause : 8000c40c
Process pvrd (pid: 331, stackpage=809ae000)
Stack: 8016eda8 8016edc0 00000310 fffffc18 00138f80 00000002 809afed8
00000070
       00000000 1001cd00 1001ccfc 809afec8 80014e74 80014e6c 00000400
00000200
       c008422b 80bd4160 00000000 00000000 00138f80 809ae000 80014dd4
2aac2000
       00000000 809aff18 00001807 7edffa50 8002242c 00000070 00000000
8016c290
       00000000 00000000 00000000 00989680 7edffa40 00000000 8000f7c4
8000f7c4
       00000000 ...
Call Trace: [<8016eda8>] [<8016edc0>] [<80014e74>] [<80014e6c>] [<c008422b>]
[<80014dd4>]
 [<8002242c>] [<8016c290>] [<8000f7c4>] [<8000f7c4>]
Code: 24a5edc0  0c0062f7  24060310 <08005485> ae200000  40016000  00000000
3421001f  3821001e


>>RA;  8001524c <schedule+33c/47c>
>>$1; b001f800 <_end+2fe2aea0/3fe2a6a0>
>>$5; 80008000 <init_task_union+0/0>
>>$7; 828f4a20 <_end+27000c0/3fe2a6a0>
>>$11; 801cb119 <printk_buf.4+19/400>
>>$18; 809ae000 <_end+7b96a0/3fe2a6a0>
>>$19; 828f4a20 <_end+27000c0/3fe2a6a0>
>>$20; 80008000 <init_task_union+0/0>
>>$22; 80008000 <init_task_union+0/0>
>>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
>>$28; 809ae000 <_end+7b96a0/3fe2a6a0>
>>$29; 809afe90 <_end+7bb530/3fe2a6a0>
>>$30; 809afe90 <_end+7bb530/3fe2a6a0>
>>$31; 8001524c <schedule+33c/47c>

>>PC;  8001524c <schedule+33c/47c>   <=====

Trace; 8016eda8 <mips_io_port_base+d08/1c30>
Trace; 8016edc0 <mips_io_port_base+d20/1c30>
Trace; 80014e74 <schedule_timeout+74/e4>
Trace; 80014e6c <schedule_timeout+6c/e4>
Trace; c008422b <[bcm7030]scard_interrupt+f/340>
Trace; 80014dd4 <process_timeout+0/2c>
Trace; 8002242c <sys_nanosleep+170/1fc>
Trace; 8016c290 <mips_hwi4_dispatch+70/78>
Trace; 8000f7c4 <stack_done+1c/38>
Trace; 8000f7c4 <stack_done+1c/38>

Code;  80015240 <schedule+330/47c>
00000000 <_PC>:
Code;  80015240 <schedule+330/47c>
   0:   24a5edc0  addiu   a1,a1,-4672
Code;  80015244 <schedule+334/47c>
   4:   0c0062f7  jal     18bdc <_PC+0x18bdc> 8002de1c
<generic_file_direct_IO+294/2d8>
Code;  80015248 <schedule+338/47c>
   8:   24060310  li      a2,784
Code;  8001524c <schedule+33c/47c>   <=====
   c:   08005485  j       15214 <_PC+0x15214> 8002a454 <__vma_link+9c/e0>
<=====
Code;  80015250 <schedule+340/47c>
  10:   ae200000  sw      zero,0(s1)
Code;  80015254 <schedule+344/47c>
  14:   40016000  mfc0    at,$12
Code;  80015258 <schedule+348/47c>
  18:   00000000  nop
Code;  8001525c <schedule+34c/47c>
  1c:   3421001f  ori     at,at,0x1f
Code;  80015260 <schedule+350/47c>
  20:   3821001e  xori    at,at,0x1e


Jack Miller <jack.miller@pioneer-pdt.com>
Pioneer Digital Technologies, Inc.
6170 Cornerstone Court East
Suite 330
San Diego, CA 92121-3767
vox: (858)824-0790 x356
fax: (858)824-0796


From sjhill@realitydiluted.com Fri Jul 18 18:11:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 18:11:11 +0100 (BST)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:42149
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225201AbTGRRLJ>; Fri, 18 Jul 2003 18:11:09 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 19dYl8-0002Yg-00; Fri, 18 Jul 2003 12:11:06 -0500
Message-ID: <3F1829AB.9090303@realitydiluted.com>
Date: Fri, 18 Jul 2003 13:08:59 -0400
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2
X-Accept-Language: en
MIME-Version: 1.0
To: Jack Miller <jack.miller@pioneer-pdt.com>
CC: Linux-Mips <linux-mips@linux-mips.org>
Subject: Re: kernel BUG at sched.c:784!
References: <JCELLCFDJLFKPOBFKGFNGEKJCFAA.jack.miller@pioneer-pdt.com>
In-Reply-To: <JCELLCFDJLFKPOBFKGFNGEKJCFAA.jack.miller@pioneer-pdt.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: 2820
X-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

Jack Miller wrote:
>   We are developing a system based around a NEC VR5432 CPU and Broadcom
> BCM703X System Controller. When the system is running with the intended
> application and drivers we intermittently experience a kernel OOPS in the
> scheduler.  Would someone please provide some insight to the following OOPS
> ?  It appears (with my limited understanding of the scheduler) that the
> scheduler is trying to schedule the 'idle' task.  What condition prevails to
> cause this to happen ?
>
Are you using their reference platform 93725 or 93730 or what?

> Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 20030322 (Pioneer
 >
Before I left Broadcom, I had that kernel at 2.4.18 I believe and the
703x drivers were working fine. Is there some reason you are not using
the Broadcom kernel? I did notice one of the lines had the smartcard
interrupt firing. Those drivers were not exactly supported well. Can
you provide more information on the hardware platform and version of
the drivers? Thanks.

-Steve, ex. Broadcom settop kernel developer


From jsun@mvista.com Fri Jul 18 18:22:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 18:23:02 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:14844 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225201AbTGRRW7>;
	Fri, 18 Jul 2003 18:22:59 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6IHMu332075;
	Fri, 18 Jul 2003 10:22:56 -0700
Date: Fri, 18 Jul 2003 10:22:56 -0700
From: Jun Sun <jsun@mvista.com>
To: Jack Miller <jack.miller@pioneer-pdt.com>
Cc: Linux-Mips <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: kernel BUG at sched.c:784!
Message-ID: <20030718102256.D31523@mvista.com>
References: <JCELLCFDJLFKPOBFKGFNGEKJCFAA.jack.miller@pioneer-pdt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <JCELLCFDJLFKPOBFKGFNGEKJCFAA.jack.miller@pioneer-pdt.com>; from jack.miller@pioneer-pdt.com on Fri, Jul 18, 2003 at 09:57:01AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2821
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


Your kernel looks old, and probably don't have the CPU bug workaround
code at the beginning of vec3 exception handler.

NESTED(except_vec3_generic, 0, sp)
#if R5432_CP0_INTERRUPT_WAR
                mfc0    k0, CP0_INDEX
#endif

Try this.

Jun

On Fri, Jul 18, 2003 at 09:57:01AM -0700, Jack Miller wrote:
>   We are developing a system based around a NEC VR5432 CPU and Broadcom
> BCM703X System Controller. When the system is running with the intended
> application and drivers we intermittently experience a kernel OOPS in the
> scheduler.  Would someone please provide some insight to the following OOPS
> ?  It appears (with my limited understanding of the scheduler) that the
> scheduler is trying to schedule the 'idle' task.  What condition prevails to
> cause this to happen ?
> 
>   Using a J-TAG Debugger, I "walked" the task list (in both directions) and
> everthing appears to be in order.
> 
>   Thanks in advance for your help.
> 
>   Regards,
>     Jack
> 
> 
> Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 20030322 (Pioneer
> Voyager)) #1 Fri May 30 14:55:32 PDT 2003
> ksymoops 2.4.6 on mips 2.4.17.  Options used
>      -v vmlinux (specified)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.17/ (default)
>      -m System.map (specified)
>      -T 32
> 
> root@stb2073:~# kernel BUG at sched.c:784!
> Unable to handle kernel paging request at virtual address 00000000, epc ==
> 8001524c, ra == 8001524c
> $0 : 00000000 b001f800 0000001b 00000000 ffffff9d 80008000 0000001f 828f4a20
> $8 : 00000001 ffffd890 00001890 801cb119 00000000 00000000 fffffff9 ffffffff
> $16: 00000000 00000000 809ae000 828f4a20 80008000 00000000 80008000 1001ccf8
> $24: 0000000a 00000002                   809ae000 809afe90 809afe90 8001524c
> epc  : 8001524c    Tainted: P
> Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
> Status: b001f803
> Cause : 8000c40c
> Process pvrd (pid: 331, stackpage=809ae000)
> Stack: 8016eda8 8016edc0 00000310 fffffc18 00138f80 00000002 809afed8
> 00000070
>        00000000 1001cd00 1001ccfc 809afec8 80014e74 80014e6c 00000400
> 00000200
>        c008422b 80bd4160 00000000 00000000 00138f80 809ae000 80014dd4
> 2aac2000
>        00000000 809aff18 00001807 7edffa50 8002242c 00000070 00000000
> 8016c290
>        00000000 00000000 00000000 00989680 7edffa40 00000000 8000f7c4
> 8000f7c4
>        00000000 ...
> Call Trace: [<8016eda8>] [<8016edc0>] [<80014e74>] [<80014e6c>] [<c008422b>]
> [<80014dd4>]
>  [<8002242c>] [<8016c290>] [<8000f7c4>] [<8000f7c4>]
> Code: 24a5edc0  0c0062f7  24060310 <08005485> ae200000  40016000  00000000
> 3421001f  3821001e
> 
> 
> >>RA;  8001524c <schedule+33c/47c>
> >>$1; b001f800 <_end+2fe2aea0/3fe2a6a0>
> >>$5; 80008000 <init_task_union+0/0>
> >>$7; 828f4a20 <_end+27000c0/3fe2a6a0>
> >>$11; 801cb119 <printk_buf.4+19/400>
> >>$18; 809ae000 <_end+7b96a0/3fe2a6a0>
> >>$19; 828f4a20 <_end+27000c0/3fe2a6a0>
> >>$20; 80008000 <init_task_union+0/0>
> >>$22; 80008000 <init_task_union+0/0>
> >>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
> >>$28; 809ae000 <_end+7b96a0/3fe2a6a0>
> >>$29; 809afe90 <_end+7bb530/3fe2a6a0>
> >>$30; 809afe90 <_end+7bb530/3fe2a6a0>
> >>$31; 8001524c <schedule+33c/47c>
> 
> >>PC;  8001524c <schedule+33c/47c>   <=====
> 
> Trace; 8016eda8 <mips_io_port_base+d08/1c30>
> Trace; 8016edc0 <mips_io_port_base+d20/1c30>
> Trace; 80014e74 <schedule_timeout+74/e4>
> Trace; 80014e6c <schedule_timeout+6c/e4>
> Trace; c008422b <[bcm7030]scard_interrupt+f/340>
> Trace; 80014dd4 <process_timeout+0/2c>
> Trace; 8002242c <sys_nanosleep+170/1fc>
> Trace; 8016c290 <mips_hwi4_dispatch+70/78>
> Trace; 8000f7c4 <stack_done+1c/38>
> Trace; 8000f7c4 <stack_done+1c/38>
> 
> Code;  80015240 <schedule+330/47c>
> 00000000 <_PC>:
> Code;  80015240 <schedule+330/47c>
>    0:   24a5edc0  addiu   a1,a1,-4672
> Code;  80015244 <schedule+334/47c>
>    4:   0c0062f7  jal     18bdc <_PC+0x18bdc> 8002de1c
> <generic_file_direct_IO+294/2d8>
> Code;  80015248 <schedule+338/47c>
>    8:   24060310  li      a2,784
> Code;  8001524c <schedule+33c/47c>   <=====
>    c:   08005485  j       15214 <_PC+0x15214> 8002a454 <__vma_link+9c/e0>
> <=====
> Code;  80015250 <schedule+340/47c>
>   10:   ae200000  sw      zero,0(s1)
> Code;  80015254 <schedule+344/47c>
>   14:   40016000  mfc0    at,$12
> Code;  80015258 <schedule+348/47c>
>   18:   00000000  nop
> Code;  8001525c <schedule+34c/47c>
>   1c:   3421001f  ori     at,at,0x1f
> Code;  80015260 <schedule+350/47c>
>   20:   3821001e  xori    at,at,0x1e
> 
> 
> Jack Miller <jack.miller@pioneer-pdt.com>
> Pioneer Digital Technologies, Inc.
> 6170 Cornerstone Court East
> Suite 330
> San Diego, CA 92121-3767
> vox: (858)824-0790 x356
> fax: (858)824-0796
> 
> 

From jack.miller@pioneer-pdt.com Fri Jul 18 18:27:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 18:27:09 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:62413
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225201AbTGRR1H>; Fri, 18 Jul 2003 18:27:07 +0100
Received: from LEDA ([172.30.2.15]) by ns.pioneer-pdt.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68491U100L2S100V35)
          with SMTP id com; Fri, 18 Jul 2003 10:29:51 -0700
From: jack.miller@pioneer-pdt.com (Jack Miller)
To: "Jun Sun" <jsun@mvista.com>
Cc: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: RE: kernel BUG at sched.c:784!
Date: Fri, 18 Jul 2003 10:26:59 -0700
Message-ID: <JCELLCFDJLFKPOBFKGFNOEKKCFAA.jack.miller@pioneer-pdt.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <20030718102256.D31523@mvista.com>
Return-Path: <jack.miller@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: 2822
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jack.miller@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips

  Jun,
   Thanks for your response.  Our kernel is actually based upon the
MontaVista kernel and that workaround is in place.

  Jack

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> Sent: Friday, July 18, 2003 10:23 AM
> To: Jack Miller
> Cc: Linux-Mips; jsun@mvista.com
> Subject: Re: kernel BUG at sched.c:784!
>
>
>
> Your kernel looks old, and probably don't have the CPU bug workaround
> code at the beginning of vec3 exception handler.
>
> NESTED(except_vec3_generic, 0, sp)
> #if R5432_CP0_INTERRUPT_WAR
>                 mfc0    k0, CP0_INDEX
> #endif
>
> Try this.
>
> Jun
>
> On Fri, Jul 18, 2003 at 09:57:01AM -0700, Jack Miller wrote:
> >   We are developing a system based around a NEC VR5432 CPU and Broadcom
> > BCM703X System Controller. When the system is running with the intended
> > application and drivers we intermittently experience a kernel
> OOPS in the
> > scheduler.  Would someone please provide some insight to the
> following OOPS
> > ?  It appears (with my limited understanding of the scheduler) that the
> > scheduler is trying to schedule the 'idle' task.  What
> condition prevails to
> > cause this to happen ?
> >
> >   Using a J-TAG Debugger, I "walked" the task list (in both
> directions) and
> > everthing appears to be in order.
> >
> >   Thanks in advance for your help.
> >
> >   Regards,
> >     Jack
> >
> >
> > Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 20030322 (Pioneer
> > Voyager)) #1 Fri May 30 14:55:32 PDT 2003
> > ksymoops 2.4.6 on mips 2.4.17.  Options used
> >      -v vmlinux (specified)
> >      -k /proc/ksyms (default)
> >      -l /proc/modules (default)
> >      -o /lib/modules/2.4.17/ (default)
> >      -m System.map (specified)
> >      -T 32
> >
> > root@stb2073:~# kernel BUG at sched.c:784!
> > Unable to handle kernel paging request at virtual address
> 00000000, epc ==
> > 8001524c, ra == 8001524c
> > $0 : 00000000 b001f800 0000001b 00000000 ffffff9d 80008000
> 0000001f 828f4a20
> > $8 : 00000001 ffffd890 00001890 801cb119 00000000 00000000
> fffffff9 ffffffff
> > $16: 00000000 00000000 809ae000 828f4a20 80008000 00000000
> 80008000 1001ccf8
> > $24: 0000000a 00000002                   809ae000 809afe90
> 809afe90 8001524c
> > epc  : 8001524c    Tainted: P
> > Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
> > Status: b001f803
> > Cause : 8000c40c
> > Process pvrd (pid: 331, stackpage=809ae000)
> > Stack: 8016eda8 8016edc0 00000310 fffffc18 00138f80 00000002 809afed8
> > 00000070
> >        00000000 1001cd00 1001ccfc 809afec8 80014e74 80014e6c 00000400
> > 00000200
> >        c008422b 80bd4160 00000000 00000000 00138f80 809ae000 80014dd4
> > 2aac2000
> >        00000000 809aff18 00001807 7edffa50 8002242c 00000070 00000000
> > 8016c290
> >        00000000 00000000 00000000 00989680 7edffa40 00000000 8000f7c4
> > 8000f7c4
> >        00000000 ...
> > Call Trace: [<8016eda8>] [<8016edc0>] [<80014e74>] [<80014e6c>]
> [<c008422b>]
> > [<80014dd4>]
> >  [<8002242c>] [<8016c290>] [<8000f7c4>] [<8000f7c4>]
> > Code: 24a5edc0  0c0062f7  24060310 <08005485> ae200000
> 40016000  00000000
> > 3421001f  3821001e
> >
> >
> > >>RA;  8001524c <schedule+33c/47c>
> > >>$1; b001f800 <_end+2fe2aea0/3fe2a6a0>
> > >>$5; 80008000 <init_task_union+0/0>
> > >>$7; 828f4a20 <_end+27000c0/3fe2a6a0>
> > >>$11; 801cb119 <printk_buf.4+19/400>
> > >>$18; 809ae000 <_end+7b96a0/3fe2a6a0>
> > >>$19; 828f4a20 <_end+27000c0/3fe2a6a0>
> > >>$20; 80008000 <init_task_union+0/0>
> > >>$22; 80008000 <init_task_union+0/0>
> > >>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
> > >>$28; 809ae000 <_end+7b96a0/3fe2a6a0>
> > >>$29; 809afe90 <_end+7bb530/3fe2a6a0>
> > >>$30; 809afe90 <_end+7bb530/3fe2a6a0>
> > >>$31; 8001524c <schedule+33c/47c>
> >
> > >>PC;  8001524c <schedule+33c/47c>   <=====
> >
> > Trace; 8016eda8 <mips_io_port_base+d08/1c30>
> > Trace; 8016edc0 <mips_io_port_base+d20/1c30>
> > Trace; 80014e74 <schedule_timeout+74/e4>
> > Trace; 80014e6c <schedule_timeout+6c/e4>
> > Trace; c008422b <[bcm7030]scard_interrupt+f/340>
> > Trace; 80014dd4 <process_timeout+0/2c>
> > Trace; 8002242c <sys_nanosleep+170/1fc>
> > Trace; 8016c290 <mips_hwi4_dispatch+70/78>
> > Trace; 8000f7c4 <stack_done+1c/38>
> > Trace; 8000f7c4 <stack_done+1c/38>
> >
> > Code;  80015240 <schedule+330/47c>
> > 00000000 <_PC>:
> > Code;  80015240 <schedule+330/47c>
> >    0:   24a5edc0  addiu   a1,a1,-4672
> > Code;  80015244 <schedule+334/47c>
> >    4:   0c0062f7  jal     18bdc <_PC+0x18bdc> 8002de1c
> > <generic_file_direct_IO+294/2d8>
> > Code;  80015248 <schedule+338/47c>
> >    8:   24060310  li      a2,784
> > Code;  8001524c <schedule+33c/47c>   <=====
> >    c:   08005485  j       15214 <_PC+0x15214> 8002a454
> <__vma_link+9c/e0>
> > <=====
> > Code;  80015250 <schedule+340/47c>
> >   10:   ae200000  sw      zero,0(s1)
> > Code;  80015254 <schedule+344/47c>
> >   14:   40016000  mfc0    at,$12
> > Code;  80015258 <schedule+348/47c>
> >   18:   00000000  nop
> > Code;  8001525c <schedule+34c/47c>
> >   1c:   3421001f  ori     at,at,0x1f
> > Code;  80015260 <schedule+350/47c>
> >   20:   3821001e  xori    at,at,0x1e
> >
> >
> > Jack Miller <jack.miller@pioneer-pdt.com>
> > Pioneer Digital Technologies, Inc.
> > 6170 Cornerstone Court East
> > Suite 330
> > San Diego, CA 92121-3767
> > vox: (858)824-0790 x356
> > fax: (858)824-0796
> >
> >
>


From jsun@mvista.com Fri Jul 18 18:44:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 18:44:48 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:52206 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225201AbTGRRoq>;
	Fri, 18 Jul 2003 18:44:46 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6IHii032136;
	Fri, 18 Jul 2003 10:44:44 -0700
Date: Fri, 18 Jul 2003 10:44:44 -0700
From: Jun Sun <jsun@mvista.com>
To: Jack Miller <jack.miller@pioneer-pdt.com>
Cc: Linux-Mips <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: kernel BUG at sched.c:784!
Message-ID: <20030718104444.E31523@mvista.com>
References: <20030718102256.D31523@mvista.com> <JCELLCFDJLFKPOBFKGFNOEKKCFAA.jack.miller@pioneer-pdt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <JCELLCFDJLFKPOBFKGFNOEKKCFAA.jack.miller@pioneer-pdt.com>; from jack.miller@pioneer-pdt.com on Fri, Jul 18, 2003 at 10:26:59AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2823
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jul 18, 2003 at 10:26:59AM -0700, Jack Miller wrote:
>   Jun,
>    Thanks for your response.  Our kernel is actually based upon the
> MontaVista kernel and that workaround is in place.
> 
>   Jack
>

Which line is 784?  There is another cpu bug which might cause this.

I checked our sherman source tree and did not find the corresponding
line.

Jun
 
> > -----Original Message-----
> > From: linux-mips-bounce@linux-mips.org
> > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> > Sent: Friday, July 18, 2003 10:23 AM
> > To: Jack Miller
> > Cc: Linux-Mips; jsun@mvista.com
> > Subject: Re: kernel BUG at sched.c:784!
> >
> >
> >
> > Your kernel looks old, and probably don't have the CPU bug workaround
> > code at the beginning of vec3 exception handler.
> >
> > NESTED(except_vec3_generic, 0, sp)
> > #if R5432_CP0_INTERRUPT_WAR
> >                 mfc0    k0, CP0_INDEX
> > #endif
> >
> > Try this.
> >
> > Jun
> >
> > On Fri, Jul 18, 2003 at 09:57:01AM -0700, Jack Miller wrote:
> > >   We are developing a system based around a NEC VR5432 CPU and Broadcom
> > > BCM703X System Controller. When the system is running with the intended
> > > application and drivers we intermittently experience a kernel
> > OOPS in the
> > > scheduler.  Would someone please provide some insight to the
> > following OOPS
> > > ?  It appears (with my limited understanding of the scheduler) that the
> > > scheduler is trying to schedule the 'idle' task.  What
> > condition prevails to
> > > cause this to happen ?
> > >
> > >   Using a J-TAG Debugger, I "walked" the task list (in both
> > directions) and
> > > everthing appears to be in order.
> > >
> > >   Thanks in advance for your help.
> > >
> > >   Regards,
> > >     Jack
> > >
> > >
> > > Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 20030322 (Pioneer
> > > Voyager)) #1 Fri May 30 14:55:32 PDT 2003
> > > ksymoops 2.4.6 on mips 2.4.17.  Options used
> > >      -v vmlinux (specified)
> > >      -k /proc/ksyms (default)
> > >      -l /proc/modules (default)
> > >      -o /lib/modules/2.4.17/ (default)
> > >      -m System.map (specified)
> > >      -T 32
> > >
> > > root@stb2073:~# kernel BUG at sched.c:784!
> > > Unable to handle kernel paging request at virtual address
> > 00000000, epc ==
> > > 8001524c, ra == 8001524c
> > > $0 : 00000000 b001f800 0000001b 00000000 ffffff9d 80008000
> > 0000001f 828f4a20
> > > $8 : 00000001 ffffd890 00001890 801cb119 00000000 00000000
> > fffffff9 ffffffff
> > > $16: 00000000 00000000 809ae000 828f4a20 80008000 00000000
> > 80008000 1001ccf8
> > > $24: 0000000a 00000002                   809ae000 809afe90
> > 809afe90 8001524c
> > > epc  : 8001524c    Tainted: P
> > > Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
> > > Status: b001f803
> > > Cause : 8000c40c
> > > Process pvrd (pid: 331, stackpage=809ae000)
> > > Stack: 8016eda8 8016edc0 00000310 fffffc18 00138f80 00000002 809afed8
> > > 00000070
> > >        00000000 1001cd00 1001ccfc 809afec8 80014e74 80014e6c 00000400
> > > 00000200
> > >        c008422b 80bd4160 00000000 00000000 00138f80 809ae000 80014dd4
> > > 2aac2000
> > >        00000000 809aff18 00001807 7edffa50 8002242c 00000070 00000000
> > > 8016c290
> > >        00000000 00000000 00000000 00989680 7edffa40 00000000 8000f7c4
> > > 8000f7c4
> > >        00000000 ...
> > > Call Trace: [<8016eda8>] [<8016edc0>] [<80014e74>] [<80014e6c>]
> > [<c008422b>]
> > > [<80014dd4>]
> > >  [<8002242c>] [<8016c290>] [<8000f7c4>] [<8000f7c4>]
> > > Code: 24a5edc0  0c0062f7  24060310 <08005485> ae200000
> > 40016000  00000000
> > > 3421001f  3821001e
> > >
> > >
> > > >>RA;  8001524c <schedule+33c/47c>
> > > >>$1; b001f800 <_end+2fe2aea0/3fe2a6a0>
> > > >>$5; 80008000 <init_task_union+0/0>
> > > >>$7; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > >>$11; 801cb119 <printk_buf.4+19/400>
> > > >>$18; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > >>$19; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > >>$20; 80008000 <init_task_union+0/0>
> > > >>$22; 80008000 <init_task_union+0/0>
> > > >>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
> > > >>$28; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > >>$29; 809afe90 <_end+7bb530/3fe2a6a0>
> > > >>$30; 809afe90 <_end+7bb530/3fe2a6a0>
> > > >>$31; 8001524c <schedule+33c/47c>
> > >
> > > >>PC;  8001524c <schedule+33c/47c>   <=====
> > >
> > > Trace; 8016eda8 <mips_io_port_base+d08/1c30>
> > > Trace; 8016edc0 <mips_io_port_base+d20/1c30>
> > > Trace; 80014e74 <schedule_timeout+74/e4>
> > > Trace; 80014e6c <schedule_timeout+6c/e4>
> > > Trace; c008422b <[bcm7030]scard_interrupt+f/340>
> > > Trace; 80014dd4 <process_timeout+0/2c>
> > > Trace; 8002242c <sys_nanosleep+170/1fc>
> > > Trace; 8016c290 <mips_hwi4_dispatch+70/78>
> > > Trace; 8000f7c4 <stack_done+1c/38>
> > > Trace; 8000f7c4 <stack_done+1c/38>
> > >
> > > Code;  80015240 <schedule+330/47c>
> > > 00000000 <_PC>:
> > > Code;  80015240 <schedule+330/47c>
> > >    0:   24a5edc0  addiu   a1,a1,-4672
> > > Code;  80015244 <schedule+334/47c>
> > >    4:   0c0062f7  jal     18bdc <_PC+0x18bdc> 8002de1c
> > > <generic_file_direct_IO+294/2d8>
> > > Code;  80015248 <schedule+338/47c>
> > >    8:   24060310  li      a2,784
> > > Code;  8001524c <schedule+33c/47c>   <=====
> > >    c:   08005485  j       15214 <_PC+0x15214> 8002a454
> > <__vma_link+9c/e0>
> > > <=====
> > > Code;  80015250 <schedule+340/47c>
> > >   10:   ae200000  sw      zero,0(s1)
> > > Code;  80015254 <schedule+344/47c>
> > >   14:   40016000  mfc0    at,$12
> > > Code;  80015258 <schedule+348/47c>
> > >   18:   00000000  nop
> > > Code;  8001525c <schedule+34c/47c>
> > >   1c:   3421001f  ori     at,at,0x1f
> > > Code;  80015260 <schedule+350/47c>
> > >   20:   3821001e  xori    at,at,0x1e
> > >
> > >
> > > Jack Miller <jack.miller@pioneer-pdt.com>
> > > Pioneer Digital Technologies, Inc.
> > > 6170 Cornerstone Court East
> > > Suite 330
> > > San Diego, CA 92121-3767
> > > vox: (858)824-0790 x356
> > > fax: (858)824-0796
> > >
> > >
> >
> 

From jack.miller@pioneer-pdt.com Fri Jul 18 18:48:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 18:48:33 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:63442
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225201AbTGRRsa>; Fri, 18 Jul 2003 18:48:30 +0100
Received: from LEDA ([172.30.2.15]) by ns.pioneer-pdt.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68491U100L2S100V35)
          with SMTP id com; Fri, 18 Jul 2003 10:51:14 -0700
From: jack.miller@pioneer-pdt.com (Jack Miller)
To: "Jun Sun" <jsun@mvista.com>
Cc: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: RE: kernel BUG at sched.c:784!
Date: Fri, 18 Jul 2003 10:48:22 -0700
Message-ID: <JCELLCFDJLFKPOBFKGFNIEKLCFAA.jack.miller@pioneer-pdt.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <20030718104444.E31523@mvista.com>
Return-Path: <jack.miller@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: 2824
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jack.miller@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips

  Jun,
   Here is the excerpt from sched.c:

	prepare_to_switch();
	{
		struct mm_struct *mm = next->mm;
		struct mm_struct *oldmm = prev->active_mm;
		if (!mm) {
784			if (next->active_mm) BUG();
			next->active_mm = oldmm;
			atomic_inc(&oldmm->mm_count);
			enter_lazy_tlb(oldmm, next, this_cpu);

  Jack


> -----Original Message-----
> From: Jun Sun [mailto:jsun@mvista.com]
> Sent: Friday, July 18, 2003 10:45 AM
> To: Jack Miller
> Cc: Linux-Mips; jsun@mvista.com
> Subject: Re: kernel BUG at sched.c:784!
> 
> 
> On Fri, Jul 18, 2003 at 10:26:59AM -0700, Jack Miller wrote:
> >   Jun,
> >    Thanks for your response.  Our kernel is actually based upon the
> > MontaVista kernel and that workaround is in place.
> > 
> >   Jack
> >
> 
> Which line is 784?  There is another cpu bug which might cause this.
> 
> I checked our sherman source tree and did not find the corresponding
> line.
> 
> Jun
>  
> > > -----Original Message-----
> > > From: linux-mips-bounce@linux-mips.org
> > > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> > > Sent: Friday, July 18, 2003 10:23 AM
> > > To: Jack Miller
> > > Cc: Linux-Mips; jsun@mvista.com
> > > Subject: Re: kernel BUG at sched.c:784!
> > >
> > >
> > >
> > > Your kernel looks old, and probably don't have the CPU bug workaround
> > > code at the beginning of vec3 exception handler.
> > >
> > > NESTED(except_vec3_generic, 0, sp)
> > > #if R5432_CP0_INTERRUPT_WAR
> > >                 mfc0    k0, CP0_INDEX
> > > #endif
> > >
> > > Try this.
> > >
> > > Jun
> > >
> > > On Fri, Jul 18, 2003 at 09:57:01AM -0700, Jack Miller wrote:
> > > >   We are developing a system based around a NEC VR5432 CPU 
> and Broadcom
> > > > BCM703X System Controller. When the system is running with 
> the intended
> > > > application and drivers we intermittently experience a kernel
> > > OOPS in the
> > > > scheduler.  Would someone please provide some insight to the
> > > following OOPS
> > > > ?  It appears (with my limited understanding of the 
> scheduler) that the
> > > > scheduler is trying to schedule the 'idle' task.  What
> > > condition prevails to
> > > > cause this to happen ?
> > > >
> > > >   Using a J-TAG Debugger, I "walked" the task list (in both
> > > directions) and
> > > > everthing appears to be in order.
> > > >
> > > >   Thanks in advance for your help.
> > > >
> > > >   Regards,
> > > >     Jack
> > > >
> > > >
> > > > Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 
> 20030322 (Pioneer
> > > > Voyager)) #1 Fri May 30 14:55:32 PDT 2003
> > > > ksymoops 2.4.6 on mips 2.4.17.  Options used
> > > >      -v vmlinux (specified)
> > > >      -k /proc/ksyms (default)
> > > >      -l /proc/modules (default)
> > > >      -o /lib/modules/2.4.17/ (default)
> > > >      -m System.map (specified)
> > > >      -T 32
> > > >
> > > > root@stb2073:~# kernel BUG at sched.c:784!
> > > > Unable to handle kernel paging request at virtual address
> > > 00000000, epc ==
> > > > 8001524c, ra == 8001524c
> > > > $0 : 00000000 b001f800 0000001b 00000000 ffffff9d 80008000
> > > 0000001f 828f4a20
> > > > $8 : 00000001 ffffd890 00001890 801cb119 00000000 00000000
> > > fffffff9 ffffffff
> > > > $16: 00000000 00000000 809ae000 828f4a20 80008000 00000000
> > > 80008000 1001ccf8
> > > > $24: 0000000a 00000002                   809ae000 809afe90
> > > 809afe90 8001524c
> > > > epc  : 8001524c    Tainted: P
> > > > Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
> > > > Status: b001f803
> > > > Cause : 8000c40c
> > > > Process pvrd (pid: 331, stackpage=809ae000)
> > > > Stack: 8016eda8 8016edc0 00000310 fffffc18 00138f80 
> 00000002 809afed8
> > > > 00000070
> > > >        00000000 1001cd00 1001ccfc 809afec8 80014e74 
> 80014e6c 00000400
> > > > 00000200
> > > >        c008422b 80bd4160 00000000 00000000 00138f80 
> 809ae000 80014dd4
> > > > 2aac2000
> > > >        00000000 809aff18 00001807 7edffa50 8002242c 
> 00000070 00000000
> > > > 8016c290
> > > >        00000000 00000000 00000000 00989680 7edffa40 
> 00000000 8000f7c4
> > > > 8000f7c4
> > > >        00000000 ...
> > > > Call Trace: [<8016eda8>] [<8016edc0>] [<80014e74>] [<80014e6c>]
> > > [<c008422b>]
> > > > [<80014dd4>]
> > > >  [<8002242c>] [<8016c290>] [<8000f7c4>] [<8000f7c4>]
> > > > Code: 24a5edc0  0c0062f7  24060310 <08005485> ae200000
> > > 40016000  00000000
> > > > 3421001f  3821001e
> > > >
> > > >
> > > > >>RA;  8001524c <schedule+33c/47c>
> > > > >>$1; b001f800 <_end+2fe2aea0/3fe2a6a0>
> > > > >>$5; 80008000 <init_task_union+0/0>
> > > > >>$7; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > > >>$11; 801cb119 <printk_buf.4+19/400>
> > > > >>$18; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > > >>$19; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > > >>$20; 80008000 <init_task_union+0/0>
> > > > >>$22; 80008000 <init_task_union+0/0>
> > > > >>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
> > > > >>$28; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > > >>$29; 809afe90 <_end+7bb530/3fe2a6a0>
> > > > >>$30; 809afe90 <_end+7bb530/3fe2a6a0>
> > > > >>$31; 8001524c <schedule+33c/47c>
> > > >
> > > > >>PC;  8001524c <schedule+33c/47c>   <=====
> > > >
> > > > Trace; 8016eda8 <mips_io_port_base+d08/1c30>
> > > > Trace; 8016edc0 <mips_io_port_base+d20/1c30>
> > > > Trace; 80014e74 <schedule_timeout+74/e4>
> > > > Trace; 80014e6c <schedule_timeout+6c/e4>
> > > > Trace; c008422b <[bcm7030]scard_interrupt+f/340>
> > > > Trace; 80014dd4 <process_timeout+0/2c>
> > > > Trace; 8002242c <sys_nanosleep+170/1fc>
> > > > Trace; 8016c290 <mips_hwi4_dispatch+70/78>
> > > > Trace; 8000f7c4 <stack_done+1c/38>
> > > > Trace; 8000f7c4 <stack_done+1c/38>
> > > >
> > > > Code;  80015240 <schedule+330/47c>
> > > > 00000000 <_PC>:
> > > > Code;  80015240 <schedule+330/47c>
> > > >    0:   24a5edc0  addiu   a1,a1,-4672
> > > > Code;  80015244 <schedule+334/47c>
> > > >    4:   0c0062f7  jal     18bdc <_PC+0x18bdc> 8002de1c
> > > > <generic_file_direct_IO+294/2d8>
> > > > Code;  80015248 <schedule+338/47c>
> > > >    8:   24060310  li      a2,784
> > > > Code;  8001524c <schedule+33c/47c>   <=====
> > > >    c:   08005485  j       15214 <_PC+0x15214> 8002a454
> > > <__vma_link+9c/e0>
> > > > <=====
> > > > Code;  80015250 <schedule+340/47c>
> > > >   10:   ae200000  sw      zero,0(s1)
> > > > Code;  80015254 <schedule+344/47c>
> > > >   14:   40016000  mfc0    at,$12
> > > > Code;  80015258 <schedule+348/47c>
> > > >   18:   00000000  nop
> > > > Code;  8001525c <schedule+34c/47c>
> > > >   1c:   3421001f  ori     at,at,0x1f
> > > > Code;  80015260 <schedule+350/47c>
> > > >   20:   3821001e  xori    at,at,0x1e
> > > >
> > > >
> > > > Jack Miller <jack.miller@pioneer-pdt.com>
> > > > Pioneer Digital Technologies, Inc.
> > > > 6170 Cornerstone Court East
> > > > Suite 330
> > > > San Diego, CA 92121-3767
> > > > vox: (858)824-0790 x356
> > > > fax: (858)824-0796
> > > >
> > > >
> > >
> > 
> 

From jsun@mvista.com Fri Jul 18 19:29:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 19:29:47 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:28920 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225255AbTGRS3p>;
	Fri, 18 Jul 2003 19:29:45 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6IITgM32275;
	Fri, 18 Jul 2003 11:29:42 -0700
Date: Fri, 18 Jul 2003 11:29:42 -0700
From: Jun Sun <jsun@mvista.com>
To: Jack Miller <jack.miller@pioneer-pdt.com>
Cc: Linux-Mips <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: kernel BUG at sched.c:784!
Message-ID: <20030718112942.G31523@mvista.com>
References: <20030718104444.E31523@mvista.com> <JCELLCFDJLFKPOBFKGFNIEKLCFAA.jack.miller@pioneer-pdt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <JCELLCFDJLFKPOBFKGFNIEKLCFAA.jack.miller@pioneer-pdt.com>; from jack.miller@pioneer-pdt.com on Fri, Jul 18, 2003 at 10:48:22AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2825
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jul 18, 2003 at 10:48:22AM -0700, Jack Miller wrote:
>   Jun,
>    Here is the excerpt from sched.c:
> 
> 	prepare_to_switch();
> 	{
> 		struct mm_struct *mm = next->mm;
> 		struct mm_struct *oldmm = prev->active_mm;
> 		if (!mm) {
> 784			if (next->active_mm) BUG();
> 			next->active_mm = oldmm;
> 			atomic_inc(&oldmm->mm_count);
> 			enter_lazy_tlb(oldmm, next, this_cpu);
> 
>   Jack
>

Jack,

Plese change that line to 
			if (next->active_mm) {
				printk("active_mm = %p\n", next->active_mm);
				BUG();
			}

If you see next->active_mm to be NULL, you are seeing the CPU bug.

However, given the frequency you are seeing the problem, I suspect it
is something else.

Whenever CPU runs out active processes to run, it will switch to idle
process, which does not have a mm.  The BUG() basically says "last time
when idle process was switched off, its active_mm pointer should be set
NULL".  The dropping active_mm code is shortly after the above chunk.

Jun

> > -----Original Message-----
> > From: Jun Sun [mailto:jsun@mvista.com]
> > Sent: Friday, July 18, 2003 10:45 AM
> > To: Jack Miller
> > Cc: Linux-Mips; jsun@mvista.com
> > Subject: Re: kernel BUG at sched.c:784!
> > 
> > 
> > On Fri, Jul 18, 2003 at 10:26:59AM -0700, Jack Miller wrote:
> > >   Jun,
> > >    Thanks for your response.  Our kernel is actually based upon the
> > > MontaVista kernel and that workaround is in place.
> > > 
> > >   Jack
> > >
> > 
> > Which line is 784?  There is another cpu bug which might cause this.
> > 
> > I checked our sherman source tree and did not find the corresponding
> > line.
> > 
> > Jun
> >  
> > > > -----Original Message-----
> > > > From: linux-mips-bounce@linux-mips.org
> > > > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> > > > Sent: Friday, July 18, 2003 10:23 AM
> > > > To: Jack Miller
> > > > Cc: Linux-Mips; jsun@mvista.com
> > > > Subject: Re: kernel BUG at sched.c:784!
> > > >
> > > >
> > > >
> > > > Your kernel looks old, and probably don't have the CPU bug workaround
> > > > code at the beginning of vec3 exception handler.
> > > >
> > > > NESTED(except_vec3_generic, 0, sp)
> > > > #if R5432_CP0_INTERRUPT_WAR
> > > >                 mfc0    k0, CP0_INDEX
> > > > #endif
> > > >
> > > > Try this.
> > > >
> > > > Jun
> > > >
> > > > On Fri, Jul 18, 2003 at 09:57:01AM -0700, Jack Miller wrote:
> > > > >   We are developing a system based around a NEC VR5432 CPU 
> > and Broadcom
> > > > > BCM703X System Controller. When the system is running with 
> > the intended
> > > > > application and drivers we intermittently experience a kernel
> > > > OOPS in the
> > > > > scheduler.  Would someone please provide some insight to the
> > > > following OOPS
> > > > > ?  It appears (with my limited understanding of the 
> > scheduler) that the
> > > > > scheduler is trying to schedule the 'idle' task.  What
> > > > condition prevails to
> > > > > cause this to happen ?
> > > > >
> > > > >   Using a J-TAG Debugger, I "walked" the task list (in both
> > > > directions) and
> > > > > everthing appears to be in order.
> > > > >
> > > > >   Thanks in advance for your help.
> > > > >
> > > > >   Regards,
> > > > >     Jack
> > > > >
> > > > >
> > > > > Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 
> > 20030322 (Pioneer
> > > > > Voyager)) #1 Fri May 30 14:55:32 PDT 2003
> > > > > ksymoops 2.4.6 on mips 2.4.17.  Options used
> > > > >      -v vmlinux (specified)
> > > > >      -k /proc/ksyms (default)
> > > > >      -l /proc/modules (default)
> > > > >      -o /lib/modules/2.4.17/ (default)
> > > > >      -m System.map (specified)
> > > > >      -T 32
> > > > >
> > > > > root@stb2073:~# kernel BUG at sched.c:784!
> > > > > Unable to handle kernel paging request at virtual address
> > > > 00000000, epc ==
> > > > > 8001524c, ra == 8001524c
> > > > > $0 : 00000000 b001f800 0000001b 00000000 ffffff9d 80008000
> > > > 0000001f 828f4a20
> > > > > $8 : 00000001 ffffd890 00001890 801cb119 00000000 00000000
> > > > fffffff9 ffffffff
> > > > > $16: 00000000 00000000 809ae000 828f4a20 80008000 00000000
> > > > 80008000 1001ccf8
> > > > > $24: 0000000a 00000002                   809ae000 809afe90
> > > > 809afe90 8001524c
> > > > > epc  : 8001524c    Tainted: P
> > > > > Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
> > > > > Status: b001f803
> > > > > Cause : 8000c40c
> > > > > Process pvrd (pid: 331, stackpage=809ae000)
> > > > > Stack: 8016eda8 8016edc0 00000310 fffffc18 00138f80 
> > 00000002 809afed8
> > > > > 00000070
> > > > >        00000000 1001cd00 1001ccfc 809afec8 80014e74 
> > 80014e6c 00000400
> > > > > 00000200
> > > > >        c008422b 80bd4160 00000000 00000000 00138f80 
> > 809ae000 80014dd4
> > > > > 2aac2000
> > > > >        00000000 809aff18 00001807 7edffa50 8002242c 
> > 00000070 00000000
> > > > > 8016c290
> > > > >        00000000 00000000 00000000 00989680 7edffa40 
> > 00000000 8000f7c4
> > > > > 8000f7c4
> > > > >        00000000 ...
> > > > > Call Trace: [<8016eda8>] [<8016edc0>] [<80014e74>] [<80014e6c>]
> > > > [<c008422b>]
> > > > > [<80014dd4>]
> > > > >  [<8002242c>] [<8016c290>] [<8000f7c4>] [<8000f7c4>]
> > > > > Code: 24a5edc0  0c0062f7  24060310 <08005485> ae200000
> > > > 40016000  00000000
> > > > > 3421001f  3821001e
> > > > >
> > > > >
> > > > > >>RA;  8001524c <schedule+33c/47c>
> > > > > >>$1; b001f800 <_end+2fe2aea0/3fe2a6a0>
> > > > > >>$5; 80008000 <init_task_union+0/0>
> > > > > >>$7; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > > > >>$11; 801cb119 <printk_buf.4+19/400>
> > > > > >>$18; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > > > >>$19; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > > > >>$20; 80008000 <init_task_union+0/0>
> > > > > >>$22; 80008000 <init_task_union+0/0>
> > > > > >>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
> > > > > >>$28; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > > > >>$29; 809afe90 <_end+7bb530/3fe2a6a0>
> > > > > >>$30; 809afe90 <_end+7bb530/3fe2a6a0>
> > > > > >>$31; 8001524c <schedule+33c/47c>
> > > > >
> > > > > >>PC;  8001524c <schedule+33c/47c>   <=====
> > > > >
> > > > > Trace; 8016eda8 <mips_io_port_base+d08/1c30>
> > > > > Trace; 8016edc0 <mips_io_port_base+d20/1c30>
> > > > > Trace; 80014e74 <schedule_timeout+74/e4>
> > > > > Trace; 80014e6c <schedule_timeout+6c/e4>
> > > > > Trace; c008422b <[bcm7030]scard_interrupt+f/340>
> > > > > Trace; 80014dd4 <process_timeout+0/2c>
> > > > > Trace; 8002242c <sys_nanosleep+170/1fc>
> > > > > Trace; 8016c290 <mips_hwi4_dispatch+70/78>
> > > > > Trace; 8000f7c4 <stack_done+1c/38>
> > > > > Trace; 8000f7c4 <stack_done+1c/38>
> > > > >
> > > > > Code;  80015240 <schedule+330/47c>
> > > > > 00000000 <_PC>:
> > > > > Code;  80015240 <schedule+330/47c>
> > > > >    0:   24a5edc0  addiu   a1,a1,-4672
> > > > > Code;  80015244 <schedule+334/47c>
> > > > >    4:   0c0062f7  jal     18bdc <_PC+0x18bdc> 8002de1c
> > > > > <generic_file_direct_IO+294/2d8>
> > > > > Code;  80015248 <schedule+338/47c>
> > > > >    8:   24060310  li      a2,784
> > > > > Code;  8001524c <schedule+33c/47c>   <=====
> > > > >    c:   08005485  j       15214 <_PC+0x15214> 8002a454
> > > > <__vma_link+9c/e0>
> > > > > <=====
> > > > > Code;  80015250 <schedule+340/47c>
> > > > >   10:   ae200000  sw      zero,0(s1)
> > > > > Code;  80015254 <schedule+344/47c>
> > > > >   14:   40016000  mfc0    at,$12
> > > > > Code;  80015258 <schedule+348/47c>
> > > > >   18:   00000000  nop
> > > > > Code;  8001525c <schedule+34c/47c>
> > > > >   1c:   3421001f  ori     at,at,0x1f
> > > > > Code;  80015260 <schedule+350/47c>
> > > > >   20:   3821001e  xori    at,at,0x1e
> > > > >
> > > > >
> > > > > Jack Miller <jack.miller@pioneer-pdt.com>
> > > > > Pioneer Digital Technologies, Inc.
> > > > > 6170 Cornerstone Court East
> > > > > Suite 330
> > > > > San Diego, CA 92121-3767
> > > > > vox: (858)824-0790 x356
> > > > > fax: (858)824-0796
> > > > >
> > > > >
> > > >
> > > 
> > 
> 

From jack.miller@pioneer-pdt.com Fri Jul 18 19:48:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 19:48:55 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:47096
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225255AbTGRSsx>; Fri, 18 Jul 2003 19:48:53 +0100
Received: from LEDA ([172.30.2.15]) by ns.pioneer-pdt.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68491U100L2S100V35)
          with SMTP id com; Fri, 18 Jul 2003 11:51:36 -0700
From: jack.miller@pioneer-pdt.com (Jack Miller)
To: "Jun Sun" <jsun@mvista.com>
Cc: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: RE: kernel BUG at sched.c:784!
Date: Fri, 18 Jul 2003 11:48:44 -0700
Message-ID: <JCELLCFDJLFKPOBFKGFNCEKNCFAA.jack.miller@pioneer-pdt.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <20030718112942.G31523@mvista.com>
Return-Path: <jack.miller@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: 2826
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jack.miller@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips

  Jun,

    Thanks alot.  ' Will implement the prescribed debugging code and see
what it yields...

  Jack

> -----Original Message-----
> From: Jun Sun [mailto:jsun@mvista.com]
> Sent: Friday, July 18, 2003 11:30 AM
> To: Jack Miller
> Cc: Linux-Mips; jsun@mvista.com
> Subject: Re: kernel BUG at sched.c:784!
>
>
> On Fri, Jul 18, 2003 at 10:48:22AM -0700, Jack Miller wrote:
> >   Jun,
> >    Here is the excerpt from sched.c:
> >
> > 	prepare_to_switch();
> > 	{
> > 		struct mm_struct *mm = next->mm;
> > 		struct mm_struct *oldmm = prev->active_mm;
> > 		if (!mm) {
> > 784			if (next->active_mm) BUG();
> > 			next->active_mm = oldmm;
> > 			atomic_inc(&oldmm->mm_count);
> > 			enter_lazy_tlb(oldmm, next, this_cpu);
> >
> >   Jack
> >
>
> Jack,
>
> Plese change that line to
> 			if (next->active_mm) {
> 				printk("active_mm = %p\n", next->active_mm);
> 				BUG();
> 			}
>
> If you see next->active_mm to be NULL, you are seeing the CPU bug.
>
> However, given the frequency you are seeing the problem, I suspect it
> is something else.
>
> Whenever CPU runs out active processes to run, it will switch to idle
> process, which does not have a mm.  The BUG() basically says "last time
> when idle process was switched off, its active_mm pointer should be set
> NULL".  The dropping active_mm code is shortly after the above chunk.
>
> Jun
>
> > > -----Original Message-----
> > > From: Jun Sun [mailto:jsun@mvista.com]
> > > Sent: Friday, July 18, 2003 10:45 AM
> > > To: Jack Miller
> > > Cc: Linux-Mips; jsun@mvista.com
> > > Subject: Re: kernel BUG at sched.c:784!
> > >
> > >
> > > On Fri, Jul 18, 2003 at 10:26:59AM -0700, Jack Miller wrote:
> > > >   Jun,
> > > >    Thanks for your response.  Our kernel is actually based upon the
> > > > MontaVista kernel and that workaround is in place.
> > > >
> > > >   Jack
> > > >
> > >
> > > Which line is 784?  There is another cpu bug which might cause this.
> > >
> > > I checked our sherman source tree and did not find the corresponding
> > > line.
> > >
> > > Jun
> > >
> > > > > -----Original Message-----
> > > > > From: linux-mips-bounce@linux-mips.org
> > > > > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> > > > > Sent: Friday, July 18, 2003 10:23 AM
> > > > > To: Jack Miller
> > > > > Cc: Linux-Mips; jsun@mvista.com
> > > > > Subject: Re: kernel BUG at sched.c:784!
> > > > >
> > > > >
> > > > >
> > > > > Your kernel looks old, and probably don't have the CPU
> bug workaround
> > > > > code at the beginning of vec3 exception handler.
> > > > >
> > > > > NESTED(except_vec3_generic, 0, sp)
> > > > > #if R5432_CP0_INTERRUPT_WAR
> > > > >                 mfc0    k0, CP0_INDEX
> > > > > #endif
> > > > >
> > > > > Try this.
> > > > >
> > > > > Jun
> > > > >
> > > > > On Fri, Jul 18, 2003 at 09:57:01AM -0700, Jack Miller wrote:
> > > > > >   We are developing a system based around a NEC VR5432 CPU
> > > and Broadcom
> > > > > > BCM703X System Controller. When the system is running with
> > > the intended
> > > > > > application and drivers we intermittently experience a kernel
> > > > > OOPS in the
> > > > > > scheduler.  Would someone please provide some insight to the
> > > > > following OOPS
> > > > > > ?  It appears (with my limited understanding of the
> > > scheduler) that the
> > > > > > scheduler is trying to schedule the 'idle' task.  What
> > > > > condition prevails to
> > > > > > cause this to happen ?
> > > > > >
> > > > > >   Using a J-TAG Debugger, I "walked" the task list (in both
> > > > > directions) and
> > > > > > everthing appears to be in order.
> > > > > >
> > > > > >   Thanks in advance for your help.
> > > > > >
> > > > > >   Regards,
> > > > > >     Jack
> > > > > >
> > > > > >
> > > > > > Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2
> > > 20030322 (Pioneer
> > > > > > Voyager)) #1 Fri May 30 14:55:32 PDT 2003
> > > > > > ksymoops 2.4.6 on mips 2.4.17.  Options used
> > > > > >      -v vmlinux (specified)
> > > > > >      -k /proc/ksyms (default)
> > > > > >      -l /proc/modules (default)
> > > > > >      -o /lib/modules/2.4.17/ (default)
> > > > > >      -m System.map (specified)
> > > > > >      -T 32
> > > > > >
> > > > > > root@stb2073:~# kernel BUG at sched.c:784!
> > > > > > Unable to handle kernel paging request at virtual address
> > > > > 00000000, epc ==
> > > > > > 8001524c, ra == 8001524c
> > > > > > $0 : 00000000 b001f800 0000001b 00000000 ffffff9d 80008000
> > > > > 0000001f 828f4a20
> > > > > > $8 : 00000001 ffffd890 00001890 801cb119 00000000 00000000
> > > > > fffffff9 ffffffff
> > > > > > $16: 00000000 00000000 809ae000 828f4a20 80008000 00000000
> > > > > 80008000 1001ccf8
> > > > > > $24: 0000000a 00000002                   809ae000 809afe90
> > > > > 809afe90 8001524c
> > > > > > epc  : 8001524c    Tainted: P
> > > > > > Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
> > > > > > Status: b001f803
> > > > > > Cause : 8000c40c
> > > > > > Process pvrd (pid: 331, stackpage=809ae000)
> > > > > > Stack: 8016eda8 8016edc0 00000310 fffffc18 00138f80
> > > 00000002 809afed8
> > > > > > 00000070
> > > > > >        00000000 1001cd00 1001ccfc 809afec8 80014e74
> > > 80014e6c 00000400
> > > > > > 00000200
> > > > > >        c008422b 80bd4160 00000000 00000000 00138f80
> > > 809ae000 80014dd4
> > > > > > 2aac2000
> > > > > >        00000000 809aff18 00001807 7edffa50 8002242c
> > > 00000070 00000000
> > > > > > 8016c290
> > > > > >        00000000 00000000 00000000 00989680 7edffa40
> > > 00000000 8000f7c4
> > > > > > 8000f7c4
> > > > > >        00000000 ...
> > > > > > Call Trace: [<8016eda8>] [<8016edc0>] [<80014e74>] [<80014e6c>]
> > > > > [<c008422b>]
> > > > > > [<80014dd4>]
> > > > > >  [<8002242c>] [<8016c290>] [<8000f7c4>] [<8000f7c4>]
> > > > > > Code: 24a5edc0  0c0062f7  24060310 <08005485> ae200000
> > > > > 40016000  00000000
> > > > > > 3421001f  3821001e
> > > > > >
> > > > > >
> > > > > > >>RA;  8001524c <schedule+33c/47c>
> > > > > > >>$1; b001f800 <_end+2fe2aea0/3fe2a6a0>
> > > > > > >>$5; 80008000 <init_task_union+0/0>
> > > > > > >>$7; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > > > > >>$11; 801cb119 <printk_buf.4+19/400>
> > > > > > >>$18; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > > > > >>$19; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > > > > >>$20; 80008000 <init_task_union+0/0>
> > > > > > >>$22; 80008000 <init_task_union+0/0>
> > > > > > >>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
> > > > > > >>$28; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > > > > >>$29; 809afe90 <_end+7bb530/3fe2a6a0>
> > > > > > >>$30; 809afe90 <_end+7bb530/3fe2a6a0>
> > > > > > >>$31; 8001524c <schedule+33c/47c>
> > > > > >
> > > > > > >>PC;  8001524c <schedule+33c/47c>   <=====
> > > > > >
> > > > > > Trace; 8016eda8 <mips_io_port_base+d08/1c30>
> > > > > > Trace; 8016edc0 <mips_io_port_base+d20/1c30>
> > > > > > Trace; 80014e74 <schedule_timeout+74/e4>
> > > > > > Trace; 80014e6c <schedule_timeout+6c/e4>
> > > > > > Trace; c008422b <[bcm7030]scard_interrupt+f/340>
> > > > > > Trace; 80014dd4 <process_timeout+0/2c>
> > > > > > Trace; 8002242c <sys_nanosleep+170/1fc>
> > > > > > Trace; 8016c290 <mips_hwi4_dispatch+70/78>
> > > > > > Trace; 8000f7c4 <stack_done+1c/38>
> > > > > > Trace; 8000f7c4 <stack_done+1c/38>
> > > > > >
> > > > > > Code;  80015240 <schedule+330/47c>
> > > > > > 00000000 <_PC>:
> > > > > > Code;  80015240 <schedule+330/47c>
> > > > > >    0:   24a5edc0  addiu   a1,a1,-4672
> > > > > > Code;  80015244 <schedule+334/47c>
> > > > > >    4:   0c0062f7  jal     18bdc <_PC+0x18bdc> 8002de1c
> > > > > > <generic_file_direct_IO+294/2d8>
> > > > > > Code;  80015248 <schedule+338/47c>
> > > > > >    8:   24060310  li      a2,784
> > > > > > Code;  8001524c <schedule+33c/47c>   <=====
> > > > > >    c:   08005485  j       15214 <_PC+0x15214> 8002a454
> > > > > <__vma_link+9c/e0>
> > > > > > <=====
> > > > > > Code;  80015250 <schedule+340/47c>
> > > > > >   10:   ae200000  sw      zero,0(s1)
> > > > > > Code;  80015254 <schedule+344/47c>
> > > > > >   14:   40016000  mfc0    at,$12
> > > > > > Code;  80015258 <schedule+348/47c>
> > > > > >   18:   00000000  nop
> > > > > > Code;  8001525c <schedule+34c/47c>
> > > > > >   1c:   3421001f  ori     at,at,0x1f
> > > > > > Code;  80015260 <schedule+350/47c>
> > > > > >   20:   3821001e  xori    at,at,0x1e
> > > > > >
> > > > > >
> > > > > > Jack Miller <jack.miller@pioneer-pdt.com>
> > > > > > Pioneer Digital Technologies, Inc.
> > > > > > 6170 Cornerstone Court East
> > > > > > Suite 330
> > > > > > San Diego, CA 92121-3767
> > > > > > vox: (858)824-0790 x356
> > > > > > fax: (858)824-0796
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


From jack.miller@pioneer-pdt.com Fri Jul 18 23:51:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 23:51:37 +0100 (BST)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:37340
	"EHLO ns.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225255AbTGRWvf>; Fri, 18 Jul 2003 23:51:35 +0100
Received: from LEDA ([172.30.2.15]) by ns.pioneer-pdt.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-68491U100L2S100V35)
          with SMTP id com; Fri, 18 Jul 2003 15:54:19 -0700
From: jack.miller@pioneer-pdt.com (Jack Miller)
To: "Jun Sun" <jsun@mvista.com>
Cc: "Linux-Mips" <linux-mips@linux-mips.org>
Subject: RE: kernel BUG at sched.c:784!
Date: Fri, 18 Jul 2003 15:51:25 -0700
Message-ID: <JCELLCFDJLFKPOBFKGFNAEKOCFAA.jack.miller@pioneer-pdt.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <20030718112942.G31523@mvista.com>
Return-Path: <jack.miller@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: 2827
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jack.miller@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips

  Jun,
    ' Got the BUG() again after about 5 hours of operation.  The BUG()
report is below.  Any additional insight you can provide is greatly
appreciated.  Thanks again for your help.

  Jack

Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 20030612 (Pioneer
Voyager)) #5 Fri Jul 18 12:51:00 PDT 2003

active_mm = 83f02b20

ksymoops 2.4.6 on mips 2.4.17.  Options used
     -v vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.17/ (default)
     -m System.map (specified)
     -T 32

kernel BUG at sched.c:786!
Unable to handle kernel paging request at virtual address 00000000, epc ==
80014c18, ra == 80014c18
$0 : 00000000 b001f800 0000001b 00000001 83a6a000 00000000 00000001 0000144d
$8 : 0000144d ffffd44d 0000144d 00000000 00000000 00000000 801d1119 fffffff9
$16: 00000000 00000000 80b5a000 83f02b20 80008000 00000000 80008000 1001ccf8
$24: 0000000a 80b5bb52                   80b5a000 80b5bc80 80b5bc80 80014c18
epc  : 80014c18    Tainted: P
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
Status: b001f803
Cause : 8000040c
Process pvrd (pid: 232, stackpage=80b5a000)
Stack: 80174bd8 80174bf0 00000312 83f02b20 00000001 7fffffff 83f14d40
00000000
       00000002 80b5be84 80b5bda0 80b5bcb8 8001489c 00000002 00000001
c0052dd8
       01f8a120 00000001 83c349a0 00000001 c0106008 00000001 00000000
00000001
       00000001 7fffffff 83f14d40 7dfff820 c002071c c0105ff4 a1f8a120
80b5be80
       80b5bd08 00000001 00000000 80b5a000 83f14d40 83f14d40 0000009c
00000001
       c0105f30 ...
Call Trace: [<80174bd8>] [<80174bf0>] [<8001489c>] [<c0052dd8>] [<c0106008>]
[<c002071c>]
 [<c0105ff4>] [<c0105f30>] [<c0078798>] [<c01192fc>] [<c01192fc>]
[<c00781e0>]
 [<800e892c>] [<c01192fc>] [<c0072264>] [<c0072394>] [<c01192fc>]
[<c0073984>]
 [<c01562f0>] [<c0155000>] [<c0157228>] [<80057ab0>] [<800de4ec>]
[<c01552f0>]
 [<c0155000>] [<80041e14>] [<80041cd4>] [<c015521c>] [<80028934>]
[<800d5d50>]
 [<c015621c>] [<c0155000>] [<80014834>] [<800d59a0>] [<c008422d>]
[<c00494ac>]
 [<8004e808>] [<8004e814>] [<8000f0e4>] [<c008422d>]
Code: 24a54bf0  0c0061b9  24060312 <080052f5> ae200000  40016000  00000000
3421001f  3821001e


>>RA;  80014c18 <schedule+348/488>
>>$1; b001f800 <_end+2fe24ea0/3fe246a0>
>>$4; 83a6a000 <_end+386f6a0/3fe246a0>
>>$14; 801d1119 <printk_buf.1+19/400>
>>$18; 80b5a000 <_end+95f6a0/3fe246a0>
>>$19; 83f02b20 <_end+3d081c0/3fe246a0>
>>$20; 80008000 <init_task_union+0/0>
>>$22; 80008000 <init_task_union+0/0>
>>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
>>$25; 80b5bb52 <_end+9611f2/3fe246a0>
>>$28; 80b5a000 <_end+95f6a0/3fe246a0>
>>$29; 80b5bc80 <_end+961320/3fe246a0>
>>$30; 80b5bc80 <_end+961320/3fe246a0>
>>$31; 80014c18 <schedule+348/488>

>>PC;  80014c18 <schedule+348/488>   <=====

Trace; 80174bd8 <mips_io_port_base+cf8/1c30>
Trace; 80174bf0 <mips_io_port_base+d10/1c30>
Trace; 8001489c <schedule_timeout+dc/e4>
Trace; c0052dd8 <[bcm7030]TransPvrAddBuffer+1b0/55c>
Trace; c0106008 <[bcm7030]gPvrPlaybackVars+d8/1e0>
Trace; c002071c <[pdtutil]pdtKNIWaitForEvent+e8/114>
Trace; c0105ff4 <[bcm7030]gPvrPlaybackVars+c4/1e0>
Trace; c0105f30 <[bcm7030]gPvrPlaybackVars+0/1e0>
Trace; c0078798 <[bcm7030]pvr_playbackWaitForFreeDescriptor+94/240>
Trace; c01192fc <[bcm7030]glNoiseLevels+c5c/1eaf>
Trace; c01192fc <[bcm7030]glNoiseLevels+c5c/1eaf>
Trace; c00781e0 <[bcm7030]pvr_playbackAddDataRequest+2f4/34c>
Trace; 800e892c <ide_do_request+1c0/3d0>
Trace; c01192fc <[bcm7030]glNoiseLevels+c5c/1eaf>
Trace; c0072264 <[bcm7030]brcm_play_getbuffer+3c/60>
Trace; c0072394 <[bcm7030]brcm_play_feeddata+10c/114>
Trace; c01192fc <[bcm7030]glNoiseLevels+c5c/1eaf>
Trace; c0073984 <[bcm7030]brcm_play_ioctl+de4/1400>
Trace; c01562f0 <END_OF_CODE+1ac41/????>
Trace; c0155000 <END_OF_CODE+19951/????>
Trace; c0157228 <END_OF_CODE+1bb79/????>
Trace; 80057ab0 <kiobuf_wait_for_io+8c/cc>
Trace; 800de4ec <submit_bh+84/e4>
Trace; c01552f0 <END_OF_CODE+19c41/????>
Trace; c0155000 <END_OF_CODE+19951/????>
Trace; 80041e14 <brw_kiovec+2e8/3c8>
Trace; 80041cd4 <brw_kiovec+1a8/3c8>
Trace; c015521c <END_OF_CODE+19b6d/????>
Trace; 80028934 <unmap_kiobuf+58/98>
Trace; 800d5d50 <rw_raw_dev+36c/3ac>
Trace; c015621c <END_OF_CODE+1ab6d/????>
Trace; c0155000 <END_OF_CODE+19951/????>
Trace; 80014834 <schedule_timeout+74/e4>
Trace; 800d59a0 <raw_read+2c/38>
Trace; c008422d <[bcm7030]scard_interrupt+11/340>
Trace; c00494ac <[bcm7030]b7030_ioctl+3c/108>
Trace; 8004e808 <sys_ioctl+9c/234>
Trace; 8004e814 <sys_ioctl+a8/234>
Trace; 8000f0e4 <stack_done+1c/38>
Trace; c008422d <[bcm7030]scard_interrupt+11/340>

Code;  80014c0c <schedule+33c/488>
00000000 <_PC>:
Code;  80014c0c <schedule+33c/488>
   0:   24a54bf0  addiu   a1,a1,19440
Code;  80014c10 <schedule+340/488>
   4:   0c0061b9  jal     186e4 <_PC+0x186e4> 8002d2f0
<grab_cache_page_nowait+c0/12c>
Code;  80014c14 <schedule+344/488>
   8:   24060312  li      a2,786
Code;  80014c18 <schedule+348/488>   <=====
   c:   080052f5  j       14bd4 <_PC+0x14bd4> 800297e0 <do_swap_page+b4/1c8>
<=====
Code;  80014c1c <schedule+34c/488>
  10:   ae200000  sw      zero,0(s1)
Code;  80014c20 <schedule+350/488>
  14:   40016000  mfc0    at,$12
Code;  80014c24 <schedule+354/488>
  18:   00000000  nop
Code;  80014c28 <schedule+358/488>
  1c:   3421001f  ori     at,at,0x1f
Code;  80014c2c <schedule+35c/488>
  20:   3821001e  xori    at,at,0x1e


> -----Original Message-----
> From: Jun Sun [mailto:jsun@mvista.com]
> Sent: Friday, July 18, 2003 11:30 AM
> To: Jack Miller
> Cc: Linux-Mips; jsun@mvista.com
> Subject: Re: kernel BUG at sched.c:784!
>
>
> On Fri, Jul 18, 2003 at 10:48:22AM -0700, Jack Miller wrote:
> >   Jun,
> >    Here is the excerpt from sched.c:
> >
> > 	prepare_to_switch();
> > 	{
> > 		struct mm_struct *mm = next->mm;
> > 		struct mm_struct *oldmm = prev->active_mm;
> > 		if (!mm) {
> > 784			if (next->active_mm) BUG();
> > 			next->active_mm = oldmm;
> > 			atomic_inc(&oldmm->mm_count);
> > 			enter_lazy_tlb(oldmm, next, this_cpu);
> >
> >   Jack
> >
>
> Jack,
>
> Plese change that line to
> 			if (next->active_mm) {
> 				printk("active_mm = %p\n", next->active_mm);
> 				BUG();
> 			}
>
> If you see next->active_mm to be NULL, you are seeing the CPU bug.
>
> However, given the frequency you are seeing the problem, I suspect it
> is something else.
>
> Whenever CPU runs out active processes to run, it will switch to idle
> process, which does not have a mm.  The BUG() basically says "last time
> when idle process was switched off, its active_mm pointer should be set
> NULL".  The dropping active_mm code is shortly after the above chunk.
>
> Jun
>
> > > -----Original Message-----
> > > From: Jun Sun [mailto:jsun@mvista.com]
> > > Sent: Friday, July 18, 2003 10:45 AM
> > > To: Jack Miller
> > > Cc: Linux-Mips; jsun@mvista.com
> > > Subject: Re: kernel BUG at sched.c:784!
> > >
> > >
> > > On Fri, Jul 18, 2003 at 10:26:59AM -0700, Jack Miller wrote:
> > > >   Jun,
> > > >    Thanks for your response.  Our kernel is actually based upon the
> > > > MontaVista kernel and that workaround is in place.
> > > >
> > > >   Jack
> > > >
> > >
> > > Which line is 784?  There is another cpu bug which might cause this.
> > >
> > > I checked our sherman source tree and did not find the corresponding
> > > line.
> > >
> > > Jun
> > >
> > > > > -----Original Message-----
> > > > > From: linux-mips-bounce@linux-mips.org
> > > > > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> > > > > Sent: Friday, July 18, 2003 10:23 AM
> > > > > To: Jack Miller
> > > > > Cc: Linux-Mips; jsun@mvista.com
> > > > > Subject: Re: kernel BUG at sched.c:784!
> > > > >
> > > > >
> > > > >
> > > > > Your kernel looks old, and probably don't have the CPU
> bug workaround
> > > > > code at the beginning of vec3 exception handler.
> > > > >
> > > > > NESTED(except_vec3_generic, 0, sp)
> > > > > #if R5432_CP0_INTERRUPT_WAR
> > > > >                 mfc0    k0, CP0_INDEX
> > > > > #endif
> > > > >
> > > > > Try this.
> > > > >
> > > > > Jun
> > > > >
> > > > > On Fri, Jul 18, 2003 at 09:57:01AM -0700, Jack Miller wrote:
> > > > > >   We are developing a system based around a NEC VR5432 CPU
> > > and Broadcom
> > > > > > BCM703X System Controller. When the system is running with
> > > the intended
> > > > > > application and drivers we intermittently experience a kernel
> > > > > OOPS in the
> > > > > > scheduler.  Would someone please provide some insight to the
> > > > > following OOPS
> > > > > > ?  It appears (with my limited understanding of the
> > > scheduler) that the
> > > > > > scheduler is trying to schedule the 'idle' task.  What
> > > > > condition prevails to
> > > > > > cause this to happen ?
> > > > > >
> > > > > >   Using a J-TAG Debugger, I "walked" the task list (in both
> > > > > directions) and
> > > > > > everthing appears to be in order.
> > > > > >
> > > > > >   Thanks in advance for your help.
> > > > > >
> > > > > >   Regards,
> > > > > >     Jack
> > > > > >
> > > > > >
> > > > > > Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2
> > > 20030322 (Pioneer
> > > > > > Voyager)) #1 Fri May 30 14:55:32 PDT 2003
> > > > > > ksymoops 2.4.6 on mips 2.4.17.  Options used
> > > > > >      -v vmlinux (specified)
> > > > > >      -k /proc/ksyms (default)
> > > > > >      -l /proc/modules (default)
> > > > > >      -o /lib/modules/2.4.17/ (default)
> > > > > >      -m System.map (specified)
> > > > > >      -T 32
> > > > > >
> > > > > > root@stb2073:~# kernel BUG at sched.c:784!
> > > > > > Unable to handle kernel paging request at virtual address
> > > > > 00000000, epc ==
> > > > > > 8001524c, ra == 8001524c
> > > > > > $0 : 00000000 b001f800 0000001b 00000000 ffffff9d 80008000
> > > > > 0000001f 828f4a20
> > > > > > $8 : 00000001 ffffd890 00001890 801cb119 00000000 00000000
> > > > > fffffff9 ffffffff
> > > > > > $16: 00000000 00000000 809ae000 828f4a20 80008000 00000000
> > > > > 80008000 1001ccf8
> > > > > > $24: 0000000a 00000002                   809ae000 809afe90
> > > > > 809afe90 8001524c
> > > > > > epc  : 8001524c    Tainted: P
> > > > > > Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
> > > > > > Status: b001f803
> > > > > > Cause : 8000c40c
> > > > > > Process pvrd (pid: 331, stackpage=809ae000)
> > > > > > Stack: 8016eda8 8016edc0 00000310 fffffc18 00138f80
> > > 00000002 809afed8
> > > > > > 00000070
> > > > > >        00000000 1001cd00 1001ccfc 809afec8 80014e74
> > > 80014e6c 00000400
> > > > > > 00000200
> > > > > >        c008422b 80bd4160 00000000 00000000 00138f80
> > > 809ae000 80014dd4
> > > > > > 2aac2000
> > > > > >        00000000 809aff18 00001807 7edffa50 8002242c
> > > 00000070 00000000
> > > > > > 8016c290
> > > > > >        00000000 00000000 00000000 00989680 7edffa40
> > > 00000000 8000f7c4
> > > > > > 8000f7c4
> > > > > >        00000000 ...
> > > > > > Call Trace: [<8016eda8>] [<8016edc0>] [<80014e74>] [<80014e6c>]
> > > > > [<c008422b>]
> > > > > > [<80014dd4>]
> > > > > >  [<8002242c>] [<8016c290>] [<8000f7c4>] [<8000f7c4>]
> > > > > > Code: 24a5edc0  0c0062f7  24060310 <08005485> ae200000
> > > > > 40016000  00000000
> > > > > > 3421001f  3821001e
> > > > > >
> > > > > >
> > > > > > >>RA;  8001524c <schedule+33c/47c>
> > > > > > >>$1; b001f800 <_end+2fe2aea0/3fe2a6a0>
> > > > > > >>$5; 80008000 <init_task_union+0/0>
> > > > > > >>$7; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > > > > >>$11; 801cb119 <printk_buf.4+19/400>
> > > > > > >>$18; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > > > > >>$19; 828f4a20 <_end+27000c0/3fe2a6a0>
> > > > > > >>$20; 80008000 <init_task_union+0/0>
> > > > > > >>$22; 80008000 <init_task_union+0/0>
> > > > > > >>$23; 1001ccf8 <_binary_ramdisk_gz_size+1001a6da/7fffe9e2>
> > > > > > >>$28; 809ae000 <_end+7b96a0/3fe2a6a0>
> > > > > > >>$29; 809afe90 <_end+7bb530/3fe2a6a0>
> > > > > > >>$30; 809afe90 <_end+7bb530/3fe2a6a0>
> > > > > > >>$31; 8001524c <schedule+33c/47c>
> > > > > >
> > > > > > >>PC;  8001524c <schedule+33c/47c>   <=====
> > > > > >
> > > > > > Trace; 8016eda8 <mips_io_port_base+d08/1c30>
> > > > > > Trace; 8016edc0 <mips_io_port_base+d20/1c30>
> > > > > > Trace; 80014e74 <schedule_timeout+74/e4>
> > > > > > Trace; 80014e6c <schedule_timeout+6c/e4>
> > > > > > Trace; c008422b <[bcm7030]scard_interrupt+f/340>
> > > > > > Trace; 80014dd4 <process_timeout+0/2c>
> > > > > > Trace; 8002242c <sys_nanosleep+170/1fc>
> > > > > > Trace; 8016c290 <mips_hwi4_dispatch+70/78>
> > > > > > Trace; 8000f7c4 <stack_done+1c/38>
> > > > > > Trace; 8000f7c4 <stack_done+1c/38>
> > > > > >
> > > > > > Code;  80015240 <schedule+330/47c>
> > > > > > 00000000 <_PC>:
> > > > > > Code;  80015240 <schedule+330/47c>
> > > > > >    0:   24a5edc0  addiu   a1,a1,-4672
> > > > > > Code;  80015244 <schedule+334/47c>
> > > > > >    4:   0c0062f7  jal     18bdc <_PC+0x18bdc> 8002de1c
> > > > > > <generic_file_direct_IO+294/2d8>
> > > > > > Code;  80015248 <schedule+338/47c>
> > > > > >    8:   24060310  li      a2,784
> > > > > > Code;  8001524c <schedule+33c/47c>   <=====
> > > > > >    c:   08005485  j       15214 <_PC+0x15214> 8002a454
> > > > > <__vma_link+9c/e0>
> > > > > > <=====
> > > > > > Code;  80015250 <schedule+340/47c>
> > > > > >   10:   ae200000  sw      zero,0(s1)
> > > > > > Code;  80015254 <schedule+344/47c>
> > > > > >   14:   40016000  mfc0    at,$12
> > > > > > Code;  80015258 <schedule+348/47c>
> > > > > >   18:   00000000  nop
> > > > > > Code;  8001525c <schedule+34c/47c>
> > > > > >   1c:   3421001f  ori     at,at,0x1f
> > > > > > Code;  80015260 <schedule+350/47c>
> > > > > >   20:   3821001e  xori    at,at,0x1e
> > > > > >
> > > > > >
> > > > > > Jack Miller <jack.miller@pioneer-pdt.com>
> > > > > > Pioneer Digital Technologies, Inc.
> > > > > > 6170 Cornerstone Court East
> > > > > > Suite 330
> > > > > > San Diego, CA 92121-3767
> > > > > > vox: (858)824-0790 x356
> > > > > > fax: (858)824-0796
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


From jsun@mvista.com Fri Jul 18 23:59:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jul 2003 23:59:31 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:1775 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225255AbTGRW73>;
	Fri, 18 Jul 2003 23:59:29 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6IMxRe02882;
	Fri, 18 Jul 2003 15:59:27 -0700
Date: Fri, 18 Jul 2003 15:59:27 -0700
From: Jun Sun <jsun@mvista.com>
To: Jack Miller <jack.miller@pioneer-pdt.com>
Cc: Linux-Mips <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: kernel BUG at sched.c:784!
Message-ID: <20030718155927.I31523@mvista.com>
References: <20030718112942.G31523@mvista.com> <JCELLCFDJLFKPOBFKGFNAEKOCFAA.jack.miller@pioneer-pdt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <JCELLCFDJLFKPOBFKGFNAEKOCFAA.jack.miller@pioneer-pdt.com>; from jack.miller@pioneer-pdt.com on Fri, Jul 18, 2003 at 03:51:25PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2828
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jul 18, 2003 at 03:51:25PM -0700, Jack Miller wrote:
>   Jun,
>     ' Got the BUG() again after about 5 hours of operation.  The BUG()
> report is below.  Any additional insight you can provide is greatly
> appreciated.  Thanks again for your help.
> 
>   Jack
> 
> Linux version 2.4.17 (jack@saturn) (gcc version 3.2.2 20030612 (Pioneer
> Voyager)) #5 Fri Jul 18 12:51:00 PDT 2003
> 
> active_mm = 83f02b20
>

This make CPU bug being the cause unlikely.

Are you using preemptible-kernel?  I can't think of anything specific.
I think you have to do some honest kgdb debugging.

BTW, I have a simple trace tool (which I think is easier to use
than LTT) you may find helpful.  Good luck.

http://linux.junsun.net/patches/generic/experimental/030716.a-jstrace.patch

Jun

From wesolows@foobazco.org Sun Jul 20 02:33:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Jul 2003 02:33:18 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:15236 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8225215AbTGTBdP>; Sun, 20 Jul 2003 02:33:15 +0100
Received: from fallout.sjc.foobazco.org (fallout.sjc.foobazco.org [192.168.21.20])
	by mail.foobazco.org (Postfix) with ESMTP
	id 65B1AFA36; Sat, 19 Jul 2003 18:33:11 -0700 (PDT)
Received: by fallout.sjc.foobazco.org (Postfix, from userid 1014)
	id EBE4C2C; Sat, 19 Jul 2003 18:33:10 -0700 (PDT)
Date: Sat, 19 Jul 2003 18:33:10 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: PATCH: mips64 bogus setsockopt translation
Message-ID: <20030720013310.GB3093@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <wesolows@foobazco.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: 2829
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

DaveM recently nuked this translation that breaks icmpv6 filters from
sparc64.  We have a copy of it, and ours is surely just as wrong.
Here's a patch.

--- arch/mips64/kernel/linux32.c.orig	2003-07-19 18:30:24.167408364 -0700
+++ arch/mips64/kernel/linux32.c	2003-07-19 18:30:52.686564580 -0700
@@ -1511,42 +1511,12 @@
 	return ret;
 }
 
-static int do_set_icmpv6_filter(int fd, int level, int optname,
-				char *optval, int optlen)
-{
-	struct icmp6_filter kfilter;
-	mm_segment_t old_fs;
-	int ret, i;
-
-	if (copy_from_user(&kfilter, optval, sizeof(kfilter)))
-		return -EFAULT;
-
-
-	for (i = 0; i < 8; i += 2) {
-		u32 tmp = kfilter.data[i];
-
-		kfilter.data[i] = kfilter.data[i + 1];
-		kfilter.data[i + 1] = tmp;
-	}
-
-	old_fs = get_fs();
-	set_fs(KERNEL_DS);
-	ret = sys_setsockopt(fd, level, optname,
-			     (char *) &kfilter, sizeof(kfilter));
-	set_fs(old_fs);
-
-	return ret;
-}
-
 asmlinkage int sys32_setsockopt(int fd, int level, int optname,
 				char *optval, int optlen)
 {
 	if (optname == SO_ATTACH_FILTER)
 		return do_set_attach_filter(fd, level, optname,
 					    optval, optlen);
-	if (level == SOL_ICMPV6 && optname == ICMPV6_FILTER)
-		return do_set_icmpv6_filter(fd, level, optname,
-					    optval, optlen);
 
 	return sys_setsockopt(fd, level, optname, optval, optlen);
 }


-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"May Buddha bless all stubborn people!"
				-- Uliassutai Karakorum Blake

From vincent.stehle@free.fr Sun Jul 20 17:20:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Jul 2003 17:20:30 +0100 (BST)
Received: from postfix4-2.free.fr ([IPv6:::ffff:213.228.0.176]:25036 "EHLO
	postfix4-2.free.fr") by linux-mips.org with ESMTP
	id <S8225222AbTGTQU2>; Sun, 20 Jul 2003 17:20:28 +0100
Received: from free.fr (lns-th2-2-82-64-25-230.adsl.proxad.net [82.64.25.230])
	by postfix4-2.free.fr (Postfix) with ESMTP id C6AECC191
	for <linux-mips@linux-mips.org>; Sun, 20 Jul 2003 18:20:24 +0200 (CEST)
Message-ID: <3F1AC15A.6050604@free.fr>
Date: Sun, 20 Jul 2003 18:20:42 +0200
From: =?ISO-8859-1?Q?Vincent_Stehl=E9?= <vincent.stehle@free.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2
X-Accept-Language: fr, en, de
MIME-Version: 1.0
To: linux-mips <linux-mips@linux-mips.org>
Subject: PATCH: time.c needs to export more funcs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <vincent.stehle@free.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2830
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vincent.stehle@free.fr
Precedence: bulk
X-list: linux-mips


Hi,

time.c needs to export some more functions for modules such as mips_rtc.

Regards,

---
diff -urN -X dontdiff linux/arch/mips/kernel/time.c 
linux-vs/arch/mips/kernel/time.c
--- linux/arch/mips/kernel/time.c       2003-07-18 03:30:14.000000000 +0200
+++ linux-vs/arch/mips/kernel/time.c    2003-07-18 03:41:19.000000000 +0200
@@ -585,3 +585,6 @@
  }

  EXPORT_SYMBOL(rtc_lock);
+EXPORT_SYMBOL(to_tm);
+EXPORT_SYMBOL(rtc_set_time);
+EXPORT_SYMBOL(rtc_get_time);

-- 
Vincent


From macro@ds2.pg.gda.pl Mon Jul 21 11:50:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 11:50:05 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:42968 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224802AbTGUKuB>; Mon, 21 Jul 2003 11:50:01 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA13685;
	Mon, 21 Jul 2003 12:49:57 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 21 Jul 2003 12:49:55 +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: <20030720230140Z8224861-1272+3549@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030721124445.13489A-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: 2831
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 21 Jul 2003 ralf@linux-mips.org wrote:

> Modified files:
> 	arch/mips      : Makefile 
> 	arch/mips/mm   : Makefile 
> 	arch/mips64    : Makefile 
> Added files:
> 	arch/mips/mm   : tlb-andes.c 
> 	arch/mips/mm-32: Makefile c-sb1.c c-tx39.c cex-gen.S fault.c 
> 	                 init.c pg-r4k.S pg-sb1.c tlb-r4k.c tlb-sb1.c 
> 	                 tlbex-r4k.S 
> 	arch/mips/mm-64: .cvsignore Makefile c-sb1.c fault.c init.c 
> 	                 pg-r4k.c pg-sb1.c tlb-dbg-r4k.c tlb-glue-r4k.S 
> 	                 tlb-glue-sb1.S tlb-r4k.c tlb-sb1.c tlbex-r4k.S 
> Removed files:
> 	arch/mips/mm   : c-sb1.c c-tx39.c cex-gen.S fault.c init.c 
> 	                 pg-r4k.S pg-sb1.c tlb-r4k.c tlb-sb1.c 
> 	                 tlbex-r4k.S 
> 	arch/mips64/mm : .cvsignore Makefile c-r4k.c c-sb1.c cache.c 
> 	                 cerr-sb1.c cex-sb1.S extable.c fault.c init.c 
> 	                 loadmmu.c pg-r4k.c pg-sb1.c pgtable.c sc-ip22.c 
> 	                 sc-r5k.c sc-rm7k.c tlb-andes.c tlb-dbg-r4k.c 
> 	                 tlb-glue-r4k.S tlb-glue-sb1.S tlb-r4k.c 
> 	                 tlb-sb1.c tlbex-r4k.S 
> 
> Log message:
> 	Coarsly sort out 32-bit-only, 64-bit-only and ``portable'' MIPS memory
> 	managment code.  Another few thousand lines of code bite the dust and
> 	it could be even more ...

 Any justifiable reason for getting rid of arch/mips64?

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


From kevink@mips.com Mon Jul 21 13:10:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 13:10:56 +0100 (BST)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:34723 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8224802AbTGUMKo>;
	Mon, 21 Jul 2003 13:10:44 +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 h6LCAVkW028966;
	Mon, 21 Jul 2003 05:10:31 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA09551;
	Mon, 21 Jul 2003 05:10:29 -0700 (PDT)
Message-ID: <02a701c34f81$4f32ca50$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
References: <Pine.GSO.3.96.1030721124445.13489A-100000@delta.ds2.pg.gda.pl>
Subject: Re: CVS Update@-mips.org: linux 
Date: Mon, 21 Jul 2003 14:12:07 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.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: 2832
X-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

>  Any justifiable reason for getting rid of arch/mips64?

In my opinion, it should never have existed.  The vast majority
of MIPS-specific kernel code can be identical for 32-bit and 64-bit
versions of the architecture.  Creating arch/mips64 (as opposed
to arch/mips/mips64 or Ralf's arch/mips/mm-64) caused duplication 
of modules that then needed to be maintained in parallel - but which 
often were not.


From dkesselr@mmc.atmel.com Mon Jul 21 15:33:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 15:33:14 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:11083
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225193AbTGUOdC>; Mon, 21 Jul 2003 15:33:02 +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 KAA11057
	for <linux-mips@linux-mips.org>; Mon, 21 Jul 2003 10:32:55 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA16289
	for <linux-mips@linux-mips.org>; Mon, 21 Jul 2003 10:32:55 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Mon, 21 Jul 2003 10:32:55 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: 64bit Sead build
Message-ID: <Pine.GSO.4.44.0307211027270.16227-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: 2833
X-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

I'm trying to build linux for Sead in 64 bit. I found that it would not
compile without the change at the end of this note. After this fix, I got
the following link error. Does anyone have an idea why?
*******************************************************************
mips64el-linux-ld --oformat elf32-tradlittlemips -G 0 -static  -Ttext
0x80100000 arch/mips64/kernel/head.o
arch/mips64/kernel/init_task.o init/main.o init/version.o init/do_mounts.o
\
        --start-group \
        arch/mips64/kernel/kernel.o arch/mips64/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o \
         drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o \
        net/network.o \
        arch/mips64/lib/lib.a
/home/dkesselr/MIPS/linux-mips-cvs/2003Jul18/linux-build-mips64b/lib/lib.a
arch/mips/mips-boards/sead/sead.o
arch/mips/mips-boards/generic/mipsboards.o \
        --end-group \
        -o vmlinux
mips64el-linux-ld: warning: cannot find entry symbol __start; defaulting
to 0000000080100000
mips64el-linux-ld: vmlinux: Not enough room for program headers (allocated
3, need 4)
mips64el-linux-ld: final link failed: Bad value
make: *** [vmlinux] Error 1

**************************************************************************
--- 2003Jul21/linux/include/asm-mips64/serial.h	2003-06-15
19:42:21.000000000 -0400
+++ 2003Jul18/linux-build-mips64b/include/asm-mips64/serial.h	2003-07-21
10:25:32.000000000 -0400
@@ -20,8 +20,6 @@
  */
 #define BASE_BAUD (1843200 / 16)

-#ifdef CONFIG_HAVE_STD_PC_SERIAL_PORT
-
 /* Standard COM flags (except for COM4, because of the 8514 problem) */
 #ifdef CONFIG_SERIAL_DETECT_IRQ
 #define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST |
ASYNC_AUTO_IRQ)
@@ -31,6 +29,7 @@
 #define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF
 #endif

+#ifdef CONFIG_HAVE_STD_PC_SERIAL_PORT
 #define STD_SERIAL_PORT_DEFNS			\
 	/* UART CLK   PORT IRQ     FLAGS        */			\
 	{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS },	/* ttyS0 */	\







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


From ralf@linux-mips.org Mon Jul 21 15:42:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 15:42:30 +0100 (BST)
Received: from p508B6C3C.dip.t-dialin.net ([IPv6:::ffff:80.139.108.60]:21228
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225193AbTGUOmS>; Mon, 21 Jul 2003 15:42:18 +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 h6LEgFDB022995;
	Mon, 21 Jul 2003 16:42:15 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6LEgEQJ022994;
	Mon, 21 Jul 2003 16:42:14 +0200
Date: Mon, 21 Jul 2003 16:42:14 +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: <20030721144213.GA22774@linux-mips.org>
References: <20030720230140Z8224861-1272+3549@linux-mips.org> <Pine.GSO.3.96.1030721124445.13489A-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.1030721124445.13489A-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: 2834
X-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, Jul 21, 2003 at 12:49:55PM +0200, Maciej W. Rozycki wrote:

> > Log message:
> > 	Coarsly sort out 32-bit-only, 64-bit-only and ``portable'' MIPS memory
> > 	managment code.  Another few thousand lines of code bite the dust and
> > 	it could be even more ...
> 
>  Any justifiable reason for getting rid of arch/mips64?

Code duplication.  Thousands of lines.  I'm fedup of maintaining several
copies of a large number of files.  And stupid patches that keep forcing
things out of sync.  Multiply that pain with 2 for 2.4 and 2.6.  Not fun.

Btw, s390 also merged their two 32-bit and 64-bit architecture flavors
again; similar for parisc; it has been considered for x86-64 also.

  Ralf

From ralf@linux-mips.org Mon Jul 21 15:44:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 15:45:05 +0100 (BST)
Received: from p508B6C3C.dip.t-dialin.net ([IPv6:::ffff:80.139.108.60]:31980
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225193AbTGUOoy>; Mon, 21 Jul 2003 15:44:54 +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 h6LEipDB023064;
	Mon, 21 Jul 2003 16:44:51 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6LEioch023063;
	Mon, 21 Jul 2003 16:44:50 +0200
Date: Mon, 21 Jul 2003 16:44:50 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030721144450.GB22774@linux-mips.org>
References: <Pine.GSO.3.96.1030721124445.13489A-100000@delta.ds2.pg.gda.pl> <02a701c34f81$4f32ca50$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <02a701c34f81$4f32ca50$10eca8c0@grendel>
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: 2835
X-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, Jul 21, 2003 at 02:12:07PM +0200, Kevin D. Kissell wrote:

> >  Any justifiable reason for getting rid of arch/mips64?
> 
> In my opinion, it should never have existed.  The vast majority
> of MIPS-specific kernel code can be identical for 32-bit and 64-bit
> versions of the architecture.  Creating arch/mips64 (as opposed
> to arch/mips/mips64 or Ralf's arch/mips/mm-64) caused duplication 
> of modules that then needed to be maintained in parallel - but which 
> often were not.

In retroperspective it was a good think to start with and allowed us to
do some of the really intrusive change necessary without disturbing
the 32-bit stuff.  Now that things are settling down it's time to cleanup.

  Ralf

From hamilton@redhat.com Mon Jul 21 16:37:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 16:37:25 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:11024 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225214AbTGUPhO>;
	Mon, 21 Jul 2003 16:37:14 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h6LFbDH31960
	for <linux-mips@linux-mips.org>; Mon, 21 Jul 2003 11:37:13 -0400
Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6LFbCI31408
	for <linux-mips@linux-mips.org>; Mon, 21 Jul 2003 11:37:12 -0400
Received: from redhat.com (slurm.hsv.redhat.com [172.16.16.102])
	by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id h6LFbCm11819
	for <linux-mips@linux-mips.org>; Mon, 21 Jul 2003 10:37:12 -0500
Message-ID: <3F1C0925.2010700@redhat.com>
Date: Mon, 21 Jul 2003 10:39:17 -0500
From: Louis Hamilton <hamilton@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
X-Accept-Language: en-us
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: PATCH: Add mips64 support to RM7000/Ocelot-C
Content-Type: multipart/mixed;
 boundary="------------010909070505070600010105"
Return-Path: <hamilton@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: 2836
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hamilton@redhat.com
Precedence: bulk
X-list: linux-mips

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

Ralf,

Here is a patchfile to add 64-bit support to RM7000 on the Momentum 
Ocelot-C platform.
The port was 2.4.21 based, so these patches are for the 2.4 tree.
The bulk number of bytes in the patch is actually for 
drivers/net/mv64340_eth.{c,h} to add
ethernet driver support.

If it looks ok, please check into the tree.

regards,
Louis

Louis Hamilton
Red Hat, Inc.

--------------010909070505070600010105
Content-Type: text/plain;
 name="patch-list.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-list.txt"

arch/mips/momentum/ocelot_c/ocelot_c_fpga.h
arch/mips/momentum/ocelot_c/prom.c
arch/mips/momentum/ocelot_c/reset.c
arch/mips/momentum/ocelot_c/setup.c
arch/mips64/defconfig-ocelotc
arch/mips64/kernel/setup.c
arch/mips64/mm/c-r4k.c
arch/mips64/mm/sc-rm7k.c
arch/mips64/mm/tlb-r4k.c
drivers/net/Config.in
drivers/net/Makefile
drivers/net/mv64340_eth.c
drivers/net/mv64340_eth.h
include/asm-mips64/addrspace.h
include/asm-mips64/io.h
include/asm-mips64/page.h
include/asm-mips64/serial.h

17 files


--------------010909070505070600010105
Content-Type: application/x-gzip;
 name="mips64-ocelotc-support.patch.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="mips64-ocelotc-support.patch.gz"

H4sICCmGGD8AA21pcHM2NC1vY2Vsb3RjLXN1cHBvcnQucGF0Y2gAvDtrV6PYsp/1V+zTs+ZM
olFDEmO0x15NABNGXg3Ex5kzi4WEJIwJ5BJi6zkz//1WbUAhYacfc+e67BZ3PXZV7Xpu4jiY
TMjROtbIfDGOjh7clX/UOu6czINw/Xzixt7sZBEsVyeLaOGHyXpxEnn+PEoc7/XBmSyn7vEs
pf8u0v2jo6O/uv1eq9lsHXEcfBPu7KJ5etHpHjfzL3LU7Dab+4eHh39BTNyifdQ8O+J6hOtc
tLoXrVZpi1PY4uNHctRqNUCKQ/xxTj5+3CfkgJD7aE1Ws2g9H5OZ++ST2Pf84MkfE5d40fKF
RBOSzHxCBtqIDPzQj905MdYP88AjSuD54con7jwKpym3z0EyA/xgRZZxNI3dxXsSTEgYJQ3y
OQ4S4JNElN9V7PvEiibJZzeG36J1OHaTIAobRA6940bKrXt2SlR3tSL8k98ggrt4iIPxFB5V
njRbXPu8QUYWf7x/SA7wHyFKtIath+4imCfIywQ9hm6SMk1RCKiZgj/G/njmJsdetCDkV1U2
rG6HLKJxMAk8KsvqNxTjZP9wn/wQTMKxPyGOowuSotuO4FwZA94ZOg4AARKEfjVw/ygHvwIF
q+nwomiSWvN54qXHVN8/hD1wC0HXruSBk8oDq0zq9At55F8FXv585X+ZmBSYFIlDMAKITrbo
TWng9HXeFE3pZm+v+dxk4FD9Mxxuf/zdwQxetDj2viU4UorvCt2U9O+I2DfOaaCeEa51wfUu
2oxAbXQhTBuvQSpAIMbBdJYQlI2oGX9YXyzXiR+n7o2Y/DqZRfEFRE0CUfaZiDM3XpCfF2P8
+ZEK5kXo8R8QnUbE18TMt4QMBiOK0gfDj0kUEp1aAbIFWIksoxhzwSzwZiRYbWvHgXZh4t4E
q8R9yw9b+v2+WocfF0+IRYWJ4nTp93UIP45DP6GG5JocTXlcs9PgmmfUnn+Cy+YOfsiKuv1D
YBRMQ9AAkxuhz89JrbzqjscxxMt/QWf6TP55Sd7C8T0ux36yjkNSJqzXakGY1Ck5YP2J+z1F
wZgcTP3EcePp5j7xdNUgQAJPXr5hGWU9f19a9ODAycFy7TXI2nuPGxDKhhxekhpwAVt26inJ
nFxuyperixQpFnAqoaX869m2kONrFAP0r+PCm+KpXvXm+21jC8bIUWTbViRH0kSZ16g4uA8K
fnjIFI9qVIn6B+DWtrDr5OefSa/+HURc93uoWtS0NAcTcnLA1JcWF5bKLNb/b1p8wWBbNO/z
yvFVOqOOr1E1r5eCJfMZ6lw0OFJvA2/sdipCMAjz4Jg6AZTp5+oQQWem22Sx8f41Jt4kSdll
Lo+nkPl5HpdpJL5tVBR7mUq7bYMsT9JOAnoJAPy6kax+I4aqa2QJvY6/QvZrzPAr0IoIZOEG
Ya1OVsnL3EcmhJrHAQmCBNusBX2qZRaAgE9lRnOlzwcHxA+fGsAhXnsJ8dz5/Mn3kihekQPv
qb5P/rtP9pA8eM/Kh3uZzZL4PabNvSVYKXmsvXvdnhyRFPff4Tu0yh5oucJ+Eps9w9RVkm85
gVw99h/W02mAeWtFdTrco0tOjgSWr5L2NTFteB9oQfML7gpq/9r8DYoLeTd916D7x/4qwYWH
COrQ0oW21IequUo3hmS4crzFGKq4j4SX5Kd/N39K2aGstQCWOOhjyc/UvvB0eFgHmx3u7YE9
Ck6S+ueGaPQUAmqSPUyTqNfcD2vFbevkkGTLwBF/4+rkwyWSYCpdBf/xo0mZoo7AvYfYdx8p
ayCHClzCaRBkxoa+I+lJgc/uoY6YovegMoOX1bivV5C6VkHBf9BtS+LlIBAj9BbL2rtpgm3Z
OyphI1c9X63X0zqSSrC3eOp22p2mgzAaqYvl3HeAJonmaK4322UMLt/VG5QSv7SRojSyBEgX
6RmUeP6zULPzZqyel7K9TQn+uKxAz5nnYVGiWPkJTj3N5x+bXHf+DAHSIEWE1HR/bhnJg5w7
j7zHTTO9rm8YCtYdCviClXL6Kjs1U2FeFXnjmWnx45jK/7peFJ4WCPqckxcd7oL8uKK0JT9O
24K0UlamTPKNmYRsZRLvCXMWbQe5c2iqD1tcDxps7AV3RgYBVWB828Oe3lm43mwaR2ssCiov
DJ2BqY8MR9VVSRP090W05GXp51gZ/HUwBETgmwXZAYROnSZfRnQc5GmbER7kS+GBDKrjg5qj
3W5wbbwQOM9vBPAo4T8gw8NEC+T1jFHOvs46h19rHUJH7WIBuknVk+xh6gpT9EPwBKovcKEd
gL9KvSEKjx4iNx4TH1BiKKx03lilfoE1HCSo0ZoFDw5S5hFYmAnyWb9cAjf86ugD9fFJ7V0f
igr6XzrfPOK28+Pj46wO5mzRlbYL9yT2fSeVx19E8QvtfOp/YV4GS/jJtw3MGcl3TcwZ7d8x
MhdYF2bmVvOi3a6cmbkmDs3wfz41b8yWNaH+fzk9H3719PzN100QAaE3X4998nNqppU388fH
sw/bkMUCl+mVQbtxBpHcbXAtqj91tUxiJzMqtkFunGTVHORYuOE4a/8gsmhE5dGE137Bwn/0
/SVYCKMIJMRVaJ8SlPJoL+3Swydop7BHwF8P6lgcvV7zLC2KVTjQRzC7zL3iZdYrl+wyi0KL
q/ktFZWeXz3SvKDdmLx6YtrCyWc38WbjaAo9cLDE2oXdNQhPPQtba+6E60Jd86JwnGYIekX5
UGs+9zoNkgp9SKv9GYTy9wclbLdefltQZiTfFZQZbRY5nSOuQzjuog3fva3I+cagLLPOg7LD
QchXByW9yeIKV1mVIdbYDsr0Aphsh97ffm+VS2jiVbO5zm6kM3mm0PKGyA+BMQxvwBEq9GPs
hv/ZXEz8J//30iKVHe3So8mqhzGLdtkHZBDDSyc36p8QrO4qCum0RaMGAtP5HIAeDhgKKkV5
tqVr86jZIJXrXOX6LNhcXrpTf+GuHmlBzO51Jc027xW99lyHxnmZ+M6TO68tHh18XM5eVjWA
NIjBDyTnWjI1SXFGmgDVXRKhU/nwgXTrf3B11BH7OPQf4kWQwbBcu3BA4TiCuJpADYRfn2Aq
wzzTSufhFnoTbfkgPNMk38Q0R6/zelnDIofgLqE7JxYEPs0RfuqHhUfEU4+sFziTxYqIugDl
wGrXabp5Q568ItPBMG9iURTnqeVQ4bOyzsxgoOTCjZ/8+ZyAagRm1dglq6XrZWPu5jHm1oXt
O9no0SClRS5bLKTGDBOsrjrdznU+b+ProAaJE69B915nmXrnpl7VpuPXxe2XC3RTrqvmmy6O
Vi8rul9QPIgvbuxXbTyp2tjf2hhvIDb63m3rvBYO8oVDIX/tULYPg+w4jNSLz9O02Mni/6/Z
qco+pMI+RbsUmtI8zsGTb5y+IDq27vRlrQZhXt+r1ejPdEbGi4l8AQK7U4eUCBNjPZutujQ0
2/QlY5rVysll0ekl7bMXB/tw7C2yZhenV0Ywbdw2gzFzdcoX0Qf1ct+wcfxlXLKbTZE8tdIb
Pd6RvfguzOKLKExmDTJ2XxpkFq1xBW8hoZlIrY+5LomWtCNZL8du4r8efoejdupyb3ZCvrl1
Vrl1Nl5A+N7Xm+pLOv59psou7ZAOlSDJ4tUe0GY9YfuFjRjYL/ZxYp+s51gJFm5CoNMJI7AT
Ne0K0NdgFVoXmq+269HAaXF54czE/sGPYygno/AxjD6HRDBGtLzQ99B0Hnwd796yet4bo5jp
RPZ6p3FZcclB9igjih6npQCMUmSSrab6ogFyP0e8Ddd/T9Vpcxyq02538zzwZxqTrBEUrGij
TqHvj1doyAcfRl4/f0c/CWK85wRd8NJ01QCw5+K1SBgR+USnXTxxPQ/6+328V/TckHyO4kfA
m+B5UHthQsy6EXolHFEHcAJAWLjLLGap9K1eow3Sn3YanfzF2j42Veu5n91Il2kL4/BX9tLd
zglYARxnEkyP0iaU3UVXIX+5f66i2uPOu+fQu8IBEa530WzC9zeNs5VMiz1z7wI68ma3smdu
NpqQHhqnzVO06uEP8I09abTAM4FzfSFT+jGMBEJx4T76JN3ngoyj8KeE+OMgoVQF37l8QSaF
hXYLr8Mh3LAjK6F2O4icbStgowb7rmEueiFz6GfnJFrSfrm4hXRnSKasQn3ilQK1Erlj92Hu
Zz5BVuslemBJOF0cKRKV723lRjItWdeKq9ewXOCsujDShXizOvc9FCeXN8XmBcl0DFngnS5X
0vMVQ+BhB0c6Pa0GoyEcQe/zil2NIEqCZfM2SLmDgXTT7XCt5k6M8y50Ejsw5BuzGjo0HIW3
JPMXiSGi3FedW928NnixGgHIeQZturUt9biz1g4M3gYeO+AqP9BGqoN9x04sxeZ3wC2JpUH5
+vBrcJxBpd9vXEOWwkUU+6fNsw7DDwDYOevuAp5VAzVJcHTLMKV7NlziB4pUDdYV+UaybdlR
z1jGtQayIxstxgFmUIZ0lty/tyXH6nPPz8+OBfNSNZomO6YKic0xBLkaxea1Pi84dr/ZajHs
VEQ5Z6Do1lDu847Zt+865yypb2TB1k1HNYR2864a5V+8DsFvwEErfJUrmLeWpDoDSYOEJjiW
IWuKLlyXHCJFuROGA14UHV4Z6KZsD9UqbmCVQhKzbnnDgbRjGZCgCuuadOvI5qfiig7uOJRM
yKhAsIFqQ6bd8NE0GkfcZqDlaRH6IUaqxNfzFQVhC95lBADCzTYzwBFs37XP7xjHgfAbs8Pt
gpud9i72Zudu9+6dnbubpzuFN087u0xjdndSa9INLzJyGyXv7d6cTplVjkWhGPrNkh/gMsQs
i2LIWw5knCvJFoYFp8pBimIJlcuiJYhb+yDotr9rK+teEwpFO//wKO2St72w/CGRSpvAVHql
QkSY8l3Vvppkl6SE6HM0XpUYJUq2GCcjMSGqwABY/RFjl6FuG8poUA00BFWQGSwzwq3Mmu94
b93IRjkN9C0RzheqmAXZQBBsBp1gK8XWStBNMLtyVWKVrvL6iFFWs6PYQiiDM66lxhP6KtXg
7e11vd3aXtRKi29s0+VNcVTZYlQqQ61KjCp96UZs35uF0TyavhDRfwpgPiI11RbrZSeFlSoe
hgtOPYfGmE5XxR73bXPeNHTTrqSer6f0fsiYuy9ZJ7+O3e1EbWhGFX2fvpsfp1KXKfrKNfSp
N84Vo3tCuGB8clgJKocLMrjTLiTcROSF8y4jleU4I1WqrJI5XNF1o3jY2bLWLyeffB0vGZn7
YXduVR75ep4ER6nB8tMiNZOXRXoMyo26eeyVp675CU7O+N63YiCCAn8tFV08XXBUlTdKukDK
UmSN6sNqA+0rWbElxhRQAcsgI02+KwggbyZH2XDUkWLDkGSxBgjD4cUbXhMk0TEhzqv3ASxw
zeJOdMERh4KxuSGu93XIa8wNEcOEaGEaA5DkndCByeiYgSsjENA2jiQwig5UMUhZ+rXMrCPG
DaOxvR7aNmtT3mZ4743Ca06v2eI+VfkdKTunbDBaGx5G8esqBvxyOfcTd85IGjDYaqyJsm/K
4oBh3bsWY5RWeKPPgCiMXI3HIcJ4YzLkkOAnS8ZbMF6Fs5Z4X4HLUxw2yvDWuVL0W1gBTKXK
jp8iCxPGSRSTiRvE5H/W/tqHdFA2J/Ky8FXYjhxCEn+VVFIa1zZMIlWkNnTzy1kUvhCrsuAM
wUKVp2/zJ7IonahX6ompKNXlChB2J3JAwHsaVkDkaMNKrS3Bkqv3pZAddion7WK+BWPBhrKQ
3iTlupoCfgCo0s0BxnQhcaSqjKG8r0N3qjGaOenTiFfkf7E8zx4xEoxkw6Rn85XlXco/xlTj
mvg3DjAQqA9BUt9QPuWxmeKHvGHcqxKvMBLbSBtIjCSEPG+gFYdpug392heRLHVHLGc4Ji+w
RBkam7dgxShIh+hC0wyrrKGMV8Uex3FoEAaCyBu2JGCDYF7JrGJhjxRWmRGlzh0j14kDkxES
onrONRkiSxL07MxbQIkJuYKT1RjpX4PuR1IZVzKa1LpmX9j0uPa5wNAdYbaus+6MrHOmFoYs
MBUBRxSxzWAchcIaB22hfdrjGGdxI/OOOZQ1BtdbWcNgdnodhlBYhS2ePz9rMxCoa+rY1n0p
cEHvt6B9c0RB0mRG1IhK65rtDiyBrF67x7puHvL4gUvGkd9LChS7K5lhZ7PHdRn3ctb1eU9h
0dnyQNfaVWFd+FBnceR7W3XK9xpFCONGv4jCCLQrUWQYYCgbBgNkGIxYsDYzRHa8t0EMxXm1
Iui3tTAKj2buInbHQbThAOhAJi/KehUXO3r0Q2LifFFZwOxd/Q3Dq0yBGfQW1IqNwpWr44bp
Bzsm7pYQt3xlc8Iv3MRfx8REpatLPbgjU3U5hmGzFoST2I39cZ3Ro5gbE2lObIkaUDys6Ed9
NmgQVkUTLtcJzN6xz9hLM6pvOSgAOqGRJWG/YwmmJGnO3SWk+s4XkO4vz7q9twvamRu7Hn4U
tfKwb6pvciRT5os3OekCDCuapStSKYAykHRnQy3e6EbLKBpQ2zwkZHPjyk9XQY/NtvLNt2gm
3LrleCO/FxSe2TGK8kCWDNblGkIZQa/f8WBgG/KXzKhKFMVSedNmYcgWKyjuNQGn891QlTWO
Qv/LmnBM2QJ79hiMDUmAk5AZpd1irJss/eA4FdFk3C9kp4539BzrTVGOcsd6OQOQ1lmGx7qL
OO85hn1ffKf7tgrONdLsy9Zpt5giboTclSuDtiUworUlVOGrEFZlxP7IolHJ8ptNUEb9SwSp
JfAeN2I0DfMBr0qsq77tNEOxfH/sj+nHVabuwqd/rkAJvpbq92p5PslCs+XAWMHQTzZUGdKw
JiqsvJ99eFpw4/FW3reFoagz5iBLeMY3ggOD5ZDQozuGCvmPETg3zJs90xaq/Iu+/gJY+b2t
rTAi12yfs15nwcSkyJsDT6b8VeIu/fTvCSfzaLl8IbiQT6XjOHjy47Kdrtjm5wes8cKs3hz/
YCgtapsHPdJZr895SNhXlnPFyLopuMOEm5IMMb2LgbgLeLUDONwB60u7gNuwvDO+s9sAKiSY
XzYujuF3mN76rJcxV/z/tvfu/W0bSaLo3/SnQLJnYtKWZJJ6+BXnLkVRNseSqCEpx0k2Fz+I
hCSu+RqCjKVzkv3stx79RgOEFMnx3DPcndgGUNXV3dXVVdXVVf3MZvNIagK7+knqH59aBNGH
tlO013m5t1fNxP33nHaP2yBAM99++JgDetLPm5vTzDHGw6XQ6QIoNZnfw7vTfs+F+MfJx52c
9rud45y3MM31zJd4KJb58uzgMPtdusVHtvOJFmDPtwCbnYNGJmJUTrrHrZ9/7mQM0clhz+Za
fPBh2+SaTqePT+2Dg8OeX4s7O+memqe4GL5w4P47/LBjq4fH+9m80jzNfPcz8G/myJ1Gi+WI
bg31b+auSnuKChnGT6kzBq9g7x10evrbFM0nR1lEH3lJosOfSTwcRRmKdvug1Ukdxohvepij
yP6+B3qL18l51tv3ayf4wvP9/ngVL2ez5ZUfav/orPWzD+493TYMrqLBJ+lBVlKp00Ml87Tt
mAJdULUwgiRHEr5/e5Dhsz9uvMWwmJ963X9kCSXYiuX9Dx/FR6NzsOtugsVstRxN3Qn4+ai9
D2vm8KiR5Z2nLw5aqS+KR5TyDc21l7JSXxaKJbVBRMzn3mZtF2M+d+qv6rVbXcHKwshRpLuv
6ruvdv3XIXe2dzbq9eAp/lnb5ejiSTReRhylXDavvDoh5VY03KPN0kDctHVu9b6CVyXnhqHC
vWnkJsj6plD74dvbUXBZiIbL21LRvB0Vg0JUDDxU0P1wugk+vymLK5oh30q376g3j8Je++cW
haZP4gl+jrfkh6ENZP/LBEp//Yt4vVnTWTCKr6vJ5Nlgc7HzKX9N6a8KrSf9ueL86sug+vzV
zotXtXT89Jq15MGGOfMA1far3YwbjNW9Ol85oz/5vgazgg7CekWZBHAuw+ksGUSDqzi8WE0H
CTGAzVgMwaFaJCYfYbR/wJdwhuWsryrB77+7H7k8WkEyFpPnn8JkwBH4JmfBK8pTc8s5TWDE
AOXaWVXfFZ1XBaAvqu4FtZev6i9f1XbuMLMuPikjt3dhev1p1mp8m0ReJhEXocQEYtaVUrm+
u/cE/XkVvMJyOLoGq3s5C+Dp+9E+JjfjiaJbE4/wYhlIa+fa04jRfY5uCOVGMLQfgGAQcOLy
zDm/n82T4Mn5AP4QaRHk1e8omTwDJqav6Fb47SZ0OT4vtEzVd0UnVAGICdjdrL8IqvVX2/W7
TaiLTy3W2qtqGp+8kgJrFf/g26H/x7zSRLPBIVYg3kAmg/SrhvyAVgrI6vlidh6H0HKZn9Mt
R0zOMVgtFvEUZPZ8FQ4jzDo3X1Eqi2/eGIKAEsZ4cIir5dievGJbPj0OxW1B9Y6uAJar9BAM
jTki4RuBmMbEpQBeIv8Em0Ft3Zpm70TybBovnzWJqK3R1B1+70eZk+/9Ws/UTlCFaXrpW3qe
mV+DjNbx7susW+b1vV1ayPCHyH4wjGHsFpgdcBkHj8Fsez+bTmNYW733my9fXF9TrBf+fRf+
/nZ0GZ2PlvrMrjGM5uiMv8Db4zdSJX/sHnr9L2nLNNtui/uLWTTEy+b90eVsup1CIY7GLAyP
ngKf/RJ8+78ypPu3wAPf3nwbbM7S3/y98fas0Q0b/Y/yq19fo6dqSrn4zmezcfA4CI4/bNIh
me6pS5eZbQUhsVcS2oA/RTdk1QcVVlWnboOr5sVVuxOuuhdX3Y/rYgRSezoEtWxFFzGtGTg9
bYboAmu3eu6wFl9ux9En2FbGcR7Ly28KLTb5sVaIdoI6WBbbBfM75OLCpbb3CoR21Z+ZtFZ9
zmlWnstNE4cvAMyfgtliCIsmEdcMgv9Alp6d//fm/yqnR75SevpGJcGKl1dbs0eB9W2j3cUo
r51dzMWFH0ejxQxIxgchusPzIMJm7w5AeOsC4AIXLloMAa74jJvdSm2ymR8WmnsL4q7XFLMR
Olyw/ar+PO+KYv35NqXRevqMM3KkO78ZHFBjdFIhpv+jk5yJQH15eoon4VGpZtE5D43sVYU/
nu4Pv8pqYRGdx/HVf15GY1gCiHJrNFY4+0YSa3Q0YKqmIBEJaV8HN7MV3Z+FDRuE/mJ0vgK5
D5sIxwQSBsovcoMPV1NcGUgcbCuTRN7XzU6pTfARtI9Pkyvo3PlNbtrs10E8wlHVGTQIhWhI
YN3AELJytETiFyJuuQIU3wTjaKlhtzLHQHcV78IT6qvZHC8OA1Lo5+fReIx3kvli9wbhgK+D
H9v9d3hToHHyU/Bjo9ttnPR/ek25wmfwNv4tZlyYumwEqKFvi2i6xNzjhOK41W2+A5jGfvuo
3f8Je3HY7p+0er3gsNMNGgF5CJtnR41ucHrWPe30WltB0IspZRxhyElejpxJt9GH8TIajRPd
+4KZ0dfNIqmda/Oi+9KiE3wqNXqw+zLox5jlDS8NDFD/660QxfZ2dSPYnyWUDee4EWCKdMzJ
tQ3C2sqT/gxNTjuRFGuqaE2kXkmu8L3jm73eVyIRmu9VTmMq1VXqzXy5gM56X10Mpkt/S6MZ
ihj/KwxqWazm/rfJODr3v4AFMPXTDuimM39b8wwSRlm0+YdgMKLn6TcgTNmh7ScMJUPO++TT
+eriwnmFwlzQbT5G4xOUZbBKne/xxcjtPj5EK8n38fxyibfDPW/4nFM1bXpPrPhtz8BdhNHC
HWyjJzILhPH6W3PHuvoW3z17cl+/R0/vDdV94wpAusuUEZTTDWQTCXTYI8VVf7GHCjl3Obps
OVs3SNnga+7jff0o0+WzJ8EBOoj4TAu3DXldi6L0eKxItq4od4fUdrsfw3+ctc5aeFnnKOyc
hP1G771ACLYuWIxTzlCpqjW0Pva7jRBvYPeC7bp+/mO3cSoKNqBJ8+6odRI8Derwvx1MGbyn
v9w/OzxsdcPj/hkedG3+MFmu4AuE19+0T8CobJz1WuHZyTGQFDaOjqikQ7X6HJPD5H+JB7H0
ca0mPuZ1avTa7m8amdMo/XzfNd+1mu/D/Xa/Vyr5SMmHIUKzemBKBJiOHuc9QdctTfIwHowj
vo3HM2QkRjHEBuZqG4egCE1l0mpYIaEIDHmCLqQ8OMwTdEu4wVU0vYxDmFUfICVDN6BTn4T4
AjpkosTMNPR4DSmUiw4BUACQk5lSqZIoT8rIlhT/pL6YriacL83O5ZTOwfrL3q+vH91N+Aak
KL2Lx5iqUk5eAnrRKiFFNRkNOXuwFGjT8Q1rQneTBOZQWIM4icbj2SBEgVC2kkahn46T0peG
k4g7vQzwr5gAbxzrVJmLOFmNlyK3WiNJVhNMCI9oKeELbtTQA5DV5P5Fwxvr74y5Kcq5xhiC
NwGoCyETBIIqAdU9ni7LnOeZHdHfaQLIzzmJJ0m8LDOCjaDK39ErkeJeUffHHafK92Njycve
+EokqC4JycfGHH2RBCjgypPoejRZTQJQEKcJjs4KuLJibFvk3cOda7oQO5fS8Tm87hU8JH0Q
1XC1xamwZ1wL1g0kWiEroaDL3xRsVZSz5JOlN53VkrFXg9UcxEmyotxLG8Fmq33yoXHETy/A
6hC47uWXLabyxQb8yWUUoCP4jeBXuaTxWL4TPJGjE85hLQFLInMIZGZT+DZ4QhLA+NBaE1I8
WC/IWLoYR1SpoeQ2BkxN2xn+E9+b+ANMl0+1jDLJqQQuQkDlkCipwvVjvBIfMrnY5floGuLd
63C0+CeepJa/sz/HdxvcE5F6nhLPi7ENfghekmfr998D9ez7YG+nIpK5E/7VVLaAmXvBRl3T
iDzhk/wlsrFTcQWhBLyRsyskDI4Z7nucqg4X+CbuY2yOS/7fYkcAWfdSFAXdjwHYDY8TMm0Z
DQLhKoBVucVPQMUEyxpgIxjNJBlhNqghMuGCfQYIQe0Rborl4DUSDzeC4SoWeGcBp8cmP8xq
PJYFhCbkz8EFpDFJ+c8UPBMDD3MOtsFiNZ2ibIbhkAONL/1bMn1kJsPH7KZhq9ulZ2LRf/u3
5FVwGC3B9uccdLjMAXqub25gKjkThOZiGk1iXTLBr0vcmQCELtr+H5qdb81ugtuqD70fLK5B
v0g+ZW0Gh8A7SfAMePeC/gacSbdxcSiiYBAvltFoau0DyoK5z31ASfuTZ40HEOac0Ds9KiKn
Np4IContl+1GSRVLtQsQ8vWXEvSn7wX++SfUHi9mBtrkU4jqTfAE5AqLzK9X/uOqxXvbIcbO
gNIUAmuVQWFyVoyYI+hXciMlzjyajgZlWrctWrHoSUVUAg1w8mAcRwv8O6WhTC3Ykq7TkmoO
dc8QBjCB7STrLR8a70qCKKtkHDx9QUat0DBZp8Sk3HRWGoFsRvfydj04v4HB5hS6JF5L0BpP
jNA24d9lwwB9GryA/xk2rVEqBj51C9lk94jLi5Qk52wNJjD0S6zwgawLBmfrpLF/1OKY2+7Z
ad/+HOkOB9OlZCK2iQ1DekcY0wapr8X4NGg05NiAcHhBwyAqCFFf0u18F/xP9fq5rM7ief+G
Pnid8frpm+CFLq6i368uQqrKI6sDoZo/ieYwrdPLcYxMCIO1+QMua1HeRQr9Ij3WIJg+6eC4
ER52O8d8u75iDyiLf/o7Fh6hRctjIcST+ABHreyuPFwqAlEFYyiQqs57NVhrNjxeOEIXwa0O
ZD5elvSsF5O3/hDsipUQ4gUobfD3jaCu1pVad+uWMmtPrJ20L7B1cgKBehJP5nRwEfTe72M+
YFg+VEiBuAYDOTTRDB5d4u40wq2KT2EoZaytveQtc64F8913UvqlqabctLhr87dSDBlDTBKZ
BrZ7bffEN6C4Hi6Q0lq1OunFA7EI7Iax1dlquRVfz0cw2sAg/z26uBjB354G5Xc/g5CTtYYw
9zXR6KobAkXFLxbMbmEADM0gRtKt8buVqNaQFHxdVmHUYYBc0ccfwh+77X6rbMYQKMHCrqtu
621Z+TiEiuVzNEn2kq4m0pUeXFsSA/R5Ec3n8SJLd+oTa4pgbGTRz5hRdjXXShTqVMgRiFMY
Aso/NuLD2xWfvo5vkI0pNBK1cYVB8hInQo+kEYHsG1xFjAJ1eEBSBp0fqcBjQVhDQuvHA8Jl
ZetfQVnL0tLs2XBye39VuttfonY5SNMLnIrJ+LRfWVKGB/H1g68uTuauXJeYSjtjaZ1x2ndc
CmaZKuGW4pucbGjLV+RE/Vfg8iyTJD04GY6mYr4ll+/+tPnxl5oMmU5z008uQ/kzWpUjK/Zk
0rnpn1TfUDexEo51dOdK9BtZXZFI1ep5qLWDBg6s28lsGOc7djntP54RjJLBakap7hfx5WqM
1XGuA4nga18mqfVhDMCfXRhl55OKtVSE3kiPyF8Dxkj78BAvcGKOTKECKrRIFx9mgmZ8KQ2L
LCZEXpLfaJ66tHDkwFaC3xU0duLshJIQStrOOmc9yi7GalOg1bW/itzvFPT/WKc6lQLkP/h+
hOUc5svwIkqW8wgdsRmbUcIXF6IVunmxkICOOeJIHXbIRgFiChAV14iiILdzEco0HDIWZtjH
iVAcL3nn4iOpe1qYqCtaxyuRiYgO82KcCjoVY0q5HoYiEr/hOxL2Iv/f8WLmnMdM40vY0H6L
H+xAJjeIJeO0xpnZrCMbZa9TpWD+ZpgsxbWBJ/DXbNVyxrolfEN7iSE48MlsTlUuZ8vZYDZG
Gz2kg0SMVwivlvA3lkFh+1TalPL4QZpjAtuM5JC8LdHonr7rHnDKOjz/4LdOb9FUxaPKbMSu
/Sq2cvQQNAgX5seQ2EASYo7FiK0WxXx/Sypk4M5sC9f2a+sIgYfdGQuolGJ3tA5nYBUCpNQh
mddPZkEyjwejCK8GL4YUK7q8woUq4hlhnQyxcIwsEKOHBM9qxp+jGzbLcMWAkqp24lVCm+99
mWL//1rk7gJ2JjXzzJUtGNLAeKXKUuyPjALkVS5AvsfVx4X34iml7OFSR1gF6AL9TcLAePcj
8URAy46dGpbO+MsIL3mWy06NrQpBVX4ZoWvwV9fq8ij4qLR8ycOgJVuGsPFkrhLMxz3kaWbn
G7kTphwgMBktacsCVosGn+L7OgLa+rKapB6FfEXS7+Xrf5TDkvbvPejkoemTfYyHoYjKtzTg
WYzI0wgqGsavkGuST5nNWdhiBO3lY4yYX8xnCckxmECK1ovGeODB0oTGJ8J6hXpy+ekGI0F3
F32rhRQpRp8B6HKEkeqjqSCHA8M4tFswDUtNaFhFIbHTC9blUtLucQYo9koxIyig5xyCSQ4D
q0s2x222TjonlGH9QnrTNoIq/ktIwIcUdVzuyzC2HyB4JNM1VmVRyf8g41oGPJdJvuJ51+zC
Npgq6mLnN7xYjNiJkw4Mo8KJehDMunVbic7nX8v3VOjPfo+P1HvcgkOqvBxeg/RJfSpfKAAV
i+d8qp7rpu0txkVtv7WhMBXKAPSjcAys7AEUdiqPwzPSKTDrGLJg/5r8xihVaWNh9U5JJAeZ
fqEIkJWZ+QV8X8f4vZ9fG7jIdRyOaeSlD74vPfqYpEB9LOzbN2CdoYnbPTs5aZ+8raj3VIKO
tkLhRqSnOhYKHn/nj5J6vUZxL/k11zwtXpfAW+9mFeF46ZOzah5P82klx+gI/zkqCMxP6CS1
1a8AQz+oiES8HGxtbfGM5ju9rEreJMM/ceRjWZCVsaYrG8Hbw1NRJVgvwPzGhAXwCe9fpcaC
z4b4nVRE0guZzvYyRtNuDMdWGxJreqN6oB2AeL5muSpS7gRxWk2MSK4NF0GtGIJaJoJ6MQR1
hSB1HNjqdllPaE9/g51myHsPb0W+A0H/3DjTmPPlulk8aH0w7L4HcuD6xsl24AoOck4paWGZ
azIj3LpSUaK0jdVG1bqjBWfEE+JW6gm80uCo5BtKhIxCEJ5jxzGcDrSWzmLbGtj9FQMOHF+5
wRMnnX672WK2IHb425A1H1Od+Vu1fv0q6z8yDk0xz0Zg+edseqq/Oj7uX2qpJ/VfPYDbqc92
Uk92f/2iJgtqC/adSuMEVSq6nzH8Er+cZim5dF9HABIqYcwbSm4klFdp9W+YLwc3A7yc2L1+
1r8meDCuB4vRfDlbJGj9YQzCVIaYJ/KwlncS0Jfb3X9Ii1tQJpAQdSnNNWXK57ngPcb7TCmu
oMdOZ1N6KHRbdnPcy48C+l11Nusqh7arEALYB8Tjlwqd+0vOZe8UDl3+ruwRX0J+8aAp6hYx
KHqghCKYHMUqVkMMT86Og6daQjjmxlLcW1iw/7Pca+jojOD3AP7ZaxyfHrXCbuPkoHNcMfYs
+qsRky0o+obiaPx7YRPYH4OTowTnhlaCMMyAt6V2CoRx3Wh1XBBoc8ja0mruyQbRBkMgtuas
QbC9qjlBw1Y3jIApGRis7E3fbo7bMM2HpEoNWCosvfydxUF6ozK27/2z3k9SBzvuHMA0NUO6
oYU5n18/SsUeZ+NMi2v3zg9f5nYW8p0vbhU+jruX9V1abdeD+dUNHkeFMq4jdYnoaxcEz8Rl
gu7H4B9owQndxBtO1W01W+0PLWHTNTvHx7BWPVFVAV8PvLioVrUS1MRQPdpXrIDuVCTXmkAu
jtWy2ww4MK0QJGfU9yJgOs+mmOwJx0MG1sK22v9IWVMUrYVIzYg5yww5s9oHxqKWKVELLoYV
bfl0ieqWQya6fBtyEEaT1IuXyhHWEJqjqcH+ydgHUqB9JoZuXQQPKa8dN++N99xKbqYD6Tnw
fyGj52zDX7zNBiNbnBZunnkhXCceA4Pjo9B7w5aoP/5SiUYvdXZYWjYWQasdt1bRtGeHymYP
nRve5fgu+iKm1jM1Syv+1Yd/aYa65ziQxPsc4CemqwXgD1q9puQ3h0sBDjXqEPTuSLasZbb3
OqeMta3tiXhy+yqnZyWEZitathvUoTzPupSq7nNmOV4s9H51yFBvSLUA5Yh0IzVx11y3hhpD
M5F6VnE0I0MdU0Tle25UpN86sm0nToF50sLhYDWZ3Kg0Not4jglWxFES6grB8tqYGY7kkuho
gFPOOlJPc7hTfOCsrLUzk14vXXO9wIvjOJpSKLkIjQ/wEPiCElhuUlKeySpZYi9V0VkM4Ti/
wWjeRYZA9K2prrum8mLVea16V90ic9V1c1fd4ousukXmquvex6pb/OlVJwP377Dq1rSEKYkQ
83wBevFslYxvjKHsiyDvZGtry9+SaGMwCsmwMK6iV30RianFaQS4GE5n8WStKNCf/jYCblvO
cFPyaBj8nfjUWWt/VjYtbiGbUtys+EbynCF5FrmSJ2d9bQS13e29DSXxNtIij++icNyAmFR3
91/bVwMWr528eRNcRGDzcpLU9C044ajKvc7DSxpvfCqBR15IvorMWqQnSlxb/EpNpHO3HD2x
eRUPPgVHhr4MewCq0VJGMBpKI5tMRhRFqL0VNbw/ZBhzevmXzcfBd2Dc1NWdHL6ljIeHfP6l
veHrTrpMb4LEgueK2Wh+B3UuhcVjZWdHe9N6FnvZnwv0/vMG9Aalx/1XsY5BRVprHfe7jZPe
cbt/N/OY8sgJFTpROgE9BX0eY/iGFA5GywZLdFifUtQRDqjcsXn9Z2vheAFNQHzv17YrCg1+
9fSpcf3euwkA1l/wy1/llUC09+iIiO6XroEhZs+xGjY36Ys/BM+rIzS/ifGNPNbjnVLucpZn
bYqTqh3qnC5yE5Qr9NDjTk0P/jb8Vu2R35r+d1vS6Y00Z8iJ7/7ktmruqgU30/V7qWf7/GOt
HFl8HXKExDT8+19AmnxJbxsJjq5XnMzRLpLqoJIn3Xx5kmckeCRJNyVJSgWkyOIOUmSxToos
MqWIV44scuRIpsat0gJcCNW7yyb1Fur1PMTJElSgb01AeLQChWU0VQbfZgD8PZMxc5MsEeMK
mcWdhUxKeS0oZNJKYxEhs/AKmQeL0IZ1ln2GSzdg6QR3MJ4la6IUA46iTZyTWnqLtYPxAi0e
5IroHQo/vJqNh4l1NGse3uK/JSQibXf/sZV/GJt/D0qetWYfwN7X+av3+DUrI96X3Qe+Ztl/
iwPX7ORG/D7nuA+P6w5a93FcR00VOK+jUEoryd6tUib+m0EUZVmmpMMRtg0nJz5bO/MY0phL
IzOuTqV/JF/DKCEn49d9Ynf8cOd1qWa+yLGcajVt2j/cbimDmrP3TPYbqnsY8jK8Y0bB/8TG
+M8VVschnklHG2EuiU17m0tmhJan0bplhJHim+k90WoiIyrJvFL0sDFIegilvDDzY22ks7p+
cTvJm8srI5MjEnR4dtIE1uxjRfL+WU/wu0GLGzIJPRXR7l+vqC3JQH1fWChTrvMPclA75QeM
h55QnSyDoL/AsghJzE4bsV5I3bQu7gnEWT5/y49t3KR8JhYnpWlEfZQzCW7AFF4Go+WWkYfI
69qBtZTnGfpeT8an8zC5Qk7Bv1aAqgVsL+iMfBrU1vtA1wzS/goDm8ypBsL6ixvSxmfq8heN
m205iUQ3K9C5v/FFRHmH7DQChGjUDMhRvMnVHTgkc/oYNHY8Up/qsaMsadalVmIRds0saOJE
grN0c3fINvpMJSBR4vVi5sb/b24GB8eNYPZ5ivk2ORf8GO9/8/GfP9FaP51ojW7041iK94ft
bq/Px2K/y2dHDfFIRAx40rJR3rIx36xJ5ztzEp0pL5yV8Ezh2FD5y/odnb3MROxNXyb24Dc6
gTWuutzsZdKzX5awPEwwMp0uJ3i1X4ikVMgHPmdAYHsVrTuLPJX5CT2zlyKx1yPjcAOolud3
dM2fQypVrj+A2cLsZlSlZEnFxEp0Mns5xYvFo0v8aBzdoEWK+y3q7iKeE4ntf3xk5jDzi47v
3+R6XkkuPOLLrjThwuF1Ke7TsTOEsoWsMIJFkLMlvn2b/5k69YqnqJcORS42unIoMPCIJ3R4
LizsocD+LE9aOWuQjBkYlgHb6rS30+U/Nbs41Xhaz7cBlGTg8+mn9trQrwV5LDj46hRiZOVB
51wzbEZPklePAefN8kqzIF0CSOfDJn3lajvZ+iOohp9xs5JTxPkrFkadHppwmWzpMd/NFFrn
ckawIvUFlgajqkIg+7qzFWdtmlC+DLEWdC7klOq5Tpu0LncqHXQSXQOUTF2uo4kF8SDWgkkM
UxnAhI0my3hYSWuk+nIoZTNUQ/GwiqmgUPB71qV2S2uEbv7liqk/yayNRHKOXFcqYGW9fpp/
UVDeX6ZW8C5giEGD0KrdAPT1arigYTGejub0EP6wCL7aoMKj7QPcvSZzGJkZrszZIhwNyxUD
fsHZWZ4slt6+cBqQ12aii39hZVvkxS1vbjLTyU0STxUMlwXNc35S0jcyw6pITSpV9XXHAS4T
yW3Xux1sBSezZcw5dQezFSZ+4LpESbDDT5vdpngjsu2y8F84wt94rvaMlI71eh2fltK8qa6r
ijy/KWu0EvhUqtfcY7GNtkVeSKOEmrRiRBE4Vj6fsfp5PlrSKVKnyxHeqAwJTMlqMokWN/gJ
bgJY6owkvFiweEU5EUlCUKuO7e1aBNIwu5ZdBVcbBd+p2K6UKts1VNkKpq5VUAVB5PeoGaZU
7O+07hj2zo6PG92fJOMZM2zbC6pXIgFsGqePskci4im7U6VbdEqQKG3dcAFsDvsWliAX4Vre
nL62BdeV3CF4I8GzRarrSLfV5+P4WwfKPUK3XztmHKf/tZM154277JMed2JEueAEOutEkTzi
aNvywaARlCOzbG/umClbcHELvxcobiC5VLWthTMWIhIL25hj0g90AaVtqM1gR/SVTSJO78TS
PX/ho8g3VrfciSrattK8Bi83f0DZPoOF9qZAXigAm19xxuqStVWIra1C5jE3EzxVnBlIkxLT
VYt+lWw8T8qrFwj/HaJCBHjP//8NnMcaIEgovQ28gBEAu1APQvgOXaeiEVKey87+WZEJ9cRd
/l+u5BEx3yNb4gEv2vecjVmSWF7V9lwSK79UfxUbTOqrxXLzh0/xzRZm7oLP9De4hfmR1Yoh
q+UjS4pSliwGaylLilJGyBzKvsGXKyR6a3aezMaxSgMAP5G0TH/C/E3vplQHEY8rcNEa0uAX
VpV+3cLJo/0tvBot5UrmCZRMQ7wKm9/1zq6BAfv4jWR9TCeGA4Xhey+qSsSJ76Yx2MbhKAnp
9nxZUyo5W7A2fXc+Wy0ceBrA5XIc/ADmr+o3RVzg7sgWyinmmpDxme7GXZP90nuDnIFvPK5I
a8VRujbVJUGTjYIsSegfmoo+6M0f0G8d8jGkjUisdEzs8f0bNR4CihLU60Gyi9zp5zuVijEs
LOpQFlKqqzfWIJ82mu9NUffagZLZ7WwoV6BZL7V008hGc2CJwQLdAyFMnP09TKfxKV9ysr8Q
XJUAKwxkwLMcUB4Z+5l798nEbLKogyoIMllR86LbVhBcRXY7xtYyM9Ye8prdLQ/pTi4cW9Tz
rkbsZ17H5R8FDOt/0vei+I002in9CtjyeGgWD7/dsL8ObGr4maEd4O8P9TevJHFkifVUCxbh
ItHCRaOl+2eTUc46NjQGNdZ34+3p1dYi+uzAeLZZ5bjFpfZA6+NPjCYoLfHCGEvhcltcaz3L
HGLx5x+OwmeJRw7D0oZNSSl6rhUeXr22XilTXL2gj4ooTigj7ksHog8BHxpDJO+p3CXorVjD
vmV+pCeQPNrIRSG5CHmtqbMV77DS8MkYWVUB0LZuXz+wG1AGKNB+9ed8b25NPuALzOpGyh15
3jiACs1cHfBE7r/Po+ReM0WmnWpWN3NTvTJHWG4rmRKBcnmG8fXyL3e2sTON3eVSHSlyyKsO
urJDmv6FfVPq4IVqZfC5S1WfkKSmES33/Xa/ChY3/PGCVSnh4Io5s5rwuKAZXNCbJeWJLraT
YRBjy2oHnqdySYzw0oC33o5xPuEzmMVRjiidY57CgWEMEhnEPVadWl5FU7z0bMY14omUhO1T
5ld48ZlqDDp4MOK+yg4iXZZEgtLJuTp6IW9UMojgb4tnlxG5+1m4bQjciEPCkn8KRYSgi6M4
P1/NMP815tCRBD5Lj61BoxrYtPsg7WDTm4EXlbRZ9XqrqvF2R/wAtdQJj29sHCA4l0ISdjnG
fAR5pUZOHhd6OplzQ1uGPVtKHCtw5HHBc/qPFgm99/uaBMyRJJU6YLhilzvE1vXIOvbKkSpq
e+NBfOhtzchgo7amYy4EJWPMxGvlK7ocXabqFyapHRGzyGzSf8XklnEpYHxyxY2BCkfDYpvn
YzdxoIVpEV8m8MdmIBt60Ey4nly4xlhSDlKKYRVVEamXKlhqjq5/vJSA/71jxR3CSDvidt3e
eXHhbaQ3Y7kev8hu/JVujrz5ddGbqxmcB00ejSX6YqUxooLC4w9ht9U4CA8a/UbxuFAVmmEj
pa1NpVl0J0tuk4Wb1AGlQrA5BKBFl9GWkfeCwkH5KutVNJx9hrmlxC328Agn7toSZ3Z/3xhJ
WchSCGEAeq/dD1nl8H+MvaTDIO5MTgM660uBBuwUMfYZpFFfbzrj7Auad2aDAcghWNnx9Wip
ig1TNr2pDL2ibX5FtzFAdrZMzptFY9CY8M0kxnjbUTJxKu45fIjuwGpFnSI688hvrVoFZqwY
k8cZiygv/8VokA6CXgji9Iyf3wSgh0xnn8fxUNULxB3qN7C86ZBME32HqGni9P+xuuNfMdTJ
b7iTCHT3OGtWG/4nbbDwOsjSguWVtIsLXbKUqDcimZT6M5lxzu5pgBUOWJOTAUEdac1h+YPH
S1XtTliX1jlhtnlGAQ7pPohSjPK4x1ByrRzfZHQKx2twHsP2Hm/oIHC8TDTfUJoq0AfkKbWL
T4tF6Wz4lAtgY0EETPQJhuwEL01I6FGSgIUBC2DA6rM8RdNZG+ThU3IDHDfBVCDLxWys0uph
zReKexf1ti/izypsexHzjTNxwKp6yoGkS6Gdc+AYkAdNipMsjKqRoKpCoEQhgnpEsRoRfKOC
1Nx06cHrYP+sLzohUeDdPVRwRxPoKqq6nKadDAHkCMD2TBUn5I6sEt0LrdJmxexqMxzFgXkz
PzAv1KvPhPecdlp/FNwPOQG0Zmys9NIgW7jRsba3xrfr0Sp6DotoCOiAQbvX+3zFgSUWStPu
dTdmL7Sw8ng4LHVjOVtG41CdT0prA/f3a1lPUyCGcbbRnS5Gs8Vo6Ri/XmrR8q2z5VvTA+A0
/lQfVGeHKNFyFcVG/2BShTjgMqaa55xDVwokMAIGNzDRLZaUwI2ZsqUKPMZVDRlKiEsJhRet
VVmZfHkVe9JW6ACFIuVLjaRueEnQaHo2dTaV+yplahUyLfGCoLQa/hK5G8F3y3+GI3RNjiKZ
3XkSLcCevSq3j49bB+1GvxXuv6sYGkV+bjXJ5oZ68AfrTafvfrIvzgzXO1Rqe8xXdbVn2/q0
nYRRjLk3H4hvvO+UGmR9bpCcwPi12UHsSIQcGZKfH8RQZnoUYIoMqPcSdzy21LWCy9lsqGrD
zi4YhcwnpBYbO1vQijR8MxuBKAlLuyMoxlMuGoQYaLMZzCYTvv+6yWsvsckSyqHeODlwaD5L
kpHw/F5SlWZMgSGlVSxcXGJtMQouRYKbKl/wHSUbYnMVmZiMscBdRYiCDYYGfFdUeOSGKzFh
xDRws9bgMlZqoTwgsEUo8aad9a8f/J6Xqkih/BC8ASRpt4LetI3ot/t06Ge3SPflZZv364wQ
t1QzfdvewUp7FrSHD3//vseqKRN+uQyn+oP56LhG62y4MgrydpVhZl3uB5rwGQwqsx1sEatr
EVme4m/hDfsS1XlxlkPqiK9XlJDBUyRK5vk//rBJMEGt+qxWpf9Vg5YU7wfUaeGMtSPLTNlV
fZROVU3pWb1V6J07XawxmpWfmKa9qrPtVqVT2CjWl01TLYum2n3SVLsVTfUsmur3SVPdQ9MX
qYEwAMt8upr/i68n8ig7C8rumbmmqGKS2umHs4CUm29A+3jMp1MRTNlk9hudPjO4vlPD/2YW
8KxdnETxCbq/yn5qWGM77hycHbXCI1jUJ71W+du3p0fEBOJ546z/rtMtf9uNzuP4Knh/BfrP
zQbmzIwugneziwvQrdg7cRwtYTY+BwdX0WJiosAA4G77tN/unJS/VRKCp5EOL46jxW8xaEeC
479lwu6J0Z4gr90bqvvGFdAxZRKDNYhG5WIpfSPj2edgHMOwyIESrg1yVNpHPFuoEXzFfbyv
H+lTj+5TXdU/cb5GfAjr7+3oMsKzNMWt2vGVmhklXgw+f2UcgPG9NDyTRx8urLyBObuN0zbV
iMhsmqsh6vaF0ZSisKkpFByDqAWcKBhbqwSdecxlCZOgPNqKt6R3ebTc4FuHeKCOBYTi5eBx
ZYvh6pXgAA3OC6TbAEP7ZEPdSDMhWtHgKk0jt5Xo0RwGv42iwNJhGZ41R4GMOiyDoeTtF8pC
rFITi7q9IE0m/HewpD6jTIlE18WYkMqPt1PJgMbLIHgNEE059I+osVF2R6nUW82RbPjsMI7w
bDN5xfUoS6VNnorUUoVnnR40NYznMEDxFAxdkYWZDxRkzTXGEsg6tjKlBedFsyrtCLMXXULS
ITsAaslUljgwOILa39LUxTxMyICYio3uO1J5H+FfA+EdXWLisDUdUowr71dGY3TSEfOiycyW
rNkf4GkezjhvWRlMi+4yiQCm9bd4OkIn7efoRhHXI49tBlupyUOqioEMFU+bIJrTcQostEHC
zBCgx08mBTAGRDcrvqPKw3YqLmS28xhjSRALMexU3BpFyBaNZBDxJVr0cQMTX8CmGxx0G8fB
eTT9lAifu+DkHj5nppLjl8zBqE0UTnSBCYQIKVaf1elTola8UJcR7eVlfn+IuRDk9zPkkbMp
VYtkVUDWjqQSDhYWSZUyZ/mfSizRyL/Sy68ts/7y2/lVlMSGVKB/o4tnjncAhFVvQYh9M1vG
CArOaKEYEgRGIVpwPg0xOMZYoKeGL5ElUkTP0XWND7Fel8zwpqSrQZFwWW6ZneT1y72JpjcM
179+1r2GmVuOfsPVBh9cRWNyeR2392X0i5BvKCJQvaMzT5pwUTgDRSe6rwaDGfcGXdYJhTAt
okm85AxGAoniOmK2LDYz+YsB2dwTedOt3vJ7r/hbL/dEnBbj8Ag/S+qB7FolfNlPCj3lFVrO
RAc9hS9tKhLuhEEFIp5JphNwauz08RAexpL7/pozQl1nj4ZgADpcg0lhh9RgBVLSHRL0aWKq
HKzAigISCZ4wEuh9RE2IBYX+y1fBaXSjKrtjwNqUEwegGBldTimuiw79EuPwW2gYKVH1TA2A
zZ9EI084JQhgeHPpiGmyfVPyspRaVjHqCCpsF4ZFdsbiKc5UkFry80UMkyCi62yxjpOqZ0Eu
HzFMbQpBSoSk0CRTT4a5lMMoyq5aRaN/ixbspsbG1eG82RO5o7xSq0GedS5iimYcUMaBZyof
gRhe5K0hHklykIKMpF2nIqFzdTUdXVBOIH7G+SfxREmPjKHumOMLO661iHAFGgsJZd5FNBmN
R9GCMU7jEY6/QHENADT+5ppSgWGJold2EmPHnNXHi4p0Ew5FPL8hberaAKcS3vxMKbnsCcaR
kn56FifUeaqMPRzh6heyIOj96Dj0xfw8FifEj81hocbYg5xIB7I8SY5+i0Zj2rcVPmRCaHcr
OBQJykql+DoiZQQzsF4H4ja+OBAn5JRthFrQWTiVKBBIuNa4SEsyjxLRNTVhlH/M3IGkdm7u
OrTj9BUNG0WJ8JDAFe8kcykyzJxCOAXGgY2g4DHOyuNAaQCZg2yMAbUsi0yL9CSkuQsBImed
R9073htiLQlRfW4ecIvVCXoe9Q7kJ0oo/PLcPgdHlGYPmVJhaGhy+biBdgbuLUnSvpcWrrhp
gQvPG9EyASkxvpGPvMOMEyAnKFanXvIo8iKQl4hVULPolEGl6oSYHJqOreAEbIEFvBsTzXw8
hnVlpygFhT7BLCSYTJAxE4lsqWULpWiF7vQ/Ts2/0LITHKoex11vvqW46y3MjmuzB+cFSA0e
bY9ieHCVTOjQHZ6qGBe1uxm8IjQNTpwWTEZDTHcEQL0VMIJMSIA5eX/DiBrc4+0DQSTIkCGi
u3R+yDvFmINURM9NoSSDdoQEkxwtGA4/XPIpVSxigmAuU6nLeJeWEU1y/xHX5rXAf6WFsJvy
gs0cQa/BXnqfREm+IVRelj9C86E6tYsNlgQqUsIEVvubK2d7mGVMz57cj9rKHUbcDoM9xwzT
5yOyPkkGiPVAyp6YinOgWnGgWOeOmomwbLMKGblKtD7JaLbk2FELXWOqUeXUm/JSDOJC3bWg
oHxpLImRlhOUOwXoTjHNzMThfhFkJU+xpVJLYJHOiRBNkWPIKEszOy0zThyEDMcYcLMibcyU
JzoL3CVM5FTOMs0EShZ0paMPXsuc/nVqK9eFY0zJw3cu2DB7jEkihAxAE11+n+iMnyZVjlwD
HWc85F5p6R2NE/wQOGXIXLNcjAaOTSeTt0q1ONFWECYmN/UU6jEVwxLsZq98PvWPp8lKZlI3
UoqWSmgpnsfOfRKb/bStwPqMEpwGB+13Gt2D4KjxU+esbwhMEXdO91g2z2fQua0gOJkF/72a
oI9iOIouwVIhNS7GLSda3BhIMQSze9I4Cija57DRbClnJv9OfTat35zVbEynEhXFLNQUj5+U
KxczsMM+Iz6aP8xhhTPl07pNT6o6ETZ/ZLfbBgBfbNhyIWV9yF/2fi0pyGF8MZqKlK5mqfIU
NNv/TrsezwDJ+AxoDDHCxeoBD8QrP3gynEQWBRqcRKd4lQEcL2C6QumtMYH5lXLkpOCtEAGr
57DMoyVJjKHUdY3YZfs2iFxMwf38XN96ykkZEaOBOIfJjUACcr8Sk5WIzcRB64fG0VnLwH8g
oLImNwONiGdW2Cw0YnYLYMP59FAmsSEn2POVQtDqthtHiKLf7RwpHBY5vnk3ditjVLWPNL3t
qZudwsjk7UlK4pQNatvl2voUW6HMUVNit5exYwtZrXNgCX4a74zCwdWnUql5eoY69W8j9Ob3
m6cci5esJqzcma3R3iPgxVXGUrpFe5cRn4tEo57PLU1a+t+NG3gCQioxvG+IzcTQj5Rkvt/f
M8qsrw5O+BwNnrDo4weYd4AFCXccZOViJq6U8Hec/4jzusrgZJUwrRL8F9B92/A0BY3haUiU
2dRBu/dAbZVrwfffB3Rb1ts7GVhbXoh4/o3AavuW1XNSLUu0aQJknx+agvKL4KlBBtMB+lhV
k9M863bD7uFB+LbVL89D1NTpEjGPftl+9CaYh2r7HywXY1F+RX0S/tPqq0Le8yJfiwwv35lg
FvKzXuvAoBzNTody41EW5eoTh3KFvOcgB9wZdBuomG4NRKidYen/mTFfrhnz/m3GfHnLMe//
mTFfrhnzvmfM8yjPH3UdJi4bOWqfvA/PTsN++7gFKnaphPFsVWNBnL77Kdw/6/2kvuAP8BMS
n3iwMDakK57BKEe/eTXv4CBsog5vRg3paMirmxCrZUhVWGvVFBouo88pd5YR7m5E9FmoLrNQ
yRAbrTnTCaBFsEB6PgMNQcGuWIfOIFDffFGxpIOrCLTDQTgdnYO9w12YzXG7YxrWDEt4Dorr
/KZsxaYmC1np3Xo8TJb82Ih+G5H7GDULVBzsKwL3HUWC8TyWFRRsBm37rMA5gBYBJARph4/Y
0SMyq7F16mEH71GCbQogQltWHHoYiGqVoCmOSX3g6kBHRFlYJp5IhowfaoT44xa1a1m+q1fw
Yg8nXVa1pOhe1z9XI1iD6DRnX5YO+g+gjQloRcBvSwPVdkWeiZOCsuZgXEV92AeXBr6dCl20
nJKxR4n7yCsSi7AX7S9d0hkDf0G37qZ403JqoNqtBD1cOfq0FR1X8i0fyDWRTNM3GqhzYu33
MUeR9GP2KSScnVyjJAWSjRnpG6FHwooGom3+kvq9OioiRmufnJ71Dc6wze7SE0egyq9yMAvE
IBVtzL1Yu+9Zv6Xvuq3+Wddk8pMZc899Bp7R71lanmgXhRM67+5KMvY5tb0Y3oA3aUPy9RoY
6QN4k2k8csS09EyUw3AfPzg5aDdOKpnITQ/BmwxLkm9TWaiP2v0+KJz3gZ0zxuKg7h8dowp7
0gl7PzZORTpYfNhXD/XFrv9gz3lnSjLAoQgvxZj9VzXpRQ++MQKVMyi3nR9vsm1kvk7gxyJ1
5VDaR+JSo//rpf9r3/fkNWaDEHPhBKICthf3MvPbR6lqW37CdLEtayWQZ4wFXRFArV4UaOs+
Y8bVz9poWXpuihtn6U3WCABYt89qEX3L4AJzn90y9/w+fwoQTXFWfKDdBqfiOpJyv3NIGfvl
zW1W+ZB15AF6/LUH4rEIWymzc4Ymiad2aZSAD2ysF+waQfoMALNmvOhtxdjYrd4RqPZjm9Gy
hpuLxu38Jvi8GC3F2YtNiAyUepw4kBytJq/v6cAKpRvkUUPqgt2sfPw4kRTcrj2+DiyizYQX
DBPCLeO5iDyylSp2qURT1pMSu+ci+i/NTSNymD5xNQkKqdUfM69YLEBhQlJCmqzCKofRtuXR
NxXMMh6EZbGPYBh5gxHo0BjzOUjAVL68CpKKPcZLtzdmIQ0zPCFTQyFJK4+sCBVqfSI6ZjU3
eASoiXVSwAfWamzbjLisoFpD8R2Gga+S8jnP8i4+l7xGoNe+t67sgdnZoLARCu6BXR+Yqtnv
nuJf+ayRmZtuvZpE+lDbXorXWZlOQPVAD0jrRDoHcRsIT/vdsFo2qRdZT8zawt9luBhUceFf
TBp+rVQqGd3EXaB74O/mYk03F8W62b3nbpo1lH9ZZHZzOKSFoYKB1KqTUahC+Aopr55y3vRn
pkIiHAxhrmZhOBr838izPncqfIc6htTfysmVY6rrplfVGM48vV9Qsha1kRbnli0Iy2JtQ47y
e6uWbHVaN9Vr9RERpYK6Y4skTcSXBMXueP8MGqeechqzZ840VW7XW232aDKEN4LI6F7nccx6
j/xaClzDQ5Oh8hrprEDOSrLSS9h+RF+KCXHFNCPHxCOVuMq0OmT8Dex5X0TXN4RDsOn4xnoy
aAknRt1GUKf5Pt1fHHX6USgZZkcF2PpLxhaIv1MrFOFJiRyhSu2dU0dKpYYWkCLoJaXJlHo2
EYG8m4IV9gw9VcS9RJhIJuWvrRi6Wn+mIjFWYpxYEqsYzjlWxlk4Z5OOZlQ6edb4ok4bc2fI
cT+XHN/zEx5qofc4ZccG4VVKy8GnY+Zv+iufH1DkyM6vfHQY/K4e7XKND0JlfFmlL+s75qc1
elbbq6hymPJNPY13mx5V86Q58ETYODjohkedHx2Rwp3ILnqtQN+1377zwV4ZcncwiOdg+eKV
h0RFyUlm9O7ejrhRQ7URNJrNFiUV4vatwtNfUoTki4+VLT54eWTIEBsN3y9JzFUE2t/iRvpr
z6wFd6FiRp+URPAMMCGudT4u4WKQ6EdHrz7jQ/vQvs6jGkc0+mpKjrAqpaRVSlxlHOCUSrIH
SKWUXpT0mD8gFziZErAU+aCHG6jC6oDvYfPB4ix4tT12xaoh8+xRhe+eMUhiSsI4sUs4uvOG
iGigt4K0+CJDDQPnOCsAFWXA66DUe2XviR7oy1IUpUx1W76obXef524eSSgGDvf9lDxcno/D
2cUFsGHqFaoJ6hVLi6PZQIZ827zOy4DEhSILBWb1+gK0DPWIZJZuEr/Qnz/D45snwc5rzhYr
rimKL7l8q9XmOR4tsX2lKAWMGuHfBK4WESc+MG6aRefIpupCJJ/ulhL4YnAVlMV4UgYOOsXq
tv7eamrp9kqmBqPMnhHJ0YQFKdWni5aBXvWS8oNGesBKxvxkZKAVe58l5Q8amByu3+qGZyft
JhZj61N8yX6j1xLfB7bwD54a0y0tPKv172jKqi0RR/LE4AH1vdpymC9vR1M+SRsmq3JOq3NQ
dD9xyzQJzhYjJ6HHtyDTU2AM/MVoTPmhvuLx/53Hv/a1jL8zAyLk8pXHXjCrhHwxi8E534Bt
XyzG8ZgmGC9fq725uRH0jpu06XaO5elw7rHBW/RrLGYrUMT5oDd22SgJykIOAnJxM1Pfj/6O
M84ayrl6V5GbP58NMDfCbl/N2dfZEWvu7HZ8h9jf6WBW7yRTDJTMcqBqWpEcKdLtstf/HQ/4
YtdXdLxrHmr5Q2AMRyh+FlL4vbaviU30ZNobS7l1HQ4Pz/oVlg+ox5UNLHTiZ6LFOubV66b9
7Okb2M4eZL3qRiobyoYoSOShj0qVVdkdFnnZeKLYxByg3rEcoYJ97J22mugAOj476v+J3npJ
5VzBfkI7HkIzSOz038F//yyBfzyw8KNcAOFkdB7KPAGW6LMTCBSOPyKsSQoD37bzZy43j8/o
8EWr7AYKvvbDITh8fXElQqm/oKjj4z2kkVIAOJ3cMAlLmNYkU+aZfZPXKr6IAExP/FrxN0rp
9cPVZHKjROGpOKmkpzQ+wu6yeEALwhFIFnIytPfDt53OQdhp9lv9nvSHHqC/4rXwgASj4Hv1
8RGm/W12jo7aPeDC1/BOiUhuu7jqheianTO819TL17dGFa8TIh2Z+EBL1Qr8xDgGsQTso2Qz
yKx4IEOyDpftSOBTKeOIWlq96XVoLsT7XocyqE56F5ShR/5JJtLsQ4rMv1IDuX0cr8cct7NL
K2f8m+yiIxieTA69buttxQGjlM/V69oh2Qy7wRNbEIjyRuJjtC8kadnfZx4wGWRsBM7xgrnA
HjIKN3DW1SWtq7cF1lWBTG5yaS1EHuPllbwgWwCxXD/BfS0gmdlSLqHA4XiZSVMuCH1VzEPe
/f6e3SUs/eHWApmd5bKC/+EHH2vTeVft4gEj11zmZJ1nk+OlnXAV6MjtmBL+q0LNe8dtI6c2
J8zIWgJbFkKVLCT4HKHfGTb4Edu2xlljdBlR+iJ+Bg/wpv5oEgOkl98flt373oW9iKfxZ3Kd
I5F5y8FYLvc842mHrhs/WXgl4PCGML7A+7vVdcE5j0RFLTnnOB6Fz4ervhIE1rnw72+osnm1
+lr61tCbVtu1GS3dKEbjxdmteg6lUQGdgS7OhQYJJV7WYbzDGVumf+LQm0695dBubhrVCH3+
K1FdM+OU/AueipuiK0eGZIuPkrOdqesag6vRnEpLnQM8J0O74YCLeHpJNxRkRjqRMoGXEBke
8mqwaRnw9QqRhIRzR1DWA5kTY4U3ZdCRNJoad7tHmHqF74jwbQirmAOmOWGrBCNhBUYZ4jcc
JVRY4S+QQ80rzL4x9iTtKyh9Hm4Xtl1ktxQ9KcHSW87mlMrICrEWUSn00My9ps9geO9+tKZq
X4GLvKYqiivYWouHh9pj1eYiV0iv5B60Uok2KsmKEybqwOYUxMkmSTi0nEN0TRBfNhbCBgj6
ETZVJgErghgJHjFILl5MRlNM/SFokQJOh/xwBJtVGpFzBwl0Vv0tLiImyodY45+2o9XDW/Wb
ANL2BBdSEtLSnRshTA1O6uZxUvdPcFJmDJZv1r4gO92KrsLc1L1fbureOzet6fafYibTb5/y
UCotxOMfsxr0qE4i4g8VHHFS1LQiD7vm8fAteDMjNtI3ApYt7w+UzIz1KRaCmWesP7QdBAMt
Y1jxiJN9YPpkHAtZ0kVRa9QluxazkJQLm9ScNG6PGW+gyGg5eEAFgxu2NmH4cQa5INiuEzvq
hD1+faR/xT5As5eMwsj+u7CSbdld1ajSw53SY76oGuPjnPywQHc4aSB8yg6JCYVUX5gzWLTY
2s6KOeayvzZGMKiIoPxlnB/FbKP8CxbypbuQpdPNE3YvGep2y9d0u/nx6SyLek0b6NzDqS9t
Iax1zGWPlLPc7/enV5i7FnxTW9xyKLKYii2jVB3tLHVB2N+plu+31p36uba4dkCQSR4NhS9K
xGnfn0OP/hENljpumy6lWeyu8ovL64YmLXSW95BrIPDuYsJ1EgQ2MfI4hyONtrLhn8hdsGsv
eU7DlbMdBj+i98lOxRoZyoBFDtWXEqkvHcTpVWvdDxRXA89XyU0w40HmPGrivuCIUr+NOL2Y
lW8vdXnwYVe6HWJquc7yd1Kf49H/8knmLov6ptrxsvycbtYdeU1RnlCJa/XyvOpN+pzBr9xz
1uABmUBG0U+cHZo2y7moKM2TVLA65XmD36UoLC/XqahKchrmDTf2XSDx4gho2i0is7QFQQ7r
BdaBHt0/CKT/km4p1CoiSQNCdU6bnYMW9VK0mTcfJUotZ+W4wc8xqhoT44tjAkHpVzOg1OKH
xlH7QA+rMqQpZQ0uV53AWujGKIGtWGARU6XHBwOq5L++T4+Wevn0qXFIe5uhAJAn8nuzZ9Xr
C/j9Rf5ny6kPm54Qs7OvauMjIpMUVQ+//f3J3S/LBOz6tcL0rqc3Pd7NGIG4kevf/HK2uqyd
zqD4L93F7AOmNQZh7j5W0Fr89z52H/tY/i5WaAejrc7ZxQglfmzLSctO+BJy0psbYxOTwlAl
ge41eo5BgNH1f8rjoSsQUSkCqjt0S1eXSmOjG5DFhCg5sk7VTvncOcu6gU2VYZKVhwJddMgK
E5A5R6gCgMxeRia/gS0jbTj1kwsaEISdUs5O9mykmDHPI6mgD+YABm4yroZhjjiRLc6o0mMg
5Lx0yjGW3IDom4j6hphUrrLlDKiqHOTzEYrUeY8xp8KK62IAhyYjGJTHqrdl8sbpTPoVLvPu
FH4QGGl3kzh0x3J3LM76gZm7UylU7K2rKdOnALWyCpqcKLq7J1lVJ1w/od1OZLIw2McHirwT
YiZ9ftHDvzGgTo7v399ku3h3i5e8W01IFOHCnBR8wwu/ytkxJTk2RrG4spFlu1SVkkLaoS9N
lJ2chmfSrIRh+VVFSYKlW6rCKoZWdEvmPT5ruMTeQGUPcKUa0Z8an73IZFi3Ub7vL93mfaJ0
XdIbwwUsktxI1k6/UZzr8xuPZ1hdyuXQvC9tzhMKxG+zMfRpzEpj9yNlaUGiBWZLkyBEzARS
VeCo7evXfJAXqUBzYWYZH6OV4NIgdA3ZGN6wNMgInlTSHdSHYsyfwbGQ+DtHPypmEoJTcV4o
4nd/2X5V/fUNpsqtiHNIOmBNLUo6z8tINMFNm/VQx6PJSJTS2Nt5Tzleeb0cA3dMQGaR8AF+
fyHe6abLlnzie/e/B/bTHwIYj/2zw0O869H4GPbaP7eysmDYxMnNcG9nky4Y8uhsCRmaJkIP
wFOL/TgW8Xl2m47Z3U1XXzFj8sV1H/jze5P/8QkYo6KIvOSJX0bXv25hvnsaizcWXa89X4rU
/djENU605xuRbF+H8FNSSB7gzo8nrYNw/6cQ5c3vclGIdOxUm6R7dtr3IJ3G10vuynyJvO7m
M9LfPq39Ks6S051kWHuJ0Wk5Zn/BsojhZ6wpBGLnt3LZWpcVhWyD+G12YS4l1aCT2QVAkk/n
2Dw0e3J2dMTXWI1V+zQ95CpeojmeUZK/zPnWHTTmebNWfLSqYqjupf8iyAMrZknhIeokUN17
M+3wlqQ/PV52InJ/7s1UrvWspJt2WquC8s/bnkJiLBSlND3xDUkWSb5kP3gmWPviLh1v6j9t
qvQf2lTp/9tU+bepcitTZZmyVAxTpZ9rqiwNKVsy7JT+ejtlmbZT+kXtlL/CtOj/27Swf9mm
xfLupsXSa1rYynyKc9gqeMQJNftyH1JJJtdr/PCsf2+aeZqx12jmSSQqV7M30t3j6YKI8tRT
qiCjdpLY8pe2MdLXm3GKHNWuU1vBU34wSwFeZirAywJqrfmNqEGV94nSfMUnGZ+t086WXl12
6dVlnYYKKHJ2C79WLH2un6/PLn36bEpfzZwe3fDydvrq8vb6qglmtyaSUGb0Wmix8VKtM8ng
qAkVUWJT1XT8SmyqdE3VYndVK5L3E0wQguxv1KP3t24nrHVWWcYi8xKX0niXWRpv39J4jSyx
Isv5TNwoS2QKYBFqLBPM0WaX0Rv8ayrL/l+iLYvMy1jRAcNWsXbH1NiwSVHNVIVLzmVtquPK
u6xQcXnFnHOR3Xk4/7SkKqj6xjMWRNb7piocq4qNIq+YtZCxPGxeddjY1B8cXUTUNMaxlgWM
ZclS6xr5UtdsNUiLLykPsl2zXCnPbVEHxoCVEKjWYmsbBjb8zKKBbyVS0VTEhVeWEB8nbbCK
MasPh6Ym2b4w6aGKzRQAlK7xPFqKPMeJjTcyFXZBm9DKP0esRus8GsAkdL3KqAZuFafWmEyZ
OVclvx9OsS6pqo7SY0VsR3UMxZMzo/R4TsxVScqqPL5ZxPZs+NVQ7BlfGTiE7cUsGpSany01
FK1ut9NV35qzi8NPuirbXFKkk7WowLk9rE4cdlu9zlm32ZKKsFoY0sgipcYgZcsmvfP+Cyqz
2ODh2UkTqO6HvX6jf9azBVVBjbak63s+CTQP2PnjSfTj9L52nuEm9tr1dMv9JhCFv0PN3KnD
cyHVQy7IpDaRgxnNnFwzunSyxRH4yFm2Sr1dX1flDe0cpr5r858iRkY3Q5MHkoEUa8vs9WqI
imWvNwcwA8JQEBAiPZgAVyhpvSLtV+Pmkw8dq3XuiNACY0B7tohuyTCbP0gFmD27P7e6nfC0
cXDQPnkrHr1tnYTNbpNQwbB+/PgxaCeiMgUHUI6D/+cb+D8eVPhkX/h7yKzAze1mPItAGZpQ
DXoMhZgqx790+UhrCJ0tgAW4Wrjoz8GYGmJl7OBHWtM0p9K0HXNG16GsfqGHZYuRiIrq9PUo
CeTnwJF9OkEIO4eHmB69fcImTSrJpEBjoTbZVQ+kMki+f4OHFmyyANMtP5Xft7onOCHSuw6/
b3+arYIrtM0uotGYScKefa9GBrgd49w2YX+9nsT/Nf2WFXzPFFNkR5ozgCRlc1iE8lM/dxr9
cKDE4yzdE40Mi2v5MKEsPCHJJ/LlPKmYOI0qvMypk/OyrdArg5SZCf0Ss89TYC68Bk13jVHP
X6zmS1FdRkyOr2Pa1HMWhEz4nH/o0fceeqjarEjx4XiVXJEHcT6ai9ymPrsnTV22RSeGRKdk
IW19Ph/fsE4qFWxqjLjCKQO8rmgU0j2ajoBwVHdYgQnOOLTS8BnkbetecVq2/v0Uaxz+LZDx
Q5I6OrpTdIhW6fqIqMjkOCOCArabs/M9MjLyk8BS+wAp2uNoLteeqWqkPS7crTfWJqo8E+t2
LWnueDYtS4nRxrnxXef9gxtKRDAtRhqBzeBwEcd0UZO2urSftoDJZN4GUiZPrA4ITLeoMDjI
728Gi4D9pNQ426JAdzfbU3raZM1uZtRINWoo7K61lWVuBckSc96NplKZMYkylFZV6+kzVbUM
vrUXxrfoEB6OsI8bwWdQMgkK/ouqtcY4hU3vN9gG6CarsbpEWjvjfpXKA+EswItxdPmvZXaI
2SS7A3nsFmbHnzQgtOoPOLs/mTgWFJQg+AbsyNnUZQEhYg9AcQj/3tl3jQ4sBgdtXwljexGP
4yj5Ki0Oe8UXNjvoV9T2wHndSFkiPqvDcKgr66SIxfF1KPk27bdS8BHgV70To3bdi6aYIoDj
hg1V027jLlq/iUHpQ1rfIpFnOqe2tgxd18H3HXspPfpShXfFICgUomDxij6UyXRwG52l5Wu5
syldhVx0QeMc47thGcp93lQsLIHrHnlQDJA73iYnVYLvvnukyoSst1npTEYNzMMPjZZQ1vic
RuIUe90eLH27aTvR1Z5fO98ZOn3G4jEtBWL/IiYFfahPMFL6Ih5HmNNoCN9sn7/lzCdrxZrz
QjprY3rDWzaN/QBTlo8TKZOcXVosnbt5O25Xcvb2DJbFV19cFxX3HbkAJN9SF/8aWgxLWW67
13pj90e0ZCulCqu8UGbooOhtZ21gOmMdiD7Ccve4xQxX7MYSWLH0C1diChqkNmoqqaolthkP
GQ9XgTWOYD1rURjNwh2vcjJL2jI94/H1VbSCVVrqOn426vA0S3M0gzYSDCPZCnKzZ3wtyqTs
pZLpoEzSyn0gVbKb44tm3/dFkB55JEJMjMg05lciFbtZfPk16o7mCnU1R0NRzNEh12mQbqVT
8YwOnX0vlCRfrzj647tLZny315vdTXuz3ble681OVRS/tTe7ayq6dHbjM6HuWLXUHMgMCFvz
fWSHqt+2SqnqHR5tXszG49lnko36wJwWsDiSpEgWkQBe5DgXnl12+aX1XdF0WtU9MU00YuM/
pereVzDyGgXO622mqnaqo/JxBbNbmB5uV00rqs5pF7LVDD/FDO25raxRBkWstcUULgodw+O0
L2KvZRxLHMntTXiBoMmLUTwe8p3k4UhUvoqWpgKsirfLswssY6YOwFdzPNQdRzfIigV/mVHS
qZ5maLNyMxMH4lPWTlgjWC10RWJbFuIEWQveUV67jvJaIJDbJ28fmRdN5Mm33txUfvwMyUjK
hnnLxO3EG0uY+/XelBCVztWiau/ahSh87l9Y710ojwzqPJSehnXVyLgRh72S7LlW9/WrvuvQ
odcVvl2M4t+E69XwVKKZJTYbw9rCLShaLnHgh8YqjFXoOa7BZYYPVfLK/blQu1+fC9VxnGWq
vm3DCphNfWPpV4VP4s/+AcAhtdarwzP3pwx/ZUqqvZzu18FJEkrqi5SfhBlzJrcfcwJI3mVd
KrQwPTKUPbHIumnnlAlSSEsr2c0UUtRMgF/VxRjzaYHjZR+AiEwsfLQsdk6LHgc+dYysjmKR
fSnnhHEga50xd0UwImaVsZxH9kmz2NTt3piX5iTn3/bOnEmsI0/XHyOnNjaTvrW7Gzd9PBPh
4aRlGyQYDgqffy1TzUn71CzeW6OWaJ9a1+tT697ep5ZncxXQLdIF1W114OELEdmxrHQTbTCL
xpyJFbOuR2MYWTZNZTDEJMZkx6NkgptI9yOou8urwpGuYn8EsDW4zdo+Eo1VjDeSVSfknYgN
1sDpX7Tb7+0EMPbjT4RgcLWafkqC1/zRZ/JYCXjQRbBG7gB0RUQ7iZJPtNMpsggBv5fUxDYx
g2g8WI0p/od9cHQw3Rx/kukojz9sAldeX1OSfcKxodLXL+J/rkYLWiJgD0gIPSgjutU1yE9Y
5KQrMhWHuc5YxF5CK1cNjpDUGfgfPpKRiHc/U8r+JI2ECeffAf1d0OzVJ9qqZwYP6JnnjC3s
LEQ8Fh1+5aJvjZeBlXEZWW4vR5ctOwPo/f6ys2mmFllujqJSkJ4l/ysae19+ImyDArFwQb/B
Qyea3WdBjW+IYEFlBoZnezuvdWQUrM6mb2Zy8vXAZrQmR225TITglaJtzMQjC9/zy+y0RHmY
SdAGIrvPAPrkZPgRQ/BFLgLQxYTbCc/+3YRn//8K4RkOjt4HFygb4+lASUXCYEumDDEqFrwt
RnuGSPoXkaJAMhipyb8lqUeSLr92Sdq/tSTtfwwP24ed8Kz7tnXSD/vvuq3eu86RpwYKi1Wi
CUTpzheXe1hIYX6DGQLwDw4sJs+50KExy0OcLLEOxWg2zT5E5Z+TrF/dZ8Kb7KPLq6VogLK/
KBeGuq1NBknqJr6qZobBJ/87XswsVHSLH6dFnYEa5Mqr7AZGPkTgG1nyrNboNV3P557LlI7C
vjHQ+nQ4gd7iuGQxEFfLVcp/G3dmluRhsnQhPd0ywcW1dvyxtYx7AP5L36XnbkJ3sN95eZYx
H6a05Kzu/tW1j5hZy95B3vCPIK8vPUZ6cISMgDX+MzIVzbEcdrpmScv7id3ak4r+iC7qsuEn
siYaI/+NTrb4pAwCY+GA6oeyA3zXV3zx9Cn9U74T/9T4NzfFqY8uxgn/uwg2V4uTYDwZzjbx
LuhmfWvn2Xg0XV0/41uuyTPYBJ9NfmNJBUO6dcVfF/jw0ebm5u1Ql2ov915u1uqb27Wg9uJV
tQr/vyWvNleDzepetfro6dOnhUko1avV7c3q883ai6C28wpw1moWwl1A+J//CX/ZqAZPaxt7
2y+C//xPMsGnaIOHoSmk34UhvILnKF08rxBuOhivhnHwPRPG+ei3rn5Iv0KCca343k1mw9U4
9r76hGrJ2Psqp7FkPpqOZ4NP9NJ8HSUTOWLyHfevtN/uV0vqYnnNelHTL+rWi7p+sWO92NYv
XlgvdtSLWtV6sate1O0Xe+rFjv3iuXrxwn7xQr6oVe0XL+WLuvOiprq+475RfX/hvpGdR/XA
fiN7X0+9kd3fSb2R/X+ReiMGgLQQ+40YgXr6jRiCnfQbMQYvUm/qPAas7NhveAzqnjc8Bjue
NzwGLzxvaAyETmW/oTGo+97QGOz43tAYvPC9wTEQzThvcAzqvjfbOAY73jc4Bi/Um/tUuO6z
Juk942IFi+/wzCMuv4j74BUoWMEYjMKxzI6g6rGAuWDVYEkwNd7X3Mf7+lGqFrlbSFOlGra7
/whPzo6DnRec3GWCybVo/GQ27g1U36qkTbjgNQWeQvi0loOt5sVWz8FWX4uN7m6SZmckiv0I
phBYP+ZZPruL6TEe7Akl9GQmYyfElUvKcWdDYm1PUBepOKn+iB3JhIQOeRsnB3gDB2+NysuY
gEdmCCsnn84fJxW6pxVHA/NMhAnps2vFpnisb4Iq54v5BTa8QeB0iXA6w/aNy6N9lwA6W9bv
oUc4rCoUhEiRY3oQX0Sr8VIOmMpsibLLosKcU29IcVBTwklh7TpYdwogtc5Ugh3G6Wm52Wkc
BeZeamLQL4meU5ATGJzixKLQoRFNlhQanAstYPWeglgNFS+cA5ogZbpLaxl1XgGEydUZFcUl
kSFI8VslqRyFS7zN+0na8To1WJdCyGCy+GIWH5la3oVryh2lkjfigdNkMptSqpPe+/0E62NA
e1NKmcEW7Fpcn84Th5RuAVIWflJWBi2aDcG0uxVOJomwPqJbzPBmGSWfVEDdBZrcksPQT4hW
5Gy5BEP5KhpfUDIzPPYj6Gd6cpb/DMXfBEZ1cMftnHEILkcQAH4iGZg3nsyXNxjEMYKVjdEE
lOqPqCF3JUOL9HnDWcw5y6447E9G00oRkSJqNIkXIWWsEW5PHFCZ6BepDCmffRhGy+VidL4C
WysMymVx8bzcOz4Nm43mu1a4/1O/1auwj1qNLOKgFjBMhPu7AtMdHsOYh9L5hI+W1qM/6NtH
T3FmzJWAqczK8BBbcd/N5vG0nFoIYEx6viUHSXg9AWz2TevgyUZQGMdsntUeGec24cvwCtbG
OF4g/RtsvuvG5hgZfJlktATYJxEbvXGS+BqVCCti4P4v0tQS8iJbqtp49vnfmpr9o433/l2m
7AJ7F0dYmeYQ/T24r73S/ngY6M+zxSej2M0Vf1zIayq+vUDEKFdBV0tAYxssZjDRN/MYdmBO
+6jcq8N4MI5EkUEgxUBIRxbRArhiHLwdXQb7I6OuvAg+G1sVUA9ap62Tg9ZJs93qfTn/3qOn
omdUdScIKZPj/+GIig1OI/kHpXeUuUVYDRHZwC09yFOikg87TAXIrEf4oXF01gr8v/+C3po/
1KfPTtpNvIh/0ukeN47C485Bq1T6PePjg9Zh4+yorzWtaqFvG93T9d/LIsz7zbB9COT0w/Zp
2OkicEGY9mlR7IAzyP622Tjtn3VbYb95Gh52G8etXnjQ7q3//uyg2PfGyGATtxlJbOI23++f
HpxJAB9ngZbDuTSKM5goeEl8Vir52u+dNk645dNG832r3wsbPcFfmTSfNrr9NgoQHDqMFnv0
1KE3GU4ilWY2g0TzPF4QiBSWRAkeCtnvArOjgRDuhHs7++1+UPpdfvO2T17S9ulbjFWDz8vV
CvKJiaPvw8H5UAQlaSxcpSlwfs4wlI1qQEYMgm/WkngxisZrB8Murq0nDLpCsaOdbrMVHrVP
3sPo93pYIuV347UI2muc9TvhSestfh4enJ0efbQ/E9Nlf3d41PkxbPa7R4H1bePgQ9j76fi4
1e+2m+ZH1ldM12GTZBHwDVB31mthQzD4gefT/VP16d8bxwY29J0GdJZqUdwh6WJ0/7DRdonA
K9aNk95xux/W9sJGv986Pu33gvwh6p22Wgfh2+N2u2TTedBvUeerQYoYd/j2f8LJsD9SL6GH
zXeNk7ctd7KwGARwN6+3sLa7W0dl3iG3edTF1RsedTqn+/CliwTzQeHdK5rm1kcaVH+P1dTh
coB22ycmoLkY0vUqgkD5KvVn/fzPaAkcN5oUgj2Pl88W8X/HaGKzHmGyfqPZbJ32AU0TRvyg
S2dkRkPd1t9bTed1TTTA6btkKiw6NxUHuDIm1GzIuv+D01q9rgtEoJtE56ZucoZJUt+OZ+ew
amWFvERv9sftfVBfKNQl0bX3qB2K/09SfjGACN92Ogdhp9lHASu2twOY2x+xw9fVgt+/a799
R0Od/n6/kfpcyqrq9Yv09xTee4I6BAyuWj2tbhe/H2TQI/ZLpwH0gPsJ8n+PAL4edDuNA9Ju
UmAA4OnCMWyb7UwATx/EZ3s7YqQMeY6++myA3RCWdK3+3IADAE8fBECt/gIh6ru7GgIAPH0Q
APXdPQTYrdUsgOw+7NbqRFO1vq0gYCfK7gN8uYMQuGINAE8fTM7rYeAIcyl3etvThxQAs6kA
WMNLCGDNw46nD62PzVavhxphs3N01O6B5mEAePqQYg3dDAB4+pBiPgvA04ezE+A2Wjxyy1bc
V73e9c1D0+2r0endrHk4bKZWDwP4+tDI+h4BvH04aHVJM0rBVK/3/Lz09hg6kV7SCODpQ+dD
VgMI4OnD3xv7+7Cv+Puw5+kDzoA0F/hSkAHwPEMuNbvNsPUhNRsA4OlDiuUsAE8fjhp9D6NK
gIHYRk4N3VDcDsBKlOXTXreS2kFIWh82QAVCfQVaafv4SLSRBXraPM6Goh+ez9vQpHGBLnfQ
+dHT/9yGJejZ6TpAarhmQ5NS3ABZ0jg6FJpK0YYlqKHk5DVct6FBU9AKk1D4DjKgqzmgrZP9
RjYkNrxtQ9PMslJaq1bhfznjVc0DzQOkhlNMroFzQdMNW+2uAcX4CxsaFOR+9tTkNtwnNfa0
23nbhZ1hbcPPbWhW27H9RrMPkuMWDQvQ9XDc8AsPa6I9A+ypjWi8DpjGlcHV68BEwy890DIg
FAlAC+mnQj22QHPARMO1qnIG9K/iJJZqv0xDzx7j07SnjKXfdTgA+Qf6eFqN9ji/Mgmp+kGB
YY7bveZZ56yXCZ8WgmlHWvYIrAOt5Q/eGuh6LnR9DfR2NnQZwYPfiYbKGjQ7uURsr4HezSdi
uyARe4XQ1NeheV4MzVqiDKepH1s2X2jQDN5IS2wvdAZvpMWuFzqDN3AQdrn3O0V6n8EbGGJX
ADqDN5CIvVsQkcEbBprdImgyeMNE4ycqxzmewuaqEOzxKALp2ddcD7u/A+sbzof07Gtph/3d
Gs6H9OxrsC81jnEjPzs9QLWbTICwd3Z83Oi6+xTFU9rg/sODQnR7QFtZKjJFZfrB7WOIW7Vs
gOa2nL38jQONQi17QbOlVi17zWvwbLFVe14APEdu1Z4Lsb2Xvdo1omzJ5fqevOA5oqv24jZ0
5Agvheh5EUQ54ksjWk+ZcYjlR5jNIxo0h0deFgDP5hHXa+cFz+GRelWMwMsiI5DBI4QoW3XT
8DlMUq/dhpAcJpGI6tUiiHKYRCNaT5l5cunHmD1PBqyfTSgGvAi4n00oULwIuJ9NaCikHpij
TxqI/GxCYelFwP1cQnTs3IoOP5dYiLYLIfJziY3IoOxO5p843FZW4EdhBrpWYPMI7O/24U/Z
e5415A7f5Zx2p6DXgvY7WYaEx5/lHpnnkO0a4AqUD/TW9LiuJ+D6WVcGhcoCHDS+3X80u8/6
8J+KO7piDRdoyTe6YhUXha75oOtFoes+6O2i0Ns+6J2i0Ds+6N2i0Ls+6L2i0Hs+6OdFoZ/7
53s9U/rUfjnfBaFf+ue7ILR7yCgnvCi4l9t2CoN72W23MLiX3/YKg3sZ7nlh8N3CQrknAndc
x1zvoJnll+u2D/dzKbCJSTvNjRCdmgjz8f9yQeu5oGlx448vyoROHxMY0C9yoXOca07v9/Lw
pKXW/tExYgDzt/djY80xS1pqCWiMPVkL73rBAbRfvOFdL/RdGpbBq51uby28z+mkodfRnj5w
uCub9m/Hpq6u641hywHfzgMvwKhZum7/dqyKum5hqePEyImD0EyJI4Ll6GRinQh0tTgDdN2W
mRZWbhRe3s/jzk/FsmUjcRrOjO9bD+qN+cuATcs5X8M6FvD2DWfApmUbRuDBGs1qK6/hrMjF
jFna8c1xVkRjbsM2aP+jBvU2vOuDduIji/XYBgW4nIPVtBLogw7B3MBkkN1uCvpF5pqg0My8
n8sh/uDOLLJdDTAj7LNIywYotN760Or6wWTL7kp2WVsHk3rBt/MXVQ50ashUcOr6XwZozhGk
RbTrrPAHvxZp2e1vDqTPY+2JqC3a526r12/gwblAsa7PjsLgRurWXlCkbpGWXdB6PRvU4+zO
iBHOBHfjkCzwl9W81nNdyw6i2ss1dLzMBX9era6h42UGHRjubIVD5/w8fuFUNHXOL6UxeAKt
c1qupcGNIKZccP+yyY/fNlp2naRiwRaB9/TZCCqiSNOsEJ8CoFmxQR51FcEd6NtMlNtw3kTt
KPUU9gHSOVN65nEbdN6eOkgUKT8AohpsBj9iyuaNoEY58KOhRu5DQykpPzSO2gcCzfM7oemc
NnGPpmRvpSrVlJhN5uOY05hdMAZV5ykPBRIUiLwngKajYEaJqCZ5SZnHzJ+KgcerO8qlKKIX
qYxFYkb5Cydk8J1bisHIhmzxe87hLf5QQFQrOXjNKsOWwenJd+0i3q4ZmAsQe9R0400dYqul
IHCE2Fl3DQxKPhcIYwnXAdVdoCMgr3fSOEXt5riRttIQ6GUge1xseihqNocSX48xALh7dpIJ
5+0xbhp0sB0etU7eSsZY02NZmzirqbLlhXGAPxw1TsJ+4+3bjIDNsu/8i84CiM6ciXFP4VS4
AA0Nhnd8sM6LyiSyXL45WANE+4479P138C2D9X86TRFZ9hn5R42fAKiOcbs0Lu6ZWtl3aKTb
SJOmgNwgGQZ6B1IIV2Z6QyYgN04Hdi8qRE3FWLOG3D3MxrDcdjcbioBcfePs5P0JyAuE6bdP
GnT8gneQLKAX6Zbc7Pnpllw24iHfAc221XwPws8dDBJO1Yylisn4ONVuarnyAMuQ/TRjEzEZ
Mi9LkKZo1QNbKtEicfmdqcCtGTZkXGYeKmruNKtF4pvjIEO2HqyB8cU5vG2dUGMILPuUAnJZ
A4GYz70wQp92gH5uddGTcHDQPvEaIV4J0y/C7ikJU4TdXWGBfQL5njF2GcKiX4TdXWFBlliO
Emyzu0o64LupL3PYUq4exF3FdJgb4h81+EdN/qMO/wD1+A8+UO10+RJwGh3mNcCCLLKomsTc
eb/BqbW6ssxNhBWl5vGACkp5fpT1RWk1GwR8uJoOo0k8XUZjrgvhhTSBqXgwAzdnq/HQqvVH
Ga2T5VbQX9wEmPWa8emWVXU2xkAZbpza37JquL95XeLPwGCXtvB3wcFAXCx36BSiJIhkDWRR
pGvLQsSz5lTPyZjAZbS4jDVHgPH/FkAOQDBsOI9aH9rNlvOwud9znpw229X0o5okih+9ttzc
mJYLs3Kcjy43MStqNEWlGAY8xmE+Gi2XYxg7fjGNY9CZMWtqjOXUKOkFLRa+SipzeP3H6EKk
nRiWw3AfL/afHLQbJxU9BCJJTSiKClEZE8phVdsrqdI1VDBSl0eR5bX0JqLmjsBk/bqSvm9L
Kb6yp3y1XS/JMoZOY4654EJRjTWqyIJleaj8oVPMRd7rTbcoi/n4u+fAaY4S9WYsTjKHcZk3
jOmxU+MmigHSZ1QfZzH7bTTEFG7NUy6Ynqwm/vFq8iA9M22qvDE61fVvvLVv3NEx6uWIDiCn
LjH3iwP6hxTxaoj+Ix5bbHjU7vdB9hfnxLvxxh0Z8Y5sfxdu+jP8ewdOLM4yt+TFoix+Z566
GxO7nAh8mMT4B1VW6kwpj50pFQN47LBnMIFdBTO5CfZ9JBNWs+A+m45g3IZyzJF+ULSRI0Ex
Vu6UhOptY2K6BddAXupKEUA70oqjBtI/mozGI/iKMznGI0wtgKimjNhQtfM0AJcTVBE+Kzdh
coUq0F143cZgcgqQmmKWpmSWNAKqbHD7lW2C337R2YnkngRmfTUqVIrTpHQVo+CqLFzIvCWL
6KlEbk6djgR0PGCOAYEakP6FqsstSg2Eikmo3JElRZmvGogYlxcl+l6moPtl71fdIcG/DEVJ
NkQafr3AmAYK4THay81N5cKFHI352gctIzV90AkVgBNNW7DCY0gIvJAUARCKCAAHODOFjoYH
CUmBjqFgOCFYFlgIcjn6LVbpMZMAeHgSyXrMCsFiHYKuFwFnlCRSgWmj5eAqmEecbZTkhGIf
OydpIustjoZPuP055y7lpI2YbqzkVHl7LWra5lesJcilB7K/BpI7wiGjlFMXlNZpdDlRRX5j
6eLdCg4BUGT6g04a4LTl6QKflCmOEjvz8qN8vG7NSbeQevjPjSBVHLIw+r4P/dJBv/SjNztP
6gU2gHUGgOOAAaHJ3CHwVs/E4qlmycpU5XfzpcqwmpJtXF7Smzv3V6bfaryvG1/mNb4s0vjS
bryfblyb1Y4olbkft66Cxmk7oLyn6mSAFpc+q1DBP1xqJQl8xTdoqVBWUqvFdKVUTMzpBabS
uv4yPwYMJQHUBYIwfWmRFlNtUu8poagQrIv4MrfGEG5v1hRxOrLXmSWMuIXLAi0wgelKkIGu
/cQVhriUjcjwaM1D8Up0diUUb5WknE5l12UqiNfS7k6dvbIAi6146w0zeUVOl2qYK6nMCawi
HQKn734iIYI5o3yNSjbjSZxf3axjzwwGpeqxYTIZFeEvO6s1tXmZ8VYxX0a7IDaGBZvNbdUu
b5NuVU3OYBxHi3AyOg9Ftbkkb6zk3NPee4FZavOEjMfJZPLidFi4OrO/MPPrtS0tVTFolMpu
cxI7/e5QGHp9+2JOBzHsazmt57R915bzy2DfQ889LBwvaCdROyRu/AWnGJsy988M+U15veU3
qEgY0iGDmMXdiVl4iRFvcFhph8+kc+HSmfcloXN6xDK3xH5ys5ARLrL8wlCidtCzKJlsTkbz
ZG/nGeJN5tEgTleHyv86s0RUPhiWdapv1qqb9e2g+vJVfedVvZoq6+SpE7Ueq1ksau/V7o63
WNSLnY294Cn89zkWiwoeBYbLNyiLLKlgk4fdne1qtUIsX/qvR8T0v/+e8eVH+aXIXpr14fHz
qv4yF+VuwQ9PWh8aB40iXx63T3t7OxUahFod+/+0Vt/dqNVoHOTJ0fuz/UYPE8RWzWcUiQ4G
nC4EJav0UGgMf/CIk4oSI6NZFslidnj0Ib3rqBKlRkQfXL2vyuavX76oWj/pjwo830aeb0kv
cT4OWx+Pwh+7pZKCRd35GhgrQcsTlGMuDw/EupAnnZNm552PMMQxnU0Hsys6WvABQ7NEZjUN
qVu/y+IdzQqtWvzsNssVvxcram+zthtUq69qu6+2n99xnRro1i/QnW1coPDfWpU506p3lozQ
w0YYf4B3Ypbtg5v0invkVk0DujbPZ9FimAhUWpENbC7tvW2H7dP680fkjllMHRF9vkrC5Qwk
NPqP6rt7YKcFt5/GeXRZTPzyh7eZSoa4x8m0EK6fzlqNBC7+oSY0NVW9Nt8x2q9dX1+HvU6z
opfQaeNtS+aTTa/0syPFBT4eOO4ct2Ddhp1m66jTD5vGGbmN113UgFd9CWpUoxmSwIAPq54P
JRsqosNwHpWvQSyXyxa/VAJ4GmyajVdMqN8klKh64QV/aoFXbs9u7OYrxHDy09uwnIQxma72
4tVO/VU9XcCxGNM5KBXbPX+1+9LLdrvPN2rbwVP+w9zgJCfQfMJ/zg6CciDrx2F94L2gYs6k
+p4vNFERr9KL6qPNzA8Eo1wMEaMZH535pfxJiOzm69x8LbP5ut18Nbv5ur/5qtV86ACBgtzu
c6EX5IMKqx2bpf8D/1wNSVF95RnijWC0+OcrciSQIzR5FfT6B2GzcxweHjXe9jYwl/btcZQb
vZ/AxNnvdPjiAS764PeAn/bet0/DfqvXrwD2AJSS0WwSTwT68uoFVmPFf2yIF2Amh8nV6GL5
KqhvsDZFQCEePwC9ov+d8Lh1HPyhh8gVMfaludbhSY8H6f8DeYvHAQUzAgA=
--------------010909070505070600010105--


From macro@ds2.pg.gda.pl Mon Jul 21 16:50:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 16:50:35 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:16370 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225214AbTGUPu3>; Mon, 21 Jul 2003 16:50:29 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA17133;
	Mon, 21 Jul 2003 17:50:10 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Mon, 21 Jul 2003 17:50:08 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Kevin D. Kissell" <kevink@mips.com>
cc: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <02a701c34f81$4f32ca50$10eca8c0@grendel>
Message-ID: <Pine.GSO.3.96.1030721172805.13489C-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: 2837
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 21 Jul 2003, Kevin D. Kissell wrote:

> >  Any justifiable reason for getting rid of arch/mips64?
> 
> In my opinion, it should never have existed.  The vast majority
> of MIPS-specific kernel code can be identical for 32-bit and 64-bit
> versions of the architecture.  Creating arch/mips64 (as opposed
> to arch/mips/mips64 or Ralf's arch/mips/mm-64) caused duplication 
> of modules that then needed to be maintained in parallel - but which 
> often were not.

 Well, duplication is certainly undesireable, but is it the result of
separate arch/mips and arch/mips64 trees or is it a side effect only? 
These separate trees have an advantage of a clear distinction between
these architectures.  And arch/sparc vs arch/sparc64 were the first case
of such a split and they seem to feel quite well. 

 I'd rather keep arch/mips/{lib,mm} and arch/mips64/{lib,mm} where they
used to be and add, say, arch/mips/{lib,mm}-generic for common stuff. 

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


From frederic@meurou.com Mon Jul 21 17:47:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 17:47:29 +0100 (BST)
Received: from sd20.sivit.org ([IPv6:::ffff:81.91.65.104]:19898 "HELO
	sd20.sivit.org") by linux-mips.org with SMTP id <S8225214AbTGUQrS>;
	Mon, 21 Jul 2003 17:47:18 +0100
Received: (qmail 23864 invoked by uid 1006); 21 Jul 2003 16:50:44 -0000
Received: from unknown (HELO ARennes-201-1-4-201.w81-53.abo.wanadoo.fr) (81.53.134.201)
  by sd20.sivit.org with SMTP; 21 Jul 2003 16:50:44 -0000
Subject: SGI O2, MIPS R10k and Linux
From: =?ISO-8859-1?Q?Fr=E9d=E9ric?= MEUROU <frederic@meurou.com>
To: linux-mips@linux-mips.org
Content-Type: text/plain; charset=iso-8859-15
Message-Id: <1058813390.30494.12.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.0 
Date: 21 Jul 2003 18:49:50 +0000
Content-Transfer-Encoding: 8bit
Return-Path: <frederic@meurou.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: 2838
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: frederic@meurou.com
Precedence: bulk
X-list: linux-mips

Is there a kernel that works on such a workstation?



-- 
Frédéric MEUROU <frederic@meurou.com>


From ilya@gateway.total-knowledge.com Mon Jul 21 18:22:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 18:22:33 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:39055
	"HELO alpha.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225214AbTGURWb>; Mon, 21 Jul 2003 18:22:31 +0100
Received: (qmail 15205 invoked from network); 21 Jul 2003 17:22:27 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with SMTP; 21 Jul 2003 17:22:27 -0000
Received: (qmail 19559 invoked by uid 502); 21 Jul 2003 17:22:27 -0000
Date: Mon, 21 Jul 2003 10:22:27 -0700
From: Ilya Volynets-Evenbach <ilya@theIlya.com>
To: Fr?d?ric MEUROU <frederic@meurou.com>
Cc: linux-mips@linux-mips.org
Subject: Re: SGI O2, MIPS R10k and Linux
Message-ID: <20030721172227.GA19461@gateway.total-knowledge.com>
References: <1058813390.30494.12.camel@localhost>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm"
Content-Disposition: inline
In-Reply-To: <1058813390.30494.12.camel@localhost>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2839
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Check out http://www.linux-mips.org/~glaurung/
There is a kernel there, that is kinda-sorta bootable.
However, do not expect *any* stability. R10K in O2's and I2's
has a problem, that needs rather intrusive modifications to kernel
to work arround it.

	Ilya.

On Mon, Jul 21, 2003 at 06:49:50PM +0000, Fr?d?ric MEUROU wrote:
> Is there a kernel that works on such a workstation?
>=20
>=20
>=20
> --=20
> Fr?d?ric MEUROU <frederic@meurou.com>
>=20
>=20

--uAKRQypu60I7Lcqm
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/HCFT7sVBmHZT8w8RAu1qAJ43YRzlN0xtdFSmsoiugZtmI+csQwCgnwLt
GsIaiCyGA7P8JHJdXbOzoE0=
=jAB6
-----END PGP SIGNATURE-----

--uAKRQypu60I7Lcqm--

From jsun@mvista.com Mon Jul 21 18:26:38 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 18:26:41 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:37108 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225221AbTGUR0i>;
	Mon, 21 Jul 2003 18:26:38 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6LHQVQ17635;
	Mon, 21 Jul 2003 10:26:31 -0700
Date: Mon, 21 Jul 2003 10:26:31 -0700
From: Jun Sun <jsun@mvista.com>
To: =?iso-8859-1?Q?Vincent_Stehl=E9?= <vincent.stehle@free.fr>
Cc: linux-mips <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: PATCH: time.c needs to export more funcs
Message-ID: <20030721102631.C17287@mvista.com>
References: <3F1AC15A.6050604@free.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F1AC15A.6050604@free.fr>; from vincent.stehle@free.fr on Sun, Jul 20, 2003 at 06:20:42PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2840
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Sun, Jul 20, 2003 at 06:20:42PM +0200, Vincent Stehlé wrote:
> 
> Hi,
> 
> time.c needs to export some more functions for modules such as mips_rtc.
> 
> Regards,
> 
> ---
> diff -urN -X dontdiff linux/arch/mips/kernel/time.c 
> linux-vs/arch/mips/kernel/time.c
> --- linux/arch/mips/kernel/time.c       2003-07-18 03:30:14.000000000 +0200
> +++ linux-vs/arch/mips/kernel/time.c    2003-07-18 03:41:19.000000000 +0200
> @@ -585,3 +585,6 @@
>   }
> 
>   EXPORT_SYMBOL(rtc_lock);
> +EXPORT_SYMBOL(to_tm);
> +EXPORT_SYMBOL(rtc_set_time);
> +EXPORT_SYMBOL(rtc_get_time);
> 

Thanks.  Just applied.

Jun

From wesolows@foobazco.org Mon Jul 21 19:20:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 19:20:09 +0100 (BST)
Received: from janus.foobazco.org ([IPv6:::ffff:198.144.194.226]:46468 "EHLO
	mail.foobazco.org") by linux-mips.org with ESMTP
	id <S8225221AbTGUSUG>; Mon, 21 Jul 2003 19:20:06 +0100
Received: by mail.foobazco.org (Postfix, from userid 1014)
	id AA4F6FA38; Mon, 21 Jul 2003 11:20:02 -0700 (PDT)
Date: Mon, 21 Jul 2003 11:20:02 -0700
From: Keith M Wesolowski <wesolows@foobazco.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Kevin D. Kissell" <kevink@mips.com>, ralf@linux-mips.org,
	linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030721182002.GA28587@foobazco.org>
References: <02a701c34f81$4f32ca50$10eca8c0@grendel> <Pine.GSO.3.96.1030721172805.13489C-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.1030721172805.13489C-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.5.4i
Return-Path: <wesolows@foobazco.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: 2841
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wesolows@foobazco.org
Precedence: bulk
X-list: linux-mips

On Mon, Jul 21, 2003 at 05:50:08PM +0200, Maciej W. Rozycki wrote:

>  Well, duplication is certainly undesireable, but is it the result of
> separate arch/mips and arch/mips64 trees or is it a side effect only? 
> These separate trees have an advantage of a clear distinction between
> these architectures.  And arch/sparc vs arch/sparc64 were the first case
> of such a split and they seem to feel quite well. 

sparc32 and sparc64 processors and systems are significantly
different.  For example, the SRMMU present in v8 CPUs is 100% replaced
with a totally different MMU (indeed, totally different instructions,
access methods, etc) in v9.  Accordingly there is very little code in
common between the two ports, and most of that is in device handling;
code that is in drivers/sbus and thus shared anyway.

Something that made sense for sparc might not make sense for mips.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"May Buddha bless all stubborn people!"
				-- Uliassutai Karakorum Blake

From ralf@linux-mips.org Mon Jul 21 22:14:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 22:14:07 +0100 (BST)
Received: from p508B6C3C.dip.t-dialin.net ([IPv6:::ffff:80.139.108.60]:4246
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225193AbTGUVOF>; Mon, 21 Jul 2003 22:14:05 +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 h6LLE2DB006219;
	Mon, 21 Jul 2003 23:14:02 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6LLE2bA006218;
	Mon, 21 Jul 2003 23:14:02 +0200
Date: Mon, 21 Jul 2003 23:14:02 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030721211402.GC5188@linux-mips.org>
References: <02a701c34f81$4f32ca50$10eca8c0@grendel> <Pine.GSO.3.96.1030721172805.13489C-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.1030721172805.13489C-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: 2842
X-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, Jul 21, 2003 at 05:50:08PM +0200, Maciej W. Rozycki wrote:

>  Well, duplication is certainly undesireable, but is it the result of
> separate arch/mips and arch/mips64 trees or is it a side effect only? 
> These separate trees have an advantage of a clear distinction between
> these architectures.  And arch/sparc vs arch/sparc64 were the first case
> of such a split and they seem to feel quite well. 
> 
>  I'd rather keep arch/mips/{lib,mm} and arch/mips64/{lib,mm} where they
> used to be and add, say, arch/mips/{lib,mm}-generic for common stuff. 

Technically these are probably equivalent.  I just felt having mm-32 and
mm-64 makes it more explicit that something can't be shared but really,
that's just directory names and I don't feel strong about them.
I even have some hope that with continuing cleanup mm-32 and mm-64, which
are supposed to contain only things that due to conflicts can't live in
mm, will finally become empty.

  Ralf

From kwalker@broadcom.com Mon Jul 21 23:28:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jul 2003 23:28:26 +0100 (BST)
Received: from mms2.broadcom.com ([IPv6:::ffff:63.70.210.59]:5642 "EHLO
	mms2.broadcom.com") by linux-mips.org with ESMTP
	id <S8225220AbTGUW2Y>; Mon, 21 Jul 2003 23:28:24 +0100
Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.5.2)); Mon, 21 Jul 2003 15:24:51 -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 PAA09376 for <linux-mips@linux-mips.org>; Mon, 21 Jul 2003 15:27:51
 -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
 h6LMSFov019439 for <linux-mips@linux-mips.org>; Mon, 21 Jul 2003 15:28:
 15 -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 PAA28252 for
 <linux-mips@linux-mips.org>; Mon, 21 Jul 2003 15:28:15 -0700
Message-ID: <3F1C68FF.58E4E94D@broadcom.com>
Date: Mon, 21 Jul 2003 15:28:15 -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: n32 signal stuff
X-WSS-ID: 1302B7B92208867-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: 2843
X-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

I've just checked in (with Ralf's approval) some changes for N32 signal
handling that came up as 64-bit tool and glibc support evolved in the
last few months.  Both 2.4 and 2.5/2.6 versions are there, but 2.4 has
had much more testing.

Credit where credit is due: this code was worked on by Chris Demetriou
and I just helped massage it into the public tree.

Hopefully there are no major complaints with this, although minor tweaks
are expected :-)

Kip


From ralf@linux-mips.org Tue Jul 22 00:37:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 00:37:04 +0100 (BST)
Received: from p508B6C3C.dip.t-dialin.net ([IPv6:::ffff:80.139.108.60]:7583
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225230AbTGUXgw>; Tue, 22 Jul 2003 00:36: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 h6LNapDB013269;
	Tue, 22 Jul 2003 01:36:51 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6LNanvM013268;
	Tue, 22 Jul 2003 01:36:49 +0200
Date: Tue, 22 Jul 2003 01:36:49 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: 64bit Sead build
Message-ID: <20030721233649.GA6900@linux-mips.org>
References: <Pine.GSO.4.44.0307211027270.16227-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0307211027270.16227-100000@ares.mmc.atmel.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: 2844
X-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, Jul 21, 2003 at 10:32:55AM -0400, David Kesselring wrote:

> I'm trying to build linux for Sead in 64 bit. I found that it would not
> compile without the change at the end of this note. After this fix, I got
> the following link error. Does anyone have an idea why?

> mips64el-linux-ld --oformat elf32-tradlittlemips -G 0 -static  -Ttext
> 0x80100000 arch/mips64/kernel/head.o
> arch/mips64/kernel/init_task.o init/main.o init/version.o init/do_mounts.o
> \
>         --start-group \
>         arch/mips64/kernel/kernel.o arch/mips64/mm/mm.o kernel/kernel.o
> mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o \
>          drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
> drivers/net/net.o drivers/media/media.o \
>         net/network.o \
>         arch/mips64/lib/lib.a
> /home/dkesselr/MIPS/linux-mips-cvs/2003Jul18/linux-build-mips64b/lib/lib.a
> arch/mips/mips-boards/sead/sead.o
> arch/mips/mips-boards/generic/mipsboards.o \
>         --end-group \
>         -o vmlinux
> mips64el-linux-ld: warning: cannot find entry symbol __start; defaulting
> to 0000000080100000
> mips64el-linux-ld: vmlinux: Not enough room for program headers (allocated
> 3, need 4)

It may not be obvious but this is ld's way of telling you it doesn't
feel happy with the options and input files; in some case it could also
be considered an insufficiency of ld ...

In this particular case the bug is that the kernel configuration doesn't
set CONFIG_BOOT_ELF32.

I'm a bit surprised to see somebody's actually using a 64-bit kernel on a
SEAD.

  Ralf

From Geert.Uytterhoeven@sonycom.com Tue Jul 22 02:22:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 02:22:18 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:20130 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225236AbTGVBWQ>;
	Tue, 22 Jul 2003 02:22:16 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h6M1M91W010790
	for <linux-mips@linux-mips.org>; Tue, 22 Jul 2003 03:22:09 +0200 (MEST)
Date: Tue, 22 Jul 2003 03:22:10 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20030722005641Z8225235-1272+3651@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0307220321300.27391-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2845
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 22 Jul 2003 ralf@linux-mips.org wrote:
> Modified files:
> 	arch/mips/mm   : Makefile c-sb1.c pg-r3k.c 
> 	arch/mips/mm-32: pg-r4k.S 
> 	arch/mips/mm-64: init.c 
> Added files:
> 	arch/mips/mm   : pgtable-32.c pgtable-64.c 

Euh, shouldn't these be in mm-32 and mm-64 then?

> Log message:
> 	Move pgd_init and pmd_init to their own files.

Gr{oetje,eeting}s,

						Geert, reading mail, not code

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From macro@ds2.pg.gda.pl Tue Jul 22 08:58:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 08:58:53 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:17089 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224821AbTGVH6u>; Tue, 22 Jul 2003 08:58:50 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA00949;
	Tue, 22 Jul 2003 09:58:47 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 22 Jul 2003 09:58:46 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: linux-mips@linux-mips.org
Subject: [patch] Generic time fixes
Message-ID: <Pine.GSO.3.96.1030722093500.607A-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: 2846
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

Hello,

 In preparation to merging DECstation's time support with the generic
version I did the following clean-ups to generic time support.  Most of
these are coding style fixes (which might have already been fixed by
someone else during past two days -- I haven't been able to study the
changes), but there are a few code changes (detailed below) as well.

 Before I proceed further I need to get an aswer to the following
question: why do we use rtc_set_time() for NTP RTC updates instead of
rtc_set_mmss() like most other architectures do?  Traditionally Linux only
updated minutes and seconds in this context and I don't think we need to
do anything more.  And setting minutes and seconds only is way, way
faster. Which might not matter that much every 11 minutes, except doing
things slowly here incurs a disruption in the latency of the timer
interrupt, which NTP might not like and the slow calculation of the RTC
time causes less precise time being stored in the RTC chip. 

 It's already questionable whether the update should be done at all (this
was discussed zillion of times at the NTP group) and it disrupts
timekeeping of the DECstation severely, but given the current choice, I'd
prefer to make it as lightweight as possible.

 Here are the changes done:

1. Explicit variable initializations that used zero or NULL are removed.

2. Inline assembly returns a result in "hi" instead of doing an explicit
"mfhi"; clobbers for "lo" and "accum" are added.

3. local_timer_interrupt() is called with arguments passed from the above
instead of fake ones (although "irq" and "dev_id" could be completely
removed here; in the next iteration, I suppose). 

4. ISO C initializers for timer_irqaction; improves readability.

5. Leap years are handled properly.

6. Missing "extern" qualifiers for function declarations are added.

 OK to apply?

  Maciej

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

patch-mips-2.4.21-20030711-mips-time-0
diff -up --recursive --new-file linux-mips-2.4.21-20030711.macro/arch/mips/kernel/time.c linux-mips-2.4.21-20030711/arch/mips/kernel/time.c
--- linux-mips-2.4.21-20030711.macro/arch/mips/kernel/time.c	2003-04-23 02:56:41.000000000 +0000
+++ linux-mips-2.4.21-20030711/arch/mips/kernel/time.c	2003-07-21 20:28:39.000000000 +0000
@@ -1,9 +1,10 @@
 /*
  * Copyright 2001 MontaVista Software Inc.
  * Author: Jun Sun, jsun@mvista.com or jsun@junsun.net
+ * Copyright (c) 2003  Maciej W. Rozycki
  *
  * Common time service routines for MIPS machines. See
- * Documents/MIPS/README.txt.
+ * Documentation/mips/time.README.
  *
  * 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
@@ -70,7 +71,7 @@ void do_gettimeofday(struct timeval *tv)
 {
 	unsigned long flags;
 
-	read_lock_irqsave (&xtime_lock, flags);
+	read_lock_irqsave(&xtime_lock, flags);
 	*tv = xtime;
 	tv->tv_usec += do_gettimeoffset();
 
@@ -81,7 +82,7 @@ void do_gettimeofday(struct timeval *tv)
 	if (jiffies - wall_jiffies)
 		tv->tv_usec += USECS_PER_JIFFY;
 
-	read_unlock_irqrestore (&xtime_lock, flags);
+	read_unlock_irqrestore(&xtime_lock, flags);
 
 	if (tv->tv_usec >= 1000000) {
 		tv->tv_usec -= 1000000;
@@ -91,7 +92,7 @@ void do_gettimeofday(struct timeval *tv)
 
 void do_settimeofday(struct timeval *tv)
 {
-	write_lock_irq (&xtime_lock);
+	write_lock_irq(&xtime_lock);
 
 	/* This is revolting. We need to set the xtime.tv_usec
 	 * correctly. However, the value in this location is
@@ -111,7 +112,7 @@ void do_settimeofday(struct timeval *tv)
 	time_maxerror = NTP_PHASE_LIMIT;
 	time_esterror = NTP_PHASE_LIMIT;
 
-	write_unlock_irq (&xtime_lock);
+	write_unlock_irq(&xtime_lock);
 }
 
 
@@ -128,14 +129,11 @@ void do_settimeofday(struct timeval *tv)
  */
 
 
-/* This is for machines which generate the exact clock. */
-#define USECS_PER_JIFFY (1000000/HZ)
-
 /* usecs per counter cycle, shifted to left by 32 bits */
-static unsigned int sll32_usecs_per_cycle=0;
+static unsigned int sll32_usecs_per_cycle;
 
 /* how many counter cycles in a jiffy */
-static unsigned long cycles_per_jiffy=0;
+static unsigned long cycles_per_jiffy;
 
 /* Cycle counter value at the previous timer interrupt.. */
 static unsigned int timerhi, timerlo;
@@ -165,34 +163,33 @@ unsigned long fixed_rate_gettimeoffset(v
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
 
-	__asm__("multu\t%1,%2\n\t"
-	        "mfhi\t%0"
-	        :"=r" (res)
-	        :"r" (count),
-	         "r" (sll32_usecs_per_cycle));
+	__asm__("multu	%1,%2"
+		: "=h" (res)
+		: "r" (count), "r" (sll32_usecs_per_cycle)
+		: "lo", "accum");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
 	 * the result so that we'll get a timer that is monotonic.
 	 */
 	if (res >= USECS_PER_JIFFY)
-		res = USECS_PER_JIFFY-1;
+		res = USECS_PER_JIFFY - 1;
 
 	return res;
 }
 
 /*
- * Cached "1/(clocks per usec)*2^32" value.
+ * Cached "1/(clocks per usec) * 2^32" value.
  * It has to be recalculated once each jiffy.
  */
 static unsigned long cached_quotient;
 
 /* Last jiffy when calibrate_divXX_gettimeoffset() was called. */
-static unsigned long last_jiffies = 0;
+static unsigned long last_jiffies;
 
 
 /*
- * This is copied from dec/time.c:do_ioasic_gettimeoffset() by Mercij.
+ * This is copied from dec/time.c:do_ioasic_gettimeoffset() by Maciej.
  */
 unsigned long calibrate_div32_gettimeoffset(void)
 {
@@ -210,7 +207,7 @@ unsigned long calibrate_div32_gettimeoff
 			unsigned long r0;
 			do_div64_32(r0, timerhi, timerlo, tmp);
 			do_div64_32(quotient, USECS_PER_JIFFY,
-			            USECS_PER_JIFFY_FRAC, r0);
+				    USECS_PER_JIFFY_FRAC, r0);
 			cached_quotient = quotient;
 		}
 	}
@@ -221,9 +218,10 @@ unsigned long calibrate_div32_gettimeoff
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
 
-	__asm__("multu  %2,%3"
-	        : "=l" (tmp), "=h" (res)
-	        : "r" (count), "r" (quotient));
+	__asm__("multu  %1,%2"
+		: "=h" (res)
+		: "r" (count), "r" (quotient)
+		: "lo", "accum");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
@@ -247,27 +245,24 @@ unsigned long calibrate_div64_gettimeoff
 
 	if (tmp && last_jiffies != tmp) {
 		last_jiffies = tmp;
-		__asm__(".set\tnoreorder\n\t"
-	        ".set\tnoat\n\t"
-	        ".set\tmips3\n\t"
-	        "lwu\t%0,%2\n\t"
-	        "dsll32\t$1,%1,0\n\t"
-	        "or\t$1,$1,%0\n\t"
-	        "ddivu\t$0,$1,%3\n\t"
-	        "mflo\t$1\n\t"
-	        "dsll32\t%0,%4,0\n\t"
-	        "nop\n\t"
-	        "ddivu\t$0,%0,$1\n\t"
-	        "mflo\t%0\n\t"
-	        ".set\tmips0\n\t"
-	        ".set\tat\n\t"
-	        ".set\treorder"
-	        :"=&r" (quotient)
-	        :"r" (timerhi),
-	         "m" (timerlo),
-	         "r" (tmp),
-	         "r" (USECS_PER_JIFFY));
-	        cached_quotient = quotient;
+		__asm__(".set	push\n\t"
+			".set	noreorder\n\t"
+			".set	noat\n\t"
+			".set	mips3\n\t"
+			"lwu	%0,%2\n\t"
+			"dsll32	$1,%1,0\n\t"
+			"or	$1,$1,%0\n\t"
+			"ddivu	$0,$1,%3\n\t"
+			"mflo	$1\n\t"
+			"dsll32	%0,%4,0\n\t"
+			"nop\n\t"
+			"ddivu	$0,%0,$1\n\t"
+			"mflo	%0\n\t"
+			".set	pop"
+			: "=&r" (quotient)
+			: "r" (timerhi), "m" (timerlo),
+			  "r" (tmp), "r" (USECS_PER_JIFFY));
+		cached_quotient = quotient;
 	}
 
 	/* Get last timer tick in absolute kernel time */
@@ -276,18 +271,17 @@ unsigned long calibrate_div64_gettimeoff
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
 
-	__asm__("multu\t%1,%2\n\t"
-	        "mfhi\t%0"
-	        :"=r" (res)
-	        :"r" (count),
-	         "r" (quotient));
+	__asm__("multu	%1,%2"
+		: "=h" (res)
+		: "r" (count), "r" (quotient)
+		: "lo", "accum");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
 	 * the result so that we'll get a timer that is monotonic.
 	 */
 	if (res >= USECS_PER_JIFFY)
-		res = USECS_PER_JIFFY-1;
+		res = USECS_PER_JIFFY - 1;
 
 	return res;
 }
@@ -317,8 +311,8 @@ void local_timer_interrupt(int irq, void
 			 * put them into the last histogram slot, so if
 			 * present, they will show up as a sharp peak.
 			 */
-			if (pc > prof_len-1)
-			pc = prof_len-1;
+			if (pc > prof_len - 1)
+				pc = prof_len - 1;
 			atomic_inc((atomic_t *)&prof_buffer[pc]);
 		}
 	}
@@ -345,7 +339,7 @@ void timer_interrupt(int irq, void *dev_
 
 		/* check to see if we have missed any timer interrupts */
 		if ((count - expirelo) < 0x7fffffff) {
-			/* missed_timer_count ++; */
+			/* missed_timer_count++; */
 			expirelo = count + cycles_per_jiffy;
 			write_c0_compare(expirelo);
 		}
@@ -365,7 +359,7 @@ void timer_interrupt(int irq, void *dev_
 	 * CMOS clock accordingly every ~11 minutes. rtc_set_time() has to be
 	 * called as close as possible to 500 ms before the new second starts.
 	 */
-	read_lock (&xtime_lock);
+	read_lock(&xtime_lock);
 	if ((time_status & STA_UNSYNC) == 0 &&
 	    xtime.tv_sec > last_rtc_update + 660 &&
 	    xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
@@ -373,11 +367,11 @@ void timer_interrupt(int irq, void *dev_
 		if (rtc_set_time(xtime.tv_sec) == 0) {
 			last_rtc_update = xtime.tv_sec;
 		} else {
-			last_rtc_update = xtime.tv_sec - 600;
 			/* do it again in 60 s */
+			last_rtc_update = xtime.tv_sec - 600;
 		}
 	}
-	read_unlock (&xtime_lock);
+	read_unlock(&xtime_lock);
 
 	/*
 	 * If jiffies has overflowed in this timer_interrupt we must
@@ -396,7 +390,7 @@ void timer_interrupt(int irq, void *dev_
 	 * In SMP mode, local_timer_interrupt() is invoked by appropriate
 	 * low-level local timer interrupt handler.
 	 */
-	local_timer_interrupt(0, NULL, regs);
+	local_timer_interrupt(irq, dev_id, regs);
 
 #else	/* CONFIG_SMP */
 
@@ -463,18 +457,15 @@ asmlinkage void ll_local_timer_interrupt
  *	c) enable the timer interrupt
  */
 
-void (*board_time_init)(void) = NULL;
-void (*board_timer_setup)(struct irqaction *irq) = NULL;
+void (*board_time_init)(void);
+void (*board_timer_setup)(struct irqaction *irq);
 
-unsigned int mips_counter_frequency = 0;
+unsigned int mips_counter_frequency;
 
 static struct irqaction timer_irqaction = {
-	timer_interrupt,
-	SA_INTERRUPT,
-	0,
-	"timer",
-	NULL,
-	NULL
+	.handler = timer_interrupt,
+	.flags = SA_INTERRUPT,
+	.name = "timer",
 };
 
 void __init time_init(void)
@@ -541,15 +532,15 @@ void __init time_init(void)
 #define STARTOFTIME		1970
 #define SECDAY			86400L
 #define SECYR			(SECDAY * 365)
-#define leapyear(year)		((year) % 4 == 0)
-#define days_in_year(a)		(leapyear(a) ? 366 : 365)
-#define days_in_month(a)	(month_days[(a) - 1])
+#define leapyear(y)		((!((y) % 4) && ((y) % 100)) || !((y) % 400))
+#define days_in_year(y)		(leapyear(y) ? 366 : 365)
+#define days_in_month(m)	(month_days[(m) - 1])
 
 static int month_days[12] = {
 	31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
 };
 
-void to_tm(unsigned long tim, struct rtc_time * tm)
+void to_tm(unsigned long tim, struct rtc_time *tm)
 {
 	long hms, day, gday;
 	int i;
@@ -564,16 +555,16 @@ void to_tm(unsigned long tim, struct rtc
 
 	/* Number of years in days */
 	for (i = STARTOFTIME; day >= days_in_year(i); i++)
-	day -= days_in_year(i);
+		day -= days_in_year(i);
 	tm->tm_year = i;
 
 	/* Number of months in days left */
 	if (leapyear(tm->tm_year))
-	days_in_month(FEBRUARY) = 29;
+		days_in_month(FEBRUARY) = 29;
 	for (i = 1; day >= days_in_month(i); i++)
-	day -= days_in_month(i);
+		day -= days_in_month(i);
 	days_in_month(FEBRUARY) = 28;
-	tm->tm_mon = i-1;	/* tm_mon starts from 0 to 11 */
+	tm->tm_mon = i - 1;		/* tm_mon starts from 0 to 11 */
 
 	/* Days are what is left over (+1) from all that. */
 	tm->tm_mday = day + 1;
@@ -581,7 +572,7 @@ void to_tm(unsigned long tim, struct rtc
 	/*
 	 * Determine the day of week
 	 */
-	tm->tm_wday = (gday + 4) % 7; /* 1970/1/1 was Thursday */
+	tm->tm_wday = (gday + 4) % 7;	/* 1970/1/1 was Thursday */
 }
 
 EXPORT_SYMBOL(rtc_lock);
diff -up --recursive --new-file linux-mips-2.4.21-20030711.macro/arch/mips64/kernel/time.c linux-mips-2.4.21-20030711/arch/mips64/kernel/time.c
--- linux-mips-2.4.21-20030711.macro/arch/mips64/kernel/time.c	2003-04-23 02:56:48.000000000 +0000
+++ linux-mips-2.4.21-20030711/arch/mips64/kernel/time.c	2003-07-21 20:28:39.000000000 +0000
@@ -1,9 +1,10 @@
 /*
  * Copyright 2001 MontaVista Software Inc.
  * Author: Jun Sun, jsun@mvista.com or jsun@junsun.net
+ * Copyright (c) 2003  Maciej W. Rozycki
  *
  * Common time service routines for MIPS machines. See
- * Documents/MIPS/README.txt.
+ * Documentation/mips/time.README.
  *
  * 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
@@ -70,7 +71,7 @@ void do_gettimeofday(struct timeval *tv)
 {
 	unsigned long flags;
 
-	read_lock_irqsave (&xtime_lock, flags);
+	read_lock_irqsave(&xtime_lock, flags);
 	*tv = xtime;
 	tv->tv_usec += do_gettimeoffset();
 
@@ -81,7 +82,7 @@ void do_gettimeofday(struct timeval *tv)
 	if (jiffies - wall_jiffies)
 		tv->tv_usec += USECS_PER_JIFFY;
 
-	read_unlock_irqrestore (&xtime_lock, flags);
+	read_unlock_irqrestore(&xtime_lock, flags);
 
 	if (tv->tv_usec >= 1000000) {
 		tv->tv_usec -= 1000000;
@@ -91,7 +92,7 @@ void do_gettimeofday(struct timeval *tv)
 
 void do_settimeofday(struct timeval *tv)
 {
-	write_lock_irq (&xtime_lock);
+	write_lock_irq(&xtime_lock);
 
 	/* This is revolting. We need to set the xtime.tv_usec
 	 * correctly. However, the value in this location is
@@ -111,7 +112,7 @@ void do_settimeofday(struct timeval *tv)
 	time_maxerror = NTP_PHASE_LIMIT;
 	time_esterror = NTP_PHASE_LIMIT;
 
-	write_unlock_irq (&xtime_lock);
+	write_unlock_irq(&xtime_lock);
 }
 
 
@@ -128,14 +129,11 @@ void do_settimeofday(struct timeval *tv)
  */
 
 
-/* This is for machines which generate the exact clock. */
-#define USECS_PER_JIFFY (1000000/HZ)
-
 /* usecs per counter cycle, shifted to left by 32 bits */
-static unsigned int sll32_usecs_per_cycle=0;
+static unsigned int sll32_usecs_per_cycle;
 
 /* how many counter cycles in a jiffy */
-static unsigned long cycles_per_jiffy=0;
+static unsigned long cycles_per_jiffy;
 
 /* Cycle counter value at the previous timer interrupt.. */
 static unsigned int timerhi, timerlo;
@@ -165,34 +163,33 @@ unsigned long fixed_rate_gettimeoffset(v
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
 
-	__asm__("multu\t%1,%2\n\t"
-	        "mfhi\t%0"
-	        :"=r" (res)
-	        :"r" (count),
-	         "r" (sll32_usecs_per_cycle));
+	__asm__("multu	%1,%2"
+		: "=h" (res)
+		: "r" (count), "r" (sll32_usecs_per_cycle)
+		: "lo", "accum");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
 	 * the result so that we'll get a timer that is monotonic.
 	 */
 	if (res >= USECS_PER_JIFFY)
-		res = USECS_PER_JIFFY-1;
+		res = USECS_PER_JIFFY - 1;
 
 	return res;
 }
 
 /*
- * Cached "1/(clocks per usec)*2^32" value.
+ * Cached "1/(clocks per usec) * 2^32" value.
  * It has to be recalculated once each jiffy.
  */
 static unsigned long cached_quotient;
 
 /* Last jiffy when calibrate_divXX_gettimeoffset() was called. */
-static unsigned long last_jiffies = 0;
+static unsigned long last_jiffies;
 
 
 /*
- * This is copied from dec/time.c:do_ioasic_gettimeoffset() by Mercij.
+ * This is copied from dec/time.c:do_ioasic_gettimeoffset() by Maciej.
  */
 unsigned long calibrate_div32_gettimeoffset(void)
 {
@@ -210,7 +207,7 @@ unsigned long calibrate_div32_gettimeoff
 			unsigned long r0;
 			do_div64_32(r0, timerhi, timerlo, tmp);
 			do_div64_32(quotient, USECS_PER_JIFFY,
-			            USECS_PER_JIFFY_FRAC, r0);
+				    USECS_PER_JIFFY_FRAC, r0);
 			cached_quotient = quotient;
 		}
 	}
@@ -221,9 +218,10 @@ unsigned long calibrate_div32_gettimeoff
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
 
-	__asm__("multu  %2,%3"
-	        : "=l" (tmp), "=h" (res)
-	        : "r" (count), "r" (quotient));
+	__asm__("multu  %1,%2"
+		: "=h" (res)
+		: "r" (count), "r" (quotient)
+		: "lo", "accum");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
@@ -247,27 +245,24 @@ unsigned long calibrate_div64_gettimeoff
 
 	if (tmp && last_jiffies != tmp) {
 		last_jiffies = tmp;
-		__asm__(".set\tnoreorder\n\t"
-	        ".set\tnoat\n\t"
-	        ".set\tmips3\n\t"
-	        "lwu\t%0,%2\n\t"
-	        "dsll32\t$1,%1,0\n\t"
-	        "or\t$1,$1,%0\n\t"
-	        "ddivu\t$0,$1,%3\n\t"
-	        "mflo\t$1\n\t"
-	        "dsll32\t%0,%4,0\n\t"
-	        "nop\n\t"
-	        "ddivu\t$0,%0,$1\n\t"
-	        "mflo\t%0\n\t"
-	        ".set\tmips0\n\t"
-	        ".set\tat\n\t"
-	        ".set\treorder"
-	        :"=&r" (quotient)
-	        :"r" (timerhi),
-	         "m" (timerlo),
-	         "r" (tmp),
-	         "r" (USECS_PER_JIFFY));
-	        cached_quotient = quotient;
+		__asm__(".set	push\n\t"
+			".set	noreorder\n\t"
+			".set	noat\n\t"
+			".set	mips3\n\t"
+			"lwu	%0,%2\n\t"
+			"dsll32	$1,%1,0\n\t"
+			"or	$1,$1,%0\n\t"
+			"ddivu	$0,$1,%3\n\t"
+			"mflo	$1\n\t"
+			"dsll32	%0,%4,0\n\t"
+			"nop\n\t"
+			"ddivu	$0,%0,$1\n\t"
+			"mflo	%0\n\t"
+			".set	pop"
+			: "=&r" (quotient)
+			: "r" (timerhi), "m" (timerlo),
+			  "r" (tmp), "r" (USECS_PER_JIFFY));
+		cached_quotient = quotient;
 	}
 
 	/* Get last timer tick in absolute kernel time */
@@ -276,18 +271,17 @@ unsigned long calibrate_div64_gettimeoff
 	/* .. relative to previous jiffy (32 bits is enough) */
 	count -= timerlo;
 
-	__asm__("multu\t%1,%2\n\t"
-	        "mfhi\t%0"
-	        :"=r" (res)
-	        :"r" (count),
-	         "r" (quotient));
+	__asm__("multu	%1,%2"
+		: "=h" (res)
+		: "r" (count), "r" (quotient)
+		: "lo", "accum");
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check
 	 * the result so that we'll get a timer that is monotonic.
 	 */
 	if (res >= USECS_PER_JIFFY)
-		res = USECS_PER_JIFFY-1;
+		res = USECS_PER_JIFFY - 1;
 
 	return res;
 }
@@ -317,8 +311,8 @@ void local_timer_interrupt(int irq, void
 			 * put them into the last histogram slot, so if
 			 * present, they will show up as a sharp peak.
 			 */
-			if (pc > prof_len-1)
-			pc = prof_len-1;
+			if (pc > prof_len - 1)
+				pc = prof_len - 1;
 			atomic_inc((atomic_t *)&prof_buffer[pc]);
 		}
 	}
@@ -345,7 +339,7 @@ void timer_interrupt(int irq, void *dev_
 
 		/* check to see if we have missed any timer interrupts */
 		if ((count - expirelo) < 0x7fffffff) {
-			/* missed_timer_count ++; */
+			/* missed_timer_count++; */
 			expirelo = count + cycles_per_jiffy;
 			write_c0_compare(expirelo);
 		}
@@ -365,7 +359,7 @@ void timer_interrupt(int irq, void *dev_
 	 * CMOS clock accordingly every ~11 minutes. rtc_set_time() has to be
 	 * called as close as possible to 500 ms before the new second starts.
 	 */
-	read_lock (&xtime_lock);
+	read_lock(&xtime_lock);
 	if ((time_status & STA_UNSYNC) == 0 &&
 	    xtime.tv_sec > last_rtc_update + 660 &&
 	    xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
@@ -373,11 +367,11 @@ void timer_interrupt(int irq, void *dev_
 		if (rtc_set_time(xtime.tv_sec) == 0) {
 			last_rtc_update = xtime.tv_sec;
 		} else {
-			last_rtc_update = xtime.tv_sec - 600;
 			/* do it again in 60 s */
+			last_rtc_update = xtime.tv_sec - 600;
 		}
 	}
-	read_unlock (&xtime_lock);
+	read_unlock(&xtime_lock);
 
 	/*
 	 * If jiffies has overflowed in this timer_interrupt we must
@@ -396,7 +390,7 @@ void timer_interrupt(int irq, void *dev_
 	 * In SMP mode, local_timer_interrupt() is invoked by appropriate
 	 * low-level local timer interrupt handler.
 	 */
-	local_timer_interrupt(0, NULL, regs);
+	local_timer_interrupt(irq, dev_id, regs);
 
 #else	/* CONFIG_SMP */
 
@@ -463,18 +457,15 @@ asmlinkage void ll_local_timer_interrupt
  *	c) enable the timer interrupt
  */
 
-void (*board_time_init)(void) = NULL;
-void (*board_timer_setup)(struct irqaction *irq) = NULL;
+void (*board_time_init)(void);
+void (*board_timer_setup)(struct irqaction *irq);
 
-unsigned int mips_counter_frequency = 0;
+unsigned int mips_counter_frequency;
 
 static struct irqaction timer_irqaction = {
-	timer_interrupt,
-	SA_INTERRUPT,
-	0,
-	"timer",
-	NULL,
-	NULL
+	.handler = timer_interrupt,
+	.flags = SA_INTERRUPT,
+	.name = "timer",
 };
 
 void __init time_init(void)
@@ -541,15 +532,15 @@ void __init time_init(void)
 #define STARTOFTIME		1970
 #define SECDAY			86400L
 #define SECYR			(SECDAY * 365)
-#define leapyear(year)		((year) % 4 == 0)
-#define days_in_year(a)		(leapyear(a) ? 366 : 365)
-#define days_in_month(a)	(month_days[(a) - 1])
+#define leapyear(y)		((!((y) % 4) && ((y) % 100)) || !((y) % 400))
+#define days_in_year(y)		(leapyear(y) ? 366 : 365)
+#define days_in_month(m)	(month_days[(m) - 1])
 
 static int month_days[12] = {
 	31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
 };
 
-void to_tm(unsigned long tim, struct rtc_time * tm)
+void to_tm(unsigned long tim, struct rtc_time *tm)
 {
 	long hms, day, gday;
 	int i;
@@ -564,16 +555,16 @@ void to_tm(unsigned long tim, struct rtc
 
 	/* Number of years in days */
 	for (i = STARTOFTIME; day >= days_in_year(i); i++)
-	day -= days_in_year(i);
+		day -= days_in_year(i);
 	tm->tm_year = i;
 
 	/* Number of months in days left */
 	if (leapyear(tm->tm_year))
-	days_in_month(FEBRUARY) = 29;
+		days_in_month(FEBRUARY) = 29;
 	for (i = 1; day >= days_in_month(i); i++)
-	day -= days_in_month(i);
+		day -= days_in_month(i);
 	days_in_month(FEBRUARY) = 28;
-	tm->tm_mon = i-1;	/* tm_mon starts from 0 to 11 */
+	tm->tm_mon = i - 1;		/* tm_mon starts from 0 to 11 */
 
 	/* Days are what is left over (+1) from all that. */
 	tm->tm_mday = day + 1;
@@ -581,7 +572,7 @@ void to_tm(unsigned long tim, struct rtc
 	/*
 	 * Determine the day of week
 	 */
-	tm->tm_wday = (gday + 4) % 7; /* 1970/1/1 was Thursday */
+	tm->tm_wday = (gday + 4) % 7;	/* 1970/1/1 was Thursday */
 }
 
 EXPORT_SYMBOL(rtc_lock);
diff -up --recursive --new-file linux-mips-2.4.21-20030711.macro/include/asm-mips/time.h linux-mips-2.4.21-20030711/include/asm-mips/time.h
--- linux-mips-2.4.21-20030711.macro/include/asm-mips/time.h	2003-07-16 01:17:24.000000000 +0000
+++ linux-mips-2.4.21-20030711/include/asm-mips/time.h	2003-07-21 21:02:58.000000000 +0000
@@ -1,6 +1,7 @@
 /*
  * Copyright (C) 2001, 2002, MontaVista Software Inc.
  * Author: Jun Sun, jsun@mvista.com or jsun@junsun.net
+ * Copyright (c) 2003  Maciej W. Rozycki
  *
  * include/asm-mips/time.h
  *     header file for the new style time.c file and time services.
@@ -13,7 +14,7 @@
  */
 
 /*
- * Please refer to Documentation/MIPS/time.README.
+ * Please refer to Documentation/mips/time.README.
  */
 
 #ifndef _ASM_TIME_H
@@ -24,7 +25,7 @@
 #include <linux/rtc.h>                  /* for struct rtc_time */
 
 /*
- * RTC ops.  By default, they point a no-RTC functions.
+ * RTC ops.  By default, they point to no-RTC functions.
  *	rtc_get_time - mktime(year, mon, day, hour, min, sec) in seconds.
  *	rtc_set_time - reverse the above translation and set time to RTC.
  */
@@ -36,12 +37,12 @@ extern int (*rtc_set_time)(unsigned long
  * It is intended to help implement rtc_set_time() functions.
  * Copied from PPC implementation.
  */
-extern void to_tm(unsigned long tim, struct rtc_time * tm);
+extern void to_tm(unsigned long tim, struct rtc_time *tm);
 
 /*
  * do_gettimeoffset(). By default, this func pointer points to
  * do_null_gettimeoffset(), which leads to the same resolution as HZ.
- * Higher resolution versions are vailable, which gives ~1us resolution.
+ * Higher resolution versions are available, which give ~1us resolution.
  */
 extern unsigned long (*do_gettimeoffset)(void);
 
@@ -58,17 +59,17 @@ extern void timer_interrupt(int irq, voi
 /*
  * the corresponding low-level timer interrupt routine.
  */
-asmlinkage void ll_timer_interrupt(int irq, struct pt_regs *regs);
+extern asmlinkage void ll_timer_interrupt(int irq, struct pt_regs *regs);
 
 /*
  * profiling and process accouting is done separately in local_timer_interrupt
  */
-void local_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs);
-asmlinkage void ll_local_timer_interrupt(int irq, struct pt_regs *regs);
+extern void local_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs);
+extern asmlinkage void ll_local_timer_interrupt(int irq, struct pt_regs *regs);
 
 /*
  * board specific routines required by time_init().
- * board_time_init is defaulted to NULL and can remains so.
+ * board_time_init is defaulted to NULL and can remain so.
  * board_timer_setup must be setup properly in machine setup routine.
  */
 struct irqaction;
diff -up --recursive --new-file linux-mips-2.4.21-20030711.macro/include/asm-mips64/time.h linux-mips-2.4.21-20030711/include/asm-mips64/time.h
--- linux-mips-2.4.21-20030711.macro/include/asm-mips64/time.h	2003-01-11 19:23:38.000000000 +0000
+++ linux-mips-2.4.21-20030711/include/asm-mips64/time.h	2003-07-21 21:02:58.000000000 +0000
@@ -1,6 +1,7 @@
 /*
  * Copyright (C) 2001, 2002, MontaVista Software Inc.
  * Author: Jun Sun, jsun@mvista.com or jsun@junsun.net
+ * Copyright (c) 2003  Maciej W. Rozycki
  *
  * include/asm-mips/time.h
  *     header file for the new style time.c file and time services.
@@ -13,7 +14,7 @@
  */
 
 /*
- * Please refer to Documentation/MIPS/time.README.
+ * Please refer to Documentation/mips/time.README.
  */
 
 #ifndef _ASM_TIME_H
@@ -24,7 +25,7 @@
 #include <linux/rtc.h>                  /* for struct rtc_time */
 
 /*
- * RTC ops.  By default, they point a no-RTC functions.
+ * RTC ops.  By default, they point to no-RTC functions.
  *	rtc_get_time - mktime(year, mon, day, hour, min, sec) in seconds.
  *	rtc_set_time - reverse the above translation and set time to RTC.
  */
@@ -36,12 +37,12 @@ extern int (*rtc_set_time)(unsigned long
  * It is intended to help implement rtc_set_time() functions.
  * Copied from PPC implementation.
  */
-extern void to_tm(unsigned long tim, struct rtc_time * tm);
+extern void to_tm(unsigned long tim, struct rtc_time *tm);
 
 /*
  * do_gettimeoffset(). By default, this func pointer points to
  * do_null_gettimeoffset(), which leads to the same resolution as HZ.
- * Higher resolution versions are vailable, which gives ~1us resolution.
+ * Higher resolution versions are available, which give ~1us resolution.
  */
 extern unsigned long (*do_gettimeoffset)(void);
 
@@ -58,17 +59,17 @@ extern void timer_interrupt(int irq, voi
 /*
  * the corresponding low-level timer interrupt routine.
  */
-asmlinkage void ll_timer_interrupt(int irq, struct pt_regs *regs);
+extern asmlinkage void ll_timer_interrupt(int irq, struct pt_regs *regs);
 
 /*
  * profiling and process accouting is done separately in local_timer_interrupt
  */
-void local_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs);
-asmlinkage void ll_local_timer_interrupt(int irq, struct pt_regs *regs);
+extern void local_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs);
+extern asmlinkage void ll_local_timer_interrupt(int irq, struct pt_regs *regs);
 
 /*
  * board specific routines required by time_init().
- * board_time_init is defaulted to NULL and can remains so.
+ * board_time_init is defaulted to NULL and can remain so.
  * board_timer_setup must be setup properly in machine setup routine.
  */
 struct irqaction;


From jbglaw@dvmwest.gt.owl.de Tue Jul 22 09:33:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 09:33:04 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:37392 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224821AbTGVIdC>; Tue, 22 Jul 2003 09:33:02 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id A03C34A86D; Tue, 22 Jul 2003 10:32:55 +0200 (CEST)
Date: Tue, 22 Jul 2003 10:32:55 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722083255.GQ7452@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <Pine.GSO.3.96.1030722093500.607A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="xiprIVX1FSGBv8kC"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030722093500.607A-100000@delta.ds2.pg.gda.pl>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
Return-Path: <jbglaw@dvmwest.gt.owl.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: 2847
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


--xiprIVX1FSGBv8kC
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2003-07-22 09:58:46 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1030722093500.607A-100000@delta.ds2.pg.gda.=
pl>:
> Hello,
>=20
>  In preparation to merging DECstation's time support with the generic
> version I did the following clean-ups to generic time support.  Most of
> these are coding style fixes (which might have already been fixed by
> someone else during past two days -- I haven't been able to study the
> changes), but there are a few code changes (detailed below) as well.

Nice to see you working on the DECstations again! Mine are not yet set
up in my cellar, but I'm slowly reaching there. Yesterday we had some
harsh thunderstorms (incl lightnings...) and I'm still recovering...
Maybe my assurance need to step in:(

MfG, JBG

--=20
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier B=FCrger" | im Internet! |   im Ira=
k!
      ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

--xiprIVX1FSGBv8kC
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/HPa3Hb1edYOZ4bsRAlRWAJ9cJ7TEyVuyztWYu9y4wRmS6OvHmgCfZY1M
HQZKMrQR+60Yjy3DY6/1m+E=
=zP15
-----END PGP SIGNATURE-----

--xiprIVX1FSGBv8kC--

From ralf@linux-mips.org Tue Jul 22 11:04:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 11:04:53 +0100 (BST)
Received: from p508B5B34.dip.t-dialin.net ([IPv6:::ffff:80.139.91.52]:50885
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTGVKEv>; Tue, 22 Jul 2003 11:04:51 +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 h6MA4jDB011658;
	Tue, 22 Jul 2003 12:04:45 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6MA4iBA011657;
	Tue, 22 Jul 2003 12:04:44 +0200
Date: Tue, 22 Jul 2003 12:04:44 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722100444.GA4148@linux-mips.org>
References: <Pine.GSO.3.96.1030722093500.607A-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.1030722093500.607A-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: 2848
X-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, Jul 22, 2003 at 09:58:46AM +0200, Maciej W. Rozycki wrote:

>  Before I proceed further I need to get an aswer to the following
> question: why do we use rtc_set_time() for NTP RTC updates instead of
> rtc_set_mmss() like most other architectures do?  Traditionally Linux only
> updated minutes and seconds in this context and I don't think we need to
> do anything more.  And setting minutes and seconds only is way, way
> faster. Which might not matter that much every 11 minutes, except doing
> things slowly here incurs a disruption in the latency of the timer
> interrupt, which NTP might not like and the slow calculation of the RTC
> time causes less precise time being stored in the RTC chip. 
> 
>  It's already questionable whether the update should be done at all (this
> was discussed zillion of times at the NTP group) and it disrupts
> timekeeping of the DECstation severely, but given the current choice, I'd
> prefer to make it as lightweight as possible.

It's a common case to have a system boot up with the RTC date being
completly off, then syncing via ntpdate and xntp to the accurate time.
If in that situation we only update the time the RTC will stay way far
from reality.  Another case would be updates of the time near midnight
where the RTC and NTP date happen to just differ.

I share your dislike of updating the RTC for performance reasons; these
chips are impressive performance pigs.  So how about updating the RTC
date only when

 - write the time to the RTC for the first time after NTP synchronizes
 - write the time to the RTC if xtime.tv_sec <= last_rtc_update + 660

?

> 3. local_timer_interrupt() is called with arguments passed from the above
> instead of fake ones (although "irq" and "dev_id" could be completely
> removed here; in the next iteration, I suppose). 

Agreed.  I can't imagine any use for dev_id in the timer interrupt and
the interrupt number seems only marginally more useful.

> 5. Leap years are handled properly.

Good thing.  People at times do run their systems with clocks set wrongly,
even intensionally.  So I blame (year % 4) == 0 for being a too trivial
view of the world.

> 6. Missing "extern" qualifiers for function declarations are added.
> 
>  OK to apply?

Yes.

  Ralf

From wd@denx.de Tue Jul 22 11:21:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 11:21:27 +0100 (BST)
Received: from mailout01.sul.t-online.com ([IPv6:::ffff:194.25.134.80]:52615
	"EHLO mailout01.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8224821AbTGVKVX>; Tue, 22 Jul 2003 11:21:23 +0100
Received: from fwd01.aul.t-online.de 
	by mailout01.sul.t-online.com with smtp 
	id 19euGl-0002AO-04; Tue, 22 Jul 2003 12:21:19 +0200
Received: from denx.de (Vg-92mZFreGhMC6dlq8CELOFaOmGUu4fb50yd9quA8OXvOjbiZaEoE@[217.235.225.134]) by fmrl01.sul.t-online.com
	with esmtp id 19euGe-0QoGe00; Tue, 22 Jul 2003 12:21:12 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id B74914299F; Tue, 22 Jul 2003 12:21:10 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id ADB10C6D82; Tue, 22 Jul 2003 12:21:09 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id A9F4BC6D81; Tue, 22 Jul 2003 12:21:09 +0200 (MEST)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: [patch] Generic time fixes 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Tue, 22 Jul 2003 12:04:44 +0200."
             <20030722100444.GA4148@linux-mips.org> 
Date: Tue, 22 Jul 2003 12:21:04 +0200
Message-Id: <20030722102109.ADB10C6D82@atlas.denx.de>
X-Seen: false
X-ID: Vg-92mZFreGhMC6dlq8CELOFaOmGUu4fb50yd9quA8OXvOjbiZaEoE@t-dialin.net
Return-Path: <wd@denx.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: 2849
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

In message <20030722100444.GA4148@linux-mips.org> Ralf Baechle wrote:
> 
> It's a common case to have a system boot up with the RTC date being
> completly off, then syncing via ntpdate and xntp to the accurate time.

Another common situation especially with embedded systems is that the
RTC holds the "correct"  time,  and  probably  runs  at  much  higher
precision  than  the systm clock. In such systems, NTP can be used to
keep the system time in sync with the RTC, but the system  time  must
never  be  written  back to the RTC. [Except when explicitely setting
the date&time.]

> I share your dislike of updating the RTC for performance reasons; these

There are more problems with the 11 minute mode.  We  ran  into  this
issue  for hard on some PowerPC systems. Assume a situation where the
RTC is connected through a I2C  bus.  Problem  1:  normally  the  i2c
drivers  will  be  loaded prety late, which means the system will run
initially with an undefined time. Problem 2: on some  actions  a  i2c
transfer  involves  programming an on-chip i2c controller, which will
perform the task and then signal it's done by an interrupt. On such a
system the 11 minute mode will crash the system because rtc_set  will
be called from interrupt contect itself.

There was a  somewhat  controverse  discussion  on  the  linuxppc_dev
mailing list, without a real solution.

> chips are impressive performance pigs.  So how about updating the RTC
> date only when
> 
>  - write the time to the RTC for the first time after NTP synchronizes
>  - write the time to the RTC if xtime.tv_sec <= last_rtc_update + 660

And never, ever update the RTC from interrupt context, please.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Free markets select for winning solutions."        - Eric S. Raymond

From ralf@linux-mips.org Tue Jul 22 12:22:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 12:22:04 +0100 (BST)
Received: from p508B5B34.dip.t-dialin.net ([IPv6:::ffff:80.139.91.52]:64970
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTGVLWC>; Tue, 22 Jul 2003 12:22:02 +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 h6MBLvDB013335;
	Tue, 22 Jul 2003 13:21:57 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6MBLutl013334;
	Tue, 22 Jul 2003 13:21:56 +0200
Date: Tue, 22 Jul 2003 13:21:56 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Wolfgang Denk <wd@denx.de>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722112156.GA12449@linux-mips.org>
References: <20030722100444.GA4148@linux-mips.org> <20030722102109.ADB10C6D82@atlas.denx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030722102109.ADB10C6D82@atlas.denx.de>
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: 2850
X-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, Jul 22, 2003 at 12:21:04PM +0200, Wolfgang Denk wrote:

> Another common situation especially with embedded systems is that the
> RTC holds the "correct"  time,  and  probably  runs  at  much  higher
> precision  than  the systm clock. In such systems, NTP can be used to
> keep the system time in sync with the RTC, but the system  time  must
> never  be  written  back to the RTC. [Except when explicitely setting
> the date&time.]

True; supposedly the TXOs in RTC have higher long term frequency accuracy
than those commonly used to clock system though some RTC are really
badly off.

> > I share your dislike of updating the RTC for performance reasons; these
> 
> There are more problems with the 11 minute mode.  We  ran  into  this
> issue  for hard on some PowerPC systems. Assume a situation where the
> RTC is connected through a I2C  bus.  Problem  1:  normally  the  i2c
> drivers  will  be  loaded prety late, which means the system will run
> initially with an undefined time. Problem 2: on some  actions  a  i2c
> transfer  involves  programming an on-chip i2c controller, which will
> perform the task and then signal it's done by an interrupt. On such a
> system the 11 minute mode will crash the system because rtc_set  will
> be called from interrupt contect itself.
> 
> There was a  somewhat  controverse  discussion  on  the  linuxppc_dev
> mailing list, without a real solution.

[...]

> And never, ever update the RTC from interrupt context, please.

It's the right thing for > 99% of systems and doing it triggered by an
interrupt seems the right thing.  If you happen to have hardware that
has trouble with updates in interrupts you still could implement the
RTC update procedure to just trigger the update in softirq or process
context, as appropriate.

  Ralf

From dkesselr@mmc.atmel.com Tue Jul 22 13:40:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 13:40:42 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:31702
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8224821AbTGVMkj>; Tue, 22 Jul 2003 13:40:39 +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 IAA19986;
	Tue, 22 Jul 2003 08:40:31 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id IAA17061;
	Tue, 22 Jul 2003 08:40:31 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Tue, 22 Jul 2003 08:40:30 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: 64bit Sead build
In-Reply-To: <20030721233649.GA6900@linux-mips.org>
Message-ID: <Pine.GSO.4.44.0307220836390.16466-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: 2851
X-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

Thanks for the info. I'm trying to build 64bit sead so that it can be a
basis for a port to our own chip with a MIPS 5kf core. Is one of the other
supported boards more generic (and thus a better start) than Sead?
David

On Tue, 22 Jul 2003, Ralf Baechle wrote:

> On Mon, Jul 21, 2003 at 10:32:55AM -0400, David Kesselring wrote:
>
> > I'm trying to build linux for Sead in 64 bit. I found that it would not
> > compile without the change at the end of this note. After this fix, I got
> > the following link error. Does anyone have an idea why?
>
> > mips64el-linux-ld --oformat elf32-tradlittlemips -G 0 -static  -Ttext
> > 0x80100000 arch/mips64/kernel/head.o
> > arch/mips64/kernel/init_task.o init/main.o init/version.o init/do_mounts.o
> > \
> >         --start-group \
> >         arch/mips64/kernel/kernel.o arch/mips64/mm/mm.o kernel/kernel.o
> > mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o \
> >          drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
> > drivers/net/net.o drivers/media/media.o \
> >         net/network.o \
> >         arch/mips64/lib/lib.a
> > /home/dkesselr/MIPS/linux-mips-cvs/2003Jul18/linux-build-mips64b/lib/lib.a
> > arch/mips/mips-boards/sead/sead.o
> > arch/mips/mips-boards/generic/mipsboards.o \
> >         --end-group \
> >         -o vmlinux
> > mips64el-linux-ld: warning: cannot find entry symbol __start; defaulting
> > to 0000000080100000
> > mips64el-linux-ld: vmlinux: Not enough room for program headers (allocated
> > 3, need 4)
>
> It may not be obvious but this is ld's way of telling you it doesn't
> feel happy with the options and input files; in some case it could also
> be considered an insufficiency of ld ...
>
> In this particular case the bug is that the kernel configuration doesn't
> set CONFIG_BOOT_ELF32.
>
> I'm a bit surprised to see somebody's actually using a 64-bit kernel on a
> SEAD.
>
>   Ralf
>
>

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


From ralf@linux-mips.org Tue Jul 22 13:48:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 13:48:42 +0100 (BST)
Received: from p508B5B34.dip.t-dialin.net ([IPv6:::ffff:80.139.91.52]:28624
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTGVMsk>; Tue, 22 Jul 2003 13:48:40 +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 h6MCmdDB015110;
	Tue, 22 Jul 2003 14:48:39 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6MCmdhh015109;
	Tue, 22 Jul 2003 14:48:39 +0200
Date: Tue, 22 Jul 2003 14:48:39 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: 64bit Sead build
Message-ID: <20030722124838.GB12449@linux-mips.org>
References: <20030721233649.GA6900@linux-mips.org> <Pine.GSO.4.44.0307220836390.16466-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0307220836390.16466-100000@ares.mmc.atmel.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: 2852
X-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, Jul 22, 2003 at 08:40:30AM -0400, David Kesselring wrote:

> Thanks for the info. I'm trying to build 64bit sead so that it can be a
> basis for a port to our own chip with a MIPS 5kf core. Is one of the other
> supported boards more generic (and thus a better start) than Sead?

We more regularly test on Malta which I also consider a way more
friendly test and development environment than SEAD which is sort of
a bare bone board.

  Ralf

From dom@mips.com Tue Jul 22 13:50:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 13:50:12 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:35853 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224821AbTGVMuK>;
	Tue, 22 Jul 2003 13:50:10 +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 19ewcN-0004jY-00; Tue, 22 Jul 2003 13:51:47 +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 19ewaT-0001Qk-00; Tue, 22 Jul 2003 13:49:49 +0100
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16157.13036.787738.445030@gladsmuir.mips.com>
Date: Tue, 22 Jul 2003 13:49:48 +0100
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: 64bit Sead build
In-Reply-To: <Pine.GSO.4.44.0307220836390.16466-100000@ares.mmc.atmel.com>
References: <20030721233649.GA6900@linux-mips.org>
	<Pine.GSO.4.44.0307220836390.16466-100000@ares.mmc.atmel.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=-8.6, required 4, AWL,
	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: 2853
X-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


David,

You wrote to Ralf:

> Thanks for the info. I'm trying to build 64bit sead so that it can
> be a basis for a port to our own chip with a MIPS 5kf core.

Interesting.  It's good to know people are looking at the 64-bit
ports.

> Is one of the other supported boards more generic (and thus a better
> start) than Sead?

We use our 'Malta' board for all our in-house Linux work.  See:

  http://www.mips.com/ProductCatalog/P626341476/productView

(I think that link will work for you... let me know if it's
non-portable) 

We maintain a relatively stable 32-bit Linux port for Malta.  64-bit
is still somewhat experimental; but at least you have a board with
ethernet and disk ports, and PCI expansion slots.

I guess you should ask your local MIPS salesperson about Malta.

-- 
Dominic Sweetman
MIPS Technologies
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706205/fax +44 1223 706250/swbrd +44 1223 706200
http://www.mips.com



From ralf@linux-mips.org Tue Jul 22 13:52:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 13:52:50 +0100 (BST)
Received: from p508B5B34.dip.t-dialin.net ([IPv6:::ffff:80.139.91.52]:47312
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTGVMws>; Tue, 22 Jul 2003 13:52:48 +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 h6MCqlDB015209;
	Tue, 22 Jul 2003 14:52:47 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6MCqlcv015208;
	Tue, 22 Jul 2003 14:52:47 +0200
Date: Tue, 22 Jul 2003 14:52:47 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: 64bit Sead build
Message-ID: <20030722125247.GC12449@linux-mips.org>
References: <20030721233649.GA6900@linux-mips.org> <Pine.GSO.4.44.0307220836390.16466-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0307220836390.16466-100000@ares.mmc.atmel.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: 2854
X-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, Jul 22, 2003 at 08:40:30AM -0400, David Kesselring wrote:

> Thanks for the info. I'm trying to build 64bit sead so that it can be a
> basis for a port to our own chip with a MIPS 5kf core. Is one of the other
> supported boards more generic (and thus a better start) than Sead?

Btw, forgot to mention I put a fix for the problem you reported into
CVS yesterday so building works.  I don't have a SEAD so I wasn't
able to test.

  Ralf

From ralf@linux-mips.org Tue Jul 22 14:04:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 14:04:10 +0100 (BST)
Received: from p508B5B34.dip.t-dialin.net ([IPv6:::ffff:80.139.91.52]:28625
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224821AbTGVNEB>; Tue, 22 Jul 2003 14:04:01 +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 h6MD40DB015481;
	Tue, 22 Jul 2003 15:04:00 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6MD40HM015480;
	Tue, 22 Jul 2003 15:04:00 +0200
Date: Tue, 22 Jul 2003 15:04:00 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: David Kesselring <dkesselr@mmc.atmel.com>,
	linux-mips@linux-mips.org
Subject: Re: 64bit Sead build
Message-ID: <20030722130400.GD12449@linux-mips.org>
References: <20030721233649.GA6900@linux-mips.org> <Pine.GSO.4.44.0307220836390.16466-100000@ares.mmc.atmel.com> <16157.13036.787738.445030@gladsmuir.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16157.13036.787738.445030@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: 2855
X-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, Jul 22, 2003 at 01:49:48PM +0100, Dominic Sweetman wrote:

> > Thanks for the info. I'm trying to build 64bit sead so that it can
> > be a basis for a port to our own chip with a MIPS 5kf core.
> 
> Interesting.  It's good to know people are looking at the 64-bit
> ports.

The general problem I'm observing is nobody wants to be the first through
the minefield of building a commercial product based on a 64-bit kernel
though for many applications it seems to be a much saner solution than
a 32-bit kernel.

My use is atypical but I'm running a 64-bit kernel SMP / ccNUMA kernel
since years without major problems so we're 90% through and I'd like to
know about the missing 10% ...

  Ralf

From jsun@mvista.com Tue Jul 22 18:10:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 18:10:29 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:20720 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224821AbTGVRK0>;
	Tue, 22 Jul 2003 18:10:26 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6MHAEg03254;
	Tue, 22 Jul 2003 10:10:14 -0700
Date: Tue, 22 Jul 2003 10:10:14 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722101014.B3135@mvista.com>
References: <Pine.GSO.3.96.1030722093500.607A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030722093500.607A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Jul 22, 2003 at 09:58:46AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2856
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Jul 22, 2003 at 09:58:46AM +0200, Maciej W. Rozycki wrote:
> Hello,
> 
>  In preparation to merging DECstation's time support with the generic
> version I did the following clean-ups to generic time support.  Most of
> these are coding style fixes (which might have already been fixed by
> someone else during past two days -- I haven't been able to study the
> changes), but there are a few code changes (detailed below) as well.
> 
>  Before I proceed further I need to get an aswer to the following
> question: why do we use rtc_set_time() for NTP RTC updates instead of
> rtc_set_mmss() like most other architectures do?  Traditionally Linux only
> updated minutes and seconds in this context and I don't think we need to
> do anything more.  And setting minutes and seconds only is way, way
> faster. Which might not matter that much every 11 minutes, except doing
> things slowly here incurs a disruption in the latency of the timer
> interrupt, which NTP might not like and the slow calculation of the RTC
> time causes less precise time being stored in the RTC chip. 
>

rtc_set_time() is more generic interface as it is also used in other 
places.  Boards which easily speed up (i.e., emulate rtc_set_mmss()) by
doing something like the following:

rtc_set_time(t)
{
	if (t-last_time_set < 660 + delta)
		rtc_set_mmss(t);
	else
		/* do a full rtc set */
	last_time_set = t;
}

A lot of boards don't do RTC update, and even when they do they
usually don't have performance issues (such as in vr41xx cases).
It is not fair to tax every board by requiring a new board interface
function.

BTW, at least one other arch (PPC) is not using rtc_set_mmss().

>  It's already questionable whether the update should be done at all (this
> was discussed zillion of times at the NTP group) and it disrupts
> timekeeping of the DECstation severely, but given the current choice, I'd
> prefer to make it as lightweight as possible.
> 

Whether to keep rtc in sync is an option which can be set by a board
Simply do a

time_status |= STA_UNSYNC 

in your <board>_setup routine will disable any RTC update.

>  Here are the changes done:
>

The changes look good to me.

Jun

From jsun@mvista.com Tue Jul 22 18:16:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 18:16:59 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:17139 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224821AbTGVRQ4>;
	Tue, 22 Jul 2003 18:16:56 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6MHGs003275;
	Tue, 22 Jul 2003 10:16:54 -0700
Date: Tue, 22 Jul 2003 10:16:54 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722101654.C3135@mvista.com>
References: <Pine.GSO.3.96.1030722093500.607A-100000@delta.ds2.pg.gda.pl> <20030722100444.GA4148@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030722100444.GA4148@linux-mips.org>; from ralf@linux-mips.org on Tue, Jul 22, 2003 at 12:04:44PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2857
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Jul 22, 2003 at 12:04:44PM +0200, Ralf Baechle wrote:
> On Tue, Jul 22, 2003 at 09:58:46AM +0200, Maciej W. Rozycki wrote:
> 
> >  Before I proceed further I need to get an aswer to the following
> > question: why do we use rtc_set_time() for NTP RTC updates instead of
> > rtc_set_mmss() like most other architectures do?  Traditionally Linux only
> > updated minutes and seconds in this context and I don't think we need to
> > do anything more.  And setting minutes and seconds only is way, way
> > faster. Which might not matter that much every 11 minutes, except doing
> > things slowly here incurs a disruption in the latency of the timer
> > interrupt, which NTP might not like and the slow calculation of the RTC
> > time causes less precise time being stored in the RTC chip. 
> > 
> >  It's already questionable whether the update should be done at all (this
> > was discussed zillion of times at the NTP group) and it disrupts
> > timekeeping of the DECstation severely, but given the current choice, I'd
> > prefer to make it as lightweight as possible.
> 
> It's a common case to have a system boot up with the RTC date being
> completly off, then syncing via ntpdate and xntp to the accurate time.
> If in that situation we only update the time the RTC will stay way far
> from reality.  Another case would be updates of the time near midnight
> where the RTC and NTP date happen to just differ.
> 
> I share your dislike of updating the RTC for performance reasons; these
> chips are impressive performance pigs.  So how about updating the RTC
> date only when
> 
>  - write the time to the RTC for the first time after NTP synchronizes

"First time after NTP synchronization" is not readily known to arch
time code.  This will involve kernel common code change.

>  - write the time to the RTC if xtime.tv_sec <= last_rtc_update + 660
>

Do you mean "xtime.tv_sec > last_rtc_update + 660", which is already
the case?

Again, board does have choice as to whether it wants RTC update or not.

Jun

From macro@ds2.pg.gda.pl Tue Jul 22 20:39:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 20:39:57 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:17405 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224821AbTGVTjy>; Tue, 22 Jul 2003 20:39:54 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA09221;
	Tue, 22 Jul 2003 21:39:40 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 22 Jul 2003 21:39:40 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Keith M Wesolowski <wesolows@foobazco.org>
cc: "Kevin D. Kissell" <kevink@mips.com>, ralf@linux-mips.org,
	linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030721182002.GA28587@foobazco.org>
Message-ID: <Pine.GSO.3.96.1030722212122.607D-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: 2858
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 21 Jul 2003, Keith M Wesolowski wrote:

> sparc32 and sparc64 processors and systems are significantly
> different.  For example, the SRMMU present in v8 CPUs is 100% replaced
> with a totally different MMU (indeed, totally different instructions,
> access methods, etc) in v9.  Accordingly there is very little code in
> common between the two ports, and most of that is in device handling;
> code that is in drivers/sbus and thus shared anyway.

 Well, the MMU of (original) 32-bit MIPS processors (i.e. R2k/R3k) is
completely different from the one in later ones, too.  I suspect this is
true for the R6k as well.  The exception handlers differ a bit as well,
especially considering the XTLB refill one.  That probably counts as
nitpicking, though... 

> Something that made sense for sparc might not make sense for mips.

 Certainly it needs to be analysed on a case by case basis, avoiding
blanket assumptions.  Anyway, I still see two reasons for having at least
a separate top-level directory:

1. A better separation of the more straightforward 32-bit Makefile and the
more complicated 64-bit one.

2. A better visual existence of the 64-bit port; not really a technical
advantage, but more a psychological one.  It stops any newcomer wondering
whether we support 64-bit systems natively or not. 

 There is also no point in having headers in asm-mips consisting of a
single #ifdef CONFIG_MIPS32/#else/#endif conditional, where two distinct
versions should be present in asm-mips and asm-mips64, respectively.  It's
easier to make a diff between such separate implementations to verify
everything's OK. 

  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 Tue Jul 22 20:40:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 20:40:52 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:28669 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224821AbTGVTku>; Tue, 22 Jul 2003 20:40:50 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA09241;
	Tue, 22 Jul 2003 21:40:48 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 22 Jul 2003 21:40:47 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030721211402.GC5188@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030722213958.607E-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: 2859
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 21 Jul 2003, Ralf Baechle wrote:

> I even have some hope that with continuing cleanup mm-32 and mm-64, which
> are supposed to contain only things that due to conflicts can't live in
> mm, will finally become empty.

 If that's going to happen, a removal of arch/mips64/mm does make sense,
indeed.

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


From macro@ds2.pg.gda.pl Tue Jul 22 21:38:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 21:38:46 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:3715 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225207AbTGVUio>; Tue, 22 Jul 2003 21:38:44 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA09983;
	Tue, 22 Jul 2003 22:38:41 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 22 Jul 2003 22:38:41 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
In-Reply-To: <20030722100444.GA4148@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030722222128.607H-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: 2860
X-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, 22 Jul 2003, Ralf Baechle wrote:

> >  It's already questionable whether the update should be done at all (this
> > was discussed zillion of times at the NTP group) and it disrupts
> > timekeeping of the DECstation severely, but given the current choice, I'd
> > prefer to make it as lightweight as possible.
> 
> It's a common case to have a system boot up with the RTC date being
> completly off, then syncing via ntpdate and xntp to the accurate time.
> If in that situation we only update the time the RTC will stay way far

 Hmm, any problems with `ntpdate <your_server>; hwclock -uw'?  Plus a lone
`hwclock -uw' before a graceful halt/reboot?  That's a typical userland
task and a trivial one, actually. 

> from reality.  Another case would be updates of the time near midnight
> where the RTC and NTP date happen to just differ.

 That's why rtc_set_mmss() never does an update that would require a
change to hours -- it defers it with a "set_rtc_mmss: can't update from x
to y" message.

> I share your dislike of updating the RTC for performance reasons; these
> chips are impressive performance pigs.  So how about updating the RTC
> date only when
> 
>  - write the time to the RTC for the first time after NTP synchronizes
>  - write the time to the RTC if xtime.tv_sec <= last_rtc_update + 660
> 
> ?

 I really see no point in doing it at all -- it's all easier and more
flexible to be done in the userland.

> > 5. Leap years are handled properly.
> 
> Good thing.  People at times do run their systems with clocks set wrongly,
> even intensionally.  So I blame (year % 4) == 0 for being a too trivial
> view of the world.

 Well, that's actually just the Julian view.

 There were a number of surprising discoveries in code here and there wrt
the y2k leap year exception -- apparently a number of people involved in
coding were not aware of the full Gregorian Calendar leap year rule, even
though doing that stuff should make them obliged to.  Somehow the rule was
already known to me many years ago, certainly before y2k and probably even
before I got involved with computers...

  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 Tue Jul 22 21:54:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 21:54:30 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:8580 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225207AbTGVUy2>; Tue, 22 Jul 2003 21:54:28 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA10148;
	Tue, 22 Jul 2003 22:54:23 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 22 Jul 2003 22:54:23 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Wolfgang Denk <wd@denx.de>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes 
In-Reply-To: <20030722102109.ADB10C6D82@atlas.denx.de>
Message-ID: <Pine.GSO.3.96.1030722223857.607I-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: 2861
X-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, 22 Jul 2003, Wolfgang Denk wrote:

> > I share your dislike of updating the RTC for performance reasons; these
> 
> There are more problems with the 11 minute mode.  We  ran  into  this
> issue  for hard on some PowerPC systems. Assume a situation where the
> RTC is connected through a I2C  bus.  Problem  1:  normally  the  i2c
> drivers  will  be  loaded prety late, which means the system will run
> initially with an undefined time. Problem 2: on some  actions  a  i2c
> transfer  involves  programming an on-chip i2c controller, which will
> perform the task and then signal it's done by an interrupt. On such a
> system the 11 minute mode will crash the system because rtc_set  will
> be called from interrupt contect itself.
> 
> There was a  somewhat  controverse  discussion  on  the  linuxppc_dev
> mailing list, without a real solution.

 A possible solution is to make the update configurable with a sysctl.  It
really begs for it.  I think it may be worth discussing at the LKML. 
Additionally Ulrich Windl may wish to share a few thoughts on the matter. 

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


From macro@ds2.pg.gda.pl Tue Jul 22 22:21:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 22:21:14 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:64389 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225207AbTGVVVM>; Tue, 22 Jul 2003 22:21:12 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA10354;
	Tue, 22 Jul 2003 23:21:05 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 22 Jul 2003 23:21:04 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
In-Reply-To: <20030722101014.B3135@mvista.com>
Message-ID: <Pine.GSO.3.96.1030722225739.607J-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: 2862
X-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, 22 Jul 2003, Jun Sun wrote:

> >  Before I proceed further I need to get an aswer to the following
> > question: why do we use rtc_set_time() for NTP RTC updates instead of
> > rtc_set_mmss() like most other architectures do?  Traditionally Linux only
> > updated minutes and seconds in this context and I don't think we need to
> > do anything more.  And setting minutes and seconds only is way, way
> > faster. Which might not matter that much every 11 minutes, except doing
> > things slowly here incurs a disruption in the latency of the timer
> > interrupt, which NTP might not like and the slow calculation of the RTC
> > time causes less precise time being stored in the RTC chip. 
> 
> rtc_set_time() is more generic interface as it is also used in other 
> places.  Boards which easily speed up (i.e., emulate rtc_set_mmss()) by
> doing something like the following:
> 
> rtc_set_time(t)
> {
> 	if (t-last_time_set < 660 + delta)
> 		rtc_set_mmss(t);
> 	else
> 		/* do a full rtc set */
> 	last_time_set = t;
> }
> 
> A lot of boards don't do RTC update, and even when they do they

 These should be fixed. 

> usually don't have performance issues (such as in vr41xx cases).
> It is not fair to tax every board by requiring a new board interface
> function.

 Well, rtc_set_time() is only used by the timekeeping code, so I see no
problem with renaming it.  And the interface remains the same -- it's a
number of seconds.  So if a full update is faster than changing minutes
and seconds only (e.g. the RTC is a monotonic counter -- I know a system
that just counts 10 ms intervals), an implementation is free to do so
(although that enforces UTC to be kept in the RTC; a good thing anyway),
but it shouldn't be required to.  And I think the name should be changed
to reflect that. 

 I you find such a cross-system update tedious -- don't worry.  I can do
that.  As a favor to platform maintainers I did such stuff in the past and
I can do it again.

> BTW, at least one other arch (PPC) is not using rtc_set_mmss().

 Their reasoning being?

> >  It's already questionable whether the update should be done at all (this
> > was discussed zillion of times at the NTP group) and it disrupts
> > timekeeping of the DECstation severely, but given the current choice, I'd
> > prefer to make it as lightweight as possible.
> > 
> 
> Whether to keep rtc in sync is an option which can be set by a board

 It can't.  But it should be configurable with a sysctl (but it isn't
now). 

> Simply do a
> 
> time_status |= STA_UNSYNC 
> 
> in your <board>_setup routine will disable any RTC update.

 Well, time_status = STA_UNSYNC initially, but ntpd will reset that.
Which is of course required to become a server.

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


From ralf@linux-mips.org Tue Jul 22 22:21:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 22:21:36 +0100 (BST)
Received: from p508B5B34.dip.t-dialin.net ([IPv6:::ffff:80.139.91.52]:56705
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225230AbTGVVV1>; Tue, 22 Jul 2003 22:21:27 +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 h6MLLJDB009291;
	Tue, 22 Jul 2003 23:21:19 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6MLLHZf009284;
	Tue, 22 Jul 2003 23:21:17 +0200
Date: Tue, 22 Jul 2003 23:21:17 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030722212117.GB1660@linux-mips.org>
References: <20030721182002.GA28587@foobazco.org> <Pine.GSO.3.96.1030722212122.607D-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.1030722212122.607D-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: 2863
X-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, Jul 22, 2003 at 09:39:40PM +0200, Maciej W. Rozycki wrote:

> > sparc32 and sparc64 processors and systems are significantly
> > different.  For example, the SRMMU present in v8 CPUs is 100% replaced
> > with a totally different MMU (indeed, totally different instructions,
> > access methods, etc) in v9.  Accordingly there is very little code in
> > common between the two ports, and most of that is in device handling;
> > code that is in drivers/sbus and thus shared anyway.
> 
>  Well, the MMU of (original) 32-bit MIPS processors (i.e. R2k/R3k) is
> completely different from the one in later ones, too.  I suspect this is
> true for the R6k as well.  The exception handlers differ a bit as well,
> especially considering the XTLB refill one.  That probably counts as
> nitpicking, though... 

It's also a question of taste - and that one can be discussed forever.
How far do you want to factor our common code, as little as possible
which was our previous approach or extremly aggressive, glibc-like.

And yes, the R6000 is different.  With that in mind R2000 and R4000 look
like enzygotic twins ...

> > Something that made sense for sparc might not make sense for mips.
> 
>  Certainly it needs to be analysed on a case by case basis, avoiding
> blanket assumptions.  Anyway, I still see two reasons for having at least
> a separate top-level directory:
> 
> 1. A better separation of the more straightforward 32-bit Makefile and the
> more complicated 64-bit one.
> 
> 2. A better visual existence of the 64-bit port; not really a technical
> advantage, but more a psychological one.  It stops any newcomer wondering
> whether we support 64-bit systems natively or not. 

I was thinking about that also.  arch/mips64 and include/asm-mips64 will
go away but on the other side there will be an option to configure a
64-bit kernel in the menus - which will hopefully be more visible than
just two subdirectories.

>  There is also no point in having headers in asm-mips consisting of a
> single #ifdef CONFIG_MIPS32/#else/#endif conditional, where two distinct
> versions should be present in asm-mips and asm-mips64, respectively.  It's
> easier to make a diff between such separate implementations to verify
> everything's OK. 

Like 80% of the headers could be identical between both files without
lots of trickery.  The current approach is have two physical copies of
these identical files.

Btw, an old experience repeats - some of the code was identical except
inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
I rewrote that stuff to use C for this arithmetic.  The result - less
inline assembler, more readable code and a file that's identical for
both 32-bit and 64-bit.

  Ralf

From macro@ds2.pg.gda.pl Tue Jul 22 22:24:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 22:24:41 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:16518 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225230AbTGVVYj>; Tue, 22 Jul 2003 22:24:39 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA10393;
	Tue, 22 Jul 2003 23:24:31 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 22 Jul 2003 23:24:31 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
In-Reply-To: <20030722101654.C3135@mvista.com>
Message-ID: <Pine.GSO.3.96.1030722232131.607K-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: 2864
X-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, 22 Jul 2003, Jun Sun wrote:

> Again, board does have choice as to whether it wants RTC update or not.

 Nope, it doesn't -- it has to update it.  There's something that is
called an interface and all systems are required to behave consistently. 
The only justifiable exception would be a system having no RTC at all.
Any other system ignoring the call is plain broken.

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


From macro@ds2.pg.gda.pl Tue Jul 22 22:37:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 22:37:50 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:23687 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225230AbTGVVhs>; Tue, 22 Jul 2003 22:37:48 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA10512;
	Tue, 22 Jul 2003 23:37:45 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 22 Jul 2003 23:37:44 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030722212117.GB1660@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030722232705.607L-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: 2865
X-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, 22 Jul 2003, Ralf Baechle wrote:

> And yes, the R6000 is different.  With that in mind R2000 and R4000 look
> like enzygotic twins ...

 ;-)

> > 2. A better visual existence of the 64-bit port; not really a technical
> > advantage, but more a psychological one.  It stops any newcomer wondering
> > whether we support 64-bit systems natively or not. 
> 
> I was thinking about that also.  arch/mips64 and include/asm-mips64 will
> go away but on the other side there will be an option to configure a
> 64-bit kernel in the menus - which will hopefully be more visible than
> just two subdirectories.

 Well, as long as one get that far to run a configuration script (BTW,
what menus are you referring to? -- I haven't seen any).  Right now that's
easily visible straight in the archive which is now even browsable in the
Internet here and there -- Q: "What architectures are supported?" A: "See
the subdirectories of arch/." 

> Btw, an old experience repeats - some of the code was identical except
> inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
> I rewrote that stuff to use C for this arithmetic.  The result - less
> inline assembler, more readable code and a file that's identical for
> both 32-bit and 64-bit.

 Well, whatever is plain C code (or should be such) should be identical,
indeed, but macros will differ as will low-level assembly.  Then add
64-bit specific options and you get yet more complication. 

 I hope `uname -m' will continue to report the correct architecture and
that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
and "mips64" a 64-bit one) -- have you considered this?

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


From Geert.Uytterhoeven@sonycom.com Tue Jul 22 22:48:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 22:48:04 +0100 (BST)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:3024 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225230AbTGVVsC>;
	Tue, 22 Jul 2003 22:48:02 +0100
Received: from vervain.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.9/8.12.9) with ESMTP id h6MLlh1W019226;
	Tue, 22 Jul 2003 23:47:43 +0200 (MEST)
Date: Tue, 22 Jul 2003 23:47:43 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <Pine.GSO.3.96.1030722232705.607L-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0307222346260.27629-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.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: 2866
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 22 Jul 2003, Maciej W. Rozycki wrote:
> On Tue, 22 Jul 2003, Ralf Baechle wrote:
> > I was thinking about that also.  arch/mips64 and include/asm-mips64 will
> > go away but on the other side there will be an option to configure a
> > 64-bit kernel in the menus - which will hopefully be more visible than
> > just two subdirectories.
> 
>  Well, as long as one get that far to run a configuration script (BTW,
> what menus are you referring to? -- I haven't seen any).  Right now that's

It will flash up on your retina and stay there for a while, waiting for your
response, if you run `make oldconfig' :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From wgowcher@yahoo.com Tue Jul 22 23:12:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 23:13:00 +0100 (BST)
Received: from web11903.mail.yahoo.com ([IPv6:::ffff:216.136.172.187]:49267
	"HELO web11903.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225230AbTGVWMz>; Tue, 22 Jul 2003 23:12:55 +0100
Message-ID: <20030722221252.37376.qmail@web11903.mail.yahoo.com>
Received: from [209.243.184.191] by web11903.mail.yahoo.com via HTTP; Tue, 22 Jul 2003 15:12:52 PDT
Date: Tue, 22 Jul 2003 15:12:52 -0700 (PDT)
From: Wayne Gowcher <wgowcher@yahoo.com>
Subject: Support of cmpxchg
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <wgowcher@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: 2867
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wgowcher@yahoo.com
Precedence: bulk
X-list: linux-mips

I am trying to get some DRM ( direct rendering module
? ) code to work with XFree86 on a mips system and
have come across the function cmpxchg(). On x86
systems 486 and higher this is an assembly
instruction. Other architectures like sparc have some
inline assembly to preform the same task. Yet other
architectures like the parisc have generic c code to
implement the function. MIPS it seems has nothing.

Has anyone ever implemented this for mips2 and higher
architecture ?

If no, does anyone think it is possible to use ll / sc
to implement this function similar to the spinlock
case. Or should I just stick with the generic c
versions ?

Any thoughts / code / comments welcome

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

From ralf@linux-mips.org Tue Jul 22 23:37:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 23:37:51 +0100 (BST)
Received: from p508B5B34.dip.t-dialin.net ([IPv6:::ffff:80.139.91.52]:47238
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225230AbTGVWht>; Tue, 22 Jul 2003 23:37: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 h6MMbkDB011057;
	Wed, 23 Jul 2003 00:37:46 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6MMbj7V011056;
	Wed, 23 Jul 2003 00:37:45 +0200
Date: Wed, 23 Jul 2003 00:37:45 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722223745.GC1660@linux-mips.org>
References: <20030722101014.B3135@mvista.com> <Pine.GSO.3.96.1030722225739.607J-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.1030722225739.607J-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: 2868
X-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

To add some performance numbers to the debate.  The DS1286 which is one of
the oldest chips we're supporting has a minimum write cycle time of 150ns.
The M48T02 which is used in the Origin needs 70ns, 150ns or 200ns depending
on the version.  Ok, those are slow numbers but they're not as bad as
postcards ...  I2C and it's evil brothers a is in a different universe
though.  There are busses in that cathegory that can transfer like 1kbyte/s.

  Ralf

From jsun@mvista.com Tue Jul 22 23:43:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 23:43:47 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:31485 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225230AbTGVWnp>;
	Tue, 22 Jul 2003 23:43:45 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6MMhe905341;
	Tue, 22 Jul 2003 15:43:40 -0700
Date: Tue, 22 Jul 2003 15:43:40 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722154340.F3135@mvista.com>
References: <20030722101014.B3135@mvista.com> <Pine.GSO.3.96.1030722225739.607J-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030722225739.607J-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Jul 22, 2003 at 11:21:04PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2869
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Jul 22, 2003 at 11:21:04PM +0200, Maciej W. Rozycki wrote:
> On Tue, 22 Jul 2003, Jun Sun wrote:
> 
> > >  Before I proceed further I need to get an aswer to the following
> > > question: why do we use rtc_set_time() for NTP RTC updates instead of
> > > rtc_set_mmss() like most other architectures do?  Traditionally Linux only
> > > updated minutes and seconds in this context and I don't think we need to
> > > do anything more.  And setting minutes and seconds only is way, way
> > > faster. Which might not matter that much every 11 minutes, except doing
> > > things slowly here incurs a disruption in the latency of the timer
> > > interrupt, which NTP might not like and the slow calculation of the RTC
> > > time causes less precise time being stored in the RTC chip. 
> > 
> > rtc_set_time() is more generic interface as it is also used in other 
> > places.  Boards which easily speed up (i.e., emulate rtc_set_mmss()) by
> > doing something like the following:
> > 
> > rtc_set_time(t)
> > {
> > 	if (t-last_time_set < 660 + delta)
> > 		rtc_set_mmss(t);
> > 	else
> > 		/* do a full rtc set */
> > 	last_time_set = t;
> > }
> > 
> > A lot of boards don't do RTC update, and even when they do they
> 
>  These should be fixed. 
> 
> > usually don't have performance issues (such as in vr41xx cases).
> > It is not fair to tax every board by requiring a new board interface
> > function.
> 
>  Well, rtc_set_time() is only used by the timekeeping code, so I see no
> problem with renaming it.  And the interface remains the same -- it's a
> number of seconds.  So if a full update is faster than changing minutes
> and seconds only (e.g. the RTC is a monotonic counter -- I know a system
> that just counts 10 ms intervals), an implementation is free to do so
> (although that enforces UTC to be kept in the RTC; a good thing anyway),
> but it shouldn't be required to.  And I think the name should be changed
> to reflect that. 
>

Actually the drivers/char/mips-rtc.c uses it too.  In that context
a full rtc set is needed.

The same interface can be used for the 2.6 gen-rtc.c as well, where
a full rtc update is needed also.

I like the current way it is because :

1) rtc_set_time() is a more generic interface so that it can be used
in more places (such as mips-rtc.c and gen-rtc.c).
2) rtc_set_mmss() can be reasonally emulated if it is desired on a particular
board
3) it is better to have just one rtc_set_xxx() instead of two.

> > BTW, at least one other arch (PPC) is not using rtc_set_mmss().
> 
>  Their reasoning being?
>

Probably the same reason as above?
 
> > >  It's already questionable whether the update should be done at all (this
> > > was discussed zillion of times at the NTP group) and it disrupts
> > > timekeeping of the DECstation severely, but given the current choice, I'd
> > > prefer to make it as lightweight as possible.
> > > 
> > 
> > Whether to keep rtc in sync is an option which can be set by a board
> 
>  It can't.  But it should be configurable with a sysctl (but it isn't
> now). 
> 
> > Simply do a
> > 
> > time_status |= STA_UNSYNC 
> > 
> > in your <board>_setup routine will disable any RTC update.
> 
>  Well, time_status = STA_UNSYNC initially, but ntpd will reset that.
> Which is of course required to become a server.
>

Actually searching through the kernel I can't find the place where
the flag is cleared.  Am I mistaken?

Jun

From macro@ds2.pg.gda.pl Tue Jul 22 23:44:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 23:44:09 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:30604 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225239AbTGVWnu>; Tue, 22 Jul 2003 23:43:50 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id AAA11264;
	Wed, 23 Jul 2003 00:43:42 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 23 Jul 2003 00:43:42 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Wayne Gowcher <wgowcher@yahoo.com>
cc: linux-mips@linux-mips.org
Subject: Re: Support of cmpxchg
In-Reply-To: <20030722221252.37376.qmail@web11903.mail.yahoo.com>
Message-ID: <Pine.GSO.3.96.1030723003736.607N-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: 2870
X-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, 22 Jul 2003, Wayne Gowcher wrote:

> I am trying to get some DRM ( direct rendering module
> ? ) code to work with XFree86 on a mips system and
> have come across the function cmpxchg(). On x86
> systems 486 and higher this is an assembly
> instruction. Other architectures like sparc have some
> inline assembly to preform the same task. Yet other
> architectures like the parisc have generic c code to
> implement the function. MIPS it seems has nothing.
> 
> Has anyone ever implemented this for mips2 and higher
> architecture ?
> 
> If no, does anyone think it is possible to use ll / sc
> to implement this function similar to the spinlock
> case. Or should I just stick with the generic c
> versions ?

 Doing it with ll/sc should be straightforward.

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


From macro@ds2.pg.gda.pl Tue Jul 22 23:52:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 23:52:29 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:10381 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225239AbTGVWw1>; Tue, 22 Jul 2003 23:52:27 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id AAA11323;
	Wed, 23 Jul 2003 00:51:38 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 23 Jul 2003 00:51:37 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <Pine.GSO.4.21.0307222346260.27629-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1030723004508.607O-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: 2871
X-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, 22 Jul 2003, Geert Uytterhoeven wrote:

> >  Well, as long as one get that far to run a configuration script (BTW,
> > what menus are you referring to? -- I haven't seen any).  Right now that's
> 
> It will flash up on your retina and stay there for a while, waiting for your
> response, if you run `make oldconfig' :-)

 Hmm, now I have to speed up my transition to 2.6 to have my curiosity
appeased...  Hopefully I won't get disappointed.

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


From macro@ds2.pg.gda.pl Tue Jul 22 23:55:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jul 2003 23:55:32 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:23437 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225239AbTGVWza>; Tue, 22 Jul 2003 23:55:30 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id AAA11353;
	Wed, 23 Jul 2003 00:55:28 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 23 Jul 2003 00:55:27 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
In-Reply-To: <20030722223745.GC1660@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030723005259.607P-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: 2872
X-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 Wed, 23 Jul 2003, Ralf Baechle wrote:

> To add some performance numbers to the debate.  The DS1286 which is one of
> the oldest chips we're supporting has a minimum write cycle time of 150ns.
> The M48T02 which is used in the Origin needs 70ns, 150ns or 200ns depending
> on the version.  Ok, those are slow numbers but they're not as bad as

 Add a number of divisions to get the conversion done to that.

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


From macro@ds2.pg.gda.pl Wed Jul 23 00:11:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 00:11:04 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:23182 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225239AbTGVXLC>; Wed, 23 Jul 2003 00:11:02 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id BAA11504;
	Wed, 23 Jul 2003 01:10:55 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 23 Jul 2003 01:10:54 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
In-Reply-To: <20030722154340.F3135@mvista.com>
Message-ID: <Pine.GSO.3.96.1030723005534.607Q-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: 2873
X-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, 22 Jul 2003, Jun Sun wrote:

> >  Well, rtc_set_time() is only used by the timekeeping code, so I see no
> > problem with renaming it.  And the interface remains the same -- it's a
> > number of seconds.  So if a full update is faster than changing minutes
> > and seconds only (e.g. the RTC is a monotonic counter -- I know a system
> > that just counts 10 ms intervals), an implementation is free to do so
> > (although that enforces UTC to be kept in the RTC; a good thing anyway),
> > but it shouldn't be required to.  And I think the name should be changed
> > to reflect that. 
> 
> Actually the drivers/char/mips-rtc.c uses it too.  In that context
> a full rtc set is needed.
> 
> The same interface can be used for the 2.6 gen-rtc.c as well, where
> a full rtc update is needed also.

 But that function should be provided by the driver (it may use
system-specific backends at will -- drivers/char/rtc.c does so as well),
with all that fancy stuff about epoch and century handling. 

> I like the current way it is because :
> 
> 1) rtc_set_time() is a more generic interface so that it can be used
> in more places (such as mips-rtc.c and gen-rtc.c).

 I see no problem with that interface being used there.

> 2) rtc_set_mmss() can be reasonally emulated if it is desired on a particular
> board

 I don't think so -- it would incur a race and a severe performance hit.
It makes no sense anyway.

> 3) it is better to have just one rtc_set_xxx() instead of two.

 Please define "better".  I think it's better to have a fast variation for
timekeeping as it's been used for years now for MC146818 and clones.

> >  Well, time_status = STA_UNSYNC initially, but ntpd will reset that.
> > Which is of course required to become a server.
> 
> Actually searching through the kernel I can't find the place where
> the flag is cleared.  Am I mistaken?

 See do_adjtimex().

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


From jsun@mvista.com Wed Jul 23 00:37:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 00:37:06 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:30192 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225239AbTGVXhE>;
	Wed, 23 Jul 2003 00:37:04 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6MNb1d14282;
	Tue, 22 Jul 2003 16:37:01 -0700
Date: Tue, 22 Jul 2003 16:37:01 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722163701.G3135@mvista.com>
References: <20030722154340.F3135@mvista.com> <Pine.GSO.3.96.1030723005534.607Q-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030723005534.607Q-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Jul 23, 2003 at 01:10:54AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2874
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Jul 23, 2003 at 01:10:54AM +0200, Maciej W. Rozycki wrote:
> On Tue, 22 Jul 2003, Jun Sun wrote:
> 
> > >  Well, rtc_set_time() is only used by the timekeeping code, so I see no
> > > problem with renaming it.  And the interface remains the same -- it's a
> > > number of seconds.  So if a full update is faster than changing minutes
> > > and seconds only (e.g. the RTC is a monotonic counter -- I know a system
> > > that just counts 10 ms intervals), an implementation is free to do so
> > > (although that enforces UTC to be kept in the RTC; a good thing anyway),
> > > but it shouldn't be required to.  And I think the name should be changed
> > > to reflect that. 
> > 
> > Actually the drivers/char/mips-rtc.c uses it too.  In that context
> > a full rtc set is needed.
> > 
> > The same interface can be used for the 2.6 gen-rtc.c as well, where
> > a full rtc update is needed also.
> 
>  But that function should be provided by the driver (it may use
> system-specific backends at will -- drivers/char/rtc.c does so as well),

Isn't it cool to take care of the board-specific with the same interface
kernel time system uses?  Every MIPS board gets a basic RTC driver for free!

> > I like the current way it is because :
> > 
> > 1) rtc_set_time() is a more generic interface so that it can be used
> > in more places (such as mips-rtc.c and gen-rtc.c).
> 
>  I see no problem with that interface being used there.

Eh?  I assume you mean "no problem with rtc_set_mmss() being used there", true?

How come no problem?  rtc_set_mmss() does not even allow you set the time
if the new time is too off.  

> 
> > 2) rtc_set_mmss() can be reasonally emulated if it is desired on a particular
> > board
> 
>  I don't think so -- it would incur a race and a severe performance hit.
> It makes no sense anyway.

What is the race condition?  And what is the performance hit?

> > 3) it is better to have just one rtc_set_xxx() instead of two.
> 
>  Please define "better".  I think it's better to have a fast variation for
> timekeeping as it's been used for years now for MC146818 and clones.
>

Oh, yeah?  Look at those ugly #ifdefs include/asm-mips/mc146818rtc.h.
It is a poor abstraction of RTC.

If you convert DEC to the new RTC interface we could get rid of that
file completely.

And make no mistake, you _can_ have fast implementation that you are
looking for.

BTW, are you proposing to rename rtc_set_time() to rtc_set_mmss() and change
its semantic accordingly?  Or are you suggesting to add rtc_set_mmss()?

If you are suggesting the later, clearly fewer interface functions 
between MIPS common and board layer is better.

> > Actually searching through the kernel I can't find the place where
> > the flag is cleared.  Am I mistaken?
> 
>  See do_adjtimex().
>

I see.  Thanks.

Jun 

From DennisCastleman@oaktech.com Wed Jul 23 00:54:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 00:54:56 +0100 (BST)
Received: from mx1.teralogic.tv ([IPv6:::ffff:207.16.148.27]:19391 "EHLO
	mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225239AbTGVXyv>; Wed, 23 Jul 2003 00:54:51 +0100
Received: from tlexmail.teralogic.tv (uugate-2.oaktech.com [207.16.148.1])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h6MNoPG02653;
	Tue, 22 Jul 2003 16:50:25 -0700 (PDT)
Received: by tlexposeidon.teralogic-inc.com with Internet Mail Service (5.5.2653.19)
	id <L92RZAYP>; Tue, 22 Jul 2003 16:45:27 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E263410301E@tlexposeidon.teralogic-inc.com>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: linux-mips@linux-mips.org
Cc: "'Ralf Baechle'" <ralf@linux-mips.org>
Subject: Profiling tools
Date: Tue, 22 Jul 2003 16:45:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C350AB.506AC4B0"
Return-Path: <DennisCastleman@oaktech.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: 2875
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.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_01C350AB.506AC4B0
Content-Type: text/plain

Any body have any experience will finding
Profile tool for mips-linux?

I'm running MontaVista 2.4.17 on a mips 5kc core.
I'm running linux on top of RTAI 2.24.1.8 
If I can find a profiler that work with the 5kc, then I'll add
RTAI support, if necessary.

Any thoughts?
Thanks
Dennis Castleman
OAK Technology 

------_=_NextPart_001_01C350AB.506AC4B0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>Profiling tools</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Any body have any experience will finding</FONT>
<BR><FONT SIZE=2>Profile tool for mips-linux?</FONT>
</P>

<P><FONT SIZE=2>I'm running MontaVista 2.4.17 on a mips 5kc core.</FONT>
<BR><FONT SIZE=2>I'm running linux on top of RTAI 2.24.1.8 </FONT>
<BR><FONT SIZE=2>If I can find a profiler that work with the 5kc, then I'll add</FONT>
<BR><FONT SIZE=2>RTAI support, if necessary.</FONT>
</P>

<P><FONT SIZE=2>Any thoughts?</FONT>
<BR><FONT SIZE=2>Thanks</FONT>
<BR><FONT SIZE=2>Dennis Castleman</FONT>
<BR><FONT SIZE=2>OAK Technology </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C350AB.506AC4B0--

From wd@denx.de Wed Jul 23 01:04:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 01:04:48 +0100 (BST)
Received: from mailout11.sul.t-online.com ([IPv6:::ffff:194.25.134.85]:13231
	"EHLO mailout11.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225239AbTGWAEq>; Wed, 23 Jul 2003 01:04:46 +0100
Received: from fwd10.aul.t-online.de 
	by mailout11.sul.t-online.com with smtp 
	id 19f77S-0003qJ-06; Wed, 23 Jul 2003 02:04:34 +0200
Received: from denx.de (r11+EoZ1ZezkXh81O5i86S3PUcesdkBknBL6SbOhg-yJa0a8vL4tww@[217.235.225.134]) by fmrl10.sul.t-online.com
	with esmtp id 19f77P-0TtNdQ0; Wed, 23 Jul 2003 02:04:31 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 3A3F142D35; Wed, 23 Jul 2003 02:04:30 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 18BEDC6D82; Wed, 23 Jul 2003 02:04:29 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 1146EC6D81; Wed, 23 Jul 2003 02:04:29 +0200 (MEST)
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: Profiling tools 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Tue, 22 Jul 2003 16:45:21 PDT."
             <56BEF0DBC8B9D611BFDB00508B5E263410301E@tlexposeidon.teralogic-inc.com> 
Date: Wed, 23 Jul 2003 02:04:24 +0200
Message-Id: <20030723000429.18BEDC6D82@atlas.denx.de>
X-Seen: false
X-ID: r11+EoZ1ZezkXh81O5i86S3PUcesdkBknBL6SbOhg-yJa0a8vL4tww@t-dialin.net
Return-Path: <wd@denx.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: 2876
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

Dear Dennis,

in message <56BEF0DBC8B9D611BFDB00508B5E263410301E@tlexposeidon.teralogic-inc.com> you wrote:
>
> Any body have any experience will finding
> Profile tool for mips-linux?

What exactly are you looking for? There can be several intentions  to
"profile" software.

> I'm running MontaVista 2.4.17 on a mips 5kc core.
> I'm running linux on top of RTAI 2.24.1.8 
> If I can find a profiler that work with the 5kc, then I'll add
> RTAI support, if necessary.

Did you have a look at the LTT? See http://www.opersys.com/LTT/index.html

> ------_=_NextPart_001_01C350AB.506AC4B0
> Content-Type: text/html
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

Please: don't post HTML to mailing lists.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I am not now, nor have I ever been, a member of the demigodic party.
                                                   -- Dennis Ritchie

From macro@ds2.pg.gda.pl Wed Jul 23 01:30:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 01:31:01 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:54419 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225239AbTGWAa7>; Wed, 23 Jul 2003 01:30:59 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id CAA12182;
	Wed, 23 Jul 2003 02:30:53 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 23 Jul 2003 02:30:53 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
In-Reply-To: <20030722163701.G3135@mvista.com>
Message-ID: <Pine.GSO.3.96.1030723014418.607S-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: 2877
X-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, 22 Jul 2003, Jun Sun wrote:

> > > >  Well, rtc_set_time() is only used by the timekeeping code, so I see no
> > > > problem with renaming it.  And the interface remains the same -- it's a
> > > > number of seconds.  So if a full update is faster than changing minutes
> > > > and seconds only (e.g. the RTC is a monotonic counter -- I know a system
> > > > that just counts 10 ms intervals), an implementation is free to do so
> > > > (although that enforces UTC to be kept in the RTC; a good thing anyway),
> > > > but it shouldn't be required to.  And I think the name should be changed
> > > > to reflect that. 
> > > 
> > > Actually the drivers/char/mips-rtc.c uses it too.  In that context
> > > a full rtc set is needed.
> > > 
> > > The same interface can be used for the 2.6 gen-rtc.c as well, where
> > > a full rtc update is needed also.
> > 
> >  But that function should be provided by the driver (it may use
> > system-specific backends at will -- drivers/char/rtc.c does so as well),
> 
> Isn't it cool to take care of the board-specific with the same interface
> kernel time system uses?  Every MIPS board gets a basic RTC driver for free!

 Well, I'm not that convinced.  What's wrong with making real support for
the RTC chip instead?

> > > I like the current way it is because :
> > > 
> > > 1) rtc_set_time() is a more generic interface so that it can be used
> > > in more places (such as mips-rtc.c and gen-rtc.c).
> > 
> >  I see no problem with that interface being used there.
> 
> Eh?  I assume you mean "no problem with rtc_set_mmss() being used
> there", true? 

 Nope, I mean rtc_set_time() is just fine here -- do I sound crazy? 

> > > 2) rtc_set_mmss() can be reasonally emulated if it is desired on a particular
> > > board
> > 
> >  I don't think so -- it would incur a race and a severe performance hit.
> > It makes no sense anyway.
> 
> What is the race condition?  And what is the performance hit?

 You need to read from the RTC, modify minutes and seconds as appropriate
and write the RTC back.  Meanwhile the time as stored in the RTC may
change.  With the 500 ms offset approximation as used by time.c it may be
unlikely, but that assumption is for the MC146818 and it may not be true
for incompatible RTC chips.  That is the race.  The performance hit is
obvious -- now a read is added to the write.

> > > 3) it is better to have just one rtc_set_xxx() instead of two.
> > 
> >  Please define "better".  I think it's better to have a fast variation for
> > timekeeping as it's been used for years now for MC146818 and clones.
> 
> Oh, yeah?  Look at those ugly #ifdefs include/asm-mips/mc146818rtc.h.
> It is a poor abstraction of RTC.

 These should probably be removed and a few variables used instead.  I'll 
get it fixed one day.

> If you convert DEC to the new RTC interface we could get rid of that
> file completely.

 We won't be able -- at least drivers/char/rtc.c needs it.  And also the
driver is used for more systems than the lone DECstation.

> And make no mistake, you _can_ have fast implementation that you are
> looking for.

 I fail to see how a single division plus two iomem writes can be slower
than complicated arithmetics, involving a couple of loops and divisions,
then seven iomem writes, sorry.

> BTW, are you proposing to rename rtc_set_time() to rtc_set_mmss() and change
> its semantic accordingly?  Or are you suggesting to add rtc_set_mmss()?
> 
> If you are suggesting the later, clearly fewer interface functions 
> between MIPS common and board layer is better.

 It's mostly alike to me, except that I won't need rtc_set_time() as I
don't use mips_rtc.c or genrtc.c, so I won't implement it.

 And having no rtc_set_mmss() interface I *will* implement rtc_set_time()
as a lone minutes and seconds update with an appropriate comment why it is
done so.

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


From jsun@mvista.com Wed Jul 23 02:14:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 02:14:35 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:50416 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225239AbTGWBOd>;
	Wed, 23 Jul 2003 02:14:33 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6N1EUd15747;
	Tue, 22 Jul 2003 18:14:30 -0700
Date: Tue, 22 Jul 2003 18:14:30 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [patch] Generic time fixes
Message-ID: <20030722181430.I3135@mvista.com>
References: <20030722163701.G3135@mvista.com> <Pine.GSO.3.96.1030723014418.607S-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030723014418.607S-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Jul 23, 2003 at 02:30:53AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2878
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Jul 23, 2003 at 02:30:53AM +0200, Maciej W. Rozycki wrote:
> On Tue, 22 Jul 2003, Jun Sun wrote:
> 
> > Isn't it cool to take care of the board-specific with the same interface
> > kernel time system uses?  Every MIPS board gets a basic RTC driver for free!
> 
>  Well, I'm not that convinced.  What's wrong with making real support for
> the RTC chip instead?
>

Nothing wrong with full RTC driver support - it is just that when
30+ MIPS boards don't have to add #ifdef's to rtc.c and mc146818rtc.h
and hwclock still works people start appreciate more about the
existence of rtc_set_time().

> > 
> > What is the race condition?  And what is the performance hit?
> 
>  You need to read from the RTC, modify minutes and seconds as appropriate
> and write the RTC back.  Meanwhile the time as stored in the RTC may
> change.  With the 500 ms offset approximation as used by time.c it may be
> unlikely, but that assumption is for the MC146818 and it may not be true
> for incompatible RTC chips.  That is the race.  The performance hit is
> obvious -- now a read is added to the write.
>

OK, I see the performance hit now.

If you really want, how about the following change:

1) add set_rtc_mmss() function pointer in asm/time.h.
2) set it equal to set_rtc_time in time_init().  Board can override
   this decision in board_timer_setup() for better performance.
3) RTC update is changed to call set_rtc_mmss()

How does this sound?  It leaves all existing code unchanged, while
gives a way for optimization.  The default setting of set_rtc_mmss
to set_rtc_time makes logical sense too, because set_rtc_mmss is really
a "back door" version of set_rtc_time().

Jun

From DennisCastleman@oaktech.com Wed Jul 23 03:13:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 03:13:11 +0100 (BST)
Received: from mx1.teralogic.tv ([IPv6:::ffff:207.16.148.27]:62915 "EHLO
	mail.teralogic.tv") by linux-mips.org with ESMTP
	id <S8225239AbTGWCNJ>; Wed, 23 Jul 2003 03:13:09 +0100
Received: from tlexmail.teralogic.tv (uugate-2.oaktech.com [207.16.148.1])
	by mail.teralogic.tv (8.11.6/8.11.6) with ESMTP id h6N28fG04239;
	Tue, 22 Jul 2003 19:08:41 -0700 (PDT)
Received: by tlexposeidon.teralogic-inc.com with Internet Mail Service (5.5.2653.19)
	id <L92RZBD4>; Tue, 22 Jul 2003 19:03:42 -0700
Message-ID: <56BEF0DBC8B9D611BFDB00508B5E263410301F@tlexposeidon.teralogic-inc.com>
From: Dennis Castleman <DennisCastleman@oaktech.com>
To: "'Wolfgang Denk'" <wd@denx.de>,
	Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
Subject: RE: Profiling tools 
Date: Tue, 22 Jul 2003 19:03:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C350BE.A1BAFB60"
Return-Path: <DennisCastleman@oaktech.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: 2879
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: DennisCastleman@oaktech.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_01C350BE.A1BAFB60
Content-Type: text/plain

I'm looking for something like 
http://sourceforge.net/projects/oprofile/
Running on mips.

-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de] 
Sent: Tuesday, July 22, 2003 5:04 PM
To: Dennis Castleman
Cc: linux-mips@linux-mips.org
Subject: Re: Profiling tools 


Dear Dennis,

in message
<56BEF0DBC8B9D611BFDB00508B5E263410301E@tlexposeidon.teralogic-inc.com> you
wrote:
>
> Any body have any experience will finding
> Profile tool for mips-linux?

What exactly are you looking for? There can be several intentions  to
"profile" software.

> I'm running MontaVista 2.4.17 on a mips 5kc core.
> I'm running linux on top of RTAI 2.24.1.8
> If I can find a profiler that work with the 5kc, then I'll add
> RTAI support, if necessary.

Did you have a look at the LTT? See http://www.opersys.com/LTT/index.html

> ------_=_NextPart_001_01C350AB.506AC4B0
> Content-Type: text/html
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

Please: don't post HTML to mailing lists.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de I am
not now, nor have I ever been, a member of the demigodic party.
                                                   -- Dennis Ritchie

------_=_NextPart_001_01C350BE.A1BAFB60
Content-Type: text/html
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=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Profiling tools </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I'm looking for something like </FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://sourceforge.net/projects/oprofile/" =
TARGET=3D"_blank">http://sourceforge.net/projects/oprofile/</A></FONT>
<BR><FONT SIZE=3D2>Running on mips.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Wolfgang Denk [<A =
HREF=3D"mailto:wd@denx.de">mailto:wd@denx.de</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, July 22, 2003 5:04 PM</FONT>
<BR><FONT SIZE=3D2>To: Dennis Castleman</FONT>
<BR><FONT SIZE=3D2>Cc: linux-mips@linux-mips.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Profiling tools </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Dear Dennis,</FONT>
</P>

<P><FONT SIZE=3D2>in message =
&lt;56BEF0DBC8B9D611BFDB00508B5E263410301E@tlexposeidon.teralogic-inc.co=
m&gt; you wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Any body have any experience will =
finding</FONT>
<BR><FONT SIZE=3D2>&gt; Profile tool for mips-linux?</FONT>
</P>

<P><FONT SIZE=3D2>What exactly are you looking for? There can be =
several intentions&nbsp; to &quot;profile&quot; software.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I'm running MontaVista 2.4.17 on a mips 5kc =
core.</FONT>
<BR><FONT SIZE=3D2>&gt; I'm running linux on top of RTAI =
2.24.1.8</FONT>
<BR><FONT SIZE=3D2>&gt; If I can find a profiler that work with the =
5kc, then I'll add</FONT>
<BR><FONT SIZE=3D2>&gt; RTAI support, if necessary.</FONT>
</P>

<P><FONT SIZE=3D2>Did you have a look at the LTT? See <A =
HREF=3D"http://www.opersys.com/LTT/index.html" =
TARGET=3D"_blank">http://www.opersys.com/LTT/index.html</A></FONT>
</P>

<P><FONT SIZE=3D2>&gt; ------_=3D_NextPart_001_01C350AB.506AC4B0</FONT>
<BR><FONT SIZE=3D2>&gt; Content-Type: text/html</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML =
3.2//EN&quot;&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Please: don't post HTML to mailing lists.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Best regards,</FONT>
</P>

<P><FONT SIZE=3D2>Wolfgang Denk</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Software Engineering:&nbsp; Embedded and Realtime =
Systems,&nbsp; Embedded Linux</FONT>
<BR><FONT SIZE=3D2>Phone: (+49)-8142-4596-87&nbsp; Fax: =
(+49)-8142-4596-88&nbsp; Email: wd@denx.de I am not now, nor have I =
ever been, a member of the demigodic party.</FONT></P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; -- Dennis Ritchie</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C350BE.A1BAFB60--

From fpga_dsp@yahoo.com.au Wed Jul 23 06:50:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 06:50:47 +0100 (BST)
Received: from web41209.mail.yahoo.com ([IPv6:::ffff:66.218.93.42]:2990 "HELO
	web41209.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225193AbTGWFup>; Wed, 23 Jul 2003 06:50:45 +0100
Message-ID: <20030723055031.64921.qmail@web41209.mail.yahoo.com>
Received: from [64.132.226.151] by web41209.mail.yahoo.com via HTTP; Wed, 23 Jul 2003 15:50:31 EST
Date: Wed, 23 Jul 2003 15:50:31 +1000 (EST)
From: =?iso-8859-1?q?fpga=20dsp?= <fpga_dsp@yahoo.com.au>
Subject: Debug linux kernel with bdi2000 debugger?
To: linux-mips@linux-mips.org
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E263410301E@tlexposeidon.teralogic-inc.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1099539574-1058939431=:64324"
Content-Transfer-Encoding: 8bit
Return-Path: <fpga_dsp@yahoo.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: 2880
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fpga_dsp@yahoo.com.au
Precedence: bulk
X-list: linux-mips

--0-1099539574-1058939431=:64324
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Hi all,

I just got my hand on a bdi2000 debugger recently and try to play around with it. It does everything i want but i am trying to figure out how to debug linux kernel. The linux kernel from AMD is used on a db1500 board. I did enable debuging option -g in the makefile, load it into the target and run it. But in the minicom window i alway got the TLB exception ( on load or store or instruction fetch). 

I suspect that i didn't initialize TLB table so it will cause the above error. However, what doesn't make sense to me is:

The same kernel, if i loaded using yamon through ethernet, it booted ok even i didn't initialize TLB table. Now if I loaded it by bdi2000, and run by bdi2000, it cause exception. In both methods, the hardware is initialized by yamon code. My assumption that it is the same in both case. So what is the difference? Any explanation will be appreciated. And am i correct that I need to initialize TLB before boot the kernel in bdi2000 ?

Many thanks!

Khuong



---------------------------------
Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
--0-1099539574-1058939431=:64324
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<P>Hi all,</P>
<P>I just got my hand on a bdi2000 debugger recently and try to play around with it. It does everything i want but i am trying to figure out how to debug linux kernel. The linux kernel from AMD is used on a db1500 board. I did enable debuging option -g in the makefile, load it into the target and run it. But in the minicom window i alway got the TLB exception ( on load or store or instruction fetch). </P>
<P>I suspect that i didn't initialize TLB table so it will cause the above error. However, what doesn't make sense to me is:</P>
<P>The same kernel, if i loaded using yamon through ethernet, it booted ok even i didn't initialize TLB table. Now if I loaded it by bdi2000, and run by bdi2000, it cause exception. In both methods, the hardware is initialized by yamon code. My assumption that it is the same in both case. So what is the difference? Any explanation will be appreciated. And am i correct that I need to initialize TLB before boot the kernel in bdi2000 ?</P>
<P>Many thanks!</P>
<P>Khuong</P><p><br><hr size=1>
<a href="http://au.rd.yahoo.com/mail/tagline/?http://au.mobile.yahoo.com/sms/mail/index.html" target=_blank><b>Yahoo! Mobile</b></a><br>
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
--0-1099539574-1058939431=:64324--

From saravana_kumar@naturesoft.net Wed Jul 23 07:18:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 07:19:04 +0100 (BST)
Received: from [IPv6:::ffff:203.145.184.221] ([IPv6:::ffff:203.145.184.221]:18953
	"EHLO naturesoft.net") by linux-mips.org with ESMTP
	id <S8225193AbTGWGS5>; Wed, 23 Jul 2003 07:18:57 +0100
Received: from [192.168.0.206] (helo=nskumar.naturesoft.com)
	by naturesoft.net with esmtp (Exim 3.35 #1)
	id 19fCw8-0002xZ-00
	for linux-mips@linux-mips.org; Wed, 23 Jul 2003 11:47:16 +0530
Subject: Cross Compilation
From: SaravanaKumar <saravana_kumar@naturesoft.net>
Reply-To: saravana_kumar@naturesoft.net
To: linux-mips@linux-mips.org
Content-Type: text/plain
Organization: 
Message-Id: <1058941229.9252.13.camel@192.168.0.206>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 23 Jul 2003 11:50:29 +0530
Content-Transfer-Encoding: 7bit
Return-Path: <saravana_kumar@naturesoft.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: 2881
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: saravana_kumar@naturesoft.net
Precedence: bulk
X-list: linux-mips

Dear All, 
    I am having my application in x86. 
 I have to cross compile that to MIPS architecture. 
How to do that. 

Is there is any document for doing the cross compilation to MIPS.

Cheers, 
N.S.Kumar


From jinum@esntechnologies.co.in Wed Jul 23 07:27:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 07:27:55 +0100 (BST)
Received: from [IPv6:::ffff:202.125.80.34] ([IPv6:::ffff:202.125.80.34]:57098
	"EHLO mail.esn.activedirectory") by linux-mips.org with ESMTP
	id <S8225193AbTGWG1w>; Wed, 23 Jul 2003 07:27:52 +0100
Received: by mail.esn.activedirectory with Internet Mail Service (5.5.2650.10)
	id <PH8476VD>; Wed, 23 Jul 2003 11:53:02 +0530
Message-ID: <AF572D578398634881E52418B2892567177FF3@mail.esn.activedirectory>
From: JinuM <jinum@esntechnologies.co.in>
To: saravana_kumar@naturesoft.net
Cc: linux-mips@linux-mips.org
Subject: RE: Cross Compilation
Date: Wed, 23 Jul 2003 11:52:58 +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: 2882
X-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

try http://www.linux-vr.org/tools.html

-Jinu

-----Original Message-----
From: SaravanaKumar [mailto:saravana_kumar@naturesoft.net]
Sent: Wednesday, July 23, 2003 11:50 AM
To: linux-mips@linux-mips.org
Subject: Cross Compilation


Dear All, 
    I am having my application in x86. 
 I have to cross compile that to MIPS architecture. 
How to do that. 

Is there is any document for doing the cross compilation to MIPS.

Cheers, 
N.S.Kumar


From debashis@alumnux.com Wed Jul 23 07:41:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 07:41:14 +0100 (BST)
Received: from [IPv6:::ffff:203.197.124.190] ([IPv6:::ffff:203.197.124.190]:45577
	"EHLO alumnux.com") by linux-mips.org with ESMTP
	id <S8225193AbTGWGlM>; Wed, 23 Jul 2003 07:41:12 +0100
Received: from alumnux.com (mamata.alumnus.co.in [192.168.10.121])
	by alumnux.com (8.9.3/8.9.3) with ESMTP id RAA28715;
	Wed, 23 Jul 2003 17:46:33 +0530
Message-ID: <3F1E2DD3.4397EDE@alumnux.com>
Date: Wed, 23 Jul 2003 12:10:20 +0530
From: debashis <debashis@alumnux.com>
Organization: Alumnus Software Ltd
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: saravana_kumar@naturesoft.net
CC: linux-mips@linux-mips.org
Subject: Re: Cross Compilation
References: <1058941229.9252.13.camel@192.168.0.206>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <debashis@alumnux.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: 2883
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: debashis@alumnux.com
Precedence: bulk
X-list: linux-mips

Hi,
see the url - http://www.linux-mips.org/toolchain.html
You need to install the appropiate toolchains.

Regards,
debashis

SaravanaKumar wrote:

> Dear All,
>     I am having my application in x86.
>  I have to cross compile that to MIPS architecture.
> How to do that.
>
> Is there is any document for doing the cross compilation to MIPS.
>
> Cheers,
> N.S.Kumar


From adeelm@enabtech.com Wed Jul 23 07:59:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 07:59:42 +0100 (BST)
Received: from 168-215-210-130.gen.twtelecom.net ([IPv6:::ffff:168.215.210.130]:49626
	"EHLO avaznet.com") by linux-mips.org with ESMTP
	id <S8225193AbTGWG7k>; Wed, 23 Jul 2003 07:59:40 +0100
Received: from adeel ([172.16.1.196])
	by avaznet.com (8.9.3/8.9.3) with SMTP id AAA06201
	for <linux-mips@linux-mips.org>; Wed, 23 Jul 2003 00:06:34 -0700 (PDT)
Reply-To: <adeelm@avaznet.com>
From: "Adeel Malik" <adeelm@avaznet.com>
To: <linux-mips@linux-mips.org>
Subject: help
Date: Wed, 23 Jul 2003 11:53:48 +0500
Message-ID: <000001c350e7$2b99c0f0$620aa8c0@enabtech>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C35111.14714F90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Return-Path: <adeelm@enabtech.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: 2884
X-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 is a multi-part message in MIME format.

------=_NextPart_000_0001_01C35111.14714F90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit



------=_NextPart_000_0001_01C35111.14714F90
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY style=3D"COLOR: #000000; FONT-FAMILY: Arial">
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0001_01C35111.14714F90--


From adeelm@enabtech.com Wed Jul 23 08:05:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 08:05:51 +0100 (BST)
Received: from 168-215-210-130.gen.twtelecom.net ([IPv6:::ffff:168.215.210.130]:4059
	"EHLO avaznet.com") by linux-mips.org with ESMTP
	id <S8225193AbTGWHFt>; Wed, 23 Jul 2003 08:05:49 +0100
Received: from adeel ([172.16.1.196])
	by avaznet.com (8.9.3/8.9.3) with SMTP id AAA06252
	for <linux-mips@linux-mips.org>; Wed, 23 Jul 2003 00:12:47 -0700 (PDT)
Reply-To: <adeelm@avaznet.com>
From: "Adeel Malik" <adeelm@avaznet.com>
To: <linux-mips@linux-mips.org>
Subject: How to get myself unsubscribed from the list
Date: Wed, 23 Jul 2003 12:00:01 +0500
Message-ID: <000d01c350e8$09d25580$620aa8c0@enabtech>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000E_01C35111.F2A85D80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Return-Path: <adeelm@enabtech.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: 2885
X-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 is a multi-part message in MIME format.

------=_NextPart_000_000E_01C35111.F2A85D80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi All,
         Can someone infom as to how can I get myself unsubscribed from the
list.

Regards,
ADEEL MALIK




------=_NextPart_000_000E_01C35111.F2A85D80
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY style=3D"COLOR: #000000; FONT-FAMILY: Arial">
<DIV><SPAN class=3D840265806-23072003><FONT size=3D2>Hi =
All,</FONT></SPAN></DIV>
<DIV><SPAN class=3D840265806-23072003><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Can someone =
infom as to=20
how can I get myself unsubscribed from the list.</FONT></SPAN></DIV>
<DIV><SPAN class=3D840265806-23072003><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D840265806-23072003><FONT =
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV class=3DSection1>
<P><SPAN><FONT face=3DGeorgia color=3D#0000ff size=3D2><EM>ADEEL MALIK=20
<BR></EM></FONT></SPAN></P></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000E_01C35111.F2A85D80--


From tk@mycable.de Wed Jul 23 08:44:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 08:44:17 +0100 (BST)
Received: from [IPv6:::ffff:62.116.167.108] ([IPv6:::ffff:62.116.167.108]:55513
	"EHLO oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225193AbTGWHoN>; Wed, 23 Jul 2003 08:44:13 +0100
Received: from mycable.de (pD9527980.dip.t-dialin.net [217.82.121.128])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id h6N7bgC7015101;
	Wed, 23 Jul 2003 09:37:43 +0200
Message-ID: <3F1E3D27.2030501@mycable.de>
Date: Wed, 23 Jul 2003 09:45:43 +0200
From: Tiemo Krueger - mycable GmbH <tk@mycable.de>
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: saravana_kumar@naturesoft.net
CC: linux-mips@linux-mips.org
Subject: Re: Cross Compilation
References: <1058941229.9252.13.camel@192.168.0.206>
In-Reply-To: <1058941229.9252.13.camel@192.168.0.206>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@mycable.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: 2886
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips

You could even use the buildroot thing from uclibc.org:

http://uclibc.org/cgi-bin/cvsweb/buildroot/buildroot.tar.gz?tarball=1

It's one of the most simple way for cross toolchain beginners, it
provides you finally with a toolchain and rootfile system and more

Tiemo

SaravanaKumar wrote:

>Dear All, 
>    I am having my application in x86. 
> I have to cross compile that to MIPS architecture. 
>How to do that. 
>
>Is there is any document for doing the cross compilation to MIPS.
>
>Cheers, 
>N.S.Kumar
>
>
>
>  
>



From eric_sy_huang@wneweb.com.tw Wed Jul 23 11:01:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 11:01:29 +0100 (BST)
Received: from smtp.wneweb.com.tw ([IPv6:::ffff:61.220.210.41]:31505 "EHLO
	smtp.wneweb.com.tw") by linux-mips.org with ESMTP
	id <S8225193AbTGWKB0>; Wed, 23 Jul 2003 11:01:26 +0100
Received: from TWWNCDS1.WNEWEB.COM.TW (unverified) by smtp.wneweb.com.tw 
    (Content Technologies SMTPRS 4.3.6) with SMTP id 
    <T639cbd2ab20a25ee0b4d0@smtp.wneweb.com.tw> for 
    <linux-mips@linux-mips.org>; Wed, 23 Jul 2003 18:03:25 +0800
Received: by TWWNCDS1.WNEWEB.COM.TW 
    (Lotus SMTP MTA v4.6.7  (934.1 12-30-1999)) id 48256D6C.0036FF6D; Wed, 23 
    Jul 2003 18:00:43 +0800
X-Lotus-FromDomain: WISTRON
From: eric_sy_huang@wneweb.com.tw
To: linux-mips@linux-mips.org
Message-ID: <48256D6C.0036FDC1.00@TWWNCDS1.WNEWEB.COM.TW>
Date: Wed, 23 Jul 2003 18:01:06 +0800
Subject: RE: Cross Compilation
Mime-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-Disposition: inline
Return-Path: <eric_sy_huang@wneweb.com.tw>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2887
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eric_sy_huang@wneweb.com.tw
Precedence: bulk
X-list: linux-mips




  If I want to build big-endian mips, how can I do?
  In the www.linux-vr.org, there is only little-endian tools.

  regards.




This document is classified as     Normal



try http://www.linux-vr.org/tools.html

-Jinu

-----Original Message-----
From: SaravanaKumar [mailto:saravana_kumar@naturesoft.net]
Sent: Wednesday, July 23, 2003 11:50 AM
To: linux-mips@linux-mips.org
Subject: Cross Compilation


Dear All,
    I am having my application in x86.
 I have to cross compile that to MIPS architecture.
How to do that.

Is there is any document for doing the cross compilation to MIPS.

Cheers,
N.S.Kumar






From jimt@vivato.net Wed Jul 23 11:07:53 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 11:07:55 +0100 (BST)
Received: from exchange.mabuhaynetworks.com ([IPv6:::ffff:206.169.233.186]:47889
	"EHLO exchange.vivato.net") by linux-mips.org with ESMTP
	id <S8225193AbTGWKHx> convert rfc822-to-8bit; Wed, 23 Jul 2003 11:07:53 +0100
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: Cross Compilation
Date: Wed, 23 Jul 2003 03:07:25 -0700
Message-ID: <D8B86D9BB607124BA1D54EDB7944DB0B013D44E1@exchange.mabuhay>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cross Compilation
Thread-Index: AcNQ7p5s83SLYOUCRZ2hZlELKbrQPQAE5LiQ
From: "Jim Thompson" <jimt@vivato.net>
To: "Tiemo Krueger - mycable GmbH" <tk@mycable.de>,
	<saravana_kumar@naturesoft.net>
Cc: <linux-mips@linux-mips.org>
Return-Path: <jimt@vivato.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: 2888
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jimt@vivato.net
Precedence: bulk
X-list: linux-mips

Unfortunately, its broken right now.

> -----Original Message-----
> From: Tiemo Krueger - mycable GmbH [mailto:tk@mycable.de]
> Sent: Wednesday, July 23, 2003 12:46 AM
> To: saravana_kumar@naturesoft.net
> Cc: linux-mips@linux-mips.org
> Subject: Re: Cross Compilation
> 
> You could even use the buildroot thing from uclibc.org:
> 
> http://uclibc.org/cgi-bin/cvsweb/buildroot/buildroot.tar.gz?tarball=1
> 
> It's one of the most simple way for cross toolchain beginners, it
> provides you finally with a toolchain and rootfile system and more
> 
> Tiemo
> 
> SaravanaKumar wrote:
> 
> >Dear All,
> >    I am having my application in x86.
> > I have to cross compile that to MIPS architecture.
> >How to do that.
> >
> >Is there is any document for doing the cross compilation to MIPS.
> >
> >Cheers,
> >N.S.Kumar
> >
> >
> >
> >
> >
> 
> 


From dkesselr@mmc.atmel.com Wed Jul 23 13:48:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 13:48:27 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:31116
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225193AbTGWMsY>; Wed, 23 Jul 2003 13:48:24 +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 IAA01880
	for <linux-mips@linux-mips.org>; Wed, 23 Jul 2003 08:48:04 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id IAA17982
	for <linux-mips@linux-mips.org>; Wed, 23 Jul 2003 08:48:04 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Wed, 23 Jul 2003 08:48:03 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: odd link error
Message-ID: <Pine.GSO.4.44.0307230844470.17973-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: 2889
X-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

I know my build for a custom board isn't right but it got through the
compiles only to get this link error. Does anyone know what it might point
to?

mips64el-linux-ld --oformat elf32-tradlittlemips -G 0 -static  -T
arch/mips64/ld.script.elf32 -Ttext  arch/mips64/kernel/head.o
arch/mips64/kernel/init_task.o init/main.o init/version.o init/do_mounts.o
\
        --start-group \
        arch/mips64/kernel/kernel.o arch/mips64/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o
arch/mips/ramdisk/ramdisk.o \
         drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o \
        net/network.o \
        arch/mips64/lib/lib.a
/home/dkesselr/stbsw/linux/linux-64sead/lib/lib.a \
        --end-group \
        -o vmlinux
mips64el-linux-ld: invalid hex number `arch/mips64/kernel/head.o'
make: *** [vmlinux] Error 1


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


From brm@tt.dk Wed Jul 23 15:27:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 15:27:22 +0100 (BST)
Received: from [IPv6:::ffff:212.130.55.83] ([IPv6:::ffff:212.130.55.83]:776
	"EHLO NTEX.tt.dk") by linux-mips.org with ESMTP id <S8225193AbTGWO1U>;
	Wed, 23 Jul 2003 15:27:20 +0100
Received: from lnsw.ttnet ([89.1.6.39]) by NTEX.tt.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 3ZYQSRDM; Wed, 23 Jul 2003 16:26:42 +0200
Received: from brmlinux.ttnet ([89.1.5.102] helo=tt.dk)
	by lnsw.ttnet with esmtp (Exim 3.35 #1 (Debian))
	id 19fKZm-000601-00; Wed, 23 Jul 2003 16:26:42 +0200
Message-ID: <3F1E9B22.8000604@tt.dk>
Date: Wed, 23 Jul 2003 16:26:42 +0200
From: Brian Murphy <brm@tt.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
X-Accept-Language: en, en-ie
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
CC: linux-mips@linux-mips.org
Subject: Re: odd link error
References: <Pine.GSO.4.44.0307230844470.17973-100000@ares.mmc.atmel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brm@tt.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2890
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brm@tt.dk
Precedence: bulk
X-list: linux-mips

David Kesselring wrote:

>I know my build for a custom board isn't right but it got through the
>compiles only to get this link error. Does anyone know what it might point
>to?
>
>mips64el-linux-ld --oformat elf32-tradlittlemips -G 0 -static  -T
>arch/mips64/ld.script.elf32 -Ttext  arch/mips64/kernel/head.o
>arch/mips64/kernel/init_task.o init/main.o init/version.o init/do_mounts.o
>\
>        --start-group \
>        arch/mips64/kernel/kernel.o arch/mips64/mm/mm.o kernel/kernel.o
>mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o
>arch/mips/ramdisk/ramdisk.o \
>         drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
>drivers/net/net.o drivers/media/media.o \
>        net/network.o \
>        arch/mips64/lib/lib.a
>/home/dkesselr/stbsw/linux/linux-64sead/lib/lib.a \
>        --end-group \
>        -o vmlinux
>mips64el-linux-ld: invalid hex number `arch/mips64/kernel/head.o'
>make: *** [vmlinux] Error 1
>
>  
>
-Ttext expects an argument, the hex number mentioned, and it is for some 
reason missing.
Since

arch/mips64/kernel/head.o

is not a valid hex number the build fails. You probably have some make 
variable which is not
defined which should be. You should look at the makefile which contains 
the linker line
and find -Ttext $(MISSING_VARIABLE) and find out why MISSING_VARIABLE is 
not set.

/Brian



From macro@ds2.pg.gda.pl Wed Jul 23 15:53:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 15:53:22 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:6868 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225193AbTGWOxU>; Wed, 23 Jul 2003 15:53:20 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA26816;
	Wed, 23 Jul 2003 16:52:32 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 23 Jul 2003 16:52:31 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
In-Reply-To: <20030722181430.I3135@mvista.com>
Message-ID: <Pine.GSO.3.96.1030723164616.26641A-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: 2891
X-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, 22 Jul 2003, Jun Sun wrote:

> > > Isn't it cool to take care of the board-specific with the same interface
> > > kernel time system uses?  Every MIPS board gets a basic RTC driver for free!
> > 
> >  Well, I'm not that convinced.  What's wrong with making real support for
> > the RTC chip instead?
> >
> 
> Nothing wrong with full RTC driver support - it is just that when
> 30+ MIPS boards don't have to add #ifdef's to rtc.c and mc146818rtc.h
> and hwclock still works people start appreciate more about the
> existence of rtc_set_time().

 Hmm, but how many different RTC chips are out there?  I agree the current
rtc.c/mc146818rtc.h implementation sucks, but it should be fixed and not
worked around.

> If you really want, how about the following change:
> 
> 1) add set_rtc_mmss() function pointer in asm/time.h.
> 2) set it equal to set_rtc_time in time_init().  Board can override
>    this decision in board_timer_setup() for better performance.
> 3) RTC update is changed to call set_rtc_mmss()
> 
> How does this sound?  It leaves all existing code unchanged, while
> gives a way for optimization.  The default setting of set_rtc_mmss
> to set_rtc_time makes logical sense too, because set_rtc_mmss is really
> a "back door" version of set_rtc_time().

 That's just fine for me.

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


From hjl@lucon.org Wed Jul 23 17:18:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 17:18:32 +0100 (BST)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:43442 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225193AbTGWQS1>; Wed, 23 Jul 2003 17:18:27 +0100
Received: from lucon.org ([12.234.88.5]) by comcast.net (sccrmhc11) with ESMTP
          id <2003072316181701100o3njde>; Wed, 23 Jul 2003 16:18:17 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 8AADE2C4EB; Wed, 23 Jul 2003 16:18:15 +0000 (UTC)
Date: Wed, 23 Jul 2003 09:18:15 -0700
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org,
	GNU C Library <libc-alpha@sources.redhat.com>,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	"Steven J. Hill" <sjhill@realitydiluted.com>
Subject: The Linux binutils 2.14.90.0.5 is released
Message-ID: <20030723161815.GA17794@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <hjl@lucon.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: 2892
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

This is the beta release of binutils 2.14.90.0.5 for Linux, which is
based on binutils 2003 0722 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.

Please report any bugs related to binutils 2.14.90.0.5 to hjl@lucon.org.

If you don't use

# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.gz

to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches.

Changes from binutils 2.14.90.0.4.1:

1. Update from binutils 2003 0722.
2. Fix an ELF/mips linker bug.
3. Fix an ELF/hpppa linker bug.
4. Fix an ELF/ia64 assembler bug.
5. Fix a linkonce support with C++ debug.
6. A new working C++ demangler.
7. Various alpha, mips, ia64, ... bug fixes.
8. Support for the current gcc and glibc.

Changes from binutils 2.14.90.0.4:
 
1. Fix an ia64 assembler hint@pause bug.
2. Support Intel Precott New Instructions.

Changes from binutils 2.14.90.0.3:

1. Work around the brain dead libtool.

Changes from binutils 2.14.90.0.2:

1. Update from binutils 2003 0523.
2. Fix 2 ELF visibility bugs.
3. Fix ELF/ppc linker bugs.

Changes from binutils 2.14.90.0.1:

1. Update from binutils 2003 0515.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Add more IAS compatibilities to ia64 assembler.

Changes from binutils 2.13.90.0.20:

1. Update from binutils 2003 0505.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Fix some ia64 assembler bugs.
5. Add some IAS compatibilities to ia64 assembler.
6. Fix ELF common symbol alignment.
7. Fix ELF weak symbol handling.

Changes from binutils 2.13.90.0.18:

1. Update from binutils 2003 0319.
2. Fix an ia64 linker brl relaxation bug.
3. Fix some ELF/ppc linker bugs.

Changes from binutils 2.13.90.0.16:

1. Update from binutils 2003 0121.
2. Fix an ia64 gas bug.
3. Fix some TLS bugs.
4. Fix some ELF/ppc bugs.
5. Fix an ELF/m68k bug.

2. Include /usr/bin/c++filt.
Changes from binutils 2.13.90.0.14:

1. Update from binutils 2002 1126.
2. Include /usr/bin/c++filt.
3. Fix "ld -r" with execption handling.

Changes from binutils 2.13.90.0.10:

1. Update from binutils 2002 1114.
2. Fix ELF/alpha bugs.
3. Fix an ELF/i386 assembler bug.

Changes from binutils 2.13.90.0.4:

1. Update from binutils 2002 1010.
2. More ELF/PPC linker bug fixes.
3. Fix an ELF/alpha linker bug.
4. Fix an ELF/sparc linker bug to support Solaris.
5. More TLS updates.

Changes from binutils 2.13.90.0.3:

1. Update from binutils 2002 0814.
2. Fix symbol versioning bugs for gcc 3.2.
3. Fix mips gas.

Changes from binutils 2.13.90.0.2:

1. Update from binutils 2002 0809.
2. Fix a mips gas compatibility bug.
3. Fix an x86 TLS bfd bug.
4. Fix an x86 PIC gas bug.
5. Improve symbol versioning support.

The file list:

1. binutils-2.14.90.0.5.tar.gz. Source code.
2. binutils-2.14.90.0.4.1-2.14.90.0.5.diff.gz. Patch against the
   previous beta source code.
3. binutils-2.14.90.0.5-1.i386.rpm. IA-32 binary RPM for RedHat 9.
4. binutils-2.14.90.0.5-1.ia64.rpm. IA-64 binary RPM for RedHat AS 2.1.

There is no separate source rpm. You can do

# rpmbuild -ta binutils-2.14.90.0.5.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

1. http://www.kernel.org/pub/linux/devel/binutils/

Thanks.


H.J. Lu
hjl@lucon.org
07/22/2003

From ralf@linux-mips.org Wed Jul 23 17:52:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 17:52:38 +0100 (BST)
Received: from p508B586D.dip.t-dialin.net ([IPv6:::ffff:80.139.88.109]:31117
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225193AbTGWQwg>; Wed, 23 Jul 2003 17:52:36 +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 h6NGqXpG006282;
	Wed, 23 Jul 2003 18:52:34 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6NGqWde006281;
	Wed, 23 Jul 2003 18:52:32 +0200
Date: Wed, 23 Jul 2003 18:52:32 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: odd link error
Message-ID: <20030723165231.GA5851@linux-mips.org>
References: <Pine.GSO.4.44.0307230844470.17973-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0307230844470.17973-100000@ares.mmc.atmel.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: 2893
X-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, Jul 23, 2003 at 08:48:03AM -0400, David Kesselring wrote:

> I know my build for a custom board isn't right but it got through the
> compiles only to get this link error. Does anyone know what it might point
> to?

Seems the SEAD bits in your Makefile are incomplete, arch/mips64/Makefile
should contain this:

[...]
#
# MIPS SEAD board
#
ifdef CONFIG_MIPS_SEAD
LIBS            += arch/mips/mips-boards/sead/sead.o \
                   arch/mips/mips-boards/generic/mipsboards.o
SUBDIRS         += arch/mips/mips-boards/generic arch/mips/mips-boards/sead
LOADADDR        := 0x80100000
endif
[...]

  Ralf

From jsun@mvista.com Wed Jul 23 18:00:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 18:00:58 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:1022 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225193AbTGWRAu>;
	Wed, 23 Jul 2003 18:00:50 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6NH0hq17393;
	Wed, 23 Jul 2003 10:00:43 -0700
Date: Wed, 23 Jul 2003 10:00:43 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [patch] Generic time fixes
Message-ID: <20030723100043.M3135@mvista.com>
References: <20030722181430.I3135@mvista.com> <Pine.GSO.3.96.1030723164616.26641A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030723164616.26641A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Jul 23, 2003 at 04:52:31PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2894
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jul 23, 2003 at 04:52:31PM +0200, Maciej W. Rozycki wrote:
> On Tue, 22 Jul 2003, Jun Sun wrote:
> 
> > > > Isn't it cool to take care of the board-specific with the same interface
> > > > kernel time system uses?  Every MIPS board gets a basic RTC driver for free!
> > > 
> > >  Well, I'm not that convinced.  What's wrong with making real support for
> > > the RTC chip instead?
> > >
> > 
> > Nothing wrong with full RTC driver support - it is just that when
> > 30+ MIPS boards don't have to add #ifdef's to rtc.c and mc146818rtc.h
> > and hwclock still works people start appreciate more about the
> > existence of rtc_set_time().
> 
>  Hmm, but how many different RTC chips are out there?  I agree the current
> rtc.c/mc146818rtc.h implementation sucks, but it should be fixed and not
> worked around.
>

Most people seem to be happy with getting hwclock working.  rtc_set_time()
does allow a low-oevrhead way to implement a generic rtc driver which
makes hwclock happy.

I like see mc146818rtc related RTC go away eventually, but we don't have to 
agree on that right now.

> > If you really want, how about the following change:
> > 
> > 1) add set_rtc_mmss() function pointer in asm/time.h.
> > 2) set it equal to set_rtc_time in time_init().  Board can override
> >    this decision in board_timer_setup() for better performance.
> > 3) RTC update is changed to call set_rtc_mmss()
> > 
> > How does this sound?  It leaves all existing code unchanged, while
> > gives a way for optimization.  The default setting of set_rtc_mmss
> > to set_rtc_time makes logical sense too, because set_rtc_mmss is really
> > a "back door" version of set_rtc_time().
> 
>  That's just fine for me.
>

Something like the attached patch looks good to me.

Board now has the choice to implement either rtc_set_time, or
rtc_set_mmss, or both, or none.  Of course there are different
implications for each choice.  I probably should update the readme
a little too.

You can either include it in your next patch (if one is coming).  Or
just let me know and I will flesh it out and check it in.

Jun

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=junk

diff -Nru link/arch/mips/kernel/time.c.orig link/arch/mips/kernel/time.c
--- link/arch/mips/kernel/time.c.orig	Wed Jul 16 10:52:57 2003
+++ link/arch/mips/kernel/time.c	Wed Jul 23 09:52:53 2003
@@ -61,6 +61,7 @@
 
 unsigned long (*rtc_get_time)(void) = null_rtc_get_time;
 int (*rtc_set_time)(unsigned long) = null_rtc_set_time;
+int (*rtc_set_mmss)(unsigned long);
 
 
 /*
@@ -370,12 +371,16 @@
 	    xtime.tv_sec > last_rtc_update + 660 &&
 	    xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
 	    xtime.tv_usec <= 500000 + ((unsigned) tick) / 2) {
-		if (rtc_set_time(xtime.tv_sec) == 0) {
+		int ret;
+		if (rtc_set_mmss)
+			ret = rtc_set_mmss(xtime.tv_sec);
+		else
+			ret = rtc_set_time(xtime.tv_sec);
+		if (ret == 0) 
 			last_rtc_update = xtime.tv_sec;
-		} else {
-			last_rtc_update = xtime.tv_sec - 600;
+		else 
 			/* do it again in 60 s */
-		}
+			last_rtc_update = xtime.tv_sec - 600;
 	}
 	read_unlock (&xtime_lock);
 
diff -Nru link/include/asm-mips/time.h.orig link/include/asm-mips/time.h
--- link/include/asm-mips/time.h.orig	Wed Jul 16 11:49:53 2003
+++ link/include/asm-mips/time.h	Wed Jul 23 09:51:58 2003
@@ -27,9 +27,12 @@
  * RTC ops.  By default, they point a no-RTC functions.
  *	rtc_get_time - mktime(year, mon, day, hour, min, sec) in seconds.
  *	rtc_set_time - reverse the above translation and set time to RTC.
+ *	rtc_set_mmss - similar to rtc_set_time, but only mim and sec need
+ *			to be set.  Used by RTC sync-up.
  */
 extern unsigned long (*rtc_get_time)(void);
 extern int (*rtc_set_time)(unsigned long);
+extern int (*rtc_set_mmss)(unsigned long);
 
 /*
  * to_tm() converts system time back to (year, mon, day, hour, min, sec).

--FL5UXtIhxfXey3p5--

From jsun@mvista.com Wed Jul 23 18:10:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 18:10:02 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:13559 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225193AbTGWRKA>;
	Wed, 23 Jul 2003 18:10:00 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6NH9k706963;
	Wed, 23 Jul 2003 10:09:46 -0700
Date: Wed, 23 Jul 2003 10:09:46 -0700
From: Jun Sun <jsun@mvista.com>
To: Tiemo Krueger - mycable GmbH <tk@mycable.de>
Cc: saravana_kumar@naturesoft.net, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: Cross Compilation
Message-ID: <20030723100946.N3135@mvista.com>
References: <1058941229.9252.13.camel@192.168.0.206> <3F1E3D27.2030501@mycable.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F1E3D27.2030501@mycable.de>; from tk@mycable.de on Wed, Jul 23, 2003 at 09:45:43AM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2895
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Wed, Jul 23, 2003 at 09:45:43AM +0200, Tiemo Krueger - mycable GmbH wrote:
> You could even use the buildroot thing from uclibc.org:
> 
> http://uclibc.org/cgi-bin/cvsweb/buildroot/buildroot.tar.gz?tarball=1
> 
> It's one of the most simple way for cross toolchain beginners, it
> provides you finally with a toolchain and rootfile system and more
>

I took a look.  It looks similar to one project that I worked on
before.   Very interesting.

Has anybody tried successfully to do a cross MIPS yet?  From a Linux/i386 host
obviously ...

Jun

From bruno.randolf@4g-systems.biz Wed Jul 23 18:40:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 18:40:58 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.189]:44246
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225193AbTGWRky> convert rfc822-to-8bit; Wed, 23 Jul 2003 18:40:54 +0100
Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 19fNbP-00059A-00; Wed, 23 Jul 2003 19:40:35 +0200
Received: from [213.39.163.208] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 19fNbP-0001jt-00; Wed, 23 Jul 2003 19:40:35 +0200
From: Bruno Randolf <bruno.randolf@4g-systems.biz>
Organization: 4G Mobile Systeme
To: Jun Sun <jsun@mvista.com>
Subject: Re: Cross Compilation
Date: Wed, 23 Jul 2003 19:40:35 +0200
User-Agent: KMail/1.5.2
References: <1058941229.9252.13.camel@192.168.0.206> <3F1E3D27.2030501@mycable.de> <20030723100946.N3135@mvista.com>
In-Reply-To: <20030723100946.N3135@mvista.com>
Cc: saravana_kumar@naturesoft.net, linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <200307231940.35188.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: 2896
X-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

On Wednesday 23 July 2003 19:09, you wrote:

> Has anybody tried successfully to do a cross MIPS yet?  From a Linux/i386
> host obviously ...

yes, i have done that (last time around may 2003) and it worked great.

now it switched to a glibc based system, so i cant use it anymore 
unfortunately.

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

iD8DBQE/HsiTfg2jtUL97G4RAgwUAJ9uRIoJ13DGGdm9/ypW4ENYUxt2bgCeIoIc
L4YD+l4sTffpWcNBpZAE4FA=
=xYI+
-----END PGP SIGNATURE-----


From baitisj@idealab.com Wed Jul 23 19:27:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 19:27:34 +0100 (BST)
Received: from il-la.la.idealab.com ([IPv6:::ffff:63.251.211.5]:51126 "HELO
	idealab.com") by linux-mips.org with SMTP id <S8225211AbTGWS1b>;
	Wed, 23 Jul 2003 19:27:31 +0100
Received: (qmail 14554 invoked by uid 6180); 23 Jul 2003 18:27:27 -0000
Date: Wed, 23 Jul 2003 11:27:27 -0700
From: Jeff Baitis <baitisj@evolution.com>
To: Jun Sun <jsun@mvista.com>
Cc: Tiemo Krueger - mycable GmbH <tk@mycable.de>,
	saravana_kumar@naturesoft.net, linux-mips@linux-mips.org
Subject: Re: Cross Compilation
Message-ID: <20030723112727.R10468@luca.pas.lab>
Reply-To: baitisj@evolution.com
References: <1058941229.9252.13.camel@192.168.0.206> <3F1E3D27.2030501@mycable.de> <20030723100946.N3135@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030723100946.N3135@mvista.com>; from jsun@mvista.com on Wed, Jul 23, 2003 at 10:09:46AM -0700
Return-Path: <baitisj@idealab.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: 2897
X-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

I find that the uClibC tools are excellent, and have no problems generating
MIPS binaries from an i386 host ;)

-Jeff

On Wed, Jul 23, 2003 at 10:09:46AM -0700, Jun Sun wrote:
> On Wed, Jul 23, 2003 at 09:45:43AM +0200, Tiemo Krueger - mycable GmbH wrote:
> > You could even use the buildroot thing from uclibc.org:
> > 
> > http://uclibc.org/cgi-bin/cvsweb/buildroot/buildroot.tar.gz?tarball=1
> > 
> > It's one of the most simple way for cross toolchain beginners, it
> > provides you finally with a toolchain and rootfile system and more
> >
> 
> I took a look.  It looks similar to one project that I worked on
> before.   Very interesting.
> 
> Has anybody tried successfully to do a cross MIPS yet?  From a Linux/i386 host
> obviously ...
> 
> Jun
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 


From jimt@vivato.net Wed Jul 23 22:16:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 22:16:55 +0100 (BST)
Received: from exchange.mabuhaynetworks.com ([IPv6:::ffff:206.169.233.186]:23152
	"EHLO exchange.vivato.net") by linux-mips.org with ESMTP
	id <S8225193AbTGWVQw> convert rfc822-to-8bit; Wed, 23 Jul 2003 22:16:52 +0100
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: Cross Compilation
Date: Wed, 23 Jul 2003 14:16:45 -0700
Message-ID: <D8B86D9BB607124BA1D54EDB7944DB0B013D452F@exchange.mabuhay>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cross Compilation
Thread-Index: AcNRSCgnA3dsRI75Rbmxupity8AE+wAF1xAQ
From: "Jim Thompson" <jimt@vivato.net>
To: <baitisj@evolution.com>, "Jun Sun" <jsun@mvista.com>
Cc: "Tiemo Krueger - mycable GmbH" <tk@mycable.de>,
	<saravana_kumar@naturesoft.net>, <linux-mips@linux-mips.org>
Return-Path: <jimt@vivato.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: 2898
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jimt@vivato.net
Precedence: bulk
X-list: linux-mips

One more time, the current top-of-tree on 'buildroot' is broken.

Specifically, the 'chew' binary gets built for the target, but should be
built for the host.  The build fails when 'chew' gets run (because it
can't).

Erik is looking for a patch.

Jim


> -----Original Message-----
> From: Jeff Baitis [mailto:baitisj@evolution.com]
> Sent: Wednesday, July 23, 2003 11:27 AM
> To: Jun Sun
> Cc: Tiemo Krueger - mycable GmbH; saravana_kumar@naturesoft.net;
linux-
> mips@linux-mips.org
> Subject: Re: Cross Compilation
> 
> I find that the uClibC tools are excellent, and have no problems
> generating
> MIPS binaries from an i386 host ;)
> 
> -Jeff
> 
> On Wed, Jul 23, 2003 at 10:09:46AM -0700, Jun Sun wrote:
> > On Wed, Jul 23, 2003 at 09:45:43AM +0200, Tiemo Krueger - mycable
GmbH
> wrote:
> > > You could even use the buildroot thing from uclibc.org:
> > >
> > >
http://uclibc.org/cgi-bin/cvsweb/buildroot/buildroot.tar.gz?tarball=1
> > >
> > > It's one of the most simple way for cross toolchain beginners, it
> > > provides you finally with a toolchain and rootfile system and more
> > >
> >
> > I took a look.  It looks similar to one project that I worked on
> > before.   Very interesting.
> >
> > Has anybody tried successfully to do a cross MIPS yet?  From a
> Linux/i386 host
> > obviously ...
> >
> > Jun
> >
> 
> --
>          Jeffrey Baitis - Associate Software Engineer
> 
>                     Evolution Robotics, Inc.
>                      130 West Union Street
>                        Pasadena CA 91103
> 
>  tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com
> 


From hamilton@redhat.com Wed Jul 23 23:25:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jul 2003 23:25:50 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:40455 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225193AbTGWWZs>;
	Wed, 23 Jul 2003 23:25:48 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h6NMPZH14575;
	Wed, 23 Jul 2003 18:25:35 -0400
Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6NMPZI26658;
	Wed, 23 Jul 2003 18:25:35 -0400
Received: from redhat.com (slurm.hsv.redhat.com [172.16.16.102])
	by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id h6NMPYm16230;
	Wed, 23 Jul 2003 17:25:34 -0500
Message-ID: <3F1F0BDC.8040609@redhat.com>
Date: Wed, 23 Jul 2003 17:27:40 -0500
From: Louis Hamilton <hamilton@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
X-Accept-Language: en-us
MIME-Version: 1.0
To: ralf@linux-mips.org
CC: linux-mips@linux-mips.org
Subject: [patch] Mips64 Ocelot-C and Jaguar ATX platform support
Content-Type: multipart/mixed;
 boundary="------------030906050905080803010205"
Return-Path: <hamilton@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: 2899
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hamilton@redhat.com
Precedence: bulk
X-list: linux-mips

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

Ralf,

Here is 64-bit support for both the RM7000-based Ocelot-C and 
RM9000-based Jaguar ATX platforms.
Since the port was 2.4.21 based, this patch submission is for the 2.4 tree.
This patch supersedes the Ocelot-C patch I sent earlier, since it 
encompasses both platforms.

Notes the board support lives under arch/mips/momentum.
Also, CONFIG_BOARD_SCACHE and CONFIG_RM7000_CPU_SCACHE are utilized and
integrated into each platform's default configuration files.
As in the first patch, drivers/net/mv64340_eth.{c,h} is added to provide 
ethernet support.

If it looks ok, please check changes into the tree.

Regards,
Louis

Louis Hamilton
Red Hat, Inc.


--------------030906050905080803010205
Content-Type: text/plain;
 name="ocelotc-jaguar-patchlist"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ocelotc-jaguar-patchlist"

  `arch/mips/config-shared.in'
  `arch/mips/momentum/jaguar_atx/dbg_io.c'
  `arch/mips/momentum/jaguar_atx/int-handler.S'
  `arch/mips/momentum/jaguar_atx/irq.c'
  `arch/mips/momentum/jaguar_atx/jaguar_atx_fpga.h'
  `arch/mips/momentum/jaguar_atx/Makefile'
  `arch/mips/momentum/jaguar_atx/mv-irq.c'
  `arch/mips/momentum/jaguar_atx/pci.c'
  `arch/mips/momentum/jaguar_atx/pci-irq.c'
  `arch/mips/momentum/jaguar_atx/prom.c'
  `arch/mips/momentum/jaguar_atx/reset.c'
  `arch/mips/momentum/jaguar_atx/setup.c'
  `arch/mips/momentum/ocelot_c/ocelot_c_fpga.h'
  `arch/mips/momentum/ocelot_c/prom.c'
  `arch/mips/momentum/ocelot_c/reset.c'
  `arch/mips/momentum/ocelot_c/setup.c'
  `arch/mips64/defconfig-jaguar'
  `arch/mips64/defconfig-ocelotc'
  `arch/mips64/kernel/cpu-probe.c'
  `arch/mips64/kernel/pci-dma.c'
  `arch/mips64/kernel/proc.c'
  `arch/mips64/kernel/setup.c'
  `arch/mips64/Makefile'
  `arch/mips64/mm/c-r4k.c'
  `arch/mips64/mm/loadmmu.c'
  `arch/mips64/mm/Makefile'
  `arch/mips64/mm/sc-rm7k.c'
  `arch/mips64/mm/tlbex-r4k.S'
  `arch/mips64/mm/tlb-r4k.c'
  `drivers/char/serial.c'
  `drivers/net/Config.in'
  `drivers/net/Makefile'
  `drivers/net/mv64340_eth.c'
  `drivers/net/mv64340_eth.h'
  `drivers/scsi/scsi_merge.c'
  `include/asm-mips64/addrspace.h'
  `include/asm-mips64/bootinfo.h'
  `include/asm-mips64/cpu.h'
  `include/asm-mips64/io.h'
  `include/asm-mips64/mipsregs.h'
  `include/asm-mips64/page.h'
  `include/asm-mips64/serial.h'
  `net/core/skbuff.c'

  43 files

--------------030906050905080803010205
Content-Type: application/x-gzip;
 name="mips64-ocelotc-jaguar-patch.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="mips64-ocelotc-jaguar-patch.gz"

H4sICGkEHz8AA21pcHM2NC1vY2Vsb3RjLWphZ3Vhci1wYXRjaADsXGt72siS/ox/RR9nNoFw
sYRtfIvniQzC1hxAjAROspN5dIQQWDFIjC6+ZGb2t5+qbgldEAZ7fPbD7vAkRu6ueruqurq6
+iKPrcmEVAO3R2bzsVMd6Z5ZrdcOqt+C2WO1zu/prnGzN7cW3p7h2BNrWvVudNcc1yybMQDt
EzQ71Wr12cCFOsftV7mjKn9MuJNT7vj0oFHjog+pcocct1Mul7cRYIlV3yf84Wn9+PTweAXr
40dSPeIrDVKGnzxHPn7cISPHmZF3arBYOK5PJo5Lus7ctP1gTmTDnDk+UOju+B1pyr22dKl1
5a7Ya8qa3BQ78mAL/urlkwja5TYYTaLbY1JtqgzLWwfW3Ck/AfaTPg10tyoMPq+D+Um4HAqK
BhQ7ZWtCfiG7P6yl2CXnZPdxl/x6Rvwb094pExJqQkirKwgXHZHMzbnjPhJ0IueejHT7dtlk
CASUHfnTTnli7ZCxudBWxe+JTdJqXZBr16geckcHpCh+7ouKBPIMhE5pCQg0tDqSOEmVZ+MU
7sFRIwUEv2/Bc5ThOaIuBrzoYwfHXIU/oU4Gn7E5sWyTqRfyyJ2WNgABtSZ53CFogHyTR32b
Z/Ac2AtZUFqa2hSaVyIAr6FSukcwMLRmf7iRtN+U1leqn4S+Jsma2heaT2D0ZNDkSlSgN4D6
CTrxU2wTdIoXuWGaJ+VpeeRr+kdShVBQlOO1jb2mUWbsNZVZY68hWzE2emXj6AC9snHCV46o
UxaIcgxSFUImFI4WkK+0jueylbQkrKUKpWppCdSWsfZkpfZkyate8Mkq+HWXKAcPEJ9JdgSo
3b7WFPoYSrL9RlU62WfBnK+wcZbmjsXKMq+xGzJcCarWV8S2OGhehcOynAd7kgO7pvdXYG0W
7vLkpdZYFTaKq0PPxNhKfIcYM1N3YR5cPJKFPjXjWK5KF18GIrq71hcuRbmvhhPfMTXW/knY
/zlaHXxGpcL2qw72F/2kqQ65bahShqdU5TyqkyxVHhb1vE1U1HRkk1xdqa/u11NY461To3k4
k+59ozOppvsPe+PRVLOcmpGXpTxFv1XK9BRAgT9pnFT5enWfJ/zxKcfBv1TK01ifPj2Jy1Kp
gypXx1SKa5zWj1Zw0aO4CkfKkEjVG+hP5TeWbcyCsUk+zCw7eAhTtNrNjztlrJyEQ2NcjIKi
2JXRT8WL4WWJ0UQAujff80zX0mfATvbekzbMvTAYCCskdD6eOYbuW45NUyO0IfwIxuT9HmIB
D9qXNUUfWbn/uDBBDhLYnjUFYYgBGSQJLNs/PsuphXJauV8/S6CKvRaR26vgb5iGJPrArDPg
G4eHnHYhDFta/QDMl/xgwUYuSCPSXFiwkeukkeE6aWzBxZ/U02y0YCPb/nFGM1qwke3wKCMk
LdgsJH+YlpIVPN0BfUGRBl9wZhQTnE82FrLIrVZSRu6BO96CS7wWeykufhuurqD8M8VV34aL
ZQMJrv3jp43REgaCdnghDZKKoWYbmRqrTPxGpqNVpvpGpuNVpv2ntVIHcl/jn6kVZaqvMh3E
w/35nzgGnZ+fR2ECH5flv3zzAvtXcm+SAOIWi2wQL8epAIcLjtvxiHJlNbgQVJHkfMK1ggor
H6HDa0i2ytwVPtOhtIYZmWh9Qol0yIt1yUIrIqxr2m1VTBuURPZ0zanl+aZLnMnEM/1c3eS2
qinNa+1i2G6LSqJX8kkHitBTtStYTW0kVUGNLOwaUqk3UDSxR1ex0afIv4/1Kz3BJ6VNW6xv
5qNO35aVrhBbrri/ma8j9WCxJEOrcuc5fF25JXYzjMWDzXyKWt+va/Jw0B8uBd2Gj8qpDoTB
UI31O9xWzjRjsbGtnFIvIeZWfGpTESBHh9ga92HxKM23pgela0mVFa2jXsSc3BY9H/J1k3x8
tkU6eth2SnWuLyBPgbGkj/fuXcs3YTTRIELDRt6QigOeIgqt4mOJNvK+WLxzZpBEzUyWAr0v
FWlgKZPHUilH3BjmE8w8YvGxQr4DVHETEmTb36kWd441hjxwFEwl2/KLLLWieVuF8ZGx7uvR
80IH5R6j3zzfWQDI77DCBFOMLU8fQWtQZbpusPA9qnghK2JmLFcIV6KpHGJgAAoWZBToYEwd
zEgRsIFCKNnYurM8x2UcEUtLEi7IyGKWLuS2mByV0OTDcdRqhBEChxDRb+dxaN6jVjlb10DC
2SpLsLfQ0mRS2sjURaZimovjSuTHH8lxQk66wnyJtlTZwp9JM2O34oQ21/31/ZSIgRXG8Ufo
A/BAux9wKazng68ZND13YUz4ZivyKZg9re8wOM4JRzVhvjM1fUrRhGy/iE4YOhKsSor/yEco
EeoIa+F5aubYl/Ny4gqSFHJzm9WqRIpayUtrEka9v8GBVixmhnUmzpZo1/Iw+s6Z14MyfuDa
2WiQnm+XNt4po3kXQcJyzJijR9/8/2O/OpcwYJ7XJpKKCrNNwtR8ZM03pj22Jn9xrwHMX72B
5e7MdGvqtuv6FNOLdx1SKK+99ZAGf+7+A8Rp3H/Ye79TJu9J01k8utb0xieAU48PP5rOHHwZ
Mk/JNmqUUgj8G8c9JV3dh8nznrTAxefkw3yM3x+pnIZTM5z5j0hOWS7AaGPi2OTecW9PaRFJ
t8hDi7avX0OWqxPVmfj3umvGbZJlq7gC+Di/Qzpsg0AkpkXfAhu+arbpL1ttW67nV2fmnTmL
5zucARe6b9yASrhSyB7u1JbsgxvLIwvXmbr6nMDjxDVhvRGKdkYenYAYug2BFBB91xqBlQiB
gA8dsgfAcwec9hEKKFhgj6FBmm2AIHMPUw/622VvSC5N23Rh+UL6wWgG8bljGaYNCxwd2scS
7wasN3pEeqYYSrI0UtsBcLqlc0aIafmo2Z3perjHU49SnAizggYrwmwC4rsUzFkgawnEfiSQ
isTM1BKJpEjTBFUVuxedL5r25LZVekMK/ueUok/DosbLYxiPXegiw8ypAxaQJqcC3MG4nUBP
Zbh24+GiTRZTvXazy5LC2EPIBg+JzhLDQ8TQKoVCDWLy1C4c4nNPVAdiqxg2xsakBogV0odV
pfTfEFo9zMIKBVW4FjWh08HnZkeiQDDTF3QfH+cTgyv4XIU0+5zWFIa4Wo3L66ychVmWb0BL
lN6vL49kSFhuFXweKqCSMbQ1qc/RxOKeW/pxQm2m1cg2v1PG2UwDQs1yf3sCj2d4/LZ4/Aa8
OuIBBEcgmIwp4Ax9bxVrYVgP+ga0/RCN3wpttAHtIESrb4O2SbTDEGx/G7BNkjVCsIONYOCd
/gawI5rDLgLiW3PTzcGAOlrFcLDWdhbLrzAJtp17MnOcWwKhxnzwYRZn28KpRUeOu2OpQUv5
0Nl5XIeEWXK8FrixJj4NbHPduyXHmGl7MJCx0GHKwwoF62kFa82bzegYQujj1eEDBO6M/Qb/
+caSIs9Kx6HJGxtNPr9rHOwfcNrYNJyxud5oNAq4puPCRLHU89517CnRZzjD4pwCyoIda7Va
2NC3grcIXMsJPG1p3AQ4pFirMakUtrcMX/FIP8WKmVXQ0QC0g5w7s6DzGL1oc/qsMHY0SfmZ
NQ7ZmjZxnTnTKh7hSZz6S3CWozuJtP9spCXWKIt18GKsFbEOnw1ViLBWxGq8ECsa10msoxdi
Jcd3Eu/4hXirA+A0RuKSSAniMEatdMJfXAi4v21/4kiJX574I/erJ/wU9JmJfp1d2VpN9IvN
0ppkv7Ih26+Q1Ww/P9mHtHU13w8b5ohijaemEtiVvEw/t3I6c2zbsT+6WOlCwg8tgwvdurr9
PVvoQ173LVW4lPGlq4+fApuoKNIzliF5mldYq4o+m4C9TOMG19WwBJh8nNpBzXGnpZj9Vdch
r7sQed2VyIalSGiNK0klRJXbg0+CAtkx/NZX5GupJeLG87/+JahY9u4dEXpYIPS+ECJ+7iui
qhJZIVK335HEFsMCBEXoDSRRrQCp1Gt2hi2pd1khF8MB6ckDkFXqSgNEHsgVaFqM+BOsRG4z
tK6oNK+gTLiQOtLgCxWgLQ162HIbmhZIX1AGUnPYERTSHyp9GbJ71KElqc2OIHXFVg2lYGg9
GeS+FnsghHoF6wVCaPvCcHAFWOSCHq90JHrQQtFRUYBSxOYARkwvfGJgoBoYCG/0QQ7TF5sS
PoifRVBGUL5U0DCQYaniz0MggkrSErrCJehWTBslEm0QG4ZaBnqgOVREvDSIx11EHV6oA2kw
HIjkUpZb0CXQgioq11JTVM9IR1Zjs0HSVyG4P1WhVAAFRgMiquVQlaj9IAUUFWXYH0hyr0Su
5E9gGpAZM8YWNbQcmg3NAHaSlS8oCNqHdkaFfLoSoRwcoEcIzSYFtJM6UKTmIEkHzQ5kJdQ0
Vp/0xMuOdCn2miKSyIj1SVLFEvSgpCIBAGPjnwRoeUjNgP2FK7hIU+q6kedWaO8SqU2E1rWE
aoQc4BaqFLoQFKnD5lXYHYlR8AUGvXfjBLMx5J93Jgx+w7TuYHDqhF5tisZaclBnxzRE0ilD
u4ehCvRxmDnDW062A8tXdk6CSTXirRvuLESHztY4OoTZwvOIcAeDvKnPRzQEV0hXIFyd3z+p
gFWE5e5CZh8BcljbySzwWY1lW35uxa3p2ibknr6eXw8RMJhldxNYFd5XobdlcqoMCHa5NXjd
JbtxEYkY5uD5tQ4eNOVDQsL1kC/GTB/lVsCMN3bytlZgxeMs8jZWRo7jW/Yka12ssnILIdt4
1s6N9whz7jy6uhRuG+Fxm7ZfB6kgs+Q0WOXwWnScXfQg9htmieR8vu6Ui7/TowoN6L2zPJoN
n+juHHw0DQTUNPiODtw0rbgdRGEXl2Zf/UXg3Xy1v/q7BfwkKsJFW6ou4t/FxexX/7+4yi7E
mkjfXUq7bbvOgsEmcU/J7rm7S4rUNqXS1tZJmQTN+mfqYJYO97W9FT1U7vRZkOq117F09Lhr
+EmjRc2GZlta314aJm0ZsA2ahgnJDubCgy9vYdkzx7jVfALOreEjOYcZUeppHbn5T23Ywy+x
Fd1aawe2Qe/K4T6gATFvEsxwVyKxy0X3H3TDMD22zbA8YqPbAfTglmVg1J7AhwzF+B7dzNWw
BGoq8f05MHtUGp4YLaswahNsJPDOkuURUKowwlke3Y5ZHMe3CsI9kwndAqW7CREEHgI+wDLr
bVI6xI3gYoKEoJSAygXVdNAbnMYKiqVE5dtz8j/F4rItPCtqt0vkwwd2iBqR/XFOisv2kkRI
w9w0xmdfpayaN5BzR3qu0bCYUHF5kJujaDGhaYIupe+6YbOyjfWfMcfWzVdIbK/0sXDCZ6mq
7m/F1J1OKAj9McenoTK8JrAONLBfAAtrJazPwFI808a7DJo7x9vQT8GmR89kpk895isYEGgY
QG4PMqni2ygwVBhdiQ2opeA8Wh11rfIl1kEIEdgRCMRU33HzcZIKpCSFMtcPFltosqpyaJz4
7JQ7w4iIe7Cw/nVxMQWpHai9wKNU+MaRsGLK8F7I/4ItX8+S0aTl3QT+2Lm3E8Ln6JPVmMoB
OZSmQ3Ob1V4rdo5XjrfAo1cAEEYbm57xCzz8WotCAqw7lJ81WBbi6q71B/4i9WBhdImrWHrD
qPCUSyYl8nw3MHxycx/vD2uYv5JQwpuFMZ7TLU1WfE6vH+yGLxhUWADK+CYtXbV5Jc89sXC1
LyqRQVftz1DGmZLeEE/M/qSOhscJ4ObU1veWa44xjzF9dj/lLF3f78o97a6OETFYZCkgT4HY
dKtPw/C0slOeC5nYodRwSbIkytocCHSWPRi6Z+hjM9rcJOeg0e+wvtJYPSxDBW25woUYWoEM
iLGQO0sn3WvKtlshaAb2k6At1rUX2IEHZsFxsEVTjHoVPbx2plEtCf7Afd7UNSD06GjShR+4
u0gvP+mzWbQETZz5sOsj9ya+PGBP2f1dehlNd3ElCWtXmMBqDCdxtQH3vGAtijuKuIIBbfUF
JWIzOrSXyATUAadJXfIHwYcL8ZoGFk0zZlYxTg9UE6TB1icbbgiExyw48ZoPhglj5840ICjh
pLR6rnJGTQJmmuKK2zLo4Fy5NhdphSklS774OgHDerjLhkI1+0PWLFIULXoli1jkA+H34btc
Dm8IxaEjChyFc5KMG2dZKuYCBXbFK101Bt1uCtHtomRNKC7Uvc0PGSt31sKDN+bBOOFkj/3o
YKTGOamQt5nBEdtrrru34MqGY9tgdAigkZGSZRlAHjrmbez+K2BVrEEgYgfzkeluxNtfwUvW
HjxZe5gny0r4YOVvrAm+QZPzjg/wLFww4W1xl4Zicjsdj/AI8Ku9u0xW6X0wDUdGmGyPICO9
XTgYxEpnaADcJp7rjwSPXdheD83LfAeGpemaNFVAmnsdBvVptcQ2Z9jtq4x0l60LvLaoyh2R
Zh0sz9RALA0M6Tkzk8oQMeOE9NeObVbucGx7XrLC+OLjnBWk1z7aWW0g/Wr+YeO0zuW+mh8e
8xweJE95EteaLvDWClGiNwhamDRZGAm85X7i+pOg5SHI32cRf59F/H0W8fdZxP/ts4iJjfOc
lvg7CVq7fyloV/TK4/IiZG51dprEV6YbBzFbgqmpcprQaimkiNtL4cdgkR3fHzFnnrmZMckQ
TbU5PPhGDP17C4p4XSikXuzLUFFdQir+aarBl75YSL2QmKGCICcOwquKBfoS4lOixYT5BosQ
lWuxxQPV4VoqaBXFb6wlaHYUJDhaSyCKMO679A0qoDvZKE8dqPSNVPtANdpIdQBUxlqq/tUX
XLyhrYBuvBHtEKjy/ShJ1QCqPN+h/czu6z9UHkts+I3gOccfyxnsN28eS/mA9I2BhxLdMR0V
81y7nBX0zZuH0qu9C9DVb0EoWHRumZdF9C/OHCOA104Yl7jPvQ7EbgO9gX9kaYzU3zuKcr93
Xt7teMrYc3zzH5BK4p6iaRuWCQspiMJjB3pbD3xnrk8tQ5/NHjFDezeHZvCvFL2r4B6AcQPx
3nMQBt9yuUNeSLKcGb7iFgPWSEvuvRvgmzQ0LSPOvZ0iILhuQZTAnuHpi+WDwB4owbY7vYVp
4DvBRcuk2wc6qRkElS0xJXbKNbXm4VW0H4rNfr9E4KvdES5VePqAf+Hih/c1jxI5IVEzSVM1
YjIH0WRtICiX4uD0nMS9xKqc0bfqY4GUz8n8roqnqk5yfwN/o2ULw6oun/Cn68zhi+5uwTdd
WcaAP+T+QQhsJPyLFA57F4mdz/5QHMh9yMNKe0oA1qphl/zFkRTqsvV9uoj+xSMpAnjtkbTE
fe4bNI3Gc96gSV2ne+L+3JZWZFfL/s3et/+lkSyP/mz+ij6eu1kwEBlAgrrm3BFG5YTXDmiS
zebORRyVDQKHR2K+J7l/+62q7p7pefQAas6T/ewn6nR19au6urq6HiBPe3qr6XgxB3Y7o90s
9AwvVQBP5zHFa5RQS6NxpYdMqBpR0Uf+7Chshb+9KBU3TjJhJ5m1rE6SzUS4OUuMecVkPo16
xSR43yyzY9HbzaxrEiJojRt+CGV54N2D2winxBNIRqqsJ3N8ppyxHfxXKMKEzBCmui1ukB98
VUR8w5lxOZgX8sGHlnuuopZGAfjpkh2xAlouUzuyBF9vjRJdMlL3+JBilLjfIpXkDqFa9gjq
MCw8ospqVVZWqrLyWlWLatXiWlXzatX8WlUNtaoRW1WdH/GoeCnflUiXOvuEgShgNyhac2Dq
BnIA/gSUYTn8Q7qb6ywj8A1I0Yhq3xzJrdyZM7Lp4IpUHAS+cPzCUhGu9YIV8mmhJ29ccJnT
A5LX95zTMDtvnJxTb73NsOfcXIT03/Qrf5n33tZYNkKS/NUSG+BS8pIW/Aa+M7zgrdq9s9rp
2Ur9i85DluZh5W7ylpR++mvOnxsfv+Li2fJfdc2/ATNIWvF/6oKHOqdb7sevNh15Fq0qf5LC
BxM4KBu96Wd3OGSV28FEnHsx5hirrG2UClQbD9ED3/F9tU7EmlQ8qje+SUWwZ1VO5OtMjnwE
X6E/q8xNA2BmFMLNrLzBXxj54ESaDbyyP1Hb1og/oYHYh2ZvA666ixDD1SrtPZEZxFJKkjxL
fX1V3iVB/sY7I8rCtKZyMfuwmNwHpDYHINRxXrrscjEY4os4c1GOHLlziiADjHDef/lSSoQ0
C0GPplSs2BMyqxHz48ymfWc4/pLx/kBrNjzMo6A0BR4s/SWA+eMn6lqCj/HCAsyLKyVeZlfl
m2qjtE9WZmqBDsZWbZi1pl+fe4UqzYppWb2q0rCcRfVZGA41pIU/FrN5xF7B5a+hNDVK23jy
qjNwqBSTyaFa7i+EOLy8EZCfthCMPSE2APAicgBlmJSUt7iOWI+BBhqDgg5KH0+8JZVCtFsx
nItL4hrLIvWFW7UpalxkhR2LYlWkAAfMikLfo0eLalgU+qzjedK0KPRJtS1KsPCJMXlhNqpm
cK0lX4G76JimY4Y3ZzKlCZpyhFeDW3bESTOlYjrZ3IOtZO7BtOYeUJLXmXtA2fPwOnoywuPU
RqjbWllnRMAPVhhR7afWFnGk3uN8nhnGgQFIC0mP88Xy/oNVRWvEWdm8z2/e5zfv85v3+f/Y
9/mVtZ56Hz3k3yurXZf44EmWE6OrjbSi1akGtadar8eweUG7UlNFt45VP2E55c7TvQXhhF0L
DyZ+V+Qy22Lq0up9Hlzxm/VxrdVhMzwYEAjDZOJlSNAFtQP4rtzPQA0zReEtNbXmO+yMU7Uu
OszIRcQoejikaBeD8cy5HtyD2HdJTjv8MtQf4J87rJ+Wblee3xVJUYO7ydDFA5JtAyww/tk2
C6qX5uymNxwM3bHXCvc/IvJwvoynV2pjMBC2A//wUHgYDI/rh3lo3QxbGCUY7ufeMH24chsY
v26tNsprN3G1yjiCjRTyK7UivKlWH0l4KGs2sf5AYEXWbGO12YpMV7AVIuNwM8ILi7xXo+gl
DXP2JthpdrKYTsYz2kv+jvR3klcBMU3RNt7pf2JZj4VXbl34eyCC1cIe4HsR/gSRCLnrfPoV
dyxsFuGJeDV28XJPL/DuPch6M/6MNSIULir9eBIA/qqPMcOYVJWABDpjPGgH7EuWpX/50yFL
5ei2jOPIsUNmeH8ZackkoIIAHl/Ljop26Un+GiYWxwBYvUZbC/SuFY2C+Ixjbb1hGWiAfr/u
DYaLqRtUM6FjAiqWHYeWUZ27VDBPATSVCaUuwKXyguKafaHHkv2Fq0J/2gMJlmv45M1VuAPg
RR4H+gvbIx2UoiSUv2eNkAYqTEUpPwpxWtJsioh2l/6hgJgKCSD4TEQt7rEQoB8e3FNgcZSL
KV9lCqfHKeAaq9MofREBrTk4MeFS53hmCPjNIOLChBHDDH38Qu/GizuXe3iQ0A6AM27+wUmG
DnD+rMyRvBTXEvi/x2a9a4FjwoUBmHaYcDIAQXSEI9j5LwNoa+r+bTGYYrivP+Q9ZcDzWMyk
wFFpY+qU09UoWaFWsebKdxFkPRsJuz4YJU4ubCuoxJX10KlL7k89d0dslxYwSO9e32D/4Ans
gPgGIm/n5LyONvkjOOlcOQVwqZotkEqvF8NhoBKcuiAoOyBnOyetc5BuqSpFPoPBjonS6ZFm
Oh2DgDPmu86rfmxW0caq1gGZ2WmeN45B7CUMPW9PjDBXyJD2jsexHntmwYQnMmJ+bPkqF2Tc
fBsj+zxUn4cwXCT0FDWqPPox/hYHwbU2l6Q44V3Ivoa/sq/5ymMV7N4Rzo3Tqbe6KQkFP69H
pHTD1gXEyXmzEoXgDAXkQrxH4yoQS/L5RoBL0YCQE6lsRLewih/R0O3PA4xJ0eNiiqPx3d1i
hNvDleI6P3pw7F5PaCLo8Zf0S8o0KmoqHGjOERInWueRwkjOsg6Qog1f1OzuuVlH6go/genb
MlZty0hsi6ZKtAIVaaz0tJ9m3wTvhr8M+ouWlNyt2TdsMCX2OsX37iMIxiHn//lrQJ44UV7Q
/9oXb5/+C1yAQMUfPql4unkK3B3QwsuhZ6RY4p8vUZZx6IWffqRYHN6aIUFsszM3O/O/fWc6
RsnbnOwFU/tVSK+1Wx95vUzcq+XNVt1s1f+OrcrvRfF7tfzjt+pqmodlMu9mt25263/zbuVV
n17oXUn3uETq3ezNzd78r9+b/xCxd6XHiGS5d7NZN5t1s1mfWO59yFuYsGyF47N/d8WbW6qR
ot2Kq1RpNRpms4oRgu4ovtYW/EQbeKUQjUu7Fi328lM/ilkglj4OzCLPJXw0y7r3Ex4QyH+u
Y6w6Jk9SEb5KlrBR786dMaEZF09R1AcZDc3lYV9nyycpg26wDp+tLeBk87sJhWQis8Ore/xV
4JBI2c708TMrGgVyF01ze8WrexF8Cn75hZXoF88gkWwEAWf2tezKByj+SBuP57fLvuak/vw5
g9/dkcxtJ+MZvbHspmPZNn2ToV+hgwesyp9kfuKBv3qfe4MhOZVcuv0eZv4dX7PtQC1vNvrj
4XCANhmz30fbxCChF8Px3MFF4q4R3hudVWtemHX69l32GjpKQQZhp9RattVpndvASGst4rJx
FFhrHSbXbVgNbWUoa9nvBdshHAj0pyNJBWLCHkHbXmiuZxRWre6ik/T14F5G6ULTuVH/q0j2
g298/V7/ViSzmaHrBXpZA+1X8DNH4pcdMUxDCof0jO3SF3zyxQ6xVBGzl5ZFNLd6oJU7tLW+
dNlrKGeIYTBjPJo1nDKw3JOJ2+OnEWaQ4Ch2l1A4SQr+LJiVM0vkJKTkW89xI/EAbTDJ+AfO
clnMr0qPb027iSZaSIjocj3HJ7DwnEDXyvyFk8hQUuFPV0R0XlvJC5fcZSHeAO6yXMc1JqBu
dq1m5b3TrTUwvWLM8H9BX6EVhx8kEhg8rBmNng9YmYIHDT3YWX/g0EGfgsOeOH+GkeRi2S2X
q2JtP0hQRPNwwXUFUi2/FgYd3z2bJgm5mMDh6kPGNxbl1OPxPOPzrWi5O8uI5KwiULg4HGC+
R+4X2NRoCCLPAy6qeqPgvwMYhSOeSeYLUgr9JTkTTjg++LaaDkYyIPcMjzK8rgC39xKR3gih
lfKbo2wF8oGTA6GiSHYJvIYipgUQHfG6GFBFckQPsderbz6QxM/TDh/6PeAnzfjOQRtwKaar
giGxOGQ2nfGdezm++sruyMKabB553iw42cfcaIDbQYzGoyzM0uiK0vpRZdlx/ueuL1v7lIiL
HKPxoyUnOQ3WgGaU5PXIa7gP95yW05v8FK7d/+FrnGbPke0xJj4/j65Ap23yk4n9JVpYa9HC
ooEBp7UIBBw9fO1jmACcyeIgttBqQATuJJpHdoAXBpjCIOub7f4EXP+nXPkeOSv+TMecwBlv
glWu4dN2wBExtOfIBsHfclS2w/Nex+4kb6OFYqcDA8+EvhFqsdlitjKSH7Rz6LnxBHZUUE7g
sxkJ1w47Ud2WHBXK8G9dGD4Aou0WDcmXYPgF7P/eDXAR3Kuf2cWpyT3NxNzhcc2NcDAoKsqk
tY7pJaSDaRmTxc7wS+/rjLsykTE+r8svE3ByfxoMx2RFJIw8XjJB+DhSOu5eYz7kXE4jvglS
qe22KMggUAYnhvl4DCfH9MYNimpAJOhFh0JDLIWowCwgX5JBzixDK5iWYhv+kPOb4r+8YEYu
XwRoA1MR/7+U99ehx3dkDbkYgub8OFoKFYwnM/XiQ39zl6Zl53FmBbF8GcyVDihyoC4FWgkT
tSfdoZRZILtdby/SX7MPH8VE/D33PeBBJWIGL7P5ZTt96Xa6xFa4HzyGQ/jDTlqeZxYKMUiX
uFHwd2B63DxL6jIoI4vHU15Kssjdu/6tPQIFRAKkqUIByWHGa+n9w8PoDuAcugvjpmr9APIA
FMcdgIpDLk4XtNmm+cGwtyEa5ZGcvYPIAzWSQGmKPeblhX72p5qHjQFePHS44Z867/HJu3E5
fJt1nPhHO5CtF3jIq/AYR7IfE3rIR7xm7KFXxo9O3u2bBAcT+qFqAG+OdXRPoONIGmDyRMnc
pFhG+hrMoh1ckm3vMbn2tLMtPAllnCOKiZv17JGRLuOiJ6GGbj6FA9mdbkIeRfKC/0iXm3jP
Gm0iMNXlJnxKrOeHwnbgn6goyE+rxXQKROXwd4BLnoEn/nlCLYKFmju3aE0kCx3MO3AY1o0C
nxyOxxM2prQdwyH7NOIx76gON6IHevM08YQXqNVxe/3blIoaWHxK6Sy9MWAhF/ZJNS6QHsmO
O5cBDGlPq+VBHvFTguuyYF/AWoiwLPz6EmhQuADwR4Lnz6lSKvQ4MpNvHwhmyIsITgMAZt8x
U8ihWx44ZTRgBS77+bfNRzadjzZ9rGm6uGrTxsNGrR3z3hM3HB6zdsQltWGvxluK9fizd7tG
oUANnYA8lN9MBLqXGvQY/1YV5dEbg2MLhBoS45NnjzDZF8m2cQJAism+5oKsVC5hM1zB5IeE
QP1ahql9SPtXMa7+YfxBg9rCqPgiew5qJgPPZv4dKX4t/iToj+lKDf50t7X17RvTrxWhkWvl
D5WuCFKf4I80qtqP1zt7zybR6UtA6uH8/uxpQgFggMvVxTiCfrgMR9WfXIDjWL1wAIC1cFDM
Hxj5pHAA+eJa4QAeIr554kp9vIBD46x3NxjO0eHGBpnhrDdXsirfirL/DSLLbW9OMhb7wMNX
B11tPkZlQiH0+dLgE0h+awh8G2FsbddobR7Vu3A20WUBJDEdz52f8DMgjaF+iTyj1ktEqnGG
3o6kx9iWdl8kYmGsYZ6aZ8aE3cdWamc8cWHOUujwt0OKdfpH5OlBgP5wPHMBIvgVeSv/mKFn
751wNe62Fw8xvr52EAaOS/eThKGPYSykRrvG/sHOoldl7OXLly8JBtFiD/Hl6Xq4mN0CoMw0
tUWwUHrjzmdygHR9P4yfE3R1wwQx4k+AIidIYG0zfGbEh60PlTo9PH08jIvhSWpMT5CGvX+o
gelPFk4fk7UdRj3WpQ2G1T2L1qYOITd17np9B6mH2vlQwg75ejl/rhiO3uEpZyk+TYwmYttj
pX4g623lBUnXOdXm4RIQ8SHN9IGAeEIdFN5FpAWsxWAHD90eZnhC78Msh5IALpsMoW9f43M9
kcI1l+MRgPDIDZljLMrMveeGCM7lYJ7iVk9k/dSf+WqwybDXD1uIRMO7Y6pUNGPJo8VKH059
JQQ+zyakzIFvfkJTTHYslEgVONlq+MksJv/QViju6BV5Z2SB0seX7jrNYoKocLvPhLuH15I/
V+JjKhUJYa8iwYSghTQZ1xhBReUNGcj0U8LneDYHepaPemWeNXQ86Y+v3A9GnpSpRoYZlJZN
+/93zx4k8wefpEiesLxPNgEiUdsbfMxwjbhE8AdH8Ae39PjDs/OgXv/x0YsjFW6trEap8qAx
9CxPJuZ9Ahk00JtcRqrkvz9TUojRhOMqVzp8DUKVZIZRnyfoEm8omkzx8gO/389TobcfYDUy
WDD+jtHb/Kwch/hZUkGgYjpFxwZVD6w58aXe9CbczvRGvO4C25UNBkEWw8PAR87mJos+7Os+
LRUjNBjkPQVYQDAopnmVIT5/BPsnh4s1OBRgCoBx/GnRLJkYIgTeOHgAYDlwPq50LoapV9rn
cKvqduuWYzWrNbNJ3cF2sOMvXmi7RyOKBcVct6kItJ8Td91KRukhtfI0tSIVi25Iuqr/sF4u
mZBIHeUwFWPwdsUwHSB2seZEHETcnFqAmkrFmC2E+as5cd84A5Cj7+NJHImRmhG0fejRtN8T
jk6QLM6yoFO5r/hO8htSuz1RmQNj/tODuM5wIz3UeTRaTTbpidgFNwuUE2bo4F9hd73BKJVm
s/lXYY8ZeHNCEYUenMRo+xkxFpwa73d35BuAqMLpTv9zSICI511bYn7mwrpPpgBswEUUhuGL
MzILIBqW9j7zsx5PJiZbvKYYACD93aAaA63niKsGBEL+dhrtrMdDQoTU/+yfzzDqD7mPePfa
vkHjJ7RbBo6PH1DOhzmGq5nrxxgNCJ05PFd+/j33c+gkM/jZgtOrHi8wHQo9cFIMdY0WYeCr
L3FcIGel1GYxLKb4DBjxLwPO8CNpkcAN2YI1uKqGsioe8ifnKdyJAzAZhsj0pdtsW7FnGsgD
lRtXpIzVh0i0pQzxT9RwoIPe8/18OurfTVLbN3OUprepjxk5ePk1nVatubdUOZ+2JQZgcqDO
fDzECfNnTyA42k57ZltbPIss52b0kVYhgPO5csBKJUlanjtb4R58O4oBl8jlvgjUwKff+Rhq
/ZQzSsN7sjJQAXypIzhJcHkhITM8Td730ER5l50lsyTrx81TTmjp5EB8nGIUwqjQ+652nrg9
/S6rqyR3wH7iVrABSuZnOKlzNfzx0byk//npucNS3iBWMmGvY18GH2m3y63++ujhu52jW3nD
i32OJ0Owx6EN6h0dD92hiGD1LbpkHwR7s/5GCHVmhZ1A3YFaHm2LszyeVFExizes25vpeIHC
QsOsnDmnduu8DXezhtWskH22ByYCEhOUKFey+S1TWiBF37j8IYDmHvBISyr+5jHK0jNjODI4
t18Wl8GolkMVy/w0hGGRILDNsq+5/ii1fUzatBuhghVvql56YIk2ajyDvUB1qcP7496Np18V
DYemAj2bosnKXW+SijFzC5vWodm/wPe4xwKeBmvl1wIB/uDnAlH/qd8LJNo1zT32ApmmNkpv
LzKe97qAKYyN/f1XGf7OYPeG1+y45/Zvh+4/4h0i2JF/h2ecmEcDvaY/8jSgjWY6uZnjK2pc
CU8XMZ7GlE1dlAZiCrh+N7ZPV+6w91U8FPCAo3zeHLHdUM4AhiREaXRs7I0UC0Hi35J3Iy0O
7txPrjuBdUKeLYzEJ2i0J3LDxvFkfksefcadeMQvzTtppmZ1LedecXlVqBL0VVRQcUXn7+Gf
aKM0L2yzsWt3K7tfevP+7dX4htJTkOUwXGOnc54pEO+wxq5RAvmxPx6JjPYid2fuvlzMMN70
C+rlK8WbsAcsQr6we00A9psx6eP4eUuznjJyuRf4Tw4aSvsoRIhKrzLGbeQHI+ZlRH3nDGl3
iOeiOwYxgUxcOGbVqrjZ6tYqFtt+KxHxkSE690ocbN91637bGwasQeMQ/z7a2aHAyMgnMSbh
8KuveKQom+Mv7lTerb0rGoomjgN06Tip7ZfQpd/nyOkLv49+n6OVMwv9t41zKgu3tpQqueQx
UPMOdEYdSNw4OZbHnaw8seTKJ6sAf/DJKuo/9ckq0QYj8+eNgz0j6Sm+sBd4ipeD89657Zp1
whqt6nndYlWrU7FrFFicCqMcPpwv1UtYOufXHWlkqD/AShn1GEs6x8RBk2M2Rty0FyPlLIhA
GTEHxipnltfR2CMro0ldwJLyWy4/ydiDTBJkD2Omg7EbEEZHiA8Lp3B4A0a413ya9kb/E/44
dz+7fwQ+xizXD5EiNvkbNvkbNvkbNvkb/hPzN2juHFprpATjcL2l+V3fKJbKRnk6769l4vSl
N4m3lSLXnzXNopLT++qM4fH+cR9vC39HjqsxtyOss5591aR3s2aNNfIAxye9SLr3xaY0TrwQ
LlvhJMcB1V4tUjb8tMQcbbkxWqK5VJKd1G5Mug7YdAu0scTbE58NSsoxZSj3U7T/W7RVhivg
yMWNJQyqVr8JHybW8W9RyXChm8ph5EaDNKp46B0qRkzUH7raOfxqyPWvIq8IHDD2+3ordZ9m
qdRk7jqfe8PU3ScHf53cfp2loASOI2CWDt7trLpz3qQoCtU0WeSU0t/wxhZUYl4uZg6FQle6
xP6OymVggWTovbPLZEAYugwwNJehVehRlje8IVLwg54i79BrMgnj9F7iPRrjd+dz3iFMIRdF
9FMHdgyyHOvWjxmI0dOBcD/ihubczhyNnSbuFG76yNlnL5FS+FVTQgAvvxmL/A+XLruFYUKn
yHad8nSCiPWl95Wh/Zk7dX+e8dq9y9l4CPIj3HxHY562DlUHQxHzYUAhOnoyMIfs4dcMCIgc
wWD+83DIEyfyqCzoxzxEbUr/Fq7SSgoZqPySmTx/wGImeo8F3EXgFu84ctgzdzqAAyxoScxb
6bF2rWvy2lTzywBaPUjzp0AeMwZu2W2gDbgdDLcuBtP5ojfEQjlVlAh0BPht92a2lbu/LvJ7
ofIrgnOj5mzlQ+cja9ercD/q5NII0/fB+z44aWYQyEhvbXFFjgdV9qDOQSKcIVSeQ135uK58
XF4PO4CT4FwfzvXhGtkOqcZmrNqqINYCdfDaB772gJEcGZNPhAGaFCoOrX6LcmTyXKhIiMAI
pj2e8UC8111dOUTDDlFHSm5afz5hjwY+GuKjoiMTkLCZG06p+EbaMyBvzTBg9Dz5xEKq4pIa
7cc1euV9VBVzSqNGqSEbvcvOvvJkSQN1JZY27MY1fB3XsBtt+NmL8JNedHYUDeIPXZR/6GL8
wxdh1clXJ115QJNnE2yTC+e4UnW6Lee41kRL0/RWiixOuR3oNb47yw9wGBXTIC4bOXxZDuKo
NQlHpRrE8RMCKyh26e9ffgFE6RhRo1ieF159dfCFEc9b5aTR7OuQDSCsqxx80DxwJx3UZYco
cS00anU+p8FUxl/d3jQDcsNofovRGOGogVsPfkHbspnb99TMs/mYR6/iYXiEqa5o+0Pu/tX1
dZkMVu+LwlAEUcOH8LIF61zzx3yCfbEM2PjIV1Q0QL1e2oL7URAcjG4p8JUExllYCn3JOw9z
tRS0x0FhRpeC7n9MK7Mu4xYunXY5K8Io7+4TEeWy9fU04hSlSZD0TJJ06K3Z7f870LcMTAP1
cBBsfudNZ388+uxy5/keTAoX968XQ5SE7npz9BcYYV4mmi/MUL6AWSHBU/gezkG2vkvBRFB8
L1rS+d3L+Z0DNZB+Da8p4diI93su4erWrexHqaRdEAN5/dEjGp918XapCjIubskR3i/J9XZl
PXEC0H6Kad/V44E6PgLcYTHVrxKqQxW/PpLmLlDmLm6TGESXekRYNWYGeglNc3PXrfDm01YQ
u8UfKkjaX1z3k6AamfoNL5AZcl0dUuA/fN9EyX4xyc7HWd0m7uvb/YJtvfAcB7BxnoN7BeIK
MQUvklvktjgV1yWxeQbTv4lU1jvorytc8xECU1OnypT1Pv41LXT3FM9oaAtE2wlausbEYhTc
7si/kwMxUmZsHjFA6RIAxXRUDAvGLM9fhAsdyXJ5Z1GQmQ8SMboJ3bZR5RC5SwYO0fndBD14
eZ/8AXBsR9GZ4YCOUCRIVYECGdQhHKrAqCOIQuLXAJinIojCekWSnp5RvEjsGHTci+u0ILtX
UUctPAzAY/CcJGiUp2ILB//jBjFdwv3vC6/kjD8x4csirMeJ7MeeMmDqBuP40g4IXvyVQ/QW
NiNmuA9ZiGX4FZff4GcLOA3w0OdGWZTNEZ3tb/CpaIsS5JF+kT/QiBu6hw8uA9fXg74fN9OL
JqzYsjld22x2GrWu8+u5dW55nuG2dZqS9xXPv2BtDMajMeRXw2BbFat2YT18EHoEK45BjyA6
BCCav38n/YWwKJA5SvBJZOVxiQvG9ZOhNJ4eZf6hKBPJ8ulxPnjoiaQbwBlLNe2W3XU6ll0z
6w69ULXqHtVq29RXojh3xvrNGQ9pznhwc/mHNJdXmuM8tKsa6hwP5lkepbJuVXWeoCjZZlil
bgsk4pAEvh7x6zxumXbVti64ozaPlkuwv7B8iQyAPFecqG/xAQ8shSFM3LtLEMBs9/NL9lNf
Rsnd+tn8+YVASA2Ia8a6OCk+JPtz7v6new+1gjZ5hOI3PkLZMH5EzAfsp6uXfhxjxPH6ddH7
/bmxJy4aWvS21bFgIbtm97wTaIKH5OOK/gMm+87U6Zh9Gcz7t96cC/PyPt64cvfGwTPVUYKx
LGuj+JAFuYweEaS5lmq5L+rmY+ouZrdZEI3n49HS6uVo9aBpWkJdIxet/NeueaqvCPfZ3mI4
j1Y7H/GIUNwajpTusv53Eqz9lxRYGV8SjN0R19cZFl6rFbZG3MpyAu3Me/PFzEsnQUucy0cX
OTCimTsFyedugvDCW8Xbcc/pRpr+y/ZgBJLYcOhebR9s9y5nsEO2I5jQCp5dD3uzW/GOrcH6
HJVCepycw+T3So3BMV6q7MY+XOnv86xatYm77O6SApJLZg4PhQuziZ7Z6LL/yy95+PW41epS
hF3bbPhYjXxZYPWCCC3B6iHEiUhC/e7dO9bgwmIoObEfbWDQxxjIsFlIiYACav5TjGmrWPZq
w6y33iqTzDkSQ9M2KMuCfIzmRuRsJYkwdmJyUuMKv5fl7+FRxFct+1WNnK6qohTXTLCnOV42
lAHPN7BkRCssSsCXA+f21GpUrePzU5QbKvDLyYmFaQ/+TrJG8P52WeExB+nC4f8JG/IZNzDN
kYtxiX0j963JGK8N08HNDQXbGsL9XOiHEJZXAPIlB2P2bYsngcEr7xyf2ej5nQ/eqwO0yGvl
ArUoWPaKNUnmLYqKZA1M74szqS248utQ1/ICtDe9C5Yd8nBjfiAwD4GE4mvKUtsyWD2FoVdm
7adcWbgAel/TfG55vKtC/nIwd/qTHN7VDEeyr9T/yuejVYTxL/z8PB7CDhu60hIY5mfqAn9B
q+Hf59vs92dq0OPReHLIdP88SYWX/HD1eyCYw/fQC4bWvWhX+JXgK+5MXETHI1e+4V4Ppui2
B9dj9BCG+6rMxTEaU4hdCgTKk4ZT7AA0U6R4oZfuNSo3yeQI10zJ/TQY82juAwBAd6Lg+/gX
92dK+D6Z4LJijDqOHt/ISQ3qR8glZ0/pG8opg1vZQwuEmudNAmqQTfmVcR8XxO9iziSf2NnZ
CfdRMgbyuw1ilw68vdGgn9quEN9FdiJq+rNE0P6xLVsL9RXXszenQ7TM6Tcls1KlQw1zbf4c
+uhQpGLscCqELqvMVzpeEQebeTEU+rLQsBWm9gBb8zE9pzt97xdhNpNo2q2rtJ7duQ4Lmonn
s4YB/zPj1UFu76BYWtv6PAk5t0EvoHdXMX9QfBVrgw4sBtp/gT/ICp09qb0fe1J7P/YAez+2
krH3WtbeIs8Sk1zMcVoVqw7Hb4VLqmeOA4XiiTW28FlWFnuFlU6OEiMw9dVa97akr83/S0WN
DNKemLKsMlOQqJVp6zF/ZF59uCI78s6K5iI5DYy89SGM8ahNvELUxhDsA7esH1vx6XZqTLzG
/MFe7qC4H79BMyXYnhlvc64WqZGt5+LHfqBjBFs1VmNkdAneDer4VvBuwIk0cgaxOiNXzBi5
VzSf34FUJWFvgjhtgjj92CBOarCLyHgZN5H7TwvytNKY/1uDQD3Dgg8hZvVxncBQbN3AUDto
i5EQGApuEGyNwFBMuT14zYOkz2E3kaH+DSNDbeJCbeJC/YvGhWJrchIWGxeKcXHQ2Aeh+kXe
KGcosglL3BkMhgLXttWC/WSTg/3ISxEAAt5QUCb20KBM7OFBmWg6CoWMUUBFwL7UBOBSMi8Q
ElsWCOnZ04RC8meH0RVbEwiJPSYQEksOhKTcCeI1lexRgZDw1hFzcGsCIT3mnrxKwKIw8ANv
ykpUoae7KgdDFS2/Kxs5vCzDv/K2HLpTLguMs+at+ccExiH1EtP6ekZKuEMpqQoKmVewg0sZ
I0/jDxgiiknVhKQhBrJ2SJrsKpFk4mBAftBKl1uJoWu24qLUwHZ6ojg1LDlOzWM24yoxTsLA
D9yMwUAkxaxRxEAkBfi/HNk3K2/GSHSTZZuRNFeGorpaOYAH0wXw+NF6Kk0AD/YUATyw7zgv
ZWJSZdyrOC/PmN4VlQlVUNjfKBzfDr4Nx7lo3Dv6bsR+vx2EP6NfNiWmPvT1t0/jAMvonvsY
V1bO3HPI3kh9VxYCykquimwdV0W2FXin33gq/qt5KqLGYXVPRbZkUdhTeyqyhMXgVLzP2WJR
7P+ndiaEzbaKMyEXQp/AmZDfpUq0NQv0mMi52krugXhb/ZHuUyyIZoet6T7F1nUPZOKOGnUP
pHkqGjRPJcOfp1U9zVadqmVj/HFTFedpJubjkZ5mNHdl2jh5Qx6cott/plgKnmFipX0uHPlJ
xwf3P+8653P1iAuKr8M4ilFqsNXdcHC8S91wcDgFw8DhFAolyQe+8z2pu3I+oXEMSzCOYUuN
Y6j3+XKmAL3fK2aK8iHtGXti641ScRfmgRsTZrm7TIykGgO1itQcU+0R4QDjsAUtMPL5g0K8
BYaMr8s5wos/w/8oh47vcB3Ih+6GTCzQ1+au98kV5pUHIv2le4Wx1qCWQi9HXxGJ8qGQVywL
A6ClIgKLZisonEG7C7gDfWVDkGGHIkraTG3Cete27FqDInwptevj3hVPX0l0wGaLCVJdoHMU
xZD653+5sOxOrdVUv76BzwrmBnfjgs4PXfLDk/3l0GbFsp12rWI6JSMwTg+iYkILjrW3F1+M
E+FUWsdmvRsPULUqaHQMvUxAYF2UikY+lwixXwLpIQGidmHHl561nbrZsey/Wpou1o4bztuW
/aZtVuMBoLqpqcub7lpl41U+AcLsAo6E8oZ52jxvOChrJELVu2ZCecfSjSCoIlwFxjldCaoS
uzsisdkVAg2YKAe2W7V6vJd7VdTQERQWX5WSCl/FFzatitPqtG3rvb7cMk/rVnxxq167sLrd
mtN4pVuczmnNqbXzGgIQpZredWrH77uW0zk27u/vnU6rogFr1hy7AYzRQVvKWJCu2Tw2K073
OJfPa+ZJBdnXgLQ6Z7Vj07GPu++K+7peX9Qq3ZbtNNqVQu5dPMhvZguYRxvIpG7GEYn9tmM1
nFOrCQyx4nTatWa9VXkTIAgO8q5ydmpWq45ZP23Zte5ZIw5brWMqNCacHeg+rXy2cQlz9Jge
KYNpVf7qvDXbDvC9Ths4pPK92QK6PrNsYOBQrBZYb50uMHanEjlBHPPcCO9ryYVB5NJwZuxk
zPkTKS9p9guW2wUtP8Hi7rvC/jvN6mH5hV00ksrtYiEJvV18l9x6MbF1ey+x8/ZeMWlq7FJi
7aZ1YVY1rJSql5Mbp4tsQjkRWhyd8lJ0SwnQCZHkse4IhsIzs+MACzuxupUzHV6Eqdc7FYUs
/c/VTqUaaRKL3h4n4eu8b1YUcUKarJLMHiXYoIlK7GDgjnzSgM1j197Ftdu0uoFeYgrrptmw
NIcnbPv4Aktb0qhoCjrH55pWzlrddv1ccyC2K41KTYNSVIzwbNni+85FrR3kGMedqoNRWq0O
MI5KpaupV+nWVaGv0rJh2usnAVT8q4lBTpOWIgIQLBZYAyIxusy2zW70e6uQj35sBj76aPnn
cHcatY7mDGwHOb+UcLnnVNft347Gw/HNV8aDyc1YqtGtpoNECl/icLR7U3Qn45HrAtK337hp
o5NrbO3h4oa0VW104Am4cIVwNNtx9Y/JMkBkbQ/WOK6/AQn6wjnRyHVYXmn/6uh4mSyv1ICc
koCwkapZ2S9puJqEOW9YseevLK+3Wu3gqoqC5nHCEBAAtZ9aALxCdGJXfzGcD7J87uTCsZRt
1qq0IvWLRpgCYgmg6c7xSk9hD6O3NhAC3lgqtfMPTqNhBgcL3Ktea9J4dLJm96RW71qaq0pM
mSg5b9ZUIboW5pO1ttM4r3fhJtfR3XLajlm9MJsVq+rYsOXj2wEooFK1JfrgVM8q7XCD+B2d
59raBhHCho2jnQwAqiWWntoasRywaggK58axKprzBw404F6tNzXtkdK+0EjPb866XV2jZldD
vRd1s+mUc3nj1zi6Y0HirLU1ApHZNetv4hCYk8nQnfeGGv4Bt++m7tp7bNeqp5rZfZfX3Pfr
ZvtYU1LXsG1cjircoWxNPyz4qevjW5i8GGIN4D4BkicYPcjZW+cEbpsVHpkgbh5/HXdkHP7r
3mDK/rZwF+4A427/OYSrg290CTyEzd3ZPLZm+00XrjtxVbtwB5jcjkdfWSf27DmDGYpd/a65
W6tau42Txq5dr8efXACQzHkBgFJhazaEBDuLHXWn0qnFt0slCfMUZNoqv4XJggYxBL0iepp2
BS2RYskcyrQkVD1vNDQ3/+NWk0LGx5Plr+dmvfabjvK65xoGQ9Hru2bsSW9Je6qUkUNnC7hG
NC4H83Ro8BxHmMWfme32+4Zl1jWM7bx5ammYEOK8AKkcruwFEN2WAnUaCXtZwNhmRdeVs3ZY
VafuAn7RVuRn+Kq7ypmNatkwDJwQDUDVbHetCgoI9klNd1h0z+u6Y6ZqFd9peF311NZsiWpj
38jFKoYps7wRut3Jj0671tIQjVa3eQIL3tScCk0QiqyGRh3UtPJv9MqislHYr2imBMu6LU1P
O7XOvq6vVrtW0Q4E6LOK0odmheq6C2O3UtgrG5oluqiZjn1Wa2qwvq01cY875aKmU3g4d0xz
/1VBA0AU20Jpb9l+hnH7e9mnz4rVrGk2U7Wef6MnB12HOuVCWacqPzPRIFSz5O+tOpyBJzXN
PNtlo6TRCXbe7Jfrunrd2mmrWYjbC4rRqXopVMIGBbeJWqJRhaggGpZxUq1qJuCs1m5ritpt
zV7ohBmHWN63g6lL4dKRblMYXuG2dzftXQ3GIQJAArLNamjjy3N//MkdMRuvHbHnWjdJ7NFQ
lV3RbvoOHCGh80wOpzfihijXvUgn3pqxMot515u7iymzcdDxEgCQo3botSlcR1OD0fW0N3Wv
0hrRxQ7dWWXlTrUJNS55gsFQHSyLqzOaLOYYfM/VtNVsx+tBqAAEJExhA2JQp2JbVtN5dwQn
QHEJ0PujV6Wyr+297U17/TmF+ohZ7It4XQ8F1VJV016UrU6rbgU2kCiy3nXhiA4JqUGQJtTu
msCQ7ZBSsNWAcYSlTZ+2iBNG9CB+9feVuqkVJKu105rV1qnfsFSz6VvvTAcTC9XruvOTQDoN
TNukgah1dJvifbOCl/bk0obulgpise7iY9c6MJ9lDWKe3ammOdo7mu+2bnywnPWqrVE7iFVH
hb+he6WSIO90D0NQkn8l4HQqiv2y0+6+V9+j/a9AXOfN7lF+r6SyiIuKJOXYTZuvaHZrvhIH
34BtFQQ8Pu/QrtTRTbhI1P7rGFjLoP8ptEf5Nj81G5ZOGRhlMwTlulciHcxN784ldwqqsGqt
P+L782utkss7cNvQjK/WbtSADTerdR3fF0beld70KsL3u5WzaktzPepU7vE18lQr0oLo7rQb
wP80G+dCq/Czu/GvyviWBmXBN+NuXbNz7cK+7m0MLlL1WvgeJAZ/Mu9NXO7veD0cTyZfGX6Q
l9Wr6eAzpklU5+lEP/3mqe7WYcc3jg5N/FALL/R5S/f0bwLDPuk4Jxquy4uL2nLbqsGeTkJQ
TSo8SSg8Syg7tpIKo2VSMn7XLUCRak9wHDzC4G+HwnVpxEOzq202qUsVINf4LnUb7UCHCDCo
K+209kulnBb3XxPabdSAgWpLL94lVG12k9amrZ1jfH5yQkMAoUYLD2Xtbidc49fmu2JC+3ar
kVAKy5zXFuKzmbbwvHqiL4u2+Cyok6IN2InbgJVW1dQipqyHDeu331qaKWqedIJUix8uCirV
YBS6ZmgO4e94Ke68abfVd140naiG/3YuikHxsHGsp5VKW1v2G9Cvdubavel8QN5NXUzsF5w0
yqOJtl/e00MsY+9UWx0fNtLnZl3X6Xpsl+hN6M69GvQ0gnatarUibzQCpoOxk4LwHZBbYnWf
553jeOkEC2Lgj4cLdz4ez2/jax3Xz63f4uq9IW9Idtvrf5KKZY8rtTooZLZroauADaIWmqMk
cMI3p1WNKr9hnqJJzvuO/auOKcFRLP1V4npcH1zCve6rkjJZHehv9dox7JmTuqlT2hNE1YpA
PMwCljtixfmPxYGtbQMr6j2VEaxEp1rBFg/28geFXKIVbK68sYLdWMFurGB/oBVsPEzI5C9i
/KohiY2168ba9YHWrhv71o196z/YvlUtJTKLGJNys1Y90rB9q1KkWrfGWq9ujFpJbtoYtW6M
WjdGrf80o9bQ52ZI87ixZPWLN5as4dKNJatAv7Fk1eHeWLJuLFk3lqwbS9Z/riWrv/7CbFVT
ujFZ3ZisBslhY7IadzXfmKx68s3GZHVjsroxWVVANiarG5PVjclqSGuxMVmN6drGZFWZp43J
qid2b0xWSRjemKxuTFaVso3J6sZkNcyU/g1MVnnak93+ZJGdTMeXbmzOg1i4FY1WoxU9M9Oc
wYz9g7xxUCysmOkgGV8+j5kT8rmDfCnWbHWfkhzAvyKIbx8DJnuGMQfqF27NEvjEbVAOMPO1
+hEtUA54dHLvKzfECdQuvqmE/rbgA/aqxIOMl4xcJp8TofK3OMKtrX729Xx4iXnEMLLz1O1d
Of2cMxhdj1MY6ztlUGrB/XSa/YWBIHfAiuVDqugnGKMm23at6tQabdlhnncq+xqmUeT18Udz
KAsHs57DLWqPGLc3BZhaB66ZFx6MePEFCLv4xmnBEce++cAn7XP1z0L+pG2zbzx3FeWt9YrQ
4IYj3d3hicp32PFgztCMbkSCJg6ayXTrMpIy77GsMBhdYZoId4Z5LbG4Wz8GhjCDWcEXA5gg
jNo+cGcvRQ1ZEVqh/wx29Bp/Csiv7K+AQQLJ/3ICCJBGgHblvKy/akreNRZZtbIg0LhFK9Oa
sRXW7AGMYdIfZK/uekvYgge1HlPwqoktvJfNl1i+cGC8CmciWoUlhLHxrCd7B0buIBfPEPL5
TJnSaYscWjzbzdSdH4q8ijfXGDz89KTtmN1Wo4Z5rmTkdGjNuVzM2A7+c8QwDRvmCMsGw77D
zD8LRYIPRKOFVcc2vvFG4BsP8T4IIGCUZez2C5zTmEEMm2LfvjH6kH0NQ3YwFQj7k5pcIY0E
EUbNHhDVW07udNxfRgQEsiYFUB2xYKWssYd+DIW9g73i+suvopJrn98/yEVR4doXXyHXhX/F
YfCBG1iWirmPW9v0czsjP/PTAL433c+9q55fwM8ErEC/bGNavg8+J6WCfV4ga6CRJX7Hn/5n
OB7gI25YVnzTx+/yPyre84v3qPgBKzjTpjSKwKy3hrNQriGjzHL7B3AS70W9R5YtYhiX2MHF
g1w0GRLt4FKREg3AD6PAF5JSZjmT6xHsyvZJ0zlvpyrts/cdzJqeeu7ADkj7aeO2/Ox43ot+
s9a1q3QAL9u6UPmtSwoojPGPAfzx0OEZ4dilOxx/oQ98bGw25vIbniV+FoDFjBxQMKEPIqGf
RomSLwwRAeq1ROq6/8/esXanbWQ/418xddsEAsaAIXHsdc9iByec2NgFu2mbzdGRhcBaC4mV
RGzvbve3733M6C0MaZx0H5w2YM3M1TzuvXNfM7fOCZrpQztNfKiNu2YswUMs472Sz2WUPOd4
OIatkjpxbU2vMckqvXeCCVaFs5hdwQ57C4WYvVH/qFs29rHOyc5KM/1OvZPTI7R3OjVYqGq7
3ao1JTnNdDvQOdFCOZ6lL5UVI3GsYWOLt71sIsI9KCqlkqOFsLdi0k5RnZXer71erwfTlfow
XbcXR+v1wlipF7FaIY7k9yI6RRKDwmkSND24y45mixJpUBLM+X1ZZqnTOCFnMj3n0Yk26v/a
oywdQCVYHROEgnSUaJT8K2q0DtM71W/MCdopcrmNKl2R0anqkebSEY1dFFNyNpdCFpeBgsyt
vdd+sbfTyk/Kttuh9EPw1eS0pydnsA8BHyvtIcHvcnajxoYIU2A+uKKgMo5KpeqByMkeFy1y
7Gfd3aiOLg9f9YcrtEt1IMUvk71XksouJ6eBieOsgQW11FirEnlDPpd44/lRf0NQvPYxKPsj
5JSJPoPURnIiOhFgZEKOTDLVdNW1MG422za2vPZN0RYbla+IdVGDCO9eigbIxoB6a4jHOXBk
mpMdELVyMe/FC5KO8Evy81A1yVWJMwoxtvBmL2400/N0wJGdZlmmuyqBhmZcm5rUjkgVKjdb
lLGKY75BQ8LV1PpHlL3qJW7XnI3reZNThj5XKnz6wwnd1+olsTPNcX3u1mThGD5ztwRiZQ46
hSP0DU6isyaDglWxXX08my2WIExYY3WUCZuECSVxsRt7lP5xLaRJQ1JoAxJ6J2uwIbShnKYv
dmKrwznLxmVligul6QqqMDmlJBhXBJb+pRDEsNPBVN8FIPi8RGU5CD7pVdQLtuBIEFtFvSCc
qLBUVlxeNFDCQdLT7LEGE6157bu7BuEeoFb7RgvsqxC1PkV1gzVcvg3GKqyOYNnNEJjSc9zG
Wllmsgy/svshc6V2nj2QGAAly63iF8v67tVft77LQS3cp5jlgUA9lT9gNmO/pvbC5D9zwDAO
ln43GF7/9cBUc8C8XB9MTm84FWIhGJC4TH8VQKPDppob/6rJYPgHNo1+ERD+8y9knkKTn2He
yWcGbA38M+cdkjrXHPPG1rI18AESMOzMHGdYe6p2sndkK86r3MnWVeeWebqgkjVvtaija5Kx
6kzxThHWWJ2QwyZR6uHnZJAH5X0NsTYHUkjKsO3kk3KrWWs2MEGgyq2oklv6kXRQKrc6z59h
AFmFVdY71rPh6VvrULiOkElPSFXHZKGgZ6dSWUph41a/J5A1MU4+AG1ItpNmvSsud+do2TPg
S6a2V2m8dX+2DdhGtSjD98YWGgpJEgi4remgtjwG0AUlB419TrNLuYrfUQ5r3biRuVk/6rZF
eShRPZ971gxdRNRedl5lAQSxus58cedFrdnGlJ67+B2ZMsvPUJypcC5AELbejnqvm2wHUaIL
d4n2nET2TCmKHQhlveYHLMVtkUFSiWsgo+000a7dhK2wqERgTsSTlhzIHFMnw1vKjYMD+bsi
XR4swgmeIpUEEvMVoy/sTGyOKP13NCckR35vj9/WBOqL9OdOS1zdB8DNMDskQJHSYTmGXNi3
JuZlhTmw8UHBwOS4tlTH9nOGmDdCnldRHvUq0isgB9YsGlgPW1icQTQ+wnq9vknrg2v5CVIm
MEngucghR4UEHKuzOv+INQoNuKgYgz6LTGQtDpKFFUqbaMDPFwd2SEkh7FcJWksaKH6D/gXq
wtucflweEr/W/47RW3Uh3l2b7FFCvw36TTnv6xhwBneUWwt9RfjDqwmdAmjNvy0AQwkaGvmk
74mao3nOcph5kCPMv3YX9ph8sa5hLDyq0cYUpcK4N2yTUzAvUNMFcFgIL9dF4OmOb+tLYOzE
YFDadCSXOjCLqSNEZ0Oc9LrHZUzTbZvaR9Nogjh5g9JlHTQcxH7H1QOZ2LZdewnz1n6JVjvi
Fva4dNOoiUb5Brf20rdiCm3MjzBP88CU5c2a2E2Uu+OxLD6/6GnDHiru4qYhbppkWlom81ZL
vm2X/m56bk3wv83f9yzMa3tVauIXr9+GaO6VHHf+FftjAtkjYr7cK9HnW8FLRBj0cYY2XkPA
2k9NXpsOr82L5v/X5gutTW/wKodspAGuTQ7C5k7omv/vWQ2ce1Hitfjaa7A6fbzcoRXZaf9/
Rb4sVTQbRBbrCx8P2ETDGmsJHil7pnQ5Ps9z9D8gduRaRpu7RTFEmEz7hajiFwcN/CMuOZPO
8YDoTFFLaNuRImRFiZSw0XsgZmiYzRxlgrqK8/jmIGbHFE+eoAsRVekH6ytUyXunKN2i4oH9
Q98fRhCUz0+19ttk2a3lAQI26GFgzuZklOKwl4NsD1TUyxaKuQ+hCoeJ+9uYpn7bNz1Lt+N4
klu8BEly68t1bW21OgLRY2ev0Vl+Q+IyMOyyQSwrlkl30TZdpW8plZZKvwl0bZD1u8RE5SF6
+BqdJvMW8wB0Emdqm/tZn3OuWw6VCdATCcdANvUDzfL+VsZs8ObWD/CzJrkoSLAjPhU0HF6e
X9QouMQ3pZ61OoTRm/7wx1qMSaj4rU2eoc2aeAI1NDqy8T6C8oGNmYjd/L4K0Qs/MfQ56kjl
o+45hlFq3Ven/UEFa7AktNOhmezsvIxmEtvlv0gCnnimmRnKsr49PBE561RbbZXULCXWIJqz
2GrEavJcJ2tFs87Vlg4onGA55Wxw6XQaOJ3wvRtNZ/j6fKz8n0FHqY1vHqHehVeUAutGyQPN
MAxShJMiNlfmbI4ZbB8Rw61bTpbFJIpX4GyJ+tHe1xaN5h5ufw9E0S4Hg5wNXUR77azmzpE2
HY606aARHtFnbMJu4Fk0veLp6N5/6zqOaQRi9Hbr5e7dHSm6+LsDv19bU/3KCqLD4N2xPsdA
zok+s+x7Fev9NH2a+ru4Yzf5xkPP1ceGOxMX1tR1djIg5JnrBAR0UIv3YvO7FDqr0ItNwMDN
+02x5WbrRCivan3YRzHVIQfQleva4qkQpz9t0enraKTpfsWOZ1NLHJVqHWt/jufbGnmttEY4
qHVgNXNhNT8JVisXVisf1sSiCIWZ6SxQ1E+uwPn5kYZnq/q9UXpa1yGzrKMrr3RFIsu6uNqi
1SJ/eTYMrZDGcuM9lpFYs8EGrYbyun+L04ZmzRvhemMgFl/eaym+RVRO+BpiM04uidlH/tsM
rjN+iW5/iNcGtcmJSkEdludCl/GBpkIjilpoR6NPaITXfEI7kW6ne2Not85KxweWIy5mqqy4
5ok261+sXQxq1dWXl2q3XuxQrI8yX2aHvCVe0cvIKiiX/WdhKnYjj81C0yN3fu9Z0+tAlI8q
AvrREqd6APVuxSuQbmfiT7Mxfv9ZRnnVgZn+gC2p9SHM1hi9LKiJw0ueN+TBTjHx3Nle0Rs8
/co0r/881W1AfQRZt+wQ5sW15QtQRqaePkPLK0prwncnwa3umfvi3l0IQ3dg9x0Dk/esqwXw
edg0+HIpgjBzAVfu8eHCQYrAzsE2MvOVVfb14DK8XvN8cWVbhjixDNORBlcd3o9P/Wtp8IUm
x9iLkeyFOMazTWSI3RemhbMqcGXx8FaLQMgXSag1tBaX9QA778kL8CrQ43th60HUtl44B9FQ
x+qow7U7RwMIAIVx3lq2La5MNBlPFnaNYEBt8a5/8QavnOwOfhHvusNhd3Dxyz7UDq7dhTSA
0LGJ2dy2ADSMzdOd4B66TyBOe8OjN9Cme9g/6V/8gqM47l8MeqOROD4biq6go2ZHlyfdoTi/
HJ6fjXp1kE9NsswQhOKZJsycoY9qbAa6ZfvR6H+BJZbmbYou9UzDBKQaCx305vn9qqtIijaO
FWpH07mPe4vjBjVB+is6CzPrS+2jNa6JvmPUa6LzUlyAegsbyLmtG6jBjhYIYmenUROHrh9g
1dOuEI1Ws9kEPQ+YtLgcdcORbaOkrLyEwLIXd9usa6OXMFOksCKvjO+izy3iSOLcoiUv8w1A
9tySeeDBYHOLJoYT5L/JcpHF5BcpITm/H7Z+lV8ABODk9x3AOW7+u+YFXbCK+pY/BYZFz7Ml
wEz5ZGR+x5AzLCn3b64Wk0mqCJm57Hf8MTqVQTh2536qPhZY6eHjQ7Tz5FWeTwMK1c6W8IH5
8NVxnS5xEWDOxE003UtPdmwkYch5VLwZ37GuN7Fs+9nn+mxUPxuozw1LAHdXgf1zne+nUFH2
MjmF3EMln5ta015q665jdP8feIyf6wMME7FCvEIjNx+Oxm1D3ftL1z3xXBFvXdBhBiXlDn/W
frzsXVKY74l2NtAuuqO3EiDotqAhOoHPDWVgSe/ni2FXw1wAI7HTip6/G3bPZXwAqjBvTnoD
URUYj9qG/5vPo5qHl8fHvaF2enEp6ODVLFhADWwf1ekPQInsXo562uXgFLqkdU9OSqXGHYh6
LzCMeXlNPNFPlZtNWZnpNDbq5HizwFIvpU9evaM3vaO32mH/YlQq5XVleRvqaNEI4hwBlmMU
YFYYgdELtMhj07B1T3q6cYV8roBRJzG2oaEJRgNByCnL0BygEE3eMPIMjebL2sF+PV+znXGN
XiYNVjWvYQ3rx1pnqmhYAAOKg5xCKT1+oCsUrIMNkAFQyKc20w2NWLlfRrSki3TCGs5ihq03
qqHjAa3VKAXNqKE+Hnsaajvvn3/Y3/g05itIUHpj2nOU+OXi+SAXLXwSVH1rzE46xdAc+54l
oU/jBPGpSEwi+wA1ZAjlRIgSRe1sVP+xUS3hGUgadCDwJ9sK0a+iTnT6CzvY5xNbXd9fzDAM
Qxr4QA2AjRpGALyaY3cwjgiL+VUUvcMQxAEd++QOAaPy8SyyE5TxRGZNcIDZk6gD5NmZmTPf
DMoMoCYaXI+KZERQ2LvfPnGp8j6sLOWiNxaV5EdyPlbmqIYvkMGVZ/qdNVvMOC4FZ2cBWFmJ
bVtkzcOdy/HkzhXK+HxP0x48JHkQxfBwiwvvz0NaSFxlSxSykAK6+jigqyKfJa8SlZwtAobe
EIs5sBN/YRim79fEVq8/+Kl7wk8noHVIWJ/lU8ymlrMN+CbOgQPBOhJfFUlz6NczNTvaHGgJ
UHKfzvYRsPirsFQ8Iw4Qq5igCcUeEgWkLE1sferj4/TLAKlpO8M/sTwOXxxIX2O5sDsVkQYI
oFJdVL1C+okVyYrcXRzy3HI0vMQfjf94MKz8JFkdy2o8EuZ/HIon51b8IF52ZLx9+OxP4nmb
fErVEsNfOOoNQHcB6KgPvCQM3JP4hY+IUEuhEHCgVldyGD7iOYItiOyYQOBbuI/JWwwk/tfZ
EEDafehrGP4sQG946pNqG50URSoAqqzzExAxQbOGtjrMpu9bGGc4RiT02GaALeh9BJsuBWEa
Mcc1MV6YEq6rDqqiHWZh26A0X1vGtZiRPQcJKIKk+D/3YFtOPKw56AbewnGQN8N0qInGwvwt
mSqRayweANkbDvn+BP5sfu/viWM9AN0f1D8X9xaBrefRFaAU2BlrQmvh6DNmrPkdIFnikzuA
rVd9/28ROq+NblH86+PuB94dyBf+TdFmcAy444ttwN0J/QLMpGvdcSp0jN0PdMtJ7AOhBvM5
94GQ2w+2u4/AzEk8yJmVMssNGNMgOXY+b8frPfJEO4rp3P9SjP78rYQ/vwnolpEYWP9GQ/FG
PAO+wizzj8v/kWoxAYCGh39BaNIAtcogMKUoRq4R3r5xrzjOXHcso0x02yOKRUsqgpJgAJMN
29Q9/I20myXYEvwHDBBjtjOvQ9lTgwn0YTspKuWwl47q0DbxaVHdJaVWSpgsU+KpWfKN6sCb
0bwsw9XxBIOny2hxeBsvjJQ24e9yTAGtil34P6bTRnzvG6haid8mg9NTOKJqlStIzKkbM5j6
AG80QdQFhbM36B6e9CKnfbI69lsznEAhEevEMUW6LZXpWFf35fx0aTbU3ABz2OWofTkDOJbs
e56IfzXuXshJzunHkwOqsF9QXD0QfNXOb8lhLCbaPPAI3QnfUcyf6XMZ7oFICJO19QOSNfP9
kmL6q4w4aoJ5uF6ddrXj4dkpp2moJCeU2T/9hjllouW5kOxJVsBZK6cpD0lFAqpgFBj26uxt
OFkPbHhMOFIWwa0OeD7eup1DL3Hc+k2iq4bnODwQ2uB3TbRCugrp7iFSZumJpZP+BN9ORiAQ
T8zZnBwXYvT2sIaXaMAWhJfXEdZgKFrUaW6uT3F3snCrYi8M1hZJ6WUZmR8cCJAjw0i7bFV6
u4a7NtdVbChzqgMndniXHEnehCI9TLCnzUZjNjINSQTJF+Nb3UVQN+/mFsw2IMhfrcnEgl9V
UX7zKzC5ZoPBgTLMfUyLGxJEJZ8txIeFIXy0ghiJ+oDdjQKJQsY3ZBEmdAYoij79SXs37F/0
yvGYgZCxsOlq2HtdDm0cUsTKMzQp9FKmJpKVHl1akhN06+nzuekVyU4XhJryVj9E0VvMgbyY
R0IUylSIEQhTKgKhfczy1UGTMRtVAI3p4Drdd6YgKFyq8U6ilAhEX7zxjA+XgAwPQMog82Mv
0C0INCSlfnQQBpX6f4KwViSlJVejnNR3/1Cy21cRu1JAswRON/3lSb9S/OWpqOw/OnXxAazQ
dAmqahFpXc7Do5Gn3SMhayuzFF8Jzoq2KiIj6n8ClhepJNnJKTA0rWZbSuPd71Y/vqrKUGg0
j9vJ1V1DBW9VMyv3ZJK56c/nlf34KxbSsI7mXAW+VjQUBTSknseiHVRwgG5n7thcbtilsB3y
EVi+sXB9xH3PnC5sHfaqO6EA/NHJJEMfsQn4vYRRTlWpJEhFyo30iOw1oIz0j4/xJnBMtipF
wBAs9oudmSAZT5ViUYSEiEuqToRT0wSMJW0rfKtq6Ma8HFA2S9W3y7PLEaWpY7FJROLa1+ru
k7D1vxJencoK3X/0/Ug3DHMeaBPdD+Y6GmILNiOfLyTQF2jmDejqWRVzJO/8I4OsLhCSQFDy
xlgMcruSoUzjMUNhhH3qS8FxyjsXu6Q+E2GirJhwr+hxQOTMM3EpyCvGPYXnV2bUSazDp9KT
RI7HyFL+GMecwob20Xw0h8zSIJYCb01qZYtcNqG+jh9ZZ+wH8uDTM/hZLFq6LFtCHdpLYowD
n7hzHxmKG7iGa6OOrpEjEeMVtOsAfjEP0vrnSqdU7geljkloLvEhdd6rOzx/M3zFuQ/R/8Gl
qdGqy2OLAaf1V7mVo4WgS7Aw0YqCBpwQk3XqrLWEyPe9XyEF101quEm7dhQh8Lg74woipdwd
E84ZoEJoqWRIxvWBK/y5aeBZkGvdG1OsaHBNFzZwPCPQydh18HoOQ8drAqIpQV+Nfavfs1qG
FANCargTL3zafD+XKvbfReRpAk4taqHPlTUYksCYUhGQxcSIFtmyRQqQsNBDCF/VakVaL6qU
+wnrkPtrMkF7k1Qw3rwjnBBEdmzUSMiM760PKEaUk3EZIEdQR95baBr8kNa6cgR8FFq+pDMo
YM0QNp5CKsHE7mNeZja+kTnB4QCBmRXQlgWophs35udyAdW/rCQZzcJyQTLfynfxs5qWrH3v
URcPVZ9iNx6GIoa2JYNXUSdLo7pLn2SN6/Qq1BlAP3iKEfPe3PWJj8ECUrSebqPDg7kJzY+O
F5tEi8tPawwEzV1UN2JSJBjdQqOphZHqliO7w4FhHNotkYa5Jrw4jEJioxfQZaD6nmMMCNEr
g4zygmOoRwaDxJCSGLfVG5wNTjEz8ERZ02qigX9JDviYrI6u/osr248QPFJoGmswq+Q/SLlW
Ac9l4q/o73InSYWpEh5l/4aJJRY7MTiDaQxhohxk4g3S8R7io31Vjv7+VDk+CstxC9b4/us7
4D6ZqqogbBDG4qWqhs+jVye3mDToZGmyFebUMUA+0mxA5ZyGUk/ledgmmULdHn5xR3Zj5Kq0
sbB4F3KkFLCoIOzArcxSxwVQv4Xxe7/ux2CR6VizaeaVDf5CWfTxkuWwstRvD0A7QxV3eDkY
9AevK2E5BhfSFCgzIj2NYqHg8ZP8KKn9BwT3Ur7kukyKj11p/aCZVYbjZT1njWU4zd5KjtGR
9nMUEBif6P6mhPglMPQDAzuAHxr1ep1XdLnRC+UGaXaVUvcNRz6WZbcKaLpSo/wOuBn1TiIC
XP4yqQHc4PmrzFywb4jLlCCSJWTy7RXMZvJlOLeRIvHAaMIRRAZA9K8lTBUZc4L0VhMikmkj
DaC5GoBmIYDWagBaIYCMO7A3HLKc0Ocb/njv4a0ozyGYvzapZVxS86FVfNX7Kab3PZIBN2+e
kgZciUEpLyURVpwmC8KtK5WQlfZhj4rojtMjRPGEuJXmBF5FzVHIjwkRKgpBWo5ThuFsoLUy
Fie1gc4HDDhI2cpjODE4u+gf9RgtCB2+H7PkExdnvm+07vaK/lFxaCHy1ETCPpfsT+NDysb9
vpl50vqQ03AnU62dedL58EVVFpQWkmcqYx5UJejeYvgl1nSKhFw6ryMbEiipzMeEXF0Kr0rr
r8UL8T4+yxDDu+2LO2oPyrXhWXPM14HaH8YgOCrE3FfOWt5JQF7uD39UGrfsmQRCvctIrhlV
fpkJPkd5d0PBFeRYx3XooZRt2czxWT4U0J8WZ4uOckR6FV2XSvdyfKnQua/il/2kcOjyk3IO
+5L8S12eInsXv0JFzWJDwwtRBpenohpxiJS6EWjqkhWyf5bjd7WIf9LFK93Tf7f3ru1pJEmi
8Gf8K6p7322DLcmALr61excBkhlLQgvIl+npUw+CksSaW1NgS7vd57e/GZe8VlZRkmW35znD
7rTtqorIyMzIyIjIyIjTo2bYqZ002sclY8/Cvxox2UzRDxhH498L64L9ITi5H8Pc4Epgw0zw
ttROBWH/PpRCjjUI62jP8WIaJxtImxgC3prTBsH2qmYEDVvdMAKmZGCwsjd9u7lKSySpUgOW
CEsv/mRxkN6ojO17/6z7Qepgx+2GmKZ6iDe0oHj4yweJ2ON0nElx7d75ocvczkK+88Wt3Mdx
97K+C6vtajC/uoHjqFDGdSQuEX3vguAJXybovA/+Cyw41k284VSdZr3Zettkm67ePj4Wa9UT
VRXQ9cCLi3JZK0F1CNXDfcUK6E5Ecq0J5KJYLbvNgALTckE23/eaCaIDg86zKRa8E+MhA2vF
ttp7j9lSdJ6mPKSmxJylhpxZ7QvGwpYxQQsshhVu+XiJ6pZDxl2+DTkAo0nqRkvlCKux5mhq
sF8Y+4AKtM/E0K1z8JDy2lHz3njPrfhmOpCeA/8XMnrONvz5bToY2uK4cLPMC3adeAwMio8C
7w1Zov74SyUavdTZYWnpWJhWO26tpGlPD5VNHzo3vMvxXfQ4ptYzNUsr/tWHf2mGumc4kPh9
BvAj09Ui4BvNbl3ym8OlAg406lDo3X3ZspbZ3uucMta2ssfx5PZVTs9KCM1WtGw3qAN5nnYp
Vd3nTHO8WOj96pCh3qBqIZQj1I3UxF1jKHZQpHT3Q+pZydGMDHVMEZXtuVGRfuvItp04OeZJ
C4fGajK5UWlsFtEcEqzwURLoCsHy2pgZiuSS6HCAE846VE8zuJM/cFbW2plJrpeOuV7Ei+Oo
P8VQcg6ND+AQ+AILU2xiUp7JKl5CL2UWAwzhOL+BaN5FikD0ramOu6ayYtVprXpX3SJ11XUy
V93im6y6Reqq69zHqlt88aqTgft3WHVrWoKURIB5vhB68WwVj2+MoexxkHcMpR+8LXEbg1GI
hoVxFb3si0hMLE4jwMVwOvOTtaJAf/ppJLhtOYNNyaNh0Hf8qbPWvlQ2LW4hmxLcrPhG8pwh
eRaZkidjfW0Eld3tvQ0l8TaSIo/uonCRcKLX3f3X9tWAhWsnr14FF31h81Ka5+QtOHZUZV7n
oSUNNz6VwEMvJF1FJi3SEyWuLX6lJuK5W4aeWL+KBh+DI0NfFnsAqNFSRhAaTJwdT0YYRai9
FRW4P2QYc3r5F83HwU/CuKmqOzl0SxkOD+n8S3vD1510md4EiQXOFdPR/CHUuQQWj5WdHu2N
65n3si8L9P5yA3oDE3z/s1jHQkVaax33OrWT7nGrdzfzGPPIsQodK50Anwp9HmL4hhgOhstG
MLb9KUYdwYDKHZvWf7oWDhfQGOJnv7ZdUmjgq8ePjev33k1AYP0VvvxNXgkEew+PiPB+6RoY
ZPYMq2FzE7/4k3leHaH5TYwf5LEe7ZRyl7M8a1OYVO1Qp3SRm0K5ktVx8MG/D39Ue+SPpv/d
lnR6I80YcuS7L9xWzV0152a6fi/1bJ9/rpUji+9DjqCYhppi3780+ZbeNhQcHa84mev840Mt
TzrZ8iTLSPBIkk5CkhRySJHFHaTIYp0UWaRKEa8cWWTIkVSNW6UFuGDVu0Mm9Rbo9TTE8VKo
QD+agOLRSigso6ky+DYDwd8zGTM3SRMxrpBZ3FnIJJTXnEImqTTmETILr5D5ahHaS6j/lHaG
izdg8QR3MJ7Fa6IUuYhb7JzU4ttFNI7gAi0c5HL0DoYfXs3Gw9g6mjUPb+HfEhKQtjr/tZV9
GJt9D0qetaYfwN7X+av3+DUtI9633Qe+Z9l/iwPX9ORG9D7juA+O6xrN+ziuw6ZynNdhKKWV
ZO9WKRP/xSCKsjRT0uEI24aTE5+unXkMacilkRpXp9I/oq9hFKOT8fs+sTv+eud1iWa+ybGc
ajVp2n+93VIGNafvmeQ3VPcw5GV4x4wS/+ON8fcV1PdCnklGG0EuiU17m4tniJam0bplBJHi
m8k90WoiJSrJvFL0dWOQ9BBKeWHmx9pIZnX95naSN5dXSiZHIOjg7KQuWLMXdnu13lmX+d2g
xQ2ZFD3laPfvV9QWZKC+LyyUKNf5BymoHfMDRkNPqE6aQdBbQFmEOCKnDa8XVDeti3uMOM3n
b/mxjZuUT3hxYppG0Ecpk+CGmMLLYLTcMvIQeV07Yi1leYZ+1pPx8TyMr4BT4K8lQdVCbC/g
jHwcVNb7QNcM0v4KApvMqRaE9RY3qI3P1OUvHDfbcuJENyuhc//gi4jyDtlpXyAEo2aAjuJN
qu5AIZlQlusKjtSneuwwS5p1qRVZhFwzC5w4TnCWbO4O2UafqAQkSrxezNz4/81NqMwezD5P
Id8m5YIfw/1vOv7zJ1rrJROt4Y1+GEt+f9DqdHt0LPaHfHZU40ccMeBJy4Z5y8Z0syaZ78xJ
dKa8cFbCM4VjQ+Uv67V19jITsTd9Ge/Br3QCa1h1mdnLpGe/KGFpmMTItDuU4NV+wUmpgA98
zoDA9ipadxZpKrMTeqYvRWSvB8bhhqBant/hNX8uZytz/QmYLchuhlVKllg8rIAns5dTuFg8
uoSPxv0bsEhhvwXdneM5gVgst6f53y86fn6V6XlFufCALrvihLPD65Lv05EzBLOFrCCChcnZ
4m8Psz9Tp14R1LOHy4aYiw2vHDIGGvEYD8/Zwh4y9idZ0spZg2jMiGEZkK2Oezte/lOzC1MN
p/V0G0BJBjqffmyvDf2aySPBQVenACMpDzrnmmEzepK8egw4b5ZXnAXpEgA6v27SV6q2k64/
CtXwM2xWcooof8XCqNODEy6TLT2ku5msdS5nCMupL6AkGFYVErKvM1tR1qYJ5svgtaBzISdU
z3XapHW5U+mgk/61gJKpy3U0MRMvxFowicRUBmLCRpNlNCwlNVJ9ORSzGaqh+LqKKVPI/J52
qd3SGkU3/3LF1J9k1kYiOUeuKxWwsl4/zb4oKO8vYytwFzCEoEHRqt2A6OvVcIHDYjwdzfGh
+MMi+GoDSye3GrB7TeZiZGawMmeLcDQslgz4BWVnebRYevtCaUBemoku/omVbc6LW9zcJKaT
myScKhguC5zn7KSkr2SGVU5NKlX1dccBLhPJbde7HWwFJ7NlRDl1B7MVJH6gukRxsENP6506
v+FsuyT8F47wN56rPSOhY71cx6eFJG+q66qc5zdhjZYCn0r1knrM22iL80IaJdSkFcNF4Ej5
fELq5/loiadI7Q5FeIMyxJji1WTSX9zAJ7AJQKkzlPC8YOGKcsxJQkCrjuztmgNpiF2LroKr
jYKfVGxXQpXtGKpsCVLXKqicIPJ70AwTKvZPWncMu2fHx7XOB8l4xgzb9oLqFSeATeL0UfaA
I57SO1W4RaeYRGnrhgvB5mLfGi2LnMLen9PXtuA6kjuYN2I4W8S6jnhbfT6OfnSg3CN0+7Vj
xlH6XztZc9a4yz7pcUdGlAuO0VknilQKWti2dDBoBOXILNubO2bKFljc7PcSittorKttLZyx
4EgsaGMOST/ABZS0oTaDHe4rmUSU3omke/bCB5FvrG65E5W0baV5Tbzc/AVk+0wstFc58kIJ
sPkVZawuWFsFb20lNI+pmeCx4sxAmpSQrpr7VbDxPCqungH8T4AKEMA9//8TOI81QBBjehvx
QoyAsAv1IISvwXXKjaDyXHT2z5JMqMd3+X+9kkfEdI9sCQe8YN9TNmZJYnFV2XNJLP1a/o03
mMRXi+XmLx+jmy3I3CU+09/AFuZHVsmHrJKNLM5LWbwYrKUszksZInMo+wFeroDordl5PBtH
Kg2A+HHSMv0J8Te+m2IdRDiugEVrSINfSVX6bQsmD/e38Gq0lCuZJlAyDfKq2Pyud3YNDNDH
HyTrQzoxGCgI33tWViKOv5tGwjYOR3GIt+eLmlLJ2cza+N35bLVw4HEAl8tx8Iswf1W/MeIC
dkeyUE4h14SMz3Q37orsl94b5Az84HFFWisO07WpLjFNNgq0JEX/wFT0QW/+An7rkI4hbUS8
0iGxx8+v1HgwFCao14NkF7nTz3dKJWNYSNSBLMRUV6+sQT6t1d+You6lAyWz29lQrkCzXmrp
ppGN5oIlBgtwD4Ri4uzvxXQan9IlJ/sL5qpYsMJABjzLAaWRsZ+5d59MzCaLOqiCIJUVNS+6
bQXBVd9ux9haZsbaA16zu+Uh3cmFY4t62tWQ/czruPTDgGH9T/yei99Iox3TrwhbHg7NouGP
G/bXgU0NPTO0A/j9qf7mlSSOLLGeasHCLhItXDRavH82GWWsY0NjUGN9N96eXm0t+p8dGM82
qxy3sNS+0vr4gtEUSku0MMaSXW6La61nmUPMf/7pKHyWeKQwLG3YFJSi51rh4dVL65UyxdUL
/CiP4gQy4r50IPxQ4ANjCOU9lrsUeivUrm+aH+kJRI82cFGILkJaa+psxTusOHwyRlZVALSt
25df2Q0oAxRwv/oy35tbk0/wBWR1Q+UOPW8UQAVmrg54Qvff51F8r5kik041q5uZqV6JIyy3
lUyJgLk8w+h6+Zc728iZRu5yqY7kOeRVB13pIU3/xL4pdfCCtTLo3KWsT0gS0wiW+36rVxYW
t/jjGalS7OCKKLMae1zADM7pzZLyRBfbSTGIoWW1A88TuSRGcGnAW2/HOJ/wGcx8lMOlc8xT
OGEYC4ksxD1UnVpe9adw6dmMa4QTKQnbw8yv4sVnrDHo4IGI+zI5iHRZEgmKJ+fq6AW9UfGg
L/62eHLZR3c/CbcNxg04JCz6p0BEMF0Uxfn5agb5ryGHjiTwSXJsDRrVwCbdB0kHm94MvKik
zarXW1mNtzviDdBSJzS+kXGA4FwKicnlGNER5JUaOXlc6Olkxg1tGfZsKXGkwKHHBc7p31sk
dN/saxIgR5JU6gTD5bvcwVvXA+vYK0OqqO2NBvFrb2tGBhu1NR1TISgZY8avla/ocnSZqF8Y
J3ZEyCKzif/lyS3CUoD45JIbAxWOhvk2z4du4kAL0yK6jMUfm4Fs6KtmwvXkwjXGEnOQYgwr
V0XEXqpgqTm4/uFSAvz3jhV3ECPuiNtVe+eFhbeR3Izlevwmu/F3ujnS5tcBb65mcBo0eTQW
64uVxogyhcdvw06z1ggbtV4tf1yoCs2wkeLWptIsupMlt8ncTeqAUhZsDgFg0aW0ZeS9wHBQ
usp61R/OPou5xcQt9vCwE3dtiTO7v6+MpCxoKYRiALov3Q9J5fB/DL3EwyDqTEYDOutLjgbs
FDH2GaRRX286o+wLmndmg4GQQ2JlR9ejpSo2jNn0pjL0Crf5Fd7GELKzaXLerD8WGhO8mUQQ
bzuKJ07FPYcPwR1YLqlTRGce6a1Vq8CMFSPyKGMR5uW/GA2SQdALJk7P+PlNIPSQ6ezzOBqq
eoGwQ30Sljcekmmi7xA1jZz+f63u+FcMdvIH6iQA3T3OmtSG/5s0WGgdpGnB8kraxYUuWYrU
G5FMSv2ZzChn9zSACgekycmAoLa05qD8wcOlqnbH1qV1TphunmGAQ7IPXIpRHvcYSq6V4xuN
Tna8BueR2N6jDR0EDpeJ5htKUxX0CfKU2kWnxVw6W3xKBbChIAIk+hSG7AQuTUjoURwLC0Ms
gAGpz/IUTWdtkIdP8Y3guAmkAlkuZmOVVg9qvmDcO9fbvog+q7DtRUQ3zviAVfWUAkmXrJ1T
4JggTzTJJ1kQVSNBVYVAiYKDerhYDQffqCA1N1168DLYP+txJyQKuLsHCu5oIroKqi6laUdD
ADhCYHuiihNSR1ax7oVWadNidrUZDuLAvJkfmBfq1WfsPced1h8F90tGAK0ZGyu9NMAWbnSs
7a3x7Xq4ip6KRTQU6ASDdq736YoDSSyQpp3rTkReaLbyaDgsdWM5W/bHoTqflNYG7O/Xsp4m
IxbjbKM7XYxmi9HSMX691ILlWyXLt6IHwGn8sT6oTg9RwuXKxUb/JFJZHFAZU81zzqErBhIY
AYMbkOgWSkrAxozZUhmPcVVDhhLCUgLhhWtVViZfXkWetBU6QCFP+VIjqRtcEjSank2dTeW+
SplahUwLtCAwrYa/RO5G8NPy93AErslRX2Z3nvQXwp69KraOj5uNVq3XDPdflwyNIju3mmRz
Qz34k/Sm09cf7Iszw/UOlcoe8VVV7dm2Pm0nYeQx9+YD8Y33nVKDrM8NkhEYvzY7iB2JkCFD
svODGMpMFwNMgQH1XuKOx5a6VnA5mw1VbdjZBaGQ+YTUYiNnC1iRhm9mI+CSsLg7CsV4SkWD
AANuNoPZZEL3Xzdp7cU2Wawc6o2TAofmszgesef3Eqs0QwoMKa0idnHx2iIUVIoENlW64DuK
N3hz5UxMxljArsKiYIOgBb4rLDxyQ5WYIGJacLPW4FJWaq48IGKLUOJNO+tffvV7XqoihfJD
0AYQJ90KetM2ot/u06Gf3iLel5dt3q8zgm+ppvq2vYOV9CxoDx/8/nWPVVPGfrkUp/pX89FR
jdbZcGUU5O0ow8y63C9ogmdiUIntxBaxuubI8gR/szfsW1TnhVkOsSO+XmFCBk+RKJnn//jt
JsIElfKTShn/Vw6aUrw3sNPsjLUjy0zZVX6QTFWN6Vm9VeidO12kMZqVn4imvbKz7ZalU9go
1pdOUyWNpsp90lS5FU3VNJqq90lT1UPTN6mBMBCW+XQ1/ydfT+hRdhaU3TNzTWHFJLXTD2cB
Kjc/CO3jIZ1O9cWUTWaf8PSZwPWdGvo3sYBn7cIk8ifg/ir6qSGN7bjdODtqhkdiUZ90m8Uf
D0+PkAn4ee2s97rdKf7Y6Z9H0VXw5kroPzcbkDOzfxG8nl1cCN2KvBPH/aWYjc9B46q/mJgo
IAC40zrttdonxR+VhKBpxMOL4/7iUyS0I+b4H4mwe2K0R8Br94bqvnEFeEwZR8IaBKNysZS+
kfHsczCOxLDIgWLXBjoq7SOeLdAIvuM+3tcP9akH96mu6h+fryEfivV3OLrsw1ma4lbt+ErM
jBIvBp+/MA7A6F4anMmDD1esvIE5u7XTFtaISG2aqiHq9tloSlBY1xQyxwBqhuOCsZVS0J5H
VJYwDoqjrWhLepdHyw26dQgH6lBAKFoOHpa2CK5aChpgcF4A3QYY2Ccb6kaaCdHsD66SNFJb
sR7NYfBp1A8sHZbgSXNkZNhhGQwlb79gFmKVmpjr9gppMqG/C0vqM8iUPnedxwRVfridigY0
XAaBa4BgyoF/RI2NsjsKhe5qDmSLzw6iPpxtxi+oHmWhsElTkViq4lm7K5oaRnMxQNFUGLqc
hZkOFGTNNcISyDq2MqUF5UWzKu2w2QsuIemQHQhq0VSWOCA4Atvf0tRFNEzAgJCKDe87Ynkf
9q8J4d2/hMRhazqkGFfer+yPwUmHzAsmM1myZn8ET9NwRlnLymBacJdJBGJaP0XTEThpP/dv
FHFd9NimsJWaPKAqH8hQ8bQJojkdpsBCG8TEDAF4/GRSAGNAdLP8HVYetlNxAbOdRxBLAliQ
Yad8axQgmziSQZ8u0YKPWzDxhdh0g0andhyc96cfY/a5Myd34TkxlRy/eC6M2ljhBBcYIwRI
Xn1Wp0+RWn6hLiPay8v8/gByIcjvZ8AjZ1OsFkmqgKwdiSUcLCySKmXO0j+VWMKRf6GXX0tm
/aW386t+HBlSAf8NLp453AFgq96C4H0zXcYwBWe4UAwJIkahv6B8Gjw4xliAp4YukcVSRM/B
dQ0PoV6XzPCmpKtBEbsst8xO0vql3vSnNwTXu37SuRYztxx9gtUmPrjqj9Hlddzal9EvLN9A
RIB6h2eeOOFcOANEJ7ivBoMZ9QZc1jGGMC36k2hJGYwYieI6ZLY0NjP5iwDJ3OO86VZv6b1X
/K2XexynRTg8ws+SekJ2rWK67CeFnvIKLWfcQU/hS5uKmDphUAGIZ5LpGE6NnT4egsNYdN9f
U0ao6/TRYAbAwzUxKeSQGqyElHSHBHyakCoHKrCCgASCJ4RE9L6PTfCCAv/li+C0f6Mqu0PA
2pQSB4AYGV1OMa4LD/1i4/CbNYyEqHqiBsDmT6SRJhwTBBC8uXR4mmzflLwspZZVBDqCCtsV
wyI7Y/EUZSpILPn5IhKTwNF1tliHSdWzIJcPD1MLQ5BilhSaZOzJMJNyMYqyq1bR6E/9Bbmp
oXF1OG/2RO4oL9RqkGediwijGQeYceCJykfAwwu8NYQjSQpSkJG061QkcK6upqMLzAlEzyj/
JJwo6ZEx1B1zfMWOay0iWIHGQgKZd9GfjMaj/oIwTqMRjD+juBYAOP7mmlKBYbGiV3YSYsec
1UeLCnUTCkU8v0Ft6toAxxLe9EwpueQJhpGSfnoSJ9h5rIw9HMHqZ1kQdN85Dn2en4d8QvzQ
HBZsjDzIsXQgy5Pk/qf+aIz7tsIHTCja3QoOOEFZoRBd91EZgQys1wHfxucDcUSO2UawBZ2F
U4kCRkK1xjktybwfc9fUhGH+MXMHktq5uevgjtNTNGzkJcJDAlW8k8ylyDBzCsEUGAc2TMFD
mJWHgdIAUgfZGANsWRaZ5vQkqLmzAJGzTqPuHe8NXkssqs/NA25enULPw94J+QkSCr48t8/B
AaXZQ6KUDQ1NLh034M5AvUVJ2vPSQhU3LXD2vCEtEyElxjfykXeYYQLkBEXq1EseRV4E8hKx
CmrmThlUqk7w5OB0bAUnwhZYiHdjpJmOx6Cu7BSkIOsTxELMZEzGjBPZYssWSm4F7/Q/TMw/
a9kxDFWX4q43DzHueguy49rsQXkBEoOH2yMPD6ySCR66i6cqxkXtbgavsKZBidOCyWgI6Y4E
UHclGEEmJICcvJ8gogb2ePtAEAgyZAh3F88PaacYU5AK99wUSjJohyWY5GhmOPhwSadUEccE
iblMpC6jXVpGNMn9h6/Na4H/QgthN+UFmTlMr8Feep8ESb7BKi/JH9Z8sE7tYoMkgYqUMIHV
/ubK2S5kGdOzJ/ejlnKHIbeLwZ5DhunzEVqfKAN4PaCyx1NxLqhWHMjr3FEzAZZsVpaRq1jr
k4RmS44dttAxphpUTr0pL3kQF+quBQblS2OJR1pOUOYUgDvFNDNjh/s5yEqeYkulFsH6OidC
fwocg0ZZktlxmVHiIGA4wgCbFWpjpjzRWeAuxURO5SzjTIBkAVc6+OC1zOldJ7ZyXTjGlDx0
54IMs4eQJIJlAJjo8vtYZ/w0qXLkmtBxxkPqlZbe/XEMHwpOGRLXLBejgWPTyeStUi2OtRUE
iclNPQV7jMWwmN3slU+n/tE0XslM6kZK0UIBLMXzyLlPYrOfthVIn1GC0+Cg/Xat0wiOah/a
Zz1DYHLcOd5j2Tyfic5tBcHJLPjv1QR8FMNR/1JYKqjGRbDl9Bc3BlIIweyc1I4CjPY5qNWb
yplJv1OfTes3ZzUb46lESTELNkXjJ+XKxUzYYZ8BH84f5LCCmfJp3aYnVZ0Imz+0220DgC42
bLmQsj7kr3u/FRTkMLoYTTmlq1mqPAFN9r/TrsczgDI+BRpCjGCxesADfuUHj4eTvkWBBkfR
ya9SgKOFmK5QemtMYHqlHDkJeCtEwOq5WOb9JUqModR1jdhl+zaIXEzB/fxc33rCSdlHRhPi
XExuX0hA6ldsshKyGR+0vq0dnTUN/A2GSpvcFDQcz6ywWWh4dnNgg/n0UCaxASfY85VA0Oy0
akeAotdpHykcFjm+eTd2K2NUtY80ue2pm51sZNL2JCVxwga17XJtffJWKHPUFMjtZezYLKt1
Dizmp/HOKBxcfSwU6qdnoFN/GoE3v1c/pVi8eDUh5c5sDfcehuerjIVki/Yuw59zolHP55Ym
Lf3vxg08hpBKDO0bvJkY+pGSzPf7e4KZ9dXBCZ2jiSck+ugB5B0gQUIdF7JyMeMrJfQd5T+i
vK4yOFklTCsF/xB03zY8TUFDeBoQZTbVaHW/UlvFSvDzzwHelvX2TgbWFhccz78RWG3fsnpO
omWJNkmA7PPXpqD4LHhskEF0CH2srMmpn3U6YeegER42e8V5CJo6XiKm0S/aj14F81Bt/4Pl
YszlV9Qn4e9WXxXyrhf5WmRw+c4Es5CfdZsNg3IwOx3KjUdplKtPHMoV8q6DXOBOodtARXRr
IETtDEvvS8Z8uWbMe7cZ8+Utx7z3JWO+XDPmPc+YZ1GePeo6TFw2ctQ6eROenYa91nFTqNiF
AsSzlY0Fcfr6Q7h/1v2gvqAP4BMUn3CwMDakK5zBKEe/eTWv0QjroMObUUM6GvLqJoRqGVIV
1lo1hobL6HPMnWWEuxsRfRaqyzRUMsRGa854AmgRzEjPZ0JDULAr0qFTCNQ3X1Qs6eCqL7TD
QTgdnQt7h7owm8N2RzSsGZbwXCiu85uiFZsaL2Sld+vxMF7SYyP6bYTuY9AsQHGwrwjcdxQJ
xPNYVlCwGbTsswLnAJoDSBDSDh+xo0dkVmPr1MMO3sME2xhABLYsH3oYiCqloM7HpD5wdaDD
URaWicfJkOFDjRB+1KJ2Lct31RJc7KGky6qWFN7r+n01EmsQnObky9JB/4FoYyK0IsFvSwPV
dkmeiaOCsuZgXEV92AeXBr6dEl60nKKxh4n70CsScdiL9pcu8YyBvsBbd1O4aTk1UO2Wgi6s
HH3aCo4r+ZYO5OpApukbDdQ5sfb7mKOI+jH5FGLKTq5RogJJxoz0jeAjtqIF0TZ/Sf1eHRUh
o7VOTs96BmfYZnfhkSNQ5VcZmBmxkIo25m6k3fek3+J3nWbvrGMy+cmMuOc+A8/w9yQpT7SL
wgmdd3clGfuc2F4Mb8CrpCH5cg2M9AG8SjUeKWJaeiaKYbgPH5w0WrWTUipy00PwKsWSpNtU
FuqjVq8nFM77wE4ZY2FQ94+OQYU9aYfdd7VTTgcLD3vqob7Y9W/kOW9PUQY4FMGlGLP/qiY9
9+AHI1A5hXLb+fEq3Uam6wR+LFJXDqV9xJca/V8v/V/7vkevMRmEkAsn4ArYXtzL1G8fJKpt
+QnTxbaslYCeMRJ0eQC1epGjrfuMGVc/a6Ml6bnJN86Sm6wRALBun9Ui+pbBBeY+u2Xu+T36
VEDU+ay4od0Gp3wdSbnfKaSM/PLmNqt8yDryADz+2gPxkMNWiuScwUmiqV0aJeADG+sFuUaA
PgPArBnPvS0ZG7vVOwTVfmwzWtZwc+G4nd8EnxejJZ+92ITIQKmHsQNJ0Wry+p4OrFC6QRY1
qC7YzcrHD2NJwe3ao+vAHG3GXjBICLeM5hx5ZCtV5FLpT0lPiu2ec/RfkptG6DB95GoSGFKr
PyZesVgAw4SkhDRZhVQOo23Lo28qmEU4CEtjH2YYeYNR0KExZnMQw5S+vQqSiD2GS7c3ZiEN
MzwhVUNBSSuPrBAVaH0cHbOaGzwiqIl0UsCvrNXYthlyWU61BuM7DANfJeVznmVdfC54jUCv
fW9d2RNmZw3DRjC4R+z6gqnqvc4p/JXOGom58darSaQPte2leJmW6USoHuABaZ5I5yBsA+Fp
rxOWiyb1nPXErC38U4qLQRUX/tWk4bdSqZTSTdgFOg1/NxdrurnI183OPXfTrKH86yK1m8Mh
LgwVDKRWnYxCZeHLUl49pbzpT0yFhB0MYaZmYTga/N/Isz53KnyHOobU38rIlWOq66ZX1RjO
LL2fKVmL2kiLc8sW2LJY25Cj/N6qJVud1k11mz1AhKmg7tgiShP+EqHIHe+fQePUU05j+syZ
psrteqvNHk0GeyOQjM51Fses98ivpcA1PDQZKq+RzgrkrCQrvYTtR/SlmOArpik5Jh6oxFWm
1SHjb8Se9010fUM4BJuOb6wrg5ZgYtRtBHWa79P9+ajTj0LJMDsqwNZfUrZA+J1aoQiPCugI
VWrvHDtSKNS0gOSgl4QmU+jaRATybgpU2DP0VI576UMimYS/tmToar2ZisRY8TiRJFYxnHOo
jLNwziYdzahw8qT2TZ025s6Q4X4uOL7nRzTUrPc4ZccG4VVCy4GnY+Jv/CudH2DkyM5vdHQY
/KEe7VKND0RlfFnGL6s75qcVfFbZK6lymPJNNYl3Gx+Vs6S54Imw1mh0wqP2O0ekUCfSi14r
0Netw9c+2CtD7g4G0VxYvnDlIVZRcpIZvbu3I27UUG0EtXq9iUmFqH2r8PS3FCHZ4mNliw9a
HikyxEZD90ticxUJ7W9xI/21Z9aCu1Axo48KHDwjmBDWOh2XUDFI8KODV5/wgX1oX+dRjQMa
fTUlQ1gVEtIqIa5SDnAKBdkDoFJKL0x6TB+gCxxNCbEU6aCHGiiL1SG+F5sPFGeBq+2RK1YN
mWePqvjuCYHEpiSMYruEoztvgAgHeitIii801CBwjrICYFEGuA6KvVf2HvdAX5bCKGWs2/JN
bbv7PHfzSEIeONj3E/JweT4OZxcXgg0Tr0BNUK9IWhzNBjLk2+Z1WgYoLhRZIDDL1xdCy1CP
UGbpJuEL/fkTOL55FOy8pGyxfE2Rv6TyrVab53C0RPaVolRg1Aj/nXE1kTj+wLhp1j8HNlUX
Iul0txCLLwZXQZHHEzNw4ClWp/m3Zl1LtxcyNRhm9uyjHI1JkGJ9uv4y0KteUt6oJQesYMxP
SgZa3vssKd+oQXK4XrMTnp206lCMrYfxJfu1bpO/D2zhHzw2pltaeFbrP+GUlZscR/LI4AH1
vdpyiC9vR1M2SRsmq1JOq3Oh6H6klnESnC1GTkKXbkEmp8AY+IvRGPNDfcfj/weNf+V7GX9n
Bjjk8oXHXjCrhHwzi8E53xDbPi/G8RgnGC5fq725vhF0j+u46baP5elw5rHBIfg1FrOVUMTp
oDdy2SgOiiwHBXK+manvR/9EGWcN5Vy9K8nNn84GiBvFbl/O2NfJEWvu7HZ8B+/veDCrd5Ip
BEqmOVA1rUCOFOl22ev/jgZ0ses7Ot41D7X8ITCGIxQ+CzH8XtvXyCZ6Mu2Npdi8DocHZ70S
yQfQ44oGFjzxM9FCHfPydd1+9viV2M6+ynrVjZQ2lA2Rk8gDH5Uqq7I7LPKy8USxiTlA3WM5
Qjn72D1t1sEBdHx21PuC3npJpVzBfkLbHkJTSGz3Xov/fimBf35l4Ye5AMLJ6DyUeQIs0Wcn
EMgdf4RY4wQGum3nz1xuHp/h4YtW2Q0UdO2HQnDo+uKKQ6m/oaij4z2gEVMAOJ3cMAmLidY4
VeaZfZPXKr6JAExO/FrxN0ro9cPVZHKjROEpn1TiUxwftrssHtCCcCQkCzoZWvvhYbvdCNv1
XrPXlf7QBvgrXrIHJBgFP6uPjyDtb719dNTqCi58Kd4pEUlt51e9AF29fQb3mrrZ+tao5HVC
JCMTv9JStQI/IY6Bl4B9lGwGmeUPZIjX4bIdCXQqZRxRS6s3uQ7NhXjf61AG1UnvgjL00D9J
RJp9SJD5V2ogt4/j9ZjjdnZp5Yx/lV50BMKT0aHXaR6WHDBM+Vy+rhygzbAbPLIFAZc34o/B
vpCkpX+fesBkkLEROMcL5gL7mlG4gbOuLnFdHeZYVzkyucmlteA8xssreUE2B2K5foL7WkAy
s6VcQoHD8TKTplwQ+qqYh7z7/T25S1j611sLaHYWiwr+l198rI3nXZWLrxi55jIn6TybFC/t
hKuIjtyOKcV/Vah597hl5NSmhBlpS2DLQqiShQSf++B3Fhv8iGxb46yxf9nH9EX0TDyAm/qj
SSQgvfz+ddm9513Yi2gafUbXORCZtRyM5XLPM5506Lrxk7lXAgxvKMZX8P5ueV1wzgOuqCXn
HMYj9/lw2VeCwDoX/uMVVjYvl19K3xp40yq7NqMlG4VovCi9Vc+hNCigM6GLU6FBRAmXdQjv
cEaW6RcceuOptxzazU2jGqHPf8XVNVNOyb/hqbgpujJkSLr4KDjbmbquMbgazbG01LmAp2Ro
NxRwEU0v8YaCzEjHKRNoCaHhIa8Gm5YBXa/gJCSUOwKzHsicGCu4KQOOpNHUuNs9gtQrdEeE
bkNYxRwgzQlZJRAJyxhliN9wFGNhhb9ADtWvIPvG2JO0L6f0+Xq7sO0iu6XoSQiW7nI2x1RG
Vog1R6XgQzP3mj6Dob37wZqqfTku8pqqKKxgay0eHGiPVYuKXAG9knvASkXasCQrTBjXgc0o
iJNOEju0nEN0TRBdNmZhIwh6JzZVIgEqghgJHiFILlpMRlNI/cG0SAGnQ34ogs0qjUi5gxid
VX+Liohx+RBr/JN2tHp4q34jQNKeoEJKLC3duWFhanBSJ4uTOl/ASakxWL5Z+4bsdCu6cnNT
5365qXPv3LSm21/ETKbfPuGhVFqIxz9mNehRnTjiDxQcPimqW5GHHfN4+Ba8mRIb6RsBy5b3
B0qmxvrkC8HMMta/th0kBlrGsMIRJ/nA9Mk4FLLEi6LWqEt2zWchKRc2qjlJ3B4z3kCR0nLw
FRUMatjahMWPMsgFwXYV2VEn7PHrI70r8gGavSQURvbfhZVsy+6qRpUc7oQe803VGB/nZIcF
usOJA+FTdlBMKKT6wpzBovnWdlrMMZX9tTEKgwoJyl7G2VHMNsq/YCFfugtZOt08YfeSoW63
fE23mx+fzrKo17SBzj2c+tYWwlrHXPpIOcv9fn96hblrwTe1+S2HPIsp3zJK1NFOUxfY/k60
fL+17tTPtcW1AwJN8v6QfVEcp31/Dj38R3+w1HHbeCnNYneVX1xeNzRpwbO8r7kGAu8uxq6T
ILCJkcc5FGm0lQ7/SO6CHXvJUxqujO0weAfeJzsVa99QBixysL4Up750ECdXrXU/kK8Gnq/i
m2BGg0x51Pi+4AhTv40ovZiVby9xefDrrnQ7xNRynWXvpD7Ho//lo9RdFvRNteOl+TndrDvy
mqI8oeJr9fK86lXynMGv3FPW4AGaQEbRT5gdnDbLuagozZJUYnXK8wa/S5EtL9epqEpyGuYN
NfZTIPHCCGjaLSLTtAUmh/QC60AP7x8E0n+JtxQqJU7SAFDt03q70cRecptZ81HA1HJWjhv4
HKKqITE+HxMwpd/NgGKLb2tHrYYeVmVIY8oaWK46gTXrxiCBrVhgjqnS4wMBVfJfPydHS718
/Ng4pL3NUAiQR/J7s2fl6wvx+4v8z5ZTX2x6LGZn39XGh0TGCaq+/vb3hbtfmgnY8WuFyV1P
b3q0mxECvpHr3/wytrq0nc6g+C/dxewDpjUGYeY+ltNa/Nc+dh/7WPYulmsHw63O2cUQJXxs
y0nLTvgWctKbG2MTksJgJYHONXiOhQDD6/+Yx0NXIMJSBFh36JauLpXGRjcgiwlhcmSdqh3z
uVOWdQObKsMkKw8FuuiQFSYgc45gBQCZvQxNfgNbStpw7CcVNEAIO6WcnezZSDFjnkdiQR/I
ASy4ybgaBjniOFucUaXHQEh56ZRjLL4Rom/C9Q0hqVxpyxlQVTnI5yPk1HkPIafCiupiCA6N
R2JQHqreFtEbpzPpl6jMu1P4gTHi7iZx6I5l7liU9QMydydSqNhbV12mTxHUyipocqLw7p5k
VZ1w/QR3O85kYbCPDxR4J4RM+vSiC38jQJ0c37+/yXbh7hYtebeaEBfhgpwUdMMLvsrYMSU5
NkZeXOnI0l2qSklB7dCXJspOTkMzaVbCsPyqXJJg6ZaqsIqh5d2SaY9PGy7eG7DsAaxUI/pT
47MXmQzrNsr3/aXbvE+Urkt6Y7iAOcmNZO3kG8W5Pr/xeAbVpVwOzfrS5jxWID7NxqJPY1Ia
O+8xSwsQzZgtTQIRERNIVYGitq9f0kFeXwWas5llfAxWgksD6xqyMbhhaZARPColO6gPxYg/
g2OW+DtH7xQzseBUnBdy/O6v2y/Kv72CVLklPofEA9bEosTzvJREE9S0WQ91PJqMuJTG3s4b
zPFK6+VYcMdEyCwUPoLfn/E73XTRkk907/6PwH76SyDGY//s4ADuetTeh93W35tpWTBs4uRm
uLeziRcMaXS2WIYmidAD8NhiP4pFfJrepmN2d5LVV8yYfL7uI/782eR/eCKMUS4iL3ni19H1
b1uQ7x7H4pVF10vPl5y6H5q4hon2fMPJ9nUIPyaFpAFuvztpNsL9DyHImz/kouB07FibpHN2
2vMgnUbXS+rKfAm87uYz0t8+rvzGZ8nJThKsvcTwtByyv0BZxPAz1BQSYudTsWity5JCtoH8
Nrswl5Jq0MnsIkDij+fQvGj25OzoiK6xGqv2cXLIVbxEfTzDJH+p8607aMzzZiX/aJV5qO6l
/xzkARWzpPDgOglY995MO7wl6U+Ol52I3J97M5FrPS3ppp3WKqf887ankBgLRSlNj3xDkkaS
L9kPnAlWvrlLx5v6T5sqva9tqvT+Zar8y1S5lamyTFgqhqnSyzRVloaULRh2Sm+9nbJM2im9
vHbKX2Fa9P5lWti/dNNieXfTYuk1LWxlPsE5ZBU8oISaPbkPqSST6zV+8ax3b5p5krHXaOZx
nytXkzfS3ePxgojy1GOqIKN2Em/5S9sY6enNOEGOatepreApP5imAC9TFeBlDrXW/IZrUGV9
ojRf/iTls3Xa2dKryy69uqzTUA5Fzm7ht5Klz/Wy9dmlT59N6Kup06MbXt5OX13eXl81wezW
OAllSq9Zi42Wap1JBgdNKI8Sm6im41diE6Vryha7q1qRtJ9AghBgf6Mevb91O2Gts8pSFpmX
uITGu0zTeHuWxmtkieUs5zO+URbLFMAcaiwTzOFml9Ib+Gsiy/5foi1z5mWo6ABhq1C7Y2ps
2KiopqrCBeeyNtZxpV2WVVxaMedUZHcezj8usQqqvvEMBZH1vqkKx6pio8ArZi1kKA+bVR02
MvUHRxfhmsYw1rKAsSxZal0jX+qarQZp0SXmQbZrlivlucV1YAxYCQFqLbS2YWCDzywa6FYi
Fk0FXHBlCfBR0garGLP6cGhqkq0Lkx6s2IwBQMkaz6Ml5zmObbx9U2Fn2lgr/9wnNVrn0RBM
gterjGrgVnFqjcmUmXNV8vvrKdYFVdVReqyQ7bCOIT85M0qPZ8RcFaSsyuKbRWTPhl8NhZ7R
lYEDsb2YRYMS87OlhqLZ6bQ76ltzdmH4UVclm0uKdLQWFTi1B9WJw06z2z7r1JtSEVYLQxpZ
qNQYpGzZpLfffENlFho8ODupC6p7YbdX6511bUGVU6Mt6PqejwLNA3b+eBT9ML0vnWewib10
Pd1yvwm48HeomTtxeM5SPaSCTGoTacxw5uSa0aWTLY6AR86yVert+roqr3DnMPVdm/8UMTK6
WTTZkAykWFtmr1dDlC97vTmAKRCGggAQycEUcLmS1ivSfjNuPvnQkVrnjgguMAK0Zwvplgyz
+YtUgMmz+/dmpx2e1hqN1skhPzpsnoT1Th1RiWF9//590Iq5MgUFUI6D//hB/B8Nqvhkn/09
aFbA5nYznvWFMjTBGvQQCjFVjn/p8pHWEDhbBBbB1eyiPxfG1BAqYwfvcE3jnErTdkwZXYey
+oUeli1CwhXV8etRHMjPBUf28AQhbB8cQHr01gmZNIkkk4zGQm2yqx5IZZD8/AoOLchkEUy3
/Fh80+ycwIRI77r4/fhhtgquwDa76I/GRBL07Gc1MoLbIc5tU+yv15PoH9MfScH3TDFGdiQ5
Q5CkbA6LUHrq506jHw4UP07TPcHIsLiWDhOK7AmJP6Iv51HJxGlU4SVOnZwXbYVeGaTETOCX
mH2eCuaCa9B41xj0/MVqvuTqMjw5vo5pU89ZEDLhc/ahR8976KFqswLFB+NVfIUexPlozrlN
fXZPkrp0i46HRKdkQW19Ph/fkE4qFWxsDLnCKQO8rmgU0D2ajgThoO6QAhOcUWil4TPI2ta9
4rRo/fsx1Dj890DGD0nq8OhO0cGt4vURrsjkOCOCHLabs/M9MDLyo8BS+wAq2uP+XK49U9VI
elyoW6+sTVR5JtbtWtLc8WxalhKjjXPju/abr24oIcG4GHEENoODRRThRU3c6pJ+2hwmk3kb
SJk8kTogMN2ibHCg398MFhH2k1LjbIsC3N1kT+lpkzW7iVH7qlFDYXetrTRzK4iXkPNuNJXK
jEmUobSqWk+fsapl8KO9MH4Eh/BwBH3cCD4LJROhxH9BtdYYp2LT+yS2AbzJaqwuTmtn3K9S
eSCcBXgx7l/+c5kdPJtodwCP3cLs+EIDQqv+Amfng4ljgUEJzDfCjpxNXRZgEdsQikP4t/a+
a3RAMTjR9hUb24toHPXj79LisFd8brMDf3ltD5jXjYQl4rM6DIe6sk7yWBzfh5Jv034rBR8A
ftM7MWjX3f4UUgRQ3LChatpt3EXrNzEofUjrWyjyTOfU1pah6zr4fiIvpUdfKtGuGAS5QhQs
XtGHMqkObqOzuHwtdzamq5CLLqidQ3y3WIZynzcVC0vgukceGAPkjrfJSaXgp58eqDIh621W
PJNRA/P1h0ZLKGt8Tvt8ir1uD5a+3aSd6GrPL53vDJ0+ZfGYlgKyfx6TAj/UJxgJfRGOI8xp
NIRvus/fcuajtWLNeS6dtTa9oS0bx34AKcvHsZRJzi7NS+du3o7blZy9PYOl8dU310X5viMV
gKRb6vyvocWwmOW2c603dn9ES7pSqrDKC2WGDgredtIGpjPSgfAjKHcPW8xwRW4sxgqlX6gS
U1BDtVFTiVUtoc1oSHioCqxxBOtZi2w0szte5WSWtKV6xqPrq/5KrNJCx/GzYYenaZqjGbQR
QxjJVpCZPeN7USZlL5VMF8okrtyvpEp2MnzR5Pu+CJIjD0TwxHCmMb8SqdjN4svvUXc0V6ir
ORqKYoYOuU6DdCud8jM8dPa9UJJ8veLoj+8umPHdXm92J+nNdud6rTc7UVH81t7sjqno4tmN
z4S6Y9VScyBTIGzN94Edqn7bKqWqd3C0eTEbj2efUTbqA3NcwHwkiZEsnACec5yzZ5dcfkl9
l5tOqronpomGbPxFqu59BSOvUeC83masaqc6Kh+XILuF6eF21bS86px2IVvN0FPI0J7Zyhpl
kGOtLaZwUegYHqd9jr2WcSxRX25v7AUSTV6MovGQ7iQPR1z5qr80FWBVvF2eXUAZM3UAvprD
oe64fwOsmPOXGiWd6GmKNis3Mz4Qn5J2QhrBaqErEtuyECbIWvCO8tpxlNccgdw+efvAvGgi
T7715qby46dIRlQ2zFsmbideWcLcr/cmhKh0ruZVe9cuRPa5f2O9d6E8MqDzYHoa0lX7xo04
6JVkz7W6r1/1XYcOvK7i28Uo+sSuV8NTCWYWbzaGtQVbUH+5hIEfGqswUqHnsAaXKT5UySv3
50LtfH8uVMdxlqr6tgwrYDb1jaVfFT6JPvsHAIbUWq8Oz9yfMvydKan2crpfBydKKKkvYn4S
YsyZ3H7MCUB5l3ap0ML0wFD2eJF1ks4pEySXllawm8mlqJkAv6mLMebTHMfLPgCOTMx9tMw7
p0WPA584RlZHscC+mHPCOJC1zpg7HIwIWWUs55F90sybut0b89Kc5Pzb3pkziXXk6fpj5MTG
ZtK3dnejpo9nHB6OWrZBguGg8PnXUtWcpE/N4r01aon2qXW8PrXO7X1qWTZXDt0iWVDdVge+
fiEiO5YVb6INZv0xZWKFrOv9sRhZMk1lMMQkgmTHo3gCm0jnvVB3l1e5I115fxRga3CbtX0k
GqsYb19WnZB3IjZIA8d/4W6/txOIsR9/RASDq9X0Yxy8pI8+o8eK4YUuAjVyB0JXBLSTfvwR
dzpFFiKg95KayCZm0B8PVmOM/yEfHB5M18cfZTrK47ebgiuvrzHJPuLYUOnrF9Hvq9ECl4iw
BySEHpQR3uoaZCcsctIVmYrDXGcsIi+hlasGRkjqDPQPH8lAxOu/Y8r+OImECKdfA//ONHv1
iZbqmcEDeuYpYws5CwGPRYdfuehZ42VgJVxGltvL0WXTzgB6v7/0bJqJRZaZo6gQJGfJ/wrH
3pefCNrAQCxY0K/g0Aln90lQoRsiUFCZgMWzvZ2XOjJKrM66b2Yy8vWIzWhNjtpiEQmBK0Xb
kIlHFr6nl+lpibIwo6ANOLvPQPTJyfDDQ/BNLgLgxYTbCc/e3YRn7/8J4RkOjt4EFyAbo+lA
SUXEYEumFDHKC94Wo11DJP2TSFFBsjBS439JUo8kXX7vkrR3a0naex8etA7a4VnnsHnSC3uv
O83u6/aRpwYKiVWkSYjSnW8u96CQwvwGMgTAHxRYjJ5z1qEhy0MUL6EOxWg2TT9EpZ+TrF/d
Z4Kb7KPLqyU3gNlflAtD3dZGgyRxE19VM4Pgk/+JFjMLFd7ih2lRZ6AGufIqu4GRDhHoRpY8
qzV6jdfzqecypSPbNwZanw7H6C2OixcDvlquUv7buFOzJA/jpQvp6ZYJztfa4UfWMuwB8C99
l566KboD/c7Kswz5MKUlZ3X3r659RMxa9A7yhn8EaX3pMdKDwzJCrPG/A1PhHMthx2uWuLwf
2a09KumP8KIuGX6cNdEY+R90ssVHRSEwFg6ofig7QHd9+YvHj/Gf8h3/U+Pf3ORTH12MU/zv
IthcLU6C8WQ424S7oJvVrZ3N/16NbzarlSd0zzV+IrbBJ5NPJKvEoG5d0ffi0/RPHmxubt4W
baHyfO/5ZqW6uV0JKs9elMvi/7fkxeZysFneK5cfPH78OEfzhWq5vL1ZfrpZ3Q4quy92nr+o
PLNQ7QpU//mf4i8b5eBxZWNv+1nwn/+JpvcUbO8wNIXz6zAUr8RzkCqeVwA3HYxXwyj4eTya
rq6fUB76ratfkq+AYFgjvneT2XA1jryvPoI6Mva+ymgsno+m49ngI740X/fjiRwx+Y76V9hv
9coFdaG8Yr2o6BdV60VVv9ixXmzrF8+sFzvqRaVsvdhVL6r2iz31Ysd+8VS9eGa/eCZfVMr2
i+fyRdV5UVFd33HfqL4/c9/IzoNaYL+Rva8m3sju7yTeyP4/S7zhAUDtw37DI1BNvuEh2Em+
4TF4lnhTpTEgJcd+Q2NQ9byhMdjxvKExeOZ5g2PAupT9Bseg6nuDY7Dje4Nj8Mz3BsaAm3He
wBhUfW+2YQx2vG9gDJ6pN/epaN1nLdJ7xkWKFd3dmfep7CLsf1dCsQrGwhgcy6wIqg6LMBOs
2isxpMT7nvt4Xz9M0SJ3C2milMNW57/Ck7PjYOcZJXWZQFItHD+ZhXsD1LYyahEueEWBJxA+
rmRgq3ixVTOwVddiwzubqNEZCWLfCxNIWD3mGT65ifExHOix8nkykzETfNUSc9vZkFDTU6iJ
WJRUf0QOZESCh7u1kwbcvIHbovISpsAjM4MV44/nD+MS3s+K+gPzLIQI6ZFLxaZ4rG+AKqeL
+QU0vIHgeHlwOoP2jUujPZcAPFPW70WPYFhVCAiSIse0EV30V+OlHDCV0RJkl0WFOafeUOKg
ooSTwtpxsO7kQGqdpQQ7hNPTcr1dOwrMvdTEoF8iPadCTkBQihODgodFOFlSaFAOtIDUegxe
NVS8cC7QBAmTXVrJoOsyECRVJ1QYj4QGIMZtFaRyFC7hFu9Hab/rlGAdDB0Tk0UXsuio1PIq
XGPOKJW0EQ6aJpPZFFOcdN/sx1AXQ7Q3xVQZZLmuxfXxPHZI6eQgZeEnZWXQotlQmHS3wkkk
IdYHeHtZvFn2448qkO4CTG3JYeAfBOtxtlwKA/mqP77AJGZw3IfQT/TkLH8P+W+MUR3YUTtn
FHpLkQMCP5IsmDeazJc3ELwxEisboggwxR9Sg25Kgua0ecNZRLnKrijcT0bRShGRIGo0iRYh
ZqphdycMqEzwC1SGmMc+DPvL5WJ0vhI2VhgUi3zhvNg9Pg3rtfrrZrj/odfslsg3rUYWcGAL
EB5C/V0Jk108FmMeSqcTPFpaj/7Ebx88hpkxVwKkMCuKh9CK+242j6bFxEIQRqTnW3SMhNcT
gc2+YR082ghy45jN09pDo9wmfBleibUxjhZA/waZ7bqxOUQEX8YpLQnskz4Zu1Ec+xqVCEs8
cP8PaWoxeo8tVW08+/wvTc3+4cZ7/65Scn29jvpQkeYA/Dywr73Qfngx0J9ni49GkZsr+jiX
t5S/vQDEIFeFrhYLjW2wmImJvplHYgemdI/KrTqMBuM+FxcUpBgI8aiivxBcMQ4OR5fB/sio
J89BZ2Or8mmjedo8aTRP6q1m99v59R485p5htZ0gxAyO/0uRFBuUPvJPTOsoc4qQGsJZwC09
yFOakg45TAXIrEP4tnZ01gz8v3+I3po/0KfPTlp1uIB/0u4c147C43ajWSj8kfJxo3lQOzvq
aU2rnOvbWud0/fey+PJ+PWwdCHJ6Yes0bHcAOCdM6zQvdoEzSP+2XjvtnXWaYa9+Gh50asfN
bthoddd/f9bI970xMtDEbUYSmrjN9/unjTMJ4OMsoeVQDo38DMaFLpHPCgVf+93T2gm1fFqr
v2n2umGty/yVSvNprdNrgQCBoYMosQePHXrj4aSv0sumkGiewzOBQGGBS+9gqH5HMDsYCOFO
uLez3+oFhT/kN4c99JK2Tg8hRk18XiyXgE9MHD0fDsqDwpQksVB1psD5OcNQNKoAGbEHvlmL
o8WoP147GHZRbT1hoisYM9ru1JvhUevkjRj9bhdKo/xhvOZgvdpZrx2eNA/h87Bxdnr03v6M
p8v+7uCo/S6s9zpHgfVtrfE27H44Pm72Oq26+ZH1FdF1UEdZJPhGUHfWbUJDYvADz6f7p+rT
v9WODWzgOw3wDNWiuI3Sxej+Qa3lEgFXq2sn3eNWL6zshbVer3l82usG2UPUPW02G+HhcatV
sOls9JrY+XKQIMYdvv0PMBn2R+ql6GH9de3ksOlOFhSBENxN6y2s7O5WQZl3yK0fdWD1hkft
9um++NJFAnmg4M4VTnPzPQ6qv8dq6mA5iHZbJyaguRiSdSqCQPkq9We97M9wCRzX6hh6PY+W
TxbRf0dgYpMeYbJ+rV5vnvYEmroY8UYHz8aMhjrNvzXrzusKN0Bpu2QKLDwv5YNbGQtqNmTd
+4FpLV9XGZHQTfrnpm5yBslRD8ezc7FqZWW8WG/2x619ob5giEusa+5hOxj3Hyf8YgIiPGy3
G2G73gMBy9tbQ8ztO+jwdTnn969bh69xqJPf79cSn0tZVb5+lvwew3pPQIcQg6tWT7PTge8H
KfTwfuk0AB5wP0H+7wHA14NOu9ZA7SYBJgA8XTgW22YrFcDTB/5sb4dHypDn4KtPB9gNxZKu
VJ8acALA0wcGqFSfAUR1d1dDCABPHxigursHALuVigWQ3ofdShVpKle3FYTYidL7IL7cAQhY
sQaApw8m53UhYIS4lDq97elDAoDYlAHW8BIAWPOw4+lD83292e2CRlhvHx21ukLzMAA8fUiw
hm5GAHj6kGA+C8DTh7MTwW24eOSWrbivfL3rm4e621ej07tp83BQT6weAvD1oZb2PQB4+9Bo
dlAzSsCUr/f8vHR4LDqRXNIA4OlD+21aAwDg6cPfavv7Yl/x92HP0weYAWku0GUgA+Bpilyq
d+ph821iNgSApw8JlrMAPH04qvU8jCoBBryNnBq6Id8KgAqUxdNup5TYQVBaH9SECgT6imil
5eMjbiMN9LR+nA6FPzift6FR4xK6XKP9ztP/zIYl6NnpOkBsuGJDo1JcE7KkdnTAmkrehiWo
oeRkNVy1oYWmoBUmVvgaKdDlDNDmyX4tHRIa3rahcWZJKa2Uy+J/GeNVzgLNAsSGE0yugTNB
kw1b7a4BhfgLG1ooyL30qclsuIdq7GmnfdgRO8Pahp/a0KS2Q/u1ek9Ijls0zKDr4ajhZx7W
BHtGsKc2ouEaYBJXClevA+OGn3ugZSAoEAAW0odcPbZAM8C44UpZOQN6V1EcSbVfpp8nj/Fp
0lNG0u86HAj5J/TxpBrtcX6lElL2gwqGOW5162fts24qfFIIJh1p6SOwDrSSPXhroKuZ0NU1
0Nvp0EUAD/5AGkpr0OxkErG9Bno3m4jtnETs5UJTXYfmaT40a4kynKZ+bOl8oUFTeCMpsb3Q
KbyRFLte6BTegEHYpd7v5Ol9Cm9AiF0O6BTeACL2bkFECm8YaHbzoEnhDRONn6gM53gCm6tC
kMcjD6RnX3M97P4OrG84G9KzryUd9ndrOBvSs6+Jfal2DBv52WkD1G40AcLu2fFxrePuUxhP
aYP7Dw9y0e0BbaapyBiV6Qe3jyFu1bIBmtly+vI3DjRytewFTZdalfQ1r8HTxVblaQ7wDLlV
ecpiey99tWtE6ZLL9T15wTNEV+XZbejIEF4K0dM8iDLEl0a0njLjEMuPMJ1HNGgGjzzPAZ7O
I67XzguewSPVMo/A8zwjkMIjiChdddPwGUxSrdyGkAwmkYiq5TyIMphEI1pPmXly6ceYPk8G
rJ9NMAY8D7ifTTBQPA+4n01wKKQemKFPGoj8bIJh6XnA/VyCdOzcig4/l1iItnMh8nOJjcig
7E7mHx9uKyvwPZuBrhVYPxL2d+vgQ/qeZw25w3cZp90J6LWgvXaaIeHxZ7lH5hlkuwa4AqUD
vTU9ruoJuH7SkUGhsvAGjm/nv+qdJz3xn5I7uryGc7TkG11exXmhKz7oal7oqg96Oy/0tg96
Jy/0jg96Ny/0rg96Ly/0ng/6aV7op/75Xs+UPrVfzndO6Of++c4J7R4yygnPC+7ltp3c4F52
280N7uW3vdzgXoZ7mht8N7dQ7nLgjuuY6zbqaX65TutgP5MCm5ik09wI0alwmI//lwlazQRN
iht/fFEqdPKYwIB+lgmd4Vxzer+XhScptfaPjgGDMH+772prjlmSUouhIfZkLbzrBRegvfwN
73qh79KwDF5td7pr4X1OJw29jvbkgcNd2bR3OzZ1dV1vDFsG+HYWeA5GTdN1e7djVdB1c0sd
J0aOD0JTJQ4Hy+HJxDoR6GpxBui6LTMprNwovKyfx52fiGVLR+I0nBrftx7UG/OXApuUc76G
dSzg7RtOgU3KNojAE2s0ra2shtMiF1Nmacc3x2kRjZkN26C99xrU2/CuD9qJj8zXYxtUwGUc
rCaVQB90KMwNSALZ6SSgn6WuCQzNzPq5HOIP7kwj29UAU8I+87RsgIrWm2+bHT+YbNldyS5r
62BSL/h29qLKgE4MmQpOXf9LAc04grSIdp0V/uDXPC27/c2A9HmsPRG1efvcaXZ7NTg4ZxTr
+uwoDG6kbuUZRurmadkFrVbTQT3O7pQY4VRwNw7JAn9ezmo907XsIKo8X0PH80zwp+XyGjqe
p9AB4c5WOHTGz+MXTkRTZ/wSGoMn0Dqj5UoS3AhiygT3L5vs+G2jZddJygs2D7ynz0ZQEUaa
poX45ABNiw3yqKsA7kDfZqLchrMmakepp2IfQJ0zoWcet4TO21UHiZzyQ0CUg83gHaRq3ggq
mPu+P9TIfWgwFeXb2lGrwWie3glN+7QOezQmeSuUsZbEbDIfR5S+7IIwqPpOWSiAoIDzngg0
bQUzirmK5CVmHDN/KgYeru4olyJHL2L5itiM8mcnZPCTW4LByIJs8XvG4S38QECUSxl4zerC
lsHpyXPtIt6uGJhzEHtUd+NNHWLLhSBwhNhZZw0MSD4XCGIJ1wFVXaAjQV73pHYK2s1xLWml
AdDzQPY43/Rg1GwGJb4eQwBw5+wkFc7bY9g08GA7PGqeHErGWNNjWZM4rami5YVxgN8e1U7C
Xu3wMCVgs+g7/8KzAKQzY2LcUzgVLoBDA+Edb63zoiKKLJdvGmuAcN9xh773WnxLYL0Ppwki
iz4j/6j2QQBVIW4Xx8U9Uyv6Do10G0nSFJAbJENAr4UUgpWZ3JARyI3TEbsXFqDGIqxpQ+4e
ZkNYbquTDoVArr5xdvLmRMgLgOm1Tmp4/AJ3kCygZ8mW3Kz5yZZcNqIh3xGabbP+Rgg/dzBQ
OJVTliok4aMUu4nlSgMsQ/aTjI3EpMi8NEGaoFUPbKGAi8Tld6ICtmaxIcMy81BRcadZLRLf
HAcpsrWxBsYX53DYPMHGAFj2KQHksgYAEZ97YVifdoD+3uyAJ6HRaJ14jRCvhOnlYfeEhMnD
7q6wgD4J+Z4ydinCopeH3V1hgZZYhhJss7tKOuC7qS9z12KuHsBdhjSYG/yPivhHRf6jKv4h
1OM/6UC13aFLwEl0kNcACrHIYmoSc/vNBqXW6sjyNn2oJDWPBlhIyvPDrC9Kq9lA4IPVdNif
RNNlf0z1ILyQJjAWDSbg+mw1Hlo1/jCTdbzcCnqLmwCyXRM+3bKqykYYMMONU/NbVgv3N69L
+xkY7JIW/i44GJCL5Q6dQBQHfVn7mItzbVmIaNacqjkpE7jsLy4jzRHC+D8UIA0hGDacR823
rXrTeVjf7zpPTuutcvJRRRJFj15abm5IywVZOc5Hl5uQDbU/BaVYDHgEw3w0Wi7HYuzoxTSK
hM4M2VIjKKOGSS9wsdBVUpnD699GF5x2YlgMw3242H/SaNVOSnoIOElNyMWEsHwJ5rCq7BVU
yRosFKnLosiyWnoTUXOHYLJuXUHft8UUX+lTvtquFmT5Qqcxx1xwobC2GlZigXI8WPbQKeIi
7/UmW5RFfPzdc+A0R3GdGYuTzGFcZg1jcuzUuHERQPwM6+IsZp9GQ0jhVj+lQunxauIfrzoN
0hPTpsoao1Nd98Zb88YdHaNODncAOHUJuV8c0D+liFdD9G/R2GLDo1avJ2R/fk68G2/ckRHv
yPZ34aYv4d87cGJ+lrklL+Zl8Tvz1N2Y2OVEwYdxBH9gRaX2FPPYmVIxEI8d9gwmYleBTG7M
vg9komoS3GfTkRi3oRxzoF8o2sCRQjFW7pQY62xDYroF1T5e6goRgnagFUZNSP/+ZDQeia8o
k2M0gtQCgGpKiA1VO0sDcDlBFd+zchPGV6AC3YXXbQwmpwhSE8xSl8ySRIAVDW6/sk3w2y86
O5Hco8Csq4YFSmGalK5iFFqVBQuJt2TxPJXIzanPEQsdTzDHAEENSP9C1WUWpQaCRSRU7siC
osxXBYTH5VkBv5cp6H7d+013iPmXoDDJBqff1wuMaMAQHqO9zNxULlxI0ZgvfdAyUtMHHWPh
N27agmWPISLwQmIEQMgRAA5wagodDS8kJAY6hsxwLFgWUAByOfoUqfSYcSB4eNKXdZgVgsU6
BB0vAsooiaQKpu0vB1fBvE/ZRlFOKPaxc5LGss7iaPiI2p9T7lJK2gjpxgpOdbeXXMs2u1It
Qi49kL01kNQRChnFnLpCaZ32LyequG8kXbxbwYEA5Ex/opMGOG55urAnZorDxM60/DAfr1tr
0i2gHv6+ESSKQuZG3/OhXzrol370ZudRvYAGoMaA4DjBgKLJzCHwVs2EoqlmqcpExXfzpcqw
mpBtVFbSmzv3N6LfarynG19mNb7M0/jSbryXbFyb1Y4olbkft66C2mkrwLyn6mQAF5c+q1DB
P1RiJQ58RTdwqWBWUqvFZIVUSMzpBcaSuv7yPgYMJgHUhYEgfWmeFhNtYu8xoSgL1kV0mVlb
CLY3a4ooHdnL1NJF1MJljhaIwGQFyEDXfKLKQlTChjM8WvOQvwKdXQHFWx0po1Pp9Zhy4rW0
u1Nnr8zBYivaesNUXpHTpRqmCipzBCtJh8Dp6w8oRCBnlK9RyWY0ifOrm3XsmcKgWDU2jCej
PPxlZ7XGNi9T3irmS2lXiI1hzmYzW7XL2iRbVZMzGEf9RTgZnYdcZS7OGis597j3XkCW2iwh
43Eymbw4HeauyuwvyPxybUtLVQQapLLbnMSOvzsUhF7fPs/pIBL7WkbrGW3fteXs8tf30HMP
C0cL3EnUDgkbf84phqbM/TNFfmNeb/kNKBKGdEghZnF3YhZeYvgNDCvu8Kl0Llw6s75EdE6P
SOYWyE9uFjKCRZa3IFQ8iEf4n3ASLS6jrUGyIlPikxwFoRIwXMWpslmpBJXKi93tF5XdfAWh
0lA9Fe0Flb0XAptTW0oWhKpUdp9u7AWP8c/KDlSFCgrsxGfjQ0i/36Hiebcxny6hVrjx8qX4
WthXezu0NQmbWYhAoeFjATvxUu3tnFP1b7XDs1oHgh2O2u9Iw33//j0lesaCnVf9wcetra2g
hYm856tlIOvC91HgXvU/8SkBFBm8jCjzPeCIxEjcSP1XvKdU68F0Nt0UzaFyPokmM/HNjEo7
/q1/uepDdQyJgWq+XFNmfYoE79a7reACqnhiBmsodSf2FyzmQe/6UEZDo2h1a8FnsM9oV++f
j8aj5c2WSrnffY1jKMYIPBdC3R/F/RCut7wKKlpFCKDwQAA4WxfktLqaxUs8JulPBePj6IKD
B/V/WEBA7BSqiDyEKUDXDvp5+oQGuYKMJzyQgZ5+vpqJIUEvhsyNPjMDbkRfJ/2PkbAsF9Ha
pcKFtp7048nmZDSP93aewBDE8/4gMguoZX+XsWiyAYHdq5uVMtQ/Kz9/Ud15UU2yu7Vy1uMz
66k9e1GuepfPsx1YPOK/WE8teBAYpyJBkZm+fnoWdna2y+US7gqFfzzAfeGPP1K+fC+/5AS/
aR8ePy3n/fK58WVm47s5Pzxpvq01anm+PG6ddvd2SiRtqjsbT4Wwqe5tCBkHIyaPYd+c7de6
kG25bD7Dax3b1YKuqiZLXmGcGX3wgDL04q4APo6+rAgJ54jyqMqQQXrs9Cnwm7Js/vr5s7L1
k87dwPNt3/MtrWD747D5/ih81ykUFCwYoteCBWNw44gFh9oyEOtCnrRP6u3XPsIAh5Bug9kV
ntP5gEWzSGY5Calbz7ETelaLUBKWoMisWd36s9stbg3Ha3Fvs7ILZRJ3qi+qlVuv7QQ62hmf
ArpKys5Y3cWNUfzx1GJVYbW9Do/bx00xMWG73jxq9yy29bwPDwuFSvYX9ULBiJW1vuBNs9Z7
Xyhsg5CB3UFI9bf9MZQY6Q+uwO2LvH8pjIh50Oo17zKlg/lqzWziF7ebSARx5nB798Xuzq3n
0MQkFZtd8f/PvdNHao34rz15p51WI2wdn4bHtcNWHXMuA0TyPUkI/OCp9wOSgPjBM/gQPKHH
u9W9cvAf//EfdjJ1jfM549ze8Te6u0PSbjft/S7B7/qJ3nmDXcJaisjDe3sob/ee8gYlIUAG
vu3sVJ5VRA92K/aL2lmlAs3sVu3n3c7TCtK/u/1g03wBoRT49LH5VPbWTCRrfL1jcDKoTUdY
rCUS8gyqR8V3YeDROmk0urUcGjkSqFwWSvmL7ae35t7R7BZqxc42MK/4b6VM02YVMo1HcHSG
GH8R73jHsSMyknqCsT97dIMHbrFUQfXm+ay/GMbckPZfBfZ+2j1sha3T6tMHeAqzmDqW2fkq
DpczYZjBsVF1d+83MAvuMLnwB9RHWjPF+rPbTbSG41naEasnKIsdouIrprtuuhPocuiS27ug
FT2GP6u0XAuFH7cglfwimi2G0eJHYdQGf8JUP+F60zh5wjD4H5goodi/AzMAjZve0T5o8av5
UFbiW47PP4/gHBr+stgQelK8Oo/BmuMgHzg0YEsAwWFDGU3J9Y5e1/hKxXvNBoMVHarvBEIw
B4ObARxFgGNxBSfhAh28RC/XctGfxuN+Bo5tAwfHFwXsjBgJa0cIDjT+BOHsVqTTn2ERHpce
BP8rhioMxfCHYRCG8tghDIt6CKczHsR/TP+x/DFjsfByEHDxePyP5f9X3hD/X2GoL3+qTLzC
jzgh3w85Xk4jIwd20cfP9nY2Ks+RL/95x/s7Isc73ncQjHNh1K8RivTJ7QQiwdzL3mehWi8I
K5UdckntSI+UZ7a6Lcq1sF+5vr4Ou+16ydCHaodNWVcjaaSdHalN08cGrl5uxArbeF17TOBV
X56d1Gv1EG098WHZ8+F6ArTan0pCsmtgiAtNdCCMgmi4ESjjEMXmeX/w0dJM15DJyFZTgW4j
OIeqoeB8QwxS61CDHobzfvG6VCgUi5YCUArE02DTpLxkQn2SUFy90Av+2AIv3WWZUMDGmoUi
P7rdUpFQ92KqOsjUcnn+opxExpZOZRtNHfGHqeRLDsYJFv85awTFQNb/Dp4I+ykomTOovqeE
FFiEufCsrHX9xAfMORdDwGjeb039Uv4kRHrzVWq+ktp81W6+nN581d982Wo+dIDC1kmrR4U6
gQdK5OnaLPyv+OdqiAcNLzxDvBGMFr+/wINgDGSJXwTdXiOst4/Dg6PaYXcDaiHdHkex1v1w
Ij5pt+niOMiK4I+AnnbftE7DXrPbKwnsQSEIRrNJNGH0xdUzsaqwDxv8QiimYXw1uli+CKob
5MBDoBD8CIJe7n87PG4ew66kvBKOaLSTnjQPTro0SMCVT9GEEf+t2ky5Hodj0hiWRlIy4nlq
eyEsRgh+OulW9nZ3q8FwBYVAyQEuGP749f8Eg8WNUCjHW/YVVo0oc4089kKYq+Rp5hdpzG/g
DRNgPv4LEszj68EXsc/j27NPIKFS+OexO/fJvroc9LiQNiD+CdhIG/aSjs29BRF5jF10Xpjq
ynbF8TVZaFXXggLAp3U8KORZZDBA+QYTMHbhnndqeyCdPGtw7RY7jZZPBkLJfxJ/hJNX81Q0
8SpjO018q/a98k5QFTvottAUszfRdBTkJBSaZjWptEr/GEyd+KNSJYvbrQUtcMIhJ6wCMGbz
nWm2p3y6GAefI4rzVmdpeHYYf8QwYrKP6XY7H1LSWSKdVAppdfCu9Y6OAD8ru/mqv5gEdMg3
F5YXRA/HAQV0b23ps8bLi3k4garlf7wSatbhwSmQaB4yCtVTyJdwJEOtiqXgp5+CooL7icHe
1VpC50Kjr6Cs8iWHbr8KyjA+iOzxY3r2c7ALn///UF86S2KBAwA=
--------------030906050905080803010205--


From lyle@zevion.com Thu Jul 24 01:56:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jul 2003 01:56:51 +0100 (BST)
Received: from host31.ipowerweb.com ([IPv6:::ffff:12.129.198.131]:5090 "EHLO
	host31.ipowerweb.com") by linux-mips.org with ESMTP
	id <S8225193AbTGXA4T>; Thu, 24 Jul 2003 01:56:19 +0100
Received: from rrcs-central-24-123-115-44.biz.rr.com ([24.123.115.44] helo=radium)
	by host31.ipowerweb.com with esmtp (Exim 3.36 #1)
	id 19fUP4-0003AG-00; Wed, 23 Jul 2003 17:56:19 -0700
From: "Lyle Bainbridge" <lyle@zevion.com>
To: "'Tiemo Krueger - mycable GmbH'" <tk@mycable.de>
Cc: <saravana_kumar@naturesoft.net>, <linux-mips@linux-mips.org>
Subject: RE: Cross Compilation
Date: Wed, 23 Jul 2003 19:55:56 -0500
Message-ID: <000101c3517e$5783a400$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: <20030723100946.N3135@mvista.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host31.ipowerweb.com
X-AntiAbuse: Original Domain - linux-mips.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - zevion.com
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: 2900
X-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


> I took a look.  It looks similar to one project that I worked on
> before.   Very interesting.
> 
> Has anybody tried successfully to do a cross MIPS yet?  From 
> a Linux/i386 host obviously ...

I have used the uclibc toolchain for big endian mips. It works great.  I
also have a gcc-3.2.3/glibc-2.2.5 based toolchain, and have used it to
cross compile a kernel and a simple root filesystem.

Lyle


From macro@ds2.pg.gda.pl Thu Jul 24 12:13:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jul 2003 12:13:46 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:26797 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225193AbTGXLNn>; Thu, 24 Jul 2003 12:13:43 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA11563;
	Thu, 24 Jul 2003 13:13:35 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 24 Jul 2003 13:13:34 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: [patch] Generic time fixes
In-Reply-To: <20030723100043.M3135@mvista.com>
Message-ID: <Pine.GSO.3.96.1030724130418.10709B-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: 2901
X-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 Wed, 23 Jul 2003, Jun Sun wrote:

> Most people seem to be happy with getting hwclock working.  rtc_set_time()
> does allow a low-oevrhead way to implement a generic rtc driver which
> makes hwclock happy.

 Well, some people are not most people and they want a full-featured
implementation as described in Documentation/rtc.txt.

> I like see mc146818rtc related RTC go away eventually, but we don't have to 
> agree on that right now.

 You'll need to convince guys at the LKML first (me inclusive ;-) ).  If
you write a clean and full-featured replacement, you'll most likely be
welcome.

> You can either include it in your next patch (if one is coming).  Or
> just let me know and I will flesh it out and check it in.

 Here is an optimized replacement I'm going to check in -- OK?  Ralf?

 I'm working on further changes, but there is no point in coalescing
self-contained changes.

  Maciej

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

patch-mips-2.4.21-20030711-mips-mmss-0
diff -up --recursive --new-file linux-mips-2.4.21-20030711.macro/arch/mips/kernel/time.c linux-mips-2.4.21-20030711/arch/mips/kernel/time.c
--- linux-mips-2.4.21-20030711.macro/arch/mips/kernel/time.c	2003-07-21 20:28:39.000000000 +0000
+++ linux-mips-2.4.21-20030711/arch/mips/kernel/time.c	2003-07-24 08:22:52.000000000 +0000
@@ -62,6 +62,7 @@ static int null_rtc_set_time(unsigned lo
 
 unsigned long (*rtc_get_time)(void) = null_rtc_get_time;
 int (*rtc_set_time)(unsigned long) = null_rtc_set_time;
+int (*rtc_set_mmss)(unsigned long);
 
 
 /*
@@ -364,7 +365,7 @@ void timer_interrupt(int irq, void *dev_
 	    xtime.tv_sec > last_rtc_update + 660 &&
 	    xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
 	    xtime.tv_usec <= 500000 + ((unsigned) tick) / 2) {
-		if (rtc_set_time(xtime.tv_sec) == 0) {
+		if (rtc_set_mmss(xtime.tv_sec) == 0) {
 			last_rtc_update = xtime.tv_sec;
 		} else {
 			/* do it again in 60 s */
@@ -473,6 +474,9 @@ void __init time_init(void)
 	if (board_time_init)
 		board_time_init();
 
+	if (!rtc_set_mmss)
+		rtc_set_mmss = rtc_set_time;
+
 	xtime.tv_sec = rtc_get_time();
 	xtime.tv_usec = 0;
 
diff -up --recursive --new-file linux-mips-2.4.21-20030711.macro/arch/mips64/kernel/time.c linux-mips-2.4.21-20030711/arch/mips64/kernel/time.c
--- linux-mips-2.4.21-20030711.macro/arch/mips64/kernel/time.c	2003-07-21 20:28:39.000000000 +0000
+++ linux-mips-2.4.21-20030711/arch/mips64/kernel/time.c	2003-07-24 08:22:52.000000000 +0000
@@ -62,6 +62,7 @@ static int null_rtc_set_time(unsigned lo
 
 unsigned long (*rtc_get_time)(void) = null_rtc_get_time;
 int (*rtc_set_time)(unsigned long) = null_rtc_set_time;
+int (*rtc_set_mmss)(unsigned long);
 
 
 /*
@@ -364,7 +365,7 @@ void timer_interrupt(int irq, void *dev_
 	    xtime.tv_sec > last_rtc_update + 660 &&
 	    xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
 	    xtime.tv_usec <= 500000 + ((unsigned) tick) / 2) {
-		if (rtc_set_time(xtime.tv_sec) == 0) {
+		if (rtc_set_mmss(xtime.tv_sec) == 0) {
 			last_rtc_update = xtime.tv_sec;
 		} else {
 			/* do it again in 60 s */
@@ -473,6 +474,9 @@ void __init time_init(void)
 	if (board_time_init)
 		board_time_init();
 
+	if (!rtc_set_mmss)
+		rtc_set_mmss = rtc_set_time;
+
 	xtime.tv_sec = rtc_get_time();
 	xtime.tv_usec = 0;
 
diff -up --recursive --new-file linux-mips-2.4.21-20030711.macro/include/asm-mips/time.h linux-mips-2.4.21-20030711/include/asm-mips/time.h
--- linux-mips-2.4.21-20030711.macro/include/asm-mips/time.h	2003-07-21 21:02:58.000000000 +0000
+++ linux-mips-2.4.21-20030711/include/asm-mips/time.h	2003-07-24 08:24:08.000000000 +0000
@@ -28,9 +28,12 @@
  * RTC ops.  By default, they point to no-RTC functions.
  *	rtc_get_time - mktime(year, mon, day, hour, min, sec) in seconds.
  *	rtc_set_time - reverse the above translation and set time to RTC.
+ *	rtc_set_mmss - similar to rtc_set_time, but only min and sec need
+ *			to be set.  Used by RTC sync-up.
  */
 extern unsigned long (*rtc_get_time)(void);
 extern int (*rtc_set_time)(unsigned long);
+extern int (*rtc_set_mmss)(unsigned long);
 
 /*
  * to_tm() converts system time back to (year, mon, day, hour, min, sec).
diff -up --recursive --new-file linux-mips-2.4.21-20030711.macro/include/asm-mips64/time.h linux-mips-2.4.21-20030711/include/asm-mips64/time.h
--- linux-mips-2.4.21-20030711.macro/include/asm-mips64/time.h	2003-07-21 21:02:58.000000000 +0000
+++ linux-mips-2.4.21-20030711/include/asm-mips64/time.h	2003-07-24 08:24:08.000000000 +0000
@@ -28,9 +28,12 @@
  * RTC ops.  By default, they point to no-RTC functions.
  *	rtc_get_time - mktime(year, mon, day, hour, min, sec) in seconds.
  *	rtc_set_time - reverse the above translation and set time to RTC.
+ *	rtc_set_mmss - similar to rtc_set_time, but only min and sec need
+ *			to be set.  Used by RTC sync-up.
  */
 extern unsigned long (*rtc_get_time)(void);
 extern int (*rtc_set_time)(unsigned long);
+extern int (*rtc_set_mmss)(unsigned long);
 
 /*
  * to_tm() converts system time back to (year, mon, day, hour, min, sec).


From dkesselr@mmc.atmel.com Thu Jul 24 15:27:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jul 2003 15:27:27 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:6994
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225229AbTGXO1Z>; Thu, 24 Jul 2003 15:27: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 KAA16323
	for <linux-mips@linux-mips.org>; Thu, 24 Jul 2003 10:27:16 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA23245
	for <linux-mips@linux-mips.org>; Thu, 24 Jul 2003 10:27:16 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 24 Jul 2003 10:27:16 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: boot requirements
Message-ID: <Pine.GSO.4.44.0307241019450.23101-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: 2902
X-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

I am trying to determine what has to be included in our boot code to start
linux. I didn't think I needed to port yamon. What does yamon or pmon
provide for starting or debugging(gdb) linux? Does the processor need to
be in a specific state or context before jumping from the boot code to the
linux downloaded image? If someone can point me to a simple example, I
would greatly appreciate it.

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


From joeg@clearcore.com Thu Jul 24 16:50:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jul 2003 16:50:37 +0100 (BST)
Received: from www.clearcore.com ([IPv6:::ffff:69.20.152.109]:40614 "EHLO
	sam.clearcore.com") by linux-mips.org with ESMTP
	id <S8225229AbTGXPuf>; Thu, 24 Jul 2003 16:50:35 +0100
Received: from clearcore.com (clrsrv.clearcore.com [192.168.1.1])
	by sam.clearcore.com (Postfix) with ESMTP
	id 87CAC136B3; Thu, 24 Jul 2003 09:50:31 -0600 (MDT)
Message-ID: <3F200047.2050506@clearcore.com>
Date: Thu, 24 Jul 2003 09:50:31 -0600
From: Joe George <joeg@clearcore.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: boot requirements
References: <Pine.GSO.4.44.0307241019450.23101-100000@ares.mmc.atmel.com>
In-Reply-To: <Pine.GSO.4.44.0307241019450.23101-100000@ares.mmc.atmel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <joeg@clearcore.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: 2903
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joeg@clearcore.com
Precedence: bulk
X-list: linux-mips

I found Jun's porting howto to be an immense help.

http://linux.junsun.net/porting-howto/

I found it easier to port Linux to my board than
Yamon.  But I guess it probably depends a lot on
the kind of port.

Joe

David Kesselring wrote:
> I am trying to determine what has to be included in our boot code to start
> linux. I didn't think I needed to port yamon. What does yamon or pmon
> provide for starting or debugging(gdb) linux? Does the processor need to
> be in a specific state or context before jumping from the boot code to the
> linux downloaded image? If someone can point me to a simple example, I
> would greatly appreciate it.
> 
> David Kesselring
> Atmel MMC
> dkesselr@mmc.atmel.com
> 919-462-6587
> 



From wd@denx.de Thu Jul 24 17:02:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jul 2003 17:02:25 +0100 (BST)
Received: from mailout05.sul.t-online.com ([IPv6:::ffff:194.25.134.82]:59530
	"EHLO mailout05.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225229AbTGXQCW>; Thu, 24 Jul 2003 17:02:22 +0100
Received: from fwd07.aul.t-online.de 
	by mailout05.sul.t-online.com with smtp 
	id 19fiXp-0007lU-01; Thu, 24 Jul 2003 18:02:17 +0200
Received: from denx.de (bj63HwZaweFLkF6sHHpWhlIdQdIJHypYnh6mVp+ddTa7+we+T0RRsw@[217.235.209.91]) by fmrl07.sul.t-online.com
	with esmtp id 19fiXl-1JQwzI0; Thu, 24 Jul 2003 18:02:13 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 0D89442E1C; Thu, 24 Jul 2003 18:02:11 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 06AC4C602D; Thu, 24 Jul 2003 18:02:10 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 04BD9C602C; Thu, 24 Jul 2003 18:02:10 +0200 (MEST)
To: Joe George <joeg@clearcore.com>
Cc: David Kesselring <dkesselr@mmc.atmel.com>,
	linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: boot requirements 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Thu, 24 Jul 2003 09:50:31 MDT."
             <3F200047.2050506@clearcore.com> 
Date: Thu, 24 Jul 2003 18:02:04 +0200
Message-Id: <20030724160210.06AC4C602D@atlas.denx.de>
X-Seen: false
X-ID: bj63HwZaweFLkF6sHHpWhlIdQdIJHypYnh6mVp+ddTa7+we+T0RRsw@t-dialin.net
Return-Path: <wd@denx.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: 2904
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

In message <3F200047.2050506@clearcore.com> you wrote:
> 
> I found it easier to port Linux to my board than
> Yamon.  But I guess it probably depends a lot on
> the kind of port.

It depends on what you want or need to do. Capabilities like  booting
over  the  network  or  storing  configuration  parameters or command
sequences can be extremely useful features of a boot loader.

We use U-Boot on a couple of MIPS boards.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
One possible reason that things aren't going  according  to  plan  is
that there never was a plan in the first place.

From lyle@zevion.com Thu Jul 24 17:32:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jul 2003 17:32:42 +0100 (BST)
Received: from host31.ipowerweb.com ([IPv6:::ffff:12.129.198.131]:7400 "EHLO
	host31.ipowerweb.com") by linux-mips.org with ESMTP
	id <S8225229AbTGXQck>; Thu, 24 Jul 2003 17:32:40 +0100
Received: from rrcs-central-24-123-115-42.biz.rr.com ([24.123.115.42] helo=radium)
	by host31.ipowerweb.com with esmtp (Exim 3.36 #1)
	id 19fj15-0000Fl-00; Thu, 24 Jul 2003 09:32:31 -0700
From: "Lyle Bainbridge" <lyle@zevion.com>
To: "'David Kesselring'" <dkesselr@mmc.atmel.com>,
	<linux-mips@linux-mips.org>
Subject: RE: boot requirements
Date: Thu, 24 Jul 2003 11:32:28 -0500
Message-ID: <000001c35201$2dbcd1e0$2a737b18@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: <Pine.GSO.4.44.0307241019450.23101-100000@ares.mmc.atmel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host31.ipowerweb.com
X-AntiAbuse: Original Domain - linux-mips.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - zevion.com
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: 2905
X-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,

Creating a simple boot loader:

Well firstly, you'll need to at least implement some
initialization code specific to your processor. Typically
for MIPS this would involve initializing CP0, the cache
and TLB. Then perhaps some peripheral initialization such
as clocks, static memory and SDRAM controllers.  Then the
stack pointer needs to be set to a suitable location
being carefull to word align.

Ok, well that's just the reset code for your processor.
What you need to fo for the Linux kernel depends on where it
is stored and whether it is compressed. Loading from a disk
requires a slightly less than trivial bootloader. For the
sake of discussion I'll assume the kernel is located in flash:

For compressed kernel in flash with ELF header:
  a. Uncompress the kernel to RAM.
  b. Read the ELF header to determine layout of sections
     and kernel entry point.
  c. Copy sections to memory as specified in ELF header.
  d. Jump to kernel entry point.
  e. Kernel does the rest :)

If the kernel is not compress then obviously this step can
be skipped. This is a pretty minimal boot loader and easy
to implement.

> I am trying to determine what has to be included in our boot 
> code to start linux. I didn't think I needed to port yamon. 
> What does yamon or pmon provide for starting or 
> debugging(gdb) linux? Does the processor need to be in a 
> specific state or context before jumping from the boot code 
> to the linux downloaded image? If someone can point me to a 
> simple example, I would greatly appreciate it.
> 
> David Kesselring
> Atmel MMC
> dkesselr@mmc.atmel.com
> 919-462-6587
> 


From jsun@mvista.com Thu Jul 24 18:15:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jul 2003 18:15:44 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57074 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225229AbTGXRPm>;
	Thu, 24 Jul 2003 18:15:42 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6OHFZS23215;
	Thu, 24 Jul 2003 10:15:35 -0700
Date: Thu, 24 Jul 2003 10:15:35 -0700
From: Jun Sun <jsun@mvista.com>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: boot requirements
Message-ID: <20030724101535.C19920@mvista.com>
References: <Pine.GSO.4.44.0307241019450.23101-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.44.0307241019450.23101-100000@ares.mmc.atmel.com>; from dkesselr@mmc.atmel.com on Thu, Jul 24, 2003 at 10:27:16AM -0400
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2906
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jul 24, 2003 at 10:27:16AM -0400, David Kesselring wrote:
> I am trying to determine what has to be included in our boot code to start
> linux. I didn't think I needed to port yamon. What does yamon or pmon
> provide for starting or debugging(gdb) linux? Does the processor need to
> be in a specific state or context before jumping from the boot code to the
> linux downloaded image? If someone can point me to a simple example, I
> would greatly appreciate it.
>

This is a good question.  I am listing what I can think of on top of my
head.  Some items might be missing:

. cold initialize board
. RAM should be ready
. kernel binary is in place
. cache is consistent.
. any kernel command line args are set up (set prom_init() for the 
  "protocol")
. Normally you would enable cache, and jump to the KSEG0 kernel_entry.
  (I have seen exceptions, in which case you need to modified a little
   in kernel)
. Obviously CPU is setup in kernel mode and a few configs are setup correctly
  (such as data path width, timing, etc).  Interrupt should be
  turned off.
 
All the rest bootloader work are negotiable between the linux kernel
and bootloader.  For example, if bootloader assigns PCI resources,
then kenel can skip pci_auto.  In other words, beyond the above
minimum requirement, other bootloader work _can_ be done in Linux board
setup routine.

Jun

From dkesselr@mmc.atmel.com Thu Jul 24 18:28:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jul 2003 18:28:39 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:6925
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225229AbTGXR2h>; Thu, 24 Jul 2003 18:28:37 +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 NAA18827
	for <linux-mips@linux-mips.org>; Thu, 24 Jul 2003 13:28:31 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id NAA23334
	for <linux-mips@linux-mips.org>; Thu, 24 Jul 2003 13:28:30 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 24 Jul 2003 13:28:30 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: boot requirements
Message-ID: <Pine.GSO.4.44.0307241327010.23101-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: 2907
X-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

I'm getting the idea of what has to happen. Thanks for your comments.

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


From Teresat@tridentmicro.com Fri Jul 25 04:27:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jul 2003 04:27:27 +0100 (BST)
Received: from [IPv6:::ffff:66.121.16.190] ([IPv6:::ffff:66.121.16.190]:9028
	"EHLO trid-mail1.tridentmicro.com") by linux-mips.org with ESMTP
	id <S8225072AbTGYD1Z> convert rfc822-to-8bit; Fri, 25 Jul 2003 04:27:25 +0100
content-class: urn:content-classes:message
Subject: mmap'ed memory cacheable or uncheable
Date: Thu, 24 Jul 2003 20:26:59 -0700
Message-ID: <61F6477DE6BED311B69F009027C3F58403AA3969@EXCHANGE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 8BIT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: mmap'ed memory cacheable or uncheable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcNSXKiReSC929WDTXmK/JHbWFx90w==
From: "Teresa Tao" <Teresat@tridentmicro.com>
To: <linux-mips@linux-mips.org>
Return-Path: <Teresat@tridentmicro.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: 2908
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Teresat@tridentmicro.com
Precedence: bulk
X-list: linux-mips

Hi there,

I got a question regarding the mmap'ed memory. Is the mmap'ed memory cacheable or uncheable? My driver just use the remap_page_range to map a reserved physical memory.

Thanks in advance!

Teresa

From yuasa@hh.iij4u.or.jp Fri Jul 25 07:47:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jul 2003 07:47:51 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:26562 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225072AbTGYGrq>;
	Fri, 25 Jul 2003 07:47:46 +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 PAA02234;
	Fri, 25 Jul 2003 15:47:36 +0900 (JST)
Received: 4UMDO00 id h6P6laP14612; Fri, 25 Jul 2003 15:47:36 +0900 (JST)
Received: 4UMRO00 id h6P6lYD12445; Fri, 25 Jul 2003 15:47:35 +0900 (JST)
	from pudding.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Fri, 25 Jul 2003 15:47:35 +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]  IDE common routine for VR41xx
Message-Id: <20030725154735.40697dca.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Fri__25_Jul_2003_15:47:35_+0900_0861d1f0"
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: 2909
X-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__25_Jul_2003_15:47:35_+0900_0861d1f0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I made a patch about IDE common routine for NEC VR41xx.

Please apply this patch to v2.4 CVS tree.

Yoichi

--Multipart_Fri__25_Jul_2003_15:47:35_+0900_0861d1f0
Content-Type: text/plain;
 name="vr41xx-ide.diff"
Content-Disposition: attachment;
 filename="vr41xx-ide.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/Makefile linux/arch/mips/vr41xx/casio-e55/Makefile
--- linux.orig/arch/mips/vr41xx/casio-e55/Makefile	Wed Nov 13 19:00:14 2002
+++ linux/arch/mips/vr41xx/casio-e55/Makefile	Fri Jul 25 12:25:24 2003
@@ -14,6 +14,4 @@
 
 obj-y	:= init.o setup.o
 
-obj-$(CONFIG_IDE)	+= ide-e55.o
-
 include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/ide-e55.c linux/arch/mips/vr41xx/casio-e55/ide-e55.c
--- linux.orig/arch/mips/vr41xx/casio-e55/ide-e55.c	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/casio-e55/ide-e55.c	Thu Jan  1 09:00:00 1970
@@ -1,99 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations
- * for the CASIO CASSIOPEIA E-55/65.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Sun, 24 Feb 2002
- *  - Added CASIO CASSIOPEIA E-55/65 support.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int e55_ide_default_irq(ide_ioreg_t base)
-{
-	return 40;
-}
-
-static ide_ioreg_t e55_ide_default_io_base(int index)
-{
-	switch (index) {
-		case 0: return 0xc1f0;
-		case 1: return 0xc170;
-		case 2: return 0xc1e8;
-		case 3: return 0xc168;
-		case 4: return 0xc1e0;
-		case 5: return 0xc160;
-	}
-	return 0;
-}
-
-static void e55_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                    ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int e55_ide_request_irq(unsigned int irq,
-                               void (*handler)(int,void *, struct pt_regs *),
-                               unsigned long flags, const char *device,
-                               void *dev_id)
-{
-	return request_irq(irq, handler, flags, device, dev_id);
-}			
-
-static void e55_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int e55_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void e55_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                   const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void e55_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops e55_ide_ops = {
-	&e55_ide_default_irq,
-	&e55_ide_default_io_base,
-	&e55_ide_init_hwif_ports,
-	&e55_ide_request_irq,
-	&e55_ide_free_irq,
-	&e55_ide_check_region,
-	&e55_ide_request_region,
-	&e55_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Fri Jul 25 12:25:25 2003
@@ -28,10 +28,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops e55_ide_ops;
-#endif
-
 void __init casio_e55_setup(void)
 {
 	set_io_port_base(IO_PORT_BASE);
@@ -57,8 +53,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &e55_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/Makefile linux/arch/mips/vr41xx/common/Makefile
--- linux.orig/arch/mips/vr41xx/common/Makefile	Thu Dec 12 10:10:09 2002
+++ linux/arch/mips/vr41xx/common/Makefile	Fri Jul 25 12:25:25 2003
@@ -20,5 +20,6 @@
 obj-$(CONFIG_SERIAL)		+= serial.o
 obj-$(CONFIG_VR41XX_TIME_C)	+= time.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
+obj-$(subst m,y,$(CONFIG_IDE))	+= ide.o
 
 include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/ide.c linux/arch/mips/vr41xx/common/ide.c
--- linux.orig/arch/mips/vr41xx/common/ide.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/common/ide.c	Fri Jul 25 14:31:32 2003
@@ -0,0 +1,50 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * IDE routines for NEC VR4100 series standard configurations.
+ *
+ * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
+ * Copyright (C) 2003 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ */
+#include <linux/hdreg.h>
+#include <linux/ide.h>
+
+#include <asm/hdreg.h>
+
+static int vr41xx_ide_default_irq(ide_ioreg_t base)
+{
+	return 0;
+}
+
+static ide_ioreg_t vr41xx_ide_default_io_base(int index)
+{
+	return 0;
+}
+
+static void vr41xx_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
+                                       ide_ioreg_t ctrl_port, int *irq)
+{
+	ide_ioreg_t reg = data_port;
+	int i;
+
+	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
+		hw->io_ports[i] = reg;
+		reg += 1;
+	}
+	if (ctrl_port) {
+		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
+	} else {
+		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
+	}
+	if (irq != NULL)
+		*irq = 0;
+	hw->io_ports[IDE_IRQ_OFFSET] = 0;
+}
+
+struct ide_ops vr41xx_ide_ops = {
+	.ide_default_irq	= &vr41xx_ide_default_irq,
+	.ide_default_io_base	= &vr41xx_ide_default_io_base,
+	.ide_init_hwif_ports	= &vr41xx_ide_init_hwif_ports
+};
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 Nov 13 19:00:14 2002
+++ linux/arch/mips/vr41xx/ibm-workpad/Makefile	Fri Jul 25 12:25:25 2003
@@ -14,6 +14,4 @@
 
 obj-y	:= init.o setup.o
 
-obj-$(CONFIG_IDE)	+= ide-workpad.o
-
 include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/ide-workpad.c linux/arch/mips/vr41xx/ibm-workpad/ide-workpad.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/ide-workpad.c	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/ibm-workpad/ide-workpad.c	Thu Jan  1 09:00:00 1970
@@ -1,98 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations for the IBM WorkPad z50.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Sun, 24 Feb 2002
- *  - Added IBM WorkPad z50 support.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int workpad_ide_default_irq(ide_ioreg_t base)
-{
-	return 49;
-}
-
-static ide_ioreg_t workpad_ide_default_io_base(int index)
-{
-	switch (index) {
-		case 0: return 0x1f0;
-		case 1: return 0x170;
-		case 2: return 0x1e8;
-		case 3: return 0x168;
-		case 4: return 0x1e0;
-		case 5: return 0x160;
-	}
-	return 0;
-}
-
-static void workpad_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                        ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int workpad_ide_request_irq(unsigned int irq,
-                                   void (*handler)(int,void *, struct pt_regs *),
-                                   unsigned long flags, const char *device,
-                                   void *dev_id)
-{
-	return request_irq(irq, handler, SA_SHIRQ, device, dev_id);
-}			
-
-static void workpad_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int workpad_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void workpad_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                       const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void workpad_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops workpad_ide_ops = {
-	&workpad_ide_default_irq,
-	&workpad_ide_default_io_base,
-	&workpad_ide_init_hwif_ports,
-	&workpad_ide_request_irq,
-	&workpad_ide_free_irq,
-	&workpad_ide_check_region,
-	&workpad_ide_request_region,
-	&workpad_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Fri Jul 25 12:25:25 2003
@@ -28,10 +28,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops workpad_ide_ops;
-#endif
-
 void __init ibm_workpad_setup(void)
 {
 	set_io_port_base(IO_PORT_BASE);
@@ -57,8 +53,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &workpad_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/Makefile linux/arch/mips/vr41xx/nec-eagle/Makefile
--- linux.orig/arch/mips/vr41xx/nec-eagle/Makefile	Thu Dec 12 10:10:09 2002
+++ linux/arch/mips/vr41xx/nec-eagle/Makefile	Fri Jul 25 12:25:25 2003
@@ -19,7 +19,6 @@
 
 obj-y	:= init.o irq.o setup.o
 
-obj-$(CONFIG_IDE)	+= ide-eagle.o
 obj-$(CONFIG_PCI)	+= pci_fixup.o vrc4173.o
 
 include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/ide-eagle.c linux/arch/mips/vr41xx/nec-eagle/ide-eagle.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/ide-eagle.c	Tue Aug  6 08:53:36 2002
+++ linux/arch/mips/vr41xx/nec-eagle/ide-eagle.c	Thu Jan  1 09:00:00 1970
@@ -1,96 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations
- * for the NEC Eagle/Hawk board.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  Fri,  5 Apr 2002
- *  - Added support for NEC Hawk.
- *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  Fri,  1 Mar 2002
- *  - Added support for NEC Eagle.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int eagle_ide_default_irq(ide_ioreg_t base)
-{
-	return 0;
-}
-
-static ide_ioreg_t eagle_ide_default_io_base(int index)
-{
-	return 0;
-}
-
-static void eagle_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                      ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int eagle_ide_request_irq(unsigned int irq,
-                                 void (*handler)(int,void *, struct pt_regs *),
-                                 unsigned long flags, const char *device,
-                                 void *dev_id)
-{
-	return request_irq(irq, handler, SA_SHIRQ, device, dev_id);
-}
-
-static void eagle_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int eagle_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void eagle_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                     const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void eagle_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops eagle_ide_ops = {
-	&eagle_ide_default_irq,
-	&eagle_ide_default_io_base,
-	&eagle_ide_init_hwif_ports,
-	&eagle_ide_request_irq,
-	&eagle_ide_free_irq,
-	&eagle_ide_check_region,
-	&eagle_ide_request_region,
-	&eagle_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Thu Dec 12 10:10:09 2002
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Fri Jul 25 12:25:25 2003
@@ -55,10 +55,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops eagle_ide_ops;
-#endif
-
 extern void eagle_irq_init(void);
 
 #ifdef CONFIG_PCI
@@ -138,8 +134,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &eagle_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Tue Feb  4 21:43:06 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Fri Jul 25 12:25:25 2003
@@ -16,7 +16,6 @@
 #include <linux/config.h>
 #include <linux/init.h>
 #include <linux/console.h>
-#include <linux/ide.h>
 #include <linux/ioport.h>
 
 #include <asm/pci_channel.h>
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	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/victor-mpc30x/Makefile	Fri Jul 25 12:25:25 2003
@@ -14,7 +14,6 @@
 
 obj-y	:= init.o setup.o
 
-obj-$(CONFIG_IDE)	+= ide-mpc30x.o
 obj-$(CONFIG_PCI)	+= pci_fixup.o
 
 include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c linux/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c	Thu Jan  1 09:00:00 1970
@@ -1,91 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations
- * for the ZAO Networks Capcella.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Fri, 23 Aug 2002
- *  - Added Victor MP-C303/304 support.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int mpc30x_ide_default_irq(ide_ioreg_t base)
-{
-	return 0;
-}
-
-static ide_ioreg_t mpc30x_ide_default_io_base(int index)
-{
-	return 0;
-}
-
-static void mpc30x_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                       ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int mpc30x_ide_request_irq(unsigned int irq,
-                                  void (*handler)(int,void *, struct pt_regs *),
-                                  unsigned long flags, const char *device,
-                                  void *dev_id)
-{
-	return request_irq(irq, handler, flags, device, dev_id);
-}
-
-static void mpc30x_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int mpc30x_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void mpc30x_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                      const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void mpc30x_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops mpc30x_ide_ops = {
-	&mpc30x_ide_default_irq,
-	&mpc30x_ide_default_io_base,
-	&mpc30x_ide_init_hwif_ports,
-	&mpc30x_ide_request_irq,
-	&mpc30x_ide_free_irq,
-	&mpc30x_ide_check_region,
-	&mpc30x_ide_request_region,
-	&mpc30x_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Fri Jul 25 12:25:25 2003
@@ -29,10 +29,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops mpc30x_ide_ops;
-#endif
-
 #ifdef CONFIG_PCI
 static struct resource vr41xx_pci_io_resource = {
 	"PCI I/O space",
@@ -105,8 +101,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &mpc30x_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/Makefile linux/arch/mips/vr41xx/zao-capcella/Makefile
--- linux.orig/arch/mips/vr41xx/zao-capcella/Makefile	Mon Jul 15 09:02:56 2002
+++ linux/arch/mips/vr41xx/zao-capcella/Makefile	Fri Jul 25 12:25:25 2003
@@ -14,7 +14,6 @@
 
 obj-y	:= init.o setup.o
 
-obj-$(CONFIG_IDE)	+= ide-capcella.o
 obj-$(CONFIG_PCI)	+= pci_fixup.o
 
 include $(TOPDIR)/Rules.make
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/ide-capcella.c linux/arch/mips/vr41xx/zao-capcella/ide-capcella.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/ide-capcella.c	Tue Aug  6 08:53:36 2002
+++ linux/arch/mips/vr41xx/zao-capcella/ide-capcella.c	Thu Jan  1 09:00:00 1970
@@ -1,99 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations
- * for the ZAO Networks Capcella.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Sun, 24 Feb 2002
- *  - Added ZAO Networks Capcella support.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int capcella_ide_default_irq(ide_ioreg_t base)
-{
-	switch (base) {
-	case 0x8300: return 42;
-	}
-
-	return 0;
-}
-
-static ide_ioreg_t capcella_ide_default_io_base(int index)
-{
-	switch (index) {
-	case 0: return 0x8300;
-	}
-
-	return 0;
-}
-
-static void capcella_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                         ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int capcella_ide_request_irq(unsigned int irq,
-                                    void (*handler)(int,void *, struct pt_regs *),
-                                    unsigned long flags, const char *device,
-                                    void *dev_id)
-{
-	return request_irq(irq, handler, flags, device, dev_id);
-}
-
-static void capcella_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int capcella_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void capcella_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                        const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void capcella_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops capcella_ide_ops = {
-	&capcella_ide_default_irq,
-	&capcella_ide_default_io_base,
-	&capcella_ide_init_hwif_ports,
-	&capcella_ide_request_irq,
-	&capcella_ide_free_irq,
-	&capcella_ide_check_region,
-	&capcella_ide_request_region,
-	&capcella_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Fri Jul 25 12:25:25 2003
@@ -29,10 +29,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops capcella_ide_ops;
-#endif
-
 #ifdef CONFIG_PCI
 static struct resource vr41xx_pci_io_resource = {
 	"PCI I/O space",
@@ -105,8 +101,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &capcella_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Thu Mar 20 10:48:19 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Fri Jul 25 14:51:18 2003
@@ -189,4 +189,8 @@
 extern void vr41xx_halt(void);
 extern void vr41xx_power_off(void);
 
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+extern struct ide_ops vr41xx_ide_ops;
+#endif
+
 #endif /* __NEC_VR41XX_H */

--Multipart_Fri__25_Jul_2003_15:47:35_+0900_0861d1f0--

From yuasa@hh.iij4u.or.jp Fri Jul 25 09:35:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jul 2003 09:35:57 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:18141 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225072AbTGYIfz>;
	Fri, 25 Jul 2003 09:35:55 +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 RAA22264;
	Fri, 25 Jul 2003 17:35:51 +0900 (JST)
Received: 4UMDO00 id h6P8ZpR15544; Fri, 25 Jul 2003 17:35:51 +0900 (JST)
Received: 4UMRO01 id h6P8Zo427868; Fri, 25 Jul 2003 17:35:50 +0900 (JST)
	from pudding.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Fri, 25 Jul 2003 17:35:51 +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] wrong value definition about IBM WorkPad
Message-Id: <20030725173551.628f5bcb.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Fri__25_Jul_2003_17:35:51_+0900_08517000"
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: 2910
X-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__25_Jul_2003_17:35:51_+0900_08517000
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I made a patch for wrong value definition about IBM WorkPad.

Please apply these patches to v2.4 and v2.6 CVS tree.

Yoichi

--Multipart_Fri__25_Jul_2003_17:35:51_+0900_08517000
Content-Type: text/plain;
 name="workpad-v24.diff"
Content-Disposition: attachment;
 filename="workpad-v24.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/workpad.h linux/include/asm-mips/vr41xx/workpad.h
--- linux.orig/include/asm-mips/vr41xx/workpad.h	Fri Oct  4 01:58:02 2002
+++ linux/include/asm-mips/vr41xx/workpad.h	Fri Jul 25 15:10:10 2003
@@ -22,7 +22,7 @@
 /*
  * Board specific address mapping
  */
-#define VR41XX_ISA_MEM_BASE		0x100000000
+#define VR41XX_ISA_MEM_BASE		0x10000000
 #define VR41XX_ISA_MEM_SIZE		0x04000000
 
 /* VR41XX_ISA_IO_BASE includes offset from real base. */

--Multipart_Fri__25_Jul_2003_17:35:51_+0900_08517000
Content-Type: text/plain;
 name="workpad-v26.diff"
Content-Disposition: attachment;
 filename="workpad-v26.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/workpad.h linux/include/asm-mips/vr41xx/workpad.h
--- linux.orig/include/asm-mips/vr41xx/workpad.h	Fri Oct  4 01:57:50 2002
+++ linux/include/asm-mips/vr41xx/workpad.h	Fri Jul 25 17:26:10 2003
@@ -22,7 +22,7 @@
 /*
  * Board specific address mapping
  */
-#define VR41XX_ISA_MEM_BASE		0x100000000
+#define VR41XX_ISA_MEM_BASE		0x10000000
 #define VR41XX_ISA_MEM_SIZE		0x04000000
 
 /* VR41XX_ISA_IO_BASE includes offset from real base. */

--Multipart_Fri__25_Jul_2003_17:35:51_+0900_08517000--

From rahul.pande@wipro.com Fri Jul 25 10:30:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jul 2003 10:30:23 +0100 (BST)
Received: from wiprom2mx1.wipro.com ([IPv6:::ffff:203.197.164.41]:58621 "EHLO
	wiprom2mx1.wipro.com") by linux-mips.org with ESMTP
	id <S8225072AbTGYJaV>; Fri, 25 Jul 2003 10:30:21 +0100
Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5])
	by wiprom2mx1.wipro.com (8.12.9/8.12.9) with SMTP id h6P9PjxX000399
	for <linux-mips@linux-mips.org>; Fri, 25 Jul 2003 14:56:04 +0530 (IST)
Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 25 Jul 2003 14:55:44 +0530
Received: from wipro.com ([10.114.5.253]) by blr-m3-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 25 Jul 2003 14:55:42 +0530
Message-ID: <3F20F795.464D14EB@wipro.com>
Date: Fri, 25 Jul 2003 14:55:41 +0530
From: Rahul Pande <rahul.pande@wipro.com>
Reply-To: rahul.pande@wipro.com
Organization: WIPRO
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: MIPS <linux-mips@linux-mips.org>
Subject: pthread issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jul 2003 09:25:42.0110 (UTC) FILETIME=[B7ECF7E0:01C3528E]
Return-Path: <rahul.pande@wipro.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: 2911
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rahul.pande@wipro.com
Precedence: bulk
X-list: linux-mips

Hi,

    I am trying to run a pthread based application on the AMD au1500
mips processor for linux version 2.4.21pre. The pthread_create function
does not return, i am attaching the strace of the process, where
pthread_create() is the call after the write statement "Creating a
thread". The thread seems to go into a sigsuspend mode after doing a
clone() and it never seems to return from there and so the thread
creation operation does not complete.

    Are there any patches that i need to apply or Are there any specific
define flags to be enabled for compilation. Please let me know if i can
run thread applications on mips.

Thanks and Regards,
          rahul





write(1, "Creating a thread\n", 18Creating a thread
)     = 18
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) =
0
setrlimit(RLIMIT_STACK, {rlim_cur=2044*1024, rlim_max=RLIM_INFINITY}) =
0
brk(0x10003000)                         = 0x10003000
pipe([721840640, 4230684])              = 4
clone(child_stack=0x100027a8,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND)
 = 385
[pid   384] write(5, "\200\373\363*\5\0\0\0\0\0\0\0\377\377\377\377
y\377\177"..
., 148 <unfinished ...>
[pid   385] rt_sigprocmask(SIG_SETMASK, ~[TRAP 33],  <unfinished ...>
[pid   384] <... write resumed> )       = 148
[pid   385] <... rt_sigprocmask resumed> NULL, 16) = 0
[pid   384] rt_sigprocmask(SIG_SETMASK, NULL,  <unfinished ...>
[pid   385] read(4,  <unfinished ...>
[pid   384] <... rt_sigprocmask resumed> [32], 16) = 0
[pid   385] <... read resumed>
"\200\373\363*\5\0\0\0\0\0\0\0\377\377\377\377 y\
377\177"..., 148) = 148
[pid   384] write(5,
"\300\235\272*\0\0\0\0\0\0\0\0\244|\265*\260\345\300*\0"...
, 148 <unfinished ...>
[pid   385] poll( <unfinished ...>
[pid   384] <... write resumed> )       = 148
[pid   385] <... poll resumed> [{fd=4, events=POLLIN, revents=POLLIN}],
1, 2000)
 = 1
[pid   384] rt_sigprocmask(SIG_SETMASK, NULL,  <unfinished ...>
[pid   385] getppid( <unfinished ...>
[pid   384] <... rt_sigprocmask resumed> [32], 16) = 0
[pid   385] <... getppid resumed> )     = 384
[pid   384] sigsuspend(~[HUP INT QUIT TRAP IOT EMT FPE KILL SEGV USR1]
<unfinish
ed ...>
[pid   385] read(4,
"\300\235\272*\0\0\0\0\0\0\0\0\244|\265*\260\345\300*\0"...,
 148) = 148
[pid   385] old_mmap(0x7f600000, 2097152,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PR
IVATE|MAP_ANONYMOUS, -1, 0) = 0x7f600000
[pid   385] mprotect(0x7f600000, 4096, PROT_NONE) = 0
[pid   385] clone(child_stack=0x7f7ffbe0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CL
ONE_SIGHAND|0x21) = 386
[pid   386] getpid()                    = 386
[pid   386] rt_sigprocmask(SIG_SETMASK, [32], NULL, 16) = 0
[pid   386] rt_sigprocmask(SIG_SETMASK, NULL, [32], 16) = 0
[pid   386] sigsuspend(~[HUP INT QUIT ILL IOT BUS SEGV TSTP] <unfinished
...>
[pid   385] kill(383, SIGRT_0)          = -1 ESRCH (No such process)
[pid   385] poll([{fd=4, events=POLLIN}], 1, 2000) = 0
[pid   385] getppid()                   = 384
[pid   385] poll( <unfinished ...>


From Foerstemann@web.de Fri Jul 25 22:37:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jul 2003 22:37:17 +0100 (BST)
Received: from mailgate5.cinetic.de ([IPv6:::ffff:217.72.192.165]:22181 "EHLO
	mailgate5.cinetic.de") by linux-mips.org with ESMTP
	id <S8225209AbTGYVhN>; Fri, 25 Jul 2003 22:37:13 +0100
Received: from web.de (fmomail03.dlan.cinetic.de [172.20.1.236])
	by mailgate5.cinetic.de (8.11.6p2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id h6PLb6Q01329
	for linux-mips@linux-mips.org; Fri, 25 Jul 2003 23:37:06 +0200
Date: Fri, 25 Jul 2003 23:37:06 +0200
Message-Id: <200307252137.h6PLb6Q01329@mailgate5.cinetic.de>
MIME-Version: 1.0
Organization: http://freemail.web.de/
From: =?iso-8859-1?Q? "Frank=20F=F6rstemann" ?= <Foerstemann@web.de>
To: linux-mips@linux-mips.org
Subject: No mouse support for Indy in 2.5.75 ?
Precedence: fm-user
Content-Type: multipart/mixed; boundary="STEFAN3f21a302758c"
Return-Path: <Foerstemann@web.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: 2912
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Foerstemann@web.de
Precedence: bulk
X-list: linux-mips

This is a MIME encoded message.
--STEFAN3f21a302758c
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi.

I tried kernel version 2.5.75 on my Indy. It works fine with the
exception that the mouse in XFree86 does not move. The devices are 
available, but event debugging shows no mouse events at all. Are there
any special configuration options for the Indy mouse except the ones in
the 'input' section ? Dmesg output and kernel configuration are
attached.

Regards

Frank


______________________________________________________________________________
Spam-Filter fuer alle - bester Spam-Schutz laut ComputerBild 15-03
WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021120
--STEFAN3f21a302758c
Content-Type: application/gzip; name="dmesg.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="dmesg.gz"

H4sICH8aHj8AA2RtZXNnALVXW2/iSBZ+96840j40SFzKN2KsSau5JBMmIWED6UTbilplu4Ba
jO2xywT61885ZSDJDt3qnZ3lwdjlc6rO/fvcux9c+TD9ddQcTSzLmNzfjW9GfR969wOYy3z9
wnMBn0VeyDQBE+7FRla3zBhMHiA/PMvCB0Y/x2XG5ck3LmPGJJdrnu9AJoXKy1CRQMjDpQCz
s+o3IFvuChnyON6B4ouFiBoQyVyECtY8y+gxloko5DdSgGCnRNE6bhpxxd/s9hOaD4mcSxFB
IcI0iWiPvTqznB9tYHmHHW5kUm5hsw+Q1XJbZy7U5vP00yiJdnWoLcLwzeuu23LAYsw0GbOg
NhSB5AlkuchFLHgh6nX4h8ngEW36rYzBsjF0PjN95sHgYjojVdsY8OSDAp7weIfGZHkap4tS
QJhGArgCz2O2azPPGA90ZmEt1im5liYKZWORv6bR1kKTPA1ksngjOJeLMueUHt+AgCcr5pPX
Y/gEzNPZZNW6eVw32X59KJTI1xir6JhOuO+NKYy4WXWGfxR/syPUyoIHsagbdwkk5A0DlSoe
Z3whsIq6ns0cA2A47sG3NBH7FdCvG3AzurxDm1S49M0Oit2m+RqPriTZKSkUupKL5VisfyjV
L2UcUXxIKJaFgnmaVwaiinEtclzGqK3XPIl0lfiQp6k6b0di0y4ibgIvVWpMRkNY8mKJpY1e
gsB0SPLLYo4HtTSPMDMmBbRje05VYHVMdiwDSgWeX+wKhbYquRZ5q9WCM5ei9sV0WUvHb3z1
DbArn43bX3GbY5I7DbBwP6mymCfk3f3Fk/3aoNh2nwfW63OvAVvMVffdSogrrwuDBgTKcdzX
lWF15jTMhUiqJsEe2p51PGOQJkUaY0xCLNQy1yV5K16yNFdUO1vHe+dkJGK+gzhNM+2i03K6
0E8X6Xg0mRrjffVYrsvOrFXb6lim46yAb7iMdVRrZtfprGB1SEokGtA5M60V2lqIfEON7Hoo
QdOiAR4qy0SqBrAVLLEYsD7rWMKYm8MwOJWyjuvanX3OfB1gbcghaSMqjub31W0LA3NUdxtg
2ib6c1Afp2WifqDumtZRmTXAYd3OQbX5EajqDv/tsAq+fqaaNAZLEa4ozlTDH164VB/eTmOK
OZTJMZ44Xe+moyc9E6ifklAAHqQzFezg4XZ0OXpCf6WSmMNvtHw/g0QobIMVFGm4Esroj+58
yNI0hnSOqevgvFVlhl471wHU3L3x7UCmdQMvGxFq6S/s2QdA1AlwhfoEJfcxwDQfo/VWw9Qa
zkkNxzulYZEGIcKpM7onD7FJpXP6EMrrCRXn2a9Q49QpVEondNznSvCUjv2mWqaD6QiKMthP
B3nIhYiMTO0qRQS6bdcDfC6O4x3fD6doVAcnBc7JGU4VGMSYMRjmEiELNmaLGb9hyyLSxDjN
+9VLbHksgqiSiVMe4UbvCmCQ7zKVLnKeLWUIvcnIuOJ5pJnEI43UKF3o03JdgzQOiHtgKbcs
Yypy3MfXK/Avich2OKlmQriUWVFvGUrt2oygbjwe3QHbInLI/Hc4B8etI98ArtWbWl0Lmz8r
XCxkIcTvrdCHId/ICKYtGEuNmbVo/Ukki7yFMi0c9nVDqCWrEHaKOghiiNaej4Dd6SJg+27k
87nxEtl22LWbKEnmnz8O9XO/bdoIIV+LXRKes+18Tg/Rmp8zHIBBufg6j/miwDcEtK8/3Thf
eY6vGoff2/dHptayOtAEy2pfiqBNrKEBg3SdyfjALCzNJSguGHrbJsgswkIyqDx6HHZtgydK
hjLjilhBgdMoKmNKMHKVDS0aaE+ikXE6nN0DM5nNTHvOQvLq63Yu8nMr/MX9SHYlUYrTatQf
7y0d44TEPA8HvWnTdmybHVxA2EITOm4P/ZrtMkENPdRErNkLQ1EUcPLXu8Uu0K1wwCQsKOu/
t/CfD73b2cP41cLL0f1Fv3dz83U2xmZh072FNmNPf4uFhfKPaaOUsI5lNZB7bzFTQTnXWKrx
ogFFGzmAWBTU0lXbR1UzIsfwEco6Z7gBoUOTRgMso5ecqC1misafbbsw7tf/rKgbrAI7H8sw
EUa1rpkLXiy62HRx6OIaPaVIGHkzVgyy5GJF61RLuoSQLSx5QvCLt9hDJlLnMkGm9P7kgEYT
sz2cZN8xGeNtnTA5+A+TX3KJqgEPV0b1Fi9keECGB2R44Jy2OfiuzdbB5jWeiQx52rZgnZaF
OJhBdA8zRhMMpyOQmCE95lg0Ox55nmDR+XAtdnpocgTXDYIpMhCZ+qAFoffwBJoFoRFsG8yD
qOs5duN4ewY0qBzHkElWYpX0ZjhosF+R3OyCFEcqoAHLLLSzwmrrndn7A677w5874PZi5vhQ
fcvMBpP2aIIThGnn6BXCwGhCnLbUuP8nYoKoXnGQkuAeCaZtXWtwMnAzH66Okm/BB2pII3BR
FpSVihHhV8j+tr63iYALonTNZbJnEwWZ1p6OJ9q8yubKyJax+neFVphlxXMyFtkMzr21VIiL
+FmyQaBz9597hXHxNLObc8TWNREutGKO83EPoy9SLUFzLFzXX5ZrnAct4/Pl1IfxXp4YFfqx
VfYb1Tr2N4/SJN61jEukwxSyMsHSiQ6s9PANRORzjhKR0Yv0kMKCP3ORqhYvyLYxuYcPCBvd
wK/cFAt95zdNwBORChT4bUIuwOWUhKldG5WbGALYh8LQvvlwsQ1Fpr+3sRi+/OJ5pmlz2/v4
DDV9H8xZ/f8m+xfy8uqUdcKpv5K5/8WI4O8y4g9ZjlEOcBEAAA==

--STEFAN3f21a302758c--



From jsun@mvista.com Fri Jul 25 23:02:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jul 2003 23:02:29 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:11249 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225209AbTGYWC1>;
	Fri, 25 Jul 2003 23:02:27 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6PM2OX26421;
	Fri, 25 Jul 2003 15:02:24 -0700
Date: Fri, 25 Jul 2003 15:02:24 -0700
From: Jun Sun <jsun@mvista.com>
To: Teresa Tao <Teresat@tridentmicro.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: mmap'ed memory cacheable or uncheable
Message-ID: <20030725150224.C25784@mvista.com>
References: <61F6477DE6BED311B69F009027C3F58403AA3969@EXCHANGE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <61F6477DE6BED311B69F009027C3F58403AA3969@EXCHANGE>; from Teresat@tridentmicro.com on Thu, Jul 24, 2003 at 08:26:59PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2913
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jul 24, 2003 at 08:26:59PM -0700, Teresa Tao wrote:
> Hi there,
> 
> I got a question regarding the mmap'ed memory. Is the mmap'ed memory cacheable or uncheable? My driver just use the remap_page_range to map a reserved physical memory.
>

I am pretty much sure it is cached, although I can't pin down exactly
where in the mm subsystem it does so - I have had cache bugs related
to mmap().

Jun

From Teresat@tridentmicro.com Fri Jul 25 23:52:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jul 2003 23:53:00 +0100 (BST)
Received: from [IPv6:::ffff:66.121.16.190] ([IPv6:::ffff:66.121.16.190]:12210
	"EHLO trid-mail1.tridentmicro.com") by linux-mips.org with ESMTP
	id <S8225214AbTGYWw6> convert rfc822-to-8bit; Fri, 25 Jul 2003 23:52:58 +0100
content-class: urn:content-classes:message
Subject: RE: mmap'ed memory cacheable or uncheable
Date: Fri, 25 Jul 2003 15:52:33 -0700
Message-ID: <61F6477DE6BED311B69F009027C3F58403AA396F@EXCHANGE>
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: mmap'ed memory cacheable or uncheable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcNS+GFAtXxthcdyRB2ywR1T0NJ4DAABsVlA
From: "Teresa Tao" <Teresat@tridentmicro.com>
To: "Jun Sun" <jsun@mvista.com>,
	"Teresa Tao" <Teresat@tridentmicro.com>
Cc: <linux-mips@linux-mips.org>
Return-Path: <Teresat@tridentmicro.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: 2914
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Teresat@tridentmicro.com
Precedence: bulk
X-list: linux-mips

How about if I specify the following flags in my mmap routine just like what the pgprot_noncached micro did.
	pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
	pgprot_val(vma->vm_page_prot) |= _CACHE_UNCACHED;

Will this have kernel make the mmap'd memory non-cacheable? Or is there a mmap non-cacheable patch?

Thanks in advance!

Teresa



-----Original Message-----
From: Jun Sun [mailto:jsun@mvista.com]
Sent: Friday, July 25, 2003 3:02 PM
To: Teresa Tao
Cc: linux-mips@linux-mips.org; jsun@mvista.com
Subject: Re: mmap'ed memory cacheable or uncheable


On Thu, Jul 24, 2003 at 08:26:59PM -0700, Teresa Tao wrote:
> Hi there,
> 
> I got a question regarding the mmap'ed memory. Is the mmap'ed memory cacheable or uncheable? My driver just use the remap_page_range to map a reserved physical memory.
>

I am pretty much sure it is cached, although I can't pin down exactly
where in the mm subsystem it does so - I have had cache bugs related
to mmap().

Jun

From wjhun@Oswego.EDU Mon Jul 28 20:05:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jul 2003 20:05:12 +0100 (BST)
Received: from oswego.oswego.edu ([IPv6:::ffff:129.3.1.1]:32145 "EHLO
	oswego.oswego.edu") by linux-mips.org with ESMTP
	id <S8225208AbTG1TFJ>; Mon, 28 Jul 2003 20:05:09 +0100
Received: from rocky.oswego.edu (rocky.oswego.edu [129.3.1.36])
	by oswego.oswego.edu (8.12.9+Sun/8.12.9) with ESMTP id h6SJ54aP025198;
	Mon, 28 Jul 2003 15:05:04 -0400 (EDT)
Received: from rocky.oswego.edu (localhost [127.0.0.1])
	by rocky.oswego.edu (8.12.9+Sun/8.12.9) with ESMTP id h6SJ54M7015019;
	Mon, 28 Jul 2003 15:05:04 -0400 (EDT)
Received: from localhost (wjhun@localhost)
	by rocky.oswego.edu (8.12.9+Sun/8.12.9/Submit) with ESMTP id h6SJ536B015014;
	Mon, 28 Jul 2003 15:05:03 -0400 (EDT)
X-Authentication-Warning: rocky.oswego.edu: wjhun owned process doing -bs
Date: Mon, 28 Jul 2003 15:05:03 -0400 (EDT)
From: William Jhun <wjhun@Oswego.EDU>
To: Louis Hamilton <hamilton@redhat.com>
cc: <ralf@linux-mips.org>, <linux-mips@linux-mips.org>
Subject: Re: [patch] Mips64 Ocelot-C and Jaguar ATX platform support
In-Reply-To: <3F1F0BDC.8040609@redhat.com>
Message-ID: <Pine.SOL.4.30.0307281503540.7737-100000@rocky.oswego.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <wjhun@Oswego.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: 2915
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wjhun@Oswego.EDU
Precedence: bulk
X-list: linux-mips

Louis,

Using Ralf's pre-packaged mips64 gcc 2.95.4 / binutils 2.13.2.1 .rpm, I
wasn't able to get this to build without having CPU-specific gcc opts
(patch below, please verify what flags are appropriate). Also, shouldn't

define_bool CONFIG_BOOT_ELF32 y

be in the config-shared.in in the jaguar section? I cannot link
otherwise...

At this point (with latest linux_2_4 tree), I can boot the kernel but get
a hang after mounting NFS root via the gt64340 eth0. If I can find a
serial cable for the second port, I might try to step with kgdb...

Thanks,
Will

Index: arch/mips64/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips64/Makefile,v
retrieving revision 1.22.2.34
diff -U3 -r1.22.2.34 Makefile
--- arch/mips64/Makefile        5 Jul 2003 13:17:04 -0000       1.22.2.34
+++ arch/mips64/Makefile        28 Jul 2003 18:37:47 -0000
@@ -79,6 +79,9 @@
 #CFLAGS                += -mips64      # Should be used then we get a
MIPS64 compiler
 CFLAGS         += -mcpu=r8000 -mips4
 endif
+ifdef CONFIG_CPU_RM9000
+GCCFLAGS       += -mcpu=r8000 -mips4
+endif

 #
 # We unconditionally build the math emulator

On Wed, 23 Jul 2003, Louis Hamilton wrote:

> Ralf,
>
> Here is 64-bit support for both the RM7000-based Ocelot-C and
> RM9000-based Jaguar ATX platforms.
> Since the port was 2.4.21 based, this patch submission is for the 2.4 tree.
> This patch supersedes the Ocelot-C patch I sent earlier, since it
> encompasses both platforms.
>
> Notes the board support lives under arch/mips/momentum.
> Also, CONFIG_BOARD_SCACHE and CONFIG_RM7000_CPU_SCACHE are utilized and
> integrated into each platform's default configuration files.
> As in the first patch, drivers/net/mv64340_eth.{c,h} is added to provide
> ethernet support.
>
> If it looks ok, please check changes into the tree.
>
> Regards,
> Louis
>
> Louis Hamilton
> Red Hat, Inc.
>
>


From hamilton@redhat.com Mon Jul 28 21:18:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jul 2003 21:18:19 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:46094 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225208AbTG1USQ>;
	Mon, 28 Jul 2003 21:18:16 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h6SKI8Z02215;
	Mon, 28 Jul 2003 16:18:08 -0400
Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6SKI7I14165;
	Mon, 28 Jul 2003 16:18:07 -0400
Received: from redhat.com (slurm.hsv.redhat.com [172.16.16.102])
	by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id h6SKI7m20687;
	Mon, 28 Jul 2003 15:18:07 -0500
Message-ID: <3F25857E.1080209@redhat.com>
Date: Mon, 28 Jul 2003 15:20:14 -0500
From: Louis Hamilton <hamilton@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
X-Accept-Language: en-us
MIME-Version: 1.0
To: William Jhun <wjhun@Oswego.EDU>
CC: linux-mips@linux-mips.org
Subject: Re: [patch] Mips64 Ocelot-C and Jaguar ATX platform support
References: <Pine.SOL.4.30.0307281503540.7737-100000@rocky.oswego.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <hamilton@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: 2916
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hamilton@redhat.com
Precedence: bulk
X-list: linux-mips

Will,

William Jhun wrote:

>Louis,
>
>Using Ralf's pre-packaged mips64 gcc 2.95.4 / binutils 2.13.2.1 .rpm, I
>wasn't able to get this to build without having CPU-specific gcc opts
>(patch below, please verify what flags are appropriate). Also, shouldn't
>
Arggh.. my (different) build environment meant messing with options in my
arch/mips64/Makefile  (like using "-march=rm9000" instead of 
"-mcpu=r8000 -mips4").
The CFLAGS change below looks fine.
Btw, an ifdef for CONFIG_CPU_RM7000 will be required too, using the
same CFLAGS options as the rm9000.

>
>define_bool CONFIG_BOOT_ELF32 y
>
>be in the config-shared.in in the jaguar section? 
>
yes

>
>
>At this point (with latest linux_2_4 tree), I can boot the kernel but get
>a hang after mounting NFS root via the gt64340 eth0. If I can find a
>serial cable for the second port, I might try to step with kgdb...
>
>Thanks,
>Will
>
thanks

>
>Index: arch/mips64/Makefile
>===================================================================
>RCS file: /home/cvs/linux/arch/mips64/Makefile,v
>retrieving revision 1.22.2.34
>diff -U3 -r1.22.2.34 Makefile
>--- arch/mips64/Makefile        5 Jul 2003 13:17:04 -0000       1.22.2.34
>+++ arch/mips64/Makefile        28 Jul 2003 18:37:47 -0000
>@@ -79,6 +79,9 @@
> #CFLAGS                += -mips64      # Should be used then we get a
>MIPS64 compiler
> CFLAGS         += -mcpu=r8000 -mips4
> endif
>+ifdef CONFIG_CPU_RM9000
>+GCCFLAGS       += -mcpu=r8000 -mips4
>+endif
>
> #
> # We unconditionally build the math emulator
>
>On Wed, 23 Jul 2003, Louis Hamilton wrote:
>
>>Ralf,
>>
>>Here is 64-bit support for both the RM7000-based Ocelot-C and
>>RM9000-based Jaguar ATX platforms.
>>Since the port was 2.4.21 based, this patch submission is for the 2.4 tree.
>>This patch supersedes the Ocelot-C patch I sent earlier, since it
>>encompasses both platforms.
>>
>>Notes the board support lives under arch/mips/momentum.
>>Also, CONFIG_BOARD_SCACHE and CONFIG_RM7000_CPU_SCACHE are utilized and
>>integrated into each platform's default configuration files.
>>As in the first patch, drivers/net/mv64340_eth.{c,h} is added to provide
>>ethernet support.
>>
>>If it looks ok, please check changes into the tree.
>>
>>Regards,
>>Louis
>>
>>Louis Hamilton
>>Red Hat, Inc.
>>
>>




From jsun@mvista.com Mon Jul 28 22:24:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jul 2003 22:24:09 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:59130 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225208AbTG1VYH>;
	Mon, 28 Jul 2003 22:24:07 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6SLO1h17925;
	Mon, 28 Jul 2003 14:24:01 -0700
Date: Mon, 28 Jul 2003 14:24:01 -0700
From: Jun Sun <jsun@mvista.com>
To: Teresa Tao <Teresat@tridentmicro.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: mmap'ed memory cacheable or uncheable
Message-ID: <20030728142401.K25784@mvista.com>
References: <61F6477DE6BED311B69F009027C3F58403AA396F@EXCHANGE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <61F6477DE6BED311B69F009027C3F58403AA396F@EXCHANGE>; from Teresat@tridentmicro.com on Fri, Jul 25, 2003 at 03:52:33PM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2917
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, Jul 25, 2003 at 03:52:33PM -0700, Teresa Tao wrote:
> How about if I specify the following flags in my mmap routine just like what the pgprot_noncached micro did.
> 	pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
> 	pgprot_val(vma->vm_page_prot) |= _CACHE_UNCACHED;
> 
> Will this have kernel make the mmap'd memory non-cacheable? Or is there a mmap non-cacheable patch?
>

I think this might work.  Did you try it?  The performance will be bad
though as mmap() is used widely by userland.

Jun

From anemo@mba.ocn.ne.jp Tue Jul 29 08:12:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jul 2003 08:12:06 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:42773
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225208AbTG2HMC>; Tue, 29 Jul 2003 08:12:02 +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; 29 Jul 2003 07:12:00 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.9/8.12.9) with ESMTP id h6T7BoDV067690;
	Tue, 29 Jul 2003 16:11:50 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Tue, 29 Jul 2003 16:13:03 +0900 (JST)
Message-Id: <20030729.161303.130243885.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: 64bit _syscall6 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: 2918
X-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

Here is a small fix for 64bit (N32 or ABI64) version of _syscall6().
"__NR_##name" is 7th parameter not 6th.

This is for 2.4 branch.  

diff -u linux-mips-cvs/include/asm-mips64/unistd.h linux.new/include/asm-mips64/unistd.h
--- linux-mips-cvs/include/asm-mips64/unistd.h	Tue Jul 22 09:48:19 2003
+++ linux.new/include/asm-mips64/unistd.h	Tue Jul 29 16:03:31 2003
@@ -883,7 +883,7 @@
 	\
 	__asm__ volatile ( \
 	".set\tnoreorder\n\t" \
-	"li\t$2, %6\t\t\t# " #name "\n\t" \
+	"li\t$2, %7\t\t\t# " #name "\n\t" \
 	"syscall\n\t" \
 	"move\t%0, $2\n\t" \
 	".set\treorder" \

And this is for 2.6.

diff -u linux-mips-cvs-2.6/include/asm-mips/unistd.h linux.new-2.6/include/asm-mips/unistd.h
--- linux-mips-cvs-2.6/include/asm-mips/unistd.h	Tue Jul 29 16:08:13 2003
+++ linux.new-2.6/include/asm-mips/unistd.h	Tue Jul 29 16:10:43 2003
@@ -1028,7 +1028,7 @@
 	\
 	__asm__ volatile ( \
 	".set\tnoreorder\n\t" \
-	"li\t$2, %6\t\t\t# " #name "\n\t" \
+	"li\t$2, %7\t\t\t# " #name "\n\t" \
 	"syscall\n\t" \
 	"move\t%0, $2\n\t" \
 	".set\treorder" \
---
Atsushi Nemoto

From ralf@linux-mips.org Tue Jul 29 12:49:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jul 2003 12:49:09 +0100 (BST)
Received: from p508B6063.dip.t-dialin.net ([IPv6:::ffff:80.139.96.99]:3494
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225214AbTG2LtH>; Tue, 29 Jul 2003 12:49:07 +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 h6TBn5x6032724;
	Tue, 29 Jul 2003 13:49:05 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6TBn5VS032723;
	Tue, 29 Jul 2003 13:49:05 +0200
Date: Tue, 29 Jul 2003 13:49:04 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: =?us-ascii?B?PT9pc28tODg1OS0xP1E/?= Frank=20F=F6rstemann ?= 
	<Foerstemann@web.de>
Cc: linux-mips@linux-mips.org
Subject: Re: No mouse support for Indy in 2.5.75 ?
Message-ID: <20030729114904.GA32526@linux-mips.org>
References: <200307252137.h6PLb6Q01329@mailgate5.cinetic.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200307252137.h6PLb6Q01329@mailgate5.cinetic.de>
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: 2919
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jul 25, 2003 at 11:37:06PM +0200, =?iso-8859-1?Q? Frank=20F=F6rstemann ?= wrote:

> I tried kernel version 2.5.75 on my Indy. It works fine with the
> exception that the mouse in XFree86 does not move. The devices are 
> available, but event debugging shows no mouse events at all. Are there
> any special configuration options for the Indy mouse except the ones in
> the 'input' section ? Dmesg output and kernel configuration are
> attached.

We knew there was something wrong in that area; the probe for kbd and mouse
also takes very long on the Indy.  What worries me more are those
kernel messages from your log:

mount: Exception at [<88113a38>] (88113bf0)
mount: Exception at [<88113a38>] (88113bf0)
mount: Exception at [<88113a38>] (88113bf0)

  Ralf

From jbglaw@dvmwest.gt.owl.de Tue Jul 29 13:20:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jul 2003 13:20:54 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:64197 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225212AbTG2MUw>; Tue, 29 Jul 2003 13:20:52 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 3C8F64A8BE; Tue, 29 Jul 2003 14:20:50 +0200 (CEST)
Date: Tue, 29 Jul 2003 14:20:50 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030729122050.GJ1873@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030729120925Z8225214-1272+3844@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="rwgQ89ZNnFUwFHTC"
Content-Disposition: inline
In-Reply-To: <20030729120925Z8225214-1272+3844@linux-mips.org>
X-Operating-System: Linux mail 2.4.18 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
User-Agent: Mutt/1.5.4i
Return-Path: <jbglaw@dvmwest.gt.owl.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: 2920
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


--rwgQ89ZNnFUwFHTC
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2003-07-29 13:09:21 +0100, ralf@linux-mips.org <ralf@linux-mips.org>
wrote in message <20030729120925Z8225214-1272+3844@linux-mips.org>:
>=20
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	03/07/29 13:09:21
>=20
> linux/drivers/media/dvb/ttusb-dec

Are DECstations now shipped with DVB receivers/decoders?

SCNR, JBG

--=20
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier B=FCrger" | im Internet! |   im Ira=
k!
      ret =3D do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

--rwgQ89ZNnFUwFHTC
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/JmahHb1edYOZ4bsRAsU9AJkBa7owzRScGMhMJ31on06X0k2P/QCePDxz
/Z0J9eS/odkp4CgFV1qXSPg=
=+pXk
-----END PGP SIGNATURE-----

--rwgQ89ZNnFUwFHTC--

From yuasa@hh.iij4u.or.jp Tue Jul 29 15:05:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jul 2003 15:05:37 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:61399 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225212AbTG2OFe>;
	Tue, 29 Jul 2003 15:05:34 +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 XAA06956;
	Tue, 29 Jul 2003 23:05:29 +0900 (JST)
Received: 4UMDO01 id h6TE5R315582; Tue, 29 Jul 2003 23:05:27 +0900 (JST)
Received: 4UMRO00 id h6TE5OQ00420; Tue, 29 Jul 2003 23:05:26 +0900 (JST)
	from stratos.frog (203.16.32.202.dy.iij4u.or.jp [202.32.16.203]) (authenticated)
Date: Tue, 29 Jul 2003 23:05:24 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, yuasa@hh.iij4u.or.jp
Subject: Re: [patch] wrong value definition about IBM WorkPad
Message-Id: <20030729230524.532006a2.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20030725173551.628f5bcb.yuasa@hh.iij4u.or.jp>
References: <20030725173551.628f5bcb.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: 2921
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

Hello Ralf,

On Fri, 25 Jul 2003 17:35:51 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf,
> 
> I made a patch for wrong value definition about IBM WorkPad.
> 
> Please apply these patches to v2.4 and v2.6 CVS tree.

These patches are needed for IBM WorkPad.
Please apply these patches.

Thanks,

Yoichi

From yuasa@hh.iij4u.or.jp Tue Jul 29 15:54:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jul 2003 15:54:12 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:28384 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225212AbTG2OyI>;
	Tue, 29 Jul 2003 15:54:08 +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 XAA13682;
	Tue, 29 Jul 2003 23:53:58 +0900 (JST)
Received: 4UMDO01 id h6TErv315983; Tue, 29 Jul 2003 23:53:57 +0900 (JST)
Received: 4UMRO00 id h6TErvQ03673; Tue, 29 Jul 2003 23:53:57 +0900 (JST)
	from stratos.frog (203.16.32.202.dy.iij4u.or.jp [202.32.16.203]) (authenticated)
Date: Tue, 29 Jul 2003 23:53:56 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org, yuasa@hh.iij4u.or.jp
Subject: Re: [patch]  IDE common routine for VR41xx
Message-Id: <20030729235356.47e10c04.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20030725154735.40697dca.yuasa@hh.iij4u.or.jp>
References: <20030725154735.40697dca.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_Tue__29_Jul_2003_23:53:56_+0900_08239318"
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: 2922
X-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_Tue__29_Jul_2003_23:53:56_+0900_08239318
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I also made a patch for v2.6.
Please apply this patch to CVS tree.

Thanks,

Yoichi

On Fri, 25 Jul 2003 15:47:35 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf,
> 
> I made a patch about IDE common routine for NEC VR41xx.
> 
> Please apply this patch to v2.4 CVS tree.
> 
> Yoichi
> 



--Multipart_Tue__29_Jul_2003_23:53:56_+0900_08239318
Content-Type: text/plain;
 name="vr41xx-ide-v26.diff"
Content-Disposition: attachment;
 filename="vr41xx-ide-v26.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/Makefile linux/arch/mips/vr41xx/casio-e55/Makefile
--- linux.orig/arch/mips/vr41xx/casio-e55/Makefile	Sat Jun 14 00:32:27 2003
+++ linux/arch/mips/vr41xx/casio-e55/Makefile	Tue Jul 29 23:35:49 2003
@@ -3,5 +3,3 @@
 #
 
 obj-y			+= init.o setup.o
-
-obj-$(CONFIG_IDE)	+= ide-e55.o
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/ide-e55.c linux/arch/mips/vr41xx/casio-e55/ide-e55.c
--- linux.orig/arch/mips/vr41xx/casio-e55/ide-e55.c	Fri Oct  4 01:57:50 2002
+++ linux/arch/mips/vr41xx/casio-e55/ide-e55.c	Thu Jan  1 09:00:00 1970
@@ -1,99 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations
- * for the CASIO CASSIOPEIA E-55/65.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Sun, 24 Feb 2002
- *  - Added CASIO CASSIOPEIA E-55/65 support.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int e55_ide_default_irq(ide_ioreg_t base)
-{
-	return 40;
-}
-
-static ide_ioreg_t e55_ide_default_io_base(int index)
-{
-	switch (index) {
-		case 0: return 0xc1f0;
-		case 1: return 0xc170;
-		case 2: return 0xc1e8;
-		case 3: return 0xc168;
-		case 4: return 0xc1e0;
-		case 5: return 0xc160;
-	}
-	return 0;
-}
-
-static void e55_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                    ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int e55_ide_request_irq(unsigned int irq,
-                               void (*handler)(int,void *, struct pt_regs *),
-                               unsigned long flags, const char *device,
-                               void *dev_id)
-{
-	return request_irq(irq, handler, flags, device, dev_id);
-}			
-
-static void e55_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int e55_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void e55_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                   const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void e55_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops e55_ide_ops = {
-	&e55_ide_default_irq,
-	&e55_ide_default_io_base,
-	&e55_ide_init_hwif_ports,
-	&e55_ide_request_irq,
-	&e55_ide_free_irq,
-	&e55_ide_check_region,
-	&e55_ide_request_region,
-	&e55_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/casio-e55/setup.c linux/arch/mips/vr41xx/casio-e55/setup.c
--- linux.orig/arch/mips/vr41xx/casio-e55/setup.c	Thu Nov  7 21:37:26 2002
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Tue Jul 29 23:38:53 2003
@@ -31,10 +31,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops e55_ide_ops;
-#endif
-
 void __init casio_e55_setup(void)
 {
 	set_io_port_base(IO_PORT_BASE);
@@ -60,8 +56,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &e55_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/Makefile linux/arch/mips/vr41xx/common/Makefile
--- linux.orig/arch/mips/vr41xx/common/Makefile	Sat Jun 14 00:32:27 2003
+++ linux/arch/mips/vr41xx/common/Makefile	Tue Jul 29 23:38:07 2003
@@ -6,5 +6,6 @@
 obj-$(CONFIG_SERIAL_8250)	+= serial.o
 obj-$(CONFIG_VR41XX_TIME_C)	+= time.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
+obj-$(subst m,y,$(CONFIG_IDE))	+= ide.o
 
 EXTRA_AFLAGS := $(CFLAGS)
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/ide.c linux/arch/mips/vr41xx/common/ide.c
--- linux.orig/arch/mips/vr41xx/common/ide.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/common/ide.c	Tue Jul 29 23:37:42 2003
@@ -0,0 +1,50 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * IDE routines for NEC VR4100 series standard configurations.
+ *
+ * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
+ * Copyright (C) 2003 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ */
+#include <linux/hdreg.h>
+#include <linux/ide.h>
+
+#include <asm/hdreg.h>
+
+static int vr41xx_ide_default_irq(ide_ioreg_t base)
+{
+	return 0;
+}
+
+static ide_ioreg_t vr41xx_ide_default_io_base(int index)
+{
+	return 0;
+}
+
+static void vr41xx_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
+                                       ide_ioreg_t ctrl_port, int *irq)
+{
+	ide_ioreg_t reg = data_port;
+	int i;
+
+	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
+		hw->io_ports[i] = reg;
+		reg += 1;
+	}
+	if (ctrl_port) {
+		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
+	} else {
+		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
+	}
+	if (irq != NULL)
+		*irq = 0;
+	hw->io_ports[IDE_IRQ_OFFSET] = 0;
+}
+
+struct ide_ops vr41xx_ide_ops = {
+	.ide_default_irq	= &vr41xx_ide_default_irq,
+	.ide_default_io_base	= &vr41xx_ide_default_io_base,
+	.ide_init_hwif_ports	= &vr41xx_ide_init_hwif_ports
+};
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	Sat Jun 14 00:32:27 2003
+++ linux/arch/mips/vr41xx/ibm-workpad/Makefile	Tue Jul 29 23:36:13 2003
@@ -3,4 +3,3 @@
 #
 
 obj-y			+= init.o setup.o
-obj-$(CONFIG_IDE)	+= ide-workpad.o
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/ide-workpad.c linux/arch/mips/vr41xx/ibm-workpad/ide-workpad.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/ide-workpad.c	Fri Oct  4 01:57:50 2002
+++ linux/arch/mips/vr41xx/ibm-workpad/ide-workpad.c	Thu Jan  1 09:00:00 1970
@@ -1,98 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations for the IBM WorkPad z50.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Sun, 24 Feb 2002
- *  - Added IBM WorkPad z50 support.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int workpad_ide_default_irq(ide_ioreg_t base)
-{
-	return 49;
-}
-
-static ide_ioreg_t workpad_ide_default_io_base(int index)
-{
-	switch (index) {
-		case 0: return 0x1f0;
-		case 1: return 0x170;
-		case 2: return 0x1e8;
-		case 3: return 0x168;
-		case 4: return 0x1e0;
-		case 5: return 0x160;
-	}
-	return 0;
-}
-
-static void workpad_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                        ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int workpad_ide_request_irq(unsigned int irq,
-                                   void (*handler)(int,void *, struct pt_regs *),
-                                   unsigned long flags, const char *device,
-                                   void *dev_id)
-{
-	return request_irq(irq, handler, SA_SHIRQ, device, dev_id);
-}			
-
-static void workpad_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int workpad_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void workpad_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                       const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void workpad_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops workpad_ide_ops = {
-	&workpad_ide_default_irq,
-	&workpad_ide_default_io_base,
-	&workpad_ide_init_hwif_ports,
-	&workpad_ide_request_irq,
-	&workpad_ide_free_irq,
-	&workpad_ide_check_region,
-	&workpad_ide_request_region,
-	&workpad_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c linux/arch/mips/vr41xx/ibm-workpad/setup.c
--- linux.orig/arch/mips/vr41xx/ibm-workpad/setup.c	Thu Nov  7 21:37:26 2002
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Tue Jul 29 23:39:15 2003
@@ -31,10 +31,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops workpad_ide_ops;
-#endif
-
 void __init ibm_workpad_setup(void)
 {
 	set_io_port_base(IO_PORT_BASE);
@@ -60,8 +56,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &workpad_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/Makefile linux/arch/mips/vr41xx/nec-eagle/Makefile
--- linux.orig/arch/mips/vr41xx/nec-eagle/Makefile	Sat Jun 14 00:32:27 2003
+++ linux/arch/mips/vr41xx/nec-eagle/Makefile	Tue Jul 29 23:36:25 2003
@@ -8,4 +8,3 @@
 #
 
 obj-y			+= init.o irq.o setup.o
-obj-$(CONFIG_IDE)	+= ide-eagle.o
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/ide-eagle.c linux/arch/mips/vr41xx/nec-eagle/ide-eagle.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/ide-eagle.c	Tue Aug  6 09:08:58 2002
+++ linux/arch/mips/vr41xx/nec-eagle/ide-eagle.c	Thu Jan  1 09:00:00 1970
@@ -1,96 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations
- * for the NEC Eagle/Hawk board.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  Fri,  5 Apr 2002
- *  - Added support for NEC Hawk.
- *
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  Fri,  1 Mar 2002
- *  - Added support for NEC Eagle.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int eagle_ide_default_irq(ide_ioreg_t base)
-{
-	return 0;
-}
-
-static ide_ioreg_t eagle_ide_default_io_base(int index)
-{
-	return 0;
-}
-
-static void eagle_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                      ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int eagle_ide_request_irq(unsigned int irq,
-                                 void (*handler)(int,void *, struct pt_regs *),
-                                 unsigned long flags, const char *device,
-                                 void *dev_id)
-{
-	return request_irq(irq, handler, SA_SHIRQ, device, dev_id);
-}
-
-static void eagle_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int eagle_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void eagle_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                     const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void eagle_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops eagle_ide_ops = {
-	&eagle_ide_default_irq,
-	&eagle_ide_default_io_base,
-	&eagle_ide_init_hwif_ports,
-	&eagle_ide_request_irq,
-	&eagle_ide_free_irq,
-	&eagle_ide_check_region,
-	&eagle_ide_request_region,
-	&eagle_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/setup.c	Sun Dec 29 23:50:56 2002
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Tue Jul 29 23:39:41 2003
@@ -58,10 +58,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops eagle_ide_ops;
-#endif
-
 extern void eagle_irq_init(void);
 
 #ifdef CONFIG_PCI
@@ -141,8 +137,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &eagle_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c
--- linux.orig/arch/mips/vr41xx/tanbac-tb0226/setup.c	Thu Apr 24 00:27:49 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c	Tue Jul 29 23:39:59 2003
@@ -16,7 +16,6 @@
 #include <linux/config.h>
 #include <linux/init.h>
 #include <linux/console.h>
-#include <linux/ide.h>
 #include <linux/ioport.h>
 
 #include <asm/pci_channel.h>
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	Sat Jun 14 00:32:27 2003
+++ linux/arch/mips/vr41xx/victor-mpc30x/Makefile	Tue Jul 29 23:37:00 2003
@@ -3,4 +3,3 @@
 #
 
 obj-y			+= init.o setup.o
-obj-$(CONFIG_IDE)	+= ide-mpc30x.o
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c linux/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c	Fri Oct  4 01:57:50 2002
+++ linux/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c	Thu Jan  1 09:00:00 1970
@@ -1,91 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations
- * for the ZAO Networks Capcella.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Fri, 23 Aug 2002
- *  - Added Victor MP-C303/304 support.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int mpc30x_ide_default_irq(ide_ioreg_t base)
-{
-	return 0;
-}
-
-static ide_ioreg_t mpc30x_ide_default_io_base(int index)
-{
-	return 0;
-}
-
-static void mpc30x_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                       ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int mpc30x_ide_request_irq(unsigned int irq,
-                                  void (*handler)(int,void *, struct pt_regs *),
-                                  unsigned long flags, const char *device,
-                                  void *dev_id)
-{
-	return request_irq(irq, handler, flags, device, dev_id);
-}
-
-static void mpc30x_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int mpc30x_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void mpc30x_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                      const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void mpc30x_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops mpc30x_ide_ops = {
-	&mpc30x_ide_default_irq,
-	&mpc30x_ide_default_io_base,
-	&mpc30x_ide_init_hwif_ports,
-	&mpc30x_ide_request_irq,
-	&mpc30x_ide_free_irq,
-	&mpc30x_ide_check_region,
-	&mpc30x_ide_request_region,
-	&mpc30x_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/setup.c	Thu Nov  7 21:37:26 2002
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Tue Jul 29 23:40:28 2003
@@ -32,10 +32,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops mpc30x_ide_ops;
-#endif
-
 #ifdef CONFIG_PCI
 static struct resource vr41xx_pci_io_resource = {
 	"PCI I/O space",
@@ -108,8 +104,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &mpc30x_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/Makefile linux/arch/mips/vr41xx/zao-capcella/Makefile
--- linux.orig/arch/mips/vr41xx/zao-capcella/Makefile	Sat Jun 14 00:32:27 2003
+++ linux/arch/mips/vr41xx/zao-capcella/Makefile	Tue Jul 29 23:37:20 2003
@@ -3,4 +3,3 @@
 #
 
 obj-y			+= init.o setup.o
-obj-$(CONFIG_IDE)	+= ide-capcella.o
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/ide-capcella.c linux/arch/mips/vr41xx/zao-capcella/ide-capcella.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/ide-capcella.c	Tue Aug  6 09:08:58 2002
+++ linux/arch/mips/vr41xx/zao-capcella/ide-capcella.c	Thu Jan  1 09:00:00 1970
@@ -1,99 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * IDE routines for typical pc-like standard configurations
- * for the ZAO Networks Capcella.
- *
- * Copyright (C) 1998, 1999, 2001 by Ralf Baechle
- */
-/*
- * Changes:
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>  Sun, 24 Feb 2002
- *  - Added ZAO Networks Capcella support.
- */
-#include <linux/sched.h>
-#include <linux/ide.h>
-#include <linux/ioport.h>
-#include <linux/hdreg.h>
-#include <asm/ptrace.h>
-#include <asm/hdreg.h>
-
-static int capcella_ide_default_irq(ide_ioreg_t base)
-{
-	switch (base) {
-	case 0x8300: return 42;
-	}
-
-	return 0;
-}
-
-static ide_ioreg_t capcella_ide_default_io_base(int index)
-{
-	switch (index) {
-	case 0: return 0x8300;
-	}
-
-	return 0;
-}
-
-static void capcella_ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port,
-                                         ide_ioreg_t ctrl_port, int *irq)
-{
-	ide_ioreg_t reg = data_port;
-	int i;
-
-	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
-		hw->io_ports[i] = reg;
-		reg += 1;
-	}
-	if (ctrl_port) {
-		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-	} else {
-		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
-	}
-	if (irq != NULL)
-		*irq = 0;
-	hw->io_ports[IDE_IRQ_OFFSET] = 0;
-}
-
-static int capcella_ide_request_irq(unsigned int irq,
-                                    void (*handler)(int,void *, struct pt_regs *),
-                                    unsigned long flags, const char *device,
-                                    void *dev_id)
-{
-	return request_irq(irq, handler, flags, device, dev_id);
-}
-
-static void capcella_ide_free_irq(unsigned int irq, void *dev_id)
-{
-	free_irq(irq, dev_id);
-}
-
-static int capcella_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-	return check_region(from, extent);
-}
-
-static void capcella_ide_request_region(ide_ioreg_t from, unsigned int extent,
-                                        const char *name)
-{
-	request_region(from, extent, name);
-}
-
-static void capcella_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-	release_region(from, extent);
-}
-
-struct ide_ops capcella_ide_ops = {
-	&capcella_ide_default_irq,
-	&capcella_ide_default_io_base,
-	&capcella_ide_init_hwif_ports,
-	&capcella_ide_request_irq,
-	&capcella_ide_free_irq,
-	&capcella_ide_check_region,
-	&capcella_ide_request_region,
-	&capcella_ide_release_region
-};
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c
--- linux.orig/arch/mips/vr41xx/zao-capcella/setup.c	Thu Nov  7 21:37:26 2002
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Tue Jul 29 23:40:54 2003
@@ -32,10 +32,6 @@
 extern void * __rd_start, * __rd_end;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-extern struct ide_ops capcella_ide_ops;
-#endif
-
 #ifdef CONFIG_PCI
 static struct resource vr41xx_pci_io_resource = {
 	"PCI I/O space",
@@ -108,8 +104,8 @@
 	conswitchp = &dummy_con;
 #endif
 
-#ifdef CONFIG_BLK_DEV_IDE
-	ide_ops = &capcella_ide_ops;
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+	ide_ops = &vr41xx_ide_ops;
 #endif
 
 	vr41xx_bcu_init();
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h
--- linux.orig/include/asm-mips/vr41xx/vr41xx.h	Mon Mar 24 00:01:42 2003
+++ linux/include/asm-mips/vr41xx/vr41xx.h	Tue Jul 29 23:41:39 2003
@@ -189,4 +189,8 @@
 extern void vr41xx_halt(void);
 extern void vr41xx_power_off(void);
 
+#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
+extern struct ide_ops vr41xx_ide_ops;
+#endif
+
 #endif /* __NEC_VR41XX_H */

--Multipart_Tue__29_Jul_2003_23:53:56_+0900_08239318--

From macro@ds2.pg.gda.pl Tue Jul 29 17:09:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jul 2003 17:09:56 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:12418 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225212AbTG2QJy>; Tue, 29 Jul 2003 17:09:54 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA09375;
	Tue, 29 Jul 2003 18:09:45 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Tue, 29 Jul 2003 18:09:43 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Teresa Tao <Teresat@tridentmicro.com>, linux-mips@linux-mips.org
Subject: Re: mmap'ed memory cacheable or uncheable
In-Reply-To: <20030728142401.K25784@mvista.com>
Message-ID: <Pine.GSO.3.96.1030729180353.9217B-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: 2923
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 28 Jul 2003, Jun Sun wrote:

> > How about if I specify the following flags in my mmap routine just like what the pgprot_noncached micro did.
> > 	pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
> > 	pgprot_val(vma->vm_page_prot) |= _CACHE_UNCACHED;
> > 
> > Will this have kernel make the mmap'd memory non-cacheable? Or is there a mmap non-cacheable patch?
> 
> I think this might work.  Did you try it?  The performance will be bad
> though as mmap() is used widely by userland.

 See mmap_mem() for how to select between cached and uncached mmap()ing
cleanly. 

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


From ralf@linux-mips.org Wed Jul 30 02:30:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 02:30:27 +0100 (BST)
Received: from p508B6063.dip.t-dialin.net ([IPv6:::ffff:80.139.96.99]:55508
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225213AbTG3BaW>; Wed, 30 Jul 2003 02:30:22 +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 h6U1UKx6008307;
	Wed, 30 Jul 2003 03:30:20 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6U1UKJS008306;
	Wed, 30 Jul 2003 03:30:20 +0200
Date: Wed, 30 Jul 2003 03:30:20 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Louis Hamilton <hamilton@redhat.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] Mips64 Ocelot-C and Jaguar ATX platform support
Message-ID: <20030730013019.GA7366@linux-mips.org>
References: <3F1F0BDC.8040609@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F1F0BDC.8040609@redhat.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: 2924
X-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, Jul 23, 2003 at 05:27:40PM -0500, Louis Hamilton wrote:

> Notes the board support lives under arch/mips/momentum.
> Also, CONFIG_BOARD_SCACHE and CONFIG_RM7000_CPU_SCACHE are utilized and
> integrated into each platform's default configuration files.
> As in the first patch, drivers/net/mv64340_eth.{c,h} is added to provide 
> ethernet support.
> 
> If it looks ok, please check changes into the tree.

Ehhh, sorry.  This CONFIG_JAGUAR_DMALOW thing just isn't the way to go.
I know the Jaguar's DMA architecture is unpleassant to say the least but
still, cluttering generic code with ifdefs isn't the way to go.  Declare
all memory above the DMA limit high-memory and put the rest into ZONE_DMA
rsp. ZONE_NORMAL, as appropriate for the Jaguar.  Then provide a dummy
implementation of kmap, kunmap etc. (unless you have "real" highmem of
course) that does the same thing as if highmem was disabled, see
<linux/highmem.h>.

  Ralf

From ralf@linux-mips.org Wed Jul 30 03:13:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 03:13:10 +0100 (BST)
Received: from p508B6063.dip.t-dialin.net ([IPv6:::ffff:80.139.96.99]:26583
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225213AbTG3CNI>; Wed, 30 Jul 2003 03:13:08 +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 h6U2Cqx6009115;
	Wed, 30 Jul 2003 04:12:52 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6U2CoB2009114;
	Wed, 30 Jul 2003 04:12:50 +0200
Date: Wed, 30 Jul 2003 04:12:50 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030730021249.GC7366@linux-mips.org>
References: <Pine.GSO.4.21.0307222346260.27629-100000@vervain.sonytel.be> <Pine.GSO.3.96.1030723004508.607O-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.1030723004508.607O-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: 2925
X-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, Jul 23, 2003 at 12:51:37AM +0200, Maciej W. Rozycki wrote:

> > >  Well, as long as one get that far to run a configuration script (BTW,
> > > what menus are you referring to? -- I haven't seen any).  Right now that's
> > 
> > It will flash up on your retina and stay there for a while, waiting for your
> > response, if you run `make oldconfig' :-)
> 
>  Hmm, now I have to speed up my transition to 2.6 to have my curiosity
> appeased...  Hopefully I won't get disappointed.

Well, 2.6 won't be the big leap that 2.4 was for most MIPS users, more
evolution than revolution ...

  Ralf

From ralf@linux-mips.org Wed Jul 30 04:23:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 04:23:56 +0100 (BST)
Received: from p508B60E0.dip.t-dialin.net ([IPv6:::ffff:80.139.96.224]:39643
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224802AbTG3DXy>; Wed, 30 Jul 2003 04:23:54 +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 h6U3GWx6015647;
	Wed, 30 Jul 2003 05:16:32 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6U3GWgM015646;
	Wed, 30 Jul 2003 05:16:32 +0200
Date: Wed, 30 Jul 2003 05:16:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030730031631.GD7366@linux-mips.org>
References: <20030722212117.GB1660@linux-mips.org> <Pine.GSO.3.96.1030722232705.607L-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.1030722232705.607L-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: 2926
X-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, Jul 22, 2003 at 11:37:44PM +0200, Maciej W. Rozycki wrote:

> > Btw, an old experience repeats - some of the code was identical except
> > inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
> > I rewrote that stuff to use C for this arithmetic.  The result - less
> > inline assembler, more readable code and a file that's identical for
> > both 32-bit and 64-bit.
> 
>  Well, whatever is plain C code (or should be such) should be identical,
> indeed, but macros will differ as will low-level assembly.  Then add
> 64-bit specific options and you get yet more complication. 

You're right, we've got a good bit of assembler code that should just be
C.  So I rewrote some of the code to C.

>  I hope `uname -m' will continue to report the correct architecture and
> that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
> and "mips64" a 64-bit one) -- have you considered this?

Not intend to change the behaviour of uname.  It actually changed in CVS,
for now consider that a bug ...

We should consider changing the behaviour though.  A machine type of
mips64 broke lots of software.  Of course that was all 32-bit softare but
it raises the question if returning mips64 is really a good idea?

As for choosing a 32-bit vs. 64-bit kernel, that's now a menu point and can
be choosen like every other config option.

  Ralf

From foerstemann@web.de Wed Jul 30 06:54:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 06:54:34 +0100 (BST)
Received: from mailgate5.cinetic.de ([IPv6:::ffff:217.72.192.165]:33713 "EHLO
	mailgate5.cinetic.de") by linux-mips.org with ESMTP
	id <S8225253AbTG3Fyc>; Wed, 30 Jul 2003 06:54:32 +0100
Received: from web.de (fmomail03.dlan.cinetic.de [172.20.1.236])
	by mailgate5.cinetic.de (8.11.6p2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id h6U5sOQ11794;
	Wed, 30 Jul 2003 07:54:25 +0200
Date: Wed, 30 Jul 2003 07:54:25 +0200
Message-Id: <200307300554.h6U5sOQ11794@mailgate5.cinetic.de>
MIME-Version: 1.0
Organization: http://freemail.web.de/
From: =?iso-8859-1?Q? "Frank=20F=F6rstemann" ?= <foerstemann@web.de>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: No mouse support for Indy in 2.5.75 ?
Precedence: fm-user
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Return-Path: <foerstemann@web.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: 2927
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: foerstemann@web.de
Precedence: bulk
X-list: linux-mips

Hi Ralf.

Is there any additional information I can collect on these issues ?

Frank

Am Die, 2003-07-29 um 13.49 schrieb Ralf Baechle:
> On Fri, Jul 25, 2003 at 11:37:06PM +0200, =?iso-8859-1?Q? Frank=20F=F6rstemann ?= wrote:
> 
> > I tried kernel version 2.5.75 on my Indy. It works fine with the
> > exception that the mouse in XFree86 does not move. The devices are 
> > available, but event debugging shows no mouse events at all. Are there
> > any special configuration options for the Indy mouse except the ones in
> > the 'input' section ? Dmesg output and kernel configuration are
> > attached.
> 
> We knew there was something wrong in that area; the probe for kbd and mouse
> also takes very long on the Indy.  What worries me more are those
> kernel messages from your log:
> 
> mount: Exception at [<88113a38>] (88113bf0)
> mount: Exception at [<88113a38>] (88113bf0)
> mount: Exception at [<88113a38>] (88113bf0)
> 
>   Ralf

______________________________________________________________________________
ComputerBild (15-03) empfiehlt: Der beste Spam-Schutz ist bei
WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021124


From macro@ds2.pg.gda.pl Wed Jul 30 08:48:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 08:48:58 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:16334 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225200AbTG3Hs4>; Wed, 30 Jul 2003 08:48:56 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA26912;
	Wed, 30 Jul 2003 09:47:35 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 30 Jul 2003 09:47:34 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030730021249.GC7366@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030730094217.26733A-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: 2928
X-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 Wed, 30 Jul 2003, Ralf Baechle wrote:

> On Wed, Jul 23, 2003 at 12:51:37AM +0200, Maciej W. Rozycki wrote:
> 
> > > >  Well, as long as one get that far to run a configuration script (BTW,
> > > > what menus are you referring to? -- I haven't seen any).  Right now that's
> > > 
> > > It will flash up on your retina and stay there for a while, waiting for your
> > > response, if you run `make oldconfig' :-)
> > 
> >  Hmm, now I have to speed up my transition to 2.6 to have my curiosity
> > appeased...  Hopefully I won't get disappointed.
> 
> Well, 2.6 won't be the big leap that 2.4 was for most MIPS users, more
> evolution than revolution ...

 I'm referring to that menus that will flash up on my retina (if I got the
meaning right). ;-)

 Anyway, it looks like some additional checks and possibly fixes will be
needed for 64-bit configurations (including changes to my pending
patches).  And last time I checked 2.5.x had showstopper problems for me
elsewhere (IDE -- I still use it here and there) -- I doubt they have been
fixed in the recent 2.6 -test releases. 

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


From macro@ds2.pg.gda.pl Wed Jul 30 08:55:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 08:55:30 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:54990 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225200AbTG3Hz2>; Wed, 30 Jul 2003 08:55:28 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA27010;
	Wed, 30 Jul 2003 09:55:26 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Wed, 30 Jul 2003 09:55:26 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030730031631.GD7366@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030730094741.26733B-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: 2929
X-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 Wed, 30 Jul 2003, Ralf Baechle wrote:

> >  I hope `uname -m' will continue to report the correct architecture and
> > that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
> > and "mips64" a 64-bit one) -- have you considered this?
> 
> Not intend to change the behaviour of uname.  It actually changed in CVS,
> for now consider that a bug ...

 OK, I will.

> We should consider changing the behaviour though.  A machine type of
> mips64 broke lots of software.  Of course that was all 32-bit softare but
> it raises the question if returning mips64 is really a good idea?

 Yes it is.  It is the only way to check if the kernel is 32-bit or 64-bit
and config.guess needs it for guessing the canonical system name.  That,
plus checking the default ld emulation lets it (or will let, once written)
select what is the proper default native configuration: 
mips{,el}-unknown-linux-gnu, mips64{,el}-unknown-linux-gnu-abin32 or
mips64{,el}-unknown-linux-gnu-abi64. 

> As for choosing a 32-bit vs. 64-bit kernel, that's now a menu point and can
> be choosen like every other config option.

 Well, I liked the `make "ARCH=mips64"' way, but I suppose I'll have to
live with your change, sigh... 

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


From ralf@linux-mips.org Wed Jul 30 12:23:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 12:23:12 +0100 (BST)
Received: from p508B60E0.dip.t-dialin.net ([IPv6:::ffff:80.139.96.224]:48265
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225202AbTG3LXK>; Wed, 30 Jul 2003 12:23:10 +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 h6UBN8x6024478;
	Wed, 30 Jul 2003 13:23:08 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6UBN7WO024477;
	Wed, 30 Jul 2003 13:23:07 +0200
Date: Wed, 30 Jul 2003 13:23:07 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: =?us-ascii?B?PT9pc28tODg1OS0xP1E/?= Frank=20F=F6rstemann ?= 
	<foerstemann@web.de>
Cc: linux-mips@linux-mips.org
Subject: Re: No mouse support for Indy in 2.5.75 ?
Message-ID: <20030730112307.GC15703@linux-mips.org>
References: <200307300554.h6U5sOQ11794@mailgate5.cinetic.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200307300554.h6U5sOQ11794@mailgate5.cinetic.de>
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: 2930
X-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, Jul 30, 2003 at 07:54:25AM +0200, =?iso-8859-1?Q? Frank=20F=F6rstemann ?= wrote:

> Is there any additional information I can collect on these issues ?

Well, as for the PS/2 issues, you'll have to read through the code yourself,
nobody's digged into that so far.

> > mount: Exception at [<88113a38>] (88113bf0)
> > mount: Exception at [<88113a38>] (88113bf0)
> > mount: Exception at [<88113a38>] (88113bf0)

The kernel messages otoh are not sign of a kernel but an application bug.
It seems mount did pass bad addresses to the kernel through some syscall;
these messages are the sign of the normal mechanism to intercept bad
address arguments to syscall kicking in.  You won't get those messages
anymore in 2.6 btw.  The kernel only print's them if the second digit of
the version number is odd, see development_version in arch/mips/mm/fault.c.

  Ralf

From ralf@linux-mips.org Wed Jul 30 15:06:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 15:06:16 +0100 (BST)
Received: from p508B60E0.dip.t-dialin.net ([IPv6:::ffff:80.139.96.224]:35475
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225202AbTG3OGO>; Wed, 30 Jul 2003 15:06:14 +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 h6UE5tx6026492;
	Wed, 30 Jul 2003 16:05:55 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6UE5tZP026491;
	Wed, 30 Jul 2003 16:05:55 +0200
Date: Wed, 30 Jul 2003 16:05:54 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030730140554.GB26372@linux-mips.org>
References: <20030730031631.GD7366@linux-mips.org> <Pine.GSO.3.96.1030730094741.26733B-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.1030730094741.26733B-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: 2931
X-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, Jul 30, 2003 at 09:55:26AM +0200, Maciej W. Rozycki wrote:

> > >  I hope `uname -m' will continue to report the correct architecture and
> > > that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
> > > and "mips64" a 64-bit one) -- have you considered this?
> > 
> > Not intend to change the behaviour of uname.  It actually changed in CVS,
> > for now consider that a bug ...
> 
>  OK, I will.

Fix is in CVS.

> > We should consider changing the behaviour though.  A machine type of
> > mips64 broke lots of software.  Of course that was all 32-bit softare but
> > it raises the question if returning mips64 is really a good idea?
> 
>  Yes it is.  It is the only way to check if the kernel is 32-bit or 64-bit
> and config.guess needs it for guessing the canonical system name.  That,
> plus checking the default ld emulation lets it (or will let, once written)
> select what is the proper default native configuration: 
> mips{,el}-unknown-linux-gnu, mips64{,el}-unknown-linux-gnu-abin32 or
> mips64{,el}-unknown-linux-gnu-abi64. 
> 
> > As for choosing a 32-bit vs. 64-bit kernel, that's now a menu point and can
> > be choosen like every other config option.
> 
>  Well, I liked the `make "ARCH=mips64"' way, but I suppose I'll have to
> live with your change, sigh... 

Well, that was one of the things that were handy at times.  Considering
the patch I sent to Linus yesterday to Linus did remove 41010 lines of code
that was a tiny price to pay.

  Ralf

From ralf@linux-mips.org Wed Jul 30 15:07:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jul 2003 15:07:58 +0100 (BST)
Received: from p508B60E0.dip.t-dialin.net ([IPv6:::ffff:80.139.96.224]:43923
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225202AbTG3OHz>; Wed, 30 Jul 2003 15:07:55 +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 h6UE7mx6026551;
	Wed, 30 Jul 2003 16:07:48 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6UE7mYC026550;
	Wed, 30 Jul 2003 16:07:48 +0200
Date: Wed, 30 Jul 2003 16:07:48 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Keith M Wesolowski <wesolows@foobazco.org>,
	"Kevin D. Kissell" <kevink@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030730140748.GC26372@linux-mips.org>
References: <20030730021249.GC7366@linux-mips.org> <Pine.GSO.3.96.1030730094217.26733A-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.1030730094217.26733A-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: 2932
X-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, Jul 30, 2003 at 09:47:34AM +0200, Maciej W. Rozycki wrote:

> > > > It will flash up on your retina and stay there for a while, waiting
> > > > for your response, if you run `make oldconfig' :-)
> > > 
> > >  Hmm, now I have to speed up my transition to 2.6 to have my curiosity
> > > appeased...  Hopefully I won't get disappointed.
> > 
> > Well, 2.6 won't be the big leap that 2.4 was for most MIPS users, more
> > evolution than revolution ...
> 
>  I'm referring to that menus that will flash up on my retina (if I got the
> meaning right). ;-)

Oh :-)

>  Anyway, it looks like some additional checks and possibly fixes will be
> needed for 64-bit configurations (including changes to my pending
> patches).  And last time I checked 2.5.x had showstopper problems for me
> elsewhere (IDE -- I still use it here and there) -- I doubt they have been
> fixed in the recent 2.6 -test releases. 

True, 2.6 isn't yet a great stability experience ...

  Ralf

From fxzhang@ict.ac.cn Thu Jul 31 02:56:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 02:56:35 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:26560
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225202AbTGaB4c>; Thu, 31 Jul 2003 02:56:32 +0100
Received: (qmail 22153 invoked from network); 31 Jul 2003 01:52:42 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 31 Jul 2003 01:52:42 -0000
Message-ID: <3F287738.1040203@ict.ac.cn>
Date: Thu, 31 Jul 2003 09:56:08 +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: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: RM7k cache_flush_sigtramp
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
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: 2933
X-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

hi,

r4k_cache_flush_sigtrap seems not enough for RM7000 cpus because
there is a writebuffer between L1 dcache & L2 cache,so the written back
block may not be seen by icache. This small patch fixes crashes of my
Xserver
on ev64240.


--- r4kcache.h.ori 2003-07-31 09:51:01.000000000 +0800
+++ r4kcache.h 2003-07-31 09:51:57.000000000 +0800
@@ -94,6 +94,9 @@
".set noreorder\n\t"
".set mips3\n"
"1:\tcache %0,(%1)\n"
+#ifdef CONFIG_CPU_RM7000
+ "sync\n\t"
+#endif
"2:\t.set mips0\n\t"
".set reorder\n\t"
".section\t__ex_table,\"a\"\n\t"



From jsun@mvista.com Thu Jul 31 03:12:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 03:12:23 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:58094 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225202AbTGaCMV>;
	Thu, 31 Jul 2003 03:12:21 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6V2CJV03298;
	Wed, 30 Jul 2003 19:12:19 -0700
Date: Wed, 30 Jul 2003 19:12:19 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: Malta + USB on 2.4, anyone?
Message-ID: <20030730191219.A14914@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2934
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


Has anybody tried USB on malta with 2.4 kernel?  I just found that
I got 0xff IRQ number and kernel panics.

Will look further tomorrow, but want to see if anybody knows about 
it first.

Also, the kgdb seems to be flaky.  Targets can send chars too fast
so that chars get lost.  It appears that the linux status register
might be lying about "transmitter buffer empty".  

Jun

From chris@mips.com Thu Jul 31 10:54:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 10:54:14 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:12561 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225213AbTGaJyM>;
	Thu, 31 Jul 2003 10:54:12 +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 19iA9h-0007c9-00; Thu, 31 Jul 2003 10:55:29 +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 19iA7O-00010r-00; Thu, 31 Jul 2003 10:53:06 +0100
Message-ID: <3F28E702.70401@mips.com>
Date: Thu, 31 Jul 2003 10:53:06 +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.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
MIME-Version: 1.0
To: Jun Sun <jsun@mvista.com>
CC: linux-mips@linux-mips.org
Subject: Re: Malta + USB on 2.4, anyone?
References: <20030730191219.A14914@mvista.com>
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 ()
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: 2935
X-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

Jun Sun wrote:
> Has anybody tried USB on malta with 2.4 kernel?  I just found that
> I got 0xff IRQ number and kernel panics.

> Also, the kgdb seems to be flaky.  Targets can send chars too fast
> so that chars get lost.  It appears that the linux status register
> might be lying about "transmitter buffer empty".  

   I regularly use gdb @ 115200 on Malta and haven't noticed any problems.

	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 Thu Jul 31 11:26:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 11:26:59 +0100 (BST)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:61896 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225213AbTGaK05>; Thu, 31 Jul 2003 11:26:57 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA18201;
	Thu, 31 Jul 2003 12:26:45 +0200 (MET DST)
X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs
Date: Thu, 31 Jul 2003 12:26:44 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: linux-mips@linux-mips.org
Subject: Re: Malta + USB on 2.4, anyone?
In-Reply-To: <20030730191219.A14914@mvista.com>
Message-ID: <Pine.GSO.3.96.1030731121705.17497D-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: 2936
X-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 Wed, 30 Jul 2003, Jun Sun wrote:

> Has anybody tried USB on malta with 2.4 kernel?  I just found that
> I got 0xff IRQ number and kernel panics.

 Possibly IRQ routing is broken -- the PIIX4 uses INTD for its USB
controller's interrupt.  For the Malta it should be routed to the IRQ11
input of the PIIX4's internal dual-8259A PIC.  What does `/sbin/lspci -vv
-s 00:0a.2' print?

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


From ralf@linux-mips.org Thu Jul 31 12:31:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 12:31:27 +0100 (BST)
Received: from p508B6081.dip.t-dialin.net ([IPv6:::ffff:80.139.96.129]:32224
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225227AbTGaLbY>; Thu, 31 Jul 2003 12:31:24 +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 h6VBVMx6003916;
	Thu, 31 Jul 2003 13:31:22 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6VBVLXu003915;
	Thu, 31 Jul 2003 13:31:21 +0200
Date: Thu, 31 Jul 2003 13:31:21 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Teresa Tao <Teresat@tridentmicro.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mmap'ed memory cacheable or uncheable
Message-ID: <20030731113121.GB2718@linux-mips.org>
References: <61F6477DE6BED311B69F009027C3F58403AA3969@EXCHANGE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <61F6477DE6BED311B69F009027C3F58403AA3969@EXCHANGE>
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: 2937
X-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, Jul 24, 2003 at 08:26:59PM -0700, Teresa Tao wrote:

> I got a question regarding the mmap'ed memory. Is the mmap'ed memory
> cacheable or uncheable? My driver just use the remap_page_range to map
> a reserved physical memory.

Mmap(2) creates cachable mappings for everything below the highest memory
address and uncached above that.  That's a somewhat naive mechanism
which fails a few systems but somehow nobody did complain so far ...

  Ralf

From ralf@linux-mips.org Thu Jul 31 12:46:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 12:46:51 +0100 (BST)
Received: from p508B6081.dip.t-dialin.net ([IPv6:::ffff:80.139.96.129]:27361
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225207AbTGaLqt>; Thu, 31 Jul 2003 12:46: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 h6VBkjx6004210;
	Thu, 31 Jul 2003 13:46:45 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6VBkda4004209;
	Thu, 31 Jul 2003 13:46:39 +0200
Date: Thu, 31 Jul 2003 13:46:39 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
Message-ID: <20030731114639.GC2718@linux-mips.org>
References: <3F287738.1040203@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F287738.1040203@ict.ac.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: 2938
X-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, Jul 31, 2003 at 09:56:08AM +0800, Fuxin Zhang wrote:
> Date:	Thu, 31 Jul 2003 09:56:08 +0800
> From:	Fuxin Zhang <fxzhang@ict.ac.cn>
> To:	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
        ^^^^^^^^^^^^^^^^^^^^

Funny name for the list :-)

> r4k_cache_flush_sigtrap seems not enough for RM7000 cpus because
> there is a writebuffer between L1 dcache & L2 cache,so the written back
> block may not be seen by icache. This small patch fixes crashes of my
> Xserver on ev64240.

It would seem a similar fix is also needed in other places then?

  Ralf

From fxzhang@ict.ac.cn Thu Jul 31 13:58:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 13:58:33 +0100 (BST)
Received: from [IPv6:::ffff:159.226.39.4] ([IPv6:::ffff:159.226.39.4]:24277
	"HELO mail.ict.ac.cn") by linux-mips.org with SMTP
	id <S8225329AbTGaM6W>; Thu, 31 Jul 2003 13:58:22 +0100
Received: (qmail 27990 invoked from network); 31 Jul 2003 12:54:28 -0000
Received: from unknown (HELO ict.ac.cn) (159.226.40.150)
  by 159.226.39.4 with SMTP; 31 Jul 2003 12:54:28 -0000
Message-ID: <3F291257.6020704@ict.ac.cn>
Date: Thu, 31 Jul 2003 20:57:59 +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: Ralf Baechle <ralf@linux-mips.org>
CC: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: Re: RM7k cache_flush_sigtramp
References: <3F287738.1040203@ict.ac.cn> <20030731114639.GC2718@linux-mips.org>
In-Reply-To: <20030731114639.GC2718@linux-mips.org>
Content-Type: text/plain; charset=gb18030; format=flowed
Content-Transfer-Encoding: 7bit
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: 2939
X-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



Ralf Baechle wrote:

>On Thu, Jul 31, 2003 at 09:56:08AM +0800, Fuxin Zhang wrote:
>  
>
>>Date:	Thu, 31 Jul 2003 09:56:08 +0800
>>From:	Fuxin Zhang <fxzhang@ict.ac.cn>
>>To:	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
>>    
>>
>        ^^^^^^^^^^^^^^^^^^^^
>
>Funny name for the list :-)
>
>  
>
>>r4k_cache_flush_sigtrap seems not enough for RM7000 cpus because
>>there is a writebuffer between L1 dcache & L2 cache,so the written back
>>block may not be seen by icache. This small patch fixes crashes of my
>>Xserver on ev64240.
>>    
>>
>
>It would seem a similar fix is also needed in other places then?
>
I have not thought about it further. But
  1. I implement wb_flush for this board,using sync and uncached read. 
Just in case
      so many buffer on the cpu and system bridge will surprise me.
  2. There are still occasionally oops, especially with IO 
activities,e.g.,when fscking a disk.

What would should suggest to look at? Some flushes will go through all 
levels of cache,
I think they should be safe. Will check later.

Thanks.

>
>  Ralf
>
>
>
>  
>


From dkesselr@mmc.atmel.com Thu Jul 31 16:54:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 16:54:36 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:15889
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225222AbTGaPye>; Thu, 31 Jul 2003 16:54:34 +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 LAA26833
	for <linux-mips@linux-mips.org>; Thu, 31 Jul 2003 11:54:16 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id LAA06954
	for <linux-mips@linux-mips.org>; Thu, 31 Jul 2003 11:54:16 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 31 Jul 2003 11:54:15 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: linux-mips@linux-mips.org
Subject: mips64/setup.c
Message-ID: <Pine.GSO.4.44.0307311150440.6891-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: 2940
X-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

Is the file mips64/setup.c used? I believe that I see two problems in it;
1) The Ocelot options in setup_arch have case statements without a switch.
2) There is no option for Sead but the mips64 build for sead compiles
fine.
Is this some leftovers from some merging that has been talked about?

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


From Adam_Kiepul@pmc-sierra.com Thu Jul 31 17:50:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 17:50:58 +0100 (BST)
Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:19436 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225207AbTGaQu4>; Thu, 31 Jul 2003 17:50:56 +0100
Received: (qmail 21028 invoked by uid 104); 31 Jul 2003 16:50:47 -0000
Received: from Adam_Kiepul@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4281.  Clear:. 
 Processed in 0.530752 secs); 31 Jul 2003 16:50:47 -0000
Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236)
  by mother.pmc-sierra.com with SMTP; 31 Jul 2003 16:50:46 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogyruan.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id h6VHHLpD013520;
	Thu, 31 Jul 2003 10:17:24 -0700
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <P4MM4VJT>; Thu, 31 Jul 2003 09:50:37 -0700
Message-ID: <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02>
From: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
To: "'Ralf Baechle'" <ralf@linux-mips.org>,
	Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
Subject: RE: RM7k cache_flush_sigtramp
Date: Thu, 31 Jul 2003 09:50:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Return-Path: <Adam_Kiepul@pmc-sierra.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: 2941
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Adam_Kiepul@pmc-sierra.com
Precedence: bulk
X-list: linux-mips

Hi,

If this is just to ensure the I Cache coherency for modified code then the following should be sufficient:

cache Hit_Writeback_D, offset(base_register)
cache Hit_Invalidate_I, offset(base_register)

The ordering does matter however since the Hit_Invalidate_I makes sure the write buffer is flushed.

Kind Regards,

_______________________________

Adam Kiepul
Sr. Applications Engineer

PMC-Sierra, Microprocessor Division
Mission Towers One
3975 Freedom Circle
Santa Clara, CA 95054, USA
Direct: 408 239 8124
Fax: 408 492 9462



-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, July 31, 2003 4:47 AM
To: Fuxin Zhang
Cc: MAKE FUN PRANK CALLS
Subject: Re: RM7k cache_flush_sigtramp


On Thu, Jul 31, 2003 at 09:56:08AM +0800, Fuxin Zhang wrote:
> Date:	Thu, 31 Jul 2003 09:56:08 +0800
> From:	Fuxin Zhang <fxzhang@ict.ac.cn>
> To:	MAKE FUN PRANK CALLS <linux-mips@linux-mips.org>
        ^^^^^^^^^^^^^^^^^^^^

Funny name for the list :-)

> r4k_cache_flush_sigtrap seems not enough for RM7000 cpus because
> there is a writebuffer between L1 dcache & L2 cache,so the written back
> block may not be seen by icache. This small patch fixes crashes of my
> Xserver on ev64240.

It would seem a similar fix is also needed in other places then?

  Ralf

From ralf@linux-mips.org Thu Jul 31 17:52:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 17:52:30 +0100 (BST)
Received: from p508B6081.dip.t-dialin.net ([IPv6:::ffff:80.139.96.129]:13446
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225207AbTGaQw2>; Thu, 31 Jul 2003 17:52:28 +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 h6VGqRx6010887;
	Thu, 31 Jul 2003 18:52:27 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6VGqQID010886;
	Thu, 31 Jul 2003 18:52:26 +0200
Date: Thu, 31 Jul 2003 18:52:26 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mips64/setup.c
Message-ID: <20030731165225.GA9566@linux-mips.org>
References: <Pine.GSO.4.44.0307311150440.6891-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0307311150440.6891-100000@ares.mmc.atmel.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: 2942
X-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, Jul 31, 2003 at 11:54:15AM -0400, David Kesselring wrote:

> Is the file mips64/setup.c used? I believe that I see two problems in it;
> 1) The Ocelot options in setup_arch have case statements without a switch.

Ocelot 64-bit kernel is currently work in progress.  A first cut of
the patch was posted to this mailing list a few days ago.

> 2) There is no option for Sead but the mips64 build for sead compiles
>    fine.

The fun of when two almost identical files go out of sync.

> Is this some leftovers from some merging that has been talked about?

No.  The big merge thing did only happen in 2.6.  It's way to intrusive
for 2.4.

  Ralf

From jsun@mvista.com Thu Jul 31 18:36:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 18:36:36 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:4094 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225229AbTGaRge>;
	Thu, 31 Jul 2003 18:36:34 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6VHaTd05947;
	Thu, 31 Jul 2003 10:36:29 -0700
Date: Thu, 31 Jul 2003 10:36:29 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Malta + USB on 2.4, anyone?
Message-ID: <20030731103629.D14914@mvista.com>
References: <20030730191219.A14914@mvista.com> <Pine.GSO.3.96.1030731121705.17497D-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030731121705.17497D-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Jul 31, 2003 at 12:26:44PM +0200
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2943
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jul 31, 2003 at 12:26:44PM +0200, Maciej W. Rozycki wrote:
> On Wed, 30 Jul 2003, Jun Sun wrote:
> 
> > Has anybody tried USB on malta with 2.4 kernel?  I just found that
> > I got 0xff IRQ number and kernel panics.
> 
>  Possibly IRQ routing is broken -- the PIIX4 uses INTD for its USB
> controller's interrupt.  For the Malta it should be routed to the IRQ11
> input of the PIIX4's internal dual-8259A PIC.  What does `/sbin/lspci -vv
> -s 00:0a.2' print?
>

The output seems to say the same thing:

root@10.0.18.6:~# lspci -vv -s 00:0a.2                                          
00:0a.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00
 [UHCI])                                                                        
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-                                                            
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-                                                        
        Latency: 32                                                             
        Interrupt: pin D routed to IRQ 11                                       
        Region 4: I/O ports at 1220 [size=32]                                   
                                                                                
Jun

From jsun@mvista.com Thu Jul 31 18:37:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 18:37:54 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27886 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225229AbTGaRhw>;
	Thu, 31 Jul 2003 18:37:52 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6VHboK06262;
	Thu, 31 Jul 2003 10:37:50 -0700
Date: Thu, 31 Jul 2003 10:37:50 -0700
From: Jun Sun <jsun@mvista.com>
To: Chris Dearman <chris@mips.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Malta + USB on 2.4, anyone?
Message-ID: <20030731103750.E14914@mvista.com>
References: <20030730191219.A14914@mvista.com> <3F28E702.70401@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3F28E702.70401@mips.com>; from chris@mips.com on Thu, Jul 31, 2003 at 10:53:06AM +0100
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2944
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jul 31, 2003 at 10:53:06AM +0100, Chris Dearman wrote:
> Jun Sun wrote:
> > Has anybody tried USB on malta with 2.4 kernel?  I just found that
> > I got 0xff IRQ number and kernel panics.
> 
> > Also, the kgdb seems to be flaky.  Targets can send chars too fast
> > so that chars get lost.  It appears that the linux status register
> > might be lying about "transmitter buffer empty".  
> 
>    I regularly use gdb @ 115200 on Malta and haven't noticed any problems.
>

Yes.  I notice that kgdb generally works, but gets flaky when I hit
this particular problem.  That makes me wonder maybe something gets
very wrong with the controller chip....

Keep debugging ...

Jun

From jsun@mvista.com Thu Jul 31 19:15:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 19:15:12 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:50927 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225207AbTGaSPK>;
	Thu, 31 Jul 2003 19:15:10 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h6VIF6Z07582;
	Thu, 31 Jul 2003 11:15:06 -0700
Date: Thu, 31 Jul 2003 11:15:06 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Malta + USB on 2.4, anyone?
Message-ID: <20030731111506.F14914@mvista.com>
References: <20030730191219.A14914@mvista.com> <Pine.GSO.3.96.1030731121705.17497D-100000@delta.ds2.pg.gda.pl> <20030731103629.D14914@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030731103629.D14914@mvista.com>; from jsun@mvista.com on Thu, Jul 31, 2003 at 10:36:29AM -0700
Return-Path: <jsun@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 2945
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jul 31, 2003 at 10:36:29AM -0700, Jun Sun wrote:
> On Thu, Jul 31, 2003 at 12:26:44PM +0200, Maciej W. Rozycki wrote:
> > On Wed, 30 Jul 2003, Jun Sun wrote:
> > 
> > > Has anybody tried USB on malta with 2.4 kernel?  I just found that
> > > I got 0xff IRQ number and kernel panics.
> > 
> >  Possibly IRQ routing is broken -- the PIIX4 uses INTD for its USB
> > controller's interrupt.  For the Malta it should be routed to the IRQ11
> > input of the PIIX4's internal dual-8259A PIC.  What does `/sbin/lspci -vv
> > -s 00:0a.2' print?
> >
> 
> The output seems to say the same thing:
> 
> root@10.0.18.6:~# lspci -vv -s 00:0a.2                                          
> 00:0a.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00
>  [UHCI])                                                                        
>         Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
> ping- SERR- FastB2B-                                                            
>         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
> - <MAbort- >SERR- <PERR-                                                        
>         Latency: 32                                                             
>         Interrupt: pin D routed to IRQ 11                                       
>         Region 4: I/O ports at 1220 [size=32]                                   
> 

Using the alternative JE driver sovles the problem.  

I suspect the main UHCI driver does not get cache flushing
or bus/virt address right.


Jun

From dkesselr@mmc.atmel.com Thu Jul 31 19:22:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 19:22:55 +0100 (BST)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:24110
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225207AbTGaSWw>; Thu, 31 Jul 2003 19:22:52 +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 OAA28612;
	Thu, 31 Jul 2003 14:22:46 -0400 (EDT)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id OAA07037;
	Thu, 31 Jul 2003 14:22:45 -0400 (EDT)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Thu, 31 Jul 2003 14:22:45 -0400 (EDT)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: mips64/setup.c
In-Reply-To: <20030731165225.GA9566@linux-mips.org>
Message-ID: <Pine.GSO.4.44.0307311421110.6891-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: 2946
X-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

On Thu, 31 Jul 2003, Ralf Baechle wrote:

> On Thu, Jul 31, 2003 at 11:54:15AM -0400, David Kesselring wrote:
>
> > Is the file mips64/setup.c used? I believe that I see two problems in it;
> > 1) The Ocelot options in setup_arch have case statements without a switch.
>
> Ocelot 64-bit kernel is currently work in progress.  A first cut of
> the patch was posted to this mailing list a few days ago.
>
> > 2) There is no option for Sead but the mips64 build for sead compiles
> >    fine.
>
> The fun of when two almost identical files go out of sync.
Then do you know what is happening when 64bit sead is configured? Why
doesn't the compile fail?



>
> > Is this some leftovers from some merging that has been talked about?
>
> No.  The big merge thing did only happen in 2.6.  It's way to intrusive
> for 2.4.
>
>   Ralf
>
>

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


From hamilton@redhat.com Thu Jul 31 20:59:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 20:59:07 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:39690 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225229AbTGaT7E>;
	Thu, 31 Jul 2003 20:59:04 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h6VJx3Z02660
	for <linux-mips@linux-mips.org>; Thu, 31 Jul 2003 15:59:03 -0400
Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6VJx2I19672
	for <linux-mips@linux-mips.org>; Thu, 31 Jul 2003 15:59:02 -0400
Received: from redhat.com (slurm.hsv.redhat.com [172.16.16.102])
	by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id h6VJx1m09471
	for <linux-mips@linux-mips.org>; Thu, 31 Jul 2003 14:59:01 -0500
Message-ID: <3F297585.6030900@redhat.com>
Date: Thu, 31 Jul 2003 15:01:09 -0500
From: Louis Hamilton <hamilton@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
X-Accept-Language: en-us
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: [patch] include/asm-mips{64}/war.h
Content-Type: multipart/mixed;
 boundary="------------050200060903080700020907"
Return-Path: <hamilton@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: 2947
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hamilton@redhat.com
Precedence: bulk
X-list: linux-mips

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

Small typo fix in war.h
-Louis

Louis Hamilton     hamilton@redhat.com



--------------050200060903080700020907
Content-Type: text/plain;
 name="warpatch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="warpatch"

--- war.h.base	2003-07-31 14:43:19.000000000 -0500
+++ war.h	2003-07-31 14:05:51.000000000 -0500
@@ -168,7 +168,7 @@
 #define MIPS4K_ICACHE_REFILL_WAR	0
 #endif
 #ifndef MIPS_CACHE_SYNC_WAR
-#deifne MIPS_CACHE_SYNC_WAR		0
+#define MIPS_CACHE_SYNC_WAR		0
 #endif
 
 #endif /* _ASM_WAR_H */

--------------050200060903080700020907--


From ralf@linux-mips.org Thu Jul 31 21:17:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 21:17:18 +0100 (BST)
Received: from p508B6081.dip.t-dialin.net ([IPv6:::ffff:80.139.96.129]:39570
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225229AbTGaURQ>; Thu, 31 Jul 2003 21:17: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 h6VKHEx6017581;
	Thu, 31 Jul 2003 22:17:14 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6VKHD0v017580;
	Thu, 31 Jul 2003 22:17:13 +0200
Date: Thu, 31 Jul 2003 22:17:13 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mips64/setup.c
Message-ID: <20030731201713.GA13263@linux-mips.org>
References: <20030731165225.GA9566@linux-mips.org> <Pine.GSO.4.44.0307311421110.6891-100000@ares.mmc.atmel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0307311421110.6891-100000@ares.mmc.atmel.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: 2948
X-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, Jul 31, 2003 at 02:22:45PM -0400, David Kesselring wrote:

> > On Thu, Jul 31, 2003 at 11:54:15AM -0400, David Kesselring wrote:
> >
> > > Is the file mips64/setup.c used? I believe that I see two problems in it;
> > > 1) The Ocelot options in setup_arch have case statements without a switch.
> >
> > Ocelot 64-bit kernel is currently work in progress.  A first cut of
> > the patch was posted to this mailing list a few days ago.
> >
> > > 2) There is no option for Sead but the mips64 build for sead compiles
> > >    fine.
> >
> > The fun of when two almost identical files go out of sync.
> Then do you know what is happening when 64bit sead is configured? Why
> doesn't the compile fail?

This is easy, there is a function call missing which won't cause an
error message unlike a missing function.  Don't ask me why - it just seems
the 64-bit SEAD port was never completly sent to me or so.  Anyway, I
just fixed this in the linux_2_4 CVS branch; as the result of merging
mips with mips64 this bug was magically dealt with in 2.6.

  Ralf

From ralf@linux-mips.org Thu Jul 31 23:09:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 23:09:15 +0100 (BST)
Received: from p508B6081.dip.t-dialin.net ([IPv6:::ffff:80.139.96.129]:46233
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225207AbTGaWJL>; Thu, 31 Jul 2003 23:09:11 +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 h6VM9Ax6027033;
	Fri, 1 Aug 2003 00:09:10 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id h6VM9Anj027032;
	Fri, 1 Aug 2003 00:09:10 +0200
Date: Fri, 1 Aug 2003 00:09:10 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Louis Hamilton <hamilton@redhat.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] include/asm-mips{64}/war.h
Message-ID: <20030731220909.GC20929@linux-mips.org>
References: <3F297585.6030900@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F297585.6030900@redhat.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: 2949
X-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, Jul 31, 2003 at 03:01:09PM -0500, Louis Hamilton wrote:

> Small typo fix in war.h

This I already fixed a few minutes ago :-)

  Ralf

From foerstemann@web.de Thu Jul 31 23:27:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Jul 2003 23:27:44 +0100 (BST)
Received: from mailgate5.cinetic.de ([IPv6:::ffff:217.72.192.165]:62410 "EHLO
	mailgate5.cinetic.de") by linux-mips.org with ESMTP
	id <S8225207AbTGaW1m>; Thu, 31 Jul 2003 23:27:42 +0100
Received: from web.de (fmomail03.dlan.cinetic.de [172.20.1.236])
	by mailgate5.cinetic.de (8.11.6p2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id h6VMRaQ26570;
	Fri, 1 Aug 2003 00:27:36 +0200
Date: Fri, 1 Aug 2003 00:27:36 +0200
Message-Id: <200307312227.h6VMRaQ26570@mailgate5.cinetic.de>
MIME-Version: 1.0
Organization: http://freemail.web.de/
From: =?iso-8859-1?Q? "Frank=20F=F6rstemann" ?= <foerstemann@web.de>
To: "RalfBaechle" <ralf@linux-mips.org>
Cc: "linux-mips" <linux-mips@linux-mips.org>
Subject: Re: No mouse support for Indy in 2.5.75 ?
Precedence: fm-user
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Return-Path: <foerstemann@web.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: 2950
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: foerstemann@web.de
Precedence: bulk
X-list: linux-mips

Am Mit, 2003-07-30 um 13.23 schrieb Ralf Baechle:
> On Wed, Jul 30, 2003 at 07:54:25AM +0200, =?iso-8859-1?Q? Frank=20F=F6rstemann ?= wrote:
> 
> > Is there any additional information I can collect on these issues ?
> 
> Well, as for the PS/2 issues, you'll have to read through the code yourself,
> nobody's digged into that so far.
> 

Hm, seems to be easier to stay at 2.4.x for the moment. I'll have a look
when I find some time...

> > > mount: Exception at [<88113a38>] (88113bf0)
> > > mount: Exception at [<88113a38>] (88113bf0)
> > > mount: Exception at [<88113a38>] (88113bf0)
> 
> The kernel messages otoh are not sign of a kernel but an application bug.
> It seems mount did pass bad addresses to the kernel through some syscall;
> these messages are the sign of the normal mechanism to intercept bad
> address arguments to syscall kicking in.  You won't get those messages
> anymore in 2.6 btw.  The kernel only print's them if the second digit of
> the version number is odd, see development_version in arch/mips/mm/fault.c.

.... which means that this problem might well be an old one, because my standard
kernel is a 2.4.

> 
>   Ralf
> 

Frank

______________________________________________________________________________
Spam-Filter fuer alle - bester Spam-Schutz laut ComputerBild 15-03
WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021120