From jsun@orion.mvista.com Fri Nov  1 20:25:00 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Nov 2002 20:25:04 +0100 (CET)
Received: from gateway-1237.mvista.com ([12.44.186.158]:12278 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S1121744AbSKATYJ>;
	Fri, 1 Nov 2002 20:24:09 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id gA1JO0W03948;
	Fri, 1 Nov 2002 11:24:00 -0800
Date: Fri, 1 Nov 2002 11:24:00 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com, Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH, 2.4&2.5, 32bit&64bit] new fpu code
Message-ID: <20021101112400.A2429@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@orion.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: 550
X-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


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


Whew!  What an effort to create a patch for 4 arches instead of one!

Anyhow, attached are the complete patches for the new FPU context 
management code, for both 2.4 and 2.5, 32bit and 64bit.

. Get rid of lazy fpu switch.  New algorithm is SMP safe.
. Simplify signal/fpu handling
. Simplify FPU register access
. Unify FPU code between 2.4 and 2.5, and between 32bit and 64bit

Ralf, good enough?

Jun

--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="021101.24-new-fpu-complete.patch"

diff -Nru link/arch/mips/kernel/process.c.orig link/arch/mips/kernel/process.c
--- link/arch/mips/kernel/process.c.orig	Tue Jul  2 08:47:33 2002
+++ link/arch/mips/kernel/process.c	Mon Oct 28 11:00:44 2002
@@ -21,6 +21,7 @@
 
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/mipsregs.h>
@@ -47,28 +48,25 @@
 	}
 }
 
-struct task_struct *last_task_used_math = NULL;
-
 asmlinkage void ret_from_fork(void);
 
+void start_thread(struct pt_regs * regs, unsigned long pc, unsigned long sp)
+{
+	regs->cp0_status &= ~(ST0_CU0|ST0_KSU|ST0_CU1);
+       	regs->cp0_status |= KU_USER;
+	current->used_math = 0;
+	loose_fpu();
+	regs->cp0_epc = pc;
+	regs->regs[29] = sp;
+	current->thread.current_ds = USER_DS;
+}
+
 void exit_thread(void)
 {
-	/* Forget lazy fpu state */
-	if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) {
-		__enable_fpu();
-		__asm__ __volatile__("cfc1\t$0,$31");
-		last_task_used_math = NULL;
-	}
 }
 
 void flush_thread(void)
 {
-	/* Forget lazy fpu state */
-	if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) {
-		__enable_fpu();
-		__asm__ __volatile__("cfc1\t$0,$31");
-		last_task_used_math = NULL;
-	}
 }
 
 int copy_thread(int nr, unsigned long clone_flags, unsigned long usp,
@@ -80,11 +78,10 @@
 
 	childksp = (unsigned long)p + KERNEL_STACK_SIZE - 32;
 
-	if (last_task_used_math == current)
-		if (mips_cpu.options & MIPS_CPU_FPU) {
-			__enable_fpu();
-			save_fp(p);
-		}
+	if (is_fpu_owner()) {
+		save_fp(p);
+	}
+	
 	/* set up new TSS. */
 	childregs = (struct pt_regs *) childksp - 1;
 	*childregs = *regs;
diff -Nru link/arch/mips/kernel/ptrace.c.orig link/arch/mips/kernel/ptrace.c
--- link/arch/mips/kernel/ptrace.c.orig	Mon Oct  7 07:34:14 2002
+++ link/arch/mips/kernel/ptrace.c	Mon Oct 28 11:08:26 2002
@@ -27,6 +27,7 @@
 #include <asm/uaccess.h>
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 
 /*
  * Called by kernel/ptrace.c when detaching..
@@ -42,7 +43,6 @@
 {
 	struct task_struct *child;
 	int ret;
-	extern void save_fp(struct task_struct *);
 
 	lock_kernel();
 #if 0
@@ -113,20 +113,7 @@
 			break;
 		case FPR_BASE ... FPR_BASE + 31:
 			if (child->used_math) {
-			        unsigned long long *fregs
-					= (unsigned long long *)
-					    &child->thread.fpu.hard.fp_regs[0];
-			 	if(!(mips_cpu.options & MIPS_CPU_FPU)) {
-					fregs = (unsigned long long *)
-						child->thread.fpu.soft.regs;
-				} else
-					if (last_task_used_math == child) {
-						__enable_fpu();
-						save_fp(child);
-						__disable_fpu();
-						last_task_used_math = NULL;
-						regs->cp0_status &= ~ST0_CU1;
-					}
+			        unsigned long long *fregs = get_fpu_regs(child);
 				/*
 				 * The odd registers are actually the high
 				 * order bits of the values stored in the even
@@ -204,21 +191,8 @@
 			break;
 		case FPR_BASE ... FPR_BASE + 31: {
 			unsigned long long *fregs;
-			fregs = (unsigned long long *)&child->thread.fpu.hard.fp_regs[0];
-			if (child->used_math) {
-				if (last_task_used_math == child) {
-					if(!(mips_cpu.options & MIPS_CPU_FPU)) {
-						fregs = (unsigned long long *)
-						child->thread.fpu.soft.regs;
-					} else {
-						__enable_fpu();
-						save_fp(child);
-						__disable_fpu();
-						last_task_used_math = NULL;
-						regs->cp0_status &= ~ST0_CU1;
-					}
-				}
-			} else {
+			fregs = (unsigned long long *)get_fpu_regs(child);
+			if (!child->used_math) {
 				/* FP not yet used  */
 				memset(&child->thread.fpu.hard, ~0,
 				       sizeof(child->thread.fpu.hard));
diff -Nru link/arch/mips/kernel/signal.c.orig link/arch/mips/kernel/signal.c
--- link/arch/mips/kernel/signal.c.orig	Mon Aug  5 16:53:33 2002
+++ link/arch/mips/kernel/signal.c	Fri Nov  1 10:07:27 2002
@@ -22,6 +22,7 @@
 #include <asm/asm.h>
 #include <asm/bitops.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/offset.h>
 #include <asm/pgalloc.h>
 #include <asm/ptrace.h>
@@ -34,9 +35,6 @@
 
 extern asmlinkage int do_signal(sigset_t *oldset, struct pt_regs *regs);
 
-extern asmlinkage int (*save_fp_context)(struct sigcontext *sc);
-extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
-
 extern asmlinkage void syscall_trace(void);
 
 int copy_siginfo_to_user(siginfo_t *to, siginfo_t *from)
@@ -185,59 +183,8 @@
 	return do_sigaltstack(uss, uoss, usp);
 }
 
-static inline int restore_thread_fp_context(struct sigcontext *sc)
-{
-	u64 *pfreg = &current->thread.fpu.soft.regs[0];
-	int err = 0;
-
-	/*
-	 * Copy all 32 64-bit values, for two reasons.  First, the R3000 and
-	 * R4000/MIPS32 kernels use the thread FP register storage differently,
-	 * such that a full copy is essentially necessary to support both.
-	 */
-
-#define restore_fpr(i) 						\
-	do { err |= __get_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-	restore_fpr( 0); restore_fpr( 1); restore_fpr( 2); restore_fpr( 3);
-	restore_fpr( 4); restore_fpr( 5); restore_fpr( 6); restore_fpr( 7);
-	restore_fpr( 8); restore_fpr( 9); restore_fpr(10); restore_fpr(11);
-	restore_fpr(12); restore_fpr(13); restore_fpr(14); restore_fpr(15);
-	restore_fpr(16); restore_fpr(17); restore_fpr(18); restore_fpr(19);
-	restore_fpr(20); restore_fpr(21); restore_fpr(22); restore_fpr(23);
-	restore_fpr(24); restore_fpr(25); restore_fpr(26); restore_fpr(27);
-	restore_fpr(28); restore_fpr(29); restore_fpr(30); restore_fpr(31);
-
-	err |= __get_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-	return err;
-}
-
-static inline int save_thread_fp_context(struct sigcontext *sc)
-{
-	u64 *pfreg = &current->thread.fpu.soft.regs[0];
-	int err = 0;
-
-#define save_fpr(i) 							\
-	do { err |= __put_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-	save_fpr( 0); save_fpr( 1); save_fpr( 2); save_fpr( 3);
-	save_fpr( 4); save_fpr( 5); save_fpr( 6); save_fpr( 7);
-	save_fpr( 8); save_fpr( 9); save_fpr(10); save_fpr(11);
-	save_fpr(12); save_fpr(13); save_fpr(14); save_fpr(15);
-	save_fpr(16); save_fpr(17); save_fpr(18); save_fpr(19);
-	save_fpr(20); save_fpr(21); save_fpr(22); save_fpr(23);
-	save_fpr(24); save_fpr(25); save_fpr(26); save_fpr(27);
-	save_fpr(28); save_fpr(29); save_fpr(30); save_fpr(31);
-
-	err |= __put_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-	return err;
-}
-
 static int restore_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 	u64 reg;
 
@@ -265,25 +212,17 @@
 	restore_gp_reg(31);
 #undef restore_gp_reg
 
-	err |= __get_user(owned_fp, &sc->sc_ownedfp);
 	err |= __get_user(current->used_math, &sc->sc_used_math);
 
-	if (owned_fp) {
-		err |= restore_fp_context(sc);
-		goto out;
-	}
-
-	if (current == last_task_used_math) {
-		/* Signal handler acquired FPU - give it back */
-		last_task_used_math = NULL;
-		regs->cp0_status &= ~ST0_CU1;
-	}
 	if (current->used_math) {
-		/* Undo possible contamination of thread state */
-		err |= restore_thread_fp_context(sc);
+		/* restore fpu context if we have used it before */
+		own_fpu();
+		err |= restore_fp_context(sc);
+	} else {
+		/* signal handler may have used FPU.  Give it up. */
+		loose_fpu();
 	}
 
-out:
 	return err;
 }
 
@@ -380,7 +319,6 @@
 
 static int inline setup_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 	u64 reg;
 
@@ -408,25 +346,20 @@
 	err |= __put_user(regs->cp0_cause, &sc->sc_cause);
 	err |= __put_user(regs->cp0_badvaddr, &sc->sc_badvaddr);
 
-	owned_fp = (current == last_task_used_math);
-	err |= __put_user(owned_fp, &sc->sc_ownedfp);
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
 	if (!current->used_math)
 		goto out;
 
-	/* There exists FP thread state that may be trashed by signal */
-	if (owned_fp) {
-		/* fp is active.  Save context from FPU */
-		err |= save_fp_context(sc);
-		goto out;
-	}
-
-	/*
-	 * Someone else has FPU.
-	 * Copy Thread context into signal context
+	/* 
+	 * Save FPU state to signal context.  Signal handler will "inherit"
+	 * current FPU state.
 	 */
-	err |= save_thread_fp_context(sc);
+	if (!is_fpu_owner()) {
+		own_fpu();
+		restore_fp(current);
+	}
+	err |= save_fp_context(sc);
 
 out:
 	return err;
diff -Nru link/arch/mips/kernel/traps.c.orig link/arch/mips/kernel/traps.c
--- link/arch/mips/kernel/traps.c.orig	Thu Oct 31 11:40:09 2002
+++ link/arch/mips/kernel/traps.c	Mon Oct 28 11:46:35 2002
@@ -24,6 +24,7 @@
 #include <asm/bootinfo.h>
 #include <asm/branch.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/cachectl.h>
 #include <asm/inst.h>
 #include <asm/jazz.h>
@@ -677,49 +678,33 @@
 asmlinkage void do_cpu(struct pt_regs *regs)
 {
 	unsigned int cpid;
-	void fpu_emulator_init_fpu(void);
-	int sig;
 
 	cpid = (regs->cp0_cause >> CAUSEB_CE) & 3;
 	if (cpid != 1)
 		goto bad_cid;
 
-	if (!(mips_cpu.options & MIPS_CPU_FPU))
-		goto fp_emul;
-
-	regs->cp0_status |= ST0_CU1;
-	if (last_task_used_math == current)
-		return;
+	die_if_kernel("do_cpu invoked from kernel context!", regs);
 
+	own_fpu();
 	if (current->used_math) {		/* Using the FPU again.  */
-		lazy_fpu_switch(last_task_used_math);
+		restore_fp(current);
 	} else {				/* First time FPU user.  */
-		if (last_task_used_math != NULL)
-			save_fp(last_task_used_math);
 		init_fpu();
 		current->used_math = 1;
 	}
-	last_task_used_math = current;
 
-	return;
-
-fp_emul:
-	if (last_task_used_math != current) {
-		if (!current->used_math) {
-			fpu_emulator_init_fpu();
-			current->used_math = 1;
+	if (!(mips_cpu.options & MIPS_CPU_FPU)) {
+		int sig = fpu_emulator_cop1Handler(0, regs, &current->thread.fpu.soft);
+		if (sig) {
+			/*
+		 	 * Return EPC is not calculated in the FPU emulator, if
+		   	 * a signal is being send. So we calculate it here.
+		 	 */
+			compute_return_epc(regs);
+			force_sig(sig, current);
 		}
 	}
-	sig = fpu_emulator_cop1Handler(0, regs, &current->thread.fpu.soft);
-	last_task_used_math = current;
-	if (sig) {
-		/*
-		 * Return EPC is not calculated in the FPU emulator, if
-		 * a signal is being send. So we calculate it here.
-		 */
-		compute_return_epc(regs);
-		force_sig(sig, current);
-	}
+
 	return;
 
 bad_cid:
@@ -901,6 +886,7 @@
 
 asmlinkage int (*save_fp_context)(struct sigcontext *sc);
 asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
+
 extern asmlinkage int _save_fp_context(struct sigcontext *sc);
 extern asmlinkage int _restore_fp_context(struct sigcontext *sc);
 
diff -Nru link/arch/mips/kernel/r2300_switch.S.orig link/arch/mips/kernel/r2300_switch.S
--- link/arch/mips/kernel/r2300_switch.S.orig	Tue May 28 20:03:17 2002
+++ link/arch/mips/kernel/r2300_switch.S	Fri Nov  1 11:02:59 2002
@@ -28,6 +28,19 @@
 	.set	mips1
 	.align	5
 
+#define PF_USEDFPU      0x00100000      /* task used FPU this quantum (SMP) */
+#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
+
+/*
+ * [jsun] FPU context is saved if and only if the process has used FPU in 
+ * the current run (PF_USEDFPU).  In any case, the CU1 bit for user space 
+ * STATUS register should be 0, so that a process *always* starts its 
+ * userland with FPU disabled after each context switch.
+ *
+ * FPU will be enabled as soon as the process accesses FPU again, through
+ * do_cpu() trap.
+ */
+
 /*
  * task_struct *resume(task_struct *prev,
  *                     task_struct *next)
@@ -41,6 +54,32 @@
 	CPU_SAVE_NONSCRATCH(a0)
 	sw	ra, THREAD_REG31(a0)
 
+	/* 
+	 * check if we need to save FPU registers
+	 */
+	lw	t0, TASK_FLAGS(a0)
+	li	t1, PF_USEDFPU
+	and	t2, t0, t1
+	beqz	t2, 1f
+	nor	t1, zero, t1
+
+	/*
+	 * clear PF_USEDFPU bit in task flags
+	 */
+	and	t0, t0, t1
+	sw	t0, TASK_FLAGS(a0)
+
+	/*
+	 * clear user-saved stack CU1 bit
+	 */
+	lw	t0, ST_OFF(a0)
+	li	t1, ~ST0_CU1
+	and	t0, t0, t1
+	sw	t0, ST_OFF(a0)
+
+	FPU_SAVE_SINGLE(a0, t0)			# clobbers t0
+
+1:
 	/*
 	 * The order of restoring the registers takes care of the race
 	 * updating $28, $29 and kernelsp without disabling ints.
@@ -64,47 +103,20 @@
 	END(resume)
 
 /*
- * Do lazy fpu context switch.  Saves FPU context to the process in a0
- * and loads the new context of the current process.
- */
-
-#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
-
-LEAF(lazy_fpu_switch)
-	mfc0	t0, CP0_STATUS			# enable cp1
-	li	t3, ST0_CU1
-	or	t0, t3
-	mtc0	t0, CP0_STATUS
-
-	.set	noreorder
-	beqz	a0, 2f				# Save floating point state
-	 nor	t3, zero, t3
-	.set	reorder
-	lw	t1, ST_OFF(a0)			# last thread looses fpu
-	and	t1, t3
-	sw	t1, ST_OFF(a0)
-	FPU_SAVE_SINGLE(a0, t1)			# clobbers t1
-
-2:
-	FPU_RESTORE_SINGLE($28, t0)		# clobbers t0
-	jr	ra
-	END(lazy_fpu_switch)
-
-/*
  * Save a thread's fp context.
  */
-LEAF(save_fp)
+LEAF(_save_fp)
 	FPU_SAVE_SINGLE(a0, t1)			# clobbers t1
 	jr	ra
-	END(save_fp)
+	END(_save_fp)
 
 /*
  * Restore a thread's fp context.
  */
-LEAF(restore_fp)
+LEAF(_restore_fp)
 	FPU_RESTORE_SINGLE(a0, t1)		# clobbers t1
 	jr	ra
-	END(restore_fp)
+	END(_restore_fp)
 
 /*
  * Load the FPU with signalling NANS.  This bit pattern we're using has
@@ -116,7 +128,7 @@
 
 #define FPU_DEFAULT  0x00000000
 
-LEAF(init_fpu)
+LEAF(_init_fpu)
 	mfc0	t0, CP0_STATUS
 	li	t1, ST0_CU1
 	or	t0, t1
@@ -162,4 +174,4 @@
 	jr	ra
 	 mtc1	t0, $f31
 	.set	reorder
-	END(init_fpu)
+	END(_init_fpu)
diff -Nru link/arch/mips/kernel/r4k_switch.S.orig link/arch/mips/kernel/r4k_switch.S
--- link/arch/mips/kernel/r4k_switch.S.orig	Mon Aug  5 16:53:33 2002
+++ link/arch/mips/kernel/r4k_switch.S	Fri Nov  1 09:49:39 2002
@@ -25,6 +25,19 @@
 
 #include <asm/asmmacro.h>
 
+#define PF_USEDFPU      0x00100000      /* task used FPU this quantum (SMP) */
+#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
+
+/*
+ * [jsun] FPU context is saved if and only if the process has used FPU in 
+ * the current run (PF_USEDFPU).  In any case, the CU1 bit for user space 
+ * STATUS register should be 0, so that a process *always* starts its 
+ * userland with FPU disabled after each context switch.
+ *
+ * FPU will be enabled as soon as the process accesses FPU again, through 
+ * do_cpu() trap.
+ */
+
 /*
  * task_struct *r4xx0_resume(task_struct *prev, task_struct *next)
  */
@@ -39,6 +52,32 @@
 	CPU_SAVE_NONSCRATCH(a0)
 	sw	ra, THREAD_REG31(a0)
 
+	/* 
+	 * check if we need to save FPU registers
+	 */
+	lw	t0, TASK_FLAGS(a0)
+	li	t1, PF_USEDFPU
+	and	t2, t0, t1
+	beqz	t2, 1f
+	nor	t1, zero, t1
+
+	/*
+	 * clear PF_USEDFPU bit in task flags
+	 */
+	and	t0, t0, t1
+	sw	t0, TASK_FLAGS(a0)
+
+	/*
+	 * clear saved user stack CU1 bit
+	 */
+	lw	t0, ST_OFF(a0)
+	li	t1, ~ST0_CU1
+	and	t0, t0, t1
+	sw	t0, ST_OFF(a0)
+
+	FPU_SAVE_DOUBLE(a0, t0)			# clobbers t0
+
+1:
 	/*
 	 * The order of restoring the registers takes care of the race
 	 * updating $28, $29 and kernelsp without disabling ints.
@@ -69,50 +108,20 @@
 	END(resume)
 
 /*
- * Do lazy fpu context switch.  Saves FPU context to the process in a0
- * and loads the new context of the current process.
- */
-
-#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
-
-LEAF(lazy_fpu_switch)
-	mfc0	t0, CP0_STATUS			# enable cp1
-	li	t3, ST0_CU1
-	or	t0, t3
-	mtc0	t0, CP0_STATUS
-	FPU_ENABLE_HAZARD
-
-	beqz	a0, 2f				# Save floating point state
-	 nor	t3, zero, t3
-
-	lw	t1, ST_OFF(a0)			# last thread looses fpu
-	and	t1, t3
-	sw	t1, ST_OFF(a0)
-
-
-	FPU_SAVE_DOUBLE(a0, t1)			# clobbers t1
-2:
-
-	.set	reorder
-	FPU_RESTORE_DOUBLE($28, t0)		# clobbers t0
-	jr	ra
-	END(lazy_fpu_switch)
-
-/*
  * Save a thread's fp context.
  */
-LEAF(save_fp)
+LEAF(_save_fp)
 	FPU_SAVE_DOUBLE(a0, t1)			# clobbers t1
 	jr	ra
-	END(save_fp)
+	END(_save_fp)
 
 /*
  * Restore a thread's fp context.
  */
-LEAF(restore_fp)
+LEAF(_restore_fp)
 	FPU_RESTORE_DOUBLE(a0, t1)		# clobbers t1
 	jr	ra
-	END(restore_fp)
+	END(_restore_fp)
 
 /*
  * Load the FPU with signalling NANS.  This bit pattern we're using has
@@ -124,7 +133,7 @@
 
 #define FPU_DEFAULT  0x00000000
 
-LEAF(init_fpu)
+LEAF(_init_fpu)
 	.set	mips3
 	mfc0	t0, CP0_STATUS
 	li	t1, ST0_CU1
@@ -156,5 +165,5 @@
 	jr	ra
 	 dmtc1	t0, $f30
 	.set	reorder
-	END(init_fpu)
+	END(_init_fpu)
 
diff -Nru link/arch/mips/kernel/cpu-probe.c.orig link/arch/mips/kernel/cpu-probe.c
--- link/arch/mips/kernel/cpu-probe.c.orig	Mon Sep  2 07:41:19 2002
+++ link/arch/mips/kernel/cpu-probe.c	Mon Oct 28 13:21:35 2002
@@ -3,6 +3,7 @@
 #include <linux/stddef.h>
 #include <asm/bugs.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/mipsregs.h>
 
 /*
diff -Nru link/arch/mips/tools/offset.c.orig link/arch/mips/tools/offset.c
--- link/arch/mips/tools/offset.c.orig	Tue Jul 23 06:27:07 2002
+++ link/arch/mips/tools/offset.c	Mon Oct 28 10:56:40 2002
@@ -151,7 +151,6 @@
 	offset("#define SC_MDLO       ", struct sigcontext, sc_mdlo);
 	offset("#define SC_PC         ", struct sigcontext, sc_pc);
 	offset("#define SC_STATUS     ", struct sigcontext, sc_status);
-	offset("#define SC_OWNEDFP    ", struct sigcontext, sc_ownedfp);
 	offset("#define SC_FPC_CSR    ", struct sigcontext, sc_fpc_csr);
 	offset("#define SC_FPC_EIR    ", struct sigcontext, sc_fpc_eir);
 	offset("#define SC_CAUSE      ", struct sigcontext, sc_cause);
diff -Nru link/arch/mips64/kernel/process.c.orig link/arch/mips64/kernel/process.c
--- link/arch/mips64/kernel/process.c.orig	Tue Sep 17 19:50:17 2002
+++ link/arch/mips64/kernel/process.c	Wed Oct 30 17:22:16 2002
@@ -30,6 +30,7 @@
 #include <asm/io.h>
 #include <asm/elf.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 
 ATTRIB_NORET void cpu_idle(void)
 {
@@ -46,32 +47,30 @@
 	}
 }
 
-struct task_struct *last_task_used_math = NULL;
-
 asmlinkage void ret_from_fork(void);
 
+void start_thread(struct pt_regs * regs, unsigned long pc, unsigned long sp)
+{
+	unsigned long status;
+
+	/* New thread looses kernel privileges. */
+	status = regs->cp0_status & ~(ST0_CU0|ST0_FR|ST0_KSU);
+	status |= KSU_USER;
+	status |= (current->thread.mflags & MF_32BIT) ? 0 : ST0_FR;
+	regs->cp0_status = status;
+	current->used_math = 0;
+	loose_fpu();
+	regs->cp0_epc = pc;
+	regs->regs[29] = sp;
+	current->thread.current_ds = USER_DS;
+}
+
 void exit_thread(void)
 {
-	/* Forget lazy fpu state */
-	if (IS_FPU_OWNER()) {
-		if (mips_cpu.options & MIPS_CPU_FPU) {
-			__enable_fpu();
-			__asm__ __volatile__("cfc1\t$0,$31");
-		}
-		CLEAR_FPU_OWNER();
-	}
 }
 
 void flush_thread(void)
 {
-	/* Forget lazy fpu state */
-	if (IS_FPU_OWNER()) {
-		if (mips_cpu.options & MIPS_CPU_FPU) {
-			__enable_fpu();
-			__asm__ __volatile__("cfc1\t$0,$31");
-		}
-		CLEAR_FPU_OWNER();
-	}
 }
 
 int copy_thread(int nr, unsigned long clone_flags, unsigned long usp,
@@ -83,10 +82,10 @@
 
 	childksp = (unsigned long)p + KERNEL_STACK_SIZE - 32;
 
-	if (IS_FPU_OWNER()) {
-		if (mips_cpu.options & MIPS_CPU_FPU)
-			save_fp(p);
+	if (is_fpu_owner()) {
+		save_fp(p);
 	}
+
 	/* set up new TSS. */
 	childregs = (struct pt_regs *) childksp - 1;
 	*childregs = *regs;
diff -Nru link/arch/mips64/kernel/ptrace.c.orig link/arch/mips64/kernel/ptrace.c
--- link/arch/mips64/kernel/ptrace.c.orig	Tue Sep 17 19:15:08 2002
+++ link/arch/mips64/kernel/ptrace.c	Wed Oct 30 17:30:46 2002
@@ -23,6 +23,7 @@
 #include <linux/user.h>
 
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/mipsregs.h>
 #include <asm/pgtable.h>
 #include <asm/page.h>
@@ -112,23 +113,7 @@
 			break;
 		case FPR_BASE ... FPR_BASE + 31:
 			if (child->used_math) {
-				unsigned long *fregs
-					= (unsigned long *)
-					    &child->thread.fpu.hard.fp_regs[0];
-				if (mips_cpu.options & MIPS_CPU_FPU) {
-#ifndef CONFIG_SMP
-					if (last_task_used_math == child) {
-						__enable_fpu();
-						save_fp(child);
-						__disable_fpu();
-						last_task_used_math = NULL;
-					}
-#endif
-				} else {
-					fregs = (unsigned long *)
-						child->thread.fpu.soft.regs;
-				}
-
+				unsigned long *fregs = get_fpu_regs(child);
 				tmp = (unsigned long) fregs[addr - FPR_BASE];
 			} else {
 				tmp = -EIO;
@@ -191,23 +176,8 @@
 			regs->regs[addr] = data;
 			break;
 		case FPR_BASE ... FPR_BASE + 31: {
-			unsigned long *fregs;
-			fregs = (unsigned long *)&child->thread.fpu.hard.fp_regs[0];
-			if (child->used_math) {
-#ifndef CONFIG_SMP
-				if (last_task_used_math == child)
-					if (mips_cpu.options & MIPS_CPU_FPU) {
-						__enable_fpu();
-						save_fp(child);
-						__disable_fpu();
-						last_task_used_math = NULL;
-						regs->cp0_status &= ~ST0_CU1;
-					} else {
-						fregs = (unsigned long *)
-						child->thread.fpu.soft.regs;
-					}
-#endif
-			} else {
+			unsigned long *fregs = get_fpu_regs(child);
+			if (!child->used_math) {
 				/* FP not yet used  */
 				memset(&child->thread.fpu.hard, ~0,
 				       sizeof(child->thread.fpu.hard));
diff -Nru link/arch/mips64/kernel/signal.c.orig link/arch/mips64/kernel/signal.c
--- link/arch/mips64/kernel/signal.c.orig	Wed Sep 18 06:03:07 2002
+++ link/arch/mips64/kernel/signal.c	Fri Nov  1 10:07:39 2002
@@ -26,14 +26,13 @@
 #include <asm/uaccess.h>
 #include <asm/ucontext.h>
 #include <asm/system.h>
+#include <asm/fpu.h>
 
 #define DEBUG_SIG 0
 
 #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP)))
 
 extern asmlinkage int do_signal(sigset_t *oldset, struct pt_regs *regs);
-extern asmlinkage int (*save_fp_context)(struct sigcontext *sc);
-extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
 
 extern asmlinkage void syscall_trace(void);
 
@@ -117,57 +116,8 @@
 	return do_sigaltstack(uss, uoss, usp);
 }
 
-static inline int restore_thread_fp_context(struct sigcontext *sc)
-{
-     u64 *pfreg = &current->thread.fpu.soft.regs[0];
-     int err = 0;
-
-     /*
-      * Copy all 32 64-bit values.
-      */
-
-#define restore_fpr(i)                          \
-     do { err |= __get_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-     restore_fpr( 0); restore_fpr( 1); restore_fpr( 2); restore_fpr( 3);
-     restore_fpr( 4); restore_fpr( 5); restore_fpr( 6); restore_fpr( 7);
-     restore_fpr( 8); restore_fpr( 9); restore_fpr(10); restore_fpr(11);
-     restore_fpr(12); restore_fpr(13); restore_fpr(14); restore_fpr(15);
-     restore_fpr(16); restore_fpr(17); restore_fpr(18); restore_fpr(19);
-     restore_fpr(20); restore_fpr(21); restore_fpr(22); restore_fpr(23);
-     restore_fpr(24); restore_fpr(25); restore_fpr(26); restore_fpr(27);
-     restore_fpr(28); restore_fpr(29); restore_fpr(30); restore_fpr(31);
-
-     err |= __get_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-     return err;
-}
-
-static inline int save_thread_fp_context(struct sigcontext *sc)
-{
-     u64 *pfreg = &current->thread.fpu.soft.regs[0];
-     int err = 0;
-
-#define save_fpr(i)                                     \
-     do { err |= __put_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-     save_fpr( 0); save_fpr( 1); save_fpr( 2); save_fpr( 3);
-     save_fpr( 4); save_fpr( 5); save_fpr( 6); save_fpr( 7);
-     save_fpr( 8); save_fpr( 9); save_fpr(10); save_fpr(11);
-     save_fpr(12); save_fpr(13); save_fpr(14); save_fpr(15);
-     save_fpr(16); save_fpr(17); save_fpr(18); save_fpr(19);
-     save_fpr(20); save_fpr(21); save_fpr(22); save_fpr(23);
-     save_fpr(24); save_fpr(25); save_fpr(26); save_fpr(27);
-     save_fpr(28); save_fpr(29); save_fpr(30); save_fpr(31);
-
-     err |= __put_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-     return err;
-}
-
 asmlinkage int restore_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 
 	err |= __get_user(regs->cp0_epc, &sc->sc_pc);
@@ -190,25 +140,17 @@
 	restore_gp_reg(31);
 #undef restore_gp_reg
 
-	err |= __get_user(owned_fp, &sc->sc_ownedfp);
 	err |= __get_user(current->used_math, &sc->sc_used_math);
 
-	if (owned_fp) {
-		err |= restore_fp_context(sc);
-		goto out;
-	}
-
-	if (IS_FPU_OWNER()) {
-		/* Signal handler acquired FPU - give it back */
-		CLEAR_FPU_OWNER();
-		regs->cp0_status &= ~ST0_CU1;
-	}
 	if (current->used_math) {
-		/* Undo possible contamination of thread state */
-		err |= restore_thread_fp_context(sc);
+		/* restore fpu context if we have used it before */
+		own_fpu();
+		err |= restore_fp_context(sc);
+	} else {
+		/* signal handler may have used FPU.  Give it up. */
+		loose_fpu();
 	}
 
-out:
 	return err;
 }
 
@@ -229,7 +171,6 @@
 static int inline setup_sigcontext(struct pt_regs *regs,
 	struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 
 	err |= __put_user(regs->cp0_epc, &sc->sc_pc);
@@ -254,25 +195,20 @@
 	err |= __put_user(regs->cp0_cause, &sc->sc_cause);
 	err |= __put_user(regs->cp0_badvaddr, &sc->sc_badvaddr);
 
-	owned_fp = IS_FPU_OWNER();
-	err |= __put_user(owned_fp, &sc->sc_ownedfp);
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
 	if (!current->used_math)
 		goto out;
 
-	/* There exists FP thread state that may be trashed by signal */
-	if (owned_fp) {
-		/* fp is active.  Save context from FPU */
-		err |= save_fp_context(sc);
-		goto out;
-	}
-
-	/*
-	 * Someone else has FPU.
-	 * Copy Thread context into signal context
+	/* 
+	 * Save FPU state to signal context.  Signal handler will "inherit"
+	 * current FPU state.
 	 */
-	err |= save_thread_fp_context(sc);
+	if (!is_fpu_owner()) {
+		own_fpu();
+		restore_fp(current);
+	}
+	err |= save_fp_context(sc);
 
 out:
 	return err;
diff -Nru link/arch/mips64/kernel/traps.c.orig link/arch/mips64/kernel/traps.c
--- link/arch/mips64/kernel/traps.c.orig	Mon Oct 28 10:55:17 2002
+++ link/arch/mips64/kernel/traps.c	Thu Oct 31 15:35:28 2002
@@ -21,6 +21,7 @@
 #include <asm/bootinfo.h>
 #include <asm/branch.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/module.h>
 #include <asm/pgtable.h>
 #include <asm/io.h>
@@ -560,58 +561,33 @@
 asmlinkage void do_cpu(struct pt_regs *regs)
 {
 	unsigned int cpid;
-	void fpu_emulator_init_fpu(void);
-	int sig;
 
 	cpid = (regs->cp0_cause >> CAUSEB_CE) & 3;
 	if (cpid != 1)
 		goto bad_cid;
 
-	if (!(mips_cpu.options & MIPS_CPU_FPU))
-		goto fp_emul;
+	die_if_kernel("do_cpu invoked from kernel context!", regs);
 
-	regs->cp0_status |= ST0_CU1;
-
-#ifdef CONFIG_SMP
-	if (current->used_math) {
-		lazy_fpu_switch(0, current);
+	own_fpu();
+	if (current->used_math) {               /* Using the FPU again.  */
+		restore_fp(current);
 	} else {
 		init_fpu();
 		current->used_math = 1;
 	}
-	current->flags |= PF_USEDFPU;
-#else
-	if (last_task_used_math == current)
-		return;
-
-	if (current->used_math) {		/* Using the FPU again.  */
-		lazy_fpu_switch(last_task_used_math, current);
-	} else {				/* First time FPU user.  */
-		lazy_fpu_switch(last_task_used_math, 0);
-		init_fpu();
-		current->used_math = 1;
-	}
-	last_task_used_math = current;
-#endif
-	return;
 
-fp_emul:
-	if (last_task_used_math != current) {
-		if (!current->used_math) {
-			fpu_emulator_init_fpu();
-			current->used_math = 1;
+	if (!(mips_cpu.options & MIPS_CPU_FPU)) {
+		int sig = fpu_emulator_cop1Handler(0, regs, &current->thread.fpu.soft);
+		if (sig) {
+			/*
+			 * Return EPC is not calculated in the FPU emulator, if
+			 * a signal is being send. So we calculate it here.
+			 */
+			compute_return_epc(regs);
+			force_sig(sig, current);
 		}
 	}
-	sig = fpu_emulator_cop1Handler(0, regs, &current->thread.fpu.soft);
-	last_task_used_math = current;
-	if (sig) {
-		/*
-		 * Return EPC is not calculated in the FPU emulator, if
-		 * a signal is being send. So we calculate it here.
-		 */
-		compute_return_epc(regs);
-		force_sig(sig, current);
-	}
+
 	return;
 
 bad_cid:
@@ -685,6 +661,7 @@
 
 asmlinkage int (*save_fp_context)(struct sigcontext *sc);
 asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
+
 extern asmlinkage int _save_fp_context(struct sigcontext *sc);
 extern asmlinkage int _restore_fp_context(struct sigcontext *sc);
 
diff -Nru link/arch/mips64/kernel/r4k_switch.S.orig link/arch/mips64/kernel/r4k_switch.S
--- link/arch/mips64/kernel/r4k_switch.S.orig	Wed Jul 31 05:02:54 2002
+++ link/arch/mips64/kernel/r4k_switch.S	Fri Nov  1 09:51:08 2002
@@ -23,6 +23,19 @@
 
 	.set	mips3
 
+#define PF_USEDFPU      0x00100000      /* task used FPU this quantum (SMP) */
+#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
+
+/*
+ * [jsun] FPU context is saved if and only if the process has used FPU in 
+ * the current run (PF_USEDFPU).  In any case, the CU1 bit for user space 
+ * STATUS register should be 0, so that a process *always* starts its 
+ * userland with FPU disabled after each context switch.
+ *
+ * FPU will be enabled as soon as the process accesses FPU again, through
+ * do_cpu() trap.
+ */
+
 /*
  * task_struct *resume(task_struct *prev, task_struct *next)
  */
@@ -35,6 +48,38 @@
 	sd	ra, THREAD_REG31(a0)
 
 	/*
+	 * check if we need to save FPU registers
+	 */
+	ld	t0, TASK_FLAGS(a0)
+	li	t1, PF_USEDFPU
+	and	t2, t0, t1
+	beqz	t2, 1f
+	nor	t1, zero, t1
+
+	/*
+	 * clear PF_USEDFPU bit in task flags
+	 */
+	and	t0, t0, t1
+	sd	t0, TASK_FLAGS(a0)
+
+	/*
+	 * clear saved user stack CU1 bit
+	 */
+	ld	t0, ST_OFF(a0)
+	li	t1, ~ST0_CU1
+	and	t0, t0, t1
+	sd	t0, ST_OFF(a0)
+
+	
+	sll	t2, t0, 5
+	bgez	t2, 2f
+	sdc1	$f0, (THREAD_FPU + 0x00)(a0)
+        fpu_save_16odd a0
+2:
+        fpu_save_16even a0 t1                   # clobbers t1
+1:
+
+	/*
 	 * The order of restoring the registers takes care of the race
 	 * updating $28, $29 and kernelsp without disabling ints.
 	 */
@@ -57,51 +102,10 @@
 	END(resume)
 
 /*
- * Do lazy fpu context switch.  Saves FPU context to the process in a0
- * and loads the new context of the current process.
- */
-
-#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
-
-LEAF(lazy_fpu_switch)
-	mfc0	t0, CP0_STATUS			# enable cp1
-	li	t3, ST0_CU1
-	or	t0, t3
-	mtc0	t0, CP0_STATUS
-	FPU_ENABLE_HAZARD
-
-	beqz	a0, 2f				# Save floating point state
-	 nor	t3, zero, t3
-
-	ld	t1, ST_OFF(a0)			# last thread looses fpu
-	and	t1, t3
-	sd	t1, ST_OFF(a0)
-	sll	t2, t1, 5
-	bgez	t2, 1f
-	 sdc1	$f0, (THREAD_FPU + 0x00)(a0)
-	fpu_save_16odd a0
-1:
-	fpu_save_16even a0 t1			# clobbers t1
-2:
-
-	beqz	a1, 3f
-
-	sll	t0, t0, 5			# load new fp state
-	bgez	t0, 1f
-	 ldc1	$f0, (THREAD_FPU + 0x00)(a1)
-	fpu_restore_16odd a1
-1:
-	.set	reorder
-	fpu_restore_16even a1, t0		# clobbers t0
-3:
-	jr	ra
-	END(lazy_fpu_switch)
-
-/*
  * Save a thread's fp context.
  */
 	.set	noreorder
-LEAF(save_fp)
+LEAF(_save_fp)
 	mfc0	t0, CP0_STATUS
 	sll	t1, t0, 5
 	bgez	t1, 1f				# 16 register mode?
@@ -111,12 +115,12 @@
 	fpu_save_16even a0 t1			# clobbers t1
 	jr	ra
 	 sdc1	$f0, (THREAD_FPU + 0x00)(a0)
-	END(save_fp)
+	END(_save_fp)
 
 /*
  * Restore a thread's fp context.
  */
-LEAF(restore_fp)
+LEAF(_restore_fp)
 	mfc0	t0, CP0_STATUS
 	sll	t1, t0, 5
 	bgez	t1, 1f				# 16 register mode?
@@ -128,7 +132,7 @@
 
 	jr	ra
 	 ldc1	$f0, (THREAD_FPU + 0x00)(a0)
-	END(restore_fp)
+	END(_restore_fp)
 
 /*
  * Load the FPU with signalling NANS.  This bit pattern we're using has
@@ -140,7 +144,7 @@
 
 #define FPU_DEFAULT  0x00000000
 
-LEAF(init_fpu)
+LEAF(_init_fpu)
 	mfc0	t0, CP0_STATUS
 	li	t1, ST0_CU1
 	or	t0, t1
@@ -188,4 +192,4 @@
 	dmtc1	t0, $f28
 	jr	ra
 	 dmtc1	t0, $f30
-	END(init_fpu)
+	END(_init_fpu)
diff -Nru link/arch/mips64/kernel/cpu-probe.c.orig link/arch/mips64/kernel/cpu-probe.c
--- link/arch/mips64/kernel/cpu-probe.c.orig	Mon Sep  2 07:41:19 2002
+++ link/arch/mips64/kernel/cpu-probe.c	Wed Oct 30 18:14:48 2002
@@ -3,6 +3,7 @@
 #include <linux/stddef.h>
 #include <asm/bugs.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/mipsregs.h>
 
 /*
diff -Nru link/arch/mips64/kernel/signal32.c.orig link/arch/mips64/kernel/signal32.c
--- link/arch/mips64/kernel/signal32.c.orig	Mon Oct 28 10:55:17 2002
+++ link/arch/mips64/kernel/signal32.c	Fri Nov  1 10:51:53 2002
@@ -25,14 +25,13 @@
 #include <asm/uaccess.h>
 #include <asm/ucontext.h>
 #include <asm/system.h>
+#include <asm/fpu.h>
 
 #define DEBUG_SIG 0
 
 #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP)))
 
 extern asmlinkage int do_signal32(sigset_t *oldset, struct pt_regs *regs);
-extern asmlinkage int (*save_fp_context)(struct sigcontext *sc);
-extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
 
 extern asmlinkage void syscall_trace(void);
 
@@ -257,58 +256,9 @@
 	return ret;
 }
 
-static inline int restore_thread_fp_context(struct sigcontext *sc)
-{
-	u64 *pfreg = &current->thread.fpu.soft.regs[0];
-	int err = 0;
-
-	/*
-	 * Copy all 32 64-bit values.
-	 */
-
-#define restore_fpr(i) 						\
-	do { err |= __get_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-	restore_fpr( 0); restore_fpr( 1); restore_fpr( 2); restore_fpr( 3);
-	restore_fpr( 4); restore_fpr( 5); restore_fpr( 6); restore_fpr( 7);
-	restore_fpr( 8); restore_fpr( 9); restore_fpr(10); restore_fpr(11);
-	restore_fpr(12); restore_fpr(13); restore_fpr(14); restore_fpr(15);
-	restore_fpr(16); restore_fpr(17); restore_fpr(18); restore_fpr(19);
-	restore_fpr(20); restore_fpr(21); restore_fpr(22); restore_fpr(23);
-	restore_fpr(24); restore_fpr(25); restore_fpr(26); restore_fpr(27);
-	restore_fpr(28); restore_fpr(29); restore_fpr(30); restore_fpr(31);
-
-	err |= __get_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-	return err;
-}
-
-static inline int save_thread_fp_context(struct sigcontext *sc)
-{
-	u64 *pfreg = &current->thread.fpu.soft.regs[0];
-	int err = 0;
-
-#define save_fpr(i) 							\
-	do { err |= __put_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-	save_fpr( 0); save_fpr( 1); save_fpr( 2); save_fpr( 3);
-	save_fpr( 4); save_fpr( 5); save_fpr( 6); save_fpr( 7);
-	save_fpr( 8); save_fpr( 9); save_fpr(10); save_fpr(11);
-	save_fpr(12); save_fpr(13); save_fpr(14); save_fpr(15);
-	save_fpr(16); save_fpr(17); save_fpr(18); save_fpr(19);
-	save_fpr(20); save_fpr(21); save_fpr(22); save_fpr(23);
-	save_fpr(24); save_fpr(25); save_fpr(26); save_fpr(27);
-	save_fpr(28); save_fpr(29); save_fpr(30); save_fpr(31);
-
-	err |= __put_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-	return err;
-}
-
 static asmlinkage int restore_sigcontext(struct pt_regs *regs,
 					 struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 
 	err |= __get_user(regs->cp0_epc, &sc->sc_pc);
@@ -331,25 +281,17 @@
 	restore_gp_reg(31);
 #undef restore_gp_reg
 
-	err |= __get_user(owned_fp, &sc->sc_ownedfp);
 	err |= __get_user(current->used_math, &sc->sc_used_math);
 
-	if (owned_fp) {
-		err |= restore_fp_context(sc);
-		goto out;
-	}
-
-	if (IS_FPU_OWNER()) {
-		/* Signal handler acquired FPU - give it back */
-		CLEAR_FPU_OWNER();
-		regs->cp0_status &= ~ST0_CU1;
-	}
 	if (current->used_math) {
-		/* Undo possible contamination of thread state */
-		err |= restore_thread_fp_context(sc);
+		/* restore fpu context if we have used it before */
+		own_fpu();
+		err |= restore_fp_context(sc);
+	} else {
+		/* signal handler may have used FPU.  Give it up. */
+		loose_fpu();
 	}
 
-out:
 	return err;
 }
 
@@ -489,7 +431,6 @@
 static int inline setup_sigcontext(struct pt_regs *regs,
 				   struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 
 	err |= __put_user(regs->cp0_epc, &sc->sc_pc);
@@ -514,25 +455,20 @@
 	err |= __put_user(regs->cp0_cause, &sc->sc_cause);
 	err |= __put_user(regs->cp0_badvaddr, &sc->sc_badvaddr);
 
-	owned_fp = IS_FPU_OWNER();
-	err |= __put_user(owned_fp, &sc->sc_ownedfp);
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
 	if (!current->used_math)
 		goto out;
 
-	/* There exists FP thread state that may be trashed by signal */
-	if (owned_fp) {
-		/* fp is active.  Save context from FPU */
-		err |= save_fp_context(sc);
-		goto out;
-	}
-
-	/*
-	 * Someone else has FPU.
-	 * Copy Thread context into signal context
+	/* 
+	 * Save FPU state to signal context.  Signal handler will "inherit"
+	 * current FPU state.
 	 */
-	err |= save_thread_fp_context(sc);
+	if (!is_fpu_owner()) {
+		own_fpu();
+		restore_fp(current);
+	}
+	err |= save_fp_context(sc);
 
 out:
 	return err;
diff -Nru link/include/asm-mips/processor.h.orig link/include/asm-mips/processor.h
--- link/include/asm-mips/processor.h.orig	Mon Oct 28 13:45:08 2002
+++ link/include/asm-mips/processor.h	Mon Oct 28 11:55:24 2002
@@ -72,9 +72,6 @@
 #define wp_works_ok 1
 #define wp_works_ok__is_a_macro /* for versions in ksyms.c */
 
-/* Lazy FPU handling on uni-processor */
-extern struct task_struct *last_task_used_math;
-
 /*
  * User space process size: 2GB. This is hardcoded into a few places,
  * so don't change it unless you know what you are doing.  TASK_SIZE
@@ -211,20 +208,16 @@
 /*
  * Do necessary setup to start up a newly executed thread.
  */
-#define start_thread(regs, new_pc, new_sp) do {				\
-	/* New thread loses kernel and FPU privileges. */	       	\
-	regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU|ST0_CU1)) | KU_USER;\
-	regs->cp0_epc = new_pc;						\
-	regs->regs[29] = new_sp;					\
-	current->thread.current_ds = USER_DS;				\
-} while (0)
+extern void start_thread(struct pt_regs * regs, unsigned long pc, unsigned long sp);
 
+struct task_struct;
 unsigned long get_wchan(struct task_struct *p);
 
 #define __PT_REG(reg) ((long)&((struct pt_regs *)0)->reg - sizeof(struct pt_regs))
 #define __KSTK_TOS(tsk) ((unsigned long)(tsk) + KERNEL_STACK_SIZE - 32)
 #define KSTK_EIP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_epc)))
 #define KSTK_ESP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(regs[29])))
+#define KSTK_STATUS(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_status)))
 
 /* Allocation and freeing of basic task resources. */
 /*
diff -Nru link/include/asm-mips/mipsregs.h.orig link/include/asm-mips/mipsregs.h
--- link/include/asm-mips/mipsregs.h.orig	Mon Oct 28 13:45:08 2002
+++ link/include/asm-mips/mipsregs.h	Mon Oct 28 11:55:24 2002
@@ -1002,48 +1002,6 @@
 __BUILD_SET_CP0(cause,CP0_CAUSE)
 __BUILD_SET_CP0(config,CP0_CONFIG)
 
-#if defined(CONFIG_CPU_SB1)
-#define __enable_fpu_hazard()						\
-do {									\
-	asm(".set push		\n\t"					\
-	    ".set mips64	\n\t"					\
-	    ".set noreorder	\n\t"					\
-	    "ssnop		\n\t"					\
-	    "bnezl $0, .+4	\n\t"					\
-	    "ssnop		\n\t"					\
-	    ".set pop");						\
-} while (0)
-#else
-#define __enable_fpu_hazard()						\
-do {									\
-	asm("nop;nop;nop;nop");		/* max. hazard */		\
-} while (0)
-#endif
-
-#define __enable_fpu()							\
-do {									\
-	set_cp0_status(ST0_CU1);					\
-	__enable_fpu_hazard();						\
-} while (0)
-
-#define __disable_fpu()							\
-do {									\
-	clear_cp0_status(ST0_CU1);					\
-	/* We don't care about the cp0 hazard here  */			\
-} while (0)
-
-#define enable_fpu()							\
-do {									\
-	if (mips_cpu.options & MIPS_CPU_FPU)				\
-		__enable_fpu();						\
-} while (0)
-
-#define disable_fpu()							\
-do {									\
-	if (mips_cpu.options & MIPS_CPU_FPU)				\
-		__disable_fpu();					\
-} while (0)
-
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_MIPSREGS_H */
diff -Nru link/include/asm-mips/sigcontext.h.orig link/include/asm-mips/sigcontext.h
--- link/include/asm-mips/sigcontext.h.orig	Wed Dec 26 15:35:56 2001
+++ link/include/asm-mips/sigcontext.h	Mon Oct 28 10:56:40 2002
@@ -18,7 +18,6 @@
 	unsigned long long sc_pc;
 	unsigned long long sc_regs[32];
 	unsigned long long sc_fpregs[32];
-	unsigned int       sc_ownedfp;
 	unsigned int       sc_fpc_csr;
 	unsigned int       sc_fpc_eir;		/* Unused */
 	unsigned int       sc_used_math;
diff -Nru link/include/asm-mips/system.h.orig link/include/asm-mips/system.h
--- link/include/asm-mips/system.h.orig	Mon Oct 28 13:45:08 2002
+++ link/include/asm-mips/system.h	Mon Oct 28 11:55:19 2002
@@ -250,11 +250,6 @@
 
 struct task_struct;
 
-extern asmlinkage void lazy_fpu_switch(void *);
-extern asmlinkage void init_fpu(void);
-extern asmlinkage void save_fp(struct task_struct *);
-extern asmlinkage void restore_fp(struct task_struct *);
-
 #define switch_to(prev,next,last) \
 do { \
 	(last) = resume(prev, next); \
diff -Nru link/include/asm-mips64/processor.h.orig link/include/asm-mips64/processor.h
--- link/include/asm-mips64/processor.h.orig	Thu Oct 31 11:42:23 2002
+++ link/include/asm-mips64/processor.h	Thu Oct 31 14:26:15 2002
@@ -103,17 +103,6 @@
 #define wp_works_ok 1
 #define wp_works_ok__is_a_macro /* for versions in ksyms.c */
 
-/* Lazy FPU handling on uni-processor */
-extern struct task_struct *last_task_used_math;
-
-#ifndef CONFIG_SMP
-#define IS_FPU_OWNER()		(last_task_used_math == current)
-#define CLEAR_FPU_OWNER()	last_task_used_math = NULL;
-#else
-#define IS_FPU_OWNER()		(current->flags & PF_USEDFPU)
-#define CLEAR_FPU_OWNER()	current->flags &= ~PF_USEDFPU;
-#endif
-
 /*
  * User space process size: 1TB. This is hardcoded into a few places,
  * so don't change it unless you know what you are doing.  TASK_SIZE
@@ -256,26 +245,16 @@
 /*
  * Do necessary setup to start up a newly executed thread.
  */
-#define start_thread(regs, pc, sp) 					\
-do {									\
-	unsigned long __status;						\
-									\
-	/* New thread looses kernel privileges. */			\
-	__status = regs->cp0_status & ~(ST0_CU0|ST0_FR|ST0_KSU);	\
-	__status |= KSU_USER;						\
-	__status |= (current->thread.mflags & MF_32BIT) ? 0 : ST0_FR;	\
-	regs->cp0_status = __status;					\
-	regs->cp0_epc = pc;						\
-	regs->regs[29] = sp;						\
-	current->thread.current_ds = USER_DS;				\
-} while(0)
+extern void start_thread(struct pt_regs * regs, unsigned long pc, unsigned long sp);
 
+struct task_struct;
 unsigned long get_wchan(struct task_struct *p);
 
 #define __PT_REG(reg) ((long)&((struct pt_regs *)0)->reg - sizeof(struct pt_regs))
 #define __KSTK_TOS(tsk) ((unsigned long)(tsk) + KERNEL_STACK_SIZE - 32)
 #define KSTK_EIP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_epc)))
 #define KSTK_ESP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(regs[29])))
+#define KSTK_STATUS(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_status)))
 
 /* Allocation and freeing of basic task resources. */
 /*
diff -Nru link/include/asm-mips64/mipsregs.h.orig link/include/asm-mips64/mipsregs.h
--- link/include/asm-mips64/mipsregs.h.orig	Thu Oct 31 11:42:23 2002
+++ link/include/asm-mips64/mipsregs.h	Thu Oct 31 10:28:30 2002
@@ -896,47 +896,6 @@
 __BUILD_SET_CP0(cause,CP0_CAUSE)
 __BUILD_SET_CP0(config,CP0_CONFIG)
 
-#if defined(CONFIG_CPU_SB1)
-#define __enable_fpu_hazard()						\
-do {									\
-	asm(".set push		\n\t"					\
-	    ".set mips2		\n\t"					\
-	    ".set noreorder	\n\t"					\
-	    "sll $0,$0,1	\n\t"					\
-	    "bnezl $0, .+4	\n\t"					\
-	    " sll $0,$0,1	\n\t"					\
-	    ".set pop");						\
-} while (0)
-#else
-#define __enable_fpu_hazard()						\
-do {									\
-	asm("nop;nop;nop;nop");		/* max. hazard */		\
-} while (0)
-#endif
-
-#define __enable_fpu()							\
-do {									\
-	set_cp0_status(ST0_CU1);					\
-	__enable_fpu_hazard();						\
-} while (0)
-
-#define __disable_fpu()							\
-do {									\
-	clear_cp0_status(ST0_CU1);					\
-	/* We don't care about the cp0 hazard here  */			\
-} while (0)
-
-#define enable_fpu()							\
-do {									\
-	if (mips_cpu.options & MIPS_CPU_FPU)				\
-		__enable_fpu();						\
-} while (0)
-
-#define disable_fpu()							\
-do {									\
-	if (mips_cpu.options & MIPS_CPU_FPU)				\
-		__disable_fpu();					\
-} while (0)
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_MIPSREGS_H */
diff -Nru link/include/asm-mips64/sigcontext.h.orig link/include/asm-mips64/sigcontext.h
--- link/include/asm-mips64/sigcontext.h.orig	Tue Jul 30 19:41:21 2002
+++ link/include/asm-mips64/sigcontext.h	Wed Oct 30 18:25:25 2002
@@ -20,7 +20,6 @@
 	unsigned long long sc_mdlo;
 	unsigned long long sc_pc;
 	unsigned int       sc_status;
-	unsigned int       sc_ownedfp;
 	unsigned int       sc_fpc_csr;
 	unsigned int       sc_fpc_eir;
 	unsigned int       sc_used_math;
diff -Nru link/include/asm-mips64/system.h.orig link/include/asm-mips64/system.h
--- link/include/asm-mips64/system.h.orig	Thu Oct 31 11:42:23 2002
+++ link/include/asm-mips64/system.h	Thu Oct 31 14:26:15 2002
@@ -222,25 +222,8 @@
 
 struct task_struct;
 
-extern asmlinkage void lazy_fpu_switch(void *, void *);
-extern asmlinkage void init_fpu(void);
-extern asmlinkage void save_fp(struct task_struct *);
-extern asmlinkage void restore_fp(struct task_struct *);
-
-#ifdef CONFIG_SMP
-#define SWITCH_DO_LAZY_FPU \
-	if (prev->flags & PF_USEDFPU) { \
-		lazy_fpu_switch(prev, 0); \
-		clear_cp0_status(ST0_CU1); \
-		prev->flags &= ~PF_USEDFPU; \
-	}
-#else /* CONFIG_SMP */
-#define SWITCH_DO_LAZY_FPU	do { } while(0)
-#endif /* CONFIG_SMP */
-
 #define switch_to(prev,next,last) \
 do { \
-	SWITCH_DO_LAZY_FPU; \
 	(last) = resume(prev, next); \
 } while(0)
 

--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="021101.25-new-fpu-complete.patch"

diff -Nru link/arch/mips/kernel/process.c.orig link/arch/mips/kernel/process.c
--- link/arch/mips/kernel/process.c.orig	Fri Nov  1 10:10:59 2002
+++ link/arch/mips/kernel/process.c	Fri Nov  1 10:20:50 2002
@@ -21,6 +21,7 @@
 
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/mipsregs.h>
@@ -56,28 +57,25 @@
 	}
 }
 
-struct task_struct *last_task_used_math = NULL;
-
 asmlinkage void ret_from_fork(void);
 
+void start_thread(struct pt_regs * regs, unsigned long pc, unsigned long sp)
+{
+	regs->cp0_status &= ~(ST0_CU0|ST0_KSU|ST0_CU1);
+       	regs->cp0_status |= KU_USER;
+	current->used_math = 0;
+	loose_fpu();
+	regs->cp0_epc = pc;
+	regs->regs[29] = sp;
+	current->thread.current_ds = USER_DS;
+}
+
 void exit_thread(void)
 {
-	/* Forget lazy fpu state */
-	if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) {
-		__enable_fpu();
-		__asm__ __volatile__("cfc1\t$0,$31");
-		last_task_used_math = NULL;
-	}
 }
 
 void flush_thread(void)
 {
-	/* Forget lazy fpu state */
-	if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) {
-		__enable_fpu();
-		__asm__ __volatile__("cfc1\t$0,$31");
-		last_task_used_math = NULL;
-	}
 }
 
 int copy_thread(int nr, unsigned long clone_flags, unsigned long usp,
@@ -90,11 +88,9 @@
 
 	childksp = (unsigned long)ti + KERNEL_STACK_SIZE - 32;
 
-	if (last_task_used_math == current)
-		if (mips_cpu.options & MIPS_CPU_FPU) {
-			__enable_fpu();
-			save_fp(p);
-		}
+	if (is_fpu_owner()) {
+		save_fp(p);
+	}
 
 	/* set up new TSS. */
 	childregs = (struct pt_regs *) childksp - 1;
diff -Nru link/arch/mips/kernel/ptrace.c.orig link/arch/mips/kernel/ptrace.c
--- link/arch/mips/kernel/ptrace.c.orig	Fri Nov  1 10:10:59 2002
+++ link/arch/mips/kernel/ptrace.c	Fri Nov  1 10:17:50 2002
@@ -28,6 +28,7 @@
 #include <asm/uaccess.h>
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 
 /*
  * Called by kernel/ptrace.c when detaching..
@@ -43,7 +44,6 @@
 {
 	struct task_struct *child;
 	int ret;
-	extern void save_fp(struct task_struct *);
 
 	lock_kernel();
 #if 0
@@ -114,20 +114,7 @@
 			break;
 		case FPR_BASE ... FPR_BASE + 31:
 			if (child->used_math) {
-			        unsigned long long *fregs
-					= (unsigned long long *)
-					    &child->thread.fpu.hard.fp_regs[0];
-			 	if(!(mips_cpu.options & MIPS_CPU_FPU)) {
-					fregs = (unsigned long long *)
-						child->thread.fpu.soft.regs;
-				} else
-					if (last_task_used_math == child) {
-						__enable_fpu();
-						save_fp(child);
-						__disable_fpu();
-						last_task_used_math = NULL;
-						regs->cp0_status &= ~ST0_CU1;
-					}
+			        unsigned long long *fregs = get_fpu_regs(child);
 				/*
 				 * The odd registers are actually the high
 				 * order bits of the values stored in the even
@@ -205,21 +192,8 @@
 			break;
 		case FPR_BASE ... FPR_BASE + 31: {
 			unsigned long long *fregs;
-			fregs = (unsigned long long *)&child->thread.fpu.hard.fp_regs[0];
-			if (child->used_math) {
-				if (last_task_used_math == child) {
-					if(!(mips_cpu.options & MIPS_CPU_FPU)) {
-						fregs = (unsigned long long *)
-						child->thread.fpu.soft.regs;
-					} else {
-						__enable_fpu();
-						save_fp(child);
-						__disable_fpu();
-						last_task_used_math = NULL;
-						regs->cp0_status &= ~ST0_CU1;
-					}
-				}
-			} else {
+			fregs = (unsigned long long *)get_fpu_regs(child);
+			if (!child->used_math) {
 				/* FP not yet used  */
 				memset(&child->thread.fpu.hard, ~0,
 				       sizeof(child->thread.fpu.hard));
diff -Nru link/arch/mips/kernel/signal.c.orig link/arch/mips/kernel/signal.c
--- link/arch/mips/kernel/signal.c.orig	Fri Nov  1 10:10:59 2002
+++ link/arch/mips/kernel/signal.c	Fri Nov  1 10:22:09 2002
@@ -23,6 +23,7 @@
 #include <asm/bitops.h>
 #include <asm/cacheflush.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/offset.h>
 #include <asm/ptrace.h>
 #include <asm/uaccess.h>
@@ -34,9 +35,6 @@
 
 extern asmlinkage int do_signal(sigset_t *oldset, struct pt_regs *regs);
 
-extern asmlinkage int (*save_fp_context)(struct sigcontext *sc);
-extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
-
 extern asmlinkage void do_syscall_trace(void);
 
 /*
@@ -150,59 +148,8 @@
 	return do_sigaltstack(uss, uoss, usp);
 }
 
-static inline int restore_thread_fp_context(struct sigcontext *sc)
-{
-	u64 *pfreg = &current->thread.fpu.soft.regs[0];
-	int err = 0;
-
-	/*
-	 * Copy all 32 64-bit values, for two reasons.  First, the R3000 and
-	 * R4000/MIPS32 kernels use the thread FP register storage differently,
-	 * such that a full copy is essentially necessary to support both.
-	 */
-
-#define restore_fpr(i) 						\
-	do { err |= __get_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-	restore_fpr( 0); restore_fpr( 1); restore_fpr( 2); restore_fpr( 3);
-	restore_fpr( 4); restore_fpr( 5); restore_fpr( 6); restore_fpr( 7);
-	restore_fpr( 8); restore_fpr( 9); restore_fpr(10); restore_fpr(11);
-	restore_fpr(12); restore_fpr(13); restore_fpr(14); restore_fpr(15);
-	restore_fpr(16); restore_fpr(17); restore_fpr(18); restore_fpr(19);
-	restore_fpr(20); restore_fpr(21); restore_fpr(22); restore_fpr(23);
-	restore_fpr(24); restore_fpr(25); restore_fpr(26); restore_fpr(27);
-	restore_fpr(28); restore_fpr(29); restore_fpr(30); restore_fpr(31);
-
-	err |= __get_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-	return err;
-}
-
-static inline int save_thread_fp_context(struct sigcontext *sc)
-{
-	u64 *pfreg = &current->thread.fpu.soft.regs[0];
-	int err = 0;
-
-#define save_fpr(i) 							\
-	do { err |= __put_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-	save_fpr( 0); save_fpr( 1); save_fpr( 2); save_fpr( 3);
-	save_fpr( 4); save_fpr( 5); save_fpr( 6); save_fpr( 7);
-	save_fpr( 8); save_fpr( 9); save_fpr(10); save_fpr(11);
-	save_fpr(12); save_fpr(13); save_fpr(14); save_fpr(15);
-	save_fpr(16); save_fpr(17); save_fpr(18); save_fpr(19);
-	save_fpr(20); save_fpr(21); save_fpr(22); save_fpr(23);
-	save_fpr(24); save_fpr(25); save_fpr(26); save_fpr(27);
-	save_fpr(28); save_fpr(29); save_fpr(30); save_fpr(31);
-
-	err |= __put_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-	return err;
-}
-
 static int restore_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 	u64 reg;
 
@@ -230,25 +177,17 @@
 	restore_gp_reg(31);
 #undef restore_gp_reg
 
-	err |= __get_user(owned_fp, &sc->sc_ownedfp);
 	err |= __get_user(current->used_math, &sc->sc_used_math);
 
-	if (owned_fp) {
-		err |= restore_fp_context(sc);
-		goto out;
-	}
-
-	if (current == last_task_used_math) {
-		/* Signal handler acquired FPU - give it back */
-		last_task_used_math = NULL;
-		regs->cp0_status &= ~ST0_CU1;
-	}
 	if (current->used_math) {
-		/* Undo possible contamination of thread state */
-		err |= restore_thread_fp_context(sc);
+		/* restore fpu context if we have used it before */
+		own_fpu();
+		err |= restore_fp_context(sc);
+	} else {
+		/* signal handler may have used FPU.  Give it up. */
+		loose_fpu();
 	}
 
-out:
 	return err;
 }
 
@@ -345,7 +284,6 @@
 
 static int inline setup_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 	u64 reg;
 
@@ -373,25 +311,20 @@
 	err |= __put_user(regs->cp0_cause, &sc->sc_cause);
 	err |= __put_user(regs->cp0_badvaddr, &sc->sc_badvaddr);
 
-	owned_fp = (current == last_task_used_math);
-	err |= __put_user(owned_fp, &sc->sc_ownedfp);
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
 	if (!current->used_math)
 		goto out;
 
-	/* There exists FP thread state that may be trashed by signal */
-	if (owned_fp) {
-		/* fp is active.  Save context from FPU */
-		err |= save_fp_context(sc);
-		goto out;
-	}
-
-	/*
-	 * Someone else has FPU.
-	 * Copy Thread context into signal context
+	/* 
+	 * Save FPU state to signal context.  Signal handler will "inherit"
+	 * current FPU state.
 	 */
-	err |= save_thread_fp_context(sc);
+	if (!is_fpu_owner()) {
+		own_fpu();
+		restore_fp(current);
+	}
+	err |= save_fp_context(sc);
 
 out:
 	return err;
diff -Nru link/arch/mips/kernel/traps.c.orig link/arch/mips/kernel/traps.c
--- link/arch/mips/kernel/traps.c.orig	Fri Nov  1 10:10:59 2002
+++ link/arch/mips/kernel/traps.c	Fri Nov  1 10:24:55 2002
@@ -24,6 +24,7 @@
 #include <asm/bootinfo.h>
 #include <asm/branch.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/inst.h>
 #include <asm/module.h>
 #include <asm/pgtable.h>
@@ -672,49 +673,32 @@
 asmlinkage void do_cpu(struct pt_regs *regs)
 {
 	unsigned int cpid;
-	void fpu_emulator_init_fpu(void);
-	int sig;
 
 	cpid = (regs->cp0_cause >> CAUSEB_CE) & 3;
 	if (cpid != 1)
 		goto bad_cid;
 
-	if (!(mips_cpu.options & MIPS_CPU_FPU))
-		goto fp_emul;
-
-	regs->cp0_status |= ST0_CU1;
-	if (last_task_used_math == current)
-		return;
+	die_if_kernel("do_cpu invoked from kernel context!", regs);
 
+	own_fpu();
 	if (current->used_math) {		/* Using the FPU again.  */
-		lazy_fpu_switch(last_task_used_math, current);
+		restore_fp(current);
 	} else {				/* First time FPU user.  */
-		if (last_task_used_math != NULL)
-			save_fp(last_task_used_math);
 		init_fpu();
 		current->used_math = 1;
 	}
-	last_task_used_math = current;
-
-	return;
-
-fp_emul:
-	if (last_task_used_math != current) {
-		if (!current->used_math) {
-			fpu_emulator_init_fpu();
-			current->used_math = 1;
+	if (!(mips_cpu.options & MIPS_CPU_FPU)) {
+		int sig = fpu_emulator_cop1Handler(0, regs, &current->thread.fpu.soft);
+		if (sig) {
+			/*
+			 * Return EPC is not calculated in the FPU emulator, if
+			 * a signal is being send. So we calculate it here.
+			 */
+			compute_return_epc(regs);
+			force_sig(sig, current);
 		}
 	}
-	sig = fpu_emulator_cop1Handler(0, regs, &current->thread.fpu.soft);
-	last_task_used_math = current;
-	if (sig) {
-		/*
-		 * Return EPC is not calculated in the FPU emulator, if
-		 * a signal is being send. So we calculate it here.
-		 */
-		compute_return_epc(regs);
-		force_sig(sig, current);
-	}
+
 	return;
 
 bad_cid:
@@ -896,6 +880,7 @@
 
 asmlinkage int (*save_fp_context)(struct sigcontext *sc);
 asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
+
 extern asmlinkage int _save_fp_context(struct sigcontext *sc);
 extern asmlinkage int _restore_fp_context(struct sigcontext *sc);
 
diff -Nru link/arch/mips/kernel/r2300_switch.S.orig link/arch/mips/kernel/r2300_switch.S
--- link/arch/mips/kernel/r2300_switch.S.orig	Fri Nov  1 10:10:59 2002
+++ link/arch/mips/kernel/r2300_switch.S	Fri Nov  1 11:02:13 2002
@@ -26,6 +26,19 @@
 	.set	mips1
 	.align	5
 
+#define PF_USEDFPU      0x00100000      /* task used FPU this quantum (SMP) */
+#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
+
+/*
+ * [jsun] FPU context is saved if and only if the process has used FPU in 
+ * the current run (PF_USEDFPU).  In any case, the CU1 bit for user space 
+ * STATUS register should be 0, so that a process *always* starts its 
+ * userland with FPU disabled after each context switch.
+ *
+ * FPU will be enabled as soon as the process accesses FPU again, through
+ * do_cpu() trap.
+ */
+
 /*
  * task_struct *resume(task_struct *prev, task_struct *next,
  *                     struct thread_info *next_ti) )
@@ -39,6 +52,32 @@
 	CPU_SAVE_NONSCRATCH(a0)
 	sw	ra, THREAD_REG31(a0)
 
+	/* 
+	 * check if we need to save FPU registers
+	 */
+	lw	t0, TASK_FLAGS(a0)
+	li	t1, PF_USEDFPU
+	and	t2, t0, t1
+	beqz	t2, 1f
+	nor	t1, zero, t1
+
+	/*
+	 * clear PF_USEDFPU bit in task flags
+	 */
+	and	t0, t0, t1
+	sw	t0, TASK_FLAGS(a0)
+
+	/*
+	 * clear user-saved stack CU1 bit
+	 */
+	lw	t0, ST_OFF(a0)
+	li	t1, ~ST0_CU1
+	and	t0, t0, t1
+	sw	t0, ST_OFF(a0)
+
+	FPU_SAVE_SINGLE(a0, t0)			# clobbers t0
+
+1:
 	/*
 	 * The order of restoring the registers takes care of the race
 	 * updating $28, $29 and kernelsp without disabling ints.
@@ -62,45 +101,20 @@
 	END(resume)
 
 /*
- * Do lazy fpu context switch.  Saves FPU context to the process in a0
- * and loads the new context of the current process.
- */
-
-#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
-
-LEAF(lazy_fpu_switch)
-	mfc0	t0, CP0_STATUS			# enable cp1
-	li	t3, ST0_CU1
-	or	t0, t3
-	mtc0	t0, CP0_STATUS
-
-	nor	t3, zero, t3
-	beqz	a0, 2f				# Save floating point state
-	lw	t1, ST_OFF(a0)			# last thread looses fpu
-	and	t1, t3
-	sw	t1, ST_OFF(a0)
-	FPU_SAVE_SINGLE(a0, t1)			# clobbers t1
-
-2:
-	FPU_RESTORE_SINGLE(a1, t0)		# clobbers t0
-	jr	ra
-	END(lazy_fpu_switch)
-
-/*
  * Save a thread's fp context.
  */
-LEAF(save_fp)
+LEAF(_save_fp)
 	FPU_SAVE_SINGLE(a0, t1)			# clobbers t1
 	jr	ra
-	END(save_fp)
+	END(_save_fp)
 
 /*
  * Restore a thread's fp context.
  */
-LEAF(restore_fp)
+LEAF(_restore_fp)
 	FPU_RESTORE_SINGLE(a0, t1)		# clobbers t1
 	jr	ra
-	END(restore_fp)
+	END(_estore_fp)
 
 /*
  * Load the FPU with signalling NANS.  This bit pattern we're using has
@@ -112,7 +126,7 @@
 
 #define FPU_DEFAULT  0x00000000
 
-LEAF(init_fpu)
+LEAF(_init_fpu)
 	mfc0	t0, CP0_STATUS
 	li	t1, ST0_CU1
 	or	t0, t1
@@ -156,4 +170,4 @@
 	mtc1	t0, $f30
 	mtc1	t0, $f31
 	jr	ra
-	END(init_fpu)
+	END(_init_fpu)
diff -Nru link/arch/mips/kernel/r4k_switch.S.orig link/arch/mips/kernel/r4k_switch.S
--- link/arch/mips/kernel/r4k_switch.S.orig	Fri Nov  1 10:10:59 2002
+++ link/arch/mips/kernel/r4k_switch.S	Fri Nov  1 10:27:42 2002
@@ -24,6 +24,19 @@
 
 #include <asm/asmmacro.h>
 
+#define PF_USEDFPU      0x00100000      /* task used FPU this quantum (SMP) */
+#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
+
+/*
+ * [jsun] FPU context is saved if and only if the process has used FPU in 
+ * the current run (PF_USEDFPU).  In any case, the CU1 bit for user space 
+ * STATUS register should be 0, so that a process *always* starts its 
+ * userland with FPU disabled after each context switch.
+ *
+ * FPU will be enabled as soon as the process accesses FPU again, through 
+ * do_cpu() trap.
+ */
+
 /*
  * task_struct *r4xx0_resume(task_struct *prev, task_struct *next,
  *                           struct thread_info *next_ti)
@@ -38,6 +51,32 @@
 	CPU_SAVE_NONSCRATCH(a0)
 	sw	ra, THREAD_REG31(a0)
 
+	/* 
+	 * check if we need to save FPU registers
+	 */
+	lw	t0, TASK_FLAGS(a0)
+	li	t1, PF_USEDFPU
+	and	t2, t0, t1
+	beqz	t2, 1f
+	nor	t1, zero, t1
+
+	/*
+	 * clear PF_USEDFPU bit in task flags
+	 */
+	and	t0, t0, t1
+	sw	t0, TASK_FLAGS(a0)
+
+	/*
+	 * clear saved user stack CU1 bit
+	 */
+	lw	t0, ST_OFF(a0)
+	li	t1, ~ST0_CU1
+	and	t0, t0, t1
+	sw	t0, ST_OFF(a0)
+
+	FPU_SAVE_DOUBLE(a0, t0)			# clobbers t0
+
+1:
 	/*
 	 * The order of restoring the registers takes care of the race
 	 * updating $28, $29 and kernelsp without disabling ints.
@@ -70,39 +109,12 @@
 	END(resume)
 
 /*
- * Do lazy fpu context switch.  Saves FPU context to the process in a0
- * and loads the new context of the current process.
- */
-
-#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
-
-LEAF(lazy_fpu_switch)
-	mfc0	t0, CP0_STATUS			# enable cp1
-	li	t3, ST0_CU1
-	or	t0, t3
-	mtc0	t0, CP0_STATUS
-	FPU_ENABLE_HAZARD
-
-	nor	t3, zero, t3
-	beqz	a0, 2f				# Save floating point state
-
-	lw	t1, ST_OFF(a0)			# last thread looses fpu
-	and	t1, t3
-	sw	t1, ST_OFF(a0)
-
-
-	FPU_SAVE_DOUBLE(a0, t1)			# clobbers t1
-2:	FPU_RESTORE_DOUBLE(a1, t0)		# clobbers t0
-	jr	ra
-	END(lazy_fpu_switch)
-
-/*
  * Save a thread's fp context.
  */
-LEAF(save_fp)
+LEAF(_save_fp)
 	FPU_SAVE_DOUBLE(a0, t1)			# clobbers t1
 	jr	ra
-	END(save_fp)
+	END(_save_fp)
 
 /*
  * Restore a thread's fp context.
@@ -110,7 +122,7 @@
 LEAF(restore_fp)
 	FPU_RESTORE_DOUBLE(a0, t1)		# clobbers t1
 	jr	ra
-	END(restore_fp)
+	END(_restore_fp)
 
 /*
  * Load the FPU with signalling NANS.  This bit pattern we're using has
@@ -122,7 +134,7 @@
 
 #define FPU_DEFAULT  0x00000000
 
-LEAF(init_fpu)
+LEAF(_init_fpu)
 	.set	mips3
 	mfc0	t0, CP0_STATUS
 	li	t1, ST0_CU1
@@ -152,4 +164,4 @@
 	dmtc1	t0, $f28
 	dmtc1	t0, $f30
 	jr	ra
-	END(init_fpu)
+	END(_init_fpu)
diff -Nru link/arch/mips/kernel/cpu-probe.c.orig link/arch/mips/kernel/cpu-probe.c
--- link/arch/mips/kernel/cpu-probe.c.orig	Tue Sep  3 14:04:28 2002
+++ link/arch/mips/kernel/cpu-probe.c	Fri Nov  1 10:17:50 2002
@@ -3,6 +3,7 @@
 #include <linux/stddef.h>
 #include <asm/bugs.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/mipsregs.h>
 
 /*
diff -Nru link/arch/mips/tools/offset.c.orig link/arch/mips/tools/offset.c
--- link/arch/mips/tools/offset.c.orig	Fri Nov  1 10:11:03 2002
+++ link/arch/mips/tools/offset.c	Fri Nov  1 10:17:50 2002
@@ -155,7 +155,6 @@
 	offset("#define SC_MDLO       ", struct sigcontext, sc_mdlo);
 	offset("#define SC_PC         ", struct sigcontext, sc_pc);
 	offset("#define SC_STATUS     ", struct sigcontext, sc_status);
-	offset("#define SC_OWNEDFP    ", struct sigcontext, sc_ownedfp);
 	offset("#define SC_FPC_CSR    ", struct sigcontext, sc_fpc_csr);
 	offset("#define SC_FPC_EIR    ", struct sigcontext, sc_fpc_eir);
 	offset("#define SC_CAUSE      ", struct sigcontext, sc_cause);
diff -Nru link/arch/mips64/kernel/process.c.orig link/arch/mips64/kernel/process.c
--- link/arch/mips64/kernel/process.c.orig	Fri Nov  1 10:11:18 2002
+++ link/arch/mips64/kernel/process.c	Fri Nov  1 10:35:45 2002
@@ -30,6 +30,7 @@
 #include <asm/io.h>
 #include <asm/elf.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 
 /*
  * We use this if we don't have any better idle routine..
@@ -55,28 +56,30 @@
 	}
 }
 
-struct task_struct *last_task_used_math = NULL;
-
 asmlinkage void ret_from_fork(void);
 
+void start_thread(struct pt_regs * regs, unsigned long pc, unsigned long sp)
+{
+	unsigned long status;
+
+	/* New thread looses kernel privileges. */
+	status = regs->cp0_status & ~(ST0_CU0|ST0_FR|ST0_KSU);
+	status |= KSU_USER;
+	status |= (current->thread.mflags & MF_32BIT) ? 0 : ST0_FR;
+	regs->cp0_status = status;
+	current->used_math = 0;
+	loose_fpu();
+	regs->cp0_epc = pc;
+	regs->regs[29] = sp;
+	current_thread_info()->addr_limit = USER_DS;
+}
+
 void exit_thread(void)
 {
-	/* Forget lazy fpu state */
-	if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) {
-		__enable_fpu();
-		__asm__ __volatile__("cfc1\t$0,$31");
-		last_task_used_math = NULL;
-	}
 }
 
 void flush_thread(void)
 {
-	/* Forget lazy fpu state */
-	if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) {
-		__enable_fpu();
-		__asm__ __volatile__("cfc1\t$0,$31");
-		last_task_used_math = NULL;
-	}
 }
 
 int copy_thread(int nr, unsigned long clone_flags, unsigned long usp,
@@ -89,10 +92,8 @@
 
 	childksp = (unsigned long)ti + KERNEL_STACK_SIZE - 32;
 
-	if (last_task_used_math == current)
-		if (mips_cpu.options & MIPS_CPU_FPU) {
-			__enable_fpu();
-			save_fp(p);
+	if (is_fpu_owner()) {
+		save_fp(p);
 	}
 
 	/* set up new TSS. */
diff -Nru link/arch/mips64/kernel/ptrace.c.orig link/arch/mips64/kernel/ptrace.c
--- link/arch/mips64/kernel/ptrace.c.orig	Fri Nov  1 10:11:18 2002
+++ link/arch/mips64/kernel/ptrace.c	Fri Nov  1 10:37:41 2002
@@ -23,6 +23,7 @@
 #include <linux/user.h>
 
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/mipsregs.h>
 #include <asm/pgtable.h>
 #include <asm/page.h>
@@ -112,23 +113,7 @@
 			break;
 		case FPR_BASE ... FPR_BASE + 31:
 			if (child->used_math) {
-				unsigned long *fregs
-					= (unsigned long *)
-					    &child->thread.fpu.hard.fp_regs[0];
-				if (mips_cpu.options & MIPS_CPU_FPU) {
-#ifndef CONFIG_SMP
-					if (last_task_used_math == child) {
-						__enable_fpu();
-						save_fp(child);
-						__disable_fpu();
-						last_task_used_math = NULL;
-					}
-#endif
-				} else {
-					fregs = (unsigned long *)
-						child->thread.fpu.soft.regs;
-				}
-
+				unsigned long *fregs = get_fpu_regs(child);
 				tmp = (unsigned long) fregs[addr - FPR_BASE];
 			} else {
 				tmp = -EIO;
@@ -191,24 +176,8 @@
 			regs->regs[addr] = data;
 			break;
 		case FPR_BASE ... FPR_BASE + 31: {
-			unsigned long *fregs;
-			fregs = (unsigned long *)&child->thread.fpu.hard.fp_regs[0];
-			if (child->used_math) {
-#ifndef CONFIG_SMP
-				if (last_task_used_math == child) {
-					if (mips_cpu.options & MIPS_CPU_FPU) {
-						__enable_fpu();
-						save_fp(child);
-						__disable_fpu();
-						last_task_used_math = NULL;
-						regs->cp0_status &= ~ST0_CU1;
-					} else {
-						fregs = (unsigned long *)
-						child->thread.fpu.soft.regs;
-					}
-				}
-#endif
-			} else {
+			unsigned long *fregs = get_fpu_regs(child);
+			if (!child->used_math) {
 				/* FP not yet used  */
 				memset(&child->thread.fpu.hard, ~0,
 				       sizeof(child->thread.fpu.hard));
diff -Nru link/arch/mips64/kernel/signal.c.orig link/arch/mips64/kernel/signal.c
--- link/arch/mips64/kernel/signal.c.orig	Fri Nov  1 10:11:18 2002
+++ link/arch/mips64/kernel/signal.c	Fri Nov  1 10:40:45 2002
@@ -27,14 +27,13 @@
 #include <asm/uaccess.h>
 #include <asm/ucontext.h>
 #include <asm/system.h>
+#include <asm/fpu.h>
 
 #define DEBUG_SIG 0
 
 #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP)))
 
 extern asmlinkage int do_signal(sigset_t *oldset, struct pt_regs *regs);
-extern asmlinkage int (*save_fp_context)(struct sigcontext *sc);
-extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
 
 extern asmlinkage void do_syscall_trace(void);
 
@@ -83,57 +82,8 @@
 	return do_sigaltstack(uss, uoss, usp);
 }
 
-static inline int restore_thread_fp_context(struct sigcontext *sc)
-{
-     u64 *pfreg = &current->thread.fpu.soft.regs[0];
-     int err = 0;
-
-     /*
-      * Copy all 32 64-bit values.
-      */
-
-#define restore_fpr(i)                          \
-     do { err |= __get_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-     restore_fpr( 0); restore_fpr( 1); restore_fpr( 2); restore_fpr( 3);
-     restore_fpr( 4); restore_fpr( 5); restore_fpr( 6); restore_fpr( 7);
-     restore_fpr( 8); restore_fpr( 9); restore_fpr(10); restore_fpr(11);
-     restore_fpr(12); restore_fpr(13); restore_fpr(14); restore_fpr(15);
-     restore_fpr(16); restore_fpr(17); restore_fpr(18); restore_fpr(19);
-     restore_fpr(20); restore_fpr(21); restore_fpr(22); restore_fpr(23);
-     restore_fpr(24); restore_fpr(25); restore_fpr(26); restore_fpr(27);
-     restore_fpr(28); restore_fpr(29); restore_fpr(30); restore_fpr(31);
-
-     err |= __get_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-     return err;
-}
-
-static inline int save_thread_fp_context(struct sigcontext *sc)
-{
-     u64 *pfreg = &current->thread.fpu.soft.regs[0];
-     int err = 0;
-
-#define save_fpr(i)                                     \
-     do { err |= __put_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-     save_fpr( 0); save_fpr( 1); save_fpr( 2); save_fpr( 3);
-     save_fpr( 4); save_fpr( 5); save_fpr( 6); save_fpr( 7);
-     save_fpr( 8); save_fpr( 9); save_fpr(10); save_fpr(11);
-     save_fpr(12); save_fpr(13); save_fpr(14); save_fpr(15);
-     save_fpr(16); save_fpr(17); save_fpr(18); save_fpr(19);
-     save_fpr(20); save_fpr(21); save_fpr(22); save_fpr(23);
-     save_fpr(24); save_fpr(25); save_fpr(26); save_fpr(27);
-     save_fpr(28); save_fpr(29); save_fpr(30); save_fpr(31);
-
-     err |= __put_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-     return err;
-}
-
 asmlinkage int restore_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 
 	err |= __get_user(regs->cp0_epc, &sc->sc_pc);
@@ -156,26 +106,17 @@
 	restore_gp_reg(31);
 #undef restore_gp_reg
 
-	err |= __get_user(owned_fp, &sc->sc_ownedfp);
 	err |= __get_user(current->used_math, &sc->sc_used_math);
 
-	if (owned_fp) {
-		err |= restore_fp_context(sc);
-		goto out;
-	}
-
-	if (current == last_task_used_math) {
-		/* Signal handler acquired FPU - give it back */
-		last_task_used_math = NULL;
-		regs->cp0_status &= ~ST0_CU1;
-	}
-
 	if (current->used_math) {
-		/* Undo possible contamination of thread state */
-		err |= restore_thread_fp_context(sc);
+		/* restore fpu context if we have used it before */
+		own_fpu();
+		err |= restore_fp_context(sc);
+	} else {
+		/* signal handler may have used FPU.  Give it up. */
+		loose_fpu();
 	}
 
-out:
 	return err;
 }
 
@@ -195,7 +136,6 @@
 
 static int inline setup_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 
 	err |= __put_user(regs->cp0_epc, &sc->sc_pc);
@@ -220,25 +160,20 @@
 	err |= __put_user(regs->cp0_cause, &sc->sc_cause);
 	err |= __put_user(regs->cp0_badvaddr, &sc->sc_badvaddr);
 
-	owned_fp = (current == last_task_used_math);
-	err |= __put_user(owned_fp, &sc->sc_ownedfp);
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
 	if (!current->used_math)
 		goto out;
 
-	/* There exists FP thread state that may be trashed by signal */
-	if (owned_fp) {
-		/* fp is active.  Save context from FPU */
-		err |= save_fp_context(sc);
-		goto out;
-	}
-
 	/*
-	 * Someone else has FPU.
-	 * Copy Thread context into signal context
+	 * Save FPU state to signal context.  Signal handler will "inherit"
+	 * current FPU state.
 	 */
-	err |= save_thread_fp_context(sc);
+	if (!is_fpu_owner()) {
+		own_fpu();
+		restore_fp(current);
+	}
+	err |= save_fp_context(sc);
 
 out:
 	return err;
diff -Nru link/arch/mips64/kernel/traps.c.orig link/arch/mips64/kernel/traps.c
--- link/arch/mips64/kernel/traps.c.orig	Fri Nov  1 10:11:19 2002
+++ link/arch/mips64/kernel/traps.c	Fri Nov  1 10:43:39 2002
@@ -21,6 +21,7 @@
 #include <asm/bootinfo.h>
 #include <asm/branch.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/module.h>
 #include <asm/pgtable.h>
 #include <asm/io.h>
@@ -560,49 +561,33 @@
 asmlinkage void do_cpu(struct pt_regs *regs)
 {
 	unsigned int cpid;
-	void fpu_emulator_init_fpu(void);
-	int sig;
 
 	cpid = (regs->cp0_cause >> CAUSEB_CE) & 3;
 	if (cpid != 1)
 		goto bad_cid;
 
-	if (!(mips_cpu.options & MIPS_CPU_FPU))
-		goto fp_emul;
+	die_if_kernel("do_cpu invoked from kernel context!", regs);
 
-	regs->cp0_status |= ST0_CU1;
-	if (last_task_used_math == current)
-		return;
-
-	if (current->used_math) {		/* Using the FPU again.  */
-		lazy_fpu_switch(last_task_used_math, current);
-	} else {				/* First time FPU user.  */
-		if (last_task_used_math != NULL)
-			save_fp(last_task_used_math);
+	own_fpu();
+	if (current->used_math) {               /* Using the FPU again.  */
+		restore_fp(current);
+	} else {
 		init_fpu();
 		current->used_math = 1;
 	}
-	last_task_used_math = current;
 
-	return;
-
-fp_emul:
-	if (last_task_used_math != current) {
-		if (!current->used_math) {
-			fpu_emulator_init_fpu();
-			current->used_math = 1;
+	if (!(mips_cpu.options & MIPS_CPU_FPU)) {
+		int sig = fpu_emulator_cop1Handler(0, regs, &current->thread.fpu.soft);
+		if (sig) {
+			/*
+			 * Return EPC is not calculated in the FPU emulator, if
+			 * a signal is being send. So we calculate it here.
+			 */
+			compute_return_epc(regs);
+			force_sig(sig, current);
 		}
 	}
-	sig = fpu_emulator_cop1Handler(0, regs, &current->thread.fpu.soft);
-	last_task_used_math = current;
-	if (sig) {
-		/*
-		 * Return EPC is not calculated in the FPU emulator, if
-		 * a signal is being send. So we calculate it here.
-		 */
-		compute_return_epc(regs);
-		force_sig(sig, current);
-	}
+
 	return;
 
 bad_cid:
@@ -676,6 +661,7 @@
 
 asmlinkage int (*save_fp_context)(struct sigcontext *sc);
 asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
+
 extern asmlinkage int _save_fp_context(struct sigcontext *sc);
 extern asmlinkage int _restore_fp_context(struct sigcontext *sc);
 
diff -Nru link/arch/mips64/kernel/r4k_switch.S.orig link/arch/mips64/kernel/r4k_switch.S
--- link/arch/mips64/kernel/r4k_switch.S.orig	Fri Nov  1 10:11:18 2002
+++ link/arch/mips64/kernel/r4k_switch.S	Fri Nov  1 10:45:55 2002
@@ -23,6 +23,19 @@
 
 	.set	mips3
 
+#define PF_USEDFPU      0x00100000      /* task used FPU this quantum (SMP) */
+#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
+
+/*
+ * [jsun] FPU context is saved if and only if the process has used FPU in 
+ * the current run (PF_USEDFPU).  In any case, the CU1 bit for user space 
+ * STATUS register should be 0, so that a process *always* starts its 
+ * userland with FPU disabled after each context switch.
+ *
+ * FPU will be enabled as soon as the process accesses FPU again, through
+ * do_cpu() trap.
+ */
+
 /*
  * task_struct *resume(task_struct *prev, task_struct *next,
  *                     struct thread_info *next_ti))
@@ -35,6 +48,38 @@
 	sd	ra, THREAD_REG31(a0)
 
 	/*
+	 * check if we need to save FPU registers
+	 */
+	ld	t0, TASK_FLAGS(a0)
+	li	t1, PF_USEDFPU
+	and	t2, t0, t1
+	beqz	t2, 1f
+	nor	t1, zero, t1
+
+	/*
+	 * clear PF_USEDFPU bit in task flags
+	 */
+	and	t0, t0, t1
+	sd	t0, TASK_FLAGS(a0)
+
+	/*
+	 * clear saved user stack CU1 bit
+	 */
+	ld	t0, ST_OFF(a0)
+	li	t1, ~ST0_CU1
+	and	t0, t0, t1
+	sd	t0, ST_OFF(a0)
+
+	
+	sll	t2, t0, 5
+	bgez	t2, 2f
+	sdc1	$f0, (THREAD_FPU + 0x00)(a0)
+        fpu_save_16odd a0
+2:
+        fpu_save_16even a0 t1                   # clobbers t1
+1:
+
+	/*
 	 * The order of restoring the registers takes care of the race
 	 * updating $28, $29 and kernelsp without disabling ints.
 	 */
@@ -57,49 +102,9 @@
 	END(resume)
 
 /*
- * Do lazy fpu context switch.  Saves FPU context to the process in a0
- * and loads the new context of the current process.
- */
-
-#define ST_OFF (KERNEL_STACK_SIZE - 32 - PT_SIZE + PT_STATUS)
-
-LEAF(lazy_fpu_switch)
-	mfc0	t0, CP0_STATUS			# enable cp1
-	li	t3, ST0_CU1
-	or	t0, t3
-	mtc0	t0, CP0_STATUS
-	FPU_ENABLE_HAZARD
-
-	nor	t3, zero, t3
-	beqz	a0, 2f				# Save floating point state
-
-	ld	t1, ST_OFF(a0)			# last thread looses fpu
-	and	t1, t3
-	sd	t1, ST_OFF(a0)
-	sll	t2, t1, 5
-	sdc1	$f0, (THREAD_FPU + 0x00)(a0)
-	bgez	t2, 1f
-	fpu_save_16odd a0
-1:
-	fpu_save_16even a0 t1			# clobbers t1
-2:
-
-	beqz	a1, 3f
-
-	sll	t0, t0, 5			# load new fp state
-	ldc1	$f0, (THREAD_FPU + 0x00)(a1)
-	bgez	t0, 1f
-	fpu_restore_16odd a1
-1:
-	fpu_restore_16even a1, t0		# clobbers t0
-3:
-	jr	ra
-	END(lazy_fpu_switch)
-
-/*
  * Save a thread's fp context.
  */
-LEAF(save_fp)
+LEAF(_save_fp)
 	mfc0	t0, CP0_STATUS
 	sll	t1, t0, 5
 	bgez	t1, 1f				# 16 register mode?
@@ -108,12 +113,12 @@
 	fpu_save_16even a0 t1			# clobbers t1
 	sdc1	$f0, (THREAD_FPU + 0x00)(a0)
 	jr	ra
-	END(save_fp)
+	END(_save_fp)
 
 /*
  * Restore a thread's fp context.
  */
-LEAF(restore_fp)
+LEAF(_restore_fp)
 	mfc0	t0, CP0_STATUS
 	sll	t1, t0, 5
 	bgez	t1, 1f				# 16 register mode?
@@ -123,7 +128,7 @@
 	 ldc1	$f0, (THREAD_FPU + 0x00)(a0)
 
 	jr	ra
-	END(restore_fp)
+	END(_restore_fp)
 
 /*
  * Load the FPU with signalling NANS.  This bit pattern we're using has
@@ -135,7 +140,7 @@
 
 #define FPU_DEFAULT  0x00000000
 
-LEAF(init_fpu)
+LEAF(_init_fpu)
 	mfc0	t0, CP0_STATUS
 	li	t1, ST0_CU1
 	or	t0, t1
@@ -183,4 +188,4 @@
 	dmtc1	t0, $f28
 	dmtc1	t0, $f30
 	jr	ra
-	END(init_fpu)
+	END(_init_fpu)
diff -Nru link/arch/mips64/kernel/cpu-probe.c.orig link/arch/mips64/kernel/cpu-probe.c
--- link/arch/mips64/kernel/cpu-probe.c.orig	Tue Sep  3 14:04:31 2002
+++ link/arch/mips64/kernel/cpu-probe.c	Fri Nov  1 10:17:50 2002
@@ -3,6 +3,7 @@
 #include <linux/stddef.h>
 #include <asm/bugs.h>
 #include <asm/cpu.h>
+#include <asm/fpu.h>
 #include <asm/mipsregs.h>
 
 /*
diff -Nru link/arch/mips64/kernel/signal32.c.orig link/arch/mips64/kernel/signal32.c
--- link/arch/mips64/kernel/signal32.c.orig	Fri Nov  1 10:11:19 2002
+++ link/arch/mips64/kernel/signal32.c	Fri Nov  1 10:53:18 2002
@@ -25,14 +25,13 @@
 #include <asm/uaccess.h>
 #include <asm/ucontext.h>
 #include <asm/system.h>
+#include <asm/fpu.h>
 
 #define DEBUG_SIG 0
 
 #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP)))
 
 extern asmlinkage int do_signal32(sigset_t *oldset, struct pt_regs *regs);
-extern asmlinkage int (*save_fp_context)(struct sigcontext *sc);
-extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc);
 
 extern asmlinkage void do_syscall_trace(void);
 
@@ -257,58 +256,9 @@
 	return ret;
 }
 
-static inline int restore_thread_fp_context(struct sigcontext *sc)
-{
-	u64 *pfreg = &current->thread.fpu.soft.regs[0];
-	int err = 0;
-
-	/*
-	 * Copy all 32 64-bit values.
-	 */
-
-#define restore_fpr(i) 						\
-	do { err |= __get_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-	restore_fpr( 0); restore_fpr( 1); restore_fpr( 2); restore_fpr( 3);
-	restore_fpr( 4); restore_fpr( 5); restore_fpr( 6); restore_fpr( 7);
-	restore_fpr( 8); restore_fpr( 9); restore_fpr(10); restore_fpr(11);
-	restore_fpr(12); restore_fpr(13); restore_fpr(14); restore_fpr(15);
-	restore_fpr(16); restore_fpr(17); restore_fpr(18); restore_fpr(19);
-	restore_fpr(20); restore_fpr(21); restore_fpr(22); restore_fpr(23);
-	restore_fpr(24); restore_fpr(25); restore_fpr(26); restore_fpr(27);
-	restore_fpr(28); restore_fpr(29); restore_fpr(30); restore_fpr(31);
-
-	err |= __get_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-	return err;
-}
-
-static inline int save_thread_fp_context(struct sigcontext *sc)
-{
-	u64 *pfreg = &current->thread.fpu.soft.regs[0];
-	int err = 0;
-
-#define save_fpr(i) 							\
-	do { err |= __put_user(pfreg[i], &sc->sc_fpregs[i]); } while(0)
-
-	save_fpr( 0); save_fpr( 1); save_fpr( 2); save_fpr( 3);
-	save_fpr( 4); save_fpr( 5); save_fpr( 6); save_fpr( 7);
-	save_fpr( 8); save_fpr( 9); save_fpr(10); save_fpr(11);
-	save_fpr(12); save_fpr(13); save_fpr(14); save_fpr(15);
-	save_fpr(16); save_fpr(17); save_fpr(18); save_fpr(19);
-	save_fpr(20); save_fpr(21); save_fpr(22); save_fpr(23);
-	save_fpr(24); save_fpr(25); save_fpr(26); save_fpr(27);
-	save_fpr(28); save_fpr(29); save_fpr(30); save_fpr(31);
-
-	err |= __put_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);
-
-	return err;
-}
-
 static asmlinkage int restore_sigcontext(struct pt_regs *regs,
 					 struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 
 	err |= __get_user(regs->cp0_epc, &sc->sc_pc);
@@ -331,26 +281,17 @@
 	restore_gp_reg(31);
 #undef restore_gp_reg
 
-	err |= __get_user(owned_fp, &sc->sc_ownedfp);
 	err |= __get_user(current->used_math, &sc->sc_used_math);
 
-	if (owned_fp) {
-		err |= restore_fp_context(sc);
-		goto out;
-	}
-
-	if (current == last_task_used_math) {
-		/* Signal handler acquired FPU - give it back */
-		last_task_used_math = NULL;
-		regs->cp0_status &= ~ST0_CU1;
-	}
-
 	if (current->used_math) {
-		/* Undo possible contamination of thread state */
-		err |= restore_thread_fp_context(sc);
+		/* restore fpu context if we have used it before */
+		own_fpu();
+		err |= restore_fp_context(sc);
+	} else {
+		/* signal handler may have used FPU.  Give it up. */
+		loose_fpu();
 	}
 
-out:
 	return err;
 }
 
@@ -490,7 +431,6 @@
 static int inline setup_sigcontext(struct pt_regs *regs,
 				   struct sigcontext *sc)
 {
-	int owned_fp;
 	int err = 0;
 
 	err |= __put_user(regs->cp0_epc, &sc->sc_pc);
@@ -515,25 +455,20 @@
 	err |= __put_user(regs->cp0_cause, &sc->sc_cause);
 	err |= __put_user(regs->cp0_badvaddr, &sc->sc_badvaddr);
 
-	owned_fp = (current == last_task_used_math);
-	err |= __put_user(owned_fp, &sc->sc_ownedfp);
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
 	if (!current->used_math)
 		goto out;
 
-	/* There exists FP thread state that may be trashed by signal */
-	if (owned_fp) {
-		/* fp is active.  Save context from FPU */
-		err |= save_fp_context(sc);
-		goto out;
-	}
-
-	/*
-	 * Someone else has FPU.
-	 * Copy Thread context into signal context
+	/* 
+	 * Save FPU state to signal context.  Signal handler will "inherit"
+	 * current FPU state.
 	 */
-	err |= save_thread_fp_context(sc);
+	if (!is_fpu_owner()) {
+		own_fpu();
+		restore_fp(current);
+	}
+	err |= save_fp_context(sc);
 
 out:
 	return err;
diff -Nru link/include/asm-mips/processor.h.orig link/include/asm-mips/processor.h
--- link/include/asm-mips/processor.h.orig	Fri Nov  1 10:13:26 2002
+++ link/include/asm-mips/processor.h	Fri Nov  1 11:11:19 2002
@@ -71,9 +71,6 @@
 #define wp_works_ok 1
 #define wp_works_ok__is_a_macro /* for versions in ksyms.c */
 
-/* Lazy FPU handling on uni-processor */
-extern struct task_struct *last_task_used_math;
-
 /*
  * User space process size: 2GB. This is hardcoded into a few places,
  * so don't change it unless you know what you are doing.  TASK_SIZE
@@ -196,20 +193,16 @@
 /*
  * Do necessary setup to start up a newly executed thread.
  */
-#define start_thread(regs, new_pc, new_sp) do {				\
-	/* New thread loses kernel and FPU privileges. */	       	\
-	regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU|ST0_CU1)) | KU_USER;\
-	regs->cp0_epc = new_pc;						\
-	regs->regs[29] = new_sp;					\
-	current_thread_info()->addr_limit = USER_DS;			\
-} while (0)
+extern void start_thread(struct pt_regs * regs, unsigned long pc, unsigned long sp);
 
+struct task_struct;
 unsigned long get_wchan(struct task_struct *p);
 
 #define __PT_REG(reg) ((long)&((struct pt_regs *)0)->reg - sizeof(struct pt_regs))
 #define __KSTK_TOS(tsk) ((unsigned long)(tsk->thread_info) + KERNEL_STACK_SIZE - 32)
 #define KSTK_EIP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_epc)))
 #define KSTK_ESP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(regs[29])))
+#define KSTK_STATUS(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_status)))
 
 #define cpu_relax()	barrier()
 
diff -Nru link/include/asm-mips/mipsregs.h.orig link/include/asm-mips/mipsregs.h
--- link/include/asm-mips/mipsregs.h.orig	Fri Nov  1 10:13:26 2002
+++ link/include/asm-mips/mipsregs.h	Fri Nov  1 10:17:50 2002
@@ -1002,48 +1002,6 @@
 __BUILD_SET_CP0(cause,CP0_CAUSE)
 __BUILD_SET_CP0(config,CP0_CONFIG)
 
-#if defined(CONFIG_CPU_SB1)
-#define __enable_fpu_hazard()						\
-do {									\
-	asm(".set push		\n\t"					\
-	    ".set mips64	\n\t"					\
-	    ".set noreorder	\n\t"					\
-	    "ssnop		\n\t"					\
-	    "bnezl $0, .+4	\n\t"					\
-	    "ssnop		\n\t"					\
-	    ".set pop");						\
-} while (0)
-#else
-#define __enable_fpu_hazard()						\
-do {									\
-	asm("nop;nop;nop;nop");		/* max. hazard */		\
-} while (0)
-#endif
-
-#define __enable_fpu()							\
-do {									\
-	set_cp0_status(ST0_CU1);					\
-	__enable_fpu_hazard();						\
-} while (0)
-
-#define __disable_fpu()							\
-do {									\
-	clear_cp0_status(ST0_CU1);					\
-	/* We don't care about the cp0 hazard here  */			\
-} while (0)
-
-#define enable_fpu()							\
-do {									\
-	if (mips_cpu.options & MIPS_CPU_FPU)				\
-		__enable_fpu();						\
-} while (0)
-
-#define disable_fpu()							\
-do {									\
-	if (mips_cpu.options & MIPS_CPU_FPU)				\
-		__disable_fpu();					\
-} while (0)
-
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_MIPSREGS_H */
diff -Nru link/include/asm-mips/sigcontext.h.orig link/include/asm-mips/sigcontext.h
--- link/include/asm-mips/sigcontext.h.orig	Wed Jul 10 14:26:34 2002
+++ link/include/asm-mips/sigcontext.h	Fri Nov  1 10:17:50 2002
@@ -18,7 +18,6 @@
 	unsigned long long sc_pc;
 	unsigned long long sc_regs[32];
 	unsigned long long sc_fpregs[32];
-	unsigned int       sc_ownedfp;
 	unsigned int       sc_fpc_csr;
 	unsigned int       sc_fpc_eir;		/* Unused */
 	unsigned int       sc_used_math;
diff -Nru link/include/asm-mips/system.h.orig link/include/asm-mips/system.h
--- link/include/asm-mips/system.h.orig	Fri Nov  1 10:13:26 2002
+++ link/include/asm-mips/system.h	Fri Nov  1 10:54:37 2002
@@ -225,11 +225,6 @@
 
 struct task_struct;
 
-extern asmlinkage void lazy_fpu_switch(void *prev, void *next);
-extern asmlinkage void init_fpu(void);
-extern asmlinkage void save_fp(struct task_struct *);
-extern asmlinkage void restore_fp(struct task_struct *);
-
 #define switch_to(prev,next,last) \
 do { \
 	(last) =resume(prev, next, next->thread_info); \
diff -Nru link/include/asm-mips64/mipsregs.h.orig link/include/asm-mips64/mipsregs.h
--- link/include/asm-mips64/mipsregs.h.orig	Fri Nov  1 10:13:27 2002
+++ link/include/asm-mips64/mipsregs.h	Fri Nov  1 10:17:53 2002
@@ -896,47 +896,6 @@
 __BUILD_SET_CP0(cause,CP0_CAUSE)
 __BUILD_SET_CP0(config,CP0_CONFIG)
 
-#if defined(CONFIG_CPU_SB1)
-#define __enable_fpu_hazard()						\
-do {									\
-	asm(".set push		\n\t"					\
-	    ".set mips2		\n\t"					\
-	    ".set noreorder	\n\t"					\
-	    "sll $0,$0,1	\n\t"					\
-	    "bnezl $0, .+4	\n\t"					\
-	    " sll $0,$0,1	\n\t"					\
-	    ".set pop");						\
-} while (0)
-#else
-#define __enable_fpu_hazard()						\
-do {									\
-	asm("nop;nop;nop;nop");		/* max. hazard */		\
-} while (0)
-#endif
-
-#define __enable_fpu()							\
-do {									\
-	set_cp0_status(ST0_CU1);					\
-	__enable_fpu_hazard();						\
-} while (0)
-
-#define __disable_fpu()							\
-do {									\
-	clear_cp0_status(ST0_CU1);					\
-	/* We don't care about the cp0 hazard here  */			\
-} while (0)
-
-#define enable_fpu()							\
-do {									\
-	if (mips_cpu.options & MIPS_CPU_FPU)				\
-		__enable_fpu();						\
-} while (0)
-
-#define disable_fpu()							\
-do {									\
-	if (mips_cpu.options & MIPS_CPU_FPU)				\
-		__disable_fpu();					\
-} while (0)
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_MIPSREGS_H */
diff -Nru link/include/asm-mips64/sigcontext.h.orig link/include/asm-mips64/sigcontext.h
--- link/include/asm-mips64/sigcontext.h.orig	Tue Sep  3 14:07:16 2002
+++ link/include/asm-mips64/sigcontext.h	Fri Nov  1 10:17:53 2002
@@ -20,7 +20,6 @@
 	unsigned long long sc_mdlo;
 	unsigned long long sc_pc;
 	unsigned int       sc_status;
-	unsigned int       sc_ownedfp;
 	unsigned int       sc_fpc_csr;
 	unsigned int       sc_fpc_eir;
 	unsigned int       sc_used_math;
diff -Nru link/include/asm-mips64/system.h.orig link/include/asm-mips64/system.h
--- link/include/asm-mips64/system.h.orig	Fri Nov  1 10:13:27 2002
+++ link/include/asm-mips64/system.h	Fri Nov  1 10:58:08 2002
@@ -211,11 +211,6 @@
 
 struct task_struct;
 
-extern asmlinkage void lazy_fpu_switch(void *prev, void *next);
-extern asmlinkage void init_fpu(void);
-extern asmlinkage void save_fp(struct task_struct *);
-extern asmlinkage void restore_fp(struct task_struct *);
-
 #define switch_to(prev,next,last) \
 do { \
 	(last) = resume(prev, next, next->thread_info); \
diff -Nru link/include/asm-mips64/processor.h.orig link/include/asm-mips64/processor.h
--- link/include/asm-mips64/processor.h.orig	Fri Nov  1 10:13:27 2002
+++ link/include/asm-mips64/processor.h	Fri Nov  1 11:12:27 2002
@@ -100,9 +100,6 @@
 #define wp_works_ok 1
 #define wp_works_ok__is_a_macro /* for versions in ksyms.c */
 
-/* Lazy FPU handling on uni-processor */
-extern struct task_struct *last_task_used_math;
-
 /*
  * User space process size: 1TB. This is hardcoded into a few places,
  * so don't change it unless you know what you are doing.  TASK_SIZE
@@ -231,26 +228,16 @@
 /*
  * Do necessary setup to start up a newly executed thread.
  */
-#define start_thread(regs, pc, sp) 					\
-do {									\
-	unsigned long __status;						\
-									\
-	/* New thread looses kernel privileges. */			\
-	__status = regs->cp0_status & ~(ST0_CU0|ST0_FR|ST0_KSU);	\
-	__status |= KSU_USER;						\
-	__status |= (current->thread.mflags & MF_32BIT) ? 0 : ST0_FR;	\
-	regs->cp0_status = __status;					\
-	regs->cp0_epc = pc;						\
-	regs->regs[29] = sp;						\
-	current_thread_info()->addr_limit = USER_DS;			\
-} while(0)
+extern void start_thread(struct pt_regs * regs, unsigned long pc, unsigned long sp);
 
+struct task_struct;
 unsigned long get_wchan(struct task_struct *p);
 
 #define __PT_REG(reg) ((long)&((struct pt_regs *)0)->reg - sizeof(struct pt_regs))
 #define __KSTK_TOS(tsk) ((unsigned long)(tsk->thread_info) + KERNEL_STACK_SIZE - 32)
 #define KSTK_EIP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_epc)))
 #define KSTK_ESP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(regs[29])))
+#define KSTK_STATUS(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_status)))
 
 #define cpu_relax()	barrier()
 

--zhXaljGHf11kAtnf--

From roger_twede@hp.com Fri Nov  1 22:28:56 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Nov 2002 22:28:57 +0100 (CET)
Received: from palrel11.hp.com ([156.153.255.246]:18883 "HELO palrel11.hp.com")
	by linux-mips.org with SMTP id <S1121744AbSKAV24>;
	Fri, 1 Nov 2002 22:28:56 +0100
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel11.hp.com (Postfix) with ESMTP
	id 0E99E600BE3; Fri,  1 Nov 2002 13:28:42 -0800 (PST)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP
	id CA332E0009C; Fri,  1 Nov 2002 13:28:41 -0800 (PST)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <V5H0G19N>; Fri, 1 Nov 2002 13:28:41 -0800
Message-ID: <CBD6266EA291D5118144009027AA63350A68F189@xboi05.boi.hp.com>
From: "TWEDE,ROGER (HP-Boise,ex1)" <roger_twede@hp.com>
To: 'Ralf Baechle' <ralf@linux-mips.org>,
	"TWEDE,ROGER (HP-Boise,ex1)" <roger_twede@hp.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: RE: NFS Root failure in 2.4.18 - Traced to 256k COLOUR_ALIGN
Date: Fri, 1 Nov 2002 13:28:32 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <roger_twede@hp.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: 551
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: roger_twede@hp.com
Precedence: bulk
X-list: linux-mips

I traced the NFS root boot failure to a change made in the the function
arch_get_unmapped_area(...).  The system goes from functional to
non-functional with a single function change made in 2.4.18.
linux/arch/mips/kernel/syscall.c :: arch_get_unmapped_area(...),
COLOUR_ALIGN 

The virtual mappings are now aligned on a 256k boundary instead of a page
boundary whenever the mapping is to be shared (as in an executable file
mapping).  The COLOUR_ALIGN macro was added and is used in place of
PAGE_ALIGN as found in the file arch/mips/kernel/syscall.c.

As our system boots from a disk such as ide, all calls to this function pass
in a requested address of 0x0.  The function then chooses a free virtual
address space accordingly.  Upon nfsroot booting, calls to this function
pass in a requested address that is non-zero (such as 0x0fb60000).  This
address is page aligned, so in the old version of
arch_get_unmapped_area(...) the exact requested address was fine and
returned from the get_unmapped_area().  In the new version of the function,
the alignment requirement is 256k, however the nfs requested address is not
aligned on a 256k boundary, and is therefore pushed up to the next 256k
boundary.  The system does not like this and fails. (the function is never
called again, further booting does not take place)

Several questions that arise:
- In the nfs case, should the file structure have its
file->f_op->get_unmapped_area() member assigned, causing a file specific
get_unmapped_area to be called instead of this arch_get_unmapped_area?
- Or should the mapping request pass in a requested address which already
has valid 256k alignment?
- Or should requested addresses that are misaligned be handled well by the
calling code once the translated/aligned address is returned to the calller?

And generally:
- Why does nfsroot booting cause apecific non-zero virtual addresses to be
requested, whereas in the ide disk booting case, addressed are left
unspecified (0x0) (no requested mapping)?

Thanks for any information anyone might lend.

Roger

From Geert.Uytterhoeven@sonycom.com Sat Nov  2 21:12:38 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Nov 2002 21:12:38 +0100 (CET)
Received: from mail2.sonytel.be ([195.0.45.172]:53417 "EHLO mail.sonytel.be")
	by linux-mips.org with ESMTP id <S1122037AbSKBUMh>;
	Sat, 2 Nov 2002 21:12:37 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id VAA29999
	for <linux-mips@linux-mips.org>; Sat, 2 Nov 2002 21:12:26 +0100 (MET)
Date: Sat, 2 Nov 2002 21:12:27 +0100 (MET)
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: <20021102200215Z1123906-9213+801@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0211022110440.12247-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: 552
X-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, 2 Nov 2002 ralf@linux-mips.org wrote:
> Log message:
> 	Merge with Linux 2.5.45.

Congratulations!!! That was a very fast merge cycle!

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 yuasa@hh.iij4u.or.jp Sun Nov  3 15:53:00 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Nov 2002 15:53:01 +0100 (CET)
Received: from r-hh.iij4u.or.jp ([210.130.0.72]:9203 "EHLO r-hh.iij4u.or.jp")
	by linux-mips.org with ESMTP id <S1122109AbSKCOxA>;
	Sun, 3 Nov 2002 15:53:00 +0100
Received: from stratos (h197.p500.iij4u.or.jp [210.149.244.197])
	by r-hh.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id gA3EqmQ19069;
	Sun, 3 Nov 2002 23:52:48 +0900 (JST)
Date: Sun, 3 Nov 2002 23:52:24 +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: fixed the problem about build of vr41xx on linux-2.5.45
Message-Id: <20021103235224.2d7a4814.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Sun__3_Nov_2002_23:52:24_+0900_08824850"
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: 553
X-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_Sun__3_Nov_2002_23:52:24_+0900_08824850
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I fixed the problem about build of vr41xx on linux-2.5.45.
Here is a patch.

Please apply this patch.

Thanks,

Yoichi
--Multipart_Sun__3_Nov_2002_23:52:24_+0900_08824850
Content-Type: text/plain;
 name="vr41xx-2.4.45.diff"
Content-Disposition: attachment;
 filename="vr41xx-2.4.45.diff"
Content-Transfer-Encoding: 7bit

diff -aruN linux.orig/arch/mips/Kconfig-shared linux/arch/mips/Kconfig-shared
--- linux.orig/arch/mips/Kconfig-shared	Sun Nov  3 20:42:38 2002
+++ linux/arch/mips/Kconfig-shared	Sun Nov  3 22:45:44 2002
@@ -508,7 +508,7 @@
 
 config SERIAL
 	tristate
-	depends on NEC_OSPREY || IBM_WORKPAD || CASIO_E55
+	depends on ZAO_CAPCELLA || NEC_EAGLE || NEC_OSPREY || VICTOR_MPC30X || IBM_WORKPAD || CASIO_E55
 	default y
 	---help---
 	  This selects whether you want to include the driver for the standard
@@ -553,9 +553,9 @@
 	depends on MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000
 	default y
 
-config CONFIG_VR41XX_COMMON
+config VR41XX_COMMON
 	bool
-	depends on CONFIG_NEC_EAGLE || CONFIG_ZAO_CAPCELLA || CONFIG_VICTOR_MPC30X || CONFIG_IBM_WORKPAD || CONFIG_CASIO_E55
+	depends on NEC_EAGLE || ZAO_CAPCELLA || VICTOR_MPC30X || IBM_WORKPAD || CASIO_E55
 	default y
 
 config CONFIG_DDB5XXX_COMMON
diff -aruN linux.orig/arch/mips/defconfig-workpad linux/arch/mips/defconfig-workpad
--- linux.orig/arch/mips/defconfig-workpad	Sun Nov  3 20:43:06 2002
+++ linux/arch/mips/defconfig-workpad	Sun Nov  3 23:36:58 2002
@@ -22,7 +22,7 @@
 # Loadable module support
 #
 CONFIG_MODULES=y
-CONFIG_MODVERSIONS=y
+# CONFIG_MODVERSIONS is not set
 CONFIG_KMOD=y
 
 #
@@ -72,6 +72,7 @@
 CONFIG_SERIAL=y
 CONFIG_SERIAL_MANY_PORTS=y
 CONFIG_DUMMY_KEYB=y
+CONFIG_VR41XX_COMMON=y
 # CONFIG_FB is not set
 
 #
diff -aruN linux.orig/drivers/ide/mips/Makefile linux/drivers/ide/mips/Makefile
--- linux.orig/drivers/ide/mips/Makefile	Fri Nov  1 05:59:35 2002
+++ linux/drivers/ide/mips/Makefile	Sun Nov  3 23:04:04 2002
@@ -1,6 +1,4 @@
 
-O_TARGET := idedriver-mips.o
-
 obj-y		:=
 obj-m		:=
 
diff -aruN linux.orig/include/asm-mips/ide.h linux/include/asm-mips/ide.h
--- linux.orig/include/asm-mips/ide.h	Thu Oct 31 22:50:01 2002
+++ linux/include/asm-mips/ide.h	Sun Nov  3 22:33:12 2002
@@ -202,8 +202,6 @@
 
 #else /* defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__)  */
 
-#define ide_fix_driveid(id)		do {} while (0)
-
 #endif
 
 #define ide_release_lock(lock)		do {} while (0)
diff -aruN linux.orig/include/asm-mips/system.h linux/include/asm-mips/system.h
--- linux.orig/include/asm-mips/system.h	Sun Nov  3 01:23:55 2002
+++ linux/include/asm-mips/system.h	Sun Nov  3 22:18:07 2002
@@ -319,11 +319,10 @@
 #else
 	unsigned long flags, retval;
 
-	save_flags(flags);
-	cli();
+	local_irq_save(flags);
 	retval = *m;
 	*m = val;
-	restore_flags(flags);	/* implies memory barrier  */
+	local_irq_restore(flags);	/* implies memory barrier  */
 	return retval;
 #endif /* Processor-dependent optimization */
 }

--Multipart_Sun__3_Nov_2002_23:52:24_+0900_08824850--

From ralf@uni-koblenz.de Sun Nov  3 18:37:02 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Nov 2002 18:37:02 +0100 (CET)
Received: from p508B7523.dip.t-dialin.net ([80.139.117.35]:6318 "EHLO
	p508B7523.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122109AbSKCRhC>; Sun, 3 Nov 2002 18:37:02 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S867025AbSKCRgu>; Sun, 3 Nov 2002 18:36:50 +0100
Date: Sun, 3 Nov 2002 18:36:50 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: fixed the problem about build of vr41xx on linux-2.5.45
Message-ID: <20021103183650.A23232@bacchus.dhis.org>
References: <20021103235224.2d7a4814.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021103235224.2d7a4814.yuasa@hh.iij4u.or.jp>; from yuasa@hh.iij4u.or.jp on Sun, Nov 03, 2002 at 11:52:24PM +0900
X-Accept-Language: de,en,fr
Return-Path: <ralf@uni-koblenz.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: 554
X-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@uni-koblenz.de
Precedence: bulk
X-list: linux-mips

On Sun, Nov 03, 2002 at 11:52:24PM +0900, Yoichi Yuasa wrote:

> Hello Ralf,
> 
> I fixed the problem about build of vr41xx on linux-2.5.45.
> Here is a patch.

I applied the patch although quite heavily modified.  Here the bad bits:

>  config SERIAL
>  	tristate
> -	depends on NEC_OSPREY || IBM_WORKPAD || CASIO_E55
> +	depends on ZAO_CAPCELLA || NEC_EAGLE || NEC_OSPREY || VICTOR_MPC30X || IBM_WORKPAD || CASIO_E55
>  	default y
>  	---help---
>  	  This selects whether you want to include the driver for the standard

This misses the problem.  There is no more CONFIG_SERIAL option and as such
I removed all CONFIG_SERIAL* stuff entirely.

> @@ -553,9 +553,9 @@
>  	depends on MIPS_PB1500 || MIPS_PB1100 || MIPS_PB1000
>  	default y
>  
> -config CONFIG_VR41XX_COMMON
> +config VR41XX_COMMON
>  	bool
> -	depends on CONFIG_NEC_EAGLE || CONFIG_ZAO_CAPCELLA || CONFIG_VICTOR_MPC30X || CONFIG_IBM_WORKPAD || CONFIG_CASIO_E55
> +	depends on NEC_EAGLE || ZAO_CAPCELLA || VICTOR_MPC30X || IBM_WORKPAD || CASIO_E55
>  	default y

And this one entirely misses the code of the problem.  There were a whole
bunch of options which accidently still had the CONFIG_ prefix.

> diff -aruN linux.orig/arch/mips/defconfig-workpad linux/arch/mips/defconfig-workpad
> --- linux.orig/arch/mips/defconfig-workpad	Sun Nov  3 20:43:06 2002
> +++ linux/arch/mips/defconfig-workpad	Sun Nov  3 23:36:58 2002
> @@ -22,7 +22,7 @@
>  # Loadable module support
>  #
>  CONFIG_MODULES=y
> -CONFIG_MODVERSIONS=y
> +# CONFIG_MODVERSIONS is not set

It's your call - but as this help to avoid accidents it's a bad idea to
disable CONFIG_MODVERSIONS.

> diff -aruN linux.orig/include/asm-mips/ide.h linux/include/asm-mips/ide.h
> --- linux.orig/include/asm-mips/ide.h	Thu Oct 31 22:50:01 2002
> +++ linux/include/asm-mips/ide.h	Sun Nov  3 22:33:12 2002
> @@ -202,8 +202,6 @@
>  
>  #else /* defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__)  */
>  
> -#define ide_fix_driveid(id)		do {} while (0)
> -

Again this entirely misses the scope of the problem.  There should be no
more definition of ide_fix_driveid() in this file at all and there's
quite a bit more of obsoleted junk left in that file.

  Ralf

From yuasa@hh.iij4u.or.jp Mon Nov  4 12:50:14 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Nov 2002 12:50:15 +0100 (CET)
Received: from r-hh.iij4u.or.jp ([210.130.0.72]:48611 "EHLO r-hh.iij4u.or.jp")
	by linux-mips.org with ESMTP id <S1122109AbSKDLuO>;
	Mon, 4 Nov 2002 12:50:14 +0100
Received: from stratos (h197.p500.iij4u.or.jp [210.149.244.197])
	by r-hh.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id gA4BnuQ25402;
	Mon, 4 Nov 2002 20:49:56 +0900 (JST)
Date: Mon, 4 Nov 2002 20:49:29 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@uni-koblenz.de>
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: fixed the problem about build of vr41xx on linux-2.5.45
Message-Id: <20021104204929.558ddff2.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20021103183650.A23232@bacchus.dhis.org>
References: <20021103235224.2d7a4814.yuasa@hh.iij4u.or.jp>
	<20021103183650.A23232@bacchus.dhis.org>
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Mon__4_Nov_2002_20:49:29_+0900_082566c0"
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: 555
X-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_Mon__4_Nov_2002_20:49:29_+0900_082566c0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

On Sun, 3 Nov 2002 18:36:50 +0100
Ralf Baechle <ralf@uni-koblenz.de> wrote:

> On Sun, Nov 03, 2002 at 11:52:24PM +0900, Yoichi Yuasa wrote:
> 
> > Hello Ralf,
> > 
> > I fixed the problem about build of vr41xx on linux-2.5.45.
> > Here is a patch.
> 
> I applied the patch although quite heavily modified.  Here the bad bits:
> 
> >  config SERIAL
> >  	tristate
> > -	depends on NEC_OSPREY || IBM_WORKPAD || CASIO_E55
> > +	depends on ZAO_CAPCELLA || NEC_EAGLE || NEC_OSPREY || VICTOR_MPC30X || IBM_WORKPAD || CASIO_E55
> >  	default y
> >  	---help---
> >  	  This selects whether you want to include the driver for the standard
> 
> This misses the problem.  There is no more CONFIG_SERIAL option and as such
> I removed all CONFIG_SERIAL* stuff entirely.

I made a patch for vr41xx about this problem.
Please apply a patch.

Thanks,

Yoichi

--Multipart_Mon__4_Nov_2002_20:49:29_+0900_082566c0
Content-Type: text/plain;
 name="vr41xx-serial.diff"
Content-Disposition: attachment;
 filename="vr41xx-serial.diff"
Content-Transfer-Encoding: 7bit

diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Mon Nov  4 15:05:00 2002
@@ -68,5 +68,7 @@
 
 	vr41xx_cmu_init(0);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
+#endif
 }
diff -aruN linux.orig/arch/mips/vr41xx/common/Makefile linux/arch/mips/vr41xx/common/Makefile
--- linux.orig/arch/mips/vr41xx/common/Makefile	Fri Nov  1 11:32:25 2002
+++ linux/arch/mips/vr41xx/common/Makefile	Mon Nov  4 15:01:14 2002
@@ -5,7 +5,7 @@
 obj-y		:= bcu.o cmu.o giu.o icu.o int-handler.o reset.o
 
 obj-$(CONFIG_PCI)		+= pciu.o
-obj-$(CONFIG_SERIAL)		+= serial.o
+obj-$(CONFIG_SERIAL_8250)	+= serial.o
 obj-$(CONFIG_VR41XX_TIME_C)	+= time.o
 
 EXTRA_AFLAGS := $(CFLAGS)
diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Mon Nov  4 15:10:05 2002
@@ -68,5 +68,7 @@
 
 	vr41xx_cmu_init(0);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
+#endif
 }
diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Mon Nov  4 15:10:46 2002
@@ -146,8 +146,10 @@
 
 	vr41xx_cmu_init(0);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_dsiu_init();
 	vr41xx_siu_init(SIU_RS232C, 0);
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Mon Nov  4 15:11:14 2002
@@ -116,7 +116,9 @@
 
 	vr41xx_cmu_init(0);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Mon Nov  4 15:11:52 2002
@@ -116,8 +116,10 @@
 
 	vr41xx_cmu_init(0x0102);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);

--Multipart_Mon__4_Nov_2002_20:49:29_+0900_082566c0--

From sjhill@realitydiluted.com Mon Nov  4 15:49:53 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Nov 2002 15:49:53 +0100 (CET)
Received: from real.realitydiluted.com ([208.242.241.164]:1175 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S1122121AbSKDOtx>; Mon, 4 Nov 2002 15:49:53 +0100
Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux))
	id 188iXw-0004Q2-00; Mon, 04 Nov 2002 08:49:44 -0600
Message-ID: <3DC68907.30708@realitydiluted.com>
Date: Mon, 04 Nov 2002 08:49:43 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl>
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: 556
X-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

Maciej W. Rozycki wrote:
> 
>>>Is every object or library mentioned on that line already marked as
>>>MIPS-2 by readelf?  Even crt*, libc*?
>>>
>>
>>I knew I was being stupid, crt* and libc* are mips1 *sigh*. Looks
>>like I have more work to do for my build system. Below is the verbose
>>output, but I think that's the problem for sure.
> 
> 
>  Hmm, that's strange as a single mips2 object among mips1 ones should make
> an executable/shared library be marked as mips2 and not mips1.  I wouldn't
> worry in the long run, though, as I think this should be fixed in the
> trunk as Richard Sandiford was working in these areas recently.  You might
> want to do a verification to be sure, though. 
> 
I tried the trunk and got the same thing. I have made some additional
progress. First, I used H.J.Lu's patch for the most part:

    http://sources.redhat.com/ml/binutils/2001-10/msg00526.html

Specifically the part:

-  elf_elfheader (abfd)->e_flags &= ~(EF_MIPS_ARCH | EF_MIPS_MACH);
-  elf_elfheader (abfd)->e_flags |= val;
+  if (isa != 0 && (elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) == 0)
+    {
+      elf_elfheader (abfd)->e_flags &= ~EF_MIPS_ARCH;
+      elf_elfheader (abfd)->e_flags |= isa;
+    }
+
+  if (cpu != 0)
+    {
+      elf_elfheader (abfd)->e_flags &= ~EF_MIPS_MACH;
+      elf_elfheader (abfd)->e_flags |= cpu;
+    }

So, now when I am building 'zlib', the object files get built with:

   mipsel-linux-gcc -march=r6000 -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP

and then shared object creation uses:

   mipsel-linux-gcc -shared -Wl,-A,r6000,-v,-soname,libz.so.1 \
     -march=r6000 -o libz.so.1.1.4 adler32.o compress.o crc32.o gzio.o \
     compr.o deflate.o trees.o zutil.o inflate.o infblock.o inftrees.o \
     infcodes.o infutil.o inffast.o

with the verbose output of:

collect2 version 3.2 (MIPSel GNU/Linux with ELF)
/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/bin/ld 
--eh-frame-hdr -EL -shared -o libz.so.1.1.4 
/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib/crti.o 
/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/crtbeginS.o 
-L/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2 
-L/opt/toolchains/uclibc/bin/../lib/gcc-lib 
-L/opt/toolchains/uclibc-crosstools-1.0.0/lib/gcc-lib/mipsel-linux/3.2 
-L/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib 
-L/opt/toolchains/uclibc-crosstools-1.0.0/lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib 
-L/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../.. -A 
r6000 -v -soname libz.so.1 adler32.o compress.o crc32.o gzio.o uncompr.o 
deflate.o trees.o zutil.o inflate.o infblock.o inftrees.o infcodes.o 
infutil.o inffast.o -lgcc -lc -lgcc 
/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/crtendS.o 
/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib/crtn.o

The 'crt*' files and my C runtime are compiled with 'mips1', but as
Maciej correctly states in his reply, the output binary should be
the highest ISA value when mixing differing ISA objects.

I'm convinced the linker completely ignores '-A' for MIPS. In the 
'_bfd_mips_elf_final_write_processing' function in 'bfd/elfxx-mips.c'
If I print out the EF_MIPS_ARCH flags for the input BFD descriptor. It
is properly set to 'MIPS2', but when the case statement in 
'_bfd_mips_elf_final_write_processing' is traversed, it
uses the R3000/default case which means that the target CPU architecture
didn't get put into the BFD descriptor. So, I instead changed the ISA
if statement above to be:

   if (((elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) != isa) && (isa 
!= 0))
     {
       elf_elfheader (abfd)->e_flags &= ~EF_MIPS_ARCH;
       elf_elfheader (abfd)->e_flags |= isa;
     }

which then properly sets the ISA in the ELF header. My gut feeling
though is that we shouldn't have to do this as the target CPU
architecture should have been set properly for the incoming BFD.
Comments and suggestions welcome. Thanks.

-Steve


From hjl@lucon.org Mon Nov  4 16:02:44 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Nov 2002 16:02:45 +0100 (CET)
Received: from rwcrmhc53.attbi.com ([204.127.198.39]:15559 "EHLO
	rwcrmhc53.attbi.com") by linux-mips.org with ESMTP
	id <S1122121AbSKDPCo>; Mon, 4 Nov 2002 16:02:44 +0100
Received: from lucon.org ([12.234.88.146]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021104150234.PNKH29857.rwcrmhc53.attbi.com@lucon.org>;
          Mon, 4 Nov 2002 15:02:34 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 850892C4EC; Mon,  4 Nov 2002 07:02:33 -0800 (PST)
Date: Mon, 4 Nov 2002 07:02:33 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
Message-ID: <20021104070233.C8860@lucon.org>
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DC68907.30708@realitydiluted.com>; from sjhill@realitydiluted.com on Mon, Nov 04, 2002 at 08:49:43AM -0600
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: 557
X-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

On Mon, Nov 04, 2002 at 08:49:43AM -0600, Steven J. Hill wrote:
> 
> I'm convinced the linker completely ignores '-A' for MIPS. In the 

-A is for assembler, not linker.


H.J.

From sjhill@realitydiluted.com Mon Nov  4 17:57:19 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Nov 2002 17:57:19 +0100 (CET)
Received: from real.realitydiluted.com ([208.242.241.164]:35991 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S1122121AbSKDQ5T>; Mon, 4 Nov 2002 17:57:19 +0100
Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux))
	id 188kXI-0004Wk-00; Mon, 04 Nov 2002 10:57:12 -0600
Message-ID: <3DC6A6E7.6000107@realitydiluted.com>
Date: Mon, 04 Nov 2002 10:57:11 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com> <20021104070233.C8860@lucon.org>
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: 558
X-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

H. J. Lu wrote:
> 
>>I'm convinced the linker completely ignores '-A' for MIPS. In the 
> 
> 
> -A is for assembler, not linker.
> 
Fine. Still, that doesn't solve the problem, or what I perceive to
be a problem. I'll submit my patch and watch it be ignored or for
someone to say something.

-Steve



From hjl@lucon.org Mon Nov  4 18:11:45 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Nov 2002 18:11:45 +0100 (CET)
Received: from p508B7C3B.dip.t-dialin.net ([80.139.124.59]:30387 "EHLO
	p508B7C3B.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122121AbSKDRLp>; Mon, 4 Nov 2002 18:11:45 +0100
Received: from sccrmhc01.attbi.com ([IPv6:::ffff:204.127.202.61]:33964 "EHLO
	sccrmhc01.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S867025AbSKDRLc>; Mon, 4 Nov 2002 18:11:32 +0100
Received: from lucon.org ([12.234.88.146]) by sccrmhc01.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021104171120.PVIK8743.sccrmhc01.attbi.com@lucon.org>;
          Mon, 4 Nov 2002 17:11:20 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 8D0FC2C4EC; Mon,  4 Nov 2002 09:11:19 -0800 (PST)
Date: Mon, 4 Nov 2002 09:11:19 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
Message-ID: <20021104091119.A10646@lucon.org>
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com> <20021104070233.C8860@lucon.org> <3DC6A6E7.6000107@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DC6A6E7.6000107@realitydiluted.com>; from sjhill@realitydiluted.com on Mon, Nov 04, 2002 at 10:57:11AM -0600
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: 559
X-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

On Mon, Nov 04, 2002 at 10:57:11AM -0600, Steven J. Hill wrote:
> H. J. Lu wrote:
> > 
> >>I'm convinced the linker completely ignores '-A' for MIPS. In the 
> > 
> > 
> > -A is for assembler, not linker.
> > 
> Fine. Still, that doesn't solve the problem, or what I perceive to
> be a problem. I'll submit my patch and watch it be ignored or for
> someone to say something.

The Linux binutils works fine for me.


H.J.

From sjhill@realitydiluted.com Mon Nov  4 18:16:28 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Nov 2002 18:16:28 +0100 (CET)
Received: from real.realitydiluted.com ([208.242.241.164]:45463 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S1122121AbSKDRQ2>; Mon, 4 Nov 2002 18:16:28 +0100
Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux))
	id 188kpn-0004YX-00; Mon, 04 Nov 2002 11:16:19 -0600
Message-ID: <3DC6AB62.7000603@realitydiluted.com>
Date: Mon, 04 Nov 2002 11:16:18 -0600
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
X-Accept-Language: en
MIME-Version: 1.0
To: "H. J. Lu" <hjl@lucon.org>
CC: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com> <20021104070233.C8860@lucon.org> <3DC6A6E7.6000107@realitydiluted.com> <20021104091119.A10646@lucon.org>
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: 560
X-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

H. J. Lu wrote:
>>
>>Fine. Still, that doesn't solve the problem, or what I perceive to
>>be a problem. I'll submit my patch and watch it be ignored or for
>>someone to say something.
> 
> 
> The Linux binutils works fine for me.
> 
Really? Good. Go get this tarball:

     ftp://ftp.realitydiluted.com/Linux/MIPS/zlib-1.1.4-mips-prob.tar.bz2

make sure your tools are in your path and just do 'make' and see
what ISA your 'libz.so.1.1.4' is. Thanks.

-Steve


From hjl@lucon.org Mon Nov  4 18:24:34 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Nov 2002 18:24:34 +0100 (CET)
Received: from p508B7C3B.dip.t-dialin.net ([80.139.124.59]:40883 "EHLO
	p508B7C3B.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122121AbSKDRYe>; Mon, 4 Nov 2002 18:24:34 +0100
Received: from rwcrmhc51.attbi.com ([IPv6:::ffff:204.127.198.38]:42675 "EHLO
	rwcrmhc51.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S867025AbSKDRYT>; Mon, 4 Nov 2002 18:24:19 +0100
Received: from lucon.org ([12.234.88.146]) by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021104172413.UVSK14374.rwcrmhc51.attbi.com@lucon.org>;
          Mon, 4 Nov 2002 17:24:13 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 24EEB2C4EC; Mon,  4 Nov 2002 09:24:13 -0800 (PST)
Date: Mon, 4 Nov 2002 09:24:13 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
Message-ID: <20021104092413.C10646@lucon.org>
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com> <20021104070233.C8860@lucon.org> <3DC6A6E7.6000107@realitydiluted.com> <20021104091119.A10646@lucon.org> <3DC6AB62.7000603@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DC6AB62.7000603@realitydiluted.com>; from sjhill@realitydiluted.com on Mon, Nov 04, 2002 at 11:16:18AM -0600
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: 561
X-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

On Mon, Nov 04, 2002 at 11:16:18AM -0600, Steven J. Hill wrote:
> H. J. Lu wrote:
> >>
> >>Fine. Still, that doesn't solve the problem, or what I perceive to
> >>be a problem. I'll submit my patch and watch it be ignored or for
> >>someone to say something.
> > 
> > 
> > The Linux binutils works fine for me.
> > 
> Really? Good. Go get this tarball:
> 
>      ftp://ftp.realitydiluted.com/Linux/MIPS/zlib-1.1.4-mips-prob.tar.bz2
> 
> make sure your tools are in your path and just do 'make' and see
> what ISA your 'libz.so.1.1.4' is. Thanks.
> 

# readelf -h libz.so.1.1.4
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x14d0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          66196 (bytes into file)
  Flags:                             0x10000003, noreorder, pic, mips2
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         25
  Section header string table index: 22

H.J.

From kernel@firstlinux.net Mon Nov  4 23:20:52 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Nov 2002 23:20:53 +0100 (CET)
Received: from sitemail3.everyone.net ([216.200.145.37]:39954 "HELO
	omta05.mta.everyone.net") by linux-mips.org with SMTP
	id <S1122121AbSKDWUw>; Mon, 4 Nov 2002 23:20:52 +0100
Received: from sitemail.everyone.net (dsnat [216.200.145.62])
	by omta05.mta.everyone.net (Postfix) with ESMTP id 23E99FFD65
	for <linux-mips@linux-mips.org>; Mon,  4 Nov 2002 14:20:26 -0800 (PST)
Received: by sitemail.everyone.net (Postfix, from userid 99)
	id AF0A1431F; Mon,  4 Nov 2002 14:20:25 -0800 (PST)
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Date: Mon, 4 Nov 2002 14:20:25 -0800 (PST)
From: John Morrison <kernel@firstlinux.net>
To: linux-mips@linux-mips.org
Subject: subcribe linux-mips
Reply-To: kernel@firstlinux.net
X-Originating-Ip: [213.101.62.84]
Message-Id: <20021104222025.AF0A1431F@sitemail.everyone.net>
Return-Path: <kernel@firstlinux.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: 562
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kernel@firstlinux.net
Precedence: bulk
X-list: linux-mips

subcribe linux-mips

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag

From carsten.lange@detewe.de Tue Nov  5 12:02:31 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 12:02:32 +0100 (CET)
Received: from dtwse201.detewe.de ([195.50.171.201]:33034 "EHLO
	dtwse201.detewe.de") by linux-mips.org with ESMTP
	id <S1122118AbSKELCb>; Tue, 5 Nov 2002 12:02:31 +0100
Received: from zinse043.detewe.de (unverified) by dtwse201.detewe.de
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e607cd783c332abc90d2@dtwse201.detewe.de> for <linux-mips@linux-mips.org>;
 Tue, 5 Nov 2002 12:02:00 +0100
Received: from detewe.de ([172.30.201.153]) by zinse043.detewe.de
          (Netscape Messaging Server 3.6)  with ESMTP id AAAFAC;
          Tue, 5 Nov 2002 12:01:25 +0100
Message-ID: <3DC7A535.A69B5DD1@detewe.de>
Date: Tue, 05 Nov 2002 12:02:13 +0100
From: Carsten Lange <Carsten.Lange@detewe.de>
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: backtrace() (glibc 2.2.5) not working
Content-Type: multipart/mixed; boundary="------------D56F559F00DA2794811188A3"
Return-Path: <carsten.lange@detewe.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: 563
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Carsten.Lange@detewe.de
Precedence: bulk
X-list: linux-mips

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

Hi,

I want to use backtrace() in my embedded application to get some idea where problems exist, but
backtrace() is not working (always returns 0).
I thing it is not implemented for mips.

Any ideas how to get it working?


Many thanks for any hints.

Carsten
--------------D56F559F00DA2794811188A3
Content-Type: text/x-vcard; charset=us-ascii;
 name="Carsten.Lange.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Carsten Lange
Content-Disposition: attachment;
 filename="Carsten.Lange.vcf"

begin:vcard 
n:Lange;Carsten
tel;fax:+49 30 6104 4234
tel;work:+49 30 6104 4228
x-mozilla-html:FALSE
url:http://www.detewe.de
org:Cordless Technology A/S Berlin
adr:;;Koepenicker Str. 180;10997 Berlin;;;Germany
version:2.1
email;internet:Carsten.Lange@detewe.de
x-mozilla-cpt:;2592
fn:Carsten Lange
end:vcard

--------------D56F559F00DA2794811188A3--


From info@render-dynamics.com Tue Nov  5 13:47:27 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 13:47:28 +0100 (CET)
Received: from colossus.systems.pipex.net ([62.241.160.73]:42944 "EHLO
	colossus.systems.pipex.net") by linux-mips.org with ESMTP
	id <S1122121AbSKEMr1> convert rfc822-to-8bit; Tue, 5 Nov 2002 13:47:27 +0100
Received: from 213.116.58.105 (1Cust105.tnt105.lnd4.uk.uudial.net [213.116.58.105])
	by colossus.systems.pipex.net (Postfix) with SMTP id 97AAA160006CB
	for <linux-mips@linux-mips.org>; Tue,  5 Nov 2002 12:47:18 +0000 (GMT)
Date: Tue, 5 Nov 2002 12:44 0000
From: info@render-dynamics.com
Subject: 
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Message-Id: <20021105124718.97AAA160006CB@colossus.systems.pipex.net>
Return-Path: <info@render-dynamics.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: 564
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: info@render-dynamics.com
Precedence: bulk
X-list: linux-mips

unsubcribe linux-mips


From carstenl@mips.com Tue Nov  5 14:46:00 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 14:46:01 +0100 (CET)
Received: from mx2.mips.com ([206.31.31.227]:30440 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1122121AbSKENqA>;
	Tue, 5 Nov 2002 14:46:00 +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 gA5DjnNf003924;
	Tue, 5 Nov 2002 05:45:49 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id FAA06195;
	Tue, 5 Nov 2002 05:46:54 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id gA5Djlb25621;
	Tue, 5 Nov 2002 14:45:48 +0100 (MET)
Message-ID: <3DC7CB8B.E2C1D4E5@mips.com>
Date: Tue, 05 Nov 2002 14:45:47 +0100
From: Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Prefetches in memcpy
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Return-Path: <carstenl@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: 565
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: carstenl@mips.com
Precedence: bulk
X-list: linux-mips

I have reported this before and it also gave a lot of responses, but
nothing has been done about, unfortunately :-(

The problem is the prefetches in the memcpy function in the kernel.
There is spread a number of PREF instructions in the memcpy function,
but there is no check if we are prefetching out-side the areas we are
copying to/from. This is extremely dangerous because we might prefetch
out-side the physical memory area, causing e.g. a bus error or something
even more nasty.

I recently found something even nastier, it could also hit a DMA buffer
region, and thereby break the PCI DMA flushing scheme.
For example if the kernel is doing a memcpy from an area that's next to
a DMA buffer area, we could end up in a situation where, we are
prefetching
data into the cache from a memory location that is used for DMA transfer
and owned by the device, but the DMA transfer has not yet completed.
We then end up in a situation, where the memory and cache is out of sync
and the cache is containing some old data.

So we definitely need to do something about the prefetches in the memcpy
function.
We can either get rid of all the prefetches or make sure we don't
prefetch out side the "memcpy" area.

/Carsten



--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com




From rsandifo@redhat.com Tue Nov  5 16:19:19 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 16:19:20 +0100 (CET)
Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:35319 "EHLO
	executor.cambridge.redhat.com") by linux-mips.org with ESMTP
	id <S1122121AbSKEPTS>; Tue, 5 Nov 2002 16:19:18 +0100
Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81])
	by executor.cambridge.redhat.com (Postfix) with ESMTP
	id CBD84ABAF8; Tue,  5 Nov 2002 15:19:11 +0000 (GMT)
Received: (from rsandifo@localhost)
	by talisman.cambridge.redhat.com (8.11.6/8.11.0) id gA5FJ5V27022;
	Tue, 5 Nov 2002 15:19:05 GMT
X-Authentication-Warning: talisman.cambridge.redhat.com: rsandifo set sender to rsandifo@redhat.com using -f
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl>
	<3DC68907.30708@realitydiluted.com>
From: Richard Sandiford <rsandifo@redhat.com>
Date: 05 Nov 2002 15:19:04 +0000
In-Reply-To: <3DC68907.30708@realitydiluted.com>
Message-ID: <wvnvg3ct57b.fsf@talisman.cambridge.redhat.com>
Lines: 44
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@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: 566
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

"Steven J. Hill" <sjhill@realitydiluted.com> writes:
> In the '_bfd_mips_elf_final_write_processing' function in 'bfd/elfxx-mips.c'
> If I print out the EF_MIPS_ARCH flags for the input BFD descriptor. It
> is properly set to 'MIPS2', but when the case statement in
> '_bfd_mips_elf_final_write_processing' is traversed, it
> uses the R3000/default case which means that the target CPU architecture
> didn't get put into the BFD descriptor.

Is it related to this?

    <http://sources.redhat.com/ml/binutils/2002-10/msg00248.html>

(In the message body, I accidentally copied the code after
the patch rather than before.  Sorry about that.)

Anyway, that patch won't solve your problem, but the issue
seems to be the same: _bfd_mips_elf_merge_private_bfd_data()
merges the EF_MIPS_ARCH and EF_MIPS_MACH bits, but
_bfd_mips_elf_final_write_processing() overwrites them
based on the BFD mach.

Personally, I think _bfd_mips_elf_final_write_processing()
is doing the right thing.  Surely we ought to be able to
set EF_MIPS_ARCH and EF_MIPS_MACH based on the value of
bfd_get_mach?

I wonder whether _bfd_mips_elf_merge_private_bfd_data() should
be checking for compatibility based on the BFD machs rather
than the header flags.  It seems a bit odd that we check the
ISA level and "machine" separately.

In other words, replace:

  /* Compare the ISA's.  */
  if ((new_flags & (EF_MIPS_ARCH | EF_MIPS_MACH))
      != (old_flags & (EF_MIPS_ARCH | EF_MIPS_MACH)))
    {
      ...
    }

with code that checks bfd_get_mach (ibfd) against bfd_get_mach (obfd).
If ibfd's architecture is an extension of obfd's, copy it to obfd.

Richard

From ralf@uni-koblenz.de Tue Nov  5 16:38:26 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 16:38:27 +0100 (CET)
Received: from p508B66C1.dip.t-dialin.net ([80.139.102.193]:441 "EHLO
	p508B66C1.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122121AbSKEPi0>; Tue, 5 Nov 2002 16:38:26 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S867025AbSKEPiJ>; Tue, 5 Nov 2002 16:38:09 +0100
Date: Tue, 5 Nov 2002 16:38:07 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Carsten Langgaard <carstenl@mips.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Prefetches in memcpy
Message-ID: <20021105163806.A24996@bacchus.dhis.org>
References: <3DC7CB8B.E2C1D4E5@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DC7CB8B.E2C1D4E5@mips.com>; from carstenl@mips.com on Tue, Nov 05, 2002 at 02:45:47PM +0100
X-Accept-Language: de,en,fr
Return-Path: <ralf@uni-koblenz.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: 567
X-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@uni-koblenz.de
Precedence: bulk
X-list: linux-mips

On Tue, Nov 05, 2002 at 02:45:47PM +0100, Carsten Langgaard wrote:

> The problem is the prefetches in the memcpy function in the kernel.
> There is spread a number of PREF instructions in the memcpy function,
> but there is no check if we are prefetching out-side the areas we are
> copying to/from. This is extremely dangerous because we might prefetch
> out-side the physical memory area, causing e.g. a bus error or something
> even more nasty.
> 
> I recently found something even nastier, it could also hit a DMA buffer
> region, and thereby break the PCI DMA flushing scheme.
> For example if the kernel is doing a memcpy from an area that's next to
> a DMA buffer area, we could end up in a situation where, we are
> prefetching
> data into the cache from a memory location that is used for DMA transfer
> and owned by the device, but the DMA transfer has not yet completed.
> We then end up in a situation, where the memory and cache is out of sync
> and the cache is containing some old data.
> 
> So we definitely need to do something about the prefetches in the memcpy
> function.  We can either get rid of all the prefetches or make sure we
> don't prefetch out side the "memcpy" area.

We could fix the prefetch into DMA buffer problem with an extra flush but
that's going to be expensive, I rather think we should avoid prefetches.
As Kevin explained KSEG1 is a loophole in the spec so we can't really say
what the behaviour of memcpy will be in KSEG1.

So I think the fix will have to be:

 - Avoid prefetching beyond the end of the copy area in memcpy and memmove.
 - Introduce a second variant of memcpy that never does prefetching.  This
   one will be safe to use in KSEG1 / uncached XKPHYS also and will be used
   for memcpy_fromio, memcpy_toio and friends.

  Ralf

From kevink@mips.com Tue Nov  5 17:10:44 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 17:10:44 +0100 (CET)
Received: from ftp.mips.com ([206.31.31.227]:28139 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1122121AbSKEQKo>;
	Tue, 5 Nov 2002 17: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 gA5GAYNf004447;
	Tue, 5 Nov 2002 08:10:35 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id IAA12636;
	Tue, 5 Nov 2002 08:11:39 -0800 (PST)
Message-ID: <00fb01c284e6$5b7bf4f0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@uni-koblenz.de>,
	"Carsten Langgaard" <carstenl@mips.com>
Cc: <linux-mips@linux-mips.org>
References: <3DC7CB8B.E2C1D4E5@mips.com> <20021105163806.A24996@bacchus.dhis.org>
Subject: Re: Prefetches in memcpy
Date: Tue, 5 Nov 2002 17:13:48 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.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: 568
X-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

From: "Ralf Baechle" <ralf@uni-koblenz.de>
> So I think the fix will have to be:
> 
>  - Avoid prefetching beyond the end of the copy area in memcpy and memmove.
>  - Introduce a second variant of memcpy that never does prefetching.  This
>    one will be safe to use in KSEG1 / uncached XKPHYS also and will be used
>    for memcpy_fromio, memcpy_toio and friends.

Assuming we had a version that prefetched exactly to the end
of the source memory block and no further, why would we need
the second variant?

            Kevin K.

From ralf@uni-koblenz.de Tue Nov  5 17:29:45 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 17:29:45 +0100 (CET)
Received: from p508B66C1.dip.t-dialin.net ([80.139.102.193]:12473 "EHLO
	p508B66C1.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122121AbSKEQ3p>; Tue, 5 Nov 2002 17:29:45 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S867025AbSKEQ3f>; Tue, 5 Nov 2002 17:29:35 +0100
Date: Tue, 5 Nov 2002 17:29:35 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Carsten Langgaard <carstenl@mips.com>, linux-mips@linux-mips.org
Subject: Re: Prefetches in memcpy
Message-ID: <20021105172935.A14721@bacchus.dhis.org>
References: <3DC7CB8B.E2C1D4E5@mips.com> <20021105163806.A24996@bacchus.dhis.org> <00fb01c284e6$5b7bf4f0$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <00fb01c284e6$5b7bf4f0$10eca8c0@grendel>; from kevink@mips.com on Tue, Nov 05, 2002 at 05:13:48PM +0100
X-Accept-Language: de,en,fr
Return-Path: <ralf@uni-koblenz.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: 569
X-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@uni-koblenz.de
Precedence: bulk
X-list: linux-mips

On Tue, Nov 05, 2002 at 05:13:48PM +0100, Kevin D. Kissell wrote:

> >  - Avoid prefetching beyond the end of the copy area in memcpy and memmove.
> >  - Introduce a second variant of memcpy that never does prefetching.  This
> >    one will be safe to use in KSEG1 / uncached XKPHYS also and will be used
> >    for memcpy_fromio, memcpy_toio and friends.
> 
> Assuming we had a version that prefetched exactly to the end
> of the source memory block and no further, why would we need
> the second variant?

Because the source of memcpy_fromio and the destination of memcpy_toio are
some I/O address, typically something like a shared memory region on a
network card, which is accessed uncached.  The uncached address region
might be mapped in KSEG2/KSEG3 or accessed through an uncached region of
XKPHYS or KSEG1 where as I recall your statment the effect of prefetch
instructions is undefined.

  Ralf

From ralf@linux-mips.org Tue Nov  5 17:41:12 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 17:41:12 +0100 (CET)
Received: from p508B66C1.dip.t-dialin.net ([80.139.102.193]:15033 "EHLO
	p508B66C1.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122121AbSKEQlM>; Tue, 5 Nov 2002 17:41:12 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S867025AbSKEQlC>; Tue, 5 Nov 2002 17:41:02 +0100
Date: Tue, 5 Nov 2002 17:41:02 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Carsten Langgaard <carstenl@mips.com>, linux-mips@linux-mips.org
Subject: Re: Prefetches in memcpy
Message-ID: <20021105174102.A14909@bacchus.dhis.org>
References: <3DC7CB8B.E2C1D4E5@mips.com> <20021105163806.A24996@bacchus.dhis.org> <00fb01c284e6$5b7bf4f0$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <00fb01c284e6$5b7bf4f0$10eca8c0@grendel>; from kevink@mips.com on Tue, Nov 05, 2002 at 05:13:48PM +0100
X-Accept-Language: de,en,fr
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: 570
X-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, Nov 05, 2002 at 05:13:48PM +0100, Kevin D. Kissell wrote:

> >  - Avoid prefetching beyond the end of the copy area in memcpy and memmove.
> >  - Introduce a second variant of memcpy that never does prefetching.  This
> >    one will be safe to use in KSEG1 / uncached XKPHYS also and will be used
> >    for memcpy_fromio, memcpy_toio and friends.
> 
> Assuming we had a version that prefetched exactly to the end
> of the source memory block and no further, why would we need
> the second variant?

Uh...  Maybe missread your mail the first time.  We're also prefechting
the destination area, of course with a different hint.  The question is
what the hints for destination are actually doing, the specs are fairly
vague on that and seem to leave the decission to the implementor.  Do
we really want to try ...

  Ralf

From alan@lxorguk.ukuu.org.uk Tue Nov  5 18:04:17 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 18:04:18 +0100 (CET)
Received: from pc1-cwma1-5-cust42.swa.cable.ntl.com ([80.5.120.42]:28053 "EHLO
	irongate.swansea.linux.org.uk") by linux-mips.org with ESMTP
	id <S1122121AbSKERER>; Tue, 5 Nov 2002 18:04:17 +0100
Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1])
	by irongate.swansea.linux.org.uk (8.12.5/8.12.5) with ESMTP id gA5HQDbc006315;
	Tue, 5 Nov 2002 17:26:14 GMT
Received: (from alan@localhost)
	by irongate.swansea.linux.org.uk (8.12.5/8.12.5/Submit) id gA5HQBB2006313;
	Tue, 5 Nov 2002 17:26:11 GMT
X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Prefetches in memcpy
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Ralf Baechle <ralf@uni-koblenz.de>,
	Carsten Langgaard <carstenl@mips.com>,
	linux-mips@linux-mips.org
In-Reply-To: <00fb01c284e6$5b7bf4f0$10eca8c0@grendel>
References: <3DC7CB8B.E2C1D4E5@mips.com>
	<20021105163806.A24996@bacchus.dhis.org> 
	<00fb01c284e6$5b7bf4f0$10eca8c0@grendel>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 05 Nov 2002 17:26:11 +0000
Message-Id: <1036517171.5012.100.camel@irongate.swansea.linux.org.uk>
Mime-Version: 1.0
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 571
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Tue, 2002-11-05 at 16:13, Kevin D. Kissell wrote:
> Assuming we had a version that prefetched exactly to the end
> of the source memory block and no further, why would we need
> the second variant?

memcpy_to/from_io needs to do strictly ordered fetches on some devices
which fake a memory range with a fifo for performance (pci bursting
dirty tricks)


From hjl@lucon.org Tue Nov  5 18:15:33 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 18:15:34 +0100 (CET)
Received: from p508B66C1.dip.t-dialin.net ([80.139.102.193]:22969 "EHLO
	p508B66C1.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122121AbSKERPd>; Tue, 5 Nov 2002 18:15:33 +0100
Received: from sccrmhc02.attbi.com ([IPv6:::ffff:204.127.202.62]:52866 "EHLO
	sccrmhc02.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S867025AbSKERPY>; Tue, 5 Nov 2002 18:15:24 +0100
Received: from lucon.org ([12.234.88.146]) by sccrmhc02.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021105171502.OXMZ5946.sccrmhc02.attbi.com@lucon.org>;
          Tue, 5 Nov 2002 17:15:02 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id DECA22C57C; Tue,  5 Nov 2002 09:15:00 -0800 (PST)
Date: Tue, 5 Nov 2002 09:15:00 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
Message-ID: <20021105091500.A2743@lucon.org>
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com> <wvnvg3ct57b.fsf@talisman.cambridge.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <wvnvg3ct57b.fsf@talisman.cambridge.redhat.com>; from rsandifo@redhat.com on Tue, Nov 05, 2002 at 03:19:04PM +0000
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: 572
X-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

On Tue, Nov 05, 2002 at 03:19:04PM +0000, Richard Sandiford wrote:
> "Steven J. Hill" <sjhill@realitydiluted.com> writes:
> > In the '_bfd_mips_elf_final_write_processing' function in 'bfd/elfxx-mips.c'
> > If I print out the EF_MIPS_ARCH flags for the input BFD descriptor. It
> > is properly set to 'MIPS2', but when the case statement in
> > '_bfd_mips_elf_final_write_processing' is traversed, it
> > uses the R3000/default case which means that the target CPU architecture
> > didn't get put into the BFD descriptor.
> 
> Is it related to this?
> 
>     <http://sources.redhat.com/ml/binutils/2002-10/msg00248.html>
> 
> (In the message body, I accidentally copied the code after
> the patch rather than before.  Sorry about that.)
> 
> Anyway, that patch won't solve your problem, but the issue
> seems to be the same: _bfd_mips_elf_merge_private_bfd_data()
> merges the EF_MIPS_ARCH and EF_MIPS_MACH bits, but
> _bfd_mips_elf_final_write_processing() overwrites them
> based on the BFD mach.
> 
> Personally, I think _bfd_mips_elf_final_write_processing()
> is doing the right thing.  Surely we ought to be able to
> set EF_MIPS_ARCH and EF_MIPS_MACH based on the value of
> bfd_get_mach?
> 
> I wonder whether _bfd_mips_elf_merge_private_bfd_data() should
> be checking for compatibility based on the BFD machs rather
> than the header flags.  It seems a bit odd that we check the
> ISA level and "machine" separately.
> 
> In other words, replace:
> 
>   /* Compare the ISA's.  */
>   if ((new_flags & (EF_MIPS_ARCH | EF_MIPS_MACH))
>       != (old_flags & (EF_MIPS_ARCH | EF_MIPS_MACH)))
>     {
>       ...
>     }
> 
> with code that checks bfd_get_mach (ibfd) against bfd_get_mach (obfd).
> If ibfd's architecture is an extension of obfd's, copy it to obfd.

The FSF binutils has never been right. I have fixed it in my Linux
binutils. See my followups on this thread.


H.J.

From drow@false.org Tue Nov  5 18:26:10 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 18:26:11 +0100 (CET)
Received: from crack.them.org ([65.125.64.184]:34319 "EHLO crack.them.org")
	by linux-mips.org with ESMTP id <S1122121AbSKER0K>;
	Tue, 5 Nov 2002 18:26:10 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 1898No-0007MI-00; Tue, 05 Nov 2002 12:25:00 -0600
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 1897T9-0001Qr-00; Tue, 05 Nov 2002 12:26:27 -0500
Date: Tue, 5 Nov 2002 12:26:27 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
Message-ID: <20021105172627.GA5275@nevyn.them.org>
Mail-Followup-To: Richard Sandiford <rsandifo@redhat.com>,
	"Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com> <wvnvg3ct57b.fsf@talisman.cambridge.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <wvnvg3ct57b.fsf@talisman.cambridge.redhat.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: 573
X-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, Nov 05, 2002 at 03:19:04PM +0000, Richard Sandiford wrote:
> "Steven J. Hill" <sjhill@realitydiluted.com> writes:
> > In the '_bfd_mips_elf_final_write_processing' function in 'bfd/elfxx-mips.c'
> > If I print out the EF_MIPS_ARCH flags for the input BFD descriptor. It
> > is properly set to 'MIPS2', but when the case statement in
> > '_bfd_mips_elf_final_write_processing' is traversed, it
> > uses the R3000/default case which means that the target CPU architecture
> > didn't get put into the BFD descriptor.
> 
> Is it related to this?
> 
>     <http://sources.redhat.com/ml/binutils/2002-10/msg00248.html>
> 
> (In the message body, I accidentally copied the code after
> the patch rather than before.  Sorry about that.)
> 
> Anyway, that patch won't solve your problem, but the issue
> seems to be the same: _bfd_mips_elf_merge_private_bfd_data()
> merges the EF_MIPS_ARCH and EF_MIPS_MACH bits, but
> _bfd_mips_elf_final_write_processing() overwrites them
> based on the BFD mach.
> 
> Personally, I think _bfd_mips_elf_final_write_processing()
> is doing the right thing.  Surely we ought to be able to
> set EF_MIPS_ARCH and EF_MIPS_MACH based on the value of
> bfd_get_mach?

Surely we can't...  Remember what EF_MIPS_ARCH says: it's actually what
we call ISA level elsewhere!  I just spent a day beating on this and
settled for untagged instead of correctly-tagged binaries; I was trying
to built SB-1 binaries (that's EF_MIPS_MACH of EF_MIPS_MACH_SB1) for a
32-bit userland (that's EF_MIPS_ARCH_2).  Not just E_MIPS_ABI_O32, but
actually -mips2 code.

We can't infer that from the result of bfd_get_mach, I don't think! 
You're moving in the wrong direction.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From hjl@lucon.org Tue Nov  5 18:34:06 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 18:34:07 +0100 (CET)
Received: from p508B66C1.dip.t-dialin.net ([80.139.102.193]:24505 "EHLO
	p508B66C1.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122121AbSKEReG>; Tue, 5 Nov 2002 18:34:06 +0100
Received: from sccrmhc01.attbi.com ([IPv6:::ffff:204.127.202.61]:41443 "EHLO
	sccrmhc01.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S867025AbSKEReA>; Tue, 5 Nov 2002 18:34:00 +0100
Received: from lucon.org ([12.234.88.146]) by sccrmhc01.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021105173333.AKB12959.sccrmhc01.attbi.com@lucon.org>;
          Tue, 5 Nov 2002 17:33:33 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 3E04B2C57C; Tue,  5 Nov 2002 09:33:33 -0800 (PST)
Date: Tue, 5 Nov 2002 09:33:33 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: Richard Sandiford <rsandifo@redhat.com>,
	"Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
Message-ID: <20021105093333.A3061@lucon.org>
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com> <wvnvg3ct57b.fsf@talisman.cambridge.redhat.com> <20021105172627.GA5275@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021105172627.GA5275@nevyn.them.org>; from dan@debian.org on Tue, Nov 05, 2002 at 12:26:27PM -0500
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: 574
X-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

On Tue, Nov 05, 2002 at 12:26:27PM -0500, Daniel Jacobowitz wrote:
> 
> Surely we can't...  Remember what EF_MIPS_ARCH says: it's actually what
> we call ISA level elsewhere!  I just spent a day beating on this and
> settled for untagged instead of correctly-tagged binaries; I was trying
> to built SB-1 binaries (that's EF_MIPS_MACH of EF_MIPS_MACH_SB1) for a
> 32-bit userland (that's EF_MIPS_ARCH_2).  Not just E_MIPS_ABI_O32, but
> actually -mips2 code.
> 

Have you tried my Linux binutils? If you follow the release note, it
may just work.


H.J.

From rsandifo@redhat.com Tue Nov  5 19:18:04 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 19:18:04 +0100 (CET)
Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:39421 "EHLO
	executor.cambridge.redhat.com") by linux-mips.org with ESMTP
	id <S1122121AbSKESSE>; Tue, 5 Nov 2002 19:18:04 +0100
Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81])
	by executor.cambridge.redhat.com (Postfix) with ESMTP
	id F1E05ABAF8; Tue,  5 Nov 2002 18:17:57 +0000 (GMT)
Received: (from rsandifo@localhost)
	by talisman.cambridge.redhat.com (8.11.6/8.11.0) id gA5IHtb11344;
	Tue, 5 Nov 2002 18:17:55 GMT
X-Authentication-Warning: talisman.cambridge.redhat.com: rsandifo set sender to rsandifo@redhat.com using -f
To: Daniel Jacobowitz <dan@debian.org>
Cc: "Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl>
	<3DC68907.30708@realitydiluted.com>
	<wvnvg3ct57b.fsf@talisman.cambridge.redhat.com>
	<20021105172627.GA5275@nevyn.them.org>
From: Richard Sandiford <rsandifo@redhat.com>
Date: 05 Nov 2002 18:17:55 +0000
In-Reply-To: <20021105172627.GA5275@nevyn.them.org>
Message-ID: <wvnpttjdgoc.fsf@talisman.cambridge.redhat.com>
Lines: 15
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@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: 575
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

Daniel Jacobowitz <dan@debian.org> writes:
> Surely we can't...  Remember what EF_MIPS_ARCH says: it's actually what
> we call ISA level elsewhere!  I just spent a day beating on this and
> settled for untagged instead of correctly-tagged binaries; I was trying
> to built SB-1 binaries (that's EF_MIPS_MACH of EF_MIPS_MACH_SB1) for a
> 32-bit userland (that's EF_MIPS_ARCH_2).  Not just E_MIPS_ABI_O32, but
> actually -mips2 code.

I'm not sure what you want from a MIPS II SB-1 binary, though.
Does it mean that you can't use instructions that are defined
in the MIPS32 ISA but not the MIPS II one?  But you can use
the SB-1-specific instructions (i.e. those not defined in the
MIPS64 ISA)?

Richard

From drow@false.org Tue Nov  5 19:31:34 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 19:31:35 +0100 (CET)
Received: from crack.them.org ([65.125.64.184]:54543 "EHLO crack.them.org")
	by linux-mips.org with ESMTP id <S1122121AbSKESbe>;
	Tue, 5 Nov 2002 19:31:34 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 1899PX-0007Sr-00; Tue, 05 Nov 2002 13:30:51 -0600
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 1898Uu-0002J1-00; Tue, 05 Nov 2002 13:32:20 -0500
Date: Tue, 5 Nov 2002 13:32:20 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: "Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
Message-ID: <20021105183220.GA8656@nevyn.them.org>
Mail-Followup-To: Richard Sandiford <rsandifo@redhat.com>,
	"Steven J. Hill" <sjhill@realitydiluted.com>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl> <3DC68907.30708@realitydiluted.com> <wvnvg3ct57b.fsf@talisman.cambridge.redhat.com> <20021105172627.GA5275@nevyn.them.org> <wvnpttjdgoc.fsf@talisman.cambridge.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <wvnpttjdgoc.fsf@talisman.cambridge.redhat.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: 576
X-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, Nov 05, 2002 at 06:17:55PM +0000, Richard Sandiford wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
> > Surely we can't...  Remember what EF_MIPS_ARCH says: it's actually what
> > we call ISA level elsewhere!  I just spent a day beating on this and
> > settled for untagged instead of correctly-tagged binaries; I was trying
> > to built SB-1 binaries (that's EF_MIPS_MACH of EF_MIPS_MACH_SB1) for a
> > 32-bit userland (that's EF_MIPS_ARCH_2).  Not just E_MIPS_ABI_O32, but
> > actually -mips2 code.
> 
> I'm not sure what you want from a MIPS II SB-1 binary, though.
> Does it mean that you can't use instructions that are defined
> in the MIPS32 ISA but not the MIPS II one?  But you can use
> the SB-1-specific instructions (i.e. those not defined in the
> MIPS64 ISA)?

Maybe I'm barking up the wrong tree... yes, it seems that I am....

The principal thing is that I want O32 code.  You can't use a higher
ISA level than MIPS2 and still use O32, as far as I understand. And
this setup has a 32-bit kernel, so using MIPS3/4/64 instructions in
userspace is a real losing proposition.

I obviously want -mtune=sb1.  So probably I should just be using
-mtune=sb1 -mips2.  And hack the GENERATE_BRANCHLIKELY test to honor
-mtune.  Blech, I wish these options were less confusing!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From echristo@redhat.com Tue Nov  5 20:21:58 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Nov 2002 20:21:59 +0100 (CET)
Received: from mx2.redhat.com ([12.150.115.133]:13583 "EHLO mx2.redhat.com")
	by linux-mips.org with ESMTP id <S1122121AbSKETV6>;
	Tue, 5 Nov 2002 20:21:58 +0100
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id gA5JKGP12450;
	Tue, 5 Nov 2002 14:20:16 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA5JLjl20109;
	Tue, 5 Nov 2002 14:21:45 -0500
Received: from dhcp-172-16-25-153.sfbay.redhat.com (dhcp-172-16-25-153.sfbay.redhat.com [172.16.25.153])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gA5JLiD09981;
	Tue, 5 Nov 2002 11:21:44 -0800
Subject: Re: Problems generating shared library for MIPS using
	binutils-2.13...
From: Eric Christopher <echristo@redhat.com>
To: Daniel Jacobowitz <dan@debian.org>
Cc: binutils@sources.redhat.com, linux-mips@linux-mips.org
In-Reply-To: <20021105183220.GA8656@nevyn.them.org>
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl>
	<3DC68907.30708@realitydiluted.com>
	<wvnvg3ct57b.fsf@talisman.cambridge.redhat.com>
	<20021105172627.GA5275@nevyn.them.org>
	<wvnpttjdgoc.fsf@talisman.cambridge.redhat.com> 
	<20021105183220.GA8656@nevyn.them.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 05 Nov 2002 11:21:37 -0800
Message-Id: <1036524097.1509.169.camel@ghostwheel>
Mime-Version: 1.0
Return-Path: <echristo@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 577
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: echristo@redhat.com
Precedence: bulk
X-list: linux-mips


> The principal thing is that I want O32 code.  You can't use a higher
> ISA level than MIPS2 and still use O32, as far as I understand. And
> this setup has a 32-bit kernel, so using MIPS3/4/64 instructions in
> userspace is a real losing proposition.
> 

You should be able to do -mips32 -mabi=32, however, I wouldn't bet on
this working atm :)

> I obviously want -mtune=sb1.  So probably I should just be using
> -mtune=sb1 -mips2.  And hack the GENERATE_BRANCHLIKELY test to honor
> -mtune.  Blech, I wish these options were less confusing!
> 

:) Good idea on the GENERATE_BRANCHLIKELY. I think it probably should be
dependent on mtune anyhow.

-eric

-- 
Yeah, I used to play basketball...


From roland@redhat.com Wed Nov  6 03:53:33 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 03:53:33 +0100 (CET)
Received: from adsl-64-163-212-31.dsl.snfc21.pacbell.net ([64.163.212.31]:27133
	"EHLO gateway.sf.frob.com") by linux-mips.org with ESMTP
	id <S1123984AbSKFCxd>; Wed, 6 Nov 2002 03:53:33 +0100
Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228])
	by gateway.sf.frob.com (Postfix) with ESMTP
	id 83076357E; Tue,  5 Nov 2002 18:53:19 -0800 (PST)
Received: (from roland@localhost)
	by magilla.sf.frob.com (8.11.6/8.11.6) id gA62rH817728;
	Tue, 5 Nov 2002 18:53:17 -0800
Date: Tue, 5 Nov 2002 18:53:17 -0800
Message-Id: <200211060253.gA62rH817728@magilla.sf.frob.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: Daniel Jacobowitz <dan@debian.org>
Cc: "H. J. Lu" <hjl@lucon.org>,
	GNU C Library <libc-alpha@sources.redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: PATCH: Fix errlist for mips
In-Reply-To: Daniel Jacobowitz's message of  Saturday, 26 October 2002 14:14:31 -0400 <20021026181431.GA11105@nevyn.them.org>
X-Zippy-Says: I hope something GOOD came in the mail today so I have a REASON to live!!
Return-Path: <roland@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: 578
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: roland@redhat.com
Precedence: bulk
X-list: linux-mips

> Here's what my MIPS glibc has:
> 0019df30 g    DO .data  000001ec (GLIBC_2.0)  sys_errlist
> 0019df30 g    DO .data  000011b8  GLIBC_2.2   sys_errlist
> 0019df30 g    DO .data  000001ec (GLIBC_2.0)  _sys_errlist
> 0019df30 g    DO .data  000011b8  GLIBC_2.2   _sys_errlist

Ok, that says sys_nerr=123 in 2.0 and sys_nerr=1134 in 2.2.
I have changed the map to have just those.


Thanks,
Roland

From hjl@lucon.org Wed Nov  6 04:24:02 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 04:24:03 +0100 (CET)
Received: from p508B726C.dip.t-dialin.net ([80.139.114.108]:20155 "EHLO
	p508B726C.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1123984AbSKFDYC>; Wed, 6 Nov 2002 04:24:02 +0100
Received: from sccrmhc03.attbi.com ([IPv6:::ffff:204.127.202.63]:40117 "EHLO
	sccrmhc03.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S867057AbSKFDXt>; Wed, 6 Nov 2002 04:23:49 +0100
Received: from lucon.org ([12.234.88.146]) by sccrmhc03.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021106032331.RFIH24285.sccrmhc03.attbi.com@lucon.org>;
          Wed, 6 Nov 2002 03:23:31 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id C37B62C57C; Tue,  5 Nov 2002 19:23:28 -0800 (PST)
Date: Tue, 5 Nov 2002 19:23:28 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: Roland McGrath <roland@redhat.com>
Cc: Daniel Jacobowitz <dan@debian.org>,
	GNU C Library <libc-alpha@sources.redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: PATCH: Fix errlist for mips
Message-ID: <20021105192328.A2230@lucon.org>
References: <20021026181431.GA11105@nevyn.them.org> <200211060253.gA62rH817728@magilla.sf.frob.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200211060253.gA62rH817728@magilla.sf.frob.com>; from roland@redhat.com on Tue, Nov 05, 2002 at 06:53:17PM -0800
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: 579
X-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

On Tue, Nov 05, 2002 at 06:53:17PM -0800, Roland McGrath wrote:
> > Here's what my MIPS glibc has:
> > 0019df30 g    DO .data  000001ec (GLIBC_2.0)  sys_errlist
> > 0019df30 g    DO .data  000011b8  GLIBC_2.2   sys_errlist
> > 0019df30 g    DO .data  000001ec (GLIBC_2.0)  _sys_errlist
> > 0019df30 g    DO .data  000011b8  GLIBC_2.2   _sys_errlist
> 
> Ok, that says sys_nerr=123 in 2.0 and sys_nerr=1134 in 2.2.
> I have changed the map to have just those.

Please keep in mind that the next version is GLIBC_2.1, not
GLIBC_2.2. The reason you see GLIBC_2.2 is GLIBC_2.2 is the
first versioned ABI for MIPS.


H.J.

From roland@redhat.com Wed Nov  6 04:44:55 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 04:44:56 +0100 (CET)
Received: from adsl-64-163-212-31.dsl.snfc21.pacbell.net ([64.163.212.31]:24317
	"EHLO gateway.sf.frob.com") by linux-mips.org with ESMTP
	id <S1123984AbSKFDoz>; Wed, 6 Nov 2002 04:44:55 +0100
Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228])
	by gateway.sf.frob.com (Postfix) with ESMTP
	id C716D357E; Tue,  5 Nov 2002 19:44:47 -0800 (PST)
Received: (from roland@localhost)
	by magilla.sf.frob.com (8.11.6/8.11.6) id gA63ikk18094;
	Tue, 5 Nov 2002 19:44:46 -0800
Date: Tue, 5 Nov 2002 19:44:46 -0800
Message-Id: <200211060344.gA63ikk18094@magilla.sf.frob.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: "H. J. Lu" <hjl@lucon.org>
Cc: Daniel Jacobowitz <dan@debian.org>,
	GNU C Library <libc-alpha@sources.redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: PATCH: Fix errlist for mips
In-Reply-To: H. J. Lu's message of  Tuesday, 5 November 2002 19:23:28 -0800 <20021105192328.A2230@lucon.org>
Emacs: impress your (remaining) friends and neighbors.
Return-Path: <roland@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: 580
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: roland@redhat.com
Precedence: bulk
X-list: linux-mips

> On Tue, Nov 05, 2002 at 06:53:17PM -0800, Roland McGrath wrote:
> > > Here's what my MIPS glibc has:
> > > 0019df30 g    DO .data  000001ec (GLIBC_2.0)  sys_errlist
> > > 0019df30 g    DO .data  000011b8  GLIBC_2.2   sys_errlist
> > > 0019df30 g    DO .data  000001ec (GLIBC_2.0)  _sys_errlist
> > > 0019df30 g    DO .data  000011b8  GLIBC_2.2   _sys_errlist
> > 
> > Ok, that says sys_nerr=123 in 2.0 and sys_nerr=1134 in 2.2.
> > I have changed the map to have just those.
> 
> Please keep in mind that the next version is GLIBC_2.1, not
> GLIBC_2.2. The reason you see GLIBC_2.2 is GLIBC_2.2 is the
> first versioned ABI for MIPS.

I don't think it's meaningful to make the distinction.  If we wrote
GLIBC_2.1, shlib-versions causes it to be GLIBC_2.2, but that's more
confusing.  Now it says GLIBC_2.2, and that's what you get.  There was
never a "sys_errlist@GLIBC_2.1" symbol in any binary, so it doesn't make
sense to have that version set.  

From hjl@lucon.org Wed Nov  6 04:53:26 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 04:53:27 +0100 (CET)
Received: from sccrmhc02.attbi.com ([204.127.202.62]:32480 "EHLO
	sccrmhc02.attbi.com") by linux-mips.org with ESMTP
	id <S1123984AbSKFDx0>; Wed, 6 Nov 2002 04:53:26 +0100
Received: from lucon.org ([12.234.88.146]) by sccrmhc02.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021106035318.SJXJ1928.sccrmhc02.attbi.com@lucon.org>;
          Wed, 6 Nov 2002 03:53:18 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 058AB2C57C; Tue,  5 Nov 2002 19:53:16 -0800 (PST)
Date: Tue, 5 Nov 2002 19:53:16 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: Roland McGrath <roland@redhat.com>
Cc: Daniel Jacobowitz <dan@debian.org>,
	GNU C Library <libc-alpha@sources.redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: PATCH: Fix errlist for mips
Message-ID: <20021105195316.A2671@lucon.org>
References: <20021105192328.A2230@lucon.org> <200211060344.gA63ikk18094@magilla.sf.frob.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200211060344.gA63ikk18094@magilla.sf.frob.com>; from roland@redhat.com on Tue, Nov 05, 2002 at 07:44:46PM -0800
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: 581
X-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

On Tue, Nov 05, 2002 at 07:44:46PM -0800, Roland McGrath wrote:
> > On Tue, Nov 05, 2002 at 06:53:17PM -0800, Roland McGrath wrote:
> > > > Here's what my MIPS glibc has:
> > > > 0019df30 g    DO .data  000001ec (GLIBC_2.0)  sys_errlist
> > > > 0019df30 g    DO .data  000011b8  GLIBC_2.2   sys_errlist
> > > > 0019df30 g    DO .data  000001ec (GLIBC_2.0)  _sys_errlist
> > > > 0019df30 g    DO .data  000011b8  GLIBC_2.2   _sys_errlist
> > > 
> > > Ok, that says sys_nerr=123 in 2.0 and sys_nerr=1134 in 2.2.
> > > I have changed the map to have just those.
> > 
> > Please keep in mind that the next version is GLIBC_2.1, not
> > GLIBC_2.2. The reason you see GLIBC_2.2 is GLIBC_2.2 is the
> > first versioned ABI for MIPS.
> 
> I don't think it's meaningful to make the distinction.  If we wrote
> GLIBC_2.1, shlib-versions causes it to be GLIBC_2.2, but that's more
> confusing.  Now it says GLIBC_2.2, and that's what you get.  There was
> never a "sys_errlist@GLIBC_2.1" symbol in any binary, so it doesn't make
> sense to have that version set.  

But you will only see sys_errlist in GLIBC_2.1 in Versions in glibc
2.2.


H.J.

From roland@redhat.com Wed Nov  6 05:06:07 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 05:06:07 +0100 (CET)
Received: from adsl-64-163-212-31.dsl.snfc21.pacbell.net ([64.163.212.31]:22269
	"EHLO gateway.sf.frob.com") by linux-mips.org with ESMTP
	id <S1123984AbSKFEGH>; Wed, 6 Nov 2002 05:06:07 +0100
Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228])
	by gateway.sf.frob.com (Postfix) with ESMTP
	id 953D6357E; Tue,  5 Nov 2002 20:05:58 -0800 (PST)
Received: (from roland@localhost)
	by magilla.sf.frob.com (8.11.6/8.11.6) id gA645vX18303;
	Tue, 5 Nov 2002 20:05:57 -0800
Date: Tue, 5 Nov 2002 20:05:57 -0800
Message-Id: <200211060405.gA645vX18303@magilla.sf.frob.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: "H. J. Lu" <hjl@lucon.org>
Cc: Daniel Jacobowitz <dan@debian.org>,
	GNU C Library <libc-alpha@sources.redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: PATCH: Fix errlist for mips
In-Reply-To: H. J. Lu's message of  Tuesday, 5 November 2002 19:53:16 -0800 <20021105195316.A2671@lucon.org>
X-Zippy-Says: ..  I feel..  JUGULAR..
Return-Path: <roland@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: 582
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: roland@redhat.com
Precedence: bulk
X-list: linux-mips

> But you will only see sys_errlist in GLIBC_2.1 in Versions in glibc 2.2.

That is indeed a bit confusing as well.  But what really matters is what
binaries historically contained, and that the current source code produces
that result.

From hjl@lucon.org Wed Nov  6 05:14:27 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 05:14:28 +0100 (CET)
Received: from rwcrmhc53.attbi.com ([204.127.198.39]:51606 "EHLO
	rwcrmhc53.attbi.com") by linux-mips.org with ESMTP
	id <S1123984AbSKFEO1>; Wed, 6 Nov 2002 05:14:27 +0100
Received: from lucon.org ([12.234.88.146]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021106041415.QMZQ22218.rwcrmhc53.attbi.com@lucon.org>;
          Wed, 6 Nov 2002 04:14:15 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 90EFD2C57C; Tue,  5 Nov 2002 20:14:14 -0800 (PST)
Date: Tue, 5 Nov 2002 20:14:14 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: Roland McGrath <roland@redhat.com>
Cc: Daniel Jacobowitz <dan@debian.org>,
	GNU C Library <libc-alpha@sources.redhat.com>,
	linux-mips@linux-mips.org
Subject: Re: PATCH: Fix errlist for mips
Message-ID: <20021105201414.A3088@lucon.org>
References: <20021105195316.A2671@lucon.org> <200211060405.gA645vX18303@magilla.sf.frob.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200211060405.gA645vX18303@magilla.sf.frob.com>; from roland@redhat.com on Tue, Nov 05, 2002 at 08:05:57PM -0800
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: 583
X-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

On Tue, Nov 05, 2002 at 08:05:57PM -0800, Roland McGrath wrote:
> > But you will only see sys_errlist in GLIBC_2.1 in Versions in glibc 2.2.
> 
> That is indeed a bit confusing as well.  But what really matters is what
> binaries historically contained, and that the current source code produces
> that result.
> 

errlist is not the only one. Most of GLIBC_2.2 for mips come from
GLIBC_2.1.


H.J.

From nemoto@toshiba-tops.co.jp Wed Nov  6 09:02:13 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 09:02:14 +0100 (CET)
Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:64004 "HELO
	topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S1123999AbSKFICN>; Wed, 6 Nov 2002 09:02:13 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [80.63.7.146]) with SMTP; 6 Nov 2002 08:02:11 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP
	id A84EFB46B; Wed,  6 Nov 2002 17:02:00 +0900 (JST)
Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP
	id RAA82673; Wed, 6 Nov 2002 17:02:00 +0900 (JST)
Date: Wed, 06 Nov 2002 17:05:02 +0900 (JST)
Message-Id: <20021106.170502.28781127.nemoto@toshiba-tops.co.jp>
To: roger_twede@hp.com
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: NFS Root failure in 2.4.18 - Traced to 256k COLOUR_ALIGN
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <CBD6266EA291D5118144009027AA63350A68F189@xboi05.boi.hp.com>
References: <CBD6266EA291D5118144009027AA63350A68F189@xboi05.boi.hp.com>
X-Fingerprint: EC 9D B9 17 2E 89 D2 25  CE F5 5D 3D 12 29 2A AD
X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <nemoto@toshiba-tops.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 584
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nemoto@toshiba-tops.co.jp
Precedence: bulk
X-list: linux-mips

>>>>> On Fri, 1 Nov 2002 13:28:32 -0800 , "TWEDE,ROGER (HP-Boise,ex1)" <roger_twede@hp.com> said:
roger> I traced the NFS root boot failure to a change made in the the
roger> function arch_get_unmapped_area(...).  The system goes from
roger> functional to non-functional with a single function change made
roger> in 2.4.18.  linux/arch/mips/kernel/syscall.c ::
roger> arch_get_unmapped_area(...), COLOUR_ALIGN

Just for your information, I also met this problem when I switched
back to old redhat-6.0 userland.  More recent userlands (RedHat 7.0,
7.1, Debian) seems free from this trouble.

---
Atsushi Nemoto

From Bert.Arnauts@fujitsu-siemens.com Wed Nov  6 13:47:36 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 13:47:36 +0100 (CET)
Received: from nixpbe.pdb.siemens.de ([192.109.2.33]:18102 "EHLO
	nixpbe.pdb.sbs.de") by linux-mips.org with ESMTP
	id <S1122122AbSKFMrg>; Wed, 6 Nov 2002 13:47:36 +0100
Received: from trulli.pdb.fsc.net ([172.25.96.20])
	by nixpbe.pdb.sbs.de (8.11.6/8.11.2) with ESMTP id gA6ClST12284
	for <linux-mips@linux-mips.org>; Wed, 6 Nov 2002 13:47:28 +0100
Received: from pdbrd01e.pdb.fsc.net (pdbrd01e.pdb.fsc.net [172.25.96.14])
	by trulli.pdb.fsc.net (8.11.6/8.11.6) with ESMTP id gA6ClSh02884
	for <linux-mips@linux-mips.org>; Wed, 6 Nov 2002 13:47:28 +0100
Received: by pdbrd01e.pdb.fsc.net with Internet Mail Service (5.5.2653.19)
	id <V8KV536A>; Wed, 6 Nov 2002 13:48:05 +0100
Message-ID: <6574B617C8C9D411B5110000D11E605802C09B18@bru0001e.bru.fsc.net>
From: "Arnauts, Bert" <Bert.Arnauts@fujitsu-siemens.com>
To: linux-mips@linux-mips.org
Subject: unsubcribe linux-mips
Date: Wed, 6 Nov 2002 13:47:07 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Bert.Arnauts@fujitsu-siemens.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: 585
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Bert.Arnauts@fujitsu-siemens.com
Precedence: bulk
X-list: linux-mips

unsubcribe linux-mips


From Deepak@ishoni.com Wed Nov  6 14:15:27 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 14:15:28 +0100 (CET)
Received: from rakshak.ishoni.co.in ([164.164.83.140]:35599 "EHLO
	arianne.in.ishoni.com") by linux-mips.org with ESMTP
	id <S1123826AbSKFNP1>; Wed, 6 Nov 2002 14:15:27 +0100
Received: from leonoid.in.ishoni.com (leonoid.in.ishoni.com [192.168.1.12])
	by arianne.in.ishoni.com (8.11.6/Ishonir2) with ESMTP id gA6DIvH32567
	for <linux-mips@linux-mips.org>; Wed, 6 Nov 2002 18:48:57 +0530
Received: by leonoid.in.ishoni.com with Internet Mail Service (5.5.2653.19)
	id <WFGKFA9Y>; Wed, 6 Nov 2002 18:48:46 +0530
Message-ID: <7CFD7CA8510CD6118F950002A519EA3003A155FB@leonoid.in.ishoni.com>
From: Deepak Shenoy <Deepak@ishoni.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: unsubcribe linux-mips
Date: Wed, 6 Nov 2002 18:48:39 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Deepak@ishoni.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: 586
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Deepak@ishoni.com
Precedence: bulk
X-list: linux-mips

unsubcribe linux-mips

From chris@render-dynamics.com Wed Nov  6 14:17:09 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 14:17:10 +0100 (CET)
Received: from colossus.systems.pipex.net ([62.241.160.73]:2273 "EHLO
	colossus.systems.pipex.net") by linux-mips.org with ESMTP
	id <S1123826AbSKFNRJ>; Wed, 6 Nov 2002 14:17:09 +0100
Received: from BIGYIN (userpq32.uk.uudial.com [62.188.172.94])
	by colossus.systems.pipex.net (Postfix) with SMTP id 8D20D160006F8
	for <linux-mips@linux-mips.org>; Wed,  6 Nov 2002 13:16:54 +0000 (GMT)
Message-ID: <001901c28596$ac215750$5eacbc3e@BIGYIN>
Reply-To: "Render Dynamics Ltd." <chris@render-dynamics.com>
From: "Render Dynamics Ltd." <chris@render-dynamics.com>
To: <linux-mips@linux-mips.org>
References: <6574B617C8C9D411B5110000D11E605802C09B18@bru0001e.bru.fsc.net>
Subject: unsubcribe linux-mips
Date: Wed, 6 Nov 2002 13:16:02 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <chris@render-dynamics.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: 587
X-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@render-dynamics.com
Precedence: bulk
X-list: linux-mips

unsubcribe linux-mips






From navneet@girnar.mti.sgi.com Wed Nov  6 17:44:06 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 17:44:06 +0100 (CET)
Received: from zok.sgi.com ([204.94.215.101]:2475 "EHLO zok.sgi.com")
	by linux-mips.org with ESMTP id <S1123951AbSKFQoG>;
	Wed, 6 Nov 2002 17:44:06 +0100
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193])
	by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gA6Fl6Kp008100
	for <linux-mips@linux-mips.org>; Wed, 6 Nov 2002 07:47:06 -0800
Received: from cardboard.mti.sgi.com (mti.mti.sgi.com [163.154.19.17])
	by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gA6GhvkZ30750044
	for <@relay.sgi.com:linux-mips@linux-mips.org>; Wed, 6 Nov 2002 08:43:57 -0800 (PST)
Received: from girnar.mti.sgi.com by cardboard.mti.sgi.com via ESMTP (980427.SGI.8.8.8/930416.SGI.AUTO-MTI)
	for <@relay.mti.sgi.com:linux-mips@linux-mips.org> id IAA82273; Wed, 6 Nov 2002 08:43:56 -0800 (PST)
Received: (from navneet@localhost) by girnar.mti.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA29584 for linux-mips@linux-mips.org; Wed, 6 Nov 2002 08:43:56 -0800 (PST)
From: "Navneet Jain" <navneet@girnar.mti.sgi.com>
Message-Id: <10211060843.ZM330569@girnar.mti.sgi.com>
Date: Wed, 6 Nov 2002 08:43:55 -0800
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: linux-mips@linux-mips.org
Subject: unsubcribe linux-mips
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <navneet@girnar.mti.sgi.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: 588
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: navneet@girnar.mti.sgi.com
Precedence: bulk
X-list: linux-mips


-- 
Navneet Jain
650-933-5749

From ralf@linux-mips.org Wed Nov  6 18:01:47 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 18:01:47 +0100 (CET)
Received: from p508B726C.dip.t-dialin.net ([80.139.114.108]:43452 "EHLO
	p508B726C.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1123951AbSKFRBr>; Wed, 6 Nov 2002 18:01:47 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S867025AbSKFRBe>; Wed, 6 Nov 2002 18:01:34 +0100
Date: Wed, 6 Nov 2002 18:01:34 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: unsubcribe linux-mips
Message-ID: <20021106180133.A7997@bacchus.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-Accept-Language: de,en,fr
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: 589
X-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:	linux-mips@linux-mips.org
> Subject: unsubcribe linux-mips

Grr...  Seems every seem to have left their brains in the fridge today.
Sending commands to the list won't help, send them to the list robot
instead.  Hint, read the help file you received when you subscribed.
Hint 2, the check the FAQ.

I enabled the filter for administrative commands on this list so from now
on should go to /nev/dull.

  Ralf, BoFH on duty

From SmithH@masirv.com Wed Nov  6 21:20:52 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 21:20:52 +0100 (CET)
Received: from [65.205.206.2] ([65.205.206.2]:27292 "EHLO NEWMAN.masirv.com")
	by linux-mips.org with ESMTP id <S1123951AbSKFUUw>;
	Wed, 6 Nov 2002 21:20:52 +0100
Received: by Newman.mascorp.com with Internet Mail Service (5.5.2653.19)
	id <4SKQYWB0>; Wed, 6 Nov 2002 12:20:45 -0800
Message-ID: <5F6E2048A983A74CA0E76CAF7B4529AD15CD3C@Newman.mascorp.com>
From: Hess Smith <SmithH@masirv.com>
To: linux-mips@linux-mips.org
Subject: unsubcribe linux-mips
Date: Wed, 6 Nov 2002 12:20:34 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <SmithH@masirv.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: 590
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: SmithH@masirv.com
Precedence: bulk
X-list: linux-mips

unsubcribe linux-mips

From joey@infodrom.org Wed Nov  6 21:37:14 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 21:37:15 +0100 (CET)
Received: from luonnotar.infodrom.org ([195.124.48.78]:12815 "EHLO
	luonnotar.infodrom.org") by linux-mips.org with ESMTP
	id <S1123920AbSKFUhO>; Wed, 6 Nov 2002 21:37:14 +0100
Received: by luonnotar.infodrom.org (Postfix, from userid 10)
	id 94447366B55; Wed,  6 Nov 2002 21:37:07 +0100 (CET)
Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2)
	from infodrom.org by finlandia.Infodrom.North.DE
	via smail from stdin
	id <m189Wn7-000pCbC@finlandia.Infodrom.North.DE>
	for linux-mips@linux-mips.org; Wed, 6 Nov 2002 21:28:45 +0100 (CET) 
Date: Wed, 6 Nov 2002 21:28:45 +0100
From: Martin Schulze <joey@infodrom.org>
To: linux-mips@linux-mips.org
Subject: Re: unsubcribe linux-mips
Message-ID: <20021106202845.GN727@finlandia.infodrom.north.de>
References: <5F6E2048A983A74CA0E76CAF7B4529AD15CD3C@Newman.mascorp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <5F6E2048A983A74CA0E76CAF7B4529AD15CD3C@Newman.mascorp.com>
User-Agent: Mutt/1.4i
Return-Path: <joey@infodrom.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 591
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joey@infodrom.org
Precedence: bulk
X-list: linux-mips

Hess Smith wrote:
> unsubcribe linux-mips

It's like the windmills...

Regards,

	Joey

-- 
It's time to close the windows.

From ppopov@mvista.com Wed Nov  6 21:50:49 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 21:50:50 +0100 (CET)
Received: from gateway-1237.mvista.com ([12.44.186.158]:29430 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S1123920AbSKFUut>;
	Wed, 6 Nov 2002 21:50:49 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA20711
	for <linux-mips@linux-mips.org>; Wed, 6 Nov 2002 12:50:16 -0800
Subject: Re: unsubcribe linux-mips
From: Pete Popov <ppopov@mvista.com>
To: linux-mips@linux-mips.org
In-Reply-To: <20021106202845.GN727@finlandia.infodrom.north.de>
References: <5F6E2048A983A74CA0E76CAF7B4529AD15CD3C@Newman.mascorp.com> 
	<20021106202845.GN727@finlandia.infodrom.north.de>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 06 Nov 2002 12:50:47 -0800
Message-Id: <1036615848.11926.23.camel@zeus.mvista.com>
Mime-Version: 1.0
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 592
X-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

So much for Ralf's filter :)

Pete

On Wed, 2002-11-06 at 12:28, Martin Schulze wrote:
> Hess Smith wrote:
> > unsubcribe linux-mips
> 
> It's like the windmills...
> 
> Regards,
> 
> 	Joey
> 
> -- 
> It's time to close the windows.
> 
> 



From ralf@uni-koblenz.de Wed Nov  6 22:14:55 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 22:14:56 +0100 (CET)
Received: from p508B726C.dip.t-dialin.net ([80.139.114.108]:29373 "EHLO
	p508B726C.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1123920AbSKFVOz>; Wed, 6 Nov 2002 22:14:55 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S867025AbSKFVOf>; Wed, 6 Nov 2002 22:14:35 +0100
Date: Wed, 6 Nov 2002 22:14:33 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: unsubcribe linux-mips
Message-ID: <20021106221433.A21307@bacchus.dhis.org>
References: <5F6E2048A983A74CA0E76CAF7B4529AD15CD3C@Newman.mascorp.com> <20021106202845.GN727@finlandia.infodrom.north.de> <1036615848.11926.23.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <1036615848.11926.23.camel@zeus.mvista.com>; from ppopov@mvista.com on Wed, Nov 06, 2002 at 12:50:47PM -0800
X-Accept-Language: de,en,fr
Return-Path: <ralf@uni-koblenz.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: 593
X-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@uni-koblenz.de
Precedence: bulk
X-list: linux-mips

On Wed, Nov 06, 2002 at 12:50:47PM -0800, Pete Popov wrote:

> So much for Ralf's filter :)

The pains of changing the list software ...

  Ralf

From jsun@orion.mvista.com Wed Nov  6 23:30:21 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Nov 2002 23:30:22 +0100 (CET)
Received: from gateway-1237.mvista.com ([12.44.186.158]:49658 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S1123920AbSKFWaV>;
	Wed, 6 Nov 2002 23:30:21 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id gA6MTsN15929;
	Wed, 6 Nov 2002 14:29:54 -0800
Date: Wed, 6 Nov 2002 14:29:54 -0800
From: Jun Sun <jsun@mvista.com>
To: "TWEDE,ROGER (HP-Boise,ex1)" <roger_twede@hp.com>
Cc: "'Ralf Baechle'" <ralf@linux-mips.org>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: NFS Root failure in 2.4.18 - Traced to 256k COLOUR_ALIGN
Message-ID: <20021106142954.C15363@mvista.com>
References: <CBD6266EA291D5118144009027AA63350A68F189@xboi05.boi.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <CBD6266EA291D5118144009027AA63350A68F189@xboi05.boi.hp.com>; from roger_twede@hp.com on Fri, Nov 01, 2002 at 01:28:32PM -0800
Return-Path: <jsun@orion.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: 594
X-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, Nov 01, 2002 at 01:28:32PM -0800, TWEDE,ROGER (HP-Boise,ex1) wrote:
> 
> Several questions that arise:
> - In the nfs case, should the file structure have its
> file->f_op->get_unmapped_area() member assigned, causing a file specific
> get_unmapped_area to be called instead of this arch_get_unmapped_area?

Don't really know about this question.

But in general if the pages are going to be shared, you will hit cache 
aliasing problem.  Then you need to implement something like cache 
coloring, which must be an unique one for the whole system, which naturally
means you need to use arch_get_unmapped_area().

> - Or should the mapping request pass in a requested address which already
> has valid 256k alignment?

Not necessarily, as long as caller is prepared for a possibly different
return value.

> - Or should requested addresses that are misaligned be handled well by the
> calling code once the translated/aligned address is returned to the calller?
>

I don't think so.

 
> And generally:
> - Why does nfsroot booting cause apecific non-zero virtual addresses to be
> requested, whereas in the ide disk booting case, addressed are left
> unspecified (0x0) (no requested mapping)?
>

I am curious too.  At least it should move along fine once it is given the
the new aligned address.

Jun

From mdharm@momenco.com Thu Nov  7 00:51:41 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 00:51:41 +0100 (CET)
Received: from jeeves.momenco.com ([64.169.228.99]:4872 "EHLO
	host099.momenco.com") by linux-mips.org with ESMTP
	id <S1123920AbSKFXvl>; Thu, 7 Nov 2002 00:51:41 +0100
Received: from beagle (natbox.momenco.com [64.169.228.98])
	by host099.momenco.com (8.11.6/8.11.6) with SMTP id gA6NpWN00589;
	Wed, 6 Nov 2002 15:51:32 -0800
From: "Matthew Dharm" <mdharm@momenco.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: "Linux-MIPS" <linux-mips@linux-mips.org>
Subject: PATCH: Small Ocelot-G cleanups
Date: Wed, 6 Nov 2002 15:51:32 -0800
Message-ID: <NEBBLJGMNKKEEMNLHGAIKECKCKAA.mdharm@momenco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0010_01C285AC.60FC1EC0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Return-Path: <mdharm@momenco.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: 595
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mdharm@momenco.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C285AC.60FC1EC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Here is a patch against the 2.4 branch.  It cleans up some dead code,
and allows the ethernet driver to get a real MAC address.

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

------=_NextPart_000_0010_01C285AC.60FC1EC0
Content-Type: application/octet-stream;
	name="patch20021106"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="patch20021106"

Index: arch/mips/momentum/ocelot_g/ocelot_pld.h=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/momentum/ocelot_g/ocelot_pld.h,v=0A=
retrieving revision 1.1.2.1=0A=
diff -u -r1.1.2.1 ocelot_pld.h=0A=
--- arch/mips/momentum/ocelot_g/ocelot_pld.h	2 Sep 2002 16:11:44 -0000	=
1.1.2.1=0A=
+++ arch/mips/momentum/ocelot_g/ocelot_pld.h	6 Nov 2002 23:46:13 -0000=0A=
@@ -8,11 +8,7 @@=0A=
 #ifndef __MOMENCO_OCELOT_PLD_H__=0A=
 #define __MOMENCO_OCELOT_PLD_H__=0A=
 =0A=
-#if 0=0A=
-#define OCELOT_CS0_ADDR (0xe0020000)=0A=
-#else=0A=
 #define OCELOT_CS0_ADDR (0xfc000000)=0A=
-#endif=0A=
 =0A=
 #define OCELOT_REG_BOARDREV (0)=0A=
 #define OCELOT_REG_PLD1_ID (1)=0A=
Index: arch/mips/momentum/ocelot_g/pci.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/momentum/ocelot_g/pci.c,v=0A=
retrieving revision 1.1.2.2=0A=
diff -u -r1.1.2.2 pci.c=0A=
--- arch/mips/momentum/ocelot_g/pci.c	2 Sep 2002 22:14:42 -0000	1.1.2.2=0A=
+++ arch/mips/momentum/ocelot_g/pci.c	6 Nov 2002 23:46:13 -0000=0A=
@@ -405,7 +405,7 @@=0A=
 	return 0;=0A=
 }=0A=
 =0A=
-int pcibios_enable_device(struct pci_dev *dev)=0A=
+int pcibios_enable_device(struct pci_dev *dev, int mask)=0A=
 {=0A=
 	return pcibios_enable_resources(dev);=0A=
 }=0A=
Index: arch/mips/momentum/ocelot_g/setup.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/momentum/ocelot_g/setup.c,v=0A=
retrieving revision 1.1.2.2=0A=
diff -u -r1.1.2.2 setup.c=0A=
--- arch/mips/momentum/ocelot_g/setup.c	2 Sep 2002 22:14:42 -0000	1.1.2.2=0A=
+++ arch/mips/momentum/ocelot_g/setup.c	6 Nov 2002 23:46:13 -0000=0A=
@@ -70,6 +70,10 @@=0A=
 =0A=
 extern struct rtc_ops no_rtc_ops;=0A=
 =0A=
+#ifdef CONFIG_GALILLEO_GT64240_ETH=0A=
+extern unsigned char prom_mac_addr_base[6];=0A=
+#endif=0A=
+=0A=
 unsigned long gt64240_base;=0A=
 =0A=
 /* These functions are used for rebooting or halting the machine*/=0A=
@@ -138,6 +142,11 @@=0A=
 =0A=
 	/* do handoff reconfiguration */=0A=
 	PMON_v2_setup();=0A=
+=0A=
+#ifdef CONFIG_GALILLEO_GT64240_ETH=0A=
+	/* get the mac addr */=0A=
+	memcpy(prom_mac_addr_base, (void*)0xfc807cf2, 6);=0A=
+#endif=0A=
 =0A=
 	/* Turn off the Bit-Error LED */=0A=
 	OCELOT_PLD_WRITE(0x80, INTCLR);=0A=
--- /dev/null	Tue May  5 13:32:27 1998=0A=
+++ arch/mips/momentum/ocelot_g/.cvsignore	Thu Sep 12 19:32:20 2002=0A=
@@ -0,0 +1,2 @@=0A=
+.depend=0A=
+.*.flags=0A=

------=_NextPart_000_0010_01C285AC.60FC1EC0--


From mdharm@momenco.com Thu Nov  7 02:48:10 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 02:48:10 +0100 (CET)
Received: from jeeves.momenco.com ([64.169.228.99]:20232 "EHLO
	host099.momenco.com") by linux-mips.org with ESMTP
	id <S1123920AbSKGBsK>; Thu, 7 Nov 2002 02:48:10 +0100
Received: from beagle (natbox.momenco.com [64.169.228.98])
	by host099.momenco.com (8.11.6/8.11.6) with SMTP id gA71m3N01252;
	Wed, 6 Nov 2002 17:48:03 -0800
From: "Matthew Dharm" <mdharm@momenco.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: "Linux-MIPS" <linux-mips@linux-mips.org>
Subject: PATCH: compile fixes for Ocelot-G for 2.5
Date: Wed, 6 Nov 2002 17:48:03 -0800
Message-ID: <NEBBLJGMNKKEEMNLHGAICECNCKAA.mdharm@momenco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001A_01C285BC.A78BD460"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Return-Path: <mdharm@momenco.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: 596
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mdharm@momenco.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

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

This patch fixes the Ocelot-G code so that it will compile with 2.5 --
primarily, this is a result of the change in PCI configuration
functions.

Note that this is a 2.5-only patch....

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

------=_NextPart_000_001A_01C285BC.A78BD460
Content-Type: application/octet-stream;
	name="patch20021106b"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="patch20021106b"

Index: arch/mips/momentum/ocelot_g/pci-irq.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/momentum/ocelot_g/pci-irq.c,v=0A=
retrieving revision 1.3=0A=
diff -u -u -r1.3 pci-irq.c=0A=
--- arch/mips/momentum/ocelot_g/pci-irq.c	3 Sep 2002 16:13:11 -0000	1.3=0A=
+++ arch/mips/momentum/ocelot_g/pci-irq.c	7 Nov 2002 01:44:22 -0000=0A=
@@ -58,14 +58,17 @@=0A=
 		}=0A=
 =0A=
 		/* Assign an interrupt number for the device */=0A=
-		bus->ops->write_byte(devices, PCI_INTERRUPT_LINE, devices->irq);=0A=
+		bus->ops->write(current_bus, devices,=0A=
+			PCI_INTERRUPT_LINE, 1, devices->irq);=0A=
 =0A=
 		/* enable master for everything but the GT-64240 */=0A=
 		if (((current_bus->number !=3D 0) && (current_bus->number !=3D 1))=0A=
 				|| (PCI_SLOT(devices->devfn) !=3D 0)) {=0A=
-			bus->ops->read_word(devices, PCI_COMMAND, &cmd);=0A=
+			bus->ops->read(current_bus, devices,=0A=
+					PCI_COMMAND, 2, &cmd);=0A=
 			cmd |=3D PCI_COMMAND_MASTER;=0A=
-			bus->ops->write_word(devices, PCI_COMMAND, cmd);=0A=
+			bus->ops->write(current_bus, devices,=0A=
+					PCI_COMMAND, 2, cmd);=0A=
 		}=0A=
 	}=0A=
 }=0A=
Index: arch/mips/momentum/ocelot_g/pci.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/momentum/ocelot_g/pci.c,v=0A=
retrieving revision 1.6=0A=
diff -u -u -r1.6 pci.c=0A=
--- arch/mips/momentum/ocelot_g/pci.c	3 Nov 2002 21:44:38 -0000	1.6=0A=
+++ arch/mips/momentum/ocelot_g/pci.c	7 Nov 2002 01:44:22 -0000=0A=
@@ -49,19 +49,26 @@=0A=
 void gt64240_board_pcibios_fixup_bus(struct pci_bus* c);=0A=
 =0A=
 /*  Functions to implement "pci ops"  */=0A=
-static int galileo_pcibios_read_config_word(struct pci_dev *dev,=0A=
+static int galileo_pcibios_read_config_word(int bus, int devfn,=0A=
 					    int offset, u16 * val);=0A=
-static int galileo_pcibios_read_config_byte(struct pci_dev *dev,=0A=
+static int galileo_pcibios_read_config_byte(int bus, int devfn,=0A=
 					    int offset, u8 * val);=0A=
-static int galileo_pcibios_read_config_dword(struct pci_dev *dev,=0A=
+static int galileo_pcibios_read_config_dword(int bus, int devfn,=0A=
 					     int offset, u32 * val);=0A=
-static int galileo_pcibios_write_config_byte(struct pci_dev *dev,=0A=
+static int galileo_pcibios_write_config_byte(int bus, int devfn,=0A=
 					     int offset, u8 val);=0A=
-static int galileo_pcibios_write_config_word(struct pci_dev *dev,=0A=
+static int galileo_pcibios_write_config_word(int bus, int devfn,=0A=
 					     int offset, u16 val);=0A=
-static int galileo_pcibios_write_config_dword(struct pci_dev *dev,=0A=
+static int galileo_pcibios_write_config_dword(int bus, int devfn,=0A=
 					      int offset, u32 val);=0A=
+#if 0=0A=
 static void galileo_pcibios_set_master(struct pci_dev *dev);=0A=
+#endif=0A=
+=0A=
+static int pci_read(struct pci_bus *bus, unsigned int devfs, int where,=0A=
+						int size, u32* val);=0A=
+static int pci_write(struct pci_bus *bus, unsigned int devfs, int where,=0A=
+						int size, u32 val);=0A=
 =0A=
 /*=0A=
  *  General-purpose PCI functions.=0A=
@@ -111,16 +118,15 @@=0A=
  * PCIBIOS_BAD_REGISTER_NUMBER when accessing non aligned=0A=
  */=0A=
 =0A=
-static int galileo_pcibios_read_config_dword(struct pci_dev *device,=0A=
+static int galileo_pcibios_read_config_dword(int bus, int devfn,=0A=
 					      int offset, u32* val)=0A=
 {=0A=
-	int dev, bus, func;=0A=
+	int dev, func;=0A=
 	uint32_t address_reg, data_reg;=0A=
 	uint32_t address;=0A=
 =0A=
-	bus =3D device->bus->number;=0A=
-	dev =3D PCI_SLOT(device->devfn);=0A=
-	func =3D PCI_FUNC(device->devfn);=0A=
+	dev =3D PCI_SLOT(devfn);=0A=
+	func =3D PCI_FUNC(devfn);=0A=
 =0A=
 	/* verify the range */=0A=
 	if (pci_range_ck(bus, dev))=0A=
@@ -152,16 +158,15 @@=0A=
 }=0A=
 =0A=
 =0A=
-static int galileo_pcibios_read_config_word(struct pci_dev *device,=0A=
+static int galileo_pcibios_read_config_word(int bus, int devfn,=0A=
 					     int offset, u16* val)=0A=
 {=0A=
-	int dev, bus, func;=0A=
+	int dev, func;=0A=
 	uint32_t address_reg, data_reg;=0A=
 	uint32_t address;=0A=
 =0A=
-	bus =3D device->bus->number;=0A=
-	dev =3D PCI_SLOT(device->devfn);=0A=
-	func =3D PCI_FUNC(device->devfn);=0A=
+	dev =3D PCI_SLOT(devfn);=0A=
+	func =3D PCI_FUNC(devfn);=0A=
 =0A=
 	/* verify the range */=0A=
 	if (pci_range_ck(bus, dev))=0A=
@@ -192,16 +197,15 @@=0A=
 	return PCIBIOS_SUCCESSFUL;=0A=
 }=0A=
 =0A=
-static int galileo_pcibios_read_config_byte(struct pci_dev *device,=0A=
+static int galileo_pcibios_read_config_byte(int bus, int devfn,=0A=
 					     int offset, u8* val)=0A=
 {=0A=
-	int dev, bus, func;=0A=
+	int dev, func;=0A=
 	uint32_t address_reg, data_reg;=0A=
 	uint32_t address;=0A=
 =0A=
-	bus =3D device->bus->number;=0A=
-	dev =3D PCI_SLOT(device->devfn);=0A=
-	func =3D PCI_FUNC(device->devfn);=0A=
+	dev =3D PCI_SLOT(devfn);=0A=
+	func =3D PCI_FUNC(devfn);=0A=
 =0A=
 	/* verify the range */=0A=
 	if (pci_range_ck(bus, dev))=0A=
@@ -230,16 +234,15 @@=0A=
 	return PCIBIOS_SUCCESSFUL;=0A=
 }=0A=
 =0A=
-static int galileo_pcibios_write_config_dword(struct pci_dev *device,=0A=
+static int galileo_pcibios_write_config_dword(int bus, int devfn,=0A=
 					      int offset, u32 val)=0A=
 {=0A=
-	int dev, bus, func;=0A=
+	int dev, func;=0A=
 	uint32_t address_reg, data_reg;=0A=
 	uint32_t address;=0A=
 =0A=
-	bus =3D device->bus->number;=0A=
-	dev =3D PCI_SLOT(device->devfn);=0A=
-	func =3D PCI_FUNC(device->devfn);=0A=
+	dev =3D PCI_SLOT(devfn);=0A=
+	func =3D PCI_FUNC(devfn);=0A=
 =0A=
 	/* verify the range */=0A=
 	if (pci_range_ck(bus, dev))=0A=
@@ -269,16 +272,15 @@=0A=
 }=0A=
 =0A=
 =0A=
-static int galileo_pcibios_write_config_word(struct pci_dev *device,=0A=
+static int galileo_pcibios_write_config_word(int bus, int devfn,=0A=
 					     int offset, u16 val)=0A=
 {=0A=
-	int dev, bus, func;=0A=
+	int dev, func;=0A=
 	uint32_t address_reg, data_reg;=0A=
 	uint32_t address;=0A=
 =0A=
-	bus =3D device->bus->number;=0A=
-	dev =3D PCI_SLOT(device->devfn);=0A=
-	func =3D PCI_FUNC(device->devfn);=0A=
+	dev =3D PCI_SLOT(devfn);=0A=
+	func =3D PCI_FUNC(devfn);=0A=
 =0A=
 	/* verify the range */=0A=
 	if (pci_range_ck(bus, dev))=0A=
@@ -307,16 +309,15 @@=0A=
 	return PCIBIOS_SUCCESSFUL;=0A=
 }=0A=
 =0A=
-static int galileo_pcibios_write_config_byte(struct pci_dev *device,=0A=
+static int galileo_pcibios_write_config_byte(int bus, int devfn,=0A=
 					     int offset, u8 val)=0A=
 {=0A=
-	int dev, bus, func;=0A=
+	int dev, func;=0A=
 	uint32_t address_reg, data_reg;=0A=
 	uint32_t address;=0A=
 =0A=
-	bus =3D device->bus->number;=0A=
-	dev =3D PCI_SLOT(device->devfn);=0A=
-	func =3D PCI_FUNC(device->devfn);=0A=
+	dev =3D PCI_SLOT(devfn);=0A=
+	func =3D PCI_FUNC(devfn);=0A=
 =0A=
 	/* verify the range */=0A=
 	if (pci_range_ck(bus, dev))=0A=
@@ -345,6 +346,7 @@=0A=
 	return PCIBIOS_SUCCESSFUL;=0A=
 }=0A=
 =0A=
+#if 0=0A=
 static void galileo_pcibios_set_master(struct pci_dev *dev)=0A=
 {=0A=
 	u16 cmd;=0A=
@@ -353,6 +355,7 @@=0A=
 	cmd |=3D PCI_COMMAND_MASTER;=0A=
 	galileo_pcibios_write_config_word(dev, PCI_COMMAND, cmd);=0A=
 }=0A=
+#endif=0A=
 =0A=
 /*  Externally-expected functions.  Do not change function names  */=0A=
 =0A=
@@ -363,7 +366,7 @@=0A=
 	int idx;=0A=
 	struct resource *r;=0A=
 =0A=
-	galileo_pcibios_read_config_word(dev, PCI_COMMAND, &cmd);=0A=
+	pci_read(dev->bus, dev->devfn, PCI_COMMAND, 2, (u32*)&cmd);=0A=
 	old_cmd =3D cmd;=0A=
 	for (idx =3D 0; idx < 6; idx++) {=0A=
 		r =3D &dev->resource[idx];=0A=
@@ -379,7 +382,7 @@=0A=
 			cmd |=3D PCI_COMMAND_MEMORY;=0A=
 	}=0A=
 	if (cmd !=3D old_cmd) {=0A=
-		galileo_pcibios_write_config_word(dev, PCI_COMMAND, cmd);=0A=
+		pci_write(dev->bus, dev->devfn, PCI_COMMAND, 2, cmd);=0A=
 	}=0A=
 =0A=
 	/*=0A=
@@ -387,19 +390,17 @@=0A=
 	 * line size =3D 32 bytes / sizeof dword (4) =3D 8.=0A=
 	 * Latency timer must be > 8.  32 is random but appears to work.=0A=
 	 */=0A=
-	galileo_pcibios_read_config_byte(dev, PCI_CACHE_LINE_SIZE, &tmp1);=0A=
+	pci_read(dev->bus, dev->devfn, PCI_CACHE_LINE_SIZE, 1, (u32*)&tmp1);=0A=
 	if (tmp1 !=3D 8) {=0A=
 		printk(KERN_WARNING "PCI setting cache line size to 8 from "=0A=
 		       "%d\n", tmp1);=0A=
-		galileo_pcibios_write_config_byte(dev, PCI_CACHE_LINE_SIZE,=0A=
-						  8);=0A=
+		pci_write(dev->bus, dev->devfn, PCI_CACHE_LINE_SIZE, 1, 8);=0A=
 	}=0A=
-	galileo_pcibios_read_config_byte(dev, PCI_LATENCY_TIMER, &tmp1);=0A=
+	pci_read(dev->bus, dev->devfn, PCI_LATENCY_TIMER, 1, (u32*)&tmp1);=0A=
 	if (tmp1 < 32) {=0A=
 		printk(KERN_WARNING "PCI setting latency timer to 32 from %d\n",=0A=
 		       tmp1);=0A=
-		galileo_pcibios_write_config_byte(dev, PCI_LATENCY_TIMER,=0A=
-						  32);=0A=
+		pci_write(dev->bus, dev->devfn, PCI_LATENCY_TIMER, 1, 32);=0A=
 	}=0A=
 =0A=
 	return 0;=0A=
@@ -413,12 +414,12 @@=0A=
 void pcibios_update_resource(struct pci_dev *dev, struct resource *root,=0A=
 			     struct resource *res, int resource)=0A=
 {=0A=
-	u32 new, check;=0A=
-	int reg;=0A=
-=0A=
 	return;=0A=
 =0A=
 #if 0=0A=
+	u32 new, check;=0A=
+	int reg;=0A=
+=0A=
 	new =3D res->start | (res->flags & PCI_REGION_FLAG_MASK);=0A=
 	if (resource < 6) {=0A=
 		reg =3D PCI_BASE_ADDRESS_0 + 4 * resource;=0A=
@@ -468,13 +469,43 @@=0A=
 }=0A=
 =0A=
 struct pci_ops galileo_pci_ops =3D {=0A=
-	galileo_pcibios_read_config_byte,=0A=
-	galileo_pcibios_read_config_word,=0A=
-	galileo_pcibios_read_config_dword,=0A=
-	galileo_pcibios_write_config_byte,=0A=
-	galileo_pcibios_write_config_word,=0A=
-	galileo_pcibios_write_config_dword=0A=
+	.read =3D pci_read,=0A=
+	.write =3D pci_write=0A=
 };=0A=
+=0A=
+static int pci_read(struct pci_bus *bus, unsigned int devfn, int where,=0A=
+						int size, u32* val)=0A=
+{=0A=
+	switch (size) {=0A=
+		case 1:=0A=
+			return galileo_pcibios_read_config_byte(bus->number,=0A=
+					devfn, where, (u8*) val);=0A=
+		case 2:=0A=
+			return galileo_pcibios_read_config_word(bus->number,=0A=
+					devfn, where, (u16*) val);=0A=
+		case 4:=0A=
+			return galileo_pcibios_read_config_dword(bus->number,=0A=
+					devfn, where, (u32*) val);=0A=
+	}=0A=
+	return PCIBIOS_FUNC_NOT_SUPPORTED;=0A=
+}=0A=
+=0A=
+static int pci_write(struct pci_bus *bus, unsigned int devfn, int where,=0A=
+						int size, u32 val)=0A=
+{=0A=
+	switch (size) {=0A=
+		case 1:=0A=
+			return galileo_pcibios_write_config_byte(bus->number,=0A=
+					devfn, where, val);=0A=
+		case 2:=0A=
+			return galileo_pcibios_write_config_word(bus->number,=0A=
+					devfn, where, val);=0A=
+		case 4:=0A=
+			return galileo_pcibios_write_config_dword(bus->number,=0A=
+					devfn, where, val);=0A=
+	}=0A=
+	return PCIBIOS_FUNC_NOT_SUPPORTED;=0A=
+}=0A=
 =0A=
 struct pci_fixup pcibios_fixups[] =3D {=0A=
 	{0}=0A=
Index: arch/mips/momentum/ocelot_g/setup.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/momentum/ocelot_g/setup.c,v=0A=
retrieving revision 1.4=0A=
diff -u -u -r1.4 setup.c=0A=
--- arch/mips/momentum/ocelot_g/setup.c	7 Nov 2002 00:02:47 -0000	1.4=0A=
+++ arch/mips/momentum/ocelot_g/setup.c	7 Nov 2002 01:44:23 -0000=0A=
@@ -86,7 +86,7 @@=0A=
 =0A=
 static char reset_reason;=0A=
 =0A=
-#define ENTRYLO(x) ((pte_val(mk_pte_phys((x) >> PAGE_SHIFT, =
PAGE_KERNEL_UNCACHED)) >> 6)|1)=0A=
+#define ENTRYLO(x) ((pte_val(pfn_pte((x) >> PAGE_SHIFT, =
PAGE_KERNEL_UNCACHED)) >> 6)|1)=0A=
 =0A=
 static void __init setup_l3cache(unsigned long size);=0A=
 =0A=

------=_NextPart_000_001A_01C285BC.A78BD460--


From mdharm@momenco.com Thu Nov  7 03:14:13 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 03:14:14 +0100 (CET)
Received: from jeeves.momenco.com ([64.169.228.99]:23560 "EHLO
	host099.momenco.com") by linux-mips.org with ESMTP
	id <S1123920AbSKGCOL>; Thu, 7 Nov 2002 03:14:11 +0100
Received: from beagle (natbox.momenco.com [64.169.228.98])
	by host099.momenco.com (8.11.6/8.11.6) with SMTP id gA72E4N01406;
	Wed, 6 Nov 2002 18:14:04 -0800
From: "Matthew Dharm" <mdharm@momenco.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: "Linux-MIPS" <linux-mips@linux-mips.org>
Subject: PATCH: fix a .cvsignore for 2.5
Date: Wed, 6 Nov 2002 18:14:04 -0800
Message-ID: <NEBBLJGMNKKEEMNLHGAIIECOCKAA.mdharm@momenco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001F_01C285C0.4A438830"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Return-Path: <mdharm@momenco.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: 597
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mdharm@momenco.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C285C0.4A438830
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The attached patch updates the .cvsignore file in
linux/arch/mips/momenco/ocelot_g/ to something reasonable for 2.5

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

------=_NextPart_000_001F_01C285C0.4A438830
Content-Type: application/octet-stream;
	name="patch20021106c"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="patch20021106c"

? arch/mips/ld.script=0A=
? arch/mips/boot/addinitrd=0A=
? arch/mips/boot/vmlinux.ecoff=0A=
? arch/mips/tools/offset.h=0A=
? scripts/mkdep=0A=
Index: arch/mips/momentum/ocelot_g/.cvsignore=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/momentum/ocelot_g/.cvsignore,v=0A=
retrieving revision 1.1=0A=
diff -u -u -r1.1 .cvsignore=0A=
--- arch/mips/momentum/ocelot_g/.cvsignore	7 Nov 2002 00:02:47 -0000	1.1=0A=
+++ arch/mips/momentum/ocelot_g/.cvsignore	7 Nov 2002 02:12:39 -0000=0A=
@@ -1,2 +1,2 @@=0A=
-.depend=0A=
+.*.cmd=0A=
 .*.flags=0A=

------=_NextPart_000_001F_01C285C0.4A438830--


From yoichi_yuasa@montavista.co.jp Thu Nov  7 12:18:53 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 12:18:54 +0100 (CET)
Received: from r-bu.iij4u.or.jp ([210.130.0.89]:29638 "EHLO r-bu.iij4u.or.jp")
	by linux-mips.org with ESMTP id <S1121743AbSKGLSx>;
	Thu, 7 Nov 2002 12:18:53 +0100
Received: from pudding ([202.216.29.50])
	by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id gA7BIaq18452;
	Thu, 7 Nov 2002 20:18:36 +0900 (JST)
Date: Thu, 7 Nov 2002 20:15:19 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: fixed the problem about build of vr41xx on linux-2.5.45
Message-Id: <20021107201519.59b90865.yoichi_yuasa@montavista.co.jp>
In-Reply-To: <20021104204929.558ddff2.yuasa@hh.iij4u.or.jp>
References: <20021103235224.2d7a4814.yuasa@hh.iij4u.or.jp>
	<20021103183650.A23232@bacchus.dhis.org>
	<20021104204929.558ddff2.yuasa@hh.iij4u.or.jp>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Thu__7_Nov_2002_20:15:19_+0900_082b4e68"
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 598
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Thu__7_Nov_2002_20:15:19_+0900_082b4e68
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Ralf,

If this patch is not applied, it will become build error by VR41xx.
Please apply this patch.

Thanks,
 
Yoichi

On Mon, 4 Nov 2002 20:49:29 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf,
> 
> On Sun, 3 Nov 2002 18:36:50 +0100
> Ralf Baechle <ralf@uni-koblenz.de> wrote:
> 
> > On Sun, Nov 03, 2002 at 11:52:24PM +0900, Yoichi Yuasa wrote:
> > 
> > > Hello Ralf,
> > > 
> > > I fixed the problem about build of vr41xx on linux-2.5.45.
> > > Here is a patch.
> > 
> > I applied the patch although quite heavily modified.  Here the bad bits:
> > 
> > >  config SERIAL
> > >  	tristate
> > > -	depends on NEC_OSPREY || IBM_WORKPAD || CASIO_E55
> > > +	depends on ZAO_CAPCELLA || NEC_EAGLE || NEC_OSPREY || VICTOR_MPC30X || IBM_WORKPAD || CASIO_E55
> > >  	default y
> > >  	---help---
> > >  	  This selects whether you want to include the driver for the standard
> > 
> > This misses the problem.  There is no more CONFIG_SERIAL option and as such
> > I removed all CONFIG_SERIAL* stuff entirely.
> 
> I made a patch for vr41xx about this problem.
> Please apply a patch.
--Multipart_Thu__7_Nov_2002_20:15:19_+0900_082b4e68
Content-Type: text/plain;
 name="vr41xx-serial.diff"
Content-Disposition: attachment;
 filename="vr41xx-serial.diff"
Content-Transfer-Encoding: 7bit

diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/casio-e55/setup.c	Mon Nov  4 15:05:00 2002
@@ -68,5 +68,7 @@
 
 	vr41xx_cmu_init(0);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
+#endif
 }
diff -aruN linux.orig/arch/mips/vr41xx/common/Makefile linux/arch/mips/vr41xx/common/Makefile
--- linux.orig/arch/mips/vr41xx/common/Makefile	Fri Nov  1 11:32:25 2002
+++ linux/arch/mips/vr41xx/common/Makefile	Mon Nov  4 15:01:14 2002
@@ -5,7 +5,7 @@
 obj-y		:= bcu.o cmu.o giu.o icu.o int-handler.o reset.o
 
 obj-$(CONFIG_PCI)		+= pciu.o
-obj-$(CONFIG_SERIAL)		+= serial.o
+obj-$(CONFIG_SERIAL_8250)	+= serial.o
 obj-$(CONFIG_VR41XX_TIME_C)	+= time.o
 
 EXTRA_AFLAGS := $(CFLAGS)
diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/ibm-workpad/setup.c	Mon Nov  4 15:10:05 2002
@@ -68,5 +68,7 @@
 
 	vr41xx_cmu_init(0);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
+#endif
 }
diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Mon Nov  4 15:10:46 2002
@@ -146,8 +146,10 @@
 
 	vr41xx_cmu_init(0);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_dsiu_init();
 	vr41xx_siu_init(SIU_RS232C, 0);
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c	Mon Nov  4 15:11:14 2002
@@ -116,7 +116,9 @@
 
 	vr41xx_cmu_init(0);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);
diff -aruN 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	Tue Oct 29 09:56:59 2002
+++ linux/arch/mips/vr41xx/zao-capcella/setup.c	Mon Nov  4 15:11:52 2002
@@ -116,8 +116,10 @@
 
 	vr41xx_cmu_init(0x0102);
 
+#ifdef CONFIG_SERIAL_8250
 	vr41xx_siu_init(SIU_RS232C, 0);
 	vr41xx_dsiu_init();
+#endif
 
 #ifdef CONFIG_PCI
 	vr41xx_pciu_init(&pci_address_map);


--Multipart_Thu__7_Nov_2002_20:15:19_+0900_082b4e68--

From macro@ds2.pg.gda.pl Thu Nov  7 20:26:09 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 20:26:10 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:51894 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1121743AbSKGT0J>; Thu, 7 Nov 2002 20:26:09 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA15700;
	Thu, 7 Nov 2002 20:26:20 +0100 (MET)
Date: Thu, 7 Nov 2002 20:26:19 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>,
	Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
Subject: Re: make xmenuconfig is broken
In-Reply-To: <Pine.GSO.3.96.1021030135048.1859E-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.3.96.1021107201241.5894L-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: 599
X-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 Oct 2002, Maciej W. Rozycki wrote:

> On Tue, 29 Oct 2002, Jun Sun wrote:
> 
> > My limited xconfig knowledge seems to tell me that moving to the generic
> > config file is the only way to make it work.  If you know a better way to fix
> > this, I will be happy to see it.
[...]
>  The problem is CONFIG_SERIAL having different meanings for the MIPS port. 
> It causes annoyance with dynamic parsers (like `make config') and I'm not
> surprised it breaks the xconfig static parser. 

 I renamed the guilty options and also I decided moving DECstation serial
port configuration to drivers/char is the way to go.  As a side effect you
now may build both the dz11/z8530 drivers and the i8250 one (as an advance
towards a generic kernel).

 Here is a patch for 2.4.  Does it fix things for you?  And is it
acceptable for the others?  Specifically, I mean putting the questions
under CONFIG_SERIAL_NONSTANDARD (the name is unfortunate, but that's
heritage from the old days and is going to vainsh in 2.6 anyway). 

 If no objections arise, I'll check the patch in soon, probably tomorrow.

  Maciej

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

patch-mips-2.4.20-pre6-20021017-dec-serial-1
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021017.macro/Documentation/Configure.help linux-mips-2.4.20-pre6-20021017/Documentation/Configure.help
--- linux-mips-2.4.20-pre6-20021017.macro/Documentation/Configure.help	2002-10-03 02:56:16.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021017/Documentation/Configure.help	2002-11-05 21:01:48.000000000 +0000
@@ -2148,6 +2148,27 @@ SGI PROM Console Support
 CONFIG_SGI_PROM_CONSOLE
   Say Y here to set up the boot console on serial port 0.
 
+DECstation serial support
+CONFIG_SERIAL_DEC
+  This selects whether you want to be asked about drivers for
+  DECstation serial ports.
+
+  Note that the answer to this question won't directly affect the
+  kernel: saying N will just cause the configurator to skip all
+  the questions about DECstation serial ports.
+
+  If unsure, say Y.
+
+Support for console on a DECstation serial port
+CONFIG_SERIAL_DEC_CONSOLE
+  If you say Y here, it will be possible to use a serial port as the
+  system console (the system console is the device which receives all
+  kernel messages and warnings and which allows logins in single user
+  mode).  Note that the firmware uses ttyS0 as the serial console on
+  the Maxine and ttyS2 on the others.
+
+  If unsure, say Y.
+
 DZ11 Serial Support
 CONFIG_DZ
   DZ11-family serial controllers for VAXstations, including the
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021017.macro/arch/mips/config-shared.in linux-mips-2.4.20-pre6-20021017/arch/mips/config-shared.in
--- linux-mips-2.4.20-pre6-20021017.macro/arch/mips/config-shared.in	2002-10-07 02:56:25.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021017/arch/mips/config-shared.in	2002-10-30 23:31:32.000000000 +0000
@@ -764,19 +764,6 @@ source drivers/char/Config.in
 
 #source drivers/misc/Config.in
 
-if [ "$CONFIG_DECSTATION" = "y" ]; then
-   mainmenu_option next_comment
-   comment 'DECStation Character devices'
-
-   tristate 'Standard/generic (dumb) serial support' CONFIG_SERIAL
-   dep_bool '  DZ11 Serial Support' CONFIG_DZ $CONFIG_SERIAL
-   dep_bool '  Z85C30 Serial Support' CONFIG_ZS $CONFIG_SERIAL $CONFIG_TC
-   dep_bool '  Support for console on serial port' CONFIG_SERIAL_CONSOLE $CONFIG_SERIAL
-#   dep_bool 'MAXINE Access.Bus mouse (VSXXX-BB/GB) support' CONFIG_DTOP_MOUSE $CONFIG_ACCESSBUS
-   bool 'Enhanced Real Time Clock Support' CONFIG_RTC
-   endmenu
-fi
-
 if [ "$CONFIG_SGI_IP22" = "y" ]; then
    mainmenu_option next_comment
    comment 'SGI Character devices'
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021017.macro/drivers/char/Config.in linux-mips-2.4.20-pre6-20021017/drivers/char/Config.in
--- linux-mips-2.4.20-pre6-20021017.macro/drivers/char/Config.in	2002-10-08 02:56:56.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021017/drivers/char/Config.in	2002-11-05 20:54:55.000000000 +0000
@@ -104,7 +104,14 @@ if [ "$CONFIG_SERIAL_NONSTANDARD" = "y" 
          fi
       fi
    fi
+   if [ "$CONFIG_DECSTATION" = "y" ]; then
+      bool '  DECstation serial support' CONFIG_SERIAL_DEC
+      dep_bool '    Support for console on a DECstation serial port' CONFIG_SERIAL_DEC_CONSOLE $CONFIG_SERIAL_DEC
+      dep_bool '    DZ11 serial support' CONFIG_DZ $CONFIG_SERIAL_DEC
+      dep_bool '    Z85C30 serial support' CONFIG_ZS $CONFIG_SERIAL_DEC $CONFIG_TC
+   fi
 fi
+
 if [ "$CONFIG_EXPERIMENTAL" = "y" -a "$CONFIG_ZORRO" = "y" ]; then
    tristate 'Commodore A2232 serial support (EXPERIMENTAL)' CONFIG_A2232
 fi
@@ -161,6 +168,9 @@ if [ "$CONFIG_BUSMOUSE" != "n" ]; then
    if [ "$CONFIG_ADB" = "y" -a "$CONFIG_ADB_KEYBOARD" = "y" ]; then
       dep_tristate '  Apple Desktop Bus mouse support (old driver)' CONFIG_ADBMOUSE $CONFIG_BUSMOUSE
    fi
+#   if [ "$CONFIG_DECSTATION" = "y" ]; then
+#      dep_bool '  MAXINE Access.Bus mouse (VSXXX-BB/GB) support' CONFIG_DTOP_MOUSE $CONFIG_ACCESSBUS
+#   fi
 fi
 
 tristate 'Mouse Support (not serial and bus mice)' CONFIG_MOUSE
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021017.macro/drivers/char/Makefile linux-mips-2.4.20-pre6-20021017/drivers/char/Makefile
--- linux-mips-2.4.20-pre6-20021017.macro/drivers/char/Makefile	2002-09-12 03:09:53.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021017/drivers/char/Makefile	2002-11-05 20:37:50.000000000 +0000
@@ -126,7 +126,6 @@ endif
 ifeq ($(CONFIG_DECSTATION),y)
   KEYMAP   =
   KEYBD    =
-  SERIAL   = decserial.o
 endif
 
 ifeq ($(CONFIG_BAGET_MIPS),y)
@@ -158,6 +157,7 @@ obj-$(CONFIG_SERIAL_21285) += serial_212
 obj-$(CONFIG_SERIAL_SA1100) += serial_sa1100.o
 obj-$(CONFIG_SERIAL_AMBA) += serial_amba.o
 obj-$(CONFIG_TS_AU1000_ADS7846) += au1000_ts.o
+obj-$(CONFIG_SERIAL_DEC) += decserial.o
 
 ifndef CONFIG_SUN_KEYBOARD
   obj-$(CONFIG_VT) += keyboard.o $(KEYMAP) $(KEYBD)
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021017.macro/drivers/char/decserial.c linux-mips-2.4.20-pre6-20021017/drivers/char/decserial.c
--- linux-mips-2.4.20-pre6-20021017.macro/drivers/char/decserial.c	2001-07-17 19:49:00.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021017/drivers/char/decserial.c	2002-11-05 20:31:26.000000000 +0000
@@ -28,7 +28,7 @@ extern int zs_init(void);
 extern int dz_init(void);
 #endif
 
-#ifdef CONFIG_SERIAL_CONSOLE
+#ifdef CONFIG_SERIAL_DEC_CONSOLE
 
 #ifdef CONFIG_ZS
 extern void zs_serial_console_init(void);
@@ -43,7 +43,7 @@ extern void dz_serial_console_init(void)
 /* rs_init - starts up the serial interface -
    handle normal case of starting up the serial interface */
 
-#ifdef CONFIG_SERIAL
+#ifdef CONFIG_SERIAL_DEC
 
 int __init rs_init(void)
 {
@@ -70,12 +70,12 @@ __initcall(rs_init);
 
 #endif
 
-#ifdef CONFIG_SERIAL_CONSOLE
+#ifdef CONFIG_SERIAL_DEC_CONSOLE
 
-/* serial_console_init handles the special case of starting
+/* dec_serial_console_init handles the special case of starting
  *   up the console on the serial port
  */
-void __init serial_console_init(void)
+void __init dec_serial_console_init(void)
 {
 #if defined(CONFIG_ZS) && defined(CONFIG_DZ)
     if (IOASIC)
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021017.macro/drivers/char/dz.c linux-mips-2.4.20-pre6-20021017/drivers/char/dz.c
--- linux-mips-2.4.20-pre6-20021017.macro/drivers/char/dz.c	2002-10-02 02:56:52.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021017/drivers/char/dz.c	2002-11-05 20:32:23.000000000 +0000
@@ -1411,7 +1411,7 @@ int __init dz_init(void)
 	}
 
 	/* reset the chip */
-#ifndef CONFIG_SERIAL_CONSOLE
+#ifndef CONFIG_SERIAL_DEC_CONSOLE
 	dz_out(info, DZ_CSR, DZ_CLR);
 	while ((tmp = dz_in(info, DZ_CSR)) & DZ_CLR);
 	iob();
@@ -1433,7 +1433,7 @@ int __init dz_init(void)
 	return 0;
 }
 
-#ifdef CONFIG_SERIAL_CONSOLE
+#ifdef CONFIG_SERIAL_DEC_CONSOLE
 static void dz_console_put_char(unsigned char ch)
 {
 	unsigned long flags;
@@ -1587,6 +1587,6 @@ void __init dz_serial_console_init(void)
 	register_console(&dz_sercons);
 }
 
-#endif /* CONFIG_SERIAL_CONSOLE */
+#endif /* CONFIG_SERIAL_DEC_CONSOLE */
 
 MODULE_LICENSE("GPL");
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021017.macro/drivers/char/tty_io.c linux-mips-2.4.20-pre6-20021017/drivers/char/tty_io.c
--- linux-mips-2.4.20-pre6-20021017.macro/drivers/char/tty_io.c	2002-09-16 02:58:19.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021017/drivers/char/tty_io.c	2002-11-05 20:30:00.000000000 +0000
@@ -2240,6 +2240,9 @@ void __init console_init(void)
 	sci_console_init();
 #endif
 #endif
+#ifdef CONFIG_SERIAL_DEC_CONSOLE
+	dec_serial_console_init();
+#endif
 #ifdef CONFIG_TN3270_CONSOLE
 	tub3270_con_init();
 #endif
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021017.macro/drivers/tc/zs.c linux-mips-2.4.20-pre6-20021017/drivers/tc/zs.c
--- linux-mips-2.4.20-pre6-20021017.macro/drivers/tc/zs.c	2002-08-06 02:58:08.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021017/drivers/tc/zs.c	2002-11-05 20:39:27.000000000 +0000
@@ -56,7 +56,7 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/ioport.h>
-#ifdef CONFIG_SERIAL_CONSOLE
+#ifdef CONFIG_SERIAL_DEC_CONSOLE
 #include <linux/console.h>
 #endif
 
@@ -157,10 +157,10 @@ struct dec_serial *zs_chain;	/* list of 
 
 struct tty_struct zs_ttys[NUM_CHANNELS];
 
-#ifdef CONFIG_SERIAL_CONSOLE
+#ifdef CONFIG_SERIAL_DEC_CONSOLE
 static struct console sercons;
 #endif
-#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) \
+#if defined(CONFIG_SERIAL_DEC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) \
     && !defined(MODULE)
 static unsigned long break_pressed; /* break, really ... */
 #endif
@@ -416,7 +416,7 @@ static _INLINE_ void receive_chars(struc
 
 		if (tty_break) {
 			tty_break = 0;
-#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
+#if defined(CONFIG_SERIAL_DEC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
 			if (info->line == sercons.index) {
 				if (!break_pressed) {
 					break_pressed = jiffies;
@@ -442,7 +442,7 @@ static _INLINE_ void receive_chars(struc
 				write_zsreg(info->zs_channel, R0, ERR_RES);
 		}
 
-#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
+#if defined(CONFIG_SERIAL_DEC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
 		if (break_pressed && info->line == sercons.index) {
 			if (ch != 0 &&
 			    time_before(jiffies, break_pressed + HZ*5)) {
@@ -473,7 +473,7 @@ static _INLINE_ void receive_chars(struc
 
 		*tty->flip.flag_buf_ptr++ = flag;
 		*tty->flip.char_buf_ptr++ = ch;
-#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
+#if defined(CONFIG_SERIAL_DEC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
 	ignore_char:
 #endif
 	}
@@ -1701,7 +1701,7 @@ int rs_open(struct tty_struct *tty, stru
 			*tty->termios = info->callout_termios;
 		change_speed(info);
 	}
-#ifdef CONFIG_SERIAL_CONSOLE
+#ifdef CONFIG_SERIAL_DEC_CONSOLE
 	if (sercons.cflag && sercons.index == line) {
 		tty->termios->c_cflag = sercons.cflag;
 		sercons.cflag = 0;
@@ -1801,7 +1801,7 @@ static void __init probe_sccs(void)
 			zs_channels[n_channels].data =
 				zs_channels[n_channels].control + 4;
 
-#ifndef CONFIG_SERIAL_CONSOLE
+#ifndef CONFIG_SERIAL_DEC_CONSOLE
 			/*
 			 * We're called early and memory managment isn't up, yet.
 			 * Thus check_region would fail.
@@ -2111,7 +2111,7 @@ unsigned int unregister_zs_hook(unsigned
  * Serial console driver
  * ------------------------------------------------------------
  */
-#ifdef CONFIG_SERIAL_CONSOLE
+#ifdef CONFIG_SERIAL_DEC_CONSOLE
 
 
 /*
@@ -2279,7 +2279,7 @@ void __init zs_serial_console_init(void)
 {
 	register_console(&sercons);
 }
-#endif /* ifdef CONFIG_SERIAL_CONSOLE */
+#endif /* ifdef CONFIG_SERIAL_DEC_CONSOLE */
 
 #ifdef CONFIG_KGDB
 struct dec_zschannel *zs_kgdbchan;


From bbozarth@cisco.com Thu Nov  7 21:34:06 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 21:34:07 +0100 (CET)
Received: from sj-msg-core-4.cisco.com ([171.71.163.54]:33947 "EHLO
	sj-msg-core-4.cisco.com") by linux-mips.org with ESMTP
	id <S1121743AbSKGUeG>; Thu, 7 Nov 2002 21:34:06 +0100
Received: from bbozarth-lnx.cisco.com (bbozarth-lnx.cisco.com [128.107.165.13])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA7KXuot004359;
	Thu, 7 Nov 2002 12:33:56 -0800 (PST)
Received: from localhost (bbozarth@localhost)
	by bbozarth-lnx.cisco.com (8.11.6/8.11.6) with ESMTP id gA7KXul10479;
	Thu, 7 Nov 2002 12:33:56 -0800
Date: Thu, 7 Nov 2002 12:33:55 -0800 (PST)
From: Bradley Bozarth <bbozarth@cisco.com>
To: linux-mips@linux-mips.org
cc: george@mvista.com
Subject: SEGEV defines
In-Reply-To: <Pine.GSO.3.96.1021107201241.5894L-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.LNX.4.44.0211071229340.7794-100000@bbozarth-lnx.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <bbozarth@cisco.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: 600
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bbozarth@cisco.com
Precedence: bulk
X-list: linux-mips

Can these be changed?

> Now a question, why does mips use these values:                               
>  #define SIGEV_SIGNAL   129     /* notify via signal */                       
>  #define SIGEV_CALLBACK 130     /* ??? */                                     
>  #define SIGEV_THREAD   131     /* deliver via thread                         
> creation */                                                                   
>                                                                               
> It is the only platform that adds anything to the simple                      
> 1,2,3 values used on other platforms.  The reason I ask, is                   
> that I would like to change them to conform to all the                        
> others.




From brm@murphy.dk Thu Nov  7 23:03:23 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 23:03:23 +0100 (CET)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:58437 "EHLO
	brian.localnet") by linux-mips.org with ESMTP id <S1121743AbSKGWDX>;
	Thu, 7 Nov 2002 23:03:23 +0100
Received: from brm by brian.localnet with local (Exim 3.35 #1 (Debian))
	id 189uk6-0001Rj-00
	for <linux-mips@linux-mips.org>; Thu, 07 Nov 2002 23:03:14 +0100
To: linux-mips@linux-mips.org
Subject: [PATCH 2.5] initramfs fix 
Message-Id: <E189uk6-0001Rj-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Thu, 07 Nov 2002 23:03:14 +0100
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: 601
X-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,
	I have had a little problem with initramfs, Finally I have
found out that the problem is that when I make a flash image I do an
objcopy of the kernel image to get something which can be flashed.
Unfortunately objcopy thinks that the .init.initramfs is a useless section
and throws it away because it does not have the alloc flag set.
Here is a fix.

/Brian

Index: usr/Makefile
===================================================================
RCS file: /home/cvs/linux/usr/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- usr/Makefile	5 Nov 2002 15:18:25 -0000	1.1
+++ usr/Makefile	7 Nov 2002 21:59:31 -0000
@@ -17,6 +17,7 @@
 	$(OBJCOPY) $(ARCHBLOBLFLAGS) \
 		--only-section=.init.initramfs \
 		--add-section=.init.initramfs=$(obj)/initramfs_data.cpio.gz \
+		--set-section-flags .init.initramfs=alloc \
 		$(obj)/empty.o $(obj)/initramfs_data.o
 	$(STRIP) -s $(obj)/initramfs_data.o
 

From drow@false.org Thu Nov  7 23:10:20 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 23:10:21 +0100 (CET)
Received: from crack.them.org ([65.125.64.184]:24584 "EHLO crack.them.org")
	by linux-mips.org with ESMTP id <S1121743AbSKGWKU>;
	Thu, 7 Nov 2002 23:10:20 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 189wiZ-0001zF-00; Thu, 07 Nov 2002 18:09:47 -0600
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 189ur7-0007lS-00; Thu, 07 Nov 2002 17:10:29 -0500
Date: Thu, 7 Nov 2002 17:10:29 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Bradley Bozarth <bbozarth@cisco.com>
Cc: linux-mips@linux-mips.org, george@mvista.com
Subject: Re: SEGEV defines
Message-ID: <20021107221029.GA22385@nevyn.them.org>
References: <Pine.GSO.3.96.1021107201241.5894L-100000@delta.ds2.pg.gda.pl> <Pine.LNX.4.44.0211071229340.7794-100000@bbozarth-lnx.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0211071229340.7794-100000@bbozarth-lnx.cisco.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: 602
X-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

Presumably they match IRIX... like the rest of MIPS's oddball
definitions.  A little hard to change them now.

On Thu, Nov 07, 2002 at 12:33:55PM -0800, Bradley Bozarth wrote:
> Can these be changed?
> 
> > Now a question, why does mips use these values:                               
> >  #define SIGEV_SIGNAL   129     /* notify via signal */                       
> >  #define SIGEV_CALLBACK 130     /* ??? */                                     
> >  #define SIGEV_THREAD   131     /* deliver via thread                         
> > creation */                                                                   
> >                                                                               
> > It is the only platform that adds anything to the simple                      
> > 1,2,3 values used on other platforms.  The reason I ask, is                   
> > that I would like to change them to conform to all the                        
> > others.
> 
> 
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From jsun@orion.mvista.com Thu Nov  7 23:23:20 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Nov 2002 23:23:21 +0100 (CET)
Received: from gateway-1237.mvista.com ([12.44.186.158]:31473 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S1121743AbSKGWXU>;
	Thu, 7 Nov 2002 23:23:20 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id gA7MN5N29499;
	Thu, 7 Nov 2002 14:23:05 -0800
Date: Thu, 7 Nov 2002 14:23:04 -0800
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: make xmenuconfig is broken
Message-ID: <20021107142304.B27505@mvista.com>
References: <Pine.GSO.3.96.1021030135048.1859E-100000@delta.ds2.pg.gda.pl> <Pine.GSO.3.96.1021107201241.5894L-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.1021107201241.5894L-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Nov 07, 2002 at 08:26:19PM +0100
Return-Path: <jsun@orion.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: 603
X-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


Yes, this patch takes care of DECSTATION part of the xconfig problem. 
Thanks.

Now we still have IP22 config which needs to be fixed.  Any volunteers?

This is the additional hack needed that would make xconfig (serial/serial 
console options) work.

diff -Nru arch/mips/config-shared.in.orig arch/mips/config-shared.in
--- arch/mips/config-shared.in.orig     Thu Nov  7 14:14:09 2002
+++ arch/mips/config-shared.in  Thu Nov  7 14:17:33 2002
@@ -800,9 +800,9 @@
 fi
 endmenu
 
-if [ "$CONFIG_SGI_IP22" = "y" ]; then
-   source drivers/sgi/Config.in
-fi
+#if [ "$CONFIG_SGI_IP22" = "y" ]; then
+#   source drivers/sgi/Config.in
+#fi
 
 source drivers/usb/Config.in
 
Jun

On Thu, Nov 07, 2002 at 08:26:19PM +0100, Maciej W. Rozycki wrote:
> On Wed, 30 Oct 2002, Maciej W. Rozycki wrote:
> 
> > On Tue, 29 Oct 2002, Jun Sun wrote:
> > 
> > > My limited xconfig knowledge seems to tell me that moving to the generic
> > > config file is the only way to make it work.  If you know a better way to fix
> > > this, I will be happy to see it.
> [...]
> >  The problem is CONFIG_SERIAL having different meanings for the MIPS port. 
> > It causes annoyance with dynamic parsers (like `make config') and I'm not
> > surprised it breaks the xconfig static parser. 
> 
>  I renamed the guilty options and also I decided moving DECstation serial
> port configuration to drivers/char is the way to go.  As a side effect you
> now may build both the dz11/z8530 drivers and the i8250 one (as an advance
> towards a generic kernel).
> 

From wgowcher@yahoo.com Fri Nov  8 04:52:42 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 04:52:43 +0100 (CET)
Received: from web11903.mail.yahoo.com ([216.136.172.187]:4279 "HELO
	web11903.mail.yahoo.com") by linux-mips.org with SMTP
	id <S1121743AbSKHDwm>; Fri, 8 Nov 2002 04:52:42 +0100
Message-ID: <20021108035234.34238.qmail@web11903.mail.yahoo.com>
Received: from [209.243.184.191] by web11903.mail.yahoo.com via HTTP; Thu, 07 Nov 2002 19:52:34 PST
Date: Thu, 7 Nov 2002 19:52:34 -0800 (PST)
From: Wayne Gowcher <wgowcher@yahoo.com>
Subject: Enabling pthreads to use ll/sc instead of emulate_load_store_insn
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: 604
X-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

Hi,

I have an userland application that uses pthreads and
crashes with a segmentaion due to an "unaligned access
in function 'emulate_load_store_insn' ". 

The processor is an r4k and the application is being
compiled with mips2 switch, which I thought would
allow it to generate the ll/sc instructions natively
and not have to generate system calls to emulate it.
I am guessing this is because the pthread library I
have is from the sgi ftp site and it was compiled for
mips1 ??

If someone has any insight into how to get libpthread
to use ll/sc instructions instead of the mips system
call I would really appreciate hearing from them.

Also if anyone can "put me straight" on what is
happening I'd equally appreciate it.

Wayne

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2

From ralf@linux-mips.org Fri Nov  8 06:13:09 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 06:13:10 +0100 (CET)
Received: from p508B6A78.dip.t-dialin.net ([80.139.106.120]:64896 "EHLO
	p508B6A78.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122165AbSKHFNJ>; Fri, 8 Nov 2002 06:13:09 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S868139AbSKHFMd>; Fri, 8 Nov 2002 06:12:33 +0100
Date: Fri, 8 Nov 2002 06:12:33 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Wayne Gowcher <wgowcher@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Enabling pthreads to use ll/sc instead of emulate_load_store_insn
Message-ID: <20021108061233.A3314@bacchus.dhis.org>
References: <20021108035234.34238.qmail@web11903.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021108035234.34238.qmail@web11903.mail.yahoo.com>; from wgowcher@yahoo.com on Thu, Nov 07, 2002 at 07:52:34PM -0800
X-Accept-Language: de,en,fr
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: 605
X-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, Nov 07, 2002 at 07:52:34PM -0800, Wayne Gowcher wrote:

> The processor is an r4k and the application is being
> compiled with mips2 switch, which I thought would
> allow it to generate the ll/sc instructions natively
> and not have to generate system calls to emulate it.
> I am guessing this is because the pthread library I
> have is from the sgi ftp site and it was compiled for
> mips1 ??
>
> If someone has any insight into how to get libpthread
> to use ll/sc instructions instead of the mips system
> call I would really appreciate hearing from them.

Rebuild it with -mips2.  The inline code in glibc is coded such that it'll
automatically use ll/sc then.

  Ralf

From hjl@lucon.org Fri Nov  8 06:18:20 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 06:18:21 +0100 (CET)
Received: from p508B6A78.dip.t-dialin.net ([80.139.106.120]:5249 "EHLO
	p508B6A78.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122165AbSKHFSU>; Fri, 8 Nov 2002 06:18:20 +0100
Received: from sccrmhc03.attbi.com ([IPv6:::ffff:204.127.202.63]:5077 "EHLO
	sccrmhc03.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S868139AbSKHFRs>; Fri, 8 Nov 2002 06:17:48 +0100
Received: from lucon.org ([12.234.88.146]) by sccrmhc03.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20021108051759.GVHN3205.sccrmhc03.attbi.com@lucon.org>;
          Fri, 8 Nov 2002 05:17:59 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 628A42C57C; Thu,  7 Nov 2002 21:17:59 -0800 (PST)
Date: Thu, 7 Nov 2002 21:17:59 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Wayne Gowcher <wgowcher@yahoo.com>, linux-mips@linux-mips.org
Subject: Re: Enabling pthreads to use ll/sc instead of emulate_load_store_insn
Message-ID: <20021107211759.A6082@lucon.org>
References: <20021108035234.34238.qmail@web11903.mail.yahoo.com> <20021108061233.A3314@bacchus.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021108061233.A3314@bacchus.dhis.org>; from ralf@linux-mips.org on Fri, Nov 08, 2002 at 06:12:33AM +0100
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: 606
X-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

On Fri, Nov 08, 2002 at 06:12:33AM +0100, Ralf Baechle wrote:
> On Thu, Nov 07, 2002 at 07:52:34PM -0800, Wayne Gowcher wrote:
> 
> > The processor is an r4k and the application is being
> > compiled with mips2 switch, which I thought would
> > allow it to generate the ll/sc instructions natively
> > and not have to generate system calls to emulate it.
> > I am guessing this is because the pthread library I
> > have is from the sgi ftp site and it was compiled for
> > mips1 ??
> >
> > If someone has any insight into how to get libpthread
> > to use ll/sc instructions instead of the mips system
> > call I would really appreciate hearing from them.
> 
> Rebuild it with -mips2.  The inline code in glibc is coded such that it'll
> automatically use ll/sc then.

I believe I enabled ll/sc unconditinally in glibc. Make sure you use
a recent glibc. The one from my RedHat 7.3 port should be ok.


H.J.

From ralf@linux-mips.org Fri Nov  8 06:27:51 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 06:27:52 +0100 (CET)
Received: from p508B6A78.dip.t-dialin.net ([80.139.106.120]:12673 "EHLO
	p508B6A78.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122165AbSKHF1v>; Fri, 8 Nov 2002 06:27:51 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S868139AbSKHF1S>; Fri, 8 Nov 2002 06:27:18 +0100
Date: Fri, 8 Nov 2002 06:27:17 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "H. J. Lu" <hjl@lucon.org>
Cc: Wayne Gowcher <wgowcher@yahoo.com>, linux-mips@linux-mips.org
Subject: Re: Enabling pthreads to use ll/sc instead of emulate_load_store_insn
Message-ID: <20021108062717.A3489@bacchus.dhis.org>
References: <20021108035234.34238.qmail@web11903.mail.yahoo.com> <20021108061233.A3314@bacchus.dhis.org> <20021107211759.A6082@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021107211759.A6082@lucon.org>; from hjl@lucon.org on Thu, Nov 07, 2002 at 09:17:59PM -0800
X-Accept-Language: de,en,fr
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: 607
X-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, Nov 07, 2002 at 09:17:59PM -0800, H. J. Lu wrote:

> > Rebuild it with -mips2.  The inline code in glibc is coded such that it'll
> > automatically use ll/sc then.
> 
> I believe I enabled ll/sc unconditinally in glibc. Make sure you use
> a recent glibc. The one from my RedHat 7.3 port should be ok.

That's a relativly recent change.  Wayne's libc obviously predates this
change ...

  Ralf

From yoichi_yuasa@montavista.co.jp Fri Nov  8 08:04:37 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 08:04:37 +0100 (CET)
Received: from r-bu.iij4u.or.jp ([210.130.0.89]:42223 "EHLO r-bu.iij4u.or.jp")
	by linux-mips.org with ESMTP id <S1122165AbSKHHEh>;
	Fri, 8 Nov 2002 08:04:37 +0100
Received: from pudding ([202.216.29.50])
	by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id gA874Qq02298;
	Fri, 8 Nov 2002 16:04:27 +0900 (JST)
Date: Fri, 8 Nov 2002 16:01:09 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: [PATCH 2.5] PCI config read/write fixed for vr41xx
Message-Id: <20021108160109.38bbb072.yoichi_yuasa@montavista.co.jp>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Fri__8_Nov_2002_16:01:09_+0900_08359028"
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 608
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Fri__8_Nov_2002_16:01:09_+0900_08359028
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Ralf,

I have fixed new PCI config read/write of vr41xx.
Please apply this patch.

Thanks,

Yoichi
--Multipart_Fri__8_Nov_2002_16:01:09_+0900_08359028
Content-Type: text/plain;
 name="vr41xx-021108.diff"
Content-Disposition: attachment;
 filename="vr41xx-021108.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.c linux/arch/mips/vr41xx/common/pciu.c
--- linux.orig/arch/mips/vr41xx/common/pciu.c	Mon Jul 15 08:47:57 2002
+++ linux/arch/mips/vr41xx/common/pciu.c	Fri Nov  8 14:39:56 2002
@@ -53,32 +53,28 @@
 
 extern unsigned long vr41xx_vtclock;
 
-static inline int vr41xx_pci_config_access(struct pci_dev *dev, int where)
+static inline int vr41xx_pci_config_access(unsigned char bus,  unsigned int devfn, int where)
 {
-	unsigned char bus = dev->bus->number;
-	unsigned int dev_fn = dev->devfn;
-
 	if (bus == 0) {
 		/*
 		 * Type 0 configuration
 		 */
-		if (PCI_SLOT(dev_fn) < 11 || PCI_SLOT(dev_fn) > 31 || where > 255)
+		if (PCI_SLOT(devfn) < 11 || where > 255)
 			return -1;
 
-		writel((1UL << PCI_SLOT(dev_fn))|
-		       (PCI_FUNC(dev_fn) << 8)	|
+		writel((1UL << PCI_SLOT(devfn))	|
+		       (PCI_FUNC(devfn) << 8)	|
 		       (where & 0xfc),
 		       PCICONFAREG);
-	}
-	else {
+	} else {
 		/*
 		 * Type 1 configuration
 		 */
-		if (bus > 255 || PCI_SLOT(dev_fn) > 31 || where > 255)
+		if (where > 255)
 			return -1;
 
 		writel((bus << 16)	|
-		       (dev_fn << 8)	|
+		       (devfn << 8)	|
 		       (where & 0xfc)	|
 		       1UL,
 		       PCICONFAREG);
@@ -87,110 +83,69 @@
 	return 0;
 }
 
-static int vr41xx_pci_read_config_byte(struct pci_dev *dev, int where, u8 *val)
-{
-	u32 data;
-
-	*val = 0xff;
-	if (vr41xx_pci_config_access(dev, where) < 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
-
-	data = readl(PCICONFDREG);
-	*val = (u8)(data >> ((where & 3) << 3));
-
-	return PCIBIOS_SUCCESSFUL;
-
-}
-
-static int vr41xx_pci_read_config_word(struct pci_dev *dev, int where, u16 *val)
+static int vr41xx_pci_config_read(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val)
 {
 	u32 data;
 
-	*val = 0xffff;
-	if (where & 1)
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	if (vr41xx_pci_config_access(dev, where) < 0)
+	*val = 0xffffffffUL;
+	if (vr41xx_pci_config_access(bus->number, devfn, where) < 0)
 		return PCIBIOS_DEVICE_NOT_FOUND;
 
 	data = readl(PCICONFDREG);
-	*val = (u16)(data >> ((where & 2) << 3));
-
-	return PCIBIOS_SUCCESSFUL;
-}
 
-static int vr41xx_pci_read_config_dword(struct pci_dev *dev, int where, u32 *val)
-{
-	*val = 0xffffffff;
-	if (where & 3)
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	if (vr41xx_pci_config_access(dev, where) < 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
-
-	*val = readl(PCICONFDREG);
+	switch (size) {
+	case 1:
+		*val = (data >> ((where & 3) << 3)) & 0xffUL;
+		break;
+	case 2:
+		*val = (data >> ((where & 2) << 3)) & 0xffffUL;
+		break;
+	case 4:
+		*val = data;
+		break;
+	default:
+		return PCIBIOS_FUNC_NOT_SUPPORTED;
+	}
 
 	return PCIBIOS_SUCCESSFUL;
 }
 
-static int vr41xx_pci_write_config_byte(struct pci_dev *dev, int where, u8 val)
+static int vr41xx_pci_config_write(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val)
 {
 	u32 data;
 	int shift;
 
-	if (vr41xx_pci_config_access(dev, where) < 0)
+	if (vr41xx_pci_config_access(bus->number, devfn, where) < 0)
 		return PCIBIOS_DEVICE_NOT_FOUND;
 
 	data = readl(PCICONFDREG);
-	shift = (where & 3) << 3;
-	data &= ~(0xff << shift);
-	data |= (((u32)val) << shift);
 
-	writel(data, PCICONFDREG);
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-static int vr41xx_pci_write_config_word(struct pci_dev *dev, int where, u16 val)
-{
-	u32 data;
-	int shift;
-
-	if (where & 1)
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	if (vr41xx_pci_config_access(dev, where) < 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
+	switch (size) {
+	case 1:
+		shift = (where & 3) << 3;
+		data &= ~(0xff << shift);
+		data |= ((val & 0xff) << shift);
+		break;
+	case 2:
+		shift = (where & 2) << 3;
+		data &= ~(0xffff << shift);
+		data |= ((val & 0xffff) << shift);
+		break;
+	case 4:
+		data = val;
+		break;
+	default:
+		return PCIBIOS_FUNC_NOT_SUPPORTED;
+	}
 
-	data = readl(PCICONFDREG);
-	shift = (where & 2) << 3;
-	data &= ~(0xffff << shift);
-	data |= (((u32)val) << shift);
 	writel(data, PCICONFDREG);
 
 	return PCIBIOS_SUCCESSFUL;
 }
 
-static int vr41xx_pci_write_config_dword(struct pci_dev *dev, int where, u32 val)
-{
-	if (where & 3)
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	if (vr41xx_pci_config_access(dev, where) < 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
-
-	writel(val, PCICONFDREG);
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
 struct pci_ops vr41xx_pci_ops = {
-	vr41xx_pci_read_config_byte,
-	vr41xx_pci_read_config_word,
-	vr41xx_pci_read_config_dword,
-	vr41xx_pci_write_config_byte,
-	vr41xx_pci_write_config_word,
-	vr41xx_pci_write_config_dword
+	.read	= vr41xx_pci_config_read,
+	.write	= vr41xx_pci_config_write,
 };
 
 void __init vr41xx_pciu_init(struct vr41xx_pci_address_map *map)

--Multipart_Fri__8_Nov_2002_16:01:09_+0900_08359028--

From tor@spacetec.no Fri Nov  8 10:15:08 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 10:15:09 +0100 (CET)
Received: from firewall.spacetec.no ([192.51.5.5]:19153 "EHLO
	pallas.spacetec.no") by linux-mips.org with ESMTP
	id <S1122165AbSKHJPI>; Fri, 8 Nov 2002 10:15:08 +0100
Received: (from tor@localhost)
	by pallas.spacetec.no (8.9.1a/8.9.1) id KAA14181;
	Fri, 8 Nov 2002 10:14:55 +0100
Message-Id: <200211080914.KAA14181@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Fri, 8 Nov 2002 10:14:53 +0100
In-Reply-To: Daniel Jacobowitz <dan@debian.org>
       "Re: SEGEV defines" (Nov  7, 23:11)
X-Mailer: Mail User's Shell (7.2.6 beta(4) 03/19/98)
To: Daniel Jacobowitz <dan@debian.org>
Subject: Re: SEGEV defines
Cc: linux-mips@linux-mips.org, george@mvista.com,
	Bradley Bozarth <bbozarth@cisco.com>
Return-Path: <tor@spacetec.no>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 609
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tor@spacetec.no
Precedence: bulk
X-list: linux-mips

On Nov 7, 23:11, Daniel Jacobowitz wrote:
>Presumably they match IRIX... like the rest of MIPS's oddball
>definitions.  A little hard to change them now.

FWIW: You are correct, those values come from IRIX.

>On Thu, Nov 07, 2002 at 12:33:55PM -0800, Bradley Bozarth wrote:
>> Can these be changed?
>> 
>> > Now a question, why does mips use these values:
>> >  #define SIGEV_SIGNAL   129     /* notify via signal */
>> >  #define SIGEV_CALLBACK 130     /* ??? */
>> >  #define SIGEV_THREAD   131     /* deliver via thread
>> > creation */
>> >
>> > It is the only platform that adds anything to the simple
>> > 1,2,3 values used on other platforms.  The reason I ask, is
>> > that I would like to change them to conform to all the
>> > others.

From macro@ds2.pg.gda.pl Fri Nov  8 13:25:05 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 13:25:06 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:57041 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1122165AbSKHMZF>; Fri, 8 Nov 2002 13:25:05 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA03741;
	Fri, 8 Nov 2002 13:25:26 +0100 (MET)
Date: Fri, 8 Nov 2002 13:25:26 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Jun Sun <jsun@mvista.com>
cc: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
Subject: Re: make xmenuconfig is broken
In-Reply-To: <20021107142304.B27505@mvista.com>
Message-ID: <Pine.GSO.3.96.1021108132207.3217C-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: 610
X-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 Thu, 7 Nov 2002, Jun Sun wrote:

> Yes, this patch takes care of DECSTATION part of the xconfig problem. 

 Thanks for testing.

> Now we still have IP22 config which needs to be fixed.  Any volunteers?

 Renaming CONFIG_SERIAL_CONSOLE to CONFIG_SGI_SERIAL_CONSOLE where
appropriate should suffice.

  Maciej

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


From ralf@linux-mips.org Fri Nov  8 14:07:37 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 14:07:38 +0100 (CET)
Received: from p508B6A78.dip.t-dialin.net ([80.139.106.120]:33924 "EHLO
	p508B6A78.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122165AbSKHNHh>; Fri, 8 Nov 2002 14:07:37 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S868139AbSKHNGM>; Fri, 8 Nov 2002 14:06:12 +0100
Date: Fri, 8 Nov 2002 14:06:12 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: EV64120 anybody?
Message-ID: <20021108140612.A7615@bacchus.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-Accept-Language: de,en,fr
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: 611
X-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

Does anybody still care about support for the EV64120?  It's significant
time since I last received a report about this board.  As it is at least
the code in arch/mips/galileo-boards/ev64120/compressed is in a shape
such that I cannot merge it with Linus, so that means either somebody
who cares about this board is going to clean the code or I'm considering
to do the rm -rf thing ...

  Ralf

From Jon_Burgess@eur.3com.com Fri Nov  8 15:52:50 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 15:52:51 +0100 (CET)
Received: from ip-161-71-171-238.corp-eur.3com.com ([161.71.171.238]:2038 "EHLO
	columba.www.eur.3com.com") by linux-mips.org with ESMTP
	id <S1122165AbSKHOwu>; Fri, 8 Nov 2002 15:52:50 +0100
Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50])
	by columba.www.eur.3com.com  with ESMTP id gA8EsJRc025778;
	Fri, 8 Nov 2002 14:54:22 GMT
Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206])
	by toucana.eur.3com.com  with SMTP id gA8Ermk08021;
	Fri, 8 Nov 2002 14:53:48 GMT
Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 80256C6B.0051C789 ; Fri, 8 Nov 2002 14:53:14 +0000
X-Lotus-FromDomain: 3COM
From: "Jon Burgess" <Jon_Burgess@eur.3com.com>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Message-ID: <80256C6B.0051C5D4.00@notesmta.eur.3com.com>
Date: Fri, 8 Nov 2002 14:52:25 +0000
Subject: Re: EV64120 anybody?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Return-Path: <Jon_Burgess@eur.3com.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: 612
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jon_Burgess@eur.3com.com
Precedence: bulk
X-list: linux-mips



Ralf wrote:
> Does anybody still care about support for the EV64120?
> It's significant time since I last received a report about
> this board.  As it is at least the code in
> arch/mips/galileo-boards/ev64120/compressed is in a shape
> such that I cannot merge it with Linus, so that means
> either somebody who cares about this board is going
> to clean the code or I'm considering to do the rm -rf
> thing ...

I copied the approach in ev64120/compressed to implement a
compressed kernel in a product based on a different chip. Having
a compressed kernel image is fairly crucial for use in an
embedded system.

I think this is the only example of support for a compressed
kernel image in the linux-mips.org code. There was the start of
some more generic support in the SF tree but I haven't
looked at it recently.

Is the problem that the code is not generic, or are there some
other issues?

I cleaned up the code a bit to get it compile with the latest
tools when I copied it, but it is still not generic enough.

The misc.c #include "../../../../../lib/inflate.c' is a nasty
piece of coding.

     Jon



From dan@embeddededge.com Fri Nov  8 16:18:07 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 16:18:07 +0100 (CET)
Received: from x1000-57.tellink.net ([63.161.110.249]:42734 "EHLO
	tibook.netx4.com") by linux-mips.org with ESMTP id <S1122165AbSKHPSH>;
	Fri, 8 Nov 2002 16:18:07 +0100
Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1])
	by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id gA8FHMt00686;
	Fri, 8 Nov 2002 10:17:22 -0500
Message-ID: <3DCBD582.200@embeddededge.com>
Date: Fri, 08 Nov 2002 10:17:22 -0500
From: Dan Malek <dan@embeddededge.com>
Organization: Embedded Edge, LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Burgess <Jon_Burgess@eur.3com.com>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: EV64120 anybody?
References: <80256C6B.0051C5D4.00@notesmta.eur.3com.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@embeddededge.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: 613
X-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@embeddededge.com
Precedence: bulk
X-list: linux-mips

Jon Burgess wrote:

> I think this is the only example of support for a compressed
> kernel image in the linux-mips.org code. There was the start of
> some more generic support in the SF tree but I haven't
> looked at it recently.

I've been doing lots of compressed kernel/initrd work recently
in the Alchemy Au1xxx kernels.  It's part of the SF stuff I'd
like to get into Ralf's tree one of these days so we stop having
different source pools.  IMHO, the MIPS initrd stuff is quite
broken, works only in a few very specific cases.  I have a more
generic version in the SF tree that would be nice to move forward
someday as well.

Most of this work was taken from the PowerPC and ARM versions
of compressing kernels and using initrd, so it looks familiar
to others that may venture out of MIPS-land. :-)

Thanks.


	-- Dan


From ralf@linux-mips.org Fri Nov  8 18:37:34 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 18:37:35 +0100 (CET)
Received: from p508B6A78.dip.t-dialin.net ([80.139.106.120]:38277 "EHLO
	p508B6A78.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122165AbSKHRhe>; Fri, 8 Nov 2002 18:37:34 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S868139AbSKHRft>; Fri, 8 Nov 2002 18:35:49 +0100
Date: Fri, 8 Nov 2002 18:35:49 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Jun Sun <jsun@mvista.com>,
	Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
Subject: Re: make xmenuconfig is broken
Message-ID: <20021108183549.A9711@bacchus.dhis.org>
References: <20021107142304.B27505@mvista.com> <Pine.GSO.3.96.1021108132207.3217C-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.5.1i
In-Reply-To: <Pine.GSO.3.96.1021108132207.3217C-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Nov 08, 2002 at 01:25:26PM +0100
X-Accept-Language: de,en,fr
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: 614
X-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, Nov 08, 2002 at 01:25:26PM +0100, Maciej W. Rozycki wrote:

> > Now we still have IP22 config which needs to be fixed.  Any volunteers?
> 
>  Renaming CONFIG_SERIAL_CONSOLE to CONFIG_SGI_SERIAL_CONSOLE where
> appropriate should suffice.

That's my part to fix, I guess.  However since not all SGI's are
using the Zilog 8530 for their serial interfaces I'll rename it
CONFIG_IP22_SERIAL_CONSOLE.

  Ralf

From macro@ds2.pg.gda.pl Fri Nov  8 19:29:52 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 19:29:52 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:25052 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1122165AbSKHS3w>; Fri, 8 Nov 2002 19:29:52 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA10834;
	Fri, 8 Nov 2002 19:30:15 +0100 (MET)
Date: Fri, 8 Nov 2002 19:30:15 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Jun Sun <jsun@mvista.com>,
	Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
Subject: Re: make xmenuconfig is broken
In-Reply-To: <20021108183549.A9711@bacchus.dhis.org>
Message-ID: <Pine.GSO.3.96.1021108192005.3217J-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: 615
X-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 Fri, 8 Nov 2002, Ralf Baechle wrote:

> >  Renaming CONFIG_SERIAL_CONSOLE to CONFIG_SGI_SERIAL_CONSOLE where
> > appropriate should suffice.
> 
> That's my part to fix, I guess.  However since not all SGI's are

 Yes, please -- I can do that myself, but it'd better be done by someone
familiar with SGI hardware, so that all details are handled right.

> using the Zilog 8530 for their serial interfaces I'll rename it
> CONFIG_IP22_SERIAL_CONSOLE.

 Well, the name of a variable doesn't matter (as my analysis professor
used to say). ;-)

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


From ralf@linux-mips.org Fri Nov  8 20:33:48 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 20:33:49 +0100 (CET)
Received: from p508B6A78.dip.t-dialin.net ([80.139.106.120]:21126 "EHLO
	p508B6A78.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1123920AbSKHTds>; Fri, 8 Nov 2002 20:33:48 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S868139AbSKHTb6>; Fri, 8 Nov 2002 20:31:58 +0100
Date: Fri, 8 Nov 2002 20:31:58 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Jun Sun <jsun@mvista.com>,
	Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
Subject: Re: make xmenuconfig is broken
Message-ID: <20021108203158.A30956@bacchus.dhis.org>
References: <20021108183549.A9711@bacchus.dhis.org> <Pine.GSO.3.96.1021108192005.3217J-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.5.1i
In-Reply-To: <Pine.GSO.3.96.1021108192005.3217J-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Nov 08, 2002 at 07:30:15PM +0100
X-Accept-Language: de,en,fr
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: 616
X-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, Nov 08, 2002 at 07:30:15PM +0100, Maciej W. Rozycki wrote:

> > >  Renaming CONFIG_SERIAL_CONSOLE to CONFIG_SGI_SERIAL_CONSOLE where
> > > appropriate should suffice.
> > 
> > That's my part to fix, I guess.  However since not all SGI's are
> 
>  Yes, please -- I can do that myself, but it'd better be done by someone
> familiar with SGI hardware, so that all details are handled right.
> 
> > using the Zilog 8530 for their serial interfaces I'll rename it
> > CONFIG_IP22_SERIAL_CONSOLE.
> 
>  Well, the name of a variable doesn't matter (as my analysis professor
> used to say). ;-)

With no more generic stuff like CONFIG_SERIAL_CONSOLE in use by the Indy
code there will be less subtilities ...

  Ralf

From kwalker@broadcom.com Fri Nov  8 23:37:52 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Nov 2002 23:37:53 +0100 (CET)
Received: from mms1.broadcom.com ([63.70.210.58]:47890 "EHLO mms1.broadcom.com")
	by linux-mips.org with ESMTP id <S1123920AbSKHWhw>;
	Fri, 8 Nov 2002 23:37:52 +0100
Received: from 63.70.210.1mms1.broadcom.com with ESMTP (Broadcom MMS1
 SMTP Relay (MMS v5.0)); Fri, 08 Nov 2002 14:37:17 -0800
X-Server-Uuid: C4EEB3B0-84E7-41AF-B685-DDB6986D9F7C
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 OAA11216; Fri, 8 Nov 2002 14:37:39 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 gA8MbcER013067; Fri, 8 Nov 2002 14:37:38 -0800 (PST)
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 PAA02158; Fri, 8
 Nov 2002 15:37:38 -0800
Message-ID: <3DCC4AC2.EC7BD4E1@broadcom.com>
Date: Fri, 08 Nov 2002 15:37:38 -0800
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: 64-bit little endian semaphore bug
X-WSS-ID: 11D2E317282156-01-01
Content-Type: multipart/mixed;
 boundary=------------83C663DB61E0A3DB4B796614
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: 617
X-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.
--------------83C663DB61E0A3DB4B796614
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

In the 64-bit kernel, the semaphore structure (like the 32-bit kernel)
has waking and count fields swizzled so they line up the same in a
64-bit double word for either endian.  However, the semaphore-helper.h
function waking_non_zero_interruptible still has specialized code for
little-endian manipulation of the fields as though they are swapped.

Patch is attached, and fixes a pipe deadlock I was seeing (both the
reader and writer were down'ing the semaphore).

patch is against 2.5, but should be clean against 2.4 also.

Kip
--------------83C663DB61E0A3DB4B796614
Content-Type: text/plain;
 charset=us-ascii;
 name=semhelp.patch
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename=semhelp.patch

Index: include/asm-mips64/semaphore-helper.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/semaphore-helper.h,v
retrieving revision 1.10
diff -u -r1.10 semaphore-helper.h
--- include/asm-mips64/semaphore-helper.h	19 Aug 2002 23:25:28 -0000	1.10
+++ include/asm-mips64/semaphore-helper.h	8 Nov 2002 22:32:46 -0000
@@ -66,8 +66,6 @@
 {
 	long ret, tmp;
 
-#ifdef __MIPSEB__
-
         __asm__ __volatile__(
 	".set\tpush\t\t\t# waking_non_zero_interruptible\n\t"
 	".set\tnoat\n\t"
@@ -87,38 +85,6 @@
 	".set\tpop"
 	: "=&r" (ret), "=&r" (tmp), "=m" (*sem)
 	: "r" (signal_pending(tsk)), "i" (-EINTR));
-
-#elif defined(__MIPSEL__)
-
-	__asm__ __volatile__(
-	".set\tpush\t\t\t# waking_non_zero_interruptible\n\t"
-	".set\t	noat\n"
-	"0:\tlld\t%1, %2\n\t"
-	"li\t%0, 0\n\t"
-	"blez\t%1, 1f\n\t"
-	"dli\t$1, 0x0000000100000000\n\t"
-	"dsubu\t%1, %1, $1\n\t"
-	"li\t%0, 1\n\t"
-	"b\t2f\n"
-	"1:\tbeqz\t%3, 2f\n\t"
-	"li\t%0, %4\n\t"
-	/*
-	 * It would be nice to assume that sem->count
-	 * is != -1, but we will guard against that case
-	 */
-	"daddiu\t$1, %1, 1\n\t"
-	"dsll32\t$1, $1, 0\n\t"
-	"dsrl32\t$1, $1, 0\n\t"
-	"dsrl32\t%1, %1, 0\n\t"
-	"dsll32\t%1, %1, 0\n\t"
-	"or\t%1, %1, $1\n"
-	"2:\tscd\t%1, %2\n\t"
-	"beqz\t	%1, 0b\n\t"
-	".set\tpop"
-	: "=&r" (ret), "=&r" (tmp), "=m" (*sem)
-	: "r" (signal_pending(tsk)), "i" (-EINTR));
-
-#endif
 
 	return ret;
 }

--------------83C663DB61E0A3DB4B796614--


From ralf@linux-mips.org Sat Nov  9 20:45:45 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Nov 2002 20:45:46 +0100 (CET)
Received: from p508B502B.dip.t-dialin.net ([80.139.80.43]:52633 "EHLO
	p508B502B.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122117AbSKITpp>; Sat, 9 Nov 2002 20:45:45 +0100
Received: (ralf@3ffe:8260:2020:2::20) by ralf.linux-mips.org
	id <S868139AbSKITmN>; Sat, 9 Nov 2002 20:42:13 +0100
Date: Sat, 9 Nov 2002 20:42:13 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Kip Walker <kwalker@broadcom.com>
Cc: linux-mips@linux-mips.org
Subject: Re: 64-bit little endian semaphore bug
Message-ID: <20021109204213.A13826@bacchus.dhis.org>
References: <3DCC4AC2.EC7BD4E1@broadcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DCC4AC2.EC7BD4E1@broadcom.com>; from kwalker@broadcom.com on Fri, Nov 08, 2002 at 03:37:38PM -0800
X-Accept-Language: de,en,fr
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: 618
X-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, Nov 08, 2002 at 03:37:38PM -0800, Kip Walker wrote:

> In the 64-bit kernel, the semaphore structure (like the 32-bit kernel)
> has waking and count fields swizzled so they line up the same in a
> 64-bit double word for either endian.  However, the semaphore-helper.h
> function waking_non_zero_interruptible still has specialized code for
> little-endian manipulation of the fields as though they are swapped.
> 
> Patch is attached, and fixes a pipe deadlock I was seeing (both the
> reader and writer were down'ing the semaphore).
> 
> patch is against 2.5, but should be clean against 2.4 also.

Patch is ok.  I tweaked it slightly to make the 2.4 and 2.5 versions
identical.

General request to everybody - cc me on all patches that you wish to
submit even if you're posting them to some list.

  Ralf

From brm@murphy.dk Mon Nov 11 21:28:42 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Nov 2002 21:28:43 +0100 (CET)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:48208 "EHLO
	brian.localnet") by linux-mips.org with ESMTP id <S1123966AbSKKU2m>;
	Mon, 11 Nov 2002 21:28:42 +0100
Received: from brm by brian.localnet with local (Exim 3.35 #1 (Debian))
	id 18BLAb-0005i7-00; Mon, 11 Nov 2002 21:28:29 +0100
To: linux-mips@linux-mips.org
Subject: [PATCH 2.4] explicit R5000 cpu controlled secondary cache support fix
Cc: ralf@linux-mips.org
Message-Id: <E18BLAb-0005i7-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Mon, 11 Nov 2002 21:28:29 +0100
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: 619
X-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,
	currently a MIPS board which has an R5000 cpu but does not
have a cpu controlled secondary cache will fail to build. This patch
fixes this by making an option which compiles secondary cache support
dependant on an explicit configure option and not on some hairy
heuristics.

Can you apply this Ralf? I have submitted a similar patch for 2.5
directly to you.

/Brian


Index: arch/mips/config-shared.in
===================================================================
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v
retrieving revision 1.1.2.29
diff -u -r1.1.2.29 config-shared.in
--- arch/mips/config-shared.in	8 Nov 2002 01:39:44 -0000	1.1.2.29
+++ arch/mips/config-shared.in	11 Nov 2002 20:22:23 -0000
@@ -226,7 +226,6 @@
    define_bool CONFIG_SCSI n
 fi
 if [ "$CONFIG_LASAT" = "y" ]; then
-   define_bool CONFIG_BOARD_SCACHE y
    define_bool CONFIG_PCI y
    define_bool CONFIG_NONCOHERENT_IO y
    define_bool CONFIG_NEW_TIME_C y
@@ -464,6 +463,14 @@
 	 R10000	CONFIG_CPU_R10000 \
 	 RM7000	CONFIG_CPU_RM7000 \
 	 SB1	CONFIG_CPU_SB1" R4x00
+
+if [ "$CONFIG_CPU_R5000" = "y" -o "$CONFIG_CPU_NEVADA" = "y" ]; then
+   bool '  R5000 CPU controlled secondary cache' CONFIG_R5000_CPU_SCACHE
+fi
+
+if [ "$CONFIG_R5000_CPU_SCACHE" = "y" ]; then
+   define_bool CONFIG_BOARD_SCACHE y
+fi
 
 if [ "$CONFIG_SMP_CAPABLE" = "y" ]; then
    bool '  Multi-Processing support' CONFIG_SMP
Index: arch/mips/mm/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/Makefile,v
retrieving revision 1.27.2.3
diff -u -r1.27.2.3 Makefile
--- arch/mips/mm/Makefile	2 Oct 2002 13:08:16 -0000	1.27.2.3
+++ arch/mips/mm/Makefile	11 Nov 2002 20:22:24 -0000
@@ -20,16 +20,16 @@
 obj-$(CONFIG_CPU_R4300)		+= pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o
 obj-$(CONFIG_CPU_R4X00)		+= pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o
 obj-$(CONFIG_CPU_VR41XX)	+= pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o
-obj-$(CONFIG_CPU_R5000)		+= pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o \
-				   r5k-sc.o
-obj-$(CONFIG_CPU_NEVADA)	+= pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o \
-				   r5k-sc.o
+obj-$(CONFIG_CPU_R5000)		+= pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o
+obj-$(CONFIG_CPU_NEVADA)	+= pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o
 obj-$(CONFIG_CPU_R5432)		+= pg-r5432.o c-r5432.o tlb-r4k.o tlbex-r4k.o
 obj-$(CONFIG_CPU_RM7000)	+= pg-rm7k.o c-rm7k.o tlb-r4k.o tlbex-r4k.o
 obj-$(CONFIG_CPU_R10000)	+= pg-andes.o c-andes.o tlb-r4k.o tlbex-r4k.o
 obj-$(CONFIG_CPU_MIPS32)	+= pg-mips32.o c-mips32.o tlb-r4k.o tlbex-r4k.o
 obj-$(CONFIG_CPU_MIPS64)	+= pg-mips32.o c-mips32.o tlb-r4k.o tlbex-r4k.o
 obj-$(CONFIG_CPU_SB1)		+= pg-sb1.o c-sb1.o tlb-sb1.o tlbex-r4k.o
+
+obj-$(CONFIG_R5000_CPU_SCACHE)	+= r5k-sc.o
 
 obj-$(CONFIG_SB1_CACHE_ERROR)	+= cex-sb1.o cerr-sb1.o
 
Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.3.2.10
diff -u -r1.3.2.10 c-r4k.c
--- arch/mips/mm/c-r4k.c	17 Oct 2002 11:49:09 -0000	1.3.2.10
+++ arch/mips/mm/c-r4k.c	11 Nov 2002 20:22:25 -0000
@@ -1356,7 +1356,7 @@
 	case CPU_R5000:
 	case CPU_NEVADA:
 			setup_noscache_funcs();
-#if defined(CONFIG_CPU_R5000) || defined(CONFIG_CPU_NEVADA)
+#if defined(CONFIG_R5000_CPU_SCACHE)
 			r5k_sc_init();
 #endif
 			break;

From dennisn@pe.net Mon Nov 11 21:50:51 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Nov 2002 21:50:52 +0100 (CET)
Received: from shell1.pe.net ([64.38.64.7]:60293 "EHLO shell1.pe.net")
	by linux-mips.org with ESMTP id <S1123966AbSKKUuv>;
	Mon, 11 Nov 2002 21:50:51 +0100
Received: from localhost (dennisn@localhost)
	by shell1.pe.net (8.11.6/8.11.3) with SMTP id gABKodX06268
	for <linux-mips@linux-mips.org>; Mon, 11 Nov 2002 12:50:40 -0800 (PST)
Date: Mon, 11 Nov 2002 12:50:39 -0800 (PST)
From: Dennis Newbold <dennisn@pe.net>
X-Sender: dennisn@shell1
Reply-To: Dennis Newbold <dennisn@pe.net>
To: linux-mips@linux-mips.org
Subject: Error Building gcc from sources
Message-ID: <Pine.GSO.3.96.1021111123638.5916D-101000@shell1>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1037047839=:6253"
Return-Path: <dennisn@pe.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: 620
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dennisn@pe.net
Precedence: bulk
X-list: linux-mips

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-851401618-1037047839=:6253
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dear Linux-mips list members:

     I'm trying to build gcc 3.2 from the sources.  It ran for quite
awhile, and then on a particular file, it got the following error:

/tmp/cc2kTG1e.s: Assembler messages:
/tmp/cc2kTG1e.s:1080: Error: Can not represent BFD_RELOC_32_PCREL relocation in
this object file format

from the gas assembler.  I'm hoping that someone on this list that
understands gcc and mips assembler better than I can suggest a
command-line switch or some other way to get gcc to generate code which
does not result in this error.

Details:  source file, and assembler output file are in the attached zip
file.  Command line used to invoke gcc is:

./xgcc -B./ -B/stuff/mipsel-pc-linux-gnu/bin/ -isystem /stuff/mipsel-pc-linux-gn
u/include -isystem /stuff/mipsel-pc-linux-gnu/sys-include -O2  -DIN_GCC    -W -W
all -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include
 -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I.
./../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
  -DL_divdi3 -c ../../gcc/gcc/libgcc2.c -fexceptions -fnon-call-exceptions -o li
bgcc/./_divdi3.o

Assembly output file was produced using the above command line, replacing
"-c" with "-S", and "_divdi3.o" with "_divdi3.s"

I'm building it with  gcc 2.95.3 and GNU make vers. 3.75 on a Linux-mips
system. The configure script says that the cpu type is
mipsel-pc-linux-gnu.  In any case, the processor is the QED (now
PMC-Sierra) RM5230.

Please send any replies directly to me (dennisn@pe.net), as I'm not
subscribed to the mailing list.  Thanks alot.

Dennis Newbold
dennisn@pe.net




---559023410-851401618-1037047839=:6253
Content-Type: APPLICATION/ZIP; name="_divdi3.zip"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.3.96.1021111125039.6253A@shell1>
Content-Description: 

UEsDBBQAAAAIAONlay1SFP+OsysAAHilAAAJAAAAbGliZ2NjMi5j7Dxrc9u2
lp+t6Y9A25lWciRFUtreZh17x4mcRLOOnbXsTXL37nJBEpK44UMmSMlqm/vb
95wDgAQlysqryaaTSUYmQDzOGwfA4bm7z54lqWAyd9Mkz4JYSBYL4QufuSv2
5NEjBrXzPGNe4guWxEwmkWAR92bYtMvY/t3G3X32KInmQShYNgsktBJsGWQz
NvU8q8V8lQbTWcaaj1qsf//X+234vT+g33v0+xP9/ky/v9Dv3+j3V/q9324w
xga9Xq+Nv336HTD2OBWCjZNJtuSAx+Mkj32eBUncZqPY6zYalwjSBIGDv3Oe
ZiyZIGLwCtHDlziC1CMcsFWSM4/HLBV+ILM0cPMM+maMx/7dJGVR4geTFVbA
TCJtZDNAW6SRxHGx8OTsij0RsUh5yJ7nbhh47DTwRCwF4wAB1siZoi82R/gb
NfAfMAE0FClbiFRCmQGpYPomzxDClCVzbNUCsFYs5ABBQzcExEYx474fYAOW
JTTNHEAMJL6XLIh3ANrG941tlGXTYAFignTK4zCIggywKcfHGcMgfk1jeEow
/AILIlLBkRjaQhM3iGlkqeQmIbznaTJNeSTbDaA8DmqxI5slQM6NniCrRI9U
YEuPgIVGQTxtTNIkIqxz6GgDARLavERq1LPMGko2/ITx+TxcIQUVkPB6LrxM
HrAJMEfc8GgeKvKtYGZAWslL4CnKJROSF5y3jQJV4oRvlzMRszjJiHxAMyIP
12iKhrgRXp5xF2BuFcJbEsU3fJ0lc6QQCAoI6TIIQ+YS2pM8bDNoyV6MLp+e
X12y47NXjRfHFxfHZ5evDgoCioVQ4wSASwDDAvtTHmcrJNuzk4tHT6H98cPR
6ejyFUhk4/Ho8uxkPGaPzy/YMXt+fHE5enR1enzBnl9dPD8fnwCBx0LskLjG
hFQL5MwXGQ9CCVL8CgRMAkihz2Z8gazwBEieTySZr3brW4OHSTxVMgXkOmBS
w0HC9+j8+avR2RMAbzRBqrfZMg1QtpJb9bLNfr7PLgXymT0PuSdYh41z7Hjv
Hpimh4nMsNGz40Zv0O/3O/17PTBjV+NjZQrRFo4y5FwQe0kKOGU4IxTC3EeR
jifBtDtjIFwgIq7wOApsZhsxV6BAgzEslAuJR3aIp1ORKckCWfKQmpMgDpSG
wNieSGPoDCY6XGlZkRkOBZKNgkfSrQH93sD0XWag+s6ulCuZiQgrEadhEv+Y
kXL9z4TH3srhbpJmPxIeSqSCSYmd5CuJaGP7IFMTfh9MAFpG/Rrfo3EtCiIG
HbIhCgMXFpcBTv6N6Tg8eQRSd+Kcjh5eHF+8ci5Ozo6fnYwBu21vynEnilBA
yuapE4upHwxajeGLbDUXDUdXsKaqYHmr8TuO+iKPSWsPrEKeHzSgmOddULtD
pkrLruyGyRLKHXhBzwe6egZLYlFPhQ5rNq9oolbR8Yj1WjRSKrI8hSlh9IPG
GxsBpMCpA1Z/IYN7DQO5LrOmgpy3mXpwFQqqsFRAAhic3WEulYAiTZcdHbIe
+1d49QBe/QtDQHgLxUUxhjWrUFkgfVOFyQeYhjZQPgI1LKAaVsAafhK4wOWp
0EqX62m1QeFidIvI0KXZcVsw+fciBPNTi0mnHpMjjcmDHZhoPLYhVCG0rthG
6A0OFfN8bkyiPKywRpe3iXENbPsWbM0mJ+ha7PDQQNpqafnpafnpvbP8gFUA
oAYNy0pguQCyTsVQ1XkBGLeJ1tNEqwPkLSABA1UxWAvbYvFaOr0nMDu03ZUV
quhyPVWQVRYANN8GfREAbGlRmFuCqV5aiNTCbSzlTloivBVa6opttPwcKNyO
ASpLxQzoinL9KszAYov+5KA/C0t/ckt/Fh+oP+gsXMWhkBKcu2CSsUkeK/ea
8VQU6/Byhl4buKwhuKnjEe4GsgTBlLQPhI0cjwTsephbuLjQJErQDyZ/KkPY
l0nqO4Qc+E0y4mEo0FOC3R38hzYVz+PUCeUsrZBOV9ikK4d0a/wA621U4xco
U3l4aMilKVTnNLgRPDZl8JsAP7epHYJ99nB0OXaen1w4V2ejy5aywXrciD0o
Bv6dfis+Ru/AqlPuSOFolO7H0RHrKNAZewO/hYiaEVUX2CGnaQC7wNpBHjwg
9DdhqJ/QrYGs2pKcIGjYYn+YmQ2Ib+MVyVlY9UBUxZfNVkWoCldrqYztgCEf
xFVD/ypT64RIz+bWgbVFUt6bqek6U79sXQXDaFGr3+328cCn1+320EhtkLOi
Qjsmh7n7rU0t+1Rq/wm03VoAJxNZWcFVedv2DbldoIci0YZtah7jLtr313mt
uFcA+W3BQ+xoEIU31NloJ9Ky7EdkqO+Ir0zPKvv2WZW/BzaLNEF6BCzB7mQp
D0LY6Du/iTSRrKkxwsmor+5C1bC3winvsP5Wf2LdndjhTdTui9tssaiSExfy
xUIVFnqjTAXHyWESGdA0JUmhLT21KpvnO7Xis1/KJ3XDpo09JXeAao3wrvdQ
E90ub6xpHRvkfoBuFgjtH/ZpglX7DyX4dp8o8Wv66NpW9WQCpHjhXKdx7MML
VcvUtM7SwZcGtg1bWWmzdchPgI/MeBZ44HmFCDzY7EwfXjoOcBHK4ZKvpKPe
Ow5SQOFyZaTPQsUwjO2n87bRYN4vH3vFo69EU5eu2yy1lN6Ddh50c/uly6sl
wVfObsUSkqPfB9fXB6sKDx0o9sgGv3AuXz0/ccajv5+QwQXw935HqQPLDvAG
PuDSpieZpOqU7jpPskCAEqLvGycx7A+AQguBFh86lvxhTYS6TfghYqjHe280
SGQKiqnwMgYPyb3+/uC/7w1A3L0eblOKIoDbYfDc3/fNPLnr+H4USbQVMAOS
pJgJcevjX7Dvmzge6FmHhCB2L2dt4SWHvxUXM5NfDHIMhggBQxe+II3qfk2a
blS0XwtMQZLaJcztAxUUNgd7e3vIlLsDPGPNlkLEOG+PeEIAwHDlquv1iX52
1+O7A+s90peEoo5CaG+UhPRbxepYSJHbb+kRoYCU23eBLDKhGR4oNrkEi2Lw
djLCSAdIxCb0bLG7oMz4F49yoVsKEA72Uw3LDwgKzXohIh7gRRajG5Lju00E
oKWJTrrgU3O9Zu0piu6VWKSoI9fwZg/nSAHn6wPzvlj6rqE6RZ/Hx4bQX4NE
zQEoWGmx6rrTwYc3dv/a9oN904N1ADGr05uqWtDsXoXQ40SxGKAhUt11+5r0
JZWJ402X5AA9N69POBGj/+n1tBCEyTTweMjOzi8Nnd+TPdc47rUetoBKMSGt
ggKm6zaG2hz8a7BwT1FlRNdRUrHGaIR+95QuO7hScFRdpI1baLEmAyrhIev4
6yRA4nf6BcYIJDRVGGl4DB6b/Qab/RRmFUzIc4V1CvG3HLBr5VHg0IjhxBYf
PxES71TETSDBd9MLvp9H0YpV1kF1iLFrhaxZbfM4l8LHZbZd+EbFMvqO7Xvv
1t6/tblarUu/9s2aZ/OJnK+Kj0XVP236Vl74W8NLYpmxq38fEW4O1jkZd//z
v9ghYdJr99sD+HdP//tp7d/PO/7BEL+0P+wfDPG39of9+zhD/Nr+sH9/nSHe
HNR76lrS/p875EPb3iiQwdzorWAMnrd+9MtHsEJrW8TKHjGGXrjlLmtS2033
0VOEtTSGvzH+HVgvr6Hyum9VuG1zFhHHalcZ41vfVwW1s/dxOYeq4krW75sK
3BNiTYxNYIiiSdw3FaoJsenbq+HoP5yzk5Ph2Dk7v3h2fDr6+/Hl6PxM7ydw
3NqNBEBwBENaG4XeNY0PDkJvaNbw3HYqehYJkCQ95T1f99V5gx6m9OsCoGxP
rRFbNgzXOOXZGU7p224Dkqf0GIhYfWjkg/tTOvxBnIGTDtziYbhCfx+PHHQI
wTrofQW2ht5AvhO7HShZ5IRlTvs4hFuaFkdMce+gqCkPxPeKRTml7X25WtOi
jLNu4ywh+FG4q45sQsF968TGjSzk9ZFhnfsGY54lacTD4DfRZkFXdFnEX6sw
lyiBVUkG05gCkGAn5QaZjppBxwu2oxgbxbMkZVJkJc8KbsOPPtPTtST8zbiv
qvF8rhnX7X3hXavsRCpUHerNR5JrdSr92aT7rVl3WM+6x7jnQnoeIbFhV/AP
1ryNcwAlXmSJDD2qPYrooYCYWzvB8LqTGR/7aqDLbbYfTKE9kbvf6jawDcVO
YoBbAJscj0u6RouFJ6Tk6aqtQoZiCkWMgt8oPKqL/ZpjvNmTijwUGGmLBx51
UHgPrkbdVkXsANYOkqIQHgXPDkfcVoKqGLvQe100D3YJ+QDlta/PqndJvrtV
0E11nQmMB1UbaDQCMIE5vkWout0tVvTtTeSadryloTQ3Pe9gLpVT8BbmcuNQ
RtvPdTPZM2ZyWJjJ614BxK02oV8sDeuoVmRmc20oajXCcbklrGKtRbHe3PQK
c+P7u81EX7H/HaxE/y2sRP+jWYl160A8wGupDzERFQ0F/DD8FoDUAcuJij6N
xQ0FwmJU42vY9nN/AdDyqY7e5RnObmgC8KY5bo4pfFNHDrMJnuEXsmCkDftg
F/CI4542vMUBBSHYV+cS9qFo3F9TukJ3N046jJxWLJhVrsqkORhZk8a9GlHc
0D7rvKTWLGpXOAJYo1LE39tYkgX0bQvor1vAz2BQe2sGtV92x1skZz6PQHkU
Ddq0TygMpuFGpOwPSgQ+HxKwP/wAHbC+17LFQ51uVYXDDG7+VoRjmxis260m
Gi4gedSPwBGwDfctYnObiCpoWgfr8mVobpM8atXJXLEQ3CZ51vnWsrzRvaab
z6V1B6x2Z+Yybeu1vtrNlreNqrz9trG8xPfMfev6neNagFPlOrd6/1i9pC1i
sDw69KW4o6J3hx7MjXBxx1jfyczSoYcizKq6d6YB26ptu9xK77co+FfN4+lL
YxxruS3Gyrq6pW2+dXVL5S+QmDUEbC6SwG/dSsMflu9LOH1sYp9yGNpdlcS7
qlLvqkKZevgANg3XThC0JlQPWiog2KcslSPT6qR4rLIpUHVX/V40x8iJQgxg
UlV1W6y2kg+e47clhBbXXOVYox7LYFxuSYRrnisBNtWYibL90Zb2A8Pj4nKQ
F4FI5YWhq+tumWqz/9GO/gPLpPXruVhD0vxj07QKuCZuFfIdVK4ZYR33L4Hu
39jRDc1TZxLc5LHMJn7QwvW8eTp6+OTRo4Fzen72xBmeXz08PbHcHVj3+4Nf
y3P/F+cXQ/VmV2hX0eXp6MlTh/o9Oj95/BhjZ7XatfD+DZbdYtBWw4pQ0nAO
R6x5+dgOM9YlipkqzM16vHGVso1KEADxkoKMAP5UyDzEyCZwp9E7jnPtYyjf
D8a7u44CWVAaL16INFPflYGPDSDjUTJ+ToYuPtQo6L5tKdNON+kqwBf2DfQl
G31vZMAx8y7sUDJCcwFkOizppOcHXylZ6P70FWfxQZ8iURsPNBZ4oIF1KETU
CjCt4snxfEETubV4Z+QILQyXIqS6CtVxEgnY3sAm5Ri/yYK/+B2dCeWAmWmT
hPukctvVhkLsqb0wdJsBoPT5G+zGpI5QZvT1GkYy41WgQWCN7wvCxxCw2WG8
Ghy2qIRNcEtxFmsGq6o376o0tixj33VBrhfXDqsKf4fb4WnVd7x1K8DQ7ubt
Yb7/y+fT8xtC52WFPC+/6vkuPX/5Hnr+8que79Dzd9QZW5RvSM1fvpOa39yi
5jf1aq6DeqmJD1N+Nr31Cb5hBd/hV73dpbfD99Db4Ve93dDbQg9ICWzZ9EkR
h++kiP4tiujvVkT5ORVREnxjhW+SBtMg5qGjEa+Ii2C6FSVSMJJYflXP6Ut8
maciXJEoTRP9bT2jNBaYZQITSiDXu0qQmM9XlAUF05zQHgaThajUAaC0XGZl
zg49EE7D8TiAvsFH0EgPkgIgFFqo1nlFUkGXjaCFryWjnClGtgyLQSdLtA++
mqE/2Qyxr3aozgzIdTskyQ6N38kOyVvskNzt94cJz/zgZvIJ3f6nx6ePb7Vc
zXLku2zQel+jpxwrpKxBcv0TJu166Vgm1BDD3hyP7svBKLSJ7R/WIbD7nS0Y
MDLQeR0R/SFAyUF/J8uyt2XZRzmS+VQ8u1zjWbbBs8svhmdazxUi/uSL4cFw
jQf+Bg+GXyYP5JfDA9NrOFqDcrgLzOFj1WP48NR5dnx26QxHT4qXY/3y8ell
+bIxXmO43GA45SeiFd/joZeHKhlXEMNsUeLrxVUmal1fgmRQMqPC+9OJpuap
8IIyiZnlpagBljNM0BSB6xTMwxX6GMG65zYxftfzNMkw9ROf8gBjx/0kd0PR
STHNFPYUaZqk2m24EDCzpI/EMNdbsuzAlJj5AFyAtoI5osx6Lri0aR57XCcD
U9hpR8tdgaeAsR4KScLQRRdIZuR5kEtBvuwU0yfgXEtK3uQKdJMwHoTGKUCc
J1IHbEy0p42zddFLUX5RxOVr8oNwYNNaDQJ+ix9iUEcYslzmGDpCqaHyVGVz
w6RcWfEFhGqt+af9FZwVloYOjj0cEZ5sliwF+Ge2B2TE6YERRdUZlx7z6gha
jUzAg6m8Y2StZaI6jQxenDx3QHaZLf+kORuD6K4KkG/R52o2K11MO4Au19f8
AFeO1yf1DYsPCtW1iWlDtsXARTZlLRAEGhyyf1bblFES7I9Dg9XmZyuMTXYY
yMktRvD2d+9hILV32UJN2nUYLNXB1ls4hQ3aOYgYc+up4CMKkGE4FagYaANF
NlGuQ9mdUYZM9L6F3i/obGXejKfmWc6sNGbgm5tH9NXNM0AJjr7wTZnslyko
i2BKz0ZnxePxyzIT2gMD01Gj/ALIEGC8ccxcJPrplJsb6uXABBUPveA45t4q
m0DHomB57KY1v/XsTgZ/SUL7ROi645fPQ2j5VyW0JELX7S8Vocd/MqG/aZhg
TFoYYenzk2VM2T5ZkT0XD5Y0sX2ecUVxk1LR+DHqQzE3meZSRQWYN1fbXw23
d9r+ShOrbrjNN4obL+zCVaX0tPquWhxWX+rinylJVuSKM/U8x/WiOeWXOg1e
A2ZQYuLGE3N1Eojj4eFKJDjmwJzkIflXF3TYpaJW9bf3IFNjioalLFV0yDIe
qLRT5MXYTaapwOS7bdbTdejwjAcU5C6uwbPRrEc0SygxIwe6fQZLIg/bl/ip
cO2LQZsygDgZ/dHRWuRvkmtdJuAycdXVAeibWRj+zh2YYEDPgzt3Diz/xKOo
c28AroNJDoKfz3oD0winweBH4xbYX2dWFMRxwF8FdCeoCpSMS6WfNRmlf5Tg
SQcLoJqdFPgBl1KkGag9ceUFKhEJhMoETB9jkOc6E9xHeuOhG6VF1ZoHAGE0
JWU3VulBuxxHwtyomCU4XTGXe6+XPPUpcSqw2g3CIMN0p2dJVmbMRUlIMpOR
FR3pBh3iggQBKaupjPVE1SxiGn2s0BI+g6kyBxp7hT6cXZ2eUsYDPBdW7r5E
RkjYwCRgkFGMMM0zlKE5VESBjHjmzcxkxlzqDmAtcaRGSX0tYlqAMqicGulS
deIG9xWIivo8txAZPErEyOtqc0w/G/NIC9/EzALzA/QgnnoGa1Q9SNGRvL5J
mMuZ6UZVZc64UpI2ljbXbTRgihz2TK7rmJxxThBPEpJ5OgP1ZsJ7LXPKYxRQ
Ug3Podh7rLBxQXAO8ANMFNgxDZujwsLKkylB7XRA6hDyDgwiiebF9I1iQgzl
d3AHuD6BwRnrp16yUFGV++qDmAPTPS7LxeAAnLjJzD7xPMSdntIaHwQFJROh
RHmUmMhYhH5x5Etjqp020Ksy6hrF9itFqUhRL68oo6nHNDXw+/M5brEuwLgF
KW7hMnGjsqNr2dVL3Z8m5mUWYCRsB2u/qzREOcSWWnYujy+enFzCBmTswDbq
5PL0315YzSdenIWqtakCKGOaygghnvzPeEAaD8h3Evd/ce9O9ACGSSM/mhH6
m1qLo0B/NFtK3IZAQbWXxfzg+EGDkoIuGr1IpFOdPZ+++8eNtv6KCrOD6zVI
Bi5lGU/UtRIsQsnS3Gl0fU6Q4RcTwEpK/2zuNYyJAHj+r7hrb24iOeJ/W59i
cRUg2ZJjA7kQjEkZWz585wdliyMUd7XRY23rkHYVrYTPlSKfPf3r7nmtdmUB
VxVVgaWd2Xl09/RrumeANCYKDVRlmvaGPJlNzSoahkSs2RUxrTMTJLxYOO7+
YQqZKs1zXkwLb/GsB+UtalmxQX3stxcebVSC9oabIqkT/U9RHvNfXmz6fWsk
3e5FR/H7i5ODn3eDsls5Vnsvumy3f0azYTGhnliZjsc9Jl7ADzlBKp0NR1H7
/MisWldtMoQz8jqZ4Ut45CcnbaQtmXUECsv11G/caiDANQ3ieZ3whxhRJbwI
6IzkGf3fegUeEyoM/NZQhjmMXmo1ZVDRcHPT+B58/G9qc1Lt4/A3l/QYPicF
xSMN9U+ExFJsyOZXBbRjevRYp+gj3zzxo+OTdrQx6MZYNUbbcfQni92nv9Jy
j3bxYRrVInfAqVcBCwvYxLItPGYu6T+s5uLyZXFQImhiXcT46B+IlAlR41VW
uJnAnmWkgKD+rzLUFEQaedaM1qebvfVGoVnO4pMXCbduXjumXpgj1yFlDCPo
TiaJOBMlz+XevrvctTTCm/HZiFYDH0SfqxOUE85G6rKMHvceY56JTjYxPlXz
6cCSo6GAm9KgiKNyx+YuhOHM7MrCMYoEPma6YRtTXALg8tesHxm3OeCSjEEy
ShAcQKJumrT6bDA4f6r5yJ0Q9nYC69HFePRuB2TEiadTlN8kbYZt3NkbE+A2
1X5tk3o9xNVwSmrKBFcXBHmSDxwCV6KD7rp/BJnv6nQNMcIXVMX1rlUoCPcv
ooMuhsu96G0z3PPDfOvXdJ1TGKMo6F1oIHhkc0MJESQ15wmPbSWRoOti/wqR
G10Q5ieEZNhbSJDLqPhQGpmCEPQ+GI78cGhgOwHj4SnkQ2wHUFvznO9VuMz4
VGKOGSH1GDLIomeWuVZErIeEZdU8fNT2Y+2F/gAImVuCzcjMrxk9UvnScB5m
VnDg+Wwfn3UuqMDBTCWOkiT4qfIYwz8LimOkxa1XVteGHdnasSUsOIqcELan
RzHKMLwE4FPWg9iBwhEcelOLUCsz19l4EuMLI91xPjzGL35sSJsaHHevSSdz
6XT1OAYWuYmo/si01jR034ye8aEppkBm9eTpqOEl8DnODuXQaYVB4h6yClfo
jMm80GERbH7fxAySlO3QHtBLBtinIbHTwbf3fJUnySdLRM3IVWZl5+DdRaOw
s8BNs7h6YbcT7l3tbRZvRkZULviofNHj0ydGPKW2HcHffz6AEJRcoSPXArFS
zbf2dPs3FpUB6qwUDdUTOxA75+9ZKDJdf7VocqdSrmkoYjZHTH045iF+BSE7
iC5QtCtb6IrAfk12iNfX6gS1SMt1fGlAl4E2XLfgYNQGowAhqzuh0HmRQut1
28MmdqE3o6eN6FH036ceyVbPbwGU3zO91o6dxHWmIkKWxm6tFJvGV/Gn4dJC
1LQcTB2LUKjuT5rwIj1XA2CNefGaZ2Qsvg2r4xUbH61W0608WRBGUOhgHbuX
EeO3N+LnHj2VjsXm6ksdpy3DvPAkSJBgXyS+7aY1AksUIfgMNNYgMRewGccB
OwjItu8HIn1lA8yzOL7G/nKGjDLxwLKptL4823xzz+t7tyC/1UZ/GfYTWO+u
ZDdsvNqy8+H5nmNsM1F9WTfwwVci5+OYlTOlbUjvAlnLeSvzcY8UvezqfnFO
SyBssyigy9pXNkrtk8iedkWpoQ56dzPjMSpruv6M2Nlz/OMDZN2vsA/t5PYm
G1nvS0Bgx1dW1kqQsiNEFV8pDteeJlLKVwnqmALgIExlOh8nKRykQFj10E1/
/wgQGr0ILPkyUIHIsitZ/Mm0tAdv6btuvBXxwvdPBDxB+yDqG4454IQ7+do+
QMkvfM9F2Id2smSxF+G6bLICTh+I3w81B6vvh46DSZH7EqOS2p52uKJmiPeW
aoYlWqFxmexUHootzOMr9L9K3a+29t0KnwpwX+fD7+BM3gDcqg2FWhPAYZWB
cr3KQ4tR9RbIa0FvKDUOKt6xcwtewlsseD0aKFeav0EXWACO0KIT4iWawMJg
OFfg+G3UHuTYYTwc/v4pB3M2uv+XwnlZV32OBrQGx8q+DaFpvP1n0DSGIs8J
JQ+c2VziCpFZiOv43QRaSLWM+Ba/sdUx3L6gjJHgUnCprtXWVvUqri14onRR
rOJEgutvmnD7BVOy1JD0PEWM8BWcRWvf7ncp97z4o1Dfy5oAoahuPos2oqee
yinNriiiK4S0ql4LQmWpWFkmKkVRXBAsS0XLPe2VCJeVl918gjtb3faTBg/c
s/Qq1vvKvU4Ts9wf5tXdCE18wZ63XnzQjdLk1tc7o8zkQ/V62FceQjodp58z
XA7cnc+yMTYakSyG1tjfPJ2nfMFrN1BgH+fR9SjrAfizzKDS2wzEHqFuBvq7
liDf3IVZye/WK7vp7YdXmQ3rY9w2y2eL0VKSxuDoT/mG6Nbshl2nvu7OC175
jd4hJzvK9XCfsmF6uExmhFhzR/JomNsg64UBmh0IU8BnyjnuhhL5iodcZ1fx
cYCr4gZRj/cG2CUc8f3OST9qqR4NQ8TsikN+Tcd6O3YXjmPs0rFD96o7Vdd/
nnB8CaFUDxHljQVNDBzMJyN7S/QUYdnmQnHe813eDzpZQCoGfe8Obw1WUrgd
LGEa5bKAHTleGw0I6aW7a5KbZsjdyvzAMGgRliDx91TkG4HmrFdPotkYEeZ9
HKjjwhU4ZsCWImoET/wTjuA6jPuk8fGJ+wf4aW+F5zsBZXasIqJWIXLv+Ozy
LD7YP3jTjt+e7J9pEHHde6y5E96Tw/bbzpuGRY03hKgu0SK95Do8e7vq9HwN
3EkHy6p7d7senLT3L2I3FoJh8RGt6wRhO+nA3kipLxcmxdTDkQ08ClwKfvex
OPHNCggFz0+O6fH748POm992XascamC5x8BEH2RXJAk5gIf3RDZ4ix1X1k7t
Ixo7P0AlyA4Mvu5CXIiWGroG9Lju5fhyw0Nk/s4PythmxEUJZ90JrpDMxAnN
zFn0KqEWofO32DpEZmae8G1pRFu/I+rDo67c7hOCgZvgDULFkBm4tKOZFUIr
fM1lsdfZDYJdIu8w6gc+EAtHUhM4ZbHW63X60RAkViGHo+8hvB5FrXLwBLvW
hATLCcImJT833LlCpZfmJaNNbwAxnYt3BzgxloP0icVQudD/XvTTu9O38f6b
9v5h7FWsGr/ZJIRnqaqCUaxLe5ZRtqpoA1kTnXcXZ/5Y3LaWQ4LbBzf6OKRL
iG+D6jz59xwRJkakEaIKdPxVmIPWWYU8po06p1fYw84PmNIQ+Yqb5P+PdFVG
LGHTmlHGP++jnwpUrUIeq6DzaEgMWfLJ+za1TMbJKzzr9+cT8AG7OSwrmk+3
7ebR6/aPFtTC7hiUPF2Ihko4IWWmnN+a+x4dt/SwUy9BT+HdRfS4Cijc1IE2
igcJOH5F0LpOYYzY/DmEHIB15rNsIpzMMi9w5W09DFhy4CHakZVAAIfWcN3v
I3B4Pp2QXm5NVrk0h1eSbKYbvkwN9IbX1/a2Xx0TDSE1CXHYhbfcFIe8T3Xk
ch7D+dERmVloqDuC0npHhsuUVPuZr7hCEr9kHFUAs+HvqHu4VUTg/eWrxNiO
VSRgaiylBCP3ikpJ9CraoZEZ+RmxcmcJphL/0aYnlRUM8srLPY/ihEnYsnCZ
ueaYgkTfBHZkA0S+vlwYsZbAE1TkQDoDbwKb2sxGVcfuZSbJPW+w970aMih+
58EeN+NFMVg+r8HyvnZJfGH/8PDCmsFFRs8QlJu0qbQEgiVy7Ivj5L/Pc1p4
aWLmAYodZAHQ7h/gZWf/ohO7Ycp7xZF6GLcX1kcB66keuIzawtEnv4dFFYLv
L7Nsx6n5i1N1ZaFAKyvjMNu8UFLUkak0sDsCQ6JgYsym3fEkA29nS/InDvfF
8TOuAKE/cvsCSwSrVUNs0NST3CYMeYmN74/Pzjqc0fjAPovjgw8/UgGp/UEB
Gc/v3iP/qcY5NQgp7V4nnClijUEdcLx/8vbNflyzGR3Pd/7+xN1Nrw+fbf/9
B+uh+mLj8uN4+PT5D3FcQzQK088s+mU4nc27I5PhrCYOcs5m7j9oVwUTJp8N
oAo3vLhXJM2MJ2FDAJA0MUpS+YIa6qagX+mkGWUTe/gNCuFx+5twjBTLfPuP
Z+ERpKbSX4NKT8orPQsq7ZRXehpU2n5WWmknrPSktNJ2WMldUloEtECGoQIY
PCJWVH7qqv+wtbMbkjaTmRCToy79DZoydMmh9Rf7Z5dH7Yv46OL8NKZfp2/P
sbprlQWFvI44zu/yX354ThTkh/Df5X9BKkq3KjAf6+o0m2XTbMTxetdy+A5c
6+Nk3J+NtjIT7Tga9iaFjJ3+8+c7W13WAsgGU8N+OOOkPnc41G3C6occ4BMZ
s50YZKqrXvLiCRqIqU0RieoOflLfDfGd80vcgaDDgmfn9KATd9r/7HCGmC5X
5oMSWX4LXUSzNnES0Gx+dUXMbXQHlNt3qUQ9Eo8HjlVwLqVWqXXzcX391/TX
2pq6/mQIeCLfXnDhOPv87+jR3/7afDjY5gfEpSbRI/ne6/e3ejR83nLgJ78T
M+vzz4f4rUV+U9u2peksX/cWs3W3LPhYgAaJiWRj2GOUOZIsiT/2P7FlbXTD
vnjnODLw6PgMl4y0PSoDwsbZ7OnT7e2tm9AvtoDFIju08FO9oPuZt4zSzJ3c
kJBV/zkRX76jF/o3zaNbBN8ibDcnTXU61AS4G2qlFqn3n9hYKtvxGmSc/AHX
33BGODa+ABz0IGHNLTyyqQJ2NNBV/FH9nCQTkGo+HE+Idl4Ygqub+ZBCwVe5
RVdzHC7GcBCDBMAIvBdnmVA+DXzOJ2AYoUTkOh1+NoDXZIcM7vQJHxa2rWeW
dUd5ZoYs46hvN1mENC185fQpnYoPZU/GWJ7k2ETRwedIxUrhVBiLYV1ejijy
A4P8od6oJQ7xm/WaiSg30eSYurwirhwCHnICNXNwpEk6OIULNakKWShN5TrC
YpFhLaV870q3j2tfzvZP23F8uk+MlOB7jVzSLt+yAkfu3biXjSSD9MPp6/MT
WxHNcV1rQWpdQ0PcgmxnA18jSGNJZiXLZnoXTTKiZsLJh2yOtsZQmZTz9bLZ
TRNoTJMhPMrWIJMELjte6wP1prAuEFp3+cb+uBXiBZ5/fHbciS/bYqPvX57G
529tfvH+ZewXu9NnFgq8kx8eWKWnWI0jeF3x+euf6Hl8hHuJOnH75KhRs2in
XxEQZFDWJ+4F3rvV1xtlOAOVyKpzfkEa7GUnjiUMX/A7zBnjyDRAvNk8lWxA
2f7g40xS4+3LScgY4cK8gQ83ab9R+TPLspCjt9+QFAXIDcwAf4+K5+ntMB20
BrdPWlQfpKzKWJgCHMe2odftH7EyPv4WMOeLeRoZc0BFhtvBYUbM2zL2QL0g
68jw10EWy7vxgN8qstfD8/jHk/PX+yfxIQHyMn59fviBIFf22OmgqiDD6mAX
48aEL884dKhA+OeuMyM2JqF5OHG5zvWN+gSxmrrP4S6vCnd/S4EuOnY1tdVM
j55HGwwDaRgDt4ch3jRb4O2b+5Wx7U/wJJq4HuJMyfiKgJ1IxEl9EZnejqI3
p+CMiPIlVo55n3oZ9ammPqyA+X4p5svJuAAx3VrSrUv5IxND5OdKgIDiy+8x
RL44/4ujsQOPxvztxgLxeucOyl7TAvCsjXYPC7Klx2e/nP/cFr7YYN4z75n8
dVVqgn1dZCL/C5Ufs2yGk20oCoJBVBDSPNDKumU4mPeRBpq6NlW/ykS5tO92
Z6E3eott+COE6TtNhM+a8vLt0VQeLSB+y7xqBCmtyf4N6UOTCdK8u9EWfKlR
nkjXt4mVkEEBWlFOutBFUxVGZqHwEw4yaEy8F8Jc1KfMQCLV7XlglzqeadKf
k8r+2cyH+hQYvuC+nd+XSFodDc47v2Tn6j6PeYk7OVqcqcel7iNFgrhPXUKa
nqZkn/pqlbXvCruk6LtSU6rJ+WUsEKl+F8dnMIVLmpLmpSa8NZ9LCInHTEjc
YUaeaGkuHr12ncxkg3+qOeNyRFlu9J4c1lNNfHf+/Zyko2oF1+j1yOZq9TNa
YsRYeCtNZToTGjxgnOD1uTua2+NaYA1jiv0RbDU3JT79hdW/2W1GFnUCL3fO
cYTGqpQTYm+SOzbzqFVkv48nszttghBASJQUMwc7dlRl3UEykBV4zLlifF9m
brxFyHhcz5PZussAyo2NIRw8nSvsRCWRKVvgRwOBOdIH0Xqg0nCFQLJabbFn
EwgJyn8hSTWGaSaLVUZ7wmlZyXSMqfHiklxEXeCIp3FDJhC/hrnO/GUGfAwy
txVg+Gm9RFkMpHDdDv4yPmyTLdg+jMm6aF+QUXjyoVEa0oVmDs51I+j8IuTQ
7y7bVHhyQl0+adSsyhFA6eMTRCT8h2ya7S+7fp3DqjqiyVS2tqQRq6IFq78E
LIw6MMOlECnaT0IW4eqHOKxe/FoNV3zG+2TJHXecckGD0QdRidNmQY0TyRuL
45PVI63CQSN+aaxB9H6lzxnOcRwlUnvUzWdx8Eo+gv+MHVzsSDRy3vbPUUU2
umlzs6qJvbKhhPy8bKybe9FTe3oOH1PlVWrU1gqzd+PaaMgR4Fk/fKdZ1g3H
AMse0IbZE7VNNaxWKMHQy7ocl/S40MeyLkTkFSbJOyGVmEQu5zK8rTkXQfvs
/LR9KpfS6gldrZ3Grn9Qod/Kx/J2sSYxcv+gL7kMzRhNHFHCbqJ0PrFRI0Gh
kBFv4AUu7AhhOGkm7SIQZ1dVEPsCKwxzL6QuhJZPUbwhFu1WwKfV0mgpA+L6
xgqzh5X0m1g+ayuBi19QVJlIiatpkhQGvluyCvyQLWMBEGswBp/97qw8B/SG
l4es0FbAqa9a97iU3RhZfcm+r10INdbUWD3sRrdTHDMwZYjqGyJo7mEKSh+m
k7oGIQaOKW8E7qHHGhe0MO6NHv4PUEsDBBQAAAAIAMJjay1dxXNPCSgAAHAK
AQAJAAAAX2RpdmRpMy5z7X1rc+M20u5n+1e4svMhqdcz4Z2Uq07VSrZmRm9k
ySvZk2TrVLF4k6NElry6eCb59QfgRWyA3SCoOJP9cFJJLFHoCxrdjQcXAmfv
dlmyX27WF++e0iw+PL6L4qVtnZ+9e95mL8vNYcc+skdJtFrxj2Xps3d54TCK
Y1bs8ptvLv/5vN08xsv97vzNGP5mXDWpluvFBqfhv2AUq+U6wyn4LznFPvuy
Z0/5n/x7tFo+rs94TR5Xm3h1Fobp8iVd2uxBtt7Dr/vfn7Pj98uLfy4O61z4
efXsivF9PzB7/O+tyZkvttFTdvZm93zpGJdvbPPs7B8XL9F2938ujMuLbfbI
PgTfs4/R9rF4xrTaRuwho32Kdr+dGV9Mw18Y7J/Ltw5nWD41yn8ujdwI+7P1
Zptttmm2Zd+T59UmSs/eWG754/Gn3SE+5OoUKuVlt9luz4gvDKb19fsRN8ru
MyM2L63gW1buu+K5WT0PLm0PPLeq59albYHndvXcuLQc8Nwpn5u9S8sAz93q
eXBpQv5e9dy/NCF/v3ruXUI1g9z4Fv//YGBdIdYpvj9FyXZzfhav9n+cvXEv
34xNg1nrafOS5VV/U9m1LCeYkfHOBdzyOhYc/JyDxx7mXnDrFArYxR9e54J1
cPnG57+7xycmcwyXP/LyssO6LLPoG94ot37BBdCwX7is26K2vfZqrrNcRyZr
7By5sGo76mremrk7rPbMa5hMtxA7GHjtErP/5CRcIjPsasm/ea5ru2c8CIwv
C/ZPm3ATCs/rrFPPUmpQ1dOuCVFJtQjv0nK96rvHRZr82yr/4l3aTClu6912
lXMtGK/inDgMk9Uf4T6Kv31jf1dU2GYRUdbWYv4UpSmsSRGLfs7GyqtbeO1Q
07hlc1pmxcrKWfltRrWrGrDy3AWssoqMlvsio99sC7c8KpbHLC/Dy/P/ch82
3eNjzsoqHltmkf4Kdx74lTQ/L2KyirNkybQ1juKidcqMZZp5gcoxchonl2Yi
zV47tMkKrzfP7NE2i34788/NKznrPS1WG1a/87N/5AWL/z8tfuE+KT7Ma5O3
EBfK7ZB7AQ+TgklPYnJY7QvLmVUJV+bIfYl7Cg9znXa1y3a1m5ZS+HDhXLmb
MjMKPp1/148bLrjg1rtk/741dWOH1w+GPcJI0pKXuarc16t4HGvtAfcoXEFI
G3+HOziiOwQnu4PT1R28hmFavcHJxQje4HT2Bq/ixrquQNsbtKtXijGNXm3u
Xh3yqupVCnElryTqnOMVDOEgz0p5V2oaTpGjgiLh+nXHahddrlf04gWUGwzd
4o99LOeU/a9lFPwCzf7QrGprVZx4QrVbUrZlHoPEyRk41Vc3/+oCw0u/ukUK
ZwILXMQR0UpEa8X3Gu0V32vUln8HaK34XqO04nuNzorvAJUNhlaNaYrgqfrl
Vh/5lRU75g2IWxX2Klp1UP4pmnBgGuVfbssCjZieb5peYBwBCQfU3GWWZdAf
+6JOEAR4da8Q5TFRpRBTqXu7MWqWllOxDNTmcIuWL6Do0DRLO2hgY54GvNJj
TU+0wzGLkE7rlAKt2uCVxiCVcW5IQqplayf0vD+5tdyyfjxYi5xLYU+pOnkl
9YxSNq9tt7iSTqZkmAeATgeCzjx/c9BpOwB1mkUMnQQ7HQR2WuXAI7dYh2HE
EcKyWNcBnpZ/zGJmCWnKJgtKD2HZF7hIXt/eETWWKNGHKJFp4RfeXUU5N5SA
mnp6ULL3FbBDIGIHl8IO/tGjTQI8BAXC0EcPrgy7e7r9qwgfgq7wwT3Ch7wz
0oUPZQWFQWSTk6QmL3N0seDI5FjvIK+2Npz8Gi4hwUneO5zqE05nn+g1bPNV
ECWXW3Ar00AHTKlZwwpUmmZtdFcPVNY1lHXkml9J/HIZAsw08xkb29AEhKWm
nn1Mja5YUSqb2maZtY9dg+WAsbkNIJdbTiPZdgFWC2xrl1NUZjXxxuiN8pN7
6RTMS+Bbgqdh+0QThygMDgs4WVkRxyu0qbrtctrA9LG5hVu7+jm4kjsI/qtf
qnv81SwnNcrfS0jIYT1IhzbIC3L/cmuXQwATTvzk0yBe7QvSvAmfiMknAUvM
aRkVrZuX/fO9UDFYMbniXE7pC4WcxjyNA3zBgLnEw3KWU6hsXiG5Kw8O0J0V
o7wyMcnc8tzlCbnLwXJXme6dLpHt9JoN+FX6M6dOXvl8RZcOzWnWoWZleniX
5vTkLs0R0zbPFHWfZqj7NNP8+p0a6hccfBpqvyj7ND2/qPo0q2mcr9OpWcLk
VpcurZPjm6YF0o6n16cdVZLqy9W+ktnlMsoujUeWzpiXZ33Hh+geVozI/HY5
IrXKEalVSFUNvjXaBNjKdophhfOKw++ap/b4u5hrcqraWtKCil9UXmPwBarm
OScuqTjlqFxDXtGVH2drvNY1Ma+sadmVW460euN3CSiv9wpja799aO0boF8P
Xndk7ZQj63IqZMDnJjqMsAOr4wjbKfGP5V5JXY9RyO82vWGaR1RaQsu2SR8m
2oOiSxqumsYMKVy78/Td7tYpB/9ggsEBss1ixQvqdGysEh4GMHXlrScskfL1
2hIB5zLKOb3jVAXXN3d919SMYgD74cSzup4uwHF5BfOHuoFsw/GAOg9y1yvq
UznuEVCXYPwIfoug8Y+IsHJ9t0oCR9jMoUdQAnW3CoweDtTdcsU7H0YJOK9G
O1bew9dA3S0n820D6uqKuhILnG7pQbapCdR1cRRf1i89p+DdGNF4Ze9nFxb3
yjVg20KhvJcvQbSBd9tuBe89Cbz7BHhvA2n5ektHDNMzkEZtBTH5GmIeqUBw
0CWp9I4pm4/y9EFar4ndRVbsvxpdVXryQsd81DtyOVa8998I3d1Xg+5uV+je
s5vGaXWKYoUrEBFVN6ewTwLu+tU7dqYOQNr+ScC9qi3X+krmlosQpqKOE/Ru
pS/PICUA5DniH/27u6JVDxflivw/JtOweJo7TD694LmNdFJboSjhHdOSaeYP
qgTuHEm74A4X9uOmDu7IBWm0Ru+y3OzlyzClZcKtV/Twnu5K70k9vFf1Q+4V
RCilekeTuMWyBlTfPhcHX3m35lddz3GjjnvsZeEmprJHtArW+dSV345kjrCi
6GxdjV0queHLKnbbQtbzOrrErZ/3pKYpYGFOCcFfD2C/ngT9zBL6+eXITUPj
fIHW65BQ+DinhELl3CSfw2wZBbePo4DhfOP1B8E1T+1B8K3vFJPPJfI7TtVW
f+uVm2LFGW6QK9wKbnGAv/p5o2kM3XnPuT1uwrDaZth9t9C4jsWTNl9oaGaV
Q12TeQsYysN/2vJf7j3vi1nqd9k6hfuWpT3S+Z5keZN0/jBftHDi3/fM/cfD
69HQePtmPOd/z8u/dYFaRfaofMItGu2S5fLsm//LxujfiL+UHx3w0ag/J6Bw
Wn/mJaod2qVOvKbz9zdDUVv+gGnbz385rz7AIkUVwQO+VRt+ZdZ7e3wKtK0K
8M3RjQJZ/dEKSLrgbUEOKglMYoLnfkCUAZ/9HlHGAmUioowNysREGdBGfkKU
8UCZjCgDaP0FUcYFZVKxtasWLB4Z0JWzXyo/jj4jnmzKnmyWnmyWnmxCT4bN
UrvwH7POTgzrBWyr7dtm5dum7Ntm5dtm5dtCkeLJ26r2kpO/fdfm5oZYtf/v
8X+fx5uix5evq2TH91WQN16gr4zv86TN/pwXfziNVbWXWPKuyJj8w3n14Qr3
5vrjAphhAaoCrE9ERNtHo+0jCM53775n/z4mCf+vjtG6wHKdrA5phv30/WG3
/R77HcZlUXS1jBl/611CpwKcMNmsF8vH75+Wz7v8f+9+6crhcX34nr9x1CS1
20iZ1stNd7L98inrTrXbp0xedzpuoXV0isSqUTqbdF+0SoOQdry6jmm2aNBZ
GnTRtimvlS78EBKq6jQH0vbtmv6+O9XbOOkuW7G01J02227XJ3jqarN+5P91
cIHjxzLzXaE/u6LJqlx5a6LKZXzKzm2TTvEEbQK7DQ1KoAKfuO1A6aD1iLxL
qUvrxBRawOtE6aHq+NapmgBjmItOlMHJdQDIxMb7QNKpjJOFCngi6EZqnS4V
Ol7HugLPgwBIhxT6F57ISFJQPwLukqT+6QqDBnE7Kgy9qf64SP5UgFoGyjWL
LzWgGMmUgLQ6pNAFuyUwy0arki7+nIFO907r9OxneaeTQu9Mu5EGp9cVeKfV
TWEb5rpukWgTYzAdUuvkutr26aTAm7xuydkGPwAFer1LaTzZjevpadCGjoZD
KpIUOlpHMxDDfR2EAx2tIzgiJhZ0SE/vVB3Qzla3xnGcky3swB9wvE2SQm/q
FhkO9KasGyn0pm7Ywzndm1zoTd3M5BLTQjqkp3uTa59OCr2pW+O4sBPs1jgu
9KZuCcaF3tTN/V1izlGHFHpTtwTjgTLdhicedKZuScKDztQtq3mnO5N3OqLy
/sR40ju9rv7pUqEzdQNjXu9kqb5xsoX906E7HJt3C3QfOlO3VOrDaYu4Gyl0
pk6BXsy4oxTCmKmYc0dm5vkZVUd+vJfNMwc2FS+cg1XzdkSJYun8PCtM3epB
9R2bMP++Ma9dTY3/+hKFm/jXdLnl5aRfP0weLq4v7Hf2hWUYlmlYzsW32Zfn
bLt8ytb7aPXdxdtHekLOAsaIvJpr8vQc8qlHidIRKauP0pRRyeP69i6cj+hp
XanojVzUpLm+p6dSZa5yUZssetv/ia6ugdssy2oeabaKfu9gtQWqyc1w3P85
nEwnQy3LFcXH0/6NlvWK4h9H46mWBYvi75l1tGaDoWUsD5jmebtJst1us9U3
D8wpQKO72fR6OJ9PZ+HN8H3/YXyvZaWaamaz8lqmgjS9Bg1uL0DjNeXgrgdo
nCaN00pjNmjcdhrTlGjwEBZoLFmO30pjN3QLWmm8Bk2vncaVaaI2Grdp6zaP
m7lOgyZppXEbNGkbTdDULWu1wQ/XEgmeX6BqDRKzNXwso0nUFj/zmW8iUdcW
QvOB7KQERBHSTgwWpPkib1gdgKmfejy8UW9Hd/OwPxhd98fjOcvQWplHJPp5
ONdaHIM1sg3QL8erTfJbyDdD6lfHx+N0MJ5e/xDeTj8NWV1mt/2xVn0Eqvtw
3J/LGRj3BkCH0ODDAgdaIZ9rgO2aPB9yOEcHJLQBCAa3ZsTXumlVAruhQLOQ
YnxcYanng0JGcC6hCbUIBxWx3EUKETGshhu3ysCH7R7VMEBpX5Bkiywrc/wS
bWmXcVGa5XpPuzog6QH5TgoYbLPHMFlFu506YqqBgJ/g+XYyDWfDD3IME5Fv
euGkj5XHI4SXRwrjWfKeF9WCF5ztPcYYRxYfZlhZHFG8v8PK4kji4wjRGE9M
4ylSFMcNHMgihXHAcHuDqYsDhevpnYGVxiECK21hpfF+hJW2sdI4LGCG609u
QrxdcC9lNqFJcFSQG5ImInBBqRvuBwQsyC2rkEQM5biFFVTEqI5bWkGFhwDr
qUNGiVLggVBRKEThUTFHI9PE44JLwUrjoTEe3fLS4TXrbudN2IHPV0Ygf7pR
VHMrkNT2sZE/JdBSJdAoAq0f13wen0OeihebwzpFEl1NLnQxGn2WgYpjGofr
w1OcyT2OKMxvVFu7EwbCmKDw8Xkrm0gUlXQUFZCiFm2iFh1FJaio3T5iiPPz
ZpsqpcVWR2km3mKL5zDZpBgoq0XBiun4hom31/N2s98gKFoQllhdhdEtFqW/
HnZ7pRmTZgS2iMNbrRCllARRoRu3V8zCo6126DfjazxGQDpLaxW3+y9hmi1o
bJRBBUV1U6DjolGsKfZkfQnQ68byvvnjLwvwi5SZq4+gVQGGD8OXaKWAdD1K
SntGNHCjeoZ5Tjg3aVR8vCqYwIPrLQG+zcnFxzGLdBfyV0ZoM7g2Jel0M1hp
41urGfClQsG58FdTfPHpUWw+Sq9cYTQNn6Ltb41uK0FZRhZqzHCdfVEMmyK7
IV7bklDKLj7IQQylwEoGTrsU3DHC541i6BbBQfSrj3A9uHfINBv1OTY4EObg
LdXz8NotVlETWoHE7nWsH9FUzK22WZSGz3vZsaCwWKhhe4QRLVYJyxpIDwpL
OgoL1MLiaKeYFIvTjtISUtrn7XKftYnLOooz6XYr5KkbbtFVHN1yhThl0yVG
V3F027EU0mLLxOwqjW47Lk1dNaujMItuuF300uYnidNVHN1wMUPrh+c2gW5X
gXTT5fVTW9PrKo1ouqJLVOTJBPYDOl2aTbRb8ku0XCvkROfdOjWbaLDFcpWt
5RlsKAimR53EbxMNFa9+2y3/ULlE2lUS0UibxWKXKWBHIiRFOEdMdS9UGx22
bKi4OjwpGioVAtnVmF4nGuqwPuwyhY+nwlKBTq0IJLD7ZbPdKxFVKmQLuA2H
EuXjovhSkkIMjKUg0BDTDVT5aWsZagUh5E4W6q0IALLctBeH9W75uM7Si+aa
Alwvqj9mDTug+pFDBWK7koVqLgykgiQlTA20S8+xxuVgiLZPBseSwcJATdCO
J3OQoJACs2TPPBX677JM4aYZRKs9u10IniCT1UbVYWYwD/e6AUd5t/LR7hnc
3Uj+QI6fxF/g0qH0i8Y8iE02gtpdicAVHRdWuidAtD9Z6V4DzLZVmtC3ZxLb
56n6wfftxfrZVKMKm8A1G5WkETponfqR7QF9mZwNovXVkG2nxA+xcy4gyWSz
+W2Z5ZhIXlJ0zjHvW+BpCWEAiWAthV6oU+572UexUox1TjgqlfxwPFUYRSFH
TCntCMfF67PchNXVqQqAvRAcIfDapeFbKAU/yHujUg1+3MHuOZOPdpCSdvUR
N9n+Jdw1OECytCH9FA9gYtZqOVlHObitAILhr9cjuIVI2RBKRPDoG2BN2II9
tJr/OWxkeZBI3PFx6szUNntSyOg6u4fbUbSHg0/Tw2VaXNUWe3Rt81Pssego
Q8cewqsWeFYnxpZqg9geJeX1DGL7HWXgIxU50Ihow3MRzGixAebyt9E63TyF
abSXt2jBGSri/B7YqzXn/iCR15B/kpnVQvyOQghAv48awwYoJegoBXdLbnds
jySUBIdBOokF729ySWkmv2UBBUUdBRETwbmkXfaskBR3lYS3UbbGVgmgoKRj
KxEvAxKoMTbgGmKtFwtH29Ic+kOjx3B5LeV2dAI0JqW+oFouN+Fb62CdXX5j
RKSxGxpoByVcy1fKcDrK8FAZMowRZQjTxRqzaPiehM0qDdX28jrWJUPlLNdL
rEOqxXTFLCbegcKuPg58ykbkxBC+6dmERkggI3wRmdhZFt5dh+PR5AfkrSZ8
Lx8nYGXD6/5kOtHasFpRjCZ3D4oN3RLFpH87RJTCN/Bxgrv+/Uf1u1kywehu
GA4e5Be/8K17nOD64/THSTgbzu9no+v7ofwmFW3gyTS8nz1M5Bci8O17nODT
zWjeH4zlV7vwHXycYP7z5JqNjbX2t/LyfZwA3+SaG2vGRt6N8jGtUL6Nv/9T
077ElBd0Z9P18HVxaDGiYeescrMP+u485+06Gt8gFIQ7c4rxD+H99Q96zszK
Tz7Mpg93c31/ZjTTu+FE358ZAXPLYf8WISE8mpHc/5sIM8KXGcn/Tgfh9XRy
P5vKL4IQ7sw1638a3oSjG3l3KeHPjILVZHw/YqrNRx8m/bFMSDj2vPDT2ej+
Z/b54/DmgaU2edM34ePcGkzgTG8nd+5mPIY+zqaT6cO8GRr4nm6g4ujf3CYy
Gb65OzdiKQ2nw3d4c7r3nFBrczcvfdu/u2P834/Gzb3AdATdDm/5ezt6O7sB
QTjrTz7IWY7Y2l2STWc/MwtO74fX96NmB0SH0+1wPu9/GLJuYj5vOgWxxTu3
+5DZ5ON01rQHHVfzj/0Zs2Kp7nTwv0xbza3euWexXDsezVkFsaxEx1kfJ6DD
jBPkmf1mOL7vY7R0pOXv/OYhg9HRUXb7Lyq1mXSsMaJcT4SIDrRPLJoRH6FD
7I45yJzFl0xBB9fsniUoTCs6wpg/hRP2P6w3kA97k8g+9ccPWLa26EBj6v3r
YYhT0XFGNat8ghsgGbB/+3NUDh1bjOhmhHVZFh1bjGZ+3R+jkuiQGuT9Iwt8
jIyOqOvpeBz+OBx9+HiPthcdWsN/PYw+FW9VYIR0XA1/upuFEwYyMTI6rFhP
h5qEjqnZMLx5wI4zsOiQumaJragTARwsOrosIiAtOryskLXcaCIjbeJIhIri
ZvhJRll0XFnh++nsHqOhg6qkYZBepqFDygrnP2JS6IiyQtZFMke/GTbOpqAj
6m4kH48hH0snFg5/um8Q0FHECTiyH8rjOJsOIU4zmtwPZ5MmFR0+nGraOBXE
VgA/FqlyaTpa5sMx65Ll8nSsPBR9z2jaaD8FzgMVL8G5TKzoiiDxzYdZk5aO
mtJ2LHk1QIdNR86Ratygcujwqahk9Rw6eu4Zev2EjWwU/dFHZr3G8MGhY6cg
YAOP98PwPRt5c6zYIKej6MPwnr+fF3IwgGlKhxSjvPtRQUnH1nj6YTSh0qpD
x9c9G+xQVHR8lQa64ZMZD9f301k4Ys7WR+1EB13J5Yfhz1gn5yiGWmX73Pf5
NMFIzqMOHYklZekRmFQ6Ikva/v39rBDdv7mRLwpx6JhskCNY0aHDsiRvH6E6
dJACHiw9fBwyRvJgn45VSFwOoWRiRdRWxPmxG+UIRyZXzIAcz+uY8+mDxqQb
HcqQcjoZy67iKvrCj8wtc0wv09Dx2/9EUykGbPfDn0YYYHMV/SKODF06Zn/K
x004iHLpIC3Ifrp+oEjpMC1IHyajhpZ0gBY017Of7xreRUdmQTScfAxHZtBQ
kA7Jgm7+Ue5+XCWmZL4bsmzXIFLDStx6ngpaPtzJ+cGjI6xsp7sPlkxDh9WR
xpZp6IA60jgyDR1KuckGjWTj0YGUUyATi3QQFRSNvsCjQ4gBJEwEHUE5QVMC
HTvjKRsxIvWmQ+bH6ewGo1DMbQzCMTofQpwvlCfFfw9n8hSgp5g7JOCIR4fJ
nGpAxcwG0YK+Ylbj4wxrQl8xoZFTNGXQMfJA1MSnQ+QB9yyfDpCH3FMQEjpC
HqjK0yEyGfPFDYSEjhFGMu5PMBo6TBjN7RwjoQOFkUwQAjpOGMF8eI+Q0IHC
SFg/i9EQa0pwrdV0A/pF2+OaLzUGuZ7n64v0khKxadH0XMBmL29Okt9gQhIS
3En4pN6w6HXdPkJsWHwKnxpvNUExcUcx+NYRJuaXzUHeOgLldH2pCd/gw6uT
Rr8r5HR9pYnYTsrkbFRmyzqKITb3MDm/Z42jsaCgP3PuhSjos9JwvtFVENlC
v6sFkTvOu73UyQQtd2njvAsoqesxHsQbnUzS49N+s5Dfz4Ki4G4Zne2ZxNuc
TNQfm7W8fQ0KEt4K1ziezsK3YMHsYnoBUOHmx91+e0gUOyADmGThKkJcc1lt
PiMMRCpJvnZ6A2J+WT7KN4/9STmt+7HnI/UhjHA3diBIjzINc8JXesAeeXl/
vkiUnDd6KYTHSj5pRGSSksrihrjBDIFvlDUFdxPfTKkZVjcly8tvQEsrk65J
khSuXm5CbhQGX4uriQU+sPuoHgM/kw9zFHUySMvBQw4dnPXLK7CGbyYlNWvs
ssyataVsk8ogLs76oLaIFHb4hTmCRQDvF7VJ9HgTJpGzksja0bI2VFsIGl94
VcbsWfXX/EZ5+G0IgzQTyOC8vvSTcIPKQvhJiHrQgPAlAkOkwOsHZygsIcZ6
EMtKPwnvJItyiPuS4NBeoggi3PIJSdFzcQpaRoRnADhvJFPEOEVEUsQeTpGS
FAl+DZxLt2KSdJWR+nh7yEioppCzbiUD7tYV0okf111fdVHCNlo/Zjvjf8RD
j0VBC0KQTVO0p0QoTojBATzJZzD0KSGR/AIrVn+JAk+nAggVKSzC53skhfza
aavPR8I9VTreFblEg5DRHhFZBU7T47BO9KDAqDFD04Pg4ENMRJFPelfkE42C
Yz5LSOaB455D1zGF3D6Ewy5JoWxB/rQgE1ps9FrNKFGYRLIh01Ns4V0G7UCx
TQQC6Q6x3R4ItA+AtzabPmDTavpETiRjqdjKf6qaPVWyU4QjhV3oJNHDK+bR
4RjhfkQn+4jqtOgkkXT1oyjt6kdRSvgRPkyRGkgYG8gNBE8rFOMzdkgwELuE
ixG5RNQHnNrV1Ccimyb22hEpLXShSqgxHUy99tCQKCK8m6G9NI7xbgYusMkU
7f2+REGcaKlICmmAU9A5OCNgqI6X9oxY0UAZ3UALooEIrxAhkC10a0ObrFti
EHWzUTHSFGsl4Ro/1QFKdQWpJjwwIjyky5enTZou5eVOYRxnSBlM4lYVAx/B
bRvyrK/IGVEO4SEfw3MKj638xqeSCUxU4K3Hz8rxriGsqQhDachkrTZJoMUk
VdtEj8kWu0SiZtLT0wS7CqpmIkxVJXDvssCkcU3NCUzWr6HJ+lU0kbcpnMLk
P+rqxHpM1NXRYxIreSR6POT1PW0mgi9HRozzD8MvSm+2F1pqhmHjdWZNLvIi
Qa2yR6qsdntHr3UYG6WnaLNR+4o+m9fRZvs62mxfRxul9yq40F4BJ+W6OLLr
a6qsdGQFF1rljFRZ7ci+oamy2pG12agdWZ/N62ijdmR9Nq+jjdKRFVxIr4id
U73C1VS5xSt02bR4hTab19GmxSu02byONmqvoLnQXiGsbXRIb71AU2VlelNw
oVWG26sklVWyIk9LFmGPJ6UfxDRvgYnSC1RMRAssLMoC6lAWThY/PZS12ahD
WZ/N62ijDmV9Nq+jjTKUFVzIuEgMh5KljItED2LQeULJXAuI4x/BpouHtl0X
7ffYiFMOkHfb1ha43AXuCdvu5ZoDE4lDR/hWns41O8LVQS9Zor48SFTqpbG9
EqglDt/gGglpNfgWnAU2cOy3WRaum/dXEYrx4rRewnJ/Arf1knoJU/lgq8P1
w+3DuH8/+jTk+4yxKybre6GgORw47Qk1f95v0yVyCDcwXo8+Zgkw4qfSq7ik
sP8WL8SCWzn4paIom3oHsKujThg+rg9J+BKFq2VjPyGkEUdNKZxPxo9KhlJa
2XvC9FWSuJS2hxC5TlXe81UzgouMINqPZ6Kr72YlfIFrkZ+trlBDuDBBOEFM
YtQ8bxGygVYXnUFiw89uVPARQj618bPm8vMfFcfFt2dDrsl/DlHa8Exyw0/q
4fm4PpBSoRCe+kWFWtWBfZN4lqbIJ0rTZsTZUvG6Xj0wA0ulr9QnHSPNXpTC
xAaF7ytK7bFU1l7c+JiapD6PLXwyTT7L9UbJR0AKKTyEQeTzxPocFSPb0FRo
vVquf1NyMjU5YXc0QD7CAdnCNmmBzaqNj7AHUOFCz+omEw5SFPsHuPMAHpUP
P2r2LotdixbC/Y9U78vioS38bPrlB4FR0sqIvsRKYMRP7lbyoU8tFvjsPscr
pQM6hh6jhN9vomREe6DQ4iZOLUwsCH2I1OT8yFaFGq5wLYpBQMUw/C37XVUb
l4ZbECixXkONkzz6IleozgfeU5tegxfcCiEk0wxOwDZuZVFexkKhn1wH5DhY
qAP9co7I6dBeHeF6NRLDFKzUWgmr6YKNwSCHX4nw6+HpucEIekgmlkddHiAK
uGdIdHIctKawXxUuS5AU5efKhc+rg/xuAuXN9XUP8OIBleqZcHefcPUAYMz1
kHjAC3JcqjqQx+J509QEchGmpDLDQq2yifObk/XsgcJ46GHi1EeWUGwwHA75
CLtMUoOwAAbDIRexy6UgAIrCYVkR/FHgBkWskI2YiCkAQCBxWFpoVxJEol04
ZCNMHWU2kXMwRCurXisTETkQw6GQizBMTRMZn5dcMBQKuYjoOiUMg2JQyEYE
1xkRCzgChXxEcL0g+GC4EXIRoLUQxZALCj/h2/UCsM5MQhkMfEIuQnxnFpUm
WriI0R0Tsw87dM4F8hEiKoMbfQUPRqEj5CP4cOYQkYBDUMhH8OLMJbIfBpAg
F7HBYwLZoDgWRJ8jeF/mUSlUnfscMbwp9HhoyefC4j2JSQ7KbO7A6CYBH2MR
qKwr3MstXoAodyxqPuKE5oJoaxytQT6iD2dEtQ4EjIWcPB0b45gPstGaDj0Q
kBYyCjTby3OUbKAHkhM9uT4tjMQ+xiOyzjZ7XO72mTLQXXLQCoAVD9CXSH5/
lciYbPD1FO1kFAZ3A4qDFDhNJfFpDuLgiSliN0C1SrbdbpoWEA5g1nKTdNkE
D/JVTseR7YLADqsWLkKdhAukBC6tbKC/CvcuwYEpG69vnp6jbbhYo8yO49MU
dpWWCRMEMa9oWbBzF66/syx46rJJmV7z1sEe8ZI6rGdRy+Vus26vqSvUNCOG
PPg8B+yxBFiQBSDgQFjF2EZJRNxjsnnB7tWBU1XknU9AXvYlyZ75qC9Ms12y
XT7vN4qlB6jBv1qWPR3ocJYFD7eB8w46Kx6EyR9aVaCXXSCfj21sRABFdWIP
rXy0YAK65Au5aM2l4CvHkI1wIQqVKVtPFIBOTXZfrUvkrjiUpTqv+fsWNtA0
lkUssy1Wm0gxw0HIvmmTDe1p2fCofCA73Rya91UGuHBhYshBi/v0WTQg2d38
eFgvG2fnNA+5ODaAuFFfeiWuriM8I9cXLB/Aw68MoXtZ/RHuo0aSgxszXGFz
u2W7Ut/Q/OiLaknnq+yyfFrr7F3xAk8Ux9vsBWeJsyfubYIrzO1MJH+oCsTo
Y7gXBZaWTnZp9nGwu0O9iqghvpwSoOLAR3gENHyMl8b1hGMU/GQcwnRJByEO
Xtf/PmuAhk87GKObaOHMClhZwDFq0xTeQocW6CYbFwI7FPz8gG78YIzhL+N1
avAMfYyLBnr+nfHYusstwtX471NUGpe+YqhA1P4aoQJxZ6vX4T51qtfJN45r
WylB1ceF4C/+tntMt9iVD23QzwUQwrRaTBhXdgqAv65XMAmJnYKy3bFeQ1MA
O7p0CwQ3WFf8ZWei3vDSGXjZXSePk09u1Pc4gh+cAsK7M4JQmlP5b3BJ/2ur
1NohwCNo5Amlv00n4CBfv5cidIKD/fbcLe8eakbVa1ShY8BSQzV8TBaYl+I1
KzCecOxDmK617f/K5rS6aArbpwvU/RtUTYnP7f5I9YudvIPQKkMrbLRLJ/gt
TuXXxZbCFXdEs7+GGPNkMQRD6WJvbReAR7+0dqny0bgI61fwHIjxO9XlVYTD
nNotub9COuiYxaG3tk9oeajIv7UrFe42/PpZllAKH363ewDBrtfGjqCDMwl4
aP6Vk1mEUrAGfhelugyI4cUDr131090i7aKUvIHor2qP7K+zVHtGwU/7g7Lx
SeZudRSux/z6SYIC7V0cmn+U1lGeD/E6esp2l998c/nP5+3mMV7ud+fwVfBz
8LLteb2WVZAv14uNcS6s84jHncdg2Uw+h9yh1YqKA9pIrRItrSqTihawiM8V
j332ZQ+/Z/mDt/IPkAitA1YF6fy5KyBmMPAaMvjJcejTgWmihZHHTT0BFwvn
gj4eWHhp/PHAtHHezcdKDV2cC/p4YAW4hujjgYXzRh4rNcRl4o8HFt5u+OOB
1XS7vDT6eGD2cE2aj1X1sfB2wx8PbB8tjT8eWA7Ou/lYqSEeKPjjgYVriDxW
ysRtiz8e2LgN8ccDG48r/PHAxj0IfzywcQ9CHqtqb+Pthj8e2Hj7II9bc+hu
v5UT6LV1BbqU8nWZokvhbxTCH0NhdzbffwF+/bzZpmDvFX83TaAVdjuyXw3w
K/be8DLN1vuzbz5cX19dfPth8vDdhf3OvrAMwzINy7n4NvvynG2XT6xQtPru
m/P/B1BLAQIUAxQAAAAIAONlay1SFP+OsysAAHilAAAJAAAAAAAAAAEAAACk
gQAAAABsaWJnY2MyLmNQSwECFAMUAAAACADCY2stXcVzTwkoAABwCgEACQAA
AAAAAAABAAAApIHaKwAAX2RpdmRpMy5zUEsFBgAAAAACAAIAbgAAAApUAAAA
AA==
---559023410-851401618-1037047839=:6253--

From mdharm@momenco.com Tue Nov 12 00:33:53 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Nov 2002 00:33:54 +0100 (CET)
Received: from jeeves.momenco.com ([64.169.228.99]:15628 "EHLO
	host099.momenco.com") by linux-mips.org with ESMTP
	id <S1122165AbSKKXdx>; Tue, 12 Nov 2002 00:33:53 +0100
Received: from beagle (natbox.momenco.com [64.169.228.98])
	by host099.momenco.com (8.11.6/8.11.6) with SMTP id gABNXiN30566;
	Mon, 11 Nov 2002 15:33:44 -0800
From: "Matthew Dharm" <mdharm@momenco.com>
To: "Linux-MIPS" <linux-mips@linux-mips.org>,
	"Ralf Baechle" <ralf@linux-mips.org>
Subject: PATCH: The other half of the Ocelot-C, plus support for the SandCraft SR71000
Date: Mon, 11 Nov 2002 15:33:44 -0800
Message-ID: <NEBBLJGMNKKEEMNLHGAIKEEHCKAA.mdharm@momenco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0007_01C28997.B8471B50"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Return-Path: <mdharm@momenco.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: 621
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mdharm@momenco.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

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

This patch is the other half of support for the Ocelot-C board from
Momentum Computer.  I've already added most of the board-specific code
to it's own directory under arch/mips/momentum/

This patch is against 2.4, but should also be applied to 2.5

This patch updates the various Makefiles, configure files,
initialization files, etc. to call the functions for the new target.

Also included in this is the code to support the SandCraft SR71000
processor, which is one of two processors supported on this board.
Not much needed in this department -- the most contraversal stuff is
an errata workaround for the 'wait' instruction, which is all done
with #ifdef's to make sure other targets aren't affected.

Also included in this is the new files for include/asm-mips/ to
support the Marvell MV-64340 chip (done much the same way as the 64240
and 64120 were done).  And the couple of changes to bootinfo.h and
serial.h to support these targets.

Ralf, please apply (or give your blessing and I'll check this all in).

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

------=_NextPart_000_0007_01C28997.B8471B50
Content-Type: application/octet-stream;
	name="patch20021111"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="patch20021111"

--- /dev/null	Tue May  5 13:32:27 1998=0A=
+++ arch/mips/mm/c-sr71000.c	Fri Aug 30 15:17:52 2002=0A=
@@ -0,0 +1,839 @@=0A=
+/*=0A=
+  Jason Gunthorpe <jgg@yottayotta.com>=0A=
+  Copyright (C) 2002 YottaYotta. Inc.=0A=
+   =0A=
+  Based on c-mips32:=0A=
+  Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, =
carstenl@mips.com=0A=
+  Copyright (C) 2000 MIPS Technologies, Inc.  All rights reserved.=0A=
+=0A=
+  This file is subject to the terms and conditions of the GNU General =
Public=0A=
+  License.  See the file "COPYING" in the main directory of this archive=0A=
+  for more details.=0A=
+   =0A=
+  Sandcraft SR71000 cache routines. =0A=
+  The SR71000 is a MIPS64 compatible CPU with 4 caches:=0A=
+   * 4 way 32K primary ICache - virtually indexed/physically tagged=0A=
+   * 4 way 32K primary DCache - virtually indexed/physically tagged=0A=
+   * 8 way 512K secondary cache - physically indexed/taged=0A=
+   * 8 way up to 16M tertiary cache - physically indexed/taged (and off =
chip)=0A=
+   =0A=
+  ICache and DCache do not have any sort of snooping. Unlike the RM7k,=0A=
+  the virtual index is 13 bits, and we use a 4k page size. This means =
you =0A=
+  can have cache aliasing effects, so they have to be treated as =
virtually=0A=
+  tagged. (unless that can be solved elsewhere, should investigate)=0A=
+=0A=
+  Note that on this chip all the _SD type cache ops (ie =
Hit_Writeback_Inv_SD)=0A=
+  are really just _S. This is in line with what the MIPS64 spec permits.=0A=
+  Also, the line size of the tertiary cache is really the block size. =
The=0A=
+  line size is always 32 bytes. The chip can tag partial blocks and the =
cache=0A=
+  op instructions work on those partial blocks too. =0A=
+  =0A=
+  See ./Documentation/cachetlb.txt=0A=
+ */=0A=
+#include <linux/init.h>=0A=
+#include <linux/kernel.h>=0A=
+#include <linux/sched.h>=0A=
+#include <linux/mm.h>=0A=
+=0A=
+#include <asm/bootinfo.h>=0A=
+#include <asm/cpu.h>=0A=
+#include <asm/bcache.h>=0A=
+#include <asm/io.h>=0A=
+#include <asm/page.h>=0A=
+#include <asm/pgtable.h>=0A=
+#include <asm/system.h>=0A=
+#include <asm/mmu_context.h>=0A=
+=0A=
+// Should move to mipsregs.h =0A=
+#define read_32bit_cp0_registerx(reg,sel)                    \=0A=
+({ int __res;                                                   \=0A=
+        __asm__ __volatile__(                                   \=0A=
+	".set\tpush\n\t"					\=0A=
+	".set\treorder\n\t"					\=0A=
+	".set\tmips64\n\t"					\=0A=
+        "mfc0\t%0,"STR(reg)","STR(sel)"\n\t"                 \=0A=
+	".set\tmips0\n\t"					\=0A=
+	".set\tpop"						\=0A=
+        : "=3Dr" (__res));                                        \=0A=
+        __res;})=0A=
+#define write_32bit_cp0_registerx(reg,sel,value)           \=0A=
+        __asm__ __volatile__(                                   \=0A=
+	".set\tmips64\n\t"					\=0A=
+        "mtc0\t%0,"STR(reg)","STR(sel)"\n\t"		\=0A=
+	".set\tmips0\n\t"					\=0A=
+	"nop"							\=0A=
+        : : "r" (value));=0A=
+=0A=
+#undef DEBUG_CACHE=0A=
+=0A=
+/* Primary cache parameters. */=0A=
+int icache_size, dcache_size; 			/* Size in bytes */=0A=
+int ic_lsize, dc_lsize;				/* LineSize in bytes */=0A=
+=0A=
+/* Secondary cache parameters. */=0A=
+unsigned int scache_size, sc_lsize;		/* Again, in bytes */=0A=
+=0A=
+/* tertiary cache (if present) parameters. */=0A=
+unsigned int tcache_size, tc_lsize;		/* Again, in bytes */=0A=
+=0A=
+#include <asm/cacheops.h>=0A=
+#include <asm/mips32_cache.h>=0A=
+=0A=
+// Unique the SR71000=0A=
+#define Index_Invalidate_T 0x2=0A=
+#define Hit_Invalidate_T 0x16=0A=
+static inline void blast_tcache(void)=0A=
+{=0A=
+	unsigned long start =3D KSEG0;=0A=
+	unsigned long end =3D KSEG0 + tcache_size;=0A=
+	=0A=
+	// Could use flash invalidate perhaps..=0A=
+	while(start < end)=0A=
+	{=0A=
+		cache_unroll(start,Index_Invalidate_T);=0A=
+		start +=3D tc_lsize;=0A=
+	}	=0A=
+}=0A=
+=0A=
+static inline void flush_tcache_line(unsigned long addr)=0A=
+{=0A=
+	__asm__ __volatile__=0A=
+		(=0A=
+		 ".set noreorder\n\t"=0A=
+		 ".set mips3\n\t"=0A=
+		 "cache %1, (%0)\n\t"=0A=
+		 ".set mips0\n\t"=0A=
+		 ".set reorder"=0A=
+		 :=0A=
+		 : "r" (addr),=0A=
+		 "i" (Hit_Invalidate_T));=0A=
+}=0A=
+=0A=
+/*=0A=
+ * Dummy cache handling routines for machines without boardcaches=0A=
+ */=0A=
+static void no_sc_noop(void) {}=0A=
+=0A=
+static struct bcache_ops no_sc_ops =3D {=0A=
+	(void *)no_sc_noop, (void *)no_sc_noop,=0A=
+	(void *)no_sc_noop, (void *)no_sc_noop=0A=
+};=0A=
+struct bcache_ops *bcops =3D &no_sc_ops;=0A=
+=0A=
+// Clean all virtually indexed caches=0A=
+static inline void sr71000_flush_cache_all_pc(void)=0A=
+{=0A=
+	unsigned long flags;=0A=
+=0A=
+	__save_and_cli(flags);=0A=
+	blast_dcache(); blast_icache();=0A=
+	__restore_flags(flags);=0A=
+}=0A=
+=0A=
+// This clears all caches. It is only used from a syscall..=0A=
+static inline void sr71000_nuke_caches(void)=0A=
+{=0A=
+	unsigned long flags;=0A=
+=0A=
+	__save_and_cli(flags);=0A=
+	blast_dcache(); blast_icache(); blast_scache();=0A=
+	if (tcache_size !=3D 0)=0A=
+		blast_tcache();=0A=
+	__restore_flags(flags);=0A=
+}=0A=
+=0A=
+/* This is called to clean out a virtual mapping. We only need to flush =
the=0A=
+   I and D caches since the other two are physically tagged */=0A=
+static void sr71000_flush_cache_range_pc(struct mm_struct *mm,=0A=
+				     unsigned long start,=0A=
+				     unsigned long end)=0A=
+{=0A=
+	if(mm->context !=3D 0) {=0A=
+		unsigned long flags;=0A=
+=0A=
+#ifdef DEBUG_CACHE=0A=
+		printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end);=0A=
+#endif=0A=
+		__save_and_cli(flags);=0A=
+		blast_dcache(); blast_icache();=0A=
+		__restore_flags(flags);=0A=
+	}=0A=
+}=0A=
+=0A=
+/*=0A=
+ * On architectures like the Sparc, we could get rid of lines in=0A=
+ * the cache created only by a certain context, but on the MIPS=0A=
+ * (and actually certain Sparc's) we cannot.=0A=
+ * Again, only clean the virtually tagged cache.=0A=
+ */=0A=
+static void sr71000_flush_cache_mm_pc(struct mm_struct *mm)=0A=
+{=0A=
+	if(mm->context !=3D 0) {=0A=
+#ifdef DEBUG_CACHE=0A=
+		printk("cmm[%d]", (int)mm->context);=0A=
+#endif=0A=
+		sr71000_flush_cache_all_pc();=0A=
+	}=0A=
+}=0A=
+=0A=
+static void sr71000_flush_cache_page_pc(struct vm_area_struct *vma,=0A=
+				    unsigned long page)=0A=
+{=0A=
+	struct mm_struct *mm =3D vma->vm_mm;=0A=
+	unsigned long flags;=0A=
+	pgd_t *pgdp;=0A=
+	pmd_t *pmdp;=0A=
+	pte_t *ptep;=0A=
+=0A=
+	/*=0A=
+	 * If ownes no valid ASID yet, cannot possibly have gotten=0A=
+	 * this page into the cache.=0A=
+	 */=0A=
+	if (mm->context =3D=3D 0)=0A=
+		return;=0A=
+=0A=
+#ifdef DEBUG_CACHE=0A=
+	printk("cpage[%d,%08lx]", (int)mm->context, page);=0A=
+#endif=0A=
+	__save_and_cli(flags);=0A=
+	page &=3D PAGE_MASK;=0A=
+	pgdp =3D pgd_offset(mm, page);=0A=
+	pmdp =3D pmd_offset(pgdp, page);=0A=
+	ptep =3D pte_offset(pmdp, page);=0A=
+=0A=
+	/*=0A=
+	 * If the page isn't marked valid, the page cannot possibly be=0A=
+	 * in the cache.=0A=
+	 */=0A=
+	if (!(pte_val(*ptep) & _PAGE_VALID))=0A=
+		goto out;=0A=
+=0A=
+	/*=0A=
+	 * Doing flushes for another ASID than the current one is=0A=
+	 * too difficult since Mips32 caches do a TLB translation=0A=
+	 * for every cache flush operation.  So we do indexed flushes=0A=
+	 * in that case, which doesn't overly flush the cache too much.=0A=
+	 */=0A=
+	if (mm =3D=3D current->active_mm) {=0A=
+		blast_dcache_page(page);=0A=
+	} else {=0A=
+		/* Do indexed flush, too much work to get the (possible)=0A=
+		 * tlb refills to work correctly.=0A=
+		 */=0A=
+		page =3D (KSEG0 + (page & (dcache_size - 1)));=0A=
+		blast_dcache_page_indexed(page);=0A=
+	}=0A=
+out:=0A=
+	__restore_flags(flags);=0A=
+}=0A=
+=0A=
+/* If the addresses passed to these routines are valid, they are=0A=
+ * either:=0A=
+ *=0A=
+ * 1) In KSEG0, so we can do a direct flush of the page.=0A=
+ * 2) In KSEG2, and since every process can translate those=0A=
+ *    addresses all the time in kernel mode we can do a direct=0A=
+ *    flush.=0A=
+ * 3) In KSEG1, no flush necessary.=0A=
+ */=0A=
+static void sr71000_flush_page_to_ram_pc(struct page *page)=0A=
+{=0A=
+	blast_dcache_page((unsigned long)page_address(page));=0A=
+}=0A=
+=0A=
+/* I-Cache and D-Cache are seperate and virtually tagged, these need to=0A=
+   flush them */=0A=
+static void sr71000_flush_icache_range(unsigned long start, unsigned =
long end)=0A=
+{=0A=
+	flush_cache_all();  // only does i and d, probably excessive=0A=
+}=0A=
+=0A=
+static void sr71000_flush_icache_page(struct vm_area_struct *vma,=0A=
+				     struct page *page)=0A=
+{=0A=
+	int address;=0A=
+=0A=
+	if (!(vma->vm_flags & VM_EXEC))=0A=
+		return;=0A=
+=0A=
+	address =3D KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & =
(dcache_size - 1));=0A=
+	blast_icache_page_indexed(address);=0A=
+}=0A=
+=0A=
+/* Writeback and invalidate the primary cache dcache before DMA.=0A=
+   See asm-mips/io.h =0A=
+ */=0A=
+static void sr71000_dma_cache_wback_inv_sc(unsigned long addr,=0A=
+					  unsigned long size)=0A=
+{=0A=
+	unsigned long end, a;=0A=
+=0A=
+	if (size >=3D scache_size) {=0A=
+		sr71000_nuke_caches();=0A=
+		return;=0A=
+	}=0A=
+=0A=
+	a =3D addr & ~(sc_lsize - 1);=0A=
+	end =3D (addr + size) & ~(sc_lsize - 1);=0A=
+	while (1) {=0A=
+		flush_dcache_line(a);=0A=
+		flush_scache_line(a); // Hit_Writeback_Inv_SD=0A=
+		if (a =3D=3D end) break;=0A=
+		a +=3D sc_lsize;=0A=
+	}=0A=
+}=0A=
+=0A=
+static void sr71000_dma_cache_wback_inv_tc(unsigned long addr,=0A=
+					  unsigned long size)=0A=
+{=0A=
+	unsigned long end, a;=0A=
+=0A=
+	a =3D addr & ~(sc_lsize - 1);=0A=
+	end =3D (addr + size) & ~(sc_lsize - 1);=0A=
+	while (1) {=0A=
+		flush_dcache_line(a);=0A=
+		flush_scache_line(a); // Hit_Writeback_Inv_SD=0A=
+		flush_tcache_line(a); // Hit_Invalidate_T=0A=
+		if (a =3D=3D end) break;=0A=
+		a +=3D sc_lsize;=0A=
+	}=0A=
+}=0A=
+=0A=
+/* It is kind of silly to writeback for the inv case.. Oh well */=0A=
+static void sr71000_dma_cache_inv_sc(unsigned long addr, unsigned long =
size)=0A=
+{=0A=
+	unsigned long end, a;=0A=
+=0A=
+	if (size >=3D scache_size) {=0A=
+		sr71000_nuke_caches();=0A=
+		return;=0A=
+	}=0A=
+=0A=
+	a =3D addr & ~(sc_lsize - 1);=0A=
+	end =3D (addr + size) & ~(sc_lsize - 1);=0A=
+	while (1) {=0A=
+		flush_dcache_line(a);=0A=
+		flush_scache_line(a); // Hit_Writeback_Inv_SD =0A=
+		if (a =3D=3D end) break;=0A=
+		a +=3D sc_lsize;=0A=
+	}=0A=
+}=0A=
+=0A=
+static void sr71000_dma_cache_inv_tc(unsigned long addr, unsigned long =
size)=0A=
+{=0A=
+	unsigned long end, a;=0A=
+=0A=
+	a =3D addr & ~(sc_lsize - 1);=0A=
+	end =3D (addr + size) & ~(sc_lsize - 1);=0A=
+	while (1) {=0A=
+		flush_dcache_line(a);=0A=
+		flush_scache_line(a); // Hit_Writeback_Inv_SD=0A=
+		flush_tcache_line(a); // Hit_Invalidate_T=0A=
+		if (a =3D=3D end) break;=0A=
+		a +=3D sc_lsize;=0A=
+	}=0A=
+}=0A=
+=0A=
+static void sr71000_dma_cache_wback(unsigned long addr, unsigned long =
size)=0A=
+{=0A=
+	panic("sr71000_dma_cache_wback called - should not happen.");=0A=
+}=0A=
+=0A=
+/*=0A=
+ * While we're protected against bad userland addresses we don't care=0A=
+ * very much about what happens in that case.  Usually a segmentation=0A=
+ * fault will dump the process later on anyway ...=0A=
+ */=0A=
+static void sr71000_flush_cache_sigtramp(unsigned long addr)=0A=
+{=0A=
+	protected_writeback_dcache_line(addr & ~(dc_lsize - 1));=0A=
+	protected_flush_icache_line(addr & ~(ic_lsize - 1));=0A=
+}=0A=
+=0A=
+/* Detect and size the various caches. */=0A=
+static void __init probe_icache(unsigned long config,unsigned long =
config1)=0A=
+{=0A=
+	unsigned int lsize;=0A=
+=0A=
+	config1 =3D read_mips32_cp0_config1(); =0A=
+	=0A=
+	if ((lsize =3D ((config1 >> 19) & 7)))=0A=
+		mips_cpu.icache.linesz =3D 2 << lsize;=0A=
+	else =0A=
+		mips_cpu.icache.linesz =3D lsize;=0A=
+	mips_cpu.icache.sets =3D 64 << ((config1 >> 22) & 7);=0A=
+	mips_cpu.icache.ways =3D 1 + ((config1 >> 16) & 7);=0A=
+	=0A=
+	ic_lsize =3D mips_cpu.icache.linesz;=0A=
+	icache_size =3D mips_cpu.icache.sets * mips_cpu.icache.ways * =0A=
+		ic_lsize;=0A=
+	printk("Primary instruction cache %dkb, linesize %d bytes (%d ways)\n",=0A=
+	       icache_size >> 10, ic_lsize, mips_cpu.icache.ways);=0A=
+}=0A=
+=0A=
+static void __init probe_dcache(unsigned long config,unsigned long =
config1)=0A=
+{=0A=
+	unsigned int lsize;=0A=
+=0A=
+	if ((lsize =3D ((config1 >> 10) & 7)))=0A=
+		mips_cpu.dcache.linesz =3D 2 << lsize;=0A=
+	else =0A=
+		mips_cpu.dcache.linesz =3D lsize;=0A=
+	mips_cpu.dcache.sets =3D 64 << ((config1 >> 13) & 7);=0A=
+	mips_cpu.dcache.ways =3D 1 + ((config1 >> 7) & 7);=0A=
+	=0A=
+	dc_lsize =3D mips_cpu.dcache.linesz;=0A=
+	dcache_size =3D =0A=
+		mips_cpu.dcache.sets * mips_cpu.dcache.ways=0A=
+		* dc_lsize;=0A=
+	printk("Primary data cache %dkb, linesize %d bytes (%d ways)\n",=0A=
+	       dcache_size >> 10, dc_lsize, mips_cpu.dcache.ways);=0A=
+}=0A=
+=0A=
+static void __init probe_scache(unsigned long config,unsigned long =
config2)=0A=
+{=0A=
+	unsigned int lsize;=0A=
+=0A=
+	if ((lsize =3D ((config2 >> 4) & 7)))=0A=
+		mips_cpu.scache.linesz =3D 2 << lsize;=0A=
+	else =0A=
+		mips_cpu.scache.linesz =3D lsize;=0A=
+	=0A=
+	mips_cpu.scache.sets =3D 64 << ((config2 >> 8) & 7);=0A=
+	mips_cpu.scache.ways =3D 1 + ((config2 >> 0) & 7);=0A=
+=0A=
+	sc_lsize =3D mips_cpu.scache.linesz;=0A=
+	scache_size =3D mips_cpu.scache.sets * mips_cpu.scache.ways * sc_lsize;=0A=
+	=0A=
+	printk("Secondary cache %dK, linesize %d bytes (%d ways)\n",=0A=
+	       scache_size >> 10, sc_lsize, mips_cpu.scache.ways);=0A=
+}=0A=
+=0A=
+static void __init probe_tcache(unsigned long config,unsigned long =
config2)=0A=
+{=0A=
+	unsigned int lsize;=0A=
+=0A=
+	/* Firmware or prom_init is required to configure the size of the =0A=
+	   tertiary cache in config2 and set the TE bit in config2 to signal =0A=
+	   the external SRAM chips are present. */=0A=
+	if ((config2 & (1<<28)) =3D=3D 0)=0A=
+		return;=0A=
+	=0A=
+	if ((lsize =3D ((config2 >> 20) & 7)))=0A=
+		mips_cpu.tcache.linesz =3D 2 << lsize;=0A=
+	else =0A=
+		mips_cpu.tcache.linesz =3D lsize;=0A=
+	=0A=
+	mips_cpu.tcache.sets =3D 64 << ((config2 >> 24) & 7);=0A=
+	mips_cpu.tcache.ways =3D 1 + ((config2 >> 16) & 7);=0A=
+=0A=
+	tc_lsize =3D mips_cpu.tcache.linesz;=0A=
+	tcache_size =3D mips_cpu.tcache.sets * mips_cpu.tcache.ways * tc_lsize;=0A=
+	=0A=
+	printk("Tertiary cache %dK, linesize %d bytes, blocksize %d "=0A=
+	       "bytes (%d ways)\n",=0A=
+	       tcache_size >> 10, sc_lsize, tc_lsize, mips_cpu.tcache.ways);=0A=
+}=0A=
+=0A=
+static void __init setup_scache_funcs(void)=0A=
+{=0A=
+        _flush_cache_all =3D sr71000_flush_cache_all_pc;=0A=
+        ___flush_cache_all =3D sr71000_nuke_caches;=0A=
+	_flush_cache_mm =3D sr71000_flush_cache_mm_pc;=0A=
+	_flush_cache_range =3D sr71000_flush_cache_range_pc;=0A=
+	_flush_cache_page =3D sr71000_flush_cache_page_pc;=0A=
+	_flush_page_to_ram =3D sr71000_flush_page_to_ram_pc;=0A=
+=0A=
+        // These can only be done on the primary cache.=0A=
+	_clear_page =3D (void *)mips32_clear_page_dc;=0A=
+	_copy_page =3D (void *)mips32_copy_page_dc;=0A=
+=0A=
+	_flush_icache_page =3D sr71000_flush_icache_page;=0A=
+=0A=
+	if (tcache_size =3D=3D 0)=0A=
+	{=0A=
+		_dma_cache_wback_inv =3D sr71000_dma_cache_wback_inv_sc;=0A=
+		_dma_cache_inv =3D sr71000_dma_cache_inv_sc;=0A=
+	}=0A=
+	else=0A=
+	{=0A=
+		_dma_cache_wback_inv =3D sr71000_dma_cache_wback_inv_tc;=0A=
+		_dma_cache_inv =3D sr71000_dma_cache_inv_tc;=0A=
+	}=0A=
+		=0A=
+	_dma_cache_wback =3D sr71000_dma_cache_wback;=0A=
+}=0A=
+=0A=
+/* This implements the cache intialization stuff from the SR71000 =
guide. After=0A=
+   this all the caches will be empty and ready to run. It must be run =
from=0A=
+   uncached space. */=0A=
+static void __init clear_enable_caches(unsigned long config)=0A=
+{=0A=
+	config =3D (config & (~CONF_CM_CMASK)) | CONF_CM_CACHABLE_NONCOHERENT;=0A=
+	printk("clear_enable_caches: config: 0x%08lx\n", config);=0A=
+	=0A=
+	/* Primary cache init (7.1.1)=0A=
+	   SR71000 Primary Cache initialization of 4-way, 32 Kbyte line I/D =0A=
+	   caches. */=0A=
+	__asm__ __volatile__ =0A=
+		(=0A=
+		 ".set push\n"=0A=
+		 ".set noreorder\n"=0A=
+		 ".set noat\n"=0A=
+		 ".set mips64\n"=0A=
+#if 0=0A=
+		 // Enable KSEG0 caching=0A=
+		 " mtc0 %0, $16\n"=0A=
+#endif=0A=
+		 =0A=
+		 /* It is recommended that parity be disabled during cache =0A=
+		    initialization. */=0A=
+		 " mfc0 $1, $12\n"      // Read CP0 Status Register.=0A=
+		 " li $2, 0x00010000\n" // DE Bit.=0A=
+		 " or $2, $1, $2\n"=0A=
+		 " mtc0 $2, $12\n"     // Disable Parity.=0A=
+		 =0A=
+		 " ori $3, %1, 0x1FE0\n" // 256 sets.=0A=
+		 " mtc0 $0, $28\n" // Set CP0 Tag_Lo Register=0A=
+		 "1:\n"=0A=
+		 " cache 8, 0x0000($3)\n" // Index_Store_Tag_I=0A=
+		 " cache 8, 0x2000($3)\n" // Index_Store_Tag_I=0A=
+		 " cache 8, 0x4000($3)\n" // Index_Store_Tag_I=0A=
+		 " cache 8, 0x6000($3)\n" // Index_Store_Tag_I=0A=
+		 " cache 9, 0x0000($3)\n" // Index_Store_Tag_D=0A=
+		 " cache 9, 0x2000($3)\n" // Index_Store_Tag_D=0A=
+		 " cache 9, 0x4000($3)\n" // Index_Store_Tag_D=0A=
+		 " cache 9, 0x6000($3)\n" // Index_Store_Tag_D=0A=
+		 " bne $3, %1, 1b\n"=0A=
+		 " addiu $3, $3, -0x0020\n" // 32 byte cache line=0A=
+		 " mtc0 $1, $12\n" // Put original back in Status Register.=0A=
+		 ".set pop\n"=0A=
+		 :=0A=
+		 : "r"(config), "r"(KSEG0) // arbitary unmapped address=0A=
+		 : "$1","$2","$3");=0A=
+=0A=
+	/* Secondary and tertiary flash invalidate (7.5.18)	   =0A=
+	    This code fragment, invalidates (also disables), and=0A=
+	    restores (re-enables) the secondary and tertiary caches.=0A=
+	    Ensure system is operating in uncached space. */=0A=
+	__asm__ __volatile__ =0A=
+		 (=0A=
+		 ".set push\n"=0A=
+		 ".set noreorder\n"=0A=
+		 ".set noat\n"=0A=
+		 ".set mips64\n"=0A=
+		 "  sync\n"			// flush core pipeline=0A=
+		 "  lw $2, 0(%0)\n"		// flush pending accesses=0A=
+		 "  bne $2, $2, 1f\n"		// prevent I-fetches=0A=
+		 "  nop\n"=0A=
+		 "1: mfc0 $1, $16, 2\n"		// save current Config2=0A=
+		 "  li $2, 0x20002000\n"	// set flash invalidation bits=0A=
+		 "  or $2, $1, $2\n"=0A=
+		 "  mtc0 $2, $16, 2\n"		// invalidate & disable caches=0A=
+		 "  li $2, 0x10001000\n"        // enable L2 and L3=0A=
+		 "  or $1, $1, $2\n"=0A=
+		 "  mtc0 $1, $16, 2\n"=0A=
+		 ".set pop\n"=0A=
+		 :=0A=
+		 : "r"(KSEG1)=0A=
+		 : "$1","$2");		 =0A=
+}=0A=
+=0A=
+void __init ld_mmu_sr71000(void)=0A=
+{=0A=
+	unsigned long config =3D read_32bit_cp0_registerx(CP0_CONFIG,0);=0A=
+	unsigned long config1 =3D read_32bit_cp0_registerx(CP0_CONFIG,1);=0A=
+	unsigned long config2 =3D read_32bit_cp0_registerx(CP0_CONFIG,2);=0A=
+	void (*kseg1_cec)(unsigned long config) =3D (void =
*)KSEG1ADDR(&clear_enable_caches);=0A=
+=0A=
+	// Should never happen=0A=
+        if (!(config & (1 << 31)) || !(config1 & (1 << 31)))=0A=
+		panic("sr71000 does not have necessary config registers");=0A=
+	=0A=
+	probe_icache(config,config1);=0A=
+	probe_dcache(config,config1);=0A=
+	probe_scache(config,config2);=0A=
+	probe_tcache(config,config2);=0A=
+	setup_scache_funcs();=0A=
+=0A=
+	// Make sure the the secondary cache is turned on (always present)=0A=
+	write_32bit_cp0_registerx(CP0_CONFIG,2,config2 | (1<<12));=0A=
+	=0A=
+#ifndef CONFIG_MIPS_UNCACHED=0A=
+	if ((config & CONF_CM_CMASK) !=3D CONF_CM_UNCACHED)=0A=
+                printk("Caches already enabled, leaving alone..\n");=0A=
+        else=0A=
+                kseg1_cec(config);=0A=
+#endif=0A=
+						  =0A=
+	_flush_cache_sigtramp =3D sr71000_flush_cache_sigtramp;=0A=
+	_flush_icache_range =3D sr71000_flush_icache_range;=0A=
+}=0A=
+=0A=
+/* Jack Veenstra: added access routines for CP0 registers.=0A=
+ * The ability to write certain CP0 registers is a huge security hole,=0A=
+ * so we limit it to processes with root privilege.=0A=
+ */=0A=
+=0A=
+#include <asm/uaccess.h>=0A=
+=0A=
+asmlinkage long sys_get_cp0_reg(int reg, int select, unsigned long =
*pval)=0A=
+{=0A=
+    unsigned long	val =3D 0;=0A=
+=0A=
+    switch (reg) {=0A=
+	case 0: val =3D read_32bit_cp0_register($0); break;=0A=
+	case 1: val =3D read_32bit_cp0_register($1); break;=0A=
+	case 2: val =3D read_32bit_cp0_register($2); break;=0A=
+	case 3: val =3D read_32bit_cp0_register($3); break;=0A=
+	case 4: val =3D read_32bit_cp0_register($4); break;=0A=
+	case 5: val =3D read_32bit_cp0_register($5); break;=0A=
+	case 6: val =3D read_32bit_cp0_register($6); break;=0A=
+	case 7: val =3D read_32bit_cp0_register($7); break;=0A=
+	case 8: val =3D read_32bit_cp0_register($8); break;=0A=
+	case 9: val =3D read_32bit_cp0_register($9); break;=0A=
+	case 10: val =3D read_32bit_cp0_register($10); break;=0A=
+	case 11: val =3D read_32bit_cp0_register($11); break;=0A=
+	case 12: val =3D read_32bit_cp0_register($12); break;=0A=
+	case 13: val =3D read_32bit_cp0_register($13); break;=0A=
+	case 14: val =3D read_32bit_cp0_register($14); break;=0A=
+	case 15: val =3D read_32bit_cp0_register($15); break;=0A=
+	case 20: val =3D read_32bit_cp0_register($20); break;=0A=
+	case 26: val =3D read_32bit_cp0_register($26); break;=0A=
+	case 27: val =3D read_32bit_cp0_register($27); break;=0A=
+	case 28: val =3D read_32bit_cp0_register($28); break;=0A=
+	case 29: val =3D read_32bit_cp0_register($29); break;=0A=
+	case 30: val =3D read_32bit_cp0_register($30); break;=0A=
+=0A=
+	case 16:=0A=
+	    switch (select) {=0A=
+		case 0: val =3D read_32bit_cp0_registerx($16,0); break;=0A=
+		case 1: val =3D read_32bit_cp0_registerx($16,1); break;=0A=
+		case 2: val =3D read_32bit_cp0_registerx($16,2); break;=0A=
+	    }=0A=
+	    break;=0A=
+	case 18:=0A=
+	    switch (select) {=0A=
+		case 0: val =3D read_32bit_cp0_registerx($18,0); break;=0A=
+		case 1: val =3D read_32bit_cp0_registerx($18,1); break;=0A=
+	    }=0A=
+	    break;=0A=
+	case 19:=0A=
+	    switch (select) {=0A=
+		case 0: val =3D read_32bit_cp0_registerx($19,0); break;=0A=
+		case 1: val =3D read_32bit_cp0_registerx($19,1); break;=0A=
+	    }=0A=
+	    break;=0A=
+	case 25:=0A=
+	    switch (select) {=0A=
+		case 0: val =3D read_32bit_cp0_registerx($25,0); break;=0A=
+		case 1: val =3D read_32bit_cp0_registerx($25,1); break;=0A=
+		case 2: val =3D read_32bit_cp0_registerx($25,2); break;=0A=
+		case 3: val =3D read_32bit_cp0_registerx($25,3); break;=0A=
+	    }=0A=
+	    break;=0A=
+    }=0A=
+    if (copy_to_user(pval, &val, sizeof(*pval)))=0A=
+	return -EFAULT;=0A=
+    return 0;=0A=
+}=0A=
+=0A=
+asmlinkage long sys_set_cp0_reg(int reg, int select, unsigned long val)=0A=
+{=0A=
+    if (!capable(CAP_SYS_ADMIN))=0A=
+	return -EPERM;=0A=
+=0A=
+    switch (reg) {=0A=
+	case 2: write_32bit_cp0_register($2, val); break;=0A=
+	case 3: write_32bit_cp0_register($3, val); break;=0A=
+	case 4: write_32bit_cp0_register($4, val); break;=0A=
+	case 5: write_32bit_cp0_register($5, val); break;=0A=
+	case 6: write_32bit_cp0_register($6, val); break;=0A=
+	case 7: write_32bit_cp0_register($7, val); break;=0A=
+	case 9: write_32bit_cp0_register($9, val); break;=0A=
+	case 10: write_32bit_cp0_register($10, val); break;=0A=
+	case 11: write_32bit_cp0_register($11, val); break;=0A=
+	case 12: write_32bit_cp0_register($12, val); break;=0A=
+	case 13: write_32bit_cp0_register($13, val); break;=0A=
+	case 14: write_32bit_cp0_register($14, val); break;=0A=
+	case 20: write_32bit_cp0_register($20, val); break;=0A=
+	case 26: write_32bit_cp0_register($26, val); break;=0A=
+	case 28: write_32bit_cp0_register($28, val); break;=0A=
+	case 29: write_32bit_cp0_register($29, val); break;=0A=
+	case 30: write_32bit_cp0_register($30, val); break;=0A=
+=0A=
+	case 16:=0A=
+	    switch (select) {=0A=
+		case 0: write_32bit_cp0_registerx($16,0, val); break;=0A=
+		case 2: write_32bit_cp0_registerx($16,2, val); break;=0A=
+	    }=0A=
+	    break;=0A=
+	case 18:=0A=
+	    switch (select) {=0A=
+		case 0: write_32bit_cp0_registerx($18,0, val); break;=0A=
+		case 1: write_32bit_cp0_registerx($18,1, val); break;=0A=
+	    }=0A=
+	    break;=0A=
+	case 19:=0A=
+	    switch (select) {=0A=
+		case 0: write_32bit_cp0_registerx($19,0, val); break;=0A=
+		case 1: write_32bit_cp0_registerx($19,1, val); break;=0A=
+	    }=0A=
+	    break;=0A=
+	case 25:=0A=
+	    switch (select) {=0A=
+		case 0: write_32bit_cp0_registerx($25,0, val); break;=0A=
+		case 1: write_32bit_cp0_registerx($25,1, val); break;=0A=
+		case 2: write_32bit_cp0_registerx($25,2, val); break;=0A=
+		case 3: write_32bit_cp0_registerx($25,3, val); break;=0A=
+	    }=0A=
+	    break;=0A=
+    }=0A=
+    return 0;=0A=
+}=0A=
+=0A=
+static unsigned long long Perf_counter0;=0A=
+static unsigned long long Perf_counter1;=0A=
+=0A=
+/* This routine is called from the context of an interrupt handler=0A=
+ * when a timer or performance counter interrupt occurs.=0A=
+ */=0A=
+asmlinkage void perf_counter_handler(void)=0A=
+{=0A=
+    unsigned int	val;=0A=
+#if 0=0A=
+    static int	calls =3D 0;=0A=
+=0A=
+    if (calls >=3D 1)=0A=
+	debug_led0_on();=0A=
+    if (calls >=3D 10)=0A=
+	debug_led1_on();=0A=
+    if (calls >=3D 100)=0A=
+	debug_led2_on();=0A=
+    calls +=3D 1;=0A=
+=0A=
+    val =3D read_32bit_cp0_register($9);=0A=
+    printk(KERN_CRIT "perf_counter_handler: cycle count: 0x%lx\n", val);=0A=
+#endif=0A=
+    =0A=
+    /* Write to the CP0 compare register to clear a possible=0A=
+     * timer interrupt.=0A=
+     */=0A=
+    write_32bit_cp0_register($11, 0);=0A=
+=0A=
+    val =3D read_32bit_cp0_registerx($25, 1);=0A=
+#if 0=0A=
+    printk(KERN_ERR "perf_counter_handler: perf_counter 0: 0x%lx\n", =
val);=0A=
+#endif=0A=
+    if (val & 0x80000000) {=0A=
+	Perf_counter0 +=3D val;=0A=
+	write_32bit_cp0_registerx($25, 1, 0);=0A=
+    }=0A=
+=0A=
+    val =3D read_32bit_cp0_registerx($25, 3);=0A=
+#if 0=0A=
+    printk("perf_counter_handler: perf_counter 1: 0x%lx\n", val);=0A=
+#endif=0A=
+    if (val & 0x80000000) {=0A=
+	Perf_counter1 +=3D val;=0A=
+	write_32bit_cp0_registerx($25, 3, 0);=0A=
+    }=0A=
+}=0A=
+=0A=
+/* Start the given performance counter to count the events specified=0A=
+ * by "event".  The "mode" argument limits the counting to certain modes=0A=
+ * (such as kernel mode, supervisor mode, or user mode).=0A=
+ */=0A=
+asmlinkage long sys_start_perf_counter(int cnum, int event, int mode)=0A=
+{=0A=
+    unsigned int	val;=0A=
+=0A=
+    /* Enable timer and performance counter interrupts */=0A=
+    set_cp0_status(IE_IRQ5);=0A=
+=0A=
+    val =3D (event << 5) | mode | 0x10;=0A=
+    if (cnum =3D=3D 0) {=0A=
+	/* Clear the current event counter */=0A=
+	write_32bit_cp0_registerx($25, 0, 0);=0A=
+	write_32bit_cp0_registerx($25, 1, 0);=0A=
+	Perf_counter0 =3D 0;=0A=
+=0A=
+	/* Start counting the new events */=0A=
+	write_32bit_cp0_registerx($25, 0, val);=0A=
+    } else {=0A=
+	/* Clear the current event counter */=0A=
+	write_32bit_cp0_registerx($25, 2, 0);=0A=
+	write_32bit_cp0_registerx($25, 3, 0);=0A=
+	Perf_counter1 =3D 0;=0A=
+=0A=
+	/* Start counting the new events */=0A=
+	write_32bit_cp0_registerx($25, 2, val);=0A=
+    }=0A=
+=0A=
+    return 0;=0A=
+}=0A=
+=0A=
+/* Read the current value of the specified performance counter.=0A=
+ * The value is returned in the location pointed to by pval.=0A=
+ */=0A=
+asmlinkage long sys_read_perf_counter(int cnum, long long *pval)=0A=
+{=0A=
+    unsigned long long	val;=0A=
+    unsigned long	flags;=0A=
+=0A=
+    if (cnum =3D=3D 0) {=0A=
+	/* Disable interrupts */=0A=
+	save_and_cli(flags);=0A=
+	val =3D read_32bit_cp0_registerx($25, 1);=0A=
+	val +=3D Perf_counter0;=0A=
+	restore_flags(flags);=0A=
+    } else {=0A=
+	/* Disable interrupts */=0A=
+	save_and_cli(flags);=0A=
+	val =3D read_32bit_cp0_registerx($25, 3);=0A=
+	val +=3D Perf_counter1;=0A=
+	restore_flags(flags);=0A=
+    }=0A=
+=0A=
+    if (copy_to_user(pval, &val, sizeof(*pval)))=0A=
+	return -EFAULT;=0A=
+    return 0;=0A=
+}=0A=
+=0A=
+/* Stop the given performance counter and clear it.=0A=
+ * If pval is non-NULL, return the current value of the counter=0A=
+ * in the location pointed to by pval.=0A=
+ */=0A=
+asmlinkage long sys_stop_perf_counter(int cnum, long long *pval)=0A=
+{=0A=
+    unsigned long long	val;=0A=
+    unsigned long	flags;=0A=
+=0A=
+    if (cnum =3D=3D 0) {=0A=
+	/* Disable interrupts */=0A=
+	save_and_cli(flags);=0A=
+	val =3D read_32bit_cp0_registerx($25, 1);=0A=
+	val +=3D Perf_counter0;=0A=
+	restore_flags(flags);=0A=
+=0A=
+	/* Stop counting and clear the count values */=0A=
+	write_32bit_cp0_registerx($25, 0, 0);=0A=
+	write_32bit_cp0_registerx($25, 1, 0);=0A=
+	Perf_counter0 =3D 0;=0A=
+    } else {=0A=
+	/* Disable interrupts */=0A=
+	save_and_cli(flags);=0A=
+	val =3D read_32bit_cp0_registerx($25, 3);=0A=
+	val +=3D Perf_counter1;=0A=
+	restore_flags(flags);=0A=
+=0A=
+	/* Stop counting and clear the count values */=0A=
+	write_32bit_cp0_registerx($25, 2, 0);=0A=
+	write_32bit_cp0_registerx($25, 3, 0);=0A=
+	Perf_counter1 =3D 0;=0A=
+    }=0A=
+=0A=
+    if (pval && copy_to_user(pval, &val, sizeof(*pval)))=0A=
+	return -EFAULT;=0A=
+    return 0;=0A=
+}=0A=
--- /dev/null	Tue May  5 13:32:27 1998=0A=
+++ include/asm-mips/mv64340.h	Fri Nov  8 14:56:51 2002=0A=
@@ -0,0 +1,1037 @@=0A=
+/***********************************************************************=
********=0A=
+* mv64340.h - MV-64340 Internal registers definition file.=0A=
+*=0A=
+* Copyright 2002 Momentum Computer, Inc.=0A=
+* Copyright 2002 GALILEO TECHNOLOGY, LTD. =0A=
+*=0A=
+* This program is free software; you can redistribute  it and/or modify =
it=0A=
+* under  the terms of  the GNU General  Public License as published by =
the=0A=
+* Free Software Foundation;  either version 2 of the  License, or (at =
your=0A=
+* option) any later version.=0A=
+*=0A=
+************************************************************************=
*******/=0A=
+=0A=
+#ifndef __MV64340_H__=0A=
+#define __MV64340_H__=0A=
+=0A=
+#include <asm/mv64340_dep.h>=0A=
+=0A=
+/****************************************/=0A=
+/* Processor Address Space              */=0A=
+/****************************************/=0A=
+=0A=
+/* DDR SDRAM BAR and size registers */=0A=
+=0A=
+#define MV64340_CS_0_BASE_ADDR                                      =
0x008=0A=
+#define MV64340_CS_0_SIZE                                           =
0x010=0A=
+#define MV64340_CS_1_BASE_ADDR                                      =
0x208=0A=
+#define MV64340_CS_1_SIZE                                           =
0x210=0A=
+#define MV64340_CS_2_BASE_ADDR                                      =
0x018=0A=
+#define MV64340_CS_2_SIZE                                           =
0x020=0A=
+#define MV64340_CS_3_BASE_ADDR                                      =
0x218=0A=
+#define MV64340_CS_3_SIZE                                           =
0x220=0A=
+=0A=
+/* Devices BAR and size registers */=0A=
+=0A=
+#define MV64340_DEV_CS0_BASE_ADDR                                   =
0x028=0A=
+#define MV64340_DEV_CS0_SIZE                                        =
0x030=0A=
+#define MV64340_DEV_CS1_BASE_ADDR                                   =
0x228=0A=
+#define MV64340_DEV_CS1_SIZE                                        =
0x230=0A=
+#define MV64340_DEV_CS2_BASE_ADDR                                   =
0x248=0A=
+#define MV64340_DEV_CS2_SIZE                                        =
0x250=0A=
+#define MV64340_DEV_CS3_BASE_ADDR                                   =
0x038=0A=
+#define MV64340_DEV_CS3_SIZE                                        =
0x040=0A=
+#define MV64340_BOOTCS_BASE_ADDR                                    =
0x238=0A=
+#define MV64340_BOOTCS_SIZE                                         =
0x240=0A=
+=0A=
+/* PCI 0 BAR and size registers */=0A=
+=0A=
+#define MV64340_PCI_0_IO_BASE_ADDR                                  =
0x048=0A=
+#define MV64340_PCI_0_IO_SIZE                                       =
0x050=0A=
+#define MV64340_PCI_0_MEMORY0_BASE_ADDR                             =
0x058=0A=
+#define MV64340_PCI_0_MEMORY0_SIZE                                  =
0x060=0A=
+#define MV64340_PCI_0_MEMORY1_BASE_ADDR                             =
0x080=0A=
+#define MV64340_PCI_0_MEMORY1_SIZE                                  =
0x088=0A=
+#define MV64340_PCI_0_MEMORY2_BASE_ADDR                             =
0x258=0A=
+#define MV64340_PCI_0_MEMORY2_SIZE                                  =
0x260=0A=
+#define MV64340_PCI_0_MEMORY3_BASE_ADDR                             =
0x280=0A=
+#define MV64340_PCI_0_MEMORY3_SIZE                                  =
0x288=0A=
+=0A=
+/* PCI 1 BAR and size registers */=0A=
+#define MV64340_PCI_1_IO_BASE_ADDR                                  =
0x090=0A=
+#define MV64340_PCI_1_IO_SIZE                                       =
0x098=0A=
+#define MV64340_PCI_1_MEMORY0_BASE_ADDR                             =
0x0a0=0A=
+#define MV64340_PCI_1_MEMORY0_SIZE                                  =
0x0a8=0A=
+#define MV64340_PCI_1_MEMORY1_BASE_ADDR                             =
0x0b0=0A=
+#define MV64340_PCI_1_MEMORY1_SIZE                                  =
0x0b8=0A=
+#define MV64340_PCI_1_MEMORY2_BASE_ADDR                             =
0x2a0=0A=
+#define MV64340_PCI_1_MEMORY2_SIZE                                  =
0x2a8=0A=
+#define MV64340_PCI_1_MEMORY3_BASE_ADDR                             =
0x2b0=0A=
+#define MV64340_PCI_1_MEMORY3_SIZE                                  =
0x2b8=0A=
+=0A=
+/* SRAM base address */=0A=
+#define MV64340_INTEGRATED_SRAM_BASE_ADDR                           =
0x268=0A=
+=0A=
+/* internal registers space base address */=0A=
+#define MV64340_INTERNAL_SPACE_BASE_ADDR                            =
0x068=0A=
+=0A=
+/* Enables the CS , DEV_CS , PCI 0 and PCI 1 =0A=
+   windows above */=0A=
+#define MV64340_BASE_ADDR_ENABLE                                    =
0x278=0A=
+=0A=
+/****************************************/=0A=
+/* PCI remap registers                  */=0A=
+/****************************************/=0A=
+      /* PCI 0 */=0A=
+#define MV64340_PCI_0_IO_ADDR_REMAP                                 =
0x0f0=0A=
+#define MV64340_PCI_0_MEMORY0_LOW_ADDR_REMAP                        =
0x0f8=0A=
+#define MV64340_PCI_0_MEMORY0_HIGH_ADDR_REMAP                       =
0x320=0A=
+#define MV64340_PCI_0_MEMORY1_LOW_ADDR_REMAP                        =
0x100=0A=
+#define MV64340_PCI_0_MEMORY1_HIGH_ADDR_REMAP                       =
0x328=0A=
+#define MV64340_PCI_0_MEMORY2_LOW_ADDR_REMAP                        =
0x2f8=0A=
+#define MV64340_PCI_0_MEMORY2_HIGH_ADDR_REMAP                       =
0x330=0A=
+#define MV64340_PCI_0_MEMORY3_LOW_ADDR_REMAP                        =
0x300=0A=
+#define MV64340_PCI_0_MEMORY3_HIGH_ADDR_REMAP                       =
0x338=0A=
+      /* PCI 1 */=0A=
+#define MV64340_PCI_1_IO_ADDR_REMAP                                 =
0x108=0A=
+#define MV64340_PCI_1_MEMORY0_LOW_ADDR_REMAP                        =
0x110=0A=
+#define MV64340_PCI_1_MEMORY0_HIGH_ADDR_REMAP                       =
0x340=0A=
+#define MV64340_PCI_1_MEMORY1_LOW_ADDR_REMAP                        =
0x118=0A=
+#define MV64340_PCI_1_MEMORY1_HIGH_ADDR_REMAP                       =
0x348=0A=
+#define MV64340_PCI_1_MEMORY2_LOW_ADDR_REMAP                        =
0x310=0A=
+#define MV64340_PCI_1_MEMORY2_HIGH_ADDR_REMAP                       =
0x350=0A=
+#define MV64340_PCI_1_MEMORY3_LOW_ADDR_REMAP                        =
0x318=0A=
+#define MV64340_PCI_1_MEMORY3_HIGH_ADDR_REMAP                       =
0x358=0A=
+ =0A=
+#define MV64340_CPU_PCI_0_HEADERS_RETARGET_CONTROL                  =
0x3b0=0A=
+#define MV64340_CPU_PCI_0_HEADERS_RETARGET_BASE                     =
0x3b8=0A=
+#define MV64340_CPU_PCI_1_HEADERS_RETARGET_CONTROL                  =
0x3c0=0A=
+#define MV64340_CPU_PCI_1_HEADERS_RETARGET_BASE                     =
0x3c8=0A=
+#define MV64340_CPU_GE_HEADERS_RETARGET_CONTROL                     =
0x3d0=0A=
+#define MV64340_CPU_GE_HEADERS_RETARGET_BASE                        =
0x3d8=0A=
+#define MV64340_CPU_IDMA_HEADERS_RETARGET_CONTROL                   =
0x3e0=0A=
+#define MV64340_CPU_IDMA_HEADERS_RETARGET_BASE                      =
0x3e8=0A=
+=0A=
+/****************************************/=0A=
+/*         CPU Control Registers        */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_CPU_CONFIG                                          =
0x000=0A=
+#define MV64340_CPU_MODE                                            =
0x120=0A=
+#define MV64340_CPU_MASTER_CONTROL                                  =
0x160=0A=
+#define MV64340_CPU_CROSS_BAR_CONTROL_LOW                           =
0x150=0A=
+#define MV64340_CPU_CROSS_BAR_CONTROL_HIGH                          =
0x158=0A=
+#define MV64340_CPU_CROSS_BAR_TIMEOUT                               =
0x168=0A=
+=0A=
+/****************************************/=0A=
+/* SMP RegisterS                        */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_SMP_WHO_AM_I                                        =
0x200=0A=
+#define MV64340_SMP_CPU0_DOORBELL                                   =
0x214=0A=
+#define MV64340_SMP_CPU0_DOORBELL_CLEAR                             =
0x21C=0A=
+#define MV64340_SMP_CPU1_DOORBELL                                   =
0x224=0A=
+#define MV64340_SMP_CPU1_DOORBELL_CLEAR                             =
0x22C=0A=
+#define MV64340_SMP_CPU0_DOORBELL_MASK                              =
0x234=0A=
+#define MV64340_SMP_CPU1_DOORBELL_MASK                              =
0x23C=0A=
+#define MV64340_SMP_SEMAPHOR0                                       =
0x244=0A=
+#define MV64340_SMP_SEMAPHOR1                                       =
0x24c=0A=
+#define MV64340_SMP_SEMAPHOR2                                       =
0x254=0A=
+#define MV64340_SMP_SEMAPHOR3                                       =
0x25c=0A=
+#define MV64340_SMP_SEMAPHOR4                                       =
0x264=0A=
+#define MV64340_SMP_SEMAPHOR5                                       =
0x26c=0A=
+#define MV64340_SMP_SEMAPHOR6                                       =
0x274=0A=
+#define MV64340_SMP_SEMAPHOR7                                       =
0x27c=0A=
+=0A=
+/****************************************/=0A=
+/*  CPU Sync Barrier Register           */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_CPU_0_SYNC_BARRIER_TRIGGER                          =
0x0c0=0A=
+#define MV64340_CPU_0_SYNC_BARRIER_VIRTUAL                          =
0x0c8=0A=
+#define MV64340_CPU_1_SYNC_BARRIER_TRIGGER                          =
0x0d0=0A=
+#define MV64340_CPU_1_SYNC_BARRIER_VIRTUAL                          =
0x0d8=0A=
+=0A=
+/****************************************/=0A=
+/* CPU Access Protect                   */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_CPU_PROTECT_WINDOW_0_BASE_ADDR                      =
0x180=0A=
+#define MV64340_CPU_PROTECT_WINDOW_0_SIZE                           =
0x188=0A=
+#define MV64340_CPU_PROTECT_WINDOW_1_BASE_ADDR                      =
0x190=0A=
+#define MV64340_CPU_PROTECT_WINDOW_1_SIZE                           =
0x198=0A=
+#define MV64340_CPU_PROTECT_WINDOW_2_BASE_ADDR                      =
0x1a0=0A=
+#define MV64340_CPU_PROTECT_WINDOW_2_SIZE                           =
0x1a8=0A=
+#define MV64340_CPU_PROTECT_WINDOW_3_BASE_ADDR                      =
0x1b0=0A=
+#define MV64340_CPU_PROTECT_WINDOW_3_SIZE                           =
0x1b8=0A=
+=0A=
+=0A=
+/****************************************/=0A=
+/*          CPU Error Report            */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_CPU_ERROR_ADDR_LOW                                  =
0x070=0A=
+#define MV64340_CPU_ERROR_ADDR_HIGH                                 =
0x078=0A=
+#define MV64340_CPU_ERROR_DATA_LOW                                  =
0x128=0A=
+#define MV64340_CPU_ERROR_DATA_HIGH                                 =
0x130=0A=
+#define MV64340_CPU_ERROR_PARITY                                    =
0x138=0A=
+#define MV64340_CPU_ERROR_CAUSE                                     =
0x140=0A=
+#define MV64340_CPU_ERROR_MASK                                      =
0x148=0A=
+=0A=
+/****************************************/=0A=
+/*      CPU Interface Debug Registers 	*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_PUNIT_SLAVE_DEBUG_LOW                               =
0x360=0A=
+#define MV64340_PUNIT_SLAVE_DEBUG_HIGH                              =
0x368=0A=
+#define MV64340_PUNIT_MASTER_DEBUG_LOW                              =
0x370=0A=
+#define MV64340_PUNIT_MASTER_DEBUG_HIGH                             =
0x378=0A=
+#define MV64340_PUNIT_MMASK                                         =
0x3e4=0A=
+=0A=
+/****************************************/=0A=
+/*  Integrated SRAM Registers           */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_SRAM_CONFIG                                         =
0x380=0A=
+#define MV64340_SRAM_TEST_MODE                                      =
0X3F4=0A=
+#define MV64340_SRAM_ERROR_CAUSE                                    =
0x388=0A=
+#define MV64340_SRAM_ERROR_ADDR                                     =
0x390=0A=
+#define MV64340_SRAM_ERROR_ADDR_HIGH                                =
0X3F8=0A=
+#define MV64340_SRAM_ERROR_DATA_LOW                                 =
0x398=0A=
+#define MV64340_SRAM_ERROR_DATA_HIGH                                =
0x3a0=0A=
+#define MV64340_SRAM_ERROR_DATA_PARITY                              =
0x3a8=0A=
+=0A=
+/****************************************/=0A=
+/* SDRAM Configuration                  */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_SDRAM_CONFIG                                        =
0x1400=0A=
+#define MV64340_D_UNIT_CONTROL_LOW                                  =
0x1404=0A=
+#define MV64340_D_UNIT_CONTROL_HIGH                                 =
0x1424=0A=
+#define MV64340_SDRAM_TIMING_CONTROL_LOW                            =
0x1408=0A=
+#define MV64340_SDRAM_TIMING_CONTROL_HIGH                           =
0x140c=0A=
+#define MV64340_SDRAM_ADDR_CONTROL                                  =
0x1410=0A=
+#define MV64340_SDRAM_OPEN_PAGES_CONTROL                            =
0x1414=0A=
+#define MV64340_SDRAM_OPERATION                                     =
0x1418=0A=
+#define MV64340_SDRAM_MODE                                          =
0x141c=0A=
+#define MV64340_EXTENDED_DRAM_MODE                                  =
0x1420=0A=
+#define MV64340_SDRAM_CROSS_BAR_CONTROL_LOW                         =
0x1430=0A=
+#define MV64340_SDRAM_CROSS_BAR_CONTROL_HIGH                        =
0x1434=0A=
+#define MV64340_SDRAM_CROSS_BAR_TIMEOUT                             =
0x1438=0A=
+#define MV64340_SDRAM_ADDR_CTRL_PADS_CALIBRATION                    =
0x14c0=0A=
+#define MV64340_SDRAM_DATA_PADS_CALIBRATION                         =
0x14c4=0A=
+=0A=
+/****************************************/=0A=
+/* SDRAM Error Report                   */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_SDRAM_ERROR_DATA_LOW                                =
0x1444=0A=
+#define MV64340_SDRAM_ERROR_DATA_HIGH                               =
0x1440=0A=
+#define MV64340_SDRAM_ERROR_ADDR                                    =
0x1450=0A=
+#define MV64340_SDRAM_RECEIVED_ECC                                  =
0x1448=0A=
+#define MV64340_SDRAM_CALCULATED_ECC                                =
0x144c=0A=
+#define MV64340_SDRAM_ECC_CONTROL                                   =
0x1454=0A=
+#define MV64340_SDRAM_ECC_ERROR_COUNTER                             =
0x1458=0A=
+=0A=
+/******************************************/=0A=
+/*  Controlled Delay Line (CDL) Registers */=0A=
+/******************************************/=0A=
+=0A=
+#define MV64340_DFCDL_CONFIG0                                       =
0x1480=0A=
+#define MV64340_DFCDL_CONFIG1                                       =
0x1484=0A=
+#define MV64340_DLL_WRITE                                           =
0x1488=0A=
+#define MV64340_DLL_READ                                            =
0x148c=0A=
+#define MV64340_SRAM_ADDR                                           =
0x1490=0A=
+#define MV64340_SRAM_DATA0                                          =
0x1494=0A=
+#define MV64340_SRAM_DATA1                                          =
0x1498=0A=
+#define MV64340_SRAM_DATA2                                          =
0x149c=0A=
+#define MV64340_DFCL_PROBE                                          =
0x14a0=0A=
+=0A=
+/******************************************/=0A=
+/*   Debug Registers                      */=0A=
+/******************************************/=0A=
+=0A=
+#define MV64340_DUNIT_DEBUG_LOW                                     =
0x1460=0A=
+#define MV64340_DUNIT_DEBUG_HIGH                                    =
0x1464=0A=
+#define MV64340_DUNIT_MMASK                                         =
0X1b40=0A=
+=0A=
+/****************************************/=0A=
+/* Device Parameters			*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_DEVICE_BANK0_PARAMETERS				    0x45c=0A=
+#define MV64340_DEVICE_BANK1_PARAMETERS				    0x460=0A=
+#define MV64340_DEVICE_BANK2_PARAMETERS				    0x464=0A=
+#define MV64340_DEVICE_BANK3_PARAMETERS				    0x468=0A=
+#define MV64340_DEVICE_BOOT_BANK_PARAMETERS			    0x46c=0A=
+#define MV64340_DEVICE_INTERFACE_CONTROL                            =
0x4c0=0A=
+#define MV64340_DEVICE_INTERFACE_CROSS_BAR_CONTROL_LOW              =
0x4c8=0A=
+#define MV64340_DEVICE_INTERFACE_CROSS_BAR_CONTROL_HIGH             =
0x4cc=0A=
+#define MV64340_DEVICE_INTERFACE_CROSS_BAR_TIMEOUT                  =
0x4c4=0A=
+=0A=
+/****************************************/=0A=
+/* Device interrupt registers		*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_DEVICE_INTERRUPT_CAUSE				    0x4d0=0A=
+#define MV64340_DEVICE_INTERRUPT_MASK				    0x4d4=0A=
+#define MV64340_DEVICE_ERROR_ADDR				    0x4d8=0A=
+#define MV64340_DEVICE_ERROR_DATA   				    0x4dc=0A=
+#define MV64340_DEVICE_ERROR_PARITY     			    0x4e0=0A=
+=0A=
+/****************************************/=0A=
+/* Device debug registers   		*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_DEVICE_DEBUG_LOW     				    0x4e4=0A=
+#define MV64340_DEVICE_DEBUG_HIGH     				    0x4e8=0A=
+#define MV64340_RUNIT_MMASK                                         =
0x4f0=0A=
+=0A=
+/****************************************/=0A=
+/* PCI Slave Address Decoding registers */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_PCI_0_CS_0_BANK_SIZE                                =
0xc08=0A=
+#define MV64340_PCI_1_CS_0_BANK_SIZE                                =
0xc88=0A=
+#define MV64340_PCI_0_CS_1_BANK_SIZE                                =
0xd08=0A=
+#define MV64340_PCI_1_CS_1_BANK_SIZE                                =
0xd88=0A=
+#define MV64340_PCI_0_CS_2_BANK_SIZE                                =
0xc0c=0A=
+#define MV64340_PCI_1_CS_2_BANK_SIZE                                =
0xc8c=0A=
+#define MV64340_PCI_0_CS_3_BANK_SIZE                                =
0xd0c=0A=
+#define MV64340_PCI_1_CS_3_BANK_SIZE                                =
0xd8c=0A=
+#define MV64340_PCI_0_DEVCS_0_BANK_SIZE                             =
0xc10=0A=
+#define MV64340_PCI_1_DEVCS_0_BANK_SIZE                             =
0xc90=0A=
+#define MV64340_PCI_0_DEVCS_1_BANK_SIZE                             =
0xd10=0A=
+#define MV64340_PCI_1_DEVCS_1_BANK_SIZE                             =
0xd90=0A=
+#define MV64340_PCI_0_DEVCS_2_BANK_SIZE                             =
0xd18=0A=
+#define MV64340_PCI_1_DEVCS_2_BANK_SIZE                             =
0xd98=0A=
+#define MV64340_PCI_0_DEVCS_3_BANK_SIZE                             =
0xc14=0A=
+#define MV64340_PCI_1_DEVCS_3_BANK_SIZE                             =
0xc94=0A=
+#define MV64340_PCI_0_DEVCS_BOOT_BANK_SIZE                          =
0xd14=0A=
+#define MV64340_PCI_1_DEVCS_BOOT_BANK_SIZE                          =
0xd94=0A=
+#define MV64340_PCI_0_P2P_MEM0_BAR_SIZE                             =
0xd1c=0A=
+#define MV64340_PCI_1_P2P_MEM0_BAR_SIZE                             =
0xd9c=0A=
+#define MV64340_PCI_0_P2P_MEM1_BAR_SIZE                             =
0xd20=0A=
+#define MV64340_PCI_1_P2P_MEM1_BAR_SIZE                             =
0xda0=0A=
+#define MV64340_PCI_0_P2P_I_O_BAR_SIZE                              =
0xd24=0A=
+#define MV64340_PCI_1_P2P_I_O_BAR_SIZE                              =
0xda4=0A=
+#define MV64340_PCI_0_CPU_BAR_SIZE                                  =
0xd28=0A=
+#define MV64340_PCI_1_CPU_BAR_SIZE                                  =
0xda8=0A=
+#define MV64340_PCI_0_INTERNAL_SRAM_BAR_SIZE                        =
0xe00=0A=
+#define MV64340_PCI_1_INTERNAL_SRAM_BAR_SIZE                        =
0xe80=0A=
+#define MV64340_PCI_0_EXPANSION_ROM_BAR_SIZE                        =
0xd2c=0A=
+#define MV64340_PCI_1_EXPANSION_ROM_BAR_SIZE                        =
0xd9c=0A=
+#define MV64340_PCI_0_BASE_ADDR_REG_ENABLE                          =
0xc3c=0A=
+#define MV64340_PCI_1_BASE_ADDR_REG_ENABLE                          =
0xcbc=0A=
+#define MV64340_PCI_0_CS_0_BASE_ADDR_REMAP			    0xc48=0A=
+#define MV64340_PCI_1_CS_0_BASE_ADDR_REMAP			    0xcc8=0A=
+#define MV64340_PCI_0_CS_1_BASE_ADDR_REMAP			    0xd48=0A=
+#define MV64340_PCI_1_CS_1_BASE_ADDR_REMAP			    0xdc8=0A=
+#define MV64340_PCI_0_CS_2_BASE_ADDR_REMAP			    0xc4c=0A=
+#define MV64340_PCI_1_CS_2_BASE_ADDR_REMAP			    0xccc=0A=
+#define MV64340_PCI_0_CS_3_BASE_ADDR_REMAP			    0xd4c=0A=
+#define MV64340_PCI_1_CS_3_BASE_ADDR_REMAP			    0xdcc=0A=
+#define MV64340_PCI_0_CS_0_BASE_HIGH_ADDR_REMAP			    0xF04=0A=
+#define MV64340_PCI_1_CS_0_BASE_HIGH_ADDR_REMAP			    0xF84=0A=
+#define MV64340_PCI_0_CS_1_BASE_HIGH_ADDR_REMAP			    0xF08=0A=
+#define MV64340_PCI_1_CS_1_BASE_HIGH_ADDR_REMAP			    0xF88=0A=
+#define MV64340_PCI_0_CS_2_BASE_HIGH_ADDR_REMAP			    0xF0C=0A=
+#define MV64340_PCI_1_CS_2_BASE_HIGH_ADDR_REMAP			    0xF8C=0A=
+#define MV64340_PCI_0_CS_3_BASE_HIGH_ADDR_REMAP			    0xF10=0A=
+#define MV64340_PCI_1_CS_3_BASE_HIGH_ADDR_REMAP			    0xF90=0A=
+#define MV64340_PCI_0_DEVCS_0_BASE_ADDR_REMAP			    0xc50=0A=
+#define MV64340_PCI_1_DEVCS_0_BASE_ADDR_REMAP			    0xcd0=0A=
+#define MV64340_PCI_0_DEVCS_1_BASE_ADDR_REMAP			    0xd50=0A=
+#define MV64340_PCI_1_DEVCS_1_BASE_ADDR_REMAP			    0xdd0=0A=
+#define MV64340_PCI_0_DEVCS_2_BASE_ADDR_REMAP			    0xd58=0A=
+#define MV64340_PCI_1_DEVCS_2_BASE_ADDR_REMAP			    0xdd8=0A=
+#define MV64340_PCI_0_DEVCS_3_BASE_ADDR_REMAP           	    0xc54=0A=
+#define MV64340_PCI_1_DEVCS_3_BASE_ADDR_REMAP           	    0xcd4=0A=
+#define MV64340_PCI_0_DEVCS_BOOTCS_BASE_ADDR_REMAP      	    0xd54=0A=
+#define MV64340_PCI_1_DEVCS_BOOTCS_BASE_ADDR_REMAP      	    0xdd4=0A=
+#define MV64340_PCI_0_P2P_MEM0_BASE_ADDR_REMAP_LOW                  =
0xd5c=0A=
+#define MV64340_PCI_1_P2P_MEM0_BASE_ADDR_REMAP_LOW                  =
0xddc=0A=
+#define MV64340_PCI_0_P2P_MEM0_BASE_ADDR_REMAP_HIGH                 =
0xd60=0A=
+#define MV64340_PCI_1_P2P_MEM0_BASE_ADDR_REMAP_HIGH                 =
0xde0=0A=
+#define MV64340_PCI_0_P2P_MEM1_BASE_ADDR_REMAP_LOW                  =
0xd64=0A=
+#define MV64340_PCI_1_P2P_MEM1_BASE_ADDR_REMAP_LOW                  =
0xde4=0A=
+#define MV64340_PCI_0_P2P_MEM1_BASE_ADDR_REMAP_HIGH                 =
0xd68=0A=
+#define MV64340_PCI_1_P2P_MEM1_BASE_ADDR_REMAP_HIGH                 =
0xde8=0A=
+#define MV64340_PCI_0_P2P_I_O_BASE_ADDR_REMAP                       =
0xd6c=0A=
+#define MV64340_PCI_1_P2P_I_O_BASE_ADDR_REMAP                       =
0xdec =0A=
+#define MV64340_PCI_0_CPU_BASE_ADDR_REMAP_LOW                       =
0xd70=0A=
+#define MV64340_PCI_1_CPU_BASE_ADDR_REMAP_LOW                       =
0xdf0=0A=
+#define MV64340_PCI_0_CPU_BASE_ADDR_REMAP_HIGH                      =
0xd74=0A=
+#define MV64340_PCI_1_CPU_BASE_ADDR_REMAP_HIGH                      =
0xdf4=0A=
+#define MV64340_PCI_0_INTEGRATED_SRAM_BASE_ADDR_REMAP               =
0xf00=0A=
+#define MV64340_PCI_1_INTEGRATED_SRAM_BASE_ADDR_REMAP               =
0xf80=0A=
+#define MV64340_PCI_0_EXPANSION_ROM_BASE_ADDR_REMAP                 =
0xf38=0A=
+#define MV64340_PCI_1_EXPANSION_ROM_BASE_ADDR_REMAP                 =
0xfb8=0A=
+#define MV64340_PCI_0_ADDR_DECODE_CONTROL                           =
0xd3c=0A=
+#define MV64340_PCI_1_ADDR_DECODE_CONTROL                           =
0xdbc=0A=
+#define MV64340_PCI_0_HEADERS_RETARGET_CONTROL                      =
0xF40=0A=
+#define MV64340_PCI_1_HEADERS_RETARGET_CONTROL                      =
0xFc0=0A=
+#define MV64340_PCI_0_HEADERS_RETARGET_BASE                         =
0xF44=0A=
+#define MV64340_PCI_1_HEADERS_RETARGET_BASE                         =
0xFc4=0A=
+#define MV64340_PCI_0_HEADERS_RETARGET_HIGH                         =
0xF48=0A=
+#define MV64340_PCI_1_HEADERS_RETARGET_HIGH                         =
0xFc8=0A=
+=0A=
+/***********************************/=0A=
+/*   PCI Control Register Map      */=0A=
+/***********************************/=0A=
+=0A=
+#define MV64340_PCI_0_DLL_STATUS_AND_COMMAND                        =
0x1d20=0A=
+#define MV64340_PCI_1_DLL_STATUS_AND_COMMAND                        =
0x1da0=0A=
+#define MV64340_PCI_0_MPP_PADS_DRIVE_CONTROL                        =
0x1d1C=0A=
+#define MV64340_PCI_1_MPP_PADS_DRIVE_CONTROL                        =
0x1d9C=0A=
+#define MV64340_PCI_0_COMMAND			         	    0xc00=0A=
+#define MV64340_PCI_1_COMMAND					    0xc80=0A=
+#define MV64340_PCI_0_MODE                                          =
0xd00=0A=
+#define MV64340_PCI_1_MODE                                          =
0xd80=0A=
+#define MV64340_PCI_0_RETRY	        	 		    0xc04=0A=
+#define MV64340_PCI_1_RETRY				            0xc84=0A=
+#define MV64340_PCI_0_READ_BUFFER_DISCARD_TIMER                     =
0xd04=0A=
+#define MV64340_PCI_1_READ_BUFFER_DISCARD_TIMER                     =
0xd84=0A=
+#define MV64340_PCI_0_MSI_TRIGGER_TIMER                             =
0xc38=0A=
+#define MV64340_PCI_1_MSI_TRIGGER_TIMER                             =
0xcb8=0A=
+#define MV64340_PCI_0_ARBITER_CONTROL                               =
0x1d00=0A=
+#define MV64340_PCI_1_ARBITER_CONTROL                               =
0x1d80=0A=
+#define MV64340_PCI_0_CROSS_BAR_CONTROL_LOW                         =
0x1d08=0A=
+#define MV64340_PCI_1_CROSS_BAR_CONTROL_LOW                         =
0x1d88=0A=
+#define MV64340_PCI_0_CROSS_BAR_CONTROL_HIGH                        =
0x1d0c=0A=
+#define MV64340_PCI_1_CROSS_BAR_CONTROL_HIGH                        =
0x1d8c=0A=
+#define MV64340_PCI_0_CROSS_BAR_TIMEOUT                             =
0x1d04=0A=
+#define MV64340_PCI_1_CROSS_BAR_TIMEOUT                             =
0x1d84=0A=
+#define MV64340_PCI_0_SYNC_BARRIER_TRIGGER_REG                      =
0x1D18=0A=
+#define MV64340_PCI_1_SYNC_BARRIER_TRIGGER_REG                      =
0x1D98=0A=
+#define MV64340_PCI_0_SYNC_BARRIER_VIRTUAL_REG                      =
0x1d10=0A=
+#define MV64340_PCI_1_SYNC_BARRIER_VIRTUAL_REG                      =
0x1d90=0A=
+#define MV64340_PCI_0_P2P_CONFIG                                    =
0x1d14=0A=
+#define MV64340_PCI_1_P2P_CONFIG                                    =
0x1d94=0A=
+=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_0_LOW                     =
0x1e00=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_0_HIGH                    =
0x1e04=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_SIZE_0                         =
0x1e08=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_1_LOW                     =
0x1e10=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_1_HIGH                    =
0x1e14=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_SIZE_1                         =
0x1e18=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_2_LOW                     =
0x1e20=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_2_HIGH                    =
0x1e24=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_SIZE_2                         =
0x1e28=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_3_LOW                     =
0x1e30=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_3_HIGH                    =
0x1e34=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_SIZE_3                         =
0x1e38=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_4_LOW                     =
0x1e40=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_4_HIGH                    =
0x1e44=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_SIZE_4                         =
0x1e48=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_5_LOW                     =
0x1e50=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_BASE_5_HIGH                    =
0x1e54=0A=
+#define MV64340_PCI_0_ACCESS_CONTROL_SIZE_5                         =
0x1e58=0A=
+=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_0_LOW                     =
0x1e80=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_0_HIGH                    =
0x1e84=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_SIZE_0                         =
0x1e88=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_1_LOW                     =
0x1e90=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_1_HIGH                    =
0x1e94=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_SIZE_1                         =
0x1e98=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_2_LOW                     =
0x1ea0=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_2_HIGH                    =
0x1ea4=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_SIZE_2                         =
0x1ea8=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_3_LOW                     =
0x1eb0=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_3_HIGH                    =
0x1eb4=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_SIZE_3                         =
0x1eb8=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_4_LOW                     =
0x1ec0=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_4_HIGH                    =
0x1ec4=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_SIZE_4                         =
0x1ec8=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_5_LOW                     =
0x1ed0=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_BASE_5_HIGH                    =
0x1ed4=0A=
+#define MV64340_PCI_1_ACCESS_CONTROL_SIZE_5                         =
0x1ed8=0A=
+=0A=
+/****************************************/=0A=
+/*   PCI Configuration Access Registers */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_PCI_0_CONFIG_ADDR 				    0xcf8=0A=
+#define MV64340_PCI_0_CONFIG_DATA_VIRTUAL_REG                       =
0xcfc=0A=
+#define MV64340_PCI_1_CONFIG_ADDR 				    0xc78=0A=
+#define MV64340_PCI_1_CONFIG_DATA_VIRTUAL_REG                       =
0xc7c=0A=
+#define MV64340_PCI_0_INTERRUPT_ACKNOWLEDGE_VIRTUAL_REG	            =
0xc34=0A=
+#define MV64340_PCI_1_INTERRUPT_ACKNOWLEDGE_VIRTUAL_REG	            =
0xcb4=0A=
+=0A=
+/****************************************/=0A=
+/*   PCI Error Report Registers         */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_PCI_0_SERR_MASK					    0xc28=0A=
+#define MV64340_PCI_1_SERR_MASK					    0xca8=0A=
+#define MV64340_PCI_0_ERROR_ADDR_LOW                                =
0x1d40=0A=
+#define MV64340_PCI_1_ERROR_ADDR_LOW                                =
0x1dc0=0A=
+#define MV64340_PCI_0_ERROR_ADDR_HIGH                               =
0x1d44=0A=
+#define MV64340_PCI_1_ERROR_ADDR_HIGH                               =
0x1dc4=0A=
+#define MV64340_PCI_0_ERROR_ATTRIBUTE                               =
0x1d48=0A=
+#define MV64340_PCI_1_ERROR_ATTRIBUTE                               =
0x1dc8=0A=
+#define MV64340_PCI_0_ERROR_COMMAND                                 =
0x1d50=0A=
+#define MV64340_PCI_1_ERROR_COMMAND                                 =
0x1dd0=0A=
+#define MV64340_PCI_0_ERROR_CAUSE                                   =
0x1d58=0A=
+#define MV64340_PCI_1_ERROR_CAUSE                                   =
0x1dd8=0A=
+#define MV64340_PCI_0_ERROR_MASK                                    =
0x1d5c=0A=
+#define MV64340_PCI_1_ERROR_MASK                                    =
0x1ddc=0A=
+=0A=
+/****************************************/=0A=
+/*   PCI Debug Registers                */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_PCI_0_MMASK                                         =
0X1D24=0A=
+#define MV64340_PCI_1_MMASK                                         =
0X1DA4=0A=
+=0A=
+/*********************************************/=0A=
+/* PCI Configuration, Function 0, Registers  */=0A=
+/*********************************************/=0A=
+=0A=
+#define MV64340_PCI_DEVICE_AND_VENDOR_ID 			    0x000=0A=
+#define MV64340_PCI_STATUS_AND_COMMAND				    0x004=0A=
+#define MV64340_PCI_CLASS_CODE_AND_REVISION_ID			    0x008=0A=
+#define MV64340_PCI_BIST_HEADER_TYPE_LATENCY_TIMER_CACHE_LINE 	    0x00C=0A=
+=0A=
+#define MV64340_PCI_SCS_0_BASE_ADDR_LOW   	      		    0x010=0A=
+#define MV64340_PCI_SCS_0_BASE_ADDR_HIGH   		            0x014=0A=
+#define MV64340_PCI_SCS_1_BASE_ADDR_LOW  	     	            0x018=0A=
+#define MV64340_PCI_SCS_1_BASE_ADDR_HIGH 		            0x01C=0A=
+#define MV64340_PCI_INTERNAL_REG_MEM_MAPPED_BASE_ADDR_LOW      	    =
0x020=0A=
+#define MV64340_PCI_INTERNAL_REG_MEM_MAPPED_BASE_ADDR_HIGH     	    =
0x024=0A=
+#define MV64340_PCI_SUBSYSTEM_ID_AND_SUBSYSTEM_VENDOR_ID	    0x02c=0A=
+#define MV64340_PCI_EXPANSION_ROM_BASE_ADDR_REG	                    =
0x030=0A=
+#define MV64340_PCI_CAPABILTY_LIST_POINTER                          =
0x034=0A=
+#define MV64340_PCI_INTERRUPT_PIN_AND_LINE 			    0x03C=0A=
+       /* capability list */=0A=
+#define MV64340_PCI_POWER_MANAGEMENT_CAPABILITY                     =
0x040=0A=
+#define MV64340_PCI_POWER_MANAGEMENT_STATUS_AND_CONTROL             =
0x044=0A=
+#define MV64340_PCI_VPD_ADDR                                        =
0x048=0A=
+#define MV64340_PCI_VPD_DATA                                        =
0x04c=0A=
+#define MV64340_PCI_MSI_MESSAGE_CONTROL                             =
0x050=0A=
+#define MV64340_PCI_MSI_MESSAGE_ADDR                                =
0x054=0A=
+#define MV64340_PCI_MSI_MESSAGE_UPPER_ADDR                          =
0x058=0A=
+#define MV64340_PCI_MSI_MESSAGE_DATA                                =
0x05c=0A=
+#define MV64340_PCI_X_COMMAND                                       =
0x060=0A=
+#define MV64340_PCI_X_STATUS                                        =
0x064=0A=
+#define MV64340_PCI_COMPACT_PCI_HOT_SWAP                            =
0x068=0A=
+=0A=
+/***********************************************/=0A=
+/*   PCI Configuration, Function 1, Registers  */=0A=
+/***********************************************/=0A=
+=0A=
+#define MV64340_PCI_SCS_2_BASE_ADDR_LOW   			    0x110=0A=
+#define MV64340_PCI_SCS_2_BASE_ADDR_HIGH			    0x114=0A=
+#define MV64340_PCI_SCS_3_BASE_ADDR_LOW 			    0x118=0A=
+#define MV64340_PCI_SCS_3_BASE_ADDR_HIGH			    0x11c=0A=
+#define MV64340_PCI_INTERNAL_SRAM_BASE_ADDR_LOW          	    0x120=0A=
+#define MV64340_PCI_INTERNAL_SRAM_BASE_ADDR_HIGH         	    0x124=0A=
+=0A=
+/***********************************************/=0A=
+/*  PCI Configuration, Function 2, Registers   */=0A=
+/***********************************************/=0A=
+=0A=
+#define MV64340_PCI_DEVCS_0_BASE_ADDR_LOW	    		    0x210=0A=
+#define MV64340_PCI_DEVCS_0_BASE_ADDR_HIGH 			    0x214=0A=
+#define MV64340_PCI_DEVCS_1_BASE_ADDR_LOW 			    0x218=0A=
+#define MV64340_PCI_DEVCS_1_BASE_ADDR_HIGH      		    0x21c=0A=
+#define MV64340_PCI_DEVCS_2_BASE_ADDR_LOW 			    0x220=0A=
+#define MV64340_PCI_DEVCS_2_BASE_ADDR_HIGH      		    0x224=0A=
+=0A=
+/***********************************************/=0A=
+/*  PCI Configuration, Function 3, Registers   */=0A=
+/***********************************************/=0A=
+=0A=
+#define MV64340_PCI_DEVCS_3_BASE_ADDR_LOW	    		    0x310=0A=
+#define MV64340_PCI_DEVCS_3_BASE_ADDR_HIGH 			    0x314=0A=
+#define MV64340_PCI_BOOT_CS_BASE_ADDR_LOW			    0x318=0A=
+#define MV64340_PCI_BOOT_CS_BASE_ADDR_HIGH      		    0x31c=0A=
+#define MV64340_PCI_CPU_BASE_ADDR_LOW 				    0x220=0A=
+#define MV64340_PCI_CPU_BASE_ADDR_HIGH      			    0x224=0A=
+=0A=
+/***********************************************/=0A=
+/*  PCI Configuration, Function 4, Registers   */=0A=
+/***********************************************/=0A=
+=0A=
+#define MV64340_PCI_P2P_MEM0_BASE_ADDR_LOW  			    0x410=0A=
+#define MV64340_PCI_P2P_MEM0_BASE_ADDR_HIGH 			    0x414=0A=
+#define MV64340_PCI_P2P_MEM1_BASE_ADDR_LOW   			    0x418=0A=
+#define MV64340_PCI_P2P_MEM1_BASE_ADDR_HIGH 			    0x41c=0A=
+#define MV64340_PCI_P2P_I_O_BASE_ADDR                 	            0x420=0A=
+#define MV64340_PCI_INTERNAL_REGS_I_O_MAPPED_BASE_ADDR              =
0x424=0A=
+=0A=
+/****************************************/=0A=
+/* Messaging Unit Registers (I20)   	*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_I2O_INBOUND_MESSAGE_REG0_PCI_0_SIDE		    0x010=0A=
+#define MV64340_I2O_INBOUND_MESSAGE_REG1_PCI_0_SIDE  		    0x014=0A=
+#define MV64340_I2O_OUTBOUND_MESSAGE_REG0_PCI_0_SIDE 		    0x018=0A=
+#define MV64340_I2O_OUTBOUND_MESSAGE_REG1_PCI_0_SIDE  		    0x01C=0A=
+#define MV64340_I2O_INBOUND_DOORBELL_REG_PCI_0_SIDE  		    0x020=0A=
+#define MV64340_I2O_INBOUND_INTERRUPT_CAUSE_REG_PCI_0_SIDE          =
0x024=0A=
+#define MV64340_I2O_INBOUND_INTERRUPT_MASK_REG_PCI_0_SIDE	    0x028=0A=
+#define MV64340_I2O_OUTBOUND_DOORBELL_REG_PCI_0_SIDE 		    0x02C=0A=
+#define MV64340_I2O_OUTBOUND_INTERRUPT_CAUSE_REG_PCI_0_SIDE         =
0x030=0A=
+#define MV64340_I2O_OUTBOUND_INTERRUPT_MASK_REG_PCI_0_SIDE          =
0x034=0A=
+#define MV64340_I2O_INBOUND_QUEUE_PORT_VIRTUAL_REG_PCI_0_SIDE       =
0x040=0A=
+#define MV64340_I2O_OUTBOUND_QUEUE_PORT_VIRTUAL_REG_PCI_0_SIDE      =
0x044=0A=
+#define MV64340_I2O_QUEUE_CONTROL_REG_PCI_0_SIDE 		    0x050=0A=
+#define MV64340_I2O_QUEUE_BASE_ADDR_REG_PCI_0_SIDE 		    0x054=0A=
+#define MV64340_I2O_INBOUND_FREE_HEAD_POINTER_REG_PCI_0_SIDE        =
0x060=0A=
+#define MV64340_I2O_INBOUND_FREE_TAIL_POINTER_REG_PCI_0_SIDE        =
0x064=0A=
+#define MV64340_I2O_INBOUND_POST_HEAD_POINTER_REG_PCI_0_SIDE        =
0x068=0A=
+#define MV64340_I2O_INBOUND_POST_TAIL_POINTER_REG_PCI_0_SIDE        =
0x06C=0A=
+#define MV64340_I2O_OUTBOUND_FREE_HEAD_POINTER_REG_PCI_0_SIDE       =
0x070=0A=
+#define MV64340_I2O_OUTBOUND_FREE_TAIL_POINTER_REG_PCI_0_SIDE       =
0x074=0A=
+#define MV64340_I2O_OUTBOUND_POST_HEAD_POINTER_REG_PCI_0_SIDE       =
0x0F8=0A=
+#define MV64340_I2O_OUTBOUND_POST_TAIL_POINTER_REG_PCI_0_SIDE       =
0x0FC=0A=
+=0A=
+#define MV64340_I2O_INBOUND_MESSAGE_REG0_PCI_1_SIDE		    0x090=0A=
+#define MV64340_I2O_INBOUND_MESSAGE_REG1_PCI_1_SIDE  		    0x094=0A=
+#define MV64340_I2O_OUTBOUND_MESSAGE_REG0_PCI_1_SIDE 		    0x098=0A=
+#define MV64340_I2O_OUTBOUND_MESSAGE_REG1_PCI_1_SIDE  		    0x09C=0A=
+#define MV64340_I2O_INBOUND_DOORBELL_REG_PCI_1_SIDE  		    0x0A0=0A=
+#define MV64340_I2O_INBOUND_INTERRUPT_CAUSE_REG_PCI_1_SIDE          =
0x0A4=0A=
+#define MV64340_I2O_INBOUND_INTERRUPT_MASK_REG_PCI_1_SIDE	    0x0A8=0A=
+#define MV64340_I2O_OUTBOUND_DOORBELL_REG_PCI_1_SIDE 		    0x0AC=0A=
+#define MV64340_I2O_OUTBOUND_INTERRUPT_CAUSE_REG_PCI_1_SIDE         =
0x0B0=0A=
+#define MV64340_I2O_OUTBOUND_INTERRUPT_MASK_REG_PCI_1_SIDE          =
0x0B4=0A=
+#define MV64340_I2O_INBOUND_QUEUE_PORT_VIRTUAL_REG_PCI_1_SIDE       =
0x0C0=0A=
+#define MV64340_I2O_OUTBOUND_QUEUE_PORT_VIRTUAL_REG_PCI_1_SIDE      =
0x0C4=0A=
+#define MV64340_I2O_QUEUE_CONTROL_REG_PCI_1_SIDE 		    0x0D0=0A=
+#define MV64340_I2O_QUEUE_BASE_ADDR_REG_PCI_1_SIDE 		    0x0D4=0A=
+#define MV64340_I2O_INBOUND_FREE_HEAD_POINTER_REG_PCI_1_SIDE        =
0x0E0=0A=
+#define MV64340_I2O_INBOUND_FREE_TAIL_POINTER_REG_PCI_1_SIDE        =
0x0E4=0A=
+#define MV64340_I2O_INBOUND_POST_HEAD_POINTER_REG_PCI_1_SIDE        =
0x0E8=0A=
+#define MV64340_I2O_INBOUND_POST_TAIL_POINTER_REG_PCI_1_SIDE        =
0x0EC=0A=
+#define MV64340_I2O_OUTBOUND_FREE_HEAD_POINTER_REG_PCI_1_SIDE       =
0x0F0=0A=
+#define MV64340_I2O_OUTBOUND_FREE_TAIL_POINTER_REG_PCI_1_SIDE       =
0x0F4=0A=
+#define MV64340_I2O_OUTBOUND_POST_HEAD_POINTER_REG_PCI_1_SIDE       =
0x078=0A=
+#define MV64340_I2O_OUTBOUND_POST_TAIL_POINTER_REG_PCI_1_SIDE       =
0x07C=0A=
+=0A=
+#define MV64340_I2O_INBOUND_MESSAGE_REG0_CPU0_SIDE		    0x1C10=0A=
+#define MV64340_I2O_INBOUND_MESSAGE_REG1_CPU0_SIDE  		    0x1C14=0A=
+#define MV64340_I2O_OUTBOUND_MESSAGE_REG0_CPU0_SIDE 		    0x1C18=0A=
+#define MV64340_I2O_OUTBOUND_MESSAGE_REG1_CPU0_SIDE  		    0x1C1C=0A=
+#define MV64340_I2O_INBOUND_DOORBELL_REG_CPU0_SIDE  		    0x1C20=0A=
+#define MV64340_I2O_INBOUND_INTERRUPT_CAUSE_REG_CPU0_SIDE  	    0x1C24=0A=
+#define MV64340_I2O_INBOUND_INTERRUPT_MASK_REG_CPU0_SIDE	    0x1C28=0A=
+#define MV64340_I2O_OUTBOUND_DOORBELL_REG_CPU0_SIDE 		    0x1C2C=0A=
+#define MV64340_I2O_OUTBOUND_INTERRUPT_CAUSE_REG_CPU0_SIDE          =
0x1C30=0A=
+#define MV64340_I2O_OUTBOUND_INTERRUPT_MASK_REG_CPU0_SIDE           =
0x1C34=0A=
+#define MV64340_I2O_INBOUND_QUEUE_PORT_VIRTUAL_REG_CPU0_SIDE        =
0x1C40=0A=
+#define MV64340_I2O_OUTBOUND_QUEUE_PORT_VIRTUAL_REG_CPU0_SIDE       =
0x1C44=0A=
+#define MV64340_I2O_QUEUE_CONTROL_REG_CPU0_SIDE 		    0x1C50=0A=
+#define MV64340_I2O_QUEUE_BASE_ADDR_REG_CPU0_SIDE 		    0x1C54=0A=
+#define MV64340_I2O_INBOUND_FREE_HEAD_POINTER_REG_CPU0_SIDE         =
0x1C60=0A=
+#define MV64340_I2O_INBOUND_FREE_TAIL_POINTER_REG_CPU0_SIDE         =
0x1C64=0A=
+#define MV64340_I2O_INBOUND_POST_HEAD_POINTER_REG_CPU0_SIDE         =
0x1C68=0A=
+#define MV64340_I2O_INBOUND_POST_TAIL_POINTER_REG_CPU0_SIDE         =
0x1C6C=0A=
+#define MV64340_I2O_OUTBOUND_FREE_HEAD_POINTER_REG_CPU0_SIDE        =
0x1C70=0A=
+#define MV64340_I2O_OUTBOUND_FREE_TAIL_POINTER_REG_CPU0_SIDE        =
0x1C74=0A=
+#define MV64340_I2O_OUTBOUND_POST_HEAD_POINTER_REG_CPU0_SIDE        =
0x1CF8=0A=
+#define MV64340_I2O_OUTBOUND_POST_TAIL_POINTER_REG_CPU0_SIDE        =
0x1CFC=0A=
+#define MV64340_I2O_INBOUND_MESSAGE_REG0_CPU1_SIDE		    0x1C90=0A=
+#define MV64340_I2O_INBOUND_MESSAGE_REG1_CPU1_SIDE  		    0x1C94=0A=
+#define MV64340_I2O_OUTBOUND_MESSAGE_REG0_CPU1_SIDE 		    0x1C98=0A=
+#define MV64340_I2O_OUTBOUND_MESSAGE_REG1_CPU1_SIDE  		    0x1C9C=0A=
+#define MV64340_I2O_INBOUND_DOORBELL_REG_CPU1_SIDE  		    0x1CA0=0A=
+#define MV64340_I2O_INBOUND_INTERRUPT_CAUSE_REG_CPU1_SIDE  	    0x1CA4=0A=
+#define MV64340_I2O_INBOUND_INTERRUPT_MASK_REG_CPU1_SIDE	    0x1CA8=0A=
+#define MV64340_I2O_OUTBOUND_DOORBELL_REG_CPU1_SIDE 		    0x1CAC=0A=
+#define MV64340_I2O_OUTBOUND_INTERRUPT_CAUSE_REG_CPU1_SIDE          =
0x1CB0=0A=
+#define MV64340_I2O_OUTBOUND_INTERRUPT_MASK_REG_CPU1_SIDE           =
0x1CB4=0A=
+#define MV64340_I2O_INBOUND_QUEUE_PORT_VIRTUAL_REG_CPU1_SIDE        =
0x1CC0=0A=
+#define MV64340_I2O_OUTBOUND_QUEUE_PORT_VIRTUAL_REG_CPU1_SIDE       =
0x1CC4=0A=
+#define MV64340_I2O_QUEUE_CONTROL_REG_CPU1_SIDE 		    0x1CD0=0A=
+#define MV64340_I2O_QUEUE_BASE_ADDR_REG_CPU1_SIDE 		    0x1CD4=0A=
+#define MV64340_I2O_INBOUND_FREE_HEAD_POINTER_REG_CPU1_SIDE         =
0x1CE0=0A=
+#define MV64340_I2O_INBOUND_FREE_TAIL_POINTER_REG_CPU1_SIDE         =
0x1CE4=0A=
+#define MV64340_I2O_INBOUND_POST_HEAD_POINTER_REG_CPU1_SIDE         =
0x1CE8=0A=
+#define MV64340_I2O_INBOUND_POST_TAIL_POINTER_REG_CPU1_SIDE         =
0x1CEC=0A=
+#define MV64340_I2O_OUTBOUND_FREE_HEAD_POINTER_REG_CPU1_SIDE        =
0x1CF0=0A=
+#define MV64340_I2O_OUTBOUND_FREE_TAIL_POINTER_REG_CPU1_SIDE        =
0x1CF4=0A=
+#define MV64340_I2O_OUTBOUND_POST_HEAD_POINTER_REG_CPU1_SIDE        =
0x1C78=0A=
+#define MV64340_I2O_OUTBOUND_POST_TAIL_POINTER_REG_CPU1_SIDE        =
0x1C7C=0A=
+=0A=
+/****************************************/=0A=
+/*        Ethernet Unit Registers  		*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_ETH_PHY_ADDR_REG                                    =
0x2000=0A=
+#define MV64340_ETH_SMI_REG                                         =
0x2004=0A=
+#define MV64340_ETH_UNIT_DEFAULT_ADDR_REG                           =
0x2008=0A=
+#define MV64340_ETH_UNIT_DEFAULTID_REG                              =
0x200c=0A=
+#define MV64340_ETH_UNIT_INTERRUPT_CAUSE_REG                        =
0x2080=0A=
+#define MV64340_ETH_UNIT_INTERRUPT_MASK_REG                         =
0x2084=0A=
+#define MV64340_ETH_UNIT_INTERNAL_USE_REG                           =
0x24fc=0A=
+#define MV64340_ETH_UNIT_ERROR_ADDR_REG                             =
0x2094=0A=
+#define MV64340_ETH_BAR_0                                           =
0x2200=0A=
+#define MV64340_ETH_BAR_1                                           =
0x2208=0A=
+#define MV64340_ETH_BAR_2                                           =
0x2210=0A=
+#define MV64340_ETH_BAR_3                                           =
0x2218=0A=
+#define MV64340_ETH_BAR_4                                           =
0x2220=0A=
+#define MV64340_ETH_BAR_5                                           =
0x2228=0A=
+#define MV64340_ETH_SIZE_REG_0                                      =
0x2204=0A=
+#define MV64340_ETH_SIZE_REG_1                                      =
0x220c=0A=
+#define MV64340_ETH_SIZE_REG_2                                      =
0x2214=0A=
+#define MV64340_ETH_SIZE_REG_3                                      =
0x221c=0A=
+#define MV64340_ETH_SIZE_REG_4                                      =
0x2224=0A=
+#define MV64340_ETH_SIZE_REG_5                                      =
0x222c=0A=
+#define MV64340_ETH_HEADERS_RETARGET_BASE_REG                       =
0x2230=0A=
+#define MV64340_ETH_HEADERS_RETARGET_CONTROL_REG                    =
0x2234=0A=
+#define MV64340_ETH_HIGH_ADDR_REMAP_REG_0                           =
0x2280=0A=
+#define MV64340_ETH_HIGH_ADDR_REMAP_REG_1                           =
0x2284=0A=
+#define MV64340_ETH_HIGH_ADDR_REMAP_REG_2                           =
0x2288=0A=
+#define MV64340_ETH_HIGH_ADDR_REMAP_REG_3                           =
0x228c=0A=
+#define MV64340_ETH_BASE_ADDR_ENABLE_REG                            =
0x2290=0A=
+#define MV64340_ETH_ACCESS_PROTECTION_REG(port)                    =
(0x2294 + (port<<2))=0A=
+#define MV64340_ETH_MIB_COUNTERS_BASE(port)                        =
(0x3000 + (port<<7))=0A=
+#define MV64340_ETH_PORT_CONFIG_REG(port)                          =
(0x2400 + (port<<10))=0A=
+#define MV64340_ETH_PORT_CONFIG_EXTEND_REG(port)                   =
(0x2404 + (port<<10))=0A=
+#define MV64340_ETH_MII_SERIAL_PARAMETRS_REG(port)                 =
(0x2408 + (port<<10))=0A=
+#define MV64340_ETH_GMII_SERIAL_PARAMETRS_REG(port)                =
(0x240c + (port<<10))=0A=
+#define MV64340_ETH_VLAN_ETHERTYPE_REG(port)                       =
(0x2410 + (port<<10))=0A=
+#define MV64340_ETH_MAC_ADDR_LOW(port)                             =
(0x2414 + (port<<10))=0A=
+#define MV64340_ETH_MAC_ADDR_HIGH(port)                            =
(0x2418 + (port<<10))=0A=
+#define MV64340_ETH_SDMA_CONFIG_REG(port)                          =
(0x241c + (port<<10))=0A=
+#define MV64340_ETH_DSCP_0(port)                                   =
(0x2420 + (port<<10))=0A=
+#define MV64340_ETH_DSCP_1(port)                                   =
(0x2424 + (port<<10))=0A=
+#define MV64340_ETH_DSCP_2(port)                                   =
(0x2428 + (port<<10))=0A=
+#define MV64340_ETH_DSCP_3(port)                                   =
(0x242c + (port<<10))=0A=
+#define MV64340_ETH_DSCP_4(port)                                   =
(0x2430 + (port<<10))=0A=
+#define MV64340_ETH_DSCP_5(port)                                   =
(0x2434 + (port<<10))=0A=
+#define MV64340_ETH_DSCP_6(port)                                   =
(0x2438 + (port<<10))=0A=
+#define MV64340_ETH_PORT_SERIAL_CONTROL_REG(port)                  =
(0x243c + (port<<10))=0A=
+#define MV64340_ETH_VLAN_PRIORITY_TAG_TO_PRIORITY(port)            =
(0x2440 + (port<<10))=0A=
+#define MV64340_ETH_PORT_STATUS_REG(port)                          =
(0x2444 + (port<<10))=0A=
+#define MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG(port)               =
(0x2448 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_FIXED_PRIORITY(port)                  =
(0x244c + (port<<10))=0A=
+#define MV64340_ETH_PORT_TX_TOKEN_BUCKET_RATE_CONFIG(port)         =
(0x2450 + (port<<10))=0A=
+#define MV64340_ETH_MAXIMUM_TRANSMIT_UNIT(port)                    =
(0x2458 + (port<<10))=0A=
+#define MV64340_ETH_PORT_MAXIMUM_TOKEN_BUCKET_SIZE(port)           =
(0x245c + (port<<10))=0A=
+#define MV64340_ETH_INTERRUPT_CAUSE_REG(port)                      =
(0x2460 + (port<<10))=0A=
+#define MV64340_ETH_INTERRUPT_CAUSE_EXTEND_REG(port)               =
(0x2464 + (port<<10))=0A=
+#define MV64340_ETH_INTERRUPT_MASK_REG(port)                       =
(0x2468 + (port<<10))=0A=
+#define MV64340_ETH_INTERRUPT_EXTEND_MASK_REG(port)                =
(0x246c + (port<<10))=0A=
+#define MV64340_ETH_RX_FIFO_URGENT_THRESHOLD_REG(port)             =
(0x2470 + (port<<10))=0A=
+#define MV64340_ETH_TX_FIFO_URGENT_THRESHOLD_REG(port)             =
(0x2474 + (port<<10))=0A=
+#define MV64340_ETH_RX_MINIMAL_FRAME_SIZE_REG(port)                =
(0x247c + (port<<10))=0A=
+#define MV64340_ETH_RX_DISCARDED_FRAMES_COUNTER(port)              =
(0x2484 + (port<<10)=0A=
+#define MV64340_ETH_PORT_DEBUG_0_REG(port)                         =
(0x248c + (port<<10))=0A=
+#define MV64340_ETH_PORT_DEBUG_1_REG(port)                         =
(0x2490 + (port<<10))=0A=
+#define MV64340_ETH_PORT_INTERNAL_ADDR_ERROR_REG(port)             =
(0x2494 + (port<<10))=0A=
+#define MV64340_ETH_INTERNAL_USE_REG(port)                         =
(0x24fc + (port<<10))=0A=
+#define MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG(port)                =
(0x2680 + (port<<10))=0A=
+#define MV64340_ETH_CURRENT_SERVED_TX_DESC_PTR(port)               =
(0x2684 + (port<<10))      =0A=
+#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_0(port)              =
(0x260c + (port<<10))     =0A=
+#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_1(port)              =
(0x261c + (port<<10))     =0A=
+#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_2(port)              =
(0x262c + (port<<10))     =0A=
+#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_3(port)              =
(0x263c + (port<<10))     =0A=
+#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_4(port)              =
(0x264c + (port<<10))     =0A=
+#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_5(port)              =
(0x265c + (port<<10))     =0A=
+#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_6(port)              =
(0x266c + (port<<10))     =0A=
+#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_7(port)              =
(0x267c + (port<<10))     =0A=
+#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_0(port)              =
(0x26c0 + (port<<10))     =0A=
+#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_1(port)              =
(0x26c4 + (port<<10))     =0A=
+#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_2(port)              =
(0x26c8 + (port<<10))     =0A=
+#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_3(port)              =
(0x26cc + (port<<10))     =0A=
+#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_4(port)              =
(0x26d0 + (port<<10))     =0A=
+#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_5(port)              =
(0x26d4 + (port<<10))     =0A=
+#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_6(port)              =
(0x26d8 + (port<<10))     =0A=
+#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_7(port)              =
(0x26dc + (port<<10))     =0A=
+#define MV64340_ETH_TX_QUEUE_0_TOKEN_BUCKET_COUNT(port)            =
(0x2700 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_1_TOKEN_BUCKET_COUNT(port)            =
(0x2710 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_2_TOKEN_BUCKET_COUNT(port)            =
(0x2720 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_3_TOKEN_BUCKET_COUNT(port)            =
(0x2730 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_4_TOKEN_BUCKET_COUNT(port)            =
(0x2740 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_5_TOKEN_BUCKET_COUNT(port)            =
(0x2750 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_6_TOKEN_BUCKET_COUNT(port)            =
(0x2760 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_7_TOKEN_BUCKET_COUNT(port)            =
(0x2770 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_0_TOKEN_BUCKET_CONFIG(port)           =
(0x2704 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_1_TOKEN_BUCKET_CONFIG(port)           =
(0x2714 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_2_TOKEN_BUCKET_CONFIG(port)           =
(0x2724 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_3_TOKEN_BUCKET_CONFIG(port)           =
(0x2734 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_4_TOKEN_BUCKET_CONFIG(port)           =
(0x2744 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_5_TOKEN_BUCKET_CONFIG(port)           =
(0x2754 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_6_TOKEN_BUCKET_CONFIG(port)           =
(0x2764 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_7_TOKEN_BUCKET_CONFIG(port)           =
(0x2774 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_0_ARBITER_CONFIG(port)                =
(0x2708 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_1_ARBITER_CONFIG(port)                =
(0x2718 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_2_ARBITER_CONFIG(port)                =
(0x2728 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_3_ARBITER_CONFIG(port)                =
(0x2738 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_4_ARBITER_CONFIG(port)                =
(0x2748 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_5_ARBITER_CONFIG(port)                =
(0x2758 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_6_ARBITER_CONFIG(port)                =
(0x2768 + (port<<10))=0A=
+#define MV64340_ETH_TX_QUEUE_7_ARBITER_CONFIG(port)                =
(0x2778 + (port<<10))=0A=
+#define MV64340_ETH_PORT_TX_TOKEN_BUCKET_COUNT(port)               =
(0x2780 + (port<<10))=0A=
+#define MV64340_ETH_DA_FILTER_SPECIAL_MULTICAST_TABLE_BASE(port)   =
(0x3400 + (port<<10))=0A=
+#define MV64340_ETH_DA_FILTER_OTHER_MULTICAST_TABLE_BASE(port)     =
(0x3500 + (port<<10))=0A=
+#define MV64340_ETH_DA_FILTER_UNICAST_TABLE_BASE(port)             =
(0x3600 + (port<<10))=0A=
+=0A=
+/*******************************************/=0A=
+/*          CUNIT  Registers               */=0A=
+/*******************************************/=0A=
+=0A=
+         /* Address Decoding Register Map */=0A=
+           =0A=
+#define MV64340_CUNIT_BASE_ADDR_REG0                                =
0xf200=0A=
+#define MV64340_CUNIT_BASE_ADDR_REG1                                =
0xf208=0A=
+#define MV64340_CUNIT_BASE_ADDR_REG2                                =
0xf210=0A=
+#define MV64340_CUNIT_BASE_ADDR_REG3                                =
0xf218=0A=
+#define MV64340_CUNIT_SIZE0                                         =
0xf204=0A=
+#define MV64340_CUNIT_SIZE1                                         =
0xf20c=0A=
+#define MV64340_CUNIT_SIZE2                                         =
0xf214=0A=
+#define MV64340_CUNIT_SIZE3                                         =
0xf21c=0A=
+#define MV64340_CUNIT_HIGH_ADDR_REMAP_REG0                          =
0xf240=0A=
+#define MV64340_CUNIT_HIGH_ADDR_REMAP_REG1                          =
0xf244=0A=
+#define MV64340_CUNIT_BASE_ADDR_ENABLE_REG                          =
0xf250=0A=
+#define MV64340_MPSC0_ACCESS_PROTECTION_REG                         =
0xf254=0A=
+#define MV64340_MPSC1_ACCESS_PROTECTION_REG                         =
0xf258=0A=
+#define MV64340_CUNIT_INTERNAL_SPACE_BASE_ADDR_REG                  =
0xf25C=0A=
+=0A=
+        /*  Error Report Registers  */=0A=
+=0A=
+#define MV64340_CUNIT_INTERRUPT_CAUSE_REG                           =
0xf310=0A=
+#define MV64340_CUNIT_INTERRUPT_MASK_REG                            =
0xf314=0A=
+#define MV64340_CUNIT_ERROR_ADDR                                    =
0xf318=0A=
+=0A=
+        /*  Cunit Control Registers */=0A=
+=0A=
+#define MV64340_CUNIT_ARBITER_CONTROL_REG                           =
0xf300=0A=
+#define MV64340_CUNIT_CONFIG_REG                                    =
0xb40c=0A=
+#define MV64340_CUNIT_CRROSBAR_TIMEOUT_REG                          =
0xf304=0A=
+=0A=
+        /*  Cunit Debug Registers   */=0A=
+=0A=
+#define MV64340_CUNIT_DEBUG_LOW                                     =
0xf340=0A=
+#define MV64340_CUNIT_DEBUG_HIGH                                    =
0xf344=0A=
+#define MV64340_CUNIT_MMASK                                         =
0xf380=0A=
+=0A=
+        /*  MPSCs Clocks Routing Registers  */=0A=
+=0A=
+#define MV64340_MPSC_ROUTING_REG                                    =
0xb400=0A=
+#define MV64340_MPSC_RX_CLOCK_ROUTING_REG                           =
0xb404=0A=
+#define MV64340_MPSC_TX_CLOCK_ROUTING_REG                           =
0xb408=0A=
+=0A=
+        /*  MPSCs Interrupts Registers    */=0A=
+=0A=
+#define MV64340_MPSC_CAUSE_REG(port)                               =
(0xb804 + (port<<3))=0A=
+#define MV64340_MPSC_MASK_REG(port)                                =
(0xb884 + (port<<3))=0A=
+ =0A=
+#define MV64340_MPSC_MAIN_CONFIG_LOW(port)                         =
(0x8000 + (port<<12))=0A=
+#define MV64340_MPSC_MAIN_CONFIG_HIGH(port)                        =
(0x8004 + (port<<12))    =0A=
+#define MV64340_MPSC_PROTOCOL_CONFIG(port)                         =
(0x8008 + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG1(port)                            =
(0x800c + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG2(port)                            =
(0x8010 + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG3(port)                            =
(0x8014 + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG4(port)                            =
(0x8018 + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG5(port)                            =
(0x801c + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG6(port)                            =
(0x8020 + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG7(port)                            =
(0x8024 + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG8(port)                            =
(0x8028 + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG9(port)                            =
(0x802c + (port<<12))    =0A=
+#define MV64340_MPSC_CHANNEL_REG10(port)                           =
(0x8030 + (port<<12))    =0A=
+        =0A=
+        /*  MPSC0 Registers      */=0A=
+=0A=
+=0A=
+/***************************************/=0A=
+/*          SDMA Registers             */=0A=
+/***************************************/=0A=
+=0A=
+#define MV64340_SDMA_CONFIG_REG(channel)                        (0x4000 =
+ (channel<<13))        =0A=
+#define MV64340_SDMA_COMMAND_REG(channel)                       (0x4008 =
+ (channel<<13))        =0A=
+#define MV64340_SDMA_CURRENT_RX_DESCRIPTOR_POINTER(channel)     (0x4810 =
+ (channel<<13))        =0A=
+#define MV64340_SDMA_CURRENT_TX_DESCRIPTOR_POINTER(channel)     (0x4c10 =
+ (channel<<13))        =0A=
+#define MV64340_SDMA_FIRST_TX_DESCRIPTOR_POINTER(channel)       (0x4c14 =
+ (channel<<13)) =0A=
+=0A=
+#define MV64340_SDMA_CAUSE_REG                                      =
0xb800=0A=
+#define MV64340_SDMA_MASK_REG                                       =
0xb880=0A=
+         =0A=
+/* BRG Interrupts */=0A=
+=0A=
+#define MV64340_BRG_CONFIG_REG(brg)                              =
(0xb200 + (brg<<3))=0A=
+#define MV64340_BRG_BAUDE_TUNING_REG(brg)                        =
(0xb208 + (brg<<3))=0A=
+#define MV64340_BRG_CAUSE_REG                                       =
0xb834=0A=
+#define MV64340_BRG_MASK_REG                                        =
0xb8b4=0A=
+=0A=
+/****************************************/=0A=
+/* DMA Channel Control			*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_DMA_CHANNEL0_CONTROL 				    0x840=0A=
+#define MV64340_DMA_CHANNEL0_CONTROL_HIGH			    0x880=0A=
+#define MV64340_DMA_CHANNEL1_CONTROL 				    0x844=0A=
+#define MV64340_DMA_CHANNEL1_CONTROL_HIGH			    0x884=0A=
+#define MV64340_DMA_CHANNEL2_CONTROL 				    0x848=0A=
+#define MV64340_DMA_CHANNEL2_CONTROL_HIGH			    0x888=0A=
+#define MV64340_DMA_CHANNEL3_CONTROL 				    0x84C=0A=
+#define MV64340_DMA_CHANNEL3_CONTROL_HIGH			    0x88C=0A=
+=0A=
+=0A=
+/****************************************/=0A=
+/*           IDMA Registers             */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_DMA_CHANNEL0_BYTE_COUNT                             =
0x800=0A=
+#define MV64340_DMA_CHANNEL1_BYTE_COUNT                             =
0x804=0A=
+#define MV64340_DMA_CHANNEL2_BYTE_COUNT                             =
0x808=0A=
+#define MV64340_DMA_CHANNEL3_BYTE_COUNT                             =
0x80C=0A=
+#define MV64340_DMA_CHANNEL0_SOURCE_ADDR                            =
0x810=0A=
+#define MV64340_DMA_CHANNEL1_SOURCE_ADDR                            =
0x814=0A=
+#define MV64340_DMA_CHANNEL2_SOURCE_ADDR                            =
0x818=0A=
+#define MV64340_DMA_CHANNEL3_SOURCE_ADDR                            =
0x81c=0A=
+#define MV64340_DMA_CHANNEL0_DESTINATION_ADDR                       =
0x820=0A=
+#define MV64340_DMA_CHANNEL1_DESTINATION_ADDR                       =
0x824=0A=
+#define MV64340_DMA_CHANNEL2_DESTINATION_ADDR                       =
0x828=0A=
+#define MV64340_DMA_CHANNEL3_DESTINATION_ADDR                       =
0x82C=0A=
+#define MV64340_DMA_CHANNEL0_NEXT_DESCRIPTOR_POINTER                =
0x830=0A=
+#define MV64340_DMA_CHANNEL1_NEXT_DESCRIPTOR_POINTER                =
0x834=0A=
+#define MV64340_DMA_CHANNEL2_NEXT_DESCRIPTOR_POINTER                =
0x838=0A=
+#define MV64340_DMA_CHANNEL3_NEXT_DESCRIPTOR_POINTER                =
0x83C=0A=
+#define MV64340_DMA_CHANNEL0_CURRENT_DESCRIPTOR_POINTER             =
0x870=0A=
+#define MV64340_DMA_CHANNEL1_CURRENT_DESCRIPTOR_POINTER             =
0x874=0A=
+#define MV64340_DMA_CHANNEL2_CURRENT_DESCRIPTOR_POINTER             =
0x878=0A=
+#define MV64340_DMA_CHANNEL3_CURRENT_DESCRIPTOR_POINTER             =
0x87C=0A=
+=0A=
+ /*  IDMA Address Decoding Base Address Registers  */=0A=
+ =0A=
+#define MV64340_DMA_BASE_ADDR_REG0                                  =
0xa00=0A=
+#define MV64340_DMA_BASE_ADDR_REG1                                  =
0xa08=0A=
+#define MV64340_DMA_BASE_ADDR_REG2                                  =
0xa10=0A=
+#define MV64340_DMA_BASE_ADDR_REG3                                  =
0xa18=0A=
+#define MV64340_DMA_BASE_ADDR_REG4                                  =
0xa20=0A=
+#define MV64340_DMA_BASE_ADDR_REG5                                  =
0xa28=0A=
+#define MV64340_DMA_BASE_ADDR_REG6                                  =
0xa30=0A=
+#define MV64340_DMA_BASE_ADDR_REG7                                  =
0xa38=0A=
+ =0A=
+ /*  IDMA Address Decoding Size Address Register   */=0A=
+ =0A=
+#define MV64340_DMA_SIZE_REG0                                       =
0xa04=0A=
+#define MV64340_DMA_SIZE_REG1                                       =
0xa0c=0A=
+#define MV64340_DMA_SIZE_REG2                                       =
0xa14=0A=
+#define MV64340_DMA_SIZE_REG3                                       =
0xa1c=0A=
+#define MV64340_DMA_SIZE_REG4                                       =
0xa24=0A=
+#define MV64340_DMA_SIZE_REG5                                       =
0xa2c=0A=
+#define MV64340_DMA_SIZE_REG6                                       =
0xa34=0A=
+#define MV64340_DMA_SIZE_REG7                                       =
0xa3C=0A=
+=0A=
+ /* IDMA Address Decoding High Address Remap and Access =0A=
+                  Protection Registers                    */=0A=
+                  =0A=
+#define MV64340_DMA_HIGH_ADDR_REMAP_REG0                            =
0xa60=0A=
+#define MV64340_DMA_HIGH_ADDR_REMAP_REG1                            =
0xa64=0A=
+#define MV64340_DMA_HIGH_ADDR_REMAP_REG2                            =
0xa68=0A=
+#define MV64340_DMA_HIGH_ADDR_REMAP_REG3                            =
0xa6C=0A=
+#define MV64340_DMA_BASE_ADDR_ENABLE_REG                            =
0xa80=0A=
+#define MV64340_DMA_CHANNEL0_ACCESS_PROTECTION_REG                  =
0xa70=0A=
+#define MV64340_DMA_CHANNEL1_ACCESS_PROTECTION_REG                  =
0xa74=0A=
+#define MV64340_DMA_CHANNEL2_ACCESS_PROTECTION_REG                  =
0xa78=0A=
+#define MV64340_DMA_CHANNEL3_ACCESS_PROTECTION_REG                  =
0xa7c=0A=
+#define MV64340_DMA_ARBITER_CONTROL                                 =
0x860=0A=
+#define MV64340_DMA_CROSS_BAR_TIMEOUT                               =
0x8d0=0A=
+=0A=
+ /*  IDMA Headers Retarget Registers   */=0A=
+=0A=
+#define MV64340_DMA_HEADERS_RETARGET_CONTROL                        =
0xa84=0A=
+#define MV64340_DMA_HEADERS_RETARGET_BASE                           =
0xa88=0A=
+=0A=
+ /*  IDMA Interrupt Register  */=0A=
+=0A=
+#define MV64340_DMA_INTERRUPT_CAUSE_REG                             =
0x8c0=0A=
+#define MV64340_DMA_INTERRUPT_CAUSE_MASK                            =
0x8c4=0A=
+#define MV64340_DMA_ERROR_ADDR                                      =
0x8c8=0A=
+#define MV64340_DMA_ERROR_SELECT                                    =
0x8cc=0A=
+=0A=
+ /*  IDMA Debug Register ( for internal use )    */=0A=
+=0A=
+#define MV64340_DMA_DEBUG_LOW                                       =
0x8e0=0A=
+#define MV64340_DMA_DEBUG_HIGH                                      =
0x8e4=0A=
+#define MV64340_DMA_SPARE                                           =
0xA8C=0A=
+=0A=
+/****************************************/=0A=
+/* Timer_Counter 			*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_TIMER_COUNTER0					    0x850=0A=
+#define MV64340_TIMER_COUNTER1					    0x854=0A=
+#define MV64340_TIMER_COUNTER2					    0x858=0A=
+#define MV64340_TIMER_COUNTER3					    0x85C=0A=
+#define MV64340_TIMER_COUNTER_0_3_CONTROL			    0x864=0A=
+#define MV64340_TIMER_COUNTER_0_3_INTERRUPT_CAUSE		    0x868=0A=
+#define MV64340_TIMER_COUNTER_0_3_INTERRUPT_MASK      		    0x86c=0A=
+=0A=
+/****************************************/=0A=
+/*         Watchdog registers  	        */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_WATCHDOG_CONFIG_REG                                 =
0xb410=0A=
+#define MV64340_WATCHDOG_VALUE_REG                                  =
0xb414=0A=
+=0A=
+/****************************************/=0A=
+/* I2C Registers                        */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_I2C_SLAVE_ADDR                                      =
0xc000=0A=
+#define MV64340_I2C_EXTENDED_SLAVE_ADDR                             =
0xc010=0A=
+#define MV64340_I2C_DATA                                            =
0xc004=0A=
+#define MV64340_I2C_CONTROL                                         =
0xc008=0A=
+#define MV64340_I2C_STATUS_BAUDE_RATE                               =
0xc00C=0A=
+#define MV64340_I2C_SOFT_RESET                                      =
0xc01c=0A=
+=0A=
+/****************************************/=0A=
+/* GPP Interface Registers              */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_GPP_IO_CONTROL                                      =
0xf100=0A=
+#define MV64340_GPP_LEVEL_CONTROL                                   =
0xf110=0A=
+#define MV64340_GPP_VALUE                                           =
0xf104=0A=
+#define MV64340_GPP_INTERRUPT_CAUSE                                 =
0xf108=0A=
+#define MV64340_GPP_INTERRUPT_MASK0                                 =
0xf10c=0A=
+#define MV64340_GPP_INTERRUPT_MASK1                                 =
0xf114=0A=
+#define MV64340_GPP_VALUE_SET                                       =
0xf118=0A=
+#define MV64340_GPP_VALUE_CLEAR                                     =
0xf11c=0A=
+=0A=
+/****************************************/=0A=
+/* Interrupt Controller Registers       */=0A=
+/****************************************/=0A=
+=0A=
+/****************************************/=0A=
+/* Interrupts	  			*/=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_MAIN_INTERRUPT_CAUSE_LOW                            =
0x004=0A=
+#define MV64340_MAIN_INTERRUPT_CAUSE_HIGH                           =
0x00c=0A=
+#define MV64340_CPU_INTERRUPT0_MASK_LOW                             =
0x014=0A=
+#define MV64340_CPU_INTERRUPT0_MASK_HIGH                            =
0x01c=0A=
+#define MV64340_CPU_INTERRUPT0_SELECT_CAUSE                         =
0x024=0A=
+#define MV64340_CPU_INTERRUPT1_MASK_LOW                             =
0x034=0A=
+#define MV64340_CPU_INTERRUPT1_MASK_HIGH                            =
0x03c=0A=
+#define MV64340_CPU_INTERRUPT1_SELECT_CAUSE                         =
0x044=0A=
+#define MV64340_INTERRUPT0_MASK_0_LOW                               =
0x054=0A=
+#define MV64340_INTERRUPT0_MASK_0_HIGH                              =
0x05c=0A=
+#define MV64340_INTERRUPT0_SELECT_CAUSE                             =
0x064=0A=
+#define MV64340_INTERRUPT1_MASK_0_LOW                               =
0x074=0A=
+#define MV64340_INTERRUPT1_MASK_0_HIGH                              =
0x07c=0A=
+#define MV64340_INTERRUPT1_SELECT_CAUSE                             =
0x084=0A=
+=0A=
+/****************************************/=0A=
+/*      MPP Interface Registers         */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_MPP_CONTROL0                                        =
0xf000=0A=
+#define MV64340_MPP_CONTROL1                                        =
0xf004=0A=
+#define MV64340_MPP_CONTROL2                                        =
0xf008=0A=
+#define MV64340_MPP_CONTROL3                                        =
0xf00c=0A=
+=0A=
+/****************************************/=0A=
+/*    Serial Initialization registers   */=0A=
+/****************************************/=0A=
+=0A=
+#define MV64340_SERIAL_INIT_LAST_DATA                               =
0xf324=0A=
+#define MV64340_SERIAL_INIT_CONTROL                                 =
0xf328=0A=
+#define MV64340_SERIAL_INIT_STATUS                                  =
0xf32c=0A=
+=0A=
+#endif=0A=
--- /dev/null	Tue May  5 13:32:27 1998=0A=
+++ include/asm-mips/mv64340_dep.h	Fri Nov  8 14:56:08 2002=0A=
@@ -0,0 +1,51 @@=0A=
+/*=0A=
+ * Copyright 2002 Momentum Computer Inc.=0A=
+ * Author: Matthew Dharm <mdharm@momenco.com>=0A=
+ *=0A=
+ * include/asm-mips/mv64340-dep.h=0A=
+ *     Board-dependent definitions for MV-64340 chip.=0A=
+ *=0A=
+ * This program is free software; you can redistribute  it and/or =
modify it=0A=
+ * under  the terms of  the GNU General  Public License as published by =
the=0A=
+ * Free Software Foundation;  either version 2 of the  License, or (at =
your=0A=
+ * option) any later version.=0A=
+ */=0A=
+=0A=
+#ifndef __MV64340_DEP_H__=0A=
+#define __MV64340_DEP_H__=0A=
+=0A=
+#include <asm/addrspace.h>		/* for KSEG1ADDR() */=0A=
+#include <asm/byteorder.h>		/* for cpu_to_le32() */=0A=
+=0A=
+extern unsigned long mv64340_base;=0A=
+=0A=
+#define MV64340_BASE       (mv64340_base)=0A=
+=0A=
+/*=0A=
+ * Because of an error/peculiarity in the Galileo chip, we need to swap =
the=0A=
+ * bytes when running bigendian.=0A=
+ */=0A=
+=0A=
+#define MV_WRITE(ofs, data)  \=0A=
+        *(volatile u32 *)(MV64340_BASE+(ofs)) =3D cpu_to_le32(data)=0A=
+#define MV_READ(ofs, data)   \=0A=
+        *(data) =3D le32_to_cpu(*(volatile u32 *)(MV64340_BASE+(ofs)))=0A=
+#define MV_READ_DATA(ofs)    \=0A=
+        le32_to_cpu(*(volatile u32 *)(MV64340_BASE+(ofs)))=0A=
+=0A=
+#define MV_WRITE_16(ofs, data)  \=0A=
+        *(volatile u16 *)(MV64340_BASE+(ofs)) =3D cpu_to_le16(data)=0A=
+#define MV_READ_16(ofs, data)   \=0A=
+        *(data) =3D le16_to_cpu(*(volatile u16 *)(MV64340_BASE+(ofs)))=0A=
+=0A=
+#define MV_WRITE_8(ofs, data)  \=0A=
+        *(volatile u8 *)(MV64340_BASE+(ofs)) =3D data=0A=
+#define MV_READ_8(ofs, data)   \=0A=
+        *(data) =3D *(volatile u8 *)(MV64340_BASE+(ofs))=0A=
+=0A=
+#define MV_SET_REG_BITS(ofs,bits) \=0A=
+	(*((volatile u32 *)(MV64340_BASE+(ofs)))) |=3D ((u32)cpu_to_le32(bits))=0A=
+#define MV_RESET_REG_BITS(ofs,bits) \=0A=
+	(*((volatile u32 *)(MV64340_BASE+(ofs)))) &=3D =
~((u32)cpu_to_le32(bits))=0A=
+=0A=
+#endif=0A=
Index: arch/mips/Makefile=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/Makefile,v=0A=
retrieving revision 1.78.2.16=0A=
diff -u -u -r1.78.2.16 Makefile=0A=
--- arch/mips/Makefile	8 Nov 2002 18:45:08 -0000	1.78.2.16=0A=
+++ arch/mips/Makefile	11 Nov 2002 23:25:55 -0000=0A=
@@ -88,6 +88,9 @@=0A=
 ifdef CONFIG_CPU_RM7000=0A=
 GCCFLAGS	+=3D -mcpu=3Dr5000 -mips2 -Wa,--trap=0A=
 endif=0A=
+ifdef CONFIG_CPU_SR71000=0A=
+GCCFLAGS	+=3D -mcpu=3Dr5000 -mips2 -Wa,--trap=0A=
+endif=0A=
 ifdef CONFIG_CPU_SB1=0A=
 #GCCFLAGS	+=3D -mcpu=3Dsb1 -mips2 -Wa,--trap=0A=
 GCCFLAGS	+=3D -mcpu=3Dr5000 -mips2 -Wa,--trap=0A=
@@ -297,6 +300,17 @@=0A=
 # mips_io_port_base.=0A=
 CORE_FILES	+=3D arch/mips/momentum/ocelot_g/ocelot_g.o=0A=
 SUBDIRS		+=3D arch/mips/momentum/ocelot_g=0A=
+LOADADDR	:=3D 0x80100000=0A=
+endif=0A=
+=0A=
+#=0A=
+# Momentum Ocelot-C and -CS boards=0A=
+#=0A=
+ifdef CONFIG_MOMENCO_OCELOT_C=0A=
+# The Ocelot-C[S] setup.o must be linked early - it does the ioremap() =
for the=0A=
+# mips_io_port_base.=0A=
+CORE_FILES	+=3D arch/mips/momentum/ocelot_c/ocelot_c.o=0A=
+SUBDIRS		+=3D arch/mips/momentum/ocelot_c=0A=
 LOADADDR	:=3D 0x80100000=0A=
 endif=0A=
 =0A=
Index: arch/mips/config-shared.in=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/Attic/config-shared.in,v=0A=
retrieving revision 1.1.2.29=0A=
diff -u -u -r1.1.2.29 config-shared.in=0A=
--- arch/mips/config-shared.in	8 Nov 2002 01:39:44 -0000	1.1.2.29=0A=
+++ arch/mips/config-shared.in	11 Nov 2002 23:25:55 -0000=0A=
@@ -58,6 +58,7 @@=0A=
 dep_bool 'Support for MIPS SEAD board (EXPERIMENTAL)' CONFIG_MIPS_SEAD =
$CONFIG_EXPERIMENTAL=0A=
 bool 'Support for Momentum Ocelot board' CONFIG_MOMENCO_OCELOT=0A=
 bool 'Support for Momentum Ocelot-G board' CONFIG_MOMENCO_OCELOT_G=0A=
+bool 'Support for Momentum Ocelot-C and -CS boards' =
CONFIG_MOMENCO_OCELOT_C=0A=
 dep_bool 'Support for NEC DDB Vrc-5074 (EXPERIMENTAL)' CONFIG_DDB5074 =
$CONFIG_EXPERIMENTAL=0A=
 bool 'Support for NEC DDB Vrc-5476' CONFIG_DDB5476=0A=
 bool 'Support for NEC DDB Vrc-5477' CONFIG_DDB5477=0A=
@@ -293,6 +294,13 @@=0A=
    define_bool CONFIG_NONCOHERENT_IO y=0A=
    define_bool CONFIG_OLD_TIME_C y=0A=
 fi=0A=
+if [ "$CONFIG_MOMENCO_OCELOT_C" =3D "y" ]; then=0A=
+   define_bool CONFIG_PCI y=0A=
+   define_bool CONFIG_SWAP_IO_SPACE y=0A=
+   define_bool CONFIG_NEW_IRQ y=0A=
+   define_bool CONFIG_NONCOHERENT_IO y=0A=
+   define_bool CONFIG_NEW_TIME_C y=0A=
+fi=0A=
 if [ "$CONFIG_DDB5074" =3D "y" ]; then=0A=
    define_bool CONFIG_HAVE_STD_PC_SERIAL_PORT y=0A=
    define_bool CONFIG_I8259 y=0A=
@@ -463,7 +471,8 @@=0A=
 	 R8000	CONFIG_CPU_R8000 \=0A=
 	 R10000	CONFIG_CPU_R10000 \=0A=
 	 RM7000	CONFIG_CPU_RM7000 \=0A=
-	 SB1	CONFIG_CPU_SB1" R4x00=0A=
+	 SB1	CONFIG_CPU_SB1 \=0A=
+	 SR71k	CONFIG_CPU_SR71000" R4x00=0A=
 =0A=
 if [ "$CONFIG_SMP_CAPABLE" =3D "y" ]; then=0A=
    bool '  Multi-Processing support' CONFIG_SMP=0A=
@@ -512,6 +521,7 @@=0A=
      "$CONFIG_CPU_RM7000" =3D "y" -o \=0A=
      "$CONFIG_CPU_R10000" =3D "y" -o \=0A=
      "$CONFIG_CPU_SB1"    =3D "y" -o \=0A=
+     "$CONFIG_CPU_SR71000"=3D "y" -o \=0A=
      "$CONFIG_CPU_MIPS32" =3D "y" -o \=0A=
      "$CONFIG_CPU_MIPS64" =3D "y" ]; then=0A=
    dep_bool '  Support for 64-bit physical address space' =
CONFIG_64BIT_PHYS_ADDR $CONFIG_MIPS32=0A=
Index: arch/mips/kernel/Makefile=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/kernel/Makefile,v=0A=
retrieving revision 1.51.2.9=0A=
diff -u -u -r1.51.2.9 Makefile=0A=
--- arch/mips/kernel/Makefile	31 Oct 2002 19:54:04 -0000	1.51.2.9=0A=
+++ arch/mips/kernel/Makefile	11 Nov 2002 23:25:55 -0000=0A=
@@ -33,6 +33,7 @@=0A=
 obj-$(CONFIG_CPU_NEVADA)	+=3D r4k_fpu.o r4k_switch.o=0A=
 obj-$(CONFIG_CPU_R10000)	+=3D r4k_fpu.o r4k_switch.o=0A=
 obj-$(CONFIG_CPU_SB1)		+=3D r4k_fpu.o r4k_switch.o=0A=
+obj-$(CONFIG_CPU_SR71000)	+=3D r4k_fpu.o r4k_switch.o=0A=
 obj-$(CONFIG_CPU_MIPS32)	+=3D r4k_fpu.o r4k_switch.o=0A=
 obj-$(CONFIG_CPU_MIPS64)	+=3D r4k_fpu.o r4k_switch.o=0A=
 obj-$(CONFIG_CPU_R6000)		+=3D r6000_fpu.o r4k_switch.o=0A=
Index: arch/mips/kernel/cpu-probe.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/kernel/cpu-probe.c,v=0A=
retrieving revision 1.1.2.7=0A=
diff -u -u -r1.1.2.7 cpu-probe.c=0A=
--- arch/mips/kernel/cpu-probe.c	7 Nov 2002 01:47:45 -0000	1.1.2.7=0A=
+++ arch/mips/kernel/cpu-probe.c	11 Nov 2002 23:25:55 -0000=0A=
@@ -5,6 +5,7 @@=0A=
 #include <asm/cpu.h>=0A=
 #include <asm/fpu.h>=0A=
 #include <asm/mipsregs.h>=0A=
+#include <asm/cacheops.h>=0A=
 =0A=
 /*=0A=
  * Not all of the MIPS CPUs have the "wait" instruction available. =
Moreover,=0A=
@@ -46,6 +47,44 @@=0A=
 #endif=0A=
 }=0A=
 =0A=
+#ifdef CONFIG_CPU_SR71000=0A=
+/* Fix the sr71000 wait errata. We have a special ret_from_irq that is =
executed=0A=
+ * when a jump is converted to a nop. Before we wait we do that =
conversion.=0A=
+ * This engages the code that detects the errata. This way we don't =
loose any=0A=
+ * speed in the normal case. Though it does make the timing race with =
wait =0A=
+ * longer..=0A=
+ */=0A=
+extern asmlinkage void ret_from_irq_sr71000(void);=0A=
+=0A=
+static void sr71000_wait(void)=0A=
+{=0A=
+  u32 *jump =3D ((u32 *)&ret_from_irq_sr71000);=0A=
+   __asm__ __volatile__=0A=
+      (=0A=
+       ".set push\n\t"=0A=
+       ".set noat\n\t"=0A=
+       ".set noreorder\n\t"=0A=
+       ".set mips3\n\t"=0A=
+       "lw $1,0(%0)\n\t"=0A=
+       "sw $0,0(%0)\n\t"=0A=
+       =0A=
+       // No snoopy i/d cache..=0A=
+       "cache %1,0(%0)\n\t"=0A=
+       "cache %2,0(%0)\n\t"=0A=
+       =0A=
+       "wait\n\t"=0A=
+       "sw $1,0(%0)\n\t"=0A=
+       =0A=
+       "cache %1,0(%0)\n\t"=0A=
+       "cache %2,0(%0)\n\t"=0A=
+       =0A=
+       ".set pop\n\t"=0A=
+       :=0A=
+       : "r" (jump), "i"(Hit_Writeback_D), "i"(Hit_Invalidate_I)=0A=
+       : "$1");=0A=
+}=0A=
+#endif=0A=
+=0A=
 static inline void check_wait(void)=0A=
 {=0A=
 	printk("Checking for 'wait' instruction... ");=0A=
@@ -84,6 +123,12 @@=0A=
 		cpu_wait =3D au1k_wait;=0A=
 		printk(" available.\n");=0A=
 		break;=0A=
+#ifdef CONFIG_CPU_SR71000=0A=
+	case CPU_SR71000:=0A=
+		cpu_wait =3D sr71000_wait;=0A=
+		printk(" available, errata workaround enabled.\n");=0A=
+		break;=0A=
+#endif=0A=
 	default:=0A=
 		printk(" unavailable.\n");=0A=
 		break;=0A=
@@ -469,6 +514,23 @@=0A=
 			/* FPU in pass1 is known to have issues. */=0A=
 			mips_cpu.options |=3D MIPS_CPU_FPU;=0A=
 #endif=0A=
+			break;=0A=
+		default:=0A=
+			mips_cpu.cputype =3D CPU_UNKNOWN;=0A=
+			break;=0A=
+		}=0A=
+		break;=0A=
+=0A=
+	case PRID_COMP_SANDCRAFT:=0A=
+		switch (mips_cpu.processor_id & 0xff00) {=0A=
+		case PRID_IMP_SR71000:=0A=
+			mips_cpu.cputype =3D CPU_SR71000;=0A=
+			mips_cpu.isa_level =3D MIPS_CPU_ISA_M64;=0A=
+			mips_cpu.options =3D MIPS_CPU_TLB | MIPS_CPU_4KEX |=0A=
+                                           MIPS_CPU_4KTLB | =
MIPS_CPU_FPU |=0A=
+			                   MIPS_CPU_COUNTER | MIPS_CPU_MCHECK;=0A=
+			mips_cpu.scache.ways =3D 8;=0A=
+			mips_cpu.tlbsize =3D 64;=0A=
 			break;=0A=
 		default:=0A=
 			mips_cpu.cputype =3D CPU_UNKNOWN;=0A=
Index: arch/mips/kernel/entry.S=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/kernel/entry.S,v=0A=
retrieving revision 1.34.2.7=0A=
diff -u -u -r1.34.2.7 entry.S=0A=
--- arch/mips/kernel/entry.S	5 Aug 2002 23:53:33 -0000	1.34.2.7=0A=
+++ arch/mips/kernel/entry.S	11 Nov 2002 23:25:55 -0000=0A=
@@ -35,7 +35,33 @@=0A=
 FEXPORT(ret_from_exception)=0A=
 		lw	t0, PT_STATUS(sp)	# returning to kernel mode?=0A=
 		andi	t0, t0, KU_USER=0A=
+#ifndef CONFIG_CPU_SR71000=0A=
 		beqz	t0, restore_all=0A=
+#else=0A=
+		bnez	t0, ret_from_sys_call=0A=
+/* SR71000 Errata #1:  The wait instruction does not advance the EPC.  =
The=0A=
+ * solution is to check if the EPC is pointing at a wait instruction =
and (if=0A=
+ * so), skip it.  This must be after ret_from_irq.  The setup code will =
nop=0A=
+ * out the jump below so we fall through.  This fixup only occurs if =
they are=0A=
+ * in the kernel.=0A=
+ */=0A=
+FEXPORT(ret_from_irq_sr71000)=0A=
+		j	restore_all=0A=
+=0A=
+		// Fetch EPC=0A=
+		lw	t0, PT_EPC(sp)=0A=
+ =0A=
+		// Is the instruction a wait?=0A=
+		li	t2, 0x42000000=0A=
+		lw	t1, 0(t0)=0A=
+		ori	t2, t2, 0x20=0A=
+		bne	t1, t2, restore_all=0A=
+=0A=
+		// Yep, go to the next instruction=0A=
+		addu	t1, t0, 4=0A=
+		sw	t1, PT_EPC(sp)=0A=
+		j	restore_all=0A=
+#endif=0A=
 =0A=
 FEXPORT(ret_from_sys_call)		# here to prevent code duplication=0A=
 ret_from_schedule:=0A=
Index: arch/mips/kernel/proc.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/kernel/proc.c,v=0A=
retrieving revision 1.27.2.11=0A=
diff -u -u -r1.27.2.11 proc.c=0A=
--- arch/mips/kernel/proc.c	7 Nov 2002 01:47:45 -0000	1.27.2.11=0A=
+++ arch/mips/kernel/proc.c	11 Nov 2002 23:25:56 -0000=0A=
@@ -73,7 +73,8 @@=0A=
 	[CPU_VR4122]	"NEC VR4122",=0A=
 	[CPU_VR4131]	"NEC VR4131",=0A=
 	[CPU_VR4181]	"NEC VR4181",=0A=
-	[CPU_VR4181A]	"NEC VR4181A"=0A=
+	[CPU_VR4181A]	"NEC VR4181A",=0A=
+	[CPU_SR71000]	"Sandcraft SR71000"=0A=
 };=0A=
 =0A=
 =0A=
Index: arch/mips/kernel/setup.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/kernel/setup.c,v=0A=
retrieving revision 1.96.2.32=0A=
diff -u -u -r1.96.2.32 setup.c=0A=
--- arch/mips/kernel/setup.c	6 Oct 2002 02:01:33 -0000	1.96.2.32=0A=
+++ arch/mips/kernel/setup.c	11 Nov 2002 23:25:56 -0000=0A=
@@ -483,6 +483,7 @@=0A=
 	void ikos_setup(void);=0A=
 	void momenco_ocelot_setup(void);=0A=
 	void momenco_ocelot_g_setup(void);=0A=
+	void momenco_ocelot_c_setup(void);=0A=
 	void nino_setup(void);=0A=
 	void nec_osprey_setup(void);=0A=
 	void nec_eagle_setup(void);=0A=
@@ -552,6 +553,11 @@=0A=
 #ifdef CONFIG_MOMENCO_OCELOT_G=0A=
 	case MACH_GROUP_MOMENCO:=0A=
 		momenco_ocelot_g_setup();=0A=
+		break;=0A=
+#endif=0A=
+#ifdef CONFIG_MOMENCO_OCELOT_C=0A=
+	case MACH_GROUP_MOMENCO:=0A=
+		momenco_ocelot_c_setup();=0A=
 		break;=0A=
 #endif=0A=
 #ifdef CONFIG_MIPS_SEAD=0A=
Index: arch/mips/mm/Makefile=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/mm/Makefile,v=0A=
retrieving revision 1.27.2.3=0A=
diff -u -u -r1.27.2.3 Makefile=0A=
--- arch/mips/mm/Makefile	2 Oct 2002 13:08:16 -0000	1.27.2.3=0A=
+++ arch/mips/mm/Makefile	11 Nov 2002 23:25:56 -0000=0A=
@@ -30,6 +30,7 @@=0A=
 obj-$(CONFIG_CPU_MIPS32)	+=3D pg-mips32.o c-mips32.o tlb-r4k.o =
tlbex-r4k.o=0A=
 obj-$(CONFIG_CPU_MIPS64)	+=3D pg-mips32.o c-mips32.o tlb-r4k.o =
tlbex-r4k.o=0A=
 obj-$(CONFIG_CPU_SB1)		+=3D pg-sb1.o c-sb1.o tlb-sb1.o tlbex-r4k.o=0A=
+obj-$(CONFIG_CPU_SR71000)	+=3D pg-mips32.o c-sr71000.o tlb-r4k.o =
tlbex-r4k.o=0A=
 =0A=
 obj-$(CONFIG_SB1_CACHE_ERROR)	+=3D cex-sb1.o cerr-sb1.o=0A=
 =0A=
Index: arch/mips/mm/loadmmu.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/arch/mips/mm/loadmmu.c,v=0A=
retrieving revision 1.45.2.1=0A=
diff -u -u -r1.45.2.1 loadmmu.c=0A=
--- arch/mips/mm/loadmmu.c	6 Aug 2002 01:46:58 -0000	1.45.2.1=0A=
+++ arch/mips/mm/loadmmu.c	11 Nov 2002 23:25:56 -0000=0A=
@@ -61,6 +61,7 @@=0A=
 extern void ld_mmu_andes(void);=0A=
 extern void ld_mmu_sb1(void);=0A=
 extern void ld_mmu_mips32(void);=0A=
+extern void ld_mmu_sr71000(void);=0A=
 extern void r3k_tlb_init(void);=0A=
 extern void r4k_tlb_init(void);=0A=
 extern void sb1_tlb_init(void);=0A=
@@ -76,6 +77,10 @@=0A=
 #endif=0A=
 #if defined(CONFIG_CPU_RM7000)=0A=
 		ld_mmu_rm7k();=0A=
+		r4k_tlb_init();=0A=
+#endif=0A=
+#if defined(CONFIG_CPU_SR71000)=0A=
+		ld_mmu_sr71000();=0A=
 		r4k_tlb_init();=0A=
 #endif=0A=
 #if defined(CONFIG_CPU_R5432) || defined(CONFIG_CPU_R5500)=0A=
Index: drivers/mtd/devices/docprobe.c=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/drivers/mtd/devices/docprobe.c,v=0A=
retrieving revision 1.3.2.1=0A=
diff -u -u -r1.3.2.1 docprobe.c=0A=
--- drivers/mtd/devices/docprobe.c	23 Sep 2002 01:04:02 -0000	1.3.2.1=0A=
+++ drivers/mtd/devices/docprobe.c	11 Nov 2002 23:25:57 -0000=0A=
@@ -89,7 +89,7 @@=0A=
 #elif defined(CONFIG_MOMENCO_OCELOT)=0A=
 	0x2f000000,=0A=
 	0xff000000,=0A=
-#elif defined(CONFIG_MOMENCO_OCELOT_G)=0A=
+#elif defined(CONFIG_MOMENCO_OCELOT_G) || defined =
(CONFIG_MOMENCO_OCELOT_C)=0A=
 	0xff000000,=0A=
 #else=0A=
 #warning Unknown architecture for DiskOnChip. No default probe =
locations defined=0A=
Index: include/asm-mips/bootinfo.h=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/include/asm-mips/bootinfo.h,v=0A=
retrieving revision 1.43.2.17=0A=
diff -u -u -r1.43.2.17 bootinfo.h=0A=
--- include/asm-mips/bootinfo.h	6 Oct 2002 02:01:33 -0000	1.43.2.17=0A=
+++ include/asm-mips/bootinfo.h	11 Nov 2002 23:25:58 -0000=0A=
@@ -125,6 +125,7 @@=0A=
  */=0A=
 #define MACH_MOMENCO_OCELOT		0=0A=
 #define MACH_MOMENCO_OCELOT_G		1=0A=
+#define MACH_MOMENCO_OCELOT_C		2=0A=
 =0A=
 /*=0A=
  * Valid machtype for group ITE=0A=
Index: include/asm-mips/cpu.h=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/include/asm-mips/cpu.h,v=0A=
retrieving revision 1.24.2.12=0A=
diff -u -u -r1.24.2.12 cpu.h=0A=
--- include/asm-mips/cpu.h	5 Aug 2002 23:53:37 -0000	1.24.2.12=0A=
+++ include/asm-mips/cpu.h	11 Nov 2002 23:25:58 -0000=0A=
@@ -29,6 +29,7 @@=0A=
 #define PRID_COMP_BROADCOM     0x020000=0A=
 #define PRID_COMP_ALCHEMY      0x030000=0A=
 #define PRID_COMP_SIBYTE       0x040000=0A=
+#define PRID_COMP_SANDCRAFT    0x050000=0A=
 =0A=
 /*=0A=
  * Assigned values for the product ID register.  In order to detect a=0A=
@@ -76,6 +77,12 @@=0A=
 #define PRID_IMP_SB1            0x0100=0A=
 =0A=
 /*=0A=
+ * These are the PRID's for when 23:16 =3D=3D PRID_COMP_SANDCRAFT=0A=
+ */=0A=
+=0A=
+#define PRID_IMP_SR71000        0x0400=0A=
+=0A=
+/*=0A=
  * Definitions for 7:0 on legacy processors=0A=
  */=0A=
 =0A=
@@ -139,7 +146,7 @@=0A=
 	CPU_TX3912, CPU_TX3922, CPU_TX3927, CPU_AU1000, CPU_4KEC, CPU_4KSC,=0A=
 	CPU_VR41XX, CPU_R5500, CPU_TX49XX, CPU_TX39XX, CPU_AU1500, CPU_20KC,=0A=
 	CPU_VR4111, CPU_VR4121, CPU_VR4122, CPU_VR4131, CPU_VR4181, =
CPU_VR4181A,=0A=
-	CPU_AU1100, CPU_LAST=0A=
+	CPU_AU1100, CPU_SR71000, CPU_LAST=0A=
 };=0A=
 =0A=
 #endif /* !__ASSEMBLY__ */=0A=
Index: include/asm-mips/serial.h=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /home/cvs/linux/include/asm-mips/serial.h,v=0A=
retrieving revision 1.23.2.9=0A=
diff -u -u -r1.23.2.9 serial.h=0A=
--- include/asm-mips/serial.h	7 Nov 2002 01:47:46 -0000	1.23.2.9=0A=
+++ include/asm-mips/serial.h	11 Nov 2002 23:25:58 -0000=0A=
@@ -311,6 +311,27 @@=0A=
 #define MOMENCO_OCELOT_G_SERIAL_PORT_DEFNS=0A=
 #endif=0A=
 =0A=
+#ifdef CONFIG_MOMENCO_OCELOT_C=0A=
+/* Ordinary NS16552 duart with a 20MHz crystal.  */=0A=
+#define OCELOT_C_BASE_BAUD ( 20000000 / 16 )=0A=
+=0A=
+#define OCELOT_C_SERIAL1_IRQ	80=0A=
+#define OCELOT_C_SERIAL1_BASE	0xfd000020=0A=
+=0A=
+#define OCELOT_C_SERIAL2_IRQ	81=0A=
+#define OCELOT_C_SERIAL2_BASE	0xfd000000=0A=
+=0A=
+#define _OCELOT_C_SERIAL_INIT(int, base)				 \=0A=
+	{ baud_base: OCELOT_C_BASE_BAUD, irq: int, flags: STD_COM_FLAGS,\=0A=
+	  iomem_base: (u8 *) base, iomem_reg_shift: 2,			 \=0A=
+	  io_type: SERIAL_IO_MEM }=0A=
+#define MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS				\=0A=
+	_OCELOT_C_SERIAL_INIT(OCELOT_C_SERIAL1_IRQ, OCELOT_C_SERIAL1_BASE), \=0A=
+	_OCELOT_C_SERIAL_INIT(OCELOT_C_SERIAL2_IRQ, OCELOT_C_SERIAL2_BASE)=0A=
+#else=0A=
+#define MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS=0A=
+#endif=0A=
+=0A=
 #ifdef CONFIG_DDB5477=0A=
 #include <asm/ddb5xxx/ddb5477.h>=0A=
 #define DDB5477_SERIAL_PORT_DEFNS                                       =
      \=0A=
@@ -338,6 +359,7 @@=0A=
 	HUB6_SERIAL_PORT_DFNS			\=0A=
 	MOMENCO_OCELOT_SERIAL_PORT_DEFNS	\=0A=
 	MOMENCO_OCELOT_G_SERIAL_PORT_DEFNS	\=0A=
+	MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS	\=0A=
 	AU1000_SERIAL_PORT_DEFNS		\=0A=
-        TXX927_SERIAL_PORT_DEFNS        	\=0A=
+	TXX927_SERIAL_PORT_DEFNS        	\=0A=
 	DDB5477_SERIAL_PORT_DEFNS=0A=

------=_NextPart_000_0007_01C28997.B8471B50--


From yoichi_yuasa@montavista.co.jp Tue Nov 12 08:48:10 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Nov 2002 08:48:11 +0100 (CET)
Received: from r-bu.iij4u.or.jp ([210.130.0.89]:46570 "EHLO r-bu.iij4u.or.jp")
	by linux-mips.org with ESMTP id <S1122037AbSKLHsJ>;
	Tue, 12 Nov 2002 08:48:09 +0100
Received: from pudding ([202.216.29.50])
	by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id gAC7lwq06883;
	Tue, 12 Nov 2002 16:47:59 +0900 (JST)
Date: Tue, 12 Nov 2002 16:44:33 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Patch for vrc4173(companion chip for NEC VR41xx)
Message-Id: <20021112164433.32788ca8.yoichi_yuasa@montavista.co.jp>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Tue__12_Nov_2002_16:44:33_+0900_08211790"
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 622
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Tue__12_Nov_2002_16:44:33_+0900_08211790
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

I added support of NEC VRC4173.
VRC4173 is companion chip for NEC VR41xx series.

This patch is based on linux_2_4 tag cvs tree on ftp.linux-mips.org
Would you apply this patch to CVS on ftp.linux-mips.org?

Best Regards,

Yoichi
--Multipart_Tue__12_Nov_2002_16:44:33_+0900_08211790
Content-Type: text/plain;
 name="vrc4173.diff"
Content-Disposition: attachment;
 filename="vrc4173.diff"
Content-Transfer-Encoding: 7bit

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	Mon Jul 15 09:02:56 2002
+++ linux/arch/mips/vr41xx/nec-eagle/Makefile	Wed Oct 30 20:10:37 2002
@@ -20,6 +20,6 @@
 obj-y	:= init.o irq.o setup.o
 
 obj-$(CONFIG_IDE)	+= ide-eagle.o
-obj-$(CONFIG_PCI)	+= pci_fixup.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/irq.c linux/arch/mips/vr41xx/nec-eagle/irq.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/irq.c	Mon Jul 15 09:02:56 2002
+++ linux/arch/mips/vr41xx/nec-eagle/irq.c	Wed Oct 30 19:48:00 2002
@@ -164,9 +164,6 @@
 	writeb(0, NEC_EAGLE_SDBINTMSK);
 	writeb(0, NEC_EAGLE_PCIINTMSKREG);
 
-	vr41xx_set_irq_trigger(VRC4173_PIN, TRIGGER_LEVEL, SIGNAL_THROUGH);
-	vr41xx_set_irq_level(VRC4173_PIN, LEVEL_LOW);
-
 	vr41xx_set_irq_trigger(PCISLOT_PIN, TRIGGER_LEVEL, SIGNAL_THROUGH);
 	vr41xx_set_irq_level(PCISLOT_PIN, LEVEL_HIGH);
 
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/pci_fixup.c linux/arch/mips/vr41xx/nec-eagle/pci_fixup.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/pci_fixup.c	Fri Oct  4 10:50:26 2002
+++ linux/arch/mips/vr41xx/nec-eagle/pci_fixup.c	Thu Oct 31 11:05:22 2002
@@ -47,9 +47,7 @@
 #include <linux/pci.h>
 
 #include <asm/vr41xx/eagle.h>
-#ifdef CONFIG_VRC4173
 #include <asm/vr41xx/vrc4173.h>
-#endif
 
 void __init pcibios_fixup_resources(struct pci_dev *dev)
 {
@@ -119,20 +117,12 @@
 				break;
 			}
 			break;
-#ifdef CONFIG_VRC4173
 		case 12:
-			dev->irq = VRC4173_CARDU1_IRQ;
+			dev->irq = VRC4173_PCMCIA1_IRQ;
 			break;
 		case 13:
-			dev->irq = VRC4173_CARDU2_IRQ;
+			dev->irq = VRC4173_PCMCIA2_IRQ;
 			break;
-		case 24:
-			dev->irq = VRC4173_CARDU1_IRQ;
-			break;
-		case 25:
-			dev->irq = VRC4173_CARDU2_IRQ;
-			break;
-#endif
 		case 28:
 			dev->irq = LANINTA_IRQ;
 			break;
@@ -152,21 +142,19 @@
 				break;
 			}
 			break;
-#ifdef CONFIG_VRC4173
 		case 30:
 			switch (func) {
 			case 0:
-				dev->irq = VRC4173_IRQ;
+				dev->irq = VRC4173_CASCADE_IRQ;
 				break;
 			case 1:
-				dev->irq = VRC4173_AC97U_IRQ;
+				dev->irq = VRC4173_AC97_IRQ;
 				break;
 			case 2:
-				dev->irq = VRC4173_USBU_IRQ;
+				dev->irq = VRC4173_USB_IRQ;
 				break;
 			}
 			break;
-#endif
 		}
 
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
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	Mon Jul 15 09:02:56 2002
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Wed Oct 30 20:08:38 2002
@@ -150,7 +150,5 @@
 	vr41xx_pciu_init(&pci_address_map);
 #endif
 
-#ifdef CONFIG_VRC4173
-	vrc4173_init();
-#endif
+	vrc4173_pre_init();
 }
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/nec-eagle/vrc4173.c linux/arch/mips/vr41xx/nec-eagle/vrc4173.c
--- linux.orig/arch/mips/vr41xx/nec-eagle/vrc4173.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/nec-eagle/vrc4173.c	Thu Oct 31 11:29:49 2002
@@ -0,0 +1,118 @@
+/*
+ * FILE NAME
+ *	arch/mips/vr41xx/nec-eagle/vrc4173.c
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Pre-setup for NEC VRC4173.
+ *
+ * Author: Yoichi Yuasa
+ *         yyuasa@mvista.com or source@mvista.com
+ *
+ * Copyright 2001,2002 MontaVista Software Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ *
+ *  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+ *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include <linux/config.h>
+
+#ifdef CONFIG_PCI
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/module.h>
+
+#include <asm/pci_channel.h>
+#include <asm/vr41xx/eagle.h>
+#include <asm/vr41xx/vrc4173.h>
+
+extern int early_read_config_byte(struct pci_channel *hose, int top_bus, int bus,
+                                  int devfn, int offset, u8 *val);
+extern int early_read_config_word(struct pci_channel *hose, int top_bus, int bus,
+                                  int devfn, int offset, u16 *val);
+extern int early_read_config_dword(struct pci_channel *hose, int top_bus, int bus,
+                                   int devfn, int offset, u32 *val);
+extern int early_write_config_byte(struct pci_channel *hose, int top_bus, int bus,
+                                   int devfn, int offset, u8 val);
+extern int early_write_config_word(struct pci_channel *hose, int top_bus, int bus,
+                                   int devfn, int offset, u16 val);
+extern int early_write_config_dword(struct pci_channel *hose, int top_bus, int bus,
+                                    int devfn, int offset, u32 val);
+
+void __init vrc4173_pre_init(void)
+{
+	struct pci_channel *hose;
+	int top_bus;
+	int current_bus;
+	u32 pci_devfn, cmdstat, base;
+	u16 vid, did, cmu_mask;
+
+	hose = mips_pci_channels;
+	top_bus = 0;
+	current_bus = 0;
+	for (pci_devfn = 0; pci_devfn < 0xff; pci_devfn++) {
+
+		early_read_config_word(hose, top_bus, current_bus, pci_devfn,
+		                       PCI_VENDOR_ID, &vid);
+		if (vid != PCI_VENDOR_ID_NEC)
+			continue;
+
+		early_read_config_word(hose, top_bus, current_bus, pci_devfn,
+		                       PCI_DEVICE_ID, &did);
+		if (did != 0x00a5)
+			continue;
+
+		/*
+		 * Initialized NEC VRC4173 Bus Control Unit
+		 */
+		early_read_config_dword(hose, top_bus, current_bus, pci_devfn,
+		                        PCI_COMMAND, &cmdstat);
+		early_write_config_dword(hose, top_bus, current_bus, pci_devfn,
+		                         PCI_COMMAND, cmdstat | PCI_COMMAND_IO |
+					 PCI_COMMAND_MEMORY |
+					 PCI_COMMAND_MASTER);
+		early_write_config_byte(hose, top_bus, current_bus, pci_devfn,
+		                        PCI_LATENCY_TIMER, 0x80);
+
+		early_write_config_dword(hose, top_bus, current_bus, pci_devfn,
+		                         PCI_BASE_ADDRESS_0, VR41XX_PCI_IO_START);
+
+		early_read_config_dword(hose, top_bus, current_bus, pci_devfn,
+		                        PCI_BASE_ADDRESS_0, &base);
+		base &= PCI_BASE_ADDRESS_IO_MASK;
+
+		early_write_config_byte(hose, top_bus, current_bus, pci_devfn,
+		                        0x40, 0x01);
+
+		/* CARDU1 IDSEL = AD12, CARDU2 IDSEL = AD13 */
+		early_write_config_byte(hose, top_bus, current_bus, pci_devfn, 0x41, 0);
+
+		cmu_mask = 0x1000;
+		outw(cmu_mask, base + 0x040);
+		cmu_mask |= 0x0800;
+		outw(cmu_mask, base + 0x040);
+
+		outw(0x000f, base + 0x042);	/* Soft reset of CMU */
+		cmu_mask |= 0x05e0;
+		outw(cmu_mask, base + 0x040);
+		cmu_mask = inw(base + 0x040);	/* dummy read */
+		outw(0x0000, base + 0x042);
+	}
+}
+
+#endif
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/victor-mpc30x/pci_fixup.c linux/arch/mips/vr41xx/victor-mpc30x/pci_fixup.c
--- linux.orig/arch/mips/vr41xx/victor-mpc30x/pci_fixup.c	Fri Oct  4 01:58:02 2002
+++ linux/arch/mips/vr41xx/victor-mpc30x/pci_fixup.c	Thu Oct 31 11:55:00 2002
@@ -17,6 +17,7 @@
 #include <linux/init.h>
 #include <linux/pci.h>
 
+#include <asm/vr41xx/vrc4173.h>
 #include <asm/vr41xx/mpc30x.h>
 
 void __init pcibios_fixup_resources(struct pci_dev *dev)
@@ -38,32 +39,28 @@
 		dev->irq = 0;
 
 		switch (slot) {
-#ifdef CONFIG_VRC4173
 		case 12:	/* NEC VRC4173 CARDU1 */
-			dev->irq = PCMCIA1_IRQ;
+			dev->irq = VRC4173_PCMCIA1_IRQ;
 			break;
 		case 13:	/* NEC VRC4173 CARDU2 */
-			dev->irq = PCMCIA2_IRQ;
+			dev->irq = VRC4173_PCMCIA2_IRQ;
 			break;
-#endif
 		case 29:	/* mediaQ MQ-200 */
 			dev->irq = MQ200_IRQ;
 			break;
-#ifdef CONFIG_VRC4173
 		case 30:
 			switch (func) {
 			case 0:	/* NEC VRC4173 */
 				dev->irq = VRC4173_CASCADE_IRQ;
 				break;
 			case 1:	/* NEC VRC4173 AC97U */
-				dev->irq = AC97_IRQ;
+				dev->irq = VRC4173_AC97_IRQ;
 				break;
 			case 2:	/* NEC VRC4173 USBU */
-				dev->irq = USB_IRQ;
+				dev->irq = VRC4173_USB_IRQ;
 				break;
 			}
 			break;
-#endif
 		}
 
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/char/Config.in linux/drivers/char/Config.in
--- linux.orig/drivers/char/Config.in	Tue Oct  8 12:40:10 2002
+++ linux/drivers/char/Config.in	Fri Nov  1 13:31:06 2002
@@ -302,4 +302,7 @@
 if [ "$CONFIG_MIPS_ITE8172" = "y" ]; then
   tristate ' ITE GPIO' CONFIG_ITE_GPIO
 fi
+if [ "$CONFIG_CPU_VR41XX" = "y" -a "$CONFIG_PCI" = "y" ]; then
+   tristate 'NEC VRC4173 Support' CONFIG_VRC4173
+fi
 endmenu
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/char/Makefile linux/drivers/char/Makefile
--- linux.orig/drivers/char/Makefile	Thu Sep 12 13:08:19 2002
+++ linux/drivers/char/Makefile	Fri Nov  1 13:35:39 2002
@@ -24,7 +24,7 @@
 export-objs     :=	busmouse.o console.o keyboard.o sysrq.o \
 			misc.o pty.o random.o selection.o serial.o \
 			sonypi.o tty_io.o tty_ioctl.o generic_serial.o \
-			au1000_gpio.o hp_psaux.o
+			au1000_gpio.o hp_psaux.o vrc4173.o
 
 mod-subdirs	:=	joystick ftape drm drm-4.0 pcmcia
 
@@ -158,6 +158,7 @@
 obj-$(CONFIG_SERIAL_SA1100) += serial_sa1100.o
 obj-$(CONFIG_SERIAL_AMBA) += serial_amba.o
 obj-$(CONFIG_TS_AU1000_ADS7846) += au1000_ts.o
+obj-$(CONFIG_VRC4173) += vrc4173.o
 
 ifndef CONFIG_SUN_KEYBOARD
   obj-$(CONFIG_VT) += keyboard.o $(KEYMAP) $(KEYBD)
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/drivers/char/vrc4173.c linux/drivers/char/vrc4173.c
--- linux.orig/drivers/char/vrc4173.c	Thu Jan  1 09:00:00 1970
+++ linux/drivers/char/vrc4173.c	Fri Nov  1 13:54:57 2002
@@ -0,0 +1,281 @@
+/*
+ * FILE NAME
+ *	drivers/char/vrc4173.c
+ * 
+ * BRIEF MODULE DESCRIPTION
+ *	NEC VRC4173 driver for NEC VR4122/VR4131.
+ *
+ * Author: Yoichi Yuasa
+ *         yyuasa@mvista.com or source@mvista.com
+ *
+ * Copyright 2001,2002 MontaVista Software Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ *
+ *  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+ *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/pci.h>
+#include <linux/types.h>
+
+#include <asm/vr41xx/vr41xx.h>
+#include <asm/vr41xx/vrc4173.h>
+
+MODULE_DESCRIPTION("NEC VRC4173 driver for NEC VR4122/4131");
+MODULE_AUTHOR("Yoichi Yuasa <yyuasa@mvista.com>");
+MODULE_LICENSE("GPL");
+
+#define PCI_DEVICE_ID_NEC_VRC4173	0x00a5
+
+#define VRC4173_CMUCLKMSK	0x040
+#define VRC4173_CMUSRST		0x042
+
+#define VRC4173_SELECTREG	0x09e
+
+#define VRC4173_SYSINT1REG	0x060
+#define VRC4173_MSYSINT1REG	0x06c
+
+static struct pci_device_id vrc4173_table[] __devinitdata = {
+	{PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_VRC4173, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{0, }
+};
+
+unsigned long vrc4173_io_port_base = 0;
+
+EXPORT_SYMBOL_GPL(vrc4173_io_port_base);
+
+static u16 vrc4173_cmuclkmsk;
+static int vrc4173_initialized;
+
+void vrc4173_clock_supply(u16 mask)
+{
+	if (vrc4173_initialized) {
+		vrc4173_cmuclkmsk |= mask;
+		vrc4173_outw(vrc4173_cmuclkmsk, VRC4173_CMUCLKMSK);
+	}
+}
+
+void vrc4173_clock_mask(u16 mask)
+{
+	if (vrc4173_initialized) {
+		vrc4173_cmuclkmsk &= ~mask;
+		vrc4173_outw(vrc4173_cmuclkmsk, VRC4173_CMUCLKMSK);
+	}
+}
+
+static inline void vrc4173_cmu_init(void)
+{
+	vrc4173_cmuclkmsk = vrc4173_inw(VRC4173_CMUCLKMSK);
+}
+
+EXPORT_SYMBOL_GPL(vrc4173_clock_supply);
+EXPORT_SYMBOL_GPL(vrc4173_clock_mask);
+
+void vrc4173_select_function(int func)
+{
+	u16 val;
+
+	if (vrc4173_initialized) {
+		val = vrc4173_inw(VRC4173_SELECTREG);
+		switch(func) {
+		case PS2CH1_SELECT:
+			val |= 0x0004;
+			break;
+		case PS2CH2_SELECT:
+			val |= 0x0002;
+			break;
+		case TOUCHPANEL_SELECT:
+			val &= 0x0007;
+			break;
+		case KIU8_SELECT:
+			val &= 0x000e;
+			break;
+		case KIU10_SELECT:
+			val &= 0x000c;
+			break;
+		case KIU12_SELECT:
+			val &= 0x0008;
+			break;
+		case GPIO_SELECT:
+			val |= 0x0008;
+			break;
+		}
+		vrc4173_outw(val, VRC4173_SELECTREG);
+	}
+}
+
+EXPORT_SYMBOL_GPL(vrc4173_select_function);
+
+static void enable_vrc4173_irq(unsigned int irq)
+{
+	u16 val;
+
+	val = vrc4173_inw(VRC4173_MSYSINT1REG);
+	val |= (u16)1 << (irq - VRC4173_IRQ_BASE);
+	vrc4173_outw(val, VRC4173_MSYSINT1REG);
+}
+
+static void disable_vrc4173_irq(unsigned int irq)
+{
+	u16 val;
+
+	val = vrc4173_inw(VRC4173_MSYSINT1REG);
+	val &= ~((u16)1 << (irq - VRC4173_IRQ_BASE));
+	vrc4173_outw(val, VRC4173_MSYSINT1REG);
+}
+
+static unsigned int startup_vrc4173_irq(unsigned int irq)
+{
+	enable_vrc4173_irq(irq);
+	return 0; /* never anything pending */
+}
+
+#define shutdown_vrc4173_irq	disable_vrc4173_irq
+#define ack_vrc4173_irq		disable_vrc4173_irq
+
+static void end_vrc4173_irq(unsigned int irq)
+{
+	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
+		enable_vrc4173_irq(irq);
+}
+
+static struct hw_interrupt_type vrc4173_irq_type = {
+	"VRC4173",
+	startup_vrc4173_irq,
+	shutdown_vrc4173_irq,
+	enable_vrc4173_irq,
+	disable_vrc4173_irq,
+	ack_vrc4173_irq,
+	end_vrc4173_irq,
+	NULL
+};
+
+static int vrc4173_get_irq_number(int irq)
+{
+	u16 status, mask;
+	int i;
+
+        status = vrc4173_inw(VRC4173_SYSINT1REG);
+        mask = vrc4173_inw(VRC4173_MSYSINT1REG);
+
+	status &= mask;
+	if (status) {
+		for (i = 0; i < 16; i++)
+			if (status & (0x0001 << i))
+				return VRC4173_IRQ_BASE + i;
+	}
+
+	return -EINVAL;
+}
+
+static inline void vrc4173_icu_init(int cascade_irq)
+{
+	int i;
+
+	if (cascade_irq < GIU_IRQ(0) || cascade_irq > GIU_IRQ(15))
+		return;
+	
+	vrc4173_outw(0, VRC4173_MSYSINT1REG);
+
+	vr41xx_set_irq_trigger(cascade_irq - GIU_IRQ(0), TRIGGER_LEVEL, SIGNAL_THROUGH);
+	vr41xx_set_irq_level(cascade_irq - GIU_IRQ(0), LEVEL_LOW);
+
+	for (i = VRC4173_IRQ_BASE; i <= VRC4173_IRQ_LAST; i++)
+                irq_desc[i].handler = &vrc4173_irq_type;
+}
+
+static int __devinit vrc4173_probe(struct pci_dev *pdev,
+                                   const struct pci_device_id *ent)
+{
+	unsigned long start, flags;
+	int err;
+
+	if ((err = pci_enable_device(pdev)) < 0) {
+		printk(KERN_ERR "vrc4173: failed to enable device -- err=%d\n", err);
+		return err;
+	}
+
+	pci_set_master(pdev);
+
+	start = pci_resource_start(pdev, 0);
+	if (!start) {
+		printk(KERN_ERR "vrc4173:No PCI I/O resources, aborting\n");
+		return -ENODEV;
+	}
+
+	if (!start || (((flags = pci_resource_flags(pdev, 0)) & IORESOURCE_IO) == 0)) {
+		printk(KERN_ERR "vrc4173: No PCI I/O resources, aborting\n");
+		return -ENODEV;
+	}
+
+	if ((err = pci_request_regions(pdev, "NEC VRC4173")) < 0) {
+		printk(KERN_ERR "vrc4173: PCI resources are busy, aborting\n");
+		return err;
+	}
+
+	set_vrc4173_io_port_base(start);
+
+	vrc4173_cmu_init();
+
+	vrc4173_icu_init(pdev->irq);
+
+	if ((err = vr41xx_cascade_irq(pdev->irq, vrc4173_get_irq_number)) < 0) {
+		printk(KERN_ERR
+		       "vrc4173: IRQ resource %d is busy, aborting\n", pdev->irq);
+		return err;
+	}
+
+	printk(KERN_INFO
+	       "NEC VRC4173 at 0x%#08lx, IRQ is cascaded to %d\n", start, pdev->irq);
+
+	return 0;
+}
+
+static struct pci_driver vrc4173_driver = {
+	name:		"NEC VRC4173",
+	probe:		vrc4173_probe,
+	remove:		NULL,
+	id_table:	vrc4173_table,
+};
+
+static int __devinit vrc4173_init(void)
+{
+	int err;
+
+	if ((err = pci_module_init(&vrc4173_driver)) < 0)
+		return err;
+
+	vrc4173_initialized = 1;
+
+	return 0;
+}
+
+static void __devexit vrc4173_exit(void)
+{
+	vrc4173_initialized = 0;
+
+	pci_unregister_driver(&vrc4173_driver);
+}
+
+module_init(vrc4173_init);
+module_exit(vrc4173_exit);
diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/include/asm-mips/vr41xx/vrc4173.h linux/include/asm-mips/vr41xx/vrc4173.h
--- linux.orig/include/asm-mips/vr41xx/vrc4173.h	Thu Jan  1 09:00:00 1970
+++ linux/include/asm-mips/vr41xx/vrc4173.h	Fri Nov  1 12:28:48 2002
@@ -0,0 +1,210 @@
+/*
+ * FILE NAME
+ *	include/asm-mips/vr41xx/vrc4173.h
+ *
+ * BRIEF MODULE DESCRIPTION
+ *	Include file for NEC VRC4173.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2000 by Michael R. McDonald
+ *
+ * Copyright 2001,2002 Montavista Software Inc.
+ * Author: Yoichi Yuasa
+ *         yyuasa@mvista.com or source@mvista.com
+ */
+#ifndef __NEC_VRC4173_H 
+#define __NEC_VRC4173_H 
+
+#include <asm/io.h>
+
+/*
+ * Interrupt Number
+ */
+#define VRC4173_IRQ_BASE	72
+#define VRC4173_USB_IRQ		(VRC4173_IRQ_BASE + 0)
+#define VRC4173_PCMCIA2_IRQ	(VRC4173_IRQ_BASE + 1)
+#define VRC4173_PCMCIA1_IRQ	(VRC4173_IRQ_BASE + 2)
+#define VRC4173_PS2CH2_IRQ	(VRC4173_IRQ_BASE + 3)
+#define VRC4173_PS2CH1_IRQ	(VRC4173_IRQ_BASE + 4)
+#define VRC4173_PIU_IRQ		(VRC4173_IRQ_BASE + 5)
+#define VRC4173_AIU_IRQ		(VRC4173_IRQ_BASE + 6)
+#define VRC4173_KIU_IRQ		(VRC4173_IRQ_BASE + 7)
+#define VRC4173_GIU_IRQ		(VRC4173_IRQ_BASE + 8)
+#define VRC4173_AC97_IRQ	(VRC4173_IRQ_BASE + 9)
+#define VRC4173_AC97INT1_IRQ	(VRC4173_IRQ_BASE + 10)
+#define VRC4173_DOZEPIU_IRQ	(VRC4173_IRQ_BASE + 13)
+#define VRC4173_IRQ_LAST	VRC4173_DOZEPIU_IRQ
+
+/*
+ * PCI I/O accesses
+ */
+extern unsigned long vrc4173_io_port_base;
+
+#define set_vrc4173_io_port_base(base)	\
+	do { vrc4173_io_port_base = mips_io_port_base + (base); } while (0)
+
+#define vrc4173_outb(val,port)							\
+do {										\
+	*(volatile u8 *)(vrc4173_io_port_base + (port)) = __ioswab8(val);	\
+} while(0)
+
+#define vrc4173_outw(val,port)							\
+do {										\
+	*(volatile u16 *)(vrc4173_io_port_base + (port)) = __ioswab16(val);	\
+} while(0)
+
+#define vrc4173_outl(val,port)							\
+do {										\
+	*(volatile u32 *)(vrc4173_io_port_base + (port)) = __ioswab32(val);	\
+} while(0)
+
+#define vrc4173_outb_p(val,port)						\
+do {										\
+	*(volatile u8 *)(vrc4173_io_port_base + (port)) = __ioswab8(val);	\
+	SLOW_DOWN_IO;								\
+} while(0)
+
+#define vrc4173_outw_p(val,port)						\
+do {										\
+	*(volatile u16 *)(vrc4173_io_port_base + (port)) = __ioswab16(val);	\
+	SLOW_DOWN_IO;								\
+} while(0)
+
+#define vrc4173_outl_p(val,port)						\
+do {										\
+	*(volatile u32 *)(vrc4173_io_port_base + (port)) = __ioswab32(val);	\
+	SLOW_DOWN_IO;								\
+} while(0)
+
+#define vrc4173_inb(port) __vrc4173_inb(port)
+#define vrc4173_inw(port) __vrc4173_inw(port)
+#define vrc4173_inl(port) __vrc4173_inl(port)
+#define vrc4173_inb_p(port) __vrc4173_inb_p(port)
+#define vrc4173_inw_p(port) __vrc4173_inw_p(port)
+#define vrc4173_inl_p(port) __vrc4173_inl_p(port)
+
+static inline unsigned char __vrc4173_inb(unsigned long port)
+{
+	return __ioswab8(*(volatile u8 *)(vrc4173_io_port_base + port));
+}
+
+static inline unsigned short __vrc4173_inw(unsigned long port)
+{
+	return __ioswab16(*(volatile u16 *)(vrc4173_io_port_base + port));
+}
+
+static inline unsigned int __vrc4173_inl(unsigned long port)
+{
+	return __ioswab32(*(volatile u32 *)(vrc4173_io_port_base + port));
+}
+
+static inline unsigned char __vrc4173_inb_p(unsigned long port)
+{
+ 	u8 __val;
+
+	__val = *(volatile u8 *)(vrc4173_io_port_base + (port));
+	SLOW_DOWN_IO;
+
+	return __ioswab8(__val);
+}
+
+static inline unsigned short __vrc4173_inw_p(unsigned long port)
+{
+ 	u16 __val;
+
+	__val = *(volatile u16 *)(vrc4173_io_port_base + (port));
+	SLOW_DOWN_IO;
+
+	return __ioswab16(__val);
+}
+
+static inline unsigned int __vrc4173_inl_p(unsigned long port)
+{
+ 	u32 __val;
+
+	__val = *(volatile u32 *)(vrc4173_io_port_base + (port));
+	SLOW_DOWN_IO;
+
+	return __ioswab32(__val);
+}
+
+#define vrc4173_outsb(port, addr, count) __vrc4173_outsb(port, addr, count)
+#define vrc4173_insb(port, addr, count) __vrc4173_insb(port, addr, count)
+#define vrc4173_outsw(port, addr, count) __vrc4173_outsw(port, addr, count)
+#define vrc4173_insw(port, addr, count) __vrc4173_insw(port, addr, count)
+#define vrc4173_outsl(port, addr, count) __vrc4173_outsl(port, addr, count)
+#define vrc4173_insl(port, addr, count) __vrc4173_insl(port, addr, count)
+
+static inline void __vrc4173_outsb(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		vrc4173_outb(*(u8 *)addr, port);
+		addr++;
+	}
+}
+
+static inline void __vrc4173_insb(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(u8 *)addr = vrc4173_inb(port);
+		addr++;
+	}
+}
+
+static inline void __vrc4173_outsw(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		vrc4173_outw(*(u16 *)addr, port);
+		addr += 2;
+	}
+}
+
+static inline void __vrc4173_insw(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(u16 *)addr = vrc4173_inw(port);
+		addr += 2;
+	}
+}
+
+static inline void __vrc4173_outsl(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		vrc4173_outl(*(u32 *)addr, port);
+		addr += 4;
+	}
+}
+
+static inline void __vrc4173_insl(unsigned long port, void *addr, unsigned int count)
+{
+	while (count--) {
+		*(u32 *)addr = vrc4173_inl(port);
+		addr += 4;
+	}
+}
+
+/*
+ * Clock Mask Unit
+ */
+extern void vrc4173_clock_supply(u16 mask);
+extern void vrc4173_clock_mask(u16 mask);
+
+/*
+ * Clock Mask Unit
+ */
+enum {
+	PS2CH1_SELECT,
+	PS2CH2_SELECT,
+	TOUCHPANEL_SELECT,
+	KIU8_SELECT,
+	KIU10_SELECT,
+	KIU12_SELECT,
+	GPIO_SELECT
+};
+
+extern void vrc4173_select_function(int func);
+
+#endif /* __NEC_VRC4173_H */


--Multipart_Tue__12_Nov_2002_16:44:33_+0900_08211790--

From yoichi_yuasa@montavista.co.jp Tue Nov 12 09:12:58 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Nov 2002 09:12:59 +0100 (CET)
Received: from r-bu.iij4u.or.jp ([210.130.0.89]:53745 "EHLO r-bu.iij4u.or.jp")
	by linux-mips.org with ESMTP id <S1122037AbSKLIM6>;
	Tue, 12 Nov 2002 09:12:58 +0100
Received: from pudding ([202.216.29.50])
	by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id gAC8Coq09081;
	Tue, 12 Nov 2002 17:12:50 +0900 (JST)
Date: Tue, 12 Nov 2002 17:09:25 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.5] PCI config read/write fixed for vr41xx
Message-Id: <20021112170925.7c7f5e2e.yoichi_yuasa@montavista.co.jp>
In-Reply-To: <20021108160109.38bbb072.yoichi_yuasa@montavista.co.jp>
References: <20021108160109.38bbb072.yoichi_yuasa@montavista.co.jp>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Tue__12_Nov_2002_17:09:25_+0900_0835b920"
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 623
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Tue__12_Nov_2002_17:09:25_+0900_0835b920
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Ralf,

Are there any problems in this patch?

On Fri, 8 Nov 2002 16:01:09 +0900
Yoichi Yuasa <yoichi_yuasa@montavista.co.jp> wrote:

> Hi Ralf,
> 
> I have fixed new PCI config read/write of vr41xx.
> Please apply this patch.

Thanks,

Yoichi
--Multipart_Tue__12_Nov_2002_17:09:25_+0900_0835b920
Content-Type: text/plain;
 name="vr41xx-021108.diff"
Content-Disposition: attachment;
 filename="vr41xx-021108.diff"
Content-Transfer-Encoding: 7bit

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/vr41xx/common/pciu.c linux/arch/mips/vr41xx/common/pciu.c
--- linux.orig/arch/mips/vr41xx/common/pciu.c	Mon Jul 15 08:47:57 2002
+++ linux/arch/mips/vr41xx/common/pciu.c	Fri Nov  8 14:39:56 2002
@@ -53,32 +53,28 @@
 
 extern unsigned long vr41xx_vtclock;
 
-static inline int vr41xx_pci_config_access(struct pci_dev *dev, int where)
+static inline int vr41xx_pci_config_access(unsigned char bus,  unsigned int devfn, int where)
 {
-	unsigned char bus = dev->bus->number;
-	unsigned int dev_fn = dev->devfn;
-
 	if (bus == 0) {
 		/*
 		 * Type 0 configuration
 		 */
-		if (PCI_SLOT(dev_fn) < 11 || PCI_SLOT(dev_fn) > 31 || where > 255)
+		if (PCI_SLOT(devfn) < 11 || where > 255)
 			return -1;
 
-		writel((1UL << PCI_SLOT(dev_fn))|
-		       (PCI_FUNC(dev_fn) << 8)	|
+		writel((1UL << PCI_SLOT(devfn))	|
+		       (PCI_FUNC(devfn) << 8)	|
 		       (where & 0xfc),
 		       PCICONFAREG);
-	}
-	else {
+	} else {
 		/*
 		 * Type 1 configuration
 		 */
-		if (bus > 255 || PCI_SLOT(dev_fn) > 31 || where > 255)
+		if (where > 255)
 			return -1;
 
 		writel((bus << 16)	|
-		       (dev_fn << 8)	|
+		       (devfn << 8)	|
 		       (where & 0xfc)	|
 		       1UL,
 		       PCICONFAREG);
@@ -87,110 +83,69 @@
 	return 0;
 }
 
-static int vr41xx_pci_read_config_byte(struct pci_dev *dev, int where, u8 *val)
-{
-	u32 data;
-
-	*val = 0xff;
-	if (vr41xx_pci_config_access(dev, where) < 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
-
-	data = readl(PCICONFDREG);
-	*val = (u8)(data >> ((where & 3) << 3));
-
-	return PCIBIOS_SUCCESSFUL;
-
-}
-
-static int vr41xx_pci_read_config_word(struct pci_dev *dev, int where, u16 *val)
+static int vr41xx_pci_config_read(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val)
 {
 	u32 data;
 
-	*val = 0xffff;
-	if (where & 1)
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	if (vr41xx_pci_config_access(dev, where) < 0)
+	*val = 0xffffffffUL;
+	if (vr41xx_pci_config_access(bus->number, devfn, where) < 0)
 		return PCIBIOS_DEVICE_NOT_FOUND;
 
 	data = readl(PCICONFDREG);
-	*val = (u16)(data >> ((where & 2) << 3));
-
-	return PCIBIOS_SUCCESSFUL;
-}
 
-static int vr41xx_pci_read_config_dword(struct pci_dev *dev, int where, u32 *val)
-{
-	*val = 0xffffffff;
-	if (where & 3)
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	if (vr41xx_pci_config_access(dev, where) < 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
-
-	*val = readl(PCICONFDREG);
+	switch (size) {
+	case 1:
+		*val = (data >> ((where & 3) << 3)) & 0xffUL;
+		break;
+	case 2:
+		*val = (data >> ((where & 2) << 3)) & 0xffffUL;
+		break;
+	case 4:
+		*val = data;
+		break;
+	default:
+		return PCIBIOS_FUNC_NOT_SUPPORTED;
+	}
 
 	return PCIBIOS_SUCCESSFUL;
 }
 
-static int vr41xx_pci_write_config_byte(struct pci_dev *dev, int where, u8 val)
+static int vr41xx_pci_config_write(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val)
 {
 	u32 data;
 	int shift;
 
-	if (vr41xx_pci_config_access(dev, where) < 0)
+	if (vr41xx_pci_config_access(bus->number, devfn, where) < 0)
 		return PCIBIOS_DEVICE_NOT_FOUND;
 
 	data = readl(PCICONFDREG);
-	shift = (where & 3) << 3;
-	data &= ~(0xff << shift);
-	data |= (((u32)val) << shift);
 
-	writel(data, PCICONFDREG);
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-static int vr41xx_pci_write_config_word(struct pci_dev *dev, int where, u16 val)
-{
-	u32 data;
-	int shift;
-
-	if (where & 1)
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	if (vr41xx_pci_config_access(dev, where) < 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
+	switch (size) {
+	case 1:
+		shift = (where & 3) << 3;
+		data &= ~(0xff << shift);
+		data |= ((val & 0xff) << shift);
+		break;
+	case 2:
+		shift = (where & 2) << 3;
+		data &= ~(0xffff << shift);
+		data |= ((val & 0xffff) << shift);
+		break;
+	case 4:
+		data = val;
+		break;
+	default:
+		return PCIBIOS_FUNC_NOT_SUPPORTED;
+	}
 
-	data = readl(PCICONFDREG);
-	shift = (where & 2) << 3;
-	data &= ~(0xffff << shift);
-	data |= (((u32)val) << shift);
 	writel(data, PCICONFDREG);
 
 	return PCIBIOS_SUCCESSFUL;
 }
 
-static int vr41xx_pci_write_config_dword(struct pci_dev *dev, int where, u32 val)
-{
-	if (where & 3)
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	if (vr41xx_pci_config_access(dev, where) < 0)
-		return PCIBIOS_DEVICE_NOT_FOUND;
-
-	writel(val, PCICONFDREG);
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
 struct pci_ops vr41xx_pci_ops = {
-	vr41xx_pci_read_config_byte,
-	vr41xx_pci_read_config_word,
-	vr41xx_pci_read_config_dword,
-	vr41xx_pci_write_config_byte,
-	vr41xx_pci_write_config_word,
-	vr41xx_pci_write_config_dword
+	.read	= vr41xx_pci_config_read,
+	.write	= vr41xx_pci_config_write,
 };
 
 void __init vr41xx_pciu_init(struct vr41xx_pci_address_map *map)


--Multipart_Tue__12_Nov_2002_17:09:25_+0900_0835b920--

From atulsrivastava9@rediffmail.com Tue Nov 12 14:23:18 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Nov 2002 14:23:18 +0100 (CET)
Received: from webmail24.rediffmail.com ([203.199.83.146]:55941 "HELO
	webmail24.rediffmail.com") by linux-mips.org with SMTP
	id <S1123961AbSKLNXS>; Tue, 12 Nov 2002 14:23:18 +0100
Received: (qmail 22771 invoked by uid 510); 12 Nov 2002 13:22:57 -0000
Date: 12 Nov 2002 13:22:57 -0000
Message-ID: <20021112132257.22770.qmail@webmail24.rediffmail.com>
Received: from unknown (203.197.184.16) by rediffmail.com via HTTP; 12 Nov 2002 13:22:57 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: problem with big endian binutils..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 624
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Have anybody confirmed stability of binutils for big endian 
mips?
while little endian gives me no problem
but i am simply unable to make a working big endian ramdisk.

specific problem is in identifying the e_type and e_machine fields 
in elf header of executables.
expected value of e_type is 0x2(ET_EXEC) amd e_machine is 
0x8(EM_MIPS)
but those are read as 0x200 and 0x800 respectivly ..this is 
obviously the endianness problem.

I have tried big endian ramdisk from 
ftp://ftp.ltc.com/pub/linux/mips/ramdisk/ramdisk
and also tried compiling one using uclibc package , both
failed because of same reason.

when i run file command on those executables after mounting the 
ramdisk on my host i get o/p like

ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, 
version 1, statically linked, stripped

though i see lot of mails regarding "invalid byteorder" but I 
didn't find specific suggestions.

if somebody has experienced similar problems , pls. give me 
guidance.

Best Regards,
Atul


__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/


From atulsrivastava9@rediffmail.com Tue Nov 12 14:25:34 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Nov 2002 14:25:34 +0100 (CET)
Received: from webmail34.rediffmail.com ([203.199.83.247]:11651 "HELO
	mailweb34.rediffmail.com") by linux-mips.org with SMTP
	id <S1123960AbSKLNZe>; Tue, 12 Nov 2002 14:25:34 +0100
Received: (qmail 31138 invoked by uid 510); 12 Nov 2002 13:25:12 -0000
Date: 12 Nov 2002 13:25:12 -0000
Message-ID: <20021112132512.31137.qmail@mailweb34.rediffmail.com>
Received: from unknown (203.197.184.16) by rediffmail.com via HTTP; 12 Nov 2002 13:25:12 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: problem with big endian binutils..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 625
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Have anybody confirmed stability of binutils for big endian 
mips?
while little endian gives me no problem
but i am simply unable to make a working big endian ramdisk.

specific problem is in identifying the e_type and e_machine fields 
in elf header of executables.
expected value of e_type is 0x2(ET_EXEC) amd e_machine is 
0x8(EM_MIPS)
but those are read as 0x200 and 0x800 respectivly ..this is 
obviously the endianness problem.

I have tried big endian ramdisk from 
ftp://ftp.ltc.com/pub/linux/mips/ramdisk/ramdisk
and also tried compiling one using uclibc package , both
failed because of same reason.

when i run file command on those executables after mounting the 
ramdisk on my host i get o/p like

ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, 
version 1, statically linked, stripped

though i see lot of mails regarding "invalid byteorder" but I 
didn't find specific suggestions.

if somebody has experienced similar problems , pls. give me 
guidance.

Best Regards,
Atul


__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/


From drow@false.org Tue Nov 12 17:22:15 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Nov 2002 17:22:16 +0100 (CET)
Received: from crack.them.org ([65.125.64.184]:41743 "EHLO crack.them.org")
	by linux-mips.org with ESMTP id <S1123923AbSKLQWP>;
	Tue, 12 Nov 2002 17:22:15 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 18Bfg3-0001iA-00; Tue, 12 Nov 2002 12:22:19 -0600
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 18Bdok-0000mP-00; Tue, 12 Nov 2002 11:23:10 -0500
Date: Tue, 12 Nov 2002 11:23:10 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: problem with big endian binutils..?
Message-ID: <20021112162310.GA2934@nevyn.them.org>
References: <20021112132512.31137.qmail@mailweb34.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021112132512.31137.qmail@mailweb34.rediffmail.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: 626
X-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, Nov 12, 2002 at 01:25:12PM -0000, atul srivastava wrote:
> Have anybody confirmed stability of binutils for big endian 
> mips?
> while little endian gives me no problem
> but i am simply unable to make a working big endian ramdisk.
> 
> specific problem is in identifying the e_type and e_machine fields 
> in elf header of executables.
> expected value of e_type is 0x2(ET_EXEC) amd e_machine is 
> 0x8(EM_MIPS)
> but those are read as 0x200 and 0x800 respectivly ..this is 
> obviously the endianness problem.

Binutils is just fine.  This is a problem with whatever's reading them.

> I have tried big endian ramdisk from 
> ftp://ftp.ltc.com/pub/linux/mips/ramdisk/ramdisk
> and also tried compiling one using uclibc package , both
> failed because of same reason.
> 
> when i run file command on those executables after mounting the 
> ramdisk on my host i get o/p like
> 
> ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, 
> version 1, statically linked, stripped
> 
> though i see lot of mails regarding "invalid byteorder" but I 
> didn't find specific suggestions.

It's normal.  The 'file' output is outdated.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.org Tue Nov 12 18:49:49 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Nov 2002 18:49:50 +0100 (CET)
Received: from p508B764F.dip.t-dialin.net ([80.139.118.79]:18566 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1123923AbSKLRtt>; Tue, 12 Nov 2002 18:49:49 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gACHmCR26127;
	Tue, 12 Nov 2002 18:48:12 +0100
Date: Tue, 12 Nov 2002 18:48:12 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: problem with big endian binutils..?
Message-ID: <20021112184811.A1972@linux-mips.org>
References: <20021112132257.22770.qmail@webmail24.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021112132257.22770.qmail@webmail24.rediffmail.com>; from atulsrivastava9@rediffmail.com on Tue, Nov 12, 2002 at 01:22:57PM -0000
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: 627
X-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, Nov 12, 2002 at 01:22:57PM -0000, atul srivastava wrote:

> Have anybody confirmed stability of binutils for big endian 
> mips?
> while little endian gives me no problem
> but i am simply unable to make a working big endian ramdisk.
> 
> specific problem is in identifying the e_type and e_machine fields 
> in elf header of executables.
> expected value of e_type is 0x2(ET_EXEC) amd e_machine is 
> 0x8(EM_MIPS)
> but those are read as 0x200 and 0x800 respectivly ..this is 
> obviously the endianness problem.

Possibly a problem in your reader.  Are you using od to look at the
header?  Od is dumping in the byteorder of the machine it's running on.

> I have tried big endian ramdisk from 
> ftp://ftp.ltc.com/pub/linux/mips/ramdisk/ramdisk
> and also tried compiling one using uclibc package , both
> failed because of same reason.
> 
> when i run file command on those executables after mounting the 
> ramdisk on my host i get o/p like
> 
> ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, 
> version 1, statically linked, stripped

The error message you're seeing simply means byte 5 of the ELF file is
zero that is unset that is not specifying any endianess.

> though i see lot of mails regarding "invalid byteorder" but I 
> didn't find specific suggestions.

It's a tool bug but a fairly harmless one.

  Ralf

From rbalsi@yahoo.com Tue Nov 12 23:25:06 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Nov 2002 23:25:07 +0100 (CET)
Received: from web40301.mail.yahoo.com ([66.218.78.80]:41592 "HELO
	web40301.mail.yahoo.com") by linux-mips.org with SMTP
	id <S1123923AbSKLWZG>; Tue, 12 Nov 2002 23:25:06 +0100
Message-ID: <20021112222458.90574.qmail@web40301.mail.yahoo.com>
Received: from [63.194.140.131] by web40301.mail.yahoo.com via HTTP; Tue, 12 Nov 2002 14:24:58 PST
Date: Tue, 12 Nov 2002 14:24:58 -0800 (PST)
From: Balaji R <rbalsi@yahoo.com>
Subject: uClinux port for MIPS
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rbalsi@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: 628
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rbalsi@yahoo.com
Precedence: bulk
X-list: linux-mips

Hello Guys,

I just want to know if there is uClinux/linux port
available for mmu less MIPS core.
we have a mips core without mmu and I'm thinking of
booting linux OS on it.
Thanks for your help.
 
Best Regards,
Balaji Ramalingam

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2

From carstenl@mips.com Wed Nov 13 14:35:06 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Nov 2002 14:35:07 +0100 (CET)
Received: from ftp.mips.com ([206.31.31.227]:26552 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1123923AbSKMNfG>;
	Wed, 13 Nov 2002 14:35:06 +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 gADDYoNf010995;
	Wed, 13 Nov 2002 05:34:50 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id FAA26010;
	Wed, 13 Nov 2002 05:34:49 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id gADDYmb21456;
	Wed, 13 Nov 2002 14:34:48 +0100 (MET)
Message-ID: <3DD254F8.14DE20EA@mips.com>
Date: Wed, 13 Nov 2002 14:34:48 +0100
From: Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	tsbogend@alpha.franken.de, linux-net@vger.kernel.org,
	kevink@mips.com
Subject: BUG in the PCNET32 ethernet driver
Content-Type: multipart/mixed;
 boundary="------------BB5442445461BE92A539EC42"
Return-Path: <carstenl@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: 629
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: carstenl@mips.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.
--------------BB5442445461BE92A539EC42
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

I finally found the problem that caused a lot of problem with an
ethernet throughput test, that we have been running.
It turned out the problem is related to a bug in the PCNET32 driver,
when you are running it on a system that doesn't support hardware
coherency.

The problem is the way the AMD ethernet driver is using the PCI DMA
mapping routines.
When the driver releases a receive DMA buffer to the controller for
later DMA transfer it call the PCI DMA flushing routine as it should,
but it calls it with a length equal to 0. The driver is assuming that
the length field in the buffer structure is equal to the actual length
of the buffer, but this field is first updated when we are receiving the
packet (and call the skb_put function).

I have attached a patch, that solve this problem.
Please note that the patch is against Ralf Baechle latest linux_2_4
tree.

/Carsten



--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com



--------------BB5442445461BE92A539EC42
Content-Type: text/plain; charset=iso-8859-15;
 name="pcnet32.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pcnet32.patch"

Index: drivers/net/pcnet32.c
===================================================================
RCS file: /home/cvs/linux/drivers/net/pcnet32.c,v
retrieving revision 1.33.2.3
diff -u -r1.33.2.3 pcnet32.c
--- drivers/net/pcnet32.c	6 Oct 2002 20:49:43 -0000	1.33.2.3
+++ drivers/net/pcnet32.c	13 Nov 2002 13:32:09 -0000
@@ -981,7 +981,7 @@
 	    }
 	    skb_reserve (rx_skbuff, 2);
 	}
-        lp->rx_dma_addr[i] = pci_map_single(lp->pci_dev, rx_skbuff->tail, rx_skbuff->len, PCI_DMA_FROMDEVICE);
+        lp->rx_dma_addr[i] = pci_map_single(lp->pci_dev, rx_skbuff->tail, PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
 	lp->rx_ring[i].base = (u32)le32_to_cpu(lp->rx_dma_addr[i]);
 	lp->rx_ring[i].buf_length = le16_to_cpu(-PKT_BUF_SZ);
 	lp->rx_ring[i].status = le16_to_cpu(0x8000);
@@ -1316,13 +1316,13 @@
 		    if ((newskb = dev_alloc_skb (PKT_BUF_SZ))) {
 			skb_reserve (newskb, 2);
 			skb = lp->rx_skbuff[entry];
-			pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], skb->len, PCI_DMA_FROMDEVICE);
+			pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], pkt_len +2, PCI_DMA_FROMDEVICE);
 			skb_put (skb, pkt_len);
 			lp->rx_skbuff[entry] = newskb;
 			newskb->dev = dev;
                         lp->rx_dma_addr[entry] = 
 				pci_map_single(lp->pci_dev, newskb->tail,
-					newskb->len, PCI_DMA_FROMDEVICE);
+					PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
 			lp->rx_ring[entry].base = le32_to_cpu(lp->rx_dma_addr[entry]);
 			rx_in_place = 1;
 		    } else
@@ -1349,13 +1349,10 @@
 		if (!rx_in_place) {
 		    skb_reserve(skb,2); /* 16 byte align */
 		    skb_put(skb,pkt_len);	/* Make room */
-                    pci_dma_sync_single(lp->pci_dev, 
-				    lp->rx_dma_addr[entry],
-				    pkt_len,
-				    PCI_DMA_FROMDEVICE);
 		    eth_copy_and_sum(skb,
 				     (unsigned char *)(lp->rx_skbuff[entry]->tail),
 				     pkt_len,0);
+		    lp->rx_dma_addr[entry] = pci_map_single(lp->pci_dev, lp->rx_skbuff[entry]->tail, PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
 		}
 		lp->stats.rx_bytes += skb->len;
 		skb->protocol=eth_type_trans(skb,dev);

--------------BB5442445461BE92A539EC42--


From jgarzik@pobox.com Wed Nov 13 17:43:17 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Nov 2002 17:43:18 +0100 (CET)
Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:23312 "EHLO
	www.linux.org.uk") by linux-mips.org with ESMTP id <S1123954AbSKMQnR>;
	Wed, 13 Nov 2002 17:43:17 +0100
Received: from nat-pool-rdu.redhat.com ([66.187.233.200] helo=pobox.com)
	by www.linux.org.uk with esmtp (Exim 3.33 #5)
	id 18C0ba-0007Dy-00; Wed, 13 Nov 2002 16:43:06 +0000
Message-ID: <3DD280FB.7070907@pobox.com>
Date: Wed, 13 Nov 2002 11:42:35 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Carsten Langgaard <carstenl@mips.com>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	tsbogend@alpha.franken.de, linux-net@vger.kernel.org,
	kevink@mips.com
Subject: Re: BUG in the PCNET32 ethernet driver
References: <3DD254F8.14DE20EA@mips.com>
In-Reply-To: <3DD254F8.14DE20EA@mips.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <jgarzik@pobox.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: 630
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: linux-mips

Carsten Langgaard wrote:

> @@ -1316,13 +1316,13 @@
>  		    if ((newskb = dev_alloc_skb (PKT_BUF_SZ))) {
>  			skb_reserve (newskb, 2);
>  			skb = lp->rx_skbuff[entry];
> -			pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], skb->len, 
> PCI_DMA_FROMDEVICE);
> +			pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], pkt_len +2, 
> PCI_DMA_FROMDEVICE);
>  			skb_put (skb, pkt_len);
>  			lp->rx_skbuff[entry] = newskb;


Why does this line not reference PKT_BUF_SZ when all the others do?


From daizenstros@quicklogic.com Wed Nov 13 20:26:33 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Nov 2002 20:26:34 +0100 (CET)
Received: from host-65-122-203-2.quicklogic.com ([65.122.203.2]:18169 "HELO
	quicklogic.com") by linux-mips.org with SMTP id <S1123954AbSKMT0d> convert rfc822-to-8bit;
	Wed, 13 Nov 2002 20:26:33 +0100
Received: from qldomain-Message_Server by quicklogic.com
	with Novell_GroupWise; Wed, 13 Nov 2002 11:39:24 -0800
Message-Id: <sdd239ec.049@quicklogic.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.6.1
Date: Wed, 13 Nov 2002 11:39:08 -0800
From: "Dan Aizenstros" <daizenstros@quicklogic.com>
To: <linux-mips@linux-mips.org>
Subject: Problem build kernel version 2.5.47
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <daizenstros@quicklogic.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: 631
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: daizenstros@quicklogic.com
Precedence: bulk
X-list: linux-mips

Hello All,

I am having a problem building the latest version
of the kernel. Below are the last lines seen during
the build.

make -f scripts/Makefile.build obj=drivers/char
  mipsel-linux-gcc -Wp,-MD,drivers/char/.consolemap.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -I /home/dan/devel/linux-2.5.x/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r5000 -mips2 -Wa,--trap -nostdinc -iwithprefix include    -DKBUILD_BASENAME=consolemap   -c -o drivers/char/consolemap.o drivers/char/consolemap.c
make[1]: *** [drivers/char] Segmentation fault (core dumped)
make: *** [drivers] Error 2

The consolemap.o is built so I think the problem is
happening when consolemap_deftbl.o is being built.

I am using gcc version 3.2 and binutils 2.13.

Has any one else seen this problem?

-- Dan A.

From carstenl@mips.com Wed Nov 13 21:09:16 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Nov 2002 21:09:16 +0100 (CET)
Received: from mx2.mips.com ([206.31.31.227]:32191 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1123954AbSKMUJQ>;
	Wed, 13 Nov 2002 21:09:16 +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 gADK8tNf012690;
	Wed, 13 Nov 2002 12:08:55 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA12791;
	Wed, 13 Nov 2002 12:08:47 -0800 (PST)
Received: from mips.com ([172.18.27.100])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id gADK8jb20525;
	Wed, 13 Nov 2002 21:08:45 +0100 (MET)
Message-ID: <3DD2B128.62DFB392@mips.com>
Date: Wed, 13 Nov 2002 21:08:08 +0100
From: Carsten Langgaard <carstenl@mips.com>
Organization: MIPS Technologies
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Garzik <jgarzik@pobox.com>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	tsbogend@alpha.franken.de, linux-net@vger.kernel.org,
	kevink@mips.com
Subject: Re: BUG in the PCNET32 ethernet driver
References: <3DD254F8.14DE20EA@mips.com> <3DD280FB.7070907@pobox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <carstenl@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: 632
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: carstenl@mips.com
Precedence: bulk
X-list: linux-mips

Jeff Garzik wrote:

> Carsten Langgaard wrote:
>
> > @@ -1316,13 +1316,13 @@
> >                   if ((newskb = dev_alloc_skb (PKT_BUF_SZ))) {
> >                       skb_reserve (newskb, 2);
> >                       skb = lp->rx_skbuff[entry];
> > -                     pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], skb->len,
> > PCI_DMA_FROMDEVICE);
> > +                     pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], pkt_len +2,
> > PCI_DMA_FROMDEVICE);
> >                       skb_put (skb, pkt_len);
> >                       lp->rx_skbuff[entry] = newskb;
>
> Why does this line not reference PKT_BUF_SZ when all the others do?

In this case we know the size of the packet and therefore only need to handle that.
In the other cases we don't know have big the receiving packet is going to be, so we has to
take care of the whole buffer.

/Carsten



From jgarzik@pobox.com Wed Nov 13 21:20:57 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Nov 2002 21:20:58 +0100 (CET)
Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:10507 "EHLO
	www.linux.org.uk") by linux-mips.org with ESMTP id <S1123954AbSKMUU5>;
	Wed, 13 Nov 2002 21:20:57 +0100
Received: from nat-pool-rdu.redhat.com ([66.187.233.200] helo=pobox.com)
	by www.linux.org.uk with esmtp (Exim 3.33 #5)
	id 18C40I-0003XA-00; Wed, 13 Nov 2002 20:20:50 +0000
Message-ID: <3DD2B402.8040508@pobox.com>
Date: Wed, 13 Nov 2002 15:20:18 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Carsten Langgaard <carstenl@mips.com>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	tsbogend@alpha.franken.de, linux-net@vger.kernel.org,
	kevink@mips.com
Subject: Re: BUG in the PCNET32 ethernet driver
References: <3DD254F8.14DE20EA@mips.com> <3DD280FB.7070907@pobox.com> <3DD2B128.62DFB392@mips.com>
In-Reply-To: <3DD254F8.14DE20EA@mips.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <jgarzik@pobox.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: 633
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: linux-mips

Carsten Langgaard wrote:

> Jeff Garzik wrote:
>
>
> >Carsten Langgaard wrote:
> >
> >
> >>@@ -1316,13 +1316,13 @@
> >>                  if ((newskb = dev_alloc_skb (PKT_BUF_SZ))) {
> >>                      skb_reserve (newskb, 2);
> >>                      skb = lp->rx_skbuff[entry];
> >>-                     pci_unmap_single(lp->pci_dev, 
> lp->rx_dma_addr[entry], skb->len,
> >>PCI_DMA_FROMDEVICE);
> >>+                     pci_unmap_single(lp->pci_dev, 
> lp->rx_dma_addr[entry], pkt_len +2,
> >>PCI_DMA_FROMDEVICE);
> >>                      skb_put (skb, pkt_len);
> >>                      lp->rx_skbuff[entry] = newskb;
> >
> >Why does this line not reference PKT_BUF_SZ when all the others do?
>
>
> In this case we know the size of the packet and therefore only need to 
> handle that.
> In the other cases we don't know have big the receiving packet is 
> going to be, so we has to
> take care of the whole buffer.



Well, it's a seriously bad idea to pass different values to map and 
unmap steps, because on some platforms you could wind up telling the 
IOMMU or some other allocator that you are allocating N bytes, but 
freeing N-M bytes.  IOW, a leak.

Now that that's been clarified, please fix up the patch and resubmit... 
  with this issue fixed, it looks apply-able.

	Jeff




From carstenl@mips.com Wed Nov 13 21:47:02 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Nov 2002 21:47:03 +0100 (CET)
Received: from mx2.mips.com ([206.31.31.227]:11456 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1123954AbSKMUrC>;
	Wed, 13 Nov 2002 21:47:02 +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 gADKkoNf012858;
	Wed, 13 Nov 2002 12:46:51 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA14450;
	Wed, 13 Nov 2002 12:46:50 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id gADKkob22973;
	Wed, 13 Nov 2002 21:46:50 +0100 (MET)
Message-ID: <3DD2BA39.E1457D67@mips.com>
Date: Wed, 13 Nov 2002 21:46:50 +0100
From: Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Garzik <jgarzik@pobox.com>
CC: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	tsbogend@alpha.franken.de, linux-net@vger.kernel.org,
	kevink@mips.com
Subject: Re: BUG in the PCNET32 ethernet driver
References: <3DD254F8.14DE20EA@mips.com> <3DD280FB.7070907@pobox.com> <3DD2B128.62DFB392@mips.com> <3DD2B402.8040508@pobox.com>
Content-Type: multipart/mixed;
 boundary="------------F6D4B5191D51956889E84897"
Return-Path: <carstenl@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: 634
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: carstenl@mips.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.
--------------F6D4B5191D51956889E84897
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

Jeff Garzik wrote:

> Carsten Langgaard wrote:
>
> > Jeff Garzik wrote:
> >
> >
> > >Carsten Langgaard wrote:
> > >
> > >
> > >>@@ -1316,13 +1316,13 @@
> > >>                  if ((newskb = dev_alloc_skb (PKT_BUF_SZ))) {
> > >>                      skb_reserve (newskb, 2);
> > >>                      skb = lp->rx_skbuff[entry];
> > >>-                     pci_unmap_single(lp->pci_dev,
> > lp->rx_dma_addr[entry], skb->len,
> > >>PCI_DMA_FROMDEVICE);
> > >>+                     pci_unmap_single(lp->pci_dev,
> > lp->rx_dma_addr[entry], pkt_len +2,
> > >>PCI_DMA_FROMDEVICE);
> > >>                      skb_put (skb, pkt_len);
> > >>                      lp->rx_skbuff[entry] = newskb;
> > >
> > >Why does this line not reference PKT_BUF_SZ when all the others do?
> >
> >
> > In this case we know the size of the packet and therefore only need to
> > handle that.
> > In the other cases we don't know have big the receiving packet is
> > going to be, so we has to
> > take care of the whole buffer.
>
> Well, it's a seriously bad idea to pass different values to map and
> unmap steps, because on some platforms you could wind up telling the
> IOMMU or some other allocator that you are allocating N bytes, but
> freeing N-M bytes.  IOW, a leak.

Ok, fine.
There is actually another place in the code that also need a fix then.


>
> Now that that's been clarified, please fix up the patch and resubmit...
>   with this issue fixed, it looks apply-able.
>

I have made the change and attached a new patch.

>
>         Jeff

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com



--------------F6D4B5191D51956889E84897
Content-Type: text/plain; charset=iso-8859-15;
 name="pcnet32.2.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pcnet32.2.patch"

Index: drivers/net/pcnet32.c
===================================================================
RCS file: /home/cvs/linux/drivers/net/pcnet32.c,v
retrieving revision 1.33.2.3
diff -u -r1.33.2.3 pcnet32.c
--- drivers/net/pcnet32.c	6 Oct 2002 20:49:43 -0000	1.33.2.3
+++ drivers/net/pcnet32.c	13 Nov 2002 20:38:39 -0000
@@ -981,7 +981,7 @@
 	    }
 	    skb_reserve (rx_skbuff, 2);
 	}
-        lp->rx_dma_addr[i] = pci_map_single(lp->pci_dev, rx_skbuff->tail, rx_skbuff->len, PCI_DMA_FROMDEVICE);
+        lp->rx_dma_addr[i] = pci_map_single(lp->pci_dev, rx_skbuff->tail, PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
 	lp->rx_ring[i].base = (u32)le32_to_cpu(lp->rx_dma_addr[i]);
 	lp->rx_ring[i].buf_length = le16_to_cpu(-PKT_BUF_SZ);
 	lp->rx_ring[i].status = le16_to_cpu(0x8000);
@@ -1316,13 +1316,13 @@
 		    if ((newskb = dev_alloc_skb (PKT_BUF_SZ))) {
 			skb_reserve (newskb, 2);
 			skb = lp->rx_skbuff[entry];
-			pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], skb->len, PCI_DMA_FROMDEVICE);
+			pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
 			skb_put (skb, pkt_len);
 			lp->rx_skbuff[entry] = newskb;
 			newskb->dev = dev;
                         lp->rx_dma_addr[entry] = 
 				pci_map_single(lp->pci_dev, newskb->tail,
-					newskb->len, PCI_DMA_FROMDEVICE);
+					PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
 			lp->rx_ring[entry].base = le32_to_cpu(lp->rx_dma_addr[entry]);
 			rx_in_place = 1;
 		    } else
@@ -1349,13 +1349,10 @@
 		if (!rx_in_place) {
 		    skb_reserve(skb,2); /* 16 byte align */
 		    skb_put(skb,pkt_len);	/* Make room */
-                    pci_dma_sync_single(lp->pci_dev, 
-				    lp->rx_dma_addr[entry],
-				    pkt_len,
-				    PCI_DMA_FROMDEVICE);
 		    eth_copy_and_sum(skb,
 				     (unsigned char *)(lp->rx_skbuff[entry]->tail),
 				     pkt_len,0);
+		    lp->rx_dma_addr[entry] = pci_map_single(lp->pci_dev, lp->rx_skbuff[entry]->tail, PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
 		}
 		lp->stats.rx_bytes += skb->len;
 		skb->protocol=eth_type_trans(skb,dev);
@@ -1406,7 +1403,7 @@
     for (i = 0; i < RX_RING_SIZE; i++) {
 	lp->rx_ring[i].status = 0;			    
 	if (lp->rx_skbuff[i]) {
-            pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[i], lp->rx_skbuff[i]->len, PCI_DMA_FROMDEVICE);
+            pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[i], PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
 	    dev_kfree_skb(lp->rx_skbuff[i]);
         }
 	lp->rx_skbuff[i] = NULL;

--------------F6D4B5191D51956889E84897--


From lindahl@keyresearch.com Thu Nov 14 02:42:21 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 02:42:22 +0100 (CET)
Received: from nixon.xkey.com ([209.245.148.124]:44717 "HELO nixon.xkey.com")
	by linux-mips.org with SMTP id <S1124139AbSKNBmV>;
	Thu, 14 Nov 2002 02:42:21 +0100
Received: (qmail 4254 invoked from network); 14 Nov 2002 01:42:13 -0000
Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1)
  by localhost with SMTP; 14 Nov 2002 01:42:13 -0000
Received: (from lindahl@localhost)
	by localhost.conservativecomputer.com (8.11.6/8.11.0) id gAE1g0a02920
	for linux-mips@linux-mips.org; Wed, 13 Nov 2002 17:42:00 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Wed, 13 Nov 2002 17:42:00 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: explain to me how this works...
Message-ID: <20021113174200.A2874@wumpus.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20021005095335.B4079@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021005095335.B4079@lucon.org>; from hjl@lucon.org on Sat, Oct 05, 2002 at 09:53:35AM -0700
Return-Path: <lindahl@keyresearch.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: 635
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

I have a 64-bit kernel and O32 userland.

I notice that arping gets confused because the syscall socket() is
returning 4183 instead of a reasonable value like 3... if strace()
isn't lying to me.

How do I debug this? The O32 userland calls through the socketcall()
syscall. It looks OK.

greg



From bbozarth@cisco.com Thu Nov 14 03:11:54 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 03:11:55 +0100 (CET)
Received: from sj-msg-core-1.cisco.com ([171.71.163.11]:32420 "EHLO
	sj-msg-core-1.cisco.com") by linux-mips.org with ESMTP
	id <S1123954AbSKNCLy>; Thu, 14 Nov 2002 03:11:54 +0100
Received: from bbozarth-lnx.cisco.com (bbozarth-lnx.cisco.com [128.107.165.13])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAE2BlNf012070;
	Wed, 13 Nov 2002 18:11:47 -0800 (PST)
Received: from localhost (bbozarth@localhost)
	by bbozarth-lnx.cisco.com (8.11.6/8.11.6) with ESMTP id gAE2Blw11125;
	Wed, 13 Nov 2002 18:11:47 -0800
Date: Wed, 13 Nov 2002 18:11:47 -0800 (PST)
From: Bradley Bozarth <bbozarth@cisco.com>
To: linux-mips@linux-mips.org
cc: george@mvista.com
Subject: Re: SEGEV defines
In-Reply-To: <200211080914.KAA14181@pallas.spacetec.no>
Message-ID: <Pine.LNX.4.44.0211131742480.11387-100000@bbozarth-lnx.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <bbozarth@cisco.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: 636
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bbozarth@cisco.com
Precedence: bulk
X-list: linux-mips

This presents a problem that I just ran into.  What should the solution 
be?  Either glibc or the kernel needs to change as far as I can tell, in 
order for programs compiled against glibc and using these SIGEV defines to 
work w/ the mips kernel.  Is this file currently wrong?

glibc-2.3.1/sysdeps/unix/sysv/linux/mips/bits/siginfo.h

Would this patch fix it?

--- siginfo.h.orig	Wed Nov 13 18:04:58 2002
+++ siginfo.h	Wed Nov 13 18:11:15 2002
@@ -295,11 +295,11 @@
 /* `sigev_notify' values.  */
 enum
 {
-  SIGEV_SIGNAL = 0,		/* Notify via signal.  */
+  SIGEV_SIGNAL = 129,		/* Notify via signal.  */
 # define SIGEV_SIGNAL	SIGEV_SIGNAL
-  SIGEV_NONE,			/* Other notification: meaningless.  */
+  SIGEV_NONE = 128,		/* Other notification: meaningless.  */
 # define SIGEV_NONE	SIGEV_NONE
-  SIGEV_THREAD			/* Deliver via thread creation.  */
+  SIGEV_THREAD = 131		/* Deliver via thread creation.  */
 # define SIGEV_THREAD	SIGEV_THREAD
 };


On Fri, 8 Nov 2002, Tor Arntsen wrote:

> On Nov 7, 23:11, Daniel Jacobowitz wrote:
> >Presumably they match IRIX... like the rest of MIPS's oddball
> >definitions.  A little hard to change them now.
> 
> FWIW: You are correct, those values come from IRIX.
> 
> >On Thu, Nov 07, 2002 at 12:33:55PM -0800, Bradley Bozarth wrote:
> >> Can these be changed?
> >> 
> >> > Now a question, why does mips use these values:
> >> >  #define SIGEV_SIGNAL   129     /* notify via signal */
> >> >  #define SIGEV_CALLBACK 130     /* ??? */
> >> >  #define SIGEV_THREAD   131     /* deliver via thread
> >> > creation */
> >> >
> >> > It is the only platform that adds anything to the simple
> >> > 1,2,3 values used on other platforms.  The reason I ask, is
> >> > that I would like to change them to conform to all the
> >> > others.
> 


From davem@redhat.com Thu Nov 14 05:13:52 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 05:13:53 +0100 (CET)
Received: from pizda.ninka.net ([216.101.162.242]:11467 "EHLO pizda.ninka.net")
	by linux-mips.org with ESMTP id <S1122118AbSKNENw>;
	Thu, 14 Nov 2002 05:13:52 +0100
Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1])
	by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA10224;
	Wed, 13 Nov 2002 20:11:56 -0800
Date: Wed, 13 Nov 2002 20:11:55 -0800 (PST)
Message-Id: <20021113.201155.106013477.davem@redhat.com>
To: carstenl@mips.com
Cc: jgarzik@pobox.com, ralf@linux-mips.org, linux-mips@linux-mips.org,
	tsbogend@alpha.franken.de, linux-net@vger.kernel.org,
	kevink@mips.com
Subject: Re: BUG in the PCNET32 ethernet driver
From: "David S. Miller" <davem@redhat.com>
In-Reply-To: <3DD2B128.62DFB392@mips.com>
References: <3DD254F8.14DE20EA@mips.com>
	<3DD280FB.7070907@pobox.com>
	<3DD2B128.62DFB392@mips.com>
X-FalunGong: Information control.
X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <davem@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: 637
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: davem@redhat.com
Precedence: bulk
X-list: linux-mips

   From: Carsten Langgaard <carstenl@mips.com>
   Date: Wed, 13 Nov 2002 21:08:08 +0100

   Jeff Garzik wrote:
   
   > Why does this line not reference PKT_BUF_SZ when all the others do?
   
   In this case we know the size of the packet and therefore only need to handle that.
   In the other cases we don't know have big the receiving packet is going to be, so we has to
   take care of the whole buffer.

When you unmap a DMA buffer, which is a resource so this is just like
freeing memory, you must specify the exact size you used when creating
the mapping to begin with.

Franks a lot,
David S. Miller
davem@redhat.com

From ilya@gateway.total-knowledge.com Thu Nov 14 05:15:47 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 05:15:48 +0100 (CET)
Received: from 12-234-207-60.client.attbi.com ([12.234.207.60]:12430 "HELO
	gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S1122118AbSKNEPr>; Thu, 14 Nov 2002 05:15:47 +0100
Received: (qmail 10822 invoked by uid 502); 14 Nov 2002 04:15:39 -0000
Date: Wed, 13 Nov 2002 20:15:38 -0800
From: ilya@theIlya.com
To: linux-mips@linux-mips.org
Subject: Re: explain to me how this works...
Message-ID: <20021114041538.GB5986@gateway.total-knowledge.com>
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="v0AS7uCPPFvPHUfF"
Content-Disposition: inline
In-Reply-To: <20021113174200.A2874@wumpus.internal.keyresearch.com>
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: 638
X-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


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

see arch/mips64/kernel/linux32.c

On Wed, Nov 13, 2002 at 05:42:00PM -0800, Greg Lindahl wrote:
> I have a 64-bit kernel and O32 userland.
>=20
> I notice that arping gets confused because the syscall socket() is
> returning 4183 instead of a reasonable value like 3... if strace()
> isn't lying to me.
>=20
> How do I debug this? The O32 userland calls through the socketcall()
> syscall. It looks OK.
>=20
> greg
>=20
>=20
>=20

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

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

iD8DBQE90yNq84S94bALfyURAj5EAKDbPqxZXcEhLOjgLkxMv4zWmd3LSACdGimC
gBhrWAg9L8iMcRybNPWI2YY=
=cHNe
-----END PGP SIGNATURE-----

--v0AS7uCPPFvPHUfF--

From george@mvista.com Thu Nov 14 05:23:48 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 05:23:49 +0100 (CET)
Received: from gateway-1237.mvista.com ([12.44.186.158]:55286 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S1122118AbSKNEXs>;
	Thu, 14 Nov 2002 05:23:48 +0100
Received: from data.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id UAA16477;
	Wed, 13 Nov 2002 20:23:22 -0800
Received: from mvista.com (IDENT:george@localhost [127.0.0.1])
	by data.mvista.com (8.9.3/8.9.3) with ESMTP id UAA26412;
	Wed, 13 Nov 2002 20:23:10 -0800
Message-ID: <3DD3252E.8DB61CE6@mvista.com>
Date: Wed, 13 Nov 2002 20:23:10 -0800
From: george anzinger <george@mvista.com>
Organization: Monta Vista Software
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bradley Bozarth <bbozarth@cisco.com>
CC: linux-mips@linux-mips.org
Subject: Re: SEGEV defines
References: <Pine.LNX.4.44.0211131742480.11387-100000@bbozarth-lnx.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <george@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: 639
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: george@mvista.com
Precedence: bulk
X-list: linux-mips

Bradley Bozarth wrote:
> 
> This presents a problem that I just ran into.  What should the solution
> be?  Either glibc or the kernel needs to change as far as I can tell, in
> order for programs compiled against glibc and using these SIGEV defines to
> work w/ the mips kernel.  Is this file currently wrong?
> 
> glibc-2.3.1/sysdeps/unix/sysv/linux/mips/bits/siginfo.h
> 
> Would this patch fix it?
> 
> --- siginfo.h.orig      Wed Nov 13 18:04:58 2002
> +++ siginfo.h   Wed Nov 13 18:11:15 2002
> @@ -295,11 +295,11 @@
>  /* `sigev_notify' values.  */
>  enum
>  {
> -  SIGEV_SIGNAL = 0,            /* Notify via signal.  */
> +  SIGEV_SIGNAL = 129,          /* Notify via signal.  */
>  # define SIGEV_SIGNAL  SIGEV_SIGNAL
> -  SIGEV_NONE,                  /* Other notification: meaningless.  */
> +  SIGEV_NONE = 128,            /* Other notification: meaningless.  */
>  # define SIGEV_NONE    SIGEV_NONE
> -  SIGEV_THREAD                 /* Deliver via thread creation.  */
> +  SIGEV_THREAD = 131           /* Deliver via thread creation.  */
>  # define SIGEV_THREAD  SIGEV_THREAD
>  };

I MUCH prefer a change to the kernel if one or the other
needs to change.  The issue is, of course, IRIX
compatability and what that means.  This comes up because I
want to use the definitions in combination and the common
bit makes a mess of things.  Still, it would be NICE if it
matched the rest of the platforms.

-g

> 
> On Fri, 8 Nov 2002, Tor Arntsen wrote:
> 
> > On Nov 7, 23:11, Daniel Jacobowitz wrote:
> > >Presumably they match IRIX... like the rest of MIPS's oddball
> > >definitions.  A little hard to change them now.
> >
> > FWIW: You are correct, those values come from IRIX.
> >
> > >On Thu, Nov 07, 2002 at 12:33:55PM -0800, Bradley Bozarth wrote:
> > >> Can these be changed?
> > >>
> > >> > Now a question, why does mips use these values:
> > >> >  #define SIGEV_SIGNAL   129     /* notify via signal */
> > >> >  #define SIGEV_CALLBACK 130     /* ??? */
> > >> >  #define SIGEV_THREAD   131     /* deliver via thread
> > >> > creation */
> > >> >
> > >> > It is the only platform that adds anything to the simple
> > >> > 1,2,3 values used on other platforms.  The reason I ask, is
> > >> > that I would like to change them to conform to all the
> > >> > others.
> >

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

From ralf@linux-mips.org Thu Nov 14 05:52:17 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 05:52:17 +0100 (CET)
Received: from p508B6D85.dip.t-dialin.net ([80.139.109.133]:40345 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122118AbSKNEwR>; Thu, 14 Nov 2002 05:52:17 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAE4puF27101;
	Thu, 14 Nov 2002 05:51:56 +0100
Date: Thu, 14 Nov 2002 05:51:56 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: george anzinger <george@mvista.com>
Cc: Bradley Bozarth <bbozarth@cisco.com>, linux-mips@linux-mips.org
Subject: Re: SEGEV defines
Message-ID: <20021114055156.C24744@linux-mips.org>
References: <Pine.LNX.4.44.0211131742480.11387-100000@bbozarth-lnx.cisco.com> <3DD3252E.8DB61CE6@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DD3252E.8DB61CE6@mvista.com>; from george@mvista.com on Wed, Nov 13, 2002 at 08:23:10PM -0800
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: 640
X-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, Nov 13, 2002 at 08:23:10PM -0800, george anzinger wrote:

> I MUCH prefer a change to the kernel if one or the other
> needs to change.  The issue is, of course, IRIX
> compatability and what that means.  This comes up because I
> want to use the definitions in combination and the common
> bit makes a mess of things.  Still, it would be NICE if it
> matched the rest of the platforms.

The IRIX compatibility code seems unused and the constants aren't even
part of the ABI at all.  So in this case it indeed seems preferable to
change the kernel side.

Anybody disagrees?

  Ralf

From lindahl@keyresearch.com Thu Nov 14 17:11:14 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 17:11:15 +0100 (CET)
Received: from nixon.xkey.com ([209.245.148.124]:60353 "HELO nixon.xkey.com")
	by linux-mips.org with SMTP id <S1122121AbSKNQLO>;
	Thu, 14 Nov 2002 17:11:14 +0100
Received: (qmail 12988 invoked from network); 14 Nov 2002 16:10:57 -0000
Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1)
  by localhost with SMTP; 14 Nov 2002 16:10:57 -0000
Received: (from lindahl@localhost)
	by localhost.conservativecomputer.com (8.11.6/8.11.0) id gAEGAhY03183
	for linux-mips@linux-mips.org; Thu, 14 Nov 2002 08:10:43 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 14 Nov 2002 08:10:43 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: explain to me how this works...
Message-ID: <20021114081043.C2192@wumpus.attbi.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com> <20021114041538.GB5986@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021114041538.GB5986@gateway.total-knowledge.com>; from ilya@theIlya.com on Wed, Nov 13, 2002 at 08:15:38PM -0800
Return-Path: <lindahl@keyresearch.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: 641
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

I saw that a long time ago. sys_socket and sys_socketcall seem
to be written just like all the other syscalls that return an int.

> see arch/mips64/kernel/linux32.c
> 
> On Wed, Nov 13, 2002 at 05:42:00PM -0800, Greg Lindahl wrote:
> > I have a 64-bit kernel and O32 userland.
> > 
> > I notice that arping gets confused because the syscall socket() is
> > returning 4183 instead of a reasonable value like 3... if strace()
> > isn't lying to me.
> > 
> > How do I debug this? The O32 userland calls through the socketcall()
> > syscall. It looks OK.
> > 
> > greg
> > 
> > 
> > 



From ralf@linux-mips.org Thu Nov 14 19:39:34 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 19:39:34 +0100 (CET)
Received: from p508B6D85.dip.t-dialin.net ([80.139.109.133]:51615 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122118AbSKNSje>; Thu, 14 Nov 2002 19:39:34 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAEIdPP07993
	for linux-mips@linux-mips.org; Thu, 14 Nov 2002 19:39:25 +0100
Date: Thu, 14 Nov 2002 19:39:24 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: explain to me how this works...
Message-ID: <20021114193924.A5610@linux-mips.org>
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021113174200.A2874@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Wed, Nov 13, 2002 at 05:42:00PM -0800
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: 642
X-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, Nov 13, 2002 at 05:42:00PM -0800, Greg Lindahl wrote:

> I have a 64-bit kernel and O32 userland.
> 
> I notice that arping gets confused because the syscall socket() is
> returning 4183 instead of a reasonable value like 3... if strace()
> isn't lying to me.
> 
> How do I debug this? The O32 userland calls through the socketcall()
> syscall. It looks OK.

Eh?  Nothing on MIPS should use socketcall(2); we have all the calls like
socket(2), bind(2), connect(2) etc. directly in our syscall table unlike
x86 which uses this pointless wrapper for historical reasons.  We only
have socketcall(2) in the o32 syscall interface but it's a candidate for
removal as nothing we still do support and that's glibc 2.0 and higher
binaries uses it.

  Ralf

From ralf@linux-mips.org Thu Nov 14 19:48:09 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 19:48:09 +0100 (CET)
Received: from p508B6D85.dip.t-dialin.net ([80.139.109.133]:57503 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122118AbSKNSsJ>; Thu, 14 Nov 2002 19:48:09 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAEIls508150;
	Thu, 14 Nov 2002 19:47:54 +0100
Date: Thu, 14 Nov 2002 19:47:54 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Brian Murphy <brian@murphy.dk>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: rsync suggestion
Message-ID: <20021114194754.B5610@linux-mips.org>
References: <3DA1E42C.3050900@murphy.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DA1E42C.3050900@murphy.dk>; from brian@murphy.dk on Mon, Oct 07, 2002 at 09:44:44PM +0200
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: 643
X-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, Oct 07, 2002 at 09:44:44PM +0200, Brian Murphy wrote:

> Is there any chance, Ralf, of an rsync server for the kernel cvs?
> This  really speeds up making diffs and so on and removes load
> from the central cvs server.

Load is hardly an argument.  The machine has 2GB of memory so can keep the
entire CVS archive in memory which extremly speeds up operation.  Anyway,
I rsync of the cvs archive was disabled from the time that the archive
was just an outdated copy of oss; now I re-enabled it.

  Ralf

From lindahl@keyresearch.com Thu Nov 14 20:31:06 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 20:31:06 +0100 (CET)
Received: from nixon.xkey.com ([209.245.148.124]:39906 "HELO nixon.xkey.com")
	by linux-mips.org with SMTP id <S1122118AbSKNTbG>;
	Thu, 14 Nov 2002 20:31:06 +0100
Received: (qmail 14124 invoked from network); 14 Nov 2002 19:30:59 -0000
Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1)
  by localhost with SMTP; 14 Nov 2002 19:30:59 -0000
Received: (from lindahl@localhost)
	by localhost.conservativecomputer.com (8.11.6/8.11.0) id gAEJUj601609
	for linux-mips@linux-mips.org; Thu, 14 Nov 2002 11:30:45 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 14 Nov 2002 11:30:45 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: explain to me how this works...
Message-ID: <20021114113045.D1494@wumpus.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com> <20021114193924.A5610@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021114193924.A5610@linux-mips.org>; from ralf@linux-mips.org on Thu, Nov 14, 2002 at 07:39:24PM +0100
Return-Path: <lindahl@keyresearch.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: 644
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Thu, Nov 14, 2002 at 07:39:24PM +0100, Ralf Baechle wrote:

> Eh?  Nothing on MIPS should use socketcall(2);

OK, so let's say it's using socket(). How do I go about debugging
this? I mean, I can start sprinkling printks all over the place, but is
there a more clever way?

greg

From jsun@orion.mvista.com Thu Nov 14 21:07:55 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 21:07:55 +0100 (CET)
Received: from gateway-1237.mvista.com ([12.44.186.158]:10744 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S1122118AbSKNUHz>;
	Thu, 14 Nov 2002 21:07:55 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id gAEK7kS28873;
	Thu, 14 Nov 2002 12:07:46 -0800
Date: Thu, 14 Nov 2002 12:07:46 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: Re: explain to me how this works...
Message-ID: <20021114120746.E28717@mvista.com>
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com> <20021114193924.A5610@linux-mips.org> <20021114113045.D1494@wumpus.internal.keyresearch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20021114113045.D1494@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Thu, Nov 14, 2002 at 11:30:45AM -0800
Return-Path: <jsun@orion.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: 645
X-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


Look like a good case for using kgdb....

Jun

On Thu, Nov 14, 2002 at 11:30:45AM -0800, Greg Lindahl wrote:
> On Thu, Nov 14, 2002 at 07:39:24PM +0100, Ralf Baechle wrote:
> 
> > Eh?  Nothing on MIPS should use socketcall(2);
> 
> OK, so let's say it's using socket(). How do I go about debugging
> this? I mean, I can start sprinkling printks all over the place, but is
> there a more clever way?
> 
> greg
> 

From ralf@linux-mips.org Thu Nov 14 21:13:03 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 21:13:04 +0100 (CET)
Received: from p508B6D85.dip.t-dialin.net ([80.139.109.133]:52384 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122118AbSKNUND>; Thu, 14 Nov 2002 21:13:03 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAEKCpW09631;
	Thu, 14 Nov 2002 21:12:51 +0100
Date: Thu, 14 Nov 2002 21:12:51 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: explain to me how this works...
Message-ID: <20021114211251.C5610@linux-mips.org>
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com> <20021114193924.A5610@linux-mips.org> <20021114113045.D1494@wumpus.internal.keyresearch.com> <20021114120746.E28717@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021114120746.E28717@mvista.com>; from jsun@mvista.com on Thu, Nov 14, 2002 at 12:07:46PM -0800
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: 646
X-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, Nov 14, 2002 at 12:07:46PM -0800, Jun Sun wrote:

> Look like a good case for using kgdb....

Unlikely to help him.  The return value 4183 of socket that he's observing
is the syscall number of socket(2).  That's making scall_o32.S the first
suspect to look at.

Greg, could this be a case of syscall restarting that you're observing?

  Ralf

From lindahl@keyresearch.com Thu Nov 14 22:26:51 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 22:26:51 +0100 (CET)
Received: from nixon.xkey.com ([209.245.148.124]:58501 "HELO nixon.xkey.com")
	by linux-mips.org with SMTP id <S1122118AbSKNV0v>;
	Thu, 14 Nov 2002 22:26:51 +0100
Received: (qmail 5832 invoked from network); 14 Nov 2002 21:26:39 -0000
Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1)
  by localhost with SMTP; 14 Nov 2002 21:26:39 -0000
Received: (from lindahl@localhost)
	by localhost.conservativecomputer.com (8.11.6/8.11.0) id gAELCWr01830;
	Thu, 14 Nov 2002 13:12:32 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 14 Nov 2002 13:12:32 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: explain to me how this works...
Message-ID: <20021114131232.B1706@wumpus.internal.keyresearch.com>
Mail-Followup-To: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com> <20021114193924.A5610@linux-mips.org> <20021114113045.D1494@wumpus.internal.keyresearch.com> <20021114120746.E28717@mvista.com> <20021114211251.C5610@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021114211251.C5610@linux-mips.org>; from ralf@linux-mips.org on Thu, Nov 14, 2002 at 09:12:51PM +0100
Return-Path: <lindahl@keyresearch.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: 647
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Thu, Nov 14, 2002 at 09:12:51PM +0100, Ralf Baechle wrote:

> Unlikely to help him.  The return value 4183 of socket that he's observing
> is the syscall number of socket(2).

Thank you, I should have noticed that one right off.

My sprinkle of printks already tells me that strace is a liar - no
surprise there.

strace says:

socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
socket(PF_PACKET, SOCK_DGRAM, 0)        = -1 EAFNOSUPPORT (Address family not supported by protocol)

printk says:

sys_socket returning 0
sys32_socket returning 0
sys_socket returning -124
sys32_socket returning -124

Note strace sees 3 syscalls. I only printk at the return statement, 
and there are 2 of those. I'll add more printks...

-- greg

From lindahl@keyresearch.com Thu Nov 14 22:51:12 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 22:51:13 +0100 (CET)
Received: from nixon.xkey.com ([209.245.148.124]:32905 "HELO nixon.xkey.com")
	by linux-mips.org with SMTP id <S1124131AbSKNVvM>;
	Thu, 14 Nov 2002 22:51:12 +0100
Received: (qmail 9181 invoked from network); 14 Nov 2002 21:51:05 -0000
Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1)
  by localhost with SMTP; 14 Nov 2002 21:51:05 -0000
Received: (from lindahl@localhost)
	by localhost.conservativecomputer.com (8.11.6/8.11.0) id gAELopv01982
	for linux-mips@linux-mips.org; Thu, 14 Nov 2002 13:50:51 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 14 Nov 2002 13:50:51 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: explain to me how this works...
Message-ID: <20021114135051.D1896@wumpus.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com> <20021114193924.A5610@linux-mips.org> <20021114113045.D1494@wumpus.internal.keyresearch.com> <20021114120746.E28717@mvista.com> <20021114211251.C5610@linux-mips.org> <20021114131232.B1706@wumpus.internal.keyresearch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021114131232.B1706@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Thu, Nov 14, 2002 at 01:12:32PM -0800
Return-Path: <lindahl@keyresearch.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: 648
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Thu, Nov 14, 2002 at 01:12:32PM -0800, Greg Lindahl wrote:

> socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
> socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
> socket(PF_PACKET, SOCK_DGRAM, 0)        = -1 EAFNOSUPPORT (Address family not supported by protocol)

strace is useless.

My problem was that CONFIG_PACKET was not set in my .config, which causes
EAFNOSUPPORT.

-- greg

From ralf@linux-mips.org Thu Nov 14 23:27:55 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Nov 2002 23:27:56 +0100 (CET)
Received: from p508B6D85.dip.t-dialin.net ([80.139.109.133]:62369 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122118AbSKNW1z>; Thu, 14 Nov 2002 23:27:55 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAEMRm217583
	for linux-mips@linux-mips.org; Thu, 14 Nov 2002 23:27:48 +0100
Date: Thu, 14 Nov 2002 23:27:48 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: explain to me how this works...
Message-ID: <20021114232748.A9839@linux-mips.org>
References: <20021005095335.B4079@lucon.org> <20021113174200.A2874@wumpus.internal.keyresearch.com> <20021114193924.A5610@linux-mips.org> <20021114113045.D1494@wumpus.internal.keyresearch.com> <20021114120746.E28717@mvista.com> <20021114211251.C5610@linux-mips.org> <20021114131232.B1706@wumpus.internal.keyresearch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021114131232.B1706@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Thu, Nov 14, 2002 at 01:12:32PM -0800
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: 649
X-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, Nov 14, 2002 at 01:12:32PM -0800, Greg Lindahl wrote:

> strace says:
> 
> socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
> socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
> socket(PF_PACKET, SOCK_DGRAM, 0)        = -1 EAFNOSUPPORT (Address family not supported by protocol)
> 
> printk says:
> 
> sys_socket returning 0
> sys32_socket returning 0
> sys_socket returning -124
> sys32_socket returning -124
> 
> Note strace sees 3 syscalls. I only printk at the return statement, 
> and there are 2 of those. I'll add more printks...

This smells alot like syscall restarting.  The first two times the
syscall fails with one of ERESTARTNOHAND, ERESTARTSYS or ERESTARTNOINTR,
then the third time is fails with EAFNOSUPPORT.

Enable CONFIG_PACKET and CONFIG_NETLINK_DEV.

The only bug here is strace being to stupid to filter out syscall restarts.

  Ralf

From bbozarth@cisco.com Fri Nov 15 01:43:33 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Nov 2002 01:43:33 +0100 (CET)
Received: from sj-msg-core-3.cisco.com ([171.70.157.152]:53446 "EHLO
	sj-msg-core-3.cisco.com") by linux-mips.org with ESMTP
	id <S1122121AbSKOAnd>; Fri, 15 Nov 2002 01:43:33 +0100
Received: from bbozarth-lnx.cisco.com (bbozarth-lnx.cisco.com [128.107.165.13])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAF0hEsA026009;
	Thu, 14 Nov 2002 16:43:14 -0800 (PST)
Received: from localhost (bbozarth@localhost)
	by bbozarth-lnx.cisco.com (8.11.6/8.11.6) with ESMTP id gAF0hPJ21476;
	Thu, 14 Nov 2002 16:43:25 -0800
Date: Thu, 14 Nov 2002 16:43:25 -0800 (PST)
From: Bradley Bozarth <bbozarth@cisco.com>
To: Ralf Baechle <ralf@linux-mips.org>
cc: george anzinger <george@mvista.com>, <linux-mips@linux-mips.org>
Subject: Re: SEGEV defines
In-Reply-To: <20021114055156.C24744@linux-mips.org>
Message-ID: <Pine.LNX.4.44.0211141518530.13664-100000@bbozarth-lnx.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <bbozarth@cisco.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: 650
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bbozarth@cisco.com
Precedence: bulk
X-list: linux-mips

Along the same lines, the struct sigevent in the kernel says that it isn't 
IRIX compatible.. but it isn't glibc compatible either.  What is it 
compatible with?  The new posix timer code copies this struct from the 
user and kaboom, so again either glibc or the kernel needs to sync up.

relevant sections:

========= glibc/sysdeps/unix/sysv/linux/mips/bits:
/* XXX This one might need to change!!!  */
typedef struct sigevent
  {
    sigval_t sigev_value;
    int sigev_signo;
    int sigev_notify;

========= linux/include/asm-mips:
/* XXX This one isn't yet IRIX / ABI compatible.  */
typedef struct sigevent {
	int sigev_notify;
	sigval_t sigev_value;
	int sigev_signo;







On Thu, 14 Nov 2002, Ralf Baechle wrote:

> On Wed, Nov 13, 2002 at 08:23:10PM -0800, george anzinger wrote:
> 
> > I MUCH prefer a change to the kernel if one or the other
> > needs to change.  The issue is, of course, IRIX
> > compatability and what that means.  This comes up because I
> > want to use the definitions in combination and the common
> > bit makes a mess of things.  Still, it would be NICE if it
> > matched the rest of the platforms.
> 
> The IRIX compatibility code seems unused and the constants aren't even
> part of the ABI at all.  So in this case it indeed seems preferable to
> change the kernel side.
> 
> Anybody disagrees?
> 
>   Ralf
> 


From maz@misterjones.org Fri Nov 15 13:45:43 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Nov 2002 13:45:44 +0100 (CET)
Received: from lopsy-lu.misterjones.org ([62.4.18.26]:63421 "EHLO
	crisis.wild-wind.fr.eu.org") by linux-mips.org with ESMTP
	id <S1122121AbSKOMpn>; Fri, 15 Nov 2002 13:45:43 +0100
Received: from hina.wild-wind.fr.eu.org ([192.168.70.139])
	by crisis.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian))
	id 18Cfsz-0001XV-00
	for <linux-mips@linux-mips.org>; Fri, 15 Nov 2002 13:47:49 +0100
Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.35 #1 (Debian))
	id 18CfqY-0008Ly-00; Fri, 15 Nov 2002 13:45:18 +0100
To: linux-mips@linux-mips.org
Subject: [PATCH] wd33c93 driver cli() removal
Organization: Metropolis -- Nowhere
X-Attribution: maz
X-Baby-1: =?iso-8859-1?q?Lo=EBn?= 12 juin 1996 13:10
X-Baby-2: None
X-Love-1: Gone
X-Love-2: Crazy-Cat
Reply-to: mzyngier@freesurf.fr
From: Marc Zyngier <mzyngier@freesurf.fr>
Date: 15 Nov 2002 13:45:17 +0100
Message-ID: <wrpd6p7huhu.fsf@hina.wild-wind.fr.eu.org>
Lines: 18
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Return-Path: <maz@misterjones.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: 651
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mzyngier@freesurf.fr
Precedence: bulk
X-list: linux-mips

--=-=-=

Hi all,

As part of my effort to get my R4400 Indigo-2 running 2.5, I've
updated the wd33c93 driver to the new locking. I hope I didn't break
it too much in the process.

Note that this is completly untested, since my I2 still refuses to
boot 2.5.47 (dies silently after loading he kernel). As anyone
succeded in running 2.5 on this platform (sgi-ip22) ?

Thanks,

        M.


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

Index: drivers/scsi/wd33c93.c
===================================================================
RCS file: /home/cvs/linux/drivers/scsi/wd33c93.c,v
retrieving revision 1.22
diff -u -r1.22 wd33c93.c
--- drivers/scsi/wd33c93.c	2 Nov 2002 06:05:18 -0000	1.22
+++ drivers/scsi/wd33c93.c	15 Nov 2002 12:35:44 -0000
@@ -315,7 +315,6 @@
 {
    struct WD33C93_hostdata *hostdata;
    Scsi_Cmnd *tmp;
-   unsigned long flags;
 
    hostdata = (struct WD33C93_hostdata *)cmd->host->hostdata;
 
@@ -385,8 +384,7 @@
     * sense data is not lost before REQUEST_SENSE executes.
     */
 
-   save_flags(flags);
-   cli();
+   spin_lock_irq (&hostdata->lock);
 
    if (!(hostdata->input_Q) || (cmd->cmnd[0] == REQUEST_SENSE)) {
       cmd->host_scribble = (uchar *)hostdata->input_Q;
@@ -407,7 +405,7 @@
 
 DB(DB_QUEUE_COMMAND,printk(")Q-%ld ",cmd->pid))
 
-   restore_flags(flags);
+   spin_unlock_irq (&hostdata->lock);
    return 0;
 }
 
@@ -765,7 +763,7 @@
    if (!(asr & ASR_INT) || (asr & ASR_BSY))
       return;
 
-   save_flags(flags);
+   spin_lock_irqsave (&hostdata->lock, flags);
 
 #ifdef PROC_STATISTICS
    hostdata->int_cnt++;
@@ -831,7 +829,7 @@
      * is here...
      */
 
-    restore_flags(flags);
+	 spin_unlock_irqrestore (&hostdata->lock, flags);
 
 /* We are not connected to a target - check to see if there
  * are commands waiting to be executed.
@@ -885,7 +883,8 @@
             hostdata->outgoing_len = 1;
 
          hostdata->state = S_CONNECTED;
-         break;
+         spin_unlock_irqrestore (&hostdata->lock, flags);
+	 break;
 
 
       case CSR_XFER_DONE|PHS_DATA_IN:
@@ -895,7 +894,8 @@
          transfer_bytes(regs, cmd, DATA_IN_DIR);
          if (hostdata->state != S_RUNNING_LEVEL2)
             hostdata->state = S_CONNECTED;
-         break;
+         spin_unlock_irqrestore (&hostdata->lock, flags);
+	 break;
 
 
       case CSR_XFER_DONE|PHS_DATA_OUT:
@@ -905,7 +905,8 @@
          transfer_bytes(regs, cmd, DATA_OUT_DIR);
          if (hostdata->state != S_RUNNING_LEVEL2)
             hostdata->state = S_CONNECTED;
-         break;
+         spin_unlock_irqrestore (&hostdata->lock, flags);
+	 break;
 
 
 /* Note: this interrupt should not occur in a LEVEL2 command */
@@ -916,7 +917,8 @@
 DB(DB_INTR,printk("CMND-%02x,%ld",cmd->cmnd[0],cmd->pid))
          transfer_pio(regs, cmd->cmnd, cmd->cmd_len, DATA_OUT_DIR, hostdata);
          hostdata->state = S_CONNECTED;
-         break;
+         spin_unlock_irqrestore (&hostdata->lock, flags);
+	 break;
 
 
       case CSR_XFER_DONE|PHS_STATUS:
@@ -935,7 +937,8 @@
          else {
             hostdata->state = S_CONNECTED;
             }
-         break;
+         spin_unlock_irqrestore (&hostdata->lock, flags);
+	 break;
 
 
       case CSR_XFER_DONE|PHS_MESS_IN:
@@ -1085,7 +1088,7 @@
                write_wd33c93_cmd(regs, WD_CMD_NEGATE_ACK);
                hostdata->state = S_CONNECTED;
             }
-         restore_flags(flags);
+	 spin_unlock_irqrestore (&hostdata->lock, flags);
          break;
 
 
@@ -1117,12 +1120,13 @@
 /* We are no longer  connected to a target - check to see if
  * there are commands waiting to be executed.
  */
-       restore_flags(flags);
+	    spin_unlock_irqrestore (&hostdata->lock, flags);
             wd33c93_execute(instance);
             }
          else {
             printk("%02x:%02x:%02x-%ld: Unknown SEL_XFER_DONE phase!!---",asr,sr,phs,cmd->pid);
-            }
+            spin_unlock_irqrestore (&hostdata->lock, flags);
+	 }
          break;
 
 
@@ -1133,7 +1137,8 @@
             hostdata->state = S_RUNNING_LEVEL2;
             write_wd33c93(regs, WD_COMMAND_PHASE, 0x41);
             write_wd33c93_cmd(regs, WD_CMD_SEL_ATN_XFER);
-         break;
+         spin_unlock_irqrestore (&hostdata->lock, flags);
+	 break;
 
 
       case CSR_XFER_DONE|PHS_MESS_OUT:
@@ -1163,7 +1168,8 @@
 DB(DB_INTR,printk("%02x",hostdata->outgoing_msg[0]))
          hostdata->outgoing_len = 0;
          hostdata->state = S_CONNECTED;
-         break;
+         spin_unlock_irqrestore (&hostdata->lock, flags);
+	 break;
 
 
       case CSR_UNEXP_DISC:
@@ -1184,7 +1190,8 @@
          if (cmd == NULL) {
             printk(" - Already disconnected! ");
             hostdata->state = S_UNCONNECTED;
-            return;
+            spin_unlock_irqrestore (&hostdata->lock, flags);
+	    return;
             }
 DB(DB_INTR,printk("UNEXP_DISC-%ld",cmd->pid))
          hostdata->connected = NULL;
@@ -1200,7 +1207,7 @@
  * there are commands waiting to be executed.
  */
     /* look above for comments on scsi_done() */
-    restore_flags(flags);
+	 spin_unlock_irqrestore (&hostdata->lock, flags);
          wd33c93_execute(instance);
          break;
 
@@ -1228,7 +1235,6 @@
                else
                   cmd->result = cmd->SCp.Status | (cmd->SCp.Message << 8);
                cmd->scsi_done(cmd);
-          restore_flags(flags);
                break;
             case S_PRE_TMP_DISC:
             case S_RUNNING_LEVEL2:
@@ -1250,6 +1256,7 @@
 /* We are no longer connected to a target - check to see if
  * there are commands waiting to be executed.
  */
+	 spin_unlock_irqrestore (&hostdata->lock, flags);
          wd33c93_execute(instance);
          break;
 
@@ -1367,7 +1374,8 @@
 
          if (!cmd) {
             printk("---TROUBLE: target %d.%d not in disconnect queue---",id,lun);
-            return;
+            spin_unlock_irqrestore (&hostdata->lock, flags);
+	    return;
             }
 
    /* Ok, found the command - now start it up again. */
@@ -1397,10 +1405,12 @@
             hostdata->state = S_CONNECTED;
 
 DB(DB_INTR,printk("-%ld",cmd->pid))
-         break;
+         spin_unlock_irqrestore (&hostdata->lock, flags);
+ break;
          
       default:
          printk("--UNKNOWN INTERRUPT:%02x:%02x:%02x--",asr,sr,phs);
+	 spin_unlock_irqrestore (&hostdata->lock, flags);
       }
 
 DB(DB_INTR,printk("} "))
@@ -1850,12 +1860,9 @@
 #endif
 
 
-   { unsigned long flags;
-     save_flags(flags);
-     cli();
-     reset_wd33c93(instance);
-     restore_flags(flags);
-   }
+   spin_lock_irq (&hostdata->lock);
+   reset_wd33c93(instance);
+   spin_unlock_irq (&hostdata->lock);
 
    printk("wd33c93-%d: chip=%s/%d no_sync=0x%x no_dma=%d",instance->host_no,
          (hostdata->chip==C_WD33C93)?"WD33c93":
@@ -1884,7 +1891,6 @@
 
 char *bp;
 char tbuf[128];
-unsigned long flags;
 struct Scsi_Host *instance;
 struct WD33C93_hostdata *hd;
 Scsi_Cmnd *cmd;
@@ -1949,8 +1955,7 @@
       return len;
       }
 
-   save_flags(flags);
-   cli();
+   spin_lock_irq (&hd->lock);
    bp = buf;
    *bp = '\0';
    if (hd->proc & PR_VERSION) {
@@ -2025,7 +2030,7 @@
          }
       }
    strcat(bp,"\n");
-   restore_flags(flags);
+   spin_unlock_irq (&hd->lock);
    *start = buf;
    if (stop) {
       stop = 0;
Index: drivers/scsi/wd33c93.h
===================================================================
RCS file: /home/cvs/linux/drivers/scsi/wd33c93.h,v
retrieving revision 1.9
diff -u -r1.9 wd33c93.h
--- drivers/scsi/wd33c93.h	29 May 2002 08:12:10 -0000	1.9
+++ drivers/scsi/wd33c93.h	15 Nov 2002 12:35:45 -0000
@@ -217,6 +217,7 @@
 struct WD33C93_hostdata {
     struct Scsi_Host *next;
     wd33c93_regs     regs;
+    spinlock_t       lock;
     uchar            clock_freq;
     uchar            chip;             /* what kind of wd33c93? */
     uchar            microcode;        /* microcode rev */

--=-=-=

-- 
Places change, faces change. Life is so very strange.

--=-=-=--

From bob.lund@visi.com Sun Nov 17 17:34:16 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 17 Nov 2002 17:34:17 +0100 (CET)
Received: from conn.mc.mpls.visi.com ([208.42.156.2]:63940 "EHLO
	conn.mc.mpls.visi.com") by linux-mips.org with ESMTP
	id <S1123966AbSKQQeQ>; Sun, 17 Nov 2002 17:34:16 +0100
Received: from blund (brian.lund.dsl.visi.com [209.98.142.194])
	by conn.mc.mpls.visi.com (Postfix) with SMTP id 211B5814C
	for <linux-mips@linux-mips.org>; Sun, 17 Nov 2002 10:34:10 -0600 (CST)
Message-ID: <01cd01c28e57$21f37ee0$0a00000a@blund>
From: "Bob Lund" <bob.lund@visi.com>
To: <linux-mips@linux-mips.org>
Subject: Linux on LSI SC2005
Date: Sun, 17 Nov 2002 10:33:59 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <bob.lund@visi.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: 652
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bob.lund@visi.com
Precedence: bulk
X-list: linux-mips

Hi,

I'm trying to figure out how much effort would be involved in getting Linux
running on the MIPS core found in the LSI Logic SC2005. According to the LSI
documentation:

MIPS R3000 CPU, executing MIPS I & II and 16 instructions
BBCC with four write back buffers included
Two 32-bit timers
MMU 64-entry TLB RAM
1 to 32 Kbytes of direct mapped or 2 to 64 Kbytes of set associative I-cache
1 to 32 Kbytes of direct mapped D-cache

Any information is appreciated.

Bob Lund





From flo@rfc822.org Sun Nov 17 18:52:40 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 17 Nov 2002 18:52:41 +0100 (CET)
Received: from noose.gt.owl.de ([62.52.19.4]:6929 "HELO noose.gt.owl.de")
	by linux-mips.org with SMTP id <S1123966AbSKQRwk>;
	Sun, 17 Nov 2002 18:52:40 +0100
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 5FD34847; Sun, 17 Nov 2002 18:52:29 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 46A21B2A7; Sun, 17 Nov 2002 18:52:17 +0100 (CET)
Date: Sun, 17 Nov 2002 18:52:17 +0100
From: Florian Lohoff <flo@rfc822.org>
To: linux-mips@linux-mips.org
Subject: loadavg calculation current cvs
Message-ID: <20021117175217.GA23404@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ"
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Organization: rfc822 - pure communication
Return-Path: <flo@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: 653
X-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


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


Could it be that somethings broken ? Although the machine is=20
idle after booting the load is automatically at 1 - Some process
is getting counted in the loadavg although it shouldnt. This is 2.4cvs
2 days old.

remake:~# vmstat 1 10
   procs                      memory    swap          io     system        =
 cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy=
  id
 0  0  1      0  20092   9476  86636   0   0    37    24   10   206   2   3=
  94
 0  0  1      0  20092   9476  86636   0   0     0     0    7   205   0   0=
 100
 0  0  1      0  20092   9476  86636   0   0     0     0    9   206   0   1=
  99
 0  0  1      0  20092   9476  86636   0   0     0     0   12   205   0   1=
  99
 0  0  1      0  20084   9484  86636   0   0     0    48   11   202   3   9=
  88
 0  0  1      0  20084   9484  86636   0   0     0     0    8   206   0   1=
  99
 0  0  1      0  20084   9484  86636   0   0     0     0    9   206   0   1=
  99
 0  0  1      0  20084   9484  86636   0   0     0     0   10   205   0   1=
  99
 0  0  1      0  20084   9484  86636   0   0     0     0   11   205   0   1=
  99
 0  0  1      0  20076   9492  86636   0   0     0    48    9   202   3   9=
  88
remake:~# uptime
 18:47:00 up 51 min,  1 user,  load average: 1.10, 1.13, 1.01
remake:~# ps auxw
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.4  1988  600 ?        S    17:55   0:01 init
root         2  0.0  0.0     0    0 ?        SW   17:55   0:00 [keventd]
root         3  0.0  0.0     0    0 ?        RWN  17:55   0:00 [ksoftirqd_C=
PU0]
root         4  0.0  0.0     0    0 ?        SW   17:55   0:00 [kswapd]
root         5  0.0  0.0     0    0 ?        SW   17:55   0:00 [bdflush]
root         6  0.0  0.0     0    0 ?        SW   17:55   0:00 [kupdated]
root         7  0.0  0.0     0    0 ?        SW   17:55   0:00 [kjournald]
root       134  0.0  0.6  2520  880 ?        S    17:55   0:00 /sbin/dhclie=
nt-2.2.x -q eth0
root      1611  0.0  0.5  2320  696 ?        S    17:55   0:00 /sbin/syslogd
root      1614  0.0  0.7  2372  984 ?        S    17:55   0:00 /sbin/klogd
root      1622  0.0  0.4  2276  628 ?        S    17:55   0:00 /usr/sbin/in=
etd
root      1626  0.0  0.4  1976  532 ?        S    17:55   0:00 /usr/sbin/sm=
artd
root      1642  0.0  1.1  6356 1492 ?        S    17:55   0:02 /usr/sbin/ss=
hd
daemon    1646  0.0  0.5  2652  716 ?        S    17:55   0:00 /usr/sbin/atd
root      1651  0.0  0.6  3700  836 ?        S    17:55   0:00 /usr/sbin/cr=
on
root      1655  0.0  1.0  4420 1384 ?        S    17:55   0:00 /bin/sh /usr=
/local/sbin/display
root      2598  0.0  0.4  1956  576 ttyS0    S    18:09   0:00 /sbin/getty =
57600 ttyS0 vt100
root      4039  0.1  1.7 12192 2236 ?        S    18:40   0:00 /usr/sbin/ss=
hd
root      4045  0.0  1.2  4472 1656 pts/0    S    18:40   0:00 -bash
root      4711  1.0  0.4  3452  584 ?        S    18:50   0:00 sleep 5
root      4712  0.0  1.0  4656 1372 pts/0    R    18:50   0:00 ps auxw
remake:~# cat /proc/cpuinfo
system type             : MQ Pro
processor               : 0
cpu model               : R5000 V4.0  FPU V1.0
BogoMIPS                : 249.85
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 48
extra interrupt vector  : no
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available
remake:~# uname -a
Linux remake.rfc822.org 2.4.20-pre6 #1 Fri Nov 15 23:16:01 CET 2002 mips un=
known

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE919dRUaz2rXW+gJcRAtoPAKCU452GYLDVzJuVpgQX2I0XRZTDkgCghGLU
jWxzdVA3+UhVUxL32lrl7U8=
=FeZ2
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--

From brian@murphy.dk Sun Nov 17 21:58:36 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 17 Nov 2002 21:58:37 +0100 (CET)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:32298 "EHLO
	ubik.localnet") by linux-mips.org with ESMTP id <S1124140AbSKQU6g>;
	Sun, 17 Nov 2002 21:58:36 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by ubik.localnet (8.12.3/8.12.3/Debian -4) with ESMTP id gAHKwQfA018134;
	Sun, 17 Nov 2002 21:58:26 +0100
Message-ID: <3DD802F2.4040306@murphy.dk>
Date: Sun, 17 Nov 2002 21:58:26 +0100
From: Brian Murphy <brian@murphy.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
MIME-Version: 1.0
To: Florian Lohoff <flo@rfc822.org>
CC: Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: loadavg calculation current cvs
References: <20021117175217.GA23404@paradigm.rfc822.org>
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: 654
X-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

Florian Lohoff wrote:

>Could it be that somethings broken ? Although the machine is 
>idle after booting the load is automatically at 1 - Some process
>is getting counted in the loadavg although it shouldnt. This is 2.4cvs
>2 days old.
>
>
>root         3  0.0  0.0     0    0 ?        RWN  17:55   0:00 [ksoftirqd_CPU0]
>  
>
ksoftirqd is always running, it seems, even when it's not.

/Brian



From brm@murphy.dk Sun Nov 17 22:41:19 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 17 Nov 2002 22:41:20 +0100 (CET)
Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:39722 "EHLO
	brian.localnet") by linux-mips.org with ESMTP id <S1123966AbSKQVlT>;
	Sun, 17 Nov 2002 22:41:19 +0100
Received: from brm by brian.localnet with local (Exim 3.35 #1 (Debian))
	id 18DXAH-0002KJ-00; Sun, 17 Nov 2002 22:41:13 +0100
To: linux-mips@linux-mips.org
Subject: [PATCH 2.4] load average fix for lasat boards (timer interrupt handling fix)
Cc: flo@rfc822.org, ralf@linux-mips.org
Message-Id: <E18DXAH-0002KJ-00@brian.localnet>
From: Brian Murphy <brm@murphy.dk>
Date: Sun, 17 Nov 2002 22:41:13 +0100
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: 655
X-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 Florian, Ralf,
	it seems the method of calling the new time code changed
or it was wrong all along, This patch fixes the problem of the
ksoftirqd running all the time on Lasat systems, can you apply
Ralf?

/Brian
	
Index: arch/mips/lasat/setup.c
===================================================================
RCS file: /cvs/linux/arch/mips/lasat/setup.c,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 setup.c
--- arch/mips/lasat/setup.c	6 Oct 2002 11:38:14 -0000	1.1.2.5
+++ arch/mips/lasat/setup.c	17 Nov 2002 21:31:42 -0000
@@ -109,14 +109,10 @@
 	change_cp0_status(ST0_IM, IE_IRQ0 | IE_IRQ5);
 }
 
+#define MIPS_CPU_TIMER_IRQ 7
 asmlinkage void lasat_timer_interrupt(struct pt_regs *regs)
 {
-	int cpu = smp_processor_id();
-
-	timer_interrupt(7, NULL, regs);
-
-	if (softirq_pending(cpu))
-		do_softirq();
+	ll_timer_interrupt(MIPS_CPU_TIMER_IRQ, regs);
 }
 
 void __init lasat_setup(void)

From hjl@lucon.org Mon Nov 18 01:42:15 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 01:42:18 +0100 (CET)
Received: from p508B6A0E.dip.t-dialin.net ([80.139.106.14]:54728 "EHLO
	p508B6A0E.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1123966AbSKRAmP>; Mon, 18 Nov 2002 01:42:15 +0100
Received: from sccrmhc03.attbi.com ([IPv6:::ffff:204.127.202.63]:4033 "EHLO
	sccrmhc03.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S868471AbSKRAgG>; Mon, 18 Nov 2002 01:36:06 +0100
Received: from lucon.org (12-234-88-146.client.attbi.com[12.234.88.146])
          by sccrmhc03.attbi.com (sccrmhc03) with ESMTP
          id <2002111800413900300rlf0ee>; Mon, 18 Nov 2002 00:41:39 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id E44532C66F; Sun, 17 Nov 2002 16:41:38 -0800 (PST)
Date: Sun, 17 Nov 2002 16:41:38 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: gcc@gcc.gnu.org, linux-gcc@vger.kernel.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, Ron Guilmette <rfg@monkeys.com>,
	"Polstra; John" <linux-binutils-in@polstra.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	Feher Janos <aries@hal2000.terra.vein.hu>,
	Leonard Zubkoff <lnz@dandelion.com>,
	"Steven J. Hill" <sjhill@cotw.com>
Subject: The Linux binutils 2.13.90.0.14 is released
Message-ID: <20021117164138.A11949@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 656
X-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.13.90.0.14 for Linux, which is
based on binutils 2002 1114 in CVS on sourecs.redhat.com plus various
changes. It is purely for Linux.

The Linux/mips support is added. You have to use

# rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz

to build it. Or you can read mips/README in the source tree to apply
the mips patches and build it by hand.

FYI, the binutils man pages now are generated from the texinfo files
during the build. As the result, those man pages may be changed for
each build even if you only have done

# ..../configure ...
# make

That means you may have many failures on the man pages when you apply
the binutils diffs next time. Those failures can be safely ignored.
You should remove all those man pages from your source tree by

# find -name *.1 | xargs rm -f
# find -name *.1.rej | xargs rm -f
# find -name *.man | xargs rm -f
# find -name *.man.rej | xargs rm -f

Please report any bugs related to binutils 2.13.90.0.14 to hjl@lucon.org.

For arm-linux targets, there are some important differences in behaviour 
between these tools and binutils 2.9.1.0.x.  The linker emulation name has 
changed from elf32arm{26} to armelf_linux{26}.  Also, the "-p" flag must be 
passed with the linker when working with object files (or static libraries) 
created using older versions of the assembler.  If this flag is omitted the 
linker will silently generate bad output when given old input files.

To get the correct behaviour from gcc, amend the *link section of your specs 
file as follows:

*link:
%{h*} %{version:-v}    %{b} %{Wl,*:%*}    %{static:-Bstatic}    %{shared:-shared}    %{symbolic:-Bsymbolic}    %{rdynamic:-export-dynamic}    %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2}    -X    %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p


Changes from binutils 2.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.

Changes from binutils 2.12.90.0.15:

1. Update from binutils 2002 0802.
2. Initial support for mips n32 ABI.
3. Fix some x86 TLS bugs.

Changes from binutils 2.12.90.0.14:

1. Update from binutils 2002 0717.
2. Fix an ia64 assembler bug.
3. Fix a symbol versioning bug.
4. You have to upgrade to modutils 2.4.19 or apply the modutils patch
enclosed here in order to support System.map generated by the new nm.

Changes from binutils 2.12.90.0.12:

1. Update from binutils 2002 0627.
2. Fix a linker bug which leads to the incorrect Linux 2.2 kernel.

Changes from binutils 2.12.90.0.11:

1. Update from binutils 2002 0618.
2. Fix a mips assembler bug.

Changes from binutils 2.12.90.0.9:

1. Update from binutils 2002 0608.
2. Fix an ELF/mips SHF_MERGE bug.

Changes from binutils 2.12.90.0.7:

1. Update from binutils 2002 0526.
2. Support "-z muldefs".

Changes from binutils 2.12.90.0.4:

1. Update from binutils 2002 0423.
2. ELF EH frame bug fix.
3. MIPS ELF visibility bug fix.

Changes from binutils 2.12.90.0.3:

1. Update from binutils 2002 0408.
2. Bug fixes for ELF/sparc.
3. Bug fixes for ELF/CRIS.

Changes from binutils 2.12.90.0.1:

1. Update from binutils 2002 0323.
2. Fix linking a.out relocatable files with ELF.
3. Fix a PPC altivec assembler bug.

Changes from binutils 2.11.93.0.2:

1. Update from binutils 2002 0307.
2. Add the .preinit_array/.init_array/.fini_array support.
3. Fix eh_frame.
4. Turn on combreloc by default.
5. Enable gprof for Linux/mips.

Changes from binutils 2.11.92.0.12.3:

1. Update from binutils 2002 0207.
2. Fix a weak symbol alpha linker bug for glibc.
3. More support for gcc 3.1.

Changes from binutils 2.11.92.0.12:

1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object
files.

Changes from binutils 2.11.92.0.10:

1. Update from binutils 2001 1121.
2. Fix a linker symbol version bug for common symbols.
3. Update handling relocations against the discarded sections. You may
need to apply the kernel patch enclosed here to your kernel source. If
you still see things like

drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit'

in the final kernel link, that means you have compiled a driver into
the kernel which has a reference to the symbol in a discarded section.
Kernel 2.4.17 or above should work fine.

4. Support "-march=xxx -mipsN" for mips gas if they are compatible.

Changes from binutils 2.11.92.0.7:

1. Update from binutils 2001 1021.
2. Fix the ELF/PPC linker.
3. Fix the ELF/cris linker.
4. Fix ELF strip.

Changes from binutils 2.11.92.0.5:

1. Update from binutils 2001 1016.
2. Fix all breakages introduced in 2.11.92.0.12.

Changes from binutils 2.11.90.0.31:

1. Update from binutils 2001 1005.
2. Support gcc 3.1 for ia64.
3. Support prelink for ELF/PPC.
4. Fix an ELF/x86 linker bug for Oracle.
5. Fix a weak symbol bug.
6. Support locale.

Changes from binutils 2.11.90.0.29:

1. Update from binutils 2001 0830.
2. Fix a mips linker bug.

Changes from binutils 2.11.90.0.27:

1. Update from binutils 2001 0827.
2. Fix an alpha assembler bug.
3. Fix an ia64 linker bug.
4. Fix a mips linker bug.
5. Support `-z combreloc|nocombreloc' in linker.

Changes from binutils 2.11.90.0.25:

1. Update from binutils 2001 0810.
2. Fix an x86 linker bug.

Changes from binutils 2.11.90.0.24:

1. Update from binutils 2001 0726.
2. Fix an x86 assembler bug.
3. "make check" in the windres test in binutils may call uudecode. We
are working on it.
4. "make check" fails the windres test in binutils if the i386/pe
is enabled in bfd. Fixed in the next release.
5. "make check" has 2 failures in the ld-selective test in ld on
Linux/alpha. They should be marked xfail. Fixed in the next release.

Changes from binutils 2.11.90.0.23:

1. Update from binutils 2001 0714.
2. Fix Sparc/ElF for Linux/sparc.
3. Fix Alpha/ELF for gcc 3.0.

Changes from binutils 2.11.90.0.19:

1. Update from binutils 2001 0706.
2. Fix objcopy/strip broken by accident.
3. Avoid COPY relocs on ia32.
4. Fix the ia64 assembler.
5. This release may not work on Linux/sparc due to the unaligned
relocation changes, which are not handled by all versions of glibc.
The current glibc in CVS on sourceware should be ok. The last known
working binutils for Linux/sparc is 2.11.90.0.8. We are working on it.

Changes from binutils 2.11.90.0.15:

1. Update from binutils 2001 0620.
2. Fix a static linking the PIC object files on ia32.
3. Add the verion script support for --export-dynamic. It can be used
to selectively export dynamic symbols from the executables.

Changes from binutils 2.11.90.0.8:

1. Update from binutils 2001 0610.
2. Fix a gas bug for gcc 3.0.

Changes from binutils 2.11.90.0.7:

1. Update from binutils 2001 0512.
2. Fix some P/III SSE 2 assembler bugs.
3. Fix DT_NEEDED and symbol version bugs.
4. Support hidden versioned symbols in DSOs.

Changes from binutils 2.11.90.0.6:

1. Update from binutils 2001 0427.
2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5.

Changes from binutils 2.11.90.0.5:

1. Update from binutils 2001 0425.
2. Update "ld --multilib-dir PATH".

Changes from binutils 2.11.90.0.4:

1. Update from binutils 2001 0414.
2. Fix an ia64 assembler bug.
3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI.
since there are no supports for the IRIX ABI in glibc. The current
Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS
instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS
instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified
for this change. 

Changes from binutils 2.11.90.0.1:

1. Update from binutils 2001 0401.
2. Fix a gas bug for the gcc from the CVS main trunk. It involves some
changes in gas. I compiled kernel 2.2.18, gcc and glibc under
Linux/ia32. The resulting binaries work fine. 
3. Fix the linker core dump on unsupported ELF binaries.

Changes from binutils 2.10.91.0.4:

1. Update from binutils 2001 0309.

Changes from binutils 2.10.91.0.2:

1. Update from binutils 2001 0223.
2. More ia64 bug fixes.

Changes from binutils 2.10.1.0.7:

1. Update from binutils 2001 0215.
2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64.
3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32.

Changes from binutils 2.10.1.0.4:

1. Update from binutils 2001 0206.
2. Enable the IA64 support.
3. Now you need to use

# ld --oformat TARGET

instead of

# ld -oformat TARGET

The Linux kernel build may be affected. BTW

# ld --oformat TARGET

should work with all previous releases of binutils.

Changes from binutils 2.10.1.0.2:

1. Update from binutils 2000 1221.

Changes from binutils 2.10.0.33:

1. Update from binutils 2000 1119.
2. It has some symbol versioning related updates.

Changes from binutils 2.10.0.32:

1. Update from binutils 2000 1018.
2. A proper ELF/PPC visibility fix.
3. m68k-a.out is supposed to be fixed.

Changes from binutils 2.10.0.31:

1. Update from binutils 2000 1014.
2. An ELF/PPC weak symbol bug fix.
3. A new linkonce section name approach.
4. m68k-a.out is still broken. To be fixed.

Changes from binutils 2.10.0.29:

1. Update from binutils 2000 1011.
2. Back out the linkonce section name change so that C++ will work.
A different approach is being worked on.
3. m68k-a.out is known to be broken. To be fixed.

Changes from binutils 2.10.0.26:

1. Update from binutils 2000 1008.

Changes from binutils 2.10.0.24:

1. Update from binutils 2000 0907.

Changes from binutils 2.10.0.18:

1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling.
Fix the ELF/ia32 DSO not compiled with PIC.
2. Try to fix the ELF visibility bug on PPC with glibc 2.2.

Changes from binutils 2.10.0.12:

1. Update from binutils 2000 0720.
2. Fix the DT_NEEDED link bug.
3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least
on libpthread.so.

Changes from binutils 2.10.0.9:

1. Update from binutils 2000 0701. Fix the parallel build in ld when PE
is enabled.

Changes from binutils 2.9.5.0.46:

1. Update from binutils 2000 0617. The demangler support for the new
g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF
relocatable object files under ELF with symbol versioning.
2. Support for linking PE relocatable object files under ia32/ELF.

Changes from binutils 2.9.5.0.42:

1. Update from binutils 2000 0604. The ELF visibility attribuite should
work correctly now.
2. The ia32 assembler has changed the way it assembles the "jmp"
instructions to the global symbols. The old assembler will optimize the
jump to the global symbol defined in the same source file so that no
relocation will be used. The new assembler will use relocation for
global jumps. It will mainly affect PIC asm code. The segment like

	.globl  __setjmp
__setjmp:
	...
	jmp __sigsetjmp
	...
	.globl __sigsetjmp
__sigsetjmp:

is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol
and relocation will be used. Instead, it can be changed to

	.globl  __setjmp
__setjmp:
	...
	jmp sigsetjmp
	...
	.globl __sigsetjmp
__sigsetjmp:
sigsetjmp:

so that "jmp sigsetjmp" jumps to a local symbol and the new assembler
will optimize out the relocation.

Changes from binutils 2.9.5.0.41:

1. Update from binutils 2000 0512.
2. Add testsuite for ELF visibility.

Changes from binutils 2.9.5.0.37:

1. Update from binutils 2000 0502.
2. Support STV_HIDDEN and STV_INTERNAL.

Changes from binutils 2.9.5.0.35:

1. Update from binutils 2000 0418.
2. Fix an ld demangle style option bug.

Changes from binutils 2.9.5.0.34:

1. Update from binutils 2000 0412. Fix a relocation bug which affects
the Linux kernel compilation.
2. An ELF/PPC linker script update.

Changes from binutils 2.9.5.0.33:

1. Update from binutils 2000 0404. Fix the bug report bug.

Changes from binutils 2.9.5.0.32:

1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug.

Changes from binutils 2.9.5.0.31:

1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug.
2. Fix a Debian assembler security bug.

Changes from binutils 2.9.5.0.29:

1. Update from binutils 2000 0319.
2. An ELF/alpha bug is fixed.

Changes from binutils 2.9.5.0.27:

1. Update from binutils 2000 0301.
2. A demangler bug is fixed.
3. A better fix for undefined symbols with -Bsymbolic when building
shared library.

Changes from binutils 2.9.5.0.24:

1. Update from binutils 2000 0204.
2. Added -taso to linker on alpha.
3. Fixed a -shared -Bsymbolic bug when PIC is not used.

Changes from binutils 2.9.5.0.22:

1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.

Changes from binutils 2.9.5.0.21:

1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.

Changes from binutils 2.9.5.0.19:

1. Update from binutils 1999 1122. An ia32 gas bug is fixed.

Changes from binutils 2.9.5.0.16:

1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.

Changes from binutils 2.9.5.0.14:

1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".

Changes from binutils 2.9.5.0.13:

1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.

Changes from binutils 2.9.5.0.12:

1. Update from binutils 1999 0922.
2. i370 update.

Changes from binutils 2.9.5.0.11:

1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
   and sparc introduced in the last release.
2. i370 update.

Changes from binutils 2.9.5.0.10:

1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
   and sparc.
2. Remove elf/hppa since it is WIP.

Changes from binutils 2.9.5.0.8:

1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
   in x86 FP register names.

Changes from binutils 2.9.5.0.7:

1. Update from binutils 1999 0821.
2. Some MIPS changes.

Changes from binutils 2.9.5.0.6:

1. Update from binutils 1999 0813.
2. i370 update.

Changes from binutils 2.9.5.0.5:

1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.

Changes from binutils 2.9.5.0.4:

1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.

Changes from binutils 2.9.5.0.3:

1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.

Changes from binutils 2.9.4.0.8:

1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.

Changes from binutils 2.9.4.0.7:

1. Update from binutils 1999 0710. A weak symbol bug

http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html

is fixed.

Changes from binutils 2.9.4.0.6:

1. Update from binutils 1999 0626.

Changes from binutils 2.9.4.0.5:

1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
   for objcopy.

Changes from binutils 2.9.4.0.4:

1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
   now.

Changes from binutils 2.9.4.0.3:

1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.

Changes from binutils 2.9.4.0.2:

1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.

Changes from binutils 2.9.4.0.1:

1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
   Linux kernel can build.
3. Fix i370 for the new gas.

Changes from binutils 1999 0605:

1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.

The file list:

1. binutils-2.13.90.0.14.tar.gz. Source code.
2. binutils-2.13.90.0.10-2.13.90.0.14.diff.gz. Patch against the
   previous beta source code.
3. binutils-2.13.90.0.14-1.i386.rpm. IA-32 binary RPM for RedHat 7.3.

There is no separate source rpm. You can do

# rpm -ta binutils-2.13.90.0.14.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

1. http://ftp.kernel.org/pub/linux/devel/binutils/

Thanks.


H.J. Lu
hjl@lucon.org
11/17/2002
----
> On Mon, Jul 15, 2002 at 04:35:47PM +0930, Alan Modra wrote:
> > Something you might like to warn about in your next release..
> > 
> > The 2002-07-05 bfd change exposes a bug in modutils.  depmod scans the
> > output of nm for a `?' symbol type when looking for certain symbols.
> > nm used to return `?' for symbols in sections other than some standard
> > sections like .text and .data.  Now, nm returns a better guess as to
> > the symbol type.
> 

No, but it parses System.map, which is generated by nm.  This was in
modutils-2.4.16.  Fix follows.

diff -urp modutils-2.4.16.orig/depmod/depmod.c modutils-2.4.16/depmod/depmod.c
--- modutils-2.4.16.orig/depmod/depmod.c	2002-04-28 17:23:35.000000000 +0930
+++ modutils-2.4.16/depmod/depmod.c	2002-07-15 16:41:20.000000000 +0930
@@ -1060,12 +1060,9 @@ static int addksyms(char *file_syms)
 		if (!isspace(*line))	/* Adressless symbol? */
 			p = strtok(NULL, " \t\n");
 		/* The second word is either the symbol name or a type */
-		if (p && strlen(p) == 1) { /* System.map */
+		if (p && p[0] && !p[1]) { /* System.map */
 			is_mapfile = 1;
-			if (*p != '?')
-				p = NULL;
-			else
-				p = strtok(NULL, " \t\n");
+			p = strtok(NULL, " \t\n");
 		} else { /* /proc/ksyms copy */
 			if (p && strtok(NULL, " \t\n"))
 				p = NULL;
@@ -1083,7 +1080,7 @@ static int addksyms(char *file_syms)
 			if (!isspace(*line))	/* Adressless symbol? */
 				p = strtok(NULL, " \t\n");
 			if (is_mapfile) {
-				if (*p != '?')
+				if (!p || !p[0] || p[1])
 					continue;
 				p = strtok(NULL, " \t\n");
 				/* Sparc has symbols like '.div' that need to be


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

From rjkm@rjkm.de Mon Nov 18 04:50:06 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 04:50:07 +0100 (CET)
Received: from xdsl-213-168-119-66.netcologne.de ([213.168.119.66]:43329 "EHLO
	rjkm.de") by linux-mips.org with ESMTP id <S1123966AbSKRDuG>;
	Mon, 18 Nov 2002 04:50:06 +0100
Received: (from rjkm@localhost)
	by rjkm.de (8.12.0.Beta19/8.12.0.Beta19) id gAI3nDMx024234;
	Mon, 18 Nov 2002 04:49:13 +0100
From: Ralph Metzler <rjkm@metzlerbros.de>
Message-ID: <15832.25401.226111.893020@gargle.gargle.HOWL>
Date: Mon, 18 Nov 2002 04:49:13 +0100
To: "Bob Lund" <bob.lund@visi.com>
Cc: <linux-mips@linux-mips.org>
Subject: Linux on LSI SC2005
In-Reply-To: <01cd01c28e57$21f37ee0$0a00000a@blund>
References: <01cd01c28e57$21f37ee0$0a00000a@blund>
X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" XEmacs Lucid
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Return-Path: <rjkm@rjkm.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: 657
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rjkm@metzlerbros.de
Precedence: bulk
X-list: linux-mips

Hi, 

Bob Lund writes:
 > I'm trying to figure out how much effort would be involved in getting Linux
 > running on the MIPS core found in the LSI Logic SC2005. According to the LSI
 > documentation:
 > 
 > MIPS R3000 CPU, executing MIPS I & II and 16 instructions
 > BBCC with four write back buffers included
 > Two 32-bit timers
 > MMU 64-entry TLB RAM
 > 1 to 32 Kbytes of direct mapped or 2 to 64 Kbytes of set associative I-cache
 > 1 to 32 Kbytes of direct mapped D-cache
 > 
 > Any information is appreciated.

I did some work on an SC2000 about 18 months ago but only for one or two
weeks. The kernel and networking on the eval board was basically
working then but, AFAIR, there were problems (as in total lock up) with 
enabled cache in user mode. Without cache it was veeeeery slow.


Ralph

From umesh.suryawanshi@tatainfotech.com Mon Nov 18 05:07:10 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 05:07:11 +0100 (CET)
Received: from 180.tatainfotech.com ([203.124.134.180]:37835 "EHLO
	tilmax.tatainfotech.co.in") by linux-mips.org with ESMTP
	id <S1124231AbSKREHK>; Mon, 18 Nov 2002 05:07:10 +0100
Received: from goamail.in.tatainfotech.com (IDENT:root@tilmax.tatainfotech.co.in [127.0.0.1])
	by tilmax.tatainfotech.co.in (8.11.0/8.11.0) with ESMTP id gAI46sf11688
	for <linux-mips@linux-mips.org>; Mon, 18 Nov 2002 09:36:54 +0530
Received: from Administrator ([163.122.44.15])
	by goamail.in.tatainfotech.com (8.8.7/8.8.7) with SMTP id JAA16693
	for <linux-mips@linux-mips.org>; Mon, 18 Nov 2002 09:26:59 +0530
From: "Umesh Suryawanshi" <umesh.suryawanshi@tatainfotech.com>
To: <linux-mips@linux-mips.org>
Subject: Study:MIPS Board
Date: Mon, 18 Nov 2002 09:47:58 +0530
Message-ID: <NFBBLKAGHEEGPLCBPPCLEEGGDEAA.umesh.suryawanshi@tatainfotech.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0019_01C28EE7.9374A540"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Return-Path: <umesh.suryawanshi@tatainfotech.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: 658
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: umesh.suryawanshi@tatainfotech.com
Precedence: bulk
X-list: linux-mips


This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C28EE7.9374A540
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hello
I am having IDT79S334A MIPS evaluation board. I want to install Linux and
perform some study on that board.
How should i proceed to understand the board?

What can I do on this board to get complete idea ...? may be one project
....
Umesh Suryawanshi
Design and Development Engineer,
Embedded Technology Group
Tata Infotech, Goa



------=_NextPart_000_0019_01C28EE7.9374A540
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D885241304-18112002>Hello</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D885241304-18112002></SPAN><FONT size=3D2><FONT =
face=3DArial><SPAN=20
class=3D885241304-18112002>I am having </SPAN>IDT79S334A MIPS evaluation =

board<SPAN class=3D885241304-18112002>. I want to install Linux and =
perform some=20
study on that board.</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D885241304-18112002>How should i=20
proceed to understand the board?</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D885241304-18112002></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D885241304-18112002>What=20
can&nbsp;I do on this board to get complete idea ...? may be one project =

....</SPAN></FONT></FONT></DIV>
<P><FONT color=3D#0000ff size=3D2><STRONG>Umesh Suryawanshi<BR>Design =
and=20
Development Engineer,<BR>Embedded Technology Group<BR>Tata Infotech, Goa =

</STRONG></FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0019_01C28EE7.9374A540--


From ralf@linux-mips.org Mon Nov 18 05:39:43 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 05:39:44 +0100 (CET)
Received: from p508B75AF.dip.t-dialin.net ([80.139.117.175]:62604 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1124241AbSKREjn>; Mon, 18 Nov 2002 05:39:43 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAI4dZq25579
	for linux-mips@linux-mips.org; Mon, 18 Nov 2002 05:39:35 +0100
Date: Mon, 18 Nov 2002 05:39:35 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Origin patches for 2.4.19-pre6
Message-ID: <20021118053935.A25428@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 659
X-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

Below a fairly dirty set tho revive the IP27 (Origin 200 & 2000) port.
Tested only on Origin 200 for now as I don't have access to something
bigger atm.

  Ralf

diff -u -r1.99.2.32 traps.c
--- arch/mips/kernel/traps.c 4 Nov 2002 19:39:56 -0000
+++ arch/mips/kernel/traps.c 18 Nov 2002 04:30:00 -0000
@@ -909,6 +909,12 @@
 
 	cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
 	set_context(cpu << 23);
+
+	atomic_inc(&init_mm.mm_count);
+	current->active_mm = &init_mm;
+	if (current->mm)
+		BUG();
+	enter_lazy_tlb(&init_mm, current, cpu);
 }
 
 void __init trap_init(void)
diff -u -r1.1.2.3 ip27-console.c
--- arch/mips/sgi-ip27/ip27-console.c 7 Nov 2002 01:47:45 -0000
+++ arch/mips/sgi-ip27/ip27-console.c 18 Nov 2002 04:30:06 -0000
@@ -9,6 +9,7 @@
 #include <linux/console.h>
 #include <linux/kdev_t.h>
 #include <linux/major.h>
+#include <asm/page.h>
 #include <asm/sn/addrs.h>
 #include <asm/sn/sn0/hub.h>
 #include <asm/sn/klconfig.h>
@@ -45,11 +46,11 @@
 }
 
 static struct console ip27_prom_console = {
-    .name	= "prom",
-    .write	= ip27prom_console_write,
-    .device	= ip27prom_console_dev,
-    .flags	= CON_PRINTBUFFER,
-    .index	= -1,
+	.name	= "prom",
+	.write	= ip27prom_console_write,
+	.device	= ip27prom_console_dev,
+	.flags	= CON_PRINTBUFFER,
+	.index	= -1,
 };
 
 __init void ip27_setup_console(void)
diff -u -r1.1.2.3 ip27-init.c
--- arch/mips/sgi-ip27/ip27-init.c 28 Sep 2002 22:28:38 -0000
+++ arch/mips/sgi-ip27/ip27-init.c 18 Nov 2002 04:30:06 -0000
@@ -424,6 +424,8 @@
 
 void __init start_secondary(void)
 {
+	extern atomic_t smp_commenced;
+
 	CPUMASK_CLRB(boot_barrier, getcpuid());	/* needs atomicity */
 	per_cpu_init();
 	per_cpu_trap_init();
@@ -435,7 +437,20 @@
 	local_flush_tlb_all();
 	flush_cache_l1();
 	flush_cache_l2();
-	start_secondary();
+
+	smp_callin();
+	while (!atomic_read(&smp_commenced));
+	return cpu_idle();
+}
+
+static int __init fork_by_hand(void)
+{
+	struct pt_regs regs;
+	/*
+	 * don't care about the epc and regs settings since
+	 * we'll never reschedule the forked task.
+	 */
+	return do_fork(CLONE_VM|CLONE_PID, 0, &regs, 0);
 }
 
 __init void allowboot(void)
@@ -457,6 +472,8 @@
 	boot_barrier = boot_cpumask;
 	/* Launch slaves. */
 	for (cpu = 0; cpu < maxcpus; cpu++) {
+		struct task_struct *idle;
+
 		if (cpu == mycpuid) {
 			alloc_cpupda(cpu, num_cpus);
 			num_cpus++;
@@ -466,59 +483,66 @@
 		}
 
 		/* Skip holes in CPU space */
-		if (CPUMASK_TSTB(boot_cpumask, cpu)) {
-			struct task_struct *p;
+		if (!CPUMASK_TSTB(boot_cpumask, cpu))
+			continue;
 
-			/*
-			 * The following code is purely to make sure
-			 * Linux can schedule processes on this slave.
-			 */
-			kernel_thread(0, NULL, CLONE_PID);
-			p = init_task.prev_task;
-			sprintf(p->comm, "%s%d", "Idle", num_cpus);
-			init_tasks[num_cpus] = p;
-			alloc_cpupda(cpu, num_cpus);
-			del_from_runqueue(p);
-			p->processor = num_cpus;
-			p->cpus_runnable = 1 << num_cpus; /* we schedule the first task manually */
-			unhash_process(p);
-			/* Attach to the address space of init_task. */
-			atomic_inc(&init_mm.mm_count);
-			p->active_mm = &init_mm;
-
-			/*
-		 	 * Launch a slave into smp_bootstrap().
-		 	 * It doesn't take an argument, and we
-			 * set sp to the kernel stack of the newly
-			 * created idle process, gp to the proc struct
-			 * (so that current-> works).
-		 	 */
-			LAUNCH_SLAVE(cputonasid(num_cpus),cputoslice(num_cpus),
-				(launch_proc_t)MAPPED_KERN_RW_TO_K0(smp_bootstrap),
-				0, (void *)((unsigned long)p +
-				KERNEL_STACK_SIZE - 32), (void *)p);
-
-			/*
-			 * Now optimistically set the mapping arrays. We
-			 * need to wait here, verify the cpu booted up, then
-			 * fire up the next cpu.
-			 */
-			__cpu_number_map[cpu] = num_cpus;
-			__cpu_logical_map[num_cpus] = cpu;
-			CPUMASK_SETB(cpu_online_map, cpu);
-			num_cpus++;
-			/*
-			 * Wait this cpu to start up and initialize its hub,
-			 * and discover the io devices it will control.
-			 *
-			 * XXX: We really want to fire up launch all the CPUs
-			 * at once.  We have to preserve the order of the
-			 * devices on the bridges first though.
-			 */
-			while(atomic_read(&numstarted) != num_cpus);
-		}
+		/*
+		 * We can't use kernel_thread since we must avoid to
+		 * reschedule the child.
+		 */
+		if (fork_by_hand() < 0)
+			panic("failed fork for CPU %d", num_cpus);
+
+		/*
+		 * We remove it from the pidhash and the runqueue
+		 * once we got the process:
+		 */
+		idle = init_task.prev_task;
+		if (!idle)
+			panic("No idle process for CPU %d", num_cpus);
+
+		idle->processor = num_cpus;
+		idle->cpus_runnable = 1 << cpu; /* we schedule the first task manually */
+
+		alloc_cpupda(cpu, num_cpus);
+
+		idle->thread.reg31 = (unsigned long) start_secondary;
+
+		del_from_runqueue(idle);
+		unhash_process(idle);
+		init_tasks[num_cpus] = idle;
+
+		/*
+	 	 * Launch a slave into smp_bootstrap().
+	 	 * It doesn't take an argument, and we
+		 * set sp to the kernel stack of the newly
+		 * created idle process, gp to the proc struct
+		 * (so that current-> works).
+	 	 */
+		LAUNCH_SLAVE(cputonasid(num_cpus),cputoslice(num_cpus),
+			(launch_proc_t)MAPPED_KERN_RW_TO_K0(smp_bootstrap),
+			0, (void *)((unsigned long)idle +
+			KERNEL_STACK_SIZE - 32), (void *)idle);
+
+		/*
+		 * Now optimistically set the mapping arrays. We
+		 * need to wait here, verify the cpu booted up, then
+		 * fire up the next cpu.
+		 */
+		__cpu_number_map[cpu] = num_cpus;
+		__cpu_logical_map[num_cpus] = cpu;
+		CPUMASK_SETB(cpu_online_map, cpu);
+		num_cpus++;
+		/*
+		 * Wait this cpu to start up and initialize its hub,
+		 * and discover the io devices it will control.
+		 *
+		 * XXX: We really want to fire up launch all the CPUs
+		 * at once.  We have to preserve the order of the
+		 * devices on the bridges first though.
+		 */
+		while(atomic_read(&numstarted) != num_cpus);
 	}
-
 
 #ifdef LATER
 	Wait logic goes here.
diff -u -r1.1.2.3 ip27-setup.c
--- arch/mips/sgi-ip27/ip27-setup.c 21 Sep 2002 21:15:23 -0000
+++ arch/mips/sgi-ip27/ip27-setup.c 18 Nov 2002 04:30:06 -0000
@@ -311,6 +311,6 @@
 	ioc3_eth_init();
 	per_cpu_init();
 
-	mips_io_port_base = IO_BASE;
+	set_io_port_base(IO_BASE);
 	board_time_init = ip27_time_init;
 }
diff -u -r1.1.2.2 ip27-timer.c
--- arch/mips/sgi-ip27/ip27-timer.c 5 Aug 2002 23:53:35 -0000
+++ arch/mips/sgi-ip27/ip27-timer.c 18 Nov 2002 04:30:06 -0000
@@ -1,5 +1,5 @@
 /*
- * Copytight (C) 1999, 2000 Ralf Baechle (ralf@gnu.org)
+ * Copytight (C) 1999, 2000, 2002 Ralf Baechle (ralf@gnu.org)
  * Copytight (C) 1999, 2000 Silicon Graphics, Inc.
  */
 #include <linux/config.h>
@@ -88,11 +88,13 @@
 	return retval;
 }
 
+#define IP27_TIMER_IRQ	9			/* XXX Assign number */
+
 void rt_timer_interrupt(struct pt_regs *regs)
 {
 	int cpu = smp_processor_id();
 	int cpuA = ((cputoslice(cpu)) == 0);
-	int irq = 9;				/* XXX Assign number */
+	int irq = IP27_TIMER_IRQ;
 
 	irq_enter(cpu, irq);
 	write_lock(&xtime_lock);
@@ -157,7 +159,7 @@
 
 static __init unsigned long get_m48t35_time(void)
 {
-        unsigned int year, month, date, hour, min, sec;
+	unsigned int year, month, date, hour, min, sec;
 	struct m48t35_rtc *rtc;
 	nasid_t nid;
 
@@ -174,16 +176,25 @@
 	year = rtc->year;
 	rtc->control &= ~M48T35_RTC_READ;
 
-        BCD_TO_BIN(sec);
-        BCD_TO_BIN(min);
-        BCD_TO_BIN(hour);
-        BCD_TO_BIN(date);
-        BCD_TO_BIN(month);
-        BCD_TO_BIN(year);
+	BCD_TO_BIN(sec);
+	BCD_TO_BIN(min);
+	BCD_TO_BIN(hour);
+	BCD_TO_BIN(date);
+	BCD_TO_BIN(month);
+	BCD_TO_BIN(year);
+
+	year += 1970;
+
+	return mktime(year, month, date, hour, min, sec);
+}
 
-        year += 1970;
+static void ip27_timer_setup(struct irqaction *irq)
+{
+	/* over-write the handler, we use our own way */
+	irq->handler = no_action;
 
-        return mktime(year, month, date, hour, min, sec);
+	/* setup irqaction */
+//	setup_irq(IP27_TIMER_IRQ, irq);		/* XXX Can't do this yet.  */
 }
 
 void __init ip27_time_init(void)
@@ -192,6 +203,9 @@
 	xtime.tv_usec = 0;
 
 	do_gettimeoffset = ip27_do_gettimeoffset;
+
+	// board_time_init = ip27_time_init;
+	board_timer_setup = ip27_timer_setup;
 }
 
 void __init cpu_time_init(void)
diff -u -r1.2.2.5 smp.c
--- arch/mips/sibyte/sb1250/smp.c 28 Sep 2002 22:28:38 -0000
+++ arch/mips/sibyte/sb1250/smp.c 18 Nov 2002 04:30:06 -0000
@@ -129,9 +129,6 @@
 		p->processor = i;
 		p->cpus_runnable = 1 << i; /* we schedule the first task manually */
 
-		/* Attach to the address space of init_task. */
-		atomic_inc(&init_mm.mm_count);
-		p->active_mm = &init_mm;
 		init_tasks[i] = p;
 
 		del_from_runqueue(p);
diff -u -r1.22.2.19 Makefile
--- arch/mips64/Makefile 12 Nov 2002 02:14:50 -0000
+++ arch/mips64/Makefile 18 Nov 2002 04:30:07 -0000
@@ -215,7 +215,7 @@
 # ELF files from 32-bit files by conversion.
 #
 ifdef CONFIG_BOOT_ELF64
-GCCFLAGS += -Wa,-32 $(shell if $(CC) $(1) -c -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
+GCCFLAGS += -Wa,-32 $(shell if $(CC) -Wa,-mgp64 -c -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "-Wa,-mgp64"; fi)
 LINKFLAGS += -T arch/mips64/ld.script.elf32
 #AS += -64
 #LD += -m elf64bmip
@@ -238,9 +238,9 @@
 MAKEBOOT = $(MAKE) -C arch/$(ARCH)/boot
 
 ifdef CONFIG_CPU_LITTLE_ENDIAN
-64bit-bfd = elf64-littlemips
+64bit-bfd = elf64-tradlittlemips
 else
-64bit-bfd = elf64-bigmips
+64bit-bfd = elf64-tradbigmips
 endif
 
 vmlinux: arch/mips64/ld.script.elf32
@@ -249,10 +249,10 @@
 
 ifdef CONFIG_MAPPED_KERNEL
 vmlinux.64: vmlinux
-	$(OBJCOPY) -O $(64bit-bfd) --change-addresses=0xbfffffff40000000 $< $@
+	$(OBJCOPY) -O $(64bit-bfd) --remove-section=.reginfo --change-addresses=0xbfffffff40000000 $< $@
 else
 vmlinux.64: vmlinux
-	$(OBJCOPY) -O $(64bit-bfd) --change-addresses=0xa7ffffff80000000 $< $@
+	$(OBJCOPY) -O $(64bit-bfd) --remove-section=.reginfo --change-addresses=0xa800000080000000 $< $@
 endif
 
 zImage: vmlinux
diff -u -r1.31.2.21 setup.c
--- arch/mips64/kernel/setup.c 25 Oct 2002 23:01:17 -0000
+++ arch/mips64/kernel/setup.c 18 Nov 2002 04:30:08 -0000
@@ -278,6 +278,7 @@
 	start_pfn = PFN_UP(CPHYSADDR(&_end));
 #endif	/* CONFIG_BLK_DEV_INITRD */
 
+#ifndef CONFIG_SGI_IP27
 	/* Find the highest page frame number we have available.  */
 	max_pfn = 0;
 	for (i = 0; i < boot_mem_map.nr_map; i++) {
@@ -342,6 +343,7 @@
 
 	/* Reserve the bootmap memory.  */
 	reserve_bootmem(PFN_PHYS(start_pfn), bootmap_size);
+#endif
 
 #ifdef CONFIG_BLK_DEV_INITRD
 	/* Board specific code should have set up initrd_start and initrd_end */
diff -u -r1.30.2.35 traps.c
--- arch/mips64/kernel/traps.c 4 Nov 2002 19:39:56 -0000
+++ arch/mips64/kernel/traps.c 18 Nov 2002 04:30:09 -0000
@@ -686,6 +686,12 @@
 	cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
 	set_context(((long)(&pgd_current[cpu])) << 23);
 	set_wired(0);
+
+	atomic_inc(&init_mm.mm_count);
+	current->active_mm = &init_mm;
+	if (current->mm)
+		BUG();
+	enter_lazy_tlb(&init_mm, current, cpu);
 }
 
 void __init trap_init(void)
diff -u -r1.25.2.14 io.h
--- include/asm-mips64/io.h 28 Sep 2002 22:28:38 -0000
+++ include/asm-mips64/io.h 18 Nov 2002 04:30:31 -0000
@@ -330,7 +330,7 @@
 
 #define outw(val,port)							\
 do {									\
-	*(volatile u16 *)(mips_io_port_base + (port)) = __ioswab16(val);\
+	*(volatile u16 *)(mips_io_port_base + (port ^ 2)) = __ioswab16(val);\
 } while(0)
 
 #define outl(val,port)							\
@@ -346,7 +346,7 @@
 
 #define outw_p(val,port)						\
 do {									\
-	*(volatile u16 *)(mips_io_port_base + (port)) = __ioswab16(val);\
+	*(volatile u16 *)(mips_io_port_base + (port ^ 2)) = __ioswab16(val);\
 	SLOW_DOWN_IO;							\
 } while(0)
 
@@ -363,7 +363,7 @@
 
 static inline unsigned short inw(unsigned long port)
 {
-	return __ioswab16(*(volatile u16 *)(mips_io_port_base + port));
+	return __ioswab16(*(volatile u16 *)(mips_io_port_base + (port ^ 2)));
 }
 
 static inline unsigned int inl(unsigned long port)
@@ -385,7 +385,7 @@
 {
 	u16 __val;
 
-	__val = *(volatile u16 *)(mips_io_port_base + port);
+	__val = *(volatile u16 *)(mips_io_port_base + (port ^ 2));
 	SLOW_DOWN_IO;
 
 	return __ioswab16(__val);
diff -u -r1.10.2.14 page.h
--- include/asm-mips64/page.h 30 Sep 2002 17:00:03 -0000
+++ include/asm-mips64/page.h 18 Nov 2002 04:30:31 -0000
@@ -115,7 +115,7 @@
 #endif
 #if defined(CONFIG_SGI_IP27)
 #define PAGE_OFFSET	0xa800000000000000UL
-#define UNCAC_BASE	0x9000000000000000UL
+#define UNCAC_BASE	0x9600000000000000UL
 #endif
 #if defined(CONFIG_SIBYTE_SB1250)
 #define PAGE_OFFSET	0xa800000000000000UL
diff -u -r1.2.2.1 addrs.h
--- include/asm-mips64/sn/sn0/addrs.h 27 Jun 2002 14:21:24 -0000
+++ include/asm-mips64/sn/sn0/addrs.h 18 Nov 2002 04:30:32 -0000
@@ -45,11 +45,11 @@
 #define HSPEC_BASE		0x9000000000000000
 #define IO_BASE			0x9200000000000000
 #define MSPEC_BASE		0x9400000000000000
-#define UNCAC_BASE		0x9600000000000000
+#define __UNCAC_BASE		0x9600000000000000
 
 #define TO_PHYS(x)		(	      ((x) & TO_PHYS_MASK))
 #define TO_CAC(x)		(CAC_BASE   | ((x) & TO_PHYS_MASK))
-#define TO_UNCAC(x)		(UNCAC_BASE | ((x) & TO_PHYS_MASK))
+#define TO_UNCAC(x)		(__UNCAC_BASE | ((x) & TO_PHYS_MASK))
 #define TO_MSPEC(x)		(MSPEC_BASE | ((x) & TO_PHYS_MASK))
 #define TO_HSPEC(x)		(HSPEC_BASE | ((x) & TO_PHYS_MASK))
 

From bmdimaculangan@bhpi.com.ph Mon Nov 18 05:51:50 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 05:51:51 +0100 (CET)
Received: from [202.58.253.178] ([202.58.253.178]:49817 "EHLO
	makati.bhpi.com.ph") by linux-mips.org with ESMTP
	id <S1124241AbSKREvu>; Mon, 18 Nov 2002 05:51:50 +0100
Received: from bmd (unknown [192.168.0.15])
	by makati.bhpi.com.ph (Postfix) with SMTP id 1C1591FFCF
	for <linux-mips@linux-mips.org>; Mon, 18 Nov 2002 12:10:28 +0800 (PHT)
From: "BMDimaculangan" <bmdimaculangan@bhpi.com.ph>
To: <linux-mips@linux-mips.org>
Subject: 
Date: Mon, 18 Nov 2002 12:58:45 +0800
Message-ID: <MEEKKAPIMDJAJLIOBCHCEEJACCAA.bmdimaculangan@bhpi.com.ph>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20021118053935.A25428@linux-mips.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <bmdimaculangan@bhpi.com.ph>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 660
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bmdimaculangan@bhpi.com.ph
Precedence: bulk
X-list: linux-mips

UNSUBSCRIBED

From kevink@mips.com Mon Nov 18 09:55:46 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 09:55:47 +0100 (CET)
Received: from mx2.mips.com ([206.31.31.227]:19646 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1123966AbSKRIzq>;
	Mon, 18 Nov 2002 09:55:46 +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 gAI8tUNf002200;
	Mon, 18 Nov 2002 00:55:30 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA11678;
	Mon, 18 Nov 2002 00:55:34 -0800 (PST)
Message-ID: <007301c28ee0$cb2eb6d0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralph Metzler" <rjkm@metzlerbros.de>,
	"Bob Lund" <bob.lund@visi.com>
Cc: <linux-mips@linux-mips.org>
References: <01cd01c28e57$21f37ee0$0a00000a@blund> <15832.25401.226111.893020@gargle.gargle.HOWL>
Subject: Re: Linux on LSI SC2005
Date: Mon, 18 Nov 2002 09:58:15 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.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: 661
X-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

From: "Ralph Metzler" <rjkm@metzlerbros.de>
> Hi, 
> 
> Bob Lund writes:
>  > I'm trying to figure out how much effort would be involved in getting Linux
>  > running on the MIPS core found in the LSI Logic SC2005. According to the LSI
>  > documentation:
>  > 
>  > MIPS R3000 CPU, executing MIPS I & II and 16 instructions
>  > BBCC with four write back buffers included
>  > Two 32-bit timers
>  > MMU 64-entry TLB RAM
>  > 1 to 32 Kbytes of direct mapped or 2 to 64 Kbytes of set associative I-cache
>  > 1 to 32 Kbytes of direct mapped D-cache
>  > 
>  > Any information is appreciated.
> 
> I did some work on an SC2000 about 18 months ago but only for one or two
> weeks. The kernel and networking on the eval board was basically
> working then but, AFAIR, there were problems (as in total lock up) with 
> enabled cache in user mode. Without cache it was veeeeery slow.

I don't have documentation on the SC2000, so I had hesitated
to respond to the question, but I can at least make the general
comment that LSI put a lot of different cache and MMU designs
around the basic R3000 execution pipe.  Some of those were
close enough to the original R3000 design to be easily supported
by Linux, others less so.  The MMU is the nastiest part of the problem,
so if you managed to get Linux running uncached, I am more
optimistic than I would otherwise be.  The LSI cores for which
I do have documantation use a non-standard mechanism
(an explicit cache control register in the System Coprocessor)
for cache management.  I would not be surprised if the SC2000
used much the same techniques, and if so, it would be necessary
to either hack up arch/mips/mm/c-r3k.c or (better software
engineering but more work) create arch/mips/mm/c-sc2k.c
with the SC2000 cache manipulation routines and add the
necessary configuration hooks to use it for your build.

            Kevin K.

From atulsrivastava9@rediffmail.com Mon Nov 18 12:43:55 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 12:43:55 +0100 (CET)
Received: from [203.199.83.247] ([203.199.83.247]:40144 "HELO
	mailweb34.rediffmail.com") by linux-mips.org with SMTP
	id <S1123974AbSKRLnz>; Mon, 18 Nov 2002 12:43:55 +0100
Received: (qmail 22527 invoked by uid 510); 18 Nov 2002 11:43:17 -0000
Date: 18 Nov 2002 11:43:17 -0000
Message-ID: <20021118114317.22526.qmail@mailweb34.rediffmail.com>
Received: from unknown (203.197.184.93) by rediffmail.com via HTTP; 18 Nov 2002 11:43:17 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: -mips2 amd -mcpu=r4600 for Rc32334..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 662
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello,

here is a quick question ..?

what should be appropiate compilation flag for MIPS 
RC32134/Rc32334..?
currently i am trying in arch/mips/Makefile
  GCCFLAGS        += -mcpu=r4600 -mips2 -Wa,--trap

But I doubt it for two reasons.

1.I think mips1 should be used instead of mips2 because
if you follow mips literature mips 2* and 3* series fall under 
MIPS1 category.
4* and bigger series comes under MIP2 and MIPS3 series.

for example CONFIG_CPU_LLSC is not enabled for all MIPS1
category processors.

2.Is -mcpu=r4600 switch is alright for Rc32334?
I was just wondering why i should use -mcpu=r4600 for RC323334


Best Regards,
Atul
__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/


From ralf@linux-mips.org Mon Nov 18 13:34:56 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 13:34:56 +0100 (CET)
Received: from p508B75AF.dip.t-dialin.net ([80.139.117.175]:32912 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1124127AbSKRMe4>; Mon, 18 Nov 2002 13:34:56 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAICYd111074;
	Mon, 18 Nov 2002 13:34:39 +0100
Date: Mon, 18 Nov 2002 13:34:39 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: -mips2 amd -mcpu=r4600 for Rc32334..?
Message-ID: <20021118133438.A4988@linux-mips.org>
References: <20021118114317.22526.qmail@mailweb34.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021118114317.22526.qmail@mailweb34.rediffmail.com>; from atulsrivastava9@rediffmail.com on Mon, Nov 18, 2002 at 11:43:17AM -0000
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: 663
X-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, Nov 18, 2002 at 11:43:17AM -0000, atul srivastava wrote:

> what should be appropiate compilation flag for MIPS 
> RC32134/Rc32334..?
> currently i am trying in arch/mips/Makefile
>   GCCFLAGS        += -mcpu=r4600 -mips2 -Wa,--trap
> 
> But I doubt it for two reasons.
> 
> 1.I think mips1 should be used instead of mips2 because
> if you follow mips literature mips 2* and 3* series fall under 
> MIPS1 category.

Exceptions such at the R3900 which is an almost-mips2 processor ...

> 4* and bigger series comes under MIP2 and MIPS3 series.
> 
> for example CONFIG_CPU_LLSC is not enabled for all MIPS1
> category processors.

CONFIG_CPU_LLSC is mandatory for for multiprocessor systems.  For uni-
processor systems such as your's CONFIG_CPU_LLSC should be enabled for
best performance - but only if your CPU actually has ll / sc instructions.

The kernel emulates ll/sc instructions if they're not available in
hardware.  The emulation is not performance optimal so should be avoided
by using the appropriate setting of CONFIG_CPU_LLSC.

> 2.Is -mcpu=r4600 switch is alright for Rc32334?

Not knowing the Rc32334 in detail I can only tell you the switch is
technically correct.  It may or may not be optimal.

> I was just wondering why i should use -mcpu=r4600 for RC323334

-mcpu=<cpu> is just a performance optimization option.  Gcc doesn't use
this value very well to optimize the code but it's making some minor
difference.  For most <cpu> values the code generator doesn't use
instructions that are specific to CPU, so there's little risk playing
with the value.  Gcc doesn't know the Rc32334 as value so you'll have to
pick a CPU that is as similar possible.

  Ralf

From kevink@mips.com Mon Nov 18 14:20:42 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 14:20:43 +0100 (CET)
Received: from mx2.mips.com ([206.31.31.227]:46792 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1123974AbSKRNUm>;
	Mon, 18 Nov 2002 14:20:42 +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 gAIDKSNf003314
	for <linux-mips@linux-mips.org>; Mon, 18 Nov 2002 05:20:28 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA19818
	for <linux-mips@linux-mips.org>; Mon, 18 Nov 2002 05:20:29 -0800 (PST)
Message-ID: <015201c28f05$cb583800$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: <linux-mips@linux-mips.org>
Subject: Alignment of FP Context Storage
Date: Mon, 18 Nov 2002 14:24:06 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.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: 664
X-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

I'm cleaning up some old Linux kernel sandboxes, and
came across a patch which I had long ago made in a
local copy of include/asm-mips/processor.h but which
does not seem to have been propagated more widely.
I had added "__attribute__((aligned(8))))" to the
declarations of the mips_fpu_hard_struct and
mips_fpu_soft_struct data structures, presumably
because there was a need to ensure 64-bit alignment
of the elements so that LDC1 instructions would work.
We don't generally have a problem here, presumably
because either the previous data declarations naturally
align things to 64-bits, or because we've ensured things 
at a higher level of makfile compiler directives.  Are we 
in fact guarnateed to be safe without the source code 
directive, or should those __attribute__ directives be 
added as insurance?

            Kevin K.

From ralf@linux-mips.org Mon Nov 18 14:34:04 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 14:34:05 +0100 (CET)
Received: from p508B75AF.dip.t-dialin.net ([80.139.117.175]:61072 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1123974AbSKRNeE>; Mon, 18 Nov 2002 14:34:04 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAIDXrB12216;
	Mon, 18 Nov 2002 14:33:53 +0100
Date: Mon, 18 Nov 2002 14:33:53 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Alignment of FP Context Storage
Message-ID: <20021118143353.A12096@linux-mips.org>
References: <015201c28f05$cb583800$10eca8c0@grendel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <015201c28f05$cb583800$10eca8c0@grendel>; from kevink@mips.com on Mon, Nov 18, 2002 at 02:24:06PM +0100
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: 665
X-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, Nov 18, 2002 at 02:24:06PM +0100, Kevin D. Kissell wrote:

> I'm cleaning up some old Linux kernel sandboxes, and
> came across a patch which I had long ago made in a
> local copy of include/asm-mips/processor.h but which
> does not seem to have been propagated more widely.
> I had added "__attribute__((aligned(8))))" to the
> declarations of the mips_fpu_hard_struct and
> mips_fpu_soft_struct data structures, presumably
> because there was a need to ensure 64-bit alignment
> of the elements so that LDC1 instructions would work.
> We don't generally have a problem here, presumably
> because either the previous data declarations naturally
> align things to 64-bits, or because we've ensured things 
> at a higher level of makfile compiler directives.  Are we 
> in fact guarnateed to be safe without the source code 
> directive, or should those __attribute__ directives be 
> added as insurance?

The definition of mips_cpu_hard_struct uses doubles which is ensuring
mips_fpu_hard_struct will have 64-bit alignment.  This is actually part
of thread_struct which itself has 8kB alignment on 32-bit and 16kB
alignment on 64-bit.

  Ralf

From ralf@linux-mips.org Mon Nov 18 14:42:20 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 14:42:21 +0100 (CET)
Received: from p508B75AF.dip.t-dialin.net ([80.139.117.175]:65424 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1123974AbSKRNmU>; Mon, 18 Nov 2002 14:42:20 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAIDgCm12364
	for linux-mips@linux-mips.org; Mon, 18 Nov 2002 14:42:12 +0100
Date: Mon, 18 Nov 2002 14:42:12 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Origin patches, take 2
Message-ID: <20021118144212.A12262@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 666
X-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

Take two on the Origin patches.  This patch pulls the broken IOC3 patches
which somebody from SGI sneaked to Linus making the IO3 ethernet driver
close to unusable ...

This is a fairly dirty patchkit to revive the port.  I'm posting it here
because these patches are quite quick'n'dirty and various people have
been flooding my mailbox during the past time with requests for Origin
kernels.

The serial console is still seriously missbehaving; fixing that is the
last big to do item before the port is fully usable again.

  Ralf

diff -u -r1.99.2.32 traps.c
--- arch/mips/kernel/traps.c 4 Nov 2002 19:39:56 -0000
+++ arch/mips/kernel/traps.c 18 Nov 2002 11:43:14 -0000
@@ -909,6 +909,12 @@
 
 	cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
 	set_context(cpu << 23);
+
+	atomic_inc(&init_mm.mm_count);
+	current->active_mm = &init_mm;
+	if (current->mm)
+		BUG();
+	enter_lazy_tlb(&init_mm, current, cpu);
 }
 
 void __init trap_init(void)
diff -u -r1.1.2.3 ip27-console.c
--- arch/mips/sgi-ip27/ip27-console.c 7 Nov 2002 01:47:45 -0000
+++ arch/mips/sgi-ip27/ip27-console.c 18 Nov 2002 11:43:15 -0000
@@ -9,6 +9,7 @@
 #include <linux/console.h>
 #include <linux/kdev_t.h>
 #include <linux/major.h>
+#include <asm/page.h>
 #include <asm/sn/addrs.h>
 #include <asm/sn/sn0/hub.h>
 #include <asm/sn/klconfig.h>
@@ -45,11 +46,11 @@
 }
 
 static struct console ip27_prom_console = {
-    .name	= "prom",
-    .write	= ip27prom_console_write,
-    .device	= ip27prom_console_dev,
-    .flags	= CON_PRINTBUFFER,
-    .index	= -1,
+	.name	= "prom",
+	.write	= ip27prom_console_write,
+	.device	= ip27prom_console_dev,
+	.flags	= CON_PRINTBUFFER,
+	.index	= -1,
 };
 
 __init void ip27_setup_console(void)
diff -u -r1.1.2.3 ip27-init.c
--- arch/mips/sgi-ip27/ip27-init.c 28 Sep 2002 22:28:38 -0000
+++ arch/mips/sgi-ip27/ip27-init.c 18 Nov 2002 11:43:16 -0000
@@ -424,6 +424,8 @@
 
 void __init start_secondary(void)
 {
+	extern atomic_t smp_commenced;
+
 	CPUMASK_CLRB(boot_barrier, getcpuid());	/* needs atomicity */
 	per_cpu_init();
 	per_cpu_trap_init();
@@ -435,7 +437,20 @@
 	local_flush_tlb_all();
 	flush_cache_l1();
 	flush_cache_l2();
-	start_secondary();
+
+	smp_callin();
+	while (!atomic_read(&smp_commenced));
+	return cpu_idle();
+}
+
+static int __init fork_by_hand(void)
+{
+	struct pt_regs regs;
+	/*
+	 * don't care about the epc and regs settings since
+	 * we'll never reschedule the forked task.
+	 */
+	return do_fork(CLONE_VM|CLONE_PID, 0, &regs, 0);
 }
 
 __init void allowboot(void)
@@ -457,6 +472,8 @@
 	boot_barrier = boot_cpumask;
 	/* Launch slaves. */
 	for (cpu = 0; cpu < maxcpus; cpu++) {
+		struct task_struct *idle;
+
 		if (cpu == mycpuid) {
 			alloc_cpupda(cpu, num_cpus);
 			num_cpus++;
@@ -466,59 +483,66 @@
 		}
 
 		/* Skip holes in CPU space */
-		if (CPUMASK_TSTB(boot_cpumask, cpu)) {
-			struct task_struct *p;
+		if (!CPUMASK_TSTB(boot_cpumask, cpu))
+			continue;
 
-			/*
-			 * The following code is purely to make sure
-			 * Linux can schedule processes on this slave.
-			 */
-			kernel_thread(0, NULL, CLONE_PID);
-			p = init_task.prev_task;
-			sprintf(p->comm, "%s%d", "Idle", num_cpus);
-			init_tasks[num_cpus] = p;
-			alloc_cpupda(cpu, num_cpus);
-			del_from_runqueue(p);
-			p->processor = num_cpus;
-			p->cpus_runnable = 1 << num_cpus; /* we schedule the first task manually */
-			unhash_process(p);
-			/* Attach to the address space of init_task. */
-			atomic_inc(&init_mm.mm_count);
-			p->active_mm = &init_mm;
-
-			/*
-		 	 * Launch a slave into smp_bootstrap().
-		 	 * It doesn't take an argument, and we
-			 * set sp to the kernel stack of the newly
-			 * created idle process, gp to the proc struct
-			 * (so that current-> works).
-		 	 */
-			LAUNCH_SLAVE(cputonasid(num_cpus),cputoslice(num_cpus),
-				(launch_proc_t)MAPPED_KERN_RW_TO_K0(smp_bootstrap),
-				0, (void *)((unsigned long)p +
-				KERNEL_STACK_SIZE - 32), (void *)p);
-
-			/*
-			 * Now optimistically set the mapping arrays. We
-			 * need to wait here, verify the cpu booted up, then
-			 * fire up the next cpu.
-			 */
-			__cpu_number_map[cpu] = num_cpus;
-			__cpu_logical_map[num_cpus] = cpu;
-			CPUMASK_SETB(cpu_online_map, cpu);
-			num_cpus++;
-			/*
-			 * Wait this cpu to start up and initialize its hub,
-			 * and discover the io devices it will control.
-			 *
-			 * XXX: We really want to fire up launch all the CPUs
-			 * at once.  We have to preserve the order of the
-			 * devices on the bridges first though.
-			 */
-			while(atomic_read(&numstarted) != num_cpus);
-		}
+		/*
+		 * We can't use kernel_thread since we must avoid to
+		 * reschedule the child.
+		 */
+		if (fork_by_hand() < 0)
+			panic("failed fork for CPU %d", num_cpus);
+
+		/*
+		 * We remove it from the pidhash and the runqueue
+		 * once we got the process:
+		 */
+		idle = init_task.prev_task;
+		if (!idle)
+			panic("No idle process for CPU %d", num_cpus);
+
+		idle->processor = num_cpus;
+		idle->cpus_runnable = 1 << cpu; /* we schedule the first task manually */
+
+		alloc_cpupda(cpu, num_cpus);
+
+		idle->thread.reg31 = (unsigned long) start_secondary;
+
+		del_from_runqueue(idle);
+		unhash_process(idle);
+		init_tasks[num_cpus] = idle;
+
+		/*
+	 	 * Launch a slave into smp_bootstrap().
+	 	 * It doesn't take an argument, and we
+		 * set sp to the kernel stack of the newly
+		 * created idle process, gp to the proc struct
+		 * (so that current-> works).
+	 	 */
+		LAUNCH_SLAVE(cputonasid(num_cpus),cputoslice(num_cpus),
+			(launch_proc_t)MAPPED_KERN_RW_TO_K0(smp_bootstrap),
+			0, (void *)((unsigned long)idle +
+			KERNEL_STACK_SIZE - 32), (void *)idle);
+
+		/*
+		 * Now optimistically set the mapping arrays. We
+		 * need to wait here, verify the cpu booted up, then
+		 * fire up the next cpu.
+		 */
+		__cpu_number_map[cpu] = num_cpus;
+		__cpu_logical_map[num_cpus] = cpu;
+		CPUMASK_SETB(cpu_online_map, cpu);
+		num_cpus++;
+		/*
+		 * Wait this cpu to start up and initialize its hub,
+		 * and discover the io devices it will control.
+		 *
+		 * XXX: We really want to fire up launch all the CPUs
+		 * at once.  We have to preserve the order of the
+		 * devices on the bridges first though.
+		 */
+		while(atomic_read(&numstarted) != num_cpus);
 	}
-
 
 #ifdef LATER
 	Wait logic goes here.
diff -u -r1.1.2.3 ip27-rtc.c
--- arch/mips/sgi-ip27/ip27-rtc.c 7 Nov 2002 01:47:45 -0000
+++ arch/mips/sgi-ip27/ip27-rtc.c 18 Nov 2002 11:43:17 -0000
@@ -61,7 +61,6 @@
 #define RTC_TIMER_ON		0x02	/* missed irq timer active	*/
 
 static unsigned char rtc_status;	/* bitmapped status byte.	*/
-static spinlock_t rtc_status_lock = SPIN_LOCK_UNLOCKED;
 static unsigned long rtc_freq;	/* Current periodic IRQ rate	*/
 static struct m48t35_rtc *rtc;
 
@@ -125,10 +124,7 @@
 		if ((yrs -= epoch) > 255)    /* They are unsigned */
 			return -EINVAL;
 
-		save_flags(flags);
-		cli();
 		if (yrs > 169) {
-			restore_flags(flags);
 			return -EINVAL;
 		}
 		if (yrs >= 100)
@@ -141,6 +137,7 @@
 		BIN_TO_BCD(mon);
 		BIN_TO_BCD(yrs);
 
+		spin_lock_irq(&rtc_lock);
 		rtc->control &= ~M48T35_RTC_SET;
 		rtc->year = yrs;
 		rtc->month = mon;
@@ -149,8 +146,8 @@
 		rtc->min = min;
 		rtc->sec = sec;
 		rtc->control &= ~M48T35_RTC_SET;
+		spin_unlock_irq(&rtc_lock);
 
-		restore_flags(flags);
 		return 0;
 	}
 	default:
@@ -167,15 +164,15 @@
 
 static int rtc_open(struct inode *inode, struct file *file)
 {
-	spin_lock(rtc_status_lock);
+	spin_lock_irq(rtc_lock);
 
 	if (rtc_status & RTC_IS_OPEN) {
-		spin_unlock(rtc_status_lock);
+		spin_unlock_irq(rtc_status_lock);
 		return -EBUSY;
 	}
 
 	rtc_status |= RTC_IS_OPEN;
-	spin_unlock(rtc_status_lock);
+	spin_unlock_irq(rtc_lock);
 
 	return 0;
 }
@@ -187,9 +184,9 @@
 	 * in use, and clear the data.
 	 */
 
-	spin_lock(rtc_status_lock);
+	spin_lock_irq(rtc_lock);
 	rtc_status &= ~RTC_IS_OPEN;
-	spin_unlock(rtc_status_lock);
+	spin_unlock_irq(rtc_lock);
 
 	return 0;
 }
@@ -226,9 +223,6 @@
 		return -ENODEV;
 	create_proc_read_entry ("rtc", 0, NULL, rtc_read_proc, NULL);
 
-	save_flags(flags);
-	cli();
-	restore_flags(flags);
 	rtc_freq = 1024;
 	return 0;
 }
@@ -304,8 +298,7 @@
 	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
 	 * by the RTC when initially set to a non-zero value.
 	 */
-	save_flags(flags);
-	cli();
+	spin_lock_irq(&rtc_lock);
         rtc->control |= M48T35_RTC_READ;
 	rtc_tm->tm_sec = rtc->sec;
 	rtc_tm->tm_min = rtc->min;
@@ -314,7 +307,7 @@
 	rtc_tm->tm_mon = rtc->month;
 	rtc_tm->tm_year = rtc->year;
 	rtc->control &= ~M48T35_RTC_READ;
-	restore_flags(flags);
+	spin_unlock_irq(&rtc_lock);
 
 	BCD_TO_BIN(rtc_tm->tm_sec);
 	BCD_TO_BIN(rtc_tm->tm_min);
diff -u -r1.1.2.3 ip27-setup.c
--- arch/mips/sgi-ip27/ip27-setup.c 21 Sep 2002 21:15:23 -0000
+++ arch/mips/sgi-ip27/ip27-setup.c 18 Nov 2002 11:43:17 -0000
@@ -311,6 +311,6 @@
 	ioc3_eth_init();
 	per_cpu_init();
 
-	mips_io_port_base = IO_BASE;
+	set_io_port_base(IO_BASE);
 	board_time_init = ip27_time_init;
 }
diff -u -r1.1.2.2 ip27-timer.c
--- arch/mips/sgi-ip27/ip27-timer.c 5 Aug 2002 23:53:35 -0000
+++ arch/mips/sgi-ip27/ip27-timer.c 18 Nov 2002 11:43:21 -0000
@@ -1,5 +1,5 @@
 /*
- * Copytight (C) 1999, 2000 Ralf Baechle (ralf@gnu.org)
+ * Copytight (C) 1999, 2000, 2002 Ralf Baechle (ralf@gnu.org)
  * Copytight (C) 1999, 2000 Silicon Graphics, Inc.
  */
 #include <linux/config.h>
@@ -55,6 +55,7 @@
 	rtc = (struct m48t35_rtc *)(KL_CONFIG_CH_CONS_INFO(nid)->memory_base +
 							IOC3_BYTEBUS_DEV0);
 
+	spin_lock(&rtc_lock);
 	rtc->control |= M48T35_RTC_READ;
 	cmos_minutes = rtc->min;
 	BCD_TO_BIN(cmos_minutes);
@@ -84,15 +85,18 @@
 		       cmos_minutes, real_minutes);
 		retval = -1;
 	}
+	spin_unlock(&rtc_lock);
 
 	return retval;
 }
 
+#define IP27_TIMER_IRQ	9			/* XXX Assign number */
+
 void rt_timer_interrupt(struct pt_regs *regs)
 {
 	int cpu = smp_processor_id();
 	int cpuA = ((cputoslice(cpu)) == 0);
-	int irq = 9;				/* XXX Assign number */
+	int irq = IP27_TIMER_IRQ;
 
 	irq_enter(cpu, irq);
 	write_lock(&xtime_lock);
@@ -157,7 +161,7 @@
 
 static __init unsigned long get_m48t35_time(void)
 {
-        unsigned int year, month, date, hour, min, sec;
+	unsigned int year, month, date, hour, min, sec;
 	struct m48t35_rtc *rtc;
 	nasid_t nid;
 
@@ -165,6 +169,7 @@
 	rtc = (struct m48t35_rtc *)(KL_CONFIG_CH_CONS_INFO(nid)->memory_base +
 							IOC3_BYTEBUS_DEV0);
 
+	spin_lock(&rtc_lock);
 	rtc->control |= M48T35_RTC_READ;
 	sec = rtc->sec;
 	min = rtc->min;
@@ -173,17 +178,27 @@
 	month = rtc->month;
 	year = rtc->year;
 	rtc->control &= ~M48T35_RTC_READ;
+	spin_unlock(&rtc_lock);
+
+	BCD_TO_BIN(sec);
+	BCD_TO_BIN(min);
+	BCD_TO_BIN(hour);
+	BCD_TO_BIN(date);
+	BCD_TO_BIN(month);
+	BCD_TO_BIN(year);
+
+	year += 1970;
 
-        BCD_TO_BIN(sec);
-        BCD_TO_BIN(min);
-        BCD_TO_BIN(hour);
-        BCD_TO_BIN(date);
-        BCD_TO_BIN(month);
-        BCD_TO_BIN(year);
+	return mktime(year, month, date, hour, min, sec);
+}
 
-        year += 1970;
+static void ip27_timer_setup(struct irqaction *irq)
+{
+	/* over-write the handler, we use our own way */
+	irq->handler = no_action;
 
-        return mktime(year, month, date, hour, min, sec);
+	/* setup irqaction */
+//	setup_irq(IP27_TIMER_IRQ, irq);		/* XXX Can't do this yet.  */
 }
 
 void __init ip27_time_init(void)
@@ -192,6 +207,9 @@
 	xtime.tv_usec = 0;
 
 	do_gettimeoffset = ip27_do_gettimeoffset;
+
+	// board_time_init = ip27_time_init;
+	board_timer_setup = ip27_timer_setup;
 }
 
 void __init cpu_time_init(void)
diff -u -r1.2.2.5 smp.c
--- arch/mips/sibyte/sb1250/smp.c 28 Sep 2002 22:28:38 -0000
+++ arch/mips/sibyte/sb1250/smp.c 18 Nov 2002 11:43:21 -0000
@@ -129,9 +129,6 @@
 		p->processor = i;
 		p->cpus_runnable = 1 << i; /* we schedule the first task manually */
 
-		/* Attach to the address space of init_task. */
-		atomic_inc(&init_mm.mm_count);
-		p->active_mm = &init_mm;
 		init_tasks[i] = p;
 
 		del_from_runqueue(p);
diff -u -r1.22.2.19 Makefile
--- arch/mips64/Makefile 12 Nov 2002 02:14:50 -0000
+++ arch/mips64/Makefile 18 Nov 2002 11:43:21 -0000
@@ -215,7 +215,7 @@
 # ELF files from 32-bit files by conversion.
 #
 ifdef CONFIG_BOOT_ELF64
-GCCFLAGS += -Wa,-32 $(shell if $(CC) $(1) -c -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
+GCCFLAGS += -Wa,-32 $(shell if $(CC) -Wa,-mgp64 -c -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "-Wa,-mgp64"; fi)
 LINKFLAGS += -T arch/mips64/ld.script.elf32
 #AS += -64
 #LD += -m elf64bmip
@@ -238,9 +238,9 @@
 MAKEBOOT = $(MAKE) -C arch/$(ARCH)/boot
 
 ifdef CONFIG_CPU_LITTLE_ENDIAN
-64bit-bfd = elf64-littlemips
+64bit-bfd = elf64-tradlittlemips
 else
-64bit-bfd = elf64-bigmips
+64bit-bfd = elf64-tradbigmips
 endif
 
 vmlinux: arch/mips64/ld.script.elf32
@@ -249,10 +249,10 @@
 
 ifdef CONFIG_MAPPED_KERNEL
 vmlinux.64: vmlinux
-	$(OBJCOPY) -O $(64bit-bfd) --change-addresses=0xbfffffff40000000 $< $@
+	$(OBJCOPY) -O $(64bit-bfd) --remove-section=.reginfo --change-addresses=0xbfffffff40000000 $< $@
 else
 vmlinux.64: vmlinux
-	$(OBJCOPY) -O $(64bit-bfd) --change-addresses=0xa7ffffff80000000 $< $@
+	$(OBJCOPY) -O $(64bit-bfd) --remove-section=.reginfo --change-addresses=0xa800000080000000 $< $@
 endif
 
 zImage: vmlinux
diff -u -r1.73.2.22 defconfig
--- arch/mips64/defconfig 8 Nov 2002 01:39:44 -0000
+++ arch/mips64/defconfig 18 Nov 2002 11:43:21 -0000
@@ -49,8 +49,8 @@
 # CONFIG_SGI_IP22 is not set
 CONFIG_SGI_IP27=y
 # CONFIG_SGI_SN0_N_MODE is not set
-CONFIG_DISCONTIGMEM=y
-CONFIG_NUMA=y
+# CONFIG_DISCONTIGMEM is not set
+# CONFIG_NUMA is not set
 # CONFIG_MAPPED_KERNEL is not set
 # CONFIG_REPLICATE_KTEXT is not set
 # CONFIG_REPLICATE_EXHANDLERS is not set
@@ -473,8 +473,8 @@
 # CONFIG_BEFS_FS is not set
 # CONFIG_BEFS_DEBUG is not set
 # CONFIG_BFS_FS is not set
-# CONFIG_EXT3_FS is not set
-# CONFIG_JBD is not set
+CONFIG_EXT3_FS=y
+CONFIG_JBD=y
 # CONFIG_JBD_DEBUG is not set
 # CONFIG_FAT_FS is not set
 # CONFIG_MSDOS_FS is not set
diff -u -r1.67.2.22 defconfig-ip27
--- arch/mips64/defconfig-ip27 8 Nov 2002 01:39:44 -0000
+++ arch/mips64/defconfig-ip27 18 Nov 2002 11:43:21 -0000
@@ -49,8 +49,8 @@
 # CONFIG_SGI_IP22 is not set
 CONFIG_SGI_IP27=y
 # CONFIG_SGI_SN0_N_MODE is not set
-CONFIG_DISCONTIGMEM=y
-CONFIG_NUMA=y
+# CONFIG_DISCONTIGMEM is not set
+# CONFIG_NUMA is not set
 # CONFIG_MAPPED_KERNEL is not set
 # CONFIG_REPLICATE_KTEXT is not set
 # CONFIG_REPLICATE_EXHANDLERS is not set
@@ -473,8 +473,8 @@
 # CONFIG_BEFS_FS is not set
 # CONFIG_BEFS_DEBUG is not set
 # CONFIG_BFS_FS is not set
-# CONFIG_EXT3_FS is not set
-# CONFIG_JBD is not set
+CONFIG_EXT3_FS=y
+CONFIG_JBD=y
 # CONFIG_JBD_DEBUG is not set
 # CONFIG_FAT_FS is not set
 # CONFIG_MSDOS_FS is not set
diff -u -r1.11.2.12 Makefile
--- arch/mips64/kernel/Makefile 7 Nov 2002 18:01:32 -0000
+++ arch/mips64/kernel/Makefile 18 Nov 2002 11:43:21 -0000
@@ -12,7 +12,7 @@
 
 O_TARGET := kernel.o
 
-export-objs	= irq.o mips64_ksyms.o pci-dma.o setup.o smp.o
+export-objs	= irq.o mips64_ksyms.o pci-dma.o setup.o smp.o time.o
 
 obj-y		:= branch.o cpu-probe.o entry.o irq.o proc.o process.o \
 		   ptrace.o r4k_cache.o r4k_fpu.o r4k_genex.o r4k_switch.o \
diff -u -r1.31.2.21 setup.c
--- arch/mips64/kernel/setup.c 25 Oct 2002 23:01:17 -0000
+++ arch/mips64/kernel/setup.c 18 Nov 2002 11:43:21 -0000
@@ -278,6 +278,7 @@
 	start_pfn = PFN_UP(CPHYSADDR(&_end));
 #endif	/* CONFIG_BLK_DEV_INITRD */
 
+#ifndef CONFIG_SGI_IP27
 	/* Find the highest page frame number we have available.  */
 	max_pfn = 0;
 	for (i = 0; i < boot_mem_map.nr_map; i++) {
@@ -342,6 +343,7 @@
 
 	/* Reserve the bootmap memory.  */
 	reserve_bootmem(PFN_PHYS(start_pfn), bootmap_size);
+#endif
 
 #ifdef CONFIG_BLK_DEV_INITRD
 	/* Board specific code should have set up initrd_start and initrd_end */
diff -u -r1.1.2.6 time.c
--- arch/mips64/kernel/time.c 31 Oct 2002 19:50:14 -0000
+++ arch/mips64/kernel/time.c 18 Nov 2002 11:43:28 -0000
@@ -21,6 +21,7 @@
 #include <linux/kernel_stat.h>
 #include <linux/spinlock.h>
 #include <linux/interrupt.h>
+#include <linux/module.h>
 
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
@@ -38,6 +39,8 @@
 extern rwlock_t xtime_lock;
 extern volatile unsigned long wall_jiffies;
 
+spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
+
 /*
  * whether we emulate local_timer_interrupts for SMP machines.
  */
@@ -580,3 +583,5 @@
 	 */
 	tm->tm_wday = (gday + 4) % 7; /* 1970/1/1 was Thursday */
 }
+
+EXPORT_SYMBOL(rtc_lock);
diff -u -r1.30.2.35 traps.c
--- arch/mips64/kernel/traps.c 4 Nov 2002 19:39:56 -0000
+++ arch/mips64/kernel/traps.c 18 Nov 2002 11:43:28 -0000
@@ -686,6 +686,12 @@
 	cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
 	set_context(((long)(&pgd_current[cpu])) << 23);
 	set_wired(0);
+
+	atomic_inc(&init_mm.mm_count);
+	current->active_mm = &init_mm;
+	if (current->mm)
+		BUG();
+	enter_lazy_tlb(&init_mm, current, cpu);
 }
 
 void __init trap_init(void)
diff -u -r1.56.2.6 ioc3-eth.c
--- drivers/net/ioc3-eth.c 7 Nov 2002 01:47:46 -0000
+++ drivers/net/ioc3-eth.c 18 Nov 2002 11:43:39 -0000
@@ -26,7 +26,6 @@
  *    which workarounds are required for them?  Do we ever have Lucent's?
  *  o For the 2.5 branch kill the mii-tool ioctls.
  */
-#include <linux/config.h>
 #include <linux/init.h>
 #include <linux/delay.h>
 #include <linux/kernel.h>
@@ -34,7 +33,6 @@
 #include <linux/errno.h>
 #include <linux/module.h>
 #include <linux/pci.h>
-#include <linux/crc32.h>
 
 #ifdef CONFIG_SERIAL
 #include <linux/serial.h>
@@ -342,15 +340,14 @@
 }
 
 /*
- * Read the NIC (Number-In-a-Can) device used to store the MAC address on
- * SN0 / SN00 nodeboards and PCI cards.
+ * Read the NIC (Number-In-a-Can) device.
  */
-static void ioc3_get_eaddr_nic(struct ioc3_private *ip)
+static void ioc3_get_eaddr(struct ioc3_private *ip)
 {
 	struct ioc3 *ioc3 = ip->regs;
 	u8 nic[14];
-	int tries = 2; /* There may be some problem with the battery?  */
 	int i;
+	int tries = 2; /* There may be some problem with the battery?  */
 
 	ioc3_w(gpcr_s, (1 << 21));
 
@@ -373,123 +370,16 @@
 	for (i = 13; i >= 0; i--)
 		nic[i] = nic_read_byte(ioc3);
 
-	for (i = 2; i < 8; i++)
-		ip->dev->dev_addr[i - 2] = nic[i];
-}
-
-#if defined(CONFIG_IA64_SGI_SN1) || defined(CONFIG_IA64_SGI_SN2)
-/*
- * Get the ether-address on SN1 nodes
- */
-static void ioc3_get_eaddr_sn(struct ioc3_private *ip)
-{
-	int ibrick_mac_addr_get(nasid_t, char *);
-	struct ioc3 *ioc3 = ip->regs;
-	nasid_t nasid_of_ioc3;
-	char io7eaddr[20];
-	long mac;
-	int err_val;
-
-	/*
-	 * err_val = ibrick_mac_addr_get(get_nasid(), io7eaddr );
-	 * 
-	 * BAD!!  The above call uses get_nasid() and assumes that
-	 * the ioc3 pointed to by struct ioc3 is hooked up to the
-	 * cbrick that we're running on.  The proper way to make this call
-	 * is to figure out which nasid the ioc3 is connected to
-	 * and use that to call ibrick_mac_addr_get.  Below is
-	 * a hack to do just that.
-	 */
-
-	/*
-	 * Get the nasid of the ioc3 from the ioc3's base addr.
-	 * FIXME: the 8 at the end assumes we're in memory mode, 
-	 * not node mode (for that, we'd change it to a 9).
-	 * Is there a call to extract this info from a physical
-	 * addr somewhere in an sn header file already?  If so,
-	 * we should probably use that, or restructure this routine
-	 * to use pci_dev and generic numa nodeid getting stuff.
-	 */
-	nasid_of_ioc3 = (((unsigned long)ioc3 >> 33) & ~(-1 << 8));
-	err_val = ibrick_mac_addr_get(nasid_of_ioc3, io7eaddr );
-
-
-	if (err_val) {
-		/* Couldn't read the eeprom; try OSLoadOptions. */
-		printk("WARNING: ibrick_mac_addr_get failed: %d\n", err_val);
-
-		/* this is where we hardwire the mac address
- 		 * 1st ibrick had 08:00:69:11:34:75
- 		 * 2nd ibrick had 08:00:69:11:35:35
- 		 *
- 		 * Eagan Machines:
- 		 *      mankato1 08:00:69:11:BE:95
- 		 *      warroad  08:00:69:11:bd:60
- 		 *      duron    08:00:69:11:34:60
- 		 *
- 		 * an easy way to get the mac address is to hook
- 		 * up an ip35, then from L1 do 'cti serial'
- 		 * and then look for MAC line XXX THIS DOESN"T QUITE WORK!!
- 		 */
-		printk("ioc3_get_eaddr: setting ethernet address to:\n -----> ");
-		ip->dev->dev_addr[0] = 0x8;
-		ip->dev->dev_addr[1] = 0x0;
-		ip->dev->dev_addr[2] = 0x69;
-		ip->dev->dev_addr[3] = 0x11;
-		ip->dev->dev_addr[4] = 0x34;
-		ip->dev->dev_addr[5] = 0x60;
-	}
-	else {
-		long simple_strtol(const char *,char **,unsigned int);
-
-		mac = simple_strtol(io7eaddr, (char **)0, 16);
-		ip->dev->dev_addr[0] = (mac >> 40) & 0xff;
-		ip->dev->dev_addr[1] = (mac >> 32) & 0xff;
-		ip->dev->dev_addr[2] = (mac >> 24) & 0xff;
-		ip->dev->dev_addr[3] = (mac >> 16) & 0xff;
-		ip->dev->dev_addr[4] = (mac >> 8) & 0xff;
-		ip->dev->dev_addr[5] = mac & 0xff;
-	}
-}
-#endif
-
-/*
- * Ok, this is hosed by design.  It's necessary to know what machine the
- * NIC is in in order to know how to read the NIC address.  We also have
- * to know if it's a PCI card or a NIC in on the node board ...
- */
-static void ioc3_get_eaddr(struct ioc3_private *ip)
-{
-	void (*do_get_eaddr)(struct ioc3_private *ip) = NULL;
-	int i;
-
-	/*
-	 * We should also use this code for PCI cards, no matter what host
-	 * machine but how to know that we're a PCI card?
-	 */
-#ifdef CONFIG_SGI_IP27
-	do_get_eaddr = ioc3_get_eaddr_nic;
-#endif
-#if defined(CONFIG_IA64_SGI_SN1) || defined(CONFIG_IA64_SGI_SN2)
-	do_get_eaddr = ioc3_get_eaddr_sn;
-#endif
-
-	if (!do_get_eaddr) {
-		printk(KERN_ERR "Don't know how to read MAC address of this "
-		       "IOC3 NIC\n");
-		return;
-	}
-
 	printk("Ethernet address is ");
-	for (i = 0; i < 6; i++) {
-		printk("%02x", ip->dev->dev_addr[i]);
+	for (i = 2; i < 8; i++) {
+		ip->dev->dev_addr[i - 2] = nic[i];
+		printk("%02x", nic[i]);
 		if (i < 7)
 			printk(":");
 	}
 	printk(".\n");
 }
 
-
 /*
  * Caller must hold the ioc3_lock ever for MII readers.  This is also
  * used to protect the transmitter side but it's low contention.
@@ -544,10 +434,10 @@
 
 	skb = ip->rx_skbs[rx_entry];
 	rxb = (struct ioc3_erxbuf *) (skb->data - RX_OFFSET);
-	w0 = be32_to_cpu(rxb->w0);
+	w0 = rxb->w0;
 
 	while (w0 & ERXBUF_V) {
-		err = be32_to_cpu(rxb->err);		/* It's valid ...  */
+		err = rxb->err;				/* It's valid ...  */
 		if (err & ERXBUF_GOODPKT) {
 			len = ((w0 >> ERXBUF_BYTECNT_SHIFT) & 0x7ff) - 4;
 			skb_trim(skb, len);
@@ -588,8 +478,8 @@
 			ip->stats.rx_frame_errors++;
 next:
 		ip->rx_skbs[n_entry] = new_skb;
-		rxr[n_entry] = cpu_to_be32((0xa5UL << 56) |
-		                         ((unsigned long) rxb & TO_PHYS_MASK));
+		rxr[n_entry] = (0xa5UL << 56) |
+		                ((unsigned long) rxb & TO_PHYS_MASK);
 		rxb->w0 = 0;				/* Clear valid flag */
 		n_entry = (n_entry + 1) & 511;		/* Update erpir */
 
@@ -597,7 +487,7 @@
 		rx_entry = (rx_entry + 1) & 511;
 		skb = ip->rx_skbs[rx_entry];
 		rxb = (struct ioc3_erxbuf *) (skb->data - RX_OFFSET);
-		w0 = be32_to_cpu(rxb->w0);
+		w0 = rxb->w0;
 	}
 	ioc3->erpir = (n_entry << 3) | ERPIR_ARM;
 	ip->rx_pi = n_entry;
@@ -1299,8 +1189,8 @@
 			/* Because we reserve afterwards. */
 			skb_put(skb, (1664 + RX_OFFSET));
 			rxb = (struct ioc3_erxbuf *) skb->data;
-			rxr[i] = cpu_to_be64((0xa5UL << 56) |
-			                ((unsigned long) rxb & TO_PHYS_MASK));
+			rxr[i] = (0xa5UL << 56)
+				| ((unsigned long) rxb & TO_PHYS_MASK);
 			skb_reserve(skb, RX_OFFSET);
 		}
 		ip->rx_ci = 0;
@@ -1622,10 +1512,10 @@
 MODULE_DEVICE_TABLE(pci, ioc3_pci_tbl);
 
 static struct pci_driver ioc3_driver = {
-	.name		= "ioc3-eth",
-	.id_table	= ioc3_pci_tbl,
-	.probe		= ioc3_probe,
-	.remove		= __devexit_p(ioc3_remove_one),
+	name:		"ioc3-eth",
+	id_table:	ioc3_pci_tbl,
+	probe:		ioc3_probe,
+	remove:		__devexit_p(ioc3_remove_one),
 };
 
 static int __init ioc3_init_module(void)
@@ -1664,8 +1554,8 @@
 			memset(desc->data + len, 0, ETH_ZLEN - len);
 			len = ETH_ZLEN;
 		}
-		desc->cmd    = cpu_to_be32(len | ETXD_INTWHENDONE | ETXD_D0V);
-		desc->bufcnt = cpu_to_be32(len);
+		desc->cmd    = len | ETXD_INTWHENDONE | ETXD_D0V;
+		desc->bufcnt = len;
 	} else if ((data ^ (data + len)) & 0x4000) {
 		unsigned long b2, s1, s2;
 
@@ -1673,20 +1563,16 @@
 		s1 = b2 - data;
 		s2 = data + len - b2;
 
-		desc->cmd    = cpu_to_be32(len | ETXD_INTWHENDONE |
-		                           ETXD_B1V | ETXD_B2V);
-		desc->bufcnt = cpu_to_be32((s1 << ETXD_B1CNT_SHIFT)
-		                           | (s2 << ETXD_B2CNT_SHIFT));
-		desc->p1     = cpu_to_be64((0xa5UL << 56) |
-                                           (data & TO_PHYS_MASK));
-		desc->p2     = cpu_to_be64((0xa5UL << 56) |
-		                           (data & TO_PHYS_MASK));
+		desc->cmd    = len | ETXD_INTWHENDONE | ETXD_B1V | ETXD_B2V;
+		desc->bufcnt = (s1 << ETXD_B1CNT_SHIFT) |
+		               (s2 << ETXD_B2CNT_SHIFT);
+		desc->p1     = (0xa5UL << 56) | (data & TO_PHYS_MASK);
+		desc->p2     = (0xa5UL << 56) | (data & TO_PHYS_MASK);
 	} else {
 		/* Normal sized packet that doesn't cross a page boundary. */
-		desc->cmd    = cpu_to_be32(len | ETXD_INTWHENDONE | ETXD_B1V);
-		desc->bufcnt = cpu_to_be32(len << ETXD_B1CNT_SHIFT);
-		desc->p1     = cpu_to_be64((0xa5UL << 56) |
-		                           (data & TO_PHYS_MASK));
+		desc->cmd    = len | ETXD_INTWHENDONE | ETXD_B1V;
+		desc->bufcnt = len << ETXD_B1CNT_SHIFT;
+		desc->p1     = (0xa5UL << 56) | (data & TO_PHYS_MASK);
 	}
 
 	BARRIER();
@@ -1725,16 +1611,27 @@
  * Given a multicast ethernet address, this routine calculates the
  * address's bit index in the logical address filter mask
  */
+#define CRC_MASK        0xedb88320
 
 static inline unsigned int
 ioc3_hash(const unsigned char *addr)
 {
 	unsigned int temp = 0;
 	unsigned char byte;
-	u32 crc;
-	int bits;
+	unsigned int crc;
+	int bits, len;
 
-	crc = ether_crc_le(ETH_ALEN, addr);
+	len = ETH_ALEN;
+	for (crc = ~0; --len >= 0; addr++) {
+		byte = *addr;
+		for (bits = 8; --bits >= 0; ) {
+			if ((byte ^ crc) & 1)
+				crc = (crc >> 1) ^ CRC_MASK;
+			else
+				crc >>= 1;
+			byte >>= 1;
+		}
+	}
 
 	crc &= 0x3f;    /* bit reverse lowest 6 bits for hash index */
 	for (bits = 6; --bits >= 0; ) {
@@ -1920,7 +1817,6 @@
 
 MODULE_AUTHOR("Ralf Baechle <ralf@oss.sgi.com>");
 MODULE_DESCRIPTION("SGI IOC3 Ethernet driver");
-MODULE_LICENSE("GPL");
 
 module_init(ioc3_init_module);
 module_exit(ioc3_cleanup_module);
diff -u -r1.25.2.14 io.h
--- include/asm-mips64/io.h 28 Sep 2002 22:28:38 -0000
+++ include/asm-mips64/io.h 18 Nov 2002 11:44:01 -0000
@@ -330,7 +330,7 @@
 
 #define outw(val,port)							\
 do {									\
-	*(volatile u16 *)(mips_io_port_base + (port)) = __ioswab16(val);\
+	*(volatile u16 *)(mips_io_port_base + (port ^ 2)) = __ioswab16(val);\
 } while(0)
 
 #define outl(val,port)							\
@@ -346,7 +346,7 @@
 
 #define outw_p(val,port)						\
 do {									\
-	*(volatile u16 *)(mips_io_port_base + (port)) = __ioswab16(val);\
+	*(volatile u16 *)(mips_io_port_base + (port ^ 2)) = __ioswab16(val);\
 	SLOW_DOWN_IO;							\
 } while(0)
 
@@ -363,7 +363,7 @@
 
 static inline unsigned short inw(unsigned long port)
 {
-	return __ioswab16(*(volatile u16 *)(mips_io_port_base + port));
+	return __ioswab16(*(volatile u16 *)(mips_io_port_base + (port ^ 2)));
 }
 
 static inline unsigned int inl(unsigned long port)
@@ -385,7 +385,7 @@
 {
 	u16 __val;
 
-	__val = *(volatile u16 *)(mips_io_port_base + port);
+	__val = *(volatile u16 *)(mips_io_port_base + (port ^ 2));
 	SLOW_DOWN_IO;
 
 	return __ioswab16(__val);
diff -u -r1.1 m48t35.h
--- include/asm-mips64/m48t35.h 18 Feb 2000 09:54:39 -0000
+++ include/asm-mips64/m48t35.h 18 Nov 2002 11:44:01 -0000
@@ -1,32 +1,30 @@
 /*
  *  Registers for the SGS-Thomson M48T35 Timekeeper RAM chip
  */
-
 #ifndef _ASM_M48T35_H
 #define _ASM_M48T35_H
 
+#include <linux/spinlock.h>
+
+extern spinlock_t rtc_lock;
+
 struct m48t35_rtc {
-        volatile u8         pad[0x7ff8];    /* starts at 0x7ff8 */
-        volatile u8         control;
-        volatile u8         sec;
-        volatile u8         min;
-        volatile u8         hour;
-        volatile u8         day;
-        volatile u8         date;
-        volatile u8         month;
-        volatile u8         year;
+	volatile u8	pad[0x7ff8];    /* starts at 0x7ff8 */
+	volatile u8	control;
+	volatile u8	sec;
+	volatile u8	min;
+	volatile u8	hour;
+	volatile u8	day;
+	volatile u8	date;
+	volatile u8	month;
+	volatile u8	year;
 };
 
-#define M48T35_RTC_SET      0x80
-#define M48T35_RTC_STOPPED  0x80
-#define M48T35_RTC_READ     0x40
-
-#ifndef BCD_TO_BIN
-#define BCD_TO_BIN(x)   ((x)=((x)&15) + ((x)>>4)*10)
-#endif
-
-#ifndef BIN_TO_BCD
-#define BIN_TO_BCD(x)   ((x)=(((x)/10)<<4) + (x)%10)
-#endif
+#define M48T35_RTC_SET		0x80
+#define M48T35_RTC_STOPPED	0x80
+#define M48T35_RTC_READ		0x40
+
+#define BCD_TO_BIN(x)		((x)=((x)&15) + ((x)>>4)*10)
+#define BIN_TO_BCD(x)		((x)=(((x)/10)<<4) + (x)%10)
 
-#endif
+#endif /* _ASM_M48T35_H */
diff -u -r1.10.2.14 page.h
--- include/asm-mips64/page.h 30 Sep 2002 17:00:03 -0000
+++ include/asm-mips64/page.h 18 Nov 2002 11:44:02 -0000
@@ -115,7 +115,7 @@
 #endif
 #if defined(CONFIG_SGI_IP27)
 #define PAGE_OFFSET	0xa800000000000000UL
-#define UNCAC_BASE	0x9000000000000000UL
+#define UNCAC_BASE	0x9600000000000000UL
 #endif
 #if defined(CONFIG_SIBYTE_SB1250)
 #define PAGE_OFFSET	0xa800000000000000UL
diff -u -r1.2.2.1 addrs.h
--- include/asm-mips64/sn/sn0/addrs.h 27 Jun 2002 14:21:24 -0000
+++ include/asm-mips64/sn/sn0/addrs.h 18 Nov 2002 11:44:06 -0000
@@ -45,11 +45,11 @@
 #define HSPEC_BASE		0x9000000000000000
 #define IO_BASE			0x9200000000000000
 #define MSPEC_BASE		0x9400000000000000
-#define UNCAC_BASE		0x9600000000000000
+#define __UNCAC_BASE		0x9600000000000000
 
 #define TO_PHYS(x)		(	      ((x) & TO_PHYS_MASK))
 #define TO_CAC(x)		(CAC_BASE   | ((x) & TO_PHYS_MASK))
-#define TO_UNCAC(x)		(UNCAC_BASE | ((x) & TO_PHYS_MASK))
+#define TO_UNCAC(x)		(__UNCAC_BASE | ((x) & TO_PHYS_MASK))
 #define TO_MSPEC(x)		(MSPEC_BASE | ((x) & TO_PHYS_MASK))
 #define TO_HSPEC(x)		(HSPEC_BASE | ((x) & TO_PHYS_MASK))
 

From flo@rfc822.org Mon Nov 18 20:30:43 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 20:30:44 +0100 (CET)
Received: from noose.gt.owl.de ([62.52.19.4]:39692 "HELO noose.gt.owl.de")
	by linux-mips.org with SMTP id <S1123974AbSKRTan>;
	Mon, 18 Nov 2002 20:30:43 +0100
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 57D0B860; Mon, 18 Nov 2002 20:30:36 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 7A6A7B2A7; Mon, 18 Nov 2002 20:27:20 +0100 (CET)
Date: Mon, 18 Nov 2002 20:27:20 +0100
From: Florian Lohoff <flo@rfc822.org>
To: Brian Murphy <brm@murphy.dk>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH 2.4] load average fix for lasat boards (timer interrupt handling fix)
Message-ID: <20021118192720.GD5702@paradigm.rfc822.org>
References: <E18DXAH-0002KJ-00@brian.localnet>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="u65IjBhB3TIa72Vp"
Content-Disposition: inline
In-Reply-To: <E18DXAH-0002KJ-00@brian.localnet>
User-Agent: Mutt/1.3.28i
Organization: rfc822 - pure communication
Return-Path: <flo@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: 667
X-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


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

On Sun, Nov 17, 2002 at 10:41:13PM +0100, Brian Murphy wrote:
> Hi Florian, Ralf,
> 	it seems the method of calling the new time code changed
> or it was wrong all along, This patch fixes the problem of the
> ksoftirqd running all the time on Lasat systems, can you apply
> Ralf?

Works like a charm - Ralf already applied and i am running the CVS
from an hour after that happily ...

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE92T8YUaz2rXW+gJcRAliTAKDONbnHH35draQCtRlO8jk1ziu4fgCgxhEQ
jC7ETKvFPOeLJYFXeCjc6C0=
=/lYv
-----END PGP SIGNATURE-----

--u65IjBhB3TIa72Vp--

From kwalker@broadcom.com Mon Nov 18 23:30:13 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Nov 2002 23:30:14 +0100 (CET)
Received: from [63.70.210.58] ([63.70.210.58]:8199 "EHLO mms1.broadcom.com")
	by linux-mips.org with ESMTP id <S1123974AbSKRWaN>;
	Mon, 18 Nov 2002 23:30:13 +0100
Received: from 63.70.210.1mms1.broadcom.com with ESMTP (Broadcom MMS1
 SMTP Relay (MMS v5.0)); Mon, 18 Nov 2002 14:29:27 -0800
X-Server-Uuid: C4EEB3B0-84E7-41AF-B685-DDB6986D9F7C
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 OAA26720; Mon, 18 Nov 2002 14:29:49 -0800 (PST)
Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by
 mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id
 gAIMTmER017892; Mon, 18 Nov 2002 14:29:48 -0800 (PST)
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 OAA23468; Mon,
 18 Nov 2002 14:29:48 -0800
Message-ID: <3DD969DC.DC6D31BA@broadcom.com>
Date: Mon, 18 Nov 2002 14:29:48 -0800
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
cc: "Ralf Baechle" <ralf@linux-mips.org>
Subject: strncpy etc.
X-WSS-ID: 11C7B64D857954-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: 668
X-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


Looks like a typo in include/asm-mips/string.h has strncpy returning the
wrong thing -- a pointer to the END of the destination string, rather
than the beginning of the destination string.

Patch for 2.4 is below:

Index: include/asm-mips/string.h
===================================================================
RCS file:
/projects/bbp/cvsroot/systemsw/linux/src/kernel/include/asm-mips/string.h,v
retrieving revision 1.6
diff -u -r1.6 string.h
--- string.h    2002/09/05 22:15:51     1.6
+++ string.h    2002/11/18 22:27:15
@@ -67,7 +67,7 @@
         : "0" (__dest), "1" (__src), "2" (__n)
         : "memory");
 
-  return __dest;
+  return __xdest;
 }
 
 #define __HAVE_ARCH_STRCMP


From kevin@gv.com.tw Tue Nov 19 13:08:58 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Nov 2002 13:08:59 +0100 (CET)
Received: from p508B6EFA.dip.t-dialin.net ([80.139.110.250]:16334 "EHLO
	p508B6EFA.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122117AbSKSMI6>; Tue, 19 Nov 2002 13:08:58 +0100
Received: from c135.h203149222.is.net.tw ([IPv6:::ffff:203.149.222.135]:50340
	"EHLO ms.gv.com.tw") by ralf.linux-mips.org with ESMTP
	id <S868471AbSKSMCt>; Tue, 19 Nov 2002 13:02:49 +0100
Received: from jmt (IDENT:root@[172.16.1.11])
	by ms.gv.com.tw (8.11.2/8.11.2) with SMTP id gAJCCtO22336;
	Tue, 19 Nov 2002 20:12:55 +0800
Message-ID: <00a901c28fc4$76ace700$df0210ac@gv.com.tw>
From: "??" <kevin@gv.com.tw>
To: "Ralf Baechle" <ralf@linux-mips.org>, <linux-mips@linux-mips.org>
References: <20021118144212.A12262@linux-mips.org>
Subject: usb hotplug function with linux mips kernel
Date: Tue, 19 Nov 2002 20:09:07 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <kevin@gv.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: 669
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevin@gv.com.tw
Precedence: bulk
X-list: linux-mips

dear all,

anyone successfully using usb hotplug function with linux mips kernel?

http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=102954820511328&w=2

best regards,



From ralf@linux-mips.org Tue Nov 19 13:29:34 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Nov 2002 13:29:35 +0100 (CET)
Received: from p508B6EFA.dip.t-dialin.net ([80.139.110.250]:10396 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122117AbSKSM3e>; Tue, 19 Nov 2002 13:29:34 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAJCTMp18057;
	Tue, 19 Nov 2002 13:29:22 +0100
Date: Tue, 19 Nov 2002 13:29:22 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: ?? <kevin@gv.com.tw>
Cc: linux-mips@linux-mips.org
Subject: Re: usb hotplug function with linux mips kernel
Message-ID: <20021119132922.A15266@linux-mips.org>
References: <20021118144212.A12262@linux-mips.org> <00a901c28fc4$76ace700$df0210ac@gv.com.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <00a901c28fc4$76ace700$df0210ac@gv.com.tw>; from kevin@gv.com.tw on Tue, Nov 19, 2002 at 08:09:07PM +0800
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: 670
X-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

Hello double questionmark ;-)

On Tue, Nov 19, 2002 at 08:09:07PM +0800, ?? wrote:

> anyone successfully using usb hotplug function with linux mips kernel?
> 
> http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=102954820511328&w=2

There is nothing in the USB code that should be MIPS specific.  Despite
what Tom suspects everything is fine.  32-bit kernel symbols always start
with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
function having been discarded by the linker.

  Ralf

From jsun@orion.mvista.com Tue Nov 19 18:54:51 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Nov 2002 18:54:51 +0100 (CET)
Received: from gateway-1237.mvista.com ([12.44.186.158]:23036 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S1122123AbSKSRyv>;
	Tue, 19 Nov 2002 18:54:51 +0100
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id gAJHsib26702;
	Tue, 19 Nov 2002 09:54:44 -0800
Date: Tue, 19 Nov 2002 09:54:44 -0800
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: ?? <kevin@gv.com.tw>, linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: usb hotplug function with linux mips kernel
Message-ID: <20021119095444.C18134@mvista.com>
References: <20021118144212.A12262@linux-mips.org> <00a901c28fc4$76ace700$df0210ac@gv.com.tw> <20021119132922.A15266@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: <20021119132922.A15266@linux-mips.org>; from ralf@linux-mips.org on Tue, Nov 19, 2002 at 01:29:22PM +0100
Return-Path: <jsun@orion.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: 671
X-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, Nov 19, 2002 at 01:29:22PM +0100, Ralf Baechle wrote:
> Hello double questionmark ;-)
> 
> On Tue, Nov 19, 2002 at 08:09:07PM +0800, ?? wrote:
> 
> > anyone successfully using usb hotplug function with linux mips kernel?
> > 
> > http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=102954820511328&w=2
> 
> There is nothing in the USB code that should be MIPS specific.  Despite
> what Tom suspects everything is fine.  32-bit kernel symbols always start
> with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
> function having been discarded by the linker.
>

Additional info:

USB has been working on MIPS for well over a year now.  There was a problem
early on due to non-coherent MIPS cache, but it was solved back then.

We have been using USB on global span IVR successfully.  Maybe there are
still some patches missing in linux-mips tree.  I will take a look later.

Jun 

From ppopov@mvista.com Tue Nov 19 19:00:55 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Nov 2002 19:00:56 +0100 (CET)
Received: from gateway-1237.mvista.com ([12.44.186.158]:22269 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S1122123AbSKSSAz>;
	Tue, 19 Nov 2002 19:00:55 +0100
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA22725;
	Tue, 19 Nov 2002 10:00:38 -0800
Subject: Re: usb hotplug function with linux mips kernel
From: Pete Popov <ppopov@mvista.com>
To: Jun Sun <jsun@mvista.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, ?? <kevin@gv.com.tw>,
	linux-mips@linux-mips.org
In-Reply-To: <20021119095444.C18134@mvista.com>
References: <20021118144212.A12262@linux-mips.org>
	<00a901c28fc4$76ace700$df0210ac@gv.com.tw>
	<20021119132922.A15266@linux-mips.org>  <20021119095444.C18134@mvista.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 19 Nov 2002 10:03:47 -0800
Message-Id: <1037729027.17678.112.camel@zeus.mvista.com>
Mime-Version: 1.0
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 672
X-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 Tue, 2002-11-19 at 09:54, Jun Sun wrote:
> On Tue, Nov 19, 2002 at 01:29:22PM +0100, Ralf Baechle wrote:
> > Hello double questionmark ;-)
> > 
> > On Tue, Nov 19, 2002 at 08:09:07PM +0800, ?? wrote:
> > 
> > > anyone successfully using usb hotplug function with linux mips kernel?
> > > 
> > > http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=102954820511328&w=2
> > 
> > There is nothing in the USB code that should be MIPS specific.  Despite
> > what Tom suspects everything is fine.  32-bit kernel symbols always start
> > with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
> > function having been discarded by the linker.
> >
> 
> Additional info:
> 
> USB has been working on MIPS for well over a year now.  There was a problem
> early on due to non-coherent MIPS cache, but it was solved back then.
> 
> We have been using USB on global span IVR successfully.  

... among many other mips boards.

> Maybe there are still some patches missing in linux-mips tree.  I will 
> take a look later.

Pete


From yoichi_yuasa@montavista.co.jp Wed Nov 20 03:53:27 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 03:53:27 +0100 (CET)
Received: from r-bu.iij4u.or.jp ([210.130.0.89]:27107 "EHLO r-bu.iij4u.or.jp")
	by linux-mips.org with ESMTP id <S1122123AbSKTCx0>;
	Wed, 20 Nov 2002 03:53:26 +0100
Received: from pudding ([202.216.29.50])
	by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id gAK2r6q27689;
	Wed, 20 Nov 2002 11:53:07 +0900 (JST)
Date: Wed, 20 Nov 2002 11:49:30 +0900
From: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
To: kevin@gv.com.tw
Cc: jsun@mvista.com, ralf@linux-mips.org, linux-mips@linux-mips.org,
	ppopov@mvista.com
Subject: Re: usb hotplug function with linux mips kernel
Message-Id: <20021120114930.117a78bb.yoichi_yuasa@montavista.co.jp>
In-Reply-To: <1037729027.17678.112.camel@zeus.mvista.com>
References: <20021118144212.A12262@linux-mips.org>
	<00a901c28fc4$76ace700$df0210ac@gv.com.tw>
	<20021119132922.A15266@linux-mips.org>
	<20021119095444.C18134@mvista.com>
	<1037729027.17678.112.camel@zeus.mvista.com>
Organization: MontaVista Software Japan, Inc.
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Wed__20_Nov_2002_11:49:30_+0900_08421100"
Return-Path: <yoichi_yuasa@montavista.co.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 673
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yoichi_yuasa@montavista.co.jp
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

--Multipart_Wed__20_Nov_2002_11:49:30_+0900_08421100
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

On 19 Nov 2002 10:03:47 -0800
Pete Popov <ppopov@mvista.com> wrote:

> On Tue, 2002-11-19 at 09:54, Jun Sun wrote:
> > On Tue, Nov 19, 2002 at 01:29:22PM +0100, Ralf Baechle wrote:
> > > Hello double questionmark ;-)
> > > 
> > > On Tue, Nov 19, 2002 at 08:09:07PM +0800, ?? wrote:
> > > 
> > > > anyone successfully using usb hotplug function with linux mips kernel?
> > > > 
> > > > http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=102954820511328&w=2
> > > 
> > > There is nothing in the USB code that should be MIPS specific.  Despite
> > > what Tom suspects everything is fine.  32-bit kernel symbols always start
> > > with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
> > > function having been discarded by the linker.
> > >
> > 
> > Additional info:
> > 
> > USB has been working on MIPS for well over a year now.  There was a problem
> > early on due to non-coherent MIPS cache, but it was solved back then.
> > 
> > We have been using USB on global span IVR successfully.  
> 
> ... among many other mips boards.
> 
> > Maybe there are still some patches missing in linux-mips tree.  I will 
> > take a look later.

I don't have a problem with current CVS tree(linux_2_4 tag) and a small patch.

I tested by the following system.
Hot plug is fine.

NEC VR4122(Eagle)
USB OCHI Controller
SanDisk SDDR-31
128MB CF

I attached a small patch.

Yoichi
--Multipart_Wed__20_Nov_2002_11:49:30_+0900_08421100
Content-Type: text/plain;
 name="usb.diff"
Content-Disposition: attachment;
 filename="usb.diff"
Content-Transfer-Encoding: 7bit

--- linux.orig/drivers/usb/hub.c	Thu Sep 12 13:09:25 2002
+++ linux/drivers/usb/hub.c	Wed Nov 20 11:43:34 2002
@@ -698,12 +698,6 @@
 		return;
 	}
 
-	if (usb_hub_port_debounce(hub, port)) {
-		err("connect-debounce failed, port %d disabled", port+1);
-		usb_hub_port_disable(hub, port);
-		return;
-	}
-
 	down(&usb_address0_sem);
 
 	tempstr = kmalloc(1024, GFP_KERNEL);

--Multipart_Wed__20_Nov_2002_11:49:30_+0900_08421100--

From umesh.suryawanshi@tatainfotech.com Wed Nov 20 04:14:14 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 04:14:14 +0100 (CET)
Received: from 180.tatainfotech.com ([203.124.134.180]:14819 "EHLO
	tilmax.tatainfotech.co.in") by linux-mips.org with ESMTP
	id <S1121744AbSKTDOO>; Wed, 20 Nov 2002 04:14:14 +0100
Received: from goamail.in.tatainfotech.com (IDENT:root@tilmax.tatainfotech.co.in [127.0.0.1])
	by tilmax.tatainfotech.co.in (8.11.0/8.11.0) with ESMTP id gAK3E1B09284
	for <linux-mips@linux-mips.org>; Wed, 20 Nov 2002 08:44:01 +0530
Received: from Administrator ([163.122.44.15])
	by goamail.in.tatainfotech.com (8.8.7/8.8.7) with SMTP id IAA05434
	for <linux-mips@linux-mips.org>; Wed, 20 Nov 2002 08:34:26 +0530
From: "Umesh Suryawanshi" <umesh.suryawanshi@tatainfotech.com>
To: <linux-mips@linux-mips.org>
Subject: IDT79S334A MIPS evaluation board 
Date: Wed, 20 Nov 2002 08:55:10 +0530
Message-ID: <NFBBLKAGHEEGPLCBPPCLOEHADEAA.umesh.suryawanshi@tatainfotech.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0011_01C29072.8822F8E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Return-Path: <umesh.suryawanshi@tatainfotech.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: 674
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: umesh.suryawanshi@tatainfotech.com
Precedence: bulk
X-list: linux-mips


This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C29072.8822F8E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Anybody has succsessfully booted IDT79S334 MIPS board with Linux? 
I trying to boot it using TFTP.
Please can you forward me that linux image ? 
Umesh Suryawanshi
Design and Development Engineer,
Embedded Technology Group
Tata Infotech, Goa 



------=_NextPart_000_0011_01C29072.8822F8E0
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D203501703-20112002>Anybody has=20
succsessfully booted IDT79S334 MIPS board with Linux? =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D203501703-20112002>I =
trying to boot it=20
using TFTP.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D203501703-20112002>Please =
can you=20
forward me that linux image ? </SPAN></FONT></DIV>
<P><FONT color=3D#0000ff size=3D2><STRONG>Umesh Suryawanshi<BR>Design =
and=20
Development Engineer,<BR>Embedded Technology Group<BR>Tata Infotech, Goa =

</STRONG></FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0011_01C29072.8822F8E0--


From kevin@gv.com.tw Wed Nov 20 04:25:03 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 04:25:04 +0100 (CET)
Received: from p508B4A7D.dip.t-dialin.net ([80.139.74.125]:41424 "EHLO
	p508B4A7D.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1121744AbSKTDZD>; Wed, 20 Nov 2002 04:25:03 +0100
Received: from c135.h203149222.is.net.tw ([IPv6:::ffff:203.149.222.135]:31952
	"EHLO ms.gv.com.tw") by ralf.linux-mips.org with ESMTP
	id <S868489AbSKTDSy>; Wed, 20 Nov 2002 04:18:54 +0100
Received: from jmt (IDENT:root@[172.16.1.11])
	by ms.gv.com.tw (8.11.2/8.11.2) with SMTP id gAK3SxO09178;
	Wed, 20 Nov 2002 11:28:59 +0800
Message-ID: <00ba01c29044$707cd400$df0210ac@gv.com.tw>
From: "??" <kevin@gv.com.tw>
To: "Jun Sun" <jsun@mvista.com>
Cc: "Ralf Baechle" <ralf@linux-mips.org>, "Fang Li" <fanky@gv.com.tw>,
	<linux-mips@linux-mips.org>
References: <20021118144212.A12262@linux-mips.org> <00a901c28fc4$76ace700$df0210ac@gv.com.tw> <20021119132922.A15266@linux-mips.org> <20021119095444.C18134@mvista.com>
Subject: Re: usb hotplug function with linux mips kernel
Date: Wed, 20 Nov 2002 11:25:13 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <kevin@gv.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: 675
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevin@gv.com.tw
Precedence: bulk
X-list: linux-mips

dear jun,
do you have the patch to fix "non-coherent MIPS cache"?
thanks in advanced!:)

and thanks you all who reply to this so quickly:)
btw, i don't mean usb not function with linux mips kernel
i mean using the "hotplug"-usb
support(http://linux-hotplug.sourceforge.net/?selected=usb) with linux mips
kernel

for example, after we plug in usb cable with a mips board,
the mips kernel try to execute "/sbin/hotplug" shell script,
then kernel wait_for_complete() for "/sbin/hotplug" with spin_lock_irq(),
the do_execve() of "/sbin/hotplug" return 0(successfully),
however, wait_for_complete() never return,
then kernel is reseted by hardware watchdog(timeout 3 secs)

we already trace this problem over a month,
but still can't figure out is it a userland
problem(cross-compiler/shell(bash))
or a problem with linux mips kernel

best regards,

----- Original Message -----
From: "Jun Sun" <jsun@mvista.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: "??" <kevin@gv.com.tw>; <linux-mips@linux-mips.org>; <jsun@mvista.com>
Sent: Wednesday, November 20, 2002 1:54 AM
Subject: Re: usb hotplug function with linux mips kernel


> On Tue, Nov 19, 2002 at 01:29:22PM +0100, Ralf Baechle wrote:
> > Hello double questionmark ;-)
> >
> > On Tue, Nov 19, 2002 at 08:09:07PM +0800, ?? wrote:
> >
> > > anyone successfully using usb hotplug function with linux mips kernel?
> > >
> > >
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=102954820511328&w=2
> >
> > There is nothing in the USB code that should be MIPS specific.  Despite
> > what Tom suspects everything is fine.  32-bit kernel symbols always
start
> > with 0xffffffff and the value of usbdevfs_cleanup is an artefact of the
> > function having been discarded by the linker.
> >
>
> Additional info:
>
> USB has been working on MIPS for well over a year now.  There was a
problem
> early on due to non-coherent MIPS cache, but it was solved back then.
>
> We have been using USB on global span IVR successfully.  Maybe there are
> still some patches missing in linux-mips tree.  I will take a look later.
>
> Jun


From kevin@gv.com.tw Wed Nov 20 04:50:35 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 04:50:35 +0100 (CET)
Received: from p508B4A7D.dip.t-dialin.net ([80.139.74.125]:46288 "EHLO
	p508B4A7D.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1121744AbSKTDuf>; Wed, 20 Nov 2002 04:50:35 +0100
Received: from c135.h203149222.is.net.tw ([IPv6:::ffff:203.149.222.135]:11221
	"EHLO ms.gv.com.tw") by ralf.linux-mips.org with ESMTP
	id <S868471AbSKTDo3>; Wed, 20 Nov 2002 04:44:29 +0100
Received: from jmt (IDENT:root@[172.16.1.11])
	by ms.gv.com.tw (8.11.2/8.11.2) with SMTP id gAK3sbO10732;
	Wed, 20 Nov 2002 11:54:37 +0800
Message-ID: <012e01c29048$0551fee0$df0210ac@gv.com.tw>
From: "??" <kevin@gv.com.tw>
To: "Yoichi Yuasa" <yoichi_yuasa@montavista.co.jp>
Cc: <jsun@mvista.com>, <ralf@linux-mips.org>,
	<linux-mips@linux-mips.org>, <ppopov@mvista.com>,
	"Fang Li" <fanky@gv.com.tw>
References: <20021118144212.A12262@linux-mips.org><00a901c28fc4$76ace700$df0210ac@gv.com.tw><20021119132922.A15266@linux-mips.org><20021119095444.C18134@mvista.com><1037729027.17678.112.camel@zeus.mvista.com> <20021120114930.117a78bb.yoichi_yuasa@montavista.co.jp>
Subject: Re: usb hotplug function with linux mips kernel
Date: Wed, 20 Nov 2002 11:50:51 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <kevin@gv.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: 676
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevin@gv.com.tw
Precedence: bulk
X-list: linux-mips

dear Yoichi,

thanks for your reply & patch
we are using kernel 2.4.18, after reading your patch,

we found there is no following section:
- if (usb_hub_port_debounce(hub, port)) {
-  err("connect-debounce failed, port %d disabled", port+1);
-  usb_hub_port_disable(hub, port);
-  return;
- }

but a following section: (mentioned redhat bug #23670)
>        /* Some low speed devices have problems with the quick delay, so */
>        /*  be a bit pessimistic with those devices. RHbug #23670 */
>       if (portstatus & USB_PORT_STAT_LOW_SPEED) {
>                wait_ms(400);
>                delay = HUB_LONG_RESET_TIME;
>        }

can we safely remove the above section?

best regards,

----- Original Message -----
From: "Yoichi Yuasa" <yoichi_yuasa@montavista.co.jp>
To: <kevin@gv.com.tw>
Cc: <jsun@mvista.com>; <ralf@linux-mips.org>; <linux-mips@linux-mips.org>;
<ppopov@mvista.com>
Sent: Wednesday, November 20, 2002 10:49 AM
Subject: Re: usb hotplug function with linux mips kernel


> Hi,
>
> On 19 Nov 2002 10:03:47 -0800
> Pete Popov <ppopov@mvista.com> wrote:
>
> > On Tue, 2002-11-19 at 09:54, Jun Sun wrote:
> > > On Tue, Nov 19, 2002 at 01:29:22PM +0100, Ralf Baechle wrote:
> > > > Hello double questionmark ;-)
> > > >
> > > > On Tue, Nov 19, 2002 at 08:09:07PM +0800, ?? wrote:
> > > >
> > > > > anyone successfully using usb hotplug function with linux mips
kernel?
> > > > >
> > > > >
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=102954820511328&w=2
> > > >
> > > > There is nothing in the USB code that should be MIPS specific.
Despite
> > > > what Tom suspects everything is fine.  32-bit kernel symbols always
start
> > > > with 0xffffffff and the value of usbdevfs_cleanup is an artefact of
the
> > > > function having been discarded by the linker.
> > > >
> > >
> > > Additional info:
> > >
> > > USB has been working on MIPS for well over a year now.  There was a
problem
> > > early on due to non-coherent MIPS cache, but it was solved back then.
> > >
> > > We have been using USB on global span IVR successfully.
> >
> > ... among many other mips boards.
> >
> > > Maybe there are still some patches missing in linux-mips tree.  I will
> > > take a look later.
>
> I don't have a problem with current CVS tree(linux_2_4 tag) and a small
patch.
>
> I tested by the following system.
> Hot plug is fine.
>
> NEC VR4122(Eagle)
> USB OCHI Controller
> SanDisk SDDR-31
> 128MB CF
>
> I attached a small patch.
>
> Yoichi


From kevink@mips.com Wed Nov 20 10:47:27 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 10:47:27 +0100 (CET)
Received: from mx2.mips.com ([206.31.31.227]:15243 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1121744AbSKTJr1>;
	Wed, 20 Nov 2002 10:47:27 +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 gAK9lENf014278;
	Wed, 20 Nov 2002 01:47:14 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA20772;
	Wed, 20 Nov 2002 01:47:11 -0800 (PST)
Message-ID: <007f01c2907a$58064150$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Umesh Suryawanshi" <umesh.suryawanshi@tatainfotech.com>,
	<linux-mips@linux-mips.org>
References: <NFBBLKAGHEEGPLCBPPCLOEHADEAA.umesh.suryawanshi@tatainfotech.com>
Subject: Re: IDT79S334A MIPS evaluation board 
Date: Wed, 20 Nov 2002 10:50:49 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.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: 677
X-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

> Anybody has succsessfully booted IDT79S334 MIPS board with Linux? 
> I trying to boot it using TFTP.
> Please can you forward me that linux image ? 

While not strictly speaking MIPS32-compatible processors,
the RC32334 will probably run a kernel configured with the
"MIPS32" processor option.  The trick is drivers for the board,
and in particular, support for the integrated PCI controller.
30 seconds searching the IDT web site (which you should 
really have done yourself before asking the question here a 
second time) turns up the following:

http://www.idt.com/news/Jun02/06_17_02_1.html

which announces Linux support for the 79S334 from
MontaVista.  I'm sure one of the MontaVista guys
will correct me if I'm wrong, but my understanding
is that the MontaVista Linux Professional Edition
is only available under a paid subscription program,
though after some period of time, a lot of their work
does find its way into the linux-mips.org repository.

So you can wait, you can pay, or you can roll up
your sleeves and start hacking driver code.  ;-)

            Kevin K.



From atulsrivastava9@rediffmail.com Wed Nov 20 11:47:05 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 11:47:06 +0100 (CET)
Received: from webmail36.rediffmail.com ([203.199.83.248]:31661 "HELO
	webmail36.rediffmail.com") by linux-mips.org with SMTP
	id <S1121744AbSKTKrF>; Wed, 20 Nov 2002 11:47:05 +0100
Received: (qmail 23927 invoked by uid 510); 20 Nov 2002 10:46:38 -0000
Date: 20 Nov 2002 10:46:38 -0000
Message-ID: <20021120104638.23926.qmail@webmail36.rediffmail.com>
Received: from unknown (202.54.89.83) by rediffmail.com via HTTP; 20 Nov 2002 10:46:38 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: epc status cause all are reported zero?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 678
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello all,

I have a wiered problem.

following is the Oops by kernel when it tries to exec the shell.

while loading /bin/sh it reads the elf_ex.e_entry as 0x4000b0 this 
address is confirmed by
mip-linux-objdump -S bin/sh after mount -o loop on my host.
$mips-linux-objdump -S ./sh

./sh:     file format elf32-bigmips

Disassembly of section .text:

00000000004000b0 <.text>:
   4000b0:	3c1c0fc1 	lui	$gp,0xfc1
   4000b4:	279c96e0 	addiu	$gp,$gp,-26912
   4000b8:	0399e021 	addu	$gp,$gp,$t9


During exec there is a page fault of 4000b0 but immediately after 
that i get another page fault 0f 0x0fc01788 and following register 
dump after it
fails to get a fixup address.

Unable to handle kernel paging request at virtual address 
0fc01788, epc == 00000Oops in fault.c:do_page_fault, line 230:
$0 : 00000000 00000000 00000000 00000000
$4 : 00007340 800f0474 00000000 801fa000
$8 : 00000000 00000000 00000000 4c696e75
$12: 78000000 00000000 00000000 00000000
$16: 00000000 00000000 00000000 00000000
$20: 00000000 00000000 00000000 00000000
$24: 00000000 00000000
$28: 6e652900 00000000 00000000 00000000
epc   : 00000000
Status: 00000000
Cause : 00000000
Process sh (pid: 1, stackpage=801fa000)


i am confused how come the epc status and cause register all are 
reported zero.
whether my regs ( pointer to struct pt_regs) is pointing somewhere 
else..?

secondly Is this a problem with shell or kernel..? may be 
somewhere the kernel is not checking the
validity of user space address and hence this problem..

to avoid any other posibilities i am running uncached.

any thought

Best Regards,
Atul



__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/


From kevink@mips.com Wed Nov 20 12:19:27 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 12:19:27 +0100 (CET)
Received: from ftp.mips.com ([206.31.31.227]:15757 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1121744AbSKTLT1>;
	Wed, 20 Nov 2002 12:19:27 +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 gAKBJENf014636;
	Wed, 20 Nov 2002 03:19:14 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA24136;
	Wed, 20 Nov 2002 03:19:12 -0800 (PST)
Message-ID: <00dc01c29087$319a3690$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "atul srivastava" <atulsrivastava9@rediffmail.com>
Cc: <linux-mips@linux-mips.org>
References: <20021120104638.23926.qmail@webmail36.rediffmail.com>
Subject: Re: epc status cause all are reported zero?
Date: Wed, 20 Nov 2002 12:23:02 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.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: 679
X-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

> During exec there is a page fault of 4000b0 but immediately after 
> that i get another page fault 0f 0x0fc01788 and following register 
> dump after it
> fails to get a fixup address.
> 
> Unable to handle kernel paging request at virtual address 
> 0fc01788, epc == 00000Oops in fault.c:do_page_fault, line 230:
> $0 : 00000000 00000000 00000000 00000000
> $4 : 00007340 800f0474 00000000 801fa000
> $8 : 00000000 00000000 00000000 4c696e75
> $12: 78000000 00000000 00000000 00000000
> $16: 00000000 00000000 00000000 00000000
> $20: 00000000 00000000 00000000 00000000
> $24: 00000000 00000000
> $28: 6e652900 00000000 00000000 00000000
> epc   : 00000000
> Status: 00000000
> Cause : 00000000
> Process sh (pid: 1, stackpage=801fa000)
> 
> 
> i am confused how come the epc status and cause register all are 
> reported zero.
> whether my regs ( pointer to struct pt_regs) is pointing somewhere 
> else..?

When you see a register dump like that, it's a safe
bet that your regs pointer is trashed.

> secondly Is this a problem with shell or kernel..? may be 
> somewhere the kernel is not checking the
> validity of user space address and hence this problem.

By definition, it would be a kernel problem even if
the shell *had* made a bogus reference.  Worst
case, an error in user mode should cause a core
dump (of course, if it's init that dumps core, you
aren't likely to get to a system login).

You seem to be pretty new to this, so let me recommend
that you first read the FAQ and related information at
http://www.linux-mips.org/, and if you want further
help from the mailing list, please specify what CPU and
board/system you are targeting, which kernel sources you used, 
and what tools you used to build it,  all of which are pretty 
important.

            Kevin K.

From ralf@linux-mips.org Wed Nov 20 13:36:42 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 13:36:42 +0100 (CET)
Received: from p508B4A7D.dip.t-dialin.net ([80.139.74.125]:935 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1123956AbSKTMgm>; Wed, 20 Nov 2002 13:36:42 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAKCZbK28496;
	Wed, 20 Nov 2002 13:35:37 +0100
Date: Wed, 20 Nov 2002 13:35:37 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: epc status cause all are reported zero?
Message-ID: <20021120133537.A26255@linux-mips.org>
References: <20021120104638.23926.qmail@webmail36.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021120104638.23926.qmail@webmail36.rediffmail.com>; from atulsrivastava9@rediffmail.com on Wed, Nov 20, 2002 at 10:46:38AM -0000
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: 680
X-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, Nov 20, 2002 at 10:46:38AM -0000, atul srivastava wrote:

> During exec there is a page fault of 4000b0 but immediately after 
> that i get another page fault 0f 0x0fc01788 and following register 
> dump after it
> fails to get a fixup address.
> 
> Unable to handle kernel paging request at virtual address 
> 0fc01788, epc == 00000Oops in fault.c:do_page_fault, line 230:
> $0 : 00000000 00000000 00000000 00000000
> $4 : 00007340 800f0474 00000000 801fa000
> $8 : 00000000 00000000 00000000 4c696e75
> $12: 78000000 00000000 00000000 00000000
> $16: 00000000 00000000 00000000 00000000
> $20: 00000000 00000000 00000000 00000000
> $24: 00000000 00000000
> $28: 6e652900 00000000 00000000 00000000
> epc   : 00000000
> Status: 00000000
> Cause : 00000000
> Process sh (pid: 1, stackpage=801fa000)
> 
> 
> i am confused how come the epc status and cause register all are 
> reported zero.
> whether my regs ( pointer to struct pt_regs) is pointing somewhere 
> else..?

Let me elaborate a bit beyond what Kevin already said.  Normally a
sane register dump will contain an 8kB aligned KSEG0 address in $28;
$29 which is the stack pointer should be a little bit less than 8kB
bigger than $28.  The status register should never become 0.

The value in $28 should be identical to the address printed by
for stackpage, 0x801fa000.  They're not in your case so you may want
to start tracking there and find why they're not identical.

  Ralf

From macro@ds2.pg.gda.pl Wed Nov 20 23:28:09 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Nov 2002 23:28:10 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:6797 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1124260AbSKTW2J>; Wed, 20 Nov 2002 23:28:09 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA10724;
	Wed, 20 Nov 2002 23:28:27 +0100 (MET)
Date: Wed, 20 Nov 2002 23:28:26 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: linux-mips@linux-mips.org, linux-vax@mithra.physics.montana.edu
cc: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Subject: [announce] MOP support for FDDI
Message-ID: <Pine.GSO.3.96.1021120223710.5853F-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: 681
X-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,

 This may be of interest to DECstation and VAX users.

 I did some work on mopd sources recently again.  As a result, it is now
possible to boot a system over a FDDI link.  I was able to successfully
boot my DECstation 5000/240 using its DEC FDDIcontroller 700 (aka
DEFZA-AA) from my i386-based development box using a DEC
FDDIcontroller/PCI (DEFPA-AB).  The performance is not astonishing,
supposedly due to the funky hardware and firmware of the DEFZA -- a kernel
loads about 1.5 times longer than via the onboard Ethernet (LANCE) 
interface, even though both interfaces request the same packet length for
incoming packets.  A DEC FDDIcontroller/TURBOchannel (DEFTA-xx) would
likely perform much better. 

 I suppose a VAX equipped with a TURBOchannel adapter and either of the
controllers would be able to boot using it as well.  And similarly for the
native FDDI interfaces (DEC FDDIcontroller 400, aka DEMFA, etc.). 

 Both MOP version 3 and 4 are supported.  While the DEFZA uses version 3,
differences between the versions are minimal (different SNAP protocol
IDs), so even though untested, version 4 should just work, too.

 Apart from adding FDDI support, I did a few clean-ups.  One detail to
note is mopd now binds packet sockets it creates to specific interfaces. 
As a result response packets are only directed to the interface requests
come from.  There is a drawback of the change, though -- if any of the
interfaces mopd listens on gets down, the daemon dies.  This is yet to be
resolved. 

 Raw patches as well as RPM packages (source, mipsel and i386) are
available at the usual places -- the master site is at
'ftp://ftp.ds2.pg.gda.pl/pub/macro/'.

 Please cc replies, if any, to the linux-mips list or to me directly. 

  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 Thu Nov 21 14:07:00 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 14:07:00 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:47275 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1122123AbSKUNHA>; Thu, 21 Nov 2002 14:07:00 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA26094
	for <linux-mips@linux-mips.org>; Thu, 21 Nov 2002 14:07:21 +0100 (MET)
Date: Thu, 21 Nov 2002 14:07:20 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: linux-mips@linux-mips.org
Subject: [RFT] DEC SCSI driver clean-up
Message-ID: <Pine.GSO.3.96.1021121134955.24541B-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: 682
X-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,

 Following is a patch that removes SCp.have_data_in references -- the
member is initialized by the NCR53C9x.c core and by the dec_esp.c
front-end, but used by neither.  I believe it's some leftover cruft from
the days there were no front-ends -- it's actually used by esp.c.  There
are a few less significant clean-ups here and there as well. 

 I want to apply the patch to the CVS, but I have no means to test it with
a SCSI device -- I could only verify after the change the driver works
well enough to detect the absence of devices in my systems.  I would
appreciate if someone with a real SCSI setup could test these changes
before I apply them.

  Maciej

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

patch-mips-2.4.20-pre6-20021106-mips64-dec_esp-2
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021106.macro/drivers/scsi/NCR53C9x.c linux-mips-2.4.20-pre6-20021106/drivers/scsi/NCR53C9x.c
--- linux-mips-2.4.20-pre6-20021106.macro/drivers/scsi/NCR53C9x.c	2002-09-12 03:20:28.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021106/drivers/scsi/NCR53C9x.c	2002-10-22 23:02:09.000000000 +0000
@@ -917,7 +917,7 @@ static void esp_get_dmabufs(struct NCR_E
 		if (esp->dma_mmu_get_scsi_one)
 			esp->dma_mmu_get_scsi_one(esp, sp);
 		else
-			sp->SCp.have_data_in = (int) sp->SCp.ptr =
+			sp->SCp.ptr =
 				(char *) virt_to_phys(sp->request_buffer);
 	} else {
 		sp->SCp.buffer = (struct scatterlist *) sp->buffer;
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021106.macro/drivers/scsi/dec_esp.c linux-mips-2.4.20-pre6-20021106/drivers/scsi/dec_esp.c
--- linux-mips-2.4.20-pre6-20021106.macro/drivers/scsi/dec_esp.c	2002-10-02 17:22:42.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021106/drivers/scsi/dec_esp.c	2002-10-22 23:49:24.000000000 +0000
@@ -323,7 +323,7 @@ static int dma_bytes_sent(struct NCR_ESP
 static void dma_drain(struct NCR_ESP *esp)
 {
 	unsigned long nw = *scsi_scr;
-	unsigned short *p = KSEG1ADDR((unsigned short *) ((*scsi_dma_ptr) >> 3));
+	unsigned short *p = (unsigned short *)KSEG1ADDR((*scsi_dma_ptr) >> 3);
 
     /*
 	 * Is there something in the dma buffers left?
@@ -437,8 +437,7 @@ static void dma_setup(struct NCR_ESP *es
  */
 static void dma_mmu_get_scsi_one(struct NCR_ESP *esp, Scsi_Cmnd * sp)
 {
-	sp->SCp.have_data_in = PHYSADDR(sp->SCp.buffer);
-	sp->SCp.ptr = (char *) ((unsigned long) sp->SCp.have_data_in);
+	sp->SCp.ptr = (char *)PHYSADDR(sp->SCp.buffer);
 }
 
 static void dma_mmu_get_scsi_sgl(struct NCR_ESP *esp, Scsi_Cmnd * sp)
@@ -484,8 +483,8 @@ static void pmaz_dma_init_write(struct N
 {
 	volatile int *dmareg = (volatile int *) ( esp->slot + DEC_SCSI_DMAREG );
 
-	memcpy((void *) (esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE),
-			KSEG0ADDR((void *) vaddress), length);
+	memcpy((void *)(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE),
+	       (void *)KSEG0ADDR(vaddress), length);
 
 	*dmareg = TC_ESP_DMAR_WRITE |
 		TC_ESP_DMA_ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE);
@@ -516,7 +515,5 @@ static void pmaz_dma_setup(struct NCR_ES
 
 static void pmaz_dma_mmu_get_scsi_one(struct NCR_ESP *esp, Scsi_Cmnd * sp)
 {
-	sp->SCp.have_data_in = (int) sp->SCp.ptr =
-	    (char *) KSEG0ADDR((sp->request_buffer));
+	sp->SCp.ptr = (char *)KSEG0ADDR((sp->request_buffer));
 }
-


From Geert.Uytterhoeven@sonycom.com Thu Nov 21 14:24:01 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 14:24:02 +0100 (CET)
Received: from [195.0.45.172] ([195.0.45.172]:60412 "EHLO mail.sonytel.be")
	by linux-mips.org with ESMTP id <S1122123AbSKUNYB>;
	Thu, 21 Nov 2002 14:24:01 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id OAA04697;
	Thu, 21 Nov 2002 14:23:12 +0100 (MET)
Date: Thu, 21 Nov 2002 14:23:13 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>
Subject: Re: [RFT] DEC SCSI driver clean-up
In-Reply-To: <Pine.GSO.3.96.1021121134955.24541B-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.21.0211211422360.18129-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: 683
X-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, 21 Nov 2002, Maciej W. Rozycki wrote:
>  Following is a patch that removes SCp.have_data_in references -- the
> member is initialized by the NCR53C9x.c core and by the dec_esp.c
> front-end, but used by neither.  I believe it's some leftover cruft from
> the days there were no front-ends -- it's actually used by esp.c.  There
> are a few less significant clean-ups here and there as well. 

BTW, it's also used by jazz_esp, oktagon_esp, and sun3_exp (the last 2 are
m68k).

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 atulsrivastava9@rediffmail.com Thu Nov 21 14:33:31 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 14:33:32 +0100 (CET)
Received: from webmail35.rediffmail.com ([203.199.83.246]:51611 "HELO
	webmail35.rediffmail.com") by linux-mips.org with SMTP
	id <S1122123AbSKUNdb>; Thu, 21 Nov 2002 14:33:31 +0100
Received: (qmail 10572 invoked by uid 510); 21 Nov 2002 13:33:07 -0000
Date: 21 Nov 2002 13:33:07 -0000
Message-ID: <20021121133307.10571.qmail@webmail35.rediffmail.com>
Received: from unknown (203.197.184.107) by rediffmail.com via HTTP; 21 Nov 2002 13:33:07 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: mysterious page fault in _syscall3..
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 684
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello,

on Mips idt with Rc323334 core i have following problem.

1.After boot when the shell is execved the sequence goes like 
this.

in init/main.c

execve -( macro expansion in _syscall3 in unistd. h)--> sys_execve 
--> do_execve

do_execve return success and i get a sensible register dump after 
do_execve(0 call in sys_execve() like,

$0 : 00000000 00000000 00000000 00000000
$4 : 00000000 00000000 00000000 00000000
$8 : 00000000 00000000 00000000 00000000
$12: 00000000 00000000 00000000 00000000
$16: 00000000 00000000 00000000 00000000
$20: 00000000 00000000 00000000 00000000
$24: 00000000 00000000
$28: 00000000 7fff7f80 00000000 00000000
epc   : 004000b0
Status: 0000ff13
Cause : 00000020

EPC 004000b0 is verified by objdump of /bin/sh
STATUS 0000ff13 imply user mode and CAUSE 00000020 indicate 
syscall exception..all fine.

2.but immediately after sys_execve returns the value, i get a 
sudden page fault producing a imposible register dump ( epc status 
and cause all zero)

Unable to handle kernel paging request at virtual address 
0fc01788, epc == 00000000, ra == 00000000
Oops in fault.c:do_page_fault, line 225:
$0 : 00000000 00000000 00000000 00000000
$4 : 000072c0 800ef814 00000000 801fc000
$8 : 00000000 00000000 00000000 4c696e75
$12: 78000000 00000000 00000000 00000000
$16: 00000000 00000000 00000000 00000000
$20: 00000000 00000000 00000000 00000000
$24: 00000000 00000000
$28: 6e652900 00000000 00000000 00000000
epc   : 00000000
Status: 00000000
Cause : 00000000

this i guess when sys_execve returns , stack is corrupted somehow 
and regs(pointer to struct pt_regs) is no more correct.

though i haven't read fully the gcc info page and acquanited with 
nasty  asm code of _syscall3 in unistd.h , but does execve enters 
sys_execve directly by macro expansion in _syscall3 ..or there are 
relevant steps in between.?

what kind of problem i am facing ?
is this problem with saving & restoring , corruption
or in _syscall3..?
any possibility of write buffer and pipeline hazard..?

I have tried with interrupts disabled in sys_execve just for 
checking prupose..
would taking support of BDI2000 kind of debuggers will be 
helpful?

Best Regards,
Atul



__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/


From macro@ds2.pg.gda.pl Thu Nov 21 15:31:46 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 15:31:47 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:56238 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1122123AbSKUObq>; Thu, 21 Nov 2002 15:31:46 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA27620;
	Thu, 21 Nov 2002 15:32:04 +0100 (MET)
Date: Thu, 21 Nov 2002 15:32:04 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>
Subject: Re: [RFT] DEC SCSI driver clean-up
In-Reply-To: <Pine.GSO.4.21.0211211422360.18129-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1021121152229.24541C-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: 685
X-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 Thu, 21 Nov 2002, Geert Uytterhoeven wrote:

> On Thu, 21 Nov 2002, Maciej W. Rozycki wrote:
> >  Following is a patch that removes SCp.have_data_in references -- the
> > member is initialized by the NCR53C9x.c core and by the dec_esp.c
> > front-end, but used by neither.  I believe it's some leftover cruft from
> > the days there were no front-ends -- it's actually used by esp.c.  There
> > are a few less significant clean-ups here and there as well. 
> 
> BTW, it's also used by jazz_esp, oktagon_esp, and sun3_exp (the last 2 are
> m68k).

 Yes, I know.  Of these jazz_esp.c and sun3x_esp.c actually make use of
SCp.have_data_in and properly initialize it.  OTOH, oktagon_esp.c
initializes the field similarly to the NCR53C9x.c core, but it doesn't use
it afterwards at all and should be fixed similarly.

  Maciej

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


From ralf@linux-mips.org Thu Nov 21 15:35:26 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 15:35:27 +0100 (CET)
Received: from p508B591D.dip.t-dialin.net ([80.139.89.29]:21941 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122123AbSKUOf0>; Thu, 21 Nov 2002 15:35:26 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gALEZ1t27567;
	Thu, 21 Nov 2002 15:35:01 +0100
Date: Thu, 21 Nov 2002 15:35:01 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mysterious page fault in _syscall3..
Message-ID: <20021121153501.B26919@linux-mips.org>
References: <20021121133307.10571.qmail@webmail35.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021121133307.10571.qmail@webmail35.rediffmail.com>; from atulsrivastava9@rediffmail.com on Thu, Nov 21, 2002 at 01:33:07PM -0000
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: 686
X-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, Nov 21, 2002 at 01:33:07PM -0000, atul srivastava wrote:

> 2.but immediately after sys_execve returns the value, i get a 
> sudden page fault producing a imposible register dump ( epc status 
> and cause all zero)

Check the cache and TLB code for your architecture.  Read it 10 times if
necessary because bugs in that code can have extremly subtle effects.

> though i haven't read fully the gcc info page and acquanited with 
> nasty  asm code of _syscall3 in unistd.h , but does execve enters 
> sys_execve directly by macro expansion in _syscall3 ..or there are 
> relevant steps in between.?

I recommend to not use the _syscall macros in userspace _at_all.  They've
been written for use by kernelspace; getting them bullet proof for
userspace as well has been a big pain over the years.  I know, you're
doing this for testing only but even then you're not safe ...

In general the use of all kernel header files for userspace applications
is a dangerous idea ...

> what kind of problem i am facing ?
> is this problem with saving & restoring , corruption
> or in _syscall3..?

_syscallX() is pure userspace stuff.  Any bugs in that area should only
result in your process but not the entire system crashing.

> any possibility of write buffer and pipeline hazard..?

Write buffer stuff is only relevant for dealing with external agents that
is SMP or I/O which doesn't seem related to your case.

Double check the cache code for your CPU.  There are lots of creative
implementations of caches out there that need special treatment in the
kernel.

(That was the political correct version of speaking about those cache
designs.  My prefered wording about this issue can't be posted in any
public forum ;-)

> I have tried with interrupts disabled in sys_execve just for 
> checking prupose..
> would taking support of BDI2000 kind of debuggers will be 
> helpful?

The Linux/MIPS kernel has been ported and debugged entirely using printk
and even more important by just look at the source.

  Ralf

From ralf@linux-mips.org Thu Nov 21 15:38:09 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 15:38:10 +0100 (CET)
Received: from p508B591D.dip.t-dialin.net ([80.139.89.29]:24245 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122123AbSKUOiJ>; Thu, 21 Nov 2002 15:38:09 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gALEbmX27616;
	Thu, 21 Nov 2002 15:37:48 +0100
Date: Thu, 21 Nov 2002 15:37:48 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	tsbogend@alpha.franken.de
Subject: Re: [RFT] DEC SCSI driver clean-up
Message-ID: <20021121153748.C26919@linux-mips.org>
References: <Pine.GSO.3.96.1021121134955.24541B-100000@delta.ds2.pg.gda.pl> <Pine.GSO.4.21.0211211422360.18129-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.4.21.0211211422360.18129-100000@vervain.sonytel.be>; from geert@linux-m68k.org on Thu, Nov 21, 2002 at 02:23:13PM +0100
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: 687
X-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, Nov 21, 2002 at 02:23:13PM +0100, Geert Uytterhoeven wrote:

> BTW, it's also used by jazz_esp, oktagon_esp, and sun3_exp (the last 2 are
> m68k).

Thomas has unfortunately stopped maintaining the Jazz support so this is
probably pretty broken by now.  Nobody left who cares about Jazz, that's
Acer PICA, MIPS Magnum & Olivetti M400 ?

  Ralf

From tor@spacetec.no Thu Nov 21 15:52:07 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 15:52:07 +0100 (CET)
Received: from firewall.spacetec.no ([192.51.5.5]:55732 "EHLO
	pallas.spacetec.no") by linux-mips.org with ESMTP
	id <S1124274AbSKUOwH>; Thu, 21 Nov 2002 15:52:07 +0100
Received: (from tor@localhost)
	by pallas.spacetec.no (8.9.1a/8.9.1) id PAA25980;
	Thu, 21 Nov 2002 15:51:44 +0100
Message-Id: <200211211451.PAA25980@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Thu, 21 Nov 2002 15:51:42 +0100
In-Reply-To: Ralf Baechle <ralf@linux-mips.org>
       "Re: [RFT] DEC SCSI driver clean-up" (Nov 21, 15:38)
X-Mailer: Mail User's Shell (7.2.6 beta(4) 03/19/98)
To: Ralf Baechle <ralf@linux-mips.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [RFT] DEC SCSI driver clean-up
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	tsbogend@alpha.franken.de
Return-Path: <tor@spacetec.no>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 688
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tor@spacetec.no
Precedence: bulk
X-list: linux-mips

On Nov 21, 15:38, Ralf Baechle wrote:
>Thomas has unfortunately stopped maintaining the Jazz support so this is
>probably pretty broken by now.  Nobody left who cares about Jazz, that's
>Acer PICA, MIPS Magnum & Olivetti M400 ?

Well, I care, because I have an M400 sitting right here.. unfortunately
I have no time available for even testing the current status until
somewhen next year :-(

-Tor

From Geert.Uytterhoeven@sonycom.com Thu Nov 21 15:59:14 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 15:59:14 +0100 (CET)
Received: from mail2.sonytel.be ([195.0.45.172]:46756 "EHLO mail.sonytel.be")
	by linux-mips.org with ESMTP id <S1122123AbSKUO7O>;
	Thu, 21 Nov 2002 15:59:14 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id PAA13666;
	Thu, 21 Nov 2002 15:59:03 +0100 (MET)
Date: Thu, 21 Nov 2002 15:59:04 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	tsbogend@alpha.franken.de
Subject: Re: [RFT] DEC SCSI driver clean-up
In-Reply-To: <20021121153748.C26919@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0211211557560.18129-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: 689
X-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, 21 Nov 2002, Ralf Baechle wrote:
> On Thu, Nov 21, 2002 at 02:23:13PM +0100, Geert Uytterhoeven wrote:
> > BTW, it's also used by jazz_esp, oktagon_esp, and sun3_exp (the last 2 are
> > m68k).
> 
> Thomas has unfortunately stopped maintaining the Jazz support so this is
> probably pretty broken by now.  Nobody left who cares about Jazz, that's

Yes, it definitely doesn't work, since SCSI_JAZZ_ESP isn't used at all in
jazz_esp.c (noticed while moving the SCSI host template initializers from the
header files to the source files).

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 Nov 21 16:38:13 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 16:38:13 +0100 (CET)
Received: from p508B591D.dip.t-dialin.net ([80.139.89.29]:6326 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122123AbSKUPiN>; Thu, 21 Nov 2002 16:38:13 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gALFbdD28575;
	Thu, 21 Nov 2002 16:37:39 +0100
Date: Thu, 21 Nov 2002 16:37:39 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yoichi_yuasa@montavista.co.jp>
Cc: kevin@gv.com.tw, jsun@mvista.com, linux-mips@linux-mips.org,
	ppopov@mvista.com
Subject: Re: usb hotplug function with linux mips kernel
Message-ID: <20021121163739.D27757@linux-mips.org>
References: <20021118144212.A12262@linux-mips.org> <00a901c28fc4$76ace700$df0210ac@gv.com.tw> <20021119132922.A15266@linux-mips.org> <20021119095444.C18134@mvista.com> <1037729027.17678.112.camel@zeus.mvista.com> <20021120114930.117a78bb.yoichi_yuasa@montavista.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021120114930.117a78bb.yoichi_yuasa@montavista.co.jp>; from yoichi_yuasa@montavista.co.jp on Wed, Nov 20, 2002 at 11:49:30AM +0900
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: 690
X-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, Nov 20, 2002 at 11:49:30AM +0900, Yoichi Yuasa wrote:

> --- linux.orig/drivers/usb/hub.c	Thu Sep 12 13:09:25 2002
> +++ linux/drivers/usb/hub.c	Wed Nov 20 11:43:34 2002
> @@ -698,12 +698,6 @@
>  		return;
>  	}
>  
> -	if (usb_hub_port_debounce(hub, port)) {
> -		err("connect-debounce failed, port %d disabled", port+1);
> -		usb_hub_port_disable(hub, port);
> -		return;
> -	}
> -
>  	down(&usb_address0_sem);
>  
>  	tempstr = kmalloc(1024, GFP_KERNEL);

Looks like a total hack, don't expect me to apply this ...

  Ralf

From hansen@phys.ufl.edu Thu Nov 21 18:17:53 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 18:17:53 +0100 (CET)
Received: from neptune.phys.ufl.edu ([128.227.64.7]:728 "HELO
	neptune.phys.ufl.edu") by linux-mips.org with SMTP
	id <S1122123AbSKURRx>; Thu, 21 Nov 2002 18:17:53 +0100
Received: by neptune.phys.ufl.edu (Postfix, from userid 4468)
	id 7C644603F; Thu, 21 Nov 2002 12:17:43 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by neptune.phys.ufl.edu (Postfix) with ESMTP id 6B54C25C3C
	for <linux-mips@linux-mips.org>; Thu, 21 Nov 2002 12:17:43 -0500 (EST)
Date: Thu, 21 Nov 2002 12:17:43 -0500 (EST)
From: David Hansen <hansen@phys.ufl.edu>
To: linux-mips@linux-mips.org
Subject: Origin 2000 installation
Message-ID: <Pine.SOL.4.44.0211201038250.7939-100000@neptune.phys.ufl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <hansen@phys.ufl.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: 691
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hansen@phys.ufl.edu
Precedence: bulk
X-list: linux-mips


 I am about to begin an attempt to install Linux onto an Origin 2000 (16p
R10K 195MHz, IP27) and was curious as to whether or not there was any
documentation geared specifically to an Origin installation (preferrably
oriented towards Debian). Also, is there a searchable archive of this
mailing list so that I can search for old posts on the subject?

Thanks,
 -David







From ralf@linux-mips.org Thu Nov 21 18:41:36 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 18:41:36 +0100 (CET)
Received: from p508B591D.dip.t-dialin.net ([80.139.89.29]:33463 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122123AbSKURlg>; Thu, 21 Nov 2002 18:41:36 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gALHfJr30566;
	Thu, 21 Nov 2002 18:41:19 +0100
Date: Thu, 21 Nov 2002 18:41:19 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: David Hansen <hansen@phys.ufl.edu>
Cc: linux-mips@linux-mips.org
Subject: Re: Origin 2000 installation
Message-ID: <20021121184119.A29975@linux-mips.org>
References: <Pine.SOL.4.44.0211201038250.7939-100000@neptune.phys.ufl.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.SOL.4.44.0211201038250.7939-100000@neptune.phys.ufl.edu>; from hansen@phys.ufl.edu on Thu, Nov 21, 2002 at 12:17:43PM -0500
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: 692
X-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, Nov 21, 2002 at 12:17:43PM -0500, David Hansen wrote:

>  I am about to begin an attempt to install Linux onto an Origin 2000 (16p
> R10K 195MHz, IP27) and was curious as to whether or not there was any
> documentation geared specifically to an Origin installation (preferrably
> oriented towards Debian).

The Debian installer support Indys only so a bit of creativity will be
required to get it to work, I fear.  At least Debian doesn't ship with
Origin kernel images.

The good old trick of booting of NFS root, then transfering the NFS root
stuff to local disk will work though.

The Origin port is fairly broken in CVS right now but I'm fixing it
currently.  I've posted patches here but let me know when you need the
patches agains the latest CVS kernel.

> Also, is there a searchable archive of this
> mailing list so that I can search for old posts on the subject?

For now there are only mbox archives available on ftp.linux-mips.org
in /pub/linux/mips/archives/linux-mips.org/linux-mips/

  Ralf

From hansen@phys.ufl.edu Thu Nov 21 19:00:16 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 19:00:16 +0100 (CET)
Received: from neptune.phys.ufl.edu ([128.227.64.7]:38883 "HELO
	neptune.phys.ufl.edu") by linux-mips.org with SMTP
	id <S1122123AbSKUSAQ>; Thu, 21 Nov 2002 19:00:16 +0100
Received: by neptune.phys.ufl.edu (Postfix, from userid 4468)
	id 88B68603F; Thu, 21 Nov 2002 13:00:09 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by neptune.phys.ufl.edu (Postfix) with ESMTP
	id 77A9525C3C; Thu, 21 Nov 2002 13:00:09 -0500 (EST)
Date: Thu, 21 Nov 2002 13:00:09 -0500 (EST)
From: David Hansen <hansen@phys.ufl.edu>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Origin 2000 installation
In-Reply-To: <20021121184119.A29975@linux-mips.org>
Message-ID: <Pine.SOL.4.44.0211211254390.11471-100000@neptune.phys.ufl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <hansen@phys.ufl.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: 693
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hansen@phys.ufl.edu
Precedence: bulk
X-list: linux-mips

On Thu, 21 Nov 2002, Ralf Baechle wrote:
> The Debian installer support Indys only so a bit of creativity will be
> required to get it to work, I fear.  At least Debian doesn't ship with
> Origin kernel images.

 Is there a preferred distribution/method for Origin installations?

> The good old trick of booting of NFS root, then transfering the NFS root
> stuff to local disk will work though.

 The system does currently have an IRIX installation on it, would it be
easier to use a NFS root method or is there a documented method for doing
this from an existing local IRIX environment?

> The Origin port is fairly broken in CVS right now but I'm fixing it
> currently.  I've posted patches here but let me know when you need the
> patches agains the latest CVS kernel.
>
> For now there are only mbox archives available on ftp.linux-mips.org
> in /pub/linux/mips/archives/linux-mips.org/linux-mips/

  Great, thanks alot for the reply and information. I'll check out the
mailing list archives today.

 -David


From ralf@linux-mips.org Thu Nov 21 19:20:12 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 21 Nov 2002 19:20:12 +0100 (CET)
Received: from p508B591D.dip.t-dialin.net ([80.139.89.29]:63159 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122123AbSKUSUM>; Thu, 21 Nov 2002 19:20:12 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gALIJxA31211;
	Thu, 21 Nov 2002 19:19:59 +0100
Date: Thu, 21 Nov 2002 19:19:59 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: David Hansen <hansen@phys.ufl.edu>
Cc: linux-mips@linux-mips.org
Subject: Re: Origin 2000 installation
Message-ID: <20021121191959.B30635@linux-mips.org>
References: <20021121184119.A29975@linux-mips.org> <Pine.SOL.4.44.0211211254390.11471-100000@neptune.phys.ufl.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.SOL.4.44.0211211254390.11471-100000@neptune.phys.ufl.edu>; from hansen@phys.ufl.edu on Thu, Nov 21, 2002 at 01:00:09PM -0500
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: 694
X-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, Nov 21, 2002 at 01:00:09PM -0500, David Hansen wrote:

>  The system does currently have an IRIX installation on it, would it be
> easier to use a NFS root method or is there a documented method for doing
> this from an existing local IRIX environment?

A super-old distribution had tools to create and fill an ext2 fs from under
IRIX but nobody did maintain that, so still having IRIX isn't useful in
that context.

It doesn't harm either, Linux can coexist with IRIX.

> > The Origin port is fairly broken in CVS right now but I'm fixing it
> > currently.  I've posted patches here but let me know when you need the
> > patches agains the latest CVS kernel.
> >
> > For now there are only mbox archives available on ftp.linux-mips.org
> > in /pub/linux/mips/archives/linux-mips.org/linux-mips/
> 
>   Great, thanks alot for the reply and information. I'll check out the
> mailing list archives today.

You won't find too much O2k-related stuff though ...

  Ralf

From agx@sigxcpu.org Fri Nov 22 02:48:54 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 22 Nov 2002 02:48:54 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([134.34.144.71]:3332 "EHLO
	honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S1123952AbSKVBsy>; Fri, 22 Nov 2002 02:48:54 +0100
Received: from bogon.sigxcpu.org (unknown [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 6DCF011E10; Fri, 22 Nov 2002 02:48:47 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 9CA574AC90; Fri, 22 Nov 2002 02:45:38 +0100 (CET)
Date: Fri, 22 Nov 2002 02:45:38 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: David Hansen <hansen@phys.ufl.edu>
Cc: linux-mips@linux-mips.org
Subject: Re: Origin 2000 installation
Message-ID: <20021122014538.GL8360@bogon.ms20.nix>
References: <20021121184119.A29975@linux-mips.org> <Pine.SOL.4.44.0211211254390.11471-100000@neptune.phys.ufl.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SOL.4.44.0211211254390.11471-100000@neptune.phys.ufl.edu>
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 695
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

On Thu, Nov 21, 2002 at 01:00:09PM -0500, David Hansen wrote:
> On Thu, 21 Nov 2002, Ralf Baechle wrote:
> > The Debian installer support Indys only so a bit of creativity will be
> > required to get it to work, I fear.  At least Debian doesn't ship with
> > Origin kernel images.
> 
>  Is there a preferred distribution/method for Origin installations?
You can fetch the debian nfs-root from:
 http://ftp.debian.org/debian/dists/woody/main/disks-mips/3.0.23-2002-05-21/root.tar.gz
This and an Origin200 kernel should do the trick. I'd be nice to add
Origin support to the debian installer though.
 -- Guido

From ralf@linux-mips.org Fri Nov 22 12:43:18 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 22 Nov 2002 12:43:18 +0100 (CET)
Received: from p508B56DA.dip.t-dialin.net ([80.139.86.218]:6851 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122109AbSKVLnS>; Fri, 22 Nov 2002 12:43:18 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAMBhA617235;
	Fri, 22 Nov 2002 12:43:10 +0100
Date: Fri, 22 Nov 2002 12:43:10 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: [ADMIN] linux-mips.org downtime
Message-ID: <20021122124310.A17054@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 696
X-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

Next Tuesday, November 26, we're planning to upgrade the disk drives of
the linux-mips.org server machine.  We expect the procedure to take most
of the work day.  I'll try to temporarily move services to other machines
temporarily.  As for ftp I'd like to point people to oss.sgi.com which
still is a mirror of ftp.linux-mips.org and much higher bandwidth than
the backup machine.

Thanks,

  Ralf

From godzilla1357@yahoo.com Sat Nov 23 00:04:55 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 23 Nov 2002 00:04:56 +0100 (CET)
Received: from web14503.mail.yahoo.com ([216.136.224.66]:41338 "HELO
	web14503.mail.yahoo.com") by linux-mips.org with SMTP
	id <S1123952AbSKVXEz>; Sat, 23 Nov 2002 00:04:55 +0100
Message-ID: <20021122230439.89716.qmail@web14503.mail.yahoo.com>
Received: from [209.243.184.191] by web14503.mail.yahoo.com via HTTP; Fri, 22 Nov 2002 15:04:39 PST
Date: Fri, 22 Nov 2002 15:04:39 -0800 (PST)
From: Steve Taylor <godzilla1357@yahoo.com>
Subject: LMBench numbers for Au1500/Au1000 ?
To: lmbench-users@bitmover.com, linux-mips@linux-mips.org
Cc: godzilla1357@yahoo.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <godzilla1357@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: 697
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: godzilla1357@yahoo.com
Precedence: bulk
X-list: linux-mips

Hello,

 I am trying to get some LMbench numbers (or any other
benchmark numbers, but LMbench preferred :) ) for
Alchemy's AU1500/AU1000 processors running Linux.
Does anybody have any or know someplace where I can
get any that they would be kind enough to share?

 Apologies to linux-mips if this is not the right
mailing list for such a question, but I wasnt sure
where to mail it to get the attention of someone,
well, in the linux-mips community(!) who might have
some results.
	
 Thanks a lot.

-Steve.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

From karsten@excalibur.cologne.de Sun Nov 24 20:47:15 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 24 Nov 2002 20:47:16 +0100 (CET)
Received: from p508B747B.dip.t-dialin.net ([80.139.116.123]:8416 "EHLO
	p508B747B.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122118AbSKXTrP>; Sun, 24 Nov 2002 20:47:15 +0100
Received: from natsmtp01.webmailer.de ([IPv6:::ffff:192.67.198.81]:22729 "EHLO
	post.webmailer.de") by ralf.linux-mips.org with ESMTP
	id <S868139AbSKXTlN>; Sun, 24 Nov 2002 20:41:13 +0100
Received: from excalibur.cologne.de (p50851F45.dip.t-dialin.net [80.133.31.69])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id UAA14394
	for <linux-mips@linux-mips.org>; Sun, 24 Nov 2002 20:46:45 +0100 (MET)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 18G2l6-0001o0-00
	for <linux-mips@linux-mips.org>; Sun, 24 Nov 2002 20:49:36 +0100
Date: Sun, 24 Nov 2002 20:49:36 +0100
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Subject: Re: [RFT] DEC SCSI driver clean-up
Message-ID: <20021124194936.GA6929@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
References: <Pine.GSO.3.96.1021121134955.24541B-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.1021121134955.24541B-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.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: 698
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips

On Thu, Nov 21, 2002 at 02:07:20PM +0100, Maciej W. Rozycki wrote:

[DEC SCSI driver patch]
>  I want to apply the patch to the CVS, but I have no means to test it with
> a SCSI device -- I could only verify after the change the driver works
> well enough to detect the absence of devices in my systems.  I would
> appreciate if someone with a real SCSI setup could test these changes
> before I apply them.

At least a short test on my /150 did not show any problems.

Regards,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

From atulsrivastava9@rediffmail.com Mon Nov 25 08:53:47 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 08:53:48 +0100 (CET)
Received: from webmail36.rediffmail.com ([203.199.83.248]:26861 "HELO
	webmail36.rediffmail.com") by linux-mips.org with SMTP
	id <S1121742AbSKYHxr>; Mon, 25 Nov 2002 08:53:47 +0100
Received: (qmail 28849 invoked by uid 510); 25 Nov 2002 07:52:38 -0000
Date: 25 Nov 2002 07:52:38 -0000
Message-ID: <20021125075238.28848.qmail@webmail36.rediffmail.com>
Received: from unknown (203.200.7.93) by rediffmail.com via HTTP; 25 nov 2002 07:52:38 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: watch exception only for kseg0 addresses..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 699
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello,

I am trying to set a watch exception in (IDT RC32334) my debugging 
execise
In arch/mips/lib/watch.S says "curremtly available only for KSEG0 
address"

which is evident by following assembly..
                 LEAF(__watch_set)
                 li      t0,0x80000000
                 subu    a0,t0
                 ori     a0,7
                 xori    a0,7
                 or      a0,a1
                 mtc0    a0,CP0_WATCHLO
                 .......

it is loading the physical address of KSEG0 addresses in CP0 
watchpoint register.

in change history of this file i am able to see  KSEG0 restriction 
removed only for arch/mips64/lib/watch.S...

while my manual is not specific about KSEG0 , can i safely use it 
for all addresses ,offcourse then above assembly has to be 
modified appropiately for addresses of different regions..

Best Regards.
Ashish




From ralf@linux-mips.org Mon Nov 25 10:25:25 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 10:25:25 +0100 (CET)
Received: from p508B747B.dip.t-dialin.net ([80.139.116.123]:16873 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1121742AbSKYJZY>; Mon, 25 Nov 2002 10:25:24 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAP9Ox931362;
	Mon, 25 Nov 2002 10:24:59 +0100
Date: Mon, 25 Nov 2002 10:24:59 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: watch exception only for kseg0 addresses..?
Message-ID: <20021125102458.B22046@linux-mips.org>
References: <20021125075238.28848.qmail@webmail36.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021125075238.28848.qmail@webmail36.rediffmail.com>; from atulsrivastava9@rediffmail.com on Mon, Nov 25, 2002 at 07:52:38AM -0000
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: 700
X-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, Nov 25, 2002 at 07:52:38AM -0000, atul srivastava wrote:

>                  LEAF(__watch_set)
>                  li      t0,0x80000000
>                  subu    a0,t0
>                  ori     a0,7
>                  xori    a0,7
>                  or      a0,a1
>                  mtc0    a0,CP0_WATCHLO
>                  .......
> 
> it is loading the physical address of KSEG0 addresses in CP0 
> watchpoint register.

Additional problem - I know of at least one CPU on which the watch register
does not work for KSEG0 but only for TLB mapped registers.  That CPU
doesn't document this behaviour btw.

> in change history of this file i am able to see  KSEG0 restriction 
> removed only for arch/mips64/lib/watch.S...

The hw takes physical addresses, so using a a virtual address as argument
for __watch_set seemed to be stupid anyway.  The hw takes a physical
address and the conversion is best done in C anyway.

> while my manual is not specific about KSEG0 , can i safely use it 
> for all addresses ,offcourse then above assembly has to be 
> modified appropiately for addresses of different regions..

The whole watch stuff in the the kernel is pretty much an ad-hoc API
which I did create to debug a stack overflow.  I'm sure if you're
going to use it you'll find problems.  For userspace for example you'd
have to switch the watch register when switching the MMU context so
each process gets it's own virtual watch register.  Beyond that there
are at least two different formats of watch registers implemented in
actual silicon, the original R4000-style and the MIPS32/MIPS64 style
watch registers and the kernel's watch code only know the R4000 style
one.  So check your CPU's manual ...

  Ralf

From atulsrivastava9@rediffmail.com Mon Nov 25 11:02:57 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 11:02:57 +0100 (CET)
Received: from [203.199.83.245] ([203.199.83.245]:7869 "HELO
	mailweb33.rediffmail.com") by linux-mips.org with SMTP
	id <S1121742AbSKYKC4>; Mon, 25 Nov 2002 11:02:56 +0100
Received: (qmail 6472 invoked by uid 510); 25 Nov 2002 10:01:52 -0000
Date: 25 Nov 2002 10:01:52 -0000
Message-ID: <20021125100152.6471.qmail@mailweb33.rediffmail.com>
Received: from unknown (203.200.7.93) by rediffmail.com via HTTP; 25 nov 2002 10:01:52 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Re: watch exception only for kseg0 addresses..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 701
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

>
> > in change history of this file i am able to see  KSEG0 
>restriction
> > removed only for arch/mips64/lib/watch.S...
>
>The hw takes physical addresses, so using a a virtual address as 
>argument >for __watch_set seemed to be stupid anyway.  The hw 
>takes a physical address and the conversion is best done in C 
>anyway.

>The whole watch stuff in the the kernel is pretty much an ad-hoc 
>API
>which I did create to debug a stack overflow.  I'm sure if 
>you're
>going to use it you'll find problems.  For userspace for example 
>you'd
>have to switch the watch register when switching the MMU context 
>so
>each process gets it's own virtual watch register.
Beyond that there
>are at least two different formats of watch registers implemented 
>in
>actual silicon, the original R4000-style and the MIPS32/MIPS64 
>style
>watch registers and the kernel's watch code only know the R4000 
>style

my cpu manual ( IDT RC32334) talks about two watch registers 
CP0_IWATCH and CP0_DWATCH where it is required to just put desired 
VIRTUAL( bits 2--31) addresses to be watched , there is no mention 
of CP0_WATCHLO and CP0_WATCHHI .

additionally i guees for userspace virtual watch register problem, 
the hardware takes care of all , i just need to specify my virual 
address this is what i understand from my  manual.

and one more problem i face when i try to debug a mysterious page 
fault problem, that i get my watch exception but after page fault 
..hence I can't really debug , shouldn't the priority of watch 
exceptions should be higher than atleast instruction fetch 
exception.? or the scope of debugging by watch exception is 
limited by design.....





From ralf@linux-mips.org Mon Nov 25 11:41:37 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 11:41:38 +0100 (CET)
Received: from p508B747B.dip.t-dialin.net ([80.139.116.123]:55785 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1121742AbSKYKlh>; Mon, 25 Nov 2002 11:41:37 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAPAf9Z32634;
	Mon, 25 Nov 2002 11:41:09 +0100
Date: Mon, 25 Nov 2002 11:41:09 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Re: watch exception only for kseg0 addresses..?
Message-ID: <20021125114109.A32007@linux-mips.org>
References: <20021125100152.6471.qmail@mailweb33.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021125100152.6471.qmail@mailweb33.rediffmail.com>; from atulsrivastava9@rediffmail.com on Mon, Nov 25, 2002 at 10:01:52AM -0000
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: 702
X-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, Nov 25, 2002 at 10:01:52AM -0000, atul srivastava wrote:

> >The whole watch stuff in the the kernel is pretty much an ad-hoc 
> >API
> >which I did create to debug a stack overflow.  I'm sure if 
> >you're
> >going to use it you'll find problems.  For userspace for example 
> >you'd
> >have to switch the watch register when switching the MMU context 
> >so
> >each process gets it's own virtual watch register.
> Beyond that there
> >are at least two different formats of watch registers implemented 
> >in
> >actual silicon, the original R4000-style and the MIPS32/MIPS64 
> >style
> >watch registers and the kernel's watch code only know the R4000 
> >style

(It's horrible what mailprograms accounts do to mail formatting ...)

> my cpu manual ( IDT RC32334) talks about two watch registers 
> CP0_IWATCH and CP0_DWATCH where it is required to just put desired 
> VIRTUAL( bits 2--31) addresses to be watched , there is no mention 
> of CP0_WATCHLO and CP0_WATCHHI .
> 
> additionally i guees for userspace virtual watch register problem, 
> the hardware takes care of all , i just need to specify my virual 
> address this is what i understand from my  manual.
> 
> and one more problem i face when i try to debug a mysterious page 
> fault problem, that i get my watch exception but after page fault 
> ..hence I can't really debug , shouldn't the priority of watch 
> exceptions should be higher than atleast instruction fetch 
> exception.? or the scope of debugging by watch exception is 
> limited by design.....

No, the watch exception is one of the lowest priority exceptions.  In case
EXL/ERL are set it might even be defered making it the lowest priority
exception.

  Ralf

From macro@ds2.pg.gda.pl Mon Nov 25 12:54:53 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 12:54:54 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:56033 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1121742AbSKYLyx>; Mon, 25 Nov 2002 12:54:53 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA09706;
	Mon, 25 Nov 2002 12:55:12 +0100 (MET)
Date: Mon, 25 Nov 2002 12:55:11 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: watch exception only for kseg0 addresses..?
In-Reply-To: <20021125102458.B22046@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1021125123643.8769B-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: 703
X-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, 25 Nov 2002, Ralf Baechle wrote:

> The whole watch stuff in the the kernel is pretty much an ad-hoc API
> which I did create to debug a stack overflow.  I'm sure if you're
> going to use it you'll find problems.  For userspace for example you'd
> have to switch the watch register when switching the MMU context so
> each process gets it's own virtual watch register.  Beyond that there
> are at least two different formats of watch registers implemented in
> actual silicon, the original R4000-style and the MIPS32/MIPS64 style
> watch registers and the kernel's watch code only know the R4000 style
> one.  So check your CPU's manual ...

 I think the best use of the watch exception would be making it available
to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
support (e.g. for gdb).  Hardware support is absolutely necessary for
watching read accesses and much beneficial for write ones (otherwise gdb
single-steps code which sucks performace-wise).

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


From kevink@mips.com Mon Nov 25 13:00:57 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 13:00:57 +0100 (CET)
Received: from mx2.mips.com ([206.31.31.227]:8141 "EHLO mx2.mips.com")
	by linux-mips.org with ESMTP id <S1121742AbSKYMA4>;
	Mon, 25 Nov 2002 13:00:56 +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 gAPC0jNf007316;
	Mon, 25 Nov 2002 04:00:45 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA00114;
	Mon, 25 Nov 2002 04:00:43 -0800 (PST)
Message-ID: <00d001c2947a$d71231d0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "atul srivastava" <atulsrivastava9@rediffmail.com>,
	"Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
References: <20021125100152.6471.qmail@mailweb33.rediffmail.com>
Subject: Re: Re: watch exception only for kseg0 addresses..?
Date: Mon, 25 Nov 2002 13:04:28 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.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: 704
X-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

> > Beyond that there
> > are at least two different formats of watch registers implemented 
> > in actual silicon, the original R4000-style and the MIPS32/MIPS64 
> > style watch registers and the kernel's watch code only know the R4000 
> > style.
> 
> my cpu manual ( IDT RC32334) talks about two watch registers 
> CP0_IWATCH and CP0_DWATCH where it is required to just put desired 
> VIRTUAL( bits 2--31) addresses to be watched , there is no mention 
> of CP0_WATCHLO and CP0_WATCHHI .

Your CPU would appear to be neither MIPS32/MIPS64 compliant
nor R4000 backward-compatible.  The designers may have sought 
to simplify the use of watch registers in user space, apparently at the price 
of the restriction you are seeing.

> additionally i guees for userspace virtual watch register problem, 
> the hardware takes care of all , i just need to specify my virual 
> address this is what i understand from my  manual.
> 
> and one more problem i face when i try to debug a mysterious page 
> fault problem, that i get my watch exception but after page fault 
> ..hence I can't really debug , shouldn't the priority of watch 
> exceptions should be higher than atleast instruction fetch 
> exception.? or the scope of debugging by watch exception is 
> limited by design.....

Does your CPU implement EJTAG?

            Kevin K.

From ralf@linux-mips.org Mon Nov 25 13:18:22 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 13:18:23 +0100 (CET)
Received: from p508B747B.dip.t-dialin.net ([80.139.116.123]:43754 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1123997AbSKYMSW>; Mon, 25 Nov 2002 13:18:22 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAPCI7n12349;
	Mon, 25 Nov 2002 13:18:07 +0100
Date: Mon, 25 Nov 2002 13:18:07 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: watch exception only for kseg0 addresses..?
Message-ID: <20021125131807.B12113@linux-mips.org>
References: <20021125102458.B22046@linux-mips.org> <Pine.GSO.3.96.1021125123643.8769B-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.5.1i
In-Reply-To: <Pine.GSO.3.96.1021125123643.8769B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Mon, Nov 25, 2002 at 12:55:11PM +0100
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: 705
X-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, Nov 25, 2002 at 12:55:11PM +0100, Maciej W. Rozycki wrote:

> > The whole watch stuff in the the kernel is pretty much an ad-hoc API
> > which I did create to debug a stack overflow.  I'm sure if you're
> > going to use it you'll find problems.  For userspace for example you'd
> > have to switch the watch register when switching the MMU context so
> > each process gets it's own virtual watch register.  Beyond that there
> > are at least two different formats of watch registers implemented in
> > actual silicon, the original R4000-style and the MIPS32/MIPS64 style
> > watch registers and the kernel's watch code only know the R4000 style
> > one.  So check your CPU's manual ...
> 
>  I think the best use of the watch exception would be making it available
> to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> support (e.g. for gdb).  Hardware support is absolutely necessary for
> watching read accesses and much beneficial for write ones (otherwise gdb
> single-steps code which sucks performace-wise).

Agreed.  And because such an extension would be fully backward compatible
introduction is no problem.  So time to come up with a reasonable API.
MIPS32 / MIPS64 extend the R4000's watch capabilities significantly,
something we don't want to ignore.

  Ralf

From macro@ds2.pg.gda.pl Mon Nov 25 13:26:34 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 13:26:34 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:20195 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1121742AbSKYM0e>; Mon, 25 Nov 2002 13:26:34 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA10218;
	Mon, 25 Nov 2002 13:26:52 +0100 (MET)
Date: Mon, 25 Nov 2002 13:26:51 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Karsten Merker <karsten@excalibur.cologne.de>
cc: linux-mips@linux-mips.org
Subject: Re: [RFT] DEC SCSI driver clean-up
In-Reply-To: <20021124194936.GA6929@excalibur.cologne.de>
Message-ID: <Pine.GSO.3.96.1021125132134.8769C-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: 706
X-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 Sun, 24 Nov 2002, Karsten Merker wrote:

> At least a short test on my /150 did not show any problems.

 The change is such that if the driver works at all, it will work in all
cases, not worse then before.  The patch is now in.  Thanks a lot for
testing it. 

  Maciej

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


From macro@ds2.pg.gda.pl Mon Nov 25 13:30:42 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 13:30:43 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:34275 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1121742AbSKYMam>; Mon, 25 Nov 2002 13:30:42 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA10305;
	Mon, 25 Nov 2002 13:30:56 +0100 (MET)
Date: Mon, 25 Nov 2002 13:30:56 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	tsbogend@alpha.franken.de
Subject: Re: [RFT] DEC SCSI driver clean-up
In-Reply-To: <Pine.GSO.4.21.0211211557560.18129-100000@vervain.sonytel.be>
Message-ID: <Pine.GSO.3.96.1021125132733.8769D-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: 707
X-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 Thu, 21 Nov 2002, Geert Uytterhoeven wrote:

> Yes, it definitely doesn't work, since SCSI_JAZZ_ESP isn't used at all in
> jazz_esp.c (noticed while moving the SCSI host template initializers from the
> header files to the source files).

 I suggest the following patch for the Oktagon driver.

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

patch-mips-2.4.20-pre6-20021125-oktagon_esp-0
--- linux/drivers/scsi/oktagon_esp.c.macro	Thu Jun 27 02:59:32 2002
+++ linux/drivers/scsi/oktagon_esp.c	Mon Nov 25 12:11:43 2002
@@ -548,7 +548,7 @@ static void dma_invalidate(struct NCR_ES
 
 void dma_mmu_get_scsi_one(struct NCR_ESP *esp, Scsi_Cmnd *sp)
 {
-        sp->SCp.have_data_in = (int) sp->SCp.ptr =
+        sp->SCp.ptr =
                 sp->request_buffer;
 }
 


From henaldohzh@hotmail.com Mon Nov 25 13:47:40 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 13:47:41 +0100 (CET)
Received: from f177.law9.hotmail.com ([64.4.9.177]:29453 "EHLO hotmail.com")
	by linux-mips.org with ESMTP id <S1121742AbSKYMrk>;
	Mon, 25 Nov 2002 13:47:40 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 25 Nov 2002 04:47:28 -0800
Received: from 12.18.185.141 by lw9fd.law9.hotmail.msn.com with HTTP;
	Mon, 25 Nov 2002 12:47:28 GMT
X-Originating-IP: [12.18.185.141]
From: "" <henaldohzh@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Problem about porting mips kernel
Date: Mon, 25 Nov 2002 12:47:28 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <F177Ll1r0sdVWb9eSry000080ef@hotmail.com>
X-OriginalArrivalTime: 25 Nov 2002 12:47:28.0593 (UTC) FILETIME=[CFFC2C10:01C29480]
Return-Path: <henaldohzh@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 708
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: henaldohzh@hotmail.com
Precedence: bulk
X-list: linux-mips

Dear gentlemen,
  these days, I am busy with porting mips kernel to a board with vr4131 
core. This board has only SIU serial port, and some hw have been modified. 
Now, I have ported the kernel to it, and modified hw run well. But so 
puzzling me, the execution file cann't run at all. If some one can help me 
or give some advices. I have been crazy for the problem. Off hat for your 
help. Thanks a lot.
 btw, I use the ramdisk with busybox.

_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/lccn/ 


From ralf@linux-mips.org Mon Nov 25 13:53:21 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 13:53:21 +0100 (CET)
Received: from p508B747B.dip.t-dialin.net ([80.139.116.123]:65258 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1121742AbSKYMxV>; Mon, 25 Nov 2002 13:53:21 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAPCrA212909;
	Mon, 25 Nov 2002 13:53:10 +0100
Date: Mon, 25 Nov 2002 13:53:10 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: henaldohzh@hotmail.com
Cc: linux-mips@linux-mips.org
Subject: Re: Problem about porting mips kernel
Message-ID: <20021125135310.A12492@linux-mips.org>
References: <F177Ll1r0sdVWb9eSry000080ef@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <F177Ll1r0sdVWb9eSry000080ef@hotmail.com>; from henaldohzh@hotmail.com on Mon, Nov 25, 2002 at 12:47:28PM +0000
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: 709
X-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, Nov 25, 2002 at 12:47:28PM +0000, henaldohzh@hotmail.com wrote:

>   these days, I am busy with porting mips kernel to a board with vr4131 
> core. This board has only SIU serial port, and some hw have been modified. 
> Now, I have ported the kernel to it, and modified hw run well. But so 
> puzzling me, the execution file cann't run at all. If some one can help me 
> or give some advices. I have been crazy for the problem. Off hat for your 
> help. Thanks a lot.
>  btw, I use the ramdisk with busybox.

In general this kind of problem means the tlb or cache code for a particular
platform is faulty or the kernel not configured properly.

  Ralf

From atulsrivastava9@rediffmail.com Mon Nov 25 14:55:48 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 14:55:49 +0100 (CET)
Received: from [203.199.83.147] ([203.199.83.147]:40086 "HELO
	webmail25.rediffmail.com") by linux-mips.org with SMTP
	id <S1122118AbSKYNzs>; Mon, 25 Nov 2002 14:55:48 +0100
Received: (qmail 19961 invoked by uid 510); 25 Nov 2002 13:54:54 -0000
Date: 25 Nov 2002 13:54:54 -0000
Message-ID: <20021125135454.19960.qmail@webmail25.rediffmail.com>
Received: from unknown (203.197.184.56) by rediffmail.com via HTTP; 25 nov 2002 13:54:54 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: does read/write trasaction hangs indicate SDRAM problem..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 710
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello,

I was trying to debug a page fault problem with watch exceptions 
but
since these exceptions (lower priority) come after the page fault 
and sometime it will also get deferred till ERL and EXL bits are 
cleared hence in this specific case they aren't helping me.

other option can be to take support of EJTAG debug available on 
my
CPU.

meanwhile i have noticed and simply tried to read the value and 
write
something on few userspace addresses(0x0 - 0x7fff_ffff) from my 
kernel and surprisingly it just hangs..ideally from my kernel i 
should be able to access all these addresses .

further VXWORKS port run fine on same piece of hardware ..does it 
looks like some mem bank configuration problem in my bootrom , or 
vxworks runs
it may be a matter of chance because of its specific 
configuration.

any suggestions ..

Best Regards,
Atul




From atulsrivastava9@rediffmail.com Mon Nov 25 14:56:54 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 14:56:54 +0100 (CET)
Received: from webmail25.rediffmail.com ([203.199.83.147]:58006 "HELO
	webmail25.rediffmail.com") by linux-mips.org with SMTP
	id <S1122118AbSKYN4y>; Mon, 25 Nov 2002 14:56:54 +0100
Received: (qmail 21618 invoked by uid 510); 25 Nov 2002 13:56:02 -0000
Date: 25 Nov 2002 13:56:02 -0000
Message-ID: <20021125135602.21617.qmail@webmail25.rediffmail.com>
Received: from unknown (203.197.184.56) by rediffmail.com via HTTP; 25 nov 2002 13:56:02 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: does read/write trasaction hangs indicate SDRAM problem..?
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 711
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello,

I was trying to debug a page fault problem with watch exceptions 
but
since these exceptions (lower priority) come after the page fault 
and sometime it will also get deferred till ERL and EXL bits are 
cleared hence in this specific case they aren't helping me.

other option can be to take support of EJTAG debug available on 
my
CPU.

meanwhile i have noticed and simply tried to read the value and 
write
something on few userspace addresses(0x0 - 0x7fff_ffff) from my 
kernel and surprisingly it just hangs..ideally from my kernel i 
should be able to access all these addresses .

further VXWORKS port run fine on same piece of hardware ..does it 
looks like some mem bank configuration problem in my bootrom , or 
vxworks runs
it may be a matter of chance because of its specific 
configuration.

any suggestions ..

Best Regards,
Atul




From drow@false.org Mon Nov 25 15:41:09 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 15:41:09 +0100 (CET)
Received: from crack.them.org ([65.125.64.184]:52936 "EHLO crack.them.org")
	by linux-mips.org with ESMTP id <S1122118AbSKYOlJ>;
	Mon, 25 Nov 2002 15:41:09 +0100
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 18GMIJ-0002GE-00; Mon, 25 Nov 2002 10:41:11 -0600
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 18GKPz-00067s-00; Mon, 25 Nov 2002 09:40:59 -0500
Date: Mon, 25 Nov 2002 09:40:59 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: watch exception only for kseg0 addresses..?
Message-ID: <20021125144059.GA23310@nevyn.them.org>
References: <20021125102458.B22046@linux-mips.org> <Pine.GSO.3.96.1021125123643.8769B-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.1021125123643.8769B-100000@delta.ds2.pg.gda.pl>
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: 712
X-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 Mon, Nov 25, 2002 at 12:55:11PM +0100, Maciej W. Rozycki wrote:
> On Mon, 25 Nov 2002, Ralf Baechle wrote:
> 
> > The whole watch stuff in the the kernel is pretty much an ad-hoc API
> > which I did create to debug a stack overflow.  I'm sure if you're
> > going to use it you'll find problems.  For userspace for example you'd
> > have to switch the watch register when switching the MMU context so
> > each process gets it's own virtual watch register.  Beyond that there
> > are at least two different formats of watch registers implemented in
> > actual silicon, the original R4000-style and the MIPS32/MIPS64 style
> > watch registers and the kernel's watch code only know the R4000 style
> > one.  So check your CPU's manual ...
> 
>  I think the best use of the watch exception would be making it available
> to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> support (e.g. for gdb).  Hardware support is absolutely necessary for
> watching read accesses and much beneficial for write ones (otherwise gdb
> single-steps code which sucks performace-wise).

(Although that isn't necessary; page-protection watchpoints are on my
TODO for next year.  They aren't quite as efficient as hardware
watchpoints but they don't require hardware support either, just an
MMU.)

Heck, you can even do read watchpoints that way.

In any case, yes, the thing to do is choose an API for these and expose
them via ptrace; not necessarily in PEEKUSER though.  There's no cost
to adding new PTRACE_* ops.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.org Mon Nov 25 16:08:46 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 16:08:46 +0100 (CET)
Received: from p508B747B.dip.t-dialin.net ([80.139.116.123]:4844 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122118AbSKYPIq>; Mon, 25 Nov 2002 16:08:46 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAPF80423363;
	Mon, 25 Nov 2002 16:08:00 +0100
Date: Mon, 25 Nov 2002 16:08:00 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: watch exception only for kseg0 addresses..?
Message-ID: <20021125160800.A22590@linux-mips.org>
References: <20021125102458.B22046@linux-mips.org> <Pine.GSO.3.96.1021125123643.8769B-100000@delta.ds2.pg.gda.pl> <20021125144059.GA23310@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021125144059.GA23310@nevyn.them.org>; from dan@debian.org on Mon, Nov 25, 2002 at 09:40:59AM -0500
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: 713
X-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, Nov 25, 2002 at 09:40:59AM -0500, Daniel Jacobowitz wrote:

> > > The whole watch stuff in the the kernel is pretty much an ad-hoc API
> > > which I did create to debug a stack overflow.  I'm sure if you're
> > > going to use it you'll find problems.  For userspace for example you'd
> > > have to switch the watch register when switching the MMU context so
> > > each process gets it's own virtual watch register.  Beyond that there
> > > are at least two different formats of watch registers implemented in
> > > actual silicon, the original R4000-style and the MIPS32/MIPS64 style
> > > watch registers and the kernel's watch code only know the R4000 style
> > > one.  So check your CPU's manual ...
> > 
> >  I think the best use of the watch exception would be making it available
> > to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> > support (e.g. for gdb).  Hardware support is absolutely necessary for
> > watching read accesses and much beneficial for write ones (otherwise gdb
> > single-steps code which sucks performace-wise).
> 
> (Although that isn't necessary; page-protection watchpoints are on my
> TODO for next year.  They aren't quite as efficient as hardware
> watchpoints but they don't require hardware support either, just an
> MMU.)
> 
> Heck, you can even do read watchpoints that way.
> 
> In any case, yes, the thing to do is choose an API for these and expose
> them via ptrace; not necessarily in PEEKUSER though.  There's no cost
> to adding new PTRACE_* ops.

I assume you got and R4000 manual and the MIPS64 spec.   R4000 implements
matching a physical address with a granularity of 8 bytes for load and
store operations.

MIPS64 extends that to also support instruction address matches; the
granularity can be set anywhere from 8 bytes to 4kB; in addition ASID
matching and a global bit can be used for matching.  A MIPS64 CPU can
support anywhere from 0 to 4 such watch registers.

The global bit stuff would only be useful for in-kernel use, I think.  The
ASID thing could be used to implement watchpoints for an entire process, not
just per thread though I doubt there is much use for something like that.

So how would a prefered ptrace(2) API for hardware watchpoints look like?

  Ralf

From macro@ds2.pg.gda.pl Mon Nov 25 16:29:58 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 16:29:59 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:55019 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1122118AbSKYP36>; Mon, 25 Nov 2002 16:29:58 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA13570;
	Mon, 25 Nov 2002 16:30:13 +0100 (MET)
Date: Mon, 25 Nov 2002 16:30:13 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Daniel Jacobowitz <dan@debian.org>
cc: Ralf Baechle <ralf@linux-mips.org>,
	atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: watch exception only for kseg0 addresses..?
In-Reply-To: <20021125144059.GA23310@nevyn.them.org>
Message-ID: <Pine.GSO.3.96.1021125162225.8769H-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: 714
X-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, 25 Nov 2002, Daniel Jacobowitz wrote:

> >  I think the best use of the watch exception would be making it available
> > to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> > support (e.g. for gdb).  Hardware support is absolutely necessary for
> > watching read accesses and much beneficial for write ones (otherwise gdb
> > single-steps code which sucks performace-wise).
> 
> (Although that isn't necessary; page-protection watchpoints are on my
> TODO for next year.  They aren't quite as efficient as hardware
> watchpoints but they don't require hardware support either, just an
> MMU.)

 As a fallback the approach is just fine, but doesn't is suck
performance-wise for watchpoints at the stack?  It certainly sucks for
instruction fetches.  While gdb doesn't seem to use hardware breakpoints
as they are only really necessary for ROMs, other software may want to
(well, gdb too, one day). 

> In any case, yes, the thing to do is choose an API for these and expose
> them via ptrace; not necessarily in PEEKUSER though.  There's no cost
> to adding new PTRACE_* ops.

 Sure, as long as common sense is applied.

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


From macro@ds2.pg.gda.pl Mon Nov 25 16:47:14 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 16:47:14 +0100 (CET)
Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:44524 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S1122118AbSKYPrO>; Mon, 25 Nov 2002 16:47:14 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA13933;
	Mon, 25 Nov 2002 16:47:34 +0100 (MET)
Date: Mon, 25 Nov 2002 16:47:33 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Daniel Jacobowitz <dan@debian.org>,
	atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: watch exception only for kseg0 addresses..?
In-Reply-To: <20021125160800.A22590@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1021125163423.8769I-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: 715
X-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, 25 Nov 2002, Ralf Baechle wrote:

> MIPS64 extends that to also support instruction address matches; the
> granularity can be set anywhere from 8 bytes to 4kB; in addition ASID
> matching and a global bit can be used for matching.  A MIPS64 CPU can
> support anywhere from 0 to 4 such watch registers.

 Actually up to eight -- for all dmfc0/dmtc0 3-bit "sel" values, if I read
it correctly.

> The global bit stuff would only be useful for in-kernel use, I think.  The
> ASID thing could be used to implement watchpoints for an entire process, not
> just per thread though I doubt there is much use for something like that.

 Well, there are two options only -- either use global matching or ASID
matching.  What else would you expect?  Do you mean lazy vs immediate
switching? 

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


From JAnderson@xyronsemi.com Mon Nov 25 18:48:24 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 18:48:25 +0100 (CET)
Received: from [208.187.37.97] ([208.187.37.97]:7947 "EHLO
	usvan01a.xyronsemi.com") by linux-mips.org with ESMTP
	id <S1122118AbSKYRsY>; Mon, 25 Nov 2002 18:48:24 +0100
To: linux-mips@linux-mips.org
Subject: GRUB for MIPS?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.10  March 22, 2002
Message-ID: <OF0C671142.6F18C55C-ON88256C7C.0060F56F-88256C7C.006197E4@xyronsemi.com>
From: "James Anderson" <JAnderson@xyronsemi.com>
Date: Mon, 25 Nov 2002 09:48:05 -0800
X-MIMETrack: Serialize by Router on USVAN01A/XyronSemi(Release 5.0.9a |January 7, 2002) at
 11/25/2002 09:48:24 AM,
	Serialize complete at 11/25/2002 09:48:24 AM
Content-Type: multipart/alternative; boundary="=_alternative 006197DC88256C7C_="
Return-Path: <JAnderson@xyronsemi.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: 716
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: JAnderson@xyronsemi.com
Precedence: bulk
X-list: linux-mips

This is a multipart message in MIME format.
--=_alternative 006197DC88256C7C_=
Content-Type: text/plain; charset="us-ascii"

Has anyone ported GRUB to a mips target?   Is it feasible or does it
not make sense?  Popular alternatives to load Linux from a local/remote 
filesystem?

TIA,

- James

BTW - can anyone point me to a search page for the linux-mips archives? 
Thanks again...
--=_alternative 006197DC88256C7C_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Has anyone ported GRUB to a mips target? &nbsp; Is it feasible or does it</font>
<br><font size=2 face="sans-serif">not make sense? &nbsp;Popular alternatives to load Linux from a local/remote filesystem?</font>
<br>
<br><font size=2 face="sans-serif">TIA,</font>
<br>
<br><font size=2 face="sans-serif">- James</font>
<br>
<br><font size=2 face="sans-serif">BTW - can anyone point me to a search page for the linux-mips archives? &nbsp;Thanks again...</font>
--=_alternative 006197DC88256C7C_=--

From karsten@excalibur.cologne.de Mon Nov 25 19:22:32 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 19:22:32 +0100 (CET)
Received: from p508B747B.dip.t-dialin.net ([80.139.116.123]:61920 "EHLO
	p508B747B.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S1122118AbSKYSWc>; Mon, 25 Nov 2002 19:22:32 +0100
Received: from natsmtp01.webmailer.de ([IPv6:::ffff:192.67.198.81]:48577 "EHLO
	post.webmailer.de") by ralf.linux-mips.org with ESMTP
	id <S868139AbSKYSQb>; Mon, 25 Nov 2002 19:16:31 +0100
Received: from excalibur.cologne.de (pD9E4044E.dip.t-dialin.net [217.228.4.78])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id TAA27007
	for <linux-mips@linux-mips.org>; Mon, 25 Nov 2002 19:22:12 +0100 (MET)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 18GNv7-0000CM-00
	for <linux-mips@linux-mips.org>; Mon, 25 Nov 2002 19:25:21 +0100
Date: Mon, 25 Nov 2002 19:25:20 +0100
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Subject: Re: GRUB for MIPS?
Message-ID: <20021125182520.GA751@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
References: <OF0C671142.6F18C55C-ON88256C7C.0060F56F-88256C7C.006197E4@xyronsemi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OF0C671142.6F18C55C-ON88256C7C.0060F56F-88256C7C.006197E4@xyronsemi.com>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.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: 717
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips

On Mon, Nov 25, 2002 at 09:48:05AM -0800, James Anderson wrote:

> Has anyone ported GRUB to a mips target?   Is it feasible or does it

Not that I know of.

> not make sense?  Popular alternatives to load Linux from a local/remote 
> filesystem?

Loaders depend on the target machine - we have DELO for booting 
DECstations from Harddisk, ARCBoot for booting SGI IP22 (Indy and
Indigo2) from harddisk and tip22 to easily create netbootable images
for IP22. Besides that, I know of no bootloaders besides the ones
that the machine firmware implements.

HTH,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

From ralf@linux-mips.org Mon Nov 25 19:24:01 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 25 Nov 2002 19:24:02 +0100 (CET)
Received: from p508B747B.dip.t-dialin.net ([80.139.116.123]:36845 "EHLO
	dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S1122118AbSKYSYB>; Mon, 25 Nov 2002 19:24:01 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAPINlQ30332;
	Mon, 25 Nov 2002 19:23:47 +0100
Date: Mon, 25 Nov 2002 19:23:47 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: James Anderson <JAnderson@xyronsemi.com>
Cc: linux-mips@linux-mips.org
Subject: Re: GRUB for MIPS?
Message-ID: <20021125192347.B29444@linux-mips.org>
References: <OF0C671142.6F18C55C-ON88256C7C.0060F56F-88256C7C.006197E4@xyronsemi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <OF0C671142.6F18C55C-ON88256C7C.0060F56F-88256C7C.006197E4@xyronsemi.com>; from JAnderson@xyronsemi.com on Mon, Nov 25, 2002 at 09:48:05AM -0800
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: 718
X-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, Nov 25, 2002 at 09:48:05AM -0800, James Anderson wrote:

> Has anyone ported GRUB to a mips target?   Is it feasible or does it
> not make sense?  Popular alternatives to load Linux from a local/remote 
> filesystem?

Pointless, MIPS usually has something better than a PC BIOS.

  Ralf

From henaldohzh@hotmail.com Tue Nov 26 03:00:46 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 26 Nov 2002 03:00:57 +0100 (MET)
Received: from f61.law9.hotmail.com ([IPv6:::ffff:64.4.9.61]:41988 "EHLO
	hotmail.com") by ralf.linux-mips.org with ESMTP id <S868814AbSKZCAq>;
	Tue, 26 Nov 2002 03:00:46 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 25 Nov 2002 18:06:22 -0800
Received: from 12.18.185.141 by lw9fd.law9.hotmail.msn.com with HTTP;
	Tue, 26 Nov 2002 02:06:21 GMT
X-Originating-IP: [12.18.185.141]
From: "" <henaldohzh@hotmail.com>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: Problem about porting mips kernel
Date: Tue, 26 Nov 2002 02:06:21 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <F61cMzfoV1qdiixjnzi000000e5@hotmail.com>
X-OriginalArrivalTime: 26 Nov 2002 02:06:22.0226 (UTC) FILETIME=[6AA81F20:01C294F0]
Return-Path: <henaldohzh@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 719
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: henaldohzh@hotmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1222
Lines: 36

I think that kernel had been configured properly, because I can open the 
ttyS0 device in ramdisk. It means no ramdisk problem. But I have not any 
experience to fix tlb or cache bug. If you can give some more advice? Thx.




>From: Ralf Baechle <ralf@linux-mips.org>
>To: henaldohzh@hotmail.com
>CC: linux-mips@linux-mips.org
>Subject: Re: Problem about porting mips kernel
>Date: Mon, 25 Nov 2002 13:53:10 +0100
>
>On Mon, Nov 25, 2002 at 12:47:28PM +0000, henaldohzh@hotmail.com wrote:
>
> >   these days, I am busy with porting mips kernel to a board with vr4131
> > core. This board has only SIU serial port, and some hw have been 
modified.
> > Now, I have ported the kernel to it, and modified hw run well. But so
> > puzzling me, the execution file cann't run at all. If some one can help 
me
> > or give some advices. I have been crazy for the problem. Off hat for 
your
> > help. Thanks a lot.
> >  btw, I use the ramdisk with busybox.
>
>In general this kind of problem means the tlb or cache code for a 
particular
>platform is faulty or the kernel not configured properly.
>
>   Ralf


_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:  http://explorer.msn.com/lccn/ 


From jeff_lee@coventive.com Tue Nov 26 03:12:19 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 26 Nov 2002 03:12:29 +0100 (MET)
Received: from [IPv6:::ffff:202.145.53.89] ([IPv6:::ffff:202.145.53.89]:58592
	"EHLO miao.coventive.com") by ralf.linux-mips.org with ESMTP
	id <S868815AbSKZCMT>; Tue, 26 Nov 2002 03:12:19 +0100
Received: from jefflee (PC193.ia.kh.coventive.com [192.168.23.193] (may be forged))
	by miao.coventive.com (8.11.6/8.11.6) with SMTP id gAQ2Hqx24014;
	Tue, 26 Nov 2002 10:17:52 +0800
From: "jeff" <jeff_lee@coventive.com>
To: <henaldohzh@hotmail.com>, <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Subject: RE: Problem about porting mips kernel
Date: Tue, 26 Nov 2002 10:23:05 +0800
Message-ID: <LPECIADMAHLPOFOIEEFNEEOBCLAA.jeff_lee@coventive.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <F61cMzfoV1qdiixjnzi000000e5@hotmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Return-Path: <jeff_lee@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: 720
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jeff_lee@coventive.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2210
Lines: 30

SGksIGNhbiB5b3UgdHVybiBvZmYgdGhlIGNhY2hlIG9uIG1lbnVjb25maWcgYW5kIHRyeSBhZ2Fp
bj8NCg0KUmVnYXJkcywNCg0KSmVmZg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogbGludXgtbWlwcy1ib3VuY2VAbGludXgtbWlwcy5vcmcgW21haWx0bzpsaW51eC1taXBzLWJv
dW5jZUBsaW51eC1taXBzLm9yZ11PbiBCZWhhbGYgT2YgaGVuYWxkb2h6aEBob3RtYWlsLmNvbQ0K
U2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjYsIDIwMDIgMTA6MDYgQU0NClRvOiByYWxmQGxpbnV4
LW1pcHMub3JnDQpDYzogbGludXgtbWlwc0BsaW51eC1taXBzLm9yZw0KU3ViamVjdDogUmU6IFBy
b2JsZW0gYWJvdXQgcG9ydGluZyBtaXBzIGtlcm5lbA0KDQoNCkkgdGhpbmsgdGhhdCBrZXJuZWwg
aGFkIGJlZW4gY29uZmlndXJlZCBwcm9wZXJseSwgYmVjYXVzZSBJIGNhbiBvcGVuIHRoZSANCnR0
eVMwIGRldmljZSBpbiByYW1kaXNrLiBJdCBtZWFucyBubyByYW1kaXNrIHByb2JsZW0uIEJ1dCBJ
IGhhdmUgbm90IGFueSANCmV4cGVyaWVuY2UgdG8gZml4IHRsYiBvciBjYWNoZSBidWcuIElmIHlv
dSBjYW4gZ2l2ZSBzb21lIG1vcmUgYWR2aWNlPyBUaHguDQoNCg0KDQoNCj5Gcm9tOiBSYWxmIEJh
ZWNobGUgPHJhbGZAbGludXgtbWlwcy5vcmc+DQo+VG86IGhlbmFsZG9oemhAaG90bWFpbC5jb20N
Cj5DQzogbGludXgtbWlwc0BsaW51eC1taXBzLm9yZw0KPlN1YmplY3Q6IFJlOiBQcm9ibGVtIGFi
b3V0IHBvcnRpbmcgbWlwcyBrZXJuZWwNCj5EYXRlOiBNb24sIDI1IE5vdiAyMDAyIDEzOjUzOjEw
ICswMTAwDQo+DQo+T24gTW9uLCBOb3YgMjUsIDIwMDIgYXQgMTI6NDc6MjhQTSArMDAwMCwgaGVu
YWxkb2h6aEBob3RtYWlsLmNvbSB3cm90ZToNCj4NCj4gPiAgIHRoZXNlIGRheXMsIEkgYW0gYnVz
eSB3aXRoIHBvcnRpbmcgbWlwcyBrZXJuZWwgdG8gYSBib2FyZCB3aXRoIHZyNDEzMQ0KPiA+IGNv
cmUuIFRoaXMgYm9hcmQgaGFzIG9ubHkgU0lVIHNlcmlhbCBwb3J0LCBhbmQgc29tZSBodyBoYXZl
IGJlZW4gDQptb2RpZmllZC4NCj4gPiBOb3csIEkgaGF2ZSBwb3J0ZWQgdGhlIGtlcm5lbCB0byBp
dCwgYW5kIG1vZGlmaWVkIGh3IHJ1biB3ZWxsLiBCdXQgc28NCj4gPiBwdXp6bGluZyBtZSwgdGhl
IGV4ZWN1dGlvbiBmaWxlIGNhbm4ndCBydW4gYXQgYWxsLiBJZiBzb21lIG9uZSBjYW4gaGVscCAN
Cm1lDQo+ID4gb3IgZ2l2ZSBzb21lIGFkdmljZXMuIEkgaGF2ZSBiZWVuIGNyYXp5IGZvciB0aGUg
cHJvYmxlbS4gT2ZmIGhhdCBmb3IgDQp5b3VyDQo+ID4gaGVscC4gVGhhbmtzIGEgbG90Lg0KPiA+
ICBidHcsIEkgdXNlIHRoZSByYW1kaXNrIHdpdGggYnVzeWJveC4NCj4NCj5JbiBnZW5lcmFsIHRo
aXMga2luZCBvZiBwcm9ibGVtIG1lYW5zIHRoZSB0bGIgb3IgY2FjaGUgY29kZSBmb3IgYSANCnBh
cnRpY3VsYXINCj5wbGF0Zm9ybSBpcyBmYXVsdHkgb3IgdGhlIGtlcm5lbCBub3QgY29uZmlndXJl
ZCBwcm9wZXJseS4NCj4NCj4gICBSYWxmDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsPit9HPwtTYIE1TTiBFeHBs
b3JlcjogIGh0dHA6Ly9leHBsb3Jlci5tc24uY29tL2xjY24vIA0K


From henaldohzh@hotmail.com Tue Nov 26 03:16:19 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 26 Nov 2002 03:16:30 +0100 (MET)
Received: from f169.law9.hotmail.com ([IPv6:::ffff:64.4.9.169]:5380 "EHLO
	hotmail.com") by ralf.linux-mips.org with ESMTP id <S868817AbSKZCQT>;
	Tue, 26 Nov 2002 03:16:19 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 25 Nov 2002 18:22:02 -0800
Received: from 12.18.185.141 by lw9fd.law9.hotmail.msn.com with HTTP;
	Tue, 26 Nov 2002 02:22:02 GMT
X-Originating-IP: [12.18.185.141]
From: "" <henaldohzh@hotmail.com>
To: jeff_lee@coventive.com
Cc: linux-mips@linux-mips.org
Subject: RE: Problem about porting mips kernel
Date: Tue, 26 Nov 2002 02:22:02 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <F169TgbLYluLCTaogxL00000112@hotmail.com>
X-OriginalArrivalTime: 26 Nov 2002 02:22:02.0868 (UTC) FILETIME=[9B52B340:01C294F2]
Return-Path: <henaldohzh@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 721
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: henaldohzh@hotmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2092
Lines: 69


  Yes. I have disabled the cache once on menuconfig. But still same 
problem.


>From: "jeff" <jeff_lee@coventive.com>
>To: <henaldohzh@hotmail.com>, <ralf@linux-mips.org>
>CC: <linux-mips@linux-mips.org>
>Subject: RE: Problem about porting mips kernel
>Date: Tue, 26 Nov 2002 10:23:05 +0800
>
>Hi, can you turn off the cache on menuconfig and try again?
>
>Regards,
>
>Jeff
>
>-----Original Message-----
>From: linux-mips-bounce@linux-mips.org 
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of 
henaldohzh@hotmail.com
>Sent: Tuesday, November 26, 2002 10:06 AM
>To: ralf@linux-mips.org
>Cc: linux-mips@linux-mips.org
>Subject: Re: Problem about porting mips kernel
>
>
>I think that kernel had been configured properly, because I can open the
>ttyS0 device in ramdisk. It means no ramdisk problem. But I have not any
>experience to fix tlb or cache bug. If you can give some more advice? Thx.
>
>
>
>
> >From: Ralf Baechle <ralf@linux-mips.org>
> >To: henaldohzh@hotmail.com
> >CC: linux-mips@linux-mips.org
> >Subject: Re: Problem about porting mips kernel
> >Date: Mon, 25 Nov 2002 13:53:10 +0100
> >
> >On Mon, Nov 25, 2002 at 12:47:28PM +0000, henaldohzh@hotmail.com wrote:
> >
> > >   these days, I am busy with porting mips kernel to a board with 
vr4131
> > > core. This board has only SIU serial port, and some hw have been
>modified.
> > > Now, I have ported the kernel to it, and modified hw run well. But so
> > > puzzling me, the execution file cann't run at all. If some one can 
help
>me
> > > or give some advices. I have been crazy for the problem. Off hat for
>your
> > > help. Thanks a lot.
> > >  btw, I use the ramdisk with busybox.
> >
> >In general this kind of problem means the tlb or cache code for a
>particular
> >platform is faulty or the kernel not configured properly.
> >
> >   Ralf
>
>
>_________________________________________________________________
>Ãâ·ÑÏÂÔØ MSN Explorer:  http://explorer.msn.com/lccn/


_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/lccn/ 


From hjl@lucon.org Thu Nov 28 15:47:19 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:48:30 +0100 (MET)
Received: from rwcrmhc51.attbi.com ([IPv6:::ffff:204.127.198.38]:42625 "EHLO
	rwcrmhc51.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S869101AbSK1Hvh>; Thu, 28 Nov 2002 08:51:37 +0100
Received: from lucon.org (12-234-88-146.client.attbi.com[12.234.88.146])
          by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP
          id <20021128075637051007sbo0e>; Thu, 28 Nov 2002 07:56:37 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 79AE82C69D; Wed, 27 Nov 2002 23:56:35 -0800 (PST)
Date: Wed, 27 Nov 2002 23:56:35 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: 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, Ron Guilmette <rfg@monkeys.com>,
	"Polstra; John" <linux-binutils-in@polstra.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	Feher Janos <aries@hal2000.terra.vein.hu>,
	Leonard Zubkoff <lnz@dandelion.com>,
	"Steven J. Hill" <sjhill@cotw.com>, linux-gcc@vger.kernel.org
Subject: The Linux binutils 2.13.90.0.16 is released
Message-ID: <20021127235635.A22872@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 722
X-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
Content-Length: 18805
Lines: 672

This is the beta release of binutils 2.13.90.0.16 for Linux, which is
based on binutils 2002 1126 in CVS on sourecs.redhat.com plus various
changes. It is purely for Linux.

The Linux/mips support is added. You have to use

# rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz

to build it. Or you can read mips/README in the source tree to apply
the mips patches and build it by hand.

FYI, the binutils man pages now are generated from the texinfo files
during the build. As the result, those man pages may be changed for
each build even if you only have done

# ..../configure ...
# make

That means you may have many failures on the man pages when you apply
the binutils diffs next time. Those failures can be safely ignored.
You should remove all those man pages from your source tree by

# find -name *.1 | xargs rm -f
# find -name *.1.rej | xargs rm -f
# find -name *.man | xargs rm -f
# find -name *.man.rej | xargs rm -f

Please report any bugs related to binutils 2.13.90.0.16 to hjl@lucon.org.

For arm-linux targets, there are some important differences in behaviour 
between these tools and binutils 2.9.1.0.x.  The linker emulation name has 
changed from elf32arm{26} to armelf_linux{26}.  Also, the "-p" flag must be 
passed with the linker when working with object files (or static libraries) 
created using older versions of the assembler.  If this flag is omitted the 
linker will silently generate bad output when given old input files.

To get the correct behaviour from gcc, amend the *link section of your specs 
file as follows:

*link:
%{h*} %{version:-v}    %{b} %{Wl,*:%*}    %{static:-Bstatic}    %{shared:-shared}    %{symbolic:-Bsymbolic}    %{rdynamic:-export-dynamic}    %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2}    -X    %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p


Changes from binutils 2.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.

Changes from binutils 2.12.90.0.15:

1. Update from binutils 2002 0802.
2. Initial support for mips n32 ABI.
3. Fix some x86 TLS bugs.

Changes from binutils 2.12.90.0.14:

1. Update from binutils 2002 0717.
2. Fix an ia64 assembler bug.
3. Fix a symbol versioning bug.
4. You have to upgrade to modutils 2.4.19 or apply the modutils patch
enclosed here in order to support System.map generated by the new nm.

Changes from binutils 2.12.90.0.12:

1. Update from binutils 2002 0627.
2. Fix a linker bug which leads to the incorrect Linux 2.2 kernel.

Changes from binutils 2.12.90.0.11:

1. Update from binutils 2002 0618.
2. Fix a mips assembler bug.

Changes from binutils 2.12.90.0.9:

1. Update from binutils 2002 0608.
2. Fix an ELF/mips SHF_MERGE bug.

Changes from binutils 2.12.90.0.7:

1. Update from binutils 2002 0526.
2. Support "-z muldefs".

Changes from binutils 2.12.90.0.4:

1. Update from binutils 2002 0423.
2. ELF EH frame bug fix.
3. MIPS ELF visibility bug fix.

Changes from binutils 2.12.90.0.3:

1. Update from binutils 2002 0408.
2. Bug fixes for ELF/sparc.
3. Bug fixes for ELF/CRIS.

Changes from binutils 2.12.90.0.1:

1. Update from binutils 2002 0323.
2. Fix linking a.out relocatable files with ELF.
3. Fix a PPC altivec assembler bug.

Changes from binutils 2.11.93.0.2:

1. Update from binutils 2002 0307.
2. Add the .preinit_array/.init_array/.fini_array support.
3. Fix eh_frame.
4. Turn on combreloc by default.
5. Enable gprof for Linux/mips.

Changes from binutils 2.11.92.0.12.3:

1. Update from binutils 2002 0207.
2. Fix a weak symbol alpha linker bug for glibc.
3. More support for gcc 3.1.

Changes from binutils 2.11.92.0.12:

1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object
files.

Changes from binutils 2.11.92.0.10:

1. Update from binutils 2001 1121.
2. Fix a linker symbol version bug for common symbols.
3. Update handling relocations against the discarded sections. You may
need to apply the kernel patch enclosed here to your kernel source. If
you still see things like

drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit'

in the final kernel link, that means you have compiled a driver into
the kernel which has a reference to the symbol in a discarded section.
Kernel 2.4.17 or above should work fine.

4. Support "-march=xxx -mipsN" for mips gas if they are compatible.

Changes from binutils 2.11.92.0.7:

1. Update from binutils 2001 1021.
2. Fix the ELF/PPC linker.
3. Fix the ELF/cris linker.
4. Fix ELF strip.

Changes from binutils 2.11.92.0.5:

1. Update from binutils 2001 1016.
2. Fix all breakages introduced in 2.11.92.0.12.

Changes from binutils 2.11.90.0.31:

1. Update from binutils 2001 1005.
2. Support gcc 3.1 for ia64.
3. Support prelink for ELF/PPC.
4. Fix an ELF/x86 linker bug for Oracle.
5. Fix a weak symbol bug.
6. Support locale.

Changes from binutils 2.11.90.0.29:

1. Update from binutils 2001 0830.
2. Fix a mips linker bug.

Changes from binutils 2.11.90.0.27:

1. Update from binutils 2001 0827.
2. Fix an alpha assembler bug.
3. Fix an ia64 linker bug.
4. Fix a mips linker bug.
5. Support `-z combreloc|nocombreloc' in linker.

Changes from binutils 2.11.90.0.25:

1. Update from binutils 2001 0810.
2. Fix an x86 linker bug.

Changes from binutils 2.11.90.0.24:

1. Update from binutils 2001 0726.
2. Fix an x86 assembler bug.
3. "make check" in the windres test in binutils may call uudecode. We
are working on it.
4. "make check" fails the windres test in binutils if the i386/pe
is enabled in bfd. Fixed in the next release.
5. "make check" has 2 failures in the ld-selective test in ld on
Linux/alpha. They should be marked xfail. Fixed in the next release.

Changes from binutils 2.11.90.0.23:

1. Update from binutils 2001 0714.
2. Fix Sparc/ElF for Linux/sparc.
3. Fix Alpha/ELF for gcc 3.0.

Changes from binutils 2.11.90.0.19:

1. Update from binutils 2001 0706.
2. Fix objcopy/strip broken by accident.
3. Avoid COPY relocs on ia32.
4. Fix the ia64 assembler.
5. This release may not work on Linux/sparc due to the unaligned
relocation changes, which are not handled by all versions of glibc.
The current glibc in CVS on sourceware should be ok. The last known
working binutils for Linux/sparc is 2.11.90.0.8. We are working on it.

Changes from binutils 2.11.90.0.15:

1. Update from binutils 2001 0620.
2. Fix a static linking the PIC object files on ia32.
3. Add the verion script support for --export-dynamic. It can be used
to selectively export dynamic symbols from the executables.

Changes from binutils 2.11.90.0.8:

1. Update from binutils 2001 0610.
2. Fix a gas bug for gcc 3.0.

Changes from binutils 2.11.90.0.7:

1. Update from binutils 2001 0512.
2. Fix some P/III SSE 2 assembler bugs.
3. Fix DT_NEEDED and symbol version bugs.
4. Support hidden versioned symbols in DSOs.

Changes from binutils 2.11.90.0.6:

1. Update from binutils 2001 0427.
2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5.

Changes from binutils 2.11.90.0.5:

1. Update from binutils 2001 0425.
2. Update "ld --multilib-dir PATH".

Changes from binutils 2.11.90.0.4:

1. Update from binutils 2001 0414.
2. Fix an ia64 assembler bug.
3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI.
since there are no supports for the IRIX ABI in glibc. The current
Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS
instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS
instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified
for this change. 

Changes from binutils 2.11.90.0.1:

1. Update from binutils 2001 0401.
2. Fix a gas bug for the gcc from the CVS main trunk. It involves some
changes in gas. I compiled kernel 2.2.18, gcc and glibc under
Linux/ia32. The resulting binaries work fine. 
3. Fix the linker core dump on unsupported ELF binaries.

Changes from binutils 2.10.91.0.4:

1. Update from binutils 2001 0309.

Changes from binutils 2.10.91.0.2:

1. Update from binutils 2001 0223.
2. More ia64 bug fixes.

Changes from binutils 2.10.1.0.7:

1. Update from binutils 2001 0215.
2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64.
3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32.

Changes from binutils 2.10.1.0.4:

1. Update from binutils 2001 0206.
2. Enable the IA64 support.
3. Now you need to use

# ld --oformat TARGET

instead of

# ld -oformat TARGET

The Linux kernel build may be affected. BTW

# ld --oformat TARGET

should work with all previous releases of binutils.

Changes from binutils 2.10.1.0.2:

1. Update from binutils 2000 1221.

Changes from binutils 2.10.0.33:

1. Update from binutils 2000 1119.
2. It has some symbol versioning related updates.

Changes from binutils 2.10.0.32:

1. Update from binutils 2000 1018.
2. A proper ELF/PPC visibility fix.
3. m68k-a.out is supposed to be fixed.

Changes from binutils 2.10.0.31:

1. Update from binutils 2000 1014.
2. An ELF/PPC weak symbol bug fix.
3. A new linkonce section name approach.
4. m68k-a.out is still broken. To be fixed.

Changes from binutils 2.10.0.29:

1. Update from binutils 2000 1011.
2. Back out the linkonce section name change so that C++ will work.
A different approach is being worked on.
3. m68k-a.out is known to be broken. To be fixed.

Changes from binutils 2.10.0.26:

1. Update from binutils 2000 1008.

Changes from binutils 2.10.0.24:

1. Update from binutils 2000 0907.

Changes from binutils 2.10.0.18:

1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling.
Fix the ELF/ia32 DSO not compiled with PIC.
2. Try to fix the ELF visibility bug on PPC with glibc 2.2.

Changes from binutils 2.10.0.12:

1. Update from binutils 2000 0720.
2. Fix the DT_NEEDED link bug.
3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least
on libpthread.so.

Changes from binutils 2.10.0.9:

1. Update from binutils 2000 0701. Fix the parallel build in ld when PE
is enabled.

Changes from binutils 2.9.5.0.46:

1. Update from binutils 2000 0617. The demangler support for the new
g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF
relocatable object files under ELF with symbol versioning.
2. Support for linking PE relocatable object files under ia32/ELF.

Changes from binutils 2.9.5.0.42:

1. Update from binutils 2000 0604. The ELF visibility attribuite should
work correctly now.
2. The ia32 assembler has changed the way it assembles the "jmp"
instructions to the global symbols. The old assembler will optimize the
jump to the global symbol defined in the same source file so that no
relocation will be used. The new assembler will use relocation for
global jumps. It will mainly affect PIC asm code. The segment like

	.globl  __setjmp
__setjmp:
	...
	jmp __sigsetjmp
	...
	.globl __sigsetjmp
__sigsetjmp:

is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol
and relocation will be used. Instead, it can be changed to

	.globl  __setjmp
__setjmp:
	...
	jmp sigsetjmp
	...
	.globl __sigsetjmp
__sigsetjmp:
sigsetjmp:

so that "jmp sigsetjmp" jumps to a local symbol and the new assembler
will optimize out the relocation.

Changes from binutils 2.9.5.0.41:

1. Update from binutils 2000 0512.
2. Add testsuite for ELF visibility.

Changes from binutils 2.9.5.0.37:

1. Update from binutils 2000 0502.
2. Support STV_HIDDEN and STV_INTERNAL.

Changes from binutils 2.9.5.0.35:

1. Update from binutils 2000 0418.
2. Fix an ld demangle style option bug.

Changes from binutils 2.9.5.0.34:

1. Update from binutils 2000 0412. Fix a relocation bug which affects
the Linux kernel compilation.
2. An ELF/PPC linker script update.

Changes from binutils 2.9.5.0.33:

1. Update from binutils 2000 0404. Fix the bug report bug.

Changes from binutils 2.9.5.0.32:

1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug.

Changes from binutils 2.9.5.0.31:

1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug.
2. Fix a Debian assembler security bug.

Changes from binutils 2.9.5.0.29:

1. Update from binutils 2000 0319.
2. An ELF/alpha bug is fixed.

Changes from binutils 2.9.5.0.27:

1. Update from binutils 2000 0301.
2. A demangler bug is fixed.
3. A better fix for undefined symbols with -Bsymbolic when building
shared library.

Changes from binutils 2.9.5.0.24:

1. Update from binutils 2000 0204.
2. Added -taso to linker on alpha.
3. Fixed a -shared -Bsymbolic bug when PIC is not used.

Changes from binutils 2.9.5.0.22:

1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.

Changes from binutils 2.9.5.0.21:

1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.

Changes from binutils 2.9.5.0.19:

1. Update from binutils 1999 1122. An ia32 gas bug is fixed.

Changes from binutils 2.9.5.0.16:

1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.

Changes from binutils 2.9.5.0.14:

1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".

Changes from binutils 2.9.5.0.13:

1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.

Changes from binutils 2.9.5.0.12:

1. Update from binutils 1999 0922.
2. i370 update.

Changes from binutils 2.9.5.0.11:

1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
   and sparc introduced in the last release.
2. i370 update.

Changes from binutils 2.9.5.0.10:

1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
   and sparc.
2. Remove elf/hppa since it is WIP.

Changes from binutils 2.9.5.0.8:

1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
   in x86 FP register names.

Changes from binutils 2.9.5.0.7:

1. Update from binutils 1999 0821.
2. Some MIPS changes.

Changes from binutils 2.9.5.0.6:

1. Update from binutils 1999 0813.
2. i370 update.

Changes from binutils 2.9.5.0.5:

1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.

Changes from binutils 2.9.5.0.4:

1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.

Changes from binutils 2.9.5.0.3:

1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.

Changes from binutils 2.9.4.0.8:

1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.

Changes from binutils 2.9.4.0.7:

1. Update from binutils 1999 0710. A weak symbol bug

http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html

is fixed.

Changes from binutils 2.9.4.0.6:

1. Update from binutils 1999 0626.

Changes from binutils 2.9.4.0.5:

1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
   for objcopy.

Changes from binutils 2.9.4.0.4:

1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
   now.

Changes from binutils 2.9.4.0.3:

1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.

Changes from binutils 2.9.4.0.2:

1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.

Changes from binutils 2.9.4.0.1:

1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
   Linux kernel can build.
3. Fix i370 for the new gas.

Changes from binutils 1999 0605:

1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.

The file list:

1. binutils-2.13.90.0.16.tar.gz. Source code.
2. binutils-2.13.90.0.14-2.13.90.0.16.diff.gz. Patch against the
   previous beta source code.
3. binutils-2.13.90.0.16-1.i386.rpm. IA-32 binary RPM for RedHat 7.3.

There is no separate source rpm. You can do

# rpm -ta binutils-2.13.90.0.16.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

1. http://ftp.kernel.org/pub/linux/devel/binutils/

Thanks.


H.J. Lu
hjl@lucon.org
11/27/2002
----
> On Mon, Jul 15, 2002 at 04:35:47PM +0930, Alan Modra wrote:
> > Something you might like to warn about in your next release..
> > 
> > The 2002-07-05 bfd change exposes a bug in modutils.  depmod scans the
> > output of nm for a `?' symbol type when looking for certain symbols.
> > nm used to return `?' for symbols in sections other than some standard
> > sections like .text and .data.  Now, nm returns a better guess as to
> > the symbol type.
> 

No, but it parses System.map, which is generated by nm.  This was in
modutils-2.4.16.  Fix follows.

diff -urp modutils-2.4.16.orig/depmod/depmod.c modutils-2.4.16/depmod/depmod.c
--- modutils-2.4.16.orig/depmod/depmod.c	2002-04-28 17:23:35.000000000 +0930
+++ modutils-2.4.16/depmod/depmod.c	2002-07-15 16:41:20.000000000 +0930
@@ -1060,12 +1060,9 @@ static int addksyms(char *file_syms)
 		if (!isspace(*line))	/* Adressless symbol? */
 			p = strtok(NULL, " \t\n");
 		/* The second word is either the symbol name or a type */
-		if (p && strlen(p) == 1) { /* System.map */
+		if (p && p[0] && !p[1]) { /* System.map */
 			is_mapfile = 1;
-			if (*p != '?')
-				p = NULL;
-			else
-				p = strtok(NULL, " \t\n");
+			p = strtok(NULL, " \t\n");
 		} else { /* /proc/ksyms copy */
 			if (p && strtok(NULL, " \t\n"))
 				p = NULL;
@@ -1083,7 +1080,7 @@ static int addksyms(char *file_syms)
 			if (!isspace(*line))	/* Adressless symbol? */
 				p = strtok(NULL, " \t\n");
 			if (is_mapfile) {
-				if (*p != '?')
+				if (!p || !p[0] || p[1])
 					continue;
 				p = strtok(NULL, " \t\n");
 				/* Sparc has symbols like '.div' that need to be


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

From henaldohzh@hotmail.com Thu Nov 28 15:50:15 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:50:52 +0100 (MET)
Received: from f116.law9.hotmail.com ([IPv6:::ffff:64.4.9.116]:9996 "EHLO
	hotmail.com") by ralf.linux-mips.org with ESMTP id <S868732AbSK1ChD>;
	Thu, 28 Nov 2002 03:37:03 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 27 Nov 2002 18:42:22 -0800
Received: from 12.18.185.141 by lw9fd.law9.hotmail.msn.com with HTTP;
	Thu, 28 Nov 2002 02:42:22 GMT
X-Originating-IP: [12.18.185.141]
From: "" <henaldohzh@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Re: Problem about porting mips kernel
Date: Thu, 28 Nov 2002 02:42:22 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <F116EbjkyqU7a0xtAEH00000946@hotmail.com>
X-OriginalArrivalTime: 28 Nov 2002 02:42:22.0746 (UTC) FILETIME=[C740CFA0:01C29687]
Return-Path: <henaldohzh@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 723
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: henaldohzh@hotmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1346
Lines: 31

 I carefully check the codes of TLB, but no any problem found.
 And I debug my kernel, I found that before init task jump into 
application, it means after do_execve, sp is 0. it is for 
__strnlen_user_asm function return invalid result. And I done a little 
change(only for test), the system stop after ret_from_syscall. In normal, 
it should jump to user space to execute user task.
before ret_from_syscall, the start_thread arguments 
is:"elf_entry:0x2aaa8a00,user_sp is:0x7fff7f40,cp0_status is:0x200cc13".I 
determine that the arguments are correct. But why my application cann't run 
at all?
> >   these days, I am busy with porting mips kernel to a board with vr4131
> > core. This board has only SIU serial port, and some hw have been 
modified.
> > Now, I have ported the kernel to it, and modified hw run well. But so
> > puzzling me, the execution file cann't run at all. If some one can help 
me
> > or give some advices. I have been crazy for the problem. Off hat for 
your
> > help. Thanks a lot.
> >  btw, I use the ramdisk with busybox.
>
>In general this kind of problem means the tlb or cache code for a 
particular
>platform is faulty or the kernel not configured properly.
>
>   Ralf


_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn 


From atulsrivastava9@rediffmail.com Thu Nov 28 15:51:46 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:52:23 +0100 (MET)
Received: from webmail24.rediffmail.com ([IPv6:::ffff:203.199.83.146]:57985
	"HELO webmail24.rediffmail.com") by ralf.linux-mips.org with SMTP
	id <S868988AbSK0JIl>; Wed, 27 Nov 2002 10:08:41 +0100
Received: (qmail 27125 invoked by uid 510); 27 Nov 2002 09:11:14 -0000
Date: 27 Nov 2002 09:11:14 -0000
Message-ID: <20021127091114.27117.qmail@webmail24.rediffmail.com>
Received: from unknown (203.197.186.248) by rediffmail.com via HTTP; 27 nov 2002 09:11:14 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: a quick question regarding CONFIG_MIPS_UNCACHED..
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 724
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 894
Lines: 33

Hello,

Is it sufficient to set "CONFIG_MIPS_UNCACHED" in order to track 
a
possible cache related problem otherwise hard to debug.
in so many places the functions to operate on caches are called
directly..don't they should be placed under
"#ifdef CONFIg_MIPS_UNCACHED" , if not technically then at least
for consistent coding.

secondly if once i have gone for UNCACHED operation then 
dump_tlb_all
should show the "page cheency attribute" for all entries as 
"UNCACHED" anywhere in whole address space..

in my case this attribute for some entries in TLB is still 
showing
"Cacheable, noncoherent, write-through, no write allocate" ..how 
this is possible..

following is the relevant code:--

#ifdef CONFIG_MIPS_UNCACHED
         change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);
#else
         change_cp0_config(CONF_CM_CMASK, 
CONF_CM_CACHABLE_NONCOHERENT);
#endif

Best Regards,
Atul



From ralf@linux-mips.org Thu Nov 28 15:52:44 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:53:20 +0100 (MET)
Received: from onda.linux-mips.net ([IPv6:::ffff:192.168.169.2]:26246 "EHLO
	dea.linux-mips.net") by ralf.linux-mips.org with ESMTP
	id <S868881AbSKZMsr>; Tue, 26 Nov 2002 13:48:47 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAQCsQb19320;
	Tue, 26 Nov 2002 13:54:26 +0100
Date: Tue, 26 Nov 2002 13:54:25 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Marc Zyngier <mzyngier@freesurf.fr>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: cli/sti removal from wd33c93.c
Message-ID: <20021126135425.A19238@linux-mips.org>
References: <20021125123750.A11523@linux-mips.org> <Pine.GSO.4.21.0211261340040.18990-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.4.21.0211261340040.18990-100000@vervain.sonytel.be>; from geert@linux-m68k.org on Tue, Nov 26, 2002 at 01:47:04PM +0100
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: 725
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1114
Lines: 26

On Tue, Nov 26, 2002 at 01:47:04PM +0100, Geert Uytterhoeven wrote:

> On Mon, 25 Nov 2002, Ralf Baechle wrote:
> > Below are patches to replace cli/sti and accomplices from the WD33c93
> > driver.  Who is currently the maintainer of this driver?  Ok to send to
> > Linus?
> 
> Feel free to send it to Linus. Meanwhile I'll check it in in the m68k tree.
> 
> > 2.5 doesn't boot on MIPS yet so this patch is untested.  This patch gets
> > it to build; it was written by Marc Zygnier and reviewed by me and we
> > think it does the right thing.
> 
> To me it looks OK as well. Unfortunately I don't have wd33c93 hardware (except
> in the old A500/A590, which doesn't run uClinux well/yet :-).
> 
> BTW, am I correct in assuming that the driver is broken on 2.4.x as well?
> It looks like there are lots of paths in wd33c93_intr() where interrupts
> aren't properly restored.

I don't have any recent bug reports about the driver on SGI hardware.  All
I can say it feels a little slow but I'm not sure how much I can expect
from my good ol' Indy.  And I think it would gain from being fed through
Lindent ...

  Ralf

From jongk@linux-m68k.org Thu Nov 28 15:53:46 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:54:18 +0100 (MET)
Received: from cc260354-a.hnglo1.ov.home.nl ([IPv6:::ffff:213.51.105.170]:22767
	"EHLO duron.addesk.org") by ralf.linux-mips.org with ESMTP
	id <S868894AbSKZSLY>; Tue, 26 Nov 2002 19:11:24 +0100
Received: from duron.addesk.org (localhost.localdomain [127.0.0.1])
	by duron.addesk.org (8.12.5/8.12.5) with ESMTP id gAQIGBQZ001703;
	Tue, 26 Nov 2002 19:16:11 +0100
Received: (from turrican@localhost)
	by duron.addesk.org (8.12.5/8.12.5/Submit) id gAQIGB5p001700;
	Tue, 26 Nov 2002 19:16:11 +0100
X-Authentication-Warning: duron.addesk.org: turrican set sender to jongk@linux-m68k.org using -f
Subject: Re: cli/sti removal from wd33c93.c
From: Kars de Jong <jongk@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-m68k@lists.linux-m68k.org,
	Linux/MIPS Development <linux-mips@linux-mips.org>
In-Reply-To: <20021125123750.A11523@linux-mips.org>
References: <20021125123750.A11523@linux-mips.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 26 Nov 2002 19:16:10 +0100
Message-Id: <1038334570.1669.5.camel@duron.addesk.org>
Mime-Version: 1.0
Return-Path: <jongk@linux-m68k.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: 726
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jongk@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 678
Lines: 22

On Mon, 2002-11-25 at 12:37, Ralf Baechle wrote:
> Below are patches to replace cli/sti and accomplices from the WD33c93
> driver.  Who is currently the maintainer of this driver?  Ok to send to
> Linus?

I kinda picked up where John Shifflett left it, to try and get it
working more reliably on the old MVME147 SBC I have access to at work.
Never tried it with anything beyond 2.4.19 though. Is the current 2.5
usable on m68k, anyone?
 
> 2.5 doesn't boot on MIPS yet so this patch is untested.  This patch gets
> it to build; it was written by Marc Zygnier and reviewed by me and we
> think it does the right thing.

The patch looks OK to me as well.


Kind regards,

Kars.



From werkt@csh.rit.edu Thu Nov 28 15:54:38 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:55:23 +0100 (MET)
Received: from mcp.csh.rit.edu ([IPv6:::ffff:129.21.60.9]:31619 "EHLO
	mcp.csh.rit.edu") by ralf.linux-mips.org with ESMTP
	id <S868907AbSKZWZQ>; Tue, 26 Nov 2002 23:25:16 +0100
Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5])
	by mcp.csh.rit.edu (Postfix) with ESMTP id C3634A113
	for <linux-mips@linux-mips.org>; Tue, 26 Nov 2002 17:30:30 -0500 (EST)
Date: Tue, 26 Nov 2002 17:30:29 -0500 (EST)
From: George Gensure <werkt@csh.rit.edu>
To: <linux-mips@linux-mips.org>
Subject: O2 Patches
Message-ID: <Pine.SOL.4.31.0211261728560.19456-100000@fury.csh.rit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <werkt@csh.rit.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: 727
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: werkt@csh.rit.edu
Precedence: bulk
X-list: linux-mips
Content-Length: 216
Lines: 7

What happened to Glaurung's O2 patches (to say nothing of his page in
general) from the linux-mips site?  That was the only place I could ever
find anything regarding the O2 port.

-George Gensure
werkt@csh.rit.edu


From atulsrivastava9@rediffmail.com Thu Nov 28 15:55:44 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:56:06 +0100 (MET)
Received: from webmail34.rediffmail.com ([IPv6:::ffff:203.199.83.247]:23211
	"HELO mailweb34.rediffmail.com") by ralf.linux-mips.org with SMTP
	id <S868825AbSKZMMk>; Tue, 26 Nov 2002 13:12:40 +0100
Received: (qmail 3797 invoked by uid 510); 26 Nov 2002 12:17:33 -0000
Date: 26 Nov 2002 12:17:33 -0000
Message-ID: <20021126121733.3796.qmail@mailweb34.rediffmail.com>
Received: from unknown (203.200.7.44) by rediffmail.com via HTTP; 26 nov 2002 12:17:33 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: quick question for CONFIG_MIPS_UNCACHED...
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 728
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 636
Lines: 20

Hello,
In order to confirm a cache problem is it sufficient to set
"CONFIG_MIPS_UNCACHED" , as in so many places functions to
operate on cache are called directly while they should under
"#ifdef CONFIg_MIPS_UNCACHED" if not technically then atleast
for consistent coding practice.

I am setting uncached opertion by,
change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);
now should the dump_tlb_all() show the "page coherency 
atributes"
for all entries "UNCACHED" anywhere in 4GB space..is it true ?
why in my case for some entries it is still showing "Cacheable, 
noncoherent, write-through, no write allocate" ?

Best Regards,
Atul




From maz@misterjones.org Thu Nov 28 15:56:26 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:56:52 +0100 (MET)
Received: from lopsy-lu.misterjones.org ([IPv6:::ffff:62.4.18.26]:34797 "EHLO
	crisis.wild-wind.fr.eu.org") by ralf.linux-mips.org with ESMTP
	id <S868874AbSKZMsr>; Tue, 26 Nov 2002 13:48:47 +0100
Received: from hina.wild-wind.fr.eu.org ([192.168.70.139])
	by crisis.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian))
	id 18GfGl-0000Eo-00; Tue, 26 Nov 2002 13:56:51 +0100
Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.35 #1 (Debian))
	id 18GfCu-0000cZ-00; Tue, 26 Nov 2002 13:52:52 +0100
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: cli/sti removal from wd33c93.c
References: <Pine.GSO.4.21.0211261340040.18990-100000@vervain.sonytel.be>
Organization: Metropolis -- Nowhere
X-Attribution: maz
X-Baby-1: =?iso-8859-1?q?Lo=EBn?= 12 juin 1996 13:10
X-Baby-2: None
X-Love-1: Gone
X-Love-2: Crazy-Cat
Reply-to: mzyngier@freesurf.fr
From: Marc Zyngier <mzyngier@freesurf.fr>
Date: 26 Nov 2002 13:52:52 +0100
Message-ID: <wrpadjw1oij.fsf@hina.wild-wind.fr.eu.org>
In-Reply-To: <Pine.GSO.4.21.0211261340040.18990-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <maz@misterjones.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: 729
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mzyngier@freesurf.fr
Precedence: bulk
X-list: linux-mips
Content-Length: 546
Lines: 15

>>>>> "Geert" == Geert Uytterhoeven <geert@linux-m68k.org> writes:

Geert> BTW, am I correct in assuming that the driver is broken on
Geert> 2.4.x as well?  It looks like there are lots of paths in
Geert> wd33c93_intr() where interrupts aren't properly restored.

Indeed, it looks like being (very) broken. Although it has never
failed on my Indigo-2. Maybe interrupts get restored by luck, or these
paths are never taken...

I'll make a 2.4 patch when I'll have some time...

        M.
-- 
Places change, faces change. Life is so very strange.

From atulsrivastava9@rediffmail.com Thu Nov 28 15:57:12 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:57:33 +0100 (MET)
Received: from webmail33.rediffmail.com ([IPv6:::ffff:203.199.83.245]:30125
	"HELO mailweb33.rediffmail.com") by ralf.linux-mips.org with SMTP
	id <S868827AbSKZMcw>; Tue, 26 Nov 2002 13:32:52 +0100
Received: (qmail 4511 invoked by uid 510); 26 Nov 2002 12:37:50 -0000
Date: 26 Nov 2002 12:37:50 -0000
Message-ID: <20021126123750.4510.qmail@mailweb33.rediffmail.com>
Received: from unknown (203.200.7.44) by rediffmail.com via HTTP; 26 nov 2002 12:37:50 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: quick question for CONFIG_MIPS_UNCACHED...
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 730
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 636
Lines: 20

Hello,
In order to confirm a cache problem is it sufficient to set
"CONFIG_MIPS_UNCACHED" , as in so many places functions to
operate on cache are called directly while they should under
"#ifdef CONFIg_MIPS_UNCACHED" if not technically then atleast
for consistent coding practice.

I am setting uncached opertion by,
change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);
now should the dump_tlb_all() show the "page coherency 
atributes"
for all entries "UNCACHED" anywhere in 4GB space..is it true ?
why in my case for some entries it is still showing "Cacheable, 
noncoherent, write-through, no write allocate" ?

Best Regards,
Atul




From Geert.Uytterhoeven@sonycom.com Thu Nov 28 15:57:53 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:58:24 +0100 (MET)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:60116 "EHLO
	mail.sonytel.be") by ralf.linux-mips.org with ESMTP
	id <S868829AbSKZMlT>; Tue, 26 Nov 2002 13:41:19 +0100
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA21799;
	Tue, 26 Nov 2002 13:47:03 +0100 (MET)
Date: Tue, 26 Nov 2002 13:47:04 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>,
	Marc Zyngier <mzyngier@freesurf.fr>
cc: Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: cli/sti removal from wd33c93.c
In-Reply-To: <20021125123750.A11523@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0211261340040.18990-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: 731
X-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
Content-Length: 1075
Lines: 29

On Mon, 25 Nov 2002, Ralf Baechle wrote:
> Below are patches to replace cli/sti and accomplices from the WD33c93
> driver.  Who is currently the maintainer of this driver?  Ok to send to
> Linus?

Feel free to send it to Linus. Meanwhile I'll check it in in the m68k tree.

> 2.5 doesn't boot on MIPS yet so this patch is untested.  This patch gets
> it to build; it was written by Marc Zygnier and reviewed by me and we
> think it does the right thing.

To me it looks OK as well. Unfortunately I don't have wd33c93 hardware (except
in the old A500/A590, which doesn't run uClinux well/yet :-).

BTW, am I correct in assuming that the driver is broken on 2.4.x as well?
It looks like there are lots of paths in wd33c93_intr() where interrupts aren't
properly restored.

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 atulsrivastava9@rediffmail.com Thu Nov 28 15:58:44 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 15:59:09 +0100 (MET)
Received: from webmail36.rediffmail.com ([IPv6:::ffff:203.199.83.248]:25220
	"HELO webmail36.rediffmail.com") by ralf.linux-mips.org with SMTP
	id <S868147AbSKZK6S>; Tue, 26 Nov 2002 11:58:18 +0100
Received: (qmail 16314 invoked by uid 510); 26 Nov 2002 11:02:45 -0000
Date: 26 Nov 2002 11:02:45 -0000
Message-ID: <20021126110245.16313.qmail@webmail36.rediffmail.com>
Received: from unknown (203.200.7.44) by rediffmail.com via HTTP; 26 nov 2002 11:02:45 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: quick question regarding CONFIG_MIPS_UNCACHED..
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 732
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 674
Lines: 22

Hello,

In order to confirm a cache related problem , Is just setting
CONFIG_MIPS_UNCACHED is suficient..as so many places function
to operate on caches are  called directly while they should be
under "#ifdef CONFIG_MIPS_UNCACHED " if not technically then
atleast to make coding consistent.

secondly i am setting the uncached feature by,
change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);

now, should the dump_tlb() show the page coherency attribute for 
each entries as "UNCACHED" in whole 4 gb address space..in my case 
for some entries the page coherency attribute is still showing 
"Cacheable, noncoherent, write-through, no write allocate".

Best Regards,
Atul





From ralf@linux-mips.org Thu Nov 28 16:30:41 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 16:30:52 +0100 (MET)
Received: from onda.linux-mips.net ([IPv6:::ffff:192.168.169.2]:61344 "EHLO
	dea.linux-mips.net") by ralf.linux-mips.org with ESMTP
	id <S869520AbSK1Pal>; Thu, 28 Nov 2002 16:30:41 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gASFU8q17532;
	Thu, 28 Nov 2002 16:30:08 +0100
Date: Thu, 28 Nov 2002 16:30:08 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: George Gensure <werkt@csh.rit.edu>
Cc: linux-mips@linux-mips.org
Subject: [ADMIN] Re: O2 Patches
Message-ID: <20021128163008.A17060@linux-mips.org>
References: <Pine.SOL.4.31.0211261728560.19456-100000@fury.csh.rit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.SOL.4.31.0211261728560.19456-100000@fury.csh.rit.edu>; from werkt@csh.rit.edu on Tue, Nov 26, 2002 at 05:30:29PM -0500
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: 733
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1091
Lines: 20

On Tue, Nov 26, 2002 at 05:30:29PM -0500, George Gensure wrote:

> What happened to Glaurung's O2 patches (to say nothing of his page in
> general) from the linux-mips site?  That was the only place I could ever
> find anything regarding the O2 port.

This week the linux-mips.org server machine's disks were upgraded, now it's
about to be shipped from Denmark to it's future home in the UK.  During
that time I'm running services more or less on my home DSL line.  That's
a dialup line so everybody who's using DUL or a similar list for blocking
email will no longer be able to receive email from this and other
linux-mips.org lists and is probably going to be unsubscribed automatically
after a few bounces.  Until the old machine is back most of the personal home
pages will also not be available which is why you couldn't get to
Glaurung's patches.  As for ftp.linux-mips.org, please use mirrors such
as oss.sgi.com for now; the anonymous cvs server is now on
:pserver:cvs.linux-mips.org:/home/cvs, password cvs.  The change of the
hostname of the cvs archive will be permanent.

  Ralf

From macro@ds2.pg.gda.pl Thu Nov 28 16:53:03 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 16:53:14 +0100 (MET)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:11675 "EHLO
	delta.ds2.pg.gda.pl") by ralf.linux-mips.org with ESMTP
	id <S869531AbSK1PxD>; Thu, 28 Nov 2002 16:53:03 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA02130;
	Thu, 28 Nov 2002 16:51:57 +0100 (MET)
Date: Thu, 28 Nov 2002 16:51:57 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: atul srivastava <atulsrivastava9@rediffmail.com>
cc: linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
In-Reply-To: <20021127091114.27117.qmail@webmail24.rediffmail.com>
Message-ID: <Pine.GSO.3.96.1021128164709.8C-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: 734
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 811
Lines: 25

On 27 Nov 2002, atul srivastava wrote:

> following is the relevant code:--
> 
> #ifdef CONFIG_MIPS_UNCACHED
>          change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);
> #else
>          change_cp0_config(CONF_CM_CMASK, 
> CONF_CM_CACHABLE_NONCOHERENT);
> #endif

 You are looking at obsolete code -- unless you have specific conditions
to use an explicit caching attribute for KSEG0, you should set it like the
rest of the code does it, i.e.:

change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT);

To avoid surprises here and elsewhere, you should make sure
CONFIG_NONCOHERENT_IO is set appropriately, too.

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


From ralf@linux-mips.org Thu Nov 28 17:16:48 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 17:16:59 +0100 (MET)
Received: from onda.linux-mips.net ([IPv6:::ffff:192.168.169.2]:16801 "EHLO
	dea.linux-mips.net") by ralf.linux-mips.org with ESMTP
	id <S869533AbSK1QQs>; Thu, 28 Nov 2002 17:16:48 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gASGFJh18257;
	Thu, 28 Nov 2002 17:15:19 +0100
Date: Thu, 28 Nov 2002 17:15:19 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
Message-ID: <20021128171519.A18165@linux-mips.org>
References: <20021127091114.27117.qmail@webmail24.rediffmail.com> <Pine.GSO.3.96.1021128164709.8C-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.5.1i
In-Reply-To: <Pine.GSO.3.96.1021128164709.8C-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Nov 28, 2002 at 04:51:57PM +0100
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: 735
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 718
Lines: 18

On Thu, Nov 28, 2002 at 04:51:57PM +0100, Maciej W. Rozycki wrote:

>  You are looking at obsolete code -- unless you have specific conditions
> to use an explicit caching attribute for KSEG0, you should set it like the
> rest of the code does it, i.e.:
> 
> change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT);
> 
> To avoid surprises here and elsewhere, you should make sure
> CONFIG_NONCOHERENT_IO is set appropriately, too.

We've talked about this before - the specification of the ll/sc
instructions says they only work ok on cached memory.  In the real world
they seem to work also in uncached memory but I'd not bet the farm on
that, too many implementations out there, too many chances for subtle
bugs.

  Ralf

From hartvige@mips.com Thu Nov 28 21:35:02 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 28 Nov 2002 21:35:16 +0100 (MET)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:5853 "EHLO
	mx2.mips.com") by ralf.linux-mips.org with ESMTP id <S869542AbSK1UfC>;
	Thu, 28 Nov 2002 21:35:02 +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 gASKapNf026683
	for <linux-mips@linux-mips.org>; Thu, 28 Nov 2002 12:36:51 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA00473
	for <linux-mips@linux-mips.org>; Thu, 28 Nov 2002 12:36:53 -0800 (PST)
Received: from coplin09.mips.com (IDENT:root@coplin09 [192.168.205.79])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id gASKaqb21980
	for <linux-mips@linux-mips.org>; Thu, 28 Nov 2002 21:36:53 +0100 (MET)
Received: (from hartvige@localhost)
	by coplin09.mips.com (8.11.6/8.11.6) id gASKaqD24646
	for linux-mips@linux-mips.org; Thu, 28 Nov 2002 21:36:52 +0100
From: Hartvig Ekner <hartvige@mips.com>
Message-Id: <200211282036.gASKaqD24646@coplin09.mips.com>
Subject: New 7.3 installation kit for MIPS dev boards
To: linux-mips@linux-mips.org
Date: Thu, 28 Nov 2002 21:36:52 +0100 (CET)
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <hartvige@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: 736
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvige@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1518
Lines: 34

On our FTP site, you will now be able to find a MIPS RedHat 7.3 
installation kit (for Malta boards) which contains all of the latest
RPM's from both H.J.'s 7.3 port as well as some extras. The kernel
is 2.4.18++. The complete kit is provided in both LE and BE versions.

It also includes the new SDE/Linux compiler provided by MIPS, both 
as a native toolchain, as well as a x86 cross version which has been
used for generating the kernels (kernels provided both as precompiled
binaries and complete source tree).

>From ftp.mips.com:

ftp> pwd
257 "/pub/linux/mips/installation/redhat7.3/01.00" is current directory.
ftp> dir
227 Entering Passive Mode (206,31,31,227,157,169)
150 Opening ASCII mode data connection for /bin/ls.
total 985416
-rw-r--r--   1 9618     40          15352 Nov 27 02:31 INSTALL
-rw-r--r--   1 9618     40       535359488 Nov 26 09:17 MIPS_RedHat7.3_Release-01.00.iso
-rw-r--r--   1 9618     40       473165864 Nov 26 06:42 MIPS_RedHat7.3_Release-01.00.tar.gz
-rw-r--r--   1 9618     40            589 Nov 27 02:31 README
226 Transfer complete.

Get the .tar file for an NFS install, and the .iso file for a CDROM install
directly on the Malta. It's all explained in the README and INSTALL files.

/Hartvig

-- 
 _    _   _____  ____     Hartvig Ekner        Mailto:hartvige@mips.com
 |\  /| | |____)(____                          Direct: +45 4486 5503
 | \/ | | |     _____)    MIPS Denmark         Switch: +45 4486 5555
T E C H N O L O G I E S   http://www.mips.com  Fax...: +45 4486 5556

From kelly@cs.dal.ca Fri Nov 29 04:28:25 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 04:28:39 +0100 (MET)
Received: from hlfx02-1429.ns.aliant.net ([IPv6:::ffff:156.34.61.149]:24068
	"EHLO gemini") by ralf.linux-mips.org with ESMTP id <S869792AbSK2D2Z>;
	Fri, 29 Nov 2002 04:28:25 +0100
Received: from technophobe1 ([192.168.1.99] ident=kellym)
	by gemini with esmtp (Exim 3.36 #1 (Debian))
	id 18HaaM-0000RT-00
	for <linux-mips@linux-mips.org>; Thu, 28 Nov 2002 22:08:54 -0400
Subject: SGI Octane support
From: Michael Kelly <kelly@cs.dal.ca>
To: linux-mips@linux-mips.org
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ofU9ckf7Y0IJCiEv9zM1"
Organization: 
Message-Id: <1038541193.1773.8.camel@technophobe1>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0 
Date: 28 Nov 2002 23:39:54 -0400
Return-Path: <kelly@cs.dal.ca>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 737
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kelly@cs.dal.ca
Precedence: bulk
X-list: linux-mips
Content-Length: 1211
Lines: 45


--=-ofU9ckf7Y0IJCiEv9zM1
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Is anyone currently working on SGI Octane (IP30) support?
If so, is there somewhere I could look for details?

I recently acquired an Octane system, and I'm interested in work in this
area.

I'm seeing support for IP22, IP27, and IP32 systems in the CVS
repository, but nothing for IP30.

Anyhow, thanks
-Mike

--=20

=3D-------------------------------------------------------------=3D
Mike Kelly	<kelly@cs.dal.ca>
		<http://www.cs.dal.ca/~kelly>

	There are two ways of constructing a software design:=20
	one way is to make it so simple that there are=20
	_obviously_ no deficiencies and the other way is=20
	to make it so complicated that there are no
	_obvious_ deficiencies.

=3D-------------------------------------------------------------=3D

--=-ofU9ckf7Y0IJCiEv9zM1
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQA95uGJCxotplL/n2kRAvw3AJ9+IvrB2LeMdZi7RoIF6KluwiLQ/QCfdH89
NsZMQnIr4OUeblQ1ozHszMM=
=ZdKC
-----END PGP SIGNATURE-----

--=-ofU9ckf7Y0IJCiEv9zM1--


From ralf@linux-mips.org Fri Nov 29 08:45:13 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 08:45:25 +0100 (MET)
Received: from onda.linux-mips.net ([IPv6:::ffff:192.168.169.2]:21671 "EHLO
	dea.linux-mips.net") by ralf.linux-mips.org with ESMTP
	id <S869802AbSK2HpM>; Fri, 29 Nov 2002 08:45:12 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAT7ibU08296;
	Fri, 29 Nov 2002 08:44:37 +0100
Date: Fri, 29 Nov 2002 08:44:36 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Michael Kelly <kelly@cs.dal.ca>
Cc: linux-mips@linux-mips.org
Subject: Re: SGI Octane support
Message-ID: <20021129084436.A8135@linux-mips.org>
References: <1038541193.1773.8.camel@technophobe1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <1038541193.1773.8.camel@technophobe1>; from kelly@cs.dal.ca on Thu, Nov 28, 2002 at 11:39:54PM -0400
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: 738
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 486
Lines: 15

On Thu, Nov 28, 2002 at 11:39:54PM -0400, Michael Kelly wrote:

> Is anyone currently working on SGI Octane (IP30) support?
> If so, is there somewhere I could look for details?
> 
> I recently acquired an Octane system, and I'm interested in work in this
> area.
> 
> I'm seeing support for IP22, IP27, and IP32 systems in the CVS
> repository, but nothing for IP30.

Because there is none.  IP30 is similar to Origin 200 but yet we don't
have sufficient documentation for it.

  Ralf

From atulsrivastava9@rediffmail.com Fri Nov 29 12:34:29 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 12:34:38 +0100 (MET)
Received: from webmail34.rediffmail.com ([IPv6:::ffff:203.199.83.247]:31459
	"HELO mailweb34.rediffmail.com") by ralf.linux-mips.org with SMTP
	id <S869800AbSK2Le3>; Fri, 29 Nov 2002 12:34:29 +0100
Received: (qmail 22959 invoked by uid 510); 29 Nov 2002 11:37:59 -0000
Date: 29 Nov 2002 11:37:59 -0000
Message-ID: <20021129113759.22958.qmail@mailweb34.rediffmail.com>
Received: from unknown (219.65.139.42) by rediffmail.com via HTTP; 29 nov 2002 11:37:59 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: pt_regs gets lost during exception handling.
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 739
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1964
Lines: 74

Hello,

Here is a strange case of struct pt_regs* getting corupted.

call sequence when /bin/sh getting exec'ed
-------------------------------------------
sys_execve -> do_execve -> search_binary_handle -> load_elf_binary 
-

--> padzero -> handle_tlbs -> do_page_fault(prints wrong regs 
address)

I have checked throughut from do_execve till before padzero the
regs( struct pt_regs*) is 0x801fded

inside  padzero it print the regs address and
dump of show_regs(regs) is like this---

Regs address is 0x801fded8

$0 : 00000000 8014b793 00000fab 00000060
$4 : 800efcb0 8013a5f4 8013a61c 0000000a
$8 : 800ef5ac ffffffff 00000000 8014b7c0
$12: 8014b7c1 0000002c 00000001 8014b793
$16: 8014b7c0 1000ff01 0000003e 80023ca0
$20: 8010e000 800efcad 80000000 00000000
$24: 0000002d 00000010
$28: 801fc000 801fdf88 8013a5f4 80018318
epc   : 80018344
Status: 1000ff03 ( kernel mode )
Cause : 00000020  (syscall exception)

now padzero() calculates page offset for elf_bss that comes 
0xea8.
now immediately the do_page_fault() for write access on 
0x10001ea8
is generated and it prints  like this...

Page Fault on addres 0x10001ea8 and Regs address is 0x10000000.

I was expecting the regs address passed as first arguement
in do_page_fault() to be same as 0x801fded8.

Am I correct..?

secondly in susequent page faults the regs address is printed
as 0x8013a5f4 which is the address of argv_init from

execve("/bin/sh",argv_init,envp_init);

in MACRO DO_FAULT(write) we have code piece like,

move a0,sp; \
jal do_page_fault; \
li a1,write

is the sp in first instruction not correct ?

Best Regards,
Atul





________________________________________________________________
  NIIT supports World Computer Literacy Day on 2nd December.
  Enroll for NIIT SWIFT Jyoti till 2nd December for only Rs. 749
  and get free Indian Languages Office software worth Rs. 2500.
  For details contact your nearest NIIT centre, SWIFT Point
  or click here http://swift.rediff.com/




From macro@ds2.pg.gda.pl Fri Nov 29 12:53:17 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 12:53:25 +0100 (MET)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:34765 "EHLO
	delta.ds2.pg.gda.pl") by ralf.linux-mips.org with ESMTP
	id <S869801AbSK2LxR>; Fri, 29 Nov 2002 12:53:17 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA25088;
	Fri, 29 Nov 2002 12:56:10 +0100 (MET)
Date: Fri, 29 Nov 2002 12:56:10 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
In-Reply-To: <20021128171519.A18165@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1021128172026.8D-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: 740
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1029
Lines: 23

On Thu, 28 Nov 2002, Ralf Baechle wrote:

> We've talked about this before - the specification of the ll/sc
> instructions says they only work ok on cached memory.  In the real world
> they seem to work also in uncached memory but I'd not bet the farm on
> that, too many implementations out there, too many chances for subtle
> bugs.

 Indeed -- CONFIG_MIPS_UNCACHED should either be removed or imply
CONFIG_CPU_HAS_LLSC=n.  I suppose there is some interest in the option, so
the latter is preferable.  That would imply moving the option into the CPU
configuration section as now it's set very late, long after
CONFIG_CPU_HAS_LLSC is set.  Or it could be set up the other way, i.e. the
option would only become available if CONFIG_CPU_HAS_LLSC had been set to
n.  There would be no need to move it then. 

 What do you think? 

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


From ralf@linux-mips.org Fri Nov 29 13:44:02 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 13:44:12 +0100 (MET)
Received: from onda.linux-mips.net ([IPv6:::ffff:192.168.169.2]:21673 "EHLO
	dea.linux-mips.net") by ralf.linux-mips.org with ESMTP
	id <S870068AbSK2MoC>; Fri, 29 Nov 2002 13:44:02 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gATCgVU12750;
	Fri, 29 Nov 2002 13:42:31 +0100
Date: Fri, 29 Nov 2002 13:42:30 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
Message-ID: <20021129134230.A11704@linux-mips.org>
References: <20021128171519.A18165@linux-mips.org> <Pine.GSO.3.96.1021128172026.8D-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.5.1i
In-Reply-To: <Pine.GSO.3.96.1021128172026.8D-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Nov 29, 2002 at 12:56:10PM +0100
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: 741
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1959
Lines: 46

On Fri, Nov 29, 2002 at 12:56:10PM +0100, Maciej W. Rozycki wrote:

> > We've talked about this before - the specification of the ll/sc
> > instructions says they only work ok on cached memory.  In the real world
> > they seem to work also in uncached memory but I'd not bet the farm on
> > that, too many implementations out there, too many chances for subtle
> > bugs.
> 
>  Indeed -- CONFIG_MIPS_UNCACHED should either be removed or imply
> CONFIG_CPU_HAS_LLSC=n.  I suppose there is some interest in the option, so
> the latter is preferable.  That would imply moving the option into the CPU
> configuration section as now it's set very late, long after
> CONFIG_CPU_HAS_LLSC is set.  Or it could be set up the other way, i.e. the
> option would only become available if CONFIG_CPU_HAS_LLSC had been set to
> n.  There would be no need to move it then. 
> 
>  What do you think? 

I had the same thought.  So far there are the following groups of people
using this option:

  - Hardware people using it so the the entire program is becoming visible
    externally.

    Becoming obsoleted by more advanced, less intrusive hardware debugging
    methods.

  - Software people kluding around bugs in their software.

    Don't expect me to support this.  Note with a line of code.

  - For testing if the cache code is actually working.

    Will only be useful to show big fat bugs.  For the more subtle bugs
    there is no way at all around understanding the entire cache managment
    thing including all subtilities.  Actually a good reason to not support
    this option either.

It's been my observation that hardly any user is aware of these consquences
nor is the Linux code making a good attempt at complying with all the
additional restrictions of running uncached.  So in my oppinion
CONFIG_MIPS_UNCACHED should go.  But I don't feel very strong about it so
I'm going to wait for a few days so others have a chance to raise their
voice.

  Ralf

From macro@ds2.pg.gda.pl Fri Nov 29 14:00:09 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 14:00:20 +0100 (MET)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:29904 "EHLO
	delta.ds2.pg.gda.pl") by ralf.linux-mips.org with ESMTP
	id <S870069AbSK2NAJ>; Fri, 29 Nov 2002 14:00:09 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA26282;
	Fri, 29 Nov 2002 14:03:01 +0100 (MET)
Date: Fri, 29 Nov 2002 14:03:00 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
In-Reply-To: <20021129134230.A11704@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1021129135000.24948B-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: 742
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1450
Lines: 28

On Fri, 29 Nov 2002, Ralf Baechle wrote:

> It's been my observation that hardly any user is aware of these consquences
> nor is the Linux code making a good attempt at complying with all the
> additional restrictions of running uncached.  So in my oppinion
> CONFIG_MIPS_UNCACHED should go.  But I don't feel very strong about it so
> I'm going to wait for a few days so others have a chance to raise their
> voice.

 I completely agree with your points and I'm not fond of this option,
either.  I had a need to run uncached to debug a problem once and even
then it was on the R3k, so I had to set up things differently from what
that option does anyway.  I can't recall the details of the problem, but
coding hooks for an uncached setup took me maybe half an hour, so I don't
think that is a problem for anyone who really needs it.

 BTW, how do you know that ll/sc happens to work for uncached operation on
some processors?  Maybe it simply fails, but the result is subtle enough
not to be observed easily.  A failure may be masked by other factors, e.g. 
for the UP operation, there is normally no way for two parallel requests
for a spinlock to happen and an exception resets the LLbit regardless of
the caching attribute of the area involved.

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


From carstenl@mips.com Fri Nov 29 14:48:19 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 14:48:28 +0100 (MET)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:45819 "EHLO
	mx2.mips.com") by ralf.linux-mips.org with ESMTP id <S870424AbSK2NsT>;
	Fri, 29 Nov 2002 14:48:19 +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 gATDncNf029546;
	Fri, 29 Nov 2002 05:49:38 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id FAA24088;
	Fri, 29 Nov 2002 05:49:37 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id gATDnbb22848;
	Fri, 29 Nov 2002 14:49:37 +0100 (MET)
Message-ID: <3DE77071.17FE9FED@mips.com>
Date: Fri, 29 Nov 2002 14:49:37 +0100
From: Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
References: <20021128171519.A18165@linux-mips.org> <Pine.GSO.3.96.1021128172026.8D-100000@delta.ds2.pg.gda.pl> <20021129134230.A11704@linux-mips.org>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Return-Path: <carstenl@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: 743
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: carstenl@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2460
Lines: 64

Ralf Baechle wrote:

> On Fri, Nov 29, 2002 at 12:56:10PM +0100, Maciej W. Rozycki wrote:
>
> > > We've talked about this before - the specification of the ll/sc
> > > instructions says they only work ok on cached memory.  In the real world
> > > they seem to work also in uncached memory but I'd not bet the farm on
> > > that, too many implementations out there, too many chances for subtle
> > > bugs.
> >
> >  Indeed -- CONFIG_MIPS_UNCACHED should either be removed or imply
> > CONFIG_CPU_HAS_LLSC=n.  I suppose there is some interest in the option, so
> > the latter is preferable.  That would imply moving the option into the CPU
> > configuration section as now it's set very late, long after
> > CONFIG_CPU_HAS_LLSC is set.  Or it could be set up the other way, i.e. the
> > option would only become available if CONFIG_CPU_HAS_LLSC had been set to
> > n.  There would be no need to move it then.
> >
> >  What do you think?
>
> I had the same thought.  So far there are the following groups of people
> using this option:
>
>   - Hardware people using it so the the entire program is becoming visible
>     externally.
>
>     Becoming obsoleted by more advanced, less intrusive hardware debugging
>     methods.
>
>   - Software people kluding around bugs in their software.
>
>     Don't expect me to support this.  Note with a line of code.
>
>   - For testing if the cache code is actually working.
>
>     Will only be useful to show big fat bugs.  For the more subtle bugs
>     there is no way at all around understanding the entire cache managment
>     thing including all subtilities.  Actually a good reason to not support
>     this option either.
>
> It's been my observation that hardly any user is aware of these consquences
> nor is the Linux code making a good attempt at complying with all the
> additional restrictions of running uncached.  So in my oppinion
> CONFIG_MIPS_UNCACHED should go.  But I don't feel very strong about it so
> I'm going to wait for a few days so others have a chance to raise their
> voice.
>

I have used this option a lot, it has been very useful in hardware (CPU)
debugging.


>
>   Ralf

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com




From ralf@linux-mips.org Fri Nov 29 14:56:23 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 14:56:31 +0100 (MET)
Received: from onda.linux-mips.net ([IPv6:::ffff:192.168.169.2]:54697 "EHLO
	dea.linux-mips.net") by ralf.linux-mips.org with ESMTP
	id <S870673AbSK2N4X>; Fri, 29 Nov 2002 14:56:23 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gATDgkR13634;
	Fri, 29 Nov 2002 14:42:46 +0100
Date: Fri, 29 Nov 2002 14:42:46 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
Message-ID: <20021129144246.A13295@linux-mips.org>
References: <20021129134230.A11704@linux-mips.org> <Pine.GSO.3.96.1021129135000.24948B-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.5.1i
In-Reply-To: <Pine.GSO.3.96.1021129135000.24948B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Nov 29, 2002 at 02:03:00PM +0100
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: 744
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1364
Lines: 25

On Fri, Nov 29, 2002 at 02:03:00PM +0100, Maciej W. Rozycki wrote:

>  BTW, how do you know that ll/sc happens to work for uncached operation on
> some processors?  Maybe it simply fails, but the result is subtle enough
> not to be observed easily.  A failure may be masked by other factors, e.g. 
> for the UP operation, there is normally no way for two parallel requests
> for a spinlock to happen and an exception resets the LLbit regardless of
> the caching attribute of the area involved.

That's a consequence of the simplemost way to implement ll/sc in hardware.
ll puts the physicall address of the the memory reference into c0_lladdr
and sets the ll-bit.  eret clears the ll-bit and finally sc fails if the
ll-bit is cleared.  That's the simplest implementation for a non-coherent
uniprocessor, there is not much more needed that a flip-flop and due to
every designers desire for simplicity a different implementation seem
unlikely.  Btw, c0_lladdr is just a useless gadget here.

It's different for coherent processors, those actually need to snoop on
the bus interface.  On those the simplest implementation is ll generates
a cache line in exclusive state; sc then fails if either the ll-bit has
been cleared; the snooping logic clears the ll-bit if the cache-line's
state changes or an eret is executed.  So the mechanism fails without
caches.

  Ralf

From macro@ds2.pg.gda.pl Fri Nov 29 15:20:27 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 29 Nov 2002 15:20:36 +0100 (MET)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:35539 "EHLO
	delta.ds2.pg.gda.pl") by ralf.linux-mips.org with ESMTP
	id <S870684AbSK2OU1>; Fri, 29 Nov 2002 15:20:27 +0100
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA27437;
	Fri, 29 Nov 2002 15:23:20 +0100 (MET)
Date: Fri, 29 Nov 2002 15:23:19 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: atul srivastava <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
In-Reply-To: <20021129144246.A13295@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1021129150114.24948D-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: 745
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 2332
Lines: 54

On Fri, 29 Nov 2002, Ralf Baechle wrote:

> That's a consequence of the simplemost way to implement ll/sc in hardware.
> ll puts the physicall address of the the memory reference into c0_lladdr
> and sets the ll-bit.  eret clears the ll-bit and finally sc fails if the
> ll-bit is cleared.  That's the simplest implementation for a non-coherent
> uniprocessor, there is not much more needed that a flip-flop and due to
> every designers desire for simplicity a different implementation seem
> unlikely.  Btw, c0_lladdr is just a useless gadget here.

 Hmm, MIPS doesn't support external invalidation requests for non-coherent
areas, so eret/rfe appears to be the only way to reset the LLbit.  So we
may simply make the option depend on CONFIG_NONCOHERENT_IO=y.  It would
simplify the CML hassle, too.

> It's different for coherent processors, those actually need to snoop on
> the bus interface.  On those the simplest implementation is ll generates
> a cache line in exclusive state; sc then fails if either the ll-bit has
> been cleared; the snooping logic clears the ll-bit if the cache-line's
> state changes or an eret is executed.  So the mechanism fails without
> caches.

 Oh, I think a comparator using CP0.LLAddr for any bus cycles wouldn't be
much more complicated if at all.  But it would then spuriously fail for
noncoherent areas, so the actual implementation is better.

 So how about the following patch?

 And yes, the Carsten's argument is valid, too.  The option need not
necessarily be used to debug Linux -- it may be used to debug hardware or
to run on an incomplete implementation.

  Maciej

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

patch-2.4.20-pre6-20021129-mips-uncached-0
--- linux/arch/mips/config-shared.in.macro	Fri Nov 22 13:28:35 2002
+++ linux/arch/mips/config-shared.in	Fri Nov 29 14:13:53 2002
@@ -836,9 +836,7 @@ if [ "$CONFIG_AU1000_UART" = "y" -o "$CO
 fi
 bool 'Enable run-time debugging' CONFIG_DEBUG
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
-if [ "$CONFIG_SMP" != "y" ]; then
-   bool 'Run uncached' CONFIG_MIPS_UNCACHED
-fi
+dep_bool 'Run uncached' CONFIG_MIPS_UNCACHED $CONFIG_NONCOHERENT_IO
 endmenu
 
 source lib/Config.in


From ralf@linux-mips.org Sat Nov 30 03:25:46 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 30 Nov 2002 03:25:57 +0100 (MET)
Received: from onda.linux-mips.net ([IPv6:::ffff:192.168.169.2]:14258 "EHLO
	dea.linux-mips.net") by ralf.linux-mips.org with ESMTP
	id <S870763AbSK3CZq>; Sat, 30 Nov 2002 03:25:46 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id gAU2P9412967
	for linux-mips@linux-mips.org; Sat, 30 Nov 2002 03:25:09 +0100
Date: Sat, 30 Nov 2002 03:25:09 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: IP27 support
Message-ID: <20021130032508.C12839@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.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: 746
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 388
Lines: 9

I've clean up and checked in all the IP27 patches into CVS.  This also fixed
some stuff that was never working before so whatever kernel you may be
running on an IP27, it seems time to try to upgrade.  There still seem to
be some issues with Origin 2000 systems, I'll try to fix that whenever I
get access (serial console and system controller) to an Origin 2000.

Happy hacking,

  Ralf

From hartvige@mips.com Sat Nov 30 22:35:48 2002
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 30 Nov 2002 22:35:59 +0100 (MET)
Received: from [IPv6:::ffff:206.31.31.227] ([IPv6:::ffff:206.31.31.227]:49331
	"EHLO mx2.mips.com") by ralf.linux-mips.org with ESMTP
	id <S870769AbSK3Vfs>; Sat, 30 Nov 2002 22:35:48 +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 gAULbDNf003534
	for <linux-mips@linux-mips.org>; Sat, 30 Nov 2002 13:37:14 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA16621
	for <linux-mips@linux-mips.org>; Sat, 30 Nov 2002 13:37:14 -0800 (PST)
Received: from coplin09.mips.com (IDENT:root@coplin09 [192.168.205.79])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id gAULbDb20749
	for <linux-mips@linux-mips.org>; Sat, 30 Nov 2002 22:37:14 +0100 (MET)
Received: (from hartvige@localhost)
	by coplin09.mips.com (8.11.6/8.11.6) id gAULbDi30499
	for linux-mips@linux-mips.org; Sat, 30 Nov 2002 22:37:13 +0100
From: Hartvig Ekner <hartvige@mips.com>
Message-Id: <200211302137.gAULbDi30499@coplin09.mips.com>
Subject: Re: New 7.3 installation kit for MIPS dev boards (fwd)
To: linux-mips@linux-mips.org
Date: Sat, 30 Nov 2002 22:37:13 +0100 (CET)
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <hartvige@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: 747
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hartvige@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2149
Lines: 58

Hello Sadik,

your mail address bounces, so I took the liberty to post the reply to
your question on the list. Maybe somebody else could use the answer anyway.

/Hartvig

Forwarded message:
> From hartvige Sat Nov 30 22:32:16 2002
> Subject: Re: New 7.3 installation kit for MIPS dev boards
> To: pallathu.sadik@attbi.com (Pallathu.Sadik)
> Date: Sat, 30 Nov 2002 22:32:16 +0100 (CET)
> In-Reply-To: <no.id> from "Pallathu.Sadik" at Dec 01, 2002 12:02:14 
> X-Mailer: ELM [version 2.5 PL5]
> Content-Length: 1822      
> 
> Hi Sadik,
> 
> it is included in the installation tar file (or iso file). If you
> download one of these, you will find a "kernel" and "installation" tree.
> The cross compiler is located in the kernel tree (together with the
> kernel sources). These RPMs are called:
> 
> /u/hartvige/cdrom7.3/linux> ll kernel/toolchain/
> total 13500
> -rw-r--r--    1 hartvige mips      7123453 Nov 19 11:00 sdelinux-5.01-4eb.i386.rpm
> -rw-r--r--    1 hartvige mips      6670206 Nov 19 11:00 sdelinux-5.01-4.i386.
> 
> The native version is located together will all the other RPMs automatically
> installed on the system:
> 
> /u/hartvige/cdrom7.3/linux> ll installation/RedHat7.3/RPMS/mips*/contrib/sde*
> -rw-r--r--    1 hartvige mips     11607824 Nov 26 09:43 installation/RedHat7.3/RPMS/mips/contrib/sdelinux-5.01-11.mips.rpm
> -rw-r--r--    1 hartvige mips     11567531 Nov 26 09:43 installation/RedHat7.3/RPMS/mipsel/contrib/sdelinux-5.01-11.mipsel.rpm
> 
> These 4 RPMs are currently not separately available on the FTP site, if that
> was what you were looking for?
> 
> /Hartvig
> 
> 
> Pallathu.Sadik writes:
> > 
> > Hello,
> >  
> > > It also includes the new SDE/Linux compiler provided by MIPS, both 
> > > as a native toolchain, as well as a x86 cross version which has been
> > > used for generating the kernels (kernels provided both as precompiled
> > > binaries and complete source tree).
> > > 
> >  
> >   I would appreciate, if you could inform me where the compiler is
> > located.  I did look into the readme files, but couldn't find the info
> > regarding toolchain.
> > 
> > Thanks and regards,
> > 
> > Sadik.